[ECOS] MAC (ESA) address with Redboot's fconfig-tool

["Philip Soeberg" <ecos at soeberg dot net>]

Hi,

I?ve now spent almost the entire day trying to figure out where Redboot get
its default MAC address for eth0 from.

Having a completely wiped flash rom, Redboot - just after installment -
finds its default MAC address as 00:68:FF:FF:FF:FF. Searching for any
combination of this MAC in the source-tree yielded nothing...

I?m using a PowerPC 823 based board, with the ethernet-part located in the
devs/eth/powerpc/quicc package.

It turns out that the MAC address Redboot finds is caused by a bug in the
fconfig design.

Below is an explanation of the cause; and a possible solution at the bottom.

---

The bug originates from the way the RedBoot_config_option is used in
fconfig:

In devs/etc/powerpc/quicc/current/src/if_quicc.c line 102 we find:
RedBoot_config_option("Network hardware address [MAC]",
                      quicc_esa,
                      ALWAYS_ENABLED, true,
                      CONFIG_ESA, 0
    );

Using the above "option", fconfig will, during initialization, fetch its
value for this option from address 0x0.
The last zero must be wrong... As far as I have understood, it should be the
address of some container holding the value for whatever the parameter is...
In our case, this should be an address of a static variable holding the ESA
address (a 6 byte MAC address for the Ethernet hardware card).

What happens when this is zero is this:
        At some point RedBoot?s fconfig-tool gets initialized... During
this, it discovers that the config-area is invalid. It then executes:
        config_init(..), which in turn executes
        flash_add_config(..), which adds the key, some other stuff and the
value of the container pointed to.
        But the above ?RedBoot_config_option? states that this container is
located at 0? Quite wrong!

Problem arises in if_quicc.c where "esa_ok = flash_get_config("quicc_esa",
enaddr, CONFIG_ESA);" is used to fetch the MAC address during ethernet
initialization. As the fconfig-tool has written the first 6 bytes of address
0x0 as the value to the "quicc_esa" option, this is what is used as my MAC
address :(

Now, this may just be an average bug, but what I don?t understand is the
design of how ESA is fetched.
Ideally, I could specify the MAC address in the if_quicc.c source-file
(using the macro QUICC_ETH_FETCH_ESA in an inline file) as well as by using
the Redboot fconfig tool.

After using the fconfig-tool properly, the MAC address is correct after a
system reset. This works fine.
But if the fconfig-config-area is invalid (as it is just after redboot
download in a new empty system), I want to set the MAC myself.
My first thought was to do this by doing a
      #define QUICC_ETH_FETCH_ESA(_ok_)				\
	esa_ok = true;							\
	memcpy(&enaddr, (unsigned char[6]){...}, sizeof(_default_enaddr))
This however resulted in not loading the MAC via fconfig, should the
fconfig-config-area later be valid.

Second thought was
	#define QUICC_ETH_FETCH_ESA(_ok_)				\
	esa_ok = false;							\
	memcpy(&_default_enaddr, (unsigned char[6]){...},
sizeof(_default_enaddr))
This would work if fconfig returns false should its fconfig-config-area be
invalid. (Currently; it does NOT)
Should "esa_ok = flash_get_config("quicc_esa", enaddr, CONFIG_ESA);" return
false, if_quicc.c would copy the contents of _default_enaddr instead.. Sweet
I thought...

A new problem arises here: If the "zero" gets fixed, I still can't use the
above QUICC_ETH_FETCH_ESA macro. This is because the flash_get_config(..)
still returns true. Nor can at compiletime/runtime initialize any container
used for the redboot_option, as the redboot_option is used included and used
before any inline files (headers, inlines whatever)...

A possible solution to all of this babble could be by inserting a check in
fconfig's flash_add_config, preventing the entire command option to be
written (or enabled or ...) if the pointer to the container is NULL. This
then results in flash_get_config returning false.

I hope you can find your way through the description... otherwise please ask
:)

Best regards,
-=[ Philip Soeberg ]=[ ecos@soeberg.net ]=-



--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss