[U-Boot] [PATCH] cmd: nvedit: env_get_f must check for env_get_char error codes

2018-01-30 Thread Simon Goldschmidt
env_get_f calls env_get_char to load single characters from the
environment. However, the return value of env_get_char was not
checked for errors. Now if the env driver does not support the
.get_char call, env_get_f did not notice this and looped over the
whole size of the environment, calling env_get_char over 8000
times with the default settings, just to return an error in the
end.

Fix this by checking if env_get_char returns < 0.

Signed-off-by: Simon Goldschmidt 
---

 cmd/nvedit.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index a690d743cd..4cb25b8248 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -650,12 +650,14 @@ char *env_get(const char *name)
  */
 int env_get_f(const char *name, char *buf, unsigned len)
 {
-   int i, nxt;
+   int i, nxt, c;
 
for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) {
int val, n;
 
-   for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) {
+   for (nxt = i; (c = env_get_char(nxt)) != '\0'; ++nxt) {
+   if (c < 0)
+   return c;
if (nxt >= CONFIG_ENV_SIZE)
return -1;
}
@@ -666,7 +668,10 @@ int env_get_f(const char *name, char *buf, unsigned len)
 
/* found; copy out */
for (n = 0; n < len; ++n, ++buf) {
-   *buf = env_get_char(val++);
+   c = env_get_char(val++);
+   if (c < 0)
+   return c;
+   *buf = c;
if (*buf == '\0')
return n;
}
-- 
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 v3 09/15] env: Support multiple environments

2018-01-30 Thread Simon Goldschmidt

On 31.01.2018 00:02, York Sun wrote:

On 01/30/2018 12:16 PM, York Sun wrote:

On 01/30/2018 11:40 AM, York Sun wrote:

On 01/30/2018 12:19 AM, Simon Goldschmidt wrote:

On 23.01.2018 21:16, Maxime Ripard wrote:

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected,

Does priority handling really work here? Most env drivers seem to ignore
the return value of env_import and may thus return success although
importing the environment failed (only reading the data from the device
succeeded).

This is from reading the code, I haven't had a chance to test this, yet.

It is broken on my LS1043ARDB with simply NOR flash. I am trying to
determine what went wrong.


I found the problem. The variable "env_load_location" is static. It is
probably not write-able during booting from flash. It is expected to be
set during ENVOP_INIT. But if I print this variable, it has
ENVL_UNKNOWN. I can make it work by moving env_load_location to global
data structure.

That being said, this addition of multiple environments really slows
down the booting process for me. I see every time env_get_char() is
called, env_driver_lookup() runs. A simple call of env_get_f() gets
slowed down dramatically. I didn't find out where the most time is spent
yet.

Does anyone else experience this unbearable slowness?


Yes. Depending on CPU speed... :-)

On my board, that slowdown comes from the fact that env_get_f does not 
check the return value of env_get_char for an error. That leads to 
trying for CONFIG_ENV_SIZE times, which is of course slow.

I'll post a fix for that.


I found the problem. In patch #3 in this series, the default get_char()
was dropped so there is no driver for a plain NOR flash. A quick (and
maybe dirty) fix is this


That patch #3 actually changed the behavior for all env drivers not 
providing .get_char (so all drivers except for eeprom and nvram) from 
returning what's behind gd->env_addr. Your patch below restores the old 
behaviour.


I can't tell what's the correct behaviour though: in my tests, env_get_f 
got called even after importing the environment, which is not what I 
would have expected...



diff --git a/env/env.c b/env/env.c
index edfb575..210bae2 100644
--- a/env/env.c
+++ b/env/env.c
@@ -159,7 +159,7 @@ int env_get_char(int index)
 int ret;

 if (!drv->get_char)
-   continue;
+   return *(uchar *)(gd->env_addr + index);

 if (!env_has_inited(drv->location))
 continue;

With this temporary fix, my flash chip works again and I can boot all
the way up in a timely manner. I still don't like to call
env_driver_lookup() thousands of times to get a simple env variable.


That's not a thing Maxime has changed but a change that came in when 
adding environment drivers.


Simon



Can Maxime post a quick post soon?

York



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] arm64: ls1012ardb: Add distro secure boot support

2018-01-30 Thread Sumit Garg
> -Original Message-
> From: York Sun
> Sent: Tuesday, January 30, 2018 2:57 AM
> To: Sumit Garg ; u-boot@lists.denx.de
> Cc: Ruchika Gupta ; Prabhakar Kushwaha
> ; Vini Pillai 
> Subject: Re: [PATCH v2] arm64: ls1012ardb: Add distro secure boot support
> 
> On 01/15/2018 09:34 AM, Sumit Garg wrote:
> >> From: York Sun
> >> Sent: Monday, January 15, 2018 10:59 PM
> >>
> >> On 01/08/2018 09:59 PM, Sumit Garg wrote:
> >>> From: Vinitha Pillai-B57223 
> >>>
> >>> Enable validation of boot.scr script prior to its execution
> >>> dependent on "secureboot" flag in environment. Enable fall back
> >>> option to qspi boot in case of secure boot.
> >>>
> >>> Signed-off-by: Sumit Garg 
> >>> Signed-off-by: Vinitha Pillai 
> >>> ---
> >>>
> >>> Changes in v2:
> >>> Rebased to top of master
> >>>
> >>>  configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 14 +++---
> >>>  include/configs/ls1012ardb.h  | 20 ++--
> >>>  2 files changed, 25 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> >>> b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> >>> index b6930be..2d5d9ad 100644
> >>> --- a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> >>> +++ b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
> >>> @@ -2,7 +2,9 @@ CONFIG_ARM=y
> >>>  CONFIG_TARGET_LS1012ARDB=y
> >>>  CONFIG_SECURE_BOOT=y
> >>>  CONFIG_FSL_LS_PPA=y
> >>> +CONFIG_QSPI_AHB_INIT=y
> >>>  CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
> >>> +CONFIG_DISTRO_DEFAULTS=y
> >>>  # CONFIG_SYS_MALLOC_F is not set
> >>>  CONFIG_FIT_VERBOSE=y
> >>>  CONFIG_OF_BOARD_SETUP=y
> >>> @@ -12,7 +14,7 @@ CONFIG_QSPI_BOOT=y
> >>>  CONFIG_BOOTDELAY=10
> >>>  CONFIG_USE_BOOTARGS=y
> >>>  CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> >> earlycon=uart8250,mmio,0x21c0500 quiet lpj=25"
> >>> -CONFIG_HUSH_PARSER=y
> >>> +# CONFIG_DISPLAY_BOARDINFO is not set
> >>>  CONFIG_CMD_GREPENV=y
> >>>  CONFIG_CMD_GPT=y
> >>>  CONFIG_CMD_I2C=y
> >>> @@ -20,16 +22,13 @@ CONFIG_CMD_MMC=y  CONFIG_CMD_PCI=y
> >>> CONFIG_CMD_SF=y  CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is
> not set
> >>> -CONFIG_CMD_DHCP=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y
> >>> CONFIG_CMD_CACHE=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_FAT=y
> >>> CONFIG_OF_CONTROL=y
> >>> +CONFIG_ENV_IS_IN_SPI_FLASH=y
> 
> This is wrong. You shouldn't have ENV for secure boot. Please double check.
> 
> York
 
Yes you are correct. We should drop this from defconfig. Shall I send next 
version or could you drop it while applying the patch?

BTW we select ENV_IS_NOWHERE in case of Secure boot.

Sumit
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Convert CONFIG_SYS_OMAP24_I2C_SLAVE et al to Kconfig

2018-01-30 Thread Tom Rini
On Wed, Jan 24, 2018 at 03:21:21PM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_OMAP24_I2C_SLAVE
>CONFIG_SYS_OMAP24_I2C_SPEED
> 
> Signed-off-by: Adam Ford 
> Reviewed-by: Paul Kocialkowski 

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] [U-Boot, V4] Convert CONFIG_SYS_DV_CLKMODE et al to Kconfig

2018-01-30 Thread Tom Rini
On Tue, Jan 23, 2018 at 04:04:28AM -0600, Adam Ford wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_DV_CLKMODE
>CONFIG_SYS_DA850_PLL0_POSTDIV
>CONFIG_SYS_DA850_PLL0_PLLDIV1
>CONFIG_SYS_DA850_PLL0_PLLDIV2
>CONFIG_SYS_DA850_PLL0_PLLDIV3
>CONFIG_SYS_DA850_PLL0_PLLDIV4
>CONFIG_SYS_DA850_PLL0_PLLDIV5
>CONFIG_SYS_DA850_PLL0_PLLDIV6
>CONFIG_SYS_DA850_PLL0_PLLDIV7
>CONFIG_SYS_DA850_PLL1_POSTDIV
>CONFIG_SYS_DA850_PLL1_PLLDIV1
>CONFIG_SYS_DA850_PLL1_PLLDIV2
>CONFIG_SYS_DA850_PLL1_PLLDIV3
> 
> Signed-off-by: Adam Ford 

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] [U-Boot, v2] Convert CONFIG_SYS_BOOT_GET_{CMDLINE, KBD} to Kconfig

2018-01-30 Thread Tom Rini
On Mon, Jan 22, 2018 at 05:17:10PM -0600, Derald D. Woods wrote:

> This converts the following to Kconfig:
>   CONFIG_SYS_BOOT_GET_CMDLINE
>   CONFIG_SYS_BOOT_GET_KBD
> 
> Signed-off-by: Derald D. Woods 

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


[U-Boot] [RFC 1/1] dm: video: tegra124: incorrect logical condition

2018-01-30 Thread Heinrich Schuchardt
2 << 24 | A is always true. To use check against a bitmask we need &.

Identified with cppcheck.

Signed-off-by: Heinrich Schuchardt 
---
I do not have the hardware available. But the current coding is fishy.

Please, clarify what should be coded here.
---
 drivers/video/tegra124/sor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/tegra124/sor.c b/drivers/video/tegra124/sor.c
index 700ab25d46..4b3381fae2 100644
--- a/drivers/video/tegra124/sor.c
+++ b/drivers/video/tegra124/sor.c
@@ -669,7 +669,7 @@ static void tegra_dc_sor_config_panel(struct 
tegra_dc_sor_data *sor,
tegra_sor_write_field(sor, CSTM,
  CSTM_ROTCLK_DEFAULT_MASK |
  CSTM_LVDS_EN_ENABLE,
- 2 << CSTM_ROTCLK_SHIFT |
+ 2 << CSTM_ROTCLK_SHIFT &
  is_lvds ? CSTM_LVDS_EN_ENABLE :
  CSTM_LVDS_EN_DISABLE);
 
-- 
2.15.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] atcspi200: avoid possible NULL dereference

2018-01-30 Thread Heinrich Schuchardt
Check if ns before and not after dereferencing it.

Indicated by cppcheck.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/spi/atcspi200_spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/atcspi200_spi.c b/drivers/spi/atcspi200_spi.c
index 3e29df03a4..5b2e9d6264 100644
--- a/drivers/spi/atcspi200_spi.c
+++ b/drivers/spi/atcspi200_spi.c
@@ -297,6 +297,8 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
return NULL;
 
ns = spi_alloc_slave(struct nds_spi_slave, bus, cs);
+   if (!ns)
+   return NULL;
 
switch (bus) {
case SPI0_BUS:
@@ -316,8 +318,6 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
ns->to = SPI_TIMEOUT;
ns->max_transfer_length = MAX_TRANSFER_LEN;
ns->slave.max_write_size = MAX_TRANSFER_LEN;
-   if (!ns)
-   return NULL;
 
return >slave;
 }
-- 
2.15.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] i2c: mvtwsi.c: Avoid NULL dereference

2018-01-30 Thread Heinrich Schuchardt
For '#ifndef CONFIG_DM_I2C' twsi_i2c_init() passes NULL as
4th parameter to __twsi_i2c_init().

Identified with cppcheck.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/i2c/mvtwsi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index dfbc4e053f..30bee0d52e 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -490,7 +490,8 @@ static void __twsi_i2c_init(struct mvtwsi_registers *twsi, 
int speed,
/* Reset controller */
twsi_reset(twsi);
/* Set speed */
-   *actual_speed = __twsi_i2c_set_bus_speed(twsi, speed);
+   if (actual_speed)
+   *actual_speed = __twsi_i2c_set_bus_speed(twsi, speed);
/* Set slave address; even though we don't use it */
writel(slaveadd, >slave_address);
writel(0, >xtnd_slave_addr);
-- 
2.15.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] rockchip: gpio: remove dead code

2018-01-30 Thread Dr. Philipp Tomsich

> On 31 Jan 2018, at 00:45, Heinrich Schuchardt  wrote:
> 
> In the following statements
> if (a) return a; if (a) return c;
> the second return can never be executed.
> 
> Identified by cppcheck.
> 
> Signed-off-by: Heinrich Schuchardt 

Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] rockchip: gpio: remove dead code

2018-01-30 Thread Heinrich Schuchardt
In the following statements
if (a) return a; if (a) return c;
the second return can never be executed.

Identified by cppcheck.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/gpio/rk_gpio.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index 11fc3e26bd..2419636c5f 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -86,10 +86,6 @@ static int rockchip_gpio_get_function(struct udevice *dev, 
unsigned offset)
ret = pinctrl_get_gpio_mux(priv->pinctrl, priv->bank, offset);
if (ret)
return ret;
-
-   /* If it's not 0, then it is not a GPIO */
-   if (ret)
-   return GPIOF_FUNC;
is_output = readl(>swport_ddr) & OFFSET_TO_BIT(offset);
 
return is_output ? GPIOF_OUTPUT : GPIOF_INPUT;
-- 
2.15.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 1/1] efi_loader: efi_smbios_register should have a return value

2018-01-30 Thread Heinrich Schuchardt
Errors may occur inside efi_smbios_register().

- Return a status code.
- Remove unused variables.
- Use constants where applicable.

Suggested-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
v2
remove a change in unrelated code
---
 include/efi_loader.h|  2 +-
 lib/efi_loader/efi_smbios.c | 23 +++
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 21c03c5c28..eb86853924 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -185,7 +185,7 @@ int efi_net_register(void);
 /* Called by bootefi to make the watchdog available */
 int efi_watchdog_register(void);
 /* Called by bootefi to make SMBIOS tables available */
-void efi_smbios_register(void);
+efi_status_t efi_smbios_register(void);
 
 struct efi_simple_file_system_protocol *
 efi_fs_from_path(struct efi_device_path *fp);
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index ac412e7362..9ff7651683 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -13,20 +13,27 @@
 
 static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
 
-void efi_smbios_register(void)
+/*
+ * Install the SMBIOS table as a configuration table.
+ *
+ * @return status code
+ */
+efi_status_t efi_smbios_register(void)
 {
/* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
-   uint64_t dmi = 0x;
-   /* Reserve 4kb for SMBIOS */
-   uint64_t pages = 1;
-   int memtype = EFI_RUNTIME_SERVICES_DATA;
+   u64 dmi = U32_MAX;
+   efi_status_t ret;
 
-   if (efi_allocate_pages(1, memtype, pages, ) != EFI_SUCCESS)
-   return;
+   /* Reserve 4kiB page for SMBIOS */
+   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
+EFI_RUNTIME_SERVICES_DATA, 1, );
+   if (ret != EFI_SUCCESS)
+   return ret;
 
/* Generate SMBIOS tables */
write_smbios_table(dmi);
 
/* And expose them to our EFI payload */
-   efi_install_configuration_table(_guid, (void*)(uintptr_t)dmi);
+   return efi_install_configuration_table(_guid,
+  (void *)(uintptr_t)dmi);
 }
-- 
2.15.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments

2018-01-30 Thread York Sun
On 01/30/2018 12:16 PM, York Sun wrote:
> On 01/30/2018 11:40 AM, York Sun wrote:
>> On 01/30/2018 12:19 AM, Simon Goldschmidt wrote:
>>> On 23.01.2018 21:16, Maxime Ripard wrote:
 Now that we have everything in place to support multiple environment, let's
 make sure the current code can use it.

 The priority used between the various environment is the same one that was
 used in the code previously.

 At read / init times, the highest priority environment is going to be
 detected,
>>>
>>> Does priority handling really work here? Most env drivers seem to ignore 
>>> the return value of env_import and may thus return success although 
>>> importing the environment failed (only reading the data from the device 
>>> succeeded).
>>>
>>> This is from reading the code, I haven't had a chance to test this, yet.
>>
>> It is broken on my LS1043ARDB with simply NOR flash. I am trying to
>> determine what went wrong.
>>
> 
> I found the problem. The variable "env_load_location" is static. It is
> probably not write-able during booting from flash. It is expected to be
> set during ENVOP_INIT. But if I print this variable, it has
> ENVL_UNKNOWN. I can make it work by moving env_load_location to global
> data structure.
> 
> That being said, this addition of multiple environments really slows
> down the booting process for me. I see every time env_get_char() is
> called, env_driver_lookup() runs. A simple call of env_get_f() gets
> slowed down dramatically. I didn't find out where the most time is spent
> yet.
> 
> Does anyone else experience this unbearable slowness?
> 

I found the problem. In patch #3 in this series, the default get_char()
was dropped so there is no driver for a plain NOR flash. A quick (and
maybe dirty) fix is this


diff --git a/env/env.c b/env/env.c
index edfb575..210bae2 100644
--- a/env/env.c
+++ b/env/env.c
@@ -159,7 +159,7 @@ int env_get_char(int index)
int ret;

if (!drv->get_char)
-   continue;
+   return *(uchar *)(gd->env_addr + index);

if (!env_has_inited(drv->location))
continue;

With this temporary fix, my flash chip works again and I can boot all
the way up in a timely manner. I still don't like to call
env_driver_lookup() thousands of times to get a simple env variable.

Can Maxime post a quick post soon?

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] mx6sabresd: Add fastboot support

2018-01-30 Thread Fabio Estevam
From: Fabio Estevam 

fastboot tool is a convenient way to flash the eMMC, so
add support for it.

Examples of usages:

On the mx6sabresd:

=> fastboot 0

On the Linux PC connected via USB:

$ sudo fastboot getvar bootloader-version -i 0x0525
bootloader-version: U-Boot 2018.01-00550-g7517cfe
finished. total time: 0.000s

Shawn Guo described the following method for flashing the eMMC
via flashboot:

"I booted the board into Debian via NFS, and then use gpart to create GPT
partitions on the eMMC.  With CONFIG_EFI_PARTITION enabled in U-Boot, I
can list the partitions on eMMC as below.

=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
=> mmc part

Partition Map for MMC device 2  --   Partition Type: EFI

PartStart LBA   End LBA Name
Attributes
Type GUID
Partition GUID
  1 0x0800  0x000407ff  "boot"
attrs:  0x
type:   21686148-6449-6e6f-744e-656564454649
guid:   6137f187-600c-4dc4-8a74-ee8f0250d455
  2 0x00040800  0x002987ff  "system"
attrs:  0x
type:   0fc63daf-8483-4772-8e79-3d69d8477de4
guid:   af78282f-21b5-4324-bf7a-f460d1ae0015
  3 0x00298800  0x003187ff  "vendor"
attrs:  0x
type:   0fc63daf-8483-4772-8e79-3d69d8477de4
guid:   15830513-0195-4e86-9b2c-cd3af5e14570
  4 0x00318800  0x003587ff  "cache"
attrs:  0x
type:   0fc63daf-8483-4772-8e79-3d69d8477de4
guid:   6e909a60-606b-4c43-bbd4-f780afd97302
  5 0x00358800  0x00ecbfde  "data"
attrs:  0x
type:   0fc63daf-8483-4772-8e79-3d69d8477de4
guid:   9e79dc0b-35d9-40f0-b638-3e718362cb26
=> fastboot 0

At this point, I can do 'fastboot flash system system.img -i 0x0525' from
host PC."

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Select CONFIG_EFI_PARTITION=y (Shawn)
- Provide the eMMC flashing procedure (Michael)

 configs/mx6sabresd_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 3e4c13c..9a4184b 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -20,6 +20,12 @@ CONFIG_SPL_USB_HOST_SUPPORT=y
 CONFIG_SPL_USB_GADGET_SUPPORT=y
 CONFIG_SPL_USB_SDP_SUPPORT=y
 CONFIG_HUSH_PARSER=y
+CONFIG_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x1200
+CONFIG_FASTBOOT_BUF_SIZE=0x1000
+CONFIG_FASTBOOT_USB_DEV=0
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=2
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_SPL=y
 CONFIG_CMD_SPL_WRITE_SIZE=0x2
@@ -41,6 +47,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_EFI_PARTITION=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments

2018-01-30 Thread York Sun
On 01/30/2018 11:40 AM, York Sun wrote:
> On 01/30/2018 12:19 AM, Simon Goldschmidt wrote:
>> On 23.01.2018 21:16, Maxime Ripard wrote:
>>> Now that we have everything in place to support multiple environment, let's
>>> make sure the current code can use it.
>>>
>>> The priority used between the various environment is the same one that was
>>> used in the code previously.
>>>
>>> At read / init times, the highest priority environment is going to be
>>> detected,
>>
>> Does priority handling really work here? Most env drivers seem to ignore 
>> the return value of env_import and may thus return success although 
>> importing the environment failed (only reading the data from the device 
>> succeeded).
>>
>> This is from reading the code, I haven't had a chance to test this, yet.
> 
> It is broken on my LS1043ARDB with simply NOR flash. I am trying to
> determine what went wrong.
> 

I found the problem. The variable "env_load_location" is static. It is
probably not write-able during booting from flash. It is expected to be
set during ENVOP_INIT. But if I print this variable, it has
ENVL_UNKNOWN. I can make it work by moving env_load_location to global
data structure.

That being said, this addition of multiple environments really slows
down the booting process for me. I see every time env_get_char() is
called, env_driver_lookup() runs. A simple call of env_get_f() gets
slowed down dramatically. I didn't find out where the most time is spent
yet.

Does anyone else experience this unbearable slowness?

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] efi_loader: use constants in efi_allocate_pages()

2018-01-30 Thread Heinrich Schuchardt
Using the existing predefined constants is less error prone and
makes the code easier to read.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_memory.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index bee0a0c97d..e967e190c8 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -295,7 +295,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
uint64_t addr;
 
switch (type) {
-   case 0:
+   case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
addr = efi_find_free_memory(len, gd->start_addr_sp);
if (!addr) {
@@ -303,7 +303,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
break;
}
break;
-   case 1:
+   case EFI_ALLOCATE_MAX_ADDRESS:
/* Max address */
addr = efi_find_free_memory(len, *memory);
if (!addr) {
@@ -311,7 +311,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
break;
}
break;
-   case 2:
+   case EFI_ALLOCATE_ADDRESS:
/* Exact address, reserve it. The addr is already in *memory. */
addr = *memory;
break;
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/1] efi_loader: efi_smbios_register should have a return value

2018-01-30 Thread Heinrich Schuchardt
Errors may occur inside efi_smbios_register().

- Return a status code.
- Remove unused variables.
- Use constants where applicable.

Suggested-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h|  2 +-
 lib/efi_loader/efi_smbios.c | 18 --
 lib/smbios.c|  2 ++
 3 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 21c03c5c28..eb86853924 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -185,7 +185,7 @@ int efi_net_register(void);
 /* Called by bootefi to make the watchdog available */
 int efi_watchdog_register(void);
 /* Called by bootefi to make SMBIOS tables available */
-void efi_smbios_register(void);
+efi_status_t efi_smbios_register(void);
 
 struct efi_simple_file_system_protocol *
 efi_fs_from_path(struct efi_device_path *fp);
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 67f71892ca..62e9697902 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -13,16 +13,22 @@
 
 static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
 
+/*
+ * Install the SMBIOS table as a configuration table.
+ *
+ * @return status code
+ */
 efi_status_t efi_smbios_register(void)
 {
/* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
-   uint64_t dmi = 0x;
-   /* Reserve 4kb for SMBIOS */
-   uint64_t pages = 1;
-   int memtype = EFI_RUNTIME_SERVICES_DATA;
+   u64 dmi = U32_MAX;
+   efi_status_t ret;
 
-   if (efi_allocate_pages(1, memtype, pages, ) != EFI_SUCCESS)
-   return EFI_OUT_OF_RESOURCES;
+   /* Reserve 4kiB page for SMBIOS */
+   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
+EFI_RUNTIME_SERVICES_DATA, 1, );
+   if (ret != EFI_SUCCESS)
+   return ret;
 
/* Generate SMBIOS tables */
write_smbios_table(dmi);
diff --git a/lib/smbios.c b/lib/smbios.c
index 8f19ad89c1..5389ca66e7 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -301,5 +301,7 @@ ulong write_smbios_table(ulong addr)
se->intermediate_checksum = table_compute_checksum(istart, isize);
se->checksum = table_compute_checksum(se, sizeof(struct smbios_entry));
 
+   printf("smbios table size: %d\n", isize);
+
return addr;
 }
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments

2018-01-30 Thread York Sun
On 01/30/2018 12:19 AM, Simon Goldschmidt wrote:
> On 23.01.2018 21:16, Maxime Ripard wrote:
>> Now that we have everything in place to support multiple environment, let's
>> make sure the current code can use it.
>>
>> The priority used between the various environment is the same one that was
>> used in the code previously.
>>
>> At read / init times, the highest priority environment is going to be
>> detected,
> 
> Does priority handling really work here? Most env drivers seem to ignore 
> the return value of env_import and may thus return success although 
> importing the environment failed (only reading the data from the device 
> succeeded).
> 
> This is from reading the code, I haven't had a chance to test this, yet.

It is broken on my LS1043ARDB with simply NOR flash. I am trying to
determine what went wrong.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] standalone example on mips/ath79/QCA9558/Tp-Link Archer-c7

2018-01-30 Thread Daniel Schwierzeck
Hi Arvid,

On 27.01.2018 12:36, Arvid Picciani wrote:
> HI,
> 
> i'm trying the standalone hello_world.bin example on a
> mips/ath79/QCA9558/Tp-Link Archer-c7
> 
> it just hangs for me:
> 
> ap135> tftpboot 0x8020
> dup 1 speed 1000
> *** Warning: no boot file name; using '6F01A8C0.img'
> Using eth1 device
> TFTP from server 192.168.1.100; our IP address is 192.168.1.111
> Filename '6F01A8C0.img'.
> Load address: 0x8020
> Loading: #
> done
> 
> done
> Bytes transferred = 1536 (600 hex)
> ap135> go 0x8020
> ## Starting application at 0x8020 ...
> 
> 
> nothing happens beyond this point
> 
> am i supposed to do anything different here?

I'm afraid that standalone support on MIPS is broken since we moved from 
manual symbol relocation to dynamic relocation. I've pushed a fix to 
git://git.denx.de/u-boot-mips.git branch 'fix_standalone_v1'. 

Could you retest with that branch? I'll send a patch series later.


At least it worked again on Malta board in Qemu:

$ qemu-system-mips -M malta -cpu 24Kc -m 256 -nographic -netdev 
user,id=ubtest,tftp=examples/standalone -device pcnet,netdev=ubtest -bios 
u-boot.bin 


U-Boot 2018.03-rc1-3-ga947c7ded0 (Jan 30 2018 - 20:31:48 +0100)

Board: MIPS Malta CoreLV
DRAM:  256 MiB
Flash: 4 MiB
*** Warning - bad CRC, using default environment

In:serial@3f8
Out:   serial@3f8
Err:   serial@3f8
Net:   pcnet#0
IDE:   Bus 0: not available  
malta # 
malta # dhcp 8020 hello_world.bin
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (1 ms)
Using pcnet#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'hello_world.bin'.
Load address: 0x8020
Loading: ###
 32.2 MiB/s
