Interesting. Speaking of odd bits. Just noticed that devether does qbwrite not
pass. Why? It defeats TCP congestion CTL.
- erik
Richard Miller <9f...@hamnavoe.com> wrote:
>quans...@quanstro.net wrote:
>> i really do like your cc malloc, though. very clean.
>
>Actually I've just noticed that
quans...@quanstro.net wrote:
> i really do like your cc malloc, though. very clean.
Actually I've just noticed that my ccmalloc() function just duplicates
what the standard mallocalign() already does. So I've removed it from
the yet-to-be-applied sdmmc-driver patch.
Blocks are intended for IO.
On 19 October 2012 22:49, erik quanstrom wrote:
> Block*s (well at least the buffer)
> needs to be special because the ethernet on the marvell is not
> cache coherent.
>
On Fri Oct 19 17:31:50 EDT 2012, charles.fors...@gmail.com wrote:
> I think it's better to specify memory that must have special cache
> properties, rather than assuming that everything is.
this depends on the ratio of memory that has special cache
properties to the memory that doesn't. if you h
I think it's better to specify memory that must have special cache
properties, rather than assuming that everything is.
> kw-style caches (16-byte lines)
mem.h says it's 32. But yeah, it's not much.
> i had to look twice to verify i understood the pointer orthodontics.
Correctness proof (or refutation) is left as an exercise for the reader...
> Or you can look in /n/sources/patch/sdmmc-driver.
Thanks, will do. Time to dust off the Plug again. Thank you.
++L
On Fri Oct 19 11:40:41 EDT 2012, 9f...@hamnavoe.com wrote:
> > easiest to just
> > cacheline-align everything in malloc
>
> Might be a good idea for ARM. Until someone produces a
> chip with gigantic cache lines?
>
> Another alternative might be to have a separate pool of
> uncached memory.
i'm
comment it out and uncomment the line above.
On Fri, Oct 19, 2012 at 8:21 AM, wrote:
>> /n/sources/contrib/miller/9/kw
>
> in "plug":
>
> I see you use /usr/miller/bin/arm/usbd, is there something special in
> it?
>
> Also, "paq" reappears, do we want it, or is it just leftover?
>
> rip
> easiest to just
> cacheline-align everything in malloc
Might be a good idea for ARM. Until someone produces a
chip with gigantic cache lines?
Another alternative might be to have a separate pool of
uncached memory.
>> /n/sources/contrib/miller/9/kw
>
> in "plug":
>
> I see you use /usr/miller/bin/arm/usbd, is there something special in
> it?
>
> Also, "paq" reappears, do we want it, or is it just leftover?
Sorry, this was leakage from my own experiments. I've now
replaced that plug config with a standard
On Fri Oct 19 10:01:11 EDT 2012, 9f...@hamnavoe.com wrote:
> > could you explain the ccmalloc trick?
>
> "cache coherent malloc" - not really a trick, just a way to
> ensure SD buffers are cache-aligned and occupy an integral
> number of cache lines, to avoid embarrassment when doing
> dma on AR
> /n/sources/contrib/miller/9/kw
in "plug":
I see you use /usr/miller/bin/arm/usbd, is there something special in
it?
Also, "paq" reappears, do we want it, or is it just leftover?
ripple# diff plug /n/sources/contrib/miller/9/kw/plug
59a60
> sdmmc sdio
> could you explain the ccmalloc trick?
"cache coherent malloc" - not really a trick, just a way to
ensure SD buffers are cache-aligned and occupy an integral
number of cache lines, to avoid embarrassment when doing
dma on ARM (which bypasses the cache). It costs a bit of
space but saves copyin
On Fri Oct 19 09:37:40 EDT 2012, 9f...@hamnavoe.com wrote:
> > it works
> > like a charm.
>
> Thanks. Patch sdmmc-driver now submitted.
could you explain the ccmalloc trick?
- erik
> it works
> like a charm.
Thanks. Patch sdmmc-driver now submitted.
Thanks!!! I plan to try it out on sheeva and guru later today.
On Thu, Oct 18, 2012 at 5:42 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> As a side effect of the raspberry pi work, I've produced an SD card
> driver for the sheevaplug (and presumably other kirkwood platforms).
> It's in two sec
> Would anyone with a sheevaplug or similar, and a collection of SD
> cards, like to try it out before I submit a patch?
I just tried with various 2 GB to 16 GB Kingston SD and
microSD (with adapter) cards on my SheevaPlug and it works
like a charm.
Thanks for your very nice work.
--
David du C
On Thu, Oct 18, 2012 at 2:42 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> As a side effect of the raspberry pi work, I've produced an SD card
> driver for the sheevaplug (and presumably other kirkwood platforms).
> It's in two sections: the top layer does the card protocol and is
> identical be
> Be aware that sometimes if the jtag isn't used early enough after
> booting it will not respond.
> Though, if there is not light in the ethernet, it sounds like it is fried...
both lights are solid on and it is not very warm.
- erik
On Sun, Jan 16, 2011 at 9:02 PM, erik quanstrom wrote:
> On Sun Jan 16 14:58:33 EST 2011, pau...@gmail.com wrote:
>> Yes there is :-). It is another endpoint in the usb. I would try going at it
>> with openocd. My jtag driver doesn't do reflashing yet.
>>
>
> ocd, catatonic. we're goign to have
Another possibility -- the omap "on chip" firmware will use SD-based
uboot image if it finds it, instead of flash. If the plug plays by the
same rules, you might be able to put a known-good u-boot on an SD and
use that image.
Marvell chips lack that. TI and Samsung were a tad more thoughtful.
On Sat, Jan 15, 2011 at 03:09:50PM -0500, erik quanstrom wrote:
> has anyone else had a sheevaplug go catatonic?
> mine reset yesterday and now no longer responds
> to the usb/serial interface and the ethernet lights
> are stuck.
After one year of working, in mine some power supply capacitors blew
On Sun Jan 16 14:58:33 EST 2011, pau...@gmail.com wrote:
> Yes there is :-). It is another endpoint in the usb. I would try going at it
> with openocd. My jtag driver doesn't do reflashing yet.
>
ocd, catatonic. we're goign to have to choose one. :-)
thanks for the info. i'll take a look.
-
no output from uboot at all. no output of any kind.
Assuming it isn't hardware death the only option I can see is re-flashing.
i haven't cracked the case. does anyone know if there's
a jtag port at all in a sheevaplug?
Even if there's no ready-to-use JTAG port on the board on the PCB there
On Sun, Jan 16, 2011 at 11:41 AM, erik quanstrom wrote:
> i haven't cracked the case. does anyone know if there's
> a jtag port at all in a sheevaplug?
Another possibility -- the omap "on chip" firmware will use SD-based
uboot image if it finds it, instead of flash. If the plug plays by the
sam
On Sun, Jan 16, 2011 at 02:41:57PM -0500, erik quanstrom wrote:
> i haven't cracked the case. does anyone know if there's
> a jtag port at all in a sheevaplug?
There is. I've used it to debug Linux boots with openocd.
The FTDI chip at the the USB-device connector should show you two serial ports.
Yes there is :-). It is another endpoint in the usb. I would try going at it
with openocd. My jtag driver doesn't do reflashing yet.
-
Curiosity sKilled the cat
G.
On Jan 16, 2011, at 8:41 PM, erik quanstrom wrote:
> On Sun Jan 16 14:38:27 EST 2011, eris.discor...@gmail.com wrote:
>> Is it co
On Sun Jan 16 14:38:27 EST 2011, eris.discor...@gmail.com wrote:
> Is it configured to use a serial console? Tried checking the output there?
yes. that's how i set it up to pxe from the auth server.
> What's the output from uBoot, if any? As a last resort, tried re-flashing
> it over JTAG?
no
Is it configured to use a serial console? Tried checking the output there?
What's the output from uBoot, if any? As a last resort, tried re-flashing
it over JTAG?
--On Saturday, January 15, 2011 15:09 -0500 erik quanstrom
wrote:
has anyone else had a sheevaplug go catatonic?
mine reset yes
>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
>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
> 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
> 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
> 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 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
>> 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 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
> 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
> >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
>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,
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
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
> 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
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
> 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
>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
> 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
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...
Thanks much!!
-Ben
<>
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
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 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.
Sorry, the second line of my recipe should be
for(i in ?[acli])
cd /sys/src/cmd/5a
mk install
etc.
ron
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
> Mouse and keyboard support should be trivial to add and will come once (if)
> video is working on the Guruplug Display or OpenRD. This could take a long
> while, since the video controller is undocumented (there isn't even Linux
> driver source available).
There is (or maybe are two) X11 driver
On 6 Sep 2010, at 6:55 pm, Skip Tavakkolian wrote:
it works for all usb disks i've tried but has never worked for
Bluetooth devices.
well if it works for all usb disks it's worth my while getting one,
not a sheevaplug as such, rather a seagate freeagent go dockstar
which is currently €25
> On Mon, Sep 6, 2010 at 10:05 AM, erik quanstrom wrote:
>
> > i like the idea. unfortunately, iirc this problem hangs on specifications
> > which we don't have. so perhaps it would be better to attack a problem
> > were we're not just guessing.
>
> I've come to the conclusion that where hardw
> Mouse and keyboard support should be trivial to add
> and will come once (if) video is working on the Guruplug
> Display or OpenRD. This could take a long while, since
> the video controller is undocumented (there isn't even
> Linux driver source available). Until then, there's
> little point t
As the documentation says, the ARM ports are currently
only CPU kernels.
Mouse and keyboard support should be trivial to add
and will come once (if) video is working on the Guruplug
Display or OpenRD. This could take a long while, since
the video controller is undocumented (there isn't even
Linux
it works for all usb disks i've tried but has never worked for
Bluetooth devices. the last time i looked, i was left with a guess
that the driver needed to support some unholy handshake with the
built-in "Transaction Translator"; not sure if that's really the
problem. Geoff and Nemo worked on dis
On Mon, Sep 6, 2010 at 10:26 AM, ron minnich wrote:
> On Mon, Sep 6, 2010 at 10:05 AM, erik quanstrom wrote:
>
>> i like the idea. unfortunately, iirc this problem hangs on specifications
>> which we don't have. so perhaps it would be better to attack a problem
>> were we're not just guessing.
On Mon, Sep 6, 2010 at 10:05 AM, erik quanstrom wrote:
> i like the idea. unfortunately, iirc this problem hangs on specifications
> which we don't have. so perhaps it would be better to attack a problem
> were we're not just guessing.
I've come to the conclusion that where hardware is concern
On Mon Sep 6 13:03:54 EDT 2010, rminn...@gmail.com wrote:
> On Mon, Sep 6, 2010 at 9:52 AM, Nemo wrote:
> > Iirc, there's still work to be done to get them working fully and
> > properly. But i may be mistaken.
> > I remember I had to add support for kbin and mousein, as Erik points out.
>
>
On Mon, Sep 6, 2010 at 9:52 AM, Nemo wrote:
> Iirc, there's still work to be done to get them working fully and properly.
> But i may be mistaken.
> I remember I had to add support for kbin and mousein, as Erik points out.
Well, here is the kind of hackathon type of think it might be fun to
do
Iirc, there's still work to be done to get them working fully and properly.
But i may be mistaken.
I remember I had to add support for kbin and mousein, as Erik points out.
On Sep 6, 2010, at 5:22 PM, erik quanstrom wrote:
> On Mon Sep 6 10:44:06 EDT 2010, eeke...@fastmail.fm wrote:
>> Just c
On Mon Sep 6 10:44:06 EDT 2010, eeke...@fastmail.fm wrote:
> Just checking before I buy something; do the host-side USB ports work
> on the Sheevaplug? That's the ports you plug USB devices into,
yes. but life is not trouble-free:
plug# /boot/usbd: /dev/usb/ep2.0: warning: device with short
>> 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
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.
> 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
>
> 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
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
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:
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.
>
>
>
Sorry, I'd forgotten to push /sys/src/9/kw/sdscsi.c to sources.
It's fixed now.
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?
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
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.
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
On Tue, Dec 15, 2009 at 4:15 AM, wrote:
>> There is also a half written untried driver for the serial usb waiting
>> for it to arrive
>> to be finished.
>
> Which is the serial USB? The console on my plug works perfectly well,
> I thought that was the purpose?
>
>
>
>
Does it?. I mean the PC fr
> There is also a half written untried driver for the serial usb waiting
> for it to arrive
> to be finished.
Which is the serial USB? The console on my plug works perfectly well,
I thought that was the purpose?
++L
> But we'll try to help there as soon as we can.
I have absolutely no doubt that you will :-)
Unfortunately, as Geoff points out, USB is difficult. No chance that
you could write a commentary on USB that is as good as your efforts on
3rd Edition Plan 9?
++L
On Mon, Dec 14, 2009 at 9:39 PM, Francisco J Ballesteros wrote:
> Ours is finally in Spain, at customs.
>
> Knowing our bureaucracy, it may still take a week or two to get my hands on
> it.
>
There is also a half written untried driver for the serial usb waiting
for it to arrive
to be finished.
Ours is finally in Spain, at customs.
Knowing our bureaucracy, it may still take a week or two to get my hands on it.
When it comes I'll take a look to usb there.
In someone can't wait before we try, I think it's a matter of getting
the controller
initialized properly (and the ports reset). Look
> Sure. Theres' lots of good candidates out there. It's just that PXE is
> not one of them. PXE was designed for a world of binary formats and
> tiny, incapable network bootstraps, and it was obsolete when it was
> designed over a decade ago.
nonetheless, it's what vendors support. fighting
them
> Sure. Theres' lots of good candidates out there. It's just that PXE is
> not one of them. PXE was designed for a world of binary formats and
> tiny, incapable network bootstraps, and it was obsolete when it was
> designed over a decade ago.
This reminds of a similar situation many years ago: it
On Mon, Dec 14, 2009 at 10:37 AM, David Leimbach wrote:
> BOOTP + 9p?
Sure. Theres' lots of good candidates out there. It's just that PXE is
not one of them. PXE was designed for a world of binary formats and
tiny, incapable network bootstraps, and it was obsolete when it was
designed over a dec
On Mon, Dec 14, 2009 at 10:33 AM, ron minnich wrote:
> On Mon, Dec 14, 2009 at 10:12 AM, erik quanstrom
> wrote:
>
> > what's the replacement for pxe?
>
> Why not 9p?
>
BOOTP + 9p?
>
> ron
>
>
On Mon, Dec 14, 2009 at 10:12 AM, erik quanstrom wrote:
> what's the replacement for pxe?
Why not 9p?
ron
> > I wonder why neither U-boot nor PMON do PXE. PMON being senile has an
> > excuse, U-boot doesn't. Or I need an excuse for not understanding :-)
>
> Why bring such an awful standard anywhere you don't have to. I think they
> made a good call :-)
two standards are always better than one.
neve
On Mon, Dec 14, 2009 at 9:44 AM, wrote:
> I wonder why neither U-boot nor PMON do PXE. PMON being senile has an
> excuse, U-boot doesn't. Or I need an excuse for not understanding :-)
Why bring such an awful standard anywhere you don't have to. I think they
made a good call :-)
ron
> I'll try to get better instructions tonight when I boot it again.
> These are a start.
Geoff actually published the details when he announced the port,
booting(8) has been updated to match. I had forgotten. Of course,
it's never this simple, but it sure isn't hard. Haven't tried it all
yet, I
On Mon, Dec 14, 2009 at 5:06 AM, wrote:
> I have received mine in the past hour or so.
>
> Are there instructions anywhere on how to turn it into a CPU server?
it was pretty easy.
get the sys/src/9 tree
cd sheevaplug, make the kernel, put it in the usual plan 9 tftpboot
site. Set up dhcp. Boot
I ordered an openrd-client from globalscale and it arrived within
a few days. It's the same SoC (Kirkwood) as the Sheevaplug, but more
(perhaps all) of the connectors are made available, plus vga output for $250.
Looking at mine, I see connectors for 7 usb 2 ports, 2 Gb ethernets,
esata, SMbus, sy
So, I honestly haven't been paying enough attention to Sheeva and Gumstix.
What does everyone think about hacking on both of these? Which one is the
easier platform to develop on/for? While Sheeva is substantially faster,
Gumstix has more interesting expansion cards. I'd love to hear some
opinions.
On Sat, Dec 5, 2009 at 9:09 AM, Skip Tavakkolian <9...@9netics.com> wrote:
>> So, what is everyone's preferred plug vendor? Out of the three, is there a
>> preference for people out there hacking on the Sheeva?
>
> i ordered through globalscale; 2-3 weeks to ship and a few more days
> for delivery.
> High volume == affordable, even if not optimal.
>
> The SheevaPlug is just not quite into that range
the volume demand is coming from companies that bundle it with their
home automation, entertainment center and other products. it seems
there's at least one company trying out every suggest
> So, what is everyone's preferred plug vendor? Out of the three, is there a
> preference for people out there hacking on the Sheeva?
i ordered through globalscale; 2-3 weeks to ship and a few more days
for delivery. week 2 of waiting.
On Sat, Dec 5, 2009 at 8:26 AM, ron minnich wrote:
> I'm sticking with globalscale because they deliver the daughter board
> too, and you have to have that board for debug.
Although, once this all works, I want to by a bunch, rip the board out
of the plug module, stack them up (they have four ni
1 - 100 of 112 matches
Mail list logo
