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
> > > > > > > > > > >
> > > > > > > > > > >
>
