If you have a usb dongle for SD cards...?
You can pull parts off an image... as so..
zcat someimage.xz |dd of=1st-16.img bs=1M count=16
check mbr on SD card and 1st-16.img, the SD card may have been altered by expandfs
Most xterms can have tabs, so you can have 2 instances of fdisk open, each in own tab
(you alter partition table by deleting and then making a partition. this ONLY alters part table)
Manjaro does not automatically update uboot, the update dumps the files in /boot,,,
then you do a dd operation.. So you don't have to 'pin' uboot version
There is not that much info about uboot that is usefull, much is old and obsolete,
much is confusing
Uboot is ONLY a loader, so there are 2 boots, uboot 1st, then the OS
the cpu has very little ram and a fixed search order for idbloader, which enumerates and activates mb ram
Then uboot can load and always? alter search order, searchs for config file (boot.scr, extlinux.conf, aarch64.efi)
uboot has a rather limited internel dtb, which is how it knows where everything is located
You can pull parts off an image... as so..
zcat someimage.xz |dd of=1st-16.img bs=1M count=16
check mbr on SD card and 1st-16.img, the SD card may have been altered by expandfs
Most xterms can have tabs, so you can have 2 instances of fdisk open, each in own tab
(you alter partition table by deleting and then making a partition. this ONLY alters part table)
Manjaro does not automatically update uboot, the update dumps the files in /boot,,,
then you do a dd operation.. So you don't have to 'pin' uboot version
There is not that much info about uboot that is usefull, much is old and obsolete,
much is confusing
Uboot is ONLY a loader, so there are 2 boots, uboot 1st, then the OS
the cpu has very little ram and a fixed search order for idbloader, which enumerates and activates mb ram
Then uboot can load and always? alter search order, searchs for config file (boot.scr, extlinux.conf, aarch64.efi)
uboot has a rather limited internel dtb, which is how it knows where everything is located