summaryrefslogtreecommitdiff
path: root/src/drivers/elog/boot_count.c
diff options
context:
space:
mode:
authorNico Huber <nico.h@gmx.de>2023-06-22 23:17:40 +0200
committerLean Sheng Tan <sheng.tan@9elements.com>2023-06-23 08:47:50 +0000
commit0754e00ace632c4a9e22670da3d676d6e9352aa2 (patch)
tree8b8cfc1548007d9969aaca512aa5de3f8fcd32d8 /src/drivers/elog/boot_count.c
parentf31ab7a4976760b63e1ca01fa9490893a0a712bc (diff)
allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G
When moving the code to allocate at the top level in commit 9260ea60bfa4 (allocator_v4: Use memranges only for toplevel), a call to restrict the limit of the resource was dropped. Probably by accident in one of the earliest rebases. Without this call to effective_limit(), 64-bit resour- ces at the top level, i.e. PCI bus 0, were always placed above 4G. Even when this was not requested with the IORESOURCE_ABOVE_4G flag. Tested on kontron/ktqm77 where the issue could be reproduced with x86_64. Without the fix, boot hangs when trying to access the GMA MMIO registers of PCI 00:02.0, which were placed above 4G. Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483 Signed-off-by: Nico Huber <nico.h@gmx.de> Found-by: 9elements QA Reviewed-on: https://review.coreboot.org/c/coreboot/+/76090 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/drivers/elog/boot_count.c')
0 files changed, 0 insertions, 0 deletions