Thomas Chou [Wed, 9 Sep 2015 07:09:43 +0000 (15:09 +0800)]
nios2: call board_init_f_mem
We will need CONFIG_SYS_MALLOC_F_LEN to use serial uclass.
So we shall undefine CONFIG_SYS_GENERIC_GLOBAL_DATA, and
call board_init_f_mem() to allocates early malloc() memory
with size of CONFIG_SYS_MALLOC_F_LEN in board_f.c.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Reviewed-by: Marek Vasut <marex@denx.de>
Thomas Chou [Sun, 6 Sep 2015 12:13:34 +0000 (20:13 +0800)]
nios2: define _end in link script
Since commit 44c6e6591cb451ae606f8bde71dd5fb7b4002544
"rename _end to __bss_end__" , the _end was removed.
But we need it now for separated device tree control,
ie, CONFIG_OF_SEPARATE .
The _end is used by fdtdec_setup() to find the blob.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Acked-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Thomas Chou [Fri, 4 Sep 2015 08:39:16 +0000 (16:39 +0800)]
nios2: enlarge the code relocation range
As we will use u-boot-dtb.bin, the code relocation range
should be adjusted to accommodate the additional dtb.
It might be overkilled to look into dtb header to find the
dtb size, so we will simply use CONFIG_SYS_MONITOR_LEN.
Mugunthan V N [Tue, 13 Oct 2015 08:32:29 +0000 (14:02 +0530)]
ARM: AM335x: mux: change mmc0 cd pinmux from mmc0_sdcd to gpio
Currently omap_hsmmc driver doesn't use sdcd pin to detect
whether the card is present or not. Instead the same pin is used
as GPIO to detect card presence. So change the pin mux mode from
mmc0_sdcd to gpio0_6.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Mugunthan V N [Tue, 13 Oct 2015 08:27:16 +0000 (13:57 +0530)]
drivers: gpio: omap: add support for parsing additional gpio parameters
With DM_GPIO, gpio parameters like ACTIVE_(LOW/HIGH) are to be
parsed in xlate gpio drivers-ops. Since xlate is not implemented
in omap_gpio driver, the driver considers all gpio to be
ACTIVE_HIGH which is the default case and fails to return actual
gpio status for ACTIVE_LOW gpios. So adding .xlate ops to
omap_gpio.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Mugunthan V N [Mon, 28 Sep 2015 10:47:51 +0000 (16:17 +0530)]
am437x: Add am437x_gp_evm_defconfig using CONFIG_DM
Import various DT files for am4372, an43xx pinctrl and
am437x-gp-evm from Linux Kernel v4.2
Add config file for this board, enable DM, DM_GPIO, DM_SERIAL
and DM_MMC.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Mugunthan V N [Mon, 28 Sep 2015 07:26:28 +0000 (12:56 +0530)]
omap_hsmmc: update struct hsmmc to accomodate base address from DT
Existing driver gets the actual omap hammc base address + 0x100
bytes as the first 0x100 bytes is not used by the driver. But
with DM conversion the base address from DT is different, to
accommodate the offset adding res0[0x100] to struct hsmmc.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Phy mode is a board property and it can be different between
multiple board and ports, so it should not be hardcoded in
driver to one specific mode. So adding a field in eth_priv_t
structure to pass phy mode to driver.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: dts: keystone2: Do not use LPAE addresses in U-Boot
Keystone dts files assumes that LPAE is enabled and top level root
node uses 64bit addresses. This breaks the keystone boot with
CONFIG_OF_CONTROL enabled. So do not use 64 bit addresse in U-Boot DT.
ARM: keystone2: spl: Fix stack allocation with CONFIG_SYS_MALLOC_F_LEN
If CONFIG_SYS_MALLOC_F_LEN is enabled, the stack is moved down to the
specified size to make the malloc function available before relocation.
But on keystone platforms SYS_SPL_MALLOC is immediately preceding stack,
which is causing an overlap with this config enabled.
So leave a gap between malloc space and stack space.
With CONFIG_DM_SERIAL is enabled NS16550_init() cannot be
called directly. Driver probe should be taking care of this.
So call this function only when DM_SERIAL is not enabled.
Introduce a dummy driver for sandbox that allows us to verify basic
functionality. This is not meant to do anything functional - but is
more or less meant as a framework plumbing debug helper.
The sandbox remoteproc driver maintains absolutey no states and is a
simple driver which just is filled with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
drivers: Introduce a simplified remoteproc framework
Many System on Chip(SoC) solutions are complex with multiple processors
on the same die dedicated to either general purpose of specialized
functions. Many examples do exist in today's SoCs from various vendors.
Typical examples are micro controllers such as an ARM M3/M0 doing a
offload of specific function such as event integration or power
management or controlling camera etc.
Traditionally, the responsibility of loading up such a processor with a
firmware and communication has been with a High Level Operating
System(HLOS) such as Linux. However, there exists classes of products
where Linux would need to expect services from such a processor or the
delay of Linux and operating system being able to load up such a
firmware is unacceptable.
To address these needs, we need some minimal capability to load such a
system and ensure it is started prior to an Operating System(Linux or
any other) is started up.
NOTE: This is NOT meant to be a solve-all solution, instead, it tries to
address certain class of SoCs and products that need such a solution.
A very simple model is introduced here as part of the initial support
that supports microcontrollers with internal memory (no MMU, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
Sjoerd Simons [Fri, 28 Aug 2015 13:01:56 +0000 (15:01 +0200)]
configs: am335x_evm: Support distro bootcmds
Add support for distro bootcmds and network booting while retaining
backwards compatibility with the current "legacy" setup. With these
changes the default boot sequence becomes:
Sjoerd Simons [Fri, 28 Aug 2015 13:01:54 +0000 (15:01 +0200)]
config_distro_bootcmd.h: Use a private variable for bootpart
Hush has an oddity where using ${var} causes var to resolved in the the global
address space (iotw the environment) first and only afterwards will the local
variable space be searched.
This causes odd side-effects when iterating over the boot partitions
using ${bootpart} if the environment also has a bootpart variable (e.g. for
the various TI boards). Fix this by using the hopefully more unique
${distro_bootpart} instead of ${bootpart}.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
omap-common: Common get_board_serial function to pass serial through ATAG
Since there is a common function to grab the serial number from the die id bits,
it makes sense have one to parse that serial number and feed it to the serial
ATAG.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
omap-common: Common function to display die id, replacing omap3-specific version
This introduces omap_die_id_display to display the full die id.
There is no need to store it in an environment variable, that no boot script
is using anyway.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
omap-common: Common serial and usbethaddr functions based on die id
Now that we have a common prototype to grab the omap die id, functions to figure
out a serial number and usb ethernet address can use it directly.
Those also get an omap_die_id prefix for better consistency.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
This introduces omap5 support for omap_die_id, which matches the common
omap_die_id definition. It replaces board-specific code to grab the die id bits.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
This introduces omap4 support for omap_die_id, which matches the common
omap_die_id definition. It replaces board-specific code to grab the die id bits.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
board_name environment variable was not getting set correctly for Pandaboard A4 and ES
Signed-off-by: David Batzle <dbatzle@dcbcyber.com> CC: Albert Aribaud <albert.u.boot@aribaud.net>; Tom Rini <trini@ti.com>; Peter Robinson <pbrobinson@gmail.com>
Advantech SOM-6896 is a Broadwell U based COM Express Compact Module
Type 6. This patch adds support for it as a coreboot payload.
On board SATA and SPI are functional. On board Ethernet isn't functional
but since it's optional and ties up a PCIe x4 that is otherwise brought
out, this isn't a concern at the moment. USB doesn't work since the
xHCI driver appears to be broken.
Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Bin Meng [Sun, 18 Oct 2015 21:55:37 +0000 (15:55 -0600)]
x86: ivybridge: Enable the MRC cache
This works correctly now, so enable it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Dropped malloc() and adjusted commit message: Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 19 Oct 2015 01:51:26 +0000 (19:51 -0600)]
x86: Init the debug UART if enabled
If the debug UART is enabled, get it ready for use at the earliest possible
opportunity. This is not actually very early, but until we have a stack it
is difficult to make it work.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 19 Oct 2015 01:51:25 +0000 (19:51 -0600)]
debug_uart: Add an option to announce the debug UART
It is useful to see a message from the debug UART early during boot so that
you know things are working. Add an option to enable this. The message will
be displayed as soon as debug_uart_init() is called.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 19 Oct 2015 01:51:24 +0000 (19:51 -0600)]
debug_uart: Support board-specific UART initialisation
Some boards need to set things up before the debug UART can be used. On
these boards a call to debug_uart_init() is insufficient. When this option
is enabled, the function board_debug_uart_init() will be called when
debug_uart_init() is called. You can put any code here that is needed to
set up the UART ready for use, such as set pin multiplexing or enable
clocks.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Mon, 19 Oct 2015 01:51:23 +0000 (19:51 -0600)]
debug_uart: Adjust the declaration of debug_uart_init()
We want to be able to add other common code to this function. So change the
driver's version to have an underscore before it, just like
_debug_uart_putc(). Define debug_uart_init() to call this version.
Update all drivers to this new method.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
projects / u-boot.git / log