Hello, My attempt at a sis530 port seems to be coming along. I am almost ready to compile and try this thing. I am though confused or unclear as to the order that stuff needs to happen. I assume that eventually I initialize RAM and then superIO and all that, what I don't understand is the basic order of execution, this happens and then this needs to and then this ... etc. I have been using as a guide the sis540 chipset and stuff like that to get my configuration files together and as examples, but well since the code for stuff is spread accross trees, what happens when I make one of these projects? Does it take the mainboard.c file first, then the raminit? I'm not sure if I am being as clear as possible, but if anyone has a clue what I'm asking about it would help.
For example, the raminit and the chipset specific code is usually assembly, whereas the mainboard.c is well, C. So where does that raminit come into play, and how is it called, IS it called like a function, same goes for the chipset initialization (I guess chip init is tied pretty closely with the ram init stuff but well what happens in what order is what I could use some pointers on....
I have been using as a guide the sis540 chipset and stuff like that to get my configuration files together and as examples, but well since the code for stuff is spread accross trees, what happens when I make one of these projects? Does it take the mainboard.c file first, then the raminit? I'm not sure if I am being as clear as possible, but if anyone has a clue what I'm asking about it would help.
One good way to get a view of the execution order is to build it, and look at the crt.s file. This file has all of the assembly language combined in it, after pre-processing. The order is in the mainboard Config file; mainboardinit files first in order (ie, the .inc assembly language), then the C code. The last assy language code is the crt0.base, which relocates the C code into ram and then jumps to it (hardwaremain). Basically, you have to setup RAM, in assy, before you move things to RAM and have a stack, etc. Only a few initial instructions after power on are in real mode; all other code is 4GB flat protected mode. Linuxbios sets up a gdt right away.
This is true for flash, at least, DocMem may be slightly different.
-Steve
and for perusing the C code, make tags or make etags and then tag around with emacs or vi to see how it goes.
I've found the tags thing really helpful for working things out. The only thing it won't help for is the fill_inbuf stuff which uses linker-sets.
ron
Sometime back Ron has mail to the group with complete serial output of LinuxBIOS. You can refer that for more clarification. It will give you some idea about the steps invloved. Also you can refer crt0.s file which will be created after build. It contains the assembly code for RAM initializationa and continues with the hardwaremain.
-Siva On Thu, 2002-12-12 at 22:07, Nathanael Noblet wrote:
Hello, My attempt at a sis530 port seems to be coming along. I am almost ready to compile and try this thing. I am though confused or unclear as to the order that stuff needs to happen. I assume that eventually I initialize RAM and then superIO and all that, what I don't understand is the basic order of execution, this happens and then this needs to and then this ... etc. I have been using as a guide the sis540 chipset and stuff like that to get my configuration files together and as examples, but well since the code for stuff is spread accross trees, what happens when I make one of these projects? Does it take the mainboard.c file first, then the raminit? I'm not sure if I am being as clear as possible, but if anyone has a clue what I'm asking about it would help.
For example, the raminit and the chipset specific code is usually assembly, whereas the mainboard.c is well, C. So where does that raminit come into play, and how is it called, IS it called like a function, same goes for the chipset initialization (I guess chip init is tied pretty closely with the ram init stuff but well what happens in what order is what I could use some pointers on....
and, as always, anyone who writes this up will receive, from me, a frowny face that I will purchase from despair.com.
These frowny faces are not cheap and come with an EULA, but can be delivered in email.
For more information on this incredible offer see http://www.despair.com/frownies.html.
ron p.s. seriously, though, if you do write something up I can put it on the web page.
On Fri, 2002-12-13 at 00:37, Nathanael Noblet wrote:
Hello, My attempt at a sis530 port seems to be coming along. I am almost ready to compile and try this thing. I am though confused or unclear as to the order that stuff needs to happen. I assume that eventually I initialize RAM and then superIO and all that, what I don't understand is the basic order of execution, this happens and then this needs to and then this ... etc. I have been using as a guide the sis540 chipset and stuff like that to get my configuration files together and as examples, but well since the code for stuff is spread accross trees, what happens when I make one of these projects? Does it take the mainboard.c file first, then the raminit? I'm not sure if I am being as clear as possible, but if anyone has a clue what I'm asking about it would help.
For example, the raminit and the chipset specific code is usually assembly, whereas the mainboard.c is well, C. So where does that raminit come into play, and how is it called, IS it called like a function, same goes for the chipset initialization (I guess chip init is tied pretty closely with the ram init stuff but well what happens in what order is what I could use some pointers on....
The very first instructions are in ipl.S for SiS chipsets. These codes are used to initialize the DRAM and some other (highly) critical registers in north/south bridge. After the DRAM is up, ipl.S will load and/or jump to the code in crt0.S. The raminit.inc and xxx_regs.inc contains (middle) critical codes to stabilize the system which are included in the head of crt0.S and executed before the generic LinuxBIOS code. The southbridge.c and southbridge.c are low priority and used mainly use to fix up some bug/configuration problem. Generally, the mainborad.c is empty and trivial unless your mainboard has some other bugs to fix.
The very first instructions are in ipl.S for SiS chipsets. These codes are used to initialize the DRAM and some other (highly) critical registers in north/south bridge.
ollie lho ollie@sis.com.tw
Good point, I forgot about ipl.S. For the vga code for the sis630, I translated ipl.S to 32-bit code and put it in the crt0.s stack. Required a few changes, but seems to work fine and the code is more continuous.
Not sure how or if this should be integrated into the code base, but this is how the vga was done for the sis630.
I do have the linuxBIOS logo showing up for a few seconds on boot, before switching to vga text console. Looks pretty cool. Great logo.
-Steve
On Sat, 2002-12-14 at 15:45, Steve M. Gehlbach wrote:
The very first instructions are in ipl.S for SiS chipsets. These codes are used to initialize the DRAM and some other (highly) critical registers in north/south bridge.
ollie lho ollie@sis.com.tw
Good point, I forgot about ipl.S. For the vga code for the sis630, I translated ipl.S to 32-bit code and put it in the crt0.s stack. Required a few changes, but seems to work fine and the code is more continuous.
Not sure how or if this should be integrated into the code base, but this is how the vga was done for the sis630.
What VGA code ?? The VGA bios emulation stuff in the freebios tree ?? How does moving ipl.S to 32-bit have anything to do with VGA ??
What VGA code ?? The VGA bios emulation stuff in the freebios tree ?? How does moving ipl.S to 32-bit have anything to do with VGA ??
-- ollie lho ollie@sis.com.tw
This was the new vga code that I wrote for a vga text console (not in the repository yet). There were a few registers that had to be set in the sis630 to turn on vga.
Translating it was not _really_ required. I am more familiar with programming in 32-bit, though, and had other changes I needed to add, in addition to the vga, that were better done in 32-bit. I also had some problems with the fixed address location and hard jumps to fixed addresses in ipl.S, which were avoided by just putting it in the .inc stack in crt0.s.
-Steve
-
Nathanael Noblet -
ollie lho -
Ronald G. Minnich -
sivakumar -
Steve M. Gehlbach