Broadcom BCM94306

Broadcom BCM94306

[valvoline]

hi all,

after googling for broadcom based wifi cards and ppc supports,
i've reached a link regarding ndiswrapper from sourceforge and mandrake-ppc.
Seems that mdk's developers have done a porting of ndiswrapper for ppc based archs.

anybody know about this?, also if this porting is really working...what kind
of drivers are required? i think that simple win32-drivers cannot work
properly in a different architecture with different *endian.

regards
--
[ valvoline :: VRL Team :: s0ftpj :: freaknet Medialab :: GPG key available  ]
[ key fingerprint :: - :: B7E2 48BC 705F AE8F 9ABE  E422 076A 2561 1D67 B4DD ]
[ GPG key available on keyserver :: pgp.mit.edu :: with keyID :: 1D67B4DD :: ]

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[linas]

On Wed, Jan 14, 2004 at 05:11:07PM +0100, valvoline wrote:
> of drivers are required? i think that simple win32-drivers cannot work
> properly in a different architecture with different *endian.

totally irrelevent and off-topic, but ... the ppc can (or used
to be able to) switch endianess dynamically.  To be more correct,
it can run some user-space code that was little endian, by having
the kernel set the appropriate bit in the MSR before it ran the
app.  I have no idea is the linux kernel saves/restores this bit(s),
or if this is still supported on the newest processors.

--linas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Segher Boessenkool]

On 15-jan-04, at 1:13, linas@austin.ibm.com wrote:
> totally irrelevent and off-topic, but ... the ppc can (or used
> to be able to) switch endianess dynamically.  To be more correct,
> it can run some user-space code that was little endian, by having
> the kernel set the appropriate bit in the MSR before it ran the
> app.  I have no idea is the linux kernel saves/restores this bit(s),
> or if this is still supported on the newest processors.

It can also run supervisor-level code in little endian mode.

The 2.0 PEM still doesn't show this support as optional [look at the
ILE and LE bits in the MSR], but it does say that "the code sequence
used to switch from big to little-endian mode may differ among
processors".

Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
mode
at all.

As these bits are in the MSR, and you are supposed to leave alone the
bits
that you don't explicitly touch, I suppose the Linux kernel
saves/restores
the bits just fine.  But I didn't check whether it actually does, so
YMMV.


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Gabriel Paubert]

On Thu, Jan 15, 2004 at 10:30:21AM +0100, Segher Boessenkool wrote:
>
> On 15-jan-04, at 1:13, linas@austin.ibm.com wrote:
> >totally irrelevent and off-topic, but ... the ppc can (or used
> >to be able to) switch endianess dynamically.  To be more correct,
> >it can run some user-space code that was little endian, by having
> >the kernel set the appropriate bit in the MSR before it ran the
> >app.  I have no idea is the linux kernel saves/restores this bit(s),
> >or if this is still supported on the newest processors.
>
> It can also run supervisor-level code in little endian mode.
>
> The 2.0 PEM still doesn't show this support as optional [look at the
> ILE and LE bits in the MSR], but it does say that "the code sequence
> used to switch from big to little-endian mode may differ among
> processors".
>
> Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
> mode
> at all.

BTW, where did you find this? IBM's sites have no real documentation on
the 970, or I was too dumb to find them.

>
> As these bits are in the MSR, and you are supposed to leave alone the
> bits
> that you don't explicitly touch, I suppose the Linux kernel
> saves/restores
> the bits just fine.  But I didn't check whether it actually does, so
> YMMV.


It's more complex than this, because it is pseudo little endian, munging
low address bits. The memory seen as an array of bytes is not invariant
through this transformation for most processors. For example the character
chain "abcdefgh" copied from a kernel buffer through a read call will
look as "hgfedcba" from a little endian application. Bridges have a
"LE" bit to also mung addresses during DMA and PIO transfers.

But this makes it almost impossible to support a mixture of little and
bug endian applications. Indeed the ROM BIOS x86 emulator I wrote a
few years ago runs in big-endian mode and uses {l,st}[hw]brx instructions
to emulate x86 crapitecture.

	Gabriel

P.S.: there is nothing wrong with calling little-endian wrong or
perverted or fucked-up ;-)

file (or written from the kernel
>
>
> Segher
>
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Segher Boessenkool]

>> Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
>> mode
>> at all.
>
> BTW, where did you find this? IBM's sites have no real documentation on
> the 970, or I was too dumb to find them.

I work for IBM.  I did not realize this information wasn't
publicly available -- if it isn't, and it's not just you.

> It's more complex than this, because it is pseudo little endian,
> munging
> low address bits.

It's not, afaics.

>  The memory seen as an array of bytes is not invariant
> through this transformation for most processors. For example the
> character
> chain "abcdefgh" copied from a kernel buffer through a read call will
> look as "hgfedcba" from a little endian application.

Representation depends on access size.

>  Bridges have a
> "LE" bit to also mung addresses during DMA and PIO transfers.

Well yeah, PCI swizzling is awful and complicates the hell out
of everything.

> But this makes it almost impossible to support a mixture of little and
> bug endian applications. Indeed the ROM BIOS x86 emulator I wrote a
> few years ago runs in big-endian mode and uses {l,st}[hw]brx
> instructions
> to emulate x86 crapitecture.

That's how to normally access PCI as well, yeah.

> P.S.: there is nothing wrong with calling little-endian wrong or
> perverted or fucked-up ;-)

I don't know if I trust you here -- you wrote "bug endian" just a few
lines up ;-)


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Sven Luther]

On Thu, Jan 15, 2004 at 02:00:16PM +0100, Segher Boessenkool wrote:
>
> >>Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
> >>mode
> >>at all.
> >
> >BTW, where did you find this? IBM's sites have no real documentation on
> >the 970, or I was too dumb to find them.
>
> I work for IBM.  I did not realize this information wasn't
> publicly available -- if it isn't, and it's not just you.

I think there was made mention of this in one of the more technical reports
that followed the G5 release.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Segher Boessenkool]

On 15-jan-04, at 14:12, Sven Luther wrote:
> I think there was made mention of this in one of the more technical
> reports
> that followed the G5 release.

Yeah I figured I must have seen it somewhere before (phew, I'm saved
;-) ).


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Colin Leroy]

> BTW, where did you find this? IBM's sites have no real documentation on
> the 970, or I was too dumb to find them.

Maybe here:
http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC_970_Microprocessor

(i've been too lazy to read them, however) ;-)
--
Colin
Ne disez pas disez, mais disez dites


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Gabriel Paubert]

On Thu, Jan 15, 2004 at 02:00:16PM +0100, Segher Boessenkool wrote:
>
> >>Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
> >>mode
> >>at all.
> >
> >BTW, where did you find this? IBM's sites have no real documentation on
> >the 970, or I was too dumb to find them.
>
> I work for IBM.  I did not realize this information wasn't
> publicly available -- if it isn't, and it's not just you.

The fact is that the documentation for the 970 is by far the
poorest from all the processors on IBM's website. I believed
IBM would release more information about these processors. Or
doesn't IBM really want to sell them?

Anyway, since you seem to have ties inside IBM ;-), you might
know why they do not even give a list of differences of the
970 implementation. I know from another source that the 970 does
not have BATs, but supports large pages with a size of 16MB.

>
> >It's more complex than this, because it is pseudo little endian,
> >munging
> >low address bits.
>
> It's not, afaics.

It's the case for all 603/604/7xx/7xxx processors.

>
> > The memory seen as an array of bytes is not invariant
> >through this transformation for most processors. For example the
> >character
> >chain "abcdefgh" copied from a kernel buffer through a read call will
> >look as "hgfedcba" from a little endian application.
>
> Representation depends on access size.

Indeed, but I said array of bytes, implying byte size accesses even
if it was not clear. However, I forgot to mention that it should be
an 8 byte array on a 8 byte boundary. This is the rule for all the
processors I have mentioned before.

>
> > Bridges have a
> >"LE" bit to also mung addresses during DMA and PIO transfers.
>
> Well yeah, PCI swizzling is awful and complicates the hell out
> of everything.

Well, if the processors switched to little endian with byte
invariant addressing, there would be no need for mode switching
control bits in the bridges, and it would be almost easy to
support a mixture of BE and LE applications (note that I said
"almost", but the only practical interest is for emulators).

>
> >But this makes it almost impossible to support a mixture of little and
> >bug endian applications. Indeed the ROM BIOS x86 emulator I wrote a
> >few years ago runs in big-endian mode and uses {l,st}[hw]brx
> >instructions
> >to emulate x86 crapitecture.
>
> That's how to normally access PCI as well, yeah.
>
> >P.S.: there is nothing wrong with calling little-endian wrong or
> >perverted or fucked-up ;-)
>
> I don't know if I trust you here -- you wrote "bug endian" just a few
> lines up ;-)

Damned laptop keyboards! U and I keys are just too close from each
other;-) Apart from this, if you look up some archives, you'll certainly
find that I think, live and breathe big-endianly ;-) (bit 0 is the most
significant bit, period)

Now the fact that the 970 does not support backwards-endian is a very
good thing. From time to time (although it has been less frequent
recently) somebody suggest on the list that Linux/PPC switches to the
dark side of the endianness. The fact that some processors don't support
it will be a killer argument.

	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Gabriel Paubert]

On Thu, Jan 15, 2004 at 02:39:01PM +0100, Colin Leroy wrote:
>
> > BTW, where did you find this? IBM's sites have no real documentation on
> > the 970, or I was too dumb to find them.
>
> Maybe here:
> http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC_970_Microprocessor

Well, there is nothing really new nor truly interesting there.

	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[linas]

