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: Tue, 11 Feb 2020 21:38:23 +0100 Message-ID: <111e642f-de53-c70f-4bab-bb9efafc6004@gmail.com> References: <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com> <4f903b5c-953f-74a5-8edf-6941a9b65c79@gmail.com> <389d8788-e5bf-a55b-cedf-0cb3c81cdf1f@gmail.com> <96d51a8e-afa1-5678-6c73-60802fe277ec@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=S0Yg3oyOghhOlVAS0mLJufL9oKDmU7MsHGEHxhcbFQ4=; b=RukCbIazoOe4UueFp8SKkEP7RDSL885zhtSRx1uoaHL+EWTxeEipV8FDHWRfy1hp1E ijvWXpfxIsnIDKjqLWs2teGvwKmlow9ZAbGSJg2RuFVm2CfjQw751rE99pZROb0hMEEj SweNMToLR9gKDsJeCrcIpJQix0x//ELtE32+gQXTyml5KttSr4lO1m7ii7Ol/Ut3KM80 wGhYuQokjURjvBgRO48E8lqipCqCVqGuLhQ1cPoAZVECbSDd1gDg6GfU8DBXCyYDLMKu F+O1wDHZp2BFEFwOnRcNm2/IJjhPIpOoy6nbnM4zvrj5nnfDw7cOS9btBPhG8N8il+l/ olrQ== 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, Yes, confirmed, a recent commit on the boot sector missed the CONFIG_IMG_HD case. Tracked by : https://github.com/elks-org/elks/issues/323 It again shows that we REALLY need more automatic testing in the CI ! MFLD Le 11/02/2020 à 00:38, Paul Osmialowski a écrit : > Hi Marc, > > I'm observing some regression with today's changes on git master. Despite > selecting MINIX boot image, -DBOOT_FAT is still present in build log > (seems -UBOOT_FAT is not propagated properly): > > make[2]: Entering directory '/home/pawelo/elks.git/elkscmd/bootblocks' > ia16-elf-gcc -I /home/pawelo/elks.git/include -E -o boot_sect.tmp > boot_sect.S > ia16-elf-gcc -I /home/pawelo/elks.git/include -E -UBOOT_FAT -o > boot_sect.tmp boot_sect.S > ia16-elf-as -o boot_sect.o boot_sect.tmp > rm -f boot_sect.tmp > ia16-elf-gcc -Wall -Os -mregparmcall -fno-toplevel-reorder -fno-inline > -mcmodel=tiny -mno-segment-relocation-stuff -ffreestanding -mtune=i8086 -I > /home/pawelo/elks.git/include -c -o boot_minix.o boot_minix.c > ia16-elf-ld -T /home/pawelo/elks.git/elks/elks-raw.ld -M -o minix.bin > boot_sect.o boot_minix.o > minix.map > ia16-elf-gcc -I /home/pawelo/elks.git/include -E -o boot_probe.tmp > boot_probe.S > ia16-elf-as -oboot_probe.o boot_probe.tmp > rm -f boot_probe.tmp > ia16-elf-ld -T /home/pawelo/elks.git/elks/elks-raw.ld -M -o probe.bin > boot_sect.o boot_probe.o > probe.map > ia16-elf-gcc -I /home/pawelo/elks.git/include -E -DBOOT_FAT -o > boot_sect_fat.tmp boot_sect.S > ia16-elf-as -o boot_sect_fat.o boot_sect_fat.tmp > boot_sect.S: Assembler messages: > boot_sect.S:41: Error: Unknown disk medium! > make[2]: *** [Makefile:42: boot_sect_fat.o] Error 1 > make[2]: Leaving directory '/home/pawelo/elks.git/elkscmd/bootblocks' > make[1]: *** [Makefile:126: all] Error 1 > make[1]: Leaving directory '/home/pawelo/elks.git/elkscmd' > make: *** [Makefile:37: all] Error 2 > Build script has terminated with error 5 > > > On Sat, 8 Feb 2020, Paul Osmialowski wrote: > >> Things changed overnight on the ELKS repo and now my Amstrad PC 2086 boots >> ELKS from 32MB CF card! >> >> There are some shortcomings though: >> >> 1. Bootable MINIX image does not contain partition table. There's nothing >> wrong about that, yet it makes ELKS's Partition Check routine lost a bit. >> Contrary to this, the Desktop tools for managing external storage in my >> Desktop Linux environment somehow are able to spot that and do mount MINIX >> fs on /dev/sdc when asked, not on /dev/sdc1 or anything else (note that >> fdisk /dev/sdc shows rubbish like non-existing /dev/sdc4 partition of >> exotic type and size). ELKS's Partition Check also shows rubbush bda4 >> partition of a very wrong size. >> >> 2. Root fs mount fails asking me to insert rootfs floppy: >> >> FAT: can't read super >> VFS: Insert root floppy and press ENTER >> >> Fortunately, I still have one. Yet during that, good old problem with >> mounting on-card fs appeared again: >> >> minix: unable to read sb >> mount failed: Invalid argument >> >> I suspect it tried to mount non-existing /dev/bda1 or wrong /dev/bda4 >> partition as suggested by misleading Partition Check >> >> When I finally reached the shell, I managed to mount MINIX fs anyway, just >> by doing: >> >> mount /dev/bda /mnt >> >> and it just worked, all the files and directories were there! >> >> Cheers, >> Paul >> >> On Thu, 6 Feb 2020, Paul Osmialowski wrote: >> >>> Some more update: >>> >>> I've compiled FAT support into kernel. Then I've also built HD image with >>> FAT filesystem (non-bootable), in facts, what have been built was not >>> binary image, it was rather rootfs in the 'target' directory. I've created >>> partition table on the 32MB CF card with DOS partition and formated the >>> partition with FAT16 filesystem (all using FreeDOS booted from floppy). >>> Then I've rebooted the machine with ELKS bootable floppy and this time... >>> the rootfs was mounted by init into '/mnt' mountpoint. So the HDD support >>> isn't that entirely bad in ELKS and we're nearly there! What I also >>> immediately noticed is that this system lacks 'chroot' command... >>> >>> Cheers, >>> Paul >>> >>> On Thu, 6 Feb 2020, Paul Osmialowski wrote: >>> >>>> Hi Marc, >>>> >>>> Now it prints: >>>> >>>> C=0x3C H=0x10 S=0x3F >>>> >>>> Following this, I've tried to build HD boot image with 63 sectors, 16 >>>> heads and 60 tracks (cylinders), but it still dies at '....4!'. >>>> >>>> Also, when I booted ELKS from floppy again, I noticed it tried to mount >>>> filesystem on the card with the image mentioned above that I left in the >>>> CF adapter. It failed eventually as such: >>>> >>>> Mounting FAT filesystem: hd: error: AX=0x04 >>>> BIOSHD: I/O error >>>> dev 301, sector 2 >>>> minix: unable to read sb >>>> mount failed: Invalid argument >>>> >>>> This 'Mounting FAT filesystem' message is kinda misleading: I didn't >>>> compile FAT support into the system, and the image on CF card has MINIX >>>> filesystem installed. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, 5 Feb 2020, Marc-F. Lucca-Daniau wrote: >>>> >>>>> 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 >>>>>>>>>>>>>>>>         > > > > > > > > > > > > > > >>>>>>>>>>>>>>>>         > > > > > > > > > > > > > > >>>>>>>>>>>>>>>>         > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>