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