[coreboot] Patch merged into coreboot/master: 425973c libpayload: Always use virtual pointers in struct sysinfo_t
gerrit at coreboot.org
gerrit at coreboot.org
Thu Nov 15 18:51:38 CET 2012
the following patch was just integrated into master:
commit 425973cf42ad5c298dd2f501d8b9437c60ae9b6f
Author: Nico Huber <nico.huber at secunet.com>
Date: Tue Nov 13 17:11:01 2012 +0100
libpayload: Always use virtual pointers in struct sysinfo_t
We had mixed virtual and physical pointers in struct sysinfo_t. Some
being virtual by accident which led to problems when we tried to
reinitialize lib_sysinfo after relocating FILO (to get intentionally
virtual pointers valid again). I guess this didn't cause much trouble
before, as lib_get_sysinfo() was always called with physical addresses
being equal to their virtual counterparts.
For FILO, two possibilities seem practical: Either, have all pointers in
struct sysinfo_t physical, so relocation doesn't hurt. Or, have all
pointers virtual and call lib_get_sysinfo() again after relocation.
This patch goes the latter way, changing the following pointers for
situations where virtual pointers differ from physical:
.extra_version
.build
.compile_time
.compile_by
.compile_host
.compile_domain
.compiler
.linker
.assembler
.cb_version
.vdat_addr
.tstamp_table
.cbmem_cons
.mrc_cache
We could also just correct the accidentally virtual pointers. But, IMO,
this would lower the risk of future confusion.
Note 1: Looks like .version gets never set.
Note 2: .option_table and .framebuffer were virtual pointers but treated
like physical ones. Even in FILO, this led to no problems as
they were set before relocation.
Change-Id: I4c456f56f049d9f8fc40e62520b1d8ec3dad48f8
Signed-off-by: Nico Huber <nico.huber at secunet.com>
Reviewed-on: http://review.coreboot.org/1855
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer at coreboot.org>
Build-Tested: build bot (Jenkins) at Thu Nov 15 12:57:51 2012, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer at coreboot.org> at Thu Nov 15 18:51:37 2012, giving +2
See http://review.coreboot.org/1855 for details.
-gerrit
More information about the coreboot
mailing list