Skip to content

board: adi: sc846: fix carrier-board config and boot SPI bus - #146

Open
ozan956 wants to merge 6 commits into
adi-u-boot-2025.10.yfrom
common-sc846-som
Open

board: adi: sc846: fix carrier-board config and boot SPI bus#146
ozan956 wants to merge 6 commits into
adi-u-boot-2025.10.yfrom
common-sc846-som

Conversation

@ozan956

@ozan956 ozan956 commented Aug 5, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

sc846-som and sc846-som-ezkit each carried their own board_init(),
differing only by the carrier-board ethernet init and RGMII enable
call. Move the shared logic into common-sc846-som/sc846-som.c, gated
on CONFIG_ADI_CARRIER_SOMCRR2_EZKIT, matching the pattern already used
by common-sc594-som and common-sc598-som.

While doing so, found ADI_CARRIER_SOMCRR2_EZKIT was forced on for any
SC846 target, not just the ezkit carrier board, so the shared
board_init would call into ethernet gpio-hog lookups missing on the
bare SOM's dts. Scoped the choice to TARGET_SC846_SOM_EZKIT.

Also drops an unused symbol (GIC_600_CLEAR_RDPD) found along the way,
and fixes sc846-som_defconfig missing CONFIG_SC_BOOT_SPI_BUS, which
left it defaulting to bus 2 instead of the SPI1 bus the boot flash is
actually wired to (confirmed against schematic).

@ozan956
board: adi: sc846: share board_init
214ca04 
sc846-som and sc846-som-ezkit each carried their own board_init(),
differing only by the carrier-board ethernet init and RGMII enable
call. Move the shared logic into common-sc846-som/sc846-som.c, gated
on CONFIG_ADI_CARRIER_SOMCRR2_EZKIT, matching the pattern already used
by common-sc594-som and common-sc598-som.

Signed-off-by: Ozan Durgut <ozan.durgut@analog.com>
@ozan956
ozan956 requested a review from a team August 5, 2026 15:13
@ozan956 ozan956 self-assigned this Aug 5, 2026
@ozan956 ozan956 added the sc846 Support for the ADSP-SC846 label Aug 5, 2026
@ozan956 ozan956 added this to ADSP Aug 5, 2026
@ozan956 ozan956 added the llm review Request a review from a LLM Reviewer label Aug 5, 2026
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown

LLM review

This series unifies the ADSP-SC846 board_init() between sc846-som and sc846-som-ezkit into a shared file, matching the existing common-sc594-som/common-sc598-som pattern.

run: 31019236773

214ca04a - board: adi: sc846: share board_init

NULL-deref bug on the bare SOM: board/adi/common-sc846-som/sc846-som.c gates adi_somcrr_init_ethernet() on CONFIG_ADI_CARRIER_SOMCRR2_EZKIT. That Kconfig symbol comes from a choice in arch/arm/mach-sc5xx/Kconfig with a single entry and default ADI_CARRIER_SOMCRR2_EZKIT, so it is unconditionally =y for both TARGET_SC846_SOM (bare SOM, no carrier) and TARGET_SC846_SOM_EZKIT - confirmed by generating .config for both defconfigs. Previously the bare SOM's board_init() was a no-op and never reached this code; now it does, and calls into adi_somcrr_enable_ethernet() (board/adi/carriers/somcrr2_ezkit.c), which does gpio_hog_lookup_name("eth0-reset", &desc). arch/arm/dts/sc846-som.dts has no eth0-reset gpio-hog (it's only added by sc846-som-ezkit.dts), so gpio_hog_lookup_name() returns desc = NULL (return code ignored by the caller), and the following dm_gpio_set_value(desc, ...) dereferences it via dm_gpio_is_valid() (return desc->dev != NULL;, no NULL guard). Net result: the plain sc846-som_defconfig build crashes in board_init().

The Kconfig choice and the GPIO code predate this commit (already merged, out of the reviewed range), but this commit is what makes that latent issue reachable on the bare SOM. Suggested fix: gate on CONFIG_TARGET_SC846_SOM_EZKIT instead, which correctly differentiates the two boards and only touches the file this commit introduces. Verified the fix builds cleanly for both sc846-som and sc846-som-ezkit defconfigs.

