Hi,
Is existing a way to globally disable some features such as ethernet or Nand support, instead of doing it for a specific board?
Other than recompiling, is it possible to disable Ethernet through environment settings? At our work, we often need Ethernet only during development, manufacturing and troubleshooting. So we put the Ethernet chip on the test fixture instead of the final board. However, compiling in Ethernet slow down the booting process. So it will be great if Ethernet can be disabled and enabled by flipping an environment setting.
Derek
Dear Derek Ou,
In message 49FA0922.2000107@siconix.com you wrote:
Other than recompiling, is it possible to disable Ethernet through environment settings? At our
No.
work, we often need Ethernet only during development, manufacturing and troubleshooting. So we put the Ethernet chip on the test fixture instead of the final board. However, compiling in Ethernet slow down the booting process. So it will be great if Ethernet
Why would compiled in Network support slow down the boot process?
The network interface will only be initialized as soon as you use it. If you don't have one, then you probably will not try using it - then why would it delay your boot?
can be disabled and enabled by flipping an environment setting.
This cannot be done in the current code (and it should not be necessary).
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Why would compiled in Network support slow down the boot process?
The network interface will only be initialized as soon as you use it. If you don't have one, then you probably will not try using it - then why would it delay your boot?
When we have the Network support compiled, it takes a few second to do the auto-negotiation even though MAC chip is not on board. Then it fails out and goes to autoboot. Is it a board specific problem or system problem?
Thanks, Derek
Derek Ou wrote:
Wolfgang Denk wrote:
Why would compiled in Network support slow down the boot process?
The network interface will only be initialized as soon as you use it. If you don't have one, then you probably will not try using it - then why would it delay your boot?
When we have the Network support compiled, it takes a few second to do the auto-negotiation even though MAC chip is not on board. Then it fails out and goes to autoboot. Is it a board specific problem or system problem?
Which network controller are you using? Autonegotiation shouldn't happen until you use the interface, but not all drivers are written that way.
regards, Ben
Hi, Ben,
Ben Warren wrote:
Do you have CONFIG_RESET_PHY_R defined? It forces a call to eth_init(), which most likely causes the delay you're seeing. Try commenting it out in your config file.
Yes, CONFIG_RESET_PHY_R is defined by default. And I can see it linking to the eth_init and then macb_init which results in the auto-negotiation. I am going to comment it out and test it. But what is the use for this config? Why does ATMEL define it in many of their boards?
Thanks, Derek
Derek Ou wrote:
Hi, Ben,
Ben Warren wrote:
Do you have CONFIG_RESET_PHY_R defined? It forces a call to eth_init(), which most likely causes the delay you're seeing. Try commenting it out in your config file.
Yes, CONFIG_RESET_PHY_R is defined by default. And I can see it linking to the eth_init and then macb_init which results in the auto-negotiation. I am going to comment it out and test it. But what is the use for this config? Why does ATMEL define it in many of their boards?
Two good questions. I don't know why, but seem to remember it coming up in this very forum.
Thanks, Derek
regards, Ben
Dear Derek Ou,
In message 49FA2FFD.3000506@siconix.com you wrote:
Yes, CONFIG_RESET_PHY_R is defined by default. And I can see it linking to the eth_init and then macb_init which results in the auto-negotiation. I am going to comment it out and test it. But what is the use for this config? Why does ATMEL define it in many of their boards?
It makes no sense to me to reset the PHY when no network command is being used. I imagine this might be a workaround for broken Linux drivers which do not correctly initialize the hardware themself.
I guess Jean-Cristophe knows this better than we. Jean-Cristophe ?
Best regards,
Wolfgang Denk
On 09:36 Fri 01 May , Wolfgang Denk wrote:
Dear Derek Ou,
In message 49FA2FFD.3000506@siconix.com you wrote:
Yes, CONFIG_RESET_PHY_R is defined by default. And I can see it linking to the eth_init and then macb_init which results in the auto-negotiation. I am going to comment it out and test it. But what is the use for this config? Why does ATMEL define it in many of their boards?
It makes no sense to me to reset the PHY when no network command is being used. I imagine this might be a workaround for broken Linux drivers which do not correctly initialize the hardware themself.
correct IIRC if you do not do it the net drivers will have no mac address and you will not be alllow to use nfs as rootfs
Best Regards, J.
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090501120400.GB3291@game.jcrosoft.org you wrote:
It makes no sense to me to reset the PHY when no network command is being used. I imagine this might be a workaround for broken Linux drivers which do not correctly initialize the hardware themself.
correct IIRC if you do not do it the net drivers will have no mac address and you will not be alllow to use nfs as rootfs
That's a bug in the Linux drivers in the first place, and a bug in the ARM Linux kernel's boot interface in the second place.
But then, I also see no correlation between setting a MAC address and waiting for autonegotiation to complte. We should be able to do the former without doing the latter. In any case, the behavious is wrong and should be fixed. See also http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux
Best regards,
Wolfgang Denk
Dear Derek Ou,
In message 49FA1279.5080406@siconix.com you wrote:
When we have the Network support compiled, it takes a few second to do the auto-negotiation
That should be part of the network init sequence, which should only be run when you run a network command.
even though MAC chip is not on board. Then it fails out and goes to autoboot. Is it a board specific problem or system problem?
Board (or architecture) problem.
Which board / architecture is this?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Derek Ou,
In message 49FA1279.5080406@siconix.com you wrote:
When we have the Network support compiled, it takes a few second to do the auto-negotiation
That should be part of the network init sequence, which should only be run when you run a network command.
The board goes to auto-negotiation before boot delay count down. So it's before I can run any command. I will look into the network init routine then.
even though MAC chip is not on board. Then it fails out and goes to autoboot. Is it a board specific problem or system problem?
Board (or architecture) problem. Which board / architecture is this?
It's an Atmel AT91SAM9263(ek) board. ARM architecture.
Best regards, Wolfgang Denk
Derek
Derek Ou wrote:
Wolfgang Denk wrote:
Dear Derek Ou,
In message 49FA1279.5080406@siconix.com you wrote:
When we have the Network support compiled, it takes a few second to do the auto-negotiation
That should be part of the network init sequence, which should only be run when you run a network command.
The board goes to auto-negotiation before boot delay count down. So it's before I can run any command. I will look into the network init routine then.
even though MAC chip is not on board. Then it fails out and goes to autoboot. Is it a board specific problem or system problem?
Board (or architecture) problem. Which board / architecture is this?
It's an Atmel AT91SAM9263(ek) board. ARM architecture.
Best regards, Wolfgang Denk
Do you have CONFIG_RESET_PHY_R defined? It forces a call to eth_init(), which most likely causes the delay you're seeing. Try commenting it out in your config file.
regards, Ben
participants (4)
-
Ben Warren -
Derek Ou -
Jean-Christophe PLAGNIOL-VILLARD -
Wolfgang Denk