Age | Commit message (Collapse) | Author |
|
split the LP0 code for tegra2 into common
LP0 code and chip specific warm boot code
BUG=chromium-os:23496
TEST=build for Seaboard
Change-Id: Id9756c08f61502affa8beee636d883d01468e6ec
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/13799
|
|
As clock source for graphics related clocks is different
for Tegra2 and Tegra3, define it under platform specific
directories.
BUG=chromium-os:23496
TEST=Build ok for Cardhu, Waluigi and Seaboard. Tested on Waluigi.
Original work by -
Mayuresh Kulkarni <mkulkarni@nvidia.com>
Change-Id: I6cee11df5e75eaf3836565c4fa4f3ab3e45d8cac
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14700
|
|
Set display parent clock separately for Tegra2 and Tegra3.
BUG=chromium-os:23496
TEST=Built ok for Cardhu Walgui and Seaboard. Tested on Waluigi.
Change-Id: Ie03d37b8dda77dcfcb72e70c34e769a23323e598
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14697
|
|
Add a case for returning RAM size as 2GB by reading
PMC scratch20 register.
BUG=chromium-os:23496
TEST=Build ok for Cardhu, Waluigi and Seaboard. Tested on Waluigi.
Change-Id: I5dc8fdf7cd9718e5dd2ca24cd1f467c5b6e9a6aa
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14696
|
|
Move pwfm.c and display.c under common folder tegra-common.
BUG=chromium-os:23496
TEST=Built ok for Cardhu, Waluigi and Seaboard. Tested on Waluigi.
Change-Id: I23c5f02270dde7bfdd6e1d26ed9984385986194e
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14694
|
|
Implement arch_phys_memset so that it can set memory at physical addresses
above 4GB using PAE paging. Because there are only 5 page tables in PAE mode,
1 PDPT and 4 PDTs, those tables are statically allocated in the BSS. The
tables must be 4K page aligned and are declared that way, and because U-Boot
starts as 4K aligned and the relocation code relocates it to a 4K aligned
address, the tables work as intended.
While paging is turned on, all 4GB are identity mapped except for one 2MB
page which is used as the window into high memory. This way, U-Boot will
continue to work as expected when running code that expects to access memory
freely, but the code can still get at high memory through its window.
The window is put at 2MB so that it's 2MB page aligned, low in memory to be
out of the way of things U-Boot is likely to care about, and above the lowest
1MB where lots of random things live.
BUG=chrome-os-partner:7579
TEST=From the original, larger patch:
Built and booted on Lumpy, Stumpy, and Kaen. Looked at the log to see
that the regions in high memory are listed as cleared. Artificially injected
a range to "clear" with 0xA5 and then 0x5A which was over the framebuffer and
covered part or all of the screen on Lumpy. Verified that the screen was
partially or completely filled with an appropriate looking color. Had U-Boot
print the PDTs it was generating to verify that the high address bits were
preserved. Identity mapped only some of memory and verified that things that
should be mapped were accessible and things that shouldn't be weren't.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: I1b3a038009de4312edba56ced1a91f9b0f6858b4
Reviewed-on: https://gerrit.chromium.org/gerrit/14418
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
When this code picked an area for U-Boot to relocate to, it was making sure
that there was enough space for U-Boot's various sections. It wasn't taking
into account the space needed for the heap and stack, however, so if it
happened to pick a very small region those areas might overlap with something
they shouldn't. This change fixes that.
Also, this change replaces the ROUND macro with the new rounddown introduced
in a previous change. It was assumed that ROUND rounded down, in contrast to
the other rounding function in common.h, roundup. It turns out that ROUND
rounds up even more agressively than roundup. If the value being rounded is
already exactly a multiple of the rounding amount, ROUND will still increase
it to the next multiple.
Because the region U-Boot had been choosing has plenty of space, there should
be no functional difference with this change.
BUG=chrome-os-partner:7579
TEST=Built and booted on Lumpy, Stumpy, and Kaen.
Change-Id: I39a45be6487ed0f60ea0900fb10632da5b312ebe
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14222
|
|
The use of post-increment with a do-while loop results in
the loop going one step too far when handling relocation fixups.
In about 1/100 cases this would cause it to hang.
BUG=chromium-os:25121
TEST=boot with serial enabled and extra debug to dump
the relocation addresses to ensure that it stops when
getting to the end of the rel.dyn section.
Change-Id: I4d3686d9c90ccfd0df0dd4d8a6483c534c93d3f2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/14290
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
Because calculate_relocation_address now uses the e820 map, it will be able
to avoid addresses over 32 bits and regions that are at high addresses but
not big enough for U-Boot. It also means we can remove the hack which
limitted U-Boot's idea of the size of memory to less than 4GB.
BUG=None
TEST=Built and booted on Lumpy. Built on Kaen.
Change-Id: I3ada4e5325ae3a0e652cf79486970e967aef6da6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14152
|
|
The way these are declared is different upstream, so these are being added in
a separate change to make rebasing easier.
BUG=None
TEST=Built and booted on Lumpy.
Change-Id: If84e0c36bd3615a561dec80eb71741c78db869b3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14211
|
|
Different systems may have different mechanisms for picking a suitable place
to relocate U-Boot to.
BUG=None
TEST=Built and booted on Lumpy. Built for Kaen.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: If3b9983865917307a4f546e8a1c35260a5dba7a4
Reviewed-on: https://gerrit.chromium.org/gerrit/14151
Commit-Ready: Gabe Black (Do Not Use) <gabeblack@google.com>
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
These types should be 64 bits long to reflect the fact that physical
addresses and the size of physical areas of memory are more than 32 bits
long.
BUG=None
TEST=Built and booted on Lumpy.
Change-Id: I58bc69051db027d6eb718ec1c92a3d4afa2b7561
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14150
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
When relocating symbols, U-Boot only relocates the ones that fall within the
range of address that are actually being moved. This change makes the upper
bound of that region closed (less than or equal to) instead of open (less
than) so that the __bss_end symbol is processed as well.
BUG=None
TEST=Built and booted on Lumpy. Built on Kaen.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: Ic1ee7402621dc266b3776ea5bdf3254ef51bc4ac
Reviewed-on: https://gerrit.chromium.org/gerrit/14148
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Gabe Black (Do Not Use) <gabeblack@google.com>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
U-boot is unable to actually use that memory and it can
cause problems with relocation if it tries to.
BUG=chrome-os-partner:6730
TEST=successfully boot on stumpy with a memory map
that ends up having 6MB remapped above 4GB.
Change-Id: I9ecde227bc0337145a7c0a6a929cfe0636fc2178
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/13923
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
This allows booting without a display, mostly as a way of calculating
the time that LCD init and maintenance costs us. Perhaps we might
integrate the lcd and video APIs within U-Boot - it would be a much
nicer solution. With that in mind I feel it is not work refactoring
this into three separate (lcd, video, none) files to implement the
display API.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: Iea4656f8939f7f2fd78292827091de4ee379954b
Reviewed-on: https://gerrit.chromium.org/gerrit/13369
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
While we wait for the new relocation stuff to come down from upstream,
this uses memset/memcpy() to do the business. Saves about 20ms on boot.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I958b9f53f27c67d4da2fa0f7a2148c59ed48f7aa
Reviewed-on: https://gerrit.chromium.org/gerrit/13215
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Delay serial console calls and do them later, to support the
CONFIG_DELAY_CONSOLE option.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: Ie15a887843a8b5f29fce055f7a2e17b7fc1e614f
Reviewed-on: https://gerrit.chromium.org/gerrit/13209
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
|
|
When DEBUG is enabled, display important clocks during init.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: Ic27e7d79bdcd9cf44d94ec25c52fc8776ddc7d04
Reviewed-on: https://gerrit.chromium.org/gerrit/13205
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Relocation takes about 40ms of the boot time, so add a timer to track it.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: If936bc8ff9a23f6dd885f60e845a597ac7edad97
Reviewed-on: https://gerrit.chromium.org/gerrit/13203
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
u-boot would load the environment from flash unconditionally
on x86. This is a security issue when booting ChromeOS in normal mode.
Add a function that looks at the device tree variable load_env to
determine whether to load it.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=boot tested on Stumpy
Change-Id: I7e4655e151b7421ec8ff9d0ce40b6de17bfede5d
Reviewed-on: https://gerrit.chromium.org/gerrit/12987
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
BUG=chromium-os:23496
TEST=built Seaboard and Waluigi OK
Signed-off-by: Tom Warren <twarren@nvidia.com>
Change-Id: I954cdb71eb80a3cf48f44b9a7183a2cafcb7755b
Reviewed-on: https://gerrit.chromium.org/gerrit/12442
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
|
|
Some clocks cannot be set to the final value until we have the fdt
and know what PLLP should be set to. For now the only example is
coresight - so this adds a call to update this clock once the A9
is up and running with the fdt.
BUG=chromium-os:23496
TEST=build and boot on Seaboard, T33, Kaen
Change-Id: I7a07306cfb0a24cec4dcdb08cac78659a1afc73f
Reviewed-on: https://gerrit.chromium.org/gerrit/12251
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This setting is now in the fdt, so remove the CONFIG item.
BUG=chromium-os:23496
TEST=build and boot on Seaboard, T33, Kaen
Change-Id: I336a6cc2140c725fdda85330efe617f82f205a90
Reviewed-on: https://gerrit.chromium.org/gerrit/12250
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
We want to use the fdt inside board_early_init_f(), so check for its
presence earlier in the pre-reloc init sequence.
BUG=chromium-os:23496
TEST=build and boot on Seaboard, T33, Kaen
Change-Id: I66fdaf976ddb419b754cc20374db4ffdcca16a09
Reviewed-on: https://gerrit.chromium.org/gerrit/12247
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
|
|
Since PLLP can be set to two different values, make it a parameter
to the function that sets up the PLLs.
BUG=chromium-os:23496
TEST=build and boot on Seaboard, T33, Kaen
Change-Id: I81ccc1cc3356796793ec2dd4ab22ed7fbd52f01d
Reviewed-on: https://gerrit.chromium.org/gerrit/12245
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This is using the latest patch recommendation from Dilan at Nvidia, we adjust
the ordering to clear bypass earlier and remove the delay.
This patch was run successfully for over 2000 reboots.
BUG=chrome-os-partner:6145
TEST=Manual
Signed-off-by: Bernie Thompson <bhthompson@chromium.org>
Change-Id: I9ef2f12d5c8abae86791f50b0f5e0e5a4249d947
Reviewed-on: https://gerrit.chromium.org/gerrit/12385
Reviewed-by: Micah Catlin <micahc@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
|
|
This function is better off in architecture code than board code.
This is quite an invasive change unfortunately.
BUG=chromium-os:23496
TEST=build and boot on Seaboard, T33, Kaen
Change-Id: I17764b134c25b684666d2c0fae2d255ac80e61b1
Reviewed-on: https://gerrit.chromium.org/gerrit/12244
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
|
|
intermittent hang
Currently with 200uS delay after PLL for stability.
BUG=chrome-os-partner:6145
TEST=None
Originaly-Reviewed-on: https://gerrit.chromium.org/gerrit/11091
Originaly-Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Originaly-Tested-by: Bernie Thompson <bhthompson@chromium.org>
Originaly-Commit-Ready: Katie Roberts-Hoffman <katierh@chromium.org>
Originaly-Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Change-Id: Idcb95d4698ea856785be8a8232c08c89309af887
Reviewed-on: https://gerrit.chromium.org/gerrit/12158
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
BUG=chromium-os:21033
TEST=built Seaboard & Waluigi OK. Booted my Waluigi to cmd prompt OK.
MMC, SPI and I2C still work fine, as does UART.
More can be done at a later date to cleanup AP20.c for T30 (and
rename/move it, since AP20 is a T2x name) and use new T30 V/W clock
enables/resets/sources/etc.
Change-Id: Ia3a86c519481fffde6926e1fece1dcf898d199c9
Reviewed-on: https://gerrit.chromium.org/gerrit/11911
Tested-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This change finishes plumbing the initrd support built into the zboot
mechanism out to the command interface.
It also fixes a bug in the command declaration where the kernel size could
be passed as an optional second parameter but not enough arguments were
allowed.
BUG=chrome-os-partner:6715
TEST=Built and booted on a Lumpy with the U-Boot command line exposed. Used
the Linux kernel in the system partition and the initramfs used for recovery
to boot the system. Observed that the recovery scripts in the initramfs ran.
The hardest part about implementing this change was testing because it took
many attempts to build/find an initrd/initramfs and command line that would
actually work. I'm confident the problems I had were from not knowing how to
set up or use an initramfs properly, not from the U-Boot support itself.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: Iccc5ff62e170e738dfb429a6b0ef9e27f0e7d8a9
Reviewed-on: https://gerrit.chromium.org/gerrit/12027
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
U-Boot Makefiles contain a number of tests for compiler features etc.
which so far are executed again and again. On some architectures
(especially ARM) this results in a large number of calls to gcc.
This patch makes sure to run such tests only once, thus largely
reducing the number of "execve" system calls.
Example: number of "execve" system calls for building the "P2020DS"
(Power Architecture) and "qong" (ARM) boards, measured as:
-> strace -f -e trace=execve -o /tmp/foo ./MAKEALL <board>
-> grep execve /tmp/foo | wc -l
Before: After: Reduction:
==================================
P2020DS 20555 15205 -26%
qong 31692 14490 -54%
As a result, built times are significantly reduced, typically by
30...50%.
Change-Id: I6e8c7c37cd13c56cb64d0a410514f2b9dc2d5adb
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Andy Fleming <afleming@gmail.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Albert Aribaud <albert.aribaud@free.fr>
cc: Graeme Russ <graeme.russ@gmail.com>
cc: Mike Frysinger <vapier@gentoo.org>
(cherry picked from commit 77d94d2d86c055f015734cc4cd972a5de30fc5a2)
Reviewed-on: https://gerrit.chromium.org/gerrit/11806
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
BUG=chromium-os:21033
TEST=Built and booted OK on my Waluigi. UART is OK, mmc, spi, i2c OK.
Note that this is only valid with CONFIG_SYS_PLLP_BASE_IS_408MHZ.
No affect on Tegra2. Seaboard builds fine, BTW.
Change-Id: I05a367afd1e78a2170d7308a658ce64017850ca0
Reviewed-on: https://gerrit.chromium.org/gerrit/11811
Tested-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
BUG=none
TEST=built Seaboard and Waluigi AOK
Change-Id: Ia860abf5ef3af66b3a39d4c57192455986b7a4f4
Reviewed-on: https://gerrit.chromium.org/gerrit/11704
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Warren <twarren@nvidia.com>
Commit-Ready: Doug Anderson <dianders@chromium.org>
|
|
BUG=chromium-os:21033
TEST=run `sf erase, write` and then `sf read` on seaboard
verify the data it reads from SPI flash matches that it writes to
Change-Id: I1b04afa4b54738cd93be29b70f428bdc3e6b234f
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/11472
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
BUG=chromium-os:21033
TEST=emerge-{tegra2_seaboard,waluigi} chromeos-u-boot
Change-Id: Icee2c26f36937e96c24318979179ba3a0cbfc09c
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11597
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
BUG=none
TEST=built Seaboard and Waluigi OK. Booted Waluigi OK.
Change-Id: I1bfbe03945d7dae44e0840349b9698fc08cef07d
Reviewed-on: https://gerrit.chromium.org/gerrit/11504
Tested-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
BUG=none
TEST=build Seaboard and Waluigi AOK
Change-Id: Id8e7227de7898bb9d117bf8d0f293ee5da7dc501
Reviewed-on: https://gerrit.chromium.org/gerrit/11506
Tested-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
|
|
Set CPU clock initially to 312Mhz; once CPU voltage is
raised, CPU clock will then be raied to 1.2GHz (for T25)
or 1.0GHz (for T20).
BUG=chrome-os-partner:5914
TEST=Build and test on Seaboard
Change-Id: I0c95a1df6b87c896daca8c03c9dc33b245764621
Reviewed-on: https://gerrit.chromium.org/gerrit/11199
Tested-by: Yen Lin <yelin@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
|
|
BUG=chromium-os:21033
TEST=build seaboard successfully
Change-Id: Idbfbdbf0bdb1070f4a2b5f8205c1caff6ef0c811
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11471
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This cleans up the rom caching optimization implemented in coreboot (and
needed throughout u-boot runtime.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:6585
TEST=boot coreboot on stumpy
Change-Id: I7242c9c2b0546c633be8fb8ebc815ed6e6fda4d1
Reviewed-on: https://gerrit.chromium.org/gerrit/11138
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
BUG=chromium-os:21540
TEST=Able to talk to MMC1 on Waluigi w/ future config changes.
Specifically:
1. mmcinfo 0 - works (shows info)
2. mmcinfo 1 - works (shows info)
3. mmc rescan 1; mmc part 1 - works (shows partitions)
Change-Id: I730d3b91088f20ccf7ca20f3f31f7d59514af243
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/10661
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
... rather than parsing the coreboot option table
BUG=none
TEST=boot tested on Stumpy
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I0814dd6c37cf826fda55a0f4acd6a1763b0626db
Reviewed-on: https://gerrit.chromium.org/gerrit/10758
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Previously the exported function definitions for pmu.c were split
among board.h, emc.c, and the architecture specific pmu.h. Create a
non-architecture-specific pmu.h and put them there.
NOTE: The arch/pmu.h file should probably be removed
eventually in favor of the device tree, since it really
just defines how a particular PMU is used by a particular
family of board.
BUG=chromium-os:21540
TEST=Compiled for seaboard
Change-Id: Ia026e3ff3f1f465be629cc8a348879d2d1564686
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10456
Reviewed-by: Tom Warren <twarren@nvidia.com>
|
|
These two functions were only used in pmu.c, so there was no
reason for them to be in the header file. They probably should
be moved elsewhere eventually, but this is a better location
than they were.
BUG=None
TEST=Compiled
Change-Id: Ia13cfd0fd828589862bfd555c3a34d3b6b4bda1c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10455
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
|
|
I ran four iterations with the two implementations and used Vadim's CBMEM
infrastructure to measure the time they took. These are all in microseconds,
and the timestamp portion of the raw output of cbmem.py is included in the bug.
The new implementation is about twice as fast as the old.
Old:
1. 418,286
2. 418,302
3. 418,298
4. 418,290
New:
1. 184,800
2. 194,629
3. 194,188
4. 192,718
BUG=chrome-os-partner:6487
TEST=Booted on Stumpy.
Change-Id: Iba398929cbba395e10851d676ae9d356ae670f41
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/10284
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
This adds support for T30 init to ap20.c, and modifies the board file
to cope with it also. The only thing missing at this point is the
pinmux setup.
BUG=chromium-os:21033
TEST=build and boot on Seaboard
Change-Id: I3e75245c1fdb99bc15eadcf60b173e6f0d9bb56c
Reviewed-on: http://gerrit.chromium.org/gerrit/8704
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This changes the layout in decreasing addresses from:
1. Stack
2. Sections in the image
3. Heap
to
1. Sections in the image
2. Heap
3. Stack
This allows the stack to grow significantly more since it isn't constrained by
the other u-boot areas. More importantly, the generic memory wipe code assumes
that the stack is the lowest addressed area used by the main part of u-boot.
In the original layout, that means that u-boot tramples all over itself. In
the new layout, it works.
BUG=chrome-os-partner:6194
BUG=chrome-os-partner:6195
TEST=Booted on Stumpy.
Change-Id: I0484ad37ba15f63cb0fb289118cad360817ad11f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/10006
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This way when that dram "banks" are displayed, there's some useful information
there. The number of "banks" we claim to have needs to be adjusted so that it
covers the number of RAM e820 regions we expect to have/care about.
This needs to be done after "RAM" initialization even though we always run
from RAM. The bd pointer in the global data structure doesn't automatically
point to anything, and it isn't set up until "RAM" is available since, I
assume, it would take too much space in the very constrained pre-RAM
environment.
BUG=None
TEST=Booted on Stumpy and saw reasonable contents in the "DRAM Configuration"
portion of the serial output.
Change-Id: Iced6c6717ba8464b972293c99505735df1a244c3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/10010
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
To maintain the initialization state of the timestamp facility, the
pointer to the CBMEM section containing the timestamp table should be
kept in the .data section (so that it is maintained across u-boot
relocation).
BUG=chromium-os:20733
TEST=manual
. build a new firmware image
. program it on a Stumpy configured for ssh communications
. reboot the stumpy
. examine the timestamp log
(host) ssh <target ip addr> /var/cbmem.py| grep -A1 'time base'
time base 2195144, total entries 4
1:77,700 2:767,214 1000:1,409,204 1100:2,274,851
observe the new timestamp entry added to the log.
Change-Id: I71edb31f1c0c7b3d24dcc9a611efc999615e09d2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10003
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
The GPIO definitions for Tegra2 were incorrectly matched up with Tegra2.
The layout is actually different, so GPIOs beyond port D do not work.
This separates out the GPIO headers again, so that Tegra2 and Tegra3 have
separate structure definitions.
BUG=None
TEST='vboot_test gpio' on Kaen; see that it responds to google rec, power, lid
correctly
Change-Id: I8540a87c8faa7179c8f0d44ef3f18b3c576392cc
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/9847
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Tested-by: Bryan Freed <bfreed@chromium.org>
|