01:57:05 jbk: https://www.illumos.org/issues/16572 01:57:05 → BUG 16572: loader should be willing to put modules above 4GB if necessary (New) 02:02:51 It's ultimately all a bit tedious -- it would a lot easier if we were able to get directly to the ELF entrypoint from longmode, rather than bounce through multiboot2 02:06:16 In the oxide arch, we end up in _start(), which is, blessedly, a C function: https://github.com/oxidecomputer/illumos-gate/blob/fc2bcb97f594a97ea281ddc9894a97376329b3c2/usr/src/uts/oxide/os/fakebop.c#L584-L770 02:07:25 which is the ELF entrypoint for "/platform/oxide/kernel/amd64/unix": https://github.com/oxidecomputer/illumos-gate/blob/stlouis/usr/src/uts/oxide/unix/Makefile#L136 02:09:15 Our Oxide-specific boot loader just calls into it with some regular arguments we've agreed as a calling convention: https://github.com/oxidecomputer/phbl/blob/2f8c42da23edc9f100797e3c81f44fb876813061/src/main.rs#L30-L33 02:10:48 I think we could come up with some loader-to-unix object that has the things we need, and use 64bit addresses etc 03:55:11 maybe a stupid question, but IIRC, UEFI (at least on 64-bit systems) is running in 64-bit long mode (everything unity mapping)... are we bouncing down to 32-bit and then back to 64-bit mode somewhere? 04:50:42 jbk: I don't have a specific reference but that's what I assume is happening as part of multiboot2 04:53:57 (that might also be inaccurate; the multiboot2 specification is a mess of bits that have and haven't been altered for 64-bit support) 04:55:49 jbk: Yeah, if you look at multiboot_tramp in boot/efi/loader/arch/amd64/multiboot_tramp.S it seems like we're clearing long mode on the way into dboot etc 04:56:54 dboot is definitely 32-bit code, as per https://www.illumos.org/issues/17548 etc 04:56:54 → BUG 17548: early boot framebuffer reach exceeds grasp (Closed) | https://code.illumos.org/c/illumos-gate/+/4350 07:48:48 jbk one reason is dboot (32-bit), another reason referred is about "some systems not providing memory mapping above 4GB" - I havent seen such systems, and I think it is most likely non-issue today. 07:56:32 starting trough the dboot was done at the time because 1) it was there 2) mb2 at the time did not really provide much support for 64-bit. and it was kind of natural path to take coming from grub and mb1 and having to have all that backwards compatibility and so on... 08:22:29 [illumos-gate] 17743 cw: want time the compiler runs -- Toomas Soome 08:24:04 [illumos-gate] 17728 hasmntopt should take const pointers -- Toomas Soome 13:58:29 i'm wondering since mb2 only seems to begrudingly acknowledge the 64-bit world, if we couldn't just add a second, 64-bit entry point alternative to dboot (efiboot?) that just takes the system pointer, efi memory map, and info about whatever boot modules are present 14:00:25 maybe 'tag' unix in some way to indicate that (section? specially named symbol?) 14:00:46 something that'd otherwise get ignored so existing systems can all work the same 14:00:54 as they do today 14:04:09 this system also interestingly has a setting in its setup to advertise 1 or 2 PCI segments... and I should hopefully have a bit longer access to it, so might be able to do some of the work to support that 14:06:45 I do not think we need another section there, I see no reason why we can not prepare the xboot struct, put things to where they need to be and jump to start, skipping all the dboot. There is no big magic in dboot -- that whole thing there is for case when we *are* in 32-bit protected mode and need to get kernel running. 14:16:21 side note: do we ever set CLASS = 32 when building usr/src/uts/i86pc ? i.e. is the _BOOT_TARGET_i386 no longer relevant (and a leftover of the 32-bit kernel -- independent of the 32/64 bit stuff dboot is doing)? 14:28:17 https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/i86pc/os/startup.c#L415-L419 matches the sh_addr values in unix, but seems to contradict https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/i86pc/os/startup.c#L711-L712 <-- is there some other magic going on, or is the latter comment just wrong? 15:13:38 What happens is, we get PT_LOAD headers, we ignore case where p_vaddr == p_paddr - thats dboot; and then there is a black magic, p_paddr == 0x400000 is text (or we could check for PF_X PF_R instead), p_paddr == 2 * 0x400000 is data (or we could check for PF_X PF_W PF_R) and SHT_NOBITS is bss. (and if p_memsz == 0, its ignored). Thats just plain and simple copy of sections from unix based on elf header data. So the comment is wrong 15:13:38 because data will land at 0xfffffffffbc00000 (and bss follows data by doing bzero() for the size of bss). 15:27:59 ok, so the comment is just wrong (or at least outdated by at least 21 years :P) 15:28:44 (opensolaris is old enough to drink in the US :P) 15:28:49 or i guess will be in june 20:45:11 you're checking the addresses to know what segments are!?!?! 20:52:54 if you do decide to accept AI-assisted contributions, you should at least have some fun with it, like have AI generate a packet trace file for use as a test for "snoop -a" that would make the audio output match the beat from Snoop's Gin & Juice 21:15:26 jbk: you should never see CLASS=32, except possibly for dboot? if it does that? 21:18:36 i suspected as much -- just looking at things (and this is _far_ from the only place) there's a bunch of #ifdefs that are likely never ever defined 21:20:21 as another example: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/tpm/tpm.c#L1545-L1550 21:20:57 the 32bit removal I think just culled it from the build 21:21:14 I try to clean up as I move through things, if it doesn't mess up my diffs 21:21:27 (mostly because I'm reminded I need to put up my tpm2.0 driver for review at some point... just don't have any 1.x ones to ensure they aren't broken) 21:21:54 I don't like automating it because there's historical gold around some of the i386-y bit 21:22:05 comments that should be reworded and moved outside, etc. 21:24:08 even xpv has some gold, where those folks figured out the mysteries