Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does harddrive images work? #63

Open
pawelka opened this issue Oct 1, 2024 · 5 comments
Open

Does harddrive images work? #63

pawelka opened this issue Oct 1, 2024 · 5 comments

Comments

@pawelka
Copy link

pawelka commented Oct 1, 2024

First of all, great project!!!

I tried to test harddisk image. In OSD I was able to select hd.img and I saw in longs (on companion device) that it's reading something (many "SDC: sdc_read(0x3fc99404,5403,1)"), after that nothing happen, no diskdrive. I also try to restart, but only same log during loading and nothing else.

Is harddisk image is implemented on FPGA? Or it's only beginning of implementation in MCU (OSD)?

I tried 1.04 and 2.06 TOSes and I tested image with Hatari emulator before trying it on FPGA.

@ojaksch
Copy link
Contributor

ojaksch commented Oct 1, 2024

It's working fine since months. Not the fastest in the world, but working.
I'd check the SD card, wiring etc. I had a SD expansion cable while experimenting with the MiSTeryNano, while this is working in principle it turned out to be unreliable and failing sometimes. Changed it to known good and working SD card and ACSI was working fine again.

@harbaum
Copy link
Owner

harbaum commented Oct 1, 2024

The logs should tell you which device it's reading from and whether it's the floppy or the HDD. In case of the HDD you need a harddisk driver installed in you image. If that's present and being loaded you should immediately see its boot messages on the Atari ST screen.

@pawelka
Copy link
Author

pawelka commented Oct 11, 2024

First image which I tested doesn't have driver in it, but it works with emutos because it has driver in tos. So I tested with standard image 1.04 on hatari and image without driver doesn't work (according harbaum comment this is expected behaviour). I have another HDD image 1.5GB with multiple partitions to support tos 1.04, but fpga is rebooted before image is loaded and it takes long time before reboot :-/ Maybe there is some watchdog causing that. This big image work without any issue on HAtari and TOS 1.04

Additionally emutos doesn't work with FPGA, I got panic error with wrong address :-/

During loading big image I see 23x times message similar to this:
SDC: sdc_read(0x3fc99404,8607,1)
E (460754) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (460754) task_wdt: - IDLE0 (CPU 0)
E (460754) task_wdt: Tasks currently running:
E (460754) task_wdt: CPU 0: menu_task
E (460754) task_wdt: CPU 1: IDLE1
E (460754) task_wdt: Print CPU 0 (current core) backtrace

Backtrace: 0x4201E60A:0x3FC96420 0x4201EA20:0x3FC96440 0x4037779D:0x3FC96470 0x40379A11:0x3FCA7B70 0x40379181:0x3FCA7B90 0x4037919E:0x3FCA7BB0 0x403796C9:0x3FCA7BD0 0x40379846:0x3FCA7C10 0x4200EAA5:0x3FCA7C30 0x4200AEE4:0x3FCA7C80 0x4200AF11:0x3FCA7CA0 0x4200AF21:0x3FCA7CC0 0x420101E2:0x3FCA7CE0 0x420104BF:0x3FCA7D00 0x42010E01:0x3FCA7D20 0x42012F7C:0x3FCA7D40 0x4200B314:0x3FCA7D80 0x4200BEFC:0x3FCA7DD0 0x4200C25D:0x3FCA7DF0 0x4200CC24:0x3FCA7E10 0x4200CC71:0x3FCA7E30 0x4037BF45:0x3FCA7E60

SDC: sdc_read(0x3fc99404,8608,1)

and just before restart there is:
SDC: sdc_read(0x3fc99404,8734,1)
SDC: sdc_read(0x3fc99404,8735,1)
SDC: sdc_read(0x3fc99404,8736,1)
SDC: sdc_read(0x3fc99404,8737,1)
SDC: Link table ok
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.

Core 0 register dump:
PC : 0x40381eaa PS : 0x00060033 A0 : 0x80381880 A1 : 0x3fca7c10
A2 : 0x3fca81c0 A3 : 0x00000010 A4 : 0x000000ff A5 : 0x0000ff00
A6 : 0x00ff0000 A7 : 0x3fc9a6ec A8 : 0x3fc99ffc A9 : 0x00000001
A10 : 0x00000000 A11 : 0x00000013 A12 : 0x00000030 A13 : 0x00080000
A14 : 0x00000000 A15 : 0x0000cdcd SAR : 0x0000001c EXCCAUSE: 0x0000001d
EXCVADDR: 0x0000003c LBEG : 0x400556d5 LEND : 0x400556e5 LCOUNT : 0xfffffffb

Backtrace: 0x40381ea7:0x3fca7c10 0x4038187d:0x3fca7c30 0x40376409:0x3fca7c50 0x40376515:0x3fca7c70 0x40376545:0x3fca7ca0 0x403761ec:0x3fca7cc0 0x40376221:0x3fca7ce0 0x40382f8d:0x3fca7d00 0x400509e2:0x3fca7d20 0x40055634:0x3fca7d40 0x40055619:0x3fca7d60 0x4200b360:0x3fca7d80 0x4200befc:0x3fca7dd0 0x4200c25d:0x3fca7df0 0x4200cc24:0x3fca7e10 0x4200cc71:0x3fca7e30 0x4037bf45:0x3fca7e60

ELF file SHA256: 0e897e1f7

Rebooting...
���ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)
Saved PC:0x40375b64

Is it a limitation of ESP32 as companion MCU? Should I try other companion MCU?

@pawelka
Copy link
Author

pawelka commented Oct 24, 2024

I've tested additionally with BL616 and 1.5GB image works, a little bit slow during image selection, but after that works as expected. It looks like it's ESP32-S3 issue only.

@pawelka
Copy link
Author

pawelka commented Oct 26, 2024

ESP32-S3
I rebuilt the image with the sdc_debugf removal for each sector read, and the image loaded successfully, though its behavior is still a bit unusual. The image is 1.5 GB, so when selecting it in the OSD, the OSD blocks for a significant amount of time after displaying “Link table ok.” I saved the settings and restarted the ESP32 and FPGA, but it stalled in the COM FPGA thread, likely due to the image loading in the background. TOS loads, but the image isn’t visible. After reviewing the logs and seeing “Link table ok,” I tried restarting the FPGA alone, and the image then mounted successfully in TOS. It appears to be a race condition between the FPGA and MCU.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants