Hello MFLD,
As I'm back to my old flat for a while, I can follow this up for couple of
days.
I've made following changes in bootsector files:
diff --git a/elkscmd/bootblocks/minix_first.S
b/elkscmd/bootblocks/minix_first.S
index c70625a6..cce72ba1 100644
--- a/elkscmd/bootblocks/minix_first.S
+++ b/elkscmd/bootblocks/minix_first.S
@@ -75,7 +75,8 @@ loopy:
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
+ // xor %dx,%dx // drive 0 - head 0
int $0x13 // BIOS disk services
jc loopy
jmp _next2
@@ -250,7 +251,7 @@ drive_reset:
// #undef CONFIG_IMG_FD360
sect_max:
-#ifdef CONFIG_IMG_FD720
+#if defined(CONFIG_IMG_FD360) || defined(CONFIG_IMG_FD720)
.word 9
#endif
#if defined(CONFIG_IMG_FD1200)
@@ -262,11 +263,17 @@ sect_max:
#if defined(CONFIG_IMG_FD1680)
.word 21
#endif
+#if defined(CONFIG_IMG_HD)
+ .word 61
+#endif
head_max:
#if defined(CONFIG_IMG_FD1440) || defined(CONFIG_IMG_FD720) ||
defined(CONFIG_IMG_FD360) || defined(CONFIG_IMG_FD1200) ||
defined(CONFIG_IMG_FD1680)
.word 2
#endif
+#if defined(CONFIG_IMG_HD)
+ .word 1
+#endif
track_max:
#if defined(CONFIG_IMG_FD360)
@@ -275,6 +282,9 @@ track_max:
#if defined(CONFIG_IMG_FD1440) || defined(CONFIG_IMG_FD720)
.word 80
#endif
+#if defined(CONFIG_IMG_HD)
+ .word 1024
+#endif
//------------------------------------------------------------------------------
diff --git a/elkscmd/bootblocks/minix_second.c
b/elkscmd/bootblocks/minix_second.c
index f33c6139..9fd3e6d2 100644
--- a/elkscmd/bootblocks/minix_second.c
+++ b/elkscmd/bootblocks/minix_second.c
@@ -74,7 +74,7 @@ static int load_super ()
int err;
while (1) {
- err = disk_read (0, 2, 2, sb_block, seg_data ());
+ err = disk_read (0x80, 2, 2, sb_block, seg_data ());
//if (err) break;
sb_data = (struct super_block *) sb_block;
@@ -116,7 +116,7 @@ static int load_inode ()
// Compute inode block and load if not cached
int ib = ib_first + i_now / INODES_PER_BLOCK;
- err = disk_read (0, ib << 1, 2, i_block, seg_data ());
+ err = disk_read (0x80, ib << 1, 2, i_block, seg_data ());
//if (err) break;
// Get inode data
@@ -137,12 +137,12 @@ static int load_zone (int level, zone_nr * z_start,
zone_nr * z_end)
for (zone_nr * z = z_start; z < z_end; z++) {
if (level == 0) {
// FIXME: image can be > 64K
- err = disk_read (0, (*z) << 1, 2, i_now ? f_pos :
d_dir + f_pos, i_now ? LOADSEG : seg_data ());
+ err = disk_read (0x80, (*z) << 1, 2, i_now ? f_pos
: d_dir + f_pos, i_now ? LOADSEG : seg_data ());
f_pos += BLOCK_SIZE;
if (f_pos >= i_data->i_size) break;
} else {
int next = level - 1;
- err = disk_read (0, *z << 1, 2, z_block [next],
seg_data ());
+ err = disk_read (0x80, *z << 1, 2, z_block [next],
seg_data ());
load_zone (next, (zone_nr *) z_block [next],
(zone_nr *) (z_block [next] + BLOCK_SIZE));
}
}
@@ -227,7 +227,7 @@ void main ()
for (int d = 0; d < i_data->i_size; d += DIRENT_SIZE) {
if (!strcmp (d_dir + 2 + d, "linux")) {
- //puts ("Linux found\r\n");
+ puts ("Linux found\r\n");
i_now = (*(int *)(d_dir + d)) - 1;
load_file ();
run_prog ();
Summary is following:
- added missing check for CONFIG_IMG_FD360 (definitely, should be fixed
upstream too!)
- hardcoded HD C/H/S geometry with values outputed by 'fdisk -c=dos' :
1024/1/61 (~32MB CF card)
- "Linux found" is printed when certain point in main() is reached (helps
with investigation)
- Disk drive is ensured 0x80 wherever I've managed to find it should be
hardcoded.
Result:
MINIX boot
Linux found
Not ELKS!
So it seems we have a small progress comparing to last attempt: sector 2
is read, main() gets executed, and run_prog() gets called. Yet run_prog()
finds that what was read from storage wasn't the thing that was expected
(does it look for "EL" at the right offset?!). I suspect something went
wrong with load_file(). Any hints welcomed.
Thanks,
Paul
On Sun, 21 Apr 2019, Marc-F. Lucca-Daniau wrote:
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
