Re: Cannot boot the real thing from HDD

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

 



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