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

[Tom Rini <trini@ti.com>]

-----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?

- -- 
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-----