done
Bytes transferred = 33784 (83f8 hex)
malta # go 8020
## Starting application at 0x8020 ...
Example expects ABI version 9
Actual U-Boot ABI version 9
Hello World
argc = 1
argv[0] = "8020"
argv[1] = ""
Hit any key to exit ... 

## Application terminated, rc = 0x0
malta # QEMU: Terminated
 

-- 
- Daniel



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 1/2] efi_loader: split README.efi into two separate documents

2018-01-30 Thread Heinrich Schuchardt
README.efi describes two different concepts:
* U-Boot exposing the UEFI API
* U-Boot running on top of UEFI.

This patch splits the document in two.
Religious references are removed.

The separation of the concepts makes sense before detailing the internals
of U-Boot exposing the UEFI API in a future patch.

Signed-off-by: Heinrich Schuchardt 
---
v2
Do not set maintainer for README.u-boot_on_efi
---
 MAINTAINERS  |   1 +
 doc/README.efi   | 275 ++-
 doc/README.u-boot_on_efi | 259 
 3 files changed, 271 insertions(+), 264 deletions(-)
 create mode 100644 doc/README.u-boot_on_efi

diff --git a/MAINTAINERS b/MAINTAINERS
index 0aecc18a6c..6d4f335d4a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -289,6 +289,7 @@ EFI PAYLOAD
 M: Alexander Graf 
 S: Maintained
 T: git git://github.com/agraf/u-boot.git
+F: doc/README.efi
 F: doc/README.iscsi
 F: include/efi*
 F: lib/efi*/
diff --git a/doc/README.efi b/doc/README.efi
index 66259f3e26..956f5bfa0c 100644
--- a/doc/README.efi
+++ b/doc/README.efi
@@ -4,279 +4,24 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-=== Table of Contents ===
-
-  1  U-Boot on EFI
-  1.1  In God's Name, Why?
-  1.2  Status
-  1.3  Build Instructions
-  1.4  Trying it out
-  1.5  Inner workings
-  1.6  EFI Application
-  1.7  EFI Payload
-  1.8  Tables
-  1.9  Interrupts
-  1.10 32/64-bit
-  1.11 Future work
-  1.12 Where is the code?
-
-  2  EFI on U-Boot
-  2.1  In God's Name, Why?
-  2.2  How do I get it?
-  2.3  Status
-  2.4  Future work
-
-U-Boot on EFI
+EFI on U-Boot
 =
-This document provides information about U-Boot running on top of EFI, either
-as an application or just as a means of getting U-Boot onto a new platform.
-
-
-In God's Name, Why?

-This is useful in several situations:
-
-- You have EFI running on a board but U-Boot does not natively support it
-fully yet. You can boot into U-Boot from EFI and use that until U-Boot is
-fully ported
-
-- You need to use an EFI implementation (e.g. UEFI) because your vendor
-requires it in order to provide support
+This document provides information about the implementation of the UEFI API [1]
+in U-Boot.
 
-- You plan to use coreboot to boot into U-Boot but coreboot support does
-not currently exist for your platform. In the meantime you can use U-Boot
-on EFI and then move to U-Boot on coreboot when ready
-
-- You use EFI but want to experiment with a simpler alternative like U-Boot
 
+=== Table of Contents ===
 
+Motivation
+How do I get it?
 Status
---
-Only x86 is supported at present. If you are using EFI on another architecture
-you may want to reconsider. However, much of the code is generic so could be
-ported.
-
-U-Boot supports running as an EFI application for 32-bit EFI only. This is
-not very useful since only a serial port is provided. You can look around at
-memory and type 'help' but that is about it.
-
-More usefully, U-Boot supports building itself as a payload for either 32-bit
-or 64-bit EFI. U-Boot is packaged up and loaded in its entirety by EFI. Once
-started, U-Boot changes to 32-bit mode (currently) and takes over the
-machine. You can use devices, boot a kernel, etc.
-
-
-Build Instructions
---
-First choose a board that has EFI support and obtain an EFI implementation
-for that board. It will be either 32-bit or 64-bit. Alternatively, you can
-opt for using QEMU [1] and the OVMF [2], as detailed below.
-
-To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI
-and CONFIG_EFI_APP. The efi-x86 config (efi-x86_defconfig) is set up for this.
-Just build U-Boot as normal, e.g.
-
-   make efi-x86_defconfig
-   make
-
-To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), adjust an
-existing config (like qemu-x86_defconfig) to enable CONFIG_EFI, CONFIG_EFI_STUB
-and either CONFIG_EFI_STUB_32BIT or CONFIG_EFI_STUB_64BIT. All of these are
-boolean Kconfig options. Then build U-Boot as normal, e.g.
-
-   make qemu-x86_defconfig
-   make
-
-You will end up with one of these files depending on what you build for:
-
-   u-boot-app.efi  - U-Boot EFI application
-   u-boot-payload.efi  - U-Boot EFI payload application
-
-
-Trying it out
--
-QEMU is an emulator and it can emulate an x86 machine. Please make sure your
-QEMU version is 2.3.0 or above to test this. You can run the payload with
-something like this:
-
-   mkdir /tmp/efi
-   cp /path/to/u-boot*.efi /tmp/efi
-   qemu-system-x86_64 -bios bios.bin -hda fat:/tmp/efi/
-
-Add -nographic if you want to use the terminal for output. Once it starts
-type 'fs0:u-boot-payload.efi' to run the payload or 'fs0:u-boot-app.efi' to
-run the application. 'bios.bin' is the EFI 'BIOS'. Check [2] to obtain a
-prebuilt EFI BIOS for QEMU or you can build one from source 

[U-Boot] [PATCH v2 0/2] efi_loader: update README.efi

2018-01-30 Thread Heinrich Schuchardt
Split README.efi into two separate documents. One for U-Boot on EFI and
one for EFI on U-Boot.

Provide information about

- usage of the bootefi command
- overview of UEFI
- interaction between U-Boot and EFI drivers

in README.efi
---
v2
Provide new README.efi
---
Heinrich Schuchardt (2):
  efi_loader: split README.efi into two separate documents
  efi_loader: rewrite README.efi

 MAINTAINERS  |   1 +
 doc/README.efi   | 535 +--
 doc/README.u-boot_on_efi | 259 +++
 3 files changed, 504 insertions(+), 291 deletions(-)
 create mode 100644 doc/README.u-boot_on_efi

-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 2/2] efi_loader: rewrite README.efi

2018-01-30 Thread Heinrich Schuchardt
Provide information about

- usage of the bootefi command
- overview of UEFI
- interaction between U-Boot and EFI drivers

Signed-off-by: Heinrich Schuchardt 
---
v2
new file
---
 doc/README.efi | 322 ++---
 1 file changed, 264 insertions(+), 58 deletions(-)

diff --git a/doc/README.efi b/doc/README.efi
index 956f5bfa0c..ea1facc431 100644
--- a/doc/README.efi
+++ b/doc/README.efi
@@ -1,86 +1,292 @@
-#
-# Copyright (C) 2015 Google, Inc
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
+
 
+# EFI on U-Boot
 
-=== Table of Contents ===
+## Motivation
 
-Motivation
-How do I get it?
-Status
-Future work
+The Unified Extensible Firmware Interface Specification (UEFI) has become the
+default for booting on AArch64 and x86 systems. It provides a stable API for 
the
+interaction between the firmware and the drivers and applications loaded by the
+firmware. The API provides access to block storage, network, and console to 
name
+a few. The Linux kernel and boot loaders like Grub or the FreeBSD loader can be
+executed.
 
+## Building for EFI
 
-Motivation
---
+The UEFI standard supports only little endian systems. The EFI support can be
+activated for ARM and x86 by specifying
 
-With this API support in place, you can run any UEFI payload (such as the Linux
-kernel, grub2 or gummiboot) on U-Boot. This dramatically simplifies boot loader
-configuration, as U-Boot based systems now look and feel (almost) the same way
-as TianoCore based systems.
+CONFIG_CMD_BOOTEFI=y
+CONFIG_EFI_LOADER=y
 
-How do I get it?
-
+in the .config file.
 
-EFI support for 32bit ARM and AArch64 is already included in U-Boot. All you
-need to do is enable
+Support for attaching virtual block devices, e.g. iSCSI drives connected by the
+loaded EFI application, requires
 
-  CONFIG_CMD_BOOTEFI=y
-  CONFIG_EFI_LOADER=y
+CONFIG_BLK=y
+CONFIG_PARTITIONS=y
 
-in your .config file and you will automatically get a bootefi command to run
-an efi application as well as snippet in the default distro boot script that
-scans for removable media efi binaries as fallback.
+A hello world EFI application can be built with
 
-Status
---
+CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
 
-I am successfully able to run grub2 and Linux EFI binaries with this code on
-ARMv7 as well as AArch64 systems.
+It can be embedded into the U-Boot binary for starting with command
+'bootefi hello' with
 
-When enabled, the resulting U-Boot binary only grows by ~10KB, so it's very
-light weight.
+CONFIG_CMD_BOOTEFI_HELLO=y
 
-All storage devices are directly accessible from the uEFI payload
+A test suite that can be executed with command 'bootefi selftest' is provided
+by
 
-Removable media booting (search for /efi/boot/boota{a64,arm}.efi) is supported.
+CONFIG_SELFTEST=y
 
-Simple use cases like "Plug this SD card into my ARM device and it just
-boots into grub which boots into Linux", work very well.
+## The bootefi command
 
+### Executing an EFI binary
 
-Running HelloWord.efi
--
+The bootefi command is used to start EFI applications or to install EFI 
drivers.
+It takes two parameters
 
-You can run a simple 'hello world' EFI program in U-Boot.
-Enable the option CONFIG_CMD_BOOTEFI_HELLO.
+bootefi  [fdt address]
 
-Then you can boot into U-Boot and type:
+* image address - the memory address of the EFI binary
+* fdt address - the memory address of the flattened device tree
 
-   > bootefi hello
+Below you find the output of an example session starting Grub.
 
-The 'hello world EFI' program will then run, print a message and exit.
+=> load mmc 0:2 ${fdt_addr_r} boot/dtb
+29830 bytes read in 14 ms (2 MiB/s)
+=> load mmc 0:1 ${kernel_addr_r} efi/debian/grubaa64.efi
+reading efi/debian/grubaa64.efi
+120832 bytes read in 7 ms (16.5 MiB/s)
+=> bootefi ${kernel_addr_r} ${fdt_addr_r}
 
+The environment variable 'bootargs' is passed as load options in the EFI system
+table. The Linux kernel EFI stub uses the load options as command line
+arguments.
 
-Future work

+### Executing the boot manager
 
-Of course, there are still a few things one could do on top:
+The UEFI specfication forsees to define boot entries and boot sequence via EFI
+variables. Booting according to these variables is possible via
 
-   - Improve disk media detection (don't scan, use what information we
-have)
-   - Add EFI variable support using NVRAM
-   - Add GFX support
-   - Make EFI Shell work
-   - Network device support
-   - Support for payload exit
-   - Payload Watchdog support
+bootefi bootmgr [fdt address]
 
-[1] http://uefi.org/
+As of U-Boot v2018.03 EFI variables cannot be set by the operating system. So
+this development is not usable yet.
+
+### Executing the built in hello world application
+
+For testing the bootefi command can be used to start a hello world application.
+
+bootefi hello 

[U-Boot] [PATCH 1/1] efi_loader: fix the online help for bootefi bootmgr

2018-01-30 Thread Heinrich Schuchardt
The bootefi command is missing in the online help for
bootefi bootmgr.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 4233d36b72..2106ed9c8c 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -411,7 +411,7 @@ static char bootefi_help_text[] =
"Use environment variable efi_selftest to select a single test.\n"
"Use 'setenv efi_selftest list' to enumerate all tests.\n"
 #endif
-   "bootmgr [fdt addr]\n"
+   "bootefi bootmgr [fdt addr]\n"
"  - load and boot EFI payload based on BootOrder/Boot variables.\n"
"\n"
"If specified, the device tree located at  gets\n"
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] fdt: Fixup only valid memory banks

2018-01-30 Thread Stephen Warren

On 01/30/2018 03:34 AM, Thierry Reding wrote:

From: Thierry Reding 

Memory banks with address 0 and size 0 are empty and should not be
passed to the OS via device tree.



if (!banks)
return 0;
  
+	for (i = 0; i < banks; i++)

+   if (start[i] == 0 && size[i] == 0)
+   break;
+
+   banks = i;


Do we want to move the for loop above the check for if (!banks)?

Should we put braces around the multi-line body of the for loop?

Aside from that,
Acked-by: Stephen Warren 


+
len = fdt_pack_reg(blob, tmp, start, size, banks);
  
  	err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Please pull u-boot-x86

2018-01-30 Thread Tom Rini
On Tue, Jan 30, 2018 at 10:42:32PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following changes since commit eef11acebaa48e241e9187c717dc92d3e175c119:
> 
>   Prepare v2018.03-rc1 (2018-01-29 20:12:33 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to e21b04fec465c84a51ca6fc6450263e0c0953fcb:
> 
>   x86: kconfig: Remove meaningless 'select n' (2018-01-30 22:34:38 +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] MIPS relocation DT error

2018-01-30 Thread Daniel Schwierzeck
Hi Álvaro,

On 26.01.2018 22:58, Álvaro Fernández Rojas wrote:
> I just found out I was missing OF_EMBED, which confirms that it was
> working because CFE was relocating u-boot and not u-boot itself...
> 
> Sorry for the noise...
> 
> El 26/01/2018 a las 22:53, Álvaro Fernández Rojas escribió:
>> Hello Paul & Daniel,
>>
>>
>> I've finally had some time to do more testing and it appears that the
>> relocation error I saw on BMIPS is due to a DT not found error caused
>> by mips relocation:
>>
>> https://gist.github.com/Noltari/9017b3d28e2109d1de4158e5ad5b1c65
>>
>> Any ideas on how to fix it?
>>
>>
>> BTW, the reason why I think it works if I disable relocation is
>> because CFE relocates .elf before executing them.
>>

I don't think CFE relocates U-Boot because the main purpose is to boot
kernels where only recent ones can be relocated. CFE's tasks should only
be to copy the ELF payload to the link address specified in ELF header,
to invalidate I-Caches and to jump to that address.

I'd rather think the appended DTB is either not correctly linked in
the ELF binary or not copied by CFE. The address of the appended DT blob
is determined with the linker symbol "_end". If CFE would relocate, this
symbol would also point to the relocated memory address.

-- 
- Daniel



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] MIPS: add BMIPS Netgear DGND3700v2 board

2018-01-30 Thread Daniel Schwierzeck


On 26.01.2018 21:30, Álvaro Fernández Rojas wrote:
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  arch/mips/dts/Makefile   |   1 +
>  arch/mips/dts/netgear,dgnd3700v2.dts | 121 
> +++
>  arch/mips/mach-bmips/Kconfig |  12 +++
>  board/netgear/dgnd3700v2/Kconfig |  12 +++
>  board/netgear/dgnd3700v2/MAINTAINERS |   6 ++
>  board/netgear/dgnd3700v2/Makefile|   5 ++
>  board/netgear/dgnd3700v2/dgnd3700v2.c|  30 
>  configs/netgear_dgnd3700v2_ram_defconfig |  46 
>  include/configs/netgear_dgnd3700v2.h |  16 
>  9 files changed, 249 insertions(+)
>  create mode 100644 arch/mips/dts/netgear,dgnd3700v2.dts
>  create mode 100644 board/netgear/dgnd3700v2/Kconfig
>  create mode 100644 board/netgear/dgnd3700v2/MAINTAINERS
>  create mode 100644 board/netgear/dgnd3700v2/Makefile
>  create mode 100644 board/netgear/dgnd3700v2/dgnd3700v2.c
>  create mode 100644 configs/netgear_dgnd3700v2_ram_defconfig
>  create mode 100644 include/configs/netgear_dgnd3700v2.h
> 
> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
> index 840dbf170d..e80905cf3a 100644
> --- a/arch/mips/dts/Makefile
> +++ b/arch/mips/dts/Makefile
> @@ -15,6 +15,7 @@ dtb-$(CONFIG_BOARD_COMTREND_VR3032U) += 
> comtrend,vr-3032u.dtb
>  dtb-$(CONFIG_BOARD_COMTREND_WAP5813N) += comtrend,wap-5813n.dtb
>  dtb-$(CONFIG_BOARD_HUAWEI_HG556A) += huawei,hg556a.dtb
>  dtb-$(CONFIG_BOARD_NETGEAR_CG3100D) += netgear,cg3100d.dtb
> +dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += netgear,dgnd3700v2.dtb
>  dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
>  dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
>  
> diff --git a/arch/mips/dts/netgear,dgnd3700v2.dts 
> b/arch/mips/dts/netgear,dgnd3700v2.dts
> new file mode 100644
> index 00..2739f2035a
> --- /dev/null
> +++ b/arch/mips/dts/netgear,dgnd3700v2.dts
> @@ -0,0 +1,121 @@
> +/*
> + * Copyright (C) 2018 Álvaro Fernández Rojas 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +/dts-v1/;
> +
> +#include "brcm,bcm6362.dtsi"
> +
> +/ {
> + model = "Netgear DGND3700v2";
> + compatible = "netgear,dgnd3700v2", "brcm,bcm6362";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + inet_green {
> + label = "DGND3700v2:green:inet";
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + };
> +
> + dsl_green {
> + label = "DGND3700v2:green:dsl";
> + gpios = < 28 GPIO_ACTIVE_LOW>;
> + };
> +
> + power_amber {
> + label = "DGND3700v2:red:power";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + brcm,serial-leds;
> + brcm,serial-dat-low;
> + brcm,serial-shift-inv;
> + brcm,serial-mux;
> +
> + led@8 {
> + reg = <8>;
> + label = "DGND3700v2:green:power";
> + };
> +
> + led@9 {
> + reg = <9>;
> + active-low;
> + label = "DGND3700v2:green:wps";
> + };
> +
> + led@10 {
> + reg = <10>;
> + active-low;
> + label = "DGND3700v2:green:usb1";
> + };
> +
> + led@11 {
> + reg = <11>;
> + active-low;
> + label = "DGND3700v2:green:usb2";
> + };
> +
> + led@12 {
> + reg = <12>;
> + active-low;
> + label = "DGND3700v2:amber:inet";
> + };
> +
> + led@13 {
> + reg = <13>;
> + active-low;
> + label = "DGND3700v2:green:ethernet";
> + };
> +
> + led@14 {
> + reg = <14>;
> + active-low;
> + label = "DGND3700v2:amber:dsl";
> + };
> +
> + led@16 {
> + reg = <16>;
> + active-low;
> + label = "DGND3700v2:amber:usb1";
> + };
> +
> + led@17 {
> + reg = <17>;
> + active-low;
> + label = "DGND3700v2:amber:usb2";
> + };
> +
> + led@18 {
> + reg = <18>;
> + active-low;
> + label = "DGND3700v2:amber:ethernet";
> + };
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> diff --git a/arch/mips/mach-bmips/Kconfig b/arch/mips/mach-bmips/Kconfig
> index 2cc6a6a8d9..10900bf604 100644
> --- a/arch/mips/mach-bmips/Kconfig
> +++ b/arch/mips/mach-bmips/Kconfig
> @@ -200,6 +200,17 @@ config BOARD_NETGEAR_CG3100D
> ethernet ports, 1 UART, GPIO buttons and LEDs, and a BCM43225
> (miniPCIe).
>  
> +config BOARD_NETGEAR_DGND3700V2
> + bool 

Re: [U-Boot] [PATCH] Build system: Don't check for CONFIG_SYS_TEXT_BASE being set

2018-01-30 Thread Alexey Brodkin
Hi MAsahiro-san, Tom,

On Wed, 2018-01-31 at 01:23 +0900, Masahiro Yamada wrote:
> 2018-01-31 0:23 GMT+09:00 Alexey Brodkin :
> > 
> Please feel free to include historical reason:
> 
> This ifneq conditional was added for Blackfin because it did not use
> CONFIG_SYS_TEXT_BASE.
> See.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_u-2Dboot_u-2Dboot_blob_v2017.03_arch_blackfin_config.mk-23L67=DwIBaQ=DPL6_X_6JkX
> Fx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=mezwGj3E5EIPuE8Oln2gVeTJ-8q19KNepz7Jo-
> Kcu1o=dmnDXQ05QLyAFKUgnsVyJOS8aybk3rhbDNsgiio6zvA=
> 
> Then Blackfin is gone, so should be OK.

Should I send a respin with this valuable addition or whoever's going to apply 
will
fix-up this?

-Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] Build system: Don't check for CONFIG_SYS_TEXT_BASE being set

2018-01-30 Thread Masahiro Yamada
2018-01-31 0:23 GMT+09:00 Alexey Brodkin :
> CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
> places in the same Makefile without any checks so there's no point in
> keeping this check araound just in one place.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Tom Rini 
> ---
>  Makefile | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ab3453dcebdc..6f15612b4d07 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -820,9 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
>  # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
>  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
>
> -ifneq ($(CONFIG_SYS_TEXT_BASE),)
>  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
> -endif





Please feel free to include historical reason:

This ifneq conditional was added for Blackfin because it did not use
CONFIG_SYS_TEXT_BASE.
See.
https://github.com/u-boot/u-boot/blob/v2017.03/arch/blackfin/config.mk#L67

Then Blackfin is gone, so should be OK.

Acked-by: Masahiro Yamada 




>  # Normally we fill empty space with 0xff
>  quiet_cmd_objcopy = OBJCOPY $@
> --
> 2.14.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] AM3703 does not boot from MicroSD card

2018-01-30 Thread Peter Robinson
On Tue, Jan 30, 2018 at 1:54 AM, phantom0  wrote:
> Hi
> I'm trying to upgrade u-boot from 2016.03 to 2017.09. When I boot it up,

I vaguely remember something similar to this with some similar device,
any reason you can't just got to 2018.01?

> u-boot gives me this error.
> What could be the problem? Thanks.
>
> U-Boot SPL 2017.09-dirty (Jan 29 2018 - 10:56:46)
> Trying to boot from MMC1
> MMC Device 0 not found
> spl: could not find mmc device. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
>
>
>
> --
> Sent from: http://u-boot.10912.n7.nabble.com/
> ___
> 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


[U-Boot] [PATCH] Build system: Don't check for CONFIG_SYS_TEXT_BASE being set

2018-01-30 Thread Alexey Brodkin
CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
places in the same Makefile without any checks so there's no point in
keeping this check araound just in one place.

Signed-off-by: Alexey Brodkin 
Cc: Tom Rini 
---
 Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Makefile b/Makefile
index ab3453dcebdc..6f15612b4d07 100644
--- a/Makefile
+++ b/Makefile
@@ -820,9 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
 # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
 LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
 
-ifneq ($(CONFIG_SYS_TEXT_BASE),)
 LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
-endif
 
 # Normally we fill empty space with 0xff
 quiet_cmd_objcopy = OBJCOPY $@
-- 
2.14.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] env: sf: fix return value of env_sf_load

2018-01-30 Thread Tom Rini
On Tue, Jan 30, 2018 at 09:15:09AM +0100, Simon Goldschmidt wrote:
> On 30.01.2018 08:55, Simon Goldschmidt wrote:
> >With the recent changes to support multiple environments, I see a
> >message "Failed (1)" when loading environment from sf.
> >
> >env_sf_load() returns the return value of env_import(). This must be
> >'inverted' to return the correct meaning.
> 
> Thinking about this again, it might be cleaner to make env_import and
> env_import_redundant return 0 on success. Would that be acceptable?

If it makes things look cleaner, yes, 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] armv8: ls1088aqds: Add IFC-NOR as boot source for LS1088

2018-01-30 Thread York Sun
Ashish,

Please use proper quotation ">" when you reply.

On 01/30/2018 06:24 AM, Ashish Kumar wrote:
> 
> 
> -Original Message-
> From: York Sun 
> Sent: Tuesday, January 30, 2018 2:54 AM
> To: Ashish Kumar ; u-boot@lists.denx.de
> Subject: Re: [PATCH] armv8: ls1088aqds: Add IFC-NOR as boot source for LS1088
> 
> On 01/01/2018 09:24 PM, Ashish Kumar wrote:
>> IFC-NOR and QSPI-NOR pins are muxed on SoC,so they cannot be accessed 
>> simultaneously, but IFC-NOR can be accessed along with SD-BOOT.
>>
>> ls1088aqds_sdcard_ifc_defconfig: is defconfig for SD as boot source 
>> and IFC-NOR to be used as flash, this will be used to write IFC-NOR 
>> image on IFC flash.
>> QSPI and DSPI cannot be accessed in this defconfig.
>>
>> IFC-NOR image is generated by ls1088aqds_defconfig.
>>
>> Signed-off-by: Ashish Kumar 
>> ---
>> depends on: 
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
>> chwork.ozlabs.org%2Fpatch%2F853615%2F=02%7C01%7Cyork.sun%40nxp.co
>> m%7Cc53b3ec4db4d48e5130a08d551a1253d%7C686ea1d3bc2b4c6fa92cd99c5c30163
>> 5%7C0%7C0%7C636504674905515652=j2VD3l2%2BIb7iYk8yvn3TOrvT38pPT8A
>> RRQjN0h%2FR5b0%3D=0
>>
>> Tested on 2018.01-rc3
>>
>> More accurate timing are used which where provided by validation team
>>
>> to switch to IFC-NOR use command for qspi prompt:
>> i2c mw 66 0x60 0x12; i2c mw 66 50 00;i2c mw 66 10 21
> 
> 
> 
>> diff --git a/include/configs/ls1088aqds.h 
>> b/include/configs/ls1088aqds.h index 8fbf890..d5075c3 100644
>> --- a/include/configs/ls1088aqds.h
>> +++ b/include/configs/ls1088aqds.h
>> @@ -27,7 +27,6 @@ unsigned long get_board_ddr_clk(void);
>>  #define CONFIG_SYS_MMC_ENV_DEV  0
>>  #define CONFIG_ENV_SIZE 0x2000
>>  #else
>> -#define CONFIG_ENV_IS_IN_FLASH
>>  #define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE + 
>> 0x30)
>>  #define CONFIG_ENV_SECT_SIZE0x2
>>  #define CONFIG_ENV_SIZE 0x2
>> @@ -41,8 +40,9 @@ unsigned long get_board_ddr_clk(void);
>>  #define CONFIG_SYS_CLK_FREQ 1
>>  #define CONFIG_DDR_CLK_FREQ 1
>>  #else
>> -#define CONFIG_SYS_CLK_FREQ get_board_sys_clk()
>> -#define CONFIG_DDR_CLK_FREQ get_board_ddr_clk()
>> +#define CONFIG_QIXIS_I2C_ACCESS
>> +#define CONFIG_SYS_CLK_FREQ 1
>> +#define CONFIG_DDR_CLK_FREQ 1
> 
> Are you sure you want to go down the path to hard-code clock speeds? You will 
> lose the ability to change clocks. Besides, you have identical hard-coded 
> value for both legs of the #if...#else..#endif.
> 
> I found that I was not able to access QIXIS_READ etc, so I had to revert to 
> fixed values.

You need to find the root cause. Qixis is on both IFC and I2C. Does NOR
flash takes the chip-select FPGA was using?

> 
> 
>>  #endif
>>  
>>  #define COUNTER_FREQUENCY_REAL  (CONFIG_SYS_CLK_FREQ/4)
>> @@ -87,16 +87,10 @@ unsigned long get_board_ddr_clk(void);
>>  CSPR_MSEL_NOR   | \
>>  CSPR_V)
>>  #define CONFIG_SYS_NOR_CSOR CSOR_NOR_ADM_SHIFT(12)
>> -#define CONFIG_SYS_NOR_FTIM0(FTIM0_NOR_TACSE(0x4) | \
>> -FTIM0_NOR_TEADC(0x5) | \
>> -FTIM0_NOR_TEAHC(0x5))
>> -#define CONFIG_SYS_NOR_FTIM1(FTIM1_NOR_TACO(0x35) | \
>> -FTIM1_NOR_TRAD_NOR(0x1a) |\
>> -FTIM1_NOR_TSEQRAD_NOR(0x13))
>> -#define CONFIG_SYS_NOR_FTIM2(FTIM2_NOR_TCS(0x4) | \
>> -FTIM2_NOR_TCH(0x4) | \
>> -FTIM2_NOR_TWPH(0x0E) | \
>> -FTIM2_NOR_TWP(0x1c))
>> +#define CONFIG_SYS_NOR_FTIM0(0xc0201410)
>> +#define CONFIG_SYS_NOR_FTIM1(0x50009028)
>> +#define CONFIG_SYS_NOR_FTIM2(0x0820501c)
>> +#define CONFIG_SYS_NOR_FTIM30x0400
> 
> This is bad coding! Please use macros. Please triple-check your timing.
> I don't want to fix the timing again. See my commit for LS1046AQDS 1b7910a37c.
> 
> How do I find timing which are correct?, I borrowed the same from validation 
> scripts used by validation team.
> Should I use these "LS1046AQDS 1b7910a37c"

If you know what you are doing, calculate the timing. If you don't, use
my timing as suggested. Do not use magic numbers.

> 
>>  #define CONFIG_SYS_NOR_FTIM30x0400
>>  #define CONFIG_SYS_IFC_CCR  0x0100
>>  
>> @@ -193,7 +187,7 @@ unsigned long get_board_ddr_clk(void);
>>  | CSPR_MSEL_GPCM \
>>  | CSPR_V)
>>  
>> -#define CONFIG_SYS_FPGA_AMASK   IFC_AMASK(64*1024)
>> +#define SYS_FPGA_AMASK  IFC_AMASK(64 * 1024)
>>  #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
>>  #define CONFIG_SYS_FPGA_CSORCSOR_GPCM_ADM_SHIFT(0)
>>  #else
>> @@ -222,7 +216,7 @@ 

[U-Boot] [PATCH v3 09/24] mmc: omap_hsmmc: use mmc_of_parse to populate mmc_config

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

Use the mmc_of_parse library function to populate mmc_config instead of
repeating the same code in host controller driver.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index ab4a095..57548ee 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1297,32 +1297,18 @@ static int omap_hsmmc_ofdata_to_platdata(struct udevice 
*dev)
struct mmc_config *cfg = >cfg;
const void *fdt = gd->fdt_blob;
int node = dev_of_offset(dev);
-   int val;
+   int ret;
 
plat->base_addr = map_physmem(devfdt_get_addr(dev),
  sizeof(struct hsmmc *),
  MAP_NOCACHE);
 
-   cfg->host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS;
-   val = fdtdec_get_int(fdt, node, "bus-width", -1);
-   if (val < 0) {
-   printf("error: bus-width property missing\n");
-   return -ENOENT;
-   }
-
-   switch (val) {
-   case 0x8:
-   cfg->host_caps |= MMC_MODE_8BIT;
-   case 0x4:
-   cfg->host_caps |= MMC_MODE_4BIT;
-   break;
-   default:
-   printf("error: invalid bus-width property\n");
-   return -ENOENT;
-   }
+   ret = mmc_of_parse(dev, cfg);
+   if (ret < 0)
+   return ret;
 
+   cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
cfg->f_min = 40;
-   cfg->f_max = fdtdec_get_int(fdt, node, "max-frequency", 5200);
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
if (fdtdec_get_bool(fdt, node, "ti,dual-volt"))
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 23/24] ARM: DRA7x/AM57x: Add MMC/SD fixups for rev1.0 and rev 1.1

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

Since DRA7xx/AM57xx SR1.1 and SR1.0 has errata to limit the frequency of
MMC1 to 96MHz and frequency of MMC2 to 48MHz for AM572x SR1.1, limit the
frequency and disable higher speed modes for those revision.
Also use the recommended IO delays (those tagged with "rev11")

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 board/ti/am57xx/board.c | 30 ++
 board/ti/dra7xx/evm.c   | 29 +
 2 files changed, 59 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 1128784..9c1e2ef 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../common/board_detect.h"
 #include "mux_data.h"
@@ -815,6 +816,35 @@ int board_mmc_init(bd_t *bis)
omap_mmc_init(1, 0, 0, -1, -1);
return 0;
 }
+
+static const struct mmc_platform_fixups am57x_es1_1_mmc1_fixups = {
+   .hw_rev = "rev11",
+   .unsupported_caps = MMC_CAP(MMC_HS_200) |
+   MMC_CAP(UHS_SDR104),
+   .max_freq = 9600,
+};
+
+static const struct mmc_platform_fixups am57x_es1_1_mmc23_fixups = {
+   .hw_rev = "rev11",
+   .unsupported_caps = MMC_CAP(MMC_HS_200) |
+   MMC_CAP(UHS_SDR104) |
+   MMC_CAP(UHS_SDR50),
+   .max_freq = 4800,
+};
+
+const struct mmc_platform_fixups *platform_fixups_mmc(uint32_t addr)
+{
+   switch (omap_revision()) {
+   case DRA752_ES1_0:
+   case DRA752_ES1_1:
+   if (addr == OMAP_HSMMC1_BASE)
+   return _es1_1_mmc1_fixups;
+   else
+   return _es1_1_mmc23_fixups;
+   default:
+   return NULL;
+   }
+}
 #endif
 
 #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_OS_BOOT)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 6ecf971..c62724e 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -866,6 +866,35 @@ void board_mmc_poweron_ldo(uint voltage)
palmas_mmc1_poweron_ldo(LDO1_VOLTAGE, LDO1_CTRL, voltage);
}
 }
+
+static const struct mmc_platform_fixups dra7x_es1_1_mmc1_fixups = {
+   .hw_rev = "rev11",
+   .unsupported_caps = MMC_CAP(MMC_HS_200) |
+   MMC_CAP(UHS_SDR104),
+   .max_freq = 9600,
+};
+
+static const struct mmc_platform_fixups dra7x_es1_1_mmc23_fixups = {
+   .hw_rev = "rev11",
+   .unsupported_caps = MMC_CAP(MMC_HS_200) |
+   MMC_CAP(UHS_SDR104) |
+   MMC_CAP(UHS_SDR50),
+   .max_freq = 4800,
+};
+
+const struct mmc_platform_fixups *platform_fixups_mmc(uint32_t addr)
+{
+   switch (omap_revision()) {
+   case DRA752_ES1_0:
+   case DRA752_ES1_1:
+   if (addr == OMAP_HSMMC1_BASE)
+   return _es1_1_mmc1_fixups;
+   else
+   return _es1_1_mmc23_fixups;
+   default:
+   return NULL;
+   }
+}
 #endif
 
 #ifdef CONFIG_USB_DWC3
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 22/24] dts: am57xx-idk: disable HS200 support

2018-01-30 Thread Jean-Jacques Hiblot
HS200 cannot be supported on mmc2, because the IO lines of mmc2 are
connected to 3.3v.

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/dts/am57xx-idk-common.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/am57xx-idk-common.dtsi 
b/arch/arm/dts/am57xx-idk-common.dtsi
index 97aa8e6..fa5a078 100644
--- a/arch/arm/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/dts/am57xx-idk-common.dtsi
@@ -413,6 +413,8 @@
bus-width = <8>;
ti,non-removable;
max-frequency = <9600>;
+   no-1-8-v;
+   /delete-property/ mmc-hs200-1_8v;
 };
 
  {
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 15/24] mmc: omap_hsmmc: implement send_init_stream callback

2018-01-30 Thread Jean-Jacques Hiblot
This callback is used to send the 74 clock cycles after power up.

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index b10d55e..71608d1 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -46,6 +46,7 @@
 #include 
 #endif
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -564,6 +565,14 @@ tuning_error:
return ret;
 }
 #endif
+
+static void omap_hsmmc_send_init_stream(struct udevice *dev)
+{
+   struct omap_hsmmc_data *priv = dev_get_priv(dev);
+   struct hsmmc *mmc_base = priv->base_addr;
+
+   mmc_init_stream(mmc_base);
+}
 #endif
 
 static void mmc_enable_irq(struct mmc *mmc, struct mmc_cmd *cmd)
@@ -652,7 +661,10 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
writel(readl(_base->hctl) | SDBP_PWRON, _base->hctl);
 
mmc_enable_irq(mmc, NULL);
+
+#if !CONFIG_IS_ENABLED(DM_MMC)
mmc_init_stream(mmc_base);
+#endif
 
return 0;
 }
@@ -1279,6 +1291,7 @@ static const struct dm_mmc_ops omap_hsmmc_ops = {
 #ifdef MMC_SUPPORTS_TUNING
.execute_tuning = omap_hsmmc_execute_tuning,
 #endif
+   .send_init_stream   = omap_hsmmc_send_init_stream,
 };
 #else
 static const struct mmc_ops omap_hsmmc_ops = {
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 20/24] ARM: dts: dra7: Add supported MMC/SD modes in MMC dt nodes

2018-01-30 Thread Jean-Jacques Hiblot
On DRA7 family SoCs, MMC1 controller supports SDR104,
SDR50, DDR50, SDR25 and SDR12 UHS modes.

MMC2 controller supports HS200 and DDR modes.

MMC3 controller supports SDR12, SDR25 and SDR50 modes.

MMC4 controller supports SDR12 and SDR25 modes.

Add these supported modes in device-tree file.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/dts/dra7.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/dts/dra7.dtsi b/arch/arm/dts/dra7.dtsi
index 9061843..0f982d8 100644
--- a/arch/arm/dts/dra7.dtsi
+++ b/arch/arm/dts/dra7.dtsi
@@ -1067,6 +1067,11 @@
status = "disabled";
pbias-supply = <_mmc_reg>;
max-frequency = <19200>;
+   sd-uhs-sdr104;
+   sd-uhs-sdr50;
+   sd-uhs-ddr50;
+   sd-uhs-sdr25;
+   sd-uhs-sdr12;
};
 
mmc2: mmc@480b4000 {
@@ -1079,6 +1084,10 @@
dma-names = "tx", "rx";
status = "disabled";
max-frequency = <19200>;
+   sd-uhs-sdr25;
+   sd-uhs-sdr12;
+   mmc-hs200-1_8v;
+   mmc-ddr-1_8v;
};
 
mmc3: mmc@480ad000 {
@@ -1092,6 +1101,9 @@
status = "disabled";
/* Errata i887 limits max-frequency of MMC3 to 64 MHz */
max-frequency = <6400>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr50;
};
 
mmc4: mmc@480d1000 {
@@ -1104,6 +1116,8 @@
dma-names = "tx", "rx";
status = "disabled";
max-frequency = <19200>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
};
 
mmu0_dsp1: mmu@40d01000 {
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 19/24] ARM: dts: DRA7: use new dra7-specific compatible string

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

Use the new compatible string "ti,dra7-hsmmc" that was specifically
added for dra7 and dra72. This is required since for dra7 and dra72
processors iodelay values has to be set unlike other processors.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/dts/dra7.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/dra7.dtsi b/arch/arm/dts/dra7.dtsi
index 02a136a..9061843 100644
--- a/arch/arm/dts/dra7.dtsi
+++ b/arch/arm/dts/dra7.dtsi
@@ -1056,7 +1056,7 @@
};
 
mmc1: mmc@4809c000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
interrupts = ;
ti,hwmods = "mmc1";
@@ -1070,7 +1070,7 @@
};
 
mmc2: mmc@480b4000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x480b4000 0x400>;
interrupts = ;
ti,hwmods = "mmc2";
@@ -1082,7 +1082,7 @@
};
 
mmc3: mmc@480ad000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x480ad000 0x400>;
interrupts = ;
ti,hwmods = "mmc3";
@@ -1095,7 +1095,7 @@
};
 
mmc4: mmc@480d1000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x480d1000 0x400>;
interrupts = ;
ti,hwmods = "mmc4";
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 10/24] ARM: OMAP5/DRA7: Enable iodelay recalibration to be done from uboot

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

Add a new API to perform iodelay recalibration without isolate
io to be used in uboot.

The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met. The MMC driver can use the new API to
set the IO delay values depending on the MMC mode.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |  3 +++
 arch/arm/mach-omap2/omap5/dra7xx_iodelay.c   | 30 
 include/configs/am57xx_evm.h |  2 --
 include/configs/dra7xx_evm.h |  2 --
 4 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h 
b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
index c997004..a8780ee 100644
--- a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
+++ b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
@@ -83,6 +83,9 @@
 void __recalibrate_iodelay(struct pad_conf_entry const *pad, int npads,
   struct iodelay_cfg_entry const *iodelay,
   int niodelays);
+void late_recalibrate_iodelay(struct pad_conf_entry const *pad, int npads,
+ struct iodelay_cfg_entry const *iodelay,
+ int niodelays);
 int __recalibrate_iodelay_start(void);
 void __recalibrate_iodelay_end(int ret);
 
diff --git a/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c 
b/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c
index 8798730..a9a9f75 100644
--- a/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c
+++ b/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c
@@ -272,3 +272,33 @@ err:
__recalibrate_iodelay_end(ret);
 
 }
+
+void late_recalibrate_iodelay(struct pad_conf_entry const *pad, int npads,
+ struct iodelay_cfg_entry const *iodelay,
+ int niodelays)
+{
+   int ret = 0;
+
+   /* unlock IODELAY CONFIG registers */
+   writel(CFG_IODELAY_UNLOCK_KEY, (*ctrl)->iodelay_config_base +
+  CFG_REG_8_OFFSET);
+
+   ret = calibrate_iodelay((*ctrl)->iodelay_config_base);
+   if (ret)
+   goto err;
+
+   ret = update_delay_mechanism((*ctrl)->iodelay_config_base);
+
+   /* Configure Mux settings */
+   do_set_mux32((*ctrl)->control_padconf_core_base, pad, npads);
+
+   /* Configure Manual IO timing modes */
+   ret = do_set_iodelay((*ctrl)->iodelay_config_base, iodelay, niodelays);
+   if (ret)
+   goto err;
+
+err:
+   /* lock IODELAY CONFIG registers */
+   writel(CFG_IODELAY_LOCK_KEY, (*ctrl)->iodelay_config_base +
+  CFG_REG_8_OFFSET);
+}
diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 7546b3f..65465d1 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -15,9 +15,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_SPL_BUILD
 #define CONFIG_IODELAY_RECALIBRATION
-#endif
 
 #define CONFIG_NR_DRAM_BANKS   2
 
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index ff90b6d..975e6fd 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -14,9 +14,7 @@
 
 #include 
 
-#ifdef CONFIG_SPL_BUILD
 #define CONFIG_IODELAY_RECALIBRATION
-#endif
 
 #define CONFIG_VERY_BIG_RAM
 #define CONFIG_NR_DRAM_BANKS   2
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 07/24] mmc: omap_hsmmc: Workaround for errata id i802

2018-01-30 Thread Jean-Jacques Hiblot
According to errata i802, DCRC error interrupts
(MMCHS_STAT[21] DCRC=0x1) can occur during the tuning procedure.

The DCRC interrupt, occurs when the last tuning block fails
(the last ratio tested). The delay from CRC check until the
interrupt is asserted is bigger than the delay until assertion
of the tuning end flag. Assertion of tuning end flag is what
masks the interrupts. Because of this race, an erroneous DCRC
interrupt occurs.

The suggested  workaround is to disable DCRC interrupts during
the tuning procedure which is implemented here.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v3:
- fixed build issue with omap3 platforms

 arch/arm/include/asm/omap_mmc.h |  4 
 drivers/mmc/omap_hsmmc.c| 28 ++--
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index cf9f1c5..635ce1e 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -219,6 +219,10 @@ struct omap_hsmmc_plat {
 #define mmc_reg_out(addr, mask, val)\
writel((readl(addr) & (~(mask))) | ((val) & (mask)), (addr))
 
+#define INT_EN_MASK (IE_BADA | IE_CERR | IE_DEB | IE_DCRC |\
+   IE_DTO | IE_CIE | IE_CEB | IE_CCRC | IE_ADMAE | IE_CTO |\
+   IE_BRR | IE_BWR | IE_TC | IE_CC)
+
 int omap_mmc_init(int dev_index, uint host_caps_mask, uint f_max, int cd_gpio,
int wp_gpio);
 
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 69a7c2e..5523210 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -476,6 +476,25 @@ tuning_error:
 #endif
 #endif
 
+static void mmc_enable_irq(struct mmc *mmc, struct mmc_cmd *cmd)
+{
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+   struct hsmmc *mmc_base = priv->base_addr;
+   u32 irq_mask = INT_EN_MASK;
+
+   /*
+* TODO: Errata i802 indicates only DCRC interrupts can occur during
+* tuning procedure and DCRC should be disabled. But see occurences
+* of DEB, CIE, CEB, CCRC interupts during tuning procedure. These
+* interrupts occur along with BRR, so the data is actually in the
+* buffer. It has to be debugged why these interrutps occur
+*/
+   if (cmd && mmc_is_tuning_cmd(cmd->cmdidx))
+   irq_mask &= ~(IE_DEB | IE_DCRC | IE_CIE | IE_CEB | IE_CCRC);
+
+   writel(irq_mask, _base->ie);
+}
+
 static int omap_hsmmc_init_setup(struct mmc *mmc)
 {
struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
@@ -542,10 +561,7 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
 
writel(readl(_base->hctl) | SDBP_PWRON, _base->hctl);
 
-   writel(IE_BADA | IE_CERR | IE_DEB | IE_DCRC | IE_DTO | IE_CIE |
-   IE_CEB | IE_CCRC | IE_ADMAE | IE_CTO | IE_BRR | IE_BWR | IE_TC |
-   IE_CC, _base->ie);
-
+   mmc_enable_irq(mmc, NULL);
mmc_init_stream(mmc_base);
 
return 0;
@@ -718,11 +734,9 @@ static int omap_hsmmc_send_cmd(struct udevice *dev, struct 
mmc_cmd *cmd,
struct mmc_data *data)
 {
struct omap_hsmmc_data *priv = dev_get_priv(dev);
-#ifndef CONFIG_OMAP34XX
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct mmc *mmc = upriv->mmc;
 #endif
-#endif
struct hsmmc *mmc_base;
unsigned int flags, mmc_stat;
ulong start;
@@ -810,6 +824,8 @@ static int omap_hsmmc_send_cmd(struct udevice *dev, struct 
mmc_cmd *cmd,
 #endif
}
 
+   mmc_enable_irq(mmc, cmd);
+
writel(cmd->cmdarg, _base->arg);
udelay(20); /* To fix "No status update" error on eMMC */
writel((cmd->cmdidx << 24) | flags, _base->cmd);
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 21/24] dts: am57xx-beagle-x15: disable UHS and HS200 support

2018-01-30 Thread Jean-Jacques Hiblot
The UHS modes are not supported in beagle-x15 because it's not possible to
switch the IO lines supply voltage to 1.8v.
Also HS200 cannot be supported on mmc2, because the IO lines of mmc2 are
connected to 3.3v.

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/dts/am57xx-beagle-x15.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/am57xx-beagle-x15.dts 
b/arch/arm/dts/am57xx-beagle-x15.dts
index d668910..8d9bdf1 100644
--- a/arch/arm/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/dts/am57xx-beagle-x15.dts
@@ -25,6 +25,11 @@
pinctrl-1 = <_pins_hs>;
 
vmmc-supply = <_reg>;
+   /delete-property/ sd-uhs-sdr104;
+   /delete-property/ sd-uhs-sdr50;
+   /delete-property/ sd-uhs-ddr50;
+   /delete-property/ sd-uhs-sdr25;
+   /delete-property/ sd-uhs-sdr12;
 };
 
  {
@@ -32,6 +37,7 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_hs>;
pinctrl-2 = <_pins_ddr_3_3v_rev11 
_iodelay_ddr_3_3v_rev11_conf>;
+   /delete-property/ mmc-hs200-1_8v;
 };
 
 /* errata i880 "Ethernet RGMII2 Limited to 10/100 Mbps" */
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 17/24] mmc: omap_hsmmc: add signal voltage selection support

2018-01-30 Thread Jean-Jacques Hiblot
I/O data lines of UHS SD card operates at 1.8V when in UHS speed
mode (same is true for eMMC in DDR and HS200 modes). Add support
to switch signal voltage to 1.8V in order to support
UHS cards and eMMC HS200 and DDR modes.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/include/asm/omap_mmc.h |  10 ++-
 drivers/mmc/omap_hsmmc.c| 176 +++-
 2 files changed, 160 insertions(+), 26 deletions(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index c50087e..c6129c5 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -172,10 +172,6 @@ struct omap_hsmmc_plat {
 #define VS30_3V0SUPBIT(25)
 #define VS18_1V8SUPBIT(26)
 
-#define IOV_3V3330
-#define IOV_3V0300
-#define IOV_1V8180
-
 #define AC12_ETBIT(22)
 #define AC12_V1V8_SIGENBIT(19)
 #define AC12_SCLK_SEL  BIT(23)
@@ -224,6 +220,12 @@ struct omap_hsmmc_plat {
IE_DTO | IE_CIE | IE_CEB | IE_CCRC | IE_ADMAE | IE_CTO |\
IE_BRR | IE_BWR | IE_TC | IE_CC)
 
+#define CON_CLKEXTFREE BIT(16)
+#define CON_PADEN  BIT(15)
+#define PSTATE_CLEVBIT(24)
+#define PSTATE_DLEV(0xF << 20)
+#define PSTATE_DLEV_DAT0   (0x1 << 20)
+
 int omap_mmc_init(int dev_index, uint host_caps_mask, uint f_max, int cd_gpio,
int wp_gpio);
 
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 0e80420..24027f2 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -78,6 +78,7 @@ struct omap_hsmmc_data {
 #endif
uint bus_width;
uint clock;
+   ushort last_cmd;
 #ifdef OMAP_HSMMC_USE_GPIO
 #if CONFIG_IS_ENABLED(DM_MMC)
struct gpio_desc cd_gpio;   /* Change Detect GPIO */
@@ -89,7 +90,6 @@ struct omap_hsmmc_data {
 #endif
 #endif
 #if CONFIG_IS_ENABLED(DM_MMC)
-   uint iov;
enum bus_mode mode;
 #endif
u8 controller_flags;
@@ -98,6 +98,8 @@ struct omap_hsmmc_data {
uint desc_slot;
 #endif
const char *hw_rev;
+   struct udevice *pbias_supply;
+   uint signal_voltage;
 #ifdef CONFIG_IODELAY_RECALIBRATION
struct omap_hsmmc_pinctrl_state *default_pinctrl_state;
struct omap_hsmmc_pinctrl_state *hs_pinctrl_state;
@@ -254,7 +256,8 @@ static unsigned char mmc_board_init(struct mmc *mmc)
_base->iclken1_core);
 #endif
 
-#if defined(CONFIG_OMAP54XX) || defined(CONFIG_OMAP44XX)
+#if (defined(CONFIG_OMAP54XX) || defined(CONFIG_OMAP44XX)) &&\
+   !CONFIG_IS_ENABLED(DM_REGULATOR)
/* PBIAS config needed for MMC1 only */
if (mmc_get_blk_desc(mmc)->devnum == 0)
vmmc_pbias_config(LDO_VOLT_3V0);
@@ -398,32 +401,148 @@ static void omap_hsmmc_set_timing(struct mmc *mmc)
omap_hsmmc_start_clock(mmc_base);
 }
 
-static void omap_hsmmc_conf_bus_power(struct mmc *mmc)
+static void omap_hsmmc_conf_bus_power(struct mmc *mmc, uint signal_voltage)
 {
struct hsmmc *mmc_base;
struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
-   u32 val;
+   u32 hctl, ac12;
 
mmc_base = priv->base_addr;
 
-   val = readl(_base->hctl) & ~SDVS_MASK;
+   hctl = readl(_base->hctl) & ~SDVS_MASK;
+   ac12 = readl(_base->ac12) & ~AC12_V1V8_SIGEN;
 
-   switch (priv->iov) {
-   case IOV_3V3:
-   val |= SDVS_3V3;
-   break;
-   case IOV_3V0:
-   val |= SDVS_3V0;
+   switch (signal_voltage) {
+   case MMC_SIGNAL_VOLTAGE_330:
+   hctl |= SDVS_3V0;
break;
-   case IOV_1V8:
-   val |= SDVS_1V8;
+   case MMC_SIGNAL_VOLTAGE_180:
+   hctl |= SDVS_1V8;
+   ac12 |= AC12_V1V8_SIGEN;
break;
}
 
-   writel(val, _base->hctl);
+   writel(hctl, _base->hctl);
+   writel(ac12, _base->ac12);
 }
 
-static void omap_hsmmc_set_capabilities(struct mmc *mmc)
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT)
+static int omap_hsmmc_wait_dat0(struct udevice *dev, int state, int timeout)
+{
+   int ret = -ETIMEDOUT;
+   u32 con;
+   bool dat0_high;
+   bool target_dat0_high = !!state;
+   struct omap_hsmmc_data *priv = dev_get_priv(dev);
+   struct hsmmc *mmc_base = priv->base_addr;
+
+   con = readl(_base->con);
+   writel(con | CON_CLKEXTFREE | CON_PADEN, _base->con);
+
+   timeout = DIV_ROUND_UP(timeout, 10); /* check every 10 us. */
+   while (timeout--)   {
+   dat0_high = !!(readl(_base->pstate) & PSTATE_DLEV_DAT0);
+   if (dat0_high == target_dat0_high) {
+   ret = 0;
+   break;

[U-Boot] [PATCH v3 18/24] ARM: OMAP5: set mmc clock frequency to 192MHz

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

Now that omap_hsmmc has support for hs200 mode, change the clock
frequency to 192MHz. Also change the REFERENCE CLOCK frequency to
192MHz based on which the internal mmc clock divider is calculated.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/include/asm/arch-omap5/clock.h |  2 +-
 arch/arm/include/asm/omap_mmc.h |  4 
 arch/arm/mach-omap2/omap5/hw_data.c | 10 +-
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
b/arch/arm/include/asm/arch-omap5/clock.h
index ee2e78b..3d718c0 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -135,7 +135,7 @@
 
 /* CM_L3INIT_HSMMCn_CLKCTRL */
 #define HSMMC_CLKCTRL_CLKSEL_MASK  (1 << 24)
-#define HSMMC_CLKCTRL_CLKSEL_DIV_MASK  (1 << 25)
+#define HSMMC_CLKCTRL_CLKSEL_DIV_MASK  (3 << 25)
 
 /* CM_L3INIT_SATA_CLKCTRL */
 #define SATA_CLKCTRL_OPTFCLKEN_MASK(1 << 8)
diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index c6129c5..3d70148 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -199,7 +199,11 @@ struct omap_hsmmc_plat {
 #define MMC_CMD0   (INDEX(0)  | RSP_TYPE_NONE | DP_NO_DATA | DDIR_WRITE)
 
 /* Clock Configurations and Macros */
+#ifdef CONFIG_OMAP54XX
+#define MMC_CLOCK_REFERENCE192 /* MHz */
+#else
 #define MMC_CLOCK_REFERENCE96 /* MHz */
+#endif
 
 /* DLL */
 #define DLL_SWTBIT(20)
diff --git a/arch/arm/mach-omap2/omap5/hw_data.c 
b/arch/arm/mach-omap2/omap5/hw_data.c
index bb05e19..7fc3836 100644
--- a/arch/arm/mach-omap2/omap5/hw_data.c
+++ b/arch/arm/mach-omap2/omap5/hw_data.c
@@ -438,17 +438,17 @@ void enable_basic_clocks(void)
setbits_le32((*prcm)->cm_l4per_gpio4_clkctrl,
GPIO4_CLKCTRL_OPTFCLKEN_MASK);
 
-   /* Enable 96 MHz clock for MMC1 & MMC2 */
+   /* Enable 192 MHz clock for MMC1 & MMC2 */
setbits_le32((*prcm)->cm_l3init_hsmmc1_clkctrl,
HSMMC_CLKCTRL_CLKSEL_MASK);
setbits_le32((*prcm)->cm_l3init_hsmmc2_clkctrl,
HSMMC_CLKCTRL_CLKSEL_MASK);
 
/* Set the correct clock dividers for mmc */
-   setbits_le32((*prcm)->cm_l3init_hsmmc1_clkctrl,
-   HSMMC_CLKCTRL_CLKSEL_DIV_MASK);
-   setbits_le32((*prcm)->cm_l3init_hsmmc2_clkctrl,
-   HSMMC_CLKCTRL_CLKSEL_DIV_MASK);
+   clrbits_le32((*prcm)->cm_l3init_hsmmc1_clkctrl,
+HSMMC_CLKCTRL_CLKSEL_DIV_MASK);
+   clrbits_le32((*prcm)->cm_l3init_hsmmc2_clkctrl,
+HSMMC_CLKCTRL_CLKSEL_DIV_MASK);
 
/* Select 32KHz clock as the source of GPTIMER1 */
setbits_le32((*prcm)->cm_wkup_gptimer1_clkctrl,
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 12/24] mmc: omap_hsmmc: Add support to get pinctrl values and max frequency for different hw revisions

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

AM572x SR1.1 requires different IODelay values to be used than that used
in AM572x SR2.0. These values are populated in device tree. Add
capability in omap_hsmmc driver to extract IOdelay values for different
silicon revision. The maximum frequency is also reduced when using a ES1.1.
To keep the ability to boot both revsions with the same dtb, those values
can be provided by the platform code.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/include/asm/arch-omap5/sys_proto.h |  7 
 arch/arm/include/asm/omap_mmc.h |  1 +
 drivers/mmc/omap_hsmmc.c| 58 ++---
 3 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/sys_proto.h 
b/arch/arm/include/asm/arch-omap5/sys_proto.h
index a6b3557..d43cd7f 100644
--- a/arch/arm/include/asm/arch-omap5/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap5/sys_proto.h
@@ -35,6 +35,12 @@ struct pad_conf_entry {
u32 val;
 };
 
+struct mmc_platform_fixups {
+   const char *hw_rev;
+   u32 unsupported_caps;
+   u32 max_freq;
+};
+
 struct omap_sysinfo {
char *board_string;
 };
@@ -71,6 +77,7 @@ void force_emif_self_refresh(void);
 void get_ioregs(const struct ctrl_ioregs **regs);
 void srcomp_enable(void);
 void setup_warmreset_time(void);
+const struct mmc_platform_fixups *platform_fixups_mmc(uint32_t addr);
 
 static inline u32 div_round_up(u32 num, u32 den)
 {
diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index 635ce1e..c50087e 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -70,6 +70,7 @@ struct omap_hsmmc_plat {
struct mmc mmc;
bool cd_inverted;
u32 controller_flags;
+   const char *hw_rev;
 };
 
 /*
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 2b77422..766cd09 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -96,6 +96,7 @@ struct omap_hsmmc_data {
struct omap_hsmmc_adma_desc *adma_desc_table;
uint desc_slot;
 #endif
+   const char *hw_rev;
 #ifdef CONFIG_IODELAY_RECALIBRATION
struct omap_hsmmc_pinctrl_state *default_pinctrl_state;
struct omap_hsmmc_pinctrl_state *hs_pinctrl_state;
@@ -1368,6 +1369,7 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, 
uint f_max, int cd_gpio,
if ((get_cpu_family() == CPU_OMAP34XX) && (get_cpu_rev() <= 
CPU_3XX_ES21))
cfg->b_max = 1;
 #endif
+
mmc = mmc_create(cfg, priv);
if (mmc == NULL)
return -1;
@@ -1587,20 +1589,28 @@ err_pinctrl_state:
return 0;
 }
 
-#define OMAP_HSMMC_SETUP_PINCTRL(capmask, mode)\
-   do {\
-   struct omap_hsmmc_pinctrl_state *s; \
-   if (!(cfg->host_caps & capmask))\
-   break;  \
-   \
-   s = omap_hsmmc_get_pinctrl_by_mode(mmc, #mode); \
-   if (!s) {   \
-   debug("%s: no pinctrl for %s\n",\
- mmc->dev->name, #mode);   \
-   cfg->host_caps &= ~(capmask);   \
-   } else {\
-   priv->mode##_pinctrl_state = s; \
-   }   \
+#define OMAP_HSMMC_SETUP_PINCTRL(capmask, mode)
\
+   do {\
+   struct omap_hsmmc_pinctrl_state *s = NULL;  \
+   char str[20];   \
+   if (!(cfg->host_caps & capmask))\
+   break;  \
+   \
+   if (priv->hw_rev) { \
+   sprintf(str, "%s-%s", #mode, priv->hw_rev); \
+   s = omap_hsmmc_get_pinctrl_by_mode(mmc, str);   \
+   }   \
+   \
+   if (!s) \
+   s = omap_hsmmc_get_pinctrl_by_mode(mmc, #mode); \
+   \
+   if (!s) {   \
+   debug("%s: no pinctrl for %s\n",\
+

[U-Boot] [PATCH v3 14/24] mmc: omap_hsmmc: update mmc->clock with the actual bus speed

2018-01-30 Thread Jean-Jacques Hiblot
When the clock is applied, compute the actual value of the clock. It may be
slightly different from the requested value (max freq, divisor threshold)

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 37fa7a4..b10d55e 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1147,7 +1147,8 @@ static void omap_hsmmc_set_clock(struct mmc *mmc)
}
}
 
-   priv->clock = mmc->clock;
+   priv->clock = MMC_CLOCK_REFERENCE * 100 / dsor;
+   mmc->clock = priv->clock;
omap_hsmmc_start_clock(mmc_base);
 }
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 03/24] mmc: omap_hsmmc: add support to set default io voltage

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

"ti,dual-volt" is used in linux kernel to set the voltage capabilities.
For host controller dt nodes that doesn't have "ti,dual-volt",
it's assumed 1.8v is the io voltage. This is not always true (like in
the case of beagle-x15 where the io lines are connected to 3.3v).
Hence if "no-1-8-v" property is set, io voltage will be set to 3v.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/include/asm/omap_mmc.h | 12 ++--
 drivers/mmc/omap_hsmmc.c| 67 +
 2 files changed, 77 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index 102aec2..c4d326d 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -65,6 +65,7 @@ struct omap_hsmmc_plat {
struct hsmmc *base_addr;
struct mmc mmc;
bool cd_inverted;
+   u32 controller_flags;
 };
 
 /*
@@ -124,8 +125,10 @@ struct omap_hsmmc_plat {
 #define DTW_8_BITMODE   (0x1 << 5) /* CON[DW8]*/
 #define SDBP_PWROFF(0x0 << 8)
 #define SDBP_PWRON (0x1 << 8)
+#define SDVS_MASK  (0x7 << 9)
 #define SDVS_1V8   (0x5 << 9)
 #define SDVS_3V0   (0x6 << 9)
+#define SDVS_3V3   (0x7 << 9)
 #define DMA_SELECT (0x2 << 3)
 #define ICE_MASK   (0x1 << 0)
 #define ICE_STOP   (0x0 << 0)
@@ -159,8 +162,13 @@ struct omap_hsmmc_plat {
 #define IE_CERR(0x01 << 28)
 #define IE_BADA(0x01 << 29)
 
-#define VS30_3V0SUP(1 << 25)
-#define VS18_1V8SUP(1 << 26)
+#define VS33_3V3SUPBIT(24)
+#define VS30_3V0SUPBIT(25)
+#define VS18_1V8SUPBIT(26)
+
+#define IOV_3V3330
+#define IOV_3V0300
+#define IOV_1V8180
 
 /* Driver definitions */
 #define MMCSD_SECTOR_SIZE  512
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 713faab..5141bf6 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -74,6 +74,9 @@ struct omap_hsmmc_data {
int wp_gpio;
 #endif
 #endif
+#if CONFIG_IS_ENABLED(DM_MMC)
+   uint iov;
+#endif
u8 controller_flags;
 #ifndef CONFIG_OMAP34XX
struct omap_hsmmc_adma_desc *adma_desc_table;
@@ -111,6 +114,8 @@ struct omap_hsmmc_adma_desc {
  * that the bandwidth is always above 3MB/s).
  */
 #define DMA_TIMEOUT_PER_MB 333
+#define OMAP_HSMMC_SUPPORTS_DUAL_VOLT  BIT(0)
+#define OMAP_HSMMC_NO_1_8_VBIT(1)
 #define OMAP_HSMMC_USE_ADMABIT(2)
 
 static int mmc_read_data(struct hsmmc *mmc_base, char *buf, unsigned int size);
@@ -252,6 +257,58 @@ void mmc_init_stream(struct hsmmc *mmc_base)
writel(readl(_base->con) & ~INIT_INITSTREAM, _base->con);
 }
 
+#if CONFIG_IS_ENABLED(DM_MMC)
+static void omap_hsmmc_conf_bus_power(struct mmc *mmc)
+{
+   struct hsmmc *mmc_base;
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+   u32 val;
+
+   mmc_base = priv->base_addr;
+
+   val = readl(_base->hctl) & ~SDVS_MASK;
+
+   switch (priv->iov) {
+   case IOV_3V3:
+   val |= SDVS_3V3;
+   break;
+   case IOV_3V0:
+   val |= SDVS_3V0;
+   break;
+   case IOV_1V8:
+   val |= SDVS_1V8;
+   break;
+   }
+
+   writel(val, _base->hctl);
+}
+
+static void omap_hsmmc_set_capabilities(struct mmc *mmc)
+{
+   struct hsmmc *mmc_base;
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+   u32 val;
+
+   mmc_base = priv->base_addr;
+   val = readl(_base->capa);
+
+   if (priv->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
+   val |= (VS30_3V0SUP | VS18_1V8SUP);
+   priv->iov = IOV_3V0;
+   } else if (priv->controller_flags & OMAP_HSMMC_NO_1_8_V) {
+   val |= VS30_3V0SUP;
+   val &= ~VS18_1V8SUP;
+   priv->iov = IOV_3V0;
+   } else {
+   val |= VS18_1V8SUP;
+   val &= ~VS30_3V0SUP;
+   priv->iov = IOV_1V8;
+   }
+
+   writel(val, _base->capa);
+}
+#endif
+
 static int omap_hsmmc_init_setup(struct mmc *mmc)
 {
struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
@@ -286,9 +343,15 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
if (reg_val & MADMA_EN)
priv->controller_flags |= OMAP_HSMMC_USE_ADMA;
 #endif
+
+#if CONFIG_IS_ENABLED(DM_MMC)
+   omap_hsmmc_set_capabilities(mmc);
+   omap_hsmmc_conf_bus_power(mmc);
+#else
  

[U-Boot] [PATCH v3 24/24] configs: dra7xx_evm/dra7xx_hs_evm: Enable MMC HS200 and SD UHS support

2018-01-30 Thread Jean-Jacques Hiblot
By default UHS and HS200 are not enabled.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v3: None

 configs/dra7xx_evm_defconfig| 3 +++
 configs/dra7xx_hs_evm_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index b13a27e..e79e6d6 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -49,6 +49,9 @@ CONFIG_DM_GPIO=y
 CONFIG_PCF8575_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 7ccb4f0..bc15fd8 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -51,6 +51,9 @@ CONFIG_DM_GPIO=y
 CONFIG_PCF8575_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 13/24] mmc: omap_hsmmc: allow the simple HS modes to use the default pinctrl

2018-01-30 Thread Jean-Jacques Hiblot
The default configuration is usually working fine for the the HS modes.
Don't enforce the presence of a dedicated pinmux for the HS modes.

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 766cd09..37fa7a4 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -328,6 +328,9 @@ static void omap_hsmmc_io_recalibrate(struct mmc *mmc)
break;
}
 
+   if (!pinctrl_state)
+   pinctrl_state = priv->default_pinctrl_state;
+
if (priv->controller_flags & OMAP_HSMMC_REQUIRE_IODELAY) {
if (pinctrl_state->iodelay)
late_recalibrate_iodelay(pinctrl_state->padconf,
@@ -1589,7 +1592,7 @@ err_pinctrl_state:
return 0;
 }
 
-#define OMAP_HSMMC_SETUP_PINCTRL(capmask, mode)
\
+#define OMAP_HSMMC_SETUP_PINCTRL(capmask, mode, optional)  \
do {\
struct omap_hsmmc_pinctrl_state *s = NULL;  \
char str[20];   \
@@ -1604,7 +1607,7 @@ err_pinctrl_state:
if (!s) \
s = omap_hsmmc_get_pinctrl_by_mode(mmc, #mode); \
\
-   if (!s) {   \
+   if (!s && !optional) {  \
debug("%s: no pinctrl for %s\n",\
  mmc->dev->name, #mode);   \
cfg->host_caps &= ~(capmask);   \
@@ -1630,15 +1633,15 @@ static int omap_hsmmc_get_pinctrl_state(struct mmc *mmc)
 
priv->default_pinctrl_state = default_pinctrl;
 
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR104), sdr104);
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR50), sdr50);
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_DDR50), ddr50);
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR25), sdr25);
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR12), sdr12);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR104), sdr104, false);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR50), sdr50, false);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_DDR50), ddr50, false);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR25), sdr25, false);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(UHS_SDR12), sdr12, false);
 
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(MMC_HS_200), hs200_1_8v);
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(MMC_DDR_52), ddr_1_8v);
-   OMAP_HSMMC_SETUP_PINCTRL(MMC_MODE_HS, hs);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(MMC_HS_200), hs200_1_8v, false);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_CAP(MMC_DDR_52), ddr_1_8v, false);
+   OMAP_HSMMC_SETUP_PINCTRL(MMC_MODE_HS, hs, true);
 
return 0;
 }
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 11/24] mmc: omap_hsmmc: Add support to set IODELAY values

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met.

Add support to parse mux values and iodelay values from device tree
and set these depending on the enumerated MMC mode.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 372 +++
 1 file changed, 372 insertions(+)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 57548ee..2b77422 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -34,6 +34,10 @@
 #endif
 #include 
 #include 
+#ifdef CONFIG_OMAP54XX
+#include 
+#include 
+#endif
 #if !defined(CONFIG_SOC_KEYSTONE)
 #include 
 #include 
@@ -57,6 +61,15 @@ DECLARE_GLOBAL_DATA_PTR;
 #define SYSCTL_SRC (1 << 25)
 #define SYSCTL_SRD (1 << 26)
 
+#ifdef CONFIG_IODELAY_RECALIBRATION
+struct omap_hsmmc_pinctrl_state {
+   struct pad_conf_entry *padconf;
+   int npads;
+   struct iodelay_cfg_entry *iodelay;
+   int niodelays;
+};
+#endif
+
 struct omap_hsmmc_data {
struct hsmmc *base_addr;
 #if !CONFIG_IS_ENABLED(DM_MMC)
@@ -83,6 +96,21 @@ struct omap_hsmmc_data {
struct omap_hsmmc_adma_desc *adma_desc_table;
uint desc_slot;
 #endif
+#ifdef CONFIG_IODELAY_RECALIBRATION
+   struct omap_hsmmc_pinctrl_state *default_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *hs_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *hs200_1_8v_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *ddr_1_8v_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *sdr12_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *sdr25_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *ddr50_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *sdr50_pinctrl_state;
+   struct omap_hsmmc_pinctrl_state *sdr104_pinctrl_state;
+#endif
+};
+
+struct omap_mmc_of_data {
+   u8 controller_flags;
 };
 
 #ifndef CONFIG_OMAP34XX
@@ -119,6 +147,7 @@ struct omap_hsmmc_adma_desc {
 #define OMAP_HSMMC_SUPPORTS_DUAL_VOLT  BIT(0)
 #define OMAP_HSMMC_NO_1_8_VBIT(1)
 #define OMAP_HSMMC_USE_ADMABIT(2)
+#define OMAP_HSMMC_REQUIRE_IODELAY BIT(3)
 
 static int mmc_read_data(struct hsmmc *mmc_base, char *buf, unsigned int size);
 static int mmc_write_data(struct hsmmc *mmc_base, const char *buf,
@@ -261,6 +290,56 @@ void mmc_init_stream(struct hsmmc *mmc_base)
 }
 
 #if CONFIG_IS_ENABLED(DM_MMC)
+#ifdef CONFIG_IODELAY_RECALIBRATION
+static void omap_hsmmc_io_recalibrate(struct mmc *mmc)
+{
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+   struct omap_hsmmc_pinctrl_state *pinctrl_state;
+
+   switch (priv->mode) {
+   case MMC_HS_200:
+   pinctrl_state = priv->hs200_1_8v_pinctrl_state;
+   break;
+   case UHS_SDR104:
+   pinctrl_state = priv->sdr104_pinctrl_state;
+   break;
+   case UHS_SDR50:
+   pinctrl_state = priv->sdr50_pinctrl_state;
+   break;
+   case UHS_DDR50:
+   pinctrl_state = priv->ddr50_pinctrl_state;
+   break;
+   case UHS_SDR25:
+   pinctrl_state = priv->sdr25_pinctrl_state;
+   break;
+   case UHS_SDR12:
+   pinctrl_state = priv->sdr12_pinctrl_state;
+   break;
+   case SD_HS:
+   case MMC_HS:
+   case MMC_HS_52:
+   pinctrl_state = priv->hs_pinctrl_state;
+   break;
+   case MMC_DDR_52:
+   pinctrl_state = priv->ddr_1_8v_pinctrl_state;
+   default:
+   pinctrl_state = priv->default_pinctrl_state;
+   break;
+   }
+
+   if (priv->controller_flags & OMAP_HSMMC_REQUIRE_IODELAY) {
+   if (pinctrl_state->iodelay)
+   late_recalibrate_iodelay(pinctrl_state->padconf,
+pinctrl_state->npads,
+pinctrl_state->iodelay,
+pinctrl_state->niodelays);
+   else
+   do_set_mux32((*ctrl)->control_padconf_core_base,
+pinctrl_state->padconf,
+pinctrl_state->npads);
+   }
+}
+#endif
 static void omap_hsmmc_set_timing(struct mmc *mmc)
 {
u32 val;
@@ -269,6 +348,7 @@ static void omap_hsmmc_set_timing(struct mmc *mmc)
 
mmc_base = priv->base_addr;
 
+   omap_hsmmc_stop_clock(mmc_base);
val = readl(_base->ac12);
val &= ~AC12_UHSMC_MASK;
priv->mode = mmc->selected_mode;
@@ -306,6 +386,11 @@ static void omap_hsmmc_set_timing(struct mmc *mmc)
break;
}

[U-Boot] [PATCH v3 04/24] mmc: omap_hsmmc: set MMC mode in the UHSMS bit field

2018-01-30 Thread Jean-Jacques Hiblot
Use the timing parameter set in the MMC core to set the
mode in UHSMS  bit field. This is in preparation for
adding HS200 support in omap hsmmc driver.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v3:
- prefer the usage of the BIT() macro over the construct ( 1 << x )

 arch/arm/include/asm/omap_mmc.h | 12 ++-
 drivers/mmc/omap_hsmmc.c| 47 +
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index c4d326d..507435a 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -53,7 +53,8 @@ struct hsmmc {
unsigned int sysctl;/* 0x12C */
unsigned int stat;  /* 0x130 */
unsigned int ie;/* 0x134 */
-   unsigned char res4[0x8];
+   unsigned char res4[0x4];
+   unsigned int ac12;  /* 0x13C */
unsigned int capa;  /* 0x140 */
unsigned char res5[0x10];
unsigned int admaes;/* 0x154 */
@@ -170,6 +171,15 @@ struct omap_hsmmc_plat {
 #define IOV_3V0300
 #define IOV_1V8180
 
+#define AC12_ETBIT(22)
+#define AC12_UHSMC_MASK(7 << 16)
+#define AC12_UHSMC_DDR50   (4 << 16)
+#define AC12_UHSMC_SDR104  (3 << 16)
+#define AC12_UHSMC_SDR50   (2 << 16)
+#define AC12_UHSMC_SDR25   (1 << 16)
+#define AC12_UHSMC_SDR12   (0 << 16)
+#define AC12_UHSMC_RES (0x7 << 16)
+
 /* Driver definitions */
 #define MMCSD_SECTOR_SIZE  512
 #define MMC_CARD   0
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 5141bf6..c6b74a1 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -76,6 +76,7 @@ struct omap_hsmmc_data {
 #endif
 #if CONFIG_IS_ENABLED(DM_MMC)
uint iov;
+   enum bus_mode mode;
 #endif
u8 controller_flags;
 #ifndef CONFIG_OMAP34XX
@@ -258,6 +259,48 @@ void mmc_init_stream(struct hsmmc *mmc_base)
 }
 
 #if CONFIG_IS_ENABLED(DM_MMC)
+static void omap_hsmmc_set_timing(struct mmc *mmc)
+{
+   u32 val;
+   struct hsmmc *mmc_base;
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+
+   mmc_base = priv->base_addr;
+
+   val = readl(_base->ac12);
+   val &= ~AC12_UHSMC_MASK;
+   priv->mode = mmc->selected_mode;
+
+   switch (priv->mode) {
+   case MMC_HS_200:
+   case UHS_SDR104:
+   val |= AC12_UHSMC_SDR104;
+   break;
+   case UHS_SDR50:
+   val |= AC12_UHSMC_SDR50;
+   break;
+   case MMC_DDR_52:
+   case UHS_DDR50:
+   val |= AC12_UHSMC_DDR50;
+   break;
+   case SD_HS:
+   case MMC_HS_52:
+   case UHS_SDR25:
+   val |= AC12_UHSMC_SDR25;
+   break;
+   case MMC_LEGACY:
+   case MMC_HS:
+   case SD_LEGACY:
+   case UHS_SDR12:
+   val |= AC12_UHSMC_SDR12;
+   break;
+   default:
+   val |= AC12_UHSMC_RES;
+   break;
+   }
+   writel(val, _base->ac12);
+}
+
 static void omap_hsmmc_conf_bus_power(struct mmc *mmc)
 {
struct hsmmc *mmc_base;
@@ -928,6 +971,10 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
if (priv->clock != mmc->clock)
omap_hsmmc_set_clock(mmc);
 
+#if CONFIG_IS_ENABLED(DM_MMC)
+   if (priv->mode != mmc->selected_mode)
+   omap_hsmmc_set_timing(mmc);
+#endif
return 0;
 }
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 16/24] mmc: omap_hsmmc: allow mmc clock to be gated

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

mmc core has defined a new parameter *clk_disable* to gate the clock.
Disable the clock here if *clk_disable* is set.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 71608d1..0e80420 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1207,6 +1207,7 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct mmc *mmc = upriv->mmc;
 #endif
+   struct hsmmc *mmc_base = priv->base_addr;
 
if (priv->bus_width != mmc->bus_width)
omap_hsmmc_set_bus_width(mmc);
@@ -1214,6 +1215,11 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
if (priv->clock != mmc->clock)
omap_hsmmc_set_clock(mmc);
 
+   if (mmc->clk_disable)
+   omap_hsmmc_stop_clock(mmc_base);
+   else
+   omap_hsmmc_start_clock(mmc_base);
+
 #if CONFIG_IS_ENABLED(DM_MMC)
if (priv->mode != mmc->selected_mode)
omap_hsmmc_set_timing(mmc);
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 08/24] mmc: omap_hsmmc: Reduce the max timeout for reset controller fsm

2018-01-30 Thread Jean-Jacques Hiblot
From OMAP3 SoCs (OMAP3, OMAP4, OMAP5, AM572x, AM571x), the DAT/CMD lines
reset procedure section in TRM suggests to first poll the SRD/SRC bit
until it is set to 0x1. But looks like that bit is never set to 1 and there
is an observable delay of 1sec everytime the driver tries to reset DAT/CMD.
(The same is observed in linux kernel).

Reduce the time the driver waits for the controller to set the SRC/SRD bits
to 1 so that there is no observable delay.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 5523210..ab4a095 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -108,6 +108,7 @@ struct omap_hsmmc_adma_desc {
 
 /* If we fail after 1 second wait, something is really bad */
 #define MAX_RETRY_MS   1000
+#define MMC_TIMEOUT_MS 20
 
 /* DMA transfers can take a long time if a lot a data is transferred.
  * The timeout must take in account the amount of data. Let's assume
@@ -598,7 +599,7 @@ static void mmc_reset_controller_fsm(struct hsmmc 
*mmc_base, u32 bit)
if (!(readl(_base->sysctl) & bit)) {
start = get_timer(0);
while (!(readl(_base->sysctl) & bit)) {
-   if (get_timer(0) - start > MAX_RETRY_MS)
+   if (get_timer(0) - start > MMC_TIMEOUT_MS)
return;
}
}
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 00/24] omap_hsmmc: Add support for HS200 and UHS modes

2018-01-30 Thread Jean-Jacques Hiblot

This series adds the missing bits to enable the UHS and HS200 modes
for the TI platforms.

Enabling support for high speed modes on omap5 requires implementing:
 * io signal voltage selection
 * tuning support
 * pin configuration (IO delays)

The few last patches enable the high speed modes for the DRA7 platforms and
also take care of disabling those modes in the dts for the platforms that
cannot support either the UHS or the HS200 because the voltage regulators
on board would not allow using those modes (not a SOC limitation).

With this in place we observe significant improvements in the performances:
on a DRA72 evm:
eMMC HS200: 124 MB/s
eMMC DDR52: 78 MB/s
sd   SDR104: 71 MB/s
sd   SDR50: 44 MB/s
For the record, the original performances were:
SD High speed: 18 MB/s
MMC High speed: 18 MB/s

This series has been tested on:
* DRA71-evm
* DRA72-evm
* DRA7x-evm
* DRA76-evm
* AM57x-evm
* Beaglebone Black (dt and non-dt)

Changes in v2:
- rebased on top of u-boot/master
- enable the H200 and UHS support in the defconfigs of the DRA7 platforms

Changes in v3:
- in omap_hsmmc_set_clock(), if mmc->clock is zero, use the max divider.
- prefer the usage of the BIT() macro over the construct ( 1 << x )
- fixed build issue with omap3 platforms

Jean-Jacques Hiblot (13):
  mmc: omap_hsmmc: cleanup clock configuration
  mmc: omap_hsmmc: set MMC mode in the UHSMS bit field
  mmc: omap_hsmmc: Add tuning support
  mmc: omap_hsmmc: Workaround for errata id i802
  mmc: omap_hsmmc: Reduce the max timeout for reset controller fsm
  mmc: omap_hsmmc: allow the simple HS modes to use the default pinctrl
  mmc: omap_hsmmc: update mmc->clock with the actual bus speed
  mmc: omap_hsmmc: implement send_init_stream callback
  mmc: omap_hsmmc: add signal voltage selection support
  ARM: dts: dra7: Add supported MMC/SD modes in MMC dt nodes
  dts: am57xx-beagle-x15: disable UHS and HS200 support
  dts: am57xx-idk: disable HS200 support
  configs: dra7xx_evm/dra7xx_hs_evm: Enable MMC HS200 and SD UHS support

Kishon Vijay Abraham I (11):
  mmc: omap_hsmmc: cleanup omap_hsmmc_set_ios
  mmc: omap_hsmmc: add support to set default io voltage
  mmc: omap_hsmmc: Enable DDR mode support
  mmc: omap_hsmmc: use mmc_of_parse to populate mmc_config
  ARM: OMAP5/DRA7: Enable iodelay recalibration to be done from uboot
  mmc: omap_hsmmc: Add support to set IODELAY values
  mmc: omap_hsmmc: Add support to get pinctrl values and max frequency
for different hw revisions
  mmc: omap_hsmmc: allow mmc clock to be gated
  ARM: OMAP5: set mmc clock frequency to 192MHz
  ARM: dts: DRA7: use new dra7-specific compatible string
  ARM: DRA7x/AM57x: Add MMC/SD fixups for rev1.0 and rev 1.1

 arch/arm/dts/am57xx-beagle-x15.dts   |   6 +
 arch/arm/dts/am57xx-idk-common.dtsi  |   2 +
 arch/arm/dts/dra7.dtsi   |  22 +-
 arch/arm/include/asm/arch-omap5/clock.h  |   2 +-
 arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |   3 +
 arch/arm/include/asm/arch-omap5/sys_proto.h  |   7 +
 arch/arm/include/asm/omap_mmc.h  |  59 +-
 arch/arm/mach-omap2/omap5/dra7xx_iodelay.c   |  30 +
 arch/arm/mach-omap2/omap5/hw_data.c  |  10 +-
 board/ti/am57xx/board.c  |  30 +
 board/ti/dra7xx/evm.c|  29 +
 configs/dra7xx_evm_defconfig |   3 +
 configs/dra7xx_hs_evm_defconfig  |   3 +
 drivers/mmc/omap_hsmmc.c | 952 +--
 include/configs/am57xx_evm.h |   2 -
 include/configs/dra7xx_evm.h |   2 -
 16 files changed, 1087 insertions(+), 75 deletions(-)

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 06/24] mmc: omap_hsmmc: Add tuning support

2018-01-30 Thread Jean-Jacques Hiblot
HS200/SDR104 requires tuning command to be sent to the card. Use
the mmc_send_tuning library function to send the tuning
command and configure the internal DLL.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v3:
- prefer the usage of the BIT() macro over the construct ( 1 << x )

 arch/arm/include/asm/omap_mmc.h |  21 ++-
 drivers/mmc/omap_hsmmc.c| 122 
 2 files changed, 141 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index 6aca9e9..cf9f1c5 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -39,7 +39,9 @@ struct hsmmc {
unsigned int sysstatus; /* 0x14 */
unsigned char res2[0x14];
unsigned int con;   /* 0x2C */
-   unsigned char res3[0xD4];
+   unsigned int pwcnt; /* 0x30 */
+   unsigned int dll;   /* 0x34 */
+   unsigned char res3[0xcc];
unsigned int blk;   /* 0x104 */
unsigned int arg;   /* 0x108 */
unsigned int cmd;   /* 0x10C */
@@ -56,7 +58,8 @@ struct hsmmc {
unsigned char res4[0x4];
unsigned int ac12;  /* 0x13C */
unsigned int capa;  /* 0x140 */
-   unsigned char res5[0x10];
+   unsigned int capa2; /* 0x144 */
+   unsigned char res5[0xc];
unsigned int admaes;/* 0x154 */
unsigned int admasal;   /* 0x158 */
 };
@@ -173,6 +176,8 @@ struct omap_hsmmc_plat {
 #define IOV_1V8180
 
 #define AC12_ETBIT(22)
+#define AC12_V1V8_SIGENBIT(19)
+#define AC12_SCLK_SEL  BIT(23)
 #define AC12_UHSMC_MASK(7 << 16)
 #define AC12_UHSMC_DDR50   (4 << 16)
 #define AC12_UHSMC_SDR104  (3 << 16)
@@ -199,6 +204,18 @@ struct omap_hsmmc_plat {
 /* Clock Configurations and Macros */
 #define MMC_CLOCK_REFERENCE96 /* MHz */
 
+/* DLL */
+#define DLL_SWTBIT(20)
+#define DLL_FORCE_SR_C_SHIFT   13
+#define DLL_FORCE_SR_C_MASK0x7f
+#define DLL_FORCE_VALUEBIT(12)
+#define DLL_CALIB  BIT(1)
+
+#define MAX_PHASE_DELAY0x7c
+
+/* CAPA2 */
+#define CAPA2_TSDR50   BIT(13)
+
 #define mmc_reg_out(addr, mask, val)\
writel((readl(addr) & (~(mask))) | ((val) & (mask)), (addr))
 
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 2f4909e..69a7c2e 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -124,6 +124,7 @@ static int mmc_write_data(struct hsmmc *mmc_base, const 
char *buf,
unsigned int siz);
 static void omap_hsmmc_start_clock(struct hsmmc *mmc_base);
 static void omap_hsmmc_stop_clock(struct hsmmc *mmc_base);
+static void mmc_reset_controller_fsm(struct hsmmc *mmc_base, u32 bit);
 
 static inline struct omap_hsmmc_data *omap_hsmmc_get_data(struct mmc *mmc)
 {
@@ -355,6 +356,124 @@ static void omap_hsmmc_set_capabilities(struct mmc *mmc)
 
writel(val, _base->capa);
 }
+
+#ifdef MMC_SUPPORTS_TUNING
+static void omap_hsmmc_disable_tuning(struct mmc *mmc)
+{
+   struct hsmmc *mmc_base;
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+   u32 val;
+
+   mmc_base = priv->base_addr;
+   val = readl(_base->ac12);
+   val &= ~(AC12_SCLK_SEL);
+   writel(val, _base->ac12);
+
+   val = readl(_base->dll);
+   val &= ~(DLL_FORCE_VALUE | DLL_SWT);
+   writel(val, _base->dll);
+}
+
+static void omap_hsmmc_set_dll(struct mmc *mmc, int count)
+{
+   int i;
+   struct hsmmc *mmc_base;
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+   u32 val;
+
+   mmc_base = priv->base_addr;
+   val = readl(_base->dll);
+   val |= DLL_FORCE_VALUE;
+   val &= ~(DLL_FORCE_SR_C_MASK << DLL_FORCE_SR_C_SHIFT);
+   val |= (count << DLL_FORCE_SR_C_SHIFT);
+   writel(val, _base->dll);
+
+   val |= DLL_CALIB;
+   writel(val, _base->dll);
+   for (i = 0; i < 1000; i++) {
+   if (readl(_base->dll) & DLL_CALIB)
+   break;
+   }
+   val &= ~DLL_CALIB;
+   writel(val, _base->dll);
+}
+
+static int omap_hsmmc_execute_tuning(struct udevice *dev, uint opcode)
+{
+   struct omap_hsmmc_data *priv = dev_get_priv(dev);
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct mmc *mmc = upriv->mmc;
+   struct hsmmc *mmc_base;
+   u32 val;
+   u8 cur_match, prev_match = 0;
+   int ret;
+   u32 phase_delay = 0;
+   u32 start_window = 0, max_window = 0;
+   u32 length = 0, max_len = 0;
+
+   mmc_base = priv->base_addr;
+   val = readl(_base->capa2);
+
+   /* clock tuning is not 

[U-Boot] [PATCH v3 01/24] mmc: omap_hsmmc: cleanup clock configuration

2018-01-30 Thread Jean-Jacques Hiblot
Add a separate function for starting the clock, stopping the clock and
setting the clock. Starting the clock and stopping the clock can
be used irrespective of setting the clock (For example during iodelay
recalibration).
Also set the clock only if there is a change in frequency.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v3:
- in omap_hsmmc_set_clock(), if mmc->clock is zero, use the max divider.

 arch/arm/include/asm/omap_mmc.h |  2 ++
 drivers/mmc/omap_hsmmc.c| 76 -
 2 files changed, 54 insertions(+), 24 deletions(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index bf9de9b..102aec2 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -172,6 +172,8 @@ struct omap_hsmmc_plat {
 #define CLK_400KHZ 1
 #define CLK_MISC   2
 
+#define CLKD_MAX   0x3FF   /* max clock divisor: 1023 */
+
 #define RSP_TYPE_NONE  (RSP_TYPE_NORSP   | CCCE_NOCHECK | CICE_NOCHECK)
 #define MMC_CMD0   (INDEX(0)  | RSP_TYPE_NONE | DP_NO_DATA | DDIR_WRITE)
 
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index b12d6d9..fa8681a 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -62,6 +62,7 @@ struct omap_hsmmc_data {
 #if !CONFIG_IS_ENABLED(DM_MMC)
struct mmc_config cfg;
 #endif
+   uint clock;
 #ifdef OMAP_HSMMC_USE_GPIO
 #if CONFIG_IS_ENABLED(DM_MMC)
struct gpio_desc cd_gpio;   /* Change Detect GPIO */
@@ -114,6 +115,8 @@ struct omap_hsmmc_adma_desc {
 static int mmc_read_data(struct hsmmc *mmc_base, char *buf, unsigned int size);
 static int mmc_write_data(struct hsmmc *mmc_base, const char *buf,
unsigned int siz);
+static void omap_hsmmc_start_clock(struct hsmmc *mmc_base);
+static void omap_hsmmc_stop_clock(struct hsmmc *mmc_base);
 
 static inline struct omap_hsmmc_data *omap_hsmmc_get_data(struct mmc *mmc)
 {
@@ -764,6 +767,53 @@ static int mmc_write_data(struct hsmmc *mmc_base, const 
char *buf,
return 0;
 }
 
+static void omap_hsmmc_stop_clock(struct hsmmc *mmc_base)
+{
+   writel(readl(_base->sysctl) & ~CEN_ENABLE, _base->sysctl);
+}
+
+static void omap_hsmmc_start_clock(struct hsmmc *mmc_base)
+{
+   writel(readl(_base->sysctl) | CEN_ENABLE, _base->sysctl);
+}
+
+static void omap_hsmmc_set_clock(struct mmc *mmc)
+{
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+   struct hsmmc *mmc_base;
+   unsigned int dsor = 0;
+   ulong start;
+
+   mmc_base = priv->base_addr;
+   omap_hsmmc_stop_clock(mmc_base);
+
+   /* TODO: Is setting DTO required here? */
+   mmc_reg_out(_base->sysctl, (ICE_MASK | DTO_MASK),
+   (ICE_STOP | DTO_15THDTO));
+
+   if (mmc->clock != 0) {
+   dsor = DIV_ROUND_UP(MMC_CLOCK_REFERENCE * 100, mmc->clock);
+   if (dsor > CLKD_MAX)
+   dsor = CLKD_MAX;
+   } else {
+   dsor = CLKD_MAX;
+   }
+
+   mmc_reg_out(_base->sysctl, ICE_MASK | CLKD_MASK,
+   (dsor << CLKD_OFFSET) | ICE_OSCILLATE);
+
+   start = get_timer(0);
+   while ((readl(_base->sysctl) & ICS_MASK) == ICS_NOTREADY) {
+   if (get_timer(0) - start > MAX_RETRY_MS) {
+   printf("%s: timedout waiting for ics!\n", __func__);
+   return;
+   }
+   }
+
+   priv->clock = mmc->clock;
+   omap_hsmmc_start_clock(mmc_base);
+}
+
 #if !CONFIG_IS_ENABLED(DM_MMC)
 static int omap_hsmmc_set_ios(struct mmc *mmc)
 {
@@ -776,8 +826,6 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
struct mmc *mmc = upriv->mmc;
 #endif
struct hsmmc *mmc_base;
-   unsigned int dsor = 0;
-   ulong start;
 
mmc_base = priv->base_addr;
/* configue bus width */
@@ -803,28 +851,8 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
break;
}
 
-   /* configure clock with 96Mhz system clock.
-*/
-   if (mmc->clock != 0) {
-   dsor = (MMC_CLOCK_REFERENCE * 100 / mmc->clock);
-   if ((MMC_CLOCK_REFERENCE * 100) / dsor > mmc->clock)
-   dsor++;
-   }
-
-   mmc_reg_out(_base->sysctl, (ICE_MASK | DTO_MASK | CEN_MASK),
-   (ICE_STOP | DTO_15THDTO));
-
-   mmc_reg_out(_base->sysctl, ICE_MASK | CLKD_MASK,
-   (dsor << CLKD_OFFSET) | ICE_OSCILLATE);
-
-   start = get_timer(0);
-   while ((readl(_base->sysctl) & ICS_MASK) == ICS_NOTREADY) {
-   if (get_timer(0) - start > MAX_RETRY_MS) {
-   printf("%s: timedout waiting for ics!\n", __func__);
-   return -ETIMEDOUT;
-   }
-   }
-   writel(readl(_base->sysctl) | CEN_ENABLE, 

[U-Boot] [PATCH v3 05/24] mmc: omap_hsmmc: Enable DDR mode support

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

In order to enable DDR mode, Dual Data Rate mode bit has to be set in
MMCHS_CON register. Set it here.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 arch/arm/include/asm/omap_mmc.h | 1 +
 drivers/mmc/omap_hsmmc.c| 5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index 507435a..6aca9e9 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -89,6 +89,7 @@ struct omap_hsmmc_plat {
 #define WPP_ACTIVEHIGH (0x0 << 8)
 #define RESERVED_MASK  (0x3 << 9)
 #define CTPL_MMC_SD(0x0 << 11)
+#define DDR(0x1 << 19)
 #define DMA_MASTER (0x1 << 20)
 #define BLEN_512BYTESLEN   (0x200 << 0)
 #define NBLK_STPCNT(0x0 << 16)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index c6b74a1..2f4909e 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -271,6 +271,11 @@ static void omap_hsmmc_set_timing(struct mmc *mmc)
val &= ~AC12_UHSMC_MASK;
priv->mode = mmc->selected_mode;
 
+   if (mmc_is_mode_ddr(priv->mode))
+   writel(readl(_base->con) | DDR, _base->con);
+   else
+   writel(readl(_base->con) & ~DDR, _base->con);
+
switch (priv->mode) {
case MMC_HS_200:
case UHS_SDR104:
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3 02/24] mmc: omap_hsmmc: cleanup omap_hsmmc_set_ios

2018-01-30 Thread Jean-Jacques Hiblot
From: Kishon Vijay Abraham I 

No functional change. Move bus width configuration setting to a
separate function and invoke it only if there is a change in the
bus width.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v3: None

 drivers/mmc/omap_hsmmc.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index fa8681a..713faab 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -62,6 +62,7 @@ struct omap_hsmmc_data {
 #if !CONFIG_IS_ENABLED(DM_MMC)
struct mmc_config cfg;
 #endif
+   uint bus_width;
uint clock;
 #ifdef OMAP_HSMMC_USE_GPIO
 #if CONFIG_IS_ENABLED(DM_MMC)
@@ -814,17 +815,9 @@ static void omap_hsmmc_set_clock(struct mmc *mmc)
omap_hsmmc_start_clock(mmc_base);
 }
 
-#if !CONFIG_IS_ENABLED(DM_MMC)
-static int omap_hsmmc_set_ios(struct mmc *mmc)
+static void omap_hsmmc_set_bus_width(struct mmc *mmc)
 {
struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
-#else
-static int omap_hsmmc_set_ios(struct udevice *dev)
-{
-   struct omap_hsmmc_data *priv = dev_get_priv(dev);
-   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
-   struct mmc *mmc = upriv->mmc;
-#endif
struct hsmmc *mmc_base;
 
mmc_base = priv->base_addr;
@@ -851,6 +844,24 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
break;
}
 
+   priv->bus_width = mmc->bus_width;
+}
+
+#if !CONFIG_IS_ENABLED(DM_MMC)
+static int omap_hsmmc_set_ios(struct mmc *mmc)
+{
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+#else
+static int omap_hsmmc_set_ios(struct udevice *dev)
+{
+   struct omap_hsmmc_data *priv = dev_get_priv(dev);
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct mmc *mmc = upriv->mmc;
+#endif
+
+   if (priv->bus_width != mmc->bus_width)
+   omap_hsmmc_set_bus_width(mmc);
+
if (priv->clock != mmc->clock)
omap_hsmmc_set_clock(mmc);
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: kconfig: Remove meaningless 'select n'

2018-01-30 Thread Bin Meng
On Tue, Jan 30, 2018 at 9:04 PM, Bin Meng  wrote:
> On Tue, Jan 30, 2018 at 8:59 PM, Ulf Magnusson  wrote:
>> 'select n' selects a constant symbol, which is meaningless and has no
>> effect. Maybe this was meant to be a 'default n', though bool and
>> tristate symbols already implicitly default to n.
>>
>> Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
>> which does more strict checking here:
>>
>> kconfiglib.KconfigSyntaxError: board/google/Kconfig:34: Couldn't 
>> parse 'select n': expected nonconstant symbol
>>
>> Signed-off-by: Ulf Magnusson 
>> ---
>>  board/google/Kconfig | 1 -
>>  1 file changed, 1 deletion(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] x86: qemu: qfw: Implement acpi_get_rsdp_addr()

2018-01-30 Thread Bin Meng
On Tue, Jan 30, 2018 at 9:05 PM, Andy Shevchenko
 wrote:
> On Tue, 2018-01-30 at 05:01 -0800, Bin Meng wrote:
>> U-Boot on QEMU does not build ACPI table by ourself, instead it uses
>> the prebuilt ACPI table via the qfw interface. This implements the
>> qfw version of acpi_get_rsdp_addr() for setup_zimage().
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  drivers/misc/qfw.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
>> index a8af9e0..9a54803 100644
>> --- a/drivers/misc/qfw.c
>> +++ b/drivers/misc/qfw.c
>> @@ -222,6 +222,14 @@ out:
>>   free(table_loader);
>>   return addr;
>>  }
>> +
>> +ulong acpi_get_rsdp_addr(void)
>> +{
>> + struct fw_file *file;
>> +
>> + file = qemu_fwcfg_find_file("etc/acpi/rsdp");
>> + return file->addr;
>> +}
>>  #endif
>>
>>  /* Read configuration item using fw_cfg PIO interface */
>
>
> For both, FWIW:
>
> Reviewed-by: Andy Shevchenko 
>
> Thanks for taking care!
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] x86: acpi: Use an API to get the ACPI RSDP table address

2018-01-30 Thread Bin Meng
On Tue, Jan 30, 2018 at 9:01 PM, Bin Meng  wrote:
> At present the acpi_rsdp_addr variable is directly referenced in
> setup_zimage(). This changes to use an API for better encapsulation
> and extension.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/include/asm/acpi_table.h |  9 +
>  arch/x86/lib/acpi_table.c |  7 ++-
>  arch/x86/lib/acpi_table.h | 10 --
>  arch/x86/lib/zimage.c |  4 ++--
>  4 files changed, 17 insertions(+), 13 deletions(-)
>  delete mode 100644 arch/x86/lib/acpi_table.h
>

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Please pull u-boot-x86

2018-01-30 Thread Bin Meng
Hi Tom,

The following changes since commit eef11acebaa48e241e9187c717dc92d3e175c119:

  Prepare v2018.03-rc1 (2018-01-29 20:12:33 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-x86.git

for you to fetch changes up to e21b04fec465c84a51ca6fc6450263e0c0953fcb:

  x86: kconfig: Remove meaningless 'select n' (2018-01-30 22:34:38 +0800)


Andy Shevchenko (4):
  x86: tangier: Make _CRS for BTH0 Serialized to avoid warning
  x86: Fix reference to QEMU variant of write_acpi_tables()
  x86: zImage: Move subarch assignment out of cmd_line check
  x86: zImage: Propagate acpi_rsdp_addr to kernel via boot parameters

Bin Meng (2):
  x86: acpi: Use an API to get the ACPI RSDP table address
  x86: qemu: qfw: Implement acpi_get_rsdp_addr()

Heinrich Schuchardt (2):
  configs: x86: allow to override CONFIG_BOOTCOMMAND
  cmd/bdinfo: print relocation info on X86

Tom Rini (1):
  x86: quark: Fix unused warnings

Ulf Magnusson (1):
  x86: kconfig: Remove meaningless 'select n'

 arch/x86/cpu/quark/smc.c| 13 -
 arch/x86/include/asm/acpi_table.h   |  9 +
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl |  2 +-
 arch/x86/include/asm/bootparam.h|  1 +
 arch/x86/lib/acpi_table.c   | 12 ++--
 arch/x86/lib/zimage.c   | 15 +++
 board/google/Kconfig|  1 -
 cmd/bdinfo.c|  2 ++
 drivers/misc/qfw.c  |  8 
 include/configs/x86-common.h|  2 ++
 10 files changed, 48 insertions(+), 17 deletions(-)

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] armv8: ls1088aqds: Add IFC-NOR as boot source for LS1088

2018-01-30 Thread Ashish Kumar


-Original Message-
From: York Sun 
Sent: Tuesday, January 30, 2018 2:54 AM
To: Ashish Kumar ; u-boot@lists.denx.de
Subject: Re: [PATCH] armv8: ls1088aqds: Add IFC-NOR as boot source for LS1088

On 01/01/2018 09:24 PM, Ashish Kumar wrote:
> IFC-NOR and QSPI-NOR pins are muxed on SoC,so they cannot be accessed 
> simultaneously, but IFC-NOR can be accessed along with SD-BOOT.
> 
> ls1088aqds_sdcard_ifc_defconfig: is defconfig for SD as boot source 
> and IFC-NOR to be used as flash, this will be used to write IFC-NOR 
> image on IFC flash.
> QSPI and DSPI cannot be accessed in this defconfig.
> 
> IFC-NOR image is generated by ls1088aqds_defconfig.
> 
> Signed-off-by: Ashish Kumar 
> ---
> depends on: 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> chwork.ozlabs.org%2Fpatch%2F853615%2F=02%7C01%7Cyork.sun%40nxp.co
> m%7Cc53b3ec4db4d48e5130a08d551a1253d%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C636504674905515652=j2VD3l2%2BIb7iYk8yvn3TOrvT38pPT8A
> RRQjN0h%2FR5b0%3D=0
> 
> Tested on 2018.01-rc3
> 
> More accurate timing are used which where provided by validation team
> 
> to switch to IFC-NOR use command for qspi prompt:
> i2c mw 66 0x60 0x12; i2c mw 66 50 00;i2c mw 66 10 21



> diff --git a/include/configs/ls1088aqds.h 
> b/include/configs/ls1088aqds.h index 8fbf890..d5075c3 100644
> --- a/include/configs/ls1088aqds.h
> +++ b/include/configs/ls1088aqds.h
> @@ -27,7 +27,6 @@ unsigned long get_board_ddr_clk(void);
>  #define CONFIG_SYS_MMC_ENV_DEV   0
>  #define CONFIG_ENV_SIZE  0x2000
>  #else
> -#define CONFIG_ENV_IS_IN_FLASH
>  #define CONFIG_ENV_ADDR  (CONFIG_SYS_FLASH_BASE + 
> 0x30)
>  #define CONFIG_ENV_SECT_SIZE 0x2
>  #define CONFIG_ENV_SIZE  0x2
> @@ -41,8 +40,9 @@ unsigned long get_board_ddr_clk(void);
>  #define CONFIG_SYS_CLK_FREQ  1
>  #define CONFIG_DDR_CLK_FREQ  1
>  #else
> -#define CONFIG_SYS_CLK_FREQ  get_board_sys_clk()
> -#define CONFIG_DDR_CLK_FREQ  get_board_ddr_clk()
> +#define CONFIG_QIXIS_I2C_ACCESS
> +#define CONFIG_SYS_CLK_FREQ  1
> +#define CONFIG_DDR_CLK_FREQ  1

Are you sure you want to go down the path to hard-code clock speeds? You will 
lose the ability to change clocks. Besides, you have identical hard-coded value 
for both legs of the #if...#else..#endif.

I found that I was not able to access QIXIS_READ etc, so I had to revert to 
fixed values.


>  #endif
>  
>  #define COUNTER_FREQUENCY_REAL   (CONFIG_SYS_CLK_FREQ/4)
> @@ -87,16 +87,10 @@ unsigned long get_board_ddr_clk(void);
>   CSPR_MSEL_NOR   | \
>   CSPR_V)
>  #define CONFIG_SYS_NOR_CSOR  CSOR_NOR_ADM_SHIFT(12)
> -#define CONFIG_SYS_NOR_FTIM0 (FTIM0_NOR_TACSE(0x4) | \
> - FTIM0_NOR_TEADC(0x5) | \
> - FTIM0_NOR_TEAHC(0x5))
> -#define CONFIG_SYS_NOR_FTIM1 (FTIM1_NOR_TACO(0x35) | \
> - FTIM1_NOR_TRAD_NOR(0x1a) |\
> - FTIM1_NOR_TSEQRAD_NOR(0x13))
> -#define CONFIG_SYS_NOR_FTIM2 (FTIM2_NOR_TCS(0x4) | \
> - FTIM2_NOR_TCH(0x4) | \
> - FTIM2_NOR_TWPH(0x0E) | \
> - FTIM2_NOR_TWP(0x1c))
> +#define CONFIG_SYS_NOR_FTIM0 (0xc0201410)
> +#define CONFIG_SYS_NOR_FTIM1 (0x50009028)
> +#define CONFIG_SYS_NOR_FTIM2 (0x0820501c)
> +#define CONFIG_SYS_NOR_FTIM3 0x0400

This is bad coding! Please use macros. Please triple-check your timing.
I don't want to fix the timing again. See my commit for LS1046AQDS 1b7910a37c.

How do I find timing which are correct?, I borrowed the same from validation 
scripts used by validation team.
Should I use these "LS1046AQDS 1b7910a37c"

>  #define CONFIG_SYS_NOR_FTIM3 0x0400
>  #define CONFIG_SYS_IFC_CCR   0x0100
>  
> @@ -193,7 +187,7 @@ unsigned long get_board_ddr_clk(void);
>   | CSPR_MSEL_GPCM \
>   | CSPR_V)
>  
> -#define CONFIG_SYS_FPGA_AMASKIFC_AMASK(64*1024)
> +#define SYS_FPGA_AMASK   IFC_AMASK(64 * 1024)
>  #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
>  #define CONFIG_SYS_FPGA_CSOR CSOR_GPCM_ADM_SHIFT(0)
>  #else
> @@ -222,7 +216,7 @@ unsigned long get_board_ddr_clk(void);
>  #define CONFIG_SYS_CSPR2_EXT CONFIG_SYS_FPGA_CSPR_EXT
>  #define CONFIG_SYS_CSPR2 CONFIG_SYS_FPGA_CSPR
>  #define CONFIG_SYS_CSPR2_FINAL   SYS_FPGA_CSPR_FINAL
> -#define CONFIG_SYS_AMASK2CONFIG_SYS_FPGA_AMASK
> +#define CONFIG_SYS_AMASK2SYS_FPGA_AMASK
>  #define CONFIG_SYS_CSOR2 CONFIG_SYS_FPGA_CSOR
>  #define CONFIG_SYS_CS2_FTIM0 SYS_FPGA_CS_FTIM0
>  #define CONFIG_SYS_CS2_FTIM1 

Re: [U-Boot] [PATCH] arm64: zynqmp: Fix misspelled choice default

2018-01-30 Thread Ulf Magnusson
On Tue, Jan 30, 2018 at 2:58 PM, Michal Simek  wrote:
> On 30.1.2018 14:38, Ulf Magnusson wrote:
>> On Tue, Jan 30, 2018 at 2:25 PM, Michal Simek  
>> wrote:
>>> On 30.1.2018 14:02, Ulf Magnusson wrote:
 There is no JTAG symbol in the "Boot mode" choice. JTAG_MODE was
 probably intended.

 No functional changes. Kconfig choices fall back on using the first
 (visible) symbol in the choice as the default if the default symbol is
 not visible.

 Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
 which prints the following warning:

   warning: the default selection JTAG (undefined) of  (defined 
 at arch/arm/cpu/armv8/zynqmp/Kconfig:107) is not contained in the choice

 I've added a corresponding warning to the C tools too, which is
 currently in linux-next: https://patchwork.kernel.org/patch/9983667/

 Signed-off-by: Ulf Magnusson 
 ---
  arch/arm/cpu/armv8/zynqmp/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
 b/arch/arm/cpu/armv8/zynqmp/Kconfig
 index 3f922b4097..56b7846f63 100644
 --- a/arch/arm/cpu/armv8/zynqmp/Kconfig
 +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
 @@ -107,7 +107,7 @@ config SPL_ZYNQMP_ALT_BOOTMODE
  choice
   prompt "Boot mode"
   depends on SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
 - default JTAG
 + default JTAG_MODE

  config JTAG_MODE
   bool "JTAG_MODE"

>>>
>>> Applied. How to run this tool inside u-boot?
>>>
>>> Thanks,
>>> Michal
>>
>> Thanks.
>>
>> The following should work, in the U-Boot root:
>>
>> $ pip install kconfiglib
>> $ UBOOTVERSION=2018.03-rc1 python
>> >>> import kconfiglib
>> >>> kconf = kconfiglib.Kconfig()
>
> Nice.
>
>>
>> That will parse the Kconfig files (and generate any parsing-related
>> errors and warnings). See the documentation for what functionality is
>> available.
>>
>> I just set the UBOOTVERSION environment variable to avoid a warning,
>> since it's referenced inside the Kconfig files (ordinarily it would be
>> exported from the makefiles). Not sure what actually depends on it.
>>
>> There's already an old version of Kconfiglib that's used by
>> tools/genboardscfg.py and some other scripts in U-Boot by the way. If
>> that one ever starts to feel slow, Kconfiglib 2 should be faster
>> (though it would require updating genboardscfg.py to the new API).
>
> I see this as the part of buildman and I use this tool quite often but
> have never seen this zynqmp error.
> I see it as part of genboardscfg and moveconfig but not buildman.
>
> Thanks,
> Michal
>

The warning is new in both Kconfiglib and the C tools (only in
linux-next currently), so it won't get generated by anything in U-Boot
at the moment.

Cheers,
Ulf
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm64: zynqmp: Fix misspelled choice default

2018-01-30 Thread Michal Simek
On 30.1.2018 14:38, Ulf Magnusson wrote:
> On Tue, Jan 30, 2018 at 2:25 PM, Michal Simek  wrote:
>> On 30.1.2018 14:02, Ulf Magnusson wrote:
>>> There is no JTAG symbol in the "Boot mode" choice. JTAG_MODE was
>>> probably intended.
>>>
>>> No functional changes. Kconfig choices fall back on using the first
>>> (visible) symbol in the choice as the default if the default symbol is
>>> not visible.
>>>
>>> Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
>>> which prints the following warning:
>>>
>>>   warning: the default selection JTAG (undefined) of  (defined 
>>> at arch/arm/cpu/armv8/zynqmp/Kconfig:107) is not contained in the choice
>>>
>>> I've added a corresponding warning to the C tools too, which is
>>> currently in linux-next: https://patchwork.kernel.org/patch/9983667/
>>>
>>> Signed-off-by: Ulf Magnusson 
>>> ---
>>>  arch/arm/cpu/armv8/zynqmp/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
>>> b/arch/arm/cpu/armv8/zynqmp/Kconfig
>>> index 3f922b4097..56b7846f63 100644
>>> --- a/arch/arm/cpu/armv8/zynqmp/Kconfig
>>> +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
>>> @@ -107,7 +107,7 @@ config SPL_ZYNQMP_ALT_BOOTMODE
>>>  choice
>>>   prompt "Boot mode"
>>>   depends on SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
>>> - default JTAG
>>> + default JTAG_MODE
>>>
>>>  config JTAG_MODE
>>>   bool "JTAG_MODE"
>>>
>>
>> Applied. How to run this tool inside u-boot?
>>
>> Thanks,
>> Michal
> 
> Thanks.
> 
> The following should work, in the U-Boot root:
> 
> $ pip install kconfiglib
> $ UBOOTVERSION=2018.03-rc1 python
> >>> import kconfiglib
> >>> kconf = kconfiglib.Kconfig()

Nice.

> 
> That will parse the Kconfig files (and generate any parsing-related
> errors and warnings). See the documentation for what functionality is
> available.
> 
> I just set the UBOOTVERSION environment variable to avoid a warning,
> since it's referenced inside the Kconfig files (ordinarily it would be
> exported from the makefiles). Not sure what actually depends on it.
> 
> There's already an old version of Kconfiglib that's used by
> tools/genboardscfg.py and some other scripts in U-Boot by the way. If
> that one ever starts to feel slow, Kconfiglib 2 should be faster
> (though it would require updating genboardscfg.py to the new API).

I see this as the part of buildman and I use this tool quite often but
have never seen this zynqmp error.
I see it as part of genboardscfg and moveconfig but not buildman.

Thanks,
Michal

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm64: zynqmp: Fix misspelled choice default

2018-01-30 Thread Ulf Magnusson
On Tue, Jan 30, 2018 at 2:38 PM, Ulf Magnusson  wrote:
> On Tue, Jan 30, 2018 at 2:25 PM, Michal Simek  wrote:
>> On 30.1.2018 14:02, Ulf Magnusson wrote:
>>> There is no JTAG symbol in the "Boot mode" choice. JTAG_MODE was
>>> probably intended.
>>>
>>> No functional changes. Kconfig choices fall back on using the first
>>> (visible) symbol in the choice as the default if the default symbol is
>>> not visible.
>>>
>>> Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
>>> which prints the following warning:
>>>
>>>   warning: the default selection JTAG (undefined) of  (defined 
>>> at arch/arm/cpu/armv8/zynqmp/Kconfig:107) is not contained in the choice
>>>
>>> I've added a corresponding warning to the C tools too, which is
>>> currently in linux-next: https://patchwork.kernel.org/patch/9983667/
>>>
>>> Signed-off-by: Ulf Magnusson 
>>> ---
>>>  arch/arm/cpu/armv8/zynqmp/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
>>> b/arch/arm/cpu/armv8/zynqmp/Kconfig
>>> index 3f922b4097..56b7846f63 100644
>>> --- a/arch/arm/cpu/armv8/zynqmp/Kconfig
>>> +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
>>> @@ -107,7 +107,7 @@ config SPL_ZYNQMP_ALT_BOOTMODE
>>>  choice
>>>   prompt "Boot mode"
>>>   depends on SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
>>> - default JTAG
>>> + default JTAG_MODE
>>>
>>>  config JTAG_MODE
>>>   bool "JTAG_MODE"
>>>
>>
>> Applied. How to run this tool inside u-boot?
>>
>> Thanks,
>> Michal
>
> Thanks.
>
> The following should work, in the U-Boot root:
>
> $ pip install kconfiglib
> $ UBOOTVERSION=2018.03-rc1 python
> >>> import kconfiglib
> >>> kconf = kconfiglib.Kconfig()
>
> That will parse the Kconfig files (and generate any parsing-related
> errors and warnings). See the documentation for what functionality is
> available.
>
> I just set the UBOOTVERSION environment variable to avoid a warning,
> since it's referenced inside the Kconfig files (ordinarily it would be
> exported from the makefiles). Not sure what actually depends on it.
>
> There's already an old version of Kconfiglib that's used by
> tools/genboardscfg.py and some other scripts in U-Boot by the way. If
> that one ever starts to feel slow, Kconfiglib 2 should be faster
> (though it would require updating genboardscfg.py to the new API).
>
> Cheers,
> Ulf

Looks like this will work as well:

$ UBOOTVERSION=`make ubootversion` python

Cheers,
Ulf
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 04/24] mmc: omap_hsmmc: set MMC mode in the UHSMS bit field

2018-01-30 Thread Jean-Jacques Hiblot

Hi Jaehoon,


On 29/01/2018 05:33, Jaehoon Chung wrote:

Hi,

On 01/25/2018 07:51 PM, Jean-Jacques Hiblot wrote:

From: Kishon Vijay Abraham I 

Use the timing parameter set in the MMC core to set the
mode in UHSMS  bit field. This is in preparation for
adding HS200 support in omap hsmmc driver.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Jean-Jacques Hiblot 
---

  arch/arm/include/asm/omap_mmc.h | 12 ++-
  drivers/mmc/omap_hsmmc.c| 47 +
  2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index c4d326d..3f94f2e 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -53,7 +53,8 @@ struct hsmmc {
unsigned int sysctl;/* 0x12C */
unsigned int stat;  /* 0x130 */
unsigned int ie;/* 0x134 */
-   unsigned char res4[0x8];
+   unsigned char res4[0x4];
+   unsigned int ac12;  /* 0x13C */
unsigned int capa;  /* 0x140 */
unsigned char res5[0x10];
unsigned int admaes;/* 0x154 */
@@ -170,6 +171,15 @@ struct omap_hsmmc_plat {
  #define IOV_3V0   300
  #define IOV_1V8   180
  
+#define AC12_ET(1 << 22)

+#define AC12_UHSMC_MASK(7 << 16)
+#define AC12_UHSMC_DDR50   (4 << 16)
+#define AC12_UHSMC_SDR104  (3 << 16)
+#define AC12_UHSMC_SDR50   (2 << 16)
+#define AC12_UHSMC_SDR25   (1 << 16)
+#define AC12_UHSMC_SDR12   (0 << 16)
+#define AC12_UHSMC_RES (0x7 << 16)

Using the BIT macro. (from checkpatch)
BIT() could be used only for AC12_ET and AC12_UHSMC_SDR25. I didn't use 
it to be consistent with the rest of the definitions.


JJ



+
  /* Driver definitions */
  #define MMCSD_SECTOR_SIZE 512
  #define MMC_CARD  0
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index a6a0df6..a65005f 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -76,6 +76,7 @@ struct omap_hsmmc_data {
  #endif
  #if CONFIG_IS_ENABLED(DM_MMC)
uint iov;
+   enum bus_mode mode;
  #endif
u8 controller_flags;
  #ifndef CONFIG_OMAP34XX
@@ -258,6 +259,48 @@ void mmc_init_stream(struct hsmmc *mmc_base)
  }
  
  #if CONFIG_IS_ENABLED(DM_MMC)

+static void omap_hsmmc_set_timing(struct mmc *mmc)
+{
+   u32 val;
+   struct hsmmc *mmc_base;
+   struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
+
+   mmc_base = priv->base_addr;
+
+   val = readl(_base->ac12);
+   val &= ~AC12_UHSMC_MASK;
+   priv->mode = mmc->selected_mode;
+
+   switch (priv->mode) {
+   case MMC_HS_200:
+   case UHS_SDR104:
+   val |= AC12_UHSMC_SDR104;
+   break;
+   case UHS_SDR50:
+   val |= AC12_UHSMC_SDR50;
+   break;
+   case MMC_DDR_52:
+   case UHS_DDR50:
+   val |= AC12_UHSMC_DDR50;
+   break;
+   case SD_HS:
+   case MMC_HS_52:
+   case UHS_SDR25:
+   val |= AC12_UHSMC_SDR25;
+   break;
+   case MMC_LEGACY:
+   case MMC_HS:
+   case SD_LEGACY:
+   case UHS_SDR12:
+   val |= AC12_UHSMC_SDR12;
+   break;
+   default:
+   val |= AC12_UHSMC_RES;
+   break;
+   }
+   writel(val, _base->ac12);
+}
+
  static void omap_hsmmc_conf_bus_power(struct mmc *mmc)
  {
struct hsmmc *mmc_base;
@@ -926,6 +969,10 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
if (priv->clock != mmc->clock)
omap_hsmmc_set_clock(mmc);
  
+#if CONFIG_IS_ENABLED(DM_MMC)

+   if (priv->mode != mmc->selected_mode)
+   omap_hsmmc_set_timing(mmc);
+#endif
return 0;
  }
  





___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm64: zynqmp: Fix misspelled choice default

2018-01-30 Thread Ulf Magnusson
On Tue, Jan 30, 2018 at 2:25 PM, Michal Simek  wrote:
> On 30.1.2018 14:02, Ulf Magnusson wrote:
>> There is no JTAG symbol in the "Boot mode" choice. JTAG_MODE was
>> probably intended.
>>
>> No functional changes. Kconfig choices fall back on using the first
>> (visible) symbol in the choice as the default if the default symbol is
>> not visible.
>>
>> Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
>> which prints the following warning:
>>
>>   warning: the default selection JTAG (undefined) of  (defined 
>> at arch/arm/cpu/armv8/zynqmp/Kconfig:107) is not contained in the choice
>>
>> I've added a corresponding warning to the C tools too, which is
>> currently in linux-next: https://patchwork.kernel.org/patch/9983667/
>>
>> Signed-off-by: Ulf Magnusson 
>> ---
>>  arch/arm/cpu/armv8/zynqmp/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
>> b/arch/arm/cpu/armv8/zynqmp/Kconfig
>> index 3f922b4097..56b7846f63 100644
>> --- a/arch/arm/cpu/armv8/zynqmp/Kconfig
>> +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
>> @@ -107,7 +107,7 @@ config SPL_ZYNQMP_ALT_BOOTMODE
>>  choice
>>   prompt "Boot mode"
>>   depends on SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
>> - default JTAG
>> + default JTAG_MODE
>>
>>  config JTAG_MODE
>>   bool "JTAG_MODE"
>>
>
> Applied. How to run this tool inside u-boot?
>
> Thanks,
> Michal

Thanks.

The following should work, in the U-Boot root:

$ pip install kconfiglib
$ UBOOTVERSION=2018.03-rc1 python
>>> import kconfiglib
>>> kconf = kconfiglib.Kconfig()

That will parse the Kconfig files (and generate any parsing-related
errors and warnings). See the documentation for what functionality is
available.

I just set the UBOOTVERSION environment variable to avoid a warning,
since it's referenced inside the Kconfig files (ordinarily it would be
exported from the makefiles). Not sure what actually depends on it.

There's already an old version of Kconfiglib that's used by
tools/genboardscfg.py and some other scripts in U-Boot by the way. If
that one ever starts to feel slow, Kconfiglib 2 should be faster
(though it would require updating genboardscfg.py to the new API).

Cheers,
Ulf
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] serial: Make full device search optional

2018-01-30 Thread Alexander Graf

On 01/30/2018 02:09 PM, Derald Woods wrote:
On Jan 30, 2018 3:17 AM, "Alexander Graf" > wrote:


On 01/30/2018 12:41 AM, Derald D. Woods wrote:

On Mon, Jan 29, 2018 at 07:46:09AM -0600, Derald Woods wrote:

On Jan 29, 2018 6:57 AM, "Alexander Graf" > wrote:

Commit 608b0c4ad4e5ec0c ("serial: Use next serial device
if probing fails")
added code to search for more serial devices if the
default one was not
probed correctly.

Unfortunately, that breaks omap3_evm. So while
investigating why that is
the case, let's disable the full search for everyone but
bcm283x where it
is needed.

Fixes: 608b0c4ad4e5ec0c ("serial: Use next serial device
if probing fails")
Reported-by: Derald D. Woods >
Signed-off-by: Alexander Graf >

---

Derald, could you please test this patch and verify it
does indeed unbreak
omap3_evm?

The omap3_evm boots now with this patch applied on master. If
I enable
SERIAL_SEARCH_ALL, it does not boot. I always build cleanly
using the
default config only. On failure, there is no console
input/output and
the board unresponsive.


So SPL is already broken? Can you try a known working SPL with
SERIAL_SEARCH_ALL=y U-Boot payload on top? Does that work?


I will give that path a try and see what I can discover. Again, it 
will be later today or tomorrow before I can get to this. This is why 
I asked what should the board code actually look like. As the 
omap3_evm is ahead of some other OMAP34XX boards currently, a good 
working example would be helpful. If omap3_evm becomes the example, 
let's make it a good one.


If you want to make it a good example, don't disable CONFIG_EFI_LOADER :).

But really, the only major difference I saw between beagle and evm was 
the fact that evm used DM in SPL. I patched that up locally (had to 
remove ext support as the binary became too big otherwise), but that 
didn't show the issue either. So we'll have to wait on your tests.



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 00/24] omap_hsmmc: Add support for HS200 and UHS modes

2018-01-30 Thread Jean-Jacques Hiblot

Hi Jaehoon,


On 30/01/2018 06:17, Jaehoon Chung wrote:

Hi JJ,

On 01/25/2018 07:51 PM, Jean-Jacques Hiblot wrote:

This series adds the missing bits to enable the UHS and HS200 modes
for the TI platforms.

Enabling support for high speed modes on omap5 requires implementing:
  * io signal voltage selection
  * tuning support
  * pin configuration (IO delays)

The few last patches enable the high speed modes for the DRA7 platforms and
also take care of disabling those modes in the dts for the platforms that
cannot support either the UHS or the HS200 because the voltage regulators
on board would not allow using those modes (not a SOC limitation).

could you fix the below errors?

I'll send a v3 shortly with the fix

JJ


arm:  +   omap3_logic

+drivers/mmc/omap_hsmmc.c: In function ?omap_hsmmc_send_cmd?:

+drivers/mmc/omap_hsmmc.c:1051:17: error: ?mmc? undeclared (first use in this 
function)

+  mmc_enable_irq(mmc, cmd);

+ ^~~

+drivers/mmc/omap_hsmmc.c:1051:17: note: each undeclared identifier is reported 
only once for each function it appears in

+make[3]: *** [drivers/mmc/omap_hsmmc.o] Error 1

+make[2]: *** [drivers/mmc] Error 2

+make[1]: *** [drivers] Error 2

+make: *** [sub-make] Error 2

arm:  +   am3517_evm

+drivers/mmc/omap_hsmmc.c: In function ?omap_hsmmc_send_cmd?:

+drivers/mmc/omap_hsmmc.c:1051:17: error: ?mmc? undeclared (first use in this 
function)

+  mmc_enable_irq(mmc, cmd);

+ ^~~

+drivers/mmc/omap_hsmmc.c:1051:17: note: each undeclared identifier is reported 
only once for each function it appears in

+make[3]: *** [drivers/mmc/omap_hsmmc.o] Error 1

+make[2]: *** [drivers/mmc] Error 2

+make[1]: *** [drivers] Error 2

+make: *** [sub-make] Error 2

2202 /24 igep0032

boards.cfg is up to date. Nothing to do.

Summary of current source for 24 boards (2 threads, 1 job per thread)

arm:  +   omap3_logic am3517_evm

+drivers/mmc/omap_hsmmc.c: In function ?omap_hsmmc_send_cmd?:

+drivers/mmc/omap_hsmmc.c:1051:17: error: ?mmc? undeclared (first use in this 
function)

+  mmc_enable_irq(mmc, cmd);


Best Regards,
Jaehoon Chung


With this in place we observe significant improvements in the performances:
on a DRA72 evm:
eMMC HS200: 124 MB/s
eMMC DDR52: 78 MB/s
sd   SDR104: 71 MB/s
sd   SDR50: 44 MB/s
For the record, the original performances were:
SD High speed: 18 MB/s
MMC High speed: 18 MB/s

This series has been tested on:
* DRA71-evm
* DRA72-evm
* DRA7x-evm
* DRA76-evm
* AM57x-evm
* Beaglebone Black (dt and non-dt)

changes since v1:
  - rebased on top of u-boot/master
  - enable the H200 and UHS support in the defconfigs of the DRA7 platforms



Jean-Jacques Hiblot (9):
   mmc: omap_hsmmc: Reduce the max timeout for reset controller fsm
   mmc: omap_hsmmc: allow the simple HS modes to use the default pinctrl
   mmc: omap_hsmmc: update mmc->clock with the actual bus speed
   mmc: omap_hsmmc: implement send_init_stream callback
   mmc: omap_hsmmc: add signal voltage selection support
   ARM: dts: dra7: Add supported MMC/SD modes in MMC dt nodes
   dts: am57xx-beagle-x15: disable UHS and HS200 support
   dts: am57xx-idk: disable HS200 support
   configs: dra7xx_evm/dra7xx_hs_evm: Enable MMC HS200 and SD UHS support

Kishon Vijay Abraham I (15):
   mmc: omap_hsmmc: cleanup clock configuration
   mmc: omap_hsmmc: cleanup omap_hsmmc_set_ios
   mmc: omap_hsmmc: add support to set default io voltage
   mmc: omap_hsmmc: set MMC mode in the UHSMS bit field
   mmc: omap_hsmmc: Enable DDR mode support
   mmc: omap_hsmmc: Add tuning support
   mmc: omap_hsmmc: Workaround for errata id i802
   mmc: omap_hsmmc: use mmc_of_parse to populate mmc_config
   ARM: OMAP5/DRA7: Enable iodelay recalibration to be done from uboot
   mmc: omap_hsmmc: Add support to set IODELAY values
   mmc: omap_hsmmc: Add support to get pinctrl values and max frequency
 for different hw revisions
   mmc: omap_hsmmc: allow mmc clock to be gated
   ARM: OMAP5: set mmc clock frequency to 192MHz
   ARM: dts: DRA7: use new dra7-specific compatible string
   ARM: DRA7x/AM57x: Add MMC/SD fixups for rev1.0 and rev 1.1

  arch/arm/dts/am57xx-beagle-x15.dts   |   6 +
  arch/arm/dts/am57xx-idk-common.dtsi  |   2 +
  arch/arm/dts/dra7.dtsi   |  22 +-
  arch/arm/include/asm/arch-omap5/clock.h  |   2 +-
  arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |   3 +
  arch/arm/include/asm/arch-omap5/sys_proto.h  |   7 +
  arch/arm/include/asm/omap_mmc.h  |  59 +-
  arch/arm/mach-omap2/omap5/dra7xx_iodelay.c   |  30 +
  arch/arm/mach-omap2/omap5/hw_data.c  |  10 +-
  board/ti/am57xx/board.c  |  30 +
  board/ti/dra7xx/evm.c|  29 +
  configs/dra7xx_evm_defconfig |   3 +
  configs/dra7xx_hs_evm_defconfig  |   3 +
  drivers/mmc/omap_hsmmc.c | 948 

Re: [U-Boot] [PATCH] arm64: zynqmp: Fix misspelled choice default

2018-01-30 Thread Michal Simek
On 30.1.2018 14:02, Ulf Magnusson wrote:
> There is no JTAG symbol in the "Boot mode" choice. JTAG_MODE was
> probably intended.
> 
> No functional changes. Kconfig choices fall back on using the first
> (visible) symbol in the choice as the default if the default symbol is
> not visible.
> 
> Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
> which prints the following warning:
> 
>   warning: the default selection JTAG (undefined) of  (defined at 
> arch/arm/cpu/armv8/zynqmp/Kconfig:107) is not contained in the choice
> 
> I've added a corresponding warning to the C tools too, which is
> currently in linux-next: https://patchwork.kernel.org/patch/9983667/
> 
> Signed-off-by: Ulf Magnusson 
> ---
>  arch/arm/cpu/armv8/zynqmp/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
> b/arch/arm/cpu/armv8/zynqmp/Kconfig
> index 3f922b4097..56b7846f63 100644
> --- a/arch/arm/cpu/armv8/zynqmp/Kconfig
> +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
> @@ -107,7 +107,7 @@ config SPL_ZYNQMP_ALT_BOOTMODE
>  choice
>   prompt "Boot mode"
>   depends on SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
> - default JTAG
> + default JTAG_MODE
>  
>  config JTAG_MODE
>   bool "JTAG_MODE"
> 

Applied. How to run this tool inside u-boot?

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] serial: Make full device search optional

2018-01-30 Thread Derald Woods
On Jan 30, 2018 3:17 AM, "Alexander Graf"  wrote:

On 01/30/2018 12:41 AM, Derald D. Woods wrote:

> On Mon, Jan 29, 2018 at 07:46:09AM -0600, Derald Woods wrote:
>
>> On Jan 29, 2018 6:57 AM, "Alexander Graf"  wrote:
>>
>> Commit 608b0c4ad4e5ec0c ("serial: Use next serial device if probing
>> fails")
>> added code to search for more serial devices if the default one was not
>> probed correctly.
>>
>> Unfortunately, that breaks omap3_evm. So while investigating why that is
>> the case, let's disable the full search for everyone but bcm283x where it
>> is needed.
>>
>> Fixes: 608b0c4ad4e5ec0c ("serial: Use next serial device if probing
>> fails")
>> Reported-by: Derald D. Woods 
>> Signed-off-by: Alexander Graf 
>>
>> ---
>>
>> Derald, could you please test this patch and verify it does indeed unbreak
>> omap3_evm?
>>
>> The omap3_evm boots now with this patch applied on master. If I enable
> SERIAL_SEARCH_ALL, it does not boot. I always build cleanly using the
> default config only. On failure, there is no console input/output and
> the board unresponsive.
>

So SPL is already broken? Can you try a known working SPL with
SERIAL_SEARCH_ALL=y U-Boot payload on top? Does that work?


I will give that path a try and see what I can discover. Again, it will be
later today or tomorrow before I can get to this. This is why I asked what
should the board code actually look like. As the omap3_evm is ahead of some
other OMAP34XX boards currently, a good working example would be helpful.
If omap3_evm becomes the example, let's make it a good one.

Derald
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] usb: ulpi: kconfig: Remove meaningless choice default

2018-01-30 Thread Ulf Magnusson
'default' on a choice refers to the symbol selected by default, not to
the choice mode, so 'default n' is meaningless.

No functional changes. Optional choices implicitly default to n mode
(and there is no way to make them default to another mode).

Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
which prints the following warning:

warning: the default selection n (undefined) of  (defined at 
drivers/usb/ulpi/Kconfig:3) is not contained in the choice

I've added a corresponding warning to the C tools too, which is
currently in linux-next: https://patchwork.kernel.org/patch/9983667/

Signed-off-by: Ulf Magnusson 
---
 drivers/usb/ulpi/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/ulpi/Kconfig b/drivers/usb/ulpi/Kconfig
index 329d2df3ed..001564d40c 100644
--- a/drivers/usb/ulpi/Kconfig
+++ b/drivers/usb/ulpi/Kconfig
@@ -3,7 +3,6 @@ comment "ULPI drivers"
 choice
prompt "ULPI Viewport type"
optional
-   default n
help
  Select ULPI viewport (SoC-side interface to ULPI) implementation
  appropriate for the device if you want to communicate with
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] x86: qemu: qfw: Implement acpi_get_rsdp_addr()

2018-01-30 Thread Andy Shevchenko
On Tue, 2018-01-30 at 05:01 -0800, Bin Meng wrote:
> U-Boot on QEMU does not build ACPI table by ourself, instead it uses
> the prebuilt ACPI table via the qfw interface. This implements the
> qfw version of acpi_get_rsdp_addr() for setup_zimage().
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/misc/qfw.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
> index a8af9e0..9a54803 100644
> --- a/drivers/misc/qfw.c
> +++ b/drivers/misc/qfw.c
> @@ -222,6 +222,14 @@ out:
>   free(table_loader);
>   return addr;
>  }
> +
> +ulong acpi_get_rsdp_addr(void)
> +{
> + struct fw_file *file;
> +
> + file = qemu_fwcfg_find_file("etc/acpi/rsdp");
> + return file->addr;
> +}
>  #endif
>  
>  /* Read configuration item using fw_cfg PIO interface */


For both, FWIW:

Reviewed-by: Andy Shevchenko 

Thanks for taking care!

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] am335x, shc: kconfig: Fix misspelled choice default

2018-01-30 Thread Ulf Magnusson
There is no EMMC symbol in the "enable different boot versions for the
shc board" choice. SHC_EMMC was probably intended.

No functional changes. Kconfig choices fall back on using the first
(visible) symbol in the choice as the default if the default symbol is
not visible.

Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
which prints the following warning:

warning: the default selection EMMC (undefined) of  (defined at 
board/bosch/shc/Kconfig:15) is not contained in the choice

I've added a corresponding warning to the C tools too, which is
currently in linux-next: https://patchwork.kernel.org/patch/9983667/

Signed-off-by: Ulf Magnusson 
---
 board/bosch/shc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/bosch/shc/Kconfig b/board/bosch/shc/Kconfig
index c71af11c1c..e0e56e6bfd 100644
--- a/board/bosch/shc/Kconfig
+++ b/board/bosch/shc/Kconfig
@@ -14,7 +14,7 @@ config SYS_CONFIG_NAME
 
 choice
prompt "enable different boot versions for the shc board"
-   default EMMC
+   default SHC_EMMC
help
  Select the boot version of the shc board.
 
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: kconfig: Remove meaningless 'select n'

