[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR

From: Pavel Shlyak
Subject: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
Date: Tue, 23 Aug 2022 00:29:11 +0300

> That web page does not claim that anywhere.

Here's a rough list of the DT changes performed by the firmware, besides merging the obvious dtoverlays and dtparams:
* Applying the "upstream" overlay, if "upstream_kernel=1".
* Changing the CPU ID declarations on a Pi 2+ (BCM2837 vs BCM2836).
* Adding i2c_vc and i2c_arm labels and aliases (and their relatives).
* If the board has a POWER_LOW GPIO declared in dt-blob.bin, using that to configure the pwr_led node.
* Adding the Bluetooth flow control pins to the "uart0_pins" node, on boards that support it.
* Setting numerous items to /chosen - bootargs (the command line), rpi-boardrev-ext, rpi-country-code (Pi 400), details of the bootloader version, boot-mode, linux,initrd-start and linux,initrd-end.
* Adding a copy of the bootloader configuration.
* Loading the vl805 overlay on CM4s which have "VL805=1" in their bootloader configuration.
* Automatically loading overlays for supported cameras that are detected.
* Automatically loading overlays for the PoE HATs, switching between firmware-driven and I2C-driven as needed.
* Expanding the dma-ranges property of the emmc2bus node on BCM2711C0.
* Disabling the old OTG USB controller and enabling the XHCI controller if "otg_mode=1".
* Loading the appropriate rpi- display overlay.
* Setting the aliases "serial0" and "serial1" to point to the console/user UART and the Bluetooth/spare UART, respectively.
* Adding information about the HAT in "/hat".
* Copying any significant error messages to "/chosen/user-warning", from where it can be read by the GUI and turned into notifications.
* Declaring the available RAM.
* Passing the board revision, serial number, kaslr seed and rng seed.
* Limiting the size of the CMA region to 256MB if < 2GB RAM or gpu_mem > 256.
* Expanding the inbound window declared by the pcie0 dma-ranges property on a C0, moving the base address to 0x4_00000000 regardless.
* Setting the MDIO address of the Ethernet PHY.
* Declaring a simple-framebuffer, if wanted.

> What does m1n1 have to do with anything here? m1n1 isn't extlinux and isn't packaged in Guix.

It chainloads uboot

> Going by the mention of 'defconfig' and 'arch/arm' and 'configs', this appears to be a patch to Linux, not uboot. As such, it appears that the device tree information is used by Linux here, there is no information there on whether it is used by U-Boot.

I cannot agree.

And is this a bad thing, and if so, perhaps FDTDIR could be added to the specification?

I don’t think so. Keep in mind the source code in Guix is named extlinux.scm and the file is named extlinux.conf and extlinux doesn’t support FDTDIR

If so, figuring out the appropriate options to let U-boot pass the device tree to Linux seems reasonable to me.

Of course it passes device tree. The problem in question is the source of that device tree: in my case, it should not be loaded from a file.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]