Fiasco.OC-UX on MIPS?

[Adam Lackorzynski]

Hi Paul,

On Fri Aug 30, 2019 at 13:43:10 +0200, Paul Boddie wrote:
> 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:
>     ...

Thanks for the update!
Indeed it seems to work for me without any adjustments both with mips32
on malta and with mips64 on the boston platform (both with a
pretty recent QEMU). I probably using the "wrong" compiler. I'll try to
follow up here once sid's cross compilers are installable again.



Adam