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

[Andre Valentin]

Hi !


Am 15.05.21 um 18:08 schrieb Bjørn Mork:
> [ 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?
It is!
>  
> 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.

Didn't notice that. Funny.
> 
> 
> 
Please let us talk about the flash layout:

Original:
                partition at 0 {
                        label = "uboot";
                        reg = <0x00000 0x80000>; /* 64 KB */
                };
                partition at 80000 {
                        label = "uboot_env";
                        reg = <0x80000 0x80000>; /* 64 KB */
                };
                factory: partition at 100000 {
                        label = "factory";
                        reg = <0x100000 0x40000>;
                };
                partition at 140000 {
                        label = "Kernel";
                        reg = <0x140000 0x1ec0000>;
                };
                partition at 2140000 {
                        label = "Kernel2";
                        reg = <0x2140000 0x1ec0000>;
                };
                partition at 4000000 {
                        label = "wwan";
                        reg = <0x4000000 0x100000>;
                };

                partition at 4100000 {
                        label = "data";
                        reg = <0x4100000 0x1000000>;
                };
                partition at 5100000 {
                        label = "rom-d";
                        reg = <0x5100000 0x100000>;
                };
                partition at 5200000 {
                        label = "reserve";
                        reg = <0x5200000 0x80000>;
                };


| uboot | uboot_env | factory | Kernel | Kernel 2 | wwan | data | rom.d | reserve

There are gaps between the partitions. I can only imagine that this is because of bad block handling in the bootloader.
It seems it uses the end of the flash for reserve and also has holes betwee partitions for this.

Manufacturer implementation:
He uses an initramfs image which is stored on Kernel and on Kernel2. Data is stored on data partition.

1st implementation by Björn:
Kernel partition is used for kernel, ubi (rootfs, rootfs_data)
-ubi image has to be uploaded separateley.
-installation via initramfs image needed
-sysupgrade working

2nd implemtation:
Kernel partition is used for kernel, rootfs and ubi (rootfs_data)
-rootfs is always included
-not initramfs installation needed.
-sysupgraded working

I would prefer the 2nd solution, because it give us a working system after the initial flash.

Modifications needed for 2nd implementation:
-mtdsplit_squashfs.c
-device specific upgrade flow

Bootup processes with 2nd implementation:
The image has been flashed with the bootloader.
1. Device boots up kernel.
2. mtdsplit_uimage.c splits the image into parition kernel and rootfs
3. mtdsplit_squashfs.c splits the rootfs parition into rootfs and ubi (see patch)
4. ubi is initialized and formated if needed
5. system is up

What do you think? Use first or second implementation?


Kind regards,

André

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210517/0496af14/attachment-0001.sig>