search

thierer / sd2iec

Cloned from https://www.sd2iec.de
GNU General Public License v2.0
13 stars 5 forks source link

v1.0.0atentdead0-55-g91de152 - uiec.. after invalid directory goes to EEPROMFS #1

Closed dabonetn closed 2 years ago

dabonetn commented 2 years ago

C128 with Jiffydos, changing to invalid directory, the UIEC then reports a empty EEPROMFS with 13 blocks free.

thierer commented 2 years ago

I can't see how this could be caused by my changes. Are you sure this behavior is different from the original release? And is it even wrong (I never used the eepromsfs)? Which exact command on the C128 did you use to change to the "invalid" directory?

dabonetn commented 2 years ago

@cd:wrongname

Just tell it to go to a directory or diskname that doesn't exist.

dabonetn commented 2 years ago

My extended settings using the @"x" command iare

03,E02+:*+:I00:R,08,00

thierer commented 2 years ago

Can't reproduce. If I try to CD to a non-existent directory, I just get a FILE NOT FOUND error.

I suspect the CD might be a red herring. What might happen is that the sd card is unmounted because there's an error accessing it and then the sd2iec falls back to eepromfs.

dabonetn commented 2 years ago

Latest standard firmware works fine, Changing to non working directory returns file not found

Loading files and changing directories works on the modified firmware.

I reflashed the latest standard firmware and I'm using it with the same sd card. Hardware is Uiec from 10 years ago or so, internally mounted, so I can't see the board currently.

thierer commented 2 years ago

When you say "latest standard firmware" you're talking about the one from https://sd2iec.de/sd2iec-current-binaries.zip?

OneCheekyDevil commented 2 years ago

C128 with Jiffydos, changing to invalid directory, the UIEC then reports a empty EEPROMFS with 13 blocks free.

I've been trying to hack the LCD support into the latest un-official sources and getting the same problem. None of the changes i've been adding have anything to do with the SD card access - except when it comes to the hardware config specific to the SD2IEC device I'm using (Evo2). The config I'm using has been the same one from the original sources from purchase. This is really confusing me :/

I'm seeing the problem right after flashing the firmware from the stock screen. LOAD "$",8 brings up the below picture: https://postimg.cc/yknwyVMD

