Minimal Linux Bootloader debugging story

I did a kernel bootstrap (and got snatched by other projects), I used the hardware USB debugging capability to trace the boot process. Basically, the UEFI BIOS fire up my kernel image, I spit out debugging stuff on the UEFI console until the UEFI to kernel image handover where I do switch to tracing using USB hardware debugging, you need a 2nd computer in order to get the trace of course.

I do suggest to use that. Careful, The AMD mantisse USB controller has a bug in it debug facility (CPU and chipset) and I had to work around it.

That blast from the past and welcome to the 80's ! The 0x87 BIOS service is used to perform the memcpy() from real mode. You might think it is just 3 arguments! But not in that good old days of 1987++ it was all much more convoluted fun! The API has so strange format because it tells you to construct two segment descriptor entries including correct segment attributes. The structure of that buffer is a hack that allows BIOS to create more entries internally (SS/CS? descriptors likely) and use whole buffer as a new GDT which will be used for a copy in protected mode stub. So your destination on SI+0x18 and source SI+0x10 are in fact two GDT entries which BIOS will just use for REP MOVSD/MOVSW. And because you are on 386+ CPU, yes you can use full 32-bit address (in SI+0x17/SI+0x1E) If you are wondering about the detailed format, check data segment descriptor format in AMD or Intel documentation. The max size to copy in CX reg is 0x8000*2 bytes, but this is likely due to the 80286 segment limit which was 64K. It may just work on 386 with 128K, but I would not count on it. Keep the SI+0x16/SI+0x1D zero -> Don't touch D/B bit nor the G bits. You can consult Ralf's brown interrupt list for further details about this INT 0x15 AH=0x87 call. Rudolf