Port to different hub

[hlyi]

@jnilo1 Thanks for your great work! I found that a smart hub that also uses RTL8196E. Could you please help me to port your work to the hub? Besides RTL8196E, it also has 16MiB NOR-flash ( 25Q127). It has the following differences:

1. it uses 64MiB DDR2 SDRAM (winbond W9751G6KB) ( how to modify bootloader to increase DDR size and using DDR2?)

2. It has EFR32MG13P732HI soldered on the main PCB board instead of using TYZS4 module. It doesn't support hw flow control, needs rebuild silab firmware to enable XON/XOFF support and otbr-agent need to rebuild to support SW flow control ( is it possible?)

3. the ethernet PHY is connected to port 0 instead of port 4 of RTL8196E ( which files to modify?)

4. LED pins/Reset button may mapped to different GPIOs.

Thanks a lot in advance!

[jnilo1]

Hi @hlyi — great find, that board is almost a twin of the Lidl/Silvercrest unit, so a port is very realistic. 🙂

Caveat first (the fun one): I don't own your hardware, so everything below is "works on paper / works on my board" guidance. If you brick your device, that's on you, not me — please make a full flash backup before you touch anything, and ideally keep a SWD/serial path open so you can always recover. With that said, I'm very happy to help you bring it up — you test on the metal, I'll point at the exact files to change.

0. Before anything — back up and keep a recovery path

• Dump the full 16 MiB SPI NOR first (backup_gateway.sh / serial FLW read). Same flash part (GD25Q127), so the existing tooling applies.
• Keep the EFR32 SWD header (J1-equivalent) reachable — if a UART/flow-control experiment wedges the radio, SWD + Simplicity Commander is your way back.
• Bring the board up over serial console first, before trusting Ethernet — you'll need the console to debug the DDR and PHY changes anyway. Console = the SoC's UART0 on the J1-style header (TX/RX/GND), 38400 baud, 8N1, no flow control, 3.3 V TTL adapter. Both the bootloader and Linux use the same setting (console=ttyS0,38400), so you don't switch baud between stages.

1. DRAM size / DDR2 (Winbond W9751G6KB, 64 MiB)

Do this on your original firmware first — do not flash my firmware yet. This is the single most important step, and here's why: the DRAM type and clock come from the SoC's hardware strap pins, which are the same physical register no matter which firmware runs. If your box already runs its stock Linux with 64 MiB DDR2, then the straps are already correct, and my bootloader will read exactly the same values. So the stock firmware is your ground truth — reading it first is non-destructive, it tells you in advance whether auto-detection will just work or whether you'll need a software override, and it's also when you take your full-flash backup (your way out). Flashing blind is the one thing that can brick the box.

On the original firmware, capture:

• The stock bootloader's serial boot log — the Realtek/Tuya bootloader prints Strap=…, the DRAM type, size and clock in almost the same format as mine.
• From the stock Linux: cat /proc/meminfo (detected RAM size) and dmesg (memory init).
• If devmem/BusyBox is available: devmem 0x18000008 to read the strap register directly (note: that's the physical address of SYS_HW_STRAP).

If that log shows 64 MiB DDR2 with a clock that exists in our table, you very likely won't need to touch any code at all — my bootloader will reproduce the same detection. Only if it differs do you fall through to the override below.

Now the mechanics: nothing about the DRAM size is hard-coded — the bootloader sizes the DRAM at runtime, and it already knows DDR2. But which type and clock it uses comes from your SoC's hardware strap pins, not from software, so the first job is just to read what it detects.

In 3-Main-SoC-Realtek-RTL8196E/31-Bootloader/btcode/start_c.c, at boot the SoC reads the strap register SYS_HW_STRAP (0xb8000008):

• DRAM type (SDR / DDR1 / DDR2) = strap bits [4:3] → dram_type_remap[].
• Memory clock = strap bits [12:10] → m2x_clksel_table[].
• DRAM size = probed at runtime by Calc_Dram_Size() — it writes test patterns and works out banks/rows/columns by address aliasing (it walks rows 11–14, columns 8–12, 2/4/8 banks). A standard 512 Mbit ×16 DDR2 part like the W9751G6KB (≈ row 13 / col 10 / 4 banks) sits inside those ranges, so 64 MiB should be detected automatically.
• Timings then come from DDR2_DTR_TAB, which already has a dedicated 64 MiB row.

So the bring-up procedure is:

1. Boot on the serial console (UART0, 38400 8N1, no flow control) and read the printfs — Strap=…, RAM=…, CLK=…, then the w/b/row/col probe output and DCR=…. That immediately tells you what the bootloader saw. If you get RAM=DDR2, the right clock, 64 MiB detected, and Linux comes up stable → you're done, nothing to declare.
2. If RAM= is not DDR2, or the clock isn't one of the table entries (i.e. your board straps differently from ours), that's where you "declare" it in software — bypass the strap read and force the values near the end of start_c():

   unsigned char dramtype = DRAM_DDR2;        // instead of dram_type_remap[dramtype_sel]
   unsigned int  m2xclk   = <your clock>;     // instead of m2x_clksel_table[m2x_freq_sel]

3. If type and clock are right but it's unstable, the knob to tune is the 64 MiB row of DDR2_DTR_TAB (and, if needed, the DDR_cali_API7() calibration pass).

Build with ./build_bootloader.sh. Don't flash a hand-tuned bootloader without a serial/SWD fallback — this is the one change that can leave you with a dead box, so keep a recovery path open and post your boot log; I can read the strap/size values with you.

2. EFR32MG13P732HI firmware + flow control

The MG13 is still Series 1, so it builds from the same Gecko SDK 4.5.0 / EmberZNet 7.5.1 line this repo already uses — no SDK jump needed. To retarget:

• 2-Zigbee-Radio-Silabs-EFR32/24-NCP-UART-HW/build_ncp.sh — TARGET_DEVICE="EFR32MG1B232F256GM48" → your EFR32MG13P732HI part id.
• The matching patches/*.slcp (e.g. 24-NCP-UART-HW/patches/ncp-uart-hw.slcp) — the board/part id line, plus the UART pin routing. This is the real porting work: the .slcp/patch overlay hard-codes the VCOM TX/RX (and RTS/CTS) pins for the Lidl board. On your module the USART pins to the RTL8196E are almost certainly different, so you'll need to map them from your schematic.

On "the chip doesn't support hardware flow control" — that's not right, and it matters. Every EFR32 Series 1 USART, the MG13 included, natively supports RTS/CTS hardware flow control: you allocate the pins with RTSPEN/CTSPEN in USARTn_ROUTEPEN and enable the handshake with CTSEN in USARTn_CTRLX (autoCsEnable at the emlib level). It's a USART peripheral feature, present regardless of the package or module. See the EFR32MG13 USART docs and AN0059.1: UART Flow Control.

So if HW flow control looks unavailable on your board, it's almost certainly not a silicon limitation but one of:

• the RTS/CTS pins aren't physically wired between the EFR32 and the RTL8196E on your PCB (the most common case);
• on a pre-made module, those GPIOs aren't broken out to pads — though RTS/CTS can be mapped to several USART pin locations, so usually a free GPIO can carry them;
• you saw the Gecko bootloader, which runs without flow control (one-shot Xmodem), and generalized from it.

The key question back to you: are the RTS and CTS lines actually routed EFR32↔RTL8196E on your board? If yes → use hardware flow control, full stop — it's the well-trodden path here and what the project mandates. If they're genuinely not wired, then and only then software (XON/XOFF) flow control becomes a fallback — and it's a fallback I'd discourage: this project deliberately requires hardware RTS/CTS, because without working flow control the EFR32's 16-byte RX FIFO overruns under burst at high baud and the link decoheres. If you're forced down the XON/XOFF route, set the flow-control type in the .slcp accordingly, drop the baud (start at 115200, not 460800+), and stress-test hard. For NCP it's at least plausible (the ASH framing layer already escapes the XON/XOFF bytes 0x11/0x13); for RCP/CPC it's more fragile.

Which firmware are you targeting — NCP (direct EZSP to Z2M/ZHA) or RCP (cpcd+zigbeed)? That changes the flow-control story (RCP/CPC is more sensitive), and it would also help to see the EFR32↔RTL8196E UART wiring from your schematic.

3. Ethernet PHY on port 0 instead of port 4

This one is clean — it's a device-tree edit, not driver surgery.

• Primary: 3-Main-SoC-Realtek-RTL8196E/32-Kernel/files-6.18/arch/mips/boot/dts/realtek/rtl8196e.dts — the interface@0 node has member-ports = <0x10> and untag-ports = <0x10> (the mask is one bit per port: bit 4 = port 4). For port 0, change both to <0x01>.
• The driver's fallback defaults live in …/drivers/net/ethernet/rtl8196e-eth/rtl8196e_dt.c (member_ports = 0x10, phy_id = 4) — the DTS overrides these, but set phy_id = 0 there too for consistency if you want a matching fallback.

Rebuild with build_kernel.sh. If the link doesn't come up, check the PHY address your board strapped — phy_id must match the PHY's MDIO address, which isn't necessarily equal to the switch port number.

4. LEDs and reset button GPIOs

• Reset/factory button: 3-Main-SoC-Realtek-RTL8196E/34-Userdata/s40button/src/s40button.c — #define BUTTON_BIT 9 (active-low GPIO read via /dev/mem at 0x18003500). Change to your button's GPIO number, rebuild with build_s40button.sh.
• Status LED: in the same rtl8196e.dts, the status-led node uses gpios = <&gpio0 11 GPIO_ACTIVE_LOW> — change 11 (and the polarity if yours is active-high).
• LAN LED heads-up: on the original board the LAN LED is hardwired to the switch ASIC LED output (driven via the Ethernet driver's LED register), not a GPIO. If your board wires LAN activity differently, that's a separate path — tell me what you see and we'll trace it.

Suggested order of attack

1. Backup + confirm serial console + SWD recovery.
2. Bootloader/DDR — boot on serial, read the Strap=/RAM=/CLK=/size printfs, get to a Linux prompt with all 64 MiB visible (cat /proc/meminfo).
3. Ethernet (port-0 DTS change → reachable over the network).
4. EFR32 firmware + flow control (radio link).
5. LEDs + button (cosmetics last).

Please share as much about the device as you can

The more I know about your exact hardware, the more specific (and safer) the guidance gets. If you can, please post:

• What it is and where it came from — make/model/brand, and a purchase link (Amazon/AliExpress/etc.) so I can see the same product page you did.
• Photos — clear shots of both sides of the PCB, the RF shield/can, any silkscreen, and close-ups of the RTL8196E, the EFR32 module, the flash chip, and the J1-style header / test points.
• Markings — exact part numbers printed on the chips and module (the module marking is what told you it's an MG13).
• Schematic or pin mapping if you have any — especially the EFR32↔RTL8196E UART wiring (TX/RX and RTS/CTS), the Ethernet PHY/port strapping, and the GPIO numbers for the LEDs and the reset button.
• Boot logs — the stock bootloader's serial output and stock Linux dmesg + cat /proc/meminfo (per section 1).

Start with the serial console log from the first DDR bring-up and we'll take it from there. Happy to iterate with you on each step. 👍

[hlyi]

@jnilo1 Thanks for detailed feedback. The device is Sengled smart hub G4. It doesn't think it run similar FW has lidl gateway, it has its own with minimum output from console. I could not log into the linux box itself to provide the information you asked.

1. It seems that start.S overrides some of strap values to force using 32MB DDR. Please see the code below:

        /* DDR timing configuration */
        REG32_W(DDR_CFG_REG, DDR1_32MB_193MHZ)  /* DDR1 32MB @ 193MHz */

Does it impact size detection?

2. in rtl8196e_uart_bridge_main.c, it manipulate bits {7,10,13} why bit 7 and bit 13 are needed? what are those two pins mapped to?

3. I was able to get ethernet port working, but ethernet LED doesn't work, ( after change pin for status LED, status works), do you know why?

4. the reset button doesn't work even after mapping to correct IO ( change from pin GPIOB1 to pin GPIOB6) in s40button.c, where else need to change?

[jnilo1]

Thanks @hlyi — this is excellent, concrete debugging, and a couple of your findings actually correct something I told you earlier, so let me set the record straight first.

0. Important correction to my DRAM explanation

In my first reply I said "nothing about the DRAM size is hard-coded, the bootloader probes it at runtime." That was misleading, and your start.S find is exactly why. Here is the real flow, which has two stages:

• Stage-1 (start.S, runs from flash): lines 75/77 write hard-coded scratch values just to bring DRAM up enough to copy and run the next stage:
  • REG32_W(DDR_CFG_REG, DDR1_32MB_193MHZ) → 0xB8001008 = 0x90E36920
  • REG32_W(DDR_TIMING_REG, DDR_TIMING_VAL) → 0xB8001004 = 0x54480000
    These come from start.h. They are throwaway — DDR1/32MB/193MHz is only "good enough to run from RAM."
• Stage-1.5 (start_c.c, runs from RAM): this is the authoritative configuration, and it overwrites both registers:
  • reads the hardware strap SYS_HW_STRAP (0xb8000008) → dramtype (bits [4:3]) and m2xclk (bits [12:10]);
  • Calc_Dram_Size() probes the geometry and writes the final DCR (0xb8001004);
  • LookUp_MemTimingTable() looks up the timing and writes the final DTR (0xb8001008) from DDRx_DTR_TAB.

This is the answer to your follow-up email ("I changed start.h to 0x54880000, reflashed, but Linux still shows 0x54480000 — did I change the wrong file?"). Yes — start.h is the wrong place. That value only seeds the transient stage-1 write; start_c.c's Calc_Dram_Size() overwrites 0xb8001004 a moment later, driven by your board's strap. Editing start.h can't change the final value.

1. So where you change it — and what to read first

The authoritative code is boot_entry in 3-Main-SoC-Realtek-RTL8196E/31-Bootloader/btcode/start_c.c (around line 820 onward). To force values, override there, right after the strap read:

unsigned char dramtype = dram_type_remap[dramtype_sel];   // <- force DRAM_DDR2 if strap is wrong
unsigned int  m2xclk   = m2x_clksel_table[m2x_freq_sel];  // <- force your clock if strap is wrong
...
unsigned int dramsize = Calc_Dram_Size(dramtype);         // <- runtime probe writes final DCR
LookUp_MemTimingTable(dramtype, dramsize, m2xclk);         // <- writes final DTR

Before you touch that code, read one register — it decides everything and needs no flash, because the strap is hardware and reads the same under any firmware. From whatever Linux is on the box right now (stock or ours):

devmem 0x18000008      # SYS_HW_STRAP — SoC pin strapping, firmware-independent

Decode it the way start_c.c does:

• bits [4:3] → DRAM type: 00/01 = SDR, 10 = DDR2, 11 = DDR1
• bits [12:10] → memory clock index

That tells you whether your SoC strapped itself as DDR1 or DDR2 and at what clock. If it says DDR2 but our build is running it as DDR1/32 MiB, then the strap path in start_c.c is decoding it differently than your stock loader does, and the override above is your lever. If it says DDR1, the type is right and you're only chasing size/timing.

Two data points you already have in hand, no flashing required:

• The B8001004 = 0x54880000 / B8001008 = 0x91051D20 you dumped in the "realtek boot shell" — worth pinning down which bootloader that shell is: your stock Sengled one, or our modified one? If it's stock, those are the DCR/DTR your RAM actually wants — the exact target to make start_c.c reproduce. (0x54880000 vs our 0x54480000 differ only in the geometry nibble — classic "stock configured the full size, our build settled on 32 MiB.")
• If you're already booting our bootloader over serial (you reflashed it, so its console is right there — no new flash), its Strap=…RAM=…CLK=…DDR2 DTR=… printf block is the fastest cross-check of all of the above. If you'd rather not run our bootloader yet, the devmem strap read alone is enough to move forward.

2. Your numbered questions

Q1 — "start.S forces DDR1_32MB_193MHZ, does it impact size detection?"
No, not the final size — it's the transient stage-1 seed (see §0). Calc_Dram_Size() re-probes afterward. It does matter in one way: if your chip can't even run reliably under the DDR1/32MB/193MHz scratch settings, the board would hang in stage-1 before the Strap= print. Since you reach a Linux prompt, stage-1 is fine and the final geometry is whatever start_c.c decides.

Q2 — rtl8196e_uart_bridge_main.c bits {7,10,13} — why 7 and 13, what pins?
Those are not UART data pins. They live in PIN_MUX_SEL_2 (syscon + 0x44), and {7,10,13} = 0x2480 route the single SoC pin wired to the EFR32 nRST line so the driver can pulse-reset the radio (echo 1 > /sys/module/rtl8196e_uart_bridge/parameters/nrst_pulse). They're three bits of one mux field for that one reset pin, not two separate data pins. The actual UART1 TX/RX mux is elsewhere — rtl8196e_hw.c sets PIN_MUX_SEL (0x40) bits [4:3]=01 (UART1 TXD). Porting caveat: if your board wires the EFR32 nRST to a different SoC pin than the Lidl unit, these 0x44 bits are wrong for you and nrst_pulse won't reset your radio — you'd need to find your nRST routing. See 2-Zigbee-Radio-Silabs-EFR32/.../POST-MORTEM-bootloader-recovery.md.

Q3 — Ethernet works, but the LAN LED doesn't (status LED does after your pin change).
The two LEDs are driven by completely different mechanisms, which is the catch:

• Status LED = GPIO-driven (gpio-leds-pwm, GPIOB3 = bit 11). That's why your DTS gpios = <... 11 ...> change worked.
• LAN LED = hardwired to the switch ASIC's LED output, not a GPIO. It's controlled by LEDCREG/DIRECTLCR (see rtl8196e_regs.h and led_mode_store in rtl8196e_main.c), and its pin mux is in PIN_MUX_SEL_2. On the Lidl board the LAN LED sits on LED_PORT0 (GPIOB2, bits [1:0] of 0x44), which rtl8196e_hw.c deliberately preserves while clearing the other 0x44 bits ([7:6],[10:9],[13:12],[17:15]).

So two things to check on your board:

1. Write bright, dim, then off into the driver's led_mode sysfs attribute (it's a DEVICE_ATTR_RW(led_mode) on the Ethernet device — find /sys -name led_mode). If none of the three changes your LAN LED at all, the pin isn't reaching the ASIC LED controller.
2. Figure out which switch LED_PORTx pin your LAN LED is physically on. If it's not LED_PORT0/GPIOB2, then our rtl8196e_hw.c pinmux code is very likely clearing the mux bits for your LED pin (we only preserve [1:0] and [4:3] of 0x44). The fix is to preserve/enable the 0x44 field for your LED pin and make sure its bit is set in DIRECTLCR. Caveat: I can't tell you which 0x44 field that is from a schematic alone — the full pin→mux-bit map isn't in the public datasheet, only the few fields our code comments document. Finding it is empirical: with the LED forced on (led_mode=bright), sweep the 0x44 fields with devmem 0x18000044 and watch which one toggles your LAN LED.

Q4 — reset button still dead after changing GPIOB1 → GPIOB6 in s40button.c.
Almost certainly a bit-numbering bug. BUTTON_BIT is the absolute bit index in the combined PABCD register at 0x18003500, where group A = bits 0–7, group B = bits 8–15, etc. So:

• GPIOB1 = 8 + 1 = 9 ← the current #define BUTTON_BIT 9 ✓
• GPIOB6 = 8 + 6 = 14 ← what you want

If you set BUTTON_BIT to 6, you're reading GPIOA6, the wrong pin entirely. Set it to 14. configure_gpio() will then clear bit 14 in CNR (mux → GPIO) and DIR (→ input) for you. Quick non-destructive check first, before rebuilding:

# read DATA bit 14 while you press/release the button:
devmem 0x1800350C 32     # bit 14 should toggle; active LOW = 0 when pressed

If bit 14 doesn't move, the button is on a different pin than GPIOB6 and the devmem sweep will tell us which. (Same absolute-bit convention applies to your status LED: GPIOB3 = 11, which is why DTS 11 worked — a nice cross-check that the A=0-7/B=8-15 mapping holds on your board.)

Net

Start with the one read that needs no flashing: devmem 0x18000008 from the Linux you already have. Decode the type/clock bits, line it up against your stock loader's 0x54880000/0x91051D20, and you'll know immediately whether you're forcing the type in start_c.c or just chasing size/timing — only then do you touch the bootloader. The button fix is a one-liner (BUTTON_BIT 14). The LAN LED is the one genuinely board-specific piece, and I'll be straight with you: the full pin→mux-bit table isn't in the public datasheet — we only reverse-engineered the few 0x44 fields the code comments document — so the exact bits for your board can't be derived on paper. The reliable way is empirical: with the LED forced on (led_mode=bright), sweep the PIN_MUX_SEL_2 fields with devmem 0x18000044 and watch which one toggles your LAN LED — that's the field your pin is on. Really nice work getting Ethernet and the status LED up already. 👍

[hlyi]

@jnilo1 Thanks for the suggestion. Here are what I found:

1. I made a mistake earlier, actually, changing DDR_CFG_REG and DDR_TIMING_REG in start.h does show up in linux
2. could you please double check "start_c.c"? The boot doesn't seem to run the code based on two observations:
   • not print out in console
   • Calc_Dram_Size doesn't seem to be coded correctly, the size detection loop should be decreasing instead of increasing, if the code run, the detected memory size should be minimum instead of 32M
3. the way rtl8196e_uart_bridge_main.c was coded, it affects 3 GPIOs instead of one. also the masks don't seem to be correct.
4. The culprit of that linux doesn't see 64M seems due to dts
5. Non-working reset button is not due to misconfiguration of GPIOB6, I already set to 14.

[hlyi]

Btw, are some codes AI generated? I found some dead codes that making tracing problem more difficult? Is there a way to trim dead codes? Thx

[jnilo1]

Thank you, @hlyi — and I owe you a straight correction. You were right and I was wrong, twice, on the DRAM, and your reading of the tree is spot-on. Let me set the record straight and answer all five points from the code.

The root cause — and your "AI-generated / dead code" question

You found the real problem, so let me start there. The btcode bootloader is a cleanup/modernization of Realtek's original 2012 SDK bootloader. The DRAM bring-up was rewritten as hand-written assembly in start.S, and the old Realtek C path — start_c.c, with the SYS_HW_STRAP read, Calc_Dram_Size() and LookUp_MemTimingTable() — was meant to go. That cleanup was incomplete: start_c.c is still in the tree, compiled to start_c.o, but never linked. The Makefile links start.o only ($<), and the final image's system.map contains zero start_c symbols.

So that file is dead code. It doesn't run (no console output — exactly as you observed), and whatever looks off in Calc_Dram_Size()'s loop is moot because nothing calls it. You were right on both counts. To answer the question directly: yes, this project is developed with AI assistance — but this particular dead code is genuine 2012 Realtek vendor legacy, not generated; it's just leftover from an incomplete cleanup, and it's exactly the kind of thing that makes tracing miserable. I'll remove start_c.c and drop it from the Makefile so it stops misleading people. Thanks for catching it.

1 & 2 — DRAM: start.h is the correct file (you were right)

The real flow: start.S (stage-1, runs from flash) writes the DDR config inline from start.h, runs DDR_Auto_Calibration, copies the payload to RAM, and jumps. Nothing overwrites those writes — there is no live strap decode and no runtime sizing in the shipped path.

• start.S:77 writes 0xB8001004 ← DDR_TIMING_VAL (currently 0x54480000)
• start.S:75 writes 0xB8001008 ← DDR1_32MB_193MHZ (currently 0x90E36920)

Your stock loader leaves 0xB8001004 = 0x54880000 and 0xB8001008 = 0x91051D20 — the config your RAM actually wants. So in start.h, set:

• DDR_TIMING_VAL → 0x54880000
• DDR1_32MB_193MHZ → 0x91051D20

