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: Fri, 24 Jan 2020 22:05:50 +0100 [thread overview]
Message-ID: <4f903b5c-953f-74a5-8edf-6941a9b65c79@gmail.com> (raw)
In-Reply-To: <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com>
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
>>>> > > > > > > > > > > > > > >
>>>> > > > > > > > > > > > > > >
>>>> >
>>>>
>>>>
next parent reply other threads:[~2020-01-24 21:05 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 ` Marc-F. Lucca-Daniau [this message]
2020-01-30 19:51 ` Cannot boot the real thing from HDD 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
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=4f903b5c-953f-74a5-8edf-6941a9b65c79@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).