Ok, here comes the svn diff (towards 2171) attached.
It's quite big, had to add superio and southbridge setups
(along with it's attached devices) which is embedded in
the SC2200. It was unfortunally not just a small port of
the current GX1...
There is some extra POST codes inserted to follow code flow,
perhaps this should be removed before adding patch into live tree.
I've also started a (yet another) porting guide, intent
is to make it more detailed and also describe "obvious"
steps that perhaps is not so obvious for a linuxbios beginner.
(at least it wasn't for me :-) )
Have a GX3 eval board (ITX form) somewhere on my desk, will
be a good testdrive porting according to document.
I've seen some logs here on mailing list that have nice
timestamps in first column. Is there some standard support
for this in LinuxBIOS? (have searched around in code but
couldn't find it)
Stefan, thanks for you answers. I'm still a bit puzzled though
why PPC, ARM, XScale, MIPS manages same thing without romcc or similar.
Is memory setup done so very much different and is so much more
complex in x86? For my port, SC2200, it looks about same to me.
(could be because of my embedded background, most targets have
had defined memory size so mem sizing isn't a problem...)
From: Stefan Reinauer <stepan(a)coresystems.de>
To: Per Hallsmark <perh(a)t2data.se>
Date: Sat, 1 Apr 2006 12:18:58 +0200
Subject: Re: [LinuxBIOS] Geode SC22000
* Per Hallsmark <perh(a)t2data.se> [060331
The LB base is svn ver 2171, I've got a 71K
big patch for it.
How do I contribute it to LB tree?
Just send an "svn diff" as an attachment to this list.
Q1: The source code files often include source
files again instead
of like building object modules that are later linked together.
Why something like this? It seems odd to me as an perhaps oldschool
That's done in the romcc compiled code. The reason is that you can only
know how the code looks like as a whole, the single parts look pretty
different depending on the register pressure. Remember: This code is
compiled to assembler code that does not use _any_ memory but runs in
Q2: Why does the LB project need a special
I've done numberous of firmware stuff and ordinary gnu tools have a
good job so far.
Must admit though that these hasn't been x86 which of course has it
special boot mode, but there exist "standard" tools for that as well.
(RPM package dev86 for example)
It does not _need_ one. The thing is, we don't want to write ram
initialization code for complex systems (such as the amd64) in
but instead in more readable and understandable C code.
Since, consequentially, there is no RAM during RAM initialization, you
need to make sure the code fits into registers only.
No other C compiler except romcc does that.
Some platforms also allow you to do cache as ram, which uses the cpu
cache as a small amount of "fake ram". The advantage is: When this
you can use gcc, which compiles faster and results in much smaller
We're trying to do this on all systems where it works reliably, but
LinuxBIOS is a burned child with respect to CAR (as we usually call
cache as ram) because the needed mechanisms changed per minor cpu
revision on intel systems a while ago which made the whole thing
I was perhaps a bit optimistic when I thought the LB port should
take one week, it was more like one month :-)
But more documentation could help here a lot, or are there docs
outside of linuxbios.org
I've missed? Any work in progress here
or can I contribute to it somehow?
There's Ron's great article on porting to the sc520 and I've written a
paper on AMD64 porting a whole while ago. Both should be linked in on
More (formal) documentation is really needed though, indeed.
coresystems GmbH · Brahmsstr. 16 · D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 · Fax: +49 761 7664613
Email: info(a)coresystems.de · http://www.coresystems.de/