[U-Boot] Disable features

[U-Boot] Disable features

[simon polette]

Hi,

Is existing a way to globally disable some features such as ethernet
or Nand support, instead of doing it for a specific board?

More over, I can't disable ethernet on the at91sam9261ek board by
simply disable the #define CONFIG_DRIVER_DM9000 in the
'config/at91sam9261ek.h' file so it cause building errors.

Thanks for your support,

best regards,

Simon P.

[U-Boot] Disable features

[Wolfgang Denk]

Dear simon polette,

In message <72795ccb0904290301h1678e99br6fe3cfb0b4226d66@mail.gmail.com> you wrote:
> 
> Is existing a way to globally disable some features such as ethernet
> or Nand support, instead of doing it for a specific board?

No, you cannot do this globally. Board configuration is always board
specific.

> More over, I can't disable ethernet on the at91sam9261ek board by
> simply disable the #define CONFIG_DRIVER_DM9000 in the
> 'config/at91sam9261ek.h' file so it cause building errors.

That's to be expected. When you just disable the network driver with-
out disabling support foir the network commands, the linker will  run
into  unresolved external references to the network driver functions.
You must also disable network commands support.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The faster I go, the behinder I get.                 -- Lewis Carroll

[U-Boot] Disable features

[Derek Ou]

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

[U-Boot] Disable features

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are things that are so serious that you can  only  joke  about
them"                                                    - Heisenberg

[U-Boot] Disable features

[Derek Ou]

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

[U-Boot] Disable features

[Ben Warren]

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

[U-Boot] Disable features

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Madness takes its toll. Please have exact change.

[U-Boot] Disable features

[Derek Ou]

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

[U-Boot] Disable features

[Ben Warren]

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

[U-Boot] Disable features

[Derek Ou]

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

[U-Boot] Disable features

[Ben Warren]

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

[U-Boot] Disable features

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Just think, with VLSI we can have 100 ENIACS on a chip!"
- Alan Perlis

[U-Boot] Disable features

[Jean-Christophe PLAGNIOL-VILLARD]

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.

[U-Boot] Disable features

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only person who always got his work done by Friday
                                                 was Robinson Crusoe.