Dear Bin Meng, In message <caeuhbmwbfvb_sgobk2f_jxhvatyzkz1jj0hxiwdc0xu61hn...@mail.gmail.com> you wrote: > > > I'm afraid I don't understand this change, Can you please explain a > > bit more detailed what "any RAM size" means? > > I meant "any RAM size" that is not power of two.
I was afraid you meant this. > > The existing code should work fine with any RAM size that is a power > > of two (and the algoithm used is based on this assumption, so the > > code would fail if it is not met). > > Unfortunately this limitation is not documented clearly. You are right - the code is completely undocumented, not even the fact that it should always operate on a single bank of memory at a time. > > For correct operation (as originally intended) you would always > > specify a maxsize twice as large as the maximum possible memory size > > of a bank of memory, and the function would return the real size it > > found. > > I don't think this function can work as expected. Even if I pass a > power-of-two RAM size to this function, it could still fail. Imagine > the target has 2GiB memory size, and I pass 8GiB as the maxsize to > this function. The function will hang when it tries to read/write > something at an address that is beyond 2GiB. It should not hang if used properly - but of course this depends a lot on the hardware properties, and you have to know what you are doing. When the code was written, all we had to deal with was Power Architecture systems with pretty flexible and easy to ptogram memory controllers. A typical use case was a system where you could for example populate either 64 or 128 or 256 MB of RAM. In such a case you would run the code with a max size of 512 MB, after configuring he memory controller to map such a size. In this case, acceses to the whole 512 MB range will work without problems, the higher address ranges just mirroring the data of the actually populated RAM. This mirroring will be detected, so you get the information how big the populated RAM really is. If we would only check with a max size of 256 MB, we would not be able to detect the case when there is bigger RAM (say, 512 MB) populated. I am aware that there are situations where you can't program the memory controller so freely, so we often cannot use this complete testing and lose the ability to detect working, but bigger RAM. In any case we always test only the memory locations at the power-of-two borders - the main reason is that this test is supposed to run on every boot, so it must be fast. In your case this immediately shows the problem. Assume you have a memory configuration which is supposed to have 2 GiB + 512 MiB, but by mistake wrong components were fit and instead of 512 MiB there are only 128 MiB actually present. U-Boot will test memory below the ... 128M, 256M, 512M, 1G, 2G (and ideally 4G) limits. It will tell you that there are 2 GiB working memory. It will NOT test any location between 2 GB and 4GB, so it has no chance to find out if there is 128 MB or 512 MB present, or nothing at all, or if this memory is not working at all and returning random data. This code works only for bank sizes that are a power of two! > Given what you mentioned the function limitation, we should update the > codes with the above power of two assumptions documented. That would indeed make sense. On the other hand, I would have expected that this behaviour is kind of obvious from the fact, that we just bit shift the address location used for testing? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The number you have dialed is imaginary. Please divide by 0 and try again.
