public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [POWERPC][BUG] ramdisk: u-boot no longer boots a ramdisk with Linux 2.6.27-rc4
Date: Fri, 05 Sep 2008 16:42:55 +0200	[thread overview]
Message-ID: <48C1456F.6080305@denx.de> (raw)
In-Reply-To: <DD50706F-F7B9-405E-AF38-7813A76D2DC3@kernel.crashing.org>

Hello Kumar,

Kumar Gala wrote:
> On Sep 5, 2008, at 3:27 AM, Heiko Schocher wrote:
>> I actually trying to boot a Linux 2.6.27-rc4 Kernel with a Ramdisk
>> and actual u-boot on a MPC82xx based board. And what should I say,
>> it doesnt work anymore :-(
>>
>> Reason is the following commit:
>>
>> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=2a1a2cb6e2b87ee550e6f27b647d23331dfd5e1b#patch3
>>
>>
>> After this commit, u-boot no longer deletes the mem reservation
>> for the initrd in Flash, what stops Linux from booting.
>>
>> So I did the following, but maybe there is a better way for it?
> 
> I don't follow.. can you provide a bit more info about what's going on
> w/your mem reserves and what locations the ramdisk is at.

OK, I try it ...

We start in lib_ppc/bootm.c (actual u-boot):

 147         if (of_size) {
 148                 /* pass in dummy initrd info, we'll fix up later */
 149                 if (fdt_chosen(of_flat_tree, images->rd_start, images->rd_end, 0) < 0) {

This calls fdt_chosen with images->rd_start which are on my Hardware
in Flash at 0xff21000

fdt_chosen calls

fdt_initrd(of_flat_tree, initrd_start, initrd_end, force);

with initrd = images->rd_start = 0xff210000

fdt initr ():
 125         /*
 126          * Look for an existing entry and update it.  If we don't find
 127          * the entry, we will j be the next available slot.
 128          */
 129         for (j = 0; j < total; j++) {
 130                 err = fdt_get_mem_rsv(fdt, j, &addr, &size);
 131                 if (addr == initrd_start) {
 132                         fdt_del_mem_rsv(fdt, j);
 133                         break;
 134                 }
 135         }

didnt find this addres -> didnt call fdt_del_mem_rsv() This is OK here,
because its the first call ...

fdt_initrd calls fdt_add_mem_rsv with this value
-> One dummy mem reserv for the 0xff210000 value

Ok lets go on, later in lib_ppc/bootm.c:

Here is called fdt_initrd again, now with the values from the initrd
somewhere in RAM (which are the right ones) ...

 181 #if defined(CONFIG_OF_LIBFDT)
 182         /* fixup the initrd now that we know where it should be */
 183         if ((of_flat_tree) && (initrd_start && initrd_end))
 184                 fdt_initrd(of_flat_tree, initrd_start, initrd_end, 1);
 185 #endif

in fdt initr ():

 125         /*
 126          * Look for an existing entry and update it.  If we don't find
 127          * the entry, we will j be the next available slot.
 128          */
 129         for (j = 0; j < total; j++) {
 130                 err = fdt_get_mem_rsv(fdt, j, &addr, &size);
 131                 if (addr == initrd_start) {
 132                         fdt_del_mem_rsv(fdt, j);
 133                         break;
 134                 }
 135         }

didnt find this addresses in RAM -> didnt call fdt_del_mem_rsv()
for the dummy reservation (on my Hardware 0xff210000)...

This is NOT OK here!

> The code should have been identical to before.

Hmm... seems not so to me ...
... taking a look at your Patch:

Here your Patch for lib_ppc_bootm.c:

 #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 == images->rd_start) {
-                               fdt_del_mem_rsv(of_flat_tree, j);

This looks for me that the old code explicitly searches for the
dummy entry with images->rd_start!!

-                               break;
-                       }
-               }
-
-               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));
-                       goto error;
-               }
-
-               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);
-       }
+       if ((of_flat_tree) && (initrd_start && initrd_end))
+               fdt_initrd(of_flat_tree, initrd_start, initrd_end, 1);
                                         ^^^^^^^^^^^^
                                         At this place (see explanation before)
                                         initrd_start has the value for the
                                         initrd in RAM! -> the search for this
                                         new address in fdt_initrd () is useless,
                                         even dangerous, if the initrd is not moved,
                                         to RAM this search is succesful and for this
                                         case the right mem reservation gets deleted ...
 #endif


Nevertheless, the actual Code works with my patch fine, so
again the question, why we need this dummy call in fdt_chosen for
the initrd, when we call it later with the right values.

I think we can drop this useless dummy call from fdt_chosen.
Has somebody any suggestions?

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

  reply	other threads:[~2008-09-05 14:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-05  8:27 [U-Boot] [POWERPC][BUG] ramdisk: u-boot no longer boots a ramdisk with Linux 2.6.27-rc4 Heiko Schocher
2008-09-05 13:56 ` Kumar Gala
2008-09-05 14:42   ` Heiko Schocher [this message]
2008-09-05 16:13     ` Kumar Gala
2008-09-05 16:36       ` Heiko Schocher
2008-09-05 18:02         ` 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=48C1456F.6080305@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox