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

[Andre Valentin]

Hi!

Am 17.05.21 um 12:54 schrieb Bjørn Mork:
> Andre Valentin <avalentin at marcant.net> writes:
> 
>> 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.
> 
> Yes, that makes sense.
> 
> 
>> 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?
> 
> I don't think we can move the ubi partition around.  It needs to
> preserve the wear levelling metadata, or it becomes pointless.  And I
> don't think we want a writable rootfs without wear levelling.

Perhaps you misunterstood me, rootfs is always concatenated to the kernel.
The free space after the rootfs will be used for the UBI partition and only rootfs_data.
You're right, metadata will be lost. But is it so important?
> 
> We could have used the first part of your idea, havinng a dynamic split
> between kernel and the read-only rootfs, with a fixed ubi rootfs_data
> partition.  But it would be hard to place that fixed split to suit
> everyone.  The total size to play with isn't that much, with the
> recovery image abusing half the flash.  So we would end up with a rootfs
> and a rootfs_data which are both too small to be useful.

Absolutely!
> 
> There are also some other possible schemes taking advantage of the flash
> reserved for the recovery image.  But they will add some risk of the
> bootloader messing up the rootfs, which I don't think we should expose
> unsuspecting users to.  It's more like something we can do for our own
> personal images.

I tried that before. UBI on the space after rom partition. But after weeks of usage, I got funny errors (xz cannot decompress).
ubi never showed any errors in that case.. And I leaf at least 4 eraseblocks free at the end.
> 
> All in all, the current scheme was the best I could come up with.
> 
> It would still be possible to do a one-step initial install by creating
> a "factory" image with kernel+rootfs concatenated, like we do for many
> devices.  In fact, I created such an image at first.  And dropped it
> after it softbricked my test device, due to a bad block in the beginning
> of the "Kernel" partition. This caused the "ubi" data to end up at
> unexpected offset, and therefore not found where the kernel was looking
> for it.
Damn, correct. That could happen. I haven't testet it.
> 
> This is not a problem specific to these devices though.  But I think
> that users are better served by clear two-step installation instructions
> than a one-step solution known to brick some devices.
> 
> The NR7101 is the first device I've bought with a bad block in such an
> "unlucky" spot.  It's obviously not common. Still not something we can
> just disregard.
> 

I think the best way would be if we had an initramfs which is able to save config on a separate filesystem.
But it wouldn't be supported be the imagebuilder and needs more work.

Not easy..

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/674f2dfd/attachment.sig>