Welcome! Log In Create A New Profile

Advanced

armada 370 L2 cache

Posted by Koen 
Forum List Message List New Topic
wacke
Re: armada 370 L2 cache
November 15, 2020 11:12PM
Hi,
It did not work: 
root@OpenWrt:/# dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.9.8 (Wacke@HOME-Server) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 10.2.0 r14945-47e089e30e) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #0 SMP Sun Nov 10
[    0.000000] CPU: ARMv7 Processor [561f5811] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: RTNAS V3
[    0.000000] Forcing write-allocate cache policy for Armada 370
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000003fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000] On node 0 totalpages: 262144
[    0.000000]   Normal zone: 1728 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 196608 pages, LIFO batch:63
[    0.000000]   HighMem zone: 65536 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] percpu: Embedded 11 pages/cpu s14732 r8192 d22132 u45056
[    0.000000] pcpu-alloc: s14732 r8192 d22132 u45056 alloc=11*4096
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 260416
[    0.000000] Kernel command line: console=ttyS0,115200
[    0.000000] Bootloader command line (ignored): console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootfstype=ubifs
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 1027760K/1048576K available (7168K kernel code, 208K rwdata, 1676K rodata, 1024K init, 235K bss, 20816K reserved, 0K cma-reserved, 262144K highmem)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] L2C: DT/platform modifies aux control register: 0x12086302 -> 0x12086300
[    0.000000] Aurora cache controller enabled, 4 ways, 256 kB
[    0.000000] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x12086300
[    0.000000] random: get_random_bytes called from start_kernel+0x400/0x5a4 with crng_init=0
[    0.000000] Switching to timer-based delay loop, resolution 53ns
[    0.000007] sched_clock: 32 bits at 18MHz, resolution 53ns, wraps every 114840871909ns
[    0.000020] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 102208375848 ns
[    0.000204] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.39 BogoMIPS (lpj=186996)
[    0.000216] pid_max: default: 32768 minimum: 301
[    0.000327] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000341] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.000968] CPU: Testing write buffer coherency: ok
[    0.001178] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.001653] Setting up static identity map for 0x100000 - 0x100060
[    0.001967] mvebu-soc-id: MVEBU SoC ID=0x6710, Rev=0x1
[    0.002054] mvebu-pmsu: Initializing Power Management Service Unit
[    0.002204] rcu: Hierarchical SRCU implementation.
[    0.002355] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build
[    0.002452] smp: Bringing up secondary CPUs ...
[    0.002461] smp: Brought up 1 node, 1 CPU
[    0.002468] SMP: Total of 1 processors activated (37.39 BogoMIPS).
[    0.002474] CPU: All CPU(s) started in SVC mode.
[    0.005075] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6
[    0.005190] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.005206] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.005318] pinctrl core: initialized pinctrl subsystem
[    0.005954] NET: Registered protocol family 16
[    0.006712] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.007372] thermal_sys: Registered thermal governor 'step_wise'
[    0.007570] mvebu-pmsu: CPU idle is currently broken: disabling
[    0.054260] cryptd: max_cpu_qlen set to 1000
[    0.056508] SCSI subsystem initialized
[    0.057839] libata version 3.00 loaded.
[    0.058045] usbcore: registered new interface driver usbfs
[    0.058089] usbcore: registered new interface driver hub
[    0.058150] usbcore: registered new device driver usb
[    0.058435] workqueue: max_active 576 requested for napi_workq is out of range, clamping between 1 and 512
[    0.064234] clocksource: Switched to clocksource armada_370_xp_clocksource
[    0.065048] NET: Registered protocol family 2
[    0.065440] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[    0.065469] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    0.065530] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.065628] TCP: Hash tables configured (established 8192 bind 8192)
[    0.065812] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[    0.065854] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[    0.066045] NET: Registered protocol family 1
[    0.066075] PCI: CLS 0 bytes, default 64
[    0.070901] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[    0.074237] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.074250] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.075886] bounce: pool size: 64 pages
[    0.077195] armada-370-pinctrl f1018000.pin-ctrl: registered pinctrl driver
[    0.078967] mvebu-pcie soc:pcie@82000000: host bridge /soc/pcie@82000000 ranges:
[    0.079006] mvebu-pcie soc:pcie@82000000:      MEM 0x00f1040000..0x00f1041fff -> 0x0000040000
[    0.079027] mvebu-pcie soc:pcie@82000000:      MEM 0x00f1080000..0x00f1081fff -> 0x0000080000
[    0.079046] mvebu-pcie soc:pcie@82000000:      MEM 0xffffffffffffffff..0x00fffffffe -> 0x0100000000
[    0.079063] mvebu-pcie soc:pcie@82000000:       IO 0xffffffffffffffff..0x00fffffffe -> 0x0100000000
[    0.079080] mvebu-pcie soc:pcie@82000000:      MEM 0xffffffffffffffff..0x00fffffffe -> 0x0200000000
[    0.079093] mvebu-pcie soc:pcie@82000000:       IO 0xffffffffffffffff..0x00fffffffe -> 0x0200000000
[    0.079311] mvebu-pcie soc:pcie@82000000: PCI host bridge to bus 0000:00
[    0.079326] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.079337] pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff] (bus address [0x00040000-0x00041fff])
[    0.079346] pci_bus 0000:00: root bus resource [mem 0xf1080000-0xf1081fff] (bus address [0x00080000-0x00081fff])
[    0.079353] pci_bus 0000:00: root bus resource [mem 0xf8000000-0xffdfffff]
[    0.079361] pci_bus 0000:00: root bus resource [io  0x1000-0xeffff]
[    0.079466] pci 0000:00:01.0: [11ab:6710] type 01 class 0x060400
[    0.079490] pci 0000:00:01.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
[    0.079807] pci 0000:00:02.0: [11ab:6710] type 01 class 0x060400
[    0.079827] pci 0000:00:02.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
[    0.080767] PCI: bus0: Fast back to back transfers disabled
[    0.080779] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.080791] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.081615] PCI: bus1: Fast back to back transfers enabled
[    0.081627] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[    0.082441] PCI: bus2: Fast back to back transfers enabled
[    0.082451] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
[    0.082511] pci 0000:00:01.0: BAR 6: assigned [mem 0xf8000000-0xf80007ff pref]
[    0.082523] pci 0000:00:02.0: BAR 6: assigned [mem 0xf8100000-0xf81007ff pref]
[    0.082533] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.082546] pci 0000:00:02.0: PCI bridge to [bus 02]
[    0.082984] mv_xor f1060800.xor: Marvell shared XOR driver
[    0.144914] mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
[    0.145202] mv_xor f1060900.xor: Marvell shared XOR driver
[    0.204892] mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
[    0.205262] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.205811] printk: console [ttyS0] disabled
[    0.205882] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 18, base_baud = 12500000) is a 16550A
[    0.975294] printk: console [ttyS0] enabled
[    0.985047] loop: module loaded
[    0.988618] sata_mv f10a0000.sata: version 1.28
[    0.988855] sata_mv f10a0000.sata: slots 32 ports 2
[    0.999662] scsi host0: sata_mv
[    1.003967] scsi host1: sata_mv
[    1.007349] ata1: SATA max UDMA/133 irq 27
[    1.011468] ata2: SATA max UDMA/133 irq 27
[    1.018190] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68
[    1.024655] nand: Micron MT29F32G08CBACAWP
[    1.028774] nand: 4096 MiB, MLC, erase size: 1024 KiB, page size: 4096, OOB size: 224
[    1.036665] nand: WARNING: pxa3xx_nand-0: the ECC used on your system (16b/2048B) is too weak compared to the one required by the NAND chip (24b/1024B)
[    1.051438] Bad block table found at page 1048320, version 0x01
[    1.058750] Bad block table found at page 1048064, version 0x01
[    1.065382] nand_read_bbt: bad block at 0x000005a00000
[    1.070542] nand_read_bbt: bad block at 0x000005b00000
[    1.076394] 7 fixed-partitions partitions found on MTD device pxa3xx_nand-0
[    1.083394] Creating 7 MTD partitions on "pxa3xx_nand-0":
[    1.088871] 0x000000000000-0x000000400000 : "u-boot"
[    1.094583] 0x000000400000-0x000000800000 : "uboot_env"
[    1.100423] 0x000000800000-0x000000c00000 : "vendor"
[    1.106047] 0x000000c00000-0x000001800000 : "unused"
[    1.111610] 0x000001800000-0x000001c00000 : "kernel"
[    1.117250] 0x000001c00000-0x000040000000 : "ubi"
[    1.122843] 0x000040000000-0x0000fbc00000 : "syscfg"
[    1.129745] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[    1.137654] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[    1.147757] libphy: Fixed MDIO Bus: probed
[    1.152731] libphy: orion_mdio_bus: probed
[    1.167322] mv88e6085 f1072004.mdio-mii:00: switch 0x1710 detected: Marvell 88E6171, revision 2
[    1.183575] libphy: mdio: probed
[    1.215425] mvneta f1074000.ethernet eth0: Using random mac address e2:06:d7:e3:68:54
[    1.223544] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.230146] ehci-platform: EHCI generic platform driver
[    1.235508] ehci-orion: EHCI orion driver
[    1.239656] orion-ehci f1050000.usb: EHCI Host Controller
[    1.245122] orion-ehci f1050000.usb: new USB bus registered, assigned bus number 1
[    1.252835] orion-ehci f1050000.usb: irq 24, io mem 0xf1050000
[    1.284207] orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
[    1.290763] hub 1-0:1.0: USB hub found
[    1.295073] hub 1-0:1.0: 1 port detected
[    1.299433] orion-ehci f1051000.usb: EHCI Host Controller
[    1.304937] orion-ehci f1051000.usb: new USB bus registered, assigned bus number 2
[    1.312633] orion-ehci f1051000.usb: irq 25, io mem 0xf1051000
[    1.344155] orion-ehci f1051000.usb: USB 2.0 started, EHCI 1.00
[    1.350648] hub 2-0:1.0: USB hub found
[    1.354929] hub 2-0:1.0: 1 port detected
[    1.359565] usbcore: registered new interface driver usb-storage
[    1.365819] i2c /dev entries driver
[    1.369881] ata1: SATA link down (SStatus 0 SControl F300)
[    1.394724] orion_wdt: Initial timeout 229 sec
[    1.399490] sdhci: Secure Digital Host Controller Interface driver
[    1.405776] sdhci: Copyright(c) Pierre Ossman
[    1.410284] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.421607] marvell-cesa f1090000.crypto: CESA device successfully registered
[    1.429630] NET: Registered protocol family 10
[    1.435943] Segment Routing with IPv6
[    1.439690] NET: Registered protocol family 17
[    1.444645] 8021q: 802.1Q VLAN Support v1.8
[    1.448907] Registering SWP/SWPB emulation handler
[    1.456137] mv88e6085 f1072004.mdio-mii:00: switch 0x1710 detected: Marvell 88E6171, revision 2
[    1.472248] libphy: mdio: probed
[    1.677007] mv88e6085 f1072004.mdio-mii:00 lan1 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:00] driver [Generic PHY] (irq=POLL)
[    1.699072] mv88e6085 f1072004.mdio-mii:00 lan2 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:01] driver [Generic PHY] (irq=POLL)
[    1.713361] ata2: SATA link down (SStatus 0 SControl F300)
[    1.724388] mv88e6085 f1072004.mdio-mii:00 lan3 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:02] driver [Generic PHY] (irq=POLL)
[    1.744332] mv88e6085 f1072004.mdio-mii:00 lan4 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:03] driver [Generic PHY] (irq=POLL)
[    1.766575] mv88e6085 f1072004.mdio-mii:00 wan (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:04] driver [Generic PHY] (irq=POLL)
[    1.781413] mv88e6085 f1072004.mdio-mii:00: configuring for fixed/ link mode
[    1.789031] DSA: tree 0 setup
[    1.793279] UBI: auto-attach mtd5
[    1.796691] ubi0: attaching mtd5
[    1.799968] mv88e6085 f1072004.mdio-mii:00: Link is Up - 1Gbps/Full - flow control off
[    3.134587] ubi0: scanning is finished
[    3.148332] ubi0: attached mtd5 (name "ubi", size 996 MiB)
[    3.153854] ubi0: PEB size: 1048576 bytes (1024 KiB), LEB size: 1040384 bytes
[    3.161070] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
[    3.167910] ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
[    3.174912] ubi0: good PEBs: 994, bad PEBs: 2, corrupted PEBs: 0
[    3.180945] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
[    3.188208] ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 1605201715
[    3.197389] ubi0: available PEBs: 0, total reserved PEBs: 994, PEBs reserved for bad PEB handling: 78
[    3.207950] block ubiblock0_0: created from ubi0:0(rootfs)
[    3.213469] ubiblock: device ubiblock0_0 (rootfs) set to be root filesystem
[    3.220999] ubi0: background thread "ubi_bgt0d" started, PID 649
[    3.232675] VFS: Mounted root (squashfs filesystem) readonly on device 254:0.
[    3.242592] Freeing unused kernel memory: 1024K
[    3.265020] Run /sbin/init as init process
[    3.269137]   with arguments:
[    3.269140]     /sbin/init
[    3.269142]   with environment:
[    3.269144]     HOME=/
[    3.269146]     TERM=linux
[    3.496202] init: Console is alive
[    3.499767] init: - watchdog -
[    3.643084] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[    3.745878] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[    3.755831] init: - preinit -
[    4.297747] random: jshn: uninitialized urandom read (4 bytes read)
[    4.377356] random: jshn: uninitialized urandom read (4 bytes read)
[    5.271572] random: jshn: uninitialized urandom read (4 bytes read)
[    5.317161] urandom_read: 1 callbacks suppressed
[    5.317167] random: jshn: uninitialized urandom read (4 bytes read)
[    5.348916] random: jshn: uninitialized urandom read (4 bytes read)
[    5.371081] random: jshn: uninitialized urandom read (4 bytes read)
[    9.585237] mount_root: loading kmods from internal overlay
[    9.599659] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[    9.606952] kmodloader: done loading kernel modules from //etc/modules-boot.d/*
[    9.748845] UBIFS (ubi0:1): Mounting in unauthenticated mode
[    9.928772] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 741
[   10.117884] UBIFS (ubi0:1): recovery needed
[   10.822752] UBIFS (ubi0:1): recovery completed
[   10.827327] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[   10.835210] UBIFS (ubi0:1): LEB size: 1040384 bytes (1016 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes
[   10.845364] UBIFS (ubi0:1): FS size: 934264832 bytes (890 MiB, 898 LEBs), journal size 33292288 bytes (31 MiB, 32 LEBs)
[   10.856204] UBIFS (ubi0:1): reserved for root: 4952683 bytes (4836 KiB)
[   10.862851] UBIFS (ubi0:1): media format: w5/r0 (latest is w5/r0), UUID 750D90FD-F1F5-49D5-8297-7598A1A1518F, small LPT model
[   10.876518] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[   10.896494] block: extroot: not configured
[   10.900735] UBIFS (ubi0:1): un-mount UBI device 0
[   10.905535] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
[   10.916663] UBIFS (ubi0:1): Mounting in unauthenticated mode
[   11.096715] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 743
[   11.753658] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[   11.761571] UBIFS (ubi0:1): LEB size: 1040384 bytes (1016 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes
[   11.771719] UBIFS (ubi0:1): FS size: 934264832 bytes (890 MiB, 898 LEBs), journal size 33292288 bytes (31 MiB, 32 LEBs)
[   11.782558] UBIFS (ubi0:1): reserved for root: 4952683 bytes (4836 KiB)
[   11.789213] UBIFS (ubi0:1): media format: w5/r0 (latest is w5/r0), UUID 750D90FD-F1F5-49D5-8297-7598A1A1518F, small LPT model
[   11.890722] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[   11.907313] block: extroot: not configured
[   11.914019] mount_root: switching to ubifs overlay
[   11.946213] urandom-seed: Seeding with /etc/urandom.seed
[   12.003272] procd: - early -
[   12.006765] procd: - watchdog -
[   12.598643] procd: - watchdog -
[   12.601993] procd: - ubus -
[   12.652214] urandom_read: 1 callbacks suppressed
[   12.652221] random: ubusd: uninitialized urandom read (4 bytes read)
[   12.664532] random: ubusd: uninitialized urandom read (4 bytes read)
[   12.671823] procd: - init -
[   13.431798] kmodloader: loading kernel modules from /etc/modules.d/*
[   13.523356] urngd: v1.0.2 started.
[   13.701993] random: crng init done
[   13.707737] xt_time: kernel timezone is -0000
[   13.734635] PPP generic driver version 2.4.2
[   13.781709] NET: Registered protocol family 24
[   13.807964] kmodloader: done loading kernel modules from /etc/modules.d/*
[   19.164897] mvneta f1074000.ethernet eth0: configuring for fixed/rgmii-id link mode
[   19.173992] mvneta f1074000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   19.194253] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   19.239358] mv88e6085 f1072004.mdio-mii:00 lan1: configuring for phy/gmii link mode
[   19.274629] 8021q: adding VLAN 0 to HW filter on device lan1
[   19.280710] br-lan: port 1(lan1) entered blocking state
[   19.286040] br-lan: port 1(lan1) entered disabled state
[   19.314296] device lan1 entered promiscuous mode
[   19.318949] device eth0 entered promiscuous mode
[   19.456509] mv88e6085 f1072004.mdio-mii:00 lan2: configuring for phy/gmii link mode
[   19.491060] 8021q: adding VLAN 0 to HW filter on device lan2
[   19.548676] br-lan: port 2(lan2) entered blocking state
[   19.553940] br-lan: port 2(lan2) entered disabled state
[   19.594906] device lan2 entered promiscuous mode
[   19.616214] mv88e6085 f1072004.mdio-mii:00 lan3: configuring for phy/gmii link mode
[   19.646404] 8021q: adding VLAN 0 to HW filter on device lan3
[   19.664848] br-lan: port 3(lan3) entered blocking state
[   19.670122] br-lan: port 3(lan3) entered disabled state
[   19.710596] device lan3 entered promiscuous mode
[   19.726957] mv88e6085 f1072004.mdio-mii:00 lan4: configuring for phy/gmii link mode
[   19.757876] 8021q: adding VLAN 0 to HW filter on device lan4
[   19.772126] br-lan: port 4(lan4) entered blocking state
[   19.777458] br-lan: port 4(lan4) entered disabled state
[   19.816970] device lan4 entered promiscuous mode
[   19.848351] mv88e6085 f1072004.mdio-mii:00 wan: configuring for phy/gmii link mode
[   19.877792] 8021q: adding VLAN 0 to HW filter on device wan
[   23.618314] mv88e6085 f1072004.mdio-mii:00 lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[   23.626930] br-lan: port 1(lan1) entered blocking state
[   23.632183] br-lan: port 1(lan1) entered forwarding state
[   23.639450] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[   33.294450] 8<--- cut here ---
[   33.297537] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f65100
[   33.305231] pgd = 59d45f36
[   33.307949] [b6f65100] *pgd=2d7e8831, *pte=f0008383, *ppte=f0008a33
Reply Quote
wacke
Re: armada 370 L2 cache
November 16, 2020 12:37AM
Hi bodhi,

Use 0xf1 address got the resualt: 

root@OpenWrt:/# devmem 0xf1008100
0x00000001
root@OpenWrt:/# devmem 0xf1008104
0x12086300
root@OpenWrt:/# devmem 0xf1020200
0x01000002

But seems still not work properly.
Reply Quote
bodhi
Re: armada 370 L2 cache
November 16, 2020 12:55AM
wacke,

You are running OpenWrt, so I don't know what caused that error in the dmesg.

Perhaps you can boot with rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 on USB.

Your u-boot is newer so the appropriate kernel and Debian rootfs is in my release thread:

https://forum.doozan.com/read.php?2,32146

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
wacke
Re: armada 370 L2 cache
November 16, 2020 01:06AM
bodhi Wrote:
-------------------------------------------------------
> wacke,
>
> You are running OpenWrt, so I don't know what
> caused that error in the dmesg.
>

That error was the resault of devmem 0xd0008100, and now I can get the resault: 
root@OpenWrt:/# devmem 0xf1008100
0x00000001
root@OpenWrt:/# devmem 0xf1008104
0x12086300
root@OpenWrt:/# devmem 0xf1020200
0x01000002

But the 
 devmem 0xf1008104
output was not correct. How did you fix this?
Reply Quote
bodhi
Re: armada 370 L2 cache
November 16, 2020 04:02AM
wacke,

I'm not sure why your system reverse the address back to 0x12086300. 

[    0.000000] L2C: DT/platform modifies aux control register: 0x12086302 -> 0x12086300
[    0.000000] Aurora cache controller enabled, 4 ways, 256 kB
[    0.000000] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x12086300

If that address 0x12086300 is indeed correct then it is OK. 

root@OpenWrt:/# devmem 0xf1008100
0x00000001
root@OpenWrt:/# devmem 0xf1008104
0x12086300

It could be because your box has newer u-boot (the memory is different with this u-boot), but I cannot tell for sure.

You might try running my Debian rootfs and see if it behaves the same way as what we saw.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
tme
Re: armada 370 L2 cache
November 20, 2020 03:36PM
Hi bodhi,

On my Netgear ReadyNAS RN102, I installed and tested Linux kernel '5.8.5-mvebu-370xp-tld-1' with the dtb-file you posted on November 14th. From the boot log: 
[    0.000000][    T0] L2C: DT/platform modifies aux control register: 0x12086300 -> 0x1a086302
[    0.000000][    T0] Aurora cache controller enabled, 4 ways, 256 kB
[    0.000000][    T0] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302
...
[    0.543313][    T1] mvebu-pmsu: CPU idle is currently broken: disabling

The L2 control register, as well as the register following it, were set as expected: 
# busybox devmem 0xd0008100
0x00000001
# busybox devmem 0xd0008104
0x1A086302

The network bandwith was tested with 'netcat'. The box and my laptop were connected directly with a patch cable (no router). Both were assigned static IP addresses and 1 GiB of data were transferred. On the box 'netcat' was set to listen and discard: 
time nc -q 0 -l -p 2222 > /dev/null
On the laptop, 'pv' and 'netcat' were set to send 1 GiB of zeros: 
pv -S -s 1G /dev/zero | nc 192.168.1.141 2222
(Port 2222 and IP address 192.168.1.141 were arbitrarily chosen.)

Before installing the new dtb-file, it took 34 - 40 s (as reported by 'pv') to transfer the data (i.e. about 27 MiB/s). Afterwards, it took 22 - 23 s (i.e. about 44 MiB/s). A signifficant improvement indeed, but still not very impressive? If I understand correctly, enabling the CPU coherency should boost performance a bit further: 
# busybox devmem 0xd0020200
0x00000002

On the box, virtually all time was spent in the kernel, and almost nothing in user space: 
real	0m21.994s
user	0m0.258s
sys	0m20.562s

Thanks, Koen, for making me aware of this discussion!

Regards,
Trond Melen
Reply Quote
bodhi
Re: armada 370 L2 cache
November 20, 2020 04:10PM
Thanks Trond,

Cool! looks like it's almost all checked out for this performace improvement.

One test left to do is the iperf test.

David reported that on Mirabox his iperf number went from 400's Mbs to 800's Mbs. But mine went from 400's Mbs to 600's Mbs! It could be the switch I am using is not good. I'll have to set up the Mirabox a little better to see if I can get to 800 Mbs.

Now regarding the IO Cohenrency (the correct terminology), and the limitation in Linux kernel ability to determine hardware very early on. Since we are using a separate kernel for the Armada 370, danitool's patch is OK. I think it could be slightly adjusted to have a litle more clarity. This issue is similar for the reason (UART address) why I need to build different kernel and cannot use the standard MVEBU kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
tme
Re: armada 370 L2 cache
November 21, 2020 02:47AM
Quote
bodhi
One test left to do is the iperf test.

In this test, the laptop's IP address was 192.168.1.200. This is from the box: 
# iperf -c 192.168.1.200
------------------------------------------------------------
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.141 port 40814 connected with 192.168.1.200 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   861 MBytes   722 Mbits/sec
The performance was the same with a direct cable as when the traffic was relayed through a gigabit router.

I'm surprised to see that the bandwidth reported by 'iperf' is about twice that achieved with 'netcat'.'iperf' seems to report peak performance, which, by definition, is some performance measure the device is guaranteed never to exceed. The performance with 'netcat' seems closer to what one can expect as a user of the device.

I guess 'iperf' runs a "ping pong test" with multiple balls in motion. Does the data in this test actually hit memory at either end, or are the IP packages turned around by the PHY itself in some test mode with hardware loop-back?

Regards,
Trond Melen
Reply Quote
tme
Re: armada 370 L2 cache
November 21, 2020 03:24AM
I repeated the 'iperf' test, but now with the RT102 as the server. This is from the laptop: 
$ iperf -c 192.168.1.141
------------------------------------------------------------
Client connecting to 192.168.1.141, TCP port 5001
TCP window size:  612 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.200 port 44248 connected with 192.168.1.141 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   658 MBytes   552 Mbits/sec
The reported bandwith is down by almost 20%.

I also repeated the test with 'pv' and 'netcat', now transferring data from the box to the laptop. This is from the box: 
# time (pv -S -s 1G /dev/zero | nc 192.168.1.200 2222)
1.00GiB 0:00:47 [21.4MiB/s] [================================>] 100%            
^C

real	0m48.386s
user	0m1.394s
sys	0m46.365s
The elapsed time doubled from 23 s to 47 s (as reported by 'pv'). For the RT102, generating all those zeros and pushing them through the shell's pipe is a similar workload to pulling them from the Ethernet connector and discarding them. As before, very few CPU cycles were spent in user mode.

On the laptop, there was no stress: 
$ time nc -l -q 0 -p 2222 > /dev/null

real	0m52,696s
user	0m1,521s
sys	0m5,793s

Regards,
Trond Melen
Reply Quote
bodhi
Re: armada 370 L2 cache
November 21, 2020 04:02AM
Hi Trond,

The performance difference might have something to do with flow control, which is the default in this kernel.

You could run the bidirectional iperf test. See if you get a difference bandwidth.

Laptop: 

iperf -s -i 3

RN102: 

iperf -n2000M -i 3 -c 192.168.1.200


Quote

I guess 'iperf' runs a "ping pong test" with multiple balls in motion. Does the data in this test actually hit memory at either end, or are the IP packages turned around by the PHY itself in some test mode with hardware loop-back?

I believe iperf test is designed to measure the pure network performance so no packet is actually processed inside.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
tme
Re: armada 370 L2 cache
November 21, 2020 05:31AM
I have repeated the above tests on my second Netgear ReadyNAS RN102 running the current stock firmware version 6.10.3: 
# uname -a
Linux rn102 4.4.190.armada.1 #1 SMP Mon Oct 28 02:07:39 UTC 2019 armv7l GNU/Linux
# cat /etc/debian_version 
8.11
# dmesg | grep mvebu-pmsu
[    0.002181] mvebu-pmsu: Initializing Power Management Service Unit

Register snooping: 
# busybox devmem 0xd0008100
0x00000001
# busybox devmem 0xd0008104
0x1A086302
# busybox devmem 0xd0020200
0x00000002

Highlights from the boot log: 
[    0.000000] Memory policy: Data cache writeback
...
[    0.000000] Kernel command line: console=ttyS0,115200 reason=normal bdtype=rn102
...
[    0.000000] L2C: DT/platform modifies aux control register: 0x12086300 -> 0x1a086302
[    0.000000] Aurora cache controller enabled, 4 ways, 256 kB
[    0.000000] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302
...
[    0.002181] mvebu-pmsu: Initializing Power Management Service Unit

The laptop, cabled to the same gigabit router as the box, was set to generate and send 1 GiB of zeros: 
$ pv -S -s 1G /dev/zero | nc 192.168.1.192 2222
1,00GiB 0:00:12 [82,1MiB/s] [===================================================================================>] 100%            
^C
So the elapsed time (as reported by 'pv' on the laptop) was down from 22 s with open source firmware to 12 s with Netgear's firmware.

The box had already been set to listen and discard: 
# time nc -q 0 -l -p 2222 > /dev/null

real	0m13.329s
user	0m0.350s
sys	0m11.890s

I think the stock firmware deserves to be the base case, implying that the performance drop of the open source firmware was reduced from 67% to 45% by enabling the L2 cache. A lot of wasted CPU cycles are still to be found though, I'm afraid.

For completeness, here is the 'iperf' result with the laptop as the server: 
# iperf -c 192.168.1.200
------------------------------------------------------------
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.192 port 40402 connected with 192.168.1.200 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec
So the RT102 is capable of saturating a gigabit Ethernet connection, but currently only with the stock firmware. The performance drop was reduced to 23% by the L2 cache fix for the open source firmware (as reported by 'iperf' with default settings). I'm happier not knowing how much it was before the fix!

Regards,
Trond Melen
Reply Quote
bodhi
Re: armada 370 L2 cache
November 21, 2020 04:49PM
@daviddyer,

Could you post your iperf test? and also 

ethtool eth0

Thanks!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
daviddyer
Re: armada 370 L2 cache
November 21, 2020 07:14PM
Server is Optiplex790 (Intel i3-2100, 8GB memory, Dell OptiPlex 790 Motherboard with Intel Giga ethernet NIC) , Ubuntu , IP address
192.168.7.28

root@OptiPlex790:~# uname -a
Linux OptiPlex790 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root@OptiPlex790:~# iperf -s 

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.87 port 52996
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.10 GBytes   938 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.87 port 52998
[  4]  0.0-10.0 sec  1.09 GBytes   935 Mbits/sec

192.168.7.87 is Rock64 1GB single board computer with 1GB memory. Run to compare.

----------------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58602
[  4]  0.0-10.0 sec   976 MBytes   818 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58604
[  4]  0.0-10.0 sec   946 MBytes   793 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58606
[  4]  0.0-10.0 sec   947 MBytes   793 Mbits/sec

192.168.7.48 is mirabox with new dtb. Kernel 5.8.5 ~800Mb/s level
----------------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 39260
[  4]  0.0-10.0 sec   483 MBytes   405 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 39262
[  4]  0.0-10.0 sec   481 MBytes   403 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 39264
[  4]  0.0-10.0 sec   486 MBytes   407 Mbits/sec


192.168.7.48 is mirabox with old dtb. Kernel 5.8.5 ~400Mb/s level
----------------------------------------------------------------------------------------------------

root@Mirabox:~# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII FIBRE ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes


One strange thing: with L2 enabled, / disabled,

time echo "scale=4000; 4*a(1)" | bc -l

is about the same. At about 68 seconds, about the same level with goflexhome / dockstar



Edited 2 time(s). Last edit at 11/21/2020 07:16PM by daviddyer.
Reply Quote
bodhi
Re: armada 370 L2 cache
November 21, 2020 09:53PM
Thanks David!

I think your test proved that the optimum performance was achieved. Usually if we get 800-900 Mbs with iperf test, that's all we can do in real world usage. It is quite near the theoretical bandwidth. 

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58602
[  4]  0.0-10.0 sec   976 MBytes   818 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58604
[  4]  0.0-10.0 sec   946 MBytes   793 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58606
[  4]  0.0-10.0 sec   947 MBytes   793 Mbits/sec

192.168.7.48 is mirabox with new dtb. Kernel 5.8.5 ~800Mb/s level

So the bottom line, 2 important factors:

1. The network driver settings in this kernel. I'd suspect that when you turn off flow control, you will get even better network performance.

2. The network nodes that are currently in your environment. Whether a Gbit router, a managed Gbit switch, an unmanaged Gbit switch,... etc, all palying a role in optimum performance. But most importanly, it will depend on what setting a target node has in its NIC. For example, if flow control is not disabled throughout the network, there might still be some degraded performance between some nodes.

====

So to eliminate the effects of the MVEBU box network settings on other connecting nodes, I think I will need to revisit this issue and ensure the kernel driver will configure the NIC with flow control disabled, as a start.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 11/21/2020 10:03PM by bodhi.
Reply Quote
daviddyer
Re: armada 370 L2 cache
November 22, 2020 02:36AM
disable / enable flow control, no big difference.

--------------------------------------------------------------

Booted mirabox original firmware, installed iperf

root@mirabox-debian:/media/usb0# uname -a
Linux mirabox-debian 3.2.36 #5 Sun Oct 6 21:30:02 EDT 2013 armv7l GNU/Linux



[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60203
[ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60204
[ 4] 0.0-10.0 sec 1.10 GBytes 937 Mbits/sec
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60205
[ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec
Reply Quote
bodhi
Re: armada 370 L2 cache
November 22, 2020 03:09AM
Thanks David,

I've looked at the Mirabox stock boot log again today. I think this must be the reason you got 900's Mbs in stock vs 800's in Debian. Apparently, stock kernel has a patch for IO coherency. 

[Mon Mar 11 08:36:03 2019] Aurora L2 Cache Enabled
[Mon Mar 11 08:36:03 2019] Support IO coherency.

I will build the new kernel 5.9.3 with danitool patch, and see if that will make up for the difference.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
tme
Re: armada 370 L2 cache
November 22, 2020 03:13AM
Hi bodhi,

Here the output of 'ethtool' from both of my Netgear RedyNAS RN102 boxes: 
root@debian:~# uname -a
Linux debian 5.8.5-mvebu-370xp-tld-1 #1.0 SMP PREEMPT Mon Aug 31 00:00:32 PDT 2020 armv7l GNU/Linux

root@debian:~# ethtool --version
ethtool version 4.19

root@debian:~# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: d
	Link detected: yes
root@rn102:~# uname -a
Linux rn102 4.4.190.armada.1 #1 SMP Mon Oct 28 02:07:39 UTC 2019 armv7l GNU/Linux

root@rn102:~# ethtool --version
ethtool version 3.16

root@rn102:~# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: external
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: d
	Link detected: yes
So your kernel does not support "1000baseT/Half", while Netgear's kernel does not support (nor advertise) "pause frame use". Further, your transceiver is reported as "internal", while Netgear's kernel reports it as "external". Both of which cannot be true, right?

I also did 2 more kernel performance tests using 'dd' only. Generating 1 GiB of zeros and discarding them takes 1.7 s on both boxes: 
root@debian:~# dd if=/dev/zero of=/dev/null bs=32k count=32768
32768+0 records in
32768+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.7174 s, 625 MB/s

root@debian:~# dd if=/dev/zero of=/dev/null bs=32k count=32768
32768+0 records in
32768+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.7253 s, 622 MB/s
root@rn102:~# dd if=/dev/zero of=/dev/null bs=32k count=32768
32768+0 records in
32768+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.70022 s, 632 MB/s

root@rn102:~# dd if=/dev/zero of=/dev/null bs=32k count=32768
32768+0 records in
32768+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.69149 s, 635 MB/s

Generating 128 MiB of random numbers takes 5 s with your kernel and 40 s with the stock kernel: 
root@debian:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096
4096+0 records in
4096+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 4.83643 s, 27.8 MB/s

root@debian:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096
4096+0 records in
4096+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 5.05595 s, 26.5 MB/s

root@debian:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096
4096+0 records in
4096+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 5.0566 s, 26.5 MB/s
root@rn102:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096
4096+0 records in
4096+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 40.2958 s, 3.3 MB/s

root@rn102:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096
4096+0 records in
4096+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 40.3769 s, 3.3 MB/s

root@rn102:~# /dev/urandom of=/dev/null bs=32k count=4096
4096+0 records in
4096+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 40.2967 s, 3.3 MB/s
That is a 700% performance increase! I'm very happy to be able to report some, for you, encouraging performance numbers.

I guess Marvell Armada 370 SoC's hardware support for random number generation was activated above, and that Netgear didn't care to add it, neither to '/dev/random' nor to '/dev/hwrng': 
root@rn102:~# ls -alF /dev/hwrng 
crw------- 1 root root 10, 183 Nov 22 08:54 /dev/hwrng

root@rn102:~# hexdump -C -n 8 /dev/hwrng 
hexdump: /dev/hwrng: No such device

Regards,
Trond Melen
Reply Quote
bodhi
Re: armada 370 L2 cache
November 22, 2020 04:57AM
Trond,

Quote

So your kernel does not support "1000baseT/Half", while Netgear's kernel does not support (nor advertise) "pause frame use". Further, your transceiver is reported as "internal", while Netgear's kernel reports it as "external". Both of which cannot be true, right?

Ah, stock kernel has flow control disabled by default. That helps in negotiating with the node at the other end (whether it is a switch or NIC). I'm not sure why stock set it to "external", the LAN chip is part of the Armada 370 SoC.

Quote

That is a 700% performance increase! I'm very happy to be able to report some, for you, encouraging performance numbers.

Cool!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 11/22/2020 04:59AM by bodhi.
Reply Quote
bodhi
Re: armada 370 L2 cache
November 22, 2020 04:13PM
Hi Trond,

Please do this in stock and Debian for this box, and also on the PC/laptop that you use for testing iperf 

ip link show

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
tme
Re: armada 370 L2 cache
November 22, 2020 08:06PM
Hi bodhi, 

root@rn102:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 532
    link/ether 12:34:56:78:90:ab brd ff:ff:ff:ff:ff:ff

tme@debian:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether 34:56:78:90:ab:cd brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
4: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/tunnel6 :: brd ::

tme@t470s:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 12:34:12:34:12:34 brd ff:ff:ff:ff:ff:ff
4: wlp58s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 56:78:56:78;56:78 brd ff:ff:ff:ff:ff:ff
42: wwan0: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 90.ab:90.ab:90.ab brd ff:ff:ff:ff:ff:ff

Regards,
Trond Melen
Reply Quote
Page 2 of 2    Pages: Previous12
Newer Topic Older Topic
Author:

Subject:
Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: