zxdiv with DivMMC Future and +3: "init not found"

[ninakali]

Hello! I've been trying to make fuzix work on my +3 for a while. I have DivMMC Future running EsxDos 0.87.

I've tried kernels built from master (today) and 600f2cbc0ecbc01fbb5ca6c825fbabfa85f652f1 with z80 rootfs 0.3 and 0.4pre, with the same result:

The kernels were built with sdcc from the fuzix sdcc fork.

I have tried the kernel from 2019 built by bruxy.regnet.cz/8bit/fuzix/ - it is affected by #766. It finds the rootfs and init, and starts init, but then goes into loop saying "sd: failed, retrying.". Basically, the reason I've tried 600f2cbc0ecbc01fbb5ca6c825fbabfa85f652f1 is because it's around the date when @pawosm-arm mentioned that the OS now boots fine. So, I am wondering if it's something wrong with how I build the kernel...

Could you please help me to figure out what's happening?

Update: a) there is a regression for +3 and DivMMC, as FUZIX from Nov 2019 can start the init, even if fails later b) my toolchain works correctly c) current kernel can't even start the init with +3 and DivMMC

[ninakali]

FWIW, the partition table I have is

/dev/sde1          2048 4196351 4194304   2G  b W95 FAT32
/dev/sde2       4196352 6293503 2097152   1G  b W95 FAT32
/dev/sde3       6293504 6359039   65535  32M 7e unknown
/dev/sde4       6359040 6367231    8192   4M 7f unknown

I've built af6bd7bd19dcd12206da7bf5070d979c6de8530e with patch from https://github.com/EtchedPixels/FUZIX/issues/766#issuecomment-661948737 - with the same "init not found" error. I seriously suspect my toolchain now :/

I've read the partition back from the SD card and diff'ed with the rootfs file. The contents is identical, the size too.

[ninakali]

Hm, the build from 2019 doesn't work with 0.4pre rootfs -- "init not found" yet again. I'm going to try the newer kernel with 0.3 image once more. Maybe I just messed up something...

Upd: no luck, newer kernels keep saying "init not found" and place DivMMC in a weird state where reboot doesn't help the system to recover.

EsxDOS problem? Toolchain problem? Hardware problem? No Idea :(

[pawosm-arm]

Hey, but the boot device must be written full name (hda3 rather than just 3). Also, my story is different, I'm using ZXMMC and I was struggling with the issues specific to that storage device. Also since then, now I'm building rootfs using Standalone tools rather downloading it, so it always matches with the kernel. I haven't been booting the most recent FUZIX on +3 for a while, but it was buildable and workable a month or two ago.

[ninakali]

@pawosm-arm

No, 3 is the same as hda3: https://github.com/EtchedPixels/FUZIX/blob/70e28d1df6129ca5e676290ce7d9607190aa75ea/Kernel/start.c#L142 Fwiw, I've tried using hda3 with the same result.

If you have FUZIX.BIN from that build laying around, could you please share it with me? Having symbols and maybe object files could help, too, so I could find the difference between my build and yours, in case if it will work.

[pawosm-arm]

Yeah, I can share it (the build directory) with you, but I don't see how could it help. Last time it was built 22nd of January this year. The bootable image is in the .dsk file, which I'm copying to gotek device.

platform-zx+3.tar.gz

[ninakali]

@pawosm-arm Oh, you're building zx+3? I've been using zxdiv build instead, because last time I checked pure zx+3 didn't support DivMMC?

Oooh you've been using ZXMMC which seems to be a different thing altogether. Now I seeeeee.....

[pawosm-arm]

Indeed it's different. And I'm using +3 build as I'm running it on +3e hardware. AFAIK zxdiv is for Spectrum 128k with DivIDE.

[ninakali]

Ugh, tough pickle. I have +3 with DivMMC which is supposed to be sort of compatible with DivIDE... And it seems to be somewhat close to working, because the kernel finds the partition table just right, and on old kernels even reads init...

[pawosm-arm]

If the old kernel starts init, then it's clearly a regression.

[ninakali]

I recompiled FUZIX for zxdiv from November 2019 (8805b121e7065ca2aae0d765072251862b1296f4) using my toolchain, and it behaves exactly like the one built by @BruXy - finds the SD, mounts the disk and starts the init. Then, after a few seconds in the init procedure (and blinking pilot tones), it fails with repeated sd card errors.

I also booted the +3 floppy, it doesn't find SD, as expected.

In other words, a) there is a regression for +3 and DivMMC b) my toolchain works correctly c) current kernel can't even start the init with +3 and DivMMC

[ninakali]

So, I got a kernel that was known to mount the rootfs and start init, and I applied a part of the patch from #766 to it:

diff --git a/Kernel/dev/devsd.c b/Kernel/dev/devsd.c
index 4581295b..5a9b17e3 100644
--- a/Kernel/dev/devsd.c
+++ b/Kernel/dev/devsd.c
@@ -50,6 +50,8 @@ uint_fast8_t devsd_transfer_sector(void)
                     sd_spi_transmit_byte(0xFF); /* dummy CRC */
                     sd_spi_transmit_byte(0xFF);
                     success = ((sd_spi_wait(false) & 0x1F) == 0x05);
+                    if (success)
+                      while (sd_spi_wait(false) == 0x00) { }
                 }
             }
        }else

The divmmc.c code seemed to be working just fine. After rebuilding the kernel, I got the prompt!

Now it's probably worth investigating when it stopped working and why.

[EtchedPixels]

It should work. It's clearly getting to the point it starts loading init, which means the low level disk access was working (it read the partition tables, superblock etc already).

When you say you used the 0.4rc1 root fs is that the one you built with the kernel ? as the ABI has changed a bit during that period.

[EtchedPixels]

Works for me if I use the root fs built from git.

Do need to find a sane way to get "make diskimage" working on a spectrum

[EtchedPixels]

make diskimage added, that was fun

[ninakali]

Thank you! It was indeed my fault; rebuilding the latest kernel and the latest rootfs helped. I had to use separate compilers for rootfs (sdcc 4.0) and kernel (3.9 patched) though.