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

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

[ksi at koi8.net]

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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

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

[Zach Sadecki]

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 at lists.sourceforge.net] On Behalf Of
ksi at 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 at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

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

[ksi at koi8.net]

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 at lists.sourceforge.net
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of
> ksi at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

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

[Dirk Behme]

ksi at 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.

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Wolfgang Denk]

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

-- 
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
The only person who always got his work done by Friday
                                                 was Robinson Crusoe.

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

[Dirk Behme]

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

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

[Jon Loeliger]

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

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

[Wolfgang Denk]

In message <1186766515.22451.29.camel@ld0161-tx32> you wrote:
> 
> 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

:-)

> 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

-- 
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
The complexity of software is an essential property, not an  acciden-
tal  one. Hence, descriptions of a software entity that abstract away
its complexity often abstract away its essence.    - Fred Brooks, Jr.