Re: Cannot boot the real thing from HDD

["Marc-F. Lucca-Daniau" <mfld.fr@gmail.com>]

Yep, hex error fixed in latest commit:

https://github.com/elks-org/elks/commit/6332929104591ecbd62f18757a76506938cf96ce

MFLD


Le 03/02/2020 à 23:05, Paul Osmialowski a écrit :
> probe.bin prints:
>
> Boot sector
> C=0x3D  H=0x10  S=0x3G
> Press key
>
> 0x3G is a rather strange hex value... I assume off-by-one error while
> doing 'A' + h.
>
> I looked at what fdisk on different systems prints about this 32MB CF
> card.
>
> On Linux (fdisk -c=dos /dev/sdX): cyls: 1024, heads: 1, sects: 61
> On Linux (fdisk -c=dos on FreeDOS image): cyls: 3, heads: 16, sects: 63
> On FreeDOS (fdisk /info /tech): TC: 61  TH: 15  TS: 63
>
> I've tried all of those values, with the same effect (....4!).
>
> Also I think the name of config option in kernel configuration is
> misleading. Tracks refers to number of tracks per cylinder which is heads
> * sectors. I assume what this option really expects is 'cylinders', and
> IMO should be named that way.
>
> There's a chance that the problem with FDD is not with the drive itself.
> I'm waiting for delivery of used 3.5'' 720k DD floppy disks to verify this
> suspicion, should arrive in a week.
>
> Thanks,
> Paul
>
> On Mon, 3 Feb 2020, Marc-F. Lucca-Daniau wrote:
>
>> Hello Paul,
>>
>> It is really too bad that you don't have any working FDD on your Amstrad PC,
>> so that we could test if the latest fixes solve the "cannot boot the real
>> thing from floppy" problem...
>>
>> It would help a lot before attacking the HDD problem.
>>
>> Anyway... there is a new payload in the 'bootblocks' folder, named
>> 'probe.bin', that queries the BIOS for the actual geometry of the HDD. Could
>> you please DD that payload to your CF first sectors (2) and give us what is
>> displayed on boot ?
>>
>> Thanks,
>>
>> MFLD
>>
>>
>> Le 03/02/2020 ? 17:59, Paul Osmialowski a écrit :
>>> Hi Marc,
>>>
>>> I gave it a go, it now looks differend, yet it still fails at the end:
>>>
>>> Boot sector
>>> ...Linux found
>>> ..........................................4!
>>> Press key
>>>
>>> (number of dots in the longest line may differ from actual)
>>>
>>> According to boot_err.h file, the error code 4 means ERR_BAD_SYSTEM
>>>
>>> I looked into hd.bin image. It does seem to have correct minix fs with
>>> /linux file of size 49778 bytes and /bin/init (instead of /sbin/init)
>>> among other files and directories.
>>>
>>> Good news with Amstrad PC 2086, I managed to fix its keyboard, it just
>>> needed a good scrub. Now I can boot FreeDOS from a CF card and start
>>> things like OpenGEM and alike.
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Sat, 1 Feb 2020, Marc-F. Lucca-Daniau wrote:
>>>
>>>> Hello Paul,
>>>>
>>>> The problem should be solved now (at least for the floppy).
>>>>
>>>> Details in the issues listed below (253 and 288).
>>>>
>>>> MFLD
>>>>
>>>>
>>>> Le 30/01/2020 ? 22:43, Marc-F. Lucca-Daniau a écrit :
>>>>> 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
>>>>>>>>>>>           > > > > > > > > > > > > > >
>>>>>>>>>>>           > > > > > > > > > > > > > >
>>>>>>>>>>>           >
>>>>>>>>>>>
>>>>>>>>>>>