FYi. I can now confirm that removing and reinserting the power plug does in fact change the value of the r8152 driver value as follows:
[root@myodroid-wireless devices]# lsusb -tInterestingly, shutting down the system and powering it off via and extension cord switch had not effected the change. But complete removal and restoration of the power cord into the chassis results in the output above.
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 14, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 4: Dev 12, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 12, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 12, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 11, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 2: Dev 11, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 1: Dev 13, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 13, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 13, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 15, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=rtl8192cu, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
Also, the "lscpu -a -e" command provides the following:
[root@myodroid-wireless devices]# lscpu -a -eNote, cpu 0 (cores 0-3) aligns with the Cortex A7 processor and cpu 1 (cores 4-7) aligns with the Cortex A15 processor. Although "dmesg" does not specifically identify the A15 Processor, the system does in fact recognize it, as can be seen in /sys/devices as follows:
CPU SOCKET CORE ONLINE MAXMHZ MINMHZ
0 0 0 yes 1300.0000 200.0000
1 0 1 yes 1300.0000 200.0000
2 0 2 yes 1300.0000 200.0000
3 0 3 yes 1300.0000 200.0000
4 1 4 yes 1800.0000 200.0000
5 1 5 yes 1800.0000 200.0000
6 1 6 yes 1800.0000 200.0000
7 1 7 yes 1800.0000 200.0000
[root@myodroid-wireless devices]# pwdThe cpus associated with the armv7_cortex_a15 can indeed be seen in the file "cpus" under the armv7_cortex_a15 directory and align perfectly with the output from the "lscpu -a -e" command. So it would seem the "lscpu" command does report as expected.
/sys/devices
[root@myodroid-wireless devices]# ls -l
total 0
drwxr-xr-x 5 root root 0 Aug 29 19:20 armv7_cortex_a15
drwxr-xr-x 5 root root 0 Aug 29 19:20 armv7_cortex_a7
drwxr-xr-x 3 root root 0 Aug 29 19:20 breakpoint
drwxr-xr-x 4 root root 0 Aug 29 19:20 kprobe
drwxr-xr-x 24 root root 0 Aug 29 14:01 platform
drwxr-xr-x 3 root root 0 Aug 29 19:20 software
drwxr-xr-x 7 root root 0 Aug 29 19:20 system
drwxr-xr-x 3 root root 0 Aug 29 19:20 tracepoint
drwxr-xr-x 4 root root 0 Aug 29 19:20 uprobe
drwxr-xr-x 16 root root 0 Aug 29 19:20 virtual
Thanks again for your work on this.
Stewart
On 08/29/2018 05:17 AM, Vince Geze wrote:
Hello Vince, Thanks for the work you've done to get 8 cores working on the Odroid-XU4. Here is the output you asked of Andreas from my XU4 running the latest fedora kernel: [root@myodroid-wireless ~]# uname -a Linux myodroid-wireless 4.17.18-200.fc28.armv7hl #1 SMP Wed Aug 22 20:36:45 UTC 2018 armv7l armv7l armv7l GNU/Linux [root@myodroid-wireless ~]# [root@myodroid-wireless ~]# lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 12M |__ Port 4: Dev 9, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 4: Dev 9, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 8, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 2: Dev 8, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 1: Dev 7, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=rtl8192cu, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M Also, here is some other output of interest: [root@myodroid-wireless ~]# cpupower frequency-info analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 154 us hardware limits: 200 MHz - 1.30 GHz available frequency steps: 200 MHz, 300 MHz, 400 MHz, 500 MHz, 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30 GHz available cpufreq governors: conservative userspace powersave ondemand performance schedutil current policy: frequency should be within 200 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 700 MHz (asserted by call to hardware) [root@myodroid-wireless ~]# cpupower frequency-info --governors analyzing CPU 0: available cpufreq governors: conservative userspace powersave ondemand performance schedutil [root@myodroid-wireless ~]# cpupower frequency-set --governor performance Setting cpu: 0 Setting cpu: 1 Setting cpu: 2 Setting cpu: 3 Setting cpu: 4 Setting cpu: 5 Setting cpu: 6 Setting cpu: 7 [root@myodroid-wireless ~]# cpupower frequency-info analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 154 us hardware limits: 200 MHz - 1.30 GHz available frequency steps: 200 MHz, 300 MHz, 400 MHz, 500 MHz, 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30 GHz available cpufreq governors: conservative userspace powersave ondemand performance schedutil current policy: frequency should be within 200 MHz and 1.30 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency: 1.30 GHz (asserted by call to hardware) [root@myodroid-wireless ~]# lscpu Architecture: armv7l Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 2 Vendor ID: ARM Model: 3 Model name: Cortex-A7 Stepping: r0p3 CPU max MHz: 1800.0000 CPU min MHz: 200.0000 BogoMIPS: 78.00 Flags: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae [root@myodroid-wireless ~]# dmesg [ 0.000000] Booting Linux on physical CPU 0x100 [ 0.000000] Linux version 4.17.18-200.fc28.armv7hl (mockbuild(a)buildvm-armv7-06.arm.fedoraproject.org) (gcc version 8.1.1 20180712 (Red Hat 8.1.1-5) (GCC)) #1 SMP Wed Aug 22 20:36:45 UTC 2018 [ 0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Hardkernel Odroid XU4 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.000000] cma: Reserved 192 MiB at 0xb2800000 [ 0.000000] Samsung CPU ID: 0xe5422001 [ 0.000000] On node 0 totalpages: 518656 [ 0.000000] Normal zone: 1728 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 322048 pages, LIFO batch:31 [ 0.000000] Running under secure firmware. [ 0.000000] random: fast init done [ 0.000000] percpu: Embedded 16 pages/cpu @(ptrval) s34572 r8192 d22772 u65536 [ 0.000000] pcpu-alloc: s34572 r8192 d22772 u65536 alloc=16*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 516928 [ 0.000000] Kernel command line: ro rd.driver.pre=ledtrig-heartbeat,xhci-plat-hcd root=UUID=d4a4b86d-5e86-4bcb-b79c-2bde6831b7c5 cma=192MB cpuidle.off=1 LANG=en_US.UTF-8 no_bL_switcher [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 1822580K/2074624K available (8168K kernel code, 1328K rwdata, 3920K rodata, 2048K init, 505K bss, 55436K reserved, 196608K cma-reserved, 1091584K highmem) [ 0.000000] Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .text : 0x(ptrval) - 0x(ptrval) (9161 kB) .init : 0x(ptrval) - 0x(ptrval) (2048 kB) .data : 0x(ptrval) - 0x(ptrval) (1329 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 506 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [ 0.000000] ftrace: allocating 37441 entries in 74 pages [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=8. [ 0.000000] Tasks RCU enabled. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] GIC physical location is 0x10481000 [ 0.000000] Switching to timer-based delay loop, resolution 41ns [ 0.000000] clocksource: mct-frc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns [ 0.000007] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [ 0.000033] genirq: irq_chip COMBINER did not update eff. affinity mask of irq 49 [ 0.006905] Console: colour dummy device 80x30 [ 0.007535] console [tty0] enabled [ 0.007603] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=24000) [ 0.007640] pid_max: default: 32768 minimum: 301 [ 0.007903] Security Framework initialized [ 0.007927] Yama: becoming mindful. [ 0.007994] SELinux: Initializing. [ 0.008199] SELinux: Starting in permissive mode [ 0.008297] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.008335] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.009575] CPU: Testing write buffer coherency: ok [ 0.010559] CPU0: thread -1, cpu 0, socket 1, mpidr 80000100 [ 0.011506] Setting up static identity map for 0x40300000 - 0x403000a0 [ 0.012297] ARM CCI driver probed [ 0.012546] Exynos MCPM support installed [ 0.015526] Hierarchical SRCU implementation. [ 0.022460] EFI services will not be available. [ 0.023397] smp: Bringing up secondary CPUs ... [ 0.024680] CPU1: thread -1, cpu 1, socket 1, mpidr 80000101 [ 0.026094] CPU2: thread -1, cpu 2, socket 1, mpidr 80000102 [ 0.027452] CPU3: thread -1, cpu 3, socket 1, mpidr 80000103 [ 0.028759] CPU4: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.030181] CPU5: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.031561] CPU6: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.032919] CPU7: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.033125] smp: Brought up 1 node, 8 CPUs [ 0.033262] SMP: Total of 8 processors activated (384.00 BogoMIPS). [ 0.033284] CPU: WARNING: CPU(s) started in wrong/inconsistent modes (primary CPU mode 0x1a) [ 0.033309] CPU: This may indicate a broken bootloader or firmware. Note the following: * Although 8 cores are recognized, the "lscpu" command (and the "dmesg" snippet) recognizes only the A7 processor. * The default cpu governor is "ondemand" providing a cpu frequency of 700 MHz for all cores per the output of the first "cpupower frequency-info" above. * The cpu governor and frequency can be changed to "performance" and 1300 MHz, respectively by using the command "cpupower frequency-set --governor performance", but this is not persistent between reboots. To make it persistent between reboots follow this procedure: https://ask.fedoraproject.org/en/question/39964/how-to-permanently-set-cp... * Note the last two lines in the "dmesg" command. There may be additional code required in the bootloader or firmware to recognize the A15 processor correctly. Does anyone have any ideas here? StewartHi Stewart, I don't think lscpu is the best source of cpu related info on this device. You can have a look at the /sys tree, I'm not at my device now but I think it's /sys/bus/cpu. There should be a lot of files with cpu related info there, probably even with the correct core type a7/a15. The system boots on an a7 core, so that's probably what you see with lscpu and dmesg. Not sure about the cpu mode, my guess it's related to kernel and user cpu modes, with the cpu not enabled in the mode the bootloader expects. The frequency/voltage pairs in dts are limited to 1.3/1.8GHz, so that's the maximum we get for now. I seem to remember frequencies being downscaled from 1.4/2.1GHz, but I'm not sure what was the background. That being said, when looking at the "current frequency" in /sys, I have the impression the default ondemand governor is behaving as expected, scaling frequency up and down depending on load. Maybe you can try monitoring those files as well? I'll have a look when I have access to the device again. Regarding the r8152 driver, did you just reboot after making the kernel option changes, or shutdown and remove power completely? The first seems to retain part of the old config, the latter will be a full reset and should behave correctly. Best regards, Vince _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
No comments:
Post a Comment