RFC Run-time configuration of U-Boot via a flat device tree (fdt)
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [RFC PATCH 0/4] Run-time configuration of U-Boot via a flat device tree (fdt)
Hi Simon,
Quoted 5 lines · Simon Glass
At present in U-Boot configuration is mostly done using CONFIG options in the board file. This patch set aims to make it possible for a single U-Boot binary to support multiple boards, with the exact configuration of each board controlled by a flat device tree (fdt). This is the approach recently taken by the ARM Linux kernel and has been used by PowerPC for some time.
Very exciting. I've thought about doing this for years, but never had the ambition (or time).
[snip]
Quoted 9 lines
and add some defines to your board (only ARM is currently supported):
#define
CONFIG_OF_CONTROL(to enable run-time config control via fdt)
#defineCONFIG_OF_EMBEDorCONFIG_OF_SEPARATE
(either build the fdt blob into U-Boot, or create a separate u-boot.dtb)
#defineCONFIG_DEFAULT_DEVICE_TREE"<your name>"
(to specify the name of the device tree file is
board/<vendor>/<board>/<your name>.dts)
Quoted 4 lines
This patch set does not include any drivers which actually use the fdt. I have some concerns about spreading fdt code around the U-Boot code base so am thinking of having a support file which makes this easier. I can provide a UART driver modified to use fdt if there is interest.
Please. A concrete reference is very useful, especially for discussion.
Quoted 7 lines
It is important to understand that the fdt only selects options available in the platform / drivers. It cannot add new drivers (yet). So you must still have the CONFIG option to enable the driver. For example, you need to define
CONFIG_SYS_NS16550to bring in the NS16550 driver, but can use the fdt to specific the UART clock, peripheral address, etc. In very broad terms, the CONFIG options in general control *what* driver files are pulled in, and the fdt controls *how* those files work.
Sounds reasonable and practical. One of the things u-boot struggles with is staying small (but it is nice to be able to make it all inclusive and big if you have the flash).
Quoted 2 lines
While only ARM is supported in this patch series, it should be easy enough to add support for other architectures.
Exercise left for the students. :-)
[snip]
Thanks!
gvb