# DF-5498 — crom_add_simple_text() crc_len includes the header quadlet; crom_load()/crom_crc() read one quadlet past chunk->data[] and publish it in the Config ROM

File: `sys/bus/firewire/fwcrom.c` — pass 2. Userspace-model verification
(fwcrom.c's own non-_KERNEL build path, as fwcontrol(8) links it).

## Build / run (guest, any user with /usr/src readable)

```
sh build.sh      # cc -DTEST (pulls in the builders) -Dmain=fwcrom_test_main
sh run.sh        # exit 42 == REPRODUCED
```

## Expected (baseline)

```
case1 len=72: builder crc_len=21 (data holds 21 quads; 1+crc_len=22 quads copied/CRC'd)
case1: PATTERN FOUND in generated ROM (OOB quadlet published)
case2 len=68 (control): crc_len=20, PATTERN absent
RESULT: REPRODUCED ...
```

The 4 bytes past `chunk->data[]` (tail of `struct crom_chunk`) are read by
`crom_crc()` (fwcrom.c:517-518) and `crom_copy()` (fwcrom.c:520-522) and copied
verbatim into the host's generated Config ROM. Also visible: the published
leaf `crc_len` is off by one against IEEE 1212 at EVERY text length (21 vs 20
for len=72; 20 vs 19 for len=68) — every text leaf this host broadcasts carries
a spurious trailing quadlet and a spec-incorrect length.

## Fix validation

`fix.diff` (`tl->crc_len = howmany(len, 4) + 2`) applied to guest /usr/src,
model rebuilt: crc_len=20 == IEEE-1212-correct, PATTERN absent, ROM one
quadlet shorter per leaf (`fix_run.log`).