Re: [U-Boot] UDP packet sender

[Gaëtan Carlier]

Hi Joe,

On 02/02/2018 08:13 PM, Joe Hershberger wrote:
> On Tue, Jan 23, 2018 at 8:02 AM, Gaëtan Carlier  wrote:
>> Joe,
>> On 01/23/2018 01:54 AM, Joe Hershberger wrote:
>>> On Mon, Jan 22, 2018 at 5:28 PM, Gaëtan Carlier  wrote:
 Hi Joe,

 On 01/22/2018 11:46 PM, Joe Hershberger wrote:
> Hi Gaëtan,
>
> On Thu, Jan 18, 2018 at 4:56 AM, Gaëtan Carlier  wrote:
>> Hi,
>> I would like to implement a new command and submit it to the mailing 
>> list.
>> The command will have the following format:
>> udpsend
>> 
>>
>> udpsend 255.255.255.255 4040 0 hello world
>>
>> If source port is 0, a random port will be used (11000 + (get_timer(0) % 
>> 4096))
> 
> If you want to add this, add it as a command in  cmd/netcat.c and use
> the same semantics as netcat as much as possible. Since there is no
> pipe support in U-Boot's shell, the data to send will have to be a
> parameter. Best to make it something that does not collide with
> netcat.
> 
> In netcat, you specify a "-u" switch to enable UDP, so your command
> would require that switch (so TCP could be added later).
> 
> So that means your invocation should be "nc -u -p  
>  -- Text to send"
>

Thank you for these informations. I will do that.
 
> I'd like to understand the purpose / use-case for this command? Maybe
> there is a more appropriate way to solve the problem you have instead.
>

 I want to send the current progression of an update script. As the board 
 has no display/leds, the only way to get update progression is to 
 broadcast UDP packet that a PC software will monitor. U-Boot will 
 load/source a script from an ext4 partition. This script will load a 
 rootfs image from update partition of an eMMC splitted into 10M chunks 
 that will be written to an other partition of the eMMC.
 This is for update on site (by customer).

 This UDP command will also be used in a closed production LAN to send 
 Unique ID of the CPU (secret) and the MAC address to the monitoring 
 production (burning) software that will feed a database to be able to 
 generate license keys linked to hardware and print a label with the 
 product name and the MAC address.

 Maybe there is already existing command that I can use from a U-Boot 
 script ?
>>>
>>> I think this is commonly done by enabling netconsole and controlling /
>>> monitoring progress based on console output sent over UDP.
>>
>> a) I can/want not enable netconsole when the product is on the network of 
>> the customer.
>> b) Once on customer LAN, everything is DHCP.
>> c) I don't want to increase load of CPU because updating software on 
>> customer's computer has to decode all UDP frames sent by U-Boot while 10% of 
>> UDP are really needed (several boards can be on the same network).
>>
>>
>>>
>>> Cheers,
>>> -Joe
>>>
>> Where do I have to place my code : cmd or net directory ?
>> For me cmd will be the better directory to keep it away from all more 
>> complex stuff like DHCP, TFTP, ...
>
> That's probably true. cmd/ would be the appropriate place.
>
> -Joe
>

 Regards,
 Gaëtan
>>
>> Regards,
>> Gaëtan.

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

[U-Boot] [PATCH 2/2] drivers: i2c: mxc: Update support to 8 I2C controllers

[Sriram Dash]

Existing driver supports upto 4 I2C controllers.
But some of future NXPs SoCs like lx2160a has
eight I2C controllers.

Update MXC driver to support upto 8 I2C controllers

Signed-off-by: Sriram Dash 
Signed-off-by: Priyanka Jain 
---
 drivers/i2c/Kconfig   | 80 +++
 drivers/i2c/mxc_i2c.c | 56 
 2 files changed, 136 insertions(+)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 7cad493..c863a6e 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -179,6 +179,30 @@ config SYS_I2C_MXC_I2C4
help
 Add support for NXP MXC I2C Controller 4.
 Required for SoCs which have I2C MXC controller 4 eg LS1088A, LS2080A
+
+config SYS_I2C_MXC_I2C5
+   bool "NXP MXC I2C5"
+   help
+Add support for NXP MXC I2C Controller 5.
+Required for SoCs which have I2C MXC controller 5 eg LX2160A
+
+config SYS_I2C_MXC_I2C6
+   bool "NXP MXC I2C6"
+   help
+Add support for NXP MXC I2C Controller 6.
+Required for SoCs which have I2C MXC controller 6 eg LX2160A
+
+config SYS_I2C_MXC_I2C7
+   bool "NXP MXC I2C7"
+   help
+Add support for NXP MXC I2C Controller 7.
+Required for SoCs which have I2C MXC controller 7 eg LX2160A
+
+config SYS_I2C_MXC_I2C8
+   bool "NXP MXC I2C8"
+   help
+Add support for NXP MXC I2C Controller 8.
+Required for SoCs which have I2C MXC controller 8 eg LX2160A
 endif
 
 if SYS_I2C_MXC_I2C1
@@ -239,6 +263,62 @@ config SYS_MXC_I2C4_SLAVE
 MXC I2C4 Slave
 endif
 
+if SYS_I2C_MXC_I2C5
+config SYS_MXC_I2C5_SPEED
+   int "I2C Channel 5 speed"
+   default 10
+   help
+MXC I2C Channel 5 speed
+
+config SYS_MXC_I2C5_SLAVE
+   int "I2C5 Slave"
+   default 0
+   help
+MXC I2C5 Slave
+endif
+
+if SYS_I2C_MXC_I2C6
+config SYS_MXC_I2C6_SPEED
+   int "I2C Channel 6 speed"
+   default 10
+   help
+MXC I2C Channel 6 speed
+
+config SYS_MXC_I2C6_SLAVE
+   int "I2C6 Slave"
+   default 0
+   help
+MXC I2C6 Slave
+endif
+
+if SYS_I2C_MXC_I2C7
+config SYS_MXC_I2C7_SPEED
+   int "I2C Channel 7 speed"
+   default 10
+   help
+MXC I2C Channel 7 speed
+
+config SYS_MXC_I2C7_SLAVE
+   int "I2C7 Slave"
+   default 0
+   help
+MXC I2C7 Slave
+endif
+
+if SYS_I2C_MXC_I2C8
+config SYS_MXC_I2C8_SPEED
+   int "I2C Channel 8 speed"
+   default 10
+   help
+MXC I2C Channel 8 speed
+
+config SYS_MXC_I2C8_SLAVE
+   int "I2C8 Slave"
+   default 0
+   help
+MXC I2C8 Slave
+endif
+
 config SYS_I2C_OMAP24XX
bool "TI OMAP2+ I2C driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 79228c2..a17c1ec 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -589,6 +589,22 @@ static int bus_i2c_write(struct mxc_i2c_bus *i2c_bus, u8 
chip, u32 addr,
 #define I2C4_BASE_ADDR 0
 #endif
 
