Sync DT bindings from kernel DT and move them to out of -u-boot.dtsi
files.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Update driver to use static PSIL endpoint Data instead of DT. This will
allow DT bindings to be in sync with kernel's DT.
Note that this patch breaks networking and OSPI boot as driver changes
are not backward compatible with existing DT. Subsequent commit will
update the DT to make it compatible with updated driver.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Much of PSIL endpoint configuration for a given SoC can be known at
compile time, therefore pass them for platform specific data instead of
DT.
Add per SoC's specific PSIL endpoint data. This is to bring driver in
sync with upstream DT.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Now that commit 3e57f879ee ("mtd: nand: raw: denali: Assert reset
before deassert") added the reset assertion, this code in the board
file is unneeded.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Fixed delay 200us is not working in certain platforms. Change to
poll for reset completion status to have more reliable reset process.
Controller will set the rst_comp bit in intr_status register after
controller has completed its reset and initialization process.
Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Radu Bacrau <radu.bacrau@intel.com>
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Always put the controller in reset, then take it out of reset.
This is to make sure controller always in reset state in both SPL and
proper Uboot.
This is preparation for the next patch to poll for reset completion
(rst_comp) bit after reset.
Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Radu Bacrau <radu.bacrau@intel.com>
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This UART controller is integrated with a FIFO. Enable it.
You can put the next character into the FIFO while the transmitter
is sending out the current character. This works slightly faster.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Ensure the transmitter is empty when chaining the baudrate or any
hardware settings. If a character is remaining in the transmitter,
the console will be garbled.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
After all, I am not a big fan of using a structure to represent the
hardware register map.
You do not need to know the entire register map.
Add only necessary register macros.
Use FIELD_PREP() instead of maintaining a pair of shift and mask.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now that this directory contains only uniphier_sbc_boot_is_swapped(),
move it to boot-device.c and delete the sbc/ directory entirely.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Since commit 1517126fda ("ARM: uniphier: select DM_ETH"), DM-based
drivers/net/smc911x.c is compiled, but it is never probed because the
parent node lacks the DM-based driver.
I need a skeleton driver to populate child devices (but the next commit
will move more hardware settings to the this driver).
I put this to drivers/bus/uniphier-system-bus.c because this is the
same path as the driver in Linux kernel.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I actually do not see this used these days because eMMC or NAND is used
for non-volatile devices. Dump the burden to maintain this crappy code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This was used by the old sLD3 SoC, the support of which was removed
by commit 00aa453ebf ("ARM: uniphier: remove sLD3 SoC support").
There is no more user of this function.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the supports for the following two ARMv7 SoC groups
are exclusive, because the boot ROM loads the SPL to a different
address:
- LD4, sLD8 (SPL is loaded at 0x00040000)
- Pro4, Pro5, PXs2, LD6b (SPL is loaded at 0x00100000)
This limitation exists only when CONFIG_SPL=y.
Instead of using crappy CONFIG options, checking SPL and SPL_TEXT_BASE
is cleaner.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I increased the maximum U-Boot proper size from time to time, but
configs/uniphier_v7_defconfig hit the current limit 832KB.
Some historical info:
In the initial support, the max size was 512MB.
Commit 58d702274c ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN")
increased it to 576KB, and commit 3ce5b1a8d8 ("ARM: uniphier: move
SPL stack address") moved the SPL stack location to avoid the memory
map conflict. It was the solution to increase the size without changing
the NOR boot image map.
commit 1a4bd3a095 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN
again") ended up with increasing the max size again, breaking the NOR
boot image map. The limit was set to 832KB, otherwise the SPL stack
would overwrite the U-Boot proper image:
CONFIG_SPL_STACK - CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header) = 0xd0000
To increase CONFIG_SYS_MONITOR_LEN even more, the SPL stack must be
moved somewhere. I put it back to the original location prior to
commit 3ce5b1a8d8.
With this change, there is no more practical size limit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This reverts commit 45f41c134b.
This weird workaround was the best I came up with at that time
to boot U-Boot from TF-A.
I noticed U-Boot successfully boots on LD20 (i.e. CA72 CPU) by using
the latest TF-A.
Specifically, since the following TF-A commit, U-Boot runs at EL2
instead of EL1, and this issue went away as a side-effect.
|commit f998a052fd94ea082833109f25b94ed5bfa24e8b
|Author: Masahiro Yamada <yamada.masahiro@socionext.com>
|Date: Thu Jul 25 10:57:38 2019 +0900
|
| uniphier: run BL33 at EL2
|
| All the SoCs in 64-bit UniPhier SoC family support EL2.
|
| Just hard-code MODE_EL2 instead of using el_implemented() helper.
|
| Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0
| Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
However, if I reverted that, this problem would come back, presumably
because some EL1 code in U-Boot triggers this issue.
Now that commit f8ddd8cbb5 ("arm64: issue ISB after updating system
registers") fixed this issue properly, this weird workaround is no
longer needed irrespective of the exception level at which U-Boot runs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
patman support for Python3 on Ubuntu 14.04
new checkpatch check to avoid #ifdefs
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl8InaQRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreazvAgAgqyvPY2o+BNHscrx9/6sEOHSAVty/D5t
SdaphzRezlJOWy9MC/ZyqyevZjogN7fgGNQVgh/I4BklIc/N5Omn68/+JWylSFVP
taJKiJD1IVSThTXGOMTxlDiTxY7NfVDUDjtFIpCDswBrnSJlX+2v/RsehUwVIrYn
NJwiRXd33IdS1vh1mqqNgwbZNBo+zGWn5LApq71vLSVkiQlmcpMG9FmYYRcg/AhG
3Xd2HB2ANcvb13fMMcwd3s4WPNYoiJvwjSHScNDUPEip7XeZNDiNeq4gC6d2Uw+J
zC3/vOCP3eRtAnr6syJ5QcGN/eeKwLtnTE+fOuOm6s5Y98po4iMykA==
=3fC5
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-10jul20' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm
of-platdata: better phandle and compatible-string support
patman support for Python3 on Ubuntu 14.04
new checkpatch check to avoid #ifdefs
Call pytest3 with argument -ra to display the reason why Python tests are
skipped.
The -r flag displays a test summary info for each test. -ra eliminates
this info for passed tests.
Pros an cons were discussed in:
https://lists.denx.de/pipermail/u-boot/2020-June/417090.html
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff800000 CPU virtual address.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
On build with 32 bit, there is a warning for int-to-pointer-cast.
Fix the int to pointer cast by using uintptr_t.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Provide function for setting arbitrary virtual-physical MMU mapping
and cache settings for the given region.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update the comments in include/asm/system.h to the common style.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move ADDR_MAP related config options from include/configs/*.h to the
proper place in lib/Kconfig. This has been done using
./tools/moveconfig.py and manual inspection of the generated changes.
This is a preparation to use ADDR_MAP helper on ARM 32bit Raspberry Pi4
board for mapping the PCIe XHCI MMIO, which is above the 4GiB identity
mapping limit.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Supporting USB keyboards out of the box is both handy for development
and production. Notably if u-boot is used to boot into GRUB.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[mb: drop rpi_4_32b_defconfig hunk]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[mb: squash fix to only build xhci_reset_hw() if CONFIG_DM_BUS]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
This is required in order to access the reset controller used to
initialize the board's xHCI chip.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
This patch adds basic driver PCI Express controller found on Broadcom
set-top-box SoCs, e.g. BCM2711.
The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
handling removed. The inbound access memory region is not currently
parsed from dma-ranges DT property and a fixed 3GB region is used.
The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
USB Host Controller.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
e7d4a95da86e0 "bitfield: fix *_encode_bits()",
37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[mb: squash fix including byteorder.h]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
All SPI drivers are converted to DM_SPI but 3 drivers
still operate in nondm mode for SPL due to footprint
constraints.
Update the migration status for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Drop the nondm code from kirkwood_spi.c since there
is no board or any other code using for it.
Signed-off-by: Bhargav Shah <bhargavshah1988@gmail.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Add a test for dtoc taking into account the cd-gpios property.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently dtoc does not support the property cd-gpios used to declare
the gpios for card detect in mmc.
This patch adds support to cd-gpios property.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Several MMC drivers use GPIO for card detection with cd-gpios property in
the MMC node pointing to a GPIO node. However, as U-Boot tries to save
space by keeping only required nodes using u-boot* properties, several
devices tree result in having only in the MMC node but not the GPIO node
associated to cd-gpios.
This patch, fixes several ocurrence of this issue.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm
Update documentation to reflect the new phandle support when OF_PLATDATA
is used. Now phandles are implemented as pointers to U_BOOT_DEVICE,
which makes it possible to get a pointer to the actual device.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the current implementation, when dtoc parses a dtb to generate a struct
platdata it converts the information related to linked nodes as pointers
to struct platdata of destination nodes. By doing this, it makes
difficult to get pointer to udevices created based on these
information.
This patch extends dtoc to use struct driver_info when populating
information about linked nodes, which makes it easier to later get
the devices created. In this context, reimplement functions like
clk_get_by_index_platdata() which made use of the previous approach.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to be able to update data in u_boot_list, move this section to
make it RW.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently when creating an U_BOOT_DEVICE entry a struct driver_info
is declared, which contains the data needed to instantiate the device.
However, the actual device is created at runtime and there is no proper
way to get the device based on its struct driver_info.
This patch extends struct driver_info adding a pointer to udevice which
is populated during the bind process, allowing to generate a set of
functions to get the device based on its struct driver_info.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to prepare for a new support of phandle when OF_PLATDATA is used
drop the const for struct driver_info as this struct will need to be
updated on runtime.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