CI warnings

checkpatch.pl --strict -g on this commit reports only the boilerplate "does MAINTAINERS need updating?" warning for the file rename; board/adi/sc846-som* isn't referenced in MAINTAINERS, so this is a false positive and needs no action.

Verification data

No ADSP-SC846 datasheet/HRM is published on the ADI doctools sitemap (only ADSP-SC83x manuals were found), so the sc5xx_enable_rgmii() pad-mux write for SC846 could not be checked against a register map; it mirrors the existing sc594/sc598 pattern so it is not flagged. The Kconfig/.config claims and the NULL-dereference path were verified directly from source (arch/arm/mach-sc5xx/Kconfig, drivers/gpio/gpio-uclass.c, include/asm-generic/gpio.h, arch/arm/dts/sc846-som*.dts) and by building both sc846-som_defconfig and sc846-som-ezkit_defconfig end-to-end with gcc-aarch64-linux-gnu (installed for this review), confirming u-boot links successfully in both cases and inspecting the resulting .config.

Suggested patches

Apply the suggested patches with:

cd path/to/repository
export GITHUB_TOKEN=ghp_***
apply-patches --repo=analogdevicesinc/u-boot 31019236773
Install instructions

The following one-liner installs the script if not present already:

curl -fSsL "https://raw.githubusercontent.com/analogdevicesinc/doctools/refs/heads/main/ci/scripts/apply-patches.sh"      -o ~/.local/bin/apply-patches.sh &&   grep -q "/apply-patches.sh" ~/.bashrc || echo "source ~/.local/bin/apply-patches.sh" >> $_ ; . $_

More information at AI Usage.

@ozan956
ozan956 requested a review from a team August 5, 2026 15:35
@ozan956

ozan956 commented Aug 5, 2026

Copy link
Copy Markdown
Member Author

The Kconfig choice and the GPIO code predate this commit (already merged, out of the reviewed range), but this commit is what makes that latent issue reachable on the bare SOM. Suggested fix: gate on CONFIG_TARGET_SC846_SOM_EZKIT instead, which correctly differentiates the two boards and only touches the file this commit introduces. Verified the fix builds cleanly for both sc846-som and sc846-som-ezkit defconfigs.

Liked the how it found the error, but did not like the suggested solution. I dig in why the carrier symbol is defined even for just SoM. Then I saw that its kinda forced. Fixed that by making that choice based on TARGET_SC846_SOM_EZKIT.

@ozan956
arch: sc5xx: fix wrongly forced symbol
9caa2f8 
The "Analog Devices SC84x SOM Carrier Board Variant" choice depended
on SC846 (the whole SoC family) with default ADI_CARRIER_SOMCRR2_EZKIT,
so the symbol was always true regardless of which SC846 target was
selected.

board_init gates adi_somcrr_init_ethernet on this symbol. On the bare
SOM it now called into adi_somcrr_enable_ethernet, which looks up the
"eth0-reset" gpio-hog. That hog only exists in sc846-som-ezkit.dts,
not sc846-som.dts, so gpio_hog_lookup_name returns NULL.

Scope the choice to TARGET_SC846_SOM_EZKIT so ADI_CARRIER_SOMCRR2_EZKIT
is only set for the carrier-board target, matching the SC59x pattern
where carrier selection is tied to the specific board target rather
than the SoC family.

Signed-off-by: Ozan Durgut <ozan.durgut@analog.com>
@ozan956
arch: sc5xx: remove dead symbol
7866610 
GIC_600_CLEAR_RDPD not mentioned anywhere else.

Signed-off-by: Ozan Durgut <ozan.durgut@analog.com>
@ozan956
configs: adi: sc846-som: set SPI bus to match hardware
dea2d72 
IS25WP02GG is wired to SPI1 per schematic and the board dts,
matching SF_DEFAULT_BUS=1 already set. Without an explicit
CONFIG_SC_BOOT_SPI_BUS, the SOM defconfig fell back to the
Kconfig default of 2, mismatching the ezkit defconfig and
the actual wiring.

