Adds support for the following Adesto Technologies
SPI Flash parts.
AT25DF081
AT25DF321
AT25DF641
It has been tested on an Orion VPX7654 board populated
with an AT25DF321A part. The "08" and "64" densities have not
been tested.
These parts are the successors of the Atmel AT26DF line that
was spun out or purchased by Adesto.
In this patch, adesto.c is identical to winbond.c with part
entries for the Adesto parts. The datasheet for the AT25DF parts
includes a "100MHz" programming command in addition to the "85MHz"
command that is currently used but this patch does not add support
for that enhanced programming mode.
Change-Id: If82d075fd9000030480c412c645dcae2c8bb7439
Signed-off-by: Christopher Douglass <cdouglass.orion@gmail.com>
Reviewed-on: http://review.coreboot.org/5225
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
i915_reg.h re-declares some of MCH registers as seen through MCHBAR mirror.
It's not currently used and we don't want any MCH registers in GFX.
Change-Id: I5fa4711fee60d64316696b7ed713013de8759b54
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5318
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
UARTs now have unified prototypes and can use a single entry
in the list of drivers for ramstage.
Change-Id: I315daaf9a83cfa60f1a270146c729907a1d6d45b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5308
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Existing code compiled serial communication and printk() for SMM
even when DEBUG_SMI was not selected.
Change-Id: Ic5e25cd7453cb2243f7ac592b093fba752a299f7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5142
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@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>
Currently this is only a minimal stub to get console on qemu-armv7.
Change-Id: I3f20b7f944bc7d0e5ace9d22198d4c16a3839d2c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5162
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We should not have pc80/ includes in console/.
Change-Id: Id7da732b1ea094be01f45f9dbb49142f4e78f095
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5157
Tested-by: build bot (Jenkins)
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>
Old video init just replayed the sequence.
This one actually computes the values.
Change-Id: Ic1fe7a2e90dc2cc36ac0d8bcea5cfabc583f09a3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5270
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Struct dbgp_pipe would not be suitable for use with xHCI.
Just use an index, it is easy to setup in Kconfig if our
future debug setup has separate pipes for console
output and debugging/traceings.
Change-Id: Icbbd28f03113b208016f80217ab801d598d443a8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5227
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
There are EHCI compatible host controllers on ARM without PCI bus
architecture. Currently we have not come across one with the debug
capability though.
Change-Id: I8775c9814f6fdf8754f97265118a7186369d721d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5175
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
USB device end toggles data PID when we ACK'd the zero-length data
packet. As USB host we need to toggle data PID too or the next data
received would get discarded.
Change-Id: I3203bc874c7ded9244c7548a666d7041a0fbb379
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4775
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Read from USB endpoint_in 8 bytes at a time, the maximum what
EHCI debug port capability has to offer.
Change-Id: I3d012d758a24b24f894e587b301f620933331407
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4700
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Also prepare this console for use in romstage.
Change-Id: I26a4d4b5db1e44a261396a21bb0f0574d72aa86d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5136
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.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 trailing whitespace breaks the Git commit hook
`util/lint/lint-stable-003-wihitespace`. So remove it.
Change-Id: I70e4ac71529884a9a4fabf2aa9a4ea6e0323b9d4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5092
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
EEPROM/RFID chip present in thinkpad should be locked in a way to avoid
any potential RFID access.
Read serial number, UUID and P/N from EEPROM.
This info is stored on AT24RF08 chip acessible through SMBUS.
Change-Id: Ia3e766d90a094f63c8c854cd37e165221ccd8acd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4774
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
The W25Q64DW spi part is programatically equivalent
to the other W25Q64 parts except it operates at 1.8V.
Just add a new entry with the appropriate ID.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=SPI controller can program the part.
Change-Id: I65b0261223a9fefcb07477a43b6a3edb8228dd03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170011
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5077
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
On Asus A8N-E this test fails but if failure is ignored keyboard works.
Change-Id: Ifeeff2f41537b35bc90a679f956fea830b94292c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4816
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This allows system voltages to be specified uniformly, rather than
hardcoding them for each board. This will be used by cubieboard in an
upcoming patch.
Change-Id: I9dc2d3281d076c359c3fad13688649f7d36c0001
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4637
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
chip found in X230 if not using hardware sequencing.
Change-Id: I6ded10d35bfdbbe3d54c4170dd7846c7833f5ff7
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4616
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This adds #defines for BUCK2DVS1_1_2625V and BOOSTCTRL_OFF.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I363c73ff4a645da53973767fa4bfa2c120394af6
Reviewed-on: https://gerrit.chromium.org/gerrit/64303
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4426
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Moved a lot of code from i915io.c to intel_dp.c with specific function calls
Change-Id: Ib2ed52b4f73ee0076e2dd68a26541e5bbe1366bc
Reviewed-on: https://gerrit.chromium.org/gerrit/63950
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4429
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Depending upon the values decoded from edid, the function decides the appropriate bits to
be set in flags parameter (Important for fastboot to work correctly in kernel)
Change-Id: I3b0f914dc2b0fd887eb6a1f706f87b87c86ff856
Reviewed-on: https://gerrit.chromium.org/gerrit/64265
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/4423
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Also, used this attribute in the calculation of htotal and other registers
Added intel_dp_* functions for m,n registers and dimension register calculations
Change-Id: I99dd7156700d59b0b4c85e34c9aa1c6408c7f31a
Reviewed-on: https://gerrit.chromium.org/gerrit/64001
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/4422
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>
An issue was observed using a specific vendor's TPM in that it
chokes on access to registers that are not explicitly defined in the
PC client specification. The previous driver used generic access
functions for reading and writing registers. However, issues come
to play when reading from the status register. It read it as a 32-bit
value, but that read address 0x1b which is not defined in the spec.
Instead of using generic access functions for the tpm registers
provide explicit ones. To that end provide more high level wrapper
functions to perform the semantic access required.
Change-Id: I781b31723f819e1387d7aa25512c83780ea0877f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63243
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4388
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It has been disseminated that the RTD2132 chip
needs to be fully programmed for settings to take affect.
Most of the settings are note documented very well and
present themselves as magic values. Also, the wait time
for starting the sequence needs to be bumped from 2ms to 60ms.
Lastly, expose all the known settings through devicetree.
Change-Id: I9eeea9c4a13ec20b8ce1c5297e43c4dd793d90e5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65857
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When we go through the resume path, there shouldn't ever be a need to
initialize the PS/2 keyboard. The OS is going to reinitialize it
anyway, and it just slows the resume.
Verified Code flow in normal boot/S3 resume with print statements.
Verified Keyboard was correctly disabled and flushed by booting
to recovery mode screen while pressing keys on the integrated
keyboard.
Change-Id: I48bdca2fa2cc0c965401d10fef75cadb09d2e1e9
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63648
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4396
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
What gets written into the parade is highly mainboard-dependent.
So the parade_writes array needs to be there.
Change-Id: Ia382d9bf1929e67b7c14d7a09f5461b71866a16b
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61486
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4362
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>
The intel_ddi.c change I thought should be in but I don't see it. It just adds two functions back
that we need.
There are two new files for slippy annotated with comments about how it needs to evolve.
That said, this code has been tested on 3 different panels. Both dev and non-dev usages work.
physbase initialization to static value removed.
Moved spin calls to intel_dp_*
Change-Id: I0480af45c21c7dedcaff7e8be729f0eb554ec78a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61136
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4370
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This driver allows the mainboard to enable spread spectrum
clocking at 0.5%, 1.0%, and 1.5% with devicetree settings.
Change-Id: I59c61e67aa8e951fd9904ad951deb6d0ba29669e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61894
Reviewed-on: http://review.coreboot.org/4365
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
x_resolution, y_resolution and bytes_per_line were not inited. Without them
coreboot sweared that screen is 1108630x1142817 and payload tried to draw on
such a big screen.
Change-Id: I0d0277a20c7e1976c27af4a57651ab2be0f9c5d7
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4535
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
AT controller needs an ACPI node, otherwise FreeBSD doesn't detect keyboard
and mouse. Currently each SuperIO adds its own description. This one should
be used in the future instead.
Change-Id: Iaad5ed3846c6d9f467a02a286a1e6f60a3607af5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4518
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Newer mainboards that use haswell -- and, presumably, chipsets to come -- need
some support functions. Add them in the drivers/intel/gma directory.
Currently, this is one file: intel_ddi.c, but more may come.
Compilation of this file is controlled by INTEL_DDI, defined
in the Kconfig as default n and used in the Makefile.inc
Change-Id: I501ee291c0d4589925ed3e478f67106337fcad31
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60612
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4337
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The elog code calculates flash offsets and their equivalent
addresses in the memory address space. However, it assumes
the detected flash size is entirely mapped into the address
space. This can lead to incorrect calculations. Add code
to allow ROM_SIZE to be less than detected flash size. The
underlying assumption is that the first ROM_SIZE bytes are
programmed into the larger device.
Change-Id: Id848f136515289b40594b7d3762e26e3e55da62f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4332
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The Intel GMA driver is in, this CL splices in the Makefile bits.
Change-Id: Icf42a537575b8cc90a679ec1fc15b09294630611
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60346
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4331
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
These functions are not all used yet, but do compile and are partially used
in the FUI testing.
They were extracted from the 3.4 kernel using coccinnelle filters. The .c files
are only compiled in if CONFIG_INTEL_DP is set.
Change-Id: Id95622a75aa02b496c9ea4717cb143394a8332e3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60245
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Removed two unnecessary register sets, and did the power well a bit
more correctly. Also, added a register definition include file so we can
used constants instead of magic numbers.
We also set registers to common initialized values that are
needed for FUI, VBIOS, and kernel. This set of registers
appears to be an absolute bare minimum. Since we're hoping to use
FUI for all chipsets from this one forward, we unconditionally do the
setting here.
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Change-Id: Ife3f661ba010214d92b646b336f2b06645119f17
Reviewed-on: https://gerrit.chromium.org/gerrit/59988
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4328
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There was always exactly one elog descriptor declared and initialized, but its
contents were being accessed through a pointer that was passed back and forth
between functions instead of being accessed directly. This made the code more
verbose than it needed to be and harder to follow. To address this the
descriptor type was eliminated, its contents were turned into individual
global variables, and various functions were adjusted to no longer take the
descriptor as an argument.
Similarly, the code was more verbose and complicated than it needed to be
because of several wrapper functions which wrapped a single line of code which
called an underlying function with particular arguments and were only used
once. This makes it harder to tell what the code is doing because the call to
the real function you may already be familiar with is obscured behind a
new function you've never seen before. It also adds one more text to the file
as a whole while providing at best a marginal benefit. Those functions were
removed and their callers now call their contents directly.
Built and booted on Link. Ran mosys eventlog list. Cleared the event log
and ran mosys eventlog list again. Added 2000 events and ran mosys eventlog
list. Cleared the log again and ran mosys eventlog list.
Change-Id: I4f5f6b9f4f508548077b7f5a92f4322db99e01ca
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49310
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4245
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The elog driver's design was a bit more elaborate than it really needed to be
since it no longer had to keep track of multiple copies of the log in flash
and also in memory. This change streamlines it by removing unnecessary
compartmentalization of some bits of code, and some variables which tracked
the last entry added which were never used.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the event log and ran mosys eventlog list again. Cleared the log by echoing 1
into /sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
Change-Id: I7d4cdebf2f5b1f6bb1fc70e65eca18f71b124b18
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49309
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4244
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
elog_validate_and_fill was called in exactly one place, in
elog_init_descriptor. It didn't actually do what its name implied since the
data in the event log was already "filled" by elog_init_descriptor. Likewise
elog_init_descriptor was delegating an important part of its own job, scanning
through the list of events, to elog_validate_and_fill.
Since one function was basically just a displaced part of the other which
couldn't really stand on its own, this change merges them together.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events with
the SMI handler and ran mosys eventlog list again.
Change-Id: Ic899eeb18146d0f127d0dded207d37d63cbc716f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49308
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4243
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function was just a wrapper around elog_init_descriptor, and all it did
was pass the current backing store location and size back in so it would be
reused. Those values, which never change, are now set in
elog_setup_descriptors, eliminating those parameters to init and eliminating
the need for _reinit_.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again.
Change-Id: I133768aa798dfc10f32e14db95235a88666890c3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49307
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4242
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The event log driver keeps two copies of the event log in memory, one to
take the place of the historically memory mapped image of flash which is now
read and written manually, and one originally intended to be an in memory
cache of flash. Since both are now just copies in memory, there's no value in
having them both and keeping them in sync.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again. Cleared the log by echoing a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list again.
Change-Id: Ibed62a10c78884849726aa15ec795ab2914afc35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49306
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4241
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The way elog_shrink currently works is that it completely clears the data in
the flash/flash descriptor and then recreates it using the part of the log
it's going to keep as stored in the memory descriptor. That scheme depends on
there being to independent copies of the log.
This change reworks elog_shrink so that it moves the data it wants to keep
within a single descriptor and then propogates it to the other and to flash
intact. This way, when one of the descriptors goes away, all we have to do is
remove the code that would update it.
Built and booted into ChromeOS on Link. Ran mosys eventlog list. Added
2000 events to the log and ran mosys eventlog list again. Echoed a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
BRANCH=None
Change-Id: I50d77a4f00ea3c6b3e0ec8996dab1a3b31580205
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49305
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4240
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The header is at the start of the log. There's no reason to either keep a
seperate pointer to it, or to keep a copy of it in some other bit of memory.
Built and booted on Link and used 'mosys eventlog list' to list the
contents of the log. Ran
for x in $(seq 1 2000); do
cat elog.event.kernel_clean > /sys/firmware/gsmi/append_to_eventlog;
done
And ran mosys eventlog list again to verify that the log had been shrunk
correctly.
Change-Id: I2afcd52c0ce5bbb662ac56f2895cdbea28d5c2ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49304
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4239
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a comment, tweak spacing a bit, addr variable
doesn't need to be global any more.
Change-Id: Id8d8a7babce671243351074f7ac52a5c8c264de5
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4274
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Do not return hardcoded numerical values to communicate succes/failure, but
instead use an enumeration.
Change-Id: I742b08796adf136dce5984b702533f91640846dd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4265
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In addition to not clearing the pending interrupts, we also
don't want to reset the RTC control register when booting
with an S3 resume.
On most new systems, when the RTC well is losing power, we
will also lose state that is required to perform a resume,
so we end up in a normal boot anyways. Hence don't do any
RTC initialization in the S3 resume path.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I73b486082faa741e9dccd15f2b8e3a8399c98f80
Reviewed-on: https://gerrit.chromium.org/gerrit/56826
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A parrot device with a bad flash part has been seen to hang
in the elog_shrink code becuase the flash was not successfully
erased and it gets stuck in a loop trying to shrink the log
and then add an event.
Change-Id: I8bb13dbadd293f9d892f322e213c9255c8e9acb3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56405
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4186
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If elog_clear is called before other elog functions, for instance if it's
called through an SMI immediately after the system boots, then the elog data
structures won't have been set up and the system will go off the deep end.
This change adds a call to elog_init to elog_clear to make sure things things
are always initialized before we start using them.
Before this change, this command would cause
the system to lock up if run immediately after boot:
echo 1 > /sys/firmware/gsmi/clear_eventlog
After this change, that results in the log being cleared correctly.
Change-Id: I45027f0dbfa40ca8c581954a93b14b4fedce91ed
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49303
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4144
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Recent commit proposal by Ron Minnich proposes to move to native gfx init for
qemu. Unfortunately we didn't have native init for default qemu video (cirrus)
Here is one extracted from GRUB one which I wrote couple of years ago.
Change-Id: Icb89cf918ef5d276bcc703c48c568e7b9c1be756
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Per our discussions with Gerd, qemu will now always do native graphics
on coreboot. The VGA BIOS capability is not needed and will no longer
be supported. Attempts to build without native graphics will result in
an error.
This code builds for both x86 emulation targets. I'm hitting an issue
testing that is unrelated to coreboot; if someone can test, that
would be helpful. Be sure to start qemu with -vga std.
We also add a test for the PCI BAR being zero and return silently if it
is.
Change-Id: I66188f61e1bac7ad93c989cc10f3e0b55140e148
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4258
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
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>
Ported from spi/winbond.c.
Fixes this error:
ICH SPI: Too much to write.
Does your SPI chip driver use CONTROLLER_PAGE_LIMIT?
Change-Id: I50db8fd1104d3b7d319b278b14f97e3ff9cb6404
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3877
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This driver is basically the same as the one in U-Boot but without the device
tree stuff. That driver is, in turn, a straightforward implementation of the
sequence of register writes described in the data sheet. Comments were added
in U-Boot which helpfully describe what the register writes are actually
doing and are kept.
Change-Id: I64ba6b373478853bb2120f0553a43de901170d02
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/3753
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds register offsets and important values for the Maxim
MAX77802 PMIC.
Change-Id: I3724b82bcb235b6684d2b976876f628f1ffbed3f
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Without that fix we have:
src/drivers/elog/elog.c: In function 'elog_is_header_valid':
src/drivers/elog/elog.c:213:3: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format]
Change-Id: I71b80a94c03a04eedb688ae107d92c05a878315e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3551
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
As the TPM driver can be accessed in romstage after
cache-as-ram is torn down use the cache-as-ram migration
API to dynamically determine the global variable address.
Change-Id: I149d7c130bc3677ed52282095670c07a76c34439
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3233
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some LPC initialiation can save some lines of code when being able
to use the functions `io_apic_read()` and `io_apic_write()`.
As these two functions are now public, remove them from the generic
driver as otherwise we get a build errors like the following.
[…]
Building roda/rk9; i386: ok, using i386-elf-gcc
Using payload /srv/jenkins/payloads/seabios/bios.bin.elf
Creating config file... (blobs, ccache) ok; Compiling image on 4 cpus in parallel .. FAILED after 12s!
Log excerpt:
coreboot-builds/roda_rk9/arch/x86/lib/ramstage.o: In function `io_apic_write':
/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/arch/x86/lib/ioapic.c:32: multiple definition of `io_apic_write'
coreboot-builds/roda_rk9/drivers/generic/ioapic/ramstage.o:/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/drivers/generic/ioapic/ioapic.c:22: first defined here
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/roda_rk9/generated/coreboot_ram.o] Error 1
make: *** Waiting for unfinished jobs....
[…]
Change-Id: Id600007573ff011576967339cc66e6c883a2ed5a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3180
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This does basic re-factoring to fit the driver into coreboot.
Change-Id: Id5f8c12a73ec37ddd545d50b3e8e9b3012657db1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3061
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This imports TPS65090 PMIC from u-boot and adds/updates Makefiles
and Kconfig files. The follow-up patch will re-factor the code.
Change-Id: Ic9e43b9665ddf7f55feae8fa17fbf3d2d5f4756d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3060
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.
- i2c_read() and i2c_write() functions updated to take bus number
as an argument.
- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
i2c_write(). If a chip needs special handling we should take care
of it elsewhere, not in every low-level i2c driver.
- All the confusing bus config functions eliminated. No more
i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
is handled automatically when the caller does a transaction and
specifies the desired bus number.
- i2c_probe() eliminated. We're not a command-line utility.
- Let the compiler place static variables automatically. We don't need
any of this fancy manual data placement.
- Remove dead code while we're at it. This stuff was ported early on
and much of it was left commented out in case we needed it. Some
also includes nested macros which caused gcc to complain.
- Clean up #includes (no more common.h, woohoo!), replace debug() with
printk().
Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:
- We only need to expose i2c_read() and i2c_write() in our public API.
Everything else is board/chip-dependent and should remain hidden
away.
- i2c_read and i2c_write functions will take bus number as an arg
and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
error and end up cluttering the code since the user needs to save
the old bus number, set the new one, do the read/write, and restore
the old value (3 added steps to do a simple transaction).
- Stop setting default values for board-specific things like SPD
and RTC bus numbers (as if we always have an SPD or RTC on I2C).
- Death to all the trivial inline wrappers. And in case there was any
doubt, we really don't care about the MPC8xx. Though if we did then
we would not pollute the public API with its idiosyncrasies.
Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
For whatever reason tabs got inserted in the license header text.
Remove one occurrence of that with the following command [1].
$ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,'
[1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2460
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
Since there are and will be other files in nb/sb folders, we change
the general spi.h to a file name which is not easy to be duplicated.
Change-Id: I6548a81206caa608369be044747bde31e2b08d1a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2309
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The power_init is not required on Exynos 5250 (snow) in bootblock stage. To get
a cleaner and faster bootblock, we can remove it.
Note, power_init internally calls max77686 and s3c24x0_i2c, so both files are
also removed.
Verified to boot on armv7/snow.
Change-Id: I5b15dfe5ac7bf4650565fea0afefc94a228ece29
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2317
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This contains some size optimizations for the Maxim MAX77686 driver:
- change max77686_para.vol_{min,div} from u32 to u16 (currently their
max value is 50000 so it should be fine)
- remove max77686_para.regnum which takes 4 bytes for each and is not
used
(Patch was originally written by Hung-Te Lin, I'm just uploading it)
Change-Id: I24044427c49467e99380d1f60ebc59e69c285b22
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2124
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Fix some minor discrepancies which prevented the MAX77676 from
getting compiled in properly.
Change-Id: Ib29136da6c15a4bdb24926a91729431c507cd209
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2076
Tested-by: build bot (Jenkins)
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SB800 and Hudson now support adding the IMC ROM which runs from the same
chip as coreboot. When the IMC is running, write or erase commands sent to
the spi bus will fail, and the IMC will die. To fix this, we send a request
to the IMC to stop fetching from the SPI rom while we write to it. This
process (in one form or another) is required for writes to the SPI bus while
the IMC is running.
Because the IMC can take up to 500ms to respond every time we claim the
bus, this patch tries to keep the number of times we need to do that to a
minimum. We only need to claim the bus on writes, and using a counter for
the semaphore allows us to call in once to claim the bus at the beginning
of a number of transactions and it will stay claimed until we release it
at the end of the transactions.
Claim() - takes up to 500ms hit
claim() - no delay
erase()
release()
claim() - no delay
write()
release()
Release()
Change-Id: I4e003c5122a2ed47abce57ab8b92dee6aa4713ed
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1976
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
With driver-y going away, the current driver code didn't get
compiled in with upstream.
Change-Id: I9bff45a35c995888a482bdc22a1573f6bfb88211
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2027
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Chris Douglass