public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marian Balakowicz <m8@semihalf.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH v2] [new uImage] ppc: Re-order	ramdisk/fdt handling sequence
Date: Fri, 22 Feb 2008 16:32:22 +0100	[thread overview]
Message-ID: <47BEEB06.7050405@semihalf.com> (raw)
In-Reply-To: <8B11A571-3BC2-42BD-9B66-DF22A736A3A7@kernel.crashing.org>

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?

Cheers,
m.

  parent reply	other threads:[~2008-02-22 15:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-18 17:27 [U-Boot-Users] [PATCH v2] [new uImage] ppc: Re-order ramdisk/fdt handling sequence Kumar Gala
2008-02-18 17:51 ` Jerry Van Baren
2008-02-18 18:52   ` Kumar Gala
2008-02-18 19:15     ` Jerry Van Baren
2008-02-18 19:39       ` Kumar Gala
2008-02-18 19:46         ` Jerry Van Baren
2008-02-18 20:13           ` Kumar Gala
2008-02-22 11:43             ` Wolfgang Denk
2008-02-22 13:27               ` Jerry Van Baren
2008-02-22 14:36                 ` Bartlomiej Sieka
2008-02-26  5:48                   ` Kumar Gala
2008-02-22 15:32             ` Marian Balakowicz [this message]
2008-02-22 15:53               ` Marian Balakowicz
2008-02-22 16:07               ` Jerry Van Baren
2008-02-22 17:08                 ` Marian Balakowicz
2008-02-26  5:52                   ` Kumar Gala
2008-02-26  9:11                     ` Marian Balakowicz
2008-02-26 14:31                       ` Kumar Gala
2008-02-27 11:20                         ` Marian Balakowicz
2008-02-27 14:58                           ` Kumar Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47BEEB06.7050405@semihalf.com \
    --to=m8@semihalf.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox