at91rm9200 undef runtime error with eldk 5.0

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

Dear zzs,

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

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

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

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 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

my code not in mainline, but I test it using the code for at91rm9200ek

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

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.

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

Dear zzs,

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

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.

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

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.

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

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

Dear zzs,

Very well - thanks.

...

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

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

Dear 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

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_

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

Dear zzs213,

Am 16.07.2011 um 10:05 schrieb zzs:

you could just build your libc for target rootfs with -march=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

Dear zzs,

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.

Le 15/07/2011 20:00, Wolfgang Denk a ?crit :

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.

Dear Albert ARIBAUD,

...

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