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