This fixes two problems with the clock configuration on tegra124. First, the
macro which set up the i2c clocks tried to account for the fact that the i2c
divisor's lsb represents 1.0 where it normally represents 0.5 by multiplying
the target frequency by 2. That doesn't work, unfortunately, because the
divisor is actually n + 1, and what n + 1 means depends on where the one's
place is in the divisor.
Also, when calculating the divisor, the standard C division operator uses
truncation to deal any remainder which tends to make the divisor smaller. That
has the effect of making the output frequency higher than what was requested.
Since it's usually safer to undershoot a frequency than overshoot it, this
change makes those divisions round up instead.
Finally, the hand tuned temporary UART clock configuration was adjusted so
that it still ends up with the same divisor. Without that, very early output
from the bootblock is garbled, specifically the coreboot welcome banner,
build timestamp, etc.
BUG=chrome-os-partner:27220
TEST=Built and booted on nyan. Used a logic analyzer to verify that the TPM
i2c bus ran at 400KHz instead of 660KHz, and that the divisor was the expected
value. Measured boot time with and without EFS and verified that there was no
change. Spot checked the output for errors and verified that none of the
bootblock output was garbled.
BRANCH=None
Had to add the stdlib.h from 89ed6c that hadn't been merged correctly.
Original-Change-Id: I7e948c361ed4bf58c608627d32f2e3424faea1fb
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193362
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 164f7010a47d3bbdbc8bb572106140ae186f3807)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I317b66eda929c0e5a5832adca267b8b54c6aae34
Reviewed-on: http://review.coreboot.org/7736
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To read EDID, we need to access I2C via DP AUX channel.
BRANCH=none
BUG=chrome-os-partner:25933
TEST=emerge-nyan coreboot chromeos-bootimage
Original-Change-Id: I2666b5d46843485b79265a537f19bd8eab5e1a26
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/188858
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8f8e98ff5038b57f89332aee75573095c3933dd2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5b1b6ab2940c8265483059fd94a2c4db2a41144a
Reviewed-on: http://review.coreboot.org/7735
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If EFS is enabled and vboot didn't tell us it's going to use the display, we
can skip initializing it and save some boot time.
BUG=chrome-os-partner:27094
TEST=Built and booted on nyan without EFS in recovery mode and normal mode.
Built and booted on nyan with EFS in recovery mode and normal mode. Verified
that in normal mode with EFS the display initialization was skipped and boot
time was essentially the same as when display initialization was simply
commented out.
BRANCH=None
Original-Change-Id: I1e2842b57a38061f40514407c8fab1e38b75be80
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/192544
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a672d18c3570e6991a1c1c0089697112a4cd71d0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I95e8bd7a447876174305f755cc632365ed6f5a30
Reviewed-on: http://review.coreboot.org/7734
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A leading double slash can result when $DESTDIR/$TARGETDIR is expanded
in the libelf portion of buildgcc. The leading double slash causes buildgcc to fail when run from Windows/Msys2. Replace $DESTDIR/$TARGETDIR
with $DESTDIR$TARGETDIR to avoid the problem.
Change-Id: Ide2bae41c07c1566f80104c3a2e2acab53de0d17
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7788
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
It appears the decimal value was used instead of the hex value.
Change-Id: I04acde9e5b2a9e08ed01b0564c3d561b0385a392
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/7799
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The doxygen directory is created by running 'make doxygen' - this
results in a huge number of new files that swamps graphical git tools.
Since this directory is a product of a build, it should be safe to
ignore.
Change-Id: I871dd2a36433d4dd46b231ebc7398e85d0278f27
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7798
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
For some of the boards using AMD processors, the Agesa Makefile.inc
is processed twice, causing the list of obj files passed to the ar
command to be added twice. This does not break the build, but does
make the ar command line unnecessarily long.
Change-Id: I02a7e6fc617e337ca2e2dceeff3d4db9995bfe16
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7787
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
powernow_acpi.c array TDP has 20 entries, yet the loop that reads it
processes 21 entries. This causes a gcc 4.9.2 build failure. Limit
processing to 20 entries.
Change-Id: Ice173b276293184386cd8943a3213f3154f86458
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7791
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Too many false positives, not useful enough for us at the moment
at the cost of not having the whole tree build without warnings
as errors.
Change-Id: I9f9910b7f66ebf3a82d42e7732e413ba27dbbbe7
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7778
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Remove '__attribute__((optimize("Os")))' as it is unlikely to be
necessary as it is not used in other families that have the same
code and only hides deeper issues.
Change-Id: Ica890812ebc2fb659b9c3e46b40cf3f6534b3cf2
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/7689
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
It's not useful in quiet mode, and is very distracting.
Change-Id: I59dc8caa22b66980560d5afb76eae801efaa29ad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/124
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The updated KaveriPI binary, upgrading to v1.1.0.7, requires changes
to define the PSP device (PCI 0:08.0) and the IOMMU device (PCI 0:00.2).
In the new AGESA binary, the IOMMU device is enabled and must be
disabled in devicetree.cb and agesawrapper_amdinitenv() to maintain
the same level of functionality.
Change-Id: I3f47e0bd5a75729ec1e4b7b11885d0622c474342
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/7727
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We already have aarch64 targets. Extend the "all" target.
Change-Id: I74d9bf5123695318c15b73c89f170f3ebb20aa80
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7729
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Clang complains:
"implicit truncation from 'int' to bitfield changes value from -1 to 15"
-1 is define in 'c11std 6.3.1.3p2' as:
[Signed and unsigned integers] Otherwise, if the new type is unsigned,
the value is converted by repeatedly adding or subtracting one
more than the maximum value that can be represented in the new type
until the value is in the range of the new type.60)
FOOTNOTE.60 The rules describe arithmetic on the mathem...
This is "0xFF" on Mullins and "0xF" in this case. Clang seems to
complain about this two's complement in a bitfield as being truncated.
As the bitfield is 4 bits wide, (a maximum of 15 decimal), we set the
field as '0x0F'. Ideally this field /should/ be set to 'UINT8_MAX' however
we still have silly truncation warnings.
Change-Id: Ib7476d453ffd932bb911e638117cf9f56f71f269
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7719
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Clang complains that a signed shift result (0x210000000)
requires 35 bits to represent, but 'int' only has 32 bits.
However, we write the high bits separately and so this is
a spurious warning.
Change-Id: I3e1c57334077feb50004d7b39abff4bd84ca095b
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7673
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
- add a 'quiet' mode that only prints important messages
- add vendor/mainboard to all strings printed
With quiet on, multithreaded looks like this:
skipping google/storm because we're missing compilers for (arm armv4 armv7)
iwill/dk8_htx built successfully. (took 5s)
jetway/j7f2 built successfully. (took 6s)
iwill/dk8x built successfully. (took 8s)
iwill/dk8s2 built successfully. (took 8s)
jetway/j7f4k1g5d built successfully. (took 10s)
With quiet off, single threaded now looks like this:
Building intel/emeraldlake2
Creating config file for intel/emeraldlake2...
intel/emeraldlake2 (blobs, ccache)
intel/emeraldlake2 config created.
Compiling intel/emeraldlake2 image...
intel/emeraldlake2 built successfully. (took 5s)
And quiet off multithreaded looks like this:
Building iwill/dk8_htx
Creating config file for iwill/dk8_htx...
iwill/dk8_htx (blobs, ccache)
intel/mohonpeak config created.
Compiling intel/mohonpeak image on 1 cpu...
intel/minnowmax config created.
--- snip ---
intel/mtarvon built successfully. (took 4s)
Building iwill/dk8s2
Creating config file for iwill/dk8s2...
iwill/dk8s2 (blobs, ccache)
intel/mohonpeak built successfully. (took 5s)
Building iwill/dk8x
Change-Id: Ib7b9a625d77bb8e0663afc00d7133e415866ecec
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7716
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
They were only used internal to the SPI drivers and, according to the comment
next to their prototypes, were for when the SPI controller doesn't control the
chip select line directly and needs some help.
BUG=None
TEST=Built for link, falco, and rambi. Built and booted on peach_pit and nyan.
BRANCH=None
Original-Change-Id: If4622819a4437490797d305786e2436e2e70c42b
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/192048
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 1e2deecd9d8c6fd690c54f24e902cc7d2bab0521)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ida08cbc2be5ad09b929ca16e483c36c49ac12627
Reviewed-on: http://review.coreboot.org/7708
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
spi_set_speed was never implemented, and spi_cs_is_valid was only implemented
as a stub and never called.
BUG=None
TEST=Built for rambi, falco, and peach_pit.
BRANCH=None
Original-Change-Id: If30c2339f5e0360a5099eb540fab73fb23582905
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/192045
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 98c1f6014c512e75e989df36b48622a7b56d0582)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Iebdb2704ee81aee432c83ab182246d31ef52a6b6
Reviewed-on: http://review.coreboot.org/7707
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The SPI drivers for tegra and exynos5420 have code in them which waits for a
frame header and leaves filler data out. The SPI driver shouldn't have support
for frame headers directly. If a device uses them, it should support them
itself. That makes the SPI drivers simpler and easier to write.
When moving the frame handling logic into the EC support code, EC communication
continued to work on tegra but no longer worked on exynos5420. That suggested
the SPI driver on the 5420 wasn't working correctly, so I replaced that with
the implementation in depthcharge. Unfortunately that implementation doesn't
support waiting for a frame header for the EC, so these changes are combined
into one.
BUG=None
TEST=Built and booted on pit. Built and booted on nyan. In both cases,
verified that there were no error messages from the SPI drivers or the EC
code.
BRANCH=None
Original-Change-Id: I62a68820c632f154acece94f54276ddcd1442c09
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/191192
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4fcfed280ad70f14a013d5353aa0bee0af540630)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id8824523abc7afcbc214845901628833e135d142
Reviewed-on: http://review.coreboot.org/7706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Depending on the platform the underlying regions vboot requires
may not be accessible through a memory-mapped interface. Allow
for non-memory-mapped regions by providing a region request
abstraction. There is then only a few touch points in the code to
provide compile-time decision making no how to obtain a region.
For the vblocks a temporary area is allocated from cbmem. They
are then read from the SPI into the temporarily buffer.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted a rambi with vboot verification.
Original-Change-Id: I828a7c36387a8eb573c5a0dd020fe9abad03d902
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190924
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit aee0280bbfe110eae88aa297b433c1038c6fe8a3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia020d1eebad753da950342656cd11b84e9a85376
Reviewed-on: http://review.coreboot.org/7709
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The arm architecture currently exports cache_sync_instructions()
in <arch/cache.h>. In order for rmodule loading to work on arm
architectures the cache_sync_instructions() needs to be called to
sequence the instruction cache. To avoid sprinkling #ifdefs around
just add an empty cache_sync_instructions() definition.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted nyan and rambi.
Original-Change-Id: I1a969757fffe0ca92754a0d953ba3630810556e3
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/191551
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit fda20947b928ee761d5ed15e414636af419970a6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3e8ca12e1d82ccedf1ff9851ae3c5c80cda2dd5f
Reviewed-on: http://review.coreboot.org/7710
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
TEST=Booted nyan in normal and recovery mode. Created a map, filled it with some
chars, then verified they can be read from the pointer returned.
BUG=chrome-os-partner:25587
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Id1f1be4f6d2d5734d87bf3452d4806d0fe3fda88
Original-Reviewed-on: https://chromium-review.googlesource.com/188894
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 7fda3885f51c8d383585a80e99ab3df9c789d872)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6255d11396c87f40b0ae12ceab0fd152f2478529
Reviewed-on: http://review.coreboot.org/7658
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use the SPSR to extract and inject CPSR values when an exception happens and
pass that information to exception hooks.
The register structure GDB expects when using its remote protocol has a spot
for the CPSR.
BUG=None
TEST=Built and booted on link, nyan.
BRANCH=None
Original-Change-Id: Id950fb09d72fb0f81e4eef2489c0849ce5dd8aca
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/180253
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8e7014f24a580f84c91fa7b0369dfa922918adcc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I49357fb6a65edeff7a9a48d54254308a6b0efdb7
Reviewed-on: http://review.coreboot.org/7657
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support a GDB stub, it will be necessary to trap various exceptions which
will be used to implement breakpoints, single stepping, etc.
BUG=None
TEST=Built and booted on Link with hooks installed and saw that they
triggered when exceptions occurred. Built and booted on nyan.
BRANCH=None
Original-Change-Id: Iab659365864a3055159a50b8f6e5c44290d3ba2b
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/179602
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8db0897b1ddad600e247cb4df147c757a8187626)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5e7f724b99988cd259909dd3bd01166fa52317ec
Reviewed-on: http://review.coreboot.org/7656
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To find the coreboot tables, the payload has historically searched for their
signature in a predefined region of memory. This is a little clumsy on x86,
but it works because you can assume certain regions are RAM. Also, there are
areas which are set aside for the firmware by convention. On x86 there's a
forwarding entry which goes in one of those fairly small conventional areas
and which points to the CBMEM area at the end of memory.
On ARM there aren't areas like that, so we've left out the forwarding entry and
gone directly to CBMEM. RAM may not start at the beginning of the address space
or go to its end, and that means there isn't really anywhere fixed you can put
the coreboot tables. That's meant that libpayload has to be configured on a
per board basis to know where to look for CBMEM.
Now that we have boards that don't have fixed amounts of memory, the location
of the end of RAM isn't fixed even on a per board level which means even that
workaround will no longer cut it.
This change makes coreboot pass the location of the coreboot tables to
libpayload using r0, the first argument register. That means we'll be able to
find them no matter where CBMEM is, and we can get rid of the per board search
ranges.
We can extend this mechanism to x86 as well, but there may be more
complications and it's less necessary there. It would be a good thing to do
eventually though.
BUG=None
TEST=Built and booted on nyan. Changed the size of memory and saw that the
payload could still find the coreboot tables where before it couldn't. Built
for pit, snow, and big.
BRANCH=None
Original-Change-Id: I7218afd999da1662b0db8172fd8125670ceac471
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185572
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit ca88f39c21158b59abe3001f986207a292359cf5)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Iab14e9502b6ce7a55f0a72e190fa582f89f11a1e
Reviewed-on: http://review.coreboot.org/7655
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The preceding patch copied gizmo2 from the amd/olivehill
board. This commit includes the changes required to make
the code reflect the gizmo2 hardware:
- Update the vendor Kconfig to add gizmo2
- Update the mainboard Kconfig
- Update devicetree
- Add support in for the soldered down DDR3
- Update the CODEC verb data
- Update the graphics connector settings
- Adjust the temperature thresholds for the fan
What's missing:
- Interrupt routing tables
Gizmo2 can boot DOS and Ubuntu 14.10.
Change-Id: I3d7202957c082974689f2a8c04d8cd33dbdc1a89
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/7722
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Clang warns of an implicit conversion from 'double' to 'int'
e.g. changes value from '26.67' to '26'. Thus take the floor() of
the array and not change orginal behaviour.
Change-Id: Ifcc7bbfe8d627451b82053f53a885f315e2550ec
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7725
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Correct mask to select bits 4-6 inclusively as per comment and use
bitwise operations while working with bits. Be sure to write back out
the data on the retrain.
See:
commit cab9efb2 southbridge/amd/rsXY0/cmn.c: Fix bitwise logic and mask in loop
Change-Id: I95d1799514157b7849f3e473837aaf2fd9bd59b9
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7692
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
abuild, inteltool, and superiotool's manpages still referenced reporting
bugs to tracker.coreboot.org. Remove that url and change the message
to point to the coreboot mailing list instead.
Change-Id: I7a85bc2b36ccdb7f3798a39a08345c1a02a67e65
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7712
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
- In '-ffreestanding' main() is just as any other function and so
it needs a type-signature. Fixes a clang warning.
- Bay Trail and Rangeley have the updated romstage.c with the code
moved into the chipset, put the prototype in romstage.c.
- The sandybridge code has not been updated, so the prototype
for it goes into chipset_fsp_util.h, next to the prototype for
romstage_main_continue.
- Correct the return value of baytrail main() from void * to void
and remove the unnecessary asmlinkage tag. I'm surprised that this
didn't generate a warning...
Change-Id: I85ac0797d1e55d2b7ffdca039a52820d7827e704
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7724
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This is a direct copy of the amd/olivehill mainboard which
will be the starting point for this port.
Change-Id: I6a643f7ac35d89e21df0ffdf4e61a2da46e19b82
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/7721
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
This is not actually required. Tested on 'minnow max' hardware as
well as compared the asm of the optimized and non-optimized. Thanks Martin!
Change-Id: I06e71876c3a3a15101013623797c2ebbf449756d
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Found-by: Clang
Reviewed-on: http://review.coreboot.org/7694
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
If it's a 4 byte format (as per documentation), there
are some reserved bits, so let's mark them as such...
Change-Id: I50f12cfff2c9bb9d082a5f3c3ac54c0d514d862b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7674
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Following the same reasoning as commit
ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library
Since AGESA is stage-independent, we can build it just once, and use
the resulting static library in both rom and ram stages.
Change-Id: I8fbb318daacf64a14a71022705eb040a01c34fa8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7699
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Following the same reasoning as commit
ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library
Since AGESA is stage-independent, we can build it just once, and use
the resulting static library in both rom and ram stages.
Change-Id: I7798b689db3e582649eb4af4ccd1877bb1d49063
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7698
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Gabe Black