Re: [U-Boot] [PATCH 1/3] usb: dwc3: Add Meson G12A USB Glue
On 3/27/19 10:12 AM, Neil Armstrong wrote:
> On 26/03/2019 16:53, Marek Vasut wrote:
>> On 3/26/19 4:15 PM, Neil Armstrong wrote:
>>> Adds support for Amlogic G12A USB Control Glue HW.
>>>
>>> The Amlogic G12A SoC Family embeds 2 USB Controllers :
>>> - a DWC3 IP configured as Host for USB2 and USB3
>>> - a DWC2 IP configured as Peripheral USB2 Only
>>>
>>> A glue connects these both controllers to 2 USB2 PHYs, and optionnally
>>> to an USB3+PCIE Combo PHY shared with the PCIE controller.
>>>
>>> The Glue configures the UTMI 8bit interfaces for the USB2 PHYs, including
>>> routing of the OTG PHY between the DWC3 and DWC2 controllers, and
>>> setups the on-chip OTG mode selection for this PHY.
>>>
>>> This driver sets the OTG capable port as Host mode by default,
>>> the switch to Device mode is to be done in a separate patch.
>>>
>>> Signed-off-by: Neil Armstrong
>>> ---
>>
>> [...]
>>
>>> +static int dwc3_meson_g12a_get_phys(struct dwc3_meson_g12a *priv)
>>> +{
>>> + int i, ret;
>>> +
>>> + for (i = 0 ; i < PHY_COUNT ; ++i) {
>>> + ret = generic_phy_get_by_name(priv->dev, phy_names[i],
>>> + >phys[i]);
>>> + if (ret == -ENOENT)
>>> + continue;
>>> +
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (i == USB3_HOST_PHY)
>>> + priv->usb3_ports++;
>>> + else
>>> + priv->usb2_ports++;
>>> + }
>>> +
>>> + printf("%s: usb2 ports: %d\n", __func__, priv->usb2_ports);
>>> + printf("%s: usb3 ports: %d\n", __func__, priv->usb3_ports);
>>
>> Are these prints needed ?
>
> Nop, forgot to switch them to debug
>
>>
>>> + return 0;
>>> +}
>>
>> [...]
>>> +static int dwc3_meson_g12a_probe(struct udevice *dev)
>>> +{
>>> + struct dwc3_meson_g12a *priv = dev_get_platdata(dev);
>>> + int ret, i;
>>> +
>>> + priv->dev = dev;
>>> +
>>> + ret = regmap_init_mem(dev_ofnode(dev), >regmap);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = dwc3_meson_g12a_clk_init(priv);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = dwc3_meson_g12a_reset_init(priv);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = dwc3_meson_g12a_get_phys(priv);
>>> + if (ret)
>>> + return ret;
>>> +
>>> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>>> + ret = device_get_supply_regulator(dev, "vbus-supply",
>>> + >vbus_supply);
>>> + if (ret && ret != -ENOENT) {
>>> + pr_err("Failed to get PHY regulator\n");
>>> + return ret;
>>> + }
>>> +
>>> + if (priv->vbus_supply) {
>>> + ret = regulator_set_enable(priv->vbus_supply, true);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +#endif
>>> +
>>> + priv->otg_mode = usb_get_dr_mode(dev_of_offset(dev));
>>> +
>>> + ret = dwc3_meson_g12a_usb_init(priv);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + for (i = 0 ; i < PHY_COUNT ; ++i) {
>>> + if (!priv->phys[i].dev)
>>> + continue;
>>> +
>>> + ret = generic_phy_init(>phys[i]);
>>> + if (ret)
>>> + goto err_phy_init;
>>> + }
>>
>> Isn't there some function to init all the PHYs already ?
>>
>
> I don't see any in u-boot master !
> Unlike dwc3, we need to get the phys with the names to check if
> the USB3 phy is enabled, so we can't get all possible phys.
I see, so thus far my only comment is about the missed debug prints.
Thanks!
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] malloc: Fix memalign not honoring alignment prior to full malloc init
On 27/03/19 11:47 PM, Andreas Dannenberg wrote:
> When using memalign() in a scenario where U-Boot is configured for full
> malloc support with simple malloc not explicitly enabled and before the
> full malloc support is initialized, a memory block is being allocated
> and returned without the alignment parameter getting honored.
>
> Fix this issue by replacing the existing memalign pre-full malloc init
> logic with a call to memalign_simple() this way ensuring proper alignment
> of the returned memory block.
>
> Fixes: ee038c58d519 ("malloc: Use malloc simple before malloc is fully
> initialized in memalign()")
> Signed-off-by: Andreas Dannenberg
> ---
Good catch.
Reviewed-by: Lokesh Vutla
Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path
Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common header file path, so that we can get the correct path directly. Signed-off-by: Kever Yang --- .../include/asm/arch-rockchip/ddr_rk3188.h| 2 +- arch/arm/mach-rockchip/Kconfig| 2 +- arch/arm/mach-rockchip/boot_mode.c| 2 +- arch/arm/mach-rockchip/bootrom.c | 4 ++-- arch/arm/mach-rockchip/rk3036-board-spl.c | 12 +-- arch/arm/mach-rockchip/rk3036-board.c | 10 +- arch/arm/mach-rockchip/rk3036/clk_rk3036.c| 4 ++-- arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 12 +-- arch/arm/mach-rockchip/rk3036/syscon_rk3036.c | 2 +- arch/arm/mach-rockchip/rk3128-board.c | 10 +- arch/arm/mach-rockchip/rk3128/clk_rk3128.c| 4 ++-- arch/arm/mach-rockchip/rk3128/syscon_rk3128.c | 2 +- arch/arm/mach-rockchip/rk3188-board-spl.c | 16 +++ arch/arm/mach-rockchip/rk3188-board.c | 10 +- arch/arm/mach-rockchip/rk3188/clk_rk3188.c| 4 ++-- arch/arm/mach-rockchip/rk3188/syscon_rk3188.c | 2 +- arch/arm/mach-rockchip/rk322x-board-spl.c | 12 +-- arch/arm/mach-rockchip/rk322x-board.c | 10 +- arch/arm/mach-rockchip/rk322x/clk_rk322x.c| 4 ++-- arch/arm/mach-rockchip/rk322x/syscon_rk322x.c | 2 +- arch/arm/mach-rockchip/rk3288-board-spl.c | 20 +-- arch/arm/mach-rockchip/rk3288-board-tpl.c | 14 ++--- arch/arm/mach-rockchip/rk3288-board.c | 12 +-- arch/arm/mach-rockchip/rk3288/clk_rk3288.c| 4 ++-- arch/arm/mach-rockchip/rk3288/rk3288.c| 2 +- arch/arm/mach-rockchip/rk3288/syscon_rk3288.c | 2 +- arch/arm/mach-rockchip/rk3328/clk_rk3328.c| 4 ++-- arch/arm/mach-rockchip/rk3328/rk3328.c| 2 +- arch/arm/mach-rockchip/rk3328/syscon_rk3328.c | 2 +- arch/arm/mach-rockchip/rk3368-board-spl.c | 10 +- arch/arm/mach-rockchip/rk3368-board-tpl.c | 12 +-- arch/arm/mach-rockchip/rk3368/clk_rk3368.c| 4 ++-- arch/arm/mach-rockchip/rk3368/rk3368.c| 6 +++--- arch/arm/mach-rockchip/rk3368/syscon_rk3368.c | 2 +- arch/arm/mach-rockchip/rk3399-board-spl.c | 12 +-- arch/arm/mach-rockchip/rk3399-board.c | 2 +- arch/arm/mach-rockchip/rk3399/clk_rk3399.c| 4 ++-- arch/arm/mach-rockchip/rk3399/rk3399.c| 2 +- arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 2 +- arch/arm/mach-rockchip/rk_timer.c | 2 +- arch/arm/mach-rockchip/rv1108/clk_rv1108.c| 4 ++-- arch/arm/mach-rockchip/rv1108/syscon_rv1108.c | 2 +- arch/arm/mach-rockchip/sdram_common.c | 2 +- board/elgin/elgin_rv1108/elgin_rv1108.c | 4 ++-- board/rockchip/evb_rk3036/evb_rk3036.c| 4 ++-- board/rockchip/evb_rk3229/evb_rk3229.c| 2 +- board/rockchip/evb_rk3399/evb-rk3399.c| 2 +- board/rockchip/evb_rv1108/evb_rv1108.c| 4 ++-- board/rockchip/kylin_rk3036/kylin_rk3036.c| 4 ++-- board/rockchip/sheep_rk3368/sheep_rk3368.c| 4 ++-- .../lion_rk3368/lion_rk3368.c | 6 +++--- .../puma_rk3399/puma-rk3399.c | 10 +- board/vamrs/rock960_rk3399/rock960-rk3399.c | 2 +- cmd/rockusb.c | 2 +- drivers/clk/rockchip/clk_rk3036.c | 6 +++--- drivers/clk/rockchip/clk_rk3128.c | 6 +++--- drivers/clk/rockchip/clk_rk3188.c | 8 drivers/clk/rockchip/clk_rk322x.c | 6 +++--- drivers/clk/rockchip/clk_rk3288.c | 8 drivers/clk/rockchip/clk_rk3328.c | 8 drivers/clk/rockchip/clk_rk3368.c | 6 +++--- drivers/clk/rockchip/clk_rk3399.c | 6 +++--- drivers/clk/rockchip/clk_rv1108.c | 6 +++--- drivers/gpio/rk_gpio.c| 3 ++- drivers/i2c/rk_i2c.c | 6 +++--- drivers/mmc/rockchip_dw_mmc.c | 4 ++-- drivers/net/gmac_rockchip.c | 18 - drivers/pwm/rk_pwm.c | 2 +- drivers/ram/rockchip/dmc-rk3368.c | 12 +-- drivers/ram/rockchip/sdram_rk3128.c | 6 +++--- drivers/ram/rockchip/sdram_rk3188.c | 14 ++--- drivers/ram/rockchip/sdram_rk322x.c | 16 +++ drivers/ram/rockchip/sdram_rk3288.c | 14 ++--- drivers/ram/rockchip/sdram_rk3328.c | 6 +++--- drivers/ram/rockchip/sdram_rk3399.c | 12 +-- drivers/reset/reset-rockchip.c| 2 +- drivers/serial/serial_rockchip.c | 2 +- drivers/sound/rockchip_sound.c| 2 +- drivers/spi/rk_spi.c | 4 ++-- drivers/sysreset/sysreset_rockchip.c | 6 +++--- drivers/timer/rockchip_timer.c| 2 +- drivers/usb/gadget/f_rockusb.c| 2 +-
[U-Boot] [PATCH 0/3] rockchip: correct SYS_SOC name for all rockchip SoCs
Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common header file path, so that we do not need to make folder for each soc, because many header file are shared for all the SoCs which not need separate for each SoC. With the SoC name correct to its own name, the build system can include the $(SOC)-u-boot.dtsi automatically. Kever Yang (3): rockchip: arm: use 'arch-rockchip' for common header rockchip: use 'arch-rockchip' as header file path rockchip: correct ARCH_SOC name arch/arm/cpu/armv8/start.S| 4 .../include/asm/arch-rockchip/ddr_rk3188.h| 2 +- arch/arm/include/asm/gpio.h | 2 +- arch/arm/lib/vectors.S| 5 - arch/arm/mach-rockchip/Kconfig| 2 +- arch/arm/mach-rockchip/boot_mode.c| 2 +- arch/arm/mach-rockchip/bootrom.c | 4 ++-- arch/arm/mach-rockchip/rk3036-board-spl.c | 12 +-- arch/arm/mach-rockchip/rk3036-board.c | 10 +- arch/arm/mach-rockchip/rk3036/Kconfig | 2 +- arch/arm/mach-rockchip/rk3036/clk_rk3036.c| 4 ++-- arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 12 +-- arch/arm/mach-rockchip/rk3036/syscon_rk3036.c | 2 +- arch/arm/mach-rockchip/rk3128-board.c | 10 +- arch/arm/mach-rockchip/rk3128/Kconfig | 2 +- arch/arm/mach-rockchip/rk3128/clk_rk3128.c| 4 ++-- arch/arm/mach-rockchip/rk3128/syscon_rk3128.c | 2 +- arch/arm/mach-rockchip/rk3188-board-spl.c | 16 +++ arch/arm/mach-rockchip/rk3188-board.c | 10 +- arch/arm/mach-rockchip/rk3188/Kconfig | 2 +- arch/arm/mach-rockchip/rk3188/clk_rk3188.c| 4 ++-- arch/arm/mach-rockchip/rk3188/syscon_rk3188.c | 2 +- arch/arm/mach-rockchip/rk322x-board-spl.c | 12 +-- arch/arm/mach-rockchip/rk322x-board.c | 10 +- arch/arm/mach-rockchip/rk322x/Kconfig | 2 +- arch/arm/mach-rockchip/rk322x/clk_rk322x.c| 4 ++-- arch/arm/mach-rockchip/rk322x/syscon_rk322x.c | 2 +- arch/arm/mach-rockchip/rk3288-board-spl.c | 20 +-- arch/arm/mach-rockchip/rk3288-board-tpl.c | 14 ++--- arch/arm/mach-rockchip/rk3288-board.c | 12 +-- arch/arm/mach-rockchip/rk3288/Kconfig | 2 +- arch/arm/mach-rockchip/rk3288/clk_rk3288.c| 4 ++-- arch/arm/mach-rockchip/rk3288/rk3288.c| 2 +- arch/arm/mach-rockchip/rk3288/syscon_rk3288.c | 2 +- arch/arm/mach-rockchip/rk3328/Kconfig | 2 +- arch/arm/mach-rockchip/rk3328/clk_rk3328.c| 4 ++-- arch/arm/mach-rockchip/rk3328/rk3328.c| 2 +- arch/arm/mach-rockchip/rk3328/syscon_rk3328.c | 2 +- arch/arm/mach-rockchip/rk3368-board-spl.c | 10 +- arch/arm/mach-rockchip/rk3368-board-tpl.c | 12 +-- arch/arm/mach-rockchip/rk3368/Kconfig | 2 +- arch/arm/mach-rockchip/rk3368/clk_rk3368.c| 4 ++-- arch/arm/mach-rockchip/rk3368/rk3368.c| 6 +++--- arch/arm/mach-rockchip/rk3368/syscon_rk3368.c | 2 +- arch/arm/mach-rockchip/rk3399-board-spl.c | 12 +-- arch/arm/mach-rockchip/rk3399-board.c | 2 +- arch/arm/mach-rockchip/rk3399/Kconfig | 2 +- arch/arm/mach-rockchip/rk3399/clk_rk3399.c| 4 ++-- arch/arm/mach-rockchip/rk3399/rk3399.c| 2 +- arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 2 +- arch/arm/mach-rockchip/rk_timer.c | 2 +- arch/arm/mach-rockchip/rv1108/Kconfig | 2 +- arch/arm/mach-rockchip/rv1108/clk_rv1108.c| 4 ++-- arch/arm/mach-rockchip/rv1108/syscon_rv1108.c | 2 +- arch/arm/mach-rockchip/sdram_common.c | 2 +- board/elgin/elgin_rv1108/elgin_rv1108.c | 4 ++-- board/rockchip/evb_rk3036/evb_rk3036.c| 4 ++-- board/rockchip/evb_rk3229/evb_rk3229.c| 2 +- board/rockchip/evb_rk3399/evb-rk3399.c| 2 +- board/rockchip/evb_rv1108/evb_rv1108.c| 4 ++-- board/rockchip/kylin_rk3036/kylin_rk3036.c| 4 ++-- board/rockchip/sheep_rk3368/sheep_rk3368.c| 4 ++-- .../lion_rk3368/lion_rk3368.c | 6 +++--- .../puma_rk3399/puma-rk3399.c | 10 +- board/vamrs/rock960_rk3399/rock960-rk3399.c | 2 +- cmd/rockusb.c | 2 +- drivers/clk/rockchip/clk_rk3036.c | 6 +++--- drivers/clk/rockchip/clk_rk3128.c | 6 +++--- drivers/clk/rockchip/clk_rk3188.c | 8 drivers/clk/rockchip/clk_rk322x.c | 6 +++--- drivers/clk/rockchip/clk_rk3288.c | 8 drivers/clk/rockchip/clk_rk3328.c | 8 drivers/clk/rockchip/clk_rk3368.c | 6 +++--- drivers/clk/rockchip/clk_rk3399.c | 6 +++--- drivers/clk/rockchip/clk_rv1108.c | 6 +++--- drivers/gpio/rk_gpio.c| 3 ++- drivers/i2c/rk_i2c.c | 6 +++--- drivers/mmc/rockchip_dw_mmc.c
[U-Boot] Questions/RFC about overlay compatible strings and device tree compression in uImage.FIT
Hi U-Boot developers, (I picked a few of you out that seem to be most related to this code, hope that's okay,) I am interested in booting device trees with overlays from a FIT image (actually for a different bootloader, but we're trying to stay compatible with U-Boot's FIT format so I'm asking here), and I came up with some questions about how this is supposed to work that I hope you can answer: I found the basic description of overlay support in FIT here: https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/overlay-fdt-boot.txt However, what it doesn't really say is how compatible string matching works in the face of overlays. From my reading of the code it seems that U-Boot tries to match the compatible string in the FDT that is listed leftmost in the 'fdt' property of the config node (fit_conf_find_compat() just calls fdt_getprop(fit, "fdt") and uses the result as a string, so since the different FDT names in the property are separated by '\0' chars I assume that will act on the first name?), which according to the documentation should be the base device tree. Is that correct? I don't see how that would make sense... for overlays to make sense you would want to have multiple config nodes that all use the same base device tree and stack different overlays on top of it (the example in the docs also looks that way). But if the compatible string matcher only checks the base device tree, all of those config nodes will have the same strings to match -- how could it find the right node? I think the correct scheme would be to scan through all overlays from right to left (i.e. in reverse application order) until you find a compatible string somewhere. Was the current overlay support just only implemented with pre-selected config nodes (i.e. passing a fit_uname_configp to boot_get_fdt_fit()) in mind? On a somewhat related note, I was also thinking about allowing compression for the 'data' property of individual fdt@X nodes (similar to how you can already do it for kernel@X nodes), which can cut them down to about 15% of their size with LZ4 or even 5% with LZMA. The main problem with this is that you would have to decompress all device trees during the compatible string match to get at their embedded compatible strings. An obvious solution would be to copy the compatible string out into an explicit property in the config node at build time, so that the 'fdt' property (and the node it points to) doesn't have to be parsed before you're actually loading the full DT (and at that time you could decompress only the one(s) you're using). This would also help the compatible string problem with overlays, since then the config node has the compatible string right there and you don't need to worry about which overlay to extract it from anymore. Would it be an acceptable change if I added support for that to U-Boot? Of course, the code could gracefully fall back to scanning the whole FDT (decompressing if necessary) if the config node has no 'compatible' property. Please let me know what you think! Thanks, Julius ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] 'U-Boot parlella board support'
Greetings Martin, I'm not sure if I'm related to it. But looking at the geo location. I have a discovered a new Russia GMT settings in my router as default this morning, which is different from my location. I'm not sure when this was applied. Have not been applying or changing scripts for a few days due to trying to resolve, my android phone mobile had some weird changes, Router keeps resetting or unable to connect properly, DHCP issues, some PPC drivers unable to update after clean install with a default disc, e.g. nvidia, intel, sam internal 512GBssd, forced MS updates related to arm64 device and no permissions to uninstall it, some drivers without doing anything have e.g. class, parent, child, nodes attached and lastly, some policy notifications from few vendors. Updated my bios clock according to my country because it is reflecting a different time. Is there any way that I could provide information that it's related? Or should I abandon project and dispose device since it's my first failed attempt. Any advise would be appreciated. Alexander Dahl, Rick Chen, Troy Benjegerdes, Lukas Auer, Atish Patra, Oskari Lemmela, Paul Kocialkowski, Takahiro Akashi, Eugen Hristev and many rest of the U-Boot administrators has been very helpful with my issues and deeply appreciated it. Thank you. Thanks and best regards Bin meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/6] spl: full-featured heap cleanups
Some platforms cannot use simple malloc even in very early stages, e.g.
when using FAT before DRAM is available. Such platforms currently often
use non-Kconfig defines to initialize full malloc and rely on simple heap
before that.
This series makes some adjustments to ensure SPL behaves the same with
simple or full malloc: when CONFIG_SPL_SYS_MALLOC_F_LEN is != 0, both heap
types can be used (by changing CONFIG_SPL_SYS_MALLOC_SIMPLE), without
manually supplying an address range for the full heap.
Changes in v3:
- improve commit message to show why CONFIG_CLEAR_BSS_F is needed
- fixed summary ("stack" -> "heap")
- enable CONFIG_SPL_CLEAR_BSS_F for socfpga_arria10 using full malloc
early in SPL
- rebased
Changes in v2:
- make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now
- add CONFIG_SPL_CLEAR_BSS_F implementation for arm64 also
- use if() instead of #if
- adapt documentation to using CONFIG_SPL_SYS_MALLOC_F_LEN for
full-featured heap as well
- ensure SPL_CLEAR_BSS_F is set when using SYS_MALLOC_F_LEN for full
featured heap (or else, the heap status stored in bss will be overwritten
between board_init_f and board_init_r)
Simon Goldschmidt (6):
spl: add Kconfig option to clear bss early
spl: arm: implement SPL_CLEAR_BSS_F
dlmalloc: fix malloc range at end of ram
dlmalloc: be compatible to tiny printf
spl: support using full malloc with SYS_MALLOC_F_LEN
arm: socfpga: a10: move SPL heap size to Kconfig
Kconfig | 24 ++
README| 15 ++
arch/arm/lib/crt0.S | 22 +
arch/arm/lib/crt0_64.S| 14 +
common/dlmalloc.c | 6 +-
common/spl/Kconfig| 12 +++
common/spl/spl.c | 10 --
configs/socfpga_arria10_defconfig | 2 ++
drivers/core/Kconfig | 33 +++
include/configs/socfpga_common.h | 14 -
10 files changed, 106 insertions(+), 46 deletions(-)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] rockchip: correct ARCH_SOC name
The ARCH_SOC name default as 'rockchip' and we put all the header file in 'arch/arm/include/asm/arch-rockchip/', but the 'rockchip' is not the SOC name, let's correct it after we update all the source file. Signed-off-by: Kever Yang --- arch/arm/mach-rockchip/rk3036/Kconfig | 2 +- arch/arm/mach-rockchip/rk3128/Kconfig | 2 +- arch/arm/mach-rockchip/rk3188/Kconfig | 2 +- arch/arm/mach-rockchip/rk322x/Kconfig | 2 +- arch/arm/mach-rockchip/rk3288/Kconfig | 2 +- arch/arm/mach-rockchip/rk3328/Kconfig | 2 +- arch/arm/mach-rockchip/rk3368/Kconfig | 2 +- arch/arm/mach-rockchip/rk3399/Kconfig | 2 +- arch/arm/mach-rockchip/rv1108/Kconfig | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-rockchip/rk3036/Kconfig b/arch/arm/mach-rockchip/rk3036/Kconfig index c63db343e2..5e04d20448 100644 --- a/arch/arm/mach-rockchip/rk3036/Kconfig +++ b/arch/arm/mach-rockchip/rk3036/Kconfig @@ -9,7 +9,7 @@ config TARGET_KYLIN_RK3036 select BOARD_LATE_INIT config SYS_SOC - default "rockchip" + default "rk3036" config SYS_MALLOC_F_LEN default 0x400 diff --git a/arch/arm/mach-rockchip/rk3128/Kconfig b/arch/arm/mach-rockchip/rk3128/Kconfig index 40655a22b5..a82b7dc063 100644 --- a/arch/arm/mach-rockchip/rk3128/Kconfig +++ b/arch/arm/mach-rockchip/rk3128/Kconfig @@ -14,7 +14,7 @@ config TARGET_EVB_RK3128 endchoice config SYS_SOC - default "rockchip" + default "rk3128" config SYS_MALLOC_F_LEN default 0x0800 diff --git a/arch/arm/mach-rockchip/rk3188/Kconfig b/arch/arm/mach-rockchip/rk3188/Kconfig index 2bb35662d1..a6fc691fb6 100644 --- a/arch/arm/mach-rockchip/rk3188/Kconfig +++ b/arch/arm/mach-rockchip/rk3188/Kconfig @@ -10,7 +10,7 @@ config TARGET_ROCK UART and GPIOs. config SYS_SOC - default "rockchip" + default "rk3188" config SYS_MALLOC_F_LEN default 0x0800 diff --git a/arch/arm/mach-rockchip/rk322x/Kconfig b/arch/arm/mach-rockchip/rk322x/Kconfig index dc8071e4f3..8a1f95f785 100644 --- a/arch/arm/mach-rockchip/rk322x/Kconfig +++ b/arch/arm/mach-rockchip/rk322x/Kconfig @@ -5,7 +5,7 @@ config TARGET_EVB_RK3229 select BOARD_LATE_INIT config SYS_SOC - default "rockchip" + default "rk322x" config SYS_MALLOC_F_LEN default 0x400 diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig b/arch/arm/mach-rockchip/rk3288/Kconfig index bce8023881..50680ce606 100644 --- a/arch/arm/mach-rockchip/rk3288/Kconfig +++ b/arch/arm/mach-rockchip/rk3288/Kconfig @@ -148,7 +148,7 @@ config ROCKCHIP_FAST_SPL and have the required PMIC code. config SYS_SOC - default "rockchip" + default "rk3288" config SYS_MALLOC_F_LEN default 0x0800 diff --git a/arch/arm/mach-rockchip/rk3328/Kconfig b/arch/arm/mach-rockchip/rk3328/Kconfig index 43afba2430..6c5c4303a3 100644 --- a/arch/arm/mach-rockchip/rk3328/Kconfig +++ b/arch/arm/mach-rockchip/rk3328/Kconfig @@ -13,7 +13,7 @@ config TARGET_EVB_RK3328 endchoice config SYS_SOC - default "rockchip" + default "rk3328" config SYS_MALLOC_F_LEN default 0x0800 diff --git a/arch/arm/mach-rockchip/rk3368/Kconfig b/arch/arm/mach-rockchip/rk3368/Kconfig index 7c9b722b00..325572a7e4 100644 --- a/arch/arm/mach-rockchip/rk3368/Kconfig +++ b/arch/arm/mach-rockchip/rk3368/Kconfig @@ -43,7 +43,7 @@ config TARGET_EVB_PX5 endchoice config SYS_SOC - default "rockchip" + default "rk3368" source "board/theobroma-systems/lion_rk3368/Kconfig" source "board/rockchip/sheep_rk3368/Kconfig" diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig index 2408adb420..2c5c93c0b8 100644 --- a/arch/arm/mach-rockchip/rk3399/Kconfig +++ b/arch/arm/mach-rockchip/rk3399/Kconfig @@ -65,7 +65,7 @@ config TARGET_CHROMEBOOK_BOB endchoice config SYS_SOC - default "rockchip" + default "rk3399" config SYS_MALLOC_F_LEN default 0x0800 diff --git a/arch/arm/mach-rockchip/rv1108/Kconfig b/arch/arm/mach-rockchip/rv1108/Kconfig index 8883aeae7a..e3a63b80e1 100644 --- a/arch/arm/mach-rockchip/rv1108/Kconfig +++ b/arch/arm/mach-rockchip/rv1108/Kconfig @@ -23,7 +23,7 @@ config TARGET_ELGIN_RV1108 RV1108 ELGIN is a board based on the Rockchip RV1108. config SYS_SOC - default "rockchip" + default "rv1108" config SYS_MALLOC_F_LEN default 0x400 -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] rockchip: arm: use 'arch-rockchip' for common header
rockchip platform header file is in 'arch-rockchip' instead of arch-$(SOC) for all SoCs. Signed-off-by: Kever Yang --- arch/arm/cpu/armv8/start.S | 4 arch/arm/include/asm/gpio.h | 2 +- arch/arm/lib/vectors.S | 5 - 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index fe52166e28..ecee9e37a5 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -26,7 +26,11 @@ _start: * order to boot, allow them to set that in their boot0.h file and then * use it here. */ +#ifdef CONFIG_ARCH_ROCKCHIP +#include +#else #include +#endif #else b reset #endif diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h index 3039e66bf9..b0c8c47c95 100644 --- a/arch/arm/include/asm/gpio.h +++ b/arch/arm/include/asm/gpio.h @@ -1,5 +1,5 @@ #if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI) && \ - !defined(CONFIG_ARCH_K3) + !defined(CONFIG_ARCH_K3) && !defined(CONFIG_ARCH_ROCKCHIP) #include #endif #include diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index 2ca6e2494a..20f485142e 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -67,8 +67,11 @@ * (1) defines '_start:' as appropriate * (2) inserts the vector table using ARM_VECTORS as appropriate */ +#ifdef CONFIG_ARCH_ROCKCHIP +#include +#else #include - +#endif #else /* -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,V4,1/2] mmc: add HS400 support
On 3/27/19 9:43 PM, Trent Piepho wrote:
> I didn't see HS400 working on my IMX7d, even thought it appears it
> should be supported.
>
> The problem appears to be when this bit of code in fsl_esdhc.c, which
> dates to a patch "mmc: fsl_esdhc: support SDR104 and HS200":
>
> static struct esdhc_soc_data usdhc_imx7d_data = {
> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
>
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400,
> .caps = UHS_CAPS | MMC_MODE_HS200 | MMC_MODE_DDR_52MHz |
> MMC_MODE_HS_52MHz | MMC_MODE_HS,
> };
>
> Notice that MMC_MODE_HS400 isn't in the caps list. Once I add that
> uboot will attempt HS400 and it appears to work correctly.
>
> I think maybe this patch should have added this to the caps?
>
> Alternatively, there is a property that can be added to the device
> tree, mmc-hs400-1_8v, that will add this cap. But the code to parse
> those dt properties, mmc_of_parse(), isn't used by the fsl_esdhc
> driver, which has its own parsing code that doesn't know about mmc-
> hs400-1_8v.
>
> So maybe fsl-esdhc should use mmc_of_parse() and the appropriate iMX
> DTs should add those properties?
>
> I think the DT method might be better, since it would allow the DT to
> not list a mode that doesn't work due to the the board.
Right, please submit a patch switching over to the generic parsing code.
Thanks
> I.e., the iMX
> host supports the mode, the eMMC supports the mode, but the board
> layout doesn't have traces that can support it. Too long, not matched
> well enough, etc. It doesn't seem like there's an nice way to remove a
> mode otherwise.
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 07/11] cmd: bootefi: move do_bootefi_bootmgr_exec() forward
On Wed, Mar 27, 2019 at 07:50:05AM +0100, Heinrich Schuchardt wrote:
> On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> > This is a preparatory patch for reworking do_bootefi() in later patch.
>
> I would suggest as commit message:
>
> Move do_bootefi_bootmgr_exec() up in code to avoid a forward declaration
> in a later patch.
No. This "move" is just from a historical reason :)
I just want the main code to be placed first, and exceptional code
(i.e. efi_selftest) to follow it.
-Takahiro Akashi
> Otherwise
>
> Reviewed-by: Heinrich Schuchardt
>
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/bootefi.c | 42 +-
> > 1 file changed, 21 insertions(+), 21 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 1267d895472c..e9d4881997a1 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -309,6 +309,27 @@ err_add_protocol:
> > return ret;
> > }
> >
> > +static int do_bootefi_bootmgr_exec(void)
> > +{
> > + struct efi_device_path *device_path, *file_path;
> > + void *addr;
> > + efi_status_t r;
> > +
> > + addr = efi_bootmgr_load(_path, _path);
> > + if (!addr)
> > + return 1;
> > +
> > + printf("## Starting EFI application at %p ...\n", addr);
> > + r = do_bootefi_exec(addr, device_path, file_path);
> > + printf("## Application terminated, r = %lu\n",
> > + r & ~EFI_ERROR_MASK);
> > +
> > + if (r != EFI_SUCCESS)
> > + return 1;
> > +
> > + return 0;
> > +}
> > +
> > #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> > static efi_status_t bootefi_run_prepare(const char *load_options_path,
> > struct efi_device_path *device_path,
> > @@ -432,27 +453,6 @@ static int do_efi_selftest(const char *fdt_opt)
> > }
> > #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
> >
> > -static int do_bootefi_bootmgr_exec(void)
> > -{
> > - struct efi_device_path *device_path, *file_path;
> > - void *addr;
> > - efi_status_t r;
> > -
> > - addr = efi_bootmgr_load(_path, _path);
> > - if (!addr)
> > - return 1;
> > -
> > - printf("## Starting EFI application at %p ...\n", addr);
> > - r = do_bootefi_exec(addr, device_path, file_path);
> > - printf("## Application terminated, r = %lu\n",
> > - r & ~EFI_ERROR_MASK);
> > -
> > - if (r != EFI_SUCCESS)
> > - return 1;
> > -
> > - return 0;
> > -}
> > -
> > /* Interpreter command to boot an arbitrary EFI image from memory */
> > static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> > argv[])
> > {
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Move Stratix 10 SDRAM driver to DM
On Wed, Mar 27, 2019 at 7:34 PM Simon Goldschmidt
wrote:
>
> On Wed, Mar 27, 2019 at 10:15 AM Ley Foon Tan wrote:
> >
> > Convert Stratix 10 SDRAM driver to device model.
>
> Nice to see that :-)
>
> >
> > Get rid of call to socfpga_per_reset() and use reset
> > framework.
> >
> > SPL is changed from calling function in SDRAM driver
> > directly to just probing UCLASS_RAM.
> >
> > Move sdram_s10.h from arch to driver/ddr/altera directory.
> >
> > Signed-off-by: Ley Foon Tan
> > ---
> > arch/arm/Kconfig | 4 +-
> > arch/arm/dts/socfpga_stratix10.dtsi | 10 +
> > arch/arm/dts/socfpga_stratix10_socdk.dts | 4 +
> > arch/arm/mach-socfpga/Kconfig | 1 +
> > arch/arm/mach-socfpga/spl_s10.c | 9 +-
> > drivers/ddr/altera/Kconfig| 2 +-
> > drivers/ddr/altera/sdram_s10.c| 246 --
> > .../mach => drivers/ddr/altera}/sdram_s10.h | 4 -
> > include/configs/socfpga_stratix10_socdk.h | 5 -
> > 9 files changed, 195 insertions(+), 90 deletions(-)
> > rename {arch/arm/mach-socfpga/include/mach =>
> > drivers/ddr/altera}/sdram_s10.h (97%)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 77a534f81fd..a2d4f7f4c25 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -821,14 +821,14 @@ config ARCH_SOCFPGA
> > select DM_SERIAL
> > select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 ||
> > TARGET_SOCFPGA_ARRIA10
> > select OF_CONTROL
> > - select RAM if TARGET_SOCFPGA_GEN5
> > + select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> > select SPL_DM_RESET if DM_RESET
> > select SPL_DM_SERIAL
> > select SPL_LIBCOMMON_SUPPORT
> > select SPL_LIBGENERIC_SUPPORT
> > select SPL_NAND_SUPPORT if SPL_NAND_DENALI
> > select SPL_OF_CONTROL
> > - select SPL_RAM if TARGET_SOCFPGA_GEN5
> > + select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> > select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
> > select SPL_SERIAL_SUPPORT
> > select SPL_WATCHDOG_SUPPORT
> > diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> > b/arch/arm/dts/socfpga_stratix10.dtsi
> > index ee93725d648..15d0f88f182 100644
> > --- a/arch/arm/dts/socfpga_stratix10.dtsi
> > +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> > @@ -245,6 +245,16 @@
> > u-boot,dm-pre-reloc;
> > };
> >
> > + sdr: sdr@f8000400 {
> > +compatible = "altr,sdr-ctl-s10";
> > +reg = <0xf8000400 0x80>,
> > + <0xf801 0x190>,
> > + <0xf8011000 0x500>;
> > +resets = < DDRSCH_RESET>;
> > +u-boot,dm-pre-reloc;
> > +status = "disabled";
>
> Why is this optional? The SPL won't work without that any more by default,
> or would it? I would have thought it's enabled by default?
Customer can use either SDRAM controller in HPS or in FPGA.
We don't need this driver if SDRAM controller is in FPGA. All
initialization process will handled by HW.
I think we just need a very simple sdram driver for sdram controller
in FPGA, just to setup get_info().
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 06/11] cmd: bootefi: carve out efi_selftest code from do_bootefi()
On Wed, Mar 27, 2019 at 07:45:36AM +0100, Heinrich Schuchardt wrote:
> On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> > This is a preparatory patch for reworking do_bootefi() in later patch.
> >
> > Efi_selftest code is unusual in terms of execution path in do_bootefi(),
> > which make that function complicated and hard to understand. With this
> > patch, all efi_selftest related code will be put in a separate function.
> >
> > The change also includes expanding efi_run_prepare() and efi_run_finish()
> > in do_bootefi_exec().
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/bootefi.c | 145 +++---
> > 1 file changed, 90 insertions(+), 55 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index ce0db07f8633..1267d895472c 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -221,39 +221,6 @@ static efi_status_t efi_install_fdt(const char
> > *fdt_opt)
> > return EFI_SUCCESS;
> > }
> >
> > -static efi_status_t bootefi_run_prepare(const char *load_options_path,
> > - struct efi_device_path *device_path,
> > - struct efi_device_path *image_path,
> > - struct efi_loaded_image_obj **image_objp,
> > - struct efi_loaded_image **loaded_image_infop)
> > -{
> > - efi_status_t ret;
> > -
> > - ret = efi_setup_loaded_image(device_path, image_path, image_objp,
> > -loaded_image_infop);
> > - if (ret != EFI_SUCCESS)
> > - return ret;
> > -
> > - /* Transfer environment variable as load options */
> > - set_load_options(*loaded_image_infop, load_options_path);
> > -
> > - return 0;
> > -}
> > -
> > -/**
> > - * bootefi_run_finish() - finish up after running an EFI test
> > - *
> > - * @loaded_image_info: Pointer to a struct which holds the loaded image
> > info
> > - * @image_objj: Pointer to a struct which holds the loaded image object
> > - */
> > -static void bootefi_run_finish(struct efi_loaded_image_obj *image_obj,
> > - struct efi_loaded_image *loaded_image_info)
> > -{
> > - efi_restore_gd();
> > - free(loaded_image_info->load_options);
> > - efi_delete_handle(_obj->header);
> > -}
> > -
> > /**
> > * do_bootefi_exec() - execute EFI binary
> > *
> > @@ -300,11 +267,14 @@ static efi_status_t do_bootefi_exec(void *efi,
> > assert(device_path && image_path);
> > }
> >
> > - ret = bootefi_run_prepare("bootargs", device_path, image_path,
> > - _obj, _image_info);
> > + ret = efi_setup_loaded_image(device_path, image_path, _obj,
> > +_image_info);
> > if (ret)
> > goto err_prepare;
> >
> > + /* Transfer environment variable as load options */
> > + set_load_options(loaded_image_info, "bootargs");
> > +
> > /* Load the EFI payload */
> > ret = efi_load_pe(image_obj, efi, loaded_image_info);
> > if (ret != EFI_SUCCESS)
> > @@ -328,7 +298,9 @@ static efi_status_t do_bootefi_exec(void *efi,
> >
> > err_prepare:
> > /* image has returned, loaded-image obj goes *poof*: */
> > - bootefi_run_finish(image_obj, loaded_image_info);
> > + efi_restore_gd();
> > + free(loaded_image_info->load_options);
> > + efi_delete_handle(_obj->header);
>
> Deletion of the image and the handle should be handled by Exit() or
> UnloadImage(). But maybe we should leave that to correction to a later
> patch. Please, add a TODO comment here.
I don't think we need a comment here.
Those code will be eventually replaced by efi_unload_image() in patch#10.
> >
> > err_add_protocol:
> > if (mem_handle)
> > @@ -338,6 +310,25 @@ err_add_protocol:
> > }
> >
> > #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> > +static efi_status_t bootefi_run_prepare(const char *load_options_path,
> > + struct efi_device_path *device_path,
> > + struct efi_device_path *image_path,
> > + struct efi_loaded_image_obj **image_objp,
> > + struct efi_loaded_image **loaded_image_infop)
> > +{
> > + efi_status_t ret;
> > +
> > + ret = efi_setup_loaded_image(device_path, image_path, image_objp,
> > +loaded_image_infop);
> > + if (ret != EFI_SUCCESS)
> > + return ret;
> > +
> > + /* Transfer environment variable as load options */
> > + set_load_options(*loaded_image_infop, load_options_path);
> > +
> > + return 0;
> > +}
> > +
> > /**
> > * bootefi_test_prepare() - prepare to run an EFI test
> > *
> > @@ -383,6 +374,62 @@ failure:
> > return ret;
> > }
> >
> > +/**
> > + * bootefi_run_finish() - finish up after running an EFI test
> > + *
> > + * @loaded_image_info: Pointer to a struct which holds the loaded image
> > info
> > + * @image_objj: Pointer to a struct which holds the loaded image object
> > + */
> > +static void bootefi_run_finish(struct efi_loaded_image_obj *image_obj,
> > + struct efi_loaded_image
Re: [U-Boot] [RFC v2 05/11] cmd: bootefi: merge efi_install_fdt() and efi_process_fdt()
On Wed, Mar 27, 2019 at 07:33:49AM +0100, Heinrich Schuchardt wrote:
> On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> > This is a preparatory patch for reworking do_bootefi() in later patch.
> > For simplicity, merge two functions.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/bootefi.c | 67 +--
> > 1 file changed, 28 insertions(+), 39 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index aba8b203d419..ce0db07f8633 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -165,41 +165,8 @@ static void efi_carve_out_dt_rsv(void *fdt)
> > }
> > }
> >
> > -static efi_status_t efi_install_fdt(ulong fdt_addr)
> > -{
> > - bootm_headers_t img = { 0 };
> > - efi_status_t ret;
> > - void *fdt;
> > -
> > - fdt = map_sysmem(fdt_addr, 0);
> > - if (fdt_check_header(fdt)) {
> > - printf("ERROR: invalid device tree\n");
> > - return EFI_INVALID_PARAMETER;
> > - }
> > -
> > - /* Create memory reservation as indicated by the device tree */
> > - efi_carve_out_dt_rsv(fdt);
> > -
> > - /* Prepare fdt for payload */
> > - ret = copy_fdt();
> > - if (ret)
> > - return ret;
> > -
> > - if (image_setup_libfdt(, fdt, 0, NULL)) {
> > - printf("ERROR: failed to process device tree\n");
> > - return EFI_LOAD_ERROR;
> > - }
> > -
> > - /* Link to it in the efi tables */
> > - ret = efi_install_configuration_table(_guid_fdt, fdt);
> > - if (ret != EFI_SUCCESS)
> > - return EFI_OUT_OF_RESOURCES;
> > -
> > - return ret;
> > -}
> > -
> > /**
> > - * efi_process_fdt() - process fdt passed by a command argument
> > + * efi_install_fdt() - install fdt passed by a command argument
> > * @fdt_opt: pointer to argument
> > * Return: CMD_RET_SUCCESS on success,
> > CMD_RET_USAGE or CMD_RET_FAILURE otherwise
> > @@ -207,21 +174,43 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
> > * If specified, fdt will be installed as configuration table,
> > * otherwise no fdt will be passed.
> > */
> > -static efi_status_t efi_process_fdt(const char *fdt_opt)
> > +static efi_status_t efi_install_fdt(const char *fdt_opt)
> > {
> > unsigned long fdt_addr;
> > + void *fdt;
> > + bootm_headers_t img = { 0 };
> > efi_status_t ret;
> >
> > if (fdt_opt) {
> > + /* Install device tree */
> > fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
> > if (!fdt_addr && *fdt_opt != '0')
> > return EFI_INVALID_PARAMETER;
> >
> > - /* Install device tree */
> > - ret = efi_install_fdt(fdt_addr);
> > + fdt = map_sysmem(fdt_addr, 0);
> > + if (fdt_check_header(fdt)) {
> > + printf("ERROR: invalid device tree\n");
> > + return EFI_INVALID_PARAMETER;
> > + }
> > +
> > + /* Create memory reservation as indicated by the device tree */
> > + efi_carve_out_dt_rsv(fdt);
> > +
> > + /* Prepare fdt for payload */
> > + ret = copy_fdt();
> > + if (ret)
> > + return ret;
> > +
> > + if (image_setup_libfdt(, fdt, 0, NULL)) {
> > + printf("ERROR: failed to process device tree\n");
> > + return EFI_LOAD_ERROR;
> > + }
> > +
> > + /* Link to it in the efi tables */
> > + ret = efi_install_configuration_table(_guid_fdt, fdt);
> > if (ret != EFI_SUCCESS) {
> > printf("ERROR: failed to install device tree\n");
> > - return ret;
> > + return EFI_OUT_OF_RESOURCES;
> > }
> > } else {
> > /* Remove device tree. EFI_NOT_FOUND can be ignored here */
> > @@ -441,7 +430,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
> > argc, char * const argv[])
> > if (argc < 2)
> > return CMD_RET_USAGE;
> >
> > - r = fdt_process_fdt(argc > 2 ? argv[2] : NULL);
> > + r = fdt_install_fdt(argc > 2 ? argv[2] : NULL);
> > if (r != EFI_SUCCESS)
> > return r;
>
> We want to return CMD_RET_* from do_bootefi() and not EFI_*.
Right, will fix.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 04/11] cmd: bootefi: carve out fdt handling from do_bootefi()
On Wed, Mar 27, 2019 at 07:29:50AM +0100, Heinrich Schuchardt wrote:
> On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> > This is a preparatory patch for reworking do_bootefi() in later patch.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/bootefi.c | 53 ---
> > 1 file changed, 38 insertions(+), 15 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 3619a20e6433..aba8b203d419 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -198,6 +198,40 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
> > return ret;
> > }
> >
> > +/**
> > + * efi_process_fdt() - process fdt passed by a command argument
> > + * @fdt_opt: pointer to argument
> > + * Return: CMD_RET_SUCCESS on success,
> > + CMD_RET_USAGE or CMD_RET_FAILURE otherwise
>
> This does not match the actual return values.
Oops, re-organizing my patch-set introduced this obvious bug.
> > + *
> > + * If specified, fdt will be installed as configuration table,
> > + * otherwise no fdt will be passed.
> > + */
> > +static efi_status_t efi_process_fdt(const char *fdt_opt)
> > +{
> > + unsigned long fdt_addr;
> > + efi_status_t ret;
> > +
> > + if (fdt_opt) {
> > + fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
> > + if (!fdt_addr && *fdt_opt != '0')
> > + return EFI_INVALID_PARAMETER;
> > +
> > + /* Install device tree */
> > + ret = efi_install_fdt(fdt_addr);
> > + if (ret != EFI_SUCCESS) {
> > + printf("ERROR: failed to install device tree\n");
> > + return ret;
> > + }
> > + } else {
> > + /* Remove device tree. EFI_NOT_FOUND can be ignored here */
> > + efi_install_configuration_table(_guid_fdt, NULL);
> > + printf("WARNING: booting without device tree\n");
>
> As x86 does not require a device tree, please, remove this message.
Okay, but I didn't change this message from the original :)
> > + }
> > +
> > + return EFI_SUCCESS;
> > +}
> > +
> > static efi_status_t bootefi_run_prepare(const char *load_options_path,
> > struct efi_device_path *device_path,
> > struct efi_device_path *image_path,
> > @@ -407,21 +441,10 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
> > argc, char * const argv[])
> > if (argc < 2)
> > return CMD_RET_USAGE;
> >
> > - if (argc > 2) {
> > - fdt_addr = simple_strtoul(argv[2], NULL, 16);
> > - if (!fdt_addr && *argv[2] != '0')
> > - return CMD_RET_USAGE;
> > - /* Install device tree */
> > - r = efi_install_fdt(fdt_addr);
> > - if (r != EFI_SUCCESS) {
> > - printf("ERROR: failed to install device tree\n");
> > - return CMD_RET_FAILURE;
> > - }
> > - } else {
> > - /* Remove device tree. EFI_NOT_FOUND can be ignored here */
> > - efi_install_configuration_table(_guid_fdt, NULL);
> > - printf("WARNING: booting without device tree\n");
> > - }
> > + r = fdt_process_fdt(argc > 2 ? argv[2] : NULL);
> > + if (r != EFI_SUCCESS)
> > + return r;
>
> Now you return EFI_INVALID_PARAMETER instead of CMD_RET_USAGE.
Okay, will fix.
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > +
> > #ifdef CONFIG_CMD_BOOTEFI_HELLO
> > if (!strcmp(argv[1], "hello")) {
> > ulong size = __efi_helloworld_end - __efi_helloworld_begin;
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rockchip: arm: remove no use macro
Signed-off-by: Kever Yang --- arch/arm/include/asm/arch-rockchip/hardware.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/hardware.h b/arch/arm/include/asm/arch-rockchip/hardware.h index cd94bdd1ba..62e8bed8f3 100644 --- a/arch/arm/include/asm/arch-rockchip/hardware.h +++ b/arch/arm/include/asm/arch-rockchip/hardware.h @@ -10,8 +10,6 @@ #define RK_SETBITS(set)RK_CLRSETBITS(0, set) #define RK_CLRBITS(clr)RK_CLRSETBITS(clr, 0) -#define TIMER7_BASE0xff810020 - #define rk_clrsetreg(addr, clr, set) \ writel(((clr) | (set)) << 16 | (set), addr) #define rk_clrreg(addr, clr) writel((clr) << 16, addr) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 03/11] efi_loader: device_path: handle special case of loading
On Wed, Mar 27, 2019 at 07:17:02AM +0100, Heinrich Schuchardt wrote:
> On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> > This is a preparatory patch.
> >
> > efi_dp_split_file_path() is used to create device_path and file_path
> > from file_path for efi_setup_loaded_image().
> > In a special case, however, of HARDWARE_DEVICE/MEMORY, it doesn't
> > work expectedly since this path doesn't contain any FILE_PATH sub-type.
>
> As already mentioned in a comment to patch 1/11 I would prefer that we
> pass the original device path to efi_setup_loaded_image() instead of
> recombining device path and file path there again.
This change would only come, as I said, after do_efi_selftest() is
also refactored.
Thanks,
-Takahiro Akashi
> This would avoid special treatment here with possible side effects in
> efi_fs_from_path().
>
> Best regards
>
> Heinrich
>
> >
> > This patch makes a workaround.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > lib/efi_loader/efi_device_path.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_device_path.c
> > b/lib/efi_loader/efi_device_path.c
> > index 53b40c8c3c2d..e283fad767ed 100644
> > --- a/lib/efi_loader/efi_device_path.c
> > +++ b/lib/efi_loader/efi_device_path.c
> > @@ -933,6 +933,14 @@ efi_status_t efi_dp_split_file_path(struct
> > efi_device_path *full_path,
> > dp = efi_dp_dup(full_path);
> > if (!dp)
> > return EFI_OUT_OF_RESOURCES;
> > +
> > + if (EFI_DP_TYPE(dp, HARDWARE_DEVICE, MEMORY)) {
> > + /* no FILE_PATH */
> > + *device_path = dp;
> > +
> > + return EFI_SUCCESS;
> > + }
> > +
> > p = dp;
> > while (!EFI_DP_TYPE(p, MEDIA_DEVICE, FILE_PATH)) {
> > p = efi_dp_next(p);
> >
>
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 01/11] efi_loader: boottime: add loaded image device path protocol to image handle
On Wed, Mar 27, 2019 at 06:58:31AM +0100, Heinrich Schuchardt wrote:
> On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> > To meet UEFI spec v2.7a section 9.2, we should add
> > EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL to image handle,
> > instead of EFI_DEVICE_PATH_PROTOCOL.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > include/efi_api.h | 4
> > include/efi_loader.h | 1 +
> > lib/efi_loader/efi_boottime.c | 19 ---
> > lib/efi_loader/efi_image_loader.c | 2 ++
> > 4 files changed, 19 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/efi_api.h b/include/efi_api.h
> > index ccf608653d4a..63b703c951a7 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -333,6 +333,10 @@ struct efi_system_table {
> > EFI_GUID(0x5b1b31a1, 0x9562, 0x11d2, \
> > 0x8e, 0x3f, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
> >
> > +#define LOADED_IMAGE_DEVICE_PATH_GUID \
> > + EFI_GUID(0xbc62157e, 0x3e33, 0x4fec, \
> > +0x99, 0x20, 0x2d, 0x3b, 0x36, 0xd7, 0x50, 0xdf)
> > +
> > #define EFI_LOADED_IMAGE_PROTOCOL_REVISION 0x1000
> >
> > struct efi_loaded_image {
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 512880ab8fbf..3f54e354bdcd 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -135,6 +135,7 @@ extern const efi_guid_t
> > efi_guid_event_group_reset_system;
> > /* GUID of the device tree table */
> > extern const efi_guid_t efi_guid_fdt;
> > extern const efi_guid_t efi_guid_loaded_image;
> > +extern const efi_guid_t efi_guid_loaded_image_device_path;
> > extern const efi_guid_t efi_guid_device_path_to_text_protocol;
> > extern const efi_guid_t efi_simple_file_system_protocol_guid;
> > extern const efi_guid_t efi_file_info_guid;
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index 391681260c27..578b32a05ffd 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -1519,6 +1519,7 @@ efi_status_t efi_setup_loaded_image(struct
> > efi_device_path *device_path,
> > efi_status_t ret;
> > struct efi_loaded_image *info = NULL;
> > struct efi_loaded_image_obj *obj = NULL;
> > + struct efi_device_path *dp;
> >
> > /* In case of EFI_OUT_OF_RESOURCES avoid illegal free by caller. */
> > *handle_ptr = NULL;
> > @@ -1542,15 +1543,19 @@ efi_status_t efi_setup_loaded_image(struct
> > efi_device_path *device_path,
> >
> > if (device_path) {
> > info->device_handle = efi_dp_find_obj(device_path, NULL);
> > - /*
> > -* When asking for the device path interface, return
> > -* bootefi_device_path
> > -*/
> > - ret = efi_add_protocol(>header,
> > - _guid_device_path, device_path);
> > - if (ret != EFI_SUCCESS)
> > +
> > + dp = efi_dp_append(device_path, file_path);
>
> I think we should pass the original device_path as a parameter to
> efi_setup_loaded_image instead of first splitting and then recombining
> devicepath elements.
Agree, but I didn't modify the code because efi_setup_loaded_image()
is still used to load "efi_selftest" in bootefi.
I hope that you will work on do_efi_selftest().
> But let's leave this as a TODO after the rest of the refactoring.
>
> > + if (!dp) {
> > + ret = EFI_OUT_OF_RESOURCES;
> > goto failure;
> > + }
> > + } else {
> > + dp = NULL;
> > }
> > + ret = efi_add_protocol(>header,
> > + _guid_loaded_image_device_path, dp);
>
> I wondered about the loaded imaged device path protocol possibly being
> NULL. But the spec explicitely states:
>
> It is legal to call LoadImage() for a buffer in memory with a NULL
> DevicePath parameter. In this case, the Loaded Image Device Path
> Protocol is installed with a NULL interface pointer.
Right, I have also found this statement.
-Takahiro Akashi
> Reviewed-by: Heinrich Schuchardt
>
> > + if (ret != EFI_SUCCESS)
> > + goto failure;
> >
> > /*
> > * When asking for the loaded_image interface, just
> > diff --git a/lib/efi_loader/efi_image_loader.c
> > b/lib/efi_loader/efi_image_loader.c
> > index fe66e7b9ffe1..c6177b9ff832 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -14,6 +14,8 @@
> > const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
> > const efi_guid_t efi_guid_device_path = DEVICE_PATH_GUID;
> > const efi_guid_t efi_guid_loaded_image = LOADED_IMAGE_GUID;
> > +const efi_guid_t efi_guid_loaded_image_device_path
> > + = LOADED_IMAGE_DEVICE_PATH_GUID;
> > const efi_guid_t efi_simple_file_system_protocol_guid =
> > EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
> > const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
> >
>
___
U-Boot
Re: [U-Boot] [PATCH 1/1] efi_loader: update TODOs in doc/README.uefi
Hi Heinrich, As a matter of fact and strictly speaking, there are bunch of missing features; * Boot manager (section 3) - boot manager policy - support for some of Boot option variables - boot recovery * various protocols, - from section 11 to section 20 and - from section 24 to section 30 * Firmware Update (Spec section 23) * UEFI Byte Code(EBC) machine (Spec section 22) * Secure boot (Spec section 31) * Support for some of HII packages (section 33) * HII configuration protocols (section 34) * security protocols (section 36) * Variables - support for authentication I don't think that we should list all of them, but we should definitely describe the *criteria* for what features be implemented and what not. # Personally, I'd like to add "integration of DM and UEFI objects" :) Thanks, -Takahiro Akashi On Wed, Mar 27, 2019 at 10:07:03PM +0100, Heinrich Schuchardt wrote: > The following TODOs are closed: > > - GetNextVariableName is not implemented > - event groups > - manage events in a linked list > > Signed-off-by: Heinrich Schuchardt > --- > doc/README.uefi | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/doc/README.uefi b/doc/README.uefi > index cda29cdcf7..b38efbc0cc 100644 > --- a/doc/README.uefi > +++ b/doc/README.uefi > @@ -299,7 +299,7 @@ This driver is only available if U-Boot is configured with > CONFIG_BLK=y > CONFIG_PARTITIONS=y > > -## TODOs as of U-Boot 2018.07 > +## TODOs as of U-Boot 2019.04 > > * unimplemented or incompletely implemented boot services >* Exit - call unload function, unload applications only > @@ -308,16 +308,13 @@ This driver is only available if U-Boot is configured > with > > * unimplemented or incompletely implemented runtime services >* SetVariable() ignores attribute EFI_VARIABLE_APPEND_WRITE > - * GetNextVariableName is not implemented >* QueryVariableInfo is not implemented > > * unimplemented events >* EVT_RUNTIME >* EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE > - * event groups > > * data model > - * manage events in a linked list >* manage configuration tables in a linked list > > * UEFI drivers > -- > 2.20.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] bootm: Simplying cache flush code
The cache flush of the kernel load area needs to be aligned outward to
the DMA cache alignment. The operations are simpler if we think of this
as aligning the start down, ALIGN_DOWN(load, ARCH_DMA_MINALIGN), and
aligning the end up, ALIGN(load_end, ARCH_DMA_MINALIGN), and then find
the length of the flushed region by subtracting the former from the
latter.
Cc: Tom Rini
Cc: Simon Glass
Cc: Bryan O'Donoghue
Signed-off-by: Trent Piepho
---
common/bootm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index 8bf84ebcb7..8af8efd169 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -453,7 +453,6 @@ static int bootm_load_os(bootm_headers_t *images, int
boot_progress)
ulong image_start = os.image_start;
ulong image_len = os.image_len;
ulong flush_start = ALIGN_DOWN(load, ARCH_DMA_MINALIGN);
- ulong flush_len;
bool no_overlap;
void *load_buf, *image_buf;
int err;
@@ -468,11 +467,7 @@ static int bootm_load_os(bootm_headers_t *images, int
boot_progress)
return err;
}
- flush_len = load_end - load;
- if (flush_start < load)
- flush_len += load - flush_start;
-
- flush_cache(flush_start, ALIGN(flush_len, ARCH_DMA_MINALIGN));
+ flush_cache(flush_start, ALIGN(load_end, ARCH_DMA_MINALIGN) -
flush_start);
debug(" kernel loaded at 0x%08lx, end = 0x%08lx\n", load, load_end);
bootstage_mark(BOOTSTAGE_ID_KERNEL_LOADED);
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pico-imx7d: README: Recommend the usage of a USB hub
Since commit 9e3c0174da842 ("pico-imx7d: Add LCD support") we started to
notice some hangs in U-Boot.
There is not an issue on such commit per se, but due to the LCD support
the current drawn is increased and this may cause issues when powering
pico-imx7d-pi from USB.
Some computers may be a bit strict with USB current draw and will
shut down their ports if the draw is too high.
The solution for that is to use an externally powered USB hub between the
board and the host computer.
Add such recommendation to the README file.
Signed-off-by: Fabio Estevam
---
board/technexion/pico-imx7d/README | 4
1 file changed, 4 insertions(+)
diff --git a/board/technexion/pico-imx7d/README
b/board/technexion/pico-imx7d/README
index 24eb97e82c..f21d8301cb 100644
--- a/board/technexion/pico-imx7d/README
+++ b/board/technexion/pico-imx7d/README
@@ -26,6 +26,10 @@ Connect a USB to serial adapter between the host PC and pico.
Connect a USB cable between the OTG pico port and the host PC.
+Note: Some computers may be a bit strict with USB current draw and will
+shut down their ports if the draw is too high. The solution for that is
+to use an externally powered USB hub between the board and the host computer.
+
Open a terminal program such as minicom.
Copy SPL and u-boot.img to the imx_usb_loader folder.
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/1] efi_loader: bootmgr: support BootNext and BootCurrent variable behavior
On 3/20/19 8:01 AM, Heinrich Schuchardt wrote:
> On 3/20/19 1:07 AM, AKASHI Takahiro wrote:
>> See UEFI v2.7, section 3.1.2 for details of the specification.
>>
>> With efidebug command, you can run any EFI boot option as follows:
>> => efi boot add 1 SHELL ...
>> => efi boot add 2 HELLO ...
>> => efi boot order 1 2
>> => efi bootmgr
>> (starting SHELL ...)
>>
>> => efi boot next 2
>> => efi bootmgr
>> (starting HELLO ...)
>> => env print -e
>>
>> BootCurrent: {boot,run}(blob)
>> : 02 00..
>> BootOrder: {boot,run}(blob)
>> : 01 00 02 00
>>
>> Signed-off-by: AKASHI Takahiro
>
> Reviewed-by: Heinrich Schuchardt
>
Added to efi-2019-07 branch.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 02/11] efi_loader: boottime: export efi_[un]load_image()
On 3/27/19 5:40 AM, AKASHI Takahiro wrote: > This is a preparatory patch. > Those two functions will be used later for reworking do_bootefi(). > > Signed-off-by: AKASHI Takahiro > Reviewed-by: Heinrich Schuchardt Added to for efi-2019-07 branch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 01/11] efi_loader: boottime: add loaded image device path protocol to image handle
On 3/27/19 6:58 AM, Heinrich Schuchardt wrote: > On 3/27/19 5:40 AM, AKASHI Takahiro wrote: >> To meet UEFI spec v2.7a section 9.2, we should add >> EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL to image handle, >> instead of EFI_DEVICE_PATH_PROTOCOL. >> >> Signed-off-by: AKASHI Takahiro >> --- Reviewed-by: Heinrich Schuchardt Added to for efi-2019-07 branch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: update TODOs in doc/README.uefi
The following TODOs are closed: - GetNextVariableName is not implemented - event groups - manage events in a linked list Signed-off-by: Heinrich Schuchardt --- doc/README.uefi | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/doc/README.uefi b/doc/README.uefi index cda29cdcf7..b38efbc0cc 100644 --- a/doc/README.uefi +++ b/doc/README.uefi @@ -299,7 +299,7 @@ This driver is only available if U-Boot is configured with CONFIG_BLK=y CONFIG_PARTITIONS=y -## TODOs as of U-Boot 2018.07 +## TODOs as of U-Boot 2019.04 * unimplemented or incompletely implemented boot services * Exit - call unload function, unload applications only @@ -308,16 +308,13 @@ This driver is only available if U-Boot is configured with * unimplemented or incompletely implemented runtime services * SetVariable() ignores attribute EFI_VARIABLE_APPEND_WRITE - * GetNextVariableName is not implemented * QueryVariableInfo is not implemented * unimplemented events * EVT_RUNTIME * EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE - * event groups * data model - * manage events in a linked list * manage configuration tables in a linked list * UEFI drivers -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: TODO for the EFI file protocol
We currently only support EFI_FILE_PROTOCOL_REVISION while
UEFI specs 2.4 - 2.7 prescribe EFI_FILE_PROTOCOL_REVISION2.
Add a todo.
Add missing constants for the EFI file protocol revision.
Signed-off-by: Heinrich Schuchardt
---
doc/README.uefi | 3 +++
include/efi_api.h | 8 +++-
lib/efi_loader/efi_file.c | 4
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/README.uefi b/doc/README.uefi
index 0982fad92e..cda29cdcf7 100644
--- a/doc/README.uefi
+++ b/doc/README.uefi
@@ -329,6 +329,9 @@ This driver is only available if U-Boot is configured with
* persistence
* runtime support
+* incompletely implemented protocols
+ * support version 0x0002 of the EFI file protocol
+
## Links
* [1](http://uefi.org/specifications)
diff --git a/include/efi_api.h b/include/efi_api.h
index 63b703c951..407acacc81 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -1326,7 +1326,9 @@ struct efi_pxe {
#define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \
EFI_GUID(0x964e5b22, 0x6459, 0x11d2, \
0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
-#define EFI_FILE_PROTOCOL_REVISION 0x0001
+#define EFI_FILE_PROTOCOL_REVISION 0x0001
+#define EFI_FILE_PROTOCOL_REVISION20x0002
+#define EFI_FILE_PROTOCOL_LATEST_REVISION EFI_FILE_PROTOCOL_REVISION2
struct efi_file_handle {
u64 rev;
@@ -1350,6 +1352,10 @@ struct efi_file_handle {
const efi_guid_t *info_type, efi_uintn_t buffer_size,
void *buffer);
efi_status_t (EFIAPI *flush)(struct efi_file_handle *file);
+ /*
+* TODO: We currently only support EFI file protocol revision 0x0001
+* while UEFI specs 2.4 - 2.7 prescribe revision 0x0002.
+*/
};
#define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_REVISION 0x0001
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index bc715218a1..f2843cad2d 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -628,6 +628,10 @@ static efi_status_t EFIAPI efi_file_flush(struct
efi_file_handle *file)
}
static const struct efi_file_handle efi_file_handle_protocol = {
+ /*
+* TODO: We currently only support EFI file protocol revision 0x0001
+* while UEFI specs 2.4 - 2.7 prescribe revision 0x0002.
+*/
.rev = EFI_FILE_PROTOCOL_REVISION,
.open = efi_file_open,
.close = efi_file_close,
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,V4,1/2] mmc: add HS400 support
I didn't see HS400 working on my IMX7d, even thought it appears it
should be supported.
The problem appears to be when this bit of code in fsl_esdhc.c, which
dates to a patch "mmc: fsl_esdhc: support SDR104 and HS200":
static struct esdhc_soc_data usdhc_imx7d_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
| ESDHC_FLAG_HS400,
.caps = UHS_CAPS | MMC_MODE_HS200 | MMC_MODE_DDR_52MHz |
MMC_MODE_HS_52MHz | MMC_MODE_HS,
};
Notice that MMC_MODE_HS400 isn't in the caps list. Once I add that
uboot will attempt HS400 and it appears to work correctly.
I think maybe this patch should have added this to the caps?
Alternatively, there is a property that can be added to the device
tree, mmc-hs400-1_8v, that will add this cap. But the code to parse
those dt properties, mmc_of_parse(), isn't used by the fsl_esdhc
driver, which has its own parsing code that doesn't know about mmc-
hs400-1_8v.
So maybe fsl-esdhc should use mmc_of_parse() and the appropriate iMX
DTs should add those properties?
I think the DT method might be better, since it would allow the DT to
not list a mode that doesn't work due to the the board. I.e., the iMX
host supports the mode, the eMMC supports the mode, but the board
layout doesn't have traces that can support it. Too long, not matched
well enough, etc. It doesn't seem like there's an nice way to remove a
mode otherwise.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/6] dlmalloc: be compatible to tiny printf
Convert debug output from '%#lx' to '0x%lx' to be compatible with tiny
printf used in SPL.
Signed-off-by: Simon Goldschmidt
---
Changes in v3: None
Changes in v2: None
common/dlmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 51d3bd671a..af6f43dcc9 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -608,7 +608,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end--;
}
- debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
+ debug("using memory 0x%lx-0x%lx for malloc()\n", mem_malloc_start,
mem_malloc_end);
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
memset((void *)mem_malloc_start, 0x0, size);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 5/6] spl: support using full malloc with SYS_MALLOC_F_LEN
Some platforms (like socfpga A10) need a big heap before SDRAM is available (e.g. because FAT is used). For such platforms, simple_malloc is often not a good option as it does not support freeing memory. These platforms often use the non-Kconfig defines CONFIG_SYS_SPL_MALLOC_START (and its SIZE). This patch allows enabling CONFIG_SPL_SYS_MALLOC_F_LEN while leaving CONFIG_SPL_SYS_MALLOC_SIMPLE disabled. In this case, the full malloc heap is made available as early as the simple_malloc heap would be normally. This way, platforms can drop the non-Kconfig options to set up the full heap and rely on the same automatically calculated heap allocation used for simple heap. Signed-off-by: Simon Goldschmidt --- Changes in v3: None Changes in v2: - use if() instead of #if - adapt documentation to using CONFIG_SPL_SYS_MALLOC_F_LEN for full-featured heap as well - ensure SPL_CLEAR_BSS_F is set when using SYS_MALLOC_F_LEN for full featured heap (or else, the heap status stored in bss will be overwritten between board_init_f and board_init_r) Kconfig | 24 README | 15 +++ common/spl/spl.c | 10 -- drivers/core/Kconfig | 33 - 4 files changed, 51 insertions(+), 31 deletions(-) diff --git a/Kconfig b/Kconfig index 305b265ed7..e4165692d1 100644 --- a/Kconfig +++ b/Kconfig @@ -155,22 +155,30 @@ config SYS_MALLOC_LEN config SPL_SYS_MALLOC_F_LEN hex "Size of malloc() pool in SPL before relocation" depends on SYS_MALLOC_F + depends on SPL_SYS_MALLOC_SIMPLE || SPL_CLEAR_BSS_F default SYS_MALLOC_F_LEN help - Before relocation, memory is very limited on many platforms. Still, - we can provide a small malloc() pool if needed. Driver model in - particular needs this to operate, so that it can allocate the - initial serial device and any others that are needed. + Before relocation (before calling board_init_r, that is), memory is + very limited on many platforms. Still, we can provide a small + malloc() pool if needed. Driver model in particular needs this to + operate, so that it can allocate the initial serial device and any + others that are needed. + This option controls the size of this initial malloc() pool by + default. config TPL_SYS_MALLOC_F_LEN hex "Size of malloc() pool in TPL before relocation" depends on SYS_MALLOC_F + depends on TPL_SYS_MALLOC_SIMPLE || SPL_CLEAR_BSS_F default SYS_MALLOC_F_LEN help - Before relocation, memory is very limited on many platforms. Still, - we can provide a small malloc() pool if needed. Driver model in - particular needs this to operate, so that it can allocate the - initial serial device and any others that are needed. + Before relocation (before calling board_init_r, that is), memory is + very limited on many platforms. Still, we can provide a small + malloc() pool if needed. Driver model in particular needs this to + operate, so that it can allocate the initial serial device and any + others that are needed. + This option controls the size of this initial malloc() pool by + default. menuconfig EXPERT bool "Configure standard U-Boot features (expert users)" diff --git a/README b/README index c9a20db34f..7c0fb8e4a7 100644 --- a/README +++ b/README @@ -2462,13 +2462,19 @@ FIT uImage format: CONFIG_SPL_STACK. CONFIG_SYS_SPL_MALLOC_START - Starting address of the malloc pool used in SPL. + This is one way of providing the starting address of the malloc + pool used in SPL. If CONFIG_SPL_SYS_MALLOC_SIMPLE isn't set, + the full-featured heap will be used and it will allocate its + memory from the initial stack if CONFIG_SPL_SYS_MALLOC_F_LEN is + != 0. If you need it to use a dedicated area, use this option + to set an absolute address for the initial heap. When this option is set the full malloc is used in SPL and it is set up by spl_init() and before that, the simple malloc() - can be used if CONFIG_SYS_MALLOC_F is defined. + can still be used if CONFIG_SPL_SYS_MALLOC_F_LEN is defined. CONFIG_SYS_SPL_MALLOC_SIZE - The size of the malloc pool used in SPL. + The size of the malloc pool used in SPL if + CONFIG_SYS_SPL_MALLOC_START is set. CONFIG_SPL_OS_BOOT Enable booting directly to an OS from SPL. @@ -2743,7 +2749,8 @@ Configuration Settings: - CONFIG_SYS_MALLOC_SIMPLE Provides a simple and small malloc() and calloc() for those boards which do not use the full malloc in SPL (which is -
[U-Boot] [PATCH v3 3/6] dlmalloc: fix malloc range at end of ram
If the malloc range passed to mem_malloc_init() is at the end of address
range and 'start + size' overflows to 0, following allocations fail as
mem_malloc_end is zero (which looks like uninitialized).
Fix this by subtracting 1 of 'start + size' overflows to zero.
Signed-off-by: Simon Goldschmidt
---
Changes in v3: None
Changes in v2: None
common/dlmalloc.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index edaad299bb..51d3bd671a 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -603,6 +603,10 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
+ if (start && size && !mem_malloc_end) {
+ /* overflow: malloc area is at end of address range */
+ mem_malloc_end--;
+ }
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
mem_malloc_end);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/6] arm: socfpga: a10: move SPL heap size to Kconfig
Instead of fixing the SPL heap to 64 KiB in the board config header via
CONFIG_SYS_SPL_MALLOC_SIZE, let's just use CONFIG_SPL_SYS_MALLOC_F_LEN
in the defconfig.
This also has the advantage that it removes sub-mach specific ifdefs in
socfpga_common.h.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- fixed summary ("stack" -> "heap")
- enable CONFIG_SPL_CLEAR_BSS_F for socfpga_arria10 using full malloc
early in SPL
- rebased
Changes in v2: None
configs/socfpga_arria10_defconfig | 2 ++
include/configs/socfpga_common.h | 14 --
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig
b/configs/socfpga_arria10_defconfig
index f321a0ac3b..094232e847 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
CONFIG_ARCH_SOCFPGA=y
CONFIG_SYS_TEXT_BASE=0x0140
CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x1
CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y
CONFIG_SPL=y
CONFIG_IDENT_STRING="socfpga_arria10"
@@ -13,6 +14,7 @@ CONFIG_BOOTARGS="console=ttyS0,115200"
CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb"
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOUNCE_BUFFER=y
+CONFIG_SPL_CLEAR_BSS_F=y
CONFIG_SPL_FPGA_SUPPORT=y
CONFIG_SPL_SPI_LOAD=y
CONFIG_CMD_ASKENV=y
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 09c9b7ca9e..24f8665c24 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -252,16 +252,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
#define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
#endif
-#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
-/* SPL memory allocation configuration, this is for FAT implementation */
-#ifndef CONFIG_SYS_SPL_MALLOC_START
-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
-#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \
-CONFIG_SYS_SPL_MALLOC_SIZE + \
-CONFIG_SYS_INIT_RAM_ADDR)
-#endif
-#endif
-
/* SPL SDMMC boot support */
#ifdef CONFIG_SPL_MMC_SUPPORT
#if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
@@ -295,11 +285,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
/*
* Stack setup
*/
-#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
-#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
-#define CONFIG_SPL_STACK CONFIG_SYS_SPL_MALLOC_START
-#endif
/* Extra Environment */
#ifndef CONFIG_SPL_BUILD
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/6] spl: arm: implement SPL_CLEAR_BSS_F
This implements the new option to clear BSS early in SPL for standard arm and arm64 crt0. BSS is cleared before calling board_init_f() and thus not cleared before calling board_init_r() as it is not relocated in SPL. Signed-off-by: Simon Goldschmidt --- Changes in v3: None Changes in v2: - add CONFIG_SPL_CLEAR_BSS_F implementation for arm64 also arch/arm/lib/crt0.S| 22 ++ arch/arm/lib/crt0_64.S | 14 ++ 2 files changed, 36 insertions(+) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index fe312db690..b06e54e144 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -80,6 +80,26 @@ ENTRY(_main) mov r9, r0 bl board_init_f_init_reserve +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_CLEAR_BSS_F) + ldr r0, =__bss_start + +#ifdef CONFIG_USE_ARCH_MEMSET + ldr r3, =__bss_end + mov r1, #0x /* prepare zero to clear BSS */ + + subsr2, r3, r0 /* r2 = memset len */ + bl memset +#else + ldr r1, =__bss_end + mov r2, #0x /* prepare zero to clear BSS */ + +clbss_l:cmpr0, r1 /* while not at end of BSS */ + strlo r2, [r0]/* clear 32-bit BSS word */ + addlo r0, r0, #4 /* move to next */ + blo clbss_l +#endif +#endif + mov r0, #0 bl board_init_f @@ -124,6 +144,7 @@ here: movne sp, r0 movne r9, r0 # endif +#if !defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SPL_CLEAR_BSS_F) ldr r0, =__bss_start/* this is auto-relocated! */ #ifdef CONFIG_USE_ARCH_MEMSET @@ -141,6 +162,7 @@ clbss_l:cmp r0, r1 /* while not at end of BSS */ addlo r0, r0, #4 /* move to next */ blo clbss_l #endif +#endif #if ! defined(CONFIG_SPL_BUILD) bl coloured_LED_init diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index d6b632aa87..82f643f737 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -86,6 +86,18 @@ ENTRY(_main) mov x18, x0 bl board_init_f_init_reserve +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_CLEAR_BSS_F) +/* + * Clear BSS section + */ + ldr x0, =__bss_start + ldr x1, =__bss_end +clear_loop: + str xzr, [x0], #8 + cmp x0, x1 + b.loclear_loop +#endif + mov x0, #0 bl board_init_f @@ -136,6 +148,7 @@ relocation_return: mov sp, x0 #endif +#if !defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SPL_CLEAR_BSS_F) /* * Clear BSS section */ @@ -145,6 +158,7 @@ clear_loop: str xzr, [x0], #8 cmp x0, x1 b.loclear_loop +#endif /* call board_init_r(gd_t *id, ulong dest_addr) */ mov x0, x18 /* gd_t */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears the bss before calling board_init_f() instead of clearing it before calling board_init_r(). This also ensures that variables placed in BSS can be shared between board_init_f() and board_init_r() in SPL. Such global variables are used, for example, when loading things from FAT before SDRAM is available: the full heap required for FAT uses global variables and clearing BSS after board_init_f() would reset the heap state. An example for such a usage is socfpa_arria10 where an FPGA configuration is required before SDRAM can be used. Make the new option depend on ARM for now until more implementations follow. Signed-off-by: Simon Goldschmidt --- Changes in v3: - improve commit message to show why CONFIG_CLEAR_BSS_F is needed Changes in v2: - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now common/spl/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 206c24076d..6a4270516a 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN to give board_init_r() a larger heap then the initial heap in SRAM which is limited to SYS_MALLOC_F_LEN bytes. +config SPL_CLEAR_BSS_F + bool "Clear BSS section before calling board_init_f" + depends on ARM + help + The BSS section is initialized to zero. In SPL, this is normally done + before calling board_init_r(). + For platforms using BSS in board_init_f() already, enable this to + clear the BSS section before calling board_init_f() instead of + clearing it before calling board_init_r(). This also ensures that + variables placed in BSS can be shared between board_init_f() and + board_init_r(). + config SPL_SEPARATE_BSS bool "BSS section is in a different memory region from text" help -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] reset: add polarity field into struct reset_ctl
On Wed, Mar 20, 2019 at 2:34 AM Shawn Guo wrote: > > Some reset controllers support different polarities for reset operation, > so let's add a polarity field into struct reset_ctl. > > Signed-off-by: Shawn Guo Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] poplar: enable Ethernet driver support
On Wed, Mar 20, 2019 at 2:34 AM Shawn Guo wrote: > > The 'phy' reset of gmac device in kernel device tree is not generic > enough for u-boot to use, so we need to overwrite the 'resets' property > as needed. With this device tree fixup and poplar_defconfig changes, > Ethernet starts working on Poplar board. > > Signed-off-by: Shawn Guo Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Add Ethernet support for Poplar board
On Tue, Mar 26, 2019 at 2:36 AM Shawn Guo wrote: > > Hi Joe, > > On Wed, Mar 20, 2019 at 03:32:37PM +0800, Shawn Guo wrote: > > The series adds Ethernet support for Poplar board. It firstly creates > > a reset driver for HiSilicon platform, then introduces higmacv300 > > Ethernet driver, and finally enables Ethernet support for Poplar board. > > > > Changes for v4: > > - Add a polarity field into struct reset_ctl. > > - Instead of defining custom macros for polarity, use generic ones > >in include/dt-bindings/reset/ti-syscon.h. > > - Use .data field as register offset and .id field as bit shift. > > How is this version? Any comments there? Looks great! Thanks! > > Shawn > > > Changes for v3: > > - Add polarity support into reset driver, so that we can drop the > >hacking on gmac reset sequence from higmacv300 driver. > > Changes for v2: > > - Rename driver symbol to HIGMACV300_ETH. > > - Remove the use of temp variable 'addr' in higmac_recv(). > > - Simplify the return of function higmac_ofdata_to_platdata() and > >higmac_probe(). > > - Combine delaration and initialization for phyintf in function > >higmac_ofdata_to_platdata(). > > - Eliminate the MDIO read/write macros. > > - Use wait_for_bit_le32() for MDIO command completion polling. > > - Set up RX packet buffers in RX_FQ descriptor at initialization time, > >so that we do not need to allocate/free packet buffers repeatedly. > > - Inform GMAC that the RX descriptor is no longer in use in function > >higmac_free_pkt(). > > - Define BITS_DESC_ENA instead of using magic number 0xf. > > > > Shawn Guo (4): > > reset: add polarity field into struct reset_ctl > > reset: add reset driver for HiSilicon platform > > net: add higmacv300 Ethernet driver for HiSilicon platform > > poplar: enable Ethernet driver support > > > > arch/arm/dts/hi3798cv200-u-boot.dtsi | 14 + > > configs/poplar_defconfig | 3 + > > drivers/net/Kconfig | 9 + > > drivers/net/Makefile | 1 + > > drivers/net/higmacv300.c | 597 +++ > > drivers/reset/Kconfig| 6 + > > drivers/reset/Makefile | 1 + > > drivers/reset/reset-hisilicon.c | 103 + > > include/reset.h | 3 + > > 9 files changed, 737 insertions(+) > > create mode 100644 drivers/net/higmacv300.c > > create mode 100644 drivers/reset/reset-hisilicon.c > > > > -- > > 2.18.0 > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] reset: add reset driver for HiSilicon platform
On Wed, Mar 20, 2019 at 2:34 AM Shawn Guo wrote: > > It adds a Driver Model compatible reset driver for HiSlicon platform. > The driver implements a custom .of_xlate function, and uses .data field > as reset register offset and .id field as bit shift. > > Signed-off-by: Shawn Guo Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.04-rc3 released
> > Hi Jagan, > > > > Did you get a chance to test this? We've seen this on at least Cubie2, > > CubieTruck and BananaPi and it still persists with rc4 > > I made a quick test on v2019.01 vs v2019.04-rc3, below are the > results. I even grab the reg dump for your information. please check > the same. So further testing on this from the people seeing the problem shows it's an issue when booting the OS off a SATA/AHCI attached device. So a mSD card with U-Boot on it and the rest of the OS on a SSD or similar, booting the OS off mSD works as expected. Output: U-Boot SPL 2019.04-rc4 (Mar 20 2019 - 15:48:13 +) DRAM: 2048 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2019.04-rc4 (Mar 20 2019 - 15:48:13 +) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: mmc@1c0f000: 0, mmc@1c12000: 1 Loading Environment from FAT... Unable to use mmc 0:2... Setting up a 1024x768 vga console (overscan 0x0) In:serial Out: vga Err: vga Allwinner mUSB OTG (Peripheral) SCSI: Target spinup took 0 ms. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: sunxi_set_gate: (CLK#66) unhandled eth0: ethernet@1c5 Warning: usb_ether using MAC address from ROM , eth1: usb_ether starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => scsi info => scsi reset Reset SCSI scanning bus for devices... data abort pc : [] lr : [] reloc pc : [<4a01c82a>]lr : [<4a017e51>] sp : baf46b58 ip : 001c fp : 00c0 r10: r9 : baf4eed8 r8 : r7 : baf46dd8 r6 : befd4094 r5 : befdbd30 r4 : befdbd30 r3 : r2 : r1 : ea16 r0 : befdbd30 Flags: nZcv IRQs off FIQs off Mode SVC_32 Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604) Resetting CPU ... resetting ... U-Boot SPL 2019.04-rc4 (Mar 20 2019 - 15:48:13 +) DRAM: 2048 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2019.04-rc4 (Mar 20 2019 - 15:48:13 +) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: mmc@1c0f000: 0, mmc@1c12000: 1 Loading Environment from FAT... Unable to use mmc 0:2... Setting up a 1024x768 vga console (overscan 0x0) In:serial Out: vga Err: vga Allwinner mUSB OTG (Peripheral) SCSI: Target spinup took 0 ms. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: sunxi_set_gate: (CLK#66) unhandled eth0: ethernet@1c5 Warning: usb_ether using MAC address from ROM , eth1: usb_ether starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => U-Boot SPL 2018.09 (Jan 29 2019 - 17:00:18 +) DRAM: 2048 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2018.09 (Jan 29 2019 - 17:00:18 +) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... ** No valid partitions found ** Setting up a 1024x768 vga console (overscan 0x0) In:serial Out: vga Err: vga Allwinner mUSB OTG (Peripheral) SCSI: Target spinup took 0 ms. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c5 Warning: usb_ether using MAC address from ROM , eth1: usb_ether starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => scsi info Device 0: device type unknown => scsi reset Reset SCSI scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: SPCC Solid State Rev: S9FM Type: Hard Disk Capacity: 57241.8 MB = 55.9 GB (117231408 x 512) Found 1 device(s). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] malloc: Fix memalign not honoring alignment prior to full malloc init
When using memalign() in a scenario where U-Boot is configured for full
malloc support with simple malloc not explicitly enabled and before the
full malloc support is initialized, a memory block is being allocated
and returned without the alignment parameter getting honored.
Fix this issue by replacing the existing memalign pre-full malloc init
logic with a call to memalign_simple() this way ensuring proper alignment
of the returned memory block.
Fixes: ee038c58d519 ("malloc: Use malloc simple before malloc is fully
initialized in memalign()")
Signed-off-by: Andreas Dannenberg
---
common/dlmalloc.c | 3 +--
include/malloc.h | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index edaad299bb..6f12a18d54 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1893,8 +1893,7 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment;
size_t bytes;
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
- nb = roundup(bytes, alignment);
- return malloc_simple(nb);
+ return memalign_simple(alignment, bytes);
}
#endif
diff --git a/include/malloc.h b/include/malloc.h
index b714fedf45..5efa6920b2 100644
--- a/include/malloc.h
+++ b/include/malloc.h
@@ -878,7 +878,6 @@ extern Void_t* sbrk();
#define memalign memalign_simple
static inline void free(void *ptr) {}
void *calloc(size_t nmemb, size_t size);
-void *memalign_simple(size_t alignment, size_t bytes);
void *realloc_simple(void *ptr, size_t size);
void malloc_simple_info(void);
#else
@@ -914,6 +913,7 @@ int initf_malloc(void);
/* Simple versions which can be used when space is tight */
void *malloc_simple(size_t size);
+void *memalign_simple(size_t alignment, size_t bytes);
#pragma GCC visibility push(hidden)
# if __STD_C
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL
On 27/03/2019 10:39, Lukasz Majewski wrote:
Hi Jean-Jacques,
The purpose of this series is to provide the SPL with ability to apply
overlays for u-boot. this is only a RFC so far, to get a feedback on
the approach.
Our use-case is the support of the daughter boards of the AM65x EVM.
In Linux, each board is supported by a unique overlay. The presence
of the boards is detected at runtime, and some useful features (like
USB) are implemented on those daughter boards. Instead of providing
multiple dtbs and fall in a combinatorial pit, we propose to use DT
overlays.
The first 4 patches are small fixes/improvement related to the build.
Patch #5 may be a bit controversial. It basically replaces u-boot.img
with a symlink to u-boot.itb in case we use a "complex" FIT (ie: if
SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set)
Patch #6 and #7 are the core support for DTB application in the SPL.
Based on a patch posted by Michal Simek a few weeks ago. The list of
overlays is read from the "fdt" of the configuration chosen in the
ITB (same property as for the DTB):
configurations {
default = "conf-1";
conf-1 {
description = "dra76-evm";
firmware = "firmware-1";
fdt = "fdt-1", "overlay-1";
};
}
Patch #8 adds a way to dynamically select the DT overlays. That is
were we would use HW detection to select the required overlays. In
that case, the board-level code tells what overlay it needs (it gives
the name of the node).
Patch #9 is not required, but demonstrates on a DRA76-evm how this
series can be used.
Jean-Jacques Hiblot (8):
dtbo: also generate dtbo from dtso
Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is
enabled
Makefile: Fix u-boot.itb generation when building outside the source
tree
Makefile: Pass the board name to the FIT generator scripts
Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or
SPL_FIT_GENERATOR are set
spl: fit: Allow calling spl_load_fit_image() to only get the image
size
sp: fit: Allow the board to dynamically select the DTB overlays it
needs.
!!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in
SPL
Michal Simek (1):
spl: fit: Add support for applying DT overlay
Just out of curiosity - what is the difference in SPL footprint when
with and without this feature?
For the dra76-evm, the diff in SPL size is 3.3kB
JJ
Makefile | 20 ++-
arch/arm/dts/Makefile | 2 +-
arch/arm/dts/dra76-evm-dummy.dtso | 14 +++
arch/arm/dts/dra76-evm-dummy2.dtso| 15 +++
arch/arm/mach-imx/mkimage_fit_atf.sh | 3 +-
arch/arm/mach-rockchip/make_fit_atf.py| 5 +-
.../lion_rk3368/fit_spl_atf.its | 6 +-
.../puma_rk3399/fit_spl_atf.its | 8 +-
board/ti/dra7xx/evm.c | 30 +
board/ti/dra7xx/evm.its | 48
common/spl/spl_fit.c | 114
+- configs/dra7xx_evm_defconfig |
2 + include/spl.h | 20 +++
scripts/Makefile.lib | 7 ++
14 files changed, 273 insertions(+), 21 deletions(-)
create mode 100644 arch/arm/dts/dra76-evm-dummy.dtso
create mode 100644 arch/arm/dts/dra76-evm-dummy2.dtso
create mode 100644 board/ti/dra7xx/evm.its
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] X850 V1.3 hat for Raspberry Pi 3 is not working with u-boot
Hi, I am trying to use a X850 V1.3 hat (USB/mSATA) for Raspberry Pi 3: http://www.raspberrypiwiki.com/index.php/X850#Installation_Guide_For_X850_V1.3_Old_Version It works to load firmware (most of the time), but it fails in u-boot with: starting USB... USB0: scanning bus 0 for devices... usb_new_device: Cannot read configuration, skipping device 152d:0578 or just fails to find it (after a long timeout): USB0: scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Only once I got it detected: starting USB... USB0: scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 (snip) Device 0: Vendor: JMicron Rev: 0204 Prod: Generic Type: Hard Disk Capacity: 238475.1 MB = 232.8 GB (488397168 x 512) ... is now current device But then, the loaded EFI payload seems to be corrupted (bad read?). Please note it is working fine when connected to a Linux PC host, without external 5V. Cheers, Guillaume ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
On Wed, Mar 27, 2019 at 12:04 PM Jun Nie wrote: > The DCD file is only used by BL33 defconfig and is not coupled with > any other code. Yes, correct. We don't want to add the DCD file for a single defconfig. > Or you are suggesting to use ATF -> OPTEE -> SPL -> u-boot flow? SPL > is unnecessary > in this case. Could you elaborate more on maintenance impact? Thanks! Once we add the DCD file in U-Boot then we need to maintain it forever. Also, if someone wants to use Optee with the 1GB variant another DCD file will be needed. This simply does not scale. pico-mx7d is capable of booting via SPL just fine. It boots 512MB and 1GB versions of the board, so we really don't need DCD for your specific defconfig. Again, just use SPL for your usecase. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 00/12] Add support for applications of overlays in SPL
The purpose of this series is to provide the SPL with ability to apply overlays for u-boot. this is only a RFC so far, to get a feedback on the approach. Our use-case is the support of the daughter boards of the AM65x EVM. In Linux, each board is supported by a unique overlay. The presence of the boards is detected at runtime, and some useful features (like USB) are implemented on those daughter boards. Instead of providing multiple dtbs and fall in a combinatorial pit, we propose to use DT overlays. Patch #1 "spl: fit: Add support for applying DT overlay" has been posted a few weeks ago by Michal Simek. Patch #2 and #3 amend Michal's patch. Patch #4 and #5 are simple fixes for the Makefile Patch #6 is not required but relates to this series and will be required later by the AM6x platform Patch #7 may be a bit controversial. It basically replaces u-boot.img with a symlink to u-boot.itb in case we use a "complex" FIT (ie: if SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set). This breaks buildman for several platforms because not all the binaries embedded in the FIT are available. Patch #9 adds a way to dynamically select the DT overlays. That is were we would use HW detection to select the required overlays. In that case, the board-level code tells what overlay it needs (it gives the name of the node). Patch #10 disables advanced SPL FIT features to keep the size of the SPL of the am335x_evm in check Patch #11 is not required, but demonstrates on a DRA76-evm how this series can be used. On arm, if overlay are supported, this series increases the size of the SPL by 3-4 kB. Changes in v2: - reworked board_fit_get_additionnal_images() and how it used in spl_fit.c - removed dtbo generation from dtso files and use .dts extension for the overlays - add dynamic allocation usage in a separate patch - defconfig change for the am335x_evm Jean-Jacques Hiblot (11): spl: fit: Make room in the FDT before applying overlays spl: fit: allocate a temporary buffer to load the overlays Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is enabled Makefile: Fix tests for CONFIG_SPL_LOAD_FIT and CONFIG_SPL_FIT_GENERATOR Makefile: Fix u-boot.itb generation when building outside the source tree Makefile: Pass the board name to the FIT generator scripts Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set spl: fit: constify the output parameter of spl_fit_get_image_name() spl: fit: Allow the board to tell if more images must be loaded from FIT configs: am335x_evm: enable SPL_FIT_IMAGE_TINY !!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in SPL Michal Simek (1): spl: fit: Add support for applying DT overlay Makefile | 27 +-- arch/arm/dts/Makefile | 2 +- arch/arm/dts/dra76-evm-dummy.dts | 14 arch/arm/dts/dra76-evm-dummy2.dts | 15 arch/arm/mach-imx/mkimage_fit_atf.sh | 3 +- arch/arm/mach-rockchip/make_fit_atf.py| 5 +- board/sunxi/mksunxi_fit_atf.sh| 2 + .../lion_rk3368/fit_spl_atf.its | 6 +- .../puma_rk3399/fit_spl_atf.its | 8 +- board/ti/dra7xx/evm.c | 30 +++ board/ti/dra7xx/evm.its | 48 +++ common/spl/spl_fit.c | 81 +-- configs/am335x_evm_defconfig | 1 + configs/dra7xx_evm_defconfig | 2 + include/spl.h | 16 scripts/Makefile.lib | 4 + 16 files changed, 239 insertions(+), 25 deletions(-) create mode 100644 arch/arm/dts/dra76-evm-dummy.dts create mode 100644 arch/arm/dts/dra76-evm-dummy2.dts create mode 100644 board/ti/dra7xx/evm.its -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v1 2/2] power: regulator: support ROHM BD71837 PMIC
Add regulator driver for ROHM BD71837 PMIC. BD71837 contains
8 bucks and 7 LDOS. Voltages for bucks 1-4 can be adjusted
when regulators are enabled. For other bucks and LDOs we may
have over- or undershooting if voltage is adjusted when
regulator is enabled. Thus this is prevented by default.
BD71837 has a quirk which may leave power output disabled
after reset if enable/disable state was controlled by SW.
Thus the SW control is only allowed for bucks3 and 4 by
default.
Signed-off-by: Matti Vaittinen
---
drivers/power/regulator/Kconfig | 15 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/bd71837.c | 373 ++
include/power/bd71837.h | 20 ++
4 files changed, 409 insertions(+)
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 3ed0dd2264..323516587c 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -43,6 +43,21 @@ config REGULATOR_AS3722
but does not yet support change voltages. Currently this must be
done using direct register writes to the PMIC.
+config DM_REGULATOR_BD71837
+ bool "Enable Driver Model for REGULATOR BD71837"
+ depends on DM_REGULATOR && DM_PMIC_BD71837
+ help
+ This config enables implementation of driver-model regulator uclass
+ features for REGULATOR BD71837. The driver implements get/set api for:
+ value and enable.
+
+config SPL_DM_REGULATOR_BD71837
+ bool "Enable Driver Model for REGULATOR BD71837 in SPL"
+ depends on DM_REGULATOR_BD71837
+ help
+ This config enables implementation of driver-model regulator uclass
+ features for REGULATOR BD71837 in SPL.
+
config DM_REGULATOR_PFUZE100
bool "Enable Driver Model for REGULATOR PFUZE100"
depends on DM_REGULATOR && DM_PMIC_PFUZE100
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index f617ce723a..898ed5f084 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
obj-$(CONFIG_$(SPL_)REGULATOR_PWM) += pwm_regulator.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FAN53555) += fan53555.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
diff --git a/drivers/power/regulator/bd71837.c
b/drivers/power/regulator/bd71837.c
new file mode 100644
index 00..5b32425ba9
--- /dev/null
+++ b/drivers/power/regulator/bd71837.c
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2019 ROHM Semiconductors
+//
+// ROHM BD71837 regulator driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HW_STATE_CONTROL 0
+
+struct bd71837_vrange {
+ unsigned intmin_volt;
+ unsigned intstep;
+ u8 min_sel;
+ u8 max_sel;
+ u8 rangeval;
+};
+
+struct bd71837_data {
+ const char *name;
+ u8 enable_reg;
+ u8 enablemask;
+ u8 volt_reg;
+ u8 volt_mask;
+ struct bd71837_vrange *ranges;
+ unsigned intnumranges;
+ u8 rangemask;
+ u8 sel_mask;
+ booldvs;
+};
+
+#define BD_RANGE(_min, _vstep, _sel_low, _sel_hi, _range_sel) \
+{ \
+ .min_volt = (_min), .step = (_vstep), .min_sel = (_sel_low), \
+ .max_sel = (_sel_hi), .rangeval = (_range_sel) \
+}
+
+#define BD_DATA(_name, enreg, enmask, vreg, vmask, _range, rmask, _dvs, sel) \
+{ \
+ .name = (_name), .enable_reg = (enreg), .enablemask = (enmask), \
+ .volt_reg = (vreg), .volt_mask = (vmask), .ranges = (_range), \
+ .numranges = ARRAY_SIZE(_range), .rangemask = (rmask), .dvs = (_dvs), \
+ .sel_mask = (sel) \
+}
+
+static struct bd71837_vrange buck1to4_vranges[] = {
+ BD_RANGE(70, 1, 0, 0x3C, 0),
+ BD_RANGE(130, 0, 0x3D, 0x3F, 0),
+};
+
+static struct bd71837_vrange buck5_vranges[] = {
+ BD_RANGE(70, 10, 0, 0x3, 0),
+ BD_RANGE(105, 5, 0x04, 0x05, 0),
+ BD_RANGE(120, 15, 0x06, 0x07, 0),
+ BD_RANGE(675000, 10, 0x0, 0x3, 0x80),
+ BD_RANGE(1025000, 5, 0x04, 0x05, 0x80),
+ BD_RANGE(1175000, 15, 0x06, 0x07, 0x80),
+};
+
+static struct bd71837_vrange buck6_vranges[] = {
+ BD_RANGE(300, 10, 0x00, 0x03, 0),
+};
+
+static struct bd71837_vrange buck7_vranges[] = {
+ BD_RANGE(1605000, 9, 0, 1, 0),
+ BD_RANGE(1755000, 45000, 2, 4, 0),
+ BD_RANGE(1905000, 45000, 5, 7, 0),
+};
+
+static struct bd71837_vrange buck8_vranges[] = {
+
[U-Boot] [RFC PATCH v1 1/2] copy the bd71837 pmic driver from NXP imx u-boot
Add initial support for ROHM BD71837 PMIC
https://source.codeaurora.org/external/imx/uboot-imx
cherry picked, styled and merged commits:
- MLK-18387 pmic: Add pmic driver for BD71837: e9a3bec2e95a
- MLK-18590 pmic: bd71837: Change to use new fdt API: acdc5c297a96
Signed-off-by: Ye Li
Signed-off-by: Matti Vaittinen
---
drivers/power/pmic/Kconfig| 7 +++
drivers/power/pmic/Makefile | 2 +
drivers/power/pmic/bd71837.c | 89 +++
drivers/power/pmic/pmic_bd71837.c | 31 +++
include/power/bd71837.h | 64 ++
5 files changed, 193 insertions(+)
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 8cf60ebcf3..e154d0a57b 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -48,6 +48,13 @@ config PMIC_AS3722
interface and is designs to cover most of the power managementment
required for a tablets or laptop.
+config DM_PMIC_BD71837
+ bool "Enable Driver Model for PMIC BD71837"
+ depends on DM_PMIC
+ help
+ This config enables implementation of driver-model pmic uclass
features
+ for PMIC BD71837. The driver implements read/write operations.
+
config DM_PMIC_FAN53555
bool "Enable support for OnSemi FAN53555"
depends on DM_PMIC && DM_REGULATOR && DM_I2C
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 637352ab2b..e74c6190a8 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DM_PMIC_FAN53555) += fan53555.o
obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
obj-$(CONFIG_DM_PMIC_MAX8998) += max8998.o
obj-$(CONFIG_DM_PMIC_MC34708) += mc34708.o
+obj-$(CONFIG_$(SPL_)DM_PMIC_BD71837) += bd71837.o
obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
@@ -30,6 +31,7 @@ obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
+obj-$(CONFIG_POWER_BD71837) += pmic_bd71837.o
obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
obj-$(CONFIG_POWER_PFUZE3000) += pmic_pfuze3000.o
obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
diff --git a/drivers/power/pmic/bd71837.c b/drivers/power/pmic/bd71837.c
new file mode 100644
index 00..eadf373a18
--- /dev/null
+++ b/drivers/power/pmic/bd71837.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2018 NXP *
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pmic_child_info pmic_children_info[] = {
+ /* buck */
+ { .prefix = "b", .driver = BD71837_REGULATOR_DRIVER},
+ /* ldo */
+ { .prefix = "l", .driver = BD71837_REGULATOR_DRIVER},
+ { },
+};
+
+static int bd71837_reg_count(struct udevice *dev)
+{
+ return BD71837_REG_NUM;
+}
+
+static int bd71837_write(struct udevice *dev, uint reg, const uint8_t *buff,
+int len)
+{
+ if (dm_i2c_write(dev, reg, buff, len)) {
+ pr_err("write error to device: %p register: %#x!", dev, reg);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int bd71837_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+ if (dm_i2c_read(dev, reg, buff, len)) {
+ pr_err("read error from device: %p register: %#x!", dev, reg);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int bd71837_bind(struct udevice *dev)
+{
+ int children;
+ ofnode regulators_node;
+
+ regulators_node = dev_read_subnode(dev, "regulators");
+ if (!ofnode_valid(regulators_node)) {
+ debug("%s: %s regulators subnode not found!", __func__,
+ dev->name);
+ return -ENXIO;
+ }
+
+ debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
+
+ children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+ if (!children)
+ debug("%s: %s - no child found\n", __func__, dev->name);
+
+ /* Always return success for this device */
+ return 0;
+}
+
+static struct dm_pmic_ops bd71837_ops = {
+ .reg_count = bd71837_reg_count,
+ .read = bd71837_read,
+ .write = bd71837_write,
+};
+
+static const struct udevice_id bd71837_ids[] = {
+ { .compatible = "rohm,bd71837", .data = 0x4b, },
+ { }
+};
+
+U_BOOT_DRIVER(pmic_bd71837) = {
+ .name = "bd71837 pmic",
+ .id = UCLASS_PMIC,
+ .of_match = bd71837_ids,
+ .bind = bd71837_bind,
+ .ops = _ops,
+};
diff --git a/drivers/power/pmic/pmic_bd71837.c
b/drivers/power/pmic/pmic_bd71837.c
new file mode 100644
index 00..3bb8db4081
--- /dev/null
+++ b/drivers/power/pmic/pmic_bd71837.c
@@ -0,0
[U-Boot] [RFC PATCH v2 09/12] spl: fit: constify the output parameter of spl_fit_get_image_name()
There is no need for it to be non-constant. Making it constant, allows to
return constant string without warning.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
common/spl/spl_fit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index b54b30820e..b11344ec6a 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -39,7 +39,7 @@ __weak ulong board_spl_fit_size_align(ulong size)
*/
static int spl_fit_get_image_name(const void *fit, int images,
const char *type, int index,
- char **outname)
+ const char **outname)
{
const char *name, *str;
__maybe_unused int node;
@@ -94,7 +94,7 @@ static int spl_fit_get_image_name(const void *fit, int images,
static int spl_fit_get_image_node(const void *fit, int images,
const char *type, int index)
{
- char *str;
+ const char *str;
int err;
int node;
@@ -356,7 +356,7 @@ static int spl_fit_record_loadable(const void *fit, int
images, int index,
{
int ret = 0;
#if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
- char *name;
+ const char *name;
int node;
ret = spl_fit_get_image_name(fit, images, "loadables",
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 10/12] spl: fit: Allow the board to tell if more images must be loaded from FIT
spl_fit_get_image_name() is used to get the names of the images that the
SPL must load from the FIT. It relies on the content of a property present
in the FIT. The list of images is thus statically defined in the FIT.
With this scheme, it becomes quickly hard to manage combinations of more
than a hand few of images.
To address this problem, give the board-level code the opportunity to
add to the list of images. The images from the FIT property are loaded
first, and then the board_fit_get_additionnal_images() is called to
get more image names.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
common/spl/spl_fit.c | 28 +---
include/spl.h| 16
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index b11344ec6a..9d4ceb4ae1 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -25,6 +25,12 @@ __weak ulong board_spl_fit_size_align(ulong size)
return size;
}
+__weak const char *board_fit_get_additionnal_images(int index,
+ const char *type)
+{
+ return NULL;
+}
+
/**
* spl_fit_get_image_name(): By using the matching configuration subnode,
* retrieve the name of an image, specified by a property name and an index
@@ -45,6 +51,7 @@ static int spl_fit_get_image_name(const void *fit, int images,
__maybe_unused int node;
int conf_node;
int len, i;
+ bool found = true;
conf_node = fit_find_config_node(fit);
if (conf_node < 0) {
@@ -70,12 +77,27 @@ static int spl_fit_get_image_name(const void *fit, int
images,
for (i = 0; i < index; i++) {
str = strchr(str, '\0') + 1;
if (!str || (str - name >= len)) {
- debug("no string for index %d\n", index);
- return -E2BIG;
+ found = false;
+ break;
}
}
- *outname = (char *)str;
+ if (!found) {
+ /*
+* no string in the property for this index. Check if the board
+* level code can supply one.
+*/
+ str = board_fit_get_additionnal_images(index - i - 1, type);
+ if (str)
+ found = true;
+ }
+
+ if (!found) {
+ debug("no string for index %d\n", index);
+ return -E2BIG;
+ }
+
+ *outname = str;
return 0;
}
diff --git a/include/spl.h b/include/spl.h
index f09909e189..72e9c75e36 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -370,6 +370,22 @@ void board_spl_fit_post_load(ulong load_addr, size_t
length);
*/
ulong board_spl_fit_size_align(ulong size);
+/**
+ * board_fit_get_additionnal_images - Get additional image names from board-
+ * level code.
+ * This function can be used to provide the image names based on runtime
+ * detection. A classic use-case would when DTBOs are used to describe
+ * additionnal daughter cards.
+ *
+ * @param indexIndex of the image. Starts at 0 and gets incremented
after each
+ * call to this function.
+ * @param type The type of image. For example, "fdt" for DTBs
+ *
+ * @return The name of the node describing the image. NULL indicates that
+ * there no more images to get from this function.
+ */
+const char *board_fit_get_additionnal_images(int index, const char *type);
+
/**
* spl_perform_fixups() - arch/board-specific callback before processing
*the boot-payload
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 03/12] spl: fit: allocate a temporary buffer to load the overlays
If the node describing an overlay does not specify a load address, it will
be loaded at the address previously used.
Fixing it by allocating a temporary 64kB region that will be used as a
default load address.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
common/spl/spl_fit.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index a2909604cd..b54b30820e 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#ifndef CONFIG_SYS_BOOTM_LEN
@@ -302,6 +303,16 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
spl_image->fdt_addr = (void *)image_info.load_addr;
#if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
#if defined(CONFIG_OF_LIBFDT_OVERLAY)
+ void *tmpbuffer;
+ /*
+* allocate 64kB of memory. This will be used to store the DT overlay
+* before it is applied. It may not be used depending on how the
+* overlay is stored.
+*/
+ tmpbuffer = malloc(64 * 1024);
+ if (!tmpbuffer)
+ debug("%s: unable to allocate space for overlays\n", __func__);
+
for (; ; index++) {
node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index);
if (node < 0) {
@@ -309,6 +320,7 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
return 0;
}
+ image_info.load_addr = (ulong) tmpbuffer;
ret = spl_load_fit_image(info, sector, fit, base_offset, node,
_info);
if (ret < 0)
@@ -327,6 +339,8 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
debug("%s: DT overlay %s applied\n", __func__,
fit_get_name(fit, node, NULL));
}
+ if (tmpbuffer)
+ free(tmpbuffer);
#endif
/* Try to make space, so we can inject details on the loadables */
ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 12/12] !!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in SPL
This is an example of how to apply overlays in SPL for the DRA76
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2:
- reworked board_fit_get_additionnal_images() and how it used in spl_fit.c
- removed dtbo generation from dtso files and use .dts extension for the
overlays
- add dynamic allocation usage in a separate patch
- defconfig change for the am335x_evm
arch/arm/dts/Makefile | 2 +-
arch/arm/dts/dra76-evm-dummy.dts | 14 +
arch/arm/dts/dra76-evm-dummy2.dts | 15 ++
board/ti/dra7xx/evm.c | 30 +++
board/ti/dra7xx/evm.its | 48 +++
configs/dra7xx_evm_defconfig | 2 ++
6 files changed, 110 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/dra76-evm-dummy.dts
create mode 100644 arch/arm/dts/dra76-evm-dummy2.dts
create mode 100644 board/ti/dra7xx/evm.its
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0e2ffdb87f..65bb6396c5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -276,7 +276,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=
\
socfpga_stratix10_socdk.dtb
dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb \
- dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb
+ dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb dra76-evm-dummy.dtbo
dra76-evm-dummy2.dtbo
dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
am57xx-beagle-x15-revb1.dtb \
am57xx-beagle-x15-revc.dtb \
diff --git a/arch/arm/dts/dra76-evm-dummy.dts b/arch/arm/dts/dra76-evm-dummy.dts
new file mode 100644
index 00..6b55670281
--- /dev/null
+++ b/arch/arm/dts/dra76-evm-dummy.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+
+ {
+ dummy_node {
+ dummy_val = "this is only in overlay 1";
+ };
+};
diff --git a/arch/arm/dts/dra76-evm-dummy2.dts
b/arch/arm/dts/dra76-evm-dummy2.dts
new file mode 100644
index 00..0f0411164c
--- /dev/null
+++ b/arch/arm/dts/dra76-evm-dummy2.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+
+ {
+ dummy_node {
+ dummy_val = "this is only in overlay 2";
+ };
+
+};
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 060c471032..a5e4867206 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -704,6 +704,14 @@ int board_late_init(void)
if (device_okay("/ocp/omap_dwc3_2@488c"))
enable_usb_clocks(1);
#endif
+ char preboot_cmd[255];
+
+ sprintf(preboot_cmd, "fdt addr %p;\
+ fdt print /ocp/mmc@480b4000/dummy_node;\
+ fdt print /ocp/mmc@4809c000/dummy_node;",
+ gd->fdt_blob);
+
+ env_set("preboot", preboot_cmd);
return 0;
}
@@ -1069,6 +1077,28 @@ int ft_board_setup(void *blob, bd_t *bd)
#endif
#ifdef CONFIG_SPL_LOAD_FIT
+#define MAX_DAUGHTER_BOARDS 2
+const bool detected[MAX_DAUGHTER_BOARDS] = {false, true};
+const char *dtbo_nodes[] = {"dra76-evm-dummy", "dra76-evm-dummy2"};
+
+const char *board_fit_get_additionnal_images(int index, const char *type)
+{
+ int i, j;
+
+ if (strcmp(type, FIT_FDT_PROP))
+ return NULL;
+
+ j = 0;
+ for (i = 0; i < MAX_DAUGHTER_BOARDS; i++) {
+ if (detected[i]) {
+ if (j == index)
+ return dtbo_nodes[i];
+ j++;
+ }
+ }
+ return NULL;
+}
+
int board_fit_config_name_match(const char *name)
{
if (is_dra72x()) {
diff --git a/board/ti/dra7xx/evm.its b/board/ti/dra7xx/evm.its
new file mode 100644
index 00..9f6d14cf9c
--- /dev/null
+++ b/board/ti/dra7xx/evm.its
@@ -0,0 +1,48 @@
+/dts-v1/;
+
+/ {
+ description = "Firmware image with one or more FDT blobs";
+ #address-cells = <0x1>;
+
+ images {
+
+ firmware-1 {
+ description = "U-Boot 2019.01 for DRA76 board";
+type = "firmware";
+arch = "arm";
+os = "u-boot";
+compression = "none";
+load = <0x8080>;
+entry = <0x0>;
+ data = /incbin/("u-boot-nodtb.bin");
+
+ };
+
+ fdt-1 {
+ description = "dra76-evm";
+ type = "fdt";
+ data = /incbin/("arch/arm/dts/dra76-evm.dtb");
+ };
+
+ dra76-evm-dummy {
+ description = "dra76-evm dummy overlay 1";
+ data = /incbin/("arch/arm/dts/dra76-evm-dummy.dtbo");
+ };
+
+ dra76-evm-dummy2 {
+
[U-Boot] [RFC PATCH v2 04/12] Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is enabled
In order to apply an overlay to a DTB. The DTB must have been generated with the option '-@'. Signed-off-by: Jean-Jacques Hiblot --- Changes in v2: None scripts/Makefile.lib | 4 1 file changed, 4 insertions(+) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 70de9bb13a..75a170380e 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -292,6 +292,10 @@ cmd_dt_S_dtb= \ $(obj)/%.dtb.S: $(obj)/%.dtb $(call cmd,dt_S_dtb) +ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y) +DTC_FLAGS += -@ +endif + quiet_cmd_dtc = DTC $@ # Modified for U-Boot # Bring in any U-Boot-specific include at the end of the file -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 05/12] Makefile: Fix tests for CONFIG_SPL_LOAD_FIT and CONFIG_SPL_FIT_GENERATOR
The current tests do to handle well the cases where those variables are not defined. When CONFIG_SPL_LOAD_FIT is not defined, U_BOOT_ITS gets defined as an empty string. Fixing it by using intermediate variables with the quotes removed Signed-off-by: Jean-Jacques Hiblot --- Changes in v2: None Makefile | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index c1af9307b3..26235d8933 100644 --- a/Makefile +++ b/Makefile @@ -1148,12 +1148,15 @@ ifndef CONFIG_SYS_UBOOT_START CONFIG_SYS_UBOOT_START := 0 endif + # Boards with more complex image requirments can provide an .its source file # or a generator script -ifneq ($(CONFIG_SPL_FIT_SOURCE),"") -U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) +SPL_FIT_SOURCE := $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) +SPL_FIT_GENERATOR := $(subst ",,$(CONFIG_SPL_FIT_GENERATOR)) +ifneq ($(SPL_FIT_SOURCE),) +U_BOOT_ITS = $(SPL_FIT_SOURCE) else -ifneq ($(CONFIG_SPL_FIT_GENERATOR),"") +ifneq ($(SPL_FIT_GENERATOR),) U_BOOT_ITS := u-boot.its ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-imx/mkimage_fit_atf.sh") U_BOOT_ITS_DEPS += u-boot-nodtb.bin @@ -1162,7 +1165,7 @@ ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-rockchip/make_fit_atf.py") U_BOOT_ITS_DEPS += u-boot endif $(U_BOOT_ITS): $(U_BOOT_ITS_DEPS) FORCE - $(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \ + $(srctree)/$(SPL_FIT_GENERATOR) \ $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@ endif endif -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 07/12] Makefile: Pass the board name to the FIT generator scripts
Currently the FIT generator scripts are passed only a list of dtbs. However some platforms may also require information about the board itself. Signed-off-by: Jean-Jacques Hiblot --- Changes in v2: None Makefile | 2 +- arch/arm/mach-imx/mkimage_fit_atf.sh | 3 ++- arch/arm/mach-rockchip/make_fit_atf.py | 5 +++-- board/sunxi/mksunxi_fit_atf.sh | 2 ++ 4 files changed, 8 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 9275c8930e..d30e229ad9 100644 --- a/Makefile +++ b/Makefile @@ -1166,7 +1166,7 @@ ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-rockchip/make_fit_atf.py") U_BOOT_ITS_DEPS += u-boot endif $(U_BOOT_ITS): $(U_BOOT_ITS_DEPS) FORCE - $(srctree)/$(SPL_FIT_GENERATOR) \ + $(srctree)/$(SPL_FIT_GENERATOR) $(BOARD) \ $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@ endif endif diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh b/arch/arm/mach-imx/mkimage_fit_atf.sh index 38c9858e84..45b325665e 100755 --- a/arch/arm/mach-imx/mkimage_fit_atf.sh +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh @@ -4,7 +4,7 @@ # script to generate FIT image source for i.MX8MQ boards with # ARM Trusted Firmware and multiple device trees (given on the command line) # -# usage: $0 [ [ [ [&2 fi +shift for dtname in $* do echo "$dtname size: " >&2 diff --git a/arch/arm/mach-rockchip/make_fit_atf.py b/arch/arm/mach-rockchip/make_fit_atf.py index d1faff1957..4138b04a37 100755 --- a/arch/arm/mach-rockchip/make_fit_atf.py +++ b/arch/arm/mach-rockchip/make_fit_atf.py @@ -4,7 +4,7 @@ A script to generate FIT image source for rockchip boards with ARM Trusted Firmware and multiple device trees (given on the command line) -usage: $0 [ [ [ [https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 11/12] configs: am335x_evm: enable SPL_FIT_IMAGE_TINY
The size of the SPL for the am335x_evm is constrained. There is no need
to have advanced SPL FIT features, so keep the SPL FIT support tiny.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
configs/am335x_evm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 6c791be374..83a046e826 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -10,6 +10,7 @@ CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run
update_to_fit; fi; run f
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_VERSION_VARIABLE=y
CONFIG_ARCH_MISC_INIT=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
# CONFIG_SPL_FS_EXT4 is not set
CONFIG_SPL_MTD_SUPPORT=y
CONFIG_SPL_MUSB_NEW_SUPPORT=y
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 08/12] Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set
If SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set, then the default output image should be built using the provided/generated ITS, not using the default template implemented by mkimage. In that case, make u-boot.img a symbolic link to u-boot.itb Signed-off-by: Jean-Jacques Hiblot --- Changes in v2: None Makefile | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index d30e229ad9..306d2ee4b3 100644 --- a/Makefile +++ b/Makefile @@ -888,6 +888,9 @@ cmd_efipayload = $(OBJCOPY) -I binary -O $(EFIPAYLOAD_BFDTARGET) -B $(EFIPAYLOAD MKIMAGEOUTPUT ?= /dev/null +quiet_cmd_ln = LN $@ -> $< +cmd_ln = ln -f -s $< $@ + quiet_cmd_mkimage = MKIMAGE $@ cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \ >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT)) @@ -1199,7 +1202,7 @@ MKIMAGEFLAGS_u-boot-spl.kwb = -n $(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \ MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \ -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage -u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ +u-boot-dtb.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin dts/dt.dtb,u-boot.bin) FORCE $(call if_changed,mkimage) $(BOARD_SIZE_CHECK) @@ -1210,10 +1213,18 @@ else MKIMAGEFLAGS_u-boot.itb = -E endif +ifndef U_BOOT_ITS +u-boot.img: $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin dts/dt.dtb,u-boot.bin) FORCE + $(call if_changed,mkimage) +else u-boot.itb: u-boot-nodtb.bin dts/dt.dtb $(U_BOOT_ITS) FORCE $(call if_changed,mkfitimage) $(BOARD_SIZE_CHECK) +u-boot.img: u-boot.itb + $(call if_changed,ln) +endif + u-boot-spl.kwb: u-boot.img spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 01/12] spl: fit: Add support for applying DT overlay
From: Michal Simek
doc/uImage.FIT/overlay-fdt-boot.txt is describing how to create FIT
image with DT overlays in it.
Add support for this feature to SPL.
Here is the ZynqMP fragment where dtb points to full DT and dtbo is
overlay which should be applied on the top of dtb.
config {
description = "ATF with full u-boot overlay";
firmware = "atf";
loadables = "uboot";
fdt = "dtb", "dtbo";
};
The whole feature depends on OF_LIBFDT_OVERLAY which is adding +4kB code
and 0 for platforms which are not enabling this feature.
Signed-off-by: Michal Simek
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
common/spl/spl_fit.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index c9bfe0cc8a..6b71de73e7 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -278,10 +278,10 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
void *fit, int images, ulong base_offset)
{
struct spl_image_info image_info;
- int node, ret;
+ int node, ret, index = 0;
/* Figure out which device tree the board wants to use */
- node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
+ node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index++);
if (node < 0) {
debug("%s: cannot find FDT node\n", __func__);
return node;
@@ -303,8 +303,31 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
#if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
/* Try to make space, so we can inject details on the loadables */
ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
+ if (ret < 0)
+ return ret;
#endif
+#if defined(CONFIG_OF_LIBFDT_OVERLAY)
+ for (; ; index++) {
+ node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index);
+ if (node < 0) {
+ debug("%s: No additional FDT node\n", __func__);
+ return 0;
+ }
+ ret = spl_load_fit_image(info, sector, fit, base_offset, node,
+_info);
+ if (ret < 0)
+ return ret;
+
+ ret = fdt_overlay_apply_verbose(spl_image->fdt_addr,
+ (void *)image_info.load_addr);
+ if (ret)
+ return ret;
+
+ debug("%s: DT overlay %s applied\n", __func__,
+ fit_get_name(fit, node, NULL));
+ }
+#endif
return ret;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 06/12] Makefile: Fix u-boot.itb generation when building outside the source tree
Include the object tree and the source tree in the search path of the
FIT compîler (dtc). This allows to use paths relative to the root of the
source or object trees in the ITS instead of working backward from the
actual location of the ITS.
It also allows to use a build directory different of the source directory.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
Makefile| 5 +++--
board/theobroma-systems/lion_rk3368/fit_spl_atf.its | 6 +++---
board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 8
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index 26235d8933..9275c8930e 100644
--- a/Makefile
+++ b/Makefile
@@ -893,7 +893,8 @@ cmd_mkimage = $(objtree)/tools/mkimage
$(MKIMAGEFLAGS_$(@F)) -d $< $@ \
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
quiet_cmd_mkfitimage = MKIMAGE $@
-cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f
$(U_BOOT_ITS) -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@\
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -D "-i $(obj)
-i $(src)"\
+ -f $(U_BOOT_ITS) $@ -p $(CONFIG_FIT_EXTERNAL_OFFSET)\
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
quiet_cmd_cat = CAT $@
@@ -1154,7 +1155,7 @@ endif
SPL_FIT_SOURCE := $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
SPL_FIT_GENERATOR := $(subst ",,$(CONFIG_SPL_FIT_GENERATOR))
ifneq ($(SPL_FIT_SOURCE),)
-U_BOOT_ITS = $(SPL_FIT_SOURCE)
+U_BOOT_ITS = $(src)/$(SPL_FIT_SOURCE)
else
ifneq ($(SPL_FIT_GENERATOR),)
U_BOOT_ITS := u-boot.its
diff --git a/board/theobroma-systems/lion_rk3368/fit_spl_atf.its
b/board/theobroma-systems/lion_rk3368/fit_spl_atf.its
index 6b04fbc7da..69202a117b 100644
--- a/board/theobroma-systems/lion_rk3368/fit_spl_atf.its
+++ b/board/theobroma-systems/lion_rk3368/fit_spl_atf.its
@@ -14,7 +14,7 @@
images {
uboot {
description = "U-Boot (64-bit)";
- data = /incbin/("../../../u-boot-nodtb.bin");
+ data = /incbin/("u-boot-nodtb.bin");
type = "standalone";
os = "U-Boot";
arch = "arm64";
@@ -23,7 +23,7 @@
};
atf {
description = "ARM Trusted Firmware";
- data = /incbin/("../../../bl31-rk3368.bin");
+ data = /incbin/("bl31-rk3368.bin");
type = "firmware";
os = "arm-trusted-firmware";
arch = "arm64";
@@ -34,7 +34,7 @@
fdt {
description = "RK3368-uQ7 (Lion) flat device-tree";
- data = /incbin/("../../../u-boot.dtb");
+ data = /incbin/("u-boot.dtb");
type = "flat_dt";
compression = "none";
};
diff --git a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
index 530f059f3d..659183ecc1 100644
--- a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
+++ b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
@@ -14,7 +14,7 @@
images {
uboot {
description = "U-Boot (64-bit)";
- data = /incbin/("../../../u-boot-nodtb.bin");
+ data = /incbin/("u-boot-nodtb.bin");
type = "standalone";
os = "U-Boot";
arch = "arm64";
@@ -23,7 +23,7 @@
};
atf {
description = "ARM Trusted Firmware";
- data = /incbin/("../../../bl31-rk3399.bin");
+ data = /incbin/("bl31-rk3399.bin");
type = "firmware";
arch = "arm64";
os = "arm-trusted-firmware";
@@ -33,14 +33,14 @@
};
pmu {
description = "Cortex-M0 firmware";
- data = /incbin/("../../../rk3399m0.bin");
+ data = /incbin/("rk3399m0.bin");
type = "pmu-firmware";
compression = "none";
load = <0x18>;
};
fdt {
description = "RK3399-Q7 (Puma) flat device-tree";
- data = /incbin/("../../../u-boot.dtb");
+ data = /incbin/("u-boot.dtb");
type = "flat_dt";
compression = "none";
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v2 02/12] spl: fit: Make room in the FDT before applying overlays
Make room in the FDT before applying the overlay, otherwise it may fail if
the overlay is big. As the exact added size is not known in advance, just
add the size of the overlay.
Move after the end of the application of the overlays, the resize of the
FDT for the injection of the details on the loadables.
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
common/spl/spl_fit.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 6b71de73e7..a2909604cd 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -301,11 +301,6 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
/* Make the load-address of the FDT available for the SPL framework */
spl_image->fdt_addr = (void *)image_info.load_addr;
#if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
- /* Try to make space, so we can inject details on the loadables */
- ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
- if (ret < 0)
- return ret;
-#endif
#if defined(CONFIG_OF_LIBFDT_OVERLAY)
for (; ; index++) {
node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index);
@@ -319,6 +314,11 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
if (ret < 0)
return ret;
+ /* Make room in FDT for changes coming from the overlay */
+ ret = fdt_increase_size(spl_image->fdt_addr, image_info.size);
+ if (ret < 0)
+ return ret;
+
ret = fdt_overlay_apply_verbose(spl_image->fdt_addr,
(void *)image_info.load_addr);
if (ret)
@@ -328,6 +328,12 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
fit_get_name(fit, node, NULL));
}
#endif
+ /* Try to make space, so we can inject details on the loadables */
+ ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
+ if (ret < 0)
+ return ret;
+#endif
+
return ret;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [SoCFPGA] co-custodianship
On Wed, 2019-03-27 at 09:40 -0400, Tom Rini wrote: > On Wed, Mar 27, 2019 at 07:00:19AM +0100, Stefan Roese wrote: > > > > Hi Marek, > > > > On 26.03.19 17:43, Marek Vasut wrote: > > > > > > I would like to nominate Simon Goldschmidt as a co-custodian for > > > the > > > SoCFPGA platform to help me review patches and collect them into > > > PRs. > > > Any objections ? > > Not at all. Simon is doing a magnificent job with his U-Boot > > contributions since quite a long time. So I would very much > > welcome him "on-board" here too. > Indeed! Please send a patch updating MAINTAINERS / git-mailrc, Yeah, i agree with you all, Simon is very helpful, and he has made a lot improvements in U-Boot. > thanks! > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 1/2] zynqmp: add minimal include files to build a pm_cfg_obj.c
On 21. 03. 19 16:48, Luca Ceresoli wrote:
> A following commit will allow U-Boot to pass a configuration object to
> the ZynqMP PMU firmware. This configuration object is generated by
> Xilinx tools in the form of a C file (pm_cfg_obj.c), which #includes a
> few headers with constants definitions.
>
> In order to allow pm_cfg_obj.c to build, include in U-Boot a minimal
> version of those headers files:
>
> - pm_defs: a copy of [0], reduced to remove unneeded values
> - pmu_global.h: empty file, it is included but not really needed
> - xil_types.h: just includes common.h which has all the needed types
>
> [0]
> https://github.com/Xilinx/embeddedsw/blob/xilinx-v2018.3/lib/sw_services/xilpm/src/common/pm_defs.h
>
> Signed-off-by: Luca Ceresoli
> ---
> board/xilinx/zynqmp/pm_defs.h| 254 +++
> board/xilinx/zynqmp/pmu_global.h | 0
> board/xilinx/zynqmp/xil_types.h | 1 +
> 3 files changed, 255 insertions(+)
> create mode 100644 board/xilinx/zynqmp/pm_defs.h
> create mode 100644 board/xilinx/zynqmp/pmu_global.h
> create mode 100644 board/xilinx/zynqmp/xil_types.h
>
> diff --git a/board/xilinx/zynqmp/pm_defs.h b/board/xilinx/zynqmp/pm_defs.h
> new file mode 100644
> index ..a339d5ef4fd1
> --- /dev/null
> +++ b/board/xilinx/zynqmp/pm_defs.h
> @@ -0,0 +1,254 @@
> +/**
> +*
> +* Copyright (C) 2015-2018 Xilinx, Inc. All rights reserved.
> +*
> +* Permission is hereby granted, free of charge, to any person obtaining a
> copy
> +* of this software and associated documentation files (the "Software"), to
> deal
> +* in the Software without restriction, including without limitation the
> rights
> +* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> +* copies of the Software, and to permit persons to whom the Software is
> +* furnished to do so, subject to the following conditions:
> +*
> +* The above copyright notice and this permission notice shall be included in
> +* all copies or substantial portions of the Software.
> +*
> +* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> +* XILINX BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> +* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
> +* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> +* SOFTWARE.
> +*
> +* Except as contained in this notice, the name of the Xilinx shall not be
> used
> +* in advertising or otherwise to promote the sale, use or other dealings in
> +* this Software without prior written authorization from Xilinx.
> +*
> +**/
> +
> +/*/
> +/**
> + * @file pm_defs.h
> + *
> + * PM Definitions implementation
> + * @addtogroup xpm_apis XilPM APIs
> + * @{
> +
> */
> +
> +#ifndef PM_DEFS_H_
> +#define PM_DEFS_H_
> +
> +/** @name Capabilities for RAM
> + *
> + * @{
> + */
> +#define PM_CAP_ACCESS0x1U
> +#define PM_CAP_CONTEXT 0x2U
> +#define PM_CAP_WAKEUP0x4U
> +/**@}*/
> +
> +/**
> + * PM Node ID Enum
> + */
> +enum XPmNodeId {
> + NODE_UNKNOWN,
> + NODE_APU,
> + NODE_APU_0,
> + NODE_APU_1,
> + NODE_APU_2,
> + NODE_APU_3,
> + NODE_RPU,
> + NODE_RPU_0,
> + NODE_RPU_1,
> + NODE_PLD,
> + NODE_FPD,
> + NODE_OCM_BANK_0,
> + NODE_OCM_BANK_1,
> + NODE_OCM_BANK_2,
> + NODE_OCM_BANK_3,
> + NODE_TCM_0_A,
> + NODE_TCM_0_B,
> + NODE_TCM_1_A,
> + NODE_TCM_1_B,
> + NODE_L2,
> + NODE_GPU_PP_0,
> + NODE_GPU_PP_1,
> + NODE_USB_0,
> + NODE_USB_1,
> + NODE_TTC_0,
> + NODE_TTC_1,
> + NODE_TTC_2,
> + NODE_TTC_3,
> + NODE_SATA,
> + NODE_ETH_0,
> + NODE_ETH_1,
> + NODE_ETH_2,
> + NODE_ETH_3,
> + NODE_UART_0,
> + NODE_UART_1,
> + NODE_SPI_0,
> + NODE_SPI_1,
> + NODE_I2C_0,
> + NODE_I2C_1,
> + NODE_SD_0,
> + NODE_SD_1,
> + NODE_DP,
> + NODE_GDMA,
> + NODE_ADMA,
> + NODE_NAND,
> + NODE_QSPI,
> + NODE_GPIO,
> + NODE_CAN_0,
> + NODE_CAN_1,
> + NODE_EXTERN,
> + NODE_APLL,
> + NODE_VPLL,
> + NODE_DPLL,
> + NODE_RPLL,
> + NODE_IOPLL,
> + NODE_DDR,
> + NODE_IPI_APU,
> + NODE_IPI_RPU_0,
> + NODE_GPU,
> + NODE_PCIE,
> + NODE_PCAP,
> + NODE_RTC,
> + NODE_LPD,
> + NODE_VCU,
> + NODE_IPI_RPU_1,
> + NODE_IPI_PL_0,
> + NODE_IPI_PL_1,
> + NODE_IPI_PL_2,
> + NODE_IPI_PL_3,
> + NODE_PL,
> + NODE_ID_MAX
> +};
> +
> +/**
> + * PM Reset Line IDs
> + */
> +enum XPmReset {
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
On Wed, Mar 27, 2019 at 11:57 AM Fabio Estevam wrote: > > On Wed, Mar 27, 2019 at 11:18 AM Jun Nie wrote: > > > I should say that SPL is not needed, not cannot run. u-boot is loaded > > and run by ATF/OPTEE, so we do not need SPL. This is an initial > > prototype of verified boot chain from ATF to Linux on ARM32. Only > > 512MB version is considered at this stage. Maybe we can add 1GB > > version later if it is needed. > > Sorry, but we cannot accept adding non-SPL code as this impacts maintenance. > > Please add OPTEE support with the existing SPL infrastructure. Also, I'd say u-boot is not need, for some use cases ... so DDR and direct OS loading can be done using SPL. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
Fabio Estevam 于2019年3月27日周三 下午10:57写道： > > On Wed, Mar 27, 2019 at 11:18 AM Jun Nie wrote: > > > I should say that SPL is not needed, not cannot run. u-boot is loaded > > and run by ATF/OPTEE, so we do not need SPL. This is an initial > > prototype of verified boot chain from ATF to Linux on ARM32. Only > > 512MB version is considered at this stage. Maybe we can add 1GB > > version later if it is needed. > > Sorry, but we cannot accept adding non-SPL code as this impacts maintenance. > > Please add OPTEE support with the existing SPL infrastructure. > > Thanks The DCD file is only used by BL33 defconfig and is not coupled with any other code. Or you are suggesting to use ATF -> OPTEE -> SPL -> u-boot flow? SPL is unnecessary in this case. Could you elaborate more on maintenance impact? Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime
On 21. 03. 19 16:48, Luca Ceresoli wrote:
> Optionally allow U-Boot to load at the PMU firmware configuration object
> into the Power Management Unit (PMU) on Xilinx ZynqMP.
>
> The configuration object is required by the PMU FW to enable most SoC
> peripherals. So far the only way to boot using U-Boot SPL was to hard-code
> the configuration object in the PMU firmware. Allow a different boot
> process, where the PMU FW is equal for any ZynqMP chip and its
> configuration is passed at runtime by U-Boot SPL.
>
> All the code for Inter-processor communication with the PMU is isolated in
> a new file (pmu_ipc.c). The code is inspired by the same feature as
> implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
> Firmware:
>
> *
> https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
> *
> https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357
>
> The load is logged on the console during boot:
>
> U-Boot SPL 2018.01 (Mar 20 2019 - 08:12:21)
> Loading PMUFW cfg obj (2008 bytes)
> EL Level: EL3
> ...
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Changes RFC v1 -> RFC v2:
> - Load the cfg_obj in SPL, not U-Boot proper: this required a complete
>reimplementation since we cannot rely on ATF now
> - Update and refine the Kconfig option help
>
> Todo:
> - don't compile pm_cfg_obj.c from source, load it from a binary file
> ---
> board/xilinx/zynqmp/Kconfig | 26
> board/xilinx/zynqmp/Makefile | 5 ++
> board/xilinx/zynqmp/pmu_ipc.c | 116 ++
> board/xilinx/zynqmp/pmu_ipc.h | 14
> board/xilinx/zynqmp/zynqmp.c | 11
> 5 files changed, 172 insertions(+)
> create mode 100644 board/xilinx/zynqmp/pmu_ipc.c
> create mode 100644 board/xilinx/zynqmp/pmu_ipc.h
>
> diff --git a/board/xilinx/zynqmp/Kconfig b/board/xilinx/zynqmp/Kconfig
> index 7d1f7398c3e9..4201e38571e7 100644
> --- a/board/xilinx/zynqmp/Kconfig
> +++ b/board/xilinx/zynqmp/Kconfig
> @@ -15,4 +15,30 @@ config CMD_ZYNQMP
> and authentication feature enabled while generating
> BOOT.BIN using Xilinx bootgen tool.
>
> +config ZYNQMP_LOAD_PM_CFG_OBJ_FILE
> + string "PMU firmware configuration object to load at runtime"
> + help
> + Path to a PMU firmware configuration object to be built into
> + U-Boot and loaded at runtime by SPL into the PMU firmware.
> +
> + The ZynqMP Power Management Unit (PMU) needs a configuration
> + object for most SoC peripherals to work. It can be either
> + hard-coded in the PMUFW or passed at runtime.
> +
> + If the configuration object is not hard-coded in the PMU
> + firmware, U-Boot SPL can load it at runtime. To enable this
> + feature set here the file name (absolute path or relative to
> + board/xilinx/zynqmp/). It will be loaded into the PMU firmware by
> + U-Boot SPL during board initialization.
> +
> + Note: if your pm_cfg_obj.c is generated by the Xilinx tools,
> + you must remove any linking directives from the
> + XPm_ConfigObject declaration! E.g.:
> +
> + -const u32 XPm_ConfigObject[] __attribute__((used,
> section(".sys_cfg_data"))) = {
> + +const u32 XPm_ConfigObject[] = {
> +
> + Leave this option empty if your PMU firmware has a hard-coded
> + configuration object or you are loading it by any other means.
> +
> endif
> diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
> index 80f8ca7e1e4b..0d8f52ecd631 100644
> --- a/board/xilinx/zynqmp/Makefile
> +++ b/board/xilinx/zynqmp/Makefile
> @@ -33,6 +33,11 @@ ifneq ($(call ifdef_any_of, CONFIG_ZYNQMP_PSU_INIT_ENABLED
> CONFIG_SPL_BUILD),)
> obj-y += $(init-objs)
> endif
>
> +ifneq ($(CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE),"")
> +CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ -I$(srctree)/$(src)
> +obj-$(CONFIG_SPL_BUILD) += pmu_ipc.o
> +endif
> +
> obj-$(CONFIG_MMC_SDHCI_ZYNQ) += tap_delays.o
>
> ifndef CONFIG_SPL_BUILD
> diff --git a/board/xilinx/zynqmp/pmu_ipc.c b/board/xilinx/zynqmp/pmu_ipc.c
> new file mode 100644
> index ..6306d33d6f17
> --- /dev/null
> +++ b/board/xilinx/zynqmp/pmu_ipc.c
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Inter-Processor Communication with the Platform Management Unit (PMU)
> + * firmware.
> + *
> + * (C) Copyright 2019 Luca Ceresoli
> + * Luca Ceresoli
> + */
> +
> +#include "pmu_ipc.h"
> +#include
> +#include
> +
> +/* IPI bitmasks, register base and register offsets */
> +#define IPI_BIT_MASK_APU 0x1
> +#define IPI_BIT_MASK_PMU0 0x1
> +#define IPI_REG_BASE_APU 0xFF30
> +#define IPI_REG_BASE_PMU0 0xFF33
> +#define IPI_REG_OFFSET_TRIG 0x00
> +#define IPI_REG_OFFSET_OBR0x04
> +
> +/* IPI mailbox buffer offsets */
> +#define
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
On Wed, Mar 27, 2019 at 11:18 AM Jun Nie wrote: > I should say that SPL is not needed, not cannot run. u-boot is loaded > and run by ATF/OPTEE, so we do not need SPL. This is an initial > prototype of verified boot chain from ATF to Linux on ARM32. Only > 512MB version is considered at this stage. Maybe we can add 1GB > version later if it is needed. Sorry, but we cannot accept adding non-SPL code as this impacts maintenance. Please add OPTEE support with the existing SPL infrastructure. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/13] mmc: sdhci: Add support for sdhci-caps-mask
On 2/12/19 2:58 AM, Faiz Abbas wrote:
> Add Support for masking some bits in the capabilities
> register of a host controller.
>
> Also remove the redundant readl() into caps1.
>
> Signed-off-by: Faiz Abbas
> Reviewed-by: Tom Rini
> ---
> drivers/mmc/sdhci.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index cdeba914f9..c8a8a299ba 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -8,6 +8,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -561,8 +562,15 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
> sdhci_host *host,
> u32 f_max, u32 f_min)
> {
> u32 caps, caps_1 = 0;
> + u32 mask[2] = {0};
> + int ret;
> +
> + ret = dev_read_u32_array(host->mmc->dev, "sdhci-caps-mask",
> + mask, 2);
You can't do this, host->mmc is not setup at this point, you will get a
null pointer deref here. (On K3 dereferencing zero does not throw an
error so it masks this problem, other platforms (and HS K3) are not so
lucky)
Andrew
> + if (ret && ret != -1)
> + return ret;
>
> - caps = sdhci_readl(host, SDHCI_CAPABILITIES);
> + caps = ~mask[1] & sdhci_readl(host, SDHCI_CAPABILITIES);
>
> #ifdef CONFIG_MMC_SDHCI_SDMA
> if (!(caps & SDHCI_CAN_DO_SDMA)) {
> @@ -584,7 +592,7 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
> sdhci_host *host,
>
> /* Check whether the clock multiplier is supported or not */
> if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_300) {
> - caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
> + caps_1 = ~mask[0] & sdhci_readl(host, SDHCI_CAPABILITIES_1);
> host->clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >>
> SDHCI_CLOCK_MUL_SHIFT;
> }
> @@ -641,9 +649,6 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
> sdhci_host *host,
> cfg->host_caps &= ~MMC_MODE_HS_52MHz;
> }
>
> - if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_300)
> - caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
> -
> if (!(cfg->voltages & MMC_VDD_165_195) ||
> (host->quirks & SDHCI_QUIRK_NO_1_8_V))
> caps_1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: zynq_gem: Modify phy supported features after max-speed was set
From: Siva Durga Prasad Paladugu
The phydev supported features were reset in phy_set_supported() so,
move the setting of driver supported features after this so that it
wont lost in phy_set_supported().
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
drivers/net/zynq_gem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index e783773493c6..1be268f11743 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -361,14 +361,15 @@ static int zynq_phy_init(struct udevice *dev)
if (!priv->phydev)
return -ENODEV;
- priv->phydev->supported &= supported | ADVERTISED_Pause |
- ADVERTISED_Asym_Pause;
if (priv->max_speed) {
ret = phy_set_supported(priv->phydev, priv->max_speed);
if (ret)
return ret;
}
+ priv->phydev->supported &= supported | ADVERTISED_Pause |
+ ADVERTISED_Asym_Pause;
+
priv->phydev->advertising = priv->phydev->supported;
priv->phydev->node = priv->phy_of_node;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] spl: add size check including devicetree
Tom Rini schrieb am Sa., 23. März 2019, 00:17: > On Fri, Mar 01, 2019 at 10:34:17PM +0100, Simon Goldschmidt wrote: > > > Current linker based size checks do not account for the devicetree, > > as this is added after linker stage. > > > > This patch moves the logic behind U-Boot proper BOARD_SIZE_CHECK > > into a common function that is called for SPL, too. > > > > For SPL, CONFIG_SPL_MAX_SIZE is used to check u-boot-spl-dtb.bin. > > > > This is RFC for two reasons: > > - scripts/Kbuild.include might not be the perfect place for this > > new function but was the only place I found included by both > > /Makefile and /scripts/Makefile.spl > > - CONFIG_SPL_MAX_SIZE at least for some boards defines the size > > of the initially available SRAM. However, this check checks the > > SPL binary only. Initial SRAM must hold gd, heap and stack in > > addition to that. > > > > Signed-off-by: Simon Goldschmidt > > Applied to u-boot/master, thanks! > Are you sure about that? I don't see it on github, and this was an RFC which probably needs a bit of cleanup... Regards, Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
Fabio Estevam 于2019年3月27日周三 下午8:03写道： > > On Wed, Mar 27, 2019 at 8:59 AM Jun Nie wrote: > > > For ATF -> OPTEE -> U-BOOT case, we cannot run SPL. > > Why not? Please provide the details. > > What about users that has the 1GB version of the board? I should say that SPL is not needed, not cannot run. u-boot is loaded and run by ATF/OPTEE, so we do not need SPL. This is an initial prototype of verified boot chain from ATF to Linux on ARM32. Only 512MB version is considered at this stage. Maybe we can add 1GB version later if it is needed. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARC: AXS10x: drop NAND support
On AXS10x boards we have non-standard NAND controller
which was never really used a lot as there're other much more
convenient [as they are standard & removable] persistent media
like SD-card and USB mass storage.
Moreover after recent changes we face with some NAND controller
runtime issues. So instead of keeping support of yet another
non-standard peripheral we're dropping its support for good.
Signed-off-by: Eugeniy Paltsev
---
board/synopsys/axs10x/Makefile | 1 -
board/synopsys/axs10x/nand.c | 242 -
configs/axs101_defconfig | 1 -
configs/axs103_defconfig | 1 -
include/configs/axs10x.h | 6 -
5 files changed, 251 deletions(-)
delete mode 100644 board/synopsys/axs10x/nand.c
diff --git a/board/synopsys/axs10x/Makefile b/board/synopsys/axs10x/Makefile
index 340e12c4432..dd5ee680e7b 100644
--- a/board/synopsys/axs10x/Makefile
+++ b/board/synopsys/axs10x/Makefile
@@ -3,4 +3,3 @@
# Copyright (C) 2013-2016 Synopsys, Inc. All rights reserved.
obj-y += axs10x.o
-obj-$(CONFIG_CMD_NAND) += nand.o
diff --git a/board/synopsys/axs10x/nand.c b/board/synopsys/axs10x/nand.c
deleted file mode 100644
index 8108460f581..000
--- a/board/synopsys/axs10x/nand.c
+++ /dev/null
@@ -1,242 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include "axs10x.h"
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#define BUS_WIDTH 8 /* AXI data bus width in bytes */
-
-/* DMA buffer descriptor bits & masks */
-#define BD_STAT_OWN(1 << 31)
-#define BD_STAT_BD_FIRST (1 << 3)
-#define BD_STAT_BD_LAST(1 << 2)
-#define BD_SIZES_BUFFER1_MASK 0xfff
-
-#define BD_STAT_BD_COMPLETE(BD_STAT_BD_FIRST | BD_STAT_BD_LAST)
-
-/* Controller command flags */
-#define B_WFR (1 << 19) /* 1b - Wait for ready */
-#define B_LC (1 << 18) /* 1b - Last cycle */
-#define B_IWC (1 << 13) /* 1b - Interrupt when complete */
-
-/* NAND cycle types */
-#define B_CT_ADDRESS (0x0 << 16) /* Address operation*/
-#define B_CT_COMMAND (0x1 << 16) /* Command operation*/
-#define B_CT_WRITE (0x2 << 16) /* Write operation */
-#define B_CT_READ (0x3 << 16) /* Write operation */
-
-enum nand_isr_t {
- NAND_ISR_DATAREQUIRED = 0,
- NAND_ISR_TXUNDERFLOW,
- NAND_ISR_TXOVERFLOW,
- NAND_ISR_DATAAVAILABLE,
- NAND_ISR_RXUNDERFLOW,
- NAND_ISR_RXOVERFLOW,
- NAND_ISR_TXDMACOMPLETE,
- NAND_ISR_RXDMACOMPLETE,
- NAND_ISR_DESCRIPTORUNAVAILABLE,
- NAND_ISR_CMDDONE,
- NAND_ISR_CMDAVAILABLE,
- NAND_ISR_CMDERROR,
- NAND_ISR_DATATRANSFEROVER,
- NAND_ISR_NONE
-};
-
-enum nand_regs_t {
- AC_FIFO = 0,/* address and command fifo */
- IDMAC_BDADDR = 0x18,/* idmac descriptor list base address */
- INT_STATUS = 0x118, /* interrupt status register */
- INT_CLR_STATUS = 0x120, /* interrupt clear status register */
-};
-
-struct nand_bd {
- uint32_t status;/* DES0 */
- uint32_t sizes; /* DES1 */
- uint32_t buffer_ptr0; /* DES2 */
- uint32_t buffer_ptr1; /* DES3 */
-};
-
-#define NAND_REG_WRITE(r, v) \
- writel(v, (volatile void __iomem *)(CONFIG_SYS_NAND_BASE + r))
-#define NAND_REG_READ(r) \
- readl((const volatile void __iomem *)(CONFIG_SYS_NAND_BASE + r))
-
-static struct nand_bd *bd; /* DMA buffer descriptors */
-
-/**
- * axs101_nand_write_buf - write buffer to chip
- * @mtd: MTD device structure
- * @buf: data buffer
- * @len: number of bytes to write
- */
-static uint32_t nand_flag_is_set(uint32_t flag)
-{
- uint32_t reg = NAND_REG_READ(INT_STATUS);
-
- if (reg & (1 << NAND_ISR_CMDERROR))
- return 0;
-
- if (reg & (1 << flag)) {
- NAND_REG_WRITE(INT_CLR_STATUS, 1 << flag);
- return 1;
- }
-
- return 0;
-}
-
-/**
- * axs101_nand_write_buf - write buffer to chip
- * @mtd: MTD device structure
- * @buf: data buffer
- * @len: number of bytes to write
- */
-static void axs101_nand_write_buf(struct mtd_info *mtd, const u_char *buf,
- int len)
-{
- struct bounce_buffer bbstate;
-
- bounce_buffer_start(, (void *)buf, len, GEN_BB_READ);
-
- /* Setup buffer descriptor */
- writel(BD_STAT_OWN | BD_STAT_BD_COMPLETE, >status);
- writel(ALIGN(len, BUS_WIDTH) & BD_SIZES_BUFFER1_MASK, >sizes);
- writel(bbstate.bounce_buffer, >buffer_ptr0);
- writel(0, >buffer_ptr1);
-
- /* Flush modified buffer descriptor */
- flush_dcache_range((unsigned long)bd,
- (unsigned
Re: [U-Boot] [SoCFPGA] co-custodianship
On Wed, Mar 27, 2019 at 07:00:19AM +0100, Stefan Roese wrote: > Hi Marek, > > On 26.03.19 17:43, Marek Vasut wrote: > >I would like to nominate Simon Goldschmidt as a co-custodian for the > >SoCFPGA platform to help me review patches and collect them into PRs. > >Any objections ? > > Not at all. Simon is doing a magnificent job with his U-Boot > contributions since quite a long time. So I would very much > welcome him "on-board" here too. Indeed! Please send a patch updating MAINTAINERS / git-mailrc, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: ds412: Enable CONFIG_BLK
This patch enables CONFIG_BLK for the ds414 Armada XP based platform. This removes this build warning: = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. Please note that I don't have this board and can't test this change. Signed-off-by: Stefan Roese Cc: Phil Sutter --- configs/ds414_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig index 62cad53888..9e936494b2 100644 --- a/configs/ds414_defconfig +++ b/configs/ds414_defconfig @@ -43,6 +43,7 @@ CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=5000 CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_OF_TRANSLATE=y +CONFIG_BLK=y # CONFIG_MMC is not set CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [REGRESSION: PATCH 34/34] drivers/net/fec: phy_init: remove redundant logic
On 3/26/19 1:08 PM, Marcel Ziswiler wrote: Hi Hannes Hi Marcel, thanks for helping me working on this. On Tue, 2019-03-26 at 12:57 +0100, Hannes Schmelzer wrote: Hi marcel, Okay. Behaviour is now clear to me. You don't have a phy node within your dts We never ever had any such anywhere but it still used to work just fine so far. Before that you didn't operate the FEC with DM i think, so there was no description at all. nor you have MXC_PHY_ADDR set in your board header. I actually once even tried setting that without success but maybe I did it wrong. Sorry, the correct name of the #define is 'CONFIG_FEC_MXC_PHYADDR'. Prior converting your board to DM you had here: #define CONFIG_FEC_MXC_PHYADDR 0 The implicit fallback mechanism for searching the whole mdio bus for st least one phy has been gone with my patch. OK, maybe I just missed noticing such behavioural change having been advertised anywhere. There was no explicit notice, it did happen ;-) I didn't expect that there is somebody who neither defines a phy-adress within dts nor board-header. Could you try describing your phy within dts to get sure that iam right here. Sure, let me try that. Did you have success in this? Later on we have to discuss if the 'fallback' should be re implemented. Yeah, I assume such behavioural change breaks other boards as well. Mhm, you're right - i will provide a patch to the mailinglist for catching this. But in general, a precise description of the hardware would be the better way. cheers, Hannes ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pico-imx6ul: Fix eMMC boot after DM_MMC conversion
Hi Fabio, > Hi Lukasz, > > On Wed, Mar 27, 2019 at 6:23 AM Lukasz Majewski wrote: > > > This seems like a temporary solution - the u-boot proper is > > converted to use DM_MMC, but the pinmux setup code is moved to SPL > > instead. > > > > The proper solution would be to add support for pinmux in SPL and > > setup those pins there. > > Thanks for the suggestion. > > The problem is that we are too close of 2019.04 and pico-mx6ul is > currently broken. > > This is the least invasive fix we can have to avoid breakage at the > moment. I see. Let's fix the board first before release. > > Can we go with this patch for 2019.04 and then revisit the pinctrl > setting in SPL afterwards? Yes, no problem. I just wanted to show that a similar work has been done previously. > > Thanks Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpBEThkYqeye.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pico-imx6ul: Fix eMMC boot after DM_MMC conversion
Hi Lukasz, On Wed, Mar 27, 2019 at 6:23 AM Lukasz Majewski wrote: > This seems like a temporary solution - the u-boot proper is converted > to use DM_MMC, but the pinmux setup code is moved to SPL instead. > > The proper solution would be to add support for pinmux in SPL and > setup those pins there. Thanks for the suggestion. The problem is that we are too close of 2019.04 and pico-mx6ul is currently broken. This is the least invasive fix we can have to avoid breakage at the moment. Can we go with this patch for 2019.04 and then revisit the pinctrl setting in SPL afterwards? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: getvar: fix broken 'fastboot flash' when partition has slots
Hi Alex,
Thanks for the precious comments. Some remarks below.
On Wed, Mar 27, 2019 at 05:55:51AM +, Alex Kiernan wrote:
> On Wed, Mar 27, 2019 at 5:44 AM Alex Kiernan wrote:
> > On Wed, Mar 27, 2019 at 1:04 AM Eugeniu Rosca wrote:
[..]
> > > diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> > > index 4d264c985d7e..03bcd7162b37 100644
> > > --- a/drivers/fastboot/fb_getvar.c
> > > +++ b/drivers/fastboot/fb_getvar.c
> > > @@ -130,8 +130,17 @@ static void getvar_slot_suffixes(char
> > > *var_parameter, char *response)
> > >
> > > static void getvar_has_slot(char *part_name, char *response)
> > > {
> > > - if (part_name && (!strcmp(part_name, "boot") ||
> > > - !strcmp(part_name, "system")))
> > > + struct blk_desc *dev_desc;
> > > + disk_partition_t info;
> > > + char name[32];
> >
> > For the code as written this needs to be 33, or the strcat can
> > overflow by 1.
>
> Sorry, wrong way around... can truncate the name by 1, not overflow.
Applying below two-liner instrumentation on top of my patch:
diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index c703be4cd61e..0149824c0d3d 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -138,7 +138,9 @@ static void getvar_has_slot(char *part_name, char *response)
return;
strlcpy(name, part_name, sizeof(name) - 2);
+ printf("%s: name: %s, strlen(name) %lu\n", __func__, name,
strlen(name));
strcat(name, "_a");
+ printf("%s: name: %s, strlen(name) %lu\n", __func__, name,
strlen(name));
if (fastboot_mmc_get_part_info(name, _desc, , response) >= 0)
fastboot_okay("yes", response);
Passing a 32+ character part-name to 'getvar has-slot' results in:
$ host> fastboot getvar
has-slot:0123456789abcdef0123456789abcdef0123456789abcdef
$ target>
getvar_has_slot: name: 0123456789abcdef0123456789abc, strlen(name) 29
getvar_has_slot: name: 0123456789abcdef0123456789abc_a, strlen(name) 31
From the above results, it looks to me that the partition name handling
(including deliberate string truncation done by strlcpy) works
correctly. I am still ready to rework/optimize the implementation if
you have any concerns/counter-proposals.
>
> > Also we should use PART_NAME_LEN not 32 (fb_mmc.c needs
> > fixing in the same way).
Agreed. Will be fixed in v2.
> > > +
> > > + if (!part_name || !strcmp(part_name, ""))
> > > + return;
> >
> > This needs to do fastboot_okay/fastboot_fail or you'll get the
> > protocol out of sync
The idea was to avoid bloating U-Boot with string literals, but I can
add a fastboot_fail() call if you wish so. IMO if the lack of
fastboot_okay/fastboot_fail at the end of dispatching a fastboot call
triggers undefined behavior on host side, then long-term this should
be fixed in the U-Boot fastboot dispatcher itself. FWIW, the current
behavior on my target is:
host $> fastboot getvar has-slot
getvar:has-slot FAILED (status malformed (0 bytes))
Finished. Total time: 0.039s
host $> fastboot getvar has-slot:
getvar:has-slot: FAILED (status malformed (0 bytes))
Finished. Total time: 0.039s
> > > +
> > > + strlcpy(name, part_name, sizeof(name) - 2);
> > > + strcat(name, "_a");
> > > +
> > > + if (fastboot_mmc_get_part_info(name, _desc, , response)
> > > >= 0)
> > > fastboot_okay("yes", response);
> > > else
> > > fastboot_okay("no", response);
> >
> > This will fail if you're building with CONFIG_FASTBOOT_FLASH_NAND.
Agreed. Has to be fixed in v2. Do you have any preference between
the build-time "#if CONFIG_IS_ENABLED()" and the run-time "IS_ENABLED()"
which will be needed for NAND-specific handling? It is my feeling that
in Linux realm the run-time checks are greatly preferred. Here is some
feedback from Stephen Rothwell in https://lkml.org/lkml/2018/2/22/406:
-8<-
> I like IS_ENABLED() being used wherever
> possible because it allows us better compiler coverage (in the face
> of CONFIG options) even if the compiler then elides the actual code.
> It also breaks the code up less than #ifdef's.
-8<-
> > Also fastboot_mmc_get_part_info() sends its own fastboot_fail so this
> > just isn't going to work in a failure case.
I agree that, with the patch applied, getvar_has_slot() will potentially
override the response returned by fastboot_mmc_get_part_info(), but is
this really a problem? Technically, this doesn't look like a problem,
because we expect the 'strlcpy(response, tag, FASTBOOT_RESPONSE_LEN)'
call from fastboot_response() to successfully overwrite any
previously-stored response. The only problematic aspect is of somewhat
increased complexity, since we allow the higher-level fastboot layers
to redefine the status returned by the lower-level fastboot layers (hey,
this sounds quite naturally to me after all). This is something related
to internal
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
On Wed, Mar 27, 2019 at 8:59 AM Jun Nie wrote: > For ATF -> OPTEE -> U-BOOT case, we cannot run SPL. Why not? Please provide the details. What about users that has the 1GB version of the board? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
On Wed, Mar 27, 2019 at 8:59 AM Jun Nie wrote: > > Fabio Estevam 于2019年3月27日周三 下午7:52写道： > > > > Hi Jun, > > > > On Tue, Mar 26, 2019 at 6:21 AM Jun Nie wrote: > > > > > > Add default configuration to run u-boot as BL33 in the boot flow case > > > of ATF(ARM Trusted Firmware) -> OPTEE -> U-boot. > > > > > > Signed-off-by: Jun Nie > > > --- > > > board/technexion/pico-imx7d/imximage-512MB.cfg | 95 > > > ++ > > > > This looks like a step in the wrong direction. > > > > We have SPL support that can handle both 512MB and 1GB variants. > > > > Why do we need to to go back to DCD table? > > For ATF -> OPTEE -> U-BOOT case, we cannot run SPL. Why? the SPL might need to be changed but it should be doable. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
Fabio Estevam 于2019年3月27日周三 下午7:52写道： > > Hi Jun, > > On Tue, Mar 26, 2019 at 6:21 AM Jun Nie wrote: > > > > Add default configuration to run u-boot as BL33 in the boot flow case > > of ATF(ARM Trusted Firmware) -> OPTEE -> U-boot. > > > > Signed-off-by: Jun Nie > > --- > > board/technexion/pico-imx7d/imximage-512MB.cfg | 95 > > ++ > > This looks like a step in the wrong direction. > > We have SPL support that can handle both 512MB and 1GB variants. > > Why do we need to to go back to DCD table? For ATF -> OPTEE -> U-BOOT case, we cannot run SPL. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
Hi Jun, On Tue, Mar 26, 2019 at 6:21 AM Jun Nie wrote: > > Add default configuration to run u-boot as BL33 in the boot flow case > of ATF(ARM Trusted Firmware) -> OPTEE -> U-boot. > > Signed-off-by: Jun Nie > --- > board/technexion/pico-imx7d/imximage-512MB.cfg | 95 > ++ This looks like a step in the wrong direction. We have SPL support that can handle both 512MB and 1GB variants. Why do we need to to go back to DCD table? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pico-imx7d: Add bl33 config
On Wed, Mar 27, 2019 at 1:06 AM Jun Nie wrote: > Otavio Salvador 于2019年3月26日周二 下午8:23写道： > > > > On Tue, Mar 26, 2019 at 6:23 AM Jun Nie wrote: > > > > > > Add default configuration to run u-boot as BL33 in the boot flow case > > > of ATF(ARM Trusted Firmware) -> OPTEE -> U-boot. > > > > > > Signed-off-by: Jun Nie > > > > Please base it on pico-imx7d_defconfig so user is asked for the base > > board to use and it provides more flexibility to test. > > Or I misunderstand you and you suggest file name pico-imx7d_bl33_defconfig ? Yes and let user choose which dtb to use. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Move Stratix 10 SDRAM driver to DM
On Wed, Mar 27, 2019 at 10:15 AM Ley Foon Tan wrote:
>
> Convert Stratix 10 SDRAM driver to device model.
Nice to see that :-)
>
> Get rid of call to socfpga_per_reset() and use reset
> framework.
>
> SPL is changed from calling function in SDRAM driver
> directly to just probing UCLASS_RAM.
>
> Move sdram_s10.h from arch to driver/ddr/altera directory.
>
> Signed-off-by: Ley Foon Tan
> ---
> arch/arm/Kconfig | 4 +-
> arch/arm/dts/socfpga_stratix10.dtsi | 10 +
> arch/arm/dts/socfpga_stratix10_socdk.dts | 4 +
> arch/arm/mach-socfpga/Kconfig | 1 +
> arch/arm/mach-socfpga/spl_s10.c | 9 +-
> drivers/ddr/altera/Kconfig| 2 +-
> drivers/ddr/altera/sdram_s10.c| 246 --
> .../mach => drivers/ddr/altera}/sdram_s10.h | 4 -
> include/configs/socfpga_stratix10_socdk.h | 5 -
> 9 files changed, 195 insertions(+), 90 deletions(-)
> rename {arch/arm/mach-socfpga/include/mach =>
> drivers/ddr/altera}/sdram_s10.h (97%)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 77a534f81fd..a2d4f7f4c25 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -821,14 +821,14 @@ config ARCH_SOCFPGA
> select DM_SERIAL
> select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 ||
> TARGET_SOCFPGA_ARRIA10
> select OF_CONTROL
> - select RAM if TARGET_SOCFPGA_GEN5
> + select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> select SPL_DM_RESET if DM_RESET
> select SPL_DM_SERIAL
> select SPL_LIBCOMMON_SUPPORT
> select SPL_LIBGENERIC_SUPPORT
> select SPL_NAND_SUPPORT if SPL_NAND_DENALI
> select SPL_OF_CONTROL
> - select SPL_RAM if TARGET_SOCFPGA_GEN5
> + select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
> select SPL_SERIAL_SUPPORT
> select SPL_WATCHDOG_SUPPORT
> diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> b/arch/arm/dts/socfpga_stratix10.dtsi
> index ee93725d648..15d0f88f182 100644
> --- a/arch/arm/dts/socfpga_stratix10.dtsi
> +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> @@ -245,6 +245,16 @@
> u-boot,dm-pre-reloc;
> };
>
> + sdr: sdr@f8000400 {
> +compatible = "altr,sdr-ctl-s10";
> +reg = <0xf8000400 0x80>,
> + <0xf801 0x190>,
> + <0xf8011000 0x500>;
> +resets = < DDRSCH_RESET>;
> +u-boot,dm-pre-reloc;
> +status = "disabled";
Why is this optional? The SPL won't work without that any more by default,
or would it? I would have thought it's enabled by default?
> +};
> +
> spi0: spi@ffda4000 {
> compatible = "snps,dw-apb-ssi";
> #address-cells = <1>;
> diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
> b/arch/arm/dts/socfpga_stratix10_socdk.dts
> index c59b77d8298..dcaca77ea69 100644
> --- a/arch/arm/dts/socfpga_stratix10_socdk.dts
> +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> @@ -87,6 +87,10 @@
> smplsel = <0>;
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
> index 441b9d41291..9aa7f062932 100644
> --- a/arch/arm/mach-socfpga/Kconfig
> +++ b/arch/arm/mach-socfpga/Kconfig
> @@ -38,6 +38,7 @@ config TARGET_SOCFPGA_GEN5
>
> config TARGET_SOCFPGA_STRATIX10
> bool
> + select ALTERA_SDRAM
> select ARMV8_MULTIENTRY
> select ARMV8_SET_SMPEN
> select ARMV8_PSCI
> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
> index 393c9949d08..9f763b2dd4d 100644
> --- a/arch/arm/mach-socfpga/spl_s10.c
> +++ b/arch/arm/mach-socfpga/spl_s10.c
> @@ -15,9 +15,9 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -119,6 +119,7 @@ void board_init_f(ulong dummy)
> {
> const struct cm_config *cm_default_cfg = cm_get_default_config();
> int ret;
> + struct udevice *dev;
>
> #ifdef CONFIG_HW_WATCHDOG
> /* Ensure watchdog is paused when debugging is happening */
> @@ -178,9 +179,9 @@ void board_init_f(ulong dummy)
> clrbits_le32(CCU_REG_ADDR(CCU_IOM_MPRT_ADMASK_MEM_RAM0),
> CCU_ADMASK_P_MASK | CCU_ADMASK_NS_MASK);
>
> - debug("DDR: Initializing Hard Memory Controller\n");
> - if (sdram_mmr_init_full(0)) {
> - puts("DDR: Initialization failed.\n");
> + ret = uclass_get_device(UCLASS_RAM, 0, );
> + if (ret) {
> + debug("DRAM init failed: %d\n", ret);
> hang();
> }
>
> diff
Re: [U-Boot] [PATCH v4] arm: dts: Stratix10: Add QSPI node
On Wed, Mar 27, 2019 at 9:44 AM Ley Foon Tan wrote:
>
> Add QSPI device tree to Stratix 10.
> Sync from Linux Stratix 10 dts.
Which tree? Which commit?
>
> Tested on Stratix 10 SoC devkit.
> SOCFPGA_STRATIX10 # sf probe 0:0
> SF: Detected mt25qu02g with page size 256 Bytes, erase size 64 KiB, total 256
> MiB
>
> Signed-off-by: Ley Foon Tan
>
> ---
> v3->v4:
> - Add qspi node to dtsi based on alphabetical order
> - Add spi-tx-bus-width and spi-rx-bus-width
>
> v2->v3:
> - Change flash compatible to "jedec,spi-nor"
> - Change spi-max-frequency to 100MHz
> ---
> arch/arm/dts/socfpga_stratix10.dtsi | 15 +++
> arch/arm/dts/socfpga_stratix10_socdk.dts | 23 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> b/arch/arm/dts/socfpga_stratix10.dtsi
> index ee93725d648..fde76774047 100644
> --- a/arch/arm/dts/socfpga_stratix10.dtsi
> +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> @@ -237,6 +237,21 @@
> reg = <0xffe0 0x10>;
> };
>
> + qspi: spi@ff8d2000 {
> + compatible = "cdns,qspi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xff8d2000 0x100>,
> + <0xff90 0x10>;
> + interrupts = <0 3 4>;
> + cdns,fifo-depth = <128>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x>;
> + bus-num = <0>;
> + status = "disabled";
> + u-boot,dm-pre-reloc;
This file should be in sync with the Linux one, no? Does the Linux on
havethis U-Boot specific property here? I could check myself if you would
have given a tree or commit id of the sync source in the commit message...
If the Linux dts does not have this property, it would have to be moved
to a U-Boot specific "-u-boot.dtsi" addon file.
> + };
> +
> rst: rstmgr@ffd11000 {
> #reset-cells = <1>;
> compatible = "altr,rst-mgr";
> diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
> b/arch/arm/dts/socfpga_stratix10_socdk.dts
> index c59b77d8298..438b43fef6b 100644
> --- a/arch/arm/dts/socfpga_stratix10_socdk.dts
> +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> @@ -10,6 +10,7 @@
>
> aliases {
> serial0 =
> + spi0 =
> };
>
> chosen {
> @@ -87,6 +88,28 @@
> smplsel = <0>;
> };
>
> + {
> + status = "okay";
> +
> + flash@0 {
> + u-boot,dm-pre-reloc;
Same as above.
Regards,
Simon
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + reg = <0>; /* chip select */
> + spi-max-frequency = <1>;
> +
> + page-size = <256>;
> + block-size = <16>; /* 2^16, 64KB */
> + cdns,tshsl-ns = <50>;
> + cdns,tsd2d-ns = <50>;
> + cdns,tchsh-ns = <4>;
> + cdns,tslch-ns = <4>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> +};
> +
> {
> status = "okay";
> };
> --
> 2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
On 27.03.19 11:41, Peng Ma wrote: -Original Message- From: Stefan Roese Sent: 2019年3月27日 18:01 To: Peng Ma ; Prabhakar Kushwaha ; Shengzhou Liu ; Ruchika Gupta Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya ; York Sun ; bmeng...@gmail.com; m...@marvell.com; Andy Tang ; u-boot@lists.denx.de Subject: Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs On 27.03.19 10:23, Peng Ma wrote: This patch is to support Freescale sata driver with dts initialized. Also resolved the following problems. = WARNING == This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. Signed-off-by: Peng Ma --- depends on: - https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchw ork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99168data =02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef 3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072 966sdata=3Z33Z5raG%2BnbtSUpz2kPCGpefk1byOgy0%2Br3R4DUFU8% 3Dreserved=0 - https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99167d ata =02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef 3%7C686e a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072966 sdata=sr %2BCh4UioJw0kuhOiLhc3F6keRhIH8Wflt%2BvMJnHtsY%3Dreserved= 0 drivers/ata/Kconfig| 10 + drivers/ata/Makefile |1 + drivers/ata/fsl_ahci.c | 1030 drivers/ata/fsl_sata.h |1 + 4 files changed, 1042 insertions(+) create mode 100644 drivers/ata/fsl_ahci.c Will this patch series replace the old fsl_sata.c driver? If yes, could you remove this driver as well in this series? [Peng Ma] Hi Stefan, fsl_sata.c used to Non DM sata driver for some powerpc socs. Currently We only have one board that supports dts initialization. I will remove this old driver When all of our powerpc socs support DM. I see, thanks. I just wanted to know, if this new SATA driver is a meant as a replacement for the old non-DM driver. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
>-Original Message-
>From: Stefan Roese
>Sent: 2019年3月27日 18:01
>To: Peng Ma ; Prabhakar Kushwaha
>; Shengzhou Liu ;
>Ruchika Gupta
>Cc: Yinbo Zhu ; s...@chromium.org; Jagdish Gediya
>; York Sun ;
>bmeng...@gmail.com; m...@marvell.com; Andy Tang ;
>u-boot@lists.denx.de
>Subject: Re: [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale
>powerpc socs
>
>On 27.03.19 10:23, Peng Ma wrote:
>> This patch is to support Freescale sata driver with dts initialized.
>> Also resolved the following problems.
>>
>> = WARNING == This board
>does
>> not use CONFIG_DM_SCSI. Please update the storage controller to use
>> CONFIG_DM_SCSI before the v2019.07 release.
>> Failure to update by the deadline may result in board removal.
>> See doc/driver-model/MIGRATION.txt for more info.
>>
>>
>> Signed-off-by: Peng Ma
>> ---
>> depends on:
>> -
>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchw
>ork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99168data
>=02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef
>3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072
>966sdata=3Z33Z5raG%2BnbtSUpz2kPCGpefk1byOgy0%2Br3R4DUFU8%
>3Dreserved=0
>> -
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>
>hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99167d
>ata
>>
>=02%7C01%7Cpeng.ma%40nxp.com%7C71e43bd30bf24799586f08d6b29b1ef
>3%7C686e
>>
>a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636892776652072966
>sdata=sr
>> %2BCh4UioJw0kuhOiLhc3F6keRhIH8Wflt%2BvMJnHtsY%3Dreserved=
>0
>>
>> drivers/ata/Kconfig| 10 +
>> drivers/ata/Makefile |1 +
>> drivers/ata/fsl_ahci.c | 1030
>
>> drivers/ata/fsl_sata.h |1 +
>> 4 files changed, 1042 insertions(+)
>> create mode 100644 drivers/ata/fsl_ahci.c
>
>Will this patch series replace the old fsl_sata.c driver? If yes, could you
>remove
>this driver as well in this series?
[Peng Ma]
Hi Stefan,
fsl_sata.c used to Non DM sata driver for some powerpc socs. Currently
We only have one board that supports dts initialization. I will remove this old
driver
When all of our powerpc socs support DM.
Best Regards,
Peng
>
>Thanks,
>Stefan
>
>> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index
>> 49a056e941..efac29c709 100644
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -59,6 +59,16 @@ config DWC_AHCI
>>Enable this driver to support Sata devices through
>>Synopsys DWC AHCI module.
>>
>> +config FSL_AHCI
>> +bool "Enable Freescale AHCI driver support"
>> +select SCSI_AHCI
>> +depends on AHCI
>> +depends on DM_SCSI
>> +help
>> + Enable this driver to support Sata devices found in
>> + some Freescale PowerPC SoCs.
>> +
>> +
>> config DWC_AHSATA
>> bool "Enable DWC AHSATA driver support"
>> select LIBATA
>> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index
>> 10bed53bb3..93aabf34c7 100644
>> --- a/drivers/ata/Makefile
>> +++ b/drivers/ata/Makefile
>> @@ -4,6 +4,7 @@
>> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>>
>> obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
>> +obj-$(CONFIG_FSL_AHCI) += fsl_ahci.o
>> obj-$(CONFIG_AHCI) += ahci-uclass.o
>> obj-$(CONFIG_AHCI_PCI) += ahci-pci.o
>> obj-$(CONFIG_SCSI_AHCI) += ahci.o
>> diff --git a/drivers/ata/fsl_ahci.c b/drivers/ata/fsl_ahci.c new file
>> mode 100644 index 00..16c6f7a335
>> --- /dev/null
>> +++ b/drivers/ata/fsl_ahci.c
>> @@ -0,0 +1,1030 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * NXP PPC SATA platform driver
>> + *
>> + * (C) Copyright 2019 NXP, Inc.
>> + *
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "fsl_sata.h"
>> +
>> +struct fsl_ahci_priv {
>> +u32 base;
>> +u32 flag;
>> +u32 number;
>> +fsl_sata_t *fsl_sata;
>> +};
>> +
>> +static int fsl_ahci_bind(struct udevice *dev) {
>> +return device_bind_driver(dev, "fsl_ahci_scsi", "fsl_ahci_scsi",
>> +NULL); }
>> +
>> +static int fsl_ahci_ofdata_to_platdata(struct udevice *dev) {
>> +struct fsl_ahci_priv *priv = dev_get_priv(dev);
>> +
>> +priv->number = dev_read_u32_default(dev, "sata-number", -1);
>> +priv->flag = dev_read_u32_default(dev, "sata-fpdma", -1);
>> +
>> +priv->base = dev_read_addr(dev);
>> +if (priv->base == FDT_ADDR_T_NONE)
>> +return -EINVAL;
>> +
>> +return 0;
>> +}
>> +
>> +static int ata_wait_register(unsigned __iomem *addr, u32 mask,
>> + u32 val, u32 timeout_msec)
>> +{
>> +int i;
>> +
>> +for (i = 0; ((in_le32(addr) & mask) != val) && i < timeout_msec; i++)
>> +mdelay(1);
>> +
>> +return (i < timeout_msec) ? 0 : -1;
>> +}
>> +
>> +static void fsl_sata_dump_sfis(struct
[U-Boot] [PATCH] net: macb: Add small delay after link establishment
I've noticed that the first ethernet packet after PHY link establishment
is not tranferred correctly most of the time on my AT91SAM9G25 board.
Here I usually see a timeout of a few seconds, which is quite
annoying.
Adding a small delay (10ms in this case) after the link establishment
helps to solve this problem. With this patch applied, this timeout
on the first packet is not seen any more.
Signed-off-by: Stefan Roese
Cc: Wenyou Yang
Cc: Eugen Hristev
Cc: Joe Hershberger
---
drivers/net/macb.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 182331f61d..72614164e9 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -550,8 +550,14 @@ static int macb_phy_init(struct macb_device *macb, const
char *name)
for (i = 0; i < MACB_AUTONEG_TIMEOUT / 100; i++) {
status = macb_mdio_read(macb, MII_BMSR);
- if (status & BMSR_LSTATUS)
+ if (status & BMSR_LSTATUS) {
+ /*
+* Delay a bit after the link is established,
+* so that the next xfer does not fail
+*/
+ mdelay(10);
break;
+ }
udelay(100);
}
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
On 27.03.19 10:23, Peng Ma wrote:
This patch is to support Freescale sata driver with dts initialized.
Also resolved the following problems.
= WARNING ==
This board does not use CONFIG_DM_SCSI. Please update
the storage controller to use CONFIG_DM_SCSI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
Signed-off-by: Peng Ma
---
depends on:
- https://patchwork.ozlabs.org/project/uboot/list/?series=99168
- https://patchwork.ozlabs.org/project/uboot/list/?series=99167
drivers/ata/Kconfig| 10 +
drivers/ata/Makefile |1 +
drivers/ata/fsl_ahci.c | 1030
drivers/ata/fsl_sata.h |1 +
4 files changed, 1042 insertions(+)
create mode 100644 drivers/ata/fsl_ahci.c
Will this patch series replace the old fsl_sata.c driver? If yes,
could you remove this driver as well in this series?
Thanks,
Stefan
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 49a056e941..efac29c709 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -59,6 +59,16 @@ config DWC_AHCI
Enable this driver to support Sata devices through
Synopsys DWC AHCI module.
+config FSL_AHCI
+ bool "Enable Freescale AHCI driver support"
+ select SCSI_AHCI
+ depends on AHCI
+ depends on DM_SCSI
+ help
+ Enable this driver to support Sata devices found in
+ some Freescale PowerPC SoCs.
+
+
config DWC_AHSATA
bool "Enable DWC AHSATA driver support"
select LIBATA
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 10bed53bb3..93aabf34c7 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -4,6 +4,7 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
+obj-$(CONFIG_FSL_AHCI) += fsl_ahci.o
obj-$(CONFIG_AHCI) += ahci-uclass.o
obj-$(CONFIG_AHCI_PCI) += ahci-pci.o
obj-$(CONFIG_SCSI_AHCI) += ahci.o
diff --git a/drivers/ata/fsl_ahci.c b/drivers/ata/fsl_ahci.c
new file mode 100644
index 00..16c6f7a335
--- /dev/null
+++ b/drivers/ata/fsl_ahci.c
@@ -0,0 +1,1030 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * NXP PPC SATA platform driver
+ *
+ * (C) Copyright 2019 NXP, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fsl_sata.h"
+
+struct fsl_ahci_priv {
+ u32 base;
+ u32 flag;
+ u32 number;
+ fsl_sata_t *fsl_sata;
+};
+
+static int fsl_ahci_bind(struct udevice *dev)
+{
+ return device_bind_driver(dev, "fsl_ahci_scsi", "fsl_ahci_scsi", NULL);
+}
+
+static int fsl_ahci_ofdata_to_platdata(struct udevice *dev)
+{
+ struct fsl_ahci_priv *priv = dev_get_priv(dev);
+
+ priv->number = dev_read_u32_default(dev, "sata-number", -1);
+ priv->flag = dev_read_u32_default(dev, "sata-fpdma", -1);
+
+ priv->base = dev_read_addr(dev);
+ if (priv->base == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int ata_wait_register(unsigned __iomem *addr, u32 mask,
+u32 val, u32 timeout_msec)
+{
+ int i;
+
+ for (i = 0; ((in_le32(addr) & mask) != val) && i < timeout_msec; i++)
+ mdelay(1);
+
+ return (i < timeout_msec) ? 0 : -1;
+}
+
+static void fsl_sata_dump_sfis(struct sata_fis_d2h *s)
+{
+ printf("Status FIS dump:\n\r");
+ printf("fis_type: %02x\n\r", s->fis_type);
+ printf("pm_port_i: %02x\n\r", s->pm_port_i);
+ printf("status:%02x\n\r", s->status);
+ printf("error: %02x\n\r", s->error);
+ printf("lba_low: %02x\n\r", s->lba_low);
+ printf("lba_mid: %02x\n\r", s->lba_mid);
+ printf("lba_high: %02x\n\r", s->lba_high);
+ printf("device:%02x\n\r", s->device);
+ printf("lba_low_exp: %02x\n\r", s->lba_low_exp);
+ printf("lba_mid_exp: %02x\n\r", s->lba_mid_exp);
+ printf("lba_high_exp: %02x\n\r", s->lba_high_exp);
+ printf("res1: %02x\n\r", s->res1);
+ printf("sector_count: %02x\n\r", s->sector_count);
+ printf("sector_count_exp: %02x\n\r", s->sector_count_exp);
+}
+
+static void fsl_sata_dump_regs(fsl_sata_reg_t __iomem *reg)
+{
+ printf("\n\rSATA: %08x\n\r", (u32)reg);
+ printf("CQR:%08x\n\r", in_le32(>cqr));
+ printf("CAR:%08x\n\r", in_le32(>car));
+ printf("CCR:%08x\n\r", in_le32(>ccr));
+ printf("CER:%08x\n\r", in_le32(>cer));
+ printf("CQR:%08x\n\r", in_le32(>cqr));
+ printf("DER:%08x\n\r",
Re: [U-Boot] [PATCH 1/2] serial: add skipping init option
Lukasz Majewski 于2019年3月27日周三 下午5:34写道：
>
> Hi Simon, Jun,
>
> > Hi Jun,
> >
> > On Fri, 22 Mar 2019 at 16:02, Jun Nie wrote:
> > >
> > > Simon Glass 于2019年3月22日周五 下午3:56写道：
> > > >
> > > > Hi Jun,
> > > >
> > > > On Fri, 22 Mar 2019 at 15:20, Jun Nie
> > > > wrote:
> > > > >
> > > > > add skipping init option to avoid corrupt data in console
> > > > > if serial is already initilized when u-boot start its excution.
> > > > >
> > > > > Signed-off-by: Jun Nie
> > > > > ---
> > > > > drivers/serial/Kconfig | 6 ++
> > > > > 1 file changed, 6 insertions(+)
> > > >
> > > > Could we use a device-tree property for this? Some UARTs have a
> > > > 'skip-init' property.
> > > >
> > > > Regards,
> > > > Simon
> > >
> > > Hi Simon,
> > >
> > > It is a good suggestion. But device tree is board specific, while
> > > the config is boot flow specific. For ATF -> OPTEE -> U-BOOT case,
> > > initialization should be skipped. Without earlier initialization
> > > from firmware, U-boot should do it by itself. So I need find a
> > > solution that is defconfig specific, instead of device tree
> > > specific.
> >
> > So you want something that is flow-specific, I think. Your thinking is
> > that the defconfig specifies this. Is that because certain boards
> > require ATF/Optee?
> >
> > Should we consider having a way to tell U-Boot that it is running
> > from Optee?
> >
> > Could the UART driver detect that the UART is already inited?
>
> Isn't this issue similar to:
> http://patchwork.ozlabs.org/patch/820824/
>
> and
>
> http://patchwork.ozlabs.org/patch/865963/
>
My case is that console does not emit any log when OPTEE runs into u-boot.
I already root caused that there is a bug in uart clock handling.
UART1_CLK_ROOT
is hard coded in imx_get_uartclk() of arch/arm/mach-imx/mx7/clock.c
If the console serial is not UART1, 0 may be returned and console does not work.
But when I add an IMX_UART_PORT config option in Kconfig to dynamic configure
the CLK_ROOT ID as below, the expansion result is
UARTCONFIG_IMX_UART_PORT_CLK_ROOT instead of UART1_CLK_ROOT.
It seems macro expansion happens before the inclusion of defconfig. Do you see
any better idea other than add the definition in
include/configs/pico-imx7d.h directly?
#define IMX_UART_CLK_ROOT UART##CONFIG_IMX_UART_PORT##_CLK_ROOT
Current plan is to add below change so that platform can define
different clock root other
than UART1_CLK_ROOT.
+++ b/arch/arm/mach-imx/mx7/clock.c
@@ -51,9 +51,12 @@ static u32 get_ipg_clk(void)
return get_ahb_clk() / 2;
}
+#ifndef UART_CLK_ROOT
+#define UART_CLK_ROOT UART1_CLK_ROOT
+#endif
u32 imx_get_uartclk(void)
{
- return get_root_clk(UART1_CLK_ROOT);
+ return get_root_clk(UART_CLK_ROOT);
}
> >
> > Regards,
> > Simon
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL
Hi Jean-Jacques,
> The purpose of this series is to provide the SPL with ability to apply
> overlays for u-boot. this is only a RFC so far, to get a feedback on
> the approach.
>
> Our use-case is the support of the daughter boards of the AM65x EVM.
> In Linux, each board is supported by a unique overlay. The presence
> of the boards is detected at runtime, and some useful features (like
> USB) are implemented on those daughter boards. Instead of providing
> multiple dtbs and fall in a combinatorial pit, we propose to use DT
> overlays.
>
> The first 4 patches are small fixes/improvement related to the build.
> Patch #5 may be a bit controversial. It basically replaces u-boot.img
> with a symlink to u-boot.itb in case we use a "complex" FIT (ie: if
> SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set)
>
> Patch #6 and #7 are the core support for DTB application in the SPL.
> Based on a patch posted by Michal Simek a few weeks ago. The list of
> overlays is read from the "fdt" of the configuration chosen in the
> ITB (same property as for the DTB):
> configurations {
> default = "conf-1";
> conf-1 {
>description = "dra76-evm";
>firmware = "firmware-1";
>fdt = "fdt-1", "overlay-1";
> };
> }
>
>
> Patch #8 adds a way to dynamically select the DT overlays. That is
> were we would use HW detection to select the required overlays. In
> that case, the board-level code tells what overlay it needs (it gives
> the name of the node).
>
> Patch #9 is not required, but demonstrates on a DRA76-evm how this
> series can be used.
>
>
> Jean-Jacques Hiblot (8):
> dtbo: also generate dtbo from dtso
> Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is
> enabled
> Makefile: Fix u-boot.itb generation when building outside the source
> tree
> Makefile: Pass the board name to the FIT generator scripts
> Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or
> SPL_FIT_GENERATOR are set
> spl: fit: Allow calling spl_load_fit_image() to only get the image
> size
> sp: fit: Allow the board to dynamically select the DTB overlays it
> needs.
> !!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in
> SPL
>
> Michal Simek (1):
> spl: fit: Add support for applying DT overlay
Just out of curiosity - what is the difference in SPL footprint when
with and without this feature?
>
> Makefile | 20 ++-
> arch/arm/dts/Makefile | 2 +-
> arch/arm/dts/dra76-evm-dummy.dtso | 14 +++
> arch/arm/dts/dra76-evm-dummy2.dtso| 15 +++
> arch/arm/mach-imx/mkimage_fit_atf.sh | 3 +-
> arch/arm/mach-rockchip/make_fit_atf.py| 5 +-
> .../lion_rk3368/fit_spl_atf.its | 6 +-
> .../puma_rk3399/fit_spl_atf.its | 8 +-
> board/ti/dra7xx/evm.c | 30 +
> board/ti/dra7xx/evm.its | 48
> common/spl/spl_fit.c | 114
> +- configs/dra7xx_evm_defconfig |
> 2 + include/spl.h | 20 +++
> scripts/Makefile.lib | 7 ++
> 14 files changed, 273 insertions(+), 21 deletions(-)
> create mode 100644 arch/arm/dts/dra76-evm-dummy.dtso
> create mode 100644 arch/arm/dts/dra76-evm-dummy2.dtso
> create mode 100644 board/ti/dra7xx/evm.its
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpmPtnSLdfyi.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] serial: add skipping init option
Hi Simon, Jun, > Hi Jun, > > On Fri, 22 Mar 2019 at 16:02, Jun Nie wrote: > > > > Simon Glass 于2019年3月22日周五 下午3:56写道： > > > > > > Hi Jun, > > > > > > On Fri, 22 Mar 2019 at 15:20, Jun Nie > > > wrote: > > > > > > > > add skipping init option to avoid corrupt data in console > > > > if serial is already initilized when u-boot start its excution. > > > > > > > > Signed-off-by: Jun Nie > > > > --- > > > > drivers/serial/Kconfig | 6 ++ > > > > 1 file changed, 6 insertions(+) > > > > > > Could we use a device-tree property for this? Some UARTs have a > > > 'skip-init' property. > > > > > > Regards, > > > Simon > > > > Hi Simon, > > > > It is a good suggestion. But device tree is board specific, while > > the config is boot flow specific. For ATF -> OPTEE -> U-BOOT case, > > initialization should be skipped. Without earlier initialization > > from firmware, U-boot should do it by itself. So I need find a > > solution that is defconfig specific, instead of device tree > > specific. > > So you want something that is flow-specific, I think. Your thinking is > that the defconfig specifies this. Is that because certain boards > require ATF/Optee? > > Should we consider having a way to tell U-Boot that it is running > from Optee? > > Could the UART driver detect that the UART is already inited? Isn't this issue similar to: http://patchwork.ozlabs.org/patch/820824/ and http://patchwork.ozlabs.org/patch/865963/ > > Regards, > Simon > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpHursEwRzhJ.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] powerpc: mpc85xx: delete FSL_SATA for T2080QDS board.
Signed-off-by: Peng Ma --- depends on: - https://patchwork.ozlabs.org/project/uboot/list/?series=99168 - https://patchwork.ozlabs.org/project/uboot/list/?series=99167 arch/powerpc/cpu/mpc85xx/Kconfig | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 0057f195b3..aebf168a89 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -352,7 +352,6 @@ config TARGET_T2080QDS select PHYS_64BIT select FSL_DDR_FIRST_SLOT_QUAD_CAPABLE select FSL_DDR_INTERACTIVE - imply CMD_SATA config TARGET_T2080RDB bool "Support T2080RDB" @@ -361,6 +360,7 @@ config TARGET_T2080RDB select SUPPORT_SPL select PHYS_64BIT imply CMD_SATA + imply FSL_SATA imply PANIC_HANG config TARGET_T2081QDS @@ -1081,10 +1081,8 @@ config ARCH_T2080 select SYS_FSL_SEC_COMPAT_4 select SYS_PPC64 select FSL_IFC - imply CMD_SATA imply CMD_NAND imply CMD_REGINFO - imply FSL_SATA config ARCH_T2081 bool -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] configs: enable sata device module in T2080QDS
This patch is to enable sata DM for T2080QDS in uboot Signed-off-by: Peng Ma --- depends on: - https://patchwork.ozlabs.org/project/uboot/list/?series=99168 - https://patchwork.ozlabs.org/project/uboot/list/?series=99167 configs/T2080QDS_NAND_defconfig | 11 +++ configs/T2080QDS_SDCARD_defconfig | 11 +++ configs/T2080QDS_SECURE_BOOT_defconfig| 16 +--- configs/T2080QDS_SPIFLASH_defconfig | 11 +++ configs/T2080QDS_SRIO_PCIE_BOOT_defconfig | 18 ++ configs/T2080QDS_defconfig| 11 +++ 6 files changed, 47 insertions(+), 31 deletions(-) diff --git a/configs/T2080QDS_NAND_defconfig b/configs/T2080QDS_NAND_defconfig index bbd2f3e781..e67a50251a 100644 --- a/configs/T2080QDS_NAND_defconfig +++ b/configs/T2080QDS_NAND_defconfig @@ -7,6 +7,7 @@ CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_SPL=y CONFIG_MPC85xx=y CONFIG_TARGET_T2080QDS=y +CONFIG_AHCI=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y @@ -38,7 +39,10 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=fe800.nor:1m(uboot),5m(kernel),128k(dtb),9 CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="t2080qds" CONFIG_ENV_IS_IN_NAND=y +CONFIG_DM=y +CONFIG_FSL_AHCI=y CONFIG_FSL_CAAM=y +CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y @@ -56,12 +60,11 @@ CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y CONFIG_MII=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_FSL_ESPI=y CONFIG_USB=y -CONFIG_USB_STORAGE=y CONFIG_DM_USB=y -CONFIG_DM_MMC=y -CONFIG_BLK=y -CONFIG_DM=y +CONFIG_USB_STORAGE=y diff --git a/configs/T2080QDS_SDCARD_defconfig b/configs/T2080QDS_SDCARD_defconfig index df66599475..5f681d6d0f 100644 --- a/configs/T2080QDS_SDCARD_defconfig +++ b/configs/T2080QDS_SDCARD_defconfig @@ -8,6 +8,7 @@ CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_SPL=y CONFIG_MPC85xx=y CONFIG_TARGET_T2080QDS=y +CONFIG_AHCI=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y @@ -38,7 +39,10 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=fe800.nor:1m(uboot),5m(kernel),128k(dtb),9 CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="t2080qds" CONFIG_ENV_IS_IN_MMC=y +CONFIG_DM=y +CONFIG_FSL_AHCI=y CONFIG_FSL_CAAM=y +CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y @@ -55,12 +59,11 @@ CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y CONFIG_MII=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_FSL_ESPI=y CONFIG_USB=y -CONFIG_USB_STORAGE=y CONFIG_DM_USB=y -CONFIG_DM_MMC=y -CONFIG_BLK=y -CONFIG_DM=y +CONFIG_USB_STORAGE=y diff --git a/configs/T2080QDS_SECURE_BOOT_defconfig b/configs/T2080QDS_SECURE_BOOT_defconfig index 766ee7c4ac..f6284fede0 100644 --- a/configs/T2080QDS_SECURE_BOOT_defconfig +++ b/configs/T2080QDS_SECURE_BOOT_defconfig @@ -3,6 +3,8 @@ CONFIG_SYS_TEXT_BASE=0xEFF4 CONFIG_SECURE_BOOT=y CONFIG_MPC85xx=y CONFIG_TARGET_T2080QDS=y +CONFIG_MPC85XX_HAVE_RESET_VECTOR=y +CONFIG_AHCI=y # CONFIG_SYS_MALLOC_F is not set CONFIG_FIT=y CONFIG_FIT_VERBOSE=y @@ -26,7 +28,11 @@ CONFIG_CMD_FAT=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=fe800.nor,nand0=fff80.flash,spi0=spife11.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=fe800.nor:1m(uboot),5m(kernel),128k(dtb),96m(fs),-(user);fff80.flash:1m(uboot),5m(kernel),128k(dtb),96m(fs),-(user);spife11.0:1m(uboot),5m(kernel),128k(dtb),-(user)" +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="t2080qds" CONFIG_DM=y +CONFIG_FSL_AHCI=y +CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y @@ -43,18 +49,14 @@ CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y CONFIG_MII=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_FSL_ESPI=y CONFIG_USB=y -CONFIG_USB_STORAGE=y CONFIG_DM_USB=y +CONFIG_USB_STORAGE=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_OF_LIBFDT=y -CONFIG_MPC85XX_HAVE_RESET_VECTOR=y -CONFIG_DEFAULT_DEVICE_TREE="t2080qds" -CONFIG_DM_MMC=y -CONFIG_BLK=y -CONFIG_OF_CONTROL=y diff --git a/configs/T2080QDS_SPIFLASH_defconfig b/configs/T2080QDS_SPIFLASH_defconfig index 43c50fb27b..4fe737ddb5 100644 --- a/configs/T2080QDS_SPIFLASH_defconfig +++ b/configs/T2080QDS_SPIFLASH_defconfig @@ -9,6 +9,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y CONFIG_MPC85xx=y CONFIG_TARGET_T2080QDS=y +CONFIG_AHCI=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y @@ -39,7 +40,10 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=fe800.nor:1m(uboot),5m(kernel),128k(dtb),9 CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="t2080qds" CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_DM=y +CONFIG_FSL_AHCI=y CONFIG_FSL_CAAM=y +CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y @@ -56,12 +60,11 @@ CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y CONFIG_MII=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_SYS_NS16550=y
[U-Boot] [PATCH 2/4] ppc: t2080qds: add sata node
This patch is to add sata node for t2080qds
Signed-off-by: Peng Ma
---
depends on:
- https://patchwork.ozlabs.org/project/uboot/list/?series=99168
- https://patchwork.ozlabs.org/project/uboot/list/?series=99167
arch/powerpc/dts/t2080.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/dts/t2080.dtsi b/arch/powerpc/dts/t2080.dtsi
index 01ed49..d2bebb08b6 100644
--- a/arch/powerpc/dts/t2080.dtsi
+++ b/arch/powerpc/dts/t2080.dtsi
@@ -87,5 +87,21 @@
dr_mode = "host";
phy_type = "utmi";
};
+
+ sata0: sata@22 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x22 0x1000>;
+ interrupts = <68 0x2 0 0>;
+ sata-number = <0x0>;
+ sata-fpdma = <0x0>;
+ };
+
+ sata1: sata@221000 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x221000 0x1000>;
+ interrupts = <69 0x2 0 0>;
+ sata-number = <0x0>;
+ sata-fpdma = <0x0>;
+ };
};
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] ata: fsl_ahci: Add sata DM support for Freescale powerpc socs
This patch is to support Freescale sata driver with dts initialized.
Also resolved the following problems.
= WARNING ==
This board does not use CONFIG_DM_SCSI. Please update
the storage controller to use CONFIG_DM_SCSI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
Signed-off-by: Peng Ma
---
depends on:
- https://patchwork.ozlabs.org/project/uboot/list/?series=99168
- https://patchwork.ozlabs.org/project/uboot/list/?series=99167
drivers/ata/Kconfig| 10 +
drivers/ata/Makefile |1 +
drivers/ata/fsl_ahci.c | 1030
drivers/ata/fsl_sata.h |1 +
4 files changed, 1042 insertions(+)
create mode 100644 drivers/ata/fsl_ahci.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 49a056e941..efac29c709 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -59,6 +59,16 @@ config DWC_AHCI
Enable this driver to support Sata devices through
Synopsys DWC AHCI module.
+config FSL_AHCI
+ bool "Enable Freescale AHCI driver support"
+ select SCSI_AHCI
+ depends on AHCI
+ depends on DM_SCSI
+ help
+ Enable this driver to support Sata devices found in
+ some Freescale PowerPC SoCs.
+
+
config DWC_AHSATA
bool "Enable DWC AHSATA driver support"
select LIBATA
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 10bed53bb3..93aabf34c7 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -4,6 +4,7 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
+obj-$(CONFIG_FSL_AHCI) += fsl_ahci.o
obj-$(CONFIG_AHCI) += ahci-uclass.o
obj-$(CONFIG_AHCI_PCI) += ahci-pci.o
obj-$(CONFIG_SCSI_AHCI) += ahci.o
diff --git a/drivers/ata/fsl_ahci.c b/drivers/ata/fsl_ahci.c
new file mode 100644
index 00..16c6f7a335
--- /dev/null
+++ b/drivers/ata/fsl_ahci.c
@@ -0,0 +1,1030 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * NXP PPC SATA platform driver
+ *
+ * (C) Copyright 2019 NXP, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fsl_sata.h"
+
+struct fsl_ahci_priv {
+ u32 base;
+ u32 flag;
+ u32 number;
+ fsl_sata_t *fsl_sata;
+};
+
+static int fsl_ahci_bind(struct udevice *dev)
+{
+ return device_bind_driver(dev, "fsl_ahci_scsi", "fsl_ahci_scsi", NULL);
+}
+
+static int fsl_ahci_ofdata_to_platdata(struct udevice *dev)
+{
+ struct fsl_ahci_priv *priv = dev_get_priv(dev);
+
+ priv->number = dev_read_u32_default(dev, "sata-number", -1);
+ priv->flag = dev_read_u32_default(dev, "sata-fpdma", -1);
+
+ priv->base = dev_read_addr(dev);
+ if (priv->base == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int ata_wait_register(unsigned __iomem *addr, u32 mask,
+u32 val, u32 timeout_msec)
+{
+ int i;
+
+ for (i = 0; ((in_le32(addr) & mask) != val) && i < timeout_msec; i++)
+ mdelay(1);
+
+ return (i < timeout_msec) ? 0 : -1;
+}
+
+static void fsl_sata_dump_sfis(struct sata_fis_d2h *s)
+{
+ printf("Status FIS dump:\n\r");
+ printf("fis_type: %02x\n\r", s->fis_type);
+ printf("pm_port_i: %02x\n\r", s->pm_port_i);
+ printf("status: %02x\n\r", s->status);
+ printf("error: %02x\n\r", s->error);
+ printf("lba_low:%02x\n\r", s->lba_low);
+ printf("lba_mid:%02x\n\r", s->lba_mid);
+ printf("lba_high: %02x\n\r", s->lba_high);
+ printf("device: %02x\n\r", s->device);
+ printf("lba_low_exp:%02x\n\r", s->lba_low_exp);
+ printf("lba_mid_exp:%02x\n\r", s->lba_mid_exp);
+ printf("lba_high_exp: %02x\n\r", s->lba_high_exp);
+ printf("res1: %02x\n\r", s->res1);
+ printf("sector_count: %02x\n\r", s->sector_count);
+ printf("sector_count_exp: %02x\n\r", s->sector_count_exp);
+}
+
+static void fsl_sata_dump_regs(fsl_sata_reg_t __iomem *reg)
+{
+ printf("\n\rSATA: %08x\n\r", (u32)reg);
+ printf("CQR:%08x\n\r", in_le32(>cqr));
+ printf("CAR:%08x\n\r", in_le32(>car));
+ printf("CCR:%08x\n\r", in_le32(>ccr));
+ printf("CER:%08x\n\r", in_le32(>cer));
+ printf("CQR:%08x\n\r", in_le32(>cqr));
+ printf("DER:%08x\n\r", in_le32(>der));
+ printf("CHBA: %08x\n\r", in_le32(>chba));
+ printf("HStatus:%08x\n\r", in_le32(>hstatus));
+ printf("HControl: %08x\n\r",
Re: [U-Boot] [PATCH] pico-imx6ul: Fix eMMC boot after DM_MMC conversion
Hi Fabio,
> After the DM_MMC conversion the following eMMC boot error is observed:
>
> U-Boot SPL 2019.04-rc4 (Mar 20 2019 - 18:53:28 +)
> Trying to boot from MMC1
> MMC Device 0 not found
> spl: could not find mmc device 0. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> This happens because the SPL code does not initialize the SDHC pins
> and clock.
>
> Fix it by moving the original eMMC initialization from U-Boot proper
> to SPL.
>
> Reported-by: Otavio Salvador
> Signed-off-by: Fabio Estevam
> Tested-by: Fabio Berton
> Reviewed-by: Otavio Salvador
> ---
> board/technexion/pico-imx6ul/spl.c | 34
> ++ 1 file changed, 34 insertions(+)
>
> diff --git a/board/technexion/pico-imx6ul/spl.c
> b/board/technexion/pico-imx6ul/spl.c index 6464a32d3b..f972cc9eaf
> 100644 --- a/board/technexion/pico-imx6ul/spl.c
> +++ b/board/technexion/pico-imx6ul/spl.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -141,4 +142,37 @@ void board_init_f(ulong dummy)
> void reset_cpu(ulong addr)
> {
> }
> +
> +#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
> + PAD_CTL_PUS_22K_UP | PAD_CTL_SPEED_LOW | \
> + PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
> +
> +static iomux_v3_cfg_t const usdhc1_pads[] = {
> + MX6_PAD_SD1_CLK__USDHC1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD1_CMD__USDHC1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD1_DATA0__USDHC1_DATA0 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD1_DATA1__USDHC1_DATA1 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD1_DATA2__USDHC1_DATA2 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD1_DATA3__USDHC1_DATA3 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_NAND_READY_B__USDHC1_DATA4 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_NAND_CE0_B__USDHC1_DATA5 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_NAND_CE1_B__USDHC1_DATA6 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_NAND_CLE__USDHC1_DATA7 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL), +};
> +
> +static struct fsl_esdhc_cfg usdhc_cfg[1] = {
> + {USDHC1_BASE_ADDR},
> +};
> +
> +int board_mmc_getcd(struct mmc *mmc)
> +{
> + return 1;
> +}
> +
> +int board_mmc_init(bd_t *bis)
> +{
> + imx_iomux_v3_setup_multiple_pads(usdhc1_pads,
> ARRAY_SIZE(usdhc1_pads));
> + usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
> + return fsl_esdhc_initialize(bis, _cfg[0]);
> +}
> #endif
This seems like a temporary solution - the u-boot proper is converted
to use DM_MMC, but the pinmux setup code is moved to SPL instead.
The proper solution would be to add support for pinmux in SPL and
setup those pins there.
Something similar to:
http://patchwork.ozlabs.org/cover/1019842/
But this patch series shall not be regarded as a template for the
conversion as some of those patches have been superseded (like clock
with CCF clock, FEC setup).
However, the pinctrl/eMMC shall be a good example.
The other question is if imx6ul has enough resources to use such
feature-rich SPL.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpmEBNxJ8_kd.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [Resend Patch] net: mscc: ocelot: Fix reset of the phys
The function mscc_miim_reset resets all the phys, but it is called for
each phy separetely. One consequence of this is that the boot time
is increased by 2 seconds.
The fix consists for calling the mscc_miim_reset function only once for
all phys.
Signed-off-by: Horatiu Vultur
Reviewed-by: Daniel Schwierzeck
---
drivers/net/mscc_eswitch/ocelot_switch.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/net/mscc_eswitch/ocelot_switch.c
b/drivers/net/mscc_eswitch/ocelot_switch.c
index bf08c35..815c2da 100644
--- a/drivers/net/mscc_eswitch/ocelot_switch.c
+++ b/drivers/net/mscc_eswitch/ocelot_switch.c
@@ -142,18 +142,16 @@ static const unsigned long ocelot_regs_ana_table[] = {
static struct mscc_miim_dev miim[NUM_PHY];
-static int mscc_miim_reset(struct mii_dev *bus)
+static void mscc_phy_reset(void)
{
- struct mscc_miim_dev *miim = (struct mscc_miim_dev *)bus->priv;
-
- if (miim->phy_regs) {
- writel(0, miim->phy_regs + PHY_CFG);
- writel(PHY_CFG_RST | PHY_CFG_COMMON_RST
- | PHY_CFG_ENA, miim->phy_regs + PHY_CFG);
- mdelay(500);
+ writel(0, miim[INTERNAL].phy_regs + PHY_CFG);
+ writel(PHY_CFG_RST | PHY_CFG_COMMON_RST
+ | PHY_CFG_ENA, miim[INTERNAL].phy_regs + PHY_CFG);
+ if (wait_for_bit_le32(miim[INTERNAL].phy_regs + PHY_STAT,
+ PHY_STAT_SUPERVISOR_COMPLETE,
+ true, 2000, false)) {
+ pr_err("Timeout in phy reset\n");
}
-
- return 0;
}
/* For now only setup the internal mdio bus */
@@ -194,7 +192,6 @@ static struct mii_dev *ocelot_mdiobus_init(struct udevice
*dev)
miim[INTERNAL].phy_regs = ioremap(phy_base[PHY], phy_size[PHY]);
miim[INTERNAL].regs = ioremap(phy_base[MIIM], phy_size[MIIM]);
bus->priv = [INTERNAL];
- bus->reset = mscc_miim_reset;
bus->read = mscc_miim_read;
bus->write = mscc_miim_write;
@@ -210,13 +207,8 @@ __weak void mscc_switch_reset(void)
static void ocelot_stop(struct udevice *dev)
{
- struct ocelot_private *priv = dev_get_priv(dev);
- int i;
-
mscc_switch_reset();
- for (i = 0; i < NUM_PHY; i++)
- if (priv->bus[i])
- mscc_miim_reset(priv->bus[i]);
+ mscc_phy_reset();
}
static void ocelot_cpu_capture_setup(struct ocelot_private *priv)
@@ -473,6 +465,7 @@ static int ocelot_probe(struct udevice *dev)
}
priv->bus[INTERNAL] = ocelot_mdiobus_init(dev);
+ mscc_phy_reset();
for (i = 0; i < 4; i++) {
phy_connect(priv->bus[INTERNAL], i, dev,
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: Move Stratix 10 SDRAM driver to DM
Convert Stratix 10 SDRAM driver to device model.
Get rid of call to socfpga_per_reset() and use reset
framework.
SPL is changed from calling function in SDRAM driver
directly to just probing UCLASS_RAM.
Move sdram_s10.h from arch to driver/ddr/altera directory.
Signed-off-by: Ley Foon Tan
---
arch/arm/Kconfig | 4 +-
arch/arm/dts/socfpga_stratix10.dtsi | 10 +
arch/arm/dts/socfpga_stratix10_socdk.dts | 4 +
arch/arm/mach-socfpga/Kconfig | 1 +
arch/arm/mach-socfpga/spl_s10.c | 9 +-
drivers/ddr/altera/Kconfig| 2 +-
drivers/ddr/altera/sdram_s10.c| 246 --
.../mach => drivers/ddr/altera}/sdram_s10.h | 4 -
include/configs/socfpga_stratix10_socdk.h | 5 -
9 files changed, 195 insertions(+), 90 deletions(-)
rename {arch/arm/mach-socfpga/include/mach => drivers/ddr/altera}/sdram_s10.h
(97%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 77a534f81fd..a2d4f7f4c25 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -821,14 +821,14 @@ config ARCH_SOCFPGA
select DM_SERIAL
select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 ||
TARGET_SOCFPGA_ARRIA10
select OF_CONTROL
- select RAM if TARGET_SOCFPGA_GEN5
+ select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
select SPL_DM_RESET if DM_RESET
select SPL_DM_SERIAL
select SPL_LIBCOMMON_SUPPORT
select SPL_LIBGENERIC_SUPPORT
select SPL_NAND_SUPPORT if SPL_NAND_DENALI
select SPL_OF_CONTROL
- select SPL_RAM if TARGET_SOCFPGA_GEN5
+ select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
select SPL_SERIAL_SUPPORT
select SPL_WATCHDOG_SUPPORT
diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
b/arch/arm/dts/socfpga_stratix10.dtsi
index ee93725d648..15d0f88f182 100644
--- a/arch/arm/dts/socfpga_stratix10.dtsi
+++ b/arch/arm/dts/socfpga_stratix10.dtsi
@@ -245,6 +245,16 @@
u-boot,dm-pre-reloc;
};
+ sdr: sdr@f8000400 {
+compatible = "altr,sdr-ctl-s10";
+reg = <0xf8000400 0x80>,
+ <0xf801 0x190>,
+ <0xf8011000 0x500>;
+resets = < DDRSCH_RESET>;
+u-boot,dm-pre-reloc;
+status = "disabled";
+};
+
spi0: spi@ffda4000 {
compatible = "snps,dw-apb-ssi";
#address-cells = <1>;
diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
b/arch/arm/dts/socfpga_stratix10_socdk.dts
index c59b77d8298..dcaca77ea69 100644
--- a/arch/arm/dts/socfpga_stratix10_socdk.dts
+++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
@@ -87,6 +87,10 @@
smplsel = <0>;
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 441b9d41291..9aa7f062932 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -38,6 +38,7 @@ config TARGET_SOCFPGA_GEN5
config TARGET_SOCFPGA_STRATIX10
bool
+ select ALTERA_SDRAM
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
select ARMV8_PSCI
diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
index 393c9949d08..9f763b2dd4d 100644
--- a/arch/arm/mach-socfpga/spl_s10.c
+++ b/arch/arm/mach-socfpga/spl_s10.c
@@ -15,9 +15,9 @@
#include
#include
#include
-#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -119,6 +119,7 @@ void board_init_f(ulong dummy)
{
const struct cm_config *cm_default_cfg = cm_get_default_config();
int ret;
+ struct udevice *dev;
#ifdef CONFIG_HW_WATCHDOG
/* Ensure watchdog is paused when debugging is happening */
@@ -178,9 +179,9 @@ void board_init_f(ulong dummy)
clrbits_le32(CCU_REG_ADDR(CCU_IOM_MPRT_ADMASK_MEM_RAM0),
CCU_ADMASK_P_MASK | CCU_ADMASK_NS_MASK);
- debug("DDR: Initializing Hard Memory Controller\n");
- if (sdram_mmr_init_full(0)) {
- puts("DDR: Initialization failed.\n");
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret) {
+ debug("DRAM init failed: %d\n", ret);
hang();
}
diff --git a/drivers/ddr/altera/Kconfig b/drivers/ddr/altera/Kconfig
index 7370d4133a6..a64e406355e 100644
--- a/drivers/ddr/altera/Kconfig
+++ b/drivers/ddr/altera/Kconfig
@@ -1,6 +1,6 @@
config ALTERA_SDRAM
bool "SoCFPGA DDR SDRAM driver"
depends on RAM
- depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+ depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 ||
TARGET_SOCFPGA_STRATIX10
help
Enable DDR
Re: [U-Boot] [PATCH 1/3] usb: dwc3: Add Meson G12A USB Glue
On 26/03/2019 16:53, Marek Vasut wrote:
> On 3/26/19 4:15 PM, Neil Armstrong wrote:
>> Adds support for Amlogic G12A USB Control Glue HW.
>>
>> The Amlogic G12A SoC Family embeds 2 USB Controllers :
>> - a DWC3 IP configured as Host for USB2 and USB3
>> - a DWC2 IP configured as Peripheral USB2 Only
>>
>> A glue connects these both controllers to 2 USB2 PHYs, and optionnally
>> to an USB3+PCIE Combo PHY shared with the PCIE controller.
>>
>> The Glue configures the UTMI 8bit interfaces for the USB2 PHYs, including
>> routing of the OTG PHY between the DWC3 and DWC2 controllers, and
>> setups the on-chip OTG mode selection for this PHY.
>>
>> This driver sets the OTG capable port as Host mode by default,
>> the switch to Device mode is to be done in a separate patch.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>
> [...]
>
>> +static int dwc3_meson_g12a_get_phys(struct dwc3_meson_g12a *priv)
>> +{
>> +int i, ret;
>> +
>> +for (i = 0 ; i < PHY_COUNT ; ++i) {
>> +ret = generic_phy_get_by_name(priv->dev, phy_names[i],
>> + >phys[i]);
>> +if (ret == -ENOENT)
>> +continue;
>> +
>> +if (ret)
>> +return ret;
>> +
>> +if (i == USB3_HOST_PHY)
>> +priv->usb3_ports++;
>> +else
>> +priv->usb2_ports++;
>> +}
>> +
>> +printf("%s: usb2 ports: %d\n", __func__, priv->usb2_ports);
>> +printf("%s: usb3 ports: %d\n", __func__, priv->usb3_ports);
>
> Are these prints needed ?
Nop, forgot to switch them to debug
>
>> +return 0;
>> +}
>
> [...]
>> +static int dwc3_meson_g12a_probe(struct udevice *dev)
>> +{
>> +struct dwc3_meson_g12a *priv = dev_get_platdata(dev);
>> +int ret, i;
>> +
>> +priv->dev = dev;
>> +
>> +ret = regmap_init_mem(dev_ofnode(dev), >regmap);
>> +if (ret)
>> +return ret;
>> +
>> +ret = dwc3_meson_g12a_clk_init(priv);
>> +if (ret)
>> +return ret;
>> +
>> +ret = dwc3_meson_g12a_reset_init(priv);
>> +if (ret)
>> +return ret;
>> +
>> +ret = dwc3_meson_g12a_get_phys(priv);
>> +if (ret)
>> +return ret;
>> +
>> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>> +ret = device_get_supply_regulator(dev, "vbus-supply",
>> + >vbus_supply);
>> +if (ret && ret != -ENOENT) {
>> +pr_err("Failed to get PHY regulator\n");
>> +return ret;
>> +}
>> +
>> +if (priv->vbus_supply) {
>> +ret = regulator_set_enable(priv->vbus_supply, true);
>> +if (ret)
>> +return ret;
>> +}
>> +#endif
>> +
>> +priv->otg_mode = usb_get_dr_mode(dev_of_offset(dev));
>> +
>> +ret = dwc3_meson_g12a_usb_init(priv);
>> +if (ret)
>> +return ret;
>> +
>> +for (i = 0 ; i < PHY_COUNT ; ++i) {
>> +if (!priv->phys[i].dev)
>> +continue;
>> +
>> +ret = generic_phy_init(>phys[i]);
>> +if (ret)
>> +goto err_phy_init;
>> +}
>
> Isn't there some function to init all the PHYs already ?
>
I don't see any in u-boot master !
Unlike dwc3, we need to get the phys with the names to check if
the USB3 phy is enabled, so we can't get all possible phys.
Neil
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4] arm: dts: Stratix10: Add QSPI node
Add QSPI device tree to Stratix 10.
Sync from Linux Stratix 10 dts.
Tested on Stratix 10 SoC devkit.
SOCFPGA_STRATIX10 # sf probe 0:0
SF: Detected mt25qu02g with page size 256 Bytes, erase size 64 KiB, total 256
MiB
Signed-off-by: Ley Foon Tan
---
v3->v4:
- Add qspi node to dtsi based on alphabetical order
- Add spi-tx-bus-width and spi-rx-bus-width
v2->v3:
- Change flash compatible to "jedec,spi-nor"
- Change spi-max-frequency to 100MHz
---
arch/arm/dts/socfpga_stratix10.dtsi | 15 +++
arch/arm/dts/socfpga_stratix10_socdk.dts | 23 +++
2 files changed, 38 insertions(+)
diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
b/arch/arm/dts/socfpga_stratix10.dtsi
index ee93725d648..fde76774047 100644
--- a/arch/arm/dts/socfpga_stratix10.dtsi
+++ b/arch/arm/dts/socfpga_stratix10.dtsi
@@ -237,6 +237,21 @@
reg = <0xffe0 0x10>;
};
+ qspi: spi@ff8d2000 {
+ compatible = "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff8d2000 0x100>,
+ <0xff90 0x10>;
+ interrupts = <0 3 4>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x>;
+ bus-num = <0>;
+ status = "disabled";
+ u-boot,dm-pre-reloc;
+ };
+
rst: rstmgr@ffd11000 {
#reset-cells = <1>;
compatible = "altr,rst-mgr";
diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
b/arch/arm/dts/socfpga_stratix10_socdk.dts
index c59b77d8298..438b43fef6b 100644
--- a/arch/arm/dts/socfpga_stratix10_socdk.dts
+++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
@@ -10,6 +10,7 @@
aliases {
serial0 =
+ spi0 =
};
chosen {
@@ -87,6 +88,28 @@
smplsel = <0>;
};
+ {
+ status = "okay";
+
+ flash@0 {
+ u-boot,dm-pre-reloc;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* chip select */
+ spi-max-frequency = <1>;
+
+ page-size = <256>;
+ block-size = <16>; /* 2^16, 64KB */
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+};
+
{
status = "okay";
};
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mvebu: turris_omnia: select Kconfig SPI_FLASH_SPANSION
On 27.03.19 08:27, Baruch Siach wrote: Signed-off-by: Baruch Siach --- This contextually depends on http://patchwork.ozlabs.org/patch/1066576/. --- configs/turris_omnia_defconfig | 1 + include/configs/turris_omnia.h | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index c406b257533e..85f214148a8e 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -43,6 +43,7 @@ CONFIG_ATSHA204A=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_MV=y CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_MVNETA=y diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 021ebae21ff7..c7805cf36bf2 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -34,8 +34,6 @@ # define CONFIG_WATCHDOG #endif -#define CONFIG_SPI_FLASH_SPANSION - /* * SDIO/MMC Card Configuration */ Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: turris_omnia: select Kconfig SPI_FLASH_SPANSION
Signed-off-by: Baruch Siach --- This contextually depends on http://patchwork.ozlabs.org/patch/1066576/. --- configs/turris_omnia_defconfig | 1 + include/configs/turris_omnia.h | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index c406b257533e..85f214148a8e 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -43,6 +43,7 @@ CONFIG_ATSHA204A=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_MV=y CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_MVNETA=y diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 021ebae21ff7..c7805cf36bf2 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -34,8 +34,6 @@ # define CONFIG_WATCHDOG #endif -#define CONFIG_SPI_FLASH_SPANSION - /* * SDIO/MMC Card Configuration */ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 11/11] cmd: add efibootmgr command
On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> Add CONFIG_CMD_STANDALONE_EFIBOOTMGR.
> With this patch, EFI boot manager can be kicked in by a standalone
> command, efibootmgr.
I miss your comment form 0/11 here:
* When we will support "secure boot" in the future, EFI Boot Manager
is expected to be invoked as a standalone command without any
arguments to mitigate security surfaces.
Simply requiring that environment variable $fdtaddr, which is under user
control, is used for loading the device tree does not offer any security
at all.
For secure boot I would expect that the device tree has to be part of a
signed binary and that that signature is checked.
If the user passes in a device tree that should be okay if it has the
required signature.
>
> Signed-off-by: AKASHI Takahiro
> ---
> cmd/Kconfig | 8
> cmd/bootefi.c | 35 +++
> 2 files changed, 43 insertions(+)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 4bcc5c45579d..aa27b21956b3 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -224,6 +224,14 @@ config CMD_BOOTEFI
> help
> Boot an EFI image from memory.
>
> +config CMD_STANDALONE_EFIBOOTMGR
> + bool "Enable EFI Boot Manager as a standalone command"
> + depends on CMD_BOOTEFI
> + default n
> + help
> + With this option enabled, EFI Boot Manager can be invoked
> + as a standalone command.
> +
> config CMD_BOOTEFI_HELLO_COMPILE
> bool "Compile a standard EFI hello world binary for testing"
> depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 17dccd718008..2a2ff4034831 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -635,3 +635,38 @@ void efi_set_bootdev(const char *dev, const char *devnr,
> const char *path)
> bootefi_image_path = NULL;
> }
> }
> +
> +#ifdef CONFIG_CMD_STANDALONE_EFIBOOTMGR
> +static int do_efibootmgr_cmd(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + char *fdt_opt;
> + int ret;
> +
> + if (argc != 1)
> + return CMD_RET_USAGE;
It is unclear why you do not allow the user to pass the location of the
device tree as a parameter.
> +
> + fdt_opt = env_get("fdtaddr");
You are looking at some environment variable $fdtaddr while most boards
use $fdt_addr_r as preferred address to load the device tree.
Best regards
Heinrich
> + if (!fdt_opt)> +fdt_opt = env_get("fdtcontroladdr");
> +
> + ret = do_efibootmgr(fdt_opt);
> +
> + free(fdt_opt);
> +
> + return ret;
> +}
> +
> +#ifdef CONFIG_SYS_LONGHELP
> +static char efibootmgr_help_text[] =
> + "(no arguments)\n"
> + " - Launch EFI boot manager and execute EFI application\n"
> + " based on BootNext and BootOrder variables\n";
> +#endif
> +
> +U_BOOT_CMD(
> + efibootmgr, 1, 0, do_efibootmgr_cmd,
> + "Launch EFI boot manager",
> + efibootmgr_help_text
> +);
> +#endif /* CONFIG_CMD_STANDALONE_EFIBOOTMGR */
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
