I'm kind new to OpenWRT internals, used it for a long time for occasional tasks, but didn't had an opportunity to dive deeper into internals. And I've recently got my order with BPI-R4 + BE14000 WiFi 7 board (from Sinovoip). I know support for 802.11be are kinda experimental as for now so I don't expecting much right away. But what I was thinking of is having a way to quickly test boot all those new build & forks with patches coming up frequently for these boards. Without flashing NAND/eMMC or writing images to external microSDs.
I have a TTL adapter attached to it but it's installed in "hard to reach" place. So the TTL are connected to another device close to it. I've also connected RESET to GPIO of that device and can "press" that button remotely.
The thing is so far I've learned how to boot "recovery" images from ram via uboot. Basically I just need some storage with image and then I can do things like usb start if required image are on the USB mass storage, then ls mmc/usb <DEV:PART> <PATH> to list files, load them to RAM with load mmc <DEV:PART> $loadaddr <PATH> or usbboot $loadaddr <DEV:PART> and then run that firmware with bootm $loadaddr.
That works for FIT images - recovery or sysupgrade so far. But even if I burn sdcard image to a USB stick it won't boot with usbboot $loadaddr 0:0 or 0:1 as it seems to expect same FIT image on the partition.
Is there are any way to make it work with "flat" images, suitable for sd card burning? Like the vendor firmware images or "sdcard" type images? Currently looking a way to boot sdcard images from USB storage, because that's a remote virtual device I can use. Tested it with real USB drive - same result.
Any way to chainload another uboot (I guess it's BL33?) from another one or this isn't possible due to ATF secure boot things?
EDIT: I know I can also boot via TFTP/network or even serial "modem" file transfer, but it's just my setup to have it preferably loaded from USB storage. Dont' changes things for my questions anyways I guess.
Not that I'm looking for anyways. Their bootloader totally lacks any filesystem functions unfortunately. But they got more advanced functions for NAND, especially that nmbm command. Hopefully those could be ported to the openwrt uboot, because it's way more advanced in features and allows booting, reading, writing and verifying raw flash with much more flexibility. Except for some of partition/internal storage handling, probably specific to MTK layout.
