> -----Original Message-----
> From: Peter Robinson [mailto:pbrobinson@gmail.com]
> Sent: Wednesday, August 22, 2018 5:04 PM
> To: vincegeze@gmail.com
> Cc: arm@lists.fedoraproject.org
> 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@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/message/Y7EMT5B5HYSV3SX533YZZHOOEOMRHNFZ/
No comments:
Post a Comment