Eric,
When can you commit cpu releated changes in the public tree?
Please advise if I could commit E7501/P62h2/82801EB-R into the v2 now or after you commit CPU stuffs.
Regards
YH
-----邮件原件----- 发件人: ebiederman@lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年6月25日 17:27 收件人: YhLu 抄送: ron minnich; Stefan Reinauer; LinuxBIOS 主题: Re: E7501 support in V2
YhLu YhLu@tyan.com writes:
Eric,
I find the problem, need to call init_timer in p6 cpu fixup. It works well now.
Some code should be moved to p6 or even p5.
For example: apic_timper.c enable_mmx_sse.inc/disable_mmx_sse.inc
Except for the Opteron init_timer is really not appropriate as a cpu thing. In general it is a motherboard type decision. It is one of the rough areas in V2 right now.
For the rest you can see why I am in the process of reworking the cpu initialization code.
Eric
YhLu YhLu@tyan.com writes:
Eric,
When can you commit cpu releated changes in the public tree?
It is going to be a little while yet. Cleanups take a little while to work through. And I don't want to rush it very much because once you start using something stupid decisions are more difficult to correct.
Please advise if I could commit E7501/P62h2/82801EB-R into the v2 now or after you commit CPU stuffs.
That stuff looks largely independent. Hmm. But to make it work you have to do some cpu stuff....
Everything I am doing I am putting under cpu/x86/blah so putting in your code should not affect me. It will mean I will have to go back and correct a few more things, but I don't want to be a hold up.
Eric
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
ebiederman@lnxi.com (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); }
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
ron minnich rminnich@lanl.gov 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
ron minnich rminnich@lanl.gov 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
ron minnich rminnich@lanl.gov writes:
On 8 Jul 2004, Eric W. Biederman wrote:
Ron does a branch sound good?
works for me!
While attempting to tag the tree early today to create a branch I ran into a problem.
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.
Eric
* Eric W. Biederman ebiederman@lnxi.com [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
Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [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?
I think someone needs to log into the cvs server and fix it. Which like requires a project admin to ask the sourceforge administrators.
My hunch is that something exited abnormally quite a while ago.
Eric
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 ...
!@$#@!
ron
ron minnich rminnich@lanl.gov 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 ...
!@$#@!
Agreed. Thank you very much for taking the time to do this.
What does it involve anyway?
Eric
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
ron minnich rminnich@lanl.gov writes:
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.
src/cpu/p5/
All I have is a directory name because I was attempting to branch the CVS tree with cvs tag.
Eric
I've reciently learned that my PIRQ table isn't making it into RAM. Going through the code I see that the the last thing that hardware_main does before loading an elf image is call write_tables() which will try and copy the various tables to thier final destination.
I don't uderstand how this will work. In order for those writes to go to RAM you have to have your shadowing control set up properly. On my chipset at this stage both reads and writes to areas such as f0000 are forwarded to PCI so the write will fail.
I don't see any mention of enableing writes for these ranges to go to RAM.
Am I missing something?
On Wed, 14 Jul 2004, Richard Smith wrote:
I don't uderstand how this will work. In order for those writes to go to RAM you have to have your shadowing control set up properly. On my chipset at this stage both reads and writes to areas such as f0000 are forwarded to PCI so the write will fail.
What I do in this case is set CONFIG_COMPRESSED to 0, since if you don't have shadow ram working you're toast.
ron
ron minnich wrote:
On Wed, 14 Jul 2004, Richard Smith wrote:
I don't uderstand how this will work. In order for those writes to go to RAM you have to have your shadowing control set up properly. On my chipset at this stage both reads and writes to areas such as f0000 are forwarded to PCI so the write will fail.
What I do in this case is set CONFIG_COMPRESSED to 0, since if you don't have shadow ram working you're toast.
I don't use compression.
I've got shadow ram working fine. ADLO won't boot without it. I was just asking before I try to add something that isn't necessary.
The tables depend on shadowing yes?
On Wed, 14 Jul 2004, Richard Smith wrote:
The tables depend on shadowing yes?
no, they don't. If you don't have shadowing, and you don't have compression, then the tables will be there in FLASH and linux will find them.
I think I don't understand the problem, I misread it, so I'll go back and reread.
ron
ron minnich wrote:
On Wed, 14 Jul 2004, Richard Smith wrote:
The tables depend on shadowing yes?
no, they don't. If you don't have shadowing, and you don't have compression, then the tables will be there in FLASH and linux will find them.
I think I don't understand the problem, I misread it, so I'll go back and reread.
Ah.. I'm begining to understand. The table is pre-locaed at 0xf0000 then. That makes sense. The code then is very confusing since it says things like "Copying tables..." and then "Verifying..." and the function called write_tables(). So I just assumed it was stuck in ROM at any old location and moved to the correct position.
What address is the PIRQ table supposed to show up at?
On Wed, 14 Jul 2004, Richard Smith wrote:
Ah.. I'm begining to understand. The table is pre-locaed at 0xf0000 then. That makes sense. The code then is very confusing since it says things like "Copying tables..." and then "Verifying..." and the function called write_tables(). So I just assumed it was stuck in ROM at any old location and moved to the correct position.
yes, that code is very annoying.
What address is the PIRQ table supposed to show up at?
I know for sure Linux looks for the $PIR signature in the F segment, and one or two other places.
ron
ron minnich wrote:
things like "Copying tables..." and then "Verifying..." and the function called write_tables(). So I just assumed it was stuck in ROM at any old location and moved to the correct position.
yes, that code is very annoying.
I Look at the PIRQ code. The code that I looked at was the stuff included with HAVE_PIRQ_TABLE=1 and it most definintly _copies_ the table to 0xf0000. So for this code to work shadowing must be setup.
Unless there is some linker magic going on that actually locates the structure at that location in the ROM as well then PIRQ stuff will not work w/o shadowing.
On my build the table is located in the ROM image and will show up at 0xf2e29. Linux searches for the table from 0xf0000 to 0x100000 but only at mutiples of 0x0f. So linux will not find this table.
There must be some sort of ELF section alignment thats missing in the linking of irq_tables.o
-
ebiederman＠lnxi.com -
Richard Smith -
ron minnich -
Stefan Reinauer -
YhLu