[U-Boot-Users] Does ELDK support autoconf?

[U-Boot-Users] Does ELDK support autoconf?

[Shawn Jin]

Hi,

This is off topic here. But Wolfgang, will there be a mailing list
dedicated to ELDK questions?

I'm trying to cross compile the package "lrzsz", a GNU/autoconf'd
software. No matter how I configured, it could never detect the
cross-compiler ppc_4xx-gcc. So I'm wondering if ELDK supports
autoconf? Well, the more general question is how to cross compile a
autoconf'd software using ELDK?

Thanks a lot,
-Shawn.

[U-Boot-Users] Does ELDK support autoconf?

[Wolfgang Denk]

In message <c3d0340b0509021508d265adf@mail.gmail.com> you wrote:
> 
> This is off topic here. But Wolfgang, will there be a mailing list
> dedicated to ELDK questions?

Probaly later this year, after our new web site goes online.

> I'm trying to cross compile the package "lrzsz", a GNU/autoconf'd
> software. No matter how I configured, it could never detect the
> cross-compiler ppc_4xx-gcc. So I'm wondering if ELDK supports
> autoconf? Well, the more general question is how to cross compile a
> autoconf'd software using ELDK?

Check "target_rpms/lrzsz/SPECS/lrzsz.spec" in module "eldk_build"  on
our CVS server, and see
http://www.denx.de/twiki/bin/view/DULG/ELDKRebuildingComponents#Section_3.7.2.

BTW: lrzsz-0.12.20 comes included with the ELDK, so rebuilding should
be trivial if you start using the SRPM :-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Remember that Beethoven wrote his first symphony in C ...

[U-Boot-Users] Using GDB with u-boot and BDI2000 on MPC8245

[Peter Hanson]

Hello all.

I'm new to the list, so forgive me if this is in the archive somewhere.

We're porting Linux to a new 8245-based platform.  We selected u-boot
as the boot-loader that plays nicest with Linux.  Of course, we needed
to create a new board configuration -- no existing configuration was
close.  And, recognizing the difficulting of testing such low-level
code, we bought a BDI2000.

Most of the instructions for using GDB to debug u-boot are clear
enough, but we have run into several gotchas.  I saw several earlier
posts on the topic of GDB with BDI2000, one of which included a
pointer to the Ultimate Solutions, Inc FAQ.  That FAQ does not explain
the behavior we see with various builds and versions of toolchain and
GDB, so I thought I would share my findings here.

Item 1.  Existing instructions and code don't support modern
toolchains.  For example, when we built u-boot-1.1.3 with gcc-4.0.1,
we immediately found three odious treatments of lvalue++ (and close
relatives) as lvalues.  Just install a recent toolchain: the error
messages are crystal clear.

Item 2.  GDB requires careful crafting to build and kinda limps in flash.

Four subitems:
  a. Recommended GDB 5.x => segfault
  b. Vanilla GDB 6.3 => <signal handler called>
  c. Best GDB 6.3 <= mysterious source
  d. Debug with single hardware breakpoint partly broken

  a. We initially tested with the recommended GDB 5.x versions.  We
received mainly seg faults for our efforts.  Likely something new and
unexpected in gcc-4.* symbol tables.

  b. We're using crosstool scripts [http://kegel.com/crosstool/] to
build our shiny new toolchain.  Crosstool has a hidden option to build
a vanilla GDB 6.3@the same time as the chain.  Seems like a good
way to ensure consistent configuration, right?  Yup.  At least the
segfaults are banished.

But . . . vanilla GDB 6.3 does not work reliably with the BDI2000. 
Perhaps this will be familiar to some of you:

    (gdb) targ rem 192.168.3.201:2001
    Remote debugging using 192.168.3.201:2001
    <signal handler called>

It seems some black magic is still missing.

  c. A gentleman was kind enough to send a tarball with markings of
6.3.50.20050725-cvs that can be built and does work.  My main concern
with this is we don't really know what is in this tarball.  Those
don't look like normal release markings.

If possible, I would like to forward whatever magic is needed to the
crosstool script, be it configuration tips, key patches, or druidic
incantations.  I'm fine with magic, I merely want it under source code
control.

  d. Our working-if-mysterious GDB is reliable, but still doesn't play
nicely with the BDI2000 and flash memory.  Perhaps this will be
familiar to some of you:

    (gdb) d b
    Delete all breakpoints? (y or n) y
    (gdb) tb 325
    Breakpoint 3 at 0xfff08ba4: file cpu_init.c, line 325.
    (gdb) c
    Continuing.
    Warning:
    Cannot insert breakpoint 3.
    Error accessing memory address 0xfff08ba4: Unknown error 4294967295.

    (gdb) c
    Continuing.

   Breakpoint 4, cpu_init_f () at cpu_init.c:325
   325     }

Yes, that's right: we see the error even after deleting all
breakpoints!  And then retrying the failed command works!  Why? 
Perhaps error recovery logic clears the condition.  Anyway, it seems
GDB logic doesn't handle this correctly.

The good news is, with a bit of care, you should be able to plow ahead
until u-boot relocates to RAM, switch to software breakpoints, and
finish the job.

Hoping this helps someone else,
 -- Peter

P.S., Labor day weekend is starting in the US.  If that's you, enjoy! 
If not, enjoy the mental image of a whole country sweltering in
immense traffic jams!

[U-Boot-Users] Using GDB with u-boot and BDI2000 on MPC8245

[Wolfgang Denk]

Hello,

in message <50e92330050902191223c38230@mail.google.com> you wrote:
> 
> I'm new to the list, so forgive me if this is in the archive somewhere.

Why should we? Being new is definitely no  excuse  for  ignoring  the
rules.

> Item 1.  Existing instructions and code don't support modern
> toolchains.  For example, when we built u-boot-1.1.3 with gcc-4.0.1,
> we immediately found three odious treatments of lvalue++ (and close
> relatives) as lvalues.  Just install a recent toolchain: the error
> messages are crystal clear.

Just use current source and (most of) the problems have been solved.

Is ther any specific reason why you *must* use GCC-4.x ?

> Item 2.  GDB requires careful crafting to build and kinda limps in flash.

It does not.

>   a. We initially tested with the recommended GDB 5.x versions.  We
> received mainly seg faults for our efforts.  Likely something new and
> unexpected in gcc-4.* symbol tables.

Sounds like you have a tool conflict then. What has this to  do  with
U-Boot?

>   b. We're using crosstool scripts [http://kegel.com/crosstool/] to
> build our shiny new toolchain.  Crosstool has a hidden option to build

This is not the place to discuss crosstool issues.

>   c. A gentleman was kind enough to send a tarball with markings of
> 6.3.50.20050725-cvs that can be built and does work.  My main concern
> with this is we don't really know what is in this tarball.  Those

Go ansd ask said gentleman. How should we know?

>   d. Our working-if-mysterious GDB is reliable, but still doesn't play
> nicely with the BDI2000 and flash memory.  Perhaps this will be
> familiar to some of you:
> 
>     (gdb) d b
>     Delete all breakpoints? (y or n) y
>     (gdb) tb 325
>     Breakpoint 3 at 0xfff08ba4: file cpu_init.c, line 325.
>     (gdb) c
>     Continuing.
>     Warning:
>     Cannot insert breakpoint 3.
>     Error accessing memory address 0xfff08ba4: Unknown error 4294967295.

Are you sure you are using hardware breakpoints?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie