If you run replica/pull (or have done so recently), you'll find a new
kernel subtree, /sys/src/9/kw, which contains a basic port of Plan 9
to the Sheevaplug, derived from the port of native Inferno. 9plug is
a diskless cpu server supporting a serial console and gigabit
ethernet. booting(8) and /s
Awesome! Thanks Geoff!
On Tue, Nov 17, 2009 at 1:37 PM, wrote:
> If you run replica/pull (or have done so recently), you'll find a new
> kernel subtree, /sys/src/9/kw, which contains a basic port of Plan 9
> to the Sheevaplug, derived from the port of native Inferno. 9plug is
> a diskless cpu
Great, thats Geoff,
My plug is susposed to be on its way...
-Steve
i am eager to try the port. can someone tell me where i can order the plug?
thanks
dharani
On Tue, Nov 17, 2009 at 2:04 PM, Steve Simon wrote:
> Great, thats Geoff,
>
> My plug is susposed to be on its way...
>
> -Steve
>
>
/acme/bin/arm is already in the distribution. It's empty because we
only ship binaries for the 386 architecture (and that's only so that
installations can bootstrap themselves using PCs). You might want to
add to my earlier instructions:
cd /acme
objtype=arm mk install
I just rediscovered that aux/timesync seems to freeze the stock 9plug
kernel. I don't yet know why. I worked around it weeks ago in
/bin/cpurc with this:
if (! ~ $sysname feared openrd) # timesync seems to kill /sys/src/9/sheeva
if(! ps|grep -s timesync) {
aux/timesync -n pool.ntp.org
On Tue Nov 17 16:38:59 EST 2009, ge...@plan9.bell-labs.com wrote:
> If you run replica/pull (or have done so recently), you'll find a new
> kernel subtree, /sys/src/9/kw, which contains a basic port of Plan 9
> to the Sheevaplug, derived from the port of native Inferno.
great deal. i suggest addi
On Wed Nov 18 18:28:36 EST 2009, ge...@plan9.bell-labs.com wrote:
> /acme/bin/arm is already in the distribution. It's empty because we
> only ship binaries for the 386 architecture (and that's only so that
> installations can bootstrap themselves using PCs). You might want to
> add to my earlier
Has any new work gone into getting the flash, usb, &c working? I was planning on
buying one soon and was wondering about the state of the port.
--
I am a man who does not exist for others.
pgpfxK0JHl4nI.pgp
Description: PGP signature
usb has advanced a little; we can see usb devices now but attempts to
read or write them hang. I don't know of progress on flash access or
anything else.
That's great.
no progress here so far on that front.
It's still on my todo list but not on the top of the stack.
If it's urgent for anyone, let me know.
On Wed, Feb 24, 2010 at 9:22 PM, wrote:
> usb has advanced a little; we can see usb devices now but attempts to
> read or write them hang. I
I tried compiling 9plug kernel and got an error:
mk: no recipe to make 'sdscsi.5' in directory /sys/src/9/kw
Do I need to copy /sys/src/9/pc/sdscsi.c , or edit plug conf file?
Sorry, I'd forgotten to push /sys/src/9/kw/sdscsi.c to sources.
It's fixed now.
Thank you. It is compiling OK now.
On Sun, Feb 28, 2010 at 3:06 PM, wrote:
> Sorry, I'd forgotten to push /sys/src/9/kw/sdscsi.c to sources.
> It's fixed now.
>
>
>
On Wed, Feb 24, 2010 at 03:22:25PM -0500, ge...@plan9.bell-labs.com wrote:
> usb has advanced a little; we can see usb devices now but attempts to
> read or write them hang. I don't know of progress on flash access or
> anything else.
in the inferno port i've been able to access the nand flash:
On Mon, Mar 8, 2010 at 7:42 AM, Mechiel Lukkien wrote:
> On Wed, Feb 24, 2010 at 03:22:25PM -0500, ge...@plan9.bell-labs.com wrote:
> > usb has advanced a little; we can see usb devices now but attempts to
> > read or write them hang. I don't know of progress on flash access or
> > anything else
>
> I thought the flashes themselves were doing wear-leveling these days in most
> products? That's not the case with sheevaplug? Or am I completely
> off-base?
>
there are a lot of embedded-space flashes that don't.
- erik
> but i think inferno's logfs and ftl both assume 512 byte pages instead
> of 2048 byte pages that the sheevaplugs nand flash has (though it has
> writable subpages of 512 bytes), so i'm not sure how hard/easy an fs on
> it will be.
Some NAND flash definitions:
block = smallest erasable unit
page
On Mar 8, 2010, at 16:42 , Mechiel Lukkien wrote:
does plan 9 have a writable nand flash file system that does wear-
leveling
and such?
could that be among the code for the bitsy?
Axel.
>> does plan 9 have a writable nand flash file system that does wear-leveling
>> and such?
>
> could that be among the code for the bitsy?
The Bitsy does it all for NOR flash but sadly NAND flash is more
problematic. NAND flash is cheap and easy for the hardware guys (and
consumers) but it's a rea
Hi,
My attempt to (belatedly) follow the instructions below has been
hindered by the fact that I don't seem to have the arm assembler 5a on
my i386 plan 9 system.
ls /bin/?c yields lots of compilers
ls /bin/?a yields only 0a and 8a.
Is 5a supposed to be there by default or should I build it fro
cd /sys/src/cmd/5a
mk install
etc.
ron
Sorry, the second line of my recipe should be
for(i in ?[acli])
On 10-10-19 12:21 PM, ron minnich wrote:
> cd /sys/src/cmd/5a
> mk install
If he's missing 5a there are probably other bits missing, too, so:
cd /sys/src
objtype = arm
mk install
is a safer bet.
On 10-10-19 12:50 PM, ron minnich wrote:
> yes for the arm binaries. But to get off the ground cross-compiling it
> helps to have 5c/5a/5l for the 386 as well :-)
Oh sh*t. I'm going back to bed now ...
On Tue, Oct 19, 2010 at 12:45 PM, Lyndon Nerenberg wrote:
> On 10-10-19 12:21 PM, ron minnich wrote:
>> cd /sys/src/cmd/5a
>> mk install
>
> If he's missing 5a there are probably other bits missing, too, so:
>
> cd /sys/src
> objtype = arm
> mk install
>
> is a safer bet.
yes for the arm binar
Speaking of which, what is the "official" method of staying up to date these
days,
especially on a combined CPU/auth server? I keep getting various permission
errors
if I do 'replica/pull /dist/replica network', even on freshly-installed
systems...
Thanks much!!
-Ben
<>
if you have a login on sources with the same user-id as your plan9,
your factotum should use your sources credentials to log in; otherwise
something like:
% 9fs sources
should just work. i think this is also true of bootes id.
-Skip
On Wed, Oct 20, 2010 at 1:11 PM, Benjamin Huntsman
wrote:
> S
> Speaking of which, what is the "official" method of staying up to date these
> days,
> especially on a combined CPU/auth server? I keep getting various permission
> errors
> if I do 'replica/pull /dist/replica network', even on freshly-installed
> systems...
there is a pull script in glenda
>there is a pull script in glenda's bin. use that.
>
>- erik
I was giving that a shot, but get a few errors. Looks like it's not pulling
new files:
! sys/src/cmd/ratrace.c: not replicated; will not update
! sys/src/9/kw/devtwsi.c: not replicated; will not update
! sys/src/9/omap/screen.c: not
> error: copying /n/boot/386/9load: '/tmp/replica00098100' permission denied
Not somthing as trivial as you have no /tmp? (its usually bound to $home/tmp in
profile).
> So is the proper thing to do to convert a new install to a cpu/file server
> (fossil)
> to change ownership of all files to bo
You might want to look at /tmp, you may not have a writable one from
the login. Executing "ramfs" normally takes care of that issue.
I saw the "ratrace.c" error this early morning, but it seems to have
been transient. I guess you ought to try a second time, by then somebody
more savvy than me m
> This is on a combined CPU/auth server, and was run as the hostowner (bootes).
> Are the permissions wrong out-of-the-box? Could this be because some
> directories
> are owned by sys while others by bootes? bootes is a member of the sys
> group, but
> as we discussed previously, that won't be
On Thu, Oct 21, 2010 at 1:23 AM, Benjamin Huntsman
wrote:
>bootes is a member of the sys group, but
> as we discussed previously, that won't be honored in the current
> implementation.
I'm pretty sure we did not say anything like that.
ron
The most effective way I've found to build from sources is to use
mercurial. The second most effective way is replica.
I have found I quite enjoy building from and hacking on a sources tree
backed by mercurial. YMMV.
ron
>this is almost certainly incorrect. (you don't mention you're using 9vx' #Z.)
>plan 9 fileservers that store files on disk (fossil, kfs, kenfs, cwfs, etc) do
>maintain their own groups. you may wish to put your fs into allow mode
>for pull.
>
>it's plan 9 file servers living in the local kernel,
> >you may wish to put your fs into allow mode for pull.
> You can do that on fossil? I thought you had to have kfs for that?
I don't believe you can simply switch fossil into and out of allow mode,
you can specify -P to open to disable permission checking (enable allow)
see fossilcons(8) but tha
> Wasn't that what we found just last week regarding the /dev/sd00/nvram thing?
> This is
> on native Plan 9, (er, under VMware), not 9vx or anything like that. The
> filesystem is
> fossil, not kfs.
i think you are confusing the block filesystem served by #S, which
does not do (real) group ch
>I don't believe you can simply switch fossil into and out of allow mode,
>you can specify -P to open to disable permission checking (enable allow)
>see fossilcons(8) but that would require a reboot.
>
>As I described before, this should not be necessary, and is not for me.
>just run bull as hostow
>> sys/src/9/omap/screen.c: not replicated; will not update
>
> I wonder if your replica databases have got in a mess? Somone whith more
> nous of replicas internals may be able to help there.
>
> -Steve
Local replica DB mismatches can be handled like pull conflicts: with
either -s path or -c path
I think it worths to mention: for convenience, run as hostworner once:
cd
mkdir lib/replica
cp -x /dist/replica/network lib/replica/sys
Since then, pulls can be done as easy as "replica/pull -v sys"
- Yaroslav
> Wasn't that what we found just last week regarding the
> /dev/sd00/nvram thing? This is
> on native Plan 9, (er, under VMware), not 9vx or anything
> like that. The filesystem is
> fossil, not kfs.
The file servers that maintain on-disk file systems
like kfs, fossil, kenfs, etc. all do use gro
> I'll check the permissions on /tmp, and I bet you're right
> there.
There's a good chance your /tmp issue is not permissions,
but a lack of /tmp being mounted. If your hostowner
doesn't have a lib/profile or its lib/profile doesn't
mount /tmp, then you won't be able to write anything
to it. As
> The file servers that maintain on-disk file systems
> like kfs, fossil, kenfs, etc. all do use groups in
> the expected way.
yes. but there are obscure exceptions.
dossrv is fully updatable, but doesn't bother with groups.
but of course that's cheating. fat doesn't even support users.
and it
>There's a good chance your /tmp issue is not permissions,
>but a lack of /tmp being mounted. If your hostowner
>doesn't have a lib/profile or its lib/profile doesn't
>mount /tmp, then you won't be able to write anything
>to it.
Ah! That's probably it. My hostowner definitely doesn't have a pro
>There's a good chance your /tmp issue is not permissions,
>but a lack of /tmp being mounted. If your hostowner
>doesn't have a lib/profile or its lib/profile doesn't
>mount /tmp, then you won't be able to write anything
>to it.
That was definitely it. I had been logging into the hostowner profi
46 matches
Mail list logo
