[En-Nut-Discussion] temporary hack in the thread NicRx

[Tomohiro HARAIKAWA]

Dear Harald,

  Thank you for your detailed comment written in your busy schedule.

> Two changes are responsible:
> 
> 1. Device initialization had been called during DevOpen/NetConfig.
> This was bad for Harddisk support and it's also more logical to
> detect a device init failure earlier. So device initialization
> is now done when NutRegisterDevice() is called.
> 
> 2. If the EEPROM doesn't contain a valid network configuration,
> the "default" MAC address egnite-00-00-00 has been used. Since
> version 3.2 there's no such thing as a default MAC. It's up to
> the application to either
>    a) Make sure that the EEPROM is valid.
> or
>    b) Deliver the MAC address when calling NutDhcpIfConfig()
>       or NutNetIfConfig()

  I uptook.  Thank you.


> Why is it temporary? I'd like to remove NutNetAutoConfig, but
> not too soon to avoid breaking too many existing apps. More important,
> the current solution is unsafe, because it depends on async timing.
> After starting NicRx, it is assumed, that this thread reaches the
> wait-for-mac-loop before NutDhcpIfConfig() sets the MAC address.
> Otherwise the controller will never get initialized.

  Additionally, as you may be aware, the NIC is immediately started 
if NutRegisterDevice() => NicInit() => NutNetLoadConfig() succeeded. 
Thereafter, if the MAC is supplied through NutDhcpIfConfig(), it is 
never passed down to the NIC registers and ethernut confused by two 
different MACs will not work properly.

# This might not be a serious problem because the MAC once supplied 
# through NutDhcpInConfig() is stored in EEPROM and they supply the 
# same address from the second boot.


> Final solution would be to split the initialization into two parts.
> 
> I) NutRegisterDevice() resets the Ethernet controller and does
> a basic hardware check and configuration.
> 
> II) NutDhcpIfConfig() / NutNetIfConfig() will set the MAC address and
> fire up the controller.

  I thought the same scheme.  I have been created patchs to support 
93C46 serial EEPROM externally connected to RTL8019AS.  Needless to 
note, Nut/OS has NO DUTY TO SUPPORT THIS, but it's not bad to do so 
since using 93C46 is also suggested in Realtek's referencial design.

  I understood your strategy and write a patch for new Nut/OS which 
won't be inconsistent to the starategy.

# First I'd better to stop firing NIC in NicInit(), to make the MAC 
# correctly passed down to the NIC registers from NutDhcpIfConfig().


> This will require a few changes in the driver code and I'd like to
> finish the LAN91C111 driver first before making further decisions.

  For more generalized design, right?  I put your plan in my mind.


> I doubt that we will ever see 00:00:00 anywhere, 

  Right.  I only pointed out very slight possibility since 00:00:00 
is issued OUI (http://standards.ieee.org/regauth/oui/oui.txt).  But 
in usual, there is not a problem at all, as you are suggesting.


Thank you again, Harald!

With my respect, 

---
Tomohiro Haraikawa
Faculty of Information, Shizuoka University
E-mail: hal at cs.inf.shizuoka.ac.jp