[U-Boot] [PATCH 0/2] tegra2: Fixes for running mainline U-Boot.

[U-Boot] [PATCH 0/2] tegra2: Fixes for running mainline U-Boot.

[Thierry Reding]

The following series contains two patches that allow mainline U-Boot to
boot standalone on Tegra2-based boards. It assumes the standard NVIDIA
flashing tools as provided by the Linux4Tegra package. The series is
based on patches that have already been reviewed but haven't been merged
upstream yet. They are available in patchwork here:

	http://patchwork.ozlabs.org/patch/122888
	http://patchwork.ozlabs.org/patch/122887
	http://patchwork.ozlabs.org/patch/122889
	http://patchwork.ozlabs.org/patch/123845 (9 patches)

Thierry Reding (2):
  tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
  tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000.

 arch/arm/cpu/armv7/tegra2/config.mk |    2 ++
 include/configs/tegra2-common.h     |    2 +-
 2 files changed, 3 insertions(+), 1 deletions(-)

-- 
1.7.7.3

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Thierry Reding]

The AVP on Tegra2 doesn't boot properly when U-Boot is linked against
the GCC provided libgcc. To work around this, always build and link
against a private libgcc for Tegra2-based boards.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 arch/arm/cpu/armv7/tegra2/config.mk |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/tegra2/config.mk b/arch/arm/cpu/armv7/tegra2/config.mk
index 8f9bdc9..2303dba 100644
--- a/arch/arm/cpu/armv7/tegra2/config.mk
+++ b/arch/arm/cpu/armv7/tegra2/config.mk
@@ -29,3 +29,5 @@
 ifdef CONFIG_TEGRA2
 CFLAGS_arch/arm/lib/board.o += -march=armv4t
 endif
+
+USE_PRIVATE_LIBGCC = yes
-- 
1.7.7.3

[U-Boot] [PATCH 2/2] tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000.

[Thierry Reding]

NVIDIA's flashing tools assume that the bootloader is loaded at address
0x00108000. Instead of requiring non-standard builds of those tools
which allow a load address of 0x00E08000, this commit just switches all
Tegra2 boards to use the standard load address.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Simon Glass <sjg@chromium.org>
---
 include/configs/tegra2-common.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index e233b1c..f7b6232 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -152,7 +152,7 @@
 #define PHYS_SDRAM_1		TEGRA2_SDRC_CS0
 #define PHYS_SDRAM_1_SIZE	0x20000000	/* 512M */
 
-#define CONFIG_SYS_TEXT_BASE	0x00E08000
+#define CONFIG_SYS_TEXT_BASE	0x00108000
 #define CONFIG_SYS_SDRAM_BASE	PHYS_SDRAM_1
 
 #define CONFIG_SYS_INIT_RAM_ADDR	CONFIG_STACKBASE
-- 
1.7.7.3

[U-Boot] [PATCH 0/2] tegra2: Fixes for running mainline U-Boot.

[Stephen Warren]

Thierry Reding wrote at Thursday, November 17, 2011 3:04 AM:
> The following series contains two patches that allow mainline U-Boot to
> boot standalone on Tegra2-based boards. It assumes the standard NVIDIA
> flashing tools as provided by the Linux4Tegra package. The series is
> based on patches that have already been reviewed but haven't been merged
> upstream yet. They are available in patchwork here:
> 
> 	http://patchwork.ozlabs.org/patch/122888
> 	http://patchwork.ozlabs.org/patch/122887
> 	http://patchwork.ozlabs.org/patch/122889
> 	http://patchwork.ozlabs.org/patch/123845 (9 patches)
> 
> Thierry Reding (2):
>   tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
>   tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000.

The series:

Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>

(On Seaboard/Springbank, booted a Linux kernel)

Thanks for cleaning this up.

-- 
nvpublic

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Simon Glass]

On Thu, Nov 17, 2011 at 2:04 AM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> The AVP on Tegra2 doesn't boot properly when U-Boot is linked against
> the GCC provided libgcc. To work around this, always build and link
> against a private libgcc for Tegra2-based boards.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

Tested-by: Simon Glass <sjg@chromium.org>

> ---
> ?arch/arm/cpu/armv7/tegra2/config.mk | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/tegra2/config.mk b/arch/arm/cpu/armv7/tegra2/config.mk
> index 8f9bdc9..2303dba 100644
> --- a/arch/arm/cpu/armv7/tegra2/config.mk
> +++ b/arch/arm/cpu/armv7/tegra2/config.mk
> @@ -29,3 +29,5 @@
> ?ifdef CONFIG_TEGRA2
> ?CFLAGS_arch/arm/lib/board.o += -march=armv4t
> ?endif
> +
> +USE_PRIVATE_LIBGCC = yes
> --
> 1.7.7.3
>
>

[U-Boot] [PATCH 2/2] tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000.

[Simon Glass]

On Thu, Nov 17, 2011 at 2:04 AM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> NVIDIA's flashing tools assume that the bootloader is loaded at address
> 0x00108000. Instead of requiring non-standard builds of those tools
> which allow a load address of 0x00E08000, this commit just switches all
> Tegra2 boards to use the standard load address.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> Tested-by: Simon Glass <sjg@chromium.org>

Acked-by: Simon Glass <sjg@chromium.org>

> ---
> ?include/configs/tegra2-common.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
> index e233b1c..f7b6232 100644
> --- a/include/configs/tegra2-common.h
> +++ b/include/configs/tegra2-common.h
> @@ -152,7 +152,7 @@
> ?#define PHYS_SDRAM_1 ? ? ? ? ? TEGRA2_SDRC_CS0
> ?#define PHYS_SDRAM_1_SIZE ? ? ?0x20000000 ? ? ?/* 512M */
>
> -#define CONFIG_SYS_TEXT_BASE ? 0x00E08000
> +#define CONFIG_SYS_TEXT_BASE ? 0x00108000
> ?#define CONFIG_SYS_SDRAM_BASE ?PHYS_SDRAM_1
>
> ?#define CONFIG_SYS_INIT_RAM_ADDR ? ? ? CONFIG_STACKBASE
> --
> 1.7.7.3
>
>

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Wolfgang Denk]

Dear Thierry Reding,

In message <1321524246-5187-2-git-send-email-thierry.reding@avionic-design.de> you wrote:
> The AVP on Tegra2 doesn't boot properly when U-Boot is linked against
> the GCC provided libgcc. To work around this, always build and link
> against a private libgcc for Tegra2-based boards.

I notice this patch only now, when pulling in from u-boot-arm.

I will accept this only temporarily.  Why don't you use a working tool
chain instead, or fix the one you are using?

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
COBOL is for morons.                                 -- E.W. Dijkstra

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Stephen Warren]

On 01/05/2012 08:50 AM, Wolfgang Denk wrote:
> Dear Thierry Reding,
> 
> In message <1321524246-5187-2-git-send-email-thierry.reding@avionic-design.de> you wrote:
>> The AVP on Tegra2 doesn't boot properly when U-Boot is linked against
>> the GCC provided libgcc. To work around this, always build and link
>> against a private libgcc for Tegra2-based boards.
> 
> I notice this patch only now, when pulling in from u-boot-arm.
> 
> I will accept this only temporarily.  Why don't you use a working tool
> chain instead, or fix the one you are using?

I believe the issue isn't that the toolchain is broken, but due to the
mix of multiple CPU types on Tegra, all of which run the same U-Boot binary.

U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then
inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue
running U-Boot.

The libraries included in the toolchain are built for the ARMv7 CPUs,
and hence fail to operate correctly when used by the portion of U-Boot
which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC,
there are overrides in the U-Boot build process such that some/all of
U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc
built by U-Boot solves this.

-- 
nvpublic

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Simon Glass]

