summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-02-03ARM: tegra: pass just partition ID to power_partition()Stephen Warren
Pass just the partition ID to power_partition(), rather than also passing the partition's status register mask too. This makes it simpler to get call-sites correct, since they don't need to pass two different values that define the same thing and must match. Consequently, we can remove the mask definitions from pmc.h. Suggested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: misc cleanups triggered by Tegra124 reviewStephen Warren
Use a named constant for the PLL lock bit in enable_cpu_clocks(). Construct the complete value of pmc_pwrgate_toggle, rather than doing a read-modify-write; the register is simple enough and doesn't need to maintain state between operations. Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03mmc: tegra: support Tegra124Stephen Warren
Tegra124's MMC controller is very similar to earlier SoC generations, and can be supported by the same driver. However, there are some non-backwards-compatible HW differences, and hence a new DT compatible value must be used to describe the HW. This patch updates the driver to support that new compatible value. That said, the HW differences are only relevant when enabling certain high-performance transfer modes. Since the driver is currently very simple and doesn't enable those modes, we don't actually need to address any of these HW differences in the code yet, hence the simple nature of this patch. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: don't exceed AVP limits when configuring PLLPJimmy Zhang
Based on the Tegra TRM, the system clock (which is the AVP clock) can run up to 275MHz. On power on, the default sytem clock source is set to PLLP_OUT0. In function clock_early_init(), PLLP_OUT0 will be set to 408MHz which is beyond system clock's upper limit. The fix is to set the system clock to CLK_M before initializing PLLP, and then switch back to PLLP_OUT4, which has an appropriate divider configured, after PLLP has been configured Implement this logic in new function tegra30_set_up_pllp(), which sets up PLLP and all PLLP_OUT* dividers, and handles the AVP clock switching. Remove the duplicate PLLP setup from pllx_set_rate() and adjust_pllp_out_freqs(). Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> [swarren, significantly refactored the change] Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: amend pmc.h for Tegra114+Stephen Warren
Tegra114 and later's PMC module removes the pwrgate_timer_on register and replaces it with a clamp_status register. Adjust pmc.h to reflect this, and update any code affected by the change. The cpu.c change in this patch was extracted from a much larger patch by Jimmy Zhang. The pmc.h change was written from scratch, but inspired by related changes made by Tom Warren. There could well be other differences in the PMC register set for chips after Tegra20/30. However, they don't affect the code in U-Boot at present, so I haven't attempted an exhaustive update of pmc.h. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: implement MASK_BITS_31_29Tom Warren
Some clock sources have 3-bit muxes in bits 31:29. Implement core support for this mux field. Signed-off-by: Tom Warren <twarren@nvidia.com> [swarren, extracted from a larger patch by Tom] Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: MASK_BITS_ no longer needs specific valuesStephen Warren
Since all code that sets or interprets MASK_BITS_* now uses the enums to define/compare the values, there is no need for MASK_BITS_* to have a specific integer value. In fact, having a specific integer value may encourage people to hard-code those values, or interpret the values in incorrect ways. As such, remove the logic that assigns a specific value to the enum values in order to make it completely clear that it's just an enum, not something that directly represents some integer value. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: use MASK_BITS_* macros everywhereStephen Warren
Not all code that set or interpreted "mux_bits" was using the named macros, but rather some was simply using hard-coded integer constants. This makes it hard to determine which pieces of code are affected by changes to those constants. Replace the integer constants with the equivalent macro definitions so that everything is nicely tied together. Note that I'm not convinced all the code was using the correct integer constants, and hence I'm not convinced that all the code is now using the desired macros. However, this change is a purely mechanical replacement and should have no functional change. Fixing any bugs will come later, separately. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: rename OUT_CLK_SOURCE_*Stephen Warren
OUT_CLK_SOURCE_ are currently named after the number of bits the mask they represent includes. However, bit count is not the only possible variable; bit position may also vary. Rename OUT_CLK_SOURCE_ to OUT_CLK_SOURCE_31_30_ and OUT_CLK_SOURCE4_ to OUT_CLK_SOURCE_31_28 to more completely describe exactly what they represent, without having to go look up the definitions. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: rename MASK_BITS_29_28 to MASK_BITS_31_28Stephen Warren
The only place where the MASK_BITS_* values are used is in adjust_periph_pll(), which interprets the value 4 (old MASK_BITS_29_28, new MASK_BITS_31_28) as being associated with mask OUT_CLK_SOURCE4_MASK, i.e. bits 31:28. Rename the MASK_BITS_ macro to reflect how it's actually implemented. Note that no Tegra clock register actually uses all of bits 31:28 as the mux field. Rather, bits 30:28, 29:28, or 28 are used. However, in those cases, nothing is stored in the bits above the mux field, so it's safe to pretend that the mux field extends all the way to the end of the register. As such, the U-Boot clock driver is currently a bit lazy, and doesn't distinguish between 31:28, 30:28, 29:28 and 28; it just lumps them all together and pretends they're all 31:28. This patch doesn't cause this issue; it was pre-existing. Hopefully, future patches will clean this up. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: deduplicate MASK_BITS_xxx clock mux enumTom Warren
The enum used to define the set of register bits used to represent a clock's input mux, MUX_BITS_*, is defined separately for each SoC at present. Move this definition to a common location to ease fixing up some issues with the definition, and the code that uses it. Signed-off-by: Tom Warren <twarren@nvidia.com> [swarren, extracted from a larger patch by Tom] Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: clear $usb_need_init each bootStephen Warren
$usb_need_init prevents "usb start" from being run multiple times for each boot attempt, i.e. once for USB storage, another for PXE, and another for DHCP. However, the flag that's used to determine when to run "usb start" is never cleared, so a subsequent "boot" command will never probe for a freshly plugged in USB device. Fix this so that new USB devices will be probed once per boot attempt. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: set env vars to indicate Cardhu A04 supportStephen Warren
The U-Boot "cardhu" build supports only revision 4 of the Cardhu board and later compatible revisions. Hence, set $board_name in the default environment to "cardhu-a04" rather than just "cardhu". The Linux kernel has separate DTs for Cardhu A02 and A04, although the former isn't really supported any more. Consequently, the kernel DT file that matches the U-Boot cardhu build is "tegra30-cardhu-a04.dtb" rather than "tegra30-cardhu.dtb". Set the $fdtfile default environment variable to reflect this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03ARM: tegra: accept any SKU ID for most chipsStephen Warren
For Tegra20, the SKU ID actually impacts how U-Boot programs the chip, and hence we need to explicitly know about each and every SKU ID in order to operate correctly. However, for Tegra30/114, this isn't the case. Rather than forcing each new user with a different SKU to manually add their SKU ID into the code, simply accept any SKU ID. If U-Boot ever starts e.g. programming maximal CPU clocks etc., we'll need to undo this, or make the default case map to conservative defaults, but for now it's likely the path to least support cost. Reported-by: Olof Johansson <olof@lixom.net> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-01-29Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'Albert ARIBAUD
2014-01-28Merge branch 'u-boot-arm/next' into 'u-boot-arm/master'Albert ARIBAUD
2014-01-27boards.cfg: Keep the entries sortedFabio Estevam
Run "tools/reformat.py -i -d '-' -s 8 <boards.cfg >boards0.cfg && mv boards0.cfg boards.cfg" in order to keep the entries sorted. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
2014-01-27board_r - fixup functions table after relocationAlexey Brodkin
This is only required for "PIC" relocation and doesn't apply to modern "PIE" relocation which does data relocation as well as code. "init_sequence_r" is just an array that consists of compile-time adresses of init functions. Since this is basically an array of integers (pointers to "void" to be more precise) it won't be modified during relocation - it will be just copied to new location as it is. As a consequence on execution after relocation "initcall_run_list" will be jumping to pre-relocation addresses. As long as we don't overwrite pre-relocation memory area init calls are executed correctly. But still it is dangerous because after relocation we don't expect initially used memory to stay untouched. Cc: Tom Rini <trini@ti.com> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Thomas Langer <thomas.langer@lantiq.com> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2014-01-24arm: am43xx: Add USB spl boot supportDan Murphy
Add the USB host boot support for the am43xx evm Add the macros to boot from a usb drive in uBoot Signed-off-by: Dan Murphy <dmurphy@ti.com>
2014-01-24spl: common: Support for USB MSD FAT image loadingDan Murphy
Add SPL support to be able to detect a USB Mass Storage device connected to a USB host. Once a USB Mass storage device is detected the SPL will load the u-boot.img from a FAT partition to target address. Signed-off-by: Dan Murphy <dmurphy@ti.com>
2014-01-24spl: common: Move FAT funcs to a common fileDan Murphy
Move the FAT functions to a common location for reuse. Signed-off-by: Dan Murphy <dmurphy@ti.com>
2014-01-24powerpc: mpc5xxx: remove redundant CONFIG_MPC5xxx definitionMasahiro Yamada
We do not have to define CONFIG_MPC5xxx in board config headers (and start.S) because it is defined in arch/powerpc/cpu/mpc5xxx/config.mk. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24board: delete meaningless serial.hMasahiro Yamada
Delete some serial.h files, whole code in which is surrounded by #if 0 ... #endif Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Stefan Roese <sr@denx.de>
2014-01-24sandbox: fix the return type of os_free() functionMasahiro Yamada
The function os_free() returns nothing. Its return type should be "void" rather than "void *". Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24ARM: merge commonly-defined PLATFORM_RELFLAGSMasahiro Yamada
Before this commit, all arch/arm/cpu/${CPU}/config.mk except ARMv8 had the same option: $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) This commit moves it into arch/arm/config.mk. If the compiler does not support the option, it is ignored by $(call cc-option,...). So this commit gives no harm to ARMv8. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: mpc86xx: move CONFIG_MPC86xx definition to CPU config.mkMasahiro Yamada
Define CONFIG_MPC86xx in arch/powerpc/cpu/mpc86xx/config.mk because all target boards with mpc86xx cpu define it. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: mpc85xx: move CONFIG_MPC85xx definition to CPU config.mkMasahiro Yamada
Define CONFIG_MPC85xx in arch/powerpc/cpu/mpc85xx/config.mk because all target boards with mpc85xx cpu define it. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: mpc824x: remove redundant CONFIG_MPC824X definitionMasahiro Yamada
We do not have to define CONFIG_MPC824X in board config headers because it is defined in arch/powerpc/cpu/mpc824x/config.mk. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: mpc5xx: remove redundant CONFIG_5xx definitionMasahiro Yamada
We do not have to define CONFIG_5xx in a source file because it is defined in arch/powerpc/cpu/mpc5xx/config.mk. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: mpc512x: remove redundant CONFIG_MPC512X definitionMasahiro Yamada
We do not have to define CONFIG_MPC512X in board config headers because it is defined in arch/powerpc/cpu/mpc512x/config.mk. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: mpc8xx: remove redundant CONFIG_8xx definitionMasahiro Yamada
We do not have to define CONFIG_8xx in source files because it is defined in arch/powerpc/cpu/mpc8xx/config.mk Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: mpc83xx: remove redundant CONFIG_MPC83xx definitionMasahiro Yamada
We do not have to define CONFIG_MPC83xx in board config headers because it is defined in arch/powerpc/cpu/mpc83xx/config.mk. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24powerpc: ppc4xx: remove redundant CONFIG_4xx definitionMasahiro Yamada
We do not have to define CONFIG_4xx in board config headers because it is defined in arch/powerpc/cpu/ppc4xx/config.mk. include/configs/JSE.h defines "CONFIG_4x", not "CONFIG_4xx". I believe it is a typo because "CONFIG_4x" is not used at all in other files. So, I also deleted "CONFIG_4x" in include/configs/JSE.h. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24board: tec-ng: Do not make directories in a board MakefileMasahiro Yamada
Commit e5c5301f refactored the build system not to make directories in board makefiles. But commit 8f380381 create directories again in board/avionic-design/tec-ng/Makefile. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Alban Bedel <alban.bedel@avionic-design.de>
2014-01-24drivers: delete unused header filesMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24include: delete unused header filesMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24board: delete unused header filesMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Stefan Roese <sr@denx.de> Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>
2014-01-24x86: delete unused header filesMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-01-24powerpc: delete unused header filesMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24blackfin: delete unused header filesMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24avr32: delete unused header filesMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24avr32: move CONFIG_AVR32 definition to arch/avr32/config.mkMasahiro Yamada
Like other architectures, CONFIG_AVR32 can be defined in arch/avr32/config.mk rather than board header files. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Andreas Bießmann <andreas.devel@googlemail.com> Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>
2014-01-24Remove obsolete _LINUX_CONFIG_H macroMasahiro Yamada
Commit 643aae1406c93ddc64fcf8c136b47cdffd9c8ccd deleted include/linux/config.h but missed to delete _LINUX_CONFIG_H macro. It is no longer used at all. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24tools: move kermit files to tools/kermit directoryMasahiro Yamada
The script files, define2mk.sed and make-asm-offsets are used to create autoconf.mk and asm-offsets.h while build. Whereas README, dot.kermrc, flash_param, send_cmd, send_image are files useful for kermit. We should not put files which have the totally different purpose into the same directory. This commit creates a new directory, tools/kermit, and move kermit files into it. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Wolfgang Denk <wd@denx.de>
2014-01-24cosmetic: tools/scripts/README: insert only one space between wordsMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-01-24lib: fix return codes when CONFIG_SYS_VSNPRINTF is enabledDarwin Rambo
When CONFIG_SYS_VSNPRINTF is enabled, it protects print operations such as sprintf, snprintf, vsnprintf, etc., from buffer overflows. But vsnprintf_internal includes the terminating NULL character in the calculation of number of characters written. This affects sprintf and snprintf return values. Fix this issue by setting pointer 'str' back to the location of the '\0'. Signed-off-by: Darwin Rambo <drambo@broadcom.com> Reviewed-by: Steve Rae <srae@broadcom.com>
2014-01-24lib: time: add weak timer_init() functionDarwin Rambo
If timer_init() is made a weak stub function, then it allows us to remove several empty timer_init functions for those boards that already have a timer initialized when u-boot starts. Architectures that use the timer framework may also remove the need for timer.c. Signed-off-by: Darwin Rambo <drambo@broadcom.com> Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
2014-01-24am43xx_evm.h: Correct SPL max sizeTom Rini
Upon further inspection of relevant parts of the architecture, the maximum SPL binary size is 220KiB. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@ti.com>
2014-01-24DRA7: add ABB setup for MPU voltage domainNishanth Menon
Patch adds modification to shared omap5 abb_setup() function, and proper registers definitions needed for ABB setup sequence. ABB is initialized for MPU voltage domain at OPP_NOM. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
2014-01-24DRA7: Add support for ES1.1 silicon ID codeNishanth Menon
ES1.1 silicon is a very minor variant of ES1.0. Add priliminary support for ES1.1 IDCODE change. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@ti.com>