+#if !defined(I2C5_BASE_ADDR)
+#define I2C5_BASE_ADDR 0
+#endif
+
+#if !defined(I2C6_BASE_ADDR)
+#define I2C6_BASE_ADDR 0
+#endif
+
+#if !defined(I2C7_BASE_ADDR)
+#define I2C7_BASE_ADDR 0
+#endif
+
+#if !defined(I2C8_BASE_ADDR)
+#define I2C8_BASE_ADDR 0
+#endif
+
 static struct mxc_i2c_bus mxc_i2c_buses[] = {
 #if defined(CONFIG_ARCH_LS1021A) || defined(CONFIG_VF610) || \
defined(CONFIG_FSL_LAYERSCAPE)
@@ -596,11 +612,19 @@ static struct mxc_i2c_bus mxc_i2c_buses[] = {
{ 1, I2C2_BASE_ADDR, I2C_QUIRK_FLAG },
{ 2, I2C3_BASE_ADDR, I2C_QUIRK_FLAG },
{ 3, I2C4_BASE_ADDR, I2C_QUIRK_FLAG },
+   { 4, I2C5_BASE_ADDR, I2C_QUIRK_FLAG },
+   { 5, I2C6_BASE_ADDR, I2C_QUIRK_FLAG },
+   { 6, I2C7_BASE_ADDR, I2C_QUIRK_FLAG },
+   { 7, I2C8_BASE_ADDR, I2C_QUIRK_FLAG },
 #else
{ 0, I2C1_BASE_ADDR, 0 },
{ 1, I2C2_BASE_ADDR, 0 },
{ 2, I2C3_BASE_ADDR, 0 },
{ 3, I2C4_BASE_ADDR, 0 },
+   { 4, I2C5_BASE_ADDR, 0 },
+   { 5, I2C6_BASE_ADDR, 0 },
+   { 6, I2C7_BASE_ADDR, 0 },
+   { 7, I2C8_BASE_ADDR, 0 },
 #endif
 };
 
@@ -738,6 +762,38 @@ U_BOOT_I2C_ADAP_COMPLETE(mxc3, mxc_i2c_init, mxc_i2c_probe,
 CONFIG_SYS_MXC_I2C4_SLAVE, 3)
 #endif
 
+#ifdef CONFIG_SYS_I2C_MXC_I2C5
+U_BOOT_I2C_ADAP_COMPLETE(mxc4, mxc_i2c_init, mxc_i2c_probe,
+mxc_i2c_read, mxc_i2c_write,
+mxc_i2c_set_bus_speed,
+CONFIG_SYS_MXC_I2C5_SPEED,
+CONFIG_SYS_MXC_I2C5_SLAVE, 4)
+#endif
+
+#ifdef CONFIG_SYS_I2C_MXC_I2C6
+U_BOOT_I2C_ADAP_COMPLETE(mxc5, mxc_i2c_init, mxc_i2c_probe,
+mxc_i2c_read, mxc_i2c_write,
+mxc_i2c_set_bus_speed,
+CONFIG_SYS_MXC_I2C6_SPEED,
+CONFIG_SYS_MXC_I2C6_SLAVE, 5)
+#endif
+
+#ifdef 

[U-Boot] [PATCH 1/2] drivers: i2c: mxc: Update SYS_I2C_MXC_I2C support in Kconfig

[Sriram Dash]

NXP layerscape platforms like ls1088a, ls2088a
uses MXC I2C Controller.
-Remove dependency of MX6 for the same.

Update related configs to use Kconfig file.
-Add SYS_I2C_MXC_I2C1,_I2C2,_I2C3,_I2C4 in Kconfig
-Add CONFIG_SYS_MXC_I2C1_SPEED,_I2C2_,_I2C3_,_I2C4_ in Kconfig
-Add CONFIG_SYS_MXC_I2C1_SLAVE,_I2C2_,_I2C3_,_I2C4_ in Kconfig

Signed-off-by: Sriram Dash 
Signed-off-by: Priyanka Jain 
---
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 23 
 drivers/i2c/Kconfig   | 89 +--
 include/configs/ls1012a_common.h  |  3 --
 include/configs/ls1043a_common.h  |  5 --
 include/configs/ls1046a_common.h  |  5 --
 include/configs/ls1088a_common.h  |  5 --
 include/configs/ls2080a_common.h  |  5 --
 include/configs/ls2080a_emu.h |  3 --
 include/configs/ls2080a_simu.h|  3 --
 9 files changed, 109 insertions(+), 32 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index cefbdfe..ebccd16 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -12,6 +12,9 @@ config ARCH_LS1012A
select SYS_FSL_ERRATUM_A009008
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
+   select SYS_I2C_MXC
+   select SYS_I2C_MXC_I2C1
+   select SYS_I2C_MXC_I2C2
imply PANIC_HANG
 
 config ARCH_LS1043A
@@ -37,6 +40,11 @@ config ARCH_LS1043A
select SYS_FSL_HAS_DDR4
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
+   select SYS_I2C_MXC
+   select SYS_I2C_MXC_I2C1
+   select SYS_I2C_MXC_I2C2
+   select SYS_I2C_MXC_I2C3
+   select SYS_I2C_MXC_I2C4
imply SCSI
imply SCSI_AHCI
imply CMD_PCI
@@ -64,6 +72,11 @@ config ARCH_LS1046A
select SYS_FSL_SRDS_2
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
+   select SYS_I2C_MXC
+   select SYS_I2C_MXC_I2C1
+   select SYS_I2C_MXC_I2C2
+   select SYS_I2C_MXC_I2C3
+   select SYS_I2C_MXC_I2C4
imply SCSI
imply SCSI_AHCI
 
@@ -94,6 +107,11 @@ config ARCH_LS1088A
select FSL_TZASC_1
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
+   select SYS_I2C_MXC
+   select SYS_I2C_MXC_I2C1
+   select SYS_I2C_MXC_I2C2
+   select SYS_I2C_MXC_I2C3
+   select SYS_I2C_MXC_I2C4
imply SCSI
imply PANIC_HANG
 
@@ -134,6 +152,11 @@ config ARCH_LS2080A
select SYS_FSL_ERRATUM_A009203
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
+   select SYS_I2C_MXC
+   select SYS_I2C_MXC_I2C1
+   select SYS_I2C_MXC_I2C2
+   select SYS_I2C_MXC_I2C3
+   select SYS_I2C_MXC_I2C4
imply PANIC_HANG
 
 config FSL_LSCH2
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 17d21bb..7cad493 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -149,13 +149,96 @@ config SYS_I2C_MESON
  both 7-bit and 10-bit addresses.
 
 config SYS_I2C_MXC
-   bool "NXP i.MX I2C driver"
-   depends on MX6
+   bool "NXP MXC I2C driver"
help
- Add support for the NXP i.MX I2C driver. This supports upto for bus
+ Add support for the NXP I2C driver. This supports upto for bus
  channels and operating on standard mode upto 100 kbits/s and fast
  mode upto 400 kbits/s.
 
+if SYS_I2C_MXC
+config SYS_I2C_MXC_I2C1
+   bool "NXP MXC I2C1"
+   help
+Add support for NXP MXC I2C Controller 1.
+Required for SoCs which have I2C MXC controller 1 eg LS1088A, LS2080A
+
+config SYS_I2C_MXC_I2C2
+   bool "NXP MXC I2C2"
+   help
+Add support for NXP MXC I2C Controller 2.
+Required for SoCs which have I2C MXC controller 2 eg LS1088A, LS2080A
+
+config SYS_I2C_MXC_I2C3
+   bool "NXP MXC I2C3"
+   help
+Add support for NXP MXC I2C Controller 3.
+Required for SoCs which have I2C MXC controller 3 eg LS1088A, LS2080A
+
+config SYS_I2C_MXC_I2C4
+   bool "NXP MXC I2C4"
+   help
+Add support for NXP MXC I2C Controller 4.
+Required for SoCs which have I2C MXC controller 4 eg LS1088A, LS2080A
+endif
+
+if SYS_I2C_MXC_I2C1
+config SYS_MXC_I2C1_SPEED
+   int "I2C Channel 1 speed"
+   default 4000 if TARGET_LS2080A_SIMU || TARGET_LS2080A_EMU
+   default 10
+   help
+MXC I2C Channel 1 speed
+
+config SYS_MXC_I2C1_SLAVE
+   int "I2C1 Slave"
+   default 0
+   help
+MXC I2C1 Slave
+endif
+
+if SYS_I2C_MXC_I2C2
+config SYS_MXC_I2C2_SPEED
+   int "I2C Channel 2 speed"
+   default 4000 if TARGET_LS2080A_SIMU || TARGET_LS2080A_EMU
+   default 10
+   help
+MXC I2C Channel 2 speed
+
+config SYS_MXC_I2C2_SLAVE
+   int "I2C2 Slave"
+   default 0
+   help
+MXC I2C2 Slave
+endif
+
+if 

Re: [U-Boot] [PATCH 1/2] parse the second area of android image

[Kever Yang]

On 01/27/2018 01:59 PM, Bin Chen wrote:
> The second area of android image was intended to put a 2nd stage
> bootloader but in practice were rarely used (in my knowledge).
>
> An proposal was made to the AOSP to (re)use the second area as the dtb[1],
> This patch itself doesn't depend on that proposal being accepted but it won't
> be that helpful as well if that proposal won't be accepted. But don't do
> any harm as well.
>
> [1] https://android-review.googlesource.com/#/c/417447/
> Signed-off-by: Bin Chen 
> Reviewed-by: Tom Rini 

Looks good to me,

Reviewed-by: Kever Yang 

Thanks,
- Kever
> ---
>  common/image-android.c | 19 +++
>  include/image.h|  2 ++
>  2 files changed, 21 insertions(+)
>
> diff --git a/common/image-android.c b/common/image-android.c
> index e74d0aafca..5ad3a1fa38 100644
> --- a/common/image-android.c
> +++ b/common/image-android.c
> @@ -146,6 +146,25 @@ int android_image_get_ramdisk(const struct andr_img_hdr 
> *hdr,
>   return 0;
>  }
>  
> +int android_image_get_second(const struct andr_img_hdr *hdr,
> +   ulong *second_data, ulong *second_len)
> +{
> + if (!hdr->second_size) {
> + *second_data = *second_len = 0;
> + return -1;
> + }
> +
> + *second_data = (unsigned long)hdr;
> + *second_data += hdr->page_size;
> + *second_data += ALIGN(hdr->kernel_size, hdr->page_size);
> + *second_data += ALIGN(hdr->ramdisk_size, hdr->page_size);
> +
> + printf("second address is 0x%lx\n",*second_data);
> +
> + *second_len = hdr->second_size;
> + return 0;
> +}
> +
>  #if !defined(CONFIG_SPL_BUILD)
>  /**
>   * android_print_contents - prints out the contents of the Android format 
> image
> diff --git a/include/image.h b/include/image.h
> index b2b23a96f1..c8ce4da901 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1263,6 +1263,8 @@ int android_image_get_kernel(const struct andr_img_hdr 
> *hdr, int verify,
>ulong *os_data, ulong *os_len);
>  int android_image_get_ramdisk(const struct andr_img_hdr *hdr,
> ulong *rd_data, ulong *rd_len);
> +int android_image_get_second(const struct andr_img_hdr *hdr,
> +   ulong *second_data, ulong *second_len);
>  ulong android_image_get_end(const struct andr_img_hdr *hdr);
>  ulong android_image_get_kload(const struct andr_img_hdr *hdr);
>  void android_print_contents(const struct andr_img_hdr *hdr);


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

Re: [U-Boot] [PATCH v2 1/3] Move CONFIG_PHY_ADDR to Kconfig

[Calvin Johnson]

Hi,

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> 
> On Mon, Feb 05, 2018 at 09:07:40AM +0100, Maxime Ripard wrote:
> > On Sat, Feb 03, 2018 at 04:37:15AM +, Calvin Johnson wrote:
> > > > Hi,
> > > >
> > > > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> > > > > Stefan Mavrodiev
> > > > > Sent: Friday, February 2, 2018 7:24 PM
> > > >
> > > > 
> > > >
> > > > > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> > > > > index 95b7534..c934aed 100644
> > > > > --- a/drivers/net/phy/Kconfig
> > > > > +++ b/drivers/net/phy/Kconfig
> > > > > @@ -12,6 +12,13 @@ menuconfig PHYLIB
> > > > >
> > > > >  if PHYLIB
> > > > >
> > > > > +config PHY_ADDR
> > > > > + int "PHY address"
> > > > > + default 1 if ARCH_SUNXI
> > >
> > > Sorry, I meant the  default value can be defined in board/sunxi/Kconfig.
> > > Remaining definition of PHY_ADDR config can be here.
> >
> > Tom has asked a few times not to do this but to put the defaults where
> > the Kconfig option is defined. I'm not sure I remember the details
> > though.
> 
> For now, yes, the preferred way of dealing with this is 'default FOO if BAR' 
> in
> the main Kconfig entry line.  What I wish for long term is for 'imply' to get
> extended to support 'imply FOO BAR' but I've not had more to add there
> other than "Gee, this would make life easier".

Got it. Thanks!

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

Re: [U-Boot] [PATCH] Kconfig: Use imply for network commands in distro default

[Tom Rini]

On Wed, Jan 31, 2018 at 04:09:57PM +0100, Michal Simek wrote:

> There is no reason to unconditially select network commands as distro
> defaults. Systems without ethernet but with sd, sata, usb should also be
> able to use distro defaults. Use imply instead of select.
> 
> Signed-off-by: Michal Simek 
> ---
> 
>  Kconfig | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Kconfig b/Kconfig
> index 9b8a8077993a..55bb00936cf7 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -69,14 +69,14 @@ config DISTRO_DEFAULTS
>   imply USE_BOOTCOMMAND
>   select CMD_BOOTZ if ARM && !ARM64
>   select CMD_BOOTI if ARM64
> - select CMD_DHCP
> - select CMD_PXE
> + imply CMD_DHCP
> + imply CMD_PXE
>   select CMD_EXT2
>   select CMD_EXT4
>   select CMD_FAT
>   select CMD_FS_GENERIC
> - select CMD_MII
> - select CMD_PING
> + imply CMD_MII
> + imply CMD_PING
>   select CMD_PART
>   select HUSH_PARSER
>   help

Should we perhaps use select CMD_DHCP if NET, etc?  There's a certain
level of non-opt-outedness that's supposed to be here, so long as the
underlying functionality is there.  And a follow-up might be that a
bunch more CMDs need to be nested under / depend on NET to start with.
But that's just a thought.  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 0/2] Android and arm64 improvement

[Bin Chen]

On 6 February 2018 at 13:12, Tom Rini  wrote:

> On Tue, Feb 06, 2018 at 10:31:10AM +1100, Bin Chen wrote:
>
> > Hello Tom,
> >
> > Any feedback on this?
>
> It's on my list to grab soon, thanks!
>
> Excellent! Thanks!


> >
> > On 27 January 2018 at 16:59, Bin Chen  wrote:
> >
> > >
> > > I rebased the two patches submitted (quite )a while ago on top of
> > > current U-boot master fb4413295c765aa8c013650984dc2d908964c81d
> > > (and there were no conflicts).
> > >
> > > The first patch added the support of parsing the second area of Android
> > > image so
> > > that it can be used for good. On Poplar board, we are using that area
> for
> > > dtb.
> > > The first patch shouldn't impact any functionality since
> > > it is new.
> > >
> > > The second patch moves the booti_setup out of booti.c. It was the
> result
> > > of a
> > > discusion[1] how to better support the arm64 Android image.
> > >
> > > I have boot tested it on Poplar board[2] with additional patch[3] that
> is
> > > built on top of the booti. I have hacked version of using bootm but it
> > > seems quit
> > > mess up - need lots of changes in different places ("Shotgun Surgery")
> to
> > > handle
> > > Android specific and/or arm64 specific code. Now, I feel a separate
> > > bootandroid command might be a cleaner solution.
> > >
> > > That being said, the second patch doesn't depend on or impact any
> change we
> > > might have in the future for better Android support.
> > >
> > > [1] https://lists.denx.de/pipermail/u-boot/2017-July/297933.html
> > > [2] https://github.com/96boards-poplar/Documentation
> > > [3] https://github.com/pierrchen/u-boot/commit/
> > > 8463e6177654026746161487d0f0bd8998bb7a5b
> > >
> > > Bin Chen (2):
> > >   parse the second area of android image
> > >   move booti_setup to arch/arm/lig/image.c
> > >
> > >  arch/arm/lib/Makefile  |  2 +-
> > >  arch/arm/lib/image.c   | 76 +
> > >  cmd/booti.c| 92 +++---
> > > 
> > >  common/image-android.c | 19 +++
> > >  include/image.h| 11 ++
> > >  5 files changed, 120 insertions(+), 80 deletions(-)
> > >  create mode 100644 arch/arm/lib/image.c
> > >
> > > --
> > > 2.15.0
> > >
> > >
> >
> >
> > --
> > Regards,
> > Bin
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
> --
> Tom
>



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

Re: [U-Boot] [PATCH 0/2] Android and arm64 improvement

[Tom Rini]

On Tue, Feb 06, 2018 at 10:31:10AM +1100, Bin Chen wrote:

> Hello Tom,
> 
> Any feedback on this?

It's on my list to grab soon, thanks!

> 
> On 27 January 2018 at 16:59, Bin Chen  wrote:
> 
> >
> > I rebased the two patches submitted (quite )a while ago on top of
> > current U-boot master fb4413295c765aa8c013650984dc2d908964c81d
> > (and there were no conflicts).
> >
> > The first patch added the support of parsing the second area of Android
> > image so
> > that it can be used for good. On Poplar board, we are using that area for
> > dtb.
> > The first patch shouldn't impact any functionality since
> > it is new.
> >
> > The second patch moves the booti_setup out of booti.c. It was the result
> > of a
> > discusion[1] how to better support the arm64 Android image.
> >
> > I have boot tested it on Poplar board[2] with additional patch[3] that is
> > built on top of the booti. I have hacked version of using bootm but it
> > seems quit
> > mess up - need lots of changes in different places ("Shotgun Surgery") to
> > handle
> > Android specific and/or arm64 specific code. Now, I feel a separate
> > bootandroid command might be a cleaner solution.
> >
> > That being said, the second patch doesn't depend on or impact any change we
> > might have in the future for better Android support.
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2017-July/297933.html
> > [2] https://github.com/96boards-poplar/Documentation
> > [3] https://github.com/pierrchen/u-boot/commit/
> > 8463e6177654026746161487d0f0bd8998bb7a5b
> >
> > Bin Chen (2):
> >   parse the second area of android image
> >   move booti_setup to arch/arm/lig/image.c
> >
> >  arch/arm/lib/Makefile  |  2 +-
> >  arch/arm/lib/image.c   | 76 +
> >  cmd/booti.c| 92 +++---
> > 
> >  common/image-android.c | 19 +++
> >  include/image.h| 11 ++
> >  5 files changed, 120 insertions(+), 80 deletions(-)
> >  create mode 100644 arch/arm/lib/image.c
> >
> > --
> > 2.15.0
> >
> >
> 
> 
> -- 
> Regards,
> Bin
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

-- 
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] arm64 :show_regs: show the address before relocation

[Tom Rini]

On Tue, Feb 06, 2018 at 12:40:39AM +, Karl Beldan wrote:
> On Sun, Feb 4, 2018 at 1:39 PM, Simon Glass  wrote:
> > Hi,
> >
> > On 22 January 2018 at 12:01, Karl Beldan  wrote:
> >>
> >> On Tue, Nov 28, 2017 at 10:08:08AM +0800, Peng Fan wrote:
> >> > After relocation, when error happends, it is hard to track
> >> > ELR and LR with asm file objdumped from elf file.
> >> >
> >> > So subtract the gd->reloc_off the reflect the compliation address.
> >> >
> >> > Signed-off-by: Peng Fan 
> >> > ---
> >> >  arch/arm/lib/interrupts_64.c | 10 --
> >> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/arch/arm/lib/interrupts_64.c b/arch/arm/lib/interrupts_64.c
> >> > index 7c9cfce69f..cbcfeec2b0 100644
> >> > --- a/arch/arm/lib/interrupts_64.c
> >> > +++ b/arch/arm/lib/interrupts_64.c
> >> > @@ -9,6 +9,7 @@
> >> >  #include 
> >> >  #include 
> >> >
> >> > +DECLARE_GLOBAL_DATA_PTR;
> >> >
> >> >  int interrupt_init(void)
> >> >  {
> >> > @@ -29,8 +30,13 @@ void show_regs(struct pt_regs *regs)
> >> >  {
> >> >   int i;
> >> >
> >> > - printf("ELR: %lx\n", regs->elr);
> >> > - printf("LR:  %lx\n", regs->regs[30]);
> >> > + if (gd->flags & GD_FLG_RELOC) {
> >> > + printf("ELR: %lx\n", regs->elr - gd->reloc_off);
> >> > + printf("LR:  %lx\n", regs->regs[30] - gd->reloc_off);
> >> > + } else {
> >> > + printf("ELR: %lx\n", regs->elr);
> >> > + printf("LR:  %lx\n", regs->regs[30]);
> >> > + }
> >> >   for (i = 0; i < 29; i += 2)
> >> >   printf("x%-2d: %016lx x%-2d: %016lx\n",
> >> >  i, regs->regs[i], i+1, regs->regs[i+1]);
> >>
> >> Hi,
> >>
> >> It is useful to show the relocated address, the kind of local mods I too
> >> have had for a while.
> >> But here you dropped the hw register values altogether, instead of
> >> displaying both, which I guess I am not the only one to not be happy
> >> about.
> >
> > Yes I agree that we should have both. Do you think you could do a patch?
> 
> Hi,
> 
> Peng did reply with a patch[1], I was bugged by the formatting but no
> follow-up ensued, so unclear whether it felt annoying on anybody's side.
> Anyways sure, if the thread stalls for a few more days, I'll make sure
> to send a patch.
> 
> [1] https://marc.info/?l=u-boot=151674072412633=2

For the record, I took your objects as "Changes still Requested" to the
patch and I think/hope in patchwork I marked it as such.

-- 
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] am335x, shc: kconfig: Fix misspelled choice default

[Tom Rini]

On Tue, Jan 30, 2018 at 02:04:43PM +0100, Ulf Magnusson wrote:

> 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 

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, 2/2] cmd: Make CONFIG_CMD_FPGA depend on CONFIG_FPGA

[Tom Rini]

On Sat, Jan 27, 2018 at 08:28:40PM +0200, Tuomas Tynkkynen wrote:

> cmd/Makefile has:
> 
> ifdef CONFIG_FPGA
> obj-$(CONFIG_CMD_FPGA) += fpga.o
> endif
> 
> which means that if CONFIG_FPGA is not set, CONFIG_CMD_FPGA silently
> does nothing. Let's remove that Makefile conditional and instead express
> this equivalent dependency in Kconfig, so a lot of redundant
> 
>  # CONFIG_CMD_FPGA is not set
> 
> can be removed from board defconfigs that don't actually have an FPGA.
> 
> Signed-off-by: Tuomas Tynkkynen 

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] usb: ulpi: kconfig: Remove meaningless choice default

[Tom Rini]

On Tue, Jan 30, 2018 at 02:07:05PM +0100, Ulf Magnusson wrote:

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

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] Fix FreeBSD endian checks

[Tom Rini]

On Mon, Jan 29, 2018 at 10:23:36PM -0600, Justin Hibbits wrote:

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

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, 1/2] fpga: Resync various CONFIG_FPGA_* symbols

[Tom Rini]

On Sat, Jan 27, 2018 at 08:28:39PM +0200, Tuomas Tynkkynen wrote:

> These are declared in Kconfig, but some #defines have crept in.
> 
> CONFIG_FPGA
> CONFIG_FPGA_ALTERA
> CONFIG_FPGA_CYCLON2
> CONFIG_FPGA_SOCFPGA
> CONFIG_FPGA_XILINX
> CONFIG_FPGA_ZYNQMPPL
> 
> Signed-off-by: Tuomas Tynkkynen 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] arm64 :show_regs: show the address before relocation

[Karl Beldan]

On Sun, Feb 4, 2018 at 1:39 PM, Simon Glass  wrote:
> Hi,
>
> On 22 January 2018 at 12:01, Karl Beldan  wrote:
>>
>> On Tue, Nov 28, 2017 at 10:08:08AM +0800, Peng Fan wrote:
>> > After relocation, when error happends, it is hard to track
>> > ELR and LR with asm file objdumped from elf file.
>> >
>> > So subtract the gd->reloc_off the reflect the compliation address.
>> >
>> > Signed-off-by: Peng Fan 
>> > ---
>> >  arch/arm/lib/interrupts_64.c | 10 --
>> >  1 file changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm/lib/interrupts_64.c b/arch/arm/lib/interrupts_64.c
>> > index 7c9cfce69f..cbcfeec2b0 100644
>> > --- a/arch/arm/lib/interrupts_64.c
>> > +++ b/arch/arm/lib/interrupts_64.c
>> > @@ -9,6 +9,7 @@
>> >  #include 
>> >  #include 
>> >
>> > +DECLARE_GLOBAL_DATA_PTR;
>> >
>> >  int interrupt_init(void)
>> >  {
>> > @@ -29,8 +30,13 @@ void show_regs(struct pt_regs *regs)
>> >  {
>> >   int i;
>> >
>> > - printf("ELR: %lx\n", regs->elr);
>> > - printf("LR:  %lx\n", regs->regs[30]);
>> > + if (gd->flags & GD_FLG_RELOC) {
>> > + printf("ELR: %lx\n", regs->elr - gd->reloc_off);
>> > + printf("LR:  %lx\n", regs->regs[30] - gd->reloc_off);
>> > + } else {
>> > + printf("ELR: %lx\n", regs->elr);
>> > + printf("LR:  %lx\n", regs->regs[30]);
>> > + }
>> >   for (i = 0; i < 29; i += 2)
>> >   printf("x%-2d: %016lx x%-2d: %016lx\n",
>> >  i, regs->regs[i], i+1, regs->regs[i+1]);
>>
>> Hi,
>>
>> It is useful to show the relocated address, the kind of local mods I too
>> have had for a while.
>> But here you dropped the hw register values altogether, instead of
>> displaying both, which I guess I am not the only one to not be happy
>> about.
>
> Yes I agree that we should have both. Do you think you could do a patch?
>

Hi,

Peng did reply with a patch[1], I was bugged by the formatting but no
follow-up ensued, so unclear whether it felt annoying on anybody's side.
Anyways sure, if the thread stalls for a few more days, I'll make sure
to send a patch.

[1] https://marc.info/?l=u-boot=151674072412633=2

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

Re: [U-Boot] [PATCH 0/2] Android and arm64 improvement

[Bin Chen]

Hello Tom,

Any feedback on this?

On 27 January 2018 at 16:59, Bin Chen  wrote:

>
> I rebased the two patches submitted (quite )a while ago on top of
> current U-boot master fb4413295c765aa8c013650984dc2d908964c81d
> (and there were no conflicts).
>
> The first patch added the support of parsing the second area of Android
> image so
> that it can be used for good. On Poplar board, we are using that area for
> dtb.
> The first patch shouldn't impact any functionality since
> it is new.
>
> The second patch moves the booti_setup out of booti.c. It was the result
> of a
> discusion[1] how to better support the arm64 Android image.
>
> I have boot tested it on Poplar board[2] with additional patch[3] that is
> built on top of the booti. I have hacked version of using bootm but it
> seems quit
> mess up - need lots of changes in different places ("Shotgun Surgery") to
> handle
> Android specific and/or arm64 specific code. Now, I feel a separate
> bootandroid command might be a cleaner solution.
>
> That being said, the second patch doesn't depend on or impact any change we
> might have in the future for better Android support.
>
> [1] https://lists.denx.de/pipermail/u-boot/2017-July/297933.html
> [2] https://github.com/96boards-poplar/Documentation
> [3] https://github.com/pierrchen/u-boot/commit/
> 8463e6177654026746161487d0f0bd8998bb7a5b
>
> Bin Chen (2):
>   parse the second area of android image
>   move booti_setup to arch/arm/lig/image.c
>
>  arch/arm/lib/Makefile  |  2 +-
>  arch/arm/lib/image.c   | 76 +
>  cmd/booti.c| 92 +++---
> 
>  common/image-android.c | 19 +++
>  include/image.h| 11 ++
>  5 files changed, 120 insertions(+), 80 deletions(-)
>  create mode 100644 arch/arm/lib/image.c
>
> --
> 2.15.0
>
>


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

Re: [U-Boot] [PATCH 2/2] Remove config_distro_defaults.h

[Tom Rini]

On Fri, Feb 02, 2018 at 02:37:11PM -0600, Adam Ford wrote:

> With the contents of config_distro_defaults.h migrated to Kconfig,
> we can remove this header file completely
> 
> Signed-off-by: Adam Ford 
> ---
>  include/config_distro_defaults.h| 16 

So, I have a problem.  In 1/2, and sadly, oops!, in other cases, we've
not been good about enforcing config_distro_defaults.h -> select X under
DISTRO_DEFAULTS entry in the top-level Kconfig.  Can you please re-do
1/2 so that it adds a select line during migration?  I think in general
there's likely been no functional loss (as I'd have noticed size
differences) but there is an ease of use loss (DISTRO_DEFAULTS should
get X/Y/Z for a new board).  Thanks!

-- 
Tom


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

[U-Boot] [PATCH] doc: watchdog: Remove Blackfin related documentation entry

[Lukasz Majewski]

This commit cleans up the README.watchdog by removing the reminescent of
ADI's Blackfin architecture removed some time ago.

Signed-off-by: Lukasz Majewski 
---

 doc/README.watchdog | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/doc/README.watchdog b/doc/README.watchdog
index b66fd6cb8a..7097c8766b 100644
--- a/doc/README.watchdog
+++ b/doc/README.watchdog
@@ -31,6 +31,3 @@ CONFIG_IMX_WATCHDOG
 
 CONFIG_XILINX_TB_WATCHDOG
Available for Xilinx Axi platforms to service timebase watchdog timer.
-
-CONFIG_BFIN_WATCHDOG
-   Available for bf5xx and bf6xx to service the watchdog.
-- 
2.11.0

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

Re: [U-Boot] [PATCH 1/4] arm: imx: mx23: Move MX23 selection to Kconfig

[Fabio Estevam]

On Mon, Feb 5, 2018 at 7:33 PM, Stefan Agner  wrote:

> --- a/arch/arm/mach-imx/mx2/Kconfig
> +++ b/arch/arm/mach-imx/mx2/Kconfig

mx23 and mx28 fits better into /arch/arm/mach-imx/mxs/Kconfig

> @@ -1,3 +1,39 @@
> +if ARCH_MX23
> +
> +config MX23
> +   bool
> +   default y
> +
> +choice
> +   prompt "MX25 board select"

Wrong SoC. This should be MX23 :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] MAINTAINERS: board: qcom: db410c, db820c: update email.

[Tom Rini]

On Sun, Feb 04, 2018 at 10:35:08AM +0100, Jorge Ramirez-Ortiz wrote:

> Update email address.
> 
> Signed-off-by: Jorge Ramirez-Ortiz 

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, 3/4] travis.yml: fix 'set +e' in build script

[Tom Rini]

On Fri, Jan 26, 2018 at 04:31:06PM +0100, Daniel Schwierzeck wrote:

> The build script should not manipulate shell flags (especially '-e').
> A non-zero exit value can also be catched with 'cmd || ret=$?'.
> 
> Signed-off-by: Daniel Schwierzeck 
> Reviewed-by: Tom Rini 

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, 2/4] buildman: add option -E for treating compiler warnings as errors

[Tom Rini]

On Fri, Jan 26, 2018 at 04:31:05PM +0100, Daniel Schwierzeck wrote:

> Add a new option '-E' for treating all compiler warnings as errors.
> Eventually this will pass 'KCFLAGS=-Werror' to Kbuild.
> 
> Signed-off-by: Daniel Schwierzeck 

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, 1/4] README: add doc for how to supply user specific compiler flags to Kbuild

[Tom Rini]

On Fri, Jan 26, 2018 at 04:31:04PM +0100, Daniel Schwierzeck wrote:

> Probably not all users are aware of this possibility, thus add a
> pointer to the README. Also add a useful example.
> 
> Signed-off-by: Daniel Schwierzeck 

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, 4/4] travis.yml: run buildman with option -E

[Tom Rini]

On Fri, Jan 26, 2018 at 04:31:07PM +0100, Daniel Schwierzeck wrote:

> This forces all compiler warnings to be treated as errors.
> 
> Signed-off-by: Daniel Schwierzeck 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] usb: dwc2: make casts of ep->dma_buf consistent

[Tom Rini]

On Mon, Feb 05, 2018 at 09:54:51AM -0500, Tom Rini wrote:

> In most places in the code we cast this to an unsigned long, but in one
> place we cast to an unsigned int.  For consistency and to fix a warning
> on 64bit targets, always cast this to unsigned long.  For the long term
> we should however change the declaration of dma_buf.
> 
> Cc: Philipp Tomsich 
> Acked-by: Lukasz Majewski 
> Acked-by: Marek Vasut 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] MAINTAINERS: Update email address for Maxime Ripard

[Tom Rini]

On Fri, Feb 02, 2018 at 09:45:23PM +0100, Maxime Ripard wrote:

> Free Electrons is no more and is now known as Bootlin, change my email
> address accordingly.
> 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH V2] Convert CONFIG_APBH_DMA et al to Kconfig

[stefan]

On 05.02.2018 14:33, Adam Ford wrote:
> This converts the following to Kconfig:
>CONFIG_APBH_DMA
>CONFIG_APBH_DMA_BURST
>CONFIG_APBH_DMA_BURST8
> 
> Signed-off-by: Adam Ford 
> ---
> Changes in V2:
> Rebase on [U-Boot,v2,1/6] Convert CONFIG_NAND_MXS to Kconfig
> Make the NAND controller in MX6 MX7 autoselect the DMA options
> 
>  configs/bg0900_defconfig|  1 +
>  configs/mx23_olinuxino_defconfig|  1 +
>  configs/mx23evk_defconfig   |  1 +
>  configs/mx28evk_auart_console_defconfig |  3 +--
>  configs/mx28evk_defconfig   |  3 +--
>  configs/mx28evk_spi_defconfig   |  3 +--
>  configs/sansa_fuze_plus_defconfig   |  1 +
>  configs/sc_sps_1_defconfig  |  1 +
>  configs/ts4600_defconfig|  1 +
>  configs/xfi3_defconfig  |  1 +

Just sent out a patchset ("arm: imx: convert MX23/28 and MXS NAND to
Kconfig") which should properly convert NAND MXS to Kconfig. Can you
rebase again? It really lead to no defconfig changes.

Can you add me to cc in v3? Sorry for the hassle.

--
Stefan


>  drivers/dma/Kconfig | 14 ++
>  drivers/mtd/nand/Kconfig|  3 +++
>  include/configs/aristainetos-common.h   |  3 ---
>  include/configs/cm_fx6.h|  3 ---
>  include/configs/colibri_imx7.h  |  3 ---
>  include/configs/gw_ventana.h|  3 ---
>  include/configs/imx6-engicam.h  |  4 
>  include/configs/imx6_logic.h|  3 ---
>  include/configs/mx6sabreauto.h  |  3 ---
>  include/configs/mx6sxsabreauto.h|  3 ---
>  include/configs/mx7dsabresd.h   |  3 ---
>  include/configs/mxs.h   |  1 -
>  include/configs/pcm058.h|  3 ---
>  include/configs/pfla02.h|  3 ---
>  include/configs/platinum.h  |  3 ---
>  include/configs/titanium.h  |  3 ---
>  scripts/config_whitelist.txt|  3 ---
>  27 files changed, 27 insertions(+), 50 deletions(-)
> 
> diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig
> index 72616ae..7314eff 100644
> --- a/configs/bg0900_defconfig
> +++ b/configs/bg0900_defconfig
> @@ -25,6 +25,7 @@ CONFIG_CMD_MII=y
>  CONFIG_CMD_PING=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_DOS_PARTITION=y
> +CONFIG_APBH_DMA=y
>  # CONFIG_MMC is not set
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
> diff --git a/configs/mx23_olinuxino_defconfig 
> b/configs/mx23_olinuxino_defconfig
> index 628c11d..2c80c3b 100644
> --- a/configs/mx23_olinuxino_defconfig
> +++ b/configs/mx23_olinuxino_defconfig
> @@ -20,6 +20,7 @@ CONFIG_CMD_CACHE=y
>  CONFIG_CMD_EXT2=y
>  CONFIG_CMD_FAT=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_LED_STATUS=y
>  CONFIG_LED_STATUS_GPIO=y
>  CONFIG_LED_STATUS0=y
> diff --git a/configs/mx23evk_defconfig b/configs/mx23evk_defconfig
> index 6ad7f2c..09f3611 100644
> --- a/configs/mx23evk_defconfig
> +++ b/configs/mx23evk_defconfig
> @@ -24,6 +24,7 @@ CONFIG_CMD_CACHE=y
>  CONFIG_CMD_EXT2=y
>  CONFIG_CMD_FAT=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_MMC_MXS=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
> diff --git a/configs/mx28evk_auart_console_defconfig
> b/configs/mx28evk_auart_console_defconfig
> index 0927333..7bdb905 100644
> --- a/configs/mx28evk_auart_console_defconfig
> +++ b/configs/mx28evk_auart_console_defconfig
> @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND_TRIMFFS=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_SPI=y
>  CONFIG_CMD_USB=y
> @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_MMC_MXS=y
>  CONFIG_NAND=y
> -CONFIG_NAND_MXS=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SST=y
>  CONFIG_USB=y
> diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
> index 21d01bc..d36ad0e 100644
> --- a/configs/mx28evk_defconfig
> +++ b/configs/mx28evk_defconfig
> @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND_TRIMFFS=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_SPI=y
>  CONFIG_CMD_USB=y
> @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_MMC_MXS=y
>  CONFIG_NAND=y
> -CONFIG_NAND_MXS=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SST=y
>  CONFIG_USB=y
> diff --git a/configs/mx28evk_spi_defconfig b/configs/mx28evk_spi_defconfig
> index dab5394..7bf1d6e 100644
> --- a/configs/mx28evk_spi_defconfig
> +++ 

[U-Boot] [PATCH 4/4] Convert CONFIG_NAND_MXS to Kconfig

[Stefan Agner]

From: Stefan Agner 

This converts CONFIG_NAND_MXS to Kconfig.

Signed-off-by: Stefan Agner 
---

 configs/apx4devkit_defconfig|  3 ++-
 configs/aristainetos2_defconfig |  3 ++-
 configs/aristainetos2b_defconfig|  3 ++-
 configs/aristainetos_defconfig  |  3 ++-
 configs/bg0900_defconfig|  3 ++-
 configs/cm_fx6_defconfig| 11 ++-
 configs/colibri_imx7_defconfig  |  3 ++-
 configs/gwventana_nand_defconfig|  3 ++-
 configs/m28evk_defconfig|  3 ++-
 configs/mx28evk_auart_console_defconfig |  3 ++-
 configs/mx28evk_defconfig   |  3 ++-
 configs/mx28evk_nand_defconfig  |  3 ++-
 configs/mx28evk_spi_defconfig   |  3 ++-
 configs/mx6sabreauto_defconfig  |  3 ++-
 configs/mx6sxsabreauto_defconfig|  3 ++-
 configs/pcm058_defconfig|  3 ++-
 configs/pfla02_defconfig|  3 +++
 configs/platinum_picon_defconfig|  3 ++-
 configs/platinum_titanium_defconfig |  3 ++-
 configs/titanium_defconfig  |  3 ++-
 drivers/mtd/nand/Kconfig|  2 +-
 include/configs/aristainetos-common.h   |  1 -
 include/configs/cm_fx6.h|  1 -
 include/configs/colibri_imx7.h  |  2 --
 include/configs/gw_ventana.h|  1 -
 include/configs/mx6sabreauto.h  |  1 -
 include/configs/mx6sxsabreauto.h|  1 -
 include/configs/mxs.h   |  1 -
 include/configs/pcm058.h|  1 -
 include/configs/pfla02.h|  1 -
 include/configs/platinum.h  |  1 -
 include/configs/titanium.h  |  1 -
 32 files changed, 42 insertions(+), 40 deletions(-)

diff --git a/configs/apx4devkit_defconfig b/configs/apx4devkit_defconfig
index 6d57bb2dbc..260ddb2194 100644
--- a/configs/apx4devkit_defconfig
+++ b/configs/apx4devkit_defconfig
@@ -14,7 +14,6 @@ CONFIG_SPL=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_MMC=y
-CONFIG_CMD_NAND=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
@@ -28,6 +27,8 @@ 
CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_MMC_MXS=y
+CONFIG_NAND=y
+CONFIG_NAND_MXS=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig
index 288dab0d3c..c0daed6b22 100644
--- a/configs/aristainetos2_defconfig
+++ b/configs/aristainetos2_defconfig
@@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
-CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
@@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NAND=y
+CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_MTD_UBI_FASTMAP=y
diff --git a/configs/aristainetos2b_defconfig b/configs/aristainetos2b_defconfig
index 115ae07ad6..fbb2c1c38d 100644
--- a/configs/aristainetos2b_defconfig
+++ b/configs/aristainetos2b_defconfig
@@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
-CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
@@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NAND=y
+CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_MTD_UBI_FASTMAP=y
diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig
index cad8b4af8a..13f4d6eb52 100644
--- a/configs/aristainetos_defconfig
+++ b/configs/aristainetos_defconfig
@@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
-CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
@@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NAND=y
+CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_MTD_UBI_FASTMAP=y
diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig
index ed0448d55d..602eb60808 100644
--- a/configs/bg0900_defconfig
+++ b/configs/bg0900_defconfig
@@ -17,7 +17,6 @@ CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
-CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
@@ -27,6 +26,8 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_DOS_PARTITION=y
 # CONFIG_MMC is not set
+CONFIG_NAND=y
+CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig
index 6b1c0a823c..995baabd5d 100644
--- a/configs/cm_fx6_defconfig
+++ b/configs/cm_fx6_defconfig
@@ -20,9 +20,7 @@ CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run 
legacy_bootcmd"
 CONFIG_SPL=y
 

[U-Boot] [PATCH 3/4] spl: use ARCH_MX23/28 to specify SPL_LDSCRIPT

[Stefan Agner]

From: Stefan Agner 

Simplify SPL_LDSCRIPT config by using the new arch Kconfig
configurations ARCH_MX23 and ARCH_MX28.

Signed-off-by: Stefan Agner 
---

 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f4301f18ce..2330c83d74 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1324,7 +1324,7 @@ source "arch/arm/Kconfig.debug"
 endmenu
 
 config SPL_LDSCRIPT
-default "arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds" if 
TARGET_APX4DEVKIT || TARGET_BG0900 || TARGET_M28EVK || TARGET_MX23_OLINUXINO || 
TARGET_MX23EVK || TARGET_MX28EVK || TARGET_SANSA_FUZE_PLUS || TARGET_SC_SPS_1 
|| TARGET_TS4600 || TARGET_XFI3
+default "arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds" if ARCH_MX23 || 
ARCH_MX28
 default "arch/arm/cpu/arm1136/u-boot-spl.lds" if CPU_ARM1136
default "arch/arm/cpu/armv8/u-boot-spl.lds" if ARM64
 
-- 
2.16.1

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

[U-Boot] [PATCH 2/4] arm: imx: mx28: Move MX28 selection to Kconfig

[Stefan Agner]

From: Stefan Agner 

The motivation for moving MX28 selection to Kconfig is to be able
to better handle NAND MXS selection through Kconfig.

This selection method also aligns with the way other i.MX SoCs are
selected in U-Boot.

Signed-off-by: Stefan Agner 
---

 arch/arm/Kconfig| 49 -
 arch/arm/mach-imx/mx2/Kconfig   | 43 +
 configs/apx4devkit_defconfig|  3 +-
 configs/bg0900_defconfig|  3 +-
 configs/m28evk_defconfig|  3 +-
 configs/mx28evk_auart_console_defconfig |  3 +-
 configs/mx28evk_defconfig   |  3 +-
 configs/mx28evk_nand_defconfig  |  3 +-
 configs/mx28evk_spi_defconfig   |  3 +-
 configs/sc_sps_1_defconfig  |  3 +-
 configs/ts4600_defconfig|  3 +-
 include/configs/apx4devkit.h|  1 -
 include/configs/bg0900.h|  3 --
 include/configs/m28evk.h|  1 -
 include/configs/mx28evk.h   |  1 -
 include/configs/sc_sps_1.h  |  1 -
 include/configs/ts4600.h|  3 --
 scripts/config_whitelist.txt|  1 -
 18 files changed, 67 insertions(+), 63 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b963a5102e..f4301f18ce 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -396,37 +396,6 @@ config TARGET_APF27
select CPU_ARM926EJS
select SUPPORT_SPL
 
-config TARGET_APX4DEVKIT
-   bool "Support apx4devkit"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select PL011_SERIAL
-
-config TARGET_M28EVK
-   bool "Support m28evk"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select PL011_SERIAL
-
-config TARGET_MX28EVK
-   bool "Support mx28evk"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select BOARD_EARLY_INIT_F
-   select PL011_SERIAL
-
-config TARGET_BG0900
-   bool "Support bg0900"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select PL011_SERIAL
-
-config TARGET_SC_SPS_1
-   bool "Support sc_sps_1"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select PL011_SERIAL
-
 config ORION5X
bool "Marvell Orion"
select CPU_ARM926EJS
@@ -650,6 +619,12 @@ config ARCH_MX25
bool "NXP MX25"
select CPU_ARM926EJS
 
+config ARCH_MX28
+   bool "NXP i.MX28 family"
+   select CPU_ARM926EJS
+   select PL011_SERIAL
+   select SUPPORT_SPL
+
 config ARCH_MX7ULP
 bool "NXP MX7ULP"
 select CPU_V7
@@ -767,12 +742,6 @@ config ARCH_SUNXI
imply SPL_SERIAL_SUPPORT
imply USB_GADGET
 
-config TARGET_TS4600
-   bool "Support TS4600"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select PL011_SERIAL
-
 config ARCH_VF610
bool "Freescale Vybrid"
select CPU_V7
@@ -1292,7 +1261,6 @@ source "arch/arm/cpu/armv8/Kconfig"
 
 source "arch/arm/mach-imx/Kconfig"
 
-source "board/aries/m28evk/Kconfig"
 source "board/bosch/shc/Kconfig"
 source "board/CarMediaLab/flea3/Kconfig"
 source "board/Marvell/aspenite/Kconfig"
@@ -1300,7 +1268,6 @@ source "board/Marvell/gplugd/Kconfig"
 source "board/armadeus/apf27/Kconfig"
 source "board/armltd/vexpress/Kconfig"
 source "board/armltd/vexpress64/Kconfig"
-source "board/bluegiga/apx4devkit/Kconfig"
 source "board/broadcom/bcm23550_w1d/Kconfig"
 source "board/broadcom/bcm28155_ap/Kconfig"
 source "board/broadcom/bcmcygnus/Kconfig"
@@ -1323,7 +1290,6 @@ source "board/freescale/ls1046ardb/Kconfig"
 source "board/freescale/ls1012aqds/Kconfig"
 source "board/freescale/ls1012ardb/Kconfig"
 source "board/freescale/ls1012afrdm/Kconfig"
-source "board/freescale/mx28evk/Kconfig"
 source "board/freescale/mx31ads/Kconfig"
 source "board/freescale/mx31pdk/Kconfig"
 source "board/freescale/mx35pdk/Kconfig"
@@ -1337,8 +1303,6 @@ source "board/hisilicon/poplar/Kconfig"
 source "board/imx31_phycore/Kconfig"
 source "board/isee/igep003x/Kconfig"
 source "board/phytec/pcm051/Kconfig"
-source "board/ppcag/bg0900/Kconfig"
-source "board/schulercontrol/sc_sps_1/Kconfig"
 source "board/silica/pengwyn/Kconfig"
 source "board/spear/spear300/Kconfig"
 source "board/spear/spear310/Kconfig"
@@ -1350,7 +1314,6 @@ source "board/tcl/sl50/Kconfig"
 source "board/birdland/bav335x/Kconfig"
 source "board/timll/devkit3250/Kconfig"
 source "board/toradex/colibri_pxa270/Kconfig"
-source "board/technologic/ts4600/Kconfig"
 source "board/vscom/baltos/Kconfig"
 source "board/woodburn/Kconfig"
 source "board/work-microwave/work_92105/Kconfig"
diff --git a/arch/arm/mach-imx/mx2/Kconfig b/arch/arm/mach-imx/mx2/Kconfig
index 7d70ee2971..e54eb55838 100644
--- a/arch/arm/mach-imx/mx2/Kconfig
+++ b/arch/arm/mach-imx/mx2/Kconfig
@@ -64,3 +64,46 @@ source "board/freescale/mx25pdk/Kconfig"
 source "board/syteco/zmx25/Kconfig"
 
 endif
+
+if ARCH_MX28
+
+config MX28
+   bool
+

[U-Boot] [PATCH 1/4] arm: imx: mx23: Move MX23 selection to Kconfig

[Stefan Agner]

From: Stefan Agner 

The motivation for moving MX23 selection to Kconfig is to be able
to better handle NAND MXS selection through Kconfig.

This selection method also aligns with the way other i.MX SoCs are
selected in U-Boot.

Signed-off-by: Stefan Agner 
---

 arch/arm/Kconfig  | 36 ++--
 arch/arm/mach-imx/mx2/Kconfig | 36 
 configs/mx23_olinuxino_defconfig  |  3 ++-
 configs/mx23evk_defconfig |  3 ++-
 configs/sansa_fuze_plus_defconfig |  1 +
 configs/xfi3_defconfig|  3 ++-
 include/configs/mx23_olinuxino.h  |  1 -
 include/configs/mx23evk.h |  1 -
 include/configs/sansa_fuze_plus.h |  3 ---
 include/configs/xfi3.h|  3 ---
 scripts/config_whitelist.txt  |  1 -
 11 files changed, 49 insertions(+), 42 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 880a56ba90..b963a5102e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -402,25 +402,12 @@ config TARGET_APX4DEVKIT
select SUPPORT_SPL
select PL011_SERIAL
 
-config TARGET_XFI3
-   bool "Support xfi3"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select PL011_SERIAL
-
 config TARGET_M28EVK
bool "Support m28evk"
select CPU_ARM926EJS
select SUPPORT_SPL
select PL011_SERIAL
 
-config TARGET_MX23EVK
-   bool "Support mx23evk"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select BOARD_EARLY_INIT_F
-   select PL011_SERIAL
-
 config TARGET_MX28EVK
bool "Support mx28evk"
select CPU_ARM926EJS
@@ -428,25 +415,12 @@ config TARGET_MX28EVK
select BOARD_EARLY_INIT_F
select PL011_SERIAL
 
-config TARGET_MX23_OLINUXINO
-   bool "Support mx23_olinuxino"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select BOARD_EARLY_INIT_F
-   select PL011_SERIAL
-
 config TARGET_BG0900
bool "Support bg0900"
select CPU_ARM926EJS
select SUPPORT_SPL
select PL011_SERIAL
 
-config TARGET_SANSA_FUZE_PLUS
-   bool "Support sansa_fuze_plus"
-   select CPU_ARM926EJS
-   select SUPPORT_SPL
-   select PL011_SERIAL
-
 config TARGET_SC_SPS_1
bool "Support sc_sps_1"
select CPU_ARM926EJS
@@ -666,6 +640,12 @@ config ARCH_MX8M
select DM
select SUPPORT_SPL
 
+config ARCH_MX23
+   bool "NXP i.MX23 family"
+   select CPU_ARM926EJS
+   select PL011_SERIAL
+   select SUPPORT_SPL
+
 config ARCH_MX25
bool "NXP MX25"
select CPU_ARM926EJS
@@ -1328,7 +1308,6 @@ source "board/broadcom/bcmnsp/Kconfig"
 source "board/broadcom/bcmns2/Kconfig"
 source "board/cavium/thunderx/Kconfig"
 source "board/cirrus/edb93xx/Kconfig"
-source "board/creative/xfi3/Kconfig"
 source "board/eets/pdu001/Kconfig"
 source "board/freescale/ls2080a/Kconfig"
 source "board/freescale/ls2080aqds/Kconfig"
@@ -1344,7 +1323,6 @@ source "board/freescale/ls1046ardb/Kconfig"
 source "board/freescale/ls1012aqds/Kconfig"
 source "board/freescale/ls1012ardb/Kconfig"
 source "board/freescale/ls1012afrdm/Kconfig"
-source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
 source "board/freescale/mx31ads/Kconfig"
 source "board/freescale/mx31pdk/Kconfig"
@@ -1358,10 +1336,8 @@ source "board/hisilicon/hikey/Kconfig"
 source "board/hisilicon/poplar/Kconfig"
 source "board/imx31_phycore/Kconfig"
 source "board/isee/igep003x/Kconfig"
-source "board/olimex/mx23_olinuxino/Kconfig"
 source "board/phytec/pcm051/Kconfig"
 source "board/ppcag/bg0900/Kconfig"
-source "board/sandisk/sansa_fuze_plus/Kconfig"
 source "board/schulercontrol/sc_sps_1/Kconfig"
 source "board/silica/pengwyn/Kconfig"
 source "board/spear/spear300/Kconfig"
diff --git a/arch/arm/mach-imx/mx2/Kconfig b/arch/arm/mach-imx/mx2/Kconfig
index ea308fccab..7d70ee2971 100644
--- a/arch/arm/mach-imx/mx2/Kconfig
+++ b/arch/arm/mach-imx/mx2/Kconfig
@@ -1,3 +1,39 @@
+if ARCH_MX23
+
+config MX23
+   bool
+   default y
+
+choice
+   prompt "MX25 board select"
+   optional
+
+config TARGET_MX23_OLINUXINO
+   bool "Support mx23_olinuxino"
+   select BOARD_EARLY_INIT_F
+
+config TARGET_MX23EVK
+   bool "Support mx23evk"
+   select BOARD_EARLY_INIT_F
+
+config TARGET_SANSA_FUZE_PLUS
+   bool "Support sansa_fuze_plus"
+
+config TARGET_XFI3
+   bool "Support xfi3"
+
+endchoice
+
+config SYS_SOC
+   default "mxs"
+
+source "board/olimex/mx23_olinuxino/Kconfig"
+source "board/freescale/mx23evk/Kconfig"
+source "board/sandisk/sansa_fuze_plus/Kconfig"
+source "board/creative/xfi3/Kconfig"
+
+endif
+
 if ARCH_MX25
 
 config MX25
diff --git a/configs/mx23_olinuxino_defconfig b/configs/mx23_olinuxino_defconfig
index 628c11d851..d70ca52da2 100644
--- a/configs/mx23_olinuxino_defconfig
+++ b/configs/mx23_olinuxino_defconfig
@@ -1,8 +1,9 @@
 CONFIG_ARM=y
-CONFIG_TARGET_MX23_OLINUXINO=y

[U-Boot] [PATCH 0/4] arm: imx: convert MX23/28 and MXS NAND to Kconfig

[Stefan Agner]

From: Stefan Agner 

This converts i.MX23/28 to Kconfig. This helps to properly
add dependencies for GPMI NAND (NAND_MXS) configs.
Patch 4 is from a previous patchset "mtd: nand: mxs_nand:
improve ECC support".

--
Stefan


Stefan Agner (4):
  arm: imx: mx23: Move MX23 selection to Kconfig
  arm: imx: mx28: Move MX28 selection to Kconfig
  spl: use ARCH_MX23/28 to specify SPL_LDSCRIPT
  Convert CONFIG_NAND_MXS to Kconfig

 arch/arm/Kconfig| 87 +
 arch/arm/mach-imx/mx2/Kconfig   | 79 ++
 configs/apx4devkit_defconfig|  6 ++-
 configs/aristainetos2_defconfig |  3 +-
 configs/aristainetos2b_defconfig|  3 +-
 configs/aristainetos_defconfig  |  3 +-
 configs/bg0900_defconfig|  6 ++-
 configs/cm_fx6_defconfig| 11 +
 configs/colibri_imx7_defconfig  |  3 +-
 configs/gwventana_nand_defconfig|  3 +-
 configs/m28evk_defconfig|  6 ++-
 configs/mx23_olinuxino_defconfig|  3 +-
 configs/mx23evk_defconfig   |  3 +-
 configs/mx28evk_auart_console_defconfig |  6 ++-
 configs/mx28evk_defconfig   |  6 ++-
 configs/mx28evk_nand_defconfig  |  6 ++-
 configs/mx28evk_spi_defconfig   |  6 ++-
 configs/mx6sabreauto_defconfig  |  3 +-
 configs/mx6sxsabreauto_defconfig|  3 +-
 configs/pcm058_defconfig|  3 +-
 configs/pfla02_defconfig|  3 ++
 configs/platinum_picon_defconfig|  3 +-
 configs/platinum_titanium_defconfig |  3 +-
 configs/sansa_fuze_plus_defconfig   |  1 +
 configs/sc_sps_1_defconfig  |  3 +-
 configs/titanium_defconfig  |  3 +-
 configs/ts4600_defconfig|  3 +-
 configs/xfi3_defconfig  |  3 +-
 drivers/mtd/nand/Kconfig|  2 +-
 include/configs/apx4devkit.h|  1 -
 include/configs/aristainetos-common.h   |  1 -
 include/configs/bg0900.h|  3 --
 include/configs/cm_fx6.h|  1 -
 include/configs/colibri_imx7.h  |  2 -
 include/configs/gw_ventana.h|  1 -
 include/configs/m28evk.h|  1 -
 include/configs/mx23_olinuxino.h|  1 -
 include/configs/mx23evk.h   |  1 -
 include/configs/mx28evk.h   |  1 -
 include/configs/mx6sabreauto.h  |  1 -
 include/configs/mx6sxsabreauto.h|  1 -
 include/configs/mxs.h   |  1 -
 include/configs/pcm058.h|  1 -
 include/configs/pfla02.h|  1 -
 include/configs/platinum.h  |  1 -
 include/configs/sansa_fuze_plus.h   |  3 --
 include/configs/sc_sps_1.h  |  1 -
 include/configs/titanium.h  |  1 -
 include/configs/ts4600.h|  3 --
 include/configs/xfi3.h  |  3 --
 scripts/config_whitelist.txt|  2 -
 51 files changed, 159 insertions(+), 146 deletions(-)

-- 
2.16.1

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

Re: [U-Boot] [PATCH v2 1/6] Convert CONFIG_NAND_MXS to Kconfig

[stefan]

On 02.02.2018 22:44, Stefan Agner wrote:
> From: Stefan Agner 
> 
> This converts CONFIG_NAND_MXS to Kconfig.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
> Changes in v2:
> - Extend the patchset with "Convert CONFIG_NAND_MXS to Kconfig" patch
> 
>  configs/apx4devkit_defconfig|  3 ++-
>  configs/aristainetos2_defconfig |  3 ++-
>  configs/aristainetos2b_defconfig|  3 ++-
>  configs/aristainetos_defconfig  |  3 ++-
>  configs/cm_fx6_defconfig| 11 ++-
>  configs/colibri_imx7_defconfig  |  3 ++-
>  configs/gwventana_nand_defconfig|  3 ++-
>  configs/m28evk_defconfig|  3 ++-
>  configs/mx28evk_auart_console_defconfig |  3 ++-
>  configs/mx28evk_defconfig   |  3 ++-
>  configs/mx28evk_nand_defconfig  |  3 ++-
>  configs/mx28evk_spi_defconfig   |  3 ++-
>  configs/mx6sabreauto_defconfig  |  3 ++-
>  configs/mx6sxsabreauto_defconfig|  3 ++-
>  configs/pcm058_defconfig|  3 ++-
>  configs/pfla02_defconfig|  3 +++
>  configs/platinum_picon_defconfig|  3 ++-
>  configs/platinum_titanium_defconfig |  3 ++-
>  configs/titanium_defconfig  |  3 ++-
>  include/configs/aristainetos-common.h   |  1 -
>  include/configs/cm_fx6.h|  1 -
>  include/configs/colibri_imx7.h  |  2 --
>  include/configs/gw_ventana.h|  1 -
>  include/configs/mx6sabreauto.h  |  1 -
>  include/configs/mx6sxsabreauto.h|  1 -
>  include/configs/mxs.h   |  1 -
>  include/configs/pcm058.h|  1 -
>  include/configs/pfla02.h|  1 -
>  include/configs/platinum.h  |  1 -
>  include/configs/titanium.h  |  1 -
>  30 files changed, 39 insertions(+), 38 deletions(-)
> 
> diff --git a/configs/apx4devkit_defconfig b/configs/apx4devkit_defconfig
> index 47a4ee9e26..cc6da42066 100644
> --- a/configs/apx4devkit_defconfig
> +++ b/configs/apx4devkit_defconfig
> @@ -13,7 +13,6 @@ CONFIG_SPL=y
>  CONFIG_HUSH_PARSER=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND=y
>  CONFIG_CMD_USB=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_CMD_DHCP=y
> @@ -27,6 +26,8 @@
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_NAND=y
>  CONFIG_MMC_MXS=y
> +CONFIG_NAND=y
> +CONFIG_NAND_MXS=y

This needs NAND_MXS to be selectable for MX23/28 architectures, however
with the current Kconfig this is not possible. I have a patchset ready
which converts MX23/28 to Kconfig.. I will move this patch ontop of that
patchset, and send a v3 for the driver related changes.

--
Stefan

>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_STORAGE=y
> diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig
> index 288dab0d3c..c0daed6b22 100644
> --- a/configs/aristainetos2_defconfig
> +++ b/configs/aristainetos2_defconfig
> @@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND=y
>  CONFIG_CMD_NAND_TRIMFFS=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
> @@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_NAND=y
> +CONFIG_NAND_MXS=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_MTD_UBI_FASTMAP=y
> diff --git a/configs/aristainetos2b_defconfig 
> b/configs/aristainetos2b_defconfig
> index 115ae07ad6..fbb2c1c38d 100644
> --- a/configs/aristainetos2b_defconfig
> +++ b/configs/aristainetos2b_defconfig
> @@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND=y
>  CONFIG_CMD_NAND_TRIMFFS=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
> @@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_NAND=y
> +CONFIG_NAND_MXS=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_MTD_UBI_FASTMAP=y
> diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig
> index cad8b4af8a..13f4d6eb52 100644
> --- a/configs/aristainetos_defconfig
> +++ b/configs/aristainetos_defconfig
> @@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND=y
>  CONFIG_CMD_NAND_TRIMFFS=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
> @@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_NAND=y
> +CONFIG_NAND_MXS=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_MTD_UBI_FASTMAP=y
> diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig
> index 6b1c0a823c..995baabd5d 100644
> --- a/configs/cm_fx6_defconfig
> +++ b/configs/cm_fx6_defconfig
> @@ -20,9 +20,7 @@ CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd;
> run legacy_bootcmd"
>  

Re: [U-Boot] [PATCH 1/1] Broadwell-DE Implementation

[vnktux]

Hi Peter,

Thanks a lot, your help was really precious! I just tested your fix on two 
platforms, one with memory down and one with DIMM. U-Boot works on both of them 
and the booting time is around 17 seconds. Now I will try to fix some minor 
errors that U-Boot report on the shell and then I will definetly submit a new 
patch. (If I manage to understand how to properly submit one). Thanks again!

Best regards,
Vincenzo

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

Re: [U-Boot] [PATCH V2] Convert CONFIG_APBH_DMA et al to Kconfig

[stefan]

On 05.02.2018 14:33, Adam Ford wrote:
> This converts the following to Kconfig:
>CONFIG_APBH_DMA
>CONFIG_APBH_DMA_BURST
>CONFIG_APBH_DMA_BURST8
> 
> Signed-off-by: Adam Ford 
> ---
> Changes in V2:
> Rebase on [U-Boot,v2,1/6] Convert CONFIG_NAND_MXS to Kconfig
> Make the NAND controller in MX6 MX7 autoselect the DMA options
> 
>  configs/bg0900_defconfig|  1 +
>  configs/mx23_olinuxino_defconfig|  1 +
>  configs/mx23evk_defconfig   |  1 +
>  configs/mx28evk_auart_console_defconfig |  3 +--
>  configs/mx28evk_defconfig   |  3 +--
>  configs/mx28evk_spi_defconfig   |  3 +--
>  configs/sansa_fuze_plus_defconfig   |  1 +
>  configs/sc_sps_1_defconfig  |  1 +
>  configs/ts4600_defconfig|  1 +
>  configs/xfi3_defconfig  |  1 +

There should be really no defconfig change since CONFIG_NAND_MXS should
select CONFIG_APBH_DMA automatically.

It seems that my patchset did not handle i.MX 23/28 correctly. Will fix
this first.

>  drivers/dma/Kconfig | 14 ++
>  drivers/mtd/nand/Kconfig|  3 +++
>  include/configs/aristainetos-common.h   |  3 ---
>  include/configs/cm_fx6.h|  3 ---
>  include/configs/colibri_imx7.h  |  3 ---
>  include/configs/gw_ventana.h|  3 ---
>  include/configs/imx6-engicam.h  |  4 
>  include/configs/imx6_logic.h|  3 ---
>  include/configs/mx6sabreauto.h  |  3 ---
>  include/configs/mx6sxsabreauto.h|  3 ---
>  include/configs/mx7dsabresd.h   |  3 ---
>  include/configs/mxs.h   |  1 -
>  include/configs/pcm058.h|  3 ---
>  include/configs/pfla02.h|  3 ---
>  include/configs/platinum.h  |  3 ---
>  include/configs/titanium.h  |  3 ---
>  scripts/config_whitelist.txt|  3 ---
>  27 files changed, 27 insertions(+), 50 deletions(-)
> 
> diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig
> index 72616ae..7314eff 100644
> --- a/configs/bg0900_defconfig
> +++ b/configs/bg0900_defconfig
> @@ -25,6 +25,7 @@ CONFIG_CMD_MII=y
>  CONFIG_CMD_PING=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_DOS_PARTITION=y
> +CONFIG_APBH_DMA=y
>  # CONFIG_MMC is not set
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
> diff --git a/configs/mx23_olinuxino_defconfig 
> b/configs/mx23_olinuxino_defconfig
> index 628c11d..2c80c3b 100644
> --- a/configs/mx23_olinuxino_defconfig
> +++ b/configs/mx23_olinuxino_defconfig
> @@ -20,6 +20,7 @@ CONFIG_CMD_CACHE=y
>  CONFIG_CMD_EXT2=y
>  CONFIG_CMD_FAT=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_LED_STATUS=y
>  CONFIG_LED_STATUS_GPIO=y
>  CONFIG_LED_STATUS0=y
> diff --git a/configs/mx23evk_defconfig b/configs/mx23evk_defconfig
> index 6ad7f2c..09f3611 100644
> --- a/configs/mx23evk_defconfig
> +++ b/configs/mx23evk_defconfig
> @@ -24,6 +24,7 @@ CONFIG_CMD_CACHE=y
>  CONFIG_CMD_EXT2=y
>  CONFIG_CMD_FAT=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_MMC_MXS=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
> diff --git a/configs/mx28evk_auart_console_defconfig
> b/configs/mx28evk_auart_console_defconfig
> index 0927333..7bdb905 100644
> --- a/configs/mx28evk_auart_console_defconfig
> +++ b/configs/mx28evk_auart_console_defconfig
> @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND_TRIMFFS=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_SPI=y
>  CONFIG_CMD_USB=y
> @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_MMC_MXS=y
>  CONFIG_NAND=y
> -CONFIG_NAND_MXS=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SST=y
>  CONFIG_USB=y
> diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
> index 21d01bc..d36ad0e 100644
> --- a/configs/mx28evk_defconfig
> +++ b/configs/mx28evk_defconfig
> @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND_TRIMFFS=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_SPI=y
>  CONFIG_CMD_USB=y
> @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
>  CONFIG_MMC_MXS=y
>  CONFIG_NAND=y
> -CONFIG_NAND_MXS=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SST=y
>  CONFIG_USB=y
> diff --git a/configs/mx28evk_spi_defconfig b/configs/mx28evk_spi_defconfig
> index dab5394..7bf1d6e 100644
> --- a/configs/mx28evk_spi_defconfig
> +++ b/configs/mx28evk_spi_defconfig
> @@ -15,7 +15,6 @@ CONFIG_CMD_BOOTZ=y
>  # 

Re: [U-Boot] [PATCH 1/1][for V2018.03] efi_loader: do not use 2.0.5 as UEFI revision number

[Mark Kettenis]

> From: Heinrich Schuchardt 
> Date: Mon,  5 Feb 2018 18:04:21 +0100
> 
> Currently the UEFI revision number in the system table header is set to
> 2.0.5. This version number does not refer to any existing version of the
> UEFI standard.
> 
> Set the revision number to 2.7.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Heh.  I noticed this when I added code to OpenBSD/arm64 to print the
version number.  Didn't get around to submitting a diff yet.

Doesn't look like 2.7 has anything new in it that is mandatory, so I
guess it is as good as any version number out there.

Reviewed-by: Mark Kettenis 

> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 0fd272253d2..3b9184b3e24 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -2893,7 +2893,7 @@ static uint16_t __efi_runtime_data firmware_vendor[] = 
> L"Das U-Boot";
>  struct efi_system_table __efi_runtime_data systab = {
>   .hdr = {
>   .signature = EFI_SYSTEM_TABLE_SIGNATURE,
> - .revision = 0x20005, /* 2.5 */
> + .revision = 2 << 16 | 70, /* 2.7 */
>   .headersize = sizeof(struct efi_table_hdr),
>   },
>   .fw_vendor = (long)firmware_vendor,
> -- 
> 2.14.2
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: dwc2: Fix logic for setup of GUSBCFG->ULPI_UTMI_Sel bit

[Marek Vasut]

On 02/05/2018 07:18 PM, Alexey Brodkin wrote:
> Hi Marek,
> 
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Monday, February 5, 2018 4:23 PM
>> To: Alexey Brodkin ; u-boot@lists.denx.de
>> Subject: Re: [PATCH] usb: dwc2: Fix logic for setup of 
>> GUSBCFG->ULPI_UTMI_Sel bit
>>
>> On 02/02/2018 04:58 PM, Alexey Brodkin wrote:
>>> According to the databook "ULPI_UTMI_Sel" bit (#4) in GUSBCFG
>>> register selects between ULPI and UTMI+ interfaces such that:
>>>  0 - stands for UTMI+ interface
>>>  1 - stands for ULPI interface
>>>
>>> Currently implemented logic in the driver is incorrect because
>>> CONFIG_DWC2_PHY_TYPE is not a "bool" but instead this is an "enum"
>>> which starts from 0 in case of full-speed and is either 1 for
>>> UTMI or 2 for ULPI.
>>>
>>> In dwc2.h we have:
>>> -->8--
>>>  #define DWC2_PHY_TYPE_FS   0
>>>  #define DWC2_PHY_TYPE_UTMI 1
>>>  #define DWC2_PHY_TYPE_ULPI 2
>>>  #define CONFIG_DWC2_PHY_TYPE   DWC2_PHY_TYPE_UTMI
>>> -->8--
>>>
>>> And in dwc2.c we do "|= CONFIG_DWC2_PHY_TYPE << 4"
>>> effectively setting "ULPI_UTMI_Sel" bit for UTMI+ and
>>> what's even worse for ULMI we keep "ULPI_UTMI_Sel" zeroed
>>> while setting the next "FSIntf" bit (#5) unexpectedly selecting
>>> Full speed interface!
>>>
>>> Signed-off-by: Alexey Brodkin 
>>> Cc: Marek Vasut 
>>> ---
>>>  drivers/usb/host/dwc2.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
>>> index 784fcbdbd94f..29138a2579ab 100644
>>> --- a/drivers/usb/host/dwc2.c
>>> +++ b/drivers/usb/host/dwc2.c
>>> @@ -366,7 +366,9 @@ static void dwc_otg_core_init(struct dwc2_priv *priv)
>>>  * immediately after setting phyif.
>>>  */
>>> usbcfg &= ~(DWC2_GUSBCFG_ULPI_UTMI_SEL | DWC2_GUSBCFG_PHYIF);
>>> -   usbcfg |= CONFIG_DWC2_PHY_TYPE << DWC2_GUSBCFG_ULPI_UTMI_SEL_OFFSET;
>>
>> What happens if PHY type is set to FS or UTMI , won't that change the
>> behavior of this code ?
> 
> Well if you look a bit more at that driver you'll notice that
> [there're way too many ifdefs] FS-part is in a separate ifdef section
> so we don’t need to worry about it in HS-part :)

Do you want to clean it up ? :)

>>> +#if (CONFIG_DWC2_PHY_TYPE == DWC2_PHY_TYPE_ULPI)
>>> +   usbcfg |= DWC2_GUSBCFG_ULPI_UTMI_SEL;
>>> +#endif
>>>
>>> if (usbcfg & DWC2_GUSBCFG_ULPI_UTMI_SEL) {  /* ULPI interface */
>>
>> This condition should be tweaked, I think. You set the ULPI_UTMI_SEL bit
>> above and check for it here again, that's a bit odd.
> 
> Completely agree but again my intention was to move with very tiny steps
> Fixing one issue at a time such that heavy refactoring could be escaped...

I'd like this cleaned, this is really braindead. Feel free to send two
patches or squash it into one, I don't care, but this is just braindead.

> But I would agree that this driver definitely needs refactoring because of 
> those
> Configuration options, some incorrect checks etc. But I'd think it's still 
> better
> To have expectedly working code today (i.e. fix existing code) instead of 
> waiting
> for major rewrite sometime down the line.

I'm not debating that part, I'm just cranky about the weirdness above.

> -Alexey
> 


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

Re: [U-Boot] [PATCH] usb: dwc2: Rename CONFIG_DWC2_UTMI_PHY_WIDTH to CONFIG_DWC2_UTMI_WIDTH

[Marek Vasut]

On 02/05/2018 07:09 PM, Alexey Brodkin wrote:
> Hi Marek,
> 
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Monday, February 5, 2018 4:18 PM
>> To: Alexey Brodkin 
>> Cc: u-boot@lists.denx.de
>> Subject: Re: [PATCH] usb: dwc2: Rename CONFIG_DWC2_UTMI_PHY_WIDTH to 
>> CONFIG_DWC2_UTMI_WIDTH
>>
>> On 02/01/2018 03:53 PM, Alexey Brodkin wrote:
>>> Hi Marek,
>>>
>>> On Wed, 2018-01-31 at 16:13 +0100, Marek Vasut wrote:
 On 01/31/2018 03:56 PM, Alexey Brodkin wrote:
> For some reason from day one we used to have both CONFIG_DWC2_UTMI_WIDTH
> mentioned in dwc2.h and in scripts/config_whitelist.txt but never really 
> used
> and CONFIG_DWC2_UTMI_PHY_WIDTH used in real code in dwc2.c (but never
> defined).
>
> Moreover even though CONFIG_DWC2_UTMI_WIDTH might be either 8 or 16
> depending on hardware (and the same is said in a comment for it in
> dwc2.h) but then 8 is hardcoded in the header leaving no ability to
> override this value in board's configuration.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Marek Vasut 

 Applied, thanks.

 btw How the heck did that code ever even compile ?
>>>
>>> Well my change doesn't really fix anything in existing code
>>> except makes once check meaningful compared to dummy always negative
>>> as it was before :)
>>
>> Ha, now I see it.
>>
>>> I'd say it means the driver was not very widely used on different hardwares.
>>> Still it does work [at least] to some extent which is really nice.
>>
>> Probably. All this info should be pulled from DT anyway.
> 
> That's so true... but now when there're real users of this driver moving 
> stuff to
> Device tree is not that trivial:
> 1) We need to move there those options that are now "configured" via defines
> 2) We need to keep compatibility with Linux DT options for the same 
> controller otherwise we'll
> lose ability to use the same .dtb-s in both Linux and U-Boot.
> 
> I'm not saying it's not doable but it is not a one-liner unfortunately.

