[9fans] Raspberry Pi image

[9fans] Raspberry Pi image

[Ramakrishnan Muthukrishnan]

Hi plan9 hackers,

I bought a Raspberry Pi last weekend and would like to try out Plan9
on it. I just want to check the list if this link is the right one to
get the latest image?

 <http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz>

thanks
--
  Ramakrishnan

Re: [9fans] Raspberry Pi image

[Richard Miller]

> I just want to check the list if this link is the right one to
> get the latest image?
>
>  <http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz>

Yes, it is.

Re: [9fans] Raspberry Pi image

[Ramakrishnan Muthukrishnan]

On Tue, Feb 18, 2014 at 3:59 PM, Richard Miller <9fans@hamnavoe.com> wrote:
>> I just want to check the list if this link is the right one to
>> get the latest image?
>>
>>  <http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz>
>
> Yes, it is.

Thank you.

--
  Ramakrishnan

Re: [9fans] Raspberry Pi image

[Grant R. Mather]

>> I just want to check the list if this link is the right one to
>> get the latest image?
>>
>>  <http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz>
>
> Yes, it is.

Thank you for creating the Raspberry Pi port.  I had always wanted to
use Plan 9, but I was not able to until this port was created, because
I didn't have any compatible hardware.  I have been using the port for
some time now, it's fast and stable and works much better than the
various UNIX ports I have tried on the Raspberry Pi, and most
importantly I'm having a lot of fun learning the Plan 9 operating
system!

Grant

Re: [9fans] Raspberry Pi image

[Richard Miller]

> Thank you for creating the Raspberry Pi port.  I had always wanted to
> use Plan 9, but I was not able to until this port was created, because
> I didn't have any compatible hardware.

Yes, that's why I did it -- to give people a low-cost way to try Plan 9,
and also to give Plan 9 users a way to try the Raspberry Pi.  I'm glad
to know it's been useful.

Re: [9fans] Raspberry Pi image

[Yoann Padioleau]

Yes, thx Richard.

But how this image was produced? just mk in the sys/src/9/bcm/ 
official plan9 distribution or do you have a custom plan9?

On Feb 18, 2014, at 1:05 PM, Richard Miller <9fans@hamnavoe.com>
 wrote:

>> Thank you for creating the Raspberry Pi port.  I had always wanted to
>> use Plan 9, but I was not able to until this port was created, because
>> I didn't have any compatible hardware.
> 
> Yes, that's why I did it -- to give people a low-cost way to try Plan 9,
> and also to give Plan 9 users a way to try the Raspberry Pi.  I'm glad
> to know it's been useful.
> 
> 

Re: [9fans] Raspberry Pi image

[Shane Morris]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

I'd be curious to know the methodology for producing this port as well.
There is a site where a fellow is describing his efforts to port Inferno to
RPi, that is certainly interesting reading... and I haven't checked his
progress in a while, so I should.

Many thanks!

Shane.
On Feb 19, 2014 9:25 AM, "Yoann Padioleau" <pad@fb.com> wrote:

> Yes, thx Richard.
>
> But how this image was produced? just mk in the sys/src/9/bcm/
> official plan9 distribution or do you have a custom plan9?
>
> On Feb 18, 2014, at 1:05 PM, Richard Miller <9fans@hamnavoe.com>
>  wrote:
>
> >> Thank you for creating the Raspberry Pi port.  I had always wanted to
> >> use Plan 9, but I was not able to until this port was created, because
> >> I didn't have any compatible hardware.
> >
> > Yes, that's why I did it -- to give people a low-cost way to try Plan 9,
> > and also to give Plan 9 users a way to try the Raspberry Pi.  I'm glad
> > to know it's been useful.
> >
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 1373 bytes --]

Re: [9fans] Raspberry Pi image

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

Check the 9front wiki.
On Feb 18, 2014 7:15 PM, "Shane Morris" <edgecomberts@gmail.com> wrote:

