26.04 12:25
[#1]
scsi.device
Czy może ktoś wie/pamięta jakie polecenia (w sensie io_Command) realizuje scsi.device? Te z trackdevice (TR_#?) też?
27.04 17:33
[#3]
Re: scsi.device
@krru, post #1
Sam sobie odpowiem bo znalazłem opis na stronach AROSa i to nawet zadziałalo:
Na stronie https://en.wikibooks.org/wiki/Aros/Developer/Docs/Devices w rozdziale 4.4
opisano, co trzeba zaimplentować by takie najprostsze scsi.device zadziałało. Zacytuje:
4.4. A MINIMAL DISK COMMAND SUBSET
It is clear that to implement a full Amiga disk driver supporting removable media is a considerable task, and I don't even pretend to know all that is required. But if all you want is a simple hard disk driver, a very small subset of the commands is sufficient. To begin with, Expunge() can be stubbed out to always return zero, indicating a delayed expunge which will never get done. AbortIO() can be stubbed out to always return a nonzero result, indicating that it failed. Unit structures can be done away with; you can store anything in the "io_Unit" field of the I/O request. In my own device driver I just store the SCSI device number and a few flags there. You can just return I/O error #20 (general catch-all) for anything that went wrong, except possibly unimplemented commands. Quick I/O need not be done; just always clear IOF_QUICK and forget about it. Send all I/O requests to a single internal task for processing. Finally, the commands can be implemented as follows:
CMD_READ, CMD_WRITE: implement fully
TD_FORMAT: same as CMD_WRITE
TD_GETDRIVETYPE: return 3.5" drive
CMD_RESET, CMD_UPDATE,
CMD_CLEAR, CMD_STOP,
CMD_START, CMD_FLUSH,
TD_MOTOR, TD_SEEK,
TD_REMOVE, TD_CHANGENUM,
TD_CHANGESTATE,
TD_PROTSTATUS,
TD_ADDCHANGEINT,
TD_REMCHANGEINT: clear "io_Actual" and return
Others: reject with IOERR_NOCMD
The resulting driver works perfectly with fast and slow file systems, and all the disk edit/repair utilities I've tried it with. If you are bringing up a hard disk from scratch, you can always get a hack driver to work, then write a "proper" one with the hard disk running.
Na stronie https://en.wikibooks.org/wiki/Aros/Developer/Docs/Devices w rozdziale 4.4
opisano, co trzeba zaimplentować by takie najprostsze scsi.device zadziałało. Zacytuje:
4.4. A MINIMAL DISK COMMAND SUBSET
It is clear that to implement a full Amiga disk driver supporting removable media is a considerable task, and I don't even pretend to know all that is required. But if all you want is a simple hard disk driver, a very small subset of the commands is sufficient. To begin with, Expunge() can be stubbed out to always return zero, indicating a delayed expunge which will never get done. AbortIO() can be stubbed out to always return a nonzero result, indicating that it failed. Unit structures can be done away with; you can store anything in the "io_Unit" field of the I/O request. In my own device driver I just store the SCSI device number and a few flags there. You can just return I/O error #20 (general catch-all) for anything that went wrong, except possibly unimplemented commands. Quick I/O need not be done; just always clear IOF_QUICK and forget about it. Send all I/O requests to a single internal task for processing. Finally, the commands can be implemented as follows:
CMD_READ, CMD_WRITE: implement fully
TD_FORMAT: same as CMD_WRITE
TD_GETDRIVETYPE: return 3.5" drive
CMD_RESET, CMD_UPDATE,
CMD_CLEAR, CMD_STOP,
CMD_START, CMD_FLUSH,
TD_MOTOR, TD_SEEK,
TD_REMOVE, TD_CHANGENUM,
TD_CHANGESTATE,
TD_PROTSTATUS,
TD_ADDCHANGEINT,
TD_REMCHANGEINT: clear "io_Actual" and return
Others: reject with IOERR_NOCMD
The resulting driver works perfectly with fast and slow file systems, and all the disk edit/repair utilities I've tried it with. If you are bringing up a hard disk from scratch, you can always get a hack driver to work, then write a "proper" one with the hard disk running.
28.04 06:47
[#5]
Re: scsi.device
@Norbert, post #4
Na zwykłem Amidze 1260 - czyli AmigaOS. Sprawdzałem kolejno HDToolBox, SCSIMounter, i zwykłe praca pod systemem.
I jeszcze - do tej listy trzeba dopisać HD_SCSICMD czyli wysłanie bezpośredniego polecenia SCSI. Zaimplementowałem odpowiedz na READ CAPACITY, INQUIRY, READ DEFECT, TEST UNIT READY. Można by jeszcze odczyt geometrii dysku i wszystko by działało bez żadnych komunikatów a tak to HDToolBox przy odczycie parametrów dysku sygnalizuje, że nie wie jak duża jest ścieżka i musi się domyślać.
Ostatnia aktualizacja: 28.04.2025 06:54:03 przez krru
I jeszcze - do tej listy trzeba dopisać HD_SCSICMD czyli wysłanie bezpośredniego polecenia SCSI. Zaimplementowałem odpowiedz na READ CAPACITY, INQUIRY, READ DEFECT, TEST UNIT READY. Można by jeszcze odczyt geometrii dysku i wszystko by działało bez żadnych komunikatów a tak to HDToolBox przy odczycie parametrów dysku sygnalizuje, że nie wie jak duża jest ścieżka i musi się domyślać.
Ostatnia aktualizacja: 28.04.2025 06:54:03 przez krru
05.05 17:34
[#6]
Re: scsi.device
@krru, post #5
Wracam do tematu, ale z trochę innej strony. Jak zauważyłem OpenDevice, zarówno dla wewnętrznego scsi.device jak i dla 1230scsi.device (moduł scsi do kart turbo Phase V) zwraca wartość 32 przy próbie otwarcia unitu, którego nie ma (nie jest podpięty dysk). Trochę to dziwna wartość - normalnie kody błędów są ujemne, a różne przykłady użycia OpenDevice sprawdzają tylko czy wynik == 0. 32 wygląda jak wynik 0, ale z jakąś flagą ustawioną. Gdzie można o tym poczytać, jakieś inkludy to opisujące?
05.05 19:23
[#7]
Re: scsi.device
@krru, post #6
OpenDevice gwarantuje tylko, ze udane wykonanie operacji zwraca 0, w innym przypadku zwracany jest kod bledu z pola io_error, otrzymany od urzadzenia. W tym przypadku zwrocona wartosc to 32 = TDERR_BadUnitNum.
Bledy o kodach <0 pochodza z systemu - np jakbys dla OpenDevice podal nazwe nieistniejacego urzadzenia, to bys dostal kod bledu -1. Jesli urzadzenie istnieje ale unit nie, to dostajesz kod bledu, zwrocony przez urzadzenie.
Wiecej o devices dowiesz sie z ROM Kernel Reference Manual - Devices.
Ostatnia aktualizacja: 05.05.2025 19:38:46 przez docent
Bledy o kodach <0 pochodza z systemu - np jakbys dla OpenDevice podal nazwe nieistniejacego urzadzenia, to bys dostal kod bledu -1. Jesli urzadzenie istnieje ale unit nie, to dostajesz kod bledu, zwrocony przez urzadzenie.
Wiecej o devices dowiesz sie z ROM Kernel Reference Manual - Devices.
Ostatnia aktualizacja: 05.05.2025 19:38:46 przez docent
wczoraj 06:32
[#9]
Re: scsi.device
@krru, post #8
Czyli, wracając do początkowego pytania, to w sumie tak, scsi.device nie tylko realizuje polecenia TD_*, te z trackdisk.device, ale i używa kodów błędów używanych i zdefiniowanych w trackdisk.device. scsi.device jest jakby rozszerzeniem trackdisk.device. W sumie to plik devices/scsidisk.h powinien inkludować devices/trackdisk.h
wczoraj 13:44
[#10]
Re: scsi.device
@krru, post #9
scsi.device jest jakby rozszerzeniem trackdisk.device
Mysle, ze zadecydowalo o tym lenistwo i podobienstwo od strony technicznej - dyski hd niewiele sie roznily od flopow (sciezki, glowice itp.) wiec zamiast utworzyc osobny header typu hddisk.h, tak jak to zrobiono pozniej w przypadku cd (zobacz cd.h), wykorzystano gotowe definicje z trackdisk.h
W sumie to plik devices/scsidisk.h powinien inkludować devices/trackdisk.h
Nie powinien, bo scsidisk.h odpowiada za definicje, zwiazane z wysylaniem komend scsi do urzadzen - nie ma tam bezposredniego powiazania z konkretnymi komendami urzadzenia, tylko z generyczna definicja interfejsow/struktur do takiej komunikacji.