Jon Smirl wrote: > On 11/8/07, Scott Wood <[EMAIL PROTECTED]> wrote: > >> I think you may be placing too much faith in the vendors. >> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-) > > There has to be more to the part number for the Freescale powerpc chip > than just 7400. 7400 is a shorthand name, it is not an orderable part number.
The orderable part numbers add 3 or 4 characters to the front and about 8 after. There is a difference between MPC7400 and PPC7400, and the low voltage versions, and the different clock speeds. Orderable part number for a recent G4 might be PPC7448B1333NL - this is a ridiculous amount of specificity in a device tree, and it also does not match the datasheet (MPC7448 is the name of the chip). What people usually do is use what's in the datasheet. >> If you want to argue that the "MPC" part differentiates them, that's >> just a less readable and more obsolete vendor prefix. > > The MPC is what is printed on the chip. fsl is not printed there. MPC > is part of the orderable part number. Not all of them *ahem* :) Like I said, trust the datasheet, not the number on the chip. >> Vendor prefixes on properties are useful in that it might not mean >> exactly the same thing as a similar property that gets standardized >> later on. >> >>> That's life in the Linux world, no backwards binary compatibility. >> There's a huge difference between compatibility of kernel interfaces and >> compatibility of interfaces between the kernel and something else -- >> whether it be userspace or firmware. Indeed, so.. at some point we should all sit down and hammer out the major issues in describing something like the MPC5121E because right now Genesi has a vested interest in that. Thanks Grant for your discussion on it, I agree of course :) One thing we don't want to go through again is the complaints we got because we named the chip node "/builtin" rather than "/soc". My fixup script is still handling that mess because you guys refused to accept it (and some drivers were coded to map from the MBAR contained in device_type soc's reg property rather than find a real device). If we could all agree on how it should be mapped out, with an example tree which shows *every damn thing available* so platform developers can pick and choose and OF developers can use it as a reference, it would make a much happier process. And then we can fix up the Efika to fit some definition of the new MPC5200 tree too. By the way while I was poking around the tree today I noticed that there is a PCI errata fixup handled by a Kconfig in there. Why? Surely this is something you check the PVR/SVR for and switch on that for a runtime solution, and not trick users with the possibility of forgetting to enable some obscure "PCI errata fix" configuration item? (CONFIG_PPC_MPC5200_BUGFIX) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded