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
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