EDIT: Trying to flash my stock firmware still has the same problem. I'm hoping we haven't bricked it in any way :(

thierer commented 2 years ago

I've been trying to hack the LCD support into the latest un-official sources and getting the same problem.

So is this with a C128 / JiffyDOS as well?

EDIT: Trying to flash my stock firmware still has the same problem. I'm hoping we haven't bricked it in any way :(

This probably means it has problems accessing the SD card. What does LOAD $=P say? Can you still read it from a PC?

OneCheekyDevil commented 2 years ago

I have a C64. I also have jiffydos installed with dual boot. The problem exists in both jiffydos and stock rom (as seen in the picture).

The SD card is fully working on the PC as i can see all it's contents and copy the SD2IEC.BIN file to it to flash onto the device. When i turn on the 64 and it detects the new firmware, it'll flash it. But then i cant access the SD card anymore.

What puzzles me the most is that the stock firmware doesn't fix our problem. Maybe the problem is deeper into the hardware. Is there a way to flash a new bootloader, or a program (or hardware) to diagnose the fault ?

thierer commented 2 years ago

The SD card is fully working on the PC [...]

So I'd suggest you do a full backup before any more experiments, in case the firmware somehow corrupts the SD card contents.

Maybe the problem is deeper into the hardware.

I doubt it. My guess is the firmware doesn't like something about the SD card contents (which still might be the firmware's fault) and therefore ignores it. Do I get that right, the SD card never works (and never worked since flashing the new firmware) for you, no need for a CDto an unknown directory like for the OP?

What happens

OneCheekyDevil commented 2 years ago

_> So I'd suggest you do a full backup before any more experiments, in case the firmware somehow corrupts the SD card contents.

  • with a different SD card, possibly freshly formatted, if you can spare one?

Done and now using a newly fully formatted 2Gb card - still no difference

I doubt it. My guess is the firmware doesn't like something about the SD card contents (which still might be the firmware's fault) and therefore ignores it. Do I get that right, the SD card never works (and never worked since flashing the new firmware) for you, no need for a CDto an unknown directory like for the OP?

  • if you delete the the firmware files from the SD card after flashing? (Very wild guess, but the firmware files are at least something that's known to have changed on the card).

The SD card contents can always be seen on the PC. With the new card, i just have the firmware file and the sd2iec config disk. When inserted into the 64 and switched on, the SD2IEC sees the new firmware file and flashes it. Once flashed, all i can see on the SD card via the 64 is shown in the picture. If i switch off the 64 and switch it back on, the SD2IEC will ignore the firmware file as it hasn't changed (this has always been the case). Still no difference when trying to access the SD card. Interesting enough, I just tried removing the SD card and switching on the 64 - still the same result. Thus concluding after flashing firmware, card inserted or not equals same result as shown in picture.

  • if you compile the firmware without eepromfs? Will probably just cause a "file not found error" instead, but maybe worth a try.

Probably pointless as the SD card config is contained inside "\src\avr\arch-config.h" and they've had the same info from the stock firmware._

EDIT: And then all of a sudden, everything has started working again!!! I dont know what i did but i tried to flash your firmware one last time before deciding to throw the SD2IEC into the bin from frustration and it just worked - can access all the files on the SD card from the 64!!! Even Evo2 config and the LCD config that i hacked into your source is working!!!

I want to thank you for your patience. My appologies if i made you freak out over the possibility of bricking my unit.

Cant offer any solution to the OP as i dont know what magic i did to make everything work again, but I'm glad it is.

And again, Thank You! Thank you for creating the new loader routines, thank you for your patience, thank you for everything you bring to the community!

PXL_20220925_013107641

thierer commented 2 years ago

And then all of a sudden, everything has started working again!!!

That's good to hear, but I don't really trust such cases of magical healing, they tend to come back...

Was the firmware you ran before (I assume you never had any similar problems with it?) based on b8572fec1d81c403abc45f573619b8812e64fa30 or an earlier revision of the official firmware?

OneCheekyDevil commented 2 years ago

The last few versions i had was based on a SD2IEC-LCD fork of the original source found here:

https://github.com/SvOlli/sd2iec-lcd

My programming abilities is very limited, but with a little luck and a lot of copying/pasting, i was able to merge across the LCD portion into your source code to add support for my device - which doesn't seem to be supported anymore :(

jpcompton commented 2 years ago

I can report that I am also inexplicably ending up in EEPROMFS w/13 blocks free, and also once ended up in a directory with only a single unexplained AUTOSWAP.GEN file (but the SD card's "expected" number of bytes free.)

I just ended up in EEPROMFS by trying to CD into a directory that does exist on the card, though. I'm also having very little (possibly no) luck making @CD:(leftarrow) work.

Also on 55-g91*, uIEC hardware 3.2. The card is a 2GB Sandisk model that has lived in this uIEC for years.

@$=P produced a 30 SYNTAX ERROR. @CP produced 02 PARTITION SELECTED 01 00.

jpcompton commented 2 years ago

Okay, here's a formula. This particular machine is a 64C w/stock ROMs, using the Warp Speed 2.0 found in the Multi-Easy CRT image via KFF to provide a wedge which plays nice.

(power up) $ (I see the normal directory contents of my SD card) @CD:MMC (MMC is a directory with fun PRGs)

$ yields 1 "EEPROMFS " EE 2A 13 blocks free

@$=P yields

1 "SD2IEC      " IK 2A
0 "SYSTEM" SYS
1 "EEPROMFS" NAT

READY

If I @CP and then $, I sometimes still get the EEPROMFS, and sometimes get put into the actual MMC directory I originally asked for. Each time @CP returns 02 PARTITION SELECTED 01 00. There doesn't seem to be a magic number of times I have to @CP / $ before ending up in the correct place: it seems like it's worked correctly after 1, 2, or 3 attempts.

When I'm back in normal-land, @$=P now yields

1 "SD2IEC      " IK 2A
0 "SYSTEM" SYS
1 "" NAT
2 "EEPROMFS" NAT

READY

(and no, I've never encountered anything quite like this on the main branch firmware)

thierer commented 2 years ago

Thanks for the detailed report! I'm still stumped about which one of my changes could possibly cause this, though.

My best guess is that there's a problem accessing the card and this makes the sd2iec ignore it. Now the most likely reason for that would be that some specific content of the FAT filesystem on the card would trigger it. That it's intermittent for you invalidates that theory a bit and makes a timing issue with the low level SD access more likely, imo. But I can't see how that would be caused by any of my changes.

That you're the second person with this problem on a uIEC might point to a cause specific to this board. I'm not really familiar with the uIEC and its variants. Is yours one with one SD card (or CF?) and no ATA support?

As a first step: Could you please test the attached firmware? It's just a fresh build of the official firmware from b8572fe, to make sure it isn't caused by anything in my build environment.

sd2iec-1.0.0atentdead0-29-gb8572fe-m1281-uIEC3.bin.zip

Would you be able to compile the firmware yourself and possibly do a git bisect to find the offending commit?

jpcompton commented 2 years ago

Yes, these are uIECs with a single onboard SD card slot. It's exactly this: https://store.go4retro.com/commodore/uiec-sd/

I also have a uIEC rev 3.0, whose main difference I believe is in the SD card socket which was a physically different part whose discontinuation led to the 3.2 rev. I have decided not to expose both uIECs to experimental firmware just now. :)

I will test the attached firmware later today.

Would you be able to compile the firmware yourself and possibly do a git bisect to find the offending commit?

Uh. Only with a step-by-step recipe that I could employ on a rickety old ubuntu laptop. I am a userland caveman.

thierer commented 2 years ago

I have decided not to expose both uIECs to experimental firmware just now. :)

Fair enough :)

