[U-Boot] [PATCH v2] ubi: Ensure no fastmap flush after uif_close
On detach UBI attempts to update fastmap after closing user interfaces but at this point UBI volumes have already been free()'ed and fastmap can no longer access these data structures. Signed-off-by: Martin Townsend Cc: h...@denx.de Cc: kmp...@infradead.org Cc: rich...@sigma-star.at --- Changes for v2: - Fix by removing update to fastmap from ubi_fastmap_close instead of reordering uif_close and ubi_wl_close in ubi_detach_mtd_dev drivers/mtd/ubi/fastmap-wl.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/mtd/ubi/fastmap-wl.c b/drivers/mtd/ubi/fastmap-wl.c index a33d406..b7876a8 100644 --- a/drivers/mtd/ubi/fastmap-wl.c +++ b/drivers/mtd/ubi/fastmap-wl.c @@ -337,11 +337,6 @@ static void ubi_fastmap_close(struct ubi_device *ubi) { int i; -#ifndef __UBOOT__ - flush_work(&ubi->fm_work); -#else - update_fastmap_work_fn(ubi); -#endif return_unused_pool_pebs(ubi, &ubi->fm_pool); return_unused_pool_pebs(ubi, &ubi->fm_wl_pool); -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] mmc: Skipping the MMC initialization at the boot time
On 01/18/2018 02:40 PM, Siva Durga Prasad Paladugu wrote: > From: Vipul Kumar > > By enabling CONFIG_SKIP_EARLY_MMC_INIT config, user can skip the MMC > initialization at the boot time. After getting the u-boot console, > user can select the device using mmc dev and can communicate with that. > This is useful where user don't want to perform mmc initialization > while booting and can do explicitly later as per choice. Is there any use-case? What benefit can user have with this config? According to commit-msg, user will choose the mmc device later. Is it same with initializing at booting time? > > Signed-off-by: Vipul Kumar > Signed-off-by: Siva Durga Prasad Paladugu > --- > common/board_r.c| 4 ++-- > drivers/mmc/Kconfig | 7 +++ > 2 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/common/board_r.c b/common/board_r.c > index 2a9df6b..8727b93 100644 > --- a/common/board_r.c > +++ b/common/board_r.c > @@ -421,7 +421,7 @@ static int initr_onenand(void) > } > #endif > > -#ifdef CONFIG_MMC > +#if defined(CONFIG_MMC) && !defined(CONFIG_SKIP_EARLY_MMC_INIT) > static int initr_mmc(void) > { > puts("MMC: "); > @@ -768,7 +768,7 @@ static init_fnc_t init_sequence_r[] = { > #ifdef CONFIG_CMD_ONENAND > initr_onenand, > #endif > -#ifdef CONFIG_MMC > +#if defined(CONFIG_MMC) && !defined(CONFIG_SKIP_EARLY_MMC_INIT) > initr_mmc, > #endif > initr_env, > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index ab0627a..05b1503 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -40,6 +40,13 @@ config SPL_DM_MMC > > if MMC > > +config SKIP_EARLY_MMC_INIT > + bool "Skip the MMC initialization at boot time" > + help > + Skip the MMC initialization at the boot time. After getting the > u-boot > + console, user need to set mmc device and after setting the mmc dev, > user > + can communicate with that device. > + > config ARM_PL180_MMCI > bool "ARM AMBA Multimedia Card Interface and compatible support" > depends on DM_MMC && OF_CONTROL > -- > 2.7.4 > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dm: spi: prevent setting a speed of 0 Hz
When the device tree is missing a correct spi slave description below the bus, the 'set_speed' callback can be called with 'speed' == 0 Hz. At least with cadence qspi, this leads to a division by zero. Prevent this by initializing speed to 100 kHz in this case, as is done in 'dm_spi_claim_bus'. Signed-off-by: Simon Goldschmidt --- drivers/spi/spi-uclass.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c index e06a603ab1..41ecef77db 100644 --- a/drivers/spi/spi-uclass.c +++ b/drivers/spi/spi-uclass.c @@ -325,6 +325,8 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode, if (!speed) { speed = plat->max_hz; mode = plat->mode; + if (!speed) + speed = 10; } ret = spi_set_speed_mode(bus, speed, mode); if (ret) -- 2.11.0 Pepperl+Fuchs GmbH, Mannheim Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), Werner Guthier, Mehmet Hatiboglu Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Claus Michael Registergericht/Register Court: AG Mannheim HRB 4713 Wichtiger Hinweis: Diese E-Mail einschliesslich ihrer Anhaenge enthaelt vertrauliche und rechtlich geschuetzte Informationen, die nur fuer den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und loeschen Sie diese Nachricht und ihre Anhaenge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veraenderung der E-Mail ist untersagt. Der Absender haftet nicht fuer Inhalte von veraenderten E-Mails. Important Information: This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: spi: prevent setting a speed of 0 Hz
Hi On Thu, Jan 18, 2018 at 9:15 AM, Simon Goldschmidt wrote: > When the device tree is missing a correct spi slave description below > the bus, the 'set_speed' callback can be called with 'speed' == 0 Hz. > At least with cadence qspi, this leads to a division by zero. > > Prevent this by initializing speed to 100 kHz in this case, as is > done in 'dm_spi_claim_bus'. > > Signed-off-by: Simon Goldschmidt > --- > > drivers/spi/spi-uclass.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c > index e06a603ab1..41ecef77db 100644 > --- a/drivers/spi/spi-uclass.c > +++ b/drivers/spi/spi-uclass.c > @@ -325,6 +325,8 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int > mode, > if (!speed) { > speed = plat->max_hz; > mode = plat->mode; > + if (!speed) > + speed = 10; You should add a warming message Michael > } > ret = spi_set_speed_mode(bus, speed, mode); > if (ret) > -- > 2.11.0 > > > Pepperl+Fuchs GmbH, Mannheim > Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), > Werner Guthier, Mehmet Hatiboglu > Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Claus > Michael > Registergericht/Register Court: AG Mannheim HRB 4713 > > Wichtiger Hinweis: > Diese E-Mail einschliesslich ihrer Anhaenge enthaelt vertrauliche und > rechtlich geschuetzte Informationen, die nur fuer den Adressaten bestimmt > sind. > Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem > Absender umgehend mit und loeschen Sie diese Nachricht und ihre Anhaenge. Die > unbefugte Weitergabe, das Anfertigen von Kopien und jede Veraenderung der > E-Mail ist untersagt. Der Absender haftet nicht fuer Inhalte von veraenderten > E-Mails. > > > Important Information: > This e-mail message including its attachments contains confidential and > legally protected information solely intended for the addressee. If you are > not the intended addressee of this message, please contact the addresser > immediately and delete this message including its attachments. The > unauthorized dissemination, copying and change of this e-mail are strictly > forbidden. The addresser shall not be liable for the content of such changed > e-mails. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: spi: prevent setting a speed of 0 Hz
On 18.01.2018 09:23, Michael Nazzareno Trimarchi wrote: Hi On Thu, Jan 18, 2018 at 9:15 AM, Simon Goldschmidt wrote: When the device tree is missing a correct spi slave description below the bus, the 'set_speed' callback can be called with 'speed' == 0 Hz. At least with cadence qspi, this leads to a division by zero. Prevent this by initializing speed to 100 kHz in this case, as is done in 'dm_spi_claim_bus'. Signed-off-by: Simon Goldschmidt --- drivers/spi/spi-uclass.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c index e06a603ab1..41ecef77db 100644 --- a/drivers/spi/spi-uclass.c +++ b/drivers/spi/spi-uclass.c @@ -325,6 +325,8 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode, if (!speed) { speed = plat->max_hz; mode = plat->mode; + if (!speed) + speed = 10; You should add a warming message Hmm, I just copied what 'dm_spi_claim_bus' does some hundred lines above in the same file. Why should one code path warn when the other doesn't? Simon Michael } ret = spi_set_speed_mode(bus, speed, mode); if (ret) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: spi: prevent setting a speed of 0 Hz
Hi On Thu, Jan 18, 2018 at 9:27 AM, Simon Goldschmidt wrote: > On 18.01.2018 09:23, Michael Nazzareno Trimarchi wrote: >> >> Hi >> >> On Thu, Jan 18, 2018 at 9:15 AM, Simon Goldschmidt >> wrote: >>> >>> When the device tree is missing a correct spi slave description below >>> the bus, the 'set_speed' callback can be called with 'speed' == 0 Hz. >>> At least with cadence qspi, this leads to a division by zero. >>> >>> Prevent this by initializing speed to 100 kHz in this case, as is >>> done in 'dm_spi_claim_bus'. >>> >>> Signed-off-by: Simon Goldschmidt >>> --- >>> >>> drivers/spi/spi-uclass.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c >>> index e06a603ab1..41ecef77db 100644 >>> --- a/drivers/spi/spi-uclass.c >>> +++ b/drivers/spi/spi-uclass.c >>> @@ -325,6 +325,8 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, >>> int mode, >>> if (!speed) { >>> speed = plat->max_hz; >>> mode = plat->mode; >>> + if (!speed) >>> + speed = 10; >> >> You should add a warming message > > > Hmm, I just copied what 'dm_spi_claim_bus' does some hundred lines above in > the same file. Why should one code path warn when the other doesn't? I just check this page but if you have some missing definition in device tree maybe make sense to make it visible Michael > > Simon > >> >> Michael >> >>> } >>> ret = spi_set_speed_mode(bus, speed, mode); >>> if (ret) >>> -- >>> 2.11.0 > > > -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: Enable gem on zc1751-dc5
Gem is available on dc5 but it wasn't enabled. Enable also random mac address generation and phy handling. Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig index ac565ecf8f9c..af9f1c47145c 100644 --- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig @@ -32,6 +32,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_SPL_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_ENV_IS_IN_FAT=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_FPGA_XILINX=y @@ -44,6 +45,8 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_ETH=y +CONFIG_PHY_GIGE=y +CONFIG_ZYNQ_GEM=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xff00 CONFIG_DEBUG_UART_CLOCK=1 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: Add identification string to ep108
Add identification string to ep108. Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_ep_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynqmp_ep_defconfig b/configs/xilinx_zynqmp_ep_defconfig index 1fc0fabd9256..223351003335 100644 --- a/configs/xilinx_zynqmp_ep_defconfig +++ b/configs/xilinx_zynqmp_ep_defconfig @@ -3,6 +3,7 @@ CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_ep" CONFIG_ARCH_ZYNQMP=y CONFIG_SYS_TEXT_BASE=0x800 CONFIG_SYS_MALLOC_F_LEN=0x8000 +CONFIG_IDENT_STRING=" Xilinx ZynqMP EP108" CONFIG_ZYNQMP_USB=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-ep108" CONFIG_DEBUG_UART=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK
On 18/01/2018 02:24, Peng Fan wrote: > Hi Stefano, > > Do you have any comments on this v5 patchset? I would like this patchset > could catch up 2018.03. Give me time until week-end, I cannot take a look before - thanks ! Regards, Stefano > > Thanks, > Peng. > >> -Original Message- >> From: Peng Fan >> Sent: Wednesday, January 10, 2018 1:20 PM >> To: sba...@denx.de; Fabio Estevam >> Cc: van.free...@gmail.com; u-boot@lists.denx.de; Peng Fan >> >> Subject: [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK >> >> This patchset is to add i.MX8M and i.MX8MQ-EVK support >> >> V5: >> Drop wait_mask_set/clr_timeout and switch to use readl_poll_timeout in the >> patchset. >> >> V4: >> Regenerate patchset based on Tom's master tree. >> In this patchset, https://patchwork.ozlabs.org/patch/855027/ >> "arm: imx: Rework i.MX specific commands to be excluded from SPL" from >> Tom is included to avoid merge conflicts because the i.mx8m change also has >> some modification to bootaux and arch/arm/mach-imx/Makefile. >> Because CONFIG_GPT_TIMER change, I did a small modification to apply Tom's >> patch, no function change. >> >> Include ATF link in README. >> >> V3: >> This patchset based on https://patchwork.ozlabs.org/patch/855027/ >> "arm: imx: Rework i.MX specific commands to be excluded from SPL" from >> Tom to avoid this patchset fail apply after Tom's patch merged. >> >> Previously "power: pmic/regulator allow dm be omited by SPL" broke other >> boards, in V3 patchset, only touch pfuze100 related options. >> >> Sharing code about get mac from fuse between mx7/mx8m Sharing code >> about bootaux between mx6/7/mx8m Sharing code about cpu speed grade >> between mx7/mx8m Sharing code about get boot device between mx7/mx8m >> Sharding code about mmc env between mx7/mx8m >> >> Introduce wait_mask_set/clr_timeout to avoid deadloop in clock pll >> configuration >> >> Correct authorship of fix building warning on fec arm64, patch 27/31. >> >> Switch to use structure for DDR Controller. For DDR PHY registers, there >> are >> about more than 10 thousands registers, I could not convert them with >> detailed register name, and the script is generated from IC team, So I use >> regs[0x] arrays here fo easily converting between IC team released >> script >> and uboot ddr phy cod. >> >> Improve REAMME file to include where to download firmware and imx- >> mkimage and how to build >> >> Add review tags on the V2 patchset. >> >> Hope this patchset could catch up next release :) >> >> V2: >> >> patch 02/23: convert to structure, drop is_boot_from_usb and >>disconnect_from_usb >> patch 04/23: conver to use structure for the clock driver, removed the >> CCM_xxx macros. Add static for local functons. >>Add init_usdhc_clk, init_uart_clk and etc to not enable >>them all at default. >> patch 05/23: Add more commit msg for the sip part. >> patch 08/23: Merge the spl boot device with i.MX7 patch 12/23: Typo fix and >> return error fix from Heiko for the SoC related part patch 22/23: Use a weak >> function ddr_init. If patch 23/23 could not be >> accepted at current stage, to make others still be could be >>compiled. >> >> The patchset depends on >> https://patchwork.ozlabs.org/patch/841934/ >> https://patchwork.ozlabs.org/patch/841958/ >> to be tested on real hardware. >> >> V1: >> >> patch: "power: pmic.h: include dm/ofnode.h" and >> "power: pmic/regulator allow dm be omited by SPL" is previously reviewed in >> mailist to not merged. If no issue, you may pick it up. >> >> The board support is a large patch because of the ddr related code. >> If it is not good, please first review/pick-up other patches if they are ok. >> >> >> >> Peng Fan (29): >> imx: add i.MX8M into Kconfig >> imx: mx8m: add register definition header file >> imx: mx8m: add pin header file >> imx: mx8m: add clock driver >> imx: add sip function >> imx: boot_mode: add USB_BOOT entry >> imx: cpu: update cpu file to support i.MX8M >> imx: spl: implement spl_boot_device for i.MX8M >> imx: add i.MX8MQ SoC Revision and is_mx8m helper >> imx: add pad settings bit definition for i.MX8M >> imx: cpu: move speed/temp to common cpu >> imx: cpu: add cpu speed/grade for i.MX8M >> imx: refactor imx_get_mac_from_fuse >> imx: cleanup bootaux >> imx: bootaux: support i.MX8M >> imx: mx7: move get_boot_device to cpu.c >> imx: cpu: support get_boot_device for i.MX8M >> imx: mx7: move mmc env code to mmc_env.c >> imx: mx8m: add soc related settings and files >> imx: makefile: compile files for i.MX8M >> misc: ocotp: add i.MX8M support >> mmc: fsl_esdhc: support i.MX8M >> imx: lcdif: include i.MX8M >> gpio: mxc: add i.MX8M support >> net: fec: do not access reserved register for i.MX8M >> imx: imx8mq: add dtsi file >> power: pmic/regulator allow dm be omitted by SPL >> imx: mx8m: add ddr controller memory map
Re: [U-Boot] [PATCH] mmc: fix the wrong dislabing clock
Hi, Le 17/01/2018 à 11:36, Jaehoon Chung a écrit : When power is off, clock is not disabling. Because it's passed to 1, mmc->clock should be set to f_min value. Some drivers can't initialize the eMMC/SD card with current status. This fixes the MMC boot for snow (Chromebook). Thanks a lot! Tested-by: Guillaume GARDET Guillaume This patch is to fix the disabling clock value to 0. Fixes: 2e7410d76ad1 ("mmc: disable the mmc clock during power off") Signed-off-by: Jaehoon Chung --- drivers/mmc/mmc.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 53c819187e..311f51f237 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1501,11 +1501,13 @@ static int mmc_set_ios(struct mmc *mmc) int mmc_set_clock(struct mmc *mmc, uint clock, bool disable) { - if (clock > mmc->cfg->f_max) - clock = mmc->cfg->f_max; + if (!disable && clock != 0) { + if (clock > mmc->cfg->f_max) + clock = mmc->cfg->f_max; - if (clock < mmc->cfg->f_min) - clock = mmc->cfg->f_min; + if (clock < mmc->cfg->f_min) + clock = mmc->cfg->f_min; + } mmc->clock = clock; mmc->clk_disable = disable; @@ -2449,7 +2451,7 @@ static int mmc_power_on(struct mmc *mmc) static int mmc_power_off(struct mmc *mmc) { - mmc_set_clock(mmc, 1, true); + mmc_set_clock(mmc, 0, true); #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_REGULATOR) if (mmc->vmmc_supply) { int ret = regulator_set_enable(mmc->vmmc_supply, false); ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK
> On 18/01/2018 02:24, Peng Fan wrote: > > Hi Stefano, > > > > Do you have any comments on this v5 patchset? I would like this > > patchset could catch up 2018.03. > > Give me time until week-end, I cannot take a look before - thanks ! Sorry for the push. Thanks. Thanks, Peng. > > Regards, > Stefano > > > > > Thanks, > > Peng. > > > >> -Original Message- > >> From: Peng Fan > >> Sent: Wednesday, January 10, 2018 1:20 PM > >> To: sba...@denx.de; Fabio Estevam > >> Cc: van.free...@gmail.com; u-boot@lists.denx.de; Peng Fan > >> > >> Subject: [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK > >> > >> This patchset is to add i.MX8M and i.MX8MQ-EVK support > >> > >> V5: > >> Drop wait_mask_set/clr_timeout and switch to use readl_poll_timeout > >> in the patchset. > >> > >> V4: > >> Regenerate patchset based on Tom's master tree. > >> In this patchset, > >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa > >> > tchwork.ozlabs.org%2Fpatch%2F855027%2F&data=02%7C01%7Cpeng.fan%40n > xp. > >> > com%7C626cf8e0c4cb46b6fa5608d55e5091dc%7C686ea1d3bc2b4c6fa92cd99c5c > 30 > >> > 1635%7C0%7C1%7C636518622542742993&sdata=PSuBdmBbxw7Z%2B9Maetke > qGWEsTC > >> tqSnO5IzYsvKkNGI%3D&reserved=0 > >> "arm: imx: Rework i.MX specific commands to be excluded from SPL" > >> from Tom is included to avoid merge conflicts because the i.mx8m > >> change also has some modification to bootaux and arch/arm/mach- > imx/Makefile. > >> Because CONFIG_GPT_TIMER change, I did a small modification to apply > >> Tom's patch, no function change. > >> > >> Include ATF link in README. > >> > >> V3: > >> This patchset based on > >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa > >> > tchwork.ozlabs.org%2Fpatch%2F855027%2F&data=02%7C01%7Cpeng.fan%40n > xp. > >> > com%7C626cf8e0c4cb46b6fa5608d55e5091dc%7C686ea1d3bc2b4c6fa92cd99c5c > 30 > >> > 1635%7C0%7C1%7C636518622542742993&sdata=PSuBdmBbxw7Z%2B9Maetke > qGWEsTC > >> tqSnO5IzYsvKkNGI%3D&reserved=0 > >> "arm: imx: Rework i.MX specific commands to be excluded from SPL" > >> from Tom to avoid this patchset fail apply after Tom's patch merged. > >> > >> Previously "power: pmic/regulator allow dm be omited by SPL" broke > >> other boards, in V3 patchset, only touch pfuze100 related options. > >> > >> Sharing code about get mac from fuse between mx7/mx8m Sharing code > >> about bootaux between mx6/7/mx8m Sharing code about cpu speed grade > >> between mx7/mx8m Sharing code about get boot device between > mx7/mx8m > >> Sharding code about mmc env between mx7/mx8m > >> > >> Introduce wait_mask_set/clr_timeout to avoid deadloop in clock pll > >> configuration > >> > >> Correct authorship of fix building warning on fec arm64, patch 27/31. > >> > >> Switch to use structure for DDR Controller. For DDR PHY registers, > >> there are about more than 10 thousands registers, I could not convert > >> them with detailed register name, and the script is generated from IC > >> team, So I use regs[0x] arrays here fo easily converting between > >> IC team released script and uboot ddr phy cod. > >> > >> Improve REAMME file to include where to download firmware and imx- > >> mkimage and how to build > >> > >> Add review tags on the V2 patchset. > >> > >> Hope this patchset could catch up next release :) > >> > >> V2: > >> > >> patch 02/23: convert to structure, drop is_boot_from_usb and > >> disconnect_from_usb > >> patch 04/23: conver to use structure for the clock driver, removed the > >> CCM_xxx macros. Add static for local functons. > >> Add init_usdhc_clk, init_uart_clk and etc to not enable > >> them all at default. > >> patch 05/23: Add more commit msg for the sip part. > >> patch 08/23: Merge the spl boot device with i.MX7 patch 12/23: Typo > >> fix and return error fix from Heiko for the SoC related part patch > >> 22/23: Use a weak function ddr_init. If patch 23/23 could not be > >> accepted at current stage, to make others still be could be > >> compiled. > >> > >> The patchset depends on > >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa > >> > tchwork.ozlabs.org%2Fpatch%2F841934%2F&data=02%7C01%7Cpeng.fan%40n > xp. > >> > com%7C626cf8e0c4cb46b6fa5608d55e5091dc%7C686ea1d3bc2b4c6fa92cd99c5c > 30 > >> > 1635%7C0%7C1%7C636518622542742993&sdata=DLNROQVpNnwy3wU0Ix25uU > QWJmk%2 > >> BEx%2BPTESrr%2Fc4330%3D&reserved=0 > >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa > >> > tchwork.ozlabs.org%2Fpatch%2F841958%2F&data=02%7C01%7Cpeng.fan%40n > xp. > >> > com%7C626cf8e0c4cb46b6fa5608d55e5091dc%7C686ea1d3bc2b4c6fa92cd99c5c > 30 > >> > 1635%7C0%7C1%7C636518622542742993&sdata=wpdsOEit3lIJ2dkc8FGh2fcY%2 > FhZ > >> vAR%2FVtC19U2fp4QE%3D&reserved=0 > >> to be tested on real hardware. > >> > >> V1: > >> > >> patch: "power: pmic.h: include dm/ofnode.h" and > >> "power: pmic/regulator allow dm be omited by SPL" is previo
Re: [U-Boot] mmc1 not working on Samsung snow chromebook
Hi, Le 17/01/2018 à 11:05, Jaehoon Chung a écrit : Hi Guillaume, On 01/09/2018 11:37 PM, Guillaume Gardet wrote: Hi, Le 17/11/2017 à 10:48, Jaehoon Chung a écrit : Hi, On 2017년 11월 16일 21:29, Guillaume Gardet wrote: I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is working fine. I guess there is a better way to implement the following patch ? ** diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index 23f642980b..a6a0934eef 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct dwmci_host *host, cfg->host_caps |= MMC_MODE_4BIT; cfg->host_caps &= ~MMC_MODE_8BIT; } - cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz; + /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so disbale it for now */ + cfg->host_caps |= MMC_MODE_HS; It means that card is running the lower clock frequency..it's not solution. Timing issue and some problems should be fixed with lowest frequency. Now, i can't test and check more detail. After back to my office or home, i will check what main cause. Any progress on this topic ? Sorry for late. It seems that is related with mmc_power_cycle(). commit 2e7410d76ad11856d09284c18d262d0bb2a3da0c Author: Kishon Vijay Abraham I Date: Thu Sep 21 16:30:04 2017 +0200 mmc: disable the mmc clock during power off There is no point in having the mmc clock enabled during power off. Disable the mmc clock. This is similar to how it's programmed in Linux Kernel. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Vignesh R Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Simon Glass diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 664b71affd..be68d8d930 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1971,6 +1971,7 @@ static int mmc_power_on(struct mmc *mmc) static int mmc_power_off(struct mmc *mmc) { + mmc_set_clock(mmc, 1, true); #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_REGULATOR) if (mmc->vmmc_supply) { int ret = regulator_set_enable(mmc->vmmc_supply, false); Current, I'm looking for fixing it. Could you test with removing its code? As replied to your patch which fixes this commit, it fixed the MMC problem on snow. Thanks a lot! Guillaume Best Regards, Jaehoon Chung Guillaume Best Regards, Jaehoon Chung cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT; } ** Guillaume Le 15/11/2017 à 11:27, Guillaume Gardet a écrit : Le 15/11/2017 à 11:22, Guillaume Gardet a écrit : Forgot to Cc ML. Done now. Le 15/11/2017 à 11:14, Guillaume Gardet a écrit : Hello, I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and while mmc0 (internal eMMC) is working fine, mmc1 (external SD slot) does not work. I get the following error for 'mmc dev 1' command: mmc_init: -110, time 30 Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop auto-boot), I firstly get: mmc_init: -5, time 39 Then, all next attempts retruns: mmc_init: -110, time 30 Guillaume Any idea what could be wrong? Guillaume ___ 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/2] efi_loader: correctly call images
On 18.01.18 08:24, Heinrich Schuchardt wrote: > Avoid a failed assertion when an EFI app calls an EFI app. > > Avoid that the indent level increases when calling 'bootefi hello' > repeatedly. > > Avoid negative indent level when an EFI app calls an EFI app that > calls an EFI app (e.g. iPXE loads grub which starts the kernel). > > Return the status code of a loaded image that returns without > calling the Exit boot service. > > Signed-off-by: Heinrich Schuchardt > --- > lib/efi_loader/efi_boottime.c | 21 ++--- > 1 file changed, 14 insertions(+), 7 deletions(-) > > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c > index 2c5499e0c8..538cc55d20 100644 > --- a/lib/efi_loader/efi_boottime.c > +++ b/lib/efi_loader/efi_boottime.c > @@ -1537,6 +1537,7 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t > image_handle, > asmlinkage ulong (*entry)(efi_handle_t image_handle, > struct efi_system_table *st); > struct efi_loaded_image *info = image_handle; > + efi_status_t ret; > > EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data); > entry = info->reserved; > @@ -1546,17 +1547,23 @@ static efi_status_t EFIAPI > efi_start_image(efi_handle_t image_handle, > /* call the image! */ > if (setjmp(&info->exit_jmp)) { > /* We returned from the child image */ > +#ifdef CONFIG_ARM > + /* efi_exit() called efi_restore_gd() */ > + gd = app_gd; > +#endif > + /* Execute the return part of EFI_CALL */ > + assert(__efi_entry_check()); > + debug("%sEFI: %lu returned by started image\n", > + __efi_nesting_dec(), I don't understand why you need to decrease the nesting level here after the other rework. You're now calling EFI_ENTRY/EFI_EXIT in all normal paths when going in/out of an application, no? Alex > + (unsigned long)((uintptr_t)info->exit_status & > + ~EFI_ERROR_MASK)); > return EFI_EXIT(info->exit_status); > } > > - __efi_nesting_dec(); > - __efi_exit_check(); > - entry(image_handle, &systab); > - __efi_entry_check(); > - __efi_nesting_inc(); > + ret = EFI_CALL(entry(image_handle, &systab)); > > /* Should usually never get here */ > - return EFI_EXIT(EFI_SUCCESS); > + return EFI_EXIT(ret); > } > > /* > @@ -1593,7 +1600,7 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t > image_handle, > exit_data_size, exit_data); > > /* Make sure entry/exit counts for EFI world cross-overs match */ > - __efi_exit_check(); > + EFI_EXIT(exit_status); > > /* >* But longjmp out with the U-Boot gd, not the application's, as > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] efi_selftest: test start image
On 18.01.18 08:24, Heinrich Schuchardt wrote: > This test checks the StartImage boot service. > An EFI application is loaded into memory and started. > > The test is not built on x86_64 because the relocation code for the efi > binary cannot be created. > > Signed-off-by: Heinrich Schuchardt Would it make sense to have 2 mini apps - one that calls ->exit() and one that just returns? Otherwise Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] efi_loader: correctly call images
On 01/18/2018 10:24 AM, Alexander Graf wrote: On 18.01.18 08:24, Heinrich Schuchardt wrote: Avoid a failed assertion when an EFI app calls an EFI app. Avoid that the indent level increases when calling 'bootefi hello' repeatedly. Avoid negative indent level when an EFI app calls an EFI app that calls an EFI app (e.g. iPXE loads grub which starts the kernel). Return the status code of a loaded image that returns without calling the Exit boot service. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_boottime.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 2c5499e0c8..538cc55d20 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -1537,6 +1537,7 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle, asmlinkage ulong (*entry)(efi_handle_t image_handle, struct efi_system_table *st); struct efi_loaded_image *info = image_handle; + efi_status_t ret; EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data); entry = info->reserved; @@ -1546,17 +1547,23 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle, /* call the image! */ if (setjmp(&info->exit_jmp)) { /* We returned from the child image */ +#ifdef CONFIG_ARM + /* efi_exit() called efi_restore_gd() */ + gd = app_gd; +#endif + /* Execute the return part of EFI_CALL */ + assert(__efi_entry_check()); + debug("%sEFI: %lu returned by started image\n", + __efi_nesting_dec(), I don't understand why you need to decrease the nesting level here after the other rework. You're now calling EFI_ENTRY/EFI_EXIT in all normal paths when going in/out of an application, no? bootefi -> level 0 ** EFI application running at level 0 LoadImage EFI_ENTRY -> level 1 LoadImage EFI_EXIT -> level 0 ** EFI application running at level 0 StartImage EFI_ENTRY -> level 1 StartImage EFI_CALL -> level 2 Exit EFI_ENTRY -> level 3 Exit EFI_EXIT -> level 2 longjmp -> level 2 __efi_nesting_dec() -> level 1 StartImage EFI_EXIT -> level 0 ** EFI application running at level 0 again. Exit EFI_ENTRY -> level 1 Exit EFI_EXIT -> level 0 Back to U-Boot For testing indent levels enable DEBUG and * repeatedly execute 'bootefi hello' * setenv efi_selftest start image bootefi selftest (requires [PATCH v2 2/2] efi_selftest: test start image) Best regards Heinrich Alex + (unsigned long)((uintptr_t)info->exit_status & + ~EFI_ERROR_MASK)); return EFI_EXIT(info->exit_status); } - __efi_nesting_dec(); - __efi_exit_check(); - entry(image_handle, &systab); - __efi_entry_check(); - __efi_nesting_inc(); + ret = EFI_CALL(entry(image_handle, &systab)); /* Should usually never get here */ - return EFI_EXIT(EFI_SUCCESS); + return EFI_EXIT(ret); } /* @@ -1593,7 +1600,7 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t image_handle, exit_data_size, exit_data); /* Make sure entry/exit counts for EFI world cross-overs match */ - __efi_exit_check(); + EFI_EXIT(exit_status); /* * But longjmp out with the U-Boot gd, not the application's, as ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/18] efi_loader: address of the simple file system protocol
On 17.01.18 20:15, Heinrich Schuchardt wrote: > When installing the the simple file system protocol we have to path > the address of the structure and not the address of a pointer ot the s/ot/to/ Alex > structure. > > Signed-off-by: Heinrich Schuchardt > --- > v2 > no change > --- > lib/efi_loader/efi_disk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c > index d299fc8dea..85b4a147e2 100644 > --- a/lib/efi_loader/efi_disk.c > +++ b/lib/efi_loader/efi_disk.c > @@ -242,7 +242,7 @@ static void efi_disk_add_dev(const char *name, >diskobj->dp); > ret = efi_add_protocol(diskobj->parent.handle, > &efi_simple_file_system_protocol_guid, > -&diskobj->volume); > +diskobj->volume); > if (ret != EFI_SUCCESS) > goto out_of_memory; > } > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] efi_selftest: test start image
On 01/18/2018 10:30 AM, Alexander Graf wrote: On 18.01.18 08:24, Heinrich Schuchardt wrote: This test checks the StartImage boot service. An EFI application is loaded into memory and started. The test is not built on x86_64 because the relocation code for the efi binary cannot be created. Signed-off-by: Heinrich Schuchardt Would it make sense to have 2 mini apps - one that calls ->exit() and one that just returns? Otherwise Yes that makes sense. I will resubmit. I really headed into trouble when I tried to allow building the test for x86_64. Building helloworld.efi fails on x86_64, too. We should at some time dive into the mixture of 64bit and 32bit defined in arch/x86/config.mk: ifneq ($(CONFIG_EFI_STUB_64BIT),) EFI_LDS := elf_x86_64_efi.lds EFI_CRT0 := crt0_x86_64_efi.o EFI_RELOC := reloc_x86_64_efi.o EFI_TARGET := --target=efi-app-ia32 else EFI_LDS := elf_ia32_efi.lds EFI_CRT0 := crt0_ia32_efi.o EFI_RELOC := reloc_ia32_efi.o EFI_TARGET := --target=efi-app-x86_64 endif Regards Heinrich Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] efi_loader: correctly call images
On 18.01.18 10:52, Heinrich Schuchardt wrote: > > > On 01/18/2018 10:24 AM, Alexander Graf wrote: >> >> >> On 18.01.18 08:24, Heinrich Schuchardt wrote: >>> Avoid a failed assertion when an EFI app calls an EFI app. >>> >>> Avoid that the indent level increases when calling 'bootefi hello' >>> repeatedly. >>> >>> Avoid negative indent level when an EFI app calls an EFI app that >>> calls an EFI app (e.g. iPXE loads grub which starts the kernel). >>> >>> Return the status code of a loaded image that returns without >>> calling the Exit boot service. >>> >>> Signed-off-by: Heinrich Schuchardt >>> --- >>> lib/efi_loader/efi_boottime.c | 21 ++--- >>> 1 file changed, 14 insertions(+), 7 deletions(-) >>> >>> diff --git a/lib/efi_loader/efi_boottime.c >>> b/lib/efi_loader/efi_boottime.c >>> index 2c5499e0c8..538cc55d20 100644 >>> --- a/lib/efi_loader/efi_boottime.c >>> +++ b/lib/efi_loader/efi_boottime.c >>> @@ -1537,6 +1537,7 @@ static efi_status_t EFIAPI >>> efi_start_image(efi_handle_t image_handle, >>> asmlinkage ulong (*entry)(efi_handle_t image_handle, >>> struct efi_system_table *st); >>> struct efi_loaded_image *info = image_handle; >>> + efi_status_t ret; >>> EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, >>> exit_data); >>> entry = info->reserved; >>> @@ -1546,17 +1547,23 @@ static efi_status_t EFIAPI >>> efi_start_image(efi_handle_t image_handle, >>> /* call the image! */ >>> if (setjmp(&info->exit_jmp)) { >>> /* We returned from the child image */ >>> +#ifdef CONFIG_ARM >>> + /* efi_exit() called efi_restore_gd() */ >>> + gd = app_gd; >>> +#endif >>> + /* Execute the return part of EFI_CALL */ >>> + assert(__efi_entry_check()); >>> + debug("%sEFI: %lu returned by started image\n", >>> + __efi_nesting_dec(), >> >> I don't understand why you need to decrease the nesting level here after >> the other rework. You're now calling EFI_ENTRY/EFI_EXIT in all normal >> paths when going in/out of an application, no? > > bootefi -> level 0 > ** EFI application running at level 0 > LoadImage EFI_ENTRY -> level 1 > LoadImage EFI_EXIT -> level 0 > ** EFI application running at level 0 -- base level at 0 > StartImage EFI_ENTRY -> level 1 This is decreased in EFI_EXIT of StartImage > StartImage EFI_CALL -> level 2 This is the one that needs manual decrease then? > Exit EFI_ENTRY -> level 3 Gets decreased right below in Exit again > Exit EFI_EXIT -> level 2 > longjmp -> level 2 > __efi_nesting_dec() -> level 1 > StartImage EFI_EXIT -> level 0 --- base level again So I guess the problem is that we never get into the second half of EFI_CALL when ->exit() gets called because of the longjmp. Can you please add a comment explaining that rationale with a hint to EFI_CALL and that all we do is execute the lower half of it manually again because it got interrupted by the longjmp? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system
On 01/18/2018 05:33 AM, Chee, Tien Fong wrote: > On Tue, 2018-01-16 at 15:41 +0100, Marek Vasut wrote: >> On 12/27/2017 06:04 AM, tien.fong.c...@intel.com wrote: >> >> Whoa, this improved substantially since last time I checked. Minor >> nitpicks below. >> >> [...] >> >>> >>> +/* USB build is not supported yet in SPL */ >>> +#ifndef CONFIG_SPL_BUILD >>> +#ifdef CONFIG_USB_STORAGE >>> +static int init_usb(void) >>> +{ >>> + int err; >>> + >>> + err = usb_init(); >>> + if (err) >>> + return err; >>> + >>> +#ifndef CONFIG_DM_USB >>> + err = usb_stor_scan(1) < 0 ? -ENODEV : 0; >> if (err) >> return err; >> ? >> > This is last line code of the function, so it's always return the > result regardless error or not. You are rewriting the true error code with -ENODEV instead of propagating it. >>> >>> +#endif >>> + >>> + return err; >>> +} >>> +#else >>> +static int init_usb(void) >>> +{ >>> + printf("Error: Cannot load flash image: no USB >>> support\n"); >> debug() ? Fix globally ... >> > okay. >>> >>> + return -ENOSYS; >>> +} >>> +#endif >>> +#endif >>> + >>> +#ifdef CONFIG_SATA >>> +static int init_storage_sata(void) >>> +{ >>> + return sata_probe(0); >>> +} >>> +#else >>> +static int init_storage_sata(void) >>> +{ >>> + printf("Error: Cannot load image: no SATA support\n"); >>> + return -ENOSYS; >>> +} >>> +#endif >>> + >>> +#ifdef CONFIG_CMD_UBIFS >>> +static int mount_ubifs(struct device_location *location) >>> +{ >>> + int ret; >>> + char cmd[32]; >>> + >>> + sprintf(cmd, "ubi part %s", location->mtdpart); >> snprintf() ... >> > okay. >>> >>> + ret = run_command(cmd, 0); >>> + if (ret) >>> + return ret; >>> + >>> + sprintf(cmd, "ubifsmount %s", location->ubivol); >>> + >>> + ret = run_command(cmd, 0); >>> + >>> + return ret; >>> +} >>> + >>> +static int umount_ubifs(void) >>> +{ >>> + return run_command("ubifsumount", 0); >> Just call the function directly ? >> > There are some checking like ubifs_initialized in the cmd/ubifs.c. > Direct callng the function would bypass those checking. Then factor those out into a function you can all and call that function. >>> >>> +} >>> +#else >>> +static int mount_ubifs(struct device_location *location) >>> +{ >>> + printf("Error: Cannot load image: no UBIFS support\n"); >>> + return -ENOSYS; >>> +} >>> +#endif >>> + >>> +#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD) >>> +static int init_mmc(void) >>> +{ >>> + /* Just for the case MMC is not yet initialized */ >>> + struct mmc *mmc = NULL; >>> + int err; >>> + >>> + spl_mmc_find_device(&mmc, spl_boot_device()); >>> + >>> + err = mmc_init(mmc); >>> + if (err) { >>> + printf("spl: mmc init failed with error: %d\n", >>> err); >>> + return err; >>> + } >>> + >>> + return err; >>> +} >>> +#else >>> +static int init_mmc(void) >>> +{ >>> + /* Expect somewhere already initialize MMC */ >>> + return 0; >>> +} >>> +#endif >>> + >>> +static int select_fs_dev(struct device_location *location) >>> +{ >>> + int ret; >>> + >>> + if (!strcmp("mmc", location->name)) { >>> + ret = fs_set_blk_dev("mmc", location->devpart, >>> FS_TYPE_ANY); >>> + } else if (!strcmp("usb", location->name)) { >>> + ret = fs_set_blk_dev("usb", location->devpart, >>> FS_TYPE_ANY); >>> + } else if (!strcmp("sata", location->name)) { >>> + ret = fs_set_blk_dev("sata", location->devpart, >>> FS_TYPE_ANY); >>> + } else if (!strcmp("ubi", location->name)) { >>> + if (location->ubivol != NULL) >>> + ret = fs_set_blk_dev("ubi", NULL, >>> FS_TYPE_UBIFS); >>> + else >>> + ret = -ENODEV; >>> + } else { >>> + printf("Error: unsupported location storage.\n"); >>> + return -ENODEV; >>> + } >>> + >>> + if (ret) >>> + printf("Error: could not access storage.\n"); >>> + >>> + return ret; >>> +} >>> + >>> +static int init_storage_device(struct device_location *location) >>> +{ >>> + int ret; >>> + >>> + if (!strcmp("mmc", location->name)) { >>> + ret = init_mmc(); >>> + } else if (!strcmp("sata", location->name)) { >>> + ret = init_storage_sata(); >>> + } else if (location->ubivol != NULL) { >>> + ret = mount_ubifs(location); >>> +#ifndef CONFIG_SPL_BUILD >>> + /* USB build is not supported yet in SPL */ >>> + } else if (!strcmp("usb", location->name)) { >>> + ret = init_usb(); >>> +#endif >>> + } else { >>> + printf("Error: no supported storage device is >>> available.\n"); >>> + ret = -ENODEV; >>> + } >>> + >>> + return ret; >>> +} >>> + >>> +static void set_storage_devpart(char *name, char *devpart) >>> +{ >>> + size_t i; >>> + >>> + for (i = 0; i < ARRAY_SIZE(default_locations); i++) { >>> + if (!strcmp(default_locations[i].name, name)) >>> + default_locations[i].devpart = devpart; >>> + } >>> +} >>> + >>
Re: [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
On 18/01/18 01:31, Kever Yang wrote: I don't think we can reuse IH_TYPE_TEE, it use a optee.img type create by mkimage and it seem use more then one cpu. Don't really understand what you mean by using more than one CPU - can you give an example in the code ? --- bod ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] Add stmf429-evaluation board support
From: Patrice Chotard This series add support for stmf429-evaluation board. Before adding this board support, the clk_stm32f driver must be updated to be able to retrieve external oscillator frequency (HSE) from device tree. This because stm32f429-evaluation board doesn't use a 8 Mhz external oscillator as all STM32F4 board supported (stm32f429-disco and stm32f469-disco). Patrice Chotard (6): ARM: dts: stm32: add "u-boot,dm-pre-reloc" for clk_hse in stm32f7-u-boot clk: stm32: retrieve external oscillator frequency from DT configs: stm32f: Remove STM32_HSE_HZ for all STM32F series board: stm32: Add stm32f429-evaluation board support ARM: dts: stm32: Add STM32F429 Evaluation board support ARM: dts: stm32: add stm32429-eval-u-boot dts file arch/arm/dts/Makefile | 1 + arch/arm/dts/stm32429i-eval-u-boot.dtsi| 231 + arch/arm/dts/stm32429i-eval.dts| 276 + arch/arm/dts/stm32f7-u-boot.dtsi | 4 + arch/arm/mach-stm32/stm32f4/Kconfig| 4 + board/st/stm32f429-evaluation/Kconfig | 19 ++ board/st/stm32f429-evaluation/MAINTAINERS | 6 + board/st/stm32f429-evaluation/Makefile | 8 + .../st/stm32f429-evaluation/stm32f429-evaluation.c | 74 ++ configs/stm32f429-evaluation_defconfig | 31 +++ drivers/clk/clk_stm32f.c | 78 -- include/configs/stm32f429-discovery.h | 2 - include/configs/stm32f429-evaluation.h | 65 + include/configs/stm32f469-discovery.h | 1 - include/configs/stm32f746-disco.h | 1 - 15 files changed, 776 insertions(+), 25 deletions(-) create mode 100644 arch/arm/dts/stm32429i-eval-u-boot.dtsi create mode 100644 arch/arm/dts/stm32429i-eval.dts create mode 100644 board/st/stm32f429-evaluation/Kconfig create mode 100644 board/st/stm32f429-evaluation/MAINTAINERS create mode 100644 board/st/stm32f429-evaluation/Makefile create mode 100644 board/st/stm32f429-evaluation/stm32f429-evaluation.c create mode 100644 configs/stm32f429-evaluation_defconfig create mode 100644 include/configs/stm32f429-evaluation.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] ARM: dts: stm32: add "u-boot, dm-pre-reloc" for clk_hse in stm32f7-u-boot
From: Patrice Chotard In order to retrieve the clk_hse fixed clock phandle in clk_stm32f driver, add "u-boot,dm-pre-reloc" property in Uboot specific DT file. Signed-off-by: Patrice Chotard --- arch/arm/dts/stm32f7-u-boot.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/stm32f7-u-boot.dtsi b/arch/arm/dts/stm32f7-u-boot.dtsi index a56ae93..9a9e4e5 100644 --- a/arch/arm/dts/stm32f7-u-boot.dtsi +++ b/arch/arm/dts/stm32f7-u-boot.dtsi @@ -26,3 +26,7 @@ &pwrcfg { u-boot,dm-pre-reloc; }; + +&clk_hse { + u-boot,dm-pre-reloc; +}; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] clk: stm32: retrieve external oscillator frequency from DT
From: Patrice Chotard All current STM32F4 supported boards uses a 8MHz external oscillator. All current STM32F7 supported boards uses a 25MHz external oscillator. In order to introduce the new stm32f429-evaluation board which uses a 25MHz external oscillator without creating a dedicated struct stm32_clk_info for this board, retrieve the external oscillator frequency from DT and set pll_m accordingly to obtain 1MHz for the VCO. Signed-off-by: Patrice Chotard --- drivers/clk/clk_stm32f.c | 78 +++- 1 file changed, 57 insertions(+), 21 deletions(-) diff --git a/drivers/clk/clk_stm32f.c b/drivers/clk/clk_stm32f.c index 63116e0..ebe1ce6 100644 --- a/drivers/clk/clk_stm32f.c +++ b/drivers/clk/clk_stm32f.c @@ -93,10 +93,9 @@ enum periph_clock { STMMAC_CLOCK_CFG, }; -struct stm32_clk_info stm32f4_clk_info = { +static const struct stm32_clk_info stm32f4_clk_info = { /* 180 MHz */ .sys_pll_psc = { - .pll_m = 8, .pll_n = 360, .pll_p = 2, .pll_q = 8, @@ -108,10 +107,9 @@ struct stm32_clk_info stm32f4_clk_info = { .v2 = false, }; -struct stm32_clk_info stm32f7_clk_info = { +static const struct stm32_clk_info stm32f7_clk_info = { /* 200 MHz */ .sys_pll_psc = { - .pll_m = 25, .pll_n = 400, .pll_p = 2, .pll_q = 8, @@ -126,7 +124,8 @@ struct stm32_clk_info stm32f7_clk_info = { struct stm32_clk { struct stm32_rcc_regs *base; struct stm32_pwr_regs *pwr_regs; - struct stm32_clk_info *info; + struct stm32_clk_info info; + unsigned long hse_rate; }; static int configure_clocks(struct udevice *dev) @@ -134,7 +133,7 @@ static int configure_clocks(struct udevice *dev) struct stm32_clk *priv = dev_get_priv(dev); struct stm32_rcc_regs *regs = priv->base; struct stm32_pwr_regs *pwr = priv->pwr_regs; - struct pll_psc sys_pll_psc = priv->info->sys_pll_psc; + struct pll_psc *sys_pll_psc = &priv->info.sys_pll_psc; u32 pllsaicfgr = 0; /* Reset RCC configuration */ @@ -152,20 +151,20 @@ static int configure_clocks(struct udevice *dev) ; setbits_le32(®s->cfgr, (( - sys_pll_psc.ahb_psc << RCC_CFGR_HPRE_SHIFT) - | (sys_pll_psc.apb1_psc << RCC_CFGR_PPRE1_SHIFT) - | (sys_pll_psc.apb2_psc << RCC_CFGR_PPRE2_SHIFT))); + sys_pll_psc->ahb_psc << RCC_CFGR_HPRE_SHIFT) + | (sys_pll_psc->apb1_psc << RCC_CFGR_PPRE1_SHIFT) + | (sys_pll_psc->apb2_psc << RCC_CFGR_PPRE2_SHIFT))); /* Configure the main PLL */ setbits_le32(®s->pllcfgr, RCC_PLLCFGR_PLLSRC); /* pll source HSE */ clrsetbits_le32(®s->pllcfgr, RCC_PLLCFGR_PLLM_MASK, - sys_pll_psc.pll_m << RCC_PLLCFGR_PLLM_SHIFT); + sys_pll_psc->pll_m << RCC_PLLCFGR_PLLM_SHIFT); clrsetbits_le32(®s->pllcfgr, RCC_PLLCFGR_PLLN_MASK, - sys_pll_psc.pll_n << RCC_PLLCFGR_PLLN_SHIFT); + sys_pll_psc->pll_n << RCC_PLLCFGR_PLLN_SHIFT); clrsetbits_le32(®s->pllcfgr, RCC_PLLCFGR_PLLP_MASK, - ((sys_pll_psc.pll_p >> 1) - 1) << RCC_PLLCFGR_PLLP_SHIFT); + ((sys_pll_psc->pll_p >> 1) - 1) << RCC_PLLCFGR_PLLP_SHIFT); clrsetbits_le32(®s->pllcfgr, RCC_PLLCFGR_PLLQ_MASK, - sys_pll_psc.pll_q << RCC_PLLCFGR_PLLQ_SHIFT); + sys_pll_psc->pll_q << RCC_PLLCFGR_PLLQ_SHIFT); /* Configure the SAI PLL to get a 48 MHz source */ pllsaicfgr = RCC_PLLSAICFGR_PLLSAIR_2 | RCC_PLLSAICFGR_PLLSAIQ_4 | @@ -178,7 +177,7 @@ static int configure_clocks(struct udevice *dev) while (!(readl(®s->cr) & RCC_CR_PLLRDY)) ; - if (priv->info->v2) { /*stm32f7 case */ + if (priv->info.v2) { /*stm32f7 case */ /* select PLLSAI as 48MHz clock source */ setbits_le32(®s->dckcfgr2, RCC_DCKCFGRX_CK48MSEL); @@ -202,7 +201,7 @@ static int configure_clocks(struct udevice *dev) setbits_le32(®s->apb1enr, RCC_APB1ENR_PWREN); - if (priv->info->has_overdrive) { + if (priv->info.has_overdrive) { /* * Enable high performance mode * System frequency up to 200 MHz @@ -241,7 +240,7 @@ static unsigned long stm32_clk_pll48clk_rate(struct stm32_clk *priv, pllq = (readl(®s->pllcfgr) & RCC_PLLCFGR_PLLQ_MASK) >> RCC_PLLCFGR_PLLQ_SHIFT; - if (priv->info->v2) /*stm32f7 case */ + if (priv->info.v2) /*stm32f7 case */ pllsai = readl(®s->dckcfgr2) & RCC_DCKCFGRX_CK48MSEL; else pllsai = readl(®s->dckcfgr) & RCC_DCKCFGRX_CK48MSEL; @@ -253,7 +252,7 @@ static unsigned long stm32_clk_pll48clk_rate(struct stm32_clk *priv,
[U-Boot] [PATCH 6/6] ARM: dts: stm32: add stm32429-eval-u-boot dts file
From: Patrice Chotard _ Add gpio compatible and aliases for stm32f469 _ Add FMC sdram node _ Add "u-boot,dm-pre-reloc" for rcc, fmc, fixed-clock, pinctrl, pwrcfg and gpio nodes. Signed-off-by: Patrice Chotard --- arch/arm/dts/stm32429i-eval-u-boot.dtsi | 231 1 file changed, 231 insertions(+) create mode 100644 arch/arm/dts/stm32429i-eval-u-boot.dtsi diff --git a/arch/arm/dts/stm32429i-eval-u-boot.dtsi b/arch/arm/dts/stm32429i-eval-u-boot.dtsi new file mode 100644 index 000..826c942 --- /dev/null +++ b/arch/arm/dts/stm32429i-eval-u-boot.dtsi @@ -0,0 +1,231 @@ +/* + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +/{ + clocks { + u-boot,dm-pre-reloc; + }; + + aliases { + /* Aliases for gpios so as to use sequence */ + gpio0 = &gpioa; + gpio1 = &gpiob; + gpio2 = &gpioc; + gpio3 = &gpiod; + gpio4 = &gpioe; + gpio5 = &gpiof; + gpio6 = &gpiog; + gpio7 = &gpioh; + gpio8 = &gpioi; + gpio9 = &gpioj; + gpio10 = &gpiok; + }; + + soc { + u-boot,dm-pre-reloc; + pin-controller { + u-boot,dm-pre-reloc; + }; + + fmc: fmc@A000 { + compatible = "st,stm32-fmc"; + reg = <0xA000 0x1000>; + clocks = <&rcc 0 STM32F4_AHB3_CLOCK(FMC)>; + st,syscfg = <&syscfg>; + pinctrl-0 = <&fmc_pins_d32>; + pinctrl-names = "default"; + st,mem_remap = <4>; + u-boot,dm-pre-reloc; + + /* +* Memory configuration from sdram +* MICRON MT48LC4M32B2B5-7 +*/ + bank0: bank@0 { + st,sdram-control = /bits/ 8 ; + st,sdram-timing = /bits/ 8 ; + st,sdram-refcount = < 2812 >; + }; + }; + }; +}; + +&clk_hse { + u-boot,dm-pre-reloc; +}; + +&clk_lse { + u-boot,dm-pre-reloc; +}; + +&clk_i2s_ckin { + u-boot,dm-pre-reloc; +}; + +&pwrcfg { + u-boot,dm-pre-reloc; +}; + +&syscfg { + u-boot,dm-pre-reloc; +}; + +&rcc { + u-boot,dm-pre-reloc; +}; + +&gpioa { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpiob { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpioc { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpiod { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpioe { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpiof { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpiog { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpioh { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpioi { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpioj { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&gpiok { + compatible = "st,stm32-gpio"; + u-boot,dm-pre-reloc; +}; + +&pinctrl { + usart1_pins_a: usart1@0 { + u-boot,dm-pre-reloc; + pins1 { + u-boot,dm-pre-reloc; + }; + pins2 { + u-boot,dm-pre-reloc; + }; + }; + + fmc_pins_d32: fmc_d32@0 { + u-boot,dm-pre-reloc; + pins + { + pinmux = , /* D31 */ +, /* D30 */ +, /* D29 */ +, /* D28 */ +, /* D27 */ +, /* D26 */ +, /* D25 */ +, /* D24 */ +, /* D23 */ +, /* D22 */ +, /* D21 */ +, /* D20 */ +, /* D19 */ +, /* D18 */ +, /* D17 */ +, /* D16 */ + +, /* D15 */ +, /* D14 */ +, /* D13 */ +, /* D12 */ +, /* D11 */ +, /* D10 */ +, /* D09 */ +
[U-Boot] [PATCH 5/6] ARM: dts: stm32: Add STM32F429 Evaluation board support
From: Patrice Chotard This DT file comes from kernel v4.15, this board offers : _ STM32F429NIH6 microcontroller _ 4.3” color TFT LCD with resistive touchscreen (480 x 272 pixels) _ Six 5 V power supply options: Power jack ST-LINK/V2 USB connector User USB HS connector User USB FS1 connector User USB FS2 connector Daughterboard _ SAI Audio DAC, stereo audio jack which supports headset with microphone _ Stereo digital microphone, audio terminal connector used to connect external speakers _ 2 GBytes (or more) SDIO interface MicroSD card _ RF EEPROM on I2 C compatible serial interface _ RS-232 communication _ IrDA transceiver _ JTAG/SWD and ETM trace debug support, ST-LINK/V2 embedded _ IEEE-802.3-2002 compliant Ethernet connector _ Camera module _ 8M x 32-bit SDRAM, 1M x 16-bit SRAM and 8M x 16-bit NOR Flash _ Joystick with 4-directional control and selector _ Reset, Wakeup and Tamper buttons _ 4 color user LEDs _ Extension connectors & memory connectors for daughterboard or wrapping board _ USB OTG HS and FS with Micro-AB connectors _ RTC with backup battery _ CAN2.0A/B compliant connection _ Potentiometer _ Motor control connector Signed-off-by: Patrice Chotard --- arch/arm/dts/Makefile | 1 + arch/arm/dts/stm32429i-eval.dts | 276 2 files changed, 277 insertions(+) create mode 100644 arch/arm/dts/stm32429i-eval.dts diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index f10482e..0626c76 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -214,6 +214,7 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \ dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb dtb-$(CONFIG_STM32F4) += stm32f429-disco.dtb \ + stm32429i-eval.dtb \ stm32f469-disco.dtb dtb-$(CONFIG_STM32F7) += stm32f746-disco.dtb \ diff --git a/arch/arm/dts/stm32429i-eval.dts b/arch/arm/dts/stm32429i-eval.dts new file mode 100644 index 000..362ea42 --- /dev/null +++ b/arch/arm/dts/stm32429i-eval.dts @@ -0,0 +1,276 @@ +/* + * Copyright (C) 2015, STMicroelectronics - All Rights Reserved + * Author: Maxime Coquelin for STMicroelectronics. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +/dts-v1/; +#include "stm32f429.dtsi" +#include "stm32f429-pinctrl.dtsi" +#include +#include + +/ { + model = "STMicroelectronics STM32429i-EVAL board"; + compatible = "st,stm32429i-eval", "st,stm32f429"; + + chosen { + bootargs = "root=/dev/ram"; + stdout-path = "serial0:115200n8"; + }; + + memory { + reg = <0x 0x200>; + }; + + aliases { + serial0 = &usart1; + }; + + clocks { + clk_ext_camera: clk-ext-camera { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <2400>; + }; + }; + + soc { + dma-ranges = <0xc000 0x0 0x1000>; + }; + + regulators { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + reg_vref: regulator@0 { + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "vref"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + }; + }; + + leds { + compatible = "gpio-leds"; + green { + gpios = <&gpiog 6 1>; + linux,default-trigger = "heartbeat"; + }; + orange { + gpios = <&gpiog 7 1>; + }; + red { + gpios = <&gpiog 10 1>; + }; + blue { + gpios = <&gpiog 12 1>; + }; + }; + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + autorepeat; + button@0 { + label = "Wake up"; + linux,code = ; + gpios = <&gpioa 0 0>; + }; + button@1 { + label = "Tamper"; + linux,code = ; + gpios = <&gpioc 13 0>; + }; + }; + + usbotg_hs_phy: usbphy { + #phy-cells = <0>; + compatible = "usb-nop-xceiv"; + clocks = <&rcc 0 STM32F4_AHB1_CLOCK(OTGHSULPI)>; + clock-names = "main_clk"; + }; + + panel_rgb: panel-rgb { + compatible = "ampire,am-480272h3tmqw-t01h"; + status = "okay"; +
[U-Boot] [PATCH 3/6] configs: stm32f: Remove STM32_HSE_HZ for all STM32F series
From: Patrice Chotard As clk_stm32f driver is able to retrieve HSE frequency from DT, CONFIG_STM32_HSE_HZ becomes useless. Signed-off-by: Patrice Chotard --- include/configs/stm32f429-discovery.h | 2 -- include/configs/stm32f469-discovery.h | 1 - include/configs/stm32f746-disco.h | 1 - 3 files changed, 4 deletions(-) diff --git a/include/configs/stm32f429-discovery.h b/include/configs/stm32f429-discovery.h index 1ad3698..af9daad 100644 --- a/include/configs/stm32f429-discovery.h +++ b/include/configs/stm32f429-discovery.h @@ -43,8 +43,6 @@ #define CONFIG_STM32_FLASH -#define CONFIG_STM32_HSE_HZ800 - #define CONFIG_SYS_CLK_FREQ18000 /* 180 MHz */ #define CONFIG_SYS_HZ_CLOCK100 /* Timer is clocked at 1MHz */ diff --git a/include/configs/stm32f469-discovery.h b/include/configs/stm32f469-discovery.h index 140..c290a66 100644 --- a/include/configs/stm32f469-discovery.h +++ b/include/configs/stm32f469-discovery.h @@ -39,7 +39,6 @@ #define CONFIG_STM32_FLASH -#define CONFIG_STM32_HSE_HZ800 #define CONFIG_SYS_CLK_FREQ18000 /* 180 MHz */ #define CONFIG_SYS_HZ_CLOCK100 /* Timer is clocked at 1MHz */ diff --git a/include/configs/stm32f746-disco.h b/include/configs/stm32f746-disco.h index d12b1d8..301ab0f 100644 --- a/include/configs/stm32f746-disco.h +++ b/include/configs/stm32f746-disco.h @@ -37,7 +37,6 @@ #define CONFIG_MII #define CONFIG_PHY_SMSC -#define CONFIG_STM32_HSE_HZ2500 #define CONFIG_SYS_CLK_FREQ2 /* 200 MHz */ #define CONFIG_SYS_HZ_CLOCK100 /* Timer is clocked at 1MHz */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] board: stm32: Add stm32f429-evaluation board support
From: Patrice Chotard Add stm32f429-evaluation board support. For more information, please visit: http://www.st.com/en/evaluation-tools/stm32429i-eval.html Signed-off-by: Patrice Chotard --- arch/arm/mach-stm32/stm32f4/Kconfig| 4 ++ board/st/stm32f429-evaluation/Kconfig | 19 ++ board/st/stm32f429-evaluation/MAINTAINERS | 6 ++ board/st/stm32f429-evaluation/Makefile | 8 +++ .../st/stm32f429-evaluation/stm32f429-evaluation.c | 74 ++ configs/stm32f429-evaluation_defconfig | 31 + include/configs/stm32f429-evaluation.h | 65 +++ 7 files changed, 207 insertions(+) create mode 100644 board/st/stm32f429-evaluation/Kconfig create mode 100644 board/st/stm32f429-evaluation/MAINTAINERS create mode 100644 board/st/stm32f429-evaluation/Makefile create mode 100644 board/st/stm32f429-evaluation/stm32f429-evaluation.c create mode 100644 configs/stm32f429-evaluation_defconfig create mode 100644 include/configs/stm32f429-evaluation.h diff --git a/arch/arm/mach-stm32/stm32f4/Kconfig b/arch/arm/mach-stm32/stm32f4/Kconfig index 7005c65..e8fae4d 100644 --- a/arch/arm/mach-stm32/stm32f4/Kconfig +++ b/arch/arm/mach-stm32/stm32f4/Kconfig @@ -3,10 +3,14 @@ if STM32F4 config TARGET_STM32F429_DISCOVERY bool "STM32F429 Discovery board" +config TARGET_STM32F429_EVALUATION + bool "STM32F429 Evaluation board" + config TARGET_STM32F469_DISCOVERY bool "STM32F469 Discovery board" source "board/st/stm32f429-discovery/Kconfig" +source "board/st/stm32f429-evaluation/Kconfig" source "board/st/stm32f469-discovery/Kconfig" endif diff --git a/board/st/stm32f429-evaluation/Kconfig b/board/st/stm32f429-evaluation/Kconfig new file mode 100644 index 000..ca4bb3d --- /dev/null +++ b/board/st/stm32f429-evaluation/Kconfig @@ -0,0 +1,19 @@ +if TARGET_STM32F429_EVALUATION + +config SYS_BOARD + string + default "stm32f429-evaluation" + +config SYS_VENDOR + string + default "st" + +config SYS_SOC + string + default "stm32f4" + +config SYS_CONFIG_NAME + string + default "stm32f429-evaluation" + +endif diff --git a/board/st/stm32f429-evaluation/MAINTAINERS b/board/st/stm32f429-evaluation/MAINTAINERS new file mode 100644 index 000..8b7b312 --- /dev/null +++ b/board/st/stm32f429-evaluation/MAINTAINERS @@ -0,0 +1,6 @@ +STM32F429-EVALUATION BOARD +M: Patrice Chotard +S: Maintained +F: board/st/stm32f429-evaluation/ +F: include/configs/stm32f429-evaluation.h +F: configs/stm32f429-evaluation_defconfig diff --git a/board/st/stm32f429-evaluation/Makefile b/board/st/stm32f429-evaluation/Makefile new file mode 100644 index 000..3efba3a --- /dev/null +++ b/board/st/stm32f429-evaluation/Makefile @@ -0,0 +1,8 @@ +# +# Copyright (C) 2018, STMicroelectronics - All Rights Reserved +# Author(s): Patrice CHOTARD, for STMicroelectronics. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := stm32f429-evaluation.o diff --git a/board/st/stm32f429-evaluation/stm32f429-evaluation.c b/board/st/stm32f429-evaluation/stm32f429-evaluation.c new file mode 100644 index 000..25e0207 --- /dev/null +++ b/board/st/stm32f429-evaluation/stm32f429-evaluation.c @@ -0,0 +1,74 @@ +/* + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved + * Author(s): Patrice Chotard, for STMicroelectronics. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include + +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +int dram_init(void) +{ + int rv; + struct udevice *dev; + + rv = uclass_get_device(UCLASS_RAM, 0, &dev); + if (rv) { + debug("DRAM init failed: %d\n", rv); + return rv; + } + + if (fdtdec_setup_memory_size() != 0) + rv = -EINVAL; + + return rv; +} + +int dram_init_banksize(void) +{ + fdtdec_setup_memory_banksize(); + + return 0; +} + +u32 get_board_rev(void) +{ + return 0; +} + +int board_early_init_f(void) +{ + return 0; +} + +int board_init(void) +{ + gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; + + return 0; +} + +#ifdef CONFIG_MISC_INIT_R +int misc_init_r(void) +{ + char serialno[25]; + u32 u_id_low, u_id_mid, u_id_high; + + if (!env_get("serial#")) { + u_id_low = readl(&STM32_U_ID->u_id_low); + u_id_mid = readl(&STM32_U_ID->u_id_mid); + u_id_high = readl(&STM32_U_ID->u_id_high); + sprintf(serialno, "%08x%08x%08x", + u_id_high, u_id_mid, u_id_low); + env_set("serial#", serialno); + } + + return 0; +} +#endif diff --git a/configs/stm32f429-evaluation_defconfig b/configs/stm32f429-evaluation_defconfig new file mode 100644 index 000..0d12fdb --- /dev/null +++ b/configs/stm32f429-evaluation_defconfig @@ -0,0 +1,31 @@ +CONFIG_ARM=y +CONFIG_STM32=y +CONFI
Re: [U-Boot] [PATCH 06/15] spl: fit: implement recording of loadables into /fit-images
Hi Philipp, 2017-09-13 21:29 GMT+02:00 Philipp Tomsich < philipp.toms...@theobroma-systems.com>: > If a FDT was loaded (e.g. to append it to U-Boot image), we store it's > address and record information for all loadables into this FDT. This > allows us to easily keep track of images for multiple privilege levels > (e.g. with ATF) or of firmware images preloaded into temporary > locations (e.g. PMU firmware that may overlap the SPL stage). > > Signed-off-by: Philipp Tomsich > --- > > common/spl/spl_fit.c | 95 ++ > ++ > 1 file changed, 81 insertions(+), 14 deletions(-) > > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c > index 9f05e1e..6dc0969 100644 > --- a/common/spl/spl_fit.c > +++ b/common/spl/spl_fit.c > @@ -2,7 +2,7 @@ > * Copyright (C) 2016 Google, Inc > * Written by Simon Glass > * > - * SPDX-License-Identifier: GPL-2.0+ > + * SPDX-License-Identifier:GPL-2.0+ > */ > > #include > @@ -16,22 +16,24 @@ > #endif > > /** > - * spl_fit_get_image_node(): By using the matching configuration subnode, > + * spl_fit_get_image_name(): By using the matching configuration subnode, > * retrieve the name of an image, specified by a property name and an > index > * into that. > * @fit: Pointer to the FDT blob. > * @images:Offset of the /images subnode. > * @type: Name of the property within the configuration subnode. > * @index: Index into the list of strings in this property. > + * @outname: Name of the image > * > - * Return: the node offset of the respective image node or a negative > - * error number. > + * Return: 0 on success, or a negative error number > */ > -static int spl_fit_get_image_node(const void *fit, int images, > - const char *type, int index) > +static int spl_fit_get_image_name(const void *fit, int images, > + const char *type, int index, > + char **outname) > { > const char *name, *str; > - int node, conf_node; > + __maybe_unused int node; > + int conf_node; > int len, i; > > conf_node = fit_find_config_node(fit); > @@ -63,7 +65,35 @@ static int spl_fit_get_image_node(const void *fit, int > images, > } > } > > + *outname = (char *)str; > + return 0; > +} > + > +/** > + * spl_fit_get_image_node(): By using the matching configuration subnode, > + * retrieve the name of an image, specified by a property name and an > index > + * into that. > + * @fit: Pointer to the FDT blob. > + * @images:Offset of the /images subnode. > + * @type: Name of the property within the configuration subnode. > + * @index: Index into the list of strings in this property. > + * > + * Return: the node offset of the respective image node or a negative > + * error number. > + */ > +static int spl_fit_get_image_node(const void *fit, int images, > + const char *type, int index) > +{ > + char *str; > + int err; > + int node; > + > + err = spl_fit_get_image_name(fit, images, type, index, &str); > + if (err) > + return err; > + > debug("%s: '%s'\n", type, str); > + > node = fdt_subnode_offset(fit, images, str); > if (node < 0) { > debug("cannot find image node '%s': %d\n", str, node); > @@ -116,15 +146,15 @@ static int get_aligned_image_size(struct > spl_load_info *info, int data_size, > * @info: points to information about the device to load data from > * @sector:the start sector of the FIT image on the device > * @fit: points to the flattened device tree blob describing the FIT > - * image > + * image > * @base_offset: the beginning of the data area containing the actual > * image data, relative to the beginning of the FIT > * @node: offset of the DT node describing the image to load > (relative > - * to @fit) > + * to @fit) > * @image_info:will be filled with information about the loaded > image > - * If the FIT node does not contain a "load" (address) > property, > - * the image gets loaded to the address pointed to by the > - * load_addr member in this struct. > + * If the FIT node does not contain a "load" (address) > property, > + * the image gets loaded to the address pointed to by the > + * load_addr member in this struct. > * > * Return: 0 on success or a negative error number. > */ > @@ -236,6 +266,35 @@ static int spl_fit_append_fdt(struct spl_image_info > *spl_image, > image_info.load_addr = spl_image->load_addr + spl_image->size; > ret = spl_load_fit_image(info, sector, fit, base_offset, node, > &image_info); > + > + if (re
Re: [U-Boot] [PATCH v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11
On Thu, Jan 18, 2018 at 09:43:33AM +0530, Pankaj Bansal wrote: > The current GPL only licensing on the device trees makes it very > impractical for other software components licensed under another > license. > > To make it easier to reuse them, re-license the the device trees for > Freescale (now NXP) SoCs and boards under GPLv2+/X11 dual license. > > Same trend is followed in linux. > > Cc: Priyanka Jain > Cc: Mingkai Hu > Cc: York Sun > Signed-off-by: Pankaj Bansal > --- > > Notes: > V2: > - Change license from X11 only to GPL2.0+/X11 dual license. > - Updated the commit message accordingly. OK. But what does the kernel have for these exact files? If it's GPL2.0+/X11 dual, then this is just a normal sync with Linux Kernel v4.xx and you should say that in the commit message. If you haven't gotten these merged to a Linux Kernel release, are they in -next there? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] STM32: Remove STMMAC clock setup from board
From: Patrice Chotard As STMMAC designware driver is now able to get and enable STMMAC clocks, we can remove code related to STMMAC clock setup in board and in clk_stm32f driver. Set SYSCFG clock directly in configure_clocks() Add missing STMMAC clocks in stm32f746 dts file. v2: _ patch 3: update commit message and add missing compilation flag. Patrice Chotard (3): ARM: dts: stm32: Add STMMAC clocks for stm32f746 clk: clk_stm32f: Remove STMMAC clock setup clk: clk_stm32f: Move SYSCFG clock setup into configure_clocks() arch/arm/dts/stm32f746.dtsi | 3 +++ arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 2 -- board/st/stm32f746-disco/stm32f746-disco.c | 20 ++-- drivers/clk/clk_stm32f.c | 18 ++ 4 files changed, 15 insertions(+), 28 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] clk: clk_stm32f: Remove STMMAC clock setup
From: Patrice Chotard Thanks to 'commit ba1f96672522 ("net: designware: add clock support")' we don't need anymore to setup the STMMAC clock in board. Signed-off-by: Patrice Chotard Reviewed-by: Vikas Manocha --- v2: _ add Reviewed-by arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 1 - board/st/stm32f746-disco/stm32f746-disco.c | 1 - drivers/clk/clk_stm32f.c | 6 -- 3 files changed, 8 deletions(-) diff --git a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h index ae0faef..13f9c9b 100644 --- a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h +++ b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h @@ -23,7 +23,6 @@ enum periph_id { enum periph_clock { SYSCFG_CLOCK_CFG, TIMER2_CLOCK_CFG, - STMMAC_CLOCK_CFG, }; #endif /* __ASM_ARM_ARCH_PERIPH_H */ diff --git a/board/st/stm32f746-disco/stm32f746-disco.c b/board/st/stm32f746-disco/stm32f746-disco.c index 2e8aa86..58a5ef0 100644 --- a/board/st/stm32f746-disco/stm32f746-disco.c +++ b/board/st/stm32f746-disco/stm32f746-disco.c @@ -75,7 +75,6 @@ static int stmmac_setup(void) clock_setup(SYSCFG_CLOCK_CFG); /* Set >RMII mode */ STM32_SYSCFG->pmc |= SYSCFG_PMC_MII_RMII_SEL; - clock_setup(STMMAC_CLOCK_CFG); return 0; } diff --git a/drivers/clk/clk_stm32f.c b/drivers/clk/clk_stm32f.c index 63116e0..d0c7a90 100644 --- a/drivers/clk/clk_stm32f.c +++ b/drivers/clk/clk_stm32f.c @@ -90,7 +90,6 @@ enum periph_clock { SYSCFG_CLOCK_CFG, TIMER2_CLOCK_CFG, - STMMAC_CLOCK_CFG, }; struct stm32_clk_info stm32f4_clk_info = { @@ -359,11 +358,6 @@ void clock_setup(int peripheral) case TIMER2_CLOCK_CFG: setbits_le32(&STM32_RCC->apb1enr, RCC_APB1ENR_TIM2EN); break; - case STMMAC_CLOCK_CFG: - setbits_le32(&STM32_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_EN); - setbits_le32(&STM32_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_RX_EN); - setbits_le32(&STM32_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_TX_EN); - break; default: break; } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ARM: dts: stm32: Add STMMAC clocks for stm32f746
From: Patrice Chotard Add ETHMAC, ETHMACRX and ETHMACTX clocks for STMMAC. Signed-off-by: Patrice Chotard Reviewed-by: Vikas Manocha --- v2: _ add Reviewed-by arch/arm/dts/stm32f746.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi index 929bf82..46d148e 100644 --- a/arch/arm/dts/stm32f746.dtsi +++ b/arch/arm/dts/stm32f746.dtsi @@ -65,6 +65,9 @@ compatible = "st,stm32-dwmac"; reg = <0x40028000 0x8000>; reg-names = "stmmaceth"; + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(ETHMAC)>, +<&rcc 0 STM32F7_AHB1_CLOCK(ETHMACTX)>, +<&rcc 0 STM32F7_AHB1_CLOCK(ETHMACRX)>; interrupts = <61>, <62>; interrupt-names = "macirq", "eth_wake_irq"; snps,pbl = <8>; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] clk: clk_stm32f: Move SYSCFG clock setup into configure_clocks()
From: Patrice Chotard Move SYSCFG clock setup into configure_clocks() instead of calling clock_setup() from board file. As this clock is only needed in case of ethernet enabled and as both stm32f4 and stm32f7 are using the Designware ethernet IP, we use CONFIG_ETH_DESIGNWARE to only enable this clock if needed. Move the RMII setup from board_early_init_f() to board_init() to insure that RMII bit is set only when clock driver is initialized. Signed-off-by: Patrice Chotard --- v2: _ update commit message to explain the usage of CONFIG_ETH_DESIGNWARE flag. _ add missing CONFIG_ETH_DESIGNWARE compilation flag to enable SYSCFG clock only if ETH_DESIGNWARE is enabled on running board. arch/arm/include/asm/arch-stm32f7/stm32_periph.h | 1 - board/st/stm32f746-disco/stm32f746-disco.c | 19 ++- drivers/clk/clk_stm32f.c | 12 ++-- 3 files changed, 12 insertions(+), 20 deletions(-) diff --git a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h index 13f9c9b..7b8f66a 100644 --- a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h +++ b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h @@ -21,7 +21,6 @@ enum periph_id { }; enum periph_clock { - SYSCFG_CLOCK_CFG, TIMER2_CLOCK_CFG, }; diff --git a/board/st/stm32f746-disco/stm32f746-disco.c b/board/st/stm32f746-disco/stm32f746-disco.c index 58a5ef0..8da7028 100644 --- a/board/st/stm32f746-disco/stm32f746-disco.c +++ b/board/st/stm32f746-disco/stm32f746-disco.c @@ -69,23 +69,10 @@ int dram_init_banksize(void) return 0; } -#ifdef CONFIG_ETH_DESIGNWARE -static int stmmac_setup(void) -{ - clock_setup(SYSCFG_CLOCK_CFG); - /* Set >RMII mode */ - STM32_SYSCFG->pmc |= SYSCFG_PMC_MII_RMII_SEL; - - return 0; -} - int board_early_init_f(void) { - stmmac_setup(); - return 0; } -#endif #ifdef CONFIG_SPL_BUILD #ifdef CONFIG_SPL_OS_BOOT @@ -162,5 +149,11 @@ int board_late_init(void) int board_init(void) { gd->bd->bi_boot_params = gd->bd->bi_dram[0].start + 0x100; + +#ifdef CONFIG_ETH_DESIGNWARE + /* Set >RMII mode */ + STM32_SYSCFG->pmc |= SYSCFG_PMC_MII_RMII_SEL; +#endif + return 0; } diff --git a/drivers/clk/clk_stm32f.c b/drivers/clk/clk_stm32f.c index d0c7a90..2d557fd 100644 --- a/drivers/clk/clk_stm32f.c +++ b/drivers/clk/clk_stm32f.c @@ -67,8 +67,6 @@ #define RCC_DCKCFGRX_SDMMC1SEL BIT(28) #define RCC_DCKCFGR2_SDMMC2SEL BIT(29) -#define RCC_APB2ENR_SAI1EN BIT(22) - /* * RCC AHB1ENR specific definitions */ @@ -86,9 +84,9 @@ * RCC APB2ENR specific definitions */ #define RCC_APB2ENR_SYSCFGEN BIT(14) +#define RCC_APB2ENR_SAI1EN BIT(22) enum periph_clock { - SYSCFG_CLOCK_CFG, TIMER2_CLOCK_CFG, }; @@ -227,6 +225,11 @@ static int configure_clocks(struct udevice *dev) /* gate the SAI clock, needed for MMC 1&2 clocks */ setbits_le32(®s->apb2enr, RCC_APB2ENR_SAI1EN); +#ifdef CONFIG_ETH_DESIGNWARE + /* gate the SYSCFG clock, needed to set RMII ethernet interface */ + setbits_le32(®s->apb2enr, RCC_APB2ENR_SYSCFGEN); +#endif + return 0; } @@ -352,9 +355,6 @@ static int stm32_clk_enable(struct clk *clk) void clock_setup(int peripheral) { switch (peripheral) { - case SYSCFG_CLOCK_CFG: - setbits_le32(&STM32_RCC->apb2enr, RCC_APB2ENR_SYSCFGEN); - break; case TIMER2_CLOCK_CFG: setbits_le32(&STM32_RCC->apb1enr, RCC_APB1ENR_TIM2EN); break; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11
> -Original Message- > From: Tom Rini [mailto:tr...@konsulko.com] > Sent: Thursday, January 18, 2018 6:34 PM > To: Pankaj Bansal > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Varun Sethi > ; Leo Li ; Priyanka Jain > ; Mingkai Hu ; York Sun > > Subject: Re: [PATCH v2] ARM: dts: Freescale: re-license device tree files > under > GPLv2+/X11 > > On Thu, Jan 18, 2018 at 09:43:33AM +0530, Pankaj Bansal wrote: > > The current GPL only licensing on the device trees makes it very > > impractical for other software components licensed under another > > license. > > > > To make it easier to reuse them, re-license the the device trees for > > Freescale (now NXP) SoCs and boards under GPLv2+/X11 dual license. > > > > Same trend is followed in linux. > > > > Cc: Priyanka Jain > > Cc: Mingkai Hu > > Cc: York Sun > > Signed-off-by: Pankaj Bansal > > --- > > > > Notes: > > V2: > > - Change license from X11 only to GPL2.0+/X11 dual license. > > - Updated the commit message accordingly. > > OK. But what does the kernel have for these exact files? The exact same files in linux kernel are GPLv2 and X11 dual licensed. Here is an excerpt from fsl-ls1043a.dtsi * This file is dual-licensed: you can use it either under the terms * of the GPLv2 or the X11 license, at your option. Note that this dual * licensing only applies to this file, and not this project as a * whole. * > If it's GPL2.0+/X11 dual, then this is just a normal sync with Linux Kernel > v4.xx and > you should say that in the commit message. I mentioned in commit message "Same trend is followed in linux." > If you haven't gotten these merged to a Linux Kernel release, are they in > -next there? These changes are already in linux. > Thanks! > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/15] spl: fit: implement recording of loadables into /fit-images
Michal, > On 18 Jan 2018, at 13:56, Michal Simek wrote: > > Hi Philipp, > > > 2017-09-13 21:29 GMT+02:00 Philipp Tomsich > : > If a FDT was loaded (e.g. to append it to U-Boot image), we store it's > address and record information for all loadables into this FDT. This > allows us to easily keep track of images for multiple privilege levels > (e.g. with ATF) or of firmware images preloaded into temporary > locations (e.g. PMU firmware that may overlap the SPL stage). > > Signed-off-by: Philipp Tomsich > --- > > common/spl/spl_fit.c | 95 > > 1 file changed, 81 insertions(+), 14 deletions(-) > > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c > index 9f05e1e..6dc0969 100644 > --- a/common/spl/spl_fit.c > +++ b/common/spl/spl_fit.c > @@ -2,7 +2,7 @@ > * Copyright (C) 2016 Google, Inc > * Written by Simon Glass > * > - * SPDX-License-Identifier: GPL-2.0+ > + * SPDX-License-Identifier:GPL-2.0+ > */ > > #include > @@ -16,22 +16,24 @@ > #endif > > /** > - * spl_fit_get_image_node(): By using the matching configuration subnode, > + * spl_fit_get_image_name(): By using the matching configuration subnode, > * retrieve the name of an image, specified by a property name and an index > * into that. > * @fit: Pointer to the FDT blob. > * @images:Offset of the /images subnode. > * @type: Name of the property within the configuration subnode. > * @index: Index into the list of strings in this property. > + * @outname: Name of the image > * > - * Return: the node offset of the respective image node or a negative > - * error number. > + * Return: 0 on success, or a negative error number > */ > -static int spl_fit_get_image_node(const void *fit, int images, > - const char *type, int index) > +static int spl_fit_get_image_name(const void *fit, int images, > + const char *type, int index, > + char **outname) > { > const char *name, *str; > - int node, conf_node; > + __maybe_unused int node; > + int conf_node; > int len, i; > > conf_node = fit_find_config_node(fit); > @@ -63,7 +65,35 @@ static int spl_fit_get_image_node(const void *fit, int > images, > } > } > > + *outname = (char *)str; > + return 0; > +} > + > +/** > + * spl_fit_get_image_node(): By using the matching configuration subnode, > + * retrieve the name of an image, specified by a property name and an index > + * into that. > + * @fit: Pointer to the FDT blob. > + * @images:Offset of the /images subnode. > + * @type: Name of the property within the configuration subnode. > + * @index: Index into the list of strings in this property. > + * > + * Return: the node offset of the respective image node or a negative > + * error number. > + */ > +static int spl_fit_get_image_node(const void *fit, int images, > + const char *type, int index) > +{ > + char *str; > + int err; > + int node; > + > + err = spl_fit_get_image_name(fit, images, type, index, &str); > + if (err) > + return err; > + > debug("%s: '%s'\n", type, str); > + > node = fdt_subnode_offset(fit, images, str); > if (node < 0) { > debug("cannot find image node '%s': %d\n", str, node); > @@ -116,15 +146,15 @@ static int get_aligned_image_size(struct spl_load_info > *info, int data_size, > * @info: points to information about the device to load data from > * @sector:the start sector of the FIT image on the device > * @fit: points to the flattened device tree blob describing the FIT > - * image > + * image > * @base_offset: the beginning of the data area containing the actual > * image data, relative to the beginning of the FIT > * @node: offset of the DT node describing the image to load (relative > - * to @fit) > + * to @fit) > * @image_info:will be filled with information about the loaded image > - * If the FIT node does not contain a "load" (address) property, > - * the image gets loaded to the address pointed to by the > - * load_addr member in this struct. > + * If the FIT node does not contain a "load" (address) property, > + * the image gets loaded to the address pointed to by the > + * load_addr member in this struct. > * > * Return: 0 on success or a negative error number. > */ > @@ -236,6 +266,35 @@ static int spl_fit_append_fdt(struct spl_image_info > *spl_image, > image_info.load_addr = spl_image->load_addr + spl_image->size; > ret = spl_load_fit_image(info, sector, fit, base_offset, node, > &imag
Re: [U-Boot] [U-Boot, v6, 2/2] common: Generic firmware loader for file system
On Thu, Jan 18, 2018 at 03:42:14AM +, Chee, Tien Fong wrote: > On Tue, 2018-01-16 at 09:35 -0500, Tom Rini wrote: > > On Tue, Jan 16, 2018 at 07:58:00AM +, Chee, Tien Fong wrote: > > > > > > On Mon, 2018-01-15 at 11:36 -0500, Tom Rini wrote: > > > > > > > > On Wed, Dec 27, 2017 at 01:04:38PM +0800, tien.fong.c...@intel.co > > > > m > > > > wrote: > > > > > > > > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > > > This is file system generic loader which can be used to load > > > > > the file image from the storage into target such as memory. > > > > > The consumer driver would then use this loader to program > > > > > whatever, > > > > > ie. the FPGA device. > > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > Please add Lothar's Reviewed-by for v7. There's a number of > > > > minor > > > > checkpatch.pl issues that checkpatch.pl can in turn fixup itself, > > > > please > > > > correct them. > > > > > > > I have ran the checkpatch.pl on this patch, i didn't see any error. > > When I ran it, it was pointing out cases where you have: > > if (foo->bar != NULL) > > when you can just use: > > if (foo->bar) > > > It's weird for checkpatch.pl not showing the same. I would fix the code > with above example. That is odd. Are you running it from within the U-Boot tree? > > [snip] > > > > > > > > > > > > > > > > > diff --git a/common/fs_loader.c b/common/fs_loader.c > > > > > new file mode 100644 > > > > > index 000..56d29b6 > > > > > --- /dev/null > > > > > +++ b/common/fs_loader.c > > > > > @@ -0,0 +1,309 @@ > > > > > +/* > > > > > + * Copyright (C) 2017 Intel Corporation > > > > > + * > > > > > + * SPDX-License-Identifier:GPL-2.0 > > > > > + */ > > > > > + > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > This wants which is not globally available, so you > > > > need > > > > to > > > > come up with something here. At least making this Kconfig- > > > > enabled > > > > will > > > > be a start and perhaps OK for now. > > > > > > > I can enable the Kconfig, and put the caution about dependency on > > > in document. > > Well, you need to make that part of the code depend on CONFIG_SPL as > > SPL > > support requires to exist. Perhaps part of the code > > needs > > to be refactored to more easily deal with SPL not always being > > present? > > > How about i just move the whole enum { } from line 17 to line 35 in > asm/spl.h to fs.h, and then enum{} above replaced with #include ? > > asm/spl.h > -- > #if defined(CONFIG_ARCH_OMAP2PLUS) \ > || defined(CONFIG_EXYNOS4) || defined(CONFIG_EXYNOS5) \ > || defined(CONFIG_EXYNOS4210) > /* Platform-specific defines */ > #include > > #else > #include <-- replacement > #endif > [...] No, because that's still arch specific code and will blow up some platforms that do not have asm/spl.h at all and is still non-portable (look at the various asm/spl.h files that do exist for how BOOT_DEVICE_xxx is handled in different places). It's OK to restructure your code to have: #ifdef CONFIG_SPL #include ... SPL specific functions #endif -- 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 v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11
On Thu, Jan 18, 2018 at 01:15:55PM +, Pankaj Bansal wrote: > > > > -Original Message- > > From: Tom Rini [mailto:tr...@konsulko.com] > > Sent: Thursday, January 18, 2018 6:34 PM > > To: Pankaj Bansal > > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Varun Sethi > > ; Leo Li ; Priyanka Jain > > ; Mingkai Hu ; York Sun > > > > Subject: Re: [PATCH v2] ARM: dts: Freescale: re-license device tree files > > under > > GPLv2+/X11 > > > > On Thu, Jan 18, 2018 at 09:43:33AM +0530, Pankaj Bansal wrote: > > > The current GPL only licensing on the device trees makes it very > > > impractical for other software components licensed under another > > > license. > > > > > > To make it easier to reuse them, re-license the the device trees for > > > Freescale (now NXP) SoCs and boards under GPLv2+/X11 dual license. > > > > > > Same trend is followed in linux. > > > > > > Cc: Priyanka Jain > > > Cc: Mingkai Hu > > > Cc: York Sun > > > Signed-off-by: Pankaj Bansal > > > --- > > > > > > Notes: > > > V2: > > > - Change license from X11 only to GPL2.0+/X11 dual license. > > > - Updated the commit message accordingly. > > > > OK. But what does the kernel have for these exact files? > > The exact same files in linux kernel are GPLv2 and X11 dual licensed. Here is > an excerpt from fsl-ls1043a.dtsi > * This file is dual-licensed: you can use it either under the terms > * of the GPLv2 or the X11 license, at your option. Note that this dual > * licensing only applies to this file, and not this project as a > * whole. > * OK, good. > > If it's GPL2.0+/X11 dual, then this is just a normal sync with Linux Kernel > > v4.xx and > > you should say that in the commit message. > > I mentioned in commit message "Same trend is followed in linux." > > > If you haven't gotten these merged to a Linux Kernel release, are they in > > -next there? > > These changes are already in linux. OK, good. But there's http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign and you need to say what kernel you're syncing this file against (since there shouldn't be anything U-Boot specific in any of these files) so it's clear for the next person to come along and sync them. 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] x86: 64-bit U-boot image compilation errors
Hello, I am having issues getting a 64bit image compiled. Every avenue I've tried, ends with a compilation error. I need a x86 U-boot 64 bit image to load as the EFI shell is 64-bit. Any help would be greatly appreciated. Path 1: scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h CFG u-boot.cfg In file included from ./include/common.h:21:0: include/config.h:5:22: fatal error: configs/.h: No such file or directory #include Path 2: arch/x86/cpu/x86_64/built-in.o: In function `checkcpu': /home/damir.krehic/uboot/u-boot/arch/x86/cpu/x86_64/cpu.c:73: multiple definition of `checkcpu' arch/x86/cpu/efi/built-in.o:/home/damir.krehic/uboot/u-boot/arch/x86/cpu/efi/efi.c:19: first defined here arch/x86/cpu/x86_64/built-in.o: In function `arch_setup_gd': /home/damir.krehic/uboot/u-boot/arch/x86/cpu/x86_64/cpu.c:18: multiple definition of `misc_init_r' arch/x86/cpu/efi/built-in.o:/home/damir.krehic/uboot/u-boot/arch/x86/cpu/efi/efi.c:14: first defined here arch/x86/cpu/x86_64/built-in.o: In function `arch_setup_gd': /home/damir.krehic/uboot/u-boot/arch/x86/cpu/x86_64/cpu.c:18: multiple definition of `print_cpuinfo' arch/x86/cpu/efi/built-in.o:/home/damir.krehic/uboot/u-boot/arch/x86/cpu/efi/efi.c:14: first defined here make[1]: *** [arch/x86/cpu/built-in.o] Error 1 make: *** [arch/x86/cpu] Error 2 settings for the configs/efi-x86_defconfig: CONFIG_X86=y CONFIG_VENDOR_EFI=y CONFIG_DEFAULT_DEVICE_TREE="efi" CONFIG_TARGET_EFI=y CONFIG_DEBUG_UART=y CONFIG_FIT=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_HUSH_PARSER=y # CONFIG_CMD_BOOTM is not set CONFIG_CMD_GPIO=y CONFIG_CMD_PART=y CONFIG_CMD_SF=y # CONFIG_CMD_SF_TEST is not set CONFIG_CMD_SPI=y CONFIG_CMD_USB=y # CONFIG_CMD_NET is not set CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y CONFIG_ISO_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_OF_EMBED=y # CONFIG_DM_ETH is not set CONFIG_DEBUG_EFI_CONSOLE=y CONFIG_DEBUG_UART_BASE=0 CONFIG_DEBUG_UART_CLOCK=0 CONFIG_ICH_SPI=y CONFIG_EFI=y # CONFIG_EFI_LOADER is not set ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: dts: Freescale: re-license device tree files under X11
> -Original Message- > From: Pankaj Bansal > Sent: Monday, January 15, 2018 11:06 PM > To: Leo Li > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Tom Rini > ; Priyanka Jain ; Varun Sethi > ; Mingkai Hu > Subject: RE: [U-Boot] [PATCH] ARM: dts: Freescale: re-license device tree > files under X11 > > ++ Leo > > Hi Leo. Can you please reply to this question ? > > > -Original Message- > > From: Tom Rini [mailto:tr...@konsulko.com] > > Sent: Tuesday, January 16, 2018 8:59 AM > > To: Pankaj Bansal > > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain > > ; Varun Sethi ; Mingkai Hu > > > > Subject: Re: [U-Boot] [PATCH] ARM: dts: Freescale: re-license device > > tree files under X11 > > > > On Tue, Jan 16, 2018 at 03:27:09AM +, Pankaj Bansal wrote: > > > HI, > > > > > > > -Original Message- > > > > From: Tom Rini [mailto:tr...@konsulko.com] > > > > Sent: Tuesday, January 16, 2018 8:32 AM > > > > To: Pankaj Bansal > > > > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain > > > > ; Varun Sethi ; Mingkai > Hu > > > > > > > > Subject: Re: [U-Boot] [PATCH] ARM: dts: Freescale: re-license > > > > device tree files under X11 > > > > > > > > On Tue, Jan 16, 2018 at 08:03:54AM +0530, Pankaj Bansal wrote: > > > > > > > > > The current GPL only licensing on the device trees makes it very > > > > > impractical for other software components licensed under another > > > > > license. > > > > > > > > > > To make it easier to reuse them, re-license the the device trees > > > > > for Freescale (now NXP) SoCs and boards under license X11. > > > > > > > > > > Cc: Priyanka Jain > > > > > Cc: Mingkai Hu > > > > > Cc: York Sun > > > > > Signed-off-by: Pankaj Bansal > > > > > --- > > > > > arch/arm/dts/fsl-ls1012a-frdm.dts | 2 +- > > > > > arch/arm/dts/fsl-ls1012a-frdm.dtsi | 2 +- > > > > > arch/arm/dts/fsl-ls1012a-qds.dts| 2 +- > > > > > arch/arm/dts/fsl-ls1012a-qds.dtsi | 2 +- > > > > > arch/arm/dts/fsl-ls1012a-rdb.dts| 2 +- > > > > > arch/arm/dts/fsl-ls1012a-rdb.dtsi | 4 +--- > > > > > arch/arm/dts/fsl-ls1012a.dtsi | 2 +- > > > > > arch/arm/dts/fsl-ls1043a-qds-duart.dts | 2 +- > > > > > arch/arm/dts/fsl-ls1043a-qds-lpuart.dts | 2 +- > > > > > arch/arm/dts/fsl-ls1043a-qds.dtsi | 4 +--- > > > > > arch/arm/dts/fsl-ls1043a-rdb.dts| 4 +--- > > > > > arch/arm/dts/fsl-ls1043a.dtsi | 4 +--- > > > > > arch/arm/dts/fsl-ls1046a-qds-duart.dts | 2 +- > > > > > arch/arm/dts/fsl-ls1046a-qds-lpuart.dts | 2 +- > > > > > arch/arm/dts/fsl-ls1046a-qds.dtsi | 4 +--- > > > > > arch/arm/dts/fsl-ls1046a-rdb.dts| 4 +--- > > > > > arch/arm/dts/fsl-ls1046a.dtsi | 4 +--- > > > > > arch/arm/dts/fsl-ls1088a-qds.dts| 2 +- > > > > > arch/arm/dts/fsl-ls1088a-rdb.dts| 2 +- > > > > > arch/arm/dts/fsl-ls1088a.dtsi | 2 +- > > > > > arch/arm/dts/fsl-ls2080a-qds.dts| 2 +- > > > > > arch/arm/dts/fsl-ls2080a-rdb.dts| 2 +- > > > > > arch/arm/dts/fsl-ls2080a.dtsi | 2 +- > > > > > arch/arm/dts/fsl-ls2081a-rdb.dts| 2 +- > > > > > arch/arm/dts/fsl-ls2088a-rdb-qspi.dts | 2 +- > > > > > 25 files changed, 25 insertions(+), 39 deletions(-) > > > > > > > > How do these changes match up to the kernel? Thanks! > > > > > > The kernel dts files are GPLv2 and X11 dual licensed. E.g. > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable. > > > gi t/tree/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > > > > > To avoid dual licensing, we used X11 only. See > > > https://www.gnu.org/licenses/license-list.en.html#X11License > > > > Why would we not want to match the kernel here? As we are working with Qualcomm for the potential acquisition, their legal team mentioned that they are against using dual license. So as we are updating the license we would like to take that concern too. Regards, Leo ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] UDP packet sender
Hi, I would like to implement a new command and submit it to the mailing list. The command will have the following format: udpsend udpsend 255.255.255.255 4040 0 hello world If source port is 0, a random port will be used (11000 + (get_timer(0) % 4096)) Where do I have to place my code : cmd or net directory ? For me cmd will be the better directory to keep it away from all more complex stuff like DHCP, TFTP, ... Thank you for these informations. Regards, Gaëtan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/15] spl: fit: implement recording of loadables into /fit-images
On 18.1.2018 14:17, Dr. Philipp Tomsich wrote: > Michal, > >> On 18 Jan 2018, at 13:56, Michal Simek wrote: >> >> Hi Philipp, >> >> >> 2017-09-13 21:29 GMT+02:00 Philipp Tomsich >> : >> If a FDT was loaded (e.g. to append it to U-Boot image), we store it's >> address and record information for all loadables into this FDT. This >> allows us to easily keep track of images for multiple privilege levels >> (e.g. with ATF) or of firmware images preloaded into temporary >> locations (e.g. PMU firmware that may overlap the SPL stage). >> >> Signed-off-by: Philipp Tomsich >> --- >> >> common/spl/spl_fit.c | 95 >> >> 1 file changed, 81 insertions(+), 14 deletions(-) >> >> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c >> index 9f05e1e..6dc0969 100644 >> --- a/common/spl/spl_fit.c >> +++ b/common/spl/spl_fit.c >> @@ -2,7 +2,7 @@ >> * Copyright (C) 2016 Google, Inc >> * Written by Simon Glass >> * >> - * SPDX-License-Identifier: GPL-2.0+ >> + * SPDX-License-Identifier:GPL-2.0+ >> */ >> >> #include >> @@ -16,22 +16,24 @@ >> #endif >> >> /** >> - * spl_fit_get_image_node(): By using the matching configuration subnode, >> + * spl_fit_get_image_name(): By using the matching configuration subnode, >> * retrieve the name of an image, specified by a property name and an index >> * into that. >> * @fit: Pointer to the FDT blob. >> * @images:Offset of the /images subnode. >> * @type: Name of the property within the configuration subnode. >> * @index: Index into the list of strings in this property. >> + * @outname: Name of the image >> * >> - * Return: the node offset of the respective image node or a negative >> - * error number. >> + * Return: 0 on success, or a negative error number >> */ >> -static int spl_fit_get_image_node(const void *fit, int images, >> - const char *type, int index) >> +static int spl_fit_get_image_name(const void *fit, int images, >> + const char *type, int index, >> + char **outname) >> { >> const char *name, *str; >> - int node, conf_node; >> + __maybe_unused int node; >> + int conf_node; >> int len, i; >> >> conf_node = fit_find_config_node(fit); >> @@ -63,7 +65,35 @@ static int spl_fit_get_image_node(const void *fit, int >> images, >> } >> } >> >> + *outname = (char *)str; >> + return 0; >> +} >> + >> +/** >> + * spl_fit_get_image_node(): By using the matching configuration subnode, >> + * retrieve the name of an image, specified by a property name and an index >> + * into that. >> + * @fit: Pointer to the FDT blob. >> + * @images:Offset of the /images subnode. >> + * @type: Name of the property within the configuration subnode. >> + * @index: Index into the list of strings in this property. >> + * >> + * Return: the node offset of the respective image node or a negative >> + * error number. >> + */ >> +static int spl_fit_get_image_node(const void *fit, int images, >> + const char *type, int index) >> +{ >> + char *str; >> + int err; >> + int node; >> + >> + err = spl_fit_get_image_name(fit, images, type, index, &str); >> + if (err) >> + return err; >> + >> debug("%s: '%s'\n", type, str); >> + >> node = fdt_subnode_offset(fit, images, str); >> if (node < 0) { >> debug("cannot find image node '%s': %d\n", str, node); >> @@ -116,15 +146,15 @@ static int get_aligned_image_size(struct spl_load_info >> *info, int data_size, >> * @info: points to information about the device to load data from >> * @sector:the start sector of the FIT image on the device >> * @fit: points to the flattened device tree blob describing the FIT >> - * image >> + * image >> * @base_offset: the beginning of the data area containing the actual >> * image data, relative to the beginning of the FIT >> * @node: offset of the DT node describing the image to load (relative >> - * to @fit) >> + * to @fit) >> * @image_info:will be filled with information about the loaded >> image >> - * If the FIT node does not contain a "load" (address) property, >> - * the image gets loaded to the address pointed to by the >> - * load_addr member in this struct. >> + * If the FIT node does not contain a "load" (address) property, >> + * the image gets loaded to the address pointed to by the >> + * load_addr member in this struct. >> * >> * Return: 0 on success or a negative error number. >> */ >> @@ -236,6 +266,35 @@ static int spl_fit_append_fdt(struct spl_image_info >> *spl_image, >> image
Re: [U-Boot] Please pull u-boot-fsl-qoriq master
On Wed, Jan 17, 2018 at 06:33:26PM +, York Sun wrote: > Tom, > > The following changes since commit 3dde8f20377c3a051dda64497bdf0cdb23e03a2d: > > Merge git://git.denx.de/u-boot-mmc (2018-01-14 22:26:38 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-fsl-qoriq.git > > for you to fetch changes up to 2eb2dbd4577898bf289e911b2286df3f2363af6e: > > armv8: ls1088ardb: Add environment variable address location for > QSPI-NOR (2018-01-17 10:30:54 -0800) > Applied to u-boot/master, thanks! -- 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 v3 0/6] arm: ti: misc updates and bug fixes
On Thursday 28 December 2017 08:39 PM, Lokesh Vutla wrote: > This series consolidates few bug fixes on TI platforms. Gentle Ping. If there are no further comments, can this series be merged ? Thanks and regards, Lokesh > > Changes since v2: > - Added a new patch for making in file structures static. > > Lokesh Vutla (4): > configs: k2g_evm: Allocate more space for u-boot > tools: omapimage: Fix mismatch of image size in header > arm: am33xx: Avoid writing into reserved DPLL divider > board: ti: k2g: Make ddr3* declarations as static > > Rex Chang (1): > board: ti: K2G FC SoC 1GHz and DDR3 1066 MT/s support > > Tomi Valkeinen (1): > board: ti: dra76: mux wakeup2 as gpio1_2 > > arch/arm/mach-keystone/include/mach/hardware.h | 3 ++ > arch/arm/mach-keystone/init.c | 17 ++- > arch/arm/mach-omap2/am33xx/clock_am33xx.c | 12 ++--- > board/ti/dra7xx/mux_data.h | 2 +- > board/ti/ks2_evm/board.h | 4 ++ > board/ti/ks2_evm/board_k2g.c | 32 ++--- > board/ti/ks2_evm/ddr3_k2g.c| 65 > +++--- > board/ti/ks2_evm/mux-k2g.h | 2 +- > include/configs/k2g_evm.h | 6 ++- > tools/omapimage.c | 2 +- > 10 files changed, 119 insertions(+), 26 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/13] arm: am57xx: Add support for am574-idk
On Friday 29 December 2017 11:47 AM, Lokesh Vutla wrote: > am574x-idk board is similar to am572x-idk with am574x SoC. > This series adds support for this board. Gentle Ping. If there are no further comments, can this series be merged ? Thanks and regards, Lokesh > > Changes since v1: > - Moved cmd_ddr3 to cmd/ti/ > > Lokesh Vutla (12): > arm: emif-common: Add ecc specific emif registers > arm: emif-common: Add suppport for enabling ECC > arm: keystone: Move cmd_ddr3 to a common place > cmd: ti: Generalize cmd_ddr3 command > arm: dra762: Add support for device package identification > board: ti: am574x-idk: Add epprom support > board: ti: am574x-idk: Add hw data support > board: ti: am574x-idk: Add ddr data support > board: ti: am574x-idk: Update pinmux using latest PMT > board: ti: am57xx: Enable CMD_DDR3 > ARM: dts: am574x-idk: Add initial support > env: ti: Select dtb name for dra76x and am574 > > Tero Kristo (1): > drivers: dma: ti-edma3: add support for memory fill > > arch/arm/dts/Makefile | 1 + > arch/arm/dts/am572x-idk-common.dtsi| 100 + > arch/arm/dts/am572x-idk.dts| 93 +--- > arch/arm/dts/am574x-idk.dts| 22 ++ > arch/arm/dts/am57xx-commercial-grade.dtsi | 1 + > arch/arm/dts/am57xx-industrial-grade.dtsi | 1 + > arch/arm/include/asm/arch-omap5/omap.h | 3 + > arch/arm/include/asm/arch-omap5/sys_proto.h| 1 + > arch/arm/include/asm/emif.h| 50 - > arch/arm/include/asm/omap_common.h | 15 ++ > arch/arm/include/asm/ti-common/ti-edma3.h | 2 + > arch/arm/mach-keystone/Kconfig | 4 + > arch/arm/mach-keystone/Makefile| 1 - > arch/arm/mach-keystone/include/mach/hardware.h | 1 + > arch/arm/mach-omap2/emif-common.c | 95 +++- > arch/arm/mach-omap2/hwinit-common.c| 33 ++- > arch/arm/mach-omap2/omap5/Kconfig | 1 + > arch/arm/mach-omap2/omap5/hw_data.c| 4 + > arch/arm/mach-omap2/omap5/hwinit.c | 21 ++ > arch/arm/mach-omap2/omap5/sdram.c | 4 + > board/ti/am57xx/board.c| 66 +- > board/ti/am57xx/mux_data.h | 299 > + > board/ti/dra7xx/evm.c | 17 +- > cmd/Kconfig| 2 + > cmd/Makefile | 1 + > cmd/ti/Kconfig | 10 + > cmd/ti/Makefile| 10 + > {arch/arm/mach-keystone => cmd/ti}/cmd_ddr3.c | 155 ++--- > configs/am57xx_evm_defconfig | 2 +- > configs/am57xx_hs_evm_defconfig| 2 +- > drivers/dma/ti-edma3.c | 55 - > include/environment/ti/boot.h | 4 +- > 32 files changed, 924 insertions(+), 152 deletions(-) > create mode 100644 arch/arm/dts/am572x-idk-common.dtsi > create mode 100644 arch/arm/dts/am574x-idk.dts > create mode 100644 cmd/ti/Kconfig > create mode 100644 cmd/ti/Makefile > rename {arch/arm/mach-keystone => cmd/ti}/cmd_ddr3.c (58%) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11
Hi Tom > -Original Message- > From: Tom Rini [mailto:tr...@konsulko.com] > Sent: Thursday, January 18, 2018 6:54 PM > To: Pankaj Bansal > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Varun Sethi > ; Leo Li ; Priyanka Jain > ; Mingkai Hu ; York Sun > > Subject: Re: [PATCH v2] ARM: dts: Freescale: re-license device tree files > under > GPLv2+/X11 > > On Thu, Jan 18, 2018 at 01:15:55PM +, Pankaj Bansal wrote: > > > > > > > -Original Message- > > > From: Tom Rini [mailto:tr...@konsulko.com] > > > Sent: Thursday, January 18, 2018 6:34 PM > > > To: Pankaj Bansal > > > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Varun Sethi > > > ; Leo Li ; Priyanka Jain > > > ; Mingkai Hu ; York Sun > > > > > > Subject: Re: [PATCH v2] ARM: dts: Freescale: re-license device tree > > > files under > > > GPLv2+/X11 > > > > > > On Thu, Jan 18, 2018 at 09:43:33AM +0530, Pankaj Bansal wrote: > > > > The current GPL only licensing on the device trees makes it very > > > > impractical for other software components licensed under another > > > > license. > > > > > > > > To make it easier to reuse them, re-license the the device trees > > > > for Freescale (now NXP) SoCs and boards under GPLv2+/X11 dual > license. > > > > > > > > Same trend is followed in linux. > > > > > > > > Cc: Priyanka Jain > > > > Cc: Mingkai Hu > > > > Cc: York Sun > > > > Signed-off-by: Pankaj Bansal > > > > --- > > > > > > > > Notes: > > > > V2: > > > > - Change license from X11 only to GPL2.0+/X11 dual license. > > > > - Updated the commit message accordingly. > > > > > > OK. But what does the kernel have for these exact files? > > > > The exact same files in linux kernel are GPLv2 and X11 dual licensed. > > Here is an excerpt from fsl-ls1043a.dtsi > > * This file is dual-licensed: you can use it either under the terms > > * of the GPLv2 or the X11 license, at your option. Note that this > > dual > > * licensing only applies to this file, and not this project as a > > * whole. > > * > > OK, good. > > > > If it's GPL2.0+/X11 dual, then this is just a normal sync with Linux > > > Kernel v4.xx and you should say that in the commit message. > > > > I mentioned in commit message "Same trend is followed in linux." > > > > > If you haven't gotten these merged to a Linux Kernel release, are they in > > > - > next there? > > > > These changes are already in linux. > > OK, good. But there's > http://www.denx.de/wiki/view/U- > Boot/Patches#Attributing_Code_Copyrights_Sign > and you need to say what kernel you're syncing this file against (since there > shouldn't be anything U-Boot specific in any of these files) so it's clear > for the > next person to come along and sync them. Thanks! > I am not syncing the files from linux to u-boot. I am just changing the license similar to commit 13b2ba1a11. There is no functional change in the commit. > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx6memcal: launder through savedefconfig
This patch just changes the order of configuration items in mx6memcal_defconfig to match the Kconfig layout, making it easier to track changes made using menuconfig. Signed-off-by: Eric Nelson --- configs/mx6memcal_defconfig | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig index 9a3bb83..b27330c 100644 --- a/configs/mx6memcal_defconfig +++ b/configs/mx6memcal_defconfig @@ -9,25 +9,24 @@ CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL,MX6QDL" CONFIG_SPL=y CONFIG_HUSH_PARSER=y -# CONFIG_MMC is not set # CONFIG_CMD_BOOTD is not set # CONFIG_CMD_BOOTM is not set # CONFIG_CMD_ELF is not set # CONFIG_CMD_IMI is not set -# CONFIG_CMD_IMLS is not set # CONFIG_CMD_XIMG is not set # CONFIG_CMD_EXPORTENV is not set # CONFIG_CMD_IMPORTENV is not set # CONFIG_CMD_EDITENV is not set # CONFIG_CMD_SAVEENV is not set # CONFIG_CMD_ENV_EXISTS is not set -CONFIG_CMD_MEMTEST=y CONFIG_CMD_MEMINFO=y -# CONFIG_CMD_LOADB is not set -# CONFIG_CMD_LOADS is not set +CONFIG_CMD_MEMTEST=y # CONFIG_CMD_FLASH is not set # CONFIG_CMD_FPGA is not set +# CONFIG_CMD_LOADB is not set +# CONFIG_CMD_LOADS is not set # CONFIG_CMD_NET is not set # CONFIG_CMD_NFS is not set CONFIG_CMD_CACHE=y +# CONFIG_MMC is not set CONFIG_REGEX=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Broadwell-DE booting time
Hi Bin, To avoid top-posting I will send another email. Basically my Broadwell-DE implementation work, on both Camelback mountain CRB (DIMM memory) and our custom design product (memory down). I can't submit the patch to U-Boot because in both cases the booting process takes 1 hour and 20 minutes and there are no errors in the log. The platform takes lot of time to boot when it reach "DDRIO Initialization". I have attached the boot log if it may help, and my source-code is available here: https://github.com/WarOfDevil/u-boot.x86_64-broadwell-de Thanks in advance! Vincenzo Sent with [ProtonMail](https://protonmail.com) Secure Email.= PEIM FSP v1.0 (_BDX-DE_ v0.0.3.2) = Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3 Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A The 0th FV start address is 0x000FFEB1000, size is 0x0011F000, handle is 0x0 Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38 Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6 Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389 Loading PEIM at 0x000FFEB8638 EntryPoint=0x000FFEB8CF0 Install PPI: 06E81C58-4AD7-44BC-8390-F10265F72480 Install PPI: 01F34D25-4DE2-23AD-3FF3-36353FF323F1 Loading PEIM at 0x000FFEBB080 EntryPoint=0x000FFEBC6D4 Install PPI: 57B195D1-E14B-40AD-A68F-9806000C436A Loading PEIM at 0x000FFEBCA2C EntryPoint=0x000FFEBD000 enable all DMI VCx :: CPU Type Socket ModelId# 56 :: CPU stepping # 1 Install PPI: 1E2ACC41-E26A-483D-AFC7-A056C34E087B Publish PlatformInfoPPI Loading PEIM at 0x000FFEBE6BC EntryPoint=0x000FFEBEC24 Install PPI: 7AE3CEB7-2EE2-48FA-AA49-3510BC83CABF ME PEI Platform Policy PPI Installed Loading PEIM at 0x000FFEBFBEC EntryPoint=0x000FFEC04F8 Force an S5 exit path. Install PPI: E5EE2066-FAA1-4DFA-924E-B1E3A8EE30E8 Install PPI: EE0EA811-FBD9-4777-B95A-BA4F71101F74 Loading PEIM at 0x000FFEC247C EntryPoint=0x000FFEC33E4 Install PPI: 8C376010-2400-4D7D-B47B-9D851DF3C9D1 ME UMA: ME UMA PPI Installed Loading PEIM at 0x000FFEC5064 EntryPoint=0x000FFEC5CD4 [SPS] Waiting for ME firmware init complete [SPS] WARNING: ME is in recovery mode (cause: 3) [HECI-0] VID-DID: 8086-8C3A [HECI-0] MBAR not programmed, using default 0xFEDB [SPS] Sending ME-BIOS Interface Version request [HECI-0] Send msg: 80010020 [HECI-0] Got msg: 80050020 [SPS] SPS ME-BIOS interface version is 1.0 Feature set is 0x [SPS] HOB: features 0x00, flow 1, boot mode 0, cores to disable 0 Loading PEIM at 0x000FFEC7B2C EntryPoint=0x000FFEF4044 OVERRIDING TOTAL SYSTEM CONFIGURATION WITH UPD upd->MemDdr4Platform = 0x0 tsc->DDR4Platform = 0x2 Halting the TCO Timer (Watchdog) FastBoot is not supported on this SKU. Running on hardware Revision: 0 BIOSSIM: InitHeap() BIOSSIM: InitUSBDebug() BDX (1HA) processor detected CPU Stepping 1 Found CCMRC Version: 0050 MRC Sync Number: 244071 RC Version: 0200 host = FE191770 (pointer to sysHost structure) Legacy Serial Debug Enabled QPI Init starting... *** QPI Setup Structure *** PPINrOptIn: 0 Bus Ratio: 1 1 1 1 IORatio: 1 1 1 1 MMIOL Ratio: 1 1 1 1 LegacyVgaSoc: 0 MmioP2pDis: 0 IsocAzaliaVc1En: 0 DebugPrintLevel: 15 ClusterOnDieEn: 0 IBPECIEn: 1 E2EParityEn: 0 EarlySnoopEn: 1 HomeDirWOSBEn: 1 DegradePrecedence: 0 QpiLinkSpeedMode: 1 (FAST) QpiLinkSpeed: 6 QpiLinkL0pEn: 1 QpiLinkL1En: 1 QpiLinkL0rEn: 1 QpiLbEn: 0 IioUniphyDisable (per socket): 0 0 0 0 QpiLinkCreditReduce: 2 QpiConfigTxWci: 11 QpiCrcMode: 0 QpiCpuSktHotPlugEn: 0 QpiCpuSktHotPlugTopology: 0 QpiSkuMismatchCheck: 1 QpiPortDisable (per port): S0:0 0 S1:0 0 S2:0 0 S3:0 0 QpiLinkCreditReduce (per port): S0:0 0 S1:0 0 S2:0 0 S3:0 0 QpiLinkSpeed (per port): S0:6 6 S1:6 6 S2:6 6 S3:6 6 QpiProbeType (per port): S0:0 0 S1:0 0 S2:0 0 S3:0 0 QpiConfigTxWci (per port): S0:11 11 S1:11 11 S2:11 11 S3:11 11 Rsvd (per port): S0:0 0 S1:0 0 S2:0 0 S3:0 0 *** Common Setup Structure *** mmCfgBase: 0x8000 mmCfgSize: 0x1000 mmiolBase: 0x9000 mmiolSize: 0x6C00 mmiohBase: 0x3800- mmiohSize: 256 GB numaEn: 1 isocEn: 0 mesegEn: 0 dcaEn: 1 *** Common Var Structure *** resetRequired: 0 state: 0 numCpus: 0 socketPresentBitMap: 0x01 busIio: 0x00 0x00 0x00 0x00 busUncore: 0x3F 0x00 0x00 0x00 mmCfgBase: 0x8000 ;*** Collecting Early System Information - START *** CAPID0[5] is set. SKU Detected as DE. SocketId: 0Physical Chop: 3 SocketId: 0CAPID5: 0x06000B6D SocketId: 0CAPID4: 0x24080F02 SocketId: 0CAPID3: 0x009B0220 SocketId: 0CAPID2: 0x53B4 SocketId: 0CAPID1: 0x8C83 SocketId: 0CAPID0: 0x00108120 ; SBSP Socket: 0 SKU: 0x05 SubSKU: 0x00 Stepping: 0x01 CAPID4[sbsp]: 0x24080F02 ; Total Cbos: 08 Cbo List: 0xB6D Total HA: 01 Total R3Qpi: 00 Total QpiAgent: 00 ; TotCpus: 4 C
Re: [U-Boot] [PATCH v2 03/15] env: Pass additional parameters to the env lookup function
On Wed, Jan 17, 2018 at 03:03:40PM -0700, Simon Glass wrote: > Hi Maxime, > > On 16 January 2018 at 01:16, Maxime Ripard > wrote: > > In preparation for the multiple environment support, let's introduce two > > new parameters to the environment driver lookup function: the priority and > > operation. > > > > The operation parameter is meant to identify, obviously, the operation you > > might want to perform on the environment. > > > > The priority is a number passed to identify the environment priority you > > want to retrieve. The lowest priority parameter (0) will be the primary > > source. > > > > Combining the two parameters allow you to support multiple environments > > through different priorities, and to change those priorities between read > > and writes operations. > > > > This is especially useful to implement migration mechanisms where you want > > to always use the same environment first, be it to read or write, while the > > common case is more likely to use the same environment it has read from to > > write it to. > > > > Signed-off-by: Maxime Ripard > > --- > > env/env.c | 135 +++ > > include/environment.h | 8 +++- > > 2 files changed, 94 insertions(+), 49 deletions(-) > > > > diff --git a/env/env.c b/env/env.c > > index 97ada5b5a6fd..4dc39b384c1e 100644 > > --- a/env/env.c > > +++ b/env/env.c > > @@ -26,8 +26,11 @@ static struct env_driver *_env_driver_lookup(enum > > env_location loc) > > return NULL; > > } > > > > -static enum env_location env_get_location(void) > > +static enum env_location env_get_location(enum env_operation op, int prio) > > Please add a function comment, including why @op is needed. This was done in a later patch (the __weak one), but you're right that it makes more sense for it to be here. > > > { > > + if (prio >= 1) > > + return ENVL_UNKNOWN; > > What is this for? Can you please add a comment? Done, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6memcal: enable SDP support
The initial implementation of mx6memcal reset the CPU after running the memory calibration procedure because the generic board has no information about which boot devices are available. Now that we have SDP support in SPL, use it to allow a full U-Boot to be uploaded (i.e. to use "mtest"). Signed-off-by: Eric Nelson --- board/freescale/mx6memcal/spl.c | 1 - configs/mx6memcal_defconfig | 10 ++ include/configs/mx6memcal.h | 2 ++ 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/board/freescale/mx6memcal/spl.c b/board/freescale/mx6memcal/spl.c index 8ee89ff..805fdab 100644 --- a/board/freescale/mx6memcal/spl.c +++ b/board/freescale/mx6memcal/spl.c @@ -452,5 +452,4 @@ void board_init_f(ulong dummy) display_calibration(&calibration); } } - reset_cpu(0); } diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig index b27330c..d3720dc 100644 --- a/configs/mx6memcal_defconfig +++ b/configs/mx6memcal_defconfig @@ -8,6 +8,10 @@ CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL,MX6QDL" CONFIG_SPL=y +CONFIG_SPL_USB_HOST_SUPPORT=y +CONFIG_SPL_USB_GADGET_SUPPORT=y +CONFIG_SPL_USBETH_SUPPORT=y +CONFIG_SPL_USB_SDP_SUPPORT=y CONFIG_HUSH_PARSER=y # CONFIG_CMD_BOOTD is not set # CONFIG_CMD_BOOTM is not set @@ -29,4 +33,10 @@ CONFIG_CMD_MEMTEST=y # CONFIG_CMD_NFS is not set CONFIG_CMD_CACHE=y # CONFIG_MMC is not set +CONFIG_USB=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_CI_UDC=y CONFIG_REGEX=y diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h index f5238a5..28c67c4 100644 --- a/include/configs/mx6memcal.h +++ b/include/configs/mx6memcal.h @@ -56,4 +56,6 @@ #define CONFIG_ENV_SIZE(8 * 1024) +#define CONFIG_MXC_USB_PORTSC PORT_PTS_UTMI + #endif/* __CONFIG_H */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK
2018-01-17 23:13 GMT-02:00 Peng Fan : > Could you share the info that with timeout value to 0 and uboot debug enabled? > > Did you try nxp internal uboot on your board? What's the behavior? > > Actually I do not want to bother debugging for A0. > > Regards, > Peng. I talked to Peng offline, and we will work on improving the README file. Thanks, Diego ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx6memcal: launder through savedefconfig
On Thu, Jan 18, 2018 at 12:47 PM, Eric Nelson wrote: > This patch just changes the order of configuration items in > mx6memcal_defconfig to match the Kconfig layout, making it easier > to track changes made using menuconfig. > > Signed-off-by: Eric Nelson Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx6memcal: enable SDP support
On Thu, Jan 18, 2018 at 12:47 PM, Eric Nelson wrote: > The initial implementation of mx6memcal reset the CPU after > running the memory calibration procedure because the generic > board has no information about which boot devices are available. > > Now that we have SDP support in SPL, use it to allow a full > U-Boot to be uploaded (i.e. to use "mtest"). > > Signed-off-by: Eric Nelson Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/15] env: fat: Make the debug messages play a little nicer
On Wed, Jan 17, 2018 at 03:03:47PM -0700, Simon Glass wrote: > Hi Maxime, > > On 16 January 2018 at 01:16, Maxime Ripard > wrote: > > Since we have global messages to indicate what's going on, the custom > > messages in the environment drivers only make the output less readable. > > > > Make FAT play a little nicer by removing all the extra \n and formatting > > that is redundant with the global output. > > > > Reviewed-by: Andre Przywara > > Signed-off-by: Maxime Ripard > > --- > > env/fat.c | 25 - > > 1 file changed, 20 insertions(+), 5 deletions(-) > > Do you have a change log for this patch? Sorry, it was buried in my cover letter. You have the diff here: http://code.bulix.org/g3emu3-259575 tl; dr: I added some comments around the printf's to make it obvious that the missing \n were intentional. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mx6memcal: fix comment in board header file
The board header file included a reference to the starting point from nitrogen6x.h, but since so much changed, the file bears little resemblance to that file. Signed-off-by: Eric Nelson --- include/configs/mx6memcal.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h index 28c67c4..5be8ce4 100644 --- a/include/configs/mx6memcal.h +++ b/include/configs/mx6memcal.h @@ -1,8 +1,7 @@ /* - * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. + * Copyright (C) 2010-2018 Freescale Semiconductor, Inc. * - * Configuration settings for the Boundary Devices Nitrogen6X - * and Freescale i.MX6Q Sabre Lite boards. + * Configuration settings for the virtual mx6memcal board. * * SPDX-License-Identifier:GPL-2.0+ */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/18] efi_loader: correct EFI_BLOCK_IO_PROTOCOL definitions
On 17.01.18 20:16, Heinrich Schuchardt wrote: > Add the revision constants. > Depending on the revision additional fields are needed in the > media descriptor. > Use efi_uintn_t for number of bytes to read or write. > > Signed-off-by: Heinrich Schuchardt > --- > v2 > no change > --- > include/efi_api.h | 10 -- > lib/efi_loader/efi_disk.c | 8 > 2 files changed, 12 insertions(+), 6 deletions(-) > > diff --git a/include/efi_api.h b/include/efi_api.h > index 502fffed20..0bc24d 100644 > --- a/include/efi_api.h > +++ b/include/efi_api.h > @@ -424,18 +424,24 @@ struct efi_block_io_media > u32 io_align; > u8 pad2[4]; > u64 last_block; Please add comments on each field which revision it's available in. Or alternatively revision cut lines, like /* Below is available as of revision 2 */. Alex > + u64 lowest_aligned_lba; > + u32 logical_blocks_per_physical_block; > + u32 optimal_transfer_length_granualarity; > }; > > +#define EFI_BLOCK_IO_PROTOCOL_REVISION2 0x00020001 > +#define EFI_BLOCK_IO_PROTOCOL_REVISION3 0x0002001f > + > struct efi_block_io { > u64 revision; > struct efi_block_io_media *media; > efi_status_t (EFIAPI *reset)(struct efi_block_io *this, > char extended_verification); > efi_status_t (EFIAPI *read_blocks)(struct efi_block_io *this, > - u32 media_id, u64 lba, unsigned long buffer_size, > + u32 media_id, u64 lba, efi_uintn_t buffer_size, > void *buffer); > efi_status_t (EFIAPI *write_blocks)(struct efi_block_io *this, > - u32 media_id, u64 lba, unsigned long buffer_size, > + u32 media_id, u64 lba, efi_uintn_t buffer_size, > void *buffer); > efi_status_t (EFIAPI *flush_blocks)(struct efi_block_io *this); > }; > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c > index 92c3f45ca5..8f84e7788e 100644 > --- a/lib/efi_loader/efi_disk.c > +++ b/lib/efi_loader/efi_disk.c > @@ -91,7 +91,7 @@ static efi_status_t efi_disk_rw_blocks(struct efi_block_io > *this, > } > > static efi_status_t EFIAPI efi_disk_read_blocks(struct efi_block_io *this, > - u32 media_id, u64 lba, unsigned long buffer_size, > + u32 media_id, u64 lba, efi_uintn_t buffer_size, > void *buffer) > { > void *real_buffer = buffer; > @@ -112,7 +112,7 @@ static efi_status_t EFIAPI efi_disk_read_blocks(struct > efi_block_io *this, > real_buffer = efi_bounce_buffer; > #endif > > - EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba, > + EFI_ENTRY("%p, %x, %" PRIx64 ", %zx, %p", this, media_id, lba, > buffer_size, buffer); > > r = efi_disk_rw_blocks(this, media_id, lba, buffer_size, real_buffer, > @@ -126,7 +126,7 @@ static efi_status_t EFIAPI efi_disk_read_blocks(struct > efi_block_io *this, > } > > static efi_status_t EFIAPI efi_disk_write_blocks(struct efi_block_io *this, > - u32 media_id, u64 lba, unsigned long buffer_size, > + u32 media_id, u64 lba, efi_uintn_t buffer_size, > void *buffer) > { > void *real_buffer = buffer; > @@ -147,7 +147,7 @@ static efi_status_t EFIAPI efi_disk_write_blocks(struct > efi_block_io *this, > real_buffer = efi_bounce_buffer; > #endif > > - EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba, > + EFI_ENTRY("%p, %x, %" PRIx64 ", %zx, %p", this, media_id, lba, > buffer_size, buffer); > > /* Populate bounce buffer if necessary */ > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/18] efi_loader: make efi_disk_create_partitions a global symbol
On 17.01.18 20:16, Heinrich Schuchardt wrote: > Up to now we have been using efi_disk_create_partitions() to create > partions for block device that existed before starting an EFI partitions devices > application. > > We need to to call it for for block devices created by EFI s/to// s/for// Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/18] efi_loader: provide links between devices EFI handles
On 17.01.18 20:16, Heinrich Schuchardt wrote: > U-Boot devices and EFI handles can be related, e.g. an > IDE disk relates to a handle with the EFI_BLOCK_IO_PROTOCOL. > Provide pointers to store these links. > > Signed-off-by: Heinrich Schuchardt > --- > v2 > no change > --- > include/dm/device.h | 4 > include/efi_loader.h | 2 ++ > lib/efi_loader/efi_boottime.c | 1 + > 3 files changed, 7 insertions(+) > > diff --git a/include/dm/device.h b/include/dm/device.h > index 813e49f330..e5c54fe7b6 100644 > --- a/include/dm/device.h > +++ b/include/dm/device.h > @@ -11,6 +11,7 @@ > #ifndef _DM_DEVICE_H > #define _DM_DEVICE_H > > +#include > #include > #include > #include > @@ -144,6 +145,9 @@ struct udevice { > uint32_t flags; > int req_seq; > int seq; > +#ifdef EFI_LOADER > + efi_handle_t handle; > +#endif I fail to find where you actually make use of the handle inside > #ifdef CONFIG_DEVRES > struct list_head devres_head; > #endif > diff --git a/include/efi_loader.h b/include/efi_loader.h > index 4060348695..711c901eda 100644 > --- a/include/efi_loader.h > +++ b/include/efi_loader.h > @@ -139,6 +139,8 @@ struct efi_object { > struct list_head protocols; > /* The object spawner can either use this for data or as identifier */ > void *handle; > + /* Device */ > + struct udevice *dev; > }; > > /** > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c > index 5a3349ecb2..4b3b63e39a 100644 > --- a/lib/efi_loader/efi_boottime.c > +++ b/lib/efi_loader/efi_boottime.c > @@ -362,6 +362,7 @@ efi_status_t efi_create_handle(efi_handle_t *handle) > (void **)&obj); > if (r != EFI_SUCCESS) > return r; > + obj->dev = NULL; How about we just zero initialize the whole struct? Alex > efi_add_handle(obj); > *handle = obj->handle; > return r; > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/18] efi_loader: provide links between devices EFI handles
On 01/18/2018 05:09 PM, Alexander Graf wrote: > > > On 17.01.18 20:16, Heinrich Schuchardt wrote: >> U-Boot devices and EFI handles can be related, e.g. an >> IDE disk relates to a handle with the EFI_BLOCK_IO_PROTOCOL. >> Provide pointers to store these links. >> >> Signed-off-by: Heinrich Schuchardt >> --- >> v2 >> no change >> --- >> include/dm/device.h | 4 >> include/efi_loader.h | 2 ++ >> lib/efi_loader/efi_boottime.c | 1 + >> 3 files changed, 7 insertions(+) >> >> diff --git a/include/dm/device.h b/include/dm/device.h >> index 813e49f330..e5c54fe7b6 100644 >> --- a/include/dm/device.h >> +++ b/include/dm/device.h >> @@ -11,6 +11,7 @@ >> #ifndef _DM_DEVICE_H >> #define _DM_DEVICE_H >> >> +#include >> #include >> #include >> #include >> @@ -144,6 +145,9 @@ struct udevice { >> uint32_t flags; >> int req_seq; >> int seq; >> +#ifdef EFI_LOADER >> +efi_handle_t handle; >> +#endif > > I fail to find where you actually make use of the handle inside > >> #ifdef CONFIG_DEVRES >> struct list_head devres_head; >> #endif >> diff --git a/include/efi_loader.h b/include/efi_loader.h >> index 4060348695..711c901eda 100644 >> --- a/include/efi_loader.h >> +++ b/include/efi_loader.h >> @@ -139,6 +139,8 @@ struct efi_object { >> struct list_head protocols; >> /* The object spawner can either use this for data or as identifier */ >> void *handle; >> +/* Device */ >> +struct udevice *dev; >> }; >> >> /** >> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c >> index 5a3349ecb2..4b3b63e39a 100644 >> --- a/lib/efi_loader/efi_boottime.c >> +++ b/lib/efi_loader/efi_boottime.c >> @@ -362,6 +362,7 @@ efi_status_t efi_create_handle(efi_handle_t *handle) >>(void **)&obj); >> if (r != EFI_SUCCESS) >> return r; >> +obj->dev = NULL; > > How about we just zero initialize the whole struct? All other fields are initialized in efi_add_handle(). So why invest more CPU cycles? Regards Heinrich > > Alex > >> efi_add_handle(obj); >> *handle = obj->handle; >> return r; >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router
Hi Andreas, On 17.01.2018 16:52, Andreas Färber wrote: Am 09.06.2017 um 19:28 schrieb Marek Behún: This is the fourth version of patches for adding support for the Turris Omnia board, a router developed by the CZ.NIC. I'm still facing trouble testing turris_omnia on latest v2018.01. First, that made me notice there's no README for how to test and deploy. I'm aware of temporary: sendbeacon /dev/ttyUSBx I have to admit, that don't know anything about this "sendbeacon" tool. ./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p This is what I have used, when I tested / debugged images for Armada XP / 38x. Please note that the init sequence is somewhat "fragile" - so I added the -q and -s parameters, to optionally finetune the startup timings: # kwboot ... -q : use specific request-delay -s : use specific response-timeout You might what to play a bit with these parameters as well. BTW: I don't have access to the Omnia router, so I can't test anything on this specific platform. BTW2: Kosta from Marvell just recently added a new tool / script, to help debug / boot Marvell MVEBU boards: tools/mrvl_uart.sh He told me that its better to use than the "old" kwboot tool. I never found the time to use it up until now, so I have no personal experience. But I'm pretty sure that Kosta did a great job here. So please give it a try. # or without -p when s/BOOT_FROM spi/BOOT_FROM uart/ and permanent: tftpboot 0x100 u-boot-spl.kwb sf probe sf update 0x100 0 $filesize I used to have the original factory CZ.NIC U-Boot in SPI and booted test versions only via sendbeacon+kwboot. With mainline that appears to be broken - the CONFIG_ARMADA_38X code in arch/arm/mach-mvebu/spl.c seems to run into !boot_device and instead of UART tries to boot from SPI - nothing happens then and kwboot complains. I can force it to continue booting from UART by commenting out the if. So Stefan, it looks like your auto-detection is not working here and the Kconfig option to force it was dropped prematurely. Hmmm. Then some patch must have broken this UART boot-ability. Could you by any chance git-bisect, to check which patch broke this functionality? Perhaps some of the newer patches from Sean Nyekjaer? When forcing UART, as soon as the progress surpasses 99%, it reboots into SPI SPL without any error message. Using the old U-Boot fork I've tried flashing u-boot-spl.kwb - similarly it gets stuck in the SPL trying to boot on from SPI. After a while it reboots, and so on in a loop. So it seems that non-SPL U-Boot 2018.01 is broken, on my 2 GB model. Hmmm. I can only I also ran into a couple DDR3 training failures when booting via UART. No such training problems observed booting from SPI. Using the same U-Boot version, meaning same DDR init code? Thats strange. I have not really worked with Armada 38x for quite some time, but I don't remember any such problems that you describe here. I might need to dig up an Armada 38x board and give it a try myself... Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/15] env: Mark env_get_location as weak
Hi Simon, On Wed, Jan 17, 2018 at 03:07:58PM -0700, Simon Glass wrote: > On 16 January 2018 at 01:16, Maxime Ripard > wrote: > > Allow boards and architectures to override the default environment lookup > > code by overriding env_get_location. > > > > Reviewed-by: Andre Przywara > > Reviewed-by: Lukasz Majewski > > Signed-off-by: Maxime Ripard > > --- > > env/env.c | 20 +++- > > 1 file changed, 19 insertions(+), 1 deletion(-) > > > > I still don't really understand why this needs to be a weak function. > If the board knows the priority order, can it not put it into > global_data? We could have a little u8 array of 4 items with a > terminator? Sure that would be simpler, but that would also prevent us from doing "smart" things based on data other than just whether the previous environment is usable. Things based for example on a GPIO state, or a custom algorithm to transition (or duplicate) the environment. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Individual files dual licenses
Tom and Wolfgang, Do we have guideline on dual licensing the code in U-Boot? If I collect consent from all contributors and copyright holders to a particular file, am I able to re-license the file? If yes, how to determine the list of contributors? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] bcm283x: Add pinctrl driver
Hi Alex, On 17 January 2018 at 16:33, Alexander Graf wrote: > The bcm283x family of SoCs have a GPIO controller that also acts as > pinctrl controller. > > This patch introduces a new pinctrl driver that can actually properly mux > devices into their device tree defined pin states and is now the primary > owner of the gpio device. The previous GPIO driver gets moved into a > subdevice of the pinctrl driver, bound to the same OF node. > > That way whenever a device asks for pinctrl support, it gets it > automatically from the pinctrl driver and GPIO support is still available > in the normal command line phase. > > Signed-off-by: Alexander Graf > --- > MAINTAINERS| 1 + > arch/arm/mach-bcm283x/include/mach/gpio.h | 2 - > board/raspberrypi/rpi/rpi.c| 5 +- > configs/rpi_0_w_defconfig | 4 + > configs/rpi_2_defconfig| 4 + > configs/rpi_3_32b_defconfig| 4 + > configs/rpi_3_defconfig| 4 + > configs/rpi_defconfig | 4 + > drivers/gpio/bcm2835_gpio.c| 29 ++ > drivers/pinctrl/Kconfig| 1 + > drivers/pinctrl/Makefile | 1 + > drivers/pinctrl/broadcom/Kconfig | 7 ++ > drivers/pinctrl/broadcom/Makefile | 7 ++ > drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 150 > + > 14 files changed, 200 insertions(+), 23 deletions(-) > create mode 100644 drivers/pinctrl/broadcom/Kconfig > create mode 100644 drivers/pinctrl/broadcom/Makefile > create mode 100644 drivers/pinctrl/broadcom/pinctrl-bcm283x.c That was quick! [...] > diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c > b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c > new file mode 100644 > index 00..62c35698f5 > --- /dev/null > +++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c > @@ -0,0 +1,150 @@ > +/* > + * Copyright (C) 2018 Alexander Graf > + * > + * Based on drivers/pinctrl/mvebu/pinctrl-mvebu.c and > + * drivers/gpio/bcm2835_gpio.c > + * > + * This driver gets instantiated by the GPIO driver, because both devices > + * share the same device node. > + * > + * SPDX-License-Identifier:GPL-2.0 > + * https://spdx.org/licenses > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; > + > +struct bcm283x_pinctrl_priv { > + u32 *base_reg; > +}; > + > +#define MAX_PINS_PER_BANK 16 > + > +static void bcm2835_gpio_set_func_id(struct udevice *dev, unsigned int gpio, > +int func) > +{ > + struct bcm283x_pinctrl_priv *priv = dev_get_priv(dev); > + int reg_offset; > + int field_offset; > + > + reg_offset = BCM2835_GPIO_FSEL_BANK(gpio); > + field_offset = BCM2835_GPIO_FSEL_SHIFT(gpio); > + > + clrsetbits_le32(&priv->base_reg[reg_offset], > + BCM2835_GPIO_FSEL_MASK << field_offset, > + (func & BCM2835_GPIO_FSEL_MASK) << field_offset); > +} > + > +static int bcm2835_gpio_get_func_id(struct udevice *dev, unsigned int gpio) > +{ > + struct bcm283x_pinctrl_priv *priv = dev_get_priv(dev); > + u32 val; > + > + val = readl(&priv->base_reg[BCM2835_GPIO_FSEL_BANK(gpio)]); > + > + return (val >> BCM2835_GPIO_FSEL_SHIFT(gpio) & > BCM2835_GPIO_FSEL_MASK); > +} > + > +/* > + * bcm283x_pinctrl_set_state: configure pin functions. > + * @dev: the pinctrl device to be configured. > + * @config: the state to be configured. > + * @return: 0 in success > + */ > +int bcm283x_pinctrl_set_state(struct udevice *dev, struct udevice *config) > +{ > + const void *blob = gd->fdt_blob; > + int node = dev_of_offset(config); > + u32 pin_arr[MAX_PINS_PER_BANK]; > + u32 function; > + int i, pin_count; > + > + pin_count = fdtdec_get_int_array_count(blob, node, > + "brcm,pins", > + pin_arr, > + ARRAY_SIZE(pin_arr)); > + if (pin_count <= 0) { > + debug("Failed reading pins array for pinconfig %s (%d)\n", > + config->name, pin_count); > + return -EINVAL; > + } > + > + function = fdtdec_get_int(blob, node, "brcm,function", -1); Please use dev_read_...() interface. > + if (function < 0) { > + debug("Failed reading function for pinconfig %s (%d)\n", > + config->name, function); > + return -EINVAL; > + } > + > + for (i = 0; i < pin_count; i++) > + bcm2835_gpio_set_func_id(dev, pin_arr[i], function); > + > + return 0; > +} > + > +static int bcm283x_pinctrl_get_gpio_mux(struct udevice *dev, int banknum, > +
Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router
Hi Stefan, Am 18.01.2018 um 18:20 schrieb Stefan Roese: > On 17.01.2018 16:52, Andreas Färber wrote: >> Am 09.06.2017 um 19:28 schrieb Marek Behún: >>> This is the fourth version of patches for adding support for the >>> Turris Omnia board, a router developed by the CZ.NIC. >> >> I'm still facing trouble testing turris_omnia on latest v2018.01. >> >> First, that made me notice there's no README for how to test and deploy. >> I'm aware of temporary: >> sendbeacon /dev/ttyUSBx > > I have to admit, that don't know anything about this "sendbeacon" > tool. Quick pointer: https://gitlab.labs.nic.cz/turris/misc/tree/master/sendbeacon Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Individual files dual licenses
On Thu, Jan 18, 2018 at 05:25:01PM +, York Sun wrote: > Tom and Wolfgang, > > Do we have guideline on dual licensing the code in U-Boot? If I collect > consent from all contributors and copyright holders to a particular > file, am I able to re-license the file? If yes, how to determine the > list of contributors? In general, I think you would use 'git log' to see who contributed to a given file, and make sure that everyone who authored a change signed off on the license change. With regards to dts files, this is another reason I would like to see that done as a strict re-sync with Linux rather than a stand-alone change. Saying we're importing file X from the kernel at revision Y makes the license change pretty easy to spot and justify. -- 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] Individual files dual licenses
On 01/18/2018 09:59 AM, Tom Rini wrote: > On Thu, Jan 18, 2018 at 05:25:01PM +, York Sun wrote: > >> Tom and Wolfgang, >> >> Do we have guideline on dual licensing the code in U-Boot? If I collect >> consent from all contributors and copyright holders to a particular >> file, am I able to re-license the file? If yes, how to determine the >> list of contributors? > > In general, I think you would use 'git log' to see who contributed to a > given file, and make sure that everyone who authored a change signed off > on the license change. Thanks. > > With regards to dts files, this is another reason I would like to see > that done as a strict re-sync with Linux rather than a stand-alone > change. Saying we're importing file X from the kernel at revision Y > makes the license change pretty easy to spot and justify. > For the dts files, they already exist in U-Boot. Can the team still say "importing" from Linux? The files in U-Boot is only a small subset of those in Linux. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Individual files dual licenses
On Thu, Jan 18, 2018 at 06:02:44PM +, York Sun wrote: > On 01/18/2018 09:59 AM, Tom Rini wrote: > > On Thu, Jan 18, 2018 at 05:25:01PM +, York Sun wrote: > > > >> Tom and Wolfgang, > >> > >> Do we have guideline on dual licensing the code in U-Boot? If I collect > >> consent from all contributors and copyright holders to a particular > >> file, am I able to re-license the file? If yes, how to determine the > >> list of contributors? > > > > In general, I think you would use 'git log' to see who contributed to a > > given file, and make sure that everyone who authored a change signed off > > on the license change. > > Thanks. > > > > > With regards to dts files, this is another reason I would like to see > > that done as a strict re-sync with Linux rather than a stand-alone > > change. Saying we're importing file X from the kernel at revision Y > > makes the license change pretty easy to spot and justify. > > > > For the dts files, they already exist in U-Boot. Can the team still say > "importing" from Linux? The files in U-Boot is only a small subset of > those in Linux. Yes, if it's a strict replace file A with contents of the same file from Linux, it's re-importing. I thought these boards had already re-synced before but perhaps not? It's something we do from time to time on other platforms. -- 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] Individual files dual licenses
On 01/18/2018 10:04 AM, Tom Rini wrote: >>> >>> With regards to dts files, this is another reason I would like to see >>> that done as a strict re-sync with Linux rather than a stand-alone >>> change. Saying we're importing file X from the kernel at revision Y >>> makes the license change pretty easy to spot and justify. >>> >> >> For the dts files, they already exist in U-Boot. Can the team still say >> "importing" from Linux? The files in U-Boot is only a small subset of >> those in Linux. > > Yes, if it's a strict replace file A with contents of the same file from > Linux, it's re-importing. I thought these boards had already re-synced > before but perhaps not? It's something we do from time to time on other > platforms. > In this case, the contents of dts files are different from those in Linux. The only thing imported this time is the dual license. Is it still considered a re-sync? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Individual files dual licenses
On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote: > On 01/18/2018 10:04 AM, Tom Rini wrote: > >>> > >>> With regards to dts files, this is another reason I would like to see > >>> that done as a strict re-sync with Linux rather than a stand-alone > >>> change. Saying we're importing file X from the kernel at revision Y > >>> makes the license change pretty easy to spot and justify. > >>> > >> > >> For the dts files, they already exist in U-Boot. Can the team still say > >> "importing" from Linux? The files in U-Boot is only a small subset of > >> those in Linux. > > > > Yes, if it's a strict replace file A with contents of the same file from > > Linux, it's re-importing. I thought these boards had already re-synced > > before but perhaps not? It's something we do from time to time on other > > platforms. > > In this case, the contents of dts files are different from those in > Linux. The only thing imported this time is the dual license. Is it > still considered a re-sync? They should not be different at all. Anything U-Boot centric should be in an appropriately named -u-boot.dtsi file. This facilitates keeping the rest of the dts/dtsi files as exact copies of the ones in the kernel. To put it another way, what is the reason they differ from the kernel? And could they be changed to not, and use a -u-boot.dtsi (or several) so that they can be kept in-sync with the kernel? -- 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 v2 14/18] efi_loader: provide links between devices EFI handles
On 18.01.18 17:18, Heinrich Schuchardt wrote: > On 01/18/2018 05:09 PM, Alexander Graf wrote: >> >> >> On 17.01.18 20:16, Heinrich Schuchardt wrote: >>> U-Boot devices and EFI handles can be related, e.g. an >>> IDE disk relates to a handle with the EFI_BLOCK_IO_PROTOCOL. >>> Provide pointers to store these links. >>> >>> Signed-off-by: Heinrich Schuchardt >>> --- >>> v2 >>> no change >>> --- >>> include/dm/device.h | 4 >>> include/efi_loader.h | 2 ++ >>> lib/efi_loader/efi_boottime.c | 1 + >>> 3 files changed, 7 insertions(+) >>> >>> diff --git a/include/dm/device.h b/include/dm/device.h >>> index 813e49f330..e5c54fe7b6 100644 >>> --- a/include/dm/device.h >>> +++ b/include/dm/device.h >>> @@ -11,6 +11,7 @@ >>> #ifndef _DM_DEVICE_H >>> #define _DM_DEVICE_H >>> >>> +#include >>> #include >>> #include >>> #include >>> @@ -144,6 +145,9 @@ struct udevice { >>> uint32_t flags; >>> int req_seq; >>> int seq; >>> +#ifdef EFI_LOADER >>> + efi_handle_t handle; >>> +#endif >> >> I fail to find where you actually make use of the handle inside Care to answer here too? :) >> >>> #ifdef CONFIG_DEVRES >>> struct list_head devres_head; >>> #endif >>> diff --git a/include/efi_loader.h b/include/efi_loader.h >>> index 4060348695..711c901eda 100644 >>> --- a/include/efi_loader.h >>> +++ b/include/efi_loader.h >>> @@ -139,6 +139,8 @@ struct efi_object { >>> struct list_head protocols; >>> /* The object spawner can either use this for data or as identifier */ >>> void *handle; >>> + /* Device */ >>> + struct udevice *dev; >>> }; >>> >>> /** >>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c >>> index 5a3349ecb2..4b3b63e39a 100644 >>> --- a/lib/efi_loader/efi_boottime.c >>> +++ b/lib/efi_loader/efi_boottime.c >>> @@ -362,6 +362,7 @@ efi_status_t efi_create_handle(efi_handle_t *handle) >>> (void **)&obj); >>> if (r != EFI_SUCCESS) >>> return r; >>> + obj->dev = NULL; >> >> How about we just zero initialize the whole struct? > > All other fields are initialized in efi_add_handle(). > So why invest more CPU cycles? I'm mostly concerned that we get into a situation where people don't fully grasp the flow of what gets initialized where and nasty bugs happen. So I guess we should either initialize obj->dev in efi_add_handle() or fully zero initialize obj, like we do for most other callers of efi_add_handle(). Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Individual files dual licenses
On 01/18/2018 10:11 AM, Tom Rini wrote: > On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote: >> On 01/18/2018 10:04 AM, Tom Rini wrote: > > With regards to dts files, this is another reason I would like to see > that done as a strict re-sync with Linux rather than a stand-alone > change. Saying we're importing file X from the kernel at revision Y > makes the license change pretty easy to spot and justify. > For the dts files, they already exist in U-Boot. Can the team still say "importing" from Linux? The files in U-Boot is only a small subset of those in Linux. >>> >>> Yes, if it's a strict replace file A with contents of the same file from >>> Linux, it's re-importing. I thought these boards had already re-synced >>> before but perhaps not? It's something we do from time to time on other >>> platforms. >> >> In this case, the contents of dts files are different from those in >> Linux. The only thing imported this time is the dual license. Is it >> still considered a re-sync? > > They should not be different at all. Anything U-Boot centric should be > in an appropriately named -u-boot.dtsi file. This facilitates keeping > the rest of the dts/dtsi files as exact copies of the ones in the > kernel. > > To put it another way, what is the reason they differ from the kernel? > And could they be changed to not, and use a -u-boot.dtsi (or several) so > that they can be kept in-sync with the kernel? > The dts files in Linux are much much bigger. U-Boot only uses a small subset. There are many nodes not used by U-Boot. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] efi_loader: correctly call images
On 01/18/2018 11:05 AM, Alexander Graf wrote: > > > On 18.01.18 10:52, Heinrich Schuchardt wrote: >> >> >> On 01/18/2018 10:24 AM, Alexander Graf wrote: >>> >>> >>> On 18.01.18 08:24, Heinrich Schuchardt wrote: Avoid a failed assertion when an EFI app calls an EFI app. Avoid that the indent level increases when calling 'bootefi hello' repeatedly. Avoid negative indent level when an EFI app calls an EFI app that calls an EFI app (e.g. iPXE loads grub which starts the kernel). Return the status code of a loaded image that returns without calling the Exit boot service. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_boottime.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 2c5499e0c8..538cc55d20 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -1537,6 +1537,7 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle, asmlinkage ulong (*entry)(efi_handle_t image_handle, struct efi_system_table *st); struct efi_loaded_image *info = image_handle; + efi_status_t ret; EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data); entry = info->reserved; @@ -1546,17 +1547,23 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle, /* call the image! */ if (setjmp(&info->exit_jmp)) { /* We returned from the child image */ +#ifdef CONFIG_ARM + /* efi_exit() called efi_restore_gd() */ + gd = app_gd; +#endif + /* Execute the return part of EFI_CALL */ + assert(__efi_entry_check()); + debug("%sEFI: %lu returned by started image\n", + __efi_nesting_dec(), >>> >>> I don't understand why you need to decrease the nesting level here after >>> the other rework. You're now calling EFI_ENTRY/EFI_EXIT in all normal >>> paths when going in/out of an application, no? >> >> bootefi -> level 0 >> ** EFI application running at level 0 >> LoadImage EFI_ENTRY -> level 1 >> LoadImage EFI_EXIT -> level 0 >> ** EFI application running at level 0 > > -- base level at 0 > >> StartImage EFI_ENTRY -> level 1 > > This is decreased in EFI_EXIT of StartImage > >> StartImage EFI_CALL -> level 2 > > This is the one that needs manual decrease then? > >> Exit EFI_ENTRY -> level 3 > > Gets decreased right below in Exit again > >> Exit EFI_EXIT -> level 2 >> longjmp -> level 2 >> __efi_nesting_dec() -> level 1 >> StartImage EFI_EXIT -> level 0 > > --- base level again > > > So I guess the problem is that we never get into the second half of > EFI_CALL when ->exit() gets called because of the longjmp. > > Can you please add a comment explaining that rationale with a hint to > EFI_CALL and that all we do is execute the lower half of it manually > again because it got interrupted by the longjmp? > I already wrote: /* Execute the return part of EFI_CALL */ Regards Heinrich > > Alex > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] efi_loader: correctly call images
On 18.01.18 19:28, Heinrich Schuchardt wrote: > On 01/18/2018 11:05 AM, Alexander Graf wrote: >> >> >> On 18.01.18 10:52, Heinrich Schuchardt wrote: >>> >>> >>> On 01/18/2018 10:24 AM, Alexander Graf wrote: On 18.01.18 08:24, Heinrich Schuchardt wrote: > Avoid a failed assertion when an EFI app calls an EFI app. > > Avoid that the indent level increases when calling 'bootefi hello' > repeatedly. > > Avoid negative indent level when an EFI app calls an EFI app that > calls an EFI app (e.g. iPXE loads grub which starts the kernel). > > Return the status code of a loaded image that returns without > calling the Exit boot service. > > Signed-off-by: Heinrich Schuchardt > --- > lib/efi_loader/efi_boottime.c | 21 ++--- > 1 file changed, 14 insertions(+), 7 deletions(-) > > diff --git a/lib/efi_loader/efi_boottime.c > b/lib/efi_loader/efi_boottime.c > index 2c5499e0c8..538cc55d20 100644 > --- a/lib/efi_loader/efi_boottime.c > +++ b/lib/efi_loader/efi_boottime.c > @@ -1537,6 +1537,7 @@ static efi_status_t EFIAPI > efi_start_image(efi_handle_t image_handle, > asmlinkage ulong (*entry)(efi_handle_t image_handle, > struct efi_system_table *st); > struct efi_loaded_image *info = image_handle; > + efi_status_t ret; > EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, > exit_data); > entry = info->reserved; > @@ -1546,17 +1547,23 @@ static efi_status_t EFIAPI > efi_start_image(efi_handle_t image_handle, > /* call the image! */ > if (setjmp(&info->exit_jmp)) { > /* We returned from the child image */ > +#ifdef CONFIG_ARM > + /* efi_exit() called efi_restore_gd() */ > + gd = app_gd; > +#endif > + /* Execute the return part of EFI_CALL */ > + assert(__efi_entry_check()); > + debug("%sEFI: %lu returned by started image\n", > + __efi_nesting_dec(), I don't understand why you need to decrease the nesting level here after the other rework. You're now calling EFI_ENTRY/EFI_EXIT in all normal paths when going in/out of an application, no? >>> >>> bootefi -> level 0 >>> ** EFI application running at level 0 >>> LoadImage EFI_ENTRY -> level 1 >>> LoadImage EFI_EXIT -> level 0 >>> ** EFI application running at level 0 >> >> -- base level at 0 >> >>> StartImage EFI_ENTRY -> level 1 >> >> This is decreased in EFI_EXIT of StartImage >> >>> StartImage EFI_CALL -> level 2 >> >> This is the one that needs manual decrease then? >> >>> Exit EFI_ENTRY -> level 3 >> >> Gets decreased right below in Exit again >> >>> Exit EFI_EXIT -> level 2 >>> longjmp -> level 2 >>> __efi_nesting_dec() -> level 1 >>> StartImage EFI_EXIT -> level 0 >> >> --- base level again >> >> >> So I guess the problem is that we never get into the second half of >> EFI_CALL when ->exit() gets called because of the longjmp. >> >> Can you please add a comment explaining that rationale with a hint to >> EFI_CALL and that all we do is execute the lower half of it manually >> again because it got interrupted by the longjmp? >> > > I already wrote: > /* Execute the return part of EFI_CALL */ Could you make that slightly more verbose? Which EFI_CALL? Why do we need to execute the return path? Keep in mind that people 2 years down the road should be able to grasp what the code does :). Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] LS1046ARDB QSPI ENV fails
Mingkai and Suresh, Please look into LS1046ARDB QSPI boot. The environmental variables fail to load. It always reports "Warning - bad CRC, using default environment". York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/18] efi_loader: provide links between devices EFI handles
On 17.01.18 20:16, Heinrich Schuchardt wrote: > U-Boot devices and EFI handles can be related, e.g. an > IDE disk relates to a handle with the EFI_BLOCK_IO_PROTOCOL. > Provide pointers to store these links. > > Signed-off-by: Heinrich Schuchardt You actually wouldn't need any of these changes I think. With a small change to the block driver, even the need for "dev" disappears. Alex diff --git a/lib/efi_driver/efi_block_device.c b/lib/efi_driver/efi_block_device.c index 837787d563..71c752d107 100644 --- a/lib/efi_driver/efi_block_device.c +++ b/lib/efi_driver/efi_block_device.c @@ -91,19 +91,19 @@ static ulong efi_bl_write(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt, return blkcnt; } -static int efi_bl_bind_partions(efi_handle_t handle) +static int efi_bl_bind_partions(efi_object *obj, struct udevice *bdev) { struct efi_object *obj = efi_search_obj(handle); struct blk_desc *desc; const char *if_typename; - if (!obj || !obj->dev) + if (!obj || !bdev) return -ENOENT; - desc = dev_get_uclass_platdata(obj->dev); + desc = dev_get_uclass_platdata(bdev); if_typename = blk_get_if_type_name(desc->if_type); return efi_disk_create_partitions(handle, desc, if_typename, - desc->devnum, obj->dev->name); + desc->devnum, bdev->name); } /* @@ -137,11 +137,10 @@ static int efi_bl_bind(efi_handle_t handle, void *interface) return ret; EFI_PRINT("%s: block device '%s' created\n", __func__, bdev->name); bdev->platdata = interface; - obj->dev = bdev; ret = blk_prepare_device(bdev); - disks = efi_bl_bind_partions(handle); + disks = efi_bl_bind_partions(obj, bdev); EFI_PRINT("Found %d partions\n", disks); return 0; ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Individual files dual licenses
On Thu, Jan 18, 2018 at 06:14:07PM +, York Sun wrote: > On 01/18/2018 10:11 AM, Tom Rini wrote: > > On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote: > >> On 01/18/2018 10:04 AM, Tom Rini wrote: > > > > With regards to dts files, this is another reason I would like to see > > that done as a strict re-sync with Linux rather than a stand-alone > > change. Saying we're importing file X from the kernel at revision Y > > makes the license change pretty easy to spot and justify. > > > > For the dts files, they already exist in U-Boot. Can the team still say > "importing" from Linux? The files in U-Boot is only a small subset of > those in Linux. > >>> > >>> Yes, if it's a strict replace file A with contents of the same file from > >>> Linux, it's re-importing. I thought these boards had already re-synced > >>> before but perhaps not? It's something we do from time to time on other > >>> platforms. > >> > >> In this case, the contents of dts files are different from those in > >> Linux. The only thing imported this time is the dual license. Is it > >> still considered a re-sync? > > > > They should not be different at all. Anything U-Boot centric should be > > in an appropriately named -u-boot.dtsi file. This facilitates keeping > > the rest of the dts/dtsi files as exact copies of the ones in the > > kernel. > > > > To put it another way, what is the reason they differ from the kernel? > > And could they be changed to not, and use a -u-boot.dtsi (or several) so > > that they can be kept in-sync with the kernel? > > The dts files in Linux are much much bigger. U-Boot only uses a small > subset. There are many nodes not used by U-Boot. For SPL where we care about size in that regard we have CONFIG_OF_SPL_REMOVE_PROPS to trim things down as needed, and it shouldn't be a concern for full U-Boot. If your really want to maintain two distinct dts/dtsi files because there's some value you see in that, I won't stop you from doing it. But I don't see a unique challenge posed by the NXP platforms just yet either. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools: remove unused ret
Remove unused ret from fw_env_flush. Signed-off-by: Jelle van der Waa --- tools/env/fw_env.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 18c2324d2f..ca5507d4d7 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -505,8 +505,6 @@ int fw_printenv(int argc, char *argv[], int value_only, struct env_opts *opts) int fw_env_flush(struct env_opts *opts) { - int ret; - if (!opts) opts = &default_opts; -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] efi_loader: correctly call images
This patch series fixes various problems with the StartImage boot service. It further provides unit tests. v3 Supply two separate unit tests covering that the application either returns by calling the Exit service or with a simple return. v2 Do not build test on x68_64 due to a problem with the build system for EFI images. Heinrich Schuchardt (2): efi_loader: correctly call images efi_selftest: test start image arch/arm/lib/Makefile | 1 + lib/efi_loader/efi_boottime.c | 21 ++- lib/efi_selftest/.gitignore | 2 + lib/efi_selftest/Makefile | 35 + lib/efi_selftest/efi_selftest_miniapp_exit.c | 37 ++ lib/efi_selftest/efi_selftest_miniapp_return.c| 32 + lib/efi_selftest/efi_selftest_startimage_exit.c | 149 ++ lib/efi_selftest/efi_selftest_startimage_return.c | 149 ++ 8 files changed, 419 insertions(+), 7 deletions(-) create mode 100644 lib/efi_selftest/.gitignore create mode 100644 lib/efi_selftest/efi_selftest_miniapp_exit.c create mode 100644 lib/efi_selftest/efi_selftest_miniapp_return.c create mode 100644 lib/efi_selftest/efi_selftest_startimage_exit.c create mode 100644 lib/efi_selftest/efi_selftest_startimage_return.c -- 2.14.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/1] efi_loader: correctly call images
Avoid a failed assertion when an EFI app calls an EFI app. Avoid that the indent level increases when calling 'bootefi hello' repeatedly. Avoid negative indent level when an EFI app calls an EFI app that calls an EFI app (e.g. iPXE loads grub which starts the kernel). Return the status code of a loaded image that returns without calling the Exit boot service. Signed-off-by: Heinrich Schuchardt --- v3 Provide more comments. --- lib/efi_loader/efi_boottime.c | 36 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 2c5499e0c8..49cd69203b 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -1537,6 +1537,7 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle, asmlinkage ulong (*entry)(efi_handle_t image_handle, struct efi_system_table *st); struct efi_loaded_image *info = image_handle; + efi_status_t ret; EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data); entry = info->reserved; @@ -1545,18 +1546,37 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t image_handle, /* call the image! */ if (setjmp(&info->exit_jmp)) { - /* We returned from the child image */ + /* +* We called the entry point of the child image with EFI_CALL +* in the lines below. The child image called the Exit() boot +* service efi_exit() which executed the long jump that brought +* us to the current line. This implies that the second half +* of the EFI_CALL macro has not been executed. +*/ +#ifdef CONFIG_ARM + /* +* efi_exit() called efi_restore_gd(). We have to undo this +* otherwise __efi_entry_check() will put the wrong value into +* app_gd. +*/ + gd = app_gd; +#endif + /* +* To get ready to call EFI_EXIT below we have to execute the +* missed out steps of EFI_CALL. +*/ + assert(__efi_entry_check()); + debug("%sEFI: %lu returned by started image\n", + __efi_nesting_dec(), + (unsigned long)((uintptr_t)info->exit_status & + ~EFI_ERROR_MASK)); return EFI_EXIT(info->exit_status); } - __efi_nesting_dec(); - __efi_exit_check(); - entry(image_handle, &systab); - __efi_entry_check(); - __efi_nesting_inc(); + ret = EFI_CALL(entry(image_handle, &systab)); /* Should usually never get here */ - return EFI_EXIT(EFI_SUCCESS); + return EFI_EXIT(ret); } /* @@ -1593,7 +1613,7 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t image_handle, exit_data_size, exit_data); /* Make sure entry/exit counts for EFI world cross-overs match */ - __efi_exit_check(); + EFI_EXIT(exit_status); /* * But longjmp out with the U-Boot gd, not the application's, as -- 2.14.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] efi_selftest: test start image
This pair of tests checks the StartImage boot service. Each test loads an EFI application into memory and starts it. One returns by calling the Exit boot service. The other returns directly. The tests are not built on x86_64 because the relocation code for the efi binary cannot be created. Signed-off-by: Heinrich Schuchardt --- v3 Supply two separate unit tests covering that the application either returns by calling the Exit service or with a simple return. v2 Do not build test on x86_64. --- arch/arm/lib/Makefile | 1 + lib/efi_selftest/.gitignore | 2 + lib/efi_selftest/Makefile | 35 + lib/efi_selftest/efi_selftest_miniapp_exit.c | 37 ++ lib/efi_selftest/efi_selftest_miniapp_return.c| 32 + lib/efi_selftest/efi_selftest_startimage_exit.c | 149 ++ lib/efi_selftest/efi_selftest_startimage_return.c | 149 ++ 7 files changed, 405 insertions(+) create mode 100644 lib/efi_selftest/.gitignore create mode 100644 lib/efi_selftest/efi_selftest_miniapp_exit.c create mode 100644 lib/efi_selftest/efi_selftest_miniapp_return.c create mode 100644 lib/efi_selftest/efi_selftest_startimage_exit.c create mode 100644 lib/efi_selftest/efi_selftest_startimage_return.c diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index abffa10c85..876024fc15 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -112,4 +112,5 @@ CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI) CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI) extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC) +extra-$(CONFIG_CMD_BOOTEFI_SELFTEST) += $(EFI_CRT0) $(EFI_RELOC) extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC) diff --git a/lib/efi_selftest/.gitignore b/lib/efi_selftest/.gitignore new file mode 100644 index 00..c527e464e5 --- /dev/null +++ b/lib/efi_selftest/.gitignore @@ -0,0 +1,2 @@ +efi_miniapp_file_image.h +*.efi diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile index 20f614d6ba..90246f7827 100644 --- a/lib/efi_selftest/Makefile +++ b/lib/efi_selftest/Makefile @@ -7,6 +7,9 @@ # This file only gets included with CONFIG_EFI_LOADER set, so all # object inclusion implicitly depends on it +CFLAGS_efi_selftest_miniapp.o := $(CFLAGS_EFI) -Os -ffreestanding +CFLAGS_REMOVE_efi_selftest_miniapp.o := $(CFLAGS_NON_EFI) -Os + obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += \ efi_selftest.o \ efi_selftest_controllers.o \ @@ -25,3 +28,35 @@ efi_selftest_watchdog.o ifeq ($(CONFIG_BLK)$(CONFIG_PARTITIONS),yy) obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += efi_selftest_block_device.o endif + +# TODO: As of v2018.01 the relocation code for the EFI application cannot +# be built on x86_64. +ifeq ($(CONFIG_X86_64),) + +ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST),) + +obj-y += \ +efi_selftest_startimage_exit.o \ +efi_selftest_startimage_return.o + +targets += \ +efi_miniapp_file_image_exit.h \ +efi_miniapp_file_image_return.h \ +efi_selftest_miniapp_exit.efi \ +efi_selftest_miniapp_return.efi + +$(obj)/efi_miniapp_file_image_exit.h: $(obj)/efi_selftest_miniapp_exit.efi + $(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_exit.efi > \ + $(obj)/efi_miniapp_file_image_exit.h + +$(obj)/efi_miniapp_file_image_return.h: $(obj)/efi_selftest_miniapp_return.efi + $(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_return.efi > \ + $(obj)/efi_miniapp_file_image_return.h + +$(obj)/efi_selftest_startimage_exit.o: $(obj)/efi_miniapp_file_image_exit.h + +$(obj)/efi_selftest_startimage_return.o: $(obj)/efi_miniapp_file_image_return.h + +endif + +endif diff --git a/lib/efi_selftest/efi_selftest_miniapp_exit.c b/lib/efi_selftest/efi_selftest_miniapp_exit.c new file mode 100644 index 00..590c948a1c --- /dev/null +++ b/lib/efi_selftest/efi_selftest_miniapp_exit.c @@ -0,0 +1,37 @@ +/* + * efi_selftest_miniapp_exit + * + * Copyright (c) 2018 Heinrich Schuchardt + * + * SPDX-License-Identifier: GPL-2.0+ + * + * This EFI application is run by the StartImage selftest. + * It uses the Exit boot service to return. + */ + +#include +#include + +/* + * Entry point of the EFI application. + * + * @handle handle of the loaded image + * @systable system table + * @return status code + */ +efi_status_t EFIAPI efi_main(efi_handle_t handle, +struct efi_system_table *systable) +{ + struct efi_simple_text_output_protocol *con_out = systable->con_out; + + con_out->output_string(con_out, L"EFI application calling Exit"); + + /* The return value is checked by the calling test */ + systable->boottime->exit(handle, EFI_UNSUPPORTED, 0, NULL); + + /* +* This statement should not be reached. +* To enable testing use a different return value. +*/ + return EFI_SUCCESS; +} diff --git a/lib/efi_selftest/efi_selftest_miniapp_return.c b/lib/efi_selftest/efi_
Re: [U-Boot] [PATCH v2 14/18] efi_loader: provide links between devices EFI handles
On 01/18/2018 07:13 PM, Alexander Graf wrote: > > > On 18.01.18 17:18, Heinrich Schuchardt wrote: >> On 01/18/2018 05:09 PM, Alexander Graf wrote: >>> >>> >>> On 17.01.18 20:16, Heinrich Schuchardt wrote: U-Boot devices and EFI handles can be related, e.g. an IDE disk relates to a handle with the EFI_BLOCK_IO_PROTOCOL. Provide pointers to store these links. Signed-off-by: Heinrich Schuchardt --- v2 no change --- include/dm/device.h | 4 include/efi_loader.h | 2 ++ lib/efi_loader/efi_boottime.c | 1 + 3 files changed, 7 insertions(+) diff --git a/include/dm/device.h b/include/dm/device.h index 813e49f330..e5c54fe7b6 100644 --- a/include/dm/device.h +++ b/include/dm/device.h @@ -11,6 +11,7 @@ #ifndef _DM_DEVICE_H #define _DM_DEVICE_H +#include #include #include #include @@ -144,6 +145,9 @@ struct udevice { uint32_t flags; int req_seq; int seq; +#ifdef EFI_LOADER + efi_handle_t handle; +#endif >>> >>> I fail to find where you actually make use of the handle inside > > Care to answer here too? :) The changes in include/dm/device.h are not needed. I will revert these. Maybe in future we will have to back link devices to handles but not now. Regards Heinrich > >>> #ifdef CONFIG_DEVRES struct list_head devres_head; #endif diff --git a/include/efi_loader.h b/include/efi_loader.h index 4060348695..711c901eda 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -139,6 +139,8 @@ struct efi_object { struct list_head protocols; /* The object spawner can either use this for data or as identifier */ void *handle; + /* Device */ + struct udevice *dev; }; /** diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 5a3349ecb2..4b3b63e39a 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -362,6 +362,7 @@ efi_status_t efi_create_handle(efi_handle_t *handle) (void **)&obj); if (r != EFI_SUCCESS) return r; + obj->dev = NULL; >>> >>> How about we just zero initialize the whole struct? >> >> All other fields are initialized in efi_add_handle(). >> So why invest more CPU cycles? > > I'm mostly concerned that we get into a situation where people don't > fully grasp the flow of what gets initialized where and nasty bugs happen. > > So I guess we should either initialize obj->dev in efi_add_handle() or > fully zero initialize obj, like we do for most other callers of > efi_add_handle(). > > > Alex > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix the wrong dislabing clock
Hi JaeHoon, On 17 January 2018 at 16:06, Jaehoon Chung wrote: > When power is off, clock is not disabling. > Because it's passed to 1, mmc->clock should be set to f_min value. > Some drivers can't initialize the eMMC/SD card with current status. > > This patch is to fix the disabling clock value to 0. > > Fixes: 2e7410d76ad1 ("mmc: disable the mmc clock during power off") > > Signed-off-by: Jaehoon Chung > --- > drivers/mmc/mmc.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index 53c819187e..311f51f237 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -1501,11 +1501,13 @@ static int mmc_set_ios(struct mmc *mmc) > > int mmc_set_clock(struct mmc *mmc, uint clock, bool disable) > { > - if (clock > mmc->cfg->f_max) > - clock = mmc->cfg->f_max; > + if (!disable && clock != 0) { > + if (clock > mmc->cfg->f_max) > + clock = mmc->cfg->f_max; > > - if (clock < mmc->cfg->f_min) > - clock = mmc->cfg->f_min; > + if (clock < mmc->cfg->f_min) > + clock = mmc->cfg->f_min; > + } > > mmc->clock = clock; > mmc->clk_disable = disable; > @@ -2449,7 +2451,7 @@ static int mmc_power_on(struct mmc *mmc) > > static int mmc_power_off(struct mmc *mmc) > { > - mmc_set_clock(mmc, 1, true); > + mmc_set_clock(mmc, 0, true); > #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_REGULATOR) > if (mmc->vmmc_supply) { > int ret = regulator_set_enable(mmc->vmmc_supply, false); > -- > 2.15.1 > I have tested this patch on Odroid Xu4 on sd_card and eMMC module and all seem to be working. Tested-by: Anand Moon Best Regards -Anand ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Individual files dual licenses
On 01/18/2018 11:17 AM, Tom Rini wrote: > On Thu, Jan 18, 2018 at 06:14:07PM +, York Sun wrote: >> On 01/18/2018 10:11 AM, Tom Rini wrote: >>> On Thu, Jan 18, 2018 at 06:09:22PM +, York Sun wrote: On 01/18/2018 10:04 AM, Tom Rini wrote: >>> >>> With regards to dts files, this is another reason I would like to see >>> that done as a strict re-sync with Linux rather than a stand-alone >>> change. Saying we're importing file X from the kernel at revision Y >>> makes the license change pretty easy to spot and justify. >>> >> >> For the dts files, they already exist in U-Boot. Can the team still say >> "importing" from Linux? The files in U-Boot is only a small subset of >> those in Linux. > > Yes, if it's a strict replace file A with contents of the same file from > Linux, it's re-importing. I thought these boards had already re-synced > before but perhaps not? It's something we do from time to time on other > platforms. In this case, the contents of dts files are different from those in Linux. The only thing imported this time is the dual license. Is it still considered a re-sync? >>> >>> They should not be different at all. Anything U-Boot centric should be >>> in an appropriately named -u-boot.dtsi file. This facilitates keeping >>> the rest of the dts/dtsi files as exact copies of the ones in the >>> kernel. >>> >>> To put it another way, what is the reason they differ from the kernel? >>> And could they be changed to not, and use a -u-boot.dtsi (or several) so >>> that they can be kept in-sync with the kernel? >> >> The dts files in Linux are much much bigger. U-Boot only uses a small >> subset. There are many nodes not used by U-Boot. > > For SPL where we care about size in that regard we have > CONFIG_OF_SPL_REMOVE_PROPS to trim things down as needed, and it > shouldn't be a concern for full U-Boot. > > If your really want to maintain two distinct dts/dtsi files because > there's some value you see in that, I won't stop you from doing it. But > I don't see a unique challenge posed by the NXP platforms just yet > either. Thanks! Got it. I don't know if most platforms use identical dts from Linux. We started with tiny dts files and haven't seen the benefit to get the full version. I will let the team decide if we want to copy Linux files over. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/18] efi_driver: EFI block driver
On 01/17/2018 08:16 PM, Heinrich Schuchardt wrote: > This patch provides > * a uclass for EFI drivers > * a EFI driver for block devices > > For each EFI driver the uclass > * creates a handle > * adds the driver binding protocol > > The uclass provides the bind, start, and stop entry points for the driver > binding protocol. > > In bind() and stop() it checks if the controller implements the protocol > supported by the EFI driver. In the start() function it calls the bind() > function of the EFI driver. In the stop() function it destroys the child > controllers. > > The EFI block driver binds to controllers implementing the block io > protocol. > > When the bind function of the EFI block driver is called it creates a > new U-Boot block device. It installs child handles for all partitions and > installs the simple file protocol on these. > > The read and write functions of the EFI block driver delegate calls to the > controller that it is bound to. > > A usage example is as following: > > U-Boot loads the iPXE snp.efi executable. iPXE connects an iSCSI drive and > exposes a handle with the block IO protocol. It calls ConnectController. > > Now the EFI block driver installs the partions with the simple file > protocol. > > iPXE uses the simple file protocol to load Grub or the Linux Kernel. > > Signed-off-by: Heinrich Schuchardt > --- > v2 > Print to console only in debug mode. > Provide more comments. > Add commit message. > --- > common/board_r.c | 3 + > drivers/block/blk-uclass.c| 4 +- > include/blk.h | 1 + > include/config_fallbacks.h| 1 + > include/dm/uclass-id.h| 1 + > include/efi_driver.h | 30 > include/efi_loader.h | 2 + > lib/Makefile | 1 + > lib/efi_driver/Makefile | 13 ++ > lib/efi_driver/efi_block_device.c | 175 > lib/efi_driver/efi_uclass.c | 330 > ++ > 11 files changed, 560 insertions(+), 1 deletion(-) > create mode 100644 include/efi_driver.h > create mode 100644 lib/efi_driver/Makefile > create mode 100644 lib/efi_driver/efi_block_device.c > create mode 100644 lib/efi_driver/efi_uclass.c > > diff --git a/common/board_r.c b/common/board_r.c > index 2baa47f3a0..4ad37ee31a 100644 > --- a/common/board_r.c > +++ b/common/board_r.c > @@ -715,7 +715,10 @@ static init_fnc_t init_sequence_r[] = { > set_cpu_clk_info, /* Setup clock information */ > #endif > #ifdef CONFIG_EFI_LOADER > + /* Setup EFI memory before any other EFI related code */ > efi_memory_init, > + /* Install EFI drivers */ > + efi_driver_init, > #endif > stdio_init_tables, > initr_serial, > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c > index 010ed32d3a..bfda2211f0 100644 > --- a/drivers/block/blk-uclass.c > +++ b/drivers/block/blk-uclass.c > @@ -24,6 +24,7 @@ static const char *if_typename_str[IF_TYPE_COUNT] = { > [IF_TYPE_HOST] = "host", > [IF_TYPE_SYSTEMACE] = "ace", > [IF_TYPE_NVME] = "nvme", > + [IF_TYPE_EFI] = "efi", > }; > > static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = { > @@ -36,8 +37,9 @@ static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = { > [IF_TYPE_SD]= UCLASS_INVALID, > [IF_TYPE_SATA] = UCLASS_AHCI, > [IF_TYPE_HOST] = UCLASS_ROOT, > - [IF_TYPE_NVME] = UCLASS_NVME, > [IF_TYPE_SYSTEMACE] = UCLASS_INVALID, > + [IF_TYPE_NVME] = UCLASS_NVME, > + [IF_TYPE_EFI] = UCLASS_EFI, > }; > > static enum if_type if_typename_to_iftype(const char *if_typename) > diff --git a/include/blk.h b/include/blk.h > index 41b4d7efa8..69b5a98e56 100644 > --- a/include/blk.h > +++ b/include/blk.h > @@ -34,6 +34,7 @@ enum if_type { > IF_TYPE_HOST, > IF_TYPE_SYSTEMACE, > IF_TYPE_NVME, > + IF_TYPE_EFI, > > IF_TYPE_COUNT, /* Number of interface types */ > }; > diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h > index 2c4d43d672..524313d5aa 100644 > --- a/include/config_fallbacks.h > +++ b/include/config_fallbacks.h > @@ -52,6 +52,7 @@ > defined(CONFIG_MMC) || \ > defined(CONFIG_NVME) || \ > defined(CONFIG_SYSTEMACE) || \ > + (defined(CONFIG_EFI_LOADER) && !defined(CONFIG_SPL_BUILD)) || \ > defined(CONFIG_SANDBOX) > #define HAVE_BLOCK_DEVICE > #endif > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h > index 3fc20834ae..07fabc3ce6 100644 > --- a/include/dm/uclass-id.h > +++ b/include/dm/uclass-id.h > @@ -34,6 +34,7 @@ enum uclass_id { > UCLASS_CROS_EC, /* Chrome OS EC */ > UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */ > UCLASS_DMA, /* Direct Memory Access */ > + UCLASS_EFI, /* EFI managed devic
[U-Boot] [PATCH] boston: Ensure DDR address calcuations don't overflow
When constraining the highest DDR address that U-Boot will use for its data & relocated self, we need to handle the common case in which a 32 bit system with 2GB DDR will have a zero gd->ram_top, due to the addition of 2GB (0x8000) to the base address of kseg0 (also 0x8000) which overflows & wraps to 0. We originally had a check for this case, but it was lost in commit 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") causing problems for the affected 32 bit systems. Signed-off-by: Paul Burton Fixes: 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") Cc: Daniel Schwierzeck --- Feel free to fold this into 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") if you prefer Daniel. board/imgtec/boston/ddr.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/board/imgtec/boston/ddr.c b/board/imgtec/boston/ddr.c index 00428496bd..892bb1754c 100644 --- a/board/imgtec/boston/ddr.c +++ b/board/imgtec/boston/ddr.c @@ -26,6 +26,15 @@ int dram_init(void) ulong board_get_usable_ram_top(ulong total_size) { DECLARE_GLOBAL_DATA_PTR; + ulong max_top; - return min_t(ulong, gd->ram_top, (ulong)phys_to_virt(SZ_256M)); + /* Limit memory use to the top of (c)kseg0 */ + max_top = (ulong)phys_to_virt(SZ_256M); + + if (gd->ram_top < (ulong)phys_to_virt(0)) { + /* >= 2GB RAM on a 32 bit system wrapped around to 0 */ + return max_top; + } + + return min_t(ulong, gd->ram_top, max_top); } -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] log: Support control over the log output format
Hi, On 28 December 2017 at 12:14, Simon Glass wrote: > This adds a few more features to the log system: > > - 'log format' command to control the log output format > - 'log rec' command to output a log record manually > - log_ret() function to log error-return values > > With these we have more control over how log records are output as well > as the ability to log errors more easily. > > > Simon Glass (9): > dm: core: Add a function to look up a uclass by name > log: Add functions to convert IDs to/from names > log: Add control over log formatting > log: Update log_console to honour the log format > log: Add a command to control the log output format > log: Add a command to output a log record > log: Add tests for the new log features > log: Add documentation for commands and formatting > log: Add a way to log error-return values > > cmd/log.c | 82 > +++ > common/Kconfig| 13 +++ > common/log.c | 68 > common/log_console.c | 27 - > configs/sandbox_defconfig | 1 + > doc/README.log| 35 + > drivers/core/uclass.c | 14 +++ > include/asm-generic/global_data.h | 1 + > include/dm/uclass.h | 8 > include/log.h | 64 +- > test/dm/core.c| 9 + > test/py/tests/test_log.py | 32 +-- > 12 files changed, 348 insertions(+), 6 deletions(-) > > -- > 2.15.1.620.gb9897f4670-goog > Are there any comments / reviews on this series, please? I'd like to apply it in this merge window. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] sandbox: Add 64-bit sandbox
Hi Mario, On 15 January 2018 at 20:28, Simon Glass wrote: > Hi Mario, > > On 14 January 2018 at 23:23, Mario Six wrote: >> Hi Simon, >> >> On Fri, Dec 29, 2017 at 4:13 AM, Simon Glass wrote: >>> Hi Mario, >>> >>> On 20 December 2017 at 07:31, Mario Six wrote: From: Mario Six To debug device tree issues involving 32- and 64-bit platforms, it is useful to have a generic 64-bit platform available. Add a version of the sandbox that uses 64-bit integers for its physical addresses as well as a modified device tree. Signed-off-by: Mario Six --- arch/sandbox/Kconfig | 6 + arch/sandbox/cpu/cpu.c | 2 +- arch/sandbox/dts/Makefile| 4 + arch/sandbox/dts/sandbox64.dts | 317 +++ arch/sandbox/include/asm/io.h| 6 + arch/sandbox/include/asm/types.h | 14 +- cmd/demo.c | 6 +- configs/sandbox64_defconfig | 200 drivers/demo/demo-simple.c | 2 +- 9 files changed, 550 insertions(+), 7 deletions(-) create mode 100644 arch/sandbox/dts/sandbox64.dts create mode 100644 configs/sandbox64_defconfig >>> >>> Reviewed-by: Simon Glass >>> >>> Can you please update the sandbox README? >>> >> >> Sure, I'll extend the README. >> >>> Also, how does this play with CONFIG_SANDBOX_64BIT and CONFIG_PHYS_64BIT ? >>> >> >> Yeah, the names of the config options are all a bit confusing (hence why I >> added the RFC to see if someone may have a better idea). Setting the >> CONFIG_PHYS_64BIT is not strictly necessary for the 64-bit sandbox, but some >> architectures use the option to decide whether they run on a 32- or 64-bit >> system, so I thought it was consistent to also set it, just in case. The >> CONFIG_SANDBOX_64BIT option causes a 64-bit sandbox *binary* to be built. >> This >> binary still uses 32-bit-wide types in the device tree (phys_addr_t and >> phys_size_t, mostly, so the width of the physical addresses are still >> 32-bit), >> so that's not what we want in this case. I decided to override the type >> definitions in arch/sandbox/include/asm/types.h based on CONFIG_SANDBOX64 >> directly, since I didn't want to introduce yet another option that has the >> words sandbox and 64 in its name. But it's pretty confusing still, I admit. >> >> Maybe we could rename CONFIG_SANDBOX_64BIT to CONFIG_HOST_64BIT, and use >> CONFIG_PHYS_64BIT to control the width of the physical addresses in types.h >> (which is what it is used for in arch/arm/include/asm/types.h now that I'm >> taking a closer look); that would at least make the names congruent with >> their >> actual semantics. We would then have the options CONFIG_HOST_64BIT, >> CONFIG_PHYS_64BIT, and CONFIG_SANDBOX64 as the "board option". >> >> Maybe that's a cleaner solution? > > Yes I think that is a good idea. Do you have a new version in the works? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dtoc: Allow DTC environment variable to provide path to dtc
On 24 December 2017 at 11:12, Simon Glass wrote: > The system device-tree compiler may not be new enough to run the tests we > use in U-Boot (e.g. with binman). Allow use of a DTC environment variable > to point to the correct dtc. If not defined, the dtc on the default PATH > is used. > > Signed-off-by: Simon Glass > --- > > tools/binman/README| 4 > tools/dtoc/fdt_util.py | 3 ++- > 2 files changed, 6 insertions(+), 1 deletion(-) Applied to u-boot-dm (and now in mainline). Sorry for the delay. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] test: Set the DTC environment variable
On 24 December 2017 at 11:12, Simon Glass wrote: > Set this to our own device-tree compiler since we know it is new enough to > run the tests. > > Signed-off-by: Simon Glass > --- > > test/run | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > Applied to u-boot-dm (and now in mainline). Sorry for the delay. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: store DT in EFI_RUNTIME_SERVICES_DATA memory
The device tree is needed at runtime. So we have to store it in EFI_RUNTIME_SERVICES_DATA memory. The UEFI spec recommends to store all configuration tables in EFI_RUNTIME_SERVICES_DATA memory. Signed-off-by: Heinrich Schuchardt --- cmd/bootefi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 97a4f269ae..a30259c4c1 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -103,11 +103,11 @@ static void *copy_fdt(void *fdt) /* Safe fdt location is at 128MB */ new_fdt_addr = fdt_ram_start + (128 * 1024 * 1024) + fdt_size; - if (efi_allocate_pages(1, EFI_BOOT_SERVICES_DATA, fdt_pages, + if (efi_allocate_pages(1, EFI_RUNTIME_SERVICES_DATA, fdt_pages, &new_fdt_addr) != EFI_SUCCESS) { /* If we can't put it there, put it somewhere */ new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size); - if (efi_allocate_pages(1, EFI_BOOT_SERVICES_DATA, fdt_pages, + if (efi_allocate_pages(1, EFI_RUNTIME_SERVICES_DATA, fdt_pages, &new_fdt_addr) != EFI_SUCCESS) { printf("ERROR: Failed to reserve space for FDT\n"); return NULL; -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] boston: Pad binary in .mcs to a multiple of 16 bytes
When flashing U-Boot on a Boston board using Xilinx Vivado tools, the final 0x00 byte which ends the .relocs section seems to be skipped & left in flash as 0xff unless the data contained in the .mcs is padded out to a 16 byte boundary. Without our final zero byte relocation will fail with an error about a spurious reloc: Avoid this problem by padding out the data in the .mcs file to a 16 byte boundary using srec_cat's -range-pad functionality. Signed-off-by: Paul Burton Cc: Daniel Schwierzeck --- board/imgtec/boston/config.mk | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/board/imgtec/boston/config.mk b/board/imgtec/boston/config.mk index 2775727744..0ba8802da0 100644 --- a/board/imgtec/boston/config.mk +++ b/board/imgtec/boston/config.mk @@ -3,7 +3,10 @@ # quiet_cmd_srec_cat = SRECCAT $@ - cmd_srec_cat = srec_cat -output $@ -$2 $< -binary -offset $3 + cmd_srec_cat = srec_cat -output $@ -$2 \ + $< -binary \ + -fill 0x00 -within $< -binary -range-pad 16 \ + -offset $3 u-boot.mcs: u-boot.bin $(call cmd,srec_cat,intel,0x7c0) -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/18] efi_loader: enable EFI driver provided block device
Hi Heinrich, On 17 January 2018 at 11:15, Heinrich Schuchardt wrote: > With this patch series an EFI application or driver can supply > a block device which in turn can be used to download an image. > > E.g. we can load iPXE, connect iSCSI drives, download grub from the > SAN and afterwards with grub download and run an EFI application. > Booting Linux from an iSCSI drive was successful on arm64. > > v2: > Add an additional patch to fix ExitBootServices. > Provide comments for EFI block driver. > Avoid printing when not in debug mode > Add product tools/file2include to .gitignore. > Put the patch with the test for block io after the patch for the > driver. > > Heinrich Schuchardt (18): > efi_loader: return NULL from device path functions > efi_loader: address of the simple file system protocol > efi_loader: correct find simple file system protocol > efi_loader: print device path when entering efi_load_image > efi_loader: allocate correct memory type for EFI image > efi_loader: check tables in helloworld.efi > efi_loader: fix StartImage bootservice > efi_loader: efi_disk_register: correctly determine if_type_name > efi_loader: make efi_block_io_guid a global symbol > efi_loader: provide a function to create a partition node > efi_loader: make efi_disk_create_partitions a global symbol > efi_loader: correct EFI_BLOCK_IO_PROTOCOL definitions > efi_loader: provide function to get last node of a device path > efi_loader: provide links between devices EFI handles > tools: provide a tool to convert a binary file to an include > efi_driver: EFI block driver > efi_selftest: provide a test for block io > efi_loader: fix ExitBootServices > > MAINTAINERS | 1 + > common/board_r.c | 3 + > drivers/block/blk-uclass.c | 4 +- > include/blk.h| 1 + > include/config_fallbacks.h | 1 + > include/dm/device.h | 4 + > include/dm/uclass-id.h | 1 + > include/efi_api.h| 16 +- > include/efi_driver.h | 30 ++ > include/efi_loader.h | 21 +- > lib/Makefile | 1 + > lib/efi_driver/Makefile | 13 + > lib/efi_driver/efi_block_device.c| 175 > lib/efi_driver/efi_uclass.c | 330 ++ > lib/efi_loader/efi_boottime.c| 42 ++- > lib/efi_loader/efi_device_path.c | 168 +--- > lib/efi_loader/efi_disk.c| 137 +++--- > lib/efi_loader/efi_image_loader.c| 64 +++-- > lib/efi_loader/helloworld.c | 26 ++ > lib/efi_selftest/Makefile| 4 + > lib/efi_selftest/efi_selftest_block_device.c | 395 > +++ > lib/efi_selftest/efi_selftest_disk_image.h | 69 + > tools/.gitignore | 1 + > tools/Makefile | 3 + > tools/file2include.c | 106 +++ > 25 files changed, 1493 insertions(+), 123 deletions(-) > create mode 100644 include/efi_driver.h > create mode 100644 lib/efi_driver/Makefile > create mode 100644 lib/efi_driver/efi_block_device.c > create mode 100644 lib/efi_driver/efi_uclass.c > create mode 100644 lib/efi_selftest/efi_selftest_block_device.c > create mode 100644 lib/efi_selftest/efi_selftest_disk_image.h > create mode 100644 tools/file2include.c > > -- > 2.14.2 > Do you have a git tree with these patches? I get errors when applying them. Some general comments for discussion, based on my limited understanding. At present from what I can tell, this looks through the UCLASS_EFI drivers and instantiates a EFI driver/device for each. But it does not seem to relate this to the U-Boot driver. It seems in fact to create a new device. For example efi_bl_bind() calls blk_create_device(). Instead I think there should be a real driver-rmodel device creasted with UCLASS_EFI. It should be a child of the DM UCLASS_BLK device. The could work in a similar way to now, except that it can scan DM devices of a particular UCLASS rather than scanning DM drivers. Also the patch that creates a tool to generate a binary as a header file - can we use the same method as we use for other embedding? See for example how .dtb is done. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: remove unused ret
On 18 January 2018 at 11:19, Jelle van der Waa wrote: > Remove unused ret from fw_env_flush. > > Signed-off-by: Jelle van der Waa > --- > tools/env/fw_env.c | 2 -- > 1 file changed, 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: console: Add serial devices probe command
Hi Wilson, On 6 November 2017 at 00:50, Wilson Lee wrote: > U-boot will only probe and register single serial device that selected U-Boot > to be used as stdio device. This will cause changing of stdio devices > from one serial devices to another serial devices is not possible due > to others serial devices are not registered on the stdio list. This > command will allow user to probe others possible serial console and > register them to stdio list for stdio switching. The wording of this seems confusing to me. How about this as a suggestion: U-Boot only probes a single serial device to be used as a stdio device. This means that changing from one serial device to another is not possible. Add a command to ... Anyway, please see below > > Signed-off-by: Wilson Lee > Cc: Joe Hershberger > Cc: Keng Soon Cheah > Cc: Chen Yee Chew > --- > cmd/console.c | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git a/cmd/console.c b/cmd/console.c > index 9a356ec..5bf897f 100644 > --- a/cmd/console.c > +++ b/cmd/console.c > @@ -8,6 +8,7 @@ > /* > * Boot support > */ > +#include > #include > #include > #include > @@ -43,6 +44,22 @@ static int do_coninfo(cmd_tbl_t *cmd, int flag, int argc, > char * const argv[]) > return 0; > } > > +static int do_conprobe(cmd_tbl_t *cmd, int flag, int argc, char * const > argv[]) > +{ > + struct udevice *dev; > + struct uclass *uc; > + > + uclass_get(UCLASS_SERIAL, &uc); This needs error checking. > + uclass_foreach_dev(dev, uc) { > + /* > +* Loop through all serial devices, probe and register > +* them with stdio services. > +*/ > + if (device_probe(dev)) > + debug("%s: %s: PROBE FAIL\n", __func__, dev->name); > + } > + return 0; > +} Do you think it would be safe to add this code in serial_stdio_init() instead? We do this for UCLASS_VIDEO and UCLASS_KEYBOARD. See stdio_add_devices() for this logic. Then we would not need this command. > > /***/ > > @@ -51,3 +68,9 @@ U_BOOT_CMD( > "print console devices and information", > "" > ); > + > +U_BOOT_CMD( > + conprobe, 3, 1, do_conprobe, > + "probe serial devices and register with stdio list", > + "" > +); > -- > 2.7.4 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] board: ls1012a: LS1012A-2G5RDB board support
On 01/11/2018 11:24 AM, Bhaskar Upadhaya wrote: > LS1012A-2G5RDB belongs to LS1012A family with features > 2 2.5G SGMII PFE MAC, SATA, USB 2.0/3.0, WiFi > DDR, eMMC, QuadSPI, UART > > Signed-off-by: Bhaskar Upadhaya > --- > changes for v2: > - LS1012A-2G5RDB patches are made independent of PFE patches > - Remove CONFIG_CMD_DHCP, CONFIG_CMD_MII, CONFIG_FSL_PFE. CONFIG_DM_MMC_OPS > - created ls1012a2g5rdb_qspi_defconfig after running savedefconfig Minor change to commit message. Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] armv8/kconfig: Align boards of same family at one place
On 01/11/2018 11:23 AM, Bhaskar Upadhaya wrote: > Align boards belonging to LS1012A, LS2080A SoC at > one place > > Signed-off-by: Bhaskar Upadhaya > --- Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: lpuart: Proper device identification
On 01/09/2018 10:27 PM, Sriram Dash wrote: > Identify and distinguish between platform device type of MX7ULP > and LS1021A. > > This is a fix to: 7edf5c45 serial: lpuart: add i.MX7ULP support > > Signed-off-by: Sriram Dash > Acked-by: Peng Fan > --- Minor change to reference of previous commit. Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8/ls1088a: configure PMU's PCTBENR to enable WDT
On 01/09/2018 12:45 AM, ying.zhang22...@nxp.com wrote: > From: Zhang Ying-22455 > > The SP805-WDT module on LS1088A requires configuration of PMU's > PCTBENR register to enable watchdog counter decrement and reset > signal generation. The watchdog clock needs to be enabled first. > > Signed-off-by: Zhang Ying-22455 Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board/ls2081ardb: Update board related prints
On 01/07/2018 11:29 PM, Priyanka Jain wrote: > Remove Board Arch print as its value is always > constant '1' and does not contain any important > information to display during boot > > Add print to display Board FPGA version. > > Signed-off-by: Priyanka Jain > --- Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] configs: SECURE_BOOT: Enable CONFIG_CMD_EXT4_WRITE
On 01/08/2018 12:23 AM, Sumit Garg wrote: > As part of chain of trust with confidentiality along with distro > boot, linux kernel image needs to be stored in encrypted form on > ext4 boot partition. So enable CONFIG_CMD_EXT4_WRITE in case of > Secure boot on ARM based platforms. > > Signed-off-by: Sumit Garg > Reviewed-by: Tom Rini > --- > > Changes in v3: > Enable CMD_EXT4_WRITE option for ARM platforms only. > > Changes in v2: > Instead of adding CMD_EXT4_WRITE option in each defconfig, added this > option in Kconfig. Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board/ls2081ard: Correct code to get QMAP value in checkboard
On 01/07/2018 10:51 PM, Priyanka Jain wrote: > QMAP value contains information about QSPI chip-selects. > These bits are used to display information of boot device > in checkboard() function. > > QMAP value is stored in most significant 3-bits > of 8-bit register brdcfg[0] in Qixis, this patch > corrects code to get QMAP bits using below logic: > (brdcfg[0] >> 5) & 0x7 > > Signed-off-by: Priyanka Jain > --- Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot