You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenWrt 18.06. does not work on at least some RB45Gs, because the yaffs2-Image for the kernel in openwrt-18.06.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin 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/platform.sh, 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.
====Workaround:====
After quite some time, I figures out the following workaround:
Netboot OpenWrt 18-06.
Open the file /lib/upgrade/platform.sh with vi and comment out the nandwrite-call in line 760.
Call sysupgrade as usual --> The Installation will not be bootable, but the kernel-Partition will still be accessable
This could be a duplicate of FS#1830 (or the other way round?)
Anyway, the issue found it's way to the mailing-list: [[http://lists.infradead.org/pipermail/openwrt-devel/2018-October/014324.html|[OpenWrt-Devel] [PATCH] kernel: tolerate using UBI/UBIFS on MLC flash (FS#1830)]]
And the openwrt developer Koen Vandeputte has issued an [[http://lists.infradead.org/pipermail/openwrt-devel/2018-October/014411.html
|request for serial numbers of affected RouterBoards]].
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������������ :
The Mikrotik-Bootloader (called "RouterBoot") needs a YAFFS2-Partition to load
the kernel from.
The sysupgrade-procedure of OpenWRT 18.06 employs a premade YAFFS2-image
that gets flashed to the chip.
YAFFS2-Partitions vitally depend on the chip's page size.
The page size of the premade kernel-YAFFS2-Image is fixed at build-time.
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".
amberthold:
OpenWrt 18.06. does not work on at least some RB45Gs, because the yaffs2-Image for the kernel in
openwrt-18.06.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin
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/platform.sh, 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:
https://wikidevi.com/wiki/MikroTik_RouterBOARD_450G_%28RB450G%29
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.
====Workaround:====
After quite some time, I figures out the following workaround:
mtd erase /dev/mtd5 mkdir /mnt/kernel mount -t yaffs2 /dev/mtdblock5 /mnt/kernel cd /mnt/kernel wget -O kernel http://192.168.88.1:8080/openwrt-18.06.0-ar71xx-mikrotik-vmlinux-lzma.elf chmod +x kernel cd / sync umount /mnt/kernel
With this procedure I got a working installation.
The text was updated successfully, but these errors were encountered: