Hervé, On Thu, 13 Feb 2025 at 17:07, Herve Codina <herve.codina@xxxxxxxxxxx> wrote: > > On Thu, 13 Feb 2025 16:30:44 +0000 > Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > > > Hi Andrew, > > > > On Thu, 13 Feb 2025 at 16:27, Andrew Lunn <andrew@xxxxxxx> wrote: > > > > > > On Thu, Feb 13, 2025 at 05:14:35PM +0100, Herve Codina wrote: > > > > Hi Phil, > > > > > > > > On Thu, 13 Feb 2025 15:18:45 +0000 > > > > Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > Hi Andrea, > > > > > > > > > > The problem with this approach (loading an overlay from the RP1 PCIe > > > > > driver), and it's one that I have raised with you offline, is that > > > > > (unless anyone can prove otherwise) it becomes impossible to create a > > > > > Pi 5 DTS file which makes use of the RP1's resources. How do you > > > > > declare something as simple as a button wired to an RP1 GPIO, or fan > > > > > connected to a PWM output? > > > > > > Where is this button or fan? On a pluggable board? Isn't that what > > > overlays are for, and they are stackable. So when you probe the > > > pluggable board via its eeprom etc, you find the overlay and load it? > > > > In the Raspberry Pi ecosystem it would be the firmware that applies > > the overlay, and it can't do that if the resources the overlay refers > > to are not yet present in the dtb. > > What do you mean by the 'the resources are not yet present in the dtb' ? Consider the fan connector on the Pi 5 PCB. It is wired to GPIO 45 on RP1. In our current Pi 5 dtb there is an instance of pwm-fan whose "pwms" property links to rp1_pwm node, which declares a PWM block on RP1. Similarly, the camera and display ports make use of I2C interfaces on RP1. The camera and display overlays, applied by the firmware, have references to those interfaces. If RP1 is not present in the dtb then neither of those scenarios - board features and overlays applied the firmware - will work because the necessary nodes and symbols are not present until the kernel has started running, at which point dtb has been handed over. > Also what you call the 'firmware' is the bootloader ? the kernel ? > Can you tell me who is the 'firmware' what is the mecanisme it uses to > load the overlay. In the case of the Pi 5, the firmware is an EEPROM image containing code run by the VPU embedded processor. It can load overlays using the same mechanisms it uses to load the kernel - SD/EMMC, NVME, USB, TFTP, etc. The same problem would exist for U-boot. Even though RP1 has a standard XHCI controller, U-boot wouldn't be able to detect it and make use of it, say to load a kernel from a USB stick, because it isn't declared in the DTB. Phil
