Re: Regression: cannot boot the real thing from floppy

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

 



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