- Jul 17, 2020
-
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Continuing with the approach in commit <addf358b> rename additional drivers to allow the OF_PLATDATA support. Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
- Jul 16, 2020
-
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
After latest improvements in dtoc, compatible strings are checked against driver and driver alias list to get a valid driver name. With this new feature the list of compatible string aliases seems not useful any more. Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
Walter Lozano authored
Currently dtoc checks if the first compatible string in a dtb node matches either a driver o driver alias name, without taking into account any other compatible string in the list. In the case that no driver matches the first compatible string a warning is printed and the U_BOOT_DEVICE is not being declared correctly. This patch adds dtoc's support for try all the compatible strings in the dtb node, in an effort to find the correct driver. Series-to: dtoc Cover-letter: dtoc: improve compatible string aliases support This series adds additional improvements to dtoc, which are focused in compatible string aliases. First, enhance dtoc to use not only the first but all the compatible strings in a dtb node in order to find a valid driver name. Second, remove compatible string aliases from dtoc which were used to generate mappings between struct names. This is not longer needed since now a valid driver name is used. END Signed-off-by:
Walter Lozano <walter.lozano@collabora.com>
-
- Jul 11, 2020
-
-
https://gitlab.denx.de/u-boot/custodians/u-boot-spiTom Rini authored
- Enable DM_SPI on siemens omap boards (Jagan) - Dropped some non-dm supported omap3 boards (Jagan) - Dropped non-dm code in omap3 spi driver (Jagan) - Dropped non-dm code in kirkwood spi driver (Bhargav)
-
https://gitlab.denx.de/u-boot/custodians/u-boot-uniphierTom Rini authored
UniPhier SoC updates for v2020.10 - remove workaround for Cortex-A72 - increase U-Boot proper size to 2MB - sync DT with Linux - add system bus controller driver - improve serial driver - add reset assertion to Denali NAND driver
-
Masahiro Yamada authored
Now that commit 3e57f879 ("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>
-
Ley Foon Tan authored
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>
-
Ley Foon Tan authored
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>
-
Masahiro Yamada authored
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>
-
Masahiro Yamada authored
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>
-
Masahiro Yamada authored
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>
-
Masahiro Yamada authored
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>
-
Masahiro Yamada authored
Move the bus initialization code to this driver from board files. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Since commit 1517126f ("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>
-
Masahiro Yamada authored
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>
-
Masahiro Yamada authored
This was used by the old sLD3 SoC, the support of which was removed by commit 00aa453e ("ARM: uniphier: remove sLD3 SoC support"). There is no more user of this function. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
If CONFIG_MICRO_SUPPORT_CARD is unset, the build fails due to function redefinition. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
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>
-
Masahiro Yamada authored
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 58d70227 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN") increased it to 576KB, and commit 3ce5b1a8 ("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 1a4bd3a0 ("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 3ce5b1a8. With this change, there is no more practical size limit. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
This reverts commit 45f41c13. 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 f8ddd8cb ("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>
-
- Jul 10, 2020
-
-
https://gitlab.denx.de/u-boot/custodians/u-boot-dmTom Rini authored
of-platdata: better phandle and compatible-string support patman support for Python3 on Ubuntu 14.04 new checkpatch check to avoid #ifdefs
-
Heinrich Schuchardt authored
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>
-
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypiTom Rini authored
- add support for PCI and XHCI for RPi4 (64 bit only) - optionally reset XHCI device on registration - enable USB_KEYBOARD for rpi_4_defconfig
-
Tom Rini authored
- Bring in Marek Szyprowski's series to allow for arbitrary virtual-physical address mappings.
-
Marek Szyprowski authored
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>
-
Marek Szyprowski authored
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>
-
Seung-Woo Kim authored
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>
-
Marek Szyprowski authored
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>
-
Marek Szyprowski authored
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>
-
Marek Szyprowski authored
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>
-