[LEDE-DEV] Mikrotik RB411AH sysupgrade issues

Felix Fietkau nbd at nbd.name
Wed Feb 22 00:41:32 PST 2017

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.

- Felix

More information about the Lede-dev mailing list