Raspberry Pi 3 Model B GPIO 40 Pin Block Pinout

Thanks Roger Wolff for checking it out!

This indicates that very little compatibility testing is being done before the roll out. Side note: Does this sound like another Pi about a year ago? So why do they preach and demagogue it so much to the mass public?

The lonely guards,

Clem

Yep. But the weird thing is that i still have a user-space ttyAMA, if it is correct that the ttyAMA hardware is now for the wifi chip. Then I'd expect the loading to first start the WIFI driver that "claims" the serial port, blocking the ttyAMA driver. (I have WIFI up-and-running, so it can't be that it's available just because WIFI isn't active).

Anyway, I hear hints that the WIFI uses an SDIO connection to the bcm2837. There is a hint in dmesg that corroborates this:

brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 43430 rev 1 pmurev 24

Anyway, it is annoying that ttyAMA no longer refers to the serial port on the GPIO pins. My raspduino software will need a revision: It refers to ttyAMA0.

Similarly, my DMX board works with software like QLC and OLA, that are now configured for /dev/ttyAMA0 on raspberry pi.....

It would have been better if the foundation had started a convention of making a symlink for the "compatible hardware" on each such change. For example, a "compatiblity" startup script could be provided that links "/dev/i2c" to "/dev/i2c-0"  on the first batch of pies, and "/dev/i2c-1" on newer ones. Similarly, /dev/theserialport should point to /dev/ttyS0 on raspberry pi 3, and /dev/ttyAMA0 on all others.

Hi Roger,

That is interesting. I guess they had to do this mapping to use the same config files (since it is the same image for the Pi variants), i.e. to try to make it transparent to the end user.

My PI3 has a ttyAMA, the ARM-uart that previous raspberries had:

3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev2

But I see a getty running on /dev/tttyS0. Ah:

3f215040.uart: ttyS0 at MMIO 0x3f215040 (irq = 29, base_baud = 50000000) is a 16550

... On the one hand an improvement: the 16550 has a 16-byte buffer, on the other hand, SOME things must have moved around to make this as compatible as possible.

My /boot/cmdline specifies: console=ttyAMA0,115200 , whereas my kernel has been started with: console=ttyS0,115200 , Tricky hacking in the videocore startup files....

Hi Roger,

I too would wish this to be true, but there were comments on another forum that possibly the UART has now moved to a soft-UART implementation to use the interface pins instead for synchronous serial to the wireless IC, so perhaps things have moved around (which a schematic or datasheets would reveal). I don't have any more information or datapoints though (still waiting to receive my Pi 3 to examine it).

Drivers of course should in theory make such things transparent to the user, but there will always be people doing things differently enough (or drivers behaving subtly different) for things to sometimes not behave as expected.