On Mon, Aug 07, 2023 at 10:18:33PM -0400, Ben Wolsieffer wrote:
On Wed, Jun 08, 2022 at 02:30:14PM -0400, Tom Rini wrote:
When migrating CONFIG_CONS_INDEX to Kconfig, on this platform we changed what "board" evaluated to in the environment. This in turn meant that we would no longer try and find the correct fdtfile via the normal distro boot logic. Fix this by overriding board in the default environment, as done on other platforms where CONFIG_SYS_BOARD is not what we want to be in the board environment variable.
Fixes: f76750d11133 ("Convert CONFIG_CONS_INDEX et al to Kconfig") Reported-by: Gabriel Hojda ghojda@yo2urs.ro Tested-by: Gabriel Hojda ghojda@yo2urs.ro Signed-off-by: Tom Rini trini@konsulko.com
include/configs/odroid_xu3.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h index eb35d7b4ae2d..360815bc03ee 100644 --- a/include/configs/odroid_xu3.h +++ b/include/configs/odroid_xu3.h @@ -86,6 +86,7 @@ "rootfstype=ext4\0" \ "console=console=ttySAC2,115200n8\0" \ "fdtfile=exynos5422-odroidxu3.dtb\0" \
- "board=odroid\0" \ "board_name=odroidxu3\0" \ "mmcbootdev=0\0" \ "mmcrootdev=0\0" \
-- 2.25.1
Hi Tom,
This patch doesn't appear to have fixed the issue. There is a report from Debian of it occuring even after this patch was applied [1], and I ran into it today as well with 2023.07.02.
I looked into it a bit, and the problem seems to be that set_board_info() constructs the fdtfile variable using CONFIG_SYS_BOARD, so setting the correct value of the board variable has no effect. I think either set_board_info() needs to construct fdtfile differently, or things need to be restructured to allow CONFIG_SYS_BOARD to be set as "odroid".
I would submit a patch, but I'm not sure of the right approach to take, and I would appreciate your help.
Thanks for the detailed report. I believe the problem is that board/samsung/common/misc.c::set_board_info() should be doing a lot more checks for if the environment variable is already set, before over-riding them. This is typically done around ethaddr (so there's a number of examples to look at) and in this case I think everything other than soc_rev / soc_id should have a check before blindly overwriting. However, just checking for board_name / fdtfile already being set before setting them is enough to fix this problem I think.