diff options
author | zbao <fishbaozi@gmail.com> | 2012-08-01 18:23:49 +0800 |
---|---|---|
committer | Ronald G. Minnich <rminnich@gmail.com> | 2012-08-01 17:24:04 +0200 |
commit | 9fd183efde9b78ba2f2bf1c1922a3968650b3b05 (patch) | |
tree | 16809e9bb531b1cf10ca95e8822993ce9b5e51fa /src/devices/oprom | |
parent | 9edd8e46f5863d6729b7042279737c483143f8ed (diff) | |
download | coreboot-9fd183efde9b78ba2f2bf1c1922a3968650b3b05.tar.xz |
AMD F15tn northbridge: Remove the misleading 0x100 from the limitk.
I dont known if missed something, but why an extra 0x100 was added to limit?
My board would get the wrong memory table entry 7f000000-7fffffff as RAM, which
is higher than TOM.
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000c0000-000000005e13efff: RAM
3. 000000005e13f000-000000005effffff: CONFIGURATION TABLES
4. 000000005f000000-000000007effffff: RESERVED
5. 000000007f000000-000000007fffffff: RAM
6. 00000000a0000000-00000000afffffff: RESERVED
Ronald G. Minnich:
I think someone who wrote the code was trying to round up the
next 0x100 boundary and did it incorrectly.
Here is code that would do it correctly:
limitk = ((resource_t)((d.mask + 0x00000ff) & 0x1fffff00)) << 9 ;
Zheng:
Plus 0xFF is correct, but the d.mask take bit 0 as enable it.
This bit should be clear when we try to calculate the limitk.
Change-Id: I3848ed5f23001e5bd61a19833650fe13df26eef3
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1265
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Diffstat (limited to 'src/devices/oprom')
0 files changed, 0 insertions, 0 deletions