pushbx wiki

User Tools

Site Tools

Trace:
blog:pushbx:2022:1107_ldos_boot_loader_review

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
blog:pushbx:2022:1107_ldos_boot_loader_review [2022-11-07 20:40:59 +0000 Nov Mon] – [The lDebug bug] ecmblog:pushbx:2022:1107_ldos_boot_loader_review [2022-11-13 14:21:17 +0000 Nov Sun] (current) – [read_sector hardening, optimisations] code format register names ecm
Line 40: Line 40:
 In any case, today I noticed that the ever-crucial read_sector function of ldosboot and also lDebug could be optimised a bit. The savings were 3 bytes in the FAT12 and FAT16 and FAT32 loaders and 5 bytes in the initial loader. What actually made me stumble on this was a vaguely recalled comment that there are ROM-BIOS implementations of the LBA extensions that require ''es'' to be set to the buffer segment, even though for the extensions the buffer address is supposed to be passed in the disk access packet. In any case, today I noticed that the ever-crucial read_sector function of ldosboot and also lDebug could be optimised a bit. The savings were 3 bytes in the FAT12 and FAT16 and FAT32 loaders and 5 bytes in the initial loader. What actually made me stumble on this was a vaguely recalled comment that there are ROM-BIOS implementations of the LBA extensions that require ''es'' to be set to the buffer segment, even though for the extensions the buffer address is supposed to be passed in the disk access packet.
  
-Cue my surprise at finding that setting es unconditionally, before the LBA or CHS dispatching, actually saved a few precious bytes! This is because we previously pushed the input bx (data target segment) onto the stack and later loaded that into es, whereas es was not used other than to hold that exact value. So early on in read_sector we now do ''mov es, bx'' and leave it at that.+Cue my surprise at finding that setting ''es'' unconditionally, before the LBA or CHS dispatching, actually saved a few precious bytes! This is because we previously pushed the input ''bx'' (data target segment) onto the stack and later loaded that into ''es'', whereas ''es'' was not used other than  to hold that exact value. So early on in read_sector we now do ''mov es, bx'' and leave it at that.
  
 During adaptation of this patch to the initial loader and the test status writer kernel we had to carefully consider the different paths. In addition to the plain LBA read and CHS read, both of them also have a "sector segment" assisted read (again LBA and CHS). That means when a data boundary error (code 09h) is returned constantly, the read is done into the aligned "sector segment" and then copied to the target. In addition to that, the test writer also has write functions for all four cases: LBA, LBA sectorseg, CHS, and CHS sectorseg. During adaptation of this patch to the initial loader and the test status writer kernel we had to carefully consider the different paths. In addition to the plain LBA read and CHS read, both of them also have a "sector segment" assisted read (again LBA and CHS). That means when a data boundary error (code 09h) is returned constantly, the read is done into the aligned "sector segment" and then copied to the target. In addition to that, the test writer also has write functions for all four cases: LBA, LBA sectorseg, CHS, and CHS sectorseg.
blog/pushbx/2022/1107_ldos_boot_loader_review.1667853659.txt.gz · Last modified: by ecm