[PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation

[Ezequiel Garcia]

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