[9fans] plan 9 on the guruplug

[9fans] plan 9 on the guruplug

[David Leimbach]

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

Just got one of these today, and I suspect my problem has nothing to do with
the guruplug and everything to do with the fact that I've never set up any
PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.

I'm getting
"ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp, linkion
refused"

I'm thinking that I don't have / either exported in a way I know how to use
it remotely or that I have another fundamental configuration issue.

I'm wondering if there's a way to use either Inferno or the same plan 9
installation to test whatever needs testing to validate that I'll be able to
remotely boot my guruplug.

Dave

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

Re: [9fans] plan 9 on the guruplug

[erik quanstrom]

> Just got one of these today, and I suspect my problem has nothing to do with
> the guruplug and everything to do with the fact that I've never set up any
> PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
>
> I'm getting
> "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp, linkion
> refused"
>
> I'm thinking that I don't have / either exported in a way I know how to use
> it remotely or that I have another fundamental configuration issue.
>
> I'm wondering if there's a way to use either Inferno or the same plan 9
> installation to test whatever needs testing to validate that I'll be able to
> remotely boot my guruplug.

once you've validated that you have a reasonable
ipnet in /lib/ndb/local covering your network (that's
been my problem many times; verify with ndb/ipquery
especially that you have a fs= entry), and you've tried
adding -Dd to bootargs (adding verbosity to
ip/ipconfig), i usually starting hacking in debug
messages to /sys/src/9/boot, to taste, until
i can reduce things down to a nice consummé.

if you're loading the kernel, you've gotten pretty far,
so it sounds like dhcp/tftpd themselves are properly
configured.

bon appitit.

- julia child

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Just got one of these today, and I suspect my problem has nothing to do
> with
> > the guruplug and everything to do with the fact that I've never set up
> any
> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
> >
> > I'm getting
> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp, linkion
> > refused"
> >
> > I'm thinking that I don't have / either exported in a way I know how to
> use
> > it remotely or that I have another fundamental configuration issue.
> >
> > I'm wondering if there's a way to use either Inferno or the same plan 9
> > installation to test whatever needs testing to validate that I'll be able
> to
> > remotely boot my guruplug.
>
> once you've validated that you have a reasonable
> ipnet in /lib/ndb/local covering your network (that's
> been my problem many times; verify with ndb/ipquery
> especially that you have a fs= entry), and you've tried
> adding -Dd to bootargs (adding verbosity to
> ip/ipconfig), i usually starting hacking in debug
> messages to /sys/src/9/boot, to taste, until
> i can reduce things down to a nice consummé.
>
> if you're loading the kernel, you've gotten pretty far,
> so it sounds like dhcp/tftpd themselves are properly
> configured.
>

Yes, the kernel loads, and prompts me for an IP for a filesystem.  I enter
one, and it goes through authid, authdom, secstore and password prompts,
then it dumps me off into kdumpland

"ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
linkion refused"

It was pretty easy to get it this far.  I'm just wondering if I have my
filesystem server set up the way I originally thought, and if there is a way
to do some basic test of that.

Example, can I attach an Inferno OS to my Plan 9 to validate if other Plan 9
instances *should* work.

Dave


>
> bon appitit.
>
> - julia child
>
>

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

Re: [9fans] plan 9 on the guruplug

[Skip Tavakkolian]

do you compile in an nvram (that includes the correct rights?)

> On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <quanstro@quanstro.net>wrote:
>
>> > Just got one of these today, and I suspect my problem has nothing to do
>> with
>> > the guruplug and everything to do with the fact that I've never set up
>> any
>> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
>> >
>> > I'm getting
>> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp, linkion
>> > refused"
>> >
>> > I'm thinking that I don't have / either exported in a way I know how to
>> use
>> > it remotely or that I have another fundamental configuration issue.
>> >
>> > I'm wondering if there's a way to use either Inferno or the same plan 9
>> > installation to test whatever needs testing to validate that I'll be able
>> to
>> > remotely boot my guruplug.
>>
>> once you've validated that you have a reasonable
>> ipnet in /lib/ndb/local covering your network (that's
>> been my problem many times; verify with ndb/ipquery
>> especially that you have a fs= entry), and you've tried
>> adding -Dd to bootargs (adding verbosity to
>> ip/ipconfig), i usually starting hacking in debug
>> messages to /sys/src/9/boot, to taste, until
>> i can reduce things down to a nice consummé.
>>
>> if you're loading the kernel, you've gotten pretty far,
>> so it sounds like dhcp/tftpd themselves are properly
>> configured.
>>
>
> Yes, the kernel loads, and prompts me for an IP for a filesystem.  I enter
> one, and it goes through authid, authdom, secstore and password prompts,
> then it dumps me off into kdumpland
>
> "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
> linkion refused"
>
> It was pretty easy to get it this far.  I'm just wondering if I have my
> filesystem server set up the way I originally thought, and if there is a way
> to do some basic test of that.
>
> Example, can I attach an Inferno OS to my Plan 9 to validate if other Plan 9
> instances *should* work.
>
> Dave
>
>
>>
>> bon appitit.
>>
>> - julia child
>>
>>

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

