On Fri, 2014-10-03 at 10:01 -0600, Stephen Warren wrote:
Recall that on many systems, U-Boot executes from ROM initially and is tasked with initializing the RAM. On all current Tegra ports, U-Boot always executes from RAM, and the boot ROM has already fully initialized RAM. That's quite a different semantic.
Understood.
If there were any stuck address lines, the chances of U-Boot actually executing the code far enough for the RAM size test to succeed vs fail is pretty minimal, since U-Boot is executing from RAM.
Agreed.
To be honest, I would rather that U-Boot explicitly *not* second guess what the user puts into the BCT. That will make debugging other problems much harder.
If the user puts the wrong BCT into flash, I want something to fail hard so they realize there's a problem and fix it early. If U-Boot just ignores what the user programmed, and silently fixes it, the user may well not know about the problem, and hence leave it unfixed for longer, which will only make it far more expensive to fix.
Unfortunately it does not do that, failing hard I mean. I can e.g. happily flash various BCTs onto various boards of ours and some will boot just fine even into Linux where certainly things start to go awry. We did have real cases where customers actually did exactly that and then were on lengthy support cases until we figured this out.
But if you are absolutely against calling get_ram_size() on the Tegras which I think it at least should not hurt I can certainly re-submit with that removed. But at the end for our customers we will have to put such a check into place again.