[U-Boot] [PATCH] mx6qsabresd: Add basic support

[stefano babic]

Am 14/04/2012 01:04, schrieb Fabio Estevam:
> On Fri, Apr 13, 2012 at 7:36 PM, Fabio Estevam <festevam at gmail.com> wrote:
> 

Hi Fabio,

>> So, would it be OK to use 0x10000000 - 0x177fffff as the memory range for mtest?

Some considerations about this issue. hopefully I am not OT. The values
put in the configuration file are the default parameters taken by the
mtest command if no parameters are issued. I agree they must not be set
to wrong values (I mean, outside the adressable RAM), but in any case
mtest is not run automatically and the range can be adjusted in the
console. I can always send a "mtest 0x0x10000000 - 0x177fffff" even if a
restricted range is set in the config file, for example as it is set
now for the mx6qsabrelite (64k).

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.

Now we can take a look at the end address. IMHO it is better to inform
always mtest about which is the end address to be tested, and not rely
to a default value. And, because the total memory is computed
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.

So I will be for a patch that changes the behavior of mtest and computes
automatically the last testable address if the second parameter is not
given, dropping CONFIG_SYS_MEMTEST_END - I know, this is not part of
your patch, I have already said I can be OT ;-)

Regarding the i.MX6, I think it is not important to bind the last
address to 0x10800000 (CONFIG_LOADADDR). This is only the default
address used to load data. U-Boot is not multitasking, so we are sure
that when mtest runs nothing is loaded, and we can test also this memory
range. Maybe it is more important to test the range from 0x10800000,
because it is used mostly to transfer data and we would like to know if
there is some problem in this range.

The only thing we have to be sure is that we cannot overwrite where
u-boot is currently running and its resorces (malloc area, stack, lcd
memory,..). That is, after the relocation, quite at the end of the
available memory (maybe  gd->relocaddr -1 ?).

Best regards,
Stefano Babic

-- 
=====================================================================
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
=====================================================================