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

[Ian Pangilinan]

> 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