MIPS Creator CI20 patches (again)

[Paul Boddie]

On Monday 5. February 2018 00.02.47 Adam Lackorzynski wrote:
> On Fri Feb 02, 2018 at 16:45:13 +0100, Paul Boddie wrote:
> > 
> > There seems to be a "kernel" UART, but the userspace seems to have the
> > configuration details in l4/pkg/bootstrap/server/src/platform for each
> > board. Does the kernel somehow delegate the configuration to the
> > bootstrap component or is there somewhere in the kernel that needs to be
> > changed for the "kernel" UART? It also makes me wonder about how the jdb
> > communications are configured.
> 
> It's the other way around. The booting begins with bootstrap, that's
> where the first output happens. Bootstrap then passes the UART config on
> to Fiasco, i.e. the UART config that is used in bootstrap is also used
> by Fiasco. Do you see the initial output of bootstrap?

No, but the serial output isn't being done reliably in a physical sense, so 
that might be my fault rather than anything the software is doing. Is there 
some kind of assembly language file I should be looking at in the bootstrap 
package, just to see where this all gets started?

In fact, I remembered that the Ben NanoNote has rather awkward requirements 
with regard to where code gets loaded while booting, so I am starting to think 
that I need to figure this out first. Fiasco puts things in the usual place 
for MIPS, but this may conflict with the device bootloader.

Previously, I've followed what others have done, deployed code at some "non-
harmful" address and then copied code into place. This affects things like 
exception vectors which cannot apparently be populated directly (at 
0x80000000) when the code is loaded. There is an actual reason for this, but I 
would have to review various mails and documentation to tell you. But it is 
related to the bootloader.

I'm experimenting with changing the location of the exception vectors, which 
should be possible as long as the EBASE coprocessor register is properly 
supported. I've actually played with this on PIC32MX devices, but I don't know 
how much the Ingenic devices support it. This might then make it possible to 
put the exception handlers in a different place, avoiding those bootloader 
conflicts, and hopefully get the kernel started.

Anyway, that was more than I intended to write. Thanks for following up again!

Paul