The detail block may contain timing descriptor, or other fields like monitor
descriptor, so we should return 1 in detailed_block function when a valid
structure is found, otherwise for any EDID containing monitor descriptor we will
see following error messages:
EDID block does not conform at all!
Detailed blocks filled with garbage
Change-Id: Ib4e91d648741e5b54a558d53a1152273c7341427
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193002
(cherry picked from commit a1f212d6aaa14d5f795beeabdb8b7b8a79578c33)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6997
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ASCII Data String in EDID Monitor Descriptor (3.10.3) is "Stored as ASCII,
code page #437" and may contain special characters like '-'. The isalnum check
should be removed.
Also, the "Monitor Name" (0xfc) does not need to always end with 0Ah, so the
name_descriptor_terminated should be replaced by has_valid_string_termination.
Change-Id: I12a670237e12577fc971c0fbd9b2a61c82040ad3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193001
(cherry picked from commit 671f82fd5963e32e72d3886aa242cb3e8519f226)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6996
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When parsing "extensions", we should skip the first EDID (main) block and start
from offset 128 (EDID may have only main block, so an EDID without any
extension is fine) because the header format for main block and extensions are
different.
Without this we will see "Unknown extension block" on all EDIDs, and seeing an
error (1) return value for EDIDs without extension.
Also, after the first "unknown" error is fixed, we can now collect all return
values from parse_extension, and return an error when any of the extensions are
wrong (not just last one).
Change-Id: I0ee029ac8ec6800687cd7749e23989399e721109
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193011
(cherry picked from commit fdf0cc2e9573c19b550fa2b5e4e06337b114f864)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6995
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some lines in decode_edid have incorrect indent levels.
Change-Id: Icc9cb57ff8dd2e2056599b3dc733fe5ac4e41c16
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193010
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 3211ac0a29a037c5414f9ed1736c8f7822ad116b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6994
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds stub implementations of exception_init() to all archs
so that it can be called from src/lib/hardwaremain.c. It also moves/adds
all other invocations of exception_init() (which needs to be rerun in
every stage) close to console_init(), in the hopes that it will be less
likely overlooked when creating future boards. Also added (an
ineffective) one to the armv4 bootblock implementations for consistency
and in case we want to implement it later.
Change-Id: Iecad10172d25f6c1fc54b0fec8165d7ef60e3414
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176764
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 2960623f4a59d841a13793ee906db8d1b1c16c5d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6884
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Print a space after a full stop.
Change-Id: Ic7d0522ae35079b64ce61956d06ea59843ef9d80
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176756
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit c7ff63038b6888b17a96783b1169c5f335022b24)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6878
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
Old-Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
(cherry picked from commit 8cdaf73e3602e15925859866714db4d5ec6c947d)
snow: Fix a typo in devicetree.cb that was breaking the snow build.
A typo in a recent change broke the snow build.
Old-Change-Id: I93074e68eb3d21510d974fd8e9c63b3947285afd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171014
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 154876c126a6690930141df178485658533096d2)
Squashed a fix into the initial patch and updated nehalem/gma.c
to have a non-static gtt_poll.
Change-Id: I2f4342c610d87335411da1d6d405171dc80c1f14
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6657
Tested-by: build bot (Jenkins)
Some drivers (like the I2C TPM driver) call mdelay instead of
udelay. While it's a shame that these chips are so slow, the
overhead of having those functions available in romstage is
minimal.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792
Reviewed-on: https://chromium-review.googlesource.com/167542
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 7083b6b843d803bd4ddbd8a5aaf9c5c05bad2044)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6531
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds a mechanism to set aside a region of cache-coherent
(i.e. usually uncached) virtual memory, which can be used to communicate
with DMA devices without automatic cache snooping (common on ARM)
without the need of explicit flush/invalidation instructions in the
driver code.
This works by setting aside said region in the (board-specific) page
table setup, as exemplary done in this patch for the Snow and Pit
boards. It uses a new mechanism for adding board-specific Coreboot table
entries to describe this region in an entry with the LB_DMA tag.
Libpayload's memory allocator is enhanced to be able to operate on
distinct types/regions of memory. It provides dma_malloc() and
dma_memalign() functions for use in drivers, which by default just
operate on the same heap as their traditional counterparts. However, if
the Coreboot table parsing code finds a CB_DMA section, further requests
through the dma_xxx() functions will return memory from the region
described therein instead.
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
(cherry picked from commit d142ccdcd902a9d6ab4d495fbe6cbe85c61a5f01)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6622
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide functionality to create dynamic classes based on program name and
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class. Also, compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/6426
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The CBFS core checks the result of a media->map() operation in multiple
places for CBFS_MEDIA_INVALID_MAP_ADDRESS, suggesting that this is a
valid response. However, it ironically fails to do so when actually
mapping the CBFS file itself, which can fail on buffer-constrained
systems since the size is much larger than when mapping metadata. This
patch adds a check with an error message and a NULL pointer return for
that case to make it easier to understand this condition.
Change-Id: Icae3dd20d3d111cdfc4f2dc6397b52174349b140
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174951
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 63f2c4465f9633a637186e69bc3862d5413106ac)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6537
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A bootblock overwalk was occuring when deriving the actual
length, the bootblock size was not taken into account and bootblock
size was not aligned.
Resolved merge conflict.
Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65989
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Steve Sherk <ssherk70@gmail.com>
Tested-by: Steve Sherk <ssherk70@gmail.com>
(cherry picked from commit 20b0ba479b01755fbdc7f3dd9214e8af923402ba)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6539
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There are three coreboot table tags that all define some kind of memory
region, and each has their own homologous struct. I'm about to add a
fourth so I'll just clean this up and turn it into a generic struct
lb_range instead.
Change-Id: Id148b2737d442e0636d2c05e74efa1fdf844a0d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167154
(cherry picked from commit 22d82ffa3f5500fbc1b785e343add25e61f4f194)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6456
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
While vendor specific extension blocks are mostly opaque to us,
they're not exactly "unknown".
Change-Id: I9136c04d12045ad13ef4f942c0814c4df88bdf6b
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6563
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Architecture provides a function for thread stack base, thread code uses it.
Build and boot tested on Falco with multitasking on and off.
Change-Id: I5016fab47f9954379acf7702ac7965b0a70c88ed
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66578
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit 3c6afef30c1a0ad6fba0fb76acc792184d924247)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6513
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The libgcc runtime workarounds found in gcc.c are not needed for
compiler-rt used by the Clang toolchain. Stop gcc.c from sneaking into
Clang builds while processing boards that use SMM code.
Change-Id: I51e8d517784721d28b4d951bd0bebc8b52682a8e
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6121
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
This GCC specific workaround of wrapping of libgcc runtime symbols with
gcc.c is not nessary with libcompiler-rt linkage.
Change-Id: I50a2bc99d97f68a2ad2b51a92ea0e7086bab35fe
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5812
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5032
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Allow ramstage cache to be used from ramstage proper. Also
add a helper function for checking validity of ramstage
cache structure.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: If1f2ad1bcf64504b42e315be243a12432b50e3d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179775
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5011
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
There's a slew of ports required to initialize baytrail's
perf and power values. Therefore, add the necessary
functionality in the iosf module as well as the reg_script
library.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted.
Change-Id: Id45def82f9b173abeba0e67e4055f21853e62772
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179748
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5007
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The reg_script library has proven to be useful. It's
also shown that many scripts operate on devices. However,
certain code paths run the same script on multiple,
but different, devices. In order to make that easier
introduce reg_script_run_on_dev() which takes a device
as a parameter. That way, chained reg_scripts are not
scrictly needed to run the same script on multiple devices.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I273499af4d303ebd7dc19e9b635ca23cf9bb2225
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179540
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5005
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Leave it under BOOTMODE_STRAPS to control whether these have
any functional meaning on the build.
Change-Id: Ieb59aa7ab4b1e8da6a1002e7a8e5462eb7988d35
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5643
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Add the LPSS IOSF port access to reg_script. This is
going to be used by baytrail.
BUG=chrome-os-partner:23790
BRANCH=None
TEST=Buit.
Change-Id: I0367acdb584f2de0bb871b136042b57fe6b7ec90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176423
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4968
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
This required changing value/mask types to uint64_t.
Another option would be to use id field to select low or high
32 bits of the MSR and set them independently.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi
Change-Id: Ied9998058a8035bf3f003185236f3be3e0df7fc9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176304
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4951
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
In the signature of the function `hexdump32()` it does not make sense to
represent a length, assumed to be positive, as a signed integer.
With this change, it is no longer necessary to cast a pointer to
unsigned long when passing it to `hexdump32()`.
The same change for the function `hexdump()` was done in commit
3dd0e72d [1].
lib/hexdump: Take const void * and size_t as arguments
[1] http://review.coreboot.org/4575
Change-Id: Id97f5daff95f94e862ee8b5be896a6629b125a13
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5646
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The coding style requires to use tabs for indentation and not spaces.
Use GNU indent 2.2.11 with the switch `-linux` to indent the file,
which also removes the empty lines at the end of the file.
Change-Id: I874f178e50d7558d3299026aec2771ad45f88d8e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4576
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
A global flag oprom_is_loaded was used to indicate to
U-boot that VGA option ROM was loaded and run, or that
native VGA init was completed on GMA device.
Implement this feature without dependency to CHROMEOS option
and replace use of global variable oprom_is_loaded with call
to gfx_get_init_done().
Change-Id: I7e1afd752f18e5346dabdee62e4f7ea08ada5faf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4309
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names (bootblock, romstage) and to allow any
Makefile rule generalization, required for patches to be submitted later.
Change-Id: Ib66e43b7e17b9c48b2d099670ba7e7d857673386
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5567
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Depending on the compiler options, subsections of the form
of .section.subsection could be generated. Therefore, include
those subsections for .bss, .sbss, and .data.
Change-Id: I80dd64d8c62e7bc449ee2bbc0a22a941777e2ea6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5407
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This framework was only available in ramstage. So we had to define
console output functions separately for bootblock, romstage and SMM.
Follow-up patches will re-enable all the consoles removed here,
in a more flexible fashion, and with less lines-of-code and copy-paste.
Also the driver list is not in a well-defined order and some of the
loops could exit without visiting all drivers.
NOTE: This build has no console in ramstage.
Change-Id: Iaddc495aaca37e2a6c2c3f802a0dba27bf227a3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5337
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Option DRIVERS_UART builds with support for UART hardware.
Option CONSOLE_SERIAL enables the console output for UART.
Those x86 boards that do not have serial port on SuperIO should select
NO_UART_ON_SUPERIO to disable 8250 UART for the default configuration.
Removes:
CONSOLE_SERIAL_UART
HAVE_UART_IO_MAPPED
HAVE_UART_MEMORY_MAPPED
Renames:
CONSOLE_SERIAL8250 -> DRIVERS_UART_8250IO
CONSOLE_SERIAL8250MEM -> DRIVERS_UART_8250MEM
Change-Id: Id3afa05f85c0d6849746886db8b6c2ed6c846b61
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5311
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Also fixes the reported baudrate to take get_option() into account.
Change-Id: Ieadad70b00df02a530b0ccb6fa4e1b51526089f3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5310
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Use of CAR_GLOBAL is not safe after CAR is torn down, unless the
board properly implements EARLY_CBMEM_INIT.
Flag vulnerable boards that only do cbmem_recovery() in romstage on S3
resume and implementation with Intel FSP that invalidates cache before
we have a chance to copy the contents.
Change-Id: Iecd10dee9b73ab3f1f66826950fa0945675ff39f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5419
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.
Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.
Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Fixing the location of the ram oops buffer can lead to certain
kernel and boot loaders being confused when there is a ram
reservation low in the address space. Alternatively provide
a mechanism to allocate the ram oops buffer in cbmem. As cbmem
is usually high in the address space it avoids low reservation
confusion.
The patch uncondtionally provides a GOOG9999 ACPI device with
a single memory resource describing the memory region used for
the ramoops region.
BUG=None
BRANCH=baytrail,haswell
TEST=Built and booted with and w/o dynamic ram oops. With
the corresponding kernel change things behave correctly.
Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5257
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order for userland to create rmodules the common code should be
shareable. Therefore, convert the short u<width> name types to the
posix uint<width>_t types. Additionally, move the definition of the
header structure to a new rmodule-defs.h header file so that userland
can include that without pulling in the coreboot state.
Change-Id: I54acd3bfd8c207b9efd50a3b6d89efd5fcbfc1d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5363
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Boot speeds can be sped up by mirroring the payload into
main memory before doing the actual loading. Systems that
would benefit from this are typically Intel ones whose SPI
are memory mapped. Without the SPI being cached all accesses
to the payload in SPI while being loaded result in uncacheable
accesses. Instead take advantage of the on-board SPI controller
which has an internal cache and prefetcher by copying 64-byte
cachelines using 32-bit word copies.
Change-Id: I4aac856b1b5130fa2d68a6c45a96cfeead472a52
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5305
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is based on the RCBA configuration setup from haswell.
It handles PCI, BARs, IO, MMIO, and baytrail-specific IOSF.
I did not extend it to handle MSR yet but that would be another
potential register type.
There are a number of approaches to this kind of thing, but in the
end they have a lot of switch statements and a mass of #defines.
I'm not particularly set on any of the details so comments welcome.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=emerge-rambi chromeos-coreboot-rambi
Change-Id: Ib873936ecf20fc996a8feeb72b9d04ddb523211f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175206
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4923
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This menu may become a bit more complicated with addition of
new USB hardware so move it out of console/.
Change-Id: Ieb330675b9227a3e53d093f7c2b5a65e3842dc82
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5307
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
NOTE: UART base for SMM continues to be broken, as it does not use
the address resource allocator has assigned.
Change-Id: I79f2ca8427a33a3c719adfe277c24dab79a33ef3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5235
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Do not pull in console hw-specific prototypes everywhere
with console.h as those are not needed for higher levels.
Move prototypes for UARTs next to other consoles.
Change-Id: Icbc9cd3e5bdfdab85d7dccd7c3827bba35248fb8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5232
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Divisor is a function of requested baudrate, platform-specific
reference clock and amount of oversampling done on the UART reference.
Calculate this parameter with divisor rounded to nearest integer.
When building without option_table or when there is no entry for
baud_rate, CONFIG_TTYS0_BAUD is used for default baudrate.
For OxPCIe use of 4 MHz for reference was arbitrary giving correct
divisor for 115200 but somewhat inaccurate for lower baudrates.
Actual hardware is 62500000 with 16 times oversampling.
FIXME: Field for baudrate in lb_tables is still incorrect.
Change-Id: I68539738469af780fadd3392263dd9b3d5964d2d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5229
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Do not guard the file by CONFIG_CONSOLE_SERIAL8250 or
CONFIG_CONSOLE_SERIAL8250MEM or CONFIG_CONSOLE_SERIAL.
Don't do indirect includes for <uart8250.h>.
The config-specific options are already properly guarded, and there
is no need to guard the register and bit definitions.
Change-Id: I7528b18cdc62bc5c22486f037e14002838a2176e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4585
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
s_srcaddr is uninitialized in the BSS section, leading to a
garbage valued operand on the LHS of a '<' on line 383.
Change-Id: Ie4fec91b09c70fb1d91ad3918ac3f60653fa1d83
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5314
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The get_lb_mem() is no longer used. Therefore, remove it.
Change-Id: I2d8427c460cfbb2b7a9870dfd54f4a75738cfb88
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5304
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Instead of packing and unpacking entries in lb_mem use
the bootmem infrastructure for performing sanity checks
during payload loading.
Change-Id: Ica2bee7ebb0f6bf9ded31deac8cb700aa387bc7a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5303
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The write_coreboot_table() in coreboot_table.c was already using
struct memrange for managing and building up the entries that
eventually go into the lb_memory table. Abstract that concept
out to a bootmem memory map. The bootmem concept can then be
used as a basis for loading payloads, for example.
Change-Id: I7edbbca6bbd0568f658fde39ca93b126cab88367
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5302
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The selfboot() function relied on global variables
within the selfboot.c compilation unit. Now that the
bounce buffer is a part of struct payload use a new
architecture-specific arch_payload_run() function
for jumping to the payload. selfboot() can then be
removed.
Change-Id: Icec74942e94599542148561b3311ce5096ac5ea5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5300
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to break the dependency on selfboot for jumping to
payload the bounce buffer location needs to be communicated.
Therefore, add the bounce buffer to struct payload.
Change-Id: I9d9396e5c5bfba7a63940227ee0bdce6cba39578
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5299
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to encapsulate more data for self loading use struct
payload as the type. That way modifications to what is needed
for payload loading does not introduce more global variables.
Change-Id: I5b8facd7881e397ca7de1c04cec747fc1dce2d5f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5298
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The selfboot() routine was perfoming most of the common teardown
and stack checking infrastructure. Move that code into
payload_run() to prepare removal of the selfboot() function.
Change-Id: I29f2a5cfcc692f7a0fe2656cb1cda18158c49c6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5297
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
A payload can be loaded either from a vboot region or from cbfs.
Provide a common place for choosing where the payload is loaded
from. Additionally, place the logic in the 'loaders' directory
similarly to the ramstage loader infrastructure.
Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5296
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
With the recent improvement 3d6ffe76f8,
speedup by CACHE_ROM is reduced a lot.
On the other hand this makes coreboot run out of MTRRs depending on
system configuration, hence screwing up I/O access and cache
coherency in worst cases.
CACHE_ROM requires the user to sanity check their boot output because
the feature is brittle. The working configuration is dependent on I/O
hole size, ram size, and chipset. Because of this the current
implementation can leave a system configured in an inconsistent state
leading to unexpected results such as poor performance and/or
inconsistent cache-coherency
Remove this as a buggy feature until we figure out how to do it properly
if necessary.
Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Decoding EDID doesn't yet mean that gfx mode is used.
Change-Id: Icedd36f26877754f34dd59233cce72271d7f0b19
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5269
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
We should not have x86 specific includes in lib/.
Change-Id: I18fa9c8017d65c166ffd465038d71f35b30d6f3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5156
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Needs printk and is not a console core function.
Change-Id: Id90a363eca133af4469663c1e8b504baa70471e0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5155
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Be more conservative and only add VGA devices' prefetchable
resources as write-combining in the address space. Previously
all prefetchable memory was added as a write-combining memory
type. Some hardware incorrectly advertises its BAR as
prefetchable when it shouldn't be.
A new memranges_add_resources_filter() function is added
to provide additional filtering on device and resource.
Change-Id: I3fc55b90d8c5b694c5aa9e2f34db1b4ef845ce10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5169
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
Unused and hard-coded to use uart8250 on IO.
Change-Id: I3f84c50039a450a2ae97a5fd2af89992f8567e6c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5137
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Also relocate and split header files, there is some interest
for EHCI debug support without PCI.
Change-Id: Ibe91730eb72dfe0634fb38bdd184043495e2fb08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The memranges_update_tag() function replaces all instances
that are tagged with old_tag and update to new_tag. This
can be helpful in the MTRR code by adjusting the address
space if certain memory types cause the MTRR usage to
become too large.
Change-Id: Ie5c405204de2fdd9fd1dd5d6190b223925d6d318
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5150
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Flash prefers 32-bit sequential access. On some platforms ROM is
not cached due to i.a. MTRR shortage. Moreover ROM caching is not
currently enabled by default. With this patch payload decompression
is sped up by theoretical factor of 4.
Test on X201, with caching disabled:
Before:
90:load payload 4,470,841 (24,505)
99:selfboot jump 6,073,812 (1,602,971)
After:
90:load payload 4,530,979 (17,728)
99:selfboot jump 5,103,408 (572,429)
Change-Id: Id17e61316dbbf73f4a837bf173f88bf26c01c62b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5144
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This will make it possible for payloads to find the ACPI
NVS region which is needed to get base addresses for devices
that are in ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: Ia67b66ee8bd45ab8270444bbb2802080d31d14eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179849
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5015
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4897
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
In order to identify the ram used in cbmem for
reference code blobs add common ids to be consumed
by downstream users.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with ref code support. Noted reference
code entries in cbmem.
Change-Id: Iae3f0c2c1ffdb2eb0e82a52ee459d25db44c1904
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4896
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Checksum is already in cmos_layout.bin. No need to add it twice
Change-Id: I6d12f35fd8ff12eee9a17365bbfab38845c09574
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4829
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This function does not really initialize anything, but only
checks for the TOC.
Change-Id: I9d100d1823a0b630f5d1175e42a6a15f45266de4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4669
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The replacement function confirms CBMEM TOC is wiped clean on power
cycles and resets. It also introduces compatibility interface to ease
up transition to DYNAMIC_CBMEM.
Change-Id: Ic5445c5bff4aff22a43821f3064f2df458b9f250
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4668
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Representing a memory location as an unsigned long is specific to
32-bit architectures. It also doesn't make sense to represent a length
assumed to be positive as a signed integer. With this change, it is no
longer necessary to cast a pointer to unsigned long when passing it to
hexdump.
Change-Id: I641777d940ceac6f37c363051f1e9c1b3ec3ed95
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4575
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On x86, log2() is defined as an inline function in arch/io.h. This is
a remnant of ROMCC, and forced us to not include clog2.c in romstage.
As a result, romstage on ARM has no log2().
Use the inline log2 only with ROMCC, but otherwise, use the one in
clog2.c.
Change-Id: Ifef2aa0a7b5a1db071a66f2eec0be421b8b2a56d
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CBMEM console buffer size is adjustable in menuconfig, but this would
not correctly adjust the overall allocation made for CBMEM.
HIGH_MEMORY_SIZE is aligned to 64kB and definitions are moved down in
the header file as HIGH_MEMORY_SIZE is not used with DYNAMIC_CBMEM.
Try to continue boot even if CBMEM cannot be created. This error would
only occur during development of new ports anyways and more log output
is better.
Change-Id: I4ee2df601b12ab6532ffcae8897775ecaa2fc05f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4621
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This function was for logging only, but we have both base and size
already logged elsewhere.
Change-Id: Ie6ac71fc859b8fd42fcf851c316a5f888f828dc2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Handler is ACPI/x86 specific so move details out of cbmem code.
With static CBMEM initialisation, ramstage will need to test for
S3 wakeup condition so publish also acpi_is_wakeup().
Change-Id: If591535448cdd24a54262b534c1a828fc13da759
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4619
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This includes the new dp code, which is better, and the fimd code,
which is changed and improved. We took the chance to remove un-needed
files, and also to remove some foolish u-boot habits, but not all of
them. That will take time.
With these changes we get graphics.
Since the only mainboards we have with 16 bit graphics are 5:6:5,
adjust edid.c to just use that format. If at some future time we need
4:4:4, which seems unlikely, we'll need to add a function to adjust
the lb_framebuffer. Note that you can't just divine this from the EDID,
as the graphics pipe format need not match the actual final format used.
The EDID reading works. We've been requested to support hard-coded
EDIDs and that will come in the next revision. Currently the hard-coded
EDID is ignored for testing.
Change-Id: Ib4d06dc3388ab90c834f94808a51133e5b515a4d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64240
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Works fine with all three panels with the change of 6 bits per color.
Change-Id: Ia47d152e62d1879150d8cf9a6657b62007ef5c0e
Reviewed-on: https://gerrit.chromium.org/gerrit/63762
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4402
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- prints hex and ascii
- detects duplicate all zero lines
Change-Id: I557fed34f0f50ae256a019cf893004a0d6cbff7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62655
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4392
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
... based on the EDID detailed timing values for
pixel_clock and link_clock.
Two undocumented registers 0x6f040 and 0x6f044 correspond to link_m and link_n
respectively. Other two undocumented registers 0x6f030 and 0x6f034 correspond
to data_m and data_n respectively.
Calculations are based on the intel_link_compute_m_n from linux kernel.
Currently, the value for 0x6f030 does not come up right with our calculations.
Hence, set to hard-coded value.
Change-Id: I40ff411729d0a61759164c3c1098504973f9cf5e
Reviewed-on: https://gerrit.chromium.org/gerrit/62915
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4336
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was used by Ron 13ys ago and was never used again
ever since.
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4256
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Do not directly check the return value of get_option, but instead compare
the returned value against a CB_CMOS_ error code, or against CB_SUCCESS.
Change-Id: I2fa7761d13ebb5e9b4606076991a43f18ae370ad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4266
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
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>
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>
Now that there is a clearly defined boot state machine
we can add some useful post codes to indicate the current
point in the state machine by having it log a post code
before the execution of each state.
This removes the currently defined POST codes that were
used by hardwaremain in favor of a new contiguous range
that are defined for each boot state.
The reason for this is that the existing codes are mostly
used to indicate when something is done, which is confusing
for actual debug because POST code debugging relies on knowing
what is about to happen (to know what may be at fault) rather
than what has just finished.
One additonal change is added during device init step as this
step often does the bulk of the work, and frequently logs POST
codes itself. Therefore in order to keep better track of what
device is being initialized POST_BS_DEV_INIT is logged before
each device is initialized.
interrupted boot with reset button and
gathered the eventlog. Mosys has been extended to
decode the well-known POST codes:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58106
Reviewed-on: http://review.coreboot.org/4231
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When testing Ron's patch on qemu I found out that fill_lb_framebuffer
overwrites size and tag fields. We need either to fix/check all
fill_lb_framebuffer implementations or write tag/size after fill_lb_framebuffer.
I prefer later as it's more robust.
Change-Id: I98f5bac14f65fb4d990cb21426d402b27f2e8a48
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4263
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
cbfs used u32 in a number of cases where uintptr_t was
correct. This change builds for both 64-bit and 32-bit
boards.
Change-Id: If42c722a8a9e8d565d3827f65ed6c2cb8e90ba60
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4037
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
The code is wrong (it's calling ntohl on an entry point that is actually
already le due to an old cbfs bug) and nothing calls it any more anyway.
Change-Id: Ief2c33faf99e3d2fc410524a5aae7bde378f088b
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4090
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Many chipset devices require additional configuration after
device init. It is not uncommmon for a device early in the devicetree
list to need to change a setting after a device later in the tree does
PCI init. A final function call has been added to device ops to handle
this case. It is called prior to coreboot table setup.
Another problem that is often seen is that the chipset or mainboard
need to do some final cleanup just before loading the OS. The chip
finalize has been added for this case. It is call after all coreboot
tables are setup and the payload is ready to be called.
Similar functionality could be implemented with the hardwaremain
states, but those don't fit well in the device tree function pointer
structure and should be used sparingly.
Change-Id: Ib37cce104ae41ec225a8502942d85e54d99ea75f
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4012
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The main usbdebug file lib/usbdebug.c was removed from romstage
build with commit f8bf5a10 but the chipset-specific parts were not,
leading to unresolved symbol errors for AMD platforms.
Add a silent Kconfig variable USBDEBUG_IN_ROMSTAGE for convenient
use of this feature.
Change-Id: I0cd3fccf2612cf08497aa5c3750c89bf43ff69be
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3983
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
As boards without EARLY_CBMEM_INIT do not initialize CBMEM in romstage,
and have no CAR migration, these features are available for ramstage only.
Change-Id: Ic3f77ccdedd4e71ba693619c02c9b98b328a0882
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Timestamps from cbfs_and_run, TS_START_COPYRAM and TS_END_COPYRAM,
were lost with commit b766b1c7.
Reason is variable ts_table was referencing CAR storage after CAR
is torn doesn. Add use of car_get_var() / car_set_var() so the
references go to migrated storage in CBMEM.
Change-Id: I5a942ad7fd59a04e3a5255f4a3636d37dcfc1591
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3967
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This reverts commit de1fe7f655.
While things appeared to work, there were actually invalid references
to CAR storage after CAR was torn down on boards without
EARLY_CBMEM_INIT. It was discussed use of CAR_GLOBAL should be
restricted to boards that handle CAR migration properly.
Change-Id: I9969d2ea79c334a7f95a0dbb7c78065720e6ccae
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3968
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
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>
Assume EARLY_CBMEM_INIT=y everywhere and remove option from Kconfig.
If romstage does not make the cbmem_initialize() call, features like
COLLECT_TIMESTAMPS and early CBMEM_CONSOLE will execute during
romstage, but that data will get lost as no CAR migration is
executed.
Change-Id: I5615645ed0f5fd78fbc372cf5c3da71a3134dd85
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3917
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
These features depend on CAR_GLOBAL region, which is not available
when romstage is built with ROMCC. Exclude these from romstage, keep
them available for ramstage.
A follow-up patch will fix the dependencies and allows enabling these
features in menuconfig.
Change-Id: I9de5ad41ea733655a3fbdc734646f818e39cc471
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3919
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
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>
We only have one table to collect timestamps into.
Change-Id: I80180fe9a05226f0351c3e66eacaf2d0cb82c924
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3912
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Some development kits with USB 2.0 HS OTG have an USB hub instead
of being directly connected to the USB host/device controller.
Send the necessary initialisation sequence, using HUB CLASS requests
of PORT_POWER and PORT_RESET to enable a pre-selected port number
where a device supporting debug descriptor is located.
This also adds the Kconfig option for BeagleBone.
Change-Id: I7a5d0ba0962a9ca06bf3196232ed4a03bdfb2b06
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3925
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Clean whitespace errors that have gotten past lint-stable-003-whitespace
and gerrit review.
Change-Id: Id76fc68e9d32d1b2b672d519b75cdc80cc4f1ad9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3920
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Old name was too much x86.
All external references have been removed.
Change-Id: I982b9abfcee57a7ea421c245dadb84342949efae
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3906
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The parameters can be dropped as initialisation always happens for
the region resolved with cbmem_locate_table().
This is no longer referenced externally, make it static.
Change-Id: Ia40350a5232dcbf30aca7b5998e7995114c44551
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3565
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
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>
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>
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>
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>
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>
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>
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>
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)
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>
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>
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>
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>
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>
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>
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>
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)
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>
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>
Hung-Te Lin