Re: [U-Boot] [PATCH 8/8] Migrate generic bootcount to Kconfig

[Lukasz Majewski]

Hi Alex,

> On Sun, Feb 11, 2018 at 9:44 PM, Lukasz Majewski 
> wrote:
> > On Sun, 11 Feb 2018 21:04:46 +
> > Alex Kiernan  wrote:
> >  
> >>
> >> That said, squashing in that change doesn't obviously break
> >> anything for me, and is probably a step in the right direction.
> >>
> >> I'll see what Travis thinks.
> >>  
> >
> > We will probably receive build breaks...  
> 
> Yup... https://travis-ci.org/akiernan/u-boot/jobs/340344489
> 
> Just tried again on one of those failures (x600) with the the default
> removed and just set the on board that uses CONFIG_EXT, but that then
> fails at config time.

Ok. I see

> 
> TBH I'd actually like to take it out of Kconfig (which I realise is
> the wrong direction) as it just feels fundamentally wrong the way it
> is. 

To finish moving SYS_BOOTCOUNT_ADDR to Kconfig we would need to add its
definition to each eligible ./configs/_defconfig file.

Then we would have the previous behaviour preserved. 

> I don't know what the U-Boot approach configuration like this
> is... struggling to find prior art.

Let's ask Tom for his opinion as he did much such work before.

> 


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


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

Re: [U-Boot] [PATCH v2 3/4] Convert socfpga: select CONFIG_HW_WATCHDOG support for ARCH_SOCFPGA

[Lukasz Majewski]

On Sun, 11 Feb 2018 19:06:32 -0500
Tom Rini  wrote:

> On Mon, Feb 12, 2018 at 12:34:10AM +0100, Lukasz Majewski wrote:
> > Hi Simon,
> >   
> > > On 09.02.2018 23:14, Lukasz Majewski wrote:  
> > > > All Socfpga boards from ./include/configs/socfpga_* define
> > > > CONFIG_HW_WATCHDOG.
> > > > To ease CONFIG_HW_WATCHDOG conversion to Kconfig select it in
> > > > config ARCH_SOCFPGA (arch/arm/Kconfig) section.
> > > 
> > > I do have board configs where the internal watchdog is not used
> > > and should be disabled (because there's an external one). Also,
> > > given that this is an FPGA, I suppose having non-upstreamed
> > > boards is not uncommon.  
> > 
> > I must admit that this patch I did after looking on the socfpga
> > pattern in the current upstream.
> > 
> > It seems like all boards there use HW_WATCHDOG.
> >   
> > > 
> > > I'm not too familiar with these settings though: can I leave the 
> > > watchdog disabled when CONFIG_HW_WATCHDOG is off? Before, I just
> > > haven't enabled this in my own board config...  
> > 
> > I think that I will prepare next revision of this patch with just
> > simple ./tools/moveconfig.py output (without blindly selecting
> > HW_WATCHDOG on all socfpga devices).
> > 
> > In that way we will preserve the current behaviour.  
> 
> You should probably use imply for features that are common, but
> optional.
> 

Thanks for the suggestion.


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


pgpqMh8iuAvyS.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/3] video: ivybridge_igd: Fix compiler warning

[Bin Meng]

Fix build warning in drivers/video/ivybridge_igd.c with gcc 7.3.0:

  warning: 'ivb_pm_gt2' defined but not used [-Wunused-const-variable=]

Signed-off-by: Bin Meng 
---

 drivers/video/ivybridge_igd.c | 56 ---
 1 file changed, 56 deletions(-)

diff --git a/drivers/video/ivybridge_igd.c b/drivers/video/ivybridge_igd.c
index d8af2e1..7c00c40 100644
--- a/drivers/video/ivybridge_igd.c
+++ b/drivers/video/ivybridge_igd.c
@@ -128,62 +128,6 @@ static const struct gt_powermeter ivb_pm_gt1[] = {
{ 0 }
 };
 
-static const struct gt_powermeter ivb_pm_gt2[] = {
-   { 0xa800, 0x1000 },
-   { 0xa804, 0x00033800 },
-   { 0xa808, 0x0902 },
-   { 0xa80c, 0x0c002f00 },
-   { 0xa810, 0x12000400 },
-   { 0xa814, 0x },
-   { 0xa818, 0x00d20800 },
-   { 0xa81c, 0x0002 },
-   { 0xa820, 0x03004b02 },
-   { 0xa824, 0x0600 },
-   { 0xa828, 0x07000773 },
-   { 0xa82c, 0x },
-   { 0xa830, 0x00010032 },
-   { 0xa834, 0x1520040d },
-   { 0xa838, 0x00020105 },
-   { 0xa83c, 0x00083700 },
-   { 0xa840, 0x151d },
-   { 0xa844, 0x },
-   { 0xa848, 0x20001b00 },
-   { 0xa84c, 0x0a10 },
-   { 0xa850, 0x },
-   { 0xa854, 0x0008 },
-   { 0xa858, 0x0008 },
-   { 0xa85c, 0x },
-   { 0xa860, 0x0002 },
-   { 0xa248, 0x221e },
-   { 0xa900, 0x },
-   { 0xa904, 0x3500 },
-   { 0xa908, 0x },
-   { 0xa90c, 0x0c00 },
-   { 0xa910, 0x12000500 },
-   { 0xa914, 0x },
-   { 0xa918, 0x00b2 },
-   { 0xa91c, 0x },
-   { 0xa920, 0x08004b02 },
-   { 0xa924, 0x0200 },
-   { 0xa928, 0x07000820 },
-   { 0xa92c, 0x },
-   { 0xa930, 0x0003 },
-   { 0xa934, 0x050f020d },
-   { 0xa938, 0x00020300 },
-   { 0xa93c, 0x00903900 },
-   { 0xa940, 0x },
-   { 0xa944, 0x },
-   { 0xa948, 0x20001b00 },
-   { 0xa94c, 0x0a10 },
-   { 0xa950, 0x },
-   { 0xa954, 0x0008 },
-   { 0xa960, 0x0011 },
-   { 0xaa3c, 0x3900 },
-   { 0xaa54, 0x0008 },
-   { 0xaa60, 0x0011 },
-   { 0 }
-};
-
 static const struct gt_powermeter ivb_pm_gt2_17w[] = {
{ 0xa800, 0x2000 },
{ 0xa804, 0x000e3800 },
-- 
2.7.4

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

[U-Boot] [PATCH 3/3] microblaze: bootm: Fix compiler warning

[Bin Meng]

Fix build warning in arch/microblaze/lib/bootm.c with gcc 7.3.0:

  warning: this 'if' clause does not guard... [-Wmisleading-indentation]

Signed-off-by: Bin Meng 
---

 arch/microblaze/lib/bootm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c
index 0a286e8..93525cc 100644
--- a/arch/microblaze/lib/bootm.c
+++ b/arch/microblaze/lib/bootm.c
@@ -62,11 +62,12 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
of_flat_tree = (char *)simple_strtoul(argv[1], NULL, 16);
 
/* fixup the initrd now that we know where it should be */
-   if (images->rd_start && images->rd_end && of_flat_tree)
+   if (images->rd_start && images->rd_end && of_flat_tree) {
ret = fdt_initrd(of_flat_tree, images->rd_start,
 images->rd_end);
if (ret)
return 1;
+   }
 
 #ifdef DEBUG
printf("## Transferring control to Linux (at address 0x%08lx) ",
-- 
2.7.4

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

[U-Boot] [PATCH 2/3] arm: omap2: Fix compiler warning

[Bin Meng]

Fix build warning in arch/arm/mach-omap2/emif-common.c and
arch/arm/mach-omap2/omap4/emif.c with gcc 7.3.0:

  warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]

Signed-off-by: Bin Meng 
---

 arch/arm/mach-omap2/emif-common.c | 2 +-
 arch/arm/mach-omap2/omap4/emif.c  | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/emif-common.c 
b/arch/arm/mach-omap2/emif-common.c
index e3ef37b..d6c56b0 100644
--- a/arch/arm/mach-omap2/emif-common.c
+++ b/arch/arm/mach-omap2/emif-common.c
@@ -599,7 +599,7 @@ s8 addressing_table_index(u8 type, u8 density, u8 width)
  * tables of the device using DDR clock frequency
  */
 static const struct lpddr2_ac_timings *get_timings_table(const struct
-   lpddr2_ac_timings const *const *device_timings,
+   lpddr2_ac_timings *const *device_timings,
u32 freq)
 {
u32 i, temp, freq_nearest;
diff --git a/arch/arm/mach-omap2/omap4/emif.c b/arch/arm/mach-omap2/omap4/emif.c
index 403c3c6..8f20b1c 100644
--- a/arch/arm/mach-omap2/omap4/emif.c
+++ b/arch/arm/mach-omap2/omap4/emif.c
@@ -90,8 +90,7 @@ static const struct lpddr2_min_tck min_tck_jedec = {
.tFAW = 8
 };
 
-static const struct lpddr2_ac_timings const*
-   jedec_ac_timings[MAX_NUM_SPEEDBINS] = {
+static const struct lpddr2_ac_timings *jedec_ac_timings[MAX_NUM_SPEEDBINS] = {
&timings_jedec_200_mhz,
&timings_jedec_400_mhz
 };
-- 
2.7.4

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

Re: [U-Boot] [PATCH] block: Migrate SystemACE chip to Kconfig

[Алексей Бродкин]

Hi Tom, Michal,

2018-02-09 8:13 GMT+01:00 Michal Simek :

> On 8.2.2018 19:51, Tom Rini wrote:
> > Migrate the base and sub-options to Kconfig.  Note that we only enable
> > this in the base sandbox config now.
> >
> > Cc: Alexey Brodkin 
> > Cc: Michal Simek 
> > Signed-off-by: Tom Rini 
> > ---
> > Is this driver still used anywhere?  It's fishy that it's only enabled
> > in sandbox anymore.
>

This driver was used on our long obsolete devboard a while ago and today it
is not used any longer. So feel free to do whatever you want with it.

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

Re: [U-Boot] [PATCH 8/8] Migrate generic bootcount to Kconfig

[Lukasz Majewski]

On Mon, 12 Feb 2018 09:48:13 +0100
Lukasz Majewski  wrote:

> Hi Alex,
> 
> > On Sun, Feb 11, 2018 at 9:44 PM, Lukasz Majewski 
> > wrote:  
> > > On Sun, 11 Feb 2018 21:04:46 +
> > > Alex Kiernan  wrote:
> > >
> > >>
> > >> That said, squashing in that change doesn't obviously break
> > >> anything for me, and is probably a step in the right direction.
> > >>
> > >> I'll see what Travis thinks.
> > >>
> > >
> > > We will probably receive build breaks...
> > 
> > Yup... https://travis-ci.org/akiernan/u-boot/jobs/340344489
> > 
> > Just tried again on one of those failures (x600) with the the
> > default removed and just set the on board that uses CONFIG_EXT, but
> > that then fails at config time.  
> 
> Ok. I see
> 
> > 
> > TBH I'd actually like to take it out of Kconfig (which I realise is
> > the wrong direction) as it just feels fundamentally wrong the way it
> > is.   
> 
> To finish moving SYS_BOOTCOUNT_ADDR to Kconfig we would need to add
> its definition to each eligible ./configs/_defconfig file.
> 
> Then we would have the previous behaviour preserved. 
> 
> > I don't know what the U-Boot approach configuration like this
> > is... struggling to find prior art.  

I had similar issue with HW_WATCHDOG conversion:

http://patchwork.ozlabs.org/cover/871576/
especially:

http://patchwork.ozlabs.org/patch/871579/

> 
> Let's ask Tom for his opinion as he did much such work before.
> 
> >   
> 
> 
> 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




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


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

Re: [U-Boot] [PATCH v1 1/2] mmc: Fix bug in sd_set_card_speed()

[Jaehoon Chung]

On 02/10/2018 07:52 AM, Jonathan Gray wrote:
> On Fri, Feb 09, 2018 at 12:09:27PM +0100, Jean-Jacques Hiblot wrote:
>> After settings the speed of the sd with the switch command, a check is
>> done to make sure that the new speed has been set. The current check has a
>> masking error: speed are encoded on 4 bits only.
>> Fix it by masking the upper bits.
>>
>> This fixes a problem seen with QEmu emulating a vexpress-a15.
>>
>> Reported-by: Jonathan Gray 
>> Signed-off-by: Jean-Jacques Hiblot 
> 
> With this change the emulated mmc controller can be accessed again here.
> 
> Tested-by: Jonathan Gray 

Thanks for testing. I will pick this. When i apply to u-boot-mmc, i will notice.

Best Regards,
Jaehoon Chung

> 
>>
>> ---
>>
>>  drivers/mmc/mmc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 255310a..31614dd 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -1333,7 +1333,7 @@ static int sd_set_card_speed(struct mmc *mmc, enum 
>> bus_mode mode)
>>  if (err)
>>  return err;
>>  
>> -if ((__be32_to_cpu(switch_status[4]) >> 24) != speed)
>> +if (((__be32_to_cpu(switch_status[4]) >> 24) & 0xF) != speed)
>>  return -ENOTSUPP;
>>  
>>  return 0;
>> -- 
>> 1.9.1
>>
> 
> 
> 

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

Re: [U-Boot] EXT: Re: [PATCH 2/2] Convert CONFIG_SYS_BOOTCOUNT_SINGLEWORD to Kconfig

[Ray, Ian (GE Healthcare)]

> On 11 Feb 2018, at 21.23, Alex Kiernan  wrote:
> 
> On Fri, Feb 9, 2018 at 10:53 PM, Lukasz Majewski  wrote:
>> This converts the following to Kconfig:
>>   CONFIG_SYS_BOOTCOUNT_SINGLEWORD
>> 
>> Signed-off-by: Lukasz Majewski 
>> ---
>> 
>> configs/highbank_defconfig | 1 +
>> drivers/bootcount/Kconfig  | 6 ++
>> include/configs/highbank.h | 1 -
>> 3 files changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig
>> index 41f4ef5f78..60a43db197 100644
>> --- a/configs/highbank_defconfig
>> +++ b/configs/highbank_defconfig
>> @@ -25,6 +25,7 @@ CONFIG_EFI_PARTITION=y
>> CONFIG_ENV_IS_IN_NVRAM=y
>> CONFIG_SCSI_AHCI=y
>> CONFIG_BOOTCOUNT_LIMIT=y
>> +CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
>> # CONFIG_MMC is not set
>> CONFIG_SCSI=y
>> CONFIG_OF_LIBFDT=y
>> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
>> index cb6be73d52..d82289f57b 100644
>> --- a/drivers/bootcount/Kconfig
>> +++ b/drivers/bootcount/Kconfig
>> @@ -17,6 +17,12 @@ config BOOTCOUNT_LIMIT
>>  Enable checking for exceeding the boot count limit.
>>  More information: http://www.denx.de/wiki/DULG/UBootBootCountLimit
>> 
>> +config SYS_BOOTCOUNT_SINGLEWORD
>> +   bool "Use single word to pack boot count and magic value"
>> +   help
>> + This option enables packing boot count magic value and boot count
>> + into single word (32 bits).
>> +
>> if BOOTCOUNT
>> 
>> config BOOTCOUNT_EXT
>> diff --git a/include/configs/highbank.h b/include/configs/highbank.h
>> index 2831aa3875..6c5d3ae3ac 100644
>> --- a/include/configs/highbank.h
>> +++ b/include/configs/highbank.h
>> @@ -26,7 +26,6 @@
>> #define CONFIG_PL01x_PORTS { (void *)(0xFFF36000) }
>> #define CONFIG_CONS_INDEX  0
>> 
>> -#define CONFIG_SYS_BOOTCOUNT_SINGLEWORD
>> #define CONFIG_SYS_BOOTCOUNT_LE/* Use little-endian 
>> accessors */
>> #define CONFIG_SYS_BOOTCOUNT_ADDR  0xfff3cf0c
>> 
> 
> Tested-by: Alex Kiernan 
> 

Reviewed-by: Ian Ray 


> -- 
> Alex Kiernan

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

Re: [U-Boot] EXT: [PATCH v1 1/5] bootcount: config: Make the SYS_BOOTCOUNT_ADDR available also for non EXT setups

[Ray, Ian (GE Healthcare)]

> On 10 Feb 2018, at 12.20, Lukasz Majewski  wrote:
> 
> This commit gives the opportunity to reuse the CONFIG_SYS_BOOTCOUNT_ADDR
> Kconfig entry also for boards, which do not use EXT as a storage for
> bootcount (i.e. on flash ones).
> 
> Signed-off-by: Lukasz Majewski 
> 

Reviewed-by: Ian Ray 


> ---
> 
> drivers/bootcount/Kconfig | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
> index d82289f57b..1254bb51ca 100644
> --- a/drivers/bootcount/Kconfig
> +++ b/drivers/bootcount/Kconfig
> @@ -31,6 +31,12 @@ config BOOTCOUNT_EXT
> Add support for maintaining boot count in a file on an EXT
> filesystem.
> 
> +config SYS_BOOTCOUNT_ADDR
> + hex "RAM address used for reading and writing the boot counter"
> + default 0x7000A000
> + help
> +   Set the address used for reading and writing the boot counter.
> +
> if BOOTCOUNT_EXT
> 
> config SYS_BOOTCOUNT_EXT_INTERFACE
> @@ -56,13 +62,6 @@ config SYS_BOOTCOUNT_EXT_NAME
>   help
> Set the filename and path of the file used to store the boot counter.
> 
> -config SYS_BOOTCOUNT_ADDR
> - hex "RAM address used for reading and writing the boot counter"
> - default 0x7000A000
> - depends on BOOTCOUNT_EXT
> - help
> -   Set the address used for reading and writing the boot counter.
> -
> endif
> 
> endif
> -- 
> 2.11.0
> 

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

Re: [U-Boot] EXT: [PATCH 1/8] Merge CONFIG_BOOTCOUNT and CONFIG_BOOTCOUNT_LIMIT

[Ray, Ian (GE Healthcare)]

> On 11 Feb 2018, at 14.06, Alex Kiernan  wrote:
> 
> CONFIG_BOOTCOUNT was only used in mx53ppd, merge it with
> CONFIG_BOOTCOUNT_LIMIT
> 
> Signed-off-by: Alex Kiernan 

Reviewed-by: Ian Ray 


> ---
> 
> configs/mx53ppd_defconfig | 1 -
> drivers/bootcount/Kconfig | 9 +
> 2 files changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/configs/mx53ppd_defconfig b/configs/mx53ppd_defconfig
> index b83cf72..d6a1c6a 100644
> --- a/configs/mx53ppd_defconfig
> +++ b/configs/mx53ppd_defconfig
> @@ -20,7 +20,6 @@ CONFIG_CMD_EXT4=y
> CONFIG_CMD_EXT4_WRITE=y
> CONFIG_CMD_FAT=y
> CONFIG_CMD_FS_GENERIC=y
> -CONFIG_BOOTCOUNT=y
> CONFIG_BOOTCOUNT_LIMIT=y
> CONFIG_BOOTCOUNT_EXT=y
> CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="0:5"
> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
> index d82289f..da2ccab 100644
> --- a/drivers/bootcount/Kconfig
> +++ b/drivers/bootcount/Kconfig
> @@ -4,13 +4,6 @@
> 
> menu "Boot count support"
> 
> -config BOOTCOUNT
> - bool "Enable Boot count support"
> - help
> -   Enable boot count support, which provides the ability to store the
> -   number of times the board has booted on a number of different
> -   persistent storage mediums.
> -
> config BOOTCOUNT_LIMIT
>   bool "Enable support for checking boot count limit"
>   help
> @@ -23,7 +16,7 @@ config SYS_BOOTCOUNT_SINGLEWORD
> This option enables packing boot count magic value and boot count
> into single word (32 bits).
> 
> -if BOOTCOUNT
> +if BOOTCOUNT_LIMIT
> 
> config BOOTCOUNT_EXT
>   bool "Boot counter on EXT filesystem"
> -- 
> 2.7.4
> 

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

[U-Boot] [PATCH 1/1] dm: core: fix typo in comment (device.h)

[Heinrich Schuchardt]

%s/Indentiies/Identifies/g

Signed-off-by: Heinrich Schuchardt 
---
 include/dm/device.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dm/device.h b/include/dm/device.h
index 813e49f330f..7786b1cf4e6 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -203,7 +203,7 @@ struct udevice_id {
  * it.
  *
  * @name: Device name
- * @id: Identiies the uclass we belong to
+ * @id: Identifies the uclass we belong to
  * @of_match: List of compatible strings to match, and any identifying data
  * for each.
  * @bind: Called to bind a device to its driver
-- 
2.15.1

___
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_driver: comment struct efi_driver_ops

[Heinrich Schuchardt]

Provide description for struct efi_driver_ops.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_driver.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/efi_driver.h b/include/efi_driver.h
index 2bbe26c6e31..010e55a4739 100644
--- a/include/efi_driver.h
+++ b/include/efi_driver.h
@@ -13,6 +13,18 @@
 #include 
 #include 
 
+/*
+ * Operations supported by an EFI driver with respect to the EFI uclass
+ *
+ * @protocol   The GUID of the protocol which is consumed by the
+ * driver. This GUID is used by the EFI uclass in the
+ * supports() and start() methods of the
+ * EFI_DRIVER_BINDING_PROTOCOL.
+ * @child_protocol Protocol supported by the child handles generated by
+ * the EFI driver.
+ * @bind   Function called by the EFI uclass to attach the
+ * driver to EFI driver to a handle.
+ */
 struct efi_driver_ops {
const efi_guid_t *protocol;
const efi_guid_t *child_protocol;
-- 
2.15.1

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

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

[Alexey Brodkin]

Hi Tom, Simon,

On Sun, 2018-02-11 at 15:47 -0500, Tom Rini wrote:
> On Tue, Jan 30, 2018 at 06:23:13PM +0300, Alexey Brodkin wrote:
> 
> > CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
> > places in the same Makefile without any checks so there's no point in
> > keeping this check araound just in one place.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Tom Rini 
> > Acked-by: Masahiro Yamada 
> > ---
> >  Makefile | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index ab3453dcebdc..6f15612b4d07 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -820,9 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> >  # Avoid 'Not enough room for program headers' error on binutils 2.28 
> > onwards.
> >  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
> >  
> > -ifneq ($(CONFIG_SYS_TEXT_BASE),)
> >  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
> > -endif
> 
> This then causes xtensa to fail to build as it does not set
> CONFIG_SYS_TEXT_BASE.

And that also obviously breaks "efi-x86" target as well because 
CONFIG_SYS_TEXT_BASE
seems to not be defined for EFI and then LD gets a string like "-Ttext  -o 
u-boot"
where CONFIG_SYS_TEXT_BASE is supposed to be used as some value.

Frankly I'm not sure what to do with that - probably EFI is just a very special 
case...

But FWIW I'm not very happy with mandatory "-ttext $(CONFIG_SYS_TEXT_BASE)"
in case of ARC and here's why:
 1. In case of ARCv2 ISA interrupt vector table is not just another code 
section with jump
instructions to corresponding handlers but instead it's just a set of 
addresses pointing
to corresponding handlers.

I.e. that's a traditional IVT (interrupt vector table) which among other 
architectures is
used on older ARCompact (AKA ARCv1 ISA):
--->8-
.ivt
jump 0x1000_
jump 0x1000_1000
...
--->8-

And that's what we have for ARCv2:
--->8-
.ivt
0x1000_
0x1000_1000
...
--->8-

 2. Now one may think there's no big difference in 2 cases above except content:
it is either encoded instructions or literals. But that really matters 
because
in case of ARC (regardless ISA version) instructions are encoded in 
__middle-endian__
format while literals are normal little-endians.

Consider the following example:
--->8-
.section .ivt
.word   0x1000
.word   0x10001000
.align  256
.section .text
.word   0x1000
.word   0x10001000
--->8-

That will be compiled into this:
--->8-
Disassembly of section .text:
 <.text>:
   0:    1000   b   131072  ;0x2
   4:   1000 1000   ld  r0,[r8]

Disassembly of section .ivt:
 <.ivt>:
   0:   00 00 00 10 .word   0x1000
   4:   00 10 00 10 .word   0x10001000
--->8-

Note how bytes are swapped in .text section.

In the end that basically means we cannot put IVT in the beginning of .text 
section how
it is usually done. We need to keep .ivt and .text sections as separate 
substances.

And so far what we used to do we put .ivt section after .text.
It was done as a preparation for ARCv2 port introduction here:
http://git.denx.de/?p=u-boot.git;a=commit;h=20a58ac0d8e09d0bf1a74c6b68fea22784512b51

Now here comes another challenge - so far U-Boot was not the first piece of 
software
that was executed by CPU, but what's even more important U-Boot was started by 
boot-ROM
via jump to U-Boot's entry point (which happened to be it's start of .text 
section).

But now we're going to run U-Boot as the first ever thing on power on and for 
that we'll
put U-Boot in ROM such that CPU starts execution from "reset" vector and that 
will be
U-Boot.

In other words in hardware location of IVT is hard-coded as 0x_ and 
that's where
we'll put U-Boot. With explanation above I think it's quite clear that we 
cannot have .text
section there at 0x_ because what's going to happen is CPU will fetch 
the first "data"
word from ROM and will attempt to junp at address it "sees" there. Obviously 
that won't be
a correct address and so CPU will just jump into some unexpected location.

Which basically means we need to put .ivt section in the very beginning of the 
image and
have .text section at say 0x_1000. I.e. now we'll need to keep in mind at 
least 2 things:
 1) CONFIG_SYS_TEXT_BASE is not the base-address of the uboot.img
 2) .ivt's base-address is something just a couple of kB below 
CONFIG_SYS_TEXT_BASE

So if "-Ttext CONFIG_SYS_TEXT_BASE" is not used for each and every board I may 
use
CON

[U-Boot] [PATCH v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

[Faiz Abbas]

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 before loading environment from it.

Signed-off-by: Faiz Abbas 
---
Dropped Lukasz's Reviewed-by because patch has
changed.

I have tested this with ENV_IS_IN_FAT and ENV_IS_IN_MMC.

 env/ext4.c | 3 +++
 env/fat.c  | 3 +++
 env/mmc.c  | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/env/ext4.c b/env/ext4.c
index 3f3aac5..6c69a0a 100644
--- a/env/ext4.c
+++ b/env/ext4.c
@@ -87,6 +87,9 @@ static int env_ext4_load(void)
int err;
loff_t off;
 
+   if (!strcmp(CONFIG_ENV_EXT4_INTERFACE, "mmc"))
+   mmc_initialize(NULL);
+
part = blk_get_device_part_str(CONFIG_ENV_EXT4_INTERFACE,
   CONFIG_ENV_EXT4_DEVICE_AND_PART,
   &dev_desc, &info, 1);
diff --git a/env/fat.c b/env/fat.c
index 35f7ab5..fdf4b7a 100644
--- a/env/fat.c
+++ b/env/fat.c
@@ -89,6 +89,9 @@ static int env_fat_load(void)
int dev, part;
int err;
 
+   if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc"))
+   mmc_initialize(NULL);
+
part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE,
CONFIG_ENV_FAT_DEVICE_AND_PART,
&dev_desc, &info, 1);
diff --git a/env/mmc.c b/env/mmc.c
index 1058b8c..6f11dec 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -273,6 +273,8 @@ static int env_mmc_load(void)
ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env1, 1);
ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env2, 1);
 
