This adds a simple loop which initializes the stack to 0xdeadbeef
which is used by checkstack().
Change-Id: I8aecf7bfb1067de68c4080c1fcb7eefa28fd04a7
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2421
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Inagua can use GPIOs 178,179 to switch VMEM to 1.5, 1.35 or 1.25 V,
which it does according to data read from the SO-DIMM's SPD EEPROM.
On Persimmon (according to DB-FT1 rev. D schematics) both GPIOs are
unconnected, there is no way to change the 1.5 V DDR3 voltage (save
unsoldering a resistor). The whole code copied over from Inagua is
useless.
Removed the code, instead a comment hints at Inagua, for people who do designs
based on Persimmon but do have a way to change VMEM.
The line ...->DDR3Voltage = VOLT1_5; is supposed to make the AGESA DDR3 code
select the RAM timings for the actually supplied voltage instead of the
hoped-for but unavailable lower voltage. I have no idea how to test this, but
in any case it can't hurt.
Change-Id: Id098e09418b665645814a6ee2d41a3bff72238ba
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2448
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
According to DB-FT1 rev. D schematics the APU PCIe lane 3 is unconnected.
Reflect this fact in the mainboard code.
Change-Id: Ic98f4a63ef971628df7fbf97f56b80ebe7cb8517
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2447
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Comparing Persimmon and Inagua schematics and Coreboot code show the PCIe reset
code has been blindly copied even though it doesn't suit the Persimmon at all.
The Inagua can employ GPIOs 21, 25, 02 to manually reset devices on APU PCIe
lanes 0/1, 2, 3 respectively. (Appearently the motivation for this is to revive
buggy PCIe gen1 devices which got confused by PCIe gen2 signal training.)
However the Persimmon not only doesn't support this, it even needs these 3 pins
for the PCI interface! Instead it uses GPIO50 to reset devices on lanes 0-2 all
at once. Lane 3 is unconnected anyway.
This patch adapts the Persimmon mainboard code according to the DB-FT1 rev. D
schematics.
Change-Id: I05a657d9bf8cc59acc4f5174eb20375165c860c7
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2446
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
At least not in menuconfig. Move it after the endchoice.
Change-Id: I87d2f70e7c1fbe539cd78cb602a39335b2886d8d
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2443
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
The "offset" in cbfs-mkpayload should be printed as type %lu
instead of %d as `gcc` rightfully warns about.
gcc -g -Wall -D_7ZIP_ST -c -o /srv/filme/src/coreboot/util/cbfstool/cbfs-mkpayload.o cbfs-mkpayload.c
cbfs-mkpayload.c: In function ‘parse_fv_to_payload’:
cbfs-mkpayload.c:284:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
cbfs-mkpayload.c:296:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
This warning was introduced in the following commit.
commit 4610247ef1
Author: Patrick Georgi <patrick@georgi-clan.de>
Date: Sat Feb 9 13:26:19 2013 +0100
cbfstool: Handle alignment in UEFI payloads
Reviewed-on: http://review.coreboot.org/2334
Change-Id: I50c26a314723d45fcc6ff9ae2f08266cb7969a12
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2440
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
According to spi.c in src/southbridge/amd/agesa/hudson
readwrite = (bytesin + readoffby1) << 4 | bytesout;
We can see that Hudson limits the SPI programming data
packet size as 15.
We used to write data to SPI in dword mode. It didn't
take full advantage of the data packet size. We need to
leverage that to speed up programming time.
Change-Id: I615e3c8e754e58702247bc26cfffbedaf5827ea8
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2306
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Add needed prototypes to .h files.
Remove unused variables and fix types in printk statements.
Add #IFNDEFs around #DEFINEs to keep them from being defined twice.
Fix a whole bunch of casts.
Fix undefined pre-increment behaviour in a couple of macros. These now
match the macros in the F14 tree.
Change a value of 0xFF that was getting truncated when being assigned
to a 4-bit bitfield to a value of 0x0f.
This was tested with the torpedo build.
This fixes roughly 132 of the 561 warnings in the coreboot build
so I'm not going to list them all.
Here is a sample of the warnings fixed:
In file included from src/cpu/amd/agesa/family12/model_12_init.c:35:0:
src/include/cpu/amd/amdfam12.h:52:5: warning: redundant redeclaration of 'get_initial_apicid' [-Wredundant-decls]
In file included from src/cpu/amd/agesa/family12/model_12_init.c:34:0:
src/include/cpu/amd/multicore.h:48:5: note: previous declaration of 'get_initial_apicid' was here
src/northbridge/amd/agesa/family12/northbridge.c:50:10: warning: no previous prototype for 'get_node_pci' [-Wmissing-prototypes]
src/northbridge/amd/agesa/family12/northbridge.c: In function 'get_hw_mem_hole_info':
src/northbridge/amd/agesa/family12/northbridge.c:302:13: warning: unused variable 'i' [-Wunused-variable]
src/northbridge/amd/agesa/family12/northbridge.c: In function 'domain_set_resources':
src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat]
src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat]
src/northbridge/amd/agesa/family12/northbridge.c:716:1: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat]
In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0,
from src/northbridge/amd/agesa/family12/northbridge.c:38:
src/vendorcode/amd/agesa/f12/AGESA.h:1282:0: warning: "TOP_MEM" redefined [enabled by default]
In file included from src/northbridge/amd/agesa/family12/northbridge.c:34:0:
src/include/cpu/amd/mtrr.h:31:0: note: this is the location of the previous definition
In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0,
from src/northbridge/amd/agesa/family12/northbridge.c:38:
src/vendorcode/amd/agesa/f12/AGESA.h:1283:0: warning: "TOP_MEM2" redefined [enabled by default]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetNumberOfComplexes':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:99:19: warning: operation on 'ComplexList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfPcieEnginesList':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:126:20: warning: operation on 'PciePortList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfDdiEnginesList':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:153:19: warning: operation on 'DdiLinkList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetComplexDescriptorOfSocket':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:225:17: warning: operation on 'ComplexList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PciePhyServices.c:246:1: warning: no previous prototype for 'PcieFmForceDccRecalibrationCallback' [-Wmissing-prototypes]
In file included from src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PcieComplexConfig.c:58:0:
src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/LlanoComplexData.h:120:5: warning: large integer implicitly truncated to unsigned type [-Woverflow]
And fixed a boatload of these types of warning:
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c: In function 'HeapGetBaseAddress':
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:687:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:694:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:701:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:702:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:705:23: warning: assignment makes integer from pointer without a cast [enabled by default]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:709:21: warning: assignment makes integer from pointer without a cast [enabled by default]
Change-Id: I97fa0b8edb453eb582e4402c66482ae9f0a8f764
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2348
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Create a new serial console variable, X86_SERIAL_CONSOLE
which is only enabled when SERIAL_CONSOLE and ARCH_X86 are defined.
Builds for x86 and ARM.
Change-Id: I607253c418de015975a839e3c33577842885ec0c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2412
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This cleans out some obsolete Kconfig variables pertaining to IRAM
usage.
Change-Id: Ie53f5f7204eadc3a3dddc739d2b4b6237242b198
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2417
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This patch fixes up the usage of stack pointer and regions.
The current approach only works by coincidence, so this fixes a few
things at once to get it into a working state and allow us to use
checkstack() again:
- Add a STACK_SIZE Kconfig variable. Earlier on it was evaluated to 0.
- Assign _stack and _estack using CPU-specific Kconfig variables since
it may reside elsewhere in memory (not necessarily DRAM).
- Make the existing IRAM stack variables more useful in this context.
Change-Id: I4ca5b5680c9ea7e26b1b2b6b3890e028188b51c2
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2416
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Just a mechanical cleanup.
Change-Id: I0815625e629ab0b7ae6c948144085f1bd8cabfb5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2408
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The compiler gets mad when the types are equivalent size but not necessarily
interchangeable because of strict aliasing checks. Since uint32_t is likely to
be used when trying to read 32 bit data, it makes sense for them to be the
compatible.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: If73d794866055dc026fc06d6268e692adac0f835
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2411
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
lpgcc was unconditionally setting -m32.
Most of the flags it sets in the common case are right, however: no need
to duplicate them everywhere, and we only want to change the common ones
in one place, so it would be a shame to duplicate _CFLAGS all over the place.
So add another variable, _ARCHEXTRA, which can be used to add
special flags to _CFLAGS. We onlu use it at present for the x86; this may
change.
This allows us to get through compiling on arm and x86.
Change-Id: I12f1620982c4ee10f76b3953e4225f13db31531e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2399
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Get rid of the nest of includes, and make separate sections
for each architecture. Also gets rid of the "there's X86 and there's
everything else" structure of this file.
Change-Id: I4232f50f048fa05e911e5de3aa9ec1530931b461
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2397
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The default_ functions in memory.c are only used to initialize a weak
variable. They should not be used outside memory.c. Make them
invisible.
Remove the declaration from libpayload.h. For real this time.
Change-Id: Id54c1fd172c78748f01a958ce4065dd0eb53bbc3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2394
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
These live at the bottom of memory on x86, but that's IO mapped on the exynos.
The particular range used will likely need to be configurable, but this will
make it work in one more case than it used to.
Change-Id: I4d4963b9732cf538d00f8effb4398f30cbbde6aa
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2410
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We don't need three different implementations.
Change-Id: Ie7b5fa90794676ea38838454a33e8e9188428eb7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2406
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
s5p-common mostly contained duplicate files, drop the whole directory
and merge the few pieces that we are using into exynos5-common.
Change-Id: I5f18e8a6d2379d719ab6bbbf817fe15bda70d17f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2405
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
They're unused. Also drop some unused defines in system.h
Change-Id: Ia5afc3a676a4a94787041430f05d08f333033c73
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2404
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
We don't have asm/
Change-Id: I7f80f47e9d7f457b7a5a64603c59b14d3b536a8c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2403
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
I think this needs to be its own ldscript. I'm pretty sure this one
is going to need some work however. Is libpayload PIC? That would be
best if so.
Change-Id: I44578d70dfa72de527af8901a86583c2a60130ec
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2398
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Multiboot is an x86 only thing. Drop support on ARM.
Change-Id: I13fafa464a794206d5450b4a1f23a187967a8338
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2392
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We don't need SHA in coreboot.
Change-Id: I1985d5e2c74fac39ff9dcdba4c23bb34fa857ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2390
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Since it's utterly architecture-dependent, put it in arch/x86.
Avoid the temptation to make yet another directory with just one
file in it. Fix the makefile to pick up the proper arch-dependent script.
Change-Id: I21ea02551a97bdcbc38419714f3b38cf8335c178
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2389
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
»Chromebook« is the official spelling [1]. So correct that with
the following command.
$ git grep -l ChromeBook | xargs sed -i s,ChromeBook,Chromebook,
The incorrect spelling was only used for the chip name.
[1] http://www.google.com/intl/en/chrome/devices/hp-pavilion-chromebook.html#hp-pav
Change-Id: I9c19f399a3e3d36bd644ec375822daa384a14961
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2370
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We don't seem to need it, and it currently confuses the payload.
(credit to Gabe Black for this, I'm just uploading it)
Change-Id: I4e3a60eceb9b24e3bc8e50db431c1a731d1cdbae
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/2385
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was omitted earlier while we were debugging DRAM code (0a5bc7f).
It was likely broken due to inconsistent units earlier on. Now that
things are cleaned up and working, let's add it back in.
Change-Id: I2f356355c98b2896e2371fa63b9c9f20ae76d634
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2379
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These were left over from earlier debugging and are no longer
needed. They don't indicate any status or useful info (other
than which line of code has been executed). Error messages are
available in case something needs attention.
Change-Id: Ie09fac29c42908cb8924169e56d8927fb76f02da
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2386
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This removes some files leftover from the initial port. Some are
leftover from U-Boot and some were leftover from the skeleton code
derived from x86.
There's a bit more that we'll get in another sweep.
Change-Id: I325793ecb902b3b9430dcf531714ce025d201de6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2380
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mmu_setup() was originally written in U-Boot to utilize board-specific
global data. Since we're trying to avoid that, we added start and size
parameters so that board-specific info can be passed in via mainboard
code. Let's start using it that way.
Change-Id: I7d7de0e42bd918c9f9f0c177acaf56c110bf8353
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2378
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The comment introduced in
commit 50c0a50ac6
Author: David Hendricks <dhendrix@chromium.org>
Date: Thu Jan 31 17:05:50 2013 -0800
armv7: unify stage hand-off routines
Reviewed-on: http://review.coreboot.org/2254
contained a typo, which is corrected now.
Change-Id: I87f7cfa82fcd12b6961d3329e634b4c201cc047e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2372
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The commit introducing support for the Google Butterfly Chromebook
commit d7bd4eb003
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon Feb 11 11:11:36 2013 -0800
Add support for "Butterfly" Chromebook
Reviewed-on: http://review.coreboot.org/2359
contains the typo, which is corrected now.
Change-Id: I932f4cd248cac71c3ede39a7da97162e791827cb
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2373
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
Correct some whitespace inconsistencies introduced in the
following commit.
commit d7bd4eb003
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon Feb 11 11:11:36 2013 -0800
Add support for "Butterfly" Chromebook
Reviewed-on: http://review.coreboot.org/2359
Change-Id: Ifeda7eb29ddf855cdfea41ddbd685441ede55756
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2374
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The commits adding support for the Google Parrot Chromebook
commit a7198b34cc
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Tue Dec 11 16:00:47 2012 -0800
Add support for Google Parrot Chromebook
Reviewed-on: http://review.coreboot.org/2026
and the Google Butterfly Chromebook
commit d7bd4eb003
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon Feb 11 11:11:36 2013 -0800
Add support for "Butterfly" Chromebook
Reviewed-on: http://review.coreboot.org/2359
had macros in `fadt.c` which were not aligned correctly and did
not adhere to the coding style which uses just one space after
`#define`. Fix this and use tabs instead of spaces everywhere.
Change-Id: I1422c57a3bdc2faa29d2a6e2064e4d3aeed0f1cb
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2375
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Upgrade CBFS in libpayload to use new media-based implementation from coreboot
( http://review.coreboot.org/#/c/2182/ ).
Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still
supported, although the recommended way is to use new CBFS API.
To migrate your existing x86 payload source:
- Change cbfs_find to cbfs_get_file
- Change cbfs_find_file to cbfs_get_file_content
- Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument.
Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH);
=> char *jpeg_data = cbfs_get_file_content(
CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH);
The legacy setup_cbfs_from_{ram,flash} is also supported, although the better
equivalent is to make a new media instance:
struct cbfs_media ram_media;
init_cbfs_ram_media(&ram_media, start, size);
char *data = cbfs_get_file_content(&ram_media, "myfile", my_type);
Verified by being successfully linked with filo.
Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2191
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
David Hendricks