Linux on Capio II (Geode) ?

Hi all.

Has anyone run Linux from the Disk-on-Chip on these little beasts?
Bought 11 of them for about $2 apiece. They have 2xUSB, sound, e100
ethernet, 16MB DOC, 64MB 144 pin SODIMM SDRAM.

I have a Rocky 558EV SBC running SuSE 9.0 with DOC socket to transfer OS
images, but even with all DOC support compiled into the SuSE 2.4.21 kernel,
fdisk, dd, mkfs, etc. seem to freeze up when accessing the DOC.

And yes, I'm a newbie at embedded stuff, so it's possible (likely?) that I
overlooked something totally basic and/or obvious.

Comments? Hints? Advice? OS images?

TIA,
Phil

"Phil" <phil@nospam.assetsure.dot.net> wrote in message
news:19KdnRvM8_hIgTDdRVn-tw@is.co.za...
> Hi all.
>
> Has anyone run Linux from the Disk-on-Chip on these little beasts?
> Bought 11 of them for about $2 apiece. They have 2xUSB, sound, e100
> ethernet, 16MB DOC, 64MB 144 pin SODIMM SDRAM.
>
> I have a Rocky 558EV SBC running SuSE 9.0 with DOC socket to transfer OS
> images, but even with all DOC support compiled into the SuSE 2.4.21
kernel,
> fdisk, dd, mkfs, etc. seem to freeze up when accessing the DOC.
>
> And yes, I'm a newbie at embedded stuff, so it's possible (likely?) that I
> overlooked something totally basic and/or obvious.
>
> Comments? Hints? Advice? OS images?
>
> TIA,
> Phil

Have a look at Lewin's experiences.
http://www.larwe.com/technical/geode_linux.html

I haven't tried the DOC, but found the terminal stuff in the Geode really
flakey.  The processor would stop for significant periods (>1 millisecond,
from memory)  while video operations were happening.  A very strange
relationship between the processor and the video chip.

Cheers,
--
Alf

Quick response only, I'm not at home (home Internet is not working
right).

