USB support on mpc5200 broken

USB support on mpc5200 broken

[Jon Smirl]

USB is not working my hardware, so I booted my Efika and it's not
working there either.  This is with linus' current git.

Can anyone verify this? Or know what happened to USB?
USB is loading but it is not finding anything plugged in.
lsusb doesn't show anything.

Last time I noticed it was working was about ten days ago. I don't use
it everyday.

usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
ASoC version 0.31
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
audit: initializing netlink socket (disabled)
type=2000 audit(1222292382.243:1): initialized
msgmni has been set to 247 for ipc namespace c0316b94
io scheduler noop registered
io scheduler deadline registered (default)
Macintosh non-volatile memory driver v1.1
Serial: MPC52xx PSC UART driver
f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
brd: module loaded
loop: module loaded
mpc52xx MII bus: probed
net eth0: Using PHY at MDIO address 16
Driver 'sd' needs updating - please use bus_type methods
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.16.
tas5504_driver_init
mpc52xx_i2s_driver_init
digispeaker_driver_init
ALSA device list:
  No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
net eth0: attached phy 16 to driver Generic PHY
Sending DHCP requests .<6>PHY: f0003000:10 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.109
IP-Config: Complete:
     device=eth0, addr=192.168.1.109, mask=255.255.255.0, gw=192.168.1.1,
     host=192.168.1.109, domain=, nis-domain=(none),
     bootserver=192.168.1.1, rootserver=192.168.1.4, rootpath=
Looking up port of RPC 100003/3 on 192.168.1.4
Looking up port of RPC 100005/3 on 192.168.1.4



-- 
Jon Smirl
jonsmirl@gmail.com

Re: USB support on mpc5200 broken

[Jon Smirl]

On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> USB is not working my hardware, so I booted my Efika and it's not
> working there either.  This is with linus' current git.
>
> Can anyone verify this? Or know what happened to USB?
> USB is loading but it is not finding anything plugged in.
> lsusb doesn't show anything.
>
> Last time I noticed it was working was about ten days ago. I don't use
> it everyday.

Efika is broken because of this:

ohci-ppc-of.c...
	is_bigendian =
		of_device_is_compatible(dn, "ohci-bigendian") ||
		of_device_is_compatible(dn, "ohci-be");

Efika doesn't have either of those in it's compatible string.

This doesn't look to me like a very reliable way to determine bigendian.


My hardware may not be working because I've broken it. Time to call in
the hardware engineers.



>
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> ASoC version 0.31
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> NET: Registered protocol family 1
> audit: initializing netlink socket (disabled)
> type=2000 audit(1222292382.243:1): initialized
> msgmni has been set to 247 for ipc namespace c0316b94
> io scheduler noop registered
> io scheduler deadline registered (default)
> Macintosh non-volatile memory driver v1.1
> Serial: MPC52xx PSC UART driver
> f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
> brd: module loaded
> loop: module loaded
> mpc52xx MII bus: probed
> net eth0: Using PHY at MDIO address 16
> Driver 'sd' needs updating - please use bus_type methods
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i2c /dev entries driver
> usbcore: registered new interface driver usbhid
> usbhid: v2.6:USB HID core driver
> Advanced Linux Sound Architecture Driver Version 1.0.16.
> tas5504_driver_init
> mpc52xx_i2s_driver_init
> digispeaker_driver_init
> ALSA device list:
>  No soundcards found.
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> net eth0: attached phy 16 to driver Generic PHY
> Sending DHCP requests .<6>PHY: f0003000:10 - Link is Up - 100/Full
> ., OK
> IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.109
> IP-Config: Complete:
>     device=eth0, addr=192.168.1.109, mask=255.255.255.0, gw=192.168.1.1,
>     host=192.168.1.109, domain=, nis-domain=(none),
>     bootserver=192.168.1.1, rootserver=192.168.1.4, rootpath=
> Looking up port of RPC 100003/3 on 192.168.1.4
> Looking up port of RPC 100005/3 on 192.168.1.4
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: USB support on mpc5200 broken

[Benjamin Herrenschmidt]

On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
> On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > USB is not working my hardware, so I booted my Efika and it's not
> > working there either.  This is with linus' current git.
> >
> > Can anyone verify this? Or know what happened to USB?
> > USB is loading but it is not finding anything plugged in.
> > lsusb doesn't show anything.
> >
> > Last time I noticed it was working was about ten days ago. I don't use
> > it everyday.
> 
> Efika is broken because of this:
> 
> ohci-ppc-of.c...
> 	is_bigendian =
> 		of_device_is_compatible(dn, "ohci-bigendian") ||
> 		of_device_is_compatible(dn, "ohci-be");
> 
> Efika doesn't have either of those in it's compatible string.
> 
> This doesn't look to me like a very reliable way to determine bigendian.

You mean it's not reliable to expect people device-trees not to
suck ? :-)

Ben.

Re: USB support on mpc5200 broken

[Jon Smirl]

On Wed, Sep 24, 2008 at 9:50 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
>> On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > USB is not working my hardware, so I booted my Efika and it's not
>> > working there either.  This is with linus' current git.
>> >
>> > Can anyone verify this? Or know what happened to USB?
>> > USB is loading but it is not finding anything plugged in.
>> > lsusb doesn't show anything.
>> >
>> > Last time I noticed it was working was about ten days ago. I don't use
>> > it everyday.
>>
>> Efika is broken because of this:
>>
>> ohci-ppc-of.c...
>>       is_bigendian =
>>               of_device_is_compatible(dn, "ohci-bigendian") ||
>>               of_device_is_compatible(dn, "ohci-be");
>>
>> Efika doesn't have either of those in it's compatible string.
>>
>> This doesn't look to me like a very reliable way to determine bigendian.
>
> You mean it's not reliable to expect people device-trees not to
> suck ? :-)

No, because the ochi driver has been changed to require
"fsl,mpc5200b-ohci" or "fsl,mpc5200-ohci" and generic "ohci-be"
doesn't work anymore.  You need CONFIG_USB_OHCI_HCD_PPC_SOC now for
mpc5200 usb to work.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: USB support on mpc5200 broken

[Matt Sealey]

Benjamin Herrenschmidt wrote:
> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
>>> Last time I noticed it was working was about ten days ago. I don't use
>>> it everyday.
>> Efika is broken because of this:
>>
>> ohci-ppc-of.c...
>> 	is_bigendian =
>> 		of_device_is_compatible(dn, "ohci-bigendian") ||
>> 		of_device_is_compatible(dn, "ohci-be");
>>
>> Efika doesn't have either of those in it's compatible string.
>>
>> This doesn't look to me like a very reliable way to determine bigendian.
> 
> You mean it's not reliable to expect people device-trees not to
> suck ? :-)

It's reasonable to expect that device-trees do not get updated with the
kernel for certain platforms (it does not fit into most quality assurance
schedules to reflash every user's firmware every time they want to move up
one revision to another, given the kernel release schedule of every 3-4
months) and when updating the search for compatible entries it should
take into account these platforms.

We had this discussion a few months back (just before I released the
last version of the device tree supplement script) when patches were
being submitted that broke detection. It was agreed that at least one
of the Efika compatibles should stay in there, mostly likely the least
insane one.

The same patch also introduced a big-endian property to replace the
stupid encoding of endianness into the controller compatible entries,
and we all though that was a great idea. "ohci-bigendian" is simply
wrong by this regard, and if the policy has changed since then, then
we are looking at yet another device tree policy flip-flop which is
starting to move more towards annoying, than being simply an acceptable
fact of life due to the Linux development process.

Jon, just use efika.forth from http://www.powerdeveloper.org/ and add
in the appropriate entry, or make a snippet for it and add it to nvramrc.

If it doesn't work, bug me about it and I will release an update as I
have one which goes way overboard and includes every variation for
compatible USB drivers and tries to make gpio fit the new gpio specs
and i2c and can buses exposed.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: USB support on mpc5200 broken

[David Gibson]

On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote:
>
> Benjamin Herrenschmidt wrote:
>> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
>>>> Last time I noticed it was working was about ten days ago. I don't use
>>>> it everyday.
>>> Efika is broken because of this:
>>>
>>> ohci-ppc-of.c...
>>> 	is_bigendian =
>>> 		of_device_is_compatible(dn, "ohci-bigendian") ||
>>> 		of_device_is_compatible(dn, "ohci-be");
>>>
>>> Efika doesn't have either of those in it's compatible string.
>>>
>>> This doesn't look to me like a very reliable way to determine bigendian.
>>
>> You mean it's not reliable to expect people device-trees not to
>> suck ? :-)

Alas, this is true :(.

> It's reasonable to expect that device-trees do not get updated with the
> kernel for certain platforms (it does not fit into most quality assurance
> schedules to reflash every user's firmware every time they want to move up
> one revision to another, given the kernel release schedule of every 3-4
> months) and when updating the search for compatible entries it should
> take into account these platforms.

This, of course, is exactly why I *don't* recommend embedded platforms
move to including the device tree in the flashed firmware.  Keeping
the device tree in the bootwrapper means that it *is* updated with the
kernel and we don't have to mess around with as much backwards
compatibility junk.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: USB support on mpc5200 broken

[Jon Smirl]

On Sun, Sep 28, 2008 at 11:43 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote:
>>
>> Benjamin Herrenschmidt wrote:
>>> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
>>>>> Last time I noticed it was working was about ten days ago. I don't use
>>>>> it everyday.
>>>> Efika is broken because of this:
>>>>
>>>> ohci-ppc-of.c...
>>>>     is_bigendian =
>>>>             of_device_is_compatible(dn, "ohci-bigendian") ||
>>>>             of_device_is_compatible(dn, "ohci-be");
>>>>
>>>> Efika doesn't have either of those in it's compatible string.
>>>>
>>>> This doesn't look to me like a very reliable way to determine bigendian.
>>>
>>> You mean it's not reliable to expect people device-trees not to
>>> suck ? :-)
>
> Alas, this is true :(.


Efika has this:
compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci";

That completely describes the hardware. Isn't that what a device tree
is supposed to do?

If we really need a big endian flag, should it be an attribute?

		usb@1000 {
			compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci";
			ohci-be;
			reg = <0x1000 0xff>;
			interrupts = <0x2 0x6 0x0>;
			interrupt-parent = <&mpc5200_pic>;
		};

Shouldn't the driver already know it is being used on a BE machine?


>
>> It's reasonable to expect that device-trees do not get updated with the
>> kernel for certain platforms (it does not fit into most quality assurance
>> schedules to reflash every user's firmware every time they want to move up
>> one revision to another, given the kernel release schedule of every 3-4
>> months) and when updating the search for compatible entries it should
>> take into account these platforms.
>
> This, of course, is exactly why I *don't* recommend embedded platforms
> move to including the device tree in the flashed firmware.  Keeping
> the device tree in the bootwrapper means that it *is* updated with the
> kernel and we don't have to mess around with as much backwards
> compatibility junk.

How do I adjust my build to put the DTB into a wrapper? I'm based on
the pcm030 makefile and it assumes the DTB is built externally.

Can u-boot handle the wrapped DTB? I'm using a pointer to kernel and
one to DTB when booting from u-boot.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: USB support on mpc5200 broken

[Peter Korsgaard]

>>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes:

Hi,

 Jon> How do I adjust my build to put the DTB into a wrapper? I'm
 Jon> based on the pcm030 makefile and it assumes the DTB is built
 Jon> externally.

 Jon> Can u-boot handle the wrapped DTB? I'm using a pointer to kernel
 Jon> and one to DTB when booting from u-boot.

See my recent (nacked by Wolfgang, but sane in principle) patch for
uImage.<platform> support:

http://patchwork.ozlabs.org/patch/589/

-- 
Bye, Peter Korsgaard

Re: USB support on mpc5200 broken

[Jon Smirl]

On Mon, Sep 29, 2008 at 10:22 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes:
>
> Hi,
>
>  Jon> How do I adjust my build to put the DTB into a wrapper? I'm
>  Jon> based on the pcm030 makefile and it assumes the DTB is built
>  Jon> externally.
>
>  Jon> Can u-boot handle the wrapped DTB? I'm using a pointer to kernel
>  Jon> and one to DTB when booting from u-boot.
>
> See my recent (nacked by Wolfgang, but sane in principle) patch for
> uImage.<platform> support:
>
> http://patchwork.ozlabs.org/patch/589/

So I should wait for the version that uses FIT images.

>
> --
> Bye, Peter Korsgaard
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: USB support on mpc5200 broken

[Peter Korsgaard]

>>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes:

Hi,

 Jon> Can u-boot handle the wrapped DTB? I'm using a pointer to kernel
 Jon> and one to DTB when booting from u-boot.
 >> 
 >> See my recent (nacked by Wolfgang, but sane in principle) patch for
 >> uImage.<platform> support:
 >> 
 >> http://patchwork.ozlabs.org/patch/589/

 Jon> So I should wait for the version that uses FIT images.

Well, yeah. As I said earlier, I won't have time to work on that right
away, so you can either use the patch as is, wait or implement FIT
support yourself.

-- 
Bye, Peter Korsgaard

Re: USB support on mpc5200 broken

[Scott Wood]

On Mon, Sep 29, 2008 at 10:14:18AM -0400, Jon Smirl wrote:
> Shouldn't the driver already know it is being used on a BE machine?

No.  Endianness of the CPU is not necessarily the same as the endianness
of device registers.

For example, PCI OHCI on a big-endian host.

-Scott

Re: USB support on mpc5200 broken

[Jon Smirl]

On Mon, Sep 29, 2008 at 4:18 PM, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Sep 29, 2008 at 10:14:18AM -0400, Jon Smirl wrote:
>> Shouldn't the driver already know it is being used on a BE machine?
>
> No.  Endianness of the CPU is not necessarily the same as the endianness
> of device registers.
>
> For example, PCI OHCI on a big-endian host.

Endianess is encoded in the specific compatible string.

compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci";
This is BE.

inside PCI bus section
compatible = "my-pci-ohci-card"
This would be LE

The specifically loaded driver knows it's endianess.

But now you're tell me I need
compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci",  "ohci-be"

But that doesn't work right on the mpc5200. If I remove the mpc5200
specific device driver from my system it will cause the generic
ohci-be one to load. And the generic one doesn't work.

The mpc5200 ohci device driver should be setting the endianess state
into the generic ohci code.


>
> -Scott
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: USB support on mpc5200 broken

[Grant Likely]

On Mon, Sep 29, 2008 at 05:04:22PM -0400, Jon Smirl wrote:
> On Mon, Sep 29, 2008 at 4:18 PM, Scott Wood <scottwood@freescale.com> wrote:
> > On Mon, Sep 29, 2008 at 10:14:18AM -0400, Jon Smirl wrote:
> >> Shouldn't the driver already know it is being used on a BE machine?
> >
> > No.  Endianness of the CPU is not necessarily the same as the endianness
> > of device registers.
> >
> > For example, PCI OHCI on a big-endian host.
> 
> Endianess is encoded in the specific compatible string.
> 
> compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci";
> This is BE.
> 
> inside PCI bus section
> compatible = "my-pci-ohci-card"
> This would be LE
> 
> The specifically loaded driver knows it's endianess.
> 
> But now you're tell me I need
> compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci",  "ohci-be"

No, we can't do that.

You're right about the current data in compatible being sufficient.
The kernel needs to deal with what firmware hands it,
either by fixups to the device tree data or by teaching the driver
what fsl,mpc5200b-ohci means.

g.

Re: USB support on mpc5200 broken

[Matt Sealey]

Jon Smirl wrote:

> 
> Efika has this:
> compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci";

It doesn't :D

My system, running production firmware, says

ohci-bigendian,ohci-be,mpc5200-ohci,mpc5200-usb

This is what we were recommended to use at the time. There is a patch
on www.powerdeveloper.org which tweaks the tree to make it ultra-compliant
with the Linux version of things, which implements every variation. It
also implements a suggested patch which added a "big-endian" property
(not built in to the compatible property, but another property).

I don't see why THAT patch got reverted as it was a great idea that we
all agreed was a great idea.

Linux development around here is getting really schizophrenic. Nobody
is writing these decisions down even as comments in the source code..

> If we really need a big endian flag, should it be an attribute?

Yes.

> Shouldn't the driver already know it is being used on a BE machine?

No; you can have little endian OHCI controllers on big endian machines.
It's a property of the host controller, not the system architecture, just
like PCI is always little endian (except when you have magic in hardware
like Amiga PowerUP cards which endianswap for you :)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: USB support on mpc5200 broken

[Benjamin Herrenschmidt]

> This is what we were recommended to use at the time. There is a patch
> on www.powerdeveloper.org which tweaks the tree to make it ultra-compliant
> with the Linux version of things, which implements every variation. It
> also implements a suggested patch which added a "big-endian" property
> (not built in to the compatible property, but another property).
> 
> I don't see why THAT patch got reverted as it was a great idea that we
> all agreed was a great idea.

I agree. Something needs to be fixed on the OHCI OF stuff, it should
definitely cope with the "big-endian" property (which is a practice
borrowed from Apple that I recommended I think back then) and I don't
see any problem with having ohci-be in the "compatible" property, its
trivial enough to cope in the driver and being anal about it on the
kernel side doesn't really bring any benefit.

Care to send a patch ?

> Linux development around here is getting really schizophrenic. Nobody
> is writing these decisions down even as comments in the source code..

That isn't entirely true. There's the ePAPR effort on power.org that is
codifying a lot of that, and there are binding documents dropped in
Documentation/powerpc.

> No; you can have little endian OHCI controllers on big endian machines.
> It's a property of the host controller, not the system architecture, just
> like PCI is always little endian (except when you have magic in hardware
> like Amiga PowerUP cards which endianswap for you :)

In fact, you can have both kinds on the same machine.

Note about the Amiga stuff: it's a bad idea :-) Every attempt at
"magically" fixing endian in HW is a recipe for tears and disasters.
Approximately ... always. The only cases that I know that have a remote
chance of being useful are specifically programmable swappers on a given
device or per-page endian configuration in the processor (like BooKE).

Cheers,
Ben.

RE: USB support on mpc5200 broken

[Carsten Schlote]

Hi Ben,

> Note about the Amiga stuff: it's a bad idea :-) Every attempt=20
> at "magically" fixing endian in HW is a recipe for tears and=20
> disasters.

I fully agree. It's one of the problem I encountered with some similiar
approach on some other big-endian Freescale CPU. It is implemented as a
hard-wired 'endian-swap feature' and it simply makes everything much
more complicated for code intended to run on LE and BE CPU by virtually
adding some additional special case.=20

> Approximately ... always. The only cases that I know that=20
> have a remote chance of being useful are specifically=20
> programmable swappers on a given device or per-page endian=20
> configuration in the processor (like BooKE).

Also agree. There might be use-cases, where hardware-supported
endian-swapping might be useful. But it must be an optional feature.=20

It's already some PITA to develope and maintain drivers running on LE/BE
CPUs and to properly access word and longword PCI registers
endian-transparent. Byte streams should never be affected by endianess
anyway.=20

Automatic endian-swapping might speed up some register accesses or e.g.
framebuffer accesses (reverse pixel endianess), but in general it adds
more problems than it's worth.=20

The framebuffer use-case is currently the only one, where such a
hardware-swapper could be really useful. But still the drivers would
have to know about this feature, it would require query/set macros/fcts
for endian translation modes in the kernel, ... - in short it causes
lots of extra overhead. And for framebuffers the need for such hard-ware
swappers can be eleminated by using the right framebuffer mode.

I fear, that such hard-wired 'magic' swapping is the source and reason
for some of my current problems.

Carsten

RE: USB support on mpc5200 broken

[Benjamin Herrenschmidt]

On Wed, 2008-10-01 at 11:46 +0200, Carsten Schlote wrote:
> 
> 
> The framebuffer use-case is currently the only one, where such a
> hardware-swapper could be really useful. But still the drivers would
> have to know about this feature, it would require query/set macros/fcts
> for endian translation modes in the kernel, ... - in short it causes
> lots of extra overhead. And for framebuffers the need for such hard-ware
> swappers can be eleminated by using the right framebuffer mode.

Actually, fb's are -the- case where it's really necessary to have endian
swappers when they sit on PCI due to the way byte lanes are swapped on a
PCI host bridge on a BE platform, if you want to keep the same pixel
order as an x86 which is usually not only all that cards support, while
still having SW use native order which is usually all that the X server
supports :-)

> I fear, that such hard-wired 'magic' swapping is the source and reason
> for some of my current problems.

I wouldn't be surprised. The worst case I've seen is HW engineers trying
to be too smart for their own good and swapping the byte lanes of >8
bits data stream fifo's such as IDE (yeah, it makes the IDE ID block
more directly readable, at the expense of swapping all the data
effectively preventing the use of DMA unless you are fine with a custom
on-disk format incompatible with everything else).

Cheers,
Ben.

Re: USB support on mpc5200 broken

[Matt Sealey]

Benjamin Herrenschmidt wrote:
>> This is what we were recommended to use at the time. There is a patch
>> on www.powerdeveloper.org which tweaks the tree to make it ultra-compliant
>> with the Linux version of things, which implements every variation. It
>> also implements a suggested patch which added a "big-endian" property
>> (not built in to the compatible property, but another property).
>>
>> I don't see why THAT patch got reverted as it was a great idea that we
>> all agreed was a great idea.
> 
> I agree. Something needs to be fixed on the OHCI OF stuff, it should
> definitely cope with the "big-endian" property (which is a practice
> borrowed from Apple that I recommended I think back then) and I don't
> see any problem with having ohci-be in the "compatible" property, its
> trivial enough to cope in the driver and being anal about it on the
> kernel side doesn't really bring any benefit.

