Hi Zixian,
I tested v1 1/3 on OrangePi RV2 and R2S with YT8531 PHYs in rgmii-id
mode. I reverted my local EMAC driver and applied the exact posted
patch to my K1 lane, keeping the unposted board support, clock/DDR
workarounds and OpenSBI v1.9 fixed. Both board defconfigs enable
PHY_MOTORCOMM and ID_EEPROM. Both variants built without warnings.
The existing SPL was retained; these were U-Boot proper tests.
RV2: both ports link at 1000 Mbps full duplex. DHCP passes on the LAN
port; the isolated second port uses static addresses. R2S: the first
port links at 1000 Mbps full duplex and DHCP passes; its second port
was not connected. Router/peer ping passes where applicable.
On every connected port, each driver passed small/1 MiB downloads,
three 64 MiB downloads at each TFTP window 1/4/16, ten further 64 MiB
window-16 stress downloads, a 128 MiB download, and 1/128 MiB uploads.
Downloads were SHA256-checked in U-Boot, uploads at the receiver.
The 128 MiB transfers cross 16-bit TFTP block rollover. No DMA TX
timeout, exception or payload corruption was recorded.
Median 64 MiB download rates, local driver / v1, in Mb/s:
window 1 window 4 window 16
RV2 MAC 0 15.58/14.89 80.66/82.19 153.04/151.44
RV2 MAC 1 16.15/14.05 82.48/82.43 152.09/153.30
R2S MAC 0 140.80/140.91 371.28/370.26 639.89/636.86
Each pair used the same physical peer and settings. These are TFTP
application rates, including peer/protocol overhead. RV2 window-1
control samples vary; a separate three-sample repeat had a 15.33 Mb/s
median. Its single 128 MiB MAC-0 upload was also slower with v1
(13.60 versus 18.22 Mb/s); this n=1 observation needs more sampling
before calling it a stable regression. R2S large-upload rates were
151.52/151.12 Mb/s. Duplicate upload packets occurred with both
drivers, with correct payload hashes and no receiver retries.
I repeated the complete RV2 MAC-0 test set against a locally adjacent
independent wired Linux peer. Its local/v1 medians at windows 1/4/16
were 51.59/148.59, 396.80/393.31 and 531.56/672.77 Mb/s. All hashes,
stress downloads and
128 MiB upload/download rollover checks passed on that peer too.
Both variants had window-1 samples near 3.6 and 10.4 seconds;
the variable three-sample medians do not establish a stable speedup.
The ten window-16 stress-transfer medians were 675.31/669.83 Mb/s.
Single 128 MiB upload rates were 56.50/61.13 Mb/s (n=1).
The isolated second-port cable remained on the first peer.
Both variants booted FreeBSD with eight CPUs and connected links.
R2S also passed the FreeBSD network checks. FreeBSD uses its own
smte driver; these checks are separate from the U-Boot transfers.
The original ESPs were restored and verified, including unchanged
boot regions, followed by normal baseline boots. No long-duration
soak or RMII/10/100 test is claimed.
One source-review suggestion: k1_emac_dma32() validates each DMA
starting address, but not the buffer/ring end. The local validator
rejects a 1536-byte buffer starting at 0xfffffc00; the posted helper
accepts it in an extracted-source identity-translation test. I did
not force such an allocation on hardware. Checking the full range
would retain that protection when allocations approach 4 GiB.
Tested-by: Dave Klotz <[email protected]>
