Fiasco.OC-UX on MIPS?
paul at boddie.org.uk
Wed Aug 28 16:07:50 CEST 2019
On Thursday 22. August 2019 15.34.05 Paul Boddie wrote:
> On Thursday 22. August 2019 14.15.55 Matthias Lange wrote:
> > Did you set the correct qemu options in your Makeconf.boot? And you may
> > have to specify the correct platform type because the default afik
> > 'boston', like
> > make O=mybuild qemu PT=malta E=hello
> > Also check the qemu cmdline that it contains "-M malta".
> I set the qemu options on the command line (noted below), but I imagine that
> Makeconf.boot would also be a reasonable place. I tend to forget about all
> these different files after a while.
> In the Fiasco and L4Re "make config" procedures, I did set the platform type
> to Malta, but it seems that you are suggesting also indicating this on the
> command line, too.
Just a quick update: I have since tried running qemu via the Makefile with the
machine and console output parameters indicated using QEMU_OPTIONS; the
emulator does start up and run code at the expected bootstrap locations but it
doesn't seem to produce any output.
make O=mybuild qemu E=hello QEMU_OPTIONS='-nographic -M malta'
I suspect that there is some kind of restarting happening because when using
the monitor to check the program counter, it showed the bootstrap code start
address even after being allowed to run for a while. I guess I could
investigate debugging options in the bootstrap code, especially since I was
doing that with real hardware last year.
The bootstrap address is, of course, defined in the following file:
It is set by this definition:
And it appears to be this address that appears in the qemu monitor.
> > Qemu is always a good start. It allows very quick development and test
> > cycles. In the end you of course have to test on hardware.
> If I can get it to work, maybe it will be more useful than UX, although I
> did find UX to be fairly useful on my IA32 machine.
I will add that I have been able to build Fiasco to run as a process in my
MIPS GNU/Linux environment, having hopefully figured out usable linker
options, modules, and so on. In order to satisfy the kernel, I have provided
some emulated support for privileged registers and the memory management unit,
although the latter will need integrating with (or be replaced by) host-level
memory mapping operations under normal operation.
Currently, I am working through adding the UX functionality as it is needed
and, with some physical memory having been provided for the kernel (using mmap
and indicating memory descriptors), I now need to handle signals and jump to
the appropriate exception handlers, starting off with handling the timer
interrupt being produced by the irq0 program.
More information about the l4-hackers