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: Wed, 5 Feb 2020 20:26:16 +0100 Message-ID: <96d51a8e-afa1-5678-6c73-60802fe277ec@gmail.com> References: <1c3b5526-66ae-5ed3-ecc2-b6e7f14b53ca@gmail.com> <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com> <4f903b5c-953f-74a5-8edf-6941a9b65c79@gmail.com> <389d8788-e5bf-a55b-cedf-0cb3c81cdf1f@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=5fBxrlN2nXbQaV2AqKqfs+pne21E/9Nvx3qhnxSb4Oo=; b=cFjVtCOqbRhw73AiGHHEOQg+hAKS8ZFSpRP6V7C4N0ri3GjzeGzu9RZdIwrWDTqQgY mR75qmqgZazQK0kmZ0KMJyf2yNnEQNmJFBJIeiywvH71N16QawJHCVFqyePsNLLRJTbT uhI2hV1mklh+Azvfi6xYC65M9BDOr69zHiY/FaJ4MS9EmuB1vMAo7waSMRI7TN5lPWOO qcVSg7Y7KwXf7GMZ/NGaIPVf89ZDVzyd46K2OqR62KWcn/QmYkhRhvAeoUcr5e/VID8U /EU4St8UccIA2+v3eM0bWaXE/I05PXemrgSkkvsX/72SrhNy1CMa6xqRB1aN3TAyXTBJ +ySQ== 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 Yep, hex error fixed in latest commit: https://github.com/elks-org/elks/commit/6332929104591ecbd62f18757a76506938cf96ce MFLD Le 03/02/2020 à 23:05, Paul Osmialowski a écrit : > probe.bin prints: > > Boot sector > C=0x3D H=0x10 S=0x3G > Press key > > 0x3G is a rather strange hex value... I assume off-by-one error while > doing 'A' + h. > > I looked at what fdisk on different systems prints about this 32MB CF > card. > > On Linux (fdisk -c=dos /dev/sdX): cyls: 1024, heads: 1, sects: 61 > On Linux (fdisk -c=dos on FreeDOS image): cyls: 3, heads: 16, sects: 63 > On FreeDOS (fdisk /info /tech): TC: 61 TH: 15 TS: 63 > > I've tried all of those values, with the same effect (....4!). > > Also I think the name of config option in kernel configuration is > misleading. Tracks refers to number of tracks per cylinder which is heads > * sectors. I assume what this option really expects is 'cylinders', and > IMO should be named that way. > > There's a chance that the problem with FDD is not with the drive itself. > I'm waiting for delivery of used 3.5'' 720k DD floppy disks to verify this > suspicion, should arrive in a week. > > Thanks, > Paul > > On Mon, 3 Feb 2020, Marc-F. Lucca-Daniau wrote: > >> Hello Paul, >> >> It is really too bad that you don't have any working FDD on your Amstrad PC, >> so that we could test if the latest fixes solve the "cannot boot the real >> thing from floppy" problem... >> >> It would help a lot before attacking the HDD problem. >> >> Anyway... there is a new payload in the 'bootblocks' folder, named >> 'probe.bin', that queries the BIOS for the actual geometry of the HDD. Could >> you please DD that payload to your CF first sectors (2) and give us what is >> displayed on boot ? >> >> Thanks, >> >> MFLD >> >> >> Le 03/02/2020 ? 17:59, Paul Osmialowski a écrit : >>> Hi Marc, >>> >>> I gave it a go, it now looks differend, yet it still fails at the end: >>> >>> Boot sector >>> ...Linux found >>> ..........................................4! >>> Press key >>> >>> (number of dots in the longest line may differ from actual) >>> >>> According to boot_err.h file, the error code 4 means ERR_BAD_SYSTEM >>> >>> I looked into hd.bin image. It does seem to have correct minix fs with >>> /linux file of size 49778 bytes and /bin/init (instead of /sbin/init) >>> among other files and directories. >>> >>> Good news with Amstrad PC 2086, I managed to fix its keyboard, it just >>> needed a good scrub. Now I can boot FreeDOS from a CF card and start >>> things like OpenGEM and alike. >>> >>> Cheers, >>> Paul >>> >>> On Sat, 1 Feb 2020, Marc-F. Lucca-Daniau wrote: >>> >>>> Hello Paul, >>>> >>>> The problem should be solved now (at least for the floppy). >>>> >>>> Details in the issues listed below (253 and 288). >>>> >>>> MFLD >>>> >>>> >>>> Le 30/01/2020 ? 22:43, Marc-F. Lucca-Daniau a écrit : >>>>> Hello Paul, >>>>> >>>>> Thanks for the report, that time with the error code 3. >>>>> >>>>> Your problem is still tracked by: >>>>> https://github.com/elks-org/elks/issues/253 >>>>> >>>>> It looks like you are facing the same problem as another user: >>>>> https://github.com/elks-org/elks/issues/288 >>>>> >>>>> We are now quite sure there is a somewhere a bug in the new `disk_read` >>>>> function, that fires only on real HW, not in QEmu. >>>>> >>>>> Investigation is still ongoing... stay tuned ! >>>>> >>>>> MFLD >>>>> >>>>> >>>>> >>>>> Le 30/01/2020 ? 20:51, Paul Osmialowski a écrit : >>>>>> Hi Marc, >>>>>> >>>>>> As I mentioned earlier, I'm again away from my old home and won't be >>>>>> there >>>>>> before April (to make tests on my old XT-Turbo). Yet I managed to buy >>>>>> on >>>>>> e-bay an Amstrad PC2086 here, so in theory, I should be able to >>>>>> continue >>>>>> from here too. The machine itself came in a very bad shape, the >>>>>> keyboard >>>>>> is broken, FDD and original MFM HDD are also dead. Fortunately, I've >>>>>> got >>>>>> one more XT-IDE 8-bit ISA card and an CF-IDE adapter. It's the only >>>>>> workable boot device this machine currently has. >>>>>> >>>>>> I've compiled ELKS's recent git master and copied boot image to the >>>>>> 32MB >>>>>> CF card. While configuring the build, some progess I've noticed in the >>>>>> way >>>>>> HD image is configured (CHS geometry can now be given through >>>>>> menuconfig). >>>>>> >>>>>> I tried to boot the image, but all I could see was: >>>>>> >>>>>> MINIX boot >>>>>> 3! >>>>>> Press key. >>>>>> >>>>>> Some specs of this machine: >>>>>> >>>>>> - CPU: AMD 8086 >>>>>> - RAM: 640kB >>>>>> - Video: Onboard VGA Paradise >>>>>> - Serial port: Onboard Amstrad 40049 inherited from Amstrad Portable >>>>>> PC >>>>>> line (I hope it's compatible with 8250, not sure where to find more >>>>>> info >>>>>> about it) >>>>>> - Amstrad-specific keyboard and mouse (not compatible with anything >>>>>> else >>>>>> and not repairable when broken) >>>>>> - Onboard Zilog 765 floppy disk controller >>>>>> >>>>>> I've removed MFM HDD controller (8-bit ISA card), as there's no use >>>>>> for >>>>>> it. >>>>>> >>>>>> Cheers, >>>>>> Paul >>>>>> >>>>>> On Fri, 24 Jan 2020, Marc-F. Lucca-Daniau wrote: >>>>>> >>>>>>> Hello Paul, >>>>>>> >>>>>>> I added some error checking with very simple traces in my latest >>>>>>> commit: >>>>>>> https://github.com/jbruchon/elks/commit/63647a9a37ec3c5751fb2adc4ddad368e18ba7c5 >>>>>>> >>>>>>> It would be nice if you (or someone else on that mailing list) could >>>>>>> try >>>>>>> to >>>>>>> boot again from a floppy disk and report the traces in case of any >>>>>>> failure. >>>>>>> >>>>>>> Also, I added some options to describe the HD geometry in the >>>>>>> configuration, >>>>>>> not to have to hack that part of code: >>>>>>> https://github.com/jbruchon/elks/commit/28d5f0ae66fd62bb7e25770e23d3c402cd301d76 >>>>>>> >>>>>>> And last but not least, the boot block now reuses the driver number >>>>>>> as >>>>>>> provided by the BIOS, again to avoid forcing it in the code: >>>>>>> https://github.com/jbruchon/elks/commit/9dbcd5ace60dc19f1bad24e34f1a3dd8793bcfcf >>>>>>> >>>>>>> MFLD >>>>>>> >>>>>>> >>>>>>> Le 22/12/2019 ? 11:51, Marc-F. Lucca-Daniau a écrit : >>>>>>>> Hello Paul, >>>>>>>> >>>>>>>> I forced the build of minix.bin to 8086 model (-mtune 8086), but >>>>>>>> no >>>>>>>> change >>>>>>>> in the binary, so not related to possible 80186/286 instructions. >>>>>>>> >>>>>>>> Also, you memory is largely enough for the relocation of the code, >>>>>>>> so >>>>>>>> not >>>>>>>> related either (it could fail for memory < 128 Kb). >>>>>>>> >>>>>>>> I am currently suspecting the INT 13h in disk_read() to fail at >>>>>>>> one >>>>>>>> moment, >>>>>>>> but as there is no error checking in load_zone() and in >>>>>>>> load_file() in >>>>>>>> the >>>>>>>> current version, it could be a silent error. >>>>>>>> >>>>>>>> I am going to try to add that error checking in the remaining >>>>>>>> space of >>>>>>>> the >>>>>>>> second sector. >>>>>>>> >>>>>>>> Stay tuned... >>>>>>>> >>>>>>>> MFLD >>>>>>>> >>>>>>>> >>>>>>>> Le 18/12/2019 ? 23:51, Paul Osmialowski a écrit : >>>>>>>>> Some more info: >>>>>>>>> >>>>>>>>> CPU: 8088, no FPU installed (empty socket) >>>>>>>>> MEM: 640kB, no expansions >>>>>>>>> FDD: standard 765-based FDD controller on 8-bit ISA card >>>>>>>>> HDD: XT-CF IDE controller on 8-bit ISA card bought here: >>>>>>>>> >>>>>>>>> https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_CompactFlash_Adapter_revision_2b >>>>>>>>> >>>>>>>>> with BIOS obtained from here: >>>>>>>>> >>>>>>>>> https://code.google.com/archive/p/xtideuniversalbios >>>>>>>>> >>>>>>>>> On Wed, 18 Dec 2019, Paul Osmialowski wrote: >>>>>>>>> >>>>>>>>>> Hi Marc, >>>>>>>>>> >>>>>>>>>> Thanks for your quick reply. This machine is NOT an original >>>>>>>>>> IBM >>>>>>>>>> PC/XT, >>>>>>>>>> it >>>>>>>>>> is a cheap Taiwan made clone from 1986, very popular Turbo XT. >>>>>>>>>> >>>>>>>>>> Using simple Willem programmer I managed to dump its BIOS to a >>>>>>>>>> file >>>>>>>>>> (attached xt-rom.BIN file, 8192 bytes). When powered on it >>>>>>>>>> prints: >>>>>>>>>> >>>>>>>>>> T U R B O - XT 1986 >>>>>>>>>> Speed 4.77/8.00MHz Version 3.10 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On Wed, 18 Dec 2019, Marc-François Lucca-Daniau wrote: >>>>>>>>>> >>>>>>>>>>> Hello Paul, >>>>>>>>>>> >>>>>>>>>>> I walked into the dump of your CF image, and everything >>>>>>>>>>> looks >>>>>>>>>>> correct >>>>>>>>>>> : Minix boot blocks, geometry constants, filesystem, root >>>>>>>>>>> directory >>>>>>>>>>> and kernel image. >>>>>>>>>>> >>>>>>>>>>> Could you please tell me the size of your low memory, and >>>>>>>>>>> confirm the >>>>>>>>>>> processor is a 8088/86, not a 80186/286 ? After reading the >>>>>>>>>>> code >>>>>>>>>>> of >>>>>>>>>>> the boot blocks again, I found two potential failures >>>>>>>>>>> related. >>>>>>>>>>> >>>>>>>>>>> Also, if you could tell me the BIOS version & date, for me >>>>>>>>>>> to >>>>>>>>>>> have a >>>>>>>>>>> look in the IBM manual ? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> MFLD >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le mar. 17 déc. 2019 23:21, Paul Osmialowski >>>>>>>>>>> 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 >>>>>>>>>>>         > > > > > > > > > > > > > > >>>>>>>>>>>         > > > > > > > > > > > > > > >>>>>>>>>>>         > >>>>>>>>>>> >>>>>>>>>>>