| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
Otherwise we have to worry about hand off between bootblock and
romstage. Too much complexity
Change-Id: I89bf8a229dba7e1330accadf9a732d831ebc4827
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3694
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I6b28bb95c7decbe3eed33b5b5a029bee48bbe403
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3691
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I1fef27c4a16ee4358ace8014a8d6e9fa92c4f790
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3728
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
All the additional work that needs to be done in EHCI BAR relocation
is independent of the hardware platform and was functionally identical
in all the copies removed.
When USBDEBUG is not selected, PCI EHCI controllers use standard
pci_dev_read_resources() call.
With USBDEBUG selected, PCI EHCI controller's device_operations
.read_resources is replaced with pci_ehci_read_resources() call,
which in turn will replace the device_operations .set_resources call.
The replacement for .set_resources reconfigures usbdebug driver side,
and calls the original .set_resources to configure hardware side.
Change-Id: I8e136a5da4efedf60b6dd7068c0488153efaaf8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3412
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
If EARLY_CONSOLE is not selected, the PCI function for EHCI
host controller must be configured in ramstage instead.
Change-Id: I20f7569f79484c744bc413450bfa139052f3580f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3383
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: Ie0507475f33d029d6e8ce59f138e0e7da5156d4f
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3339
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The qemu debugcon port returns 0xe9 on reads in case the device is
present. Use that for detection and write console output to the
port only in case the device is actually present.
Change-Id: I41aabcf11845d24004e4f795dfd799822fd14646
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3338
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ibcc0a94638c022a76cd3c2e3387af6e1ab757ccb
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3337
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add support for sending debug output to an I/O port.
It can be used together with QEMU's isa-debugcon driver to log the
coreboot output to a file. The port is configurable and defaults
to 0x402 which has established as the de facto standard. For example,
SeaBIOS+OVMF [1] use that one too.
[1] http://www.linux-kvm.org/page/OVMF
Open Virtual Machine Firmware
Change-Id: I0803f7fc70030242f80003e25c9449c37d71975e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3331
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
binary
This option has never had much if any use. It solved a problem over 10
years ago that resulted from an argument over the value or lack thereof
of including all the debug strings in a coreboot image. The answer is
in: it's a good idea to maintain the capability to print all messages,
for many reasons.
This option is also misleading people, as in a recent discussion, to
believe that log messges are controlled at build time in a way they are
not. For the record, from this day forward, we can print messages at all
log levels and the default log level is set at boot time, as directed by
DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and
if you are having trouble override it in CMOS and get more messages.
Besides, a quick glance shows it's always set to max (9 in this case) in
the very few cases (1) in which it is set.
Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3188
Tested-by: build bot (Jenkins)
|
|
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>
|
|
It makes much more sense to use CONFIG_USE_OPTION_TABLE instead
of CONFIG_HAVE_CMOS_DEFAULT. As we want to read the used
debug_level from our CMOS. This change makes it possible to
change log_debug via nvramtool and make use of the new
value after a reboot/poweroff.
CONFIG_HAVE_CMOS_DEFAULT does have an other meaning
Change-Id: I438dd01a2b4171dba2b73f2001511c71f4317725
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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>
|
|
On ARMv7 the console code can also be built into
the bootblock. Currently building the ARM targets
on a reasonably fast machine can fail, because
console.bootblock.o is attempted to build before
build.h is created. This patch adds a specific
rule for the bootblock variant of console.c, to
match the other variants so that the race condition
goes away.
Change-Id: I52e4242c66a02f011ef26b854aa50c2606a1f81f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2873
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This eliminates the use of do_div() in favor of using libgcc
functions.
This was tested by building and booting on Google Snow (ARMv7)
and Qemu (x86). printk()s which use division in vtxprintf() look good.
Change-Id: Icad001d84a3c05bfbf77098f3d644816280b4a4d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2606
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
Just a tiny mistake, but it made the console driver assume that
CMOS data isn't available.
Change-Id: I4e6f53e9ed59024de7b09333f82f0ce3235ef8f6
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/2323
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Revise console source file dependency (especially for EARLY_CONSOLE) and
interpret printk/console_init according to EARLY_CONSOLE setting (no-ops if
EARLY_CONSOLE is not defined).
Verified to boot on x86/qemu and armv7/snow. Disabling EARLY_CONSOLE correctly
stops romstage messages on x86/qemu (armv7/snow needs more changes to work).
Change-Id: Idbbd3a26bc1135c9d3ae282aad486961fb60e0ea
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2300
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Early console should always be allowed to be turned on / off (for generating
production and debug versions), and should not be enforced by "select" Kconfig
rule.
A new "DEFAULT_EARLY_CONSOLE" is introduced for devices to select if they
prefer early console output by default.
Verified Kconfig value on qemu/x86 (default y by CACHE_AS_RAM), snow/x86
(default y by EXYNOS5 config), and intel/jarrell (default n).
Change-Id: Ib1cc76d4ec115a302b95e7317224f1a40d1ab035
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2307
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
The console drivers (especially serial drivers) in Kconfig were named in
different styles. This change will rename configuration names to a better naming
style.
- EARLY_CONSOLE:
Enable output in pre-ram stage. (Renamed from EARLY_SERIAL_CONSOLE
because it also supports non-serial)
- CONSOLE_SERIAL:
Enable serial output console, from one of the serial drivers. (Renamed
from SERIAL_CONSOLE because other non-serial drivers are named as
CONSOLE_XXX like CONSOLE_CBMEM)
- CONSOLE_SERIAL_UART:
Device-specific UART driver. (Renamed from
CONSOLE_SERIAL_NONSTANDARD_MEM because it may be not memory-mapped)
- HAVE_UART_SPECIAL:
A dependency for CONSOLE_SERIAL_UART.
Verified to boot on x86/qemu and armv7/snow, and still seeing console
messages in romstage for both platforms.
Change-Id: I4bea3c8fea05bbb7d78df6bc22f82414ac66f973
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2299
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The do_div code has a nice optimization in it when it is called with
constants. The current highly generalized use of it defeats those
optimizations and causes trouble on ARM, resulting in a complex and
buggy code path.
Since we only need to print in bases 8, 10, and 16, do a minor
restructuring of the code so that we call do_div with constants.
If you need base 2, print in base 16 and do it in your head. :-)
This fixes an ongoing problem with ARM, will not harm X86, and will
help PPC should we ever want to support it again.
Plus, I don't have to ever try to understand the div64 assembly and where
it's going wrong :-)
Change-Id: I6a480011916eb0834e05c5bb10909d83330fe797
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2235
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
During the ARM port, disabling serial console became broken.
This patch fixes it.
Change-Id: I40460596073918a08c19bb9c991cada341cca940
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2136
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch makes pre-RAM serial init more generic, particularly for
platforms which do not necessarily need cache-as-RAM in order to use
the serial console and do not have a standard 8250 serial port.
This adds a Kconfig variable to set romstage-* for very early serial
console init. The current method assumes that cache-as-RAM should
enable this, so to maintain compatibility selecting CACHE_AS_RAM will
also select EARLY_SERIAL_CONSOLE.
The UART code structure needs some rework, but the use of ROMCC,
romstage, and then ramstage makes things complex.
uart.h now includes all .h files for all uarts. All 2 of them.
This is actually a simplifying change.
Change-Id: I089e7af633c227baf3c06c685f005e9d0e4b38ce
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2086
Tested-by: build bot (Jenkins)
|
|
Change-Id: I5b412678bb8993633b3a610315d298cb20c705f3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2011
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Because they use outb instructions, they are bound to fail
on non-PC80 systems like ARM.
Change-Id: I679ac6c0964c06c369cc90556529bb6f629d56f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1974
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
get_option() is used to get a config option (debug loglevel) from
CMOS. However, not all machines have CMOS, so define a dummy inline
function that will return an error code so the caller (console_init())
will use the default loglevel.
Change-Id: I6adf371d79164178f40a83f7608289a6a7673357
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1962
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This will omit the mc1468181rtc header if it is not needed. Currently
it contains a lot of inlined functions which depend on architecture-
specific IO.
Change-Id: I4ef1bc1362c159e0c780c3eade01af04f029f949
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1916
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This adds more configurability to POST codes. The current assumption
is that POST codes should be written to an IO port (e.g. LPC) if POST
codes are enabled. This changes the assumption so that POST codes can
be written to the serial console without being written to an IO port.
This enables POST codes by default using "default y" to avoid
changing current behavior.
Change-Id: I3db91c358ccb1557096983c4d07f70b2e872c4b3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1685
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Read out the post code from the previous boot and
log it if the code is not one of the expected values.
Test:
1) interrupt the boot of the system, this is easiest
with warm reset button when servo is attached
2) check the event log with mosys
65 | 2012-09-09 12:32:11 | Last post code in previous boot | 0x9d
Change-Id: Id418f4c0cf005a3e97b8c63de67cb9a09bc57384
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This will use 3 bytes of CMOS to keep track of the POST
code for the current boot while also leaving a record of
the previous boot.
The active bank is switched early in the bootblock.
Test:
1) clear cmos
2) reboot
3) use "mosys nvram dump" to verify that the first byte
contains 0x80 and the second byte contains 0xF8
4) powerd_suspend and then resume
5) use "mosys nvram dump" to verify that the first byte
contains 0x81 and the second byte contains 0xFD
Change-Id: I1ee6bb2dac053018f3042ab5a0b26c435dbfd151
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some mainboards have really nice capabilities for posting, beyond
simple POST cards. Further, some can not use a POST card. This
change defines a weak symbol (mainboard_post) that can be overridden
by a real mainboard_post function.
If, for example, you'd like to do something fancy before the payload starts,
you can add this to mainboard.c:
void mainboard_post(u8 value)
{
switch(value){
case POST_TIME_TO_PARTY: some_fancy_lights();
break;
}
}
Maybe the post function should be an entry in the device. We're beginning to over-use
weak symbols.
BUG=None
TEST=Build and boot a google chromebook. Observe that it still works. Use it to drive
some pretty lights.
Change-Id: I3512d2ec34a66c747287191851c3f68b6a7cc1b2
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1397
Tested-by: build bot (Jenkins)
|
|
EHCI debug allows to send message with 8 bytes length, but
we're only sending one byte in each transaction. Buffer up
to 8 bytes to speed up debug output.
Change-Id: I9dbb406833c4966c3afbd610e1b13a8fa3d62f39
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1357
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
|
|
This is used by the SPI driver and ELOG.
It requires SMM TSEG and a _heap/_eheap region defined in the
linker script. The first time malloc is called in SMM the
start and end pointers to the heap region will be relocated
for the TSEG region.
Enable SPI flash and ELOG in SMM and successfully
allocate memory. The allocated addresses are verified
to be sure they are within the TSEG heap region:
smm.elf:00014000 B _eheap
smm.elf:00010000 B _heap
TSEG base is 0xad000000
Memory allocated in ELOG:
ELOG: MEM @0xad018030
Change-Id: I5cca38e4888d597cbbfcd9983cd6a7ae3600c2a3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1312
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The oxpcie ramstage code calls uartmem_init after the PCI memory
allocation, but hte function was static and didn't have a prototype.
Change-Id: Iabc1a3d248aeaed29aaaa22504defac97c572326
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1285
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The SPI drivers from u-boot make heavy use of %zu/%zd (size_t/ssize_t).
Implement this in our printk implementation so we get useful output.
Change-Id: I91798ff4f28b9c3cd4db204c7ec503596d247dcd
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1043
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Traditionally coreboot's SMM handler runs in ASEG (0xa0000),
"behind" the graphics memory. This approach has two issues:
- It limits the possible size of the SMM handler (and the
number of CPUs supported in a system)
- It's not considered a supported path anymore in newer CPUs.
Change-Id: I9f2877e46873ab2ea8f1157ead4bc644a50be19e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Acked-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/842
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
- cash -> Cache
- make the new size of the cbmem console buffer the default
Change-Id: Ia906077257e93622ad56bc54a42f8184ade78b29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The appropriate Makefiles are modified to include the required
source code in compilation.
Change-Id: I91842b1ba0f89d611d3249b63c020a2713a9124f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/722
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The new added code is compiled in when the CBMEM_CONSOLE config
flag is enabled.
Change-Id: Ifd1f492ce6321412a014333babbc5b3f14635988
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/721
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
Some experiments have demonstrated that total amount of text
generated by coreboot console when BIOS_SPEW level is enabled
exceeds 40KB.
Console output generated before DRAM is initialized can exceed
2KB. This patch introduces the new configuration option and
assigns adequate default values to cache based and DRAM based
console buffers.
BUG=chrome-os-partner:4200
TEST=manual
. run the following commands in the root directory
cp config.stumpy .config
make menuconfig
. enable the new option (Console->Send console output to a CBMEM buffer)
. save the configuration
Observe the following settings added to the config:
+CONFIG_CONSOLE_CBMEM=y
+CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0xae00
+CONFIG_CONSOLE_CAR_BUFFER_SIZE=0xc00
Change-Id: I209603f516244ae136631e6281ba21ebc6fb1710
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/5855
Tested-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/718
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Because it's included everywhere anyways.
Change-Id: I99a9e6edac08df57c50ef3a706fdbd395cad0abc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/691
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Also mark the corresponding lint test stable.
Change-Id: Ib7c9ed88c5254bf56e68c01cdbd5ab91cd7bfc2f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
trivial change in src/console/Kconfig
Change-Id: Ib6bb4ccfabaa3af18b48a23a51a576b872d807a8
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/505
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
