From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Marc-F. Lucca-Daniau" Subject: Re: Cannot boot the real thing from HDD Date: Sat, 1 Feb 2020 11:28:28 +0100 Message-ID: References: <6e26eeeb-c80a-c42b-f2af-91b8df146a5e@gmail.com> <1c3b5526-66ae-5ed3-ecc2-b6e7f14b53ca@gmail.com> <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com> <4f903b5c-953f-74a5-8edf-6941a9b65c79@gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ft52TJxRslhvGSaOGYfqe1L36meCfdn/cxF/eGGuy5g=; b=sPpsqRssrcEcgfTHDSHqKGgsdB4xvgFZHszskQ53A4Jsfuh6MrrHpWwaHafUW8ZllV /I5pt+NHRJTAoUYCUW0sC22Tz1PdNVLUkDyL0vsBBdvMxXmpsFqNdXHBFGV3N6tYtIea MhQMQMBTAZ2LO5Pim5QPuOTujYTvpJyrkovKZB0wVSOju+/JOS2laxPDWVLtrLPGO4Pz WTQXcUChOAglwU1+hB+KT0jr3O7fqbNFu6XeJxYQeigRvc52YTZuvOLdSf9CRx3Tug8p p4m2Wmtz4Gv8B4BXIZf/aLsLCAvaNxQWv+KBGX6ygp9lO3d9ky3sZ2oxsEi72q07q6iS Ghqw== In-Reply-To: Content-Language: fr-FR Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8"; format="flowed" To: Paul Osmialowski Cc: ELKS 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 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 >>>>>>>         > > > > > > > > > > > > >>>>>>>         > > > > > > > > > > > > causing link-time issue as some >>>>>>> of the >>>>>>> macros defined >>>>>>>         > > > > > > > > > > > > there >>>>>>>         > > > > > > > > > > > > are >>>>>>>         > > > > > > > > > > > > mistaken >>>>>>>         > > > > > > > > > > > > for functions (outb_p() and >>>>>>> friends), >>>>>>> adding missing >>>>>>>         > > > > > > > > > > > > #include >>>>>>>         > > > > > > > > > > > > >>>>>>>         > > > > > > > > > > > > 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 >>>>>>>         > > > > > > > > > > > > > > >>>>>>>         > > > > > > > > > > > > > > >>>>>>>         > >>>>>>> >>>>>>>