[PATCH V4 2/2] riscv: board: Support OpenPiton SoC

[Bin Meng]

Hi Tianrui,

On Thu, May 13, 2021 at 2:50 PM Tianrui Wei <tianrui-wei at outlook.com> wrote:
>
> Hi Bin,
>
> On 5/13/2021 2:32 PM, Bin Meng wrote:
> > Hi Tianrui,
> >
> > On Thu, May 13, 2021 at 1:07 PM Tianrui Wei <tianrui-wei at outlook.com> wrote:
> >> Hi Sean,
> >>
> >> On 5/13/2021 1:14 AM, Sean Anderson wrote:
> >>> [snip]
> >>>
> >>>> On 5/8/2021 11:14 PM, Sean Anderson wrote:
> >>>>> On 5/8/21 12:57 AM, Tianrui Wei wrote:
> >>>>>> On 5/7/2021 9:03 PM, Sean Anderson wrote:
> >>>>>>> On 5/6/21 11:48 PM, Tianrui Wei wrote:
> >>>>>>>> On 5/7/2021 11:41 AM, Sean Anderson wrote:
> >>>>>>>>> On 5/6/21 11:28 PM, Tianrui Wei wrote:
> >>>>>>>>>> On 5/7/2021 11:15 AM, Sean Anderson wrote:
> >>>>>>>>>>> On 5/6/21 11:06 PM, Tianrui Wei wrote:
> >>>>>>>>>>>> On 5/7/2021 10:32 AM, Sean Anderson wrote:
> >>>>>>>>>>>>> Please use a log without debug uart.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> So this is the part where it was a little confusing. Disabling
> >>>>>>>>>>>> debug uart acutally doesn't work for some reason, so we had to
> >>>>>>>>>>>> keep it open. Will submit another patch if we got it working
> >>>>>>>>>>>> with debug uart turned off.
> >>>>>>>>>>> This is a bit of a strange request, but can you try adding
> >>>>>>>>>>> some nops()
> >>>>>>>>>>> (around 10-30) to some function (e.g. board_init). I've been
> >>>>>>>>>>> having
> >>>>>>>>>>> alignment problems in k210, so it could be something similar.
> >>>>>>>>>>>
> >>>> I was wondering if you have any idea what may cause the alignment
> >>>> problems, we're also hitting it constantly and adding nops seems to
> >>>> have no impact so far.
> >>> I have no idea :)
> >>>
> >>> If adding nop()s doesn't solve it, it may not be an alignment problem.
> >>> You can also try switching from -Os to -O2, which should move things
> >>> around a bit.
> >>>
> >>> My attempts to dig into this have been stymied by the poor debugging
> >>> tools for the k210. The upstream openocd port only supports debugging
> >>> hart 0. While Canaan's fork supports debugging both harts, you must pick
> >>> the one to debug when launching the debugger. And both debuggers are
> >>> very buggy themselves.
> >>>
> >>> The other problem on the k210 at least is that the typical failure mode
> >>> (trying to read from unaddressable/unmapped addresses) hangs the bus.
> >>> This also has the tendancy of hanging the jtag debug port.
> >>
> >> I did try to switch from -Os to -O2, and it didn't help either. I've
> >> also encountered
> >>
> >> the same debugger situation unfortunately, so I have not much luck
> >> finding the
> >>
> >> faulty instruction either.  Maybe we should bring this issue up with the
> >> others along
> >>
> >> the compilation error?
> > Sorry I lost the track. What problems are you seeing?
>
>
> There are two issues we're talking about.
>
> The first issue is a compilation issue, where CONFIG_SYS_TEXT_BASE
> cannot be set to a high address, otherwise the linker will error. The
> error messages are as follows
>

Why do you need to set it to a high address?

>
> common/built-in.o: in function `malloc_trim':
> /u-boot/common/dlmalloc.c:2236:(.text.malloc_trim+0x7e): relocation
> truncated to fit: R_RISCV_PCREL_HI20 against `.LANCHOR0'
> common/built-in.o: in function `free':
> /u-boot/common/dlmalloc.c:1603:(.text.free+0x62): relocation truncated
> to fit: R_RISCV_PCREL_HI20 against `.LANCHOR3'
> common/built-in.o: in function `malloc_extend_top':
> /u-boot/common/dlmalloc.c:1124:(.text.malloc+0x284): relocation
> truncated to fit: R_RISCV_PCREL_HI20 against `.LANCHOR3'
> scripts/Makefile.spl:463: recipe for target 'spl/u-boot-spl' failed
> make[1]: *** [spl/u-boot-spl] Error 1
> Makefile:1904: recipe for target 'spl/u-boot-spl' failed
> make: *** [spl/u-boot-spl] Error 2
> make: *** Waiting for unfinished jobs....
>
> With the qemu_riscv64_spl_defconfig on u-boot HEAD and toolchain of
> xpack-riscv-none-embed-gcc-10.1.0-1.1, only changing
> CONFIG_SPL_TEXT_BASE to 0xfff00000000.
>
>
> The second problem we're seeing is that u-boot can only successfully
> boot linux with a set of certain configuration options. In our case, we
> had to explicitly enable many irrelevant features and turn on uart debug
> for linux to boot, otherwise uboot will be stuck. Sean suspected there
> may be some alignment issues.
>

Does U-Boot boot, or were you talking about using U-Boot to boot Linux
kernel and saw some random crash of U-Boot or Linux?

Regards,
Bin