Age | Commit message (Collapse) | Author |
|
We should not have an arch-specific header file in common.h. Adjust the
board files a little so it is not needed, and drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
We should not have an arch-specific header file in common.h. Instead, use
the asm/hardware.h header to provide the required declarations, and drop
the common.h changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
These declarations should not be in common. Remove those that are not
needed and move the others to an arch-specific location.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These declarations should not be in common.h. Move them to an
arch-specific header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The declarations should not be in common.h. Move them to the arch-specific
headers.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Fixup thinko defined(FSL_LSCH3) -> defined(CONFIG_FSL_LSCH3)]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Set up a new asm/ppc.h header file to hold this arch-specific stuff. It
should not be in common.h. It probably should be refactored to use
asm/arch instead, but that is a job for the maintainer.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These definitions should not be in common.h. Move them to an arch-specific
header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These arch-specific declarations should not be in common.h. Drop them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These arch-specific functions are not needed here.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
With a small tweak we can avoid including these files for all boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Include this header where needed so we do not need to rely on common.h.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
At present common.h includes various ARM-specific headers. In preparation
for dropping this, add a few explicit declarations.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than relying on common.h to provide this include, which is going
away at some point, include it explicitly in each file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
With a few tweaks we can avoid including these files, which are only
needed by two C files.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
With a small fixup to u-boot-x86.h, this is not actually needed anywhere,
so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is not actually needed anywhere, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is not actually needed anywhere, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
This is not actually needed anywhere, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than including this arch-specific header file in common.h, include
it from within nds32's u-boot.h header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than including this arch-specific header file in common.h, include
it from within mips's u-boot.h header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
Rather than including this arch-specific header file in common.h, include
it from within arm's u-boot.h header.
Also drop the comment about something to be fixed. It has been there
forever and it is not clear what it means.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than including this arch-specific header file in common.h, include
it from within x86's u-boot.h header.
Also drop the comment about something to be fixed. It is not clear what
needs fixing.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than including this arch-specific header file in common.h, include
it from within sandbox's u-boot.h header.
Also drop the comment about something to be fixed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than including this arch-specific header file in common.h, include
it from within arc's u-boot.h header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is dead code now. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is not used anymore. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is not used anymore. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is no-longer used in U-Boot. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
This is not used anymore. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This is no longer used in U-Boot. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Put this in its own header instead of using common.h.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These should not be in common.h. Move the to an arch-specific header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Only one board needs this definition. Move it to an arch-specific header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This should not be in common.h. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Only one boards needs this definition. Move it to an arch-specific header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These should not be in common.h. They are used in some legacy PowerPC
code. Just drop them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This should not be in common.h - remove it and update the only file that
needs it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The symbol CONFIG_TI81XX is used for the parts that are common to the
TI816x and TI814x SoCs and are not part of CONFIG_ARCH_OMAP2PLUS nor
CONFIG_AM33XX. It however has so few uses that we can just modify the
code to check for both and drop the symbol. The symbols CONFIG_TI816X
and CONFIG_TI814X are for the repective SoCs.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
- Switch to using <configs/ti_armv7_omap.h> and family. This lets us
drop lots of custom defines.
- Ensure that our default environment uses DEFAULT_LINUX_BOOT_ENV so
that Linux will boot correctly.
- Enable CONFIG_DISTRO_DEFAULTS
- Switch to using CONFIG_OF_CONTROL
- Various other cleanups to match other SoCs in the family line.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This brings in the required dts/dtsi files for the TI8168-EVM from the
Linux Kernel v4.11 release.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The TI8168-EVM comes with NAND on board. Enable it and move environment
over there.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
On this platform, we can trace a general failure to boot to enabling /
disabling this option. When this is enabled, we go off into the
weeds during SPL and are unable to talk with the SD card and
mmc_initialize() fails.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The ti816x/am389x SoC is the first generation in what U-Boot calls the
"am33xx" family. In the first generation of this family the DDR
initialization sequence is quite different from all of the subsequent
generations. Whereas with ti814x (second generation) we can easily work
the minor differenced between that and am33xx (third generation), our
attempts to do this for ti816x weren't sufficient. Rather than add a
large amount of #ifdef logic to make this different sequence work we add
a new file, ti816x_emif4.c to handle the various required undocumented
register writes and sequence and leverage what we can from
arch/arm/mach-omap2/am33xx/ddr.c still. As DDR2 has similar problems
today but I am unable to test it, we drop the DDR2 defines from the code
rather than imply that it works by leaving it. We also remove a bunch
of other untested code about changing the speed the DDR runs at.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Rather than have a long and if check in the Makefile, mark the default
lowlevel_init function as weak (as we do on armv8) so that SoCs can
override it if needed, and it will still be discarded if unused.
Provide a weak s_init as well to allow for this to link and be
discarded.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Any TFTP or DHCP boot on the Davinci OMAP-L138 LCDK board requires
that the 'ethaddr' variable be defined. There are no e-fuses to store
the ethernet mac address for this platform, and neither is a MAC
address reserved in any format. So enable random MAC address support
so that networking boot can be supported.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
Enable distro_bootcmd PXE functions on meson-gxbb systems.
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
|
|
First of all, it's inappropriate to call setup_internal_uart() in a
generic API fsp_init(), as CONFIG_INTERNAL_UART is an option that
is only available on BayTrail platform. Secondly even for BayTrail,
there is no need to call setup_internal_uart() at all, as Intel FSP
will do this for us.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
It was observed that when -DDEBUG is used to generate a debug build,
U-Boot does not boot on MinnowMax board. A workaround is to disable
CONFIG_DEBUG_UART. The real issue is that in order to have the debug
uart to work, BayTrail SoC needs to be configured so that its internal
uart is available to be used as the debug uart.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
At present lpe/lpss-sio/scc FSP properties are all boolean, but in
fact for "enable-lpe" it has 3 possible options. This adds macros
for these options and change the property from a boolean type to
an integer type, and change their names to explicitly indicate what
the property is really for.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|