> I'd be curious to know the methodology for producing this port as well.
> There is a site where a fellow is describing his efforts to port Inferno to
> RPi, that is certainly interesting reading... and I haven't checked his
> progress in a while, so I should.
>
> Many thanks!
>
> Shane.
> On Feb 19, 2014 9:25 AM, "Yoann Padioleau" <pad@fb.com> wrote:
>
>> Yes, thx Richard.
>>
>> But how this image was produced? just mk in the sys/src/9/bcm/
>> official plan9 distribution or do you have a custom plan9?
>>
>> On Feb 18, 2014, at 1:05 PM, Richard Miller <9fans@hamnavoe.com>
>>  wrote:
>>
>> >> Thank you for creating the Raspberry Pi port.  I had always wanted to
>> >> use Plan 9, but I was not able to until this port was created, because
>> >> I didn't have any compatible hardware.
>> >
>> > Yes, that's why I did it -- to give people a low-cost way to try Plan 9,
>> > and also to give Plan 9 users a way to try the Raspberry Pi.  I'm glad
>> > to know it's been useful.
>> >
>> >
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 1757 bytes --]

Re: [9fans] Raspberry Pi image

[Richard Miller]

> 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.

Re: [9fans] Raspberry Pi image

[Shane Morris]

[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]

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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 4464 bytes --]

Re: [9fans] Raspberry Pi image

[erik quanstrom]

On Wed Feb 19 05:16:16 EST 2014, edgecomberts@gmail.com wrote:

> 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.

unfortunately, a port is still a big time commitment even with all the docs.
they get big, and you have to load a large amount of esoteric state into your
brain.  and debugging the early stages takes esoteric skills.  a frequent problem
is trying to debug the inital boot, since most of the easy debugging tools like
print are often not available.

> 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 think you're right, but i've run across devices which shall remain nameless
which claim open source documentation, but when you check there docs
against the linux driver you see they have nothing in common.

cavet emptor.

- erik

Re: [9fans] Raspberry Pi image

[Steven Stallion]

On Wed, Feb 19, 2014 at 4:14 AM, Shane Morris <edgecomberts@gmail.com> wrote:
> 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!

Patience. It's being worked on :)

Steve

Re: [9fans] Raspberry Pi image

[erik quanstrom]

On Thu Feb 20 10:48:19 EST 2014, sstallion@gmail.com wrote:
> On Wed, Feb 19, 2014 at 4:14 AM, Shane Morris <edgecomberts@gmail.com> wrote:
> > 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!
>
> Patience. It's being worked on :)

what about the trimslice?

- erik

Re: [9fans] Raspberry Pi image

[David du Colombier]

> I just think it would be interesting having Plan 9 on a multicore ARM chip

Plan 9 runs on the Trim-Slice, which is running a Tegra 2 (dual-core Cortex-A9).

--
David du Colombier

Re: [9fans] Raspberry Pi image

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 209 bytes --]

On 20 February 2014 15:47, Steven Stallion <sstallion@gmail.com> wrote:

> > I just think it would be interesting having Plan 9 on a multicore ARM
> chip,


/sys/src/9/teg2 is dual core (eg, Trimslice)

[-- Attachment #2: Type: text/html, Size: 497 bytes --]

Re: [9fans] Raspberry Pi image

[Ramakrishnan Muthukrishnan]

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

Re: [9fans] Raspberry Pi image

[Richard Miller]

> But how this image was produced? just mk in the sys/src/9/bcm/
> official plan9 distribution or do you have a custom plan9?

The 9pi image is very standard Plan 9.  Libraries, command binaries
and kernel are all built from distribution sources with
  cd /sys/src && mk install
  cd /sys/src/9/bcm && mk install
For the first, you need to link with the '-f' flag to get hardware
floating point.  That could be done by editing mkfiles, but since I
build for other arm systems from the same sources, I do it by setting
up aliases in my shell environment before running mk -
  fn 5l { /$cputype/bin/5l -f $* }
  fn pcc { /$cputype/bin/pcc -f $* }

The rest of the image is the same as the standard distribution for any
architecture, with x86 binaries and libraries removed, and these small
changes in config files to make an easier introduction for new users
running as 'glenda':

1. The /rc/bin/termrc.local script will optionally start up networking
using the command defined in cmdline.txt variable ipconfig=

2. The /usr/glenda/bin/rc/riostart script adds a console output window
to prevent console messages from messing up the rio desktop

3. The /rc/bin/replica/pull script filters x86 binaries from the update
log, so the replica/pull command won't add them all in again