> I haven't tried the DOC, but found the terminal stuff in the Geode really
> flakey.  The processor would stop for significant periods (>1 millisecond,

Actually it is not stopped, it's servicing a SMM interrupt. Every
{time period} a nonmaskable SMM interrupt occurs. The Geode hardware
doesn't support text modes natively. In text modes, the SMM ISR checks
to see if the color or character memory has changed, and if so it
updates the frame buffer memory. You can mitigate this evil behavior
somewhat by disabling text-mode-related SMM traps. (BTW, this won't
prevent the periodic interrupts, which also handle other things, but
it will prevent text-mode RAM hits from triggering SMM traps).

Ultimately the only way to get Geode tuned properly for an application
with any kind of realtime needs is to get a customized BIOS with your
particular fetish implemented in the VSA code.

larwe@larwe.com (Lewin A.R.W. Edwards) wrote in message news:<608b6569.0405221412.393ad2fe@posting.google.com>...
> Quick response only, I'm not at home (home Internet is not working
> right).
> 
> > I haven't tried the DOC, but found the terminal stuff in the Geode really
> > flakey.  The processor would stop for significant periods (>1 millisecond,
> 
> Actually it is not stopped, it's servicing a SMM interrupt. Every
> {time period} a nonmaskable SMM interrupt occurs. The Geode hardware
> doesn't support text modes natively. In text modes, the SMM ISR checks
> to see if the color or character memory has changed, and if so it
> updates the frame buffer memory. You can mitigate this evil behavior
> somewhat by disabling text-mode-related SMM traps. (BTW, this won't
> prevent the periodic interrupts, which also handle other things, but
> it will prevent text-mode RAM hits from triggering SMM traps).
> 
> Ultimately the only way to get Geode tuned properly for an application
> with any kind of realtime needs is to get a customized BIOS with your
> particular fetish implemented in the VSA code.

We are using a Geode GX1 based Compaq Internet Appliance 2.  We have
not experienced any of the problem you mentioned.  The only strange
thing is that I can only run at 1024x768 and my friend can only run at
800x600.  Any other video mode would get the monitor out of sync.  I
am using Xfree 3.3.6 and my friend is using Xfree 4.2.  Any idea why?

> > {time period} a nonmaskable SMM interrupt occurs. The Geode hardware
> > doesn't support text modes natively. In text modes, the SMM ISR checks
> > to see if the color or character memory has changed, and if so it
> 
> We are using a Geode GX1 based Compaq Internet Appliance 2.  We have
> not experienced any of the problem you mentioned.  The only strange

Are you using text modes? The discussion we're having here relates to
use of modes which, ordinarily, would be supported by character
generator hardware (which the CS5530/GX1 combo lacks). Font/color
rendering, blink text and cursor are all emulated in unpreemptible
firmware. You'll note that there are many Geode BIOSes out there that
show significant problems with text-mode scrolling in Linux, BTW.

There are other functions in Geode which also go through this baroque
arrangement of HW/SW codependency, but text mode display rendering is
one of the biggies. Geode is not a good choice for realtime
applications unless you can get great vendor support for customized
BIOSes (and not always even then).

> thing is that I can only run at 1024x768 and my friend can only run at
> 800x600.  Any other video mode would get the monitor out of sync.  I
> am using Xfree 3.3.6 and my friend is using Xfree 4.2.  Any idea why?

The changes between these two versions are pretty radical, and in the
case of 3.x servers, there are at /least/ three different forks of the
source tree; two closed-source XF86_SVGA servers (one from NS, one
from a third party I have yet to identify), and one official
open-source version from xfree86.org. I don't know that there is any
good source of documentation on all of this besides the XFree86
source. Unfortunately the "official" NS sources are only available
with an NDA (? I'm not sure how this is reconcilable with GPL).

Anyway, these versions all differ substantially in how they calculate
and validate clock settings. The symptom you describe is, I'd say, par
for the course (it can be instructive to scope the sync lines and see
what's being set up, BTW!). If you are very careful to specify exact
video mode setup in the ModeLine, you can *usually* get a particular
mode working [except scandoubled modes - a patch is required for 4.x -
see my webpage] but really the only way to ensure identicical behavior
between systems is to use the _exact_ same binaries. An alternative
option is to use the fbdev server running over kernel framebuffer
console.

One problem with 4.x servers is that all the "built-in" implicit
modelines need to be overridden. It can be very hard to work out
exactly where the server is picking up its config information
sometimes, and/or hard to work out why it is rejecting user-supplied
modelines.

larwe@larwe.com (Lewin A.R.W. Edwards) wrote in message news:<608b6569.0405251813.6a8d5bc0@posting.google.com>...
> > > {time period} a nonmaskable SMM interrupt occurs. The Geode hardware
> > > doesn't support text modes natively. In text modes, the SMM ISR checks
> > > to see if the color or character memory has changed, and if so it
> > 
> > We are using a Geode GX1 based Compaq Internet Appliance 2.  We have
> > not experienced any of the problem you mentioned.  The only strange
> 
> Are you using text modes? The discussion we're having here relates to
> use of modes which, ordinarily, would be supported by character
> generator hardware (which the CS5530/GX1 combo lacks). Font/color
> rendering, blink text and cursor are all emulated in unpreemptible
> firmware. You'll note that there are many Geode BIOSes out there that
> show significant problems with text-mode scrolling in Linux, BTW.
> 

Yes, we are using text mode for Dos and Linux, piror to run X.  The
scrolling is slow, but not unusually slow.

> There are other functions in Geode which also go through this baroque
> arrangement of HW/SW codependency, but text mode display rendering is
> one of the biggies. Geode is not a good choice for realtime
> applications unless you can get great vendor support for customized
> BIOSes (and not always even then).
> 
> > thing is that I can only run at 1024x768 and my friend can only run at
> > 800x600.  Any other video mode would get the monitor out of sync.  I
> > am using Xfree 3.3.6 and my friend is using Xfree 4.2.  Any idea why?
> 
> The changes between these two versions are pretty radical, and in the
> case of 3.x servers, there are at /least/ three different forks of the
> source tree; two closed-source XF86_SVGA servers (one from NS, one
> from a third party I have yet to identify), and one official
> open-source version from xfree86.org. I don't know that there is any
> good source of documentation on all of this besides the XFree86
> source. Unfortunately the "official" NS sources are only available
> with an NDA (? I'm not sure how this is reconcilable with GPL).

I am using the open source XFree 3.3.6.  I am not surprised that my
friend's system work on 800x600 only, since the original box (for msn)
was designed to run at 800x600.  What's surprising is that I can only
run at 1024x768, with an external Multi-Sync monitor.

I have tried modeline timings from my own (worked on many other
systems), the example on your site and another one from the web.  None
of them can get the display to work in 800x600.

It appears that the system has a firmware limitation coded somewhere
to a fixed resolution.

> 
> Anyway, these versions all differ substantially in how they calculate
> and validate clock settings. The symptom you describe is, I'd say, par
> for the course (it can be instructive to scope the sync lines and see
> what's being set up, BTW!). If you are very careful to specify exact
> video mode setup in the ModeLine, you can *usually* get a particular
> mode working [except scandoubled modes - a patch is required for 4.x -
> see my webpage] but really the only way to ensure identicical behavior
> between systems is to use the _exact_ same binaries. An alternative
> option is to use the fbdev server running over kernel framebuffer
> console.
> 
> One problem with 4.x servers is that all the "built-in" implicit
> modelines need to be overridden. It can be very hard to work out
> exactly where the server is picking up its config information
> sometimes, and/or hard to work out why it is rejecting user-supplied
> modelines.