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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev