From: Wolfgang Wegner <wolfgang@leila.ping.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces >32 bit
Date: Thu, 27 May 2010 20:59:09 +0200 [thread overview]
Message-ID: <20100527185909.GG31271@leila.ping.de> (raw)
In-Reply-To: <1274983869-9173-1-git-send-email-wd@denx.de>
Dear Wolfgang Denk,
as the systems I was working on always had far less memory, I can
not comment much on the extension you propose here, but as Timur
Tabi's comments seem to go in a direction which could lead to a
bigger overhaul/discussion, I would like to add 2C from my point
of view on coldfire...
- MCF53xx/MCF5445x both simply lock up if non-existent memory is
accessed. So if the SDRAM controller is set up for a too big size
of memory, get_ram_size() will fail. I assume this applies to
most coldfire devices.
- How about systems/configurations using CONFIG_MONITOR_IS_IN_RAM?
I could not see special precautions for this, but in case an address
to be tested by accident is occupied by a part of get_ram_size()
itself, the result would be ... interesting. ;-) Of course, this is
a rare thing (both using CONFIG_MONITOR_IS_IN_RAM and the chance
to have get_ram_size() at such a crucial location), but still I
fear it might have an impact if get_ram_size() gets "mandatory".
- at least in the coldfire world, CONFIG_SYS_SDRAM_SIZE is quite
often used for cache setup in the assembly code. This contradicts
changing/setting the SDRAM size at runtime...
(Please don't see this as a vote against using and promoting
get_ram_size() - I just see some problems that I am not aware of an
easy solution for.)
Best regards,
Wolfgang Wegner
next prev parent reply other threads:[~2010-05-27 18:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 18:11 [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces >32 bit Wolfgang Denk
2010-05-27 18:16 ` [U-Boot] [PATCH v2] " Wolfgang Denk
2010-05-27 19:46 ` Scott Wood
2010-05-27 19:57 ` Wolfgang Denk
2010-05-27 20:00 ` Scott Wood
2010-05-27 20:53 ` Wolfgang Denk
2010-05-27 18:23 ` [U-Boot] [PATCH] " Timur Tabi
2010-05-27 19:44 ` Wolfgang Denk
2010-05-27 20:01 ` Timur Tabi
2010-05-27 20:57 ` Wolfgang Denk
2010-05-27 21:05 ` Timur Tabi
2010-05-27 21:13 ` Wolfgang Denk
2010-05-27 21:10 ` Kumar Gala
2010-05-27 21:16 ` Wolfgang Denk
2010-05-27 20:06 ` Scott Wood
2010-05-27 21:06 ` Wolfgang Denk
2010-05-27 18:59 ` Wolfgang Wegner [this message]
2010-05-27 19:49 ` 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=20100527185909.GG31271@leila.ping.de \
--to=wolfgang@leila.ping.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.