+   mmc_initialize(NULL);
+
mmc = find_mmc_device(dev);
 
errmsg = init_mmc_for_env(mmc);
-- 
2.7.4

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

[U-Boot] [PATCH] mmc: Drop unnecessary case for mmc_probe()

[Faiz Abbas]

Drop the unnecessary empty function case for mmc_probe().

Signed-off-by: Faiz Abbas 
---
 drivers/mmc/mmc.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 255310a..e0b9a42 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2657,12 +2657,7 @@ void mmc_set_preinit(struct mmc *mmc, int preinit)
mmc->preinit = preinit;
 }
 
-#if CONFIG_IS_ENABLED(DM_MMC) && defined(CONFIG_SPL_BUILD)
-static int mmc_probe(bd_t *bis)
-{
-   return 0;
-}
-#elif CONFIG_IS_ENABLED(DM_MMC)
+#if CONFIG_IS_ENABLED(DM_MMC)
 static int mmc_probe(bd_t *bis)
 {
int ret, i;
-- 
2.7.4

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

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

[Tom Rini]

On Mon, Feb 12, 2018 at 01:27:30PM +, Alexey Brodkin wrote:
> Hi Tom, Simon,
> 
> On Sun, 2018-02-11 at 15:47 -0500, Tom Rini wrote:
> > On Tue, Jan 30, 2018 at 06:23:13PM +0300, Alexey Brodkin wrote:
> > 
> > > CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
> > > places in the same Makefile without any checks so there's no point in
> > > keeping this check araound just in one place.
> > > 
> > > Signed-off-by: Alexey Brodkin 
> > > Cc: Tom Rini 
> > > Acked-by: Masahiro Yamada 
> > > ---
> > >  Makefile | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/Makefile b/Makefile
> > > index ab3453dcebdc..6f15612b4d07 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -820,9 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> > >  # Avoid 'Not enough room for program headers' error on binutils 2.28 
> > > onwards.
> > >  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
> > >  
> > > -ifneq ($(CONFIG_SYS_TEXT_BASE),)
> > >  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
> > > -endif
> > 
> > This then causes xtensa to fail to build as it does not set
> > CONFIG_SYS_TEXT_BASE.
> 
> And that also obviously breaks "efi-x86" target as well because 
> CONFIG_SYS_TEXT_BASE
> seems to not be defined for EFI and then LD gets a string like "-Ttext  -o 
> u-boot"
> where CONFIG_SYS_TEXT_BASE is supposed to be used as some value.
> 
> Frankly I'm not sure what to do with that - probably EFI is just a very 
> special case...
> 
> But FWIW I'm not very happy with mandatory "-ttext $(CONFIG_SYS_TEXT_BASE)"
> in case of ARC and here's why:
>  1. In case of ARCv2 ISA interrupt vector table is not just another code 
> section with jump
> instructions to corresponding handlers but instead it's just a set of 
> addresses pointing
> to corresponding handlers.
> 
> I.e. that's a traditional IVT (interrupt vector table) which among other 
> architectures is
> used on older ARCompact (AKA ARCv1 ISA):
> --->8-
> .ivt
> jump 0x1000_
> jump 0x1000_1000
> ...
> --->8-
> 
> And that's what we have for ARCv2:
> --->8-
> .ivt
> 0x1000_
> 0x1000_1000
> ...
> --->8-
> 
>  2. Now one may think there's no big difference in 2 cases above except 
> content:
> it is either encoded instructions or literals. But that really matters 
> because
> in case of ARC (regardless ISA version) instructions are encoded in 
> __middle-endian__
> format while literals are normal little-endians.
> 
> Consider the following example:
> --->8-
> .section .ivt
> .word 0x1000
> .word 0x10001000
> .align256
> .section .text
> .word 0x1000
> .word 0x10001000
> --->8-
> 
> That will be compiled into this:
> --->8-
> Disassembly of section .text:
>  <.text>:
>0:  1000   b   131072  ;0x2
>4: 1000 1000   ld  r0,[r8]
> 
> Disassembly of section .ivt:
>  <.ivt>:
>0: 00 00 00 10 .word   0x1000
>4: 00 10 00 10 .word   0x10001000
> --->8-
> 
> Note how bytes are swapped in .text section.
> 
> In the end that basically means we cannot put IVT in the beginning of .text 
> section how
> it is usually done. We need to keep .ivt and .text sections as separate 
> substances.
> 
> And so far what we used to do we put .ivt section after .text.
> It was done as a preparation for ARCv2 port introduction here:
> http://git.denx.de/?p=u-boot.git;a=commit;h=20a58ac0d8e09d0bf1a74c6b68fea22784512b51
> 
> Now here comes another challenge - so far U-Boot was not the first piece of 
> software
> that was executed by CPU, but what's even more important U-Boot was started 
> by boot-ROM
> via jump to U-Boot's entry point (which happened to be it's start of .text 
> section).
> 
> But now we're going to run U-Boot as the first ever thing on power on and for 
> that we'll
> put U-Boot in ROM such that CPU starts execution from "reset" vector and that 
> will be
> U-Boot.
> 
> In other words in hardware location of IVT is hard-coded as 0x_ and 
> that's where
> we'll put U-Boot. With explanation above I think it's quite clear that we 
> cannot have .text
> section there at 0x_ because what's going to happen is CPU will fetch 
> the first "data"
> word from ROM and will attempt to junp at address it "sees" there. Obviously 
> that won't be
> a correct address and so CPU will just jump into some unexpected location.
> 
> Which basically means we need to put .ivt section in the very beginning of 
> the image and
> have .text sect

Re: [U-Boot] About convert to LIVE DT

[Simon Glass]

Hi Kever,

On 4 February 2018 at 18:00, Kever Yang  wrote:
>
>
> On 02/04/2018 09:40 PM, Simon Glass wrote:
>> Hi Kever,
>>
>> On 4 February 2018 at 00:44, Kever Yang  wrote:
>>> Hi Simon, Philipp,
>>>
>>> When I try to convert to live dt, I fount there are many APIs work
>>> in fdt are missing in live dt,
>>>
>>> do you have any suggestion to add these APIs in live dt quickly? I need:
>>>
>>> fdtdec_get_addr_size_auto_noparent
>> dev_read_addr_size() - not having a parent doesn't happen with livetree
>>
>>> fdt_alloc_phandle
>> We don't support changing the live tree yet.
>>
>>> fdt_device_is_available
>> dev_read_enabled()
>>
>>> fdt_for_each_subnode
>> dev_for_each_subnode()
>>
>>> fdt_getprop
>> dev_read_prop()
>>
>>> fdt_getprop_u32_default_node
>> This is an odd function. Can you first check that the property exists,
>> and then use a dev_read_...() function to read it?
>>
>>> fdt_get_named_resource
>> dev_read_resource_byname()
>>
>>> fdt_get_name
>> dev_read_name() - although I see that the comment is wrong
>>
>>> fdt_get_path
>> Not available but you can add it
>>
>>> fdt_get_phandle
>> Why do you need this?
>
> Most of the APIs are used in this file or other files in this folder,
> https://github.com/rockchip-linux/u-boot/blob/release/drivers/video/drm/rockchip_display.c
> It needs to handle quite complicated dts node for display system in
> rockchip drm display driver(not upstream yet):
> https://github.com/rockchip-linux/u-boot/blob/release/arch/arm/dts/rk3128.dtsi#L421
> https://github.com/rockchip-linux/u-boot/blob/release/arch/arm/dts/rk3126-bnd-d708.dts#L114

One difference I see with Linux is that U-Boot creates devices for all
nodes automatically, provided that they have a compatible string and
matching driver. This should simplify things in U-Boot.

The supernode-at-depth function looks like it just takes the parent of
the parent when an argument of -2 is used.

The existing rockchip driver in U-Boot handles a similar binding,
doesn't it? It has phandles and multiple nodes and subnodes.

>
> Thanks,
> - Kever
>>
>>> fdt_node_depth
>>> fdt_node_offset_by_phandle
>>> fdt_node_offset_by_phandle_node
>> uclass_get_device_by_phandle() or similar?
>>
>>> fdt_path_offset
>> ofnode_path() although it does not return a device. Best avoided.
>>
>>> fdt_set_phandle
>> You can't change the livtree at present.
>>
>>> fdt_stringlist_get
>> dev_read_string_index()
>>
>>> fdt_stringlist_search
>> dev_read_stringlist_search()
>>
>>> fdt_subnode_offset
>> Why do you want that?
>>
>>> fdt_supernode_atdepth_offset
>> This should be found by scanning, generally using separate drivers for
>> each DT node.
>>
>> If you like you could send a patch with the info above, to
>> doc/driver-model/livetree.txt to help others.

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

Re: [U-Boot] [PATCH v4 3/4] dm: video: use constants to refer to colors

[Simon Glass]

On 8 February 2018 at 13:47, Heinrich Schuchardt  wrote:
> Use constants to refer to colors.
> Adjust initialization of foreground and background color to avoid
> setting reserved bits.
> Consistently u32 instead of unsigned for color bit mask.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v4
> Fix a build warning, that was treated as an error in Travis testing
> by conditional compling with CONFIG_DM_VIDEO.
> v3
> Use color constants for initalizing the console.
> v2
> no change
> ---
>  drivers/video/vidconsole-uclass.c | 55 
> +++
>  drivers/video/video-uclass.c  | 19 +-
>  include/video.h   | 11 ++--
>  include/video_console.h   | 35 +
>  4 files changed, 89 insertions(+), 31 deletions(-)

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

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

[Simon Glass]

Hi Alex,

On 9 February 2018 at 11:55, Alexander Graf  wrote:
>
>
> On 30.01.18 20:03, Heinrich Schuchardt wrote:
>> Provide information about
>>
>> - usage of the bootefi command
>> - overview of UEFI
>> - interaction between U-Boot and EFI drivers
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> v2
>>   new file
>
> The patch is very hard to read. Please just make this 2 patches. One
> that removes the old file, one that adds the rewrite.

That doesn't make a lot of sense to me. Can you not just apply the
patch locally and read it?

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

Re: [U-Boot] [PATCH v2 1/2] core: add uclass_get_device_by_phandle_id() api

[Simon Glass]

Hi Kever,

On 8 February 2018 at 19:56, Kever Yang  wrote:
> Add api for who can not get phandle from a device property.

Can you please add a motivation to the commit message? It is not
obvious to me when this function would be used.
>
> Signed-off-by: Kever Yang 
> ---
>
> Changes in v2:
> - use uint instead of int for phandle
> - address comment from Philipp
>
>  drivers/core/uclass.c | 26 ++
>  include/dm/uclass.h   | 16 
>  2 files changed, 42 insertions(+)
>

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

Re: [U-Boot] [PATCH] core: add ofnode_get_by_phandle() api

[Simon Glass]

On 8 February 2018 at 06:55, Kever Yang  wrote:
> We need to get ofnode from a phandle, add interface to support
> both live dt and fdt.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/core/ofnode.c | 13 +
>  include/dm/ofnode.h   |  8 
>  2 files changed, 21 insertions(+)

This reminds me that we need some tests for this code. I will see if I
can come up with something.

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

Re: [U-Boot] [PATCH v1 2/2] mmc: fix bug in mmc_startup_v4()

[Simon Glass]

On 9 February 2018 at 04:09, Jean-Jacques Hiblot  wrote:
> The correspondence between mmc versions as used in u-boot and the version

U-Boot

> numbers reported in register EXT_CSD_REV is wrong for versions above and
> including MMC_VERSION_4_41. All those versions were shifted by one:
> real 4.5 hardware appeared to be MMC_VERSION_5_0.
>
> Fix this by adding the missing version in the correspondence table.
>
> Reported-by: eil Eilmsteiner Heribert 
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
>  drivers/mmc/mmc.c | 1 +
>  include/mmc.h | 1 +
>  2 files changed, 2 insertions(+)
>

Reviewed-by: Simon Glass 

> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 31614dd..99e2a75 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1950,6 +1950,7 @@ static int mmc_startup_v4(struct mmc *mmc)
> MMC_VERSION_4_1,
> MMC_VERSION_4_2,
> MMC_VERSION_4_3,
> +   MMC_VERSION_4_4,
> MMC_VERSION_4_41,
> MMC_VERSION_4_5,
> MMC_VERSION_5_0,
> diff --git a/include/mmc.h b/include/mmc.h
> index a46eaed..86f885b 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -54,6 +54,7 @@
>  #define MMC_VERSION_4_1MAKE_MMC_VERSION(4, 1, 0)
>  #define MMC_VERSION_4_2MAKE_MMC_VERSION(4, 2, 0)
>  #define MMC_VERSION_4_3MAKE_MMC_VERSION(4, 3, 0)
> +#define MMC_VERSION_4_4MAKE_MMC_VERSION(4, 4, 0)
>  #define MMC_VERSION_4_41   MAKE_MMC_VERSION(4, 4, 1)
>  #define MMC_VERSION_4_5MAKE_MMC_VERSION(4, 5, 0)
>  #define MMC_VERSION_5_0MAKE_MMC_VERSION(5, 0, 0)
> --
> 1.9.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] video: ivybridge_igd: Fix compiler warning

[Tom Rini]

On Mon, Feb 12, 2018 at 05:54:35PM +0800, Bin Meng wrote:

> Fix build warning in drivers/video/ivybridge_igd.c with gcc 7.3.0:
> 
>   warning: 'ivb_pm_gt2' defined but not used [-Wunused-const-variable=]
> 
> Signed-off-by: Bin Meng 

Since it's also what I sent, code-wise:

Reviewed-by: Tom Rini 

:)

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

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

[Marek Vasut]

On 02/12/2018 03:23 PM, Tom Rini wrote:
> On Mon, Feb 12, 2018 at 01:27:30PM +, Alexey Brodkin wrote:
>> Hi Tom, Simon,
>>
>> On Sun, 2018-02-11 at 15:47 -0500, Tom Rini wrote:
>>> On Tue, Jan 30, 2018 at 06:23:13PM +0300, Alexey Brodkin wrote:
>>>
 CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
 places in the same Makefile without any checks so there's no point in
 keeping this check araound just in one place.

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

 diff --git a/Makefile b/Makefile
 index ab3453dcebdc..6f15612b4d07 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -820,9 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
  # Avoid 'Not enough room for program headers' error on binutils 2.28 
 onwards.
  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
  
 -ifneq ($(CONFIG_SYS_TEXT_BASE),)
  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
 -endif
>>>
>>> This then causes xtensa to fail to build as it does not set
>>> CONFIG_SYS_TEXT_BASE.
>>
>> And that also obviously breaks "efi-x86" target as well because 
>> CONFIG_SYS_TEXT_BASE
>> seems to not be defined for EFI and then LD gets a string like "-Ttext  -o 
>> u-boot"
>> where CONFIG_SYS_TEXT_BASE is supposed to be used as some value.
>>
>> Frankly I'm not sure what to do with that - probably EFI is just a very 
>> special case...
>>
>> But FWIW I'm not very happy with mandatory "-ttext $(CONFIG_SYS_TEXT_BASE)"
>> in case of ARC and here's why:
>>  1. In case of ARCv2 ISA interrupt vector table is not just another code 
>> section with jump
>> instructions to corresponding handlers but instead it's just a set of 
>> addresses pointing
>> to corresponding handlers.
>>
>> I.e. that's a traditional IVT (interrupt vector table) which among other 
>> architectures is
>> used on older ARCompact (AKA ARCv1 ISA):
>> --->8-
>> .ivt
>> jump 0x1000_
>> jump 0x1000_1000
>> ...
>> --->8-
>>
>> And that's what we have for ARCv2:
>> --->8-
>> .ivt
>> 0x1000_
>> 0x1000_1000
>> ...
>> --->8-
>>
>>  2. Now one may think there's no big difference in 2 cases above except 
>> content:
>> it is either encoded instructions or literals. But that really matters 
>> because
>> in case of ARC (regardless ISA version) instructions are encoded in 
>> __middle-endian__
>> format while literals are normal little-endians.
>>
>> Consider the following example:
>> --->8-
>> .section .ivt
>> .word0x1000
>> .word0x10001000
>> .align   256
>> .section .text
>> .word0x1000
>> .word0x10001000
>> --->8-
>>
>> That will be compiled into this:
>> --->8-
>> Disassembly of section .text:
>>  <.text>:
>>0: 1000   b   131072  ;0x2
>>4:1000 1000   ld  r0,[r8]
>>
>> Disassembly of section .ivt:
>>  <.ivt>:
>>0:00 00 00 10 .word   0x1000
>>4:00 10 00 10 .word   0x10001000
>> --->8-
>>
>> Note how bytes are swapped in .text section.
>>
>> In the end that basically means we cannot put IVT in the beginning of .text 
>> section how
>> it is usually done. We need to keep .ivt and .text sections as separate 
>> substances.
>>
>> And so far what we used to do we put .ivt section after .text.
>> It was done as a preparation for ARCv2 port introduction here:
>> http://git.denx.de/?p=u-boot.git;a=commit;h=20a58ac0d8e09d0bf1a74c6b68fea22784512b51
>>
>> Now here comes another challenge - so far U-Boot was not the first piece of 
>> software
>> that was executed by CPU, but what's even more important U-Boot was started 
>> by boot-ROM
>> via jump to U-Boot's entry point (which happened to be it's start of .text 
>> section).
>>
>> But now we're going to run U-Boot as the first ever thing on power on and 
>> for that we'll
>> put U-Boot in ROM such that CPU starts execution from "reset" vector and 
>> that will be
>> U-Boot.
>>
>> In other words in hardware location of IVT is hard-coded as 0x_ and 
>> that's where
>> we'll put U-Boot. With explanation above I think it's quite clear that we 
>> cannot have .text
>> section there at 0x_ because what's going to happen is CPU will 
>> fetch the first "data"
>> word from ROM and will attempt to junp at address it "sees" there. Obviously 
>> that won't be
>> a correct address and so CPU will just jump into some unexpected location.
>>
>> Which basicall

Re: [U-Boot] [PATCH 3/3] microblaze: bootm: Fix compiler warning

[Tom Rini]

On Mon, Feb 12, 2018 at 05:54:37PM +0800, Bin Meng wrote:

> Fix build warning in arch/microblaze/lib/bootm.c with gcc 7.3.0:
> 
>   warning: this 'if' clause does not guard... [-Wmisleading-indentation]
> 
> Signed-off-by: Bin Meng 

Reviewed-by: Tom Rini 

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

Re: [U-Boot] [PATCH 2/3] arm: omap2: Fix compiler warning

[Tom Rini]

On Mon, Feb 12, 2018 at 05:54:36PM +0800, Bin Meng wrote:

> Fix build warning in arch/arm/mach-omap2/emif-common.c and
> arch/arm/mach-omap2/omap4/emif.c with gcc 7.3.0:
> 
>   warning: duplicate 'const' declaration specifier 
> [-Wduplicate-decl-specifier]
> 
> Signed-off-by: Bin Meng 

Reviewed-by: Tom Rini 

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

[U-Boot] [PATCH] SystemACE: Remove

[Tom Rini]

This driver is no longer used on any supported platform in U-Boot and
there is no interest in maintaining it further from people that have
used it historically.

Cc: Simon Glass 
Cc: Michal Simek 
c: Alexey Brodkin 
Signed-off-by: Tom Rini 
---
 arch/sandbox/include/asm/io.h |   4 -
 configs/sandbox_defconfig |   3 -
 drivers/block/Kconfig |  19 ---
 drivers/block/Makefile|   1 -
 drivers/block/blk-uclass.c|   2 -
 drivers/block/systemace.c | 303 --
 include/blk.h |   1 -
 7 files changed, 333 deletions(-)
 delete mode 100644 drivers/block/systemace.c

diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
index 59729f5635e8..d3e8b969d63c 100644
--- a/arch/sandbox/include/asm/io.h
+++ b/arch/sandbox/include/asm/io.h
@@ -171,10 +171,6 @@ static inline void _outsw(volatile u16 *port, const void 
*buf, int ns)
 #define insw(port, buf, ns)_insw((u16 *)port, buf, ns)
 #define outsw(port, buf, ns)   _outsw((u16 *)port, buf, ns)
 
-/* For systemace.c */
-#define out16(addr, val)
-#define in16(addr) 0
-
 #include 
 #include 
 
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index c0f4c0a89f12..063828333d58 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -81,9 +81,6 @@ CONFIG_DEVRES=y
 CONFIG_DEBUG_DEVRES=y
 CONFIG_ADC=y
 CONFIG_ADC_SANDBOX=y
-CONFIG_SYSTEMACE=y
-CONFIG_SYS_SYSTEMACE_BASE=0x0
-CONFIG_SYS_SYSTEMACE_WIDTH=16
 CONFIG_CLK=y
 CONFIG_CPU=y
 CONFIG_DM_DEMO=y
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 73836ada094b..15fd1bcb2b7e 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -44,22 +44,3 @@ config IDE
  This allows access to raw blocks and filesystems on an IDE drive
  from U-Boot. See also CMD_IDE which provides an 'ide' command for
  performing various IDE operations.
-
-config SYSTEMACE
-   bool "Xilinx SystemACE support"
-   select HAVE_BLOCK_DEVICE
-   help
- Adding this option adds support for Xilinx SystemACE chips attached
- via some sort of local bus. The address of the chip must also be
- defined in the CONFIG_SYS_SYSTEMACE_BASE macro.
-
- When SystemACE support is added, the "ace" device type becomes
- available to the fat commands, i.e. fatls.
-
-config SYS_SYSTEMACE_BASE
-   hex "Base address of SystemACE chip"
-   depends on SYSTEMACE
-
-config SYS_SYSTEMACE_WIDTH
-   int "Word size of access to the of SystemACE chip"
-   depends on SYSTEMACE
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index d06a598f1409..3d52bd8f4639 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -13,5 +13,4 @@ endif
 
 obj-$(CONFIG_IDE) += ide.o
 obj-$(CONFIG_SANDBOX) += sandbox.o
-obj-$(CONFIG_SYSTEMACE) += systemace.o
 obj-$(CONFIG_BLOCK_CACHE) += blkcache.o
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index bfda2211f0e8..c32aee67605a 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -22,7 +22,6 @@ static const char *if_typename_str[IF_TYPE_COUNT] = {
[IF_TYPE_SD]= "sd",
[IF_TYPE_SATA]  = "sata",
[IF_TYPE_HOST]  = "host",
-   [IF_TYPE_SYSTEMACE] = "ace",
[IF_TYPE_NVME]  = "nvme",
[IF_TYPE_EFI]   = "efi",
 };
@@ -37,7 +36,6 @@ static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = {
[IF_TYPE_SD]= UCLASS_INVALID,
[IF_TYPE_SATA]  = UCLASS_AHCI,
[IF_TYPE_HOST]  = UCLASS_ROOT,
-   [IF_TYPE_SYSTEMACE] = UCLASS_INVALID,
[IF_TYPE_NVME]  = UCLASS_NVME,
[IF_TYPE_EFI]   = UCLASS_EFI,
 };
diff --git a/drivers/block/systemace.c b/drivers/block/systemace.c
deleted file mode 100644
index 9392beaf052e..
--- a/drivers/block/systemace.c
+++ /dev/null
@@ -1,303 +0,0 @@
-/*
- * Copyright (c) 2004 Picture Elements, Inc.
- *Stephen Williams ()
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * The Xilinx SystemACE chip support is activated by defining
- * CONFIG_SYSTEMACE to turn on support, and CONFIG_SYS_SYSTEMACE_BASE
- * to set the base address of the device. This code currently
- * assumes that the chip is connected via a byte-wide bus.
- *
- * The CONFIG_SYSTEMACE also adds to fat support the device class
- * "ace" that allows the user to execute "fatls ace 0" and the
- * like. This works by making the systemace_get_dev function
- * available to cmd_fat.c:get_dev and filling in a block device
- * description that has all the bits needed for FAT support to
- * read sectors.
- *
- * According to Xilinx technical support, before accessing the
- * SystemACE CF you need to set the following control bits:
- *  FORCECFGMODE : 1
- *  CFGMODE : 0
- *  CFGSTART : 0
- */
-
-#include 
-#include 
-#include 
-#include 
-#in

[U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Simon Goldschmidt]

In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
thins for spi flash and mmc that are not required by the hw.

Give users more freedom of choice and use imply here instead
of select.

This should allow disabling spi support completely or using
sd/mmc boot in "raw mode" (no partitions).

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 225f57e847..37bf3dd69f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -699,13 +699,13 @@ config ARCH_SOCFPGA
select OF_CONTROL
select SPL_OF_CONTROL
select DM
-   select DM_SPI_FLASH
-   select DM_SPI
select ENABLE_ARM_SOC_BOOT0_HOOK
select ARCH_EARLY_INIT_R
select ARCH_MISC_INIT
-   select SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
select SYS_THUMB_BUILD
+   imply DM_SPI_FLASH
+   imply DM_SPI
+   imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
imply CMD_MTDPARTS
imply CRC32_VERIFY
imply FAT_WRITE
-- 
2.11.0

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

Re: [U-Boot] [PATCH] SystemACE: Remove

[Michal Simek]

On 12.2.2018 15:51, Tom Rini wrote:
> This driver is no longer used on any supported platform in U-Boot and
> there is no interest in maintaining it further from people that have
> used it historically.
> 
> Cc: Simon Glass 
> Cc: Michal Simek 
> c: Alexey Brodkin 
> Signed-off-by: Tom Rini 
> ---
>  arch/sandbox/include/asm/io.h |   4 -
>  configs/sandbox_defconfig |   3 -
>  drivers/block/Kconfig |  19 ---
>  drivers/block/Makefile|   1 -
>  drivers/block/blk-uclass.c|   2 -
>  drivers/block/systemace.c | 303 
> --
>  include/blk.h |   1 -
>  7 files changed, 333 deletions(-)
>  delete mode 100644 drivers/block/systemace.c

Acked-by: Michal Simek 

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

Re: [U-Boot] U-Boot

[Marek Vasut]

On 02/12/2018 03:52 PM, Mariano Coromac wrote:
> Hello, I was hoping you could help me out with something. I just have 2
> main questions. I am using a SAMA5D27 and I've managed to port
> AT91Bootloader and I'm currently on U-Boot

U-Boot SPL can bring SAMA5D2 up, you don't need the AT91 bootloader.

> 1. I am trying to use FLEXCOM1 (UART) as the main console of U-Boot but
> haven't been able to find any documentation saying where or how U-Boot
> specifies the console port.

$ git grep DEBUG_UART configs/sama5d2*
configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART=y
configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_ATMEL=y
configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_BASE=0xf802
configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_CLOCK=8200
configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_BOARD_INIT=y
configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_ANNOUNCE=y

would indicate there's a debug uart which you can use.

I'm adding atmel maintainer to CC and dropping dead contacts.

> 2. When U-Boot tries to boot it gives me these errors:
> 
> bind node sdio-host@a000
>    - attempt to match compatible string 'atmel,sama5d2-sdhci'
> No match for node 'sdio-host@a000'
> bind node sdio-host@b000
>    - attempt to match compatible string 'atmel,sama5d2-sdhci'
> No match for node 'sdio-host@b000'
> bind node apb
>    - attempt to match compatible string 'simple-bus'
>    - found match at 'generic_simple_bus'
> bind node pmc@f0014000
>    - attempt to match compatible string 'atmel,sama5d2-pmc'
>    - found match at 'at91-pmc'
> bind node mainck
>    - attempt to match compatible string 'atmel,at91sam9x5-clk-main'
>    - found match at 'at91sam9x5-main-osc-clk'
> bind node pllack@0
>    - attempt to match compatible string 'atmel,sama5d3-clk-pll'
>    - found match at 'at91-plla-clk'
> bind node utmick
>    - attempt to match compatible string 'atmel,at91sam9x5-clk-utmi'
> No match for node 'utmick'
> bind node masterck
>    - attempt to match compatible string 'atmel,at91sam9x5-clk-master'
>    - found match at 'at91-master-clk'
> bind node h32mxck
>    - attempt to match compatible string 'atmel,sama5d4-clk-h32mx'
> No match for node 'h32mxck'
> bind node periph32ck
>    - attempt to match compatible string 'atmel,at91sam9x5-clk-peripheral'
>    - found match at 'sam9x5-periph-clk'
> Cannot create device named 'uart1_clk@25' (err=-12)
> Error binding driver 'sam9x5-periph-clk': -12
> bind node periph64ck
>    - attempt to match compatible string 'atmel,at91sam9x5-clk-peripheral'
>    - found match at 'sam9x5-periph-clk'
> Error binding driver 'sam9x5-periph-clk': -12
> bind node gck
>    - attempt to match compatible string 'atmel,sama5d2-clk-generated'
> No match for node 'gck'
> Some drivers failed to bind
> Error binding driver 'at91-pmc': -12
> bind node spi@f800
>    - attempt to match compatible string 'atmel,at91rm9200-spi'
> No match for node 'spi@f800'
> bind node serial@f8038200
>    - attempt to match compatible string 'atmel,at91sam9260-usart'
>    - found match at 'serial_atmel'
> Error binding driver 'serial_atmel': -12
> bind node gpio@fc038000
>    - attempt to match compatible string 'atmel,sama5d2-gpio'
>    - found match at 'gpio_atmel_pio4'
> Error binding driver 'gpio_atmel_pio4': -12
> Some drivers failed to bind
> Error binding driver 'generic_simple_bus': -12
> Some drivers failed to bind
> Error binding driver 'generic_simple_bus': -12
> Some drivers failed to bind
> initcall sequence 26f20864 failed at call 26f073e4 (err=-12)
> ### ERROR ### Please RESET the board ###
> 
> NOTE: On my lists.c file I changed all the "dm_debug" for "dm_warn"
> because the debug uart is the only one that's responding.
> Any help or guidance would be really appreciated.

Seems like some drivers are disabled.

Which version of U-Boot do you use ?

What platform did you derive your configuration from ?

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

Re: [U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Marek Vasut]

On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:
> In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
> thins for spi flash and mmc that are not required by the hw.

things ?

what hw, all supported boards you mean ?

> Give users more freedom of choice and use imply here instead
> of select.
> 
> This should allow disabling spi support completely or using
> sd/mmc boot in "raw mode" (no partitions).

You can just turn them off in the defconfigs, but I get what you're
trying to say.

Just reword the commit message and do make savedefconfig for all the
socfpga platforms (in a separate patch) to sync the defconfigs up.

> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
>  arch/arm/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 225f57e847..37bf3dd69f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -699,13 +699,13 @@ config ARCH_SOCFPGA
>   select OF_CONTROL
>   select SPL_OF_CONTROL
>   select DM
> - select DM_SPI_FLASH
> - select DM_SPI
>   select ENABLE_ARM_SOC_BOOT0_HOOK
>   select ARCH_EARLY_INIT_R
>   select ARCH_MISC_INIT
> - select SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
>   select SYS_THUMB_BUILD
> + imply DM_SPI_FLASH
> + imply DM_SPI
> + imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
>   imply CMD_MTDPARTS
>   imply CRC32_VERIFY
>   imply FAT_WRITE
> 


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

Re: [U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Simon Goldschmidt]

On 12.02.2018 15:54, Marek Vasut wrote:

On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:

In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
thins for spi flash and mmc that are not required by the hw.

things ?

what hw, all supported boards you mean ?


Give users more freedom of choice and use imply here instead
of select.

This should allow disabling spi support completely or using
sd/mmc boot in "raw mode" (no partitions).

You can just turn them off in the defconfigs, but I get what you're
trying to say.

Just reword the commit message and do make savedefconfig for all the
socfpga platforms (in a separate patch) to sync the defconfigs up.


OK, thanks. Given that the same files are touched, should I wait for the 
CONFIG_HW_WATCHDOG patches from Lukasz to be applied first?


Simon




Signed-off-by: Simon Goldschmidt 
---

  arch/arm/Kconfig | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 225f57e847..37bf3dd69f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -699,13 +699,13 @@ config ARCH_SOCFPGA
select OF_CONTROL
select SPL_OF_CONTROL
select DM
-   select DM_SPI_FLASH
-   select DM_SPI
select ENABLE_ARM_SOC_BOOT0_HOOK
select ARCH_EARLY_INIT_R
select ARCH_MISC_INIT
-   select SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
select SYS_THUMB_BUILD
+   imply DM_SPI_FLASH
+   imply DM_SPI
+   imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
imply CMD_MTDPARTS
imply CRC32_VERIFY
imply FAT_WRITE





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

Re: [U-Boot] [PATCH 3/3] microblaze: bootm: Fix compiler warning

[Michal Simek]

On 12.2.2018 15:46, Tom Rini wrote:
> On Mon, Feb 12, 2018 at 05:54:37PM +0800, Bin Meng wrote:
> 
>> Fix build warning in arch/microblaze/lib/bootm.c with gcc 7.3.0:
>>
>>   warning: this 'if' clause does not guard... [-Wmisleading-indentation]
>>
>> Signed-off-by: Bin Meng 
> 
> Reviewed-by: Tom Rini 
> 

Reviewed-by: Michal Simek 

If you want me to apply via my tree, I am happy to do that.
You have sent it as series that's why I am asking.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




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

Re: [U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Marek Vasut]

On 02/12/2018 04:16 PM, Simon Goldschmidt wrote:
> On 12.02.2018 15:54, Marek Vasut wrote:
>> On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:
>>> In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
>>> thins for spi flash and mmc that are not required by the hw.
>> things ?
>>
>> what hw, all supported boards you mean ?
>>
>>> Give users more freedom of choice and use imply here instead
>>> of select.
>>>
>>> This should allow disabling spi support completely or using
>>> sd/mmc boot in "raw mode" (no partitions).
>> You can just turn them off in the defconfigs, but I get what you're
>> trying to say.
>>
>> Just reword the commit message and do make savedefconfig for all the
>> socfpga platforms (in a separate patch) to sync the defconfigs up.
> 
> OK, thanks. Given that the same files are touched, should I wait for the
> CONFIG_HW_WATCHDOG patches from Lukasz to be applied first?

You two figure it out :)

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

Re: [U-Boot] U-Boot

[Marek Vasut]

On 02/12/2018 04:13 PM, Mariano Coromac wrote:
> Oh ok.
> My main problem is that I DO have debug_uart but I don't have U-Boot
> main console.
> I already have the configuration on my defconf for the debug UART like this:
> CONFIG_DM=y
> CONFIG_DM_SERIAL=y
> CONFIG_DEBUG_UART=y
> CONFIG_DEBUG_UART_ATMEL=y
> CONFIG_DEBUG_UART_BASE=0xf8038200
> CONFIG_DEBUG_UART_CLOCK=5800
> CONFIG_DEBUG_UART_BOARD_INIT=y
> CONFIG_DEBUG_UART_ANNOUNCE=y
> I cloned from the github repository
> *https://github.com/linux4sam/u-boot-at91*
> My configuration was derived from the sama5d2_xplained board because I'm
> working with a custom one.

If you used vendor fork of U-Boot, please ask vendor, the U-Boot
upstream repo is at [1]. You should rather use that. Adding more Atmel
people on CC, they should be able to help.

You should also tell us which version (or even better, which commit in
which repo) do you use. That's important.

Also please stop top-posting.

[1] http://git.denx.de/?p=u-boot.git;a=summary

