Re: [9fans] sheevaplug port available
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 profile but hadn't run newuser. I ran it, and then the pull worked. I did have to use the -s sys/src flag, but anyway, all up to date. So looks like having a profile for hostowner is required. Good to know. When rebuilding, I did have to change the permissions on /mail/lib/gone.* in order for 'mk install' to complete, though I suppose I could have added bootes to the upas group... but anyway, thanks all for the help!! -Ben winmail.dat
Re: [9fans] sheevaplug port available
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 replicated; will not update ! sys/src/9/omap/screen.h: not replicated; will not update ! sys/src/9/omap/screen.h: not replicated; will not update ! sys/src/9/omap/devuart.c: not replicated; will not update ! sys/src/9/omap/screen.c: not replicated; will not update Also, I get a bunch of permissions errors, such as the following: error: copying /n/boot/386/9load: '/tmp/replica00098100' permission denied error: copying /n/boot/386/9loadask: '/tmp/replica00098100' permission denied error: copying /n/boot/386/9loaddebug: '/tmp/replica00098100' permission denied 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 honored in the current implementation. 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 bootes? Thanks!! -Ben winmail.dat
Re: [9fans] sheevaplug port available
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 bootes? This is definitely not necessary. My senario at home: I have a single combined cpu/auth/file server, my hostowner is bootes. When I want to do a pull I run cpu -u bootes, as $cpu points to this server I loopback and get a new prompt, but this time as bootes (think of it like the unix su(1) command, though you don't get the console's namespace). I beleive Now I can run pull(1) from /usr/glenda/bin/rc/ and get my updates. 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
Re: [9fans] sheevaplug port available
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 might be awake to guide you. ++L
Re: [9fans] sheevaplug port available
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 honored in the current implementation. 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, e.g. #c, that don't know about groups. - erik
Re: [9fans] sheevaplug port available
On Thu, Oct 21, 2010 at 1:23 AM, Benjamin Huntsman bhunts...@mail2.cu-portland.edu 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
Re: [9fans] sheevaplug port available
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
Re: [9fans] sheevaplug port available
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, e.g. #c, that don't know about groups. - erik 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. 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? Thanks!! -Ben winmail.dat
Re: [9fans] sheevaplug port available
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 that would require a reboot. As I described before, this should not be necessary, and is not for me. just run bull as hostowner, i.e. from your server's console. -Steve
Re: [9fans] sheevaplug port available
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 checking, and the filesystem your files are stored on, which does. 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? steve's right. allow mode is managed by the srv command in fossil. - erik
Re: [9fans] sheevaplug port available
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 hostowner, i.e. from your server's console. -Steve Hmm, I did run pull as the hostowner, and got the errors in the previous post. I'll check the permissions on /tmp, and I bet you're right there. Also though, what about the not replicated; will not update errors? Thanks! -Ben winmail.dat
Re: [9fans] sheevaplug port available
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. In this particular case replica/pull -ssys/src /dist/replica/network should suffice. BTW, /dist/replica/network automatically toogles fossil in -AWP mode in /srv/replica - Yaroslav
Re: [9fans] sheevaplug port available
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
Re: [9fans] sheevaplug port available
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 groups in the expected way. Part of the reason they can easily do so is that they have the file that lists the groups. The in-kernel file servers and many of the user space file servers that don't provide persistent data storage do not fully handle groups. This isn't too surprising since they might well be running without a persistent disk-based file system present. So the fossil file system does use groups, but the server that provides /dev/sd00 does not. BLS
Re: [9fans] sheevaplug port available
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 has been mentioned, ramfs provides a file system that lives in memory and defaults to mounting it on /tmp. So running it will give you a /tmp even without fossil being there. BLS
Re: [9fans] sheevaplug port available
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 doesn't really matter. nobody stores more than boot files in fat. there are also some non-updatable fses that don't support groups such as paqfs, 9660srv, the various tapefs programs that also don't support groups. of these, i can't see how it would be useful, except in the case of paqfs. - erik
Re: [9fans] sheevaplug port available
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 winmail.dat
Re: [9fans] sheevaplug port available
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 bhunts...@mail2.cu-portland.edu wrote: 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
Re: [9fans] sheevaplug port available
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's bin. use that. - erik
Re: [9fans] sheevaplug port available
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 from
source? If so how.
Thanks,
James
Thanks,
James
On Tue, Nov 17, 2009 at 10:37 PM, 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. 9plug is
a diskless cpu server supporting a serial console and gigabit
ethernet. booting(8) and /sys/doc/port.* have been updated to match.
`kw' stands for Kirkwood, the Marvell system-on-a-chip that the
Sheevaplug is based upon. There are more Kirkwood systems on the way.
What's not yet in this port: access to flash memory, USB devices,
memory cards and possibly more. The documentation for Kirkwood flash
and USB is some combination of vague, obscure, incomplete,
unavailable, contradictory and tediously voluminous. If you configure
in the USB drivers, you'll find that there appears to be an
unpopulated root hub, but that may be a figment of the usb driver's
imagination. The EHCI registers do seem to be present and we probably
just need to tweak some undocumented register to make it all go.
If you only been building 386 binaries to date, you'll want to edit
/sys/src/mkfile.proto to at least include the arm architecture:
OS=58
CPUS=arm 386
and make sure all your /386/bin compiler binaries are up to date:
cd /sys/src/cmd
for(i in ?c)
if(! ~ $i cc rc) @{
cd $i
mk clean
objtype=$cputype mk install
mk clean
}
and populate your /arm tree:
cd /sys/src
objtype=arm mk install
You should then be able to build a sheeva kernel:
cd /sys/src/9/kw
mk 'CONF=plug' install # `mk install' will work too
This should create /arm/9plug; see booting(8) to get started.
Enjoy!
Re: [9fans] sheevaplug port available
cd /sys/src/cmd/5a mk install etc. ron
Re: [9fans] sheevaplug port available
Sorry, the second line of my recipe should be for(i in ?[acli])
Re: [9fans] sheevaplug port available
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.
Re: [9fans] sheevaplug port available
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 ...
Re: [9fans] sheevaplug port available
On Tue, Oct 19, 2010 at 12:45 PM, Lyndon Nerenberg lyn...@orthanc.ca 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 binaries. But to get off the ground cross-compiling it helps to have 5c/5a/5l for the 386 as well :-) ron
Re: [9fans] sheevaplug port available
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 = smallest writable/readable unit. Inferno's logfs limits the maximum number of pages per block to 32 because it uses a 32-bit integer bit mapping. The flash you're using, has 64 pages per block. You'll need to switch to vlong and change all the associated bit bashing code. if anyone has tips tricks for dealing with nand flashes, i'm interested in hearing them. one question i have: can you read the erase/program times from the chip? (hard-coding a table with properties based on data sheets isn't so great). another: my new sheevaplug has samsung memory instead of hynix, so a different vendor id in the chip. but the device id is the same (identifying chip properties (size, voltages, etc)). are those device id's standardized? that would make a hard-coded table less annoying at least... NAND flash technology is moving very quickly and new standards will give you timing info. However, the hardware you mention will require you to put the timing numbers in a table. I don't know if device IDs are standardized, so I make no such assumption. For Samsung chips, pure data retention is guaranteed for 10+ years. Repetitive reading, without erasing the blocks is verified to 1E6 cycles. The number of program/erase operations is guaranteed up to 1E6 cycles if the system adopts ECC. I've not seen much agreement with ECC and bad block mapping when it comes to either linux or uboot. There are slabs of NAND specific code in the linux tree that are never used. There are more slabs of code that are used sometimes. You can do whatever you want. I've only dealt with embedded systems and they're all different. Read word size, write size, it's all an experiment to what works. If you're lucky, you can put a probe on a pin and look at a signal but normally it's just trial and error.
Re: [9fans] sheevaplug port available
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.
Re: [9fans] sheevaplug port available
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 real hassle for programmers. If you're feeling lucky, then its a simple extension from random access to page read/write. If you care about reliability, then it's back to ECC generation/checking and bad block mapping and wear leveling and mirroring
Re: [9fans] sheevaplug port available
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: http://code.google.com/p/inferno-kirkwood/source/detail?r=fb12821689bac5589075be3049f4a9413d3dfa54 that was early code that i committed because my sheevaplug was going away (i now have a new one with an esata port on it!). once that code works a better, having a file system on it would be nice. 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. does plan 9 have a writable nand flash file system that does wear-leveling and such? if anyone has tips tricks for dealing with nand flashes, i'm interested in hearing them. one question i have: can you read the erase/program times from the chip? (hard-coding a table with properties based on data sheets isn't so great). another: my new sheevaplug has samsung memory instead of hynix, so a different vendor id in the chip. but the device id is the same (identifying chip properties (size, voltages, etc)). are those device id's standardized? that would make a hard-coded table less annoying at least... mjl
Re: [9fans] sheevaplug port available
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
Re: [9fans] sheevaplug port available
Thank you. It is compiling OK now. On Sun, Feb 28, 2010 at 3:06 PM, ge...@plan9.bell-labs.com wrote: Sorry, I'd forgotten to push /sys/src/9/kw/sdscsi.c to sources. It's fixed now.
Re: [9fans] sheevaplug port available
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?
Re: [9fans] sheevaplug port available
Sorry, I'd forgotten to push /sys/src/9/kw/sdscsi.c to sources. It's fixed now.
Re: [9fans] sheevaplug port available
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, 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.
Re: [9fans] sheevaplug port available
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
Re: [9fans] sheevaplug port available
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.
Re: [9fans] sheevaplug port available
/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
Re: [9fans] sheevaplug port available
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
if (test -e '#r/rtc') @ {
sleep 10# let timesync correct the time
awk '{print $1}' /dev/time '#r/rtc'# fix hw clock
}
}
and then forgot about it until it bit me today when I tried to boot a
new machine. You may want to do the same until this bug is fixed.
Meanwhile, it turns out that the 9plug kernel also runs on the
openrd-client board, which has more peripherals, notably vga and a
second Gb ether.
Re: [9fans] sheevaplug port available
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 adding the directory /acme/bin/arm to the dist. - erik
Re: [9fans] sheevaplug port available
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 instructions: cd /acme objtype=arm mk install sorry for the noise. evidently i wasn't looking where i thought. - erik
[9fans] sheevaplug port available
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 /sys/doc/port.* have been updated to match.
`kw' stands for Kirkwood, the Marvell system-on-a-chip that the
Sheevaplug is based upon. There are more Kirkwood systems on the way.
What's not yet in this port: access to flash memory, USB devices,
memory cards and possibly more. The documentation for Kirkwood flash
and USB is some combination of vague, obscure, incomplete,
unavailable, contradictory and tediously voluminous. If you configure
in the USB drivers, you'll find that there appears to be an
unpopulated root hub, but that may be a figment of the usb driver's
imagination. The EHCI registers do seem to be present and we probably
just need to tweak some undocumented register to make it all go.
If you only been building 386 binaries to date, you'll want to edit
/sys/src/mkfile.proto to at least include the arm architecture:
OS=58
CPUS=arm 386
and make sure all your /386/bin compiler binaries are up to date:
cd /sys/src/cmd
for(i in ?c)
if(! ~ $i cc rc) @{
cd $i
mk clean
objtype=$cputype mk install
mk clean
}
and populate your /arm tree:
cd /sys/src
objtype=arm mk install
You should then be able to build a sheeva kernel:
cd /sys/src/9/kw
mk 'CONF=plug' install # `mk install' will work too
This should create /arm/9plug; see booting(8) to get started.
Enjoy!
Re: [9fans] sheevaplug port available
Awesome! Thanks Geoff!
On Tue, Nov 17, 2009 at 1:37 PM, 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. 9plug is
a diskless cpu server supporting a serial console and gigabit
ethernet. booting(8) and /sys/doc/port.* have been updated to match.
`kw' stands for Kirkwood, the Marvell system-on-a-chip that the
Sheevaplug is based upon. There are more Kirkwood systems on the way.
What's not yet in this port: access to flash memory, USB devices,
memory cards and possibly more. The documentation for Kirkwood flash
and USB is some combination of vague, obscure, incomplete,
unavailable, contradictory and tediously voluminous. If you configure
in the USB drivers, you'll find that there appears to be an
unpopulated root hub, but that may be a figment of the usb driver's
imagination. The EHCI registers do seem to be present and we probably
just need to tweak some undocumented register to make it all go.
If you only been building 386 binaries to date, you'll want to edit
/sys/src/mkfile.proto to at least include the arm architecture:
OS=58
CPUS=arm 386
and make sure all your /386/bin compiler binaries are up to date:
cd /sys/src/cmd
for(i in ?c)
if(! ~ $i cc rc) @{
cd $i
mk clean
objtype=$cputype mk install
mk clean
}
and populate your /arm tree:
cd /sys/src
objtype=arm mk install
You should then be able to build a sheeva kernel:
cd /sys/src/9/kw
mk 'CONF=plug' install # `mk install' will work too
This should create /arm/9plug; see booting(8) to get started.
Enjoy!
Re: [9fans] sheevaplug port available
Great, thats Geoff, My plug is susposed to be on its way... -Steve
Re: [9fans] sheevaplug port available
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 st...@quintile.net wrote: Great, thats Geoff, My plug is susposed to be on its way... -Steve