Hi Stephen,

On Thu, Jan 5, 2012 at 8:53 AM, Stephen Warren <swarren@nvidia.com> wrote:
> On 01/05/2012 08:50 AM, Wolfgang Denk wrote:
>> Dear Thierry Reding,
>>
>> In message <1321524246-5187-2-git-send-email-thierry.reding@avionic-design.de> you wrote:
>>> The AVP on Tegra2 doesn't boot properly when U-Boot is linked against
>>> the GCC provided libgcc. To work around this, always build and link
>>> against a private libgcc for Tegra2-based boards.
>>
>> I notice this patch only now, when pulling in from u-boot-arm.
>>
>> I will accept this only temporarily. ?Why don't you use a working tool
>> chain instead, or fix the one you are using?
>
> I believe the issue isn't that the toolchain is broken, but due to the
> mix of multiple CPU types on Tegra, all of which run the same U-Boot binary.
>
> U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then
> inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue
> running U-Boot.
>
> The libraries included in the toolchain are built for the ARMv7 CPUs,
> and hence fail to operate correctly when used by the portion of U-Boot
> which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC,
> there are overrides in the U-Boot build process such that some/all of
> U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc
> built by U-Boot solves this.

Yes that's right, but actually I have never delved into exactly why.
Perhaps it is an integer divide or internal memcpy() call early in the
code. We might be able to find the offending C library code, given
enough time, and perhaps arrange not to call it. A little fragile
though.

Regards,
Simon

>
> --
> nvpublic

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Tom Warren]

Simon,

> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: Thursday, January 05, 2012 10:07 AM
> To: Stephen Warren
> Cc: Wolfgang Denk; Thierry Reding; u-boot at lists.denx.de; Tom Warren
> Subject: Re: [U-Boot] [PATCH 1/2] tegra2: Always build with
> USE_PRIVATE_LIBGCC=yes.
> 
> Hi Stephen,
> 
> On Thu, Jan 5, 2012 at 8:53 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > On 01/05/2012 08:50 AM, Wolfgang Denk wrote:
> >> Dear Thierry Reding,
> >>
> >> In message <1321524246-5187-2-git-send-email-thierry.reding@avionic-
> design.de> you wrote:
> >>> The AVP on Tegra2 doesn't boot properly when U-Boot is linked
> >>> against the GCC provided libgcc. To work around this, always build
> >>> and link against a private libgcc for Tegra2-based boards.
> >>
> >> I notice this patch only now, when pulling in from u-boot-arm.
> >>
> >> I will accept this only temporarily. ?Why don't you use a working
> >> tool chain instead, or fix the one you are using?
> >
> > I believe the issue isn't that the toolchain is broken, but due to the
> > mix of multiple CPU types on Tegra, all of which run the same U-Boot
> binary.
> >
> > U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then
> > inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to
> > continue running U-Boot.
> >
> > The libraries included in the toolchain are built for the ARMv7 CPUs,
> > and hence fail to operate correctly when used by the portion of U-Boot
> > which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC,
> > there are overrides in the U-Boot build process such that some/all of
> > U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc
> > built by U-Boot solves this.
> 
> Yes that's right, but actually I have never delved into exactly why.
> Perhaps it is an integer divide or internal memcpy() call early in the code.
> We might be able to find the offending C library code, given enough time,
> and perhaps arrange not to call it. A little fragile though.

IIRC, it was a divide that caused an undefined instruction exception. You can run U-Boot w/o the UE_PRIVATE_LIBGCC, and break in w/JTAG and look at the undefined instr shadow regs (sp/lr/pc) and find the opcode that caused the fault pretty easily, again IIRC.  But USE_PRIVATE_LIBGCC was intended for just this problem, and works fine.

Tom
> 
> Regards,
> Simon
> 
> >
> > --
> > nvpublic

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Wolfgang Denk]

Dear Stephen Warren,

