Kernel changes needed for mpc85xx NAND ECC under 5.10?

zeroping · November 4, 2021, 3:09am

Hi all,

A while back, I got OpenWrt working on my EdgeCore ECW7210's. They're Freescale P1020-based, and not too different from a few other models.

github.com/openwrt/openwrt

mpc85xx: add support for Edge-core ECW7210-L

openwrt:master ← zeroping:master

opened 04:11AM - 30 Dec 19 UTC

zeroping

+366 -0

Hardware ======== - CPU: Freescale P1020 PowerPC - RAM: 256 M DDR3 Nanya 2x N…T5CB64M16FP-DH (128 each) - NOR: 32MiB MXIC S134790MX29GL256FHT2I-90Q (u-boot) - NAND: 512MiB Micron 29F4G08ABADA (system images) - Eth0: BCM54612E PoE - Eth1: BCM54612E - 2.4GHz WiFi: 14e4:4331 BCM4331 802.11a/b/g/n - 5.0GHz WiFi: 14e4:43a2 BCM4360 802.11ac - USB: 1x USB 2.0 (internal) - LED: Power, WiFi, LAN ( all non-controllable) - BTN: Reset (harware) Serial is a Cisco-compatible RJ45 jack next to the ethernet ports. 115200-N-8 are the settings for OS and U-Boot. Installation ============ 1. Power on the device while attached to the console port. 2. Halt the U-Boot by pressing Enter when prompted. 2a. Boot loader may be configured to always autoboot (observed on a Tallac device). If this is the case, you need to corrupt the reads from the NAND after u-boot has started, but before the kernel image is read. It's U32, under the PoE board. Short pin 25 (GND) to any pin 29-32 at just the right time, and u-boot should see the failed checksum and drop you to a console. If you're dealing with this, temporarily disable autoboot by setting bootcmd to something useless: > setenv bootcmd echo "This u-boot has a hardcoded autoboot" > saveenv When you're done, you might consider leaving yourself a way in. I use a USB key plugged in to cause the boot loader to stop autoboot: > setenv bootcmd run boot_openwrt > setenv boot_openwrt "echo Autoboot broken on this U-boot. Insert a USB key to abort boot; usb start; if usb storage; then echo aborting\ autoboot; else echo autobooting; nboot 0x1000000 0 0 && \ bootm 0x1000000 ; fi" 3. Set the correct bootcmd for booting OpenWRT: > setenv boot_openwrt "setenv bootargs console=ttyS0,115200; \ nboot 0x1000000 0 0 && bootm 0x1000000" > setenv bootcmd run boot_openwrt > saveenv 4. Rename OpenWRT initramfs image to 'kernel.bin' and place it in a TFTP server root-directory. 5. Configure ip addresses: > setenv ipaddr 192.168.0.250 (a static ip on your network) > setenv serverip 192.168.0.42 (your tftp server's IP) 6. Set up the u-boot environment variables for the Ethernet MAC addresses: (br-lan won't work if there's not a mac address set for eth0) > setenv ethaddr 70:72:CF:00:12:10 > setenv eth2addr 70:72:CF:00:12:02 > saveenv 4. Boot OpenWRT initramfs image with: > setenv bootargs console=ttyS0; tftpboot kernel.bin; bootm 6. (Optional) Make a Backup of the NAND flash in case you ever want to go back to the vendor firmware. We will be reformatting it entirely, so you may want to record the layout shown during stock kernel boot. 8. Transfer OpenWRT sysupgrade image to the device via SCP and install it with: > sysupgrade -n \<openwrt-image-file\> Signed-off-by: Scott Gilliland <zeroping@gmail.com>

The device support never actually got merged, mostly because I was too slow and inexperienced to get the PR together quickly. That said, I've been keeping these devices running for myself, since a set of three of them are my home network.

I went to build a snapshot image, and ran into some trouble. Specifically, the NAND flash wouldn't show up:

nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
nand: Micron MT29F4G08ABADAWP
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
fsl,elbc-fcm-nand: probe of ffa00000.nand failed with error -22

As near as I can tell, this is because the Linux kernel's internal description of how the NAND is handling ECC has outpaced the driver for the built-in NAND controller in the P1020 processors. Adding a new case to handle NAND_ECC_ENGINE_TYPE_ON_HOST seems to get it working for me.

(yes, that comment seems to be foreshadowing)

That said, I could be wrong. Maybe there's just some magic incantation that needs to be in the device tree to get it working. Not my area of expertise.

This post isn't a github issue or a PR - I'm looking for some high-level guidance first.

First, if I understand this correctly, this ought to affect other P1020-based devices with NAND, right? That includes the OCEDO Panda and the Sophos RED 15w. Am I just the first one to notice this issue? Does the OpenWRT community represent everyone that runs the P1020 under newer kernels? Are there even other people running OpenWrt on these devices? ... Or am I just doing something uniquely wrong?

Second, how should I approach getting this fixed? Do I try to get a PR in to the kernel? Or get a PR in to add a kernel patch to OpenWRT? Should I try again to merge support for my EdgeCores in too? Or just keep them running in my own fork? Or is this older hardware that no one else cares about any more?

Any impressions or suggestions are appreciated.

hurricos · December 19, 2021, 5:47pm

So, funny, the AP370 (which is another P1020E device with an open PR that hasn't gotten merged) actually has:

[    9.062526] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd3
[    9.138709] nand: Samsung NAND 1GiB 3,3V 8-bit
[    9.191872] nand: 1024 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    9.284045] Bad block table found at page 524224, version 0x01
[    9.354596] Bad block table found at page 524160, version 0x01
[    9.424746] nand_read_bbt: bad block at 0x0000042a0000
[    9.486296] nand_read_bbt: bad block at 0x000031700000
[    9.547787] nand_read_bbt: bad block at 0x000036420000
[    9.609277] nand_read_bbt: bad block at 0x0000368c0000

This runs fine on

root@ap370-1:~# uname -a
Linux ap370-1 5.10.80 #0 SMP Fri Nov 26 18:05:16 2021 ppc GNU/Linux

I'm guessing this is because mine is hardware NAND whereas yours is software NAND (just a guess!), specifically based on your new case for NAND_ECC_ENGINE_TYPE_ON_HOST.

Do you know how to create a .patch file to apply your changes that got your EdgeCore working again? If so, you would want to raise @chunkeey and we can see if we can get that patch submitted to the linuxppc-dev mailing list. OpenWrt would then backport it (keep your patch) until the upstream kernel has it in backports.