piscsi: Mac Plus won't boot with SCDP attached
Info
-
Which version of Pi are you using: 4B
-
Which github revision of software: cf9a578c82 (v21.10.01)
-
Which board version: FULLSPEC
-
Which computer is the RaSCSI connected to: Macintosh Plus
Describe the issue
When attaching a DaynaPort SCSI/Link ethernet device via rasctl before booting the Mac, the Mac won’t boot similar to issue #40 where it shows a black screen. If the Mac is booted and the ethernet device is attached later, it works fine. This makes it difficult to use RaSCSI for both a hard drive (SCHD) and ethernet (SCDP), since the SCHD device has to be attached before booting but the ethernet has to be attached after a delay.
I’m assuming the Mac probes the SCSI bus during boot while looking for hard drives and gets a weird response from the ethernet device just like in #40 where the Lido driver caused issues.
Perhaps there’s a way to detect this activity and just ignore the probe in the ethernet device driver…
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 21 (10 by maintainers)
Commits related to this issue
- DaynaPort: Delay sending real ethernet traffic until Mac driver inits The Mac Plus tries to read a sector from the DaynaPort device at boot as if it were a hard drive. If we send actual ethernet dat... — committed to jcs/RASCSI by jcs 3 years ago
- DaynaPort: Ignore commands with a bogus control value All traffic from the DaynaPort will have a control value of 0xc0 or 0x80, so any commands that don't should be ignored. This helps the Mac Plus ... — committed to jcs/RASCSI by jcs 3 years ago
- DaynaPort: Ignore commands with a bogus control value All traffic from the DaynaPort will have a control value of 0xc0 or 0x80, so any commands that don't should be ignored. This helps the Mac Plus ... — committed to jcs/RASCSI by jcs 3 years ago
- DaynaPort: Ignore commands with a bogus control value All traffic from the DaynaPort will have a control value of 0xc0 or 0x80, so any commands that don't should be ignored. This helps the Mac Plus ... — committed to jcs/RASCSI by jcs 3 years ago
- DaynaPort: Ignore commands with a bogus control value All traffic from the DaynaPort will have a control value of 0xc0 or 0x80, so any commands that don't should be ignored. This helps the Mac Plus ... — committed to jcs/RASCSI by jcs 3 years ago
- DaynaPort: Ignore commands with a bogus control value (#433) All traffic from the DaynaPort will have a control value of 0xc0 or 0x80, so any commands that don't should be ignored. This helps the... — committed to PiSCSI/piscsi by jcs 3 years ago
- DaynaPort: Ignore commands with a bogus control value (#433) All traffic from the DaynaPort will have a control value of 0xc0 or 0x80, so any commands that don't should be ignored. This helps the... — committed to PiSCSI/piscsi by jcs 3 years ago
@marciot To give you a short answer: I also like to use Basilisk in the way that you describe. Basilisk II is able to connect to the same Netatalk server (over TCP only) running on the Pi. Netatalk is smart enough to save the resource fork on the Linux file system as separate files, and then merge them back together when copying back to a Mac. It works totally seamlessly.
But yeah, the Zero might struggle. Maybe you can run it on another Linux machine (or VM).
Anyhow, let’s stop getting off topic here. The https://tinkerdifferent.com/ forums could be a good place for these topics!