5. Assisting POE (via GPIO daughter board) If a POE daughter board was plugged into the GPIO pins with the daughter board having a POE input

RJ45 on it, supplying power to the R-Pi. The four ethernet data line output from the daughter board being connected to currently unused GPIO pins. I suspect inputting ethernet via the GPIO pins breaks various rules and could add to RF output:-(

mmm, I really hope those "power issues" turn out to be just bad cable/adaptors/ppl doing it wrong.

You guys are working on it I suppose.

btw PeteL, what is requiring redesign (for full compliance)? That's what is bugging me, since it leads to another question: when will this be implemented (and then re-certified)? Before or after the queue of orders?

I guess "what are the changes needed" is more your cup of coffee (or better tea), so that's what I'd really like you to enlight me on.

"those 2K" should be "those 10k". The other 8k are Guaranteed to be exactly the same: they were produced feb-march just like the first 2k that are delivered right now.

and yes, I too would want to know what changes seem to be neccessary and when they will go through.

What is the HD interface? (schematics P4 left top)

What value is typical for the built-in pullup/pulldown? I expect that to be on the order of 50-100k. In that case you can encode 3^4 different board revisions with the 4 board-revision strap resistors:

read value. If zero, enable pullup, if one enable pulldown. If value now changes, the strap is left "open", so that's the third value. (Ah! found them!).

There is an error in the schematics. p3 mentions the "USB" part of the LAN9512 as "model A only". That should be "Model B only" of course.

R22-R25, R28, C28 are missing their "Model B only" tag.

Why is there a line going from R25 to R22?

Due to space constraints the 100M led is labeled 10M on the board. How about calling that "FE" for "Fast Ethernet"? That's what 100M was called back in the days.

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1

What is the purpose of D15, D16? I'm thinking: Protection against static discharges, right? The question is: Wouldn't it be better to connect their kathode to +5V0 instead of +5V0_HDMI? The +5V_HDMI is just a small net that only has the 100N C75 on it....

Are the HDMI_SDA and HDMI_SCL pins 5V tolerant? I wouldn't have guessed.

Just in case you missed it, I did - tied up in a meeting, Liz has posted the schematics on the main site.

I'll let everyone have their comments and inputs and review/respond in detail where I can in few days.

I will also start a new discussion here, PLEASE put all comments on the schema's there, and the folks who have already please cross post, it keeps it all nicely together and will be useful for people to read.

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps,full-duplex, lpa 0xC5E1

I agree with that, FDX led is not really usefull, it would be much better if that could be used as a gpio led.

That way you can directly let kids program the led without the need for extra hardware.

Well, in principle you can use the FDX as a GPIO LED. The difficulty is that you need to talk to the LAN9512 in USB-speak to configure and toggle it, and the driver may make this difficult. Still, students would learn a lot about USB drivers trying to do it :-)

I know it is only slightly different, and may not matter at all, but in a post on the Raspberrypi.org website one recipient (another case manufacturer actually) has said that: The board is 85.00 x 56.17

Pete. Very excited, I've been looking for the Raspberry Pi for the last two years to make an affordable audio player to generate sound effects and audio interpretation for museum exhibits. The aim would be to trigger the audio with a PIR via the GPIO. There would be no display so I need to use the 2.5mm audio jack. In this thread http://www.raspberrypi.org/forum/features-and-requests/possible-higher-bitrate-dac-in-the-future item 6 GERT mentions that there will be power supply noise on the audio. I don't have a Pi yet so don't know what this sounds like but for amplified sound effects background noise is important. I wonder if the situation can be improved in the next revision, or maybe the pwm lines brought out to the GPIO connector so users can implement their own clean power supply, driver and filter as described in the same thread. The GPIO solution would give 2 additional pwm outputs, assuming they can be decoupled from the audio software.

The schematic does not show any of the connections to the Package on Package (POP) memory that actually sits on top of the BCM2835. It never gets to the PCB so there is just a hidden attribute that calls up the part onto the parts list so it doesn't get forgotten! I think I should make reference to that on the next schematic set.

More than one chip select would not be of any use unless a memory manufacturer decided to make a DRAM chip that passed through all the signals (and the additional chip select) to a package that sits above.

Theoretically it is possible, and there are examples of Package on Package on Package. It's not uncommon for this to be done inside a single package (stacked die) but the interconnect is done usually with bond wires.

Unless we pass the 4-5 Million Pi's mark with no obvious tailing off of demand I think Broadcom would not be interested, I suspect the number is in reality much higher than this. Making even a minor mod to silicon can cost millions of dollars. One of the big costs used to be a mask set, but now I think direct imaging has taken this out of the loop. I'm sure there are people on the forum who could comment better than me - I just use the chips now.

I used to make silicon but the advent of cheap (relatively) programmable logic (FPGAs) has largely chopped away the mid volume market. The stress of waiting for a PCB spin is nothing compared to 'first off' silicon - hats off to those guys, I'm to old to suffer that now! You can fix a multitude of sins in an FPGA.

One option discussed before is to use a larger capacity POP memory chip but for the moment this is not in the roadmap.

Several people have commented on the hardware design of the Raspberry Pi. Some are buried in other topics so please post your comments here. I'll try my best to answer questions about the design decisions we made. The Raspberry Pi is not perfect, never will be. I've always found that perfect designs have a habit of never getting built, engineers are always a bit guilty of that, but I had Eben phoning/emailing me every day wanting to know when it would be finished. Also, one persons perfection is another persons nightmare.

e14 is the home for engineers so please contribute to make Raspberry Pi better.