2018-01-30 Thread Bin Meng
On Tue, Jan 30, 2018 at 8:59 PM, Ulf Magnusson  wrote:
> 'select n' selects a constant symbol, which is meaningless and has no
> effect. Maybe this was meant to be a 'default n', though bool and
> tristate symbols already implicitly default to n.
>
> Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
> which does more strict checking here:
>
> kconfiglib.KconfigSyntaxError: board/google/Kconfig:34: Couldn't 
> parse 'select n': expected nonconstant symbol
>
> Signed-off-by: Ulf Magnusson 
> ---
>  board/google/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] arm64: zynqmp: Fix misspelled choice default

2018-01-30 Thread Ulf Magnusson
There is no JTAG symbol in the "Boot mode" choice. JTAG_MODE was
probably intended.

No functional changes. Kconfig choices fall back on using the first
(visible) symbol in the choice as the default if the default symbol is
not visible.

Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
which prints the following warning:

warning: the default selection JTAG (undefined) of  (defined at 
arch/arm/cpu/armv8/zynqmp/Kconfig:107) is not contained in the choice

I've added a corresponding warning to the C tools too, which is
currently in linux-next: https://patchwork.kernel.org/patch/9983667/

Signed-off-by: Ulf Magnusson 
---
 arch/arm/cpu/armv8/zynqmp/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
b/arch/arm/cpu/armv8/zynqmp/Kconfig
index 3f922b4097..56b7846f63 100644
--- a/arch/arm/cpu/armv8/zynqmp/Kconfig
+++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
@@ -107,7 +107,7 @@ config SPL_ZYNQMP_ALT_BOOTMODE
 choice
prompt "Boot mode"
depends on SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
-   default JTAG
+   default JTAG_MODE
 
 config JTAG_MODE
bool "JTAG_MODE"
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] x86: kconfig: Remove meaningless 'select n'

2018-01-30 Thread Ulf Magnusson
'select n' selects a constant symbol, which is meaningless and has no
effect. Maybe this was meant to be a 'default n', though bool and
tristate symbols already implicitly default to n.

Discovered in Kconfiglib (https://github.com/ulfalizer/Kconfiglib),
which does more strict checking here:

kconfiglib.KconfigSyntaxError: board/google/Kconfig:34: Couldn't parse 
'select n': expected nonconstant symbol

Signed-off-by: Ulf Magnusson 
---
 board/google/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/board/google/Kconfig b/board/google/Kconfig
index e56c026ef6..766db1b449 100644
--- a/board/google/Kconfig
+++ b/board/google/Kconfig
@@ -31,7 +31,6 @@ config TARGET_CHROMEBOOK_LINK64
 
 config TARGET_CHROMEBOX_PANTHER
bool "Chromebox panther (not available)"
-   select n
help
  Note: At present this must be used with coreboot. See README.x86
  for instructions.
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/2] x86: qemu: qfw: Implement acpi_get_rsdp_addr()

2018-01-30 Thread Bin Meng
U-Boot on QEMU does not build ACPI table by ourself, instead it uses
the prebuilt ACPI table via the qfw interface. This implements the
qfw version of acpi_get_rsdp_addr() for setup_zimage().

Signed-off-by: Bin Meng 
---

 drivers/misc/qfw.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
index a8af9e0..9a54803 100644
--- a/drivers/misc/qfw.c
+++ b/drivers/misc/qfw.c
@@ -222,6 +222,14 @@ out:
free(table_loader);
return addr;
 }
+
+ulong acpi_get_rsdp_addr(void)
+{
+   struct fw_file *file;
+
+   file = qemu_fwcfg_find_file("etc/acpi/rsdp");
+   return file->addr;
+}
 #endif
 
 /* Read configuration item using fw_cfg PIO interface */
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/2] x86: acpi: Use an API to get the ACPI RSDP table address

2018-01-30 Thread Bin Meng
At present the acpi_rsdp_addr variable is directly referenced in
setup_zimage(). This changes to use an API for better encapsulation
and extension.

Signed-off-by: Bin Meng 
---

 arch/x86/include/asm/acpi_table.h |  9 +
 arch/x86/lib/acpi_table.c |  7 ++-
 arch/x86/lib/acpi_table.h | 10 --
 arch/x86/lib/zimage.c |  4 ++--
 4 files changed, 17 insertions(+), 13 deletions(-)
 delete mode 100644 arch/x86/lib/acpi_table.h

diff --git a/arch/x86/include/asm/acpi_table.h 
b/arch/x86/include/asm/acpi_table.h
index 8003850..d5d77cc 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -330,6 +330,15 @@ void enter_acpi_mode(int pm1_cnt);
 ulong write_acpi_tables(ulong start);
 
 /**
+ * acpi_get_rsdp_addr() - get ACPI RSDP table address
+ *
+ * This routine returns the ACPI RSDP table address in the system memory.
+ *
+ * @return:ACPI RSDP table address
+ */
+ulong acpi_get_rsdp_addr(void);
+
+/**
  * acpi_find_fadt() - find ACPI FADT table in the sytem memory
  *
  * This routine parses the ACPI table to locate the ACPI FADT table.
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index d3e5d2e..115a8e4 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -29,7 +29,7 @@
 extern const unsigned char AmlCode[];
 
 /* ACPI RSDP address to be used in boot parameters */
-unsigned long acpi_rsdp_addr;
+static ulong acpi_rsdp_addr;
 
 static void acpi_write_rsdp(struct acpi_rsdp *rsdp, struct acpi_rsdt *rsdt,
struct acpi_xsdt *xsdt)
@@ -480,6 +480,11 @@ ulong write_acpi_tables(ulong start)
return current;
 }
 
+ulong acpi_get_rsdp_addr(void)
+{
+   return acpi_rsdp_addr;
+}
+
 static struct acpi_rsdp *acpi_valid_rsdp(struct acpi_rsdp *rsdp)
 {
if (strncmp((char *)rsdp, RSDP_SIG, sizeof(RSDP_SIG) - 1) != 0)
diff --git a/arch/x86/lib/acpi_table.h b/arch/x86/lib/acpi_table.h
deleted file mode 100644
index cece5d1..000
--- a/arch/x86/lib/acpi_table.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/*
- * SPDX-License-Identifier:GPL-2.0
- */
-
-#ifndef _X86_LIB_ACPI_TABLES_H
-#define _X86_LIB_ACPI_TABLES_H
-
-extern unsigned long acpi_rsdp_addr;
-
-#endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index eae2663..2a82bc8 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -14,6 +14,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,7 +25,6 @@
 #include 
 #endif
 #include 
-#include "acpi_table.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -258,7 +258,7 @@ int setup_zimage(struct boot_params *setup_base, char 
*cmd_line, int auto_boot,
 
 #ifdef CONFIG_GENERATE_ACPI_TABLE
if (bootproto >= 0x020e)
-   hdr->acpi_rsdp_addr = acpi_rsdp_addr;
+   hdr->acpi_rsdp_addr = acpi_get_rsdp_addr();
 #endif
 
setup_video(_base->screen_info);
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1 2/2] x86: zImage: Propagate acpi_rsdp_addr to kernel via boot parameters

2018-01-30 Thread Bin Meng
On Mon, Jan 15, 2018 at 10:33 AM, Bin Meng  wrote:
> On Fri, Jan 12, 2018 at 9:01 PM, Andy Shevchenko
>  wrote:
>> On Fri, 2018-01-12 at 17:00 +0800, Bin Meng wrote:
>>> Hi Andy,
>>>
>>> On Thu, Jan 11, 2018 at 1:40 AM, Andy Shevchenko
>>>  wrote:
>>> > New field acpi_rsdp_addr, which has been introduced in boot protocol
>>> > v2.14 [1], in boot parameters tells kernel the exact address of RDSP
>>> > ACPI table. Knowing it increases robustness of the kernel by
>>> > avoiding
>>> > in some cases traversal through a part of physical memory.
>>> > It will slightly reduce boot time by the same reason.
>>> >
>>> > [1] See Linux kernel commit
>>> >
>>> >   2f74cbf947f4 ("x86/boot: Add the ACPI RSDP address to struct
>>> > setup_header::acpi_rdsp_addr")
>>>
>>> I don't see this commit id in my linux tree. Is this in some
>>> custodian's tree?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2
>> f74cbf947f45fa082dda8eac1a1f1299a372f49
>>
>
> thanks!
>
>>> > for the details.
>>> >
>>> > Signed-off-by: Andy Shevchenko 
>>> > ---
>>> >  arch/x86/include/asm/bootparam.h |  1 +
>>> >  arch/x86/lib/acpi_table.c|  7 +++
>>> >  arch/x86/lib/acpi_table.h| 10 ++
>>> >  arch/x86/lib/zimage.c|  6 ++
>>> >  4 files changed, 24 insertions(+)
>>> >  create mode 100644 arch/x86/lib/acpi_table.h
>>> >
>>> > diff --git a/arch/x86/include/asm/bootparam.h
>>> > b/arch/x86/include/asm/bootparam.h
>>> > index 48b138c6b0..90768a99ce 100644
>>> > --- a/arch/x86/include/asm/bootparam.h
>>> > +++ b/arch/x86/include/asm/bootparam.h
>>> > @@ -66,6 +66,7 @@ struct setup_header {
>>> > __u64   pref_address;
>>> > __u32   init_size;
>>> > __u32   handover_offset;
>>> > +   __u64   acpi_rsdp_addr;
>>> >  } __attribute__((packed));
>>> >
>>> >  struct sys_desc_table {
>>> > diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
>>> > index 7b33cd371e..45bfc111ef 100644
>>> > --- a/arch/x86/lib/acpi_table.c
>>> > +++ b/arch/x86/lib/acpi_table.c
>>> > @@ -20,6 +20,7 @@
>>> >  #include 
>>> >  #include 
>>> >  #include 
>>> > +#include "acpi_table.h"
>>> >
>>> >  /*
>>> >   * IASL compiles the dsdt entries and writes the hex values
>>> > @@ -27,6 +28,11 @@
>>> >   */
>>> >  extern const unsigned char AmlCode[];
>>> >
>>> > +/*
>>> > + * ACPI RSDP address to be used in boot parameters.
>>> > + */
>>>
>>> nits: use single line comment format without the ending .
>>
>> OK.
>>
>>>
>>> > +unsigned long acpi_rsdp_addr;
>>> > +
>>> >  static void acpi_write_rsdp(struct acpi_rsdp *rsdp, struct
>>> > acpi_rsdt *rsdt,
>>> > struct acpi_xsdt *xsdt)
>>> >  {
>>> > @@ -460,6 +466,7 @@ ulong write_acpi_tables(ulong start)
>>> >
>>> > debug("current = %x\n", current);
>>> >
>>> > +   acpi_rsdp_addr = (unsigned long)rsdp;
>>> > debug("ACPI: done\n");
>>> >
>>> > /* Don't touch ACPI hardware on HW reduced platforms */
>>> > diff --git a/arch/x86/lib/acpi_table.h b/arch/x86/lib/acpi_table.h
>>> > new file mode 100644
>>> > index 00..cece5d1420
>>> > --- /dev/null
>>> > +++ b/arch/x86/lib/acpi_table.h
>>> > @@ -0,0 +1,10 @@
>>> > +/*
>>> > + * SPDX-License-Identifier:GPL-2.0
>>> > + */
>>> > +
>>> > +#ifndef _X86_LIB_ACPI_TABLES_H
>>> > +#define _X86_LIB_ACPI_TABLES_H
>>> > +
>>> > +extern unsigned long acpi_rsdp_addr;
>>> > +
>>> > +#endif
>>> > diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
>>> > index d224db4e07..eae26635b1 100644
>>> > --- a/arch/x86/lib/zimage.c
>>> > +++ b/arch/x86/lib/zimage.c
>>> > @@ -24,6 +24,7 @@
>>> >  #include 
>>> >  #endif
>>> >  #include 
>>> > +#include "acpi_table.h"
>>> >
>>> >  DECLARE_GLOBAL_DATA_PTR;
>>> >
>>> > @@ -255,6 +256,11 @@ int setup_zimage(struct boot_params
>>> > *setup_base, char *cmd_line, int auto_boot,
>>> > hdr->hardware_subarch = X86_SUBARCH_INTEL_MID;
>>> >  #endif
>>> >
>>> > +#ifdef CONFIG_GENERATE_ACPI_TABLE
>>> > +   if (bootproto >= 0x020e)
>>> > +   hdr->acpi_rsdp_addr = acpi_rsdp_addr;
>>> > +#endif
>>> > +
>>> > setup_video(_base->screen_info);
>>> >
>>> > return 0;
>>> > --
>>>
>>> Other than the above nits,
>>> Reviewed-by: Bin Meng 
>>>
>>> I can fix the nits when applying if you like.
>>
>> If you have a chance to do it soon, please, do, otherwise I would send a
>> new version later (next week I suppose).
>
> Fixed the nits and mentioned the git commit URL
>
> applied to u-boot-x86, thanks!

This unfortunately breaks qemu-x86 and qemu-x86_64. I will post
patches to fix this.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v7 3/3] common: Generic firmware loader for file system

2018-01-30 Thread Marek Vasut
On 01/30/2018 12:16 PM, tien.fong.c...@intel.com 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 
> Reviewed-by: Lothar Waßmann 
> ---
>  common/Kconfig |   9 ++
>  common/Makefile|   1 +
>  common/fs_loader.c | 326 
> +
>  doc/README.firmware_loader |  76 +++
>  include/fs_loader.h|  28 
>  5 files changed, 440 insertions(+)
>  create mode 100644 common/fs_loader.c
>  create mode 100644 doc/README.firmware_loader
>  create mode 100644 include/fs_loader.h

[...]

> +#ifdef CONFIG_CMD_UBIFS
> +static int mount_ubifs(struct device_location *location)
> +{
> + int ret;
> + char cmd[32];
> +
> + snprintf(cmd, sizeof(location->mtdpart), "ubi part %s",
> +  location->mtdpart);
> +
> + ret = run_command(cmd, 0);

Can you call the UBI functions directly instead of invoking the U-Boot
command parser ?

> + if (ret)
> + return ret;
> +
> + snprintf(cmd, sizeof(location->ubivol), "ubifsmount %s",
> +  location->ubivol);
> +
> + ret = run_command(cmd, 0);

DTTO here ...

> + return ret;
> +}
> +
> +static int umount_ubifs(void)
> +{
> + return cmd_ubifs_umount();
> +}
> +#else
> +static int mount_ubifs(struct device_location *location)
> +{
> + debug("Error: Cannot load image: no UBIFS support\n");
> + return -ENOSYS;
> +}
> +#endif

[...]
-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v7 2/3] cmd: ubifs: Move ubifs_initialized checking into cmd_ubifs_umount()

2018-01-30 Thread Marek Vasut
On 01/30/2018 12:16 PM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> cmd_ubifs_umount() function would be called directly instead of involving
> whole command machinery in generic firmware loader, so checking on
> ubifs_initialized status need to be done in cmd_ubifs_umount() without
> breaking original functionality design.
> 
> Signed-off-by: Tien Fong Chee 
> 64db5518baa2ea1a8a0e81cc485d760b850c7052
> ---
>  cmd/ubifs.c | 20 
>  include/ubi_uboot.h |  1 +
>  2 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/cmd/ubifs.c b/cmd/ubifs.c
> index 5e9d357..d18e0da 100644
> --- a/cmd/ubifs.c
> +++ b/cmd/ubifs.c
> @@ -51,27 +51,31 @@ int ubifs_is_mounted(void)
>   return ubifs_mounted;
>  }
>  
> -void cmd_ubifs_umount(void)
> +int cmd_ubifs_umount(void)
>  {
> + if (ubifs_initialized == 0) {
> + printf("No UBIFS volume mounted!\n");
> + return -1;
> + }
> +
>   uboot_ubifs_umount();
>   ubifs_mounted = 0;
>   ubifs_initialized = 0;
> +
> + return 0;
>  }
>  
>  static int do_ubifs_umount(cmd_tbl_t *cmdtp, int flag, int argc,
>   char * const argv[])
>  {
> + int ret;
> +
>   if (argc != 1)
>   return CMD_RET_USAGE;
>  
> - if (ubifs_initialized == 0) {
> - printf("No UBIFS volume mounted!\n");
> - return -1;
> - }
> -
> - cmd_ubifs_umount();
> + ret = cmd_ubifs_umount();

return cmd_ubifs_umount() directly ?

> - return 0;
> + return ret;
>  }
>  
>  static int do_ubifs_ls(cmd_tbl_t *cmdtp, int flag, int argc,
> diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
> index 80acbcb..827dbfc 100644
> --- a/include/ubi_uboot.h
> +++ b/include/ubi_uboot.h
> @@ -75,5 +75,6 @@ extern int ubi_volume_write(char *volume, void *buf, size_t 
> size);
>  extern int ubi_volume_read(char *volume, char *buf, size_t size);
>  
>  extern struct ubi_device *ubi_devices[];
> +int cmd_ubifs_umount(void);
>  
>  #endif
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] fdt: Fixup only valid memory banks

2018-01-30 Thread Thierry Reding
On Tue, Jan 30, 2018 at 12:41:15PM +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Tue, 30 Jan 2018 11:34:17 +0100 Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > Memory banks with address 0 and size 0 are empty and should not be
> > passed to the OS via device tree.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  common/fdt_support.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/common/fdt_support.c b/common/fdt_support.c
> > index 724452d75452..8b33f6773d27 100644
> > --- a/common/fdt_support.c
> > +++ b/common/fdt_support.c
> > @@ -457,7 +457,7 @@ int fdt_record_loadable(void *blob, u32 index, const 
> > char *name,
> >  int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
> >  {
> > int err, nodeoffset;
> > -   int len;
> > +   int len, i;
> > u8 tmp[MEMORY_BANKS_MAX * 16]; /* Up to 64-bit address + 64-bit size */
> >  
> > if (banks > MEMORY_BANKS_MAX) {
> > @@ -489,6 +489,12 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], 
> > u64 size[], int banks)
> > if (!banks)
> > return 0;
> >  
> > +   for (i = 0; i < banks; i++)
> > +   if (start[i] == 0 && size[i] == 0)
> > +   break;
> > +
> > +   banks = i;
> > +
> > len = fdt_pack_reg(blob, tmp, start, size, banks);
> >  
> > err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);
> >
> Does an empty bank always imply the end of the list, or
> Is it a valid scenario to have intervening empty banks?

I think it's a fair assumption that there aren't going to be any holes.
The vast majority of boards will only every initialize a single bank or
perhaps two. There's a few odd ones (hisilicon/hikey for example) that
adds more, but they are still all contiguous.

Thierry


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] fdt: Fixup only valid memory banks

2018-01-30 Thread Lothar Waßmann
Hi,

On Tue, 30 Jan 2018 11:34:17 +0100 Thierry Reding wrote:
> From: Thierry Reding 
> 
> Memory banks with address 0 and size 0 are empty and should not be
> passed to the OS via device tree.
> 
> Signed-off-by: Thierry Reding 
> ---
>  common/fdt_support.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 724452d75452..8b33f6773d27 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -457,7 +457,7 @@ int fdt_record_loadable(void *blob, u32 index, const char 
> *name,
>  int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
>  {
>   int err, nodeoffset;
> - int len;
> + int len, i;
>   u8 tmp[MEMORY_BANKS_MAX * 16]; /* Up to 64-bit address + 64-bit size */
>  
>   if (banks > MEMORY_BANKS_MAX) {
> @@ -489,6 +489,12 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64 
> size[], int banks)
>   if (!banks)
>   return 0;
>  
> + for (i = 0; i < banks; i++)
> + if (start[i] == 0 && size[i] == 0)
> + break;
> +
> + banks = i;
> +
>   len = fdt_pack_reg(blob, tmp, start, size, banks);
>  
>   err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);
>
Does an empty bank always imply the end of the list, or
Is it a valid scenario to have intervening empty banks?


Lothar Waßmann
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Uboot as x86_64 EFI payload

2018-01-30 Thread Javier Santos Romo
FYI


[cid:image001.gif@01D39927.A0D208D0]

Javier Santos Romo
Ingeniero de Telecomunicaciones /
Telecommunications Engineer /

GMV
Juan de Herrera nº17
Boecillo
E-47151 Valladolid
Tel. +34 983 54 65 54
Fax +34 983 54 65 53
www.gmv.com 
[cid:image002.png@01D39927.A0D208D0]

[cid:image003.png@01D39927.A0D208D0]

[cid:image004.png@01D39927.A0D208D0]

[cid:image005.png@01D39927.A0D208D0]

[cid:image006.png@01D39927.A0D208D0]

[cid:image007.png@01D39927.A0D208D0]


[cid:image008.png@01D39927.A0D208D0]




De: Juan Alfonso Reyes Ajenjo
Enviado el: lunes, 29 de enero de 2018 16:18
Para: u-boot@lists.denx.de
CC: Javier Santos Romo 
Asunto: Uboot as x86_64 EFI payload

Hi,
I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are 
developing new boards based in Apollo Lake CPU.  We are trying to load uboot 
from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting 
"U-Boot EFI Payload 2002 No memory map" error code.
As I can see in the code 2002 means (efi_stub.c):

ret = boot->get_memory_map(, NULL, , _size, );
if (ret != EFI_BUFFER_TOO_SMALL) {
printhex2(BITS_PER_LONG);
printhex2(ret);
puts(" No memory map\n");
while(1);
return ret;
}

0x20   -> BITS_PER_LONG 32bits
0x02 -> EFI_INVALID_PARAMETER

32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT 
instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation 
error:

In file included from include/common.h:53:0,
 from cmd/efi.c:8:
cmd/efi.c: In function 'do_efi_mem':
./arch/x86/include/asm/global_data.h:117:12: error: 'global_data_ptr' 
undeclared (first use in this function)
#define gd global_data_ptr


I have surfed in the code and I have found this in 
./arch/x86/include/asm/global_data.h

# if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
/* TODO(s...@chromium.org): Consider using a fixed 
register for gd on x86_64 */
#define gd global_data_ptr

What do you mean with "Consider using a fixed register for gd" ?Can you help us 
to make this work? Are we in the correct direction?

Thank you very much,

Best regards,

[cid:image001.gif@01D39927.A0D208D0]

Juan Alfonso Reyes Ajenjo
Ingeniero en Informatica / Computer Systems Engineer
Ingeniero en Automática y Electrónica Industrial / Automation and Industrial 
Electronics Engineer

GMV
Juan de Herrera nº17
Boecillo
E-47151 Valladolid
Tel. +34 983 54 65 54
Fax +34 983 54 65 53
www.gmv.com 
[cid:image002.png@01D39927.A0D208D0]

[cid:image003.png@01D39927.A0D208D0]

[cid:image004.png@01D39927.A0D208D0]

[cid:image005.png@01D39927.A0D208D0]

[cid:image006.png@01D39927.A0D208D0]

[cid:image007.png@01D39927.A0D208D0]


[cid:image008.png@01D39927.A0D208D0]






P Please consider the environment before printing this e-mail.

P Please consider the environment before printing this e-mail.

__
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

__
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.

__

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 2/2] Enable test case with A20-OLinuXino-Lime2

2018-01-30 Thread Stefan Mavrodiev

On 01/22/2018 10:36 AM, Jagan Teki wrote:

On Tue, Jan 2, 2018 at 4:31 PM, Stefan Mavrodiev
 wrote:

On 12/26/2017 11:47 AM, Jagan Teki wrote:

On Fri, Dec 22, 2017 at 3:30 PM, Stefan Mavrodiev 
wrote:

Driver testing is done with A20-OLinuXino-Lime2. Testing
requirements are:
- Exposing spi0 alternative pins in the dts file
- Add alias node, enabling driver probing
- Enable spi flash related options in the defconfig file

The testing log is:
U-Boot SPL 2018.01-rc2-00023-gfa13cb3-dirty (Dec 22 2017 - 11:39:48)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from sunxi SPI


U-Boot 2018.01-rc2-00023-gfa13cb3-dirty (Dec 22 2017 - 11:39:48 +0200)
Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Olimex A20-OLinuXino-LIME2

Lime2 doen't have in-built spi-nor is it?

We have some prototypes with this option.

I've Rev.6 does it have spi-nor?
I assume Rev.6 is actually Rev.F. The first prototype with SPI flash is 
Rev.I (Rev.9).





I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
MMC: no card present
mmc_init: -123, time 1
*** Warning - MMC init failed, using default environment

you lost the env? since it's spi-nor better to use flash env.

What's the point since this is only test case?

this can be an issue if we boot the system from spi-nor, where we can
get saved env.




In:serial
Out:   serial
Err:   serial
Allwinner mUSB OTG (Peripheral)
SCSI:  SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   No ethernet found.
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
=> sspi

=> sf probe
SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB,
total 16 MiB

try to use erase/write and read commands to verify

# Erase one sector
=> sf erase 0x1000 0x100
SF: 256 bytes @ 0x1000 Erased: ERROR
=> sf erase 0x1000 0x1000
SF: 4096 bytes @ 0x1000 Erased: OK

# Get some random data
=> md.b 0x5000 0x100
5000: d6 4d d0 7e 93 d8 0f 48 1b ef 7f 7e be 4e a8 5d .M.~...H...~.N.]
5010: fd 9f e5 7f 2f 7b 5b 19 ed de d8 58 99 7a 24 da /{[X.z$.
5020: ef dd 9c 45 d7 97 ab 4f e7 fb ee 61 bc de 6a 1a ...E...O...a..j.
5030: 9a 9f f4 3a be 4b 2f f3 ce 77 87 7e 07 23 af ff ...:.K/..w.~.#..
5040: e5 e5 c0 fa 65 e2 78 9b 16 38 42 52 e5 6c 52 0d e.x..8BR.lR.
5050: f5 ff da 94 7f 98 96 d7 f0 9d 66 ae 9b b9 a2 cd ..f.
5060: 0b dd f1 c9 1d 3b fe 5b cf ef d6 ce 8b c5 fd 56 .;.[...V
5070: e2 52 eb 78 d4 f1 bf 57 56 6a 57 58 52 f1 0e 9d .R.x...WVjWXR...
5080: df be f8 19 bf cf d7 ac 4b 3e 86 21 3f c3 fe 3e K>.!?..>
5090: ea 27 52 ca 1f 79 bd 7b ef bf 96 c9 9d f6 81 d3 .'R..y.{
50a0: cc 2e 8b c8 34 7f c5 2f 29 19 a8 dc 54 7a 07 1d 4../)...Tz..
50b0: f4 e6 db ed 38 03 59 bb 31 ee b3 dd 5c e6 be 58 8.Y.1...\..X
50c0: a6 7c 87 61 84 47 e0 b1 a1 fc 6e d3 d5 93 bf 8a .|.a.Gn.
50d0: 5d a3 be 4b cf 07 1d 92 ff 36 f9 46 fb 5a cb 8f ]..K.6.F.Z..
50e0: f9 27 7a b8 7b 07 2e 22 a1 ee 56 bc a7 de 57 6a .'z.{.."..V...Wj
50f0: da d4 7d 7f ee db 7a e2 bc 5c 44 64 b7 fc ea 3e ..}...z..\Dd...

# Write one page to spi-nor
=> sf write 0x5000 0x1000 0x100
device 0 offset 0x1000, size 0x100
SF: 256 bytes @ 0x1000 Written: OK

# Readback data
=> sf read 0x5100 0x1000 0x100
device 0 offset 0x1000, size 0x100
SF: 256 bytes @ 0x1000 Read: OK

# Compare data
=> cmp.b 0x5000 0x5100 0x100
Total of 256 byte(s) were the same


=> sf test 0 10
SPI flash test:
0 erase: 11407 ticks, 89 KiB/s 0.712 Mbps
1 check: 8881 ticks, 115 KiB/s 0.920 Mbps
2 write: 10824 ticks, 94 KiB/s 0.752 Mbps
3 read: 8872 ticks, 115 KiB/s 0.920 Mbps
Test passed
0 erase: 11407 ticks, 89 KiB/s 0.712 Mbps
1 check: 8881 ticks, 115 KiB/s 0.920 Mbps
2 write: 10824 ticks, 94 KiB/s 0.752 Mbps
3 read: 8872 ticks, 115 KiB/s 0.920 Mbps
=>

Signed-off-by: Stefan Mavrodiev 
---
   arch/arm/dts/sun7i-a20-olinuxino-lime2.dts | 21 +
   configs/A20-OLinuXino-Lime2_defconfig  |  8 
   2 files changed, 29 insertions(+)

diff --git a/arch/arm/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..3c708da 100644
--- a/arch/arm/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/dts/sun7i-a20-olinuxino-lime2.dts
@@ -54,6 +54,7 @@

  aliases {
  serial0 = 
+   spi0 = 
  };

  chosen {
@@ -215,6 +216,20 @@
  

[U-Boot] Raspberry Pi USB storage broken after 64 byte device descriptor patch

2018-01-30 Thread Kristian Amlie
I have a recent problem with USB storage on the Raspberry Pi 3 with
U-Boot. Take a look at the output from v2017.01:

--
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot:  0
U-Boot>
--

which is the correct output. And compare to v2018.01:

--
USB0:   Core Release: 2.80a
scanning bus 0 for devices... unable to get device descriptor(error=-110)
3 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot>
--

I'm unable to use USB storage afterwards, such as "ls usb 0".

I have bisected the commits and found that the problem was introduced in
the commit below. I am not familiar enough with USB internals to comment
on the correctness of the commit, but apparently it's not working
entirely as expected. Maybe the original author can comment?

--
commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2
Author: Bin Meng 
Date:   Mon Sep 18 15:40:42 2017

usb: Only get 64 bytes device descriptor for full speed devices

Full speed device endpoint 0 can have 8/16/32/64 bMaxPacketSize0.
Other speed devices report fixed value per USB spec. So it only
makes sense if we send a get device descriptor with 64 bytes to
full speed devices.

While we are here, update the comment block to be within 80 cols.

Signed-off-by: Bin Meng 
--

-- 
Kristian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] Fix FreeBSD endian checks

2018-01-30 Thread Justin Hibbits
FreeBSD, like OpenBSD, uses BIG_ENDIAN, LITTLE_ENDIAN, and BYTE_ORDER,
whereas Linux and compatibles use __-prefixed names.  Define the names
the same as the OpenBSD block below it.
---
 include/compiler.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/compiler.h b/include/compiler.h
index a43fb6a738..957f4b5d49 100644
--- a/include/compiler.h
+++ b/include/compiler.h
@@ -50,6 +50,9 @@ typedef unsigned long ulong;
 #endif
 #ifdef __FreeBSD__
 # include  /* htole32 and friends */
+# define __BYTE_ORDER BYTE_ORDER
+# define __LITTLE_ENDIAN LITTLE_ENDIAN
+# define __BIG_ENDIAN BIG_ENDIAN
 #elif defined(__OpenBSD__)
 # include 
 # define __BYTE_ORDER BYTE_ORDER
-- 
2.15.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] AM3703 does not boot from MicroSD card

2018-01-30 Thread phantom0
Hi 
I'm trying to upgrade u-boot from 2016.03 to 2017.09. When I boot it up,
u-boot gives me this error.
What could be the problem? Thanks.

U-Boot SPL 2017.09-dirty (Jan 29 2018 - 10:56:46)
Trying to boot from MMC1
MMC Device 0 not found
spl: could not find mmc device. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###




--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Uboot as x86_64 EFI payload

2018-01-30 Thread Juan Alfonso Reyes Ajenjo
Hi,
I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are 
developing new boards based in Apollo Lake CPU.  We are trying to load uboot 
from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting 
"U-Boot EFI Payload 2002 No memory map" error code.
As I can see in the code 2002 means (efi_stub.c):

ret = boot->get_memory_map(, NULL, , _size, );
if (ret != EFI_BUFFER_TOO_SMALL) {
printhex2(BITS_PER_LONG);
printhex2(ret);
puts(" No memory map\n");
while(1);
return ret;
}

0x20   -> BITS_PER_LONG 32bits
0x02 -> EFI_INVALID_PARAMETER

32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT 
instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation 
error:

In file included from include/common.h:53:0,
 from cmd/efi.c:8:
cmd/efi.c: In function 'do_efi_mem':
./arch/x86/include/asm/global_data.h:117:12: error: 'global_data_ptr' 
undeclared (first use in this function)
#define gd global_data_ptr


I have surfed in the code and I have found this in 
./arch/x86/include/asm/global_data.h

# if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
/* TODO(s...@chromium.org): Consider using a fixed 
register for gd on x86_64 */
#define gd global_data_ptr

What do you mean with "Consider using a fixed register for gd" ?Can you help us 
to make this work? Are we in the correct direction?

Thank you very much,

Best regards,

[cid:image001.gif@01D39918.97D8D0B0]

Juan Alfonso Reyes Ajenjo
Ingeniero en Informatica / Computer Systems Engineer
Ingeniero en Automática y Electrónica Industrial / Automation and Industrial 
Electronics Engineer

GMV
Juan de Herrera nº17
Boecillo
E-47151 Valladolid
Tel. +34 983 54 65 54
Fax +34 983 54 65 53
www.gmv.com 
[cid:image002.png@01D39918.97D8D0B0]

[cid:image003.png@01D39918.97D8D0B0]

[cid:image004.png@01D39918.97D8D0B0]

[cid:image005.png@01D39918.97D8D0B0]

[cid:image006.png@01D39918.97D8D0B0]

[cid:image007.png@01D39918.97D8D0B0]


[cid:image008.png@01D39918.97D8D0B0]






P Please consider the environment before printing this e-mail.

__
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

__
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.

__

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v7 3/3] common: Generic firmware loader for file system

2018-01-30 Thread tien . fong . chee
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 
Reviewed-by: Lothar Waßmann 
---
 common/Kconfig |   9 ++
 common/Makefile|   1 +
 common/fs_loader.c | 326 +
 doc/README.firmware_loader |  76 +++
 include/fs_loader.h|  28 
 5 files changed, 440 insertions(+)
 create mode 100644 common/fs_loader.c
 create mode 100644 doc/README.firmware_loader
 create mode 100644 include/fs_loader.h

diff --git a/common/Kconfig b/common/Kconfig
index 21e067c..cbb0976 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -547,6 +547,15 @@ config DISPLAY_BOARDINFO
  when U-Boot starts up. The board function checkboard() is called
  to do this.
 
+config GENERIC_FIRMWARE_LOADER
+   bool "Enable generic firmware loader driver for file system"
+   help
+ 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.
+
 menu "Start-up hooks"
 
 config ARCH_EARLY_INIT_R
diff --git a/common/Makefile b/common/Makefile
index c7bde23..92d8fb3 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -134,3 +134,4 @@ obj-$(CONFIG_$(SPL_)LOG) += log.o
 obj-$(CONFIG_$(SPL_)LOG_CONSOLE) += log_console.o
 obj-y += s_record.o
 obj-y += xyzModem.o
+obj-$(CONFIG_GENERIC_FIRMWARE_LOADER) += fs_loader.o
diff --git a/common/fs_loader.c b/common/fs_loader.c
new file mode 100644
index 000..c58a492
--- /dev/null
+++ b/common/fs_loader.c
@@ -0,0 +1,326 @@
+/*
+ * Copyright (C) 2018 Intel Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_SPL
+#include 
+#endif
+#include 
+#ifdef CONFIG_CMD_UBIFS
+#include 
+#endif
+#include 
+
+struct firmware_priv {
+   const char *name;   /* Filename */
+   u32 offset; /* Offset of reading a file */
+};
+
+static struct device_location default_locations[] = {
+   {
+   .name = "mmc",
+   .devpart = "0:1",
+   },
+   {
+   .name = "usb",
+   .devpart = "0:1",
+   },
+   {
+   .name = "sata",
+   .devpart = "0:1",
+   },
+};
+
+/* 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);
+   if (err)
+   return err;
+#endif
+
+   return err;
+}
+#else
+static int init_usb(void)
+{
+   debug("Error: Cannot load flash image: no USB support\n");
+   return -ENOSYS;
+}
+#endif
+#endif
+
+#ifdef CONFIG_SATA
+static int init_storage_sata(void)
+{
+   return sata_probe(0);
+}
+#else
+static int init_storage_sata(void)
+{
+   debug("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];
+
+   snprintf(cmd, sizeof(location->mtdpart), "ubi part %s",
+location->mtdpart);
+
+   ret = run_command(cmd, 0);
+   if (ret)
+   return ret;
+
+   snprintf(cmd, sizeof(location->ubivol), "ubifsmount %s",
+location->ubivol);
+
+   ret = run_command(cmd, 0);
+
+   return ret;
+}
+
+static int umount_ubifs(void)
+{
+   return cmd_ubifs_umount();
+}
+#else
+static int mount_ubifs(struct device_location *location)
+{
+   debug("Error: Cannot load image: no UBIFS support\n");
+   return -ENOSYS;
+}
+#endif
+
+#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
+__weak int init_mmc(void)
+{
+   /* Just for the case MMC is not yet initialized */
+   struct mmc *mmc = NULL;
+   int err;
+
+#ifdef CONFIG_SPL
+   spl_mmc_find_device(, spl_boot_device());
+#else
+   debug("#define CONFIG_SPL is required or overrriding %s\n",
+ __func__);
+   return -ENOENT;
+#endif
+
+   err = mmc_init(mmc);
+   if (err) {
+   debug("spl: mmc init failed with error: %d\n", err);
+   return err;
+   }
+
+   return err;
+}
+#else
+__weak 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)) {
+   

[U-Boot] [PATCH v7 2/3] cmd: ubifs: Move ubifs_initialized checking into cmd_ubifs_umount()

2018-01-30 Thread tien . fong . chee
From: Tien Fong Chee 

cmd_ubifs_umount() function would be called directly instead of involving
whole command machinery in generic firmware loader, so checking on
ubifs_initialized status need to be done in cmd_ubifs_umount() without
breaking original functionality design.

Signed-off-by: Tien Fong Chee 
64db5518baa2ea1a8a0e81cc485d760b850c7052
---
 cmd/ubifs.c | 20 
 include/ubi_uboot.h |  1 +
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/cmd/ubifs.c b/cmd/ubifs.c
index 5e9d357..d18e0da 100644
--- a/cmd/ubifs.c
+++ b/cmd/ubifs.c
@@ -51,27 +51,31 @@ int ubifs_is_mounted(void)
return ubifs_mounted;
 }
 
-void cmd_ubifs_umount(void)
+int cmd_ubifs_umount(void)
 {
+   if (ubifs_initialized == 0) {
+   printf("No UBIFS volume mounted!\n");
+   return -1;
+   }
+
uboot_ubifs_umount();
ubifs_mounted = 0;
ubifs_initialized = 0;
+
+   return 0;
 }
 
 static int do_ubifs_umount(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
+   int ret;
+
if (argc != 1)
return CMD_RET_USAGE;
 
-   if (ubifs_initialized == 0) {
-   printf("No UBIFS volume mounted!\n");
-   return -1;
-   }
-
-   cmd_ubifs_umount();
+   ret = cmd_ubifs_umount();
 
-   return 0;
+   return ret;
 }
 
 static int do_ubifs_ls(cmd_tbl_t *cmdtp, int flag, int argc,
diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
index 80acbcb..827dbfc 100644
--- a/include/ubi_uboot.h
+++ b/include/ubi_uboot.h
@@ -75,5 +75,6 @@ extern int ubi_volume_write(char *volume, void *buf, size_t 
size);
 extern int ubi_volume_read(char *volume, char *buf, size_t size);
 
 extern struct ubi_device *ubi_devices[];
+int cmd_ubifs_umount(void);
 
 #endif
-- 
2.2.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v7 1/3] spl: Remove static declaration on spl_mmc_find_device function

2018-01-30 Thread tien . fong . chee
From: Tien Fong Chee 

This patch removes the static declation on spl_mmc_find_device_function
so this function is accessible by the caller from other file. This patch
is required for later patch.

Signed-off-by: Tien Fong Chee 
Reviewed-by: Tom Rini 
---
 common/spl/spl_mmc.c | 2 +-
 include/spl.h| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index b57e0b0..183d05a 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -114,7 +114,7 @@ static int spl_mmc_get_device_index(u32 boot_device)
return -ENODEV;
 }
 
-static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
+int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
 {
 #if CONFIG_IS_ENABLED(DM_MMC)
struct udevice *dev;
diff --git a/include/spl.h b/include/spl.h
index c14448b..60424d7 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -12,6 +12,7 @@
 /* Platform-specific defines */
 #include 
 #include 
+#include 
 
 /* Value in r0 indicates we booted from U-Boot */
 #define UBOOT_NOT_LOADED_FROM_SPL  0x13578642
@@ -83,6 +84,7 @@ void preloader_console_init(void);
 u32 spl_boot_device(void);
 u32 spl_boot_mode(const u32 boot_device);
 void spl_set_bd(void);
+int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device);
 
 /**
  * spl_set_header_raw_uboot() - Set up a standard SPL image structure
-- 
2.2.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v7 0/3] Generic firmware loader

2018-01-30 Thread tien . fong . chee
From: Tien Fong Chee 

This patchset contains generic firmware loader which is very close to Linux
firmware loader but for U-Boot framework. Generic firmware loader can be used
load whatever into target location, and then consumer driver would use it to
program whatever, ie. the FPGA. This version mainly resolved comments from
Tom Rini, Marek Vasut and Simon Goldschmidt in [v6].

This series is working on top of u-boot.git -
 http://git.denx.de/u-boot.git .

[v6]: https://www.mail-archive.com/u-boot@lists.denx.de/msg273961.html

v6 -> v7 changes:
-
- Fixed minor issues from checkpatch.pl.
- Ensure  is included when running generic firmware loader.
- Created new Kconfig option for generic firmware loader.
- Changed all printf to debug.
- Changed sprintf to snprintf.
- Call ubifs function directly instead of involving whoe command machinery.
- Follow kerneldoc format.
- Declare __weak to init_mmc, so user can override it.
- Some nitpicks fixed.

Patchset history

[v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg271905.html
[v2]: https://www.mail-archive.com/u-boot@lists.denx.de/msg271979.html
[v3]: https://www.mail-archive.com/u-boot@lists.denx.de/msg272039.html
[v4]: https://www.mail-archive.com/u-boot@lists.denx.de/msg272432.html
[v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg272771.html

Tien Fong Chee (3):
  spl: Remove static declaration on spl_mmc_find_device function
  cmd: ubifs: Move ubifs_initialized checking into cmd_ubifs_umount()
  common: Generic firmware loader for file system

 cmd/ubifs.c|  20 +--
 common/Kconfig |   9 ++
 common/Makefile|   1 +
 common/fs_loader.c | 326 +
 common/spl/spl_mmc.c   |   2 +-
 doc/README.firmware_loader |  76 +++
 include/fs_loader.h|  28 
 include/spl.h  |   2 +
 include/ubi_uboot.h|   1 +
 9 files changed, 456 insertions(+), 9 deletions(-)
 create mode 100644 common/fs_loader.c
 create mode 100644 doc/README.firmware_loader
 create mode 100644 include/fs_loader.h

-- 
2.2.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] fdt: Fixup only valid memory banks

2018-01-30 Thread Thierry Reding
From: Thierry Reding 

Memory banks with address 0 and size 0 are empty and should not be
passed to the OS via device tree.

Signed-off-by: Thierry Reding 
---
 common/fdt_support.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 724452d75452..8b33f6773d27 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -457,7 +457,7 @@ int fdt_record_loadable(void *blob, u32 index, const char 
*name,
 int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
 {
int err, nodeoffset;
-   int len;
+   int len, i;
u8 tmp[MEMORY_BANKS_MAX * 16]; /* Up to 64-bit address + 64-bit size */
 
if (banks > MEMORY_BANKS_MAX) {
@@ -489,6 +489,12 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64 
size[], int banks)
if (!banks)
return 0;
 
+   for (i = 0; i < banks; i++)
+   if (start[i] == 0 && size[i] == 0)
+   break;
+
+   banks = i;
+
len = fdt_pack_reg(blob, tmp, start, size, banks);
 
err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);
-- 
2.15.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v3] armv8: Remove dependency of SERDES for LSCH2 and LSCH3

2018-01-30 Thread Sriram Dash
Remove dependency of SYS_HAS_SERDES for Layerscape Chasis 3/2.

Signed-off-by: Sriram Dash 
---
Changes in v3:
  - Rebase to latest code.
  - Include changes for LSCH2.

Changes in v2:
  - Remove ifdef when including fsl_serdes.h

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index cefbdfe..7b59dc9 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -3,6 +3,8 @@ config ARCH_LS1012A
select ARMV8_SET_SMPEN
select ARM_ERRATA_855873
select FSL_LSCH2
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
select SYS_FSL_DDR_BE
select SYS_FSL_MMDC
select SYS_FSL_ERRATUM_A010315
@@ -19,6 +21,8 @@ config ARCH_LS1043A
select ARMV8_SET_SMPEN
select ARM_ERRATA_855873
select FSL_LSCH2
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
select SYS_FSL_DDR
select SYS_FSL_DDR_BE
select SYS_FSL_DDR_VER_50
@@ -45,6 +49,8 @@ config ARCH_LS1046A
bool
select ARMV8_SET_SMPEN
select FSL_LSCH2
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
select SYS_FSL_DDR
select SYS_FSL_DDR_BE
select SYS_FSL_DDR_VER_50
@@ -72,6 +78,8 @@ config ARCH_LS1088A
select ARMV8_SET_SMPEN
select ARM_ERRATA_855873
select FSL_LSCH3
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
select SYS_FSL_DDR
select SYS_FSL_DDR_LE
select SYS_FSL_DDR_VER_50
@@ -105,6 +113,8 @@ config ARCH_LS2080A
select ARM_ERRATA_829520
select ARM_ERRATA_833471
select FSL_LSCH3
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
select SYS_FSL_DDR
select SYS_FSL_DDR_LE
select SYS_FSL_DDR_VER_50
@@ -142,13 +152,9 @@ config FSL_LSCH2
select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_5
select SYS_FSL_SEC_BE
-   select SYS_FSL_SRDS_1
-   select SYS_HAS_SERDES
 
 config FSL_LSCH3
bool
-   select SYS_FSL_SRDS_1
-   select SYS_HAS_SERDES
 
 config FSL_MC_ENET
bool "Management Complex network"
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] mtd: nand: mxs_nand: use self init

2018-01-30 Thread stefan
On 29.01.2018 17:01, Stefan Agner wrote:
> From: Stefan Agner 
> 
> Instead of completing initialization via scan_bbt callback use
> NAND self init to initialize the GPMI (MXS) NAND controller.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  drivers/mtd/nand/Kconfig|  1 +
>  drivers/mtd/nand/mxs_nand.c | 52 
> +
>  2 files changed, 30 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 78a39abf75..1ca86925dc 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -140,6 +140,7 @@ config NAND_MXC
>  config NAND_MXS
>   bool "MXS NAND support"
>   depends on MX6 || MX7
> + select SYS_NAND_SELF_INIT

Just realized while NAND_MXS is available in Kconfig since commit
df10a850c5e3 ("mtd: nand: Kconfig: Add NAND_MXS entry") several boards
still select CONFIG_NAND_MXS in the old config header. Those need to be
updated to use Kconfig first before we can add this select.

Will send a v2 with the move to Kconfig before this patch.

--
Stefan

>   imply CMD_NAND
>   help
> This enables NAND driver for the NAND flash controller on the
> diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
> index bed9b65ef4..cf96584fa8 100644
> --- a/drivers/mtd/nand/mxs_nand.c
> +++ b/drivers/mtd/nand/mxs_nand.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -47,6 +48,7 @@
>  #define  MXS_NAND_BCH_TIMEOUT1
>  
>  struct mxs_nand_info {
> + struct nand_chip chip;
>   int cur_chip;
>  
>   uint32_tcmd_queue_len;
> @@ -972,20 +974,15 @@ static int mxs_nand_block_bad(struct mtd_info
> *mtd, loff_t ofs)
>  }
>  
>  /*
> - * Nominally, the purpose of this function is to look for or create the bad
> - * block table. In fact, since the we call this function at the very end of
> - * the initialization process started by nand_scan(), and we doesn't have a
> - * more formal mechanism, we "hook" this function to continue init process.
> - *
>   * At this point, the physical NAND Flash chips have been identified and
>   * counted, so we know the physical geometry. This enables us to make some
>   * important configuration decisions.
>   *
>   * The return value of this function propagates directly back to this 
> driver's
> - * call to nand_scan(). Anything other than zero will cause this driver to
> + * board_nand_init(). Anything other than zero will cause this driver to
>   * tear everything down and declare failure.
>   */
> -static int mxs_nand_scan_bbt(struct mtd_info *mtd)
> +static int mxs_nand_setup_ecc(struct mtd_info *mtd)
>  {
>   struct nand_chip *nand = mtd_to_nand(mtd);
>   struct mxs_nand_info *nand_info = nand_get_controller_data(nand);
> @@ -1047,8 +1044,7 @@ static int mxs_nand_scan_bbt(struct mtd_info *mtd)
>   mtd->_block_markbad = mxs_nand_hook_block_markbad;
>   }
>  
> - /* We use the reference implementation for bad block management. */
> - return nand_default_bbt(mtd);
> + return 0;
>  }
>  
>  /*
> @@ -1150,27 +1146,22 @@ err1:
>   return ret;
>  }
>  
> -/*!
> - * This function is called during the driver binding process.
> - *
> - * @param   pdev  the device structure used to store device specific
> - *information that is used by the suspend, resume and
> - *remove functions
> - *
> - * @return  The function always returns 0.
> - */
> -int board_nand_init(struct nand_chip *nand)
> +void board_nand_init(void)
>  {
> + struct mtd_info *mtd;
>   struct mxs_nand_info *nand_info;
> + struct nand_chip *nand;
>   int err;
>  
>   nand_info = malloc(sizeof(struct mxs_nand_info));
>   if (!nand_info) {
>   printf("MXS NAND: Failed to allocate private data\n");
> - return -ENOMEM;
> + return;
>   }
>   memset(nand_info, 0, sizeof(struct mxs_nand_info));
>  
> + nand = _info->chip;
> + mtd = nand_to_mtd(nand);
>   err = mxs_nand_alloc_buffers(nand_info);
>   if (err)
>   goto err1;
> @@ -1189,13 +1180,19 @@ int board_nand_init(struct nand_chip *nand)
>   nand->dev_ready = mxs_nand_device_ready;
>   nand->select_chip   = mxs_nand_select_chip;
>   nand->block_bad = mxs_nand_block_bad;
> - nand->scan_bbt  = mxs_nand_scan_bbt;
>  
>   nand->read_byte = mxs_nand_read_byte;
>  
>   nand->read_buf  = mxs_nand_read_buf;
>   nand->write_buf = mxs_nand_write_buf;
>  
> + /* first scan to find the device and get the page size */
> + if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_DEVICE, NULL))
> + goto err2;
> +
> + if (mxs_nand_setup_ecc(mtd))
> + goto err2;
> +
>   nand->ecc.read_page = 

Re: [U-Boot] [PATCH] serial: Make full device search optional

2018-01-30 Thread Alexander Graf

On 01/30/2018 12:41 AM, Derald D. Woods wrote:

On Mon, Jan 29, 2018 at 07:46:09AM -0600, Derald Woods wrote:

On Jan 29, 2018 6:57 AM, "Alexander Graf"  wrote:

Commit 608b0c4ad4e5ec0c ("serial: Use next serial device if probing fails")
added code to search for more serial devices if the default one was not
probed correctly.

Unfortunately, that breaks omap3_evm. So while investigating why that is
the case, let's disable the full search for everyone but bcm283x where it
is needed.

Fixes: 608b0c4ad4e5ec0c ("serial: Use next serial device if probing fails")
Reported-by: Derald D. Woods 
Signed-off-by: Alexander Graf 

---

Derald, could you please test this patch and verify it does indeed unbreak
omap3_evm?


The omap3_evm boots now with this patch applied on master. If I enable
SERIAL_SEARCH_ALL, it does not boot. I always build cleanly using the
default config only. On failure, there is no console input/output and
the board unresponsive.


So SPL is already broken? Can you try a known working SPL with 
SERIAL_SEARCH_ALL=y U-Boot payload on top? Does that work?



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/4] Kconfig: gadget: Move CONFIG_USB_FUNCTION_MASS_STORAGE to Kconfig

2018-01-30 Thread Lukasz Majewski
Hi Maxime,

> Hi,
> 
> On Mon, Jan 29, 2018 at 07:25:54PM +0100, Lukasz Majewski wrote:
> > This commit moves USB_FUNCTION_MASS_STORAGE config to Kconfig.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > 
> >  configs/Bananapi_m2m_defconfig | 1 +
> >  configs/CHIP_pro_defconfig | 1 +
> >  configs/Nintendo_NES_Classic_Edition_defconfig | 1 +
> >  configs/Sinlinx_SinA33_defconfig   | 1 +  
> 
> Please make that a default for sunxi instead of crippling our
> defconfigs.

Could you be more specific here?

I've used moveconfig.py script to check which board has this define in
its *.h config file.
Then, it was moved to proper defconfig for this board.

Hence, I don't understand why I "cripple" your (sunxi) defconfig(s)?

If this is the case - I can "select" this option for all sunxi devices,
so all of them would have UMS function enabled.

Is this the case here?

> 
> Thanks!
> Maxime
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpjLG8YEGx8j.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


  1   2   >