On Fri, Jan 16, 2004 at 08:54:06PM +0100, Gabriel Paubert wrote:
> find that I think, live and breathe big-endianly ;-) (bit 0 is the most

awww, come on, I thought "bug endian" was pretty funny!

--linas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Benjamin Herrenschmidt]

> Anyway, since you seem to have ties inside IBM ;-), you might
> know why they do not even give a list of differences of the
> 970 implementation. I know from another source that the 970 does
> not have BATs, but supports large pages with a size of 16MB.

Yup, it's more/less a POWER4 in this regard (which is probably
as badly documented :)

I'll check out the status of public specs, I _think_ that there is
some doc in the process of beeing cleaned up & declassified for this
chip, but I'm not 100% sure at this point.

> Now the fact that the 970 does not support backwards-endian is a very
> good thing. From time to time (although it has been less frequent
> recently) somebody suggest on the list that Linux/PPC switches to the
> dark side of the endianness. The fact that some processors don't support
> it will be a killer argument.

Hehe, you know, there isn't much risk that we take such a patch in
the first place anyway :)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Geert Uytterhoeven]

On Fri, 16 Jan 2004, Gabriel Paubert wrote:
> On Thu, Jan 15, 2004 at 02:00:16PM +0100, Segher Boessenkool wrote:
> > >P.S.: there is nothing wrong with calling little-endian wrong or
> > >perverted or fucked-up ;-)
> >
> > I don't know if I trust you here -- you wrote "bug endian" just a few
> > lines up ;-)
>
> Damned laptop keyboards! U and I keys are just too close from each
> other;-) Apart from this, if you look up some archives, you'll certainly
> find that I think, live and breathe big-endianly ;-) (bit 0 is the most
> significant bit, period)

Although I prefer big endian myself, I don't like counting bits in the `wrong'
direction ;-) Hence bit 0 is always the least significant bit.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Segher Boessenkool]

> Anyway, since you seem to have ties inside IBM ;-), you might
> know why they do not even give a list of differences of the
> 970 implementation.

I guess the documentation is just not ready for public consumption.
I don't really know.

> I know from another source that the 970 does
> not have BATs, but supports large pages with a size of 16MB.

The BAT thing at least is documented (and has been documented
_for ever_ -- see the PEM, the 970 is a 64-bit chip.  Get the
rev 2.0 PEM from the 970 doc page).

The large page thing is cpu specific afaik (from memory).


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Benjamin Herrenschmidt]

> The BAT thing at least is documented (and has been documented
> _for ever_ -- see the PEM, the 970 is a 64-bit chip.  Get the
> rev 2.0 PEM from the 970 doc page).
>
> The large page thing is cpu specific afaik (from memory).

POWER3 had BATs

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Segher Boessenkool]

On 19-jan-04, at 23:05, Benjamin Herrenschmidt wrote:

>
>> The BAT thing at least is documented (and has been documented
>> _for ever_ -- see the PEM, the 970 is a 64-bit chip.  Get the
>> rev 2.0 PEM from the 970 doc page).
>>
>> The large page thing is cpu specific afaik (from memory).
>
> POWER3 had BATs

Sure, but BATs are not *required* by the 64-bit architecture.


Segher


p.s.  Well actually, I went to check -- and the PEM 2.0 _does_
define BATs for 64-bit.  Let's put this under "POWER4 and
derivatives specific" as well then, until the docs get fixed :-)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broadcom BCM94306

[Gabriel Paubert]

On Tue, Jan 20, 2004 at 07:01:15PM +0100, Segher Boessenkool wrote:
>
> On 19-jan-04, at 23:05, Benjamin Herrenschmidt wrote:
>
> >
> >>The BAT thing at least is documented (and has been documented
> >>_for ever_ -- see the PEM, the 970 is a 64-bit chip.  Get the
> >>rev 2.0 PEM from the 970 doc page).
> >>
> >>The large page thing is cpu specific afaik (from memory).
> >
> >POWER3 had BATs
>
> Sure, but BATs are not *required* by the 64-bit architecture.
>
>
> Segher
>
>
> p.s.  Well actually, I went to check -- and the PEM 2.0 _does_
> define BATs for 64-bit.  Let's put this under "POWER4 and
> derivatives specific" as well then, until the docs get fixed :-)

Indeed, sorry for the late reply, but I was really wondering how you
could interpret a bit level description of the BATs and the sentences
describing them as "some implementations may not have them" ;-)

There are no mention of big/large/huge pages either[1], nor of
instructions which may have been added for Power4/970 (I know
about mfcrf)

Frankly speaking the current state of the documentation is worrying me,
I remember that when the PPC750 was announced, a lot of documentation
was added to IBM and Motorola websites in a matter of days.

	Regards,
	Gabriel

[1] well, I found some mentions of the large pages in a redbook about
Power4. But that's about all.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/