| Message ID | 20200815155237.467720-12-seanga2@gmail.com |
|---|---|
| State | Superseded |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
| Series | riscv: Add FPIOA and GPIO support for Kendryte K210 | expand |
Hi Tom > This patch adds the necessary configs and docs for FPIOA and GPIO support > on the K210. > > The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default > value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not > changed). It also boots when changes are made to the device tree and then > committed. I don't know why this happens. These breakages only occur after > bf2fb81ad3. > > Signed-off-by: Sean Anderson <seanga2@gmail.com> > --- > > Changes in v5: > - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again > - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded > by commit 2548493ab4. Would you like to pick up this series, [PATCH v5 00/11] riscv: Add FPIOA and GPIO support for Kendryte K210 ? Or maybe it is better to figure out what is wrong here and find the root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? Thanks, Rick > > Changes in v3: > - Document pins 6 and 7 as not set > > Changes in v2: > - Remove SPI flash related Kconfig settings > > board/sipeed/maix/Kconfig | 9 +++++ > configs/sipeed_maix_bitm_defconfig | 2 + > doc/board/sipeed/maix.rst | 64 +++++++++++++++++++++++++++++- > 3 files changed, 73 insertions(+), 2 deletions(-) > > diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig > index 0cdcd32adc..4c42dd2087 100644 > --- a/board/sipeed/maix/Kconfig > +++ b/board/sipeed/maix/Kconfig > @@ -44,4 +44,13 @@ config BOARD_SPECIFIC_OPTIONS > imply RESET_SYSCON > imply SYSRESET > imply SYSRESET_SYSCON > + imply PINCTRL > + imply PINCONF > + imply PINCTRL_K210 > + imply DM_GPIO > + imply DWAPB_GPIO > + imply SIFIVE_GPIO > + imply CMD_GPIO > + imply LED > + imply LED_GPIO > endif > diff --git a/configs/sipeed_maix_bitm_defconfig b/configs/sipeed_maix_bitm_defconfig > index 459bf0d530..0b038ff0a1 100644 > --- a/configs/sipeed_maix_bitm_defconfig > +++ b/configs/sipeed_maix_bitm_defconfig > @@ -2,6 +2,8 @@ CONFIG_RISCV=y > CONFIG_TARGET_SIPEED_MAIX=y > CONFIG_ARCH_RV64I=y > CONFIG_STACK_SIZE=0x100000 > +# FIXME: Dirty hack to get boot working! > +CONFIG_LOGLEVEL=5 > # CONFIG_NET is not set > # CONFIG_INPUT is not set > # CONFIG_DM_ETH is not set > diff --git a/doc/board/sipeed/maix.rst b/doc/board/sipeed/maix.rst > index b1894f3a6f..3811eac61f 100644 > --- a/doc/board/sipeed/maix.rst > +++ b/doc/board/sipeed/maix.rst > @@ -156,7 +156,7 @@ To run legacy images, use the ``bootm`` command: > Load Address: 80000000 > Entry Point: 80000000 > > - $ picocom -b 115200 /dev/ttyUSB0i > + $ picocom -b 115200 /dev/ttyUSB0 > => loady > ## Ready for binary (ymodem) download to 0x80000000 at 115200 bps... > C > @@ -187,6 +187,66 @@ To run legacy images, use the ``bootm`` command: > argv[0] = "<NULL>" > Hit any key to exit ... > > +Pin Assignment > +-------------- > + > +The K210 contains a Fully Programmable I/O Array (FPIOA), which can remap any of > +its 256 input functions to any any of 48 output pins. The following table has > +the default pin assignments for the BitM. > + > +===== ========== ======= > +Pin Function Comment > +===== ========== ======= > +IO_0 JTAG_TCLK > +IO_1 JTAG_TDI > +IO_2 JTAG_TMS > +IO_3 JTAG_TDO > +IO_4 UARTHS_RX > +IO_5 UARTHS_TX > +IO_6 Not set > +IO_7 Not set > +IO_8 GPIO_0 > +IO_9 GPIO_1 > +IO_10 GPIO_2 > +IO_11 GPIO_3 > +IO_12 GPIO_4 Green LED > +IO_13 GPIO_5 Red LED > +IO_14 GPIO_6 Blue LED > +IO_15 GPIO_7 > +IO_16 GPIOHS_0 ISP > +IO_17 GPIOHS_1 > +IO_18 I2S0_SCLK MIC CLK > +IO_19 I2S0_WS MIC WS > +IO_20 I2S0_IN_D0 MIC SD > +IO_21 GPIOHS_5 > +IO_22 GPIOHS_6 > +IO_23 GPIOHS_7 > +IO_24 GPIOHS_8 > +IO_25 GPIOHS_9 > +IO_26 SPI1_D1 MMC MISO > +IO_27 SPI1_SCLK MMC CLK > +IO_28 SPI1_D0 MMC MOSI > +IO_29 GPIOHS_13 MMC CS > +IO_30 GPIOHS_14 > +IO_31 GPIOHS_15 > +IO_32 GPIOHS_16 > +IO_33 GPIOHS_17 > +IO_34 GPIOHS_18 > +IO_35 GPIOHS_19 > +IO_36 GPIOHS_20 Panel CS > +IO_37 GPIOHS_21 Panel RST > +IO_38 GPIOHS_22 Panel DC > +IO_39 SPI0_SCK Panel WR > +IO_40 SCCP_SDA > +IO_41 SCCP_SCLK > +IO_42 DVP_RST > +IO_43 DVP_VSYNC > +IO_44 DVP_PWDN > +IO_45 DVP_HSYNC > +IO_46 DVP_XCLK > +IO_47 DVP_PCLK > +===== ========== ======= > + > Over- and Under-clocking > ------------------------ > > @@ -361,5 +421,5 @@ Address Size Description > 0x8801C000 0x1000 riscv priv spec 1.9 config > 0x8801D000 0x2000 flattened device tree (contains only addresses and > interrupts) > -0x8801f000 0x1000 credits > +0x8801F000 0x1000 credits > ========== ========= =========== > -- > 2.28.0 >
On 8/18/20 11:48 PM, Rick Chen wrote: > Hi Tom > >> This patch adds the necessary configs and docs for FPIOA and GPIO support >> on the K210. >> >> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default >> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not >> changed). It also boots when changes are made to the device tree and then >> committed. I don't know why this happens. These breakages only occur after >> bf2fb81ad3. >> >> Signed-off-by: Sean Anderson <seanga2@gmail.com> >> --- >> >> Changes in v5: >> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again >> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded >> by commit 2548493ab4. > > Would you like to pick up this series, [PATCH v5 00/11] riscv: Add > FPIOA and GPIO support for Kendryte K210 ? > Or maybe it is better to figure out what is wrong here and find the > root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased for the same effect. In addition, there are several other ways I found to "fix" this bug (as noted in the commit message). If you would like to test this out, I have two trees [1, 2] where this series (actually a slightly earlier version of this series) is applied just before and just after bf2fb81ad3. The original patch is located at [3]. --Sean [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/
Hi Sean > On 8/18/20 11:48 PM, Rick Chen wrote: > > Hi Tom > > > >> This patch adds the necessary configs and docs for FPIOA and GPIO support > >> on the K210. > >> > >> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default > >> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not > >> changed). It also boots when changes are made to the device tree and then > >> committed. I don't know why this happens. These breakages only occur after > >> bf2fb81ad3. > >> > >> Signed-off-by: Sean Anderson <seanga2@gmail.com> > >> --- > >> > >> Changes in v5: > >> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again > >> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded > >> by commit 2548493ab4. > > > > Would you like to pick up this series, [PATCH v5 00/11] riscv: Add > > FPIOA and GPIO support for Kendryte K210 ? > > Or maybe it is better to figure out what is wrong here and find the > > root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? > > As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased > for the same effect. In addition, there are several other ways I found > to "fix" this bug (as noted in the commit message). If you would like to > test this out, I have two trees [1, 2] where this series (actually a slightly > earlier version of this series) is applied just before and just after > bf2fb81ad3. The original patch is located at [3]. > > --Sean > > [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good > [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad > [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/ I don't have a K210 board for verification. But it is OK to run in AE350 board after applying your series. After check about this commit "common/board_r: Remove initr_serial wrapper", it seem shall not affect anything. It just change to call serial_initialize directly. Only I can think about maybe it is a cache problem. Just like sometime we add a printf, then the problem will be walk around. Thanks, Rick
Hi Sean > Hi Sean > > > On 8/18/20 11:48 PM, Rick Chen wrote: > > > Hi Tom > > > > > >> This patch adds the necessary configs and docs for FPIOA and GPIO support > > >> on the K210. > > >> > > >> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default > > >> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not > > >> changed). It also boots when changes are made to the device tree and then > > >> committed. I don't know why this happens. These breakages only occur after > > >> bf2fb81ad3. > > >> > > >> Signed-off-by: Sean Anderson <seanga2@gmail.com> > > >> --- > > >> > > >> Changes in v5: > > >> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again > > >> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded > > >> by commit 2548493ab4. > > > > > > Would you like to pick up this series, [PATCH v5 00/11] riscv: Add > > > FPIOA and GPIO support for Kendryte K210 ? > > > Or maybe it is better to figure out what is wrong here and find the > > > root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? > > > > As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased > > for the same effect. In addition, there are several other ways I found > > to "fix" this bug (as noted in the commit message). If you would like to > > test this out, I have two trees [1, 2] where this series (actually a slightly > > earlier version of this series) is applied just before and just after > > bf2fb81ad3. The original patch is located at [3]. > > > > --Sean > > > > [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good > > [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad > > [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/ > > I don't have a K210 board for verification. > But it is OK to run in AE350 board after applying your series. > > After check about this commit "common/board_r: Remove initr_serial > wrapper", it seem shall not affect anything. > It just change to call serial_initialize directly. > Only I can think about maybe it is a cache problem. > Just like sometime we add a printf, then the problem will be walk around. Can you dig in to find the root cause ? For code stability, it is better not to have any unknown issue. Yo can dirty hack and work around currently, but it may crash again after several commits. Thanks, Rick > > Thanks, > Rick
Hi Sean and all, Sorry for dropping this mail out of the blue. I'm trying to follow the instrcutions from `doc/board/sipeed/maix.rst` to build and flash u-boot so as to verify Sean's work on `maix_gpio_good` tree. Yet the console has no output. Furthermore, I found the documentation on Sipeed board to be a little bit confusing. In your first commit of that document, it's stated that "only the Sipeed MAIX BiT V2.0 (bitm) and Sipeed MAIXDUINO are supported." Yet the later commit (137dc15) added a table which implies that the older version of MAIX BiT is supported. So I'm a bit confused about whether older MAIX BiTs get supported or not ? (I'm testing the builts on the older version.) Does the replacement of CH34x with CH552 may cause the issue I'm encountering ? By the way, I was trying to use the pre-built toolchain from kendryte's GitHub [1]. Yet the linker (riscv64-unknown-elf-ld.bfd) complains that `-pie` is not supported. Hence I switched to the the binutils v2.34 built from upstream and the u-boot could be built without that hiccup. Could someone tell me which toolchain is recommended for building the u-boot for boards Kendryte K210 ? [1] https://github.com/kendryte/kendryte-gnu-toolchainhttps://github.com/kendryte/kendryte-gnu-toolchain Many thanks, Ruinland On Thu, Aug 20, 2020 at 02:25:36PM +0800, Rick Jian-Zhi Chen(陳建志) wrote: > > > -----Original Message----- > From: Sean Anderson [mailto:seanga2@gmail.com] > Sent: Wednesday, August 19, 2020 7:13 PM > To: Rick Chen > Cc: U-Boot Mailing List; Simon Glass; Tom Rini; Bin Meng; Rick Jian-Zhi Chen(陳建志); Alan Quey-Liang Kao(高魁良) > Subject: Re: [PATCH v5 11/11] riscv: Add FPIOA and GPIO support for Kendryte K210 > > On 8/18/20 11:48 PM, Rick Chen wrote: > > Hi Tom > > > >> This patch adds the necessary configs and docs for FPIOA and GPIO support > >> on the K210. > >> > >> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default > >> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not > >> changed). It also boots when changes are made to the device tree and then > >> committed. I don't know why this happens. These breakages only occur after > >> bf2fb81ad3. > >> > >> Signed-off-by: Sean Anderson <seanga2@gmail.com> > >> --- > >> > >> Changes in v5: > >> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again > >> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded > >> by commit 2548493ab4. > > > > Would you like to pick up this series, [PATCH v5 00/11] riscv: Add > > FPIOA and GPIO support for Kendryte K210 ? > > Or maybe it is better to figure out what is wrong here and find the > > root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? > > As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased > for the same effect. In addition, there are several other ways I found > to "fix" this bug (as noted in the commit message). If you would like to > test this out, I have two trees [1, 2] where this series (actually a slightly > earlier version of this series) is applied just before and just after > bf2fb81ad3. The original patch is located at [3]. > > --Sean > > [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good > [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad > [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/
On 8/21/20 5:08 AM, Ruinland ChuanTzu Tsai wrote: > Hi Sean and all, > > Sorry for dropping this mail out of the blue. > > I'm trying to follow the instrcutions from `doc/board/sipeed/maix.rst` > to build and flash u-boot so as to verify Sean's work on `maix_gpio_good` tree. > > Yet the console has no output. > > Furthermore, I found the documentation on Sipeed board to be a little bit confusing. > In your first commit of that document, it's stated that "only the Sipeed MAIX BiT > V2.0 (bitm) and Sipeed MAIXDUINO are supported." Those are the only boards I have, so those are all that I can support. > Yet the later commit (137dc15) added a table which implies that the older version > of MAIX BiT is supported. So I'm a bit confused about whether older MAIX BiTs get > supported or not ? (I'm testing the builts on the older version.) It *should* work, but I haven't tested anything on a bit v1. Have you tried booting with v2020.07? That release should have the bare minimum needed to get things working. > Does the replacement of CH34x with CH552 may cause the issue I'm encountering ? Probably not. > > By the way, I was trying to use the pre-built toolchain from kendryte's GitHub [1]. > Yet the linker (riscv64-unknown-elf-ld.bfd) complains that `-pie` is not supported. > Hence I switched to the the binutils v2.34 built from upstream and the u-boot could > be built without that hiccup. I have been using the toolchain which comes with my distro (riscv64-linux-gnu-* on Arch). I don't know whether that makes much difference, but I have never used Canaan's pre-build toolchain. --Sean > > Could someone tell me which toolchain is recommended for building the u-boot for > boards Kendryte K210 ? > > [1] https://github.com/kendryte/kendryte-gnu-toolchainhttps://github.com/kendryte/kendryte-gnu-toolchain > > Many thanks, > Ruinland > > On Thu, Aug 20, 2020 at 02:25:36PM +0800, Rick Jian-Zhi Chen(陳建志) wrote: >> >> >> -----Original Message----- >> From: Sean Anderson [mailto:seanga2@gmail.com] >> Sent: Wednesday, August 19, 2020 7:13 PM >> To: Rick Chen >> Cc: U-Boot Mailing List; Simon Glass; Tom Rini; Bin Meng; Rick Jian-Zhi Chen(陳建志); Alan Quey-Liang Kao(高魁良) >> Subject: Re: [PATCH v5 11/11] riscv: Add FPIOA and GPIO support for Kendryte K210 >> >> On 8/18/20 11:48 PM, Rick Chen wrote: >>> Hi Tom >>> >>>> This patch adds the necessary configs and docs for FPIOA and GPIO support >>>> on the K210. >>>> >>>> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default >>>> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not >>>> changed). It also boots when changes are made to the device tree and then >>>> committed. I don't know why this happens. These breakages only occur after >>>> bf2fb81ad3. >>>> >>>> Signed-off-by: Sean Anderson <seanga2@gmail.com> >>>> --- >>>> >>>> Changes in v5: >>>> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again >>>> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded >>>> by commit 2548493ab4. >>> >>> Would you like to pick up this series, [PATCH v5 00/11] riscv: Add >>> FPIOA and GPIO support for Kendryte K210 ? >>> Or maybe it is better to figure out what is wrong here and find the >>> root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? >> >> As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased >> for the same effect. In addition, there are several other ways I found >> to "fix" this bug (as noted in the commit message). If you would like to >> test this out, I have two trees [1, 2] where this series (actually a slightly >> earlier version of this series) is applied just before and just after >> bf2fb81ad3. The original patch is located at [3]. >> >> --Sean >> >> [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good >> [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad >> [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/
On 8/20/20 4:47 AM, Rick Chen wrote: > Hi Sean > >> Hi Sean >> >>> On 8/18/20 11:48 PM, Rick Chen wrote: >>>> Hi Tom >>>> >>>>> This patch adds the necessary configs and docs for FPIOA and GPIO support >>>>> on the K210. >>>>> >>>>> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default >>>>> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not >>>>> changed). It also boots when changes are made to the device tree and then >>>>> committed. I don't know why this happens. These breakages only occur after >>>>> bf2fb81ad3. >>>>> >>>>> Signed-off-by: Sean Anderson <seanga2@gmail.com> >>>>> --- >>>>> >>>>> Changes in v5: >>>>> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again >>>>> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded >>>>> by commit 2548493ab4. >>>> >>>> Would you like to pick up this series, [PATCH v5 00/11] riscv: Add >>>> FPIOA and GPIO support for Kendryte K210 ? >>>> Or maybe it is better to figure out what is wrong here and find the >>>> root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? >>> >>> As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased >>> for the same effect. In addition, there are several other ways I found >>> to "fix" this bug (as noted in the commit message). If you would like to >>> test this out, I have two trees [1, 2] where this series (actually a slightly >>> earlier version of this series) is applied just before and just after >>> bf2fb81ad3. The original patch is located at [3]. >>> >>> --Sean >>> >>> [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good >>> [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad >>> [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/ >> >> I don't have a K210 board for verification. >> But it is OK to run in AE350 board after applying your series. >> >> After check about this commit "common/board_r: Remove initr_serial >> wrapper", it seem shall not affect anything. >> It just change to call serial_initialize directly. >> Only I can think about maybe it is a cache problem. >> Just like sometime we add a printf, then the problem will be walk around. > > Can you dig in to find the root cause ? > For code stability, it is better not to have any unknown issue. > Yo can dirty hack and work around currently, but it may crash again > after several commits. Ok, so I did some further digging, but I was unable to pin down the cause of the bug. My efforts to determine a cause have been primarily thwarted because the bug disappears after any change to initialization code. Adding any function to init_sequence_f or init_sequence_r, even a no-op function which just returns 0, causes the board to boot normally. In addition, adding a nop() to any function in those sequences will cause the board to boot normally. The board seems to fail to boot only with a very specific boot sequence and timing. When the board fails to boot, it hangs in a manner similar to when the airam is accessed: the bus appears to hang. Just as when airam is accessed, a debugger cannot read registers or memory until the cpu is reset. This may be a separate issue which hangs the bus, or it could also be caused by an inadvertent access to airam. The puzzling thing is still the manner of triggering the bug. It's almost as if it was specifically designed to be impossible to debug by disappearing whenever one makes an attempt... --Sean
Hi Sean > On 8/20/20 4:47 AM, Rick Chen wrote: > > Hi Sean > > > >> Hi Sean > >> > >>> On 8/18/20 11:48 PM, Rick Chen wrote: > >>>> Hi Tom > >>>> > >>>>> This patch adds the necessary configs and docs for FPIOA and GPIO support > >>>>> on the K210. > >>>>> > >>>>> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default > >>>>> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not > >>>>> changed). It also boots when changes are made to the device tree and then > >>>>> committed. I don't know why this happens. These breakages only occur after > >>>>> bf2fb81ad3. > >>>>> > >>>>> Signed-off-by: Sean Anderson <seanga2@gmail.com> > >>>>> --- > >>>>> > >>>>> Changes in v5: > >>>>> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again > >>>>> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded > >>>>> by commit 2548493ab4. > >>>> > >>>> Would you like to pick up this series, [PATCH v5 00/11] riscv: Add > >>>> FPIOA and GPIO support for Kendryte K210 ? > >>>> Or maybe it is better to figure out what is wrong here and find the > >>>> root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? > >>> > >>> As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased > >>> for the same effect. In addition, there are several other ways I found > >>> to "fix" this bug (as noted in the commit message). If you would like to > >>> test this out, I have two trees [1, 2] where this series (actually a slightly > >>> earlier version of this series) is applied just before and just after > >>> bf2fb81ad3. The original patch is located at [3]. > >>> > >>> --Sean > >>> > >>> [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good > >>> [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad > >>> [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/ > >> > >> I don't have a K210 board for verification. > >> But it is OK to run in AE350 board after applying your series. > >> > >> After check about this commit "common/board_r: Remove initr_serial > >> wrapper", it seem shall not affect anything. > >> It just change to call serial_initialize directly. > >> Only I can think about maybe it is a cache problem. > >> Just like sometime we add a printf, then the problem will be walk around. > > > > Can you dig in to find the root cause ? > > For code stability, it is better not to have any unknown issue. > > Yo can dirty hack and work around currently, but it may crash again > > after several commits. > > Ok, so I did some further digging, but I was unable to pin down the > cause of the bug. My efforts to determine a cause have been primarily > thwarted because the bug disappears after any change to initialization > code. Adding any function to init_sequence_f or init_sequence_r, even a > no-op function which just returns 0, causes the board to boot normally. > In addition, adding a nop() to any function in those sequences will > cause the board to boot normally. The board seems to fail to boot only > with a very specific boot sequence and timing. If you modify any code and the result will change, then you shall debug it via debugger(GDB) without any code modification. > > When the board fails to boot, it hangs in a manner similar to when the Maybe you can try to set a break and access the bus, if the bus access fail, then you re-set a break a bit ahead until the bus access NOT fail. To see if this way can pin down which instruction or the crucial code to cause the bus hang problem. And guess what maybe the root-cause. If you can find the instruction which may cause the bus hang, you can info all-registers and compare the differences between NG and OK. And guess what maybe the root-cause. Thanks, Rick > airam is accessed: the bus appears to hang. Just as when airam is > accessed, a debugger cannot read registers or memory until the cpu is > reset. This may be a separate issue which hangs the bus, or it could > also be caused by an inadvertent access to airam. The puzzling thing is > still the manner of triggering the bug. It's almost as if it was > specifically designed to be impossible to debug by disappearing whenever > one makes an attempt... > > --Sean
On 01.09.20 03:19, Rick Chen wrote: > Hi Sean > >> On 8/20/20 4:47 AM, Rick Chen wrote: >>> Hi Sean >>> >>>> Hi Sean >>>> >>>>> On 8/18/20 11:48 PM, Rick Chen wrote: >>>>>> Hi Tom >>>>>> >>>>>>> This patch adds the necessary configs and docs for FPIOA and GPIO support >>>>>>> on the K210. >>>>>>> >>>>>>> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default >>>>>>> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not >>>>>>> changed). It also boots when changes are made to the device tree and then >>>>>>> committed. I don't know why this happens. These breakages only occur after >>>>>>> bf2fb81ad3. >>>>>>> >>>>>>> Signed-off-by: Sean Anderson <seanga2@gmail.com> >>>>>>> --- >>>>>>> >>>>>>> Changes in v5: >>>>>>> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again >>>>>>> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded >>>>>>> by commit 2548493ab4. >>>>>> >>>>>> Would you like to pick up this series, [PATCH v5 00/11] riscv: Add >>>>>> FPIOA and GPIO support for Kendryte K210 ? >>>>>> Or maybe it is better to figure out what is wrong here and find the >>>>>> root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? >>>>> >>>>> As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased >>>>> for the same effect. In addition, there are several other ways I found >>>>> to "fix" this bug (as noted in the commit message). If you would like to >>>>> test this out, I have two trees [1, 2] where this series (actually a slightly >>>>> earlier version of this series) is applied just before and just after >>>>> bf2fb81ad3. The original patch is located at [3]. >>>>> >>>>> --Sean >>>>> >>>>> [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good >>>>> [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad >>>>> [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/ >>>> >>>> I don't have a K210 board for verification. >>>> But it is OK to run in AE350 board after applying your series. >>>> >>>> After check about this commit "common/board_r: Remove initr_serial >>>> wrapper", it seem shall not affect anything. >>>> It just change to call serial_initialize directly. >>>> Only I can think about maybe it is a cache problem. >>>> Just like sometime we add a printf, then the problem will be walk around. >>> >>> Can you dig in to find the root cause ? >>> For code stability, it is better not to have any unknown issue. >>> Yo can dirty hack and work around currently, but it may crash again >>> after several commits. >> >> Ok, so I did some further digging, but I was unable to pin down the >> cause of the bug. My efforts to determine a cause have been primarily >> thwarted because the bug disappears after any change to initialization >> code. Adding any function to init_sequence_f or init_sequence_r, even a >> no-op function which just returns 0, causes the board to boot normally. >> In addition, adding a nop() to any function in those sequences will >> cause the board to boot normally. The board seems to fail to boot only >> with a very specific boot sequence and timing. > > If you modify any code and the result will change, then you shall > debug it via debugger(GDB) without any code modification. > >> >> When the board fails to boot, it hangs in a manner similar to when the > > Maybe you can try to set a break and access the bus, if the bus access > fail, then you re-set a break a bit ahead until the bus access NOT > fail. > To see if this way can pin down which instruction or the crucial code > to cause the bus hang problem. And guess what maybe the root-cause. > > If you can find the instruction which may cause the bus hang, you can > info all-registers and compare the differences between NG and OK. And > guess what maybe the root-cause. Trying to narrow down on the problem I found the following: The system hangs before arch_cpu_init_dm() is called. After adding some debug functions the error appeared and disappeared when changing the code in function panic(). So my guess is that there is some alignment problem in the static data section. Best regards Heinrich > > Thanks, > Rick > >> airam is accessed: the bus appears to hang. Just as when airam is >> accessed, a debugger cannot read registers or memory until the cpu is >> reset. This may be a separate issue which hangs the bus, or it could >> also be caused by an inadvertent access to airam. The puzzling thing is >> still the manner of triggering the bug. It's almost as if it was >> specifically designed to be impossible to debug by disappearing whenever >> one makes an attempt... >> >> --Sean
On 9/2/20 8:26 AM, Heinrich Schuchardt wrote: > On 01.09.20 03:19, Rick Chen wrote: >> Hi Sean >> >>> On 8/20/20 4:47 AM, Rick Chen wrote: >>>> Hi Sean >>>> >>>>> Hi Sean >>>>> >>>>>> On 8/18/20 11:48 PM, Rick Chen wrote: >>>>>>> Hi Tom >>>>>>> >>>>>>>> This patch adds the necessary configs and docs for FPIOA and GPIO support >>>>>>>> on the K210. >>>>>>>> >>>>>>>> The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default >>>>>>>> value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not >>>>>>>> changed). It also boots when changes are made to the device tree and then >>>>>>>> committed. I don't know why this happens. These breakages only occur after >>>>>>>> bf2fb81ad3. >>>>>>>> >>>>>>>> Signed-off-by: Sean Anderson <seanga2@gmail.com> >>>>>>>> --- >>>>>>>> >>>>>>>> Changes in v5: >>>>>>>> - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again >>>>>>>> - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded >>>>>>>> by commit 2548493ab4. >>>>>>> >>>>>>> Would you like to pick up this series, [PATCH v5 00/11] riscv: Add >>>>>>> FPIOA and GPIO support for Kendryte K210 ? >>>>>>> Or maybe it is better to figure out what is wrong here and find the >>>>>>> root cause why it need to Increase CONSOLE_LOGLEVEL to 5 as a hack ? >>>>>> >>>>>> As an additional note, *CONFIG_LOGLEVEL (whoops) can also be decreased >>>>>> for the same effect. In addition, there are several other ways I found >>>>>> to "fix" this bug (as noted in the commit message). If you would like to >>>>>> test this out, I have two trees [1, 2] where this series (actually a slightly >>>>>> earlier version of this series) is applied just before and just after >>>>>> bf2fb81ad3. The original patch is located at [3]. >>>>>> >>>>>> --Sean >>>>>> >>>>>> [1] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_good >>>>>> [2] https://github.com/Forty-Bot/u-boot/tree/maix_gpio_bad >>>>>> [3] https://patchwork.ozlabs.org/project/uboot/patch/20200724111225.12513-15-ovidiu.panait@windriver.com/ >>>>> >>>>> I don't have a K210 board for verification. >>>>> But it is OK to run in AE350 board after applying your series. >>>>> >>>>> After check about this commit "common/board_r: Remove initr_serial >>>>> wrapper", it seem shall not affect anything. >>>>> It just change to call serial_initialize directly. >>>>> Only I can think about maybe it is a cache problem. >>>>> Just like sometime we add a printf, then the problem will be walk around. >>>> >>>> Can you dig in to find the root cause ? >>>> For code stability, it is better not to have any unknown issue. >>>> Yo can dirty hack and work around currently, but it may crash again >>>> after several commits. >>> >>> Ok, so I did some further digging, but I was unable to pin down the >>> cause of the bug. My efforts to determine a cause have been primarily >>> thwarted because the bug disappears after any change to initialization >>> code. Adding any function to init_sequence_f or init_sequence_r, even a >>> no-op function which just returns 0, causes the board to boot normally. >>> In addition, adding a nop() to any function in those sequences will >>> cause the board to boot normally. The board seems to fail to boot only >>> with a very specific boot sequence and timing. >> >> If you modify any code and the result will change, then you shall >> debug it via debugger(GDB) without any code modification. >> >>> >>> When the board fails to boot, it hangs in a manner similar to when the >> >> Maybe you can try to set a break and access the bus, if the bus access >> fail, then you re-set a break a bit ahead until the bus access NOT >> fail. Yeah, I was investigating that, however I was unable to get the k210 to break at 0x80000000. I suspect this may be a problem with openocd, as the k210 port is rather buggy (e.g. it can cause address misaligned errors, and sometimes leaves the pc in the debug dection of memory). I *can* get it to break in the otp (0x88000000), so perhaps I just need to identify the address before it jumps to U-Boot. >> To see if this way can pin down which instruction or the crucial code >> to cause the bus hang problem. And guess what maybe the root-cause. >> >> If you can find the instruction which may cause the bus hang, you can >> info all-registers and compare the differences between NG and OK. And >> guess what maybe the root-cause. > > Trying to narrow down on the problem I found the following: > > The system hangs before arch_cpu_init_dm() is called. This is not always the case. On most boots, the following output is present: U-Boot 2020.10-rc3-00045-g7532b003f0 (Sep 02 2020 - 11:09:16 -0400) DRAM: 8 MiB which means at least everything up to dram_init gets called. > > After adding some debug functions the error appeared and disappeared > when changing the code in function panic(). So my guess is that there is > some alignment problem in the static data section. I investigated this further using the following script while true; do sed -i 's/nop();$/nop(); nop();/g' board/sipeed/maix/maix.c && git commit --amend --no-edit board/sipeed/maix/maix.c && CROSS_COMPILE=riscv64-linux-gnu- make -j$(nproc) && kflash -tp /dev/ttyUSB0 -B bit_mic -b 1500000 u-boot-dtb.bin" done To start this process, create a commit which adds a nop() to board/sipeed/maix/maix.c. On every iteration, this script will amend that commit by adding another nop. I tried up to 65 nops. If the amount of nops is 0, 24, 28, 29, 30, 31, 32, 40, 44, 46, 49, 56, 60, 61, 62, 63, or 64 the board fails to boot. Of these failures, all printed up to "DRAM: ..." except for those with 28, 29, 30, 31, 60, 61, 62, or 64 nops. There is clearly a pattern whith failures occuring at or near (but not always exactly on) multiples of 4, and in the lead-up to multiples of 32. My next line of investigation will be to determine the size and alignment of the various sections based in the failing configurations. I also plan to try enabling more debug info and see if I can trigger this issue by adding some choice no-ops. --Sean
On 9/2/20 11:59 AM, Sean Anderson wrote: > On 9/2/20 8:26 AM, Heinrich Schuchardt wrote: >> After adding some debug functions the error appeared and disappeared >> when changing the code in function panic(). So my guess is that there is >> some alignment problem in the static data section. > > I investigated this further using the following script > > while true; do > sed -i 's/nop();$/nop(); nop();/g' board/sipeed/maix/maix.c && > git commit --amend --no-edit board/sipeed/maix/maix.c && > CROSS_COMPILE=riscv64-linux-gnu- make -j$(nproc) && > kflash -tp /dev/ttyUSB0 -B bit_mic -b 1500000 u-boot-dtb.bin" > done > > To start this process, create a commit which adds a nop() to > board/sipeed/maix/maix.c. On every iteration, this script will amend > that commit by adding another nop. I tried up to 65 nops. If the amount > of nops is 0, 24, 28, 29, 30, 31, 32, 40, 44, 46, 49, 56, 60, 61, 62, > 63, or 64 the board fails to boot. Of these failures, all printed up to > "DRAM: ..." except for those with 28, 29, 30, 31, 60, 61, 62, or 64 > nops. There is clearly a pattern whith failures occuring at or near > (but not always exactly on) multiples of 4, and in the lead-up to > multiples of 32. These patterns cause two different bugs, which I will refer to as the "multiple-of-four" bug and the "periodic-32" bug. The multiple-of-four bug is fixed by [1]. This bug is not present in u-boot/master atm, but I am not sure why. Perhaps adding more drivers which depend on the device tree triggers the behavior. >> On 01.09.20 03:19, Rick Chen wrote: >>> To see if this way can pin down which instruction or the crucial code >>> to cause the bus hang problem. And guess what maybe the root-cause. >>> >>> If you can find the instruction which may cause the bus hang, you can >>> info all-registers and compare the differences between NG and OK. And >>> guess what maybe the root-cause. >> >> Trying to narrow down on the problem I found the following: >> >> The system hangs before arch_cpu_init_dm() is called. > > This is not always the case. On most boots, the following output is > present: > > U-Boot 2020.10-rc3-00045-g7532b003f0 (Sep 02 2020 - 11:09:16 -0400) > > DRAM: 8 MiB > > which means at least everything up to dram_init gets called. This output is symptomatic of the multiple-of-four bug. After applying [1], either a successful boot should take place, or there should be no output at all (corresponding to the periodic-32 bug). >>> >>> Maybe you can try to set a break and access the bus, if the bus access >>> fail, then you re-set a break a bit ahead until the bus access NOT >>> fail. > > Yeah, I was investigating that, however I was unable to get the k210 to > break at 0x80000000. I suspect this may be a problem with openocd, as > the k210 port is rather buggy (e.g. it can cause address misaligned > errors, and sometimes leaves the pc in the debug dection of memory). I > *can* get it to break in the otp (0x88000000), so perhaps I just need to > identify the address before it jumps to U-Boot. When attempting to boot with a U-boot which has the periodic-32 bug, there is no output, even with an early uart and debug logs enabled. I have tried using two versions of openocd to determine the cause. The kendryte openocd [2] supports attaching to either core of the k210, but must be restarted to debug the other core. It also keeps the non-debugged core halted. The riscv openocd [3] only supports debugging core 0. However, it contains numerous bugfixes and improvements which the kendryte openocd does not contain. When attaching the kendryte openocd, the following output (among other things) is printed: Core [1] halted at 0x80015590 due to debug interrupt Core [0] halted at 0x88008c00 due to debug interrupt The core 1's pc is located within _sifive_serial_putc, and this is reflected by the console containing a partially-printed announcement for the first printed initcall. This initcall is initf_bootstage, which is the first initcall after log_init. If openocd is attached to core 1, and it is resumed, then U-Boot boots as normal (in contrast to the behavior exhibited if openocd is not attached). What is more interesting is the pc of core 0. It is located in the boot rom of the K210. According to [4] (and as verified by myself), this address corresponds with the uarths_getc function. This function is only called by isp_run. This means core 0 is stuck in ISP mode, which is used to flash firmware. Attaching a debugger clearly affects the boot process of this core, but I am not sure in what manner. I am attempting to modify the riscv openocd to support multiple cores, but it is slow going (there is a lot of undocumented code with side-effects). --Sean [1] https://patchwork.ozlabs.org/project/uboot/patch/20200905132211.412711-1-seanga2@gmail.com/ [2] https://github.com/kendryte/openocd-kendryte [3] https://github.com/riscv/riscv-openocd [4] https://github.com/kelas/k210-sdk-stuff/blob/master/rom/k210.rom.h
diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig index 0cdcd32adc..4c42dd2087 100644 --- a/board/sipeed/maix/Kconfig +++ b/board/sipeed/maix/Kconfig @@ -44,4 +44,13 @@ config BOARD_SPECIFIC_OPTIONS imply RESET_SYSCON imply SYSRESET imply SYSRESET_SYSCON + imply PINCTRL + imply PINCONF + imply PINCTRL_K210 + imply DM_GPIO + imply DWAPB_GPIO + imply SIFIVE_GPIO + imply CMD_GPIO + imply LED + imply LED_GPIO endif diff --git a/configs/sipeed_maix_bitm_defconfig b/configs/sipeed_maix_bitm_defconfig index 459bf0d530..0b038ff0a1 100644 --- a/configs/sipeed_maix_bitm_defconfig +++ b/configs/sipeed_maix_bitm_defconfig @@ -2,6 +2,8 @@ CONFIG_RISCV=y CONFIG_TARGET_SIPEED_MAIX=y CONFIG_ARCH_RV64I=y CONFIG_STACK_SIZE=0x100000 +# FIXME: Dirty hack to get boot working! +CONFIG_LOGLEVEL=5 # CONFIG_NET is not set # CONFIG_INPUT is not set # CONFIG_DM_ETH is not set diff --git a/doc/board/sipeed/maix.rst b/doc/board/sipeed/maix.rst index b1894f3a6f..3811eac61f 100644 --- a/doc/board/sipeed/maix.rst +++ b/doc/board/sipeed/maix.rst @@ -156,7 +156,7 @@ To run legacy images, use the ``bootm`` command: Load Address: 80000000 Entry Point: 80000000 - $ picocom -b 115200 /dev/ttyUSB0i + $ picocom -b 115200 /dev/ttyUSB0 => loady ## Ready for binary (ymodem) download to 0x80000000 at 115200 bps... C @@ -187,6 +187,66 @@ To run legacy images, use the ``bootm`` command: argv[0] = "<NULL>" Hit any key to exit ... +Pin Assignment +-------------- + +The K210 contains a Fully Programmable I/O Array (FPIOA), which can remap any of +its 256 input functions to any any of 48 output pins. The following table has +the default pin assignments for the BitM. + +===== ========== ======= +Pin Function Comment +===== ========== ======= +IO_0 JTAG_TCLK +IO_1 JTAG_TDI +IO_2 JTAG_TMS +IO_3 JTAG_TDO +IO_4 UARTHS_RX +IO_5 UARTHS_TX +IO_6 Not set +IO_7 Not set +IO_8 GPIO_0 +IO_9 GPIO_1 +IO_10 GPIO_2 +IO_11 GPIO_3 +IO_12 GPIO_4 Green LED +IO_13 GPIO_5 Red LED +IO_14 GPIO_6 Blue LED +IO_15 GPIO_7 +IO_16 GPIOHS_0 ISP +IO_17 GPIOHS_1 +IO_18 I2S0_SCLK MIC CLK +IO_19 I2S0_WS MIC WS +IO_20 I2S0_IN_D0 MIC SD +IO_21 GPIOHS_5 +IO_22 GPIOHS_6 +IO_23 GPIOHS_7 +IO_24 GPIOHS_8 +IO_25 GPIOHS_9 +IO_26 SPI1_D1 MMC MISO +IO_27 SPI1_SCLK MMC CLK +IO_28 SPI1_D0 MMC MOSI +IO_29 GPIOHS_13 MMC CS +IO_30 GPIOHS_14 +IO_31 GPIOHS_15 +IO_32 GPIOHS_16 +IO_33 GPIOHS_17 +IO_34 GPIOHS_18 +IO_35 GPIOHS_19 +IO_36 GPIOHS_20 Panel CS +IO_37 GPIOHS_21 Panel RST +IO_38 GPIOHS_22 Panel DC +IO_39 SPI0_SCK Panel WR +IO_40 SCCP_SDA +IO_41 SCCP_SCLK +IO_42 DVP_RST +IO_43 DVP_VSYNC +IO_44 DVP_PWDN +IO_45 DVP_HSYNC +IO_46 DVP_XCLK +IO_47 DVP_PCLK +===== ========== ======= + Over- and Under-clocking ------------------------ @@ -361,5 +421,5 @@ Address Size Description 0x8801C000 0x1000 riscv priv spec 1.9 config 0x8801D000 0x2000 flattened device tree (contains only addresses and interrupts) -0x8801f000 0x1000 credits +0x8801F000 0x1000 credits ========== ========= ===========
This patch adds the necessary configs and docs for FPIOA and GPIO support on the K210. The board does not boot unless CONSOLE_LOGLEVEL is set to a non-default value . It also boots when the tree is dirty (and CONSOLE_LOGLEVEL is not changed). It also boots when changes are made to the device tree and then committed. I don't know why this happens. These breakages only occur after bf2fb81ad3. Signed-off-by: Sean Anderson <seanga2@gmail.com> --- Changes in v5: - Increase CONSOLE_LOGLEVEL to 5 as a hack to get the board booting again - Patch 05/12 "gpio: sifive: Use generic reg read function" has been superseded by commit 2548493ab4. Changes in v3: - Document pins 6 and 7 as not set Changes in v2: - Remove SPI flash related Kconfig settings board/sipeed/maix/Kconfig | 9 +++++ configs/sipeed_maix_bitm_defconfig | 2 + doc/board/sipeed/maix.rst | 64 +++++++++++++++++++++++++++++- 3 files changed, 73 insertions(+), 2 deletions(-)