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.
BUG=chrome-os-partner:19420
TEST=Built for pit.
BRANCH=None
Change-Id: Ie52a5eba459bc2a070656b264e00ef783838026e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59237
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.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.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit into the RAM stage without any errors reading or
writing registers on the PMIC. There isn't really any direct feedback from the
PMIC, so I'm assuming since it didn't complain it worked. I looked at some of
the transaction on an oscilloscope and they looked correct.
BRANCH=None
Change-Id: I01b1f9ea43eafb4aae1dbebddc051cd5ec5aea74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59201
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.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.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=no functional change
BRANCH=none
Change-Id: I57667dc5c5af5f61a54186a8fd47ceeae143d688
Reviewed-on: https://gerrit.chromium.org/gerrit/59291
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I785a4b9038d25c1a564784da0b7d54eaa9ef651d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58761
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.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.
BUG=chrome-os-partner:19420
TEST=Build and boot on pit.
BRANCH=None
Change-Id: Ie40786139b0b496e22a80dc3dd712b6adff03d1e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59087
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.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.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit and saw that the SPI now works at what is
nominally 50MHz, and that the I2C bus connected to the PMIC is running at the
same frequency as it does under U-Boot.
BRANCH=None
Change-Id: I9fede9cd3defdff7cbb2a76bb0e0bf86967bebb7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59020
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Tested and working. Gets us to ramstage.
BUG=chrome-os-partner:19420
TEST=Build and boot on pit.
BRANCH=None
Change-Id: I603aec97155a468a12b3fd492521b5a4e7169f9e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57363
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.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.
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I4b006c034575e6bd1f4722503668b9a142020eb5
Reviewed-on: https://gerrit.chromium.org/gerrit/58782
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and started booting on pit.
BRANCH=None
Change-Id: I06ea5dfdb1de2d32bd1f3b276f98617c0c3efc46
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58788
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.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.
BUG=None
TEST=Built and booted Coreboot on Snow. Went into recovery mode and back.
BRANCH=None
Change-Id: Ib6f6921ffcf749da02e25519279d2dc7cbf8f2ec
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58784
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.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).
BUG=chrome-os-partner:20162.
TEST=Manual. Test on peppy board with non-zero SPD GPIOs, verify correct
SPD is selected.
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
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.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit with another change and an external tool, and was
able to get serial output. Built for snow.
BRANCH=None
Change-Id: Ie27ae7a7b22f336d23893618969efde4145fefd7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57725
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.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.
BUG=None
TEST=None
BRANCH=None
Change-Id: I59d6699fcea1c5ca4402ae6cf45df9c14878943a
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55837
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.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.
BUG=None
TEST=None
BRANCH=None
Change-Id: I1fb2bd6e14777470456e9517d3efba24c3b170a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55836
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.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.
BUG=None
TEST=None
BRANCH=None
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia21bcbfdd0007e9088c98c339aa031853a282cf5
Reviewed-on: https://gerrit.chromium.org/gerrit/55835
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.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.
BUG=chrome-os-partner:19420
TEST=Built for pit with another change and an external tool, and was able to
receive serial output.
BRANCH=None
Change-Id: Ia2cea7ce8ee2c8ae721e09069bcf9711b1d30aec
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57726
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.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.
BUG=none
TEST=manual: emerge-daisy chromeos-coreboot-snow;
emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=none
Change-Id: I9b3ee083c2edac64a653d5d7dffc123d252878d7
Reviewed-on: https://gerrit.chromium.org/gerrit/58342
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.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.
BUG=chrome-os-partner:20100
BRANCH=None
TEST=Manually inspected cbfs layout:
CBFS @ Offset 0x00700000 into 0x00800000 ROM size
[0xfff00000] cmos_layout.bin type cmos layout (0x1aa) @ 0xfff00028,
0x48c (1164) bytes
[0xfff004c0] pci8086,0406.rom type optionrom (0x30) @ 0xfff004f8,
0x10000 (65536) bytes
[0xfff10500] cpu_microcode_blob.bin type microcode (0x53) @ 0xfff10560,
0x9c40 (40000) bytes
[0xfff1a1c0] config type raw (0x50) @ 0xfff1a1e8, 0x157f (5503) bytes
[0xfff1b780] fallback/vboot type stage (0x10) @ 0xfff1b7a8, 0x3ad3
(15059) bytes
[0xfff1f280] (empty) type null (0xffffffff) @ 0xfff1f2a8, 0xcd8 (3288)
bytes
[0xfff1ff80] fallback/romstage type stage (0x10) @ 0xfff1ffe4, 0xa001
(40961) bytes
[0xfff2a000] fallback/coreboot_ram type stage (0x10) @ 0xfff2a038,
0x15373 (86899) bytes
[0xfff3f3c0] fallback/payload type payload (0x20) @ 0xfff3f3f8, 0xd00e
(53262) bytes
[0xfff4c440] u-boot.dtb type unknown (0xac) @ 0xfff4c468, 0x1e4b (7755)
bytes
[0xfff4e2c0] (empty) type null (0xffffffff) @ 0xfff4e2e8, 0x51cd8
(335064) bytes
[0xfff9ffc0] mrc.bin type mrc (0xab) @ 0xfffa0000, 0x2d8b8 (186552)
bytes
[0xfffcd8c0] (empty) type null (0xffffffff) @ 0xfffcd8e8, 0x1e6d8
(124632) bytes
[0xfffebfc0] spd.bin type mrc (0xab) @ 0xfffec000, 0x200 (512) bytes
[0xfffec200] (empty) type null (0xffffffff) @ 0xfffec228, 0x13418
(78872) bytes
Change-Id: Icc676a1c76c368d77e48cf573c6f846301da42a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58238
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Change every "boot loader 1" to be same file name in different folders.
BUG=none
TEST=manual: emerge-daisy chromeos-firmware-snow
BRANCH=none
Change-Id: Ie709b74b3bd3340f2cdc7b5685300102340bb399
Reviewed-on: https://gerrit.chromium.org/gerrit/58125
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.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.
BUG=chrome-os-partner:19928
BRANCH=none
TEST=manual: enter recovery with crossystem recovery_request=193
Change-Id: Ic927c69a95a2114e29c343f0dcc28374266db394
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57470
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=chrome-os-partner:19355
BRANCH=None
TEST=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>
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.
BUG=chrome-os-partner:19699
BRANCH=None
TEST=Used HT disabled part on WTM2. No more spontaneous reboots.
Change-Id: Ia4e3aa7456092e0ac0ea0ef16f10ba638a3e6dbe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56824
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The new code is stolen from U-Boot with little or no understanding of how it
works.
BUG=chrome-os-partner:16132
TEST=Built for pit. Verified that boot progressed past clock initialization.
BRANCH=None
Change-Id: I3f826e799529adee89898015af9e3f3a5114b7f5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55570
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This function had been declared in a public header file, but was marked
static when actually defined.
BUG=chrome-os-partner:16132
TEST=Built for pit.
BRANCH=None
Change-Id: I7cc9e583c20e54c926b805fcc49b06b629c8a508
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55569
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.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.
BUG=none
TEST=not yet, pit is still in early bringup.
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I8165622580e1fbe76e1ad06805dc87b4a06b27d8
Reviewed-on: https://gerrit.chromium.org/gerrit/55808
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.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.
BUG=None
TEST=Built and booted on Snow. Verified that graphics were drawn completely.
BRANCH=None
Change-Id: I94c81145b422eb440c7698273e7f3944c5ee486e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55640
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=None
TEST=Boot on Snow and verified that graphics are still displayed correctly.
BRANCH=None
Change-Id: Ibfd12c1f45c57994cd970751be7aee106a5ff0a1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55639
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=None
TEST=Built and booted on Snow.
BRANCH=None
Change-Id: Ied4d293cd96dfd93543aa523b8c3a14aec7080f5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55637
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
These pins will be driven by the internal controller which shouldn't have pull
ups or downs in the pin fighting with them.
BUG=None
TEST=Built and booted on snow.
BRANCH=None
Change-Id: Ia0fc84cd4575e80b2148dce27e14bb7e5042d473
Reviewed-on: https://gerrit.chromium.org/gerrit/55634
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:16132
TEST=Built for pit and verified that it was able to get past setting up the
pinmux for the serial port which it wasn't before. Used some primitive checks
to verify that some of the registers being modified were in the right place.
BRANCH=None
Change-Id: I2fff71d821a6ed092cd2ecbd197a93e2189e6596
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55567
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
- 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.
BUG=none
TEST=boot tested on Snow, no serial garbage and no multiple UART
init in bootblock.
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I3c203fa541ea5fffa2ae38943278d6358db45379
Reviewed-on: https://gerrit.chromium.org/gerrit/51497
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=chrome-os-partner:19420
TEST=With this and other changes, built a pit image for this CPU.
BRANCH=None
Change-Id: I2ea6d7a2531100348c365347b92bdcab8125ab4a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51459
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.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.
BUG=chrome-os-partner:19420
TEST=With this and other changes, built a pit image which uses this CPU.
BRANCH=None
Change-Id: Ib793edea2709fecbbc31e3178a0d3887f2e277b5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51458
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
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.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: I1a8de380a70d8b375ba138da3219408ef5c823b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51390
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: Ie0104a6e24cc6430a575ee3691671900c36db0d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51386
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
BUG=none
TEST=booted on Snow
BRANCH=none
Change-Id: Iafc0a27ee5266a397abfd0aa2abdb88a63298384
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51371
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.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.
BUG=none
TEST=booted on Snow
BRANCH=none
Change-Id: I7581e9005e09ad264f85d57b6771f40faa2e63af
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51216
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@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.
BUG=None
BRANCH=None
TEST=Built
Change-Id: I9d65a8e67ffdee5fd813f7554ecafbdf37b93af0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51163
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
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.
BUG=none
TEST=boot tested on snow
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I5d4ae4533174d42802dc4d0af19b81224b89c9cd
Reviewed-on: https://gerrit.chromium.org/gerrit/51169
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=none
BRANCH=none
TEST=boot tested on snow
Change-Id: Ibc56b5bf7ec60ee730b32180ad9ef415438fffaf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50911
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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
BUG=none
TEST=boot tested on Link
BRANCH=none
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>
Reviewed-on: https://gerrit.chromium.org/gerrit/50723
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
BUG=none
TEST=boot tested on snow+link
BRANCH=none
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50721
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
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.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: I0f86672e0951b51c791c63bb1173eb371b347f40
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50457
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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: I2ebd567c7c40cf5013f2c1d7e3b381171ad17a4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50454
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: Ic7096b7f5c9dec26a3f0441e6715fe02b15d44db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50453
Reviewed-by: Stefan Reinauer <reinauer@google.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.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: Iac35eb02b424b54e490b4fdaa2fc74f35066db27
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