It should be done, soon. I'm not saying it's gonna be easy, but I don't
see it being hard either.

btw same should be done for the Linux driver.

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

Re: [U-Boot] [PATCH] usb: dwc2: Fix logic for setup of GUSBCFG->ULPI_UTMI_Sel bit

[Alexey Brodkin]

Hi Marek,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, February 5, 2018 4:23 PM
> To: Alexey Brodkin ; u-boot@lists.denx.de
> Subject: Re: [PATCH] usb: dwc2: Fix logic for setup of GUSBCFG->ULPI_UTMI_Sel 
> bit
> 
> On 02/02/2018 04:58 PM, Alexey Brodkin wrote:
> > According to the databook "ULPI_UTMI_Sel" bit (#4) in GUSBCFG
> > register selects between ULPI and UTMI+ interfaces such that:
> >  0 - stands for UTMI+ interface
> >  1 - stands for ULPI interface
> >
> > Currently implemented logic in the driver is incorrect because
> > CONFIG_DWC2_PHY_TYPE is not a "bool" but instead this is an "enum"
> > which starts from 0 in case of full-speed and is either 1 for
> > UTMI or 2 for ULPI.
> >
> > In dwc2.h we have:
> > -->8--
> >  #define DWC2_PHY_TYPE_FS   0
> >  #define DWC2_PHY_TYPE_UTMI 1
> >  #define DWC2_PHY_TYPE_ULPI 2
> >  #define CONFIG_DWC2_PHY_TYPE   DWC2_PHY_TYPE_UTMI
> > -->8--
> >
> > And in dwc2.c we do "|= CONFIG_DWC2_PHY_TYPE << 4"
> > effectively setting "ULPI_UTMI_Sel" bit for UTMI+ and
> > what's even worse for ULMI we keep "ULPI_UTMI_Sel" zeroed
> > while setting the next "FSIntf" bit (#5) unexpectedly selecting
> > Full speed interface!
> >
> > Signed-off-by: Alexey Brodkin 
> > Cc: Marek Vasut 
> > ---
> >  drivers/usb/host/dwc2.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> > index 784fcbdbd94f..29138a2579ab 100644
> > --- a/drivers/usb/host/dwc2.c
> > +++ b/drivers/usb/host/dwc2.c
> > @@ -366,7 +366,9 @@ static void dwc_otg_core_init(struct dwc2_priv *priv)
> >  * immediately after setting phyif.
> >  */
> > usbcfg &= ~(DWC2_GUSBCFG_ULPI_UTMI_SEL | DWC2_GUSBCFG_PHYIF);
> > -   usbcfg |= CONFIG_DWC2_PHY_TYPE << DWC2_GUSBCFG_ULPI_UTMI_SEL_OFFSET;
> 
> What happens if PHY type is set to FS or UTMI , won't that change the
> behavior of this code ?

Well if you look a bit more at that driver you'll notice that
[there're way too many ifdefs] FS-part is in a separate ifdef section
so we don’t need to worry about it in HS-part :)

> > +#if (CONFIG_DWC2_PHY_TYPE == DWC2_PHY_TYPE_ULPI)
> > +   usbcfg |= DWC2_GUSBCFG_ULPI_UTMI_SEL;
> > +#endif
> >
> > if (usbcfg & DWC2_GUSBCFG_ULPI_UTMI_SEL) {  /* ULPI interface */
> 
> This condition should be tweaked, I think. You set the ULPI_UTMI_SEL bit
> above and check for it here again, that's a bit odd.

Completely agree but again my intention was to move with very tiny steps
Fixing one issue at a time such that heavy refactoring could be escaped...
But I would agree that this driver definitely needs refactoring because of those
Configuration options, some incorrect checks etc. But I'd think it's still 
better
To have expectedly working code today (i.e. fix existing code) instead of 
waiting
for major rewrite sometime down the line.

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

[U-Boot] [PATCH 1/1] efi_loader: do_bootefi_exec should always return an EFI status code

[Heinrich Schuchardt]

The return type of do_bootefi_exec() is efi_status_t. So in case
of an error we should always return an EFI status code.

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

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f3ac04bebfb..3df1d3fbd07 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -189,7 +189,7 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
struct efi_loaded_image loaded_image_info = {};
struct efi_object loaded_image_info_obj = {};
struct efi_device_path *memdp = NULL;
-   ulong ret;
+   efi_status_t ret;
 
EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
 struct efi_system_table *st);
@@ -251,7 +251,7 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
/* Load the EFI payload */
entry = efi_load_pe(efi, _image_info);
if (!entry) {
-   ret = -ENOENT;
+   ret = EFI_LOAD_ERROR;
goto exit;
}
 
-- 
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] Broadwell-DE Implementation

[Peter Tyser]

Hi Vincenzo,

On Thu, 2018-01-25 at 13:58 -0500, vnktux wrote:
> Hi all,
> 
> This patch contain a working implementation of Broadwell-DE for U-
> Boot, and support memory down with external SPD binary file. However
> there is only one issue that I couldn't solve, the booting process
> takes 1 hour. When the FSP reach "DDRIO Initialization" it take a lot
> before the memory is initialized and you can reach the U-Boot shell.
> I would like a review of my implementation since I am out of options.
> I tried to Enable/Disable MRC Cache and ACPI Resume but the problem
> is still there.

Thanks for the Broadwell-DE work.  It'd be nice to have a port!  I
tried your code on one of our Broadwell-DE board this weekend and saw
similar behavior to you with the slow boot time.  I believe this is
related to cache configuration.  A modification like the following
makes my board boot quickly (sub 10 seconds):

--- a/arch/x86/lib/fsp/fsp_car.S
+++ b/arch/x86/lib/fsp/fsp_car.S
@@ -106,5 +106,5 @@ _dt_ucode_base_size:
 ucode_base:/* Declared in micrcode.h */
.long   0   /* microcode base */
.long   0   /* microcode size */
-   .long   CONFIG_SYS_MONITOR_BASE /* code region base */
-   .long   CONFIG_SYS_MONITOR_LEN  /* code region size */
+   .long   0x - 0x100 + 1  /* code region base */
+   .long   0x100   /* code region size */

The above is just a proof of concept meant to show the problem area - a
more elegant solution should likely be used.  The "code region" above
is passed into the FSP, which I believe enables caching in that region.
 Increasing it from 1MB to 16MB (the size of my SPI flash) made the
boot time more sane.

The latest patch series also seems to have whitespace issues so that it
can't apply cleanly without modification.  As an example,
arch/x86/dts/u-boot.dtsi has indentation that is not present in  https:
//patchwork.ozlabs.org/patch/866257/ which makes it not apply.  It'd be
good to fix that on future submissions.

The patch series seemed to mostly work out of the box to get up to a
command prompt, which is great!  It could boot a Linuz zImage as well.
 There seemed to be some rough edges (eg multi processor support), but
I didn't kick the tires too much and assume those edges shouldn't be
too bad to smooth out later.

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

[U-Boot] [PATCH 1/1] efi_loader: check initialization of EFI subsystem is successful

[Heinrich Schuchardt]

Up to now errors in the initialization of the EFI subsystems was not
checked.

If any initialization fails, leave the bootefi command.

We do not retry initialization because this would require to undo all prior
initalization steps.

Suggested-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 67 +--
 1 file changed, 47 insertions(+), 20 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index dff86cf9f9a..f3ac04bebfb 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -22,40 +22,65 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static u8 efi_obj_list_initialized;
+#define OBJ_LIST_NOT_INITIALIZED 1
+
+static efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
 
 static struct efi_device_path *bootefi_image_path;
 static struct efi_device_path *bootefi_device_path;
 
 /* Initialize and populate EFI object list */
-static void efi_init_obj_list(void)
+efi_status_t efi_init_obj_list(void)
 {
+   efi_status_t ret = EFI_SUCCESS;
+
/* Initialize once only */
-   if (efi_obj_list_initialized)
-   return;
-   efi_obj_list_initialized = 1;
+   if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
+   return efi_obj_list_initialized;
 
/* Initialize EFI driver uclass */
-   efi_driver_init();
+   ret = efi_driver_init();
+   if (ret != EFI_SUCCESS)
+   goto out;
 
-   efi_console_register();
+   ret = efi_console_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #ifdef CONFIG_PARTITIONS
-   efi_disk_register();
+   ret = efi_disk_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
 #if defined(CONFIG_LCD) || defined(CONFIG_DM_VIDEO)
-   efi_gop_register();
+   ret = efi_gop_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
 #ifdef CONFIG_NET
-   efi_net_register();
+   ret = efi_net_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
 #ifdef CONFIG_GENERATE_SMBIOS_TABLE
-   efi_smbios_register();
+   ret = efi_smbios_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
-   efi_watchdog_register();
+   ret = efi_watchdog_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 
/* Initialize EFI runtime services */
-   efi_reset_system_init();
-   efi_get_time_init();
+   ret = efi_reset_system_init();
+   if (ret != EFI_SUCCESS)
+   goto out;
+   ret = efi_get_time_init();
+   if (ret != EFI_SUCCESS)
+   goto out;
+
+out:
+   efi_obj_list_initialized = ret;
+   return ret;
 }
 
 /*
@@ -186,9 +211,6 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
assert(device_path && image_path);
}
 
-   /* Initialize and populate EFI object list */
-   efi_init_obj_list();
-
efi_setup_loaded_image(_image_info, _image_info_obj,
   device_path, image_path);
 
@@ -285,9 +307,6 @@ static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
void *addr;
efi_status_t r;
 
-   /* Initialize and populate EFI object list */
-   efi_init_obj_list();
-
/*
 * gd lives in a fixed register which may get clobbered while we execute
 * the payload. So save it here and restore it on every callback entry
@@ -316,6 +335,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
unsigned long addr, fdt_addr = 0;
efi_status_t r;
 
+   /* Initialize EFI drivers */
+   r = efi_init_obj_list();
+   if (r != EFI_SUCCESS) {
+   printf("Error: Cannot set up EFI drivers, r = %lu\n",
+  r & ~EFI_ERROR_MASK);
+   return CMD_RET_FAILURE;
+   }
+
if (argc < 2)
return CMD_RET_USAGE;
 #ifdef CONFIG_CMD_BOOTEFI_HELLO
-- 
2.15.1

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

Re: [U-Boot] [PATCH] usb: dwc2: Rename CONFIG_DWC2_UTMI_PHY_WIDTH to CONFIG_DWC2_UTMI_WIDTH

[Alexey Brodkin]

Hi Marek,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, February 5, 2018 4:18 PM
> To: Alexey Brodkin 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] usb: dwc2: Rename CONFIG_DWC2_UTMI_PHY_WIDTH to 
> CONFIG_DWC2_UTMI_WIDTH
> 
> On 02/01/2018 03:53 PM, Alexey Brodkin wrote:
> > Hi Marek,
> >
> > On Wed, 2018-01-31 at 16:13 +0100, Marek Vasut wrote:
> >> On 01/31/2018 03:56 PM, Alexey Brodkin wrote:
> >>> For some reason from day one we used to have both CONFIG_DWC2_UTMI_WIDTH
> >>> mentioned in dwc2.h and in scripts/config_whitelist.txt but never really 
> >>> used
> >>> and CONFIG_DWC2_UTMI_PHY_WIDTH used in real code in dwc2.c (but never
> >>> defined).
> >>>
> >>> Moreover even though CONFIG_DWC2_UTMI_WIDTH might be either 8 or 16
> >>> depending on hardware (and the same is said in a comment for it in
> >>> dwc2.h) but then 8 is hardcoded in the header leaving no ability to
> >>> override this value in board's configuration.
> >>>
> >>> Signed-off-by: Alexey Brodkin 
> >>> Cc: Marek Vasut 
> >>
> >> Applied, thanks.
> >>
> >> btw How the heck did that code ever even compile ?
> >
> > Well my change doesn't really fix anything in existing code
> > except makes once check meaningful compared to dummy always negative
> > as it was before :)
> 
> Ha, now I see it.
> 
> > I'd say it means the driver was not very widely used on different hardwares.
> > Still it does work [at least] to some extent which is really nice.
> 
> Probably. All this info should be pulled from DT anyway.

That's so true... but now when there're real users of this driver moving stuff 
to
Device tree is not that trivial:
1) We need to move there those options that are now "configured" via defines
2) We need to keep compatibility with Linux DT options for the same controller 
otherwise we'll
lose ability to use the same .dtb-s in both Linux and U-Boot.

I'm not saying it's not doable but it is not a one-liner unfortunately.

-Alexey

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

[U-Boot] [PATCH 1/1] efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL

[Heinrich Schuchardt]

Not complete, but enough for Shell.efi and SCT.efi.  We'll implement the
rest as needed or once we have SCT running properly so there is a way to
validate the interface against the conformance test suite.

Initial skeleton written by Leif, and then implementation by Rob.

Rebased on v2018.03-rc1.

Suggested-by: Leif Lindholm 
Suggested-by: Rob Clark 
Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h  | 29 ++
 include/efi_loader.h   |  4 ++
 lib/efi_loader/Makefile|  3 +-
 lib/efi_loader/efi_boottime.c  |  6 ++
 lib/efi_loader/efi_device_path_utilities.c | 89 ++
 5 files changed, 130 insertions(+), 1 deletion(-)
 create mode 100644 lib/efi_loader/efi_device_path_utilities.c

diff --git a/include/efi_api.h b/include/efi_api.h
index 559e58e5501..993e8231fca 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -588,6 +588,35 @@ struct efi_device_path_to_text_protocol
bool allow_shortcuts);
 };
 
+#define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \
+   EFI_GUID(0x0379be4e, 0xd706, 0x437d, \
+0xb0, 0x37, 0xed, 0xb8, 0x2f, 0xb7, 0x72, 0xa4)
+
+struct efi_device_path_utilities_protocol {
+   efi_uintn_t (EFIAPI *get_device_path_size)(
+   const struct efi_device_path *device_path);
+   struct efi_device_path *(EFIAPI *duplicate_device_path)(
+   const struct efi_device_path *device_path);
+   struct efi_device_path *(EFIAPI *append_device_path)(
+   const struct efi_device_path *src1,
+   const struct efi_device_path *src2);
+   struct efi_device_path *(EFIAPI *append_device_node)(
+   const struct efi_device_path *device_path,
+   const struct efi_device_path *device_node);
+   struct efi_device_path *(EFIAPI *append_device_path_instance)(
+   const struct efi_device_path *device_path,
+   const struct efi_device_path *device_path_instance);
+   struct efi_device_path *(EFIAPI *get_next_device_path_instance)(
+   struct efi_device_path **device_path_instance,
+   efi_uintn_t *device_path_instance_size);
+   bool (EFIAPI *is_device_path_multi_instance)(
+   const struct efi_device_path *device_path);
+   struct efi_device_path *(EFIAPI *create_device_node)(
+   uint8_t node_type,
+   uint8_t node_sub_type,
+   uint16_t node_length);
+};
+
 #define EFI_GOP_GUID \
EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
 0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 7caae97ea70..c8b2e81f78b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -83,6 +83,9 @@ extern struct efi_simple_text_output_protocol efi_con_out;
 extern struct efi_simple_input_interface efi_con_in;
 extern struct efi_console_control_protocol efi_console_control;
 extern const struct efi_device_path_to_text_protocol efi_device_path_to_text;
+/* implementation of the EFI_DEVICE_PATH_UTILITIES_PROTOCOL */
+extern const struct efi_device_path_utilities_protocol
+   efi_device_path_utilities;
 
 uint16_t *efi_dp_str(struct efi_device_path *dp);
 
@@ -97,6 +100,7 @@ extern const efi_guid_t efi_guid_loaded_image;
 extern const efi_guid_t efi_guid_device_path_to_text_protocol;
 extern const efi_guid_t efi_simple_file_system_protocol_guid;
 extern const efi_guid_t efi_file_info_guid;
+extern const efi_guid_t efi_guid_device_path_utilities_protocol;
 
 extern unsigned int __efi_runtime_start, __efi_runtime_stop;
 extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 2722265ee3d..55c97c04766 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -17,7 +17,8 @@ endif
 obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
 obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
 obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
-obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
+obj-y += efi_device_path_utilities.o efi_file.o efi_variable.o efi_bootmgr.o
+obj-y += efi_watchdog.o
 obj-$(CONFIG_LCD) += efi_gop.o
 obj-$(CONFIG_DM_VIDEO) += efi_gop.o
 obj-$(CONFIG_PARTITIONS) += efi_disk.o
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 013e0353c3a..0fd272253d2 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1426,6 +1426,12 @@ efi_status_t efi_setup_loaded_image(
if (ret != EFI_SUCCESS)
goto failure;
 
+   ret = efi_add_protocol(obj->handle,
+  _guid_device_path_utilities_protocol,
+  (void *)_device_path_utilities);
+   if 

[U-Boot] [PATCH 1/1] efi_loader: show UEFI revision in helloworld

[Heinrich Schuchardt]

Output the UEFI revision number in helloworld.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/helloworld.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 1ec01792263..6c539ba2049 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -46,9 +46,27 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
struct efi_loaded_image *loaded_image;
efi_status_t ret;
efi_uintn_t i;
+   u16 rev[] = L"0.0.0";
 
con_out->output_string(con_out, L"Hello, world!\n");
 
+   /* Print the revision number */
+   rev[0] = (systable->hdr.revision >> 16) + '0';
+   rev[4] = systable->hdr.revision & 0x;
+   for (; rev[4] >= 10;) {
+   rev[4] -= 10;
+   ++rev[2];
+   }
+   /* Third digit is only to be shown if non-zero */
+   if (rev[4])
+   rev[4] += '0';
+   else
+   rev[3] = 0;
+
+   con_out->output_string(con_out, L"Running on UEFI ");
+   con_out->output_string(con_out, rev);
+   con_out->output_string(con_out, L"\n");
+
/* Get the loaded image protocol */
ret = boottime->handle_protocol(handle, _image_guid,
(void **)_image);
-- 
2.14.2

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

Re: [U-Boot] [PATCH] usb: dwc2: make casts of ep->dma_buf consistent

[Lukasz Majewski]

On Mon,  5 Feb 2018 09:54:51 -0500
Tom Rini  wrote:

> In most places in the code we cast this to an unsigned long, but in
> one place we cast to an unsigned int.  For consistency and to fix a
> warning on 64bit targets, always cast this to unsigned long.  For the
> long term we should however change the declaration of dma_buf.
> 
> Cc: Lukasz Majewski 
> Cc: Marek Vasut 
> Cc: Philipp Tomsich 
> Signed-off-by: Tom Rini 
> ---
>  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c index
> b6164afa9245..57dbbd5ebfa1 100644 ---
> a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c +++
> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c @@ -114,7 +114,7 @@
> static int setdma_rx(struct dwc2_ep *ep, struct dwc2_request *req)
> (unsigned long) ep->dma_buf + ROUND(ep->len,
> CONFIG_SYS_CACHELINE_SIZE)); 
> - writel((unsigned int) ep->dma_buf,
> >out_endp[ep_num].doepdma);
> + writel((unsigned long) ep->dma_buf,
> >out_endp[ep_num].doepdma); writel(DOEPT_SIZ_PKT_CNT(pktcnt) |
> DOEPT_SIZ_XFER_SIZE(length), >out_endp[ep_num].doeptsiz);
>   writel(DEPCTL_EPENA|DEPCTL_CNAK|ctrl,
> >out_endp[ep_num].doepctl);

Acked-by: Lukasz Majewski 


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


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

[U-Boot] [PATCH 1/1][for V2018.03] efi_loader: do not use 2.0.5 as UEFI revision number

[Heinrich Schuchardt]

Currently the UEFI revision number in the system table header is set to
2.0.5. This version number does not refer to any existing version of the
UEFI standard.

Set the revision number to 2.7.

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

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 0fd272253d2..3b9184b3e24 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2893,7 +2893,7 @@ static uint16_t __efi_runtime_data firmware_vendor[] = 
L"Das U-Boot";
 struct efi_system_table __efi_runtime_data systab = {
.hdr = {
.signature = EFI_SYSTEM_TABLE_SIGNATURE,
-   .revision = 0x20005, /* 2.5 */
+   .revision = 2 << 16 | 70, /* 2.7 */
.headersize = sizeof(struct efi_table_hdr),
},
.fw_vendor = (long)firmware_vendor,
-- 
2.14.2

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

Re: [U-Boot] [PATCH] ls1088a: qspi: Enable XIP mode above 16 MB addresses

[York Sun]

On 02/04/2018 09:37 PM, Rajat Srivastava wrote:
> 
> 
>> -Original Message-
>> From: York Sun
>> Sent: Friday, February 02, 2018 9:29 PM
>> To: Rajat Srivastava ; u-boot@lists.denx.de
>> Subject: Re: [PATCH] ls1088a: qspi: Enable XIP mode above 16 MB addresses
>>
>> On 02/02/2018 04:07 AM, Rajat Srivastava wrote:
>>> Currently in LS1088A, XIP mode in QSPI works up to 16 MB addresses.
>>> This patch enables QSPI support in XIP mode for addresses above 16 MB
>>> as well.
>>
>> Can you write to QSPI above 16MB address?
>  
> No, I think execute in place (XIP) itself means we can only read.
> Please suggest if I shall change the patch description.
> 

How do you put the image into it to begin with? Don't tell me you were
using an external tool or a hacked version of older U-Boot.

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

Re: [U-Boot] [PATCH v2 1/3] mach-stm32: Add set_env_soc_name support

[Vikas Manocha]

Hi,

On 02/05/2018 02:33 AM, patrice.chot...@st.com wrote:
> From: Patrice Chotard 
> 
> This allows to create and set the environment variable
> "soc_name" which contains the current STM32 SoC's name.
> 
> Signed-off-by: Christophe Priouzeau 
> Signed-off-by: Patrice Chotard 

For the series,
Reviewed-by: Vikas Manocha 

One point below,
[...]

> +
>  #endif /* _ASM_ARCH_HARDWARE_H */
> diff --git a/arch/arm/mach-stm32/soc.c b/arch/arm/mach-stm32/soc.c
> index df20d547c500..06ca61b270cf 100644
> --- a/arch/arm/mach-stm32/soc.c
> +++ b/arch/arm/mach-stm32/soc.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  int arch_cpu_init(void)
>  {
> @@ -54,3 +55,17 @@ int arch_cpu_init(void)
>  
>   return 0;
>  }
> +
> +void set_env_soc_name(void)
> +{
> + char soc[16];
> +
> +#ifdef CONFIG_STM32F4
> + snprintf(soc, sizeof(soc), "stm32f4");
> +#elif CONFIG_STM32F7
> + snprintf(soc, sizeof(soc), "stm32f7");
> +#elif CONFIG_STM32H7
> + snprintf(soc, sizeof(soc), "stm32h7");
> +#endif

Can we move these conditional checks in the background like in some header file 
inline function & use it like get_soc_name();

Cheers,
Vikas

> + env_set("soc_name", soc);
> +}
> 
___
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

[Simon Glass]

Hi Javier,

On 5 February 2018 at 01:07, Javier Santos Romo  wrote:
> Hi Simon,
>
> Thanks for your support. We just need a x64 bootloader because we are using a 
> 64-bit EFI. We understood, reading README.efi file from U-boot documentation 
> that we could use u-boot like an 64-bit payload. However, we don´t understand 
> why we get the memory map error. Anyway, we will consider other possibilities.

There is no need to use a 64-bit bootloader with UEFI. In fact the
U-Boot payload is specifically designed to jump from 64-bit to 32-bit
for running U-Boot. It also have native 64-bit kernel support so it
can load a 64-bit kernel.

I suggest you try it in 32-bit mode for now. That is how we use it
here. There is not a lot of benefit to using U-Boot in 64-bit mode,
but if you find something I'm interested to hear it.

If you hit a memory allocation problem in that case, please let us know.

[BTW it is best not to top-post on a mailing list]

Regards,
Simon

>
> Thanks a lot,
> BR
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -Mensaje original-
> De: s...@google.com [mailto:s...@google.com] En nombre de Simon Glass
> Enviado el: domingo, 4 de febrero de 2018 14:41
> Para: Javier Santos Romo 
> CC: u-boot@lists.denx.de; bmeng...@gmail.com; Juan Alfonso Reyes Ajenjo 
> 
> Asunto: Re: Uboot as x86_64 EFI payload
>
> Hi Javier,
>
> On 29 January 2018 at 09:36, Javier Santos Romo  wrote:
>
>> 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:
>
> Are you using 64-bit EFI or 32-bit?
>
> I think you was CONFIG_EFI_STUB_64BIT
>
> See doc/README.efi for some info about this. Note this this option makes the 
> stub run as a 64-bit EFI app, but U-Boot itself is still only 32-bit.
>
>>
>>
>>
>> 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?
>
> This is for running U-Boot itself as a 64-bit app. This is not currently 
> supported as an EFI payload, only as a bar-metal U-Boot (not run from EFI).
>
> The meaning of the comment is that on 32-bit x86 we use the FS register to 
> store gd. See:
>
> #define gd  get_fs_gd_ptr()
>
> We could potentially make gd use a fixed x86 register on 64-bit x86 as well. 
> This comment is about considering that.
>
> Regards,
> Simon
>
>
>>
>>
>>
>> Thank you very much,
>>
>>
>>
>> Best regards,
>>
>> 
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>> P Please consider the environment before printing this e-mail.
>>
>>
>> P Please consider the environment before printing this e-mail.
>
> What does this mean?
>
>>
>> 
>> 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. Thank you.
>> 
>> 

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

[York Sun]

On 02/05/2018 05:44 AM, Maxime Ripard wrote:
> Hi York,
> 
> On Fri, Feb 02, 2018 at 08:04:12PM +, York Sun wrote:
>> On 02/02/2018 10:51 AM, Maxime Ripard wrote:
> This patch looks correct. But it doesn't fix NOR flash. Do you have plan
> to add .get_char function to other drivers? Without that function, we
> cannot get env variables before relocation.

 Ehrm, sorry  I don't plan to do that, no: my target seems to run fine
 without this.

 Given that only the eeprom and nvram env drivers support the get_char
 method, I don't know if this is widely used at all. Maybe a better fallback
 would be to just remove that get_char code path totally and always load 
 from
 the internal (default) environment until the full environment is available
 (after relocation).

 After all, the environment variables loaded via get_char are not CRC 
 checked
 at all. To me, this is another indication that this code is not really
 useful and should probably be removed.
>>>
>>> To be honest, I'm not really sure what get_char was here for in the
>>> first place, so getting rid of it sounds like a good idea :)
>>
>> On almost all my boards, a variable hwconfig is read before relocation
>> to determine DDR configuration. This has been broken. I don't mind you
>> remove some dead code. But this is breaking almost all my boards booting
>> from NOR flash.
> 
> Sorry if it fell through the cracks, I don't have a board with NOR
> myself. Do you know what breaks exactly?
> 
> Or can you bisect at least?
> 

Yes, I did. It was the #3 patch in the series of "env: Multiple env
support and env transition for sunxi". I reported in the email thread
"Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments",
along with another problem found regarding variable "env_load_location".
The latter problem breaks saveenv on NOR flash.

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

Re: [U-Boot] [PATCH 1/2] ARM: omap3: ti_omap3_common: Fix CONFIG_SYS_NS16550_REG_SIZE compiler warning

[Tom Rini]

On Sun, Feb 04, 2018 at 07:04:49PM -0600, Derald D. Woods wrote:

> This commit fixes the following compiler warnings when DM_SERIAL is
> enabled.
> 

Reviewed-by: Tom Rini 

-- 
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 2/2] ARM: omap3: evm: Remove CONFIG_SYS_NS16550_REG_SIZE undefine

[Tom Rini]

On Sun, Feb 04, 2018 at 07:04:50PM -0600, Derald D. Woods wrote:

> This commit removes an attempt to workaround a previous compilation
> warning that is is now fixed in "include/configs/ti_omap3_common.h".
> 
> Signed-off-by: Derald D. Woods 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/3] Move CONFIG_PHY_ADDR to Kconfig

[Tom Rini]

On Mon, Feb 05, 2018 at 09:07:40AM +0100, Maxime Ripard wrote:
> On Sat, Feb 03, 2018 at 04:37:15AM +, Calvin Johnson wrote:
> > > Hi,
> > > 
> > > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Stefan
> > > > Mavrodiev
> > > > Sent: Friday, February 2, 2018 7:24 PM
> > > 
> > > 
> > > 
> > > > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index
> > > > 95b7534..c934aed 100644
> > > > --- a/drivers/net/phy/Kconfig
> > > > +++ b/drivers/net/phy/Kconfig
> > > > @@ -12,6 +12,13 @@ menuconfig PHYLIB
> > > >
> > > >  if PHYLIB
> > > >
> > > > +config PHY_ADDR
> > > > +   int "PHY address"
> > > > +   default 1 if ARCH_SUNXI
> > 
> > Sorry, I meant the  default value can be defined in board/sunxi/Kconfig.
> > Remaining definition of PHY_ADDR config can be here.
> 
> Tom has asked a few times not to do this but to put the defaults where
> the Kconfig option is defined. I'm not sure I remember the details
> though.

For now, yes, the preferred way of dealing with this is 'default FOO if
BAR' in the main Kconfig entry line.  What I wish for long term is for
'imply' to get extended to support 'imply FOO BAR' but I've not had more
to add there other than "Gee, this would make life easier".

-- 
Tom


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

Re: [U-Boot] [PATCH v2] configs: am335x_evm: Disable ISO and EFI partitions in SPL

[Tom Rini]

On Mon, Feb 05, 2018 at 07:22:29PM +0530, Faiz Abbas wrote:

> ISO and EFI partition configs in SPL are selected by default.
> However, they are not being used.
> 
> Therefore, remove ISO and EFI partition support in SPL.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
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] sunxi: Add reg property for USB OTG node in sun8i-a83t.dtsi

[Jagan Teki]

On Mon, Feb 5, 2018 at 7:54 PM, Maxime Ripard  wrote:
> On Mon, Feb 05, 2018 at 10:03:25PM +0800, Chen-Yu Tsai wrote:
>> When the OTG node was added, its reg property for its address space was
>> missing. With commit f4f9896ac310 ("musb: sunxi: Use base address from
>> device tree"), the OTG controller's address is derived from the device
>> tree exclusively. The missing property results in U-boot crashing when
>> MUSB is initialized.
>>
>> Fixes: b0bea6678981 ("sunxi: Add USB and R_PIO nodes to sun8i-a83t.dtsi")
>> Signed-off-by: Chen-Yu Tsai 
>
> Acked-by: Maxime Ripard 

Reviewed-by: Jagan Teki 
Tested-by: Jagan Teki 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: dwc2: make casts of ep->dma_buf consistent

[Marek Vasut]

On 02/05/2018 03:54 PM, Tom Rini wrote:
> In most places in the code we cast this to an unsigned long, but in one
> place we cast to an unsigned int.  For consistency and to fix a warning
> on 64bit targets, always cast this to unsigned long.  For the long term
> we should however change the declaration of dma_buf.
> 
> Cc: Lukasz Majewski 
> Cc: Marek Vasut 
> Cc: Philipp Tomsich 
> Signed-off-by: Tom Rini 
> ---
>  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c 
> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> index b6164afa9245..57dbbd5ebfa1 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> @@ -114,7 +114,7 @@ static int setdma_rx(struct dwc2_ep *ep, struct 
> dwc2_request *req)
>   (unsigned long) ep->dma_buf +
>   ROUND(ep->len, CONFIG_SYS_CACHELINE_SIZE));
>  
> - writel((unsigned int) ep->dma_buf, >out_endp[ep_num].doepdma);
> + writel((unsigned long) ep->dma_buf, >out_endp[ep_num].doepdma);
>   writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
>  >out_endp[ep_num].doeptsiz);
>   writel(DEPCTL_EPENA|DEPCTL_CNAK|ctrl, >out_endp[ep_num].doepctl);
> 

Acked-by: Marek Vasut 

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

[U-Boot] [PATCH] usb: dwc2: make casts of ep->dma_buf consistent

[Tom Rini]

In most places in the code we cast this to an unsigned long, but in one
place we cast to an unsigned int.  For consistency and to fix a warning
on 64bit targets, always cast this to unsigned long.  For the long term
we should however change the declaration of dma_buf.

Cc: Lukasz Majewski 
Cc: Marek Vasut 
Cc: Philipp Tomsich 
Signed-off-by: Tom Rini 
---
 drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c 
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index b6164afa9245..57dbbd5ebfa1 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -114,7 +114,7 @@ static int setdma_rx(struct dwc2_ep *ep, struct 
dwc2_request *req)
(unsigned long) ep->dma_buf +
ROUND(ep->len, CONFIG_SYS_CACHELINE_SIZE));
 
-   writel((unsigned int) ep->dma_buf, >out_endp[ep_num].doepdma);
+   writel((unsigned long) ep->dma_buf, >out_endp[ep_num].doepdma);
writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
   >out_endp[ep_num].doeptsiz);
writel(DEPCTL_EPENA|DEPCTL_CNAK|ctrl, >out_endp[ep_num].doepctl);
-- 
2.7.4

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

Re: [U-Boot] [PATCH] sunxi: Add reg property for USB OTG node in sun8i-a83t.dtsi

[Maxime Ripard]

On Mon, Feb 05, 2018 at 10:03:25PM +0800, Chen-Yu Tsai wrote:
> When the OTG node was added, its reg property for its address space was
> missing. With commit f4f9896ac310 ("musb: sunxi: Use base address from
> device tree"), the OTG controller's address is derived from the device
> tree exclusively. The missing property results in U-boot crashing when
> MUSB is initialized.
> 
> Fixes: b0bea6678981 ("sunxi: Add USB and R_PIO nodes to sun8i-a83t.dtsi")
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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

[U-Boot] [PATCH] sunxi: Add reg property for USB OTG node in sun8i-a83t.dtsi

[Chen-Yu Tsai]

When the OTG node was added, its reg property for its address space was
missing. With commit f4f9896ac310 ("musb: sunxi: Use base address from
device tree"), the OTG controller's address is derived from the device
tree exclusively. The missing property results in U-boot crashing when
MUSB is initialized.

Fixes: b0bea6678981 ("sunxi: Add USB and R_PIO nodes to sun8i-a83t.dtsi")
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/sun8i-a83t.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/sun8i-a83t.dtsi b/arch/arm/dts/sun8i-a83t.dtsi
index 0fe73e173f44..bab6c1812b8a 100644
--- a/arch/arm/dts/sun8i-a83t.dtsi
+++ b/arch/arm/dts/sun8i-a83t.dtsi
@@ -227,6 +227,7 @@
 
usb_otg: usb@01c19000 {
compatible = "allwinner,sun8i-a33-musb";
+   reg = <0x01c19000 0x400>;
interrupts = ;
interrupt-names = "mc";
status = "disabled";
-- 
2.15.1

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

[U-Boot] [PATCH v2] configs: am335x_evm: Disable ISO and EFI partitions in SPL

[Faiz Abbas]

ISO and EFI partition configs in SPL are selected by default.
However, they are not being used.

Therefore, remove ISO and EFI partition support in SPL.

Signed-off-by: Faiz Abbas 
---
changes in v2:
did savedefconfig to appropriate the position of configs

 configs/am335x_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 9e79d1c..8f33c8e 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -22,6 +22,8 @@ CONFIG_CMD_NAND=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
am335x-bonegreen am335x-icev2"
 # CONFIG_BLK is not set
-- 
2.7.4

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

Re: [U-Boot] [PATCH] usb: dwc2: Fix logic for setup of GUSBCFG->ULPI_UTMI_Sel bit

[Marek Vasut]

On 02/02/2018 04:58 PM, Alexey Brodkin wrote:
> According to the databook "ULPI_UTMI_Sel" bit (#4) in GUSBCFG
> register selects between ULPI and UTMI+ interfaces such that:
>  0 - stands for UTMI+ interface
>  1 - stands for ULPI interface
> 
> Currently implemented logic in the driver is incorrect because
> CONFIG_DWC2_PHY_TYPE is not a "bool" but instead this is an "enum"
> which starts from 0 in case of full-speed and is either 1 for
> UTMI or 2 for ULPI.
> 
> In dwc2.h we have:
> -->8--
>  #define DWC2_PHY_TYPE_FS 0
>  #define DWC2_PHY_TYPE_UTMI   1
>  #define DWC2_PHY_TYPE_ULPI   2
>  #define CONFIG_DWC2_PHY_TYPE DWC2_PHY_TYPE_UTMI
> -->8--
> 
> And in dwc2.c we do "|= CONFIG_DWC2_PHY_TYPE << 4"
> effectively setting "ULPI_UTMI_Sel" bit for UTMI+ and
> what's even worse for ULMI we keep "ULPI_UTMI_Sel" zeroed
> while setting the next "FSIntf" bit (#5) unexpectedly selecting
> Full speed interface!
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Marek Vasut 
> ---
>  drivers/usb/host/dwc2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index 784fcbdbd94f..29138a2579ab 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -366,7 +366,9 @@ static void dwc_otg_core_init(struct dwc2_priv *priv)
>* immediately after setting phyif.
>*/
>   usbcfg &= ~(DWC2_GUSBCFG_ULPI_UTMI_SEL | DWC2_GUSBCFG_PHYIF);
> - usbcfg |= CONFIG_DWC2_PHY_TYPE << DWC2_GUSBCFG_ULPI_UTMI_SEL_OFFSET;

What happens if PHY type is set to FS or UTMI , won't that change the
behavior of this code ?

> +#if (CONFIG_DWC2_PHY_TYPE == DWC2_PHY_TYPE_ULPI)
> + usbcfg |= DWC2_GUSBCFG_ULPI_UTMI_SEL;
> +#endif
>  
>   if (usbcfg & DWC2_GUSBCFG_ULPI_UTMI_SEL) {  /* ULPI interface */

This condition should be tweaked, I think. You set the ULPI_UTMI_SEL bit
above and check for it here again, that's a bit odd.

>  #ifdef CONFIG_DWC2_PHY_ULPI_DDR
> 


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

Re: [U-Boot] [PATCH] usb: dwc2: Rename CONFIG_DWC2_UTMI_PHY_WIDTH to CONFIG_DWC2_UTMI_WIDTH

[Marek Vasut]

On 02/01/2018 03:53 PM, Alexey Brodkin wrote:
> Hi Marek,
> 
> On Wed, 2018-01-31 at 16:13 +0100, Marek Vasut wrote:
>> On 01/31/2018 03:56 PM, Alexey Brodkin wrote:
>>> For some reason from day one we used to have both CONFIG_DWC2_UTMI_WIDTH
>>> mentioned in dwc2.h and in scripts/config_whitelist.txt but never really 
>>> used
>>> and CONFIG_DWC2_UTMI_PHY_WIDTH used in real code in dwc2.c (but never
>>> defined).
>>>
>>> Moreover even though CONFIG_DWC2_UTMI_WIDTH might be either 8 or 16
>>> depending on hardware (and the same is said in a comment for it in
>>> dwc2.h) but then 8 is hardcoded in the header leaving no ability to
>>> override this value in board's configuration.
>>>
>>> Signed-off-by: Alexey Brodkin 
>>> Cc: Marek Vasut 
>>
>> Applied, thanks.
>>
>> btw How the heck did that code ever even compile ?
> 
> Well my change doesn't really fix anything in existing code
> except makes once check meaningful compared to dummy always negative
> as it was before :)

Ha, now I see it.

> I'd say it means the driver was not very widely used on different hardwares.
> Still it does work [at least] to some extent which is really nice.

Probably. All this info should be pulled from DT anyway.

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

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

[Maxime Ripard]

Hi York,

On Fri, Feb 02, 2018 at 08:04:12PM +, York Sun wrote:
> On 02/02/2018 10:51 AM, Maxime Ripard wrote:
> >>> This patch looks correct. But it doesn't fix NOR flash. Do you have plan
> >>> to add .get_char function to other drivers? Without that function, we
> >>> cannot get env variables before relocation.
> >>
> >> Ehrm, sorry  I don't plan to do that, no: my target seems to run fine
> >> without this.
> >>
> >> Given that only the eeprom and nvram env drivers support the get_char
> >> method, I don't know if this is widely used at all. Maybe a better fallback
> >> would be to just remove that get_char code path totally and always load 
> >> from
> >> the internal (default) environment until the full environment is available
> >> (after relocation).
> >>
> >> After all, the environment variables loaded via get_char are not CRC 
> >> checked
> >> at all. To me, this is another indication that this code is not really
> >> useful and should probably be removed.
> > 
> > To be honest, I'm not really sure what get_char was here for in the
> > first place, so getting rid of it sounds like a good idea :)
> 
> On almost all my boards, a variable hwconfig is read before relocation
> to determine DDR configuration. This has been broken. I don't mind you
> remove some dead code. But this is breaking almost all my boards booting
> from NOR flash.

Sorry if it fell through the cracks, I don't have a board with NOR
myself. Do you know what breaks exactly?

Or can you bisect at least?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

[Faiz Abbas]

Hi,

On Monday 05 February 2018 02:59 AM, Alex Kiernan wrote:
> On Fri, Feb 2, 2018 at 9:47 AM, Faiz Abbas  wrote:
>> When booting from a non-MMC device, the MMC sub-system may not be
>> initialized when the environment is first accessed.
>> We need to make sure that the MMC sub-system is ready in even a non-MMC
>> boot case.
>>
>> Therefore, initialize mmc during .init() of environment.
>>
>> Signed-off-by: Faiz Abbas 
>> ---
>>  env/ext4.c | 9 +
>>  env/fat.c  | 9 +
>>  env/mmc.c  | 8 
>>  3 files changed, 26 insertions(+)
>>
>> diff --git a/env/ext4.c b/env/ext4.c
>> index 9cdf28e..ba93e5b 100644
>> --- a/env/ext4.c
>> +++ b/env/ext4.c
>> @@ -123,9 +123,18 @@ err_env_relocate:
>> return -EIO;
>>  }
>>
>> +static int env_ext4_init(void)
>> +{
>> +   if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc"))
> 
> Shouldn't that be CONFIG_ENV_EXT4_INTERFACE ?

Yes. Will fix in v2.

Thanks,
Faiz

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

[U-Boot] [PATCH V2] Convert CONFIG_APBH_DMA et al to Kconfig

[Adam Ford]

This converts the following to Kconfig:
   CONFIG_APBH_DMA
   CONFIG_APBH_DMA_BURST
   CONFIG_APBH_DMA_BURST8

Signed-off-by: Adam Ford 
---
Changes in V2:
Rebase on [U-Boot,v2,1/6] Convert CONFIG_NAND_MXS to Kconfig
Make the NAND controller in MX6 MX7 autoselect the DMA options

 configs/bg0900_defconfig|  1 +
 configs/mx23_olinuxino_defconfig|  1 +
 configs/mx23evk_defconfig   |  1 +
 configs/mx28evk_auart_console_defconfig |  3 +--
 configs/mx28evk_defconfig   |  3 +--
 configs/mx28evk_spi_defconfig   |  3 +--
 configs/sansa_fuze_plus_defconfig   |  1 +
 configs/sc_sps_1_defconfig  |  1 +
 configs/ts4600_defconfig|  1 +
 configs/xfi3_defconfig  |  1 +
 drivers/dma/Kconfig | 14 ++
 drivers/mtd/nand/Kconfig|  3 +++
 include/configs/aristainetos-common.h   |  3 ---
 include/configs/cm_fx6.h|  3 ---
 include/configs/colibri_imx7.h  |  3 ---
 include/configs/gw_ventana.h|  3 ---
 include/configs/imx6-engicam.h  |  4 
 include/configs/imx6_logic.h|  3 ---
 include/configs/mx6sabreauto.h  |  3 ---
 include/configs/mx6sxsabreauto.h|  3 ---
 include/configs/mx7dsabresd.h   |  3 ---
 include/configs/mxs.h   |  1 -
 include/configs/pcm058.h|  3 ---
 include/configs/pfla02.h|  3 ---
 include/configs/platinum.h  |  3 ---
 include/configs/titanium.h  |  3 ---
 scripts/config_whitelist.txt|  3 ---
 27 files changed, 27 insertions(+), 50 deletions(-)

diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig
index 72616ae..7314eff 100644
--- a/configs/bg0900_defconfig
+++ b/configs/bg0900_defconfig
@@ -25,6 +25,7 @@ CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_DOS_PARTITION=y
+CONFIG_APBH_DMA=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/mx23_olinuxino_defconfig b/configs/mx23_olinuxino_defconfig
index 628c11d..2c80c3b 100644
--- a/configs/mx23_olinuxino_defconfig
+++ b/configs/mx23_olinuxino_defconfig
@@ -20,6 +20,7 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_APBH_DMA=y
 CONFIG_LED_STATUS=y
 CONFIG_LED_STATUS_GPIO=y
 CONFIG_LED_STATUS0=y
diff --git a/configs/mx23evk_defconfig b/configs/mx23evk_defconfig
index 6ad7f2c..09f3611 100644
--- a/configs/mx23evk_defconfig
+++ b/configs/mx23evk_defconfig
@@ -24,6 +24,7 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_APBH_DMA=y
 CONFIG_MMC_MXS=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/mx28evk_auart_console_defconfig 
b/configs/mx28evk_auart_console_defconfig
index 0927333..7bdb905 100644
--- a/configs/mx28evk_auart_console_defconfig
+++ b/configs/mx28evk_auart_console_defconfig
@@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
-CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
@@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_APBH_DMA=y
 CONFIG_MMC_MXS=y
 CONFIG_NAND=y
-CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_USB=y
diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index 21d01bc..d36ad0e 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
-CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
@@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_APBH_DMA=y
 CONFIG_MMC_MXS=y
 CONFIG_NAND=y
-CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_USB=y
diff --git a/configs/mx28evk_spi_defconfig b/configs/mx28evk_spi_defconfig
index dab5394..7bf1d6e 100644
--- a/configs/mx28evk_spi_defconfig
+++ b/configs/mx28evk_spi_defconfig
@@ -15,7 +15,6 @@ CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
-CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
@@ -33,9 +32,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_APBH_DMA=y
 CONFIG_MMC_MXS=y
 CONFIG_NAND=y
-CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
 

Re: [U-Boot] [PATCH v3 12/15] env: Allow to build multiple environments in Kconfig

[Maxime Ripard]

On Sat, Feb 03, 2018 at 10:23:12AM +, Goldschmidt Simon wrote:
> On 01.02.2018 20:47, Maxime Ripard wrote:
> > On Thu, Feb 01, 2018 at 11:06:14AM +0100, Simon Goldschmidt wrote:
> >> On 23.01.2018 21:17, Maxime Ripard wrote:
> >> > Now that we have everything in place in the code, let's allow to build
> >> > multiple environments backend through Kconfig.
> >> >
> >> > Reviewed-by: Andre Przywara 
> >> > Reviewed-by: Lukasz Majewski 
> >> > Reviewed-by: Simon Glass 
> >> > Signed-off-by: Maxime Ripard 
> >>
> >> I get a build error when enabling CONFIG_ENV_IS_IN_SPI_FLASH and
> >> CONFIG_ENV_IS_IN_MMC at the same time.
> > 
> > Is that happening in any of the current defconfig right now? Or is it
> > only when you add more environments?
> 
> No, this is with my own config. I'm trying out the new feature :-)
> 
> > 
> >> The build error is in host tools, not in U-Boot or SPL itself. In fact, 
> >> this
> >> is not specific to CONFIG_ENV_IS_IN_SPI_FLASH but to the combination of
> >> CONFIG_ENV_IS_IN_MMC and any of the environments marked as ENVCRC- in
> >> tools/Makefile.
> >>
> >> The actual error is that the compiler does not know standard types in efi.h
> >> and mmc.h, e.g.:
> >> In file included from include/blk.h:11:0,
> >>  from include/part.h:10,
> >>  from include/mmc.h:16,
> >>  from include/environment.h:168,
> >>  from ./tools/../env/embedded.c:16,
> >>  from tools/env/embedded.c:2:
> >> include/efi.h:32:2: error: unknown type name ‘u8’
> >>   u8 b[16];
> >>   ^~
> >>
> >> I can't think of a correct fix right now...
> > 
> > I'm not sure what it could be either, that file looks like it would
> > need a quite big rework, in order to be able to operate properly.
> > 
> > Do you actually need those? Maybe we can just disable those in Kconfig
> > to forbid such a combination?
> 
> I planned to have the environment in both SPI flash and eMMC to
> be able to use a common U-Boot binary accross multiple boards.
> 
> I don't need 'tools/envcrc' though. And this is where the build
> error is.
> 
> Maybe we could disable the combination for 'tools/envcrc' only?

Apparently, envcrc is used to generate the CRC of an embedded
environment image inside the U-Boot image, which would be triggered in
some specific cases.

I'm not sure we can disable it without breaking use cases.

in this particular case, it seems that the u8 typedef is done at the
architecture level, and efi.h doesn't include asm/types.h that define
it. Maybe it's as simple as that. Otherwise, it includes linux/types.h
that defines uint8_t, we can use that instead.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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] serial: Make full device search optional

[Derald Woods]

On Mon, Feb 5, 2018 at 3:42 AM, Alexander Graf  wrote:

>
>
> On 05.02.18 01:39, Derald Woods wrote:
> > On Tue, Jan 30, 2018 at 7:34 AM, Alexander Graf  > > wrote:
> >
> > 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 test
> > ​s.
> >
> >
> >
> > ​It looks like some compiler issue is causing the problem. I was using
> > GCC 7.2.0. When I go back to GCC 6.4.0 the board boots with
> > SERIAL_SEARCH_ALL=y. I also verified this by enabling SPL_DM_SERIAL on
> > 'omap3_beagle' and booting with SERIAL_SEARCH_ALL=y. Both GCC versions
> > compiled without error. GCC 6.4.0 is the compiler version that is
> > working for me now. The actual offending generated code will take more
> > time, for me, to sort through.
>
> Can you somehow make it break with omap3_beagle? I have one of those and
> could then help debug.
>


​No. Not with the current default configurations. I have both the
beagleboard(3530) and beagleboard-xM(3730) at home. Their configuration
currently does not enable DM_SERIAL/SPL_DM_SERIAL. I just recently added
OF_CONTROL for them on U-Boot master. The code path is different for
without DM_SERIAL. Enabling DM_SERIAL will aid in comparison, but will
require dropping some config options to make it fit into SRAM. The '-xM'
does not have NAND. On the omap3_evm, I enable UBI in the default config.
So their are at least a couple of options that would not apply to both
beagle variants. There should probably be a separate default config file
for each variant. The 3530 beagle variant would/should be identical to the
omap3_evm. They are somewhat related from a historical perspective. I will
put together an update to the default configurations this week. Once that
is 

Re: [U-Boot] [PATCH v4 2/2] imx: mx7: run sec_init for CAAM RNG

[Fabio Estevam]

On Mon, Feb 5, 2018 at 10:56 AM, Stefano Babic  wrote:

>
> Yes, thanks, I applied this yesterday. It is still in u-boot-imx, but it
> will go soon into Tom's tree.

Actually Tom has already applied it :-)
http://git.denx.de/?p=u-boot.git;a=commit;h=22191ac353445ad8fafc5a78aefcd94e78963041
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/2] imx: mx7: run sec_init for CAAM RNG

[Stefano Babic]

On 05/02/2018 13:07, Fabio Estevam wrote:
> Hi Bryan,
> 
> On Mon, Feb 5, 2018 at 10:01 AM, Bryan O'Donoghue
>  wrote:
> 
>> Thanks,
>>
>> Could you apply these two also ?
>>
>> [PATCH v4 1/2] drivers/crypto/fsl: assign job-rings to non-TrustZone
> 
> Stefano has already applied it:
> http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=22191ac353445ad8fafc5a78aefcd94e78963041
> 

Yes, thanks, I applied this yesterday. It is still in u-boot-imx, but it
will go soon into Tom's tree.

>> [PATCH] crypto/fsl: instantiate all rng state handles
> 
> This one should go via York Sun's tree. Please resend this patch with him on 
> Cc.
> 

Right - added York in CC. Patch is already assigned to him, you should
not need to repost it.

Regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Adam Ford]

On Mon, Feb 5, 2018 at 3:08 AM,   wrote:
> Hi Adam,
>
> On 04.02.2018 15:46, Adam Ford wrote:
>> This converts the following to Kconfig:
>>CONFIG_APBH_DMA
>>CONFIG_APBH_DMA_BURST
>>CONFIG_APBH_DMA_BURST8
>
>
> I recently sent a patch which completely converts NAND_MXS to Kconfig
>
> https://patchwork.ozlabs.org/patch/868797/

Cool, thanks!
>
> Can you rebase ontop of it?
>
Absolutely

> Since APBH DMA is used for the GPMI NAND block only (afaict) we can
> easily let Kconfig handle the dependency.
>

That makes sense.

> E.g. in drivers/mtd/nand/Kconfig, add:
>
> config NAND_MXS
> ...
> select APBH_DMA
> select APBH_DMA_BURST if ARCH_MX6 || ARCH_MX7
> select APBH_DMA_BURST8 if ARCH_MX6 || ARCH_MX7
>
>
> With that, you should be able to implement your change with just
> removing APBH_DMA from the headers and adding the dependency to Kconfig
> files without any defconfig changes.
>

I'll try to do that later today.

adam

