u-boot.git/include/asm-generic/global_data.h, branch v2014.10 Unnamed repository; edit this file 'description' to name the repository. Add a flag indicating when the serial console is ready 2014-07-23T13:07:25+00:00 Simon Glass sjg@chromium.org 2014-07-23T12:55:07+00:00 093f79ab88d57b800283b0a172c17167699f4243 For sandbox we have a fallback console which is used very early in U-Boot, before serial drivers are available. Rather than try to guess when to switch to the real console, add a flag so we can be sure. This makes sure that sandbox can always output a panic() message, for example, and avoids silent failure (which is very annoying in sandbox). Signed-off-by: Simon Glass <sjg@chromium.org> 
For sandbox we have a fallback console which is used very early in
U-Boot, before serial drivers are available. Rather than try to guess
when to switch to the real console, add a flag so we can be sure. This
makes sure that sandbox can always output a panic() message, for example,
and avoids silent failure (which is very annoying in sandbox).

Signed-off-by: Simon Glass <sjg@chromium.org>
dm: Support driver model prior to relocation 2014-07-23T13:07:24+00:00 Simon Glass sjg@chromium.org 2014-07-23T12:55:04+00:00 ab7cd62790c4f7831b91eab8a2ec81742d01bb54 Initialise devices marked 'pre-reloc' and make them available prior to relocation. Note that this requires pre-reloc malloc() to be available. Signed-off-by: Simon Glass <sjg@chromium.org> 
Initialise devices marked 'pre-reloc' and make them available prior to
relocation. Note that this requires pre-reloc malloc() to be available.

Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple malloc() implementation for pre-relocation 2014-07-23T13:05:40+00:00 Simon Glass sjg@chromium.org 2014-07-11T04:23:28+00:00 d59476b6446799c21e64147d86483140154c1886 If we are to have driver model before relocation we need to support some way of calling memory allocation routines. The standard malloc() is pretty complicated: 1. It uses some BSS memory for its state, and BSS is not available before relocation 2. It supports algorithms for reducing memory fragmentation and improving performace of free(). Before relocation we could happily just not support free(). 3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since this has been loaded anyway this is not really a problem. The simplest way to support pre-relocation malloc() is to reserve an area of memory and allocate it in increasing blocks as needed. This implementation does this. To enable it, you need to define the size of the malloc() pool as described in the README. It will be located above the pre-relocation stack on supported architectures. Note that this implementation is only useful on machines which have some memory available before dram_init() is called - this includes those that do no DRAM init (like tegra) and those that do it in SPL (quite a few boards). Enabling driver model preior to relocation for the rest of the boards is left for a later exercise. Signed-off-by: Simon Glass <sjg@chromium.org> 
If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.

The standard malloc() is pretty complicated:

1. It uses some BSS memory for its state, and BSS is not available before
relocation

2. It supports algorithms for reducing memory fragmentation and improving
performace of free(). Before relocation we could happily just not support
free().

3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
this has been loaded anyway this is not really a problem.

The simplest way to support pre-relocation malloc() is to reserve an area
of memory and allocate it in increasing blocks as needed. This
implementation does this.

To enable it, you need to define the size of the malloc() pool as described
in the README. It will be located above the pre-relocation stack on
supported architectures.

Note that this implementation is only useful on machines which have some
memory available before dram_init() is called - this includes those that
do no DRAM init (like tegra) and those that do it in SPL (quite a few
boards). Enabling driver model preior to relocation for the rest of the
boards is left for a later exercise.

Signed-off-by: Simon Glass <sjg@chromium.org>
dm: rename device struct to udevice 2014-05-27T14:21:32+00:00 Heiko Schocher hs@denx.de 2014-05-22T10:43:05+00:00 54c5d08a09e631f88738db54c75395c6457c2157 using UBI and DM together leads in compiler error, as both define a "struct device", so rename "struct device" in include/dm/device.h to "struct udevice", as we use linux code (MTD/UBI/UBIFS some USB code,...) and cannot change the linux "struct device" Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Marek Vasut <marex@denx.de> 
using UBI and DM together leads in compiler error, as
both define a "struct device", so rename "struct device"
in include/dm/device.h to "struct udevice", as we use
linux code (MTD/UBI/UBIFS some USB code,...) and cannot
change the linux "struct device"

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Marek Vasut <marex@denx.de>
driver/mxc_i2c: Move static data structure to global_data 2014-04-29T05:10:27+00:00 York Sun yorksun@freescale.com 2014-02-10T22:02:52+00:00 dec1861be90c948ea9fb771927d3d26a994d2e20 This driver needs a data structure in SRAM before SDRAM is available. This is not alway the case using .data section. Moving this data structure to global_data guarantees it is writable. Signed-off-by: York Sun <yorksun@freescale.com> CC: Troy Kisky <troy.kisky@boundarydevices.com> 
This driver needs a data structure in SRAM before SDRAM is available.
This is not alway the case using .data section. Moving this data
structure to global_data guarantees it is writable.

