EtchedPixels / FUZIX

FuzixOS: Because Small Is Beautiful
Other
2.15k stars 271 forks source link

Creating 68000 filesystem image #933

Closed ddraig68k closed 1 year ago

ddraig68k commented 2 years ago

I've got FUZIX booting from a disk image but when I do using the built disk image I get the following error.

bootdev: hda1
Mounting root fs (root_dev=1, ro): OK
Starting /init
init version 0.9.0ac#1

 ^ ^
 n n   Fuzix 0.3.1
 >@<
       Welcome to Fuzix
 m m

login: root
login: unable to change owner of controlling tty

Welcome to FUZIX.

panic: inode freed.

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:

diskimage:
    # Make a blank disk image with partition
    dd if=$(FUZIX_ROOT)/Standalone/filesystem-src/parttab.40M of=$(IMAGES)/disk.img bs=40017920 conv=sync
    # Add the file system
    dd if=$(IMAGES)/filesys.img of=$(IMAGES)/disk.img bs=512 seek=2048 conv=notrunc
    cp ../fuzix.bin $(IMAGES)

Is there any special steps that are needed for creating the 68000 disk image?

EtchedPixels commented 2 years 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 ?

ddraig68k commented 2 years ago

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.

EtchedPixels commented 2 years ago

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.

EtchedPixels commented 2 years ago

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 ?

EtchedPixels commented 2 years ago

Can't duplicate this locally with tiny68k and a current build, can you share your filesys.img anywhere ?

ddraig68k commented 2 years ago

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.

EtchedPixels commented 2 years ago

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

ddraig68k commented 2 years ago

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)

EtchedPixels commented 2 years ago

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.

ddraig68k commented 2 years ago

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.

EtchedPixels commented 2 years ago

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.

madtom1999 commented 1 year ago

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

EtchedPixels commented 1 year ago

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

madtom1999 commented 1 year ago

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.

madtom1999 commented 1 year ago

Sorry - not sure why I'm trying to run a 68000 on dosbox - meds need adjusting!