[PATCH v4 00/10] Add support for extension boards detection and DT overlays application

Tom Rini trini at konsulko.com
Tue May 4 13:57:50 CEST 2021


On Tue, Apr 20, 2021 at 10:25:31AM +0200, Kory Maincent wrote:

> This series of patches aims at proposing a generic U-Boot mechanism to
> detect extension boards connected to the HW platform, and apply the
> appropriate Device Tree overlays depending on the detected extension
> boards.
> 
> Indeed, numerous popular platforms, such as the BeagleBone or the
> RaspberryPi, feature some kind of extension board mechanism. These
> extension boards are often discoverable through some kind of EEPROM
> (connected on I2C, 1-wire, etc.) and require Device Tree overlays to be
> applied at the U-Boot level to provide a complete HW description to the
> Linux kernel. However, currently this logic is usually implemented
> ad-hoc in downstream forks of U-Boot.
> 
> This series proposes to bring a HW-agnostic and generic solution to
> this problem to upstream U-Boot. The series shows that it is generic
> enough by implementing its usage for 2 different families of HW
> platforms and expansion boards:
> 
>  - The BeagleBone Black and BeagleBone AI, that use extension boards
>    where the EEPROM describing the extension boards is connected over
>    I2C.
> 
>  - The CHIP, that uses extension boards where the EEPROM describing the
>    extension boards is connected over 1-wire.
> 
> The patch series implements a new command called "extension", with two
> sub-commands:
> 
>  - "extension scan" to detect available extension boards
> 
>  - "extension list" will simply list the detected extension boards
> 
>  - "extension apply" will allow to apply the Device Tree overlays
>    corresponding to one extension board or to all expansion boards
> 
> Note that the name "extension" has been chosen to not refer to any
> particular board-specific terminology for extension boards ("cape" for
> BeagleBone, "DIP" for CHIP, "hat" for RaspberryPi, etc.). However, we
> welcome suggestions of other names and are definitely willing to use a
> different naming.
> 
> The "extension apply" command requires two environment variables to be
> defined so that it knows how to apply DT overlays. This is described
> in more details in PATCH 1.
> 
> This generic code requires board-specific code for the detection and
> enumeration of extension boards. This is simply implemented in the form
> of a board-specific extension_board_scan() function, which fills in a
> list of detected extension boards.
> 
> In detail:
> 
>  - PATCH 1 move fdt_valid function to fdt_support file
>  - PATCH 2 implements the generic command and logic
>  - PATCH 3 implements the python test for the "extension" command
>  - PATCH 4 implements the board-specific code for the BeagleBone platforms
>  - PATCH 5 enables the mechanism for the BeagleBone AI
>  - PATCH 6 review the detection mechanism of one-wire devices
>  - PATCH 7 and 8 enable the mechanism for the CHIP
>  - PATCH 9 and 10 enable the mechanism for the BeagleBone Black
> 
> Thanks in advance for your review and feedback

Can you please rebase this on current master?  Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210504/7602d018/attachment.sig>


More information about the U-Boot mailing list