Declare locally-used data structures and functions as
static and pull in header files to prevent compiler warnings
of "Should it be static?" when building with "make C=1".
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Configure CLKO outputs for SGTL5000, CSI camera.
The sys_mclk output for the SGTL500 in particular prevents
Windows CE from properly driving audio.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Ensure that cameras and USB OTG power are in a stable (reset)
state at reset by configuring their pads and toggling GPIOs.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Pads SD2_CLK/CMD/DAT0-3 are connected to an SDIO WiFi device on
Nitrogen and unconnected on BD-SL-i.MX6 (sabre lite).
Configure them as SDIO pins to prevent them from being in a state
that confuses the WiFi part.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
The same logic applies to both SD card slots, only with different
GPIOs and the code should make that easier to see.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Several customers have asked to leave the display quiet during
boot, so allow the user to express this request by the presence
of environment variable "novideo".
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Update DDR calibration settings based on a larger test set.
The initial values were gathered on a small number of boards,
and have been found to fail on some boards under load.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
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>
Now the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME}
are specified in arch/Kconfig.
We can delete the ones in arch and board Kconfig files.
This commit can be easily reproduced by the following command:
find . -name Kconfig -a ! -path ./arch/Kconfig | xargs sed -i -e '
/config[[:space:]]SYS_\(ARCH\|CPU\|SOC\|\VENDOR\|BOARD\|CONFIG_NAME\)/ {
N
s/\n[[:space:]]*string//
}
'
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
We have switched to Kconfig and the boards.cfg file is going to
be removed. We have to retrieve the board status and maintainers
information from it.
The MAINTAINERS format as in Linux Kernel would be nice
because we can crib the scripts/get_maintainer.pl script.
After some discussion, we chose to put a MAINTAINERS file under each
board directory, not the top-level one because we want to collect
relevant information for a board into a single place.
TODO:
Modify get_maintainer.pl to scan multiple MAINTAINERS files.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Suggested-by: Tom Rini <trini@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
This commit adds:
- arch/${ARCH}/Kconfig
provide a menu to select target boards
- board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
set CONFIG macros to the appropriate values for each board
- configs/${TARGET_BOARD}_defconfig
default setting of each board
(This commit was automatically generated by a conversion script
based on boards.cfg)
In Linux Kernel, defconfig files are located under
arch/${ARCH}/configs/ directory.
It works in Linux Kernel since ARCH is always given from the
command line for cross compile.
But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH until the board configuration is done.
That is why all the "*_defconfig" files should be gathered into a
single directory ./configs/.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
There is no need to keep iomuxc_base_regs structure as it serves the exact same
purpose of the iomuxc structure, which is to provide access to the GPR
registers.
The additional fields of iomuxc_base_regs are not used. Other advantage of
'iomuxc' is that it has a shorter name and the variable declarations can fit
into a single line.
So remove iomuxc_base_regs structure and use iomuxc instead.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Stefano Babic <sbabic@denx.de>
ECSPI chipselect (MX6_PAD_EIM_D19__GPIO3_IO19) is used with GPIO functionality,
so it does not make sense to set its pad as SPI pin.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>
Acked-by: Eric Nelson <eric.nelson@boundarydevices.com>
The mv_udc is not marvell-specific anymore. The mv_udc is used to drive
generic ChipIdea CI13xxx series OTG cores, so rename the driver to ci_udc
instead.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Eric Nelson <eric.nelson@boundarydevices.com>
Cc: Stefano Babic <sbabic@denx.de>
MAINTAINERS file has been removed from the project.
Replace its reference with 'boards.cfg' file instead.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Eric Nelson <eric.nelson@boundarydevices.com>
No need to pass 'u-boot.imx' as parameter for 'make' because u-boot.imx is
built by default.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Eric Nelson <eric.nelson@boundarydevices.com>
Move setup_sata function definition from platform file nitrogen6x.c
to arch/arm/imx-common/sata.c to avoid code duplication.
Signed-off-by: Giuseppe Pagano <giuseppe.pagano@seco.com>
CC: Stefano Babic <sbabic@denx.de>
CC: Fabio Estevam <fabio.estevam@freescale.com>
CC: Eric Nelson <eric.nelson@boundarydevices.com>
Conflicts:
arch/arm/cpu/arm926ejs/mxs/Makefile
board/compulab/cm_t35/Makefile
board/corscience/tricorder/Makefile
board/ppcag/bg0900/Makefile
drivers/bootcount/Makefile
include/configs/omap4_common.h
include/configs/pdnb3.h
Makefile conflicts are due to additions/removals of
object files on the ARM branch vs KBuild introduction
on the main branch. Resolution consists in adjusting
the list of object files in the main branch version.
This also applies to two files which are not listed
as conflicting but had to be modified:
board/compulab/common/Makefile
board/udoo/Makefile
include/configs/omap4_common.h conflicts are due to
the OMAP4 conversion to ti_armv7_common.h on the ARM
side, and CONFIG_SYS_HZ removal on the main side.
Resolution is to convert as this icludes removal of
CONFIG_SYS_HZ.
include/configs/pdnb3.h is due to a removal on ARM side.
Trivial resolution is to remove the file.
Note: 'git show' will also list two files just because
they are new:
include/configs/am335x_igep0033.h
include/configs/omap3_igep00x0.h
The 6x_upgrade script is used to upgrade U-Boot in SPI-NOR
on Nitrogen6x/SABRE Lite boards using U-Boot's 'sf' command.
U-Boot is placed at offset 0x400 in flash, and the script
currently only erases 0x50000 bytes. Since the current
head is 319k, any additional features enabled in the
configuration will exceed the space erased and cause errors
re-programming the device.
This patch increases the erase size to the full size of
the region allocated for the U-Boot binary.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Acked-by: Stefano Babic <sbabic@denx.de>
This clock isn't feeding anything under U-Boot, so there's no
point in changing it from power-on default.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Our Linux kernel switches the HDMI connector onto IPU0/DI1,
but the U-Boot display driver only supports IPU0/DI0 for the
time being.
Because of this, a soft re-boot will leave the HDMI output
connected to the wrong display port and prevent video from
being displayed.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
A little background is probably appropriate for this patch.
Since "the beginning" of usage of the SABRE Lite and Nitrogen6x
boards, DVI detection has been somewhat broken.
Some (most) DVI monitors don't produce the "HPD" bit in
the PHY_STAT0 register, but do show proper toggling of the
RX_SENSE0..3 bits.
Creating a new the bit-mask to include all five bits and
modifying the 'hdmidet' command and internal detection
routines allows these monitors to function properly in U-Boot.
A related patch to our kernels allows things to work under
Linux:
7d8752905c
Signed-off-by: Robert Winkler <robert.winkler@boundarydevices.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Instead of duplicating HDMI setup code for every mx6 board, factor out the common code
Signed-off-by: Pardeep Kumar Singla <b45784@freescale.com>
Acked-By: Eric Nelson <eric.nelson@boundarydevices.com>
mx6qsabrelite and nitrogen6q boards are hardware compatible, so let's avoid the
code duplication and only use the nitrogen6x source code to make board code
maintainance easier.
Tested booting a mainline device tree kernel on a mx6qsabrelite board.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
The old value of 0x000e0030 will cause ethernet
timeout issues on the sabrelite and possibly other
boards using the KSZ9021.
I have no explanation as to why.
But this is a correct change, the TRM will be updated
to show that 00b is the only valid setting for bits
19-18 of DRAM_RESET.
My thanks go to Liu Hui(Jason) for this information.
Acked-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
The number of gpio signal is packed inside CONFIG_SF_DEFAULT_CS macro
(shifted and or'ed with chip select), so it's incorrect to pass
that macro directly as an argument to gpio_direction_output() call.
Also, SPI driver sets the direction and initial value of a gpio,
used as a chip select signal, before any actual activity happens
on the bus.
So, it is safe to just remove the gpio_direction_output call,
that works incorrectly, thus making no effect, anyway.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Tested-by: Robert Winkler <robert.winkler@boundarydevices.com>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Many boot image configuration files refer to the
appropriate documentation file, but these references
contain typos in the directory and file name. Fix
them. Also fix reference to doc/README.SPL file.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Cc: Stefano Babic <sbabic@denx.de>
Acked-by: Stefano Babic <sbabic@denx.de>
PUE requires PKE to mean something, as do pull values with PUE, so do not
compell users to explicitly use PKE and PUE everywhere. This is also what is
done on Linux and what has already been done for i.MX51.
By the way, remove some unused pad control definitions.
There is no change of behavior.
Note that SPI_PAD_CTRL was defined by several boards with a pull value, but
without PKE or PUE, which means that no pull was actually enabled in the pad.
This might be a bug in those boards, but this patch does not change the
behavior, so it just removes the meaningless pull value from those definitions.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
CKO1 drives sgtl5000 codec clock on nitrogen boards and wandboard.
Doing this setup in the bootloader will allow us to remove a lot of code in
arch/arm/mach-imx/mach-imx6q.c from the mainline kernel.
Also, according to Eric Nelson: "enabling the clock <in the bootloader> will
remove squeal after an ungraceful reboot (watchdog) if hooked up to speakers."
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
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>
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>
When building for the nitrogen boards with 2GiB the following warning happens:
nitrogen6x.c:89:38: warning: integer overflow in expression [-Woverflow]
2GiB can not fit in 32-bits, so use ulong instead.
Reported-by: Albert Aribaud <albert.u.boot@aribaud.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
