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 _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
