public inbox for linux-8086@vger.kernel.org
 help / color / mirror / Atom feed
From: "Marc-F. Lucca-Daniau" <mfld.fr@gmail.com>
To: Paul Osmialowski <pawelo@king.net.pl>
Cc: ELKS <Linux-8086@vger.kernel.org>
Subject: Re: Cannot boot the real thing from HDD
Date: Tue, 11 Feb 2020 21:38:23 +0100	[thread overview]
Message-ID: <111e642f-de53-c70f-4bab-bb9efafc6004@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.21.1.2002110036560.23407@localhost.localdomain>

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
>>>>>>>>>>>>>>>>            > > > > > > > > > > > > > >
>>>>>>>>>>>>>>>>            > > > > > > > > > > > > > >
>>>>>>>>>>>>>>>>            >
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>

  reply	other threads:[~2020-02-11 20:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LNX.2.21.1904141943280.11933@localhost.localdomain>
     [not found] ` <alpine.LNX.2.21.1904151809190.25824@localhost.localdomain>
     [not found]   ` <e10535c1-4751-7e9a-5f76-9cc631e4eb3c@gmail.com>
     [not found]     ` <alpine.LNX.2.21.1904162210400.4944@localhost.localdomain>
     [not found]       ` <6e26eeeb-c80a-c42b-f2af-91b8df146a5e@gmail.com>
     [not found]         ` <alpine.LNX.2.21.1904172300570.28634@localhost.localdomain>
     [not found]           ` <cf48f070-f306-4afa-8afa-3e5b338114e7@gmail.com>
     [not found]             ` <alpine.LNX.2.21.1904181343510.11093@localhost.localdomain>
     [not found]               ` <1c3b5526-66ae-5ed3-ecc2-b6e7f14b53ca@gmail.com>
     [not found]                 ` <alpine.LNX.2.21.1.1912161352140.19666@localhost.localdomain>
     [not found]                   ` <alpine.LNX.2.21.1.1912171117001.25658@localhost.localdomain>
     [not found]                     ` <f62d11b1-8e42-cbd9-d466-b4b60c5c18ea@gmail.com>
     [not found]                       ` <alpine.LNX.2.21.1.1912172310001.28757@localhost.localdomain>
     [not found]                         ` <CACpuWUnxxZr=8i0srFGkSPPLzrhMxMVBF1xXbh6ZXaG2ORS8Tw@mail.gmail.com>
     [not found]                           ` <alpine.LNX.2.21.1.1912182337240.24813@localhost.localdomain>
     [not found]                             ` <alpine.LNX.2.21.1.1912182347540.24813@localhost.localdomain>
     [not found]                               ` <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com>
2020-01-24 21:05                                 ` Cannot boot the real thing from HDD Marc-F. Lucca-Daniau
2020-01-30 19:51                                   ` Paul Osmialowski
2020-01-30 21:43                                     ` Marc-F. Lucca-Daniau
2020-02-01 10:28                                       ` Marc-F. Lucca-Daniau
2020-02-03 16:59                                         ` Paul Osmialowski
2020-02-03 18:52                                           ` Marc-F. Lucca-Daniau
2020-02-03 22:05                                             ` Paul Osmialowski
2020-02-03 22:09                                               ` Paul Osmialowski
2020-02-05 15:37                                                 ` Paul Osmialowski
2020-02-08  9:35                                                   ` Marc-F. Lucca-Daniau
2020-02-08 12:58                                                     ` Paul Osmialowski
2020-02-05 19:26                                               ` Marc-F. Lucca-Daniau
2020-02-05 23:45                                                 ` Paul Osmialowski
2020-02-06 10:07                                                   ` Paul Osmialowski
2020-02-08 13:08                                                     ` Paul Osmialowski
2020-02-10 23:38                                                       ` Paul Osmialowski
2020-02-11 20:38                                                         ` Marc-F. Lucca-Daniau [this message]
2020-02-12 19:39                                                           ` Marc-F. Lucca-Daniau
     [not found]                                                             ` <alpine.LNX.2.21.1.2002122207100.31423@localhost.localdomain>
     [not found]                                                               ` <CACpuWU=DhqB93KxhmD2jpueOUrAkSPVeMPmLnRq4_j=zLjfm5g@mail.gmail.com>
     [not found]                                                                 ` <alpine.LNX.2.21.1.2002122326370.561@localhost.localdomain>
2020-02-17 21:24                                                                   ` Marc-F. Lucca-Daniau
2020-02-17 21:27                                                                     ` Paul Osmialowski
2020-02-17 21:34                                                                       ` Paul Osmialowski
2020-02-20 23:21                                                                         ` Paul Osmialowski
2020-02-22 16:24                                                                         ` Derek Johansen
2020-02-22 16:38                                                                           ` Jody Bruchon
2020-02-22 17:19                                                                             ` Derek Johansen
2020-02-22 21:27                                                                               ` Paul Osmialowski
2020-02-21  9:11                                                                       ` Marc-F. Lucca-Daniau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=111e642f-de53-c70f-4bab-bb9efafc6004@gmail.com \
    --to=mfld.fr@gmail.com \
    --cc=Linux-8086@vger.kernel.org \
    --cc=pawelo@king.net.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox