On Fri, Aug 17, 2012 at 05:29:27PM +0100, Peter Maydell wrote:
> On 17 August 2012 17:12, Dave Martin <dave.martin@xxxxxxxxxx> wrote:
> > On Fri, Aug 17, 2012 at 05:00:46PM +0100, Peter Maydell wrote:
> >> On 17 August 2012 16:45, Dave Martin <dave.martin@xxxxxxxxxx> wrote:
> >> >> @@ -186,7 +202,10 @@ no_add_memory:
> >> >>
> >> >> if(info->initrd_start) {
> >> >> uint32_t initrd_end = info->initrd_start + info->initrd_size;
> >> >> -
> >> >> + /* It's not documented whether these cells should honour
> >> >> + * #address-cells. Currently the kernel accepts them as being
> >> >> + * addresses of either size, so we leave them as 32 bits for now.
> >> >> + */
> >> >
> >> > Interesting... OK.
> >>
> >> I have a query in with Grant to get him to make a decision here
> >> and write some documentation...
> >
> > OK. It feels like they certainly should follow #address-cells. For
> > non-AArch64 platforms, we're dependent on at least enough low physical
> > RAM (or a low alias) to load the kernel -- in practice that means the
> > initrd should fit in it too. I guess we should just leave this patch
> > as-is for now.
> >
> > Ultimately, for AArch64 it can make sense for there to be no RAM in the
> > bottom 4GB of physical address space, so I would be worried if the DT
> > bindings don't cope with this.
>
> You can also feed in a 64 bit address here and the kernel will cope
> fine: it simply looks at the size of the property itself, ignoring
> #address-cells. So the kernel will cope fine with any of the following
> DTB generator strategies:
> * assume these properties follow #address-cells
> * always 32 bit (and implicitly require the initrd to be in low memory)
> * always 64 bit
Sure
---Dave
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
