From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Ramakrishnan Muthukrishnan Date: Wed, 19 Feb 2014 16:25:58 +0530 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Raspberry Pi image Topicbox-Message-UUID: bc7b9ad8-ead8-11e9-9d60-3106f5b1d025 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