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 <sean...@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.pan...@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