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
next prev parent 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 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.