Greetings,
The terms should at least be documented. They are spread all over the place, so might take some doing to change.
XIP = eXecute In Place.
As for the division of stages, generally, the assembly is serial setup, initial CPU setup, RAM setup, and decompress the C portion (plus a short startup in asm to get the stack ready) into ram.
In a number of cases (I'm guilty here), Config files still have unneeded or useless options either due to legacy or from using older configs as a template for new boards.
G'day, sjames
On Sun, 12 Jan 2003, Peter Stuge wrote:
Hi, I've been confused by these commands and options too. Below are some suggested namechanges followed by some reasoning about documentation in general.
On Sat, Jan 11, 2003 at 12:48:06PM -0500, steven james wrote:
biosbase 0xffff0000
The BIOS image will begin at the biosbase address in the CPU's memory space
imagephysaddr or stage1physaddr
rambase 0x00000800
Once RAM is set up, the C portion of LinuxBIOS will be uncompressed and loaded to rambase in system memory.
cportionramaddr or stage2ramaddr
option XIP_ROM_BASE=0xffff0000
same as biosbase
XIP_IMAGE_PHYS_ADDR
Why is there both a command and an option for this? And what is XIP?
option XIP_ROM_SIZE=0x10000
The rom size for LinuxBIOS is this size (a 64K blockmany cases)
XIP_IMAGE_SIZE # if this accounts for the payload or XIP_LINUXBIOS_SIZE # if not
Reading some Config files this doesn't seem to be the whole story, caching is mentioned. What's up?
option STACK_SIZE=0x2000
This is the size of RAM allocated for the stack used by the C code
C_STACK_SIZE # for cportionramaddr or STAGE2_STACK_SIZE # for stage2ramaddr
Already pretty good the way it is but adding the context should help.
option ZKERNEL_START=0xfff40000
This is where the payload (such as etherboot) will be located in the memory space (as part of the flash).
PAYLOAD_PHYS_ADDR
Does LinuxBIOS require this to be aligned in any way?
option ZKERNEL_MASK=0x3ed
Near as I can tell, this is just a legacy now.
Great, then it can be removed. :) What has it been used for?
I'd be happy to make these changes.
What about general documentation, e.g. regarding current LinuxBIOS structure? I know I've read about the different parts of LinuxBIOS somewhere but it might have been here on the mailing list. I'm thinking of the stage1/stage2 names I used above, is it a good idea to establish a stage 1 and a stage 2 (or similar) of LinuxBIOS or should it just continue to be "in assembly" and "in C" ?
Also, I would very much like a complete documenatation of the Config files, I'm thinking about doing something along the lines of a Capabilities or Options file that specifies all possible (used) options for that particular directory, along with sane default values where possible. It might only apply to mainboards but would be useful for learning the structure, when porting to new mainboards and for the web Config creator. Thoughts?
//Peter