I just built the CONF=plug

Let me see what that includes.  Maybe my sources are just really old.

Dave

On Mon, Aug 30, 2010 at 8:46 PM, Skip Tavakkolian <9nut@9netics.com> wrote:

> do you compile in an nvram (that includes the correct rights?)
>
> > On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <quanstro@quanstro.net
> >wrote:
> >
> >> > Just got one of these today, and I suspect my problem has nothing to
> do
> >> with
> >> > the guruplug and everything to do with the fact that I've never set up
> >> any
> >> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
> >> >
> >> > I'm getting
> >> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
> linkion
> >> > refused"
> >> >
> >> > I'm thinking that I don't have / either exported in a way I know how
> to
> >> use
> >> > it remotely or that I have another fundamental configuration issue.
> >> >
> >> > I'm wondering if there's a way to use either Inferno or the same plan
> 9
> >> > installation to test whatever needs testing to validate that I'll be
> able
> >> to
> >> > remotely boot my guruplug.
> >>
> >> once you've validated that you have a reasonable
> >> ipnet in /lib/ndb/local covering your network (that's
> >> been my problem many times; verify with ndb/ipquery
> >> especially that you have a fs= entry), and you've tried
> >> adding -Dd to bootargs (adding verbosity to
> >> ip/ipconfig), i usually starting hacking in debug
> >> messages to /sys/src/9/boot, to taste, until
> >> i can reduce things down to a nice consummé.
> >>
> >> if you're loading the kernel, you've gotten pretty far,
> >> so it sounds like dhcp/tftpd themselves are properly
> >> configured.
> >>
> >
> > Yes, the kernel loads, and prompts me for an IP for a filesystem.  I
> enter
> > one, and it goes through authid, authdom, secstore and password prompts,
> > then it dumps me off into kdumpland
> >
> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
> > linkion refused"
> >
> > It was pretty easy to get it this far.  I'm just wondering if I have my
> > filesystem server set up the way I originally thought, and if there is a
> way
> > to do some basic test of that.
> >
> > Example, can I attach an Inferno OS to my Plan 9 to validate if other
> Plan 9
> > instances *should* work.
> >
> > Dave
> >
> >
> >>
> >> bon appitit.
> >>
> >> - julia child
> >>
> >>
>
>
>

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

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

plug included nvram, so I'm not sure what's going on.  Still trying to
figure out if I should just be able to mount this thing from another machine
to test.

On Mon, Aug 30, 2010 at 8:48 PM, David Leimbach <leimy2k@gmail.com> wrote:

> I just built the CONF=plug
>
> Let me see what that includes.  Maybe my sources are just really old.
>
> Dave
>
>
> On Mon, Aug 30, 2010 at 8:46 PM, Skip Tavakkolian <9nut@9netics.com>wrote:
>
>> do you compile in an nvram (that includes the correct rights?)
>>
>> > On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <quanstro@quanstro.net
>> >wrote:
>> >
>> >> > Just got one of these today, and I suspect my problem has nothing to
>> do
>> >> with
>> >> > the guruplug and everything to do with the fact that I've never set
>> up
>> >> any
>> >> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
>> >> >
>> >> > I'm getting
>> >> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>> linkion
>> >> > refused"
>> >> >
>> >> > I'm thinking that I don't have / either exported in a way I know how
>> to
>> >> use
>> >> > it remotely or that I have another fundamental configuration issue.
>> >> >
>> >> > I'm wondering if there's a way to use either Inferno or the same plan
>> 9
>> >> > installation to test whatever needs testing to validate that I'll be
>> able
>> >> to
>> >> > remotely boot my guruplug.
>> >>
>> >> once you've validated that you have a reasonable
>> >> ipnet in /lib/ndb/local covering your network (that's
>> >> been my problem many times; verify with ndb/ipquery
>> >> especially that you have a fs= entry), and you've tried
>> >> adding -Dd to bootargs (adding verbosity to
>> >> ip/ipconfig), i usually starting hacking in debug
>> >> messages to /sys/src/9/boot, to taste, until
>> >> i can reduce things down to a nice consummé.
>> >>
>> >> if you're loading the kernel, you've gotten pretty far,
>> >> so it sounds like dhcp/tftpd themselves are properly
>> >> configured.
>> >>
>> >
>> > Yes, the kernel loads, and prompts me for an IP for a filesystem.  I
>> enter
>> > one, and it goes through authid, authdom, secstore and password prompts,
>> > then it dumps me off into kdumpland
>> >
>> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>> > linkion refused"
>> >
>> > It was pretty easy to get it this far.  I'm just wondering if I have my
>> > filesystem server set up the way I originally thought, and if there is a
>> way
>> > to do some basic test of that.
>> >
>> > Example, can I attach an Inferno OS to my Plan 9 to validate if other
>> Plan 9
>> > instances *should* work.
>> >
>> > Dave
>> >
>> >
>> >>
>> >> bon appitit.
>> >>
>> >> - julia child
>> >>
>> >>
>>
>>
>>
>

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

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

