CHIPPro NAND issue with 4.12 rc1
Boris Brezillon
boris.brezillon at free-electrons.com
Sat May 20 08:14:18 PDT 2017
Le Sat, 20 May 2017 08:49:04 -0600,
Angus Ainslie <angus at akkea.ca> a écrit :
> Hi All,
>
> I'm trying to boot a CHIPPro with the stock 4.12 rc1 kernel. If I make
> no modifications to the sun5i-gr8-chip-pro.dtb the kernel boots but
> can't find the root partition.
>
> So I added the partitions to the dts file
>
> diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> index c55b11a..0e61e6b 100644
> --- a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> +++ b/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
> @@ -146,6 +146,32 @@
> reg = <0>;
> allwinner,rb = <0>;
> nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + spl at 0 {
> + label = "SPL";
> + reg = /bits/ 64 <0x0 0x400000>;
> + };
> +
> + spl-backup at 400000 {
> + label = "SPL.backup";
> + reg = /bits/ 64 <0x400000 0x400000>;
> + };
> +
> + u-boot at 800000 {
> + label = "U-Boot";
> + reg = /bits/ 64 <0x800000 0x400000>;
> + };
> +
> + env at c00000 {
> + label = "env";
> + reg = /bits/ 64 <0xc00000 0x400000>;
> + };
> +
> + rootfs at 1000000 {
> + label = "rootfs";
> + reg = /bits/ 64 <0x1000000 0x1f000000>;
> + };
> };
> };
>
> and now the kernel finds the partition but it times out trying to mount
> it. It seems to be something in the dts files because if I use the
> ntc-gr8-crumb.dts from the ntc 4.4.30 kernel then the system boots all
> the way to userland.
Hm, that's weird. Just changing the dtb makes it work? Did you try to
dump both dtbs and figure out what else changes?
Also, I wonder how the NAND is correctly detected without this patch
[1].
>
> [ 7.130000] ubi0: scanning is finished
> [ 7.150000] ubi0: attached mtd4 (name "rootfs", size 496 MiB)
> [ 7.160000] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 258048
> bytes
> [ 7.170000] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size
> 1024
> [ 7.180000] ubi0: VID header offset: 1024 (aligned 1024), data
> offset: 4096
> [ 7.190000] ubi0: good PEBs: 1977, bad PEBs: 7, corrupted PEBs: 0
> [ 7.200000] ubi0: user volume: 1, internal volumes: 1, max. volumes
> count: 128
> [ 7.210000] ubi0: max/mean erase counter: 3/1, WL threshold: 4096,
> image sequence number: 1444477407
> [ 7.220000] ubi0: available PEBs: 1, total reserved PEBs: 1976, PEBs
> reserved for bad PEB handling: 33
UBI attach works...
> [ 7.240000] hctosys: unable to open rtc device (rtc0)
> [ 7.250000] vcc3v0: disabling
> [ 7.250000] ALSA device list:
> [ 7.260000] #0: sun4i-codec
> [ 7.260000] ubi0: background thread "ubi_bgt0d" started, PID 53
> [ 8.320000] sunxi_nand 1c03000.nand: wait interrupt timedout
> [ 9.320000] sunxi_nand 1c03000.nand: wait interrupt timedout
> [ 10.330000] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 11.340000] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 12.350000] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 13.360000] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 14.370000] sunxi_nand 1c03000.nand: wait for empty cmd FIFO timedout
> [ 14.380000] ubi0 warning: ubi_io_read: error -110 while reading 4096
> bytes from PEB 1034:4096, read only 0 bytes, retry
And suddenly you get timeouts. That's really weird.
[1]https://github.com/NextThingCo/linux/commit/5ebc35ce1223ef14ace9479d5f97d0fce979e550
More information about the linux-arm-kernel
mailing list