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, 12 Feb 2020 20:39:21 +0100 Message-ID: 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> <111e642f-de53-c70f-4bab-bb9efafc6004@gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=VvBcMRFuCQLY6w7IO1zCCAjNMYIWsRkwZG0YHpbNGDc=; b=MQJRCl7U5G9/ONN4HRDFyX6GR/T4ETFY+sIUYGnzyXJzpd1Ytjc26Qm6+uRfD4lv3C pzw31yxZ6DD50SFm0OciRECRZJ3p0idXI3vGUuotQrB4oa0+ccCKcP6/0vnAOLozVgIw sNd0+RTYAuzHKAVFFqwOAO0xpRN2oAmjZH/3CKedsqBevh/vpTB7N/nsy3C/GkmF34NQ Hc+0ICq7nGlLCuqbRdTnSRsRWSADPZjhTgpzn6intd3ZJKYnxenfNvp199h83+4W6RO4 M2HxnnsCG/IyeIh9Ol74IkiWYx2TZJcG2sTftvCNqcT/Nv2nWsMcpo13DQH7jO/b7i0Y +zxw== In-Reply-To: <111e642f-de53-c70f-4bab-bb9efafc6004@gmail.com> Content-Language: fr-FR Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8"; format="flowed" To: Paul Osmialowski Cc: ELKS Hello Paul, Regression should be fixed now by latest commits. I selected CONFIG_IMG_HD, set CHS to 80/2/18 and size to 1440 blocks (to mimic a floppy). After modifying 'qemu.sh' to boot on 'image/hd.bin', got the ELKS login prompt. So closing the issue, unless you still have the problem. Thanks, MFLD Le 11/02/2020 à 21:38, Marc-F. Lucca-Daniau a écrit : > 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 >>>>>>>>>>>>>>>>>            > > > > > > > > > > > > > > >>>>>>>>>>>>>>>>>            > > > > > > > > > > > > > > >>>>>>>>>>>>>>>>>            > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>