From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] ppc4xx: Don't use last 256 bytes of SDRAM, workaround for 440EPx CHIP 11 errata
Date: Thu, 20 Mar 2008 14:57:37 +0100 [thread overview]
Message-ID: <200803201457.38177.sr@denx.de> (raw)
In-Reply-To: <20080320111638.1EA51241A2@gemini.denx.de>
On Thursday 20 March 2008, Wolfgang Denk wrote:
> At the cost of an #ifdef, this could be added to the memory
> reservation code in "lib_ppc/board.c", i. e. somewhere after
>
> ...
> 427 * Reserve memory at end of RAM for (top down in that order):
> 428 * - kernel log buffer
> 429 * - protected RAM
> 430 * - LCD framebuffer
> 431 * - monitor code
> 432 * - board info struct
> 433 */
> 434 len = (ulong)&_end - CFG_MONITOR_BASE;
> 435
> 436 addr = CFG_SDRAM_BASE + get_effective_memsize();
OK. I'll add it here with an additional #ifdef here. How about something like
this:
len = (ulong)&_end - CFG_MONITOR_BASE;
+#ifdef CONFIG_MEM_TOP_HIDE
+ /*
+ * Subtract specified amount of memory to hide so that it won't
+ * get "touched" at all by U-Boot. By fixing up gd->ram_size
+ * the Linux kernel should now get passed the now "corrected"
+ * memory size and won't touch it either. This should work
+ * for arch/ppc and arch/powerpc. Only Linux board ports in
+ * arch/powerpc with bootwrapper support, that recalculate the
+ * memory size from the SDRAM controller setup will have to
+ * get fixed.
+ */
+ gd->ram_size -= CONFIG_MEM_TOP_HIDE;
+#endif
addr = CFG_SDRAM_BASE + get_effective_memsize();
Or even better this somewhere above:
#ifndef CONFIG_MEM_TOP_HIDE
#define CONFIG_MEM_TOP_HIDE 0
#endif
and we can drop the #ifdef completely.
> Of course you need to make sure that the linux kernel understands
> this changed behaviour / shifted addresses, too.
Right. By fixing up gd->ram_size in the new patch version above, this should
get handled for arch/ppc and arch/powerpc kernel versions. So no need
for 'mem=xxx' in the bootargs anymore. Or did I miss something here?
Thanks.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
next prev parent reply other threads:[~2008-03-20 13:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-20 9:46 [U-Boot-Users] [PATCH] ppc4xx: Don't use last 256 bytes of SDRAM, workaround for 440EPx CHIP 11 errata Stefan Roese
2008-03-20 10:03 ` Wolfgang Denk
2008-03-20 10:29 ` Stefan Roese
2008-03-20 11:16 ` Wolfgang Denk
2008-03-20 12:55 ` Kumar Gala
2008-03-20 13:57 ` Stefan Roese [this message]
2008-03-20 11:50 ` Dave Littell
2008-03-20 14:11 ` Stefan Roese
2008-03-20 16:06 ` Larry Johnson
2008-03-20 21:12 ` Stefan Roese
2008-03-27 2:50 ` Larry Johnson
2008-03-27 6:21 ` Stefan Roese
2008-03-27 18:36 ` Larry Johnson
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=200803201457.38177.sr@denx.de \
--to=sr@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