> --
> Stefan
>
>>
>> Signed-off-by: Adam Ford 
>> ---
>>  configs/apx4devkit_defconfig|  1 +
>>  configs/aristainetos2_defconfig |  3 +++
>>  configs/aristainetos2b_defconfig|  3 +++
>>  configs/aristainetos_defconfig  |  3 +++
>>  configs/bg0900_defconfig|  1 +
>>  configs/cm_fx6_defconfig| 11 +++
>>  configs/colibri_imx7_defconfig  |  3 +++
>>  configs/gwventana_nand_defconfig|  3 +++
>>  configs/imx6q_logic_defconfig   |  3 +++
>>  configs/imx6qdl_icore_nand_defconfig|  3 +++
>>  configs/imx6ul_geam_nand_defconfig  |  3 +++
>>  configs/imx6ul_isiot_nand_defconfig |  3 +++
>>  configs/m28evk_defconfig|  1 +
>>  configs/mx23_olinuxino_defconfig|  1 +
>>  configs/mx23evk_defconfig   |  1 +
>>  configs/mx28evk_auart_console_defconfig |  1 +
>>  configs/mx28evk_defconfig   |  1 +
>>  configs/mx28evk_nand_defconfig  |  1 +
>>  configs/mx28evk_spi_defconfig   |  1 +
>>  configs/mx6sabreauto_defconfig  |  3 +++
>>  configs/mx6sxsabreauto_defconfig|  3 +++
>>  configs/pcm058_defconfig|  3 +++
>>  configs/pfla02_defconfig|  3 +++
>>  configs/platinum_picon_defconfig|  3 +++
>>  configs/platinum_titanium_defconfig |  3 +++
>>  configs/sansa_fuze_plus_defconfig   |  1 +
>>  configs/sc_sps_1_defconfig  |  1 +
>>  configs/titanium_defconfig  |  3 +++
>>  configs/ts4600_defconfig|  1 +
>>  configs/xfi3_defconfig  |  1 +
>>  drivers/dma/Kconfig | 14 ++
>>  include/configs/aristainetos-common.h   |  3 ---
>>  include/configs/cm_fx6.h|  3 ---
>>  include/configs/colibri_imx7.h  |  3 ---
>>  include/configs/gw_ventana.h|  3 ---
>>  include/configs/imx6-engicam.h  |  4 
>>  include/configs/imx6_logic.h|  3 ---
>>  include/configs/mx6sabreauto.h  |  3 ---
>>  include/configs/mx6sxsabreauto.h|  3 ---
>>  include/configs/mx7dsabresd.h   |  3 ---
>>  include/configs/mxs.h   |  1 -
>>  include/configs/pcm058.h|  3 ---
>>  include/configs/pfla02.h|  3 ---
>>  include/configs/platinum.h  |  3 ---
>>  include/configs/titanium.h  |  3 ---
>>  scripts/config_whitelist.txt|  3 ---
>>  46 files changed, 78 insertions(+), 52 deletions(-)
>>
>> diff --git a/configs/apx4devkit_defconfig b/configs/apx4devkit_defconfig
>> index 47a4ee9..f7d868d 100644
>> --- a/configs/apx4devkit_defconfig
>> +++ b/configs/apx4devkit_defconfig
>> @@ -26,6 +26,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>>
>> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root)"
>>  CONFIG_CMD_UBI=y
>>  CONFIG_ENV_IS_IN_NAND=y
>> +CONFIG_APBH_DMA=y
>>  CONFIG_MMC_MXS=y
>>  CONFIG_USB=y
>>  CONFIG_USB_EHCI_HCD=y
>> diff --git a/configs/aristainetos2_defconfig 
>> b/configs/aristainetos2_defconfig
>> index 288dab0..926f07f 100644
>> --- a/configs/aristainetos2_defconfig
>> +++ b/configs/aristainetos2_defconfig
>> @@ -31,6 +31,9 @@ CONFIG_CMD_FAT=y
>>  CONFIG_CMD_FS_GENERIC=y
>>  CONFIG_CMD_UBI=y
>>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>> +CONFIG_APBH_DMA=y
>> +CONFIG_APBH_DMA_BURST=y
>> +CONFIG_APBH_DMA_BURST8=y
>>  CONFIG_SPI_FLASH=y
>>  CONFIG_SPI_FLASH_STMICRO=y
>>  CONFIG_MTD_UBI_FASTMAP=y
>> diff --git a/configs/aristainetos2b_defconfig 
>> b/configs/aristainetos2b_defconfig
>> index 115ae07..9ab7002 100644
>> --- a/configs/aristainetos2b_defconfig
>> +++ b/configs/aristainetos2b_defconfig
>> @@ -31,6 +31,9 @@ CONFIG_CMD_FAT=y
>>  CONFIG_CMD_FS_GENERIC=y
>>  CONFIG_CMD_UBI=y
>>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>> +CONFIG_APBH_DMA=y
>> +CONFIG_APBH_DMA_BURST=y
>> +CONFIG_APBH_DMA_BURST8=y
>>  CONFIG_SPI_FLASH=y
>>  CONFIG_SPI_FLASH_STMICRO=y
>>  CONFIG_MTD_UBI_FASTMAP=y

[U-Boot] I210 serdes fails to auto negotiate

[John Kading]

Hi u-boot community!



I am working on a x86 processor with 4 Intel I210 network interfaces.



When U-Boot comes up, it probes the 4 devices and assigns the e1000 driver.



6:0.0 0x157c // PCI_DEVICE_ID_INTEL_I210_SERDES_FLASHLESS

7:0.0 0x157c // PCI_DEVICE_ID_INTEL_I210_SERDES_FLASHLESS

8:0.0 0x157b // PCI_DEVICE_ID_INTEL_I210_COPPER_FLASHLESS

9:0.0 0x157b // PCI_DEVICE_ID_INTEL_I210_COPPER_FLASHLESS



The dhcp command works great with the copper flashless interfaces -- off
and away I go.



The SERDES interface does not behave. It times out in
e1000_copper_link_autoneg() function. It is not quite clear to me if the
serdes version of the i210 should be going through auto negotiation. If I
comment out the copper autoneg as shown below, I can get the link to come
up and dhcp.





@@ -3088,9 +3103,11 @@ e1000_setup_copper_link(struct e1000_hw *hw)

  /* always auto */

  /* Setup autoneg and flow control advertisement

* and perform autonegotiation */

+/*

  ret_val = e1000_copper_link_autoneg(hw);

  if (ret_val)

 return ret_val;

+*/



I noticed that even though there are 3 media types, copper, serdes, and
fiber -- i210 only has link logic for copper and fiber. I wondered if the
media_type should be serdes. I rewrote a little bit of the code so that
this serdes version of the I210 would be media type serdes.

+ case PCI_DEVICE_ID_INTEL_I210_SERDES_FLASHLESS:

 hw->media_type = e1000_media_type_internal_serd
es;

 break;



I modified the setup link function so that it would not call
e1000_setup_copper_link(hw) to avoid the auto negotiation. This works...



Ok, so it sure seems like I am running up against a bug here, but a little
lost on how to fix this. Has anybody else run into this issue where the
i210 serdes (0x157c) fails to detect link because it times out during auto
negotiation? Is there a reason this device is considered a
e1000_media_type_copper rather than a e1000_media_type_internal_serdes? Or
is this a bug? Any advice for how I should proceed?



Any help is much appreciated!



By the way, I am using the tag v2017.07, however no changes in
drivers/net/e1000.c since then.



Thanks,

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

[Javier Santos Romo]

Hi Simon,

Thanks for your support. We just need a x64 bootloader because we are using a 
64-bit EFI. We understood, reading README.efi file from U-boot documentation 
that we could use u-boot like an 64-bit payload. However, we don´t understand 
why we get the memory map error. Anyway, we will consider other possibilities.

Thanks a lot,
BR















-Mensaje original-
De: s...@google.com [mailto:s...@google.com] En nombre de Simon Glass
Enviado el: domingo, 4 de febrero de 2018 14:41
Para: Javier Santos Romo 
CC: u-boot@lists.denx.de; bmeng...@gmail.com; Juan Alfonso Reyes Ajenjo 

Asunto: Re: Uboot as x86_64 EFI payload

Hi Javier,

On 29 January 2018 at 09:36, Javier Santos Romo  wrote:

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

Are you using 64-bit EFI or 32-bit?

I think you was CONFIG_EFI_STUB_64BIT

See doc/README.efi for some info about this. Note this this option makes the 
stub run as a 64-bit EFI app, but U-Boot itself is still only 32-bit.

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

This is for running U-Boot itself as a 64-bit app. This is not currently 
supported as an EFI payload, only as a bar-metal U-Boot (not run from EFI).

The meaning of the comment is that on 32-bit x86 we use the FS register to 
store gd. See:

#define gd  get_fs_gd_ptr()

We could potentially make gd use a fixed x86 register on 64-bit x86 as well. 
This comment is about considering that.

Regards,
Simon


>
>
>
> Thank you very much,
>
>
>
> Best regards,
>
> 
>
> 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
>
>
>
>
>
>
>
>
> P Please consider the environment before printing this e-mail.
>
>
> P Please consider the environment before printing this e-mail.

What does this mean?

>
> 
> 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. Thank you.
> 
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener 
> información clasificada por su emisor como confidencial en el marco de su 
> Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo 
> del destinatario, quedando prohibida su divulgación copia o distribución a 
> terceros sin la autorización expresa del remitente. Si Vd. ha recibido este 
> mensaje erróneamente, se ruega lo notifique al remitente y proceda a su 
> borrado. Gracias por su colaboración.
> 
> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação 
> confidencial, de acordo com nosso Sistema de Gestão de Segurança da 
> Informação, sendo para uso exclusivo do destinatário e estando proibida a sua 
> divulgação, cópia ou distribuição a terceiros sem autorização expressa do 
> remetente da 

Re: [U-Boot] [PATCH v4 2/2] imx: mx7: run sec_init for CAAM RNG

[Fabio Estevam]

Hi Bryan,

On Mon, Feb 5, 2018 at 10:01 AM, Bryan O'Donoghue
 wrote:

> Thanks,
>
> Could you apply these two also ?
>
> [PATCH v4 1/2] drivers/crypto/fsl: assign job-rings to non-TrustZone

Stefano has already applied it:
http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=22191ac353445ad8fafc5a78aefcd94e78963041

> [PATCH] crypto/fsl: instantiate all rng state handles

This one should go via York Sun's tree. Please resend this patch with him on Cc.

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

Re: [U-Boot] [PATCH v4 2/2] imx: mx7: run sec_init for CAAM RNG

[Bryan O'Donoghue]

On 04/02/18 10:31, Stefano Babic wrote:

On 26/01/2018 17:27, Bryan O'Donoghue wrote:

This patch adds a sec_init call into arch_misc_init(). Doing so in
conjunction with the patch "drivers/crypto/fsl: assign job-rings to
non-TrustZone" enables use of the CAAM in Linux when OPTEE/TrustZone is
active.

u-boot will initialise the RNG and assign ownership of the job-ring
registers to a non-TrustZone context. With recent changes by Lukas Auer to
fully initialize the RNG in sec_init() this means that u-boot will hand-off
the CAAM in a state that Linux then can use the CAAM without touching the
reserved DECO registers.

This change is safe both for the OPTEE/TrustZone boot path and the regular
non-OPTEE/TrustZone boot path.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Marco Franchi 
Cc: Vanessa Maegima 
Cc: Stefano Babic 
Cc: Lukas Auer 
---
  arch/arm/mach-imx/mx7/soc.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index d160e80..d444046 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #if defined(CONFIG_IMX_THERMAL)

  static const struct imx_thermal_plat imx7_thermal_plat = {
@@ -262,6 +263,10 @@ int arch_misc_init(void)
env_set("soc", "imx7s");
  #endif
  
+#ifdef CONFIG_FSL_CAAM

+   sec_init();
+#endif
+
return 0;
  }
  #endif


Applied to u-boot-imx, thanks !


Thanks,

Could you apply these two also ?

[PATCH v4 1/2] drivers/crypto/fsl: assign job-rings to non-TrustZone
[PATCH] crypto/fsl: instantiate all rng state handles

I had a plan to send out these three patches together as a series - 
since they are all required to fix the CAAM/TrustZone issue and so they 
should be treated as a set.


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

[U-Boot] [PATCH v2 3/3] board: stm32: Add set_env_soc_name() in board_late_init()

[patrice.chotard]

From: Patrice Chotard 

Add set_env_soc_name() call in board_late_init() to set environment
variable "soc_name" with the name of current STM32 SoC.

Signed-off-by: Christophe Priouzeau 
Signed-off-by: Patrice Chotard 
---
v2: _ None

 board/st/stm32f429-discovery/stm32f429-discovery.c   | 7 +++
 board/st/stm32f429-evaluation/stm32f429-evaluation.c | 7 +++
 board/st/stm32f469-discovery/stm32f469-discovery.c   | 7 +++
 board/st/stm32f746-disco/stm32f746-disco.c   | 2 ++
 board/st/stm32h743-disco/stm32h743-disco.c   | 4 
 board/st/stm32h743-eval/stm32h743-eval.c | 4 
 6 files changed, 31 insertions(+)

diff --git a/board/st/stm32f429-discovery/stm32f429-discovery.c 
b/board/st/stm32f429-discovery/stm32f429-discovery.c
index 3d90218faa61..44dcca5be508 100644
--- a/board/st/stm32f429-discovery/stm32f429-discovery.c
+++ b/board/st/stm32f429-discovery/stm32f429-discovery.c
@@ -60,6 +60,13 @@ int board_init(void)
return 0;
 }
 
+int board_late_init(void)
+{
+   set_env_soc_name();
+
+   return 0;
+}
+
 #ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
diff --git a/board/st/stm32f429-evaluation/stm32f429-evaluation.c 
b/board/st/stm32f429-evaluation/stm32f429-evaluation.c
index 25e020784d62..9041dca5937b 100644
--- a/board/st/stm32f429-evaluation/stm32f429-evaluation.c
+++ b/board/st/stm32f429-evaluation/stm32f429-evaluation.c
@@ -54,6 +54,13 @@ int board_init(void)
return 0;
 }
 
+int board_late_init(void)
+{
+   set_env_soc_name();
+
+   return 0;
+}
+
 #ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
diff --git a/board/st/stm32f469-discovery/stm32f469-discovery.c 
b/board/st/stm32f469-discovery/stm32f469-discovery.c
index 36f7b2e8e176..263d995c1534 100644
--- a/board/st/stm32f469-discovery/stm32f469-discovery.c
+++ b/board/st/stm32f469-discovery/stm32f469-discovery.c
@@ -54,6 +54,13 @@ int board_init(void)
return 0;
 }
 
+int board_late_init(void)
+{
+   set_env_soc_name();
+
+   return 0;
+}
+
 #ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index 8da70281f976..d259bb14fee3 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -115,6 +115,8 @@ int board_late_init(void)
struct gpio_desc gpio = {};
int node;
 
+   set_env_soc_name();
+
node = fdt_node_offset_by_compatible(gd->fdt_blob, 0, "st,led1");
if (node < 0)
return -1;
diff --git a/board/st/stm32h743-disco/stm32h743-disco.c 
b/board/st/stm32h743-disco/stm32h743-disco.c
index 226b7045d278..d4ad9230c06e 100644
--- a/board/st/stm32h743-disco/stm32h743-disco.c
+++ b/board/st/stm32h743-disco/stm32h743-disco.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+#include 
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int dram_init(void)
@@ -46,6 +48,8 @@ u32 get_board_rev(void)
 
 int board_late_init(void)
 {
+   set_env_soc_name();
+
return 0;
 }
 
diff --git a/board/st/stm32h743-eval/stm32h743-eval.c 
b/board/st/stm32h743-eval/stm32h743-eval.c
index 226b7045d278..d4ad9230c06e 100644
--- a/board/st/stm32h743-eval/stm32h743-eval.c
+++ b/board/st/stm32h743-eval/stm32h743-eval.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+#include 
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int dram_init(void)
@@ -46,6 +48,8 @@ u32 get_board_rev(void)
 
 int board_late_init(void)
 {
+   set_env_soc_name();
+
return 0;
 }
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/3] mach-stm32: Add set_env_soc_name support

[patrice.chotard]

From: Patrice Chotard 

This allows to create and set the environment variable
"soc_name" which contains the current STM32 SoC's name.

Signed-off-by: Christophe Priouzeau 
Signed-off-by: Patrice Chotard 
---

v2: _ Remove get_cpu_id() function and use directly CONFIG_STM32xx flag
  to identify the STM32 SoC family.


 arch/arm/include/asm/arch-stm32f4/stm32.h |  1 +
 arch/arm/include/asm/arch-stm32f7/stm32.h |  1 +
 arch/arm/include/asm/arch-stm32h7/stm32.h |  3 +++
 arch/arm/mach-stm32/soc.c | 15 +++
 4 files changed, 20 insertions(+)

diff --git a/arch/arm/include/asm/arch-stm32f4/stm32.h 
b/arch/arm/include/asm/arch-stm32f4/stm32.h
index 0449fcecede0..d4b0c40804c0 100644
--- a/arch/arm/include/asm/arch-stm32f4/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f4/stm32.h
@@ -50,5 +50,6 @@ static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
 };
 
 void stm32_flash_latency_cfg(int latency);
+void set_env_soc_name(void);
 
 #endif /* _MACH_STM32_H_ */
diff --git a/arch/arm/include/asm/arch-stm32f7/stm32.h 
b/arch/arm/include/asm/arch-stm32f7/stm32.h
index f54e6f195575..315d2a14790c 100644
--- a/arch/arm/include/asm/arch-stm32f7/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f7/stm32.h
@@ -63,5 +63,6 @@ static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
 
 
 void stm32_flash_latency_cfg(int latency);
+void set_env_soc_name(void);
 
 #endif /* _ASM_ARCH_HARDWARE_H */
diff --git a/arch/arm/include/asm/arch-stm32h7/stm32.h 
b/arch/arm/include/asm/arch-stm32h7/stm32.h
index f2922aa3237e..9377c5d65bfb 100644
--- a/arch/arm/include/asm/arch-stm32h7/stm32.h
+++ b/arch/arm/include/asm/arch-stm32h7/stm32.h
@@ -18,4 +18,7 @@
  * arch/arm/include/asm/arch-stm32f4/stm32.h
  * arch/arm/include/asm/arch-stm32f7/stm32.h
  */
+
+void set_env_soc_name(void);
+
 #endif /* _ASM_ARCH_HARDWARE_H */
diff --git a/arch/arm/mach-stm32/soc.c b/arch/arm/mach-stm32/soc.c
index df20d547c500..06ca61b270cf 100644
--- a/arch/arm/mach-stm32/soc.c
+++ b/arch/arm/mach-stm32/soc.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int arch_cpu_init(void)
 {
@@ -54,3 +55,17 @@ int arch_cpu_init(void)
 
return 0;
 }
+
+void set_env_soc_name(void)
+{
+   char soc[16];
+
+#ifdef CONFIG_STM32F4
+   snprintf(soc, sizeof(soc), "stm32f4");
+#elif CONFIG_STM32F7
+   snprintf(soc, sizeof(soc), "stm32f7");
+#elif CONFIG_STM32H7
+   snprintf(soc, sizeof(soc), "stm32h7");
+#endif
+   env_set("soc_name", soc);
+}
-- 
1.9.1

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

[U-Boot] [PATCH v2 2/3] mach-stm32: Move BOARD_LATE_INIT flag to mach-stm32 Kconfig

[patrice.chotard]

From: Patrice Chotard 

Move BOARD_LATE_INIT flag from include/configs/stm32*.h to
mach-stm32/Kconfig.
Enable this flag also for STM32F4 SoCs family.

Signed-off-by: Patrice Chotard 
---

v2: _ None

 arch/arm/mach-stm32/Kconfig   | 3 +++
 include/configs/stm32f746-disco.h | 1 -
 include/configs/stm32h743-disco.h | 1 -
 include/configs/stm32h743-eval.h  | 1 -
 4 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
index f79b1a2c700e..c734a0ab8768 100644
--- a/arch/arm/mach-stm32/Kconfig
+++ b/arch/arm/mach-stm32/Kconfig
@@ -13,6 +13,7 @@ config STM32F4
select STM32_RCC
select STM32_RESET
select STM32_SERIAL
+   select BOARD_LATE_INIT
 
 config STM32F7
bool "stm32f7 family"
@@ -27,6 +28,7 @@ config STM32F7
select STM32_RCC
select STM32_RESET
select STM32_SERIAL
+   select BOARD_LATE_INIT
select SUPPORT_SPL
select SPL
select SPL_BOARD_INIT
@@ -63,6 +65,7 @@ config STM32H7
select STM32_RESET
select STM32_SERIAL
select SYSCON
+   select BOARD_LATE_INIT
 
 source "arch/arm/mach-stm32/stm32f4/Kconfig"
 source "arch/arm/mach-stm32/stm32f7/Kconfig"
diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index 3e952c2acd82..ae6889584a03 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -65,7 +65,6 @@
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CONFIG_CMD_CACHE
-#define CONFIG_BOARD_LATE_INIT
 #define CONFIG_DISPLAY_BOARDINFO
 
 /* For SPL */
diff --git a/include/configs/stm32h743-disco.h 
b/include/configs/stm32h743-disco.h
index 531de701492a..44b2813d3eeb 100644
--- a/include/configs/stm32h743-disco.h
+++ b/include/configs/stm32h743-disco.h
@@ -46,6 +46,5 @@
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CONFIG_CMD_CACHE
-#define CONFIG_BOARD_LATE_INIT
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/stm32h743-eval.h b/include/configs/stm32h743-eval.h
index 531de701492a..44b2813d3eeb 100644
--- a/include/configs/stm32h743-eval.h
+++ b/include/configs/stm32h743-eval.h
@@ -46,6 +46,5 @@
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CONFIG_CMD_CACHE
-#define CONFIG_BOARD_LATE_INIT
 
 #endif /* __CONFIG_H */
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/3] Add set_env_soc_name() for STM32 SoCs

[patrice.chotard]

From: Patrice Chotard 

This series allows to create and set the environment variable 
"soc_name" corresponding to the current STM32 SoCs name.

We will add STM32 SoCs support in buildroot environment
Our objective is to propose a flexible solution to boot linux
kernel from sdcard.

As for STM32F4, STM32F7 and STM32H7 linux defconfig is slightly
different (specific CONFIG_DRAM_BASE and CONFIG_DRAM_SIZE) we can't use
the same zImage for all these SoCs.

To simplify, we will embed all dtb/zImage in the sdcard and using the
soc_name environment variable to select the correct zImage. 

v2: _ Remove get_cpu_id() function and use directly CONFIG_STM32xx flag
  to identify the STM32 SoC family.


Patrice Chotard (8):
  mach-stm32: Add get_cpu_id support
  mach-stm32: Move BOARD_LATE_INIT flag to mach-stm32 Kconfig
  board: stm32: Add set_env_soc_name() in board_late_init()

 arch/arm/include/asm/arch-stm32f4/stm32.h|  1 +
 arch/arm/include/asm/arch-stm32f7/stm32.h|  1 +
 arch/arm/include/asm/arch-stm32h7/stm32.h|  3 +++
 arch/arm/mach-stm32/Kconfig  |  3 +++
 arch/arm/mach-stm32/soc.c| 15 +++
 board/st/stm32f429-discovery/stm32f429-discovery.c   |  7 +++
 board/st/stm32f429-evaluation/stm32f429-evaluation.c |  7 +++
 board/st/stm32f469-discovery/stm32f469-discovery.c   |  7 +++
 board/st/stm32f746-disco/stm32f746-disco.c   |  2 ++
 board/st/stm32h743-disco/stm32h743-disco.c   |  4 
 board/st/stm32h743-eval/stm32h743-eval.c |  4 
 include/configs/stm32f746-disco.h|  1 -
 include/configs/stm32h743-disco.h|  1 -
 include/configs/stm32h743-eval.h |  1 -
 14 files changed, 54 insertions(+), 3 deletions(-)

-- 
1.9.1

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

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Mark Kettenis]

> Date: Mon, 5 Feb 2018 21:06:59 +1100
> From: Jonathan Gray 
> 
> > > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > >  failed(6). will try /bsd
> > 
> > How do you find out that it's sd0a instead of sd1a?
> 
> The loaded image protocol I believe.

Actually the OpenBSD bootloader currently only supports loading the
bsd kernel from the same device as the bootloader.  It will always
call that device sd0.  It invokes the device path protocol on the
loaded image handle and then matches that path to a device that
supports the block io protocol.

> > The only thing I can think of that changed with this commit is that now
> > we're honoring the device tree's pinmuxing rules. So if the DT wants to
> > use the sdhost mmc controller instead of the sdhci one, it will actually
> > get muxed there. Before, we didn't mux, so on the rpi3 we just happened
> > to run on the sdhci.
> > 
> > At least the default Linux dtb uses sdhost for SD card access.
> > 
> > So maybe all that happened was a change in device numbers because we end
> > up creating device nodes for mmc devices that don't have a card plugged
> > in (sdhci).
> > 
> > In that case however, I guess it means you really were booting from MMC
> > before, rather than USB?
> 
> There is no driver for either broadcom mmc controller in OpenBSD.
> U-Boot is loaded of the sd card, then bootaa64.efi is loaded
> from usb via "boot_targets=usb0 mmc0 pxe dhcp" and distro bootcmd.
> Root filesystem is then on usb.

Right.  So what the bootloader calls sd0 above is really the usb disk.

