[PATCH v6 12/12] riscv: Add FPIOA and GPIO support for Kendryte K210

Fri Sep 18 12:46:45 CEST 2020

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 <seanga2 at 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
>>
> 