Add XDR functions and use them to convert the ELF headers
to native headers, using the Elf64 structs to ensure we accomodate
all word sizes. Also, use these XDR functions for output.
This may seem overly complex but it turned out to be much the easiest
way to do this. Note that the basic elf parsing function
in cbfs-mkstage.c now works over all ELF files, for all architectures,
endian, and word size combinations. At the same time, the basic elf parsing
in cbfs-mkstage.c is a loop that has no architecture-specific conditionals.
Add -g to the LDFLAGS while we're here. It's on the CFLAGS so there is no
harm done.
BUG=None
TEST=Build and boot for Peppy; works fine. Build and boot for nyan, works fine. Build for qemu targets and armv8 targets.
BRANCH=None
Change-Id: I5a4cee9854799189115ac701e22efc406a8d902f
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178606
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Patch 547fbbfe2e introduced an off-by-one error in the offsets of the
PMU register struct, which put both the newly added register and the
PSHOLD that comes after it in the wrong place. This patch corrects the
offsets (5420 had already been correct).
BUG=None
TEST=Boots on Snow.
Change-Id: I1d9d31a6a73ee91890824e94fbd247d5feb4f6ae
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179411
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
On Tegra1x4 platforms, certain display-related registers
cannot be accessed unless the VPR registers are correctly
set up first. This allows the kernel graphics driver to
talk to the HW in the same manner on all Tegra SoCs.
Change-Id: I96e0c4075709da51be530a473da8d593ca498722
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/179327
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Now that the SD card controller is limited to the SD card
2.0 spec it's possible to use 20K pulls for the pads.
BUG=chrome-os-partner:24423
BUG=chrome-os-partner:24312
BRANCH=None
TEST=Built and booted. Able to dd to/from /dev/mmcblk1 without
any errors.
Change-Id: Id5396c55330a84bf7a09d227507d2bfcde66a1a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179423
The rambi board can only meet the SD card 2.0 specification.
Therefore, the controller capabilities need to be overridden
to match.
BUG=chrome-os-partner:24423
BRANCH=None
TEST=Built and booted. /sys/kernel/debug/mmc0/ios shows
high speed as maximum timing as well as 3.3V signal voltage.
Change-Id: Ib3824800852376e0f15a70584917d6692087ccfe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179415
The SD card controller can have the capabilities it supports
to be overridden. Add two optional fields to the chip structure
to allow the mainboard to override the SD card controller
capabilities.
BUG=chrome-os-partner:24423
BRANCH=None
TEST=Built and booted. Noted capabilities override console output.
Change-Id: Ibfef8f765b35eeec6da969dd05f5484f8672a7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179414
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The VDAT data was off by 2 bytes when reading it from the
kernel. The reason is that the header did not line up
correctly with actual ACPI code.
BUG=chrome-os-partner:24440
BRANCH=None
TEST=crossystem devsw_cur now returns either 0 or 1 depending
on state.
Change-Id: Ie78599f29cd5daf7da98db5e37fa276d24339f6a
Signed-off-by: Aaron durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179372
Bay Trail has 3 banks of gpios. Therefore, in order to
properly identify a gpio the specific bank number as well
as the GPIO within that bank is needed. The SPI
write-protect GPIO is GPIO 6 within the SUS bank (offset
0x2000).
BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24408
BRANCH=None
TEST=Built and booted. Looked at GPIO sysfs in the
chromeos_acpi directory.
Change-Id: Ic51b5abe3bacf6cf9b6a90cf666f1a63b098a0e3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179195
The coreboot eclass can append these options to the coreboot config to enable
the serial console.
BUG=None
TEST=Built and booted on nyan and verified that serial was enabled. Built for
all other supported boards except baskingridge which is already broken.
BRANCH=None
Change-Id: I01cfce6dafc866bcc30d98f064a320f2243b4fed
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178210
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Install the BL1 and set up the checksum in the Makefile instead of relying on
post processing. Import the exynos checksum script, split it in two and
simplify it significantly. Stop putting the CBFS header in the midst of the
bootblock so that it can be checksummed before CBFS is put together. Stop
saving space for it and leaving an anchor in the bootblock which nobody looks
for.
BUG=None
TEST=Built and booted on pit. Built for snow, but it doesn't boot on ToT so I
couldn't test it more than that.
BRANCH=None
Change-Id: Icbb5a5914ece60b2827433b6dc29d80db996ea6c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179229
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The LPE audio device needs 1MiB of memory for its firmware.
It also has a requirement that the memory needs to be on a
512MiB boundary. Just take 1MiB @ 512MiB for the LPE device.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and analyzed console logs for resources. Also interrogated
registres within the kernel.
Change-Id: I4d9ad5c7b5a2f3eb627b30528d738289278b3a7b
Reviewed-on: https://chromium-review.googlesource.com/179192
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
The test on official ChromeOS firmware bitmaps will be very blurry if
the screen resolution is too low (current value, 0x114 = 800x600).
BUG=chrome-os-partner:23766
TEST=emerge-panther chromeos-coreboot-panther
Change-Id: I0b26a3d4a14397fb7e195cda57bc5c1bc713e29e
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179202
Commit-Queue: Mohammed Habibulla <moch@google.com>
Tested-by: Mohammed Habibulla <moch@google.com>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The Linux kernel driver cannot handle Baytrail legacy GPIOs, so make the
default input GPIO type MMIO.
BUG=chrome-os-partner:24408
TEST=Manual on Rambi. Run "echo 169 > /sys/class/gpio/export; cat
/sys/class/gpio/gpio169/value", verify GPIO value changes based upon mic
jack status.
BRANCH=None
Change-Id: I27870ce8b7ecae9228e06e48c8759409c824c2eb
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179169
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Strengthen PUs on all eMMC pins to fix problems with eMMC not coming up
on certain boards.
BUG=chrome-os-partner:24353
TEST=Manual. Burn FW on board that previously failed to boot eMMC,
verify chromeos can now install + boot from eMMC.
BRANCH=none
Change-Id: I7a9742968b8b8c2c42285ffc21de46aed9c87fb7
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178917
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Rambi 1.5 boards use the native SD card controller on baytrail.
Therefore, enable those signals. The CLK, D*, and CMD pins use
2K pulls as these were shown to not exhibit any errors when
doing reads or writes to a DDR50 sd card.
Note that if a servo is connected on needs to enable the
sd_vref_sel rail to pp1800 as this causes issues with card
detect if it is not set to pp1800.
BUG=chrome-os-partner:24312
BRANCH=None
TEST=Built and booted. Tested sd card read and write works in kernel.
Also noted that write protect detection works as well.
Change-Id: I520e2808acbd8494534fcb710411dbc0e12fc874
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178961
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The enable_resources callback was accidentally populated
with NULL. Make that callback be the generic
pci_dev_enable_resources.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted.
Change-Id: I670b51bd9aff6764e9b549287a737b662572cdc7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178960
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The USB VBUS GPIOs on Nyan boards are two-directional: usually the SoC
sets them high or low to enable USB power, but on overcurrent conditions
they get forcefully driven low by the voltage source. To avoid driving
it from two sides, we configure them on the SoC side as tristated input
pins with a pull-up instead.
BUG=None
TEST=Made sure USB devices still get detected.
Change-Id: I423cb312805cbacb651a569ddc1530813b148576
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178914
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
The new IASL is complaining about the PCI memory region not
having consistent base/end/length values because they are
placeholder that are fixed up in the method before returning.
Put in some more valid placeholder values to make it happy.
BUG=chromium:311294
BRANCH=none
TEST=build and boot with IASL 20130117 on rambi
Change-Id: I0e21adcce43deb14d3c2c45787ff8c9efc357c2f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178864
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@google.com>
Rambi has the LPE audio codec connected to PMC_PLT_CLK[0].
Configure it for 25MHz.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted. Noted message in console output.
Change-Id: I11297ba951149e5831c65ca70ac7bdbbed113098
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178781
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Add device tree option to determine if the LPE
audio codec has a platform clock signal connected
to it from the SoC. If a frequency is selected the
platform clock number is used to enable the
clock.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted rambi with 25MHz option. Probed pin
to audio codec. Noted 25MHz clock.
Change-Id: I67d0d034f30ae1c7ee8269c0aea43e8c92ff868c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178780
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The C standard considers it legal to return a NULL pointer for zero
length memory allocations, and our malloc implementation does in fact
make use of that. xmalloc() and xzmalloc() should therefore not consider
this case a failure.
Also fixed a minor formatting issue.
BUG=None
TEST=Made sure xmalloc(0) and xmalloc(1000) succeed and
xmalloc(0xffffffff) still dies.
Change-Id: Ib9b75df9458ce2ba75fd0bc0af9814a3323298eb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178725
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
There are 3 banks of GPIOs that need to be described
with specific _UID and memory/interrupt values.
BUG=chrome-os-partner:24314
BRANCH=none
TEST=build and boot on rambi, check for probed driver:
gpiochip_find_base: found new base at 154
gpiochip_add: registered GPIOs 154 to 255 on device: INT33FC:00
gpiochip_find_base: found new base at 126
gpiochip_add: registered GPIOs 126 to 153 on device: INT33FC:01
gpiochip_find_base: found new base at 82
gpiochip_add: registered GPIOs 82 to 125 on device: INT33FC:02
fed0c000-fed0cfff : INT33FC:00
fed0c000-fed0cfff : INT33FC:00
fed0d000-fed0dfff : INT33FC:01
fed0d000-fed0dfff : INT33FC:01
fed0e000-fed0efff : INT33FC:02
fed0e000-fed0efff : INT33FC:02
Change-Id: I9619e2af4e1ccdf3d7b2e4ae280aadf22e278aeb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178601
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These panel numbers provided by the OEM.
The old display will stop working.
BUG=None
TEST=builds. I'll test when I get a unit.
BRANCH=None
Change-Id: I6020f0c725d44c4b69d5806e0dfc8da125686baf
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177958
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The xmalloc wrapper checks whether the malloc succeeded, and if not stops
execution and prints a message. xmalloc always returns a valid pointer. The
xzalloc wrapper does the same thing, but also zeroes the memory before
returning it.
BUG=None
TEST=Used this function in nyan, built and booted on it.
BRANCH=None
Change-Id: I00e7de04a5c368ab3603530b98bd3e3596e10632
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178001
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
With microcode 31E MWAIT 0x51 is now C6NS and 0x52 is now C6FS.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi, check that C1/C2/C3 are all used now
Change-Id: I8528d808f4082c85d90e2b57747d9f2e2d982b85
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178461
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Some 1.5 boards have a single channel ram configuration.
Accomodate such configs.
BUG=chrome-os-partner:22865
BRANCH=None
TEST=Built and booted ChromeOS.
Change-Id: I513327e47b9211d2dd1ea960d7da671a3773cb91
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178340
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
BUG=chrome-os-partner:24258
TEST=built/booted on Norrin/Nyan1 OK, loaded 3.10 kernel, and
did a shutdown -r. Next boot was OK.
Note that if other regs in the PMIC need to be (re)initialized,
it's a simple matter of adding more entries to the init_reg table.
Change-Id: I8cb4721da90673216f0a771d72c6d81590532837
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/178226
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If a programming error is detected, die can be used to print a message and
stop execution similar to failing an assert. There's also a "die_if" function
which is conditional.
die functions, like asserts, should be used to trap programming errors and not
when the hardware does something wrong. If all code was written perfectly, no
die function would ever be called. In other words, it would be appropriate to
use die if a function was called with a value that was out of bounds or if
malloc failed. It wouldn't be appropriate if an external device doesn't
respond.
In the future, the die family of functions might print a stack trace or show
other debugging info.
BUG=None
TEST=Used the die_if function in other code and verified that it stops
execution, prints messages like printf, shows file, line, and function
information, and is correctly gated by its condition.
BRANCH=None
Change-Id: I653fc8cb0b4e459522f1b86f7fac280836d57916
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178000
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This adds some delay to allow for the SPI controller to copy data
from the Rx register to the FIFO.
This is intended to complement a similar patch in Depthcharge.
BUG=chrome-os-partner:24215
BRANCH=none
TEST=built and booted on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Idc12f8a835e7e6529724254948684bd05cafdac1
Reviewed-on: https://chromium-review.googlesource.com/177832
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This pin is active low and resets the SOC and TPM. It leaves the memory alone
so that panic info can be discovered by the kernel once the reboot is
complete.
BUG=chrome-os-partner:24098
TEST=With a corresponding change in depthcharge, verified that depthcharge can
reboot the SOC using this GPIO.
BRANCH=None
Change-Id: I101dbb712c458b88213e2254fd1893a1284d1491
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177965
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This print isn't really useful and consumes a lot of time (~13ms)
during copying phases.
BUG=none
BRANCH=none
TEST=Built and booted on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I2f32dc097dd3d2b53edd739124f4317f2f91ad71
Reviewed-on: https://chromium-review.googlesource.com/177833
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The AHB burst length was being set to an invalid value. Apparently
this didn't hurt anything, but we may as well set it correctly.
Also, we don't need to explicitly set AHB_SEQ_WRAP since it defaults
to the value we want.
BUG=none
BRANCH=none
TEST=built and booted on Nyan rev. 0 and 1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iffb9edeb178ab48876f891d0822a24daae93aa8e
Reviewed-on: https://chromium-review.googlesource.com/177564
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch activates -ffunction-sections and -fdata-sections for the
compiler and --gc-sections for the linker. This will strip out all
unused functions and static/global variables from the final binaries and
reduce the amount of data we need to read over SPI.
A quick test with ToT images shows a 2.5k (13%) / 10k (29%) / 12k (28%)
reduction on Nyan and 3k (38%) / 23k (50%) / 13k (29%) on Pit,
respectively for bootblock / romstage / ramstage.
BUG=None
TEST=Made sure Nyan and Pit still boot to kernel.
Change-Id: I052411d4ad190d0395921ac4d4677341fb91568a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177111
This doesn't seem to be truly necessary, but it matches what other drivers do
and might be a good idea for safety's sake.
BUG=chrome-os-partner:24138
TEST=Built and booted on norrin.
BRANCH=None
Change-Id: Ie7c2717e81b2a5dcb831e608eb56347709dc1483
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177638
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
On nyan boards, the hardware flow control pins for the UART aren't used or
connected to anything, but the reset pinmux settings still have them routed
out some of the SOC pins. That can break input over the serial console if the
pin is pulled in the wrong direction.
Also, if the RX line isn't connected to anything, ie if no servo is connected,
then we don't want it to float around and potentially draw power through the
input pin buffering logic. We add a pull up to it so it will go somewhere in
particular if otherwise unattached.
This is generally not a great place to put pinmux configuration because it's
specific to a particular board but this is shared by everything with a
tegra124 in it. It's a good idea to have serial output as soon as possible,
though, and the other serial related pinmux settings were probably put here
before we really understood the complexities and flexibility of the tegra
pinmux. We might want to factor out this part of the serial console config and
delegate it to a hook in the mainboard specific code, or just wait until we
call bootblock_mainboard_init.
BUG=chrome-os-partner:24138
TEST=Built and booted on a peppy based nyan. Before this change serial input
was ignored. After this change, serial input was accepted by both the firmware
and the kernel.
BRANCH=None
Change-Id: Ie5428500aa525a600eb1ff4a81b5cc2805d5cc92
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177637
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Instead of choosing between SDRAM configurations for rev0 nyans and everything
else (currently only rev1), we should create a kconfig for each possible config
and put them inside a "choice" block. That way we can have an arbitrarily large
number of choices without them getting to be hard to manage or accidentally not
being mutually exclusive. This also makes the choice of SDRAM config more
explicit instead of it being implied by what rev you're compiled for.
One tradeoff of this approach is that you need to know which config goes with
which rev. Unfortunately we can't decide using the board ID like we can for
most other things because the BCT is consumed by code we don't control before
any of our own code runs.
We default to the slower config for safety's sake, because it will work on
both boards, and because it's the right config for the norrin which we were
going to transition to soon anyway.
Also, we can eliminate the NYAN_IN_A_PIXEL kconfig variable. Alas, we hardly
knew ye.
BUG=None
TEST=Built and booted on both types of nyan.
BRANCH=None
Change-Id: I9a630189e001e95c740c6741057511bf5939fdbb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177580
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Use the board ID to figure out how to initialize the PMIC instead of using a
config option.
BUG=None
TEST=Built and booted on both types of nyan.
BRANCH=None
Change-Id: I26f735f3c7ba910fd237a1d00d616d3d89b9fbd9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177489
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
We can use that to figure out which revision of nyan we're running on and make
some small adjustments for the differences in hardware.
BUG=None
TEST=Built and booted on both versions of nyan.
BRANCH=None
Change-Id: Iaedbc36dcc8e27b95b1e1ec5687bd9592c49d775
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177488
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This sets the sclk:hclk:pclk ratio to 1:2:2 which allows faster
transfers from peripherals to memory.
Performance-wise this currently decreases ramstage loading time
by about 20ms and payload loading time by 35ms.
BUG=chrome-os-partner:24182
BRANCH=none
TEST=Built and booted on Nyan rev 1 and 0. No longer see long
delays in between bytes when transferring >64 bytes via SPI.
CQ-DEPEND=CL:177578
Change-Id: I5812122bf6312a1ab490945c6e52fa3372e86fc9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177563
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
NCORE pad addresses were wildly wrong due to documentation bugs.
BUG=chrome-os-partner:24179
TEST=Manual on Rambi. Verify display isn't always on. Verify brightness
control now works in Chrome OS.
BRANCH=None.
Change-Id: I464436a58baa4957329c11231c5a866dafd97ce8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177597
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The memory clock set up for the pixel based nyan boards is too fast for the
peppy based boards. We want to use the right config for the right board, so
that needs to be configurable based on what board your targeting.
This CL makes the SDRAM BCT config configurable based on whether your nyan is
in a pixel case, and also adds a slower config for us on norrin.
BUG=None
TEST=Built with settings for each board. Used bct_dump to verify that the
settings matched the current config.
BRANCH=None
Change-Id: Ibf1335ac3c9eb488d3753e41c5c9c40c9eda3d56
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177487
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It turns out that kconfig will silently ignore settings to a variable that
doesn't have a prompt, meaning that this variable was always off no matter
what the config said.
BUG=None
TEST=Before this change, saw that CONFIG_NYAN_IN_A_PIXEL was always off no
matter how it was set in the config. Afterwards, saw that the value followed
the setting in the config.
BRANCH=None
Change-Id: I6f003c4bc2fbaea013a3f1e328280e64fbe7479d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177486
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The level shifting between 3.3V and 1.8V for the SERIRQ
signal is not working. Instead use the SERIRQ pad as
a gpio which is used as a direct IRQ signal for the
keyboard interupt.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi. Keyboard works with associated EC change.
CQ-DEPEND=CL:177189
Change-Id: Ifc270ca38207828a6d4711551d4bde9121559cca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177223
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Some boards need to override which IRQ the i8042 keyboard
controller has its interrupt on instead of the default
IRQ#1. The SIO_EC_PS2K_IRQ macro provides the mainboard
an ability to override the interrupt location.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi using this option. New IRQ is correctly
picked up by kernel allowing keyboard support.
Change-Id: Ic2b222018dfc3aa30e24a31009e832ae0fb7e9cf
Reviewed-on: https://chromium-review.googlesource.com/177222
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(panther port of Ib980100c648ae7472eac6f97e47f8ef3cbe72c7e)
BUG=none
BRANCH=none
TEST=boot tested on Panther
Change-Id: Iedcc107a43be170762d42d515c7e2a16ec395452
Reviewed-on: https://chromium-review.googlesource.com/177474
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@google.com>
Tested-by: Mohammed Habibulla <moch@google.com>
This writes the default value to the register, but it gets rid of
the error that disturbs some of our tests:
ERROR: PNP: 002e.4 70 irq size: 0x0000000001 not assigned
(panther port of Ieab1c776b553c996a7d06e4059110943aaf41338)
BRANCH=none
BUG=chrome-os-partner:23945
TEST=boot test on Panther
Change-Id: Id45c3bdc0d2feaf6f75d984c41d1f6ffef592d4d
Reviewed-on: https://chromium-review.googlesource.com/177468
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@google.com>
Tested-by: Mohammed Habibulla <moch@google.com>
The exception_test() mechanism might have been useful when exceptions
were first implemented, but now that they are pretty stable it's really
not necessary anymore (especially not on every single boot in production
Chromebooks). It forces a simple unaligned access, and as we start
having exceptions in stages that might not have paging turned on yet,
it's better to remove that completely.
Also removed the duplicated implementations of SCTLR-stuff and switched
to the existing ones in cache.h.
BUG=None
TEST=Made sure Pit and Nyan still boot and can trigger exceptions in all
stages.
Change-Id: I85e66269f5e2f2dfd3e8aaaa18441493514b62f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177101
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
