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: Fri, 24 Jan 2020 22:05:50 +0100 Message-ID: <4f903b5c-953f-74a5-8edf-6941a9b65c79@gmail.com> References: <6e26eeeb-c80a-c42b-f2af-91b8df146a5e@gmail.com> <1c3b5526-66ae-5ed3-ecc2-b6e7f14b53ca@gmail.com> <3c988b36-6f34-b903-6a80-e54b56c1c950@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=52yk0iPR2Nvu+v5KWpf+FHlLSKlwGNIJBiZtg1bkxrY=; b=VtwcVrw+++GJk7qH8es+JVHQlPoG3yKyVIBgfEEfAjJLIwYGHpxnq3LALRxQM2TVto kKLU5eT0UyEEYJ96Tqc8aODCuNLDeq6D8YHp0y1yShkCAXj4ZFjvWsnmlAqJPIehCVTT 4fVDeqLAhPvO7+Px7MxvUChaInhkCdKb8M5OVTfcfNVy6HYfuN4/ry+5znKqy/CC58j/ TxI3fPT6oYRNWs78o5KDuEgOEaKFFFzjoRXjw0gZeWijTCOwbkpBl6Fwu4TyerDyNYBE rTROCyINIGsxf4ZNFMwseuaA/2D37NQFFOFre9w1/NzIeJj9Ze5tDZ/mdyB7lYK3Cu7R gZWA== In-Reply-To: <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com> 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, 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 >>>>        > > > > > > > > > > > > > > >>>>        > > > > > > > > > > > > > > >>>>        > >>>> >>>>