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?
Thanks,
Tianrui
--Sean
