Commit graph

7 commits

Author SHA1 Message Date
Bin Meng
a187559e3d Use correct spelling of "U-Boot"
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
2016-02-06 12:00:59 +01:00
Fabio Estevam
e7eb277dce mx6boards: Fix error handling in board_mmc_init()
When an invalid USDHC port is passed we should return -EINVAL instead of 0.

Also, return the error immediately on fsl_esdhc_initialize() failure.

Cc: Eric Benard <eric@eukrea.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
2014-11-24 12:10:18 +01:00
Eric Nelson
3acb011c3c ARM: i.MX: provide declaration for board_spi_cs_gpio
Provide a public declaration of the board_spi_cs_gpio()
callback for i.MX SPI chip selects to prevent the warning
"Should it be static?" when compiling with "make C=1".

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
2014-10-21 10:47:14 +02:00
Nikita Kiryanov
155fa9af95 spi: mxc: fix sf probe when using mxc_spi
MXC SPI driver has a feature whereas a GPIO line can be used to force CS high
across multiple transactions. This is set up by embedding the GPIO information
in the CS value:

cs = (cs | gpio << 8)

This merge of cs and gpio data into one value breaks the sf probe command:
if the use of gpio is required, invoking "sf probe <cs>" will not work, because
the CS argument doesn't have the GPIO information in it. Instead, the user must
use "sf probe <cs | gpio << 8>". For example, if bank 2 gpio 30 is used to force
cs high on cs 0, bus 0, then instead of typing "sf probe 0" the user now must
type "sf probe 15872".

This is inconsistent with the description of the sf probe command, and forces
the user to be aware of implementaiton details.

Fix this by introducing a new board function: board_spi_cs_gpio(), which will
accept a naked CS value, and provide the driver with the relevant GPIO, if one
is necessary.

Cc: Eric Nelson <eric.nelson@boundarydevices.com>
Cc: Eric Benard <eric@eukrea.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
2014-09-24 17:25:39 +05:30
Iain Paton
015e215bbf embest/mx6boards: only toggle eMMC usdhc3 RST line on MarSboard
On MarS usdhc3 is eMMC, on RIoT usdhc3 is uSD and eMMC is usdhc4.

Don't run the MarS specific eMMC reset code on usdhc3 when
board_type == BOARD_IS_RIOTBOARD

Signed-off-by: Iain Paton <ipaton0@gmail.com>
2014-08-13 09:32:53 +02:00
Eric Benard
fef8c66180 embest/mx6boards: use common detect_hdmi
Signed-off-by: Eric Bénard <eric@eukrea.com>
2014-04-15 12:23:57 +02:00
Eric Benard
3cbeb0f004 RiOTboard and MarSBoard: add new boards support
RiOTboard is produced by Embest/Element 14 and is based on i.MX6 Solo
The following features are tested :
- UART2 (console)
- eMMC
- SDCard
- uSDCard
- Ethernet
- USB Host (through 4 ports hub)
- HDMI output
- I2C 1/2/3
- LVDS TFT with LCD8000-97C from Embest/Element 14

Boot on eMMC and through USB loader are tested.

For more informations on this board : http://www.riotboard.org/

MarSBoard is produced by Embest/Element 14 and is based on i.MX6 Dual
The following features are tested :
- UART2 (console)
- eMMC
- uSDCard
- Ethernet
- USB Host (through 2 ports hub)
- HDMI output
- I2C 1/2
- SPI NOR Flash
- LVDS TFT with LCD8000-97C from Embest/Element 14

Boot on SPI NOR and through USB loader are tested.

For more informations on this board :
http://www.embest-tech.com/shop/star/marsboard.html

Both boards are supported by the same code base as they are based on a
common trunk of schematics.

Signed-off-by: Eric Bénard <eric@eukrea.com>
Acked-by: Stefano Babic <sbabic@denx.de>
2014-04-15 12:23:57 +02:00