i2c: Drop use of CONFIG_I2C_HARD

This option is pretty old. It predates CONFIG_SYS_I2C which is itself
deprecated in favour of driver model. Disable it for all boards.

Also drop I2C options which d

i2c: Drop use of CONFIG_I2C_HARD

This option is pretty old. It predates CONFIG_SYS_I2C which is itself
deprecated in favour of driver model. Disable it for all boards.

Also drop I2C options which depend on this.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

board_f: Rename initdram() to dram_init()

This allows us to use the same DRAM init function on all archs. Add a
dummy function for arc, which does not use DRAM init here.

Signed-off-by: Simon Glass

board_f: Rename initdram() to dram_init()

This allows us to use the same DRAM init function on all archs. Add a
dummy function for arc, which does not use DRAM init here.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Dummy function on nios2]
Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...

powerpc: Move setup_board_extra() into a PPC file

We don't need this PPC-specific function in generic code. Move it to
the powerpc directory.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-

powerpc: Move setup_board_extra() into a PPC file

We don't need this PPC-specific function in generic code. Move it to
the powerpc directory.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

Move dram_init_banksize() to a common header

This is an weak function present on all archs so we should have it in the
common header file. Remove it from arch-specific headers and add a
function com

Move dram_init_banksize() to a common header

This is an weak function present on all archs so we should have it in the
common header file. Remove it from arch-specific headers and add a
function comment.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

board_f: Drop return value from initdram()

At present we cannot use this function as an init sequence call without a
wrapper, since it returns the RAM size. Adjust it to set the RAM size in
global_d

board_f: Drop return value from initdram()

At present we cannot use this function as an init sequence call without a
wrapper, since it returns the RAM size. Adjust it to set the RAM size in
global_data instead, and return 0 on success.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: Drop board_type parameter from initdram()

It looks like only cm5200 and tqm8xx use this feature, so we don't really
need it in generic code. Drop it and have the users access gd->board_type

board_f: Drop board_type parameter from initdram()

It looks like only cm5200 and tqm8xx use this feature, so we don't really
need it in generic code. Drop it and have the users access gd->board_type
directly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: powerpc: Make prt_8260_rsr(), prt_8260_clks() private

Move these two function calls into checkcpu(), which is called on this
arch immediately after these two.

Signed-off-by: Simon Glass <s

board_f: powerpc: Make prt_8260_rsr(), prt_8260_clks() private

Move these two function calls into checkcpu(), which is called on this
arch immediately after these two.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: powerpc: Move prt_83xx_rsr() to private code

This function is called just before checkcpu() on MPX83xx. Move it to the
code for that arch.

Signed-off-by: Simon Glass <sjg@chromium.org>

board_f: powerpc: Use timer_init() instead of init_timebase()

There is no good reason to use a different name on PowerPC. Change it to
timer_init() like the others.

Signed-off-by: Simon Glass <sjg@

board_f: powerpc: Use timer_init() instead of init_timebase()

There is no good reason to use a different name on PowerPC. Change it to
timer_init() like the others.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: Remove adjust_sdram_tbs_8xx() from the init sequence

We can just call this from the only place that needs it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@de

board_f: Remove adjust_sdram_tbs_8xx() from the init sequence

We can just call this from the only place that needs it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: Remove sdram_adjust_866() from the init sequence

We can just call this from the only function that needs it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@den

board_f: Remove sdram_adjust_866() from the init sequence

We can just call this from the only function that needs it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: powerpc: Rename get_clocks_866() to get_clocks()

We really don't need to have a name like this in the generic init
sequence. Use the generic get_clocks() name so that we can merge these
two

board_f: powerpc: Rename get_clocks_866() to get_clocks()

We really don't need to have a name like this in the generic init
sequence. Use the generic get_clocks() name so that we can merge these
two at some point.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

board_f: x86: Rename x86_fsp_init() to arch_fsp_init()

While x86 is the only user and this could in principle be moved to
arch_cpu_init() there is some justification for this being a separate
call.

board_f: x86: Rename x86_fsp_init() to arch_fsp_init()

While x86 is the only user and this could in principle be moved to
arch_cpu_init() there is some justification for this being a separate
call. It provides a way to handle init which is not CPU-specific, but
must happen before the CPU can be set up.

Rename the function to be more generic.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

show more ...

Blackfin: Remove

The architecture is currently unmaintained, remove.

Cc: Benjamin Matthews <mben12@gmail.com>
Cc: Chong Huang <chuang@ucrobotics.com>
Cc: Dimitar Penev <dpn@switchfin.org>
Cc: Haita