Signed-off-by: York Sun <yorksun@freescale.com>
CC: Troy Kisky <troy.kisky@boundarydevices.com>
dm: Add base driver model support 2014-03-04T17:15:29+00:00 Simon Glass sjg@chromium.org 2014-02-26T22:59:18+00:00 6494d708bfc630ac0585d5a81707442ebf578eac Add driver model functionality for generic board. This includes data structures and base code for registering devices and uclasses (groups of devices with the same purpose, e.g. all I2C ports will be in the same uclass). The feature is enabled with CONFIG_DM. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com> 
Add driver model functionality for generic board.

This includes data structures and base code for registering devices and
uclasses (groups of devices with the same purpose, e.g. all I2C ports will
be in the same uclass).

The feature is enabled with CONFIG_DM.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com>
Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com>
Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
Introduce common timer functions 2013-11-04T16:06:16+00:00 Rob Herring rob.herring@calxeda.com 2013-10-04T15:22:41+00:00 8dfafdde88eb3e71d5569846396ae67a91017232 Many platforms duplicate pretty much the same timer code yet they all have a 32-bit freerunning counter register. Create a common implementation that minimally requires 2 or 3 defines to add timer support: CONFIG_SYS_TIMER_RATE - Clock rate of the timer counter CONFIG_SYS_TIMER_COUNTER - Address of 32-bit counter CONFIG_SYS_TIMER_COUNTS_DOWN - Define if counter counts down All functions are weak or ifdef'ed so they can still be overriden by any platform. Signed-off-by: Rob Herring <rob.herring@calxeda.com> 
Many platforms duplicate pretty much the same timer code yet they all have
a 32-bit freerunning counter register. Create a common implementation that
minimally requires 2 or 3 defines to add timer support:

CONFIG_SYS_TIMER_RATE - Clock rate of the timer counter
CONFIG_SYS_TIMER_COUNTER - Address of 32-bit counter
CONFIG_SYS_TIMER_COUNTS_DOWN - Define if counter counts down

All functions are weak or ifdef'ed so they can still be overriden by any
platform.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Merge branch 'master' of git://git.denx.de/u-boot-i2c 2013-07-24T13:50:24+00:00 Tom Rini trini@ti.com 2013-07-24T13:22:28+00:00 c2120fbfbc4d1f6953228f86be8bdbf38bacfdab The sandburst-specific i2c drivers have been deleted, conflict was just over the SPDX conversion. Conflicts: board/sandburst/common/ppc440gx_i2c.c board/sandburst/common/ppc440gx_i2c.h Signed-off-by: Tom Rini <trini@ti.com> 
The sandburst-specific i2c drivers have been deleted, conflict was just
over the SPDX conversion.

Conflicts:
	board/sandburst/common/ppc440gx_i2c.c
	board/sandburst/common/ppc440gx_i2c.h

Signed-off-by: Tom Rini <trini@ti.com>
Add GPL-2.0+ SPDX-License-Identifier to source files 2013-07-24T13:44:38+00:00 Wolfgang Denk wd@denx.de 2013-07-08T07:37:19+00:00 1a4596601fd395f3afb8f82f3f840c5e00bdd57a Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> 
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
i2c: add i2c_core and prepare for new multibus support 2013-07-23T03:54:28+00:00 Heiko Schocher hs@denx.de 2012-01-16T21:12:23+00:00 385c9ef5a7215b2b0c22836fee6c692dfc8559d7 This Patch introduce the new i2c_core file, which holds the I2C core functions, for the rework of the multibus/ multiadapter support. Also adds changes in i2c.h for the new I2C multibus/multiadapter support. This new support can be activated with the CONFIG_SYS_I2C define. Signed-off-by: Heiko Schocher <hs@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Stephen Warren <swarren@wwwdotorg.org> 
This Patch introduce the new i2c_core file, which holds
the I2C core functions, for the rework of the multibus/
multiadapter support.
Also adds changes in i2c.h for the new I2C multibus/multiadapter
support. This new support can be activated with the
CONFIG_SYS_I2C define.

Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>