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

[Rick Chen]

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.

Thanks,
Rick