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
Hi Stewart,
Thanks for checking, looks like all settings can be considered confirmed now.
Regarding USB, you probably mean the difference between unplugging from the wall and the
board? This is normal, in the first case you have to wait for both the smps and the board
to bleed, in the latter just the board. In the end the result will be the same, but wall
side will take much longer.
For the cpu, there is quite some information in /sys, but the location might depend on
your scaling governor. In my case frequency info was under
/sys/devices/system/cpu/cpufreq/policy*, you can look for "scaling_cur_freq",
other cpu info under /sys/devices/system/cpu, e.g.
[root@localhost cpu]# grep cortex cpu*/uevent
cpu0/uevent:OF_COMPATIBLE_0=arm,cortex-a7
cpu1/uevent:OF_COMPATIBLE_0=arm,cortex-a7
cpu2/uevent:OF_COMPATIBLE_0=arm,cortex-a7
cpu3/uevent:OF_COMPATIBLE_0=arm,cortex-a7
cpu4/uevent:OF_COMPATIBLE_0=arm,cortex-a15
cpu5/uevent:OF_COMPATIBLE_0=arm,cortex-a15
cpu6/uevent:OF_COMPATIBLE_0=arm,cortex-a15
cpu7/uevent:OF_COMPATIBLE_0=arm,cortex-a15
Best regards,
Vince