On Tue, Jul 21, 2026 at 17:55, 国豪 <[email protected]> wrote: > Hi, > > > Thanks for the question. > > > My use case is a third-party board based on the AM6254 SoC, rather than a TI > EVM. The board reuses the common AM62x EVM boot flow, but it does not have a > TI > AM6-compatible board EEPROM. Its board identity and device tree selection are > fixed by the board configuration.
I see, thanks for the explanation. I think that this should be mentioned in the commit message. > > > I verified this behavior on the board. With TI_I2C_BOARD_DETECT enabled, > U-Boot > probes I2C addresses 0x50 and 0x51, and both probes fail. The AM62x late-init > code then sets: > > > board_name=am62x_skevm > board_rev=unknown > board_software_revision=unknown > board_serial=unknown > serial#=0000000000000000 > > > This information is incorrect for the third-party board. Its configuration > therefore uses: > > > CONFIG_BOARD_LATE_INIT=y > # CONFIG_TI_I2C_BOARD_DETECT is not set > > > This keeps the board late-init hook, including the fdtfile setup, while > disabling the TI EVM EEPROM detection. > > > The submitted patch fixes the build error for this valid configuration. I am > also fine with the suggested no-op stubs, provided they preserve the behavior > of not applying EVM fallback information or setting a serial number when board > detection is disabled. I have a slight preference for adding setup_board_eeprom_env() and setup_serial_am6() as no-op stubs. But I'm not the TI board maintainer so I let them decide. > > > I limited this patch to AM62x, which is the platform I tested. I agree that > the > same pattern should be addressed for the other affected platforms as well. > > > Best regards, > Guo Hao > > > > At 2026-07-21 16:14:08, "Mattijs Korpershoek" <[email protected]> wrote: >>On Thu, Jul 16, 2026 at 13:08, Anshul Dalal <[email protected]> wrote: >> >>> On Wed, 15 Jul 2026 11:32:26 +0800, Guo Hao <[email protected]> wrote: >>>> setup_board_eeprom_env() and setup_serial_am6() are only available when >>>> TI_I2C_BOARD_DETECT is enabled. >>>> >>>> IS_ENABLED() does not remove the guarded statements during preprocessing, >>>> so disabling TI_I2C_BOARD_DETECT results in an implicit function >>>> declaration error. Use a preprocessor condition to match the condition >>>> used for the function definition. >>>> >>>> Fixes: ff1b83c095c2 ("board: am62x: Add support for reading eeprom data") >>>> Signed-off-by: Guo Hao <[email protected]> >>> >>> This is a valid fix however I wonder if there's an actual use-case where >>> someone >>> might want to disable TI_I2C_BOARD_DETECT on an EVM board. >> >>I agree with Anshul here. What's the use use-case for disabling i2c >>board detection? >> >>Also, if we really want it disabled, we could also create stub functions >>instead of replacing this. >> >>> >>> Also, it looks like the same issue exists for other platforms too (AM64x, >>> AM65x, >>> J721s2 ...). >>> >>> -- >>> Anshul Dalal <[email protected]>
