Hello,
I am writing to the CoreBoot mailing list concerning the PCI bus mastering issue that prevents Windows CE drivers from functioning. Artec DBE62 board has a VIA Velocity NIC, that requires bus mastering in order to perform DMA and function correctly. I noticed that nearly all Linux drivers set the bus mastering flag manually during init stage.
Unfortunately, this is not the case with Windows CE drivers. I would be more than happy to do the same thing there, but the problem is, drivers for modern NICs are often supplied as pre-compiled binaries. And it is not always feasible to init the mastering flag in a CE board support packages.
Provided that we want CoreBoot to set PCI bus mastering for a NIC, what is the most adequate way of doing it?
1. With DBE61, we had a dummy RTL8139 PCI driver under src/drivers/pci/rtl8139 that did some chip initialization. I believe that is not suitable for the mainline.
2. Another option would be to globally force the PCI_COMMAND_MASTER in pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
3. It must be also possible to find the PCI device during the mainboard-specific init and issue the mastering command from there.
We have already implemented it as (2), please let me know if you want the patch.
Regards, Andrei
On Fri, May 09, 2008 at 05:06:37PM +0300, Andrei Birjukov wrote:
- With DBE61, we had a dummy RTL8139 PCI driver under
src/drivers/pci/rtl8139 that did some chip initialization. I believe that is not suitable for the mainline.
No? I think I like this option the best, at least for v2. But please pick a name for the driver that more clearly shows what it does or at least that it is local for the board.
- Another option would be to globally force the PCI_COMMAND_MASTER
in pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
I don't like doing this unconditionally. Maybe add an option?
- It must be also possible to find the PCI device during the
mainboard-specific init and issue the mastering command from there.
This would be my second choice. But this fixup isn't really tied to the board, so maybe #2 is better?
//Peter
- Another option would be to globally force the PCI_COMMAND_MASTER
in pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
I don't like doing this unconditionally. Maybe add an option?
The condition is the base class of a PCI device. Currently, CoreBoot does the following:
/* Architectural/System devices always need to be bus masters. */ if ((dev->class >> 16) == PCI_BASE_CLASS_SYSTEM) { dev->command |= PCI_COMMAND_MASTER; }
We could add PCI_BASE_CLASS_NETWORK there as well. Or did you mean an externally configurable condition?
andrei
On 09/05/08 16:22 +0200, Peter Stuge wrote:
On Fri, May 09, 2008 at 05:06:37PM +0300, Andrei Birjukov wrote:
- With DBE61, we had a dummy RTL8139 PCI driver under
src/drivers/pci/rtl8139 that did some chip initialization. I believe that is not suitable for the mainline.
No? I think I like this option the best, at least for v2. But please pick a name for the driver that more clearly shows what it does or at least that it is local for the board.
- Another option would be to globally force the PCI_COMMAND_MASTER
in pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
I don't like doing this unconditionally. Maybe add an option?
The first rule of PCI is that you should never trust a PCI device. There is a universe of broken boards, either by fate or by design. Nowhere is this more true then in the commodity world of the NIC, where you can plug in any random thing assuming you have a PCI slot and a few bucks in your pocket.
Thats why leaving things like enabling bus master is better left to the device driver, which we presume knows best. Thing is, not all drivers know best or we wouldn't have this problem.
I like the idea of an option - those of us with boards that we feel more confident about (because they have a built in NIC and/or don't have a PCI slot) can enable the flag and fix their broken drivers, while those who are less confident in the quality of their components can leave it off and let the OS deal with it.
Put me down for a ++ on #2, with a side of hash browns, please.
Jordan
On Fri, May 9, 2008 at 7:06 AM, Andrei Birjukov andrei.birjukov@artecdesign.ee wrote:
- Another option would be to globally force the PCI_COMMAND_MASTER in
pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
then we'll hit the same problem with disk potentially or any other bus master device? Not sure.
I think we need to make it clear to the user: this is being done because their OS is defective, and it is dangerous. But we've got to support it, so that's life. It really ought to be a Kconfig option. (this is v3 I assume). And the help needs to make clear why this is being done. I don't mind it if you want to beat WinCE over the head.
I'd rather have an this done in phase 6, as part of global PCI device processing. Recall that as soon as you enable DMA on a NIC, things get interesting: Once the NIC is enabled, will it receive packets? If so, where do broadcast packets end up? I don't know. So this is quite dangerous.
Sorry to ramble, I'm just trying to figure this out. Any objections to making it something we do at the very end, as opposed to the probe step? That's what phase 6 is for.
ron
On Fri, May 09, 2008 at 10:29:29AM -0700, ron minnich wrote:
Once the NIC is enabled, will it receive packets? If so, where do broadcast packets end up? I don't know. So this is quite dangerous.
Not neccessarily. Resources being allocated does not really mean the controller can pass traffic into the system.
Typically a driver has to set up RX descriptors that are used to exchange data between card and driver, until the driver has reset the card and set everything up no interrupts are likely to fire.
Any objections to making it something we do at the very end, as opposed to the probe step? That's what phase 6 is for.
Well I'd like it to be configurable, but after that I'm not sure which phase is best. 4-6 all seem good, though there's nothing written about 5-6 in newboot.lyx.
//Peter
On 09.05.2008 19:29, ron minnich wrote:
On Fri, May 9, 2008 at 7:06 AM, Andrei Birjukov wrote:
- Another option would be to globally force the PCI_COMMAND_MASTER in
pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
then we'll hit the same problem with disk potentially or any other bus master device? Not sure.
I think we need to make it clear to the user: this is being done because their OS is defective, and it is dangerous. But we've got to support it, so that's life. It really ought to be a Kconfig option. (this is v3 I assume). And the help needs to make clear why this is being done. I don't mind it if you want to beat WinCE over the head.
Andrei was talking about v2. With v3, we can simply add a "busmaster" property to the dts object which is used to set the busmastering flag in stage6 or so.
I'd rather have an this done in phase 6, as part of global PCI device processing. Recall that as soon as you enable DMA on a NIC, things get interesting: Once the NIC is enabled, will it receive packets? If so, where do broadcast packets end up? I don't know. So this is quite dangerous.
Sorry to ramble, I'm just trying to figure this out. Any objections to making it something we do at the very end, as opposed to the probe step? That's what phase 6 is for.
Very much agreed.
Regards, Carl-Daniel
Ühel kenal päeval, T, 2008-05-13 kell 03:11, kirjutas Carl-Daniel Hailfinger:
On 09.05.2008 19:29, ron minnich wrote:
On Fri, May 9, 2008 at 7:06 AM, Andrei Birjukov wrote:
- Another option would be to globally force the PCI_COMMAND_MASTER in
pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
then we'll hit the same problem with disk potentially or any other bus master device? Not sure.
I think we need to make it clear to the user: this is being done because their OS is defective, and it is dangerous. But we've got to support it, so that's life. It really ought to be a Kconfig option. (this is v3 I assume). And the help needs to make clear why this is being done. I don't mind it if you want to beat WinCE over the head.
Andrei was talking about v2. With v3, we can simply add a "busmaster" property to the dts object which is used to set the busmastering flag in stage6 or so.
No, we were (me on IRC beforehand, Andrei on mailing list) talking about v3. I didn't see any such option for the dts in v3 codebase, or rather, the only two places PCI_COMMAND_MASTER is used is where it is explicitly enabled for PCI Bridge IO Resources and PCI_BASE_CLASS_SYSTEM devices - nowhere else. How is this property set then?
Regards, Mart Raudsepp
On 13.05.2008 08:52, Mart Raudsepp wrote:
Ühel kenal päeval, T, 2008-05-13 kell 03:11, kirjutas Carl-Daniel Hailfinger:
On 09.05.2008 19:29, ron minnich wrote:
On Fri, May 9, 2008 at 7:06 AM, Andrei Birjukov wrote:
- Another option would be to globally force the PCI_COMMAND_MASTER in
pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK.
then we'll hit the same problem with disk potentially or any other bus master device? Not sure.
I think we need to make it clear to the user: this is being done because their OS is defective, and it is dangerous. But we've got to support it, so that's life. It really ought to be a Kconfig option. (this is v3 I assume). And the help needs to make clear why this is being done. I don't mind it if you want to beat WinCE over the head.
Andrei was talking about v2. With v3, we can simply add a "busmaster" property to the dts object which is used to set the busmastering flag in stage6 or so.
No, we were (me on IRC beforehand, Andrei on mailing list) talking about v3.
OK. I thought v2 because Andrei talked about "src/drivers/pci/rtl8139" and no v3 path begins with src/.
I didn't see any such option for the dts in v3 codebase, or rather, the only two places PCI_COMMAND_MASTER is used is where it is explicitly enabled for PCI Bridge IO Resources and PCI_BASE_CLASS_SYSTEM devices - nowhere else. How is this property set then?
Create this property in the base dts and add code to stage6 to act on the setting.
Regards, Carl-Daniel
-
Andrei Birjukov -
Carl-Daniel Hailfinger -
Jordan Crouse -
Mart Raudsepp -
Peter Stuge -
ron minnich