> On Mon, Feb 12, 2018 at 8:59 AM, Marek Vasut  > wrote:
> 
> On 02/12/2018 03:52 PM, Mariano Coromac wrote:
> > Hello, I was hoping you could help me out with something. I just have 2
> > main questions. I am using a SAMA5D27 and I've managed to port
> > AT91Bootloader and I'm currently on U-Boot
> 
> U-Boot SPL can bring SAMA5D2 up, you don't need the AT91 bootloader.
> 
> > 1. I am trying to use FLEXCOM1 (UART) as the main console of U-Boot but
> > haven't been able to find any documentation saying where or how U-Boot
> > specifies the console port.
> 
> $ git grep DEBUG_UART configs/sama5d2*
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART=y
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_ATMEL=y
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_BASE=0xf802
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_CLOCK=8200
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_BOARD_INIT=y
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_ANNOUNCE=y
> 
> would indicate there's a debug uart which you can use.
> 
> I'm adding atmel maintainer to CC and dropping dead contacts.
> 
> > 2. When U-Boot tries to boot it gives me these errors:
> >
> > bind node sdio-host@a000
> >    - attempt to match compatible string 'atmel,sama5d2-sdhci'
> > No match for node 'sdio-host@a000'
> > bind node sdio-host@b000
> >    - attempt to match compatible string 'atmel,sama5d2-sdhci'
> > No match for node 'sdio-host@b000'
> > bind node apb
> >    - attempt to match compatible string 'simple-bus'
> >    - found match at 'generic_simple_bus'
> > bind node pmc@f0014000
> >    - attempt to match compatible string 'atmel,sama5d2-pmc'
> >    - found match at 'at91-pmc'
> > bind node mainck
> >    - attempt to match compatible string 'atmel,at91sam9x5-clk-main'
> >    - found match at 'at91sam9x5-main-osc-clk'
> > bind node pllack@0
> >    - attempt to match compatible string 'atmel,sama5d3-clk-pll'
> >    - found match at 'at91-plla-clk'
> > bind node utmick
> >    - attempt to match compatible string 'atmel,at91sam9x5-clk-utmi'
> > No match for node 'utmick'
> > bind node masterck
> >    - attempt to match compatible string 'atmel,at91sam9x5-clk-master'
> >    - found match at 'at91-master-clk'
> > bind node h32mxck
> >    - attempt to match compatible string 'atmel,sama5d4-clk-h32mx'
> > No match for node 'h32mxck'
> > bind node periph32ck
> >    - attempt to match compatible string
> 'atmel,at91sam9x5-clk-peripheral'
> >    - found match at 'sam9x5-periph-clk'
> > Cannot create device named 'uart1_clk@25' (err=-12)
> > Error binding driver 'sam9x5-periph-clk': -12
> > bind node periph64ck
> >    - attempt to match compatible string
> 'atmel,at91sam9x5-clk-peripheral'
> >    - found match at 'sam9x5-periph-clk'
> > Error binding driver 'sam9x5-periph-clk': -12
> > bind node gck
> >    - attempt to match compatible string 'atmel,sama5d2-clk-generated'
> > No match for node 'gck'
> > Some drivers failed to bind
> > Error binding driver 'at91-pmc': -12
> > bind node spi@f800
> >    - attempt to match compatible string 'atmel,at91rm9200-spi'
> > No match for node 'spi@f800'
> > bind node serial@f8038200
> >    - attempt to match compatible string 'atmel,at91sam9260-usart'
> >    - found match at 'serial_atmel'
> > Error binding driver 'serial_atmel': -12
> > bind node gpio@fc038000
> >    - attempt to match compatible string 'atmel,sama5d2-gpio'
> >    - found match at 'gpio_atmel_pio4'
> > Error binding driver 'gpio_atmel_pio4': -12
> > Some drivers failed to bind
> > Error binding driver 'generic_simple_bus': -12
> > Some drivers failed to bind
>   

Re: [U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Lukasz Majewski]

Hi Simon, Marek,

> On 02/12/2018 04:16 PM, Simon Goldschmidt wrote:
> > On 12.02.2018 15:54, Marek Vasut wrote:  
> >> On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:  
> >>> In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
> >>> thins for spi flash and mmc that are not required by the hw.  
> >> things ?
> >>
> >> what hw, all supported boards you mean ?
> >>  
> >>> Give users more freedom of choice and use imply here instead
> >>> of select.
> >>>
> >>> This should allow disabling spi support completely or using
> >>> sd/mmc boot in "raw mode" (no partitions).  
> >> You can just turn them off in the defconfigs, but I get what you're
> >> trying to say.
> >>
> >> Just reword the commit message and do make savedefconfig for all
> >> the socfpga platforms (in a separate patch) to sync the defconfigs
> >> up.  
> > 
> > OK, thanks. Given that the same files are touched, should I wait
> > for the CONFIG_HW_WATCHDOG patches from Lukasz to be applied
> > first?  
> 
> You two figure it out :)

It is always better to ask socfpga veteran for his opinion :-)

> 

Simon, feel free to perform the clean up. I will have to look more
closely to the WDT move to Kconfig.

Even better, you are more than welcome to use/squash this patch to your
work:
http://patchwork.ozlabs.org/patch/871578/

It will simplify my WDT conversion work.

Thanks for help.


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


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

Re: [U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Marek Vasut]

On 02/12/2018 04:39 PM, Lukasz Majewski wrote:
> Hi Simon, Marek,
> 
>> On 02/12/2018 04:16 PM, Simon Goldschmidt wrote:
>>> On 12.02.2018 15:54, Marek Vasut wrote:  
 On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:  
> In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
> thins for spi flash and mmc that are not required by the hw.  
 things ?

 what hw, all supported boards you mean ?
  
> Give users more freedom of choice and use imply here instead
> of select.
>
> This should allow disabling spi support completely or using
> sd/mmc boot in "raw mode" (no partitions).  
 You can just turn them off in the defconfigs, but I get what you're
 trying to say.

 Just reword the commit message and do make savedefconfig for all
 the socfpga platforms (in a separate patch) to sync the defconfigs
 up.  
>>>
>>> OK, thanks. Given that the same files are touched, should I wait
>>> for the CONFIG_HW_WATCHDOG patches from Lukasz to be applied
>>> first?  
>>
>> You two figure it out :)
> 
> It is always better to ask socfpga veteran for his opinion :-)

SoCFPGA veteran is old and is delegating tasks ;-)

> Simon, feel free to perform the clean up. I will have to look more
> closely to the WDT move to Kconfig.
> 
> Even better, you are more than welcome to use/squash this patch to your
> work:
> http://patchwork.ozlabs.org/patch/871578/
> 
> It will simplify my WDT conversion work.

Good!

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

Re: [U-Boot] [RFC PATCH] net: mii command: disable build for 64-bit Allwinner boards

[Tom Rini]

On Mon, Feb 12, 2018 at 01:25:21AM +, Andre Przywara wrote:

> The current master fails to build some Allwinner H5 boards, due to
> exceeding the U-Boot proper size limit we currently have still in place.
> This affects:
> - nanopi_neo2_defconfig
> - nanopi_neo_plus2_defconfig
> - orangepi_pc2_defconfig
> - orangepi_prime_defconfig
> - orangepi_zero_plus2_defconfig
> To workaround this issue, a left-over low hanging fruit is to disable
> the MII *command*, which is probably only useful for debugging and not
> needed for a normal boot flow, even when booting via network (PXE/TFTP).
> 
> Allow to de-select CMD_MII, even when the distro default enables it.
> Then disable it explicitly in the affected board's defconfigs.
> This makes all Allwinner ARMv8 boards build again.
> 
> Signed-off-by: Andre Przywara 
> ---
> Hi,
> 
> my sincere apologies for this ugly hack (and I welcome any nicer solution!),
> but we are running out of silver bullets for this particular problem and this
> command seems both easy to give up and worthwhile in terms of code size
> savings (~11KB).
> The "default n if ..." doesn't seem to work with "imply", so I needed to
> disable it in each of the affected defconfigs. Please let me know if there
> is a better solution.

Can we not move the env location now?  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] Build system: Don't check for CONFIG_SYS_TEXT_BASE being set

[Alexey Brodkin]

On Mon, 2018-02-12 at 09:23 -0500, Tom Rini wrote:
> On Mon, Feb 12, 2018 at 01:27:30PM +, Alexey Brodkin wrote:
> > Hi Tom, Simon,
> > 
> > On Sun, 2018-02-11 at 15:47 -0500, Tom Rini wrote:
> > > On Tue, Jan 30, 2018 at 06:23:13PM +0300, Alexey Brodkin wrote:
> > > 
> > > > CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
> > > > places in the same Makefile without any checks so there's no point in
> > > > keeping this check araound just in one place.
> > > > 
> > > > Signed-off-by: Alexey Brodkin 
> > > > Cc: Tom Rini 
> > > > Acked-by: Masahiro Yamada 
> > > > ---
> > > >  Makefile | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > > 
> > > > diff --git a/Makefile b/Makefile
> > > > index ab3453dcebdc..6f15612b4d07 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -820,9 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> > > >  # Avoid 'Not enough room for program headers' error on binutils 2.28 
> > > > onwards.
> > > >  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
> > > >  
> > > > -ifneq ($(CONFIG_SYS_TEXT_BASE),)
> > > >  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
> > > > -endif
> > > 
> > > This then causes xtensa to fail to build as it does not set
> > > CONFIG_SYS_TEXT_BASE.
> > 
> > And that also obviously breaks "efi-x86" target as well because 
> > CONFIG_SYS_TEXT_BASE
> > seems to not be defined for EFI and then LD gets a string like "-Ttext  -o 
> > u-boot"
> > where CONFIG_SYS_TEXT_BASE is supposed to be used as some value.

[snip]

> > So if "-Ttext CONFIG_SYS_TEXT_BASE" is not used for each and every board I 
> > may use
> > CONFIG_SYS_TEXT_BASE directly in linker just as we have it now, see
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.denx.de_-3Fp-3Du-2Dboot.git-3Ba-3Dblob-3Bf-3Darch_arc_cpu_u-2Dboot.lds-23l14&d=DwIBAg&c=DP
> > L6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=3oKsgMcKriZJ81auV4XDwr4ovIElxycDMpRlTqS7nhc&s=Yq0YW-
> > MQvofxwQ961IRHzIS5xWYtHHzxMp_Fwn91h5s&e=
> > and then there might be any section like .ivt, .text, .myfunkysection etc.
> > 
> > In fact in the Linux kernel "-Ttext XXX" is not used for everybody - some
> > arches like MIPS and PPC indeed set it but others do other things.
> > 
> > The simplest thing might be is to add another #ifdef for ARC and X86 which 
> > both
> > use CONFIG_SYS_TEXT_BASE directly in their linker scripts like that:
> > --->8-
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -820,9 +820,11 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> >  # Avoid 'Not enough room for program headers' error on binutils 2.28 
> > onwards.
> >  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
> >  
> > +ifeq($(CONFIG_ARC)$(CONFIG_X86),)
> >  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
> > +endif
> >  
> >  # Normally we fill empty space with 0xff
> >  quiet_cmd_objcopy = OBJCOPY $@
> > --->8-
> > 
> > Any thoughts?
> 
> I'm largely ok with the above, but:
> - You need to exclude CONFIG_NIOS2 in the above as well, or convert the
>   usage of CONFIG_SYS_MONITOR_BASE to CONFIG_SYS_TEXT_BASE (Thomas?)

Looks like NIOS2 builds are not yet supported in TravisCI which is
quite unfortunate... are there any instructions on how to build for Nios2
so that I may test my changes before posting them?

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

Re: [U-Boot] [PATCH] env: restore old env_get_char() behaviour

[York Sun]

On 02/09/2018 12:23 PM, Goldschmidt Simon wrote:
> With multiple environments, the 'get_char' callback for env
> drivers does not really make sense any more because it is
> only supported by two drivers (eeprom and nvram).
> 
> To restore single character loading for these drivers,
> override 'env_get_char_spec'.
> 
> Signed-off-by: Simon Goldschmidt 

This patch looks OK to me, as long as eeprom and nvram drivers continue
to work, don't they?

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

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

[Tom Rini]

On Mon, Feb 12, 2018 at 04:21:09PM +, Alexey Brodkin wrote:
> On Mon, 2018-02-12 at 09:23 -0500, Tom Rini wrote:
> > On Mon, Feb 12, 2018 at 01:27:30PM +, Alexey Brodkin wrote:
> > > Hi Tom, Simon,
> > > 
> > > On Sun, 2018-02-11 at 15:47 -0500, Tom Rini wrote:
> > > > On Tue, Jan 30, 2018 at 06:23:13PM +0300, Alexey Brodkin wrote:
> > > > 
> > > > > CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
> > > > > places in the same Makefile without any checks so there's no point in
> > > > > keeping this check araound just in one place.
> > > > > 
> > > > > Signed-off-by: Alexey Brodkin 
> > > > > Cc: Tom Rini 
> > > > > Acked-by: Masahiro Yamada 
> > > > > ---
> > > > >  Makefile | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > > 
> > > > > diff --git a/Makefile b/Makefile
> > > > > index ab3453dcebdc..6f15612b4d07 100644
> > > > > --- a/Makefile
> > > > > +++ b/Makefile
> > > > > @@ -820,9 +820,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> > > > >  # Avoid 'Not enough room for program headers' error on binutils 2.28 
> > > > > onwards.
> > > > >  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
> > > > >  
> > > > > -ifneq ($(CONFIG_SYS_TEXT_BASE),)
> > > > >  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
> > > > > -endif
> > > > 
> > > > This then causes xtensa to fail to build as it does not set
> > > > CONFIG_SYS_TEXT_BASE.
> > > 
> > > And that also obviously breaks "efi-x86" target as well because 
> > > CONFIG_SYS_TEXT_BASE
> > > seems to not be defined for EFI and then LD gets a string like "-Ttext  
> > > -o u-boot"
> > > where CONFIG_SYS_TEXT_BASE is supposed to be used as some value.
> 
> [snip]
> 
> > > So if "-Ttext CONFIG_SYS_TEXT_BASE" is not used for each and every board 
> > > I may use
> > > CONFIG_SYS_TEXT_BASE directly in linker just as we have it now, see
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.denx.de_-3Fp-3Du-2Dboot.git-3Ba-3Dblob-3Bf-3Darch_arc_cpu_u-2Dboot.lds-23l14&d=DwIBAg&c=DP
> > > L6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=3oKsgMcKriZJ81auV4XDwr4ovIElxycDMpRlTqS7nhc&s=Yq0YW-
> > > MQvofxwQ961IRHzIS5xWYtHHzxMp_Fwn91h5s&e=
> > > and then there might be any section like .ivt, .text, .myfunkysection etc.
> > > 
> > > In fact in the Linux kernel "-Ttext XXX" is not used for everybody - some
> > > arches like MIPS and PPC indeed set it but others do other things.
> > > 
> > > The simplest thing might be is to add another #ifdef for ARC and X86 
> > > which both
> > > use CONFIG_SYS_TEXT_BASE directly in their linker scripts like that:
> > > --->8-
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -820,9 +820,11 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> > >  # Avoid 'Not enough room for program headers' error on binutils 2.28 
> > > onwards.
> > >  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
> > >  
> > > +ifeq($(CONFIG_ARC)$(CONFIG_X86),)
> > >  LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
> > > +endif
> > >  
> > >  # Normally we fill empty space with 0xff
> > >  quiet_cmd_objcopy = OBJCOPY $@
> > > --->8-
> > > 
> > > Any thoughts?
> > 
> > I'm largely ok with the above, but:
> > - You need to exclude CONFIG_NIOS2 in the above as well, or convert the
> >   usage of CONFIG_SYS_MONITOR_BASE to CONFIG_SYS_TEXT_BASE (Thomas?)
> 
> Looks like NIOS2 builds are not yet supported in TravisCI which is
> quite unfortunate... are there any instructions on how to build for Nios2
> so that I may test my changes before posting them?

So, part of the issue is that we need newer kernel.org toolchains
(https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/) in
order for buildman to be able to grab a nios2 toolchain, and that in
turn has its own issues.  You can however grab one of those (or the
6.4.0) version manually, extract into ~/.buildman/ and then just let
buildman build the arch.

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

[Mariano Coromac]

Sorry, I tried to switch to the upstream repo but it gave some compiling
errors.
I am using the 409952795f8a28d3c266b2b8b2b9eccf46347601 commit from git://
github.com/linux4sam/u-boot-at91.git
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-Boot

[Mariano Coromac]

Oh ok.
My main problem is that I DO have debug_uart but I don't have U-Boot main
console.
I already have the configuration on my defconf for the debug UART like this:
CONFIG_DM=y
CONFIG_DM_SERIAL=y
CONFIG_DEBUG_UART=y
CONFIG_DEBUG_UART_ATMEL=y
CONFIG_DEBUG_UART_BASE=0xf8038200
CONFIG_DEBUG_UART_CLOCK=5800
CONFIG_DEBUG_UART_BOARD_INIT=y
CONFIG_DEBUG_UART_ANNOUNCE=y
I cloned from the github repository *https://github.com/linux4sam/u-boot-at91
*
My configuration was derived from the sama5d2_xplained board because I'm
working with a custom one.

On Mon, Feb 12, 2018 at 8:59 AM, Marek Vasut  wrote:

> On 02/12/2018 03:52 PM, Mariano Coromac wrote:
> > Hello, I was hoping you could help me out with something. I just have 2
> > main questions. I am using a SAMA5D27 and I've managed to port
> > AT91Bootloader and I'm currently on U-Boot
>
> U-Boot SPL can bring SAMA5D2 up, you don't need the AT91 bootloader.
>
> > 1. I am trying to use FLEXCOM1 (UART) as the main console of U-Boot but
> > haven't been able to find any documentation saying where or how U-Boot
> > specifies the console port.
>
> $ git grep DEBUG_UART configs/sama5d2*
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART=y
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_ATMEL=y
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_BASE=0xf802
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_CLOCK=8200
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_BOARD_INIT=y
> configs/sama5d27_som1_ek_mmc_defconfig:CONFIG_DEBUG_UART_ANNOUNCE=y
>
> would indicate there's a debug uart which you can use.
>
> I'm adding atmel maintainer to CC and dropping dead contacts.
>
> > 2. When U-Boot tries to boot it gives me these errors:
> >
> > bind node sdio-host@a000
> >- attempt to match compatible string 'atmel,sama5d2-sdhci'
> > No match for node 'sdio-host@a000'
> > bind node sdio-host@b000
> >- attempt to match compatible string 'atmel,sama5d2-sdhci'
> > No match for node 'sdio-host@b000'
> > bind node apb
> >- attempt to match compatible string 'simple-bus'
> >- found match at 'generic_simple_bus'
> > bind node pmc@f0014000
> >- attempt to match compatible string 'atmel,sama5d2-pmc'
> >- found match at 'at91-pmc'
> > bind node mainck
> >- attempt to match compatible string 'atmel,at91sam9x5-clk-main'
> >- found match at 'at91sam9x5-main-osc-clk'
> > bind node pllack@0
> >- attempt to match compatible string 'atmel,sama5d3-clk-pll'
> >- found match at 'at91-plla-clk'
> > bind node utmick
> >- attempt to match compatible string 'atmel,at91sam9x5-clk-utmi'
> > No match for node 'utmick'
> > bind node masterck
> >- attempt to match compatible string 'atmel,at91sam9x5-clk-master'
> >- found match at 'at91-master-clk'
> > bind node h32mxck
> >- attempt to match compatible string 'atmel,sama5d4-clk-h32mx'
> > No match for node 'h32mxck'
> > bind node periph32ck
> >- attempt to match compatible string 'atmel,at91sam9x5-clk-
> peripheral'
> >- found match at 'sam9x5-periph-clk'
> > Cannot create device named 'uart1_clk@25' (err=-12)
> > Error binding driver 'sam9x5-periph-clk': -12
> > bind node periph64ck
> >- attempt to match compatible string 'atmel,at91sam9x5-clk-
> peripheral'
> >- found match at 'sam9x5-periph-clk'
> > Error binding driver 'sam9x5-periph-clk': -12
> > bind node gck
> >- attempt to match compatible string 'atmel,sama5d2-clk-generated'
> > No match for node 'gck'
> > Some drivers failed to bind
> > Error binding driver 'at91-pmc': -12
> > bind node spi@f800
> >- attempt to match compatible string 'atmel,at91rm9200-spi'
> > No match for node 'spi@f800'
> > bind node serial@f8038200
> >- attempt to match compatible string 'atmel,at91sam9260-usart'
> >- found match at 'serial_atmel'
> > Error binding driver 'serial_atmel': -12
> > bind node gpio@fc038000
> >- attempt to match compatible string 'atmel,sama5d2-gpio'
> >- found match at 'gpio_atmel_pio4'
> > Error binding driver 'gpio_atmel_pio4': -12
> > Some drivers failed to bind
> > Error binding driver 'generic_simple_bus': -12
> > Some drivers failed to bind
> > Error binding driver 'generic_simple_bus': -12
> > Some drivers failed to bind
> > initcall sequence 26f20864 failed at call 26f073e4 (err=-12)
> > ### ERROR ### Please RESET the board ###
> >
> > NOTE: On my lists.c file I changed all the "dm_debug" for "dm_warn"
> > because the debug uart is the only one that's responding.
> > Any help or guidance would be really appreciated.
>
> Seems like some drivers are disabled.
>
> Which version of U-Boot do you use ?
>
> What platform did you derive your configuration from ?
>
> --
> Best regards,
> Marek Vasut
>



-- 
Mariano Coromac 
I&D of Electronics Engineer
mcoro...@stsa.info
+502 41544712
www.gps.gt 

[U-Boot] [RFC 00/14] bmips: add bcm6348-enet support

[Álvaro Fernández Rojas]

In order to add bcm6348-enet support, dma-uclass must be extended to support
dma channels and rewordked to operate like the other dm uclass (clk, reset...).

This is an RFC, so please give you feedback on the things that I should
fix or rework.

