> I've just started playing with my gumstix, and it seems the flash on
> mine is out of sync with what's currently shipping (or at least the
Join the club.
> In /root there should be a usbnet script, right? There isn't one on
> mine, and I haven't found it anywhere to download it yet.
Ditto. Further... what is it based on? And why wasn't it properly
integrated with the network rc scripts? Dwayne has put together some
great rootfs support for the stix, including the ability to flash and
boot from a JFFS2 partition. This will allow non-volatile storage on
the stix without needing the MMC -- the way it should be.
> The support area on gumstix.com is a great improvement-- but this
> brings up the issue I've run into: If there are multiple versions of
> what's shipping (as things progress) I think I'm not going to be the
> only one who could use a guide to the variations that have shipped,
> how to tell which version you have, and a method for updating to the
> latest. I'm a bit wary of using the kermit stuff that Zach has put
> up until I'm sure I'm not going to end up in a state I can't get out
I presently believe there are probably close to N different versions of
firmware - one for every day they've been shipping. They have not been
releasing their source code for all of the different variants, which
leads me to believe that they can't readily provide patches for all of
those versions (even if asked). Needless to say, you'll never have that
problem with what I release -- everything has been managed in Subversion
repositories since I started, so I'll have every version around forever.
Next, I think the alternative to using the kermit scripts on my site is
too painful to contemplate. In fact, I would argue that using my
scripts will be orders of magnitudes *safer* than not, as it automates
commands that are slow and tedious to type and which write to the flash.
And who says I won't try to help get you out of a bad state if those
scripts put you there? You worry too much. ;)
> If Zach is the one responsible for the usbnet stuff, he's saved me a
> tonne of work, as that would have been the first thing I'd tried to
> port. So, THANKS!
I got the information I needed from Gordon, but I was the one to find
and implement the required fixes, yes. And you're welcome. :)
> Generally, things seem to be in the state that you'd expect at this
> stage-- its a bit hard to figure out. (For instance, I'm not hosting
> on Linux, but on Mac OS X, so the ifconfigs given for the host side
I would expect the ifconfig commands to work on MacOS X just as they do
under Linux, but you are correct in your summary of the link created.
If you provide me with any deviations from the HOWTO that I've posted, I
will happily post a MacOS X flavor. Same goes for Win32, though I'd
just assume leave that for Gumstix, Inc. as they actually are using such
machines in-house. [[ I've been a 100% FOSS shop for years; even my
TiBook had Linux loaded onto it immediately after being purchased. ]]
> Again, thanks to Gordon and Zach-- I'm a bit behind the curve due to
> lack of experience with Linux, but hopefully I'll be contributing
> soon, at least on the testing side. Also, I'm going to try to build
> a toolchain that's Mac OS X hosted based on the work that others have
> done to support Zaurus development on OS X...
Those of you wanting to test the latest kernel releases should join the
#gumstix channel on irc.freenode.net. I always try to review my latest
patches there with Dwayne before posting them. The more feedback I
receive in between releases, the more information that I have to try and
fix the problems, which should lead to greater gains at each step.
In fact, I did not even know the symptoms of the problems with HWUART
(other than, "it doesn't work") until Dwayne was able to provide some
concrete feedback this week. So let me be clear: bugs will never get
fixed unless they are reported with sufficient context and detail for
them to either be reproduced or understood.
That last bit isn't directed at you, Jay, so much as it is at everyone
with a Gumstix that has problems with the software -- don't assume it's
on a list of things to fix. Unless they have been reported, those
problems effectively don't exist.
> Finally, a question--- is it possible to have uboot look to the MMC
> and boot from a kernel there instead? If so, I'd like to move to
I believe u-boot does need further development, as I believe the current
problems relate more to timing problems than anything else. After all,
these cards that are supposedly 'defective' all work fine in desktop
systems - or inside the Gumstix Linux kernel itself.
Come on - that's crap code, not bad hardware. I'm entirely unconvinced
that these are really defects, but rather an incredibly difficult
software problem that, operationally speaking, can be easier solved by
using more rigidly spec'd cards.
Not having seen the actual hardware manufacturer's wording of the
alleged problem, there is no way to tell if what we are being led to
believe about these cards is true or not. In saying this, I simply am
relating my own experience with these systems, having fought
frighteningly similar problems with CompactFlash cards on a previous
StrongARM handheld platform.
Further, I related this experience to Gordon a couple of weeks ago in a
private message, and it seems that he took up my (poor) suggestion of
pre-qualifying cards. At that time, I did not make it clear that such a
solution does *not* only avoid solving the problem, it creates a bigger
operational nightmare in the long term, as every batch of cards must be
pre-qualified. And just how can we pre-qualify cards we buy ourselves?
In the case of the handheld, the CF card was built-in to the unit so
such a test *could* be reasonably built into the assembly process, but
the Gumstix should allow users to use MMC cards they've purchased off
the shelf. So... what? we'll never be able to buy a new bootable card
except from Gumstix, Inc.? That really stinks, and I am going to at
least try to fix the code before blandly accepting that fate.
All that said, I personally believe that all of the MMC cards shipped
are perfectly fine, with the singular exception being their performance
under u-boot on the stix -- which I firmly believe is a software bug.
Would anyone care to add to this point?
As I have mentioned on the list before now, I plan to release a new
gumstix patch for u-boot that (at least) cleans it up a little bit;
however, my JTAG setup continues to be non-functional. Until I can get
that system brought up, I can't predict when I'll be able to start
working on these issues.