From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Date: Tue, 18 May 2010 09:10:49 -0500 Subject: [U-Boot] libfdt: make fdt_increase_size() available to everyone In-Reply-To: <20100517203355.2B215E6D663@gemini.denx.de> References: <1273526815-1091-1-git-send-email-timur@freescale.com> <1273975868.3244.9.camel@xps> <20100517131650.1060EE6D663@gemini.denx.de> <4BF14FBF.3040900@freescale.com> <20100517203355.2B215E6D663@gemini.denx.de> Message-ID: <4BF29FE9.1070305@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 Denk wrote: > Assume the case that the DTB is stored in NOR flash, and I pass the > NOR flash address to the bootm command... > > I'm not sure if there is any guarantee for free room behind the DTB in > this case. We can never guarantee this. The code that calls fdt_increase_size() will just have to ensure that there is enough room. If the fdt is in NOR flash, then boot_relocate_fdt() will copy it to RAM via lmb_alloc_base(), which uses CONFIG_SYS_FDT_PAD to determine how much extra room is needed. So it appear to me that there are two ways the fdt is "allocated" in memory: 1) It is copied to a location allocated via lmb_alloc_base() by boot_relocate_fdt(). 2) It is simply placed somewhere in memory (via tftp) and left there. I don't believe we ever use malloc() to allocate the memory for the fdt, so these two should cover 100% of all cases. So for case #1, we can use CONFIG_SYS_FDT_PAD. For case #2, we just have to assume that when the user did "tftp c0000 my.dtb", that he knows what he's doing. I assume that fdt_increase_size() will only be used to increase the available space by a significant amount. One example of this (and the reason I posted this patch in the first place), is to embed firmware inside the device tree. A new binding for Freescale QE firmware allows for this, and I have code in-house which implements this. So I say that a particular board will know whether it needs to significantly expand the available amount of RAM beyond the default CONFIG_SYS_FDT_PAD. Therefore, we can define a new value of CONFIG_SYS_FDT_PAD in the board header files for those boards that need it. I believe that this should cover everything, and that my patch is okay and should be merged in. -- Timur Tabi Linux kernel developer at Freescale