Re: bootxx needs to fit within 0th track of MBR partition?
Rin Okuyama <[email protected]> Wed, 6 Sep 2023 13:00:41 +0900
| Newsgroups | gmane.os.netbsd.ports.x86-64,gmane.os.netbsd.ports.i386 |
|---|---|
| Message-ID | <CAPSZb0S0_Fg8vLxtfNLRDgW7z2OYmwod2Z1WpQ80+C6Tcu1Vcg@mail.gmail.com> |
Hi, Thank you guys for comments, and sorry for the late reply. The original problem itself has already been fixed by christos@; optimization flags for libi386 was unintentionally missing. However, sparse room for bootxx_ffsv2 is still less than a sector, and fix will be necessary in the near future. I found bootxx works as follows: (1) mbr(8) or BIOS load 1st sector of bootxx into the memory (2) bootxx loads itself by "int 13h" calls (CHS ah:0x02 or LBA ah:0x42) For (2), we use hardcoded 15-sectors (one track for 5" 2HD disk). "int 13h" for old machines may have 1-track restriction, but I still have not found any documentation. Even if single reads had 1-track restriction, it should be OK to use multiple BIOS calls, IMO. Therefore, I *guess* that we can use entire sectors for target filesystems even for old machines, in principle. But this needs careful assembler coding and tests... BTW: On Fri, Aug 25, 2023 at 9:08 PM Tobias Nygren <[email protected]> wrote: > Side note I think there are other issues with boot code built with > clang. For example I've encountered that bootx64.efi hangs for > me when built with clang. I could not reproduce this problem on QEMU with OVMF. Can you please share more details? In my limited experience, I can say printf debugging is useful for efiboot; at least you can find out where it stalls. Thanks, rin