Álvaro Fernández Rojas (14):
  dma: add dma channels support and improve uclass
  dma: add bcm6348-iudma support
  bmips: bcm6338: add bcm6348-iudma support
  bmips: bcm6348: add bcm6348-iudma support
  bmips: bcm6358: add bcm6348-iudma support
  phy: add support for internal phys
  net: add support for bcm6348-enet
  bmips: bcm6338: add support for bcm6348-enet
  bmips: enable f@st1704 enet support
  bmips: bcm6348: add support for bcm6348-enet
  bmips: enable ct-5361 enet support
  bmips: bcm6358: add support for bcm6348-enet
  bmips: enable hg556a enet support
  bmips: enable nb4-ser enet support

 arch/mips/dts/brcm,bcm6338.dtsi   |  29 ++
 arch/mips/dts/brcm,bcm6348.dtsi   |  42 +++
 arch/mips/dts/brcm,bcm6358.dtsi   |  46 +++
 arch/mips/dts/comtrend,ct-5361.dts|  12 +
 arch/mips/dts/huawei,hg556a.dts   |  12 +
 arch/mips/dts/sagem,f...@st1704.dts  |  12 +
 arch/mips/dts/sfr,nb4-ser.dts |  24 ++
 configs/comtrend_ct5361_ram_defconfig |   8 +-
 configs/huawei_hg556a_ram_defconfig   |   8 +-
 configs/sagem_f@st1704_ram_defconfig  |   9 +-
 configs/sfr_nb4-ser_ram_defconfig |   8 +-
 drivers/dma/Kconfig   |   8 +
 drivers/dma/Makefile  |   1 +
 drivers/dma/bcm6348-iudma.c   | 498 
 drivers/dma/dma-uclass.c  | 212 +++---
 drivers/mtd/spi/sf-uclass.c   |  17 ++
 drivers/mtd/spi/spi_flash.c   |  11 +-
 drivers/net/Kconfig   |   9 +
 drivers/net/Makefile  |   1 +
 drivers/net/bcm6348-eth.c | 517 ++
 include/configs/bmips_common.h|   5 +-
 include/dma-uclass.h  | 110 
 include/dma.h | 226 +++
 include/dt-bindings/dma/bcm6338-dma.h |  15 +
 include/dt-bindings/dma/bcm6348-dma.h |  17 ++
 include/dt-bindings/dma/bcm6358-dma.h |  17 ++
 include/phy.h |   2 +
 include/spi_flash.h   |   3 +
 28 files changed, 1780 insertions(+), 99 deletions(-)
 create mode 100644 drivers/dma/bcm6348-iudma.c
 create mode 100644 drivers/net/bcm6348-eth.c
 create mode 100644 include/dma-uclass.h
 create mode 100644 include/dt-bindings/dma/bcm6338-dma.h
 create mode 100644 include/dt-bindings/dma/bcm6348-dma.h
 create mode 100644 include/dt-bindings/dma/bcm6358-dma.h

-- 
2.11.0

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

[U-Boot] [RFC 01/14] dma: add dma channels support and improve uclass

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 drivers/dma/dma-uclass.c| 212 ++---
 drivers/mtd/spi/sf-uclass.c |  17 
 drivers/mtd/spi/spi_flash.c |  11 ++-
 include/dma-uclass.h| 110 +
 include/dma.h   | 226 +---
 include/spi_flash.h |   3 +
 6 files changed, 485 insertions(+), 94 deletions(-)
 create mode 100644 include/dma-uclass.h

diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 3d0ce22fbc..7d04d98493 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -1,59 +1,176 @@
 /*
- * Direct Memory Access U-Class driver
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ * Copyright (C) 2015 Texas Instruments Incorporated, 
+ * Written by Mugunthan V N 
  *
- * (C) Copyright 2015
- * Texas Instruments Incorporated, 
- *
- * Author: Mugunthan V N 
- *
- * SPDX-License-Identifier: GPL-2.0+
+ * SPDX-License-Identifier:GPL-2.0+
  */
 
 #include 
-#include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int dma_get_device(u32 transfer_type, struct udevice **devp)
+static inline struct dma_ops *dma_dev_ops(struct udevice *dev)
+{
+   return (struct dma_ops *)dev->driver->ops;
+}
+
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+# if CONFIG_IS_ENABLED(OF_PLATDATA)
+int dma_get_by_index_platdata(struct udevice *dev, int index,
+ struct phandle_2_cell *cells, struct dma *dma)
 {
-   struct udevice *dev;
int ret;
 
-   for (ret = uclass_first_device(UCLASS_DMA, &dev); dev && !ret;
-ret = uclass_next_device(&dev)) {
-   struct dma_dev_priv *uc_priv;
+   if (index != 0)
+   return -ENOSYS;
+   ret = uclass_get_device(UCLASS_DMA, 0, &dma->dev);
+   if (ret)
+   return ret;
+   dma->id = cells[0].id;
 
-   uc_priv = dev_get_uclass_priv(dev);
-   if (uc_priv->supported & transfer_type)
-   break;
-   }
+   return 0;
+}
+# else
+static int dma_of_xlate_default(struct dma *dma,
+   struct fdtdec_phandle_args *args)
+{
+   debug("%s(dma=%p)\n", __func__, dma);
 
-   if (!dev) {
-   pr_err("No DMA device found that supports %x type\n",
- transfer_type);
-   return -EPROTONOSUPPORT;
+   if (args->args_count > 1) {
+   pr_err("Invaild args_count: %d\n", args->args_count);
+   return -EINVAL;
}
 
-   *devp = dev;
+   if (args->args_count)
+   dma->id = args->args[0];
+   else
+   dma->id = 0;
 
-   return ret;
+   return 0;
 }
 
-int dma_memcpy(void *dst, void *src, size_t len)
+int dma_get_by_index(struct udevice *dev, int index, struct dma *dma)
 {
-   struct udevice *dev;
-   const struct dma_ops *ops;
int ret;
+   struct fdtdec_phandle_args args;
+   struct udevice *dev_dma;
+   struct dma_ops *ops;
+
+   debug("%s(dev=%p, index=%d, dma=%p)\n", __func__, dev, index, dma);
 
-   ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM, &dev);
-   if (ret < 0)
+   assert(dma);
+   ret = fdtdec_parse_phandle_with_args(gd->fdt_blob, dev_of_offset(dev),
+"dmas", "#dma-cells", 0, index,
+&args);
+   if (ret) {
+   pr_err("%s: fdtdec_parse_phandle_with_args failed: err=%d\n",
+ __func__, ret);
return ret;
+   }
+
+   ret = uclass_get_device_by_of_offset(UCLASS_DMA, args.node, &dev_dma);
+   if (ret) {
+   pr_err("%s: uclass_get_device_by_of_offset failed: err=%d\n",
+ __func__, ret);
+   return ret;
+   }
+
+   dma->dev = dev_dma;
+
+   ops = dma_dev_ops(dev_dma);
+
+   if (ops->of_xlate)
+   ret = ops->of_xlate(dma, &args);
+   else
+   ret = dma_of_xlate_default(dma, &args);
+   if (ret) {
+   pr_err("of_xlate() failed: %d\n", ret);
+   return ret;
+   }
+
+   return dma_request(dev_dma, dma);
+}
+# endif /* OF_PLATDATA */
+
+int dma_get_by_name(struct udevice *dev, const char *name, struct dma *dma)
+{
+   int index;
+
+   debug("%s(dev=%p, name=%s, dma=%p)\n", __func__, dev, name, dma);
+
+   index = fdt_stringlist_search(gd->fdt_blob, dev_of_offset(dev),
+ "dma-names", name);
+   if (index < 0) {
+   pr_err("fdt_stringlist_search() failed: %d\n", index);
+   return index;
+   }
+
+   return dma_get_by_index(dev, index, dma);
+}
+#endif /* OF_CONTROL */
+
+int dma_request(struct udevice *dev, struct dma *dma)
+{
+   struct dma_ops *ops = dma_dev_ops(dev);
+
+   debug("%s(dev=%p, dma=%p)\n", 

[U-Boot] [RFC 03/14] bmips: bcm6338: add bcm6348-iudma support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/brcm,bcm6338.dtsi   | 14 ++
 include/dt-bindings/dma/bcm6338-dma.h | 15 +++
 2 files changed, 29 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6338-dma.h

diff --git a/arch/mips/dts/brcm,bcm6338.dtsi b/arch/mips/dts/brcm,bcm6338.dtsi
index 0cab44cb8d..4125f71d9f 100644
--- a/arch/mips/dts/brcm,bcm6338.dtsi
+++ b/arch/mips/dts/brcm,bcm6338.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -131,5 +132,18 @@
reg = <0xfffe3100 0x38>;
u-boot,dm-pre-reloc;
};
+
+   iudma: dma-controller@fffe2400 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe2400 0x1c>,
+ <0xfffe2500 0x60>,
+ <0xfffe2600 0x60>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <6>;
+   resets = <&periph_rst BCM6338_RST_DMAMEM>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6338-dma.h 
b/include/dt-bindings/dma/bcm6338-dma.h
new file mode 100644
index 00..5dd66239b4
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6338-dma.h
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6338_H
+#define __DT_BINDINGS_DMA_BCM6338_H
+
+#define BCM6338_DMA_ENET_RX0
+#define BCM6338_DMA_ENET_TX1
+
+#endif /* __DT_BINDINGS_DMA_BCM6338_H */
-- 
2.11.0

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

[U-Boot] [RFC 02/14] dma: add bcm6348-iudma support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 drivers/dma/Kconfig |   8 +
 drivers/dma/Makefile|   1 +
 drivers/dma/bcm6348-iudma.c | 498 
 3 files changed, 507 insertions(+)
 create mode 100644 drivers/dma/bcm6348-iudma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1b92c7789d..f58323f6c0 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -12,6 +12,14 @@ config DMA
  buses that is used to transfer data to and from memory.
  The uclass interface is defined in include/dma.h.
 
+config BCM6348_IUDMA
+   bool "BCM6348 IUDMA driver"
+   depends on ARCH_BMIPS
+   help
+ Enable the BCM6348 IUDMA driver.
+ This driver support data transfer from devices to
+ memory and from memory to devices.
+
 config TI_EDMA3
bool "TI EDMA3 driver"
help
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 39b78b2a3d..b2b4147349 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DMA) += dma-uclass.o
 
 obj-$(CONFIG_FSLDMAFEC) += MCD_tasksInit.o MCD_dmaApi.o MCD_tasks.o
 obj-$(CONFIG_APBH_DMA) += apbh_dma.o
+obj-$(CONFIG_BCM6348_IUDMA) += bcm6348-iudma.o
 obj-$(CONFIG_FSL_DMA) += fsl_dma.o
 obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
 obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
diff --git a/drivers/dma/bcm6348-iudma.c b/drivers/dma/bcm6348-iudma.c
new file mode 100644
index 00..22d81cc990
--- /dev/null
+++ b/drivers/dma/bcm6348-iudma.c
@@ -0,0 +1,498 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/dma/bcm63xx-iudma.c:
+ * Copyright (C) 2015 Simon Arlott 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c:
+ * Copyright (C) 2008 Maxime Bizon 
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
+ * Copyright (C) 2000-2010 Broadcom Corporation
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/bcmdrivers/opensource/net/enet/impl4/bcmenet.c:
+ * Copyright (C) 2010 Broadcom Corporation
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ALIGN_END_ADDR(type, ptr, size)\
+   ((unsigned long)(ptr) + roundup((size) * sizeof(type), \
+ARCH_DMA_MINALIGN))
+
+#define DMA_MAX_BURST_LENGTH   16
+
+/* DMA Channels */
+#define DMA_CHAN_FLOWC(x)  ((x) >> 1)
+#define DMA_CHAN_FLOWC_MAX 8
+#define DMA_CHAN_MAX   16
+#define DMA_CHAN_SIZE  0x10
+#define DMA_CHAN_TOUT  500
+
+/* DMA Global Configuration register */
+#define DMA_CFG_REG0x00
+#define DMA_CFG_ENABLE_SHIFT   0
+#define DMA_CFG_ENABLE_MASK(1 << DMA_CFG_ENABLE_SHIFT)
+#define DMA_CFG_FLOWC_ENABLE(x)BIT(DMA_CHAN_FLOWC(x) + 1)
+#define DMA_CFG_NCHANS_SHIFT   24
+#define DMA_CFG_NCHANS_MASK(0xf << DMA_CFG_NCHANS_SHIFT)
+
+/* DMA Global Flow Control Threshold registers */
+#define DMA_FLOWC_THR_LO_REG(x)(0x04 + DMA_CHAN_FLOWC(x) * 
0x0c)
+#define DMA_FLOWC_THR_LO_SHIFT 0
+#define DMA_FLOWC_THR_LO_MASK  (5 << DMA_FLOWC_THR_LO_SHIFT)
+
+#define DMA_FLOWC_THR_HI_REG(x)(0x08 + DMA_CHAN_FLOWC(x) * 
0x0c)
+#define DMA_FLOWC_THR_HI_SHIFT 0
+#define DMA_FLOWC_THR_HI_MASK  (10 << DMA_FLOWC_THR_HI_SHIFT)
+
+/* DMA Global Flow Control Buffer Allocation registers */
+#define DMA_FLOWC_ALLOC_REG(x) (0x0c + DMA_CHAN_FLOWC(x) * 0x0c)
+#define DMA_FLOWC_ALLOC_FORCE_SHIFT31
+#define DMA_FLOWC_ALLOC_FORCE_MASK (1 << DMA_FLOWC_ALLOC_FORCE_SHIFT)
+
+/* DMA Global Reset register */
+#define DMA_RST_REG0x34
+#define DMA_RST_CHAN_SHIFT 0
+#define DMA_RST_CHAN_MASK(x)   (1 << x)
+
+/* DMA Channel Configuration register */
+#define DMAC_CFG_REG(x)(DMA_CHAN_SIZE * (x) + 0x00)
+#define DMAC_CFG_ENABLE_SHIFT  0
+#define DMAC_CFG_ENABLE_MASK   (1 << DMAC_CFG_ENABLE_SHIFT)
+#define DMAC_CFG_PKT_HALT_SHIFT1
+#define DMAC_CFG_PKT_HALT_MASK (1 << DMAC_CFG_PKT_HALT_SHIFT)
+#define DMAC_CFG_BRST_HALT_SHIFT   2
+#define DMAC_CFG_BRST_HALT_MASK(1 << DMAC_CFG_BRST_HALT_SHIFT)
+
+/* DMA Channel Interrupts registers */
+#define DMAC_IR_ST_REG(x)  (DMA_CHAN_SIZE * (x) + 0x04)
+#define DMAC_IR_EN_REG(x)  (DMA_CHAN_SIZE * (x) + 0x08)
+
+#define DMAC_IR_DONE_SHIFT 2
+#define DMAC_IR_DONE_MASK  (1 << DMAC_IR_DONE_SHIFT)
+
+/* DMA Channel Max Burst Length register */
+#define DMAC_BURST_REG(x)  (DMA_CHAN_SIZE * (x) + 0x0c)
+#define DMAC_BURST_MAX_SHIFT   0
+#define DMAC_BURST_MAX_MASK(16 << DMAC_BURST_MAX_SHIFT)
+
+/* DMA SRAM Descri

Re: [U-Boot] U-Boot

[Nicolas Ferre]

On 12/02/2018 at 17:28, Mariano Coromac wrote:
> Sorry, I tried to switch to the upstream repo but it gave some compiling
> errors.
> I am using the 409952795f8a28d3c266b2b8b2b9eccf46347601 commit from
> git://github.com/linux4sam/u-boot-at91.git
> 

Can you tell us what is the compiling error that you are experiencing?

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

[U-Boot] [RFC 05/14] bmips: bcm6358: add bcm6348-iudma support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/brcm,bcm6358.dtsi   | 18 ++
 include/dt-bindings/dma/bcm6358-dma.h | 17 +
 2 files changed, 35 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6358-dma.h

diff --git a/arch/mips/dts/brcm,bcm6358.dtsi b/arch/mips/dts/brcm,bcm6358.dtsi
index b63b53baee..1468e4f63a 100644
--- a/arch/mips/dts/brcm,bcm6358.dtsi
+++ b/arch/mips/dts/brcm,bcm6358.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -191,5 +192,22 @@
 
status = "disabled";
};
+
+   iudma: dma-controller@fffe5000 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe5000 0x24>,
+ <0xfffe5100 0x80>,
+ <0xfffe5200 0x80>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <8>;
+   clocks = <&periph_clk BCM6358_CLK_EMUSB>,
+<&periph_clk BCM6358_CLK_USBSU>,
+<&periph_clk BCM6358_CLK_EPHY>;
+   resets = <&periph_rst BCM6358_RST_ENET>,
+<&periph_rst BCM6358_RST_EPHY>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6358-dma.h 
b/include/dt-bindings/dma/bcm6358-dma.h
new file mode 100644
index 00..3b1fcf8540
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6358-dma.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6358_H
+#define __DT_BINDINGS_DMA_BCM6358_H
+
+#define BCM6358_DMA_ENET0_RX   0
+#define BCM6358_DMA_ENET0_TX   1
+#define BCM6358_DMA_ENET1_RX   2
+#define BCM6358_DMA_ENET1_TX   3
+
+#endif /* __DT_BINDINGS_DMA_BCM6358_H */
-- 
2.11.0

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

[U-Boot] [RFC 08/14] bmips: bcm6338: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/brcm,bcm6338.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6338.dtsi b/arch/mips/dts/brcm,bcm6338.dtsi
index 4125f71d9f..621278c9d1 100644
--- a/arch/mips/dts/brcm,bcm6338.dtsi
+++ b/arch/mips/dts/brcm,bcm6338.dtsi
@@ -145,5 +145,20 @@
dma-channels = <6>;
resets = <&periph_rst BCM6338_RST_DMAMEM>;
};
+
+   enet: ethernet@fffe2800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe2800 0x2dc>;
+   clocks = <&periph_clk BCM6338_CLK_ENET>;
+   resets = <&periph_rst BCM6338_RST_ENET>;
+   dmas = <&iudma BCM6338_DMA_ENET_RX>,
+  <&iudma BCM6338_DMA_ENET_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
};
 };
-- 
2.11.0

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

[U-Boot] [RFC 13/14] bmips: enable hg556a enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/huawei,hg556a.dts | 12 
 configs/huawei_hg556a_ram_defconfig |  8 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/huawei,hg556a.dts b/arch/mips/dts/huawei,hg556a.dts
index a1e9c15ab9..2f99e0905c 100644
--- a/arch/mips/dts/huawei,hg556a.dts
+++ b/arch/mips/dts/huawei,hg556a.dts
@@ -94,6 +94,18 @@
status = "okay";
 };
 
+&enet1 {
+   status = "okay";
+   phy = <&enet1phy>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio0 {
status = "okay";
 };
diff --git a/configs/huawei_hg556a_ram_defconfig 
b/configs/huawei_hg556a_ram_defconfig
index 7f7f34ed61..c7c7c6554f 100644
--- a/configs/huawei_hg556a_ram_defconfig
+++ b/configs/huawei_hg556a_ram_defconfig
@@ -26,11 +26,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -38,6 +41,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6358_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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

[U-Boot] [RFC 11/14] bmips: enable ct-5361 enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/comtrend,ct-5361.dts| 12 
 configs/comtrend_ct5361_ram_defconfig |  8 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/comtrend,ct-5361.dts 
b/arch/mips/dts/comtrend,ct-5361.dts
index 74dc09046c..a78aa877fc 100644
--- a/arch/mips/dts/comtrend,ct-5361.dts
+++ b/arch/mips/dts/comtrend,ct-5361.dts
@@ -35,6 +35,18 @@
};
 };
 
+&enet1 {
+   status = "okay";
+   phy = <&enet1phy>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio0 {
status = "okay";
 };
diff --git a/configs/comtrend_ct5361_ram_defconfig 
b/configs/comtrend_ct5361_ram_defconfig
index 8b842606f5..0737772dd2 100644
--- a/configs/comtrend_ct5361_ram_defconfig
+++ b/configs/comtrend_ct5361_ram_defconfig
@@ -26,11 +26,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -38,6 +41,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6348_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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

[U-Boot] [RFC 04/14] bmips: bcm6348: add bcm6348-iudma support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/brcm,bcm6348.dtsi   | 16 
 include/dt-bindings/dma/bcm6348-dma.h | 17 +
 2 files changed, 33 insertions(+)
 create mode 100644 include/dt-bindings/dma/bcm6348-dma.h

diff --git a/arch/mips/dts/brcm,bcm6348.dtsi b/arch/mips/dts/brcm,bcm6348.dtsi
index 92fb91afc1..d774c59665 100644
--- a/arch/mips/dts/brcm,bcm6348.dtsi
+++ b/arch/mips/dts/brcm,bcm6348.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include "skeleton.dtsi"
@@ -160,5 +161,20 @@
reg = <0xfffe2300 0x38>;
u-boot,dm-pre-reloc;
};
+
+   iudma: dma-controller@fffe7000 {
+   compatible = "brcm,bcm6348-iudma";
+   reg = <0xfffe7000 0x1c>,
+ <0xfffe7100 0x40>,
+ <0xfffe7200 0x40>;
+   reg-names = "dma",
+   "dma-channels",
+   "dma-sram";
+   #dma-cells = <1>;
+   dma-channels = <4>;
+   clocks = <&periph_clk BCM6348_CLK_ENET>;
+   resets = <&periph_rst BCM6348_RST_ENET>,
+<&periph_rst BCM6348_RST_DMAMEM>;
+   };
};
 };
diff --git a/include/dt-bindings/dma/bcm6348-dma.h 
b/include/dt-bindings/dma/bcm6348-dma.h
new file mode 100644
index 00..a1d3a6456d
--- /dev/null
+++ b/include/dt-bindings/dma/bcm6348-dma.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DT_BINDINGS_DMA_BCM6348_H
+#define __DT_BINDINGS_DMA_BCM6348_H
+
+#define BCM6348_DMA_ENET0_RX   0
+#define BCM6348_DMA_ENET0_TX   1
+#define BCM6348_DMA_ENET1_RX   2
+#define BCM6348_DMA_ENET1_TX   3
+
+#endif /* __DT_BINDINGS_DMA_BCM6348_H */
-- 
2.11.0

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

[U-Boot] [RFC 06/14] phy: add support for internal phys

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 include/phy.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/phy.h b/include/phy.h
index 0543ec10c2..8f3e53db01 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -50,6 +50,7 @@
 
 
 typedef enum {
+   PHY_INTERFACE_MODE_INTERNAL,
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
@@ -72,6 +73,7 @@ typedef enum {
 } phy_interface_t;
 
 static const char *phy_interface_strings[] = {
+   [PHY_INTERFACE_MODE_INTERNAL]   = "internal",
[PHY_INTERFACE_MODE_MII]= "mii",
[PHY_INTERFACE_MODE_GMII]   = "gmii",
[PHY_INTERFACE_MODE_SGMII]  = "sgmii",
-- 
2.11.0

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

[U-Boot] [RFC 12/14] bmips: bcm6358: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/brcm,bcm6358.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6358.dtsi b/arch/mips/dts/brcm,bcm6358.dtsi
index 1468e4f63a..04329864c2 100644
--- a/arch/mips/dts/brcm,bcm6358.dtsi
+++ b/arch/mips/dts/brcm,bcm6358.dtsi
@@ -193,6 +193,34 @@
status = "disabled";
};
 
+   enet0: ethernet@fffe4000 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe4000 0x2dc>;
+   clocks = <&periph_clk BCM6358_CLK_ENET0>;
+   dmas = <&iudma BCM6358_DMA_ENET0_RX>,
+  <&iudma BCM6358_DMA_ENET0_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
+   enet1: ethernet@fffe4800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe4800 0x2dc>;
+   clocks = <&periph_clk BCM6358_CLK_ENET1>;
+   dmas = <&iudma BCM6358_DMA_ENET1_RX>,
+  <&iudma BCM6358_DMA_ENET1_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
iudma: dma-controller@fffe5000 {
compatible = "brcm,bcm6348-iudma";
reg = <0xfffe5000 0x24>,
-- 
2.11.0

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

[U-Boot] [RFC 14/14] bmips: enable nb4-ser enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/sfr,nb4-ser.dts | 24 
 configs/sfr_nb4-ser_ram_defconfig |  8 +++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/sfr,nb4-ser.dts b/arch/mips/dts/sfr,nb4-ser.dts
index 473372faa1..73db45f9ea 100644
--- a/arch/mips/dts/sfr,nb4-ser.dts
+++ b/arch/mips/dts/sfr,nb4-ser.dts
@@ -54,6 +54,30 @@
status = "okay";
 };
 
+&enet0 {
+   status = "okay";
+   phy = <&enet0phy>;
+   phy-mode = "internal";
+
+   enet0phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
+&enet1 {
+   status = "okay";
+   phy = <&enet1phy>;
+   phy-mode = "mii";
+
+   enet1phy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio0 {
status = "okay";
 };
diff --git a/configs/sfr_nb4-ser_ram_defconfig 
b/configs/sfr_nb4-ser_ram_defconfig
index fc323d879d..07b49a1a77 100644
--- a/configs/sfr_nb4-ser_ram_defconfig
+++ b/configs/sfr_nb4-ser_ram_defconfig
@@ -27,11 +27,14 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_USB=y
-# CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -40,6 +43,9 @@ CONFIG_LED_GPIO=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_PHY=y
 CONFIG_BCM6358_USBH_PHY=y
 CONFIG_DM_RESET=y
-- 
2.11.0

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

[U-Boot] [RFC 09/14] bmips: enable f@st1704 enet support

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/sagem,f...@st1704.dts | 12 
 configs/sagem_f@st1704_ram_defconfig |  9 -
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/sagem,f...@st1704.dts 
b/arch/mips/dts/sagem,f...@st1704.dts
index dd0e5b8b7c..99d031f10a 100644
--- a/arch/mips/dts/sagem,f...@st1704.dts
+++ b/arch/mips/dts/sagem,f...@st1704.dts
@@ -40,6 +40,18 @@
};
 };
 
+&enet {
+   status = "okay";
+   phy = <&enetphy>;
+   phy-mode = "mii";
+
+   enetphy: fixed-link {
+   reg = <1>;
+   speed = <100>;
+   full-duplex;
+   };
+};
+
 &gpio {
status = "okay";
 };
diff --git a/configs/sagem_f@st1704_ram_defconfig 
b/configs/sagem_f@st1704_ram_defconfig
index 0adcd46d51..1a640781b7 100644
--- a/configs/sagem_f@st1704_ram_defconfig
+++ b/configs/sagem_f@st1704_ram_defconfig
@@ -28,11 +28,15 @@ CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
-# CONFIG_CMD_NET is not set
+CONFIG_CMD_DHCP=y
 # CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 # CONFIG_CMD_MISC is not set
 CONFIG_OF_EMBED=y
+CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_BCM6348_IUDMA=y
 CONFIG_DM_GPIO=y
 CONFIG_BCM6345_GPIO=y
 CONFIG_LED=y
@@ -41,6 +45,9 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_FLASH_MTD=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_BCM6348_ETH=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_BCM6345=y
 # CONFIG_SPL_SERIAL_PRESENT is not set
-- 
2.11.0

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

[U-Boot] [RFC 10/14] bmips: bcm6348: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 arch/mips/dts/brcm,bcm6348.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/mips/dts/brcm,bcm6348.dtsi b/arch/mips/dts/brcm,bcm6348.dtsi
index d774c59665..e540865019 100644
--- a/arch/mips/dts/brcm,bcm6348.dtsi
+++ b/arch/mips/dts/brcm,bcm6348.dtsi
@@ -162,6 +162,32 @@
u-boot,dm-pre-reloc;
};
 
+   enet0: ethernet@fffe6000 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe6000 0x2dc>;
+   dmas = <&iudma BCM6348_DMA_ENET0_RX>,
+  <&iudma BCM6348_DMA_ENET0_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
+   enet1: ethernet@fffe6800 {
+   compatible = "brcm,bcm6348-enet";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xfffe6800 0x2dc>;
+   dmas = <&iudma BCM6348_DMA_ENET1_RX>,
+  <&iudma BCM6348_DMA_ENET1_TX>;
+   dma-names = "rx",
+   "tx";
+
+   status = "disabled";
+   };
+
iudma: dma-controller@fffe7000 {
compatible = "brcm,bcm6348-iudma";
reg = <0xfffe7000 0x1c>,
-- 
2.11.0

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

[U-Boot] [RFC 07/14] net: add support for bcm6348-enet

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
 drivers/net/Kconfig|   9 +
 drivers/net/Makefile   |   1 +
 drivers/net/bcm6348-eth.c  | 517 +
 include/configs/bmips_common.h |   5 +-
 4 files changed, 531 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/bcm6348-eth.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index de1947ccc1..12a231cc99 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -71,6 +71,15 @@ config BCM_SF2_ETH_GMAC
  by the BCM_SF2_ETH driver.
  Say Y to any bcmcygnus based platforms.
 
+config BCM6348_ETH
+   bool "BCM6348 EMAC support"
+   depends on DM_ETH && ARCH_BMIPS
+   select DMA
+   select MII
+   select PHYLIB
+   help
+ This driver supports the BCM6348 Ethernet MAC.
+
 config DWC_ETH_QOS
bool "Synopsys DWC Ethernet QOS device support"
depends on DM_ETH
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index ac5443c752..282adbc775 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
 obj-$(CONFIG_AG7XXX) += ag7xxx.o
 obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
+obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
 obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
 obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
 obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
diff --git a/drivers/net/bcm6348-eth.c b/drivers/net/bcm6348-eth.c
new file mode 100644
index 00..890b7d5396
--- /dev/null
+++ b/drivers/net/bcm6348-eth.c
@@ -0,0 +1,517 @@
+/*
+ * Copyright (C) 2018 Álvaro Fernández Rojas 
+ *
+ * Derived from linux/drivers/net/ethernet/broadcom/bcm63xx_enet.c:
+ * Copyright (C) 2008 Maxime Bizon 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ETH_ZLEN   60
+
+#define ETH_TX_WATERMARK   32
+#define ETH_MAX_MTU_SIZE   1518
+
+#define ETH_TIMEOUT100
+
+/* ETH Receiver Configuration register */
+#define ETH_RXCFG_REG  0x00
+#define ETH_RXCFG_ENFLOW_SHIFT 5
+#define ETH_RXCFG_ENFLOW_MASK  (1 << ETH_RXCFG_ENFLOW_SHIFT)
+
+/* ETH Receive Maximum Length register */
+#define ETH_RXMAXLEN_REG   0x04
+#define ETH_RXMAXLEN_SHIFT 0
+#define ETH_RXMAXLEN_MASK  (0x7ff << ETH_RXMAXLEN_SHIFT)
+
+/* ETH Transmit Maximum Length register */
+#define ETH_TXMAXLEN_REG   0x08
+#define ETH_TXMAXLEN_SHIFT 0
+#define ETH_TXMAXLEN_MASK  (0x7ff << ETH_TXMAXLEN_SHIFT)
+
+/* MII Status/Control register */
+#define MII_SC_REG 0x10
+#define MII_SC_MDCFREQDIV_SHIFT0
+#define MII_SC_MDCFREQDIV_MASK (0x7f << MII_SC_MDCFREQDIV_SHIFT)
+#define MII_SC_PREAMBLE_EN_SHIFT   7
+#define MII_SC_PREAMBLE_EN_MASK(1 << MII_SC_PREAMBLE_EN_SHIFT)
+
+/* MII Data register */
+#define MII_DAT_REG0x14
+#define MII_DAT_DATA_SHIFT 0
+#define MII_DAT_DATA_MASK  (0x << MII_DAT_DATA_SHIFT)
+#define MII_DAT_TA_SHIFT   16
+#define MII_DAT_TA_MASK(0x3 << MII_DAT_TA_SHIFT)
+#define MII_DAT_REG_SHIFT  18
+#define MII_DAT_REG_MASK   (0x1f << MII_DAT_REG_SHIFT)
+#define MII_DAT_PHY_SHIFT  23
+#define MII_DAT_PHY_MASK   (0x1f << MII_DAT_PHY_SHIFT)
+#define MII_DAT_OP_SHIFT   28
+#define MII_DAT_OP_WRITE   (0x5 << MII_DAT_OP_SHIFT)
+#define MII_DAT_OP_READ(0x6 << MII_DAT_OP_SHIFT)
+
+/* ETH Interrupts Mask register */
+#define ETH_IRMASK_REG 0x18
+
+/* ETH Interrupts register */
+#define ETH_IR_REG 0x1c
+#define ETH_IR_MII_SHIFT   0
+#define ETH_IR_MII_MASK(1 << ETH_IR_MII_SHIFT)
+
+/* ETH Control register */
+#define ETH_CTL_REG0x2c
+#define ETH_CTL_ENABLE_SHIFT   0
+#define ETH_CTL_ENABLE_MASK(1 << ETH_CTL_ENABLE_SHIFT)
+#define ETH_CTL_DISABLE_SHIFT  1
+#define ETH_CTL_DISABLE_MASK   (1 << ETH_CTL_DISABLE_SHIFT)
+#define ETH_CTL_RESET_SHIFT2
+#define ETH_CTL_RESET_MASK (1 << ETH_CTL_RESET_SHIFT)
+#define ETH_CTL_EPHY_SHIFT 3
+#define ETH_CTL_EPHY_MASK  (1 << ETH_CTL_EPHY_SHIFT)
+
+/* ETH Transmit Control register */
+#define ETH_TXCTL_REG  0x30
+#define ETH_TXCTL_FD_SHIFT 0
+#define ETH_TXCTL_FD_MASK  (1 << ETH_TXCTL_FD_SHIFT)
+
+/* ETH Transmit Watermask register */
+#define ETH_TXWMARK_REG0x34
+#define ETH_TXWMARK_WM_SHIFT   0
+#define ETH_TXWMARK_WM_MASK(0x3f << ETH_TXWMARK_WM_SHIFT)
+
+/* MIB Control register */
+#define MIB_CTL_REG0x3

Re: [U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Tom Rini]

On Mon, Feb 12, 2018 at 03:54:13PM +0100, Marek Vasut wrote:
> On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:
> > In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
> > thins for spi flash and mmc that are not required by the hw.
> 
> things ?
> 
> what hw, all supported boards you mean ?
> 
> > Give users more freedom of choice and use imply here instead
> > of select.
> > 
> > This should allow disabling spi support completely or using
> > sd/mmc boot in "raw mode" (no partitions).
> 
> You can just turn them off in the defconfigs, but I get what you're
> trying to say.

Well, hold on.  If you have select FOO under ARCH_xxx then you
can't disable it.  You have to use imply FOO under ARCH_xxx so that it's
turned on by default but a board can disable it in their defconfig.
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] arm: socfpga: use imply instead of select for spi/mmc

[Marek Vasut]

On 02/12/2018 05:46 PM, Tom Rini wrote:
> On Mon, Feb 12, 2018 at 03:54:13PM +0100, Marek Vasut wrote:
>> On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:
>>> In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
>>> thins for spi flash and mmc that are not required by the hw.
>>
>> things ?
>>
>> what hw, all supported boards you mean ?
>>
>>> Give users more freedom of choice and use imply here instead
>>> of select.
>>>
>>> This should allow disabling spi support completely or using
>>> sd/mmc boot in "raw mode" (no partitions).
>>
>> You can just turn them off in the defconfigs, but I get what you're
>> trying to say.
> 
> Well, hold on.  If you have select FOO under ARCH_xxx then you
> can't disable it.  You have to use imply FOO under ARCH_xxx so that it's
> turned on by default but a board can disable it in their defconfig.
> Thanks!

The patch is using imply already ...

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

Re: [U-Boot] [PATCH] arm: socfpga: use imply instead of select for spi/mmc

[Tom Rini]

On Mon, Feb 12, 2018 at 05:51:08PM +0100, Marek Vasut wrote:
> On 02/12/2018 05:46 PM, Tom Rini wrote:
> > On Mon, Feb 12, 2018 at 03:54:13PM +0100, Marek Vasut wrote:
> >> On 02/12/2018 03:52 PM, Simon Goldschmidt wrote:
> >>> In arch/arm/Kconfig, ARCH_SOCFPGA currently selects some
> >>> thins for spi flash and mmc that are not required by the hw.
> >>
> >> things ?
> >>
> >> what hw, all supported boards you mean ?
> >>
> >>> Give users more freedom of choice and use imply here instead
> >>> of select.
> >>>
> >>> This should allow disabling spi support completely or using
> >>> sd/mmc boot in "raw mode" (no partitions).
> >>
> >> You can just turn them off in the defconfigs, but I get what you're
> >> trying to say.
> > 
> > Well, hold on.  If you have select FOO under ARCH_xxx then you
> > can't disable it.  You have to use imply FOO under ARCH_xxx so that it's
> > turned on by default but a board can disable it in their defconfig.
> > Thanks!
> 
> The patch is using imply already ...

Right.  I wasn't clear if you were saying it wasn't needed, or just to
re-word things a lot :)

-- 
Tom


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

[U-Boot] Please pull u-boot-fsl-qoriq master

[York Sun]

Tom,

The following changes since commit 1811a928c6c7604d6d05a84b4d552a7c31b4994e:

  Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig (2018-02-08 19:09:03 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-fsl-qoriq.git

for you to fetch changes up to ee3556bcafbb05e59aabdc31368984e76acaabc4:

  drivers/ddr/fsl: Dual-license DDR driver (2018-02-09 08:36:40 -0800)


Hou Zhiqiang (1):
  ARMv8: ls1046a: Enable PCIe and E1000 in lpuart defconfig

Lukas Auer (1):
  crypto/fsl: instantiate all rng state handles

Rajat Srivastava (1):
  armv8: ls1088a: qspi: Enable XIP mode above 16 MB addresses

Sriram Dash (1):
  armv8: Remove dependency of SERDES for LSCH2 and LSCH3

Vinitha Pillai-B57223 (1):
  armv8: ls1012ardb: Add distro secure boot support

York Sun (1):
  drivers/ddr/fsl: Dual-license DDR driver

Zhao Qiang (1):
  PowerPC: phy: enable all phylib drivers when use phylib and tsec enet

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 14 +--
 arch/powerpc/include/asm/config.h |  4 +-
 configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 13 +++---
 configs/ls1046aqds_lpuart_defconfig   |  7 
 configs/ls1088aqds_qspi_SECURE_BOOT_defconfig |  1 +
 configs/ls1088aqds_qspi_defconfig |  1 +
 configs/ls1088ardb_qspi_SECURE_BOOT_defconfig |  1 +
 configs/ls1088ardb_qspi_defconfig |  1 +
 drivers/crypto/fsl/jobdesc.c  | 35 
 drivers/crypto/fsl/jobdesc.h  |  2 +-
 drivers/crypto/fsl/jr.c   | 57
---
 drivers/crypto/fsl/jr.h   |  2 +
 drivers/ddr/fsl/arm_ddr_gen3.c|  2 +-
 drivers/ddr/fsl/ctrl_regs.c   |  2 +-
 drivers/ddr/fsl/ddr1_dimm_params.c|  2 +-
 drivers/ddr/fsl/ddr2_dimm_params.c|  2 +-
 drivers/ddr/fsl/ddr3_dimm_params.c|  2 +-
 drivers/ddr/fsl/ddr4_dimm_params.c|  2 +-
 drivers/ddr/fsl/fsl_ddr_gen4.c|  2 +-
 drivers/ddr/fsl/fsl_mmdc.c|  2 +-
 drivers/ddr/fsl/interactive.c |  2 +-
 drivers/ddr/fsl/lc_common_dimm_params.c   |  2 +-
 drivers/ddr/fsl/main.c|  2 +-
 drivers/ddr/fsl/mpc85xx_ddr_gen1.c|  2 +-
 drivers/ddr/fsl/mpc85xx_ddr_gen2.c|  2 +-
 drivers/ddr/fsl/mpc85xx_ddr_gen3.c|  2 +-
 drivers/ddr/fsl/mpc86xx_ddr.c |  2 +-
 drivers/ddr/fsl/options.c |  2 +-
 drivers/ddr/fsl/util.c|  2 +-
 include/common_timing_params.h|  2 +-
 include/configs/ls1012ardb.h  | 20 +-
 include/fsl_ddr.h |  2 +-
 include/fsl_ddr_dimm_params.h |  2 +-
 include/fsl_ddrc_version.h|  2 +-
 include/fsl_immap.h   |  2 +-
 include/fsl_mmdc.h|  2 +-
 include/fsl_sec.h |  3 ++
 37 files changed, 129 insertions(+), 78 deletions(-)

Thanks.

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

Re: [U-Boot] U-Boot

[Mariano Coromac]

With that one there is none, I had problems with the other one.
Right now I just want to know how the CONIG parameters like this one:
CONFIG_8xx_CONS_SMC1=
Apply to my SAMA5D2. I already have my debug uart working but not the
monitor console. Therefore I can't even print 'help'.
Also, I'm still having trouble with the drivers as you can see above.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] CMD_PXE: Ramdisk does not pass to the kernel if FDT image does not specified

[vlaomao]

From: VlaoMao 

---
 cmd/pxe.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/cmd/pxe.c b/cmd/pxe.c
index 7043ad11fd..cf12b780b1 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -783,6 +783,11 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label 
*label)
if (!bootm_argv[3])
bootm_argv[3] = env_get("fdt_addr");
 
+   if (bootm_argv[2]) {
+   if(!bootm_argv[3])
+   bootm_argc = 3;
+   }
+
if (bootm_argv[3]) {
if (!bootm_argv[2])
bootm_argv[2] = "-";
-- 
2.16.1

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

Re: [U-Boot] [PATCH v2 0/5] STM32: Clean unused and factorize .h files in arch-stm32

[Vikas Manocha]

Great !

On 02/09/2018 04:09 AM, patrice.chot...@st.com wrote:
> From: Patrice Chotard 

For the series,

Reviewed-by: Vikas Manocha 

Cheers,
Vikas

> 
> Removes unused .h files in arch/arm/include/asm/arch-stm32xx 
> Factorize and clean some .h files to avoid to duplicate defines in 
> separate .h files
> 
> V2: _ create arch/arm/include/asm/arch-stm32 directory and move 
>   gpio.h and stm32f.h in it.
> 
> Patrice Chotard (5):
>   arch-stm32f4: Remove fmc.h file
>   arch-stm32: Move gpio.h for STM32 SoCs in include/asm/
>   arch-stm32: Factorize stm32.h for STM32F4 and F7
>   arch-stm32: Remove stm32_periph.h
>   arch-stm32: Clean arch-stm32f7/syscfg.h
> 
>  arch/arm/include/asm/arch-stm32/gpio.h   | 115 ++
>  arch/arm/include/asm/arch-stm32/stm32f.h |  22 
>  arch/arm/include/asm/arch-stm32f4/fmc.h  |  75 
>  arch/arm/include/asm/arch-stm32f4/gpio.h | 146 
> +--
>  arch/arm/include/asm/arch-stm32f4/stm32.h|  14 +--
>  arch/arm/include/asm/arch-stm32f4/stm32_periph.h |  38 --
>  arch/arm/include/asm/arch-stm32f7/gpio.h | 115 +-
>  arch/arm/include/asm/arch-stm32f7/stm32.h|  45 +--
>  arch/arm/include/asm/arch-stm32f7/stm32_periph.h |  23 
>  arch/arm/include/asm/arch-stm32f7/syscfg.h   |   9 --
>  arch/arm/include/asm/arch-stm32h7/gpio.h | 115 +-
>  board/st/stm32f746-disco/stm32f746-disco.c   |   1 -
>  drivers/mtd/stm32_flash.c|   2 +-
>  13 files changed, 144 insertions(+), 576 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-stm32/gpio.h
>  create mode 100644 arch/arm/include/asm/arch-stm32/stm32f.h
>  delete mode 100644 arch/arm/include/asm/arch-stm32f4/fmc.h
>  delete mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_periph.h
>  delete mode 100644 arch/arm/include/asm/arch-stm32f7/stm32_periph.h
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] TCP & Overrrun

[Joe Hershberger]

Hi Duncan,