> > > boot>
> > > 
> > > U-Boot> part list mmc 0
> > > 
> > > Partition Map for MMC device 0  --   Partition Type: DOS
> > > 
> > > PartStart SectorNum Sectors UUIDType
> > >   1 81928192-01 0c Boot
> > >   4 16384   26624   -04 a6
> > > U-Boot> part list usb 0
> > > 
> > > Partition Map for USB device 0  --   Partition Type: DOS
> > > 
> > > PartStart SectorNum Sectors UUIDType
> > >   1 819232768   -01 0c Boot
> > >   4 40960   60021540-04 a6
> > > U-Boot> ls mmc 0:1 /
> > 
> > I assume "ls usb 0:1 /" also works?
> 
> U-Boot> ls usb 0:1 /
> efi/
> 50248   bootcode.bin
>   2820196   start.elf
>  6551   fixup.dat
> 17794   bcm2710-rpi-3-b.dtb
> 16550   bcm2710-rpi-cm3.dtb
>422776   u-boot.bin
>76   config.txt
> 
> 7 file(s), 1 dir(s)
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Jonathan Gray]

On Mon, Feb 05, 2018 at 09:37:15AM +0100, Alexander Graf wrote:
> 
> 
> On 03.02.18 12:38, Jonathan Gray wrote:
> > On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 03.02.18 02:47, Jonathan Gray wrote:
> >>> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
>  On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> 
> > The bcm283x family of SoCs have a GPIO controller that also acts as
> > pinctrl controller.
> >
> > This patch introduces a new pinctrl driver that can actually properly 
> > mux
> > devices into their device tree defined pin states and is now the primary
> > owner of the gpio device. The previous GPIO driver gets moved into a
> > subdevice of the pinctrl driver, bound to the same OF node.
> >
> > That way whenever a device asks for pinctrl support, it gets it
> > automatically from the pinctrl driver and GPIO support is still 
> > available
> > in the normal command line phase.
> >
> > Signed-off-by: Alexander Graf 
> 
>  Applied to u-boot/master, thanks!
> >>>
> >>> It seems one of the recent commits here has broken booting on rpi_3 with
> >>> the vendor supplied device tree via efi_loader.
> >>
> >> Do you have a pointer to the dtb? I'm actually using the vendor supplied
> >> device tree to boot, but I don't specify it, I just leave it to the RPi
> >> fw to pass it in.
> >>
> >> Can you please go into detail on your setup?
> >>
> >>
> >> Alex
> > 
> > Sure.  Using the most recent release of the firmware
> > https://github.com/raspberrypi/firmware/releases/tag/1.20171029
> > 
> > https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb
> > 
> > dtb is placed in the root of the fat partition and loaded by the
> > firmware, it is not placed in a 'broadcom' or 'dtb' directory.
> > 
> > MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb
> > MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508
> > MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de
> > MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a
> > 
> > $ cat config.txt
> > arm_control=0x200
> > enable_uart=1
> > device_tree_address=0x100
> > kernel=u-boot.bin
> > 
> > These files are included in the installation disk image for OpenBSD/arm64
> > (along with u-boot.bin):
> > 
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> > 
> > In the setup I use U-Boot is loaded off sd card with boot target set to
> > prefer usb (fuse to enable usb boot isn't blown).  distro bootcmd finds
> > bootaa64.efi and loads that.
> > 
> > With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:
> 
> Are you using the defconfig or do you set CONFIG_OF_BOARD to fetch the
> U-Boot DT from firmware?

defconfig with no changes

> 
> > 
> > U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)
> > 
> > DRAM:  948 MiB
> > RPI 3 Model B (0xa02082)
> > MMC:   mmc@7e202000: 0, sdhci@7e30: 1
> > Loading Environment from FAT... OK
> > In:serial
> > Out:   vidconsole
> > Err:   vidconsole
> > Net:   No ethernet found.
> > starting USB...
> > 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
> > Hit any key to stop autoboot:  0
> > U-Boot> printenv
> > arch=arm
> > baudrate=115200
> > board=rpi
> > board_name=3 Model B
> > board_rev=0x8
> > board_rev_scheme=1
> > board_revision=0xA02082
> > boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} 
> > ${prefix}${script}; source ${scriptaddr}
> > boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} 
> > ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then 
> > bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} 
> > ${fdtcontroladdr};fi
> > boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any 
> > ${scriptaddr} ${prefix}extlinux/extlinux.conf
> > boot_net_usb_start=usb start
> > boot_prefixes=/ /boot/
> > boot_script_dhcp=boot.scr.uimg
> > boot_scripts=boot.scr.uimg boot.scr
> > boot_targets=usb0 mmc0 pxe dhcp
> > bootcmd=run distro_bootcmd
> > bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} 
> > ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile 
> > ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch 
> > ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv 
> > bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} 
> > dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} 
> > ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv 
> > bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv 
> > efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> > bootcmd_mmc0=setenv devnum 0; run mmc_boot
> > bootcmd_pxe=run 

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

[Alexander Graf]

On 05.02.18 01:39, Derald Woods wrote:
> On Tue, Jan 30, 2018 at 7:34 AM, Alexander Graf  > wrote:
> 
> 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 test
> ​s.
> 
> 
>  
> ​It looks like some compiler issue is causing the problem. I was using
> GCC 7.2.0. When I go back to GCC 6.4.0 the board boots with
> SERIAL_SEARCH_ALL=y. I also verified this by enabling SPL_DM_SERIAL on
> 'omap3_beagle' and booting with SERIAL_SEARCH_ALL=y. Both GCC versions
> compiled without error. GCC 6.4.0 is the compiler version that is
> working for me now. The actual offending generated code will take more
> time, for me, to sort through.

Can you somehow make it break with omap3_beagle? I have one of those and
could then help debug.


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

Re: [U-Boot] [PATCH 0/8] Add get_cpu_id for STM32 SoCs

[Patrice CHOTARD]

Hi Vikas

On 02/02/2018 06:20 PM, Vikas Manocha wrote:
> Hi Patrice,
> 
> On 02/02/2018 12:22 AM, Patrice CHOTARD wrote:
>> +Christophe Priouzeau who is the requester/developper of this feature
>>
>>
>> On 01/31/2018 07:22 PM, Vikas Manocha wrote:
>>> Hi Patrice,
>>>
>>> On 01/31/2018 08:08 AM, patrice.chot...@st.com wrote:
 From: Patrice Chotard 

 This series allows to get the cpu id of STM32 SoCs and to set
 the environment variable "soc_name" with the corresponding SoC name.

 This will be useful in some development environment to retrieve files
 correspondig to SoC family.
>>>
>>> can you provide some example ? We have the device tree compatible string to 
>>> distinguish board & soc.
>>
>> We will add STM32 SoCs support in buildroot environment
>> Our objective is to propose a flexible solution to boot linux
>> kernel from sdcard.
>>
>> As for STM32F4, STM32F7 and STM32H7 linux defconfig is slightly
>> different (specific CONFIG_DRAM_BASE and CONFIG_DRAM_SIZE) we can't use
>> the same zImage for all these SoCs.
>>
>> To simplify, we will embed all dtb/zImage in the sdcard and using the
>> soc_name environment variable to select the correct zImage.
> 
> soc name is already part of configuration (SYS_SOC). It would be simpler and 
> less expensive (for both cpu & memory) to use it.
> In this patchset, 56 Bytes(currently, which will increase with more SOCs 
> support) of lookup table are becoming part of text apart from the additional 
> code.

Ok i got your point, i will rework this series

Thanks

Patrice

> 
> Cheers,
> Vikas
> 
>>
>> Patrice
>>
>>
>>>
>>> Cheers,
>>> Vikas
>>>

 Patrice Chotard (8):
 mach-stm32: Add get_cpu_id support
 mach-stm32: Move BOARD_LATE_INIT flag to mach-stm32 Kconfig
 board: stm32f429-discovery: Add set_env_soc_name() in
   board_late_init()
 board: stm32h743-evaluation: Add set_env_soc_name() in
   board_late_init()
 board: stm32f743-discovery: Add set_env_soc_name() in
   board_late_init()
 board: stm32f469-discovery: Add set_env_soc_name() in
   board_late_init()
 board: stm32f469-discovery: Add set_env_soc_name() in
   board_late_init()
 board: stm32f429-evaluation: Add set_env_soc_name() in
   board_late_init()

arch/arm/include/asm/arch-stm32f4/stm32.h  |  2 +
arch/arm/include/asm/arch-stm32f7/stm32.h  |  2 +
arch/arm/include/asm/arch-stm32h7/stm32.h  |  4 ++
arch/arm/mach-stm32/Kconfig|  3 ++
arch/arm/mach-stm32/soc.c  | 46 
 ++
board/st/stm32f429-discovery/stm32f429-discovery.c |  7 
.../st/stm32f429-evaluation/stm32f429-evaluation.c |  7 
board/st/stm32f469-discovery/stm32f469-discovery.c |  7 
board/st/stm32f746-disco/stm32f746-disco.c |  2 +
board/st/stm32h743-disco/stm32h743-disco.c |  4 ++
board/st/stm32h743-eval/stm32h743-eval.c   |  4 ++
include/configs/stm32f746-disco.h  |  1 -
include/configs/stm32h743-disco.h  |  1 -
include/configs/stm32h743-eval.h   |  1 -
14 files changed, 88 insertions(+), 3 deletions(-)

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

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

[stefan]

Hi Adam,

On 04.02.2018 15:46, Adam Ford wrote:
> This converts the following to Kconfig:
>CONFIG_APBH_DMA
>CONFIG_APBH_DMA_BURST
>CONFIG_APBH_DMA_BURST8


I recently sent a patch which completely converts NAND_MXS to Kconfig

https://patchwork.ozlabs.org/patch/868797/

Can you rebase ontop of it?

Since APBH DMA is used for the GPMI NAND block only (afaict) we can
easily let Kconfig handle the dependency.

E.g. in drivers/mtd/nand/Kconfig, add:

config NAND_MXS
...
select APBH_DMA
select APBH_DMA_BURST if ARCH_MX6 || ARCH_MX7
select APBH_DMA_BURST8 if ARCH_MX6 || ARCH_MX7


With that, you should be able to implement your change with just
removing APBH_DMA from the headers and adding the dependency to Kconfig
files without any defconfig changes.

--
Stefan

> 
> Signed-off-by: Adam Ford 
> ---
>  configs/apx4devkit_defconfig|  1 +
>  configs/aristainetos2_defconfig |  3 +++
>  configs/aristainetos2b_defconfig|  3 +++
>  configs/aristainetos_defconfig  |  3 +++
>  configs/bg0900_defconfig|  1 +
>  configs/cm_fx6_defconfig| 11 +++
>  configs/colibri_imx7_defconfig  |  3 +++
>  configs/gwventana_nand_defconfig|  3 +++
>  configs/imx6q_logic_defconfig   |  3 +++
>  configs/imx6qdl_icore_nand_defconfig|  3 +++
>  configs/imx6ul_geam_nand_defconfig  |  3 +++
>  configs/imx6ul_isiot_nand_defconfig |  3 +++
>  configs/m28evk_defconfig|  1 +
>  configs/mx23_olinuxino_defconfig|  1 +
>  configs/mx23evk_defconfig   |  1 +
>  configs/mx28evk_auart_console_defconfig |  1 +
>  configs/mx28evk_defconfig   |  1 +
>  configs/mx28evk_nand_defconfig  |  1 +
>  configs/mx28evk_spi_defconfig   |  1 +
>  configs/mx6sabreauto_defconfig  |  3 +++
>  configs/mx6sxsabreauto_defconfig|  3 +++
>  configs/pcm058_defconfig|  3 +++
>  configs/pfla02_defconfig|  3 +++
>  configs/platinum_picon_defconfig|  3 +++
>  configs/platinum_titanium_defconfig |  3 +++
>  configs/sansa_fuze_plus_defconfig   |  1 +
>  configs/sc_sps_1_defconfig  |  1 +
>  configs/titanium_defconfig  |  3 +++
>  configs/ts4600_defconfig|  1 +
>  configs/xfi3_defconfig  |  1 +
>  drivers/dma/Kconfig | 14 ++
>  include/configs/aristainetos-common.h   |  3 ---
>  include/configs/cm_fx6.h|  3 ---
>  include/configs/colibri_imx7.h  |  3 ---
>  include/configs/gw_ventana.h|  3 ---
>  include/configs/imx6-engicam.h  |  4 
>  include/configs/imx6_logic.h|  3 ---
>  include/configs/mx6sabreauto.h  |  3 ---
>  include/configs/mx6sxsabreauto.h|  3 ---
>  include/configs/mx7dsabresd.h   |  3 ---
>  include/configs/mxs.h   |  1 -
>  include/configs/pcm058.h|  3 ---
>  include/configs/pfla02.h|  3 ---
>  include/configs/platinum.h  |  3 ---
>  include/configs/titanium.h  |  3 ---
>  scripts/config_whitelist.txt|  3 ---
>  46 files changed, 78 insertions(+), 52 deletions(-)
> 
> diff --git a/configs/apx4devkit_defconfig b/configs/apx4devkit_defconfig
> index 47a4ee9..f7d868d 100644
> --- a/configs/apx4devkit_defconfig
> +++ b/configs/apx4devkit_defconfig
> @@ -26,6 +26,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_NAND=y
> +CONFIG_APBH_DMA=y
>  CONFIG_MMC_MXS=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
> diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig
> index 288dab0..926f07f 100644
> --- a/configs/aristainetos2_defconfig
> +++ b/configs/aristainetos2_defconfig
> @@ -31,6 +31,9 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_APBH_DMA=y
> +CONFIG_APBH_DMA_BURST=y
> +CONFIG_APBH_DMA_BURST8=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_MTD_UBI_FASTMAP=y
> diff --git a/configs/aristainetos2b_defconfig 
> b/configs/aristainetos2b_defconfig
> index 115ae07..9ab7002 100644
> --- a/configs/aristainetos2b_defconfig
> +++ b/configs/aristainetos2b_defconfig
> @@ -31,6 +31,9 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_APBH_DMA=y
> +CONFIG_APBH_DMA_BURST=y
> +CONFIG_APBH_DMA_BURST8=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_MTD_UBI_FASTMAP=y
> diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig
> index cad8b4a..6c09e8d 100644
> --- a/configs/aristainetos_defconfig
> +++ b/configs/aristainetos_defconfig
> @@ -31,6 +31,9 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_UBI=y
>  

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

[Bin Meng]

Hi Miao,

On Mon, Feb 5, 2018 at 2:00 PM, Miao Yan  wrote:
> On Tue, Jan 30, 2018 at 9:01 PM, 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;
>
> qemu_fwcfg_find_file() can return NULL. Don't we need to check that ? Or
> can we assume etc/acpi/rsdp is always present ?
>
> Sorry for the late response.
>

I think you are correct. If file is NULL, we should return 0.

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

Re: [U-Boot] Minnowmax Turbot not supported

[Bin Meng]

Hi Vincenzo,

On Sat, Feb 3, 2018 at 3:34 AM, vnktux  wrote:
> Hi all,
>
> I have just received from ADI Engineering a MinnowBoard Turbot Quad-core 
> (Baytrail E3845).
> I wanted to compile bare metal U-Boot according to the README.x86 in the doc 
> folder. Unfortunately the board doesn't boot and doesn't print any 
> informations on the serial port. I know that also someone else have the same 
> problem, but I couldn't find any solutions on internet. It look like the 
> board doesn't load the correct microcode.
>
> I got the descriptor file from the original firmware.
> Then for the FSP binary I tried the one from the official Intel Github repo, 
> and also the one you can download from Intelfirmware.com called FSP Gold 2014 
> Minnowmax.
>
> From the official UEFI firmware I can see the following specs:
> CPU Family: 6
> Model: 7
> Step: 9
> Microcode: 906
> Sig: 0x30679
> PF: 0x1
>
> Did anybody succeeded to boot U-Boot on the new Turbot board?

It should not be the microcode problem as U-Boot ships
m0130679907.dtsi which is newer than what you get (906)

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

Re: [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Alexander Graf]

On 03.02.18 12:38, Jonathan Gray wrote:
> On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
>>
>>
>> On 03.02.18 02:47, Jonathan Gray wrote:
>>> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
 On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:

> The bcm283x family of SoCs have a GPIO controller that also acts as
> pinctrl controller.
>
> This patch introduces a new pinctrl driver that can actually properly mux
> devices into their device tree defined pin states and is now the primary
> owner of the gpio device. The previous GPIO driver gets moved into a
> subdevice of the pinctrl driver, bound to the same OF node.
>
> That way whenever a device asks for pinctrl support, it gets it
> automatically from the pinctrl driver and GPIO support is still available
> in the normal command line phase.
>
> Signed-off-by: Alexander Graf 

 Applied to u-boot/master, thanks!
>>>
>>> It seems one of the recent commits here has broken booting on rpi_3 with
>>> the vendor supplied device tree via efi_loader.
>>
>> Do you have a pointer to the dtb? I'm actually using the vendor supplied
>> device tree to boot, but I don't specify it, I just leave it to the RPi
>> fw to pass it in.
>>
>> Can you please go into detail on your setup?
>>
>>
>> Alex
> 
> Sure.  Using the most recent release of the firmware
> https://github.com/raspberrypi/firmware/releases/tag/1.20171029
> 
> https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb
> 
> dtb is placed in the root of the fat partition and loaded by the
> firmware, it is not placed in a 'broadcom' or 'dtb' directory.
> 
> MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb
> MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508
> MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de
> MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a
> 
> $ cat config.txt
> arm_control=0x200
> enable_uart=1
> device_tree_address=0x100
> kernel=u-boot.bin
> 
> These files are included in the installation disk image for OpenBSD/arm64
> (along with u-boot.bin):
> 
> https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> 
> In the setup I use U-Boot is loaded off sd card with boot target set to
> prefer usb (fuse to enable usb boot isn't blown).  distro bootcmd finds
> bootaa64.efi and loads that.
> 
> With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:

Are you using the defconfig or do you set CONFIG_OF_BOARD to fetch the
U-Boot DT from firmware?

> 
> U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   mmc@7e202000: 0, sdhci@7e30: 1
> Loading Environment from FAT... OK
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> 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
> Hit any key to stop autoboot:  0
> U-Boot> printenv
> arch=arm
> baudrate=115200
> board=rpi
> board_name=3 Model B
> board_rev=0x8
> board_rev_scheme=1
> board_revision=0xA02082
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} 
> ${prefix}${script}; source ${scriptaddr}
> boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} 
> efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi 
> ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} 
> ${fdtcontroladdr};fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any 
> ${scriptaddr} ${prefix}extlinux/extlinux.conf
> boot_net_usb_start=usb start
> boot_prefixes=/ /boot/
> boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_targets=usb0 mmc0 pxe dhcp
> bootcmd=run distro_bootcmd
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} 
> ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile 
> ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch 
> ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv 
> bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} 
> dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} 
> ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv 
> bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv 
> efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_usb0=setenv devnum 0; run usb_boot
> bootdelay=2
> bootfstype=fat
> cpu=armv8
> devnum=0
> devplist=1
> devtype=usb
> dhcpuboot=usb start; dhcp u-boot.uimg; bootm
> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> 

Re: [U-Boot] [PULL] Please pull u-boot-imx

[Stefano Babic]

Hi Tom,

On 05/02/2018 04:57, Tom Rini wrote:
> On Sun, Feb 04, 2018 at 07:16:07PM -0500, Tom Rini wrote:
>> On Sun, Feb 04, 2018 at 12:34:29PM +0100, Stefano Babic wrote:
>>
>>> Hi Tom,
>>>
>>> please pull from u-boot-imx, thanks !
>>>
>>>
>>> checkpatch warnings in this PR are just related to long lines (in DTS
>>> and pinmux). These are accepted exceptions. In a couple of cases long
>>> lines are also accepted because code ramains more readable if not split
>>> into more lines).
>>>
>>> The following changes since commit b2153075f42c2d46d310778e226bcb11f0af47f5:
>>>
>>>   Kconfig: usb: rockchip: Remove not needed *_defconfig USB/gadget
>>> entries (2018-02-02 07:13:48 -0500)
>>>
>>> are available in the git repository at:
>>>
>>>   git://www.denx.de/git/u-boot-imx.git master
>>>
>>> for you to fetch changes up to d1ceb0c4881332cb0586920f0a40f8e4a48d99a9:
>>>
>>>   imx: mx7: run sec_init for CAAM RNG (2018-02-04 12:14:11 +0100)
>>>
>>
>> Applied to u-boot/master, thanks!
> 
> That said, oops!
> WARNING: no status info for 'imx6qdl_icore_mipi'
> WARNING: no maintainers for 'imx6qdl_icore_mipi'
> 
> Please fix, thanks!
> 

Yes, thanks, I have sent a patch.

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mx6: fix MAINTAINERS for Engicam i.CoreM6 1.5 MIPI

[Stefano Babic]

Signed-off-by: Stefano Babic 
CC: Jagan Teki 
---
 board/engicam/imx6q/MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/engicam/imx6q/MAINTAINERS b/board/engicam/imx6q/MAINTAINERS
index 82efb46..02216c1 100644
--- a/board/engicam/imx6q/MAINTAINERS
+++ b/board/engicam/imx6q/MAINTAINERS
@@ -6,9 +6,13 @@ F: include/configs/imx6-engicam.h
 F: configs/imx6qdl_icore_mmc_defconfig
 F: configs/imx6qdl_icore_nand_defconfig
 F: configs/imx6qdl_icore_rqs_defconfig
+F: configs/imx6qdl_icore_mipi_defconfig
 F: arch/arm/dts/imx6qdl-icore.dtsi
 F: arch/arm/dts/imx6q-icore.dts
 F: arch/arm/dts/imx6dl-icore.dts
 F: arch/arm/dts/imx6qdl-icore-rqs.dtsi
 F: arch/arm/dts/imx6q-icore-rqs.dts
 F: arch/arm/dts/imx6dl-icore-rqs.dts
+F: arch/arm/dts/imx6dl-icore-mipi.dts
+F: arch/arm/dts/imx6q-icore-mipi.dts
+F: arch/arm/dts/imx6qdl-icore.dtsi
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 1/3] Move CONFIG_PHY_ADDR to Kconfig

[Maxime Ripard]

On Sat, Feb 03, 2018 at 04:37:15AM +, Calvin Johnson wrote:
> > Hi,
> > 
> > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Stefan
> > > Mavrodiev
> > > Sent: Friday, February 2, 2018 7:24 PM
> > 
> > 
> > 
> > > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index
> > > 95b7534..c934aed 100644
> > > --- a/drivers/net/phy/Kconfig
> > > +++ b/drivers/net/phy/Kconfig
> > > @@ -12,6 +12,13 @@ menuconfig PHYLIB
> > >
> > >  if PHYLIB
> > >
> > > +config PHY_ADDR
> > > + int "PHY address"
> > > + default 1 if ARCH_SUNXI
> 
> Sorry, I meant the  default value can be defined in board/sunxi/Kconfig.
> Remaining definition of PHY_ADDR config can be here.

Tom has asked a few times not to do this but to put the defaults where
the Kconfig option is defined. I'm not sure I remember the details
though.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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