Ron,
It seems that you roll back to the tree, because of Stefan's complain.
I want to give detail description on the coherent_ht.c and raminit.c 1. coherent_ht.c add two function: notify_bsp_ap_is_stopped. And wait_ap_stop. 2. raminit.c change csbase counting methods.
Any way you at least can put files on s2880 for me.
Also please send the Config.lb to me and I would to test the new config tool.
Thanks.
Regards
Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年7月24日 21:31 收件人: linuxbios@clustermatic.org 主题: Fixes for Tyan s2880
Yh Lu needed to add a mainboard-specific initialization code for the Tyan s2880 board, and needed it called at a special place in hardwaremain(). In V1, we would use defines and other such trickery to get this capability. We're trying to avoid that in V2.
This problem turns out to be a perfect use for the static device initialization support.
First, we apply patches that are tyan-only or are bug fixes to these files:
src/include/device/pci_ids.h src/mainboard/tyan/s2880/auto.c src/mainboard/tyan/s2880/Config src/mainboard/tyan/s2880/debug.c src/mainboard/tyan/s2880/failover.c src/mainboard/tyan/s2880/static_devices.c src/mainboard/tyan/s2880/tyan-fallback.config src/mainboard/tyan/s2880/tyan-normal.config src/mainboard/tyan/s2880/VERSION src/mainboard/tyan/VERSION src/northbridge/amd/amdk8/coherent_ht.c src/northbridge/amd/amdk8/raminit.c src/southbridge/amd/amd8111/Config src/southbridge/amd/amd8111/Config.lb src/southbridge/amd/amd8131/amd8131_bridge.c targets/tyan/s2880/Config.lb
Now, we need to ensure that YhLu's "special code" is called for his mainboard.
As it happens, the mainboard is also a "chip" in the new scheme. The config tool builds a tree based on this structure, from src/include/device/chip.h:
struct chip { struct chip_control *control; /* for this device */ char *path; /* can be 0, in which case the default is taken */ char *configuration; /* can be 0. */ int irq; struct chip *next, *children; /* there is one of these for each INSTANCE of a chip */ void *chip_info; /* the dreaded "void *" */ };
The tree for the s2880 looks like this:
===== #include <device/chip.h> struct chip static_root, static_dev1, static_dev2, static_dev3, static_dev4, sta tic_dev5, static_dev6, static_dev7, static_dev8, static_dev9, static_dev10; #include "/home/rminnich/src/bios/freebios2/src/mainboard/tyan/s2880/chip.h"
struct chip static_root = { /* mainboard /home/rminnich/src/bios/freebios2/src/mainboard/tyan/s2880 */ .children = &static_dev9, }; struct chip static_dev9 = { /* cpu /home/rminnich/src/bios/freebios2/src/cpu/k8 */ .next = &static_dev8, };
. . .
======
(the rest is removed for clearness)
Note that there are even "chips" for CPUs: it is possible to handle CPU fixup in this system.
Each entry in the above structures defines a static device.
Please recall that static devices consist of a generic structure and then special-purpose (device specific) structures.
The generic structure is this: /* there is one of these for each TYPE of chip */ struct chip_control { void (*enable)(struct chip *, enum chip_pass); char *path; /* the default path. Can be overridden * by commands in config */ // This is the print name for debugging char *name; };
Device-specific classes are defined by the attributes of the device, and hence vary for each device. In the V1 days, we tried to have one generic structure, but that did not even work for the limited case of superio's, so for V2 we are making the structure unique to each device.
We have to define one device structure for the Tyan s2880. The structure has to be defined in an include file that is in the directory that contains the code for the device. So, for the tyan s2880 mainboard, we need to have a definition file in src/mainboard/tyan/s2880. We'll call it src/mainboard/tyan/s2880/chip.h.
In this case, it is rather simple:
struct mainboard_tyan_s2880_config { int fixup_scsi; };
This is the only thing we're controlling at present. Note that the name of the struct is a 'flattened' version of the device name.
We need to tell the config tool where to find the file containing the structure, and how to initialize the struct in the file. Add these lines to src/tyan/s2880/Config.lb. They will define the name of the file to use, and the code to initialize the static device.
config chip.h register "fixup_scsi" = "1"
We need to create the structure that defines the generic structure for the mainboard, so linuxbios can hook into it. So add these lines to the end of src/mainboard/tyan/s2880/mainboard.c:
struct chip_control mainboard_tyan_s2880_control = { enable: enable, name: "Tyan s2880 mainboard " };
Then add the enable function (BEFORE the struct chip_control declaration). Note that it is declared 'static', and has only one entry in the switch.
static void enable(struct chip *chip, enum chip_pass pass) {
struct mainboard_tyan_s2880_config *conf = (struct mainboard_tyan_s2880_config *)chip->chip_info;
switch (pass) { default: break; case CONF_PASS_PRE_BOOT: if (conf->fixup_scsi) onboard_scsi_fixup(); printk_debug("mainboard fixup pass %d done\r\n", pass); break; }
}
That's pretty much it. total changes are 170 lines. The static device tree (which is generated by the config tool, you don't have to write this code) now looks like this:
========== #include <device/chip.h> struct chip static_root, static_dev1, static_dev2, static_dev3, static_dev4, sta tic_dev5, static_dev6, static_dev7, static_dev8, static_dev9, static_dev10; #include "/home/rminnich/src/bios/freebios2/src/mainboard/tyan/s2880/chip.h" extern struct chip_control mainboard_tyan_s2880_control; struct mainboard_tyan_s2880_config mainboard_tyan_s2880_config_0 = { .fixup_scsi = 1, };
struct chip static_root = { /* mainboard /home/rminnich/src/bios/freebios2/src/mainboard/tyan/s2880 */ .children = &static_dev9, .control= &mainboard_tyan_s2880_control, .chip_info = (void *) &mainboard_tyan_s2880_config_0, }; struct chip static_dev9 = { /* cpu /home/rminnich/src/bios/freebios2/src/cpu/k8 */ .next = &static_dev8, }; =====
Note that the mainboard now has several new entries, and there is a new struct for controlling the mainboard, along with an initializer. The enable function for the mainboard will be called at several
places in hardwaremain with a different pass #, and since there is only one case defined, only one action is taken.
So to add this capability for this mainbard, we had to: - define a file containing the device-specific structure which we called chip.h, and placed in src/mainboard/tyan/s2880 - add two lines to src/mainboard/tyan/s2880/Config.lb, which define the file we need (chip.h) and the initialization of the structure. - add the "base class" structure to src/mainboard/tyan/s2880/mainboard.c, along with the enable function.
I've built this mainboard and hexdump of the romimage looks pretty good. Yh Lu, can you please verify this? The config.lb is in targets/tyan/s2880/Config.lb. I can send the context diffs if that will help.
Note that this technique will work for anything that the config tool considers a 'device': mainboard, cpu, north and south bridge, superio, etc.
Thanks
ron
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Fri, 25 Jul 2003, YhLu wrote:
It seems that you roll back to the tree, because of Stefan's complain.
no, I did not roll anything back. Did something roll back?
Or are you seeing the 24-hour sourceforge.net delay?
ron
Ron,
The image that is built via the new config tool can work as the old config tools last night. CHIP_CONFIGURE is workable too. It will be very useful to device config or disable some device.
I can send you the diff next Monday if you want.
I add LINUXBIOS_EXTRA_VERSION to the Option.lb in the config. Use that We can diff from normal boot to fallback boot in the output.
Change some #ifdef to #if CONFIG_SMP==1....
Also please verify 1. Several CONFIG_MAX_CPUS using in the source code, You may need to select one from CONFIG_MAX_CPUS and MAX_CPUS.....CONFIG_MAX_PHYSICAL_CPUS..... Since all SMP have been changed to CONFIG_SMP, and Will you use CONFIG_MAX_CPUS etc instead of MAX_CPUS etc... 2. Config.lb in arch/i386/smp, missed secondary.S.need to remove the #. 3. _RAMBASE default is 0x100000 in the new Config , and it is not working with SMP. In hardwaremain(), can not start the second CPU. Need to change to 0x4000 as the old config tool did. 4. You need to remove make.base.lb, since the function has been replaced by the above Config.lb. the rule control make linuxbios.rom.
Regards
Yinghai Lu
-----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年7月25日 14:44 收件人: YhLu 主题: Re: Fixes for Tyan s2880
On Fri, 25 Jul 2003, YhLu wrote:
- I have tried to add lines
In targets/tyan/s2880/Config.lb
Uses CONFIG_LSI_SCSI_FW_FIXUP Option CONFIG_LSI_SCSI_FW_FIXUP=1
you shouldn't need to do that at all. What code depends on it?
As I set up the code, this should just be working right now. We need to talk about what you need to do, I may have gotten part of it wrong.
- Another problem:
In Makefile newconfig tool it creates, it says "linuxbios.rom: linuxbios.strip buildrom ./buildrom $< $@ $(PAYLOAD) $(ROM_IMAGE_SIZE) $(ROM_SIZE)"
can you change ROM_SIZE to ROM_SECTION_SIZE?
committed.
You also changes the standing for linuxbios.rom. old tool it doesn't
include
pay load and only romimage include payload, if so you should discard romimage define.
fixed and committed.
Thanks very much for working with the new tool.
ron
What's the deal with Intel's firmware hubs? The status file for Clearwaters seems to indicate that only an Intel firmware hub will do.. Is that the case, or should I still be able to use a standard plcc flash part? This is an unforseen snag for someone without a flash programmer..
- Adam Agnew
On Sat, 26 Jul 2003, Adam Agnew wrote:
What's the deal with Intel's firmware hubs? The status file for Clearwaters seems to indicate that only an Intel firmware hub will do.. Is that the case, or should I still be able to use a standard plcc flash part? This is an unforseen snag for someone without a flash programmer..
you have to use the 82801ab or ac parts. They are easy to get, I got mine from avnet.
BE SURE to ask for N82801AB or N82801AC. Their search tools need the exact name.
ron
Greetings,
It needs to be a firmware hub as far as I can tell. Those do come in 4 and 8MBIT PLCC versions. From a software standpoint, they behave the same as any other flash part, it's just something in the electrical specs. SST makes a compatible part (I can check the part number when I get in tomorrow.
G'day, sjames
On Sat, 26 Jul 2003, Adam Agnew wrote:
What's the deal with Intel's firmware hubs? The status file for Clearwaters seems to indicate that only an Intel firmware hub will do.. Is that the case, or should I still be able to use a standard plcc flash part? This is an unforseen snag for someone without a flash programmer..
- Adam Agnew
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
any other flash part, it's just something in the electrical specs. SST
I think you're right there. The datasheet for the 82802s shows that they're all 3.3v while a myriad of datasheets i found for other plcc flash parts were 5v. Good to know. It seems AMD offers a line of low voltage flash parts as SST must too. Thanks Steven.
- Adam Agnew
* Adam Agnew agnew@cs.umd.edu [030728 01:31]:
any other flash part, it's just something in the electrical specs. SST
I think you're right there. The datasheet for the 82802s shows that they're all 3.3v while a myriad of datasheets i found for other plcc flash parts were 5v. Good to know. It seems AMD offers a line of low voltage flash parts as SST must too. Thanks Steven.
the 49* types should all be 3.3v as well. but i am not sure the pinout is the same..
Stefan
On Sun, 27 Jul 2003, Adam Agnew wrote:
I think you're right there. The datasheet for the 82802s shows that they're all 3.3v while a myriad of datasheets i found for other plcc flash parts were 5v. Good to know. It seems AMD offers a line of low voltage flash parts as SST must too. Thanks Steven.
no, the 82802ac uses address-address multiplexing to get up to 27 bits of address. They are a synchronous part whereas many flashes we have used to date are not. So the bus, clocking, and timing are nothing like the parts we've used on other platforms.
You can only program an 82802ac on a board with support for firmware hub.
ron
On Sat, 26 Jul 2003, Yinghai Lu wrote:
I can send you the diff next Monday if you want.
please do.
I add LINUXBIOS_EXTRA_VERSION to the Option.lb in the config. Use that We can diff from normal boot to fallback boot in the output.
very cool.
Change some #ifdef to #if CONFIG_SMP==1....
thanks, we're still working on them.
Also please verify
- Several CONFIG_MAX_CPUS using in the source code, You may need to
select one from CONFIG_MAX_CPUS and MAX_CPUS.....CONFIG_MAX_PHYSICAL_CPUS..... Since all SMP have been changed to CONFIG_SMP, and Will you use CONFIG_MAX_CPUS etc instead of MAX_CPUS etc...
Eric and Stefan, please pick a name and let us know what it should be. Are CONFIG_MAX_CPUS and CONFIG_MAX_PHYSICAL_CPUS the same or different (I'm guessing different due to hyperthreading)?
- Config.lb in arch/i386/smp, missed secondary.S.need to remove the #.
I fixed this too, please make sure you have it as I have comitted it.
- _RAMBASE default is 0x100000 in the new Config , and it is not
working with SMP. In hardwaremain(), can not start the second CPU. Need to change to 0x4000 as the old config tool did.
Done and committed. Eric, Stefan, please make sure this is not a problem for you, but it looks harmless to me.
- You need to remove make.base.lb, since the function has been replaced
by the above Config.lb. the rule control make linuxbios.rom.
Done and committed.
I thank you for using the new tool. We intend to make further changes this week as requested by Stefan. I am on vacation so this will not happen as quickly as I would wish, but it should happen. I think we are getting closer to the goals we set for the new tool. I know Greg is very happy with it for his use on PPC.
thanks
ron
* ron minnich rminnich@lanl.gov [030728 06:38]:
Eric and Stefan, please pick a name and let us know what it should be. Are CONFIG_MAX_CPUS and CONFIG_MAX_PHYSICAL_CPUS the same or different (I'm guessing different due to hyperthreading)?
I agree. Naming CONFIG_MAX_CPUS CONFIG_MAX_LOGICAL_CPUS would imply that there is a number of max. physical cpus as well.
Stefan