Re: Cannot boot the real thing from HDD
"Marc-F. Lucca-Daniau" <[email protected]> Tue, 11 Feb 2020 21:38:23 +0100
| Newsgroups | gmane.linux.ports.x8086 |
|---|---|
| Message-ID | <[email protected]> |
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 >>>>>>>>>>>>>>>> <[email protected]> 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 >>>>>>>>>>>>>>>> > > > > > > > > > > > > <arch/io.h> >>>>>>>>>>>>>>>> > > > > > > > > > > > > causing link-time >>>>>>>>>>>>>>>> issue as >>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>> macros defined >>>>>>>>>>>>>>>> > > > > > > > > > > > > there >>>>>>>>>>>>>>>> > > > > > > > > > > > > are >>>>>>>>>>>>>>>> > > > > > > > > > > > > mistaken >>>>>>>>>>>>>>>> > > > > > > > > > > > > for functions >>>>>>>>>>>>>>>> (outb_p() and >>>>>>>>>>>>>>>> friends), >>>>>>>>>>>>>>>> adding missing >>>>>>>>>>>>>>>> > > > > > > > > > > > > #include >>>>>>>>>>>>>>>> > > > > > > > > > > > > <arch/io.h> >>>>>>>>>>>>>>>> > > > > > > > > > > > > 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 >>>>>>>>>>>>>>>> > > > > > > > > > > > > > > >>>>>>>>>>>>>>>> > > > > > > > > > > > > > > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>