summaryrefslogtreecommitdiffstats
path: root/src/vendorcode
Commit message (Collapse)AuthorAgeFilesLines
* Build without ChromeOSKyösti Mälkki2014-05-011-1/+1
| | | | | | | | | Change-Id: I1da636573eed62ce693b984917084643787c094b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3978 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* ChromeOS: Remove oprom_is_loadedKyösti Mälkki2014-05-011-1/+0
| | | | | | | | | | | | | | | | | A global flag oprom_is_loaded was used to indicate to U-boot that VGA option ROM was loaded and run, or that native VGA init was completed on GMA device. Implement this feature without dependency to CHROMEOS option and replace use of global variable oprom_is_loaded with call to gfx_get_init_done(). Change-Id: I7e1afd752f18e5346dabdee62e4f7ea08ada5faf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4309 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* Declare recovery and developer modes outside ChromeOSKyösti Mälkki2014-05-013-38/+8
| | | | | | | | | | | Move the implementation for recovery and developer modes from vendorcode/google/chromes to lib/. Change-Id: I33335fb282de2c7bc613dc58d6912c47f3b5c06c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4308 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
* vendorcode/amd/agesa/fam14: Build as a static libraryEdward O'Callaghan2014-04-151-1/+261
| | | | | | | | | | | | | Following the same reasoning as commit ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library Since AGESA is stage-independent, we can build it just once, and use the resulting static library in both rom and ram stages. Change-Id: I8b78c462f4963fbb3a40d739196529fffedccb4c Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5441 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* vendorcode/amd/agesa/fam15tn: Build as a static libraryAlexandru Gagniuc2014-04-151-0/+437
| | | | | | | | | | | | | | | | | | | | | Up until now, we were building AGESA by specifying each AGESA source file and adding it to the list of romstage and ramstage source files. As a result, we were compiling each AGESA source twice, despite the fact that it does not depend on the stage we're in. Since AGESA is stage-independent, we can build it just once, and use the resulting static library in both rom and ram stages. We still keep the practice of specifying every single AGESA directory as an include dir and adding the AGESA CFLAGS to our global CFLAGS; this is needed due to the way AGESA builds. Change-Id: I9b23264129d1c08cb67cabc31d15a68d43ed7624 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5430 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Idwer Vollering <vidwer@gmail.com>
* Add the Rangeley FSP include & srx directoriesMartin Roth2014-04-1112-0/+2581
| | | | | | | | | | | | | | | | | | | | | | | | These are the .h and .c files from Intel that support interaction with the FSP. These have been modified from the FSP distribution only to strip trailing whitespace. Intel® Firmware Support Package for Intel® Atom™ Processor C2000 Product Family (Formerly Rangeley) "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/fsp Change-Id: I9ed94cb92909c3681cc88bf10b85a9ba25e8fc55 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5457 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
* Add the Bay Trail FSP include & srx directoriesMartin Roth2014-04-1113-0/+2248
| | | | | | | | | | | | | | | | | | | | | | | These are the .h and .c files from Intel that support interaction with the FSP. These have been modified from the FSP distribution only to strip trailing whitespace. Intel® Atom™ processor E3800 product family (formerly Bay Trail) "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/fsp Change-Id: I0fa64dbaf640493cdb5e670e8d213a49d9e7dcfb Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5456 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* Add the ivybridge i89xx FSP include & srx directoriesMartin Roth2014-04-1112-0/+1989
| | | | | | | | | | | | | | | | | | | | | | | | | | | These are the .h and .c files from Intel that support interaction with the FSP. These have been modified from the FSP distribution only to strip trailing whitespace. Intel® Firmware Support Package for Intel® Xeon® E3-1125C v2, E3-1105C v2, Intel® Pentium® Processor B925C, and Intel® Core™ i3-3115C Processors for Communications Infrastructure with Intel® Communications Chipset 89xx Series Platform Controller Hub (formerly Crystal Forest Refresh: Ivy Bridge Gladden and Cave Creek "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/fsp Change-Id: Ib76e89b2d2f6407cf55a5a664da989c7a7e0eb23 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5455 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Update vendorcode/intel/makefile for coming FSPsMartin Roth2014-04-111-4/+7
| | | | | | | | | | | | | | Other FSPs have more than just the initial fsphob.c source file. Add any .c files in the srx directory to the ramstage build. Change-Id: I5118bdcca44935b579809c4fc9566ab7914a6e4b Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5454 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* vendorcode/amd/agesa: Do not hardcode ROM base addressAlexandru Gagniuc2014-04-093-6/+0
| | | | | | | | | | | | | | | | | | | | | | | The ROM address range is set up in the LPC PCI device, register 0x6c. Coreboot already sets that up correctly in the bootblock, however AGESA overrides that to 0xffffff00, which will always map the ROM from 0xff000000. This may conflict with other devices which are assigned address space in that range. If a device is assigned a range between 0xff000000 and the real ROM base, accesses to that device will be diverted to the system ROM, regardless of how other BARs are set up. Since we already need to set up the ROM address range in the bootblock, before calling AGESA, just remove the override from AGESA. Note that not all AGESA versions override this mapping. Change-Id: I592e5d087ed830c9604a04a356912c7654ce56d2 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5467 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Aaron Durbin <adurbin@google.com>
* console: Add printk helper for ChromeOSKyösti Mälkki2014-04-091-2/+1
| | | | | | | | | | | Do not expose console_tx_flush() to ChromeOS as that function is part of lower-level implementation. Change-Id: I1e31662da88a60e83f8e5d307a4b53441c130aab Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5347 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* chromeos: fix build breakage when !CHROMEOS_RAMOOPSAaron Durbin2014-04-051-1/+1
| | | | | | | | | | | | | | | | | Needed types were being guarded by CONFIG_CHROMEOS_RAMOOPS. Expose those unconditionally. BUG=None BRANCH=None TEST=None Change-Id: Ie858c746307ad3669eab5c35bf219e1a58da2382 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/188714 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/5453 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* rmodules: use rmodtool to create rmodulesAaron Durbin2014-03-202-5/+5
| | | | | | | | | | | | | | | | | | | | | Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
* chromeos: provide option to dynamically allocate ram oops bufferAaron Durbin2014-03-119-3/+174
| | | | | | | | | | | | | | | | | | | | | | | | Fixing the location of the ram oops buffer can lead to certain kernel and boot loaders being confused when there is a ram reservation low in the address space. Alternatively provide a mechanism to allocate the ram oops buffer in cbmem. As cbmem is usually high in the address space it avoids low reservation confusion. The patch uncondtionally provides a GOOG9999 ACPI device with a single memory resource describing the memory region used for the ramoops region. BUG=None BRANCH=baytrail,haswell TEST=Built and booted with and w/o dynamic ram oops. With the corresponding kernel change things behave correctly. Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5257 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* coreboot: unify infrastructure for loading payloadsAaron Durbin2014-03-032-2/+24
| | | | | | | | | | | | | | | A payload can be loaded either from a vboot region or from cbfs. Provide a common place for choosing where the payload is loaded from. Additionally, place the logic in the 'loaders' directory similarly to the ramstage loader infrastructure. Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5296 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* vendorcode/amd/agesa/f*: Improve gcccar.inc assembler compatibility.Edward O'Callaghan2014-03-025-5/+5
| | | | | | | | | | | | A comparison with a two's complement in gcccar.inc has dubious GAS/AT&T notation. Clang miss-parses 0x-1 as an invalid hexadecimal number. Change-Id: I88baa5c2513f062ff309df05916a3832b9bd9bb1 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5277 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* coreboot: infrastructure for different ramstage loadersAaron Durbin2014-02-152-52/+39
| | | | | | | | | | | | | | | | | | | | | | There are 2 methods currently available in coreboot to load ramstage from romstage: cbfs and vboot. The vboot path had to be explicitly enabled and code needed to be added to each chipset to support both. Additionally, many of the paths were duplicated between the two. An additional complication is the presence of having a relocatable ramstage which creates another path with duplication. To rectify this situation provide a common API through the use of a callback to load the ramstage. The rest of the existing logic to handle all the various cases is put in a common place. Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5087 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* x86: provide stage_exit() like armAaron Durbin2014-02-151-5/+2
| | | | | | | | | | | | | The arm architectures have a stage_exit() function which takes a void * pointer as an entry point. Provide the same API for x86. This can make the booting paths less architecture-specific. Change-Id: I4ecfbf32f38f2e3817381b63e1f97e92654c5f97 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5086 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* amd/cimx: fix sb(8|9)00 NULL type redefineAaron Durbin2014-02-1111-23/+23
| | | | | | | | | | | | | | | It is inappropriate for chipset code to be redefining types -- especially NULL to a non-pointer type. There's only one non-straight forward change. A condition being checked was '!ptr_type == NULL' (0 as int). That check is actually 'ptr_type != NULL'. Change-Id: Iab5733e5a573baba6fec94e0c955ba4fad72c836 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5088 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* AGESA f15tn: Fix GPP ports resumeRudolf Marek2014-02-012-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The AGESA resumes the GPP ports in the romstage using FchInitResetGpp(), which does FchGppPortInitS3Phase() for S3 resume. The PreInitGppLink() looks into CMOS to figure out what ports to just force to Gen1 or Gen2 PCIe. Then boot continues and in the ramstage the rest of GPP init is executed. There is a problem that nobody sets properly the PortDetected flags in the S3 path. As the consequence FchGppDynamicPowerSaving() thinks the GPP port is not enabled and shut downs it. The best fix would be also to remove the CMOS dependency which might be some left over, because AGESA does not use CMOS much for anything else. There could be also some way how to pass the GPP state structure from romstage to ramstage possibly via hudson/resume.c but I don't know how to do that. Similar problem is that the "late" stage of init again "forgets" the PortDetected state. This fix fixes the resume issue on Asus F2A85-M. With this patch applied both GPP ports (used as PCIe x1 and internal ethernet) are working again after resume. Change-Id: Idaf609043abb09441c6790504d66d23e0637588f Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/4671 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* chromeos: provide option to identify reference code blobAaron Durbin2014-01-301-0/+8
| | | | | | | | | | | | | | | | | | Certain platforms need to have reference code packaged and verified through vboot. Therefore, add this option. BUG=chrome-os-partner:22867 BRANCH=None TEST=Built. Change-Id: Iea4b96bcf334289edbc872a253614bb1bebe196a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/180025 Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/5022 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
* vboot: provide empty vboot_verify_firmware()Aaron Durbin2014-01-301-1/+3
| | | | | | | | | | | | | | | | | | | | In the case of CONFIG_VBOOT_VERIFY_FIRMWARE not being selected allow for calling vboot_verify_firmware() with an empty implementation. This allows for one not to clutter the source with ifdefs. BUG=chrome-os-partner:23249 BRANCH=None TEST=Built with a !CONFIG_VBOOT_VERIFY_FIRMWARE and non-guarded call to vboot_verify_firmware(). Change-Id: I72af717ede3c5d1db2a1f8e586fefcca82b191d5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172711 Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/4879 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* VBOOT: Set virtual recovery switch based on EC Software SyncDuncan Laurie2014-01-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | The Virtual Recovery switch flag needs to be set in coreboot since it is passed through directly to VBOOT layer by depthcharge. Rather than add a new config option we can assume that devices with EC Software Sync also have a virtual recovery switch and set the flag appropriately. BUG=chrome-os-partner:25250 BRANCH=all TEST=build and boot on rambi, successfully enter developer mode Change-Id: Id067eacbc48bc25a86887bce8395fa3a9b85e9f2 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/183672 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5061 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* rmodule: consolidate rmodule stage loadingAaron Durbin2014-01-281-77/+18
| | | | | | | | | | | | | | | | | | | | | | | | There are 3 places rmodule stages are loaded in the existing code: cbfs and 2 in vboot_wrapper. Much of the code is the same except for a few different cbmem entry ids. Instead provide a common implementation in the rmodule library itself. A structure named rmod_stage_load is introduced to manage the inputs and outputs from the new API. BUG=chrome-os-partner:22866 BRANCH=None TEST=Built and booted successfully. Change-Id: I146055005557e04164e95de4aae8a2bde8713131 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174425 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4897 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
* chromeos: include stddef to fix compilation errorAaron Durbin2014-01-281-0/+1
| | | | | | | | | | | As some of the standard definitions were shuffled around chromeos started failing to build. Correct this. Change-Id: I9927441ccb2d646e8b3395e6e9f8e8166de74ab0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4844 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* CBFS: use cbfs_get_file_content whenever possible rather than cbfs_get_fileVladimir Serbinenko2014-01-122-2/+2
| | | | | | | | | | | Number one reason to use cbfs_get_file was to get file length. With previous patch no more need for this. Change-Id: I330dda914d800c991757c5967b11963276ba9e00 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/4674 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
* lib/cbfs_core.c: Supply size of file as well in cbfs_get_file_contentVladimir Serbinenko2014-01-121-1/+1
| | | | | | | | Change-Id: I5b93e5321e470f19ad22ca2cfdb1ebf3b340b252 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/4659 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
* chromeos: Check for recovery reason code in shared dataDuncan Laurie2013-12-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | When using RW firmware path the proper recovery reason can be retrieved from the shared data region. This will result in the actual reason being logged instead of the default "recovery button pressed" reason. 1) build and boot on falco 2) crossystem recovery_request=193 3) reboot into recovery mode, check reason with <TAB> 4) reboot back into chromeos 5) check event log entry for previous recovery mode: 25 | 2013-07-15 10:34:23 | Chrome OS Recovery Mode | Test from User Mode Change-Id: I6f9dfed501f06881e9cf4392724ad28b97521305 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61906 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4368 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
* Correct file permissions.Idwer Vollering2013-12-0746-0/+0
| | | | | | | | | | | | Some files have incorrect/odd permissions, correct them: remove unnecessary +x flags. Change-Id: I784e6e599dfee88239f85bb58323aae9e40fb21c Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/4490 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
* src/vendorcode/amd: remove Visual Studio remnants.Idwer Vollering2013-12-073-877/+0
| | | | | | | | | | | | Delete files that (were overlooked and) are probably needed to build with Visual Studio. Remove doxygen helper files as well. Change-Id: I6b6cece178917ad9da1081eb6b1bb9be33066a77 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/4489 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
* AMD IMC AGESA: Access the data in stack by correct lengthZheng Bao2013-12-053-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug is hard to find. We were adding the feature of fan control. We met some strange things which could not be explained. Like, sometimes adding printk let the error disappear. Then we traced the code by hardware debug tool (HDT). It turned out the data in stack was overwritten. The values of AccessWidthxx are { AccessWidth8 = 1, AccessWidth16, AccessWidth32,} For the case of AccessWidth8, we only need to access the index/data once. But ReadECmsg and WriteECmsg did the loop twice, 1 more time than they are supposed to do. The data in stack next to "Value" would be overwritten. For all the cases, the code should be OpFlag = OpFlag & 0x7f; switch (OpFlag) { case 1: /* AccessWidth8 */ OpFlag = 0;break; case 2: /* AccessWidth16 */ OpFlag = 1;break; case 3: /* AccessWidth32 */ OpFlag = 3;break; case 4: /* AccessWidth64 */ OpFlag = 7;break; default: error; } Actually, the caller only takes AccessWidth8 as the parameter. We can ignore other cases for now. That is an AGESA bug. AMD's AGESA team own this code. They have given the response that they are going to update this in next release. I presume let them decide the proper way to fix that. Before that, I change the code as little as possible to make it run without crash. Change-Id: I566f74c242ce93f4569eedf69ca07d2fb7fb368d Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/4297 Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
* Add Intel FSP northbridge support Sandybridge and IvybridgeMarc Jones2013-12-0414-0/+2001
| | | | | | | | | | | | | | | | | | | | Add support for Sandybridge and Ivybridge using the Intel FSP. The FSP is different enough to warrant its own source files. This source handle the majority of FSP interaction. "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html Change-Id: Ib879c6b0fbf2eb1cbf929a87f592df29ac48bcc5 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/4015 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* vboot: use out_flags to indicate recovery modeDuncan Laurie2013-12-031-4/+26
| | | | | | | | | | | | | | | | | In order to make the proper decision on loading the option rom or not the recovery mode setting needs to be known. Normally this is detected by asking the EC, but if recovery is requested with crossystem then the EC does not know about it. Instead we need to check the output flags from VbInit(). Change-Id: I09358e6fd979b4af6b37a13115ac34db3d98b09d Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/57474 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4223 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
* vboot: Do not pass OPROM_MATTERS flag to VbInitDuncan Laurie2013-12-031-7/+1
| | | | | | | | | | | | | Since we are using VBNV to determine if developer mode is active we do not need the messy OPROM hook magic any longer. Change-Id: I1b9effef3ef2aa84e916060d8e61ee42515a2b7c Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/57473 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4222 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* Add option to disable ChromeOSKyösti Mälkki2013-12-021-8/+12
| | | | | | | | | | | Those building Chromebook firmware from coreboot git might be more interested in building without ChromeOS extras. Change-Id: I2f176d059fd45bf4eb02cc0f3f1dcc353095d0ce Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3977 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* vboot: use out_flags to indicate dev modeAaron Durbin2013-12-021-1/+20
| | | | | | | | | | | | | | | | | In order to make the proper decision on loading the option rom or not the developer mode setting needs to be known. Under early firmware selection it is possible to know the state of developer mode by a flag in out flags. Use this flag when early firmware selection is being employed to determine if developer mode is enabled or not. Change-Id: I9c226d368e92ddf8f14ce4dcde00da144de2a5f3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/57380 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4218 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* slippy: Minor vboot related fixesDuncan Laurie2013-11-251-1/+7
| | | | | | | | | | | | | | | | - Disable EC software sync for now - Report correct EC active firmware mode - Force enable developer mode by default - Set up PCH generic decode regions in romstage - Pass the oprom_is_loaded flag into vboot handoff data Change-Id: Ib7ab35e6897c19455cbeecba88160ae830ea7984 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51155 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4169 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* Honor vboot's request to load the VGA option ROMBill Richardson2013-11-241-7/+1
| | | | | | | | | | | | | | | This removes an earlier patch that caused the VGA option ROM to be loaded by coreboot even in normal mode when it isn't needed. Change-Id: Ie0a331a10fff212a2394e7234a0dbb37570607b7 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48173 Commit-Queue: Stefan Reinauer <reinauer@google.com> Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/4125 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* Fix compile error in chromeos by adding stddef.hDuncan Laurie2013-11-241-0/+1
| | | | | | | | | | | | | | | | | | | Compile was failing with the following error: In file included from src/vendorcode/google/chromeos/vboot_handoff.h:22:0, from src/vendorcode/google/chromeos/chromeos.c:22: vboot_reference/firmware/include/vboot_api.h:388:18: error: unknown type name 'size_t' src/vendorcode/google/chromeos/chromeos.c: In function 'vboot_get_payload': src/vendorcode/google/chromeos/chromeos.c:50:23: error: 'NULL' undeclared (first use in this function) Change-Id: I13f9e41ef6a4151dc65a49eacfa0574083f72978 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48289 Reviewed-on: http://review.coreboot.org/4131 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* vendorcode/amd/agesa/f16kb: Update Kabini PI from v1.0.0.0 to v1.0.0.7WANG Siyuan2013-10-1550-10466/+5465
| | | | | | | | | | | | | | | | | | The platform initialization (PI) code v1.0.0.7 for Kabini has some enhancements like ECC DIMM support, new CPU microcode rev 0700010B, FCH bug fix (RTC) and so on. Use the name Kabini instead of Kerala everywhere. Note, the former PI code was indeed version v1.0.0.0 instead of v0.0.1.0 as used in `AGESA_VERSION_STRING`. Change-Id: I186de1aef222cd35ea69efa93967a3ffb8da7248 Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com> Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3935 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
* Rename cpu/x86/car.h to arch/early_variables.hStefan Reinauer2013-10-131-1/+1
| | | | | | | | | | | | and add an ARMv7 version. Change-Id: I14fbff88d7c2b003dde57a19bf0ba9640d322156 Signed-off-by: Stefan Reinauer <reinauer@google.com> [km: rebased fa004acf8 from chromium git] Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3939 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
* southbridge/cimx/sb900: Rename headers to match sb700 & sb800Corey Osgood2013-09-242-1/+1
| | | | | | | | | | | | | | Northbridge code includes these headers, so they all need to have the same name to allow different combinations of northbridge and southbridge. This changes the sb900 names to match sb700 & sb800, and points agesa/family12 and amd/torpedo to the new file names. Change-Id: I7a654ce9ae591a636a56177f64fb8cb953b4b04f Signed-off-by: Corey Osgood <corey.osgood@gmail.com> Reviewed-on: http://review.coreboot.org/3825 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* AMD f16kb: use AZ_PIN in Kconfig to customize AZALIA_PIN in YangtzeWANG Siyuan2013-08-271-4/+4
| | | | | | | | | | | | | | | | | src/southbridge/amd/agesa/hudson/Kconfig config default value, mainboard Kconfig config value for specific mainboard. bit 1,0 - pin 0 bit 3,2 - pin 1 bit 5,4 - pin 2 bit 7,6 - pin 3 Change-Id: I54a87cf734685515a3e1850838ca7d94387172ce Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com> Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3879 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
* Correct spelling of shadow, setting and memoryPaul Menzel2013-08-161-1/+1
| | | | | | | | Change-Id: Ic7d793754a8b59623b49b7a88c09b5c6b6ef2cf0 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3768 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* CBFS: Change the signature of cbfs_decompress.Gabe Black2013-08-151-4/+4
| | | | | | | | | | | | Instead of returning 0 on success and -1 on error, return the decompressed size of the data on success and 0 on error. The decompressed size is useful information to have that was being thrown away in that function. Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3578 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* AMD AGESA: Fix comment for `PCIE_DDI_DATA_INITIALIZER`Paul Menzel2013-08-061-2/+2
| | | | | | | | | | | | | | | | | Copied from a similar commit for Family 10h AGESA [1] Remove the fourth argument in the comments. Luckily the compiler, at least gcc, warns about a wrong number of arguments, and therefore no incorrect code resulted from the wrong documentation. [1] 07e0f1b AMD AGESA: Fix argument list for `PCIE_DDI_DATA_INITIALIZER` in comments [2] fc47bfa Revert "AMD f14 vendorcode: Fix warning" Change-Id: I3806e368a823e4a40d22e99b91bf3598d9ed2f15 Signed-off-by: Bruce Griffith <bruce.griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/3840 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin@se-eng.com>
* AMD AGESA: Add missing breaks to switch statement in one fileBruce Griffith2013-08-061-1/+8
| | | | | | | | | | | | | | | | | This is the same patch as an earlier one applied to family 15 [1]. Static analysis often flags case statements that do not include a terminating "break;" statement. Eclipse's CODAN is an example of this. This changelist modifies amdlib.c to terminate case statements with "break;". [1] e44a89f amd/agesa/f15/Lib/amdlib.c: Add missing breaks ... Change-Id: Ibd1ae6f2b52fde07de3d978d174975f4d93647ab Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/3839 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin@se-eng.com>
* AMD Kabini: Add "const" modifier to AGESA function parametersBruce Griffith2013-08-066-67/+67
| | | | | | | | | | | | | | | | | | | | Add CONST modifiers to read-only pass-by-reference function parameters in AGESA. This allows the use of "const" modifiers on the declaration of lookup tables that are pass-by-reference. These will be used to identify tables that are copied onto the HEAP but don't need to be. This same change was made for AMD Trinity APUs (Family15tn) [1]. [1] 283ba78 AGESA: Add "const" modifier to function parameters Change-Id: I2bdd9fc5e027e938de9df0f923b95da934bb48dc Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Tested-by: Bruce Griffith <bruce.griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/3837 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
* AMD SATA: Correct "them implement" to "then implement" in commentsPaul Menzel2013-08-052-2/+2
| | | | | | | | | | | | | | This changelist was cherry-picked from merged community code for Parmer [1] and the paths modified so that the Parmer modification is applied against Olive Hill. [1] 0086162 AMD SATA: Correct _them implement_ ... in comments Change-Id: I9849e9a75dacfde15331c4200d72343a59036f14 Signed-off-by: Bruce Griffith <bruce.griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/3841 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* AMD Kabini: Add AGESA/PI code for new processor familySiyuan Wang2013-08-04669-0/+249353
| | | | | | | | | | | Change-Id: Icb6f64e2e3cfd678fb4fb4f13f0e4b678d5acc4a Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-by: Nick Dill <nick.dill@se-eng.com> Tested-by: Bruce Griffith <bruce.griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/3836 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-16 22:19:26 +0000