Repository navigation
J71b RAM test of main on a second unit: touchscreen, charging, brcmfmac reset #22
Description
Results from RAM-booting current main (2d256cf, apple-16k, plus #20) with orchard run on a second J71b (iPad7,5, iPadOS 17.7.11 firmware). The init is omarchy-a/examples/charger-001's USB serial shell, with drivers loaded by hand. The comparison column is the Omarchy A 0.1.1 / hardware 0.1.10 install on the same unit. Posting it here for the J71b items in docs/integration/j71t.md.
| Check | 0.1.10 install | main RAM boot |
|---|---|---|
| Landlock | not built | /sys/kernel/security/lsm = capability,landlock |
| Wi-Fi | P2P -52 errors at every boot |
disabling feature P2P with #20, wlan0 up, 0 P2P errors (details on #20) |
| Touchscreen, untouched | about 13 IRQ/s; irq/58-apple-z2-irq in D state, about 7% of a core spinning in _spi_transfer_delay_ns (10 µs CS delays); load average 1.0 |
0 IRQs and 0 thread ticks in 10 s, thread in S state, load average 0.04 |
| Touchscreen, swiping | — | 301 IRQs in 15 s, input: iPad7,5 Touchscreen |
Charging: same x86 laptop USB port and cable, two boots, two classifications
| Boot | lightning usb_type |
input_current_limit |
battery current_now |
|---|---|---|---|
| 1 | [CDP] |
1500000 | +910000 (Charging) |
| 2 | [SDP] |
500000 | -113000 (Discharging) |
The kernel, modules and gadget setup were identical in both boots. Between them I changed only the init's /proc/sys/kernel/modprobe (/bin/false → /bin/modprobe) and the order of manual modprobes, all after the charger had already probed (it's built in). The init creates the configfs ACM gadget (05ac:4144) right after mounting, so the host enumerates early in both. This looks like the race in the README ("only when the early check runs before USB enumeration"), on a non-Mac host. One more data point for CH-04 and CH-16.
brcmfmac: a second probe after a failed setup reset the iPad (no rmmod needed)
charger-001's init sets /proc/sys/kernel/modprobe to /bin/false, so the first probe can't load brcmfmac-wcc:
brcmf_fwvid_request_module: mod=wcc: failed 256
brcmf_attach: brcmf_fwvid_attach failed
brcmf_pcie_setup: Dongle setup failed
brcmf_fw_crashed: Firmware has halted or crashed
Then:
modprobe brcmfmac-wcc(ok).rmmod brcmfmac→Resource temporarily unavailable(wcc holds a reference).echo 0000:02:00.0 > /sys/bus/pci/drivers/brcmfmac/unbind→No such device(already unbound after the failed setup).echo 0000:02:00.0 > /sys/bus/pci/drivers/brcmfmac/bind→ the iPad reset to iPadOS within seconds (USB re-enumerated as05ac:12ab).
So the open item "rmmod brcmfmac after a failed probe, then loading it again, reset the iPad 6 once" reproduces without rmmod: probing the PCI function a second time after a failed dongle setup is enough. I only had USB serial, so there's no kernel log of the reset itself. On the next RAM boot, with brcmfmac-wcc loaded before brcmfmac, the first probe succeeded and nothing reset.
Side note: Wi-Fi experiments built from charger-001 need brcmfmac-wcc loaded first, or request_module allowed. Otherwise the first probe takes this failure path.
Found on the way
- kernel: Let x86_64 hosts reproduce the committed config #21: on x86_64 Linux,
kernel/buildfails its configcmponCONFIG_CC_CAN_LINK, so no kernel builds there. - Stop checkra1n when a RAM boot abandons palera1n cli#10:
orchard runstill left checkra1n running after a palera1n timeout (it happened during this session). Add opt-in source-aware charging to J71b #8 covered install/launch only.
🤖 Generated with Claude Code
Activity
dl-alexandre commentedon Oct 29, 2026
A cable-specific charging failure on
main, plus the frame behind it.With a different Lightning cable than in the results above (same unit and host, a different laptop USB port), a RAM boot of
mainwithapple_tristar_charger.dyndbg=+pnever identified the source:(The USB session only began at 21.5 s, so this isn't the gadget/early-look race. That race is a separate observation.)
I read the frame passively from the installed 0.1.10 system with the same cable (
i2c-dev,i2ctransfer -y 0 w1@0x1a 0x0c r1, then0x20 r8, then0x0c r1). Three reads, all identical:So the controller reports a valid capability frame whose payload, CRC included, is all zero.
cbtl_crc(packet, 7)over75 00 … 00with init0xffcan't be0x00, socbtl_capability()returns-EBADMSGon every attempt.tristar_identify()then gives up before BrickID/BC1.2, although the orientation it needs (after & 0x40) is valid.The same unit and host with the cable used earlier today got a valid frame and was identified as CDP at 1500 mA (+910 mA charging).
A possible handling: treat an all-zero payload after
0x75as "this cable reports no capability" rather than a corrupted read. For example, assume nousbclane and continue withtristar_identify_usba()on the status orientation. Then BrickID/BC1.2 still decide the current, and a source with no signature still gets the 500 mA fallback. It's your call whether that's safe enough; I haven't changed the driver.🤖 Generated with Claude Code