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
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.
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.PhilE wrote: ↑Thu Jun 04, 2020 3:13 pmAs 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.
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.
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?