2.4.18 AND Geode GX1/200Mhz problem

2.4.18 AND Geode GX1/200Mhz problem

[Pierre Ficheux]

	Hi all,

	I have a strange problem with a Geode/GX1 200Mhz based system. My
kernel is compiled  with 586 as processor type but the system stops just
after the 'Uncompressing Linux...Ok, booting the kernel' message. It's
strange as GX1 is claimed to work fine with 2.4.18. The same system
works fine with 2.2.18 kernel.

	Is there any new patch to test? Any idea?

	Thx a lot by advance.

-- 
Pierre FICHEUX -/- CTO OpenWide, France -\- pierre.ficheux@openwide.fr
				         http://www.ficheux.com
					 http://www.emulateur-xtel.org
More fun, more freedom, less Micro$oft

Re: 2.4.18 AND Geode GX1/200Mhz problem

[Alan Cox]

> 	I have a strange problem with a Geode/GX1 200Mhz based system. My
> kernel is compiled  with 586 as processor type but the system stops just
> after the 'Uncompressing Linux...Ok, booting the kernel' message. It's
> strange as GX1 is claimed to work fine with 2.4.18. The same system
> works fine with 2.2.18 kernel.

With 586 and no TSC set it should work fine yes. You might want to plug a 
serial port in and compile with serial console enabled, see if it gives any
clues

Re: 2.4.18 AND Geode GX1/200Mhz problem

[Peter Wächtler]

Alan Cox wrote:
> 
> >       I have a strange problem with a Geode/GX1 200Mhz based system. My
> > kernel is compiled  with 586 as processor type but the system stops just
> > after the 'Uncompressing Linux...Ok, booting the kernel' message. It's
> > strange as GX1 is claimed to work fine with 2.4.18. The same system
> > works fine with 2.2.18 kernel.
> 
> With 586 and no TSC set it should work fine yes. You might want to plug a
> serial port in and compile with serial console enabled, see if it gives any
> clues

I want to translate this to:

Processor -> 586/K5/5x86/6x86/6x86MX

right?

Re: 2.4.18 AND Geode GX1/200Mhz problem

[Zwane Mwaikambo]

On Mon, 8 Apr 2002, Peter Wächtler wrote:

> I want to translate this to:
> 
> Processor -> 586/K5/5x86/6x86/6x86MX
> 
> right?

Or you can boot with kernel parameter notsc which should have the effect.

	Zwane

-- 
http://function.linuxpower.ca
		

Re: 2.4.18 AND Geode GX1/200Mhz problem

[Pierre Ficheux]

Peter Wächtler wrote:

> I want to translate this to:
> 
> Processor -> 586/K5/5x86/6x86/6x86MX
> 
> right?

	That's right, have tried with 486 too but I got the same problem.


-- 
Pierre FICHEUX -/- CTO OpenWide, France -\- pierre.ficheux@openwide.fr
				         http://www.ficheux.com
					 http://www.emulateur-xtel.org
More fun, more freedom, less Micro$oft

Re: 2.4.18 AND Geode GX1/200Mhz problem

[Ricky Beam]

On Mon, 8 Apr 2002, Zwane Mwaikambo wrote:
>Or you can boot with kernel parameter notsc which should have the effect.

One might think that, but it isn't true.  That'll just stop the kernel from
halting immediately when it doesn't find any tsc capability.  The system
still locks up -- maybe some other parts of the kernel tries to use tsc?
I never looked into it as compiling the kernel correctly (sans tsc) works
just fine.

On a side note, has anyone seen dd scrolling behavior with video chipse
using shared memory?  On the geode board I'm playing with, the screen
never scrolls correctly.  It's probablly something stupid in the 5530's
setup that's at fault. (I have ever intention of turning the VGA port
off entirely.)

--Ricky

Re: 2.4.18 AND Geode GX1/200Mhz problem

[Alan Cox]

> On a side note, has anyone seen dd scrolling behavior with video chipse
> using shared memory?  On the geode board I'm playing with, the screen
> never scrolls correctly.  It's probablly something stupid in the 5530's
> setup that's at fault. (I have ever intention of turning the VGA port
> off entirely.)

My 5530 works fine in VESA mode

Re: 2.4.18 AND Geode GX1/200Mhz problem

[Christer Weinigel]

Ricky Beam <jfbeam@bluetronic.net> wrote:
> On a side note, has anyone seen dd scrolling behavior with video chipse
> using shared memory?  On the geode board I'm playing with, the screen
> never scrolls correctly.  It's probablly something stupid in the 5530's
> setup that's at fault. (I have ever intention of turning the VGA port
> off entirely.)

The VSA CGA/EGA/VGA text emulation seems to be rather awful and has
lots of bugs.  Compile in the VESA framebuffer support in your Linux
kernel and add vga=785 (see linux/Documentation/fb/vesafb.txt) to
your kernel command line.  It's a choice of:

    Linux kernel frobs the text console -> buggy VSA emulation -> framebuffer

or

    Linux kernel frobs the framebuffer directly

Guess which works better?  *grin*

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"