Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030902 19:28]:
If you want all of your hypertransport devices to be on bus 0, that is feasible but it will take a little more work. Right now each hypertranport chain get's it's own bus.
What is missing to achieve this?
Just a little code. Merging busses into bus 0 is an interesting logicistics feat, but the current infrastructure will allow it.
Can this cause trouble with current board implementations?
Not it is software only.
In the Tyan update code, some hardcoded bus numbers were changed.
We should be able to complete remove that. Right now each Hypertransport chains appears to be it's own bus and all of that information is dynamically calculated.
The busses that are Hypertranpsort chains are enumerated just like other busses.
The way to look at the code is that: - device.c has the logic to enumerate and assign resources to devices and busses. - pci_device.c has the methods for doing that on pci devices. - hypertransport.c has the methods for doing that with hypertranport devices. - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific northbridge.
In short dynamic resource assignment should now be pretty simple and should remove the need for most of the hard codes.
I have committed the code not in a final perfect state. But in a state where it works well enough to be useful. And whatever details we encounter are minor things.
Passing information to the dynamic device tree from the static device tree is currently a weak area. But we are building one tree from the other so it is just a matter of a small amount of refactoring if we want to do something better.
Basically what remains is to dive into the code see what it is doing, and tweak it a little if is not doing quite the right thing. But usually all that needs to happen is to improve a method of a device so that it operates better.
Eric
OK, this commit works for me. Not completely, but well enough to say it's good enough.
The only problem is the usual PIRQ fun. I'm going to try to work out a reasonable solution given time.
ron
ron minnich rminnich@lanl.gov writes:
OK, this commit works for me. Not completely, but well enough to say it's good enough.
The only problem is the usual PIRQ fun. I'm going to try to work out a reasonable solution given time.
Cool that sounds about right. There is a very real chance I might reverse the order of the devices on the hypertransport chain. So I can allocate from the top of the unitid space instead of from the bottom. With that it will be easier to cram all of the hypertransport chains into bus 0 cleanly.
So we really need to find a way to move irq information to the static to the dynamic device tree. That is one of the harder remaining problems.
It is not a show stopper but something we need to do before we are done.
Eric
The way to look at the code is that:
- device.c has the logic to enumerate and assign resources to devices and busses.
- pci_device.c has the methods for doing that on pci devices.
- hypertransport.c has the methods for doing that with hypertranport devices.
- northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific northbridge.
In short dynamic resource assignment should now be pretty simple and should remove the need for most of the hard codes.
Ok, thanks for the clarification.
The config file for the hdama looks like follows: northbridge amd/amdk8 "mc0" pci 0:18.0 pci 0:18.0 pci 0:18.0 pci 0:18.1 pci 0:18.2 pci 0:18.3 southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 pci 0:1.1 pci 0:1.2 pci 0:1.3 pci 0:1.5 pci 0:1.6 superio NSC/pc87360 [..] end end end
northbridge amd/amdk8 "mc1" pci 0:19.0 pci 0:19.0 pci 0:19.0 pci 0:19.1 pci 0:19.2 pci 0:19.3 end
cpu k8 "cpu0" register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" end
cpu k8 "cpu1" end
What's the meaning of the "pci" command? why are some mentioned multiple times? (0:18.0, 0:19.0)
I started digging through the code, but I am not completely there yet. It seems to me it would make sense to move the register "up" information from cpu k8 "cpu0" to the northbridge amd/amdk8 "mc0" definition since its information associated with the used southbridges.
There is currently no information on how the amd8131 and 8151 are actually linked.
Does it look like this? :
8111 | 8131 | CPU0 -- CPU1
In this case it could be needed to describe to which link of the 8131 the 8111 is connected?! Would the link speed between 8131 and 8111 be set correctly with the current code?
Same thing applies for the 8151 that is used in the tyan and solo boards. The link speed is currently written by src/southbridge/amd/amd8151/amd8151_agp3.c
If the code is already covered by the new ht code it could be removed from the 8151 code. If this constellation is not possible, amd8151_agp3.c should read the link values from static.c - What is the better solution?
Stefan
On Wed, 3 Sep 2003, Stefan Reinauer wrote:
pci 0:18.0
one thing I'd still like to see as long as we are declaring these pci slots: why not have the IRQ routing in there?
pci 0:18.o A=B, B=C, C=D, D=A
that way, we'd have info to build PIRQ.
any reason not to do this?
ron
ron minnich rminnich@lanl.gov writes:
On Wed, 3 Sep 2003, Stefan Reinauer wrote:
pci 0:18.0one thing I'd still like to see as long as we are declaring these pci slots: why not have the IRQ routing in there?
pci 0:18.o A=B, B=C, C=D, D=A
that way, we'd have info to build PIRQ.
any reason not to do this?
Nope. The only reason it is not done is that no one has gotten there yet.
There are a few practical issues with not specifying the interrupt controller an irq goes to though...
Eric
Stefan Reinauer stepan@suse.de writes:
The way to look at the code is that:
- device.c has the logic to enumerate and assign resources to devices and
busses.
- pci_device.c has the methods for doing that on pci devices.
- hypertransport.c has the methods for doing that with hypertranport devices.
- northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific northbridge.
In short dynamic resource assignment should now be pretty simple and should remove the need for most of the hard codes.
Ok, thanks for the clarification.
The config file for the hdama looks like follows: northbridge amd/amdk8 "mc0" pci 0:18.0 pci 0:18.0 pci 0:18.0 pci 0:18.1 pci 0:18.2 pci 0:18.3 southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 pci 0:1.1 pci 0:1.2 pci 0:1.3 pci 0:1.5 pci 0:1.6 superio NSC/pc87360 [..] end end end
northbridge amd/amdk8 "mc1" pci 0:19.0 pci 0:19.0 pci 0:19.0 pci 0:19.1 pci 0:19.2 pci 0:19.3 end
cpu k8 "cpu0" register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" end
cpu k8 "cpu1" end
What's the meaning of the "pci" command? why are some mentioned multiple times? (0:18.0, 0:19.0)
First the most basic result I have is that I need to know what all of the logical devices that come out of a chip are.
So off of each logical device I have one or more channels. The only way I could think of to describe multiple channels is to repeat the logical device in the configuration file.
All of the logical device paths are relative to the device they are hanging off of (it just looks like the bus number). So to say the amd/amd8131 was hanging off of the second hypertransport link I would change it's logical devices to:
southbridge amd/amd8131 "amd8131" pci 1:0.0 pci 1:0.1 pci 1:1.0 pci 1:1.1 end
I am not saying that is the best way to go, but it currently works.
I started digging through the code, but I am not completely there yet. It seems to me it would make sense to move the register "up" information from cpu k8 "cpu0" to the northbridge amd/amdk8 "mc0" definition since its information associated with the used southbridges.
The register "up" is something that has not been used at all yet. Personally I am not comfortable with the fact that we have both cpu and northbridge instances for the cpus..
There is currently no information on how the amd8131 and 8151 are actually linked.
Yes there is, but it is mostly implicit.
Does it look like this? :
8111 | 8131 | CPU0 -- CPU1
Yes. The order of the device structures is significant.
In this case it could be needed to describe to which link of the 8131 the 8111 is connected?! Would the link speed between 8131 and 8111 be set correctly with the current code?
Yes. Except I don't yet have a way to automatically down clock it from 800Mhz which it claims it can do but cannot.
Same thing applies for the 8151 that is used in the tyan and solo boards. The link speed is currently written by src/southbridge/amd/amd8151/amd8151_agp3.c
If the code is already covered by the new ht code it could be removed from the 8151 code.
Sounds good.
If this constellation is not possible, amd8151_agp3.c should read the link values from static.c - What is the better solution?
Since it is already covered and it can be done automatically I would go there.
Eric
* Eric W. Biederman ebiederman@lnxi.com [030903 17:47]:
First the most basic result I have is that I need to know what all of the logical devices that come out of a chip are.
So off of each logical device I have one or more channels. The only way I could think of to describe multiple channels is to repeat the logical device in the configuration file.
All of the logical device paths are relative to the device they are hanging off of (it just looks like the bus number). So to say the amd/amd8131 was hanging off of the second hypertransport link I would change it's logical devices to:
southbridge amd/amd8131 "amd8131" pci 1:0.0 pci 1:0.1 pci 1:1.0 pci 1:1.1 endI am not saying that is the best way to go, but it currently works.
Ah. this is fine and allows porting linuxbios easily to new opteron mainboards. I see some drawbacks:
* the logical devices of the amd8131 pci-x bridge has to be described in the mainboard configuration file. This means a lot of duplicate config "code" spread over the mainboard directory. Can this somehow go to the Config.lb file in southbridge/amd/amd8131/ ?
* The device description itself and the link (channel?) information is intermixed (preventing above config change from happening)
* link information is duplicate. This might be a feature though when devices happen that connect to more than one link. (Is this theoretically possible, i.e. to raise bandwidth?)
The register "up" is something that has not been used at all yet. Personally I am not comfortable with the fact that we have both cpu and northbridge instances for the cpus..
This looks weird for the opteron case, true. But most architectures still don't come with an on-cpu northbridge, so keeping that seperated might be a good idea (in case a certain northbridge can cope with several cpu types)
Does it look like this? :
8111 | 8131 | CPU0 -- CPU1
Yes. The order of the device structures is significant.
should this:
southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 [..] end
not rather look like this then: ?
southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end
Yes. Except I don't yet have a way to automatically down clock it from 800Mhz which it claims it can do but cannot.
this seems only like a matter of the information not being parsed from an appropriate place in the config file yet.
Same thing applies for the 8151 that is used in the tyan and solo boards. The link speed is currently written by src/southbridge/amd/amd8151/amd8151_agp3.c
If the code is already covered by the new ht code it could be removed from the 8151 code.
Sounds good.
YhLu? Can you confirm that link speeds to AGP are ok without that code? Does anyone have an appropriate method of testing the actual link speed and/or width between any pair of devices?
Stefan
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030903 17:47]:
First the most basic result I have is that I need to know what all of the logical devices that come out of a chip are.
So off of each logical device I have one or more channels. The only way I could think of to describe multiple channels is to repeat the logical device in the configuration file.
All of the logical device paths are relative to the device they are hanging off of (it just looks like the bus number). So to say the amd/amd8131 was hanging off of the second hypertransport link I would change it's logical devices to:
southbridge amd/amd8131 "amd8131" pci 1:0.0 pci 1:0.1 pci 1:1.0 pci 1:1.1 endI am not saying that is the best way to go, but it currently works.
Ah. this is fine and allows porting linuxbios easily to new opteron mainboards. I see some drawbacks:
- the logical devices of the amd8131 pci-x bridge has to be described in the mainboard configuration file. This means a lot of duplicate config "code" spread over the mainboard directory. Can this somehow go to the Config.lb file in southbridge/amd/amd8131/ ?
Yes. But at the same time everything there is explicit and up front. Which is not necessarily a bad thing. It is very hard to see what is going on if you introduce a level of indirection here to be more sparse.
I have tried for the most part to ensure that if you don't mention a logical device it still turns up. It is just that you can not feed it any static configuration if it is not mentioned.
- The device description itself and the link (channel?) information is intermixed (preventing above config change from happening)
I introduced channel because that is a concept that is purely in the configuration. How that maps to hardware capabilities can vary. Think a pci bridge chip with 8 pci busses hanging off of it, for the kinds of problem I was trying to solve.
- link information is duplicate. This might be a feature though when devices happen that connect to more than one link. (Is this theoretically possible, i.e. to raise bandwidth?)
A little.
The register "up" is something that has not been used at all yet. Personally I am not comfortable with the fact that we have both cpu and northbridge instances for the cpus..
This looks weird for the opteron case, true. But most architectures still don't come with an on-cpu northbridge, so keeping that seperated might be a good idea (in case a certain northbridge can cope with several cpu types)
Right. Which is why I have not messed with it yet.
I have just stared with a rough draft that works. I don't have problems with changing it, so long as all of the requirements are met.
Does it look like this? :
8111 | 8131 | CPU0 -- CPU1
Yes. The order of the device structures is significant.
should this:
southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 [..] endnot rather look like this then: ?
southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end
Quite possibly. A hypertransport chain is a weird case. For the moment I am treating it like a weird pci bus, and that seems to work... But further nesting might not be bad with the right set of changes.
Yes. Except I don't yet have a way to automatically down clock it from 800Mhz which it claims it can do but cannot.
this seems only like a matter of the information not being parsed from an appropriate place in the config file yet.
Yep, pretty much. Although for bug fixes I would like it if the configuration file didn't have to be involved. Just the driver for the 8131 saying that it can't do 800Mhz which is a slightly different thing.
Eric
On 3 Sep 2003, Eric W. Biederman wrote:
- the logical devices of the amd8131 pci-x bridge has to be described in the mainboard configuration file. This means a lot of duplicate config "code" spread over the mainboard directory. Can this somehow go to the Config.lb file in southbridge/amd/amd8131/ ?
Yes. But at the same time everything there is explicit and up front. Which is not necessarily a bad thing. It is very hard to see what is going on if you introduce a level of indirection here to be more sparse.
One of the goals of the new tool was to bring everything up to the top level. People were getting lost in the maze of include files and option settings. The disadvantage, as you point out, is some duplicated code, but the advantages have so far outweighed that disadvantage.
In this case duplicated code is actually not too bad, as the hardware that the code describes will not change for a given board.
Quite possibly. A hypertransport> > southbridge amd/amd8131 "amd8131"
pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end
chain is a weird case. For the
moment I am treating it like a weird pci bus, and that seems to work... But further nesting might not be bad with the right set of changes.
Ah, this is a chain and not a true parent/child case? I'm still getting the hang of HT, obviously.
ron
* ron minnich rminnich@lanl.gov [030904 16:22]:
One of the goals of the new tool was to bring everything up to the top level. People were getting lost in the maze of include files and option settings. The disadvantage, as you point out, is some duplicated code, but the advantages have so far outweighed that disadvantage.
In this case duplicated code is actually not too bad, as the hardware that the code describes will not change for a given board.
I agree.. but right now there are still Config.lb files in the mainboard and in the targets directory. And at least last time I checked both were used.
Stefan
On Thu, 4 Sep 2003, Stefan Reinauer wrote:
I agree.. but right now there are still Config.lb files in the mainboard and in the targets directory. And at least last time I checked both were used.
possibly I am missing your point. What bits did you want to see in mainboard/Config.lb that are in the target?
ron
* ron minnich rminnich@lanl.gov [030904 17:49]:
On Thu, 4 Sep 2003, Stefan Reinauer wrote:
I agree.. but right now there are still Config.lb files in the mainboard and in the targets directory. And at least last time I checked both were used.
possibly I am missing your point. What bits did you want to see in mainboard/Config.lb that are in the target?
There are some things that are in both Config.lb files. Some of these make sense as a board default that gets overwritten by the image config file, keeping the idea in mind that whoever builds an image for a certain mainboard has to change/create a targets/ Config.lb, but does not have to care about the mainboards/Config.lb. When porting LinuxBIOS to a new board for a known platform, it should be the other way round.
Still, I am uncertain what belongs where ...
uses XIP_ROM_SIZE uses XIP_ROM_BASE [..] option CONFIG_CHIP_CONFIGURE=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option k7=1 option k8=1 option _RAMBASE=0x00004000
These are currently found in the arima targets-Config.lb but they seem pretty much mainboard specific, not build specific.
Left for the targets config file would be: * console loglevels * console output (serial, vga, ..) * rom/ide streaming (is anything but rom streaming still supported?) * fallback/normal image builds: size, payloads * option table
Whats the difference between option FALLBACK_SIZE=131072 and the option option ROM_IMAGE_SIZE=0x10000
in the romimage "fallback" group? Both sound like they do similar things.
I had trouble getting a build to work with a kernel (800k) in the normal image and etherboot (~20k) in the fallback image. Do the payload image sizes have to be the same for fallback and normal?
I'll investigate further..
Stefan
Any inconsistencies you find in the options are most certainly real. :-)
Much of the confusion comes from the configuration setup in the old tree which allowed options to be specified and set in any config file. The result was that many options were duplicated because their definition was buried in some device specific directory somewhere. This is the main reason we now use a global options file so that at least everything is in one place.
As it stands there is also no way to distinguish between which options should be set in the target config file and which in the mainboard config, except by convention. It would be relatively easy to add a flag to the option to enforce this if it was felt to be desirable.
In any case, please feel free to continue to clean up the option situation as it is long overdue.
BTW, I use IDE streaming on the PPC boards.
Regards,
Greg
At 3:26 PM +0200 8/9/03, Stefan Reinauer wrote:
- ron minnich rminnich@lanl.gov [030904 17:49]:
On Thu, 4 Sep 2003, Stefan Reinauer wrote:
I agree.. but right now there are still Config.lb files in the mainboard and in the targets directory. And at least last time I checked both were used.
possibly I am missing your point. What bits did you want to see in mainboard/Config.lb that are in the target?
There are some things that are in both Config.lb files. Some of these make sense as a board default that gets overwritten by the image config file, keeping the idea in mind that whoever builds an image for a certain mainboard has to change/create a targets/ Config.lb, but does not have to care about the mainboards/Config.lb. When porting LinuxBIOS to a new board for a known platform, it should be the other way round.
Still, I am uncertain what belongs where ...
uses XIP_ROM_SIZE uses XIP_ROM_BASE [..] option CONFIG_CHIP_CONFIGURE=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option k7=1 option k8=1 option _RAMBASE=0x00004000
These are currently found in the arima targets-Config.lb but they seem pretty much mainboard specific, not build specific.
Left for the targets config file would be:
- console loglevels
- console output (serial, vga, ..)
- rom/ide streaming (is anything but rom streaming still supported?)
- fallback/normal image builds: size, payloads
- option table
Whats the difference between option FALLBACK_SIZE=131072 and the option option ROM_IMAGE_SIZE=0x10000
in the romimage "fallback" group? Both sound like they do similar things.
I had trouble getting a build to work with a kernel (800k) in the normal image and etherboot (~20k) in the fallback image. Do the payload image sizes have to be the same for fallback and normal?
I'll investigate further..
Stefan
-- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Stefan Reinauer stepan@suse.de writes:
- ron minnich rminnich@lanl.gov [030904 17:49]:
On Thu, 4 Sep 2003, Stefan Reinauer wrote:
I agree.. but right now there are still Config.lb files in the mainboard and in the targets directory. And at least last time I checked both were used.
possibly I am missing your point. What bits did you want to see in mainboard/Config.lb that are in the target?
There are some things that are in both Config.lb files. Some of these make sense as a board default that gets overwritten by the image config file, keeping the idea in mind that whoever builds an image for a certain mainboard has to change/create a targets/ Config.lb, but does not have to care about the mainboards/Config.lb. When porting LinuxBIOS to a new board for a known platform, it should be the other way round.
Still, I am uncertain what belongs where ...
uses XIP_ROM_SIZE uses XIP_ROM_BASE [..] option CONFIG_CHIP_CONFIGURE=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option k7=1 option k8=1 option _RAMBASE=0x00004000
These are currently found in the arima targets-Config.lb but they seem pretty much mainboard specific, not build specific.
Correct. It is a little better on the HDAMA. But currently there are some options that don't seem to work properly when I move them in closer.
Left for the targets config file would be:
- console loglevels
- console output (serial, vga, ..)
- rom/ide streaming (is anything but rom streaming still supported?)
- fallback/normal image builds: size, payloads
- option table
The option table pretty much should be mainboard specific, I think.
Whats the difference between option FALLBACK_SIZE=131072 and the option option ROM_IMAGE_SIZE=0x10000
in the romimage "fallback" group? Both sound like they do similar things.
As I recall FALLBACK_SIZE is the fallback part of the rom image. Both payload and LinuxBIOS. Whereas ROM_IMAGE_SIZE is just the LinuxBIOS part.
I had trouble getting a build to work with a kernel (800k) in the normal image and etherboot (~20k) in the fallback image. Do the payload image sizes have to be the same for fallback and normal?
No. Although there are some peculiarities in the new configuration tool. make echo
works so you should be able to see what the variables are set to.
Eric
On 8 Sep 2003, Eric W. Biederman wrote:
Correct. It is a little better on the HDAMA. But currently there are some options that don't seem to work properly when I move them in closer.
yes, I've seen this too, not had time to fix it. Clearly, some things should move into the mainboard file.
I just don't want to go back to what we had before, with lots of things getting set/reset/changed all over the place.
Left for the targets config file would be:
- console loglevels
- console output (serial, vga, ..)
- rom/ide streaming (is anything but rom streaming still supported?)
IDE streaming is not going away any time soon, if ever; too useful too often.
- fallback/normal image builds: size, payloads
- option table
The option table pretty much should be mainboard specific, I think.
yup.
Whats the difference between option FALLBACK_SIZE=131072 and the option option ROM_IMAGE_SIZE=0x10000
in the romimage "fallback" group? Both sound like they do similar things.
As I recall FALLBACK_SIZE is the fallback part of the rom image. Both payload and LinuxBIOS. Whereas ROM_IMAGE_SIZE is just the LinuxBIOS part.
we need to rename these, these names are far too confusing.
I had trouble getting a build to work with a kernel (800k) in the normal image and etherboot (~20k) in the fallback image. Do the payload image sizes have to be the same for fallback and normal?
No. Although there are some peculiarities in the new configuration tool. make echo works so you should be able to see what the variables are set to.
or just cat Makefile.settings, as the perl is gone and these are now almost always just numbers.
send me make output if you want, I'll take a look.
ron
* Eric W. Biederman ebiederman@lnxi.com [030908 22:04]:
Stefan Reinauer stepan@suse.de writes:
uses XIP_ROM_SIZE uses XIP_ROM_BASE [..] option CONFIG_CHIP_CONFIGURE=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option k7=1 option k8=1 option _RAMBASE=0x00004000
These are currently found in the arima targets-Config.lb but they seem pretty much mainboard specific, not build specific.
Correct. It is a little better on the HDAMA. But currently there are some options that don't seem to work properly when I move them in closer.
The above was taken from the hdama CVS. So is there a difference for the build process whether an option is placed into the build target specific config file or in the mainboard specific config file?
I had trouble getting a build to work with a kernel (800k) in the normal image and etherboot (~20k) in the fallback image. Do the payload image sizes have to be the same for fallback and normal?
No. Although there are some peculiarities in the new configuration tool.
I now have a weird effect in the new DS1006 target I checked in. It uses an 872887 bytes elf image payload, and the whole rom is 1MB (SST 49LF080A). Since the machine it shall run on has no CMOS, the CMOS table and failsafe booting is disabled in the Config files. Unfortunately this makes LinuxBIOS hang when setting up the default resource map:
LinuxBIOS-1.1.4.0-dspace Don Sep 11 13:14:37 CEST 2003 starting... setting up resource map....
Running a Solo image on the same machine (Solo for testing purposes) works fine.
Is there any magic in the failsafe bootcode that is missing before resources can be set up? At least amd8111_enable_rom() is only called in failover.c
Stefan
On Thu, 11 Sep 2003, Stefan Reinauer wrote:
Correct. It is a little better on the HDAMA. But currently there are some options that don't seem to work properly when I move them in closer.
The above was taken from the hdama CVS. So is there a difference for the build process whether an option is placed into the build target specific config file or in the mainboard specific config file?
due to a bug, yes.
I now have a weird effect in the new DS1006 target I checked in. It uses an 872887 bytes elf image payload, and the whole rom is 1MB (SST 49LF080A). Since the machine it shall run on has no CMOS, the CMOS table and failsafe booting is disabled in the Config files. Unfortunately this makes LinuxBIOS hang when setting up the default resource map:
if I am only loading one image, I always make it a failsafe image and it all works. ron
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030908 22:04]:
Stefan Reinauer stepan@suse.de writes:
uses XIP_ROM_SIZE uses XIP_ROM_BASE [..] option CONFIG_CHIP_CONFIGURE=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option k7=1 option k8=1 option _RAMBASE=0x00004000
These are currently found in the arima targets-Config.lb but they seem pretty much mainboard specific, not build specific.
Correct. It is a little better on the HDAMA. But currently there are some options that don't seem to work properly when I move them in closer.
The above was taken from the hdama CVS.
Ouch I had not realized it was that bad.
So is there a difference for the build process whether an option is placed into the build target specific config file or in the mainboard specific config file?
Yes. Some options don't work in the mainboard directory. At least they didn't when I tested them.
I had trouble getting a build to work with a kernel (800k) in the normal image and etherboot (~20k) in the fallback image. Do the payload image sizes
have to be the same for fallback and normal?
No. Although there are some peculiarities in the new configuration tool.
I now have a weird effect in the new DS1006 target I checked in. It uses an 872887 bytes elf image payload, and the whole rom is 1MB (SST 49LF080A). Since the machine it shall run on has no CMOS, the CMOS table and failsafe booting is disabled in the Config files. Unfortunately this makes LinuxBIOS hang when setting up the default resource map:
The default failover.c depends on having a CMOS... This is something that definitely needs fixing.
Although I have trouble imagining where to place BIOS options if you have an SST chip. Unless you have found the magic sequence that always works.
Running a Solo image on the same machine (Solo for testing purposes) works fine.
Odd.
Is there any magic in the failsafe bootcode that is missing before resources can be set up? At least amd8111_enable_rom() is only called in failover.c
I think amd8111_enable_rom is the only one. But I may be wrong. I know I enumerate the whole HT chain for the bus with the amd8111.
There are a lot of pieces to work through.
Eric
On Wed, 3 Sep 2003, Stefan Reinauer wrote:
Does it look like this? :
8111 | 8131 | CPU0 -- CPU1
Yes. The order of the device structures is significant.
should this:
southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 [..] endnot rather look like this then: ?
southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end
that's how greg intended it to be used when he came up with that part of the language. So your second example is right.
ron
On 3 Sep 2003, Eric W. Biederman wrote:
I started digging through the code, but I am not completely there yet. It seems to me it would make sense to move the register "up" information from cpu k8 "cpu0" to the northbridge amd/amdk8 "mc0" definition since its information associated with the used southbridges.
The register "up" is something that has not been used at all yet. Personally I am not comfortable with the fact that we have both cpu and northbridge instances for the cpus..
yes, this is the eternal question. For the earlier version I put in northsouthbridge as a type because of stuff like the sis 630. Now, I always wondered if we should not have just kept southbridge/sis/630 and northbridge/sis/630, but acknowledging that they were in fact one chip seemed the way to go.
For the k8, we have a cpu and a northbridge. We could have a part called cpunorthbridge (ACK) but where does this end? It seems ugly. Is it better to just have a northbridge.c in the cpu/k8 directory and remove northbridge/amdk8?
There is currently no information on how the amd8131 and 8151 are actually linked.
Yes there is, but it is mostly implicit.
The issue is that we designed the config file hierarchy as parent/child. That is not enough of a topology description to allow the more complex topologies possible on the K8 systems. Thus you have to extend the topology with the per-chip "register" declarations.
Since every other system we have can be satisfied with the parent/child relationship, I think we ought to leave this be.
ron
-
ebiederman＠lnxi.com -
Greg Watson -
ron minnich -
Stefan Reinauer