summaryrefslogtreecommitdiff
path: root/src/lib
AgeCommit message (Collapse)Author
2016-01-21memlayout: Fix unified CBFS_CACHE macroJulius Werner
commit a8aef3ac (cbfs_spi: Initialize spi_flash when initializing cbfs_cache) introduced a bug that makes the rarely-used unified CBFS_CACHE() memlayout macro break when used in conjunction with cbfs_spi.c (since that macro does not define a separate postram_cbfs_cache region). This patch fixes the problem by making all three region names always available for both the unified and split macros in every stage (and adds code to ensure we don't reinitialize the same buffer again in romstage, which might be a bad idea if previous mappings are still in use). BRANCH=None BUG=None TEST=Compiled for both kinds of macros, manually checked symbols in disassembled stages. Change-Id: I114933e93080c8eceab04bfdba3aabf0f75f8ef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0f270f88e54b42afb8b5057b0773644c4ef357ef Original-Change-Id: If172d9fa3d1fe587aa449bd4de7b5ca87d0f4915 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/318834 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12933 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-21*/Makefile.inc: Compile files needed by uart8250 in x86 bootblockAlexandru Gagniuc
These files provide symbols needed by console and uart drivers. This was not an issue in the past, as we were not setting up a C environment this early in the boot process. Change-Id: Ied5106ac30a68971c8330e8f8270ab060994a89d Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/12869 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-20lib: compile mdelay for bootblockPatrick Georgi
Mediatek's bootblock needs mdelay, which depends on a udelay implementation. Compiling the file for bootblock poses no harm: Either udelay exists (in which case mdelay is usable) or it doesn't in which case we see exactly the same kind of build time error (just with udelay instead of mdelay). Change-Id: I7037308d2d79c5cb1b05bb2b57a0912ad11cd7a6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13049 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-15lib: NHLT ACPI table supportAaron Durbin
Intel's SST (Smart Sound Technology) employs audio support which may not consist of HDA. In order to define the topology of the audio devices (mics, amps, codecs) connected to the platform a NHLT specification was created to pass this information from the firmware to the OS/userland. BUG=chrome-os-partner:44481 BRANCH=None TEST=Tested on glados. Audio does get emitted and some mic recording works. Change-Id: I8a9c2f4f76a0d129be44070f09d938c28a73fd27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2472af5793dcffd2607a7b95521ddd25b4be0e8c Original-Change-Id: If469f99ed1a958364101078263afb27761236421 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/312264 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/12935 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-07Correct some common spelling mistakesMartin Roth
- occured -> occurred - accomodate -> accommodate - existant -> existent - asssertion -> assertion - manangement -> management - cotroller -> controller Change-Id: Ibd6663752466d691fabbdc216ea05f2b58ac12d1 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12850 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-06commonlib: Add common cbfs parsing logic to coreboot and cbfstool.Aaron Durbin
To continue sharing more code between the tools and coreboot proper provide cbfs parsing logic in commonlib. A cbfs_for_each_file() function was added to allow one to act on each file found within a cbfs. cbfs_locate() was updated to use that logic. BUG=chrome-os-partner:48412 BUG=chromium:445938 BRANCH=None TEST=Utilized and booted on glados. Change-Id: I1f23841583e78dc3686f106de9eafe1adbef8c9f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12783 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-10lib: remove assets infrastructureAaron Durbin
Now that only CBFS access is supported for finding resources within the boot media the assets infrastructure can be removed. Remove it. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-10cbfs/vboot: remove firmware component supportAaron Durbin
The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-04cbfs: Fix typo in cbfs_prog_stage_load()Julius Werner
The proper return value to signal an error from cbfs_prog_stage_load() is -1, not 0. Change-Id: Ie53b0359c7c036e3f809d1f941dab53f090b84ab Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12633 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-12-03cbfs_spi: Initialize spi_flash when initializing cbfs_cacheMary Ruthven
Most devices do not use SPI before they initialize CBMEM. This change initializes spi_flash in the CBMEM_INIT_HOOK to initialize the postram cbfs cache so it is not overwritten when boot_device_init is called later. BUG=chromium:210230 BRANCH=none TEST=confirm that the first cbfs access can occur before RAM initialized and after on panther and jerry. Change-Id: If3b6efc04082190e81c3773c0d3ce116bb12421f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0ab242786a16eba7fb423694f6b266e27d7660ec Original-Change-Id: I5f884b473e51e6813fdd726bba06b56baf3841b0 Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/314311 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12601 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-03cbfs_spi: enable CBFS access in early romstageMary Ruthven
Currently the CBFS mmap cannot be accessed at the beginning of romstage because it waits until DRAM is initialized. This change first loads CBFS into SRAM and then switches to using DRAM as the backing once it is initialized. BUG=chromium:210230 BRANCH=none TEST=confirm that the cbfs can be access at the beginning and end of romstage on different boards. Change-Id: I9fdaef392349c27ba1c19d4cd07e8ee0ac92dddc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ccaaba266386c7d5cc62de63bdca81a0cc7c4d83 Original-Change-Id: Idabfab99765b52069755e1d1aa61bbee39501796 Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/312577 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12586 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-24lib/timestamp.c: only log "Timestamp table full" onceBen Gardner
If the timestamp table gets corrupted (separate issue), the timestamp_sync_cache_to_cbmem() function may add a large number of bogus timestamp entries. This causes a flood of "ERROR: Timestamp table full". With logs going to a serial console, this renders the system essentially unbootable. There really isn't a need to log that more than once, so log it when the last slot in the timestamp table is filled. Change-Id: I05d131183afceca31f4dac91c5edc95cfb1e443f Signed-off-by: Ben Gardner <gardner.ben@gmail.com> Reviewed-on: http://review.coreboot.org/12506 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-11-21hexdump: Fix output if length is not a multiple of 16Ben Gardner
hexdump currently rounds up length to a multiple of 16. So, hexdump(ptr, 12) prints 16 hex digits, including 4 garbage bytes. That isn't desirable and is easy to fix. Change-Id: I86415fa9bc6cdc84b111e5e1968e39f570f294d9 Signed-off-by: Ben Gardner <gardner.ben@gmail.com> Reviewed-on: http://review.coreboot.org/12486 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-11-19vendorcode/google/chromeos: Cache VPD data into CBMEMHung-Te Lin
There are few drawbacks reading VPD from SPI flash in user land, including "lack of firmware level authority" and "slow reading speed". Since for many platforms we are already reading VPD in firmware (for example MAC and serial number), caching the VPD data in CBMEM should will speed up and simplify user land VPD processing without adding performance cost. A new CBMEM ID is added: CBMEM_ID_VPD, referring to a structure containing raw Google VPD 2.0 structure and can be found by the new LB_TAG_VPD in Coreboot tables. BRANCH=smaug BUG=chrome-os-partner:39945 TEST=emerge-smaug coreboot chromeos-bootimage # and boots successfully. [pg: lots of changes to make it work with what happened in upstream since 2013] Change-Id: If8629ac002d52abed7b480d3d06298665613edbf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 117a9e88912860a22d250ff0e53a7d40237ddd45 Original-Change-Id: Ic79f424a6e3edfb6c5d168b9661d61a56fab295f Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/285031 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/12453 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-11-19edid: Don't half parse (and wrongly print) more detailed timingsDouglas Anderson
The EDID parsing code continued to update _some_ fields of the output edid but not others if "did_detailed_timing" was already set. It also then went on to print out this halfway mix of modes each time, despite the fact that it didn't really update everything. Let's fix that. We'll reduce code changes by using a temporary copy of data in detailed_block() and then we'll copy it back if we decide we should update. BRANCH=none BUG=chrome-os-partner:46998 TEST=No more bogus printouts Change-Id: Idbfa233e0997244c22ef21c892c4473a91621821 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 4d69999cdd7ce3cd2c9332ab3f22ea8eb4b6f2e9 Original-Change-Id: Ia72cac7fda2772f26477e43237678fa30feca584 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309541 Original-Reviewed-on: https://chromium-review.googlesource.com/309609 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12444 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19edid: Use a better mode for 640x480Douglas Anderson
The hardcoded clock value for 640x480 was 25.175 MHz. That's a valid clock to use, but is quite hard to make a non-jittery clock from PLLs. It's much easier to make 25.200 MHz, so let's do that. The difference between the two modes is 59.9 Hz vs. 60 Hz and it seems better to make a non-jittery 60 Hz rather than a very jittery 59.9 Hz. BRANCH=none BUG=chrome-os-partner:46256 TEST=Insignia monitor works, so do others Change-Id: I8aa124d04a90f5dcf9cfa923ed3b693fbb4a06d8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e32ce13462101dc60cfed60b6948b7597e93525a Original-Change-Id: Ia9804afe8011a915e4bec306e863d34ad7e27be5 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309540 Original-Reviewed-by: Stphane Marchesin <marcheu@chromium.org> Original-(cherry picked from commit 7f32c9f460991e5e3b947117d6ae4080e630a532) Original-Reviewed-on: https://chromium-review.googlesource.com/309576 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12443 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19edid: Don't set standard timings as supported if they're notDouglas Anderson
The set to say that a standard timing was supported was not properly in the "if" test. That meant that even when standard timings weren't supported, we thought that they were. That had the side effect of never using the detailed mode. BRANCH=none BUG=chrome-os-partner:46998 TEST=Adafruit panel works now Change-Id: Ide3ed6c5682840f808d854755dac58e9057e6bda Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c99d3ee8d163fc6be207c5a7df2a7aecd7af7849 Original-Change-Id: Ib67735219fd28516857d9b63f1ba156573f1bea3 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309521 Original-(cherry picked from commit 4e4c2816e2239299bc02e3a57fb18056db62b56c) Original-Reviewed-on: https://chromium-review.googlesource.com/309552 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12442 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19edid: Remove useless parameter from detailed_cvt_descriptor()Douglas Anderson
The detailed_cvt_descriptor() function takes a parameter "out" for no good reason. Remove it. BRANCH=none BUG=chrome-os-partner:46998 TEST=Build and boot Change-Id: I1042dba9ddf2b4b543bd07615013088be5055950 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5c3474c9b1f9fb73f44d64d3a0592f92339da2df Original-Change-Id: I4d695a6dba6606d2132578ce0ab4cb612c83d0f4 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/309598 Original-(cherry picked from commit 39122e242e808d71a4e274e8a23e9a63f4984388) Original-Reviewed-on: https://chromium-review.googlesource.com/309496 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12441 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-17arm64: tegra132: tegra210: Remove old arm64/stage_entry.SJulius Werner
This patch removes the old arm64/stage_entry.S code that was too specific to the Tegra SoC boot flow, and replaces it with code that hides the peculiarities of switching to a different CPU/arch in ramstage in the Tegra SoC directories. BRANCH=None BUG=None TEST=Built Ryu and Smaug. !!!UNTESTED!!! Change-Id: Ib3a0448b30ac9c7132581464573efd5e86e03698 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12078 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-11arm/arm64: Generalize bootblock C entry pointJulius Werner
When we first added ARM support to coreboot, it was clear that the bootblock would need to do vastly different tasks than on x86, so we moved its main logic under arch/. Now that we have several more architectures, it turns out (as with so many things lately) that x86 is really the odd one out, and all the others are trying to do pretty much the same thing. This has already caused maintenance issues as the ARM32 bootblock developed and less-mature architectures were left behind with old cruft. This patch tries to address that problem by centralizing that logic under lib/ for use by all architectures/SoCs that don't explicitly opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option). This works great out of the box for ARM32 and ARM64. It could probably be easily applied to MIPS and RISCV as well, but I don't have any of those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and leave that for later cleanup. BRANCH=None BUG=None TEST=Built Jerry and Falco, booted Oak. Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12076 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-11-10edid: add hdmi_monitor_detected in data struct edidYakir Yang
HDMI driver need to know whether the monitor is DVI or HDMI interface, so this commit just introduce a new number 'hdmi_monitor_detected' to struct edid. There were four bits to indicate the monitor interfaces, it's better to take use of that. But those bits only existed in EDID 1.4 version, but didn't persented in the previous EDID version, so I decided to detect the hdmi cea block. BRANCH=none BUG=chrome-os-partner:43789 TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'. When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'. Change-Id: I1a4f1410e1cce1474ffae858db161a18578cac3a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 409f041805d9fdff2d49faa1a3a262cf4dc609c2 Original-Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/309055 Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/12345 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-07arm64: remove secmonAaron Durbin
It's been decided to only support ARM Trusted Firmware for any EL3 monitor. That means any SoC that requires PSCI needs to add its support for ATF otherwise multi-processor bring up won't work. Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11897 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-11-03drivers/pc80: Rework normal / fallback selector codeTimothy Pearson
Per IRC and Gerrit discussion, the normal / fallback selector code is a rather weak spot in coreboot, and did not function correctly for certain use cases. Rework the selector to more clearly indicate proper operation, and also remove dead code. Also tentatively abandon use of RTC bit 385; a follow-up patch will remove said bit from all affected mainboards. The correct operation of the fallback code selector approximates that of a power line recloser, with a user option to attempt normal boot that can be cleared by firmware, but never set by firmware. Additionally, if cleared by user, the fallback path should always be used on the next reboot. Change-Id: I753ae9f0710c524875a85354ac2547df0c305569 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/12289 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-11-03cbmem: add coreboot table records for each cbmem entryAaron Durbin
In order to not expose the cbmem data structures to userland that are used by coreboot internally add each of the cbmem entries to a coreboot table record. The payload ABI uses coreboot tables so this just provides a shortcut for cbmem entries which were manually added previously by doing the work on behalf of all entries. A cursor structure and associated functions are added to the imd code for walking the entries in order to be placed in the coreboot tables. Additionally a struct lb_cbmem_entry is added that lists the base address, size, and id of the cbmem entry. BUG=chrome-os-partner:43731 BRANCH=None TEST=Booted glados. View coreboot table entries with cbmem. Change-Id: I125940aa1898c3e99077ead0660eff8aa905b13b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11757 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-10-28jpeg: add jpeg_fetch_size()Patrick Georgi
This aids the fuzzer test case. Change-Id: Ic7d43b76cf5660e085e7b3b13499de0358c13197 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/12181 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2015-10-27boot_device: add call to boot_device_init()Aaron Durbin
In the program loading paths using vboot it's possible that the boot media has not been initiazed for that stage. Therefore, provide this call such that it's guaranteed to be called at least once. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados. Change-Id: I3a0ef4d9eebbf5f15780316cc76b469e8ac3f358 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6ee0c5bb36d17fd80ba34762e7547359fd8971ce Original-Change-Id: If8dfeedbe1243ec482764e05c8d3f333c18aedd2 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/305540 Original-Tested-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12154 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-27coreboot: make lb_framebuffer a weak functionrobbie zhang
This is to support other gfx enable method such as Gfx Peim (AKA GOP) for Intel soc. BRANCH=none BUG=chrome-os-partner:44559 TEST=Built and boot on kunimitsu/glados. Change-Id: Ib8010ea6901ea906a8b4129807b94ace71ef1165 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ad26a99560009c487070cccf6ab132188b9e247d Original-Change-Id: Id132718a8bcec5446cc4c0d9d636d26e8a99bb15 Original-Signed-off-by: robbie zhang <robbie.zhang@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/303801 Original-Commit-Ready: Robbie Zhang <robbie.zhang@intel.com> Original-Tested-by: Robbie Zhang <robbie.zhang@intel.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/12140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-24lib/stack: Add stack overrun detectionTimothy Pearson
Change-Id: I9a59fcb7cf221ae590a047c520e7aff99e23ecf1 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/11962 Tested-by: build bot (Jenkins) Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2015-10-20Revert "coreboot_table: don't add CMOS checksum twice."Nico Huber
This reverts commit e6606518243d9beda31693d40493b5f7a1a3e2e0. After some discussion on IRC we decided to revert it as libpayload can only read the copy that was removed (and other users like nvramtool can only read the other copy). So we need both copies at this time. Signed-off-by: Nico Huber <nico.h@gmx.de> Change-Id: I6cf6b2a1523d771bb52f3d5720b1b16ed4b348db Reviewed-on: http://review.coreboot.org/11696 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-16bootblock: Link timestamp.c only with EARLY_CBMEM_INITPaul Menzel
Commit dbeedbef (arch/x86/bootblock: Link in object files selected with bootblock-y) breaks building of x86 boards with `CONFIG_EARLY_CBMEM_INIT` *not* selected but CBMEM time stamp collection enabled. Aaron Durbin explained as below [1] and provided this patch to fix it. > That change actually processes bootblock-objs where before it never did > such a thing. I'm sure this isn’t the only issue lurking. bootblock on > x86 implied romcc and thus all the bootblock-y += rules that other > architectures use worked, but now all the implied assumptions are no > longer true on x86. > > timestamp stuff on x86 !CONFIG_EARLY_CBMEM_INIT is the issue you're > seeing. In order to compile timestamp.c for bootblock under these > conditions will mean there needs to be some more Makefile guarding. [1] http://review.coreboot.org/11864 Change-Id: I3441b9fcdbbc8bbe82b9f2075e60668a846ecf09 Fix-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/11875 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-10-14x86: add standalone verstage supportAaron Durbin
To support x86 verstage one needs a working buffer for vboot. That buffer resides in the cache-as-ram region which persists across verstage and romstage. The current assumption is that verstage brings cache-as-ram up and romstage tears cache-as-ram down. The timestamp, cbmem console, and the vboot work buffer are persistent through in both romstage and verstage. The vboot work buffer as well as the cbmem console are permanently destroyed once cache-as-ram is torn down. The timestamp region is migrated. When verstage is enabled the assumption is that _start is the romstage entry point. It's currently expected that the chipset provides the entry point to romstage when verstage is employed. Also, the car_var_*() APIs use direct access when in verstage since its expected verstage does not tear down cache-as-ram. Lastly, supporting files were added to verstage-y such that an x86 verstage will build and link. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados using separate verstage. Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11822 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-11cbfs: don't load x86 programs over the top of read-only mediaAaron Durbin
On x86 the early stages are currently execute-in-place which means they live in the memory-mapped spi flash. However, when loading romstage from verstage the romstage is execute-in-place so it's unnecessary to write over a read-only media -- not to mention writing to read-only memory is wrong to begin with. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados. Noted reduction of 20ms when loading romstage. Change-Id: I7cd399302a3925a05fbce82600b4c50ea66a0fcb Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11823 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-11cbmem console: make verstage first class citizenAaron Durbin
The conditions in cbmem console for supporting verstage were implicitly utilizing CONFIG_BOOTBLOCK_CONSOLE to handle the cbmem console enablement. Fix it so verstage is a first class citizen for deciding actions pertaining to cbmem console. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados using verstage. cbmem console shows verstage output. Change-Id: Iba79efd1c1d4056f1a105a5e10ffc95f3e69b597 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11820 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-11Derive lvds_dual_channel from EDID timings.Vladimir Serbinenko
Based on the info by Felix Held. Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/11857 Tested-by: build bot (Jenkins) Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2015-10-08lib/gcov-glue.c: Define macro `COVERAGE_MAGIC` and use itPaul Menzel
The macro is defined in `util/cbmem/cbmem.c` too, so do the same here, so that searching for that macro name shows all the usages. Change-Id: I52e9fa414fbbe2012bc6d00312db528efba3e564 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/11803 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-10-07cbfs: add struct cbfsfAaron Durbin
Now that cbfs is adding more metadata in the cbfs file header one needs to access that metadata. Therefore, add struct cbfsf which tracks the metadata and data of the file separately. Note that stage and payload metadata specific to itself is still contained within the 'data' portion of a cbfs file. Update the cbfs API to use struct cbfsf. Additionally, remove struct cbfsd as there's nothing else associated with a cbfs region aside from offset and size which tracked by a region_device (thanks, CBFS_ALIGNMENT!). BUG=None BRANCH=None TEST=Built and booted through end of ramstage on qemu armv7. Built and booted glados using Chrome OS. Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-28program.ld: terminate ALIGN statementPatrick Georgi
This fixes building with CONFIG_COVERAGE=y Change-Id: I5128ae0ef0d4f71e3ede7bcb3ee7ed7e265d1bb7 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/11729 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-24coreboot: move TS_END_ROMSTAGE to one spotAaron Durbin
While the romstage code flow is not consistent across all mainboards/chipsets there is only one way of running ramstage from romstage -- run_ramstage(). Move the timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage(). BUG=chrome-os-partner:44827 BRANCH=None TEST=Built and booted glados. TS_END_ROMSTAGE still present in timestamp table. Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11700 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-22linking: link bootblock.elf with .data and .bss sections againAaron Durbin
Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-22coreboot: introduce commonlibAaron Durbin
Instead of reaching into src/include and re-writing code allow for cleaner code sharing within coreboot and its utilities. The additional thing needed at this point is for the utilities to provide a printk() declaration within a <console/console.h> file. That way code which uses printk() can than be mapped properly to verbosity of utility parameters. Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11592 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-09-17linking: Repair special treatments for non-x86 bootblocksJulius Werner
Patch b2a62622b (linking: move romstage and bootblock to use program.ld) unified the linker scripts between different stages. Unfortunately it omitted several special cases from the old bootblock.ld script that are required for non-x86 environments. This patch expands program.ld to once again merge the .BSS into the program image for bootblocks (ensuring correct initialization by the external loader). It also revives the .id section (which adds a human-readable blurb of information to the top of an image) and fixes a problem with unintended automated section alignment. BRANCH=None BUG=None TEST=Jerry and Oak boot again. Change-Id: I54271b8b59a9c773d858d676cde0218cb7f20e74 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6fddbc00963e363039634fa31a9b66254b6cf18f Original-Change-Id: I4d748056f1ab29a8e730f861879982bdf4c33eab Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/299413 Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11660 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09x86: link ramstage the same way regardless of RELOCATABLE_RAMSTAGEAaron Durbin
Previously there were 2 paths in linking ramstage. One was used for RELOCATABLE_RAMSTAGE while the other was fixed location. Now that rmodtool can handle multiple secitons for a single proram segment there's no need for linking ramstage using lib/rmodule.ld. That also means true rmodules don't have symbols required for ramstage purposes so fix memlayout.h. Lastly add default rules for creating rmod files from the known file names and locations. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi. Inspected ramstage.debug as well as rmodules created during the build. Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11524 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: add and use LDFLAGS_commonAaron Durbin
Add an LDFLAGS_common variable and use that for each stage during linking within all the architectures. All the architectures support gc-sections, and as such they should be linking in the same way. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage. Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11522 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-09-09rmodule: use program.ld for linkingAaron Durbin
Bring rmodule linking into the common linking method. The __rmodule_entry symbol was removed while using a more common _start symbol. The rmodtool will honor the entry point found within the ELF header. Add ENV_RMODULE so that one can distinguish the environment when generating linker scripts for rmodules. Lastly, directly use program.ld for the rmodule.ld linker script. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage, sipi_vector, and smm rmodules. Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11517 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09verstage: use common program.ld for linkingAaron Durbin
There's no reason to have a separate verstage.ld now that there is a unified stage linking strategy. Moreover verstage support is throughout the code base as it is so bring in those link script macros into the common memlayout.h as that removes one more specific thing a board/chipset needs to do in order to turn on verstage. BUG=chrome-os-partner:44827 BRANCH=None TEST=None Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11516 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09x86: link romstage like the other architecturesAaron Durbin
All the other architectures are using the memlayout for linking romstage. Use that same method on x86 as well for consistency. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Analyzed readelf output. Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11510 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: move romstage and bootblock to use program.ldAaron Durbin
Instead of having separate <stage>.ld files in src/lib one file can be used: program.ld. There's now only one touch point for stage layout. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Analyzed readelf output. Change-Id: I4c3e3671d696caa2c7601065a85fab803e86f971 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11509 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: lay the groundwork for a unified linking approachAaron Durbin
Though coreboot started as x86 only, the current approach to x86 linking is out of the norm with respect to other architectures. To start alleviating that the way ramstage is linked is partially unified. A new file, program.ld, was added to provide a common way to link stages by deferring to per-stage architectural overrides. The previous ramstage.ld is no longer required. Note that this change doesn't handle RELOCATABLE_RAMSTAGE because that is handled by rmodule.ld. Future convergence can be achieved, but for the time being that's being left out. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built a myriad of boards. Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11507 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-09-07Drop "See file CREDITS..." commentStefan Reinauer
coreboot has no CREDITS file. Change-Id: Iaa4686979ba1385b00ad1dbb6ea91e58f5014384 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/11514 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 15:52:35 +0000