The length of the memcpy is incorrect and this will cause the
destination buffer to corrupt the following 2 bytes of data.
BUG=none
BRANCH=All
TEST=build and boot on rambi, system boot up without error
Change-Id: I96adf2555b01aa35bb38a2e0f221fc2b2e87a41b
Signed-off-by: Zhuo-Hao Lee <zhuo-hao.lee@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/237510
Reviewed-by: Ryan Lin <ryan.lin@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
[Remove usage of macro `FIELD_SIZEOF(t, f)`.]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8227
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Do not allocate memory if the bootsplash was not found.
Found by Cppcheck 1.65. Fixes:
[src/device/oprom/realmode/x86.c:280]: (error) Memory leak: decdata
Change-Id: I8f8160d3d349c0c2b2a3ed84461729e9210153d8
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6376
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The mainboard_interrupt_handlers() argument for the function
pointer was using void * as the type. This does not allow the compiler
to catch type differences for the arguments. Thus, some code has been
committed which violates the new interrupt callbacks not taking any
arguments. Make sure the compiler provides a type checking benefit.
Change-Id: Ie20699a368e70c33a9a9912e0fcd63f1e6bb4f18
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48970
Reviewed-on: http://review.coreboot.org/4141
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add three functions to edid.c:
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr)
takes an edid and uintptr_t, and fills in a static lb_framebuffer struct
as well as setting the static vbe_valid to 1 unless some problem
is found in the edid. The intent here is that this could be called from
the native graphics setup code on both ARM and x86.
int vbe_mode_info_valid(void)
returns value of the static vbe_valid.
void fill_lb_framebuffer(struct lb_framebuffer *framebuffer)
copies the static edid_fb to lb_framebuffer.
There is now a common vbe.h in src/include, removed the two special ones.
In general, graphics in coreboot is a mess, but graphics is always a
mess. We don't have a clean way to try two different ways to turn on
a device and use the one that works. One battle at a time. Overall,
things are much better.
The best part: this code would also work for ARM, which also uses EDID.
Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3636
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current ramstage code contains uses of symbols that cause issues
when the ramstage is relocatable. There are 2 scenarios resolved by this
patch:
1. Absolute symbols that are actually sizes/limits. The symbols are
problematic when relocating a program because there is no way to
distinguish a symbol that shouldn't be relocated and one that can.
The only way to handle these symbols is to write a program to post
process the relocations and keep a whitelist of ones that shouldn't
be relocated. I don't believe that is a route that should be taken
so fix the users of these sizes/limits encoded as absolute symbols
to calculate the size at runtime or dereference a variable in memory
containing the size/limit.
2. Absoulte symbols that were relocated to a fixed address. These
absolute symbols are generated by assembly files to be placed at a
fixed location. Again, these symbols are problematic because one
can't distinguish a symbol that can't be relocated. The symbols
are again resolved at runtime to allow for proper relocation.
For the symbols defining a size either use 2 symbols and calculate the
difference or provide a variable in memory containing the size.
Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2789
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This hit me when running the latest Qemu with coreboot:
First the graphics OPROM is running, then an iPXE OPROM.
The iPXE OPROM has no int10 support (obviously) so calling
vbe_set_graphics() wipes the framebuffer information from
the coreboot table.
Change-Id: Ie0453c4a908ea4a6216158f663407a3e72ce4d34
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2325
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Not sure why this didn't bite us earlier..
src/device/oprom/realmode/x86.c: In function 'fill_lb_framebuffer':
src/device/oprom/realmode/x86.c:272:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:274:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:275:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:276:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:278:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:280:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:281:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:283:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:284:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:286:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:287:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:289:13: error: dereferencing pointer to incomplete type
src/device/oprom/realmode/x86.c:290:13: error: dereferencing pointer to incomplete type
Change-Id: Ie3b0f731a7b995e954a26e745b07fc122088ca9f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2321
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of adding regparm(0) to each assembler function called
by coreboot, add an asmlinkage macro (like the Linux kernel does)
that can be different per architecture (and that is empty on ARM
right now)
Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1973
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
to match src/include/device
Change-Id: I5d0e5b4361c34881a3b81347aac48738cb5b9af0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1960
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2012-11-30 23:59:58 +01:00
Renamed from src/devices/oprom/realmode/x86.c (Browse further)
