[PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus

Bjørn Mork bjorn at mork.no
Sat May 15 09:08:00 PDT 2021


[ answering some comments which also apply to the NR7101 ]

"Adrian Schmutzler" <mail at adrianschmutzler.de> writes:

>> +		partition at 140000 {
>> +			label = "Kernel";
>> +			reg = <0x140000 0x1ec0000>;
>> +		};
>
> "ubi" is part of kernel?

The operator specific firmware I have for the NR7101 does not use any
rootfs partition at all.  The stock images are huge initramfs
images. Any retained config is stored separately as a json blob in the
ubifs formatted "data" partition.

I assume the same is true for the LTE3301-Plus?
 
The writable "data" partition isn't suitable for a rootfs IMHO.  It's
tiny, and it's already full of stock/operator specific data which we
want to retain in case of a revert to stock.

So I split out part of the "Kernel" partition for our rootfs..

I still kept the original "Kernel" partition intact so that it is
possible to revert to stock without having to jump trough hoops.  The
stock images are much, much larger than we want to reserve for the
kernel, Typically 14-15 MB.

>> +
>> +		partition at 540000 {
>> +			label = "ubi";
>> +			reg = <0x540000 0x1ac0000>;
>> +		};
>> +
>> +		partition at 2140000 {
>> +			label = "Kernel2";
>> +			reg = <0x2140000 0x1ec0000>;
>> +		};
>
> What's in 0x2000000 to 0x2140000? Or did I miscalculate?

No you didn't.  This is a hole in the stock firmware.  I was a bit
unsure what to do about it. I left it alone to maintain the 1-to-1
mapping with bootloader and stock firmware partitions, not wanting to
risk that either secretly used the hole for something.

Funny thing is that there was a JFFS2 file system with UCI config files
at 0x2100000 on the NR7101.  This was not mapped as a partition by the
stock firmware, and obviously not mounted.  The contents was quite
useful as it contained a file with gpio mappings among other stuff.
Which was another reason I decided not to take this hole in use - the
factory data in there could be useful.




Bjørn



More information about the openwrt-devel mailing list