Uh. Only with a step-by-step recipe that I could employ on a rickety old ubuntu laptop. I am a userland caveman.

I could also build them and send them to you, if you would be willing to test a few. Though I'd suggest we would do that via email, so we don't spam this issue.

jpcompton commented 2 years ago

They don't make it easy to get to the email exchange portion on Github, do they? Just followed a Twitter account that appears to be you!

Since you were mentioning concern about SD card corruption above, do you want to provide those of us testing this issue with a recipe to start with a completely fresh SD card? I have a couple of candidates (one an older sub-GB card with nothing important on it, another a 32GB card that's never been used) I could put on that job. Tell us how you want it formatted, labeled, what kind of file/directory structure to put on it for testing purposes, and then at least we're all starting from what should be a reasonably comparable baseline.

thierer commented 2 years ago

They don't make it easy to get to the email exchange portion on Github, do they?

I thought my email was visible on my profile, apparently it was not, but is now.

Tell us how you want it formatted, labeled, what kind of file/directory structure to put on it for testing purposes

That would be easier if I knew what to look for :) Right now I don't think it makes sense to put much effort into preparing a sd card. What you could do (and what I would have suggested, if you didn't mention that it works sometimes, which kind of makes it unlikely that it's really some specific content) is that you could try with a freshly FAT32 formatted card and see if it still happens. If it does not, it would indicate that the content actually matters and we could look start looking closer into this aspect.

jpcompton commented 2 years ago

0-29-gb* appears to work perfectly fine on my uIEC 3.2 with the card I used in previous tests: navigation (including leftarrow) all fine, no weird dropping into EEPROMFS, loading a long PRG is fine, etc.

OneCheekyDevil commented 2 years ago

This is a wild guess, but comparing the "eefs-ops.c" source files between an old version and your updated source, I've noticed a difference in line 318 :

OLD static void eefs_format(uint8_t drv, uint8_t name, uint8_t id) {

NEW static void eefs_format(path_t path, uint8_t name, uint8_t *id) {

could the error be here ? (either in the change from uint8_t to path_t, or the fact that there's a added asterix in your updated code?)

thierer commented 2 years ago

could the error be here ?

Thanks for the heads up, but that's correct. I had to change the format() function's signature to support creating d64 images on the FAT filesystem. This affects all filesystems.

Also, I'm confident the problem has nothing to with the eepromfs. That the firmware falls back to it is just a symptom.

thierer commented 2 years ago

Should be fixed by 1.0.0atentdead0-59-g5f6521d.

Thanks to @jpcompton for the help investigating!

OneCheekyDevil commented 2 years ago

I realised this is closed, but i was researching something else and came across this post by accident: https://www.forum64.de/index.php?thread/68656-seltsames-verhalten-bei-einer-sd2iec-evo2/&pageNo=1

It seems the fault might be hardware related. Mine could've been dirty contacts that sorted themselves out from the constant pull out / push in during testing phases.

Again, I appologise for any un-necessary stress i may have caused.