[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [debian-sparc] Re: 2.6.0-test6



They do make it _sound_ like that:
For example, UPA supports UltraSPARC's separate data and

address bus architecture. These large buses-the address bus is

64 bits wide to directly support the 64-bit, V9 architecture,

while the data bus is 144 bits wide (128 bits for data and 16

bits for error checking)-allowing for peak, achievable

bandwidth.

But, they are talking about the seperate busses of the mainboard, not the
UPA.

http://docs.sun.com/db/doc/805-7764-12/6j7a77hhh?a=view#z400010a55fa

Thaey actually state that UPA data is 64 bit.

Check figure C-2 where the connector is 64 bit, and shares the data bus.
With a 72 bit interface. That functional diagram isn't really clear on that
part of it. I'm assuming the other 8 bits are parity (1/2 width data, 1/2
width parity?) but I wouldn't bet anything on it nor would I state it as
more than a guess.



The non-working arch refers to sparc (not sparc64) in 2.6.0-test6 and is
completely wrong. It actually was a compound issue with gcc, then a
corrupted second stage loader. The wierd part was that another user I mail
to had the exact same problem, and wierdly enough, the exact same cause.
(Not quite SO wierd, we are in the same area that had a blackout..both
working on install's and kernels at the same time.)


----- Original Message ----- 
From: "Erwann Abalea" <erwann.abalea@certplus.com>
To: <debian-sparc@lists.debian.org>
Sent: Friday, October 03, 2003 10:19 AM
Subject: Re: [debian-sparc] Re: 2.6.0-test6

<snip>

> According to this document
> (http://www.eecis.udel.edu/nsfri/docs/Ultra-II/UPA.pdf), the UPA *address*
> bus is 64 bit wide, and its *data* bus is 144 bit wide, with 128 bits for
> data and 16 bits for error checking.
>
> I saw mentions of 64-byte transfer blocks in other documents, for example
> for the prefetch instruction. Thanks Google for those interesting
> documents. ;)
>
> > Maybe I'm just an old fogey who remembers the days when you tried to
wring
> > out the performance by aligning software as closely to hardware as
possible.
> > Maybe I think it's strange/inelegant to have a nonworking architecture
in
> > the kernel source.
>
> What are you talking about? nonworking architecture?
>
> -- 
> Erwann ABALEA <eabalea@certplus.com> - RSA PGP Key ID: 0x2D0EABD5
> -----
> SM> Désolé (c'est quand-même terrible cette société oû l'on doit
> SM> s'excuser d'être doué, vraiment...)
> Si en + tu devais t'excuser d'être crétin t'aurais un job a plein temps
> -+- RM in http://neuneu.ctw.cc - Là, ya indubitablement consensus -+-
>
>
>
> -- 
> To UNSUBSCRIBE, email to debian-sparc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>




Reply to: