Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
mediatek: Fix U-Boot variables handling for D-Link M30 A1
I think I implemented the U-Boot handling incorrectly on M30 (saw the issue while porting M60 to OpenWrt). Maybe someone with more U-Boot experience can have a look at it. What I understood until now: Before flashing, `sw_tryactive` must be set to 0 because OpenWrt runs on partition 0 During reset after flashing, U-Boot executes the following line: `boot_rd_auto_sw_img=if itest.s ${sw_tryactive} == 2; then run boot_by_part; else run boot_by_tryactive; fi` As `sw_tryactive` was set to 0 before flashing, `boot_by_tryactive` will be executed: `boot_by_tryactive=if itest.s ${sw_tryactive} == 0; then setenv sw_tryactive 2; setenv sw_active 1; saveenv; run ub0; else setenv sw_tryactive 2; setenv sw_active 2; saveenv; run ub1; fi` As `sw_tryactive` was set to 0 before flashing, `sw_active` will be set to 1 and `ub0` will be executed: `ub0=setenv bootpart 0; mtkboardboot; run ub0to1; uip main; reset` If the OpenWrt boot is successful, `ub0to1` and `uip` main will never be executed. Only in case OpenWrt cannot be loaded, `mtkboardboot` will return and the fallback `ub0to1` is executed. Conclusion: It's sufficient to set `sw_tryacitve` to 0 before flashing, the added code in `target/linux/mediatek/filogic/base-files/etc/init.d/bootcount` is useless. In the worst case (/proc/cmdline doesn't contain `bootpart=ubi0` as expected), the bootpart variable would be set to 1 and causes starting the firmware from the second partition instead of the one on the first partition. Signed-off-by: Roland Reinl <[email protected]> Link: openwrt/openwrt#17298 Signed-off-by: Hauke Mehrtens <[email protected]>
- Loading branch information