Canonical Working To Ramp Up Ubuntu Support For The Raspberry Pi 4

[phoronix]

Phoronix: Canonical Working To Ramp Up Ubuntu Support For The Raspberry Pi 4

With the recently released Ubuntu 19.10 there is initial support for the Raspberry Pi 4 single-board computers sans the highest-tier 4GB version that embarrassingly suffers from USB ports not working with the current Ubuntu 19.10 build. Fortunately, Canonical is working to address that issue with the RPi4 4GB version as well as making other Raspberry Pi support improvements...

http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Better-Raspberry-Pi-4

[wizard69]

Make it stand out by being 64 bit only if it isn’t already.

it does make one wonder why the 4GB model suffers.

[bradlyatc]

This issue was resolved quickly with aarch64 ports of other distros on Rpi4b.

[Ironmask]

I'm legitimately curious how this happens. USB is a very well-defined standard and the kernel should be extremely adjusted to it. I don't feel like Canonical is to blame here. Is it the guys who make the Raspberry Pi? They are infamous for using GPUs that require proprietary drivers. Seriously, what happened?

[Grawp]

I'm legitimately curious how this happens. USB is a very well-defined standard and the kernel should be extremely adjusted to it. I don't feel like Canonical is to blame here. Is it the guys who make the Raspberry Pi? They are infamous for using GPUs that require proprietary drivers. Seriously, what happened?

On what planet or when do you live? Raspberry Pi is one of very few ARM boards which have fully opensource GPU drivers (and also having full OpenGL not just ES). Praise Eric Anholt for that.

[klokik]

I'm legitimately curious how this happens. USB is a very well-defined standard and the kernel should be extremely adjusted to it. I don't feel like Canonical is to blame here. Is it the guys who make the Raspberry Pi? They are infamous for using GPUs that require proprietary drivers. Seriously, what happened?

Probably some memory mapping overlap not taken into account. Say, usb controller address space blindly mapped onto region under 4gb boundary for the rest of the 32bit IP on SoC to access, and linux kernel does not know that it has to avoid using this region as regular ram.

EDIT: I've found the bug on github was opened almost 4 months ago. And the problem is that due to DMA limitation the buffer for usb controller has to be located in the lower 3gb zone of adress space, which is not a problem for 2gb units, but wa not handled priperly for 4gb boards.

[kaprikawn]

On what planet or when do you live? Raspberry Pi is one of very few ARM boards which have fully opensource GPU drivers (and also having full OpenGL not just ES). Praise Eric Anholt for that.

The GPU contains some firmware or something that is required for booting. Pretty sure it's a binary blob.

[Grawp]

The GPU contains some firmware or something that is required for booting. Pretty sure it's a binary blob.

or something... First of all the VideoCore VPU bullshit - for which the ARM core and QPU (SIMD processor) are just co-processors - requires the firmware to boot. The firmware contains/contained code that used the QPU to provide GPU functionality. This is not utilized anymore. The opensource drivers utilize the QPU directly now.. full instruction set for the QPU had been known for a while back then.

So no, the GPU does not require binary blob to function. This was not true just few years back. The blob is used just for booting Pi up now, not for providing GPU functionality.

[bison]

Probably some memory mapping overlap not taken into account. Say, usb controller address space blindly mapped onto region under 4gb boundary for the rest of the 32bit IP on SoC to access, and linux kernel does not know that it has to avoid using this region as regular ram.

Thanks for the explanation. It seems likely that this is what is happening.

[QwertyChouskie]

Does anyone know if this is running the RPi Foundation kernel, a RPi-modified Ubuntu kernel, or the stock Ubuntu aarch64 kernel? My 3B+ runs aarch64 Ubuntu with the hwe-edge stock kernel. On problem is the lack of CPUFreq driver, but that should come with the next kernel version update (the driver was upstreamed in 5.2 or 5.3, can't remember which). Anyways, always nice to see lots of distros working on support for the RPi 4, it'd be nice if OSMC would get a RPi4-capable update soon.