I'ts been awhile since I've messed with the config system and having some difficulity adding a new config option.
I have modified the epia-m auto.c to have a ifdef wrapper around the section that disables the firewire bridge. I called it DISABLE_FIREWIRE. I added uses DISABLE_FIREWIRE to the Options.lb and setup a defaut.
I then created a new target called epia-ml that just uses the epia-m mainboard but would disable the firewire disable section.
But when I run buildtarget I still get:
build_dir=via/epia-ml/epia-ml Configuring TARGET epia-ml Will place Makefile, crt0.S, etc. in via/epia-ml/epia-ml ===> ERROR: Can't use undefined option DISABLE_FIREWIRE via/epia-ml/Config.lb:0 src/mainboard/via/epia-m/Options.lb:0
Where else do I have to add my new config option so the buld system knwos about it?
-- Richard A. Smith
* Richard Smith smithbone@gmail.com [060421 18:05]:
I have modified the epia-m auto.c to have a ifdef wrapper around the section that disables the firewire bridge. I called it DISABLE_FIREWIRE. I added uses DISABLE_FIREWIRE to the Options.lb and setup a defaut.
you need to add the option in src/config/Options.lb as well.
I then created a new target called epia-ml that just uses the epia-m mainboard but would disable the firewire disable section.
Another idea: /* * Disable the firewire stuff, which apparently steps on IO 0+ * on * reset. Doh! */ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_6305), 0); if (dev != PCI_DEV_INVALID) { pci_write_config8(dev, 0x15, 0x1c); }
This is the problematic code, especially pci_locate_device.
I would guess this is messing up boot times on all systems that it is running on without finding a device.
Idea: We should add a maximum bus number to it, so we can look for the device on bus0 only for example, or on the first 10 busses, if we know its an epia that will never have an onboard device with a bus number higher than that. Searching 256 busses takes a while, no doubt. And its not a smart thing to do at this place either.
Stefan
you need to add the option in src/config/Options.lb as well.
Ah thats it. I knew there was another place.
Idea: We should add a maximum bus number to it, so we can look for the device on bus0 only for example, or on the first 10 busses, if we know its an epia that will never have an onboard device with a bus number higher than that. Searching 256 busses takes a while, no doubt. And its not a smart thing to do at this place either.
Excellent Idea. Much better than more #if's. So OPTION_PCI_MAX_BUS? and then fixup the search routine to never look beyond that. The default could be 5 or so which is sane for 99% of the setups.
-- Richard A. Smith
actually, what would be nice is, instead of a config option, set up the struct in chip.h to have a member called firewire, and then in the Config.lb, enable it on or off.
thanks
ron
On 4/21/06, Ronald G Minnich rminnich@lanl.gov wrote:
actually, what would be nice is, instead of a config option, set up the struct in chip.h to have a member called firewire, and then in the Config.lb, enable it on or off.
That was actually what I was thinking about first but then we would need to create a new mainboard directory right? Seemed a lot of duplication just to skip over a couple of lines of code or Can the target build file override the device stuff in the MB config?
-- Richard A. Smith
That was actually what I was thinking about first but then we would need to create a new mainboard directory right? Seemed a lot of duplication just to skip over a couple of lines of code or Can the target build file override the device stuff in the MB config?
There is also an enable setting for the MII in the config.lb under src/motherboard/via/epia-m for the ricoh chip
I'm not sure, what happens on this, but most epia-m revisions like the ME and others don't have a cf card slot.
chris
* Ronald G Minnich rminnich@lanl.gov [060421 19:32]:
actually, what would be nice is, instead of a config option, set up the struct in chip.h to have a member called firewire, and then in the Config.lb, enable it on or off.
chip.h is post-auto.c stuff, so this won't affect it. nor?
struct in chip.h to have a member called firewire, and then in the Config.lb, enable it on or off.
chip.h is post-auto.c stuff, so this won't affect it. nor?
If its post auto.c then no it won't work. According to the comments you have to disable the firewire to make legacy IO work. So even prior to early_serial.
Sombody with an Epia-M (not ML) may want to verfiy all this.
-- Richard A. Smith
On Fri, Apr 21, 2006 at 05:20:42PM -0500, Richard Smith wrote:
struct in chip.h to have a member called firewire, and then in the Config.lb, enable it on or off.
chip.h is post-auto.c stuff, so this won't affect it. nor?
If its post auto.c then no it won't work. According to the comments you have to disable the firewire to make legacy IO work. So even prior to early_serial.
Sombody with an Epia-M (not ML) may want to verfiy all this.
You want confirmation that that Firewire disabling is necessary for the Epia-M? I should be able to check this out in the next few days if someone else doesn't get there first; I've finally got to the point where my M10000 based project is ready to go ahead and have started testing again. Recent
J.
you have to disable the firewire to make legacy IO work. So even prior to early_serial.
Sombody with an Epia-M (not ML) may want to verfiy all this.
You want confirmation that that Firewire disabling is necessary for the Epia-M? I should be able to check this out in the next few days if someone else doesn't get there first; I've finally got to the point where my M10000 based project is ready to go ahead and have started testing again. Recent
Yeah. just as a sanity check that that code is there for a reason. Board bring up is Voodo sometimes.
-- Richard A. Smith
On Fri, Apr 21, 2006 at 05:53:08PM -0500, Richard Smith wrote:
you have to disable the firewire to make legacy IO work. So even prior to early_serial.
Sombody with an Epia-M (not ML) may want to verfiy all this.
You want confirmation that that Firewire disabling is necessary for the Epia-M? I should be able to check this out in the next few days if someone else doesn't get there first; I've finally got to the point where my M10000 based project is ready to go ahead and have started testing again. Recent
Yeah. just as a sanity check that that code is there for a reason. Board bring up is Voodo sometimes.
Yes, it's necessary (which is good, because I was certainly the last person to touch it though I can't remember if I put it there in the first place; I certainly remember seeing it in v1). Without it my boot hangs, though I do still see the LinuxBIOS banner output before this happens.
J.
Yes, it's necessary (which is good, because I was certainly the last person to touch it though I can't remember if I put it there in the first place; I certainly remember seeing it in v1). Without it my boot hangs, though I do still see the LinuxBIOS banner output before this happens.
Ok.. But you do get serial output prior to that then? So it must not totally stop on all legacy IO.
Can you test the changing pci_locate_device() to pci_locate_device_on_bus(0) (or what ever bus that need to be) and see if it still works?
-- Richard A. Smith
On Wed, Apr 26, 2006 at 11:55:51AM -0500, Richard Smith wrote:
Yes, it's necessary (which is good, because I was certainly the last person to touch it though I can't remember if I put it there in the first place; I certainly remember seeing it in v1). Without it my boot hangs, though I do still see the LinuxBIOS banner output before this happens.
Ok.. But you do get serial output prior to that then? So it must not totally stop on all legacy IO.
Yes, I get the "LinuxBIOS-1.1.8.0Fallback Wed...booting..." header fine. My guess it it stomps over something else or quite possible does so randomly; ISTR getting random lockups when first getting the EPIA-M up and running again.
Can you test the changing pci_locate_device() to pci_locate_device_on_bus(0) (or what ever bus that need to be) and see if it still works?
That works; s/pci_locate_device/pci_locate_device_on_bus/ for the firewire bits.
On a separate note, but still related to the EPIA-M, I'm sure I'd found the appropriate bit to twiddle to make sure the machine auto powers on always. However I can't find my tree where I did that and I'm failing to find the details in the datasheet again. Has anyone else done this?
J.
Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [060421 19:32]:
actually, what would be nice is, instead of a config option, set up the struct in chip.h to have a member called firewire, and then in the Config.lb, enable it on or off.
chip.h is post-auto.c stuff, so this won't affect it. nor?
Oops. My bad. That's what comes of not reading a thread in enough detail. Sorry.
Go with config option, I guess.
ron
-
Christian Sühs -
Jonathan McDowell -
Richard Smith -
Ronald G Minnich -
Stefan Reinauer