Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Mar 2022 22:10:31 +0100 (CET)
From:      Wojciech Puchar <wojtek@puchar.net>
To:        Eugene Grosbein <eugen@grosbein.net>
Cc:        John-Mark Gurney <jmg@funkthat.com>, freebsd-hackers@freebsd.org
Subject:   Re: problem with USB-CD drive
Message-ID:  <8f255987-db8b-b1ee-3732-b587c35c9d40@puchar.net>
In-Reply-To: <cf405de9-0a86-79ee-698a-a4956b52c848@grosbein.net>
References:  <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> <20220302014925.GA88842@funkthat.com> <2de67fd5-40d9-55fc-18ea-671aa096bab5@puchar.net> <cf405de9-0a86-79ee-698a-a4956b52c848@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
>> The question is how to debug it on host side - what exactly is wrong.
>
> Use sysctl kern.cam.dflags to enable CAM-level debugging.


That's what i will do next week with access to the device.

It is not really a problem - end users use windows, unix users don't need 
to mount this image at all in fact. User level program to control this 
devices (using vendor specific SCSI commands) works fine on unix 
(FreeBSD and linux) windows and mac OS without problems.

For sure that's wrong response to some of few CD-specific SCSI commands i 
implemented. or maybe some missing.

More importantly - when i was implementing this it worked properly under 
FreeBSD in some point WITHOUT most SCSI command implemented (READ was 
implemented and few others).

Actually i implemented this reading SCSI specs but often - just doing 
camcontrol on real CD drive to see what to respond :)

And not implementing more than needed - all microcontroller side code, 
including all USB/SCSI handling, firmware update code with decryption AND 
CD image (decompressed on the fly) fits in PIC32MX bootloader space - 12kB 
;)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8f255987-db8b-b1ee-3732-b587c35c9d40>