search

ghaerr / elks

Embeddable Linux Kernel Subset - Linux for 8086
Other
1.02k stars 108 forks source link

regression: ELKS does not boot after this month changes, ELKS...*****1! #674

Closed pawosm-arm closed 4 years ago

pawosm-arm commented 4 years ago

I wanted to verify recent ARP and ktcp changes, unfortunately, ELKS does not boot, it only prints:

ELKS...*****1!
Press key
ghaerr commented 4 years ago

Hello @pawosm-arm,

The last time anything was changed in the boot sector code was on May 4, I think you have booted successfully since then correct?

The "*" mean sector is read, and "1!" is an exception condition (error return AX=1) from the BIOS, usually due to can't read sector. Can you verify or perhaps try a different floppy disk to make sure the floppy sector is OK?

pawosm-arm commented 4 years ago

Wait, I forgot about one detail. I've changed XT-IDE controller. In theory identical (and it appears so for FreeDOS), in practice, it may not be the case. Closing for now as I need to investigate this.

pawosm-arm commented 4 years ago

Can you verify or perhaps try a different floppy disk to make sure the floppy sector is OK?

I'm not booting from floppy.

pawosm-arm commented 4 years ago

Problem solved with some help from probe.bin, ELKS boots again. Two lo-tech 8-bit XT-IDE controllers, in theory, they both should be the same thing, in practice, probe.bin shows different geometry for the same CF card on both! It's amazing that FreeDOS with FAT filesystem is immune to changes like that!

ghaerr commented 4 years ago

It's amazing that FreeDOS with FAT filesystem is immune to changes like that!

That is amazing. I wonder if DOS does its own geometry calculations differently from the BIOS. ELKS uses only CHS and the BIOS for accessing the disk and disk geometry.

If you're going to be testing ARP and/or ethernet, please pull down the latest tree, I just found an ARP bug that yesterdays commit broke.

Mellvik commented 4 years ago

This is indeed fascinating - not the least because the drive geometry is in the CF-card. And - even thought the CF card parameters are changeable with the right tool, the drive geometrydata are not. It took me a lot of time realizing this a while back via Z80 assembly coding and a lot of head scratching.

That said, DOS does NOT use the BIOS CHS params. When I use CF cards (typically 512MB) with the COMPAQ, there is no matching drive type, so I choose one with the same # of sectors per track (and at least the same # of heads), so the machine will boot. DOS apparently uses the CHS from the partition table, which is usually preloaded on CF cards. SO while the BIOS setup thinks the drive is 318MB, DOS happily use all 512MB...

--Mellvik

  1. jul. 2020 kl. 01:22 skrev Gregory Haerr notifications@github.com:

 It's amazing that FreeDOS with FAT filesystem is immune to changes like that!

That is amazing. I wonder if DOS does its own geometry calculations differently from the BIOS. ELKS uses only CHS and the BIOS for accessing the disk and disk geometry.

If you're going to be testing ARP and/or ethernet, please pull down the latest tree, I just found an ARP bug that yesterdays commit broke.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.