Closed ddraig68k closed 1 year ago
It's also possible the failure is coming from the user space corrupting something or something else that happens to show due to differences in the binaries involved. The joy of a non memory protected system and debug. It'll also potentially happen if there are disk I/O errors but you don't seem to log any and it's mounted r/o.
Is your port and some hardware info visible anywhere so I can take a look and maybe also knock up an emulator to see what's going on with some traces ?
I haven't had a look at your emulator, will have to give it a try.
I've tried building the code using GCC 6 and GCC 9, is there any specific version of the compiler that should be used?
Hardware information can be found here and schematics are on this site and KiCAD files are on Github. For the FUZIX code, i've added a platform-ddraig68k folder with my code, it's mostly based on the rc2014-68008 code. So far i've only added support for the serial port, IDE and RTC.
Thanks for looking, let me know if there's anything you need to know.
gcc version shouldn't matter. And if it did move mysteriously by version it wouldn't surprise me if that was just how the memory layout shifted not the compiler. I'll try and take a look this weekend see if I can make an emulator for your board and duplicate the behaviour.
Don't see anything obvious looking at the code. It does make a lot more use of interrupt vectoring, priority etc on that platform but I don't immediately see why that would manifest bugs down to user space.
For emulation is there a ROM binary somewhere and description of how the address 0-7 fetch is handled ?
Can't duplicate this locally with tiny68k and a current build, can you share your filesys.img anywhere ?
I've uploaded the filesys.img file here and the ROM file can be found here or there's a much simpler monitor program here
The first 4 bytes are read from ROM. U401 on the board is used to count the first 4 address reads and the BOOTROM flag is used by the CPLD decoding to fetch the bytes from the ROM at address 0xF80000.
Ok much to my surprise if I use your userspace it bombs, if I use mine it does not.
I am using
$ m68k-elf-gcc -v Using built-in specs. COLLECT_GCC=m68k-elf-gcc COLLECT_LTO_WRAPPER=/opt/gcc10-68k/libexec/gcc/m68k-elf/10.3.0/lto-wrapper Target: m68k-elf Configured with: ../gcc-10.3.0/configure --target=m68k-elf --prefix=/opt/gcc10-68k --disable-threads --enable-languages=c --disable-shared --without-headers --disable-libquadmath --disable-libssp --disable-libgcj --disable-gold --disable-libmpx --disable-libgomp --disable-libatomic --with-cpu=68000
This is what I have for GCC. I'll try it with GCC 10 and see if there's any difference
$ m68k-elf-gcc -v Using built-in specs. COLLECT_GCC=m68k-elf-gcc COLLECT_LTO_WRAPPER=/opt/m68k-elf/libexec/gcc/m68k-elf/9.5.0/lto-wrapper Target: m68k-elf Configured with: /home/steve/code/m68k-elf-toolchain/projects/gcc/configure --prefix=/opt/m68k-elf --target=m68k-elf --enable-languages=c,c++,lto --enable-version-specific-runtime-libs --disable-libssp --disable-nls --disable-threads --disable-libmudflap --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --with-newlib --with-headers=/home/steve/code/m68k-elf-toolchain/projects/newlib-cygwin/newlib/libc/include/ --disable-shared --src=../../projects/gcc Thread model: single gcc version 9.5.0 (GCC)
Nothing particularly strikes me as odd there. The newlib stuff shouldn't in theory get sucked in (unless I messed up) and the --with-cpu=68000 I have ought to be covered by -m68000 in all my make rules but that might be wrong somewhere I guess.
It's quite strange what's going on. I've tried GCC 10 as well now and that didn't make any difference so I don't believe it's an issue with the compiler. The kernel seems to build and run correctly and it even runs /init and gets to the login prompt, so it would appear that some of the executable side of it is working ok.
I managed to have a quick look at the emulator code you have for the tiny68k, i don't think it should be too difficult to get something up and running as an emulator for my computer so will give that a try and see what happens.
Your filesystem fails the same way on tiny68k. In both cases stuff is going wrong fairly early on as it fails to run much of the /etc/rc script. Interestingly it fails exactly the same way in both cases.
Just wondering what the parameter values for the rootfs-68000-32 image would be for
D:\imgmount c ROOTFS~1 -size bps,spc,hpc,cyl
for dosbox
All the emulator images (as opposed to the raw disk images) have the ATA identify block (512 bytes) at 512 bytes into the file. That gives you all the disk geometry data you need.
If I remember rightly it'll be CHS of 977/5/16 and 512 byte sectors
sectors
I think that translates to -size 512,16,5,977 but I get imgmount c ROOTFS~1 -size 512,16,5,977 Can't create drive from file.
Sorry - not sure why I'm trying to run a 68000 on dosbox - meds need adjusting!
I've got FUZIX booting from a disk image but when I do using the built disk image I get the following error.
If I use the rootfs-68000-32 image from the website then it does boot correctly. The way i'm building the image is based off the rc2014-68008 platform and is writing the created filesys.img to block 2048:
Is there any special steps that are needed for creating the 68000 disk image?