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