[EV3] [Feature] Either properly support, or else remove, use of u-boot

[ArcaneNibble]

The current WIP EV3 bare-metal port loads via u-boot even though it does not use Linux, devicetree, or really any features that u-boot actually adds. The copy of u-boot used appears to a checked-in binary blob built from an unclean working tree (U-Boot 2019.07-00224-gb10c65ef79-dirty (Nov 12 2024 - 15:19:12 +0100))

Can we remove this extra step and boot the MicroPython image directly (incidentally removing the need for u-boot-tools during the build process)? If not, perhaps because we want to support easy swapping to ev3dev, this should be mentioned in developer documentation, and the origin of the u-boot binary should be made clear.

[laurensvalk]

Thanks for opening this one. Yes, this needs to be looked at.

Indeed, ev3dev compatibility is one of the main reasons to potentially keep u-boot. The other reason is that the EEPROM bootloader only loads up to 256 KB of firmware size. When our firmware gets larger (for other hubs, it is there or thereabouts, so this is likely), we'd need to add some kind of loader even if it isn't u-boot.

Which brings us to the reason why it is currently a custom version. The original LEGO version of u-boot loads the entire 16MB into RAM, which takes about 4 extra seconds. I would rather only load as much as we need. Right now it is loading a fixed, smaller amount, but it could look at the uImage header to figure out the size.

But the very latest upstream version of u-boot is bigger than 256KB, which is bigger than the EEPROM will load, so this custom version is just the version that introduced upstream EV3 support.

tl;dr: It is an experimental solution and we still need to figure out what we want :)

[dlech]

As I just mentioned in #2247 (comment), I think keeping u-boot could be advantageous, if for nothing else, to save us from having to write our own SPI Flash driver.

It would be super-simple to modify the u-boot script to load as little or as much flash memory as we need. Also, I suspect that u-boot doesn't use DMA for this currently, but it has an EDMA driver already, so we could probably add support pretty easy. And the code quality is going to be much better that the TI starterware.

[laurensvalk]

@dlech, do you think we can disable enough things in u-boot to get a modern upstream release down to 256KB?

[dlech]

Having a look right now 😄

[laurensvalk]

Thanks!

And even though we could load user data with u-boot as well as you've mentioned, I would perhaps restrict it to load just the firmware binary. (Perhaps with the u-boot script reading the 4 size bytes from the uImage to find out how much is needed.)

We can load user data asynchronously with #2247, allowing devices such as LEGO sensors to initialize at the same time rather than waiting for it. This should save even more time, and we'll need most of that code on shutdown anyway. We also don't have to mix in Pybricks user data formats with u-boot that way, and just keep things simple.

[dlech]

I just pushed a new pybricks-ev3 branch to https://github.com/pybricks/u-boot, so we can use that as the "official" source. It is based on the current master u-boot branch with a patch to reduce the size and a patch to handle booting a Pybricks firmware blob.

And we can publish a u-boot.bin using GitHub releases there so that we aren't committing binary blobs to git. (And we should remove https://github.com/pybricks/pybricks-micropython/blob/master/bricks/ev3/u-boot.bin).

[dlech]

And here is the release: https://github.com/pybricks/u-boot/releases/tag/pybricks%2Fv1.0.0

[dlech]

I just merged pybricks/pybricks-micropython#315 which improves the u-boot situation a bit.

There was an issue with using the wrong entry point address in the uImage, so that could explain why certain firmware builds would boot and some wouldn't. It just depended on getting lucky enough that the linker didn't put much between the start address and the entry point address.

If we want to drop using u-boot-tools and the uImage, we could use the bootelf command instead of bootm. We would want to strip the .elf file to get it down close to the uImage size, but that could take out a few steps of the build process.