From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Date: Mon, 21 May 2007 12:02:49 -0500 Subject: [U-Boot-Users] Ideas on U-Boot configuration with FDT In-Reply-To: <4651CF98.30107@grandegger.com> References: <20070520093335.9FF32353428@atlas.denx.de> <4650477F.3040007@grandegger.com> <4651B871.2070904@freescale.com> <4651CF98.30107@grandegger.com> Message-ID: <4651D0B9.9080000@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Grandegger wrote: > Timur Tabi wrote: >> Wolfgang Grandegger wrote: >> >>> Then something similar to the ENV could be chosen: >>> >>> CFG_FDT_ADDR >>> CFG_FDT_IS_IN_FLASH >>> CFG_FDT_IS_IN_xxx >> >> We need two addresses: >> >> 1) The address where the FDT is stored when the system is powered up > > OK. > >> 2) The address in RAM where the FDT should be placed before Linux is >> booted. > > This should be some kind of default address. Any default address is most likely board-specific. It would be nice if U-Boot could determine the best address automatically when possible. > Also be aware, that the > blob can be within a uImage created with mkimage. Then the load address > defined in the uImage should be used. Yes. > You might be right. The _IS_IN_ is used for the ENV, I have to check > what the rational behind it is (if there is one at all). It's handy if you want to use the same macro to represent different types of addresses. Personally, I don't see much value in that. I would rather that a particular macro be used to represent only one kind of value. When I see CFG_FDT_ADDR_RAM, I know that the value is a virtual address that the CPU can dereference at any time. > I'm not sure if you understand the intended purpose. The address of the > _initial_ blob could be stored in the env variable "fdtaddr" to select > _one_ blob out of many in the FLASH. Hmm.... I can see value in that, but then that variable can contain completely different addresses depending on the type of storage, which I don't like. Plus, I would rather that we use macro commands to set the FDT address, rather than an environment variable. This gives us more flexibility. > I tend to leave it up to the board specific code where and how to verify > the FDT. fdt_checkboard() *is* board-specific code. There are already various entry points like checkboard() or > misc_init_r(). But this functions don't normally know where the FDT is. fdt_checkboard() would be designed specifically to validate an FDT from a board-specific point-of-view. It's good to have that code isolated from other board-specific code. -- Timur Tabi Linux Kernel Developer @ Freescale