From: https://www.raspberrypi.org/blog/raspbe ... 3-on-sale/BCM2837, BCM43438 and Raspberry Pi 3
For Raspberry Pi 3, Broadcom have supported us with a new SoC, BCM2837. This retains the same basic architecture as its predecessors BCM2835 and BCM2836, so all those projects and tutorials which rely on the precise details of the Raspberry Pi hardware will continue to work. The 900MHz 32-bit quad-core ARM Cortex-A7 CPU complex has been replaced by a custom-hardened 1.2GHz 64-bit quad-core ARM Cortex-A53. Combining a 33% increase in clock speed with various architectural enhancements, this provides a 50-60% increase in performance in 32-bit mode versus Raspberry Pi 2, or roughly a factor of ten over the original Raspberry Pi.
James Adams spent the second half of 2015 designing a series of prototypes, incorporating BCM2837 alongside the BCM43438 wireless “combo” chip.
From: https://www.raspberrypi.org/products/ra ... 3-model-b/Quad Core 1.2GHz Broadcom BCM2837 64bit CPU
BCM43438 wireless LAN and Bluetooth Low Energy (BLE) on board
40-pin extended GPIO
But there's no real reasons for a GPIO expander on the user side of the CM3 as you have all the GPIOs available. Choose one you like the look of and connect up to that (if needed).
You're right.6by9 wrote: ↑Tue Apr 24, 2018 9:05 amBut there's no real reasons for a GPIO expander on the user side of the CM3 as you have all the GPIOs available. Choose one you like the look of and connect up to that (if needed).
There is a GPIO expander on the CM3 as an I2C bus was required to the SMPS, so two lines bit-bash I2C to the SMPS and the expander to replicate the original functions on the two lost GPIOs.
TBH I'm not sure whether anything in the software stack actually toggles BT_ON or WL_ON. The firmware will set them up at boot and set the required state. Things could then turn them off, but I can't see anything in the device tree config to point the kernel at it.
That doesn't hold together as an argument.adun wrote: ↑Wed Apr 25, 2018 12:32 pmYou're right.
There’s just one case where it would be handy to have the additional GPIOs available.
If a CM board should be equal to a Raspberry Pi 3+ and all the GPIOs from the 40 pin header are also used (e.g. for DPI/SMI) you would need additional GPIOs for at least the LEDs and the LAN chip if BT_ON and WL_ON are not necessary.
Act LED can certainly be controlled direct from Linux, and it is on B+ and 2 (GPIO 47 on both).
No, the firmware knows about one expander, and that is doing HDMI hotplug and EMMC_Enable on the CM3.
Hello Nameste sir,6by9 wrote: ↑Wed Apr 25, 2018 3:31 pmAct LED can certainly be controlled direct from Linux, and it is on B+ and 2 (GPIO 47 on both).
Same with the power LED, although the firmware needs to be able to access it if you want the low voltage detection (which is optional).
LAN_RUN is a funny one in that again I don't think it is actively controlled after boot. I don't know the full logic behind it. Probably safest to keep that one accessible to the firmware.
Then again if you are not network or USB booting then the LAN device is just a USB device, so the firmware doesn't care. There would be nothing stopping you controlling LAN_RUN from Linux, and setting the GPIO via a gpio hog during Linux boot, at which point the USB device should enumerate.
So many ways to skin the rabbit...