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

[Rick Chen]

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.

Thanks,
Rick

>
> Thanks,
> Rick