In message <4F05D596.6030900@nvidia.com> you wrote:
>
> > I will accept this only temporarily.  Why don't you use a working tool
> > chain instead, or fix the one you are using?
> 
> I believe the issue isn't that the toolchain is broken, but due to the
> mix of multiple CPU types on Tegra, all of which run the same U-Boot binary.

When we can solve this issue with our own version of the libgcc, then
we can also solve it by using a tool chain that provides the needed
lingcc code.

> U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then
> inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue
> running U-Boot.

OK, so you have to use a tool chain which provides libgcc code for
armv4t systems.  What exactly is the problem here?

> The libraries included in the toolchain are built for the ARMv7 CPUs,

SO this is not the right tool chain for the job.  Ecactly what I said.

> and hence fail to operate correctly when used by the portion of U-Boot
> which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC,
> there are overrides in the U-Boot build process such that some/all of
> U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc
> built by U-Boot solves this.

No, this is NOT a solution, it is a workaround for an inappropriate
toolchain.  If you want to build code for an armv4t system, you must
use a tool chain that supports it.

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
Small is beautiful.

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ2wCqF2tPWwFUdKG7y_xDeYhbFrEnqXxRJG6eU7yj9Xug@mail.gmail.com> you wrote:
> 
> > The libraries included in the toolchain are built for the ARMv7 CPUs,
> > and hence fail to operate correctly when used by the portion of U-Boot
> > which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC,
> > there are overrides in the U-Boot build process such that some/all of
> > U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc
> > built by U-Boot solves this.
> 
> Yes that's right, but actually I have never delved into exactly why.
> Perhaps it is an integer divide or internal memcpy() call early in the
> code. We might be able to find the offending C library code, given
> enough time, and perhaps arrange not to call it. A little fragile
> though.

That would be the totally wrong approach.  Problems should be solved
where they originate.  Here this appears to be the tool chain, which
does not provide a version of libgcc suitable for amv4t
configurations.

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
All men should freely use those seven words which have the  power  to
make any marriage run smoothly: You know dear, you may be right.

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Stephen Warren]

On 01/05/2012 12:16 PM, Wolfgang Denk wrote:
> In message <4F05D596.6030900@nvidia.com> you wrote:
...
>> The libraries included in the toolchain are built for the ARMv7 CPUs,
> 
> SO this is not the right tool chain for the job.  Ecactly what I said.
> 
>> and hence fail to operate correctly when used by the portion of U-Boot
>> which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC,
>> there are overrides in the U-Boot build process such that some/all of
>> U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc
>> built by U-Boot solves this.
> 
> No, this is NOT a solution, it is a workaround for an inappropriate
> toolchain.  If you want to build code for an armv4t system, you must
> use a tool chain that supports it.

But we don't want to generate code for ARMv4 in general, but rather
ARMv7 as the toolchain does. Only a tiny part of the code needs to be
built for ARMv4, and in general we want to benefit from using ARMv7.

-- 
nvpublic

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Wolfgang Denk]

Dear Stephen Warren,

In message <4F05FCBD.2040207@nvidia.com> you wrote:
>
> > No, this is NOT a solution, it is a workaround for an inappropriate
> > toolchain.  If you want to build code for an armv4t system, you must
> > use a tool chain that supports it.
> 
> But we don't want to generate code for ARMv4 in general, but rather

Then just turn on the ARMv4 specific options (-march=armv4t -mno-thumb
-mthumb-interwork -mtune=arm920t ???) for the files that need it.

But as soon as any of these files liks code from libgcc you have to
decide.

> ARMv7 as the toolchain does. Only a tiny part of the code needs to be
> built for ARMv4, and in general we want to benefit from using ARMv7.

Then you should probably still link against a ARMv4 specific libgcc.

If you were building U-Boot's libgcc code with optimization set for
ARMv7 this would not fix anything.

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
I'd rather be led to hell than managed to heaven.

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Simon Glass]

Hi,

On Thu, Jan 5, 2012 at 12:17 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Stephen Warren,
>
> In message <4F05FCBD.2040207@nvidia.com> you wrote:
>>
>> > No, this is NOT a solution, it is a workaround for an inappropriate
>> > toolchain. ?If you want to build code for an armv4t system, you must
>> > use a tool chain that supports it.
>>
>> But we don't want to generate code for ARMv4 in general, but rather
>
> Then just turn on the ARMv4 specific options (-march=armv4t -mno-thumb
> -mthumb-interwork -mtune=arm920t ???) for the files that need it.
>
> But as soon as any of these files liks code from libgcc you have to
> decide.

Perhaps we could adjust Tegra's config.mk to use ARMv4T when not
building with the private libgcc?

>
>> ARMv7 as the toolchain does. Only a tiny part of the code needs to be
>> built for ARMv4, and in general we want to benefit from using ARMv7.
>
> Then you should probably still link against a ARMv4 specific libgcc.
>
> If you were building U-Boot's libgcc code with optimization set for
> ARMv7 this would not fix anything.
>

It might be possible to specify ARMv4T on the link flags and have it
pick up the v4T library, even if nearly everything else is ARMv7?

Regards,
Simon

> 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
> I'd rather be led to hell than managed to heaven.

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Stephen Warren]

On 01/05/2012 01:42 PM, Simon Glass wrote:
> Hi,
> 
> On Thu, Jan 5, 2012 at 12:17 PM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Stephen Warren,
>>
>> In message <4F05FCBD.2040207@nvidia.com> you wrote:
>>>
>>>> No, this is NOT a solution, it is a workaround for an inappropriate
>>>> toolchain.  If you want to build code for an armv4t system, you must
>>>> use a tool chain that supports it.
>>>
>>> But we don't want to generate code for ARMv4 in general, but rather
>>
>> Then just turn on the ARMv4 specific options (-march=armv4t -mno-thumb
>> -mthumb-interwork -mtune=arm920t ???) for the files that need it.

That's exactly what we've already done, but that doesn't affect code
that gets pulled in from libgcc, which is what USE_PRIVATE_LIBGCC
affects IIUC.

>> But as soon as any of these files liks code from libgcc you have to
>> decide.
> 
> Perhaps we could adjust Tegra's config.mk to use ARMv4T when not
> building with the private libgcc?

I believe the relevant U-Boot source files are already built for ARMv4T,
it's just libgcc that's the issue.

>>> ARMv7 as the toolchain does. Only a tiny part of the code needs to be
>>> built for ARMv4, and in general we want to benefit from using ARMv7.
>>
>> Then you should probably still link against a ARMv4 specific libgcc.
>>
>> If you were building U-Boot's libgcc code with optimization set for
>> ARMv7 this would not fix anything.
> 
> It might be possible to specify ARMv4T on the link flags and have it
> pick up the v4T library, even if nearly everything else is ARMv7?

I don't think we use any multilib toolchains, so I don't think that's
possible.

-- 
nvpublic

[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Wolfgang Denk]

Dear Stephen,

In message <4F060DD1.9050907@nvidia.com> you wrote:
>
> > It might be possible to specify ARMv4T on the link flags and have it
> > pick up the v4T library, even if nearly everything else is ARMv7?
> 
> I don't think we use any multilib toolchains, so I don't think that's
> possible.

I don't even think you need one with multilib support.  You need one
that provides a libgcc for armv4t, that's all.

It is wrong, always and everywhere, NOT to try to fix the problems at
the origin.  If your tool chain does not meet your requirements, then
the first action should always be to get a working tool chain -
ideally by getting the deficiencies of the currnt one fixed, or by
using another one.

Working around such problems may be a short term approach to get
things running quickly.  But it appears that more and more people make
it a habit to do just that, without even trying to get the real
problems fixed upstream.  That's bad, bad, bad.

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
I'd rather be led to hell than managed to heaven.