[PATCH] board: ti: cape_detect: Add overlay name lookup table for extension boards
Kory Maincent
kory.maincent at bootlin.com
Tue Apr 14 15:36:00 CEST 2026
On Tue, 14 Apr 2026 07:25:34 -0500
Andrew Davis <afd at ti.com> wrote:
> On 4/14/26 3:20 AM, Kory Maincent wrote:
> > From: "Kory Maincent (TI)" <kory.maincent at bootlin.com>
> >
> > Some extension boards have EEPROM part numbers that do not directly match
> > their devicetree overlay filenames. Introduce a static name_mapping table
> > and a set_cape_overlay() helper that translates the part number and version
> > strings read from the EEPROM into the correct overlay filename.
> >
> > When no entry matches, fall back to the existing behavior of constructing
> > the overlay name as "<part_number>-<version>.dtbo" directly from the
> > EEPROM content.
> >
> > Add an initial entry mapping BB-GREEN-HDMI revision 00A0 to
> > am335x-bone-hdmi-00a0.dtbo.
> >
> > Signed-off-by: Kory Maincent (TI) <kory.maincent at bootlin.com>
> > ---
> > board/ti/common/cape_detect.c | 42 +++++++++++++++++++++++++++++++++--
> > 1 file changed, 40 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/ti/common/cape_detect.c b/board/ti/common/cape_detect.c
> > index 88fa6ae81f0..c9555779c0c 100644
> > --- a/board/ti/common/cape_detect.c
> > +++ b/board/ti/common/cape_detect.c
> > @@ -13,6 +13,44 @@
> >
> > #include "cape_detect.h"
> >
> > +struct name_mapping {
> > + char part_number[17];
> > + char version[5];
> > + char overlay[64];
> > +};
> > +
> > +static struct name_mapping extension_mapping[] = {
> > + {
> > + "BB-GREEN-HDMI",
> > + "00A0",
> > + "am335x-bone-hdmi-00a0.dtbo",
> > + },
> > + { /* sentinel */ }
> > +};
> > +
> > +void set_cape_overlay(char *overlay, char *part_number, char *version)
> > +{
> > + struct name_mapping *mapping;
> > +
> > + for (mapping = extension_mapping; mapping->part_number[0] != 0;
> > + mapping++) {
>
> Does ARRAY_SIZE() make this any cleaner than a null-terminated array? Or
> do you plan to generalize this in some way more?
>
> Either way, the concept looks good to me.
We could indeed use ARRAY_SIZE. I have no preference.
Maybe its indeed better in terms of footprint size. I will send a v2 with it.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
More information about the U-Boot
mailing list