> -----Original Message----- > From: Peter Robinson [mailto:pbrobinson@xxxxxxxxx] > Sent: Wednesday, August 22, 2018 5:04 PM > To: vincegeze@xxxxxxxxx > Cc: arm@xxxxxxxxxxxxxxxxxxxxxxx > Subject: Re: [fedora-arm] F28 on odroid XU4 > > > > > First of all I would like to thank all contributors for figuring > > > > out the bits and pieces that make the F28 images bootable and > > > > functional on the odroid XU4. > > > > > > > > However, I noticed a couple of things after booting the F28 server > image: > > > > - network interface (r8152) is connected as USB2 > > > > - connecting USB3 devices seems to be hit or (mostly) miss, they > > > > are detected by the xhci driver, but usually after they are > > > > already connected as > > > > USB2 > > > > > > What kernel are you running? Are you running the GA kernel > > > (4.16.something?) or have you upgraded to the latest (4.17.x) as I > > > believe both of those issues were fixed in updates kernels. > > > > > I noticed this with 4.16.3-301.fc28 included in the image, but there was the > same behaviour with 4.17.11-200.fc28 and rawhide 4.18.0-0.rc7.git2.1.fc29. I > have to say things indeed _do_ work with the default f28 kernels, you only > notice the performance issue by checking the output of lsusb -t, dmesg or > console when plugging in a USB3 device. My guess is there is some kind of > race between the ehci/ohci and xhci modules, with the latter being loaded > too slow or too late, because I do see detection messages for both USB2 and > USB3 on the console, but usually USB2 comes first and USB3 after connection > is established as USB2. Since r8152 is USB based, this probably is linked. > > > > > > - it seems like only the 4 A7 cores are active and switching to > > > > the 4 > > > > A15 cores is not possible > > > > > > Hmm, what does lscpu report? Also what u-boot are you using? I'm not > > > 100% sure here but I thought they were working, although with > > > big.little I'm not sure wthether they switch the whole cluster under > > > load or just bring more cpus online. > > > > > /proc/cpuinfo reports the 4 A7 cores, upon loading (load average>4) I can > see these cores up in /sys/.../cpu[0-3], but the A15 cores cpu[4-7] don't > seem to become active. Lscpu I don't know by heart, would need to check. > The line " # CONFIG_BL_SWITCHER is not set" changes this to all 8 cores up all > the time (exynos HMP). Again, the system works, but with reduced > performance. > > The u-boot is the one for odroid-xu3 in the fedora 28 image, cat of .bin and > .dtb. Not sure if the cat is required. > > > > > > Since I noticed the Hardkernel Ubuntu image does correctly detect > > > > USB3, the issue could not be purely related to hardware design or > > > > bus power, so I decided to recompile (then) F28 kernel 4.17.11-200 > > > > with some alternative config settings, compiling in lots of USB > > > > related modules. In the end I got to the point where USB3 devices > > > > and the Ethernet chip indeed are detected as USB3, some more > > > > fiddling also > > > enabled all 8 cores simultaneously. > > > > Attached you find the kernel-local used to modify the config, > > > > which still can use some cleaning up. > > > > > > I would need a diff against the fedora config because I don't have > > > the time to work out what's changed but a lot of stuff is built in > > > by the look of it and that's not going to happen in the upstream > > > kernel, it's also strange that it's needed since others have > > > reported it works fine, it of course could be a regression but the > > > above changes work around a regression not fix it. The Hardkernel > > > group have never been particularly upstream friendly so it's anyone's > guess. > > > > > > > One point now remains, these adjustments require recompiling the > > > > kernel each time an update is available, thus breaking an easy > > > > update path. Would there be a way to achieve a similar result > > > > using initramfs and > > > grub options? > > > > Thanks in advance for your comments and feedback! > > > > > > See above. > > > > Everything works, but some bits and pieces seem sub-optimal. Could > anyone else check the output of `lsusb -t` on an odroid XU4 with stock fedora > 28/29 kernel? I'm mostly interested in the USB stuff, if that is sorted out, I > can easily evaluate cpu power. Maybe just A7 already does the trick. > > > > The main difference between both kernel configs is built in vs module for > USB related stuff, so this makes me wonder about modifying initramfs > and/or grub instead of recompiling. Any suggestion to this end would be > appreciated and can be tested quite fast. > > man 5 dracut.conf Well, after countless reboots it seems to be even more simple. - USB3: preloading xhci-plat-hcd, which already is in the initramfs, is sufficient to get proper USB3 operation and the r8152 at full speed as well - CPU HMP: this one I already knew was linked to the CONFIG_BL_SWITCHER. On [1] it is mentioned there are both sysfs and kernel boot options to control this behavior. The sysfs path exists and with lscpu you can see all 8 cores being put online. The kernel boot command however turned out to be incorrect, but after some digging I found you only need "no_bL_switcher" as boot option. Since the board will be used headless, I also enabled the blinking led by preloading ledtrig-heartbeat, but this needs to be included in a /etc/dracut.conf.d/ conf file with 'add_drivers+=" ledtrig-heartbeat "'. The blinking frequency also gives an indication of the load. The final boot line now looks like this: append ro rd.driver.pre=ledtrig-heartbeat,xhci-plat-hcd root=UUID=your_UUID cpuidle.off=1 no_bL_switcher console=tty1 console=ttySAC2,115200n8 Result: - systematically correct detection of USB3 - performance improvement by enabling all cpus - indication whether the system is alive or not - no need for recompiling kernels, only boot time options and an optional dracut inclusion Best regards, Vince [1] https://wiki.linaro.org/projects/big.LITTLE.MP/Big.Little.Switcher/Docs/porting-guide _______________________________________________ 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/message/Y7EMT5B5HYSV3SX533YZZHOOEOMRHNFZ/
