[U-Boot] [PATCH v2] ubi: Ensure no fastmap flush after uif_close

[Martin Townsend]

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

[Jaehoon Chung]

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

[Simon Goldschmidt]

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

[Michael Nazzareno Trimarchi]

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

[Simon Goldschmidt]

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

[Michael Nazzareno Trimarchi]

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

[Michal Simek]

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

[Michal Simek]

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

[Stefano Babic]

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

[Guillaume Gardet]

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

[Peng Fan]

> 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

[Guillaume Gardet]

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

[Alexander Graf]

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

[Alexander Graf]

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

[Heinrich Schuchardt]

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

[Alexander Graf]

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

[Heinrich Schuchardt]

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

[Alexander Graf]

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

[Marek Vasut]

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

[Bryan O'Donoghue]

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

[patrice.chotard]

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

[patrice.chotard]

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

[patrice.chotard]

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

[patrice.chotard]

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

[patrice.chotard]

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

[patrice.chotard]

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

[patrice.chotard]

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

[Michal Simek]

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

[Tom Rini]

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

[patrice.chotard]

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

[patrice.chotard]

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

[patrice.chotard]

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()

[patrice.chotard]

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

[Pankaj Bansal]

> -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

[Dr. Philipp Tomsich]

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

[Tom Rini]

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

[Tom Rini]

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

[Krehic, Damir]

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

[Leo Li]

> -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

[Gaëtan Carlier]

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

[Michal Simek]

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

[Tom Rini]

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

[Lokesh Vutla]

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

[Lokesh Vutla]

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

[Pankaj Bansal]

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

[Eric Nelson]

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

[vnktux]

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

[Maxime Ripard]

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

[Eric Nelson]

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

[Diego Dorta]

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

[Fabio Estevam]

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

[Fabio Estevam]

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

[Maxime Ripard]

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

[Eric Nelson]

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

[Alexander Graf]

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

[Alexander Graf]

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

[Alexander Graf]

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

[Heinrich Schuchardt]

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

[Stefan Roese]

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

[Maxime Ripard]

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

[York Sun]

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

[Simon Glass]

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

[Andreas Färber]

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

[Tom Rini]

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

[York Sun]

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

[Tom Rini]

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

[York Sun]

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

[Tom Rini]

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

[Alexander Graf]

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

[York Sun]

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

[Heinrich Schuchardt]

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

[Alexander Graf]

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

[York Sun]

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

[Alexander Graf]

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

[Tom Rini]

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

[Jelle van der Waa]

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

[Heinrich Schuchardt]

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

[Heinrich Schuchardt]

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

[Heinrich Schuchardt]

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

[Heinrich Schuchardt]

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

[Anand Moon]

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

[York Sun]

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

[Heinrich Schuchardt]

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

[Paul Burton]

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

[Simon Glass]

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

[Simon Glass]

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

[Simon Glass]

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

[Simon Glass]

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

[Heinrich Schuchardt]

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

[Paul Burton]

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

[Simon Glass]

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

[Simon Glass]

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

[Simon Glass]

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

[York Sun]

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

[York Sun]

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

[York Sun]

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

[York Sun]

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

[York Sun]

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

[York Sun]

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

[York Sun]

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