Paging code is tricky and figuring out what is wrong with it can be a
pain. This patch tries to ease the burden by giving a little more
information for prefetch and data aborts, dumping the Instruction Fault
Address Register (IFAR), Instruction Fault Status Register (IFSR) and
Auxiliary Instruction Fault Status Register (AIFSR) or the respective
Data registers. These contain additional information about the cause of
the abort (internal/external, write or read, fault subtype, etc.) and
the faulting address.
BUG=None
TEST=I have read through enough imprecise asynchronous external abort
reports with this patch that I learned the bit pattern by heart.
Change-Id: If1850c4a6df29b1195714ed0bdf025e51220e8ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bf3b4924121825a5ceef7e5c14b7b307d01f8e9c
Original-Change-Id: I56a0557d4257f40b5b30c559c84eaf9b9f729099
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223784
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If a TD is comprised of one or more Normal TRBs and terminated with an
Event Data TRB, then the transition to the Idle state (and associated
Stream state save) could occur after all the data for the TD has been
moved (e.g. after Transfer Event TRBs have been executed), but before the
Event Data TRB is executed. Under these conditions, the execution of the
Event Data TRB is necessary to complete the TD, otherwise it does not
occur until the next time the Stream is scheduled. This could lead to the
lock up.
The Evaluate Next TRB(ENT) flag provides a means of forcing the execution
of a terminating Event Data TRB. Setting ENT flag in last Normal TRB makes
the xHC to evaluate the Even Data TRB.
BUG=chrome-os-partner:29375
TEST=Verified kernel boot-up on storm from previously failing USB stick.
USB stick model: Sandisk Ultra USB 3.0 Pen Drive 32 GB
Strontium Jet USB 3.0 Pen Drive 32 GB
Change-Id: I092e2109c55c2274239c493cb67b47d730304ed2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7eefb3b2858c841165ae839d349d2a0be50fbcc8
Original-Change-Id: I4e123577ec5a5996d87d2fc52cb6cf5c571c9fae
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220123
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8736
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If EHCI controller has TT (Transaction Translator) support in
root-hub, then we need to keep control over this controller when
USB keyboard (low-speed device) is connected to root-hub port.
Need to add "CONFIG_LP_USB_EHCI_HOSTPC_ROOT_HUB_TT=y" to config file
(e.g. payloads/libpayload/configs/config.nyan_big) to support this
feature.
BUG=chrome-os-partner:32355
TEST=Tested on nyan_big platform.
Press ESC+REFRESH+POWER keys on internal keyboard to power up.
Press Left Arrow or Right Arrow on USB keyboard to switch between
"English" and "Default Locale" in coreboot UI. Or unplug and plug
in device and try again.
Root hub <- low-speed USB keyboard
Root hub <- full-speed hub <- low-speed USB keyboard
Root hub <- high-speed hub <- low-speed USB keyboard
Change-Id: Iaa2823f64c8769fc808ee7a316c378f18f004e63
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ad57fd673d6dc8814fe99a4ac420566bb17e77b
Original-Change-Id: Id86a289bc587653b85227c1d50f7a4f476f37983
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/220125
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8737
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of forcing boards to have DMA region below 4GiB, provide
Kconfig option DMA_LIM_EXCL that a board can use to set the upper
limit in MiB units on the address range reserved by DMA. By default,
this value is 0x1000 i.e. 4GiB limit on the DMA upper address.
BUG=None
BRANCH=None
TEST=Compiles successfully for rush. Default value is seen as 0x1000.
Change-Id: Ie35d3844a0989486ae022f8922fdd4c9d7d57fb4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6716cf312a103bc0440a558fc43c8c77869816e3
Original-Change-Id: I3ecbb4ec90995ab1568cb0924d5ce9467492697d
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245250
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/8800
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Align struct members with tabs.
Change-Id: Ie8bdbd718c7217a3f3768dd037fa7c10badbc05e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/8854
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The raw_write_sctlr_current() cannot be used in mmu_disable() because
it pushes some registers to cached stack, and then just after cache
disabled, the value was gone.
BRANCH=none
BUG=none
TEST=build and boot on mt8173-evb
Change-Id: I512405b7917f27d16bdd3c51d9459827ad714e67
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: aafe64922cc4cd01ecb099db106d04538e3e57ff
Original-Change-Id: I0dda8518d14c46fae1fe76e3629bd4ee81c1e0ee
Original-Signed-off-by: HC Yen <hc.yen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/240323
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8799
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Allow read/write to registers at a given el. Also, make read/write
registers at current el call this newly added function.
BRANCH=none
BUG=none
TEST=build and boot on mt8173-evb
Change-Id: Id69f0fdc07193c5c7e997712f0cd99de6f41510b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c091917babc39d9ab997f51f81b486c9aa900c24
Original-Change-Id: I0944946642066b88331e497a92388e74e86902d0
Original-Signed-off-by: HC Yen <hc.yen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/240322
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8798
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The framebuffer structure lives in the coreboot tables. Those
tables have a checksum calculation applied over all the entries.
Therefore, one shouldnot be modifying fields within the coreboot
table entries because the calculated checksum would be wrong.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=On ryu, confirmed dev screen still works as well as cbmem utility
once booted.
Change-Id: I93830a8efe98aa848f2b0f8388688de0e93b2f82
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6026ca5ad0254c14c30412882dc63550656c7d16
Original-Change-Id: Ic9c164ded03d10d6f6f3ce15e9b38b1f6ce61a91
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/230471
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8797
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
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>
It turns out that CB_TAG_ACPI_GNVS is handled in both x86 specific and
common coreboot table parsing code. The MRC cache case used only by
x86 is handled in the common code.
This patch restores sanity and moves processing to where it belongs.
BRANCH=none
BUG=none
TEST=verified that arm and x86 targets build.
Change-Id: Iaddaa3380725be6d08a51a96c68b70522531bafe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0afae893d5027026cb666cd46e054aeae4e71f83
Original-Change-Id: I2c114a8469455002c51593cb8be80585925969a7
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225457
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8752
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Pass MAC addresses found in coreboot table into lib_sysinfo.
BUG=chrome-os-partner:32152
TEST=with all changes in place MAC addresses are properly inserted
into the kernel device tree.
Change-Id: I6b13c1c2c246362256abce3efa4a97b355647ef8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e2fe74f86b4ed43eb8a3c9d99055afc5d6fb7b78
Original-Change-Id: I1d0bd437fb27fabd14b9ba1fb5415586cd8847bb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219444
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8751
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are three instances of coreboot.c in libpayload. for x86, arm
and arm64 architectures. The arm and arm64 instances are exactly the
same. The differences with the x86 instance are as follows:
- a very slightly different set of coreboot table tags is parsed (one
tag added and two removed)
- instead of checking a fixed address if it contains the coreboot
table, the x86 version iterates over two address ranges.
This patch refactors the module, leaving architecture specific
processing in arch subdirectories and moving the common code into
libc.
BUG=none
TEST=none yet
Change-Id: I1c7ad6f74e3498e93df78086ba0ff708c08e0a5c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3df209d58ebd5c5b1cf0168f6466e065d1ef3598
Original-Change-Id: I6dfed73f6ba5939f692d0f98d2774c0e0312a25f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210770
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8750
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Make board ID value supplied in the coreboot table available to the
bootloader on all three architectures.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: I6c2d39e94212b55650929d7d99896581d23f789d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 723e4a600a5d3a03e960169b04f8322f6dd2486b
Original-Change-Id: I7847bd9fe2d000a29c7ae95144f4868d926fb198
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210430
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8730
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As opposed to other architectures, on MIPS gcc toolchain provided
gcclib is not always adequate, for instance when the library does not
account for the case when data segment is too large to fit into the
64K GOT.
Let's make sure the library is not included when building for MIPS
targets.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of patches applied the FPGA board boots all the way
to verifying and loading the kernel from the USB stick.
Change-Id: I710d3c49bdc57877152cf28d5bd8cb4fa4d0b9ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f8d7d84c81af7e3eee1c8f3304c15069e8701cde
Original-Change-Id: I1a26b9e575a20101329359b80dffc236ef7f9e9f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232231
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add support to check if the driver for console_out or console_in is already
present in the list. If console_init is called twice, then the driver might get
added twice leading to a loop.
BUG=None
BRANCH=None
TEST=With console_init in libpayload and depthcharge both, there are no console
loops seen anymore
Change-Id: I9103230dfe88added28c51bff33ea4fa1ab034c1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6931236ba2cfa71849973fe41cc340b7d70656ad
Original-Change-Id: If9a927318b850ec59619d92b1da4dddd0aa09cd1
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214072
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/8739
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds a simple function to convert a string in UTF-16LE
to ASCII.
TEST=Ran against a string found in a GPT with the intended outcome
BRANCH=none
BUG=none
Change-Id: I94ec0a32f5712259d3d0caec2233c992330228e3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1104db8328a197c7ccf6959a238277f416a2113a
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Change-Id: I50ca5bfdfbef9e084321b2beb1b8d4194ca5af9c
Original-Reviewed-on: https://chromium-review.googlesource.com/231456
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8733
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For memalign() requests the current allocator keeps metadata
about each chunk of aligned memory that copmrises the size
requested. For large allocations relative to the alignment
this can cause significant metadata overhead. Instead, consider
all memalign() requests whose size meets or exceeds 1KiB or
alignment that meets or exceeds 1KiB large requests.
These requests are handled specially to only allocate
the amount of memory required for the size and alignment
constraints by not allocating any metadata as the whole region
would be consumed by the request.
BUG=None
BRANCH=None
TEST=Built and tested various scenarios. Noted the ability to
free() and properly coalesce the heap as expected.
Change-Id: Ia9cf5529ca859e490617af296cffd2705c2c6fd8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4e32fc57626dac6194c9fd0141df680b4a5417e8
Original-Change-Id: Icdf022831b733e3bb84a2d2f3b499f4e25d89128
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242456
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some USB sticks seem to send a NAK at a place where they mustn't
by spec, leading to a controller side error condition.
To avoid it, wait a millisecond which is enough to get past the
NAK condition. That delay only happens on device discovery so it
won't affect boot time by more than 1ms per device.
BUG=chromium:414959
BRANCH=none
TEST=depthcharge recognizes a Lexar 16GB USB stick after applying
this change.
Change-Id: I0e385702a5259b16fda0a253fc121d8f66e6705c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10bbfda8395af009e7f910cc503f50c2ad969ae8
Original-Change-Id: I6dd5ca34e9f3767003ccb0ca9daaf16116f4a2df
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228791
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-on: http://review.coreboot.org/8735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
EHCI driver accesses mmio space using regular struct pointers. In order to avoid
any CPU re-ordering, memory barrier is required in async_set_schedule,
especially for arm64. Without the memory barrier, there seems to be re-ordering
taking place which leads to USB errors with some flash drives as well as
transfer errors in netboot.
BUG=chrome-os-partner:31533
BRANCH=None
TEST=With the memory barrier introduced, netboot for ryu completes transfer
without any error and finishes within 6-7 seconds.
Change-Id: Ib6d29dc79fd5722c27284478e8da316929e86bff
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 561bdd746c4d4446ce0a6d21337d354625d85ddc
Original-Change-Id: Ic05d47422312a1cddbebe3180f4f159853604440
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/213917
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/8732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for memory barriers in arch {arm,arm64,x86}. This is required to
force strict CPU ordering. Definitions are based on FREEBSD atomic.h
definitions.
BUG=chrome-os-partner:31533
BRANCH=None
TEST=Memory barriers tested with ehci driver on arm64
Change-Id: I50060b0f33a6bd6cb95e829df079df379b2ff2a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 937d66cdab92a8521ede8307f5af8f5c20d3e552
Original-Change-Id: Ie51e3452f7a254b24111000da5dbe8714ac22223
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/213916
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8731
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Similarly to xzalloc() and xmalloc() provide an xmemalign() function
to do the approriate assertions on allocation failure.
BUG=None
BRANCH=None
TEST=Built and booted using xmemalign().
Change-Id: I59579d9ee973af3bb34037b7df5b1024b60e348d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3001822656024dbfc34d6b849a0245274b8c0f46
Original-Change-Id: Ie307d4c9c1882bba25745afe38455f2682303e37
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242455
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/8728
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Julius Werner