This ensures that the LCD FETs are off before we do graphics init.
FIXME: The location of the code is sub-optimal and should probably be
done in romstage, but there are __PRE_RAM__ considerations to take
into account.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0844030d0a0e51eee1d29f1762f0b495777268df
Reviewed-on: https://gerrit.chromium.org/gerrit/64305
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Assign correct parent PLL's for the following clocks:
ACLK_400_WCORE (MPLL->CPLL) (400 -> 333MHz)
PCLK_200_FSYS (MPLL->DPLL) (200 -> 200MHz)
MUX_ACLK_100_NOC_SEL (MPLL -> DPLL) (100 -> 100MHz)
ACLK_266 (DPLL->MPLL) (300 -> 266MHz)
ACLK_200_DISP1(MPLL->DPLL) (200 -> 200MHz)
ACLK_400_MSCL(MPLL->CPLL) (400 -> 333MHz)
ACLK_66 (MPLL->CPLL) (66.666 -> 66.6MHz)
MUX_ACLK_400_DISP1_SEL (CPLL->DPLL) (666 -> 300MHz)
MUX_MPHY_REFCLK (MPLL->OSC)
MUX_UNIPRO (MPLL->OSC)
MUX_MIPI1 (EPLL->OSC)
MUX_DP1_EXT_VID (EPLL->OSC)
MUX_FIMD1_OPT (EPLL->OSC)
MUX_IPLL(IPLL->OSC)
This also corrects the clock dividers for few of the clocks,
as the clock parent changes affect the final frequency of the
clocks.
This is ported from: https://gerrit.chromium.org/gerrit/#/c/62437/
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ie833c01913d0961a6190446bd573511de8dee5f8
Reviewed-on: https://gerrit.chromium.org/gerrit/65620
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-on: http://review.coreboot.org/4469
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This reads the clock select field for MUX_ACLK_66_SEL in the
CLK_SRC_TOP1 register in order to obtain the source clock rate
for I2C peripherals. Before we were always assuming that the source
was the MPLL.
Unfortunately not all fields in the CLK_SRC_TOPn registers are
enumerated the same with regard to clock select. So this is just
a one-off for now.
This is basically ported from https://gerrit.chromium.org/gerrit/#/c/62443.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9fa85194ae1a1fadab79695f059efdc2e2f1f75f
Reviewed-on: https://gerrit.chromium.org/gerrit/65611
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4468
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Increase SPLL to 400MHz from 300MHz as we set SPLL as the
switching parent for ARM and KFC. This value is as per
recommendation of the hardware team.
This is ported from https://gerrit.chromium.org/gerrit/62618
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8a5a5b957083b0b1f3e3e318fe5753cf7ae19223
Reviewed-on: https://gerrit.chromium.org/gerrit/65432
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4464
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This re-factors clock_get_periph_rate() to be a simpler and also
make a few corrections along the way. To summarize:
- clk_bit_info is no longer used. It had numerous errors and was
really painful anyway since it was just a bunch of opaque magic
numbers that made bugs non-obvious.
- Clock source bitfields for peripherals handled in the switch
statement are 3 bits, not 4. Some divider values are 3 bits,
some are 4. The earlier code always assumed 4 bits for both
which included reserved bits in many cases.
- UART source clock and divider shift values were wrong.
- PWM clock divider was being read from the wrong register.
- SPI3 divider value was being read from the wrong register.
- There was a really confusing calculation for SDMMC0 and SDMMC2
clock rates, but it was never actually used since the switch
statement never handled PERIPH_ID_SDMMC{0,2} and would thus
return if they were ever passed into this function.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0a03a64d8b42fbe83dbf377292597ce681b22f4b
Reviewed-on: https://gerrit.chromium.org/gerrit/65284
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4463
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This adds a helper function to translate between peripheral clock
select fields in clock source registers and PLLs. Some of this was
already done to handle a few special cases, this generalizes the
earlier work so that follow-up patches can do further clean-up.
Unfortunately, the PLLs represented by clock select fields in
various modules are not uniformly ordered. So for now we focus on
peripheral clock sources only.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Id58a3e488650d09e6a35c22d5394fcbf0ee9ddff
Reviewed-on: https://gerrit.chromium.org/gerrit/65283
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4462
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch adds CPLL and DPLL to the known list of PLLs.
This is ported from https://gerrit.chromium.org/gerrit/#/c/62617/
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I2f2614e44cd9c98d98b8db9347f29de21703d1af
Reviewed-on: https://gerrit.chromium.org/gerrit/65282
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4461
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch matches the User Manual Table 7-2 about the PMS value for
CPLL. This doesn't change the PLL frequency (before and after both make
666MHz) but this is the suggested PMSK values for obtaining 666.
(Suggested as per user manual).
This is ported from https://gerrit.chromium.org/gerrit/#/c/62438/
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ia33e1971ab88da761000d443792560476514626b
Reviewed-on: https://gerrit.chromium.org/gerrit/65281
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4460
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Configure the pins for the UART unconditionally in the mainboard code (when we
know which UART to configure) instead of in the UART driver. This also means
the UART will work if later software wants to use it without setting up the
pins.
Built and booted on pit with the serial turned off and some serial init
in the kernel decompression stub fixed.
Change-Id: Icab5755e4f935f52d44b9cb3b43d1cb62acce08f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65299
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4457
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch implements the basic infrastructure required to use the USB
A-A firmware upload feature on Exynos5 processors with Coreboot. It will
require a corresponding host-side script that activates the feature and
uploads the correct image parts in the correct order to harcoded target
addresses, as described in the comments of alternate_cbfs.c.
Also fixes a bug in the Google Snow mainboard where it would not
correctly initialize the pinmux configuration for the SPI flash bus.
During a normal SPI boot the IROM would already do that for you, but
when booting from USB you have to do it yourself.
Change-Id: I40a39f8f5d1d70b58dbf258015c1653a27097d67
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64875
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4456
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The existing GPIO config routines for SDMMC0-2 are over-generalized
and somewhat confusing as a result. It would work nicely if all SDMMC
ports were configured in the same fashion, but there are a few
exceptions.
For example, the inner function runs differently if we're using 8 bits
of data instead of 4, so a big chunk is skipped for SDMMC2. SDMMC0
requires SD_0_CDn to be an output rather than alternate function and
must have a value set.
This patch trades some verbosity for simplicy. Now the SDMMC GPIO
configuration a straight-forward sequence of GPIO operations
without any exceptions.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: If75075b24c6588c4c1b3be3fb9b1aa95e2fac2d1
Reviewed-on: https://gerrit.chromium.org/gerrit/65248
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4446
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
On Exynos5420 the MMC channel 0 is connected to eMMC
Which does not have a card detection pin. Also this pin
is connected as VDDEN to PMIC.
This is ported from https://gerrit.chromium.org/gerrit/#/c/60732/
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I19048d22b7dd00df1716b6b5b332a7eb70fe0836
Reviewed-on: https://gerrit.chromium.org/gerrit/65247
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4445
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This initializes the APLL at 1800MHz.
Change-Id: I366bf4e75510847ab93d9c9f214a49c731cca08a
Reviewed-on: https://gerrit.chromium.org/gerrit/64745
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4443
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Switch ARM clock source when changing the APLL frequency to avoid
stability issues.
This is ported from https://gerrit.chromium.org/gerrit/#/c/64189/5
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I923107555e6d3287b3694cbf9e4bb548d3e5f4a8
Reviewed-on: https://gerrit.chromium.org/gerrit/64838
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4442
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch does the following for the A15 cores:
- Disable clean/evict push to external
- Enable hazard detect timout
- Prevent gating the L2 logic clock
This is ported from https://gerrit.chromium.org/gerrit/#/c/60154
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I7ac9f40acecfa7daee6fb81772676bf5119d0536
Reviewed-on: https://gerrit.chromium.org/gerrit/64862
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4441
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This bus is hooked up on snow and, as it's the only bus hooked up on some
other boards, having it available in firmware to test is handy.
Change-Id: Icb48b9af4a67d382bd6fbce1e4c6a320d811d365
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64877
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4438
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This divides the CPU frequency by 1,000,000 instead of 2^20.
serial console shows "CPU: S5P5420 @ 800MHz" instead of
claiming 762MHz.
Change-Id: I70cc5b62f689c5553b57c82be61233fb9f733f6e
Reviewed-on: https://gerrit.chromium.org/gerrit/64743
Reviewed-by: Gabe Black <gabeblack@chromium.org>
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/4434
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The memory corruption problem in Exynos suspend/resume process is caused by two
things together: PHY_RESET and MRS command.
After stop sending MRS on resume, we can now remove the workaround of skipping
PHY_RESET.
Change-Id: I64acc27c1d2bb549ae6ad7d32ecda94b0355972c
Reviewed-on: https://gerrit.chromium.org/gerrit/64736
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
The kernel assumes that trust zone is disabled.
Change-Id: Ia8d6fa69adcb812a747d8b89eb77e57144423eaa
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64722
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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/4431
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This ensures that various trust zone things are reset,
which is important because the kernel assumes they are.
Change-Id: Ie02ea89885621f58a3ccc4f1729617208a264153
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64697
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4430
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The current function seems to be outdated...
Signed-off-by: David Hendricks <dhendrix@chromium.org>
built and booted. Now we see "CPU: S5P5420 @ 762MHz"
instead of "CPU: S5PC420 @ 762MHz"
Change-Id: Ieb103a5fa62bda9a6b2cbd9a82fb4f72c5dd6466
Reviewed-on: https://gerrit.chromium.org/gerrit/64302
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4425
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
A previous change removed init_timer from timer_monotonic_get because its old
implementation set up the PWM based timer which was going away. It would still
be a good idea to initialize the timer at that point, just not the pwm.
Change-Id: I4816710ec2c9d5ca53b704c6b9397bcfac183fdc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64160
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4419
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
... In order to do this, the graphics memory has to move into
the resource allocator and out of CBMEM.
Change-Id: I565c3d6dea747822fbabf6f3845232d4adfbf333
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63657
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4391
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
... In order to do this, the graphics memory has to move into
the resource allocator and out of CBMEM.
Change-Id: I7396da4a7068404b0d2e4d308becab4dd6ea59bb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59326
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4390
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Some registers and bit fields were wrong, but the difference is mostly
academic since the code that uses them are never called.
Change-Id: I0ce5e1529cdda1a4973765af8c31b79130b1111c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63189
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4385
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The divisor mask had been set to 0xff, but the bitfield is 4 bits wide.
Change-Id: Id8a205c80ca2fb0b6f0d86a0c3be4bba9527c0b5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63188
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4384
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The timer code was supposed to be using the mct, and also using the monotonic
timer infrastructure instead of the get_timer function. This change had been
made for the 5250 but not yet for the 5420.
Change-Id: I03a4fbb434f2346761f28fb6bd2218b526f2a4a2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64159
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4418
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This code was left over from U-Boot and was superceded by the MCT.
Change-Id: Ia85e3b7281dcdd4740238dddd0dfc6f0ba2c94da
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63778
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4401
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When the const was removed from write function arguments, a related bug in the
5250 code was fixed so that it would still compile. Unfortunately, that same
change needed to be made to the 5420.
Change-Id: If15057c92422de91dc8e35dbd8b5c978bfae122a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64154
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4417
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The code generally intended to make the pointer const instead of the thing it
pointed at, but it had const backwards. Sometimes both the pointer and the
data could be const, but sometimes there were writes where only the pointer
should be.
Change-Id: Ifcd5495769b86b47d7b583cce63ed5c2158bec4e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63775
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4397
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
SYS_TEXT_BASE is not used by any one. To prevent confusion when changing memory
layout, remove it from current configurations.
Change-Id: I15012b864bbb9c12003843b9b24ea64c91f4578b
Reviewed-on: https://gerrit.chromium.org/gerrit/61853
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4371
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Up until now, a dummy terminator was required for CBFS microcode files.
This was a coreboot only requirement in order to terminate the loop which
searches for updates.
Figure out where the microcode file ends, and exit the loop if we pass the
end of the CBFS without finding any updates.
Change-Id: Ib61247e83ae6b67b27fcd61bd40241d4cd7bd246
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4505
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Microcode update file contains patches for various processor
revisions, it is not an error to have those.
Change-Id: Ifbca26276b66f17092afe249a2cfc229713a9fec
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4520
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
CPU_MICROCODE_IN_CBFS was designed to mean that loading microcode updates
from a CBFS file is supported, however, the name implies that microcode is
present in CBFS. This has recently caused confusion both with contributions
from Google, as well as SAGE. Rename this option to
SUPPORT_CPU_UCODE_IN_CBFS in order to make it clearer that what is meant is
"hey, the code we have for this CPU supports loading microcode updates from
CBFS", and prevent further confusion.
Change-Id: I394555f690b5ab4cac6fbd3ddbcb740ab1138339
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4482
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
The 5250 DRAM code is *really* chatty. That's not a great
idea in time critical code, and DRAM init is generally
very sensitive about such things.
Finally, for those things that are errors, print them
at an error level, not a debug level.
Change-Id: Ifa86b019dfd5f8ae6c8a1da2a35b5d0808dc3623
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60100
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4359
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name "LPDDR3PHY_CTRL_PHY_RESET_OFF" is not appropriate because the real
phy-reset is a low-active pin, so "off(0)" will trigger "start to reset".
To prevent confusion, we should rename the constants to "RESET_ENABLE" and
"RESET_DISABLE".
Change-Id: Iccba5ef3a2e992f877dea90741f0308c161758c9
Reviewed-on: https://gerrit.chromium.org/gerrit/61081
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4357
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are needed to enable workarounds/features on specific
CPU types and stepping. The older northbridge function and
defines from sandybridge/ivybridge are removed.
Change-Id: I80370f53590a5caa914ec8cf0095c3177a8b5c89
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61333
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4355
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To configure source clocks on Exynos 5420 for MMC drivers.
Some registers are different from the 5250. FSYS now has two parts
and MMC uses FSYS2. The MMC block uses MPLL as the clock source.
The "high-speed" MMC interface runs as 52MHz, so divider is set
accordingly.
Also, the MMC driver has changed from MSHCI (Mobile Storage Host Controller
Interface) to DWMCI (DesignWare MMC Controller Interface).
Change-Id: I9ba9cf43e2f2dcd9da747888c0c7676bd545177b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60858
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4354
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
No ROMCC involved, no need to include .c files in romstage.c.
Change-Id: I8a2aaf84276f2931d0a0557ba29e359fa06e2fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4501
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
1) fix enable of power aware interrupt routing
2) set BIOS_RESET_CPL to 3 instead of 1
3) mirror PKG power limit values from MSR to MMIO on all SKUs
4) mirror DDR power limit values from MMIO to MSR
5) remove DMI settings that were from snb/ivb as they do
not apply to haswell
1) verify power aware interrupt routing is working by looking
in /proc/interrupts to see interrupts routed to both cores
instead of always to core0
BEFORE: 58: 4943 0 PCI-MSI-edge ahci
AFTER: 58: 4766 334 PCI-MSI-edge ahci
2) read back BIOS_RESET_CPL to verify it is == 3
localhost ~ # iotools mmio_read32 0xfed15da8
0x00000003
3) read PKG power limit from MMIO and verify it is the same
as the MSR value
localhost ~ # rdmsr 0 0x610
0x0000809600dc8078
localhost ~ # iotools mmio_read32 0xfed159a0
0x00dc8078
localhost ~ # iotools mmio_read32 0xfed159a4
0x00008096
4) read DDR power limit from MSR and verify it is the same
as the MMIO value (note this is zero based on current MRC input)
localhost ~ # rdmsr 0 0x618
0x0000000000000000
localhost ~ # iotools mmio_read32 0xfed158e0
0x00000000
localhost ~ # iotools mmio_read32 0xfed158e4
0x00000000
Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60544
Reviewed-on: http://review.coreboot.org/4333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The original intention was to only run UPDATE_FIT when a microcode file was
included in CBFS. This happens when either CPU_MICROCODE_CBFS_GENERATE or
CPU_MICROCODE_CBFS_EXTERNAL is selected, however, the makefile checked that
CPU_MICROCODE_IN_CBFS was selected instead. The end result was that on
hasswell, the UPDATE-FIT step was always run, even when no microcode was
included, generating a build error.
Instead, introduce a new variable which tells if a microcode update is
added in CBFS during the build.
Change-Id: I28638912ed6f77761ef8a584f7636dc907b7a9b7
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4480
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit * bdafcfa Add the Intel FSP 206ax CPU core support
Introduced this option. This option was meant to have a board generate
a CBFS file containing microcode. However, microcode generation used to be
enabled by default when CPU_MICROCODE_IN_CBFS was selected.
The introduction of BOARD_MICROCODE_CBFS_GENERATE killed that automatic
default, which is not what we want. This option is misguided in the sense
that it tends to introduce a non-default which had been intentionally a
default. We now have to select two Kconfig options in order to generate
microcode in CBFS, meaning one option is redundant.
Change-Id: I3034833df1a9afa7d6d9d537484cb4ac89d30183
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4478
Tested-by: build bot (Jenkins)
Add the FSP northbridge and southbridge includes.
Change-Id: I5c7f395dc033caa8d0bf0313382769595d77f2a5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4019
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for 206ax using the Intel FSP.
The FSP is different enough to warrant its own source files
for now. It has different CAR code, micorcode, and FSP inclusion.
It may be possible to combine this code with the mrc based
solution used by the chromebooks in the future.
Change-Id: I5105631af34e9c3a804ace908c4205f073abb9b4
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4016
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
Compiler may do loads of optimisations around stack switch and so it's allowed
to break stack switch as it sees fit. Do it in assembly instead.
Not tested.
Change-Id: I277a62a9052e8fe9b04e7c65d149e087282ac2a2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4286
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
SPD GPIOs were being read prior to initialization in romstage_common. To
fix, pass the copy_spd function to romstage_common, to be called at the
appropriate time (after PCH init, before DRAM init).
Change-Id: I2554813e56a58c8c81456f1a53cc8ce9c2030a73
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58608
Reviewed-on: http://review.coreboot.org/4237
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If Vortex86EX PS/2 keyboard controller system flag bit times out,
reload controller firmware code and try again.
Abort and die after 11 tries as this means the CPU is defect. Also
inform the user by printing a message.
Change-Id: I24aec4b20d85c721c01e72686f3eb1259f9334b8
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3988
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
When an INIT# is delivered to the CPU the CPU starts
executing from the reset vector. However, the internal state
is maintained. Therefore, check for such a condition and
reset the system.
Issues 'apreset warm' on the EC console. INIT# is sent and
CPU notices it's not a clean reset and forces one. No hangs.
Change-Id: I71229e0e5015ba8c60f5989c533268604ecc1ecc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57111
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Part of X201 port.
Change-Id: If17d707004aba9f08459dbd8f3a146fa3c076aa9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4052
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
With the XHCI controller enabled we no longer hang the
system when dropping into a package C-state so remove
the code that was disabling it.
Change-Id: Icd60488fd2506dac04fb6ec96a77bec265b10d8c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50355
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4163
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The current microcode blobs contain both ULT and non-ULT
revisions. Only include one or the other based off of the
CONFIG_INTEL_LYNXPOINT_LP Kconfig option.
Change-Id: I3e4e41d4cd727b1a974361fb469267e6f6022d5a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50318
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4160
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This reads PCH power levels via PCODE mailbox and writes the
values into the PMSYNC registers as indicated in the BWG.
Change-Id: Iddcdef9b7deb6365f874f629599d1f7376c9a190
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4143
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On haswell ULT systems there is a 24MHz clock that continuously runs
when deep package c-states are entered. The 100MHz BCLK is shut down
in the lower c-states. When the package wakes back up a conversion
formula needs to be applied. The 24MHz calibration is done using the
internal PCODE unit.
Change-Id: I6be7702fb1de1429273724536f5af9125b98da64
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48292
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4136
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The c-states are configured according to the BWG, however the
package c-states are disabled as they currently cause platform
instability. The exposed ACPI c-state to processor c-state mapping
are as follows for ULT boards:
ACPI(C1) = MWAIT(C1E)
ACPI(C2) = MWAIT(C7S long latency)
ACPI(C3) = MWAIT(C10)
The non-ULT boards have an expoed c-state mapping:
ACPI(C1) = MWAIT(C1E)
ACPI(C2) = MWAIT(C3)
ACPI(C3) = MWAIT(C7S)
Included in this patch is removing the updating of current limit
registers as some of the MSRs are different and the proper values
are currently unknown. Lastly, some of the MSRs were renamed to
match the BWG.
Booted 3.8 kernel and used powertop to note package, core, and acpi
c-state residency.
Change-Id: Ia428d4a4979ba3cba44eb9faa96f74b7d3f22dfe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48291
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4133
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
With the LynxPoint chipset there are more than 16
possible GPIOs that can trigger an SMI so we need
a mainboard handler that can support this.
There are only a handful of users of this function
so just change them all to use the new prototype.
Change-Id: I3d96da0397d6584f713fcf6003054b25c1c92939
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49530
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4145
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Move into src/cpu/dmp/dmp_post_code.h
Change-Id: If9f4d842f352eb41618e71f49a226d3cc4ad0b46
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3989
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The recommendation from Intel is to report each core as a
separate logical domain in the _PSD table.
This goes against the recommendation in the ACPI specification
because all of these cores are on the same package and share a
VR so they will do voltage transitions together.
The reasoning is that with a larger number of logical processors
the P-state often ramps too quickly resulting in higher power
consumption. By exposing each core as a separate domain the OS
can manage them individually allowing the socket to select the
optimum frequency.
$ cat /sys/firmware/acpi/tables/SSDT > /tmp/SSDT
$ iasl -d /tmp/SSDT
Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000000,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000001,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU2, 0x02, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000002,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU3, 0x03, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000003,
0x000000FE,
0x00000001
}
})
}
Change-Id: I5ef41b6ead4d88e9ba117003293dbc629c376803
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4130
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2065x is with nehalem and not sandybridge.
I don't care much eitherway but it clears some confusion.
Change-Id: Ib2b8e570b830a12ed8d0d313ee4eb56755796d4b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4046
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2065x boards don't use MRC. And the space in question isn't used either.
Read number of variable range MTRRs from MSR rather than hardcoding it.
2ff is still zeroed out as unless you zero-out undocumented bits as well
boot fails.
Tested on Lenovo X201.
Change-Id: Ic574193094e7d27c2d6a4d7d3e387d989578532e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4080
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The mdelay is not necessarry on 2065x.
Tested on X201 that it works without delay.
Change-Id: Ida9e85be7c214f3ba4c9476b5d8a0351e7980e5e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4083
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
For the ram init of Intel Nehalem ram init we need a udelay implementation.
Use common TSC framework for it as Intel Haswell already does.
Change-Id: I360a6db1ec1ba32c92698a7d6f6968c93ead5c52
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4043
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The platform initialization (PI) code v1.0.0.7 for Kabini has some
enhancements like ECC DIMM support, new CPU microcode rev 0700010B, FCH
bug fix (RTC) and so on.
Use the name Kabini instead of Kerala everywhere.
Note, the former PI code was indeed version v1.0.0.0 instead of v0.0.1.0
as used in `AGESA_VERSION_STRING`.
Change-Id: I186de1aef222cd35ea69efa93967a3ffb8da7248
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3935
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.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>
When building coreboot with the Clang static analyzer scan-build,
it reports »Value stored to 'type_index' is never read«. Indeed,
in `memranges_each_entry()` `type_index` is assigned a value
before being read. So remove that line.
Change-Id: I6da2fb8be7157bb98c57281babd4a08ca0d9f7a7
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3953
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Fix "set but not used" variable warning with gcc 4.7.3
Change-Id: Ia27291ecb4f993c4ba6f29b134167dc23a449bf5
Signed-off-by: Allen Martin <amartin@nvidia.com>
Reviewed-on: http://review.coreboot.org/3949
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
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>
This retrieves back the value stored with store_initial_timestamp()
in the bootblock for southbridge.
Change-Id: I377c823706c33ed65af023d20d2e4323edd31199
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3908
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
The way those variables work has changed twice since this file was last
changed, and console output was no longer working. Now that they're up to
date there's serial output from beaglebone again.
Change-Id: I5167fd8c0a8c33438d7f056fdf5951bd054010ed
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3923
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.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>
Use BSP CPU's stack space to store CAR GLOBALS for the
duration of romstage before CAR migration.
NOTE: Such globals can only be accessed from BSP CPU due
the way AMD platform has memory architecture set up.
TODO: Add compile-time assertions to verify CAR configuration
matches with the programming in vendorcode.
Change-Id: Ica4700433268f484ce69a24d934732f9cfd4ba41
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3832
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.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)
The AMD AGESA function to move the stack from cache-as-ram to
actual RAM doesn't need any help. The current implementation has
an INVD instruction just before cache-as-RAM is torn down. It isn't
needed for Trinity processors and makes Kabini boot unreliable.
Change-Id: Ibe9e4105eee032471ccbb2d537471d5fa5847d22
Signed-off-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3852
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Split the Family16 (Kabini) DSDT file into logical regions.
Olive Hill is the only mainboard and Kabini is the only NB/CPU
currently using Family16 AGESA code.
Change-Id: I9ef9a7245d14c59f664fc768d0ffa92ef5db7484
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3821
Tested-by: build bot (Jenkins)
This change brings back the possibility to disable console
output while in romstage, like before commit d2f45c65.
For some platforms (AMD multi-socket) USBDEBUG and/or CBMEM
CONSOLE do not work correctly for romstage due the way
cache-as-ram is set up, but might already work for ramstage.
Change-Id: Id8d830e02a18129af419d3b5860866acf315d531
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3846
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Change-Id: I4a1d2118aeb2895f3c2acea5e792fbd69c855156
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3781
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The added device.h file was indirectly picked from cpu.h, which will
have this include removed in a follow-up patch.
Change-Id: Ifc0a4800de3b1ef220ab1034934f583be8c527b0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3826
Tested-by: build bot (Jenkins)
The code to figure out how to set num_starts was
starting to get kludgy. It's a constant for a given
CPU; constants should be constant; make it a config variable.
This change includes an example of how to override it.
Build but not boot tested; drivers welcome.
Change-Id: Iddd906a707bb16251615c7b42f2bfb5a044379b4
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3796
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Split the Parmer, Family 15tn, and Hudson DSDT into groups. This splits
the DSDT table into includable ASL files which carry details specific
to the Family 15tn APU, the Parmer platform, and the Hudson FCH. The
dsdt.asl file in the mainboard directory contains only #include
references to the appropriate files.
Initially, this split was done by moving each piece of functionality
into its own file (e.g. IRQ routing and mapping, processor tree, sleep
states and sleep methods, etc.) and those pieces were #included in
dsdt.asl to ensure an exact match (via acpidump/acpixtract/iasl -d)
with the extant version of the table. Once the new tables were found
to exactly match the existing tables, the pieces were rearranged into
reasonable groups (e.g. fch.asl, northbridge.asl, pci_int.asl, etc.).
Some include files have no content but are left as a template for
other platforms and as placeholders for completing the ACPI
implementation for Parmer (e.g. thermal.asl, superio.asl, ide.asl,
sata.asl, etc.).
Change-Id: I098b0c5ca27629da9bc1cff1e6ba9fa6703e2710
Signed-off-by: Steve Goodrich <steve.goodrich@se-eng.com>
Reviewed-on: http://review.coreboot.org/3629
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The SOC's built in ROM loads the bootblock and the ROM stage into the on chip
memory before handing over control to the bootblock. To avoid having to add
one or more driver to the bootblock so that it can re-load the ROM stage from
whatever media Coreboot is stored on, we can just take advantage of the copy
that's already there. Loading the RAM stage/payloads won't be so simple,
so the ROM stage and the RAM stage will have to have different media drivers.
Change-Id: Id74ed4bc3afd2063277a36e666080522af2305dd
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3583
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This variable wasn't being defined and was defaulting to zero when used in the
ROM stage's linker script. This change defines it as a variable, and gives it
a value which is slightly beyond the end of the bootblock. By making the ROM
stage request to be loaded slightly farther into memory than it was loaded by
the SOC's masked ROM, we ensure that it's moved away from the stage's metadata
instead of on top of it. When it moves the other way, it clobbers important
values like the entry point vefore the bootblock has had a chance to use them.
Change-Id: I027a1365d05f1d79d7fc1e1349965ccb7d4e81b9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3582
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
PCI bus operations are static through the ramstage, and should be
initialized from the very beginning. For all the replaced instances,
there is no MMCONF_SUPPORT nor MMCONF_SUPPORT_DEFAULT selected for
the northbridge, so these continue to use PCI IO config access.
Change-Id: I658abd4a02aa70ad4c9273568eb5560c6e572fb1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Store EHCI Debug Port runtime variables in CAR_GLOBAL.
For platforms without CAR_MIGRATION, logging on EHCI Debug Port is
temporarily lost when CAR is torn down at end of romstage.
On model_2065x and model_206ax ehci_debug_info was overlapping the MRC
variable region and additionally migration used incorrect size for
the structure.
Change-Id: I5e6c613b8a4b1dda43d5b69bd437753108760fca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3475
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Data is intended to be a byte array, so it should be described by a type which
has a fixed size equal to an 8 bit byte. Also, the data passed to write
shouldn't be modified and can be const.
Change-Id: I6466303d962998f6c37c2d4006a39c2d79a235c1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3721
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The workaround of re-opening device in exynos_spi_read has been fixed by the new
correct open/close and xfer procedure. It's safe to be removed now.
Change-Id: I6b1bf717c916903999a137998a578b0a866829bd
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3715
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Switch spi_xfer and exynos_spi_read to use the new spi_rx_tx function.
Change-Id: I01ab43509df1319672bec30dd111f98001d655d0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3714
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SPI driver (exynos_spi_rx_tx) was implemented with only "read" ability and
only full-duplex mode. To communicate with devices like ChromeOS EC, we need
both output (tx) and half-duplex (searching frame header) features.
This commit adds a spi_rx_tx that can handle all cases we need.
Change-Id: I6aba3839eb0711d49c143dc0620245c0dfe782d8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3713
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The original Exynos SPI open/close procedure was copied from U-Boot SPL with
some assumptions that only works in SPL stage. For example, it tries to always
work in 4-byte transmission mode with only RX data is swapped, and claims a
packet for initial address command (and with incorrect size).
This commit revises open/close and reset so only the required SPI registers are
configured.
Change-Id: Ieba1f03d80a8949c39a6658218831ded39853744
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3712
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fill the SPI device parameters for spi_setup_slave on Exynos 5420.
Change-Id: I10b4b9e6cfe46d7bfa34e80e3727c7e7da99ba9d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SPI module in Exynos 5420 didn't follow Coreboot's SPI API standard
(spi-generic.h) and will be a problem when we want to share SPI drivers.
This commit replaces exynos_spi_* by spi_* functions.
Note, exynos_spi_read is kept and changed to a static function because its usage
is different from the standard API "spi_xfer".
Change-Id: I6de301bc6b46a09f87b0336c60247fedbe844ca3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3710
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remove unused header and constant definition in SPI module.
Change-Id: I339e603f48186e4a356e83518b0d0b4c907f11b8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3709
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add SPI0 and SPI2 to Exynos 5 SPI list, and correct structure names.
Also removed the un-enumerated devices (SPI_BASE, base_spi()).
Change-Id: Ica6d9a41f9619c8c61eab664d5e988dd4a428e09
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3708
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some initialization / shutdown commands should be paired correctly in a SPI I/O
session. For example, setting CS should be enabled and disabled in each read;
and the bus width (byte or word) should be configured only when opening /
closing the SPI device.
Change-Id: Ie56b1c3a6df7d542f7ea8f1193ac435987f937ba
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The functions which checked the status of a transfer would return success if
the bus was no longer occupied, even if it's no longer occupied because the
transfer failed. This change modifies those functions to return three possible
values, 0 if the transfer isn't done, -1 if there was a fault, and 1 if the
transaction completed successfully.
Change-Id: Idcc5fdf73cab3c3ece0e96f14113a216db289e05
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3704
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The exynos manual suggests hooking the mmc ip blocks to the mpll. They had
been set to use a different pll. This changes them over and modifies the
divider so that the frequency stays the same.
Change-Id: I85103388d6cc2c63d1ca004654fc08fcc8929962
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3703
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This allows us to set different speeds for each HSI2C bus.
Change-Id: I50cc257aad9ef50025d0837b0516940b956efc02
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3701
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change adjusts some clock settings so that they match U-Boot. There are
three different changes.
1. Change the source for psgen from the oscillator clock to the pclk.
2. Change the pll feeding the SPI busses from epll to mpll, as suggested in
the manual.
3. Change the SPI prescaller.
Change-Id: Ib54a255bc14fc286629dac86db9b8cf8e75a610b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3700
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The clock divider was being read from registers incorrectly which meant that
the periph rate was wrong.
Change-Id: I50efb62849ef29bdfb0efc56c49642d3edca094c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3699
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Wait for UART FIFO to be ready.
(Credit to dhendrix for finding the bits to test with.)
Change-Id: Ib6733e422cbc1c61b942bd90d85f88a3f412d6ff
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3698
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... this is needed for libpayload to talk to USB devices.
(forward ported from https://gerrit.chromium.org/gerrit/#/c/55554)
Change-Id: I5a20864689efd0c0149775e6d85b658e0cc6715c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3697
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... this is needed for libpayload to talk to USB devices.
Change-Id: I7eb19003c9e96efb5fa7a3f97c7b15f3ef332687
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I5cddffc2e524aae7a31a8f94f67e03a5b7e15c82
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3695
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I6b28bb95c7decbe3eed33b5b5a029bee48bbe403
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3691
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The members data structures in dmc.h are intended to have a particular size.
Rather than assume that particular types are the right size, we should use
types that are guaranteed to be the right size. Also, since the registers are
at particular offsets as well, the structures should be packed.
Change-Id: I9cc11d7451f92ba3eb85c6be88ecbc62c7a5652d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3685
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The previous driver was a bit awkward and not entirely correct. This change
primarily replaces the read/write functions with simpler and more robust
(hopefully) version.
Change-Id: I55f0ad8faec2de520e27577bd6dad9c0118d8171
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3684
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For all other CPUs, we unconditionally include the CPU Kconfig
files in the CPU directory, not in the vendor directory. Do the
same thing for the Exynos CPUs. This allows us to make CPU dependent
changes in the directory of that CPU alone.
Also, drop some unused Kconfig variables from the Exynos Kconfig
files.
Change-Id: I4e4c22a0693988834e619dd33d121bf994ed57e8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3683
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This updates the low-level I2C code to handle the new high-speed
HSI2C/USI inteface. It also outputs a bit more error information
when things go wrong. Also adds some more error prints. Timeouts
really need to be noted.
In hsi2c_wait_for_irq, order the delay so that we do an initial
sleep first to avoid an early-test that was kicking us out of the
test too soon. We got to the test before the hardware was ready
for us. Finally, test clearing the interrupt status register every time
we wait for it on the write. Works.
Change-Id: I69500eedad58ae0c6405164fbeee89b6a4c6ec6c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3681
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We saw a problem on x86 last year in which setting direction, then value,
glitched the output and caused problems. Change this code to set the output,
then the direction.
Change-Id: I3e1e17ffe82ae270eea539530368a58c6cfe0ebe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3679
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The 5420 clock code still had a data structure in it for the 5250 clock
registers which was used by some of the clock functions. That caused some
clocks to be configured incorrectly, specifically the i2c clock which was
running at about 80KHz instead of about 600KHz as configured by U-Boot.
Also, the registers and bit positions used to set up the SPI bus were not
consistent with U-Boot, and if the bus clock rate were set to 50MHz, a rate
which has historically worked on snow, loading would fail. With these fixes
the clock rate can be set to 50MHz and the device boots as much as is
expected. I haven't yet measured the actual frequency of the bus to verify
that it's now being calculated correctly.
Change-Id: Id53448fcb6d186bddb3f889c84ba267135dfbc00
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3678
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested and working. Gets us to ramstage.
Change-Id: Ib9ea4a6c912e8152246aaf4f1f084a4aa1626053
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds entries for I2C8-10 to giant switch statement in
clock_get_periph_rate(). It also eliminates the I2C peripheral's
usage of clk_bit_info since it's confusing and error-prone.
Change-Id: I30dfc4c9a03fbf16d08e44e074189fb9021edb6d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The pinmux code for the exynos5250 was all bundled into a single, large
function which contained a switch statement that would set up the pins for
different peripherals within the SOC. There was also a "flags" parameter, the
meaning of which, if any, depended on which peripheral was being set up.
There are several problems with that approach. First, the code is inefficient
in both time and space. The caller knows which peripheral it wants to set up,
but that information is encoded in a constant which has to be unpacked within
the function before any action can be taken. If there were a function per
peripheral, that information would be implicit. Also, the compiler and linker
are forced to include the entire function with all its cases even if most of
them are never called. If each peripheral was a function, the unused ones
could be garbage collected.
Second, it would be possible to try to set up a peripheral which that function
doesn't know about, so there has to be additional error checking/handling. If
each peripheral had a function, the fact that there was a function to call at
all would imply that the call would be understood.
Third, the flags parameter is fairly opaque, usually doesn't do anything, and
sometimes has to have multiple values embedded in it. By having separate
functions, you can have only the parameters you actually want, give them
names that make sense, and pass in values directly.
Fourth, having one giant function pretends to be a generic, portable API, but
in reality, the only way it's useful is to call it with constants which are
specific to a particular implementation of that API. It's highly unlikely that
a bit of code will need to set up a peripheral but have no idea what that
peripheral actually is.
Call sights for the prior pinmux API have been updated. Also, pinmux
initialization within the i2c driver was moved to be in the board setup code
where it really probably belongs. The function block that implements the I2C
controller may be shared between multiple SOCs (and in fact is), and those
SOCs may have different pinmuxes (which they do).
Other places this same sort of change can be made are the pinmux code for the
5420, and the clock configuration code for both the 5250 and the 5420.
Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we
make it uncacheable first, the writes will be serialized writes of
whatever sized chunks memset uses, probably 4 bytes or less.
Change-Id: I960f87a370e97f9e91236ad796d931573bb3dbb8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3668
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
At one time it seemed to be necessary to disable and then re-enable the
MMU when setting the framebuffer to be uncache-able due to bugs in the
MMU management code. Since those bugs have been fixed, this is no longer
necessary.
Change-Id: I7ce825cf5eaaa95119364d780cba0935752e4632
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3667
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already
known when that structure was put together. Eliminate the extra space,
and pass the single value instead of the structure.
Change-Id: I29bc17488539dbe695908e47f0b80c07e102e17d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/3666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code which figured out the rate of the input clock to a peripheral was
doing several things wrong. First, it was using the wrong values when
determing what the source of a clock was set to. Second, it was using the
wrong offset into that register to find the current source setting.
This change fixes the constants which select a clock source which get some
more things working, but doesn't attempt to fix the bit position table.
Change-Id: Id7482ee1c78cec274353bae3ce2dccb84705c66a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3665
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3664
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On x86 there is a 16-byte alignment requirement for the
addresses containing the CPU microcode. The cbfs files
containing the microcode are used in memory-mapped fashion
when loading new mircocode. Therefore, the data payload's
address/offset of a cbfs file in flash dictates the resulting
alignment. Fix this by processing the CPU microcode cbfs
file separately as it uses $(CBFSTOOL) to find the proper
location within the provided rom image.
Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3663
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
Change-Id: I30d2a0c7131b8e4ec30c63eea36944ec111a8fba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The new code is stolen from U-Boot with little or no understanding of how it
works.
Change-Id: I3de7d25174072f6068d9d4fdaa308c0462296737
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function had been declared in a public header file, but was marked
static when actually defined.
Change-Id: Ia551a5a12e7dbaf7bc00861e085695145ab7b91a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3657
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I983d011c6ca602445f447d17799c1b2a33e8bd1d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we make
it uncacheable first, the writes will be serialized writes of whatever sized
chunks memset uses, probably 4 bytes or less.
Change-Id: I1b81731cfed00ae091ba6357451ab186d16f559e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3655
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
At one time it seemed to be necessary to disable and then re-enable the MMU
when setting the framebuffer to be uncache-able due to bugs in the MMU
management code. Since those bugs have been fixed, this is no longer
necessary.
Change-Id: I5f7b9bd14dc9929efe1834ec9a258d388b8c94e9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already known
when that structure was put together. Eliminate the extra space, and pass the
single value instead of the structure.
Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3652
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These pins will be driven by the internal controller which shouldn't have pull
ups or downs in the pin fighting with them.
Change-Id: I579aed84ace45d8f5f1d3ca64c064d98de842b57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3649
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some of the settings which were defaulted to or automatically selected for the
exynos5420 which were inherited from the exynos5250 were not correct for this
SOC.
Change-Id: I11ffd8a6b80628405ac493fe2139f79c05d15d7e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3645
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change creates an exynos5420 directory with code that will eventually
implement support for the exynos5420 cpu from Samsung. Currently it's a copy
of the exynos5250 directory with the name changed. There are going to be some
problems where headers in src/cpu/samsung/exynos-common include headers in the
exynos5250 directory directly.
Change-Id: Ia8d7244310d32499238bbc171c0c668ec48178e1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3644
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3643
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>
Change-Id: Ice28114e5f53f510d305cd85d095044e2f4bd7b2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3740
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
It turns out that the exynos5-common code previously imported from
u-boot is not common code at all but very specific to the 5250 and
not compatible with the 5450. Hence, unify the directories exynos5250
and exynos5-common. We will try to factor out common code while
progressing with the 5450 port.
Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3641
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3640
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch was started by Dave Hendricks and implements the procedure for
setting up the UART as described in the manual. Some unused code was removed.
Change-Id: If26a424cac401ef3eafaec081147f41184fbcee9
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3490
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The pinmux register data structure describes a subset of the control module
registers, but the address which pointed to the base of the pinmux registers
was actually being set to the beginning of all the control module registers,
not just those having to do with the pinmux. With this address fixed, the UART
now works on the beaglebone black.
Change-Id: I7c99b6f37d7da359af074127cd0c1a86fda2d9a0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3574
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch is based on 'AMD S3: Program the flash in a bigger data packet'[1]
Some AMD south bridge can write bigger data when saving S3 info.
In this patch, I use config 'AMD_SB_SPI_TX_LEN' to contral data size.
AMD_SB_SPI_TX_LEN is defined in 'src/southbridge/amd/Kconfig'
and then can be overridden in the Kconfig for specific
southbridges that support larger size.
I have tested on AMD Parmer and Thatcher. We will release a new board
whose south bridge can transfer more than 4 bytes each time.
[1] http://review.coreboot.org/#/c/2306/
Change-Id: Id984955d46eae487e39d45979f1a90054aa9f54b
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3413
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Non-S3 resume paths of sandy/ivybridge call cbmem_initialize()
more than once. Doing car_migrate_variables() more than twice caused
at least loss of some lines in CBMEM console.
Change-Id: Idd14aba9384984aa3a7d38937a4b3572aa5dc088
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
I was unable to find documentation that said what mode numbers correspond
to what functionality, so I translated over what U-Boot does.
Change-Id: I34fab0f024fa2322d6bb66106aed75224e67354d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3489
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for the new q35 chipset emulation
added in qemu 1.4.
Change-Id: Iabfaa1310dc7b54c9d224635addebdfafe1fbfaf
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3430
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
An uninitialized RAM value was used to select an MSR because a $ was forgotten
in front of `CPU_DM_CONFIG0`. It should be the constant value 0x1800, corresponding
to CPU_DM_CONFIG0 MSR defined in `src/include/cpu/amd/lxdef.h`.
Change-Id: Id53ca98b06cc4a9b55916fd8db23904f98008d45
Signed-off-by: Christopher Kilgour <techie@whiterocker.com>
Reviewed-on: http://review.coreboot.org/3478
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
With this patch, output on usbdebug also includes the section of
MTRR setups for every CPU. This makes usbdebug output almost identical
with that of serial port and CBMEM console.
Tested with model_206ax. Also tested previously on model_f2x which does
not have these disable/enable calls in model_f2x_init() without detected issues.
Change-Id: Idfd0e93439907b17255633658195d698feab3895
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3423
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
In function OemAgesaSaveMtrr of 'src/cpu/amd/agesa/s3_resume.c',
there are many code like this:
msr_data = rdmsr(0x258);
flash->write(flash, nvram_pos, 4, &msr_data.lo);
nvram_pos += 4;
flash->write(flash, nvram_pos, 4, &msr_data.hi);
nvram_pos += 4;
Add a function write_mtrr to do this.
Change-Id: Id6464e637db1758b07ac2d79d3be1375a8d49651
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3410
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a struct for referencing UART registers. The layout is quite
strange on this chip, as the entire register space can take on three
different meanings depending on the line control settings (in the LCR
register) And to make things more confusing, some offsets reference
different registers depending on if a read or a write operation is
used.
Change-Id: Ie62af9c0e0edafd01b81686a0fe5c5c1d4fa06c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The current method will treat hex values as 0 and would calculate the wrong
size. This change switches back to an earlier method which used shell syntax
to add the offset and size.
Change-Id: I9fb2d9b323f113cc56a5ad2e38b47d2d22084f08
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3432
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The bootblock and ROM stages are the only ones that are really required to be
loaded in the quite limited on chip RAM during startup. Rather than load the
whole image which requires everything to be small, load just the bootblock and
the ROM stage, allowing the rest of the image to be arbitrarily large. Loading
a minimal amount of stuff should also improve boot performance a little bit.
Change-Id: I2fede63b8d3d8f0d880e4a692ae423021f8232b6
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3421
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Loading on an OMAP SOC requires that the first sector of the image have a
configuration header, and, when not an execute in place image, an additional
header which describes how big the image is and where it should be loaded.
This change adds some infrastructure to statically build that header using C
code, and to paste the header onto the front of coreboot.rom in a new top
level target file called MLO.
The configuration header we're using is as inert as possible, in line with
what U-Boot is doing. I think it could be used to give additional
configuration parameters to the built-in ROM on the SOC, but we don't need to
do that, and there didn't seem to be any actual documentation how to do that.
Because the header is built from C and is defined per CPU, it would be
possible to include extra settings in other CPUs if desired.
Adding a new top level build target is a bit disruptive, but should be
contained to the am335x directory and not interfere with other mainboards.
Change-Id: I06d346a4050c20963b3c7c6e8a152070bf2d145a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3332
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
fam15 vendorcode (src/vendorcode/amd/agesa/f15tn) was licensed under the
AMD software license agreement. Change this license to 3-clause BSD.
Change-Id: I7cab09bb58ef7cd24602628e2278672d577214a2
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds a qemu x86 cpu chip. It has no initialization function
as this isn't needed on virtual hardware. A virtual machine can have
pretty much any CPU: qemu emulates a wide range of x86 CPUs (try 'qemu
-cpu ? for a list), also with 'qemu -cpu host' the guest will see a cpu
which is (almost) identical to the one on the host machine. So I've
added X86_VENDOR_ANY as wildcard match for the cpu_table.
Change-Id: Ib01210694b09702e41ed806f31d0033e840a863f
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3344
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
While we had support for updating microcode on the VIA Nano CPUs for a
while now, we never included the actual microcode. Unlike, Intel and
AMD CPUs, VIA microcode is not available for download, and was
extracted from the vendor BIOS. It was not included in coreboot since
we never had explicit permission to do so. I have just received
confirmation from VIA that we can distribute the microcode.
Change-Id: I4c15b090cd2713cfe5dc6b50db777ff89dbc0f19
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3357
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
There were assumptions being made in the haswell
MP and SMM code which assumed the APIC id space
was 1:1 w.r.t. cpu number. When hyperthreading is
disabled the APIC ids of the logical processors
are all even. That means the APIC id space is sparse.
Handle this situation.
Change-Id: Ibe79ab156c0a171208a77db8a252aa5b73205d6c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3353
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some settings in the am335x Kconfig weren't actually used for anything, some
where place holders, and some where left over from another CPU. The memory
addresses are in the internal RAM in the SOC as described in the reference
manual. The stack is put where the internal ROM had its stack, and the
bootblock is put at the bottom of that region as the manual suggests. The
ROM stage offset is set to 10K which is a bit bigger than the ~7.5K the
bootblock currently takes up.
Change-Id: I1a117d789a791d7e3db1118823f8216b3361433c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3327
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Initial structure of Beaglebone port
Change-Id: Ia255ab207f424dcd525990cdc0d74953e012c087
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit »haswell: 24MHz monotonic time implementation« (c46cc6f1) [1]
added the Kconfig variable `MONOTONIC_TIMER_MSR` with a help text,
but only used one space instead of the suggested two spaces for
indentation. So add one space.
»Lines under a "config" definition are indented with one tab, while
help text is indented an additional two spaces.« [2]
[1] http://review.coreboot.org/3153
[2] https://www.kernel.org/doc/Documentation/CodingStyle
(Chapter 10: Kconfig configuration files)
Change-Id: I39cf356bfd54c66a2f1b837c6667dcc915e41f29
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3262
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The haswell code allows for vboot ramstage verification.
However, that code path relies on accessing global cache-as-ram
variables after cache-as-ram is torn down. In order to avoid
that situation enable cache-as-ram migration.
cbmemc_reinit() no longer needs to be called from romstage
because it is invoked automatically by the cache-as-ram
migration infrastructure.
Change-Id: I08998dca579c167699030e1e24ea0af8802c0758
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3236
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
build-snow got broken when the snow makefile improved. So fix it.
While we're at it, create a script like the update-microcode
scripts that gets the bl1. I thought about making this a common
script but the various names and paths always evolve, leaving
me thinking it's not worth it. This script is just a
piece of the snow build script.
Change-Id: I65c0f8697a978c62fe12533c4f0152d14dbaefda
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3238
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
Change-Id: Ie39b9eb565eb189676c06645bdf2a8720fe0636a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3207
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some entries still used spaces while others used tabulators[1]. Convert
spaces to tabs to uniformly use tabs.
---------------------- 8< -------------- 8< -----------------------------
For all of the Kconfig* configuration files throughout the source tree,
the indentation is somewhat different. Lines under a "config" definition
are indented with one tab, while help text is indented an additional two
spaces. [2]
---------------------- 8< -------------- 8< -----------------------------
[1] http://en.wikipedia.org/wiki/File:HollerithMachine.CHM.jpg
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle?id=HEAD
Change-Id: Iee80ad4a90e95b925afbb0c6adc563fa3a6503cf
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3173
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Since the TSC udelay() function can be used in SMM that means the
TSC can count up to whatever value. The current loop was not handling
TSC rollover properly. In most cases this should not matter as the TSC
typically starts ticking at value 0, and it would take a very long time
to roll it over. However, it is my understanding that this behavior is
not guaranteed. Theoretically the TSC could start or be be written to
with a large value that would cause the rollover.
Change-Id: I2f11a5bc4f27d5543e74f8224811fa91e4a55484
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3171
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When the haswell MP/SMM code was developed it was using a coreboot
repository that did not contain the asmlinkage macro. Now that the
asmlinkage macro exists use it.
BUG=None
BRANCH=None
TEST=Built and booted.
Change-Id: I662f1b16d1777263b96a427334fff8f98a407755
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3203
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have the monotonic timer implemented on exynos now, and this
also enables helpful bootstage prints with timing info.
Change-Id: I3baa4c9d70d4b4d059abd5e05eddcabd5258dbfd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3210
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Some boards use the local apic for udelay(), but they also provide
their own implementation of udelay() for SMM. The reason for using
the local apic for udelay() in ramstage is to not have to pay the
penalty of calibrating the TSC frequency. Therefore provide a
TSC_CONSTANT_RATE option to indicate that TSC calibration is not
needed. Instead rely on the presence of a tsc_freq_mhz() function
provided by the cpu/board. Additionally, assume that if
TSC_CONSTANT_RATE is selected the udelay() function in SMM will
be the tsc.
Change-Id: I1629c2fbe3431772b4e80495160584fb6f599e9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of using the local apic timer for udelay() use the tsc.
That way SMM, romstage, and ramstage all use the same delay
functionality.
Change-Id: I024de5af01eb5de09318e13d0428ee98c132f594
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3169
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/)
which was reverted due to unsatisfied dependencies.
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This goes thru various call sites where we used timer_us() and updates
them to use the new monotonic timer API.
udelay() changed substantially and now gracefully handles wraparound.
Change-Id: Ie2cc86a4125cf0de12837fd7d337a11aed25715c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3176
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This reverts commit 2fde9668b4
Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself.
Reverting this until the other two go in.
Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3195
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5
Reviewed-on: http://review.coreboot.org/3177
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit
commit 825c78b5da
Author: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Date: Thu May 2 18:06:03 2013 -0600
mainboard/{asus/f2a85-m,amd/thatcher}: move UDELAY_LAPIC
Reviewed-on: http://review.coreboot.org/3178
adds `UDELAY_LAPIC` to `cpu/amd/agesa/family15tn/Kconfig`. This is
not needed, because since commit
commit e135ac5a7e
Author: Patrick Georgi <patrick.georgi@secunet.com>
Date: Tue Nov 20 11:53:47 2012 +0100
Remove AMD special case for LAPIC based udelay()
Reviewed-on: http://review.coreboot.org/1618
`select UDELAY_LAPIC` is present in `src/cpu/amd/agesa/Kconfig` which
applies also to AMD Family 15tn.
Therefore remove `select UDELAY_LAPIC` again from
`cpu/amd/agesa/family15tn/Kconfig`.
Change-Id: I98b783a97c4a1e45ecb29b776cb3d3877bad9c0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3179
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
This implements the new monotonic timer API using the global
multi-core timer (MCT).
Change-Id: Id56249ff5d3e0f85808f5754954c83c0bc75f1c1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3175
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Stefan Reinauer suggested 'select UDELAY_LAPIC' did not belong in
f2a85-m/Kconfig. It got there via copy-paste from thatcher/Kconfig
so this commit removes the 'select UDELAY_LAPIC' from both and puts
it in cpu/amd/agesa/family15tn/Kconfig
Since f2a85-m is the only Thatcher board coreboot supports right
now, this should not break any other boards.
Change-Id: I811b579c31f8d259a237d3a6724ad3b17f3a6c3e
Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-on: http://review.coreboot.org/3178
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Implement the timer_monotonic_get() using the TSC.
Change-Id: I5118da6fb9bccc75d2ce012317612e0ab20a2cac
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3155
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Implement the timer_monotonic_get() functionality based off of
the local apic timer.
Change-Id: I1aa1ff64d15a3056d6abd1372be13da682c5ee2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3154
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Haswell ULT devices have a 24MHz package-level counter. Use
this counter to provide a timer_monotonic_get() implementation.
Change-Id: Ic79843fcbfbbb6462ee5ebd12b39502307750dbb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3153
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On x86 systems there is a concept of cachings the ROM. However,
the typical policy is that the boot cpu is the only one with
it enabled. In order to ensure the MTRRs are the same across cores
the rom cache needs to be disabled prior to OS resume or boot handoff.
Therefore, utilize the boot state callbacks to schedule the disabling
of the ROM cache at the ramstage exit points.
Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3138
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This makes the intermediate rule visible so BL1 gets automatically
placed in the final image.
Change-Id: Iffb0268e5bbcbe135f2d39863ed64fa302409a22
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3141
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The "wakeup" procedure will be shared by bootblock and romstage for different
types of resume processes.
Note, this commit does not include changes in romstage/bootblock to enable
suspend/resume feature. Simply adding functions to handle suspend/resume.
Verified by successfully building and booting Google/Snow firmware image.
Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3129
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support suspend/resume, PHY control must be reset only on normal boot
path. So add a new param "mem_reset" to specify that.
Verified to boot successfully on Google/Snow.
Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds support for display bring-up on Snow. It
includes framebuffer initialization and LCD enable functions.
Change-Id: I16e711c97e9d02c916824f621e2313297448732b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3116
Tested-by: build bot (Jenkins)
Add a safety check in function `intel_update_microcode` to return when
accidentally `NULL` is passed as `microcode_updates`, which would lead
to a null pointer dereference later on.
for (c = microcode_updates; m->hdrver; m = (const struct microcode *)c) {
While at it, use `return NULL` for clarity in function
`intel_microcode_find` and include the header file `stddef.h`. for it.
The review of this patch had some more discussion on adding more
comments and more detailed error messages. But this should be done in
a separate patch.
For clarity here some history, on how this was found and what caused
the discussion and confusion.
Originally when Vladimir made this improvement, selecting
`CPU_MICROCODE_IN_CBFS` in Kconfig but not having the microcode blob
`cpu_microcode_blob.bin` in CBFS resulted in a null pointer dereference
later on causing a crash.
for (c = microcode_updates; m->hdrver; m = (const struct microcode *)c) {
Vladimir fixed this by returning if `microcode_updates` is `NULL`,
that means no file is found and successfully tested this on his
Lenovo X201.
When pushing the patch to Gerrit for review, the code was rewritten
though by Aaron in commit »intel microcode: split up microcode loading
stages« (98ffb426) [1], which also returns when no file is found. So
the other parts of the code were checked and the safety check as
described above is added.
[1] http://review.coreboot.org/2778
Change-Id: I6e18fd37256910bf047061e4633a66cf29ad7b69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2990
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This makes sure that the product ID (PRO_ID) register can be read
when the OS kernel is figuring out what kind of CPU it's running on.
For historical reference, the original U-Boot code seems to have
worked basically by accident here. The hardware has a quirk where by
reading the value before gating the IP block keeps the value
persistent. U-Boot reads the chip ID early on to distinguish between
chip family, but we do not mix code the same way so we do not read
the chip ID. Since the value has been read before the clock gating
happens, the value remains available for the kernel to use during the
decompression stage. We don't want to rely on that behavior when using
coreboot. Instead the kernel should gate unused IPs.
(credit to Gabe for finding symptom in the kernel)
Change-Id: Iaa21e6e718b9000b5558f568020f393779fd208e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3121
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This simple error led to corrupted graphics.
How annoying.
Change-Id: I2295c0df0f1d16014a603dc5d66bd4d72f3fb7c9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3120
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The original imported code used "lcdbase" and "lcd_base" which quite
predictably caused confusion and bugs. Let's put an end to this little
bit of insanity.
Change-Id: I4f995482cfbff5f23bb296a1e6d35beccf5f8a91
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3114
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
We neglected to copy xres and yres out; now we do.
Change-Id: Icc4a8eb35799d156b11274f71bcfb4a1d10e01e3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3111
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This updates the Exynos TMU code for coreboot:
- Remove dependency on device tree
- Add Makefile entries
Change-Id: I55e1b624d7c7b695b1253ec55f6ae3de8dc671bc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3107
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This simply imports the Exynos TMU driver from u-boot. It is not
built and thus should not break anything.
Change-Id: I7861132fbf97f864e4250ffbda1ef3843f296ddc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3106
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This moves the prototype for power_enable_hw_thermal_trip() to
a generic location so it can be used by generalized thermal
management code. The implementation will still be CPU-specific.
Change-Id: Iae449cb8c72c8441dedaf65b73db9898b4730cef
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3105
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This gets rid of the clock-tick based sdelay in favor of udelay().
udelay() is more consistent and easier to work with, and this allows
us to carry one less variation of timers (and headers and sources...).
Every 1 unit in the sdelay() argument was assumed to cause a delay of
2 clock ticks (@1.7GHz). So the conversion factor is roughly:
sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6)
= udelay((N * 2) / (1.7 * 10^3))
The sdelay() periods used were:
sdelay(100) --> udelay(1)
sdelay(0x10000) --> udelay(78) (rounded up to udelay(100))
There was one instance of sdelay(10000), which looked like sort of a
typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should
approximate to about 12us, so we'll stick with that for now and leave
a note.
Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3079
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The types are (esp. int) are confusing at times as to size.
Make them definite as to size.
Change-Id: Id7808f1f61649ec0a3403c1afc3c2c3d4302b7fb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3103
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This removes the wait_ms argument from the dp_controller_init(). The
only delay involved is a constant 60ms delay that happens if
everything else goes well. This delay is derived from the LCD spec
so there's no reason it should be baked into the controller code.
(This patch also has the side-effect of fixing a bug where we were
delaying on an undefined value for wait_ms).
Change-Id: I03aa19f2ac2f720524fcb7c795e10cc57f0a226e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
Split the Persimmon DSDT into common code areas.
For example, split the Southbridge specific code into
the Southbridge directory and CPU specific code into
the CPU directory. Also adding the superio.asl file
to the Persimmon DSDT tree. This file is empty for
the moment but will be necessary in the future. I have
also emptied the thermal.asl file in the mainboard
directory because it does not seem to perform as
intended (fan control does not change when it is
brought back into the code base) and it has been
inside a '#if 0' statement for a long time. Removing
it until it is decided that it is actually necessary.
This change was verified in three different ways:
1. Visual comparison of the compiled DSDT pulled from the
Persimmon after booting into Linux using the ACPI tools
acpidump, acpixtract, and iasl. The comparison was done
between the DSDT before and after doing the split work.
This test is somewhat difficult considering the expanse
of the changes. Blocks of code have been moved, and
others changed.
2. Linux logs were dumped before and after the DSDT split.
Logs dumped and compared include dmesg and lspci -tv.
Neither log changed significantly between the two compare
points.
3. The test suite FWTS was run on the Coreboot build both
before and after doing the DSDT split with the command
'sudo fwts -b -P -u'. The flag -b specifies all batch jobs,
-P specifies all power tests, and -u specifies utilities.
Interactive jobs were not run as most of them consist of
laptop checks. Again, there were no significant changes
between the two endpoints.
These tests lead me to believe that there was no change in
the functionality of the ACPI tables apart from what is
known and expected.
This patch is the first of a series of patches to split the DSDT.
The ASRock patch was merged before this one and breaks the ASROCK
E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/).
Please be aware of this dependency when pulling these patches.
Other patches that depend on this patch are
'AMD Fam14: Split out the AMD Fam14 DSDT'
(http://review.coreboot.org/#/c/3051/)
and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC'
(http://review.coreboot.org/#/c/3052/)
Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3048
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Properly use the chip settings when configuring the CPU,
at this point being purely graphics.
Change-Id: I9bc2d32c1037653837937b314e4041abc0024835
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3054
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add basic edp support to the ramstage. Not working.
Change-Id: I15086e03417edca7426c214e67b51719d8ed9341
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3055
Tested-by: build bot (Jenkins)
Basic cleanup, this code still does not work.
Change-Id: I84ed9f08fd04cd8eb74cd860e0775d8c602f42d6
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3049
Tested-by: build bot (Jenkins)
This enables type checking for safety as to help prevent errors like
http://review.coreboot.org/#/c/3038/ . Now compilation fails if the
wrong type is passed into readb/readw/readl/writeb/writew/writel
or other macros in io.h.
This also deprecates readw/writew. The previous definition was 16-bits
which is incorrect since wordsize on ARMv7 is 32-bits and there was
only 1 instance of writew (#if 0'd anyway). Going forward we should
always use read{8,16,32} and write{8,16,32} where N specifies the
exact length rather than relying on ambiguous definition of wordsize.
Since many macros relied on __raw_*, which were basically the same
(minus data memory barrier instructions), this patch also gets rid
of __raw_*. There were parts of the code which ended up using these
macros consecutively, for example:
setbits_le32(®s->ch_cfg, SPI_CH_RST);
clrbits_le32(®s->ch_cfg, SPI_CH_RST);
In such cases the safe versions of readl() and writel() should be
used anyway.
Note: This also fixes two dubious casts as to avoid breaking
compilation.
Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3045
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>
This adds a missing address-of operator. This was a subtle bug that
didn't seem to cause problems at first since the serial console
appeared to work. However it caused an imprecise external abort which
became apparent later on when aborts were unmasked in the kernel via
the CPSR_A bit.
(credit goes to Gabe Black for finding this)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I80a33b147d92d559fa8fefbe7d5642235deb9aea
Reviewed-on: http://review.coreboot.org/3038
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This moves highly board-specific code out from the Exynos5250
power_init() into Snow's romstage.c. There's no reason the CPU-
specific code should care about which PMIC we are using and
which bus it is on.
Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Display hardware is part of this SOC, and we need to be able
to set certain variables in devicetree.cb. This chip file
contains the initial things we think we need to set.
Change-Id: I16f2d4228c87116dbeb53a3c9f3f359a6444f552
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3031
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This was a first pass at display port support, we have
realized that it was ultimately a bad path. The display
hardware is intimately tied into a specific cpu and
mainboard combination, and the code has to be elsewhere.
The devicetree formatting is ugly, but it matters not:
it's changing soon.
Change-Id: Iddce54f9e7219a7569315565fac65afbbe0edd29
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3029
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Based on comments in cpu/x86/msr.h for wrmsr/rdmsr, and for symmetry,
I have added __attribute__((always_inline)) for these.
Change-Id: Ia0a34c15241f9fbc8c78763386028ddcbe6690b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2898
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
If ROM caching is selected the haswell CPU initialization code
will enable ROM caching after all other CPU threads are brought
up.
Change-Id: I75424bb75174bfeca001468c3272e6375e925122
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3016
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MP code on haswell was mirroring the BSPs MTRRs. In addition it
was cleaning up the ROM cache so that the MTRR register values were
the same once the OS was booted. Since the hyperthread sibling of
the BSP was going through this path the ROM cache was getting torn
down once the hyperthread was brought up.
That said, there was no differnce in observed boot time keeping the
ROM cache enabled.
Change-Id: I2a59988fcfeea9291202c961636ea761c2538837
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3008
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The haswell code was using the old assumption of which MTRR
was used for the ROM cache. Now that there is an API for doing
this use it as the old assumption is no longer valid.
Change-Id: I59ef897becfc9834d36d28840da6dc4f1145b0c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3007
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On certain architectures such as x86 the bootstrap processor
does most of the work. When CACHE_ROM is employed it's appropriate
to ensure that the caching enablement of the ROM is disabled so that
the caching settings are symmetric before booting the payload or OS.
Tested this on an x86 machine that turned on ROM caching. Linux did not
complain about asymmetric MTRR settings nor did the ROM show up as
cached in the MTRR settings.
Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I did not check what was once after the 'and'.
Change-Id: I9f3f725bec281a94abdb2eeb692a96fecdebcc0c
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/2999
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Previously southbridge_smm_init() was provided that did both
the clearing of the SMM state and enabling SMIs. This is
troublesome in how haswell machines bring up the APs. The BSP
enters SMM once to determine if parallel SMM relocation is possible.
If it is possible the BSP releases the APs to do SMM relocation.
Normally, after the APs complete the SMM relocation, the BSP would then
re-enter the relocation handler to relocate its own SMM space.
However, because SMIs were previously enabled it is possible for an SMI
event to occur before the APs are complete or have entered the
relocation handler. This is bad because the BSP will turn off parallel
SMM save state. Additionally, this is a problem because the relocation
handler is not written to handle regular SMIs which can cause an
SMI storm which effectively looks like a hung machine. Correct these
issues by turning on SMIs after all the SMM relocation has occurred.
Change-Id: Id4f07553b110b9664d51d2e670a14e6617591500
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2977
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a new function to configure L2 cache for the
exynos5250 and deprecates the old function.
Change-Id: I9562f3301aa1e2911dae3856ab57bb6beec2e224
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2949
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
There is an optimization that can take place when hole
carving in ranges above 4GiB. If the range is the last
range then there is no need to carve UC holes out from
the larger WB range.
This optimization also has the same assumption of choosing
WB as the default MTRR type: the OS needs to properly
handle accessing realloacted MMIO resources with PAT so
that the MTRR type can be overidden.
Below are results using a combination of options. The
board this was tested on has 10 variable MTRRs at its
disposal. It has 4GiB of RAM.
IO hole config #1: hole starts at 0xad800000
No CACHE_ROM and no WRCOMB resources (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x0000000100000000 size 0x52800000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 4/6.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
No CACHE_ROM and 1 WRCOMB resource (takes 6 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 6/7.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
CACHE_ROM and no WRCOMB resources (takes 7 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000ff800000 size 0x52000000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 11/7.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6
MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6
MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 5 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 6 base 0x0000000100000000 mask 0x0000007f00000000 type 6
CACHE_ROM and 1 WRCOMB resource (takes 8 MTRRs):
Previously this combination was impossible without the optimization.
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 12/8.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6
MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6
MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 5 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 6 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 7 base 0x0000000100000000 mask 0x0000007f00000000 type 6
IO hole config #1: hole starts at 0x80000000
No CACHE_ROM and no WRCOMB resources (takes 1 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x0000000100000000 size 0x80000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 1/2.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000080000000 mask 0x0000007f80000000 type 0
No CACHE_ROM and 1 WRCOMB resource (takes 3 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 4/3.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 2 base 0x0000000100000000 mask 0x0000007f00000000 type 6
CACHE_ROM and no WRCOMB resources (takes 3 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000ff800000 size 0x7f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 9/3.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x0000000100000000 mask 0x0000007f00000000 type 6
CACHE_ROM and 1 WRCOMB resource (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 10/4.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 2 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 3 base 0x0000000100000000 mask 0x0000007f00000000 type 6
Change-Id: Ia3195af686c3f0603b21f713cfb2d9075eb02806
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2959
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some ranges would use less variable MTRRs if an UC area
can be carved off the top of larger WB range. Implement this
approach by doing 3 passes over each region in the addres space:
1. UC default type. Cover non-UC and non-WB regions with respectie type.
Punch UC hole at upper end of larger WB regions with WB type.
2. UC default type. Cover non-UC regions with respective type.
3. WB default type. Cover non-WB regions with respective type.
The hole at upper end of a region uses the same min alignment of 64MiB.
Below are results using a combination of options. The board this was
tested on has 10 variable MTRRs at its disposal. It has 4GiB of RAM.
IO hole config #1: hole starts at 0xad800000
No CACHE_ROM or WRCOMB resources (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x0000000100000000 size 0x52800000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 4/9.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
No CACHE_ROM. 1 WRCOMB resource (takes 6 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 6/10.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
CACHE_ROM and no WRCOMB resources (taks 10 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000ff800000 size 0x52000000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 11/10.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6
MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6
MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 5 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 6 base 0x0000000100000000 mask 0x0000007fc0000000 type 6
MTRR: 7 base 0x0000000140000000 mask 0x0000007ff0000000 type 6
Taking a reserved OS MTRR.
MTRR: 8 base 0x000000014f600000 mask 0x0000007fffe00000 type 0
Taking a reserved OS MTRR.
MTRR: 9 base 0x000000014f800000 mask 0x0000007fff800000 type 0
A combination of CACHE_ROM and WRCOMB just won't work.
IO hole config #2: hole starts at 0x80000000:
No CACHE_ROM or WRCOMB resources (takes 1 MTRR):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x0000000100000000 size 0x80000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 1/5.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000080000000 mask 0x0000007f80000000 type 0
No CACHE_ROM. 1 WRCOMB resource (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 4/6.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000080000000 mask 0x0000007fc0000000 type 0
MTRR: 1 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 2 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 3 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
CACHE_ROM and no WRCOMB resources (takes 6 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000ff800000 size 0x7f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 9/6.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x0000000100000000 mask 0x0000007f80000000 type 6
MTRR: 3 base 0x000000017ce00000 mask 0x0000007fffe00000 type 0
MTRR: 4 base 0x000000017d000000 mask 0x0000007fff000000 type 0
MTRR: 5 base 0x000000017e000000 mask 0x0000007ffe000000 type 0
CACHE_ROM and 1 WRCOMB resource (takes 7 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 10/7.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 2 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 3 base 0x0000000100000000 mask 0x0000007f80000000 type 6
MTRR: 4 base 0x000000017ce00000 mask 0x0000007fffe00000 type 0
MTRR: 5 base 0x000000017d000000 mask 0x0000007fff000000 type 0
MTRR: 6 base 0x000000017e000000 mask 0x0000007ffe000000 type 0
Change-Id: Iceb9b64991accf558caae2e7b0205951e9bcde44
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2925
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Downstream payloads may need to take advantage of caching the
ROM for performance reasons. Add the ability to communicate the
variable range MTRR index to use to perform the caching enablement.
An example usage implementation would be to obtain the variable MTRR
index that covers the ROM from the coreboot tables. Then one would
disable caching and change the MTRR type from uncacheable to
write-protect and enable caching. The opposite sequence is required
to tearn down the caching.
Change-Id: I4d486cfb986629247ab2da7818486973c6720ef5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2919
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The CONFIG_CACHE_ROM support in the MTRR code allocates an MTRR
specifically for setting up write-protect cachine of the ROM. It is
assumed that CONFIG_ROM_SIZE is the size of the ROM and the whole
area should be cached just under 4GiB. If enabled, the MTRR code
will allocate but not enable rom caching. It is up to the callers
of the MTRR code to explicitly enable (and disable afterwards) through
the use of 2 new functions:
- x86_mtrr_enable_rom_caching()
- x86_mtrr_disable_rom_caching()
Additionally, the CACHE_ROM option is exposed to the config menu so
that it is not just selected by the chipset or board. The reasoning
is that through a multitude of options CACHE_ROM may not be appropriate
for enabling.
Change-Id: I4483df850f442bdcef969ffeaf7608ed70b88085
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2918
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All resources that set the IORESOURCE_WRCOMB attribute which are
also marked as IORESOURCE_PREFETCH will have a MTRR set up that
is of the write-combining cacheable type. The only resources on
x86 that can be set to write-combining are prefetchable ones.
Change-Id: Iba7452cff3677e07d7e263b79982a49c93be9c54
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2892
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The old MTRR code had issues using too many variable
MTRRs depending on the physical address space layout dictated
by the device resources. This new implementation calculates
the default MTRR type by comparing the number of variable MTRRs
used for each type. This avoids the need for IORESOURE_UMA_FB
because in many of those situations setting the default type to WB
frees up the variable MTTRs to set that space to UC.
Additionally, it removes the need for IORESOURCE_IGNORE_MTRR
becuase the new mtrr uses the memrange library which does merging
of resources.
Lastly, the sandybridge gma has its speedup optimization removed
for the graphics memory by writing a pre-determined MTRR index.
That will be fixed in an upcoming patch once write-combining support
is added to the resources.
Slight differences from previous MTRR code:
- The number of reserved OS MTRRs is not a hard limit. It's now advisory
as PAT can be used by the OS to setup the regions to the caching
policy desired.
- The memory types are calculated once by the first CPU to run the code.
After that all other CPUs use that value.
- CONFIG_CACHE_ROM support was dropped. It will be added back in its own
change.
A pathological case that was previously fixed by changing vendor code
to adjust the IO hole location looked like the following:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
As noted by the output below it's impossible to accomodate those
ranges even with 10 variable MTRRS. However, because the code
can select WB as the default MTRR type it can be done in 6 MTRRs:
MTRR: default type WB/UC MTRR counts: 6/14.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2889
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This moves the ram resource allocation into cpu_init() so that we
no longer rely on declaring a domain in devicetree.cb (which is kind
of weird for this platform). This does not cause any actual changes
to the coreboot memory table, and paves the way for further updates
to Snow's devicetree.
Change-Id: I141277f59b5d48288f409257bf556a1cfa7a8463
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2923
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 9427ca151e
Looks like we were a bit too anxious to see this one get in. The devicetree.cb change seems to have broken things.
coreboot memory table:
0. 0000000050000000-000000005000ffff: RESERVED
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
2. 0000014004000000-00000140044007ff: RESERVED
Before this patch:
coreboot memory table:
0. 0000000040000000-00000000bfefffff: RAM
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
Change-Id: I618e4f1976265d56cfd6a61d0c5736c55a0f3cec
Reviewed-on: http://review.coreboot.org/2914
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This does NOT turn on the graphics.
The device tree has been changed enough so that, at the very least, the correct
functions are called at the correct time, with the correct paramaters. We
decided to yank the I2C entries as they did not obvious function and might
not even have been correct.
Not working, seemingly, but we need to add a 4M resource for
memory, and it seems it needs to be fixed at the address shown.
This address was chosen from current hardware.
We realized that the display code should be part of the cpu -- that's how
the hardware works!
Change-Id: Ied65a554f833566be817540702f79a02e7b6cb6e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2615
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The amd_mtrr.c file contains a copy of the fixed MTRR algorithm.
However, the AMD code needs to handle the RdMem and WrMem attribute
bits in the fixed MTRR MSRs. Instead of duplicating the code
with the one slight change introduce a Kconfig option,
X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields
need to be handled for writeback fixed MTRR ranges.
The order of how the AMD MTRR setup routine is maintained by providing
a x86_setup_fixed_mtrrs_no_enable() function which does not enable
the fixed MTRRs after setting them up. All Kconfig files which had a
Makefile that included amd/mtrr in the subdirs-y now have a default
X86_AMD_FIXED_MTRRS selection. There may be some overlap with the
agesa and socket code, but I didn't know the best way to tease out
the interdependency.
Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2866
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
David Hendricks
