..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 <[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