[U-Boot] at91rm9200 undef runtime error with eldk 5.0

[U-Boot] at91rm9200 undef runtime error with eldk 5.0

[zzs]

Hi, everybody:

I'am using a board similar to at91rm9200ek, u-boot version is v2011.03.

Early I use eldk4.2 to build u-boot, all things ok, but eldk 4.2 can't
compile busybox whith ubiattach enabled. So I change my toolchain to
eldk5.0 (eldk-eglibc-i686-arm-toolchain-gmae-5.0.tar.bz2,
poky-image-sato-sdk-armv5te.tar.gz). Now the make process all ok. But
when download u-boot.bin to the board. the code say:

       -F- Undef detected

eldk5.0-armv5te CAN'T used for arm920t ??? Is this true?

anybody help me!

-- 
Best Regards,
zzs

[U-Boot] at91rm9200 undef runtime error with eldk 5.0

[Wolfgang Denk]

Dear zzs,

In message <20110713061040.GA5148@greatfirst.com> you wrote:
> 
> I'am using a board similar to at91rm9200ek, u-boot version is v2011.03.

Is your code in mainline?  Which board configuration si this?

[Otherwise: see http://article.gmane.org/gmane.linux.kernel.embedded/3534 ]

> Early I use eldk4.2 to build u-boot, all things ok, but eldk 4.2 can't
> compile busybox whith ubiattach enabled. So I change my toolchain to

Really?  What are the exact problems? [Please post this on the ELDK
mailing list.]

> eldk5.0 (eldk-eglibc-i686-arm-toolchain-gmae-5.0.tar.bz2,
> poky-image-sato-sdk-armv5te.tar.gz). Now the make process all ok. But
> when download u-boot.bin to the board. the code say:
> 
>        -F- Undef detected

Is this the exact error message?  And it gets printed by U-Boot?
Problem is, I cannot find any such text in mainline U-Boot.

> eldk5.0-armv5te CAN'T used for arm920t ??? Is this true?

The AT91RM9200 uses a ARM920 core, i. e. it belongs to the ARM9TDMI
family, ARMv4T architecture.

As the tool chain name "armv5te" clearly suggests, this is configured
for the ARMv5TE architecture (for example ARM9E, ARM10E, XScale
families).

So yes, this is configured for a more advanced architecture.  OTOH, if
you provide correct compiler options, it should still work for U-Boot.
But the, I don't know your code...

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
Die Scheu vor Verantwortung ist die Krankheit unserer Zeit.
                                                 -- Otto von Bismarck

[U-Boot] at91rm9200 undef runtime error with eldk 5.0

[zzs]

In message <20110713084043.1725516F12CE@gemini.denx.de> Wolfgang Denk wrote:
> > I'am using a board similar to at91rm9200ek, u-boot version is v2011.03.
>
> Is your code in mainline?  Which board configuration si this?
my code not in mainline, but I test it using the code for at91rm9200ek

> > Early I use eldk4.2 to build u-boot, all things ok, but eldk 4.2 can't
> > compile busybox whith ubiattach enabled. So I change my toolchain to
>
> Really?  What are the exact problems? [Please post this on the ELDK
> mailing list.]

Yes, it was. I will sent the error message to ELDK mailing list

>
> > eldk5.0 (eldk-eglibc-i686-arm-toolchain-gmae-5.0.tar.bz2,
> > poky-image-sato-sdk-armv5te.tar.gz). Now the make process all ok. But
> > when download u-boot.bin to the board. the code say:
> >
> >        -F- Undef detected
>
> Is this the exact error message?  And it gets printed by U-Boot?
> Problem is, I cannot find any such text in mainline U-Boot.

The message is printed after uboot.bin downloaded by my preloader, Maybe
this message was printed by the preloader code after it jump to uboot.
In my preloader some exception vector were setted to print message.  So
it seems uboot.bin had some illegal asm code in it.

> > eldk5.0-armv5te CAN'T used for arm920t ??? Is this true?
>
> The AT91RM9200 uses a ARM920 core, i. e. it belongs to the ARM9TDMI
> family, ARMv4T architecture.
>
> As the tool chain name "armv5te" clearly suggests, this is configured
> for the ARMv5TE architecture (for example ARM9E, ARM10E, XScale
> families).
>
> So yes, this is configured for a more advanced architecture.  OTOH, if
> you provide correct compiler options, it should still work for U-Boot.
> But the, I don't know your code...

My code is exactly same for at91rm9200ek at version v2011.03

So what compiler options should be use? I notice some u-boot compile
commandline has option '-march=armv4'. Why with this option it is still
generate wrong code

-- 
Best Regards,
zzs

[U-Boot] at91rm9200 undef runtime error with eldk 5.0

[Wolfgang Denk]

Dear zzs,

In message <20110713104600.GA17872@greatfirst.com> you wrote:
>
> > >        -F- Undef detected
> >
> > Is this the exact error message?  And it gets printed by U-Boot?
> > Problem is, I cannot find any such text in mainline U-Boot.
> 
> The message is printed after uboot.bin downloaded by my preloader, Maybe
> this message was printed by the preloader code after it jump to uboot.

I don;t know your preloader, so I cannot help you with that.

> In my preloader some exception vector were setted to print message.  So
> it seems uboot.bin had some illegal asm code in it.

Are you sure that your preloader analyses the binary image it loads
and that it would detect specific assembler code in it?  I tend to
doubt that.


> So what compiler options should be use? I notice some u-boot compile
> commandline has option '-march=armv4'. Why with this option it is still
> generate wrong code

Thi sis a strong statement, based on somewhat weak facts.  Why are you
so sure that there is any "wrong code" being generated?  Please show
which exact instructions you are talking about.

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
Those who hate and fight must stop themselves -- otherwise it is  not
stopped.
	-- Spock, "Day of the Dove", stardate unknown

[U-Boot] at91rm9200 undef runtime error with eldk 5.0

[zzs]

In message <20110713105743.0C2C116F12CE@gemini.denx.de> Wolfgang Denk wrote:
>
> > In my preloader some exception vector were setted to print message.  So
> > it seems uboot.bin had some illegal asm code in it.
>
> Are you sure that your preloader analyses the binary image it loads
> and that it would detect specific assembler code in it?  I tend to
> doubt that.

No, No, No it is impossibe, My preloader just set exception vector and
it jump to the message output code, It print out error message when a
undef instruction exception occurs.

>
>
> > So what compiler options should be use? I notice some u-boot compile
> > commandline has option '-march=armv4'. Why with this option it is still
> > generate wrong code
>
> Thi sis a strong statement, based on somewhat weak facts.  Why are you
> so sure that there is any "wrong code" being generated?  Please show
> which exact instructions you are talking about.

Because the code raised a 'undef instruction' exception, So I guess some
illegal code for arm920(may be legal for other armVs) exist.

I will try to objbump u-boot and  analyses it later.

-- 
Best Regards,
zzs

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[zzs]

>
> > So what compiler options should be use? I notice some u-boot compile
> > commandline has option '-march=armv4'. Why with this option it is still
> > generate wrong code
>
> Thi sis a strong statement, based on somewhat weak facts.  Why are you
> so sure that there is any "wrong code" being generated?  Please show
> which exact instructions you are talking about.
>
Today I found the  "wrong code" :

in u-boot v2011.03

drivers/serial/at91rm9200_usart.c:68:
	us->US_BRGR = (AT91C_MASTER_CLOCK >> 4) / (unsigned)baudrate;

The correspond asm code :

2010c830:	d1a01003 	movle	r1, r3
2010c834:	eb001530 	bl	20111cfc <__udivsi3>
2010c838:	e5840020 	str	r0, [r4, #32]

and the __udivsi3 contain the  "wrong code" :

20111cfc <__udivsi3>:
20111cfc:	e2512001 	subs	r2, r1, #1	; 0x1
20111d00:	012fff1e 	bxeq	lr
20111d04:	3a000023 	bcc	20111d98 <__udivsi3+0x9c>
20111d08:	e1500001 	cmp	r0, r1
20111d0c:	9a00001a 	bls	20111d7c <__udivsi3+0x80>
20111d10:	e1110002 	tst	r1, r2
20111d14:	0a00001b 	beq	20111d88 <__udivsi3+0x8c>
20111d18:	e16f3f11 	clz	r3, r1         # ***this is the  "wrong code"
20111d1c:	e16f2f10 	clz	r2, r0
20111d20:	e0432002 	sub	r2, r3, r2

I search the 'clz' instruction in ARM's manual and it says:

Usage

   The CLZ instruction counts the number of leading zeroes in the value
   in Rm and returns the result in Rd. The result value is 32 if no bits
   are set in the source register, and zero if bit 31 is set.  Condition
   flags

   This instruction does not affect the flags.

Architectures

    This instruction is available in ARM architecture versions 5 and above.


But at91rm9200 is armv4.

Does this mean I can't use eldk5.0 for at91rm9200 ? If yes, How can I
use eldk4.2 to build the newest busybox? Because eldk4.2 can't build
busybox(with ubiattach enabled) due to it's too old kernel header
files(the error message had been sent to eldk list, but no response).

help me, please.

-- 
Best Regards,
zzs

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[Wolfgang Denk]

Dear zzs,

In message <20110715161531.GA5221@greatfirst.com> you wrote:
>
> Today I found the  "wrong code" :

Very well - thanks.

> and the __udivsi3 contain the  "wrong code" :
> 
> 20111cfc <__udivsi3>:
> 20111cfc:	e2512001 	subs	r2, r1, #1	; 0x1
> 20111d00:	012fff1e 	bxeq	lr
> 20111d04:	3a000023 	bcc	20111d98 <__udivsi3+0x9c>
> 20111d08:	e1500001 	cmp	r0, r1
> 20111d0c:	9a00001a 	bls	20111d7c <__udivsi3+0x80>
> 20111d10:	e1110002 	tst	r1, r2
> 20111d14:	0a00001b 	beq	20111d88 <__udivsi3+0x8c>
> 20111d18:	e16f3f11 	clz	r3, r1         # ***this is the  "wrong code"
> 20111d1c:	e16f2f10 	clz	r2, r0
> 20111d20:	e0432002 	sub	r2, r3, r2
...

> Architectures
> 
>     This instruction is available in ARM architecture versions 5 and above.
> 
> 
> But at91rm9200 is armv4.

This is to be expected.  It comes from using the GCC library routines
from ELDK, which are configured for an ARMv5TE architecture.

> Does this mean I can't use eldk5.0 for at91rm9200 ? If yes, How can I

You can use it, but you must make sure to rebuild the needed GCC
library routines as needed for your target.

See the USE_PRIVATE_LIBGCC make option, i. e. use:

	USE_PRIVATE_LIBGCC=yes make ...

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
One of the advantages of being a captain is being able to ask for ad-
vice without necessarily having to take it.
	-- Kirk, "Dagger of the Mind", stardate 2715.2

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[Wolfgang Denk]

Dear zzs,

In message <20110715161531.GA5221@greatfirst.com> you wrote:
>
> Today I found the  "wrong code" :

Thanks again for the feedback.  I have documented this issue in the
ELDK FAQ section:

http://www.denx.de/wiki/view/ELDK-5/QuestionsAndAnswers#GCC_generates_illegal_opcodes_fo

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
In my experience the best way to get something done  is to give it to
someone who is busy.               - Terry Pratchett, _Going_Postal_

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[zzs]

>
> Thanks again for the feedback.  I have documented this issue in the
> ELDK FAQ section:
>
> http://www.denx.de/wiki/view/ELDK-5/QuestionsAndAnswers#GCC_generates_illegal_opcodes_fo
>
Yes. When using "USE_PRIVATE_LIBGCC=yes make my_board_name". It works
well. And the kernel works fine too because linux kernel has private libgcc
code too.

But when I examine the *.so files in eldk5.0, Almost all of them has
'clz' opcode. So if I use them in my aplication like busybox. It will
crash.

So I think the best way is to rebuild eldk5.0 for armv4. Did you tell
me how to configure eldk5.0 to build for armv4. And why eldk5.0 hasn't
a release for armv4, Is armv4 too old and has no value to support it?

-- 
Best Regards,
zzs

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[Andreas Bießmann]

Dear zzs213,

Am 16.07.2011 um 10:05 schrieb zzs:

> But when I examine the *.so files in eldk5.0, Almost all of them has
> 'clz' opcode. So if I use them in my aplication like busybox. It will
> crash.

you could just build your libc for target rootfs with -march=armv4.

> So I think the best way is to rebuild eldk5.0 for armv4.

That is another solution. Then you could use the libc from your toolchain for your rootfs, but I recomend to build your own in any way.

regards

Andreas Bie?mann

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[Wolfgang Denk]

Dear zzs,

In message <20110716080555.GA17211@greatfirst.com> you wrote:
>
> So I think the best way is to rebuild eldk5.0 for armv4. Did you tell
> me how to configure eldk5.0 to build for armv4. And why eldk5.0 hasn't
> a release for armv4, Is armv4 too old and has no value to support it?

This is actually off topic here.  Please let's take this discussion to
the ELDK mailing list instead.

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
If I ever needed a brain transplant, I'd choose a teenager's  because
I'd want a brain that had never been used.

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[Albert ARIBAUD]

Le 15/07/2011 20:00, Wolfgang Denk a ?crit :
> Dear zzs,
>
> In message<20110715161531.GA5221@greatfirst.com>  you wrote:
>>
>> Today I found the  "wrong code" :
>
> Thanks again for the feedback.  I have documented this issue in the
> ELDK FAQ section:
>
> http://www.denx.de/wiki/view/ELDK-5/QuestionsAndAnswers#GCC_generates_illegal_opcodes_fo
>
> Best regards,
>
> Wolfgang Denk

This would not happen for AT91 only, would it? Maybe the FAQ should 
mention other arches / SoC families that might be hurt by the issue.

Amicalement,
-- 
Albert.

[U-Boot] eldk5.0 generate illegal instruction for at91rm9200

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4E214769.3060606@aribaud.net> you wrote:
>
> > http://www.denx.de/wiki/view/ELDK-5/QuestionsAndAnswers#GCC_generates_illegal_opcodes_fo
...
> This would not happen for AT91 only, would it? Maybe the FAQ should
> mention other arches / SoC families that might be hurt by the issue.

It mentions that the problem comes from using a tool chain that is
configured for the ARMv5TE architecture for a processor that belongs
to another, less capable architecture (ARMv4T).

You always have to expect problems when using a tool chain that is set
up to support another architecture than the one you have.

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
It seems intuitively obvious to me, which  means  that  it  might  be
wrong.                                                 -- Chris Torek