fix Raspberry Pi support #621
Conversation
…ions, so use REL instead
|
I haven't had time to fully look over this but a number of changes are incorrect/unnecessary/unwanted. FWIW the arm build hasn't been working since Michal attempted to make it use proper elf files, but prior to that, it was able to boot. I have not had time to look into what was not reverted correctly, but that should've been all that was necessary to get it back to a booting state. |
|
I'm not sure exactly, and would need to test to find out - but it should be in the 2019 timeframe. |
|
Thanks, guys. Ah, the new elf support probably explains why I'm having these reloc issues, so I'll try building some old commits. What was it using before elf files? AROS has used elf for as far as I can remember. |
|
I tried to build commit c720582 from 17 March 2019, since this seems to be the last one that dealt with ARM before adding ELF support, but I get a lot of these kinds of errors. I'm aware that a lot of the changes I made in this PR are unwanted. I will clean that up later. I keep running into endless build errors trying to compile old versions of AROS, so I'm going to give up on trying to get that to compile, and just work from the current version instead. |
|
These "bad pointer" errors that I am getting like |
…printf before screen and serial are initialised
Yes - we had issues getting the toolchain built correctly (the toolchain is generally built to be generic for AROS targets, using the correct flags for specific targets at compile time).
Ok - it was meant more to look at what changed in regards to the RasPI target, causing it to break in the reported ways. |
To clarify - AROS uses "Elf" format, but not real executables. We had discussed using real executables, which is what Michal was attempting to implement for ARM, but eventually he gave up and instead started working on the arm-m68k emulator that takes up his time these days. So the ARM build is in a broken state due to this - its somewhere between the old working build, and using proper executable elf binaries. |
It fails because the kernel has been mapped into virtual memory, but no memory region has been registered to express this, so the asserts correctly declare it is invalid. The kernel should register a region matching the used mappings. |
|
p.s if you have frequent questions, you would be better asking on the linen/slack channel(s) ;) |
|
Thanks. Do you have a link to the Slack channel? |
see https://github.com/aros-development-team/AROS/wiki |
I've ran into plenty of issues trying to get AROS running on a Raspberry Pi 3, so this ongoing PR attempts to fix a few of them.
In binutils, I disabled RELA relocations and use REL instead, since the addends all get ignored during the final link of an ELF file for some reason, breaking a lot of code (notably the PC-relative jumps like non-local "bl" which use these to adjust for the PC prefetch bias).
I am also compiling everything with
-mword-relocations. arch/arm-raspi/boot/elf.c doesn't seem to compute R_ARM_MOVT_ABS relocations properly (frankly, I don't know exactly how these are supposed to work, either), and compiling with the-mword-relocationsflag avoids generating these (uses pool loads instead).The boot process gets quite far, but there are a few
bad pointerandSoftware Failure!errors generated.Here's a log from me running it in qemu. How do I find what code is generating those errors?