Hello Paul,
I should have asked that question before all : is your CF card partitioned ?
In the boot sector, the 'disk_read' procedure computes the CHS for the
BIOS routines from the absolute sector number.
But today that procedure does not offset that number based on the
partition absolute first sector (it is planned for issue #199).
So it cannot work on a partitioned disk, because even if you force the
drive number to 0x80, and succeed to load the second sector (the MINIX
boot loader in C), the 'disk_read' procedure won't offset the relative
sector numbers given by the C code, and the parsing of the file system
will fail after some times.
Maybe a more simple test with a single volume on your CF card, before
improving the procedure to support partitioning ?
Thank you for your testing !
MFLD
Le 16/04/2019 à 23:18, Paul Osmialowski a écrit :
Hi Marc,
Thanks for the hints. Feels like disk-bootable ELKS is getting closer, but
we're still not there yet. I've changed first param of all occurrences of
disk_read in minix_second.c to 0x80, unfortunately, it still behaves the
same way: as "MINIX boot" is displayed, the led on the first FDD blinks
and nothing happens, "Sector 2!" and "Press key" pops up again. I guess
this is the reason (in minix_first.S):
_next1:
mov $msg_head,%bx
call _puts
// Load the second sector of the boot block
mov $0x0201,%ax // read 1 sector
mov $sector_2,%bx // destination
mov $2,%cx // track 0 - from sector 2 (base 1)
xor %dx,%dx // drive 0 - head 0
int $0x13 // BIOS disk services
jnc _next2
mov $msg_load,%bx
call _puts
// void reboot ()
.global reboot
reboot:
mov $msg_reboot,%bx
call _puts
xor %ax,%ax // wait for key
int $0x16
int $0x19
jmp reboot
I tried to make some changes to it. Note that now I'm using 32MB CF card
with geometry 60 tracks per head, 16 heads, 63 sectors per track. Using
hexviewer I've found that the boot partition starts at byte 0x7e00
on the CF card (first sector of the second track), so sector_2 is at byte
0x8000 on the CF card (assuming that the thing I should look for is the
same as I can find at byte 512 of hd.img). So I modified minix_first.S as
such:
- mov $2,%cx // track 0 - from sector 2 (base 1)
- xor %dx,%dx // drive 0 - head 0
+ mov $0x42,%cx // track 1 - from sector 2 (base 1)
+ mov $0x80,%dx // head 0 - drive 0x80
(CX: assuming 6 bits for sector, track 1 should be 0x40)
Unfortunately, the only real change is that FDD does not blink anymore.
After a longer while of waiting "Secotr 2!" and "Press key" still pops
out.
On Tue, 16 Apr 2019, Marc-F. Lucca-Daniau wrote:
Hello Paul,
Sounds good, because if you see "MINIX boot" message when booting from your
HD/CF, and if you can mount it when booting from the floppy, it means there
are only a few changes left to make it fully working.
Did you tried to hack the 3 variables 'sect_max', 'head_max' and 'track_max'
in 'elkscmd/bootblocks/minix_first.S' with the geometry as presented by your
adapter (123 / 16 / 6) ?
Also, in 'elkscmd/bootblocks/minix_second.c', the boot drive number is forced
to 0 when calling 'disk_read' (as first argument), so the MINIX boot loader
has to be improved to use the right one provided by the BIOS. Meantime, you
can also hack that file and set that argument to 0x80 (= first hard drive) for
you experiment.
MFLD
Le 15/04/2019 ? 18:12, Paul Osmialowski a écrit :
Just one more observation. I managed to mount minix filesystem from CF
Card on system booted from 360k floppy! And not using directhd driver at
all! My mistake was, I tried to mount /dev/hda1 while the partition is at
/dev/bda1
I've noticed, chroot command would be a great help.
Cheers again,
Paul
On Mon, 15 Apr 2019, Paul Osmialowski wrote:
Hi Marc,
Thanks for your response. I've noticed a few interesting things btw.
I've found lots of #ifdef HARDDISK in this new boot sector code, so I
decided to give it a try. I've placed this boot sector code in
/dev/hda1 (leaving original FreeDOS MBR in /dev/hda) and for a first time
I've noticed something is alive: "MINIX boot" appeared on screen when I
booted from CF Card! But that's all, the next thing it tried to do was to
access floppy disk drive, having it empty, I could only see "Press key"
and it rebooted itself after pressing any key. I guess my XT-IDE card is
not handled properly, although when I boot ELKS from floppy I can see this
on the serial console:
hd Driver Copyright (C) 1994 Yggdrasil Computing, Inc.
Extended
and modified for Liux 8086 by Alan Cox.
doshd:
2 floppy drives and 1 hard drive
/dev/hda:
123 cylindrs, 16 heads, 6 sectors = 60.5 Mb
(that's when 64MB FreeDOS CF Card is inserted)
Also, before the ELKS boot starts I can see this:
XTIDE Universal BIOS (XT) @ C800h
Master at 300h: CF Card
Slave at 300h: not found
I've tried to compile directhd driver, but it lacks #include <arch/io.h>
causing link-time issue as some of the macros defined there are mistaken
for functions (outb_p() and friends), adding missing #include <arch/io.h>
makes whole thing buildable, yet it still doesn't seem to make any
(visible) difference.
Cheers,
Paul
On Sun, 14 Apr 2019, Marc-F. Lucca-Daniau wrote:
Hello,
Not a surprise, as the new code has only been tested on 1.44 MB floppy.
Looks like there is a missing "#ifdef FD360" in the boot sector new
code...
Now tracked by issue https://github.com/jbruchon/elks/issues/253
Thanks for the report,
MFLD
Le 14/04/2019 ? 19:46, Paul Osmialowski a écrit :
Hi,
I'm having access to my old XT for next couple of days so I decided to
give the latest ELKS a go. Since I still don't know how to boot it
from
CF-IDE card (I can boot FreeDOS from it), I'm still booting it from
360k
floppy. Unfortunately, nowadays it only prints MINIX and reboots
itself
after a while.
I managed to make it boot again after reverting following commits on
master:
93b57f474cb0e3fa9917b4783781cd405c944b04 [libc] Data segment starts
with
nil data
9e038b816014f83c0808df1ee5697380cd6be499 Revise bootblocks for
GCC-IA16
(the first one is reverted mostrly to reduce conflicts when reverting
the
other one).
I guess something went wrong with implementing new features.
Cheers,
Paul
