[LEDE-DEV] Mikrotik RB411AH sysupgrade issues

[Sergey Ryazanov]

On Wed, Feb 22, 2017 at 11:41 AM, Felix Fietkau <nbd at nbd.name> wrote:
> On 2017-02-21 23:10, Sergey Ryazanov wrote:
>> Hello,
>>
>> I tried to install latest LEDE to RB411AH board. Sysupgrade worked
>> fine, but device now do not boot at all. Bootloader claims that it
>> could not find kernel :(
>>
>> I tracked down the situation and found that the kernel partition image
>> generated with assumption that any 64Mb NAND flash IC consists of
>> pages, the size of which is 512 bytes with an 8-byte spare area. But
>> my board equipped with Toshiba NAND flash, which consists of pages,
>> the size of which is 2048 bytes with an 64-byte spare area.
>>
>> Even worse, after such reflashing with the corruption of the page
>> structure, kernel starts thinking that pages are bad and they could
>> not be used anymore. So I had to install vendor's firmware back with
>> help of vendor utility to recover pages structure.
>>
>> To fix this I see several solutions:
>>
>> 1. Generate more images, one for each combination of flash and page
>> sizes (e.g. xxx-64m-512-sysupgrade.bin, xxxx-64m-2048-sysupgrade.bin)
>> Pros: quick realization, no sysupgrade code modification
>> Cons: exponential growth of number of images, unusable due to endless
>> mess with this set of images.
>>
>> 2. Inclusion of multiple kernel partition images to one firmware image
>> for sysupgrade (e.g. xxx-64m-sysupgrade.bin will contain
>> kernel-512.bin, kernel-2048.bin, etc.).
>> Pros: there are no mess with set of images
>> Cons: useless growth of sysupgrade image
>>
>> 3. Create utility, which will generate yaffs image on the fly during flashing
>> Pros: avoid mount operation during flashing procedure
>> Cons: a lot of work, rootfs growth
>>
>> 4. Return the YAFFS support back to the kernel, place kernel as
>> regular file to sysupgrade image, mount kernel partition during
>> sysupgrade, just copy kernel there and let YAFFS driver do its work.
>> Pros: quite universal solution, ability to access yaffs partitions at any time
>> Cons: small kernel growth, incompatible sysupgrade code modification,
>> mounting of the partition during flashing
>>
>> Personally I like last solution, and if there are no objection then I
>> will prepare patches in few days.
>
> I prefer option 2. Option 4 gets a NACK from me - we're working hard on
> reducing our non-upstream kernel code, so adding back the ugly YAFFS
> kernel patch mess would be a huge step backwards.

Ok. Could we discuss your NACK? Don't you like YAFFS just because it
is a non-upstream code or you do not like YAFFS as a file system?

In first case I would like to note that this code is perfectly
isolated and it requires minimal maintaining. It is only require few
patches in order to integrate it to the kernel build process while the
main filesystem code remain as a set of files. I dig through yaffs
commit history and found that this code was changed only few times per
year in the past.

On the other hand since the device in subject is still on market we
could start yaffs upstreaming process and switch to upstream version
in the future.

-- 
Sergey