[U-Boot-Users] PPC970FX 64-bit processor

[U-Boot-Users] PPC970FX 64-bit processor

[Tzachi Perelstein]

U-Boot is running as a 64-bit binary on the IBM-970FX (PPC64 CPU arch),
on one of Marvell evaluation boards (Pythagoras family)!!!

Some of the *NEW* components I've added to U-Boot: 
/include/asm-ppc64, /include/ppc970, /include/ppc64_asm.tmpl,
/cpu/ppc970, /lib_ppc64

I want to add 64-bit support to some of the *COMMON* files, 
starting with cmd_mem.c. The commands are followed with [.b, .w, .l] 
represents display option: 8-bit, 16-bit, and 32-bit, accordingly. 
Will it be ok to change it to [.b, .s, .w, .l] for 8, 16, 32, and 64?
If it is not acceptable what do you suggest? new cmd_mem64.c? other?

Regards,
Tzachi Perelstein


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20050110/52dd60bf/attachment.htm 

[U-Boot-Users] PPC970FX 64-bit processor

[John W. Linville]

On Mon, Jan 10, 2005 at 05:12:28PM +0200, Tzachi Perelstein wrote:

> Will it be ok to change it to [.b, .s, .w, .l] for 8, 16, 32, and 64?
> If it is not acceptable what do you suggest? new cmd_mem64.c? other?

I know I'm old-fashioned, but how about "[.b, .w, .l, .ll]"?

[U-Boot-Users] PPC970FX 64-bit processor

[tzachi perelstein]

In 64-bit mode both 'long' and 'long long' types are 8 bytes.
Therefore I think that [.l] and [.ll] is not good enough for 64-bit users.
I can be even more explicitly and suggest [.8, .16, .32, .64].
What do you think?  
 
> On Mon, Jan 10, 2005 at 05:12:28PM +0200, Tzachi Perelstein wrote:
> 
> > Will it be ok to change it to [.b, .s, .w, .l] for 8, 16, 32, and 64?
> > If it is not acceptable what do you suggest? new cmd_mem64.c? other?
> 
> I know I'm old-fashioned, but how about "[.b, .w, .l, .ll]"?

[U-Boot-Users] PPC970FX 64-bit processor

[Wolfgang Denk]

In message <200501101551.j0AFpOAq025585@il.marvell.com> you wrote:
> 
> In 64-bit mode both 'long' and 'long long' types are 8 bytes.
> Therefore I think that [.l] and [.ll] is not good enough for 64-bit users.
> I can be even more explicitly and suggest [.8, .16, .32, .64].
> What do you think?  

Too much typing, and not backwards compatible.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Wenn Du ein' weise Antwort verlangst, Mu?t Du vern?nftig fragen.
                                                -- Goethe, Invektiven

[U-Boot-Users] PPC970FX 64-bit processor

[John W. Linville]

On Mon, Jan 10, 2005 at 05:53:11PM +0200, tzachi perelstein wrote:

> I can be even more explicitly and suggest [.8, .16, .32, .64].
> What do you think?  

I think I like that even better.

John

[U-Boot-Users] PPC970FX 64-bit processor

[Tolunay Orkun]

It would break compatibility with existing scripts and documentation of 
everyone else. I think we should maintain earlier definitions at least 
for existing 32-bit implementations.

Best regards,
Tolunay

John W. Linville wrote:
> On Mon, Jan 10, 2005 at 05:53:11PM +0200, tzachi perelstein wrote:
> 
> 
>>I can be even more explicitly and suggest [.8, .16, .32, .64].
>>What do you think?  
> 
> 
> I think I like that even better.
> 
> John
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] PPC970FX 64-bit processor

[John W. Linville]

> John W. Linville wrote:
> >On Mon, Jan 10, 2005 at 05:53:11PM +0200, tzachi perelstein wrote:
> >
> >
> >>I can be even more explicitly and suggest [.8, .16, .32, .64].
> >>What do you think?  
> >
> >
> >I think I like that even better.

On Mon, Jan 10, 2005 at 05:09:59PM -0600, Tolunay Orkun wrote:
> It would break compatibility with existing scripts and documentation of 
> everyone else. I think we should maintain earlier definitions at least 
> for existing 32-bit implementations.

Perhaps...if that is the prevailing logic, then I think my original
proposal (just adding a .ll) makes the most sense.

Still, I think the bit-width based modifiers is the cleaner solution.

Tzachi, perhaps you can #ifdef the cli code to only use the [.8, ...,
.64] for new and/or 64-bit platforms?

Just a thought...

John
-- 
John W. Linville
linville at tuxdriver.com

[U-Boot-Users] PPC970FX 64-bit processor

[Wolfgang Denk]

In message <5C4013D09582FF41833487F21C085CF991ADCE@Hqexch02.il.marvell.com> you wrote:
> 
> U-Boot is running as a 64-bit binary on the IBM-970FX (PPC64 CPU arch),
> on one of Marvell evaluation boards (Pythagoras family)!!!

Congratulations!!!!

> I want to add 64-bit support to some of the *COMMON* files, 
> starting with cmd_mem.c. The commands are followed with [.b, .w, .l] 
> represents display option: 8-bit, 16-bit, and 32-bit, accordingly. 
> Will it be ok to change it to [.b, .s, .w, .l] for 8, 16, 32, and 64?

No, this is not acceptable, as it would break backwards compatibility.

> If it is not acceptable what do you suggest? new cmd_mem64.c? other?

The BDI2000 telnet interface (which was one of my references for  the
"b" and "w" suffixes) uses "d" for "double" to access 64 bit objects.
I think we should do the same and add ".d" [=> .b, .w, .l, .d].

> ------_=_NextPart_001_01C4F726.CC47ACA6
> Content-Type: text/html
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

And *please* don't post HTML to this list.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There is nothing new under the sun, but there are lots of old things
we don't know yet."                                  - Ambrose Bierce

[U-Boot-Users] PPC970FX 64-bit processor

[John W. Linville]

On Mon, Jan 10, 2005 at 04:45:34PM +0100, Wolfgang Denk wrote:

> The BDI2000 telnet interface (which was one of my references for  the
> "b" and "w" suffixes) uses "d" for "double" to access 64 bit objects.
> I think we should do the same and add ".d" [=> .b, .w, .l, .d].

That would satisfy me...

John
-- 
John W. Linville
linville at tuxdriver.com

[U-Boot-Users] PPC970FX 64-bit processor

[tzachi perelstein]

[.b, .w, .l, .d] - Done. Works ok.

[U-Boot-Users] PPC970FX 64-bit processor

[Tzachi Perelstein]

Hi,

I'm working on new project running on CPU PPC970FX (64bit processor). Soon
I'll have a platform to run on. Meanwhile I've done some work. I've
implemented new components /cpu/ppc970, /lib_ppc64, /include/asm-ppc64,
/include/ppc64_asm.tmpl, /include/ppc970, Makefiles... (Code is ported from
74xx_7xx, lib/ppc, and other resources). 
Sources are compiled and linked properly using 64bit crossed tool-chain
(gcc-3.4.3 glibc-2.3.3 binutils-2.14). I have lots of stubs that need to be
implemented.

I would like to get some assistance regarding 64bit issues:
1. The 64bit PPC EABI defines TOC (similar to GOT). Does anyone know about a
problem of 'fixing' the TOC during reallocation to DRAM like in 74xx_7xx
arch?
2. Are there any components (malloc, network...) that are know to be
incompatible to 64bit mode? 

Regards.