All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.