Re: Regression: cannot boot the real thing from floppy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Kernel]     [Linux ia64]     [DCCP]     [Linux for ARM]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux