On Wed, Aug 02, 2006 at 03:18:30PM -0400, Jamie Guinan wrote:
> On Thu, 6 Jul 2006, Marc Singer wrote:
>
> > On Mon, May 15, 2006 at 03:23:29PM -0400, Jamie Guinan wrote:
> > > On Thu, 20 Apr 2006, Marc Singer wrote:
> > >
> > > > Let me know of this works better for you when connecting to a Windows
> > > > host using RNDIS.
> > > >
> > > > <ftp://ftp.buici.com/pub/arm/gadget>
> > >
> > > I finally got around to trying this, with linux-2.6.16 + ms28 +
> > > lh7_udc.c from above link.
> > >
> > > It comes right up when plugged into an XP host, and as a quick test I
> > > round-tripped an 800MB file over some netcat pipes, worked fine.
> > >
> > > I did need the "buggy hardware" #define, which in turn needs some
> > > typo fixes,
> > >
> > > http://www.bluebutton.com/misc/lh7usb/udc-typos.patch
> > >
> > > One sticker on my LPD board (on an SDRAM chip) reads,
> > >
> > > 80000127 - 0033 REV 303
> > >
> > > and the chip itself reads,
> > >
> > > SHARP
> > > LH7A404-N08-000
> > > B0
> > > 0346 Korea
> > > 10050280
> > >
> > > What about yours? I'm thinking about a more descriptive name for that
> > > #define than your board's serial number.
> >
> > Long delay, sorry.
>
> Likewise...
>
> > It is very unlikely that you needed the 80000258 define enabled. This
> > is for some preproduction hardware that no one should have. Note that
> > this is not supposed to be a serial number, but a part number,
> > according to LogicPD.
>
> Confirmed, the few LPD7A404 boards I have, all have the same 80000???
> number, so it may well be/contain pre-production hardware, but I have
> to wonder what the Nordic ID guys have in their products (if they are
> on the market), or what I would get if I ordered a kit from DigiKey,
>
> http://www.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=460-1017-ND
So, do your boards have the 80000258 ID?
> > Are you sure it's necessary?
>
> Without it I don't see the device from the host, so it is necessary.
> Note that this applies to the LogicPD boards only, our custom boards
> are fine without it (we don't see the CONFIG_MACH_LPD7A404 blocks).
Right. There is an alternative mechanism available that LPD chose not
to use. I'd have to see your schematics to know if the code will work
properly for you.
> I noticed that some USB support circuitry related to this issue
> changed between the 400 and 404 manuals, maybe the old boards have
> the 400-style circuitry.
>
> Anyway, up to you if you want to leave in or remove the #define, I can
> keep a patch on the side if I need it.
I'd like to resolve the problem properly. I could add a config option
instead of a #define in the driver so that, at the very least, it can
be configured automatically.
However, I want to make sure that we're doing things the right way.
To do so, I need:
1) The board ID of your hardware. This includes both the card
engine and the SDK board. I'll communicate with LPD about these
revisions if necessary.
2) Schematics from the LPD kits. The CD in the kits has schematics
that must match the hardware.
3) A description of your test environment. I've verified that the
driver works as-is when connecting between the LPD boards and a
Linux host. I've not done the same for a Windows host as I don't
have one, but I can arrange to run a test.
Cheers.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
