[U-Boot] [PATCH 1/3] tegra: add a method to query RAM size from hardware

[Stephen Warren <swarren@wwwdotorg.org>]

On 05/30/2012 10:04 AM, Tom Warren wrote:
> On Tue, May 29, 2012 at 4:47 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 05/29/2012 05:19 PM, Tom Warren wrote:
>>> On Tue, May 29, 2012 at 3:12 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 05/29/2012 03:47 PM, Lucas Stach wrote:
>>>>> The RAM configuration is set by the bootrom to values specified by the BCT.
>>>>> To query the available RAM size of a board we can easily read back those
>>>>> values instead of using the hardcoded ODMdata. This allows for a single
>>>>> u-boot image on similar boards with different amount of RAM.
>>>>
>>>> While this probably works fine (although I didn't read it in detail),
>>>> the boot protocol is defined to work a little differently. U-Boot is
>>>> supposed to read the BCT/BIT from the IRAM, and program PMC_SCRATCH20
>>>> with the ODMDATA, and then the rest of the bootloader and kernel can
>>>> continue to use the fields in the ODMDATA as they currently do.
>>>>
>>>> Tom, you wrote commit f22c431 "arm: Tegra: Use ODMDATA from BCT in IRAM"
>>>> in our downstream tree for this. Are you planning on upstreaming it?
>>>
>>> Eventually, yes.  The nice thing about using a (flash) cmd-line
>>> variable ODMData is that you can vary things like RAM size, UART, etc.
>>> With Lucas' change, you get the fixed RAM size directly from the HW
>>> instead of the ODMDATA (which could be wrong, since it currently has
>>> no bearing on anything else in the BL code, and isn't checked against
>>> what's in the BCT/BIT that the BootROM used).
>>
>> I don't quite understand. Doesn't the boot ROM read the ODMDATA in order
>> to set up the EMC register that Lucas' change reads? Hmm. Perhaps not
>> ODMDATA, but at least some field in the BCT. And when flashing, both the
>> ODMDATA and the BCT are part of the flashing process.
> 
> The BootROM uses the BCT (and maybe the ODMDATA) to set up the SDRAM,
> including, I assume, the size. What I'm talking about is varying the
> ODMDATA RAM size bits so that the BL and kernel/OS see a smaller
> amount of RAM, so you could, for instance, test how things run in 1GB
> on a 2GB system. Not sure if that's actually applicable, but the
> flexibility is there when you allow the ODMData to be changed.

Oh right. I don't think we should support putting the wrong data into
ODMDATA at all.

Having U-Boot or the kernel assume less RAM for testing purposes seems
reasonable. I don't know of a way to do that in U-Boot right now other
than changing the ODMDATA (which as I'll explain below I don't like) or
editing the source. Since this is a pretty low-level testing thing, I
think editing the source is a reasonable method. For the kernel, this
can easily be achieved by editing the device tree or using the mem=
command-line argument.

I don't know if the boot ROM does use ODMDATA to initialize the memory
controller or not, but since the fields are defined, I think we can't
rule out that it either does now or will in a future chip. Typically,
the memory controller (EMC) initialization would need to know exactly
how many chips, chip selects, RAS/CAS lines etc. are actually present.
Some of that information might be automatically derived from the total
RAM size coupled with knowledge of supported configurations in HW. In
other words, if we lie to the EMC setup code about the RAM size, it's
quite possible it would completely mis-program the EMC and hence nothing
would work. So, I think we should, as policy, require that any
BCT/ODMDATA/BIT-related data always be completely accurate, and use
other techniques to test limited-memory scenarios.