Add Pi Compute Module 3 Support

Bug #1806813 reported by DavidT
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
flash-kernel (Ubuntu)
Fix Released
Undecided
Unassigned
livecd-rootfs (Ubuntu)
Invalid
Undecided
Unassigned
u-boot (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Hi all,

Apologies if this is not the proper location for reporting this bug / feature request. If there is a more applicable place for it, please just let me know.

I have been doing some testing on the newly released Raspberry Pi 3 64-bit ARM preinstalled server image located here: http://cdimage.ubuntu.com/releases/18.04/beta/

I am particularly interested in running this image on the Raspberry Pi Compute Module 3 (the model that has 4gb of eMMC onboard, located here: https://www.raspberrypi.org/products/compute-module-3). However, after flashing this Ubuntu Server image to the Compute Module 3, U-boot is unable to locate a device tree and proceed with booting.

The serial console output is:

U-Boot 2018.03+dfsg1-2ubuntu1.1~18.04.1~test1 (Nov 20 2018 - 11:50:30 +0000)

DRAM: 948 MiB
RPI: Board rev 0xa unknown
RPI Unknown model (0xa020a0)
MMC: mmc@7e202000: 0, sdhci@7e300000: 1
Loading Environment from FAT... WARNING at /build/u-boot-B3y2jo/u-boot-2018.03+dfsg1/drivers/mmc/bcm2835_sdhost.c:437/bcm2835_send_command()!
WARNING at /build/u-boot-B3y2jo/u-boot-2018.03+dfsg1/drivers/mmc/bcm2835_sdhost.c:437/bcm2835_send_command()!
OK
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
23914504 bytes read in 817 ms (27.9 MiB/s)
18931168 bytes read in 648 ms (27.9 MiB/s)
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
U-Boot>

I can flash and boot a default Raspbian image fine on this Compute Module 3, so, the hardware is functional. I made a few attempts at configuring an FDT address as the error indicates, but was unsuccessful. I also copied over a Compute Module 3 .dtb from Raspbian and placed it the boot partition of this Ubuntu image, but that was also a failure. As you can tell, U-boot is not my area of expertise.

It would be great if the CM3 was able to be supported out of the box, with no additional input or configuration needed by the user (such as is currently the case in Raspbian).

Thanks in advance for any efforts.

Revision history for this message
Adam Smith (adamsmith) wrote :

Hi David, can you add your voice to bug 1805668 please? I expect the beta image you are using uses the updated packages described in that bug report.

I have no experience of the compute module, but I expect changes similar to https://wiki.ubuntu.com/ARM/RaspberryPi#Booting_the_official_Pi_2_image_on_the_Pi_3B.2F3B.2B- will make the image bootable. For arm64 you need to make an additional change https://wiki.ubuntu.com/ARM/RaspberryPi#Ubuntu_arm64.2FAArch64 . Once booted I suggest you remove either the raspi3-firmware or flash-kernel package as they are both trying to do the same job.

Adam Smith (adamsmith)
affects: linux-raspi2 (Ubuntu) → flash-kernel (Ubuntu)
Revision history for this message
Oliver Grawert (ogra) wrote :

note that Ubuntu Core is fully supported on that device without any special treatment or code.

Core uses the same kernel but newer firmware and u-boot, so it is likely that either of these are too far behind in their .deb versions to fully support the CM3.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in flash-kernel (Ubuntu):
status: New → Confirmed
Changed in livecd-rootfs (Ubuntu):
status: New → Confirmed
Changed in u-boot (Ubuntu):
status: New → Confirmed
Revision history for this message
DavidT (dtischler) wrote :

Adam, thank you for these pointers! Using the advice you provided, I was able to get the Compute Module 3 to boot! I had perused the various wiki docs, but somehow overlooked those two key pieces of information you provided.

From my (previously broken) installation, I mounted the boot partition, and edited the config.txt file, adding the changes you identified in those two links.

This alone was enough to then boot up! Upon boot an login to the system, I do need to issue 'ifconfig eth0 up' and 'dhclient eth0' to actually get ethernet connectivity, and those changes do not persist across reboots, so that is not really an ideal situation, but at least its solvable.

Thus, as mentioned in my first report, the ideal scenario is that the Compute Module 3 is supported out-of-the-box, with networking functional, with no tinkering necessary (similar to Raspian). I fully understand this is free software though, and truly appreciate any efforts made here.

Revision history for this message
Adam Smith (adamsmith) wrote :

Excellent! It's probably worth opening a new bug for those network problems. That maybe is a problem with linux-raspi2. People with a 3b+ have had problems too, @ogra may know more.

Revision history for this message
Oliver Grawert (ogra) wrote :

these 3 b+ issues you refer to were with the 4.4 kernel in 16.04 (bugs in the interaction with backported patches of the NIC driver)

... the above 18.04 should use a newer kernel (4.15 ?) which should have the necessary patches included already, this looks more like the netplan configuration was not done correctly during install ... (check /etc/netplan/ for a yaml file and take a look at https://netplan.io/ for info about how to set up its contents)

Revision history for this message
Adam Smith (adamsmith) wrote :

Ethernet stopped working on the 3b+ due to an update to linux-raspi2 (bug 1797406). According to people on the Ubuntu mate forum it still wasn't working correctly after the fix.

Revision history for this message
Adam Smith (adamsmith) wrote :

With the server/cloud image you need ethernet connected on first boot. Did you do that?

Revision history for this message
Adam Smith (adamsmith) wrote :

Scrap the bit about it still not working. They probably didn't have the fix.

Revision history for this message
DavidT (dtischler) wrote :

Aha, I was unaware of the need to have ethernet connected on first boot...I did not have it connected. I only had the Computer Module sitting in the I/O board, and UART serial connected, since I was not even sure if it was going to boot.

Also, the image located in the repository I am using (http://cdimage.ubuntu.com/releases/18.04/beta/) was updated last night. I am downloading it now, will use the same instructions you have previously provided me to make it bootable, and will connect ethernet this time.

Currently downloading the new image now, so I will report back with the results.

Revision history for this message
DavidT (dtischler) wrote :

Sorry for the delayed reply to this report, but, using the newly published version of this image file, and having ethernet connected on first boot, worked perfectly! Thus, to recap:

Download 64-bit Arm Ubuntu Server 18.04 from here: http://cdimage.ubuntu.com/releases/18.04/beta/
Flash image to CM3
Mount CM3 boot partition
Apply changes noted above to config.txt
Copy in CM3 .dtb file
Unmount
Connect ethernet
Boot up!

So, if there was some methodology to detect a CM3 and apply those fixes automatically, that would be excellent.

tags: added: id-5c34d59fc5f6a37897d6d355
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

So actually the only thing we're missing for basic CM3 support is the .dtb file. Apparently the linux-raspi2 kernel for arm64 does not provide the .dtb due to misconfiguration. I have reported that to the kernel team and they have prepared a fix for the next kernel cycle (ETA in some weeks). In the meantime, for the upcoming .2 point-release, I'll work-around it temporarily by using the armhf CM3 dtb through the gadget tree configuration (as the rule is all binaries have to come from the archive, so I can't just jam in a binary that's not built in official repos). This way at least we'll have the images booting, before we can get the right dtbs from the kernel.

Changed in u-boot (Ubuntu):
status: Confirmed → Fix Released
Changed in flash-kernel (Ubuntu):
status: Confirmed → Fix Released
Changed in livecd-rootfs (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.