5 ms·

Microprocessors in embedded devices are getting pretty capable. I've been asked to port FreeRTOS and Linux in about equal measure. What gets me is, if the sche

Microprocessors in embedded devices are getting pretty capable. I've been asked to port FreeRTOS and Linux in about equal measure. What gets me is, if the schematic designer would annotate the schematic with address, busses, chip pin uses, then I could write a script to port a new design to a particular OS automatically. My job would be obsolete.

markus_zhang 4y ago
Just curious, porting Linux or other OS to different chip sounds like a daunting job. How do you approach the task? And I guess it's mostly about the kernel? Thanks!
- JoeAltmaier 4y ago
  A different chip is a big job. A different development board with a familiar architecture (e.g. ARM Cortex etc) is a matter of loading drivers for all the parts connected on the board. For that you create a 'device tree' which is a blob of text similar to javascript or json data definition, with many particular conventions for pins, addresses and busses. See any document on Device Tree formats e.g. from Freescale. It gets compiled into a .dtb blob which is 'device tree binary' which is flashed into the board next to the os. The bootloader or uboot image expects it in a certain place, loads it into memory and provides it to the booting kernel. Of course you need to know about the device tree, to use most devices. That's why you have to have an extra step to load - the bootloader is a flash image that has hardcoded a tiny subset of device information just for initial load. That's all I can say without launching into chapters of details!
  - Krutonium 4y ago
    Device Trees seem like such a step backwards compared to how it is on x86_64 boxes, where searching and discovering all your hardware has long since been standardized.
    - kevin_thibedeau 4y ago
      PCs have a device tree too. It's just called ACPI. Everything post PnP relies on static descriptors to discover hardware.
      - yjftsjthsd-h 4y ago
        Yeah, but those descriptors are baked into the hardware so you don't have to hard code it into the operating system
        AlotOfReading 4y ago
        Those tables are often wrong. That can cause all sorts of issues and a big reason why Linux tends to have sleep issues and why windows modern standby exists. When that happens you're either maintaining workarounds on the kernel side or patching the acpi table yourself (terrifying, see this example [1]). The hope is that the end user will eventually apply firmware updates that might not exist for months or years. With device trees, the kernel applies a patch and it rolls out with the next update. [1] https://www.reddit.com/r/XMG_gg/comments/ia9x6c/fusion15_linux_howto_patch_acpi_table_to_enable/ https://www.reddit.com/r/XMG_gg/comments/ia9x6c/fusion15_lin...
    - JoeAltmaier 4y ago
      Yeah, I guess it's to be distributed? There's no central driver repo to refer to.
    - mfuzzey 4y ago
      PCs are far more functionally standardised than embedded systems. And in fact modern PCs do use something similar to, but in fact far more complicated than, DTs - ACPI tables which not only contain static data but also callbacks to let system firmware do some of the work. Even on a PC there are still many things that are not on discoverable buses but I2C or SPI. The only reason it seems simpler on PCs is because the ACPI tables are supplied by the hardware vendor so they're mostly invisible to the end user. But that only works because they're mass produced and the variability between different manufacturers is fairly limited. Microsoft and Intel specified what the system firmware must do and enforced it through certifcations. Most PC firmware is also only tested for the case of booting Windows and Linux often emulates bugs... The same wouldn't work for embedded systems which need far more flexibility. Yes some ARM systems these days use UEFI and ACPI but that is for server hardware which is basically a PC where the x86_64 processor has been replaced by ARM and it is desired to have it otherwise work the same.
  - markus_zhang 4y ago
    Thanks. Interesting process. I guess for new chips especially of other architectures it might require a lot of rewriting of the underlying code.
  - circuit10 4y ago
    I have a calculator that uses a SuperH CPU, which is already supported by Linux, but drivers for things like the display won't be. It only has 8MB of RAM and 16MB of storage which could be restrictive. Would porting Linux to it for fun/learning be a viable thing to do as someone who knows some C and has done some low level programming, but hasn't worked on Linux before?
- davemp 4y ago
  Not OP and haven’t ported linux in a while but: Obviously some details are going to depend on the device, but it’s essentially: - set up a (cross) compiler - configure&compile the kernel - write the device tree (so the kernel knows what/where everything is) - compile the boot loader (with the device tree) - cross compile the minimum userspace for the system to function - bundle everything so you can install/flash it. Yocto [0] is what most people use to manage all those steps atm. > And I guess it's mostly about the kernel? Afaik it’s mostly writing the device tree (though it’s often provided in a board support package) and setting up the toolchain. [0]: https://www.yoctoproject.org/ https://www.yoctoproject.org/
  - markus_zhang 4y ago
    Thanks! These are all strangers to me I think, except the cross compiling part. But it's good to know some pointers and go from there.
  - markus_zhang 4y ago
    Stupid question: which jobs port Linux or other OS or other sys software for a majority of their time?
    - davemp 4y ago
      Embedded systems or firmware dev
      - markus_zhang 4y ago
        Thanks! Gonna take a look of job description and skill requirements.
- matthewfcarlson 4y ago
  Not to subtract from GP's experience, but here's a good journey of someone porting linux to an older device (Chumby) https://hackaday.com/2022/12/21/chumby-gets-new-kernel-soon/ https://hackaday.com/2022/12/21/chumby-gets-new-kernel-soon/
  - markus_zhang 4y ago
    Thanks, this looks like an interesting project. I'll probably start small and get something into my Pico (without any modification as I know some people already did this) and dev from there.
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]

