Re: USB support on mpc5200 broken
On Wed, Sep 24, 2008 at 6:09 PM, Jon Smirl [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Nov 3, 2008 at 10:41 AM, Grant Likely [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 6:09 PM, Jon Smirl [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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
RE: USB support on mpc5200 broken
Hi Ben, 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. 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. 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). Also agree. There might be use-cases, where hardware-supported endian-swapping might be useful. But it must be an optional feature. 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. 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. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: USB support on mpc5200 broken
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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 [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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 [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Sun, Sep 28, 2008 at 11:43 PM, David Gibson
[EMAIL PROTECTED] 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?
[EMAIL PROTECTED] {
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
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
Jon == Jon Smirl [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 10:22 AM, Peter Korsgaard [EMAIL PROTECTED] wrote: Jon == Jon Smirl [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
Jon == Jon Smirl [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
Sven == Sven Luther [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 4:18 PM, Scott Wood [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 05:04:22PM -0400, Jon Smirl wrote: On Mon, Sep 29, 2008 at 4:18 PM, Scott Wood [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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
Re: USB support on mpc5200 broken
..wasn't the real issue for the device tree to get the firmware right? RB On Mon, Sep 29, 2008 at 8:12 PM, David Gibson [EMAIL PROTECTED] 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/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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 [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB support on mpc5200 broken
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(192382.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 .6PHY: 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 13/3 on 192.168.1.4 Looking up port of RPC 15/3 on 192.168.1.4 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
