summaryrefslogtreecommitdiff
path: root/src/lib
AgeCommit message (Collapse)Author
2013-09-11CBMEM: Drop parameter from cbmem_reinit()Kyösti Mälkki
Function is always called with get_top_of_ram() - HIGH_MEMORY_SIZE which equals cbmem_base, thus no need to pass it as a parameter. Change-Id: If026cb567ff534716cd9200cdffa08b21ac0c162 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3564 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM x86: Unify get_cbmem_toc()Kyösti Mälkki
Remove any chipset-specific implementations and use arch-specific implementation of get_cbmem_table() instead. Change-Id: I338ee2c1bd51f5e517462115170dc926e040159e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3907 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM: Backup top_of_ram instead of cbmem_tocKyösti Mälkki
AMD northbridges have a complex way to resolve top_of_ram. Once it is resolved, it is stored in NVRAM to be used on resume. TODO: Redesign these get_top_of_ram() functions from scratch. Change-Id: I3cceb7e9b8b07620dacf138e99f98dc818c65341 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3557 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM: Add cbmem_locate_table()Kyösti Mälkki
For both romstage and ramstage, this calls an arch-specific function get_cbmem_table() to resolve the base and size of CBMEM region. In ramstage, the result is cached as the query may be relatively slow involving multiple PCI configuration reads. For x86 CBMEM tables are located right below top of low ram and have fixed size of HIGH_MEMORY_SIZE in EARLY_CBMEM_INIT implementation. Change-Id: Ie8d16eb30cd5c3860fff243f36bd4e7d8827a782 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3558 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM: Unify get_top_of_ram()Kyösti Mälkki
Change-Id: Ic40a51638873642f33c74d80ac41cf082b2fb177 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3904 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM tables: Remove references to global high_tables_baseKyösti Mälkki
Unify checks and writing of CBMEM tables for x86 and ARMv7. Change-Id: I89c012bce1b86d0710748719a8840ec532ce6939 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3559 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM: Add cbmem_late_set_table() and drop references to high_tables_baseKyösti Mälkki
This helper function is for compatibility only for chipsets that do not implement get_top_of_ram() to support early CBMEM. Also remove references to globals high_tables_base and _size under arch/ and from two ARMv7 boards. Change-Id: I17eee30635a0368b2ada06e0698425c5ef0ecc53 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3902 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-06usbdebug: Use CAR migrationKyösti Mälkki
If we already initialized EHCI controller and USB device in romstage, locate active configuration from salvaged CAR_GLOBAL and avoid doing the hardware initialisation again. Change-Id: I7cb3a359488b25abc9de49c96c0197f6563a4a2c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3476 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-06usbdebug: Dump low-level protocol detailsKyösti Mälkki
Dumping these EHCI host controller registers is useful to solve problems with debug devices. Change-Id: I0610cecca57b1b952d4f87211dd00c8c0bc398b9 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3866 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-06usbdebug: Adjust endpoint retry timeoutsKyösti Mälkki
Change Setup Stage of control messages to have no retries, while data and status stages may retry until timing out after 1000 retries. The correct amount of retries might vary by endpoint and device dongle used, so make it a variable. Change-Id: I63313f994d0bd3444a3aab527ca942da5de9e6fa Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3882 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-06usbdebug: Adjust transaction retriesKyösti Mälkki
Transaction consistently completes with 80 to 150 status reads on my setups. Hardware should always be able to complete this within 125us as the debug port is serviced at the beginning of each microframe. Timeout is set to DBGP_MICROFRAME_TIMEOUT_LOOPS=1000 status reads. Do not retry transactions if this timeout is reached as the host controller probably needs full re-initialisation to recover. If this timeout is not reached, but a transaction is corrupted on the wire, or it is otherwise not properly delivered to the USB device, transaction is retried upto DBGP_MICROFRAME_RETRIES=10 times. Change-Id: I44bc0a1bd194cdb5a2c13d5b81fc39bc568ae054 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3881 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-31Remove NRV2B compression supportPatrick Georgi
It wasn't even hooked up to the build system anymore. Change-Id: I4b962ffd945b39451e19da3ec2f7b8e0eecf2e53 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/3892 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-08-29usbdebug: Fix control messagesKyösti Mälkki
Add support for control messages with a write of data stage. Add status stage after a read of non-zero length data stage. Do not retry control message if device responds with STALL. Change-Id: I16fb9ae39630b975af5461b63d050b9adaccef0f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3867 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-29usbdebug: Use separate data toggle for each pipeKyösti Mälkki
USB defines a mechanism to detect certain cases of lost handshakes using an alternating data sequence number, referred to as data toggling. This patch fixes each pipe to have its own tracking of the data toggle state. Change-Id: I62420bdaeadd0842da3189428a37eeb10c646900 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3865 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-29usbdebug: Reference endpoints by pipes in callsKyösti Mälkki
Add allocation for endpoint0 as a pipe for control messages. Endpoint number was already stored in the pipe object, place devnum there too, although all pipes will use same devnum==127. Change-Id: I299d139bdd8083af8b04a694e8e41435ec026a25 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3864 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-29usbdebug: Support choice of EHCI controllerKyösti Mälkki
Nowadays, chipsets or boards do not only have one USB port with the capabilities of a debug port but several ones. Some of these ports are easier accessible than others, so making them configurable is also necessary. This change adds infrastructure to switch between EHCI controllers, but does not implement it for any chipset. Change-Id: I079643870104fbc64091a54e1bfd56ad24422c9f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3438 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-29usbdebug: Change debug port scanningKyösti Mälkki
On AMD platforms, setting of USBDEBUG_DEFAULT_PORT=0 tries to scan all physical ports one after other in incrementing order. To avoid possible problems with other USB devices, one can select the port number here and bypass the scan. Intel platforms can communicate with usbdebug dongle on one physical port only, and this option makes no difference there. Change-Id: I45be6cc3aa91b74650eda2d444c9fcad39d58897 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3872 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-24usbdebug: Only test two possible USB device numbersKyösti Mälkki
After an USB device sees USB bus reset on the bus, it will reset to device number 0. Per the EHCI debug port specification, a debug dongle device may reset to the fixed debug device number of 127 instead. Thus there is no need to try device numbers from 1 to 126. Do a sanity-check on a returned debug descriptor as I experienced some USB flash memory to respond on this request with zero-fill data. Change-Id: I78d58f3dc049cd8c20c6e2aa3a4207ad7e6a6d33 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3861 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-23usbdebug: Halt host controller before resetting itKyösti Mälkki
Resetting an EHCI controller when it is not halted can have undefined behaviour. This mostly fixes a case where calling usbdebug_init() twice would fail to reset the USB dongle device properly. On amd/persimmon it still requires one extra retry, but at least it is now possible to have usbdebug enabled for both romstage and ramstage. Change-Id: Ib0e6e5a0167404f68af2edf112306fdb8def0be9 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3862 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-08-23usbdebug: Do not support logging from SMMKyösti Mälkki
Letting SMI handler touch EHCI controller is an excellent source of USB problems. Remove usbdebug entirely from SMM. It may be possible to make usbdebug console work from SMM after hard work and coordination with payloads and even OS drivers. But we are not there. Change-Id: Id50586758ee06e8d76e682dc6f64f756ab5b79f5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3858 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2013-08-23usbdebug: Add compatibility quirk for FX2Kyösti Mälkki
This quirk is needed with a DIY debug dongle using obsolete CY7C68013 (aka FX2) USB chips. Old revision of chip requires a SET_CONFIGURATION to be sent, while this is not required in EHCI debug port specs. Change-Id: I4926eb19b7e991d6efeef782682756571ad006b9 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3386 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-08-23usbdebug: Block recursive calls of printkKyösti Mälkki
When we create low-level debugging of EHCI controller registers, we call printk() within printk(). In ramstage this would leave us with deadlock waiting on the console spinlock. Change-Id: Idbe029af9af76de27094bb2964c60d9ccfdd96e6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3860 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-08-23usbdebug: Add logging level to debuggingKyösti Mälkki
Increase existing level from DEBUG to INFO. Change-Id: Ic5934aec449f921af96dd3a6524f7275f8de1304 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3859 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-08-19Don't include LZMA in romstage if ramstage is not compressed.Andrew Wu
If ramstage is not compressed, the CBFS module in romstage doesn't need to support LZMA. Removing the LZMA module in this case can save about 3000 bytes in romstage. Change-Id: Id6f7869e32979080e2985c07029edcb39eee9106 Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3878 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-15CBFS: Change how the bss is zeroed when loading a stage.Gabe Black
For reasons explained in a previous CL, it might be necessary to "load" a file from CBFS in place. The loading code in CBFS was, however, zeroing the area of memory the stage was about to be loaded into. When the CBFS data is located elsewhere this works fine, but when it isn't you end up clobbering the data you're trying to load. Also, there's no reason to zero memory we're about to load something into or have just loaded something into. This change makes it so that we only zero out the portion of the memory between what was loaded/decompressed and the final size of the stage in memory. Change-Id: If34df16bd74b2969583e11ef6a26eb4065842f57 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3579 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-15CBFS: Change the signature of cbfs_decompress.Gabe Black
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>
2013-08-10usbdebug: Add option for verbose logging of connectionKyösti Mälkki
Add option to log changes in USB 2.0 EHCI debug port connection. For romstage move usbdebug as the last initialised console so one actually can see these messages. Init order of consoles in ramstage is undetermined and unchanged. Change-Id: I3aceec8a93064bd952886839569e9f5beb6c5720 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3387 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-08-01Add directive __SIMPLE_DEVICE__Kyösti Mälkki
The tests for __PRE_RAM__ or __SMM__ were repeatedly used for detection if dev->ops in the devicetree are not available and simple device model functions need be used. If a source file build for ramstage had __PRE_RAM__ inserted at the beginning, the struct device would no longer match the allocation the object had taken. This problem is fixed by replacing such cases with explicit __SIMPLE_DEVICE__. Change-Id: Ib74c9b2d8753e6e37e1a23fcfaa2f3657790d4c0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3555 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-30usbdebug: Fix missing includeKyösti Mälkki
Change-Id: I74d28c13e6597c56e3b85ccd2b83386b86c200f0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3828 Tested-by: build bot (Jenkins)
2013-07-24usbdebug: Split endpoint buffersKyösti Mälkki
Refactor the structure to better support receive and another set of endpoints over usbdebug. Change-Id: Ib0f76afdf4e638363ff30c67010920142c58f250 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3726 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-15CBFS: Use memmove instead of memcpy when loading a file from CBFS.Gabe Black
It might be the case that a file is being loaded from a portion of CBFS which has already been loaded into a limitted bit of memory somewhere, and we want to load that file in place, effectively, so that it's original location in CBFS overlaps with its new location. That's only guaranteed to work if you use memmove instead of memcpy. Change-Id: Id550138c875907749fff05f330fcd2fb5f9ed924 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3577 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-14Add a HAVE_ARCH_MEMMOVE option to allow overriding memmove.Gabe Black
Change-Id: I4b6a57e7d8e7e685c609b1d85368585b9dd197dc Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3761 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-11usbdebug: Cleanup dbgp_ehci_info callKyösti Mälkki
Change-Id: I9cad64796fcfb7a50d9ed9ec95c56ab855c872e3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3766 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-11Fix CBMEM console use with CAR_MIGRATIONKyösti Mälkki
With EARLY_CBMEM_INIT and CAR_MIGRATION selected, cbmemc_reinit() was called twice during romstage. This effectively deleted output of romstage in CBMEM console. Change-Id: I21072a319c0e4a5f695b0573bc017bf7921fc663 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3609 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-10usbdebug: Put ehci_debug_info in CAR_GLOBALKyösti Mälkki
Store EHCI Debug Port runtime variables in CAR_GLOBAL. For platforms without CAR_MIGRATION, logging on EHCI Debug Port is temporarily lost when CAR is torn down at end of romstage. On model_2065x and model_206ax ehci_debug_info was overlapping the MRC variable region and additionally migration used incorrect size for the structure. Change-Id: I5e6c613b8a4b1dda43d5b69bd437753108760fca Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3475 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-07-10usbdebug: Move EHCI BAR relocation codeKyösti Mälkki
There are other uses for EHCI debug port besides console, so move EHCI relocation code from console to lib. Change-Id: I95cddd31be529351d9ec68f14782cc3cbe08c617 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3626 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-07-10usbdebug: Move ehci_debug_info allocationKyösti Mälkki
Move ehci_debug_info allocation from console to lib, as console code was only built for ramstage. Implement dbgp_ehci_info() to return the EHCI context. Alread alias this as dbgp_console_input() and _output() to return the console stream context later on. Change-Id: Id6cc07d62953f0466df61eeb159e22b0e3287d4e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3625 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10usbdebug: Refactor disable logicKyösti Mälkki
Output to usbdebug console needs to be disabled until hardware is initialized and while EHCI BAR is relocated. Add separate field ehci_info to point to back to EHCI context when hardware is ready to transfer data. Change-Id: If7d441b561819ab8ae23ed9f3f320f7742ed231e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3624 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-10Drop ELF remains from boot codeStefan Reinauer
This stuff is not used, so let's drop it. Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3660 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10lib: Fix spellingMartin Roth
Change-Id: I999987af9cb44906e3c3135c0351a0cd6eb210ff Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3756 Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Rename hardwaremain() to main()Stefan Reinauer
... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10FUI: reorganize include filesRonald G. Minnich
We've got enough of a handle on this to realize some things: drm_dp_helper.h is by design device and architecture independent i915.h is common to most intel graphics chipsets going back several years i915_reg.h is as well Move these files to src/include/device, and adjust the .c files accordingly. Change-Id: I07512b3695fea0b22949074b467986420783d62a Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3637 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Provide support for setting up the framebuffer from EDIDRonald G. Minnich
Add three functions to edid.c: void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr) takes an edid and uintptr_t, and fills in a static lb_framebuffer struct as well as setting the static vbe_valid to 1 unless some problem is found in the edid. The intent here is that this could be called from the native graphics setup code on both ARM and x86. int vbe_mode_info_valid(void) returns value of the static vbe_valid. void fill_lb_framebuffer(struct lb_framebuffer *framebuffer) copies the static edid_fb to lb_framebuffer. There is now a common vbe.h in src/include, removed the two special ones. In general, graphics in coreboot is a mess, but graphics is always a mess. We don't have a clean way to try two different ways to turn on a device and use the one that works. One battle at a time. Overall, things are much better. The best part: this code would also work for ARM, which also uses EDID. Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3636 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-24AMD Fam15tn: Add support for AGESA runtime allocation in CBMEMRudolf Marek
The IOMMU AGESA needs a reserved scratch space and it wants to allocate the stuff for runtime. So provide a simple allocator for 4 KB CBMEM page. Change-Id: I53bdfcd2cd69f84fbfbc6edea53a051f516c05cc Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/3315 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-21Dynamic cbmem: don't compile src/lib/cbmem.c when dynamic cbmem is selected.Denis 'GNUtoo' Carikli
src/lib/cbmem.c is for the static cbmem. Thanks to adurbin for the Makefile.inc pointer and code on #coreboot IRC channel on freenode: <adurbin> no. if you have CONFIG_DYNAMIC_CBMEM then cbmem.c shouldn't be compiled [...] <adurbin> +ifeq ($(CONFIG_EARLY_CBMEM_INIT),y) <adurbin> +ifneq ($(CONFIG_DYNAMIC_CBMEM),y) romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c <adurbin> +endif <adurbin> +endif Without that fix we have: src/lib/cbmem.c:58:43: error: no previous prototype for 'get_cbmem_toc' [-Werror=missing-prototypes] src/lib/cbmem.c:76:6: error: no previous prototype for 'cbmem_init' [-Werror=missing-prototypes] src/lib/cbmem.c:107:5: error: no previous prototype for 'cbmem_reinit' [-Werror=missing-prototypes] This commit was tested on qemu-i440fx with the following commit: qemu-i440fx: Make it compile with CONFIG_DYNAMIC_CBMEM ( http://review.coreboot.org/#/c/3504/ ). Change-Id: I98636aad4bb4b954f3ed3957df67c77f3615964a Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3503 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-06-20fix bootstate typo (bs_dev_eanble -> bs_dev_enable)David Hendricks
Change-Id: I2e3fd58404c48e863a3a1b255337fb397086651b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3506 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-19edid: fix warningGerd Hoffmann
src/lib/edid.c:1177: error: ‘y’ may be used uninitialized in this function Warning is bogus, but seems my gcc (4.4.7 as shipped by RHEL-6) isn't clever enougth to figure this on its own. So help a bit by explicitly initializing the variable. Change-Id: Ia9f966c9c0a6bd92a9f41f1a4a3c8e49f258be37 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-on: http://review.coreboot.org/3501 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-12usbdebug: Improve solving EHCI debug port problemsKyösti Mälkki
Add comment how one can debug the usbdebug hardware init. Do not send printk's to usbdebug console when one is debugging the usbdebug console initialisation itself. Change-Id: I21a285cb31cf64e853bc626f8b6a617bc5a8be19 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3382 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-06-10ramtest.c: Add silent ram_checkAlexandru Gagniuc
In some cases, we want a ram_check that does not die and does not clobber the terminal with useless output that slows us down a lot. Usage examples include Checking if the RAM is up at the start of raminit, or checking if each rank is accessible as it is being initialized. As with all other ram_checks, this is more of a "Is my DRAM properly configured?" test, which is exactly what we want for something to use during memory initialization. Change-Id: I95d8d9a2ce1e29c74ef97b90aba0773f88ae832c Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3416 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-16cbmem console: use cache-as-ram API and cleanupAaron Durbin
Allow for automatic cache-as-ram migration for the cbmem console. The code was refactored in the thought of making it easier to read. The #ifdefs still exist, but they are no longer sprinkled throughout the code. The cbmem_console_p variable now exists globally in both romstage and ramstage. However, the cbmem_console_p is referenced using the cache-as-ram API. When cbmem is initialized the console is automatically copied over by calling cbmemc_reinit() through a callback. Change-Id: I9f4a64e33c58b8b7318db27942e37c13804e6f2c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3235 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-16x86: add cache-as-ram migration optionAaron Durbin
There are some boards that do a significant amount of work after cache-as-ram is torn down but before ramstage is loaded. For example, using vboot to verify the ramstage is one such operation. However, there are pieces of code that are executed that reference global variables that are linked in the cache-as-ram region. If those variables are referenced after cache-as-ram is torn down then the values observed will most likely be incorrect. Therefore provide a Kconfig option to select cache-as-ram migration to memory using cbmem. This option is named CAR_MIGRATION. When enabled, the address of cache-as-ram variables may be obtained dynamically. Additionally, when cache-as-ram migration occurs the cache-as-ram data region for global variables is copied into cbmem. There are also automatic callbacks for other modules to perform their own migration, if necessary. Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3232 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-14coreboot: add thread cooperative multitaskingAaron Durbin
The cooperative multitasking support allows the boot state machine to be ran cooperatively with other threads of work. The main thread still continues to run the boot state machine (src/lib/hardwaremain.c). All callbacks from the state machine are still ran synchronously from within the main thread's context. Without any other code added the only change to the boot sequence when cooperative multitasking is enabled is the queueing of an idlle thread. The idle thread is responsible for ensuring progress is made by calling timer callbacks. The main thread can yield to any other threads in the system. That means that anyone that spins up a thread must ensure no shared resources are used from 2 or more execution contexts. The support is originally intentioned to allow for long work itesm with busy loops to occur in parallel during a boot. Note that the intention on when to yield a thread will be on calls to udelay(). Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3206 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-08hardwaremain: drop boot_complete parameterStefan Reinauer
it has been unused since 9 years or so, hence drop it. Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3212 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-08cbfs_core.c: make cfbs searches even less verboseDave Frodin
The cbfs core code would print out the name of the file it is searching for and when it is found would print out the name again. This contributes to a lot of unnecessary messages in a functioning payload’s output. Change this message to a DEBUG one so that it will only be printed when CONFIG_DEBUG_CBFS is enabled. Change-Id: Ib238ff174bedba8eaaad8d1d452721fcac339b1a Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3208 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-07boot state: remove drain timers optionAaron Durbin
Internally there were states that had an attribute to indicate that the timers needed to be drained. Now that there is a way to block state transitions rely on this ability instead of draining timers. The timers will drain themselves when a state is blocked. Change-Id: I59be9a71b2fd5a17310854d2f91c2a8957aafc28 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3205 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-07boot state: add ability to block state transitionsAaron Durbin
In order to properly sequence the boot state machine it's important that outside code can block the transition from one state to the next. When timers are not involved there's no reason for any of the existing code to block a state transition. However, if there is a timer callback that needs to complete by a certain point in the boot sequence it is necessary to place a block for the given state. To that end, 4 new functions are added to provide the API for blocking a state. 1. boot_state_block(boot_state_t state, boot_state_sequence_t seq); 2. boot_state_unblock(boot_state_t state, boot_state_sequence_t seq); 3. boot_state_current_block(void); 4. boot_state_current_unblock(void); Change-Id: Ieb37050ff652fd85a6b1e0e2f81a1a2807bab8e0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3204 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-03cbfs: make searching for a file less verboseAaron Durbin
The cbfs core code would print out all unmatched file names when searching for a file. This contributes to a lot of unnecessary messages in the boot log. Change this message to a DEBUG one so that it will only be printed when CONFIG_DEBUG_CBFS is enabled. Change-Id: I1e46a4b21d80e5d2f9b511a163def7f5d4e0fb99 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3131 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com> Tested-by: build bot (Jenkins)
2013-05-01boot state: run timers on state entryAaron Durbin
When TIMER_QUEUE is configured on call the timer callbacks on entry into a state but before its entry callbacks. In addition provide a barrier to the following states so that timers are drained before proceeding. This allows for blocking state traversal for key components of boot. BS_OS_RESUME BS_WRITE_TABLES BS_PAYLOAD_LOAD BS_PAYLOAD_BOOT Future functionality consists of evaluating the timer callbacks within the device tree. One example is dev_initialize() as that seems state seems to take 90% of the boot time. The timer callbacks could then be ran in a more granular manner. Change-Id: Idb549ea17c5ec38eb57b4f6f366a1c2183f4a6dd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3159 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coreboot: add timer queue implementationAaron Durbin
A timer queue provides the mechanism for calling functions in the future by way of a callback. It utilizes the MONOTONIC_TIMER to track time through the boot. The implementation is a min-heap for keeping track of the next-to-expire callback. Change-Id: Ia56bab8444cd6177b051752342f53b53d5f6afc1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3158 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: track times for each stateAaron Durbin
When the MONOTONIC_TIMER is available track the entry, run, and exit times for each state. It should be noted that the times for states that vector to OS or a payload do not have their times reported. Change-Id: I6af23fe011609e0b1e019f35ee40f1fbebd59c9d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3156 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: rebalance payload load vs actual bootAaron Durbin
The notion of loading a payload in the current boot state machine isn't actually loading the payload. The reason is that cbfs is just walked to find the payload. The actual loading and booting were occuring in selfboot(). Change this balance so that loading occurs in one function and actual booting happens in another. This allows for ample opportunity to delay work until just before booting. Change-Id: Ic91ed6050fc5d8bb90c8c33a44eea3b1ec84e32d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3139 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01x86: use boot state callbacks to disable rom cacheAaron Durbin
On x86 systems there is a concept of cachings the ROM. However, the typical policy is that the boot cpu is the only one with it enabled. In order to ensure the MTRRs are the same across cores the rom cache needs to be disabled prior to OS resume or boot handoff. Therefore, utilize the boot state callbacks to schedule the disabling of the ROM cache at the ramstage exit points. Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3138 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot: remove cbmem_post_handling()Aaron Durbin
The cbmem_post_handling() function was implemented by 2 chipsets in order to save memory configuration in flash. Convert both of these chipsets to use the boot state machine callbacks to perform the saving of the memory configuration. Change-Id: I697e5c946281b85a71d8533437802d7913135af3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3137 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01cbmem: use boot state machineAaron Durbin
There were previously 2 functions, init_cbmem_pre_device() and init_cbmem_post_device(), where the 2 cbmem implementations implemented one or the other. These 2 functions are no longer needed to be called in the boot flow once the boot state callbacks are utilized. Change-Id: Ida71f1187bdcc640ae600705ddb3517e1410a80d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3136 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coverage: use boot state callbacksAaron Durbin
Utilize the static boot state callback scheduling to initialize and tear down the coverage infrastructure at the appropriate points. The coverage initialization is performed at BS_PRE_DEVICE which is the earliest point a callback can be called. The tear down occurs at the 2 exit points of ramstage: OS resume and payload boot. Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3135 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01acpi: split resume check and actual resume codeAaron Durbin
It's helpful to provide a distinct state that affirmatively describes that OS resume will occur. The previous code included the check and the actual resuming in one function. Because of this grouping one had to annotate the innards of the ACPI resume path to perform specific actions before OS resume. By providing a distinct state in the boot state machine the necessary actions can be scheduled accordingly without modifying the ACPI code. Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3134 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: schedule static callbacksAaron Durbin
Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01ramstage: introduce boot state machineAaron Durbin
The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01rmodule: put all code/data bits in one sectionAaron Durbin
While debugging a crash it was discovered that ld was inserting address space for sections that were empty depending on section address boundaries. This led to the assumption breaking down that on-disk payload (code/data bits) was contiguous with the address space. When that assumption breaks down relocation updates change the wrong memory. Fix this by making the rmodule.ld linker script put all code/data bits into a payload section. Change-Id: Ib5df7941bbd64662090136e49d15a570a1c3e041 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3149 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-04-20Eliminate use of pointers in coreboot tableStefan Reinauer
Because pointers can be 32bit or 64bit big, using them in the coreboot table requires the OS and the firmware to operate in the same mode which is not always the case. Hence, use 64bit for all pointers stored in the coreboot table. Guess we'll have to fix this up once we port to the first 128bit machines. Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3115 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-04-18spkmodem consoleVladimir Serbinenko
Change-Id: Ie497e4c8da05001ffe67c4a541bd24aa859ac0e2 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/2987 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08Fix read_option invocation in uart8250mem.cStefan Reinauer
read_option was unified between ramstage and romstage a while ago. However, it seems some invocations were not fixed accordingly. This patch switches uart8250mem.c to use the new scheme. Change-Id: I03cef4f6ee9188a6412c61d7ed34fbaff808a32b Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3033 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08Fix compilation when coverage debugging is enabledStefan Reinauer
With CONFIG_DEBUG_COVERAGE enabled, the build currently fails with src/lib/gcov-glue.c: In function 'fseek': src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format] src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format] Change-Id: Iddaa601748c210d9dad06ae9dab2a3deaa635b2c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3032 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01lynxpoint: Move ACPI NVS into separate CBMEM tableDuncan Laurie
The ACPI NVS region was setup in place and there was a CBMEM table that pointed to it. In order to be able to use NVS earlier the CBMEM region is allocated for NVS itself during the LPC device init and the ACPI tables point to it in CBMEM. The current cbmem region is renamed to ACPI_GNVS_PTR to indicate that it is really a pointer to the GNVS and does not actually contain the GNVS. Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2970 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01boot: add disable_cache_rom() functionAaron Durbin
On certain architectures such as x86 the bootstrap processor does most of the work. When CACHE_ROM is employed it's appropriate to ensure that the caching enablement of the ROM is disabled so that the caching settings are symmetric before booting the payload or OS. Tested this on an x86 machine that turned on ROM caching. Linux did not complain about asymmetric MTRR settings nor did the ROM show up as cached in the MTRR settings. Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2980 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29memrange: add 2 new range_entry routinesAaron Durbin
Two convenience functions are added to operate on a range_entry: - range_entry_update_tag() - update the entry's tag - memranges_next_entry() - get the next entry after the one provide These functions will be used by a follow on patch to the MTRR code to allow hole punching in WB region when the default MTRR type is UC. Change-Id: I3c2be19c8ea1bbbdf7736c867e4a2aa82df2d611 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2924 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: add rom cache variable MTRR index to tablesAaron Durbin
Downstream payloads may need to take advantage of caching the ROM for performance reasons. Add the ability to communicate the variable range MTRR index to use to perform the caching enablement. An example usage implementation would be to obtain the variable MTRR index that covers the ROM from the coreboot tables. Then one would disable caching and change the MTRR type from uncacheable to write-protect and enable caching. The opposite sequence is required to tearn down the caching. Change-Id: I4d486cfb986629247ab2da7818486973c6720ef5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2919 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29lib: add memrange infrastructureAaron Durbin
The memrange infrastructure allows for keeping track of the machine's physical address space. Each memory_range entry in a memory_ranges structure can be tagged with an arbitrary value. It supports merging and deleting ranges as well as filling in holes in the address space with a particular tag. The memrange infrastructure will serve as a shared implementation for address tracking by the MTRR and coreboot mem table code. Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2888 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29coreboot table: use memrange libraryAaron Durbin
Use the memrange library for keeping track of the address space region types. The memrange library is built to do just that for both the MTRR code and the coreboot memtable code. Change-Id: Iee2a7c37a3f4cf388db87ce40b580f274384ff3c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2917 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26Revert "coreboot table: use memrange library"Aaron Durbin
This reverts commit 56075eaefcd7ef51464206166b24a0a47a59147f Change-Id: I8a37ce1f5ce36e4a120941ec264140abc9447ff5 Reviewed-on: http://review.coreboot.org/2915 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-26coreboot table: use memrange libraryAaron Durbin
Use the memrange library for keeping track of the address space region types. The memrange library is built to do just that for both the MTRR code and the coreboot memtable code. Change-Id: Ic667df444586c2b5b5f2ee531370bb790d683a42 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2896 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23dynamic cbmem: fix memconsole and timestampsAaron Durbin
There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM rely on EARLY_CBMEM_INIT. This isn't true in the face of DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT. Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem implementation when COLLECT_TIMESTAMPS is selected. Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2895 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23rmodule: align ld script with latest x86 ld scriptAaron Durbin
The x86 linker script added a .textfirst section. In order to properly link ramstage as a relocatable module the .textfirst section needs to be included. Also, the support for code coverage was added by including the constructor section and symbols. Coverage has not been tested as I suspect it might not work in a relocatable environment without some tweaking. However, the section and symbols are there if needed. Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2883 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23cbfs: fix relocation ramstage compiler errorsAaron Durbin
There were some cbfs calls that did not get transitioned to the new cbfs API. Fix the callsites to conform to the actual cbfs, thus fixing the copilation errors. Change-Id: Ia9fe2c4efa32de50982e21bd01457ac218808bd3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2880 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22Unify coreboot table generationStefan Reinauer
coreboot tables are, unlike general system tables, a platform independent concept. Hence, use the same code for coreboot table generation on all platforms. lib/coreboot_tables.c is based on the x86 version of the file, because some important fixes were missed on the ARMv7 version lately. Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d Signed-off-by: Stefan Reinauer <reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/2863 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-22romstage: add support for vboot firmware selectionAaron Durbin
This patch implements support for vboot firmware selection. The vboot support is comprised of the following pieces: 1. vboot_loader.c - this file contains the entry point, vboot_verify_firmware(), for romstage to call in order to perform vboot selection. The loader sets up all the data for the wrapper to use. 2. vboot_wrapper.c - this file contains the implementation calling the vboot API. It calls VbInit() and VbSelectFirmware() with the data supplied by the loader. The vboot wrapper is compiled and linked as an rmodule and placed in cbfs as 'fallback/vboot'. It's loaded into memory and relocated just like the way ramstage would be. After being loaded the loader calls into wrapper. When the wrapper sees that a given piece of firmware has been selected it parses firmware component information for a predetermined number of components. Vboot result information is passed to downstream users by way of the vboot_handoff structure. This structure lives in cbmem and contains the shared data, selected firmware, VbInitParams, and parsed firwmare components. During ramstage there are only 2 changes: 1. Copy the shared vboot data from vboot_handoff to the chromeos acpi table. 2. If a firmware selection was made in romstage the boot loader component is used for the payload. Noteable Information: - no vboot path for S3. - assumes that all RW firmware contains a book keeping header for the components that comprise the signed firmware area. - As sanity check there is a limit to the number of firmware components contained in a signed firmware area. That's so that an errant value doesn't cause the size calculation to erroneously read memory it shouldn't. - RO normal path isn't supported. It's assumed that firmware will always load the verified RW on all boots but recovery. - If vboot requests memory to be cleared it is assumed that the boot loader will take care of that by looking at the out flags in VbInitParams. Built and booted. Noted firmware select worked on an image with RW firmware support. Also checked that recovery mode worked as well by choosing the RO path. Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2854 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22cbmem: add vboot cmbem idAaron Durbin
The vboot firmware selection from romstage will need to pass the resulting vboot data to other consumers. This will be done using a cbmem entry. Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2851 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: dynamic cbmem requirementAaron Durbin
Dynamic cbmem is now a requirement for relocatable ramstage. This patch replaces the reserve_* fields in the romstage_handoff structure by using the dynamic cbmem library. The haswell code is not moved over in this commit, but it should be safe because there is a hard requirement for DYNAMIC_CBMEM when using a reloctable ramstage. Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2849 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: Unify arch/io.h and arch/romcc_io.hStefan Reinauer
Here's the great news: From now on you don't have to worry about hitting the right io.h include anymore. Just forget about romcc_io.h and use io.h instead. This cleanup has a number of advantages, like you don't have to guard device/ includes for SMM and pre RAM anymore. This allows to get rid of a number of ifdefs and will generally make the code more readable and understandable. Potentially in the future some of the code in the io.h __PRE_RAM__ path should move to device.h or other device/ includes instead, but that's another incremental change. Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2872 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21rmodule: correct ordering of bss clearingAaron Durbin
This patch fixes an issue for rmodules which are copied into memory at the final load/link location. If the bss section is cleared for that rmodule the relocation could not take place properly since the relocation information was wiped by act of clearing the bss. The reason is that the relocation information resides at the same address as the bss section. Correct this issue by performing the relocation before clearing the bss. Change-Id: I01a124a8201321a9eaf6144c743fa818c0f004b4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2822 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-21cbmem: dynamic cbmem supportAaron Durbin
This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21cbfs: Change false ERROR print to a WARNING.Shawn Nematbakhsh
Change "ERROR" to "WARNING" -- not finding the indicated file is usually not a fatal error. Change-Id: I0600964360ee27484c393125823e833f29aaa7e7 Signed-off-by: Shawn Nematbakhsh <shawnn@google.com> Reviewed-on: http://review.coreboot.org/2833 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21rmodule: add string functions to rmodules classAaron Durbin
The standard string functions memcmp(), memset(), and memcpy() are needed by most programs. The rmodules class provides a way to build objects for the rmodules class. Those programs most likely need the string functions. Therefore provide those standard functions to be used by any generic rmodule program. Change-Id: I2737633f03894d54229c7fa7250c818bf78ee4b7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2821 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: add caching loaded ramstage interfaceAaron Durbin
Instead of hard coding the policy for how a relocated ramstage image is saved add an interface. The interface consists of two functions. cache_loaded_ramstage() and load_cached_ramstage() are the functions to cache and load the relocated ramstage, respectively. There are default implementations which cache and load the relocated ramstage just below where the ramstage runs. Change-Id: I4346e873d8543e7eee4c1cd484847d846f297bb0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2805 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: cache relocated ramstage in RAMAaron Durbin
Accessing the flash part where the ramstage resides can be slow when loading it. In order to save time in the S3 resume path a copy of the relocated ramstage is saved just below the location the ramstage was loaded. Then on S3 resume the cached version of the relocated ramstage is copied back to the loaded address. This is achieved by saving the ramstage entry point in the romstage_handoff structure as reserving double the amount of memory required for ramstage. This approach saves the engineering time to make the ramstage reentrant. The fast path in this change will only be taken when the chipset's romstage code properly initializes the s3_resume field in the romstage_handoff structure. If that is never set up properly then the fast path will never be taken. e820 entries from Linux: BIOS-e820: [mem 0x000000007bf21000-0x000000007bfbafff] reserved BIOS-e820: [mem 0x000000007bfbb000-0x000000007bffffff] type 16 The type 16 is the cbmem table and the reserved section contains the two copies of the ramstage; one has been executed already and one is the cached relocated program. With this change the S3 resume path on the basking ridge CRB shows to be ~200ms to hand off to the kernel: 13 entries total: 1:95,965 2:97,191 (1,225) 3:131,755 (34,564) 4:132,890 (1,135) 8:135,165 (2,274) 9:135,840 (675) 10:135,973 (132) 30:136,016 (43) 40:136,581 (564) 50:138,280 (1,699) 60:138,381 (100) 70:204,538 (66,157) 98:204,615 (77) Change-Id: I9c7a6d173afc758eef560e09d2aef5f90a25187a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: Add cbmem_get_table_location()Aaron Durbin
When CONFIG_EARLY_CBMEM_INIT is selected romstage is supposed to have initialized cbmem. Therefore provide a weak function for the chipset to implement named cbmem_get_table_location(). When CONFIG_EARLY_CBMEM_INIT is selected cbmem_get_table_location() will be called to get the cbmem location and size. After that cbmem_initialize() is called. Change-Id: Idc45a95f9d4b1d83eb3c6d4977f7a8c80c1ffe76 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2797 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21romstage_handoff: provide common logic for setupAaron Durbin
The romstage_handoff structure can be utilized from different components of the romstage -- some in the chipset code, some in coreboot's core libarary. To ensure that all users handle initialization of a newly added romstage_handoff structure properly, provide a common function to handle structure initialization. Change-Id: I3998c6bb228255f4fd93d27812cf749560b06e61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2795 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGEAaron Durbin
This patch adds an option to build the ramstage as a reloctable binary. It uses the rmodule library for the relocation. The main changes consist of the following: 1. The ramstage is loaded just under the cmbem space. 2. Payloads cannot be loaded over where ramstage is loaded. If a payload is attempted to load where the relocatable ramstage resides the load is aborted. 3. The memory occupied by the ramstage is reserved from the OS's usage using the romstage_handoff structure stored in cbmem. This region is communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem. 4. There is no need to reserve cbmem space for the OS controlled memory for the resume path because the ramsage region has been reserved in #3. 5. Since no memory needs to be preserved in the wake path, the loading and begin of execution of a elf payload is straight forward. Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2792 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-03-21cbmem: add CBMEM_ID_ROMSTAGE_INFO idAaron Durbin
Introduce a new cbmem id to indicate romstage information. Proper coordination with ramstage and romstage can use this cbmem entity to communicate between one another. Change-Id: Id785f429eeff5b015188c36eb932e6a6ce122da8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2790 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-21rmodule: add ability to calculate module placementAaron Durbin
There is a need to calculate the proper placement for an rmodule in memory. e.g. loading a compressed rmodule from flash into ram can be an issue. Determining the placement is hard since the header is not readable until it is decompressed so choosing the wrong location may require a memmove() after decompression. This patch provides a function to perform this calculation by finding region below a given address while making an assumption on the size of the rmodule header.. Change-Id: I2703438f58ae847ed6e80b58063ff820fbcfcbc0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2788 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>