Re: Ways to report trace when boot panics [Was NetBSD 7.0 i386 panic during boot]

[Brett Lymn <blymn%internode.on.net@localhost>]

On Mon, Oct 12, 2015 at 09:32:13PM +0700, Robert Elz wrote:
> 
> Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> said:
>  | You don't need "just" a cable, but one with quite a bit logic in between.
>  | USB is not designed for host-to-host communication,
> 
> Thanks - that's the kind of info I was lacking, given I know nothing about
> USB...   I had naively assumed that something which calls itself a
> universal serial bus would actually have some of the characteristics that
> would justify such a name.
> 

But it does - it is exactly like an old school computer bus, it has one
controller (usually your computer) with devices connected to it.  It is
a pretty primitive bus, the controller has to poll all the devices on
the bus to see if they want to do something, there are no real
interrupts at all.  New devices on the bus are done using a bit of a
signalling dance involving deliberately breaking the protocol - very
much similar to a rs-232 break signal.  

> I was kind of anticipating there might be issues with USB power, but I
> had a vague understanding that it might be possible to control that.
> 

Power is fine, the standard allows for multiple devices to power the bus
the complexity is in the multiphase protocol required to put data across
the bus and that it is really only designed to have a single controller
on the bus and most computers expect to be that controller so they
aren't equipped to become a client on another controllers bus.  Also the
usb A to usb A cable is an illegal configuration according to the USB
spec - you can get them but they are not a common thing because it is a
breach of the spec.

> Also might be useful I guess, perhaps allowing one of those small systems
> to act as a console for any other system being debugged, but again, not
> really very general.   Lack of support (currently) isn't necessarily a problem,
> none of this currently has any support - any of it would require lots of
> code to be written.
> 

AFAIU you need hardware that supports OTG, I don't think it is a common
thing in most computer hardware.  So you would have to have a special
thing to make this work.

> Mayuresh  <mayuresh%acm.org@localhost> said:
>  | Even nicer if such device could be a smartphone,
> 
> That's looking like perhaps a better choice - phones are already "devices"
> rather than hosts aren't they?  And they are almost as common as USB, so
> requiring that would not be overly limiting.   Of course, I have no idea
> whether it is possible on those systems to get low level enough access to
> implement something like this.
> 

Yes, they are devices.  You could possibly get an implementation of MTP
(media transfer protocol) up and going to write out a file, most phones
support MTP I believe but it does mean doing the usb protocol and then
layering the mtp over the top.  First step would be to get a polled mode
USB transfer going, technically not impossible but it does mean a lot of
work for someone....

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.