From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marian Balakowicz Date: Fri, 22 Feb 2008 18:08:36 +0100 Subject: [U-Boot-Users] [PATCH v2] [new uImage] ppc: Re-order ramdisk/fdt handling sequence In-Reply-To: <47BEF33A.40506@ge.com> References: <47B9C5BD.6030409@ge.com> <47B9D969.2080807@ge.com> <47B9E092.608@ge.com> <8B11A571-3BC2-42BD-9B66-DF22A736A3A7@kernel.crashing.org> <47BEEB06.7050405@semihalf.com> <47BEF33A.40506@ge.com> Message-ID: <47BF0194.8080501@semihalf.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Jerry Van Baren wrote: > Marian Balakowicz wrote: >> Kumar Gala wrote: >>> On Feb 18, 2008, at 1:46 PM, Jerry Van Baren wrote: >>> >>>> Kumar Gala wrote: >>>>> On Feb 18, 2008, at 1:15 PM, Jerry Van Baren wrote: >>>>>> Kumar Gala wrote: >>>>>>> On Feb 18, 2008, at 11:51 AM, Jerry Van Baren wrote: >>>>>>>> Kumar Gala wrote: >>>> [[[[snip]]]] >>>> >>>>>> The patch is creating dummy initrd entries in the reserved map >>>>>> and in /chosen, only to work hard to delete and re-create the >>>>>> reserved map entries and rewrite the /chosen entries. >>>>>> >>>>>> My counter-proposal is to not bother with dummy values. Simply >>>>>> pass in 0,0 which will prevent the creation of the initrd entries >>>>>> by fdt_chosen(). By not creating dummy entries, you can simply >>>>>> create the proper entries once you know what the the correct >>>>>> values are, rather than the more complicated rsvmap search & >>>>>> delete + rsvmap creation + /chosen modifications. >>>>> Ahh, the reason I wanted them created was to ensure we have enough >>>>> size for them up front rather than figuring that out later. By >>>>> creating them and replacing them I will not being changing the >>>>> size at all. >>>>> - k >>>> OK, I see. >>>> >>>> Currently this isn't an issue because our blob has a fixed size >>>> that has free space inside it, so creating the rsvmap and /chosen >>>> entries eat at the internal free space and don't change the total >>>> blob size. >>>> >>>> People are advocating dynamically increasing the blob size, which >>>> simplifies things for blob generation (don't have to guess how big >>>> to make the blob when running the dtc to create it), but that would >>>> cause problems with my counter-proposal. >>> And the whole point of my patch was to enable the ability to >>> dynamically grow the blob before we do anything w/the ramdisk. >> >> But we don't really grow the blob, we are just allocating the space for >> the initrd properties - *if* the blob already has enough free space. If >> the blob does not have enough free space we'll hit the bottom anyway, >> whether in fdt_chosen() or ft_board_setup(), so it seem that it doesn't >> matter whether we pre-allocate space for initrd or not. Or am I missing >> something? >> >> I was rather thinking of increasing the total blob size when relocating >> it. Currently relocation happens only when the blob is not within >> BOOTMAPSZ region, so we would need to always relocate the blob and >> figure out the size delta: (1) get it from env variable, if set (2) or >> use some default delta. What do you think? >> > The missing part is libfdt doesn't exactly support dynamic resizing and > our current code doesn't do in-place resizing (which it could do by > doing a move to the same location, but with a larger/smaller length). > > Kumar is lining up the pieces to get there, but we aren't there yet... I see, but how about resizing to a new location: - err = fdt_open_into (fdt_blob, (void *)of_start, of_len); + err = fdt_open_into (fdt_blob, (void *)of_start, of_len + delta); Should that work? If we add LMB and rework bootm memory allocation, putting things (kernel, cmdline, kdb, initrd (optionally), fdt) in sequence starting from bootm_low then we may want to always relocate fdt to avoid overlapping. And, in case of new uImage FDT blob will be embedded in a new uImage shell which is a blob itself. So, in this case in-place resizing is not really a clean option, we would need to resize the embedding new uImage blob first, and this one may have significant size, so I suspect it may impact performance. m.