[U-Boot-Users] Re: RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
Benjamin Herrenschmidt
benh at kernel.crashing.org
Thu May 19 10:09:58 CEST 2005
On Thu, 2005-05-19 at 09:46 +0200, Arnd Bergmann wrote:
> On Dunnersdag 19 Mai 2005 06:56, Benjamin Herrenschmidt wrote:
>
> > d) the /memory node(s)
> > Required properties:
> >
> > - name : has to be "chosen"
>
> s/chosen/memory/
Thanks, will fix.
> > c) The /chosen node
> >
> > - linux,platform : This is your platform number as assigned by the
> > architecture maintainers
>
> Does this mean you want a new platform number for every board type?
> I would guess that it might be easier to extend the maple platform
> to support all boards with ppc970 and similar CPUs (except the
> pmac and pSeries ones), just like I would like to extend the BPA
> platform for all Cell based systems.
I'd rather have a different number per board family. Embedded vendors
are likely to hard code all sort of things and deal with all sort of
funky bits of hardware in their xxx_setup.c code among others, I'd
rather have them have a separate platform. Though it is better if they
could keep "similar" boards under the same platform number and use the
device-tree to differenciate them.
> > This is all that is currently required. However, it is strongly
> > recommended that you expose PCI host bridges as documented in the
> > PCI binding to open firmware, and your interrupt tree as documented
> > in OF interrupt tree specification.
>
> AFAICS, the pci device tree is currently required if you want to
> use an IOMMU or if you want PCI-X or PCIe style devices with
> extended PCI config space. I wouldn't be surprised if other
> functionality also depends on it.
No, you can use the iommu without the PCI device tree. I've verified
that it works on maple by disabling generation of the PCI device tree in
PIBS. Extended config space should be fixed too, though it's not an
issue with existing bridges yet.
Ben.
More information about the U-Boot
mailing list