Signed-off-by: Ozan Durgut <ozan.durgut@analog.com>
@ozan956

ozan956 commented Aug 5, 2026

Copy link
Copy Markdown
Member Author

I believe the SoM config was not working, since I saw that when compiled, the ezkit gets CONFIG_SC_BOOT_SPI_BUS=1, but just SoM does not define it so gets 2.

One of them must not working. I checked the schematics, I think the SoM config was not working -> https://www.analog.com/media/en/technical-documentation/eval-board-schematic/ev-sc846-som-schem.pdf

image

If someone has bare SoM setup, worth confirming this was actually failing to boot before the fix.

@ozan956 ozan956 changed the title board: adi: sc846: share board_init board: adi: sc846: fix carrier-board config and boot SPI bus Aug 5, 2026
@CalebEthridgeADI

CalebEthridgeADI commented Aug 5, 2026 •
edited
Loading

Copy link
Copy Markdown

I believe the SoM config was not working, since I saw that when compiled, the ezkit gets CONFIG_SC_BOOT_SPI_BUS=1, but just SoM does not define it so gets 2.

You are correct, the SOM is the broken one, we fixed the EZKIT defconfig a while back. Do we have a setup with just the sc846 SOM we could run tests on in the future? Would be nice to have to catch things like this if we are going to support the sc846 with and without a carrier.

@ozan956

ozan956 commented Aug 5, 2026

Copy link
Copy Markdown
Member Author

I believe the SoM config was not working, since I saw that when compiled, the ezkit gets CONFIG_SC_BOOT_SPI_BUS=1, but just SoM does not define it so gets 2.

You are correct, the SOM is the broken one, we fixed the EZKIT defconfig a while back. Do we have a setup with just the sc846 SOM we could run tests on in the future? Would be nice to have to catch things like this if we are going to support the sc846 with and without a carrier.

Our all SC846s has the carrier and intensively used 😅 Maybe @artursartamonovsadi have one 🤔

@CalebEthridgeADI

CalebEthridgeADI commented Aug 5, 2026

Copy link
Copy Markdown

Our all SC846s has the carrier and intensively used 😅 Maybe @artursartamonovsadi have one 🤔

I think everyone's SC846 will be tied up for this bring-up. Maybe something worth revisiting in the future once the sc846 initial support rush has calmed down.

@pamolloy

pamolloy commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

We don't support a SoM only config for the SC59x boards and now isn't the time to do it for SC846, without supporting it for SC59x. Drop the SoM only config and board configuration

@ozan956
board: adi: sc846: drop bare-SOM-only config
3221887 
TARGET_SC846_SOM offered a no-carrier SC846 configuration, but the
SC59x boards never supported that mode and now isn't the time to add
it for SC846 either without also adding it there. Drop
TARGET_SC846_SOM, its board dir, and sc846-som_defconfig, leaving
sc846-som-ezkit as the only SC846 target. This matches the SC594/SC598
pattern where board selection is always tied to a specific carrier.

board_init() no longer needs to branch on the carrier symbol since
SOMCRR2-EZKIT is now unconditionally selected by the sole remaining
target.

Signed-off-by: Ozan Durgut <ozan.durgut@analog.com>
@ozan956

ozan956 commented Aug 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

We don't support a SoM only config for the SC59x boards and now isn't the time to do it for SC846, without supporting it for SC59x. Drop the SoM only config and board configuration

Makes sense. Removed everything related with bare SoM.

@ozan956
board: adi: carriers: check gpio_hog_lookup_name
9c538ea 
adi_somcrr_enable_ethernet/disable_ethernet ignored the lookup result
and dereferenced eth0_reset unconditionally. somcrr_ezkit.c and
somcrr_ezlite.c already guard this call; somcrr2_ezkit.c did not.

Match the sibling carriers and skip dm_gpio_set_value on lookup
failure.

Signed-off-by: Ozan Durgut <ozan.durgut@analog.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@ozan956 ozan956

Labels

llm review Request a review from a LLM Reviewer sc846 Support for the ADSP-SC846

Projects

ADSP
Status: No status

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@ozan956 @CalebEthridgeADI @pamolloy