[U-Boot] 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!
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
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 detectedIs 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
Dear zzs,
In message 20110713104600.GA17872@greatfirst.com you wrote:
-F- Undef detectedIs 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
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.
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.
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
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_illega...
Best regards,
Wolfgang Denk
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_illega...
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?
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
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
Le 15/07/2011 20:00, Wolfgang Denk a écrit :
Dear zzs,
In message20110715161531.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_illega...
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,
Dear Albert ARIBAUD,
In message 4E214769.3060606@aribaud.net you wrote:
http://www.denx.de/wiki/view/ELDK-5/QuestionsAndAnswers#GCC_generates_illega...
...
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
participants (4)
-
Albert ARIBAUD -
Andreas Bießmann -
Wolfgang Denk -
zzs