Marek Vasut [Mon, 9 Apr 2018 18:47:31 +0000 (20:47 +0200)]
mmc: matsushita-common: Wait for command completion
Make sure to wait for the command to complete altogether, including
the trailing 8 clock cycles. This prevents the driver for accidentally
writing the CMD register too fast before the previous command fully
completed.
Marek Vasut [Mon, 9 Apr 2018 18:47:31 +0000 (20:47 +0200)]
mmc: matsushita-common: Special case only select registers in 16bit
There are only a few registerse used in the 16bit mode which are
32bit internally. Special-case only those in the IO accessors and
always write both halves. Any other register access is protected
from accidentally overwriting neighboring register.
Marek Vasut [Sat, 23 Sep 2017 11:01:20 +0000 (13:01 +0200)]
mmc: matsushita-common: Always check controller version
Handle the controller version even if quirks are set. The controller in
Renesas Gen3 SoCs does provide the version register, which indicates a
controller v10 and the controller does support internal DMA and /1024
divider.
Marek Vasut [Tue, 2 Jan 2018 18:40:49 +0000 (19:40 +0100)]
mmc: matsushita-common: Handle DMA completion flag differences
The DMA READ completion flag position differs on Socionext and Renesas
SoCs. It is bit 20 on Socionext SoCs and using bit 17 is a hardware bug
and forbidden. It is bit 17 on Renesas SoCs and bit 20 does not work on
them.
Marek Vasut [Tue, 26 Sep 2017 18:34:35 +0000 (20:34 +0200)]
mmc: matsushita-common: Handle Renesas div-by-1
On the Renesas version of the IP, the /1 divider is realized by
setting the clock register [7:0] to 0xff instead of setting bit
10 of the register. Check the quirk and handle accordingly.
Marek Vasut [Sun, 8 Apr 2018 16:49:52 +0000 (18:49 +0200)]
mmc: matsushita-common: Add Renesas RCar quirks
Add a quirk to identify that the controller is Renesas RCar variant
of the Matsushita SD IP and another quirk indicating it can support
Renesas RCar HS200/HS400/SDR104 modes.
Marek Vasut [Sun, 8 Apr 2018 16:14:22 +0000 (18:14 +0200)]
mmc: renesas-sdhi: Handle 16bit IP
The Renesas RCar Gen2 chips have a mix of 32bit and 16bit variants
of the IP. There is no DT property which allows discerning those,
so what Linux does is it checks the size of the register area and
if it is 0x100, the IP is 16bit, otherwise the IP is 32bit. Handle
the distinction the same way.
Marek Vasut [Sun, 8 Apr 2018 15:45:23 +0000 (17:45 +0200)]
mmc: uniphier: Allow passing quirks to the probe function
Certain instances of the SD IP require more elaborate digging
in the DT to figure out which variant of the SD IP is in use.
Allow explicit passing of the quirks into the probe function.
Marek Vasut [Sun, 8 Apr 2018 15:41:14 +0000 (17:41 +0200)]
mmc: uniphier: Add support for 16bit variant
Add support for 16bit mutation of the Matsushita SD IP. Since some
registers are internally 32bit, the matsu_sd_{read,write}l() has
to special-case this 16bit variant a bit.
Marek Vasut [Sun, 8 Apr 2018 15:25:49 +0000 (17:25 +0200)]
mmc: uniphier: Drop useless check
Drop useless check in matsu_sd_{read,write}q(), this is only ever
called to read the data from FIFO and only when 64bit variant of
the block is used anyway.
Marek Vasut [Sun, 8 Apr 2018 15:14:42 +0000 (17:14 +0200)]
mmc: uniphier: Factor out FIFO accessors
Add macros to generate the FIFO accessors, since the code is almost
the same with only minor differences. This is done in preparation
for adding 16bit variant of the IP.
Marek Vasut [Sun, 8 Apr 2018 13:22:58 +0000 (15:22 +0200)]
mmc: uniphier: Split out SoC specific bits from the driver
Factor out common code from the uniphier SD driver, change the prefix
of the functions from uniphier_sd_ to matsu_sd_ and create separate
renesas-sdhi.c driver. Thus far, all the code is still compiled when
CONFIG_UNIPHIER_MMC is selected and there is no functional change.
This patch is a preparation for further split of the SoC specific
parts of the Matsushita SD driver, used both on Uniphier and R-Car.
Marek Vasut [Sat, 7 Apr 2018 14:16:30 +0000 (16:16 +0200)]
ARM: rmobile: Add JTAG recovery support for M2 Porter
Add JTAG recovery support into the M2 Porter TPL. This allows the
TPL to be loaded over JTAG, initialize the system, wait for the
JTAG debugger to load U-Boot image into RAM and then resume and
start U-Boot from RAM.
The procedure is as follows:
1) Load u-boot-tpl.bin to 0xe6300000
2) Write magic number 0x1337c0de to 0xe6300020
TPL checks for this particular magic and starts JTAG recovery
if this number is present. This is not present by default.
3) Start U-Boot TPL from 0xe6300000
4) Wait for a message from TPL on UART indicating JTAG boot:
"JTAG boot detected!"
5) Halt the system in JTAG debugger
6) Load U-Boot image (u-boot.img) to 0x4fffffc0
7) Write magic number 0xb33fc0de to 0xe6300024
TPL checks for this particular magic to verify that the U-Boot
image was loaded into DRAM by the JTAG debugger.
8) Resume the system in JTAG debugger
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Marek Vasut [Tue, 3 Apr 2018 10:52:48 +0000 (12:52 +0200)]
ARM: rmobile: Add TPL support on R8A7791 M2 Porter
Add and enable TPL on M2 Porter. The TPL must fit into 16 kiB due
to the Gen2 BootROM restriction. The TPL is running from MERAM and
is capable of performing the initial initialization of PFC, Clock,
GPIO, LBSC, DBSC and QSPI NOR. DBSC is responsible for bringing up
the DDR DRAM access. The TPL is capable of loading the next stage,
U-Boot, from either SPI NOR or UART as a fallback. If either does
provide a valid U-Boot uImage, the system stops, which allows the
operator to load U-Boot ie. via JTAG and start it manually.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Marek Vasut [Sat, 7 Apr 2018 15:03:28 +0000 (17:03 +0200)]
spl: ram: Convert to CONFIG_IS_ENABLED
This patch is a preparation for adding TPL support for RAM loading.
CONFIG_IS_ENABLED allows for proper handling of the U-Boot/SPL/TPL
differences in config symbol names.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Marek Vasut [Sat, 7 Apr 2018 14:06:36 +0000 (16:06 +0200)]
ARM: Fix Makefile during SPL and TPL build
The tiny variants of memset and memcpy implementations can be
built for TPL as well, check whether a TPL build is in progress
and avoid including the default variants.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Marek Vasut [Sat, 7 Apr 2018 14:06:22 +0000 (16:06 +0200)]
serial: Fix Makefile during SPL and TPL build
This patch fixes a situation where CONFIG_DM_SERIAL is enabled for
regular U-Boot and SPL, but not for TPL. In that case, the build
will try to include serial-uclass into the TPL nonetheless, because
CONFIG_DM_SERIAL is set.
The solution is to check if the build is for SPL or TPL and in that
case, check if CONFIG_$(SPL_TPL_)DM_SERIAL is also set. Only in that
case, include serial-uclass.c . If the build is for regular U-Boot,
CONFIG_BUILD is not set, so only check if CONFIG_DM_SERIAL is set
and if so, include serial-uclass.c
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
The mutex lock and unlock functions are stubbed out and mutex_is_locked
was 0. This caused asserts to fail in ubifs code when checking that the
mutex was locked. For example,
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
Assume that the "mutex" is locked since that is the normal case when it
is checked in the ubifs code.
Neil Armstrong [Tue, 3 Apr 2018 09:40:51 +0000 (11:40 +0200)]
reset: add sandbox test for bulk API
This patch adds the bulk reset API tests for the sandbox test suite.
Unlike the main test, it also check the "other" reset signal using the bulk API
and checks if the resets are correctly asserted/deasserted.
To allow the bulk API to work, and avoid changing the DT, the number of resets
of the sandbox reset controller has been bumped to 101 for the "other" reset
line to be valid.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Guillaume GARDET [Fri, 30 Mar 2018 08:28:19 +0000 (10:28 +0200)]
mkimage: do not fail if there is no print_header function
Commit 253c60a breaks the exit value of 'mkimage -T rkimage'
and print the following error:
mkimage: Can't print header for Rockchip Boot Image support: Success
It is not a failure to not print headers, so just display the warning message,
and finish the function properly.
Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Neil Armstrong [Thu, 29 Mar 2018 12:56:02 +0000 (14:56 +0200)]
serial: meson: Update compatible with new Linux bindings
The Amlogic Meson SoCs serial bindings were not written when serial
support was pushed into Linux and U-Boot.
A clean bindings document has been merged into Linux tree to correctly
handle the multiple clocks feeding the serial peripheral.
This update the U-Boot serial_meson driver with the new compatible
string for Amlogic Meson GX Socs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Mon, 9 Apr 2018 15:05:44 +0000 (11:05 -0400)]
Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot
Patch queue for efi - 2018-04-09
Highlights this time around:
- Lots of minor spec compliance fixes
- Support full range of GOP BLT commands
- More fine grained error checking
- Network fixes (init, DP)
- Lots of other bug fixes...
Luca Ceresoli [Mon, 12 Mar 2018 16:18:38 +0000 (17:18 +0100)]
arm64: zynqmp: Enable booting to ATF
U-Boot is now able to boot to ARM Trusted Firmware (ATF). The boot
flow is SPL(EL3) loads ATF and full u-boot and jump to ATF(EL3) which
pass control to full u-boot(EL2). This has been tested on zcu106, so
enable it in this defconfig.
To generate an image that triggers this booting flow, you need to pass
'-O arm-trusted-firmware' to mkimage.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
net: phy: xilinx_phy: Read phytype using property xlnx,phy-type
This patch reads phytype from property "xlnx,phy-type" instead
od simply looking for "phy-type". This is to be inline with
Linux and also fixes the issue of detecting it wrongly in
u-boot.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Vipul Kumar [Sat, 10 Mar 2018 12:22:23 +0000 (17:52 +0530)]
nand: arasan_nfc: Fixed NAND write issue
In commit 2453c695185f ("arm64: zynqmp: nand: Fixed NAND erase issue for
size 1GiB or more"), ARASAN_NAND_MEM_ADDR1_PAGE_MASK macro changed
to 0xFFFF and the same macro is used in nand write and so that getting
nand write error.
This patch reverted this macro to the 0xFFFF0000 and used
ARASAN_NAND_MEM_ADDR1_COL_MASK in the nand erase function
which is equal to 0xFFFF.
Signed-off-by: Vipul Kumar <vipulk@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
There is delay needed after PCFG_PROGB change if
AES key source is efuse. This fixes the issue of
encrypted bitstream loading with AES efuse as key
source.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
ARM: dts: zynq: Add generic compatible string for I2C EEPROM
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.
So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Tue, 27 Mar 2018 12:31:42 +0000 (14:31 +0200)]
arm: zynq: Remove 0x prefixes from cc108
The patch fixing issues reported by DTC:
zynq-cc108.dtb: Warning (unit_address_format): Node
/amba/spi@e000d000/flash@0/partition@0x400000 unit name should not have
leading "0x"
zynq-cc108.dtb: Warning (unit_address_format): Node
/amba/spi@e000d000/flash@0/partition@0x800000 unit name should not have
leading "0x"
zynq-cc108.dtb: Warning (unit_address_format): Node
/amba/spi@e000d000/flash@0/partition@0xc00000 unit name should not have
leading "0x"
zynq-cc108.dtb: Warning (unit_address_format): Node
/amba/spi@e000d000/flash@0/partition@0xd00000 unit name should not have
leading "0x"
zynq-cc108.dtb: Warning (unit_address_format): Node
/amba/spi@e000d000/flash@0/partition@0xf00000 unit name should not have
leading "0x"
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
efi_loader: correctly set the machine type in the PE header
The portable executable header has a field describing the machine type.
The machine type should match the binary. So on i386 we should use
IMAGE_FILE_MACHINE_I386 and on x86_64 we should use
IMAGE_FILE_MACHINE_AMD64. The actual value is issued by the objcopy
command invoked in scripts/Makefile.lib in depdendence of the value of
EFI_TARGET.
The value is used both for EFI_STUB and for EFI_LOADER.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
Cc: Michal Simek <michal.simek@xilinx.com> Cc: Michal Simek <monstr@monstr.eu> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
projects / u-boot.git / log