U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mattijs Korpershoek via U-Boot <u-boot@lists.u-boot-project.org>
To: 国豪 <guohaoprc@163.com>, "Mattijs Korpershoek" <mkorpershoek@kernel.org>
Cc: Anshul Dalal <anshuld@ti.com>,
	"Guillaume La Roque (TI.com)" <glaroque@baylibre.com>,
	u-boot@lists.denx.de, Bryan Brattlof <bb@ti.com>,
	Tom Rini <trini@konsulko.com>, Yao Zi <me@ziyao.cc>,
	Patrice Chotard <patrice.chotard@foss.st.com>,
	Vishal Mahaveer <vishalm@ti.com>, Peng Fan <peng.fan@nxp.com>
Subject: Re:Re: [PATCH] board: ti: am62x: Fix build without TI_I2C_BOARD_DETECT
Date: Tue, 21 Jul 2026 16:14:17 +0200	[thread overview]
Message-ID: <87v7a8ig5i.fsf@kernel.org> (raw)
In-Reply-To: <7b7be0c1.8185.19f841a7a0c.Coremail.guohaoprc@163.com>

On Tue, Jul 21, 2026 at 17:55, 国豪  <guohaoprc@163.com> 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" <mkorpershoek@kernel.org> wrote:
>>On Thu, Jul 16, 2026 at 13:08, Anshul Dalal <anshuld@ti.com> wrote:
>>
>>> On Wed, 15 Jul 2026 11:32:26 +0800, Guo Hao <guohaoprc@163.com> 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 <guohaoprc@163.com>
>>>
>>> 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 <anshuld@ti.com>

      parent reply	other threads:[~2026-07-21 14:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15  3:32 [PATCH] board: ti: am62x: Fix build without TI_I2C_BOARD_DETECT Guo Hao via B4 Relay
2026-07-15  5:44 ` Varadarajan Narayanan
2026-07-16  7:38 ` Anshul Dalal
2026-07-21  8:14   ` Mattijs Korpershoek via U-Boot
     [not found]     ` <7b7be0c1.8185.19f841a7a0c.Coremail.guohaoprc@163.com>
2026-07-21 14:14       ` Mattijs Korpershoek via U-Boot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v7a8ig5i.fsf@kernel.org \
    --to=u-boot@lists.u-boot-project.org \
    --cc=anshuld@ti.com \
    --cc=bb@ti.com \
    --cc=glaroque@baylibre.com \
    --cc=guohaoprc@163.com \
    --cc=me@ziyao.cc \
    --cc=mkorpershoek@kernel.org \
    --cc=patrice.chotard@foss.st.com \
    --cc=peng.fan@nxp.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=vishalm@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox