From mboxrd@z Thu Jan  1 00:00:00 1970
From: Timur Tabi <timur@freescale.com>
Date: Mon, 21 May 2007 10:23:34 -0500
Subject: [U-Boot-Users] Ideas on U-Boot configuration with FDT
In-Reply-To: <46500875.6060706@grandegger.com>
References: <464D6D4A.4000200@grandegger.com> <464DB7C1.4050509@freescale.com>
	<464DC663.90707@smiths-aerospace.com>
	<464DC7D8.2050703@freescale.com>
	<464DCEAE.3030201@smiths-aerospace.com>
	<464DD073.1030709@freescale.com>
	<464DD48F.8070808@smiths-aerospace.com>
	<46500875.6060706@grandegger.com>
Message-ID: <4651B976.2030700@freescale.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Wolfgang Grandegger wrote:
> Jerry Van Baren wrote:
>> Timur Tabi wrote:
>>> Jerry Van Baren wrote:
>>>
>>>> Yes, that is what "fdt addr" does today, it tells the u-boot innards 
>>>> where the blob is (sets/changes the blob location).  The user can 
>>>> download a new blob and switch to using it via the "fdt addr" command.
>>>
>>> By "change", I thought you meant that "fdt addr" would actually move 
>>> the device tree, since that's technically changing the address.  
>>> Perhaps you meant "set the address"?
>>
>> Yes.
>>
>>>> The user can use the "fdt addr" command to set/change the location 
>>>> of the blob.  Moving blobs is not out of scope, it is what "fdt 
>>>> move" does. 
>>>
>>> How is "fdt move" different than cp.b followed by another "fdt addr"?
>>
>> Conceptually the same thing but easier: you don't have to know (guess) 
>> the blob size because fdt_open_into() gets the size from the source blob.
> 
> Summing up, brainstorming a bit more, here are my revised ideas:
> 
> The following definitions control the FDT usage in U-Boot:
> 
> CFG_FDT_ADDR_FLASH:
>     If defined, "fdt" is set to that address at compile time. The
>         FDT can be used from the early beginning of the boot.
> 
> CFG_FDT_ADDR_BY_ENV:
>     If defined, the env variable "fdtaddr" is looked up early in the
>         boot and "fdt" is set accordingly. This allows to hold more than
>         one blob in FLASH and select one via env setting. This would
>         allow for _one_ combination of images of U-Boot + Linux + Blobs
>         for a _set_ of boards.

If CFG_FDT_ADDR_BY_ENV is *not* defined, should the FDT code then set that variable?

> CFG_FDT_ADDR_RAM:
>     If defined, the blob is moved to RAM after relocation for
>         further preparation or for performance reasons. "fdt" is re-set
>         accordingly. The blob is then ready and in place for booting
>         Linux. If CFG_FDT_ADDR_RAM is set to 0, the blob will be copied
>     to a default location, e.g. before the initrd location.

I think the FDT blob should *always* be copied to RAM.

> 
> A board-specific checkboad function is called as early as possible to 
> verify the FDT.
> 
> This should also make Timur happy, as he has the choice, e.g. read the 
> FDT solely from FLASH. 

I think I may have changed my mind a bit.  I'm not so much concerned about read-only FDT 
as I want to automate the process of copying it to RAM.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale