Quantcast

FAT32 CHS boot sector problems since we introduced FAT32 LBA support?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FAT32 CHS boot sector problems since we introduced FAT32 LBA support?

Eric Auer-3

Hi everybody,

apparently the same SYS update which introduced FAT32 LBA support also
broke FAT32 CHS support: On Dimitris' PC, CHS based FAT32 boot always
fails, but his BIOS lacks LBA support. After installing MBR-based disk
drivers to add LBA support and support for 4 instead of 2 harddisks,
FreeDOS boots fine with modern FAT32 LBA boot sectors. Before that, he
had to use ancient CHS-only-for-FAT32 SYS to get a working boot sector.

I was busy trying to find out what broke and when, but cannot find it.
Maybe you can help me out here... :-)

- old SYS sets drive number to -1 but it gets overwritten on boot anyway

- new SYS sets drive number to 0x80 but it gets overwritten on boot, too

- new SYS uses signed byte to word comparison in cluster code (fff fff8
  versus fff -8) but source code is unchanged, maybe a NASM auto tune?)

- r751 moves the load location far pointer to inside the code, while it
  was at +5a in the variable area before. Not sure why that was changed?

Apparently both good and bad are AFTER this diff, so that should be
safe? The r321 to r343 patch makes CHS calculations small but obscure:

> https://sf.net/p/freedos/svn/343/tree//kernel/trunk/boot/boot32.asm?diff=321

This leaves the main "calculate parameters at runtime, instead of using
SYS to hardcode them" patch as suspicious change. We have this patch to
keep FAT32 partitions bootable even when you resize them with 3rd party
tools. Of course the patch adds yet more obscure code to the boot sect:

> https://sf.net/p/freedos/svn/652/tree//kernel/trunk/boot/boot32.asm?diff=382

Note that this r382 to r652 patch also drops the last call of "print",
so we could drop that function to gain some space for making the code
a bit less unreadable by "un-optimizing" some bits. Apparently somebody
simply forgot to drop print after dropping the last place using it ;-)

Not sure why, but the patch also moves around the offsets of 4 variables
by 4 bytes each: fat_start, data_start, fat_secmask, fat_secshift, which
makes the before / after the patch situation a bit harder to "diff" now.

The basic function of the patch is to add some code after the setup of
stack, segments and registers and relocation to 1FE0:xxxx, but before
the first call to "find sector for cluster" and "read sector from disk"
after which the root directory is scanned and, when a kernel is found,
the kernel file is loaded by cluster chain:

dword fat start [+5E] = DI:SI = dword hidden [+1c] + word reserved [+0e]

DI = DI + (byte fats [+10] * word sec per fat HIGH [+26])
[+62] = DX:AX = (byte fats [+10] * word sec per fat LOW [+24]) + DI:SI

word sec mask [+66] = CX ... = (AX >> 2) - 1
AX = 1 ...
do
  CX >>= 1
  AX++
while CX not 1
byte sec shift [+68] = AL

(the above is my attempt to summarize what the code actually does, see
the source code for the description of what it wants to do - as said,
I fail to see a problem here, but the symptom still is a failed boot!)

Thanks for helping out!

Cheers, Eric

PS: Of course the boot sector stores DL to byte drive [+40] before it
starts juggling with DX:AX, so that value seems to be safe as well.


------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FAT32 CHS boot sector problems since we introduced FAT32 LBA support?

Jayden Charbonneau-2
If it comes down to it,one could simply create a config option for the LBA support.By default,LBA would be enabled.If the user experiences issues booting,or if it detects an issue booting,it would then revert to the old SYS update code,grouped as a function or something of the liking.

On Sat, Aug 20, 2016 at 8:28 PM, Eric Auer <[hidden email]> wrote:

Hi everybody,

apparently the same SYS update which introduced FAT32 LBA support also
broke FAT32 CHS support: On Dimitris' PC, CHS based FAT32 boot always
fails, but his BIOS lacks LBA support. After installing MBR-based disk
drivers to add LBA support and support for 4 instead of 2 harddisks,
FreeDOS boots fine with modern FAT32 LBA boot sectors. Before that, he
had to use ancient CHS-only-for-FAT32 SYS to get a working boot sector.

I was busy trying to find out what broke and when, but cannot find it.
Maybe you can help me out here... :-)

- old SYS sets drive number to -1 but it gets overwritten on boot anyway

- new SYS sets drive number to 0x80 but it gets overwritten on boot, too

- new SYS uses signed byte to word comparison in cluster code (fff fff8
  versus fff -8) but source code is unchanged, maybe a NASM auto tune?)

