> On 2022-07-25 15:21, Bjørn Mork wrote: > Ian Pangilinan writes: > >> Here's the contents of the u-boot-env as a fw_printenv output: >> >> bootcmd=tftp > > This is odd. Might indicate that U-Boot doesn't use these settings at > all? > >> baudrate=57600 >> ethaddr="00:AA:BB:CC:DD:10" >> BootType=3 > > But that's probably overriding the bootcmd - booting from flash by > default. > >> uboot_ver=V1.1 >> PCB_SN=<snip> >> SN=<snip> >> dropbear_password=75912917 >> dropbear_mode=0 >> dropbear_key_type=0 >> bootargs=console=ttyS1,57600n8 root=/dev/mtdblock6 >
We can only guess what black magic goes on for devices such as these where the bootloader is modified by the vendor, per request of the ISP being their customer. > This is sort of interesting since that root partition is dynamically > split out of the firmware partition. I assume it would be > /dev/mtdblock5 if you booted from the first image. But I don't think > it's likely that U-Boot uses this as imput. It's rather something > that's set by U-Boot depending on which image it decides to boot. The layout is fixed afaict, depending on whether the bootloader is coded to load at mtd4 or mtd5. In the mtd4 variant, I can make an educated guess that it looks like this: ALL Bootloader Config Factory firmware1 rootfs rootfs_data firmware2 ota Configbak So it will have bootargs=console=ttyS1,57600n8 root=/dev/mtdblock5. That other firmware partition really is only there as a standby/backup copy. > >> wifi_ate=on >> rootfs_data_ofs=0x3180000 >> rootfs_data_size=0x01d40000 >> rootfs_data_fail=0 >> IMEI=<snip> >> stdin=serial >> stdout=serial >> stderr=serial >> filesize=651338 >> fileaddr=84000000 >> ipaddr=10.10.10.123 >> serverip=10.10.10.3 >> autostart=no >> bootfile=test.bin >> bootdelay=3 >> >> It may look like a dual-partition scheme on the outside, but the other >> partition merely serves as backup to the main partition where the >> bootloader >> is hardcoded, it seems, to load. This is an ISP-branded device that is >> actively being updated to thwart consumer modifications. And just >> recently >> they went beyond regular system updates and released a bootloader >> update >> that >> effectively disables tftpboot. > > Ah, OK. So they do modify the bootloader too. Then I guess anything > is > possible. > > I've seen ISP-branded devices seemingly ignoring one of the dual > partitions, using the other image purely as an emergency backup. The > ZyXEL NR7101 used to be like this. But that was only because the ISP > firmware never modified the BootingFlag variable. This changed with an > update, but without changing U-Boot. It was already looking at the > variable. > I was hoping that they used a variable to tell which flash address to load, but it no longer looks that way if you consider the two different partition layouts of the same hardware, thus two different bootloader images with hardcoded values for each layout. >> I guess they forgot that this is a CPE, where the C stands for >> consumer. > > "customer", I believe :-) > Haha, yes good catch. :D >> I >> have tried setting load_firmware_addr=0xbc140000 but this did not >> change >> anything. The variable was taken from another device, a Cat.4 LTE R051 >> from the same vendor. I thought it could work, but it didn't. > > Maybe run "strings" on the U-Boot partition (or a copy of it) to see if > any interesting variable names show up? > > >> Here's the >> serial console log from the stock firmware, in case you could find >> something: >> https://pastebin.com/etEUiphL > > Thanks. I see that you got no hints there. But that's not unusual. > There could still be a magic variable controlling which image to load. > Even one that doesn't show up in the current settings, making U-Boot > fall back to a default value. > > > > Bjørn > Yes I have tried to strings /dev/mtd0, but I didn't see anything that could give hint. Maybe I missed it, so here it is. Another set of eyes is better than one. https://pastebin.com/uDcUyvNc -ianp _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
