Re: Cannot boot the real thing from HDD

["Marc-F. Lucca-Daniau" <mfld.fr@gmail.com>]

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
>>>>>>>>>>>>>>>>> <pawelo@king.net.pl> 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
>>>>>>>>>>>>>>>>>            > > > > > > > > > > > > > >
>>>>>>>>>>>>>>>>>            > > > > > > > > > > > > > >
>>>>>>>>>>>>>>>>>            >
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>