- Jul 14, 2021
-
-
All devices based on ST-Ericsson Ux500 use a PMIC similar to AB8500 (Analog Baseband). There is AB8500, AB8505, AB9540 and AB8540 although in practice only AB8500 and AB8505 are relevant since the platforms with AB9540 and AB8540 were cancelled and never used in production. In general, the AB8500 PMIC uses I2C as control interface, where the different register banks are represented as separate I2C devices. However, in practice AB8500 is always connected to a special I2C bus on the DB8500 SoC that is controlled by the power/reset/clock management unit (PRCMU) firmware. Add a simple driver that allows reading/writing registers of the AB8500 PMIC. The driver directly accesses registers from the PRCMU parent device (represented by syscon in U-Boot). Abstracting it further (e.g. with the i2c uclass) would not provide any advantage because the PRCMU I2C bus is always just connected to AB8500 and vice-versa. The ab8500.h header is mostly taken as-is from Linux (with some minor adjustments) to allow using similar code in both Linux and U-Boot. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Acked-by:
Jaehoon Chung <jh80.chung@samsung.com>
-
The U-Boot "stemmy" board is mainly intended to simplify booting mainline Linux on various smartphones from Samsung based on ST-Ericsson Ux500. While the mainline kernel is working great, there are still some features missing there. In particular, it is currently not possible to charge the battery when using the mainline kernel. This means that it is still necessary to boot the downstream/vendor kernel from Samsung sometimes to charge the device. That kernel is ancient, still uses board files + ATAGS instead of device trees and relies on a strange very long kernel command line hardcoded in the Samsung bootloader. Actually, since mainline is booted with device trees there is a very simple way to make the old downstream kernel work as well: We can simply take most of the ATAGS passed to U-Boot from the Samsung bootloader and copy them as-is when booting a kernel without device tree. That way the long command line and other needed ATAGS are copied as-is without having to bother with them. The only exception is the ATAG_INITRD - since the initrd is loaded by U-Boot, the atag for that should be generated in U-Boot so it points to the correct address. All other ATAGS are copied as-is and not generated in U-Boot. Also use the chance and provide a serial# for U-Boot by parsing the ATAG_SERIAL that is also passed by the Samsung bootloader. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
At the moment the "stemmy" board attempts to detect the RAM size with a simple memory test (get_ram_size()). Unfortunately, this does not work correctly for devices with 768 MiB RAM (e.g. Samsung Galaxy Ace 2 (GT-I8160), "codina"). Reading/writing memory after the 768 MiB RAM succeeds but actually overwrites some earlier parts of the memory. For U-Boot this does not result in any major problems, but on Linux this will eventually lead to strange crashes because of the memory corruption. Since the "stemmy" U-Boot port is designed to be chainloaded from the original Samsung bootloader, the most reliable way to get the available amount of RAM is to look at the ATAGS passed by the Samsung bootloader. Fortunately, the header used to generate ATAGS in U-Boot (asm/setup.h) can also be easily used to parse them. Also clarify and simplify stemmy.h a bit to make it more clear where some of the magic values in there are actually coming from. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
Add the device tree for Akebi96. Akebi96 is a 96boards certified development board based on UniPhier LD20. ( https://www.96boards.org/product/akebi96/ ) Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org> Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-
Enable CONFIG_SYS_PCI_64BIT to allow 64bit access to PCI space. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-
Add PCIe driver for UniPhier SoCs. This PCIe controller is based on Synopsys DesignWare Core IP. This version doesn't apply common DW functions because supported controller doesn't have unroll version of iATU. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-
Add PCIe PHY driver support for Pro5, LD20 and PXs3 SoCs. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-
Add reset control for PCIe controller on each SoC. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-
Add clock control for PCIe controller on each SoC. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-
I'm no longer work in Intel, change Intel SoCFPGA co-maintainer to Tien Fong Chee. Signed-off-by:
Ley Foon Tan <lftan.linux@gmail.com> Acked-by:
Marek Vasut <marex@denx.de>
-
According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE" and uninitialized before relocation. Also, it overlaps with the appended DTB before relocation, so writing data into a variable in the BSS section might corrupt the appended DTB. Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the "pin_name" variable in the BSS section (since it's uninitialized). It's also used before relocation, when setting up the pinctrl for the serial driver. On DB410c this causes "GPIO_5" to be written into some part of an appended DTB, e.g.: 80111820: edfe0dd0 9f100000 38000000 c00e0000 ...........8.... 80111830: 28000000 11000000 10000000 00000000 ...(............ 80111840: 4f495047 8800355f 00000000 00000000 GPIO_5.......... 80111850: 00000000 00000000 01000000 00000000 ................ 80111860: 03000000 04000000 00000000 02000000 ................ 80111870: 03000000 04000000 0f000000 02000000 ................ 80111880: 03000000 2d000000 1b000000 6c617551 .......-....Qual 80111890: 6d6d6f63 63655420 6c6f6e68 6569676f comm Technologie Depending on the part of the DTB that is corrupted this might not cause any problems, but it can also result in strange reboots without any serial output. Fortunately, in practice this does not cause issues on DB410c yet because board_fdt_blob_setup() in dragonboard410c.c currently overrides the appended DTB with the one passed by the previous bootloader (LK) (which does not get corrupted). DB820c does not have board_fdt_blob_setup() so I would expect it to be affected by this problem. Perhaps everyone was just fortunate to not compile an U-Boot configuration where the pin_name corrupts an important part of the DTB. Make sure "pin_name" is explicitly placed in the .data section instead of .bss to fix this. Cc: Ramon Fried <rfried.dev@gmail.com> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Ramon Fried <rfried.dev@gmail.com>
-
The sysinfo_get_str() implementation checks whether the sysinfo was even detected. In U-Boot proper, sysinfo_detect() is not called anywhere but on one specific board. Call sysinfo_detect() before sysinfo_get_str() to make sure the sysinfo is detected and sysinfo_get_str() returns valid value instead of -EPERM. Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Replace uclass_first_device_err(UCLASS_SYSINFO, &dev) with sysinfo_get(&dev). The board_info code may use sysinfo to print board information, so use the sysinfo functions consistently. The sysinfo_get() is internally implemented as return uclass_first_device_err(UCLASS_SYSINFO, &dev) anyway, so there is no functional change. Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Linux kernel binding is using atmel,24c01 compatible string. On the other hand there is atmel,24c01a which is not listed in the kernel. Add compatible string without "a" suffix to be compatible with Linux kernel binding. Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Heiko Schocher <hs@denx.de> Cc: Michal Simek <michal.simek@xilinx.com> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
Simplify the code a bit by using dev_read_addr_ptr() instead of dev_read_addr(). This avoids having to cast explicitly to the struct nomadik_mtu_regs. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
Nomadik GPIO is a fairly simple GPIO module used in the ST-Ericsson Ux500 SoCs (and some older Nomadik SoCs). It uses registers where each GPIO is represented as a single bit, plus "set" and "clear" registers that allow updating the state without having to read the existing state. The driver implements support for it for use together with DM_GPIO and the existing ste-dbx5x0.dtsi device tree. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
The original U-Boot port for the ST-Ericsson U8500 SoC was dropped in commit 68282f55 ("arm: Remove unused ST-Ericsson u8500 arch"). Most of the drivers related to the old port were removed, but the db8500_gpio.c driver was forgotten for some reason. There is no way to select it and it does not compile anymore because of missing headers, so let's just remove it. The new port for U8500 introduced in commit 689088f9 ("arm: Add support for ST-Ericsson U8500 SoC") fully embraces the new Driver Model and device trees where possible, so this is preparation to add a new, simplified GPIO driver based on DM_GPIO. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
This information will be maintained in the device tree instead. Signed-off-by:
Anders Dellien <anders.dellien@arm.com>
-
- Jul 13, 2021
-
-
https://source.denx.de/u-boot/custodians/u-boot-efiTom Rini authored
Pull request for efi-2021-10-rc1 Documentation * fix typo in signature.txt UEFI * provide file attributes in EFI_FILE_PROTOCOL.Read() * various capsule update fixes
-
- Jul 12, 2021
-
-
Fix find_boot_device() to set bootdev_root if it finds the bootdev from BootNext. Currently it sets the bootdev_root only when it finds bootdev from BootOrder. Fixes: c74cd8bd ("efi_loader: capsule: add capsule_on_disk support") Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org> Accked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
If multiple capsules are applied, the FMP drivers for the individual capsules can expect the value of CapsuleLast to be accurate. Hence CapsuleLast must be updated after each capsule. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
efi_set_variable() should be called with EFI_CALL(). Use efi_set_variable_int() instead. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
* Use log category LOGC_EFI. This allows to remove 'EFI:' prefixes in messages. * Rephrase some of the messages. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
When reading a directory using EFI_FILE_PROTOCOL.Read() provide file attributes and timestamps. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
We should avoid #ifdef in C modules. Unused functions are eliminated by the linker. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Heinrich Schuchardt authored
When reading a directory in the UEFI file system we have to return file attributes and timestamps. Copy this data to the directory entry structure. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
Fix value fields in signature nodes. Signed-off-by:
Thomas Perrot <thomas.perrot@bootlin.com> Reviewed-by:
Heinrich Schuchardt <xypron.glpk@gmx.de>
-
- Jul 10, 2021
-
-
https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini authored
Aside from the usual fixes and updates one visible change is the MMC update, which fixes some lingering bugs and gives a decent speed increase on some boards (9->19 MB/s on H6, 21->43 MB/s on A64 eMMC). I am keeping an watchful eye on bug reports here, to spot any correctness regressions. Another change is finally the enablement of the first USB host port on many boards without micro-USB (data) sockets, like the Pine64 family. That doubles the number of usable USB ports from 1 to 2 on those boards. Some smaller fixes, 4GB DRAM support (on the H616) and a new board (ZeroPi) conclude this first round of changes. Compile-tested for all 157 sunxi boards, boot-tested on Pine H64, Pine64-LTS, OrangePi Zero 2 and BananaPi M2 Berry. Summary: - DT update for H3/H5/H6 - Enable first USB port on boards without micro-USB - ZeroPi board support - 4GB DRAM support for H616 boards - MMC fixes and speed improvement - some fixes
-
André Przywara authored
At the moment the Allwinner MMC driver parses the bus-width and non-removable DT properties itself, in the probe() routine. There is actually a generic function provided by the MMC framework doing this job, also it parses more generic properties like broken-cd and advanced transfer modes. Drop our own code and call mmc_of_parse() instead, to get all new features for free. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com>
-
André Przywara authored
To avoid the complexity of DMA operations (with chained descriptors), we use repeated MMIO reads and writes to the SD_FIFO_REG, which allows us to drain or fill the MMC data buffer FIFO very easily. However those MMIO accesses are somewhat costly, so this limits our MMC performance, to between 17 and 22 MB/s, but down to 9.5 MB/s on the H6 (partly due to the lower AHB1 frequency). As it turns out we read the FIFO status register after *every* word we read or write, which effectively doubles the number of MMIO accesses, thus effectively more than halving our performance. To avoid this overhead, we can make use of the FIFO level bits, which are in the very same FIFO status registers. So for a read request, we now can collect as many words as the FIFO level originally indicated, and only then need to update the status register. We don't know for sure the size of the FIFO (and it seems to differ across SoCs anyway), so writing is more fragile, which is why we still use the old method for that. If we find a minimum FIFO size available on all SoCs, we could use that, in a later optimisation. This patch increases the eMMC read speed on a Pine64-LTS from about 22MB/s to 44 MB/s. SD card reads don't gain that much, but with 23 MB/s we now reach the practical limit for 3.3V SD cards. On the H6 we double our transfer speed, from 9.5 MB/s to 19.7 MB/s. Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-
André Przywara authored
Newer SoCs have a self calibration feature, which avoids us writing hard coded phase delay values into the controller. Consolidate the code by avoiding unnecessary #ifdefs, and also enabling the feature for all those newer SoCs. Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-
André Przywara authored
All SoCs since the Allwinner A64 (H5, H6, R40, H616) feature the so called "new timing mode", so enable this in Kconfig for those SoCs. Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-
André Przywara authored
Among the SoCs using the "new timing mode", only the A83T needs to explicitly switch to that mode. By just defining the symbol for that one odd A83T bit to 0 for any other SoCs, we can always OR that in, and save the confusing nested #ifdefs. Clean up the also confusing new_mode setting on the way. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com>
-
André Przywara authored
Most Allwinner SoCs which use the so called "new timing mode" in their MMC controllers actually use the double-rate PLL6/PERIPH0 clock as their parent input clock. This is interestingly enough compensated by a hidden "by 2" post-divider in the mod clock, so the divider and actual output rate stay the same. Even though for the H6 and H616 (but only for them!) we use the doubled input clock for the divider computation, we never accounted for the implicit post-divider, so the clock was only half the speed on those SoCs. This didn't really matter so far, as our slow MMIO routine limits the transfer speed anyway, but we will fix this soon. Clean up the code around that selection, to always use the normal PLL6 (PERIPH0(1x)) clock as an input. As the rate and divider are the same, that makes no difference. Explain the hardware differences in a comment. Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-
André Przywara authored
When enabling PHYS_64BIT on 32-bit platforms, we get two warnings about pointer casts in sunxi_mmc.c. Those are related to MMIO addresses, which are always below 1GB on all Allwinner SoCs, so there is no problem with anything having more than 32 bits. Add the proper casts to make it compile cleanly. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com>
-
André Przywara authored
The delay and bus-width setup are slightly different across the Allwinner SoC generations, and we covered this so far with some preprocessor conditionals. Use the more readable IS_ENABLE() instead. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com>
-
André Przywara authored
The H616 is our first supported Allwinner SoC which goes beyond the 4GB address space "barrier", by having more than 32 address bits. Lift the preliminary 3GB DRAM limit for the H616, and update the page table setup on the way, to actually map that last GB as well. As not all devices are actually capable of dealing with more than 32 bits (the DMA in the EMAC for instance), we also limit U-Boot's own DRAM usage to 4GB on the way. Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-
André Przywara authored
We hardcode the pinctrl setting for the MMC controllers in boards.c, since we need them also in the SPL, where there is no DT yet. Add the respective setting for the H616 SoC, to enable eMMC on boards with this SoC as well. Also to make diagnosing this problem easier, print a warning if a board tries to setup MMC2 pins without a respective SoC setting being defined. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jagan Teki <jagan at amarulasolutions.com> Reviewed-by: Jernej Skrabec <jernej.skrabec at siol.net>
-
ZeroPi is a new board of high performance with low cost designed by FriendlyElec., using the Allwinner H3 SOC. ZeroPi features - Allwinner H3, Quad-core Cortex-A7@1.2GHz - 256MB/512MB DDR3 RAM - microsd slot - 10/100/1000Mbps Ethernet - Debug Serial Port - DC 5V/2A power-supply Signed-off-by:
Yu-Tung Chang <mtwget@gmail.com> Reviewed-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-
OrangePi PC2 board has DRAM with ODT, so enable it. H5 SoC is also connected to voltage regulator. It's default value is reasonable at reset, but might be too low when rebooting with a lower voltage programmed. In order to avoid instability, enable driver for it and set it to appropriate voltage. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Tested-by:
Andre Przywara <andre.przywara@arm.com> [Andre: remove original ZQ value change, adjust commit message] Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-