The part that confuses me right now is the following set of comments in the
plug configuration file with respect to flash and nvram.

Do I need nvram or not?  nvram appears to be where my boot process dies.


bootdir
boot$CONF.out boot
/arm/bin/ip/ipconfig
/arm/bin/auth/factotum
# /arm/bin/paqfs
/arm/bin/usb/usbd
# nvram not needed any longer, it's in flash
nvram

link
ether1116 ethermii
archkw
ethermedium
# no flash yet for guruplug
flashkw ecc
loopbackmedium
netdevmedium
usbehci

# sheeva plug, openrd-client, guruplug and others
# based on marvell's kirkwood soc
dev
root
cons
env
pipe
proc
mnt
srv
dup
rtc
arch
ssl
tls
cap
kprof
aoe
sd
flash
# pnp pci

ether netif
ip arp chandial ip ipv6 ipaux iproute netlog nullmedium pktmedium ptclbsum
inferno

## draw screen vga vgax
## mouse mouse
## vga
# kbmap
## kbin

uart
usb


On Mon, Aug 30, 2010 at 8:52 PM, David Leimbach <leimy2k@gmail.com> wrote:

> plug included nvram, so I'm not sure what's going on.  Still trying to
> figure out if I should just be able to mount this thing from another machine
> to test.
>
>
> On Mon, Aug 30, 2010 at 8:48 PM, David Leimbach <leimy2k@gmail.com> wrote:
>
>> I just built the CONF=plug
>>
>> Let me see what that includes.  Maybe my sources are just really old.
>>
>> Dave
>>
>>
>> On Mon, Aug 30, 2010 at 8:46 PM, Skip Tavakkolian <9nut@9netics.com>wrote:
>>
>>> do you compile in an nvram (that includes the correct rights?)
>>>
>>> > On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <quanstro@quanstro.net
>>> >wrote:
>>> >
>>> >> > Just got one of these today, and I suspect my problem has nothing to
>>> do
>>> >> with
>>> >> > the guruplug and everything to do with the fact that I've never set
>>> up
>>> >> any
>>> >> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
>>> >> >
>>> >> > I'm getting
>>> >> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>>> linkion
>>> >> > refused"
>>> >> >
>>> >> > I'm thinking that I don't have / either exported in a way I know how
>>> to
>>> >> use
>>> >> > it remotely or that I have another fundamental configuration issue.
>>> >> >
>>> >> > I'm wondering if there's a way to use either Inferno or the same
>>> plan 9
>>> >> > installation to test whatever needs testing to validate that I'll be
>>> able
>>> >> to
>>> >> > remotely boot my guruplug.
>>> >>
>>> >> once you've validated that you have a reasonable
>>> >> ipnet in /lib/ndb/local covering your network (that's
>>> >> been my problem many times; verify with ndb/ipquery
>>> >> especially that you have a fs= entry), and you've tried
>>> >> adding -Dd to bootargs (adding verbosity to
>>> >> ip/ipconfig), i usually starting hacking in debug
>>> >> messages to /sys/src/9/boot, to taste, until
>>> >> i can reduce things down to a nice consummé.
>>> >>
>>> >> if you're loading the kernel, you've gotten pretty far,
>>> >> so it sounds like dhcp/tftpd themselves are properly
>>> >> configured.
>>> >>
>>> >
>>> > Yes, the kernel loads, and prompts me for an IP for a filesystem.  I
>>> enter
>>> > one, and it goes through authid, authdom, secstore and password
>>> prompts,
>>> > then it dumps me off into kdumpland
>>> >
>>> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>>> > linkion refused"
>>> >
>>> > It was pretty easy to get it this far.  I'm just wondering if I have my
>>> > filesystem server set up the way I originally thought, and if there is
>>> a way
>>> > to do some basic test of that.
>>> >
>>> > Example, can I attach an Inferno OS to my Plan 9 to validate if other
>>> Plan 9
>>> > instances *should* work.
>>> >
>>> > Dave
>>> >
>>> >
>>> >>
>>> >> bon appitit.
>>> >>
>>> >> - julia child
>>> >>
>>> >>
>>>
>>>
>>>
>>
>

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

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

I found something on a french Plan 9 translation site about dd'ing my nvram
from my PC to a file in /sys/src/9/kw then building.

This seems to have gotten me past the point where it crashes because it
can't write to nvram, but it crashes all the same anyway :-)

Marvell>> setenv bootcmd 'dhcp 0x800000; tftp 0x1000 /cfg/pxe/f0ad4eff148b;
go 0x800000'
Marvell>> boot
BOOTP broadcast 1
DHCP client bound to address 192.168.1.77
Using egiga0 device
TFTP from server 192.168.1.250; our IP address is 192.168.1.77
Filename '/arm/9plug'.
Load address: 0x800000
Loading: #################################################################
         ##########################
done
Bytes transferred = 1331184 (144ff0 hex)
Using egiga0 device
TFTP from server 192.168.1.250; our IP address is 192.168.1.77
Filename '/cfg/pxe/f0ad4eff148b'.
Load address: 0x1000
Loading: #
done
Bytes transferred = 121 (79 hex)
## Starting application at 0x00800000 ...

Plan 9 from Bell Labs

l1 D: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-through only
l1 I: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-back type `reg 7
ops, format C' (016) possible
l2 cache: 256K or 512K: 4 ways, 32-byte lines, write-back, sdram only
cpu0: 1200MHz ARM Marvell 88F6281 A1; arm926ej-s arch v5te rev 2.1 part 131
#F0: kwnand: Samsung 2Gb 536,870,912 bytes pagesize 2048 erasesize 131,072
spares per page 64
#F0: nand addr 0xd8000000 len 536870912 width 1 interleave 0
#l0: 88e1116: 100Mbps port 0xf1072000 irq 11: f0ad4eff148b
#l1: 88e1116: 100Mbps port 0xf1076000 irq 15: f0ad4eff148c
#u/usb/ep1.0: ehci: port 0XF1050100 irq 19
504M memory: 52M kernel data, 452M user, 1959M swap
usb/hub... filesystem IP address[no default]: 192.168.1.250
authentication server IP address[no default]: 192.168.1.250
bootpanic: boot process died: unknown
ktrace /kernel/path 0x60806f14 0x6099ff50 0x6099ff8d # pc, sp, linkion
refused

panic: boot process died: unknown
cpu0: exiting
reset!




On Mon, Aug 30, 2010 at 11:43 PM, David Leimbach <leimy2k@gmail.com> wrote:

> The part that confuses me right now is the following set of comments in the
> plug configuration file with respect to flash and nvram.
>
> Do I need nvram or not?  nvram appears to be where my boot process dies.
>
>
> bootdir
> boot$CONF.out boot
> /arm/bin/ip/ipconfig
>  /arm/bin/auth/factotum
> # /arm/bin/paqfs
> /arm/bin/usb/usbd
> # nvram not needed any longer, it's in flash
> nvram
>
> link
> ether1116 ethermii
>  archkw
> ethermedium
> # no flash yet for guruplug
> flashkw ecc
>  loopbackmedium
> netdevmedium
> usbehci
>
> # sheeva plug, openrd-client, guruplug and others
> # based on marvell's kirkwood soc
> dev
> root
>  cons
> env
> pipe
>  proc
> mnt
> srv
>  dup
> rtc
> arch
>  ssl
> tls
> cap
>  kprof
> aoe
> sd
>  flash
> # pnp pci
>
> ether netif
> ip arp chandial ip ipv6 ipaux iproute netlog nullmedium pktmedium ptclbsum
> inferno
>
> ## draw screen vga vgax
> ## mouse mouse
> ## vga
> # kbmap
> ## kbin
>
> uart
> usb
>
>
> On Mon, Aug 30, 2010 at 8:52 PM, David Leimbach <leimy2k@gmail.com> wrote:
>
>> plug included nvram, so I'm not sure what's going on.  Still trying to
>> figure out if I should just be able to mount this thing from another machine
>> to test.
>>
>>
>> On Mon, Aug 30, 2010 at 8:48 PM, David Leimbach <leimy2k@gmail.com>wrote:
>>
>>> I just built the CONF=plug
>>>
>>> Let me see what that includes.  Maybe my sources are just really old.
>>>
>>> Dave
>>>
>>>
>>> On Mon, Aug 30, 2010 at 8:46 PM, Skip Tavakkolian <9nut@9netics.com>wrote:
>>>
>>>> do you compile in an nvram (that includes the correct rights?)
>>>>
>>>> > On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <
>>>> quanstro@quanstro.net>wrote:
>>>> >
>>>> >> > Just got one of these today, and I suspect my problem has nothing
>>>> to do
>>>> >> with
>>>> >> > the guruplug and everything to do with the fact that I've never set
>>>> up
>>>> >> any
>>>> >> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
>>>> >> >
>>>> >> > I'm getting
>>>> >> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>>>> linkion
>>>> >> > refused"
>>>> >> >
>>>> >> > I'm thinking that I don't have / either exported in a way I know
>>>> how to
>>>> >> use
>>>> >> > it remotely or that I have another fundamental configuration issue.
>>>> >> >
>>>> >> > I'm wondering if there's a way to use either Inferno or the same
>>>> plan 9
>>>> >> > installation to test whatever needs testing to validate that I'll
>>>> be able
>>>> >> to
>>>> >> > remotely boot my guruplug.
>>>> >>
>>>> >> once you've validated that you have a reasonable
>>>> >> ipnet in /lib/ndb/local covering your network (that's
>>>> >> been my problem many times; verify with ndb/ipquery
>>>> >> especially that you have a fs= entry), and you've tried
>>>> >> adding -Dd to bootargs (adding verbosity to
>>>> >> ip/ipconfig), i usually starting hacking in debug
>>>> >> messages to /sys/src/9/boot, to taste, until
>>>> >> i can reduce things down to a nice consummé.
>>>> >>
>>>> >> if you're loading the kernel, you've gotten pretty far,
>>>> >> so it sounds like dhcp/tftpd themselves are properly
>>>> >> configured.
>>>> >>
>>>> >
>>>> > Yes, the kernel loads, and prompts me for an IP for a filesystem.  I
>>>> enter
>>>> > one, and it goes through authid, authdom, secstore and password
>>>> prompts,
>>>> > then it dumps me off into kdumpland
>>>> >
>>>> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>>>> > linkion refused"
>>>> >
>>>> > It was pretty easy to get it this far.  I'm just wondering if I have
>>>> my
>>>> > filesystem server set up the way I originally thought, and if there is
>>>> a way
>>>> > to do some basic test of that.
>>>> >
>>>> > Example, can I attach an Inferno OS to my Plan 9 to validate if other
>>>> Plan 9
>>>> > instances *should* work.
>>>> >
>>>> > Dave
>>>> >
>>>> >
>>>> >>
>>>> >> bon appitit.
>>>> >>
>>>> >> - julia child
>>>> >>
>>>> >>
>>>>
>>>>
>>>>
>>>
>>
>

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

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

Ok, now I can't remember what I just did, but it's working.



On Mon, Aug 30, 2010 at 11:59 PM, David Leimbach <leimy2k@gmail.com> wrote:

> I found something on a french Plan 9 translation site about dd'ing my nvram
> from my PC to a file in /sys/src/9/kw then building.
>
> This seems to have gotten me past the point where it crashes because it
> can't write to nvram, but it crashes all the same anyway :-)
>
> Marvell>> setenv bootcmd 'dhcp 0x800000; tftp 0x1000 /cfg/pxe/f0ad4eff148b;
> go 0x800000'
> Marvell>> boot
> BOOTP broadcast 1
> DHCP client bound to address 192.168.1.77
> Using egiga0 device
> TFTP from server 192.168.1.250; our IP address is 192.168.1.77
> Filename '/arm/9plug'.
> Load address: 0x800000
> Loading: #################################################################
>          ##########################
> done
> Bytes transferred = 1331184 (144ff0 hex)
> Using egiga0 device
> TFTP from server 192.168.1.250; our IP address is 192.168.1.77
> Filename '/cfg/pxe/f0ad4eff148b'.
> Load address: 0x1000
> Loading: #
> done
> Bytes transferred = 121 (79 hex)
> ## Starting application at 0x00800000 ...
>
> Plan 9 from Bell Labs
>
> l1 D: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-through only
> l1 I: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-back type `reg 7
> ops, format C' (016) possible
> l2 cache: 256K or 512K: 4 ways, 32-byte lines, write-back, sdram only
> cpu0: 1200MHz ARM Marvell 88F6281 A1; arm926ej-s arch v5te rev 2.1 part 131
> #F0: kwnand: Samsung 2Gb 536,870,912 bytes pagesize 2048 erasesize 131,072
> spares per page 64
> #F0: nand addr 0xd8000000 len 536870912 width 1 interleave 0
> #l0: 88e1116: 100Mbps port 0xf1072000 irq 11: f0ad4eff148b
> #l1: 88e1116: 100Mbps port 0xf1076000 irq 15: f0ad4eff148c
> #u/usb/ep1.0: ehci: port 0XF1050100 irq 19
> 504M memory: 52M kernel data, 452M user, 1959M swap
> usb/hub... filesystem IP address[no default]: 192.168.1.250
> authentication server IP address[no default]: 192.168.1.250
> bootpanic: boot process died: unknown
> ktrace /kernel/path 0x60806f14 0x6099ff50 0x6099ff8d # pc, sp, linkion
> refused
>
> panic: boot process died: unknown
> cpu0: exiting
> reset!
>
>
>
>
> On Mon, Aug 30, 2010 at 11:43 PM, David Leimbach <leimy2k@gmail.com>wrote:
>
>> The part that confuses me right now is the following set of comments in
>> the plug configuration file with respect to flash and nvram.
>>
>> Do I need nvram or not?  nvram appears to be where my boot process dies.
>>
>>
>> bootdir
>> boot$CONF.out boot
>> /arm/bin/ip/ipconfig
>>  /arm/bin/auth/factotum
>> # /arm/bin/paqfs
>> /arm/bin/usb/usbd
>> # nvram not needed any longer, it's in flash
>> nvram
>>
>> link
>> ether1116 ethermii
>>  archkw
>> ethermedium
>> # no flash yet for guruplug
>> flashkw ecc
>>  loopbackmedium
>> netdevmedium
>> usbehci
>>
>> # sheeva plug, openrd-client, guruplug and others
>> # based on marvell's kirkwood soc
>> dev
>> root
>>  cons
>> env
>> pipe
>>  proc
>> mnt
>> srv
>>  dup
>> rtc
>> arch
>>  ssl
>> tls
>> cap
>>  kprof
>> aoe
>> sd
>>  flash
>> # pnp pci
>>
>> ether netif
>> ip arp chandial ip ipv6 ipaux iproute netlog nullmedium pktmedium
>> ptclbsum inferno
>>
>> ## draw screen vga vgax
>> ## mouse mouse
>> ## vga
>> # kbmap
>> ## kbin
>>
>> uart
>> usb
>>
>>
>> On Mon, Aug 30, 2010 at 8:52 PM, David Leimbach <leimy2k@gmail.com>wrote:
>>
>>> plug included nvram, so I'm not sure what's going on.  Still trying to
>>> figure out if I should just be able to mount this thing from another machine
>>> to test.
>>>
>>>
>>> On Mon, Aug 30, 2010 at 8:48 PM, David Leimbach <leimy2k@gmail.com>wrote:
>>>
>>>> I just built the CONF=plug
>>>>
>>>> Let me see what that includes.  Maybe my sources are just really old.
>>>>
>>>> Dave
>>>>
>>>>
>>>> On Mon, Aug 30, 2010 at 8:46 PM, Skip Tavakkolian <9nut@9netics.com>wrote:
>>>>
>>>>> do you compile in an nvram (that includes the correct rights?)
>>>>>
>>>>> > On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <
>>>>> quanstro@quanstro.net>wrote:
>>>>> >
>>>>> >> > Just got one of these today, and I suspect my problem has nothing
>>>>> to do
>>>>> >> with
>>>>> >> > the guruplug and everything to do with the fact that I've never
>>>>> set up
>>>>> >> any
>>>>> >> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
>>>>> >> >
>>>>> >> > I'm getting
>>>>> >> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>>>>> linkion
>>>>> >> > refused"
>>>>> >> >
>>>>> >> > I'm thinking that I don't have / either exported in a way I know
>>>>> how to
>>>>> >> use
>>>>> >> > it remotely or that I have another fundamental configuration
>>>>> issue.
>>>>> >> >
>>>>> >> > I'm wondering if there's a way to use either Inferno or the same
>>>>> plan 9
>>>>> >> > installation to test whatever needs testing to validate that I'll
>>>>> be able
>>>>> >> to
>>>>> >> > remotely boot my guruplug.
>>>>> >>
>>>>> >> once you've validated that you have a reasonable
>>>>> >> ipnet in /lib/ndb/local covering your network (that's
>>>>> >> been my problem many times; verify with ndb/ipquery
>>>>> >> especially that you have a fs= entry), and you've tried
>>>>> >> adding -Dd to bootargs (adding verbosity to
>>>>> >> ip/ipconfig), i usually starting hacking in debug
>>>>> >> messages to /sys/src/9/boot, to taste, until
>>>>> >> i can reduce things down to a nice consummé.
>>>>> >>
>>>>> >> if you're loading the kernel, you've gotten pretty far,
>>>>> >> so it sounds like dhcp/tftpd themselves are properly
>>>>> >> configured.
>>>>> >>
>>>>> >
>>>>> > Yes, the kernel loads, and prompts me for an IP for a filesystem.  I
>>>>> enter
>>>>> > one, and it goes through authid, authdom, secstore and password
>>>>> prompts,
>>>>> > then it dumps me off into kdumpland
>>>>> >
>>>>> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>>>>> > linkion refused"
>>>>> >
>>>>> > It was pretty easy to get it this far.  I'm just wondering if I have
>>>>> my
>>>>> > filesystem server set up the way I originally thought, and if there
>>>>> is a way
>>>>> > to do some basic test of that.
>>>>> >
>>>>> > Example, can I attach an Inferno OS to my Plan 9 to validate if other
>>>>> Plan 9
>>>>> > instances *should* work.
>>>>> >
>>>>> > Dave
>>>>> >
>>>>> >
>>>>> >>
>>>>> >> bon appitit.
>>>>> >>
>>>>> >> - julia child
>>>>> >>
>>>>> >>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

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

Re: [9fans] plan 9 on the guruplug

[erik quanstrom]

On Tue Aug 31 03:27:52 EDT 2010, leimy2k@gmail.com wrote:

> Ok, now I can't remember what I just did, but it's working.
>
>
>
> On Mon, Aug 30, 2010 at 11:59 PM, David Leimbach <leimy2k@gmail.com> wrote:
>
> > I found something on a french Plan 9 translation site about dd'ing my nvram
> > from my PC to a file in /sys/src/9/kw then building.
> >
> > This seems to have gotten me past the point where it crashes because it
> > can't write to nvram, but it crashes all the same anyway :-)

is there any chance that you either haven't resync'd
/sys/src/libauthsrv/readnvram.c or that you haven't rebuilt
your kernel or other auth-related stuff since this change?

Jul 23 18:49:34 EDT 2010 /n/sourcesdump/2010/0726/plan9/sys/src/libauthsrv/readnvram.c 10695 [geoff]
47a48
> 	"power", "#F/flash/flash", 0x440000, sizeof(Nvrsafe),
50a52
> 	"arm", "#F/flash/flash", 0x100000, sizeof(Nvrsafe),

- erik

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

On Tue, Aug 31, 2010 at 6:07 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Tue Aug 31 03:27:52 EDT 2010, leimy2k@gmail.com wrote:
>
> > Ok, now I can't remember what I just did, but it's working.
> >
> >
> >
> > On Mon, Aug 30, 2010 at 11:59 PM, David Leimbach <leimy2k@gmail.com>
> wrote:
> >
> > > I found something on a french Plan 9 translation site about dd'ing my
> nvram
> > > from my PC to a file in /sys/src/9/kw then building.
> > >
> > > This seems to have gotten me past the point where it crashes because it
> > > can't write to nvram, but it crashes all the same anyway :-)
>
> is there any chance that you either haven't resync'd
> /sys/src/libauthsrv/readnvram.c or that you haven't rebuilt
> your kernel or other auth-related stuff since this change?
>
> Jul 23 18:49:34 EDT 2010
> /n/sourcesdump/2010/0726/plan9/sys/src/libauthsrv/readnvram.c 10695 [geoff]
> 47a48
> >       "power", "#F/flash/flash", 0x440000, sizeof(Nvrsafe),
> 50a52
> >       "arm", "#F/flash/flash", 0x100000, sizeof(Nvrsafe),
>
> - erik
>

