From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Date: Mon, 21 May 2007 19:08:19 +0200 Subject: [U-Boot-Users] Ideas on U-Boot configuration with FDT In-Reply-To: <4651B976.2030700@freescale.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> <4651B976.2030700@freescale.com> Message-ID: <4651D203.10004@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: >> 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? Yes, then the address is set to CFG_FDT_ADDR_XXX at compile time. >> 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. As a result of discussion, in the meantime I have now also a better idea on how to implement FDT for U-Boot configuration. Going to make a demo for my Icecube board a.s.a.p. Wolfgang.