Page 2 of 2

Re: Status of Raspberry Pi 4 in Mainline

Posted: Mon Jul 06, 2020 8:38 pm
by swahren
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

Re: Status of Raspberry Pi 4 in Mainline

Posted: Tue Jul 07, 2020 2:13 am
by Gavinmc42
How does that work if booting from SSD on USB3?
The VL805 driver wold need to be in the bootloader EEPROM?

Re: Status of Raspberry Pi 4 in Mainline

Posted: Tue Jul 07, 2020 8:30 am
by swahren
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.

Re: Status of Raspberry Pi 4 in Mainline

Posted: Tue Dec 08, 2020 2:55 am
by ehem
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?