Raspberry Pi - Hardware Flaws and Fixups?

Reviewing the rev 1.0 schematics and docs for the related parts, I found something that looks wrong.

The SMSC LAN9512 has two VDD18CORE pins that are internally connected between them and to the internal core 1.8V voltage regulator, those pins need to be connected externally as well and to a couple of filter caps.

The RasPi schematics shows those pins also connected to the +1V8 power line from RG1.

That looks wrong, the SMSC VDD18CORE pins should not be connected to +1V8.

-J

I fully agree! with your "VDD18CORE" remark.

Jamodio, have you found a "reset" pin on the 2835? The only thing I could find was "run". Would the CPU just pause when pulled low? I don't know.

While investigating this, I found that "D10" is not marked "(B)" as it should. (even though it is involved with the USB powersupply for the model A, the other side is not connected on the model A, so the component is redundant on model A).

What issue are you referring to? The pinout datasheet? You say "it would be  nice... ", and I agree. But it is not going to happen.

Perhaps ask them nicely for informally documented pinout information?

At worst they'll either refuse or just ignore the request, but you never know.  We might be hugely and pleasantly surprised.  It's summer after all, and Broadcom might have some interns kicking around the lab looking for something simple to do.

In addition, there's another possible outcome lying somewhere  between the best and worst cases, which is that certain Broadcom employees who regularly post on the RPF forum will probably come out with elaborate rationales about why pinout information must be protected at all costs otherwise it will reveal the deepest secrets of the company to the competition.  That would be worth its weight in gold for sheer comedy, so please ask.

Maybe someone should ask Where's Pete?

Last we heard, back in April he was going to release v1.1

of the schematics "soon".    After seeing 100% of the

foundation's paid staff (Myra) disappear without any

announcement, I get nervous when key people like Pete,

who was quite active on this forum, go off to fixup the schematic

and don't return.  I think the Model A was also his baby,

and has disappeared from radar.  And as we know, Seneca was

going to fix the login and timezone problems in Fedora 14 back in

March, and from what I can tell, Chris Tyler is off writing a book,

and his student helpers haven't been heard from lately. 

I was actually referring to the LAN9512 VDDCORE pin connected to the +1V8 line.

There is also somewhere else a question posted about thermal issues and the warning sheet shipped with the Rpis that says "should not be covered."

I'm also trying to dig into a kernel panic issue when the network interface is under stress using the Debian distro, I'll be posting a msg on the forum.

-J

Combining the last two messages into a "glass half full" kind of explanation, with a bit of luck Pete's not here because he's massively busy redesigning Pi v2 with better thermal and power management.

It has to be done, the only question is when.  Far better to do it sooner rather than after the world is flooded with marginal boards, IMO.

I'd hope that's the case and will be very helpful for them and for us if they post the design before they commit to a circuit board or go to production.

There is another issue that I believe it has been already reported and I can see now that I've the gear hooked up to the Rpi.

There seems to be some leakage from the HDMI interface to the 5V line, a voltmeter without a power supply connected but with the HDMI connected to a Samsung SyncMaster B2330 shows about 1.45VDC, that goes to 0VDC when the HDMI is disconnected, that voltage shoudn't be there.

-J

jamodio wrote:

 

There seems to be some leakage from the HDMI interface to the 5V line, a voltmeter without a power supply connected but with the HDMI connected to a Samsung SyncMaster B2330 shows about 1.45VDC, that goes to 0VDC when the HDMI is disconnected, that voltage shoudn't be there.

My guess is that leakage is from HDMI_SDA and HDMI_SCL through 1.8 K resistors R13 and R14.  They probably provide enough current get the SoC and/or LAN9512 to the point where they first start to turn on, but not enough current to get any further.  If this is the case, the few mA shouldn't hurt anything.

Morgaine Dinova wrote:

 

In addition, there's another possible outcome lying somewhere  between the best and worst cases, which is that certain Broadcom employees who regularly post on the RPF forum will probably come out with elaborate rationales about why pinout information must be protected at all costs otherwise it will reveal the deepest secrets of the company to the competition.  That would be worth its weight in gold for sheer comedy, so please ask.

Giggle.  One of them will accuse you of sounding like a broken record, and provide a link to a page that describes a phonograph record in case you're only familiar with MPEG files.  However, he won't reference the most amusing cinema scenes about phonograph records, such as when Joan Crawford in her later years strikes a "light anywhere" match on a record in Strait-Jacket (1964) and the marvelous scene in Bedazzled (1967) where the devil (played by Peter Cook) scratches records out of malice so they'll skip and cause anger and (with luck) blasphemy when played by their victims.  Honorary mention to Anthony Perkins in The Trial (1962) when he gets flustered and refers to his record player as a "pornograph".

You are probably right, that interface should be isolated as it was done on the BeagleBoard and Pandaboard. I think that RPF is cutting too many corners trying to save few $$.

-J

jamodio wrote:

 

You are probably right, that interface should be isolated as it was done on the BeagleBoard and Pandaboard. I think that RPF is cutting too many corners trying to save few $$.

I believe the BeagleBoard had revisions A1-A5, followed by B1-B3, before general availability of B4.  So BeagleBoard had lots of opportunities to fix minor issues.  With RasPi there were lots of changes from the Alpha to Beta boards, and the Beta boards had virtually no experience in the field before going to mass production after a very small PCB change.  The BeagleBoard community grew slowly so problems with ICs and Linux drivers could keep up with community growth.  RasPi had an instant community of people with various degrees of experience all buying "developer" boards.  Given all this, I think RasPi did rather well.

jamodio wrote:

 

You are probably right, that interface should be isolated as it was done on the BeagleBoard and Pandaboard. I think that RPF is cutting too many corners trying to save few $$.

I believe the BeagleBoard had revisions A1-A5, followed by B1-B3, before general availability of B4.  So BeagleBoard had lots of opportunities to fix minor issues.  With RasPi there were lots of changes from the Alpha to Beta boards, and the Beta boards had virtually no experience in the field before going to mass production after a very small PCB change.  The BeagleBoard community grew slowly so problems with ICs and Linux drivers could keep up with community growth.  RasPi had an instant community of people with various degrees of experience all buying "developer" boards.  Given all this, I think RasPi did rather well.