Hello Paul,
Yes, all your testing is consistent, and really help to know where to
improve the ELKS boot for real HW. Thanks for that !
Let us plan that improvement for the next commits...
Thanks,
MFLD
Le 18/04/2019 à 13:48, Paul Osmialowski a écrit :
Hello,
Booting fd1140.bin from CF card didn't help, from visible point of view,
I'm observing the same behaviour, "MINIX boot" on screen and FDD led
blinking.
I also did some confirmation test and changed mov $0x80,%dx back to xor
%dx,%dx and indeed, "Sector 2!" appeared again (with FDD led blinking), so
at least symptoms are consistent. There must be something FDD-bound
between sector_2 and disk_read(0x80,...) calls in minix_second.c.
On Thu, 18 Apr 2019, Marc-F. Lucca-Daniau wrote:
Hello,
For a "flat volume", please DD the 'fd1440.bin' on your CF, don't use the 'HD'
image & option, I added it to the ELKS configuration, but it is not completed
& tested (see issue #199).
Thanks,
MFLD
Le 17/04/2019 ? 23:12, Paul Osmialowski a écrit :
Hi Marc,
So I changed minix_first.S as such:
@@ -68,7 +68,7 @@ _next1:
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
+ mov $0x80,%dx // head 0 - drive 0x80
int $0x13 // BIOS disk services
jnc _next2
And placed hd.img directly to /dev/hda (so now there's no partition table,
and no MBR written by FreeDOS). Now, "MINIX boot" appears on screen, which
is a good sign, but, FDD led is blinking and nothing else happens,
Ctrl-Alt-Del doesn't reboot, power-off is the only option. Something else
in between sector_2 and minix_second.c is hard-coded for trying to access
FDD...
On Wed, 17 Apr 2019, Marc-F. Lucca-Daniau wrote:
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
