Date: Thu, 8 Oct 2020 14:15:42 +0300 From: Sleep Walker <s199p.wa1k9r@gmail.com> To: Free BSD <freebsd-arm@freebsd.org> Subject: Re: FreeBSD-13.0-CURRENT on Helios64 Kobol NAS Message-ID: <CAHa8N88y=9S6a0dT9d=ydxV0dJdT4tqRm6eoJFhWEqQrC-nkoQ@mail.gmail.com> In-Reply-To: <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B@yahoo.com> References: <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B.ref@yahoo.com> <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello FreeBSD ARM community! I have successfully installed FreeBSD-13.0-CURRENT on Kobol Helios64 (RK3399). https://wiki.kobol.io/helios64/intro/ U-boot and DTS file kindly provided by Kobol TEAM :-). dmesg and dmesg verbose can be viewed here. dmesg - https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5695 dmesg verbose - https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5694 I have not yet had time to conduct a thorough test, but at first glance, all 6 SATA dicks work perfectly, even with 6 kernels enabled with OpenZFS support. Of course, the speed of dwc (4) - 53MB / sec and the incomprehensible behavior of the 2.5GbE port built on the Realtek RTL8156 chip via VL815 USB 3.0 Hub - is disappointing. --- ue0: flags =3D 8843 <UP, BROADCAST, RUNNING, SIMPLEX, MULTICAST> metric 0 m= tu 1500 ether 64: 62: 66: d0: 01: 3d inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options =3D 29 <PERFORMNUD, IFDISABLED, AUTO_LINKLOCAL> ---- root @ tsy: ~ # iperf3 -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 [5] local 192.168.1.182 port 60358 connected to 192.168.1.1 port 5201 [ID] Interval Transfer Bitrate Retr Cwnd [5] 0.00-1.00 sec 10.4 MBytes 87.2 Mbits / sec 90 42.6 KBytes [5] 1.00-2.00 sec 10.8 MBytes 91.0 Mbits / sec 106 1.41 KBytes [5] 2.00-3.00 sec 10.8 MBytes 91.0 Mbits / sec 109 24.1 KBytes [5] 3.00-4.00 sec 10.8 MBytes 90.7 Mbits / sec 101 1.41 KBytes [5] 4.00-5.00 sec 10.8 MBytes 90.9 Mbits / sec 105 1.41 KBytes [5] 5.00-6.00 sec 10.9 MBytes 91.1 Mbits / sec 104 42.6 KBytes [5] 6.00-7.00 sec 10.8 MBytes 90.7 Mbits / sec 105 41.2 KBytes [5] 7.00-8.00 sec 10.8 MBytes 91.0 Mbits / sec 105 42.6 KBytes [5] 8.00-9.00 sec 10.8 MBytes 91.0 Mbits / sec 110 22.6 KBytes [5] 9.00-10.00 sec 10.9 MBytes 91.0 Mbits / sec 105 29.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate Retr [5] 0.00-10.00 sec 108 MBytes 90.6 Mbits / sec 1040 sender [5] 0.00-10.00 sec 107 MBytes 90.0 Mbits / sec receiver iperf Done. root @ tsy: ~ # iperf3 -R -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 Reverse mode, remote host 192.168.1.1 is sending [5] local 192.168.1.182 port 55719 connected to 192.168.1.1 port 5201 [ID] Interval Transfer Bitrate [5] 0.00-1.00 sec 20.7 MBytes 174 Mbits / sec [5] 1.00-2.00 sec 21.7 MBytes 182 Mbits / sec [5] 2.00-3.00 sec 21.7 MBytes 182 Mbits / sec [5] 3.00-4.00 sec 21.7 MBytes 182 Mbits / sec [5] 4.00-5.00 sec 21.7 MBytes 182 Mbits / sec [5] 5.00-6.00 sec 21.7 MBytes 182 Mbits / sec [5] 6.00-7.00 sec 21.7 MBytes 182 Mbits / sec [5] 7.00-8.00 sec 21.7 MBytes 182 Mbits / sec [5] 8.00-9.00 sec 21.7 MBytes 182 Mbits / sec [5] 9.00-10.00 sec 21.7 MBytes 182 Mbits / sec - - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate Retr [5] 0.00-10.03 sec 217 MBytes 181 Mbits / sec 1 sender [5] 0.00-10.00 sec 216 MBytes 181 Mbits / sec receiver In general, the speed of the network is terribly annoying. Before that, I last tested the 22 Jun system and then eMMC worked fine. --- FreeBSD 13.0-CURRENT # 0 r361113M 0fb6ad5-c996 (nanopi): Mon Jun 22 12:18:06 MSK 2020 root@dev.kubsu.ru: /usr/crochet/work/obj/usr/crochet/src-13.0/arm64.aarch64/sys/FREENAS arm64 FreeBSD clang version 10.0.0 (git@github.com: llvm / llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b) Now eMMC is not detected. As a result, there is a replenishment in the ranks of ARM hardware ;-). --- Sergey Tyuryukanov. =D1=87=D1=82, 8 =D0=BE=D0=BA=D1=82. 2020 =D0=B3. =D0=B2 12:01, Mark Millard= via freebsd-arm < freebsd-arm@freebsd.org>: > sys/gnu/dts/arm/bcm2711.dtsi reports: > > /* > * emmc2 has different DMA constraints based on SoC revisions. It > was > * moved into its own bus, so as for RPi4's firmware to update > them. > * The firmware will find whether the emmc2bus alias is defined, > and if > * so, it'll edit the dma-ranges property below accordingly. > */ > emmc2bus: emmc2bus { > compatible =3D "simple-bus"; > #address-cells =3D <2>; > #size-cells =3D <1>; > > ranges =3D <0x0 0x7e000000 0x0 0xfe000000 0x01800000>; > dma-ranges =3D <0x0 0xc0000000 0x0 0x00000000 0x4000000= 0>; > > emmc2: emmc2@7e340000 { > compatible =3D "brcm,bcm2711-emmc2"; > reg =3D <0x0 0x7e340000 0x100>; > interrupts =3D <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>; > clocks =3D <&clocks BCM2711_CLOCK_EMMC2>; > status =3D "disabled"; > }; > }; > > > The old u-boot/DTB combination in use does not have emmc2bus. > And, even if it did, FreeBSD would not use the dma-ranges > content, expecting it to not vary within the RPi4B family. > Relative to "lowaddr", for example, there is: > > #define BCM2838_PERIPH_MAXADDR 0x3fffffff > > (the emmc2bus dma-ranges' size_cell_value-1 for the text > above). > > sys/arm/broadcom/bcm2835/bcm2835_sdhci.c does list brcm,bcm2711-emmc2 in > its compat_data: > > static struct ofw_compat_data compat_data[] =3D { > {"broadcom,bcm2835-sdhci", (uintptr_t)&bcm2835_sdhci_conf}, > {"brcm,bcm2835-sdhci", (uintptr_t)&bcm2835_sdhci_conf}, > {"brcm,bcm2835-mmc", (uintptr_t)&bcm2835_sdhci_conf}, > {"brcm,bcm2711-emmc2", (uintptr_t)&bcm2838_emmc2_conf}, > {"brcm,bcm2838-emmc2", (uintptr_t)&bcm2838_emmc2_conf}, > {NULL, 0} > }; > > where BCM2838_PERIPH_MAXADDR is picked out based on: > (from sys/arm/broadcom/bcm2835/bcm2835_vcbus.c) > > static struct bcm283x_memory_soc_cfg { > struct bcm283x_memory_mapping *memmap; > const char *soc_compat; > bus_addr_t busdma_lowaddr; > } bcm283x_memory_configs[] =3D { > . . . > { > .memmap =3D bcm2838_memmap, > .soc_compat =3D "brcm,bcm2711", > .busdma_lowaddr =3D BCM2838_PERIPH_MAXADDR, > }, > { > .memmap =3D bcm2838_memmap, > .soc_compat =3D "brcm,bcm2838", > .busdma_lowaddr =3D BCM2838_PERIPH_MAXADDR, > }, > }; > > (I've not found tracking of SoC revisions. But I also do > not know what varies across which SoC revisions. So far > as I know, the few I have access to have a uniform > structure.) > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHa8N88y=9S6a0dT9d=ydxV0dJdT4tqRm6eoJFhWEqQrC-nkoQ>