Attention is currently required from: Arthur Heymans, Kyösti Mälkki, Lean Sheng Tan.
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/76274?usp=email )
Change subject: nb/intel/sandybridge: Rework nb resource reading ......................................................................
Patch Set 4:
(3 comments)
Commit Message:
https://review.coreboot.org/c/coreboot/+/76274/comment/ffa2fa7b_0c3269f1 : PS4, Line 10: UMA Which function are you referring to? Note that "UMA" in the code refers to the ME stolen memory range just below TOM
File src/northbridge/intel/sandybridge/northbridge.c:
https://review.coreboot.org/c/coreboot/+/76274/comment/f36402c7_5da8ab7a : PS2, Line 151: mmio_from_to(dev, index++, me_base, tom);
This seems weird and potentially crossing 4GiB boundary?
ME UMA is placed just below TOM (Top Of Memory), and TOM is the total installed DRAM capacity. ME UMA is 32 MiB or 64 MiB (can't remember), DIMM sizes are powers of 2 and this platform supports up to 4 DIMMs: no combination of DIMMs can result in ME UMA crossing the 4 GiB boundary.
Then again, the code is quite confusing.
File src/northbridge/intel/sandybridge/northbridge.c:
https://review.coreboot.org/c/coreboot/+/76274/comment/395ef625_e0a758de : PS3, Line 161: printk(BIOS_DEBUG, "DPR base 0x%08lx size %luM\n", dpr_base, dpr_size / MiB);
clang throws this, gcc does not: […]
`uintptr_t` is supposed to be printed using the `PRIxPTR` macro. For `size_t`, the correct way to print is with `%zu` (or `%zx` for hex).