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

Tianrui Wei tianrui-wei at outlook.com
Thu May 13 08:50:29 CEST 2021


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


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.


Thanks,

Tianrui


>
> Regards,
> Bin


More information about the U-Boot mailing list