Re: [LinuxBIOS] Geode SC22000

[Per Hallsmark]

Hi again,

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...)

-----Original Message-----
From: Stefan Reinauer 
To: Per Hallsmark 
Cc: [e-mail]
Date: Sat, 1 Apr 2006 12:18:58 +0200
Subject: Re: [LinuxBIOS] Geode SC22000
> Per Hallsmark  [060331 14:16]:
> > 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
> > C programmer.
>
> 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
> registers only.
> > Q2: Why does the LB project need a special compiler?
> > 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
> assembler
> 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
> works
> you can use gcc, which compiles faster and results in much smaller
> code.
>
> 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
> reaaally fragile.
> > Q3: Documentation...
> > 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
> linuxbios.org though.
>
> More (formal) documentation is really needed though, indeed.
>
> Stefan