4 ms·

no support for xtensa/esp32 :<

by __void 4y ago

ncmncm 4y ago
Yet. But maybe that says more about esp32 than about RTEMS?
- __void 4y ago
  ..and what should this say about esp32? I don't understand what you are implying... xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture and weird memory structure because out there I find very few loader/relocator impementations (nominally I only know niicoooo's version[1], brian pug's derivative[2] for his interesting joltos, mongoose/Zephyr's supercustom versions, and my own) and this seems to be the main stumbling block for new os development in this platform [1] https://github.com/niicoooo/esp32-elfloader https://github.com/niicoooo/esp32-elfloader [2] https://github.com/joltwallet/jolt_wallet/tree/master/jolt_os/jelf_loader/src https://github.com/joltwallet/jolt_wallet/tree/master/jolt_o...
  - p_l 4y ago
    Most ESP32 devices are on the small side from RTEMS PoV, plus harvard architecture is probably an issue as well. Even with external memory, I'm not sure if I've seen any ESP32 with more than 8MB of SPI-attached RAM - this would be enough for RTEMS, but I'm not sure about viability of using SPI-attached SRAM as main memory. EDIT: Looking through processor supplements documentation for RTEMS, the 520kB of RAM in ESP32 would be enough. I guess RTEMS is simply less well known and its main users target heavier platforms whereas many people are fine with just the provided ESP32 toolkit as base "OS"
  - ajross 4y ago
    > xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture Pedantry: everyone uses a Harvard architecture, that just means having separate buses internally for instructions and data -- essentially if you have a separate icache/dcache, you're Harvard. Xtensa is weird because it's L1 caches are incoherent. As far as the architecture, it's sort of too clever for its own good. The register windowing scheme seems amazing, just a few comparators at runtime and some special exception handlers is all it takes to get 64 hardware registers to work. But... no one ever taught compilers how to deal with the complexity (the generated code needs to decide how many of its local registers to preserve across a call, which is a global optimization that depends on the behavior of the code it's invoking). So the end result is that for the same code, Xtensa code actually uses significantly more stack space than conventional architectures like ARM or RISC-V. (Their own toolchain is better at this than gcc, but still bad). And FWIW: Zephyr doesn't do dynamic loading yet. We have crazy linker behavior, but it's all static.
    - JoelSherrill 4y ago
      The Harvard architecture shouldn't be a problem. Xtensa has a gcc port so that's covered. It is mostly a matter of no one has volunteered to do it or paid for someone to do it. If someone wants to port it, we'd be happy to guide you.
      - ajross 4y ago
        I can absolutely guarantee you making SMP work in a cache incoherent environment is a hard problem. :)
  - ncmncm 4y ago
    The people using RTEMS have self-selected for building extremely reliable systems. They have preferentially maintained ports to targets that they can use for that. A popular chip without a port hints that they have not found it a good choice for building their extremely reliable systems. Not everything has to be especially reliable. Cheap is a merit of its own, as is, often, newness. Targets with maintained ports are often slower, less capable, less kitted out than what catches your eye. But if it has been out for some time without a port, it is very possible it is because it was tried and rejected for reasons. You are not obliged to find their reasons persuasive, but it might be wise to find out what they are.

no support for xtensa/esp32 :<

by __void 4y ago

no support for xtensa/esp32 :<

ncmncm 4y ago

Yet. But maybe that says more about esp32 than about RTEMS?

__void 4y ago
..and what should this say about esp32? I don't understand what you are implying... xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture and weird memory structure because out there I find very few loader/relocator impementations (nominally I only know niicoooo's version[1], brian pug's derivative[2] for his interesting joltos, mongoose/Zephyr's supercustom versions, and my own) and this seems to be the main stumbling block for new os development in this platform [1] https://github.com/niicoooo/esp32-elfloader https://github.com/niicoooo/esp32-elfloader [2] https://github.com/joltwallet/jolt_wallet/tree/master/jolt_os/jelf_loader/src https://github.com/joltwallet/jolt_wallet/tree/master/jolt_o...
- p_l 4y ago
  Most ESP32 devices are on the small side from RTEMS PoV, plus harvard architecture is probably an issue as well. Even with external memory, I'm not sure if I've seen any ESP32 with more than 8MB of SPI-attached RAM - this would be enough for RTEMS, but I'm not sure about viability of using SPI-attached SRAM as main memory. EDIT: Looking through processor supplements documentation for RTEMS, the 520kB of RAM in ESP32 would be enough. I guess RTEMS is simply less well known and its main users target heavier platforms whereas many people are fine with just the provided ESP32 toolkit as base "OS"
- ajross 4y ago
  > xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture Pedantry: everyone uses a Harvard architecture, that just means having separate buses internally for instructions and data -- essentially if you have a separate icache/dcache, you're Harvard. Xtensa is weird because it's L1 caches are incoherent. As far as the architecture, it's sort of too clever for its own good. The register windowing scheme seems amazing, just a few comparators at runtime and some special exception handlers is all it takes to get 64 hardware registers to work. But... no one ever taught compilers how to deal with the complexity (the generated code needs to decide how many of its local registers to preserve across a call, which is a global optimization that depends on the behavior of the code it's invoking). So the end result is that for the same code, Xtensa code actually uses significantly more stack space than conventional architectures like ARM or RISC-V. (Their own toolchain is better at this than gcc, but still bad). And FWIW: Zephyr doesn't do dynamic loading yet. We have crazy linker behavior, but it's all static.
  - JoelSherrill 4y ago
    The Harvard architecture shouldn't be a problem. Xtensa has a gcc port so that's covered. It is mostly a matter of no one has volunteered to do it or paid for someone to do it. If someone wants to port it, we'd be happy to guide you.
    - ajross 4y ago
      I can absolutely guarantee you making SMP work in a cache incoherent environment is a hard problem. :)
- ncmncm 4y ago
  The people using RTEMS have self-selected for building extremely reliable systems. They have preferentially maintained ports to targets that they can use for that. A popular chip without a port hints that they have not found it a good choice for building their extremely reliable systems. Not everything has to be especially reliable. Cheap is a merit of its own, as is, often, newness. Targets with maintained ports are often slower, less capable, less kitted out than what catches your eye. But if it has been out for some time without a port, it is very possible it is because it was tried and rejected for reasons. You are not obliged to find their reasons persuasive, but it might be wise to find out what they are.