freebsd
Add support for 64-bit machines with 32-bit UEFI implementations
Some machines (mostly baytrail notebooks) have 64-bit capable cpus but are stuck on 32-bit uefi firmware, with so CSM.
Add support for them by making the amd64 loader compile itself again with DO32=1, (see the amd64 Makefile.inc) all of the extra ia32 specific code is in loader/arch/amd64/ia32. The loader can be disabled using MK_LOADER_IA32.
Tested on qemu and the Acer one 10 s1002 Also cross-compiled to armv6 to make sure nothing broke.
Cant reproduce build errors locally. Maybe this can be fixed by using __aligned to force padding? Edit: Instead of casting
Clang seems to ignore -Wint-to-pointer-cast and -Wpointer-to-int-cast when -m32 is specified. Can reproduce errors with gcc toolchain.
This makes it easier for me to look at this and to have a conversation. I got too busy last time and naybe this way we'll keep momentum.
OK. I've ordered an inexpensive laptop to see if I can use it to test this. Generally I like this, but it's all one commit and I've left a few comments, but I'm thinking about others Some of this I think that I can land quickly, but other bits need a little refinement. If things are broken down better I can do that. I'll tag a couple of things first.
Alright, I split everything into a total of 5 commits:
- Allow overriding NEWVERSWHAT
- Add the LOADER_IA32 build option
- Add libefi32
- The main commit
- Script changes, copy the ia32 loader
I put LOADER_IA32 on its own since it doesn't really fit with adding libefi32. Also about the comment in defs.mk, I ended up moving the comment explaining DO32 up to its first use.
Of course, let me know if you want any of these reverted, thanks!
I'll take a look at this. IIRC, I can use qemu-system-x86_64 to test this if I load the i386 EDKII firmware, right? Thanks for the updates.
IIRC, I can use qemu-system-x86_64 to test this if I load the i386 EDKII firmware, right?
Yea, thats how I did it
Just a little cleanup: Use NULL instead of 0. Also, put the 32-bit compatibility fixes in their own commit.
I've changed all of the __uefi64__ to __i386__ and fixed the merge conflicts, I also updated the linker script stuff in accordance with 5b3b9a5. I added my name to the copyright notice at the top of the amd64_tramp32.S file since I rewrote most of it, let me know if you dont what that.
Also, thers a typo at https://github.com/freebsd/freebsd-src/blob/main/stand/liblua/lutils.h#L37 and I have no idea why it causes the 32-bit loader to crash, but not the 64-bit one, probably some linker weirdness.
Edit: Oh, I didn't realize I had to request a review manually.
Wouldn't it just make a set called _LUA_COMPILE_SET instead of Xlua_compile_set
As long as the set isn't accessed outside the macros, there shouldn't be any problems
Of course in our case, it is causing problems since we objcopy -j set_Xlua_compile_set
I was actually interested in finding out why it only crashed on the 32-bit loader, turns out its fairly straightforward.
With the 32-bit loader, the addend is expected to be present in the set_Xlua_compile_set section, which doesn't exist in this case. The address this section is expected to start at is just full of uninitialized data, so when LUA_FOREACH_SET is used we end up jumping to some garbage and crashing. With the 64-bit loader we get the addend from the relocation entry, so thats not a problem.
Ah, also, while looking into this I noticed that the i386 script I re-added wasn't up to date with d024bc7, I'll check the rest of the script and push a fix soon.
OK. Another round of comments. Apart from the style nits that the style checker highlighted (which I gave advice on), I have worries about uintptr_t only being 4 bytes and whether or not that's a problem.
Ok, I've addressed the comments but I don't think I'll push yet as it looks like there's still some discussion to be had.