Fiasco.OC-UX on MIPS?

[Paul Boddie]

On Thursday 29. August 2019 12.31.49 Paul Boddie wrote:
> On Wednesday 28. August 2019 16.47.31 Sarah Hoffmann wrote:
> > On 8/28/19 4:07 PM, Paul Boddie wrote:
> > > make O=mybuild qemu E=hello QEMU_OPTIONS='-nographic -M malta'
> > 
> > You must also add the CPU type for Mips QEMU. For Mips 32 R2 this would
> > be:
> >   -M malta -cpu P5600
> > 
> > (Unrelated, I usually also set: -nographic -monitor none -serial stdio
> > That gives you the output directly on the console, no extra windows.)
> 
> This is very useful to know. I will give it a try and report back on the
> outcome.

Well, the short story is that I got it to work, so many thanks are due for the 
help. Of course, had I looked at the Makeconf.boot.example file, I would have 
learned about the necessary -cpu option, but that was not the only obstacle 
here.

(The -serial stdio option is apparently the default, but with qemu having so 
many options and switches, I imagine that it is worth specifying in case 
defaults change or option combinations have side-effects.)

What I found was that the bootstrap code was not completing. I added the -S 
option to qemu to stop the CPU at start-up time, and I used the -s option to 
set up remote debugging. Then, I ran gdb in another terminal, using the 
following commands in the gdb session:

target remote localhost:1234
set architecture mips:isa32r2
hbreak *0x802d0000
c

Using the si command to step through the code, it appeared that execution 
failed at the point where a load was first made relative to the gp register. 
Using the info registers command, I could see that the initialisation of this 
register was not done properly. And looking at the registers at the start of 
bootstrap routine execution, I could see that t9 was being used to initialise 
gp but had not been set up.

If this sounds familiar it is because there were similar issues with other 
assembly language routines that I ended up patching to run L4Re on the 
different Ingenic devices I have been using. However, I never needed to patch 
this code. An explanation for this might be that on the actual hardware, U-
Boot is involved and it might well initialise t9 when jumping to the bootstrap 
code. Here, the CPU firmware does not set up t9.

Previously, it was noted that other compilers had been used to develop L4Re 
for MIPS platforms, and I suspect that there must be a difference in the 
behaviour of the .cpload macro between the assemblers employed by these 
compilers. With my Debian-provided GCC toolchains, .cpload doesn't seem to be 
setting up t9, and it may be that it will only do so if there is a frame 
declared, which is not the case in the code affected by this problem (in the 
different places in L4Re).

(I would have to remind myself about what the .cp* macros actually do because 
I don't remember at this point in time.)

So maybe the approach for initialising t9 could be reviewed so that it is not 
toolchain-specific. Here, as before, I ended up doing something like this:

_start:
    lui $25, %hi(_realstart)
    ori $25, $25, %lo(_realstart)
_realstart:
    ...

As for the eventual outcome, I managed to get the payload working with qemu 
which is encouraging, although the performance didn't seem particularly great. 
I imagine that the performance might improve if and when qemu realises that 
most of the code can just run directly on the hardware, and the just-in-time 
compilation should figure this out, so perhaps more testing is needed.

Thanks once again for the help!

Paul