From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 19 Feb 2014 21:14:42 +1100 Message-ID: From: Shane Morris To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=e89a8f646f8f42744b04f2bfa867 Subject: Re: [9fans] Raspberry Pi image Topicbox-Message-UUID: bc73d582-ead8-11e9-9d60-3106f5b1d025 --e89a8f646f8f42744b04f2bfa867 Content-Type: text/plain; charset=ISO-8859-1 So the "trade secret" thing explains why you don't see a port of Plan 9 for every new and exciting device and board that comes out. It is a shame, but these companies producing things like the GPUs in ARM devices insist on proprietary licences. As far as I can tell, the i.MX6 chip from Freescale is about as open as you can get, I'm just trying to remember where someone said it had an over 1,000 page manual for the chip, and I'm hoping its not this very list, otherwise I will look like a fool! The i.MX6, for that "openness" reason has been a chip I've been meaning to get, and never gotten around to. The UDOO board has the chip, and integrates an Arduino Due along for the ride. Its reasonably cheap too, although availability is not something I've looked at in a little while, and being one of those Kickstarter things, I don't think availability is a priority past shipping them to backers. I found the blog I was referring to: http://lynxline.com/projects/labs-portintg-inferno-os-to-raspberry-pi/ And it is a detailed read, I've skimmed over his Season 2 with interest. He cites your work regularly. I think you can tell what I'm thinking by mentioning the i.MX6, but I'm not pressuring you to make a port, or even get a board with the chip on it. I just think it would be interesting having Plan 9 on a multicore ARM chip, but as I said, I'm pretty certain its open enough, but please do not quote me - I'd hate to be horribly wrong! Many thanks for your description! On Wed, Feb 19, 2014 at 9:00 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. > > > --e89a8f646f8f42744b04f2bfa867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So the "trade secret" thing explains why you don= 't see a port of Plan 9 for every new and exciting device and board tha= t comes out. It is a shame, but these companies producing things like the G= PUs in ARM devices insist on proprietary licences.

As far as I can tell, the i.MX6 chip from Freescale is about= as open as you can get, I'm just trying to remember where someone said= it had an over 1,000 page manual for the chip, and I'm hoping its not = this very list, otherwise I will look like a fool! The i.MX6, for that &quo= t;openness" reason has been a chip I've been meaning to get, and n= ever gotten around to. The UDOO board has the chip, and integrates an Ardui= no Due along for the ride. Its reasonably cheap too, although availability = is not something I've looked at in a little while, and being one of tho= se Kickstarter things, I don't think availability is a priority past sh= ipping them to backers.

I found the blog I was referring to:


And it is a detailed read, I've skimmed over = his Season 2 with interest. He cites your work regularly.

I think you can tell what I'm thinking by mentioning the i.MX6,= but I'm not pressuring you to make a port, or even get a board with th= e chip on it. I just think it would be interesting having Plan 9 on a multi= core ARM chip, but as I said, I'm pretty certain its open enough, but p= lease do not quote me - I'd hate to be horribly wrong!

Many thanks for your description!


On Wed, Feb 19, 2014 at= 9:00 PM, Richard Miller <9fans@hamnavoe.com> wrote:
> I'd be curious to k= now the methodology for producing this port as well.

OS porting is something of a black art. =A0I've been doing it for= a while
(http://www.usenix.org/le= gacy/publications/library/proceedings/usenix98/invited_talks/miller.ps)=
and it's not getting any easier. =A0Hardware vendors used to provide meticulously accurate reference manuals describing device behaviour at a register level, along with a programming manual explaining the sequence of<= br> operations required for standard procedures like device initialisation and<= br> error recovery. =A0Too often nowadays the best you'll get is a sketchy = and
inaccurate datasheet, and at worst the datasheet will be a "trade secr= et"
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. =A0Plan 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.<= br> Hardware floating support for the kernel had already been done at the Labs<= br> 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<= br> other Plan 9 instances (eg uart and lcd display), some written from scratch=
using Broadcom's BCM2835 datasheet (eg sd/mmc). =A0By far the hardest d= river
was for the usb host adapter, which on the Pi is very non-standard and has<= br> no officially available documentation. =A0I couldn't face the prospect = of
digesting the linux driver (which is huge, unreadable, and at the time was<= br> known not to work reliably). =A0Luckily 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 tim= e
and effort of the whole project.



--e89a8f646f8f42744b04f2bfa867--