Move the SerialIO related register/bit defines into a separate header
file at broadwell/serialio.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I84fea5fd0b2c82f37e7aa025ed0188e0bf19c411
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198551
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Split the SPI related register/bit defines into a separate header
at broadwell/spi.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I6d675ede9f3d25a47761543dbf1e18e15e8f63e8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198550
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the SATA related register/bit defines into a separate header
file at broadwell/sata.h
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ia92439533d99def96316bab4898d38388e52c4dd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198429
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Split out defines for RCBA related registers/bits into a separate
header file in broadwell/rcba.h.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I070317015b546bb8a641e9a12279e3f86152ca66
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198428
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Various register/bit defines for power management offsets
in PMBASE are split into a separate header together with
the prototypes for pmutil helper functions.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I3d79e288b79641d8c4b4c8d10ed122b0c5c7e143
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198427
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the same copyright string and license formatting in
every file in the soc/intel/broadwell directory.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: Ibfa9f1f10ad0e2410d200f7120d07a793a2bbfb2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198426
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The haswell and lynxpoint code will form the starting point for
broadwell support but it will be heavily reworked to fit into
a unified soc directory.
For now just copy in the raw starting sources.
BUG=chrome-os-partner:28234
TEST=None
Change-Id: I013c5c95e839a27979da8b6ebbee290529ae3279
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198425
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When a watchdog reset happens, the SOC will reset but other parts of the
system might not. That puts the machine in a funny state and may prevent it
from booting properly.
BUG=chrome-os-partner:28559
TEST=Built for nyan, nyan_big and nyan_blaze. Booted normally, through EC
reset, software reset ("reboot" command from the terminal), and through watch
dog reset. Verified that the new code only triggered during the watchdog reset
and that the system rebooted and was able to boot without going into recovery
mode unnecessarily.
BRANCH=nyan
Change-Id: Id92411c928344547fcd97e45063e4aff52d2e9e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/198582
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
When a watchdog reset happens, the SOC will reset but other parts of the
system might not. In order to detect those situations we can check the
rst_status register in the PMC.
BUG=chrome-os-partner:28559
TEST=With this and a change which uses the new function in the nyan boards,
built for nyan, nyan_big and nyan_blaze. Booted normally, through EC reset,
software reset ("reboot" command from the terminal), and through watch dog
reset. Verified that the new code only triggered during the watchdog reset and
that the system rebooted and was able to boot without going into recovery mode
unnecessarily.
BRANCH=nyan
Change-Id: I7430768baa0304d4ec8524957a9cc37078ac5a71
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/198581
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Added the empty function clear_recovery_mode_switch (weak)
Problem:
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC is set,
the following will happen:
1. Boot device in recovery mode with Esc + F3 + Pwr.
2. Turn device off with Pwr button.
3. Turn device on with Pwr button.
Device still boots to recovery screen with
recovery_reason:0x02 recovery button pressed.
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC isn't set,
turning the device off and on again
with the Pwr button does a normal boot.
Solution:
Unconditionally clear the recovery flag.
BUG=chromium:279607
BRANCH=TOT
TEST=Compile OK.
Change-Id: Ie1e3251a6db12e75e385220e9d3791078393b1bf
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197780
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Sheng-liang Song <ssl@google.com>
Tested-by: Sheng-liang Song <ssl@google.com>
The original sdram-hynix-2GB-792.inc was just copied from nyan
bct file. This change updates the cfg file for Hynix 2GB, 792MHz
DRAM based on the data generated by t124_emc_reg_tool.
BUG=none
BRANCH=blaze
TEST=emerged coreboot, booted successfully into kernel.
Change-Id: I9534b4df6d35193179de124309df12ed830098a0
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/197660
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
All what's needed apart from configuring the feature is to provide a
function which would report the top of DRAM address.
BUG=chrome-os-partner:27784
TEST=manual
. with all other patches applied, the image proceeds all the way to
trying to download 'fallback/payload'.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: Ifa586964c931976df1dff354066670463f8e9ee3
Reviewed-on: https://chromium-review.googlesource.com/197897
Length arguments for VbExTpmSendReceive have type uint32_t but it calls function
which expects size_t. This change converts uint32_t to size_t on call and
size_t to uint32_t on return.
BUG=None
BRANCH=None
TEST=Booted Nyan Big to Linux
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1971488baae2d060c0cddec7749461c91602a4f9
Reviewed-on: https://chromium-review.googlesource.com/198016
This is a fix for the 'Lost arb' we're seeing on Nyan* during
reboot stress testing. It occurs when we are slamming the
default PMIC registers with pmic_write_reg().
Currently, I've only captured this a few times, and the bus
clear seemed to work, as the PMIC writes continued (where
they'd hang the system before bus clear) for a couple of regs,
then it hangs hard, no messages, no 2nd lost arb, etc. So
I've added code to the PMIC write function that will reset the
SoC if any I2C error occurs. That seems to recover OK, i.e. on
the next reboot the PMIC writes all go thru, boot is OK, kernel
loads, etc.
BUG=chrome-os-partner:28323
BRANCH=nyan
TEST=Tested on nyan. Built for nyan and nyan_big.
Change-Id: I1ac5e3023ae22c015105b7f0fb7849663b4aa982
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/197732
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
This service is required by various coreboot code modules. It looks
like the 8064 SOC does not provide anything better than a 32 KHz free
running counter (it is used in u-boot for us timer as well). Let's use
this for now.
BUG=chrome-os-partner:27784
TEST=manual
. with the rest of the patches applied AP148 boots all the way to
trying to start the payload.
Change-Id: I98b91ce179f7388d59c769a59caf49ca7640e047
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197896
This change forces storm platform to use the common CBFS SPI wrapper,
which makes the SOC specific CBFS code unnecessary and requires
including SPI controller support in all coreboot stages.
BUG=chrome-os-partner:27784
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Change-Id: Ib468096f8e844deca11909293d90fc327aa99787
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197932
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Since the same driver is going to be used at all coreboot stages, it
can not use malloc() anymore. Replace it with static allocation of the
driver container structure.
The read interface is changed to spi_flash_cmd_read_slow(), because of
the problems with spi_flash_cmd_read_fast() implementation. In fact
there is no performance difference in the way the two interface
functions are implemented.
BUG=chrome-os-partner:27784
TEST=manual
. with all patches applied coreboot proceeds to attempting to load
the payload.
Change-Id: I1c7beedce7747bc89ab865fd844b568ad50d2dae
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197931
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.
COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.
init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.
BUG=none
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197800
Tested-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
A typical SPI operation consists of two phases - command and data
transfers. Command transfer is always from the host to the chip (i.e.
is going in the 'write' direction), data transfer could be either read
or write.
We don't want the receive FIFO to be operating while the command phase
is in progress. A simple way to keep the receive FIFO shut down is to
not to enable it until the command phase is completed.
Selective control of the receive FIFO allows to consolidate the
receive and transmit functions in a single spi_xfer() function, as it
happens in other SPI controller drivers.
The FIFO FULL and FIFO NOT EMPTY conditions are used to decide if the
next byte can be written or received, respectively. While data is
being received the 0xFF bytes are transmitted per each received byte,
to keep the SPI bus clocking.
The data structure describing the three GSBI ports is moved from the
.h file into .c file. A version of the clrsetbits macro is added to
work with integer addresses instead of pointers.
BUG=chrome-os-partner:27784
TEST=not yet, but with the res of the changes the bootblock loads and
starts the rombase section successfully.
Change-Id: I78cd0054f1a8f5e1d7213f38ef8de31486238aba
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197779
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
I always thought the support for multiple logical SCSI units in the USB
mass storage class was a dead feature. Turns out that it's actually used
by SD card readers that provide multiple slots (e.g. one regular sized
and one micro-SD). Implementing perfect support for that would require a
major redesign of the whole MSC stack, since the one device -> one disk
assumption is deeply embedded in our data structures.
Instead, this patch implements a poor man's LUN support that will just
cycle through all available LUNs (in multiple calls to usb_msc_poll())
until it finds a connected device. This should be reasonable enough to
allow these card readers to be usable while only requiring superficial
changes.
Also removes the unused 'protocol' attribute of usb_msc_inst_t.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=Alternatively plug an SD or micro-SD card (or both) into my card
reader, confirm that one of them is correctly detected at all times.
Change-Id: I3df4ca88afe2dcf7928b823aa2a73c2b0f599cf2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198101
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
So I was debugging this faulty USB SD card reader that would just fail
it's REQUEST SENSE response for some reason (sending the CSW immediately
without the data), cursing those damn device vendors for building
non-compliant crap like I always do... when I noticed that we do not
actually set the Allocation Length field in our REQUEST SENSE command
block at all! We set a length in the CBW, but the SCSI command still has
its own length field and the SCSI spec specifically says that the device
has to return the exact amount of bytes listed there (even if it's 0). I
don't know what's more suprising: that we had such a blatant bug in this
stack for so long, or that this card reader is really the first device
to actually be spec compliant in that regard.
This patch fixes the bug and changes the command block structures to be
a little easier to read (why that field was called 'lun' before is
beyond me... LUN is a transport level thing and should never appear in
the command block at all, for any command). It also fixes a memcpy() in
wrap_cbw() to avoid a read buffer overflow that might expose stack frame
data to the device.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=The card reader works now (for it's first LUN at least).
Change-Id: I86fdcae2ea4d2e2939e3676d31d8b6a4e797873b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198100
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To avoid LCD_VCC glitch on cold reset, set SOC_DISP_ON as GPIO output high.
After gfx initialize was done set it to native funtion 2.
BUG=chrome-os-partner:25159
BRANCH=firmware-rambi-5216.B
TEST=Tested on Rambi and squawks, no LCD_VCC glitch anymore.
Change-Id: If16af498e910a8da1d77a9a66456eb767286a61a
Original-Change-Id: Icf62588fa0338f89fafb3fe9246c26f16bcdaa60
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/197985
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Use the RTC driver interface to find the timestamp for events instead of
reading the CMOS based RTC directly on x86 or punting on ARM. This makes
timestamps available on both architectures, assuming an RTC driver is
available.
BUG=None
TEST=Built and booted on nyan_big and link and verified that the timestamps
in the event log were accurate.
BRANCH=nyan
Change-Id: Id45da53bc7ddfac8dd0978e7f2a3b8bc2c7ea753
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197798
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Enable the AS3722 RTC driver for use with event log.
BUG=None
TEST=Built and booted on nyan_big. Built for nyan and nyan_blaze.
BRANCH=nyan
Change-Id: I8c26c304f4bed52d3fe5d2756931075d27bc2c6d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197797
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The AS3722 PMIC, like many PMICs, has an RTC built into it. This change adds a
driver for it which implements the new RTC API.
BUG=None
TEST=Built and booted with the event log code modified to use this interface.
Verified that events had accurate timestamps.
BRANCH=nyan
Change-Id: I400adccbf84221dcba8d520276bb91b389f72268
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197796
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This CL adds an API for RTC drivers, and implements its two functions, rtc_get
and rtc_set, for x86's RTC. The function which resets the clock when the CMOS
has lost state now uses the RTC driver instead of accessing the those registers
directly. The availability of "ALTCENTURY" is now set through a kconfig
variable so it can be available to the RTC driver without having to have a
specialized interface.
BUG=None
TEST=Built and booted on Link with the event log code modified to use the RTC
interface. Verified that the event times were accurate.
BRANCH=nyan
Change-Id: Ifa807898e583254e57167fd44932ea86627a02ee
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197795
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Most of the code related to the mc146818 is not related to the RTC and is
really for managing the CMOS storage. Since we intend to add a generic API
for RTC drivers it's inconvenient for those functions to have an rtc_ prefix.
This CL renames those functions so they start with cmos_ instead. There are
some places where rtc_init was called with a comment that says something about
starting the RTC. That wasn't correct before (the RTC is always running), but
it looks a little odd now that the function is called cmos_init.
This CL also opportunistically cleans up some style problems in this file.
BUG=None
TEST=Built for link. Built for nyan.
BRANCH=nyan
Change-Id: Id4b9f6bea93e8bd5eaef2cb17f296adb9697114c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197794
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Add the device ID definitions and properties for the SPI chip used on
the AP148 board.
BUG=chrome-os-partner:27784
TEST=manual
. with the rest of the patches applied AP148 boots all the way to
trying to read the payload.
Change-Id: I5a0e5c9d3cc9ea81bc5227c0fbc1d0a5fc7bec27
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197895
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The recent addition of the storm bootblock initialization broke
compilation of Exynos platforms. The SOC specific code needs to be
kept in the respective source files, not in the common CPU code.
As of now coreboot does not provide a separate SOC initialization API.
In general it makes sense to invoke SOC initialization from the board
initialization code, as the board knows what SOC it is running on.
Presently all what's need initialization on 8064 is the timer. This
patch adds the SOC initialization framework for 8064 and moves there
the related code.
BUG=chrome-os-partner:27784
TEST=manual
. nyan_big, peach_pit, and storm targets build fine now.
Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197835
For some reason the file has been added as an executable, it should
not be.
BUG=none
TEST=none
Change-Id: Ie53d1d22348f671b1137b282b0afb77d9bf159b2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197750
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This brings in the banana_cs version of the SPI driver.
BUG=chrome-os-partner:27784
TEST=none
Change-Id: Ie93ec8c962c26fff1f0a235516cd8a4062cab40b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194225
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We recently changed the USB stack to detach devices aggressively that we
don't intend to use. This alone is not really a problem, but it
exarcerbates the fact that our device detachment itself is not very
good. We destroy any local info about the device, but we don't properly
disable the offending port. The device keeps thinking that it's active,
and if we later try to reuse that device address for another device
things become confused.
The real fix would be to properly disable all ports that we don't intend
to use. Unfortunately, this isn't really possible in our current
device/hub polymorphism structure, and I don't want to hack a new
disable_port() callback into usbdev_t that really doesn't belong there.
We will only be able to fix this cleanly after we ported all root hubs
to the generic_hub interface.
Until then, an easy workaround is to just avoid reusing addresses as
long as possible. This is firmware, so the chance that we'll ever run
through 127 devices is really small in practice. Even if we ever fix the
underlying issue, it's probably a smart precaution to keep.
BRANCH=nyan,rambi
BUG=chrome-os-partner:28328
TEST=Boot from a hub that has an "unknown" device in an earlier port
than the stick you want to boot from, make sure you can still boot.
Change-Id: I9b522dd8cbcd441e8c3b8781fcecd2effa0f23ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197420
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The console output driver framework in libpayload is currently built on
the putchar primitive, meaning that every driver's function gets called
one character at a time. This becomes an issue when we add drivers that
could output multiple characters at a time, but have a high constant
overhead per invocation (such as the planned GDB stub, which needs to
wrap a special frame around output strings and wait for an
acknowledgement from the server).
This patch adds a new 'write' function pointer to the
console_output_driver structure as an alternative to 'putchar'. Output
drivers need to provide at least one of the two ('write' is preferred if
available). The CBMEM console driver is ported as a proof of concept
(since it's our most performace-critical driver and should in theory
benefit the most from less function pointer invocations, although it's
probably still negligible compared to the big sprawling mess that is
printf()).
Even with this fix, the problem remains that printf() was written with
the putchar primitive in mind. Even though normal text already contains
an optimization to allow multiple characters at a time, almost all
formatting directives cause their output (including things like
padding whitespace) to be putchar()ed one character at a time.
Therefore, this patch reworks parts of the output code (especially
number printing) to all but remove that inefficiency (directives still
invoke an extra write() call, but at least not one per character). Since
I'm touching printf() core code anyway, I also tried to salvage what I
could from that weird, broken "return negative on error" code path (not
that any of our current output drivers can trigger it anyway).
A final consequence of this patch is that the responsibility to prepend
line feeds with carriage returns is moved into the output driver
implementations. Doing this only makes sense for drivers with explicit
cursor position control (i.e. serial or video), and things like the
CBMEM console that appears like a normal file to the system really have
no business containing carriage returns (we don't want people to
accidentally associate us with Windows, now, do we?).
BUG=chrome-os-partner:18390
TEST=Made sure video and CBMEM console still look good, tried printf()
with as many weird edge-case strings as I could find and compared serial
output as well as sprintf() return value.
Change-Id: Ie05ae489332a0103461620f5348774b6d4afd91a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196384
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
To access superio in ramstage, we need to find the device by PNP path.
Original-Change-Id: Iea4451381545f7c401e212ac7d7567a32aa92b25
Original-Reviewed-on: https://chromium-review.googlesource.com/190841
BRANCH=zako
BUG=chrome-os-partner:25024
TEST=emerge-zako chromeos-coreboot-zako
Change-Id: I6118177e5d62b32596caeb119800e8716c998a90
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190972
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
When across warm reset, if VDD_3V3_SD_CARD gets power-cycled but VDDIO_SDMMC3
does not, we will get ~1.5V leakage on VDD. To fix that, we reset VDDIO_SDMMC3
to 0 along with VDD_3V3_SD_CARD in Coreboot. Payloads must turn on VDDIO_SDMMC3
explicitly before accessing SD card.
Note the warnings of "VDD_SDMMC must set early" in comment seems only happens on
U-Boot and can be removed.
BUG=chrome-os-partner:27053
BRNACH=nyan
TEST=Ctrl-U to boot from SD card, login and type "reboot", then Ctrl-U to boot
again. Without this patch, system will fail in loading kernel.
Change-Id: I7f85995317d18587d514ea3afcff3bfea0a33e93
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196961
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
When warm booting, SD card reader on Tegra 124 needs to be reset by setting
power GPIO to zero. Since we don't really access SD card in Coreboot, set it to
zero and let payloads enable power when they need to access SD cards.
CQ-DEPEND=CL:196783
BRANCH=nyan
BUG=chrome-os-partner:27053
TEST=emerge-nyan coreboot depthcharge chromeos-bootimage
# With related changes in depthcharge, boots SD card successfully.
Change-Id: I2d368eb9480c978e9e343648b58a729028c94622
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196774
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Some panels (including those on Big DVT) cannot work fine without link training
before sending the video signals, especially multi-lane Full HD panels. We need
to use the fast link training functions from kernel to support them.
BRANCH=Nyan
BUG=chrome-os-partner:28128, chrome-os-partner:28129
TEST=tested on nyan, nyan_big dvt.
Vince verified on Full HD panels.
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: Ifde8daf0ebdc6fb407610d3563f3311b2a72dbc4
Reviewed-on: https://chromium-review.googlesource.com/196162
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Minor style fixes to avoid future bikeshedding.
- Opening brace for functions go on their own lines.
- use fixed-length types where appropriate.
BUG=none
BRANCH=none
TEST=it compiles
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: If9855d32c8ed1f5977937806c8c4cce65dd7d450
Reviewed-on: https://chromium-review.googlesource.com/196955
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
When preparing an image for source level debugging, it is convenient
to be able to compile some modules with -O0, which makes it much
easier to follow the execution flow.
This patch allows to do it by defining GDB_DEBUG=1 in the environment
before invoking make. Adding this feature as a common config flag is
problematic, because we don't want to compile the entire image with
-O0.
BUG=none
TEST=manual
. ran make with GDB_DEBUG=1 and observed the modified compiler
invocation line in the log.
Change-Id: Ie0be653509509eeb64ea3a7229f54c0c812840a9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196359
This patch it the last one in the chain adapting the ipq9064 UART
driver for use in coreboot. A new config option
(CONSOLE_SERIAL_IPQ806X) is being introduced to control inclusion of
the driver.
The previously introduced uart_wrapper.c is now included in the build
to provide the console driver structure used by ramstage.
Necessary configuration options are added to allow use of UART in the
bootblock.
BUG=chrome-os-partner:27784
TEST=with this change the coreboot image on AP148 prints a banner on
start up:
coreboot-4.0 Wed Apr 23 16:24:51 PDT 2014 starting...
Change-Id: I129ee30ba17a5061b30cfee56c135df31eba98b5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196663
The IO accessor wrappers are used to allow integer register addresses.
A structure defining UART interface configuration is declared and
defined. A few long lines are wrapped. Interface functions are renamed
to match the wrapper API.
cdp.c is edited to fit into coreboot compilation environment, and the
only function required by the UART driver if exposed, the rest are
compiled out for now.
BUG=chrome-os-partner:27784
TEST=after all patches are applied the serial console on AP148 becomes
operational.
Change-Id: I80c824d085036c0f90c52aad77843e87976dbe49
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196662
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
These patch modifies .h files to match the coreboot API. A few more
significant changes are:
- UART specific fields removed from common board structure in cdp.h.
These fields are set at compile time in u-boot (where this
structure comes from), they will be set in a different structure in
the UART driver in an upcoming patch.
- an inline wrapper is added in gpio.h to provide GPIO API the UART
driver expects.
- the ipq_configure_gpio() is passed the descriptor placed in ro data.
BUG=chrome-os-partner:27784
TEST=none
Change-Id: Id49507fb0c72ef993a89b538cd417b6c86ae3786
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196661
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Coreboot is designed to have a single serial console at most, on top
of that it may have a CBMEM (virtual) console. Matters are complicated
by the fact that console interface is different between bootblock and
later stages.
A linker list of console driver descriptors is used to allow to
determine the set and type of console drivers at compile time. Even
though the upstream seems to have done away with this approach, which
does not seem the best idea.
As an alternative this patch introduces a common wrapper which
different UART drivers can plug in into. The driver exports a single
API which can be used both directly (in bootblock) and through the
wrapper (in later stages).
The existing drivers can be adjusted to fit this scheme one by one.
The common UART driver API also aligns fine with the upstream
approach.
BUG=chrome-os-partner:27784
TEST=none yet
Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196660
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Move the driver to where it belongs.
BUG=chrome-os-partner:27784
TEST=none
Change-Id: Iee33de0b29a6bb86ba7c37e7e89aabc0fee42e80
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196658
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
