swahren
Posts: 150
Joined: Mon Sep 19, 2016 5:24 pm
Location: Germany

Re: Status of Raspberry Pi 4 in Mainline

Mon Jul 06, 2020 8:38 pm

Here are the upcoming Raspberry Pi specific features for Mainline Linux 5.8:
- proper USB support for Raspberry Pi 4 boards without separate VL805 EEPROM

User avatar
Gavinmc42
Posts: 5162
Joined: Wed Aug 28, 2013 3:31 am

Re: Status of Raspberry Pi 4 in Mainline

Tue Jul 07, 2020 2:13 am

How does that work if booting from SSD on USB3?
The VL805 driver wold need to be in the bootloader EEPROM?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

swahren
Posts: 150
Joined: Mon Sep 19, 2016 5:24 pm
Location: Germany

Re: Status of Raspberry Pi 4 in Mainline

Tue Jul 07, 2020 8:30 am

Gavinmc42 wrote:
Tue Jul 07, 2020 2:13 am
How does that work if booting from SSD on USB3?
The VL805 driver wold need to be in the bootloader EEPROM?
I don't know the details, but the VideoCore cares about the VL805 and it's firmware. The kernel only needs to notify the VC about XHCI resets, because after a reset the RAM of the VL805 is cleared and the firmware lost. This is very hacky.

User avatar
ehem
Posts: 61
Joined: Mon Sep 09, 2019 1:17 am

Re: Status of Raspberry Pi 4 in Mainline

Tue Dec 08, 2020 2:55 am

PhilE wrote:
Thu Jun 04, 2020 3:13 pm
As I understand, "upstream" are wanting to discourage people from using device names to identify partitions, preferring volume labels and UUIDs instead. That is why there is no way to force a particular mmcblk index (e.g. mmcblk0) to be used on a specific MMC interface. In the downstream rpi-* trees we include a patch that sets the index based on aliases found in the DTB. Try using a PARTUUID or PARTLABEL instead.
I was under the impression it was more the Linux distributions driving this. They like UUIDs/labels since those more reliably stay with a device even through changes. As such if hardware or drivers change, the UUIDs would remain and still survive no matter what users do.
Mostly this is a user-support issue.

For me the problem is most often filesystem UUIDs/labels are what are being pushed. These quite reliably track the filesystem, but this becomes troublesome if you're working with VMs. If the a malicious owner of a VM manages to discover the UUIDs used by the host machine, they could potentially cause what is supposed to be a VM to get loaded on bare hardware. At which point your VM machine is completely compromised.

This is a difficult attack to pull off (128 bits is a lot to guess), but not impossible.
swahren wrote:
Mon Jul 06, 2020 8:38 pm
Here are the upcoming Raspberry Pi specific features for Mainline Linux 5.8:
- proper USB support for Raspberry Pi 4 boards without separate VL805 EEPROM
Other items which showed up by 5.6 included ACPI support for most of the drivers used. Suddenly the Tianocore implementation becomes viable.
Question which arises is, how far does the boot firmware go to deal with the VL805 firmware issue? Is it reliable enough to get U-Boot operational with USB booting? Does it last long enough for U-Boot to load GRUB and GRUB to load a kernel?

Return to “Linux Kernel”