Re: Cannot boot the real thing from HDD
"Marc-F. Lucca-Daniau" <[email protected]> Fri, 24 Jan 2020 22:05:50 +0100
| Newsgroups | org.kernel.vger.linux-8086 |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > >>>> >>>>