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

[Tianrui Wei]

Hi Sean,

On 5/13/2021 3:49 PM, Bin Meng wrote:
> 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?


Out bootrom was at this address, and we were hoping to use SPL as ZSBL 
directly.


>
>> 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?


U-Boot boots alright, but it will stuck when loading the kernel image 
without specific

configurations.


>
> Regards,
> Bin