Re: Cannot boot the real thing from HDD

Marc-F. Lucca-Daniau
2020-01-30T21:43:51Z

Hello Paul,

Thanks for the report, that time with the error code 3.

Your problem is still tracked by:
https://github.com/elks-org/elks/issues/253

It looks like you are facing the same problem as another user:
https://github.com/elks-org/elks/issues/288

We are now quite sure there is a somewhere a bug in the new `disk_read`
function, that fires only on real HW, not in QEmu.

Investigation is still ongoing... stay tuned !

MFLD

Le 30/01/2020 à 20:51, Paul Osmialowski a écrit :
> Hi Marc,
>
> As I mentioned earlier, I'm again away from my old home and won't be there
> before April (to make tests on my old XT-Turbo). Yet I managed to buy on
> e-bay an Amstrad PC2086 here, so in theory, I should be able to continue
> from here too. The machine itself came in a very bad shape, the keyboard
> is broken, FDD and original MFM HDD are also dead. Fortunately, I've got
> one more XT-IDE 8-bit ISA card and an CF-IDE adapter. It's the only
> workable boot device this machine currently has.
>
> I've compiled ELKS's recent git master and copied boot image to the 32MB
> CF card. While configuring the build, some progess I've noticed in the way
> HD image is configured (CHS geometry can now be given through menuconfig).
>
> I tried to boot the image, but all I could see was:
>
> MINIX boot
> 3!
> Press key.
>
> Some specs of this machine:
>
> - CPU: AMD 8086
> - RAM: 640kB
> - Video: Onboard VGA Paradise
> - Serial port: Onboard Amstrad 40049 inherited from Amstrad Portable PC
> line (I hope it's compatible with 8250, not sure where to find more info
> about it)
> - Amstrad-specific keyboard and mouse (not compatible with anything else
> and not repairable when broken)
> - Onboard Zilog 765 floppy disk controller
>
> I've removed MFM HDD controller (8-bit ISA card), as there's no use for
> it.
>
> Cheers,
> Paul
>
> On Fri, 24 Jan 2020, Marc-F. Lucca-Daniau wrote:
>
>> Hello Paul,
>>
>> I added some error checking with very simple traces in my latest commit:
>> https://github.com/jbruchon/elks/commit/63647a9a37ec3c5751fb2adc4ddad368e18ba7c5
>>
>> It would be nice if you (or someone else on that mailing list) could try to
>> boot again from a floppy disk and report the traces in case of any failure.
>>
>> Also, I added some options to describe the HD geometry in the configuration,
>> not to have to hack that part of code:
>> https://github.com/jbruchon/elks/commit/28d5f0ae66fd62bb7e25770e23d3c402cd301d76
>>
>> And last but not least, the boot block now reuses the driver number as
>> provided by the BIOS, again to avoid forcing it in the code:
>> https://github.com/jbruchon/elks/commit/9dbcd5ace60dc19f1bad24e34f1a3dd8793bcfcf
>>
>> MFLD
>>
>>
>> Le 22/12/2019 ? 11:51, Marc-F. Lucca-Daniau a écrit :
>>> Hello Paul,
>>>
>>> I forced the build of minix.bin to 8086 model (-mtune 8086), but no change
>>> in the binary, so not related to possible 80186/286 instructions.
>>>
>>> Also, you memory is largely enough for the relocation of the code, so not
>>> related either (it could fail for memory < 128 Kb).
>>>
>>> I am currently suspecting the INT 13h in disk_read() to fail at one moment,
>>> but as there is no error checking in load_zone() and in load_file() in the
>>> current version, it could be a silent error.
>>>
>>> I am going to try to add that error checking in the remaining space of the
>>> second sector.
>>>
>>> Stay tuned...
>>>
>>> MFLD
>>>
>>>
>>> Le 18/12/2019 ? 23:51, Paul Osmialowski a écrit :
>>>> Some more info:
>>>>
>>>> CPU: 8088, no FPU installed (empty socket)
>>>> MEM: 640kB, no expansions
>>>> FDD: standard 765-based FDD controller on 8-bit ISA card
>>>> HDD: XT-CF IDE controller on 8-bit ISA card bought here:
>>>>
>>>> https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_CompactFlash_Adapter_revision_2b
>>>>
>>>> with BIOS obtained from here:
>>>>
>>>> https://code.google.com/archive/p/xtideuniversalbios
>>>>
>>>> On Wed, 18 Dec 2019, Paul Osmialowski wrote:
>>>>
>>>>> Hi Marc,
>>>>>
>>>>> Thanks for your quick reply. This machine is NOT an original IBM PC/XT,
>>>>> it
>>>>> is a cheap Taiwan made clone from 1986, very popular Turbo XT.
>>>>>
>>>>> Using simple Willem programmer I managed to dump its BIOS to a file
>>>>> (attached xt-rom.BIN file, 8192 bytes). When powered on it prints:
>>>>>
>>>>> T U R B O - XT 1986
>>>>> Speed 4.77/8.00MHz Version 3.10
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> On Wed, 18 Dec 2019, Marc-François Lucca-Daniau wrote:
>>>>>
>>>>>> Hello Paul,
>>>>>>
>>>>>> I walked into the dump of your CF image, and everything looks correct
>>>>>> : Minix boot blocks, geometry constants, filesystem, root directory
>>>>>> and kernel image.
>>>>>>
>>>>>> Could you please tell me the size of your low memory, and confirm the
>>>>>> processor is a 8088/86, not a 80186/286 ? After reading the code of
>>>>>> the boot blocks again, I found two potential failures related.
>>>>>>
>>>>>> Also, if you could tell me the BIOS version & date, for me to have a
>>>>>> look in the IBM manual ?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> MFLD
>>>>>>
>>>>>>
>>>>>> Le mar. 17 déc. 2019 23:21, Paul Osmialowski <pawelo@king.net.pl> a
>>>>>> écrit :
>>>>>>        Hi Marc,
>>>>>>
>>>>>>        The bzipped file is so small I'd try to attach it to this
>>>>>> message.
>>>>>>        The other attachment is the diff of all of my changes.
>>>>>>
>>>>>>        I must admit, I was looking into wrong places. As I mounted
>>>>>> this image, it
>>>>>>        indeed contains MINIX filesystem with /linux file in it, and
>>>>>> that file
>>>>>>        indeed has magic string "ELKS" at offset 0x1E6. So I suspect,
>>>>>> load_zone()
>>>>>>        does something wrong.
>>>>>>
>>>>>>        Note that I wasn't able to boot from 360k floppy either (with
>>>>>> the same
>>>>>>        outcome!), despite all the changes as in the patch.
>>>>>>
>>>>>>        Cheers,
>>>>>>        Paul
>>>>>>
>>>>>>        On Tue, 17 Dec 2019, Marc-F. Lucca-Daniau wrote:
>>>>>>
>>>>>>        > Hello Paul,
>>>>>>        >
>>>>>>        > I understand your mail on dec-16, but I don't the latest
>>>>>> today.
>>>>>>        >
>>>>>>        > * minix_second.c loads the root directory, then finds the
>>>>>> "/linux" file in it,
>>>>>>        > as you got the "Linux found!" trace.
>>>>>>        >
>>>>>>        > * the "linux" file is supposed to be the
>>>>>> /elks/arch/i86/boot/Image (see
>>>>>>        > image/Makefile):
>>>>>>        >
>>>>>>        > sudo install $(ELKS_DIR)/arch/i86/boot/Image
>>>>>> $(TARGET_MNT)/linux
>>>>>>        >
>>>>>>        > * that file concatenates 3 other files : bootsect, setup and
>>>>>> system (through
>>>>>>        > the /elks/arch/i86/tools utility)
>>>>>>        >
>>>>>>        > * run_prog() checks that the "bootsect" file contains "ELKS"
>>>>>> at offset 1E6h:
>>>>>>        >
>>>>>>        > minix_first.S:
>>>>>>        >     mov 0x01E6,%ax  // check for ELKS magic number
>>>>>>        >     cmp $0x4C45,%ax
>>>>>>        >     jnz not_elks
>>>>>>        >     mov 0x01E8,%ax
>>>>>>        >     cmp $0x534B,%ax
>>>>>>        >     jz  boot_it
>>>>>>        >
>>>>>>        > bootsect.S:
>>>>>>        > .org 0x1E3
>>>>>>        > msg1:
>>>>>>        >     .byte 13,10,7
>>>>>>        >     .ascii "ELKS Boot"
>>>>>>        >
>>>>>>        > * dumping the "Image" file on my machine shows that the
>>>>>> offset and the string
>>>>>>        > are correct:
>>>>>>        >
>>>>>>        > 0001e0 12 0f 09 0d 0a 07 45 4c 4b 53 20 42 6f 6f 74 20
>>>>>>> ......ELKS Boot <
>>>>>>        >
>>>>>>        > * so I agree that the loaded file "linux" is not the right
>>>>>> one in memory
>>>>>>        >
>>>>>>        > Could you please:
>>>>>>        >
>>>>>>        > 1) dump the "Image" file and check the data @ 1E0h ?
>>>>>>        >
>>>>>>        > 2) "DD" the content of your CF card to a file and upload that
>>>>>> file to a
>>>>>>        > server, so that I could inspect the actual structure of the
>>>>>> Minix filesystem
>>>>>>        > on your CF card ? I understood you flashed it with
>>>>>> fd1440.bin, but I would
>>>>>>        > like to see what the CF card contains at the end.
>>>>>>        >
>>>>>>        > Thanks,
>>>>>>        >
>>>>>>        > MFLD
>>>>>>        >
>>>>>>        >
>>>>>>        >
>>>>>>        >
>>>>>>        > Le 17/12/2019 ? 11:23, Paul Osmialowski a écrit :
>>>>>>        > > I've looked at the problem more closely and now I see that
>>>>>> after
>>>>>>        > > "Revise bootblocks for GCC-IA16" commit
>>>>>>        > > (9e038b816014f83c0808df1ee5697380cd6be499) there's no way
>>>>>> to boot ELKS on
>>>>>>        > > any real machine whatsoever. The magic number was specified
>>>>>> in file
>>>>>>        > > sysboot16.s that this patch hapily removes. The
>>>>>> bootloader's run_prog()
>>>>>>        > > routine looks for non-existing thing. And even after
>>>>>> removal of that check,
>>>>>>        > > the bootloader stucks somewhere after boot_it label. It
>>>>>> happens with hd,
>>>>>>        > > it happens with floppy. ELKS now can be used only with
>>>>>> emulators and it's
>>>>>>        > > a regression comparing to what was possible last year.
>>>>>>        > >
>>>>>>        > > On Mon, 16 Dec 2019, Paul Osmialowski wrote:
>>>>>>        > >
>>>>>>        > > > 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
>>>>>>        > > > > > > > > > > > > > >
>>>>>>        > > > > > > > > > > > > > >
>>>>>>        >
>>>>>>
>>>>>>