I decided to blow everything away last night and start over, including the
Plan 9 CPU server I am pxe booting from.   The plan 9 installation I worked
from was from the ISO available last night.

Looking over my notes it appears the only thing I had to do to prevent the
crash was enable my fossil FS's listening capabilities.  Now the guruplug
gets a kernel and an FS every time.

I'm probably going to plan 9 wikify my notes either tonight or tomorrow.

Dave

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

Re: [9fans] plan 9 on the guruplug

[David du Colombier]

> Looking over my notes it appears the only thing I had to do to prevent the
> crash was enable my fossil FS's listening capabilities.  Now the guruplug
> gets a kernel and an FS every time.

Yes, if you don't make fossil listening on port 564/tcp, this error appear.
It is a common oversight, when you are not accustomed to enable
unencrypted connection to 9P.

> I'm probably going to plan 9 wikify my notes either tonight or tomorrow.

I am probably the author of the documentation you find on some french
Plan 9 website. I didn't think it was worth writing it on the Plan 9 wiki at
the time, but I encourage you to do it now as it will be obviously helpful
to others.

--
David du Colombier

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

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

On Tue, Aug 31, 2010 at 11:19 AM, David du Colombier <0intro@gmail.com>wrote:

> > Looking over my notes it appears the only thing I had to do to prevent
> the
> > crash was enable my fossil FS's listening capabilities.  Now the guruplug
> > gets a kernel and an FS every time.
>
> Yes, if you don't make fossil listening on port 564/tcp, this error appear.
> It is a common oversight, when you are not accustomed to enable
> unencrypted connection to 9P.
>

