u-boot.git/board/nvidia, branch v2020.04 Unnamed repository; edit this file 'description' to name the repository. ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support 2020-04-02T21:30:02+00:00 Tom Warren twarren@nvidia.com 2020-02-28T23:17:07+00:00 7c02bc9649f6d3afd272ac4a94b280495473834c The Jetson Nano Developer Kit is a Tegra X1-based development board. It is similar to Jetson TX1 but it is not pin compatible. It features 4GB of LPDDR4, a SPI NOR flash for early boot firmware and an SD card slot used for storage. HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB 2.0 and 1 USB 3.0) can be used to attach a variety of peripherals and a PCI Ethernet controller provides onboard network connectivity. NVMe support has also been added. Env save is at the end of QSPI (4MB-8K). A 40-pin header on the board can be used to extend the capabilities and exposed interfaces of the Jetson Nano. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> 
The Jetson Nano Developer Kit is a Tegra X1-based development board. It
is similar to Jetson TX1 but it is not pin compatible. It features 4GB
of LPDDR4, a SPI NOR flash for early boot firmware and an SD card slot
used for storage.

HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB 2.0
and 1 USB 3.0) can be used to attach a variety of peripherals and a PCI
Ethernet controller provides onboard network connectivity. NVMe support
has also been added. Env save is at the end of QSPI (4MB-8K).

A 40-pin header on the board can be used to extend the capabilities and
exposed interfaces of the Jetson Nano.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
t210: pinmux: Remove pinmux/GPIO init from T210 boards 2020-04-02T21:30:01+00:00 Tom Warren twarren@nvidia.com 2020-03-26T23:10:11+00:00 48ba1969c1deeb7599179d328be814362e4f63cc T210 CBoot is now doing the full pinmux and GPIO init, based on the DTB tables. Remove pinmux/GPIO init tables & code from all T210-based builds below: p2371-2180 aka TX1 p2371-0000 e2220-1170 p2571 Signed-off-by: Tom Warren <twarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> 
T210 CBoot is now doing the full pinmux and GPIO init, based on the DTB
tables. Remove pinmux/GPIO init tables & code from all T210-based builds
below:

p2371-2180 aka TX1
p2371-0000
e2220-1170
p2571

Signed-off-by: Tom Warren <twarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
env: Drop environment.h header file where not needed 2019-08-11T20:43:41+00:00 Simon Glass sjg@chromium.org 2019-08-01T15:47:12+00:00 e7dcf5645f09504573f534b0fc9abbbc6ff8a5ad This header file is now only used by files that access internal environment features. Drop it from various places where it is not needed. Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Simon Glass <sjg@chromium.org> 
This header file is now only used by files that access internal
environment features. Drop it from various places where it is not needed.

Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
env: Move env_get() to env.h 2019-08-11T20:43:41+00:00 Simon Glass sjg@chromium.org 2019-08-01T15:46:52+00:00 7b51b576d6db714e8668a98de67e93651e18123c Move env_get() over to the new header file. Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Simon Glass <sjg@chromium.org> 
Move env_get() over to the new header file.

Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
p2771-0000: Add support for framebuffer carveouts 2019-06-05T16:16:35+00:00 Thierry Reding treding@nvidia.com 2019-04-15T09:32:36+00:00 c79aa81dbc8a753ac8b00adbfb8c355933b89caa If early firmware initialized the display hardware and the display controllers are scanning out a framebuffer (e.g. a splash screen), make sure to pass information about the memory location of that framebuffer to the kernel before booting to avoid the kernel from using that memory for the buddy allocator. This same mechanism can also be used in the kernel to set up early SMMU mappings and avoid SMMU faults caused by the display controller reading from memory for which it has no mapping. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> 
If early firmware initialized the display hardware and the display
controllers are scanning out a framebuffer (e.g. a splash screen), make
sure to pass information about the memory location of that framebuffer
to the kernel before booting to avoid the kernel from using that memory
for the buddy allocator.

