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: Thu, 30 Jan 2020 22:43:51 +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:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/CJEiF35IVthOS28nwuP+Qk+k1Brs7tGnxthtt1HqZk=; b=HffWmOYrFe2DZV/UWbpCeM05m7zU1kRTPLL0/FpFzLfVENO0vXA+4HkrVlpl37d7rM j5C9cM0gVYHCEDcM6J1Kew16+Dnj+kul8C3/CBQYEpX6V911Q6p2HKuSZQO6CT9RCfR2 uBVsWD3F44Q9S8OU1wYPokWsmZeANLoScFaaJ/yIQ1qvH5NIJaTCuULYvFSlk92qd6MM EI7OfNA0rwkaG+1xIT/ehodFaojUXlp/RF4K0zbtyMZShodor0SAMLfdHot1BFURE48k gsqOeZRQatUrPd2MRdIDEoCI74MrU/YSpyyIs/aSJt79H10FAh62xV8kFRLIYwL22JqJ ZzAA== 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, 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 >>>>>>        > > > > > > > > > > > > > > >>>>>>        > > > > > > > > > > > > > > >>>>>>        > >>>>>> >>>>>>