Re: [9fans] Raspberry Pi image

[Ramakrishnan Muthukrishnan <vu3rdd@gmail.com>]

On Wed, Feb 19, 2014 at 3:30 PM, Richard Miller <9fans@hamnavoe.com> wrote:
>> 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.

Many thanks for the great writeup.


--
  Ramakrishnan