Closed humanoid2050 closed 3 years ago
I believe that may have been a bug at the time that was fixed later. Normally updating U-Boot happens at the same time as updating env. But you can also fix env later in a manner as here: https://edison-fw.github.io/meta-intel-edison/6.4-Installing-an-updated-U-Boot.html#install-updated-u-boot-env-over-the-air-ota
Hmmm... Looks like I'm just bad at reading documentation. Perhaps an additional reminder in the section https://edison-fw.github.io/meta-intel-edison/2.6-Building-Debian.html#optional-optimizing-of-disk-partitions-for-emmc-installations that some changes will need to be reflected in the U-Boot env would be helpful.
I haven't reread each page with each update, so you may well find inconsistencies.
I previously got my Edison running from the zeus branch. More specifically, I was using the Debian image with a modified file system as described on this document: https://edison-fw.github.io/meta-intel-edison/2.6-Building-Debian.html. I had removed the update and home partitions from the mmc, grown the root fs to the full mmc, and moved home to the sd card.
Today I thought I would upgrade to dunfell.
Apparently, uboot will refuse to go into dfu mode if the file system does not match what it expects
Digging into the uboot env shows that the update and home partitions are directly coded into the methods that populate dfu_alt_info.
do_dfu_alt_info_mmc=setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0 part 0 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0 4;boot part 0 7;rootfs part 0 8;update part 0 9;home part 0 10;bzImage fat 0 7;initrd fat 0 7"
I don't know if there is a great solution for handling this in an automated way, but I figured it would be worthwhile to document the edge case.