Age | Commit message (Collapse) | Author |
|
|
|
|
|
Add optional aka commented out 800x480@60 timing suitable for EDT
ET070080DH6.
|
|
Turns out our simplistic approach of just blindly enabling LAN_V_BUS
and releasing LAN_RESET_N does not prove very reliable.
Properly resetting the chip for 5 microseconds after VBUS is stable
just like we do on the Colibri T20 seems to fix the issue.
|
|
Include "colibri_" prefix in our board compatibility tables in
preparation to properly distinguish future e.g. Apalis modules.
While at it bring the device tree matching more in par with Linux
kernel 3.1.10 from NVIDIA's L4T R16-R2.
|
|
- board.c: changes required by different PMIC variant
|
|
|
|
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
|
|
Turns out we completely missed properly resetting the ASIX USB to FastEthernet chip which from time-to-time on certain modules caused severe Ethernet detection faults only a complete hardware reset or power-cycle could eliminate. Properly resetting the chip for 5 microseconds after VBUS is stable seems to fix the issue.
|
|
|
|
- kernel can now be up to 8MB
- cleanup, e.g. remove any NAND config
- unify with T20 file layout
|
|
If the USR partition we usually mount as root file system could not be
found which is e.g. the case for Android make sure mtdparts does not
start with a spurious coma separator the kernel would interpret as an
empty partition entry.
|
|
|
|
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>
|
|
|
|
As the kernel recently passed the 4 MB size limit simply copying 4 MB
won't quite cut it. Increase to 8 MB for now. In the future properly
parsing the SD card's partition table would be the way to go.
|
|
Fix build issues introduced with NVIDIA partition table parsing
integration.
|
|
|
|
If booting from SD card BCT contains information specific to SD card
partition layout which is bogus if used for NAND partition parsing.
Simply fall back to default offset just like in recovery BCT case.
Note: in the future we could parse SD partition table as well to more
generically support SD booting from various card densities.
|
|
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.
|
|
If booting from SD card BCT contains information specific to SD card
partition layout which is bogus if used for NAND partition parsing.
Simply fall back to default offset just like in recovery BCT case.
Note: in the future we could parse SD partition table as well to more
generically support SD booting from various card densities.
|
|
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.
|
|
Change SD boot bootdevice in environment variable sdargs from mmcblk3p1
to mmcblk0p1 due to later kernels using a different numbering scheme.
While at it clean-up some white space indentation stuff.
|
|
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.
|
|
User space tools like init just use last console kernel boot argument
as their one and only console. Re-order them in order to output boot
messages on serial debug console.
|
|
Examples: Properly append LDFLAGS to LD command
The LD command in examples/standalone/Makefile ignored platform specific
LDFLAGS setup. Pass these LDFLAGS to the command.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bryan Hundven <bryanhundven@gmail.com>
Cc: Michael Schwingen <rincewind@discworld.dascon.de>
|
|
Activate BL_ON backlight GPIO PT4 on SODIMM pin 71.
While at it add commented out XGA 1024x768 display timing values as well.
|
|
|
|
Change tegra2's entry address to its default address 0x108000.
BUG=none
TEST=flashed with local built u-boot. Kernel boots up fine.
Change-Id: I6ff4ed1f2901df73b21d033fbd191550108e96b5
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/22171
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
0x108000/0x80108000 is used as tegra2/tegra3's default boot loader entry
address. This change makes u-boot to comply with nvidia standard flash tools.
BUG=none
TEST=run cros_write_firmware with local build u-boot. Kernel boots up
fine.
Change-Id: I55e9b5d1847cf7e6a94d362935deef5f6855ba5a
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/21979
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
The cros_write_firmware has updated flash script command 'crc32' with -v
option. To support this change, u-boot needs to be built with
CONFIG_CRC32_VERIFY for seaboard.
BUG=none
TEST=run cros_write_firmware with local build u-boot.
Change-Id: I49046ce2424c4624a335af32051421e44bd388bb
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/21420
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mark Zhang <markz@nvidia.com>
Reviewed-by: Wei Ni <wni@nvidia.com>
|
|
This change allows to build a customized u-boot image, which includes
networking capabilities, provides diagnostic commands and supports
command line editing. These features are necessary to facilitate the
factory flow.
This image needs to be clearly distinguishable by ChromeOS. This is
achieved by modifying the value presented by the BINF.3 ACPI object.
To build this modified image one needs to add BUILD_FACTORY_IMAGE=1 to
the make invocation line.
BUG=chrome-os-partner:7952
TEST=manual
. build the new firmware image as follows:
USE='pcserial factory-mode' emerge-link chromeos-u-boot \
chromeos-coreboot chromeos-bootimage
. program the new image on the Link target with ChromeOS installed
on the SSD and restart it
. observe the target stop at u-boot command prompt (boot >)
. connect the target to an Ethernet network with a DHCP server
using a USB Ethernet dongle
. run the following commands at the u-boot prompt
boot > usb start
(Re)start USB...
USB: Register 203007 NbrPorts 7
USB EHCI 1.00
Register 20400b NbrPorts 11
USB EHCI 1.00
8 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
scanning bus for ethernet devices... 1 Ethernet Device(s) found
boot > dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
[a few warnings of unsupported DHCP options]
DHCP client bound to address 172.22.75.25
Using asx0 device
TFTP from server 172.16.255.7; our IP address is 172.22.75.25; sending through gateway 172.22.75.254
Filename 'pxelinux.0'.
Load address: 0x100000
Loading: ##
done
Bytes transferred = 15840 (3de0 hex)
boot >
. start ChromeOS on the target by issuing
vboot_twostop
. once ChromeOS boots check the mainfw_type crossystem reported value
localhost ~ # echo $(crossystem mainfw_type)
netboot
localhost ~ #
Change-Id: I1c50517754b6b5f773e432b9adec4b290f303e6f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/21071
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
- Fix bug in traversal of vendor name list.
- Sending "command ready" needs additional logic to handle
TPMs that need that bit set twice: once to empty the read
FIFOs and once to actualy set command ready.
- Certain TPMs need a small delay between requesting locality
and attempting to set command ready or they will hang the bus.
BUG=chrome-os-partner:8558
TEST=manual
Successful boot and suspend/resume with all TPMs listed
in the driver vendor/device list.
Change-Id: I22021b24f9498c3cafe0e1d5f1c6562ea0be5aad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/18480
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
The full range of LPC controllers should be accepted by u-boot when
looking for the SPI controller. The values come from Intel's
Panther_Point_EDS_v072.pdf (document #472178).
BUG=chrome-os-partner:7734
TEST=manual
. program the new image on the target
. reboot it and observe coming up to ChromeOS login screen
Change-Id: Id8f7068c3b48885f868a1f30e7927e678d2154b6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19147
Reviewed-by: Jon Salz <jsalz@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19310
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
Link's MRC produces significantly more training data than
the one used on Stumpy/Lumpy.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BUG=none
TEST=boot tested on Link
Change-Id: I9310c3bcc77fb4318db0635b97b115ab0eb7e5ec
Reviewed-on: https://gerrit.chromium.org/gerrit/18748
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Cardhu boards can use Atmel and Winbond SPI flash
parts - support both in one binary.
BUG=chromium-os:23496
TEST=build all OK, test on Cardhu.
'sf probe 0' returns:
SF: Detected AT25DF321A with page size 256, total 4 MiB.
sf read/write/erase all work OK.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Change-Id: I7df3abb030a49b572e1172ca77227cd4d63e0c21
Reviewed-on: https://gerrit.chromium.org/gerrit/18539
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
BUG=none
TEST=check fmap on generated binary for unique names
Change-Id: Id1ac5cf223ec6a333fc8f4c587e972afd087f90d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/18435
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This saves 500ms in the RW BIOS path and still leaves 130K
overhead from the current U-boot size (372K) which should be
more than enough for any future updates on stumpy/lumpy.
This should be re-visited if/when vboot is smart enough to
just read+validate the actual binary within the section.
BUG=chrome-os-partner:8518
TEST=boot lumpy/stumpy through RW BIOS path and gather
timestamps to see 500ms improvement.
Change-Id: Ia714b4b95245f02f6e781247f820ca915bb403f5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/18372
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
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>
|
|
For some still unknown reason writes to localtion 0xcf9 do not cause
the Link to reboot, they cause it to shut down instead. While this
will have to be investigated and fixed, this change modifies the code
to use the keyboard controller (implemented by the EC on Link) to
restart the system.
Once the 0xcf9 problem is resolved, this change could be reverted.
BUG=chrome-os-partner:8397
TEST=manual
. when u-boot tires restarting the system it now reboots. before
this change it would just shut down.
Change-Id: I8076f897304f705e20ec8f2e30cce17d7fdd31c4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/18332
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
The code in this file tries to print an LBA using the format specifier
"%10ld", but when CONFIG_SYS_64BIT_LBA is turned on, the argument passed in
this position is a 64 bit value and isn't compatible. This change selects the
appropriate format specifier, the original or "10lld", based on whether
CONFIG_SYS_64BIT_LBA is turned on.
BUG=chrome-os-partner:8180
TEST=Built for Stumpy with BUILD_PART_FS_STUFF turned on and
CONFIG_SYS_64BIT_LBA enabled and disable, and saw the compile errors go away.
Change-Id: Ib80b1567ce07673aea2b47dfba9b3526b32f9de5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/18219
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
BUG=chromium-os:23496
TEST=build on Waluigi, Seaboard, Cardhu
Change-Id: I9ccd3085fb551e9887815592e9b518b6944beda7
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/14474
Reviewed-by: Simon Glass <sjg@chromium.org>
|