From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] cmd_mem: Decode the mtest start and end values from fdt
Date: Mon, 04 Mar 2013 10:44:49 +0100 [thread overview]
Message-ID: <20130304094449.286AD200246@gemini.denx.de> (raw)
In-Reply-To: <51f05678-4118-4be8-bb94-ad295c407602@DB3EHSMHS015.ehs.local>
Dear Jagannadha Sutradharudu Teki,
In message <51f05678-4118-4be8-bb94-ad295c407602@DB3EHSMHS015.ehs.local> you wrote:
>
> I think the entire logic to add mtest address support through devicetree with the
> help of environment variables is a mess as there are some side effects (as you mentioned already).
Agreed.
> The main intention to add these address on devicetree is to make memory address configured at
> runtime instead of CONFIG_ macros.
Then just use command line arguments!
The defaults set in the CONFIG_ veriables are intended as safe
margins; they should be set such that they exclude just the exception
vector area (supposed to be located at the lower end of memory) and
the U-Boot code and data (supposed to be located at the upper end of
memory) from testing, but exclude nearly all otherwise available RAM.
> As in most of the boards CONFIG_SYS_MEMTEST_START is depends on CONFIG_SYS_SDRAM_BASE.
> I am trying to remove the dependency instead use the devicetree nodes.
This makes no sense to me.
If CONFIG_SYS_SDRAM_BASE and the device tree settings don;t agree, you
have a serious problem anyway, and need to fix this first.
> Ok, maybe I will add my logic for decoding these address from devicetree on to common/cmd_mem.c
> instead of common/main.c, does it make sense? Help me I f am wrong.
I have to admit that I don't see a use case where this might be
needed, or even beneficial.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Time is a drug. Too much of it kills you.
- Terry Pratchett, _Small Gods_
next prev parent reply other threads:[~2013-03-04 9:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 14:32 [U-Boot] [PATCH] cmd_mem: Decode the mtest start and end values from fdt Jagannadha Sutradharudu Teki
2013-03-01 16:06 ` Wolfgang Denk
2013-03-01 19:15 ` Tom Rini
2013-03-01 19:24 ` Simon Glass
[not found] ` <ff1257d2-b332-477f-915d-0851e5ef944f@CO9EHSMHS030.ehs.local>
2013-03-01 22:48 ` Wolfgang Denk
[not found] ` <51f05678-4118-4be8-bb94-ad295c407602@DB3EHSMHS015.ehs.local>
2013-03-04 9:44 ` Wolfgang Denk [this message]
2013-03-08 19:08 ` [U-Boot] [PATCH] Feature Removal: disable "mtest" command by default Wolfgang Denk
2013-03-08 19:41 ` Ira W. Snyder
2013-03-08 20:50 ` Wolfgang Denk
2013-03-08 20:51 ` [U-Boot] [PATCH v2] " Wolfgang Denk
2013-03-11 19:57 ` Tom Rini
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=20130304094449.286AD200246@gemini.denx.de \
--to=wd@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