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

[Rick Chen]

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

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