Am 14/04/2012 01:04, schrieb Fabio Estevam: > On Fri, Apr 13, 2012 at 7:36 PM, Fabio Estevam <feste...@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: off...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
