fb8632ab58
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> |
||
|---|---|---|
| .. | ||
| oprom | ||
| agp_device.c | ||
| cardbus_device.c | ||
| cpu_device.c | ||
| device.c | ||
| device_romstage.c | ||
| device_util.c | ||
| dummy_chip_ops.c | ||
| hypertransport.c | ||
| Kconfig | ||
| Makefile.inc | ||
| pci_device.c | ||
| pci_ops.c | ||
| pci_rom.c | ||
| pciexp_device.c | ||
| pcix_device.c | ||
| pnp_device.c | ||
| root_device.c | ||
| smbus_ops.c | ||