OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version openwrt-18.06
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Adolf Berthold - 14.08.2018

FS#1778 - release 18.06 does not work for recent RouterBoard 450G (ar71xx/mikrotik)

OpenWrt 18.06. does not work on at least some RB45Gs, because the yaffs2-Image for the kernel in


seems to be created with a pagesize of 2048, but my recent RB450G contains a NAND-Chip with a pagesize of 4096 (as displayed by the linux-kernel). Flashing this image onto this chip with “nandwrite -o”, inside function platform_nand_pre_upgrade() in file target/linux/ar71xx/base-files/lib/upgrade/, screws up oop-data and renders the kernel-nand-partition unbootable, unreadable, unwritable and even unerasable (at least with “mtd erase”).

See attached File cap1.txt for an installation log. The Installation seemed to work just fine, but the device did not bool any more.
See attached File cap2.txt for a log of a netboot-session after that. The kernel showed up 6 new “Bad eraseblock”s and “mtd erase” did not work any more.
After restoring Mikrotik’s RouterOS to the device with their NetInstall-Application, the “bad eraseblock”s were gone, which prooves, that the NAND-Chip is not really defective and the “Bad eraseblock” are erroneous.

There seem to be RouterBoards with different NAND-Chips around: This page:

states that it is a “Hynix HY27UT084G2A”, but the Linux-Kernel states that
the Chip is from Toshiba. Hence the sysupgrade-procedure should probably prepared
for different yaffs2-page-sizes.


After quite some time, I figures out the following workaround:

  1. Netboot OpenWrt 18-06.
  2. Open the file /lib/upgrade/ with vi and comment out the nandwrite-call in line 760.
  3. Call sysupgrade as usual –> The Installation will not be bootable, but the kernel-Partition will still be accessable
  4. Netboot OpenWrt 14.07 (because v18.06 lacks yaffs2-kernel-support !)
  5. Manually install the kernel-file with:
mtd erase /dev/mtd5
mkdir /mnt/kernel
mount -t yaffs2 /dev/mtdblock5 /mnt/kernel
cd /mnt/kernel
wget -O kernel
chmod +x kernel
cd /
umount /mnt/kernel

With this procedure I got a working installation.

   cap1.txt (228.6 KiB)
   cap2.txt (11.7 KiB)
Project Manager
Christian Lamparter commented on 25.10.2018 21:52

This could be a duplicate of  FS#1830  (or the other way round?)

Anyway, the issue found it's way to the mailing-list: [OpenWrt-Devel] [PATCH] kernel: tolerate using UBI/UBIFS on MLC flash (FS#1830)

And the openwrt developer Koen Vandeputte has issued an request for serial numbers of affected RouterBoards.

Adolf Berthold commented on 29.10.2018 14:11

No, this isn't ...

 FS#1830  is about MLC-Chips. My Flash-Chip is SLC, is perfectly supported by the
Kernel and just has a differend page size.

For further clarification, I here describe the chain of causation :

1. The Mikrotik-Bootloader (called "RouterBoot") needs a YAFFS2-Partition to load
the kernel from.
2. The sysupgrade-procedure of OpenWRT 18.06 employs a premade YAFFS2-image
that gets flashed to the chip.
3. YAFFS2-Partitions vitally depend on the chip's page size.
4. The page size of the premade kernel-YAFFS2-Image is fixed at build-time.
5. If this build-time-fixed page size does not exactily match the actual chip's page size,
then installation (of the kernel, not the rootfs) fails.

As there seem to be different chips with different page sizes around, the best solution
would probably be, not to flash a prebuild filesystem-image for the kernel, but to add
YAFFS2-kernel-Support and write the kernel file with "mount; cp; umount".


Available keyboard shortcuts


Task Details

Task Editing