Now that we can set CC to an arbitrary compiler, fix issues that clang
finds. Luckily, there were only two trivial errors.
Change-Id: I0fd1f0f263a8ab7004f39cd36ed42d1a1cba5c04
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5081
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
LDN is 8-bit but coreboot squeezes unrelated info: VLDN in this field.
Increase to 16-bit to handle this.
Change-Id: I97af1b32dcfaed84980fa3aa4c317dfab6fad6d8
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5165
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Be more conservative and only add VGA devices' prefetchable
resources as write-combining in the address space. Previously
all prefetchable memory was added as a write-combining memory
type. Some hardware incorrectly advertises its BAR as
prefetchable when it shouldn't be.
A new memranges_add_resources_filter() function is added
to provide additional filtering on device and resource.
Change-Id: I3fc55b90d8c5b694c5aa9e2f34db1b4ef845ce10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5169
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
It was a typo.
Change-Id: I82964b5ed7e7749ba141aeb3ee8dc4c107bcd7a9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5127
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The calculations for static allocation are no longer valid.
Change-Id: I6740cdcec789abddf78485a0edaf24882ef8c2a5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4569
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Unused and hard-coded to use uart8250 on IO.
Change-Id: I3f84c50039a450a2ae97a5fd2af89992f8567e6c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5137
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Also prepare this console for use in romstage.
Change-Id: I26a4d4b5db1e44a261396a21bb0f0574d72aa86d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5136
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Also relocate and split header files, there is some interest
for EHCI debug support without PCI.
Change-Id: Ibe91730eb72dfe0634fb38bdd184043495e2fb08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
If the MTRR usage exceeds the BIOS allocation for MTRR usage
re-try without the WRCOMB type.
Change-Id: Ie70ce84994428ff6700c36310264c3c44d9ed128
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5151
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
The memranges_update_tag() function replaces all instances
that are tagged with old_tag and update to new_tag. This
can be helpful in the MTRR code by adjusting the address
space if certain memory types cause the MTRR usage to
become too large.
Change-Id: Ie5c405204de2fdd9fd1dd5d6190b223925d6d318
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5150
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Flash prefers 32-bit sequential access. On some platforms ROM is
not cached due to i.a. MTRR shortage. Moreover ROM caching is not
currently enabled by default. With this patch payload decompression
is sped up by theoretical factor of 4.
Test on X201, with caching disabled:
Before:
90:load payload 4,470,841 (24,505)
99:selfboot jump 6,073,812 (1,602,971)
After:
90:load payload 4,530,979 (17,728)
99:selfboot jump 5,103,408 (572,429)
Change-Id: Id17e61316dbbf73f4a837bf173f88bf26c01c62b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5144
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
And use it in fit.c and remove one more use of htonl.
Change-Id: Ibf18dcc0a7f08d75c2374115de0db7a4bf64ec1e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5120
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The punit is responsible for a number of things. Without
performing the sequence included it won't change processor
frequency when requested and apparently there are some bizarre
hangs introduced if this sequence isn't included either. Lastly,
this needs to come after microcode has been loaded. As that is
done in bootblock the ordering is correct.
One other side effect is that this fixes the graphics devices'
device id. Before it was showing up as the same device id of the
SoC transaction router.
BUG=chrome-os-partner:22880
BUG=chrome-os-partner:23085
BUG=chrome-os-partner:22876
BRANCH=None
TEST=Built and booted.
Change-Id: Ib7be1d4b365e9a45647c778ee5f91de497c55bf1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171862
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4864
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Start loading microcode in the bootblock. This way
no caching has been set up and cache-as-ram mode
will be running in a validated configruation (with ucode
patch).
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted. Confirmed microcode is loaded.
Change-Id: I6fd1d8e55bcc9d799b11d9faed771ac50dc120a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171861
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4863
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The TCO timer always starts ticking out of reset.
However, depending on microcode loading and punit
initialization the TCO timing out has a different
impact on the sytem. Without loading microcode
or initializing the punit the tco times out and
nothing happens. However, when microcode is loaded
a timeout will reset the system. Lastly, if the
punit is initialized but the microcode isn't loaded
the TCO timeout will shut down the system.
To fix all the weird symptoms disable the TCO.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted with microcode loading. Reset doesn't
occur.
Change-Id: I49cd62f510726a96bf734ae728a352c671d1561e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171860
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4862
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Apparently there was another BAR living at 0x5c in the LPC
bridge that mapped the PUNIT registers. EDS 2.0 released
and this register is now documented.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built and booted.
Change-Id: I5892c2a14923b57826060e92b4335cb1952ea057
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171612
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4861
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The 316 microcode is the newest version. Include that in the build.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and partially booted with microcode loading. Noted 316
loaded.
Change-Id: Iba01dd58688737ae38bc58a84014ee9526540db1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171611
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4860
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Allow for one to write an individual byte of a 32-bit register
when sending a read/write through the IOSF messaging system.
Add PUNIT registers and fields for early sequencing.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built and partially booted with changes that use PUNIT
registers and individual byte en fields.
Change-Id: I929fb5c51d805c55c478cab884e3572254987fc7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171710
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4859
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The mrc_wrapper.h was changed to protect against ABI differences
between the two sets of compilers and flags used. This requires
a prope shim for the console output funciton.
BUG=chrome-os-partner:23048
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I976e692e66dcfc0eacadae6173abfd9b81e31137
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171580
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4858
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This commit always selects COLLECT_TIMESTAMPS and starts
tracking TSC values from the early stages of bootblock.
The initial timestamp value is saved in mm0 and mm1 while
in bootlbock. This approach works because romcc is not configured
to use mmx registers for its compilation.
Additionally, the romstage api with the mainboard was changed to
always pass around a pointer to a romstage_params structure as the
timestamps are saved in there until ram is up.
BUG=chrome-os-partner:22873
BRANCH=None
TEST=Built and booted with added code to print out timestamps at
end of ramstage. Everything looks legit.
Change-Id: Iba8d5fff1654afa6471088c46a357474ba533236
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170950
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4856
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When I changed mkpayload, I did not realize we had a duplicate
block of code in the linux payload code. Have it use the same
header generator as the standard payload code does.
Change-Id: Ie39540089ce89b704290c89127da4c7b051ecb0e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5115
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Now that unused functions have been removed, the global "arch" is only
used in very few places. We can pack "arch" in the "param" structure
and pass it down to where it is actually used.
Change-Id: I255d1e2bc6b5ead91b6b4e94a0202523c4ab53dc
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5105
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A lot of the early functions have been re-implemented in a context-
centric mode, rather than relying on global variables. Removing these
has the nice side-effect of allowing us to remove more global
variables.
Change-Id: Iee716ef38729705432dd10d12758c886d38701a8
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5104
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is part of a larger effort to reduce global variable usage in
cbfstool. cbfstool_offset is particularly easy to hide since it's only
used in common.c .
Change-Id: Ic45349b5148d4407f31e12682ea0ad4b68136711
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5102
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
According to vendor (Pascal Dornier) they're the same from coreboot
perspective.
Change-Id: I43aeb77f21c251b3d9c5c2dcfa01d4d1de0bc87b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5114
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Broken with/since commit d1cb0eec.
Original intention was to set the frequency for 'Fast Read' command
in bits 15..14, and enable 'Fast Read' command.
Modified register contains SPI frequency for 'Normal Read' command
in bits 13..12. Default for this is 11b for 16.5 MHz. Existing code
unintentionally clears these bits, increasing SPI frequency to 66MHz
for 'Normal Read' command.
This is above specifications for many common SPI flash components
and also makes flashrom older than 0.9.7-r1750 to operate unreliably
on read/write/erase for these platforms.
Change-Id: I30109e2a0410c0bb0bdc968ea71787396b32e761
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5089
Tested-by: build bot (Jenkins)
Reviewed-by: Kevin O'Connor <kevin@koconnor.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The added CPU's are OSA248CEP5AU and a OSP280 processors.
The OSP280 VID/FID numbers have been found by experimentation
and extrapolation/guesses from similar models. It has been
verified to work fine under Linux (OpenSuse 12.2, kernel
3.4.63-2.44) with four different test-processors.
Windows is untested.
Change-Id: I3afa1cba5f55c8a78917b3636382af7706a80fee
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5095
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
It's not used anymore. Instead, we have the better replacements
cbfs_image_create() and cbfs_image_from_file().
Change-Id: I7835f339805f6b41527fe3550028b29f79e35d13
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5103
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
During ramstage, call mainboard_get_gpios to get initial GPIO configuration
from the mainboard code, then initialize GPIOs as requested.
BUG=chrome-os-partner:22863
TEST=Manual. Using bayleybay GPIO table, set UART GPIOs to 'function 1',
and verify UART still works after GPIO configuration. Also, verify
legacy GPIO config is functional by toggling test pin.
Change-Id: Ic58d8ddd15c4dc48a751a83f6d26c7809c1efc42
Reviewed-on: https://chromium-review.googlesource.com/170306
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4855
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Port 2 is used by msata. Enable it.
Change-Id: Ib75227f64c9d77f6cfca1902a78d63b5cdd23d76
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4789
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
This change adds a header serialization function. Programmers can thus just
set up a header as needed, without worrying about forgetting if and how to
use the [hn]to[hn]* functions.
In the long term, we will work to remove swab.h, i.e. we need to get to the
point where programmers don't have to try to remember [hn]to[nh]* and where
it goes. To date, even the best programmers we have have made an error with
those functions, and those errors have persisted for 6 or 7 years now. It's
very easy to make that mistake.
BUG=None
TEST=Build a peppy image and verify that it's bit for bit the same. All
chromebooks use this code and build and boot correctly.
BRANCH=None
Change-Id: I0f9b8e7cac5f52d0ea330ba948650fa0803aa0d5
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181552
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/5100
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This completes the improvements to the ELF file parsing code. We can
now parse section headers too, across all 4 combinations of word size
and endianness. I had hoped to completely remove the use of htonl
until I found it in cbfs_image.c. That's a battle for another day.
There's now a handy macro to create magic numbers in host byte order.
I'm using it for all the PAYLOAD_SEGMENT_* constants and maybe
we can use it for the others too, but this is sensitive code and
I'd rather change one thing at a time.
To maximize the ease of use for users, elf parsing is accomplished with
just one function:
int
elf_headers(const struct buffer *pinput,
Elf64_Ehdr *ehdr,
Elf64_Phdr **pphdr,
Elf64_Shdr **pshdr)
which requires the ehdr and pphdr pointers to be non-NULL, but allows
the pshdr to be NULL. If pshdr is NULL, the code will not try to read
in section headers.
To satisfy our powerful scripts, I had to remove the ^M from an unrelated
microcode file.
BUG=None
TEST=Build a peppy image (known to boot) with old and new versions and verify they are bit-for-bit the same. This was also fully tested across all chromebooks for building and booting and running chromeos.
BRANCH=None
Change-Id: I54dad887d922428b6175fdb6a9cdfadd8a6bb889
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181272
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5098
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The trailing whitespace breaks the Git commit hook
`util/lint/lint-stable-003-wihitespace`. So remove it.
Change-Id: I70e4ac71529884a9a4fabf2aa9a4ea6e0323b9d4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5092
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The AGESA resumes the GPP ports in the romstage using FchInitResetGpp(),
which does FchGppPortInitS3Phase() for S3 resume. The PreInitGppLink()
looks into CMOS to figure out what ports to just force to Gen1 or
Gen2 PCIe. Then boot continues and in the ramstage the rest of GPP
init is executed. There is a problem that nobody sets properly the
PortDetected flags in the S3 path. As the consequence FchGppDynamicPowerSaving()
thinks the GPP port is not enabled and shut downs it.
The best fix would be also to remove the CMOS dependency which
might be some left over, because AGESA does not use CMOS much for
anything else. There could be also some way how to pass the GPP state
structure from romstage to ramstage possibly via hudson/resume.c
but I don't know how to do that. Similar problem is that the "late"
stage of init again "forgets" the PortDetected state.
This fix fixes the resume issue on Asus F2A85-M. With this patch applied
both GPP ports (used as PCIe x1 and internal ethernet) are working again
after resume.
Change-Id: Idaf609043abb09441c6790504d66d23e0637588f
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/4671
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
AT24RF08 was inherited from RE of original BIOS. As we don't really care
if the chip in question is really AT24RF08 or a generic replacement,
we can skip this check.
Change-Id: I862dd66b2332314beb835f215f1c1cd838aa07b9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4769
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Alexandru Gagniuc