summaryrefslogtreecommitdiff
path: root/src/southbridge
diff options
context:
space:
mode:
authorGabe Black <gabeblack@google.com>2012-09-30 04:47:48 -0700
committerStefan Reinauer <stefan.reinauer@coreboot.org>2012-11-12 04:22:34 +0100
commitfb8632ab58de871ef3a25b5e57c7a2e95f04a0d8 (patch)
treea1402a9b96267c648a2b8477b24dd7ee89c13b1f /src/southbridge
parent04c5bae39054aedbff1865d9dd2633260c23ece3 (diff)
oprom: Ensure that mode information is valid before putting it in the tables.
At least when CONFIG_CHROMEOS is turned on, it's possible for CONFIG_FRAMEBUFFER_KEEP_VESA_MODE to be set but for there not to be any valid information to put into the framebuffer coreboot table. That means that what's put in there is junk, probably all zeroes from the uninitialized global variable the mode information is stored in (mode_info). When a payload uses libpayload and turns on the coreboot framebuffer console, that console will attempt to scroll at some point and decrease the cursor's y coordinate until it is less than the number of rows claimed by the console. The number of rows is computed by taking the vertical resolution of the framebuffer and dividing it by the height of the font. Because the mode information was all zeroes, the coreboot table info is all zeroes, and that means that the number of rows the console claims is zero. You can't get the unsigned y coordinate of the cursor to be less than zero, so libpayload gets stuck in an infinite loop. The solution this change implements is to add a new function, vbe_mode_info_valid, which simply returns whether or not mode_info has anything in it. If not, the framebuffer coreboot table is not created, and libpayload doesn't get stuck. Change-Id: I08f3ec628e4453f0cfe9e15c4d8dfd40327f91c9 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/1758 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Diffstat (limited to 'src/southbridge')
0 files changed, 0 insertions, 0 deletions