- Apr 08, 2013
-
-
Tom Rini authored
Cc: Sricharan R <r.sricharan@ti.com> Signed-off-by:
Tom Rini <trini@ti.com>
-
Tom Rini authored
The omap5_uevm platform has eMMC, and it makes sense to say that our default env storage shall reside there. Other platforms may not, so move this choice to the EVM config. In addition, we should provide some way to partition the flash for later usage, so take advantage of the GPT partition table support code and allow that to be setup with some reasonable defaults. Cc: Sricharan R <r.sricharan@ti.com> Signed-off-by:
Tom Rini <trini@ti.com>
-
Tom Rini authored
In the case of booting from certain peripherals, such as UART, we must not see what the device descriptor says for RAW or FAT mode because in addition to being nonsensical, it leads to a hang. This is why we have a test currently for the boot mode being within range. The problem however is that on some platforms we get MMC2_2 as the boot mode and not the defined value for MMC2, and in others we get the value for MMC2_2. This is required to fix eMMC booting on omap5_uevm. Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC). Signed-off-by:
Tom Rini <trini@ti.com>
-
Lokesh Vutla authored
Commit "86021143 omap: emif: configure emif only when required" breaks SDRAM_AUTO_DETECTION. The issue is dmm_init() depends on emif_sizes[](SDRAM Auto detection) done in do_sdram_init(). The above commit moves dmm_init() above do_sdram_init() because of which dmm_init() uses uninitialized emif_sizes[]. So instead of using global emif_sizes[], get sdram details locally and calculate emif sizes. Reported-by:
Michael Cashwell <mboards@prograde.net> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com>
-
Lubomir Popov authored
V2 fixes line wrap issue of the patch itself. UART3 was enabled twice instead of UART4. One more cosmetic change in a comment on EMIF clock. Signed-off-by:
Lubomir Popov <lpopov@mm-sol.com> Reviewed-by:
R Sricharan <r.sricharan@ti.com>
-
Tom Rini authored
We shall remove these OMAP4/5-specific options in v2013.07, barring insufficient progress on the kernel side. Cc: Sricharan R <r.sricharan@ti.com> Signed-off-by:
Tom Rini <trini@ti.com>
-
SRICHARAN R authored
So with OMAP added to multi platform kernel, the uImage no more contains a valid load address. With the uboot already supporting zImage, change the default boot command to bootz instead. Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Sricharan R <r.sricharan@ti.com> Tested-by:
Nishanth Menon <nm@ti.com>
-
SRICHARAN R authored
Now with kernel moving to all device tree, the default boot command is changed to pass the device tree blob. Also, adding the findfdt command to get the dt-blob based on the board. Thanks to Tom Rini <trini@ti.com> for suggesting this. Signed-off-by:
Sricharan R <r.sricharan@ti.com>
-
Nishanth Menon authored
For production systems it is better to use script images since they are protected by checksums and carry valuable information like name and timestamp. Also, you can't validate the content passed to env import. But for development, it is easier to use the env import command and plain text files instead of script-images. Since both OMAP5evm/uevm boards are used primarily for development, we allow U-Boot to load env var from a text file in case that an boot.scr script-image is not present. The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence will be started. Inspired by commit: d70f5480 (omap4: allow the use of a plain text env file instead boot scripts) Signed-off-by:
Sricharan R <r.sricharan@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Tested-by:
Sricharan R <r.sricharan@ti.com>
-
SRICHARAN R authored
While booting with dt blob, if fdt_high is not set to 0xffffffff, the dt blob gets relocated to a high ram address, which the kernel is not able to use without HIGHMEM. So set it to 0xffffffff to avoid the issue. Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Sricharan R <r.sricharan@ti.com> Tested-by:
Nishanth Menon <nm@ti.com>
-
SRICHARAN R authored
The omap5-uevm is the reference board name for OMAP5 soc based platform. So rename it accordingly. Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Sricharan R <r.sricharan@ti.com> Tested-by:
Nishanth Menon <nm@ti.com>
-
Hunter, Jon authored
The function get_timer() should return time in ms and CONFIG_SYS_HZ should be set to 1000 by default. Fix both of these items. Signed-off-by:
Jon Hunter <jon-hunter@ti.com>
-
Hunter, Jon authored
Enable device-tree support for the omap2420-h4 board. Signed-off-by:
Jon Hunter <jon-hunter@ti.com>
-
Hunter, Jon authored
The omap2420-h4 board is using a RAM based address as the linker location for code. This is causing several problems when attempting to run the latest u-boot code base on this board from flash. Update the default linker location for code to be in NOR flash. Please note that OMAP maps the NOR flash to address 0x08000000 by default and so use this as the default address for the NOR flash. Also remove legacy code that attempts to calculate where in flash the sdata structure, that holds the memory interface configuration data, is located. By changing the default linker location for code to flash this is no longer necessary. Signed-off-by:
Jon Hunter <jon-hunter@ti.com>
-
Hunter, Jon authored
The size of the DRAM for the omap2420-h4 board is getting setup in the dram_init() function. However, for the current u-boot release this is too late and needs to be done in dram_init_banksize(). Therefore, add a dram_init_banksize() function for the omap2420-h4 board and setup the DRAM size there. Signed-off-by:
Jon Hunter <jon-hunter@ti.com>
-
Andreas Bießmann authored
Signed-off-by:
Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Cc: Thomas Weber <weber@corscience.de> Cc: Ilya Yanok <ilya.yanok@cogentembedded.com> Cc: Scott Wood <scottwood@freescale.com>
-
Andreas Bießmann authored
The kernel states: ---8<--- The OMAP3 GPMC hardware BCH engine computes remainder polynomials, it does not provide automatic error location and correction: this step is implemented using the BCH library. --->8--- And we do so in u-boot. This implementation uses the same layout for BCH8 but it is fix. The current provided layout does only work with 64 Byte OOB. Signed-off-by:
Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Cc: Ilya Yanok <ilya.yanok@cogentembedded.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Mansoor Ahamed <mansoor.ahamed@ti.com> Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
-
Andreas Bießmann authored
With uppcoming BCH support on OMAP devices we need to decide between differnt algorithms when switching the ECC engine. Currently we support 1-bit hammign and 8-bit BCH on HW backend. In order to switch between differnet ECC algorithms we need to change the interface of omap_nand_switch_ecc() also. Signed-off-by:
Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
-
Andreas Bießmann authored
This patch adds BCH8 ooblayout for NAND as provided by 0e618ef0a6a33cf7ef96c2c824402088dd8ef48c in linux kernel. This Layout is currently only provided for 64 byte OOB. Signed-off-by:
Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Cc: Ilya Yanok <ilya.yanok@cogentembedded.com> Cc: Scott Wood <scottwood@freescale.com> Reviewed-by:
Tom Rini <trini@ti.com>
-
Andreas Bießmann authored
arch/arm/include/asm/arch-am33xx/omap_gpmc.h and arch/arm/include/asm/arch-omap3/omap_gpmc.h are almost the same, consolidate the common parts into a new header. Introduce a new asm/omap_gpmc.h which defines the command part and pulls in the architecture specific one. Signed-off-by:
Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Reviewed-by:
Tom Rini <trini@ti.com>
-
Andreas Bießmann authored
This patch adds the BCH result registers to register mapping for OMAP3 gpmc. Signed-off-by:
Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Cc: Ilya Yanok <ilya.yanok@cogentembedded.com> Cc: Scott Wood <scottwood@freescale.com> Reviewed-by:
Tom Rini <trini@ti.com>
-
Manfred Huber authored
Flush UART3 xmit on enable if TEMT is broken On some OMAP3 devices when UART3 is configured for boot mode before SPL starts only THRE bit is set. We have to empty the transmitter before initialization starts. This patch avoids the use of CONFIG_SYS_NS16550_BROKEN_TEMT. Signed-off-by:
Manfred Huber <man.huber@arcor.de> Tested-by:
Javier Martinez Canillas <javier@dowhile0.org> Tested-by:
Andreas Bießmann <andreas.devel@googlemail.com>
-
Tom Rini authored
We must not assume ROM has enabled the clock for MMC1. Reported-by:
Koen Kooi <koen@dominion.thruhere.net> Signed-off-by:
Tom Rini <trini@ti.com> Acked-by:
Peter Korsgaard <jacmet@sunsite.dk>
-
Lars Poeschel authored
This is done already for am335x in 59dcf970 and also applies for pcm051. It powers down the IO receiver when not performing read which helps reducing the overall power consuption in low power states (suspend/standby). Signed-off-by:
Lars Poeschel <poeschel@lemonage.de>
-
Bin Liu authored
Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED is not set, in which case Ether gadget only operates in fullspeed. Reviewed-by:
Tom Rini <trini@ti.com> Signed-off-by:
Bin Liu <b-liu@ti.com>
-
Bin Liu authored
On TI AM335x devices, MUSB has bulk split/combine feature enabled in the ConfigData register, but the current MUSB driver does not support it yet. Therefore, disable the feature for now, until the driver adds the support. One usecase which is broken because of this feature is that Ether gadget stops working in Fullspeed mode (by un-defining CONFIG_USB_GADGET_DUALSPEED) After desabled this feature, MUSB driver send packets in proper size (no more than 64 bytes) in Fullspeed mode. This has been validated with Ether gadget in Fullspeed mode on AM335x EVM. Signed-off-by:
Bin Liu <b-liu@ti.com>
-
- Apr 05, 2013
-
-
Josh Wu authored
Atmel change to new logo since 2012. This patch update the logo to new one. Signed-off-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
Andreas Bießmann <andreas.devel@googlemail.com>
-
- Apr 04, 2013
-
-
Albert ARIBAUD authored
-
Minkyu Kang authored
Fix the indentation of some defines by tab. Signed-off-by:
Minkyu Kang <mk7.kang@samsung.com>
-
Albert ARIBAUD authored
-
Dirk Behme authored
Reviewing the ECSPI reset handling shows two issues: 1. For the enable/reset bit (MXC_CSPICTRL_EN) in the control reg (ECSPIx_CONGREG) the i.MX6 technical reference manual states: -- cut -- ECSPIx_CONREG[0]: EN: Writing zero to this bit disables the block and resets the internal logic with the exception of the ECSPI_CONREG. -- cut -- Note the exception mentioned: The CONREG itself isn't reset. Fix this by manually writing the reset value 0 to the whole register. This sets the EN bit to zero, too (i.e. includes the old ~MXC_CSPICTRL_EN). 2. We want to reset the whole SPI block here. So it makes no sense to first read the old value of the CONREG and write it back, later. This will give us the old (historic/random) value of the CONREG back. And doesn't reset the CONREG. To get a clean CONREG after the reset of the block, too, don't use the old (historic/random) value of the CONREG while doing the reset. And read the clean CONREG after the reset. This was found while working on a SPI boot device where the i.MX6 boot ROM has already initialized the SPI block. The initialization by the boot ROM might be different to what the U-Boot driver wants to configure. I.e. we need a clean reset of SPI block, including the CONREG. Signed-off-by:
Dirk Behme <dirk.behme@de.bosch.com> CC: Stefano Babic <sbabic@denx.de> CC: Fabio Estevam <fabio.estevam@freescale.com>
-
Stephen Warren authored
Apparently, CONFIG_SYS_HZ must be 1000. Change this, and fix the timer driver to conform to this. Have the timer implementation export a custom API get_timer_us() for use by the BCM2835 MMC API, which needs us resolution for a HW workaround. Signed-off-by:
Stephen Warren <swarren@wwwdotorg.org>
-
- Apr 03, 2013
-
-
Javier Martinez Canillas authored
board/freescale/mx6qsabrelite/README explain a procedure to update the SPI-NOR on the SabreLite board without Freescale manufacturing tool but following this procedure leads to both "sf erase" and "sf write" failing on a mx6qsabrelite board: MX6QSABRELITE U-Boot > sf probe 1 MX6QSABRELITE U-Boot > sf erase 0 0x40000 SPI flash erase failed MX6QSABRELITE U-Boot > sf write 0x10800000 0 0x40000 SPI flash write failed This is because the chip-select 1 is wrong and the correct value is 0x7300. Since commit c1173bd0 ("sf command: allow default bus and chip selects") the chip-select and bus arguments for the sf probe command are optional so let's just remove it and use "sf probe" instead. Signed-off-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk>
-
Fabio Estevam authored
CONFIG_SYS_FSL_USDHC_NUM is not used for wandboard. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Acked-by:
Otavio Salvador <otavio@ossystems.com.br>
-
Fabio Estevam authored
No need to call 'mmc dev' twice. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Acked-by:
Otavio Salvador <otavio@ossystems.com.br>
-
Fabio Estevam authored
No need to call 'mmc dev' twice. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Acked-by:
Otavio Salvador <otavio@ossystems.com.br>
-
Fabio Estevam authored
When booting a Freescale kernel 3.0.35 on a Wandboard solo, the get_board_rev() returns 0x62xxx, which is not a value understood by the VPU (Video Processing Unit) library in the kernel and causes the video playback to fail. The expected values for get_board_rev are: 0x63xxx: For mx6quad/dual 0x61xxx: For mx6dual-lite/solo So adjust get_board_rev() accordingly and make it as weak function, so that we do not need to define it in every mx6 board file. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Acked-by:
Dirk Behme <dirk.behme@de.bosch.com> Acked-by:
Eric Nelson <eric.nelson@boundarydevices.com>
-
Alexandre Pereira da Silva authored
The netargs variable was referencing the non-existing variable console_mainline. Change that to console variable instead. Signed-off-by:
Alexandre Pereira da Silva <aletes.xgr@gmail.com> Acked-by:
Otavio Salvador <otavio@ossystems.com.br>
-
Abbas Raza authored
Maximum bus width supported by some i.MX6 boards is not 8bit like others. In case where both host controller and card support 8bit transfers, they agree to communicate on 8bit interface while some boards support only 4bit interface. Due to this reason the mmc 8bit default mode fails on these boards. To rectify this, define maximum bus width supported by these boards (4bit). If max_bus_width is not defined, it is 0 by default and 8bit width support will be enabled in host capabilities otherwise host capabilities are modified accordingly. It is tested with a MMCplus card. Signed-off-by:
Abbas Raza <Abbas_Raza@mentor.com> cc: stefano Babic <sbabic@denx.de> cc: Andy Fleming <afleming@gmail.com> Acked-by:
Dirk Behme <dirk.behme@de.bosch.com> Acked-by:
Andrew Gabbasov <andrew_gabbasov@mentor.com>
-
Otavio Salvador authored
Change all "#define/ifdef<TAB>" sequences into "#define/ifdef<SPACE>". Signed-off-by:
Otavio Salvador <otavio@ossystems.com.br>
-