- Jan 03, 2024
-
-
Svyatoslav Ryhel authored
Signed-off-by:
Svyatoslav Ryhel <clamor95@gmail.com>
-
- Dec 19, 2023
-
-
Svyatoslav Ryhel authored
Move all existing pinmux and funcmux code into a dedicated folder in pinctrl to simplify further maintenance. Signed-off-by:
Svyatoslav Ryhel <clamor95@gmail.com>
-
- Dec 05, 2022
-
-
Tom Rini authored
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NS16550 namespace do not easily transition to Kconfig. In many cases they likely should come from the device tree instead. Move these out of CONFIG namespace and in to CFG namespace. Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
- May 24, 2021
-
-
This commit does the same thing as Linux commit 33def8498fdd. Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Signed-off-by:
Marek Behún <marek.behun@nic.cz> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
- Feb 02, 2021
-
-
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Tom Rini <trini@konsulko.com>
-
- Jan 05, 2021
-
-
Simon Glass authored
The current macro is a misnomer since it does not declare a device directly. Instead, it declares driver_info record which U-Boot uses at runtime to create a device. The distinction seems somewhat minor most of the time, but is becomes quite confusing when we actually want to declare a device, with of-platdata. We are left trying to distinguish between a device which isn't actually device, and a device that is (perhaps an 'instance'?) It seems better to rename this macro to describe what it actually is. The macros is not widely used, since boards should use devicetree to declare devices. Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is declaring a new driver_info record, not a device. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Dec 13, 2020
-
-
Simon Glass authored
Try to maintain some consistency between these variables by using _plat as a suffix for them. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- May 19, 2020
-
-
Move this header out of the common header. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- May 18, 2020
-
-
Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Jan 24, 2020
-
-
These functions relate to memory init so move them into the init header. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Jan 17, 2020
-
-
These functions relate to memory init so move them into the init header. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Dec 02, 2019
-
-
These functions belong in cpu_func.h. Another option would be cache.h but that code uses driver model and we have not moved these cache functions to use driver model. Since they are CPU-related it seems reasonable to put them here. Move them over. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
- Jun 05, 2019
-
-
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>
-
The save_boot_params() function takes as its first four arguments the first four registers. On 32-bit ARM these are r0, r1, r2 and r3, all of which are 32 bits wide. However, on 64-bit ARM thene registers are x0, x1, x2 and x3, all of which are 64 bits wide. In order to allow reusing the save_boot_params() implementation on 64-bit ARM, change it to take unsigned long parameters rather than the fixed size 32-bit integers. This ensures that the correct values are passed. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
Pin controller code is not relevant on all Tegra SoC generations, so guard it with a Kconfig symbol that can be selected by the generations that need it. This is in preparation for unifying Tegra186 code with the code used on older generations. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
Memory controller code is not relevant on all Tegra SoC generations, so guard it with a Kconfig symbol that can be selected by the generations that need it. This is in preparation for unifying Tegra186 code with the code used on older generations. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
Clock code is not relevant on all Tegra SoC generations, so guard it with a Kconfig symbol that can be selected by the generations that need it. This is in preparation for unifying Tegra186 code with the code used on older generations. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- May 18, 2019
-
-
While converting CONFIG_SYS_[DI]CACHE_OFF to Kconfig, there are instances where these configuration items are conditional on SPL. This commit adds SPL variants of these configuration items, uses CONFIG_IS_ENABLED(), and updates the configurations as required. Acked-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Trevor Woerner <trevor@toganlabs.com> [trini: Make the default depend on the setting for full U-Boot, update more zynq hardware] Signed-off-by:
Tom Rini <trini@konsulko.com>
-
- May 07, 2018
-
-
Tom Rini authored
When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
- Jan 20, 2017
-
-
commit: 65f83802 "serial: 16550: Add getfcr accessor" breaks u-boot commandline working with long commands sending to the board. Since the above patch, you have to setup the fcr register. For board/archs which enable OF_PLATDATA, the new field fcr in struct ns16550_platdata is not filled with a default value ... This leads in not setting up the uarts fifo, which ends in problems, when you send long commands to u-boots commandline. Detected this issue with automated tbot tests on am335x based shc board. The error does not popup, if you type commands. You need to copy&paste a long command to u-boots commandshell (or send a long command with tbot) Possible boards/plattforms with problems: ./arch/arm/cpu/arm926ejs/lpc32xx/devices.c ./arch/arm/mach-tegra/board.c ./board/overo/overo.c ./board/quipos/cairo/cairo.c ./board/logicpd/omap3som/omap3logic.c ./board/logicpd/zoom1/zoom1.c ./board/timll/devkit8000/devkit8000.c ./board/lg/sniper/sniper.c ./board/ti/beagle/beagle.c ./drivers/serial/serial_rockchip.c Signed-off-by:
Heiko Schocher <hs@denx.de> Signed-off-by:
Ladislav Michl <ladis@linux-mips.org> Tested-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
- Dec 05, 2015
-
-
At present an incorrect #if term is preventing this data from being compiled in. All tegra boards use driver model for serial, so we can just drop this. Fixes: fde7e189 ("dm: tegra: pci: Move CONFIG_PCI_TEGRA to Kconfig") Signed-off-by:
Simon Glass <sjg@chromium.org> Reported-by:
Stephen Warren <swarren@nvidia.com> Acked-by:
Thomas Chou <thomas@wytron.com.tw>
-
- Nov 22, 2015
-
-
Unify serial_tegra, and use the generic binding. Signed-off-by:
Thomas Chou <thomas@wytron.com.tw> Reviewed-by:
Tom Rini <trini@konsulko.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Aug 13, 2015
-
-
The return value of query_sdram_size() is assigned directly to gd->ram_size in dram_init(). Adjust the return type to match the field it's assigned to. This has the beneficial effect that on 64-bit systems, the return value can correctly represent large RAM sizes over 4GB. For similar reasons, change the type of variable size_bytes in the same way. query_sdram_size() would previously clip the detected RAM size to at most just under 4GB in all cases, since on 32-bit systems, larger values could not be represented. Disable this feature on 64-bit systems since the representation restriction does not exist. On 64-bit systems, never call get_ram_size() to validate the detected/ calculated RAM size. On any system with a secure OS/... carve-out, RAM may not have a single contiguous usable area, and this can confuse get_ram_size(). Ideally, we'd make this call conditional upon some other flag that indicates specifically that a carve-out is actually in use. At present, building for a 64-bit system is the best indication we have of this fact. In fact, the call to get_ram_size() is not useful by the time U-Boot runs on any system, since U-Boot (and potentially much other early boot software) always runs from RAM on Tegra, so any mistakes in memory controller register programming will already have manifested themselves and prevented U-Boot from running to this point. In the future, we may simply delete the call to get_ram_size() in all cases. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Jul 28, 2015
-
-
Tom Warren authored
Derived from Tegra124, modified as appropriate during T210 board bringup. Cleaned up debug statements to conserve string space, too. This also adds misc 64-bit changes from Thierry Reding/Stephen Warren. Signed-off-by:
Tom Warren <twarren@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Stephen Warren <swarren@nvidia.com>
-
Tom Warren authored
Simon's 'tegra124: Implement spl_was_boot_source()' needs a prototype for save_boot_params_ret() to build cleanly for 64-bit Tegra210. Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
On 64-bit SoCs the I-cache isn't enabled in early code, so the default cache enable functions for 64-bit ARM can be used. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com> Signed-off-by:
Stephen Warren <swarren@nvidia.com>
-
- Jul 27, 2015
-
-
Add an implementation of this function for Tegra. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- May 13, 2015
-
-
This is only used by Nvidia boards, so move it into nvidia/common to simplify things. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Mar 04, 2015
-
-
When the CPU is in non-secure (NS) mode (when running U-Boot under a secure monitor), certain actions cannot be taken, since they would need to write to secure-only registers. One example is configuring the ARM architectural timer's CNTFRQ register. We could support this in one of two ways: 1) Compile twice, once for secure mode (in which case anything goes) and once for non-secure mode (in which case certain actions are disabled). This complicates things, since everyone needs to keep track of different U-Boot binaries for different situations. 2) Detect NS mode at run-time, and optionally skip any impossible actions. This has the advantage of a single U-Boot binary working in all cases. (2) is not possible on ARM in general, since there's no architectural way to detect secure-vs-non-secure. However, there is a Tegra-specific way to detect this. This patches uses that feature to detect secure vs. NS mode on Tegra, and uses that to: * Skip the ARM arch timer initialization. * Set/clear an environment variable so that boot scripts can take different action depending on which mode the CPU is in. This might be something like: if CPU is secure: load secure monitor code into RAM. boot secure monitor. secure monitor will restart (a new copy of) U-Boot in NS mode. else: execute normal boot process Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
Some systems have so much RAM that the end of RAM is beyond 4GB. An example would be a Tegra124 system (where RAM starts at 2GB physical) that has more than 2GB of RAM. In this case, we want gd->ram_size to represent the actual RAM size, so that the actual RAM size is passed to the OS. This is useful if the OS implements LPAE, and can actually use the "extra" RAM. However, we can't use get_ram_size() to verify the actual amount of RAM present on such systems, since some of the RAM can't be accesses, which confuses that function. Avoid calling get_ram_size() when the RAM size is too large for it to work correctly. It's never actually needed anyway, since there's no reason for the BCT to report the wrong RAM size. In systems with >=4GB RAM, we still need to clip the reported RAM size since U-Boot uses a 32-bit variable to represent the RAM size in bytes. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
size_mb is used to hold a value that's sometimes KB, sometimes MB, and sometimes bytes. Use separate correctly named variables to avoid confusion here. Also fix indentation of a conditional statement. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Feb 21, 2015
-
-
This commit moves files as follows: arch/arm/cpu/arm720t/tegra20/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/arm720t/tegra30/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/arm720t/tegra114/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/arm720t/tegra124* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/arm720t/tegra-common/* -> arch/arm/mach-tegra/* arch/arm/cpu/armv7/tegra20/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/armv7/tegra30/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/armv7/tegra114/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/armv7/tegra124/* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/armv7/tegra-common/* -> arch/arm/mach-tegra/* arch/arm/cpu/tegra20-common/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/tegra30-common/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/tegra114-common/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/tegra124-common/* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/tegra-common/* -> arch/arm/mach-tegra/* Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Simon Glass <sjg@chromium.org> [ on nyan-big ] Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com>
-
- Oct 22, 2014
-
-
On popular request this now completes the Warren's work started for TK1: aeb3fcb3 ARM: tegra: Use mem size from MC rather than ODMDATA In addition to the move of using the Tegra memory controller (MC) register rather than ODMDATA for T20, T30 and T114 as well it further uses the generic get_ram_size() function (see "common/memsize.c") <supposed to be used in each and every U-Boot port>TM. Added benefit is that it should <catch 99% of hardware related (i. e. reliably reproducible) memory errors> as well. Thoroughly tested on the various Toradex line of Tegra modules available which unfortunately does not include T114 and T124 (yet at least) plus on the Jetson TK1. Based-on-work-by:
Stephen Warren <swarren@nvidia.com> Based-on-work-by:
Tom Warren <twarren@nvidia.com> Signed-off-by:
Marcel Ziswiler <marcel@ziswiler.com> Acked-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Aug 18, 2014
-
-
In at least Tegra124, the Tegra memory controller (MC) has a register that controls the memory size. Read this to determine the memory size rather than requiring this to be redundantly encoded into the ODMDATA. This way, changes to the BCT (i.e. MC configuration) automatically updated SW's view of the memory size, without requiring manual changes to the ODMDATA. Future work potentially required: * Clip the memory size to architectural limits; U-Boot probably doesn't and won't support either LPAE or Tegra's "swiss cheese" memory layout, at least one of which would be required for >2GB RAM. * Subtract out any carveout required by firmware on future SoCs. Based-on-work-by:
Tom Warren <twarren@nvidia.com> Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Feb 03, 2014
-
-
These files are used by both SPL and main U-Boot. Signed-off-by:
Tom Warren <twarren@nvidia.com> Signed-off-by:
Stephen Warren <swarren@nvidia.com> Tested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Jul 24, 2013
-
-
Wolfgang Denk authored
Signed-off-by:
Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by:
Tom Rini <trini@ti.com>
-
- Feb 11, 2013
-
-
These files are used by both SPL and main U-Boot. Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
FUNCMUX_ defines should be named after the pin groups they affect, not after the module they're muxing onto those pin groups. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Acked-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Jan 16, 2013
-
-
IRDA is a synonym for UARTB in tegra pinmux, remove all usage of this synonym and replace with UARTB to disambiguate. Signed-off-by:
Allen Martin <amartin@nvidia.com> Reviewed-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
These files are used by both SPL and main U-Boot. Also made minor changes to shared Tegra code to support T30 differences. Signed-off-by:
Tom Warren <twarren@nvidia.com> Reviewed-by:
Stephen Warren <swarren@nvidia.com>
-