Age | Commit message (Collapse) | Author |
|
The Raspberry Pi 3 contains a BCM2837 SoC. The BCM2837 is a BCM2836 with
the CPU complex swapped out for a quad-core ARMv8. This can operate in 32-
or 64-bit mode. 32-bit mode is the current default selected by the
VideoCore firmware on the Raspberry Pi 3. This patch adds a 32-bit port of
U-Boot for the Raspberry Pi 3.
>From U-Boot's perspective, the only delta between the RPi 2 and RPi 3 is a
change in usage of the SoC UARTs. On all previous Pis, the PL011 was the
only UART in use. The Raspberry Pi 3 adds a Bluetooth module which uses a
UART to connect to the SoC. By default, the PL011 is used for this purpose
since it has larger FIFOs than the other "mini" UART. However, this can
be configured via the VideoCore firmware's config.txt file. This patch
hard-codes use of the mini UART in the RPi 3 port. If your system uses the
PL011 UART for the console even on the RPi 3, please use the RPi 2 U-Boot
port instead. A future change might determine which UART to use at
run-time, thus allowing the RPi 2 and RPi 3 (32-bit) ports to be squashed
together.
The mini UART has some limitations. One externally visible issue in the
BCM2837 integration is that the UART divides the SoC's "core clock" to
generate the baud rate. The core clock is typically variable, and under
control of the VideoCore firmware for thermal management reasons. If the
VC FW does modify the core clock rate, UART communication will be
corrupted since the baud rate will vary from the expected value. This was
not an issue for the PL011 UART, since it is fed by a fixed 3MHz clock. To
work around this, the VideoCore firmware can be told not to modify the SoC
core clock. However, the only way this can happen and be thermally safe is
to limit the core clock to a low/minimum frequency. This leaves
performance on the table for use-cases that don't care about a UART
console. Consequently, use of the mini UART console must be explicitly
requested by entering the following line into config.txt:
enable_uart=1
A recent version of the VC firmware is required to ensure that the mini
UART is fully and correctly initialized by the VC FW; at least
firmware.git 046effa13ebc "firmware: arm_loader: emmc clock depends on
core clock See: https://github.com/raspberrypi/firmware/issues/572".
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Command parsing and processing code is not needed when the command line is
disabled. Remove this code in that case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
|
|
The Allwinner A64 SoC is used in the Pine64. This patch adds
all bits necessary to compile U-Boot for it running in AArch64
mode.
Unfortunately SPL is not ready yet due to legal problems, so
we need to boot using the binary boot0 for now.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
[agraf: remove SPL code, move to AArch64]
Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
I no longer see the problem claimed in the comment block. Rather,
the 0.5 msec timeout seems too short for some TFTP servers.
Drop the CONFIG_ARM_TIMEOUT to fall back to the 5 sec timeout.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
These defined were used for pre-DM ns16550 serial driver. They are
unneeded because UniPhier SoCs now use DM serial.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
This command would be useful to update U-Boot images in SRAM.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Commit d085ecd61b99 ("ARM: uniphier: switch to raw U-Boot image")
claimed that u-boot-with-spl.bin would be useful in its commit log,
but it was not available because the commit missed to define
CONFIG_SPL_MAX_SIZE. Without it, CONFIG_SPL_PAD_TO is not defined
either (see include/config_fallbacks.h). So, the SPL image is not
padded correctly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The A83T has 3 USB PHYs: 1 for USB OTG, 1 for standard USB 1.1/2.0 host,
1 for USB HSIC.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
The FLDOs on AXP818 PMIC normally provide power to CPUS and USB HSIC PHY
on the A83T/H8.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
AXP818 supports VBUS drive function, even though the manual does not
mention it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
VBUS drive is supported on AXP221 and later PMICs. Rework the macros
so we can support this on later PMICs without too much work.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
axp818_init() is declared, but never defined.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
This patch enable VID support for ls2080ardb platform.
It uses the common VID driver.
Signed-off-by: Rai Harninder <harninder.rai@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
Use a pointer to pass image address to fsl_secboot_validate(),
instead of using environmental variable "img_addr".
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Saksham Jain <saksham.jain@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
In case of fatal failure during secure boot execution (e.g. header
not found), reset is asserted to stop execution. If the RESET_REQ
is not tied to HRESET, this allows the execution to continue.
Add esbh_halt() after the reset to make sure execution stops.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Saksham Jain <saksham.jain@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
For secure boot, currently we were using fixed bootargs for all SoCs.
This is not needed and we can use the bootargs which are used in
non-secure boot.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Saksham Jain <saksham.jain@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
To unify steps for secure boot for xip (eg. NOR) and non-xip memories
(eg. NAND, SD), bootscipts and its header are copied to main memory.
Validation and execution are performed from there.
For other ARM Platforms (ls1043 and ls1020), to avoid disruption of
existing users, this copy step is not used for NOR boot.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Saksham Jain <saksham.jain@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
Sec_init has been called at the beginning to initialize SEC Block
(CAAM) which is used by secure boot validation later for both ls2080a
qds and rdb. 64-bit address in ESBC Header has been enabled. Secure
boot defconfigs are created for boards (NOR boot).
Signed-off-by: Saksham Jain <saksham.jain@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
For secure boot, a header is used to identify key table, signature
and image address. A new header structure is added for lsch3.
Currently key extension (IE) feature is not supported. Single key
feature is not supported. Keys must be in table format. Hence, SRK
(key table) must be present. Max key number has increase from 4 to
8. The 8th key is irrevocable. A new barker Code is used.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Saksham Jain <saksham.jain@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
In LS2080, SFP has version 3.4. It is in little endian. The base
address is 0x01e80200. SFP is used in Secure Boot to read fuses.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Saksham Jain <saksham.jain@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
It speeds up loading kernel from SD or USB a lot.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
|
|
Tested with OHCI and pxafb drivers - no issues found
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
|
|
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
|
|
3rd port can be used as a device or host.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
|
|
zipitz2 supports DT boot since linux-4.4 (not mainlined yet)
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
|
|
z2's screen is rotated by 270 degrees
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
|
|
zipitz2 was dropped in 49d8899ba9c26335e4a12e01c18028fc5e40c796
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
|
|
The RPi3 typically uses the regular UART for high-speed communication with
the Bluetooth device, leaving us the mini UART to use for the serial
console. Add support for this UART so we can use it.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
|
|
Some TI boards (e.g. IDK) have 4 to 6 ethernet ports and
this function is handy at board.c to configure the
MAC address of the ports.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Currently, CONFIG_BCM2835 is defined for all BCM283x builds and _BCM2836
is defined when building for that SoC. That means there isn't a single
define that means "exactly BCM2835". This will complicate future patches
where BCM2835-vs-anything-else needs to be determined simply.
Modify the code to define one or the other of CONFIG_BCM2835/BCM2836 so
future patches are simpler.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Now that we have support for running with caches enabled in HYP mode,
opt in to that on the Raspberry Pi 2. This brings a significant performance
boost.
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
The EFI standard defines a simple boot protocol that an EFI payload can use
to access video output.
This patch adds support to expose exactly that one (and the mode already in
use) as possible graphical configuration to an EFI payload.
With this, I can successfully run grub2 with graphical output.
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
This patch enables embedded flash for stm32f746 discovery board.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
|
|
Same flash driver can be used by other stm32 families like stm32f7.
Better place for this driver would be mtd driver location.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
|
|
The description was borrowed from kernel. "tristate" type was changed
to "bool" (I believe we don't support modules for u-boot yet, right?).
CONFIG_USB_GADGET requires CONFIG_USB to be defined too, so add it along
as well.
Definitions were added to defconfig files in a way that
"make savedefconfig" generates exactly the same file as used defconfig.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
[trini: Add zynq_zc702 conversion]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
|
|
Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
|
|
This patch adds support for Altera StratixV bitstream programming. 2 FPGAs
are connected to the SPI busses. This patch uses board specific write
code to program the bitstream via SPI direct write mode.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
This patch adds support for programming of the StratixV FPGAs. Programming
is done in this case (board theadorable) via SPI. The board may provide
board specific code for bitstream programming.
This StratixV support will be used by the theadorable board.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
Commit 1e3d640316 (ARM: sheevaplug: redefine MTDPARTS) changed the partition
layout (without any description why), but didn't change the offset/size to
load the kernel from or the root=/dev/mtdblockX in the bootargs.
The 3MB forseen for a kernel is furthermore too little. A 4.4 build of
mvebu_v5_defconfig is 3.6MB:
-rw-r--r-- 1 peko peko 3.6M Jan 16 20:24 uImage.kirkwood-sheevaplug
When device tree support for sheevaplug was added to the kernel in commit
ee514b381e (ARM: Kirkwood: Add dts files for Sheevaplug and eSATA
Sheevaplug) a default flash partition layout (used if mtdparts= isn't passed
on the command line / CONFIG_MTD_CMDLINE_PARTS isn't enabled) with 1MB for
u-boot / environment, 4MB for the kernel and the rest for the rootfs, so use
that layout here and adjust the kernel loading to match.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
|
|
Enable building of drivers/net/phy/realtek.c so that realtek phys
get properly initialized.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
|
|
This commit syncs the dt-bindings/input/* headers with the kernel (v4.5)
and adds dt-bindings/clock/sun4i-a10-pll2.h, both are necessary for newer
sunxi dts files to build.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
|
|
Now everything is done to load a raw U-Boot proper image instead of
an mkimage-processed one (as far as I tested on NAND, eMMC, NOR).
The SPL already knows the load address of the U-Boot proper without
parsing its uImage header because the load address is defined by
CONFIG_SYS_TEXT_BASE, assuming that the two images are generated from
the same build.
My main motivation of this switch is to use u-boot-with-spl.bin, a
concatenation of u-boot-spl.bin and u-boot.bin. (I wish there were
a concatenation of u-boot-spl.bin and u-boot.img...) Anyway, this
commit would be useful for one-shot image burn.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
This allows to boot from NOR flash (or SRAM) with help of an external
loader (NOR-loader).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The current CONFIG names like "CONFIG_ARCH_UNIPHIER_PH1_PRO4" is too
long. It would not hurt to drop "PH1_" because "UNIPHIER_" already
well specifies the SoC family. Also, rename files for consistency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
This comment line is telling the opposite of the logic.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|