Usb dual partition firmware - uboot

developing a dual firmware from usb...

NOTE: it is removable... so when you unplug... 99.9% vanishes and normal router operations are not effected.

There are some really cool benefits like;

  1. developing lowlevel scripts on removable media...
  2. switching releases by switching drives...
  3. massive reduction on router wear and tear
  4. oem flash dumps and restores made easy

starting out with arm / uboot with ext2load...

Deal with now;

Gather other device usb bootcmds and related info
# none known
# make a post with your info if you know / have tested it... or just the fw_printenv ( minus macs or serials ) -> ipq806x for now unless someone gifted is super keen on that end...

i.e.;

To support a board:

	Much of this info is available online but to be sure... serial access would be prefferable.

	all boards)

		-ext2load or what your uboot supports
		-check whether enabling bootloader ATAG passing will break boot ( may need serial or alternate recovery skills and methods )
		-your bootloader loadaddr/bootcmd/defaults ( info re: limits on kernels over 5~MB - memory availablity overlap )
		-your bootloader usb init command/s
		-does / can your bootloader auto reset its environment
		-does any of its other functions ( disk init ) interfere with device labels or initialisation ( nousb3,mmc2 etc )

	ipq806x) stop here

		-buildroot ATAG/bootloader cmdline kernel option/s ( can help with this )



Partition layout... what is optimal?

this is what I currently have

1 -> ext2 "boot"
2 -> ext2 "scratchbackup/restore.tar.gz archive etc"
3 -> rootfs (now ext4)
4 -> swap (optional)
Rootfs format issue re: squashfs/overlays/etc

( ext4 for now... but would like to support others with pure extroot... no /overlay )... i'm wondering if a spare partition or two for "dynamic/per-install overlay" functionality might be wise...

PARTUUID and not LABEL....?

i'd possibly contribute to LABEL "upstream" code as it would greatly simplify ubootvar<>bootcmd's.... the LABELs are used within my buildroot / pc scripts to mount / format / copy / interact with the USBstick... they are

1 wrtboot
2 wrtsnapback
3 wrtrootfs
Deal with later
  1. uboot variable names ( bootalt=0/1 usbrootfsalt=/dev/sda3 etc. etc. )
  2. kernel name: kernel1+kernel2 / kernel+kernelalt etc
  3. Should it flash the alternate partition always? Would a switch to specify current or alt be of use?

Naming samples... ( all oem? )

target/linux/ramips/mt7621/.../platform.sh alfa-network,quad-e4g) dual_image -> "1" bootactive 1|2"

( will likely be scalable to other "loadcmds" / rootfs formats )

2 Likes

From the original post...

notes regarding existing targets and ext4 operations or alternatives

I now have sysupgrade working on usb... so scaling to mmc i'm more confident now with the caveats that it's a purely copy based method... and no re-formatting takes place...
I need any info regarding example targets that might use ext2/boot ext4/rootfs on internal... mmc.

assuming reformatting was not an option to co-exist with existing OEM files...

  1. do any methods/targets/solutions exist for such situations?**

  2. what targets use similar routines? ( which one would be best to use as a base? )

( edit: adding notes )

mvebu -> uDPU(and others) ( advanced emmc operations )
tegra -> mybook-live ( "disk" and bootpart / rootpart functions )
imx6|x86|apm821xx ( also reference /boot tba )
ipq806x>nbg6817 ( interesting loop operations )
rPI|other-"intree-devboards" ( tba )

( yet to investigate firstboot operation in the above )
also of interest... NoTengoBattery 's bin/BackToStock and related method/s specifically due to firstboot handling...

seems like uDPU is closest... due to "misc" ... and my "part 1" may have size constraints ....

Any 3rd party projects or technical docs regarding uboot LABELS/UUID's and fancy partition methods

lexa2 bpi-r2 custom-settings-restore and some-uboot-logic

It's a bit hard to understand what you wrote... sorry but I'm not a native speaker.
Anyway, just a hint: Linux (it doesn't matter if it's OpenWrt because they use an "almost stock" kernel) does support booting by label. A special initrd is requiered to actually find the real root by LABEL/UUID, but block-mount (the responsible of the extroot/overlay) can find drives by LABEL, so in theory it must be trivial to support.

1 Like

Just a little question: where can one download your prebuilt? I'm thinking about trying in a virtual machine.

Also: any plans to support EFI?

  • only rt2600ac has support... ( only device tested bootcmd's are known )

  • messed around a little with UEFI... ( pending answers to earlier questions / input ) merry x-mas @jeff

( p.s. doubt the above will function... but a quick scan of it is enough to give you a feel for the basic building blocks )