[U-Boot-Users] reading ethaddr from env

[U-Boot-Users] reading ethaddr from env

[Juan Antonio Garcia Redondo]

Hello all,

I'm porting u-boot to a custom board with pxa255. I have a problem that I'm
not be able to solve.

When u-boot starts and try to read the ethaddr, (lib_arm/board.c at 296),
the parameter tmp used in the function getenv_r is pointing to the gd->bd
structure, so the execution of this function corrupts the data stored in
it.

I've found a "dirty" workaround of this problem rising the size of tmp
buffer:
The code in lib_arm/board.c

        /* IP Address */
        gd->bd->bi_ip_addr = getenv_IPaddr ("ipaddr");

        /* MAC Address */
        {
                int i;
                ulong reg;
                char *s, *e;
                /* uchar tmp[64]; */
                uchar tmp[128];

                i = getenv_r ("ethaddr", tmp, sizeof (tmp));
                printf("ethaddr %s[%d]\n", tmp, i);
                s = (i > 0) ? tmp : NULL;

                for (reg = 0; reg < 6; ++reg) {
                        gd->bd->bi_enetaddr[reg] = s ? simple_strtoul (s,
                        &e, 16) : 0;
                        if (s)
                                s = (*e) ? e + 1 : e;
                }
        }

The output of gdb before execute the getenv_r(with tmp[64]):

(gdb) print *gd
$2 = {bd = 0xa00bffa0, flags = 0, baudrate = 115200, have_console = 1,
reloc_off = 0, env_addr = 2685141004, env_valid = 1,
  fb_base = 0, jt = 0x0}
(gdb) n
(gdb) print &tmp[0]
$3 = (uchar *) 0xa00bffa4 ""
(gdb) s
getenv_r (name=0xa0114bb0 "ethaddr", buf=0xa00bffa4 "??\002?", len=64) at
cmd_nvedit.c:512


As you can see the tmp buffer is pointing to the gd->bd plus 4.

My compiler:

arm-linux-gcc -v
Reading specs from
/home/jgarcia/PXA2XX/ELDK/eldk_work/usr/bin/../lib/gcc-lib/arm-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit --with-newlib
--enable-languages=c,c++ --disable-libgcj --host=i386-redhat-linux
--target=arm-linux
Thread model: posix
gcc version 3.3.3 (DENX ELDK 3.1 3.3.3-8)


Any hints ?

Regards,
        Juan Antonio

[U-Boot-Users] reading ethaddr from env

[Wolfgang Denk]

In message <20050223100142.GA3003@nabla101> you wrote:
> 
> When u-boot starts and try to read the ethaddr, (lib_arm/board.c at 296),
> the parameter tmp used in the function getenv_r is pointing to the gd->bd
> structure, so the execution of this function corrupts the data stored in
> it.

You are wrong. "tmp" is a local array, declared in line 294:

    294                 uchar tmp[64];
    295
    296                 i = getenv_r ("ethaddr", tmp, sizeof (tmp));

> I've found a "dirty" workaround of this problem rising the size of tmp
> buffer:

What exactly is your problem?

>                 /* uchar tmp[64]; */
>                 uchar tmp[128];
> 
>                 i = getenv_r ("ethaddr", tmp, sizeof (tmp));

Why do you think that 64 bytes should be insufficient  to  store  the
MAC address?

> As you can see the tmp buffer is pointing to the gd->bd plus 4.

At least this is what the debugger claims.

> Any hints ?

I cannot reproduce this problem here. WHat do you get  when  you  use
printf() to display the addresses _before_ calling getenv_r()?

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 22 - 24,  Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As a general rule, the freedom of any people can  be  judged  by  the
volume of their laughter.

[U-Boot-Users] reading ethaddr from env

[Juan Antonio Garcia Redondo]

On 24/02/05 23:49, Wolfgang Denk wrote:
> In message <20050223100142.GA3003@nabla101> you wrote:

> I cannot reproduce this problem here. WHat do you get  when  you  use
> printf() to display the addresses _before_ calling getenv_r()?
> 

I've found the problem. I'd forgotten to assign the CFG_GBL_DATA_SIZE
constant, so sp was pointing to a wrong place.

Thanks for your answer.

Regards,
        Juan Antonio