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

[Sean Anderson <seanga2@gmail.com>]

[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.

--Sean