That's why I kept asking over and over again if there was a good way for me
to test that I set my CPUFSAUTH server up properly before I started asking
questions about the Sheevaplug port.


>
> > I'm probably going to plan 9 wikify my notes either tonight or tomorrow.
>
> I am probably the author of the documentation you find on some french
> Plan 9 website. I didn't think it was worth writing it on the Plan 9 wiki
> at
> the time, but I encourage you to do it now as it will be obviously helpful
> to others.
>
>
Yes it was very helpful to me to see a boiled down list of steps that make
this work.   The only difference I think I have from your notes is my TFTP
U-Boot string is a lot shorter and seems to work ok.

I think the Sheeva/Guru platform is very interesting to work with.  It'd be
even more so if anyone ever makes U-SNAP capable appliances.  Also their is
an announced DisplayPlug that comes with either HDMI or a touchscreen
interface that could make for a nice Plan 9 terminal for some programs
potentially.

I could see having these all over my house at some point.

Dave


> --
> David du Colombier
>
>

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

Re: [9fans] plan 9 on the guruplug

[hiro]

> I could see having these all over my house at some point.

I'm having bad luck with my light bulbs lately. There are no
replacements in the shop either and I'm still waiting for my guruscrew
(ingenious light bulb form factor) to arrive.
But when they come they will be everywhere.

