public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH v2] [new uImage] ppc: Re-order ramdisk/fdt handling sequence
Date: Mon, 18 Feb 2008 14:15:53 -0500	[thread overview]
Message-ID: <47B9D969.2080807@ge.com> (raw)
In-Reply-To: <C4B0D67E-6FB5-4ED5-A20C-6434B1186166@kernel.crashing.org>

Kumar Gala wrote:
> 
> On Feb 18, 2008, at 11:51 AM, Jerry Van Baren wrote:
> 
>> Kumar Gala wrote:
>>> Doing the fdt before the ramdisk allows us to grow the fdt w/o concern
>>> however it does mean we have to go in and fixup the initrd info since
>>> we don't know where it will be.
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> Hi Kumar,
>>
>>> ---
>>> Fixed up the error handling.  The old code tried returning an error and
>>> should have called do_reset().
>>> lib_ppc/bootm.c |   40 +++++++++++++++++++++++++++++++++++-----
>>> 1 files changed, 35 insertions(+), 5 deletions(-)
>>> diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
>>> index 5158ccc..09e349e 100644
>>> --- a/lib_ppc/bootm.c
>>> +++ b/lib_ppc/bootm.c
>>> @@ -71,7 +71,7 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag,
>>>     bd_t    *kbd;
>>>     void    (*kernel)(bd_t *, ulong, ulong, ulong, ulong);
>>> -    int    has_of = 0;
>>> +    int    ret, has_of = 0;
>>
>> I would strongly prefer to see "ret" declared on a separate line.  I'm 
>> not a fan of comma declared variables and, when one is initialized and 
>> the other isn't, it makes my brain play tricks on me (thinking ret is 
>> initialized to 0 too, which it isn't).
>>
>>> #if defined(CONFIG_OF_LIBFDT)
>>>     char    *of_flat_tree;
>>> @@ -121,9 +121,6 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag,
>>>     rd_len = rd_data_end - rd_data_start;
>>> -    alloc_current = ramdisk_high (alloc_current, rd_data_start, rd_len,
>>> -            sp_limit, get_sp (), &initrd_start, &initrd_end);
>>> -
>>> #if defined(CONFIG_OF_LIBFDT)
>>>     /* find flattened device tree */
>>>     alloc_current = get_fdt (alloc_current,
>>> @@ -134,7 +131,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag,
>>>      * if the user wants it (the logic is in the subroutines).
>>>      */
>>>     if (of_flat_tree) {
>>> -        if (fdt_chosen(of_flat_tree, initrd_start, initrd_end, 0) < 
>>> 0) {
>>> +        /* pass in dummy initrd info, we'll fix up later */
>>> +        if (fdt_chosen(of_flat_tree, rd_data_start, rd_data_end, 0) 
>>> < 0) {
>>
>> If you pass in 0,0 for rd_data_start, rd_data_end it will not create 
>> the ramdisk entry...
> 
> If rd_data_start, rd_data_end are 0,0 than we don't have a ramdisk, so 
> its ok.

My point is to pass in 0,0 *so that* they are not created at all, rather 
than passing in dummy values, creating entries that we have to 
delete/rewrite later.

>>>             fdt_error ("/chosen node create failed");
>>>             do_reset (cmdtp, flag, argc, argv);
>>>         }
>>> @@ -157,6 +155,38 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag,
>>>     }
>>> #endif    /* CONFIG_OF_LIBFDT */
>>> +    alloc_current = ramdisk_high (alloc_current, rd_data_start, rd_len,
>>> +            sp_limit, get_sp (), &initrd_start, &initrd_end);
>>> +
>>> +#if defined(CONFIG_OF_LIBFDT)
>>> +    /* fixup the initrd now that we know where it should be */
>>> +    if ((of_flat_tree) && (initrd_start && initrd_end)) {
>>> +        uint64_t addr, size;
>>> +        int  total = fdt_num_mem_rsv(of_flat_tree);
>>> +        int  j;
>>> +
>>> +        /* Look for the dummy entry and delete it */
>>> +        for (j = 0; j < total; j++) {
>>> +            fdt_get_mem_rsv(of_flat_tree, j, &addr, &size);
>>> +            if (addr == rd_data_start) {
>>> +                fdt_del_mem_rsv(of_flat_tree, j);
>>> +                break;
>>> +            }
>>> +        }
>>
>> ...and the above loop and delete will then be unnecessary.
> 
> Again, protected by initrd_start/_end being non-zero.

My point is to pass in 0,0 *so that* they are not created at all, rather 
than passing in dummy values, creating entries that we have to 
delete/rewrite later.

>>> +        ret = fdt_add_mem_rsv(of_flat_tree, initrd_start,
>>> +                    initrd_end - initrd_start + 1);
>>> +        if (ret < 0) {
>>> +            printf("fdt_chosen: %s\n", fdt_strerror(ret));
>>> +            do_reset (cmdtp, flag, argc, argv);
>>> +        }
>>> +
>>> +        do_fixup_by_path_u32(of_flat_tree, "/chosen",
>>> +                    "linux,initrd-start", initrd_start, 0);
>>> +        do_fixup_by_path_u32(of_flat_tree, "/chosen",
>>> +                    "linux,initrd-end", initrd_end, 0);
>>> +    }
>>> +#endif
>>>     debug ("## Transferring control to Linux (at address %08lx) ...\n",
>>>         (ulong)kernel);
>>
>> ...and you will have to pass in '1' for the create (last) parameter in 
>> the do_fixup_by_path_u32() calls to create them if they don't exist.
> 
> They should exist by the time we are doing the fixup.
> 
>> Is that better, or just a different way to do the same thing?  It 
>> seems more straight-forward to me.
> 
> Its just re-ordering the way we do things.
> 
> - k

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.

Best regards,
gvb

  reply	other threads:[~2008-02-18 19:15 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 [this message]
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
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=47B9D969.2080807@ge.com \
    --to=gerald.vanbaren@ge.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