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:
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.
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.
Colorblind person here. Are the colors for ‘current’ and ‘next’ supposed to be the same?
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… Read more »
>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… ”
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.
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… Read more »
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… Read more »
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… Read more »
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… Read more »
There is new packages
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.
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.