Hello Vince,
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 -t
/: 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
Interestingly, 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.
Also, the "lscpu -a -e" command provides the following:
[root@myodroid-wireless devices]# lscpu -a -e
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
Note, 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:
[root@myodroid-wireless devices]# pwd
/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
The 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.
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?
Stewart
Hi 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
|