This same mechanism can also be used in the kernel to set up early SMMU
mappings and avoid SMMU faults caused by the display controller reading
from memory for which it has no mapping.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
p2371-2180: Add support for framebuffer carveouts 2019-06-05T16:16:35+00:00 Thierry Reding treding@nvidia.com 2019-04-15T09:32:35+00:00 595ea7381bc30839bf6f01ccdf1236020ad1958f If early firmware initialized the display hardware and the display controllers are scanning out a framebuffer (e.g. a splash screen), make sure to pass information about the memory location of that framebuffer to the kernel before booting to avoid the kernel from using that memory for the buddy allocator. This same mechanism can also be used in the kernel to set up early SMMU mappings and avoid SMMU faults caused by the display controller reading from memory for which it has no mapping. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> 
If early firmware initialized the display hardware and the display
controllers are scanning out a framebuffer (e.g. a splash screen), make
sure to pass information about the memory location of that framebuffer
to the kernel before booting to avoid the kernel from using that memory
for the buddy allocator.

This same mechanism can also be used in the kernel to set up early SMMU
mappings and avoid SMMU faults caused by the display controller reading
from memory for which it has no mapping.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
p2771-0000: Pass Ethernet MAC to the kernel 2019-06-05T16:16:35+00:00 Thierry Reding treding@nvidia.com 2019-04-15T09:32:34+00:00 8317189737a93753f634e0f14d984226b7a2da4c Pass the ethernet MAC address to the kernel upon boot. This passes both the local-mac-address property (as passed to U-Boot from cboot) and the currently set MAC address via the mac-address property. The latter will only be set if it is different from the address that was already passed via the local-mac-address property. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> 
Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
p2371-2180: Pass Ethernet MAC to the kernel 2019-06-05T16:16:35+00:00 Thierry Reding treding@nvidia.com 2019-04-15T09:32:33+00:00 a930a727423c6559ccf0b35c833669ad491a3db5 Pass the ethernet MAC address to the kernel upon boot. This passes both the local-mac-address property (as passed to U-Boot from cboot) and the currently set MAC address via the mac-address property. The latter will only be set if it is different from the address that was already passed via the local-mac-address property. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> 
Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: Unify Tegra186 builds 2019-06-05T16:16:34+00:00 Thierry Reding treding@nvidia.com 2019-04-15T09:32:28+00:00 a0dbc1314c3275c3af3591fc6f4762ff3367a4fd Tegra186 build are currently dealt with in very special ways, which is because Tegra186 is fundamentally different in many respects. It is no longer necessary to do many of the low-level programming because early boot firmware will already have taken care of it. Unfortunately, separating Tegra186 builds from the rest in this way makes it difficult to share code with prior generations of Tegra. With all of the low-level programming code behind Kconfig guards, the build for Tegra186 can again be unified. As a side-effect, and partial reason for this change, other Tegra SoC generations can now make use of the code that deals with taking over a boot from earlier bootloaders. This used to be nvtboot, but has been replaced by cboot nowadays. Rename the files and functions related to this to avoid confusion. The implemented protocols are unchanged. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> 
Tegra186 build are currently dealt with in very special ways, which is
because Tegra186 is fundamentally different in many respects. It is no
longer necessary to do many of the low-level programming because early
boot firmware will already have taken care of it.

Unfortunately, separating Tegra186 builds from the rest in this way
makes it difficult to share code with prior generations of Tegra. With
all of the low-level programming code behind Kconfig guards, the build
for Tegra186 can again be unified.

As a side-effect, and partial reason for this change, other Tegra SoC
generations can now make use of the code that deals with taking over a
boot from earlier bootloaders. This used to be nvtboot, but has been
replaced by cboot nowadays. Rename the files and functions related to
this to avoid confusion. The implemented protocols are unchanged.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
tegra: nyan: Add a README 2019-05-24T17:14:15+00:00 Simon Glass sjg@chromium.org 2019-04-01T20:38:42+00:00 593216f9cb16978e5178c15bd51b82327d6270f3 Add a short note about how to boot U-Boot on Nyan-big using tegrarcm. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com> 
Add a short note about how to boot U-Boot on Nyan-big using tegrarcm.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>