Hello LB people,
First, a great thank for the quick boost I had from your project in creating a special firmware for our project.
I've ported LB to a SC2200 based platform, NCG266 (you can see some old photos at www.nano-system.com) The jump to the load just takes a couple of secs instead of like a minute with the Insyde BIOS...
The LB base is svn ver 2171, I've got a 71K big patch for it. How do I contribute it to LB tree?
Also during the learning and porting of LB, a couple of questions popped up:
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.
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)
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?
mvh Per Hallsmark
T2 Data
* Per Hallsmark perh@t2data.se [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
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 stepan@coresystems.de To: Per Hallsmark perh@t2data.se Cc: linuxbios@linuxbios.org Date: Sat, 1 Apr 2006 12:18:58 +0200 Subject: Re: [LinuxBIOS] Geode SC22000
- Per Hallsmark perh@t2data.se [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
-- coresystems GmbH · Brahmsstr. 16 · D-79104 Freiburg i. Br. Tel.: +49 761 7668825 · Fax: +49 761 7664613 Email: info@coresystems.de · http://www.coresystems.de/
* Per Hallsmark perh@t2data.se [060403 10:19]:
Stefan, thanks for you answers. I'm still a bit puzzled though why PPC, ARM, XScale, MIPS manages same thing without romcc or similar.
Cache-As-Ram works reliably on most platforms and it is definitely the way to go. Romcc helps in cases where we don't have that, so we get something up easily. On PPC it just works I think. Arm and Mips are not supported in LinuxBIOS yet, but many of these systems (embedded and/or with a fixed amount of memory soldered on) are a lot easier to set up than the x86 (-64) boxes we support in LinuxBIOS.
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.
It is pretty complex on AMD64 which was the reason for romcc. And since its there we use it to make readable C code rather than Assembler init code. It's a matter of maintainability and ease of use. 100 lines of C are easier to read than 100 lines of Assembler. Well, for most of us.
(could be because of my embedded background, most targets have had defined memory size so mem sizing isn't a problem...)
Yeah, with a fixed memory size the ram initialization is more or less poking some values into some machine specific registers. There you dont even gain a lot of readability with C. But imagine you read the SPD rom sitting on each DDR Ram module and you have to find out how many rows and columns it is, find a timing supported by all installed modules and generate values that the chipset understands. And then something doesnt work and you want to output some debugging information but your functions are tight in registers (which is usually the case on x86 machines) so you have to reorganize lots of your code.
romcc does that. It's a great tool. But in a "perfect world" we would not need it ;-)
Stefan
Hello LB people,
First, a great thank for the quick boost I had from your project in creating a special firmware for our project.
I've ported LB to a SC2200 based platform, NCG266 (you can see some old photos at www.nano-system.com) The jump to the load just takes a couple of secs instead of like a minute with the Insyde BIOS...
Is there any reason you are working on an EOL product?
Ollie
Per Hallsmark wrote:
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.
this is a romcc issue. It pretty much has to work this way. romcc has almost no function calls, as there is no stack, so all must be inlined.
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.
GNU can't be convinced to run without 1) memory 2) stack
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?
yes, please send a HOWTO of your experience and it goes on the web page.
docs are ALWAYS welcome.
thanks. please send me the patch.
ron
-
Li-Ta Lo -
Per Hallsmark -
Ronald G Minnich -
Stefan Reinauer -
Stefan Reinauer