[U-Boot] [PATCH v2 5/7] Tegra30: Cardhu: Add DT files

[Simon Glass]

Hi Stephen,

On Mon, Dec 3, 2012 at 4:57 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 12/03/2012 05:49 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Dec 3, 2012 at 4:40 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 12/03/2012 04:45 PM, Tom Warren wrote:
>>>> These are stripped down for bringup, They'll be filled out later
>>>> to match-up with the kernel DT contents, and/or as devices are
>>>> brought up (mmc, usb, spi, etc.).
>>>>
>>>> Signed-off-by: Tom Warren <twarren at nvidia.com>
>>>
>>>> diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
>>>
>>>> +/ {
>>>> +     model = "NVIDIA Tegra30";
>>>
>>> We don't really need a model property here, but it's not a big deal.
>>
>> We do actually use it in U-Boot (in ARM patches on the mailing list).
>
> Hmmm. The tegra20.dtsi file doesn't have one...

No problem, then it won't display a model.

>
>>>> diff --git a/board/nvidia/dts/tegra30-cardhu.dts b/board/nvidia/dts/tegra30-cardhu.dts
>>>
>>>> +/memreserve/ 0x1c000000 0x04000000;
>>>
>>> /memreserve/ isn't correct for U-Boot; no memory should be reserved.
>>
>> But don't we want to use the same fdt for U-Boot as the kernel?
>
> The only reason for a memreserve are:
>
> a) To reserve the current display frame-buffer. This is a run-time thing
> that U-Boot should add to the DTB itself, not pre-populated in the DT.
>
> b) To reserve memory for some kind of co-processor. We shouldn't be
> using memreserve for this any more, but rather allocating the memory
> dynamically in the kernel.
>
> So irrespective of the answer to your question we should still remove this.
>
> Re: your question: Perhaps, but we're so far away from that right now,
> it almost doesn't seem worth caring yet. Also, while we should certainly
> use the same bindings, I'm not sure we should use the same actual .dtb
> file bitstream, since the .dtb passed to the kernel should be loaded
> from the filesystem/... where the kernel zImage was, not embedded into
> the bootloader.

I don't really mind, but I hold fond hopes of using the same source
for each at some point. Not an issue for now.

Regards,
Simon