Re: [U-Boot] [PATCH 5/5] rockchip: rk3328: add rock64-rk3328_defconfig
Hi Matwey, Please add commit message for the patch. On 05/08/2019 02:34 PM, Matwey V. Kornilov wrote: > Signed-off-by: Matwey V. Kornilov > --- > configs/rock64-rk3328_defconfig | 91 > + > 1 file changed, 91 insertions(+) > create mode 100644 configs/rock64-rk3328_defconfig > > diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig > new file mode 100644 > index 00..b278315035 > --- /dev/null > +++ b/configs/rock64-rk3328_defconfig > @@ -0,0 +1,91 @@ > +CONFIG_SMBIOS_MANUFACTURER="pine64" > +CONFIG_SMBIOS_PRODUCT_NAME="rock64_rk3328" > +CONFIG_ARM=y > +CONFIG_ARCH_ROCKCHIP=y > +CONFIG_SPL_LIBCOMMON_SUPPORT=y > +CONFIG_SPL_LIBGENERIC_SUPPORT=y > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_SYS_TEXT_BASE=0x0020 > +CONFIG_ROCKCHIP_RK3328=y > +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x0 Does this SPL_REVERVE_IRAM=0 fine with support ATF? SPL TEXT_BASE is 0, and ATF starts at 0x10, I use to reserve big enough space for ATF and U-Boot before SPL enable the relocate feature, or else it's very easy to get panic in SPL. Thanks, - Kever > +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y > +CONFIG_SPL_STACK_R_ADDR=0x60 > +CONFIG_DEBUG_UART_BASE=0xFF13 > +CONFIG_DEBUG_UART_CLOCK=2400 > +CONFIG_DEBUG_UART=y > +CONFIG_NR_DRAM_BANKS=1 > +# CONFIG_ANDROID_BOOT_IMAGE is not set > +CONFIG_FIT=y > +CONFIG_FIT_VERBOSE=y > +CONFIG_SPL_LOAD_FIT=y > +CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py" > +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock64.dtb" > +# CONFIG_DISPLAY_CPUINFO is not set > +CONFIG_DISPLAY_BOARDINFO_LATE=y > +CONFIG_SPL_STACK_R=y > +CONFIG_SPL_ATF=y > +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y > +CONFIG_FASTBOOT_BUF_ADDR=0x800800 > +CONFIG_FASTBOOT_FLASH=y > +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > +CONFIG_CMD_BOOTZ=y > +CONFIG_CMD_GPT=y > +CONFIG_CMD_MMC=y > +CONFIG_CMD_SF=y > +CONFIG_CMD_USB=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_CMD_TIME=y > +CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64" > +CONFIG_SPL_OF_CONTROL=y > +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names > interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" > +CONFIG_ENV_IS_IN_MMC=y > +CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_REGMAP=y > +CONFIG_SPL_REGMAP=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > +CONFIG_CLK=y > +CONFIG_SPL_CLK=y > +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > +CONFIG_ROCKCHIP_GPIO=y > +CONFIG_SYS_I2C_ROCKCHIP=y > +CONFIG_MMC_DW=y > +CONFIG_MMC_DW_ROCKCHIP=y > +CONFIG_SPI_FLASH=y > +CONFIG_SF_DEFAULT_SPEED=2000 > +CONFIG_DM_ETH=y > +CONFIG_ETH_DESIGNWARE=y > +CONFIG_GMAC_ROCKCHIP=y > +CONFIG_PHY=y > +CONFIG_PINCTRL=y > +CONFIG_SPL_PINCTRL=y > +CONFIG_PINCTRL_ROCKCHIP_RK3328=y > +CONFIG_DM_PMIC=y > +CONFIG_PMIC_RK8XX=y > +CONFIG_REGULATOR_PWM=y > +CONFIG_DM_REGULATOR_FIXED=y > +CONFIG_REGULATOR_RK8XX=y > +CONFIG_PWM_ROCKCHIP=y > +CONFIG_RAM=y > +CONFIG_SPL_RAM=y > +CONFIG_DM_RESET=y > +CONFIG_BAUDRATE=150 > +CONFIG_DEBUG_UART_SHIFT=2 > +CONFIG_SYSRESET=y > +CONFIG_USB=y > +CONFIG_USB_XHCI_HCD=y > +CONFIG_USB_XHCI_DWC3=y > +CONFIG_USB_EHCI_HCD=y > +CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_GENERIC=y > +CONFIG_USB_DWC2=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Rockchip" > +CONFIG_USB_GADGET_VENDOR_NUM=0x2207 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x330a > +CONFIG_USB_GADGET_DWC2_OTG=y > +CONFIG_USE_TINY_PRINTF=y > +CONFIG_SPL_TINY_MEMSET=y > +CONFIG_ERRNO_STR=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
On Thu, May 16, 2019 at 1:47 AM Andre Przywara wrote: > > The first USB controller on the A64 SoC shares a PHY with the OTG > controller. Reportedly to avoid problems with the VBUS regulator under > Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file. > > However on boards which can't use peripheral mode (because they have an > always-on VBUS supply on an USB-A socket) we don't need this trick, and > can properly connect host controller 0 to the PHY 0. > > Amend the Pine64 and SoPine/LTS .dts to reflect this. This enables the > upper USB port in U-Boot on those boards. > > Signed-off-by: Andre Przywara > --- > arch/arm/dts/sun50i-a64-pine64.dts | 5 - > arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 - > 2 files changed, 8 insertions(+), 2 deletions(-) Are these changes going to go upstream to Linux too? If not it's probably best to add it to a u-boot.dtsi so the changes don't get lost when the DT files are re-synced from Linux. Same with the similar patches for the H6 boards. Peter > diff --git a/arch/arm/dts/sun50i-a64-pine64.dts > b/arch/arm/dts/sun50i-a64-pine64.dts > index c077b6c1f4..523a4d5bff 100644 > --- a/arch/arm/dts/sun50i-a64-pine64.dts > +++ b/arch/arm/dts/sun50i-a64-pine64.dts > @@ -80,6 +80,8 @@ > }; > > &ehci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -136,6 +138,8 @@ > }; > > &ohci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -301,7 +305,6 @@ > > &usb_otg { > dr_mode = "host"; > - status = "okay"; > }; > > &usbphy { > diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > index 53fcc9098d..1986897177 100644 > --- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > @@ -85,6 +85,8 @@ > }; > > &ehci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -131,6 +133,8 @@ > }; > > &ohci0 { > + phys = <&usbphy 0>; > + phy-names = "usb"; > status = "okay"; > }; > > @@ -172,7 +176,6 @@ > > &usb_otg { > dr_mode = "host"; > - status = "okay"; > }; > > &usbphy { > -- > 2.14.5 > > ___ > 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 v2 1/3] arm: exynos: arndale: Remove unused CONFIG_POWER and CONFIG_POWER_I2C
Hi, On 11/05/2019 20:24, Krzysztof Kozlowski wrote: > The CONFIG_POWER and CONFIG_POWER_I2C were introduced in > include/configs/exynos5-common.h in commit 19bd3aaa5991 ("exynos5: fix > build break by adding CONFIG_POWER") and then it propagated up to > include/configs/arndale.h. However before that commit, there was no > build break at all on Arndale and SMDK5250 boards. It seems the commit > fixed nothing and just added unused defines. > > In fact, the Arndale board is not configuring its PMIC (S5M8767) which > uses I2C bus. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Simon Glass > > --- > > Not tested on Arndale board. Testing is welcomed. > > Changes since v1: > 1. Add Simon's tag. > 2. Reorder patches - first remove CONFIG_POWER_I2C, then >CONFIG_DM_I2C_COMPAT. > --- > include/configs/arndale.h | 8 > 1 file changed, 8 deletions(-) > > diff --git a/include/configs/arndale.h b/include/configs/arndale.h > index dd321c4748d0..841f3616482b 100644 > --- a/include/configs/arndale.h > +++ b/include/configs/arndale.h > @@ -29,10 +29,6 @@ > > #define CONFIG_SYS_INIT_SP_ADDR CONFIG_IRAM_STACK > > -/* PMIC */ > -#define CONFIG_POWER > -#define CONFIG_POWER_I2C > - > #define CONFIG_PREBOOT > > #define CONFIG_S5P_PA_SYSRAM 0x0202 > @@ -41,8 +37,4 @@ > /* The PERIPHBASE in the CBAR register is wrong on the Arndale, so override > it */ > #define CONFIG_ARM_GIC_BASE_ADDRESS 0x1048 > > -/* Power */ > -#define CONFIG_POWER > -#define CONFIG_POWER_I2C > - > #endif /* __CONFIG_H */ > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] arm: exynos: arndale: Remove unused CONFIG_DM_I2C_COMPAT
Hi, On 11/05/2019 20:24, Krzysztof Kozlowski wrote: > The CONFIG_DM_I2C_COMPAT was introduced in > include/configs/exynos5-common.h in commit 189d80166b31 ("exynos5: > enable dm i2c") and then it propagated up to configs/arndale_defconfig. > However since beginning the Arndale board (Exynos5250) was not using > I2C. > > In fact, the Arndale board is not configuring its PMIC (S5M8767) which > uses I2C bus. This setting can be thus safely removed to fix build > warning: > > This board uses CONFIG_DM_I2C_COMPAT. Please remove > (possibly in a subsequent patch in your series) > before sending patches to the mailing list. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Simon Glass > > --- > > Not tested on Arndale board. Testing is welcomed. > > Changes since v1: > 1. Add Simon's tag. > 2. Reorder patches - first remove CONFIG_POWER_I2C, then >CONFIG_DM_I2C_COMPAT. > --- > configs/arndale_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig > index 9727d28c1241..e90d670f6813 100644 > --- a/configs/arndale_defconfig > +++ b/configs/arndale_defconfig > @@ -25,7 +25,6 @@ CONFIG_CMD_SOUND=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_DEFAULT_DEVICE_TREE="exynos5250-arndale" > CONFIG_ENV_IS_IN_MMC=y > -CONFIG_DM_I2C_COMPAT=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_MMC_DW=y > CONFIG_MMC_SDHCI=y > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] configs: arndale: Use appropriate driver for Asix AX88760
Hi, On 11/05/2019 20:24, Krzysztof Kozlowski wrote: > Arndale board has an Asix AX88760 USB 2.0 Hub and Fast Ethernet combo. > The appropriate driver for it is USB_ETHER_ASIX. > > The mistake probably came from misinterpretation of commit e9954b867ce0 > ("usb: eth: add ASIX AX88179 DRIVER") which was tested on RECS5250 COM > module. This module indeed has Exynos5250 and some similarities with > Arndale 5250 board but the USB/Ethernet chip used there is apparently > different. > > Fixes: f58ad98a621c ("usb: net: migrate USB Ethernet adapters to Kconfig") > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Lukasz Majewski > > --- > > Not tested. > > Changes since v1: > 1. Add Lukasz's tag. > --- > configs/arndale_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig > index e90d670f6813..37ad6accc396 100644 > --- a/configs/arndale_defconfig > +++ b/configs/arndale_defconfig > @@ -42,4 +42,4 @@ CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_HOST_ETHER=y > -CONFIG_USB_ETHER_ASIX88179=y > +CONFIG_USB_ETHER_ASIX=y > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/3] imx: Cleanup i.MX6Q mccmon6 board configuration
This patch series updates mccmon6 configuration to remove some "removal" warnings (i.e. disables the USB related code). It also on purpose disables gigabig ethernet, as this board works on 10/100 Mib environments. Patches applicable on top of master branch: SHA1: 5b4b680cfe29a67171ccbe439c66374cb31faca3 Lukasz Majewski (3): ARM: imx: cosmetic: Remove not needed comment from the mccmon6.h file ARM: imx: config: Disable support for USB on MCCMON6 ARM: imx: Disable 1Gbps support on MCCMON6's KSZ9031 PHY configs/mccmon6_nor_defconfig | 2 -- configs/mccmon6_sd_defconfig | 2 -- include/configs/mccmon6.h | 8 +--- 3 files changed, 1 insertion(+), 11 deletions(-) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/3] ARM: imx: cosmetic: Remove not needed comment from the mccmon6.h file
This comment is a leftover from the Kconfig CONFIG_*MTD* move. Signed-off-by: Lukasz Majewski --- include/configs/mccmon6.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h index a1774c027a..b97373512f 100644 --- a/include/configs/mccmon6.h +++ b/include/configs/mccmon6.h @@ -65,8 +65,6 @@ #define CONFIG_SYS_FLASH_BANKS_LIST{ (CONFIG_SYS_FLASH_BASE) } #define CONFIG_SYS_FLASH_BANKS_SIZES { (32 * SZ_1M) } -/* MTD support */ - /* USB Configs */ #define CONFIG_USB_MAX_CONTROLLER_COUNT2 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/3] ARM: imx: Disable 1Gbps support on MCCMON6's KSZ9031 PHY
mccmon6 works in 10/100 MiB Ethernet environment, so disabling 1GiB support improves robustness of the network after power up (as one don't need to wait for autoneg). Signed-off-by: Lukasz Majewski --- include/configs/mccmon6.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h index 231b2af87a..667dac7340 100644 --- a/include/configs/mccmon6.h +++ b/include/configs/mccmon6.h @@ -78,6 +78,7 @@ "fdt_high=0x\0" \ "initrd_high=0x\0" \ "boot_os=yes\0" \ + "disable_giga=yes\0" \ "download_kernel=" \ "tftpboot ${kernel_addr} ${kernel_file};" \ "tftpboot ${fdt_addr} ${fdtfile};\0" \ -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/3] ARM: imx: config: Disable support for USB on MCCMON6
The IMX6Q based MCCMON6 is not using USB for any purpose. Signed-off-by: Lukasz Majewski --- configs/mccmon6_nor_defconfig | 2 -- configs/mccmon6_sd_defconfig | 2 -- include/configs/mccmon6.h | 5 - 3 files changed, 9 deletions(-) diff --git a/configs/mccmon6_nor_defconfig b/configs/mccmon6_nor_defconfig index af2a106644..ddbcd69316 100644 --- a/configs/mccmon6_nor_defconfig +++ b/configs/mccmon6_nor_defconfig @@ -20,7 +20,6 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_SF=y -CONFIG_CMD_USB=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_MTDPARTS=y @@ -50,5 +49,4 @@ CONFIG_MII=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_DM_THERMAL=y -CONFIG_USB=y CONFIG_OF_LIBFDT=y diff --git a/configs/mccmon6_sd_defconfig b/configs/mccmon6_sd_defconfig index aac433c13b..a018d804f8 100644 --- a/configs/mccmon6_sd_defconfig +++ b/configs/mccmon6_sd_defconfig @@ -21,7 +21,6 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_SF=y -CONFIG_CMD_USB=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_MTDPARTS=y @@ -51,5 +50,4 @@ CONFIG_MII=y CONFIG_SPI=y CONFIG_MXC_SPI=y CONFIG_DM_THERMAL=y -CONFIG_USB=y CONFIG_OF_LIBFDT=y diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h index b97373512f..231b2af87a 100644 --- a/include/configs/mccmon6.h +++ b/include/configs/mccmon6.h @@ -65,11 +65,6 @@ #define CONFIG_SYS_FLASH_BANKS_LIST{ (CONFIG_SYS_FLASH_BASE) } #define CONFIG_SYS_FLASH_BANKS_SIZES { (32 * SZ_1M) } -/* USB Configs */ -#define CONFIG_USB_MAX_CONTROLLER_COUNT2 -#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) -#define CONFIG_MXC_USB_FLAGS 0 - /* Ethernet Configuration */ #define CONFIG_FEC_MXC #define IMX_FEC_BASE ENET_BASE_ADDR -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sysreset: switch to using SYSRESET_POWER_OFF for poweroff
Hi Urja, > > It seems that SYSRESET_POWER_OFF was added recently, and all previous > code used SYSRESET_POWER for poweroff. SYSRESET_POWER is supposed > to be a PMIC-level power cycle, not a poweroff. > > Signed-off-by: Urja Rannikko > --- > Note: I didnt touch the test/dm/sysreset.c code yet, mostly because I wanted > to > get feedback on this first and that i'd need to understand the tests properly > to do > that (and i havent used them before at all). > --- > arch/arm/mach-stm32mp/cmd_poweroff.c | 2 +- > arch/sandbox/cpu/state.c | 2 +- > drivers/power/pmic/stpmic1.c | 2 +- > drivers/sysreset/sysreset_psci.c | 2 +- > drivers/sysreset/sysreset_sandbox.c | 4 ++-- > 5 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mach-stm32mp/cmd_poweroff.c b/arch/arm/mach- > stm32mp/cmd_poweroff.c > index f54dd1daf2..62347425a0 100644 > --- a/arch/arm/mach-stm32mp/cmd_poweroff.c > +++ b/arch/arm/mach-stm32mp/cmd_poweroff.c > @@ -14,7 +14,7 @@ int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * > const argv[]) > puts("poweroff ...\n"); > mdelay(100); > > - ret = sysreset_walk(SYSRESET_POWER); > + ret = sysreset_walk(SYSRESET_POWER_OFF); > > if (ret == -EINPROGRESS) > mdelay(1000); > diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c index > d3b9c05985..dee5fde4f7 100644 > --- a/arch/sandbox/cpu/state.c > +++ b/arch/sandbox/cpu/state.c > @@ -355,7 +355,7 @@ void state_reset_for_test(struct sandbox_state *state) { > /* No reset yet, so mark it as such. Always allow power reset */ > state->last_sysreset = SYSRESET_COUNT; > - state->sysreset_allowed[SYSRESET_POWER] = true; > + state->sysreset_allowed[SYSRESET_POWER_OFF] = true; > > memset(&state->wdt, '\0', sizeof(state->wdt)); > memset(state->spi, '\0', sizeof(state->spi)); diff --git > a/drivers/power/pmic/stpmic1.c b/drivers/power/pmic/stpmic1.c index > 65296c5fc3..eb735f4fe3 100644 > --- a/drivers/power/pmic/stpmic1.c > +++ b/drivers/power/pmic/stpmic1.c > @@ -221,7 +221,7 @@ static int stpmic1_sysreset_request(struct udevice *dev, > enum sysreset_t type) > struct udevice *pmic_dev; > int ret; > > - if (type != SYSRESET_POWER) > + if (type != SYSRESET_POWER_OFF) > return -EPROTONOSUPPORT; In fact in the next part of the code, we are supporting only SYSRESET_POWER (reset with PMIC1 switch OFF and restart) and not SYSRESET_POWER_OFF because Power Cycle if RREQ_EN=1 I think you need to remove the update on this file for your patch and I will modified this function is to support both mode > ret = uclass_get_device_by_driver(UCLASS_PMIC, > diff --git a/drivers/sysreset/sysreset_psci.c > b/drivers/sysreset/sysreset_psci.c > index de2ec8aeb1..c7907b3226 100644 > --- a/drivers/sysreset/sysreset_psci.c > +++ b/drivers/sysreset/sysreset_psci.c > @@ -18,7 +18,7 @@ static int psci_sysreset_request(struct udevice *dev, enum > sysreset_t type) > case SYSRESET_COLD: > function_id = PSCI_0_2_FN_SYSTEM_RESET; > break; > - case SYSRESET_POWER: > + case SYSRESET_POWER_OFF: > function_id = PSCI_0_2_FN_SYSTEM_OFF; > break; > default: > diff --git a/drivers/sysreset/sysreset_sandbox.c > b/drivers/sysreset/sysreset_sandbox.c > index 38e2a7e241..8bc9f4b4cc 100644 > --- a/drivers/sysreset/sysreset_sandbox.c > +++ b/drivers/sysreset/sysreset_sandbox.c > @@ -57,13 +57,13 @@ static int sandbox_sysreset_request(struct udevice *dev, > enum sysreset_t type) > case SYSRESET_COLD: > state->last_sysreset = type; > break; > - case SYSRESET_POWER: > + case SYSRESET_POWER_OFF: > state->last_sysreset = type; > if (!state->sysreset_allowed[type]) > return -EACCES; > sandbox_exit(); > break; > - case SYSRESET_POWER_OFF: > + case SYSRESET_POWER: > if (!state->sysreset_allowed[type]) > return -EACCES; > default: > -- > 2.21.0 Regards. Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mailbox: introduce stm32-ipcc driver
Hi Fabien On 5/14/19 11:20 AM, Fabien Dessenne wrote: > On STM32 family, the IPCC peripheral allows the communication > between 2 processors offering doorbells mechanism. > > Signed-off-by: Fabien Dessenne > Signed-off-by: Loic Pallardy > --- > drivers/mailbox/Kconfig | 7 ++ > drivers/mailbox/Makefile | 1 + > drivers/mailbox/stm32-ipcc.c | 167 > +++ > 3 files changed, 175 insertions(+) > create mode 100644 drivers/mailbox/stm32-ipcc.c > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig > index 2836ee4..11bf552 100644 > --- a/drivers/mailbox/Kconfig > +++ b/drivers/mailbox/Kconfig > @@ -24,6 +24,13 @@ config TEGRA_HSP > This enables support for the NVIDIA Tegra HSP Hw module, which > implements doorbells, mailboxes, semaphores, and shared interrupts. > > +config STM32_IPCC > + bool "Enable STM32 IPCC controller support" > + depends on DM_MAILBOX && ARCH_STM32MP > + help > + This enables support for the STM32MP IPCC Hw module, which > + implements doorbells between 2 processors. > + > config K3_SEC_PROXY > bool "Texas Instruments K3 Secure Proxy Driver" > depends on DM_MAILBOX && ARCH_K3 > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile > index cd23769..a753cc4 100644 > --- a/drivers/mailbox/Makefile > +++ b/drivers/mailbox/Makefile > @@ -6,5 +6,6 @@ > obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox-uclass.o > obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox.o > obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox-test.o > +obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o > obj-$(CONFIG_TEGRA_HSP) += tegra-hsp.o > obj-$(CONFIG_K3_SEC_PROXY) += k3-sec-proxy.o > diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c > new file mode 100644 > index 000..c3df967 > --- /dev/null > +++ b/drivers/mailbox/stm32-ipcc.c > @@ -0,0 +1,167 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +/* > + * IPCC has one set of registers per CPU > + * IPCC_PROC_OFFST allows to define cpu registers set base address > + * according to the assigned proc_id. > + */ > + > +#define IPCC_PROC_OFFST 0x010 > + > +#define IPCC_XSCR0x008 > +#define IPCC_XTOYSR 0x00c > + > +#define IPCC_HWCFGR 0x3f0 > +#define IPCFGR_CHAN_MASK GENMASK(7, 0) > + > +#define RX_BIT_CHAN(chan)BIT(chan) > +#define TX_BIT_SHIFT 16 > +#define TX_BIT_CHAN(chan)BIT(TX_BIT_SHIFT + (chan)) > + > +#define STM32_MAX_PROCS 2 > + > +struct stm32_ipcc { > + void __iomem *reg_base; > + void __iomem *reg_proc; > + u32 proc_id; > + u32 n_chans; > +}; > + > +static int stm32_ipcc_request(struct mbox_chan *chan) > +{ > + struct stm32_ipcc *ipcc = dev_get_priv(chan->dev); > + > + debug("%s(chan=%p)\n", __func__, chan); > + > + if (chan->id >= ipcc->n_chans) { > + debug("%s failed to request channel: %ld\n", > + __func__, chan->id); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int stm32_ipcc_free(struct mbox_chan *chan) > +{ > + debug("%s(chan=%p)\n", __func__, chan); > + > + return 0; > +} > + > +static int stm32_ipcc_send(struct mbox_chan *chan, const void *data) > +{ > + struct stm32_ipcc *ipcc = dev_get_priv(chan->dev); > + > + debug("%s(chan=%p, data=%p)\n", __func__, chan, data); > + > + if (readl(ipcc->reg_proc + IPCC_XTOYSR) & BIT(chan->id)) > + return -EBUSY; > + > + /* set channel n occupied */ > + setbits_le32(ipcc->reg_proc + IPCC_XSCR, TX_BIT_CHAN(chan->id)); > + > + return 0; > +} > + > +static int stm32_ipcc_recv(struct mbox_chan *chan, void *data) > +{ > + struct stm32_ipcc *ipcc = dev_get_priv(chan->dev); > + u32 val; > + int proc_offset; > + > + debug("%s(chan=%p, data=%p)\n", __func__, chan, data); > + > + /* read 'channel occupied' status from other proc */ > + proc_offset = ipcc->proc_id ? -IPCC_PROC_OFFST : IPCC_PROC_OFFST; > + val = readl(ipcc->reg_proc + proc_offset + IPCC_XTOYSR); > + > + if (!(val & BIT(chan->id))) > + return -ENODATA; > + > + setbits_le32(ipcc->reg_proc + IPCC_XSCR, RX_BIT_CHAN(chan->id)); > + > + return 0; > +} > + > +static int stm32_ipcc_probe(struct udevice *dev) > +{ > + struct stm32_ipcc *ipcc = dev_get_priv(dev); > + fdt_addr_t addr; > + const fdt32_t *cell; > + struct clk clk; > + int len, ret; > + > + debug("%s(dev=%p)\n", __func__, dev); > + > + addr = dev_read_addr(dev); > + if (addr == FDT_ADDR_T_NONE) > + return -EINVAL; > + > + ipcc->reg_base = (void __iomem *)addr; > + > + /* proc_id */ > + cell = dev_read_prop(dev, "st,proc_id", &len); > + if (len < sizeof(fdt32_t)) { > + dev_dbg(dev, "Missing st,proc
Re: [U-Boot] [PATCH 3/4] configs: stm32mp15: enable IPCC mailbox
On 5/14/19 11:20 AM, Fabien Dessenne wrote: > Activate the ipcc mailbox for stm32mp15 configs. > > Signed-off-by: Fabien Dessenne > --- > configs/stm32mp15_basic_defconfig | 2 ++ > configs/stm32mp15_trusted_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/stm32mp15_basic_defconfig > b/configs/stm32mp15_basic_defconfig > index 0ea9dff..f03c72c 100644 > --- a/configs/stm32mp15_basic_defconfig > +++ b/configs/stm32mp15_basic_defconfig > @@ -52,6 +52,8 @@ CONFIG_DM_I2C=y > CONFIG_SYS_I2C_STM32F7=y > CONFIG_LED=y > CONFIG_LED_GPIO=y > +CONFIG_DM_MAILBOX=y > +CONFIG_STM32_IPCC=y > CONFIG_DM_MMC=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_STM32_SDMMC2=y > diff --git a/configs/stm32mp15_trusted_defconfig > b/configs/stm32mp15_trusted_defconfig > index 3c2bb75..525f4c3 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -44,6 +44,8 @@ CONFIG_DM_I2C=y > CONFIG_SYS_I2C_STM32F7=y > CONFIG_LED=y > CONFIG_LED_GPIO=y > +CONFIG_DM_MAILBOX=y > +CONFIG_STM32_IPCC=y > CONFIG_DM_MMC=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_STM32_SDMMC2=y > Reviewed-by: Patrice Chotard Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] MAINTAINERS: Add stm32 mailbox IPPC driver
On 5/14/19 11:20 AM, Fabien Dessenne wrote: > Signed-off-by: Fabien Dessenne > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 33fd465..5523c4a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -301,6 +301,7 @@ S:Maintained > F: arch/arm/mach-stm32mp/ > F: drivers/clk/clk_stm32mp1.c > F: drivers/i2c/stm32f7_i2c.c > +F: drivers/mailbox/stm32-ipcc.c > F: drivers/misc/stm32mp_fuse.c > F: drivers/mmc/stm32_sdmmc2.c > F: drivers/phy/phy-stm32-usbphyc.c > Reviewed-by: Patrice Chotard Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: dts: stm32: Add ipcc mailbox support on stm32mp1
On 5/14/19 11:20 AM, Fabien Dessenne wrote: > Add IPCC mailbox support on stm32mp157 eval and disco boards. > > Signed-off-by: Fabien Dessenne > --- > arch/arm/dts/stm32mp157a-dk1.dts | 4 > arch/arm/dts/stm32mp157c-ed1.dts | 4 > arch/arm/dts/stm32mp157c.dtsi| 13 + > 3 files changed, 21 insertions(+) > > diff --git a/arch/arm/dts/stm32mp157a-dk1.dts > b/arch/arm/dts/stm32mp157a-dk1.dts > index e36773d..b8dd4ba 100644 > --- a/arch/arm/dts/stm32mp157a-dk1.dts > +++ b/arch/arm/dts/stm32mp157a-dk1.dts > @@ -228,6 +228,10 @@ > }; > }; > > +&ipcc { > + status = "okay"; > +}; > + > &iwdg2 { > timeout-sec = <32>; > status = "okay"; > diff --git a/arch/arm/dts/stm32mp157c-ed1.dts > b/arch/arm/dts/stm32mp157c-ed1.dts > index b10208f..ab11c83 100644 > --- a/arch/arm/dts/stm32mp157c-ed1.dts > +++ b/arch/arm/dts/stm32mp157c-ed1.dts > @@ -318,6 +318,10 @@ > }; > }; > > +&ipcc { > + status = "okay"; > +}; > + > &iwdg2 { > timeout-sec = <32>; > status = "okay"; > diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi > index 9463433..d90028a 100644 > --- a/arch/arm/dts/stm32mp157c.dtsi > +++ b/arch/arm/dts/stm32mp157c.dtsi > @@ -849,6 +849,19 @@ > status = "disabled"; > }; > > + ipcc: mailbox@4c001000 { > + compatible = "st,stm32mp1-ipcc"; > + #mbox-cells = <1>; > + reg = <0x4c001000 0x400>; > + st,proc-id = <0>; > + interrupts-extended = > + <&intc GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, > + <&intc GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "rx", "tx"; > + clocks = <&rcc IPCC>; > + status = "disabled"; > + }; > + > rcc: rcc@5000 { > compatible = "st,stm32mp1-rcc", "syscon"; > reg = <0x5000 0x1000>; > Reviewed-by: Patrice Chotard Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] configs: Add SPL Kconfig options
Add CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_NAND_SUPPORT for Kconfig selection. Signed-off-by: Jagan Teki Signed-off-by: Shyam Saini --- configs/imx6dl_icore_nand_defconfig | 1 + configs/imx6dl_mamoj_defconfig | 1 + configs/imx6q_icore_nand_defconfig | 1 + configs/imx6q_logic_defconfig| 1 + configs/imx6qdl_icore_mipi_defconfig | 1 + configs/imx6qdl_icore_mmc_defconfig | 1 + configs/imx6qdl_icore_nand_defconfig | 1 + configs/imx6qdl_icore_rqs_defconfig | 1 + configs/imx6ul_geam_mmc_defconfig| 1 + configs/imx6ul_geam_nand_defconfig | 1 + configs/imx6ul_isiot_emmc_defconfig | 1 + configs/imx6ul_isiot_nand_defconfig | 1 + include/configs/imx6-engicam.h | 10 +- 13 files changed, 13 insertions(+), 9 deletions(-) diff --git a/configs/imx6dl_icore_nand_defconfig b/configs/imx6dl_icore_nand_defconfig index 7b1f7abc4e..94c81b3e4a 100644 --- a/configs/imx6dl_icore_nand_defconfig +++ b/configs/imx6dl_icore_nand_defconfig @@ -13,6 +13,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_SPL_NAND_SUPPORT=y CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=3 diff --git a/configs/imx6dl_mamoj_defconfig b/configs/imx6dl_mamoj_defconfig index f3661c0a76..62a068c3c1 100644 --- a/configs/imx6dl_mamoj_defconfig +++ b/configs/imx6dl_mamoj_defconfig @@ -11,6 +11,7 @@ CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=3 CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_OS_BOOT=y +CONFIG_SPL_MMC_SUPPORT=y CONFIG_CRC32_VERIFY=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_DFU=y diff --git a/configs/imx6q_icore_nand_defconfig b/configs/imx6q_icore_nand_defconfig index 1e26f7a8c9..58c4ccc66c 100644 --- a/configs/imx6q_icore_nand_defconfig +++ b/configs/imx6q_icore_nand_defconfig @@ -13,6 +13,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_SPL_NAND_SUPPORT=y CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=3 diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig index 385efcec4e..33f9c3b19d 100644 --- a/configs/imx6q_logic_defconfig +++ b/configs/imx6q_logic_defconfig @@ -19,6 +19,7 @@ CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y CONFIG_BOUNCE_BUFFER=y CONFIG_SPL_RAW_IMAGE_SUPPORT=y CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_MMC_SUPPORT=y # CONFIG_TPL_BANNER_PRINT is not set # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set CONFIG_SPL_DMA_SUPPORT=y diff --git a/configs/imx6qdl_icore_mipi_defconfig b/configs/imx6qdl_icore_mipi_defconfig index 7a0e5169b6..8b30115b37 100644 --- a/configs/imx6qdl_icore_mipi_defconfig +++ b/configs/imx6qdl_icore_mipi_defconfig @@ -17,6 +17,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_LOAD_FIT=y CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" diff --git a/configs/imx6qdl_icore_mmc_defconfig b/configs/imx6qdl_icore_mmc_defconfig index 223f732207..8b8b382bf9 100644 --- a/configs/imx6qdl_icore_mmc_defconfig +++ b/configs/imx6qdl_icore_mmc_defconfig @@ -24,6 +24,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_LOAD_FIT=y CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" diff --git a/configs/imx6qdl_icore_nand_defconfig b/configs/imx6qdl_icore_nand_defconfig index 8702426561..5dfd276270 100644 --- a/configs/imx6qdl_icore_nand_defconfig +++ b/configs/imx6qdl_icore_nand_defconfig @@ -12,6 +12,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_SPL_NAND_SUPPORT=y CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=3 diff --git a/configs/imx6qdl_icore_rqs_defconfig b/configs/imx6qdl_icore_rqs_defconfig index a4766063ca..a56196b68a 100644 --- a/configs/imx6qdl_icore_rqs_defconfig +++ b/configs/imx6qdl_icore_rqs_defconfig @@ -14,6 +14,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_LOAD_FIT=y CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" diff --git a/configs/imx6ul_geam_mmc_defconfig b/configs/imx6ul_geam_mmc_defconfig index 8a7f41b53c..4c328fac2f 100644 --- a/configs/imx6ul_geam_mmc_defconfig +++ b/configs/imx6ul_geam_mmc_defconfig @@ -14,6 +14,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_SPL_MMC_SUPPORT=y CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=3 diff --git a/configs/imx6ul_geam_nand_defconfig b/configs/imx6ul_geam_nand_defconfig index bf61f768ab..22b559b9ed 100644 --- a/configs/
[U-Boot] [PATCH 2/2] Kconfig: Add BUILD_TARGET for i.MX6 images
Right now, i.MX6 supports single image variants like u-boot-with-spl.imx and u-boot-nand-with-spl.imx for MMC and NAND boots respectively. But, it requires an explicit argument passing to 'make' to build these images, like 'make u-boot-with-spl.imx' This patch would fix this by selecting BUILD_TARGET images with respective SPL variants MMC, NAND. This would eventually help us to get rid of explicit argument passing to 'make' to build these single images. Tested-by: Shyam Saini Signed-off-by: Jagan Teki Signed-off-by: Shyam Saini --- Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Kconfig b/Kconfig index 7a5491bd67..05d1a19b1d 100644 --- a/Kconfig +++ b/Kconfig @@ -243,6 +243,8 @@ config BUILD_TARGET default "u-boot.itb" if SPL_LOAD_FIT && ARCH_SUNXI default "u-boot.kwb" if KIRKWOOD default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT + default "u-boot-with-spl.imx" if ARCH_MX6 && SPL_MMC_SUPPORT + default "u-boot-with-nand-spl.imx" if ARCH_MX6 && SPL_NAND_SUPPORT help Some SoCs need special image types (e.g. U-Boot binary with a special header) as build targets. By defining -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] board_r: move initr_serial to be called before initr_watchdog
On 16.05.19 08:48, Weijie Gao wrote: The initr_watchdog is currently placed before initr_serial. The initr_watchdog calls printf and printf finally calls ops->putc of a serial driver. However, gd->cur_serial_dev points to a udevice allocated in board_f. The gd->cur_serial_dev->driver->ops->putc points the the code region before relocation. Some serial drivers call WATCHDOG_RESET() in ops->putc. When DM is enabled for watchdog, watchdog_reset() is called. watchdog_reset() calls get_timer to get current timer. On some platforms the timer driver is also a DM driver. initr_watchdog is placed right after initr_dm, which means the timer driver hasn't been initialized. So dm_timer_init() is called. To create a new udevice, calloc is called. However start from ops->putc, u-boot execution flow is redirected into the memory region before relocation (board_f). In board_f, dlmalloc hasn't been initialized. The call to calloc will fail, and this will cause DM to print out an error message, and it will call printf again, causing recursive error outputs. This patch places initr_serial before initr_watchdog to solve this issue. Cc: Stefan Roese Reviewed-by: Ryder Lee Signed-off-by: Weijie Gao --- common/board_r.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/board_r.c b/common/board_r.c index 150e8cd424..a298146c2b 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -678,6 +678,7 @@ static init_fnc_t init_sequence_r[] = { #ifdef CONFIG_DM initr_dm, #endif + initr_serial, #if defined(CONFIG_WDT) initr_watchdog, #endif @@ -698,7 +699,6 @@ static init_fnc_t init_sequence_r[] = { efi_memory_init, #endif stdio_init_tables, - initr_serial, initr_announce, I'm not 100% sure, if moving initr_serial before stdio_init_tables and other functions is safe. Perhaps its better to just move initr_watchdog down a bit, perhaps after initr_announce? What do you think? Thanks, Stefan BTW: Somehow your Cc'ing me did not reach me directly. I only found the patch on the list. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] watchdog: mtk_wdt: fix timeout calculation
On 16.05.19 08:49, Weijie Gao wrote: U-Boot passes timeout in milliseconds for ops->start. However the driver treats this value as seconds. This will cause an overflow on writing wdt register. This patch divides the timeout by 1000 before writing to wdt register. Reviewed-by: Ryder Lee Signed-off-by: Weijie Gao Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: mediatek: remove arch_misc_init
On 16.05.19 08:49, Weijie Gao wrote: The watchdog of mediatek chips is enabled by bootrom before u-boot is running. Previously we choose to enable the wdt driver only to disable the watchdog hardware. Now wdt service is enabled by default. The function arch_misc_init which is only used to disable wdt is no longer needed. Reviewed-by: Ryder Lee Signed-off-by: Weijie Gao I must have missed this WDT init in my cleanup series. Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate
On Thu, 9 May 2019 01:13:15 + Peng Fan wrote: > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > clk_fixed_rate > > > > On Wed, 8 May 2019 07:45:39 + > > Peng Fan wrote: > > > > > > -Original Message- > > > > From: Lukasz Majewski [mailto:lu...@denx.de] > > > > Sent: 2019年5月8日 15:40 > > > > To: Peng Fan > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx > > > > ; s...@chromium.org; > > ja...@amarulasolutions.com; > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > clk_fixed_rate > > > > > > > > On Wed, 8 May 2019 06:51:46 + > > > > Peng Fan wrote: > > > > > > > > > > -Original Message- > > > > > > From: Lukasz Majewski [mailto:lu...@denx.de] > > > > > > Sent: 2019年5月8日 14:46 > > > > > > To: Peng Fan > > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx > > > > > > ; s...@chromium.org; > > > > ja...@amarulasolutions.com; > > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > > > clk_fixed_rate > > > > > > > > > > > > On Tue, 7 May 2019 13:27:45 + Peng Fan > > > > > > wrote: > > > > > > > > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > > > > > clk_fixed_rate > > > > > > > > > > > > > > > > Hi Peng, > > > > > > > > > > > > > > > > > Export the structure for others to use. > > > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > --- > > > > > > > > > drivers/clk/clk_fixed_rate.c | 8 +--- > > > > > > > > > include/linux/clk-provider.h | 7 +++ > > > > > > > > > 2 files changed, 8 insertions(+), 7 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/drivers/clk/clk_fixed_rate.c > > > > > > > > > b/drivers/clk/clk_fixed_rate.c index > > > > > > > > > 089f060a23..069e643fbc 100644 --- > > > > > > > > > a/drivers/clk/clk_fixed_rate.c +++ > > > > > > > > > b/drivers/clk/clk_fixed_rate.c @@ -6,13 +6,7 @@ > > > > > > > > > #include #include > > > > > > > > > #include - > > > > > > > > > -struct clk_fixed_rate { > > > > > > > > > - struct clk clk; > > > > > > > > > - unsigned long fixed_rate; > > > > > > > > > -}; > > > > > > > > > - > > > > > > > > > -#define to_clk_fixed_rate(dev) ((struct > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +#include > > > > > > > > > > > > > > > > > > > > > > > > > > > static ulong clk_fixed_rate_get_rate(struct clk > > > > > > > > > *clk) { diff --git a/include/linux/clk-provider.h > > > > > > > > > b/include/linux/clk-provider.h index > > > > > > > > > 3ed0db86d2..b2bed768b6 100644 --- > > > > > > > > > a/include/linux/clk-provider.h +++ > > > > > > > > > b/include/linux/clk-provider.h @@ -112,6 +112,13 @@ > > > > > > > > > struct clk_fixed_factor { #define > > > > > > > > > to_clk_fixed_factor(_clk) container_of(_clk, struct > > > > > > > > > clk_fixed_factor,\ clk) > > > > > > > > > > > > > > > > > > +struct clk_fixed_rate { > > > > > > > > > + struct clk clk; > > > > > > > > > + unsigned long fixed_rate; }; > > > > > > > > > > > > > > > > I think that this struct shall stay where it was. > > > > > > > > Moreover, the clk-provider.h is not the API to be used > > > > > > > > by other parts of the clock API. > > > > > > > > > > > > > > > > The clk_fixed_rate shall be accessed via get_rate() > > > > > > > > only and in IMX6Q it is available in early SPL (parsed > > > > > > > > from dts /clocks property > > > > > > > > - the 24MHz OSC) > > > > > > > > > + > > > > > > > > > +#define to_clk_fixed_rate(dev) ((struct > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) + int > > > > > > > > > clk_register(struct clk *clk, const char *drv_name, > > > > > > > > >ulong drv_data, const char *name, > > > > > > > > >const char *parent_name); > > > > > > > > > > > > > > > > Please explain why iMX8MM needs such global export? > > > > > > > > > > > > > > In clk-imx8mm.c, first configure ARM clk to osc24M fixed > > > > > > > clk to change pll clock. > > > > > > > + /* Configure ARM to osc24M */ > > > > > > > + clk_get_by_id(IMX8MM_CLK_A53_SRC, &clkp); > > > > > > > + uclass_get_device_by_name(UCLASS_CLK, > > > > > > > "clock-osc-24m", > > > > > > &devp); > > > > > > > + clkp1 = &to_clk_fixed_rate(devp)->clk; > > > > > > > + clk_set_parent(clkp, clkp1); > > > > > > > > > > > > This code looks a bit strange to me. Why imx8mm sets parent > > > > > > here? > > > > > > > > > > The A53 clk could not change on the fly. There is a mux here, > > > > > one is PLL, one is OSC, And there are others. If we want to > > > > > change the pll clock which is currently being used by A53, we > > > > > need first switch the A53 clk to source from OSC, then change > > > > > pll clock, then switch A53 clk back to PLL. > > > > > > > > The above description looks lik
Re: [U-Boot] [PATCH 1/3] board_r: move initr_serial to be called before initr_watchdog
On Thu, 2019-05-16 at 10:21 +0200, Stefan Roese wrote: > On 16.05.19 08:48, Weijie Gao wrote: > > The initr_watchdog is currently placed before initr_serial. The > > initr_watchdog calls printf and printf finally calls ops->putc of a serial > > driver. > > > > However, gd->cur_serial_dev points to a udevice allocated in board_f. The > > gd->cur_serial_dev->driver->ops->putc points the the code region before > > relocation. > > > > Some serial drivers call WATCHDOG_RESET() in ops->putc. When DM is enabled > > for watchdog, watchdog_reset() is called. watchdog_reset() calls get_timer > > to get current timer. > > > > On some platforms the timer driver is also a DM driver. initr_watchdog is > > placed right after initr_dm, which means the timer driver hasn't been > > initialized. So dm_timer_init() is called. To create a new udevice, calloc > > is called. > > > > However start from ops->putc, u-boot execution flow is redirected into the > > memory region before relocation (board_f). In board_f, dlmalloc hasn't > > been initialized. The call to calloc will fail, and this will cause DM to > > print out an error message, and it will call printf again, causing > > recursive error outputs. > > > > This patch places initr_serial before initr_watchdog to solve this issue. > > > > Cc: Stefan Roese > > Reviewed-by: Ryder Lee > > Signed-off-by: Weijie Gao > > --- > > common/board_r.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/common/board_r.c b/common/board_r.c > > index 150e8cd424..a298146c2b 100644 > > --- a/common/board_r.c > > +++ b/common/board_r.c > > @@ -678,6 +678,7 @@ static init_fnc_t init_sequence_r[] = { > > #ifdef CONFIG_DM > > initr_dm, > > #endif > > + initr_serial, > > #if defined(CONFIG_WDT) > > initr_watchdog, > > #endif > > @@ -698,7 +699,6 @@ static init_fnc_t init_sequence_r[] = { > > efi_memory_init, > > #endif > > stdio_init_tables, > > - initr_serial, > > initr_announce, > > I'm not 100% sure, if moving initr_serial before stdio_init_tables and > other functions is safe. Perhaps its better to just move initr_watchdog > down a bit, perhaps after initr_announce? > > What do you think? > > Thanks, > Stefan > > BTW: Somehow your Cc'ing me did not reach me directly. I only found the > patch on the list. I'll change it to move initr_watchdog only. My company's mail server reported delivery failure every time I Cc'ed you and some others. I have no idea. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] riscv: sifive: fu540: Make GEM 10/100 Mbps work
At present the GEM ethernet on SiFive Unleashed board can only work in 1000 Mbps mode. With a 10/100 Mbps connection it just fails to do any network communication. This adds a new GEMGXL clock driver to adjust the clock settings per the connection speed so that 10/100 Mbps works. Bin Meng (4): clk: sifive: Add clock driver for GEMGXL MGMT dm: net: macb: Update macb_linkspd_cb() signature dm: net: macb: Implement link speed change callback sifive: fu540: Enable GEMGXL MGMT driver board/sifive/fu540/Kconfig | 1 + drivers/clk/sifive/Kconfig | 7 + drivers/clk/sifive/Makefile | 2 ++ drivers/clk/sifive/gemgxl-mgmt.c | 60 drivers/net/macb.c | 48 +++- 5 files changed, 117 insertions(+), 1 deletion(-) create mode 100644 drivers/clk/sifive/gemgxl-mgmt.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] clk: sifive: Add clock driver for GEMGXL MGMT
This adds a clock driver to support the GEMGXL management IP block found in FU540 SoCs to control GEM TX clock operation mode for 10/100/1000 Mbps. Signed-off-by: Bin Meng --- drivers/clk/sifive/Kconfig | 7 + drivers/clk/sifive/Makefile | 2 ++ drivers/clk/sifive/gemgxl-mgmt.c | 60 3 files changed, 69 insertions(+) create mode 100644 drivers/clk/sifive/gemgxl-mgmt.c diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig index 81fc9f8..644881b 100644 --- a/drivers/clk/sifive/Kconfig +++ b/drivers/clk/sifive/Kconfig @@ -17,3 +17,10 @@ config CLK_SIFIVE_FU540_PRCI Supports the Power Reset Clock interface (PRCI) IP block found in FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, enable this driver. + +config CLK_SIFIVE_GEMGXL_MGMT + bool "GEMGXL management for SiFive FU540 SoCs" + depends on CLK_SIFIVE + help + Supports the GEMGXL management IP block found in FU540 SoCs to + control GEM TX clock operation mode for 10/100/1000 Mbps. diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile index 1155e07..f8263e7 100644 --- a/drivers/clk/sifive/Makefile +++ b/drivers/clk/sifive/Makefile @@ -3,3 +3,5 @@ obj-$(CONFIG_CLK_ANALOGBITS_WRPLL_CLN28HPC)+= wrpll-cln28hpc.o obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o + +obj-$(CONFIG_CLK_SIFIVE_GEMGXL_MGMT) += gemgxl-mgmt.o diff --git a/drivers/clk/sifive/gemgxl-mgmt.c b/drivers/clk/sifive/gemgxl-mgmt.c new file mode 100644 index 000..d989989 --- /dev/null +++ b/drivers/clk/sifive/gemgxl-mgmt.c @@ -0,0 +1,60 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019, Bin Meng + */ + +#include +#include +#include +#include + +struct gemgxl_mgmt_regs { + __u32 tx_clk_sel; +}; + +struct gemgxl_mgmt_platdata { + struct gemgxl_mgmt_regs *regs; +}; + +static int gemgxl_mgmt_ofdata_to_platdata(struct udevice *dev) +{ + struct gemgxl_mgmt_platdata *plat = dev_get_platdata(dev); + + plat->regs = (struct gemgxl_mgmt_regs *)dev_read_addr(dev); + + return 0; +} + +static ulong gemgxl_mgmt_set_rate(struct clk *clk, ulong rate) +{ + struct gemgxl_mgmt_platdata *plat = dev_get_platdata(clk->dev); + + /* +* GEMGXL TX clock operation mode: +* +* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic +* and output clock on GMII output signal GTX_CLK +* 1 = MII mode. Use MII input signal TX_CLK in TX logic +*/ + writel(rate != 12500, &plat->regs->tx_clk_sel); + + return 0; +} + +const struct clk_ops gemgxl_mgmt_ops = { + .set_rate = gemgxl_mgmt_set_rate, +}; + +static const struct udevice_id gemgxl_mgmt_match[] = { + { .compatible = "sifive,cadencegemgxlmgmt0", }, + { /* sentinel */ } +}; + +U_BOOT_DRIVER(gemgxl_mgmt) = { + .name = "gemgxl-mgmt", + .id = UCLASS_CLK, + .of_match = gemgxl_mgmt_match, + .ofdata_to_platdata = gemgxl_mgmt_ofdata_to_platdata, + .platdata_auto_alloc_size = sizeof(struct gemgxl_mgmt_platdata), + .ops = &gemgxl_mgmt_ops, +}; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] dm: net: macb: Implement link speed change callback
At present the link speed change callback is a nop. According to macb device tree bindings, an optional "tx_clk" is used to clock the ethernet controller's TX_CLK under different link speed. In 10/100 MII mode, transmit logic must be clocked from a free running clock generated by the external PHY. In gigabit GMII mode, the controller, not the external PHY, must generate the 125 MHz transmit clock towards the PHY. Signed-off-by: Bin Meng --- drivers/net/macb.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index b7f404e..7d86fa1 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -497,6 +497,32 @@ static int macb_phy_find(struct macb_device *macb, const char *name) #ifdef CONFIG_DM_ETH int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed) { +#ifdef CONFIG_CLK + struct clk tx_clk; + ulong rate; + int ret; + + ret = clk_get_by_name(dev, "tx_clk", &tx_clk); + if (ret) + return 0; + + switch (speed) { + case _10BASET: + rate = 250; + break; + case _100BASET: + rate = 2500; + break; + case _1000BASET: + default: + rate = 12500; + break; + } + + if (tx_clk.dev) + clk_set_rate(&tx_clk, rate); +#endif + return 0; } #else -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] dm: net: macb: Update macb_linkspd_cb() signature
This updates DM version macb_linkspd_cb() signature for future expansion, eg: adding an implementation for link speed changes. Signed-off-by: Bin Meng --- drivers/net/macb.c | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 7261416..b7f404e 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -488,15 +488,23 @@ static int macb_phy_find(struct macb_device *macb, const char *name) /** * macb_linkspd_cb - Linkspeed change callback function - * @regs: Base Register of MACB devices + * @dev/@regs: MACB udevice (DM version) or + * Base Register of MACB devices (non-DM version) * @speed: Linkspeed * Returns 0 when operation success and negative errno number * when operation failed. */ +#ifdef CONFIG_DM_ETH +int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed) +{ + return 0; +} +#else int __weak macb_linkspd_cb(void *regs, unsigned int speed) { return 0; } +#endif #ifdef CONFIG_DM_ETH static int macb_phy_init(struct udevice *dev, const char *name) @@ -589,7 +597,11 @@ static int macb_phy_init(struct macb_device *macb, const char *name) macb_writel(macb, NCFGR, ncfgr); +#ifdef CONFIG_DM_ETH + ret = macb_linkspd_cb(dev, _1000BASET); +#else ret = macb_linkspd_cb(macb->regs, _1000BASET); +#endif if (ret) return ret; @@ -614,9 +626,17 @@ static int macb_phy_init(struct macb_device *macb, const char *name) ncfgr &= ~(MACB_BIT(SPD) | MACB_BIT(FD) | GEM_BIT(GBE)); if (speed) { ncfgr |= MACB_BIT(SPD); +#ifdef CONFIG_DM_ETH + ret = macb_linkspd_cb(dev, _100BASET); +#else ret = macb_linkspd_cb(macb->regs, _100BASET); +#endif } else { +#ifdef CONFIG_DM_ETH + ret = macb_linkspd_cb(dev, _10BASET); +#else ret = macb_linkspd_cb(macb->regs, _10BASET); +#endif } if (ret) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] sifive: fu540: Enable GEMGXL MGMT driver
Enable the new GEMGXL MGMT driver so that GEM 10/100 Mbps works now. Signed-off-by: Bin Meng --- board/sifive/fu540/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index f464379..8eb5e30 100644 --- a/board/sifive/fu540/Kconfig +++ b/board/sifive/fu540/Kconfig @@ -28,6 +28,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply CMD_PING imply CLK_SIFIVE imply CLK_SIFIVE_FU540_PRCI + imply CLK_SIFIVE_GEMGXL_MGMT imply DOS_PARTITION imply EFI_PARTITION imply IP_DYN -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] board_r: move initr_watchdog to be called after initr_serial
The initr_watchdog is currently placed before initr_serial. The initr_watchdog calls printf and printf finally calls ops->putc of a serial driver. However, gd->cur_serial_dev points to a udevice allocated in board_f. The gd->cur_serial_dev->driver->ops->putc points the the code region before relocation. Some serial drivers call WATCHDOG_RESET() in ops->putc. When DM is enabled for watchdog, watchdog_reset() is called. watchdog_reset() calls get_timer to get current timer. On some platforms the timer driver is also a DM driver. initr_watchdog is placed right after initr_dm, which means the timer driver hasn't been initialized. So dm_timer_init() is called. To create a new udevice, calloc is called. However start from ops->putc, u-boot execution flow is redirected into the memory region before relocation (board_f). In board_f, dlmalloc hasn't been initialized. The call to calloc will fail, and this will cause DM to print out an error message, and it will call printf again, causing recursive error outputs. This patch places initr_watchdog after initr_serial to solve this issue. Cc: Stefan Roese Reviewed-by: Ryder Lee Signed-off-by: Weijie Gao --- Changes since v1: move initr_watchdog instead of initr_serial --- common/board_r.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/common/board_r.c b/common/board_r.c index 150e8cd424..df24021f2c 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -678,9 +678,6 @@ static init_fnc_t init_sequence_r[] = { #ifdef CONFIG_DM initr_dm, #endif -#if defined(CONFIG_WDT) - initr_watchdog, -#endif #if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \ defined(CONFIG_SANDBOX) board_init, /* Setup chipselects */ @@ -700,6 +697,9 @@ static init_fnc_t init_sequence_r[] = { stdio_init_tables, initr_serial, initr_announce, +#if defined(CONFIG_WDT) + initr_watchdog, +#endif INIT_FUNC_WATCHDOG_RESET #ifdef CONFIG_NEEDS_MANUAL_RELOC initr_manual_reloc_cmdtable, -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] watchdog: mtk_wdt: fix timeout calculation
U-Boot passes timeout in milliseconds for ops->start. However the driver treats this value as seconds. This will cause an overflow on writing wdt register. This patch divides the timeout by 1000 before writing to wdt register. Reviewed-by: Stefan Roese Reviewed-by: Ryder Lee Signed-off-by: Weijie Gao --- Changes since v1: none --- drivers/watchdog/mtk_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 0b501733f2..19e3fde968 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -78,7 +78,7 @@ static void mtk_wdt_set_timeout(struct udevice *dev, unsigned int timeout) * One bit is the value of 512 ticks * The clock has 32 KHz */ - timeout = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY; + timeout = WDT_LENGTH_TIMEOUT((timeout << 6) / 1000) | WDT_LENGTH_KEY; writel(timeout, priv->base + MTK_WDT_LENGTH); mtk_wdt_reset(dev); -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] arm: mediatek: remove arch_misc_init
The watchdog of mediatek chips is enabled by bootrom before u-boot is running. Previously we choose to enable the wdt driver only to disable the watchdog hardware. Now wdt service is enabled by default. The function arch_misc_init which is only used to disable wdt is no longer needed. Reviewed-by: Stefan Roese Reviewed-by: Ryder Lee Signed-off-by: Weijie Gao --- Changes since v1: none --- arch/arm/mach-mediatek/Kconfig | 3 --- arch/arm/mach-mediatek/cpu.c | 12 2 files changed, 15 deletions(-) diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig index b5e91d4a7d..60aef15f15 100644 --- a/arch/arm/mach-mediatek/Kconfig +++ b/arch/arm/mach-mediatek/Kconfig @@ -12,7 +12,6 @@ choice config TARGET_MT7623 bool "MediaTek MT7623 SoC" select CPU_V7A - select ARCH_MISC_INIT help The MediaTek MT7623 is a ARM-based SoC with a quad-core Cortex-A7 including NEON and GPU, Mali-450 graphics, several DDR3 options, @@ -25,7 +24,6 @@ config TARGET_MT7629 bool "MediaTek MT7629 SoC" select CPU_V7A select SPL - select ARCH_MISC_INIT help The MediaTek MT7629 is a ARM-based SoC with a dual-core Cortex-A7 including DDR3, crypto engine, 3x3 11n/ac Wi-Fi, Gigabit Ethernet, @@ -34,7 +32,6 @@ config TARGET_MT7629 config TARGET_MT8516 bool "MediaTek MT8516 SoC" select ARM64 - select ARCH_MISC_INIT help The MediaTek MT8516 is a ARM64-based SoC with a quad-core Cortex-A35. including UART, SPI, USB2.0 and OTG, SD and MMC cards, NAND, PWM, diff --git a/arch/arm/mach-mediatek/cpu.c b/arch/arm/mach-mediatek/cpu.c index b37e299b74..1923c9e527 100644 --- a/arch/arm/mach-mediatek/cpu.c +++ b/arch/arm/mach-mediatek/cpu.c @@ -8,18 +8,6 @@ #include #include -int arch_misc_init(void) -{ - struct udevice *wdt; - int ret; - - ret = uclass_first_device_err(UCLASS_WDT, &wdt); - if (!ret) - wdt_stop(wdt); - - return 0; -} - int arch_cpu_init(void) { icache_enable(); -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
On Thu, 16 May 2019 08:15:23 +0100 Peter Robinson wrote: Hi Peter, > On Thu, May 16, 2019 at 1:47 AM Andre Przywara wrote: > > > > The first USB controller on the A64 SoC shares a PHY with the OTG > > controller. Reportedly to avoid problems with the VBUS regulator under > > Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file. > > > > However on boards which can't use peripheral mode (because they have an > > always-on VBUS supply on an USB-A socket) we don't need this trick, and > > can properly connect host controller 0 to the PHY 0. > > > > Amend the Pine64 and SoPine/LTS .dts to reflect this. This enables the > > upper USB port in U-Boot on those boards. > > > > Signed-off-by: Andre Przywara > > --- > > arch/arm/dts/sun50i-a64-pine64.dts | 5 - > > arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 - > > 2 files changed, 8 insertions(+), 2 deletions(-) > > Are these changes going to go upstream to Linux too? If not it's > probably best to add it to a u-boot.dtsi so the changes don't get lost > when the DT files are re-synced from Linux. Same with the similar > patches for the H6 boards. Yes, but I need to wait for the end of the merge window before I can post anything there. So I just posted this here to get some input on this. And we need to resync the DTs anyway, I will post something next week, probably syncing with 5.2-rc1. Actually I believe the changes belong into the .dtsi, as this is how the hardware is wired. But I need to do more tests, as Chen-Yu hinted that this might break USB-OTG on boards with a proper micro-B socket (like the Banana-Pi M64), due to the HCI driver always enabling VBUS. So far I failed to use host mode on that board, but I will keep digging. Cheers, Andre. > > diff --git a/arch/arm/dts/sun50i-a64-pine64.dts > > b/arch/arm/dts/sun50i-a64-pine64.dts > > index c077b6c1f4..523a4d5bff 100644 > > --- a/arch/arm/dts/sun50i-a64-pine64.dts > > +++ b/arch/arm/dts/sun50i-a64-pine64.dts > > @@ -80,6 +80,8 @@ > > }; > > > > &ehci0 { > > + phys = <&usbphy 0>; > > + phy-names = "usb"; > > status = "okay"; > > }; > > > > @@ -136,6 +138,8 @@ > > }; > > > > &ohci0 { > > + phys = <&usbphy 0>; > > + phy-names = "usb"; > > status = "okay"; > > }; > > > > @@ -301,7 +305,6 @@ > > > > &usb_otg { > > dr_mode = "host"; > > - status = "okay"; > > }; > > > > &usbphy { > > diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > > b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > > index 53fcc9098d..1986897177 100644 > > --- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > > +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts > > @@ -85,6 +85,8 @@ > > }; > > > > &ehci0 { > > + phys = <&usbphy 0>; > > + phy-names = "usb"; > > status = "okay"; > > }; > > > > @@ -131,6 +133,8 @@ > > }; > > > > &ohci0 { > > + phys = <&usbphy 0>; > > + phy-names = "usb"; > > status = "okay"; > > }; > > > > @@ -172,7 +176,6 @@ > > > > &usb_otg { > > dr_mode = "host"; > > - status = "okay"; > > }; > > > > &usbphy { > > -- > > 2.14.5 > > > > ___ > > 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] [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate
> Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate > > On Thu, 9 May 2019 01:13:15 + > Peng Fan wrote: > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > clk_fixed_rate > > > > > > On Wed, 8 May 2019 07:45:39 + > > > Peng Fan wrote: > > > > > > > > -Original Message- > > > > > From: Lukasz Majewski [mailto:lu...@denx.de] > > > > > Sent: 2019年5月8日 15:40 > > > > > To: Peng Fan > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx > > > > > ; s...@chromium.org; > > > ja...@amarulasolutions.com; > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > > clk_fixed_rate > > > > > > > > > > On Wed, 8 May 2019 06:51:46 + Peng Fan > > > > > wrote: > > > > > > > > > > > > -Original Message- > > > > > > > From: Lukasz Majewski [mailto:lu...@denx.de] > > > > > > > Sent: 2019年5月8日 14:46 > > > > > > > To: Peng Fan > > > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx > > > > > > > ; s...@chromium.org; > > > > > ja...@amarulasolutions.com; > > > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > > > > clk_fixed_rate > > > > > > > > > > > > > > On Tue, 7 May 2019 13:27:45 + Peng Fan > > > > > > > wrote: > > > > > > > > > > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > > > > > > clk_fixed_rate > > > > > > > > > > > > > > > > > > Hi Peng, > > > > > > > > > > > > > > > > > > > Export the structure for others to use. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > --- > > > > > > > > > > drivers/clk/clk_fixed_rate.c | 8 +--- > > > > > > > > > > include/linux/clk-provider.h | 7 +++ > > > > > > > > > > 2 files changed, 8 insertions(+), 7 deletions(-) > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/clk/clk_fixed_rate.c > > > > > > > > > > b/drivers/clk/clk_fixed_rate.c index > > > > > > > > > > 089f060a23..069e643fbc 100644 --- > > > > > > > > > > a/drivers/clk/clk_fixed_rate.c +++ > > > > > > > > > > b/drivers/clk/clk_fixed_rate.c @@ -6,13 +6,7 @@ > > > > > > > > > > #include #include #include > > > > > > > > > > - -struct clk_fixed_rate { > > > > > > > > > > - struct clk clk; > > > > > > > > > > - unsigned long fixed_rate; > > > > > > > > > > -}; > > > > > > > > > > - > > > > > > > > > > -#define to_clk_fixed_rate(dev) ((struct > > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +#include > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > static ulong clk_fixed_rate_get_rate(struct clk > > > > > > > > > > *clk) { diff --git a/include/linux/clk-provider.h > > > > > > > > > > b/include/linux/clk-provider.h index > > > > > > > > > > 3ed0db86d2..b2bed768b6 100644 --- > > > > > > > > > > a/include/linux/clk-provider.h +++ > > > > > > > > > > b/include/linux/clk-provider.h @@ -112,6 +112,13 @@ > > > > > > > > > > struct clk_fixed_factor { #define > > > > > > > > > > to_clk_fixed_factor(_clk) container_of(_clk, struct > > > > > > > > > > clk_fixed_factor,\ clk) > > > > > > > > > > > > > > > > > > > > +struct clk_fixed_rate { > > > > > > > > > > + struct clk clk; > > > > > > > > > > + unsigned long fixed_rate; }; > > > > > > > > > > > > > > > > > > I think that this struct shall stay where it was. > > > > > > > > > Moreover, the clk-provider.h is not the API to be used > > > > > > > > > by other parts of the clock API. > > > > > > > > > > > > > > > > > > The clk_fixed_rate shall be accessed via get_rate() only > > > > > > > > > and in IMX6Q it is available in early SPL (parsed from > > > > > > > > > dts /clocks property > > > > > > > > > - the 24MHz OSC) > > > > > > > > > > + > > > > > > > > > > +#define to_clk_fixed_rate(dev) ((struct > > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) + int > > > > > > > > > > clk_register(struct clk *clk, const char *drv_name, > > > > > > > > > > ulong drv_data, const char *name, > > > > > > > > > > const char *parent_name); > > > > > > > > > > > > > > > > > > Please explain why iMX8MM needs such global export? > > > > > > > > > > > > > > > > In clk-imx8mm.c, first configure ARM clk to osc24M fixed > > > > > > > > clk to change pll clock. > > > > > > > > + /* Configure ARM to osc24M */ > > > > > > > > + clk_get_by_id(IMX8MM_CLK_A53_SRC, &clkp); > > > > > > > > + uclass_get_device_by_name(UCLASS_CLK, > > > > > > > > "clock-osc-24m", > > > > > > > &devp); > > > > > > > > + clkp1 = &to_clk_fixed_rate(devp)->clk; > > > > > > > > + clk_set_parent(clkp, clkp1); > > > > > > > > > > > > > > This code looks a bit strange to me. Why imx8mm sets parent > > > > > > > here? > > > > > > > > > > > > The A53 clk could not change on the fly. There is a mux here, > > > > > > one is PLL, one is OSC, And there are others. If we want to > > > > > > chan
Re: [U-Boot] [linux-sunxi] [PATCH 2/6] sunxi: gpio: Enable support for H6 pin controller
On Thu, 16 May 2019 10:34:38 +0800 Icenowy Zheng wrote: Hi Icenowy, thanks for having a look! > 于 2019年5月16日 GMT+08:00 上午9:26:29, Andre Przywara 写到: > >The Allwinner H6 pin controller is not really special, at least not > >when it comes to normal GPIO operation. > > > >Add the H6 compatible strings to the list of recognised strings, to > >make GPIOs work for H6 boards. > > > >Signed-off-by: Andre Przywara > >--- > > drivers/gpio/sunxi_gpio.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > >diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c > >index cbed8d42b7..780c39962a 100644 > >--- a/drivers/gpio/sunxi_gpio.c > >+++ b/drivers/gpio/sunxi_gpio.c > >@@ -354,12 +354,14 @@ static const struct udevice_id sunxi_gpio_ids[] = > >{ > > ID("allwinner,sun8i-v3s-pinctrl", a_all), > > ID("allwinner,sun9i-a80-pinctrl", a_all), > > ID("allwinner,sun50i-a64-pinctrl", a_all), > >+ID("allwinner,sun50i-h6-pinctrl", a_all), > > ID("allwinner,sun6i-a31-r-pinctrl", l_2), > > ID("allwinner,sun8i-a23-r-pinctrl", l_1), > > ID("allwinner,sun8i-a83t-r-pinctrl",l_1), > > ID("allwinner,sun8i-h3-r-pinctrl", l_1), > > ID("allwinner,sun9i-a80-r-pinctrl", l_3), > > ID("allwinner,sun50i-a64-r-pinctrl",l_1), > >+ID("allwinner,sun50i-h6-r-pinctrl", l_1), > > Should be l_2 because H6 has PM bank. Oh, indeed, I totally missed that. Thanks for pointing this out! Cheers, Andre ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/9] arm: mvebu: clearfog: support boot from SATA disk
This series enables support for boot from SATA on the SolidRun Clearfog platform. Patches 1-3 are preparations for the addition of loading U-Boot main image from raw SATA device. They make spl sata code independent of board macros and specific kconfig symbols. Patch 4 adds to SPL generic support for loading U-Boot from a raw SATA device. This code is modeled after the similar support for MMC devices. Patches 5-6 are mvebu specific. Patch 5 fixes SATA access from SPL. Patch 6 adds the SATA boot option at the SoC level. Patches 7-9 are the board specific update that enable SATA boot in Clearfog, and document the offset setting requirement. Baruch Siach (9): spl: sata: add default partition and image name spl: sata: fix build with DM_SCSI spl: sata: don't force FS_FAT support spl: sata: support U-Boot load from raw sata disk arm: mvebu: fix ahci mbus config in SPL arm: mvebu: add support for boot from SATA arm: mvebu: clearfog: enable SATA in SPL arm: mvebu: clearfog: set U-Boot offset for SATA boot arm: mvebu: clearfog: document boot from SATA arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8 arch/arm/mach-mvebu/Kconfig | 5 ++ arch/arm/mach-mvebu/Makefile | 3 ++ arch/arm/mach-mvebu/cpu.c| 4 ++ arch/arm/mach-mvebu/include/mach/soc.h | 2 + arch/arm/mach-mvebu/spl.c| 5 ++ board/solidrun/clearfog/README | 6 +++ common/spl/Kconfig | 14 ++ common/spl/spl_sata.c| 49 ++-- include/configs/clearfog.h | 2 +- 10 files changed, 94 insertions(+), 4 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/9] spl: sata: add default partition and image name
Add sensible defaults for the FAT partition selection and the main U-Boot image file name. This allows spl_sata to build when the board headers does not select them explicitly. Signed-off-by: Baruch Siach --- common/spl/spl_sata.c | 8 1 file changed, 8 insertions(+) diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c index adfce1d527f6..b08efc841903 100644 --- a/common/spl/spl_sata.c +++ b/common/spl/spl_sata.c @@ -17,6 +17,14 @@ #include #include +#ifndef CONFIG_SYS_SATA_FAT_BOOT_PARTITION +#define CONFIG_SYS_SATA_FAT_BOOT_PARTITION 1 +#endif + +#ifndef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" +#endif + static int spl_sata_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) { -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/9] arm: mvebu: fix ahci mbus config in SPL
SPL does not initialize mbus_dram_info. Don't change the ahci mbus settings of the ROM. This allows the ahci to work in SPL. Signed-off-by: Baruch Siach --- arch/arm/mach-mvebu/cpu.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index f09e7b10e935..f4b7a4fa8010 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -542,6 +542,10 @@ static void ahci_mvebu_mbus_config(void __iomem *base) const struct mbus_dram_target_info *dram; int i; + /* mbus is not initialized in SPL; keep the ROM settings */ + if (IS_ENABLED(CONFIG_SPL_BUILD)) + return; + dram = mvebu_mbus_dram_info(); for (i = 0; i < 4; i++) { -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/9] spl: sata: fix build with DM_SCSI
The init_sata() routine is only present when DM_SCSI is not enabled. Don't call init_sata() when DM_SCSI is enabled. The code will fall back to scsi_scan() in this case. Signed-off-by: Baruch Siach --- common/spl/spl_sata.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c index b08efc841903..2fb46108a512 100644 --- a/common/spl/spl_sata.c +++ b/common/spl/spl_sata.c @@ -28,10 +28,12 @@ static int spl_sata_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) { - int err; + int err = 0; struct blk_desc *stor_dev; +#if !defined(CONFIG_DM_SCSI) && !defined(CONFIG_AHCI) err = init_sata(CONFIG_SPL_SATA_BOOT_DEVICE); +#endif if (err) { #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT printf("spl: sata init failed: err - %d\n", err); -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/9] spl: sata: don't force FS_FAT support
Allow the code to build when FS_FAT is not enabled, and thus spl_load_image_fat() is not provided. A subsequent patch should add alternative raw access U-Boot main image load method. Signed-off-by: Baruch Siach --- common/spl/spl_sata.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c index 2fb46108a512..f0af9f38d19f 100644 --- a/common/spl/spl_sata.c +++ b/common/spl/spl_sata.c @@ -53,9 +53,13 @@ static int spl_sata_load_image(struct spl_image_info *spl_image, CONFIG_SYS_SATA_FAT_BOOT_PARTITION)) #endif { - err = spl_load_image_fat(spl_image, stor_dev, + err = -ENOSYS; + + if (IS_ENABLED(CONFIG_SPL_FS_FAT)) { + err = spl_load_image_fat(spl_image, stor_dev, CONFIG_SYS_SATA_FAT_BOOT_PARTITION, - CONFIG_SPL_FS_LOAD_PAYLOAD_NAME); + CONFIG_SPL_FS_LOAD_PAYLOAD_NAME); + } } if (err) { puts("Error loading sata device\n"); -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/9] spl: sata: support U-Boot load from raw sata disk
Support load of the U-Boot image from raw SATA disk sector. This is equivalent to load from MMC raw sector. Signed-off-by: Baruch Siach --- common/spl/Kconfig| 14 ++ common/spl/spl_sata.c | 29 + 2 files changed, 43 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index c7cd34449a52..a90c6adbf68b 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -733,6 +733,20 @@ config SPL_SATA_SUPPORT expense and power consumption. This enables loading from SATA using a configured device. +config SPL_SATA_RAW_U_BOOT_USE_SECTOR + bool "SATA raw mode: by sector" + depends on SPL_SATA_SUPPORT + help + Use sector number for specifying U-Boot location on SATA disk in + raw mode. + +config SPL_SATA_RAW_U_BOOT_SECTOR + hex "Sector on the SATA disk to load U-Boot from" + depends on SPL_SATA_RAW_U_BOOT_USE_SECTOR + help + Sector on the SATA disk to load U-Boot from, when the SATA disk is being + used in raw mode. Units: SATA disk sectors (1 sector = 512 bytes). + config SPL_SERIAL_SUPPORT bool "Support serial" select SPL_PRINTF diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c index f0af9f38d19f..3ad8a5a58035 100644 --- a/common/spl/spl_sata.c +++ b/common/spl/spl_sata.c @@ -25,6 +25,32 @@ #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" #endif +static int spl_sata_load_image_raw(struct spl_image_info *spl_image, + struct blk_desc *stor_dev, unsigned long sector) +{ + struct image_header *header; + unsigned long count; + u32 image_size_sectors; + int ret; + + header = spl_get_load_buffer(-sizeof(*header), stor_dev->blksz); + count = blk_dread(stor_dev, sector, 1, header); + if (count == 0) + return -EIO; + + ret = spl_parse_image_header(spl_image, header); + if (ret) + return ret; + + image_size_sectors = DIV_ROUND_UP(spl_image->size, stor_dev->blksz); + count = blk_dread(stor_dev, sector, image_size_sectors, + (void *)spl_image->load_addr); + if (count != image_size_sectors) + return -EIO; + + return 0; +} + static int spl_sata_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) { @@ -59,6 +85,9 @@ static int spl_sata_load_image(struct spl_image_info *spl_image, err = spl_load_image_fat(spl_image, stor_dev, CONFIG_SYS_SATA_FAT_BOOT_PARTITION, CONFIG_SPL_FS_LOAD_PAYLOAD_NAME); + } else if (IS_ENABLED(CONFIG_SPL_SATA_RAW_U_BOOT_USE_SECTOR)) { + err = spl_sata_load_image_raw(spl_image, stor_dev, + CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR); } } if (err) { -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/9] arm: mvebu: add support for boot from SATA
Add the required Kconfig and macro definitions to allow boot from SATA on Armada 38x systems. Signed-off-by: Baruch Siach --- arch/arm/mach-mvebu/Kconfig| 5 + arch/arm/mach-mvebu/Makefile | 3 +++ arch/arm/mach-mvebu/include/mach/soc.h | 2 ++ arch/arm/mach-mvebu/spl.c | 5 + 4 files changed, 15 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 495c48e6c749..fdd39685b75d 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -239,6 +239,11 @@ config MVEBU_SPL_BOOT_DEVICE_MMC bool "SDIO/MMC card" select SPL_LIBDISK_SUPPORT +config MVEBU_SPL_BOOT_DEVICE_SATA + bool "SATA" + select SPL_SATA_SUPPORT + select SPL_LIBDISK_SUPPORT + config MVEBU_SPL_BOOT_DEVICE_UART bool "UART" diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index 02d3ce27ee74..8228a17972f9 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -37,6 +37,9 @@ endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),) KWB_CFG_BOOT_FROM=sdio endif +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),) + KWB_CFG_BOOT_FROM=sata +endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),) KWB_CFG_BOOT_FROM=uart endif diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index f666ee24243b..acb9257c90fe 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -159,7 +159,9 @@ #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS) #define BOOT_FROM_NAND 0x0A +#define BOOT_FROM_SATA 0x22 #define BOOT_FROM_UART 0x28 +#define BOOT_FROM_SATA_ALT 0x2A #define BOOT_FROM_UART_ALT 0x3f #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c index 530b98c1aa31..d54de5195624 100644 --- a/arch/arm/mach-mvebu/spl.c +++ b/arch/arm/mach-mvebu/spl.c @@ -59,6 +59,11 @@ static u32 get_boot_device(void) case BOOT_FROM_UART_ALT: #endif return BOOT_DEVICE_UART; +#ifdef BOOT_FROM_SATA + case BOOT_FROM_SATA: + case BOOT_FROM_SATA_ALT: + return BOOT_DEVICE_SATA; +#endif case BOOT_FROM_SPI: default: return BOOT_DEVICE_SPI; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 8/9] arm: mvebu: clearfog: set U-Boot offset for SATA boot
See the offset of U-Boot in raw SATA disk to the same value as the MMC offset. That is 0x140 sectors from the beginning of the SPL, which is 0x141 sectors from the beginning of the device (after the MBR sector). Signed-off-by: Baruch Siach --- include/configs/clearfog.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 4198ff051177..15c402b542e9 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -85,7 +85,7 @@ /* SPL related SPI defines */ #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 #define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_SPI_U_BOOT_OFFS -#elif defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC) +#elif defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC) || defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA) /* SPL related MMC defines */ #define CONFIG_SYS_MMC_U_BOOT_OFFS (160 << 10) #define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_MMC_U_BOOT_OFFS -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/9] ARM: dts: clearfog: enable SATA in SPL
Enable SATA peripherals in SPL to allow boot from SATA. Signed-off-by: Baruch Siach --- arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi index a12694e17103..cf6c08881b18 100644 --- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi +++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi @@ -11,3 +11,11 @@ &sdhci { u-boot,dm-spl; }; + +&ahci0 { + u-boot,dm-spl; +}; + +&ahci1 { + u-boot,dm-spl; +}; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/9] arm: mvebu: clearfog: enable SATA in SPL
Enable SATA peripherals in SPL to allow boot from SATA. Signed-off-by: Baruch Siach --- arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi index a12694e17103..cf6c08881b18 100644 --- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi +++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi @@ -11,3 +11,11 @@ &sdhci { u-boot,dm-spl; }; + +&ahci0 { + u-boot,dm-spl; +}; + +&ahci1 { + u-boot,dm-spl; +}; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/9] ARM: mvebu: add support for boot from SATA
Add the required Kconfig and macro definitions to allow boot from SATA on Armada 38x systems. Signed-off-by: Baruch Siach --- arch/arm/mach-mvebu/Kconfig| 5 + arch/arm/mach-mvebu/Makefile | 3 +++ arch/arm/mach-mvebu/include/mach/soc.h | 2 ++ arch/arm/mach-mvebu/spl.c | 5 + 4 files changed, 15 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 495c48e6c749..fdd39685b75d 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -239,6 +239,11 @@ config MVEBU_SPL_BOOT_DEVICE_MMC bool "SDIO/MMC card" select SPL_LIBDISK_SUPPORT +config MVEBU_SPL_BOOT_DEVICE_SATA + bool "SATA" + select SPL_SATA_SUPPORT + select SPL_LIBDISK_SUPPORT + config MVEBU_SPL_BOOT_DEVICE_UART bool "UART" diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index 02d3ce27ee74..8228a17972f9 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -37,6 +37,9 @@ endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),) KWB_CFG_BOOT_FROM=sdio endif +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),) + KWB_CFG_BOOT_FROM=sata +endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),) KWB_CFG_BOOT_FROM=uart endif diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index f666ee24243b..acb9257c90fe 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -159,7 +159,9 @@ #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS) #define BOOT_FROM_NAND 0x0A +#define BOOT_FROM_SATA 0x22 #define BOOT_FROM_UART 0x28 +#define BOOT_FROM_SATA_ALT 0x2A #define BOOT_FROM_UART_ALT 0x3f #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c index 530b98c1aa31..d54de5195624 100644 --- a/arch/arm/mach-mvebu/spl.c +++ b/arch/arm/mach-mvebu/spl.c @@ -59,6 +59,11 @@ static u32 get_boot_device(void) case BOOT_FROM_UART_ALT: #endif return BOOT_DEVICE_UART; +#ifdef BOOT_FROM_SATA + case BOOT_FROM_SATA: + case BOOT_FROM_SATA_ALT: + return BOOT_DEVICE_SATA; +#endif case BOOT_FROM_SPI: default: return BOOT_DEVICE_SPI; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate
On Thu, 16 May 2019 09:58:17 + Peng Fan wrote: > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > clk_fixed_rate > > > > On Thu, 9 May 2019 01:13:15 + > > Peng Fan wrote: > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > clk_fixed_rate > > > > > > > > On Wed, 8 May 2019 07:45:39 + > > > > Peng Fan wrote: > > > > > > > > > > -Original Message- > > > > > > From: Lukasz Majewski [mailto:lu...@denx.de] > > > > > > Sent: 2019年5月8日 15:40 > > > > > > To: Peng Fan > > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx > > > > > > ; s...@chromium.org; > > > > ja...@amarulasolutions.com; > > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > > > clk_fixed_rate > > > > > > > > > > > > On Wed, 8 May 2019 06:51:46 + Peng Fan > > > > > > wrote: > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Lukasz Majewski [mailto:lu...@denx.de] > > > > > > > > Sent: 2019年5月8日 14:46 > > > > > > > > To: Peng Fan > > > > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx > > > > > > > > ; s...@chromium.org; > > > > > > ja...@amarulasolutions.com; > > > > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com > > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export > > > > > > > > clk_fixed_rate > > > > > > > > > > > > > > > > On Tue, 7 May 2019 13:27:45 + Peng Fan > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: > > > > > > > > > > export clk_fixed_rate > > > > > > > > > > > > > > > > > > > > Hi Peng, > > > > > > > > > > > > > > > > > > > > > Export the structure for others to use. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > --- > > > > > > > > > > > drivers/clk/clk_fixed_rate.c | 8 +--- > > > > > > > > > > > include/linux/clk-provider.h | 7 +++ > > > > > > > > > > > 2 files changed, 8 insertions(+), 7 deletions(-) > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/clk/clk_fixed_rate.c > > > > > > > > > > > b/drivers/clk/clk_fixed_rate.c index > > > > > > > > > > > 089f060a23..069e643fbc 100644 --- > > > > > > > > > > > a/drivers/clk/clk_fixed_rate.c +++ > > > > > > > > > > > b/drivers/clk/clk_fixed_rate.c @@ -6,13 +6,7 @@ > > > > > > > > > > > #include #include > > > > > > > > > > > #include - -struct clk_fixed_rate { > > > > > > > > > > > - struct clk clk; > > > > > > > > > > > - unsigned long fixed_rate; > > > > > > > > > > > -}; > > > > > > > > > > > - > > > > > > > > > > > -#define to_clk_fixed_rate(dev) ((struct > > > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +#include > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > static ulong clk_fixed_rate_get_rate(struct clk > > > > > > > > > > > *clk) { diff --git a/include/linux/clk-provider.h > > > > > > > > > > > b/include/linux/clk-provider.h index > > > > > > > > > > > 3ed0db86d2..b2bed768b6 100644 --- > > > > > > > > > > > a/include/linux/clk-provider.h +++ > > > > > > > > > > > b/include/linux/clk-provider.h @@ -112,6 +112,13 > > > > > > > > > > > @@ struct clk_fixed_factor { #define > > > > > > > > > > > to_clk_fixed_factor(_clk) container_of(_clk, > > > > > > > > > > > struct clk_fixed_factor,\ clk) > > > > > > > > > > > > > > > > > > > > > > +struct clk_fixed_rate { > > > > > > > > > > > + struct clk clk; > > > > > > > > > > > + unsigned long fixed_rate; }; > > > > > > > > > > > > > > > > > > > > I think that this struct shall stay where it was. > > > > > > > > > > Moreover, the clk-provider.h is not the API to be > > > > > > > > > > used by other parts of the clock API. > > > > > > > > > > > > > > > > > > > > The clk_fixed_rate shall be accessed via get_rate() > > > > > > > > > > only and in IMX6Q it is available in early SPL > > > > > > > > > > (parsed from dts /clocks property > > > > > > > > > > - the 24MHz OSC) > > > > > > > > > > > + > > > > > > > > > > > +#define to_clk_fixed_rate(dev) ((struct > > > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) + int > > > > > > > > > > > clk_register(struct clk *clk, const char > > > > > > > > > > > *drv_name, ulong drv_data, const char *name, > > > > > > > > > > >const char *parent_name); > > > > > > > > > > > > > > > > > > > > Please explain why iMX8MM needs such global > > > > > > > > > > export? > > > > > > > > > > > > > > > > > > In clk-imx8mm.c, first configure ARM clk to osc24M > > > > > > > > > fixed clk to change pll clock. > > > > > > > > > + /* Configure ARM to osc24M */ > > > > > > > > > + clk_get_by_id(IMX8MM_CLK_A53_SRC, &clkp); > > > > > > > > > + uclass_get_device_by_name(UCLASS_CLK, > > > > > > > > > "clock-osc-24m", > > > > > > > > &devp); > > > > > > > > > + clkp1 = &to_clk_fixed_rate(devp)->clk; > > > > > > > > > + clk_set_parent(cl
[U-Boot] [PATCH 9/9] arm: mvebu: clearfog: document boot from SATA
Document the main U-Boot image offset when booting from SATA disk on the Clearfog board. Signed-off-by: Baruch Siach --- board/solidrun/clearfog/README | 6 ++ 1 file changed, 6 insertions(+) diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README index 0b0e98de90a0..6171ce66f4f8 100644 --- a/board/solidrun/clearfog/README +++ b/board/solidrun/clearfog/README @@ -40,6 +40,12 @@ Install U-Boot on eMMC boot partition from Linux running on Clearfog: Note that the SD card is not accessible when the Clearfog SOM has eMMC. Consider initial boot from UART (see below). +Install U-Boot on SATA: +--- + +When loading the main U-Boot image from raw SATA sector, set +CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR to 0x141. + Boot selection: --- -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] ARM: mvebu: add support for boot from SATA
Hi u-boot list, Stefan, Please ignore this patch and the next. The patch series starts at the 0/9 cover letter. Sorry for the spam. baruch On Thu, May 16 2019, Baruch Siach wrote: > Add the required Kconfig and macro definitions to allow boot from SATA > on Armada 38x systems. > > Signed-off-by: Baruch Siach > --- > arch/arm/mach-mvebu/Kconfig| 5 + > arch/arm/mach-mvebu/Makefile | 3 +++ > arch/arm/mach-mvebu/include/mach/soc.h | 2 ++ > arch/arm/mach-mvebu/spl.c | 5 + > 4 files changed, 15 insertions(+) > > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig > index 495c48e6c749..fdd39685b75d 100644 > --- a/arch/arm/mach-mvebu/Kconfig > +++ b/arch/arm/mach-mvebu/Kconfig > @@ -239,6 +239,11 @@ config MVEBU_SPL_BOOT_DEVICE_MMC > bool "SDIO/MMC card" > select SPL_LIBDISK_SUPPORT > > +config MVEBU_SPL_BOOT_DEVICE_SATA > + bool "SATA" > + select SPL_SATA_SUPPORT > + select SPL_LIBDISK_SUPPORT > + > config MVEBU_SPL_BOOT_DEVICE_UART > bool "UART" > > diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile > index 02d3ce27ee74..8228a17972f9 100644 > --- a/arch/arm/mach-mvebu/Makefile > +++ b/arch/arm/mach-mvebu/Makefile > @@ -37,6 +37,9 @@ endif > ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),) > KWB_CFG_BOOT_FROM=sdio > endif > +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),) > + KWB_CFG_BOOT_FROM=sata > +endif > ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),) > KWB_CFG_BOOT_FROM=uart > endif > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h > b/arch/arm/mach-mvebu/include/mach/soc.h > index f666ee24243b..acb9257c90fe 100644 > --- a/arch/arm/mach-mvebu/include/mach/soc.h > +++ b/arch/arm/mach-mvebu/include/mach/soc.h > @@ -159,7 +159,9 @@ > #define BOOT_DEV_SEL_MASK(0x3f << BOOT_DEV_SEL_OFFS) > > #define BOOT_FROM_NAND 0x0A > +#define BOOT_FROM_SATA 0x22 > #define BOOT_FROM_UART 0x28 > +#define BOOT_FROM_SATA_ALT 0x2A > #define BOOT_FROM_UART_ALT 0x3f > #define BOOT_FROM_SPI0x32 > #define BOOT_FROM_MMC0x30 > diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c > index 530b98c1aa31..d54de5195624 100644 > --- a/arch/arm/mach-mvebu/spl.c > +++ b/arch/arm/mach-mvebu/spl.c > @@ -59,6 +59,11 @@ static u32 get_boot_device(void) > case BOOT_FROM_UART_ALT: > #endif > return BOOT_DEVICE_UART; > +#ifdef BOOT_FROM_SATA > + case BOOT_FROM_SATA: > + case BOOT_FROM_SATA_ALT: > + return BOOT_DEVICE_SATA; > +#endif > case BOOT_FROM_SPI: > default: > return BOOT_DEVICE_SPI; -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}ooO--U--Ooo{= - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
On Sat, 27 Apr 2019 at 12:03, Heinrich Schuchardt wrote: > On 4/27/19 7:31 AM, Paolo Bonzini wrote: > > > I've done porting linux's pkcs7/x509 parsers and they work well > with my UEFI secure boot patch, but I'm still looking for other > options > as well. > > * openssl > Most of existing components linked to UEFI secure boot, including > EDK2, shim and grub, reply on this library. Why not for U-Boot? > The size of U-Boot UEFI code in U-Boot is already quite big, and > so the size of openssl won't be a big issue. > * mbedTLS > which is maintained by ARM and used with Zephyr, I guess it should > have small footprint. But it currently lacks pkcs7 parser. > > Any thoughts? > >>> > >>> > >>> Paolo, Laszlo, Ard, if you could write a new secure boot implementation > >>> today, which of the options above would you pick and why so? :) > >> > >> Difficult question. Ideally you'd want a library where three aspects > met: > >> > >> - widely used (so that there is a diverse community that's interested in > >> vulnerabilities, and fixing them too) > >> > >> - easy to cross-compile for your free-standing environment (optimally > >> the upstream project would support being cross-compiled and packaged > >> stand-alone, for that free-standing environment) > >> > >> - cares about API stability > >> > >> OpenSSL is very widely used... > >> ...and that's where we can stop in the list :) > > > > It's also license-incompatible with U-Boot's GPLv2 I think. I guess > > grub can use it because GPLv3 and Apache v2 can be combined just fine. > > Reusing Linux's code seems like the best match. > > > > Paolo > > > > You could have a look at GnuTLS available at > https://gitlab.com/gnutls/gnutls/ . > > PKCS7 is supported, cf. > https://www.gnutls.org/manual/html_node/PKCS-7-API.html > > There seem to be four main contributors to GnuTLS adding two patches a day: > > https://github.com/gnutls/gnutls/graphs/contributors?from=2018-04-28&to=2019-04-27&type=a There is LibreSSL as well which is a fork of openssl. Guess that too should be fine. What would be the more preferred solution here. The relevant bits can be imported from the kernel code into u-boot, or there can be a solution with linking of ssl/tls library with u-boot. Which would be the more preferred solution. It'd be great if the maintainers can comment on this. Thanks. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] please pull u-boot-samsung master
Dear Tom, The following changes since commit 5b4b680cfe29a67171ccbe439c66374cb31faca3: Prepare v2019.07-rc2 (2019-05-15 15:58:48 -0400) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to f4b2ab97ed37ea6b202aaa951d31dab9187e3720: configs: arndale: Use appropriate driver for Asix AX88760 (2019-05-16 16:11:42 +0900) Krzysztof Kozlowski (3): arm: exynos: arndale: Remove unused CONFIG_POWER and CONFIG_POWER_I2C arm: exynos: arndale: Remove unused CONFIG_DM_I2C_COMPAT configs: arndale: Use appropriate driver for Asix AX88760 configs/arndale_defconfig | 3 +-- include/configs/arndale.h | 8 2 files changed, 1 insertion(+), 10 deletions(-) -- Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
Dear Sughosh Ganu, In message you wrote: > > There is LibreSSL as well which is a fork of openssl. Guess that too should > be fine. What would be the more preferred solution here. The relevant bits > can be imported from the kernel code into u-boot, or there can be a > solution with linking of ssl/tls library with u-boot. Which would be the > more preferred solution. It'd be great if the maintainers can comment on > this. Thanks. I'd go for the Linux kernel code. A number of issues we have here (cross compiling, code size, license compatibility, long term maintenance efforts) have already been considered there, so why should we duplicate all these efforts? And if we did, is there any clear benefit from doing this? Just my 0,02€ Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never underestimate the power of human stupidity when it comes to using technology they don't understand. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote: Hello Wolfgang, Thanks for taking the time with this > > > > There is LibreSSL as well which is a fork of openssl. Guess that too should > > be fine. What would be the more preferred solution here. The relevant bits > > can be imported from the kernel code into u-boot, or there can be a > > solution with linking of ssl/tls library with u-boot. Which would be the > > more preferred solution. It'd be great if the maintainers can comment on > > this. Thanks. > > I'd go for the Linux kernel code. A number of issues we have here > (cross compiling, code size, license compatibility, long term > maintenance efforts) have already been considered there, so why > should we duplicate all these efforts? And if we did, is there any > clear benefit from doing this? Well someone has to port the linux code in U-Boot and maintain it though. The LibreSSL proposal was made with some of these in mind. We don't expect the licence to ever change (which is compatible) and it's being maintained. I am not sure on the portability status, but i think it runs on all major architectures. I'd imagine this lifts the maintenance burden from U-Boot. On the other hand we'll rely on an external library to offer the functionality. Regards /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 2/2] pci: layerscape: Add the workaround for errata A-009460
From: Xiaowei Bao The VF_BARn_REG register's Prefetchable and Type bit fields are overwritten by a write to VF's BAR Mask register. workaround: Before writing to the VF_BARn_MASK_REG register, write 0b to the PCIE_MISC_CONTROL_1_OFF register. Signed-off-by: Xiaowei Bao --- v2: - Add the NXP copyright. drivers/pci/pcie_layerscape.c |9 + drivers/pci/pcie_layerscape.h |1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c index 8f5ebda..25c5a0c 100644 --- a/drivers/pci/pcie_layerscape.c +++ b/drivers/pci/pcie_layerscape.c @@ -446,6 +446,15 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie) if (PCI_EXT_CAP_ID(sriov) == PCI_EXT_CAP_ID_SRIOV) { pcie->sriov_flag = 1; for (pf = 0; pf < PCIE_PF_NUM; pf++) { + /* +* The VF_BARn_REG register's Prefetchable and Type bit +* fields are overwritten by a write to VF's BAR Mask +* register. Before writing to the VF_BARn_MASK_REG +* register, write 0b to the PCIE_MISC_CONTROL_1_OFF +* register. +*/ + writel(0, pcie->dbi + PCIE_MISC_CONTROL_1_OFF); + if (pcie->cfg2_flag) { for (vf = 0; vf <= PCIE_VF_NUM; vf++) { ctrl_writel(pcie, diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h index eb910ba..c6f1cb2 100644 --- a/drivers/pci/pcie_layerscape.h +++ b/drivers/pci/pcie_layerscape.h @@ -94,6 +94,7 @@ #define PCIE_BAR4_SIZE SZ_1M /* 1M */ #define PCIE_SRIOV_VFBAR0 0x19C +#define PCIE_MISC_CONTROL_1_OFF0x8BC #define PCIE_CTRL1_FUNC_NUM(pf)(pf << 20) #define PCIE_MASK_OFFSET(flag, pf) ((flag) ? 0 : (0x1000 + 0x2 * (pf))) -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode
From: Xiaowei Bao Signed-off-by: hongbo.wang Signed-off-by: Minghuan Lian Signed-off-by: Xiaowei Bao --- v2: - Add the NXP copyright and make the function readability. drivers/pci/pcie_layerscape.c | 117 +++-- drivers/pci/pcie_layerscape.h | 19 +-- 2 files changed, 91 insertions(+), 45 deletions(-) diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c index db1375a..8f5ebda 100644 --- a/drivers/pci/pcie_layerscape.c +++ b/drivers/pci/pcie_layerscape.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright 2017 NXP + * Copyright 2017, 2019 NXP * Copyright 2014-2015 Freescale Semiconductor, Inc. * Layerscape PCIe driver */ @@ -105,13 +105,14 @@ static void ls_pcie_atu_outbound_set(struct ls_pcie *pcie, int idx, int type, } /* Use bar match mode and MEM type as default */ -static void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, int idx, -int bar, u64 phys) +static void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, int idx, + int bar, u64 phys) { dbi_writel(pcie, PCIE_ATU_REGION_INBOUND | idx, PCIE_ATU_VIEWPORT); dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_TARGET); dbi_writel(pcie, phys >> 32, PCIE_ATU_UPPER_TARGET); - dbi_writel(pcie, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1); + dbi_writel(pcie, PCIE_ATU_TYPE_MEM | PCIE_CTRL1_FUNC_NUM(pf), + PCIE_ATU_CR1); dbi_writel(pcie, PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE | PCIE_ATU_BAR_NUM(bar), PCIE_ATU_CR2); } @@ -341,50 +342,61 @@ static void ls_pcie_setup_ctrl(struct ls_pcie *pcie) ls_pcie_disable_bars(pcie); } -static void ls_pcie_ep_setup_atu(struct ls_pcie *pcie) +static void ls_pcie_ep_setup_atu(struct ls_pcie *pcie, u32 pf) { - u64 phys = CONFIG_SYS_PCI_EP_MEMORY_BASE; + pci_size_t atu_size = CONFIG_SYS_PCI_MEMORY_SIZE; + u64 phys = 0; + phys = CONFIG_SYS_PCI_EP_MEMORY_BASE + pf * SZ_2M; + + phys = ALIGN(phys, PCIE_BAR0_SIZE); /* ATU 0 : INBOUND : map BAR0 */ - ls_pcie_atu_inbound_set(pcie, 0, 0, phys); + ls_pcie_atu_inbound_set(pcie, pf, 0 + pf * BAR_NUM, 0, phys); /* ATU 1 : INBOUND : map BAR1 */ - phys += PCIE_BAR1_SIZE; - ls_pcie_atu_inbound_set(pcie, 1, 1, phys); + phys = ALIGN(phys + PCIE_BAR0_SIZE, PCIE_BAR1_SIZE); + ls_pcie_atu_inbound_set(pcie, pf, 1 + pf * BAR_NUM, 1, phys); /* ATU 2 : INBOUND : map BAR2 */ - phys += PCIE_BAR2_SIZE; - ls_pcie_atu_inbound_set(pcie, 2, 2, phys); - /* ATU 3 : INBOUND : map BAR4 */ - phys = CONFIG_SYS_PCI_EP_MEMORY_BASE + PCIE_BAR4_SIZE; - ls_pcie_atu_inbound_set(pcie, 3, 4, phys); + phys = ALIGN(phys + PCIE_BAR1_SIZE, PCIE_BAR2_SIZE); + ls_pcie_atu_inbound_set(pcie, pf, 2 + pf * BAR_NUM, 2, phys); + /* ATU 3 : INBOUND : map BAR2 */ + phys = ALIGN(phys + PCIE_BAR2_SIZE, PCIE_BAR2_SIZE); + ls_pcie_atu_inbound_set(pcie, pf, 3 + pf * BAR_NUM, 4, phys); /* ATU 0 : OUTBOUND : map MEM */ - ls_pcie_atu_outbound_set(pcie, 0, -PCIE_ATU_TYPE_MEM, -pcie->cfg_res.start, -0, -CONFIG_SYS_PCI_MEMORY_SIZE); + ls_pcie_atu_outbound_set(pcie, PCIE_ATU_REGION_INDEX0, +PCIE_ATU_TYPE_MEM, (u64)pcie->cfg_res.start, +0, atu_size); + + /* ATU 1 : OUTBOUND : map MEM */ + ls_pcie_atu_outbound_set(pcie, PCIE_ATU_REGION_INDEX1, +PCIE_ATU_TYPE_MEM, (u64)pcie->cfg_res.start ++ atu_size, atu_size, atu_size); } /* BAR0 and BAR1 are 32bit BAR2 and BAR4 are 64bit */ static void ls_pcie_ep_setup_bar(void *bar_base, int bar, u32 size) { + u32 mask; + /* The least inbound window is 4KiB */ - if (size < 4 * 1024) - return; + if (size < SZ_4K) + mask = 0; + else + mask = size - 1; switch (bar) { case 0: - writel(size - 1, bar_base + PCI_BASE_ADDRESS_0); + writel(mask, bar_base + PCI_BASE_ADDRESS_0); break; case 1: - writel(size - 1, bar_base + PCI_BASE_ADDRESS_1); + writel(mask, bar_base + PCI_BASE_ADDRESS_1); break; case 2: - writel(size - 1, bar_base + PCI_BASE_ADDRESS_2); + writel(mask, bar_base + PCI_BASE_ADDRESS_2); writel(0, bar_base + PCI_BASE_ADDRESS_3); break; case 4: - writel(size - 1, bar_base + PCI_BASE_ADDRESS_4); + writel(mask, bar_base + PCI_BASE_ADDRESS_4); writel(0, bar_base + PCI_BASE_ADDRESS_5); break; default:
Re: [U-Boot] RSA in U-Boot
On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote: > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote: > Hello Wolfgang, > > Thanks for taking the time with this > > > > > > There is LibreSSL as well which is a fork of openssl. Guess that too > > > should > > > be fine. What would be the more preferred solution here. The relevant bits > > > can be imported from the kernel code into u-boot, or there can be a > > > solution with linking of ssl/tls library with u-boot. Which would be the > > > more preferred solution. It'd be great if the maintainers can comment on > > > this. Thanks. > > > > I'd go for the Linux kernel code. A number of issues we have here > > (cross compiling, code size, license compatibility, long term > > maintenance efforts) have already been considered there, so why > > should we duplicate all these efforts? And if we did, is there any > > clear benefit from doing this? > Well someone has to port the linux code in U-Boot and maintain it though. > > The LibreSSL proposal was made with some of these in mind. > We don't expect the licence to ever change (which is compatible) > and it's being maintained. > I am not sure on the portability status, but i think it runs on all major > architectures. > > I'd imagine this lifts the maintenance burden from U-Boot. On the other > hand we'll rely on an external library to offer the functionality. I don't see how using LibreSSL instead of Linux kernel code would have a lesser maintenance burden, sorry. If anything, given the number of parts of the code we have today that come from the Linux kernel, adding one more to the "keep in sync, or at least port bugfixes" list is less than "add a new external project to keep an eye on". -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
Hi Tom, > > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote: > > Hello Wolfgang, > > > > Thanks for taking the time with this > > > > > > > > There is LibreSSL as well which is a fork of openssl. Guess that too > > > > should > > > > be fine. What would be the more preferred solution here. The relevant > > > > bits > > > > can be imported from the kernel code into u-boot, or there can be a > > > > solution with linking of ssl/tls library with u-boot. Which would be the > > > > more preferred solution. It'd be great if the maintainers can comment on > > > > this. Thanks. > > > > > > I'd go for the Linux kernel code. A number of issues we have here > > > (cross compiling, code size, license compatibility, long term > > > maintenance efforts) have already been considered there, so why > > > should we duplicate all these efforts? And if we did, is there any > > > clear benefit from doing this? > > Well someone has to port the linux code in U-Boot and maintain it though. > > > > The LibreSSL proposal was made with some of these in mind. > > We don't expect the licence to ever change (which is compatible) > > and it's being maintained. > > I am not sure on the portability status, but i think it runs on all major > > architectures. > > > > I'd imagine this lifts the maintenance burden from U-Boot. On the other > > hand we'll rely on an external library to offer the functionality. > > I don't see how using LibreSSL instead of Linux kernel code would have a > lesser maintenance burden, sorry. If anything, given the number of > parts of the code we have today that come from the Linux kernel, adding > one more to the "keep in sync, or at least port bugfixes" list is less > than "add a new external project to keep an eye on". > Right then we know what we have to do. Kernel code it is. Thanks a lot /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sysreset: switch to using SYSRESET_POWER_OFF for poweroff
Hi, On Thu, May 16, 2019 at 7:44 AM Patrick DELAUNAY wrote: > > Hi Urja, > > > - if (type != SYSRESET_POWER) > > + if (type != SYSRESET_POWER_OFF) > > return -EPROTONOSUPPORT; > > In fact in the next part of the code, we are supporting > only SYSRESET_POWER (reset with PMIC1 switch OFF and restart) > and not SYSRESET_POWER_OFF > > because Power Cycle if RREQ_EN=1 > > I think you need to remove the update on this file for your patch and > I will modified this function is to support both mode Okay I will drop this part, but just to confirm... this means that currently you have a configuration where using the poweroff command causes a power-cycle? Neat. -- Urja Rannikko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass
Hi, On Tue, May 14, 2019 at 4:07 PM Patrice CHOTARD wrote: > > Hi Urja > > This patch doesn't compile using the stm32mp15_trusted_defconfig > configuration: > > ... > LD drivers/pinctrl/built-in.o > LD drivers/core/built-in.o > LD drivers/mmc/built-in.o > LD drivers/built-in.o > drivers/sysreset/built-in.o: In function `do_poweroff': > /local/home/nxp11987/projects/community/u-boot.denx/drivers/sysreset/sysreset-uclass.c:123: > multiple definition of `do_poweroff' > drivers/firmware/built-in.o:/local/home/nxp11987/projects/community/u-boot.denx/drivers/firmware/psci.c:134: > first defined here > make[1]: *** [drivers/built-in.o] Error 1 > make: *** [drivers] Error 2 > build error !! > > > I suggest you to update your patch with : > > config PMIC_STPMIC1 > bool "Enable support for STMicroelectronics STPMIC1 PMIC" > depends on DM_PMIC && DM_I2C > - select SYSRESET_CMD_POWEROFF if CMD_POWEROFF > + select SYSRESET_CMD_POWEROFF if CMD_POWEROFF && !ARM_PSCI_FW > ---help--- > The STPMIC1 PMIC provides 4 BUCKs, 6 LDOs, 1 VREF and 2 power > switches. > It is accessed via an I2C interface. The device is used with STM32MP1 > SoCs. This driver implements register read/write operations. I'll do that in v2, thanks for the test. -- Urja Rannikko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
Hi Tom, On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote: > On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote: > > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote: > > Hello Wolfgang, > > > > Thanks for taking the time with this > > > > > > > > There is LibreSSL as well which is a fork of openssl. Guess that too > > > > should > > > > be fine. What would be the more preferred solution here. The relevant > > > > bits > > > > can be imported from the kernel code into u-boot, or there can be a > > > > solution with linking of ssl/tls library with u-boot. Which would be the > > > > more preferred solution. It'd be great if the maintainers can comment on > > > > this. Thanks. > > > > > > I'd go for the Linux kernel code. A number of issues we have here > > > (cross compiling, code size, license compatibility, long term > > > maintenance efforts) have already been considered there, so why > > > should we duplicate all these efforts? And if we did, is there any > > > clear benefit from doing this? > > Well someone has to port the linux code in U-Boot and maintain it though. > > > > The LibreSSL proposal was made with some of these in mind. > > We don't expect the licence to ever change (which is compatible) > > and it's being maintained. > > I am not sure on the portability status, but i think it runs on all major > > architectures. > > > > I'd imagine this lifts the maintenance burden from U-Boot. On the other > > hand we'll rely on an external library to offer the functionality. > > I don't see how using LibreSSL instead of Linux kernel code would have a > lesser maintenance burden, sorry. If anything, given the number of > parts of the code we have today that come from the Linux kernel, adding > one more to the "keep in sync, or at least port bugfixes" list is less > than "add a new external project to keep an eye on". # I will reply on this topic in more details tomorrow. Can you give me an example of U-Boot code which comes from linux (or other projects) and is regularly synced (or updated) with the origin? Who maintains that? and how? Thanks, -Takahiro Akashi > -- > Tom > ___ > 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] [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode
Hi, On Thu, May 16, 2019 at 7:02 PM Xiaowei Bao wrote: > > From: Xiaowei Bao > > Signed-off-by: hongbo.wang > Signed-off-by: Minghuan Lian > Signed-off-by: Xiaowei Bao > --- > v2: > - Add the NXP copyright and make the function readability. > > drivers/pci/pcie_layerscape.c | 117 > +++-- > drivers/pci/pcie_layerscape.h | 19 +-- > 2 files changed, 91 insertions(+), 45 deletions(-) > Could you please support the PCIe EP mode using driver model? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v1] ls1028a: video: Add a empty video hw init for LS1028A
On Thu, May 16, 2019 at 11:57 AM Wen He wrote: > > The video driver causes a link failure when config VIDEO built-in, > > drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init' > > Adding a empty video hw init to slove the build issue, now the board > does not support display anything on U-boot. > > Signed-off-by: Wen He > --- > board/freescale/ls1028a/ls1028a.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/board/freescale/ls1028a/ls1028a.c > b/board/freescale/ls1028a/ls1028a.c > index e5de4eb70c..ece91660bf 100644 > --- a/board/freescale/ls1028a/ls1028a.c > +++ b/board/freescale/ls1028a/ls1028a.c > @@ -20,6 +20,7 @@ > #endif > #include > #include > +#include > > #include > #include > @@ -229,3 +230,8 @@ int checkboard(void) > return 0; > } > #endif > + > +void *video_hw_init(void) > +{ > + return NULL; > +} > -- Please stop adding non-DM driver support to any new platforms. We should start using DM driver. In this case, use DM_VIDEO. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
On Thu, May 16, 2019 at 08:56:40PM +0900, AKASHI Takahiro wrote: > Hi Tom, > > On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote: > > On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote: > > > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote: > > > Hello Wolfgang, > > > > > > Thanks for taking the time with this > > > > > > > > > > There is LibreSSL as well which is a fork of openssl. Guess that too > > > > > should > > > > > be fine. What would be the more preferred solution here. The relevant > > > > > bits > > > > > can be imported from the kernel code into u-boot, or there can be a > > > > > solution with linking of ssl/tls library with u-boot. Which would be > > > > > the > > > > > more preferred solution. It'd be great if the maintainers can comment > > > > > on > > > > > this. Thanks. > > > > > > > > I'd go for the Linux kernel code. A number of issues we have here > > > > (cross compiling, code size, license compatibility, long term > > > > maintenance efforts) have already been considered there, so why > > > > should we duplicate all these efforts? And if we did, is there any > > > > clear benefit from doing this? > > > Well someone has to port the linux code in U-Boot and maintain it though. > > > > > > The LibreSSL proposal was made with some of these in mind. > > > We don't expect the licence to ever change (which is compatible) > > > and it's being maintained. > > > I am not sure on the portability status, but i think it runs on all major > > > architectures. > > > > > > I'd imagine this lifts the maintenance burden from U-Boot. On the other > > > hand we'll rely on an external library to offer the functionality. > > > > I don't see how using LibreSSL instead of Linux kernel code would have a > > lesser maintenance burden, sorry. If anything, given the number of > > parts of the code we have today that come from the Linux kernel, adding > > one more to the "keep in sync, or at least port bugfixes" list is less > > than "add a new external project to keep an eye on". > > # I will reply on this topic in more details tomorrow. > > Can you give me an example of U-Boot code which comes from linux (or > other projects) and is regularly synced (or updated) with the origin? > Who maintains that? and how? The device trees are one example. Kbuild is another. ubifs too. We just added lib/zstd :) -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v3] armv8: ls1028a: Add NXP LS1028A SoC support
Hi, On Wed, Apr 10, 2019 at 4:50 PM Yuantian Tang wrote: > > Ls1028a Soc is based on Layerscape Chassis Generation 3.2 > architecture with features: > 2 ARM v8 Cortex-A72 cores, CCI400, SEC, DDR3L/4, LCD, GPU, TSN > ENETC, 2 USB 3.0, 2 eSDHC, 2 FlexCAN, 2 SPI, SATA, 8 I2C controllers, > 6 LPUARTs, GPIO, SAI, qDMA, eDMA, GIC, TMU etc. > > Signed-off-by: Sudhanshu Gupta > Signed-off-by: Rai Harninder > Signed-off-by: Rajesh Bhagat > Signed-off-by: Bhaskar Upadhaya > Signed-off-by: Tang Yuantian > --- > v3: > -- fix some issues > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 39 ++- > arch/arm/cpu/armv8/fsl-layerscape/Makefile | 4 + > arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 3 + > arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc | 51 > arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c | 73 ++ > arch/arm/dts/fsl-ls1028a.dtsi | 280 > + > arch/arm/include/asm/arch-fsl-layerscape/config.h | 61 + > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 9 + > arch/arm/include/asm/arch-fsl-layerscape/soc.h | 1 + > .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 2 +- > 10 files changed, 521 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c > create mode 100644 arch/arm/dts/fsl-ls1028a.dtsi > I really would like to see complete DM driver support on this new platform. Please consider converting appropriate codes to driver model. If there is no proper uclass model, please propose one and discuss it on the list. I see the existing NXP PowerPC support is stuck in such a situation that lots of codes are still non-DM and we are getting close to the DM deadline. I don't want to see such happens again in the NXP ARM support. Thanks! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v2] board: ls1028a: Add an empty video hw init function
On Thu, May 16, 2019 at 2:48 PM Wen He wrote: > > The video driver causes a link failure when config VIDEO built-in, > > drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init' > > Adding an empty video hw init to slove the build issue, now the board > does not support display anything on U-boot. > > Signed-off-by: Wen He > --- > board/freescale/ls1028a/ls1028a.c | 6 ++ > 1 file changed, 6 insertions(+) > I should have commented in the v2 patch here. Sorry for the duplication. Please stop adding non-DM driver support to any new platforms. We should start using DM driver. In this case, use DM_VIDEO. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
Dear Akashi Takahiro, In message <20190516115636.GA8052@fireball> you wrote: > > Can you give me an example of U-Boot code which comes from linux (or > other projects) and is regularly synced (or updated) with the origin? > Who maintains that? and how? Comes from Linux: a ton... Kconfig, Linker Script, MTD, UBI, UBIFS, ext2/3/4, jffs2, libfdt, many drivers, network stack, reiserfs, just to name a few. Regularly synced: None. Usually this only happens in irregular intervals, if incompatibilities or bugs (that have been fixed in more recent code) show up Who: usually the responsible custodians How: ideally thius should be a straightforward, though largely manual process. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Eureka! -- Archimedes ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Enable spl relocation on arm
Some times we want to relocate spl code to dram after dram initialization or relocate spl code to a high memory to avoid code overid. For example on Rockchip armv8 platform, we run with boot flow TPL->SPL->ATF->U-Boot. TPL run in sram and is responsible for dram initialization. SPL run from the start address of dram and is responsible for loading ATF and U-Boot. The case here is that the ATF load address is from 64KB of dram, which overlaps with spl code itself. So we want to relocate spl itself to high memory to aovid this. When look the code, I found powerpc use the spl relocation. So I dicide share the config with powerpc. Changes in v2: - Move Kconfig modification to PATCH 1/3 - Add more detial commit message Andy Yan (3): powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig spl: add relocation support arm: add spl relocation support for arm arch/arm/config.mk | 6 +++ arch/arm/cpu/armv8/start.S | 4 ++ arch/arm/cpu/armv8/u-boot-spl.lds| 17 ++ arch/arm/lib/Makefile| 2 +- arch/arm/lib/crt0_64.S | 3 +- common/spl/Kconfig | 13 + common/spl/spl.c | 55 configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 2 + configs/BSC9131RDB_NAND_defconfig| 2 + configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 2 + configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 2 + configs/C29XPCIE_NAND_defconfig | 2 + configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 + configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 2 + configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 + configs/P1010RDB-PA_NAND_defconfig | 2 + configs/P1010RDB-PA_SDCARD_defconfig | 2 + configs/P1010RDB-PA_SPIFLASH_defconfig | 2 + configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 + configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 2 + configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 + configs/P1010RDB-PB_NAND_defconfig | 2 + configs/P1010RDB-PB_SDCARD_defconfig | 2 + configs/P1010RDB-PB_SPIFLASH_defconfig | 2 + configs/P1020MBG-PC_36BIT_SDCARD_defconfig | 2 + configs/P1020MBG-PC_SDCARD_defconfig | 2 + configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 + configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 + configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + configs/P1020RDB-PC_NAND_defconfig | 2 + configs/P1020RDB-PC_SDCARD_defconfig | 2 + configs/P1020RDB-PC_SPIFLASH_defconfig | 2 + configs/P1020RDB-PD_NAND_defconfig | 2 + configs/P1020RDB-PD_SDCARD_defconfig | 2 + configs/P1020RDB-PD_SPIFLASH_defconfig | 2 + configs/P1020UTM-PC_36BIT_SDCARD_defconfig | 2 + configs/P1020UTM-PC_SDCARD_defconfig | 2 + configs/P1021RDB-PC_36BIT_NAND_defconfig | 2 + configs/P1021RDB-PC_36BIT_SDCARD_defconfig | 2 + configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig | 2 + configs/P1021RDB-PC_NAND_defconfig | 2 + configs/P1021RDB-PC_SDCARD_defconfig | 2 + configs/P1021RDB-PC_SPIFLASH_defconfig | 2 + configs/P1022DS_36BIT_NAND_defconfig | 2 + configs/P1022DS_36BIT_SDCARD_defconfig | 2 + configs/P1022DS_36BIT_SPIFLASH_defconfig | 2 + configs/P1022DS_NAND_defconfig | 2 + configs/P1022DS_SDCARD_defconfig | 2 + configs/P1022DS_SPIFLASH_defconfig | 2 + configs/P1024RDB_NAND_defconfig | 2 + configs/P1024RDB_SDCARD_defconfig| 2 + configs/P1024RDB_SPIFLASH_defconfig | 2 + configs/P1025RDB_NAND_defconfig | 2 + configs/P1025RDB_SDCARD_defconfig| 2 + configs/P1025RDB_SPIFLASH_defconfig | 2 + configs/P2020RDB-PC_36BIT_NAND_defconfig | 2 + configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 2 + configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + configs/P2020RDB-PC_NAND_defconfig | 2 + configs/P2020RDB-PC_SDCARD_defconfig | 2 + configs/P2020RDB-PC_SPIFLASH_defconfig | 2 + include/configs/BSC9131RDB.h | 1 - include/configs/BSC9132QDS.h | 1 - include/configs/C29XPCIE.h | 3 -- include/configs/P1010RDB.h | 4 -- include/configs/P1022DS.h| 3 -- include/configs/p1_p2_rdb_pc.h | 3 -- 67 files changed, 206 insertions(+), 17 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig
Move CONFIG_SPL_RELOC_TEXT_BASE and CONFIG_SPL_SKIP_RELOCATE to Kconfig, so we can reuse it for cross other platform. Signed-off-by: Andy Yan --- Changes in v2: None common/spl/Kconfig | 13 + configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 2 ++ configs/BSC9131RDB_NAND_defconfig| 2 ++ configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 2 ++ configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 2 ++ configs/C29XPCIE_NAND_defconfig | 2 ++ configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 ++ configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 2 ++ configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1010RDB-PA_NAND_defconfig | 2 ++ configs/P1010RDB-PA_SDCARD_defconfig | 2 ++ configs/P1010RDB-PA_SPIFLASH_defconfig | 2 ++ configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 ++ configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 2 ++ configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1010RDB-PB_NAND_defconfig | 2 ++ configs/P1010RDB-PB_SDCARD_defconfig | 2 ++ configs/P1010RDB-PB_SPIFLASH_defconfig | 2 ++ configs/P1020MBG-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1020MBG-PC_SDCARD_defconfig | 2 ++ configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 ++ configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1020RDB-PC_NAND_defconfig | 2 ++ configs/P1020RDB-PC_SDCARD_defconfig | 2 ++ configs/P1020RDB-PC_SPIFLASH_defconfig | 2 ++ configs/P1020RDB-PD_NAND_defconfig | 2 ++ configs/P1020RDB-PD_SDCARD_defconfig | 2 ++ configs/P1020RDB-PD_SPIFLASH_defconfig | 2 ++ configs/P1020UTM-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1020UTM-PC_SDCARD_defconfig | 2 ++ configs/P1021RDB-PC_36BIT_NAND_defconfig | 2 ++ configs/P1021RDB-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1021RDB-PC_NAND_defconfig | 2 ++ configs/P1021RDB-PC_SDCARD_defconfig | 2 ++ configs/P1021RDB-PC_SPIFLASH_defconfig | 2 ++ configs/P1022DS_36BIT_NAND_defconfig | 2 ++ configs/P1022DS_36BIT_SDCARD_defconfig | 2 ++ configs/P1022DS_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1022DS_NAND_defconfig | 2 ++ configs/P1022DS_SDCARD_defconfig | 2 ++ configs/P1022DS_SPIFLASH_defconfig | 2 ++ configs/P1024RDB_NAND_defconfig | 2 ++ configs/P1024RDB_SDCARD_defconfig| 2 ++ configs/P1024RDB_SPIFLASH_defconfig | 2 ++ configs/P1025RDB_NAND_defconfig | 2 ++ configs/P1025RDB_SDCARD_defconfig| 2 ++ configs/P1025RDB_SPIFLASH_defconfig | 2 ++ configs/P2020RDB-PC_36BIT_NAND_defconfig | 2 ++ configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 2 ++ configs/P2020RDB-PC_NAND_defconfig | 2 ++ configs/P2020RDB-PC_SDCARD_defconfig | 2 ++ configs/P2020RDB-PC_SPIFLASH_defconfig | 2 ++ include/configs/BSC9131RDB.h | 1 - include/configs/BSC9132QDS.h | 1 - include/configs/C29XPCIE.h | 3 --- include/configs/P1010RDB.h | 4 include/configs/P1022DS.h| 3 --- include/configs/p1_p2_rdb_pc.h | 3 --- 61 files changed, 121 insertions(+), 15 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 206c24076d..52669ce1f8 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -189,6 +189,19 @@ config SPL_DISPLAY_PRINT banner ("U-Boot SPL ..."). This function should be provided by the board. +config SPL_SKIP_RELOCATE + bool "Skip code relocation in SPL" + default y + help + The SPL code will be relocated to a high memory if you say no here. + Only ARM64 and PowerPC SPL support relocate now. + +config SPL_RELOC_TEXT_BASE + hex "Address the SPL relocate to" + depends on !SPL_SKIP_RELOCATE + help + The address on the ram where the SPL relocate to. + config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR bool "MMC raw mode: by sector" default y if ARCH_SUNXI || ARCH_DAVINCI || ARCH_UNIPHIER || \ diff --git a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig index 55906fa0ff..81aaff4585 100644 --- a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig +++ b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig @@ -13,6 +13,8 @@ CONFIG_BOOTDELAY=10 CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_MISC_INIT_R is not set # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0x10 CONFIG_SPL_NAND_SUPPORT=y CONFIG_HUSH_PARSER=y # CONFIG_CMD_FLASH is not set diff --git a/configs/BSC9131RDB_NAND_defconfig b/configs/BSC9131RDB_NAND_d
[U-Boot] [PATCH v2 2/3] spl: add relocation support
Some times we want to relocate spl code to dram after dram initialization or relocate spl code to a high memory to avoid code overid. For example on Rockchip armv8 platform, we run with boot flow TPL->SPL->ATF->U-Boot. TPL run in sram and is responsible for dram initialization. SPL run from the start address of dram and is responsible for loading ATF and U-Boot. The case here is that the ATF load address is from 64KB of dram, which overlaps with spl code itself. So we want to relocate spl itself to high memory to aovid this. Signed-off-by: Andy Yan --- Changes in v2: - Move Kconfig modification to PATCH 1/3 common/spl/spl.c | 55 1 file changed, 55 insertions(+) diff --git a/common/spl/spl.c b/common/spl/spl.c index 88d4b8a9bf..affb65ccbd 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) return 0; } +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) +static void spl_setup_relocate(void) +{ + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; + gd->new_gd = (gd_t *)gd; + gd->start_addr_sp = gd->relocaddr; + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); + + gd->start_addr_sp -= gd->fdt_size; + gd->new_fdt = (void *)gd->start_addr_sp; + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); + gd->fdt_blob = gd->new_fdt; + + gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start; +} +#else +static void spl_setup_relocate(void) +{ + +} +#endif + void spl_set_bd(void) { /* @@ -460,6 +483,8 @@ int spl_early_init(void) return ret; gd->flags |= GD_FLG_SPL_EARLY_INIT; + spl_setup_relocate(); + return 0; } @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info *spl_image, return -ENODEV; } +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) +static int spl_initr_dm(void) +{ + int ret; + + /* Save the pre-reloc driver model and start a new one */ + gd->dm_root_f = gd->dm_root; + gd->dm_root = NULL; + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); + ret = dm_init_and_scan(false); + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); + if (ret) + return ret; + +#if defined(CONFIG_TIMER) + gd->timer = NULL; +#endif + serial_init(); + + return 0; +} +#else +static int spl_initr_dm(void) +{ + return 0; +} +#endif + void board_init_r(gd_t *dummy1, ulong dummy2) { u32 spl_boot_list[] = { @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); + spl_initr_dm(); + spl_set_bd(); #if defined(CONFIG_SYS_SPL_MALLOC_START) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] arm: add spl relocation support for arm
Some times we want to relocate spl code to dram after dram initialization or relocate spl code to a high memory to avoid code overid. For example on Rockchip armv8 platform, we run with boot flow TPL->SPL->ATF->U-Boot. TPL run in sram and is responsible for dram initialization. SPL run from the start address of dram and is responsible for loading ATF and U-Boot. The case here is that the ATF load address is from 64KB of dram, which overlaps with spl code itself. So we want to relocate spl itself to high memory to aovid this. Signed-off-by: Andy Yan --- Changes in v2: - Add more detial commit message arch/arm/config.mk| 6 ++ arch/arm/cpu/armv8/start.S| 4 arch/arm/cpu/armv8/u-boot-spl.lds | 17 + arch/arm/lib/Makefile | 2 +- arch/arm/lib/crt0_64.S| 3 ++- 5 files changed, 30 insertions(+), 2 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f25603109e..7f6ad89601 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -102,6 +102,12 @@ endif # needed for relocation LDFLAGS_u-boot += -pie +ifndef CONFIG_SPL_SKIP_RELOCATE +LDFLAGS_u-boot-spl = -pie +else +SPL_LDFLAGS_u-boot-spl = +endif + # # FIXME: binutils versions < 2.22 have a bug in the assembler where # branches to weak symbols can be incorrectly optimized in thumb mode diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index fe52166e28..a7dad3cd69 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -35,7 +35,11 @@ _start: .globl _TEXT_BASE _TEXT_BASE: +#if defined(CONFIG_SPL_BUILD) + .quad CONFIG_SPL_TEXT_BASE +#else .quad CONFIG_SYS_TEXT_BASE +#endif /* * These are defined in the linker script. diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds index ccbf359bd1..64102afc8b 100644 --- a/arch/arm/cpu/armv8/u-boot-spl.lds +++ b/arch/arm/cpu/armv8/u-boot-spl.lds @@ -53,6 +53,23 @@ SECTIONS *(.__end) } >.sram +#ifndef CONFIG_SPL_SKIP_RELOCATE + . = ALIGN(8); + + .rel_dyn_start : + { + *(.__rel_dyn_start) + } >.sram + + .rela.dyn : { + *(.rela*) + } >.sram + + .rel_dyn_end : + { + *(.__rel_dyn_end) + } >.sram +#endif _image_binary_end = .; .bss_start (NOLOAD) : { diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 48ee6c3c60..f27b3fb79f 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -21,7 +21,7 @@ else obj-y += setjmp.o endif -ifndef CONFIG_SPL_BUILD +ifndef CONFIG_TPL_BUILD ifdef CONFIG_ARM64 obj-y += relocate_64.o else diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index d6b632aa87..e5605fe325 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -89,7 +89,8 @@ ENTRY(_main) mov x0, #0 bl board_init_f -#if !defined(CONFIG_SPL_BUILD) +#if (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) && !defined(CONFIG_SPL_SKIP_RELOCATE)) || \ + !defined(CONFIG_SPL_BUILD) /* * Set up intermediate environment (new sp and gd) and call * relocate_code(addr_moni). Trick here is that we'll return -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] The CONFIG_DM_I2C_COMPAT option is not available
hi, Heiko Schocher Some soc related files use i2c_read, i2c_write similar function interface, if you do not use the CONFIG_DM_I2C_COMPAT option to compile, there will be a function undefined compilation error, but if you do CONFIG_DM_I2C_COMPAT=y When compiling, there will be the following warnings: = WARNING == This board uses CONFIG_DM_I2C_COMPAT. Please remove (possibly in a subsequent patch in your series) before sending patches to the mailing list. If I do ONFIG_DM_I2C_COMPAT=y, do I need to implement i2c_read, i2c_write such as the function interface definition in the i2c controller driver? But these function declarations are all from include/i2c.h, if CONFIG_DM_I2C=y, these functions are not declared. How should I be compatible with these old-style interfaces? look forward to your reply! Thanks, Chuanhua ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Avoid writing temporary asl files into the source tree
Hi Simon, On Thu, May 9, 2019 at 10:57 AM Simon Glass wrote: > > At present the iasl tool (Intel ACPI (Advanced Configuration and Power > Interface) Source Language compiler) is called in such a way that it uses > the source directory for its temporary files. > > This means we end up with these files when building x86 boards: > >board/dfi/dfi-bt700/dsdt.aml >board/dfi/dfi-bt700/dsdt.asl.tmp > > Update the code to put temporary files in the target directory instead. > > Signed-off-by: Simon Glass > --- > > scripts/Makefile.lib | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index de67677f61..6cf1382721 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -397,9 +397,10 @@ $(obj)/%_efi.so: $(obj)/%.o $(obj)/efi_crt0.o > $(obj)/efi_reloc.o $(obj)/efi_free > # --- > quiet_cmd_acpi_c_asl= ASL $< > cmd_acpi_c_asl= \ > - $(CPP) -x assembler-with-cpp -D__ASSEMBLY__ -P $(UBOOTINCLUDE) -o > $<.tmp $<; \ > - iasl -p $< -tc $<.tmp $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \ > - mv $(patsubst %.asl,%.hex,$<) $@ > + $(CPP) -x assembler-with-cpp -D__ASSEMBLY__ -P $(UBOOTINCLUDE) \ > + -o $@.tmp $< && \ With the changes here, there is no board/dfi/dfi-bt700/dsdt.asl.tmp anymore, but board/dfi/dfi-bt700/dsdt.c.tmp. This file name looks not correct as it is not a C file. I am not sure if this could confuse anyone else. Besides, 'make distclean' does not clean the 'dsdt.c.tmp'. > + iasl -p $@ -tc $@.tmp $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \ > + mv $(patsubst %.c,%.hex,$@) $@ > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: coreboot: make it possible to process unhandled tags
On Wed, Apr 17, 2019 at 8:42 PM Christian Gmeiner wrote: > > coreboot makes it possible to add own entries into coreboot's > table at a per mainboard basis. As there might be some custom > ones it makes sense to provide a way to process them. > > Signed-off-by: Christian Gmeiner > --- > arch/x86/cpu/coreboot/tables.c | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Bin Meng > diff --git a/arch/x86/cpu/coreboot/tables.c b/arch/x86/cpu/coreboot/tables.c > index bc18b710c9..a7c55c7dd1 100644 > --- a/arch/x86/cpu/coreboot/tables.c > +++ b/arch/x86/cpu/coreboot/tables.c > @@ -109,6 +109,8 @@ static void cb_parse_string(unsigned char *ptr, char > **info) > *info = (char *)((struct cb_string *)ptr)->string; > } > > +__weak void cb_parse_unhandled(u32 tag, unsigned char *ptr) {} > + nits: I would prefer to have {} in sparate lines. I can fix this when applying. > static int cb_parse_header(void *addr, int len, struct sysinfo_t *info) > { > struct cb_header *header; > @@ -211,6 +213,9 @@ static int cb_parse_header(void *addr, int len, struct > sysinfo_t *info) > case CB_TAG_VBNV: > cb_parse_vbnv(ptr, info); > break; > + default: > + cb_parse_unhandled(rec->tag, ptr); > + break; > } > > ptr += rec->size; > -- ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: coreboot: make it possible to process unhandled tags
On Thu, May 16, 2019 at 9:18 PM Bin Meng wrote: > > On Wed, Apr 17, 2019 at 8:42 PM Christian Gmeiner > wrote: > > > > coreboot makes it possible to add own entries into coreboot's > > table at a per mainboard basis. As there might be some custom > > ones it makes sense to provide a way to process them. > > > > Signed-off-by: Christian Gmeiner > > --- > > arch/x86/cpu/coreboot/tables.c | 5 + > > 1 file changed, 5 insertions(+) > > > > Reviewed-by: Bin Meng > > > diff --git a/arch/x86/cpu/coreboot/tables.c b/arch/x86/cpu/coreboot/tables.c > > index bc18b710c9..a7c55c7dd1 100644 > > --- a/arch/x86/cpu/coreboot/tables.c > > +++ b/arch/x86/cpu/coreboot/tables.c > > @@ -109,6 +109,8 @@ static void cb_parse_string(unsigned char *ptr, char > > **info) > > *info = (char *)((struct cb_string *)ptr)->string; > > } > > > > +__weak void cb_parse_unhandled(u32 tag, unsigned char *ptr) {} > > + > > nits: I would prefer to have {} in sparate lines. > > I can fix this when applying. Fixed the nits and applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/4] Kconfig: Make CMD_SPL_NAND_OFS only available when proper memory is used
This commit makes the CMD_SPL_NAND_OFS only visible when we use NAND memory. Before this change it was present when only CMD_SPL was enabled (and would stay when board with other falcon boot medium is used). Signed-off-by: Lukasz Majewski --- cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 0d36da2a5c..7bc275f135 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -327,6 +327,7 @@ config CMD_SPL config CMD_SPL_NAND_OFS hex "Offset of OS command line args for Falcon-mode NAND boot" depends on CMD_SPL + depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT) default 0 help This provides the offset of the command line arguments for Linux -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/4] Kconfig: cosmetic: Update description of CMD_SPL_NAND_OFS
The CMD_SPL_NAND_OFS description was a bit misleading, has been updated. Signed-off-by: Lukasz Majewski --- cmd/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 7bc275f135..4dec190a38 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -325,8 +325,7 @@ config CMD_SPL command. config CMD_SPL_NAND_OFS - hex "Offset of OS command line args for Falcon-mode NAND boot" - depends on CMD_SPL + hex "Offset of OS args or dtb for Falcon-mode NAND boot" depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT) default 0 help -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/4] Kconfig: Add CMD_SPL_NOR_OFS config for falcon boot argument offset
This option will provide the offset in the parallel NOR flash memory to, which the falcon boot data is stored. Signed-off-by: Lukasz Majewski --- cmd/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 4dec190a38..b4b10cce00 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -334,6 +334,14 @@ config CMD_SPL_NAND_OFS for full information about how to use this option (and also see board/gateworks/gw_ventana/README for an example). +config CMD_SPL_NOR_OFS + hex "Offset of OS args or dtb for Falcon-mode NOR boot" + depends on CMD_SPL && SPL_NOR_SUPPORT + default 0 + help + This provides the offset of the command line arguments or dtb for + Linux when booting from NOR in Falcon mode. + config CMD_SPL_WRITE_SIZE hex "Size of argument area" depends on CMD_SPL -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 4/4] doc: Update parallel NOR flash related information in README.falcon
This commit updates the doc/README.falcon regarding Falcon boot on NOR flash memories. Signed-off-by: Lukasz Majewski --- doc/README.falcon | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/README.falcon b/doc/README.falcon index 9a7f0bc235..204f4b12b6 100644 --- a/doc/README.falcon +++ b/doc/README.falcon @@ -67,6 +67,9 @@ CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was saved. +CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved. + (Please refer to MCCMON6 board's configuraiton) + CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied CONFIG_SPL_OS_BOOT Activate Falcon Mode. -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] doc: Update parallel NOR flash related information in README.falcon
On Thu, May 16, 2019 at 10:33 AM Lukasz Majewski wrote: > CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was > saved. > > +CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved. > + (Please refer to MCCMON6 board's configuraiton) Typo: configuration. Also, it is not very obvious for the reader where the MCCMON6 board configuration is located. It would be easier to explicitly mention configs/mccmon6_nor_defconfig as an example. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] Kconfig: Make CMD_SPL_NAND_OFS only available when proper memory is used
This commit makes the CMD_SPL_NAND_OFS only visible when we use NAND memory. Before this change it was present when only CMD_SPL was enabled (and would stay when board with other falcon boot medium is used). Signed-off-by: Lukasz Majewski --- Changes in v2: None cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 0d36da2a5c..7bc275f135 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -327,6 +327,7 @@ config CMD_SPL config CMD_SPL_NAND_OFS hex "Offset of OS command line args for Falcon-mode NAND boot" depends on CMD_SPL + depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT) default 0 help This provides the offset of the command line arguments for Linux -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] Kconfig: cosmetic: Update description of CMD_SPL_NAND_OFS
The CMD_SPL_NAND_OFS description was a bit misleading, has been updated. Signed-off-by: Lukasz Majewski --- Changes in v2: None cmd/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 7bc275f135..4dec190a38 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -325,8 +325,7 @@ config CMD_SPL command. config CMD_SPL_NAND_OFS - hex "Offset of OS command line args for Falcon-mode NAND boot" - depends on CMD_SPL + hex "Offset of OS args or dtb for Falcon-mode NAND boot" depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT) default 0 help -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] doc: Update parallel NOR flash related information in README.falcon
This commit updates the doc/README.falcon regarding Falcon boot on NOR flash memories. This code is used by MCCMON6 board - so for more details please refer to configs/mccmon6_nor_defconfig. Signed-off-by: Lukasz Majewski --- Changes in v2: - Fix the description - Update the comit message doc/README.falcon | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/README.falcon b/doc/README.falcon index 9a7f0bc235..713d7063a1 100644 --- a/doc/README.falcon +++ b/doc/README.falcon @@ -67,6 +67,8 @@ CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was saved. +CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved. + CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied CONFIG_SPL_OS_BOOT Activate Falcon Mode. -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] Kconfig: Add CMD_SPL_NOR_OFS config for falcon boot argument offset
This option will provide the offset in the parallel NOR flash memory to, which the falcon boot data is stored. Signed-off-by: Lukasz Majewski --- Changes in v2: None cmd/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 4dec190a38..b4b10cce00 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -334,6 +334,14 @@ config CMD_SPL_NAND_OFS for full information about how to use this option (and also see board/gateworks/gw_ventana/README for an example). +config CMD_SPL_NOR_OFS + hex "Offset of OS args or dtb for Falcon-mode NOR boot" + depends on CMD_SPL && SPL_NOR_SUPPORT + default 0 + help + This provides the offset of the command line arguments or dtb for + Linux when booting from NOR in Falcon mode. + config CMD_SPL_WRITE_SIZE hex "Size of argument area" depends on CMD_SPL -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] dm: pinctrl: Remove obsolete function pinctrl_decode_pin_config_dm().
Hi Kever, sorry for the delay. Will do within the next couple of days. Thanks, Christoph On 09.05.19 12:46, Kever Yang wrote: > Hi Christoph, > > Could you re-send this patch with re-base on top of master, > > because there is a conflict when I try to merge it. > > > Thanks, > - Kever > On 05/09/2019 11:52 AM, Simon Glass wrote: >> Hi, >> >> On Fri, 5 Apr 2019 at 05:43, Christoph Müllner >> wrote: >>> Hi Simon, >>> >>> any plans to get this merged? >> Yes, Kever should do it. >> >> - Simon >> >>> Thanks, >>> Christoph >>> On 14.02.2019, at 02:54, Simon Glass wrote: On Tue, 12 Feb 2019 at 18:29, Christoph Muellner wrote: > This reverts commit 5ff776889212c080e3d1a33634ac904405ed6845. > > As noted in the comment, the function pinctrl_decode_pin_config_dm() > only served as a temporary solution. > > Since the function has no users anymore, we can remove it again. > > Signed-off-by: Christoph Muellner > > > --- > > drivers/pinctrl/pinctrl-uclass.c | 22 -- > include/dm/pinctrl.h | 12 > 2 files changed, 34 deletions(-) Reviewed-by: Simon Glass > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fs: fat: Fix possible double free of fatbuf
fat_itr_root() allocates fatbuf so we free it on the exit path, if the function fails we should not free it, check the return value and skip freeing if the function fails. Signed-off-by: Andrew F. Davis --- fs/fat/fat.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index c5997c2173..06c8ed14bd 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -1134,11 +1134,12 @@ int fat_size(const char *filename, loff_t *size) * expected to fail if passed a directory path: */ free(fsdata.fatbuf); - fat_itr_root(itr, &fsdata); - if (!fat_itr_resolve(itr, filename, TYPE_DIR)) { + ret = fat_itr_root(itr, &fsdata); + if (ret) + goto out_free_itr; + ret = fat_itr_resolve(itr, filename, TYPE_DIR); + if (!ret) *size = 0; - ret = 0; - } goto out_free_both; } -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
Hi Tom On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote: > Hey folks, > > I'm attempting, again, to see what we need to do in order to use gcc- > 8.x > for U-Boot and ran into, again: > https://patchwork.ozlabs.org/patch/920329/ which in short is that > when > using -mcpu=xscale gcc-8.x throws an odd error: > cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch > [-Werror] > > Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale > which > suggests perhaps something broke in upstream gcc. Looking at the > kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that > leads to different failures (seen here with gcc-7.3): > CC drivers/usb/gadget/pxa25x_udc.o > {standard input}: Assembler messages: > {standard input}:779: Error: selected processor does not support `pld > [lr]' in ARM mode > {standard input}:1201: Error: selected processor does not support > `pld [r7]' in ARM mode > {standard input}:2519: Error: selected processor does not support > `pld [r3]' in ARM mode > {standard input}:2796: Error: selected processor does not support > `pld [r3]' in ARM mode > > So, what should we do about this? Is there still active interest in > supporting the PXA platforms? Thanks folks! We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips. The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM. The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again. Cheers Marcel > ___ > 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] U-Boot PXA support
On 5/16/19 4:53 PM, Marcel Ziswiler wrote: > Hi Tom > > On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote: >> Hey folks, >> >> I'm attempting, again, to see what we need to do in order to use gcc- >> 8.x >> for U-Boot and ran into, again: >> https://patchwork.ozlabs.org/patch/920329/ which in short is that >> when >> using -mcpu=xscale gcc-8.x throws an odd error: >> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch >> [-Werror] >> >> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale >> which >> suggests perhaps something broke in upstream gcc. Looking at the >> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that >> leads to different failures (seen here with gcc-7.3): >> CC drivers/usb/gadget/pxa25x_udc.o >> {standard input}: Assembler messages: >> {standard input}:779: Error: selected processor does not support `pld >> [lr]' in ARM mode >> {standard input}:1201: Error: selected processor does not support >> `pld [r7]' in ARM mode >> {standard input}:2519: Error: selected processor does not support >> `pld [r3]' in ARM mode >> {standard input}:2796: Error: selected processor does not support >> `pld [r3]' in ARM mode >> >> So, what should we do about this? Is there still active interest in >> supporting the PXA platforms? Thanks folks! > > We are actually still shipping Colibri PXA270 modules for another one > or two years I believe after which Marvell stops selling us chips. > > The strange thing is that I build U-Boot master more or less daily > without any known issues currently using the regular gcc 8.2 2019.01 > tool chain from ARM. > > The only issue is the missing DM_MMC and/or DM_USB conversion which I > started working on a long time ago but never came around properly > debugging. I may pick that one up tomorrow again. Would you like to co-maintain the PXA ? :) -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] pci: pci_mvebu: fix bus enumeration if some buses have empty slots
Hi Mario, you are right. I shall send a new patch chaning pci_init to use the _check functions after I test it. Marek On Wed, 15 May 2019 07:05:43 +0200 Mario Six wrote: > Hi Marek, > > On Tue, May 14, 2019 at 5:12 PM Marek Behún > wrote: > > > > The documentation for the uclass_next_device says this: > > > > @devp: On entry, pointer to device to lookup. On exit, returns > > pointer to the next device in the uclass if no error occurred, or > > NULL if there is no next device, or an error occurred with that > > next device. > > > > But this is useless, because if an error occured with that next > > device, the iteration stops and devices which should work won't be > > probed. > > The class_{first,next}_device_check functions do exactly what you > need: They skip the devices that won't probe and only return the ones > that do probe. > > Best regards, > > Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
On 30/04/2019 21:07, Heinrich Schuchardt wrote: > On 4/30/19 4:53 AM, Eugeniu Rosca wrote: >> The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our >> platform are always the same. Below is consistent on each cold boot: >> >> => ### interrupt autoboot >> => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >> ... >> uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2 >> => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >> ... >> uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3 >> => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >> ... >> uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4 >> => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >> ... >> uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d >> => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >> ... >> uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7 >> >> While the uuids do change on every 'gpt write' command, the values >> appear to be taken from the same pool, in the same order. >> >> As a user, I expect a trully random uuid value in the above example. >> Otherwise, system/RFS designers and OS people might assume they have >> a reliable/consistent uuid passed by the bootloader, while the truth >> is U-Boot simply lacks entropy to generate a random string. >> >> In its first attempt [1] to improve the uuid randomness, this patch >> updated the seed based on the output of get_timer(), similar to [2]. >> >> There are two problems with this approach: >> - get_timer() has a poor _ms_ resolution >> - when gen_rand_uuid() is called in a loop, get_timer() returns the >> same result, leading to the same seed being passed to srand(), >> leading to the same uuid being generated for several partitions >> with different names >> >> This second patch addresses both drawbacks. >> >> My R-Car3 testing [3] consists of running 'gpt write mmc 1 $partitions' >> in a loop for several minutes collecting 8844 randomly generated UUIDS. >> Two consecutive cold boots are concatenated in the log. As a result, >> all uuid values are unique (scripted check). >> >> Thanks to Roman, who reported the issue and provided support in fixing. >> >> [1] https://patchwork.ozlabs.org/patch/1091802/ >> [2] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() >> function") >> [3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca >> => while true; do \ >> env default -a; \ >> gpt write mmc 1 $partitions; \ >> print; done >> >> Reported-by: Roman Stratiienko >> Signed-off-by: Eugeniu Rosca > > This patch may ameliorate the situation for GUIDs a bit. But I dislike: > > - This patch is a uuid only solution to introduce time ticks as source > of entropy. > - With timer ticks you possibly introduce very little entropy. > - Our random number generator with only 32 state bits remains > sub-standard. > > This is the current situation: > > net/bootp.c uses the MAC address to seed the random number generator and > uses random numbers for defining waits. > > lib/uuid.c is using it for UUID generation. > > In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL. > Linux uses it for randomizing memory layout. iPXE needs it for secure > network connections. This requires a good random number generator with > sufficient entropy. > > We already have implemented a single hardware random number generator in > drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA). > > Many other CPUs come with a hardware random number generator. In Linux's > drivers/char/hw_random/ I found, e.g. > > - meson-rng.c (Amlogic) > - mtk-rng.c (MediaTek) > - st-rng.c (STMicroelectronics) > - imx-rng.c (Freescale) > > I think we should have a u-class for hardware RNGs as one source of entropy. > Anyone working on this already? If not I can have a look. It could be used for RPi3 as well (drivers/char/hw_random/bcm2835-rng.c in the Linux kernel). :) Regards, Matthias > I would like a random number generator with a high number of state bits > (> 127) that we initialize with hardware RNG bits and other sources of > entropy. A nice discussion of how Linux does it can be found in [1]. > > Best regards > > Heinrich > > [1] > https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf > > > >> --- >> v2: >> - Replaced get_timer(0) with get_ticks() and added rand() to seed value >> - Performed extensive testing on R-Car3 (ARMv8) >> v1: >> - https://patchwork.ozlabs.org/patch/1091802/ >> --- >> lib/uuid.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/lib/uuid.c b/lib/uuid.c >> index fa20ee39fc32..2d4d6ef7e461 100644 >> --- a/lib/uuid.c >> +++ b/lib/uuid.c >> @@ -238,6 +238,8 @@ void gen_rand_uuid(unsigned char *uuid_bin) >> unsigned int *ptr = (unsigned int *)&uuid; >> int i; >> >> + srand(get_ticks() + rand()); >> + >> /* Set al
[U-Boot] [PATCH] board/BuR: invalidate ${dtbaddr} before cfgscr
From: Hannes Schmelzer The first memory location of ${dtbaddr} may be still valid after a warm restart of the machine and 'fdt addr ${dtbaddr}' doesn't recognize that the cfgscript didn't run properly and fallback mechanism with copying the internal fdt ${fdtcontroladdr} to ${dtbaddr} doesn't catch this. To get sure that we have proper failsafe behaviour we simply zero the first memory location of ${dtbaddr} for getting sure that the fdt is invalid if cfgscript didn't run. Signed-off-by: Hannes Schmelzer Signed-off-by: Hannes Schmelzer --- include/configs/brppt1.h | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/include/configs/brppt1.h b/include/configs/brppt1.h index 51af93a..82f3f1a 100644 --- a/include/configs/brppt1.h +++ b/include/configs/brppt1.h @@ -66,7 +66,8 @@ #define NANDTGTS \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \ -"cfgscr=nand read ${cfgaddr} cfgscr && source ${cfgaddr}\0" \ +"cfgscr=mw ${dtbaddr} 0; nand read ${cfgaddr} cfgscr && source ${cfgaddr};" \ +" fdt addr ${dtbaddr} || cp ${fdtcontroladdr} ${dtbaddr} 4000\0" \ "nandargs=setenv bootargs console=${console} ${optargs} ${optargs_rot} " \ "root=mtd6 rootfstype=jffs2 b_mode=${b_mode}\0" \ "b_nand=nand read ${loadaddr} kernel; nand read ${dtbaddr} dtb; " \ @@ -104,7 +105,9 @@ #ifdef CONFIG_ENV_IS_IN_MMC #define MMCTGTS \ MMCSPI_TGTS \ -"cfgscr=mmc dev 1; mmc read ${cfgaddr} 200 80; source ${cfgaddr}\0" +"cfgscr=mw ${dtbaddr} 0;" \ +" mmc dev 1; mmc read ${cfgaddr} 200 80; source ${cfgaddr};" \ +" fdt addr ${dtbaddr} || cp ${fdtcontroladdr} ${dtbaddr} 4000\0" #else #define MMCTGTS "" #endif /* CONFIG_MMC */ @@ -112,7 +115,9 @@ MMCSPI_TGTS \ #ifdef CONFIG_SPI #define SPITGTS \ MMCSPI_TGTS \ -"cfgscr=sf probe; sf read ${cfgaddr} 0xC 1; source ${cfgaddr}\0" +"cfgscr=mw ${dtbaddr} 0;" \ +" sf probe; sf read ${cfgaddr} 0xC 1; source ${cfgaddr};" \ +" fdt addr ${dtbaddr} || cp ${fdtcontroladdr} ${dtbaddr} 4000\0" #else #define SPITGTS "" #endif /* CONFIG_SPI */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Raspberry Pi's MAC address locked to the first device the SD card boots on
On 03/05/2019 01:07, Timothy Froehlich wrote: > We've had a problem the past few days that we've traced back to U-Boot. > We're generating images using Yocto with Mender's update routine. The issue > is the first time a clean image is booted on a Raspberry Pi, the mac > address gets permanently saved to the ethaddr env variable. It's a > combination of this line: > > https://github.com/u-boot/u-boot/blob/b4ee6daad7a2604ca9466b2ba48de86cc27d381f/board/raspberrypi/rpi/rpi.c#L348 > > and what I'm pretty sure is Mender doing a "saveenv" on first boot. If you > move the SD card to a different Raspberry Pi, it will boot up with the mac > address of the first Raspberry Pi. > What you would need to do is, delete ethaddr before booting on a different board. I suppose your problem is, that you want to use the same image on different boards and find yourself with the same address. Correct? > I'm not sure what the best long-term solution will be but I can make a > patch for my purposes to just always set ethaddr to usbethaddr. > Well that would omit the possibility to use other MAC addresses then the one in the RPi firmware. Regards, Matthias > So I guess i'm emailing this in to report an issue and maybe help anyone > else who runs into this issue. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework
Hi Tom, On Wed, May 15, 2019 at 05:50:31PM -0400, Tom Rini wrote: > On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote: > > Hi Tom, > > > > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote: > > > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote: > > > > > > > Introduce a framework that allows loading the System Firmware (SYSFW) > > > > binary as well as the associated configuration data from an image tree > > > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC > > > > RAW mode partition or sector. > > > > > > > > To simplify the handling of and loading from the different boot media > > > > we tap into the existing U-Boot SPL framework usually used for loading > > > > U-Boot by building on an earlier commit that exposes some of that > > > > functionality. > > > > > > > > Note that this initial implementation only supports FS and RAW-based > > > > eMMC/SD card boot. > > > [snip] > > > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig > > > > index e677a2e01b..f1731dda58 100644 > > > > --- a/arch/arm/mach-k3/Kconfig > > > > +++ b/arch/arm/mach-k3/Kconfig > > > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID > > > > int > > > > default 16 > > > > > > > > +config K3_LOAD_SYSFW > > > > + bool > > > > + depends on SPL > > > > + default n > > > > > > 'n' is already default, you can drop this. > > > > Ok sure. > > > > > > > > [snip] > > > > +config K3_SYSFW_IMAGE_SIZE_MAX > > > > + int "Amount of memory dynamically allocated for loading SYSFW > > > > blob" > > > > + depends on K3_LOAD_SYSFW > > > > + default 269000 > > > > + help > > > > + Amount of memory reserved through dynamic allocation at > > > > runtime for > > > > + loading the combined System Firmware and configuration image > > > > tree > > > > + blob. Keep it as tight as possible, as this directly affects > > > > the > > > > + overall SPL memory footprint. > > > > > > This is missing a unit, and is 'int' really the best choice here (and > > > really, I guess, 262.6KiB as a default) ? I think 'int' is a more natural fit as this is to reserve memory for the 'sysfw.itb' blob we load from media. This blob is build outside U-Boot using the "System Firmware Image Generator" project [1], and if after build somebody does an 'll' in the build directory the file size would show up as decimal, and that's what needs to fit inside K3_SYSFW_IMAGE_SIZE_MAX. > > Will add a unit. > > > > As for the specific value, in our R5 SPL memory is very very tight. The > > value used here is basically used for a malloc(), and any extra byte > > allocated will be "wasted" and not available for stack etc. Also our > > SYSFW image that is loaded is fixed size (except some +/-100 odd bytes > > if the configuration data is changed that's part of the same SYSFW.ITB > > blob), so a rather tailored size makes sense here. > > Right, that makes sense. But how did you get to that > not-exactly-"round" number rather than say 0x41A00 or some other > slightly smaller value in hex? If 0x41AC8 is right, then, OK, it's > right. It just seems strange at first. The sysfw.itb blob consumed by the SYSFW loader comprises a fixed component (the SYSFW itself), plus a few smaller chunks of variable data containing user configuration data. During initial development the combined size of this ITB was about 264,900 bytes, and 4KB was added as slack to accommodate configuration changes, resulting in what looks like the arbitrary number under discussion. The sysfw.itb blob has actually since grown in size but there is still plenty of space for it to further grow if needed. Since we use this value already in production since last year with no issues I'd rather leave it alone (due to using stack based malloc in R5 SPL increasing that value would directly decrease available stack space with our R5 SPL memory layout where the stack is growing down towards the R5 SPL image itself). > > > [snip] > > > > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile > > > > index 0c3a4f7db1..6c895400c2 100644 > > > > --- a/arch/arm/mach-k3/Makefile > > > > +++ b/arch/arm/mach-k3/Makefile > > > > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o > > > > obj-$(CONFIG_ARM64) += arm64-mmu.o > > > > obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o > > > > obj-$(CONFIG_TI_SECURE_DEVICE) += security.o > > > > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o > > > > obj-y += common.o > > > [snip] > > > > diff --git a/arch/arm/mach-k3/sysfw-loader.c > > > > b/arch/arm/mach-k3/sysfw-loader.c > > > > new file mode 100644 > > > > index 00..a66c27 > > > > --- /dev/null > > > > +++ b/arch/arm/mach-k3/sysfw-loader.c > > > > @@ -0,0 +1,263 @@ > > > [snip] > > > > +#ifdef CONFIG_SPL_BUILD > > > [snip of the whole body of the file] > > > > +#endif > > > > > > We should be using something else in the Makefile, typicall
Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
On Thu, May 16, 2019 at 5:14 PM Matthias Brugger wrote: > On 30/04/2019 21:07, Heinrich Schuchardt wrote: > > > > I think we should have a u-class for hardware RNGs as one source of entropy. > > Anyone working on this already? Not me. > If not I can have a look. green_light_on(); // :) > It could be used for > RPi3 as well (drivers/char/hw_random/bcm2835-rng.c in the Linux kernel). :) > > Regards, > Matthias -- Regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tpm: wait for valid status
The TPM specification says that the EXPECT_DATA bit is not valid until the VALID bit is set. Wait for that bit to be set. Fixes problems with Ifineon SPI TPM. Signed-off-by: Roman Kapl --- drivers/tpm/tpm2_tis_spi.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c index 8878130bd7..7186c179d1 100644 --- a/drivers/tpm/tpm2_tis_spi.c +++ b/drivers/tpm/tpm2_tis_spi.c @@ -295,6 +295,14 @@ static int tpm_tis_spi_wait_for_stat(struct udevice *dev, u8 mask, return -ETIMEDOUT; } +static u8 tpm_tis_spi_valid_status(struct udevice *dev, u8 *status) +{ + struct tpm_chip *chip = dev_get_priv(dev); + + return tpm_tis_spi_wait_for_stat(dev, TPM_STS_VALID, + chip->timeout_c, status); +} + static int tpm_tis_spi_get_burstcount(struct udevice *dev) { struct tpm_chip *chip = dev_get_priv(dev); @@ -455,7 +463,7 @@ static int tpm_tis_spi_send(struct udevice *dev, const u8 *buf, size_t len) i += size; } - ret = tpm_tis_spi_status(dev, &status); + ret = tpm_tis_spi_valid_status(dev, &status); if (ret) goto out_err; @@ -469,7 +477,7 @@ static int tpm_tis_spi_send(struct udevice *dev, const u8 *buf, size_t len) if (ret) goto out_err; - ret = tpm_tis_spi_status(dev, &status); + ret = tpm_tis_spi_valid_status(dev, &status); if (ret) goto out_err; -- 2.20.1.390.gb5101f9297 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC/RESEND 01/22] arm: introduce ARCH_THUNDERX
Hi Tim, Missed aggressive timeline, first RFC series should be out in three weeks time as priority. Regards, Suneel On Tue, May 7, 2019 at 8:10 AM Tim Harvey wrote: > > On Fri, Mar 22, 2019 at 11:23 AM Suneel Garapati wrote: > > > > Hi Tim, > > > > First series will be out week ending April 20th. > > > > Regards, > > Suneel > > Suneel, > > Any update on a Marvell submitted/maintained patch series for Octeon-TX support? > > Best Regards, > > Tim ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
Hi, I get the following error when trying to boot mx6q sabresd with 2019.07-rc2: U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I haven't debugged this yet. Does anyone have any ideas? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] efi_loader: implement deprecated Unicode collation protocol
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2 language codes existed. This protocol is not part of the UEFI specification any longer. Unfortunately it is required to run the UEFI Self Certification Test (SCT) II, version 2.6, 2017. So we implement it here for the sole purpose of running the SCT. It can be removed once a compliant SCT is available. The configuration option defaults to no. Heinrich Schuchardt (2): efi_loader: rename Unicode collation protocol 2 variables efi_loader: implement deprecated Unicode collation protocol include/efi_api.h | 5 include/efi_loader.h | 9 +-- lib/efi_loader/Kconfig | 15 ++-- lib/efi_loader/Makefile| 2 +- lib/efi_loader/efi_root_node.c | 7 +- lib/efi_loader/efi_unicode_collation.c | 33 +++--- lib/efi_selftest/Makefile | 3 ++- 7 files changed, 64 insertions(+), 10 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] efi_loader: rename Unicode collation protocol 2 variables
Rename variables to make it clear they refer to the Unicode collation protocol identified by the EFI_UNICODE_PROTOCOL2_GUID. Signed-off-by: Heinrich Schuchardt --- include/efi_loader.h | 4 ++-- lib/efi_loader/Kconfig | 4 ++-- lib/efi_loader/Makefile| 2 +- lib/efi_loader/efi_root_node.c | 6 +++--- lib/efi_loader/efi_unicode_collation.c | 6 +++--- lib/efi_selftest/Makefile | 3 ++- 6 files changed, 13 insertions(+), 12 deletions(-) diff --git a/include/efi_loader.h b/include/efi_loader.h index 07ef14ba1c..835007e179 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -108,7 +108,7 @@ extern const struct efi_device_path_utilities_protocol efi_device_path_utilities; /* Implementation of the EFI_UNICODE_COLLATION_PROTOCOL */ extern const struct efi_unicode_collation_protocol - efi_unicode_collation_protocol; + efi_unicode_collation_protocol2; extern const struct efi_hii_config_routing_protocol efi_hii_config_routing; extern const struct efi_hii_config_access_protocol efi_hii_config_access; extern const struct efi_hii_database_protocol efi_hii_database; @@ -146,7 +146,7 @@ extern const efi_guid_t efi_file_info_guid; extern const efi_guid_t efi_file_system_info_guid; extern const efi_guid_t efi_guid_device_path_utilities_protocol; /* GUID of the Unicode collation protocol */ -extern const efi_guid_t efi_guid_unicode_collation_protocol; +extern const efi_guid_t efi_guid_unicode_collation_protocol2; extern const efi_guid_t efi_guid_hii_config_routing_protocol; extern const efi_guid_t efi_guid_hii_config_access_protocol; extern const efi_guid_t efi_guid_hii_database_protocol; diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 6501ee56aa..7e13ee54b2 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -36,14 +36,14 @@ config EFI_LOADER_HII U-Boot implements enough of its features to be able to run the UEFI Shell, but not more than that. -config EFI_UNICODE_COLLATION_PROTOCOL +config EFI_UNICODE_COLLATION_PROTOCOL2 bool "Unicode collation protocol" default y help The Unicode collation protocol is used for lexical comparisons. It is required to run the UEFI shell. -if EFI_UNICODE_COLLATION_PROTOCOL +if EFI_UNICODE_COLLATION_PROTOCOL2 config EFI_UNICODE_CAPITALIZATION bool "Support Unicode capitalization" diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index f3d6773bf6..01769ea58b 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -30,7 +30,7 @@ obj-y += efi_memory.o obj-y += efi_root_node.o obj-y += efi_runtime.o obj-y += efi_setup.o -obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL) += efi_unicode_collation.o +obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o obj-y += efi_variable.o obj-y += efi_watchdog.o obj-$(CONFIG_LCD) += efi_gop.o diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c index d8496cc3c2..2b7277de05 100644 --- a/lib/efi_loader/efi_root_node.c +++ b/lib/efi_loader/efi_root_node.c @@ -60,10 +60,10 @@ efi_status_t efi_root_node_register(void) /* Device path utilities protocol */ &efi_guid_device_path_utilities_protocol, (void *)&efi_device_path_utilities, -#if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL) +#if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL2) /* Unicode collation protocol */ -&efi_guid_unicode_collation_protocol, -(void *)&efi_unicode_collation_protocol, +&efi_guid_unicode_collation_protocol2, +(void *)&efi_unicode_collation_protocol2, #endif #if CONFIG_IS_ENABLED(EFI_LOADER_HII) /* HII string protocol */ diff --git a/lib/efi_loader/efi_unicode_collation.c b/lib/efi_loader/efi_unicode_collation.c index 7f3ea3c77e..e04a4de5b7 100644 --- a/lib/efi_loader/efi_unicode_collation.c +++ b/lib/efi_loader/efi_unicode_collation.c @@ -26,8 +26,8 @@ static const u16 codepage[] = CP1250; static const u16 codepage[] = CP437; #endif -/* GUID of the EFI_UNICODE_COLLATION_PROTOCOL */ -const efi_guid_t efi_guid_unicode_collation_protocol = +/* GUID of the EFI_UNICODE_COLLATION_PROTOCOL2 */ +const efi_guid_t efi_guid_unicode_collation_protocol2 = EFI_UNICODE_COLLATION_PROTOCOL2_GUID; /** @@ -318,7 +318,7 @@ static bool EFIAPI efi_str_to_fat(struct efi_unicode_collation_protocol *this, return ret; } -const struct efi_unicode_collation_protocol efi_unicode_collation_protocol = { +const struct efi_unicode_collation_protocol efi_unicode_collation_protocol2 = { .stri_coll = efi_stri_coll, .metai_match = efi_metai_match, .str_lwr = efi_str
[U-Boot] [PATCH 2/2] efi_loader: implement deprecated Unicode collation protocol
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2 language codes existed. This protocol is not part of the UEFI specification any longer. Unfortunately it is required to run the UEFI Self Certification Test (SCT) II, version 2.6, 2017. So we implement it here for the sole purpose of running the SCT. It can be removed once a compliant SCT is available. The configuration option defaults to no. Signed-off-by: Rob Clark Most of Rob's original patch is already merged. Only the deprecated protocol is missing. Rebase it and make it configurable. Signed-off-by: Heinrich Schuchardt --- include/efi_api.h | 5 + include/efi_loader.h | 7 ++- lib/efi_loader/Kconfig | 11 +++ lib/efi_loader/efi_root_node.c | 7 ++- lib/efi_loader/efi_unicode_collation.c | 27 ++ 5 files changed, 55 insertions(+), 2 deletions(-) diff --git a/include/efi_api.h b/include/efi_api.h index 755c405793..7dcd82b681 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -1425,6 +1425,11 @@ struct efi_driver_binding_protocol { efi_handle_t driver_binding_handle; }; +/* Deprecated version of the Unicode collation protocol */ +#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \ + EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \ +0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d) +/* Current version of the Unicode collation protocol */ #define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \ EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \ 0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49) diff --git a/include/efi_loader.h b/include/efi_loader.h index 835007e179..8167e6ffcb 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -106,7 +106,10 @@ extern const struct efi_device_path_to_text_protocol efi_device_path_to_text; /* implementation of the EFI_DEVICE_PATH_UTILITIES_PROTOCOL */ extern const struct efi_device_path_utilities_protocol efi_device_path_utilities; -/* Implementation of the EFI_UNICODE_COLLATION_PROTOCOL */ +/* deprecated version of the EFI_UNICODE_COLLATION_PROTOCOL */ +extern const struct efi_unicode_collation_protocol + efi_unicode_collation_protocol; +/* current version of the EFI_UNICODE_COLLATION_PROTOCOL */ extern const struct efi_unicode_collation_protocol efi_unicode_collation_protocol2; extern const struct efi_hii_config_routing_protocol efi_hii_config_routing; @@ -145,6 +148,8 @@ extern const efi_guid_t efi_file_info_guid; /* GUID for file system information */ extern const efi_guid_t efi_file_system_info_guid; extern const efi_guid_t efi_guid_device_path_utilities_protocol; +/* GUID of the deprecated Unicode collation protocol */ +extern const efi_guid_t efi_guid_unicode_collation_protocol; /* GUID of the Unicode collation protocol */ extern const efi_guid_t efi_guid_unicode_collation_protocol2; extern const efi_guid_t efi_guid_hii_config_routing_protocol; diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 7e13ee54b2..fc04ea39d0 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -54,6 +54,17 @@ config EFI_UNICODE_CAPITALIZATION set, only the the correct handling of the letters of the codepage used by the FAT file system is ensured. +config EFI_UNICODE_COLLATION_PROTOCOL + bool "Deprecated version of the Unicode collation protocol" + default n + help + In EFI 1.10 a version of the Unicode collation protocol using ISO + 639-2 language codes existed. This protocol is not part of the UEFI + specification any longer. Unfortunately it is required to run the + UEFI Self Certification Test (SCT) II, version 2.6, 2017. + + Choose this option for testing only. It is bound to be removed. + endif config EFI_LOADER_BOUNCE_BUFFER diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c index 2b7277de05..f68b0fdc61 100644 --- a/lib/efi_loader/efi_root_node.c +++ b/lib/efi_loader/efi_root_node.c @@ -61,7 +61,12 @@ efi_status_t efi_root_node_register(void) &efi_guid_device_path_utilities_protocol, (void *)&efi_device_path_utilities, #if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL2) -/* Unicode collation protocol */ +#if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL) +/* Deprecated Unicode collation protocol */ +&efi_guid_unicode_collation_protocol, +(void *)&efi_unicode_collation_protocol, +#endif +/* Current Unicode collation protocol */ &efi_guid_unicode_collation_protocol2, (void *)&efi_unicode_collation_protocol2, #endif diff --git a/lib/efi_loader/efi_unicode_collation.c b/lib/efi_lo
Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
On Thu, May 16, 2019 at 11:02 PM Fabio Estevam wrote: > > Hi, > > I get the following error when trying to boot mx6q sabresd with 2019.07-rc2: > > U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) > Trying to boot from MMC1 > spl: could not find mmc device 0. error: -19 No device. Is it DM-SPL-enabled? check with u-boot,dm-spl on associated nodes? usdhc3 is for sabresd, seems like gpio2 missing to add u-boot,dm-spl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote: > Hi Tom > > On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote: > > Hey folks, > > > > I'm attempting, again, to see what we need to do in order to use gcc- > > 8.x > > for U-Boot and ran into, again: > > https://patchwork.ozlabs.org/patch/920329/ which in short is that > > when > > using -mcpu=xscale gcc-8.x throws an odd error: > > cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch > > [-Werror] > > > > Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale > > which > > suggests perhaps something broke in upstream gcc. Looking at the > > kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that > > leads to different failures (seen here with gcc-7.3): > > CC drivers/usb/gadget/pxa25x_udc.o > > {standard input}: Assembler messages: > > {standard input}:779: Error: selected processor does not support `pld > > [lr]' in ARM mode > > {standard input}:1201: Error: selected processor does not support > > `pld [r7]' in ARM mode > > {standard input}:2519: Error: selected processor does not support > > `pld [r3]' in ARM mode > > {standard input}:2796: Error: selected processor does not support > > `pld [r3]' in ARM mode > > > > So, what should we do about this? Is there still active interest in > > supporting the PXA platforms? Thanks folks! > > We are actually still shipping Colibri PXA270 modules for another one > or two years I believe after which Marvell stops selling us chips. > > The strange thing is that I build U-Boot master more or less daily > without any known issues currently using the regular gcc 8.2 2019.01 > tool chain from ARM. Oh, that is interesting. The failure that triggers this comes from https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-arm-linux-gnueabi.tar.xz Can you point me at the gcc-8.2 toolchain you're talking about please? 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] Regarding usage of e1000 driver with our device tree in U-boot.
I have accustom hardware uses IMX6q which has a intel i210 ethernet controller connected to PCIE of IMX6Q , I had configured the PCIE in Kernel and enabled the e1000 driver , I am able to enumerate the controller ping works fine, etc. whereas when I try to configure the controller and PCIE in UBoot, I see PCI driver listing the devices but the ethernet controller is not seen in the "NET:" looks like the e1000 driver is not getting linked to built-in.o Can someone help me with the correct configuration of the uboot for PCIE and e1000. (I am not using driver model, I am configuring my 2017 in the legacy way. Below is my Uboot log U-Boot 2017.03 (May 14 2019 - 14:22:34 -0700) CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 55C Reset cause: POR Board: iMX6q Sbare-SD I2C: ready DRAM: 2 GiB spi setup i2C INIT : PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 *** Warning - bad CRC, using default environment PCI: 00:01.0 - 16c3:abcd - Bridge device 01:00.0- 8086:1533 - Network controller No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In:serial Out: serial Err: serial switch to partitions #0, OK mmc0 is current device Net: FEC Normal Boot Hit any key to stop autoboot: 0 => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.01.00 0x16c3 0xabcd Bridge device 0x04 Cannot read bus configuration: -1 => pci 1 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x8086 0x1533 Network controller 0x00 Cannot read bus configuration: -1 => pci header 1 vendor ID = 0x16c3 device ID = 0xabcd command register ID = 0x0007 status register = 0x0010 revision ID = 0x01 class code = 0x06 (Bridge device) sub class code = 0x04 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x01 BIST =0x00 base address 0 = 0x0100 base address 1 = 0x primary bus number = 0x00 secondary bus number =0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x00 IO limit =0x00 secondary status =0x memory base = 0x0120 memory limit =0x0120 prefetch memory base =0x1000 prefetch memory limit = 0x prefetch memory base upper = 0x prefetch memory limit upper = 0x IO base upper 16 bits = 0x IO limit upper 16 bits = 0x expansion ROM base address = 0x0110 interrupt line = 0xff interrupt pin = 0x01 bridge control = 0x Thanks and Regards Terry Statement Of Confidentiality: This electronic message transmission, and all attachments, contains information from Extron Electronics which is confidential and privileged. The information is for the exclusive viewing or use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by a "reply to sender only" message and destroy all electronic and hard copies of the communication, including attachments. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: zynqmp: Add ZynqMP minimal R5 support
Hello, I have recently been investigating u-boot for booting VxWorks on to the APU and an RPU core of a ZU+ ZCU102 Rev1.1. For some general context, it would be ideal if it were possible to run u-boot on an RPU core to boot VxWorks on to the APU and RPU, instead of running u-boot on the APU. I came across this post (by Michal Simek at xilinx.com) describing minimal support for the R5 which was tested on a ZCU100 Rev C. I compiled and ran the u-boot source with the R5 defconfig, however was not able to get it to run when programmed on to the ZCU102 (no serial data, R5 program counter cycling between 0x0, 0x2, 0x4...0xC, 0x0...). To program it, I placed the binary in memory over JTAG and commanded the CPU to jump to the address (I tried 0x0, 0x100, and 0x200 based on the R5 defconfig CONFIG_SYS_TEXT_BASE= 0x1000). Can you provide any insight as to why this may be and what I can try to fix it? I also noticed that this post specifically mentions using a u-boot.elf, but when I compile the u-boot source a u-boot.elf is not generated, only a u-boot.bin which is what I tried and failed to get working. I suspect there will be more work to be able to boot VxWorks on both processors, but simply having u-boot run would be a great first step. Thank you, Dan Evangelista ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot