Ubuntu 19.10 server was recently released with official support for Raspberry Pi 4 SBC. Shortly after I read stories about the USB ports not working on the board, but it took another interesting turn as Canonical now explains the bug only affects RPI 4 with 4GB RAM, and USB works just fine on boards with just 1/2GB RAM.
The issue has been identified and it’s been found to be a kernel bug with a solution in the works that being tested. In the meantime, you can access to your Raspberry Pi 4 4GB USB ports by limiting the memory to 3GB in /boot/firmware/usercfg.txt as follows:
|
1 |
total_mem=3072 |
Alternatively here’s the link to an updated kernel provided by Hui Wang with you want to test it out:
I built a testing kernel, not only includes the fix for USB host, but also includes all new patches from https://github.com/raspberrypi/linux.git rpi-5.3.y branch (about 107 patches).
I tested both arm64 and armhf kernels on Pi4 without HDMI monitor, everything works well.
Could anybody help test these two kernels on Pi4 with HDMI monitor, Pi3 and Pi2 if you have any of them?
After verifying the kernel will not introduce regression on Pi4/3/2, I will submit the patches to UBUNTU kernel.
The new kernel could be downloaded: https://people.canonical.com/~hwang4/rpiv2/
To install and test the kernel: copy arm64 or armhf folders to rootfs of Pi, sudo dpkg -i linux-modules-xxxx.deb; sudo dpkg -i linux-image-xxx.deb;sudo reboot
The explanation about the bug is likely related to the “Pi4 Arm64 USB Device descriptor errors” issue on Raspberry Pi’s Linux issue tracker and that was fixed by implementing pcie-brcmstb DMA bounce buffer to ARM64.
Beside discussing about the USB bug, Canonical also announced their roadmap for Raspberry Pi 4 support with Ubuntu 18.04 HWE being next, and Ubuntu Core coming after.
Via Phoronix
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Colorblind person here. Are the colors for ‘current’ and ‘next’ supposed to be the same?
No.
Current is green, only for rpi 1&2 GB.
Next is orange, for rpi 4 GB and ubuntu 18.04 release.
Future is red, for ubuntu core release.
“Future is red” is quite a depressive prediction…
No, “current” is green vs orange for “next”. Only the first two on the left (19.10 for 1 & 2 GB) are green thus “current”.
Such issues would be discovered and fixed earlier if RPI foundation made the jump to 64bit by default instead of leaving it to distro vendors to discover hardware compatibility issues the hard way :-/
And it still doesn’t change a single bit that Ubuntu on x86 is something entirely different than on ARM.
>And it still doesn’t change a single bit that Ubuntu on x86 is something entirely different than on ARM.
I don’t use ubuntu so pardon my ignorance but it’s the same userland just built for ARM isn’t it? Like Debian is? Or is there something else?
It’s not about the userland but the kernel or ‘Linux’ as it’s also called 😉
Canonical has a whole team assigned to the kernel on x86. With ARM there’s nothing (maybe situation is better if you run one of the few qualified ARM servers Canonical provides support for). As can be seen above there’s one Canonical employee taking care of the RPi kernel (using patches from RPi Trading guys and having to use ‘external resources’ AKA RPi users for ‘QA’). If you use Ubuntu on other ARM platforms it gets even worse (regardless whether you use the average crappy Ubuntu OS image a board vendor provides or an Ubuntu Armbian flavor).
Just three subjective simple points:
* “Canonical Livepatch Service” provides the ability on x86 to get kernel upgrades without a reboot.
* ZFS integration: since Ubuntu 16.04 using ZFS is completely painless on x86 due to a team taking care of the integration issues (maybe this will stop soon once some Linux kernel folks start to sue Canonical for these integration efforts due to license incompatibilities)
* On x86 it’s a team looking at kernel issues interconnected with Canonical’s security guys. With ARM or the RPi platform some individual pulls in whatever patches that float around. Even those from RPi Trading guys that might even interact with the VideoCore crap rendering all Linux security concepts pretty much useless. It’s simply a different world.
For me the greatest Ubuntu feature is ZFS support. On x86 not worth a thought, on ARM simply PITA. I could tell a long story about two ODROID HC2, Armbian Bionic, ZFS and why all of this sucks… but I guess nobody wants to read about this stuff 🙂
>Canonical has a whole team assigned to the kernel on x86.
Ok. I read what you wrote as ubuntu shipping some slightly different make up of software for ARM.
TBH I don’t think throwing a whole ubuntu team at ARM would make much difference. x86 is a good way ahead in the generic computer space and ARM vendors don’t seem to want to move out of the Android or “port, ship, forget” space any time soon.
@tkaiser ” I could tell a long story about two ODROID HC2, Armbian Bionic, ZFS and why all of this sucks… ”
Hi,
I would like to hear why this sucks?
I thought to buy HC2.
Technically, they leave it to the users to discover the issues the hard way, and to the distro vendors to fix those issues.
>The issue has been identified and it’s been found to be a kernel bug with a solution in the works that being tested.
TBH this doesn’t look like a kernel bug i.e. it’s meant to work but it doesn’t. It looks like a no one actually tested it issue.
Nico D, pointed this out almost a week ago. I installed Ubuntu 19.10 32 bit in my Rpi 4 4Gb OC’d at 1750Mhz(CPU) and 600Mhz(GPU)and feels sluggish, almost unusable, too freaking slow, even after moving rootfs to my USB 3.0 Samsung T5 SSD drive to run it from there. I’ll stick to Raspbian running on my Rpi 4 OC’d at 2.0Ghz and 650 Mhz for GPU for pure speed. I’d definitely prefer to use a Linux Distro 64 bit version.
I also addressed this in my video about Ubuntu Mate 19.10 on the Raspberry Pi 4.
https://youtu.be/lmQItlK1e04
I can’t understand how they didn’t notice this before release. Nobody gotten a RPi4 4GB at Canonical cause RPi people too greedy or so? Probably close to the truth 🙂
Ubuntu does run well on the RPi4. But I rather use any other SBC.
One developer said he did not notice because he set the memory to 3GB during testing. Not sure why exactly though.
Likely because 4GB on 32-bit sounds almost pointless to most users. I mean, you can’t use this into a single process. Just start firefox, browse a few sites, see it fail to allocate memory while you still have 1.5 GB available… This is ridiculous IMHO. The really positive point I noticed when they announced a 4GB board was that this will likely convince them to switch to 64-bit for their next board.
Point accepted because Ben Upton himself didn’t see the need for 64-bit OS for RPi a year or so ago. Commendable on Canonical’s part to push the envelope. The 64-bit OS would be, IMHO, purely for “server” use and not desktop/client use.
> The 64-bit OS would be, IMHO, purely for “server” use and not desktop/client use
And what would be the benefits of 64-bit here? Yesterday I did a quick check with their 64-bit Ubuntu 19.10 image on my RPi 4. For whatever reasons 65 MB of RAM are missing compared to Raspbian Buster which results in some of my standard benchmarks not finishing. In general memory footprint is higher and overall performance is worse with such ‘server use’: https://github.com/ThomasKaiser/sbc-bench/commit/89c4a2a901fcecf8ba26a138dcc4e8146bd6189a (especially OpenSSL performance halved compared to Raspbian, but due to missing ARMv8 Crypto Extensions using any RPi for this stuff is rather stupid anyway).
Everything used to be broken when using the full 4GB, it’s only recent patches that have fixed it.
So they would have enabled it in the beginning, and forgot to disable it.
> it’s only recent patches that have fixed it
With a 64-bit kernel while there were no problems with 32-bit.
RPi is a 32-bit world and the RPi Trading guys simply did not care about 64-bit since their main platform called VideoCore is 32-bit anyway. Please remember that the ARM cores on any RPi are just guests running a secondary operating system.
They plan on providing a stable 64-bit kernel sometimes in the future (to be still combined with a 32-bit userland called Raspbian) and as such any 3rd party attempts to use the RPi with a full 64-bit software stack are mostly a matter of ignorance.
Simpleton “moi” here: “Canonical was never gifted a 4GB board by the Raspberry Pi Foundation.” Nobody at Canonical tested it let alone read the specs.
> I can’t understand how they didn’t notice this before release
Why should they care? Their platform is called ‘VideoCore’ which is from decades ago and remains 32-bit most probably forever. 64-bit abilities simply don’t matter for them since their most important asset is backwards compatibility. This is why they only take care about Raspbian which in fact is a crippled 32-bit Debian derivate with a lot of hacks to perform better on ARM11 from 2 decades ago.
The average RPi Joe will always use Raspbian, some ‘nerds’ who don’t know how the Raspberry Pi works (Linux being still a 2nd or 3rd class citizen on this platform) want other options and then Linux distro vendors like Suse or Canonical dedicate some limited resources to this platform solely for marketing reasons.
I don’t think “greedy” is the right term here. The buyers of the 4GB model want to run leverage the RPi for bigger challenges and somebody (either donating or purchasing) overlooked the availability of the 4GB model for testing.
The sad part is that after the fix (to the kernel) by Hui Wang nobody at Canonical seems to care about updating the pre-install image. There is no communication and no acknowledgement. It is only thanks to the user community at large (and, of course, Hui Wang) that we have a working solution for the 4GB model. But given the resources at their disposal and web clicks it would generate I would have thought that Canonical would be more proactive on this front.
There is new packages
https://people.canonical.com/~hwang4/v3d/
with “working” gpu acceleration
How does one get Canonical to provide a GA date for the updated (i.e. with Hui Wang fix) pre-installed image? My efforts to solicit any response from the Product Manager (at Canonical) have fallen on deaf years.
Forgive a newbie… if I wanted to max out, would I grab the 64 bit image, do the “total_mem=3072”, install Hui Wang’s updated kernel packages, then take out the “total_mem=3072”??? then install Cinnamon and start testing the overclocking?
Just download latest ubuntu image and everything should be fine I think
Jean-Luc, I hope that you can keep us apprised on future news/discussions on the RPi4 4GB ubuntu-server image. Thanks for your well crafted article here – sufficient technical details to digest (i.e. NOT click-bait!) but at the same time not overloading the “user” with extraneous technical fluff.
A+
How do I edit the /boot/firmware/usercfg.txt file if I can’t use my peripherials? Don’t have any ssh instaled 🙁
Hi, can anyone here point me in the right direction for this:
I seem to be having a situation where my usb 3.0 wifi adapter connects to the usb 2.0 bus port. I can force usb 3.0 in the realtek driver but that almost kills my usb 2.0 connected keyboard/touchpad. I am running Raspian OS (32bit) updates are current, on Raspberry Pi 4B 4GB.
I realize this is an old thread, I can’t find info anywhere else so I thought I’d try here.
Thanks in advance.