As rambi has the ChromeOS EC on it the EC needs to
be configured properly. Do this along with updating the
ChromeOS support for passing on write protect state, recovery
mode and developer mode.
BUG=chrome-os-partner:23387
BRANCH=None
TEST=Built and booted to depthcharge. EC software sync appears to
work correctly. Additionaly, 'mainboard_ec_init' appears in
the console output.
Change-Id: I40c5c9410b4acaba662c2b18b261dd4514a7410a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174714
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The EC needs to be initialized early in romstage. Therefore
perform the call after console has been initialized in order to
view any messages that the code may spit out.
BUG=chrome-os-partner:23387
BRANCH=None
TEST=Built and booted with recovery mode and EC in RW. Noted that
system reboots the EC.
Change-Id: I35aa3ea4aa3dbd9bd806b6498e227f45ceebd7a1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174713
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
First, use the _set and _clr versions of the clk_enb and rst_dev registers to
avoid having to both read and write to clear or set bits. Also, check to see
if we're actually trying to set or clear bits before writing into those
registers.
BUG=None
TEST=Built and booted on Nyan.
BRANCH=None
Change-Id: If3e5a0401bef7888e6af6395dd480901d25fdf09
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174845
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
If we don't need the clocks or function units to get out of bootblock and onto
the main CPUs running rom stage, we can move that code to later where it might
be updated if/when we get early firmware selection going.
BUG=None
TEST=Built and booted on nyan.
BRANCH=None
Change-Id: Id4a77c24fe9f362a45d267c5f78808472c789e67
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174844
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=None
TEST=Built and booted into depthcharge. Saw that the AP could communicate with
the EC over SPI.
BRANCH=None
Change-Id: Ib19a8e543a96a0614a97afc6e795496b1bdfc8b4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173954
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Version 2 of the efi wrapper wants the speed of the TSC
timer initialized in the parameter structure.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted through depthcharge. No errors spit out by
wrapper.
CQ-DEPEND=CL:*147256
Change-Id: I9cd265ea6bde93be85fc6fbc905d83af57fc2773
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174712
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Before the special PUNIT settings the GFX pci device
had the same device id as the transaction router. This
required a special case in the transaction router's
driver to do the proper thing for read_resources().
However, that requirement is no longer needed as the
PUNIT special message is now being done. Therefore,
remove the work around.
BUG=None
BRANCH=None
TEST=Built and looked at resource allocation logs to confirm
work around is no longer needed.
Change-Id: I90b155cb5560ca3291f146c2f586456e5529f6b2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174652
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There's been a bit of confusion on this and the book is not helpful.
BUG=None
TEST=Just a comment, building is sufficient and it builds.
BUG=None
Change-Id: I497fe387238196602d57f178ba40eb4998ec2877
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173910
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The decision about what clocks and units to enable and what sources and
divisors to use had been configured in the tegra124 source, but really those
decisions need to be made on a mainboard to mainboard basis. This code keeps
some generic mechanism in the tegra124 directory but moves most of the rest of
it to the nyan directory.
It would be good to abstract the source and divisor setting functions a bit
more since that code is still pretty big, and requires knowledge of the clock
and reset controller and its constants and bitfields.
Also we should move code related to function units which aren't actually used
in the bootblock into later stages so they can be updated.
BUG=None
TEST=Built and booted on nyan.
BRANCH=None
Change-Id: Ied7ecceced3016f1fcb32101d780b7c235b881db
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174843
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This could be done much sooner in the generic timer initialization, but it's
not used by coreboot and, if it's done in the RAM stage, it would be
updateable when using early firmware selection.
BUG=None
TEST=Before setting up these timers, the Linux kernel behaved very poorly and
would hang, trip the watchdog timer, and/or otherwise crash. After setting
them up those problems were no longer noticeable.
BRANCH=None
Change-Id: I26e9dc6d5090a67c775e67f96cee13fad582803e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174836
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The kernel knows how to use the ARM architectural timer in a generic way, but
some setup is needed which is specific to the implementation. The tegra code
in the kernel doesn't configure those parts so we need to, or the kernel
behaves poorly.
BUG=None
TEST=Before this change, the kernel would hang, the watch dog timer would go
off and kill the machine, and/or there would be random seeming crashes and
instability. After this change those problems were essentially gone.
BRANCH=None
Change-Id: Ibe0dccc964771b0a4a2376be9940192a4dfa6c43
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174835
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This GPIO is still wired up and can be manipulated from servo, but using it in
the coreboot tables causes a couple problems. First, people may not realize
that the little switch on their servo matters and may be confused when their
machine isn't doing what they told it to. Second, dev mode is considered
selected when the GPIO is high. To simplify matching voltages and to ensure
the GPIO doesn't float around when no servo is attached, it has a pull up
configured for it in the SOC. That means that when no servo is attached, the
pin will be pulled high, effectively forcing the machine into developer mode.
With might be able to reverse the polarity of the GPIO through config files
for servo which could deal with the second problem, but we would still have
the first problem.
To simplify things and to avoid unforseen problems related to this GPIO, I
think it's best to just ignore its value like other chromebooks do and to rely
on the soft dev mode setting stored elsewhere.
BUG=None
TEST=Built and booted on nyan. Entered and exited dev mode using the keyboard
and hacking get_recovery_mode_switch to return yes or no at the appropriate
times.
BRANCH=None
Change-Id: I80c5e2d290ce9f1c3d60ef45c9132ddfd8ce7680
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174837
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Given the comments in the file and the description, I
suspected these are generated as part of the Nvidia tool
flow. Hence, I am committing them as-is, since there may be updates
in the future. I learned on the x86 side that it's best to stick
with this type of vendor-sourced file.
BUG=None
TEST=Builds and boots with this in place.
BRANCH=None
Change-Id: I8ccbe656188942064839f201576288ab619e6bfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174610
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
This patch adds a function to configure an output GPIO with the
PINMUX_OPEN_DRAIN flag set, such as is necessary for some of the DD
class GPIOs. It requires some shifting around of the GPIO code plumbing
but doesn't change the existing external interfaces.
BUG=None
TEST=None
Change-Id: Iac294aeb8705834104c8351849b37d07759c3dae
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174650
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The clock_ll_set_source_divisor() function has loads of issues, its
ugly name only being the least of them. This patch replaces it with a
nice little macro that allows you to very easily and cleanly specify the
clock source and target frequency you want to use for a specific device,
while automatically calculating the correct divisor bits at compile
time.
There's the small catch that Nvidia hardware designers in their great
wisdom decided to just encode the same clock sources with different bits
for a few devices. There's no easy way around this, so I suggest
building this solution for the common case and writing the bits directly
for those few outlier devices (right now we only need one of them).
Also moves some clock source configuration code from display.c to
clock.c so that we can lose the external dependency on clk_rst.h and
hide all the ugly clock internals in one file (which I think is a
cleaner architecture). This still won't prevent us from splitting the
clock_config() function into individual smaller wrappers at a later
point.
BUG=None
TEST=Booted, runs as good as before, dumped and compared all clock
source registers to ensure they stayed the same.
Change-Id: I2365c9167977eebe36fb1e8e48c7983cdd655f51
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174804
Wrong clock for I2C4 and it was not getting set anyway.
And, it was breaking I2C3.
BUG=None
BRANCH=None
TEST=Builds with this change. Boots as far as it ever boots for me. But as it is now it's so wrong
you really want to pick this one up.
Change-Id: I67d8bf0675759497a998a99e31810006a4424c90
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174684
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
There is nothing attached to these devices so we can disable
them as well as the function 0 DMA controller.
Also remove the EC SMI/SCI mappings since there is no EC.
BUG=chrome-os-partner:23593
BRANCH=beltino
TEST=build and boot on beltino
Change-Id: Iedfe711058676f7ee118b0b66ab0f8a1e792ea87
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174752
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Fan is attached to port 2 instead of 3.
BUG=chrome-os-partner:23593
BRANCH=beltino
TEST=tested with 4-wire fan on beltino board
Change-Id: I9878063a24b0b908c74522580f776a4ce7d03d75
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174751
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The AUX channel (panel communications link) is on i2c4.
Enable the clocks for it. Not knowing any better, since
no extant source or docs seem to indicate a best choice,
we leave it on CLK_M, which is also the power on
default.
BUG=None
TEST=Build and boot. Gets to depth charge. I've never see anything from depth charge so this is as far as I get.
BRANCH=None
Change-Id: I60882b9035ad901ddb3cf859a5e03558d918d989
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174620
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
This field was being set with the clock_ll_source_divisor function, but that
doesn't use the right shift amount when setting the source, and the disp1
register doesn't have a divisor field. Also, because there's no divisor, we
need to use a PLL that's already at the right frequency. Since PLLC is at
600MHz and is the PLL used for disp1 in U-Boot (according to the comment),
lets use that instead of PLLD.
BUG=None
TEST=Built and booted into the kernel on nyan. Saw that it no longer tripped
over its shoe laces when an illegal source was used for disp1.
BRANCH=None
Change-Id: Ibeeb6483bfedcaac994d78a0773fab41d982ae9c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174701
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
These few changes will turn on the backlight. There is a redundant (at present)
power on of the panel vdd but we should leave it there, as we are not
sure whether to keep it in romstage or not.
Note in this mode (at Nvidia's recommendation) we don't run the PWM as a PWM,
just a GPIO. That keeps things simple.
The backlight, incidentally, is turning out to be a nice, visible, power LED.
BUG=None
TEST=Build, boot, backlight comes on.
BRANCH=None
Change-Id: I5def9a0255d82fdd240be7e9097de3889595db2d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174533
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The code in that file was using the raw GPIO indices instead of using the GPIO
macro to generate a combined gpio_t index type. This technically works just
fine, but it's not how these functions are intended to be used.
BUG=None
TEST=Built and booted into depthcharge on nyan.
BRANCH=None
Change-Id: I6a886cc7b909b6622c67eeef93833f1a9cade835
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174418
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The load_stage_from_cbfs() when CONFIG_RELOCATABLE_RAMSTAGE is
selected is incorrect in that it hard coded the wrong stage name.
Instead it should honor the name past in instead of using a
predetermined (and wrong!) name.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built booted. Noted fallback path works.
Change-Id: I61654313d15167efe50d5e4ff24fb06eab16f389
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174391
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
A global microcode_ptr was added when doing the MP
development work. However, this is unnecessary as the
pattrs structure already contains the pointer. Use
that instead.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted. Microcode still being loaded correctly.
Change-Id: I0abba66fc7741699411d14bd3e1bb28cf1618028
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174552
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This reverts commit a84f498129.
Change-Id: Ieb9f2ae8cccfbf3d8abd1cebff9c998bffadc42c
Reviewed-on: https://chromium-review.googlesource.com/174542
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Linux tegra124 kernel uses pmc.odmdata to figure out serial console type &
address, which was defined by BCT in U-Boot world.
For Coreboot, we should build that value by Kconfig values. But since we don't
have a complete support for BCT & ODMDATA values yet, let's follow the values
defined in bct/odmdata.cfg.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan; boot # see linux kernel messages.
BRANCH=none
Change-Id: I95e8473df840cb9f55259670add9e99cebde4dee
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174486
The ramstage image is the third image in the partition (after ECRW hash
and depthcharge image).
TEST=Manual. Boot rambi, verify that ramstage image is correctly found:
"RW ramstage image at 0xffb1dc70, 0x0000f391 bytes"
BUG=None.
Change-Id: I628db3daf0b109106c51693960487a0c83b4e9f4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The reference code blog is needed to bootstrap
certain pieces of hardware in bay trail. Provide
the ability to run reference code by loading
the reference code as an rmodule.
Note that support for vboot verification and S3
resume is omitted from this commit.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with refcode loading.
Change-Id: I30334db441a57f4d87b4de6fca0a9a48e1c05c05
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174426
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order to identify the ram used in cbmem for
reference code blobs add common ids to be consumed
by downstream users.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with ref code support. Noted reference
code entries in cbmem.
Change-Id: Iae3f0c2c1ffdb2eb0e82a52ee459d25db44c1904
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order to incorporate external blobs into
CBFS besides MRC have a notion of a reference code
blob. By selecting HAVE_REFCODE_BLOB and providing
the file name the refcode blob will be added to
cbfs as a stage file.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Using this option and other patches able to build,
boot, and run blob code.
Change-Id: I472604d77f4cb48f286b5a76b25d8b5bfb0c7780
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174423
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Enabling the monotonic timer allows for collecting
boot stage times as well as each device initialization
time.
BUG=chrome-os-partner:23166
BRANCH=None
TEST=Built and booted. Noted timings in console output.
Change-Id: I5fdc703ea21710fd26de352f367c6fc0c767ab6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174422
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The PCU (platform controller unit) contains the
resources and IP blocks that used to reside in the
south bridge. Bay Trail has since renamed it south
cluster. There are quite a few fixed MMIO and I/O
resources. If these aren't added the resource allocator
will freely assign these addresses which causes conflicts
and other subtle bugs.
BUG=chrome-os-partner:23544
BUG=chrome-os-partner:23545
BRANCH=None
TEST=Built and booted through depthcharge. Verified
resource allocation not weird. And no more depthcharge
crashes.
Change-Id: I697fbda4538c03fded293bcb63a5823b1ed150ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174421
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This does a couple things:
- Fix typo in function name. This is not tegra2...
- Use #defines instead of numerical constants.
- Enable FLOW and set REQ_SEL.
BUG=none
BRANCH=none
TEST=built and booted on nyan
Change-Id: If35b75c13969ec1e898a4ff9d8cd3678508cb725
Reviewed-on: https://chromium-review.googlesource.com/174445
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This exposes some #defines that are needed by the SPI driver so that
we can get rid of hard-coded constants.
BUG=none
BRANCH=none
TEST=compile tested
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I460028173af8ec8fe11fac47d21f954d23ed6fc4
Reviewed-on: https://chromium-review.googlesource.com/174444
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
To access MMC 3/4 in payloads, we need to first configure pinmux for their data
and command channel.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
BRANCH=none
Change-Id: I6e54afb0c38b34ba637bc97e1caac7f7fef505f6
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174011
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The base clock is set to maximum speed supported by Tegra MMC controllers.
Actual SD clock speed will be configured by payloads.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
BRANCH=none
Change-Id: I4140cc0e680daab6692bb39327dc182eafac50e0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173841
This patch intializes the PLLs P, C, D and U in addition to the already
existing PLLX. It completely revamps the oscillator-dependent divisor
table mechanism, using binary compatible bitfield structs in a
transparent union to make it both compact and compile-time range checked
while still being readable and easy to use in a generic init_pll()
function.
It also moves the clock.h file into <soc/...> include space because I'm
going to need that for USB code soon.
BUG=None
TEST=Make sure it still boots as well as before.
Change-Id: I5f06f97eb9e0a7359fef02469c63306f500aa423
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174380
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This patch enables the UART first thing in the bootblock, without even
depending on a programmable clock source. This depends on being able to
divide CLK_M correctly, which may not be possible for all oscillator
frequencies, but it works for 12MHz.
BUG=None
TEST=Put a printk at the top of clock_init() and see it's output (also
put one after clock_config() and make sure that works as well).
Change-Id: Ided01a569fb3d141347992776970601042cb4402
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174339
Reviewed-by: Gabe Black <gabeblack@chromium.org>
- GPIO29 is no longer connected so we don't need the SMI workaround
on the entry to sleep states.
- Disable touchscreen wake source until the kernel driver is working
so it does not wake immediately.
- Update a few GPIOs and disable the codec for now as it is leaking
into the 1.8V DDR rail.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: Ia67b17eb4a097627befd8f39aadc939da1bf3d40
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174122
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The LPDDR3 memory is x32 and dual rank with 14 row bits.
In addition the memory is actually elpida, even though
they are owned by micron it is confusing to label it as such.
And the ram strap options were inverted from what I expected
so the memory table needs to be updated.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: Ia29a23e8140d884fb84f940806f041b40562aab9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is only one bit for memory width reporting, either x16 or
other. With x32 memory this code is reporting it as x8 so instead
report "x8 or x32" in this condition.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: I2a7c49bcb8de19084947b9dc42b93140641886fc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174120
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds a stub for dcache_line_bytes() that returns a hard-coded
value for now. The actual value won't matter until we try to turn
on caching in the bootblock (if ever).
BUG=none
BRANCH=none
TEST=tested on nyan
Change-Id: I3876e8282698cc860ddd7b65e58246d8095958bd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173976
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This exposes the function that obtains cache line size so that it can
be used by drivers in DMA-related functions.
BUG=none
BRANCH=none
TEST=built and booted on nyan, nothing obvious broke
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9b0ddc36aa39084f0d621af064487d1b2ef3d023
Reviewed-on: https://chromium-review.googlesource.com/174099
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
