Re: Cannot boot the real thing from HDD

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

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