Re: Cannot boot the real thing from HDD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Kernel]     [Linux ia64]     [DCCP]     [Linux for ARM]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux