The hack seems to set up coreboot display to use window B. We eventually
want to use the same window as the kernel is going to use (I think), so
that's what this patch does.
We think window B is hiding the contents of window A, which is why we
weren't seeing ChromeOS UI come up. This fix makes that not happen anymore
by making coreboot use window A.
BUG=chrome-os-partner:24844
TEST=Can boot ChromeOS to UI from coreboot.
Change-Id: I24b95200ba2e8eaeadecd45392ccee5e270aa7da
Reviewed-on: https://chromium-review.googlesource.com/182001
Tested-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
This improves boot time in 2 ways for a firmware upgrade:
1. Normally MRC would detect the S0 state without an MRC cache
even though it's told to the S5 path. When it observes this
state a cold reset occurs. The cold reset stays in S5 for
at least 4 seconds which is time observed by the end user.
2. As the EC was running RW code before the reset after firmware
upgrade it will still be running the older RW code. Vboot will
then reboot the EC and the whole system to put the EC into RO
mode so it can handle the RW update.
The issues are mitigated by detecting the system is in S0 with
no MRC cache and the EC isn't in RO mode. Therefore we can do the
reboot without waiting the 4 secs and the EC is running RO so
the 2nd reboot is not necessary.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Booted. Updated firmware while in OS. Rebooted. Noted the
EC reboot before MRC execution.
Change-Id: I1c53d334a5e18c237a74ffbe96f263a7540cd8fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182061
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It's helpful to have a generic function that will tell
the EC to reboot if the EC isn't running a specified
image. Add that and implement google_chromeec_early_init()
to utilize the new function still maintaing its semantics
of if recvoery mode is enabled the EC should be running its
RO image. There is a slight change in that no communication
is done with the EC if not in recovery mode.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Built and boot with recovery request. Noted EC reboot.
Change-Id: I22240f6a11231e39c33fd79796a52ec76b119397
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182060
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Set critical temperature thresdholds to 70C. This will cause DPTF
framework to shut down the system so it may need to be higher or
lower but will need some testing.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, start DPTF framework and observe it
using specified critical thresholds.
Change-Id: Ibbf6d814295eb5ff006cb879676b7613f5eb56a3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182025
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Added a method in each temp sensor to disable the aux trip points
and then a wrapper function to call this method for each enabled
temperature sensor.
The event handler function is changed to not use a switch statement
so it does not need to be serialized. This was causing issues
with nested locking between the global lock and the EC PATM mutex.
Some unused code in temp sensors that was added earlier is removed
and instead a critical threshold is specified in _CRT.
The top level DPTF device _OSC method is expanded to check for the
passive policy UUID and initialize thermal devices. This is done
for both enable and disable steps to ensure that the EC thermal
thresholds are reset in both cases.
Additionally the priority based _TRT is specified with TRTR=1.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and start
esif_uf application. Observe that temperature thresholds are set
properly when running 'appstart Dptf' and that they are disabled
after running 'appstop Dptf'
Change-Id: Ia15824ca42164dadae2011d4e364b70905e36f85
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182024
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The PATx methods will be passed a temperature in deci-kelvin,
so it needs to be converted back to kelvin before being sent
to the EC.
The PAT disable method is changed to take the temperature ID
as an argument so individual sensors can be disabled.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and
esif_uf userspace application. Start and stop DPTF and see
that temperature thresholds are set to sane values.
Change-Id: Ieeff5a5d2d833042923c059caf3e5abaf392da95
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182023
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some SSD modules don't support DEVSLP correctly due to their
firmware. Since the power savings are minimal, don't use
DEVSLP to prevent potential problems. Some of the symptoms
are that sometimes this causes USB devices to not work properly.
BUG=chrome-os-partner:23186,
BRANCH=panther
TEST=Boot tested on Panther
Change-Id: Iba3f721c73e0e760b6a9861ca23480ddb923df40
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181957
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The SMI on TCO timer timeout policy was copied from other
chipsets. However, it's not very advantageous to have
the TCO timer timeout trigger an SMI unless the firmware
was the one responsible for setting up the timer.
BUG=chromium:321832
BRANCH=rambi,squawks
TEST=Manually enabled TCO timer. TCO fires and logged in
eventlog.
Change-Id: I420b14d6aa778335a925784a64160fa885cba20f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181985
The PMC in baytrail maintains an additional set
wake status in memory-mapped registers. If these
bits aren't cleared the device won't be able to
go to S5 or S3 without being immediately woken up.
Therefore clear these registers.
BUG=chrome-os-partner:24913
BRANCH=rambi,squawks
TEST=Ensured PRSTS bit 4 is cleared after a reboot and S3 and S5 work
correctly.
Change-Id: I356e00ece851961135b4760cebcdd34e8b9da027
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181984
When CONFIG_ELOG is selected the reset, power, and wake
events are logged in the eventlog.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Various resets and wake sources. Interrogated eventlog
to ensure results are expected.
Change-Id: Ia68548562917be6c2a0d8d405a5b519102b8c563
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181983
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
KBD_IRQ# is moved to GPIO SC101, with SC50 going back to its original
SERIRQ function.
Note that this change breaks Rambi 1.5 keyboard functionality.
BUG=chrome-os-partner:24424
TEST=Manual on Rambi 2.0. Verify KB functions in OS with SC50 / SERIRQ KB
interrupt toggling removed from EC code.
BRANCH=Rambi, Glimmer, Clapper
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I3fa40441741ea9d52a6e2ff15925570510b5b82b
Reviewed-on: https://chromium-review.googlesource.com/181757
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There needs to be an ACPI linkage to provide the power resource
needed to wake this device so the kernel will enable the SCI
before going to suspend.
A link is added for both NIC and WLAN, but it is only tested
on the NIC.
This is a forward port from Duncan's beltino patch.
BUG=chrome-os-partner:24657
BRANCH=panther
TEST=build and boot on panther, suspend and wake with etherwake
Change-Id: I2804d2e904e26d6e34f5a177f0dabc1aaa3f0288
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181752
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
1. Clean up some debug messages
2. Remove some dead code
3. Correct some delay time.
BUG=none
BRANCH=none
TEST=build and boot up graphic
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I4362cd886cfd625ef55535839e8ad1a7416977d4
Reviewed-on: https://chromium-review.googlesource.com/181003
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is an emulation cpu.
Lots of stuff missing, clearly, but I want to get the basic outline right.
BUG=None
TEST=breaks no builds
BRANCH=None
Change-Id: Ie9431afe1dbc4eb8e4b5b73da006a0603a221f3f
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180385
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
- Remove some unused functions from CPU participant that were
confusing the userland component since the CPU does not have
an ACPI managed sensor.
- Guard the charger participant with an ifdef so it can be
left out if not supported.
- Use the EC methods for setting auxiliary trip points and for
handling the event when those trip points are crossed.
- Add _NTT _DTI _SCP methods for thermal sensors. I'm not
clear if these are required or not but they seem to be expected
by the other DPTF framework components.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi and load ESIF framework
Change-Id: I3c9d92d5c52e5a7ec890a377e65ebf118cdd7087
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The EC now supports two auxiliary programmable trip points for
thermal monitoring. These are expected to be used by DPTF and
need to be exported.
In order to support these the header was updated from the latest
chrome ec source.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: I257d910daac4e36280c0cecf4129381a32ffcb9a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181661
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There needs to be an ACPI linkage to provide the power resource
needed to wake this device so the kernel will enable the SCI
before going to suspend.
A link is added for both NIC and WLAN, but it is only tested
on the NIC.
BUG=chrome-os-partner:24657
BRANCH=beltino
TEST=build and boot on beltino, suspend and wake with etherwake
Change-Id: Ifef013217c68f88d15e83d6f60de7eb80db8cbe5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181519
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
There's no reason to keep maintaining support on this mainboard, since nobody has one.
BUG=None
TEST=no need to test, it was no longer even used
BRANCH=None
Change-Id: I5c7c8ea4640170ba231fec82a94a54ee1876b845
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180503
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The products having shipped, and living in their own branch,
we might as well enable native graphics since:
1. it works
2. it removes a blob and the only good blob is a dead blob
3. it's faster
4. when we have problems, we can diagnose them more easily
5. when we get to newer kernels the boot time will magically get faster
as the driver realizes graphics is running. Where else do you get a 3-4 second
speedup for free?
BUG=None
BRANCH=None
TEST=Built and booted and saw graphics on peppy and falco
Change-Id: Iad937320e7f46b1de7ab00dace04115a7f182ed1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181225
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Historically we had set panel timing in the mainboard gma code. This goes
back to the replay-attack video startup.
We can let the haswell gma code set these values from the device tree
settings.
BUG=None
TEST=Build and boot with this change.
BRANCH=None
Change-Id: If32150d2857241ca2d2c88880086f49d25815d76
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180521
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
This is always built into coreboot, and is enabled by a static variable
in src/lib/hardwaremain.c. Payload choosing can be enabled at build
time, or at runtime via jtag/gdb.
The operation is simple. The chooser, if enabled, lists the payloads and puts
up a prompt.
Payloads:
fallback/payload
Pick one>
The user then types in the name of a payload, e.g.
Pick one>fallback/payload
The line is ended by newline or carriage return.
And the payload is booted.
If you get it wrong, no backspace
or correction. Just hit return and try again.
I started with Bayou but feel the need is low and the complexity
high for that solution; this is just much simpler.
So, let's think about some UI here. Some options:
- default to the first payload if the user hits return
- time out after 5 seconds or so
- Don't make people type the name;
number the payloads as they are printed and let the user
hit, say, 2, to get the second payload
What would you like to see?
BUG=None
TEST=Works on Nyan
BRANCH=None
Change-Id: I4f93633636abf73e65e1b14c1b9e77ac2e25c453
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180343
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
eMMC CLK was incorrectly configured as PULL_UP, but should have been
PULL_DOWN. 2K pulls somehow masked this problem.
BUG=chrome-os-partner:24353
TEST=Verify eMMC is bootable on Rambi on boards that previously failed
with an all-20K, all-PU eMMC pin configuration.
BRANCH=None
Change-Id: I0cbb6ebbb6818f83402b99330728266b09a0f5d6
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181034
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The kernel expects CPUs to be in a known good state at boot, which
means the CPUs are not in reset and not gated. Ungate the clock
and clear the resets for the LP cluster (cluster1) as is done for
the G cluster.
BUG=chrome-os-partner:23816,chrome-os-partner:24487
TEST=No more hangs during cluster switching.
BRANCH=None
Change-Id: I88d80f6072281beb98bba6ae38a0ddeb81165038
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180866
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
When the system loses AC power, the system will power back on
automatically as soon as the AC power is reapplied.
BUG=chrome-os-partner:24066
BRANCH=firmware-panther-4920.24.B
TEST=boot tested on panther
Change-Id: I37ddc5a162afcce01c2df5f509bfd7f2d0c15ba1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179537
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
BUG=chrome-os-partner:24455
BRANCH=none
TEST=Manual. Run heavy workload on device with fan disabled.
Verify throttling starts at 95C and system shuts down at 99C.
Change-Id: I3326b6e3c412b6360af37030cefd13d95b704e70
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180750
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The kernel does not support using pll_c_out0 as the parent of sclk,
nor does it support the use of super dividers. The reason for this
is that DVFS schemes must use the pre-divided rate with using super
dividers when setting voltages, which makes them essentially useless.
Instead, set pll_c_out1 to 300Mhz (pll_c / 2) and use that as the parent
of sclk.
BUG=chrome-os-partner:24487
TEST=Kernel now boots with sclk DVFS enabled
BRANCH=None
Change-Id: Ia106963d290122cddbaf9eaf88047fda2dfe8b8a
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180865
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
The BISOC.EXIT_SELF_REFRESH_LATENCY field should
not be updated from the default.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: I6e701a520513372318258648e998dd8c7ab29ea4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180730
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
For choosing payloads we need to be able to read out all the payload
headers. cbfs_payload_headers() delivers names and all the info available
about any payloads.
BUG=None
TEST=builds, tested on Nyan, works fine.
BRANCH=None
Change-Id: If98437819d53cc01d175234fc7429d6aa3383c2c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180352
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
This is for the aarch64 architecture. A followon patch will be for the
ARM Ltd. v8 cpu implementation, followed by a mainboard.
This builds but will require the two follow on patches and my recently submitted
cbfstool patch if you wish to see what it looks like.
It is missing critical support for functions such as memcpy, etc. but my goal
is to get an early view of where it is going to the community.
The initial test will be getting it to halt correctly.
BUG=None
TEST=it breaks no builds
BRANCH=None
Change-Id: Ic298fa5c86547bbe3ca0545d338877673219cfd4
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180178
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
As a first step towards removing hardcodes from the FUI support,
change the haswell call to i915_lightup to panel_lightup, and pass the
intel_dp * as a parameter. Get rid of the scalar arguments and make
them part of intel_dp. Get rid of file-scope variables and use the
ones in the intel_dp struct. In falco, use functions that peppy
uses. Drop slippy support for FUI, it's a dead board; if this is ok
I'll remove the files next.
And, incidentally, fix the broken RGBX constant and change it to BGRX.
BUG=None
TEST=build and boot on falco and peppy. Verify that the colors are now correct.
BRANCH=None
Change-Id: I46ef5a9ed8433382d042066ee3542af04cfc319a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174932
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
We have no good reason to be handling the TCO timeout
as an SMI since we aren't doing anything special with it
and clearing the status in the handler prevents the reboot
from actually happening.
BUG=chromium:321832
BRANCH=falco,peppy,wolf,leon,beltino,panther,monroe,samus
TEST=boot and read PMBASE+30h and check that bit13 is clear
Change-Id: I074ac0cfa7230606690e3f0e4c40ebc2a8713635
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180672
Rambi's reference code will live at slot 3 in the
verified firmware section.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. Verified correct area where
reference code was loaded from.
Change-Id: I8bee46600429ac8f732fe334852f69aff1324150
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180027
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
When employing vboot firmware verification the reference
code loading should load from the verified firmware
section. Add this ability.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted rambi. Noted firmware being loaded
from rw verified area. Also noted S3 resume loading
from cached area.
Change-Id: I114de844f218b7573cf90107e174bf0962fdaa50
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180026
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Certain platforms need to have reference code
packaged and verified through vboot. Therefore,
add this option.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built.
Change-Id: Iea4b96bcf334289edbc872a253614bb1bebe196a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180025
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Nyan's SPI chip is capable of dual-output reads, so let's use it.
BUG=none
BRANCH=none
TEST=built and booted on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I51a97c05aa25442d8ddcc4e3e35a2507d91a64df
Reviewed-on: https://chromium-review.googlesource.com/177836
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This implements x2 mode when reading CBFS media over SPI.
In theory this effectively doubles our throughput, though the initial
results were almost negligibly better. Using a logic analyzer we see
a pattern of 12 clocks, ~70ns delay, 4 clocks, ~310ns delay. So if we
want to see further gains here then we'll probably need to tune AHB
arbitration and utilization to eliminate bubbles/stalls when copying
from APB DMA.
BUG=none
BRANCH=none
TEST=built and booted on Nyan.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I33d6ae30923fc42b4dc7103d029085985472cf3e
Reviewed-on: https://chromium-review.googlesource.com/177835
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Add a Kconfig variable so that driver code knows whether
or not to use dual-output reads.
BUG=none
BRANCH=none
TEST=built and booted on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I31d23bfedd91521d719378ec573e33b381ebd2c5
Reviewed-on: https://chromium-review.googlesource.com/177834
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This reverts commit 58ee4a7f63.
The underlying problem has been fixed by:
ARM: Define custom ELF headers for ARM.
$ cbfstool /build/nyan/firmware/coreboot.rom printcoreboot.rom: 1024 kB, bootblocksize 83968, romsize 1048576, offset 0x18080
alignment: 64 bytes, architecture: arm
Name Offset Type Size
fallback/romstage 0x18080 stage 17556
fallback/coreboot_ram 0x1c580 stage 31509
config 0x24100 raw 2920
(empty) 0x24cc0 null 897752
BUG=None
TEST=Built for nyan and verified that the ROM stage was less than 18KB instead
of being 46KB.
BRANCH=None
Change-Id: I4727f1b3d96a27a6382363565ab3153cec559547
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180164
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
At least when building with the gnu toolchain, the headers the linker
automatically generate save space for the actual ELF headers in one of the
loadable segments. This creates two problems. First, the data you intended to
be at the start of the image doesn't actually show up there, it's actually the
ELF headers. Second, the ELF headers are essentially useless for firmware
since there's currently nothing to tell you where they are, and even if there
was, there isn't much of a reason to look at them. They're useful in userspace
for, for instance, the dynamic linker, but not really in firmware.
This change adds a PHDRS construct to each of the linker scripts used on ARM
which define a single segment called to_load which does not have the flag set
which would tell the linker to put headers in it. The first section defined in
the script has ": to_load" to tell the linker which segment to put it in, and
from that point on the other sections go in there by default.
BUG=None
TEST=Built and booted on nyan. Verified that the ROM stage was less than 18KB.
Reverted the change which forced ROM stage alignment and saw that the ROM
stage stayed the same size.
BRANCH=None
Change-Id: Ie2670f33f0421b16b2d4663fbfa99358890c77e4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180163
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Remove many no longer needed code and files.
More clean up will be followed.
BUG=none
BRANCH=none
TEST=build and boot up graphic
Change-Id: I72471be01e7c9b5244aff12b45f887dd35dfe58e
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/180135
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Make it clear that we are doing little more than toggling some
GPIOs. Also remove any hint that we think romstage is in RW; that's
some ways off.
BUG=chrome-os-partner:24548
TEST=just a comment change, it still builds.
BRANCH=None
Change-Id: Ie2bd051fb99ed86d588f6dfc2e80aea1edc8f07c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180161
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The ROMSTAGE_BASE currently must be aligned to 0x8000 bytes, otherwise linker
will try to do that and pad zeros, creating a large (ex, >40k) romstage blob,
which cannot be loaded properly.
BUG=none
TEST=Boots successfully on Nyan.
Change-Id: I7626542c8344bbf6641a200879e4aa18183dc1bd
Reviewed-on: https://chromium-review.googlesource.com/180150
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The kernel iosf driver uses HID INT33BD to probe and
be provided the 12 bytes in PCI for access.
BUG=chrome-os-partner:17279
BRANCH=none
TEST=build and boot on rambi, load iosf_mbi driver and
verify that it gets address 0xe00000d0
Change-Id: I865eafe664f00f21d1ebb967c291083830d895b9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180098
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Not used currently on rambi board. Disable in case it
saves power.
BUG=chrome-os-partner:23862
BRANCH=none
TEST=build and boot on rambi
Change-Id: Idb870c2cfa88cb6c3f1ada3caf0db566e33ec1eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180084
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
