[PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation
Ezequiel Garcia
ezequiel.garcia at free-electrons.com
Thu Jun 20 03:58:24 EST 2013
On Wed, Jun 19, 2013 at 10:58:34AM -0600, Jason Gunthorpe wrote:
> On Wed, Jun 19, 2013 at 07:02:00AM -0300, Ezequiel Garcia wrote:
>
> > > Verifying the DT is setup this way and aborting if it is not seems
> > > like a good idea..
> >
> > I agree it's a nice idea, but I'm not too sure how to accomplish this
> > in a simple and generic way. There's nothing in the DT that allows you
> > to know which of the ranges entries correspond to the BootROM, unless you go
> > through each of the entries comparing against the known target ID and
> > attribute.
>
> I think you need to have a defined compatible string for the bootrom,
> use one of the of_find.. functions to locate the node, then translate
> the regs to get a CPU address, ensure it is the right base and size..
>
I wasn't sure you wanted to panic(), to clip on available CPUs,
or to just do a pr_warn / WARN(), so here's a piece of code:
(disclaimer: non-tested, non-compiled, etc.)
/*
* In order to boot the secondary CPUs we need to ensure
* the bootROM is mapped at the correct address.
*/
node = of_find_compatible_node(NULL, NULL, "bootrom");
if (!node) {
pr_warn("No 'bootrom' node found");
return;
}
err = of_address_to_resource(node, 0, &res);
if (err < 0) {
pr_warn("Cannot get 'bootrom' node address");
return;
}
if (res.start != AXP_BOOTROM_BASE||
resource_size(&res) != AXP_BOOTROM_SIZE) {
pr_warn("bootrom address is incorrect");
return;
}
How does it look?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
More information about the devicetree-discuss
mailing list