> 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. > - 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. > 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. _______________________________________________ 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/LBME35N7RRZBDEFEMY4GFDWNC7UHGRJY/
