Problem Led support for Iconnect device

[igorert]

$this->bbcode_second_pass_quote('WarheadsSE', 'D')oes the iConnect's uboot support scripting at all? because it would not be that hard to say:
a) If USB found & labeled "rootfs", set archNumber=YYYY, boot from usb.
b) no "rootfs" found on usb, set archNumber=XXXX, boot from NAND (or whatever)

[WarheadsSE]

My guess:
arcNumber is passed as a kernel argument, or checked later? If it is a kernel argument (I think it is) then it's as simple as updating bootargs, and booting, no save necessary.

[kmihelich]

arcNumber is passed immediately at kernel start, it's what identifies which board file to use for device initialization. I imagine the u-boot on the devices has the same basic logic capabilities as the versions we use in the other devices. Could probably do something along the lines of:

if ext2load usb 0:1 0x800000 /boot/uImage; then setenv arcNumber 2870; bootm 0x800000; else setenv arcNumber 1682; <insert nand boot stuff>; fi;

[igorert]

Hey, I'm not theorizing, I've actually tried this Changes to arcNumber have no effect until you saveenv and reboot.

If you'd like the gory details: machine id (i.e., arcNumber) is not a kernel command line parameter so it can't be passed through bootargs; instead, it's a separate parameter to the kernel entry point function. If you look at uboot git source, you'll see that the code populates kernel command line from bootargs during the kernel boot process but sets machine id based on bi_arch_number field of a certain structure, which is populated when u-boot is loaded, not when control is about to be passed to the kernel. The git uboot code actually does allow overwriting that value with machid uboot variable but, alas, that part is not present in Marvell's uboot that is shipped on iconnect.

[WarheadsSE]

Ah, we weren't sure which uboot you were using