The USBHID driver zero-initializes some but not all of the fields in its
usbhid_inst_t structure. This is a problem because under some
circumstances, some of the uninitialized fields may be read and lead to
incorrect behavior. Some (broken) USB keyboards keep sending reports
that contain all zeroes even when they have no new keys... these usually
get silently ignored, but if the usbhid_inst_t structure is in an
inconsistent state where 'previous' is zeroed out but 'lastkeypress'
is non-zero because it wasn't properly initialized, these reports will
be interpreted as keyrepeats of the bogus 'lastkeypress'. This patch
changes the code to just xzalloc() the whole structure so we won't have
to worry about initialization issues anymore.
Change-Id: Ic987de2daaceaad2ae401a1e12b1bee397f802ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/23766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Make is so that a different timer source can be provided instead
of TSC on x86 platforms.
BUG=b:72378235,b:72170796
Change-Id: I6faeecf7624a5aa4e1af8862036f1fbd2f54eb51
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23435
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add just enough code and boilerplate to keep it compatible with future
libflashrom.
Change-Id: If0d46fab141da525f8f115d3f6045a8c417569eb
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds support to read the SKU ID entry from the coreboot table
that was recently added in coreboot.
Change-Id: I1c3b375da6119a4f8e8e7e25a11644becb90f927
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22743
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch mirrors recent cleanups in coreboot regarding the strapping
ID entries in the coreboot table.
Change-Id: Ia5c3728daf2cb317f8e2bc72c6f1714d6cb4d080
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
bebitenc() just runs a downward loop over the same body as lebitenc().
That doesn't give you a byte-swapped result, it gives you the same final
value, just starting from the other side to fill it in. (Also, it
confused i++ and i--, so it really gives you a compiler error.)
The correct code needs to have the array index inverted relative to the
bit shift index to produce a big endian result.
Change-Id: I5c2da3a196334844ce23468bd0124bbe2f378c46
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When building the Go version of cbmem I found that
LB_TAG_MAC_ADDRS has the same value as LB_TAG_VERSION_TIMESTAMP.
I am guessing that this tag was little used. In any event, move it
forward to 0x33.
Change-Id: I038ad68e787e56903a2ed9cb530809a55821c313
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/22218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
this adds convenience definitions for MSECS_PER_SEC, USECS_PER_MSEC,
and USECS_PER_SEC along the lines of the time units in coreboot's
<timer.h>.
Change-Id: I489dc2d1ff55d137936acec74ac875dc7fbc1713
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://review.coreboot.org/20882
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Currently the only testing we had was 'what-jenkins-does' and
'make lint'. While the lint testing is suitable for developers,
the 'what-jenkins-does' target really isn't, as it was designed
specifically for testing on jenkins.
This adds the infrastructure for basic tests that are more suitable
for the developer. Extended tests and improvements will follow.
Add the coreboot-builds directories to .gitignore.
TODO:
- Save/restore .config
- Update test-abuild to use existing COREBOOT_BUILD_DIR variable
Change-Id: I19e1256d79531112ff84e47a307f55791533806f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chris Ching <chingcodes@google.com>
libpayload needs a static copy of the out of line function
`font_glyph_filled()` in every TU that needs it. So make it static
inline.
This fixes a build error by gcc (Debian 7.1.0-12) 7.1.0 from Debian
Sid/unstable. This happens with any libpayload based payload like
coreinfo, nvramcui or tint.
```
[…]
LPCC build/coreinfo.elf (LINK)
/src/coreboot/payloads/coreinfo/build/libpayload/bin/../lib/libpayload.a(corebootfb.libc.o): In function `corebootfb_putchar':
/src/coreboot/payloads/libpayload/drivers/video/corebootfb.c:173: undefined reference to `font_glyph_filled'
[…]
```
Change-Id: I931f0f17b33abafdc49aa755a0dad65e28820750
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/20897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
the __must_check function attribute is pretty much straight from the
linux kernel - used to encourage callers to consume function return
values.
Change-Id: I1812d957b745d6bebe2a8d34a9c4862316aa8530
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://review.coreboot.org/20881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This introduces support for font scaling with a factor provided via
Kconfig. In practice, the font itself is not scaled at any point in
memory and only the logic to determine whether a pixel should be filled
or not is changed.
Thus, it should not significantly impact either the access time or
memory use.
Change-Id: Idff210617c9ec08c6034aef107cfdb34c7cdf029
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/20709
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This introduces helpers for accessing the included font, instead of
using hardcoded values provided by the font's header itself.
It will allow painlessly adding support for font scaling in a subsequent
change. It should not introduce any functionality change.
Change-Id: I0277984ec01f49dc51bfc8237ef806f13e3547e2
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/20708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Bettong board with the standard configuration is not capable of
running nvramui with the default size.
malloc error happens on PDC_makelines(). Resulting in:
Booting from CBFS...
Run img/nvramcui
Calling addr 0x00100000
initscr(): Unable to create stdscr.
exited with status 1
Change-Id: I56a0fb3319fe77599bf3dd6c328a0b70be60a348
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/20681
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
AHCI spec explicitly states that we may poll.
TEST=Ran FILO on kontron/bsl6 and observed that the controller
always becomes ready during the first delay.
Change-Id: If34694abff14d719d10d89bc6771dbfa12065071
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is (thankfully) not done by coreboot any more for recent chipsets.
Change-Id: If56e38037f7b1e53871ee63e6ff297028c59d493
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Use a `for` instead of a `while` loop and use meaningful identifiers.
Also, don't use more than one variable for one and the same purpose,
don't use more (non-const) variables than necessary, don't alter more
than one variable per statement, don't compare pointers of different
types and don't do pointer arithmetic on `void *`.
This was meant as a fix up to a regression but that has already been
fixed.
Change-Id: I0c8fd118d127a26cfcf68bfb0bf681495821e80a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Fix an issue when setting an unaligned buffer where n is less
than the difference of the rounded up pointer and the pointer.
This was identified where n=1 was passed. n was decremented
once, as expected, then decremented again after the while()
evaluated to false. This resulted in a new n of 4GB.
Change-Id: I862671bbe7efa8d370d0148e22ea55407e260053
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/20655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
The memcpy(), memmove() and memcmp() functions use word by word
operations regardless of the pointer alignment. Depending on the
platform, this could lead to a crash.
This patch makes the memcpy(), memmove() or memcmp() operate byte per
byte if they are supplied with unaligned pointers.
Change-Id: I0b668739b7b58d47266f10f2dff2dc9cbf38577e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/20535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The optimization of the memset() function introduced by commit
dbadb1dd63 (libpayload: Reorder default
memcpy, speed up memset and memcmp) is provoking an issue on x86
platform when compiling without the CONFIG_GPL option.
GCC is making use of the movdqa instruction to copy words. This
instruction can raise a "General Protection Fault Exception" when it
is called on a non-aligned address argument.
Change-Id: I73382a76a4399d8e78244867f2ebb1dca176a6bf
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/20524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
If the framebuffer address is zero the corebootfb_init() function
should abort and not attempt to use it for video, otherwise it
will likely hang.
This was tested by booting on a board that does not have a display
attached and includes the previous patch to zero the framebuffer
structure in the coreboot tables.
Change-Id: I53ca2e947a7915cebb31b51e11ac6c310d9d6c55
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/20368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a Kconfig value to enable building libpayload with the 586 compiler.
Update the cross compiler script to add the Kconfig value name that is
used when libpayload builds.
The Quark SOC does not support some of the instructions generated with
the 686 compiler (e.g. CMOV). Success occurs when
payloads/libpayload/build/config.h indicates that
CONFIG_LP_USE_MARCH_586=1.
TEST=Build and run on Galileo Gen2.
Change-Id: I04907e9a38ee139bae2e8b227821f54614707c25
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/20322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add the default configuration file for the Galileo board. The Quark SOC
requires building libpayload with march=i586.
TEST=Build and run on Galileo Gen2
Change-Id: Ifd4b533feacbab6f0d357e13d8cebb64bc1c18c6
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/20323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The word 'coreboot' should always be written in lowercase, even at the
start of a sentence.
Change-Id: I2ec18ca55e0ea672343a951ab81a24a5630f45fd
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
<https://coreboot.org> is redirected to <https://www.coreboot.org>.
```
$ curl -I https://coreboot.org
HTTP/1.1 301 Moved Permanently
Server: nginx/1.8.1
Date: Mon, 05 Jun 2017 10:41:33 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: https://www.coreboot.org/
```
So use the command below to use the final location to save a redirect.
```
$ git grep -l https://coreboot.org \
| xargs sed -i 's,https://coreboot.org,https://www.coreboot.org,g'
```
Change-Id: I4176c20ef31399f0063b41e3a0029cca0c1b0ff3
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/20035
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The coreboot sites support HTTPS, and requests over HTTP with SSL are
also redirected. So use the more secure URLs, which also saves a
request most of the times, as nothing needs to be redirected.
Run the command below to replace all occurences.
```
$ git grep -l -E 'http://(www.|review.|)coreboot.org'
| xargs sed -i 's,http://\(.*\)coreboot.org,https://\1coreboot.org,g'
```
Change-Id: If53f8b66f1ac72fb1a38fa392b26eade9963c369
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/20034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
coreboot and libpayload currently use completely different code to
perform a full cache flush on ARM64, with even different function names.
The libpayload code is closely inspired by the ARM32 version, so for the
sake of overall consistency let's sync coreboot to that. Also align a
few other cache management details to work the same way as the
corresponding ARM32 parts (such as only flushing but not invalidating
the data cache after loading a new stage, which may have a small
performance benefit).
Change-Id: I9e05b425eeeaa27a447b37f98c0928fed3f74340
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of storing inverted-colored bitmaps,
invert drawing of text bitmap on the fly by adding
an invert parameter down to libpayload. Merging
pivot and invert fields into flags field.
BUG=b:35585623
BRANCH=None
TEST=Make sure compiles successfully
CQ-DEPEND=CL:506453
Change-Id: Ide6893a26f19eb2490377d4d53366ad145a9e6e3
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://review.coreboot.org/19698
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
cbgfx currently does not support portrait screen which height >width.
so add it.
Change-Id: I66fee6d73654e736a2db4a3d191f030c52a23e0d
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Reviewed-on: https://review.coreboot.org/19474
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
input_underrun is defined but not used. A reasonably new compiler,
enabled warnings and warnings-as-error make the build break for no good
reason.
Change-Id: Ibeb7ba53aad5738938093ab7b34695c9c99c9afe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/19482
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
This patch allows the CBMEM console to persist across reboots, which
should greatly help post factum debugging of issues involving multiple
reboots. In order to prevent the console from filling up, it will
instead operate as a ring buffer that continues to evict the oldest
lines once full. (This means that if even a single boot doesn't fit into
the buffer, we will now drop the oldest lines whereas previous code
would've dropped the newest lines instead.)
The console control structure is modified in a sorta
backwards-compatible way, so that new readers can continue to work with
old console buffers and vice versa. When an old reader reads a new
buffer that has already once overflowed (i.e. is operating in true ring
buffer mode) it will print lines out of order, but it will at least
still print out the whole console content and not do any illegal memory
accesses (assuming it correctly implemented cursor overflow as it was
already possible before this patch).
BUG=chromium:651966
TEST=Rebooted and confirmed output repeatedly on a Kevin and a Falco.
Also confirmed correct behavior across suspend/resume for the latter.
Change-Id: Ifcbf59d58e1ad20995b98d111c4647281fbb45ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When console input driver registers itself, perform flush of input
buffer to avoid interpreting any stale key presses before libpayload
is run.
keyboard.c: Remove the redundant buffer flush.
8250.c: Ensure that serial_hardware_is_present is set before call to
add input driver.
BUG=b:37273808
TEST=Verified that any key presses in serial console before payload is
up do not have any effect after the payload starts running.
Change-Id: I46f1b6715ccf6418f5b2c741bf90db2ece26a60d
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19345
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CBGFX currently doesn't support portrait screens at all. This will have
to be fixed eventually but might take a bit of effort. As a first step
to make devices with a portrait panel somewhat usable, this patch will
just force a square canvas on these panels and keep the bottom part of
the screen black.
Also switch set_pixel to calculate framebuffer position via
bytes_per_line instead of x_resolution. This is supposed to be the
canonical way to do that and may differ in cases where the display
controller requires a certain alignment from framebuffer lines.
Change-Id: I47dd3bf95ab8a7d8b7e1913e0ddab346eedd46f1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19279
Tested-by: build bot (Jenkins)
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This adds a gru libpayload config, that should fit all gru-based
devices such as kevin.
As gru-based devices are CrOS devices, select the associated config
to enable CrOS-specific features.
Change-Id: I6e79b763fc497c126612b8786a669a33b57ea29f
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/19137
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We have found a non-compliant USB hub (RealTek RTS 5413) that does not
set a port's Connect Status Change bit on its USB 3.0 half if the port
had already been connected while the hub was being reset. To work around
this bug, this patch adds code to initially request the status of every
port after a hub was enumerated, clear the Connect Status Change bit if
set, and then enumerate the port iff it is currently connected,
regardless of whether the change bit was set. A similar behavior can
also be found in the Linux kernel.
BRANCH=oak
BUG=b:35929438
TEST=Booted Elm with this change, my USB 3.0 sticks enumerate now even
if they had been plugged in since boot.
Change-Id: I8a28252eb94f005f04866d06e4fc61ea265cee89
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18729
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Allows to use SSE and floating point in payloads without digging to
much into x86 assembly code.
Tested on Lenovo T500 (Intel Core2Duo).
Both floating point operation and SSE is properly working.
Change-Id: I4a5fc633f158de421b70435a8bfdc0dcaa504c72
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/18345
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This adds an oak libpayload config, that should fit all oak-based
devices such as elm.
Change-Id: Iabb71404ff84029a5976371a353e8c92e781ca1f
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/18447
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some simple implementation of the MultiBoot protocol may not pass a
memory map (MULTIBOOT_FLAGS_MMAP missing in the flags) but just the two
values for low and high memory, indicated by the MULTIBOOT_FLAGS_MEMINFO
flag.
Support those kind of boot loaders too, instead of falling back to the
hard-coded values in lib_get_sysinfo().
Tested with a multiboot enhanced version of FILO.
Change-Id: I22cf9e3ec0075aff040390bd177c5cd22d439b81
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: https://review.coreboot.org/18350
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Implement the argc/argv passing as described in coreboot’s payload API:
http://www.coreboot.org/Payload_API
While at it, give the code some love by not needlessly trashing register
values.
Change-Id: Ib830f2c67b631b7216843203cefd55d9bb780d83
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: https://review.coreboot.org/18336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Simplify the code by directly using the arguments on the stack as base
pointer relative memory references, instead of loading them into
intermediate registers first.
Make it more robust by preserving all callee saved registers mandated by
the C calling convention (and only those), namely EBP, EBX, ESI and EDI.
Don't assume anything about the register state when the called function
returns -- beside the segment registers and the stack pointer to be
still the same as before the call.
Change-Id: I383d6ccefc5b3d5cca37a1c9b638c231bbc48aa8
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: https://review.coreboot.org/18335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
According to coreboot’s payload API [1], the called payload should be
able to return a value via %eax. Support this by changing the prototype
of start_main() and pass on the return value of main() to the caller
instead of discarding it.
[1] https://www.coreboot.org/Payload_API
Change-Id: I8442faea19cc8e04487092f8e61aa4e5cba3ba76
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: https://review.coreboot.org/18334
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Julius Werner