| ▲ | zzzoom 2 days ago | |
If the image contains information required to bring up the device, why isn't that data shipped in firmware? | ||
| ▲ | parl_match 2 days ago | parent | next [-] | |
> If the image contains information required to bring up the device, why isn't that data shipped in firmware? the firmware is usually an extremely minimal set of boot routines loaded on the SOC package itself. to save space and cost, their goal is to jump to an external program. so, many reasons - firmware is less modular, meaning you cant ship hardware variants without also shipping firmware updates (the boot blob contains the device tree). also raises cost (see next) - requires flash, which adds to BOM. intended designs of these ultra low cost SOCs would simply ship a single emmc (which the SD card replaces) - no guaranteed input device for interactive setup. they'd have to make ui variants, including for weird embedded devices (such as a transit kiosk). and who is that for? a technician who would just reimage the device anyways? - firmware updates in the field add more complexity. these are often low service or automatic service devices anyways if you're shipping a highly margin sensitive, mass market device (such as a set top box, which a lot of these chipsets were designed for), the product is not only the SOC but the board reference design. when you buy a pi-style product, you're usually missing out on a huge amount of normally-included ecosystem. that means that you can get a SBC for cheap using mass produced merchant silicon, but the consumer experience is sub-par. after all, this wasn't designed for your use case :) | ||
| ▲ | orangeboats 2 days ago | parent | prev [-] | |
In some cases the built-in firmware is very barebones, just enough to get U-boot to load up and do the rest of the job. | ||