On Sat, Feb 10, 2018 at 6:44 PM, Duncan Hare  wrote:
> On Sun, 11 Feb 2018 00:39:05 + (UTC)
> Duncan Hare  wrote:
>
>>  Duncan Hare
>>
>> 714 931 7952
>>
>>
>> - Forwarded Message -
>>  From: Joe Hershberger 
>>  To: Duncan Hare 
>> Cc: Joe Hershberger ; u-boot
>>  Sent: Friday, February 9, 2018 1:11 PM
>>  Subject: Re: [U-Boot] TCP & Overrrun
>>
>> On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare  wrote:
>> > On Thu, 8 Feb 2018 22:15:44 + (UTC)
>> > Duncan Hare  wrote:
>> >
>> >>  Duncan Hare
>> >>
>> >> 714 931 7952
>> >>
>> >>
>> >> - Forwarded Message -
>> >>  From: Joe Hershberger 
>> >>  To: Duncan Hare 
>> >> Cc: u-boot ; Joe Hershberger
>> >>  Sent: Thursday, February 8, 2018 11:40 AM
>> >>  Subject: Re: [U-Boot] TCP & Overrrun
>> >>
>> >> Hi Duncan,
>> >>
>> >> On Wed, Feb 7, 2018 at 8:40 PM, Duncan Hare 
>> >> wrote:
>> >> > I'm gettin overrun on the raspberry pi.
>> >> >
>> >> > Which ethernet drived does it use?
>> >>
>> >> You didn't specify which one you are talking about, but here's how
>> >> to find out...
>> >>
>> >> Assuming rpi3, find the config first...
>> >>
>> >> configs/rpi_3_defconfig says:
>> >> CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
>> >> arch/arm/dts/bcm2837-rpi-3-b.dts says: #include
>> >> "bcm283x-rpi-smsc9514.dtsi" arch/arm/dts/bcm283x-rpi-smsc9514.dtsi
>> >> says:ethernet: usbether@1 {
>> >> compatible = "usb424,ec00"; grep -rn ec00 drivers/ says:
>> >> drivers/usb/eth/smsc95xx.c
>> >>
>> >> Cheers,
>> >> -Joe
>> >>
>> >> > I need to determine if it
>> >> > uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the
>> >> > "net_rx_packets" buffer pool defined in net/net.c
>> >> >
>> >> > grep suggests it is not using net_rx_packets.
>> >> >
>> >> > Thanks
>> >> >
>> >> > Duncan Hare
>> >> > ___
>> >> > U-Boot mailing list
>> >> > U-Boot@lists.denx.de
>> >> > https://lists.denx.de/listinfo/u-boot
>> > ___
>> > Joe
>> >
>> > Two solutions:
>> >
>> > Option 1.
>> >
>>
>> I think option 1 is the way to go.
>>
>> Thanks,
>> -Joe
>
> Joe
>
> The overruns were caused by printing error messages. The print
> process is (very) slow compared with packet and computer speeds, and
> causes overruns.
>
> I turned off all the error messages in tcp.c and the overruns also
> stopped.

You could probably make the printing buffered (maybe just turn on such
a thing) to speed it up. You can also have different log levels to
turn on different traces so you can reduce the load for printing.

> Makes debugging harder.
>
> Duncan
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Alexander Graf]

> Am 12.02.2018 um 15:35 schrieb Simon Glass :
> 
> Hi Alex,
> 
>> On 9 February 2018 at 11:55, Alexander Graf  wrote:
>> 
>> 
>>> On 30.01.18 20:03, Heinrich Schuchardt wrote:
>>> Provide information about
>>> 
>>> - usage of the bootefi command
>>> - overview of UEFI
>>> - interaction between U-Boot and EFI drivers
>>> 
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>> v2
>>>  new file
>> 
>> The patch is very hard to read. Please just make this 2 patches. One
>> that removes the old file, one that adds the rewrite.
> 
> That doesn't make a lot of sense to me. Can you not just apply the
> patch locally and read it?

That‘s what I did, but I doubt the occasional reviewer does it. He also 
rewrites the file completely, even changing copyright. So IMHO remove+add is 
the better way to express what is happening here.

Alex


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

[U-Boot] SPARC support

[Travis Waters]

Hi All!


For several years, my organization has built and maintained boards 
SPARCH-architecture processors (specifically Gaisler's implementation of the 
LEON3), and we have depended on u-boot as our primary bootloader.  But when 
attempting to update u-boot this morning, we were disappointed to find that the 
SPARC support was completely removed last March with commits:


936478e797a87bcd4e002bf70430b6f58584b155

54f302f1197a490c2c4e3564c698ecd090d5013b


What was the reasoning for completely removing support for SPARC?  What will it 
take to get it back in?


Thanks!

-Travis Waters


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

Re: [U-Boot] SPARC support

[Tom Rini]

On Mon, Feb 12, 2018 at 07:28:14PM +, Travis Waters wrote:
> Hi All!
> 
> 
> For several years, my organization has built and maintained boards
> SPARCH-architecture processors (specifically Gaisler's implementation
> of the LEON3), and we have depended on u-boot as our primary
> bootloader.  But when attempting to update u-boot this morning, we
> were disappointed to find that the SPARC support was completely
> removed last March with commits:
> 
> 
> 936478e797a87bcd4e002bf70430b6f58584b155
> 
> 54f302f1197a490c2c4e3564c698ecd090d5013b
> 
> 
> What was the reasoning for completely removing support for SPARC?
> What will it take to get it back in?

It was removed due to a lack of active maintainers.  Last year when I
removed it, I know a few people reached out to other groups in private
to see if anyone wanted to maintain it, and no one stood up.  I would be
happy to have SPARC re-introduced, so long as:
- It builds with a modern toolchain such as
  https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/ or
  https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/
- It does not add anything to scripts/config_whitelist.txt
- Someone is going to be active in maintaining the port and doing the
  driver conversions to DM as they need to be done.
- A real nice bonus would be hooking up QEMU and Travis-CI and test.py
  so that a basic level of functionality can be confirmed and tested
  every time.

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] SPARC support

[Travis Waters]

Thanks for the update, Tom.
I think those are all fair assertions.  Was Gaisler ever approached as a 
maintainer, or have they just been unable to keep up?  We will approach Gaisler 
again and find out what's going on with their side.  We certainly have a vested 
interest in it so I may be able to talk the powers-that-be into maintaining if 
Gaisler won't commit.

-Travis

-Original Message-
From: Tom Rini [mailto:tr...@konsulko.com] 
Sent: Monday, February 12, 2018 1:16 PM
To: Travis Waters 
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] SPARC support

On Mon, Feb 12, 2018 at 07:28:14PM +, Travis Waters wrote:
> Hi All!
> 
> 
> For several years, my organization has built and maintained boards 
> SPARCH-architecture processors (specifically Gaisler's implementation 
> of the LEON3), and we have depended on u-boot as our primary 
> bootloader.  But when attempting to update u-boot this morning, we 
> were disappointed to find that the SPARC support was completely 
> removed last March with commits:
> 
> 
> 936478e797a87bcd4e002bf70430b6f58584b155
> 
> 54f302f1197a490c2c4e3564c698ecd090d5013b
> 
> 
> What was the reasoning for completely removing support for SPARC?
> What will it take to get it back in?

It was removed due to a lack of active maintainers.  Last year when I removed 
it, I know a few people reached out to other groups in private to see if anyone 
wanted to maintain it, and no one stood up.  I would be happy to have SPARC 
re-introduced, so long as:
- It builds with a modern toolchain such as
  https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/ or
  https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/
- It does not add anything to scripts/config_whitelist.txt
- Someone is going to be active in maintaining the port and doing the
  driver conversions to DM as they need to be done.
- A real nice bonus would be hooking up QEMU and Travis-CI and test.py
  so that a basic level of functionality can be confirmed and tested
  every time.

Thanks!

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

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

[Simon Glass]

Hi Alex,

On 12 February 2018 at 12:41, Alexander Graf  wrote:
>
>
>
> > Am 12.02.2018 um 15:35 schrieb Simon Glass :
> >
> > Hi Alex,
> >
> >> On 9 February 2018 at 11:55, Alexander Graf  wrote:
> >>
> >>
> >>> On 30.01.18 20:03, Heinrich Schuchardt wrote:
> >>> Provide information about
> >>>
> >>> - usage of the bootefi command
> >>> - overview of UEFI
> >>> - interaction between U-Boot and EFI drivers
> >>>
> >>> Signed-off-by: Heinrich Schuchardt 
> >>> ---
> >>> v2
> >>>  new file
> >>
> >> The patch is very hard to read. Please just make this 2 patches. One
> >> that removes the old file, one that adds the rewrite.
> >
> > That doesn't make a lot of sense to me. Can you not just apply the
> > patch locally and read it?
>
> That‘s what I did, but I doubt the occasional reviewer does it. He also 
> rewrites the file completely, even changing copyright. So IMHO remove+add is 
> the better way to express what is happening here.

Then perhaps the changes should be multiple patches? I agree it is
hard to review this sort of thing. But if you are happy with a
complete rewrite, then why not add a review tag? It doesn't much
matter that others cannot be bothered to review it properly. There is
some benefit to having a change history, I think.

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

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

[Max Filippov]

Hello,

On Tue, Jan 30, 2018 at 7:23 AM, Alexey Brodkin
 wrote:
> CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
> places in the same Makefile without any checks

Why? xtensa doesn't use any of it.

On Mon, Feb 12, 2018 at 6:23 AM, Tom Rini  wrote:
> I'm largely ok with the above, but:
> - For Xtensa (Max?), CONFIG_SYS_TEXT_ADDR needs to be renamed to
>   CONFIG_SYS_TEXT_BASE there

For xtensa that address is defined as an expression, like
(CONFIG_SYS_MEMORY_TOP - CONFIG_SYS_MONITOR_LEN),
and for a single board it may vary with the CPU core on that board.
If I just do this replacement then linking fails because of this symbolic
definition:

  xtensa-dc233c-elf-ld.bfd--gc-sections -Bstatic
--no-dynamic-linker -Ttext "(CONFIG_SYS_MEMORY_TOP -
CONFIG_SYS_MONITOR_LEN)"
  ...
  xtensa-dc233c-elf-ld.bfd: invalid hex number `(CONFIG_SYS_MEMORY_TOP
- CONFIG_SYS_MONITOR_LEN)'

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

Re: [U-Boot] SPARC support

[Tom Rini]

On Mon, Feb 12, 2018 at 08:40:44PM +, Travis Waters wrote:

> Thanks for the update, Tom.
> I think those are all fair assertions.  Was Gaisler ever approached as
> a maintainer, or have they just been unable to keep up?  We will
> approach Gaisler again and find out what's going on with their side.
> We certainly have a vested interest in it so I may be able to talk the
> powers-that-be into maintaining if Gaisler won't commit.

I believe that in the end I simply never got a reply from the previous
maintainers, one of whom was at Gaisler and one at Spaceteq.  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] Build system: Don't check for CONFIG_SYS_TEXT_BASE being set

[Tom Rini]

On Mon, Feb 12, 2018 at 12:48:02PM -0800, Max Filippov wrote:
> Hello,
> 
> On Tue, Jan 30, 2018 at 7:23 AM, Alexey Brodkin
>  wrote:
> > CONFIG_SYS_TEXT_BASE must be set anyways and then it is used in many
> > places in the same Makefile without any checks
> 
> Why? xtensa doesn't use any of it.
> 
> On Mon, Feb 12, 2018 at 6:23 AM, Tom Rini  wrote:
> > I'm largely ok with the above, but:
> > - For Xtensa (Max?), CONFIG_SYS_TEXT_ADDR needs to be renamed to
> >   CONFIG_SYS_TEXT_BASE there
> 
> For xtensa that address is defined as an expression, like
> (CONFIG_SYS_MEMORY_TOP - CONFIG_SYS_MONITOR_LEN),
> and for a single board it may vary with the CPU core on that board.
> If I just do this replacement then linking fails because of this symbolic
> definition:
> 
>   xtensa-dc233c-elf-ld.bfd--gc-sections -Bstatic
> --no-dynamic-linker -Ttext "(CONFIG_SYS_MEMORY_TOP -
> CONFIG_SYS_MONITOR_LEN)"
>   ...
>   xtensa-dc233c-elf-ld.bfd: invalid hex number `(CONFIG_SYS_MEMORY_TOP
> - CONFIG_SYS_MONITOR_LEN)'

OK.  But are those also really dynamic values?  SYS_MEMORY_TOP,
SYS_MONITOR_LEN and SYS_TEXT_ADDR need to be converted to Kconfig, or
removed from CONFIG namespace, whatever makes the most sense.  If the
notion of CONFIG_SYS_TEXT_BASE is just pointless to Xtensa, we add them
to the ifneq(...,) test for the change Alexey is doing.  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] Build system: Don't check for CONFIG_SYS_TEXT_BASE being set

[Max Filippov]

On Mon, Feb 12, 2018 at 1:03 PM, Tom Rini  wrote:
>> On Mon, Feb 12, 2018 at 6:23 AM, Tom Rini  wrote:
>> > I'm largely ok with the above, but:
>> > - For Xtensa (Max?), CONFIG_SYS_TEXT_ADDR needs to be renamed to
>> >   CONFIG_SYS_TEXT_BASE there
>>
>> For xtensa that address is defined as an expression, like
>> (CONFIG_SYS_MEMORY_TOP - CONFIG_SYS_MONITOR_LEN),
>> and for a single board it may vary with the CPU core on that board.
>
> OK.  But are those also really dynamic values?  SYS_MEMORY_TOP,
> SYS_MONITOR_LEN and SYS_TEXT_ADDR need to be converted to Kconfig, or
> removed from CONFIG namespace, whatever makes the most sense.  If the

At least two of the three -- yes, in a sense that they cannot be calculated
without the core-specific configuration overlay.
I'll move SYS_MONITOR_LEN to the Kconfig and move SYS_MEMORY_TOP
and SYS_TEXT_ADDR from the CONFIG namespace.

> notion of CONFIG_SYS_TEXT_BASE is just pointless to Xtensa, we add them
> to the ifneq(...,) test for the change Alexey is doing.  Thanks!

Yes, please.

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

Re: [U-Boot] Please pull u-boot-fsl-qoriq master

[Tom Rini]

On Mon, Feb 12, 2018 at 05:06:35PM +, York Sun wrote:

> Tom,
> 
> The following changes since commit 1811a928c6c7604d6d05a84b4d552a7c31b4994e:
> 
>   Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig (2018-02-08 19:09:03 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to ee3556bcafbb05e59aabdc31368984e76acaabc4:
> 
>   drivers/ddr/fsl: Dual-license DDR driver (2018-02-09 08:36:40 -0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Fix misaligned buffer in env_fat_save

[Tom Rini]

On Wed, Feb 07, 2018 at 08:01:54PM +, Alex Kiernan wrote:

> When saving the environment on a platform which has DMA alignment
> larger than the natural alignment, env_fat_save triggers a debug
> message in file_fat_write:
> 
>   Saving Environment to FAT... writing uboot.env
>   FAT: Misaligned buffer address (9df1c8e0)
>   OK
> 
> Signed-off-by: Alex Kiernan 

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] ARMv8: ls1046a: Enable PCIe and E1000 in lpuart defconfig

[York Sun]

On 02/04/2018 09:47 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> Enable PCIe and E1000 in ls1046aqds lpuart defconfig.
> 
> Signed-off-by: Hou Zhiqiang 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks

York
___
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/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.
> 
> Signed-off-by: Rajat Srivastava 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks

York

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

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

[York Sun]

On 01/30/2018 02:29 AM, Sriram Dash wrote:
> Remove dependency of SYS_HAS_SERDES for Layerscape Chasis 3/2.
> 
> Signed-off-by: Sriram Dash 
> ---
> Changes in v3:
>   - Rebase to latest code.
>   - Include changes for LSCH2.
> 
> Changes in v2:
>   - Remove ifdef when including fsl_serdes.h
> 

Applied to fsl-qoriq master, awaiting upstream. Thanks

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

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

[York Sun]

On 01/30/2018 09:07 PM, Sumit Garg wrote:
>> -Original Message-
>> From: York Sun
>> Sent: Tuesday, January 30, 2018 2:57 AM
>> To: Sumit Garg ; u-boot@lists.denx.de
>> Cc: Ruchika Gupta ; Prabhakar Kushwaha
>> ; Vini Pillai 
>> Subject: Re: [PATCH v2] arm64: ls1012ardb: Add distro secure boot support
>>
>> On 01/15/2018 09:34 AM, Sumit Garg wrote:
 From: York Sun
 Sent: Monday, January 15, 2018 10:59 PM

 On 01/08/2018 09:59 PM, Sumit Garg wrote:
> From: Vinitha Pillai-B57223 
>
> Enable validation of boot.scr script prior to its execution
> dependent on "secureboot" flag in environment. Enable fall back
> option to qspi boot in case of secure boot.
>
> Signed-off-by: Sumit Garg 
> Signed-off-by: Vinitha Pillai 
> ---
>
> Changes in v2:
> Rebased to top of master
>
>  configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 14 +++---
>  include/configs/ls1012ardb.h  | 20 ++--
>  2 files changed, 25 insertions(+), 9 deletions(-)
>



> +CONFIG_ENV_IS_IN_SPI_FLASH=y
>>
>> This is wrong. You shouldn't have ENV for secure boot. Please double check.
>>
>> York
>  
> Yes you are correct. We should drop this from defconfig. Shall I send next 
> version or could you drop it while applying the patch?
> 

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] crypto/fsl: instantiate all rng state handles

[York Sun]

On 01/25/2018 05:11 AM, Lukas Auer wrote:
> Extend the instantiate_rng() function and the corresponding CAAM job
> descriptor to instantiate all RNG state handles. This moves the RNG
> instantiation code in line with the CAAM kernel driver.
> 
> Previously, only the first state handle was instantiated. The second one
> was instantiated by the CAAM kernel driver. This works if the kernel
> runs in secure mode, but fails in non-secure mode since the kernel
> driver uses DEC0 directly instead of over the job ring interface.
> Instantiating all RNG state handles in u-boot removes the need for using
> DEC0 in the kernel driver, making it possible to use the CAAM in
> non-secure mode.
> 
> Signed-off-by: Lukas Auer 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] PowerPC: phy: enable all phylib drivers when use phylib and tsec enet

[York Sun]

On 02/06/2018 06:22 PM, Zhao Qiang wrote:
>  should be included when CONFIG_PHYLIB and
> CONFIG_TSEC_ENET are defined.
> 
> Fixes: 3146f0c017 ("Move PHYLIB to Kconfig")
> Signed-off-by: Zhao Qiang 
> ---

Applied to fsl-qoriq master, awaiting upstream. Thanks.

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

Re: [U-Boot] [RFC PATCH] net: mii command: disable build for 64-bit Allwinner boards

[André Przywara]

On 12/02/18 15:47, Tom Rini wrote:
> On Mon, Feb 12, 2018 at 01:25:21AM +, Andre Przywara wrote:
> 
>> The current master fails to build some Allwinner H5 boards, due to
>> exceeding the U-Boot proper size limit we currently have still in place.
>> This affects:
>> - nanopi_neo2_defconfig
>> - nanopi_neo_plus2_defconfig
>> - orangepi_pc2_defconfig
>> - orangepi_prime_defconfig
>> - orangepi_zero_plus2_defconfig
>> To workaround this issue, a left-over low hanging fruit is to disable
>> the MII *command*, which is probably only useful for debugging and not
>> needed for a normal boot flow, even when booting via network (PXE/TFTP).
>>
>> Allow to de-select CMD_MII, even when the distro default enables it.
>> Then disable it explicitly in the affected board's defconfigs.
>> This makes all Allwinner ARMv8 boards build again.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>> Hi,
>>
>> my sincere apologies for this ugly hack (and I welcome any nicer solution!),
>> but we are running out of silver bullets for this particular problem and this
>> command seems both easy to give up and worthwhile in terms of code size
>> savings (~11KB).
>> The "default n if ..." doesn't seem to work with "imply", so I needed to
>> disable it in each of the affected defconfigs. Please let me know if there
>> is a better solution.
> 
> Can we not move the env location now?  Thanks!

Not yet, unfortunately. As of v2018.01 we store the environment in raw
MMC still and need to obey the limit. The just merged multi-env support
allows us to *transition* all users over to a FAT environment (because
it will pickup the env from MMC, but save it in FAT by default). But we
need at least one release to be nice to our users: v2018.03. In this
time we still need to obey the limit, to not destroy the existing legacy
env in MMC.
With v2018.05-rc1 we can then disable ENV_IS_IN_MMC and remove the limit.

So the end is nigh ;-), but not there yet.

Cheers,
Andre.

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

Re: [U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

[York Sun]

On 02/07/2018 11:48 AM, York Sun wrote:
> To make this driver easier to be reused, dual-license DDR driver.
> 
> Signed-off-by: York Sun 
> CC: Simon Glass 
> CC: Tom Rini 
> CC: Heinrich Schuchardt 
> CC: Thomas Schaefer 
> CC: Masahiro Yamada 
> CC: Robert P. J. Day 
> CC: Alexander Merkle 
> CC: Joakim Tjernlund 
> CC: Curt Brune 
> CC: Valentin Longchamp 
> CC: Wolfgang Denk 
> CC: Anatolij Gustschin 
> CC: Ira W. Snyder 
> CC: Marek Vasut 
> CC: Kyle Moffett 
> CC: Sebastien Carlier 
> CC: Stefan Roese 
> CC: Peter Tyser 
> CC: Paul Gortmaker 
> CC: Peter Tyser 
> CC: Jean-Christophe PLAGNIOL-VILLARD 
> ---
> 

Applied to fsl-qoriq master, awaiting upstream.

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

[U-Boot] [PATCH 3/3] Atmel TPM: Fix potential buffer overruns

[Jeremy Boone]

From: Jeremy Boone 

Ensure that the Atmel TPM driver performs sufficient
validation of the length returned in the TPM response header.
This patch prevents memory corruption if the header contains a
length value that is larger than the destination buffer.

Signed-off-by: Jeremy Boone 
---
 drivers/tpm/tpm_atmel_twi.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index eba654b..4fd772d 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -106,13 +106,23 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
udelay(100);
}
if (!res) {
-   *recv_len = get_unaligned_be32(recvbuf + 2);
-   if (*recv_len > 10)
+   unsigned int hdr_recv_len;
+   hdr_recv_len = get_unaligned_be32(recvbuf + 2);
+   if (hdr_recv_len < 10) {
+   puts("tpm response header too small\n");
+   return -1;
+   } else if (hdr_recv_len > *recv_len) {
+   puts("tpm response length is bigger than receive 
buffer\n");
+   return -1;
+   } else {
+   *recv_len = hdr_recv_len;
 #ifndef CONFIG_DM_I2C
res = i2c_read(0x29, 0, 0, recvbuf, *recv_len);
 #else
res = dm_i2c_read(dev, 0, recvbuf, *recv_len);
 #endif
+
+   }
}
if (res) {
printf("i2c_read returned %d (rlen=%d)\n", res, *recv_len);
-- 
2.7.4

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

[U-Boot] [PATCH 0/3] Fix potential buffer overruns in TPM driver

[Jeremy Boone]

From: Jeremy Boone 

The TPM response packet often contains a variable-length payload. It is
the responsibility of U-Boot driver code to ensure that the length value
that has been extracted from the response packet's header or body is
appropriately sized before copying that data into another buffer.

Jeremy Boone (3):
  STMicro TPM: Fix potential buffer overruns
  Infineon TPM: Fix potential buffer overruns
  Atmel TPM: Fix potential buffer overruns

 drivers/tpm/tpm_atmel_twi.c| 14 --
 drivers/tpm/tpm_tis_infineon.c |  5 +++--
 drivers/tpm/tpm_tis_st33zp24_i2c.c |  5 +++--
 drivers/tpm/tpm_tis_st33zp24_spi.c |  5 +++--
 4 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH 1/3] STMicro TPM: Fix potential buffer overruns

[Jeremy Boone]

From: Jeremy Boone 

This patch prevents integer underflow when the length was too small,
which could lead to memory corruption.

Signed-off-by: Jeremy Boone 
---
 drivers/tpm/tpm_tis_st33zp24_i2c.c | 5 +++--
 drivers/tpm/tpm_tis_st33zp24_spi.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/tpm/tpm_tis_st33zp24_i2c.c 
b/drivers/tpm/tpm_tis_st33zp24_i2c.c
index c8d0125..245218f 100644
--- a/drivers/tpm/tpm_tis_st33zp24_i2c.c
+++ b/drivers/tpm/tpm_tis_st33zp24_i2c.c
@@ -303,7 +303,8 @@ static int st33zp24_i2c_recv_data(struct udevice *dev, u8 
*buf, size_t count)
 static int st33zp24_i2c_recv(struct udevice *dev, u8 *buf, size_t count)
 {
struct tpm_chip *chip = dev_get_priv(dev);
-   int size, expected;
+   int size;
+   unsigned int expected;
 
if (!chip)
return -ENODEV;
@@ -320,7 +321,7 @@ static int st33zp24_i2c_recv(struct udevice *dev, u8 *buf, 
size_t count)
}
 
expected = get_unaligned_be32(buf + 2);
-   if (expected > count) {
+   if (expected > count || expected < TPM_HEADER_SIZE) {
size = -EIO;
goto out;
}
diff --git a/drivers/tpm/tpm_tis_st33zp24_spi.c 
b/drivers/tpm/tpm_tis_st33zp24_spi.c
index dcf55ee..c4c5e05 100644
--- a/drivers/tpm/tpm_tis_st33zp24_spi.c
+++ b/drivers/tpm/tpm_tis_st33zp24_spi.c
@@ -431,7 +431,8 @@ static int st33zp24_spi_recv_data(struct udevice *dev, u8 
*buf, size_t count)
 static int st33zp24_spi_recv(struct udevice *dev, u8 *buf, size_t count)
 {
struct tpm_chip *chip = dev_get_priv(dev);
-   int size, expected;
+   int size;
+   unsigned int expected;
 
if (!chip)
return -ENODEV;
@@ -448,7 +449,7 @@ static int st33zp24_spi_recv(struct udevice *dev, u8 *buf, 
size_t count)
}
 
expected = get_unaligned_be32(buf + 2);
-   if (expected > count) {
+   if (expected > count || expected < TPM_HEADER_SIZE) {
size = -EIO;
goto out;
}
-- 
2.7.4

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

[U-Boot] [PATCH 2/3] Infineon TPM: Fix potential buffer overruns

[Jeremy Boone]

From: Jeremy Boone 

Ensure that the Infineon I2C and SPI TPM driver performs adequate
validation of the length extracted from the TPM response header.
This patch prevents integer underflow when the length was too small,
which could lead to memory corruption.

Signed-off-by: Jeremy Boone 
---
 drivers/tpm/tpm_tis_infineon.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tpm/tpm_tis_infineon.c b/drivers/tpm/tpm_tis_infineon.c
index e3e20d8..41b748e 100644
--- a/drivers/tpm/tpm_tis_infineon.c
+++ b/drivers/tpm/tpm_tis_infineon.c
@@ -374,7 +374,8 @@ static int tpm_tis_i2c_recv(struct udevice *dev, u8 *buf, 
size_t count)
 {
struct tpm_chip *chip = dev_get_priv(dev);
int size = 0;
-   int expected, status;
+   int status;
+   unsigned int expected;
int rc;
 
status = tpm_tis_i2c_status(dev);
@@ -394,7 +395,7 @@ static int tpm_tis_i2c_recv(struct udevice *dev, u8 *buf, 
size_t count)
}
 
expected = get_unaligned_be32(buf + TPM_RSP_SIZE_BYTE);
-   if ((size_t)expected > count) {
+   if ((size_t)expected > count || (size_t)expected < TPM_HEADER_SIZE) {
debug("Error size=%x, expected=%x, count=%x\n", size, expected,
  count);
return -ENOSPC;
-- 
2.7.4

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

Re: [U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

[York Sun]

On 02/12/2018 02:44 PM, Marek Vasut wrote:
> On 02/12/2018 11:41 PM, York Sun wrote:
>> On 02/07/2018 11:48 AM, York Sun wrote:
>>> To make this driver easier to be reused, dual-license DDR driver.
>>>
>>> Signed-off-by: York Sun 
>>> CC: Simon Glass 
>>> CC: Tom Rini 
>>> CC: Heinrich Schuchardt 
>>> CC: Thomas Schaefer 
>>> CC: Masahiro Yamada 
>>> CC: Robert P. J. Day 
>>> CC: Alexander Merkle 
>>> CC: Joakim Tjernlund 
>>> CC: Curt Brune 
>>> CC: Valentin Longchamp 
>>> CC: Wolfgang Denk 
>>> CC: Anatolij Gustschin 
>>> CC: Ira W. Snyder 
>>> CC: Marek Vasut 
>>> CC: Kyle Moffett 
>>> CC: Sebastien Carlier 
>>> CC: Stefan Roese 
>>> CC: Peter Tyser 
>>> CC: Paul Gortmaker 
>>> CC: Peter Tyser 
>>> CC: Jean-Christophe PLAGNIOL-VILLARD 
>>> ---
>>>
>>
>> Applied to fsl-qoriq master, awaiting upstream.
> 
> Are you sure you can do that so easily ? Did you get ACK on this from
> everyone who contributed to that driver ?
> 

Nobody said anything. Some addresses bounced. And most changes made out
people outside Freescale/NXP are minor changes, except twice the files
were moved during U-Boot structure change. What options do I have?

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

Re: [U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

[Marek Vasut]

On 02/12/2018 11:41 PM, York Sun wrote:
> On 02/07/2018 11:48 AM, York Sun wrote:
>> To make this driver easier to be reused, dual-license DDR driver.
>>
>> Signed-off-by: York Sun 
>> CC: Simon Glass 
>> CC: Tom Rini 
>> CC: Heinrich Schuchardt 
>> CC: Thomas Schaefer 
>> CC: Masahiro Yamada 
>> CC: Robert P. J. Day 
>> CC: Alexander Merkle 
>> CC: Joakim Tjernlund 
>> CC: Curt Brune 
>> CC: Valentin Longchamp 
>> CC: Wolfgang Denk 
>> CC: Anatolij Gustschin 
>> CC: Ira W. Snyder 
>> CC: Marek Vasut 
>> CC: Kyle Moffett 
>> CC: Sebastien Carlier 
>> CC: Stefan Roese 
>> CC: Peter Tyser 
>> CC: Paul Gortmaker 
>> CC: Peter Tyser 
>> CC: Jean-Christophe PLAGNIOL-VILLARD 
>> ---
>>
> 
> Applied to fsl-qoriq master, awaiting upstream.

Are you sure you can do that so easily ? Did you get ACK on this from
everyone who contributed to that driver ?

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

[U-Boot] [PATCH 0/2] xtensa: clean up SYS_MONITOR_LEN/SYS_TEXT_ADDR

[Max Filippov]

Hello,

this series moves SYS_MONITOR_LEN to Kconfig for board/cadence/xtfpga,
removes SYS_MEMORY_TOP and renames CONFIG_SYS_TEXT_ADDR to
XTENSA_SYS_TEXT_ADDR.

Max Filippov (2):
  board/cadence/xtfpga: move SYS_MONITOR_LEN to Kconfig
  xtensa: clean up CONFIG_SYS_TEXT_ADDR

 arch/xtensa/cpu/start.S  |  2 +-
 arch/xtensa/cpu/u-boot.lds   |  4 ++--
 board/cadence/xtfpga/Kconfig |  5 +
 include/configs/xtfpga.h | 12 ++--
 4 files changed, 10 insertions(+), 13 deletions(-)

-- 
2.1.4

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

[U-Boot] [PATCH 1/2] board/cadence/xtfpga: move SYS_MONITOR_LEN to Kconfig

[Max Filippov]

Signed-off-by: Max Filippov 
---
 board/cadence/xtfpga/Kconfig | 5 +
 include/configs/xtfpga.h | 7 ---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/board/cadence/xtfpga/Kconfig b/board/cadence/xtfpga/Kconfig
index 69296be49c7a..67ae3860b6d4 100644
--- a/board/cadence/xtfpga/Kconfig
+++ b/board/cadence/xtfpga/Kconfig
@@ -36,4 +36,9 @@ config BOARD_SDRAM_SIZE
default 0x1800 if XTFPGA_ML605
default 0x3800 if XTFPGA_KC705
 
+config SYS_MONITOR_LEN
+   hex
+   default 0x0002 if XTFPGA_LX60
+   default 0x0004 if !XTFPGA_LX60
+
 endif
diff --git a/include/configs/xtfpga.h b/include/configs/xtfpga.h
index 79cc1e8fc1b8..86c7e7cf279c 100644
--- a/include/configs/xtfpga.h
+++ b/include/configs/xtfpga.h
@@ -59,13 +59,6 @@
 
 #define CONFIG_SYS_SDRAM_BASE  MEMADDR(0x)
 
-/* Lx60 can only map 128kb memory (instead of 256kb) when running under OCD */
-#ifdef CONFIG_XTFPGA_LX60
-# define CONFIG_SYS_MONITOR_LEN0x0002  /* 128KB */
-#else
-# define CONFIG_SYS_MONITOR_LEN0x0004  /* 256KB */
-#endif
-
 #define CONFIG_SYS_MALLOC_LEN  (256 << 10) /* heap  256KB */
 
 /* Linux boot param area in RAM (used only when booting linux) */
-- 
2.1.4

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

[U-Boot] [PATCH 2/2] xtensa: clean up CONFIG_SYS_TEXT_ADDR

[Max Filippov]

Drop CONFIG_SYS_MEMORY_TOP. Rename CONFIG_SYS_TEXT_ADDR to
XTENSA_SYS_TEXT_ADDR.

Signed-off-by: Max Filippov 
---
 arch/xtensa/cpu/start.S| 2 +-
 arch/xtensa/cpu/u-boot.lds | 4 ++--
 include/configs/xtfpga.h   | 5 ++---
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/xtensa/cpu/start.S b/arch/xtensa/cpu/start.S
index 8e4bc99e4295..cdb875da5339 100644
--- a/arch/xtensa/cpu/start.S
+++ b/arch/xtensa/cpu/start.S
@@ -226,7 +226,7 @@ _start:
 #endif
 
movia0, 0
-   movisp, (CONFIG_SYS_TEXT_ADDR - 16) & 0xfff0
+   movisp, (XTENSA_SYS_TEXT_ADDR - 16) & 0xfff0
 
 #ifdef CONFIG_DEBUG_UART
movia4, debug_uart_init
diff --git a/arch/xtensa/cpu/u-boot.lds b/arch/xtensa/cpu/u-boot.lds
index 853ae5a94891..7200bc59fbfc 100644
--- a/arch/xtensa/cpu/u-boot.lds
+++ b/arch/xtensa/cpu/u-boot.lds
@@ -74,9 +74,9 @@ SECTIONS
   SECTION_VECTOR(DoubleExceptionVector,text,XCHAL_DOUBLEEXC_VECTOR_VADDR,
 FOLLOWING(.DoubleExceptionVector.literal))
 
-  __monitor_start = CONFIG_SYS_TEXT_ADDR;
+  __monitor_start = XTENSA_SYS_TEXT_ADDR;
 
-  SECTION_text(CONFIG_SYS_TEXT_ADDR, FOLLOWING(.DoubleExceptionVector.text))
+  SECTION_text(XTENSA_SYS_TEXT_ADDR, FOLLOWING(.DoubleExceptionVector.text))
   SECTION_rodata(ALIGN(16), FOLLOWING(.text))
   SECTION_u_boot_list(ALIGN(16), FOLLOWING(.rodata))
   SECTION_data(ALIGN(16), FOLLOWING(.u_boot_list))
diff --git a/include/configs/xtfpga.h b/include/configs/xtfpga.h
index 86c7e7cf279c..d0b3b34571d2 100644
--- a/include/configs/xtfpga.h
+++ b/include/configs/xtfpga.h
@@ -91,9 +91,8 @@
 #define CONFIG_SYS_MEMORY_SIZE CONFIG_SYS_SDRAM_SIZE
 #endif
 
-#define CONFIG_SYS_MEMORY_TOP  MEMADDR(CONFIG_SYS_MEMORY_SIZE)
-#define CONFIG_SYS_TEXT_ADDR   \
-   (CONFIG_SYS_MEMORY_TOP - CONFIG_SYS_MONITOR_LEN)
+#define XTENSA_SYS_TEXT_ADDR   \
+   (MEMADDR(CONFIG_SYS_MEMORY_SIZE) - CONFIG_SYS_MONITOR_LEN)
 
 /* Used by tftpboot; env var 'loadaddr' */
 #define CONFIG_SYS_LOAD_ADDR   MEMADDR(0x0200)
-- 
2.1.4

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

Re: [U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

[Tom Rini]

On Mon, Feb 12, 2018 at 10:51:10PM +, York Sun wrote:
> On 02/12/2018 02:44 PM, Marek Vasut wrote:
> > On 02/12/2018 11:41 PM, York Sun wrote:
> >> On 02/07/2018 11:48 AM, York Sun wrote:
> >>> To make this driver easier to be reused, dual-license DDR driver.
> >>>
> >>> Signed-off-by: York Sun 
> >>> CC: Simon Glass 
> >>> CC: Tom Rini 
> >>> CC: Heinrich Schuchardt 
> >>> CC: Thomas Schaefer 
> >>> CC: Masahiro Yamada 
> >>> CC: Robert P. J. Day 
> >>> CC: Alexander Merkle 
> >>> CC: Joakim Tjernlund 
> >>> CC: Curt Brune 
> >>> CC: Valentin Longchamp 
> >>> CC: Wolfgang Denk 
> >>> CC: Anatolij Gustschin 
> >>> CC: Ira W. Snyder 
> >>> CC: Marek Vasut 
> >>> CC: Kyle Moffett 
> >>> CC: Sebastien Carlier 
> >>> CC: Stefan Roese 
> >>> CC: Peter Tyser 
> >>> CC: Paul Gortmaker 
> >>> CC: Peter Tyser 
> >>> CC: Jean-Christophe PLAGNIOL-VILLARD 
> >>> ---
> >>>
> >>
> >> Applied to fsl-qoriq master, awaiting upstream.
> > 
> > Are you sure you can do that so easily ? Did you get ACK on this from
> > everyone who contributed to that driver ?
> 
> Nobody said anything. Some addresses bounced. And most changes made out
> people outside Freescale/NXP are minor changes, except twice the files
> were moved during U-Boot structure change. What options do I have?

So, I saw this when it was posted.  Am I pleased to see more code change
license terms? No.  Do I expect everyone to agree with this?  No.  Do I
accept the (nominally) technical arguments made about why this should be
done? Yes.  Can I object if someone who feels they do have standing to
object to this objects?  No.

Hope this helps.

-- 
Tom


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

[U-Boot] [ANN] U-Boot v2018.03-rc2 released

[Tom Rini]

Hey all,

It's release day and v2018.03-rc2 is out.  The big thing is that there's
some env related changes that need to be first sorted out and tested,
then pulled in.

Other than the env fixes, I hope to pull in some more Kconfig
migrations.  These I hope will be size neutral, but I know that a few
things aren't due to fixing underlying omissions.

Things look on track f26th, -rc4 on March 5th and then release on March
12th.  Thanks all!

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

[Derald Woods]

On Mon, Feb 5, 2018 at 7:13 AM, Derald Woods 
wrote:

> 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"
>> > mailto:ag...@suse.de>
>> > >>
>> 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
>> > mailto:woods.techni...@gmail.com>
>> > > > >>
>> > 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
> 

Re: [U-Boot] [PATCH] configs: Migrate CONFIG_SYS_TEXT_BASE

[Tom Rini]

On Tue, Feb 06, 2018 at 03:15:58PM -0600, Adam Ford wrote:
> On Sat, Feb 3, 2018 at 11:10 AM, Tom Rini  wrote:
> > On the NIOS2 and Xtensa architectures, we do not have
> > CONFIG_SYS_TEXT_BASE set.  This is a strict migration of the current
> > values into the defconfig and removing them from the headers.
> >
> > I did not attempt to add more default values in and for now will leave
> > that to maintainers.
> >
> > Signed-off-by: Tom Rini 
> > ---
> > What I wonder about, at this point, would be how hard it would be to add
> > imply FOO hex/int/str/etc value to the imply keyword.  I don't want to
> > see 100 lines worth of default 0xX if Y || Z for CONFIG_SYS_TEXT_BASE as
> > that will be unmaintainable.
> > ---
> 
> [snip]
> 
> >   new boards should not use this option.
> >
> >  config SYS_TEXT_BASE
> > -   depends on ARC || X86 || ARCH_UNIPHIER || ARCH_ZYNQMP || \
> > -   (M68K && !TARGET_ASTRO_MCF5373L) || MICROBLAZE || MIPS || \
> > -   ARCH_ZYNQ || ARCH_KEYSTONE || ARCH_OMAP2PLUS
> > +   depends on !NIOS2 && !XTENSA
> > depends on !EFI_APP
> > +   default 0x8080 if ARCH_OMAP2PLUS
> > hex "Text Base"
> > help
> > - TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
> > + The address in memory that U-Boot will be running from, initially.
> >
> > -   default 0x8080 if ARCH_OMAP2PLUS
> >
> 
> I have a question.  I don't think anything is wrong, but
> doc/SPL/README.omap3 shows two different options for
> CONFIG_SYS_TEXT_BASE and neither of them are 0x8080
> 
> Option 1 (SPL only):
> 0x8010: CONFIG_SYS_TEXT_BASE of U-Boot
> 
> Option 2 (SPL or X-Loader):
> 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
> 
> I'm sure it's probably been this way for a while, but when reviewing
> the omap3_logic board (am/dm37), I noticed it's currenly using
> 0x8080, but I am not sure how the rest of the memory map from the
> readme applies.  Does this README file need to be updated or deleted?
> Will we have any memory conflicts or overlap?

So, good question.  And I think it's partly due to the docs being out of
date.  The docs are correct, for the time.  This is best now explained
in include/configs/ti_armv7_common.h:
/*
 * Place the image at the start of the ROM defined image space (per
 * CONFIG_SPL_TEXT_BASE and we limit our size to the ROM-defined
 * downloaded image area minus 1KiB for scratch space.  We initalize DRAM as
 * soon as we can so that we can place stack, malloc and BSS there.  We load
 * U-Boot itself into memory at 0x8080 for legacy reasons (to not conflict
 * with older SPLs).  We have our BSS be placed 2MiB after this, to allow for
 * the default Linux kernel address of 0x80008000 to work with most sized
 * kernels, in the Falcon Mode case.  We have the SPL malloc pool at the end
 * of the BSS area.  We suggest that the stack be placed at 32MiB after the
 * start of DRAM to allow room for all of the above (handled in Kconfig).
 */

-- 
Tom


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