Use U-Boot for the Raspberry Pi 4-specific image #97883
Conversation
|
Since I'm including modified changes from @matthewbauer and keeping authorship, I'd like for him to review at least that part of the changes. |
| # We previously defined it on the kernel command line as cma= | ||
| # The kernel command line will override a platform-specific configuration from its device tree. | ||
| # https://github.com/torvalds/linux/blob/856deb866d16e29bd65952e0289066f6078af773/kernel/dma/contiguous.c#L35-L44 | ||
| CMA_SIZE_MBYTES = freeform "32"; |
There was a problem hiding this comment.
Note that the platform specific config is not always good. At least on rpi3, I had to set it to 256M to get plymouth to display properly.
There was a problem hiding this comment.
Yes, though this becomes the default, which was previously set on the command-line. The command-line still has precedence over this value.
It is actually hard to know what value should be used! It seems basically no one is in agreement.
So for the time being I only moved the value so the Raspberry Pi 4B can use whatever the device tree defines.
There was a problem hiding this comment.
Since you can reclaim cma not in use, a higher value may be a good idea. I wish rpi published defaults for it.
There was a problem hiding this comment.
Yes, multiple angles on that:
- Each board vendors should provide a device tree entry with what is needed to make them useful. Probably through an overlay. This is because some boards have issues that are specific! E.g. here the Pi4 can't use CMA higher than 1GiB!
- We can provide known useful values per-board in some manner. As it seemingly can't be universal (see previous issue)
- What even is a good universal value to use here?
Right now I really only moved the current value to a location where it has the least precedence. Let's leave changing the value to a further PR. I don't want this change set to start breaking things :) (even though I'm pretty sure it would be fine).
There was a problem hiding this comment.
Adding another note about cma. Through the device tree it's entirely possible that multiple CMA ranges are allocated, and needed for some devices. I haven't looked at it in details, but I saw that transpire in a Mobile NixOS device.
|
I spent most of my weekend testing these changes with @samueldr's help on IRC. Here is what I've found:
I am now testing whether |
|
Another noticed side-effect of this: USB ports on the Pi4 don't work at all when you boot with U-boot |
|
Raspberry Pi 4 USB works for me after also upgrading to |
|
So this just needs an update? |
|
FWIW I rebased this PR locally on current master by dropping the raspberrypifw commit (master has a newer version) and fixing the conflict in all-packages.nix. SD image built fine & boots fine, installed system has been running fine afaict. |
|
@samueldr Can you rebase this PR? |
| ubootRaspberryPi4_64bit = buildUBoot { | ||
| defconfig = "rpi_4_defconfig"; | ||
| extraMeta.platforms = ["aarch64-linux"]; | ||
| filesToInstall = ["u-boot.bin"]; | ||
| }; |
There was a problem hiding this comment.
I was looking today at similar changes b/c this never got merged to master. I found this (unified) config file for RPi 3 & 4 (arm64 == aarch64): https://github.com/u-boot/u-boot/blob/0817daa7606ec55ba551acb0208eaba33a548804/configs/rpi_arm64_defconfig. Would it be worth merging these two configurations to reduce code overhead? I know that'll make this PR take slightly longer b/c more to review, so that might be a second step.
There's also an updated UBoot for Raspberry Pi 3B+: https://github.com/u-boot/u-boot/blob/0817daa7606ec55ba551acb0208eaba33a548804/configs/rpi_3_b_plus_defconfig. Complete speculation, but might fix some of the issues tracked in #66960
There was a problem hiding this comment.
It should be easy for anyone to use these configs already with a custom buildUBoot. If it turns out there is a big difference, we can still switch to them or provide additional builds.
ghost
force-pushed
the
feature/raspberrypi4-with-u-boot
branch
2 times, most recently
from
b194225
to
cb998a2
Compare
|
Rebased (which made the linux-rpi update obsolete), updated armstubs to 2020-10-08 |
This includes setting up everything for the mainline Raspberry Pi 4 image. In fact, the only difference left in the Raspberry Pi 4-specific image is the kernel from the vendor.
As per the in-line comment, this is where distros should configure it. Not via kernel command line parameters. As found by looking at the implementation, while exploring the cause of a bug on the Raspberry Pi 4, it was found that `cma=` on the command line parameters will overwrite the values a device tree will have configured for a given platform. With this, the more recent 5.4 vendor kernel boots just fine on the Raspberry Pi 4 using our common configuration.
ghost
force-pushed
the
feature/raspberrypi4-with-u-boot
branch
from
cb998a2
to
c673c5e
Compare
|
nixos.sd_image_raspberrypi4.aarch64-linux does not boot on my rpi4 8g: Edit: fixed by including these lines to config: {
boot.kernelParams = [
# hangs on "Starting kernel ..." without this
"coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=0 bcm2708_fb.fbheight=0 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:BB:43:C3 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x4000000"
];
nixpkgs.overlays = [
(self: super:
{
# downgrade u-boot to fix "Synchronous Abort"
ubootRaspberryPi4_64bit = super.buildUBoot rec {
defconfig = "rpi_4_defconfig";
extraMeta.platforms = [ "aarch64-linux" ];
filesToInstall = [ "u-boot.bin" ];
version = "2020.07";
src = super.fetchurl {
url = "ftp://ftp.denx.de/pub/u-boot/u-boot-${version}.tar.bz2";
sha256 = "0sjzy262x93aaqd6z24ziaq19xjjjk5f577ivf768vmvwsgbzxf1";
};
};
})
];
} |
|
@misuzu have you tried upgrading u-boot too? I haven't looked at all, but maybe the regression was fixed for the next stable version? If it wasn't, we'd need to investigate, first confirming whether it's 8GB specific or not. As an additional thing to try (but not a fix), have you tried editing |
|
Disregard trying with I suspect something other than the memory amount. Though, a new thought (I shared with @makefu on IRC) is that it could be related to the firmware installed to the eeprom. I don't know which version I have, but I did confirm that it boots on my setup. I know that an arbitrary date in the past I updated the eeprom, so I only know that it's not the one it shipped with, and not the latest. |
|
|
Oh, so is it the kernel command-line that fixes the issue, and not changing the u-boot version? (I really don't know what is going on here. And I cannot reproduce and test due to some difference in setups.) |
It's both. |
|
Given that 2021.01-rc5 works with the cmdline, and they're most probably releasing next week, we'll sit on that until next week, where we'll be able to update u-boot and fix part of the issue. Do you know which command-line parameter is required? Or is it a combination of some? All? Sorry again for the harsh interrogation. I'd like to say it didn't work on mine either. |
|
Testing a bit more, with the same build, headless, actually headless, HDMI ports both unpopulated, I can say that Looks like this is approx. equivalent to using uart1-overlay. Added it to the raspberry pi 4 nixos on arm wiki page. So I figure that the "no serial console" issue is solved via the command-line parameter, but we still have that odd U-Boot failing to boot. (Until the next stable release, soon enough.) |
|
I'm so sorry I can't be more helpful here. I only have the 8GB version and I don't have an HDMI cable or equipment to use the serial port. I tested this in a headless setup so I couldn't see many of the issues you are having. |
|
@petabyteboy It seems the issue here happens, too, in a headless situation. And don't worry, I can't reproduce it either, though I'm sure something makes the error happen. And thanks for your input, it's useful to know it's not necessarily an 8GB version issue. Now it'd be nicer if we could figure out what is the issue. It seems that the revision of the board itself doesn't matter, as [@makefu / I] have a 4GB 1.1 board, it works for me, fails for him; both of you [@petabyteboy / @misuzu] have an 8GB board (1.4 obligatory) and works for one of you, fails for the other. I have personally tested:
Both situation didn't produce a "Synchronuous abort". The image booted fine. Though I can confirm that in Linux, something needs to be done for UART to work, one solution is |
Adding only |
|
@misuzu what do you mean network doesn't work? To no avail. |
There are no DHCP requests over ethernet from my rpi4 when started without |
This is part of the effort to slowly move the Raspberry Pi 4 support to the mainline-based generic AArch64 image.
With this change, the image is now structurally compatible with the mainline AArch64 image. This means that when mainline Linux has been verified to work on the Raspberry Pi 4 enough for the end-user to gain a foothold into ARM-land, we can finally remove the Raspberry Pi 4-specific SD image.
The idea being that if mainline is not working well enough for specific use cases, or incompatible with the Raspberry Pi Foundation's ecosystem of hardware, drivers and software, the user now has the ability to either switch the running kernel and rebuild, or even now build AArch64 packages. The Raspberry Pi 4 might be that user's first and only way to build AArch64 things!
With this change, we should be able to somewhat reduce the difficulties in supporting, and answering questions about the Raspberry Pi 4. It should work, structurally speaking, just like the Raspberry Pi 3 images.
One last change, for the rpi-5.4.y kernel branch, we need to drop the
cma=parameter from the kernel command line. The kernel command line takes precedence from the pre-configured CMA set in the FDT; which in turn allocates in an area that VC cannot read. The pre-configured CMA value works just fine. Using the configuration option (1) clears up the kernel command-line a bit, and (2) fixes that issue since it has lower precedence.This includes changes from:
This changes nothing for existing Raspberry Pi 4B users. Only images made from the moment this change lands are going to be different.
Should this get backported? Well, the main part of this PR, changing to U-Boot for the Raspberry Pi 4 image, does not apply as there is no Raspberry Pi 4 image on stable. The kernel update might be relevant, but might bring breaking changes.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)cc #63720