I see a problem with having ohci-be being in there to the exclusion of
fixed properties on existing hardware that are not easy to realise what
changed (i.e. you upgrade your kernel, and not being an avid follower
of linux-usb or linuxppc-dev, wonder why USB stopped working).

It's not that easy for a lot of people who are not kernel developers to
find out WHY it broke let alone HOW to fix it (edit the USB compatibility
names list to re-add it, use efika.forth, edit a custom snippet in nvramrc
or a forth boot script, hack chrp_fixups some more - in order of increasing
brain death :)

> Care to send a patch ?

I don't really have time to go into it right now but I will look into
it. At some point I have to get my act together and release the latest
version of efika.forth as some things did change between that and the
latest Linux version...

>> Linux development around here is getting really schizophrenic. Nobody
>> is writing these decisions down even as comments in the source code..
> 
> That isn't entirely true. There's the ePAPR effort on power.org that is
> codifying a lot of that, and there are binding documents dropped in
> Documentation/powerpc.

You know I don't believe in Power.org any more than I believe in the
tooth fairy. Codifying ePAPR is just reverse engineering decisions made
a year ago with the booting-without-of.txt and the existing code, and
putting it into a document.

It didn't solve this situation and it won't - ePAPR can't help codifying
a board's device tree that was engineered, produced and will probably
be discontinued before a decent version of ePAPR will be released. Just
like ePAPR doesn't expect anyone conform to Apple device trees, ePAPR
will not make Efika device trees suddenly work without "help" (which is
why I wrote that forth script..)

