MIPS Creator CI20 patches (again)
paul at boddie.org.uk
Mon Feb 5 01:43:55 CET 2018
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!
More information about the l4-hackers