search

lueschem / edi-cl

This repository contains an edi project configuration for Compulab embedded devices.
https://www.get-edi.io
Other
10 stars 2 forks source link

Firmware update #25

Open anysomewhere opened 4 months ago

anysomewhere commented 4 months ago

Hi Matthias,

edi-cl is a huge help to build our system-images.

Context: With the newest release r3.2.1 from compulab we need to update the firmware of our devices as the new kernel won't work correctly (missing can device besides other issues). Building the new firmware is easy and it works well after flashing

Issue: It's not feasable to manually copy and flash the firmware to all our devices. Is is possible to embed the new firmware in the mender image created by edi-cl?

Thanks in advance.

lueschem commented 4 months ago

Hi

Cool that edi/edi-cl is helpful for building your OS images!

U-Boot updates are always a bit tricky and there is a (small) chance to brick the device if it gets powered off in the wrong moment. However, it is still a viable solution instead of visiting each device out there. Furthermore I would try to schedule the update of U-Boot in a good moment where there is limited likelihood of somebody removing the power supply again. After the update I would reboot the device to double check that everything is working properly.

In case you are using Mender for the OTA update I would personally ship the updated U-Boot as a separate Mender update module artifact: https://docs.mender.io/client-installation/use-an-updatemodule

In case Mender is not being used then the situation is a bit more complex. A possibility would be to include the bootloader into the image and flash it during boot. Some logic needs to be implemented that the current version of u-boot gets retrieved in order to not (re-)flash u-boot on every boot.

IMHO the Mender update module would be the more elegant approach. In a perfect world we could even make use of the fact that the hardware has two boot partitions (/dev/mmcblk2boot0 and /dev/mmcblk2boot1) in order to make it more fail safe. Are you using Mender?

anysomewhere commented 4 months ago

Yes, we are using mender. Shipping the updated U-Boot as a seperate Mender update is for sure a possible solution. We then have a loose dependency between the new kernel and the new firmware as the new kernel only fully works with the new kernel.

Thank you for the hint with the mender update module. I will write a module to update the firmware as safely as possible. Then we will see how that goes.

anysomewhere commented 6 days ago

After some tweaking I got the firmware update working. My new problem is that after a mender update the partitions are not switched. Is there a way how I can check if your shim is still working?

lueschem commented 6 days ago

Hi

The best way to observe the early boot process is to use a serial console. Furthermore you can also print the U-Boot environment using the tool fw_printenv. Mender basically interacts with U-Boot via the U-Boot environment via changing some variables there (see also here). The counterpart of Mender in our case is this script. Now depending on the update module setup this partition switching will happen or not. So if the bootloader has its own update module then the partition switch will not be needed. If you however combine the rootfs together with the bootloader into one update module then you need to use an update module that switches the partition. Mender 4 uses the rootfs-image module that could be used as a starting point.

Having said all this, I hope that the issue is not due to the new bootloader. Anyway - I am going to upgrade my bootloader as soon as I find time.