Add usb ether gadget device with usb_ether_init() when
CONFIG_DM_ETH and CONFIG_USB_ETHER are defined.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add 'Peng Fan' as MAINTAINERS of configs/mx6ull_14x14_evk_plugin_defconfig
which is missing in below commit
"imx: mx6ull_14x14_evk: add plugin defconfig"
(sha1: b90ebf49bb)
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jagan Teki <jagan@openedev.com>
The SPL load address changes based on boot type in HS devices,
ISW_ENTRY_ADDR is used to set this address for AM43xx based SoCs
for similar reasons. Add this same logic for AM33xx devices.
Also make the default value for ISW_ENTRY_ADDR correct for GP
devices based on SoC, HS devices already pick the correct
value in their defconfig.
Signed-off-by: Andrew F. Davis <afd@ti.com>
When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
not generated but generate an unsigned one anyway, first fix this
warning to say that it was generated but not secured.
When the user then exports TI_SECURE_DEV_PKG after getting this warning,
and tries to re-build, 'make' will detect the build artifacts as
unchanged and so assume they do not need to be re-generated. This causes
it to fail to sign the files and it will pack unsigned files into the
final image, even though TI_SECURE_DEV_PKG is now correctly defined and
working.
Fix this by using FORCE on the targets causes them to be re-run even if
the dependent files have not changed.
This then causes another issue. We currently rename the signed dtb files
to overwrite the non-signed ones. We do this so the 'mkimage' tool gives
the packaged dtb sections the correct name. If we do not rename the files
then SPL will not find them during boot.
Fix this by renaming the dtb files by appending _HS to the end of the
filename, after the ".dtb", this causes them to still be named correctly
in the FIT blob.
Signed-off-by: Andrew F. Davis <afd@ti.com>
These two macros are used for the same thing, the total number of DDR
controllers for a given SoC. Use SYS_NUM_DDR_CTRLS in Kconfig and
merge existing usage.
Signed-off-by: York Sun <york.sun@nxp.com>
Use option NUM_DDR_CONTROLLERS in ddr Kconfig and clean up existing
usage in ls102xa and fsl-layerscape. Remove all powerpc macros in
config header and board header files.
Signed-off-by: York Sun <york.sun@nxp.com>
Add option SYS_FSL_ERRATUM_ESDHC111, SYS_FSL_ERRATUM_ESDHC13,
SYS_FSL_ERRATUM_ESDHC135, SYS_FSL_ERRATUM_ESDHC_A001 to mmc Kconfig.
Move existing macros to related Kconfig.
Signed-off-by: York Sun <york.sun@nxp.com>
[trini: Migrate bk4r1]
Signed-off-by: Tom Rini <trini@konsulko.com>
Create driver/ddr/fsl/Kconfig and move existing options. Clean up
existing macros.
Signed-off-by: York Sun <york.sun@nxp.com>
[trini: Migrate sbc8641d, xpedite537x and MPC8536DS, run a moveconfig.py -s]
Signed-off-by: Tom Rini <trini@konsulko.com>
Use TARGET_T1024RDB from Kconfig instead.
Signed-off-by: York Sun <york.sun@nxp.com>
[trini: Get missing hunk in board/freescale/t102xrdb/ddr.c]
Signed-off-by: Tom Rini <trini@konsulko.com>
Instead of define CONFIG_SYS_FSL_SEC_COMPAT in header files for PowerPC
and ARM SoCs, move it to Kconfig under the driver.
Signed-off-by: York Sun <york.sun@nxp.com>
Use Kconfig SYS_PPC_E500_DEBUG_TLB and clean up existing macros.
Signed-off-by: York Sun <york.sun@nxp.com>
[trini: Migrate 8572]
Signed-off-by: Tom Rini <trini@konsulko.com>
SPL from nand will print 'NAND' in boot_from_devices based on
the image_loader name, remove the extra 'NAND ' in mxs_nand_spl driver.
Original behaviour:
-------------------
U-Boot SPL 2017.01-rc2-gf84dd8b (Jan 02 2017 - 22:24:19)
Trying to boot from NANDNAND : 512 MiB
After the fix:
-------------
U-Boot SPL 2017.01-rc2-gf84dd8b-dirty (Jan 02 2017 - 23:17:00)
Trying to boot from NAND: 512 MiB
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Jagan Teki <jagan@openedev.com>
According to Section 11.15.4.9.1 Indirect Read Controller of K2G SoC
TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
data interface reads until the last word of an indirect transfer
So, make sure that QSPI indirect reads are 32 bit sized except for the
final read. If the rxbuf is unaligned then use bounce buffer, so that
readsl() can be used instead of readsb() to avoid non 32-bit accesses.
[1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>
According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
data interface writes until the last word of an indirect transfer
otherwise indirect writes is known to fails sometimes. So, make sure
that QSPI indirect writes are 32 bit sized except for the last write. If
the txbuf is unaligned then use bounce buffer to avoid data aborts.
So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
for all boards that use Cadence QSPI driver.
[1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Now that the SPL is ready to be compiled in AArch64 and the DRAM
init code is ready, enable SPL support for the A64 SoC and in the
Pine64 defconfig.
For now we keep the boot0 header in the U-Boot proper, as this allows
to still use boot0 as an SPL replacement without hurting the SPL use
case.
We disable FEL support for now by making its compilation conditional
and disabling it for ARM64, as the code isn't ready yet.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Fix the output of the DRAM size on AArch64 SPLs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
According to Jens disabling the on-die-termination should set bit 5,
not bit 1 in the respective register. Fix this.
Reported-by: Jens Kuske <jenskuske@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The A64 DRAM controller is very similar to the H3 one,
so the code can be reused with some small changes.
This refactoring does not change the code size for the existing H3 part.
[Andre: rework from #ifdefs to using socid parameters in static
functions, minor fixes, merging in fixes from Jens]
Signed-off-by: Jens Kuske <jenskuske@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
So far the DRAM driver for the H3 SoC (and apparently boot0/libdram as
well) only applied coarse delay line settings, with one delay value for
all the data lines in each byte lane and one value for the control lines.
Instead of setting the delays for whole bytes only allow setting it for
each individual bit. Also add support for address/command lane delays.
For the purpose of this patch the rules for the existing coarse settings
were just applied to the new scheme, so the actual register writes don't
change for the H3. Other SoCs will utilize this feature later properly.
With a stock GCC 5.3.0 this increases the dram_sun8i_h3.o code size from
2296 to 2344 Bytes.
[Andre: move delay parameters into macros to ease later sharing, use
defines for numbers of delay registers, extend commit message]
Signed-off-by: Jens Kuske <jenskuske@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The IOCR registers got renamed to BDLR to match the public
documentation of similar controllers.
Signed-off-by: Jens Kuske <jenskuske@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
So far the MBUS priority setup was done by writing "magic" values taken
from a DRAM controller register dump after a boot0 run.
By peeking at the Linux (sic!) MBUS driver [1] from the Allwinner BSP
kernel, we learned more about the actual meaning of those bits.
Add macros and refactor the setup function to make the MBUS setup much
more readable and meaningful.
The actual values used now are a transformation of the values used
before, which are assembled by the new code to result in the same register
writes. So this rework does not change any settings, also the code size
stays the same.
The respective source files in the BSP kernel had a proper GPL header,
so lifting this code and information into U-Boot is legal.
[Andre: provide a convenience macro to fit definitions on one line]
[1] https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65/drivers/bus/sunxi_mbus.c
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
To avoid enumerating the very same DRAM values in defconfig files
for each and every Allwinner A64 board out there, let's put some sane
default values in the Kconfig file.
Boards with different needs can override them at any time.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The Allwinner A64 SoC starts execution in AArch32 mode, and both
the boot ROM and Allwinner's boot0 keep running in this mode.
So U-Boot gets entered in 32-bit, although we want it to run in AArch64.
By using a "magic" instruction, which happens to be an almost-NOP in
AArch64 and a branch in AArch32, we differentiate between being
entered in 64-bit or 32-bit mode.
If in 64-bit mode, we proceed with the branch to reset, but in 32-bit
mode we trigger an RMR write to bring the core into AArch64/EL3 and
re-enter U-Boot at CONFIG_SYS_TEXT_BASE.
This allows a 64-bit U-Boot to be both entered in 32 and 64-bit mode,
so we can use the same start code for the SPL and the U-Boot proper.
We use the existing custom header (boot0.h) functionality, but restrict
the existing boot0 header reservation to the non-SPL build now. A SPL
wouldn't need such header anyway. This allows to have both options
defined and lets us use one for the SPL and the other for U-Boot proper.
Also add arch/arm/mach-sunxi/rmr_switch.S, which contains the original
ARM assembly code and instructions how to re-generate the encoded
version.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The ENABLE_ARM_SOC_BOOT0_HOOK option is a generic option shared with
other boards. To allow alternative code to be inserted, we create
another, now function specific config symbol on top of it to simplify
later additions. No functional change at this time.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
For prepending some board specific header area to U-Boot images we
were so far including a header file with a macro definition containing
the actual header specification.
This works fine if there are just a few statements and if there is only
one alternative.
However adding more complex code quickly gets messy with this approach,
so let's just drop that intermediate macro and let the #include actually
insert the code directly.
This converts the callers and the callees, but doesn't change anything
at this point.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Steve Rae <steve.rae@raedomain.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The boot0 hook we have so far is applied _after_ the initial branch
to the "reset" entry point. An upcoming change requires even this
branch to be changed, so we apply the hook macro at the earliest
point, and have the branch in the hook file as well.
This is no functional change at this point, just refactoring to simplify
upcoming patches.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>