11 Feb, 2018
1 commit
-
On the NIOS2 and Xtensa architectures, we do not have
CONFIG_SYS_TEXT_BASE set. This is a strict migration of the current
values into the defconfig and removing them from the headers.I did not attempt to add more default values in and for now will leave
that to maintainers.Signed-off-by: Tom Rini
29 Jul, 2017
1 commit
-
Now that EHCD does not use CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS,
remove it in all boards' config files.Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese
27 Aug, 2016
1 commit
-
This series moves the CONFIG_SYS_CACHELINE_SIZE. First, in nearly all
cases we are mirroring the values used by the Linux Kernel here. Also,
so long as (and in this case, it is true) we implement flushes in hunks
that are no larger than the smallest implementation (and given that we
mirror the Linux Kernel, again we are fine) it is OK to align higher.
The biggest changes here are that we always use 64 bytes for CPU_V7 even
if for example the underlying core is only 32 bytes (this mirrors
Linux). Second, we say ARM64 uses 64 bytes not 128 (as found in the
Linux Kernel) as we do not need multi-platform support (to this degree)
and only the Cavium ThunderX 88xx series has a use for such large
alignment.Cc: Albert Aribaud
Cc: Marek Vasut
Cc: Stefano Babic
Cc: Prafulla Wadaskar
Cc: Luka Perkov
Cc: Stefan Roese
Cc: Nagendra T S
Cc: Vaibhav Hiremath
Acked-by: Lokesh Vutla
Cc: Steve Rae
Cc: Igor Grinberg
Cc: Nikita Kiryanov
Cc: Stefan Agner
Acked-by: Heiko Schocher
Cc: Mateusz Kulikowski
Cc: Peter Griffin
Acked-by: Paul Kocialkowski
Cc: Anatolij Gustschin
Acked-by: "Pali Rohár"
Cc: Adam Ford
Cc: Steve Sakoman
Cc: Grazvydas Ignotas
Cc: Nishanth Menon
Cc: Stephen Warren
Cc: Robert Baldyga
Cc: Minkyu Kang
Cc: Thomas Weber
Cc: Masahiro Yamada
Cc: David Feng
Cc: Alison Wang
Cc: Michal Simek
Cc: Simon Glass
Cc: York Sun
Cc: Shengzhou Liu
Cc: Mingkai Hu
Cc: Prabhakar Kushwaha
Cc: Aneesh Bansal
Cc: Saksham Jain
Cc: Qianyu Gong
Cc: Wang Dongsheng
Cc: Alex Porosanu
Cc: Hongbo Zhang
Cc: tang yuantian
Cc: Rajesh Bhagat
Cc: Josh Wu
Cc: Bo Shen
Cc: Viresh Kumar
Cc: Hannes Schmelzer
Cc: Thomas Chou
Cc: Joe Hershberger
Cc: Sam Protsenko
Cc: Bin Meng
Cc: Christophe Ricard
Cc: Anand Moon
Cc: Beniamino Galvani
Cc: Carlo Caione
Cc: huang lin
Cc: Sjoerd Simons
Cc: Xu Ziyuan
Cc: "jk.kernel@gmail.com"
Cc: "Ariel D'Alessandro"
Cc: Kever Yang
Cc: Samuel Egli
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Hans de Goede
Cc: Ian Campbell
Cc: Siarhei Siamashka
Cc: Boris Brezillon
Cc: Andre Przywara
Cc: Bernhard Nortmann
Cc: Wolfgang Denk
Cc: Ben Whitten
Cc: Tom Warren
Cc: Alexander Graf
Cc: Sekhar Nori
Cc: Vitaly Andrianov
Cc: "Andrew F. Davis"
Cc: Murali Karicheri
Cc: Carlos Hernandez
Cc: Ladislav Michl
Cc: Ash Charles
Cc: Mugunthan V N
Cc: Daniel Allred
Cc: Gong Qianyu
Signed-off-by: Tom Rini
Acked-by: Masahiro Yamada
Acked-by: Chin Liang See
Tested-by: Stephen Warren
Acked-by: Paul Kocialkowski
07 Aug, 2015
1 commit
-
U-boot is responsible for enabling the GPU DT node after all necessary
configuration (VPR setup for T124) is performed. In order to be able to
check whether this configuration has been performed right before booting
the kernel, make it happen during board_init().Also move VPR configuration into the more generic gpu.c file, which will
also host other GPU-related functions, and let boards specify
individually whether they need VPR setup or not.Signed-off-by: Alexandre Courbot
Cc: Stephen Warren
Cc: Tom Warren
Signed-off-by: Tom Warren
28 Jul, 2015
1 commit
-
We are getting very close to running out of space in SPL, and with the
currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space.Signed-off-by: Simon Glass
Signed-off-by: Tom Warren
14 May, 2015
1 commit
-
As best I can tell, CONFIG_SYS_LOAD_ADDR and CONFIG_LOADADDR/$loadaddr
serve essentially the same purpose. Roughly, if a command takes a load
address, then CONFIG_SYS_LOAD_ADDR or $loadaddr (or both) are the default
if the command-line does not specify the address. Different U-Boot
commands are inconsistent re: which of the two default values they use.
As such, set the two to the same value, and move the logic that does this
into tegra-common-post.h so it's not duplicated. A number of other non-
Tegra boards do this too.The values chosen for these macros are no longer consistent with anything
in MEM_LAYOUT_ENV_SETTINGS. Regain consistency by setting $kernel_addr_r
to CONFIG_LOADADDR. Older scripts tend to use $loadaddr for the default
kernel load address, whereas newer scripts and features tend to use
$kernel_addr_r, along with other variables for other purposes such as
DTBs and initrds. Hence, it's logical they should share the same value.I had originally thought to make the $kernel_addr_r and CONFIG_LOADADDR
have different values. This would guarantee no interference if a script
used the two variables for different purposes. However, that scenario is
unlikely given the semantic meaning associated with the two variables.
The lowest available value is 0x90200000; see comments for
MEM_LAYOUT_ENV_SETTINGS in tegra30-common-post.h for details. However,
that value would be problematic for a script that loaded a raw zImage to
$loadaddr, since it's more than 128MB beyond the start of SDRAM, which
would interfere with the kernel's CONFIG_AUTO_ZRELADDR. So, let's not do
that.The only potential fallout I could foresee from this patch is if someone
has a script that loads the kernel to $loadaddr, but some other file
(DTB, initrd) to a hard-coded address that the new value of $loadaddr
interferes with. This seems unlikely. A user should not do that; they
should either hard-code all load addresses, or use U-Boot-supplied
variables for all load addresses. Equally, any fallout due to this change
is trivial to fix; simply modify the load addresses in that script.Cc: Paul Walmsley
Signed-off-by: Stephen Warren
Reviewed-by: Paul Walmsley
Reviewed-by: Simon Glass
Signed-off-by: Tom Warren
12 Dec, 2014
1 commit
-
This converts all Tegra boards over to use driver model for I2C. The driver
is adjusted to use driver model and the following obsolete CONFIGs are
removed:- CONFIG_SYS_I2C_INIT_BOARD
- CONFIG_I2C_MULTI_BUS
- CONFIG_SYS_MAX_I2C_BUS
- CONFIG_SYS_I2C_SPEED
- CONFIG_SYS_I2CThis has been tested on:
- trimslice (no I2C)
- beaver
- Jetson-TK1It has not been tested on Tegra 114 as I don't have that board.
Acked-by: Heiko Schocher
Signed-off-by: Simon Glass
06 Mar, 2014
2 commits
-
Tegra's EHCI controllers only have a single PORTSC register. Configure
U-Boot to know this. This prevents e.g. ehci_shutdown() from touching
non-existent registers.Signed-off-by: Stephen Warren
Signed-off-by: Tom Warren -
needs to use CONFIG_TEGRA* to conditionalize
some definitions, since some modules moved between generations. Move
the definition of CONFIG_TEGRAnn to a header that's included earlier,
so that it's set by the time tegra.h needs to use it.Signed-off-by: Stephen Warren
Signed-off-by: Tom Warren
04 Feb, 2014
2 commits
-
Fix the timeout issue after running "bootp" command in U-Boot console.
TXFIFOTHRES bits of TXFILLTUNING register should be set to 0x10 after a
controller reset and before RUN bit is set (per technical reference
manual).Signed-off-by: Jim Lin
Signed-off-by: Stephen Warren
Tested-by: Thierry Reding
Signed-off-by: Tom Warren -
These are the board files for Venice2 (Tegra124), plus the AS3722 PMIC
files. PMIC init will be moved to pmic_common_init later.This builds/boots on Venice2, SPI/MMC/USB/I2C all work. Audio, display
and WB/LP0 are not supported yet.Signed-off-by: Tom Warren
Signed-off-by: Stephen Warren
Tested-by: Thierry Reding
Signed-off-by: Tom Warren
