https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297800
Bug ID: 297800
Summary: arm: BeagleBone Black does not boot on 15.x; hardware
validation of the pending ti_sysc/clock stack on
stable/15
Product: Base System
Version: 15.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: arm
Assignee: [email protected]
Reporter: [email protected]
Created attachment 274036
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=274036&action=edit
per-peripheral verification matrix, BBB on 15.1-STABLE
THE PROBLEM
A BeagleBone Black does not boot any 15.x FreeBSD. 13.3 was the last release
that booted it, and 13.x has since been removed from the download mirrors,
surviving only on archive.freebsd.org/old-releases. AM335x was removed from
the armv7 GENERIC kernel config in 3416e102c4e9, and the drivers left in the
tree have bit-rotted since, because nothing builds them.
The failure on current sources is documented on the project wiki at
https://wiki.freebsd.org/arm/BeagleBoneBlackMain:
ti_sysc0: <TI SYSC Interconnect> on ofwbus0
device_attach: ti_sysc0 attach returned 6
...
panic: No usable event timer found!
The real fault is the ti_sysc attach failure; the timer panic is a consequence.
THE WORK ALREADY EXISTS, AND IS STALLED
Oskar Holmlund (oh@) has an eleven-revision stack in review that fixes this:
D46703 AM335X kernel config
D46712 D46713 D46714 ti_sysc, DM timer, related
D41888 ti,clksel driver
D46722 simple-pm-bus
D46723 update TI clocks (syscon, clkctrl tables)
D46742 D46743 D46744 pinmux / GPIO
D46746 cpsw -> cpsw-switch for Ethernet
That stack has been idle since October 2024. D46723, the largest piece, has
two open reviewer comments on it: "Where do all these tables come from?" and
"This is a bit too much for me to fully review."
This PR does not propose changes to that work. It exists to supply the
hardware evidence the review has been waiting on, in a durable place that the
individual revisions can link to.
WHAT WAS ALREADY KNOWN, AND WHAT THIS ADDS
The wiki, written by the author of the stack, already shows the stack working
on a PocketBeagle, on main (15.0-CURRENT), reaching a login prompt. It also
states plainly that this was not true of the BeagleBone Black:
"with these changes Pocketbeagle will boot, but not the BBB due to changes
in the ethernetcontroller in the DTS"
with D46742/D46743/D46744 named for GPIO and D46746 for Ethernet, but no BBB
result shown.
This report closes that gap, and moves it to a branch:
- BeagleBone Black Rev B3, not PocketBeagle
- stable/15, not main -- the eleven revisions rebased from stable/14 onto
stable/15 at 6b25004d1d18, KERNCONF=AM335X
- a full per-peripheral verification matrix rather than a single boot
- six unattended reboot soak cycles
Result: the board boots 15.1-STABLE to multi-user with zero device attach
failures. The ti_sysc / event-timer failure above does not occur.
VERIFIED FUNCTIONAL
- Serial console
- microSD as UFS root, read-write
- Ethernet (DHCP lease, 100baseTX full duplex, bidirectional ping 0.0% loss,
MAC read from board EEPROM matching what 13.5-RELEASE reports on the same
board)
- USB OTG (both controllers, root hubs at 480 Mbps)
- I2C (TPS65217 PMIC at 0x24, board EEPROM at 0x50)
- GPIO (all four banks, direction and value verified at register level).
- With device tree overlays, additionally ADC (12-bit conversions with real
variation), PWM (period and duty set and read back) and SPI (spigen attaches,
/dev/spigen0.0 created).
- eMMC is detected but deliberately not written, to preserve a recovery path.
The attached matrix distinguishes FUNCTIONAL from ATTACH-only and lists what
was not tested and why -- eQEP has no FreeBSD driver at all, PRUSS needs a PRU
toolchain, SPI loopback needs a jumper, electrical verification at the header
pins needs instruments. Nothing is claimed that was not exercised.
TWO BUGS FOUND ON HARDWARE
1. Under the ti,clksel binding the parent holds the register offset and a
child's reg is an index matching its unit address. ti_mux_clock.c,
ti_divider_clock.c and ti_gate_clock.c test the child's reg first, so the
offset becomes 1, the syscon read lands on an odd address, and it takes a
fatal alignment fault while registering mux clocks:
ti_clksel0: <TI CLKSEL> on ofw_clkbus0
ti_mux12: <TI Mux Clock> on ti_clksel0
Fatal kernel mode data abort: 'Alignment Fault' on read
FSR=00000001, FAR=ffd00001
All three drivers share the defect, so fixing only the mux hits the same
fault twice more. This will be submitted separately as a follow-up on top
of the stack, not folded into it.
2. A musb clock-name fix is required for USB to attach. Credit for that one
belongs to the original author -- it exists on the malavon stablebbb/14
branch as commit 6d93b69bcf99 and requests "usbotg_fck" rather than
"usbotg_fck@47c". It is absent from the Phabricator diffs. I rebased from
the reviews, hit the failure, and diagnosed it before discovering it had
already been fixed on the branch.
A PROCESS NOTE FOR ANYONE REPRODUCING THIS
The Phabricator revisions and the github.com/malavon/freebsd-src stablebbb/14
branch have diverged, and neither is a superset of the other. D46713's branch
commit touches six files while the D46713 diff here touches four; D46712
differs the other way. The musb fix above is the practical consequence:
anyone building from the reviews alone gets a tree where USB does not attach,
with nothing to indicate a piece is missing.
Also note D46742/D46743 are not on that branch, so anyone working from the
branch alone is missing the GPIO fixes.
RELATED PRs ALREADY FILED
297785 MFC the three AM335x device-tree path fixes to stable/15. Without
those, no AM335x DTB builds on any 15.x branch at all -- a
prerequisite for any of this.
297788 MFC the cpufreq_dt single-core fix to stable/14. The wiki boot log
shows this failure ("cpufreq_dt0: Only opp-shared is supported"),
though on main it was fixed by def7999c2ccd in January 2025; it
remains present on stable/14.
297793 MFC two GENERIC cleanups to stable/14, removing vestigial TI lines.
ATTACHMENTS
bench15b-clean.log
full serial console capture, 15.1-STABLE on BeagleBone Black,
boot to multi-user
soak-results.txt
six unattended reboot cycles, each asserting login reached with no
attach failures and no panics
07-verification-matrix.md
per-peripheral results, with evidence level and what was not tested
rebase-notes.md
the stable/14 -> stable/15 rebase, file by file
Hostnames in the console log have been replaced with "buildhost" and
"[redacted]". No technical content was altered.
Two classes of console message in the log are not defects. The
"clknode_link_recalc: Attempt to use unresolved linked clock: sys_clkin_ck"
lines and their "Cannot get frequency ... error: 9" companions are artefacts
of bootverbose calling clkdom_dump(), which prints fixed-factor clocks before
their parent has resolved; sys_clkin_ck does resolve, and later entries in the
same dump read "parent: sys_clkin_ck(0), freq: 24000000". The original author
documents these as ignorable. Separately, the capture is taken over a serial
console at 115200 and occasionally drops a character.
NOT PROPOSED HERE
No change to Holmlund's revisions is proposed, and no competing revision is
intended. If splitting D46723 would help it move, I am willing to do that
work as child revisions with authorship preserved.
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.