Operation comparison at startup between v1.1 and RP2040 #128
Comments
|
To debug whether this is a problem with synchronous mode, can you try with |
|
I tried setting Excerpt from v1.1 Excerpt from RP2040 |
|
That's interesting. The bus reset is most likely coming from the host during the command reception (bus reset terminates the command reading, which is why it gets logged immediately after the reset). I'm currently trying to be on a vacation so in-depth debugging will have to wait. |
|
Firmware 1.1.5 also causes a bus reset at the timing of Inquiry, but TestUnitReady is notified after that. In any case, it cannot be recognized from the BIOS because Inquiry is NG. Please check back after the holidays are over. |
|
The "TestUnitReady" is probably just due to the reset - it has the 0x00 command code, and the bus reset aborts the command reading. In any case the command won't be handled because the bus reset causes immediate abort of the command. I'll try to compare the SCSI bus waveforms of RP2040 and V1.1 when I get back from vacation in January, but it may be that there is something weird that occurs only on that platform. |
It seems that some hosts like PC-9821 have low tolerance for delay between the different phase signals toggling. The Cortex-M0 processor slow bit twiddling instructions caused around 100 ns delay before this change. The signals are now toggled simultaneously.
|
Sorry for the delay, it took me longer than expected to get back to this. Studying the waveforms, the only significant difference I see at this point of communication is that RP2040 has longer delay between toggling @Kurist2010 I have a test build here that you could try (download zip at bottom of page): |
|
I haven't changed the SCSI HA (AHA-2940UW/J) settings, but the LED lights up momentarily at the timing when it seems that an inquiry was made from the BIOS when rebooting, but there was no access log. Of course there is no recognition from BIOS. Just to be sure, I also tried 1.15 and 1.20, but it's the same. If you access RP2040 using a tool (SCCTL) after starting DOS, the debug log will be output, so I think there is no connection difference. |
|
Hmm, interesting - especially as I'm also using AHA-2940UW to test, but on a more modern machine and running Linux. Even if there is no visible difference, could you get me the debug log from the test build? |
|
I got the debug log for 1.2.1-devel. This is the state after device scanning at MS-DOS startup (not recognized when ASPI8DOS.SYS is installed) and SCCTL startup. Some parts are in Japanese, but you should be able to understand what you need.
|
|
Ok, it seems to get further, because there is no I assume in this newest log, termination is disabled on purpose, i.e. you have other device doing termination? It seems to have trouble reacting to the selection pulse now - a quite different problem than in the earlier logs where responding to selection worked ok. Would it be possible for you to try the new firmware in a configuration equivalent to your earlier tests, i.e. at the terminating position? Just in case that is somehow affecting the signal characteristics. |
|
Since I wanted to boot MS-DOS, I connected RaSCSI after RP2040 and turned off the terminator. |
RP2040: Reduce delay between phase signal changes (#128)
|
@Kurist2010 it seems you tested the development build before the pull request was merged. Can you please re-download the nightly image, and try again? Thanks |
|
@aperezbios Based on timestamp (Jan 31 2023 10:12:56) it is the correct build from the development branch that I linked. I don't currently know what could be causing this problem, as far as I can tell there should be no difference between RP2040 and GD32 models that should affect this. |
|
I checked with nightly image 2023-02-09 (fd9839b), but there was no particular change. |
|
Nightly image 2023-03-02 (4c17507) also had a bus reset. |
|
@Kurist2010 bus resets are a normal part of SCSI, and any SCSI controller can re-set the bus at any time, for any reason, so that in and of itself isn't an issue. |
|
The issue here seems to be that something is making the SCSI host unhappy enough that it decides to abort the request with a bus reset. Because the reset is happening only 8 milliseconds after the synchronous mode reply, it is not any timeout. |
|
Looking closely at the log, v1.1 shows BUS_BUSY between BUS RESET and SELECTION: 0, but with RP2040, SELECTION: 0 suddenly appears after BUS RESET. What is the difference? |
|
It's probably just random variation whether it has time to notice & log the BUS_BUSY state before the selection signal occurs (there is less than a millisecond time between them). It has no difference for operation, it is only logged to aid debugging in cases where host has problems selecting the device. |
|
In #172 it was noticed that RP2040 model was more sensitive to power supply variations than ZuluSCSI V1.1. If you are still interested in testing and if the previous tests were by SCSI cable termination power, it is worth trying either the 4-pin power connector or USB power. Though the error behavior in your case is quite different, so this is just a guess. |
|
It was only a power supply for termination. |
|
Ok, thanks for info! I still hope to figure this out eventually, but currently I don't know what could possibly be causing the problems. |
|
@Kurist2010 can you try the latest firmware, which I released today? You can grab it here ZuluSCSI_RP2040_2023-05-04.bin v2023.05.04 implements new voltage monitoring and logging, which was introduced in this commit 4cc78ca |
|
I took a debug log without an external power supply. |
|
@PetteriAimonen any idea what the two unknown SCSI commands are, in the log above? |
|
@aperezbios It's the same behavior as earlier, the host terminates request by issuing BUS RESET so the command is never received or processed, and is instead just garbage from the bus. So something weird has to be happening in selection or the message phases. It is probably related to this device re-issuing |
|
@Kurist2010 If you have time, here is a test build with more debug messages related to SCSI phase changes that you could try on the RP2040 (download zip at bottom of page): This seems to be related to how the two negotiations (SCSI wide bus negotiation and SCSI sync mode negotiation) are executed in same transaction. The above build tries to debug what happens there. For some reason my AHA-2940UW doesn't send the wide bus negotiation at all, even though I have enabled it in the SCSI bios. Trying to disable wide mode in the Adaptec bios is worth trying also, though the negotiation should really work. |
|
設定は前回と同様で試してみました。 |
|
This is when the wide setting is disabled. |
|
Thanks a lot for the log. Looks like it happens even with a single MESSAGE_IN phase then. So much for that theory, but I'll try to figure something out. |
|
Hmm, does the same happen if also synchronous mode gets disabled in the SCSI bios? This could help differentiate whether the problem has anything to do with the MESSAGE_IN phase at all. |
|
In addition to wide setting disabled, asynchronous setting. |
|
For reference, if you start MS-DOS 6.2 from the FD after checking the BIOS, you can access SCSI from the DOS kernel. There is no problem with inquiries at this time. Also, the SCSI device is not recognized by his BIOS, so I can't use it without a device driver. This is the continuation of the above log. |
|
@Kurist2010 does this still happen with recent versions of the firmware, or is this resolved. |
|
The issue was not resolved in the 2023-10-31 version. |
This is the debug log when the same SD card is started with 1.1, RP2040 and PC-9821 respectively. RP2040 is not recognized by PC-9821.
After negotiating at 10MB/s, the RP2040 somehow resets the bus.
The text was updated successfully, but these errors were encountered: