a day ago
- The author bought a 2008 OMAP3530 BeagleBoard to debug a UART driver bug.
- They explored USB booting—a feature of the OMAP3530—out of curiosity, not necessity.
- Finding documentation was difficult as many old resources (gitorious, arago-project, eLinux) had disappeared, but Internet Archive helped.
- The USB boot process involves the OMAP enumerating, host reading ASIC ID, sending commands, and transferring bootloader within 300 ms.
- Modern computers with USB 3.0 (xHCI) controllers failed to upload X-Loader—they crammed too many packets into one frame, causing STALL errors.
- Adding a 1 ms delay before each libusb_bulk_transfer call fixed the X-Loader upload on modern machines.
- A second issue arose: after uploading X-Loader, newer host controllers gave up after unanswered IN packets, even though retries should have worked.
- A 20 ms delay between uploading X-Loader and reading from it resolved the issue, as X-Loader needed time to launch.
- On slower computers, udev couldn't respond to the OMAP's 300 ms timeout; a custom libusb using netlink instead of udev fixed hotplug detection.
- The author's patches to omap_loader (with delays and transfer size limits) were submitted upstream and later proved useful for reviving old Nest thermostats that use OMAP processors.
- The project highlights how a random side project unexpectedly helped others, and that USB 3.0 host controller speed rather than xHCI itself caused the issues.