Allocate noncacheable memory for frame buffer and save base
address to sys_libinfo.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Change-Id: I19a8079616376dc7c1a8ecdbd7499c2553b8c6c3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cebb5650167264902548339bb1a2b428f3b7f4ed
Original-Change-Id: I7bfbfefb92001632ce3d572a50e46188795c4ab8
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/226404
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8796
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is important since mmu is disabled during the post_sysinfo_mmu_setup call
and calling printf can cause unaligned access.
BUG=None
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt with console_init
Change-Id: I5ef72ee449fdcf30186f97485cc532d6c56b2c5d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 688ef3856d0502d057c9543ee7763601156e6385
Original-Change-Id: Ie376e394d084edd6c999fc9edde79f15a0264e7b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/222664
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8795
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide a function to obtain a new memrange with requested properties (type,
size, alignment, max_addr and other restrictions) from the set of available
memranges passed in coreboot table. One user of this function would be getting
memrange for dma, another one would be framebuffer.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt
Change-Id: Ic5a63ca2dca6c71f4ca2d77e2e2c8180d32a38e0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3cd75756e1405e044c029f2878bfcc9c8c962bdf
Original-Change-Id: I187d73a4d55d3c6f49afbe9852901672d25de8dc
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/222110
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
1. keep functions and objects used entirely within mmu.c as static.
2. DMA region finding needs to terminate. Therefore, the next address
to be attempted needs to be less then the current end address.
3. Ensure mmu_ranges passed to mmu_init_ranges_from_sysinfo() has
0 entries marked as used.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Booted ryu with RAM hole above cbmem tables below 4GiB.
Change-Id: I71a9cb89466978aa63fca5d8bee97b8af75ea206
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 66518fd86e676bbddf52e9d9afdd76d72c8e2222
Original-Change-Id: I5cb4e5009359cb04c4e1b5fe60845f80fbdff02c
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/221725
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8793
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
What this change does:
1) Initialize limited page tables as soon as we jump into libpayload. Basically
two ranges are initialized. One is for the BASE_ADDRESS and other is for the
coreboot_tables. With page tables initialized and MMU enabled, we jump into
code to parse coreboot tables.
2) Once coreboot tables are parsed and we have complete picture of the memory,
we perform a complete page table initialzation and enable MMU and then jump to
payload.
Additionally, we also:
1) Initialize DMA memory on our own depending upon the memory map. It ensures
that the DMA buffer is placed in 32-bit memory.
CQ-DEPEND=CL:216826
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and we are able to start execution of libpayload in
EL2 and reach kernel login prompt
Change-Id: I8a6203e465868bc2a3e5cc377e108f36cc58e2fa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7695bb7afe34ea460282125a0be440e8994b01e4
Original-Change-Id: Ie0f47b7759d4ac65a6920f7f2f7502b889afda6d
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216824
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8792
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to ease the process of reading and writing any register at current EL,
provide read_current and write_current assembly macros. These are included in
arch/lib_helpers.h under the __ASSEMBLY__ macro condition. This is done to allow
the same header file to be included by .c and .S files.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully for ryu
Change-Id: I79241a944b68ebb24865e745a9835f54ab6d1a8f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2b55fbde466126c4de7f5f7bb2d1427196be842f
Original-Change-Id: I678ab89c4aa1b08898166e135b5ab2d6453bb5e8
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214576
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8801
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Adds support for initializing mmu, setting up dma areas and enabling mmu based
on the memranges passed on in the coreboot tables.
CQ-DEPEND=CL:216826
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully
Change-Id: Id41a4255f1cd45a9455840f1eaa53503bd6fef3f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f2c6676bf51fcd85b61e9e08a261634a78137c4c
Original-Change-Id: I217bc5a5aff6a1fc0809c769822d820316d5c434
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216823
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8791
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Libpayload should be able to setup its own dma areas and not depend on coreboot
tables for passing this information. This patch and next allow libpayload to
setup dma areas while performing mmu_init
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and dma areas are setup properly with the mmu init patch
Change-Id: I5f6fd19a957c7626a2bbe6b826c8987e64ed248f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4f3552b8d3439a8b12d1e0b15ef67dcb14b8c96a
Original-Change-Id: I44d9f394fa349abd7182c4ba10f1eaefd6e4fdaa
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216822
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8789
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
By default we dont want to use the special DC instruction. Thus getting rid of
the DONT_USE_DC macro and enabling code appropriately in memset.S
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and memset works fine for mmu init
Change-Id: Icb3193f4f0d122726dcdacbdcacbf53eba30e235
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 54f639ef2348acab54e32b18f6826a67bf52bc14
Original-Change-Id: Id89ec2c1731d21496eca617a3c03abaf48062908
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216820
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8787
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Allow more flexibility by reading and writing to system registers at current
EL. Instead of specifying what _ELx register to write to, code can specify
_current.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles and boots to kernel on ryu
Change-Id: Id38b675bfe67ca1e25f8c268192114e3f0bee800
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6d4d07e26fc964dc3aaebfe03db59596d90093e9
Original-Change-Id: Ic1d9e18e6fc016a04f17621a148e62d6cbd04ce7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214577
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8785
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add library helpers to access standard arm64 registers. This library also
provides functions to directly read/write register based on current el. So, rest
of the code doesnt need to keep checking the el and call appropriate function
based on that.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Libpayload and depthcharge compile successfully for ryu
Change-Id: Ibc0ca49f158362d4b7ab2045bf0fbd58ada79360
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2ca6da580cb51b4c23abdaf04fee2785e5780510
Original-Change-Id: I9b63e04aa26a98bbeb34fdef634776d49454ca8d
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214575
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8784
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA and bring up board; works as
expected
BRANCH=none
Change-Id: I368494f388b82969dda0ce73a38824791efce616
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e4c2bbcbdbcf706062724cffe2d5f15953468ace
Original-Change-Id: Id5c9b1d65c6ec87f2aba06995dc940c50afb041f
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245386
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add CPU frequency corresponding to SOC.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; behaves as expected.
BRANCH=none
Change-Id: I05458070a15c6cf1ef0fc2104715a63902a38887
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4afe332bcc41afeb7e31e918e345c3336f7dc604
Original-Change-Id: I55b788faf7984bafc2509cac69867a772c7cb863
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241427
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8853
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
timer_raw_value must return the number of CPU ticks, and not
the time obtained by dividing the ticks by the CPU frequency.
The CPU counter is increased at every 2 CPU clocks
and therfore the number of ticks will be the counter value
multiplied by 2.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA; it works properly.
BRANCH=none
Change-Id: Iae62cb328e882f84822250bdf72146321ca9bbe0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7ab25ce7dcaffb453ee774d870963a56444d46af
Original-Change-Id: I74408950900463a2c054d5aebd3edb005a325adb
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242393
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8744
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The default string functions work with multiple of 4 bytes
(sizeof(unsinged long)); MIPS will use LW/SW instructions
for these operations and if the source and destination
addresses are not aligned it will trigger an exception.
Therefore, this implementation does all data access operations
per byte, because there is no guarantee that the provided
strings are properly aligned.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; behaves as expected
BRANCH=none
Change-Id: I05b43673deb954f022d12cb9c3d7baac26be2a34
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e13b3d31726404abd8c8e5c8780d3d3e16e032d
Original-Change-Id: I456e312eb6b7fee2eff10e461af7f578aed07648
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241885
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the basic build infrastructure and architectural support
required to build for targets using the MIPS architecture.
This will require the addition of cache maintenance.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA with Depthcharge as payload;
successfully executed payload.
BRANCH=none
Change-Id: I75cfd0536860b6d84b53a567940fe6668d9b2cbb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 758c8cb9a6846e6ca32be409ec5f7a888ac9c888
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Change-Id: I0b9af983bf5032335a519ce2510a0b3aca082edf
Original-Reviewed-on: https://chromium-review.googlesource.com/219740
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8741
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The correct return value for errors on a cbfs_media->map() call is
CBFS_MEDIA_INVALID_MAP_ADDRESS, not NULL. Not sure if that's the best
choice (since 0xffffffff is probably a more likely valid address than 0
there), but that's what the upper layers expect right now.
BRANCH=veyron
BUG=None
TEST=Press CTRL+L with an RW_LEGACY section filled with 0xff. Observe
how cbfs_get_header() returns failure without doing a bunch of NULL
pointer accesses first (not that those have any visible effect on
Veyron, but that's another problem...)
Change-Id: I3d012fc9af9da6e01159990a6bdd62c38fc22329
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3a609e17bb9b0ef4d3a833f72fa4fbfd8e8cb0ab
Original-Change-Id: I0793434116a8c568e19fe0dee24f13942fc50f25
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238991
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/8758
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This adds CB_TAG_RAM_CODE and an entry to sysinfo_t.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=Built and booted on pinky w/ depthcharge patch and saw that
/proc/device-tree/firmware/coreboot/ram-code contains correct
value
Change-Id: I35ee1bcdc77bc6d4d24c1e804aefdbbfaa3875a4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ca6d044f2e719ded1d78a5ab3d923e06c3b88d6b
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I69ee1fc7bc09c9d1c387efe2d171c57e62cfaf3f
Original-Reviewed-on: https://chromium-review.googlesource.com/231132
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8755
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The WiFi calibration blob saved in the CBMEM by coreboot needs to be
visible by depthcharge to supply it to the kernel.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none yet
Change-Id: I43a857f073a47ca315d400df4c53d5eb38e91601
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 46a649608e6740e07c562c722fadd8c64e264b5f
Original-Change-Id: Iecd8739c9269b58064b3c3275f5376cebcd6804b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225506
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8753
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Certain boards need to speak proto v3 over i2c. Leverage the
transport agnostic API to share the logic with other proto v3
impelementations.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=Built and ran on ryu. Can talk to the EC successfully.
Change-Id: I1d0cd6907057af4ded3c4460193bbe1d897a1db7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cb9ac965ad04c9491f40fd9aa595176a28a467b3
Original-Change-Id: Ib699120fd232392e8caa0889c2bf40f4587a8a35
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211139
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8828
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Depending on the transport mechanism for proto v3 different bytes
need to be send and/or read before the request and response. Depending
on the software and/or controller interface that requirement leads to
needing to copy data into temporary buffers. Avoid this by allowing
the transport mechanism to provide the request and response
buffers.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=Built for rush and ryu. Ran on ryu with i2c implementation.
Also built for rambi to check x86 systems.
Change-Id: I35d4d69bd1fa900fc0cfe3822496f381405bdcb1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c7224426e1d0bcf06ed010131a2462a6ca201d8b
Original-Change-Id: Iad6cce566a253ca72e6f5009a97235ece0a6c1b5
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211138
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8827
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The EC doesn't return any data when one performs a write to
VBNV context. Therefore there is a mismatch of expectations.
Correct this by properly setting the expected response length.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=No longer hanging while writing to VBNV on ryu.
Change-Id: I7077a507c3280358dac1f88ece62cacee9b71bea
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c1735c3377163aeb9e90155cb9f081a1eea919c9
Original-Change-Id: I455724f20f5442bd62a792f09273227417475f07
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211137
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8826
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The default mapping size is 1MiB of ram. However, not
all systems allow 1MiB of memory to mapped depending on
the kernel's memory map. Therefore, be explicit about
the sizes to mmap().
The only path that wasn't cleaned up was the coverage path
as that needs to handle dynamic cbmem. The correct way to
fix that is to add a global like the timestamps that is set
while parsing cbtable.
BUG=chrome-os-partner:31355
BRANCH=None
TEST=Can cbmem -ltc on ryu.
Change-Id: I548afa5ddbe0a859f52bc2ab2d0931186ee378a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: df4991ce1da7f0c25e99d84222cbc8d3189d0d66
Original-Change-Id: I27b70ae8a8fba168d1c1829bbef0135c7b651eac
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/221971
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8829
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's helpful to view program size by inspecting the symbols.
_start and _end exist on romstage and ramstage. In order to
be consistent add _end for bootblock too.
BUG=None
BRANCH=None
TEST=Built and noted bootblock has _end symbol.
Change-Id: I06634b317e957e8271bf32530a56b5541c79b9ee
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b4ac926b30749d22e90a6f12ebac52107e241526
Original-Change-Id: I7f0b4dd4078c7d23c70949563b4c3f4df9e66142
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210832
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8824
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In some cases, we need to use 1 common VGA device ID to share
among different VGA devices.
But it will show error when it can't find a specific pci rom
by PCI DID.
in fact, it will find the pci rom with common vga ID.
Without this commit, you may need to skip error check during
suspend_stress_test
BUG=none
BRANCH=none
TEST=build OK, and check no error on Auron and Samus
Change-Id: I2b18347e46c831038f048cfd0b065430c72c6f30
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c32ee21b4c942182e5ffb21b58b93fa7c082223
Original-Change-Id: Ib743e960f772b7e2e73a1feb80790a13bd8c06c7
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217415
Original-Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: http://review.coreboot.org/8821
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It causes fan top speed due to this bug + our board-specific workaround,
and causes invalid temperature sensor readings.
Therefore, re-configure the register "External Temperature Sensor Host
Control Register" to terminate processes when this issue happens.
BUG=chromium:402204
TEST=ran suspend_stress_test 500 times
Change-Id: I439d5de798fbe999e4eec5497e6969b7b453121b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b82f2922c7fce3ca6b2797a8d9775e9db2817fe9
Original-Change-Id: I6e71b6a46a31b00e541c304f1ed58c1678c1d42e
Original-Signed-off-by: Ryan Lin <ryan.lin@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219445
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/8820
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=None
BUG=None
TEST=Manual
Change-Id: I8b31a0b194d353ea3e7863513f2e36f3e032fad8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7ccba49a7c2372cdfff6e2947e417d4d4f5436c2
Original-Change-Id: I9beebdf29e4fc4aa645581146fdc61c659de72df
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229973
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/8808
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built secmon which had this type of relocation.
Change-Id: Ie367c348fbf59465e238e5fa60f217f5373501b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a754bc1fe39c19ab8b2f7be9648cccb06156b0ef
Original-Change-Id: If170d9e270daf3153e92d16c06516915c727e930
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218843
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8807
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When adding gargabe collection to x86 the --gc-sections
flags was inadvertently missed when linking romstage_null.debug.
Fix this omission.
Change-Id: I7d2700755afa78459c6f8707303a0e64936a1a9f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8850
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Chapter 3.1 "Periodic Frame List" of EHCI 1.0 specification says
"Frame List Link pointers always reference memory objects that are
32-byte aligned."
jwerner@chromium.org suggests setting it to be 64-byte aligned for
consistency with other EHCI queue structures.
BUG=chrome-os-partner:31993
TEST=Tested on nyan platform. Before adding patch, USB keyboard behind
an external hub is not working to switch between "Default Locale" and
"English" (after pressing ESC+REFRESH+POWER on embedded keyboard and
later Left/Right-Arrow key on USB keyboard).
Change-Id: Ie6259f2df20ae2618c2074e831fad087f227091d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 23fc02e6ba3b17be4eaf18810ec6fc0d9c0e0b9a
Original-Change-Id: If52ddc43ebd5d509c19f104928dced5bd09b1706
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/218403
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8738
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Data toggle should be running like 0, 1, 0, 1, ...
In the failed case (where a low-speed USB keyboard or km232 device
is installed), data toggle will be running as 0, 1, 0, 1, ..., 1, 1.
Therefore causing Halted or Transaction Error bit to be set in qTD
Status field.
BUG=None
BRANCH=None
TEST=Tested on nyan_kitty platform, firmware-kitty-5771.61.B branch.
Attached USB keyboard or km232 device to root-hub port (same side as
SD card slot).
Made sure no transaction error after doing interrupt transfer.
Change-Id: I576f3c583dae4c279a6e0e8ffdfce5abe463277d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64b0428aaab869e20f6720669e953acf82ecb846
Original-Change-Id: Ic2c0f95cff2ae6e314967b0b82231a962255f1a7
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233857
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These functions are usually provided by gcc lib, which is not supposed
to be included on embedded platforms. This patch adds a no thrills C
implementation.
Other than MIPS platforms are happy using the gcc library provided
implementation, but in case of Chrome OS MIPS toolchain the libraries
are compiled with the small GOT, such that the entire data segment
does not fit.
With this implementation mips, arm and x86 targets build fine.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=checked the logic by incorporating this code into a C file and
running a loop continuously comparing random inputs' division and
left and right shift results.
The test ran for extended periods of time without failure.
Change-Id: I468acd2fdbcdd493a76758a394e79cad35f9535a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2cc5f8668dd2609408af8da5a74c5a3d063fc0d3
Original-Change-Id: Ib46616d7eb0b2b497199270057514f730bb1cb0b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232232
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_romstage() to perform
the necessary work to load and run romstage.
Change-Id: Id59f47febf5122cb3ee60f9741cfb58cb60ccab5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_ramstage() to perform
the necessary work to load and run ramstage.
Change-Id: I37b1e94be36ef7a43efe65b2db110742fa105169
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8710
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide a common run_romstage() function to be used by
bootblocks to load and run romstage. This is similar to
run_ramstage() in that it provides a single entry point
for doing the necessary work of loading and running romstage.
Change-Id: Ia9643cc091f97a836cf5caefdff8df4a3443df4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8709
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Miraculously a console is being compiled in for romstage.
However, as no calls were potentially printing to the preram
console this was being ignored. Instead provide the symbol
required so as not to fail the build.
Change-Id: Id8f0b6e6d15b41fa7fe1b63bf2d91f15baa0edda
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8712
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of two headers for payload and ramstage loading
combine the 2 files into one. This also allows for easier
refactoring by keeping header files consistent.
Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8708
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER
configuration option enabled, so the verstage is missing the relevant
files in some Makefiles. This patch fixes the problem.
BRANCH=none
BUG=none
TEST=with the rest of the patches applied cosmos target builds fine
with COMMON_CBFS_SPI_WRAPPER enabled
Change-Id: I3ce78c8afc5f7d8ce822bbf8dd789c0c2ba4b99c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b72693c96f7d8ce94ce6fe12b316d5b88fded579
Original-Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223751
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8772
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Jimmy Zhang