>> No; you can have little endian OHCI controllers on big endian machines.
>> It's a property of the host controller, not the system architecture, just
>> like PCI is always little endian (except when you have magic in hardware
>> like Amiga PowerUP cards which endianswap for you :)
> 
> In fact, you can have both kinds on the same machine.

And all kinds of USB controllers at once. I have seen a Pegasos with a
little endian UHCI, big endian OHCI, little endian OHCI in the same
box. Very confusing for drivers. Don't get me started on the FireWire
OHCI, which I think above "ohci-be" really conflicts with in terms
of namespace.

What I thought we all agreed on before was this;

compatible = "usb-ohci, usb-ohci-be"
big-endian

Would be canonical. That way you can tell it's OHCI USB, it's big
endian for compatibility and big-endian property just in case the
driver forgot or was misled somehow (at least it should match on
usb-ohci, usb-ohci-be, then check if usb-ohci-be is present, and
then check for big-endian, and it will have a comprehensive
knowledge..)

There stands to be some discussion over whether mpc5200-usb-ohci
or mpc5200-ohci or mpc5200-usb is valid or required or not. You
still need to check for quirks (I am sure there ARE some) after
all.

I really wish it would be codified somewhere so that we could once
and for all put in exactly what it should be, and not just change
it at the whim of the latest patch (the reason we do not release
firmware this often is because the burden of releasing firmware does
not match the expectations of a 3-month-long kernel release where
the decisions are overturned, reverted and having 15 firmware
versions since release makes our life and your lives much harder
when fixing these things down. Efika stayed as it was, so it can
be consistently supported :)

I think the thing to do somewhere is note that while ePAPR is the
recommended practise, it's based on Open Firmware standards which
already exist, and there are still Open Firmware standard firmwares
which still exist, which may not be so easily updated as to just
run the device tree compiler and attach it to a kernel, so when
making decisions about naming or submitting patches about naming,
check out the users of that peripheral and make sure you're not
just submitting a patch assuming that everyone can update their
device tree WITH their kernel :D

> Note about the Amiga stuff: it's a bad idea :-) Every attempt at
> "magically" fixing endian in HW is a recipe for tears and disasters.
> Approximately ... always. The only cases that I know that have a remote
> chance of being useful are specifically programmable swappers on a given
> device or per-page endian configuration in the processor (like BooKE).

I do like that system. But as you said, there are uses for it; and
the APUS swap implementation did allow raw access, 16-bit and 32-bit
swaps through "mirrored" memory regions - you could write any way
you wanted if you so pleased, or just handle the difference yourself,
or do both if you were a masochist :D

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: USB support on mpc5200 broken

[Sven Luther]

On Mon, Sep 29, 2008 at 01:43:29PM +1000, David Gibson wrote:
> On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote:
> >
> > Benjamin Herrenschmidt wrote:
> >> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
> >>>> Last time I noticed it was working was about ten days ago. I don't use
> >>>> it everyday.
> >>> Efika is broken because of this:
> >>>
> >>> ohci-ppc-of.c...
> >>> 	is_bigendian =
> >>> 		of_device_is_compatible(dn, "ohci-bigendian") ||
> >>> 		of_device_is_compatible(dn, "ohci-be");
> >>>
> >>> Efika doesn't have either of those in it's compatible string.
> >>>
> >>> This doesn't look to me like a very reliable way to determine bigendian.
> >>
> >> You mean it's not reliable to expect people device-trees not to
> >> suck ? :-)
> 
> Alas, this is true :(.
> 
> > It's reasonable to expect that device-trees do not get updated with the
> > kernel for certain platforms (it does not fit into most quality assurance
> > schedules to reflash every user's firmware every time they want to move up
> > one revision to another, given the kernel release schedule of every 3-4
> > months) and when updating the search for compatible entries it should
> > take into account these platforms.
> 
> This, of course, is exactly why I *don't* recommend embedded platforms
> move to including the device tree in the flashed firmware.  Keeping
> the device tree in the bootwrapper means that it *is* updated with the
> kernel and we don't have to mess around with as much backwards
> compatibility junk.

This completely defeats the purpopse of having a separate device tree
though, no ? I mean, we could just as well hardcode the device-tree info
in the kernel in this case ? 

(In embedded cases, the kernel is usyually in the flash as well, so you
just upgrade both at the same time :)

Friendly,

Sven Luther

Re: USB support on mpc5200 broken

[Peter Korsgaard]

>>>>> "Sven" == Sven Luther <sven@genesi-usa.com> writes:

Hi,

 >> This, of course, is exactly why I *don't* recommend embedded platforms
 >> move to including the device tree in the flashed firmware.  Keeping
 >> the device tree in the bootwrapper means that it *is* updated with the
 >> kernel and we don't have to mess around with as much backwards
 >> compatibility junk.

 Sven> This completely defeats the purpopse of having a separate
 Sven> device tree though, no ? I mean, we could just as well hardcode
 Sven> the device-tree info in the kernel in this case ?

Well, yes and no. The device tree brings a number of advantages (and a
few disadvantages as well), one of those being the potential
decoupling of kernel and DT. Even if you don't make use of that
feature in a production build you still have the other advantages
(E.G. easy compile test of multiple boards, limited
repeated-these-are-my-platform-devices code in board files, ...).

 Sven> (In embedded cases, the kernel is usyually in the flash as
 Sven> well, so you just upgrade both at the same time :)

Sure, but if you do that you might as well include them in a single
uImage because:

- They are always in sync
- You don't waste flash space (E.G. the DT is very small, but you
  waste a complete flash sector)

With uImage.<platform> U-Boot can still fix up the tree before booting
the kernel, so you don't lose any functionality (E.G. if you
enable/disable certain nodes based on what option boards are
available).

-- 
Bye, Peter Korsgaard

Re: USB support on mpc5200 broken

[David Gibson]

On Mon, Sep 29, 2008 at 05:18:54PM +0200, Sven Luther wrote:
> On Mon, Sep 29, 2008 at 01:43:29PM +1000, David Gibson wrote:
> > On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote:
> > >
> > > Benjamin Herrenschmidt wrote:
> > >> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
> > >>>> Last time I noticed it was working was about ten days ago. I don't use
> > >>>> it everyday.
> > >>> Efika is broken because of this:
> > >>>
> > >>> ohci-ppc-of.c...
> > >>> 	is_bigendian =
> > >>> 		of_device_is_compatible(dn, "ohci-bigendian") ||
> > >>> 		of_device_is_compatible(dn, "ohci-be");
> > >>>
> > >>> Efika doesn't have either of those in it's compatible string.
> > >>>
> > >>> This doesn't look to me like a very reliable way to determine bigendian.
> > >>
> > >> You mean it's not reliable to expect people device-trees not to
> > >> suck ? :-)
> > 
> > Alas, this is true :(.
> > 
> > > It's reasonable to expect that device-trees do not get updated with the
> > > kernel for certain platforms (it does not fit into most quality assurance
> > > schedules to reflash every user's firmware every time they want to move up
> > > one revision to another, given the kernel release schedule of every 3-4
> > > months) and when updating the search for compatible entries it should
> > > take into account these platforms.
> > 
> > This, of course, is exactly why I *don't* recommend embedded platforms
> > move to including the device tree in the flashed firmware.  Keeping
> > the device tree in the bootwrapper means that it *is* updated with the
> > kernel and we don't have to mess around with as much backwards
> > compatibility junk.
> 
> This completely defeats the purpopse of having a separate device tree
> though, no ? I mean, we could just as well hardcode the device-tree info
> in the kernel in this case ? 

And just what form would "hardcoded" device info take in the kernel?
The *primary* purpose of the device-tree is to have a consistent
in-kernel representation of the hardware information.  A device-tree
was the obvious choice, because OF machines already used it, and it's
flexible enough to cover pretty much anything.

How the kernel gets a device tree doesn't matter so much - we don't
really care if it comes from OF, from some other firmware or if it's
built into the kernel or wrapper.

Being able to pass in the device tree is a secondary advantage in
*some* circumstances - albeit one people seem to have leapt on with
unwise enthusiasm, IMO.  This approachd also has drawbacks which can
override the advantages - specifically that firmware has always been
buggy as hell more often than not, so there's absolutely no reason to
expect that firmware will get a device tree right.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: USB support on mpc5200 broken

[Raquel and Bill]

..wasn't the real issue for the device tree to get the firmware right?

R&B

On Mon, Sep 29, 2008 at 8:12 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Mon, Sep 29, 2008 at 05:18:54PM +0200, Sven Luther wrote:
>> On Mon, Sep 29, 2008 at 01:43:29PM +1000, David Gibson wrote:
>> > On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote:
>> > >
>> > > Benjamin Herrenschmidt wrote:
>> > >> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
>> > >>>> Last time I noticed it was working was about ten days ago. I don't use
>> > >>>> it everyday.
>> > >>> Efika is broken because of this:
>> > >>>
>> > >>> ohci-ppc-of.c...
>> > >>>         is_bigendian =
>> > >>>                 of_device_is_compatible(dn, "ohci-bigendian") ||
>> > >>>                 of_device_is_compatible(dn, "ohci-be");
>> > >>>
>> > >>> Efika doesn't have either of those in it's compatible string.
>> > >>>
>> > >>> This doesn't look to me like a very reliable way to determine bigendian.
>> > >>
>> > >> You mean it's not reliable to expect people device-trees not to
>> > >> suck ? :-)
>> >
>> > Alas, this is true :(.
>> >
>> > > It's reasonable to expect that device-trees do not get updated with the
>> > > kernel for certain platforms (it does not fit into most quality assurance
>> > > schedules to reflash every user's firmware every time they want to move up
>> > > one revision to another, given the kernel release schedule of every 3-4
>> > > months) and when updating the search for compatible entries it should
>> > > take into account these platforms.
>> >
>> > This, of course, is exactly why I *don't* recommend embedded platforms
>> > move to including the device tree in the flashed firmware.  Keeping
>> > the device tree in the bootwrapper means that it *is* updated with the
>> > kernel and we don't have to mess around with as much backwards
>> > compatibility junk.
>>
>> This completely defeats the purpopse of having a separate device tree
>> though, no ? I mean, we could just as well hardcode the device-tree info
>> in the kernel in this case ?
>
> And just what form would "hardcoded" device info take in the kernel?
> The *primary* purpose of the device-tree is to have a consistent
> in-kernel representation of the hardware information.  A device-tree
> was the obvious choice, because OF machines already used it, and it's
> flexible enough to cover pretty much anything.
>
> How the kernel gets a device tree doesn't matter so much - we don't
> really care if it comes from OF, from some other firmware or if it's
> built into the kernel or wrapper.
>
> Being able to pass in the device tree is a secondary advantage in
> *some* circumstances - albeit one people seem to have leapt on with
> unwise enthusiasm, IMO.  This approachd also has drawbacks which can
> override the advantages - specifically that firmware has always been
> buggy as hell more often than not, so there's absolutely no reason to
> expect that firmware will get a device tree right.
>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                | _way_ _around_!
> http://www.ozlabs.org/~dgibson
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



-- 
http://bbrv.blogspot.com/

Re: USB support on mpc5200 broken

[Matt Sealey]

David Gibson wrote:
> 
> This, of course, is exactly why I *don't* recommend embedded platforms
> move to including the device tree in the flashed firmware.  Keeping
> the device tree in the bootwrapper means that it *is* updated with the
> kernel and we don't have to mess around with as much backwards
> compatibility junk.

Pardon my language, but this is such bullshit.

This isn't "including a device tree in flashed firmware", this is
"having a real Open Firmware". We don't embed anything in there, it's
procedurally generated on each boot.

Our whole problem here is that we have a device tree which was fixed
for production before the device tree specification was nailed down
for the MPC5200B, and it's still in flux. We can't be expected to
walk lock-step with a 3 month kernel development cycle and we certainly
do not appreciate sidelining real firmware in favor of static device
trees which need to be compiled *per board*.

All the FDT does is move a lot of extra hardcoded values out of the
kernel and into a just-as-annoying extra file you need to be wary of
keeping up to date since the format and specification changes so much.

We never had this much whining about Apple's device tree, people just
implemented the workarounds..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: USB support on mpc5200 broken

[Grant Likely]

On Wed, Sep 24, 2008 at 6:09 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> USB is not working my hardware, so I booted my Efika and it's not
>> working there either.  This is with linus' current git.
>>
>> Can anyone verify this? Or know what happened to USB?
>> USB is loading but it is not finding anything plugged in.
>> lsusb doesn't show anything.
>>
>> Last time I noticed it was working was about ten days ago. I don't use
>> it everyday.
>
> Efika is broken because of this:
>
> ohci-ppc-of.c...
>        is_bigendian =
>                of_device_is_compatible(dn, "ohci-bigendian") ||
>                of_device_is_compatible(dn, "ohci-be");
>
> Efika doesn't have either of those in it's compatible string.

I finally got my Efika out and booted again.  I do not see this issue.

My efika shows compatible = "ohci-bigendian", "ohci-be",
"mpc5200-ohci", "mpc5200-usb";

I'm running stock firmware without any forth scripts.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: USB support on mpc5200 broken

[Jon Smirl]

On Mon, Nov 3, 2008 at 10:41 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Sep 24, 2008 at 6:09 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>> USB is not working my hardware, so I booted my Efika and it's not
>>> working there either.  This is with linus' current git.
>>>
>>> Can anyone verify this? Or know what happened to USB?
>>> USB is loading but it is not finding anything plugged in.
>>> lsusb doesn't show anything.
>>>
>>> Last time I noticed it was working was about ten days ago. I don't use
>>> it everyday.
>>
>> Efika is broken because of this:
>>
>> ohci-ppc-of.c...
>>        is_bigendian =
>>                of_device_is_compatible(dn, "ohci-bigendian") ||
>>                of_device_is_compatible(dn, "ohci-be");
>>
>> Efika doesn't have either of those in it's compatible string.
>
> I finally got my Efika out and booted again.  I do not see this issue.
>
> My efika shows compatible = "ohci-bigendian", "ohci-be",
> "mpc5200-ohci", "mpc5200-usb";

It's been too long and I've lost track of what happened.

-- 
Jon Smirl
jonsmirl@gmail.com