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