Re: CPU refactoring status....
ron minnich [EMAIL PROTECTED] writes: On 13 Jul 2004, Eric W. Biederman wrote: I think someone needs to log into the cvs server and fix it. Which like requires a project admin to ask the sourceforge administrators. I'll do it tomorrow. usually these things time out, but ... [EMAIL PROTECTED]@! Agreed. Thank you very much for taking the time to do this. What does it involve anyway? Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
you need to send me the file name again (I forgot it) and then I file a trouble ticket with sourceforge, etc., etc., since I don't have direct access to the repo. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
* Eric W. Biederman [EMAIL PROTECTED] [040713 07:40]: It appears Stefan has one of CVS's internal locks on src/cpu/p5 and so I can't get past that It is probably just CVS messed up somewhere but anyway. I will look back tomorrow and see what I can accomplish. Weird, all my commits are quite a while ago and were completed without trouble. Is there anything I can do to fix this? Stefan ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
On 13 Jul 2004, Eric W. Biederman wrote: I think someone needs to log into the cvs server and fix it. Which like requires a project admin to ask the sourceforge administrators. I'll do it tomorrow. usually these things time out, but ... [EMAIL PROTECTED]@! ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
: CPU refactoring status....
The hardwaremain become more tidy.
How about the progress about the romcc? I hope I can enable debug info while
include all ati support stuff.
Regards
YH
--
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
: 200477 21:03
: LinuxBIOS
: YhLu; ron minnich; Stefan Reinauer
: Re: CPU refactoring status
[EMAIL PROTECTED] (Eric W. Biederman) writes:
The next big task is to get make the SMP cpu initialization methods
normal device tree methods. I have everything ready to do that
except I need a good way to get the information in the struct
mem_range array by sizeram(). My gut feel is that I want to
incorporate the sizeram functionality into the resource allocator,
Moving sizeram into read_resources/set_resources comes out fairly
clean, but it did require some grunt work.
That has allowed me to sort out the device tree and have a fairly
generic method of initializing cpus. Cpus don't fit into device
model methods as nicely as I would like (largely because their
methods have to run on the cpu in question). But it does work
well enough I can remove the special case from hardwaremain.
I still have a special case in the root_device methods but
that can be overridden, if necessary.
Because I have restructured where things fall in the device tree.
Because I have removed the sizeram call.
Because I have refactored x86 cpu handling.
Because I have removed the array initial_apic_id.
Every port in the tree is likely to break when I check this code in.
I have the arima/hdama working and I can with a little care
fix up the k8 based ports.
I can also likely fixup the recent e7501 forward port from the
freebios tree.
However beyond that I don't have testing resources to fix things up
so I am looking for some feedback before I break everything.
When in the next week or so is a good time?
Does any one have concerns about this set of changes?
I have attached my current version of hardwaremain below
to give a feel of what the changes look like.
Ok now I am off to bed. Before I commit anything I am going to let
the code sit a little.
Good Night,
Eric
/*
* C Bootstrap code for the LinuxBIOS
*/
#include console/console.h
#include mem.h
#include version.h
#include boot/tables.h
#include device/device.h
#include device/pci.h
#include device/chip.h
#include delay.h
#include stdlib.h
#include part/hard_reset.h
#include boot/elf.h
void hardwaremain(int boot_complete)
{
/* the order here is a bit tricky. We don't want to do much of
* anything that uses config registers until after
PciAllocateResources
* since that function also figures out what kind of config strategy
* to use (type 1 or type 2).
* so we turn on cache, then worry about PCI setup, then do other
* things, so that the other work can use the PciRead* and PciWrite*
* functions.
*/
struct lb_memory *lb_mem;
post_code(0x80);
CONFIGURE(CONF_PASS_PRE_CONSOLE);
/* displayinit MUST PRECEDE ALL PRINTK! */
console_init();
post_code(0x39);
printk_notice(LinuxBIOS-%s%s %s %s...\n,
linuxbios_version, linuxbios_extra_version, linuxbios_build,
(boot_complete)?rebooting:booting);
post_code(0x40);
/* If we have already booted attempt a hard reboot */
if (boot_complete) {
hard_reset();
}
init_timer(); /* needs to be moved into static configuration */
CONFIGURE(CONF_PASS_PRE_PCI);
/* pick how to scan the bus. This is first so we can get at memory
size. */
printk_info(Finding PCI configuration type.\n);
pci_set_method();
post_code(0x5f);
enumerate_static_devices();
dev_enumerate();
post_code(0x66);
/* Now do the real bus.
* We round the total ram up a lot for thing like the SISFB, which
* shares high memory with the CPU.
*/
dev_configure();
post_code(0x88);
dev_enable();
dev_initialize();
post_code(0x89);
CONFIGURE(CONF_PASS_POST_PCI);
/* Now that we have collected all of our information
* write our configuration tables.
*/
lb_mem = write_tables();
CONFIGURE(CONF_PASS_PRE_BOOT);
elfboot(lb_mem);
}
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: : CPU refactoring status....
YhLu [EMAIL PROTECTED] writes: The hardwaremain become more tidy. How about the progress about the romcc? I hope I can enable debug info while include all ati support stuff. The major bug that was causing the core dump is fixed. As far as improving the optimizations things are working well enough it is not killing me at the moment. At this point I feel more urgency for getting the APIs in the freebios2 tree to the point where we can comfortably freeze them. Thinking about it size is a significant factor so if I can't reduce the about of inlining in romcc we have some structural changes that are needed at least on x86. So that needs to come before a final freeze as well. YHLu your mailer currently breaks threads, because it does include a references line for older messages. Could see if that can be fixed? It makes it hard to keep all of the pieces of a conversation together. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
ron minnich [EMAIL PROTECTED] writes: Eric, would it make sense for you to send a few of us the tree so we can take a look and see what it will involve? I'm concerned about the EPIA port. i'd like to take a week or two on this if needed to make sure we are all good on it. It looks like a very useful set of changes. Thinking about this some more. I think what makes the most sense is for me to create a branch on of the freebios2 tree and check the code in there. That way everyone will have access to it, but nothing will immediately break. Then we can take and merge everything into the mainline once the code reviews and whatever are completed. I need to purge the nda bits from my tree before I give it to anyone, anyway. Ron does a branch sound good? Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
On 8 Jul 2004, Eric W. Biederman wrote: Ron does a branch sound good? works for me! ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
[EMAIL PROTECTED] (Eric W. Biederman) writes:
The next big task is to get make the SMP cpu initialization methods
normal device tree methods. I have everything ready to do that
except I need a good way to get the information in the struct
mem_range array by sizeram(). My gut feel is that I want to
incorporate the sizeram functionality into the resource allocator,
Moving sizeram into read_resources/set_resources comes out fairly
clean, but it did require some grunt work.
That has allowed me to sort out the device tree and have a fairly
generic method of initializing cpus. Cpus don't fit into device
model methods as nicely as I would like (largely because their
methods have to run on the cpu in question). But it does work
well enough I can remove the special case from hardwaremain.
I still have a special case in the root_device methods but
that can be overridden, if necessary.
Because I have restructured where things fall in the device tree.
Because I have removed the sizeram call.
Because I have refactored x86 cpu handling.
Because I have removed the array initial_apic_id.
Every port in the tree is likely to break when I check this code in.
I have the arima/hdama working and I can with a little care
fix up the k8 based ports.
I can also likely fixup the recent e7501 forward port from the
freebios tree.
However beyond that I don't have testing resources to fix things up
so I am looking for some feedback before I break everything.
When in the next week or so is a good time?
Does any one have concerns about this set of changes?
I have attached my current version of hardwaremain below
to give a feel of what the changes look like.
Ok now I am off to bed. Before I commit anything I am going to let
the code sit a little.
Good Night,
Eric
/*
* C Bootstrap code for the LinuxBIOS
*/
#include console/console.h
#include mem.h
#include version.h
#include boot/tables.h
#include device/device.h
#include device/pci.h
#include device/chip.h
#include delay.h
#include stdlib.h
#include part/hard_reset.h
#include boot/elf.h
void hardwaremain(int boot_complete)
{
/* the order here is a bit tricky. We don't want to do much of
* anything that uses config registers until after PciAllocateResources
* since that function also figures out what kind of config strategy
* to use (type 1 or type 2).
* so we turn on cache, then worry about PCI setup, then do other
* things, so that the other work can use the PciRead* and PciWrite*
* functions.
*/
struct lb_memory *lb_mem;
post_code(0x80);
CONFIGURE(CONF_PASS_PRE_CONSOLE);
/* displayinit MUST PRECEDE ALL PRINTK! */
console_init();
post_code(0x39);
printk_notice(LinuxBIOS-%s%s %s %s...\n,
linuxbios_version, linuxbios_extra_version, linuxbios_build,
(boot_complete)?rebooting:booting);
post_code(0x40);
/* If we have already booted attempt a hard reboot */
if (boot_complete) {
hard_reset();
}
init_timer(); /* needs to be moved into static configuration */
CONFIGURE(CONF_PASS_PRE_PCI);
/* pick how to scan the bus. This is first so we can get at memory size. */
printk_info(Finding PCI configuration type.\n);
pci_set_method();
post_code(0x5f);
enumerate_static_devices();
dev_enumerate();
post_code(0x66);
/* Now do the real bus.
* We round the total ram up a lot for thing like the SISFB, which
* shares high memory with the CPU.
*/
dev_configure();
post_code(0x88);
dev_enable();
dev_initialize();
post_code(0x89);
CONFIGURE(CONF_PASS_POST_PCI);
/* Now that we have collected all of our information
* write our configuration tables.
*/
lb_mem = write_tables();
CONFIGURE(CONF_PASS_PRE_BOOT);
elfboot(lb_mem);
}
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
ron minnich [EMAIL PROTECTED] writes: Eric, would it make sense for you to send a few of us the tree so we can take a look and see what it will involve? I'm concerned about the EPIA port. Sure. Not a problem. I will see what I can put together in the next couple of days. i'd like to take a week or two on this if needed to make sure we are all good on it. It looks like a very useful set of changes. Sounds like a reasonable time line. The biggest advantage I see (besides making cpu initialization more maintainable) is that it reduces the amount of unconditional generic code. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
Eric, would it make sense for you to send a few of us the tree so we can take a look and see what it will involve? I'm concerned about the EPIA port. i'd like to take a week or two on this if needed to make sure we are all good on it. It looks like a very useful set of changes. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: CPU refactoring status....
Ok before I head to bed and get some sleep here is a quick status update of my refactoring the cpu initialization code. The cpu tree for x86 cpu now looks like: cpu/x86/mtrr cpu/x86/lapic cpu/x86/fpu cpu/x86/mmx cpu/x86/sse ... One directory for each generic feature we may want to reuse cpu/intel/model_f0x/ cpu/intel/model_f1x/ cpu/intel/model_f2x/ cpu/intel/model_f3x/ ... One directory for each core that is supported. The numbers are the significant bits from cpuid. Stepping differences are conglerated together. cpu/intel/socket_mPGA603/ cpu/intel/socket_mPGA604_533Mhz/ cpu/intel/socket_mPGA604_800Mhz/ ... One directory for each socket we support. These will use the dir directive to suck in the appropriate cores. cpu/amd/model_fxx/ ... So far for Opteron AMD really only has one core, with multiple steppings cpu/amd/socket_940/ cpu/amd/socket_939/ cpu/amd/socket_754/ ... But there are currently 3 sockets I need to support. cpu/x86/socket7 ... Generic sockets supported my multiple vendors go here. arch/i386/lib/cpu.c now computes the vendor and device information of each cpu with cpuid. And then looks up the appropriate code in a table. I have sorted out cpus in the device tree and assigning their apic id's in the static tree. The next big task is to get make the SMP cpu initialization methods normal device tree methods. I have everything ready to do that except I need a good way to get the information in the struct mem_range array by sizeram(). My gut feel is that I want to incorporate the sizeram functionality into the resource allocator, we will see. As for the rest of the pieces I have started on there are still a lot of details to flesh out but the with the structure there it is just a matter of taking the time to do everything. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
