On Tue, Feb 13, 2018 at 03:07:11PM +0100, Martin Husemann wrote:
> On Tue, Feb 13, 2018 at 03:02:56PM +0100, Wolfgang Solfrank wrote:
> > What exactly do you mean with "can't use ttyU1"?
>
> The ttyU1 serial console is dead, no data in/no data out as far as I can
> tell. I'll debug/investigate
Hi,
It doesn't solve the generic (no pun intended) problem of raw ugen access to
arbitrary other devices, e.g. for use by USB over IP
http://usbip.sourceforge.net/
Of course, a better approach may be to add detach kernel driver functionality:
On Tue, Feb 13, 2018 at 03:02:56PM +0100, Wolfgang Solfrank wrote:
> What exactly do you mean with "can't use ttyU1"?
The ttyU1 serial console is dead, no data in/no data out as far as I can
tell. I'll debug/investigate this, as I have a good debug setup now.
Martin
Hi Martin,
Martin Husemann schrieb:
On Thu, Feb 08, 2018 at 07:15:55PM +0100, Martin Husemann wrote:
Seems to work for me as well:
root file system type: ffs
kern.module.path=/stand/i386/8.99.12/modules
ugen0 at uhub0 port 1 configuration 1 interface 0
ugen0: FTDI (0x9e88) SheevaPlug JTAGKey
On Thu, 8 Feb 2018, Martin Husemann wrote:
On Thu, Feb 08, 2018 at 05:22:18PM +0100, Wolfgang Solfrank wrote:
Hi,
with the attached diffs I'm able to attach my debug board like this:
ugen0 at uhub5 port 1 configuration 1 interface 0
ugen0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118),
On Thu, Feb 08, 2018 at 07:15:55PM +0100, Martin Husemann wrote:
> Seems to work for me as well:
>
> root file system type: ffs
> kern.module.path=/stand/i386/8.99.12/modules
> ugen0 at uhub0 port 1 configuration 1 interface 0
> ugen0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev
On Thu, Feb 08, 2018 at 05:22:18PM +0100, Wolfgang Solfrank wrote:
> Hi,
>
> with the attached diffs I'm able to attach my debug board like this:
>
> ugen0 at uhub5 port 1 configuration 1 interface 0
> ugen0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00,
> addr 3
> uftdi0
Hi,
with the attached diffs I'm able to attach my debug board like this:
ugen0 at uhub5 port 1 configuration 1 interface 0
ugen0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, addr 3
uftdi0 at uhub5 port 1 configuration 1 interface 1
uftdi0: OpenMoko (0x1457) Debug Board
Hi again,
- add a variation of uftdi that attaches on single interfaces (Wolfgang,
can you share your code, even if it does not work with -current?), and
either always use this variant, or use this variant on chips matched
by above mentioned quirks table.
See attached.
Hi Martin,
- add a variation of uftdi that attaches on single interfaces (Wolfgang,
can you share your code, even if it does not work with -current?), and
either always use this variant, or use this variant on chips matched
by above mentioned quirks table.
See attached.
The
On Sat, Dec 16, 2017 at 06:07:42PM -0500, Thor Lancelot Simon wrote:
> On Fri, Dec 15, 2017 at 08:30:00PM +0100, Martin Husemann wrote:
> > - when libusb takes over controll (as Steffen described) a kernel driver
> >that would have attached (i.e. when the skipping does not happen or
> >
On Fri, Dec 15, 2017 at 08:30:00PM +0100, Martin Husemann wrote:
> - when libusb takes over controll (as Steffen described) a kernel driver
>that would have attached (i.e. when the skipping does not happen or
>the userland application is configured wrong) is detached, so no
>
Ok, after playing a bit more with Linux and OpenOCD (and getting kind
help from the openocd mailing list to unbrick my device), I think
I now understand a bit better how it plays together and what could
be done.
So Linux does:
- on certain fdti devices the first port of the chip is "skipped",
Hi Martin,
I have a Guruplug JTAG device (and right now need to use it to unbrick
one of my Guruplugs after some ... stupid u-boot experiment).
I've got some similar device which also uses a 2 port uftdi, where one
port is wired as a serial interface and the other is used for jtag.
In order
On Mon, 11 Dec 2017, Martin Husemann wrote:
[snip]
However, it can not work with the way NetBSD uses ugen devices:
uftdi0 at uhub3 port 2
uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00,
addr 3
ucom0 at uftdi0 portno 1
ucom1 at uftdi0 portno 2
I can disable the ucom
Martin Husemann writes:
> On Mon, Dec 11, 2017 at 08:24:00AM -0500, Greg Troxel wrote:
>> I wonder if we should be attaching drivers to endpoints, rather than
>> devices.
>
> This is the drivers decision (we have drivers that do it).
>
> However, ugen is not able to attach
On Mon, Dec 11, 2017 at 08:24:00AM -0500, Greg Troxel wrote:
> I wonder if we should be attaching drivers to endpoints, rather than
> devices.
This is the drivers decision (we have drivers that do it).
However, ugen is not able to attach to a single interface itself (currently).
Martin
Martin Husemann writes:
> However, it can not work with the way NetBSD uses ugen devices:
>
> uftdi0 at uhub3 port 2
> uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00,
> addr 3
> ucom0 at uftdi0 portno 1
> ucom1 at uftdi0 portno 2
>
> I can
> Date: Mon, 11 Dec 2017 12:44:32 +0100
> From: Martin Husemann
>
> I could hack uftdi to allow attaching a ugen child, but that sounds
> like a very special hack. Jared suggested to instead make ugen not a
> separate device, but globaly fold it into the usb stack. That would
19 matches
Mail list logo