sys and boot sector improvements [TODO]
PerditionC opened this issue · 5 comments
Not yet included:
- SYS should warn if /L is < 0x60 or > 0x200
- SYS could detect kernel file (already present if /BOOTONLY or to be copied else) and cluster size and warn if load might fail
- One of the FAT32 loaders doesn't contain a license header
- The FAT12/FAT16 read buffer address can be accessed with +imm8 addressing now, drop the "word" to optimise this (some magic offsets will change)
- Loaders should set up stack before relocating (magic offsets of the load segment will change)
- Fix comments referring to 640 KiB as a kernel file size limit, this is wrong because we unconditionally relocate to 1FE0h:7C00h (27A00h) so the 640 KiB limit is not relevant
- SYS could detect magic bytes by scanning for them rather than hardcoding magic offsets
Originally posted by @ecm-pushbx in #135 (comment)
- update sys and boot code so sys can extract all necessary offsets without hard coding, possibly by scanning for magic bytes or having the boot sectors have an additional trailer chunk
- possible update is to have sys move files so PC/MS DOS kernel files first two directory entries and physically on disk [not sure if worth the bloat, since can ensure this by sys to a blank disk]
- see if possible to update FAT32 boot code to support both LBA and CHS with same boot sector, may require using more than one sector
merge all changes from kernel sys and boot sectors into sys repo and then make it a submodule of the kernel like share, etc.
- update sys and boot code so sys can extract all necessary offsets without hard coding, possibly by scanning for magic bytes or having the boot sectors have an additional trailer chunk
The current 512-Bytes files per boot sector loader are more compatible and easier to use for other programs, eg my instsect or with dd to write to an image. Albeit, it would be a nice(r) approach to append some trailer. I also did this in #78 for the new exeflat stubs, the stubs have trailing data to point exeflat to where to patch them. But in that case there was no compatibility with other programs to consider.
The unit selection code (/FORCE:BSDRV or /FORCE:BIOSDRV) can be scanned very easily, I do that in instsect already. The FAT12/FAT16 LBA detection (/FORCE:LBA or /FORCE:CHS or /FORCE:AUTO) is also easily scanned.
The loadsegoff is fairly simple to scan for too, just check for a dword matching 60_0000h or 70_0000h and also you can check that there is a jmp far indirect that references the same dword. The check for segment 70h is for boot sector loaders that are modified with the EDR-DOS SYS/boot patches, which changed the default segment too. Eg in https://pushbx.org/ecm/download/edrdos/freedos/drsys35s.zip boot.asm and boot32.asm have the default segment as 70h, but not boot32lb.asm. (It doesn't really matter to SYS because it writes opts->kernel.loadaddr to the variable unconditionally.)
In the OEM boot sector loaders, just scanning for jmp 70h:0 or jmp 70h:200h should be sufficient to find the far branch to the next stage.
The kernel name is okay to leave as a magic offset I think. In instsect I chose to scan for potentially multiple filenames (up to 4 are supported by default) just using a heuristic for valid filenames, which works nicely, but isn't really needed for SYS.
- see if possible to update FAT32 boot code to support both LBA and CHS with same boot sector, may require using more than one sector
lDOS boot32 does this, it is a combined LBA and CHS, 8086-clean loader. It uses its "FSIBOOT4" stage in the FSINFO sector's large reserved area, which I believe has never been used by anyone else. The current revision has a _COMPAT_FREEDOS mode which allows to load kernel.sys. The addressing and relocation differs from the kernel's current loaders, but the protocol matches what I consider essential to FreeDOS load. The exact same FSIBOOT4 stage can be used by different loader first stages, to load RxDOS.3, lDOS/lDebug, MS-DOS v7.10, or PC-DOS v7.10, all changes for these protocols are confined to the first stage. That includes the addresses to load at and transfer control to, as well as the filenames to search for.
Ah, I think in the PR I forgot that not all of the boot loader sources use the appropriate cpu 8086 or cpu 386 NASM directives. So add that to the pile.
Also relevant: #94