From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Date: Mon, 21 May 2007 18:58:00 +0200 Subject: [U-Boot-Users] Ideas on U-Boot configuration with FDT In-Reply-To: <4651B871.2070904@freescale.com> References: <20070520093335.9FF32353428@atlas.denx.de> <4650477F.3040007@grandegger.com> <4651B871.2070904@freescale.com> Message-ID: <4651CF98.30107@grandegger.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. 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. > Therefore, we can't have just CFG_FDT_ADDR. We need CFG_FDT_ADDR_xxxx > > My vote is to have xxxx be the type of memory. So if CFG_FDT_ADDR_FLASH > is defined to value X, that means that the FDT is stored in flash at > address X. If CFG_FDT_ADDR_EEPROM is defined instead, then it means > that FDT is located in EEPROM at address X. > > This would eliminate the "CFG_FDT_IS_IN_xxx"-type macros, which I think > are redundant. 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). > >>>> 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 > > I would rather that the FDT subsystem *set* the fdtaddr variable, > instead of the other way around. 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. >>>> 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 we're going to have to always relocate the FDT to RAM. > Considering the level of functionality that libfdt provides, and > considering how much of that functionality depends on being able to > write to the FDT, it makes sense to require it to be in RAM. Good, and for booting the FDT must be in RAM anyhow. >>> "checkboard()" is a name that can mean anything. If the function is > > The purpose of the function is to provide board-specific code that > validates the FDT. The amount of checking performed is at the > discretion of the function. > > For example, checkboard() *should* compare the values in the board > header file with the FDT to verify that the memory mappings map, for > instance. I tend to leave it up to the board specific code where and how to verify the FDT. There are already various entry points like checkboard() or misc_init_r(). Wolfgang.