Rebuild, and our loader programs the controller identically to your stock one. (Heads-up: those macro names are unreliable — another cleanup leftover — so go by the address, not the name. DDR_TIMING_VAL is what lands at 0x…1004, the register holding the geometry nibble you spotted.) You already confirmed start.h edits reach Linux, so this is the right lever.

And please ignore my earlier "read devmem 0x18000008" advice — that was premised on start_c.c decoding the strap, which it never does. The strap has no effect on our DRAM config. Your stock register dump is the ground truth, and you already have it.

4 — Linux still shows 32 MB: that's the DTS, not the bootloader

Independently of the controller, Linux takes its RAM size from the device-tree memory node, hard-coded to 32 MiB:

/* rtl8196e.dts (and rtl819x.dtsi) */
memory@0 { device_type = "memory"; reg = <0x00000000 0x02000000>; };  /* 32MB */

For 64 MiB, change it to 0x04000000. The .dts value wins over the .dtsi, but fix both for consistency. This is separate from the bootloader change — you need both: the controller programmed for 64 MB and the DTS telling Linux it's there.

3 — nRST bits {7,10,13}: you're right, three fields and an empirical value

nrst_pulse does regmap_update_bits(0x44, 0x2480, …). 0x2480 = bits 7, 10, 13 — three separate, non-adjacent bits, so it modifies three mux fields, not "the one pin" the comment claims. And the value is empirical — the comment itself notes it merely mirrors the chip/bootloader default; it is not derived from a field map (the RTL8196E pad-mux field layout isn't in any public datasheet). The Ethernet driver clears the same region at probe (rtl8196e_hw.c: (3<<6)|(3<<9)|(3<<12)|(7<<15)).

For your board, the EFR32 nRST almost certainly lands on a different SoC pin, so 0x2480 won't be right for you — you'd have to find your nRST routing empirically. The comment overstates its precision; thanks for calling it out.

5 — Button: BUTTON_BIT=14 is necessary but not sufficient

s40button only pokes the GPIO controller at 0x18003500 (CNR +0x00, DIR +0x08, DATA +0x0C). It never touches the SoC pad-mux (0x18000040 / 0x44) — it assumes the pad is already routed to the GPIO controller.

On the Lidl board GPIOB1's pad defaults to GPIO; on yours GPIOB6's pad is likely muxed to a peripheral — and the Ethernet driver actively rewrites 0x40/0x44 at probe, which can steer it. (Note: the GPIO-controller bit index — B6 = 14 — is a different coordinate space from the pad-mux field in 0x40/0x44.)

Diagnostic, before rebuilding anything: devmem 0x1800350C and watch bit 14 toggle as you press (active LOW). If it doesn't move, the pad isn't reaching the GPIO controller — you'd need to mux it at 0x40/0x44 first, and make sure the Ethernet driver isn't clearing it.

Net

Thank you, genuinely. You corrected two wrong answers from me and surfaced real dead code — both are going straight into the project's notes, and I'll clean up start_c.c. The DRAM path forward is: your stock values into start.h (controller) + 0x04000000 in the DTS (Linux), built and verified separately. Keep the findings coming. 👍

[hlyi]

@jnilo1 Thanks for confirming. Can we enhance build system to support multiple hubs? Current setup is good for building single configuration. Any other configuration requires manually changing quite a few files, making sync between configurations error prone. Thx

[hlyi]

This request has been tracked with multiple subtasks. Closing