[9fans] porting plan9

[9fans] porting plan9

[Michael Grunditz]

Hi

Is there a arm plan9 kernel ? I want to port plan9 to the RiscPC
platform.

Best regards

--
Michael Grunditz

System Software Engineer
E-mail: michael.grunditz@imt.im.se
Office direct:  +46 8 448 04 92
Office general: +46 8 448 04 50
Mobile:         +46 709 54 61 54
Industri-Matematik International
Web:  http://www.im.se
_______________________________________________________
IMI Industri-Matematik International
  THE ORDER COMPANY
_______________________________________________________

Re: [9fans] Porting plan9

[yoann padioleau]

I think one of the reason 9load is quite complicated is because
they wanted to boot a kernel from the network, so you need a network stack and the drivers for the ethernet card, so you really need lots of OS code in the end.

On Dec 2, 2014, at 2:28 PM, Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net> wrote:

> On 02.12.2014 23:02, Iruatã Souza wrote:
> 
>>> apropos kernel/bootloader: I just recently had a look at the code
>>> and somewhat got the impression that 9load seems to be a specially
>>> tailored plan9 kernel, which then loads the real kernel.
>>> 
>>> is that correct or am I mistaken here ?
>> 
>> Correct.
> 
> hmm, interesting.
> 
> What's the exact reason behind that ?
> 
> I'm really not an expert for bootloaders, but I always got the
> impression, that bootloaders need to be extremly minimal (eg. on
> PC you'll have only about 0.5k for the first stage) and serve an
> entirely different purpose than an OS kernel.
> 
> OTOH, having a complete OS/Kernel as preboot environment of course
> also has it's charm - allows easily adding lots of setup things,
> even rescue stuff, etc.
> 
> Can 9front also boot other operating systems, eg. Linux ?
> Could it become a replacement for other bootloaders like grub ?
> 
> 
> cu
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
> 

Re: [9fans] Porting plan9

[Iruatã Souza]

as far as I can remember, Plan 9 (Bell Labs) as 9load expect each other.
9front, on the other hand, got rid of 9load for its own good.

On Tue, Dec 2, 2014 at 8:28 PM, Enrico Weigelt, metux IT consult
<enrico.weigelt@gr13.net> wrote:
> On 02.12.2014 23:02, Iruatã Souza wrote:
>
>>> apropos kernel/bootloader: I just recently had a look at the code
>>> and somewhat got the impression that 9load seems to be a specially
>>> tailored plan9 kernel, which then loads the real kernel.
>>>
>>> is that correct or am I mistaken here ?
>>
>> Correct.
>
> hmm, interesting.
>
> What's the exact reason behind that ?
>
> I'm really not an expert for bootloaders, but I always got the
> impression, that bootloaders need to be extremly minimal (eg. on
> PC you'll have only about 0.5k for the first stage) and serve an
> entirely different purpose than an OS kernel.
>
> OTOH, having a complete OS/Kernel as preboot environment of course
> also has it's charm - allows easily adding lots of setup things,
> even rescue stuff, etc.
>
> Can 9front also boot other operating systems, eg. Linux ?
> Could it become a replacement for other bootloaders like grub ?
>
>
> cu
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
>

Re: [9fans] Porting plan9

[Enrico Weigelt, metux IT consult]

On 02.12.2014 23:02, Iruatã Souza wrote:

>> apropos kernel/bootloader: I just recently had a look at the code
>> and somewhat got the impression that 9load seems to be a specially
>> tailored plan9 kernel, which then loads the real kernel.
>>
>> is that correct or am I mistaken here ?
> 
> Correct.

hmm, interesting.

What's the exact reason behind that ?

I'm really not an expert for bootloaders, but I always got the
impression, that bootloaders need to be extremly minimal (eg. on
PC you'll have only about 0.5k for the first stage) and serve an
entirely different purpose than an OS kernel.

OTOH, having a complete OS/Kernel as preboot environment of course
also has it's charm - allows easily adding lots of setup things,
even rescue stuff, etc.

Can 9front also boot other operating systems, eg. Linux ?
Could it become a replacement for other bootloaders like grub ?


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287

Re: [9fans] Porting plan9

[Iruatã Souza]

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

Em 02/12/2014 19:59, "Enrico Weigelt, metux IT consult" <
enrico.weigelt@gr13.net> escreveu:
>
> On 02.12.2014 16:21, Steven Stallion wrote:
>
> <snip>
>
> apropos kernel/bootloader: I just recently had a look at the code
> and somewhat got the impression that 9load seems to be a specially
> tailored plan9 kernel, which then loads the real kernel.
>
> is that correct or am I mistaken here ?
>
>
> cu
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
>

Correct.

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

Re: [9fans] Porting plan9

[Enrico Weigelt, metux IT consult]

On 02.12.2014 16:21, Steven Stallion wrote:

<snip>

apropos kernel/bootloader: I just recently had a look at the code
and somewhat got the impression that 9load seems to be a specially
tailored plan9 kernel, which then loads the real kernel.

is that correct or am I mistaken here ?


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287

Re: [9fans] Porting plan9

[Steven Stallion]

On Tue, Dec 2, 2014 at 8:10 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> One of the functions u-boot performs is configuring the various subsystems
>> in the SoC (individual clocks and power settings for subcomponents, gpio
>> pin functions, ...) -- things a BIOS would do in a more old-timey computer.
>> In my experience these are typically undocumented (or worse, incorrectly
>> documented), so doing this initialisation in Plan 9 would require reverse
>> engineering of u-boot to figure out what to do.  It's easier just to be
>> lazy and let u-boot do it.
>
> that's interesting.  with the marvell chip and board i had, there was almost no
> setup code required.  and what setup code there was, the hardware guy had got
> wrong.

That project was a little different. Off the shelf SoC's (particularly
those targeted for mobile) usually have firmware blobs that have to be
loaded at specific addresses, (undocumented) clock trees, signed stage
1 loaders, and other bits. Many times, using u-boot is your only
choice. You can pick apart the source if you like, but honestly why do
the work? I'm more interested in porting the kernel than writing a
bootloader. Frankly, purity in a software system only exists if you've
also designed the hardware.

Steve

Re: [9fans] Porting plan9

[erik quanstrom]

> One of the functions u-boot performs is configuring the various subsystems
> in the SoC (individual clocks and power settings for subcomponents, gpio
> pin functions, ...) -- things a BIOS would do in a more old-timey computer.
> In my experience these are typically undocumented (or worse, incorrectly
> documented), so doing this initialisation in Plan 9 would require reverse
> engineering of u-boot to figure out what to do.  It's easier just to be
> lazy and let u-boot do it.

that's interesting.  with the marvell chip and board i had, there was almost no
setup code required.  and what setup code there was, the hardware guy had got
wrong.

- erik

Re: [9fans] Porting plan9

[mischief]

by 'ci ap' i meant cinap_lenrek.

Re: [9fans] Porting plan9

[mischief]

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

UEFI support was written for 9front by ci ap. It has been tested on the x230 and in OVMF. I have an working gpt editor but it needs cleanup.

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

Re: [9fans] Porting plan9

[Jens Staal]

On Tuesday 02 December 2014 09:32:22 Richard Miller wrote:
> It's easier just to be
> lazy and let u-boot do it.

Sorry for hijacking a bit. There was a mention on this list a couple of months
ago about work on getting Plan9 working on UEFI/GPT machines...

whoever that was - any progress?

Re: [9fans] Porting plan9

[Richard Miller]

quanstro@quanstro.net:
> u-boot has several drawbacks that have hindered my development
> ...
> i worked on an embedded pcie endpoint, and all these factors cost
> me 4-5 weeks of dev time, time enough that i could have brought the
> board up myself directly with plan 9 as a bootloader in tht amount of
> time.

One of the functions u-boot performs is configuring the various subsystems
in the SoC (individual clocks and power settings for subcomponents, gpio
pin functions, ...) -- things a BIOS would do in a more old-timey computer.
In my experience these are typically undocumented (or worse, incorrectly
documented), so doing this initialisation in Plan 9 would require reverse
engineering of u-boot to figure out what to do.  It's easier just to be
lazy and let u-boot do it.

Re: [9fans] Porting plan9

[erik quanstrom]

> I took Steve's point to be that I don't get to have an opinion
> because he's never seen me in his playground before, but I figured
> it would be more productive to focus on the fact that uboot sucks
> rather than an exercise in disregarding personal experience because
> Steve told me to.

i didn't see that to be steve's point.  but, whatever.  if you can assume it's
not personal, it's probablly better that way.  :-)

btw, u-boot sucks mucky pigs feat and stinks of pickled eggs.

- erik

Re: [9fans] Porting plan9

[Kurt H Maier]

Quoting erik quanstrom <quanstro@quanstro.net>:

>
> while i don't agree that u-boot is nice, i do agree with steve's point,
> which i understood to be that hardware is messy, and it's hard to write
> software that isn't a tad messy to deal with this.  steve has a lot
> of experience
> with hardware, and knows what he's talking about.
>
> - erik

I took Steve's point to be that I don't get to have an opinion
because he's never seen me in his playground before, but I figured
it would be more productive to focus on the fact that uboot sucks
rather than an exercise in disregarding personal experience because
Steve told me to.

khm

Re: [9fans] Porting plan9

[erik quanstrom]

On Mon Dec  1 20:00:59 PST 2014, khm@sciops.net wrote:
> Quoting Steven Stallion <sstallion@gmail.com>:
>
> > Clearly you've never worked on hardware.
>
> No, thank Christ, my conscience is clean.  Instead I work on
> software, and uboot is a fine example of "well it builds on my
> laptop" development paradigms.  Plenty glad I don't have to
> screw with such nonsense any more, and even more glad the company
> I work for has got out of the habit of compensating for bad hw
> designs by spackling things over with "it builds, ship it" code.

while i don't agree that u-boot is nice, i do agree with steve's point,
which i understood to be that hardware is messy, and it's hard to write
software that isn't a tad messy to deal with this.  steve has a lot of experience
with hardware, and knows what he's talking about.

- erik

Re: [9fans] Porting plan9

[Kurt H Maier]

Quoting Steven Stallion <sstallion@gmail.com>:

> Clearly you've never worked on hardware.

No, thank Christ, my conscience is clean.  Instead I work on
software, and uboot is a fine example of "well it builds on my
laptop" development paradigms.  Plenty glad I don't have to
screw with such nonsense any more, and even more glad the company
I work for has got out of the habit of compensating for bad hw
designs by spackling things over with "it builds, ship it" code.

khm

Re: [9fans] Porting plan9

[Steven Stallion]

On Mon, Dec 1, 2014 at 8:42 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> On Mon, 01 Dec 2014 15:54:36 CST Steven Stallion <sstallion@gmail.com> wrote:
>>
>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>> boot significantly - there is zero reason to eschew the functionality
>> it brings.
>
> Do you think it is worth adding support for "flattened device
> tree" (a data structure that describes system hardware)?  IIRC
> uboot already supports FDT.  Supposedly FDT reduces the
> porting effort and more than one system may even be able to
> use the same kernel (but with a different FDT).

I looked into it at the time. FDT makes more sense for targets that
have dynamically addressable peripherals (think PCI et al.) For an
SoC, you're dealing with fixed addresses, so there is very little gain
in this context.

Steve

Re: [9fans] Porting plan9

[erik quanstrom]

> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.

i don't think this is a full accounting of the situation.

u-boot has several drawbacks that have hindered my development
(a) there are many of versions, the mainline will probablly not work
on your special device, and further
(b) it often depends on a very special version of gcc,
(c) it is full of #ifdefs and vendor code that's hard to read,
(d) it is very slow, thus if you need to boot quickly, it might not work
for you.

i worked on an embedded pcie endpoint, and all these factors cost
me 4-5 weeks of dev time, time enough that i could have brought the
board up myself directly with plan 9 as a bootloader in tht amount of
time.

certainly, this is preferrable, no?

- erik

Re: [9fans] Porting plan9

[Bakul Shah]

On Mon, 01 Dec 2014 15:54:36 CST Steven Stallion <sstallion@gmail.com> wrote:
>
> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.

Do you think it is worth adding support for "flattened device
tree" (a data structure that describes system hardware)?  IIRC
uboot already supports FDT.  Supposedly FDT reduces the
porting effort and more than one system may even be able to
use the same kernel (but with a different FDT).

Re: [9fans] Porting plan9

[Skip Tavakkolian]

Where is the +1 on this whatchamajig?

Sent from my iPhone

> On Dec 1, 2014, at 6:16 PM, Steven Stallion <sstallion@gmail.com> wrote:
>
>> On Mon, Dec 1, 2014 at 6:56 PM, Kurt H Maier <khm@sciops.net> wrote:
>> Quoting Steven Stallion <sstallion@gmail.com>:
>>
>>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>>> boot significantly - there is zero reason to eschew the functionality
>>> it brings.
>>
>> Instead, I'll recommend eschewing hardware that requires circus tricks to
>> load a kernel.
>
> Clearly you've never worked on hardware.
>

Re: [9fans] Porting plan9

[Steven Stallion]

On Mon, Dec 1, 2014 at 6:56 PM, Kurt H Maier <khm@sciops.net> wrote:
> Quoting Steven Stallion <sstallion@gmail.com>:
>
>> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
>> boot significantly - there is zero reason to eschew the functionality
>> it brings.
>
> Instead, I'll recommend eschewing hardware that requires circus tricks to
> load a kernel.

Clearly you've never worked on hardware.

Re: [9fans] Porting plan9

[Kurt H Maier]

Quoting Steven Stallion <sstallion@gmail.com>:

> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.

Instead, I'll recommend eschewing hardware that requires circus tricks to
load a kernel.

khm

Re: [9fans] Porting plan9

[Ramakrishnan Muthukrishnan]

On Tue, Dec 2, 2014, at 03:24 AM, Steven Stallion wrote:
> They do. In fact, I contributed a patch a while back to add u-boot
> image support to 5l a while back. U-boot has also been patched to
> expect these binaries. You can take a look at what has been done in
> the Chromebook port (http://code.google.com/p/9chrome), but I've been
> stalled due to demands at the office.
>
> FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
> boot significantly - there is zero reason to eschew the functionality
> it brings.
>
> http://plan9.bell-labs.com/sources/contrib/stallion/patch/arm-uboot/
>
> HTH,

Thanks. That is very helpful. I will look at your patches.

Ramakrishnan

> On Mon, Dec 1, 2014 at 2:43 AM, Ramakrishnan Muthukrishnan
> <ram@rkrishnan.org> wrote:
> > On Mon, Dec 1, 2014, at 11:14 AM, erik quanstrom wrote:
> >> > Surprisingly I didn't see a paper on porting Plan9 to new architectures
> >> > in the plan9 paper collection. Any help and pointers on how to get
> >> > started with the porting effort will be highly appreciated.
> >>
> >> it's all about the documentation.  if you can get it, boringing up a new
> >> kernel for a new architecture can go from impossible to very doable.
> >> it's still a lot of work, and it can be hard to sit down and spend a week
> >> finding that one little bit that prevents anything from working.  good
> >> luck, nonetheless.  more architectures is definately moar better.
> >
> > Thanks. IMX6 documentation is freely available. There is a version of
> > u-boot. The manufacturer (Solid Run) also has made the board schematics
> > etc available.
> >
> > From the reading of booting(8), I am assuming that the ARM devices in
> > plan9 use the u-boot for booting the kernel up?
> >
>

Re: [9fans] Porting plan9

[Steven Stallion]

They do. In fact, I contributed a patch a while back to add u-boot
image support to 5l a while back. U-boot has also been patched to
expect these binaries. You can take a look at what has been done in
the Chromebook port (http://code.google.com/p/9chrome), but I've been
stalled due to demands at the office.

FWIW, u-boot is not a net-negative at all. For SoC's it simplifies
boot significantly - there is zero reason to eschew the functionality
it brings.

http://plan9.bell-labs.com/sources/contrib/stallion/patch/arm-uboot/

HTH,

Steve

On Mon, Dec 1, 2014 at 2:43 AM, Ramakrishnan Muthukrishnan
<ram@rkrishnan.org> wrote:
> On Mon, Dec 1, 2014, at 11:14 AM, erik quanstrom wrote:
>> > Surprisingly I didn't see a paper on porting Plan9 to new architectures
>> > in the plan9 paper collection. Any help and pointers on how to get
>> > started with the porting effort will be highly appreciated.
>>
>> it's all about the documentation.  if you can get it, boringing up a new
>> kernel for a new architecture can go from impossible to very doable.
>> it's still a lot of work, and it can be hard to sit down and spend a week
>> finding that one little bit that prevents anything from working.  good
>> luck, nonetheless.  more architectures is definately moar better.
>
> Thanks. IMX6 documentation is freely available. There is a version of
> u-boot. The manufacturer (Solid Run) also has made the board schematics
> etc available.
>
> From the reading of booting(8), I am assuming that the ARM devices in
> plan9 use the u-boot for booting the kernel up?
>

Re: [9fans] Porting plan9

[erik quanstrom]

> Thanks. IMX6 documentation is freely available. There is a version of
> u-boot. The manufacturer (Solid Run) also has made the board schematics
> etc available.
>
>  From the reading of booting(8), I am assuming that the ARM devices in
> plan9 use the u-boot for booting the kernel up?

some do.  u-boot is definately a net negative.  but not  a disaster.
(u-boot is much bigger than plan 9!)

- erik

Re: [9fans] Porting plan9

[Ramakrishnan Muthukrishnan]

On Mon, Dec 1, 2014, at 11:14 AM, erik quanstrom wrote:
> > Surprisingly I didn't see a paper on porting Plan9 to new architectures
> > in the plan9 paper collection. Any help and pointers on how to get
> > started with the porting effort will be highly appreciated.
>
> it's all about the documentation.  if you can get it, boringing up a new
> kernel for a new architecture can go from impossible to very doable.
> it's still a lot of work, and it can be hard to sit down and spend a week
> finding that one little bit that prevents anything from working.  good
> luck, nonetheless.  more architectures is definately moar better.

Thanks. IMX6 documentation is freely available. There is a version of
u-boot. The manufacturer (Solid Run) also has made the board schematics
etc available.

>From the reading of booting(8), I am assuming that the ARM devices in
plan9 use the u-boot for booting the kernel up?

Re: [9fans] Porting plan9

[erik quanstrom]

> Surprisingly I didn't see a paper on porting Plan9 to new architectures
> in the plan9 paper collection. Any help and pointers on how to get
> started with the porting effort will be highly appreciated.

it's all about the documentation.  if you can get it, boringing up a new
kernel for a new architecture can go from impossible to very doable.
it's still a lot of work, and it can be hard to sit down and spend a week
finding that one little bit that prevents anything from working.  good
luck, nonetheless.  more architectures is definately moar better.

- erik

[9fans] Porting plan9

[Ramakrishnan Muthukrishnan]

Hi,

I have a hummingboard i1 board [1] which I would like to use as a Plan9
terminal. I also want to use the opportunity to learn about the plan9
kernel and read the code. The board has a FreeScale iMX6 Solo SoC which
is based on ARM-Cortex A9 core. I am hoping to reuse parts of the OMAP3
port (though it is Cortex-A8) and intend to look at the boot process of
the chip in more detail in the coming days.

Surprisingly I didn't see a paper on porting Plan9 to new architectures
in the plan9 paper collection. Any help and pointers on how to get
started with the porting effort will be highly appreciated.

[1] http://www.solid-run.com/product/hummingboard-i1/

Ramakrishnan

Re: [9fans] porting plan9

[Michael Grunditz]

In message <20020124011934.20D7C19A27@mail.cse.psu.edu> you wrote:

> i thought it was an ARM7500.
>
> i can dredge up the a7000  inferno code if that would be useful.
>
>

My riscpc is acorn branded with a strongarm cpu. But If you have
bootstraping code that works on an a7000 , then it sholdnt be any
problems at all.

--
Michael Grunditz

System Software Engineer
E-mail: michael.grunditz@imt.im.se
Office direct:  +46 8 448 04 92
Office general: +46 8 448 04 50
Mobile:         +46 709 54 61 54
Industri-Matematik International
Web:  http://www.im.se
_______________________________________________________
IMI Industri-Matematik International
  THE ORDER COMPANY
_______________________________________________________

Re: [9fans] porting plan9

[forsyth]

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

i thought it was an ARM7500.

i can dredge up the a7000  inferno code if that would be useful.


[-- Attachment #2: Type: message/rfc822, Size: 1639 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] porting plan9
Date: Wed, 23 Jan 2002 19:45:06 -0500
Message-ID: <20020124004508.39DF019A63@mail.cse.psu.edu>

On Wed Jan 23 18:03:34 EST 2002, micken@privat.utfors.se wrote:
> Hi
>
> Is there a arm plan9 kernel ? I want to port plan9 to the RiscPC
> platform.
>
> Best regards
>
> --
> Michael Grunditz

What hardware is a RiscPC? The original ARM work we did was on an
Acorn machine, we ported Inferno.

Re: [9fans] porting plan9

[jmk]

On Wed Jan 23 18:03:34 EST 2002, micken@privat.utfors.se wrote:
> Hi
>
> Is there a arm plan9 kernel ? I want to port plan9 to the RiscPC
> platform.
>
> Best regards
>
> --
> Michael Grunditz

What hardware is a RiscPC? The original ARM work we did was on an
Acorn machine, we ported Inferno.

Re: [9fans] porting plan9

[anothy]

there is. plan 9 runs on the Compaq iPAQ (the little
handheld thingie, not the internet appliance). it's a
SA1100 (i think).
ア