On Wed, 9 Oct 2019 at 02:00, Markus Birth <[email protected]> wrote:
>
> So what does u-boot do differently than the internal bootloader? Or what
> could be the issue in my setup? I'd like to keep going without u-boot if
> possible.
Let's clear up this misunderstanding first: u-boot doesn't supplant
the pi's usual bootloader. It's just an extra step in the chain
between the pi's bootloader and the kernel. So the overall boot
process on ubuntu goes like this:
1) bootcode.bin (or on the pi4, the boot flash EEPROM) which loads...
2) start*.elf (usually start.elf but can be changed if, e.g. camera is
enabled in which case it's start_x.elf) which loads...
3) uboot*.bin (historically there was just one u-boot, once Eoan
releases there'll be one per pi, e.g. uboot_rpi_2.bin,
uboot_rpi_3.bin, etc.) which loads...
4) vmlinuz the kernel
You may (very reasonably) ask "why bother with u-boot at all?". The
answer is partly "because Core needs it for A/B booting" (A/B booting
requires a bootloader that can re-write state to track whether an
attempted kernel booted or not), and partly because we wish the Core
and Classic boot procedures to become much closer for the sake of
easier maintenance which in turn means Classic will retain u-boot for
the foreseeable future.
> I'm booting my Pis without u-boot with this in my config.txt:
>
> [pi4]
> enable_gic=1
> armstub=armstub8-gic.bin
> total_mem=1024
>
> [all]
> kernel=vmlinuz
> initramfs initrd.img followkernel
> arm_64bit=1
> gpu_mem=32
> dtparam=eee=off
>
> This exact setup works fine on my Pi 3B+ (and also my Pi 2B has this
> non-u-boot-setup - they both boot fine this way.) The Pi 4 only even
> tries to boot with that total_mem=1024 line in the config.txt. Without
> that line (i.e. with the full 4GB RAM) it stays at the rainbow screen.
> But this isn't the big issue.
>
> When booting, it's failing to detect the SD card and thus the root
> filesystem. This is with today's updates and your PPA included.
>
> cmdline.txt is:
>
> root=/dev/mmcblk0p2 rootfstype=ext4 rootflags=noload rootwait
> verbose nosplash net.ifnames=0 dwc_otg.lpm_enable=0
> dwc_otg.fiq_fix_enable=1 fsck.repair=yes modprobe.blacklist=sdhci_iproc
Which release of Ubuntu are we talking about here? The Pi4 will have
preliminary support with the Eoan release (and the current Eoan
dailies have a Pi4 compatible kernel, though I'm not sure if the new
Pi4-compatible u-boot has made it into them yet), but prior releases
do not (yet) have a Pi4 compatible kernel (there are plans to enable
Pi4 on Bionic, but not until after the Eoan release).
I can't say we'll support u-boot-less booting of classic, but I did
test your boot config on the arm64 Eoan daily available from:
http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/
I managed to get it working with a couple of minor tweaks: you need
the vc4-fkms-v3d overlay loaded to get the screen working without
corruption. Secondly, I dropped the armstub line as we don't have an
armstub (and I'm fairly sure it's not required at this point; I
vaguely recall it was required for 64-bit boots at some point in the
past but the firmware was updated to make it unnecessary). Anyway, the
following config worked happily for me:
[pi4]
enable_gic=1
total_mem=1024
[all]
kernel=vmlinuz
initramfs initrd.img followkernel
dtoverlay=vc4-fkms-v3d
arm_64bit=1
gpu_mem=32
dtparam=eee=off
cmdline=cmdline.txt
With the following in cmdline.txt:
net.ifnames=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200
console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline
rootwait
(which is just the standard command line we'll be shipping Eoan with)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847163
Title:
[FFe] Firmware bump for Pi 4 boot support
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/1847163/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
