From: Dirk Behme <dirk.behme@de.bosch.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mx6qsabresd: Add basic support
Date: Wed, 11 Jul 2012 08:23:20 +0200 [thread overview]
Message-ID: <4FFD1BD8.9040107@de.bosch.com> (raw)
In-Reply-To: <4F8A8E8A.2010609@denx.de>
Hi Fabio,
On 15.04.2012 11:02, stefano babic wrote:
> Am 14/04/2012 22:13, schrieb Wolfgang Denk:
>> Dear Stefano,
>>
>> In message <4F898CA5.8070308@denx.de> you wrote:
>>> The start address CONFIG_SYS_MEMTEST_START is the lowest address of the
>>> SDRAM that can be accessed, that is MMDC0_ARB_BASE_ADDR (0x10000000) for
>>> i.MX6.
>> But it _should_ be the lowest address that can _safely_ be used for
>> such tests, i. e. the range MEMTEST_START - MEMTEST_START must neither
>> contain the exception vectors, not U-Boot's code, stack or malloc arena.
>>
>>> dynamically, also the last RAM address that can be tested should be
>>> computed at run time and not at compile time with CONFIG_SYS_MEMTEST_END.
>> CONFIG_SYS_MEMTEST_END is NOT the end of physical RAM, but the end of
>> the range that can be tested without crashing U-Boot...
>
> Well, but why do we have to define at compile time this value, that in
> most cases can be wrong ? Why should "mtest" use a default value if not
> all parameters are passed ? IMHO it is better if mtest returns with an
> error if end address is not provided.
>
>> Such a patch would be wrong.
>
> Really I think it is better to get rid completely of
> CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END without trying to
> make some (maybe wrong) assumptions, and let mtest doing its job
Will we get an update of this patch?
Many thanks and best regards
Dirk
next prev parent reply other threads:[~2012-07-11 6:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 15:28 [U-Boot] [PATCH] mx6qsabresd: Add basic support Fabio Estevam
2012-04-11 19:49 ` Wolfgang Denk
2012-04-11 20:15 ` Fabio Estevam
2012-04-11 21:36 ` Wolfgang Denk
2012-04-13 15:56 ` Fabio Estevam
2012-04-13 16:14 ` Dirk Behme
2012-04-13 22:36 ` Fabio Estevam
2012-04-13 23:04 ` Fabio Estevam
2012-04-14 5:36 ` Dirk Behme
2012-04-14 14:41 ` stefano babic
2012-04-14 15:24 ` Fabio Estevam
2012-04-14 15:28 ` Fabio Estevam
2012-04-14 16:00 ` stefano babic
2012-04-14 20:15 ` Wolfgang Denk
2012-04-15 8:56 ` stefano babic
2012-04-14 20:14 ` Wolfgang Denk
2012-04-14 20:13 ` Wolfgang Denk
2012-04-15 9:02 ` stefano babic
2012-07-11 6:23 ` Dirk Behme [this message]
2012-07-11 8:08 ` Fabio Estevam
2012-04-12 8:23 ` Marek Vasut
2012-04-12 10:52 ` Stefano Babic
2012-09-11 3:56 ` Fabio Estevam
2012-09-11 4:27 ` stefano babic
2012-09-11 5:39 ` Dirk Behme
2012-09-11 14:43 ` Eric Nelson
2012-09-11 15:07 ` Otavio Salvador
2012-09-11 22:10 ` stefano babic
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=4FFD1BD8.9040107@de.bosch.com \
--to=dirk.behme@de.bosch.com \
--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