[U-Boot] [PATCH 6/6] board: bcm28155_ap: Add board files

[Darwin Rambo <drambo@broadcom.com>]

On 14-01-31 09:15 AM, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/31/2014 12:05 PM, Tim Kryger wrote:
>> On Fri, Jan 31, 2014 at 6:17 AM, Tom Rini <trini@ti.com> wrote:
>>> On 01/30/2014 06:05 PM, Darwin Rambo wrote:
>>>> We tried using this on our reference board and it hangs accessing
>>>> memory regions that are not populated. Our memory controller
>>>> doesn't appear to properly support accessing regions that are not
>>>> backed by physical sdram. So I think it's best to keep this code as
>>>> is and consider this approach for future designs.
>>>
>>> Wait, what did you do?  get_ram_size(base, max) must work and return
>>> CONFIG_SYS_SDRAM_SIZE, or you haven't properly configured your
>>> controller (as get_ram_size just pokes parts of the specified range).
>>
>> Tom,
>>
>> In my experience, there are three general ways memory controllers
>> behave when an access is made to an address that could be backed by
>> RAM but isn't on a particular board.
>>
>> 1. All reads return a fixed pattern and writes are ignored
>> 2. A bus error is triggered that the CPU sees as a data abort
>> 3. No response to the transaction so the bus and CPU lock up
>>
>> I believe the Broadcom memory controller can only behave in the third,
>> least desirable way.
> 
> That's fine.  You should still use get_ram_size(base,
> CONFIG_SYS_SDRAM_SIZE) like other platforms use as this go above the max
> size it's given.  If this hangs, you have a problem with your
> configuration of the memory controller.  Make sense?
Yes. We have tested that this works and will implement this way. Thanks.
> 
> - -- 
> Tom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJS69oUAAoJENk4IS6UOR1Wf/AP/2ApLwjAffxJ7LmEFFEK7hlr
> +dq1FW9ZRppfLRbfUrZz8Q/muyrx1ZuF9pIjjrFxLkNSLS3t8LZrJmfeswePqGC+
> dq6qLl+ovk0VNYsxEhS77j1QQ/LLri67QCiGEZuS8vDB7qxiyuuCXkzyyW8hRFZ7
> yfKpbfdRYpzWTJhAYnB0b1OaBi1jamsnjhXNU5XNa/H3PfDDofNA2fFQQfKbleOH
> BVOka1LP/+28gqKksEziM9cbcjPYJdE/FfY75nkbqKl9PWl+qIUZli90QO3Qdbgy
> uJJB1d3v6amfHZYbJymR3r8FoRjjCKxnCza5rCLpwFLxAKCUIIGHBFUGpvdcFoVa
> YctuEu2Dx2SgQ9dEGbLT1d2bsbfxOATEr5CyCpD7vD/9e/Ze7XaXALVKocfQmDbs
> 77s0YvHuXLGQPudPzYrEqPvgxf/NlNjeLj5IWqF++AE3j5U1sE26x95qk8jobMSn
> KjYGwzsxnd/gErqiYBawkrHxS2f4beAucsoprCh0WmSXiqSh6Wzc/+XlAIVSV7vm
> UE969gAzP1F2j37QfWR2/B0ILP27Pk3Ano8Dj2MIVKCAVkkpSQ5SCqAA7wvMzHej
> 801O52kArhG3/G/WrAbeLoQxKsdUyNI92+T0UaquTI4hRZk5GSvHQNCaZAcx6fCa
> hZ1o6zG9nMsp/yzVe7VZ
> =0yIj
> -----END PGP SIGNATURE-----
>