| 9e336903 | 16-Apr-2013 |
Wu, Josh <Josh.wu@atmel.com> |
arm: at91: add at91sam9n12ek board support
Add support for following features:
- nand boot, with PMECC 2bit ECC for 512 bytes sector
- SPI flash boot
- SD card boot
- LCD support
Signed-off
arm: at91: add at91sam9n12ek board support
Add support for following features:
- nand boot, with PMECC 2bit ECC for 512 bytes sector
- SPI flash boot
- SD card boot
- LCD support
Signed-off-by: Josh Wu <josh.wu@atmel.com>
[fix -Wimplicit-function-declaration for at91_lcd_hw_init()]
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
show more ...
|
| cac423a7 | 11-May-2013 |
Albert ARIBAUD <albert.u.boot@aribaud.net> |
Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' |
| ec7023db | 11-May-2013 |
Albert ARIBAUD <albert.u.boot@aribaud.net> |
Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
Conflicts:
drivers/mtd/nand/mxc_nand_spl.c
include/configs/m28evk.h |
| e825b100 | 10-May-2013 |
Albert ARIBAUD <albert.u.boot@aribaud.net> |
Merge branch 'u-boot-pxa/master' into 'u-boot-arm/master' |
| 47c6ea07 | 24-Apr-2013 |
SRICHARAN R <r.sricharan@ti.com> |
ARM: OMAP: Add arch_cpu_init function
The boot parameters passed from SPL to UBOOT
must be saved as a part of uboot's gd data
as early as possible, before we will inadvertently
overwrite it. So addi
ARM: OMAP: Add arch_cpu_init function
The boot parameters passed from SPL to UBOOT
must be saved as a part of uboot's gd data
as early as possible, before we will inadvertently
overwrite it. So adding a arch_cpu_init for the required
Socs to save it.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
[trini: Add igep0033 hunk]
Signed-off-by: Tom Rini <trini@ti.com>
show more ...
|
| 4a0eb757 | 24-Apr-2013 |
SRICHARAN R <r.sricharan@ti.com> |
ARM: OMAP: Cleanup boot parameters usage
The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'g
ARM: OMAP: Cleanup boot parameters usage
The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'gd'
structure. So read them from 'gd' instead.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
[trini: Add igep0033 hunk]
Signed-off-by: Tom Rini <trini@ti.com>
show more ...
|
| fda06812 | 24-Apr-2013 |
SRICHARAN R <r.sricharan@ti.com> |
ARM: OMAP: Correct save_boot_params and replace with 'C' function
Currently save_boot_params saves the boot parameters passed
from romcode. But this is not stored in a writable location
consistently
ARM: OMAP: Correct save_boot_params and replace with 'C' function
Currently save_boot_params saves the boot parameters passed
from romcode. But this is not stored in a writable location
consistently. So the current code would not work for a
'XIP' boot. Change this by saving the boot parameters in
'gd' which is always writable. Also add a 'C' function
instead of an assembly code that is more readable.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
show more ...
|
| f92f2277 | 24-Apr-2013 |
SRICHARAN R <r.sricharan@ti.com> |
ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common
These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.
Signed-off-by: Sricharan R
ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common
These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
show more ...
|
| 30bba017 | 25-Apr-2013 |
Tom Rini <trini@ti.com> |
am33xx: Fix warning with CONFIG_DISPLAY_CPUINFO
The arm_freq and ddr_freq variables are unused, so remove. Fixup
whitespace slightly while in here.
Reviewed-by: Peter Korsgaard <jacmet@sunsite.dk>
am33xx: Fix warning with CONFIG_DISPLAY_CPUINFO
The arm_freq and ddr_freq variables are unused, so remove. Fixup
whitespace slightly while in here.
Reviewed-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Tom Rini <trini@ti.com>
show more ...
|
| 81ac7e51 | 22-Apr-2013 |
Eric Benard <eric@eukrea.com> |
da850: provide davinci_enable_uart0
this is needed to bring UART0 out of reset but this function
currently only exists for dm644x/355/365/646x when da850 (at
least am1808 also need it).
Signed-off-
da850: provide davinci_enable_uart0
this is needed to bring UART0 out of reset but this function
currently only exists for dm644x/355/365/646x when da850 (at
least am1808 also need it).
Signed-off-by: Eric Bénard <eric@eukrea.com>
show more ...
|
| 0b1b60c7 | 17-Apr-2013 |
Lokesh Vutla <lokeshvutla@ti.com> |
ARM: OMAP5: Fix warm reset with USB cable connected
Warm reset on OMAP5 freezes when USB cable is connected.
Fix requires PRM_RSTTIME.RSTTIME1 to be programmed
with the time for which reset should b
ARM: OMAP5: Fix warm reset with USB cable connected
Warm reset on OMAP5 freezes when USB cable is connected.
Fix requires PRM_RSTTIME.RSTTIME1 to be programmed
with the time for which reset should be held low for the
voltages and the oscillator to reach stable state.
There are 3 parameters to be considered for calculating
the time, which are mostly board and PMIC dependent.
-1- Time taken by the Oscillator to shut + restart
-2- PMIC OTP times
-3- Voltage rail ramp times, which inturn depends on the
PMIC slew rate and value of the voltage ramp needed.
In order to keep the code in u-boot simple, have a way
for boards to specify a pre computed time directly using
the 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'
option. If boards fail to specify the time, use a default
as specified by 'CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC' instead.
Using the default value translates into some ~22ms and should work in
all cases.
However in order to avoid this large delay hiding other bugs,
its recommended that all boards look at their respective data
sheets and specify a pre computed and optimal value using
'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'
In order to help future board additions to compute this
config option value, add a README at doc/README.omap-reset-time
which explains how to compute the value. Also update the toplevel
README with the additional option and pointers to
doc/README.omap-reset-time.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[rnayak@ti.com: Updated changelog and added the README]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
show more ...
|
| 2bcc785a | 11-Apr-2013 |
Lubomir Popov <lpopov@mm-sol.com> |
OMAP5: USB: hsusbtll_clkctrl has to be in hw_auto for USB to work
USB TLL clocks do not support 'explicit_en', only 'hw_auto'
control (R. Sricharan). cm_l3init_hsusbtll_clkctrl has to be
moved to th
OMAP5: USB: hsusbtll_clkctrl has to be in hw_auto for USB to work
USB TLL clocks do not support 'explicit_en', only 'hw_auto'
control (R. Sricharan). cm_l3init_hsusbtll_clkctrl has to be
moved to the clk_modules_hw_auto_essential[] array in order
to make the clock work.
This fix is needed (but not sufficient) for USB EHCI operation
in U-Boot.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
show more ...
|
| 166e5cc6 | 27-Mar-2013 |
Lokesh Vutla <lokeshvutla@ti.com> |
arm: omap: emif: Fix DDR3 init after warm reset
EMIF supports a global warm reset mode, during which the
EMIF keeps the SDRAM content. But if leveling is enabled
at the time of warm reset for DDR3,
arm: omap: emif: Fix DDR3 init after warm reset
EMIF supports a global warm reset mode, during which the
EMIF keeps the SDRAM content. But if leveling is enabled
at the time of warm reset for DDR3, the following steps
needs to be done after warm reset:
1) Keep EMIF in self refresh mode.
2) Reset PHY to bring back the PHY to a known state.
3) Start Levelling procedure.
Doing the same.
And also enabling DLL lock and code output after warm reset.
Tested on OMAP5432 ES2.0
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
show more ...
|
| 3935277d | 08-Apr-2013 |
Lubomir Popov <lpopov@mm-sol.com> |
OMAP5: I2C: Enable i2c5 clocks
I2C4 and I2C5 are utilized on all known OMAP5 hardware platforms.
The i2c5 clock was however not enabled; do this here.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.co
OMAP5: I2C: Enable i2c5 clocks
I2C4 and I2C5 are utilized on all known OMAP5 hardware platforms.
The i2c5 clock was however not enabled; do this here.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
show more ...
|
| 035d5639 | 20-Mar-2013 |
Matt Porter <mporter@ti.com> |
am33xx: add pll and clock support for TI814x CPSW
Enables required PLLs and clocks for CPSW on TI814x.
Signed-off-by: Matt Porter <mporter@ti.com>
Reviewed-by: Tom Rini <trini@ti.com> |
| 7411cdf0 | 28-Apr-2013 |
Marek Vasut <marex@denx.de> |
arm: mxs: Add LCDIF clock configuration function
This function turns on the LCDIF clock and configures it's frequency. The
dividers settings are calculated within the function and the current
implem
arm: mxs: Add LCDIF clock configuration function
This function turns on the LCDIF clock and configures it's frequency. The
dividers settings are calculated within the function and the current
implementation should be fast and accurate.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
show more ...
|
| d5dae85f | 22-Apr-2013 |
Michal Simek <michal.simek@xilinx.com> |
fpga: zynq: Add support for loading bitstream
Devcfg device requires to load bitstream in binary format.
But u-boot also has an option for loading bitstream in bit
format. Let's handle both cases by
fpga: zynq: Add support for loading bitstream
Devcfg device requires to load bitstream in binary format.
But u-boot also has an option for loading bitstream in bit
format. Let's handle both cases by zynqpl driver.
Also add suport for loading partial bitstreams.
The first driver version was done by:
Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
show more ...
|
| 714dc001 | 28-Apr-2013 |
Marek Vasut <marex@denx.de> |
arm: mxs: Preprocess u-boot.bd so they contain full path
The u-boot-imx23.bd and u-boot-imx28.bd need to be preprocessed, otherwise
they have issues with out-of-tree build where elftosb tool couldn'
arm: mxs: Preprocess u-boot.bd so they contain full path
The u-boot-imx23.bd and u-boot-imx28.bd need to be preprocessed, otherwise
they have issues with out-of-tree build where elftosb tool couldn't sometimes
find the u-boot.bin and spl/u-boot-spl.bin .
Preprocess these .bd files with sed and insert full path to u-boot.bin and
spl/u-boot-spl.bin to prevent this issue. Moreover, to avoid adding more
churn into main Makefile, move all this preprocessing and u-boot.sb generation
into CPU directory instead.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
show more ...
|
| dd3ecf02 | 28-Apr-2013 |
Marek Vasut <marex@denx.de> |
arm: mx23: Fix VDDMEM misconfiguration
The VDDMEM ramped up in very weird way as it was horribly misconfigured.
Instead of setting up VDDMEM in one swipe, let it rise slowly the same
way as VDDD and
arm: mx23: Fix VDDMEM misconfiguration
The VDDMEM ramped up in very weird way as it was horribly misconfigured.
Instead of setting up VDDMEM in one swipe, let it rise slowly the same
way as VDDD and VDDA in spl_power_init.c and then only clear ILIMIT before
memory gets inited. This makes sure the VDDMEM rises sanely, not jumps up
and down as it did till now.
The VDDMEM prior to this change did this:
2V0____ .--------2V5
| `--'
0V____|
The VDDMEM now does this:
2V0_____,-----------2V5
/
0V__|
Moreover, VDDIO on MX23 uses 25mV steps while MX28 uses 50mV steps,
fix this difference too.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
show more ...
|
| 286a88cf | 05-May-2013 |
Fabio Estevam <fabio.estevam@freescale.com> |
mxs: Explain why some mx23 DDR registers are not configured
Put an explanation in the source code as to why some DDR registers do not
need to be configured.
Signed-off-by: Fabio Estevam <fabio.este
mxs: Explain why some mx23 DDR registers are not configured
Put an explanation in the source code as to why some DDR registers do not
need to be configured.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
show more ...
|
| 26be20fa | 05-May-2013 |
Fabio Estevam <fabio.estevam@freescale.com> |
mx23: Operate DDR voltage supply at 2.5V
After the recent fixes in the mx23 DDR setup, it is safe to operate DDR voltage
at the recommended 2.5V voltage level again.
Signed-off-by: Fabio Estevam <f
mx23: Operate DDR voltage supply at 2.5V
After the recent fixes in the mx23 DDR setup, it is safe to operate DDR voltage
at the recommended 2.5V voltage level again.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
show more ...
|
| 2ac2bb7a | 12-Jan-2013 |
Łukasz Dałek <luk0104@gmail.com> |
pxa: Add weak attribute to reset_cpu() function
This commit allows pxa2xx based boards to reimplement reset_cpu()
function with board specific reset sequence.
Signed-off-by: Lukasz Dalek <luk0104@g
pxa: Add weak attribute to reset_cpu() function
This commit allows pxa2xx based boards to reimplement reset_cpu()
function with board specific reset sequence.
Signed-off-by: Lukasz Dalek <luk0104@gmail.com>
show more ...
|
| ba5dfc11 | 03-May-2013 |
Benoît Thébaudeau <benoit.thebaudeau@advansee.com> |
imx: mx5: Remove legacy iomux support
Legacy iomux support is no longer needed now that all boards have been converted
to iomux-v3.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
imx: mx5: Remove legacy iomux support
Legacy iomux support is no longer needed now that all boards have been converted
to iomux-v3.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Reviewed-by: Marek Vasut <marex@denx.de>
show more ...
|
| e2003c16 | 03-May-2013 |
Benoît Thébaudeau <benoit.thebaudeau@advansee.com> |
imx: mx35: Remove legacy iomux support
Legacy iomux support is no longer needed now that all boards have been converted
to iomux-v3.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> |
| 9e933b43 | 03-May-2013 |
Benoît Thébaudeau <benoit.thebaudeau@advansee.com> |
imx: mx25: Remove legacy iomux support
Legacy iomux support is no longer needed now that all boards have been converted
to iomux-v3.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> |