| Message ID | 399ea126f3b18071fbe46bfc9787df6b@www.akkea.ca |
|---|---|
| State | Not Applicable |
| Headers | show |
Le Sat, 20 May 2017 08:49:04 -0600, Angus Ainslie <angus@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@0 { > + label = "SPL"; > + reg = /bits/ 64 <0x0 0x400000>; > + }; > + > + spl-backup@400000 { > + label = "SPL.backup"; > + reg = /bits/ 64 <0x400000 0x400000>; > + }; > + > + u-boot@800000 { > + label = "U-Boot"; > + reg = /bits/ 64 <0x800000 0x400000>; > + }; > + > + env@c00000 { > + label = "env"; > + reg = /bits/ 64 <0xc00000 0x400000>; > + }; > + > + rootfs@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
On 2017-05-20 09:14, Boris Brezillon wrote: > Le Sat, 20 May 2017 08:49:04 -0600, > Angus Ainslie <angus@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@0 { >> + label = "SPL"; >> + reg = /bits/ 64 <0x0 0x400000>; >> + }; >> + >> + spl-backup@400000 { >> + label = "SPL.backup"; >> + reg = /bits/ 64 <0x400000 0x400000>; >> + }; >> + >> + u-boot@800000 { >> + label = "U-Boot"; >> + reg = /bits/ 64 <0x800000 0x400000>; >> + }; >> + >> + env@c00000 { >> + label = "env"; >> + reg = /bits/ 64 <0xc00000 0x400000>; >> + }; >> + >> + rootfs@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? > Yeah I thought it was weird too. I was thinking that maybe the pin muxes were getting changed and the rb net or the interrupt net was getting changed to a different function. I did decompile to 2 dtb's and I couldn't find many differences. They were mostly around some pull ups and drive strength for some of the NAND and i2c pins. I tried adding those changes and it still didn't work so I went back to the minimal set of changes to reproduce the bug. > Also, I wonder how the NAND is correctly detected without this patch > [1]. > That patch seems to be in my 4.12-rc1 kernel, I have a definition for the TC58NVG2S0H. >> >> [ 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. Is there anything I can do on this end to help debug ? > > [1]https://github.com/NextThingCo/linux/commit/5ebc35ce1223ef14ace9479d5f97d0fce979e550
Le Sat, 20 May 2017 15:24:06 -0600, Angus Ainslie <angus@akkea.ca> a écrit : > On 2017-05-20 09:14, Boris Brezillon wrote: > > Le Sat, 20 May 2017 08:49:04 -0600, > > Angus Ainslie <angus@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@0 { > >> + label = "SPL"; > >> + reg = /bits/ 64 <0x0 0x400000>; > >> + }; > >> + > >> + spl-backup@400000 { > >> + label = "SPL.backup"; > >> + reg = /bits/ 64 <0x400000 0x400000>; > >> + }; > >> + > >> + u-boot@800000 { > >> + label = "U-Boot"; > >> + reg = /bits/ 64 <0x800000 0x400000>; > >> + }; > >> + > >> + env@c00000 { > >> + label = "env"; > >> + reg = /bits/ 64 <0xc00000 0x400000>; > >> + }; > >> + > >> + rootfs@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? > > > > Yeah I thought it was weird too. I was thinking that maybe the pin muxes > were getting changed and the rb net or the interrupt net was getting > changed to a different function. > > I did decompile to 2 dtb's and I couldn't find many differences. They > were mostly around some pull ups and drive strength for some of the NAND > and i2c pins. I tried adding those changes and it still didn't work so I > went back to the minimal set of changes to reproduce the bug. > > > Also, I wonder how the NAND is correctly detected without this patch > > [1]. > > > > > That patch seems to be in my 4.12-rc1 kernel, I have a definition for > the TC58NVG2S0H. > > >> > >> [ 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 Interestingly, it starts failing after the core disables all unused regulators. Not sure this is related but that's worth having a look. I looked at the schematics and it seems VCC-3V3 (which is powering the NAND chip) is enabled with the EXTEN pin of the AXP209 [1]. I don't know if this pin is controlled by Linux, but maybe you can dump register 0x12 and check if EXTEN is set to 1. > >> [ 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. > > > Is there anything I can do on this end to help debug ? > > > > > > [1]https://github.com/NextThingCo/linux/commit/5ebc35ce1223ef14ace9479d5f97d0fce979e550 > [1]http://linux-sunxi.org/AXP209
Hi, On Sun, May 21, 2017 at 07:45:35AM +0200, Boris Brezillon wrote: > > >> [ 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 > > Interestingly, it starts failing after the core disables all unused > regulators. Not sure this is related but that's worth having a look. > > I looked at the schematics and it seems VCC-3V3 (which is powering the > NAND chip) is enabled with the EXTEN pin of the AXP209 [1]. I don't know > if this pin is controlled by Linux, but maybe you can dump register > 0x12 and check if EXTEN is set to 1. > > > >> [ 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. This just made me realise, this is also the time where the clocks are disabled, and we changed our clock implementation in 4.11. And using the 4.4 DT will keep the old driver... Did you test in 4.11? If it's also broken, could you try to revert 1f4ce3b6ca79 and 6b48644b1d29 (I'm not sure it's going to be a trivial revert, but in that order it should work). Maxime
Hi Maxime On 2017-05-22 01:01, Maxime Ripard wrote: > > This just made me realise, this is also the time where the clocks are > disabled, and we changed our clock implementation in 4.11. > > And using the 4.4 DT will keep the old driver... > > Did you test in 4.11? If it's also broken, could you try to revert > 1f4ce3b6ca79 and 6b48644b1d29 (I'm not sure it's going to be a trivial > revert, but in that order it should work). > Thanks reverting those two allow the kernel to boot and mount the NAND.
On Mon, May 22, 2017 at 10:32:42AM -0600, Angus Ainslie wrote: > Hi Maxime > > On 2017-05-22 01:01, Maxime Ripard wrote: > > > > This just made me realise, this is also the time where the clocks are > > disabled, and we changed our clock implementation in 4.11. > > > > And using the 4.4 DT will keep the old driver... > > > > Did you test in 4.11? If it's also broken, could you try to revert > > 1f4ce3b6ca79 and 6b48644b1d29 (I'm not sure it's going to be a trivial > > revert, but in that order it should work). > > > > Thanks reverting those two allow the kernel to boot and mount the NAND. Ok, good. If you unrevert those patches, and add clk_ignore_unused to the kernel command line, is it still broken? Maxime
On 2017-05-23 13:52, Maxime Ripard wrote: > On Mon, May 22, 2017 at 10:32:42AM -0600, Angus Ainslie wrote: >> Hi Maxime >> >> On 2017-05-22 01:01, Maxime Ripard wrote: >> > >> > This just made me realise, this is also the time where the clocks are >> > disabled, and we changed our clock implementation in 4.11. >> > >> > And using the 4.4 DT will keep the old driver... >> > >> > Did you test in 4.11? If it's also broken, could you try to revert >> > 1f4ce3b6ca79 and 6b48644b1d29 (I'm not sure it's going to be a trivial >> > revert, but in that order it should work). >> > >> >> Thanks reverting those two allow the kernel to boot and mount the >> NAND. > > Ok, good. > > If you unrevert those patches, and add clk_ignore_unused to the kernel > command line, is it still broken? > > Maxime Putting those back in with the changed command line doesn't work [ 5.840000] UBI error: cannot open mtd 4, error -19 [ 5.840000] hctosys: unable to open rtc device (rtc0) [ 5.860000] clk: Not disabling unused clocks [ 5.860000] vcc3v0: disabling [ 5.870000] ALSA device list: [ 5.870000] #0: sun4i-codec [ 5.880000] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -19 [ 5.890000] Please append a correct "root=" boot option; here are the available partitions: [ 5.910000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 5.910000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2TNCPro #14 [ 5.910000] Hardware name: Allwinner sun4i/sun5i Families [ 5.910000] [<c010e440>] (unwind_backtrace) from [<c010b01c>] (show_stack+0x10/0x14) [ 5.910000] [<c010b01c>] (show_stack) from [<c0372cac>] (dump_stack+0x84/0x98) [ 5.910000] [<c0372cac>] (dump_stack) from [<c01ad0b0>] (panic+0xdc/0x248) [ 5.910000] [<c01ad0b0>] (panic) from [<c0a01208>] (mount_block_root+0x198/0x270) [ 5.910000] [<c0a01208>] (mount_block_root) from [<c0a014a8>] (prepare_namespace+0x9c/0x198) [ 5.910000] [<c0a014a8>] (prepare_namespace) from [<c0a00e40>] (kernel_init_freeable+0x1d8/0x1e8) [ 5.910000] [<c0a00e40>] (kernel_init_freeable) from [<c0711e74>] (kernel_init+0x8/0x110) [ 5.910000] [<c0711e74>] (kernel_init) from [<c0107578>] (ret_from_fork+0x14/0x3c) [ 5.910000] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 6.430000] g_cdc gadget: high-speed config #1: CDC Composite (ECM + ACM)
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@0 { + label = "SPL"; + reg = /bits/ 64 <0x0 0x400000>; + }; + + spl-backup@400000 { + label = "SPL.backup"; + reg = /bits/ 64 <0x400000 0x400000>; + }; + + u-boot@800000 { + label = "U-Boot"; + reg = /bits/ 64 <0x800000 0x400000>; + }; + + env@c00000 { + label = "env"; + reg = /bits/ 64 <0xc00000 0x400000>; + }; + + rootfs@1000000 { + label = "rootfs"; + reg = /bits/ 64 <0x1000000 0x1f000000>; + }; }; };