On Tue, Oct 27, 2015 at 06:27:42PM +0100, Alexander Aring wrote: > On Tue, Oct 27, 2015 at 05:54:59PM +0100, Alexander Aring wrote: > > On Tue, Oct 27, 2015 at 09:29:53AM +0100, Sascha Hauer wrote: > > > This series has some updates for the memory test. The output and the > > > code are made more compact and some additional options are added. Also > > > the remap_range function is reworked. > > > > > > ... > > > > What means 0xdeadbeef here? > > okay, I it's guess the pattern argument which doesn't exist anymore. > > I run memtest now with: > > memtest -t -u > > on the RPi and it seems the first progressbar range of "0/3" - "1/3" runs > faster than the last range of "1/3" - "3/3". > > This sounds like that remap_range does not full manipulate the range > of page tables (the range at the start address). Okay we can't full use > the range, because we need to be PAGE_ALIGN, but the whole first range of > "0/3" - "1/3" sounds not correct for me (it's bigger than PAGE_ALIGN). > > Maybe everything is correct and the first address room is always a > little bit faster than the others, but I don't think that. > > I haven't tried to debug this issue. Can somebody confirm that on an > other arm board? > okay, false alarm. It's confusing me, we do not always the same operation in each progressbar step. We doing in the first part filling some pattern, in second/third part we doing filling pattern and compare. This is why it takes longer. It just looks like some area is still cached and the other uncached. - Alex _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
