[PATCH v5 11/11] riscv: Add FPIOA and GPIO support for Kendryte K210

[Sean Anderson]

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