On Thu, Sep 24, 2009 at 12:52 AM, Stefan Reinauer stepan@coresystems.dewrote: Myles Watson wrote:
Are there other differences? Should I2C devices use objects, since you can't scan for them?
Some structures defined in the code are put in an extra section in the binary for enumeration. Those are:
#define __console __attribute__((used, __section__(".rodata.console_drivers"))) #define __cpu_driver __attribute__((used,__section__(".rodata.cpu_driver"))) #define __pci_driver __attribute__((used,__section__(".rodata.pci_driver")))
All others don't need to be "drivers"
Stefan
--------------- Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj.
The most common one was mainboard.c as a driver.
Boot tested with Tyan s2895.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
PS. It looks like the rtl8168 driver ought to go somewhere more general in the tree.
Myles Watson wrote:
PS. It looks like the rtl8168 driver ought to go somewhere more general in the tree.
It's not really a driver but only keeps the device allocator from trying to execute an option rom where there is none. I'm not sure if that really happens on other boards with that chip...
Stefan
On Fri, Sep 25, 2009 at 2:25 PM, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
PS. It looks like the rtl8168 driver ought to go somewhere more general in the tree.
It's not really a driver but only keeps the device allocator from trying to execute an option rom where there is none. I'm not sure if that really happens on other boards with that chip...
I don't know how common that is. Maybe there should be a flavor of the onboard driver for that.
Thanks, Myles
Myles Watson wrote:
On Fri, Sep 25, 2009 at 2:25 PM, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
PS. It looks like the rtl8168 driver ought to go somewhere more general in the tree.
It's not really a driver but only keeps the device allocator from trying to execute an option rom where there is none. I'm not sure if that really happens on other boards with that chip...
I don't know how common that is. Maybe there should be a flavor of the onboard driver for that.
Ah, I looked at that driver today... Should we drop that, now that we have CBFS everywhere? It was only used for onboard pci devices with option roms in the system bios. Which is no longer done that way...
PS. It looks like the rtl8168 driver ought to go somewhere more general in the tree.
Ah, I looked at that driver today... Should we drop that, now that we have CBFS everywhere? It was only used for onboard pci devices with option roms in the system bios. Which is no longer done that way...
I'd ack that patch.
Myles
Myles Watson wrote:
>>> PS. It looks like the rtl8168 driver ought to go somewhere more >>> general in the tree. Ah, I looked at that driver today... Should we drop that, now that we have CBFS everywhere? It was only used for onboard pci devices with option roms in the system bios. Which is no longer done that way...
I'd ack that patch.
Ok, I put it on my todo list.. right now there's 139 references of that driver in the code, so it's more than a quick shot on a tired evening.. BTW, I am hunting another bug with an onboard rtl8168 that comes up as an 8129 after reset... (Seems it can't read its EEPROM anymore after Linux talked to it) .. hope to get a patch done for that today.
Stefan
On Thu, Sep 24, 2009 at 2:59 PM, Myles Watson mylesgw@gmail.com wrote:
On Thu, Sep 24, 2009 at 12:52 AM, Stefan Reinauer stepan@coresystems.de wrote: Myles Watson wrote:
Are there other differences? Should I2C devices use objects, since you can't scan for them?
Some structures defined in the code are put in an extra section in the binary for enumeration. Those are:
#define __console __attribute__((used, __section__(".rodata.console_drivers"))) #define __cpu_driver __attribute__((used,__section__(".rodata.cpu_driver"))) #define __pci_driver __attribute__((used,__section__(".rodata.pci_driver")))
All others don't need to be "drivers"
Stefan
Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj.
The most common one was mainboard.c as a driver.
Boot tested with Tyan s2895.
Signed-off-by: Myles Watson mylesgw@gmail.com
Ping.
Am 24.09.2009 22:59, schrieb Myles Watson:
Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj.
The most common one was mainboard.c as a driver.
Boot tested with Tyan s2895.
Signed-off-by: Myles Watson mylesgw@gmail.com
I updated the patch, with all the boards converted that appeared in Kconfig after this patch was made, too. There's not a single driver in src/mainboard left.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
On Tue, Feb 23, 2010 at 8:37 AM, Patrick Georgi patrick@georgi-clan.dewrote:
Am 24.09.2009 22:59, schrieb Myles Watson:
Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj.
The most common one was mainboard.c as a driver.
Boot tested with Tyan s2895.
Signed-off-by: Myles Watson mylesgw@gmail.com
I updated the patch, with all the boards converted that appeared in Kconfig after this patch was made, too. There's not a single driver in src/mainboard left.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Index: src/mainboard/roda/rk886ex/Makefile.inc =================================================================== --- src/mainboard/roda/rk886ex/Makefile.inc (revision 5149) +++ src/mainboard/roda/rk886ex/Makefile.inc (working copy) @@ -21,10 +21,10 @@ ## This mainboard requires DCACHE_AS_RAM enabled. It won't work without. ##
-driver-y += mainboard.o -driver-y += m3885.o -driver-y += ec.o -driver-y += rtl8168.o +obj-y += mainboard.o +obj-y += m3885.o +obj-y += ec.o +obj-y += rtl8168.o
It looks like rtl8168 should stay a driver, since it's a PCI device. I don't know about m3885.o and ec.o. I'm also not sure about the debug devices. Are they considered PCI? It's been a long time since I thought about this.
Thanks, Myles
Am 23.02.2010 17:28, schrieb Myles Watson:
-driver-y += mainboard.o -driver-y += m3885.o -driver-y += ec.o -driver-y += rtl8168.o +obj-y += mainboard.o +obj-y += m3885.o +obj-y += ec.o +obj-y += rtl8168.o
It looks like rtl8168 should stay a driver, since it's a PCI device. I don't know about m3885.o and ec.o. I'm also not sure about the debug devices. Are they considered PCI? It's been a long time since I thought about this.
As I understand it, the main criterion was if they're using the linker magic. I couldn't find any of that in there, but maybe that's just too hidden for my (short, I admit) glance?
Patrick
On 2/23/10 5:29 PM, Patrick Georgi wrote:
Am 23.02.2010 17:28, schrieb Myles Watson:
-driver-y += mainboard.o -driver-y += m3885.o -driver-y += ec.o -driver-y += rtl8168.o +obj-y += mainboard.o +obj-y += m3885.o +obj-y += ec.o +obj-y += rtl8168.o
It looks like rtl8168 should stay a driver, since it's a PCI device. I don't know about m3885.o and ec.o. I'm also not sure about the debug devices. Are they considered PCI? It's been a long time since I thought about this.
As I understand it, the main criterion was if they're using the linker magic. I couldn't find any of that in there, but maybe that's just too hidden for my (short, I admit) glance?
No, that's right.. the EC code is only called from mainboard.c and the SMM handler
On 2/23/10 4:37 PM, Patrick Georgi wrote:
Am 24.09.2009 22:59, schrieb Myles Watson:
Based on that, here's a patch that changes drivers that aren't console, pci, or cpu, to obj.
The most common one was mainboard.c as a driver.
Boot tested with Tyan s2895.
Signed-off-by: Myles Watson mylesgw@gmail.com
I updated the patch, with all the boards converted that appeared in Kconfig after this patch was made, too. There's not a single driver in src/mainboard left.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Acked-by: Stefan Reinauer stepan@coresystems.de