summaryrefslogtreecommitdiff
path: root/src/lib/cbmem_console.c
AgeCommit message (Collapse)Author
2013-11-30CBMEM console: increase temporary buffer size for non-dynamic CBMEMKyösti Mälkki
Make temporary buffer allocation equal with the allocation in CBMEM and let copy_console_buffer() handle possible truncation. When not using dynamic CBMEM the CBMEM area is initialized late in the ramstage and should be able to hold almost as many characters as the CBMEM can hold. We have seen 40000 was not always enough with logging level set to spew, new default size is 0x10000. Change-Id: If4b143fdf807e28b6766b8b99db5216b767948d5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4295 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-11-30cbmem console: reduce temporary buffer size for dynamic CBMEMStefan Reinauer
When using dynamic CBMEM the CBMEM area is initialized before entering ram stage, and so we need a way smaller temporary buffer for the CBMEM console during early bits of ram stage. In practice around 256 bytes are needed, but keep the buffer at 1k so we make sure we don't run out. TEST=Boot tested on pit BRANCH=none BUG=none Change-Id: I462810b7bafbcc57f8e5f9b1d1f38cfdf85fa630 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/168575 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [km: cherry-pick 7fd1bbc0 from chromium git] Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4293 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-11-30CBMEM console: Prevent buffer overrunKyösti Mälkki
Make sure memcpy target and a possible message telling log was truncated stay within the allocated region for CBMEM console. This fixes observed CBMEM corruption on platforms that do not use CBMEM console during romstage. Those platforms will need an additional fix to reset cursor position to zero on s3 resume. Change-Id: I76501ca3afc716545ca76ebca1119995126a43f8 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4292 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Idwer Vollering <vidwer@gmail.com> Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-10-13Rename cpu/x86/car.h to arch/early_variables.hStefan Reinauer
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)
2013-09-21CBMEM: Always select CAR_MIGRATIONKyösti Mälkki
If romstage does not make cbmem_initialize() call, linker should optimize the code for CAR migration away. This simplifies design of CBMEM console by a considerable amount. As console buffer is now migrated within cbmem_initialize() call there is no longer need for cbmemc_reinit() call made at end of romstage. Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3916 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-21CBMEM console: Support late initKyösti Mälkki
It is not compulsory to have CBMEM console initialised in romstage, so try add the CBMEM table entry again in ramstage, if not found. Change-Id: I96ab502df7f05d6bf1d6e6fa84d395ef6306b525 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3915 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> 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-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-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>
2012-03-29Add infrastructure for global data in the CAR phase of bootGabe Black
The cbmem console structure and car global data are put in their own section, with the cbmem console coming after the global data. These areas are linked to be where CAR is available and at the very bottom of the stack. There is one shortcoming of this change: The section created by this change needs to be stripped out by the Makefile since leaving it in confuses cbfstool when it installs the stage in the image. I would like to make the tools link those symbols at the right location but leave allocation of that space out of the ELF. Change-Id: Iccfb99b128d59c5b7d6164796d21ba46d2a674e0 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/727 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-29CBMEM CONSOLE: Add CBMEM console driver implementation.Vadim Bendebury
The CBMEM console driver saves console output in a CBMEM area, which then is made available to Linux applications for perusing. There are some system limitations which need to be worked around to achieve this goal: - some console traffic is generated before DRAM is initialized, leave alone CBMEM initialized. - after the RAM based stage starts, a lot of traffic is generated before CBMEM is initialized. As a result, the console log lives in three different places - the bottom of the cache as RAM space, the CBMEM buffer (where it is expected to be) and a static buffer used early in the RAM stage. When execution starts (in the cache as RAM mode), the console buffer is allocated at the bottom of the cache as RAM memory address range. Once DRAM is initialized, the CBMEM structure is initialized, and then the console buffer contents are copied from the bottom of the cache as RAM space into the CBMEM area right before the cache as RAM mode is disabled. The src/lib/cbmem_console.c:cbmemc_reinit() takes care of the copying. At this point the cache as RAM memory is about to be disabled, but the ROM stage is still going generating console output. To make sure this output is not lost, cbmemc_reinit() saves the new buffer address at a fixed location (0x600 was chosen for this), and the actual "printing" function checks to see if the RAM is already initialized (the stack is in RAM), and if so, gets the console buffer pointer from this location instead of using the cache as RAM address. When the RAM stage starts, a static buffer is used to store the console output, as the CBMEM buffer location is not known. Then, when CBMEM is reinitialized, cbmemc_reinit() again takes care of the copying. In case the allocated buffers are not large enough, the excessive data is dropped, and the copying routine adds some text to the output buffer to indicate that there has been data lost and how many characters were dropped. Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/719 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>