Dear Timur Tabi, In message <4bf29fe9.1070...@freescale.com> you wrote: > 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.
Such an "ensure that there is enough room" is exactly what I'm asking for. > 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. Hm... it seems that not a single board uses this setting, which also happens to be completely undocumented. > 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. For me lmb_alloc_base() is just another form of malloc()... > 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'm not sure if we have the same intentions here. I think, that for case #1 the available size is known, so we can check if we exceed the limits. And this is what we should do then. > 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. If we are talking about such substantial increments then it is all the more important to check for available room. > 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. No. We should check if the programmed value is sufficient. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If in any problem you find yourself doing an immense amount of work, the answer can be obtained by simple inspection. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
