Age | Commit message (Collapse) | Author |
|
In preparation for the new Apalis T30 SKUs implement memory size auto
detection based on reading the aperture register set by boot ROM from
BCT and a simple mirroring detection.
Tested on initial samples of Apalis T30 1GB V1.0A,
Apalis T30 2GB V1.0B, Apalis T30 2GB V1.0C and Colibri T30 V1.1C.
|
|
Due to a unoptimised PLL X table we were only running at 400MHz during
boot.
Incorporated the PLL X table from NVIDIA's latest public U-Boot sources:
http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/u-boot.git;a=blob;f=arch/arm/cpu/arm720t/tegra-common/cpu.c;h=119342e9577f6b42f93d118b81c0e931c9c9423a;hb=chromeos/v2013.01.01-tegra114#l67
And actually set up the T30 PLLs regardless of slow flag as this is
anyway exclusively used on T20.
Issue report courtesy of Mariusz Bulkowski from Draminski.
|
|
Add initial Apalis T30 support based off our current Colibri T30
implementation:
- Updated machine ID.
- USB host USBH2 and USBH3 support. Note: USBO1 support is currently broken.
- Updated MMC and SD card support.
- Adjusted available amount of memory.
|
|
NVIDIA's MMC/SD layout includes a partition table that can be used to
generically determine U-Boot environment, kernel, configuration block
as well as GPT offsets. As an added benefit this is completely
independent of the underlying MMC/SD card used which might differ with
various future module versions or particularly cards used for T20 SD
boot. Also handles the case of T20 SD boot where the configuration
block is still taken from NAND flash while the rest resides on the SD
card.
Initial partition table parsing courtesy of Mitja Špes from LXNAV.
|
|
After having registered the following proper machine type migrate to
actually using it.
http://www.arm.linux.org.uk/developer/machines/list.php?id=4493
While at it clean-out some obsolete Cardhu specific device-tree
nodes resp. properties and clean-up the mach-types header file as well.
|
|
|
|
CLK_RST_CONTROLLER_RST_CPU_CMPLX_SET/CLR_0
|
|
description in Android code. no bug visible as function is not called with run = 1
|
|
here this use did not show any adverse effects
|
|
Conflicts:
arch/arm/cpu/armv7/tegra3/warmboot_avp.c
arch/arm/include/asm/arch-tegra/clk_rst.h
|
|
tegra: add enterrcm command
Tegra's boot ROM supports a mode whereby code may be downloaded and flash
programmed over a USB connection. On dev boards, this is typically entered
by holding down a "force recovery" button and resetting the CPU. However,
not all boards have such a button (one example is the Compulab Trimslice),
so a method to enter RCM from software is useful.
This change implements the command "enterrcm" to do this, and enables it
for all Tegra boards by default. Even on boards other than Trimslice,
controlling this over a UART may be useful, e.g. to allow simple remote
control without the need for mechanical button actuators, or hooking up
relays/... to the button.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Rather than relying on hard-coded offsets actually make use of
partition table parsing implementation.
|
|
NVIDIA's NAND layout includes a partition table that can be used to
generically construct the mtdparts kernel boot argument. As an added
benefit this is completely independent of the underlying NAND part
used which differs with various module versions. It further allows our
customer easy adoption to their own custom partition layout.
Initial partition table parsing courtesy of Mitja Špes from LXNAV.
|
|
Colibri T20 does not use OdmData but rather relies on memory controller
configuration done by boot ROM based on BCT information. Unfortunately
it is possible to at least boot a 256 MB module with a 512 MB BCT
therefore double check whether we really do have that.
|
|
Add comment concerning PMIC initialisation of VDD_CPU via VDDCtrl.
|
|
|
|
At bootup time device enters in standby state as
CLK_RST_CONTROLLER_SCLK_BURST_POLICY is not set correctly.
This change correctly sets clock burst policy.
BUG = None
TEST= Build OK for Seaboard,Cardhu and Waluigi.
Tested on Cardhu and waluigi. Device boots up.
Change-Id: I598ca7bcfc4a39ecaa68c211d3439ac3569c6e44
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/24164
Reviewed-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Tested-by: Tom Warren <twarren@nvidia.com>
Commit-Ready: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
When U-boot is loaded via verified boot it starts at the
_x86boot_start entry point and promptly disables caching,
resulting in about a 500ms hit to boot time.
BUG=chrome-os-partner:8518
TEST=boot on lumpy with RW BIOS and gather timestamps
to observe 500ms less time spent in u-boot init.
Change-Id: I4eb1ad5ebcb20a156fef77452030e47a5e510115
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/18371
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
BUG=chromium-os:23496
TEST=build and boot on Waluigi, Cardhu by enabling
CONFIG_TEGRA_LP0 and CONFIG_TEGRA3_WARMBOOT.
odification of the work done by:
a. Jimmy Zhang <jimmzhang@nvidia.com>
b. Yen Lin <yelin@nvidia.com>
c. Wei Ni <wni@nvidia.com>
Change-Id: If2fa63ccd23341694955bca25fb5cfc4a8a805ad
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/13800
|
|
warmboot_avp.h needs to be present in include/arch-tegra
in order to use it for Tegra3.
BUG=chromium-os:23496
TEST=build for Seaboard
Change-Id: I3f369194e4002e8257c9d2ff37253bc20733138d
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/15394
|
|
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: I6d26502d1ecc393b266ffe06b540f59c595e19ae
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14811
|
|
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: Ifa06f941798ff242197dcd31f4091567d91fe4b2
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14810
|
|
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: I74bb2418ab996e362060351de3ba7efd538ffd87
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14809
|
|
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: I20ac75c71d86d65ff422ff3f4f966a69718f4f91
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14808
|
|
These registers would be useful for the warmboot code.
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: I58f52b6b8653d72b2e842ee44bdf3632eff304a2
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14690
|
|
Would be useful for the warmboot code.
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: I271f6cdcc0248337e516c2c32014c6ec4f08fb15
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14689
|
|
These registers would be useful for the warmboot
code.
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: I8da1ed3a382e1b65247236cb19f527f81d8ecaac
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14688
|
|
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi
Change-Id: Iacd6fdb178afbfdb978dbe53bbe2766916bf26f9
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14685
|
|
BUG=chromium-os:23496
TEST=build for Cardhu, Waluigi and Seaboard
Change-Id: I32dbfa02ac1d6954b3a7e515914fbc0b6695f98b
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14683
|
|
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: Ie04bf9ac17482a37afd0f4515dc3aafeb4f48ae7
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/15883
|
|
This reverts commit 4c7502242627f64d91432cb4958be5f93f65fbff
Don't think this is the cause of http://code.google.com/p/chromium-os/issues/detail?id=26116, but it was in the same batch so I'm reverting in the process.
Change-Id: Icc013ced6c22e29d569ee4ca8ef73522154ec1a8
Reviewed-on: https://gerrit.chromium.org/gerrit/15561
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
|
|
This reverts commit 9a3fbb5f0b02382c7abe0cf40a4f08abbf269d05
Broke tegra2: http://code.google.com/p/chromium-os/issues/detail?id=26116
Change-Id: I7d35211c6ebce7a10750cb1033c6f8ba9a0f63bc
Reviewed-on: https://gerrit.chromium.org/gerrit/15560
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
|
|
move away from the current method, where we add wb_end() immediately
after wb_start() and then use the function addresses to calculate the
WB code size. Add a .lds script to expose __wb_end after wb_start() in
the .text section and then reference this variable in the WB size
calculation code.
BUG=chromium-os:23496
TEST=build on Seaboard. Verified that uboot.map has the correct address
assigned to __wb_end and that LP0 works reliably.
Change-Id: I170277f00b450d38063018453faf44d5a38abaaa
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14682
|
|
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>
|