[PATCH] ramips: add support for Notion R281 (mtd5)

[Bjørn Mork]

Ian Pangilinan <ian.pangilinan at upd.edu.ph> 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