[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