Ian Pangilinan <[email protected]> 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 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. > 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 guess they forgot that this is a CPE, where the C stands for consumer. "customer", I believe :-) > 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 _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
