On 9/18/20 3:37 AM, Leo Liang wrote: > Hi Sean, > > On Mon, Sep 14, 2020 at 11:02:06AM -0400, Sean Anderson wrote: >> This patch adds the necessary configs and docs for FPIOA and GPIO support >> on the K210. >> >> Signed-off-by: Sean Anderson <sean...@gmail.com> >> --- >> >> Changes in v6: >> - Add dependency on "riscv: Clean up timer drivers", which fixes the bugs >> discovered earlier. >> > > I am curious about the weird bug you found in v5. > Is there any new discovery on the cause or how the bug is resolved ?
I don't really know the exact mechanism of the bug. I noticed that the timer series fixed it because I was unable to reproduce the bug (by adjusting the size of the binary with nops) with that series applied, but I was still able to reproduce it with it unapplied. I suspect that the effects of the bug are caused by something unintentionally modifying the device tree. Most modifications to the device tree will not cause a boot to fail, because the k210 device tree is relatively large and contains many unused devices and properties. I don't know why U-Boot crashes instead of just resulting in an error. Another reason I suspect it is due to the device tree is that I can also reproduce this bug with the wdt series applied (and without the timer series). To determine the direct cause of this bug, I would need to add some features to openocd to let it debug multiple cores at once. The k210 uses an older debug device, and openocd (even the kendryte fork) only supports debugging one hart at once. This bug only occurs when both harts are running at once; I can take a buggy U-Boot, jump to _start, and it will boot fine. > > You have mentioned that any modification to init_sequence_f or > init_sequence_r would lead to a successful boot. Yeah. In general, the buggy sizes/alignments are fairly sparse. Usually, a buggy size occurs every 64 bytes or so. > Is this related to "riscv: Clean up timer drivers" and thus resolve the bug ? Sorry, I'm not sure what you mean by "this" in that sentence. --Sean >> Changes in v5: >> - Increase CONFIG_LOGLEVEL to 5 as a hack to get the board booting again >> >> 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 ++++++ >> doc/board/sipeed/maix.rst | 64 +++++++++++++++++++++++++++++++++++++-- >> 2 files changed, 71 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/doc/board/sipeed/maix.rst b/doc/board/sipeed/maix.rst >> index efcde9aebf..90ef70b7cf 100644 >> --- a/doc/board/sipeed/maix.rst >> +++ b/doc/board/sipeed/maix.rst >> @@ -199,7 +199,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 >> @@ -230,6 +230,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 >> ------------------------ >> >> @@ -404,7 +464,7 @@ 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 >> ========== ========= =========== >> >> Links >> -- >> 2.28.0 >> >
