Hi Dave, On Sat, Oct 3, 2026 at 3:33 PM Dave Klotz <[email protected]> wrote: > > 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]> >
Thanks for your testing and suggestions. You are right, the helper only validates the start address. I checked the current board dts: dram is declared as 2 GiB at k1-bananapi-f3-u-boot.dtsi, and u-boot's heap sits just below ram_top, so the straddling case is not reachable on today's boards. But for logical completeness, the helper should honour its contract regardless of the current memory map, so I will validate the full range in the next revision. Regards, Zixian
