[U-Boot-Users] [ARM] TI DaVinci support, hopefully final [0/5]

Here it is.
Changes:
- Fixed CONFIG_CMD_NET in net files. - Fixed CONFIG_CMD_EEPROM for schmoogie. - Made sure it compiles and works (forceenv() link problem) on SCHMOOGIE and DV_EVM. Can't check if it works on SONATA, don't have a board any more, but it at least compiles.
I'm sending patches in two forms -- inline (set of 5 patches) _AND_ as a set of 2 GZIP files. Those should survive _ANY_ reformatting by various MUAs.
Hopefully it is the final attempt...
Here is an excerpt from session log on SCHMOOGIE...
=== Cut === U-Boot 1.2.0-g6c33c785-dirty (Aug 7 2007 - 13:07:17)
DRAM: 128 MB NAND: 128 MiB In: serial Out: serial Err: serial ARM Clock : 297MHz DDR Clock : 162MHz ETH PHY : DP83848 @ 0x01 U-Boot > iprobe Valid chip addresses: 1B 38 3A 3D 3F 50 5D 6F U-Boot > ping 192.168.253.10 host 192.168.253.10 is alive U-Boot > === Cut ===
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

Nice... With the gzipped files I can get it to patch and compile (after applying the biosemu patch).
But something breaks if I change the dvevm.h file to #define CFG_USE_NAND. The compile breaks at the end with warnings (warnings that cause make to error out). They have to do with "function '__udivsi3'" being redifined (and the warning that stops the compile is this: "arm_v5t_le-ld: Warning: size of symbol `__udivsi3' changed from 152 in lib_arm/libarm.a(_udivsi3.o) to 496 in /opt/montavista-arm-v4.00-alt/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5 tl-montavista-linuxeabi/3.4.3/libgcc.a(_udivsi3.oS)"
I got this same error last time I made a quick and dirty attempt to get 1.2.0 to compile for Davinci.
Anybody know what I can do to fix this one?
Thanks, Zach
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of ksi@koi8.net Sent: Tuesday, August 07, 2007 4:07 PM To: U-Boot list Subject: [U-Boot-Users] [ARM] TI DaVinci support, hopefully final [0/5]
Here it is.
Changes:
- Fixed CONFIG_CMD_NET in net files. - Fixed CONFIG_CMD_EEPROM for schmoogie. - Made sure it compiles and works (forceenv() link problem) on SCHMOOGIE and DV_EVM. Can't check if it works on SONATA, don't have a board any more, but it at least compiles.
I'm sending patches in two forms -- inline (set of 5 patches) _AND_ as a set of 2 GZIP files. Those should survive _ANY_ reformatting by various MUAs.
Hopefully it is the final attempt...
Here is an excerpt from session log on SCHMOOGIE...
=== Cut === U-Boot 1.2.0-g6c33c785-dirty (Aug 7 2007 - 13:07:17)
DRAM: 128 MB NAND: 128 MiB In: serial Out: serial Err: serial ARM Clock : 297MHz DDR Clock : 162MHz ETH PHY : DP83848 @ 0x01 U-Boot > iprobe Valid chip addresses: 1B 38 3A 3D 3F 50 5D 6F U-Boot > ping 192.168.253.10 host 192.168.253.10 is alive U-Boot > === Cut ===
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