markus_zhang 4y ago

Just curious, porting Linux or other OS to different chip sounds like a daunting job. How do you approach the task? And I guess it's mostly about the kernel? Thanks!

JoeAltmaier 4y ago
A different chip is a big job. A different development board with a familiar architecture (e.g. ARM Cortex etc) is a matter of loading drivers for all the parts connected on the board. For that you create a 'device tree' which is a blob of text similar to javascript or json data definition, with many particular conventions for pins, addresses and busses. See any document on Device Tree formats e.g. from Freescale. It gets compiled into a .dtb blob which is 'device tree binary' which is flashed into the board next to the os. The bootloader or uboot image expects it in a certain place, loads it into memory and provides it to the booting kernel. Of course you need to know about the device tree, to use most devices. That's why you have to have an extra step to load - the bootloader is a flash image that has hardcoded a tiny subset of device information just for initial load. That's all I can say without launching into chapters of details!
- Krutonium 4y ago
  Device Trees seem like such a step backwards compared to how it is on x86_64 boxes, where searching and discovering all your hardware has long since been standardized.
  - kevin_thibedeau 4y ago
    PCs have a device tree too. It's just called ACPI. Everything post PnP relies on static descriptors to discover hardware.
    - yjftsjthsd-h 4y ago
      Yeah, but those descriptors are baked into the hardware so you don't have to hard code it into the operating system
      - AlotOfReading 4y ago
        Those tables are often wrong. That can cause all sorts of issues and a big reason why Linux tends to have sleep issues and why windows modern standby exists. When that happens you're either maintaining workarounds on the kernel side or patching the acpi table yourself (terrifying, see this example [1]). The hope is that the end user will eventually apply firmware updates that might not exist for months or years. With device trees, the kernel applies a patch and it rolls out with the next update. [1] https://www.reddit.com/r/XMG_gg/comments/ia9x6c/fusion15_linux_howto_patch_acpi_table_to_enable/ https://www.reddit.com/r/XMG_gg/comments/ia9x6c/fusion15_lin...
  - JoeAltmaier 4y ago
    Yeah, I guess it's to be distributed? There's no central driver repo to refer to.
  - mfuzzey 4y ago
    PCs are far more functionally standardised than embedded systems. And in fact modern PCs do use something similar to, but in fact far more complicated than, DTs - ACPI tables which not only contain static data but also callbacks to let system firmware do some of the work. Even on a PC there are still many things that are not on discoverable buses but I2C or SPI. The only reason it seems simpler on PCs is because the ACPI tables are supplied by the hardware vendor so they're mostly invisible to the end user. But that only works because they're mass produced and the variability between different manufacturers is fairly limited. Microsoft and Intel specified what the system firmware must do and enforced it through certifcations. Most PC firmware is also only tested for the case of booting Windows and Linux often emulates bugs... The same wouldn't work for embedded systems which need far more flexibility. Yes some ARM systems these days use UEFI and ACPI but that is for server hardware which is basically a PC where the x86_64 processor has been replaced by ARM and it is desired to have it otherwise work the same.
- markus_zhang 4y ago
  Thanks. Interesting process. I guess for new chips especially of other architectures it might require a lot of rewriting of the underlying code.
- circuit10 4y ago
  I have a calculator that uses a SuperH CPU, which is already supported by Linux, but drivers for things like the display won't be. It only has 8MB of RAM and 16MB of storage which could be restrictive. Would porting Linux to it for fun/learning be a viable thing to do as someone who knows some C and has done some low level programming, but hasn't worked on Linux before?
davemp 4y ago
Not OP and haven’t ported linux in a while but: Obviously some details are going to depend on the device, but it’s essentially: - set up a (cross) compiler - configure&compile the kernel - write the device tree (so the kernel knows what/where everything is) - compile the boot loader (with the device tree) - cross compile the minimum userspace for the system to function - bundle everything so you can install/flash it. Yocto [0] is what most people use to manage all those steps atm. > And I guess it's mostly about the kernel? Afaik it’s mostly writing the device tree (though it’s often provided in a board support package) and setting up the toolchain. [0]: https://www.yoctoproject.org/ https://www.yoctoproject.org/
- markus_zhang 4y ago
  Thanks! These are all strangers to me I think, except the cross compiling part. But it's good to know some pointers and go from there.
- markus_zhang 4y ago
  Stupid question: which jobs port Linux or other OS or other sys software for a majority of their time?
  - davemp 4y ago
    Embedded systems or firmware dev
    - markus_zhang 4y ago
      Thanks! Gonna take a look of job description and skill requirements.
matthewfcarlson 4y ago
Not to subtract from GP's experience, but here's a good journey of someone porting linux to an older device (Chumby) https://hackaday.com/2022/12/21/chumby-gets-new-kernel-soon/ https://hackaday.com/2022/12/21/chumby-gets-new-kernel-soon/
- markus_zhang 4y ago
  Thanks, this looks like an interesting project. I'll probably start small and get something into my Pico (without any modification as I know some people already did this) and dev from there.
deleted 4y ago
[deleted]

deleted 4y ago

[deleted]