Blackfin: Remove

The architecture is currently unmaintained, remove.

Cc: Benjamin Matthews <mben12@gmail.com>
Cc: Chong Huang <chuang@ucrobotics.com>
Cc: Dimitar Penev <dpn@switchfin.org>
Cc: Haitao Zhang <hzhang@ucrobotics.com>
Cc: I-SYST Micromodule <support@i-syst.com>
Cc: M.Hasewinkel (MHA) <info@ssv-embedded.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Martin Strubel <strubel@section5.ch>
Cc: Peter Meerwald <devel@bct-electronic.com>
Cc: Sonic Zhang <sonic.adi@gmail.com>
Cc: Valentin Yakovenkov <yakovenkov@niistt.ru>
Cc: Wojtek Skulski <info@skutek.com>
Cc: Wojtek Skulski <skulski@pas.rochester.edu>
Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...

dm: Add callback to modify the device tree

Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added

dm: Add callback to modify the device tree

Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added to the main board's busses, e.g. I2C.

The device tree support for such boards would either, quite naturally,
employ the overlay mechanism to add such chips to the tree, or would use
one large default device tree, and delete the devices that are actually
not present.

Regardless of approach, even on the U-Boot level, a modification of the
device tree is a prerequisite to have such modular families of boards
supported properly.

Therefore, we add an option to make the U-Boot device tree (the actual
copy later used by the driver model) writeable, and add a callback
method that allows boards to modify the device tree at an early stage,
at which, hopefully, also the application of device tree overlays will
be possible.

Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>

show more ...

Merge git://www.denx.de/git/u-boot-marvell

This mainly adds support for some new boards, like the ARMv8 community
boards MACCHIATOBin and ESPRESSBin

dm: Add callback to modify the device tree

Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added

dm: Add callback to modify the device tree

Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added to the main board's busses, e.g. I2C.

The device tree support for such boards would either, quite naturally,
employ the overlay mechanism to add such chips to the tree, or would use
one large default device tree, and delete the devices that are actually
not present.

Regardless of approach, even on the U-Boot level, a modification of the
device tree is a prerequisite to have such modular families of boards
supported properly.

Therefore, we add an option to make the U-Boot device tree (the actual
copy later used by the driver model) writeable, and add a callback
method that allows boards to modify the device tree at an early stage,
at which, hopefully, also the application of device tree overlays will
be possible.

Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>

show more ...

Drop CONFIG_CMD_DOC

This is not used in U-Boot, and the only usage calls a non-existent
function. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Drop the static inline print_cpuinfo()

This is only called from one place and the function cannot be inlined.
Convert it to a normal function.

Signed-off-by: Simon Glass <sjg@chromium.org>

powerpc: Drop probecpu() in favour of arch_cpu_init()

To avoid an unnecessary arch-specific call in board_init_f(), rename this
function.

Signed-off-by: Simon Glass <sjg@chromium.org>

status_led: Kconfig migration

Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.

TBD: Move a

status_led: Kconfig migration

Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.

TBD: Move all of the definitions in the include/status_led.h to the
relevant board's defconfig files.

Tested boards: CL-SOM-AM57x, CM-T335

Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>

show more ...

time: move timer APIs to include/time.h

The include/common.h is a collection of unrelated declarations,
macros, etc.

It is horrible to include such a cluttered header just for some
timer functions.

time: move timer APIs to include/time.h

The include/common.h is a collection of unrelated declarations,
macros, etc.

It is horrible to include such a cluttered header just for some
timer functions. Split out timer functions into include/time.h.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

delay: collect {m, n, u}delay declarations to include/linux/delay.h

Currently, mdelay() and udelay() are declared in include/common.h,
while ndelay() in include/linux/compat.h. It would be nice to

delay: collect {m, n, u}delay declarations to include/linux/delay.h

Currently, mdelay() and udelay() are declared in include/common.h,
while ndelay() in include/linux/compat.h. It would be nice to
collect them into include/linux/delay.h like Linux.

While we are here, fix the ndelay() implementation; I used the
DIV_ROUND_UP() instead of (x)/1000 because it must wait *longer*
than the given period of time.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-sunxi

move UL() macro from armv8/mmu.h into common.h

The UL() macro is pretty useful in sharing constants between assembly
and C files while still being able to specify a type for C.
Move the macro from a

move UL() macro from armv8/mmu.h into common.h

The UL() macro is pretty useful in sharing constants between assembly
and C files while still being able to specify a type for C.
Move the macro from an armv8 specific header into a common header file
to be able to use it by arm code (for instance) as well.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>

show more ...