- r751 moves the load location far pointer to inside the code, while it
  was at +5a in the variable area before. Not sure why that was changed?

Apparently both good and bad are AFTER this diff, so that should be
safe? The r321 to r343 patch makes CHS calculations small but obscure:

> https://sf.net/p/freedos/svn/343/tree//kernel/trunk/boot/boot32.asm?diff=321

This leaves the main "calculate parameters at runtime, instead of using
SYS to hardcode them" patch as suspicious change. We have this patch to
keep FAT32 partitions bootable even when you resize them with 3rd party
tools. Of course the patch adds yet more obscure code to the boot sect:

> https://sf.net/p/freedos/svn/652/tree//kernel/trunk/boot/boot32.asm?diff=382

Note that this r382 to r652 patch also drops the last call of "print",
so we could drop that function to gain some space for making the code
a bit less unreadable by "un-optimizing" some bits. Apparently somebody
simply forgot to drop print after dropping the last place using it ;-)

Not sure why, but the patch also moves around the offsets of 4 variables
by 4 bytes each: fat_start, data_start, fat_secmask, fat_secshift, which
makes the before / after the patch situation a bit harder to "diff" now.

The basic function of the patch is to add some code after the setup of
stack, segments and registers and relocation to 1FE0:xxxx, but before
the first call to "find sector for cluster" and "read sector from disk"
after which the root directory is scanned and, when a kernel is found,
the kernel file is loaded by cluster chain:

dword fat start [+5E] = DI:SI = dword hidden [+1c] + word reserved [+0e]

DI = DI + (byte fats [+10] * word sec per fat HIGH [+26])
[+62] = DX:AX = (byte fats [+10] * word sec per fat LOW [+24]) + DI:SI

word sec mask [+66] = CX ... = (AX >> 2) - 1
AX = 1 ...
do
  CX >>= 1
  AX++
while CX not 1
byte sec shift [+68] = AL

(the above is my attempt to summarize what the code actually does, see
the source code for the description of what it wants to do - as said,
I fail to see a problem here, but the symptom still is a failed boot!)

Thanks for helping out!

Cheers, Eric

PS: Of course the boot sector stores DL to byte drive [+40] before it
starts juggling with DX:AX, so that value seems to be safe as well.


------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


------------------------------------------------------------------------------

_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FAT32 CHS boot sector problems since we introduced FAT32 LBA support?

Eric Auer-3

Hi Jayden,

both SYS (which puts boot sectors on drives) and the kernel
already automatically detect LBA support. They both also
already have options to manually select CHS or LBA. However,
some old computers do not have LBA support. People with old
computers must use CHS. The support for boot from FAT32 disk
on CHS seems broken. My question is: Who can find the bug in
our FAT32 CHS boot sector? The bug started when we removed
the need to pre-compute some values in SYS. The pre-computed
values mean that boot broke when you moved or resized FAT32
partition. The improved but buggy version was introduced at
the same moment when FAT32 LBA boot support was introduced.
I hope that that clarifies my question.

Eric

> If it comes down to it, one could simply create a config option for the LBA
> support. By default, LBA would be enabled. If the user experiences issues
> booting, or if it detects an issue booting, it would then revert to the old
> SYS update code, grouped as a function or something of the liking.



------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FAT32 CHS boot sector problems since we introduced FAT32 LBA support?

Jayden Charbonneau-2
I will look into it.Not sure if I will find the bug,as ASM isn't my strong suit,but I'm sure I could probably find something.

I'll reply with my results if I find anything.

Best,Jayden.

On Thu, Sep 1, 2016 at 6:28 AM, Eric Auer <[hidden email]> wrote:

Hi Jayden,

both SYS (which puts boot sectors on drives) and the kernel
already automatically detect LBA support. They both also
already have options to manually select CHS or LBA. However,
some old computers do not have LBA support. People with old
computers must use CHS. The support for boot from FAT32 disk
on CHS seems broken. My question is: Who can find the bug in
our FAT32 CHS boot sector? The bug started when we removed
the need to pre-compute some values in SYS. The pre-computed
values mean that boot broke when you moved or resized FAT32
partition. The improved but buggy version was introduced at
the same moment when FAT32 LBA boot support was introduced.
I hope that that clarifies my question.

Eric

> If it comes down to it, one could simply create a config option for the LBA
> support. By default, LBA would be enabled. If the user experiences issues
> booting, or if it detects an issue booting, it would then revert to the old
> SYS update code, grouped as a function or something of the liking.



------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


------------------------------------------------------------------------------

_______________________________________________
Freedos-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Loading...