All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH][for 1.3.5] Fix handling of mem reserves for ramdisk
Date: Tue, 09 Sep 2008 08:18:41 +0200	[thread overview]
Message-ID: <48C61541.7060902@denx.de> (raw)
In-Reply-To: <6E892604-9B2A-4338-8DF7-C58688FC5A94@kernel.crashing.org>

Hello Kumar,

Kumar Gala wrote:
[...]
>> Please have a look at the following patch, it deletes the steps a) - c)
>> and fixes the fdt chosen command ...
[...]
>> diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
>> index 0593bad..288a5c4 100644
>> --- a/common/cmd_fdt.c
>> +++ b/common/cmd_fdt.c
>> @@ -450,7 +450,8 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc,
>> char *argv[])
>>             initrd_end = simple_strtoul(argv[3], NULL, 16);
>>         }
>>
>> -        fdt_chosen(working_fdt, initrd_start, initrd_end, 1);
>> +        fdt_chosen(working_fdt, 1);
>> +        fdt_initrd(working_fdt, initrd_start, initrd_end, 1);
> 
> You are removing functionality, if you want to do this add a command
> 'fdt initrd' that sets the initrd props and the mem reserve information.

Hmm... really? Your patch

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=2a1a2cb6e2b87ee550e6f27b647d23331dfd5e1b#patch3

moved functionality from fdt_chosen in the fdt_initrd function and
called fdt_initrd() in fdt_chosen ().

My patch removes now this fdt_initrd() call from fdt_chosen(), and
so I call it here to fix the fdt_chosen command ... maybe I miss
something?

>>     }
>>     /* resize the fdt */
>>     else if (strncmp(argv[1], "re", 2) == 0) {
>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>> index a7773ab..8ceeb0f 100644
>> --- a/common/fdt_support.c
>> +++ b/common/fdt_support.c
>> @@ -165,7 +165,7 @@ int fdt_initrd(void *fdt, ulong initrd_start,
>> ulong initrd_end, int force)
>>     return 0;
>> }
>>
>> -int fdt_chosen(void *fdt, ulong initrd_start, ulong initrd_end, int
>> force)
>> +int fdt_chosen(void *fdt, int force)
>> {
>>     int   nodeoffset;
>>     int   err;
>> @@ -215,8 +215,6 @@ int fdt_chosen(void *fdt, ulong initrd_start,
>> ulong initrd_end, int force)
>>         }
>>     }
>>
>> -    fdt_initrd(fdt, initrd_start, initrd_end, force);
>> -
>> #ifdef CONFIG_OF_STDOUT_VIA_ALIAS
[...]
> The reason we had the code before was to try and make sure the size of
> the fdt was as close to its final size as possible before we dealt with
> the ramdisk relocation (boot_ramdisk_high()) that included the
> properties and the memreserve in the fdt.  Step's a)-c) are there to
> make sure the size is correct.

Hmmm... and thats the reason why we risk to forgot a memreservation?
(Keep in mind, I think actually it is not possible to boot Linux
with actual u-boot from a Ramdisk in Flash on a powerpc!)

Is this really so essential to know the final fdt size?

While writing this, and if the final fdt size is so important,
I wanted to propose a fix Ramdisk address we can later find and
delete, but then I saw your patch

http://lists.denx.de/pipermail/u-boot/2008-September/040054.html

does this principally! So this patch is okay for me.

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  parent reply	other threads:[~2008-09-09  6:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-06  5:57 [U-Boot] [PATCH][for 1.3.5] Fix handling of mem reserves for ramdisk Heiko Schocher
2008-09-08 14:02 ` Kumar Gala
2008-09-08 14:10   ` Wolfgang Denk
2008-09-08 15:57     ` Kumar Gala
2008-09-10  8:19       ` Heiko Schocher
2008-09-10  9:03         ` Wolfgang Denk
2008-09-09  6:18   ` Heiko Schocher [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-09-05 16:13 Kumar Gala
2008-09-06 23:22 ` Wolfgang Denk

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=48C61541.7060902@denx.de \
    --to=hs@denx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.