On Tue, 7 Aug 2007, Zach Sadecki wrote:
That's MontaVista toolchain.
I can post a proper RPM .spec file and all required patches for GCC 4.2.0 based toolchain (arm-elf, for standalone applications e.g. U-Boot with almost complete multilib less EP9312 FPU) if somebody wants them...
Nice... With the gzipped files I can get it to patch and compile (after applying the biosemu patch).
But something breaks if I change the dvevm.h file to #define CFG_USE_NAND. The compile breaks at the end with warnings (warnings that cause make to error out). They have to do with "function '__udivsi3'" being redifined (and the warning that stops the compile is this: "arm_v5t_le-ld: Warning: size of symbol `__udivsi3' changed from 152 in lib_arm/libarm.a(_udivsi3.o) to 496 in /opt/montavista-arm-v4.00-alt/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5 tl-montavista-linuxeabi/3.4.3/libgcc.a(_udivsi3.oS)"
I got this same error last time I made a quick and dirty attempt to get 1.2.0 to compile for Davinci.
Anybody know what I can do to fix this one?
Thanks, Zach
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of ksi@koi8.net Sent: Tuesday, August 07, 2007 4:07 PM To: U-Boot list Subject: [U-Boot-Users] [ARM] TI DaVinci support, hopefully final [0/5]
Here it is.
Changes:
- Fixed CONFIG_CMD_NET in net files.
- Fixed CONFIG_CMD_EEPROM for schmoogie.
- Made sure it compiles and works (forceenv() link problem) on SCHMOOGIE
and DV_EVM. Can't check if it works on SONATA, don't have a board any more, but it at least compiles.
I'm sending patches in two forms -- inline (set of 5 patches) _AND_ as a set of 2 GZIP files. Those should survive _ANY_ reformatting by various MUAs.
Hopefully it is the final attempt...
Here is an excerpt from session log on SCHMOOGIE...
=== Cut === U-Boot 1.2.0-g6c33c785-dirty (Aug 7 2007 - 13:07:17)
DRAM: 128 MB NAND: 128 MiB In: serial Out: serial Err: serial ARM Clock : 297MHz DDR Clock : 162MHz ETH PHY : DP83848 @ 0x01 U-Boot > iprobe Valid chip addresses: 1B 38 3A 3D 3F 50 5D 6F U-Boot > ping 192.168.253.10 host 192.168.253.10 is alive U-Boot > === Cut ===
- KSI@home KOI8 Net < > The impossible we do immediately. *
- Las Vegas NV, USA < > Miracles require 24-hour notice. *
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

ksi@koi8.net wrote:
On Tue, 7 Aug 2007, Zach Sadecki wrote:
That's MontaVista toolchain.
No, that's not a MontaVista specific issue. I have an other toolchain and it has similiar issues. Nor is it an ARM specific issue.
nand_utils.c uses 64bit division, and if you use stuff from nand_utils.c you may get these issues. So solution is to make U-Boot independent from toolchain for 64bit division used in nand_utils.c as already done with other math helpers in lib_arm.
Please apply
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30484 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30476
as well.
Best regards
Dirk
P.S.: Wolfgang: Sorry if I missed anything. Do I have to do anything more to get above patches applied? Thanks.
I can post a proper RPM .spec file and all required patches for GCC 4.2.0 based toolchain (arm-elf, for standalone applications e.g. U-Boot with almost complete multilib less EP9312 FPU) if somebody wants them...
....
But something breaks if I change the dvevm.h file to #define CFG_USE_NAND. The compile breaks at the end with warnings (warnings that cause make to error out). They have to do with "function '__udivsi3'" being redifined (and the warning that stops the compile is this: "arm_v5t_le-ld: Warning: size of symbol `__udivsi3' changed from 152 in lib_arm/libarm.a(_udivsi3.o) to 496 in /opt/montavista-arm-v4.00-alt/pro/devkit/arm/v5t_le/bin/../lib/gcc/armv5 tl-montavista-linuxeabi/3.4.3/libgcc.a(_udivsi3.oS)"
I got this same error last time I made a quick and dirty attempt to get 1.2.0 to compile for Davinci.

Hi Wolfgang,
On Wednesday 08 August 2007, Dirk Behme wrote:
No, that's not a MontaVista specific issue. I have an other toolchain and it has similiar issues. Nor is it an ARM specific issue.
nand_utils.c uses 64bit division, and if you use stuff from nand_utils.c you may get these issues. So solution is to make U-Boot independent from toolchain for 64bit division used in nand_utils.c as already done with other math helpers in lib_arm.
Please apply
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30484 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30476
as well.
Acked-by: Stefan Roese sr@denx.de
to both patches mentioned above.
Wolfgang, could you please pick those up and apply directly? It's hard for me to apply the nand patch only because it needs the do_div() first.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

In message 200708100625.35760.sr@denx.de you wrote:
On Wednesday 08 August 2007, Dirk Behme wrote:
No, that's not a MontaVista specific issue. I have an other toolchain and it has similiar issues. Nor is it an ARM specific issue.
nand_utils.c uses 64bit division, and if you use stuff from nand_utils.c you may get these issues. So solution is to make U-Boot independent from toolchain for 64bit division used in nand_utils.c as already done with other math helpers in lib_arm.
Please apply
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30484 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30476
as well.
Acked-by: Stefan Roese sr@denx.de
to both patches mentioned above.
Wolfgang, could you please pick those up and apply directly? It's hard for me to apply the nand patch only because it needs the do_div() first.
Done.
Please do not use a completely unrelated Subject next time!
Best regards,
Wolfgang Denk

Wolfgang Denk wrote:
In message 200708100625.35760.sr@denx.de you wrote:
On Wednesday 08 August 2007, Dirk Behme wrote:
No, that's not a MontaVista specific issue. I have an other toolchain and it has similiar issues. Nor is it an ARM specific issue.
nand_utils.c uses 64bit division, and if you use stuff from nand_utils.c you may get these issues. So solution is to make U-Boot independent from toolchain for 64bit division used in nand_utils.c as already done with other math helpers in lib_arm.
Please apply
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30484 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/30476
as well.
Acked-by: Stefan Roese sr@denx.de
to both patches mentioned above.
Wolfgang, could you please pick those up and apply directly? It's hard for me to apply the nand patch only because it needs the do_div() first.
Done.
Really? But not on u-boot.git? Or can you please recheck?
My local git top is "mpc83xx: fix ITX[GP] O=builddir builds", same with
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary
Compiling DaVinci patches on top of this recent git I still get the 64bit division errors. Looking into gitweb, div64.c is still in lib_avr32 and drivers /nand /nand_util.c was last touched at 2007-07-09.
Sorry if I missed anything.
Best regards
Dirk

On Fri, 2007-08-10 at 10:26, Dirk Behme wrote:
Wolfgang, could you please pick those up and apply directly? It's hard for me to apply the nand patch only because it needs the do_div() first.
Done.
Really? But not on u-boot.git? Or can you please recheck?
Just as a point of procedure, Here's what sometimes happens in the maintainer repositories:
1) A stack of patches and requests queues up 2) Maintainer gets around to working through the queue: while (patch_queue_has_stuff()) { apply patch send "Applied! Thanks!" mail } 3) Open a Ch. Lafitte 1988 1er Grand Cru 4) Test build and stuff 5) Tinker with tree after eating dinner 6) Push repo out to public site
If you happen to look at the public repo between mail being sent and 6), it may not look right to you. The key here will be to open your own bottle of, say, David Coffaro Petite Sirah, and wait for the repo to be pushed. :-)
_Then_ abuse the maintainer. :-)
Naturally, I have no idea what the timing on the events here really was. Nor am I going to go look....
Thanks! jdl

In message 1186766515.22451.29.camel@ld0161-tx32 you wrote:
- A stack of patches and requests queues up
- Maintainer gets around to working through the queue: while (patch_queue_has_stuff()) { apply patch send "Applied! Thanks!" mail }
- Open a Ch. Lafitte 1988 1er Grand Cru
- Test build and stuff
- Tinker with tree after eating dinner
- Push repo out to public site
:-)
Naturally, I have no idea what the timing on the events here really was. Nor am I going to go look....
Even if you look, you probably cannot find out later as we use rsync to copy the data from our servers here to the externally visible web server. That makes it impossible for you to find out the exact moment when I fell asleep and my head banged on the keyboard...
Best regards,
Wolfgang Denk
participants (6)
-
Dirk Behme
-
Jon Loeliger
-
ksi@koi8.net
-
Stefan Roese
-
Wolfgang Denk
-
Zach Sadecki