Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
openwrt-bot opened this issue Aug 14, 2018 · 2 comments
Labels

Comments

@openwrt-bot
Copy link

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:

  • 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
  • Netboot OpenWrt 14.07 (because v18.06 lacks yaffs2-kernel-support !)
  • 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 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.

@openwrt-bot
Copy link
Author

chunkeey:

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]].

@openwrt-bot
Copy link
Author

amberthold:

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant