Re: [9fans] Raspberry Pi image

[Richard Miller <9fans@hamnavoe.com>]

> I'd be curious to know the methodology for producing this port as well.

OS porting is something of a black art.  I've been doing it for a while
(http://www.usenix.org/legacy/publications/library/proceedings/usenix98/invited_talks/miller.ps)
and it's not getting any easier.  Hardware vendors used to provide
meticulously accurate reference manuals describing device behaviour at a
register level, along with a programming manual explaining the sequence of
operations required for standard procedures like device initialisation and
error recovery.  Too often nowadays the best you'll get is a sketchy and
inaccurate datasheet, and at worst the datasheet will be a "trade secret"
and the only option is to reverse engineer many thousand lines of badly
written linux driver.

For the Raspberry Pi port, excellent documentation was available at least
for the arm cpu.  Plan 9 kernels already existed for armv5 and armv7
architectures, so I was mostly able to interpolate between the two to
produce the low-level assembly parts of the kernel for the Pi's armv6.
Hardware floating support for the kernel had already been done at the Labs
for the teg2, and vfp code generation for the 5l linker was straightforward
to add, using arm manuals.

The rest of the work was creating device drivers, some easily adapted from
other Plan 9 instances (eg uart and lcd display), some written from scratch
using Broadcom's BCM2835 datasheet (eg sd/mmc).  By far the hardest driver
was for the usb host adapter, which on the Pi is very non-standard and has
no officially available documentation.  I couldn't face the prospect of
digesting the linux driver (which is huge, unreadable, and at the time was
known not to work reliably).  Luckily a web search turned up datasheets
for some apparently very similar devices, which I was able to work from.
Even so, writing and debugging the usb driver accounted for most of the time
and effort of the whole project.