Re: [9fans] plan 9 on the guruplug

[Christian Neukirchen]

leimy2k@gmail.com (David Leimbach) writes:

> # sheeva plug, openrd-client, guruplug and others

Did anyone already try plan9 (or inferno?) on the Seagate Dockstar?
These litte boxes are really cheap currently.

--
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: [9fans] plan 9 on the guruplug

[David Leimbach]

On Monday, August 30, 2010, Skip Tavakkolian <9nut@9netics.com> wrote:
> do you compile in an nvram (that includes the correct rights?)
>
Yeah, I dd'd the one from my boot disk on the CPU server.

>> On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom <quanstro@quanstro.net>wrote:
>>
>>> > Just got one of these today, and I suspect my problem has nothing to do
>>> with
>>> > the guruplug and everything to do with the fact that I've never set up
>>> any
>>> > PXE bootable systems before to mount a Plan 9 CPUAUTHFS service.
>>> >
>>> > I'm getting
>>> > "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp, linkion
>>> > refused"
>>> >
>>> > I'm thinking that I don't have / either exported in a way I know how to
>>> use
>>> > it remotely or that I have another fundamental configuration issue.
>>> >
>>> > I'm wondering if there's a way to use either Inferno or the same plan 9
>>> > installation to test whatever needs testing to validate that I'll be able
>>> to
>>> > remotely boot my guruplug.
>>>
>>> once you've validated that you have a reasonable
>>> ipnet in /lib/ndb/local covering your network (that's
>>> been my problem many times; verify with ndb/ipquery
>>> especially that you have a fs= entry), and you've tried
>>> adding -Dd to bootargs (adding verbosity to
>>> ip/ipconfig), i usually starting hacking in debug
>>> messages to /sys/src/9/boot, to taste, until
>>> i can reduce things down to a nice consummé.
>>>
>>> if you're loading the kernel, you've gotten pretty far,
>>> so it sounds like dhcp/tftpd themselves are properly
>>> configured.
>>>
>>
>> Yes, the kernel loads, and prompts me for an IP for a filesystem.  I enter
>> one, and it goes through authid, authdom, secstore and password prompts,
>> then it dumps me off into kdumpland
>>
>> "ktrace /kernel/path 0x60806f34 0x6095cf30 0x6095cf6d # pc, sp,
>> linkion refused"
>>
>> It was pretty easy to get it this far.  I'm just wondering if I have my
>> filesystem server set up the way I originally thought, and if there is a way
>> to do some basic test of that.
>>
>> Example, can I attach an Inferno OS to my Plan 9 to validate if other Plan 9
>> instances *should* work.
>>
>> Dave
>>
>>
>>>
>>> bon appitit.
>>>
>>> - julia child
>>>
>>>
>
>
>