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?
Also, for the blob growing changes it would be nice to first merge your LMB patches to sort out the memory allocation. I didn't have a time to review your changes in detail but it's definitely step in the right direction. Current bootm allocation is pretty messy, I cleaned it a bit but didn't want to touch too many pieces at the same time. For the same reason I would like to finish the current patch I am working on that adds dual format framework before we add LMB and dynamic blob growing. m. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
