From: Peter Robinson [mailto:firstname.lastname@example.org]
Sent: Wednesday, August 22, 2018 5:04 PM
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
> > > - 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
> 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
> > > 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  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
- 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