Great to see that all 4 boot options (SD, eMMC, SPI-NOR, SPI-NAND) are supported, finally I can test a single OpenWrt image for all existing storage backends (block for SD/eMMC, mtd for SPI-NOR, ubi for SPI-NAND).
For now I can test block and ubi on the R64 and have to use UniFi 6 LR as a sample-device with NOR-flash (and hence plain MTD storage, JFFS2 as overlay filesystem, …) to see if U-Boot and single-image approach works there as well.
So I can’t wait to receive a sample!
Also great to hear that 2.5G speeds will be supported on SFP! (btw: both slots up to 2.5G? or only 2nd SFP slot?)
Regarding the mPCIe socket: Does it only have USB2.0? If so, it would have been better to at least put NGFF/M.2 socket with USB2.0 and USB3.x connected because modern 4G/5G modems tend to come in that form factor and 5G speeds will require USB3.x…
You’re right,i see no sata port too,and this is one of key features of bpi boards. And i’m using it in production (r2).
For gmac,moore posted a shematic
1 sfp is connected to switch as port5 and one to gmac2 of soc. Basicly the connection which is hard wired on r2/r64,but p5 of mt753x can be configured as userport. So afaik they are independ.
And maybe you can connect sfp to each other to have same constellation as on r2/r64. @moore can you confirm this? If anyone do this (because of financial and stability aspects) is another story of course p5 have to be configured as cpu-port again and in case of dsa driver used it have to be support that (currently no second cpu port possible,but workaround with vlan-aware bridge)
I don’t think taking 12v from fan for hdd is a good idea and 5v from usb also needs a splitter to not block usb port
and the top 2 white connectors are defined as USB, can you please use usb-connectors for it like used on x86 mainboards? so we can attach usb-extensions like this
Not fact that fan voltage is 12V it might be a 5V and also it might be PWM.
There is a header right next to the PSU barrel port, and likely it’s directly connected to it. So it might be used as a 12V source. (if the board uses 12V, of course)
What is the capacity of the network accelerator? (HW NAT) On R64 it can handle 1G NAT easily.
10G is becoming more popular, I think a product like R3 but with 10G only ports (at least one SFP+ for fiber) would be amazing. Also instead of the built in wifi chips on board, gives us PCIE ports instead (WIFI 7 is coming)
Would such a device be possible in the future?
Either way, R3 looks like a solid product, a very good upgrade over R64.
Did my first steps with bpi-r3,noticed some problems:
pcie seems usb-only (maybe use pcie switch like on r64 to have full featured pcie) and pin 46 is again +5v which may break some cards. See here: [BPI-R64] mPCIe hardware pin 48
usb-sockets near gpio are non-standard. Made a cable for testing it,but this is not end-user friendly.Please use a default 9-pin motherboard connector here
m2-slot misses hole for 30mm nvme, so currently cannot test it. If using an sata adapter there is a need for power (5v+12v+gnd). 12v seems to be behind power socket,but have not found a 5v yet (except usb/fan) which may give enough power for 2.5inch hdd
Apart of this r3 is a great board
Edit: got response:
Usb-sockets will be replaced my 9-pin motherboard connector
hole for 2230 nvme not possible because other side of board is pcie slot
If doing new hardware rev imho it is better to move the switches all to top side of the board and maybe replace them by 2.54mm pins +jumper. This will allow moving these switches to somewhere on the case. As install to emmc requires switching multiple times this will be hard if board is inside a case.
Looks like the RST button is connected to the NVME/M.2 PCIe socket on the back of the board and hence detected in always-pressed condition as soon as a card is plugged in. This is also visible in V1.0 schematics
Was this fixed in V1.1 or newer versions of the board? Because like this (obviously) the RST button doesn’t make much sense.
@sinovoip Imho for mass production you should remove R171 and R173 (ie. instead of 0R make it NC) so the buttons work. If someone really wants PCIe power management (because that’s what they are for, apparently), that would have to be changed in drivers/device-tree as well and one would have to populate R171 and R173 and sacrifice the button functionality.
of course p5 have to be configured as cpu-port again and in case of dsa driver used it have to be support that (currently no second cpu port possible,but workaround with vlan-aware bridge)
