Forums

Linux on Capio II (Geode) ?

Started by Phil May 20, 2004
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.