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>