From: Steve Kinneberg <steve.xcomlabs@gmail.com>
To: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: ubiattach fails after ubiformat
Date: Mon, 13 Dec 2021 09:04:20 -0800 [thread overview]
Message-ID: <3c95f53c5253f50ab491faabd2abc4f111146d88.camel@gmail.com> (raw)
In-Reply-To: <ae580001397f55ff36f1e46e8ff09ab0c068a131.camel@gmail.com>
On Mon, 2021-12-06 at 14:13 -0800, Steve Kinneberg wrote:
> Hello,
>
> I am having problems using ubiattach with an SLC NAND Flash device on a
> custom board based off the NXP LS1046ARDB reference design running
> OpenWrt 21.02. If I issue the following commands, ubiattach appears to
> work:
>
> flash_erase /dev/mtd0 0 4096
> ubiattach -m 0 -O 2048
>
> If I use ubiformat, then ubiattach will fail. Here is the sequence of
> commands that I have tried:
>
> flash_erase /dev/mtd0 0 4096
> ubiformat /dev/mtd0 -s 2048 -O 2048
> ubiattach -m 0 -O 2048
>
> At this point, the kernel repeatedly outputs the following (the PEB
> value increments):
>
> [13440.396590] ubi0 warning: ubi_io_read: error -74 (ECC error) while
> reading 64 bytes from PEB 3:0, read only 64 bytes, retry
> [13440.408305] ubi0 warning: ubi_io_read: error -74 (ECC error) while
> reading 64 bytes from PEB 3:0, read only 64 bytes, retry
> [13440.420021] ubi0 warning: ubi_io_read: error -74 (ECC error) while
> reading 64 bytes from PEB 3:0, read only 64 bytes, retry
> [13440.431737] ubi0 error: ubi_io_read: error -74 (ECC error) while
> reading 64 bytes from PEB 3:0, read 64 bytes
> [13440.441660] CPU: 2 PID: 3110 Comm: ubiattach Not tainted 5.4.154 #0
> [13440.447924] Hardware name: XAPH Board (DT)
> [13440.452013] Call trace:
> [13440.454453] dump_backtrace+0x0/0x120
> [13440.458110] show_stack+0x14/0x20
> [13440.461417] dump_stack+0xb4/0xf4
> [13440.464724] ubi_io_read+0x17c/0x308
> [13440.468292] ubi_io_read_ec_hdr+0x4c/0x210
> [13440.472383] ubi_attach+0x40c/0x1330
> [13440.475953] ubi_attach_mtd_dev+0x570/0xb08
> [13440.480130] ctrl_cdev_ioctl+0x3ac/0x510
> [13440.484047] do_vfs_ioctl+0xa4/0xe00
> [13440.487617] ksys_ioctl+0x44/0x90
> [13440.490924] __arm64_sys_ioctl+0x1c/0x210
> [13440.494928] el0_svc_handler+0x88/0x118
> [13440.498757] el0_svc+0x8/0x210
>
> The same sequence of commands using the nandsim driver on a desktop
> Linux system works fine. I can even flash a UBI image or create
> volumes using the nandsim.
>
> Here is Linux kernel bootup messages regarding identification of the
> NAND Flash:
>
> [ 0.787530] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xac
> [ 0.793889] nand: AMD/Spansion S34MS04G2
> [ 0.797810] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 128
> [ 0.806065] Bad block table found at page 262080, version 0x01
> [ 0.813052] Bad block table found at page 262016, version 0x01
> [ 0.819495] mtd: no mtd-id
> [ 0.822506] fsl,ifc-nand 7e800000.nand: IFC NAND device at
> 0x7e800000, bank 0
>
> The part number and size are correct for the HW.
> Linux kernel version (from /proc/version):
>
> Linux version 5.4.154 (steve@steve-linux) (gcc version 8.4.0 (OpenWrt
> GCC 8.4.0 r16330+8-4607f55439)) #0 SMP PREEMPT Tue Nov 30 14:37:50 2021
>
>
> Output from /proc/mtd:
>
> dev: size erasesize name
> mtd0: 20000000 00020000 "7e800000.flash"
> mtd1: 00100000 00001000 "bl2"
> mtd2: 00400000 00001000 "fip"
> mtd3: 00100000 00001000 "u-boot-env"
> mtd4: 00300000 00001000 "reserved-1"
> mtd5: 00040000 00001000 "fman"
> mtd6: 005c0000 00001000 "reserved-2"
> mtd7: 00100000 00001000 "dtb"
> mtd8: 01000000 00001000 "kernel"
> mtd9: 02000000 00001000 "rootfs"
> mtd10: 0186e000 00001000 "rootfs_data"
> mtd11: 03100000 00001000 "firmware"
>
>
> Linux boot command line:
>
> root=/dev/mtdblock9 rootfstype=squashfs noinitrd
> earlycon=uart8250,mmio,0x21c0500 console=ttyS0,115200
> mtdparts=1550000.spi:1m(bl2),4m(fip),1m(u-boot-env),3m(reserved-
> 1),256k(fman),5888k(reserved-
> 2),1m(dtb),16m(kernel),32m(rootfs),49m@0xf00000(firmware),
> 64m@0x000000(nor-flash);7e800000.flash
>
>
> I presume that I am missing a step or mis-configured something. Any
> pointers would be greatly appreciated.
>
> Thanks,
> Steve Kinneberg
Hi,
I'm still having problems with ubiattach. I've even tried hacking the
Linux kernel driver as suggested in this thread from almost 3 years
ago: https://www.spinics.net/lists/linux-mtd/msg05327.html
That thread is the closest I can find to a similar problem to what I'm
having, but the suggested solutions in it do not work for me.
I've since discovered that even though ubiattach works after
flash_erase, if I detach and re-attach, I get the same kernel errors.
Any suggestions on debugging this will be greatly appreciated.
Thanks,
Steve
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2021-12-13 17:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-06 22:13 ubiattach fails after ubiformat Steve Kinneberg
2021-12-13 17:04 ` Steve Kinneberg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3c95f53c5253f50ab491faabd2abc4f111146d88.camel@gmail.com \
--to=steve.xcomlabs@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox