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: Ic2c0f95cff2ae6e314967b0b82231a962255f1a7
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233857
Reviewed-by: Julius Werner <jwerner@chromium.org>
This reverts commit c29a5e368d.
This option is not used any longer.
BUG=None
BRANCH=None
TEST=Config not used.
Change-Id: I0718bd701c5588b39b69e36d8e2b510a82cf1372
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233075
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This patch changes the ram_media CBFS backend implementation to no
longer detect an absolute address that is inside the "memory region"
used to back the CBFS image (which on x86 is really just the
memory-mapped flash due to a depthcharge implementation detail). This
was (as far as I know only) used to support the ugly CBFS header pointer
situation with SeaBIOS, which is now resolved. It is a very dangerous
feature, since it's perfectly possible for a negative offset relative to
the end of the image to overlap that region. We only get lucky that in
our existing use cases the embedded CBFS is further away from the end of
the ROM than it's own size... if we instead had a 3MB image from
0xfffd0000 to 0xffff0000, then we might want to pass in an address like
0xfffe8000 (interpreted as a relative offset from the end) to refer to
the absolute address 0xfffd8000, but this feature would prevent that
since it fits inside the window when interpreted absolutely. (Also, it
is unlikely but possible that a non-memory-mapped architecture which
starts DRAM at 0x0 may put its bounce buffer within the first few
megabyte of the address space, so that a relative offset from the start
of the image could be interpreted as an absolute offset inside the
buffer.
CQ-DEPEND=CL:229962
BRANCH=None
BUG=None
TEST=Built and booted on Falco and Nyan_Blaze, confirmed that legacy
mode still works as well as before.
Change-Id: I0c9149d725adeecef2520342b307ce7ea52990c1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229976
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229975
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
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I50ca5bfdfbef9e084321b2beb1b8d4194ca5af9c
Reviewed-on: https://chromium-review.googlesource.com/231456
Reviewed-by: Julius Werner <jwerner@chromium.org>
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
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I69ee1fc7bc09c9d1c387efe2d171c57e62cfaf3f
Reviewed-on: https://chromium-review.googlesource.com/231132
Reviewed-by: Julius Werner <jwerner@chromium.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: Ic9c164ded03d10d6f6f3ce15e9b38b1f6ce61a91
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230471
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
This reverts commit e83de6429c.
The initialization can be moved into depthcharge. Moving it
there also provides symmetry with the backlight support.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=built on ryu
Change-Id: I46e720567f5732f3a0e0612caa91670e8cb5aa8a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229790
Reviewed-by: Furquan Shaikh <furquan@chromium.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: I6dd5ca34e9f3767003ccb0ca9daaf16116f4a2df
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228791
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Since display controller and panel configuration is done
in coreboot but the frame buffer address is not
available until payload stage, it is needed to have a
function in libpayload to set fb address and enable window
in dc registers.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Change-Id: Ib5fe9da4d8257d616e13c5556ec25d8b900d60e3
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226406
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Need to add function to set framebuffer address to dc register.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I3f2ed7a15cabf6be02786c5245d055b2bc6c7491
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226405
Reviewed-by: Aaron Durbin <adurbin@chromium.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: I7bfbfefb92001632ce3d572a50e46188795c4ab8
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226404
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: Iecd8739c9269b58064b3c3275f5376cebcd6804b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225506
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I2c114a8469455002c51593cb8be80585925969a7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225457
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We have two drivers for a 100%-identical peripheral right now, mostly
because we couldn't come up with a good common name for it back when we
checked it in. That seems like a pretty silly reason in the long run.
Both Tegra and Rockchip SoCs contain UARTs that use the common 8250
register interface (at least for the very basic byte-per-byte transmit
and receive parts we care about), memory-mapped with a 32-bit register
stride. This patch combines them to a single 8250_mmio32 driver (which
also fixes a problem when booting Rockchip without serial enabled, since
that driver forgot to check for serial initialization when registering
its console drivers). The register accesses are done using readl/writel
(as Rockchip did before), since the registers are documented as 32-bit
length (with top 24 bits RAZ/WI), although the Tegra SoC doesn't enforce
APB accesses to have the full word length. Also fixed checkpatch stuff.
A day may come when we can also merge this driver into the (completely
different, with more complicated features and #ifdefs) 8250 driver for
x86 (which has MMIO support for 8-bit register stride only), both here
and in coreboot. But it is not this day. This day I just want to get rid
of a 99% identical file without expending too much effort.
BUG=None
TEST=Booted on Veyron_Pinky and Nyan_Blaze with and without serial
enabled, both worked fine (although Veyron has another kernel issue).
Change-Id: Ib84d00f52ff2c48398c75f77f6a245e658ffdeb9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225102
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change is based on wtm2
BUG=none
BRANCH=none
TEST=compile ok and boot to OS
Change-Id: I9625662eaf782f44258c15b956d04cbfdb82a14a
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/212368
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: I56a0557d4257f40b5b30c559c84eaf9b9f729099
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223784
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With a few recently added configuration options many libpayload board
config got out of sync. The following command was used to normalize
them (with default answers to all questions):
for f in configs/config.*; do
cp $f .config
make oldconfig
mv .config $f
done
BRANCH=as required
BUG=none
TEST=none
Change-Id: I25b9862d868f9a62d663567b077e7b2b8cc42e22
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223650
Reviewed-by: Aaron Durbin <adurbin@chromium.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: Ie376e394d084edd6c999fc9edde79f15a0264e7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222664
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.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: I187d73a4d55d3c6f49afbe9852901672d25de8dc
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.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 nexttime 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: I4e123577ec5a5996d87d2fc52cb6cf5c571c9fae
Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/220123
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.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: I5cb4e5009359cb04c4e1b5fe60845f80fbdff02c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221725
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
With introduction of GDB support the GDB_DEBUG make parameter sounds
misleading. Let's change it to SOURCE_DEBUG. It is still quite useful
when debugging with GDB, but can be used with any debugger.
BUG=None
TEST=built coreboot with SOURCE_DEBUG in the environment, observed it
compiled as expected
Change-Id: Ia6cfddfa1764fb070f4d35f374ed4f35e38d38fe
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221386
Reviewed-by: Julius Werner <jwerner@chromium.org>
Set "CONFIG_LP_USB_EHCI_HOSTPC_ROOT_HUB_TT=y" for nyan-series
platforms to enable USB keyboard when it's connected to root hub.
BUG=chrome-os-partner:32355
TEST=Tested on nyan series platforms.
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: I0c47cdd7018133185b6ffe1a51c62932f1287b34
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/221035
Reviewed-by: Julius Werner <jwerner@chromium.org>
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: Id86a289bc587653b85227c1d50f7a4f476f37983
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/220125
Reviewed-by: Julius Werner <jwerner@chromium.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: I1d0bd437fb27fabd14b9ba1fb5415586cd8847bb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219444
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: If52ddc43ebd5d509c19f104928dced5bd09b1706
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/218403
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.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: Ie0f47b7759d4ac65a6920f7f2f7502b889afda6d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216824
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.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: I217bc5a5aff6a1fc0809c769822d820316d5c434
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216823
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.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: I44d9f394fa349abd7182c4ba10f1eaefd6e4fdaa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216822
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
We retroactively decided to use the variant name "pinky" for the Rk3288
board we're currently bringing up, and retcon the unadorned "veyron"
name to refer to the Rockchip evaluation board. Since we currently have
no interest to maintain coreboot support for that board in our tree,
let's rename everything to "veyron_pinky" and forget about "veyron".
CQ-DEPEND=CL:217592
BUG=chrome-os-partner:30167
TEST='emerge-veyron libpayload coreboot' fails but
'emerge-veyron_pinky libpayload coreboot' succeeds.
Change-Id: I366391efc8e0a7c610584b50cea331a0164da6f3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217674
Reviewed-by: David Hendricks <dhendrix@chromium.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: Id89ec2c1731d21496eca617a3c03abaf48062908
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216820
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/211053
Reviewed-by: Julius Werner <jwerner@chromium.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: Ic1d9e18e6fc016a04f17621a148e62d6cbd04ce7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214577
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.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: I678ab89c4aa1b08898166e135b5ab2d6453bb5e8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214576
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.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: I9b63e04aa26a98bbeb34fdef634776d49454ca8d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
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: If9a927318b850ec59619d92b1da4dddd0aa09cd1
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214072
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
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: Ic05d47422312a1cddbebe3180f4f159853604440
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/213917
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
