Re: [PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins

[Marek Szyprowski]

Hi

On 23.01.2020 08:33, Minkyu Kang wrote:
> On 23/01/2020 16:20, Marek Szyprowski wrote:
>> On 23.01.2020 08:09, Minkyu Kang wrote:
>>> On 17/01/2020 22:02, Marek Szyprowski wrote:
 XOM pins provide information for iROM bootloader about the boot device.
 Those pins are mapped to lower bits of OP_MODE register (0x1008),
 which is common for all Exynos SoC variants. Set the default MMC device id
 to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
 the eMMC).

 Signed-off-by: Marek Szyprowski 
 ---
 v2:
 - store mmc boot device to ${mmcbootdev} env
 - print information about boot mmc device
 ---
arch/arm/mach-exynos/include/mach/cpu.h |  1 +
board/samsung/common/board.c| 28 +
configs/odroid-xu3_defconfig|  1 +
configs/odroid_defconfig|  1 +
4 files changed, 31 insertions(+)

 diff --git a/arch/arm/mach-exynos/include/mach/cpu.h 
 b/arch/arm/mach-exynos/include/mach/cpu.h
 index 766edeeb29..fb5fdaf3ba 100644
 --- a/arch/arm/mach-exynos/include/mach/cpu.h
 +++ b/arch/arm/mach-exynos/include/mach/cpu.h
 @@ -17,6 +17,7 @@

#define EXYNOS4_GPIO_PART3_BASE 0x0386
#define EXYNOS4_PRO_ID  0x1000
 +#define EXYNOS4_OP_MODE   0x1008
#define EXYNOS4_SYSREG_BASE 0x1001
#define EXYNOS4_POWER_BASE  0x1002
#define EXYNOS4_SWRESET 0x10020400
 diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
 index ee2fc7971e..cb94ced54e 100644
 --- a/board/samsung/common/board.c
 +++ b/board/samsung/common/board.c
 @@ -24,6 +24,8 @@
#include 
#include 
#include 
 +#include 
 +#include 
#include 
#include 
#include 
 @@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
return 0;
}

 +/**
 + * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
 + */
 +static int get_boot_mmc_dev(void)
 +{
 +  u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
 +
 +  if (mode == 0x04)
 +  return 2; /* MMC2: SD */
 +
 +  /* MMC0: eMMC or unknown */
 +  return 0;
 +}
 +
#if defined CONFIG_EXYNOS_TMU
/* Boot Time Thermal Analysis for SoC temperature threshold breach */
static void boot_temp_check(void)
 @@ -280,6 +296,8 @@ int board_late_init(void)
{
struct udevice *dev;
int ret;
 +  int mmcbootdev = get_boot_mmc_dev();
 +  char mmcbootdev_str[16];

stdio_print_current_devices();
ret = uclass_first_device_err(UCLASS_CROS_EC, );
 @@ -292,6 +310,11 @@ int board_late_init(void)
panic("Cannot init cros-ec device");
return -1;
}
 +
 +  printf("Boot device: MMC(%u)\n", mmcbootdev);
 +  sprintf(mmcbootdev_str, "%u", mmcbootdev);
 +  env_set("mmcbootdev", mmcbootdev_str);
 +
return 0;
}
#endif
 @@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type 
 init)
#endif
return 0;
}
 +
 +int mmc_get_env_dev(void)
 +{
 +  return get_boot_mmc_dev();
 +}
 diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
 index 20038d4197..2e982e1b53 100644
 --- a/configs/odroid-xu3_defconfig
 +++ b/configs/odroid-xu3_defconfig
 @@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
CONFIG_SILENT_CONSOLE=y
CONFIG_CONSOLE_MUX=y
CONFIG_MISC_INIT_R=y
 +CONFIG_BOARD_LATE_INIT=y
>>> Is it a related change?
>> Yes, it is needed to enable the code added to board_late_init() function.
> I mean, is your changes should located to board_late_init?

Setting mmcbootdev env is being done in board_late_init() (see the diff 
a few lines above), so to make it working, one has to enable 
CONFIG_BOARD_LATE_INIT.

# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_TYPES=y
 diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
 index be914e4caf..e4392e477e 100644
 --- a/configs/odroid_defconfig
 +++ b/configs/odroid_defconfig
 @@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_MISC_INIT_R=y
 +CONFIG_BOARD_LATE_INIT=y
CONFIG_BOARD_TYPES=y
CONFIG_SYS_PROMPT="Odroid # "
# CONFIG_CMD_XIMG is not set

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins

[Minkyu Kang]

Hi!

On 23/01/2020 16:20, Marek Szyprowski wrote:
> Hi Minkyu,
> 
> On 23.01.2020 08:09, Minkyu Kang wrote:
>> On 17/01/2020 22:02, Marek Szyprowski wrote:
>>> XOM pins provide information for iROM bootloader about the boot device.
>>> Those pins are mapped to lower bits of OP_MODE register (0x1008),
>>> which is common for all Exynos SoC variants. Set the default MMC device id
>>> to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
>>> the eMMC).
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> ---
>>> v2:
>>> - store mmc boot device to ${mmcbootdev} env
>>> - print information about boot mmc device
>>> ---
>>>   arch/arm/mach-exynos/include/mach/cpu.h |  1 +
>>>   board/samsung/common/board.c| 28 +
>>>   configs/odroid-xu3_defconfig|  1 +
>>>   configs/odroid_defconfig|  1 +
>>>   4 files changed, 31 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-exynos/include/mach/cpu.h 
>>> b/arch/arm/mach-exynos/include/mach/cpu.h
>>> index 766edeeb29..fb5fdaf3ba 100644
>>> --- a/arch/arm/mach-exynos/include/mach/cpu.h
>>> +++ b/arch/arm/mach-exynos/include/mach/cpu.h
>>> @@ -17,6 +17,7 @@
>>>   
>>>   #define EXYNOS4_GPIO_PART3_BASE   0x0386
>>>   #define EXYNOS4_PRO_ID0x1000
>>> +#define EXYNOS4_OP_MODE0x1008
>>>   #define EXYNOS4_SYSREG_BASE   0x1001
>>>   #define EXYNOS4_POWER_BASE0x1002
>>>   #define EXYNOS4_SWRESET   0x10020400
>>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>>> index ee2fc7971e..cb94ced54e 100644
>>> --- a/board/samsung/common/board.c
>>> +++ b/board/samsung/common/board.c
>>> @@ -24,6 +24,8 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> @@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
>>> return 0;
>>>   }
>>>   
>>> +/**
>>> + * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
>>> + */
>>> +static int get_boot_mmc_dev(void)
>>> +{
>>> +   u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
>>> +
>>> +   if (mode == 0x04)
>>> +   return 2; /* MMC2: SD */
>>> +
>>> +   /* MMC0: eMMC or unknown */
>>> +   return 0;
>>> +}
>>> +
>>>   #if defined CONFIG_EXYNOS_TMU
>>>   /* Boot Time Thermal Analysis for SoC temperature threshold breach */
>>>   static void boot_temp_check(void)
>>> @@ -280,6 +296,8 @@ int board_late_init(void)
>>>   {
>>> struct udevice *dev;
>>> int ret;
>>> +   int mmcbootdev = get_boot_mmc_dev();
>>> +   char mmcbootdev_str[16];
>>>   
>>> stdio_print_current_devices();
>>> ret = uclass_first_device_err(UCLASS_CROS_EC, );
>>> @@ -292,6 +310,11 @@ int board_late_init(void)
>>> panic("Cannot init cros-ec device");
>>> return -1;
>>> }
>>> +
>>> +   printf("Boot device: MMC(%u)\n", mmcbootdev);
>>> +   sprintf(mmcbootdev_str, "%u", mmcbootdev);
>>> +   env_set("mmcbootdev", mmcbootdev_str);
>>> +
>>> return 0;
>>>   }
>>>   #endif
>>> @@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type 
>>> init)
>>>   #endif
>>> return 0;
>>>   }
>>> +
>>> +int mmc_get_env_dev(void)
>>> +{
>>> +   return get_boot_mmc_dev();
>>> +}
>>> diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
>>> index 20038d4197..2e982e1b53 100644
>>> --- a/configs/odroid-xu3_defconfig
>>> +++ b/configs/odroid-xu3_defconfig
>>> @@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
>>>   CONFIG_SILENT_CONSOLE=y
>>>   CONFIG_CONSOLE_MUX=y
>>>   CONFIG_MISC_INIT_R=y
>>> +CONFIG_BOARD_LATE_INIT=y
>> Is it a related change?
> 
> Yes, it is needed to enable the code added to board_late_init() function.

I mean, is your changes should located to board_late_init?

> 
>>>   # CONFIG_DISPLAY_BOARDINFO is not set
>>>   CONFIG_DISPLAY_BOARDINFO_LATE=y
>>>   CONFIG_BOARD_TYPES=y
>>> diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
>>> index be914e4caf..e4392e477e 100644
>>> --- a/configs/odroid_defconfig
>>> +++ b/configs/odroid_defconfig
>>> @@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
>>>   CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>>   CONFIG_SYS_CONSOLE_INFO_QUIET=y
>>>   CONFIG_MISC_INIT_R=y
>>> +CONFIG_BOARD_LATE_INIT=y
>>>   CONFIG_BOARD_TYPES=y
>>>   CONFIG_SYS_PROMPT="Odroid # "
>>>   # CONFIG_CMD_XIMG is not set
> 
> Best regards
> 

Thanks,
Minkyu Kang.

Re: [PATCH v3 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Baruch Siach]

Hi Joel,

On Wed, Jan 22, 2020 at 07:28:51PM +, Joel Johnson wrote:
> On January 22, 2020 10:32:58 AM UTC, Baruch Siach  wrote:
> >On Wed, Jan 22 2020, Joel Johnson wrote:
> >> On 2020-01-21 10:49, Baruch Siach wrote:
> >>> On Tue, Jan 21, 2020 at 10:32:17AM -0700, Joel Johnson wrote:
>  Add a unique entry for ClearFog Base variant, reflected in the
> >board
>  name and adjusted SerDes topology.
> 
>  Signed-off-by: Joel Johnson 
> 
>  ---
> 
>  v2 changes:
>    - reworked based on Baruch's run-time TLV EEPROM detection series
>  v3 changes:
>    - rebased on mvebu merged run-time TLV EEPROM detection series
>    - minor update to help test regarding runtime detection failures
> 
>  ---
>   arch/arm/mach-mvebu/Kconfig|  2 ++
>   board/solidrun/clearfog/Kconfig| 18 ++
>   board/solidrun/clearfog/clearfog.c | 12 
>   3 files changed, 32 insertions(+)
>   create mode 100644 board/solidrun/clearfog/Kconfig
> 
>  diff --git a/arch/arm/mach-mvebu/Kconfig
> >b/arch/arm/mach-mvebu/Kconfig
>  index bc5eaa5a76..161dee937f 100644
>  --- a/arch/arm/mach-mvebu/Kconfig
>  +++ b/arch/arm/mach-mvebu/Kconfig
>  @@ -280,4 +280,6 @@ config SECURED_MODE_CSK_INDEX
>   default 0
>   depends on SECURED_MODE_IMAGE
> 
>  +source "board/solidrun/clearfog/Kconfig"
>  +
>   endif
>  diff --git a/board/solidrun/clearfog/Kconfig
>  b/board/solidrun/clearfog/Kconfig
>  new file mode 100644
>  index 00..936d5918f8
>  --- /dev/null
>  +++ b/board/solidrun/clearfog/Kconfig
>  @@ -0,0 +1,18 @@
>  +menu "ClearFog configuration"
>  +depends on TARGET_CLEARFOG
>  +
>  +config TARGET_CLEARFOG_BASE
>  +bool "Use ClearFog Base static configuration"
>  +help
>  +  Use the ClearFog Base as the static configuration instead of
> >the
>  +  default which uses the ClearFog Pro.
>  +
>  +  Runtime board detection is always attempted and used if
>  available. The
>  +  static configuration is used as a fallback in cases where
> >runtime
>  +  detection is disabled, is not available in hardware, or
> >otherwise
>  fails.
>  +
>  +  Only newer revisions of the ClearFog product line support
> >runtime
>  +  detection via additional EEPROM hardware. This option enables
>  selecting
>  +  the Base variant for older hardware revisions.
>  +
>  +endmenu
>  diff --git a/board/solidrun/clearfog/clearfog.c
>  b/board/solidrun/clearfog/clearfog.c
>  index e268ef55a2..e77b9465d4 100644
>  --- a/board/solidrun/clearfog/clearfog.c
>  +++ b/board/solidrun/clearfog/clearfog.c
>  @@ -47,7 +47,11 @@ static struct serdes_map board_serdes_map[] = {
>   {SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>   {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>   {USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>  +#if defined (CONFIG_TARGET_CLEARFOG_BASE)
>  +{USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>  +#else
>   {PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>  +#endif
> >>>
> >>> I'd prefer run-time test instead of '#ifdefs' that IMO make the code
> >harder
> >>> to
> >>> read. Something like this (build tested only):
> >>>
> >>> diff --git a/board/solidrun/clearfog/clearfog.c
> >>> b/board/solidrun/clearfog/clearfog.c
> >>> index e268ef55a2a0..202c60cb7841 100644
> >>> --- a/board/solidrun/clearfog/clearfog.c
> >>> +++ b/board/solidrun/clearfog/clearfog.c
> >>> @@ -55,7 +55,8 @@ int hws_board_topology_load(struct serdes_map
> >>> **serdes_map_array, u8 *count)
> >>>  {
> >>>   cf_read_tlv_data();
> >>>
> >>> - if (sr_product_is(_tlv_data, "Clearfog GTR")) {
> >>> + if (sr_product_is(_tlv_data, "Clearfog GTR") ||
> >>> + CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE)) {
> >>>   board_serdes_map[0].serdes_type = PEX0;
> >>>   board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
> >>>   board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
> >>> @@ -172,6 +173,9 @@ int checkboard(void)
> >>>  {
> >>>   char *board = "ClearFog";
> >>>
> >>> + if (CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
> >>> + board = "ClearFog Base";
> >>> +
> >>>   cf_read_tlv_data();
> >>>   if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
> >>>   board = cf_tlv_data.tlv_product_name[0];
> >>> @@ -194,7 +198,8 @@ int board_late_init(void)
> >>>  {
> >>>   cf_read_tlv_data();
> >>>
> >>> - if (sr_product_is(_tlv_data, "Clearfog Base"))
> >>> + if (sr_product_is(_tlv_data, "Clearfog Base") ||
> >>> + CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
> >>>   env_set("fdtfile", 

Re: [PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins

[Marek Szyprowski]

Hi Minkyu,

On 23.01.2020 08:09, Minkyu Kang wrote:
> On 17/01/2020 22:02, Marek Szyprowski wrote:
>> XOM pins provide information for iROM bootloader about the boot device.
>> Those pins are mapped to lower bits of OP_MODE register (0x1008),
>> which is common for all Exynos SoC variants. Set the default MMC device id
>> to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
>> the eMMC).
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
>> v2:
>> - store mmc boot device to ${mmcbootdev} env
>> - print information about boot mmc device
>> ---
>>   arch/arm/mach-exynos/include/mach/cpu.h |  1 +
>>   board/samsung/common/board.c| 28 +
>>   configs/odroid-xu3_defconfig|  1 +
>>   configs/odroid_defconfig|  1 +
>>   4 files changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/mach-exynos/include/mach/cpu.h 
>> b/arch/arm/mach-exynos/include/mach/cpu.h
>> index 766edeeb29..fb5fdaf3ba 100644
>> --- a/arch/arm/mach-exynos/include/mach/cpu.h
>> +++ b/arch/arm/mach-exynos/include/mach/cpu.h
>> @@ -17,6 +17,7 @@
>>   
>>   #define EXYNOS4_GPIO_PART3_BASE0x0386
>>   #define EXYNOS4_PRO_ID 0x1000
>> +#define EXYNOS4_OP_MODE 0x1008
>>   #define EXYNOS4_SYSREG_BASE0x1001
>>   #define EXYNOS4_POWER_BASE 0x1002
>>   #define EXYNOS4_SWRESET0x10020400
>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>> index ee2fc7971e..cb94ced54e 100644
>> --- a/board/samsung/common/board.c
>> +++ b/board/samsung/common/board.c
>> @@ -24,6 +24,8 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
>>  return 0;
>>   }
>>   
>> +/**
>> + * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
>> + */
>> +static int get_boot_mmc_dev(void)
>> +{
>> +u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
>> +
>> +if (mode == 0x04)
>> +return 2; /* MMC2: SD */
>> +
>> +/* MMC0: eMMC or unknown */
>> +return 0;
>> +}
>> +
>>   #if defined CONFIG_EXYNOS_TMU
>>   /* Boot Time Thermal Analysis for SoC temperature threshold breach */
>>   static void boot_temp_check(void)
>> @@ -280,6 +296,8 @@ int board_late_init(void)
>>   {
>>  struct udevice *dev;
>>  int ret;
>> +int mmcbootdev = get_boot_mmc_dev();
>> +char mmcbootdev_str[16];
>>   
>>  stdio_print_current_devices();
>>  ret = uclass_first_device_err(UCLASS_CROS_EC, );
>> @@ -292,6 +310,11 @@ int board_late_init(void)
>>  panic("Cannot init cros-ec device");
>>  return -1;
>>  }
>> +
>> +printf("Boot device: MMC(%u)\n", mmcbootdev);
>> +sprintf(mmcbootdev_str, "%u", mmcbootdev);
>> +env_set("mmcbootdev", mmcbootdev_str);
>> +
>>  return 0;
>>   }
>>   #endif
>> @@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type init)
>>   #endif
>>  return 0;
>>   }
>> +
>> +int mmc_get_env_dev(void)
>> +{
>> +return get_boot_mmc_dev();
>> +}
>> diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
>> index 20038d4197..2e982e1b53 100644
>> --- a/configs/odroid-xu3_defconfig
>> +++ b/configs/odroid-xu3_defconfig
>> @@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
>>   CONFIG_SILENT_CONSOLE=y
>>   CONFIG_CONSOLE_MUX=y
>>   CONFIG_MISC_INIT_R=y
>> +CONFIG_BOARD_LATE_INIT=y
> Is it a related change?

Yes, it is needed to enable the code added to board_late_init() function.

>>   # CONFIG_DISPLAY_BOARDINFO is not set
>>   CONFIG_DISPLAY_BOARDINFO_LATE=y
>>   CONFIG_BOARD_TYPES=y
>> diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
>> index be914e4caf..e4392e477e 100644
>> --- a/configs/odroid_defconfig
>> +++ b/configs/odroid_defconfig
>> @@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
>>   CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>   CONFIG_SYS_CONSOLE_INFO_QUIET=y
>>   CONFIG_MISC_INIT_R=y
>> +CONFIG_BOARD_LATE_INIT=y
>>   CONFIG_BOARD_TYPES=y
>>   CONFIG_SYS_PROMPT="Odroid # "
>>   # CONFIG_CMD_XIMG is not set

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

RE: [EXT] Re: [Patch v4] net: pfe_eth: Use spi_flash_read API to access flash memory

[Kuldeep Singh]

Hi Joe,

> -Original Message-
> From: Schrempf Frieder 
> Sent: Monday, January 13, 2020 3:11 PM
> To: Kuldeep Singh ; u-boot@lists.denx.de
> Cc: Joe Hershberger ; Thomas Hebb
> ; Patrick Delaunay ;
> Priyanka Jain 
> Subject: [EXT] Re: [Patch v4] net: pfe_eth: Use spi_flash_read API to access
> flash memory
> 
> Caution: EXT Email
> 
> On 13.01.20 10:23, Kuldeep Singh wrote:
> > Current PFE firmware access spi-nor memory directly. New spi-mem
> > framework does not support direct memory access. So, let's use
> > spi_flash_read API to access memory instead of directly using it.
> >
> > Signed-off-by: Kuldeep Singh 
> 
> Reviewed-by: Frieder Schrempf 
> 

ping. this already has reviewed-by tag.
Please let me know if there's any dependency on my side.

Thanks
Kuldeep

> > ---
> > v4:
> > -Return -ENODEV if flash probe fails
> > v3:
> > -Replace ret with 0 if flash probe fails
> > v2:
> > -Add return error code
> > -Changes in displayed error log
> >
> >   drivers/net/pfe_eth/pfe_firmware.c | 45
> +-
> >   include/configs/ls1012a_common.h   |  5 -
> >   2 files changed, 48 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/pfe_eth/pfe_firmware.c
> > b/drivers/net/pfe_eth/pfe_firmware.c
> > index e4563f1..27ae8ae 100644
> > --- a/drivers/net/pfe_eth/pfe_firmware.c
> > +++ b/drivers/net/pfe_eth/pfe_firmware.c
> > @@ -12,13 +12,14 @@
> >
> >   #include 
> >   #include 
> > +#include 
> >   #ifdef CONFIG_CHAIN_OF_TRUST
> >   #include 
> >   #endif
> >
> >   #define PFE_FIRMWARE_FIT_CNF_NAME   "config@1"
> >
> > -static const void *pfe_fit_addr = (void *)CONFIG_SYS_LS_PFE_FW_ADDR;
> > +static const void *pfe_fit_addr;
> >
> >   /*
> >* PFE elf firmware loader.
> > @@ -159,6 +160,44 @@ static int pfe_fit_check(void)
> >   return ret;
> >   }
> >
> > +int pfe_spi_flash_init(void)
> > +{
> > + struct spi_flash *pfe_flash;
> > + int ret = 0;
> > + void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
> > +
> > +#ifdef CONFIG_DM_SPI_FLASH
> > + struct udevice *new;
> > +
> > + /* speed and mode will be read from DT */
> > + ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS,
> > +  CONFIG_ENV_SPI_CS, 0, 0, );
> > +
> > + pfe_flash = dev_get_uclass_priv(new); #else
> > + pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
> > + CONFIG_ENV_SPI_CS,
> > + CONFIG_ENV_SPI_MAX_HZ,
> > + CONFIG_ENV_SPI_MODE); #endif
> > + if (!pfe_flash) {
> > + printf("SF: probe for pfe failed\n");
> > + return -ENODEV;
> > + }
> > +
> > + ret = spi_flash_read(pfe_flash,
> > +  CONFIG_SYS_LS_PFE_FW_ADDR,
> > +  CONFIG_SYS_QE_FMAN_FW_LENGTH,
> > +  addr);
> > + if (ret)
> > + printf("SF: read for pfe failed\n");
> > +
> > + pfe_fit_addr = addr;
> > + spi_flash_free(pfe_flash);
> > +
> > + return ret;
> > +}
> > +
> >   /*
> >* PFE firmware initialization.
> >* Loads different firmware files from FIT image.
> > @@ -183,6 +222,10 @@ int pfe_firmware_init(void)
> >   int ret = 0;
> >   int fw_count;
> >
> > + ret = pfe_spi_flash_init();
> > + if (ret)
> > + goto err;
> > +
> >   ret = pfe_fit_check();
> >   if (ret)
> >   goto err;
> > diff --git a/include/configs/ls1012a_common.h
> > b/include/configs/ls1012a_common.h
> > index 2579e2f..cbc5bff 100644
> > --- a/include/configs/ls1012a_common.h
> > +++ b/include/configs/ls1012a_common.h
> > @@ -36,9 +36,12 @@
> >   /* Size of malloc() pool */
> >   #define CONFIG_SYS_MALLOC_LEN   (CONFIG_ENV_SIZE + 128 *
> 1024)
> >
> > +/* PFE */
> > +#define CONFIG_SYS_FMAN_FW_ADDR  0x400d
> > +#define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x1
> > +
> >   /*SPI device */
> >   #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT)
> > -#define CONFIG_SYS_FMAN_FW_ADDR  0x400d
> >   #define CONFIG_SPI_FLASH_SPANSION
> >   #define CONFIG_FSL_SPI_INTERFACE
> >   #define CONFIG_SF_DATAFLASH
> >

Re: [PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins

[Minkyu Kang]

Hi,

On 17/01/2020 22:02, Marek Szyprowski wrote:
> XOM pins provide information for iROM bootloader about the boot device.
> Those pins are mapped to lower bits of OP_MODE register (0x1008),
> which is common for all Exynos SoC variants. Set the default MMC device id
> to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
> the eMMC).
> 
> Signed-off-by: Marek Szyprowski 
> ---
> v2:
> - store mmc boot device to ${mmcbootdev} env
> - print information about boot mmc device
> ---
>  arch/arm/mach-exynos/include/mach/cpu.h |  1 +
>  board/samsung/common/board.c| 28 +
>  configs/odroid-xu3_defconfig|  1 +
>  configs/odroid_defconfig|  1 +
>  4 files changed, 31 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/include/mach/cpu.h 
> b/arch/arm/mach-exynos/include/mach/cpu.h
> index 766edeeb29..fb5fdaf3ba 100644
> --- a/arch/arm/mach-exynos/include/mach/cpu.h
> +++ b/arch/arm/mach-exynos/include/mach/cpu.h
> @@ -17,6 +17,7 @@
>  
>  #define EXYNOS4_GPIO_PART3_BASE  0x0386
>  #define EXYNOS4_PRO_ID   0x1000
> +#define EXYNOS4_OP_MODE  0x1008
>  #define EXYNOS4_SYSREG_BASE  0x1001
>  #define EXYNOS4_POWER_BASE   0x1002
>  #define EXYNOS4_SWRESET  0x10020400
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index ee2fc7971e..cb94ced54e 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -24,6 +24,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
>   return 0;
>  }
>  
> +/**
> + * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
> + */
> +static int get_boot_mmc_dev(void)
> +{
> + u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
> +
> + if (mode == 0x04)
> + return 2; /* MMC2: SD */
> +
> + /* MMC0: eMMC or unknown */
> + return 0;
> +}
> +
>  #if defined CONFIG_EXYNOS_TMU
>  /* Boot Time Thermal Analysis for SoC temperature threshold breach */
>  static void boot_temp_check(void)
> @@ -280,6 +296,8 @@ int board_late_init(void)
>  {
>   struct udevice *dev;
>   int ret;
> + int mmcbootdev = get_boot_mmc_dev();
> + char mmcbootdev_str[16];
>  
>   stdio_print_current_devices();
>   ret = uclass_first_device_err(UCLASS_CROS_EC, );
> @@ -292,6 +310,11 @@ int board_late_init(void)
>   panic("Cannot init cros-ec device");
>   return -1;
>   }
> +
> + printf("Boot device: MMC(%u)\n", mmcbootdev);
> + sprintf(mmcbootdev_str, "%u", mmcbootdev);
> + env_set("mmcbootdev", mmcbootdev_str);
> +
>   return 0;
>  }
>  #endif
> @@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type init)
>  #endif
>   return 0;
>  }
> +
> +int mmc_get_env_dev(void)
> +{
> + return get_boot_mmc_dev();
> +}
> diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
> index 20038d4197..2e982e1b53 100644
> --- a/configs/odroid-xu3_defconfig
> +++ b/configs/odroid-xu3_defconfig
> @@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
>  CONFIG_SILENT_CONSOLE=y
>  CONFIG_CONSOLE_MUX=y
>  CONFIG_MISC_INIT_R=y
> +CONFIG_BOARD_LATE_INIT=y

Is it a related change?

>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_BOARD_TYPES=y
> diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
> index be914e4caf..e4392e477e 100644
> --- a/configs/odroid_defconfig
> +++ b/configs/odroid_defconfig
> @@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
>  CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  CONFIG_MISC_INIT_R=y
> +CONFIG_BOARD_LATE_INIT=y
>  CONFIG_BOARD_TYPES=y
>  CONFIG_SYS_PROMPT="Odroid # "
>  # CONFIG_CMD_XIMG is not set
> 

Thanks,
Minkyu Kang.

Re: [PATCH v3 05/10] arm: mvebu: clearfog: Add SATA mode flags

[Baruch Siach]

Hi Joel,

On Tue, Jan 21, 2020 at 10:32:19AM -0700, Joel Johnson wrote:
> The mPCIe slots on ClearFog Pro and ClearFog Base may be alternately
> configured for SATA usage.
> 
> Signed-off-by: Joel Johnson 
> 
> ---
> 
> v2 changes:
>   - fixed help indentation
> v3 changes:
>   - none
> 
> ---
>  board/solidrun/clearfog/Kconfig| 17 +
>  board/solidrun/clearfog/clearfog.c |  6 ++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index 936d5918f8..4e189b13e0 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -15,4 +15,21 @@ config TARGET_CLEARFOG_BASE
> detection via additional EEPROM hardware. This option enables 
> selecting
> the Base variant for older hardware revisions.
>  
> +config CLEARFOG_CON3_SATA
> + bool "Use CON3 slot in SATA mode"
> + help
> +   Use the CON3 port with SATA protocol instead of the default PCIe.
> +   The ClearFog port allows usage of either mSATA or miniPCIe
> +   modules, but the desired protocol must be configured at build
> +   time since it affects the SerDes topology layout.
> +
> +config CLEARFOG_CON2_SATA
> + bool "Use CON2 slot in SATA mode"
> + depends on !TARGET_CLEARFOG_BASE
> + help
> +   Use the CON2 port with SATA protocol instead of the default PCIe.
> +   The ClearFog port allows usage of either mSATA or miniPCIe
> +   modules, but the desired protocol must be configured at build
> +   time since it affects the SerDes topology layout.
> +
>  endmenu
> diff --git a/board/solidrun/clearfog/clearfog.c 
> b/board/solidrun/clearfog/clearfog.c
> index 086912e400..7046665d6c 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -45,10 +45,16 @@ static void cf_read_tlv_data(void)
>  static struct serdes_map board_serdes_map[] = {
>   {SATA0, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>   {SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> +#if defined (CONFIG_CLEARFOG_CON3_SATA)
> + {SATA1, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},

Have you tested mSATA with this patch?

My testing showed that swap_rx must be set for mSATA. See this pull request:

  https://github.com/SolidRun/u-boot/pull/3

To make #ifdef less annoying I would prefer something like this instead (build 
tested only):

diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index e268ef55a2a0..5bbb7906b681 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -29,6 +29,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #define BOARD_GPP_POL_LOW  0x0
 #define BOARD_GPP_POL_MID  0x0
 
+#if defined (CONFIG_CLEARFOG_CON3_SATA)
+#define SERDES2_CONFIG {SATA1, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 1, 0}
+#else
+#define SERDES2_CONFIG {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0}
+#endif
+
 static struct tlv_data cf_tlv_data;
 
 static void cf_read_tlv_data(void)
@@ -45,7 +51,7 @@ static void cf_read_tlv_data(void)
 static struct serdes_map board_serdes_map[] = {
{SATA0, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
-   {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
+   SERDES2_CONFIG,
{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},

baruch

> +#else
>   {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
> +#endif
>   {USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>  #if defined (CONFIG_TARGET_CLEARFOG_BASE)
>   {USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> +#elif defined(CONFIG_CLEARFOG_CON2_SATA)
> + {SATA2, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>  #else
>   {PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>  #endif

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[PATCH] mmc: remove unneeded forward declarations

[Masahiro Yamada]

These functions are defined before the callers.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/mmc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index b26e266c1c29..dd8e29460cef 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -24,10 +24,6 @@
 #define DEFAULT_CMD6_TIMEOUT_MS  500
 
 static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
-static int mmc_power_cycle(struct mmc *mmc);
-#if !CONFIG_IS_ENABLED(MMC_TINY)
-static int mmc_select_mode_and_width(struct mmc *mmc, uint card_caps);
-#endif
 
 #if !CONFIG_IS_ENABLED(DM_MMC)
 
-- 
2.17.1

Re: [PATCH v3 04/10] arm: mvebu: clearfog: Use Pro DT by default

[Baruch Siach]

Hi Joel,

On Tue, Jan 21, 2020 at 10:32:18AM -0700, Joel Johnson wrote:
> Switch to explicitly using the Pro variant DT, which has been
> available since Linux 4.11. Also unify the location of DT selection
> in board_late_init instead of split between detection and static
> configuration paths.
> 
> ---
> 
> v2 changes
>   - newly added in V2 series based on run-time rebasing
> v2 changes
>   - none
> 
> Signed-off-by: Joel Johnson 
> ---
>  board/solidrun/clearfog/clearfog.c | 6 --
>  include/configs/clearfog.h | 1 -
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/board/solidrun/clearfog/clearfog.c 
> b/board/solidrun/clearfog/clearfog.c
> index e77b9465d4..086912e400 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -177,7 +177,7 @@ int checkboard(void)
>  #if defined (CONFIG_TARGET_CLEARFOG_BASE)
>   char *board = "ClearFog Base";
>  #else
> - char *board = "ClearFog";
> + char *board = "ClearFog Pro";
>  #endif
>  
>   cf_read_tlv_data();
> @@ -208,9 +208,11 @@ int board_late_init(void)
>   env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
>   else if (sr_product_is(_tlv_data, "Clearfog GTR L8"))
>   env_set("fdtfile", "armada-385-clearfog-gtr-l8.dtb");
> -#if defined (CONFIG_TARGET_CLEARFOG_BASE)
>   else
> +#if defined (CONFIG_TARGET_CLEARFOG_BASE)
>env_set("fdtfile", "armada-388-clearfog-base.dtb");
> +#else
> +  env_set("fdtfile", "armada-388-clearfog-pro.dtb");

I'd prefer to keep the default here for backwards compatibility. The kernel 
also keeps armada-388-clearfog.dtb. The -pro variant only updates the 'model' 
and 'compatible' properties.

Unrelated to that here is another reason to avoid #ifdef. Syntax aware text 
editor automatic indentation might fail to see that the second env_set() is in 
the 'else' block. We can workaround that by adding braces around the block, 
but it's not nice.

baruch

>  #endif
>  
>   return 0;
> diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
> index 633187d86f..6ca0474461 100644
> --- a/include/configs/clearfog.h
> +++ b/include/configs/clearfog.h
> @@ -134,7 +134,6 @@
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>   RELOCATION_LIMITS_ENV_SETTINGS \
>   LOAD_ADDRESS_ENV_SETTINGS \
> - "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
>   "console=ttyS0,115200\0" \
>   BOOTENV

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[PATCH v4] board: fsl: lx2160a: Add support to reset to eMMC

[Meenakshi Aggarwal]

Add support of "qixis_reset emmc" command for lx2160a based platforms

Signed-off-by: Meenakshi Aggarwal 

---
Changes:

v2:
- update in commit message
- using set_rcw_src() in place of QIXIS_WRITE()

v3:
- update in commit message

v4:
-incorporated review comments
---
 board/freescale/common/qixis.c| 4 
 board/freescale/lx2160a/lx2160a.c | 2 ++
 include/configs/lx2160aqds.h  | 2 ++
 include/configs/lx2160ardb.h  | 2 ++
 4 files changed, 10 insertions(+)

diff --git a/board/freescale/common/qixis.c b/board/freescale/common/qixis.c
index 716c93b..dd1ee90 100644
--- a/board/freescale/common/qixis.c
+++ b/board/freescale/common/qixis.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2011 Freescale Semiconductor
+ * Copyright 2020 NXP
  * Author: Shengzhou Liu 
  *
  * This file provides support for the QIXIS of some Freescale reference boards.
@@ -287,7 +288,9 @@ static int qixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const ar
 #ifdef QIXIS_LBMAP_EMMC
QIXIS_WRITE(rst_ctl, 0x30);
QIXIS_WRITE(rcfg_ctl, 0);
+#ifndef NON_EXTENDED_DUTCFG
set_lbmap(QIXIS_LBMAP_EMMC);
+#endif
set_rcw_src(QIXIS_RCW_SRC_EMMC);
QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_IDLE);
QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_START);
@@ -365,6 +368,7 @@ U_BOOT_CMD(
"qixis watchdog  - set the watchdog period\n"
"   period: 1s 2s 4s 8s 16s 32s 1min 2min 4min 8min\n"
"qixis_reset dump - display the QIXIS registers\n"
+   "qixis_reset emmc - reset to emmc\n"
"qixis_reset switch - display switch\n"
);
 #endif
diff --git a/board/freescale/lx2160a/lx2160a.c 
b/board/freescale/lx2160a/lx2160a.c
index dd3cd45..79abcd8 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -325,6 +325,8 @@ int checkboard(void)
 
if (src == BOOT_SOURCE_SD_MMC) {
puts("SD\n");
+   } else if (src == BOOT_SOURCE_SD_MMC2) {
+   puts("eMMC\n");
} else {
sw = QIXIS_READ(brdcfg[0]);
sw = (sw >> QIXIS_XMAP_SHIFT) & QIXIS_XMAP_MASK;
diff --git a/include/configs/lx2160aqds.h b/include/configs/lx2160aqds.h
index f523b37..56a50d3 100644
--- a/include/configs/lx2160aqds.h
+++ b/include/configs/lx2160aqds.h
@@ -22,7 +22,9 @@
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE  0x08
 #define QIXIS_LBMAP_MASK   0x0f
 #define QIXIS_LBMAP_SD
+#define QIXIS_LBMAP_EMMC
 #define QIXIS_RCW_SRC_SD   0x08
+#define QIXIS_RCW_SRC_EMMC 0x09
 #define NON_EXTENDED_DUTCFG
 #define QIXIS_SDID_MASK0x07
 #define QIXIS_ESDHC_NO_ADAPTER 0x7
diff --git a/include/configs/lx2160ardb.h b/include/configs/lx2160ardb.h
index 6ff1c24..5b530f0 100644
--- a/include/configs/lx2160ardb.h
+++ b/include/configs/lx2160ardb.h
@@ -22,7 +22,9 @@
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE  0x08
 #define QIXIS_LBMAP_MASK   0x0f
 #define QIXIS_LBMAP_SD
+#define QIXIS_LBMAP_EMMC
 #define QIXIS_RCW_SRC_SD   0x08
+#define QIXIS_RCW_SRC_EMMC 0x09
 #define NON_EXTENDED_DUTCFG
 
 /* VID */
-- 
1.9.1

RE: [PATCH v3] board: fsl: lx2160a: Add support to reset to eMMC

[Meenakshi Aggarwal]

> -Original Message-
> From: Priyanka Jain (OSS) 
> Sent: Wednesday, January 22, 2020 4:34 PM
> To: Meenakshi Aggarwal ; u-
> b...@lists.denx.de
> Subject: RE: [PATCH v3] board: fsl: lx2160a: Add support to reset to eMMC
> 
> 
> 
> >-Original Message-
> >From: U-Boot  On Behalf Of Meenakshi
> >Aggarwal
> >Sent: Thursday, January 16, 2020 9:13 PM
> >To: u-boot@lists.denx.de; Priyanka Jain 
> >Subject: [PATCH v3] board: fsl: lx2160a: Add support to reset to eMMC
> >
> >Add support of "qixis_reset emmc" command for lx2160a based platforms
> >
> >Signed-off-by: Meenakshi Aggarwal 
> >
> >---
> >Changes:
> >
> > v2:
> > - Update in commit message
> > - using set_rcw_src() in place of QIXIS_WRITE()
> >
> > v3:
> > - update in commit message
> Whenever you send a next version , please mark previous version as superseded.
> It is sometimes difficult to isolate specially if subject is different.

Ok, will take care of same in future.

> >
> >Signed-off-by: Meenakshi Aggarwal 
> >---
> > board/freescale/common/qixis.c| 6 ++
> > board/freescale/lx2160a/lx2160a.c | 2 ++
> > include/configs/lx2160aqds.h  | 2 ++
> > include/configs/lx2160ardb.h  | 2 ++
> > 4 files changed, 12 insertions(+)
> >
> >diff --git a/board/freescale/common/qixis.c
> >b/board/freescale/common/qixis.c index 716c93b..ab229b9 100644
> >--- a/board/freescale/common/qixis.c
> >+++ b/board/freescale/common/qixis.c
> >@@ -1,6 +1,7 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> >  * Copyright 2011 Freescale Semiconductor
> >+ * Copyright 2020 NXP
> >  * Author: Shengzhou Liu 
> >  *
> >  * This file provides support for the QIXIS of some Freescale reference 
> > boards.
> >@@ -287,8 +288,12 @@ static int qixis_reset_cmd(cmd_tbl_t *cmdtp, int
> >flag, int argc, char * const ar  #ifdef QIXIS_LBMAP_EMMC
> > QIXIS_WRITE(rst_ctl, 0x30);
> > QIXIS_WRITE(rcfg_ctl, 0);
> >+#ifdef NON_EXTENDED_DUTCFG
> >+set_rcw_src(QIXIS_RCW_SRC_EMMC);
> >+#else
> > set_lbmap(QIXIS_LBMAP_EMMC);
> It would be better to just enclosed above in #ifndef

Ok

> > set_rcw_src(QIXIS_RCW_SRC_EMMC);
> >+#endif
> > QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_IDLE);
> > QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_START);
> #else @@
> >-365,6 +370,7 @@ U_BOOT_CMD(
> > "qixis watchdog  - set the watchdog period\n"
> > "   period: 1s 2s 4s 8s 16s 32s 1min 2min 4min 8min\n"
> > "qixis_reset dump - display the QIXIS registers\n"
> >+"qixis_reset emmc - reset to emmc\n"
> > "qixis_reset switch - display switch\n"
> > );
> > #endif
> >diff --git a/board/freescale/lx2160a/lx2160a.c
> >b/board/freescale/lx2160a/lx2160a.c
> >index dd3cd45..79abcd8 100644
> >--- a/board/freescale/lx2160a/lx2160a.c
> >+++ b/board/freescale/lx2160a/lx2160a.c
> >@@ -325,6 +325,8 @@ int checkboard(void)
> >
> > if (src == BOOT_SOURCE_SD_MMC) {
> > puts("SD\n");
> >+} else if (src == BOOT_SOURCE_SD_MMC2) {
> >+puts("eMMC\n");
> > } else {
> > sw = QIXIS_READ(brdcfg[0]);
> > sw = (sw >> QIXIS_XMAP_SHIFT) & QIXIS_XMAP_MASK; diff --git
> >a/include/configs/lx2160aqds.h b/include/configs/lx2160aqds.h index
> >f523b37..56a50d3 100644
> >--- a/include/configs/lx2160aqds.h
> >+++ b/include/configs/lx2160aqds.h
> >@@ -22,7 +22,9 @@
> > #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE   0x08
> > #define QIXIS_LBMAP_MASK0x0f
> > #define QIXIS_LBMAP_SD
> >+#define QIXIS_LBMAP_EMMC
> > #define QIXIS_RCW_SRC_SD0x08
> >+#define QIXIS_RCW_SRC_EMMC 0x09
> > #define NON_EXTENDED_DUTCFG
> > #define QIXIS_SDID_MASK 0x07
> > #define QIXIS_ESDHC_NO_ADAPTER  0x7
> >diff --git a/include/configs/lx2160ardb.h
> >b/include/configs/lx2160ardb.h index
> >6ff1c24..5b530f0 100644
> >--- a/include/configs/lx2160ardb.h
> >+++ b/include/configs/lx2160ardb.h
> >@@ -22,7 +22,9 @@
> > #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE   0x08
> > #define QIXIS_LBMAP_MASK0x0f
> > #define QIXIS_LBMAP_SD
> >+#define QIXIS_LBMAP_EMMC
> > #define QIXIS_RCW_SRC_SD   0x08
> >+#define QIXIS_RCW_SRC_EMMC 0x09
> > #define NON_EXTENDED_DUTCFG
> >
> > /* VID */
> >--
> >1.9.1
> -Priyanka

RE: [EXT] Issue with saveenv() and the QSPI NOR memory MICRON MT25QU01GBBB

[Kuldeep Singh]

Hi Florian,

> -Original Message-
> From: U-Boot  On Behalf Of
> florian.man...@siemens.com
> Sent: Wednesday, January 22, 2020 7:13 PM
> To: u-boot@lists.denx.de
> Cc: daniel.schert...@siemens.com
> Subject: [EXT] Issue with saveenv() and the QSPI NOR memory MICRON
> MT25QU01GBBB
> 
> Caution: EXT Email
> 
> Hello U-Boot team,
> 
> 
> 
> I am Florian, working at Siemens in Germany.
> 
> I am in charge of bringing up a custom board based on the processor NXP
> QorIQ LS1043a.
> 
> 
> 
> So far, I have been able to bring U-Boot on the board without too much
> troubles.
> 
> However I can not get the command 'saveenv' to work. Our environment
> variables are stored in the QSPI NOR memory that is also used as boot
> memory.
> 
> 
> 
> The 'saveenv' command always ends up in a
> 

Please apply patch series [1] on top of denx tree.
Please let me know in case of any failure.

Thanks
Kuldeep
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=152743
Detail of this series:
https://patchwork.ozlabs.org/patch/1221983/
https://patchwork.ozlabs.org/patch/1221977/
https://patchwork.ozlabs.org/patch/1221979/
https://patchwork.ozlabs.org/patch/1221978/
https://patchwork.ozlabs.org/patch/1221980/
https://patchwork.ozlabs.org/patch/1221981/
https://patchwork.ozlabs.org/patch/1221982/

> "
> 
> => saveenv
> 
> Saving Environment to SPI Flash... Erasing SPI flash...flash operation timed 
> out
> 
> Failed (-110)
> 
> "
> 
> 
> 
> Few more information:
> 
> - No issue with a Lauterbach debugger
> 
> - I noticed that the NOR memory at offset address 0 get erased during the
> operation. The normal offset of the env variable is normally 0x90.
> 
> - The memory used is the 'MT25QU01GBBB' from MICRON (Device ID
> 0x20bb21). I can provide the datasheet.
> 
> - the NOR memory is correctly discovered, 'sf probe => SF: Detected n25q00a
> with page size 256 Bytes, erase size 64 KiB, total 128 MiB'
> 
> - I have tried to activate the debug logs but they didn't bring any 
> interesting
> information.
> 
> - current version :
> 
> "
> 
> => version
> 
> U-Boot 2019.10-00062-gc71ef945eb-dirty (Jan 22 2020 - 14:14:26 +0100)
> 
> 
> 
> aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
> 
> GNU ld (GNU Binutils for Debian) 2.28
> 
> "
> 
> 
> 
> Can you provide support to fix this issue ?
> 
> Of course, I can provide more info/logs.
> 
> 
> 
> Regards,
> 
> Mit freundlichen Grüßen
> Florian Manoël
> 
> Siemens AG
> Digital Industries
> Process Automation
> Software House Khe
> DI PA CI R 2
> Östliche Rheinbrückenstr. 50
> 76187 Karlsruhe, Deutschland
> Tel.: +49 721 595-1433
> mailto:florian.man...@siemens.com
> https://eur01.safelinks.protection.outlook.com/?url=www.siemens.com%2Fing
> enuityforlifedata=02%7C01%7Ckuldeep.singh%40nxp.com%7C2fa80e44
> 8dc24ad8ed1308d79f411443%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C1%7C637152974174541907sdata=naUNOT%2FqfND%2B7uEMPDvzmi
> HK33QsGZZsfYUy2hNAiJw%3Dreserved=0 ction.outlook.com/?url=https%3A%2F%2Fsiemens.com%2Fingenuityforlife
> p;data=02%7C01%7Ckuldeep.singh%40nxp.com%7C2fa80e448dc24ad8ed1308
> d79f411443%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6371529
> 74174541907sdata=d41afMBGhTOC8mskURQ4vrXZR205s9TitKxjzeIqy%
> 2FQ%3Dreserved=0>
> 
> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann
> Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus
> Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Sitz der
> Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin
> Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE
> 23691322

[PATCH] Kconfig/fpgad: Add dependencies

[Olliver Schinagl]

Until the fpgad command is converted to driver model; it will depend on
some drivers to implement said features.

cmd/built-in.o: In function `do_fpga_md':
cmd/fpgad.c:73: undefined reference to `fpga_get_reg'
cmd/fpgad.c:85: undefined reference to `fpga_ptr'

Signed-off-by: Olliver Schinagl 
---
 cmd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6e1efaaf85..0925236c0c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -924,6 +924,7 @@ config CMD_FPGA_LOAD_SECURE
 
 config CMD_FPGAD
bool "fpgad - dump FPGA registers"
+   depends on HRCON || STRIDER
help
  (legacy, needs conversion to driver model)
  Provides a way to dump FPGA registers by calling the board-specific
-- 
2.20.1

Re: [PATCH v3 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Stefan Roese]

On 22.01.20 20:28, Joel Johnson wrote:




It probably makes more sense to reverse the order of ORed conditions:

if (IS_ENABLED(TARGET_CLEARFOG_BASE) ||
sr_product_is(_tlv_data, "Clearfog Base"))

IS_ENABLED() is evaluated at build time. When it is true, the compiler
drops all other 'if' branches, thus saving space. That also means that
the build time configuration overrides the EEPROM set value, which is a
Good Thing I believe.


I'll take a look and do testing and size comparison in the next day or
two.

Note that I intended (and wrote the Base target help docs accordingly)
that runtime detection, if both enabled and supported in hardware,
should be preferred to the static configuration, with static config
being only a fallback.


This sounds reasonable.


This seems to be different from what your
thought about it being good for build configuration to override
EEPROM detected values, and I'm curious as to your reasoning.

There are a few gaps here related to what you point out (e.g.
booting on a Pro with EEPROM and Base static config won't give the
expected results). Relocating the static adjustment may be fine and
help with that case as well.

I'll want to add support in such handling for the EEPROM Pro
devices but don't have one available. You seem to have them
available, can you confirm that "Clearfog Pro" would match those
devices using sr_product_is?


I currently don't have any of these boards available, so I also would
like to see some reviewed-by and even better tested-by comments from
Baruch (or someone else at SolidRun).

Thanks,
Stefan

Re: [PATCH] mmc: check the return value of mmc_select_mode_and_width()

[Jaehoon Chung]

On 1/23/20 2:31 PM, Masahiro Yamada wrote:
> Since commit 01298da31d92 ("mmc: Change mode when switching to a boot
> partition"), errors in mmc_select_mode_and_width() are ignored.
> The return value should be checked.
> 
> Fixes: 01298da31d92 ("mmc: Change mode when switching to a boot partition")
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Jaehoon Chung 

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 d43983d4a648..b26e266c1c29 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2575,7 +2575,7 @@ static int mmc_startup(struct mmc *mmc)
>   err = mmc_get_capabilities(mmc);
>   if (err)
>   return err;
> - mmc_select_mode_and_width(mmc, mmc->card_caps);
> + err = mmc_select_mode_and_width(mmc, mmc->card_caps);
>   }
>  #endif
>   if (err)
> 

Re: [RFC] Vocore2 MMC needs clock patches

[Stefan Roese]

Hi Maruo,

On 22.01.20 21:16, Mauro Condarelli wrote:

Hi Stefan,

On 1/21/20 1:08 PM, Stefan Roese wrote:

Hi Mauro,

On 21.01.20 12:27, Mauro Condarelli wrote:

Thanks Weijie,
I made the changes You suggested.
I have also seen You sent a new version of Your patches.
Since mine are based on yours I *think* I should suspend
sending my VoCore2 patches till Yours are fixed and integrated
into master.

@Stefan Roese: is this the right course of action?


I think in the current state of Weijie's patches (v3), you can resume
sending your VoCore2 support based on this latest patchset to the
list. Please don't attach a patch but send it inline next time
(git send-email) to enable review.

I will send next iteration as soon as I fix the reflash problem (see below).
  
===8<

Side Question: Stefan wrote:

Most of this can be done by using the
RAM version now (again). There is no additional RAM booting target now
any more. You can use the normal U-Boot image for this now. Please note
the changes TEXT_BASE here. Its now 0x8020.

This actually seems to work right if I start from my original u-boot
(1.1.3,
flashed at start of SPI NOR), but it fails if I start from a flashed
(at the
same location) u-boot-mtmips.bin
I *think* this happens because unpacking actually writes u-boot at
0x8020 and runs it from there, so "load usb 0:1 8020 u-boot.bin"
(or equivalent) will overwrite the running u-boot and the following
"go ${fileaddr}" fails:
     ## Starting application at 0x8020 ...
     


No, U-Boot relocates itself to the end of RAM and runs from there. So
this should work. Perhaps a cache flush is missing.

I'll give it a try on my LinkIt board as well later.

Did You manage to test this?


Yes. I just tested for a few minutes and it seems to work on the LinkIt
board:

=> printenv tt
tt=tftp 8020 ${tftpdir}/u-boot.bin;dcache off;go ${fileaddr}
=> run tt
Using eth@1011 device
TFTP from server 192.168.1.5; our IP address is 192.168.1.233
Filename 'linkit-smart-7688/u-boot.bin'.
Load address: 0x8020
Loading: ###
 4.8 MiB/s
done
Bytes transferred = 450139 (6de5b hex)
Unknown command 'dcache' - try 'help'
## Starting application at 0x8020 ...


U-Boot 2020.01-00680-g90cb39245e (Jan 21 2020 - 10:54:50 +0100)

CPU:   MediaTek MT7688A ver:1 eco:2
Boot:  DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: LinkIt-Smart-7688
...


I am currently testing loading from "paleolithic" u-boot, but I want to fix
this before I finalize VoCore2 patches.

I tried to do some manual testing enabling CONFIG_CMD_CACHE, but this
bombs with Weijie patches with:

   LD  u-boot
mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache':
cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined
reference to `icache_enable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined
reference to `icache_status'
make: *** [Makefile:1697: u-boot] Error 1

icache seems enabled unconditionally in
arch/mips/mach-mtmips/mt7628/lowlevel_init.S::73+

I will try to add dummy functions just-to-play.


No need to "play" with these cache functions. Its included in the
LinkIt image and should be in yours as well, if you didn't change
too much.

Thanks,
Stefan

Re: [PATCH v2 01/11] clk: Always use the supplied struct clk

[Sean Anderson]

> [1] https://patchwork.ozlabs.org/patch/1215327/
> [2] https://patchwork.ozlabs.org/patch/1215328/

err, these references should be

[1] https://patchwork.ozlabs.org/patch/1215335/
[2] https://patchwork.ozlabs.org/patch/1215337/

[PATCH] mmc: check the return value of mmc_select_mode_and_width()

[Masahiro Yamada]

Since commit 01298da31d92 ("mmc: Change mode when switching to a boot
partition"), errors in mmc_select_mode_and_width() are ignored.
The return value should be checked.

Fixes: 01298da31d92 ("mmc: Change mode when switching to a boot partition")
Signed-off-by: Masahiro Yamada 
---

 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 d43983d4a648..b26e266c1c29 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2575,7 +2575,7 @@ static int mmc_startup(struct mmc *mmc)
err = mmc_get_capabilities(mmc);
if (err)
return err;
-   mmc_select_mode_and_width(mmc, mmc->card_caps);
+   err = mmc_select_mode_and_width(mmc, mmc->card_caps);
}
 #endif
if (err)
-- 
2.17.1

Re: [Patchv4 1/3] mmc: meson-gx: Fix clk phase tuning for MMC

[Anand Moon]

Hi Jaehoon,

On Thu, 23 Jan 2020 at 05:09, Jaehoon Chung  wrote:
>
> Dear Anand,
>
> On 1/22/20 9:06 PM, Anand Moon wrote:
> > As per mainline line kernel fix the clk tunig phase for
> > mmc, set Core=180, Tx=180, Rx=0 clk phase for mmc initialization.
> > As per S905X and S922X datasheet set the default values
> > for clk tuning.
> >
> > Signed-off-by: Anand Moon 
> > ---
> > Changes from previous
> > v3  Fix the initialization of core clk tunning phase as per datasheet.
> > Fix the commit message.
> >
> > v2: Fix the clk phase macro to support PHASE_180
> > drop the wrong CLK_CORE_PHASE_MASK macro.
> >
> > v1: use the mainline kernel tuning for clk tuning.
> >
> > Fixed the commmit messages.
> > Patch v1:
> > https://protect2.fireeye.com/url?k=c4a34ac1-9973420d-c4a2c18e-000babff3793-f192c82d705776ae=https://patchwork.ozlabs.org/patch/1201208/
> >
> > Before these changes.
> > clock is enabled (380953Hz)
> > clock is enabled (2500Hz)
> > After these changes
> > clock is enabled (380953Hz)
> > clock is enabled (2500Hz)
> > clock is enabled (5200Hz)
> > Test on Odroid N2 and Odroid C2 with eMMC and microSD cards
> > ---
> >  arch/arm/include/asm/arch-meson/sd_emmc.h | 11 ++-
> >  drivers/mmc/meson_gx_mmc.c| 38 +++
> >  2 files changed, 35 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h 
> > b/arch/arm/include/asm/arch-meson/sd_emmc.h
> > index e3a72c8b66..c193547aad 100644
> > --- a/arch/arm/include/asm/arch-meson/sd_emmc.h
> > +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
> > @@ -7,6 +7,7 @@
> >  #define __SD_EMMC_H__
> >
> >  #include 
> > +#include 
> >
> >  #define SDIO_PORT_A  0
> >  #define SDIO_PORT_B  1
> > @@ -19,14 +20,8 @@
> >  #define   CLK_MAX_DIV63
> >  #define   CLK_SRC_24M(0 << 6)
> >  #define   CLK_SRC_DIV2   (1 << 6)
> > -#define   CLK_CO_PHASE_000   (0 << 8)
> > -#define   CLK_CO_PHASE_090   (1 << 8)
> > -#define   CLK_CO_PHASE_180   (2 << 8)
> > -#define   CLK_CO_PHASE_270   (3 << 8)
> > -#define   CLK_TX_PHASE_000   (0 << 10)
> > -#define   CLK_TX_PHASE_090   (1 << 10)
> > -#define   CLK_TX_PHASE_180   (2 << 10)
> > -#define   CLK_TX_PHASE_270   (3 << 10)
> > +#defineUPDATE(x, h, l)   (((x) << (l)) & GENMASK((h), 
> > (l)))
> > +
> >  #define   CLK_ALWAYS_ON  BIT(24)
> >
> >  #define MESON_SD_EMMC_CFG0x44
> > diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
> > index 86c1a7164a..67b1b075ab 100644
> > --- a/drivers/mmc/meson_gx_mmc.c
> > +++ b/drivers/mmc/meson_gx_mmc.c
> > @@ -51,12 +51,38 @@ static void meson_mmc_config_clock(struct mmc *mmc)
> >   }
> >   clk_div = DIV_ROUND_UP(clk, mmc->clock);
> >
> > - /* 180 phase core clock */
> > - meson_mmc_clk |= CLK_CO_PHASE_180;
> > -
> > - /* 180 phase tx clock */
> > - meson_mmc_clk |= CLK_TX_PHASE_000;
> > -
> > + /* Clock divider */
> > + meson_mmc_clk = GENMASK(5, 0);
> > + /* Clock source 1: Fix PLL, 1000MHz */
> > + meson_mmc_clk |= UPDATE(1, 7, 6);
> > + /* Core clock phase 2:180 */
> > + meson_mmc_clk |= UPDATE(2, 9, 8);
> > + /* TX clock phase 2:180 */
> > + meson_mmc_clk |= UPDATE(2, 11, 10);
> > + /* RX clock phase 0:180 */
> > + meson_mmc_clk |= UPDATE(0, 13, 12);
> > +#ifdef CONFIG_MESON_GX
> > + /* TX clock delay line */
> > + meson_mmc_clk |= GENMASK(19, 16);
> > + /* RX clock delay line */
> > + meson_mmc_clk |= GENMASK(23, 20);
> > + /* clk always on */

Opps Typo this should be BIT(24)

> > + meson_mmc_clk |= BIT(20);
> > + /* clk irq sdio sleep */
> > + meson_mmc_clk |= BIT(25);
>
> Could you define the macro instead of BIT(x)?
> It's helpful to know what its bit is used.
>
> e.g) #define CLK_ALWAYS_ON BIT(20)
>
> i didn't know that BIT(20)/(25) are defined as what purpose has.
>
> Best Regards,
> Jaehoon Chung

Thanks for your review.
Their are different bit setting for CLK_ALWAYS_ON on
BIT(24) for (S905. S905X)  and BIT(28) for S922X.
I will change this as per your suggestion in the next version
Lets wait for more comments on this patch.

-Anand

>
> > +#endif
> > +#if (defined(CONFIG_MESON_AXG) || defined(CONFIG_MESON_G12A))
> > + /* TX clock delay line */
> > + meson_mmc_clk |=  GENMASK(21, 16);
> > + /* RX clock delay line */
> > + meson_mmc_clk |=  GENMASK(27, 22);
> > + /* clk always on */
> > + meson_mmc_clk |= BIT(28);
> > + /* clk irq sdio sleep */
> > + meson_mmc_clk |= BIT(29);
> > + /* clk irq sdio sleep_ds */
> > + meson_mmc_clk |= BIT(30);
> > +#endif
> >   /* clock settings */
> >   meson_mmc_clk |= clk_src;
> >   meson_mmc_clk |= clk_div;
> >
>

Re: [PATCH v3 02/10] arm: k3: Add support for loading non linux remote cores

[Keerthy]

On 22/01/20 9:55 pm, Andrew F. Davis wrote:

On 1/21/20 8:10 PM, keerthy wrote:



On 1/21/2020 6:26 PM, Andrew F. Davis wrote:

On 1/21/20 6:07 AM, Keerthy wrote:

Add MAIN domain R5FSS0 remoteproc support from spl. This enables
loading the elf firmware in SPL and starting the remotecore.

In order to start the core, there should be a file with path
"/lib/firmware/j7-main-r5f0_0-fw" under filesystem
of respective boot mode.

Signed-off-by: Keerthy 
Signed-off-by: Lokesh Vutla 
[Guard start_non_linux_remote_cores under CONFIG_FS_LOADER]
Signed-off-by: Andreas Dannenberg 
---
   arch/arm/mach-k3/common.c | 84 ---
   arch/arm/mach-k3/common.h |  2 +
   arch/arm/mach-k3/j721e_init.c | 34 ++
   3 files changed, 115 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 8d1529062d..f0ac0c39f1 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -16,6 +16,10 @@
   #include 
   #include 
   #include 
+#include 
+#include 
+#include 
+#include 
     struct ti_sci_handle *get_ti_sci_handle(void)
   {
@@ -57,6 +61,74 @@ int early_console_init(void)
   #endif
     #ifdef CONFIG_SYS_K3_SPL_ATF
+
+void init_env(void)
+{
+#ifdef CONFIG_SPL_ENV_SUPPORT
+    char *part;
+
+    env_init();
+    env_load();
+    switch (spl_boot_device()) {
+    case BOOT_DEVICE_MMC2:
+    part = env_get("bootpart");
+    env_set("storage_interface", "mmc");
+    env_set("fw_dev_part", part);
+    break;
+    case BOOT_DEVICE_SPI:
+    env_set("storage_interface", "ubi");
+    env_set("fw_ubi_mtdpart", "UBI");
+    env_set("fw_ubi_volume", "UBI0");
+    break;
+    default:
+    printf("%s from device %u not supported!\n",
+   __func__, spl_boot_device());



This will print for almost every boot mode..


I can keep this under debug.





+    return;
+    }
+#endif
+}
+
+#ifdef CONFIG_FS_LOADER
+int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
+{
+    struct udevice *fsdev;
+    char *name = NULL;
+    int size = 0;
+
+    *loadaddr = 0;
+#ifdef CONFIG_SPL_ENV_SUPPORT
+    switch (spl_boot_device()) {
+    case BOOT_DEVICE_MMC2:
+    name = env_get(name_fw);
+    *loadaddr = env_get_hex(name_loadaddr, *loadaddr);
+    break;
+    default:
+    printf("Loading rproc fw image from device %u not
supported!\n",
+   spl_boot_device());



This whole thing seems very MMC specific, if early firmware loading is
important it should work for all boot modes. Find a way to include it in
the next boot stage FIT image (tispl.bin) so it works for all modes.


That was not NAKd. We are going with fs_loader approach.




When, where, link?


I had implemented that way internally. That was rejected for multiple 
right reasons:


1) SPL size would bloat based on the size of the firmware.
2) There are multiple cores that need to be loaded and hence adding all 
the firmwares under a fit can be really painful.

3) Changing firmware means building the tispl.bin again.

The FIT solution can not scale well.

- Keerthy







+    return 0;
+    }
+#endif
+    if (!*loadaddr)
+    return 0;
+
+    if (!uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
+    size = request_firmware_into_buf(fsdev, name, (void
*)*loadaddr,
+ 0, 0);
+    }
+
+    return size;
+}
+#else
+int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
+{
+    return 0;
+}
+#endif
+
+__weak void start_non_linux_remote_cores(void)
+{
+}
+
   void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
   {
   struct ti_sci_handle *ti_sci = get_ti_sci_handle();
@@ -65,15 +137,17 @@ void __noreturn jump_to_image_no_args(struct
spl_image_info *spl_image)
   /* Release all the exclusive devices held by SPL before
starting ATF */
   ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
   +    ret = rproc_init();
+    if (ret)
+    panic("rproc failed to be initialized (%d)\n", ret);
+
+    init_env();
+    start_non_linux_remote_cores();
+
   /*
    * It is assumed that remoteproc device 1 is the corresponding
    * Cortex-A core which runs ATF. Make sure DT reflects the same.
    */
-    ret = rproc_dev_init(1);
-    if (ret)
-    panic("%s: ATF failed to initialize on rproc (%d)\n", __func__,
-  ret);
-



Where did this code go?


rproc_init takes care of that.




Is that new behavior then? It should be it's own patch with a commit
message about that.






   ret = rproc_load(1, spl_image->entry_point, 0x200);
   if (ret)
   panic("%s: ATF failed to load on rproc (%d)\n", __func__,
ret);
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index d8b34fe060..42fb8ee6e7 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -24,3 +24,5 @@ void setup_k3_mpu_regions(void);
   int early_console_init(void);
   void 

Re: [PATCH v2 7/7] board: presidio-asic: Add basic G3 engr. development board support

[Alex Nemirovsky]

Hi Daniel,

We have a question about one of your feedback points. 


> On Jan 22, 2020, at 1:24 PM, Daniel Schwierzeck 
>  wrote:
> 
> 
> 
> the defconfig file must not created manually, try this:
> 
> make savedefconfig
> cp defconfig configs/cortina_presidio-asic-base_defconfig

We can appreciate that  *defconfig should be complete. 
However we also have a desire to easy maintenance of multiple board *defconfig 
files variants which differ
in key CA features differences.  As presidio is a development board, its 
important to be able to support and easily maintain different
but common configuration variants for our customers.  

It seems that buildman takes in our partial board varient  *defconfig files and 
autogenerates more complete defconfig 
called u-boot.cfg at build time.  This also, in our opinion, helps to keep our 
defconfig files from becoming stale
with newer revisions of the core u-boot code base. 

If this is not acceptable, do you have any recommendation on how we easy our 
maintenance of 
multiple board defconfig variants using an alternate approach?

-BR
AN

[PATCH] common: blk: fix comment about blkcache_read return value

[Eric Nelson]

The blkcache_read() routine returns 1 (true) to indicate that a block was
found in the cache and returned, or 0 if not.

Signed-off-by: Eric Nelson 
---
 include/blk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/blk.h b/include/blk.h
index 65db69f5d9..6f541bb2ba 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -129,7 +129,7 @@ int blkcache_init(void);
  * @param blksz - size in bytes of each block
  * @param buf - buffer to contain cached data
  *
- * @return - '1' if block returned from cache, '0' otherwise.
+ * @return - 1 if block returned from cache, 0 otherwise.
  */
 int blkcache_read(int iftype, int dev,
  lbaint_t start, lbaint_t blkcnt,
-- 
2.17.1

[PATCH] Optionally: Set the serial# environment variable on the i.MX7.

[Mark Grosberg]

Enabline this new option allows the kernel to obtain the unique ID of 
the CPU when not using ATAGS.


Signed-off-by: Mark G 
---
 arch/arm/include/asm/bootm.h  |  2 +-
 arch/arm/mach-imx/mx7/Kconfig |  7 +++
 arch/arm/mach-imx/mx7/soc.c   | 15 ++-
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/bootm.h b/arch/arm/include/asm/bootm.h
index a2131ca07c..64ceb36ed8 100644
--- a/arch/arm/include/asm/bootm.h
+++ b/arch/arm/include/asm/bootm.h
@@ -39,7 +39,7 @@ extern void udc_disconnect(void);
 #endif

 struct tag_serialnr;
-#ifdef CONFIG_SERIAL_TAG
+#if defined(CONFIG_SERIAL_TAG) || defined(CONFIG_SET_SERIAL_ENV)
  #define BOOTM_ENABLE_SERIAL_TAG   1
 void get_board_serial(struct tag_serialnr *serialnr);
 #else
diff --git a/arch/arm/mach-imx/mx7/Kconfig b/arch/arm/mach-imx/mx7/Kconfig
index 286d36589d..4cf14d43c0 100644
--- a/arch/arm/mach-imx/mx7/Kconfig
+++ b/arch/arm/mach-imx/mx7/Kconfig
@@ -71,6 +71,13 @@ config TARGET_COLIBRI_IMX7

 endchoice

+config SET_SERIAL_ENV
+   bool "Set serial number variable from the OCOTP"
+   help
+ Selecting this option will populate the serial# environment
+ variable with a unique identifier from the i.MX7 CPU. The
+ Linux kernel will use this as the serial number of the machine.
+
 config SYS_SOC
default "mx7"

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 4aafeed188..208400a4a7 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -344,11 +344,24 @@ int arch_misc_init(void)
sec_init();
 #endif

+#ifdef CONFIG_SET_SERIAL_ENV
+   {
+   struct tag_serialnr serialnr;
+   char serialbuf[sizeof(serialnr) * 2 + 8];
+
+   get_board_serial();
+   snprintf(serialbuf, sizeof(serialbuf),
+"%08lx%08lx",
+(ulong)serialnr.high, (ulong)serialnr.low);
+   env_set("serial#", serialbuf);
+   }
+#endif
+
return 0;
 }
 #endif

-#ifdef CONFIG_SERIAL_TAG
+#if defined(CONFIG_SERIAL_TAG) || defined(CONFIG_SET_SERIAL_ENV)
 /*
  * OCOTP_TESTER
  * i.MX 7Solo Applications Processor Reference Manual, Rev. 0.1, 08/2016
--
2.17.1

[PATCH] common/board_f.c: Remove arch-specific checks for cpucheck

[Ovidiu Panait]

This removes the arch-specific checks for "checkcpu" function from the init
sequence. Make "checkcpu" generic and provide a weak nop stub instead.

Signed-off-by: Ovidiu Panait 
---
 common/board_f.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index 3f0132a6e3..8fa26e3ca5 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -862,6 +862,11 @@ __weak int arch_cpu_init_dm(void)
return 0;
 }
 
+__weak int checkcpu(void)
+{
+   return 0;
+}
+
 static const init_fnc_t init_sequence_f[] = {
setup_mon_len,
 #ifdef CONFIG_OF_CONTROL
@@ -904,9 +909,7 @@ static const init_fnc_t init_sequence_f[] = {
console_init_f, /* stage 1 init of console */
display_options,/* say that we are here */
display_text_info,  /* show debugging info if required */
-#if defined(CONFIG_PPC) || defined(CONFIG_SH) || defined(CONFIG_X86)
checkcpu,
-#endif
 #if defined(CONFIG_SYSRESET)
print_resetinfo,
 #endif
-- 
2.17.1

[PATCH] board: novtech: meerkat96: use correct mmc driver

[Carl Gelfand]

When the board was originally submitted, it was attempting to use the
ESDHC driver. The board uses the USDHC driver.

Signed-off-by: Carl Gelfand 
Cc: Shawn Guo  (maintainer:MEERKAT96 BOARD)
---
 configs/meerkat96_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/meerkat96_defconfig b/configs/meerkat96_defconfig
index d8782815e1..50d9040c54 100644
--- a/configs/meerkat96_defconfig
+++ b/configs/meerkat96_defconfig
@@ -36,7 +36,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM_GPIO=y
 CONFIG_MMC_BROKEN_CD=y
 CONFIG_DM_MMC=y
-CONFIG_FSL_ESDHC=y
+CONFIG_FSL_USDHC=y
 CONFIG_MTD=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX7=y
--
2.11.0

Re: [PATCH] common: add blkcache init

[Eric Nelson]

Thanks Angelo,

On 1/21/20 2:37 AM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
Changes for v2:
- call blkcache_init directly
---
  common/board_r.c | 3 +++
  drivers/block/blkcache.c | 9 -
  include/blk.h| 6 ++
  3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 8a0c1114e7..4f56c19fcc 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -864,6 +864,9 @@ static init_fnc_t init_sequence_r[] = {
  #endif
  #if defined(CONFIG_PRAM)
initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE
+   blkcache_init,
  #endif
run_main_loop,
  };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..f603aa129d 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,20 @@ struct block_cache_node {
char *cache;
  };
  
-static LIST_HEAD(block_cache);

+static struct list_head block_cache;
  
  static struct block_cache_stats _stats = {

.max_blocks_per_entry = 8,
.max_entries = 32
  };
  
+int blkcache_init(void)

+{
+   INIT_LIST_HEAD(_cache);
+
+   return 0;
+}
+
  static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t blkcnt,
   unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..65db69f5d9 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
(PAD_SIZE(size, blk_desc->blksz))
  
  #if CONFIG_IS_ENABLED(BLOCK_CACHE)

+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+int blkcache_init(void);
+
  /**
   * blkcache_read() - attempt to read a set of blocks from cache
   *



This looks good to me.

Reviewed-by: Eric Nelson 

Re: [Patchv4 1/3] mmc: meson-gx: Fix clk phase tuning for MMC

[Jaehoon Chung]

Dear Anand,

On 1/22/20 9:06 PM, Anand Moon wrote:
> As per mainline line kernel fix the clk tunig phase for
> mmc, set Core=180, Tx=180, Rx=0 clk phase for mmc initialization.
> As per S905X and S922X datasheet set the default values
> for clk tuning.
> 
> Signed-off-by: Anand Moon 
> ---
> Changes from previous
> v3  Fix the initialization of core clk tunning phase as per datasheet.
> Fix the commit message.
> 
> v2: Fix the clk phase macro to support PHASE_180
> drop the wrong CLK_CORE_PHASE_MASK macro.
> 
> v1: use the mainline kernel tuning for clk tuning.
> 
> Fixed the commmit messages.
> Patch v1:
> https://protect2.fireeye.com/url?k=c4a34ac1-9973420d-c4a2c18e-000babff3793-f192c82d705776ae=https://patchwork.ozlabs.org/patch/1201208/
> 
> Before these changes.
> clock is enabled (380953Hz)
> clock is enabled (2500Hz)
> After these changes
> clock is enabled (380953Hz)
> clock is enabled (2500Hz)
> clock is enabled (5200Hz)
> Test on Odroid N2 and Odroid C2 with eMMC and microSD cards
> ---
>  arch/arm/include/asm/arch-meson/sd_emmc.h | 11 ++-
>  drivers/mmc/meson_gx_mmc.c| 38 +++
>  2 files changed, 35 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h 
> b/arch/arm/include/asm/arch-meson/sd_emmc.h
> index e3a72c8b66..c193547aad 100644
> --- a/arch/arm/include/asm/arch-meson/sd_emmc.h
> +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
> @@ -7,6 +7,7 @@
>  #define __SD_EMMC_H__
>  
>  #include 
> +#include 
>  
>  #define SDIO_PORT_A  0
>  #define SDIO_PORT_B  1
> @@ -19,14 +20,8 @@
>  #define   CLK_MAX_DIV63
>  #define   CLK_SRC_24M(0 << 6)
>  #define   CLK_SRC_DIV2   (1 << 6)
> -#define   CLK_CO_PHASE_000   (0 << 8)
> -#define   CLK_CO_PHASE_090   (1 << 8)
> -#define   CLK_CO_PHASE_180   (2 << 8)
> -#define   CLK_CO_PHASE_270   (3 << 8)
> -#define   CLK_TX_PHASE_000   (0 << 10)
> -#define   CLK_TX_PHASE_090   (1 << 10)
> -#define   CLK_TX_PHASE_180   (2 << 10)
> -#define   CLK_TX_PHASE_270   (3 << 10)
> +#defineUPDATE(x, h, l)   (((x) << (l)) & GENMASK((h), 
> (l)))
> +
>  #define   CLK_ALWAYS_ON  BIT(24)
>  
>  #define MESON_SD_EMMC_CFG0x44
> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
> index 86c1a7164a..67b1b075ab 100644
> --- a/drivers/mmc/meson_gx_mmc.c
> +++ b/drivers/mmc/meson_gx_mmc.c
> @@ -51,12 +51,38 @@ static void meson_mmc_config_clock(struct mmc *mmc)
>   }
>   clk_div = DIV_ROUND_UP(clk, mmc->clock);
>  
> - /* 180 phase core clock */
> - meson_mmc_clk |= CLK_CO_PHASE_180;
> -
> - /* 180 phase tx clock */
> - meson_mmc_clk |= CLK_TX_PHASE_000;
> -
> + /* Clock divider */
> + meson_mmc_clk = GENMASK(5, 0);
> + /* Clock source 1: Fix PLL, 1000MHz */
> + meson_mmc_clk |= UPDATE(1, 7, 6);
> + /* Core clock phase 2:180 */
> + meson_mmc_clk |= UPDATE(2, 9, 8);
> + /* TX clock phase 2:180 */
> + meson_mmc_clk |= UPDATE(2, 11, 10);
> + /* RX clock phase 0:180 */
> + meson_mmc_clk |= UPDATE(0, 13, 12);
> +#ifdef CONFIG_MESON_GX
> + /* TX clock delay line */
> + meson_mmc_clk |= GENMASK(19, 16);
> + /* RX clock delay line */
> + meson_mmc_clk |= GENMASK(23, 20);
> + /* clk always on */
> + meson_mmc_clk |= BIT(20);
> + /* clk irq sdio sleep */
> + meson_mmc_clk |= BIT(25);

Could you define the macro instead of BIT(x)?
It's helpful to know what its bit is used. 

e.g) #define CLK_ALWAYS_ON BIT(20)

i didn't know that BIT(20)/(25) are defined as what purpose has.

Best Regards,
Jaehoon Chung

> +#endif
> +#if (defined(CONFIG_MESON_AXG) || defined(CONFIG_MESON_G12A))
> + /* TX clock delay line */
> + meson_mmc_clk |=  GENMASK(21, 16);
> + /* RX clock delay line */
> + meson_mmc_clk |=  GENMASK(27, 22);
> + /* clk always on */
> + meson_mmc_clk |= BIT(28);
> + /* clk irq sdio sleep */
> + meson_mmc_clk |= BIT(29);
> + /* clk irq sdio sleep_ds */
> + meson_mmc_clk |= BIT(30);
> +#endif
>   /* clock settings */
>   meson_mmc_clk |= clk_src;
>   meson_mmc_clk |= clk_div;
> 

Re: [U-Boot] [PATCH v2] spl: Move check for SPL_LIBCOMMON support to header

[Tom Rini]

On Tue, Jan 07, 2020 at 06:36:23PM -0500, Andrew F. Davis wrote:

> Print statements in SPL depend on lib/common support, due to this many
> such print statements are ifdef'd. Instead of checking at each call site
> move the check to the common.h header and remove these inline checks.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Simon Glass 
> Reviewed-by: Lokesh Vutla 

This breaks a number of platforms as can be seen on Travis/GitLab/Azure.
I bisected down to this commit while testing by using the firefly-px30
board.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 7/7] board: presidio-asic: Add basic G3 engr. development board support

[Alex Nemirovsky]

Hi Daniel,
Thanks for your feedback and guidance. I grok all except the recommendation 
about migrating out the definition of GICD_BASE and GIDCC_BASE.

your comment was:
+/* Generic Interrupt Controller Definitions */
+#define GICD_BASE 0xf7011000
+#define GICC_BASE 0xf7012000

don't put register addresses in the config file. Those should come from
device-tree anyway. The config file should only set the legacy config
options which aren't yet migrated to Kconfig. If you need that in
low-level code or so, put the defines there or create a small header file

However,  I think this may be wider concern than just our new ARMv8 board 
submission.

ARMv8 core components such as:

arch/arm/lib/gic_64.S
arch/arm/cpu/armv8/start.S

reference these ARM GIC symbols without going through DT. As a result,
many boards define them in their configs/board.h files.

Perhaps this needs to be solved at a later time in bulk for all ARMv8 boards?

see below:

uboot@78d4bae197f9:/build$ find . -type f -exec grep -H GICC_BASE {} \;
./board/cortina/common/armv8/lowlevel_init.S: ldr x1, =GICC_BASE
./board/cortina/common/armv8/lowlevel_init.S: ldr x0, =GICC_BASE
./include/configs/rcar-gen3-common.h:#define GICC_BASE 0xF102
./include/configs/px30_common.h:#define GICC_BASE 0xff132000
./include/configs/vexpress_aemv8a.h:#define GICC_BASE (0x2c00)
./include/configs/vexpress_aemv8a.h:#define GICC_BASE (0x2C02f000)
./include/configs/meson64.h:#define GICC_BASE 0xffc02000
./include/configs/meson64.h:#define GICC_BASE 0xc4302000
./include/configs/s32v234evb.h:#define GICC_BASE 0x7D002000
./include/configs/hikey960.h:#define GICC_BASE 0xe82b2000
./include/configs/hikey.h:#define GICC_BASE 0xf6802000
./include/configs/sun50i.h:#define GICC_BASE 0x1c82000
./include/configs/sun50i.h:#define GICC_BASE 0x3022000
./include/configs/xilinx_zynqmp.h:#define GICC_BASE 0xF902
./arch/arm/include/asm/arch-tegra210/tegra.h:#define GICC_BASE 0x50042000 /* 
Generic Int Cntrlr CPU I/F */
./arch/arm/include/asm/arch-fsl-layerscape/config.h:#define GICC_BASE 0x01402000
./arch/arm/include/asm/arch-fsl-layerscape/config.h:#define GICC_BASE_64K 
0x0142
./arch/arm/include/asm/arch-fsl-layerscape/config.h:#define GICC_BASE 0x01402000
./arch/arm/include/asm/arch-fsl-layerscape/config.h:#define GICC_BASE 0x0142
./arch/arm/include/asm/arch-tegra186/tegra.h:#define GICC_BASE 0x03882000 /* 
Generic Int Cntrlr CPU I/F */
./arch/arm/lib/gic_64.S: ldr x1, =GICC_BASE /* GICC_CTLR */
./arch/arm/mach-snapdragon/include/mach/sysmap-apq8016.h:#define GICC_BASE 
(0x0a20c000)
./arch/arm/mach-socfpga/include/mach/base_addr_s10.h:#define GICC_BASE 
0xfffc2000
./arch/arm/cpu/armv7/sunxi/psci.c:#define GICC_BASE (SUNXI_GIC400_BASE + 
GIC_CPU_OFFSET_A15)
./arch/arm/cpu/armv7/sunxi/psci.c: reg = readl(GICC_BASE + GICC_IAR);
./arch/arm/cpu/armv7/sunxi/psci.c: writel(reg, GICC_BASE + GICC_EOIR);
./arch/arm/cpu/armv7/sunxi/psci.c: writel(0xff, GICC_BASE + GICC_PMR);
./arch/arm/cpu/armv7/sunxi/psci.c: setbits_le32(GICC_BASE + GICC_CTLR, BIT(3));
./arch/arm/cpu/armv8/start.S: ldr x1, =GICC_BASE
./arch/arm/cpu/armv8/start.S: ldr x0, =GICC_BASE
./arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S: ldr x1, =GICC_BASE
./arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S: ldr x1, =GICC_BASE_64K
./arch/arm/cpu/armv8/fsl-layerscape/fdt.c: reg[2] = cpu_to_fdt64(GICC_BASE_64K);
./arch/arm/cpu/armv8/fsl-layerscape/fdt.c: reg[2] = cpu_to_fdt64(GICC_BASE);
./arch/arm/cpu/armv8/start.S.orig: ldr x1, =GICC_BASE
./arch/arm/cpu/armv8/start.S.orig: ldr x0, =GICC_BASE
./arch/arm/mach-rmobile/lowlevel_init_gen3.S: ldr x1, =GICC_BASE
./arch/arm/mach-rmobile/lowlevel_init_gen3.S: ldr x0, =GICC_BASE

On Jan 22, 2020, at 1:24 PM, Daniel Schwierzeck 
mailto:daniel.schwierz...@gmail.com>> wrote:



Am 21.01.20 um 11:19 schrieb Alex Nemirovsky:
Add basic Presidio G3 engineering board support

Signed-off-by: Alex Nemirovsky 
mailto:alex.nemirov...@cortina-access.com>>
---

Changes in v2: None

arch/arm/Kconfig |   5 ++
arch/arm/dts/Makefile|   2 +
arch/arm/dts/ca-presidio-engboard.dts|  69 +++
board/cortina/common/armv8/ca7774_regs.h |  18 
board/cortina/presidio-asic/Kconfig  |  20 +
board/cortina/presidio-asic/MAINTAINERS  |   6 ++
board/cortina/presidio-asic/Makefile |   8 ++
board/cortina/presidio-asic/presidio.c   | 126 +++
configs/cortina_presidio-asic-base_defconfig |  45 ++
include/configs/presidio_asic.h  | 123 ++
10 files changed, 422 insertions(+)
create mode 100644 arch/arm/dts/ca-presidio-engboard.dts
create mode 100644 board/cortina/common/armv8/ca7774_regs.h
create mode 100644 board/cortina/presidio-asic/Kconfig
create mode 100644 board/cortina/presidio-asic/MAINTAINERS
create mode 100644 board/cortina/presidio-asic/Makefile
create mode 100644 board/cortina/presidio-asic/presidio.c
create mode 100644 

[PATCH 1/3] mmc: sdhci: use phys2bus macro when dma address is accessed

[Jaehoon Chung]

Use phys2bus macro when dma address is accessed.
Some targets need to use pyhs2bus macro. (e.g, RPI4)
After applied it, SDMA mode can be used.

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/sdhci.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 01fa5a9d4d..93c9049c5d 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_FIXED_SDHCI_ALIGNED_BUFFER)
 void *aligned_buffer = (void *)CONFIG_FIXED_SDHCI_ALIGNED_BUFFER;
@@ -164,7 +165,8 @@ static void sdhci_prepare_dma(struct sdhci_host *host, 
struct mmc_data *data,
if (data->flags != MMC_DATA_READ)
memcpy(aligned_buffer, data->src, trans_bytes);
 #endif
-   sdhci_writel(host, host->start_addr, SDHCI_DMA_ADDRESS);
+   sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
+   SDHCI_DMA_ADDRESS);
 
} else if (host->flags & (USE_ADMA | USE_ADMA64)) {
sdhci_prepare_adma_table(host, data);
@@ -220,7 +222,7 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data)
start_addr &=
~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
-   sdhci_writel(host, start_addr,
+   sdhci_writel(host, 
phys_to_bus((ulong)start_addr),
 SDHCI_DMA_ADDRESS);
}
}
-- 
2.25.0

[PATCH 0/3] Support SDMA mode on RPI4 target - 32bit

[Jaehoon Chung]

RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel side)
But It doesn't use on u-boot side. Then it's too slow about read/write 
performance.
This patchset is supported SDMA mode on RPI4 target(32bit).
- I didn't test on RPI4 64bit.

Read/write time about 8MB file
Before
- Read : 1.472 seconds
- Write : 4.690 seconds
After
- Read : 0.359 seconds
- Write : 0.574 seconds

This patch is based on my RFC's patches.

Jaehoon Chung (3):
  mmc: sdhci: use phys2bus macro when dma address is accessed
  mmc: sdhci: not return error when SDMA is not supported
  configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config

 configs/rpi_4_32b_defconfig |  1 +
 drivers/mmc/sdhci.c | 16 +---
 2 files changed, 10 insertions(+), 7 deletions(-)

-- 
2.25.0

[PATCH 3/3] configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config

[Jaehoon Chung]

Enable SDHCI_SDMA configuration.

Signed-off-by: Jaehoon Chung 
---
 configs/rpi_4_32b_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index 00f80f71ad..8fbadc0bc8 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -23,6 +23,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_BCM2835=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
-- 
2.25.0

[PATCH 2/3] mmc: sdhci: not return error when SDMA is not supported

[Jaehoon Chung]

If Host controller doesn't support SDMA, it doesn't need to return
error. Because it can be worked with PIO mode.

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/sdhci.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 93c9049c5d..bd8157d053 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -729,13 +729,13 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct 
sdhci_host *host,
debug("%s, caps: 0x%x\n", __func__, caps);
 
 #ifdef CONFIG_MMC_SDHCI_SDMA
-   if (!(caps & SDHCI_CAN_DO_SDMA)) {
-   printf("%s: Your controller doesn't support SDMA!!\n",
+   if ((caps & SDHCI_CAN_DO_SDMA)) {
+   host->flags |= USE_SDMA;
+   } else {
+   caps &= ~SDHCI_CAN_DO_SDMA;
+   debug("%s: Your controller doesn't support SDMA!!\n",
   __func__);
-   return -EINVAL;
}
-
-   host->flags |= USE_SDMA;
 #endif
 #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
if (!(caps & SDHCI_CAN_DO_ADMA2)) {
-- 
2.25.0

Re: [PATCH v2 7/7] board: presidio-asic: Add basic G3 engr. development board support

[Daniel Schwierzeck]

Am 21.01.20 um 11:19 schrieb Alex Nemirovsky:
> Add basic Presidio G3 engineering board support
> 
> Signed-off-by: Alex Nemirovsky 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/Kconfig |   5 ++
>  arch/arm/dts/Makefile|   2 +
>  arch/arm/dts/ca-presidio-engboard.dts|  69 +++
>  board/cortina/common/armv8/ca7774_regs.h |  18 
>  board/cortina/presidio-asic/Kconfig  |  20 +
>  board/cortina/presidio-asic/MAINTAINERS  |   6 ++
>  board/cortina/presidio-asic/Makefile |   8 ++
>  board/cortina/presidio-asic/presidio.c   | 126 
> +++
>  configs/cortina_presidio-asic-base_defconfig |  45 ++
>  include/configs/presidio_asic.h  | 123 ++
>  10 files changed, 422 insertions(+)
>  create mode 100644 arch/arm/dts/ca-presidio-engboard.dts
>  create mode 100644 board/cortina/common/armv8/ca7774_regs.h
>  create mode 100644 board/cortina/presidio-asic/Kconfig
>  create mode 100644 board/cortina/presidio-asic/MAINTAINERS
>  create mode 100644 board/cortina/presidio-asic/Makefile
>  create mode 100644 board/cortina/presidio-asic/presidio.c
>  create mode 100644 configs/cortina_presidio-asic-base_defconfig
>  create mode 100644 include/configs/presidio_asic.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 36c9c2f..6d95cde 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1638,6 +1638,10 @@ config TARGET_DURIAN
> Support for durian platform.
> It has 2GB Sdram, uart and pcie.
>  
> +config TARGET_PRESIDIO_ASIC
> + bool "Support Cortina Presidio ASIC Platform"
> + select ARM64
> +
>  endchoice
>  
>  config ARCH_SUPPORT_TFABOOT
> @@ -1782,6 +1786,7 @@ source "board/Marvell/gplugd/Kconfig"
>  source "board/armadeus/apf27/Kconfig"
>  source "board/armltd/vexpress/Kconfig"
>  source "board/armltd/vexpress64/Kconfig"
> +source "board/cortina/presidio-asic/Kconfig"
>  source "board/broadcom/bcm23550_w1d/Kconfig"
>  source "board/broadcom/bcm28155_ap/Kconfig"
>  source "board/broadcom/bcm963158/Kconfig"
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0127a91..81db1e6 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -849,6 +849,8 @@ dtb-$(CONFIG_TARGET_VEXPRESS_CA15_TC2) += 
> vexpress-v2p-ca15_a7.dtb
>  
>  dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
>  
> +dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
> +
>  targets += $(dtb-y)
>  
>  # Add any required device tree compiler flags here
> diff --git a/arch/arm/dts/ca-presidio-engboard.dts 
> b/arch/arm/dts/ca-presidio-engboard.dts
> new file mode 100644
> index 000..ef371b0
> --- /dev/null
> +++ b/arch/arm/dts/ca-presidio-engboard.dts
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020, Cortina Access Inc.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +   #address-cells = <2>;
> +   #size-cells = <1>;
> +
> + mmc0: mmc@f440 {
> + compatible = "snps,dw-cortina";
> + reg = <0x0 0xf440 0x1000>;
> + bus-width = <4>;
> + io_ds = <0x77>;
> + fifo-mode;
> + sd_dll_ctrl = <0xf43200e8>;
> + io_drv_ctrl = <0xf432004c>;
> + };
> +
> + gpio0: gpio-controller@0xf4329280  {
> + compatible = "cortina,ca-gpio";
> + reg = <0x0 0xf4329280 0x24>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + status = "okay";
> + };
> + gpio1: gpio-controller@0xf43292a4  {
> + compatible = "cortina,ca-gpio";
> + reg = <0x0 0xf43292a4 0x24>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + status = "disabled";
> + };
> +
> + watchdog: watchdog@0xf432901c {
> + compatible = "cortina,ca-wdt";
> + reg = <0x0 0xf432901c 0x34>,
> +   <0x0 0xf4320020 0x04>;
> + status = "okay";
> + };
> +
> + uart0: serial@0xf4329148  {
> + u-boot,dm-pre-reloc;
> + compatible = "cortina,ca-uart";
> + reg = <0x0 0xf4329148 0x30>;
> + status = "okay";
> + };
> +
> + i2c: i2c@f4329120 {
> + compatible = "cortina,ca-i2c";
> + reg = <0x0 0xf4329120 0x28>;
> + clock-frequency = <40>;
> + };
> +
> + sflash: sflash-controller@f4324000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "cortina,ca-sflash";
> + reg = <0x0 0xf4324000 0x50>;
> + reg-names = "sflash-regs";
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <1>;
> + spi-max-frequency = <10800>;
> + };

closing bracket is incorrectly indented

> + };
> +};
> diff --git 

Re: [RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

Hi,
I'm clearly out of my depth:

=> icache flush
No arch specific invalidate_icache_all available!
=> dcache flush
No arch specific flush_dcache_all available!
=> icache off 
=> dcache off 

Ooops:
$ 0   :   87e806c8 
$ 4   : ffd0 0014 87e80518 87fce61c
$ 8   : 87e7bc00 0010  fffc
$12   :  000f 0006 0007
$16   : ffd0   002f
$20   : 87e81350 87fe8528  0001
$24   : 0016 87f84130 
$28   : 87f882a0 87e7bba8 87e81362 87fa9524
Hi    : 0006
Lo    : 000640a2
epc   : 87fa1600 (text 80221600)
ra    : 87fa9524 (text 80229524)
Status: 0006
Cause : d0008028 (ExcCode 0a)
PrId  : 00019655
### ERROR ### Please RESET the board ###

Thanks
Mauro

On 1/22/20 9:16 PM, Mauro Condarelli wrote:
> Hi Stefan,
>
> On 1/21/20 1:08 PM, Stefan Roese wrote:
>> Hi Mauro,
>>
>> On 21.01.20 12:27, Mauro Condarelli wrote:
>>> Thanks Weijie,
>>> I made the changes You suggested.
>>> I have also seen You sent a new version of Your patches.
>>> Since mine are based on yours I *think* I should suspend
>>> sending my VoCore2 patches till Yours are fixed and integrated
>>> into master.
>>>
>>> @Stefan Roese: is this the right course of action?
>> I think in the current state of Weijie's patches (v3), you can resume
>> sending your VoCore2 support based on this latest patchset to the
>> list. Please don't attach a patch but send it inline next time
>> (git send-email) to enable review.
> I will send next iteration as soon as I fix the reflash problem (see below).
>  
> ===8<
>>> Side Question: Stefan wrote:
 Most of this can be done by using the
 RAM version now (again). There is no additional RAM booting target now
 any more. You can use the normal U-Boot image for this now. Please note
 the changes TEXT_BASE here. Its now 0x8020.
>>> This actually seems to work right if I start from my original u-boot
>>> (1.1.3,
>>> flashed at start of SPI NOR), but it fails if I start from a flashed
>>> (at the
>>> same location) u-boot-mtmips.bin
>>> I *think* this happens because unpacking actually writes u-boot at
>>> 0x8020 and runs it from there, so "load usb 0:1 8020 u-boot.bin"
>>> (or equivalent) will overwrite the running u-boot and the following
>>> "go ${fileaddr}" fails:
>>>     ## Starting application at 0x8020 ...
>>>     
>> No, U-Boot relocates itself to the end of RAM and runs from there. So
>> this should work. Perhaps a cache flush is missing.
>>
>> I'll give it a try on my LinkIt board as well later.
> Did You manage to test this?
> I am currently testing loading from "paleolithic" u-boot, but I want to fix
> this before I finalize VoCore2 patches.
>
> I tried to do some manual testing enabling CONFIG_CMD_CACHE, but this
> bombs with Weijie patches with:
>
>   LD  u-boot
> mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache':
> cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
> mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined
> reference to `icache_enable'
> mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined
> reference to `icache_status'
> make: *** [Makefile:1697: u-boot] Error 1
>
> icache seems enabled unconditionally in
> arch/mips/mach-mtmips/mt7628/lowlevel_init.S::73+
>
> I will try to add dummy functions just-to-play.
>
> Please advise
>
>> Thanks,
>> Stefan
> Regards and Many Thanks
> Mauro
>

Re: [PATCH v2 6/7] serial: serial_cortina: add UART DM driver for CAxxxx SoCs

[Daniel Schwierzeck]

Am 21.01.20 um 11:19 schrieb Alex Nemirovsky:
> From: Jason Li 
> 
> Add serial UART driver support for all Cortina Access
> CA family of SoCs.
> 
> Signed-off-by: Jason Li 
> Signed-off-by: Alex Nemirovsky 
> 
> 
> ---
> 
> Changes in v2:
> - Rename driver in DT namespace for consistency between all
>CA drivers.
> - Remove blank line after SPDX identifier
> - Remove authorship comment as it is already recorded within Git
>   and is redundant
> - Merge serial_cortina.h reg defines into serial_cortina.c
> - Modify ca_serial_pending() and API to get resource.
> 
>  drivers/serial/Kconfig  |   7 ++
>  drivers/serial/Makefile |   2 +-
>  drivers/serial/serial_cortina.c | 164 
> 
>  3 files changed, 172 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/serial/serial_cortina.c

Reviewed-by: Daniel Schwierzeck 

nits below

> 
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index ece7d87..9f76596 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -539,6 +539,13 @@ config BCM6345_SERIAL
>   help
> Select this to enable UART on BCM6345 SoCs.
>  
> +config CORTINA_UART
> + bool "Cortina UART support"
> + depends on DM_SERIAL
> + help
> +   Select this to enable UART support for Cortina-Access UART devices
> +   found on CA SoCs.
> +
>  config FSL_LINFLEXUART
>   bool "Freescale Linflex UART support"
>   depends on DM_SERIAL
> diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> index 06ee306..c8f2db4 100644
> --- a/drivers/serial/Makefile
> +++ b/drivers/serial/Makefile
> @@ -28,13 +28,13 @@ obj-$(CONFIG_PL010_SERIAL) += serial_pl01x.o
>  obj-$(CONFIG_PL011_SERIAL) += serial_pl01x.o
>  obj-$(CONFIG_SYS_NS16550_SERIAL) += serial_ns16550.o
>  endif
> -
>  obj-$(CONFIG_ALTERA_UART) += altera_uart.o
>  obj-$(CONFIG_ALTERA_JTAG_UART) += altera_jtag_uart.o
>  obj-$(CONFIG_AR933X_UART) += serial_ar933x.o
>  obj-$(CONFIG_ARM_DCC) += arm_dcc.o
>  obj-$(CONFIG_ATMEL_USART) += atmel_usart.o
>  obj-$(CONFIG_BCM6345_SERIAL) += serial_bcm6345.o
> +obj-$(CONFIG_CORTINA_UART) += serial_cortina.o
>  obj-$(CONFIG_EFI_APP) += serial_efi.o
>  obj-$(CONFIG_LPC32XX_HSUART) += lpc32xx_hsuart.o
>  obj-$(CONFIG_MCFUART) += mcfuart.o
> diff --git a/drivers/serial/serial_cortina.c b/drivers/serial/serial_cortina.c
> new file mode 100644
> index 000..3af64ba
> --- /dev/null
> +++ b/drivers/serial/serial_cortina.c
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2020
> + * Cortina-Access Ltd.

I think this should be on one line

> + *
> + */
> +
> +/* Common UART Driver for Cortina Access CA line of SoCs */

this should be moved to the previous comment block

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register definitions */
> +#define UCFG 0x00/* UART config register */
> +#define UFC  0x04/* Flow Control */
> +#define URX_SAMPLE   0x08/* UART RX Sample register */
> +#define URT_TUNE 0x0C/* Fine tune of UART clk */
> +#define UTX_DATA 0x10/* UART TX Character data */
> +#define URX_DATA 0x14/* UART RX Character data */
> +#define UINFO0x18/* UART Info */
> +#define UINT_EN0 0x1C/* UART Interrupt enable 0 */
> +#define UINT_EN1 0x20/* UART Interrupt enable 1 */
> +#define UINT00x24/* UART Interrupt 0 
> setting/clearing */
> +#define UINT10x28/* UART Interrupt 1 
> setting/clearing */
> +#define UINT_STAT0x2C/* UART Interrupt Status */
> +
> +/* UART Control Register Bit Fields */
> +#define UCFG_BAUD_COUNT  BIT(8)
> +#define UCFG_EN  BIT(7)
> +#define UCFG_RX_EN   BIT(6)
> +#define UCFG_TX_EN   BIT(5)
> +#define UCFG_PARITY_EN   BIT(4)
> +#define UCFG_PARITY_SEL  BIT(3)
> +#define UCFG_2STOP_BIT   BIT(2)
> +#define UCFG_CNT1BIT(1)
> +#define UCFG_CNT0BIT(0)
> +#define UCFG_CHAR_5  0
> +#define UCFG_CHAR_6  1
> +#define UCFG_CHAR_7  2
> +#define UCFG_CHAR_8  3
> +
> +#define UINFO_TX_FIFO_EMPTY  BIT(3)
> +#define UINFO_TX_FIFO_FULL   BIT(2)
> +#define UINFO_RX_FIFO_EMPTY  BIT(1)
> +#define UINFO_RX_FIFO_FULL   BIT(0)
> +
> +#define UINT_RX_NON_EMPTYBIT(6)
> +#define UINT_TX_EMPTYBIT(5)
> +#define UINT_RX_UNDERRUN BIT(4)
> +#define UINT_RX_OVERRUN  BIT(3)
> +#define UINT_RX_PARITY_ERR   BIT(2)
> +#define UINT_RX_STOP_ERR BIT(1)
> +#define UINT_TX_OVERRUN  BIT(0)
> +#define UINT_MASK_ALL0x7F
> +
> +struct ca_uart_priv {
> + void __iomem *base;
> +};
> +
> +int ca_serial_setbrg(struct udevice *dev, int baudrate)
> +{
> + struct 

Re: [PATCH v2 5/7] watchdog: cortina_wdt: add support for HW WDT on CAxxxx SoCs

[Daniel Schwierzeck]

Am 21.01.20 um 11:19 schrieb Alex Nemirovsky:
> From: Jason Li 
> 
> Add support for hardware watchdog timer on all Cortina Access
> CA family of SoCs.
> 
> Reviewed-by: Stefan Roese 
> Signed-off-by: Jason Li 
> Signed-off-by: Alex Nemirovsky 
> 
> 
> ---
> 
> Changes in v2:
> - Rename driver in DT namespace for consistency between all
>   CA drivers.
> - Remove blank line after SPDX identifier
> - Remove authorship comment as it is already recorded within Git
>   and is redundant
> - Use setbits_32() for read-modify-write operation.
> 
>  drivers/watchdog/Kconfig   |   8 +++
>  drivers/watchdog/Makefile  |   1 +
>  drivers/watchdog/cortina_wdt.c | 138 
> +
>  3 files changed, 147 insertions(+)
>  create mode 100644 drivers/watchdog/cortina_wdt.c
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel

Re: [PATCH v2 4/7] gpio: cortina_gpio: add DM_GPIO driver for CAxxxx SoCs

[Daniel Schwierzeck]

Am 21.01.20 um 11:19 schrieb Alex Nemirovsky:
> From: Jason Li 
> 
> DM_GPIO based GPIO controller driver for CA SoCs.
> This driver support multiple CPU architectures and
> Cortina Access SoC platforms.
> 
> Signed-off-by: Jason Li 
> Signed-off-by: Alex Nemirovsky 
> 
> 
> ---
> 
> Changes in v2:
> - Rename driver in DT namespace for consistency between all
>   CA drivers.
> - Remove blank line after SPDX identifier
> - Remove Authorship as it is already recorded within Git and is redundant
> - Replace printf() as debug()
> 
>  drivers/gpio/Kconfig|   8 
>  drivers/gpio/Makefile   |   1 +
>  drivers/gpio/cortina_gpio.c | 111 
> 
>  3 files changed, 120 insertions(+)
>  create mode 100644 drivers/gpio/cortina_gpio.c
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel

Re: [RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

Hi Stefan,

On 1/21/20 1:08 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 21.01.20 12:27, Mauro Condarelli wrote:
>> Thanks Weijie,
>> I made the changes You suggested.
>> I have also seen You sent a new version of Your patches.
>> Since mine are based on yours I *think* I should suspend
>> sending my VoCore2 patches till Yours are fixed and integrated
>> into master.
>>
>> @Stefan Roese: is this the right course of action?
>
> I think in the current state of Weijie's patches (v3), you can resume
> sending your VoCore2 support based on this latest patchset to the
> list. Please don't attach a patch but send it inline next time
> (git send-email) to enable review.
I will send next iteration as soon as I fix the reflash problem (see below).
 
===8<
>> Side Question: Stefan wrote:
>>> Most of this can be done by using the
>>> RAM version now (again). There is no additional RAM booting target now
>>> any more. You can use the normal U-Boot image for this now. Please note
>>> the changes TEXT_BASE here. Its now 0x8020.
>> This actually seems to work right if I start from my original u-boot
>> (1.1.3,
>> flashed at start of SPI NOR), but it fails if I start from a flashed
>> (at the
>> same location) u-boot-mtmips.bin
>> I *think* this happens because unpacking actually writes u-boot at
>> 0x8020 and runs it from there, so "load usb 0:1 8020 u-boot.bin"
>> (or equivalent) will overwrite the running u-boot and the following
>> "go ${fileaddr}" fails:
>>     ## Starting application at 0x8020 ...
>>     
>
> No, U-Boot relocates itself to the end of RAM and runs from there. So
> this should work. Perhaps a cache flush is missing.
>
> I'll give it a try on my LinkIt board as well later.
Did You manage to test this?
I am currently testing loading from "paleolithic" u-boot, but I want to fix
this before I finalize VoCore2 patches.

I tried to do some manual testing enabling CONFIG_CMD_CACHE, but this
bombs with Weijie patches with:

  LD  u-boot
mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache':
cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined
reference to `icache_enable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined
reference to `icache_status'
make: *** [Makefile:1697: u-boot] Error 1

icache seems enabled unconditionally in
arch/mips/mach-mtmips/mt7628/lowlevel_init.S::73+

I will try to add dummy functions just-to-play.

Please advise

> Thanks,
> Stefan
Regards and Many Thanks
Mauro

Re: [PATCH v3 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Joel Johnson]

On January 22, 2020 10:32:58 AM UTC, Baruch Siach  wrote:
>Hi Joel,
>
>On Wed, Jan 22 2020, Joel Johnson wrote:
>> On 2020-01-21 10:49, Baruch Siach wrote:
>>> On Tue, Jan 21, 2020 at 10:32:17AM -0700, Joel Johnson wrote:
 Add a unique entry for ClearFog Base variant, reflected in the
>board
 name and adjusted SerDes topology.

 Signed-off-by: Joel Johnson 

 ---

 v2 changes:
   - reworked based on Baruch's run-time TLV EEPROM detection series
 v3 changes:
   - rebased on mvebu merged run-time TLV EEPROM detection series
   - minor update to help test regarding runtime detection failures

 ---
  arch/arm/mach-mvebu/Kconfig|  2 ++
  board/solidrun/clearfog/Kconfig| 18 ++
  board/solidrun/clearfog/clearfog.c | 12 
  3 files changed, 32 insertions(+)
  create mode 100644 board/solidrun/clearfog/Kconfig

 diff --git a/arch/arm/mach-mvebu/Kconfig
>b/arch/arm/mach-mvebu/Kconfig
 index bc5eaa5a76..161dee937f 100644
 --- a/arch/arm/mach-mvebu/Kconfig
 +++ b/arch/arm/mach-mvebu/Kconfig
 @@ -280,4 +280,6 @@ config SECURED_MODE_CSK_INDEX
default 0
depends on SECURED_MODE_IMAGE

 +source "board/solidrun/clearfog/Kconfig"
 +
  endif
 diff --git a/board/solidrun/clearfog/Kconfig
 b/board/solidrun/clearfog/Kconfig
 new file mode 100644
 index 00..936d5918f8
 --- /dev/null
 +++ b/board/solidrun/clearfog/Kconfig
 @@ -0,0 +1,18 @@
 +menu "ClearFog configuration"
 +  depends on TARGET_CLEARFOG
 +
 +config TARGET_CLEARFOG_BASE
 +  bool "Use ClearFog Base static configuration"
 +  help
 +Use the ClearFog Base as the static configuration instead of
>the
 +default which uses the ClearFog Pro.
 +
 +Runtime board detection is always attempted and used if
 available. The
 +static configuration is used as a fallback in cases where
>runtime
 +detection is disabled, is not available in hardware, or
>otherwise
 fails.
 +
 +Only newer revisions of the ClearFog product line support
>runtime
 +detection via additional EEPROM hardware. This option enables
 selecting
 +the Base variant for older hardware revisions.
 +
 +endmenu
 diff --git a/board/solidrun/clearfog/clearfog.c
 b/board/solidrun/clearfog/clearfog.c
 index e268ef55a2..e77b9465d4 100644
 --- a/board/solidrun/clearfog/clearfog.c
 +++ b/board/solidrun/clearfog/clearfog.c
 @@ -47,7 +47,11 @@ static struct serdes_map board_serdes_map[] = {
{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 +#if defined (CONFIG_TARGET_CLEARFOG_BASE)
 +  {USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 +#else
{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
 +#endif
>>>
>>> I'd prefer run-time test instead of '#ifdefs' that IMO make the code
>harder
>>> to
>>> read. Something like this (build tested only):
>>>
>>> diff --git a/board/solidrun/clearfog/clearfog.c
>>> b/board/solidrun/clearfog/clearfog.c
>>> index e268ef55a2a0..202c60cb7841 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -55,7 +55,8 @@ int hws_board_topology_load(struct serdes_map
>>> **serdes_map_array, u8 *count)
>>>  {
>>> cf_read_tlv_data();
>>>
>>> -   if (sr_product_is(_tlv_data, "Clearfog GTR")) {
>>> +   if (sr_product_is(_tlv_data, "Clearfog GTR") ||
>>> +   CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE)) {
>>> board_serdes_map[0].serdes_type = PEX0;
>>> board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
>>> board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
>>> @@ -172,6 +173,9 @@ int checkboard(void)
>>>  {
>>> char *board = "ClearFog";
>>>
>>> +   if (CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
>>> +   board = "ClearFog Base";
>>> +
>>> cf_read_tlv_data();
>>> if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
>>> board = cf_tlv_data.tlv_product_name[0];
>>> @@ -194,7 +198,8 @@ int board_late_init(void)
>>>  {
>>> cf_read_tlv_data();
>>>
>>> -   if (sr_product_is(_tlv_data, "Clearfog Base"))
>>> +   if (sr_product_is(_tlv_data, "Clearfog Base") ||
>>> +   CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
>>> env_set("fdtfile", "armada-388-clearfog-base.dtb");
>>> else if (sr_product_is(_tlv_data, "Clearfog GTR S4"))
>>> env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
>>>
>>> What do you think?
>>>
>>> baruch
>>
>> I'll have to revisit and test to be sure, but I believe the reason I
>didn't go
>> that route is because I wasn't able to get the CONFIG_IS_ENABLED
>macro version
>> to trigger when building 

Re: [PATCH] env: another attempt at fixing SPL build failures

[Tom Rini]

On Sun, Jan 12, 2020 at 08:23:02PM +, Rasmus Villemoes wrote:
> On 11/01/2020 23.44, Rasmus Villemoes wrote:
> > On 10/01/2020 15.34, Tom Rini wrote:
> >> On Fri, Jan 10, 2020 at 02:28:54PM +, Rasmus Villemoes wrote:
> >>> On 15/12/2019 23.29, Rasmus Villemoes wrote:
>  I'm also seeing the build failure that commit
> 
>  7d4776545b env: solve compilation error in SPL
> 
> >>>
> >>> Yeah, I think this is a difference in how the linker works on ppc vs
> >>> arm. Doing
> >>>
> >>>
> >>> For reference, I have
> >>>
> >>> $ ${CROSS_COMPILE}ld --version
> >>> GNU ld (GNU Binutils for Ubuntu) 2.30
> >>
> >> Which SPL are you using on PowerPC?  There's the one based
> >> CONFIG_SPL_FRAMEWORK and the one that's not.  I suspect it's a framework
> >> vs not problem here rather than linker exactly.
> >>
> > 
> > No, it's nothing to do with SPL per se. 
> 
> OK, I think I found it. On powerpc, the .fixup section contains a
> reference to .data.rel.env_htab, and all of .fixup is kept (because of
> KEEP(*(.fixup))), so env_htab cannot get garbage collected. Hence
> anything that section refers to must also exist. So it's not a defect in
> ppc-ld vs arm-ld, it's just a consequence of ppc having that .fixup section.
> 
> So, the only way to fix that is by either making sure env_flags_validate
> exists in the link, or avoiding having env_htab being part of the link
> in the first place. My patch does the latter.

Thanks for digging in to the root cause on this.  I'll take a harder
look at your patch, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-marvell/master v2

[Tom Rini]

On Tue, Jan 21, 2020 at 04:00:01PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the 2nd batch of MVEBU related patches in this merge
> window:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 0/3] Ethernet support for Raspberry Pi 4

[Matthias Brugger]

On 22/01/2020 18:34, Andre Przywara wrote:
> On Wed, 22 Jan 2020 18:18:39 +0100
> Matthias Brugger  wrote:
> 
> Hi Matthias,
> 
>> On 17/01/2020 02:20, Andre Przywara wrote:
>>> This series adds Ethernet support for the Raspberry Pi 4. The SoC
>>> includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
>>> device (no USB anymore!). Patch 1 provides a driver for that. There does
>>> not seem to be publicly available documentation, so this is based on the
>>> Linux driver, but stripped down to just provide what U-Boot needs.
>>> Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
>>> MAC lives in, while patch 3 enables it in the respective defconfigs.
>>>
>>> This version addresses the comments by the diligent reviewers and testers,
>>> for a changelog see below.
>>> To see the individual changes as patches, refer to [1].
>>>
>>> Please have a look and test it, I hope this helps to simplify
>>> development, as you spare the SD card and its slot from heavy swapping.
>>>
>>> I dropped the Tested-by's, as there were changes in the code. Happy
>>> to reapply them when people confirm that it still works for them.
>>>   
>>
>> I having problems to actually boot a kernel when the genet driver is build 
>> into
>> U-Boot.
> 
> Ah! Sorry, I misread the former reports, I thought this was about booting 
> kernels in general, with mainline U-Boot, without this series.
> 
>> If I boot grub and linux-next from there, I get the following SError (when 
>> using
>> earlycon):
>> https://pastebin.com/c1sw2uZk
>>
>> If I skip grub and boot the kernel directly from the SD:
>> load mmc 0:1 $kernel_addr_r Image
>> load mmc 0:1 $fdt_addr_r bcm2711-rpi-4-b.dtb
>> setenv bootargs "earlycon=uart8250,mmio32,0xfe215040"
>> booti $kernel_addr_r - $fdt_addr_r
>>
>> Gives a similar result.
>>
>> Do you see similar issues?
> 
> I didn't manage to start some kernel even without this series, I think, but 
> didn't investigate further. I *loaded* several kernel images via TFTP and 
> verified them with md5sum.
> 

I think linux-next with defconfig should work.

> Some questions:
> - Does this happen even without touching the Ethernet in U-Boot at all (no 
> dhcp command, no tftpboot, etc.)?

Yes, as soon as the genet is compiled into U-Boot I'm not able to boot a Linux
kernel.

>   (I wonder if we have still DMA going on, even after the kernel already 
> started. But if we just call probe(), there shouldn't be much going on).

At least when we start grub, we are actually starting the genet. I played with
the DMA shutdown in bcmgenet_gmac_eth_stop() but wasn't lucky.

> - Does reverting patch 2/3 change anything?

That was my first bet, but it hangs the board when it tries to initialize the
network driver.

> - Does TFTP load work in grub? (net_bootp efinet0; set net_default_server= address>; linux (tftp)/Image-5.5-rc7 )

Yes that works, until you boot the kernel and you end up with a SError.

> 
> I will try to debug this later tonight.
> 

Thanks, if I can help you in any way, let me know.

Regards,
Matthias

> Thanks!
> Andre.
> 
>>
>> Regards,
>> Matthias
>>
>>> Cheers,
>>> Andre.
>>>
>>> [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v2
>>>
>>> Changelog v1 ... v2:
>>> - use native endianess functions when accessing MMIO registers
>>> - use dev_* DM wrappers for accessing devicetree data
>>> - round base and length for flush_dcache_range, plus a comment
>>> - check and round length for invalidate_cache_range
>>> - support RGMII_RXID PHY mode, to support mainline .dtb
>>>
>>> Amit Singh Tomar (3):
>>>   net: Add support for Broadcom GENETv5 Ethernet controller
>>>   rpi4: Update memory map to accommodate scb devices
>>>   rpi4: Enable GENET Ethernet controller
>>>
>>>  arch/arm/mach-bcm283x/init.c |   6 +-
>>>  configs/rpi_4_32b_defconfig  |   2 +
>>>  configs/rpi_4_defconfig  |   2 +
>>>  configs/rpi_arm64_defconfig  |   1 +
>>>  drivers/net/Kconfig  |   7 +
>>>  drivers/net/Makefile |   1 +
>>>  drivers/net/bcmgenet.c   | 722 
>>> +++
>>>  7 files changed, 738 insertions(+), 3 deletions(-)
>>>  create mode 100644 drivers/net/bcmgenet.c
>>>   
> 

Re: [RFC PATCH 0/5] arm: Restore minimal support for ST-Ericsson U8500 SoC

[Tom Rini]

On Wed, Jan 22, 2020 at 05:47:07PM +0100, Stephan Gerhold wrote:
> Hi Tom,
> 
> On Sat, Jan 04, 2020 at 06:45:14PM +0100, Stephan Gerhold wrote:
> > This patch series restores minimal U-Boot support for
> > the ST-Ericsson NovaThor U8500 SoC.
> > 
> > Previous support for U8500 was removed in
> > commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch")
> > since none of the boards were converted to generic boards
> > before the deadline.
> > 
> > The motivation for adding the SoC and board is explained in
> >   - Patch 3 ("arm: Add support for ST-Ericsson U8500 SoC") and
> >   - Patch 5 ("board: Add new Samsung "stemmy" board based on ST-Ericsson 
> > U8500")
> > 
> > I have additional patches for MMC, USB, display and the "stemmy"
> > board, that configure it to provide an Android fastboot interface
> > with similar functionality as the original Samsung bootloader.
> > Some of the patches require some additional work, so I thought
> > it is easier to start with some minimal changes first (only UART).
> > 
> > I think this makes the patch series quite straightforward,
> > with only ~225 new lines of C code, plus device tree and documentation.
> > The only patch that stands out with ~1.8k lines is the device tree
> > import, directly copied (without modification) from the Linux kernel.
> > 
> 
> Since we are approaching the end of the merge window,
> I was wondering if there is anything I can do to get this patch set
> applied for v2020.04?

Since you had marked it as RFC, I had marked it as such in patchwork and
overlooked it.  I'll take a look soon, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Andre Przywara]

On Wed, 22 Jan 2020 18:22:47 +0100
Daniel Schwierzeck  wrote:

Hi,

> Am 22.01.20 um 16:36 schrieb Andre Przywara:
> > On Wed, 22 Jan 2020 16:02:22 +0100
> > Daniel Schwierzeck  wrote:
> > 
> > Hi Daniel,
> >   
> >> Am 17.01.20 um 02:20 schrieb Andre Przywara:  
> >>> From: Amit Singh Tomar 
> >>>
> >>> The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs
> >>> and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4.
> >>> There is no publicly available documentation, so this driver is based
> >>> on the Linux driver. Compared to that the queue management is
> >>> drastically simplified, also we only support version 5 of the IP and
> >>> RGMII connections between MAC and PHY, as used on the RPi4.
> >>>
> >>> Signed-off-by: Amit Singh Tomar 
> >>> Reviewed-by: Andre Przywara 
> >>> [Andre: heavy cleanup and a few fixes]
> >>> Signed-off-by: Andre Przywara 
> >>> ---
> >>>  drivers/net/Kconfig|   7 +
> >>>  drivers/net/Makefile   |   1 +
> >>>  drivers/net/bcmgenet.c | 722 
> >>> +
> >>>  3 files changed, 730 insertions(+)
> >>>  create mode 100644 drivers/net/bcmgenet.c
> >>
> >> Reviewed-by: Daniel Schwierzeck   
> > 
> > Many thanks!
> >   
> >>>
> >>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> >>> index 01d087f229..4d1013c984 100644
> >>> --- a/drivers/net/Kconfig
> >>> +++ b/drivers/net/Kconfig
> >>> @@ -136,6 +136,13 @@ config BCM6368_ETH
> >>>   help
> >>> This driver supports the BCM6368 Ethernet MAC.
> >>>  
> >>> +config BCMGENET
> >>> + bool "BCMGENET V5 support"
> >>> + depends on DM_ETH
> >>
> >> maybe this should be limited to the supported SoC's?
> >>
> >> e.g.  depends on DM_ETH && ARCH_BCM283X  
> > 
> > Technically this would not be correct: Nothing in the driver *code* depends 
> > on the Broadcom 2711 SoC. It uses generic accessors for the MMIO registers 
> > and the probe function is using generic DM routines. The rest is GENET 
> > driver code, which would even work on other architectures (hence the 
> > endianess changes).
> > It would be a different story if we would take any 2711 specific shortcuts 
> > in the code, say poking some special hardcoded register to configure some 
> > clocks or the like.
> > 
> > Or is there any actual problem that you are thinking about, that would 
> > require this to be restricted?  
> 
> Without the Kconfig dependency the config entry for BCMGENET would
> always show up in "make menuconfig" under "Network devices".

Yes, that's the idea. Because it's a driver for some piece of IP. And older 
versions of this IP were used in MIPS chips, reportedly.

> Or BCMGENET
> could be automatically selected by a "make oldconfig"

I was under the impression that "default n" is the behaviour when no default 
line is specified? So oldconfig or defconfig would never enable those devices?

> or "make randconfig" in unrelated board configs.

For randconfig: Yes please, compile this driver in, to get more (compile) test 
coverage. Shouldn't hurt, and you probably don't want to use such an image.

> That doesn't make much sense if BCMGENET is only ever found in Broadcom SoC's.

I don't know that for sure, and I don't think that "makes sense" or "only ever 
found in..." is within the scope of Kconfig. It's purely about technical 
dependencies, like: contains assembly code, accesses BCM2711 specific 
registers, requires a framework, etc.

> Thus you should consider
> to limit the config option to the Broadcom platforms. Without that
> limitation you should add at least a "default n" line to not enable that
> driver per default on unrelated boards.

I understand this sentence from Documentation/kbuild/kconfig-language.txt like 
it does this already:
"The default value deliberately defaults to 'n' in order to avoid bloating the
 build. With few exceptions, new config options should not change this. The
 intent is for "make oldconfig" to add as little as possible to the config from
 release to release."

Did this happen to be compiled in for you?

Cheers,
Andre.


> 
> >   
> >>  
> >>> + select PHYLIB
> >>> + help
> >>> +   This driver supports the BCMGENET 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 30991834ec..6e0a68834d 100644
> >>> --- a/drivers/net/Makefile
> >>> +++ b/drivers/net/Makefile
> >>> @@ -8,6 +8,7 @@ obj-$(CONFIG_AG7XXX) += ag7xxx.o
> >>>  obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
> >>>  obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
> >>>  obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o
> >>> +obj-$(CONFIG_BCMGENET) += bcmgenet.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/bcmgenet.c b/drivers/net/bcmgenet.c
> >>> new file mode 100644
> >>> index 00..4f8f190071

Re: [PATCH v3 0/9] am57xx: Implement Android 10 boot flow

[Bajjuri, Praneeth]

+ Sam Protsenko's current email address

On 1/22/2020 11:51 AM, Bajjuri, Praneeth wrote:

Tom,

On 12/24/2019 1:54 PM, Sam Protsenko wrote:

Android 10 brings a lot of new requirements for bootloaders: [1]. This
patch series attempts to implement such a boot process on BeagleBoard
X15 platform. Some common code is added too, which can be reused later
for other platforms (see "abootimg" command and associated C API).

This patch series must be applied on top of these recently sent patches
by Eugeniu:

 [PATCH 0/3] cmd: dtimg: Rename to adtimg and refactor usage style

Changes in v3:
  - rename command to "abootimg" (requested by Simon Glass)
  - rework command interface (as discussed with Eugeniu)
  - add command documentation
  - address other comments



Since this series is functionally mature,
can this series be pulled as-is in the next merge window,
verified v3 with current aosp master and functionality is working
as expected.

the comments on changing to a more suitable names , adding a
new test script for the functionality can be done as a incremental
update on the top during the next cycle.




[1] https://source.android.com/devices/bootloader

Sam Protsenko (9):
   image: android: Add functions for handling dtb field
   image: android: Add routine to get dtbo params
   cmd: abootimg: Add abootimg command
   doc: android: Add documentation for Android Boot Image
   test/py: android: Add test for abootimg
   configs: am57xx_evm: Enable Android commands
   env: ti: boot: Respect slot_suffix in AVB commands
   env: ti: boot: Boot Android with dynamic partitions
   arm: ti: boot: Use correct dtb and dtbo on Android boot

  cmd/Kconfig |  10 +
  cmd/Makefile    |   1 +
  cmd/abootimg.c  | 242 +
  common/Makefile |   2 +-
  common/image-android.c  | 275 
  configs/am57xx_evm_defconfig    |   6 +
  configs/am57xx_hs_evm_defconfig |   6 +
  configs/am57xx_hs_evm_usb_defconfig |   6 +
  configs/sandbox_defconfig   |   1 +
  doc/android/boot-image.rst  | 154 +++
  include/configs/ti_armv7_common.h   |   7 +
  include/environment/ti/boot.h   | 146 ++-
  include/image.h |   6 +
  test/py/tests/test_android/test_abootimg.py | 159 +++
  14 files changed, 954 insertions(+), 67 deletions(-)
  create mode 100644 cmd/abootimg.c
  create mode 100644 doc/android/boot-image.rst
  create mode 100644 test/py/tests/test_android/test_abootimg.py

Re: [PATCH v3 0/9] am57xx: Implement Android 10 boot flow

[Bajjuri, Praneeth]

Tom,

On 12/24/2019 1:54 PM, Sam Protsenko wrote:

Android 10 brings a lot of new requirements for bootloaders: [1]. This
patch series attempts to implement such a boot process on BeagleBoard
X15 platform. Some common code is added too, which can be reused later
for other platforms (see "abootimg" command and associated C API).

This patch series must be applied on top of these recently sent patches
by Eugeniu:

 [PATCH 0/3] cmd: dtimg: Rename to adtimg and refactor usage style

Changes in v3:
  - rename command to "abootimg" (requested by Simon Glass)
  - rework command interface (as discussed with Eugeniu)
  - add command documentation
  - address other comments



Since this series is functionally mature,
can this series be pulled as-is in the next merge window,
verified v3 with current aosp master and functionality is working
as expected.

the comments on changing to a more suitable names , adding a
new test script for the functionality can be done as a incremental
update on the top during the next cycle.




[1] https://source.android.com/devices/bootloader

Sam Protsenko (9):
   image: android: Add functions for handling dtb field
   image: android: Add routine to get dtbo params
   cmd: abootimg: Add abootimg command
   doc: android: Add documentation for Android Boot Image
   test/py: android: Add test for abootimg
   configs: am57xx_evm: Enable Android commands
   env: ti: boot: Respect slot_suffix in AVB commands
   env: ti: boot: Boot Android with dynamic partitions
   arm: ti: boot: Use correct dtb and dtbo on Android boot

  cmd/Kconfig |  10 +
  cmd/Makefile|   1 +
  cmd/abootimg.c  | 242 +
  common/Makefile |   2 +-
  common/image-android.c  | 275 
  configs/am57xx_evm_defconfig|   6 +
  configs/am57xx_hs_evm_defconfig |   6 +
  configs/am57xx_hs_evm_usb_defconfig |   6 +
  configs/sandbox_defconfig   |   1 +
  doc/android/boot-image.rst  | 154 +++
  include/configs/ti_armv7_common.h   |   7 +
  include/environment/ti/boot.h   | 146 ++-
  include/image.h |   6 +
  test/py/tests/test_android/test_abootimg.py | 159 +++
  14 files changed, 954 insertions(+), 67 deletions(-)
  create mode 100644 cmd/abootimg.c
  create mode 100644 doc/android/boot-image.rst
  create mode 100644 test/py/tests/test_android/test_abootimg.py

Re: [PATCH] arm: Enable VIDEO_BPP32 on pinebook.

[Maxime Ripard]

On Sat, Jan 18, 2020 at 05:00:52PM -0500, Tom Rini wrote:
> On Sat, Jan 18, 2020 at 12:03:02PM -0800, Vagrant Cascadian wrote:
> > On 2020-01-18, Maxime Ripard wrote:
> > > On Sat, Jan 18, 2020 at 03:15:15AM -0800, Vagrant Cascadian wrote:
> > >> Video output on the pinebook LCD screen was broken by:
> > >>
> > >> commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional").
> > >>
> > >> Enable VIDEO_BPP32 which was previously enabled by default when
> > >> DM_VIDEO was set.
> > >>
> > >> Signed-off-by: Vagrant Cascadian 
> > >
> > > There's nothing really specific about the pinebook here, but it's
> > > needed for pretty much all the boards using DM_VIDEO (on Allwinner at
> > > least).
> > >
> > > You should add a kconfig select / default instead
> >
> > That would basically revert 2cc393f32fd9, and I figured there was a
> > reason for it...
> >
> > It wouldn't surprise me that other systems are affected, but I only
> > notice this issue on the pinebook (most of the systems I use are
> > headless), where it definitely needed to be fixed somehow.
> >
> > If there's a correct and more general fix, please propose it!
>
> Well, looking at 2cc393f32fd9 there are a number of platforms that
> enable more than one mode.  But maybe we should always have at least one
> mode?

Yeah, I guess that would make the most sense. My suggestions was
actually to enable it platform by platform, which wouldn't be a revert
and would fix all the sunxi boards at once.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH] imx: distinguish POR from POR+WDOG reset cause for first wd

[Fabio Estevam]

Hi Flavio,

On Wed, Jan 22, 2020 at 11:18 AM Flavio Suligoi  wrote:
>
> In some application the possibility to check if the reset
> is caused by a watchdog is essential, even if it occurs
> simultaneously with POR.
>
> Signed-off-by: Flavio Suligoi 
> ---
>  arch/arm/mach-imx/cpu.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
> index bfa85c6..ce0c663 100644
> --- a/arch/arm/mach-imx/cpu.c
> +++ b/arch/arm/mach-imx/cpu.c
> @@ -47,7 +47,6 @@ static char *get_reset_cause(void)
>  {
> switch (get_imx_reset_cause()) {
> case 0x1:
> -   case 0x00011:
> return "POR";
> case 0x4:
> return "CSU";
> @@ -59,6 +58,12 @@ static char *get_reset_cause(void)
>  #else
> return "WDOG";
>  #endif
> +   case 0x00011:
> +#ifdef CONFIG_MX7
> +   return "POR + WDOG1";
> +#else
> +   return "POR + WDOG";
> +#endif
> case 0x00020:
> return "JTAG HIGH-Z";
> case 0x00040:

If I understand this correctly your board has a WDOG_B pin connected
to the PMIC and when WDOG_B is asserted the PMIC is power cycled and
the system resets via POR.

Is this correct? If not, please describe exactly your setup and what
you are trying to achieve.

It seems that the current behavior is correct for me.

Thanks

Re: [PATCH v2 0/3] Ethernet support for Raspberry Pi 4

[Andre Przywara]

On Wed, 22 Jan 2020 18:18:39 +0100
Matthias Brugger  wrote:

Hi Matthias,

> On 17/01/2020 02:20, Andre Przywara wrote:
> > This series adds Ethernet support for the Raspberry Pi 4. The SoC
> > includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
> > device (no USB anymore!). Patch 1 provides a driver for that. There does
> > not seem to be publicly available documentation, so this is based on the
> > Linux driver, but stripped down to just provide what U-Boot needs.
> > Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
> > MAC lives in, while patch 3 enables it in the respective defconfigs.
> > 
> > This version addresses the comments by the diligent reviewers and testers,
> > for a changelog see below.
> > To see the individual changes as patches, refer to [1].
> > 
> > Please have a look and test it, I hope this helps to simplify
> > development, as you spare the SD card and its slot from heavy swapping.
> > 
> > I dropped the Tested-by's, as there were changes in the code. Happy
> > to reapply them when people confirm that it still works for them.
> >   
> 
> I having problems to actually boot a kernel when the genet driver is build 
> into
> U-Boot.

Ah! Sorry, I misread the former reports, I thought this was about booting 
kernels in general, with mainline U-Boot, without this series.

> If I boot grub and linux-next from there, I get the following SError (when 
> using
> earlycon):
> https://pastebin.com/c1sw2uZk
> 
> If I skip grub and boot the kernel directly from the SD:
> load mmc 0:1 $kernel_addr_r Image
> load mmc 0:1 $fdt_addr_r bcm2711-rpi-4-b.dtb
> setenv bootargs "earlycon=uart8250,mmio32,0xfe215040"
> booti $kernel_addr_r - $fdt_addr_r
> 
> Gives a similar result.
> 
> Do you see similar issues?

I didn't manage to start some kernel even without this series, I think, but 
didn't investigate further. I *loaded* several kernel images via TFTP and 
verified them with md5sum.

Some questions:
- Does this happen even without touching the Ethernet in U-Boot at all (no dhcp 
command, no tftpboot, etc.)?
  (I wonder if we have still DMA going on, even after the kernel already 
started. But if we just call probe(), there shouldn't be much going on).
- Does reverting patch 2/3 change anything?
- Does TFTP load work in grub? (net_bootp efinet0; set net_default_server=; linux (tftp)/Image-5.5-rc7 )

I will try to debug this later tonight.

Thanks!
Andre.

> 
> Regards,
> Matthias
> 
> > Cheers,
> > Andre.
> > 
> > [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v2
> > 
> > Changelog v1 ... v2:
> > - use native endianess functions when accessing MMIO registers
> > - use dev_* DM wrappers for accessing devicetree data
> > - round base and length for flush_dcache_range, plus a comment
> > - check and round length for invalidate_cache_range
> > - support RGMII_RXID PHY mode, to support mainline .dtb
> > 
> > Amit Singh Tomar (3):
> >   net: Add support for Broadcom GENETv5 Ethernet controller
> >   rpi4: Update memory map to accommodate scb devices
> >   rpi4: Enable GENET Ethernet controller
> > 
> >  arch/arm/mach-bcm283x/init.c |   6 +-
> >  configs/rpi_4_32b_defconfig  |   2 +
> >  configs/rpi_4_defconfig  |   2 +
> >  configs/rpi_arm64_defconfig  |   1 +
> >  drivers/net/Kconfig  |   7 +
> >  drivers/net/Makefile |   1 +
> >  drivers/net/bcmgenet.c   | 722 
> > +++
> >  7 files changed, 738 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/net/bcmgenet.c
> >   

Re: [PATCH v2 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Daniel Schwierzeck]

Am 22.01.20 um 16:36 schrieb Andre Przywara:
> On Wed, 22 Jan 2020 16:02:22 +0100
> Daniel Schwierzeck  wrote:
> 
> Hi Daniel,
> 
>> Am 17.01.20 um 02:20 schrieb Andre Przywara:
>>> From: Amit Singh Tomar 
>>>
>>> The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs
>>> and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4.
>>> There is no publicly available documentation, so this driver is based
>>> on the Linux driver. Compared to that the queue management is
>>> drastically simplified, also we only support version 5 of the IP and
>>> RGMII connections between MAC and PHY, as used on the RPi4.
>>>
>>> Signed-off-by: Amit Singh Tomar 
>>> Reviewed-by: Andre Przywara 
>>> [Andre: heavy cleanup and a few fixes]
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  drivers/net/Kconfig|   7 +
>>>  drivers/net/Makefile   |   1 +
>>>  drivers/net/bcmgenet.c | 722 
>>> +
>>>  3 files changed, 730 insertions(+)
>>>  create mode 100644 drivers/net/bcmgenet.c  
>>
>> Reviewed-by: Daniel Schwierzeck 
> 
> Many thanks!
> 
>>>
>>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>>> index 01d087f229..4d1013c984 100644
>>> --- a/drivers/net/Kconfig
>>> +++ b/drivers/net/Kconfig
>>> @@ -136,6 +136,13 @@ config BCM6368_ETH
>>> help
>>>   This driver supports the BCM6368 Ethernet MAC.
>>>  
>>> +config BCMGENET
>>> +   bool "BCMGENET V5 support"
>>> +   depends on DM_ETH  
>>
>> maybe this should be limited to the supported SoC's?
>>
>> e.g.  depends on DM_ETH && ARCH_BCM283X
> 
> Technically this would not be correct: Nothing in the driver *code* depends 
> on the Broadcom 2711 SoC. It uses generic accessors for the MMIO registers 
> and the probe function is using generic DM routines. The rest is GENET driver 
> code, which would even work on other architectures (hence the endianess 
> changes).
> It would be a different story if we would take any 2711 specific shortcuts in 
> the code, say poking some special hardcoded register to configure some clocks 
> or the like.
> 
> Or is there any actual problem that you are thinking about, that would 
> require this to be restricted?

Without the Kconfig dependency the config entry for BCMGENET would
always show up in "make menuconfig" under "Network devices". Or BCMGENET
could be automatically selected by a "make oldconfig" or "make
randconfig" in unrelated board configs. That doesn't make much sense if
BCMGENET is only ever found in Broadcom SoC's. Thus you should consider
to limit the config option to the Broadcom platforms. Without that
limitation you should add at least a "default n" line to not enable that
driver per default on unrelated boards.

> 
>>
>>> +   select PHYLIB
>>> +   help
>>> + This driver supports the BCMGENET 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 30991834ec..6e0a68834d 100644
>>> --- a/drivers/net/Makefile
>>> +++ b/drivers/net/Makefile
>>> @@ -8,6 +8,7 @@ obj-$(CONFIG_AG7XXX) += ag7xxx.o
>>>  obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
>>>  obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
>>>  obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o
>>> +obj-$(CONFIG_BCMGENET) += bcmgenet.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/bcmgenet.c b/drivers/net/bcmgenet.c
>>> new file mode 100644
>>> index 00..4f8f190071
>>> --- /dev/null
>>> +++ b/drivers/net/bcmgenet.c
>>> @@ -0,0 +1,722 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2019 Amit Singh Tomar 
>>> + *
>>> + * Driver for Broadcom GENETv5 Ethernet controller (as found on the RPi4)
>>> + * This driver is based on the Linux driver:
>>> + *  drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> + *  which is: Copyright (c) 2014-2017 Broadcom
>>> + *
>>> + * The hardware supports multiple queues (16 priority queues and one
>>> + * default queue), both for RX and TX. There are 256 DMA descriptors (both
>>> + * for TX and RX), and they live in MMIO registers. The hardware allows
>>> + * assigning descriptor ranges to queues, but we choose the most simple 
>>> setup:
>>> + * All 256 descriptors are assigned to the default queue (#16).
>>> + * Also the Linux driver supports multiple generations of the MAC, whereas
>>> + * we only support v5, as used in the Raspberry Pi 4.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* Register definitions derived from Linux source */
>>> +#define SYS_REV_CTRL   0x00
>>> +
>>> +#define SYS_PORT_CTRL  0x04
>>> +#define 

Re: [PATCH v2 0/3] Ethernet support for Raspberry Pi 4

[Matthias Brugger]

Hi Andre,
Hi All,


On 17/01/2020 02:20, Andre Przywara wrote:
> This series adds Ethernet support for the Raspberry Pi 4. The SoC
> includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
> device (no USB anymore!). Patch 1 provides a driver for that. There does
> not seem to be publicly available documentation, so this is based on the
> Linux driver, but stripped down to just provide what U-Boot needs.
> Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
> MAC lives in, while patch 3 enables it in the respective defconfigs.
> 
> This version addresses the comments by the diligent reviewers and testers,
> for a changelog see below.
> To see the individual changes as patches, refer to [1].
> 
> Please have a look and test it, I hope this helps to simplify
> development, as you spare the SD card and its slot from heavy swapping.
> 
> I dropped the Tested-by's, as there were changes in the code. Happy
> to reapply them when people confirm that it still works for them.
> 

I having problems to actually boot a kernel when the genet driver is build into
U-Boot.

If I boot grub and linux-next from there, I get the following SError (when using
earlycon):
https://pastebin.com/c1sw2uZk

If I skip grub and boot the kernel directly from the SD:
load mmc 0:1 $kernel_addr_r Image
load mmc 0:1 $fdt_addr_r bcm2711-rpi-4-b.dtb
setenv bootargs "earlycon=uart8250,mmio32,0xfe215040"
booti $kernel_addr_r - $fdt_addr_r

Gives a similar result.

Do you see similar issues?

Regards,
Matthias

> Cheers,
> Andre.
> 
> [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v2
> 
> Changelog v1 ... v2:
> - use native endianess functions when accessing MMIO registers
> - use dev_* DM wrappers for accessing devicetree data
> - round base and length for flush_dcache_range, plus a comment
> - check and round length for invalidate_cache_range
> - support RGMII_RXID PHY mode, to support mainline .dtb
> 
> Amit Singh Tomar (3):
>   net: Add support for Broadcom GENETv5 Ethernet controller
>   rpi4: Update memory map to accommodate scb devices
>   rpi4: Enable GENET Ethernet controller
> 
>  arch/arm/mach-bcm283x/init.c |   6 +-
>  configs/rpi_4_32b_defconfig  |   2 +
>  configs/rpi_4_defconfig  |   2 +
>  configs/rpi_arm64_defconfig  |   1 +
>  drivers/net/Kconfig  |   7 +
>  drivers/net/Makefile |   1 +
>  drivers/net/bcmgenet.c   | 722 
> +++
>  7 files changed, 738 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/bcmgenet.c
> 

Re: [PATCH v2 4/4] board_f.c: Insure 16 alignment of start_addr_sp and reserved memory

[Stephen Warren]

On 1/22/20 6:52 AM, Patrick Delaunay wrote:

Add a function reserve_sp() to reserved memory with 16 bits alignment
after the stack pointer (gd->start_addr_sp) and use this new function
in board_f.c to reserve all the memory area (malloc, board, gd, fdt,
bootstage, stacks).

This 16 byte alignment is needed for cast on struct pointer
for the reserved memory, for example:
+ x86_64 ABI: https://reviews.llvm.org/D30049: 16 bytes
+ ARMv8 Instruction Set Overview: quad word, 16 bytes

An other alignment value could be needed for other architecture.



diff --git a/common/board_f.c b/common/board_f.c


  
+/*

+ * reserve after start_addr_sp the requested size and make the stack pointer
+ * 16-byte aligned, this alignment is needed for cast on the reserved memory
+ * ref = x86_64 ABI: https://reviews.llvm.org/D30049: 16 bytes
+ * = ARMv8 Instruction Set Overview: quad word, 16 bytes
+ */
+static unsigned long reserve_sp(size_t size)


Bikeshed: Not sure this name is very description. Perhaps 
reserve_stack_aligned() would be better. Not a big deal though. Patches 
1,4 look fine otherwise.

Re: [PATCH v2 1/4] board_f.c: Insure gd->new_bootstage alignment

[Stephen Warren]

On 1/22/20 6:52 AM, Patrick Delaunay wrote:

From: Patrice Chotard 

In reserve_bootstage(), in case size is odd, gd->new_bootstage
is not aligned. In bootstage_relocate(), the platform hangs when
getting access to data->record[i].name.
To avoid this issue, make gd->new_bootstage 16 byte aligned.

To insure that new_bootstage is 16 byte aligned (at least needed for
x86_64 and ARMv8) and new_bootstage starts down to get enough space,
ALIGN_DOWN macro is used.



diff --git a/common/board_f.c b/common/board_f.c
index d66afb37ca..e21f533634 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -562,6 +562,11 @@ static int reserve_bootstage(void)
int size = bootstage_get_size();
  
  	gd->start_addr_sp -= size;

+   /*
+* Insure that start_addr_sp is aligned down to reserve enough


Nit: Ensure not insure (a pet peeve of mine!)


+* space for new_bootstage
+*/
+   gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp, 16);
gd->new_bootstage = map_sysmem(gd->start_addr_sp, size);
debug("Reserving %#x Bytes for bootstage at: %08lx\n", size,
  gd->start_addr_sp);

Re: [RFC PATCH 0/5] arm: Restore minimal support for ST-Ericsson U8500 SoC

[Stephan Gerhold]

Hi Tom,

On Sat, Jan 04, 2020 at 06:45:14PM +0100, Stephan Gerhold wrote:
> This patch series restores minimal U-Boot support for
> the ST-Ericsson NovaThor U8500 SoC.
> 
> Previous support for U8500 was removed in
> commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch")
> since none of the boards were converted to generic boards
> before the deadline.
> 
> The motivation for adding the SoC and board is explained in
>   - Patch 3 ("arm: Add support for ST-Ericsson U8500 SoC") and
>   - Patch 5 ("board: Add new Samsung "stemmy" board based on ST-Ericsson 
> U8500")
> 
> I have additional patches for MMC, USB, display and the "stemmy"
> board, that configure it to provide an Android fastboot interface
> with similar functionality as the original Samsung bootloader.
> Some of the patches require some additional work, so I thought
> it is easier to start with some minimal changes first (only UART).
> 
> I think this makes the patch series quite straightforward,
> with only ~225 new lines of C code, plus device tree and documentation.
> The only patch that stands out with ~1.8k lines is the device tree
> import, directly copied (without modification) from the Linux kernel.
> 

Since we are approaching the end of the merge window,
I was wondering if there is anything I can do to get this patch set
applied for v2020.04?

Thanks,
Stephan

> 
> Stephan Gerhold (5):
>   timer: Add driver for Nomadik Multi Timer Unit (MTU)
>   arm: dts: Import device tree for ST-Ericsson Ux500
>   arm: Add support for ST-Ericsson U8500 SoC
>   MAINTAINERS: Add ARM U8500
>   board: Add new Samsung "stemmy" board based on ST-Ericsson U8500
> 
>  MAINTAINERS|8 +
>  arch/arm/Kconfig   |   20 +
>  arch/arm/Makefile  |1 +
>  arch/arm/dts/Makefile  |2 +
>  arch/arm/dts/ste-ab8500.dtsi   |  328 ++
>  arch/arm/dts/ste-ab8505.dtsi   |  275 +
>  arch/arm/dts/ste-dbx5x0-u-boot.dtsi|   29 +
>  arch/arm/dts/ste-dbx5x0.dtsi   | 1144 
>  arch/arm/dts/ste-ux500-samsung-stemmy.dts  |   20 +
>  arch/arm/include/asm/gpio.h|2 +-
>  arch/arm/mach-u8500/Kconfig|   27 +
>  arch/arm/mach-u8500/Makefile   |4 +
>  arch/arm/mach-u8500/cache.c|   37 +
>  arch/arm/mach-u8500/cpuinfo.c  |   25 +
>  board/ste/stemmy/Kconfig   |   12 +
>  board/ste/stemmy/MAINTAINERS   |6 +
>  board/ste/stemmy/Makefile  |2 +
>  board/ste/stemmy/README|   49 +
>  board/ste/stemmy/stemmy.c  |   18 +
>  configs/stemmy_defconfig   |   18 +
>  drivers/timer/Kconfig  |9 +
>  drivers/timer/Makefile |1 +
>  drivers/timer/nomadik-mtu-timer.c  |  114 ++
>  include/configs/stemmy.h   |   29 +
>  include/dt-bindings/arm/ux500_pm_domains.h |   15 +
>  include/dt-bindings/clock/ste-ab8500.h |   12 +
>  include/dt-bindings/mfd/dbx500-prcmu.h |   84 ++
>  27 files changed, 2290 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/ste-ab8500.dtsi
>  create mode 100644 arch/arm/dts/ste-ab8505.dtsi
>  create mode 100644 arch/arm/dts/ste-dbx5x0-u-boot.dtsi
>  create mode 100644 arch/arm/dts/ste-dbx5x0.dtsi
>  create mode 100644 arch/arm/dts/ste-ux500-samsung-stemmy.dts
>  create mode 100644 arch/arm/mach-u8500/Kconfig
>  create mode 100644 arch/arm/mach-u8500/Makefile
>  create mode 100644 arch/arm/mach-u8500/cache.c
>  create mode 100644 arch/arm/mach-u8500/cpuinfo.c
>  create mode 100644 board/ste/stemmy/Kconfig
>  create mode 100644 board/ste/stemmy/MAINTAINERS
>  create mode 100644 board/ste/stemmy/Makefile
>  create mode 100644 board/ste/stemmy/README
>  create mode 100644 board/ste/stemmy/stemmy.c
>  create mode 100644 configs/stemmy_defconfig
>  create mode 100644 drivers/timer/nomadik-mtu-timer.c
>  create mode 100644 include/configs/stemmy.h
>  create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h
>  create mode 100644 include/dt-bindings/clock/ste-ab8500.h
>  create mode 100644 include/dt-bindings/mfd/dbx500-prcmu.h
> 
> -- 
> 2.24.1
> 

Re: [PATCH v3 02/10] arm: k3: Add support for loading non linux remote cores

[Andrew F. Davis]

On 1/21/20 8:10 PM, keerthy wrote:
> 
> 
> On 1/21/2020 6:26 PM, Andrew F. Davis wrote:
>> On 1/21/20 6:07 AM, Keerthy wrote:
>>> Add MAIN domain R5FSS0 remoteproc support from spl. This enables
>>> loading the elf firmware in SPL and starting the remotecore.
>>>
>>> In order to start the core, there should be a file with path
>>> "/lib/firmware/j7-main-r5f0_0-fw" under filesystem
>>> of respective boot mode.
>>>
>>> Signed-off-by: Keerthy 
>>> Signed-off-by: Lokesh Vutla 
>>> [Guard start_non_linux_remote_cores under CONFIG_FS_LOADER]
>>> Signed-off-by: Andreas Dannenberg 
>>> ---
>>>   arch/arm/mach-k3/common.c | 84 ---
>>>   arch/arm/mach-k3/common.h |  2 +
>>>   arch/arm/mach-k3/j721e_init.c | 34 ++
>>>   3 files changed, 115 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
>>> index 8d1529062d..f0ac0c39f1 100644
>>> --- a/arch/arm/mach-k3/common.c
>>> +++ b/arch/arm/mach-k3/common.c
>>> @@ -16,6 +16,10 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>     struct ti_sci_handle *get_ti_sci_handle(void)
>>>   {
>>> @@ -57,6 +61,74 @@ int early_console_init(void)
>>>   #endif
>>>     #ifdef CONFIG_SYS_K3_SPL_ATF
>>> +
>>> +void init_env(void)
>>> +{
>>> +#ifdef CONFIG_SPL_ENV_SUPPORT
>>> +    char *part;
>>> +
>>> +    env_init();
>>> +    env_load();
>>> +    switch (spl_boot_device()) {
>>> +    case BOOT_DEVICE_MMC2:
>>> +    part = env_get("bootpart");
>>> +    env_set("storage_interface", "mmc");
>>> +    env_set("fw_dev_part", part);
>>> +    break;
>>> +    case BOOT_DEVICE_SPI:
>>> +    env_set("storage_interface", "ubi");
>>> +    env_set("fw_ubi_mtdpart", "UBI");
>>> +    env_set("fw_ubi_volume", "UBI0");
>>> +    break;
>>> +    default:
>>> +    printf("%s from device %u not supported!\n",
>>> +   __func__, spl_boot_device());
>>
>>
>> This will print for almost every boot mode..
> 
> I can keep this under debug.
> 
>>
>>
>>> +    return;
>>> +    }
>>> +#endif
>>> +}
>>> +
>>> +#ifdef CONFIG_FS_LOADER
>>> +int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
>>> +{
>>> +    struct udevice *fsdev;
>>> +    char *name = NULL;
>>> +    int size = 0;
>>> +
>>> +    *loadaddr = 0;
>>> +#ifdef CONFIG_SPL_ENV_SUPPORT
>>> +    switch (spl_boot_device()) {
>>> +    case BOOT_DEVICE_MMC2:
>>> +    name = env_get(name_fw);
>>> +    *loadaddr = env_get_hex(name_loadaddr, *loadaddr);
>>> +    break;
>>> +    default:
>>> +    printf("Loading rproc fw image from device %u not
>>> supported!\n",
>>> +   spl_boot_device());
>>
>>
>> This whole thing seems very MMC specific, if early firmware loading is
>> important it should work for all boot modes. Find a way to include it in
>> the next boot stage FIT image (tispl.bin) so it works for all modes.
> 
> That was not NAKd. We are going with fs_loader approach.
> 


When, where, link?


>>
>>
>>> +    return 0;
>>> +    }
>>> +#endif
>>> +    if (!*loadaddr)
>>> +    return 0;
>>> +
>>> +    if (!uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
>>> +    size = request_firmware_into_buf(fsdev, name, (void
>>> *)*loadaddr,
>>> + 0, 0);
>>> +    }
>>> +
>>> +    return size;
>>> +}
>>> +#else
>>> +int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
>>> +{
>>> +    return 0;
>>> +}
>>> +#endif
>>> +
>>> +__weak void start_non_linux_remote_cores(void)
>>> +{
>>> +}
>>> +
>>>   void __noreturn jump_to_image_no_args(struct spl_image_info
>>> *spl_image)
>>>   {
>>>   struct ti_sci_handle *ti_sci = get_ti_sci_handle();
>>> @@ -65,15 +137,17 @@ void __noreturn jump_to_image_no_args(struct
>>> spl_image_info *spl_image)
>>>   /* Release all the exclusive devices held by SPL before
>>> starting ATF */
>>>   ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
>>>   +    ret = rproc_init();
>>> +    if (ret)
>>> +    panic("rproc failed to be initialized (%d)\n", ret);
>>> +
>>> +    init_env();
>>> +    start_non_linux_remote_cores();
>>> +
>>>   /*
>>>    * It is assumed that remoteproc device 1 is the corresponding
>>>    * Cortex-A core which runs ATF. Make sure DT reflects the same.
>>>    */
>>> -    ret = rproc_dev_init(1);
>>> -    if (ret)
>>> -    panic("%s: ATF failed to initialize on rproc (%d)\n", __func__,
>>> -  ret);
>>> -
>>
>>
>> Where did this code go?
> 
> rproc_init takes care of that.
> 


Is that new behavior then? It should be it's own patch with a commit
message about that.


>>
>>
>>>   ret = rproc_load(1, spl_image->entry_point, 0x200);
>>>   if (ret)
>>>   panic("%s: ATF failed to load on rproc (%d)\n", __func__,
>>> ret);
>>> diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
>>> index d8b34fe060..42fb8ee6e7 100644
>>> --- 

Re: [Patchv4 3/3] arm: dts: Add cd-gpio for eMMC

[Anand Moon]

Hi Neil,

On Wed, 22 Jan 2020 at 17:45, Neil Armstrong  wrote:
>
> Hi,
>
> On 22/01/2020 13:06, Anand Moon wrote:
> > Add cd-gpio property for eMMC node.
> >
> > Signed-off-by: Anand Moon 
> > ---
> > New patch in this series
> > ---
> >  arch/arm/dts/meson-g12b-odroid-n2.dts | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dts 
> > b/arch/arm/dts/meson-g12b-odroid-n2.dts
> > index 888429b1cc..23ec14abe7 100644
> > --- a/arch/arm/dts/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm/dts/meson-g12b-odroid-n2.dts
> > @@ -449,6 +449,7 @@
> >   max-frequency = <2>;
> >   disable-wp;
> >
> > + cd-gpios = < GPIOH_7 GPIO_ACTIVE_LOW>; /* eMMC_nDET */
> >   mmc-pwrseq = <_pwrseq>;
> >   vmmc-supply = <_3v3>;
> >   vqmmc-supply = <_1v8>;
> >
>
> If it's missing, submit it to linux-amlogic and move it to the -u-boot.dtsi 
> file.
>
> Neil

Thanks for your review.
Ok I will submit this patch to linux-amlogic

-Anand

Re: [Patchv4 2/3] arm: dts: Add mmc alias to avoid warning

[Anand Moon]

Hi Neil,

On Wed, 22 Jan 2020 at 17:44, Neil Armstrong  wrote:
>
>
> Hi,
>
> On 22/01/2020 13:06, Anand Moon wrote:
> > Add missing mmc alias to dts nodes to avoid
> > below debug warning.
> >
> > mmc_bind: alias ret=-2, devnum=-1
> > mmc_bind: alias ret=-2, devnum=-1
> >
> > Signed-off-by: Anand Moon 
> > ---
> >  arch/arm/dts/meson-axg-s400.dts   | 2 ++
> >  arch/arm/dts/meson-g12a-sei510.dts| 3 +++
> >  arch/arm/dts/meson-g12a-u200.dts  | 3 +++
> >  arch/arm/dts/meson-g12b-odroid-n2.dts | 3 +++
> >  arch/arm/dts/meson-gxbb-odroidc2.dts  | 3 +++
> >  arch/arm/dts/meson-gxbb-p20x.dtsi | 3 +++
> >  arch/arm/dts/meson-gxl-s805x-libretech-ac.dts | 3 +++
> >  arch/arm/dts/meson-gxl-s905x-p212.dtsi| 3 +++
> >  arch/arm/dts/meson-gxm-khadas-vim2.dts| 3 +++
> >  arch/arm/dts/meson-sm1-sei610.dts | 3 +++
> >  10 files changed, 29 insertions(+)
> >
> > diff --git a/arch/arm/dts/meson-axg-s400.dts 
> > b/arch/arm/dts/meson-axg-s400.dts
> > index 18778ada7b..b0192a9720 100644
> > --- a/arch/arm/dts/meson-axg-s400.dts
> > +++ b/arch/arm/dts/meson-axg-s400.dts
> > @@ -58,6 +58,8 @@
> >   aliases {
> >   serial0 = _AO;
> >   serial1 = _A;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   linein: audio-codec@0 {
> > diff --git a/arch/arm/dts/meson-g12a-sei510.dts 
> > b/arch/arm/dts/meson-g12a-sei510.dts
> > index c7a8736885..0e6378a320 100644
> > --- a/arch/arm/dts/meson-g12a-sei510.dts
> > +++ b/arch/arm/dts/meson-g12a-sei510.dts
> > @@ -31,6 +31,9 @@
> >   aliases {
> >   serial0 = _AO;
> >   ethernet0 = 
> > + mmc0 = _emmc_a;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   mono_dac: audio-codec-0 {
> > diff --git a/arch/arm/dts/meson-g12a-u200.dts 
> > b/arch/arm/dts/meson-g12a-u200.dts
> > index 8551fbd4a4..88b4d365f8 100644
> > --- a/arch/arm/dts/meson-g12a-u200.dts
> > +++ b/arch/arm/dts/meson-g12a-u200.dts
> > @@ -16,6 +16,9 @@
> >   aliases {
> >   serial0 = _AO;
> >   ethernet0 = 
> > + mmc0 = _emmc_a;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   chosen {
> > diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dts 
> > b/arch/arm/dts/meson-g12b-odroid-n2.dts
> > index 42f1540575..888429b1cc 100644
> > --- a/arch/arm/dts/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm/dts/meson-g12b-odroid-n2.dts
> > @@ -18,6 +18,9 @@
> >   aliases {
> >   serial0 = _AO;
> >   ethernet0 = 
> > + mmc0 = _emmc_a;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   chosen {
> > diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts 
> > b/arch/arm/dts/meson-gxbb-odroidc2.dts
> > index 54954b314a..1436002013 100644
> > --- a/arch/arm/dts/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
> > @@ -17,6 +17,9 @@
> >   aliases {
> >   serial0 = _AO;
> >   ethernet0 = 
> > + mmc0 = _emmc_a;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   chosen {
> > diff --git a/arch/arm/dts/meson-gxbb-p20x.dtsi 
> > b/arch/arm/dts/meson-gxbb-p20x.dtsi
> > index 0be0f2a5d2..d55f5e1abb 100644
> > --- a/arch/arm/dts/meson-gxbb-p20x.dtsi
> > +++ b/arch/arm/dts/meson-gxbb-p20x.dtsi
> > @@ -11,6 +11,9 @@
> >   aliases {
> >   serial0 = _AO;
> >   ethernet0 = 
> > + mmc0 = _emmc_a;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   chosen {
> > diff --git a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts 
> > b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> > index 82b1c48511..6422e11e5e 100644
> > --- a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> > +++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> > @@ -20,6 +20,9 @@
> >   serial0 = _AO;
> >   ethernet0 = 
> >   spi0 = 
> > + mmc0 = _emmc_a;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   chosen {
> > diff --git a/arch/arm/dts/meson-gxl-s905x-p212.dtsi 
> > b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> > index a1b31013ab..d712e9fa1d 100644
> > --- a/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> > +++ b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> > @@ -17,6 +17,9 @@
> >   serial0 = _AO;
> >   serial1 = _A;
> >   ethernet0 = 
> > + mmc0 = _emmc_a;
> > + mmc1 = _emmc_b;
> > + mmc2 = _emmc_c;
> >   };
> >
> >   chosen {
> > diff --git a/arch/arm/dts/meson-gxm-khadas-vim2.dts 
> > b/arch/arm/dts/meson-gxm-khadas-vim2.dts
> > index 782e9edac8..723061f0e2 100644
> > --- a/arch/arm/dts/meson-gxm-khadas-vim2.dts
> > +++ 

[BUG] binman: Add a library to access binman entries

[Frank Wunderlich]

Hi,

this Patch seems to break init-chain at least on bpi-r64 if BINMAN_FDT not 
disabled (enabled by default). adding some code for debugging

38 int binman_init(void)
39 {
40 binman = malloc(sizeof(struct binman_info));
41 printf("%s:%d",__FUNCTION__,__LINE__);
42 if (!binman)
43 return log_msg_ret("space for binman", -ENOMEM);
44 printf("%s:%d",__FUNCTION__,__LINE__);
45 binman->image = ofnode_path("/binman");
46 printf("%s:%d",__FUNCTION__,__LINE__);
47 if (!ofnode_valid(binman->image))
48 return log_msg_ret("binman node", -EINVAL); <<< this 
seems to break init-flow
49
50 printf("%s:%d",__FUNCTION__,__LINE__);
51 return 0;
52 }

results in this:

binman_init:41binman_init:44binman_init:46initcall sequence 4ffd2588 
failed at call 41e0cdec (err=-22)

regards Frank

Re: [PATCH v2 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Andre Przywara]

On Wed, 22 Jan 2020 16:02:22 +0100
Daniel Schwierzeck  wrote:

Hi Daniel,

> Am 17.01.20 um 02:20 schrieb Andre Przywara:
> > From: Amit Singh Tomar 
> > 
> > The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs
> > and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4.
> > There is no publicly available documentation, so this driver is based
> > on the Linux driver. Compared to that the queue management is
> > drastically simplified, also we only support version 5 of the IP and
> > RGMII connections between MAC and PHY, as used on the RPi4.
> > 
> > Signed-off-by: Amit Singh Tomar 
> > Reviewed-by: Andre Przywara 
> > [Andre: heavy cleanup and a few fixes]
> > Signed-off-by: Andre Przywara 
> > ---
> >  drivers/net/Kconfig|   7 +
> >  drivers/net/Makefile   |   1 +
> >  drivers/net/bcmgenet.c | 722 
> > +
> >  3 files changed, 730 insertions(+)
> >  create mode 100644 drivers/net/bcmgenet.c  
> 
> Reviewed-by: Daniel Schwierzeck 

Many thanks!

> > 
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 01d087f229..4d1013c984 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -136,6 +136,13 @@ config BCM6368_ETH
> > help
> >   This driver supports the BCM6368 Ethernet MAC.
> >  
> > +config BCMGENET
> > +   bool "BCMGENET V5 support"
> > +   depends on DM_ETH  
> 
> maybe this should be limited to the supported SoC's?
> 
> e.g.  depends on DM_ETH && ARCH_BCM283X

Technically this would not be correct: Nothing in the driver *code* depends on 
the Broadcom 2711 SoC. It uses generic accessors for the MMIO registers and the 
probe function is using generic DM routines. The rest is GENET driver code, 
which would even work on other architectures (hence the endianess changes).
It would be a different story if we would take any 2711 specific shortcuts in 
the code, say poking some special hardcoded register to configure some clocks 
or the like.

Or is there any actual problem that you are thinking about, that would require 
this to be restricted?

> 
> > +   select PHYLIB
> > +   help
> > + This driver supports the BCMGENET 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 30991834ec..6e0a68834d 100644
> > --- a/drivers/net/Makefile
> > +++ b/drivers/net/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_AG7XXX) += ag7xxx.o
> >  obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
> >  obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
> >  obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o
> > +obj-$(CONFIG_BCMGENET) += bcmgenet.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/bcmgenet.c b/drivers/net/bcmgenet.c
> > new file mode 100644
> > index 00..4f8f190071
> > --- /dev/null
> > +++ b/drivers/net/bcmgenet.c
> > @@ -0,0 +1,722 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2019 Amit Singh Tomar 
> > + *
> > + * Driver for Broadcom GENETv5 Ethernet controller (as found on the RPi4)
> > + * This driver is based on the Linux driver:
> > + *  drivers/net/ethernet/broadcom/genet/bcmgenet.c
> > + *  which is: Copyright (c) 2014-2017 Broadcom
> > + *
> > + * The hardware supports multiple queues (16 priority queues and one
> > + * default queue), both for RX and TX. There are 256 DMA descriptors (both
> > + * for TX and RX), and they live in MMIO registers. The hardware allows
> > + * assigning descriptor ranges to queues, but we choose the most simple 
> > setup:
> > + * All 256 descriptors are assigned to the default queue (#16).
> > + * Also the Linux driver supports multiple generations of the MAC, whereas
> > + * we only support v5, as used in the Raspberry Pi 4.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Register definitions derived from Linux source */
> > +#define SYS_REV_CTRL   0x00
> > +
> > +#define SYS_PORT_CTRL  0x04
> > +#define PORT_MODE_EXT_GPHY 3
> > +
> > +#define GENET_SYS_OFF  0x
> > +#define SYS_RBUF_FLUSH_CTRL(GENET_SYS_OFF  + 0x08)
> > +#define SYS_TBUF_FLUSH_CTRL(GENET_SYS_OFF  + 0x0c)
> > +
> > +#define GENET_EXT_OFF  0x0080
> > +#define EXT_RGMII_OOB_CTRL (GENET_EXT_OFF + 0x0c)
> > +#define RGMII_LINK BIT(4)
> > +#define OOB_DISABLEBIT(5)
> > +#define RGMII_MODE_EN  BIT(6)
> > +#define ID_MODE_DISBIT(16)
> > +
> > +#define GENET_RBUF_OFF 0x0300
> 

[RFC PATCH 1/4] x86: apl: Add the term "Interrupt Timer Subsystem" to ITSS files

[Wolfgang Wallner]

ITSS stands for "Interrupt Timer Subsystem", so add that term to the
description of the relevant files.

Signed-off-by: Wolfgang Wallner 
---
ITSS stands for "Interrupt Timer Subsystem", at least according to
coreboot [1].

[1] https://coreboot.org/status/kconfig-options.html

 arch/x86/cpu/apollolake/itss.c  | 2 +-
 arch/x86/include/asm/arch-apollolake/itss.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/cpu/apollolake/itss.c b/arch/x86/cpu/apollolake/itss.c
index 8789f8e6bb..95c9ebddc1 100644
--- a/arch/x86/cpu/apollolake/itss.c
+++ b/arch/x86/cpu/apollolake/itss.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Something to do with Interrupts, but I don't know what ITSS stands for
+ * Interrupt Timer Subsystem
  *
  * Copyright (C) 2017 Intel Corporation.
  * Copyright (C) 2017 Siemens AG
diff --git a/arch/x86/include/asm/arch-apollolake/itss.h 
b/arch/x86/include/asm/arch-apollolake/itss.h
index 1e29503974..c75d8fe8c2 100644
--- a/arch/x86/include/asm/arch-apollolake/itss.h
+++ b/arch/x86/include/asm/arch-apollolake/itss.h
@@ -1,5 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
+ * Interrupt Timer Subsystem
+ *
  * Copyright (C) 2017 Intel Corporation.
  * Copyright 2019 Google LLC
  *
-- 
2.25.0

Re: [PATCH v2 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Daniel Schwierzeck]

Am 17.01.20 um 02:20 schrieb Andre Przywara:
> From: Amit Singh Tomar 
> 
> The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs
> and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4.
> There is no publicly available documentation, so this driver is based
> on the Linux driver. Compared to that the queue management is
> drastically simplified, also we only support version 5 of the IP and
> RGMII connections between MAC and PHY, as used on the RPi4.
> 
> Signed-off-by: Amit Singh Tomar 
> Reviewed-by: Andre Przywara 
> [Andre: heavy cleanup and a few fixes]
> Signed-off-by: Andre Przywara 
> ---
>  drivers/net/Kconfig|   7 +
>  drivers/net/Makefile   |   1 +
>  drivers/net/bcmgenet.c | 722 
> +
>  3 files changed, 730 insertions(+)
>  create mode 100644 drivers/net/bcmgenet.c

Reviewed-by: Daniel Schwierzeck 

nits below

> 
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 01d087f229..4d1013c984 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -136,6 +136,13 @@ config BCM6368_ETH
>   help
> This driver supports the BCM6368 Ethernet MAC.
>  
> +config BCMGENET
> + bool "BCMGENET V5 support"
> + depends on DM_ETH

maybe this should be limited to the supported SoC's?

e.g.  depends on DM_ETH && ARCH_BCM283X

> + select PHYLIB
> + help
> +   This driver supports the BCMGENET 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 30991834ec..6e0a68834d 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_AG7XXX) += ag7xxx.o
>  obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
>  obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
>  obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o
> +obj-$(CONFIG_BCMGENET) += bcmgenet.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/bcmgenet.c b/drivers/net/bcmgenet.c
> new file mode 100644
> index 00..4f8f190071
> --- /dev/null
> +++ b/drivers/net/bcmgenet.c
> @@ -0,0 +1,722 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Amit Singh Tomar 
> + *
> + * Driver for Broadcom GENETv5 Ethernet controller (as found on the RPi4)
> + * This driver is based on the Linux driver:
> + *  drivers/net/ethernet/broadcom/genet/bcmgenet.c
> + *  which is: Copyright (c) 2014-2017 Broadcom
> + *
> + * The hardware supports multiple queues (16 priority queues and one
> + * default queue), both for RX and TX. There are 256 DMA descriptors (both
> + * for TX and RX), and they live in MMIO registers. The hardware allows
> + * assigning descriptor ranges to queues, but we choose the most simple 
> setup:
> + * All 256 descriptors are assigned to the default queue (#16).
> + * Also the Linux driver supports multiple generations of the MAC, whereas
> + * we only support v5, as used in the Raspberry Pi 4.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register definitions derived from Linux source */
> +#define SYS_REV_CTRL 0x00
> +
> +#define SYS_PORT_CTRL0x04
> +#define PORT_MODE_EXT_GPHY   3
> +
> +#define GENET_SYS_OFF0x
> +#define SYS_RBUF_FLUSH_CTRL  (GENET_SYS_OFF  + 0x08)
> +#define SYS_TBUF_FLUSH_CTRL  (GENET_SYS_OFF  + 0x0c)
> +
> +#define GENET_EXT_OFF0x0080
> +#define EXT_RGMII_OOB_CTRL   (GENET_EXT_OFF + 0x0c)
> +#define RGMII_LINK   BIT(4)
> +#define OOB_DISABLE  BIT(5)
> +#define RGMII_MODE_ENBIT(6)
> +#define ID_MODE_DIS  BIT(16)
> +
> +#define GENET_RBUF_OFF   0x0300
> +#define RBUF_TBUF_SIZE_CTRL  (GENET_RBUF_OFF + 0xb4)
> +#define RBUF_CTRL(GENET_RBUF_OFF + 0x00)
> +#define RBUF_ALIGN_2BBIT(1)
> +
> +#define GENET_UMAC_OFF   0x0800
> +#define UMAC_MIB_CTRL(GENET_UMAC_OFF + 0x580)
> +#define UMAC_MAX_FRAME_LEN   (GENET_UMAC_OFF + 0x014)
> +#define UMAC_MAC0(GENET_UMAC_OFF + 0x00c)
> +#define UMAC_MAC1(GENET_UMAC_OFF + 0x010)
> +#define UMAC_CMD (GENET_UMAC_OFF + 0x008)
> +#define MDIO_CMD (GENET_UMAC_OFF + 0x614)
> +#define UMAC_TX_FLUSH(GENET_UMAC_OFF + 0x334)
> +#define MDIO_START_BUSY  BIT(29)
> +#define MDIO_READ_FAIL   BIT(28)
> +#define MDIO_RD  (2 << 26)
> +#define MDIO_WR  

[RFC PATCH 4/4] x86: itss: Remove apl-prefix

[Wolfgang Wallner]

The Interrupt Timer Subsystem (ITSS) is not specific to Apollo Lake, so
remove the apl-prefix of the implemented functions/structures/...

Signed-off-by: Wolfgang Wallner 
---

 arch/x86/cpu/intel_common/itss.c  | 56 +++
 arch/x86/dts/chromebook_coral.dts |  2 +-
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/x86/cpu/intel_common/itss.c b/arch/x86/cpu/intel_common/itss.c
index ff7a83d618..9df51adecc 100644
--- a/arch/x86/cpu/intel_common/itss.c
+++ b/arch/x86/cpu/intel_common/itss.c
@@ -17,10 +17,10 @@
 #include 
 #include 
 
-struct apl_itss_platdata {
+struct itss_platdata {
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
/* Put this first since driver model will copy the data here */
-   struct dtd_intel_apl_itss dtplat;
+   struct dtd_intel_itss dtplat;
 #endif
 };
 
@@ -30,13 +30,13 @@ struct pmc_route {
u32 gpio;
 };
 
-struct apl_itss_priv {
+struct itss_priv {
struct pmc_route *route;
uint route_count;
u32 irq_snapshot[NUM_IPC_REGS];
 };
 
-static int apl_set_polarity(struct udevice *dev, uint irq, bool active_low)
+static int set_polarity(struct udevice *dev, uint irq, bool active_low)
 {
u32 mask;
uint reg;
@@ -53,9 +53,9 @@ static int apl_set_polarity(struct udevice *dev, uint irq, 
bool active_low)
 }
 
 #ifndef CONFIG_TPL_BUILD
-static int apl_snapshot_polarities(struct udevice *dev)
+static int snapshot_polarities(struct udevice *dev)
 {
-   struct apl_itss_priv *priv = dev_get_priv(dev);
+   struct itss_priv *priv = dev_get_priv(dev);
const int start = GPIO_IRQ_START;
const int end = GPIO_IRQ_END;
int reg_start;
@@ -86,9 +86,9 @@ static void show_polarities(struct udevice *dev, const char 
*msg)
}
 }
 
-static int apl_restore_polarities(struct udevice *dev)
+static int restore_polarities(struct udevice *dev)
 {
-   struct apl_itss_priv *priv = dev_get_priv(dev);
+   struct itss_priv *priv = dev_get_priv(dev);
const int start = GPIO_IRQ_START;
const int end = GPIO_IRQ_END;
int reg_start;
@@ -132,9 +132,9 @@ static int apl_restore_polarities(struct udevice *dev)
 }
 #endif
 
-static int apl_route_pmc_gpio_gpe(struct udevice *dev, uint pmc_gpe_num)
+static int route_pmc_gpio_gpe(struct udevice *dev, uint pmc_gpe_num)
 {
-   struct apl_itss_priv *priv = dev_get_priv(dev);
+   struct itss_priv *priv = dev_get_priv(dev);
struct pmc_route *route;
int i;
 
@@ -146,14 +146,14 @@ static int apl_route_pmc_gpio_gpe(struct udevice *dev, 
uint pmc_gpe_num)
return -ENOENT;
 }
 
-static int apl_itss_ofdata_to_platdata(struct udevice *dev)
+static int itss_ofdata_to_platdata(struct udevice *dev)
 {
-   struct apl_itss_priv *priv = dev_get_priv(dev);
+   struct itss_priv *priv = dev_get_priv(dev);
int ret;
 
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
-   struct apl_itss_platdata *plat = dev_get_platdata(dev);
-   struct dtd_intel_apl_itss *dtplat = >dtplat;
+   struct itss_platdata *plat = dev_get_platdata(dev);
+   struct dtd_intel_itss *dtplat = >dtplat;
 
/*
 * It would be nice to do this in the bind() method, but with
@@ -189,26 +189,26 @@ static int apl_itss_ofdata_to_platdata(struct udevice 
*dev)
return 0;
 }
 
-static const struct irq_ops apl_itss_ops = {
-   .route_pmc_gpio_gpe = apl_route_pmc_gpio_gpe,
-   .set_polarity   = apl_set_polarity,
+static const struct irq_ops itss_ops = {
+   .route_pmc_gpio_gpe = route_pmc_gpio_gpe,
+   .set_polarity   = set_polarity,
 #ifndef CONFIG_TPL_BUILD
-   .snapshot_polarities = apl_snapshot_polarities,
-   .restore_polarities = apl_restore_polarities,
+   .snapshot_polarities = snapshot_polarities,
+   .restore_polarities = restore_polarities,
 #endif
 };
 
-static const struct udevice_id apl_itss_ids[] = {
-   { .compatible = "intel,apl-itss"},
+static const struct udevice_id itss_ids[] = {
+   { .compatible = "intel,itss"},
{ }
 };
 
-U_BOOT_DRIVER(apl_itss_drv) = {
-   .name   = "intel_apl_itss",
+U_BOOT_DRIVER(itss_drv) = {
+   .name   = "intel_itss",
.id = UCLASS_IRQ,
-   .of_match   = apl_itss_ids,
-   .ops= _itss_ops,
-   .ofdata_to_platdata = apl_itss_ofdata_to_platdata,
-   .platdata_auto_alloc_size = sizeof(struct apl_itss_platdata),
-   .priv_auto_alloc_size = sizeof(struct apl_itss_priv),
+   .of_match   = itss_ids,
+   .ops= _ops,
+   .ofdata_to_platdata = itss_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct itss_platdata),
+   .priv_auto_alloc_size = sizeof(struct itss_priv),
 };
diff --git a/arch/x86/dts/chromebook_coral.dts 
b/arch/x86/dts/chromebook_coral.dts
index 24fcbb5063..a1820fa187 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -171,7 +171,7 @@
 

[RFC PATCH 3/4] x86: Move itss.c from Apollo Lake to a more generic location

[Wolfgang Wallner]

The Interrupt Timer Subsystem (ITSS) is not specific to Apollo Lake, so
move it to a common location within arch/x86.

Signed-off-by: Wolfgang Wallner 
---
At the moment, this commit enables building of itss.o unconditionally.
which is a bad idea I guess.
What is the preferred way to handle this?
Should I add a kconfig option e.g. in arch/x86/Kconfig?

 arch/x86/cpu/apollolake/Makefile | 1 -
 arch/x86/cpu/intel_common/Makefile   | 1 +
 arch/x86/cpu/{apollolake => intel_common}/itss.c | 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/x86/cpu/{apollolake => intel_common}/itss.c (100%)

diff --git a/arch/x86/cpu/apollolake/Makefile b/arch/x86/cpu/apollolake/Makefile
index 1760df54d8..f99f2c6473 100644
--- a/arch/x86/cpu/apollolake/Makefile
+++ b/arch/x86/cpu/apollolake/Makefile
@@ -19,7 +19,6 @@ obj-y += fsp_s.o
 endif
 
 obj-y += hostbridge.o
-obj-y += itss.o
 obj-y += lpc.o
 obj-y += p2sb.o
 obj-y += pch.o
diff --git a/arch/x86/cpu/intel_common/Makefile 
b/arch/x86/cpu/intel_common/Makefile
index cc4e1c962b..266e6e26fa 100644
--- a/arch/x86/cpu/intel_common/Makefile
+++ b/arch/x86/cpu/intel_common/Makefile
@@ -27,6 +27,7 @@ obj-y += microcode.o
 endif
 endif
 obj-y += pch.o
+obj-y += itss.o
 
 ifdef CONFIG_SPL
 ifndef CONFIG_SPL_BUILD
diff --git a/arch/x86/cpu/apollolake/itss.c b/arch/x86/cpu/intel_common/itss.c
similarity index 100%
rename from arch/x86/cpu/apollolake/itss.c
rename to arch/x86/cpu/intel_common/itss.c
-- 
2.25.0

[RFC PATCH 0/4] x86: Move ITSS from Apollo Lake to a more generic location

[Wolfgang Wallner]

The Interrupt Timer Subsystem (ITSS) is not specific to Apollo Lake, so
move it to a more generic location.
Additionally, the series adds the term "Interrupt Timer Subsystem" for
ITSS in the file descriptions.

Moving the ITSS implementation out of the Apllo Lake-specific folders not
only allows to use this driver on other platforms, it is also useful for
Apollo Lake when U-Boot is chain-loaded via coreboot (in which case the
files within arch/x86/cpu/apollolake would not be compiled and the
include/asm/arch-symlink points to arch-coreboot instead of
arch-apollolake).


Wolfgang Wallner (4):
  x86: apl: Add the term "Interrupt Timer Subsystem" to ITSS files
  x86: Move itss.h from Apollo Lake to the generic x86 include directory
  x86: Move itss.c from Apollo Lake to a more generic location
  x86: itss: Remove apl-prefix

 arch/x86/cpu/apollolake/Makefile  |  1 -
 arch/x86/cpu/intel_common/Makefile|  1 +
 .../cpu/{apollolake => intel_common}/itss.c   | 60 +--
 arch/x86/dts/chromebook_coral.dts |  2 +-
 .../include/asm/{arch-apollolake => }/itss.h  |  2 +
 drivers/pinctrl/intel/pinctrl.c   |  2 +-
 6 files changed, 35 insertions(+), 33 deletions(-)
 rename arch/x86/cpu/{apollolake => intel_common}/itss.c (73%)
 rename arch/x86/include/asm/{arch-apollolake => }/itss.h (97%)

-- 
2.25.0

[RFC PATCH 2/4] x86: Move itss.h from Apollo Lake to the generic x86 include directory

[Wolfgang Wallner]

The code in this file is not specific to Apollo Lake. According to
coreboot sources (where this code comes from), it is common to at least:
  * Apollo Lake
  * Cannon Lake
  * Ice Lake
  * Skylake

Signed-off-by: Wolfgang Wallner 
---

 arch/x86/cpu/apollolake/itss.c| 2 +-
 arch/x86/include/asm/{arch-apollolake => }/itss.h | 0
 drivers/pinctrl/intel/pinctrl.c   | 2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/x86/include/asm/{arch-apollolake => }/itss.h (100%)

diff --git a/arch/x86/cpu/apollolake/itss.c b/arch/x86/cpu/apollolake/itss.c
index 95c9ebddc1..ff7a83d618 100644
--- a/arch/x86/cpu/apollolake/itss.c
+++ b/arch/x86/cpu/apollolake/itss.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 struct apl_itss_platdata {
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
diff --git a/arch/x86/include/asm/arch-apollolake/itss.h 
b/arch/x86/include/asm/itss.h
similarity index 100%
rename from arch/x86/include/asm/arch-apollolake/itss.h
rename to arch/x86/include/asm/itss.h
diff --git a/drivers/pinctrl/intel/pinctrl.c b/drivers/pinctrl/intel/pinctrl.c
index 4875a3b0b5..5bf5d8b0e2 100644
--- a/drivers/pinctrl/intel/pinctrl.c
+++ b/drivers/pinctrl/intel/pinctrl.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.25.0

Antwort: Re: Re: Apollo Lake GPIO driver with Coreboot/U-Boot

[Wolfgang Wallner]

Hi Simon,

> Hi Wolfgang,
> 
> On Sat, 18 Jan 2020 at 00:56, Wolfgang Wallner
>  wrote:
> >
> > Hello Simon,
> >
> > > -"Simon Glass"  schrieb: -
> > > On Thu, 16 Jan 2020 at 02:55, Wolfgang Wallner
> > >  wrote:
> > > >
> > > > Hello Simon, Bin, all,
> > > >
> > > > I have an Apollo Lake based device, where U-Boot is booted as a Coreboot
> > > > payload. I would like to utilize the Apollo Lake GPIO driver
> > > > (drivers/gpio/intel_gpio.c), but I struggle with the dependencies.
> > > >
> > > > For my use case, I face 2 obstacles:
> > > >
> > > >   1) Some required drivers are not built
> > > >
> > > > The Apollo Lake GPIO driver requires the P2SB and ITSS drivers, but 
> > > > those
> > > > are located in arch/x86/cpu/apollolake. Drivers in this directory 
> > > > are not
> > > > included in my build as it builds for Coreboot, not for Apollo Lake.
> > > >
> > > >   2) Some header files are not found
> > > >
> > > > The header files gpio.h and itss.h are located in
> > > > arch/x86/include/asm/arch-apollolake, but as I build for Coreboot 
> > > > the
> > > > symlink arch/x86/include/asm/arch points to arch-coreboot instead of
> > > > arch-apollolake, so those header files are not found.
> > > >
> > > > Does anyone have recommendations on how to solve those issues?
> > > > Would it be possible to move the drivers for P2SB and ITSS out of
> > > > arch/x86/cpu/apollolake to the generic drivers/ directory?
> > >
> > > I don't have any great ideas. At present we rely on the device tree to
> > > bind these drivers but I suppose we could add the PCI IDs and then the
> > > coreboot target could bind them.
> >
> > I have added the relevant entries in my device tree, the point is that the
> > required drivers are not even built, because they are located in the
> > Apollo Lake directory. This is why I asked wheter we could move them to the
> > generic drivers directory. (This could also make sense IMHO as they are not
> > specific for Apollo Lake, but could be used for mulitple generations of 
> > chips)
> 
> Yes that sounds OK to me.

Ok, thanks for the feedback.
As a first step, I will send a patch series to move the ITSS driver to a
more common location within arch/x86.

regards, Wolfgang

[PATCH] imx: distinguish POR from POR+WDOG reset cause for first wd

[Flavio Suligoi]

In some application the possibility to check if the reset
is caused by a watchdog is essential, even if it occurs
simultaneously with POR.

Signed-off-by: Flavio Suligoi 
---
 arch/arm/mach-imx/cpu.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index bfa85c6..ce0c663 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -47,7 +47,6 @@ static char *get_reset_cause(void)
 {
switch (get_imx_reset_cause()) {
case 0x1:
-   case 0x00011:
return "POR";
case 0x4:
return "CSU";
@@ -59,6 +58,12 @@ static char *get_reset_cause(void)
 #else
return "WDOG";
 #endif
+   case 0x00011:
+#ifdef CONFIG_MX7
+   return "POR + WDOG1";
+#else
+   return "POR + WDOG";
+#endif
case 0x00020:
return "JTAG HIGH-Z";
case 0x00040:
-- 
2.7.4

RE: [PATCH v3] board_f.c: Insure gd->new_bootstage alignment

[Patrick DELAUNAY]

Hi Tom,

> From: Tom Rini 
> Sent: mercredi 22 janvier 2020 00:18
> 
> On Thu, Jan 09, 2020 at 05:23:51PM +, Patrick DELAUNAY wrote:
> > Hi,
> >
> > > From: Patrick DELAUNAY
> > > Sent: mardi 7 janvier 2020 13:07
> > >
> > > Hi Patrice and Tom
> > >
> > > > Sent: mercredi 18 décembre 2019 10:10
> > > >
> > > > Hi Simon,
> > > >
> > > > > From: Simon Glass 
> > > > > Sent: mardi 17 décembre 2019 16:46
> > > > >
> > > > > Hi Patrice,
> > > > >
> > > > > On Wed, 27 Nov 2019 at 02:11, Patrice Chotard
> > > > > 
> > > > wrote:
> > > > > >
> > > > > > In reserve_bootstage(), in case size is odd, gd->new_bootstage
> > > > > > is not aligned. In bootstage_relocate(), the platform hangs
> > > > > > when getting access to data->record[i].name.
> > > > > > To avoid this issue, make gd->new_bootstage 16 byte aligned.
> > > > > >
> > > > > > To insure that new_bootstage is 16 byte aligned (at least
> > > > > > needed for
> > > > > > x86_64 and ARMv8) and new_bootstage starts down to get enough
> > > > > > space, ALIGN_DOWN macro is used.
> > > > > >
> > > > > > Fixes: ac9cd4805c8b ("bootstage: Correct relocation
> > > > > > algorithm")
> > > > > >
> > > > > > Signed-off-by: Patrice Chotard 
> > > > > > Reviewed-by: Vikas MANOCHA 
> > > > > > Reviewed-by: Patrick Delaunay 
> > > > > > Tested-by: Patrick Delaunay 
> > > >
> > > > For information, Patrice is absent for personal reason up to beginning 
> > > > next
> year.
> > > > Don't wait a fast answer.
> > > >
> > > > > For this patch I think it would be better to update
> > > > > reserve_fdt() to keep things aligned, assuming that is the problem.
> > > >
> > > > I don't sure that solve the issue, for me the problem is only for
> > > > the bootstage struct (gd->bootstage) And
> > > > reserve_fdt() already alligne size on 32 bytes
> > > >
> > > > If I remember the Patrice analysis:
> > > >
> > > > 1- bootstage_get_size return a odd value (or at least not 16 bytes
> > > > aligned I don't remember).
> > > >
> > > > 2- In reserve_bootstage()
> > > > int size = bootstage_get_size();
> > > > gd->start_addr_sp -= size
> > > > => it is a unaligned address even if gd->start_addr_sp is 32
> > > > bytes alligned
> > > >
> > > > gd->new_bootstage = map_sysmem(gd->start_addr_sp, size);
> > > > => also unaligned
> > > >
> > > > 3- Then during relocation, in reloc_bootstage()
> > > > gd->bootstage = gd->new_bootstage;
> > > >
> > > >
> > > > 4- crash occur because in next bootstage function beaucse the
> > > > boostage address don't respect pointer to struct allignement...
> > > >
> > > > struct bootstage_data *data = gd->bootstage
> > > >
> > > >
> > > > > At some point we should also document that reservations must
> > > > > keep things aligned.
> > > > >
> > > > > Perhaps this should be handled by a separate function called
> > > > > from all these places, which subtracts gd->start_addr_sp and
> > > > > ensures 16-byte
> > > alignment.
> > > >
> > > > Yes that can be a improvement,  but perhaps ia a second step / second
> serie
> > > >
> > > > Do you think about a function called in all reversed_ functions
> > > > (when start_addr_sp is modified)...
> > > >
> > > > static int reserved_allign_check(void) {
> > > > /* make stack pointer 16-byte aligned */
> > > > if (gd->start_addr_sp & 0xf) {
> > > > gd->start_addr_sp -= 16;
> > > > gd->start_addr_sp &= ~0xf;
> > > >  }
> > > > }
> > > >
> > > > I prefer a function to reserved a size wich replace in any
> > > > reserve_ function  the line
> > > > :
> > > > gd->start_addr_sp -= ...
> > > >
> > > > /* reserve size and make stack pointer 16-byte aligned */  static
> > > > int reserve(size_t size) {
> > > > gd->start_addr_sp -= size;
> > > > /* make stack pointer 16-byte aligned */
> > > > gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp, 16); }
> > > >
> > > > I think I will push it, when the patrice patch will be accepted.
> > >
> > > I am preparing this patch
> > >
> > > Do you think it is ok to merge the Patrice v3 proposal first on
> > > master branch for
> > > v2020.04 release (he just align the reserved memory for bootstage),
> > > and after I make my patch (16-byte align all reserved area).
> > >
> > > or it is better to make a more generic patch v4 to replace the Patrice 
> > > one.
> >
> > I push a  serie, with my proposal:
> > [3/3] board_f.c: Insure 16 alignment of start_addr_sp and reserved
> > memory
> >
> > http://patchwork.ozlabs.org/project/uboot/list/?series=152226
> >
> > As I found issue for ARM32 (I need to modify arch/arm/lib/crt0.S) I
> > think it is preferable that the Patrice Patch is merged in v2020.04, and my 
> > serie
> can live  independently.
> > But I can also squash of the 2 series.
> 
> Sorry for the delay.  Yes, please put together a single series that takes 
> care of
> everything.  Thanks!

Done with serie = "Insure 16 alignment of reserved 

[PATCH v2 0/4] Insure 16 alignment of reserved memory in board_f.c

[Patrick Delaunay]

Hi,

It is a V2, rebased on master branch, for the untitled serie
http://patchwork.ozlabs.org/project/uboot/list/?series=152226

This serie now include the previous patch:
[U-Boot,v3] board_f.c: Insure gd->new_bootstage alignment
http://patchwork.ozlabs.org/patch/1201452/

After this first correction, I remove the stm32mp1 workaround
as the issue of bootstage alignment is solved.

The 4th patch is a complete solution to alignment
(proposed in comment 5 of
 http://patchwork.ozlabs.org/patch/1201452/#2327366)
I always align the reserved memory to 16 bytes with a new function
reserve_sp().

This patch causes an issue on ARM 32 bits, as the relocated gd pointer
is not initialized with gd->new_gd as expected in reserve_global_data()
but is hard-coded with
  relocated gd = gd->bd - GD_SIZE
  {with GD_SIZE = sizeof(struct global_data)}

This issue is solved with the 3rd patch of the serie
  arm: set the relocated gd with gd->new_gd

Only tested on STM32MP157C-EV1 board (ARM32 architecture).


Changes in v2:
- import: [U-Boot,v3] board_f.c: Insure gd->new_bootstage alignment

Patrice Chotard (1):
  board_f.c: Insure gd->new_bootstage alignment

Patrick Delaunay (3):
  Revert "stm32mp1: remove the imply BOOTSTAGE"
  arm: set the relocated gd with gd->new_gd
  board_f.c: Insure 16 alignment of start_addr_sp and reserved memory

 arch/arm/lib/crt0.S   |  3 +--
 arch/arm/mach-stm32mp/Kconfig |  2 ++
 common/board_f.c  | 27 ++-
 3 files changed, 21 insertions(+), 11 deletions(-)

-- 
2.17.1

[PATCH v2 1/4] board_f.c: Insure gd->new_bootstage alignment

[Patrick Delaunay]

From: Patrice Chotard 

In reserve_bootstage(), in case size is odd, gd->new_bootstage
is not aligned. In bootstage_relocate(), the platform hangs when
getting access to data->record[i].name.
To avoid this issue, make gd->new_bootstage 16 byte aligned.

To insure that new_bootstage is 16 byte aligned (at least needed for
x86_64 and ARMv8) and new_bootstage starts down to get enough space,
ALIGN_DOWN macro is used.

Fixes: ac9cd4805c8b ("bootstage: Correct relocation algorithm")

Signed-off-by: Patrice Chotard 
Reviewed-by: Vikas MANOCHA 
Reviewed-by: Patrick Delaunay 
Tested-by: Patrick Delaunay 
Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- import: [U-Boot,v3] board_f.c: Insure gd->new_bootstage alignment

 common/board_f.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c
index d66afb37ca..e21f533634 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -562,6 +562,11 @@ static int reserve_bootstage(void)
int size = bootstage_get_size();
 
gd->start_addr_sp -= size;
+   /*
+* Insure that start_addr_sp is aligned down to reserve enough
+* space for new_bootstage
+*/
+   gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp, 16);
gd->new_bootstage = map_sysmem(gd->start_addr_sp, size);
debug("Reserving %#x Bytes for bootstage at: %08lx\n", size,
  gd->start_addr_sp);
-- 
2.17.1

[PATCH v2 3/4] arm: set the relocated gd with gd->new_gd

[Patrick Delaunay]

Simplify the arm relocation behavior and get gd directly form new_gd,
as it is already done in crt0_64.S:

ldr x18, [x18, #GD_NEW_GD]  /* x18 <- gd->new_gd */

This patch avoid assumption on new GD location (new GD is below bd -
with #GD_SIZE offset).

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 arch/arm/lib/crt0.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index fb6c37cf51..df9dd83e40 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -127,8 +127,7 @@ ENTRY(_main)
ldr r0, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */
bic r0, r0, #7  /* 8-byte alignment for ABI compliance */
mov sp, r0
-   ldr r9, [r9, #GD_BD]/* r9 = gd->bd */
-   sub r9, r9, #GD_SIZE/* new GD is below bd */
+   ldr r9, [r9, #GD_NEW_GD]/* r9 <- gd->new_gd */
 
adr lr, here
ldr r0, [r9, #GD_RELOC_OFF] /* r0 = gd->reloc_off */
-- 
2.17.1

[PATCH v2 2/4] Revert "stm32mp1: remove the imply BOOTSTAGE"

[Patrick Delaunay]

This reverts the workaround introduced by the
commit 16fec9b0bc1a ("stm32mp1: remove the imply BOOTSTAGE")
As the bootstage alignment issue is now solved.

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 arch/arm/mach-stm32mp/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index ae28f6e206..e920b89ef5 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -46,7 +46,9 @@ config TARGET_STM32MP1
select STM32_SERIAL
select SYS_ARCH_TIMER
imply BOOTCOUNT_LIMIT
+   imply BOOTSTAGE
imply CMD_BOOTCOUNT
+   imply CMD_BOOTSTAGE
imply CMD_CLS if CMD_BMP
imply DISABLE_CONSOLE
imply PRE_CONSOLE_BUFFER
-- 
2.17.1

[PATCH v2 4/4] board_f.c: Insure 16 alignment of start_addr_sp and reserved memory

[Patrick Delaunay]

Add a function reserve_sp() to reserved memory with 16 bits alignment
after the stack pointer (gd->start_addr_sp) and use this new function
in board_f.c to reserve all the memory area (malloc, board, gd, fdt,
bootstage, stacks).

This 16 byte alignment is needed for cast on struct pointer
for the reserved memory, for example:
+ x86_64 ABI: https://reviews.llvm.org/D30049: 16 bytes
+ ARMv8 Instruction Set Overview: quad word, 16 bytes

An other alignment value could be needed for other architecture.

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 common/board_f.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index e21f533634..0302ee4a6e 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -470,6 +470,17 @@ static int reserve_uboot(void)
return 0;
 }
 
+/*
+ * reserve after start_addr_sp the requested size and make the stack pointer
+ * 16-byte aligned, this alignment is needed for cast on the reserved memory
+ * ref = x86_64 ABI: https://reviews.llvm.org/D30049: 16 bytes
+ * = ARMv8 Instruction Set Overview: quad word, 16 bytes
+ */
+static unsigned long reserve_sp(size_t size)
+{
+   return ALIGN_DOWN(gd->start_addr_sp - size, 16);
+}
+
 #ifdef CONFIG_SYS_NONCACHED_MEMORY
 static int reserve_noncached(void)
 {
@@ -495,7 +506,7 @@ static int reserve_noncached(void)
 /* reserve memory for malloc() area */
 static int reserve_malloc(void)
 {
-   gd->start_addr_sp = gd->start_addr_sp - TOTAL_MALLOC_LEN;
+   gd->start_addr_sp = reserve_sp(TOTAL_MALLOC_LEN);
debug("Reserving %dk for malloc() at: %08lx\n",
  TOTAL_MALLOC_LEN >> 10, gd->start_addr_sp);
 #ifdef CONFIG_SYS_NONCACHED_MEMORY
@@ -509,7 +520,7 @@ static int reserve_malloc(void)
 static int reserve_board(void)
 {
if (!gd->bd) {
-   gd->start_addr_sp -= sizeof(bd_t);
+   gd->start_addr_sp = reserve_sp(sizeof(bd_t));
gd->bd = (bd_t *)map_sysmem(gd->start_addr_sp, sizeof(bd_t));
memset(gd->bd, '\0', sizeof(bd_t));
debug("Reserving %zu Bytes for Board Info at: %08lx\n",
@@ -528,7 +539,7 @@ static int setup_machine(void)
 
 static int reserve_global_data(void)
 {
-   gd->start_addr_sp -= sizeof(gd_t);
+   gd->start_addr_sp = reserve_sp(sizeof(gd_t));
gd->new_gd = (gd_t *)map_sysmem(gd->start_addr_sp, sizeof(gd_t));
debug("Reserving %zu Bytes for Global Data at: %08lx\n",
  sizeof(gd_t), gd->start_addr_sp);
@@ -546,7 +557,7 @@ static int reserve_fdt(void)
if (gd->fdt_blob) {
gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32);
 
-   gd->start_addr_sp -= gd->fdt_size;
+   gd->start_addr_sp = reserve_sp(gd->fdt_size);
gd->new_fdt = map_sysmem(gd->start_addr_sp, gd->fdt_size);
debug("Reserving %lu Bytes for FDT at: %08lx\n",
  gd->fdt_size, gd->start_addr_sp);
@@ -561,12 +572,7 @@ static int reserve_bootstage(void)
 #ifdef CONFIG_BOOTSTAGE
int size = bootstage_get_size();
 
-   gd->start_addr_sp -= size;
-   /*
-* Insure that start_addr_sp is aligned down to reserve enough
-* space for new_bootstage
-*/
-   gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp, 16);
+   gd->start_addr_sp = reserve_sp(size);
gd->new_bootstage = map_sysmem(gd->start_addr_sp, size);
debug("Reserving %#x Bytes for bootstage at: %08lx\n", size,
  gd->start_addr_sp);
@@ -583,8 +589,7 @@ __weak int arch_reserve_stacks(void)
 static int reserve_stacks(void)
 {
/* make stack pointer 16-byte aligned */
-   gd->start_addr_sp -= 16;
-   gd->start_addr_sp &= ~0xf;
+   gd->start_addr_sp = reserve_sp(16);
 
/*
 * let the architecture-specific code tailor gd->start_addr_sp and
@@ -596,8 +601,7 @@ static int reserve_stacks(void)
 static int reserve_bloblist(void)
 {
 #ifdef CONFIG_BLOBLIST
-   gd->start_addr_sp &= ~0xf;
-   gd->start_addr_sp -= CONFIG_BLOBLIST_SIZE;
+   gd->start_addr_sp = reserve_sp(CONFIG_BLOBLIST_SIZE);
gd->new_bloblist = map_sysmem(gd->start_addr_sp, CONFIG_BLOBLIST_SIZE);
 #endif
 
-- 
2.17.1

Re: [PATCH 4/4] mx6sabreauto: Convert to DM_ETH

[Fabio Estevam]

On Mon, Jan 20, 2020 at 1:31 PM Alifer Moraes  wrote:
>
> From: Pedro Jardim 
>
> This fixes the following warning:
>
> = WARNING ==
> This board does not use CONFIG_DM_ETH (Driver Model
> for Ethernet drivers). Please update the board to use
> CONFIG_DM_ETH before the v2020.07 release. Failure to
> update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
> 
>
> Signed-off-by: Pedro Jardim 
> Signed-off-by: Alifer Moraes 

Reviewed-by: Fabio Estevam 

Re: [PATCH 2/4] mx6sabresd: Convert PCI to driver model

[Fabio Estevam]

On Mon, Jan 20, 2020 at 1:31 PM Alifer Moraes  wrote:
>
> Convert imx6sabresd PCI to driver model to fix the following warning:
>
> = WARNING ==
> This board does not use CONFIG_DM_PCI Please update
> the board to use CONFIG_DM_PCI before the v2019.07 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/MIGRATION.txt for more info.
> 
>
> After the conversion the following commands were used for testing:
>
> => pci enum
> PCI: Failed autoconfig bar 10
> PCI: Failed autoconfig bar 10
> => pci 1
> Scanning PCI devices on bus 1
> BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
> _
> 01.00.00   0x8086 0x08b1 Network controller  0x80
>
> Signed-off-by: Alifer Moraes 

Reviewed-by: Fabio Estevam 

Re: [PATCH 3/4] mx6sabresd: Convert ethernet to driver model

[Fabio Estevam]

On Mon, Jan 20, 2020 at 1:23 PM Alifer Moraes  wrote:
>
> Convert imx6sabresd ethernet to driver model to fix the following warning:
>
> = WARNING ==
> This board does not use CONFIG_DM_ETH (Driver Model
> for Ethernet drivers). Please update the board to use
> CONFIG_DM_ETH before the v2020.07 release. Failure to
> update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
> 
>
> Signed-off-by: Alifer Moraes 

Reviewed-by: Fabio Estevam 

Issue with saveenv() and the QSPI NOR memory MICRON MT25QU01GBBB

[florian.man...@siemens.com]

Hello U-Boot team,



I am Florian, working at Siemens in Germany.

I am in charge of bringing up a custom board based on the processor NXP QorIQ 
LS1043a.



So far, I have been able to bring U-Boot on the board without too much troubles.

However I can not get the command 'saveenv' to work. Our environment variables 
are stored in the QSPI NOR memory that is also used as boot memory.



The 'saveenv' command always ends up in a

"

=> saveenv

Saving Environment to SPI Flash... Erasing SPI flash...flash operation timed out

Failed (-110)

"



Few more information:

- No issue with a Lauterbach debugger

- I noticed that the NOR memory at offset address 0 get erased during the 
operation. The normal offset of the env variable is normally 0x90.

- The memory used is the 'MT25QU01GBBB' from MICRON (Device ID 0x20bb21). I can 
provide the datasheet.

- the NOR memory is correctly discovered, 'sf probe => SF: Detected n25q00a 
with page size 256 Bytes, erase size 64 KiB, total 128 MiB'

- I have tried to activate the debug logs but they didn't bring any interesting 
information.

- current version :

"

=> version

U-Boot 2019.10-00062-gc71ef945eb-dirty (Jan 22 2020 - 14:14:26 +0100)



aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516

GNU ld (GNU Binutils for Debian) 2.28

"



Can you provide support to fix this issue ?

Of course, I can provide more info/logs.



Regards,

Mit freundlichen Grüßen
Florian Manoël

Siemens AG
Digital Industries
Process Automation
Software House Khe
DI PA CI R 2
Östliche Rheinbrückenstr. 50
76187 Karlsruhe, Deutschland
Tel.: +49 721 595-1433
mailto:florian.man...@siemens.com
www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; 
Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, 
Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Sitz der Gesellschaft: 
Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 
12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322



u-boot.cfg
Description: u-boot.cfg

[PATCH v2] genboardscfg.py: drop python version comment

[Baruch Siach]

genboardscfg.py requires python 3.x since commit 3bc14098d8fb
("genboardscfg.py: Convert to Python 3").

Cc: Masahiro Yamada 
Signed-off-by: Baruch Siach 
---
v2: Remove the comment entirely (Masahiro Yamada)
---
 tools/genboardscfg.py | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tools/genboardscfg.py b/tools/genboardscfg.py
index 24df13e5008d..4f6382bc7ca9 100755
--- a/tools/genboardscfg.py
+++ b/tools/genboardscfg.py
@@ -10,8 +10,6 @@ Converter from Kconfig and MAINTAINERS to a board database.
 Run 'tools/genboardscfg.py' to create a board database.
 
 Run 'tools/genboardscfg.py -h' for available options.
-
-Python 2.6 or later, but not Python 3.x is necessary to run this script.
 """
 
 import errno
-- 
2.24.1

Re: [PATCHv3] cmd/gpt: Address error cases during gpt rename more correctly

[Jordy]

Just caught up with all the patches and the final one indeed looks good to me 
too!

Kind Regards,

Jordy
> On January 22, 2020 2:20 AM Simon Goldschmidt 
>  wrote:
> 
>  
> On Tue, Jan 21, 2020 at 5:53 PM Tom Rini  wrote:
> >
> > New analysis by the tool has shown that we have some cases where we
> > weren't handling the error exit condition correctly.  When we ran into
> > the ENOMEM case we wouldn't exit the function and thus incorrect things
> > could happen.  Rework the unwinding such that we don't need a helper
> > function now and free what we may have allocated.
> >
> > Fixes: 18030d04d25d ("GPT: fix memory leaks identified by Coverity")
> > Reported-by: Coverity (CID: 275475, 275476)
> > Cc: Alison Chaiken 
> > Cc: Simon Goldschmidt 
> > Cc: Jordy 
> > Signed-off-by: Tom Rini 
> 
> Looks good to me.
> 
> Reviewed-by: Simon Goldschmidt 
> 
> > ---
> > Changes in v3:
> > - Move del_gpt_info() call into the unwind as set_gpt_info() will have
> >   been called at that point and we need to clear it. (Simon)
> > Changes in v2:
> > - Initialize str_disk_guid to NULL to be sure we can test that it has
> >   been set later on (Simon, Jordy).
> > ---
> >  cmd/gpt.c | 47 ---
> >  1 file changed, 12 insertions(+), 35 deletions(-)
> >
> > diff --git a/cmd/gpt.c b/cmd/gpt.c
> > index 0c4349f4b249..964702bad43e 100644
> > --- a/cmd/gpt.c
> > +++ b/cmd/gpt.c
> > @@ -633,21 +633,6 @@ static int do_disk_guid(struct blk_desc *dev_desc, 
> > char * const namestr)
> >  }
> >
> >  #ifdef CONFIG_CMD_GPT_RENAME
> > -/*
> > - * There are 3 malloc() calls in set_gpt_info() and there is no info about 
> > which
> > - * failed.
> > - */
> > -static void set_gpt_cleanup(char **str_disk_guid,
> > -   disk_partition_t **partitions)
> > -{
> > -#ifdef CONFIG_RANDOM_UUID
> > -   if (str_disk_guid)
> > -   free(str_disk_guid);
> > -#endif
> > -   if (partitions)
> > -   free(partitions);
> > -}
> > -
> >  static int do_rename_gpt_parts(struct blk_desc *dev_desc, char *subcomm,
> >char *name1, char *name2)
> >  {
> > @@ -655,7 +640,7 @@ static int do_rename_gpt_parts(struct blk_desc 
> > *dev_desc, char *subcomm,
> > struct disk_part *curr;
> > disk_partition_t *new_partitions = NULL;
> > char disk_guid[UUID_STR_LEN + 1];
> > -   char *partitions_list, *str_disk_guid;
> > +   char *partitions_list, *str_disk_guid = NULL;
> > u8 part_count = 0;
> > int partlistlen, ret, numparts = 0, partnum, i = 1, ctr1 = 0, ctr2 
> > = 0;
> >
> > @@ -697,14 +682,8 @@ static int do_rename_gpt_parts(struct blk_desc 
> > *dev_desc, char *subcomm,
> > /* set_gpt_info allocates new_partitions and str_disk_guid */
> > ret = set_gpt_info(dev_desc, partitions_list, _disk_guid,
> >_partitions, _count);
> > -   if (ret < 0) {
> > -   del_gpt_info();
> > -   free(partitions_list);
> > -   if (ret == -ENOMEM)
> > -   set_gpt_cleanup(_disk_guid, _partitions);
> > -   else
> > -   goto out;
> > -   }
> > +   if (ret < 0)
> > +   goto out;
> >
> > if (!strcmp(subcomm, "swap")) {
> > if ((strlen(name1) > PART_NAME_LEN) || (strlen(name2) > 
> > PART_NAME_LEN)) {
> > @@ -766,14 +745,8 @@ static int do_rename_gpt_parts(struct blk_desc 
> > *dev_desc, char *subcomm,
> >  * Even though valid pointers are here passed into set_gpt_info(),
> >  * it mallocs again, and there's no way to tell which failed.
> >  */
> > -   if (ret < 0) {
> > -   del_gpt_info();
> > -   free(partitions_list);
> > -   if (ret == -ENOMEM)
> > -   set_gpt_cleanup(_disk_guid, _partitions);
> > -   else
> > -   goto out;
> > -   }
> > +   if (ret < 0)
> > +   goto out;
> >
> > debug("Writing new partition table\n");
> > ret = gpt_restore(dev_desc, disk_guid, new_partitions, numparts);
> > @@ -795,10 +768,14 @@ static int do_rename_gpt_parts(struct blk_desc 
> > *dev_desc, char *subcomm,
> > }
> > printf("new partition table with %d partitions is:\n", numparts);
> > print_gpt_info();
> > -   del_gpt_info();
> >   out:
> > -   free(new_partitions);
> > -   free(str_disk_guid);
> > +   del_gpt_info();
> > +#ifdef CONFIG_RANDOM_UUID
> > +   if (str_disk_guid)
> > +   free(str_disk_guid);
> > +#endif
> > +   if (new_partitions)
> > +   free(new_partitions);
> > free(partitions_list);
> > return ret;
> >  }
> > --
> > 2.17.1
> >

Re: [Patchv4 3/3] arm: dts: Add cd-gpio for eMMC

[Neil Armstrong]

Hi,

On 22/01/2020 13:06, Anand Moon wrote:
> Add cd-gpio property for eMMC node.
> 
> Signed-off-by: Anand Moon 
> ---
> New patch in this series
> ---
>  arch/arm/dts/meson-g12b-odroid-n2.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dts 
> b/arch/arm/dts/meson-g12b-odroid-n2.dts
> index 888429b1cc..23ec14abe7 100644
> --- a/arch/arm/dts/meson-g12b-odroid-n2.dts
> +++ b/arch/arm/dts/meson-g12b-odroid-n2.dts
> @@ -449,6 +449,7 @@
>   max-frequency = <2>;
>   disable-wp;
>  
> + cd-gpios = < GPIOH_7 GPIO_ACTIVE_LOW>; /* eMMC_nDET */
>   mmc-pwrseq = <_pwrseq>;
>   vmmc-supply = <_3v3>;
>   vqmmc-supply = <_1v8>;
> 

If it's missing, submit it to linux-amlogic and move it to the -u-boot.dtsi 
file.

Neil

Re: [Patchv4 2/3] arm: dts: Add mmc alias to avoid warning

[Neil Armstrong]

Hi,

On 22/01/2020 13:06, Anand Moon wrote:
> Add missing mmc alias to dts nodes to avoid
> below debug warning.
> 
> mmc_bind: alias ret=-2, devnum=-1
> mmc_bind: alias ret=-2, devnum=-1
> 
> Signed-off-by: Anand Moon 
> ---
>  arch/arm/dts/meson-axg-s400.dts   | 2 ++
>  arch/arm/dts/meson-g12a-sei510.dts| 3 +++
>  arch/arm/dts/meson-g12a-u200.dts  | 3 +++
>  arch/arm/dts/meson-g12b-odroid-n2.dts | 3 +++
>  arch/arm/dts/meson-gxbb-odroidc2.dts  | 3 +++
>  arch/arm/dts/meson-gxbb-p20x.dtsi | 3 +++
>  arch/arm/dts/meson-gxl-s805x-libretech-ac.dts | 3 +++
>  arch/arm/dts/meson-gxl-s905x-p212.dtsi| 3 +++
>  arch/arm/dts/meson-gxm-khadas-vim2.dts| 3 +++
>  arch/arm/dts/meson-sm1-sei610.dts | 3 +++
>  10 files changed, 29 insertions(+)
> 
> diff --git a/arch/arm/dts/meson-axg-s400.dts b/arch/arm/dts/meson-axg-s400.dts
> index 18778ada7b..b0192a9720 100644
> --- a/arch/arm/dts/meson-axg-s400.dts
> +++ b/arch/arm/dts/meson-axg-s400.dts
> @@ -58,6 +58,8 @@
>   aliases {
>   serial0 = _AO;
>   serial1 = _A;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   linein: audio-codec@0 {
> diff --git a/arch/arm/dts/meson-g12a-sei510.dts 
> b/arch/arm/dts/meson-g12a-sei510.dts
> index c7a8736885..0e6378a320 100644
> --- a/arch/arm/dts/meson-g12a-sei510.dts
> +++ b/arch/arm/dts/meson-g12a-sei510.dts
> @@ -31,6 +31,9 @@
>   aliases {
>   serial0 = _AO;
>   ethernet0 = 
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   mono_dac: audio-codec-0 {
> diff --git a/arch/arm/dts/meson-g12a-u200.dts 
> b/arch/arm/dts/meson-g12a-u200.dts
> index 8551fbd4a4..88b4d365f8 100644
> --- a/arch/arm/dts/meson-g12a-u200.dts
> +++ b/arch/arm/dts/meson-g12a-u200.dts
> @@ -16,6 +16,9 @@
>   aliases {
>   serial0 = _AO;
>   ethernet0 = 
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   chosen {
> diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dts 
> b/arch/arm/dts/meson-g12b-odroid-n2.dts
> index 42f1540575..888429b1cc 100644
> --- a/arch/arm/dts/meson-g12b-odroid-n2.dts
> +++ b/arch/arm/dts/meson-g12b-odroid-n2.dts
> @@ -18,6 +18,9 @@
>   aliases {
>   serial0 = _AO;
>   ethernet0 = 
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   chosen {
> diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts 
> b/arch/arm/dts/meson-gxbb-odroidc2.dts
> index 54954b314a..1436002013 100644
> --- a/arch/arm/dts/meson-gxbb-odroidc2.dts
> +++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
> @@ -17,6 +17,9 @@
>   aliases {
>   serial0 = _AO;
>   ethernet0 = 
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   chosen {
> diff --git a/arch/arm/dts/meson-gxbb-p20x.dtsi 
> b/arch/arm/dts/meson-gxbb-p20x.dtsi
> index 0be0f2a5d2..d55f5e1abb 100644
> --- a/arch/arm/dts/meson-gxbb-p20x.dtsi
> +++ b/arch/arm/dts/meson-gxbb-p20x.dtsi
> @@ -11,6 +11,9 @@
>   aliases {
>   serial0 = _AO;
>   ethernet0 = 
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   chosen {
> diff --git a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts 
> b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> index 82b1c48511..6422e11e5e 100644
> --- a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> +++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> @@ -20,6 +20,9 @@
>   serial0 = _AO;
>   ethernet0 = 
>   spi0 = 
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   chosen {
> diff --git a/arch/arm/dts/meson-gxl-s905x-p212.dtsi 
> b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> index a1b31013ab..d712e9fa1d 100644
> --- a/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> +++ b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> @@ -17,6 +17,9 @@
>   serial0 = _AO;
>   serial1 = _A;
>   ethernet0 = 
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   chosen {
> diff --git a/arch/arm/dts/meson-gxm-khadas-vim2.dts 
> b/arch/arm/dts/meson-gxm-khadas-vim2.dts
> index 782e9edac8..723061f0e2 100644
> --- a/arch/arm/dts/meson-gxm-khadas-vim2.dts
> +++ b/arch/arm/dts/meson-gxm-khadas-vim2.dts
> @@ -20,6 +20,9 @@
>   serial0 = _AO;
>   serial1 = _A;
>   serial2 = _AO_B;
> + mmc0 = _emmc_a;
> + mmc1 = _emmc_b;
> + mmc2 = _emmc_c;
>   };
>  
>   chosen {
> diff --git a/arch/arm/dts/meson-sm1-sei610.dts 
> b/arch/arm/dts/meson-sm1-sei610.dts
> index 

Re: [PATCH] [FS] Print error message for unknown device type

[Wolfgang Denk]

Dear Heiko,

In message <3546d28c-f638-5357-a20f-5d03db762...@denx.de> you wrote:
>
> > File system commands like "ls" etc. require a device type parameter.
> > If an unknown type is specified, they return an error code but no
> > visible feedback to the user:
> > 
> >   -> ls FOOBAR 1:1 /
> >   ->
> > 
> > Add an error message to make clear what happens, and why.
> > 
> > Signed-off-by: Wolfgang Denk 
> > ---
> >   disk/part.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
>
> Tested on wandboard.
>
> Tested-by: Heiko Schocher 

Thanks for testing.

> > -   if (dev < 0)
> > +   if (dev < 0) {
> > +   printf("** Unknown device type %s **\n", ifname);
> > goto cleanup;
> > +   }
>
> It would be nice to have here a list of supported devices, so a user
> can see what are valid arguments for ifname.

Yes, you are absolutely right.  I aready thought about this, but I
have to admit that I got stuck in the code; there are several
complexities - code for example for blk_driver_lookup_typename()
is duplicated both in drivers/block/blk_legacy.c   and in
drivers/block/blk-uclass.c;  I was not able to find any exported
interface that actually allows to get a list of supported device
drivers, and the things I tried all looked really ugly to me.

Adding Simon to Cc: - he has designed and written all this code and
should know better.

Simon, what would be a clean and elegant approach to get such a list
of supported drivers ?


In any case I recommend to accept this patch as is; this other thing
is additional information that can /should get added later in a
spearate patch.

Best regards,

Wolfgang Denk

-- 
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
People don't like to be lectured to, but if you can make them  laugh,
their  defenses  come  down,  and for the time being they've accepted
whatever truth is embedded in your humor. - Paul Krassner

Re: [PATCH v2 0/3] Ethernet support for Raspberry Pi 4

[Matthias Brugger]

Hi Corentin,

On 22/01/2020 11:04, LABBE Corentin wrote:
> On Fri, Jan 17, 2020 at 01:20:44AM +, Andre Przywara wrote:
>> This series adds Ethernet support for the Raspberry Pi 4. The SoC
>> includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
>> device (no USB anymore!). Patch 1 provides a driver for that. There does
>> not seem to be publicly available documentation, so this is based on the
>> Linux driver, but stripped down to just provide what U-Boot needs.
>> Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
>> MAC lives in, while patch 3 enables it in the respective defconfigs.
>>
>> This version addresses the comments by the diligent reviewers and testers,
>> for a changelog see below.
>> To see the individual changes as patches, refer to [1].
>>
>> Please have a look and test it, I hope this helps to simplify
>> development, as you spare the SD card and its slot from heavy swapping.
>>
>> I dropped the Tested-by's, as there were changes in the code. Happy
>> to reapply them when people confirm that it still works for them.
>>
>> Cheers,
>> Andre.
>>
>> [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v2
>>
>> Changelog v1 ... v2:
>> - use native endianess functions when accessing MMIO registers
>> - use dev_* DM wrappers for accessing devicetree data
>> - round base and length for flush_dcache_range, plus a comment
>> - check and round length for invalidate_cache_range
>> - support RGMII_RXID PHY mode, to support mainline .dtb
>>
>> Amit Singh Tomar (3):
>>   net: Add support for Broadcom GENETv5 Ethernet controller
>>   rpi4: Update memory map to accommodate scb devices
>>   rpi4: Enable GENET Ethernet controller
>>
>>  arch/arm/mach-bcm283x/init.c |   6 +-
>>  configs/rpi_4_32b_defconfig  |   2 +
>>  configs/rpi_4_defconfig  |   2 +
>>  configs/rpi_arm64_defconfig  |   1 +
>>  drivers/net/Kconfig  |   7 +
>>  drivers/net/Makefile |   1 +
>>  drivers/net/bcmgenet.c   | 722 
>> +++
>>  7 files changed, 738 insertions(+), 3 deletions(-)
>>  create mode 100644 drivers/net/bcmgenet.c
>>
>> -- 
>> 2.14.5
>>
> 
> Hello
> 
> I have tested it again and grabbing DHCP and doing TFTP works.
> But I still fail to boot any kernel.
> 
> U-Boot 2020.01-00660-gec13baddca (Jan 21 2020 - 11:38:05 +0100)
> DRAM:  3.9 GiB
> RPI 4 Model B (0xc03111)
> MMC:   emmc2@7e34: 0, mmcnr@7e30: 1
> Loading Environment from FAT... *** Warning - bad CRC, using default 
> environment
> In:serial
> Out:   serial
> Err:   serial
> Net:   eth0: genet@7d58
> 
> dhcp
> 
> genet@7d58 Waiting for PHY auto negotiation to complete... done
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> DHCP client bound to address 192.168.66.27 (1255 ms)
> 
> I use 0x8 for kernel, 0x0270 for RAMfs, 0x0240 for DTB and booti 
> 0x0008 0x0270 0x0240 for starting kernel.
> Both mainline kernel and rpi kernel wont boot.
> 
> But this is unrelated to your serie.

Thanks for bringing this up. I only tested tftp and was able to run a grub
binary. But I realized that with the patches applied, I can't boot a kernel from
the SD card neither.

As I have grub2 booting the kernel I wonder if you have the same problems?

Regards,
Matthias

> Tested-by: Corentin Labbe 
> 
> Thanks
> Regards
> 

[Patchv4 3/3] arm: dts: Add cd-gpio for eMMC

[Anand Moon]

Add cd-gpio property for eMMC node.

Signed-off-by: Anand Moon 
---
New patch in this series
---
 arch/arm/dts/meson-g12b-odroid-n2.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dts 
b/arch/arm/dts/meson-g12b-odroid-n2.dts
index 888429b1cc..23ec14abe7 100644
--- a/arch/arm/dts/meson-g12b-odroid-n2.dts
+++ b/arch/arm/dts/meson-g12b-odroid-n2.dts
@@ -449,6 +449,7 @@
max-frequency = <2>;
disable-wp;
 
+   cd-gpios = < GPIOH_7 GPIO_ACTIVE_LOW>; /* eMMC_nDET */
mmc-pwrseq = <_pwrseq>;
vmmc-supply = <_3v3>;
vqmmc-supply = <_1v8>;
-- 
2.25.0

Re: [PATCH] [FS] Print error message for unknown device type

[Nikita Ermakov]

On Wed, 22 Jan 2020 at 14:09, Wolfgang Denk  wrote:

> File system commands like "ls" etc. require a device type parameter.
> If an unknown type is specified, they return an error code but no
> visible feedback to the user:
>
>  -> ls FOOBAR 1:1 /
>  ->
>
> Add an error message to make clear what happens, and why.
>
> Signed-off-by: Wolfgang Denk 
> ---
>  disk/part.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/disk/part.c b/disk/part.c
> index 8982ef3bae..14000835c8 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -512,8 +512,10 @@ int blk_get_device_part_str(const char *ifname, const
> char *dev_part_str,
>
> /* Look up the device */
> dev = blk_get_device_by_str(ifname, dev_str, dev_desc);
> -   if (dev < 0)
> +   if (dev < 0) {
> +   printf("** Unknown device type %s **\n", ifname);
> goto cleanup;
> +   }
>
> /* Convert partition ID string to number */
> if (!part_str || !*part_str) {
> --
> 2.23.0
>
>
Oww, I've submitted the similar patch to this mailing list recently but it
is waiting for moderator approval :)

-- 
Thanks,
Nikita
B8 00 4C CD 21

[Patchv4 2/3] arm: dts: Add mmc alias to avoid warning

[Anand Moon]

Add missing mmc alias to dts nodes to avoid
below debug warning.

mmc_bind: alias ret=-2, devnum=-1
mmc_bind: alias ret=-2, devnum=-1

Signed-off-by: Anand Moon 
---
 arch/arm/dts/meson-axg-s400.dts   | 2 ++
 arch/arm/dts/meson-g12a-sei510.dts| 3 +++
 arch/arm/dts/meson-g12a-u200.dts  | 3 +++
 arch/arm/dts/meson-g12b-odroid-n2.dts | 3 +++
 arch/arm/dts/meson-gxbb-odroidc2.dts  | 3 +++
 arch/arm/dts/meson-gxbb-p20x.dtsi | 3 +++
 arch/arm/dts/meson-gxl-s805x-libretech-ac.dts | 3 +++
 arch/arm/dts/meson-gxl-s905x-p212.dtsi| 3 +++
 arch/arm/dts/meson-gxm-khadas-vim2.dts| 3 +++
 arch/arm/dts/meson-sm1-sei610.dts | 3 +++
 10 files changed, 29 insertions(+)

diff --git a/arch/arm/dts/meson-axg-s400.dts b/arch/arm/dts/meson-axg-s400.dts
index 18778ada7b..b0192a9720 100644
--- a/arch/arm/dts/meson-axg-s400.dts
+++ b/arch/arm/dts/meson-axg-s400.dts
@@ -58,6 +58,8 @@
aliases {
serial0 = _AO;
serial1 = _A;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
linein: audio-codec@0 {
diff --git a/arch/arm/dts/meson-g12a-sei510.dts 
b/arch/arm/dts/meson-g12a-sei510.dts
index c7a8736885..0e6378a320 100644
--- a/arch/arm/dts/meson-g12a-sei510.dts
+++ b/arch/arm/dts/meson-g12a-sei510.dts
@@ -31,6 +31,9 @@
aliases {
serial0 = _AO;
ethernet0 = 
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
mono_dac: audio-codec-0 {
diff --git a/arch/arm/dts/meson-g12a-u200.dts b/arch/arm/dts/meson-g12a-u200.dts
index 8551fbd4a4..88b4d365f8 100644
--- a/arch/arm/dts/meson-g12a-u200.dts
+++ b/arch/arm/dts/meson-g12a-u200.dts
@@ -16,6 +16,9 @@
aliases {
serial0 = _AO;
ethernet0 = 
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
chosen {
diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dts 
b/arch/arm/dts/meson-g12b-odroid-n2.dts
index 42f1540575..888429b1cc 100644
--- a/arch/arm/dts/meson-g12b-odroid-n2.dts
+++ b/arch/arm/dts/meson-g12b-odroid-n2.dts
@@ -18,6 +18,9 @@
aliases {
serial0 = _AO;
ethernet0 = 
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
chosen {
diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts 
b/arch/arm/dts/meson-gxbb-odroidc2.dts
index 54954b314a..1436002013 100644
--- a/arch/arm/dts/meson-gxbb-odroidc2.dts
+++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
@@ -17,6 +17,9 @@
aliases {
serial0 = _AO;
ethernet0 = 
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
chosen {
diff --git a/arch/arm/dts/meson-gxbb-p20x.dtsi 
b/arch/arm/dts/meson-gxbb-p20x.dtsi
index 0be0f2a5d2..d55f5e1abb 100644
--- a/arch/arm/dts/meson-gxbb-p20x.dtsi
+++ b/arch/arm/dts/meson-gxbb-p20x.dtsi
@@ -11,6 +11,9 @@
aliases {
serial0 = _AO;
ethernet0 = 
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
chosen {
diff --git a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts 
b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
index 82b1c48511..6422e11e5e 100644
--- a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
+++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
@@ -20,6 +20,9 @@
serial0 = _AO;
ethernet0 = 
spi0 = 
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
chosen {
diff --git a/arch/arm/dts/meson-gxl-s905x-p212.dtsi 
b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
index a1b31013ab..d712e9fa1d 100644
--- a/arch/arm/dts/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
@@ -17,6 +17,9 @@
serial0 = _AO;
serial1 = _A;
ethernet0 = 
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
chosen {
diff --git a/arch/arm/dts/meson-gxm-khadas-vim2.dts 
b/arch/arm/dts/meson-gxm-khadas-vim2.dts
index 782e9edac8..723061f0e2 100644
--- a/arch/arm/dts/meson-gxm-khadas-vim2.dts
+++ b/arch/arm/dts/meson-gxm-khadas-vim2.dts
@@ -20,6 +20,9 @@
serial0 = _AO;
serial1 = _A;
serial2 = _AO_B;
+   mmc0 = _emmc_a;
+   mmc1 = _emmc_b;
+   mmc2 = _emmc_c;
};
 
chosen {
diff --git a/arch/arm/dts/meson-sm1-sei610.dts 
b/arch/arm/dts/meson-sm1-sei610.dts
index 3435aaa4e8..3aafc20ccd 100644
--- a/arch/arm/dts/meson-sm1-sei610.dts
+++ b/arch/arm/dts/meson-sm1-sei610.dts
@@ -17,6 +17,9 @@
aliases {
serial0 = _AO;
ethernet0 = 
+   

[Patchv4 1/3] mmc: meson-gx: Fix clk phase tuning for MMC

[Anand Moon]

As per mainline line kernel fix the clk tunig phase for
mmc, set Core=180, Tx=180, Rx=0 clk phase for mmc initialization.
As per S905X and S922X datasheet set the default values
for clk tuning.

Signed-off-by: Anand Moon 
---
Changes from previous
v3  Fix the initialization of core clk tunning phase as per datasheet.
Fix the commit message.

v2: Fix the clk phase macro to support PHASE_180
drop the wrong CLK_CORE_PHASE_MASK macro.

v1: use the mainline kernel tuning for clk tuning.

Fixed the commmit messages.
Patch v1:
https://patchwork.ozlabs.org/patch/1201208/

Before these changes.
clock is enabled (380953Hz)
clock is enabled (2500Hz)
After these changes
clock is enabled (380953Hz)
clock is enabled (2500Hz)
clock is enabled (5200Hz)
Test on Odroid N2 and Odroid C2 with eMMC and microSD cards
---
 arch/arm/include/asm/arch-meson/sd_emmc.h | 11 ++-
 drivers/mmc/meson_gx_mmc.c| 38 +++
 2 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h 
b/arch/arm/include/asm/arch-meson/sd_emmc.h
index e3a72c8b66..c193547aad 100644
--- a/arch/arm/include/asm/arch-meson/sd_emmc.h
+++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
@@ -7,6 +7,7 @@
 #define __SD_EMMC_H__
 
 #include 
+#include 
 
 #define SDIO_PORT_A0
 #define SDIO_PORT_B1
@@ -19,14 +20,8 @@
 #define   CLK_MAX_DIV  63
 #define   CLK_SRC_24M  (0 << 6)
 #define   CLK_SRC_DIV2 (1 << 6)
-#define   CLK_CO_PHASE_000 (0 << 8)
-#define   CLK_CO_PHASE_090 (1 << 8)
-#define   CLK_CO_PHASE_180 (2 << 8)
-#define   CLK_CO_PHASE_270 (3 << 8)
-#define   CLK_TX_PHASE_000 (0 << 10)
-#define   CLK_TX_PHASE_090 (1 << 10)
-#define   CLK_TX_PHASE_180 (2 << 10)
-#define   CLK_TX_PHASE_270 (3 << 10)
+#define  UPDATE(x, h, l)   (((x) << (l)) & GENMASK((h), 
(l)))
+
 #define   CLK_ALWAYS_ONBIT(24)
 
 #define MESON_SD_EMMC_CFG  0x44
diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index 86c1a7164a..67b1b075ab 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -51,12 +51,38 @@ static void meson_mmc_config_clock(struct mmc *mmc)
}
clk_div = DIV_ROUND_UP(clk, mmc->clock);
 
-   /* 180 phase core clock */
-   meson_mmc_clk |= CLK_CO_PHASE_180;
-
-   /* 180 phase tx clock */
-   meson_mmc_clk |= CLK_TX_PHASE_000;
-
+   /* Clock divider */
+   meson_mmc_clk = GENMASK(5, 0);
+   /* Clock source 1: Fix PLL, 1000MHz */
+   meson_mmc_clk |= UPDATE(1, 7, 6);
+   /* Core clock phase 2:180 */
+   meson_mmc_clk |= UPDATE(2, 9, 8);
+   /* TX clock phase 2:180 */
+   meson_mmc_clk |= UPDATE(2, 11, 10);
+   /* RX clock phase 0:180 */
+   meson_mmc_clk |= UPDATE(0, 13, 12);
+#ifdef CONFIG_MESON_GX
+   /* TX clock delay line */
+   meson_mmc_clk |= GENMASK(19, 16);
+   /* RX clock delay line */
+   meson_mmc_clk |= GENMASK(23, 20);
+   /* clk always on */
+   meson_mmc_clk |= BIT(20);
+   /* clk irq sdio sleep */
+   meson_mmc_clk |= BIT(25);
+#endif
+#if (defined(CONFIG_MESON_AXG) || defined(CONFIG_MESON_G12A))
+   /* TX clock delay line */
+   meson_mmc_clk |=  GENMASK(21, 16);
+   /* RX clock delay line */
+   meson_mmc_clk |=  GENMASK(27, 22);
+   /* clk always on */
+   meson_mmc_clk |= BIT(28);
+   /* clk irq sdio sleep */
+   meson_mmc_clk |= BIT(29);
+   /* clk irq sdio sleep_ds */
+   meson_mmc_clk |= BIT(30);
+#endif
/* clock settings */
meson_mmc_clk |= clk_src;
meson_mmc_clk |= clk_div;
-- 
2.25.0

[Patchv4 0/3] Odroid n2 using eMMC would fail to boot up

[Anand Moon]

Here are some small changes to fix booting of Odroid N2 using eMMC.
Fixed the clk tunnig during mmc initialization.
Added two new patches to fix warning

Build and tested on top of below patches
[0] https://patchwork.ozlabs.org/patch/1213648/
[1] https://patchwork.ozlabs.org/patch/1213650/

Tested on below eMMC module on Odroid N2 and C2
new orange - eMMC AJNB4R 14.6 GiB MMC 5.1
old back   - eMMC CGND3R 58.2 GiB MMC 5.0

Prevoius changes: 
Fixed the clk tuning as per mainline kernel

[3]v1 https://patchwork.ozlabs.org/cover/1201206/
[4]v2 https://patchwork.ozlabs.org/cover/1215217/
[5]v3 https://www.mail-archive.com/u-boot@lists.denx.de/msg351859.html

-Anand

Anand Moon (3):
  mmc: meson-gx: Fix clk phase tuning for MMC
  arm: dts: Add mmc alias to avoid warning
  arm: dts: Add cd-gpio for eMMC

 arch/arm/dts/meson-axg-s400.dts   |  2 +
 arch/arm/dts/meson-g12a-sei510.dts|  3 ++
 arch/arm/dts/meson-g12a-u200.dts  |  3 ++
 arch/arm/dts/meson-g12b-odroid-n2.dts |  4 ++
 arch/arm/dts/meson-gxbb-odroidc2.dts  |  3 ++
 arch/arm/dts/meson-gxbb-p20x.dtsi |  3 ++
 arch/arm/dts/meson-gxl-s805x-libretech-ac.dts |  3 ++
 arch/arm/dts/meson-gxl-s905x-p212.dtsi|  3 ++
 arch/arm/dts/meson-gxm-khadas-vim2.dts|  3 ++
 arch/arm/dts/meson-sm1-sei610.dts |  3 ++
 arch/arm/include/asm/arch-meson/sd_emmc.h | 11 ++
 drivers/mmc/meson_gx_mmc.c| 38 ---
 12 files changed, 65 insertions(+), 14 deletions(-)

-- 
2.25.0

Re: [PATCH] Output information about device look up failure.

[Wolfgang Denk]

Dear Nikita,

In message <20200121221005.9303-1-coff...@gmail.com> you wrote:
> In the case of error while device look up (e.g. wrong interface type
> was specified) put a message about it even if debug was not enable.
>
> Signed-off-by: Nikita Ermakov 
> ---
>  disk/part.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/disk/part.c b/disk/part.c
> index 8982ef3bae..280e3e4f42 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -513,7 +513,10 @@ int blk_get_device_part_str(const char *ifname, const 
> char *dev_part_str,
>   /* Look up the device */
>   dev = blk_get_device_by_str(ifname, dev_str, dev_desc);
>   if (dev < 0)
> + {
> + printf("** Look up for the device %s %s failed **\n", ifname, 
> dev_str);
>   goto cleanup;
> + }

Please see my other patch instead.

You are using incorrect brace style, and I think your error message
is a bit misleading - "look up failed" sounds like some internal
error, the reason of which is still unclear.  We should instead say
clearly the the given device type is not supported/known in the
given configuration.

Thanks.

Best regards,

Wolfgang Denk

-- 
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
That's the thing about people who think  they  hate  computers.  What
they really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"

Re: [PATCH v2 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Fri, Jan 17, 2020 at 01:20:44AM +, Andre Przywara wrote:
> This series adds Ethernet support for the Raspberry Pi 4. The SoC
> includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
> device (no USB anymore!). Patch 1 provides a driver for that. There does
> not seem to be publicly available documentation, so this is based on the
> Linux driver, but stripped down to just provide what U-Boot needs.
> Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
> MAC lives in, while patch 3 enables it in the respective defconfigs.
> 
> This version addresses the comments by the diligent reviewers and testers,
> for a changelog see below.
> To see the individual changes as patches, refer to [1].
> 
> Please have a look and test it, I hope this helps to simplify
> development, as you spare the SD card and its slot from heavy swapping.
> 
> I dropped the Tested-by's, as there were changes in the code. Happy
> to reapply them when people confirm that it still works for them.
> 
> Cheers,
> Andre.
> 
> [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v2
> 
> Changelog v1 ... v2:
> - use native endianess functions when accessing MMIO registers
> - use dev_* DM wrappers for accessing devicetree data
> - round base and length for flush_dcache_range, plus a comment
> - check and round length for invalidate_cache_range
> - support RGMII_RXID PHY mode, to support mainline .dtb
> 
> Amit Singh Tomar (3):
>   net: Add support for Broadcom GENETv5 Ethernet controller
>   rpi4: Update memory map to accommodate scb devices
>   rpi4: Enable GENET Ethernet controller
> 
>  arch/arm/mach-bcm283x/init.c |   6 +-
>  configs/rpi_4_32b_defconfig  |   2 +
>  configs/rpi_4_defconfig  |   2 +
>  configs/rpi_arm64_defconfig  |   1 +
>  drivers/net/Kconfig  |   7 +
>  drivers/net/Makefile |   1 +
>  drivers/net/bcmgenet.c   | 722 
> +++
>  7 files changed, 738 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/bcmgenet.c
> 
> -- 
> 2.14.5
> 

Hello

I have tested it again and grabbing DHCP and doing TFTP works.
But I still fail to boot any kernel.

U-Boot 2020.01-00660-gec13baddca (Jan 21 2020 - 11:38:05 +0100)
DRAM:  3.9 GiB
RPI 4 Model B (0xc03111)
MMC:   emmc2@7e34: 0, mmcnr@7e30: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment
In:serial
Out:   serial
Err:   serial
Net:   eth0: genet@7d58

dhcp

genet@7d58 Waiting for PHY auto negotiation to complete... done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.66.27 (1255 ms)

I use 0x8 for kernel, 0x0270 for RAMfs, 0x0240 for DTB and booti 
0x0008 0x0270 0x0240 for starting kernel.
Both mainline kernel and rpi kernel wont boot.

But this is unrelated to your serie.
Tested-by: Corentin Labbe 

Thanks
Regards

[PATCH] Output information about device look up failure.

[Nikita Ermakov]

In the case of error while device look up (e.g. wrong interface type
was specified) put a message about it even if debug was not enable.

Signed-off-by: Nikita Ermakov 
---
 disk/part.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/disk/part.c b/disk/part.c
index 8982ef3bae..280e3e4f42 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -513,7 +513,10 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
/* Look up the device */
dev = blk_get_device_by_str(ifname, dev_str, dev_desc);
if (dev < 0)
+   {
+   printf("** Look up for the device %s %s failed **\n", ifname, 
dev_str);
goto cleanup;
+   }
 
/* Convert partition ID string to number */
if (!part_str || !*part_str) {
-- 
2.24.1

Re: [PATCH] [FS] Print error message for unknown device type

[Heiko Schocher]

Hello Wolfgang,

Am 22.01.2020 um 12:08 schrieb Wolfgang Denk:

File system commands like "ls" etc. require a device type parameter.
If an unknown type is specified, they return an error code but no
visible feedback to the user:

  -> ls FOOBAR 1:1 /
  ->

Add an error message to make clear what happens, and why.

Signed-off-by: Wolfgang Denk 
---
  disk/part.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)


Tested on wandboard.

Tested-by: Heiko Schocher 



diff --git a/disk/part.c b/disk/part.c
index 8982ef3bae..14000835c8 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -512,8 +512,10 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
  
  	/* Look up the device */

dev = blk_get_device_by_str(ifname, dev_str, dev_desc);
-   if (dev < 0)
+   if (dev < 0) {
+   printf("** Unknown device type %s **\n", ifname);
goto cleanup;
+   }


It would be nice to have here a list of supported devices, so a user
can see what are valid arguments for ifname.

  
  	/* Convert partition ID string to number */

if (!part_str || !*part_str) {



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

[PATCH] [FS] Print error message for unknown device type

[Wolfgang Denk]

File system commands like "ls" etc. require a device type parameter.
If an unknown type is specified, they return an error code but no
visible feedback to the user:

 -> ls FOOBAR 1:1 /
 ->

Add an error message to make clear what happens, and why.

Signed-off-by: Wolfgang Denk 
---
 disk/part.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/disk/part.c b/disk/part.c
index 8982ef3bae..14000835c8 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -512,8 +512,10 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
 
/* Look up the device */
dev = blk_get_device_by_str(ifname, dev_str, dev_desc);
-   if (dev < 0)
+   if (dev < 0) {
+   printf("** Unknown device type %s **\n", ifname);
goto cleanup;
+   }
 
/* Convert partition ID string to number */
if (!part_str || !*part_str) {
-- 
2.23.0

RE: [PATCH v3] board: fsl: lx2160a: Add support to reset to eMMC

[Priyanka Jain (OSS)]

>-Original Message-
>From: U-Boot  On Behalf Of Meenakshi
>Aggarwal
>Sent: Thursday, January 16, 2020 9:13 PM
>To: u-boot@lists.denx.de; Priyanka Jain 
>Subject: [PATCH v3] board: fsl: lx2160a: Add support to reset to eMMC
>
>Add support of "qixis_reset emmc" command for lx2160a based platforms
>
>Signed-off-by: Meenakshi Aggarwal 
>
>---
>Changes:
>
>   v2:
>   - Update in commit message
>   - using set_rcw_src() in place of QIXIS_WRITE()
>
>   v3:
>   - update in commit message
Whenever you send a next version , please mark previous version as superseded.
It is sometimes difficult to isolate specially if subject is different.
>
>Signed-off-by: Meenakshi Aggarwal 
>---
> board/freescale/common/qixis.c| 6 ++
> board/freescale/lx2160a/lx2160a.c | 2 ++
> include/configs/lx2160aqds.h  | 2 ++
> include/configs/lx2160ardb.h  | 2 ++
> 4 files changed, 12 insertions(+)
>
>diff --git a/board/freescale/common/qixis.c
>b/board/freescale/common/qixis.c index 716c93b..ab229b9 100644
>--- a/board/freescale/common/qixis.c
>+++ b/board/freescale/common/qixis.c
>@@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
>  * Copyright 2011 Freescale Semiconductor
>+ * Copyright 2020 NXP
>  * Author: Shengzhou Liu 
>  *
>  * This file provides support for the QIXIS of some Freescale reference 
> boards.
>@@ -287,8 +288,12 @@ static int qixis_reset_cmd(cmd_tbl_t *cmdtp, int flag,
>int argc, char * const ar  #ifdef QIXIS_LBMAP_EMMC
>   QIXIS_WRITE(rst_ctl, 0x30);
>   QIXIS_WRITE(rcfg_ctl, 0);
>+#ifdef NON_EXTENDED_DUTCFG
>+  set_rcw_src(QIXIS_RCW_SRC_EMMC);
>+#else
>   set_lbmap(QIXIS_LBMAP_EMMC);
It would be better to just enclosed above in #ifndef
>   set_rcw_src(QIXIS_RCW_SRC_EMMC);
>+#endif
>   QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_IDLE);
>   QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_START);
>#else @@ -365,6 +370,7 @@ U_BOOT_CMD(
>   "qixis watchdog  - set the watchdog period\n"
>   "   period: 1s 2s 4s 8s 16s 32s 1min 2min 4min 8min\n"
>   "qixis_reset dump - display the QIXIS registers\n"
>+  "qixis_reset emmc - reset to emmc\n"
>   "qixis_reset switch - display switch\n"
>   );
> #endif
>diff --git a/board/freescale/lx2160a/lx2160a.c
>b/board/freescale/lx2160a/lx2160a.c
>index dd3cd45..79abcd8 100644
>--- a/board/freescale/lx2160a/lx2160a.c
>+++ b/board/freescale/lx2160a/lx2160a.c
>@@ -325,6 +325,8 @@ int checkboard(void)
>
>   if (src == BOOT_SOURCE_SD_MMC) {
>   puts("SD\n");
>+  } else if (src == BOOT_SOURCE_SD_MMC2) {
>+  puts("eMMC\n");
>   } else {
>   sw = QIXIS_READ(brdcfg[0]);
>   sw = (sw >> QIXIS_XMAP_SHIFT) & QIXIS_XMAP_MASK; diff --git
>a/include/configs/lx2160aqds.h b/include/configs/lx2160aqds.h index
>f523b37..56a50d3 100644
>--- a/include/configs/lx2160aqds.h
>+++ b/include/configs/lx2160aqds.h
>@@ -22,7 +22,9 @@
> #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE 0x08
> #define QIXIS_LBMAP_MASK  0x0f
> #define QIXIS_LBMAP_SD
>+#define QIXIS_LBMAP_EMMC
> #define QIXIS_RCW_SRC_SD  0x08
>+#define QIXIS_RCW_SRC_EMMC 0x09
> #define NON_EXTENDED_DUTCFG
> #define QIXIS_SDID_MASK   0x07
> #define QIXIS_ESDHC_NO_ADAPTER0x7
>diff --git a/include/configs/lx2160ardb.h b/include/configs/lx2160ardb.h index
>6ff1c24..5b530f0 100644
>--- a/include/configs/lx2160ardb.h
>+++ b/include/configs/lx2160ardb.h
>@@ -22,7 +22,9 @@
> #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE 0x08
> #define QIXIS_LBMAP_MASK  0x0f
> #define QIXIS_LBMAP_SD
>+#define QIXIS_LBMAP_EMMC
> #define QIXIS_RCW_SRC_SD   0x08
>+#define QIXIS_RCW_SRC_EMMC 0x09
> #define NON_EXTENDED_DUTCFG
>
> /* VID */
>--
>1.9.1
-Priyanka

[PATCH 2/2] armv8: ls2088a: Updates secure boot headers offset

[Priyanka Singh]

Updates the secure boot headers offsets of Kernel and other
firmware images for SD and NOR boot sources used by
esbc_validate command.

Signed-off-by: Priyanka Singh 
---
 include/configs/ls2080aqds.h | 12 -
 include/configs/ls2080ardb.h | 52 ++--
 2 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/include/configs/ls2080aqds.h b/include/configs/ls2080aqds.h
index e2a897557d..f71bf95978 100644
--- a/include/configs/ls2080aqds.h
+++ b/include/configs/ls2080aqds.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright 2017, 2019 NXP
+ * Copyright 2017, 2019-2020 NXP
  * Copyright 2015 Freescale Semiconductor
  */
 
@@ -365,8 +365,8 @@ unsigned long get_board_ddr_clk(void);
"kernel_load=0xa000\0"  \
"kernel_size=0x280\0"   \
"mcmemsize=0x4000\0"\
-   "mcinitcmd=esbc_validate 0x58070;"  \
-   "esbc_validate 0x58074;"\
+   "mcinitcmd=esbc_validate 0x58064;"  \
+   "esbc_validate 0x58068;"\
"fsl_mc start mc 0x580a0"   \
" 0x580e0 \0"
 #else
@@ -394,7 +394,7 @@ unsigned long get_board_ddr_clk(void);
"kernel_size=0x280\0"   \
"kernel_size_sd=0x14000\0"   \
"load_addr=0xa000\0"\
-   "kernelheader_addr=0x58080\0"   \
+   "kernelheader_addr=0x58060\0"   \
"kernelheader_addr_r=0x8020\0"  \
"kernelheader_size=0x4\0"   \
"BOARD=ls2088aqds\0" \
@@ -447,7 +447,7 @@ unsigned long get_board_ddr_clk(void);
 #ifdef CONFIG_TFABOOT
 #define SD_BOOTCOMMAND \
"env exists mcinitcmd && env exists secureboot "\
-   "&& mmcinfo && mmc read $load_addr 0x3c00 0x800 " \
+   "&& mmcinfo && mmc read $load_addr 0x3600 0x800 " \
"&& esbc_validate $load_addr; " \
"env exists mcinitcmd && run mcinitcmd "\
"&& mmc read 0x80d0 0x6800 0x800 "  \
@@ -457,7 +457,7 @@ unsigned long get_board_ddr_clk(void);
 
 #define IFC_NOR_BOOTCOMMAND\
"env exists mcinitcmd && env exists secureboot "\
-   "&& esbc_validate 0x58078; env exists mcinitcmd "\
+   "&& esbc_validate 0x5806C; env exists mcinitcmd "\
"&& fsl_mc lazyapply dpl 0x580d0;"  \
"run nor_bootcmd; " \
"env exists secureboot && esbc_halt;"
diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index ee9b3484dd..6be1ac95c3 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright 2017, 2019 NXP
+ * Copyright 2017, 2019-2020 NXP
  * Copyright 2015 Freescale Semiconductor
  */
 
@@ -340,46 +340,46 @@ unsigned long get_board_sys_clk(void);
 #ifdef CONFIG_TFABOOT
 #define QSPI_MC_INIT_CMD   \
"env exists secureboot && " \
-   "esbc_validate 0x2070 && "  \
-   "esbc_validate 0x2074;" \
+   "esbc_validate 0x2064 && "  \
+   "esbc_validate 0x2068;" \
"fsl_mc start mc 0x20a0 0x20e0 \0"
 #define SD_MC_INIT_CMD \
"mmcinfo;mmc read 0x80a0 0x5000 0x1200;" \
"mmc read 0x80e0 0x7000 0x800;" \
"env exists secureboot && " \
-   "mmc read 0x8070 0x3800 0x20 && "   \
-   "mmc read 0x8074 0x3A00 0x20 && "   \
-   "esbc_validate 0x8070 && "  \
-   "esbc_validate 0x8074 ;"\
+   "mmc read 0x8064 0x3200 0x20 && "   \
+   "mmc read 0x8068 0x3400 0x20 && "   \
+   "esbc_validate 0x8064 && "  \
+   "esbc_validate 0x8068 ;"\
"fsl_mc start mc 0x80a0 0x80e0\0"
 #define IFC_MC_INIT_CMD\
"env exists secureboot && " \
-   "esbc_validate 0x58070 && " \
-   "esbc_validate 0x58074; "   \
+   "esbc_validate 0x58064 && " \
+   "esbc_validate 0x58068; "   \
"fsl_mc start mc 0x580a0 0x580e0 \0"
 #else
 #ifdef CONFIG_QSPI_BOOT
 #define MC_INIT_CMD\
"mcinitcmd=env exists secureboot && "   \
-   "esbc_validate 0x2070 && "  \
-   "esbc_validate 0x2074;" \
+   "esbc_validate 0x2064 && "  \
+   "esbc_validate 0x2068;" \
"fsl_mc start mc 0x20a0 0x20e0 \0"
 #elif 

Re: [PATCH v3 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Baruch Siach]

Hi Joel,

On Wed, Jan 22 2020, Joel Johnson wrote:
> On 2020-01-21 10:49, Baruch Siach wrote:
>> On Tue, Jan 21, 2020 at 10:32:17AM -0700, Joel Johnson wrote:
>>> Add a unique entry for ClearFog Base variant, reflected in the board
>>> name and adjusted SerDes topology.
>>>
>>> Signed-off-by: Joel Johnson 
>>>
>>> ---
>>>
>>> v2 changes:
>>>   - reworked based on Baruch's run-time TLV EEPROM detection series
>>> v3 changes:
>>>   - rebased on mvebu merged run-time TLV EEPROM detection series
>>>   - minor update to help test regarding runtime detection failures
>>>
>>> ---
>>>  arch/arm/mach-mvebu/Kconfig|  2 ++
>>>  board/solidrun/clearfog/Kconfig| 18 ++
>>>  board/solidrun/clearfog/clearfog.c | 12 
>>>  3 files changed, 32 insertions(+)
>>>  create mode 100644 board/solidrun/clearfog/Kconfig
>>>
>>> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
>>> index bc5eaa5a76..161dee937f 100644
>>> --- a/arch/arm/mach-mvebu/Kconfig
>>> +++ b/arch/arm/mach-mvebu/Kconfig
>>> @@ -280,4 +280,6 @@ config SECURED_MODE_CSK_INDEX
>>> default 0
>>> depends on SECURED_MODE_IMAGE
>>>
>>> +source "board/solidrun/clearfog/Kconfig"
>>> +
>>>  endif
>>> diff --git a/board/solidrun/clearfog/Kconfig
>>> b/board/solidrun/clearfog/Kconfig
>>> new file mode 100644
>>> index 00..936d5918f8
>>> --- /dev/null
>>> +++ b/board/solidrun/clearfog/Kconfig
>>> @@ -0,0 +1,18 @@
>>> +menu "ClearFog configuration"
>>> +   depends on TARGET_CLEARFOG
>>> +
>>> +config TARGET_CLEARFOG_BASE
>>> +   bool "Use ClearFog Base static configuration"
>>> +   help
>>> + Use the ClearFog Base as the static configuration instead of the
>>> + default which uses the ClearFog Pro.
>>> +
>>> + Runtime board detection is always attempted and used if
>>> available. The
>>> + static configuration is used as a fallback in cases where runtime
>>> + detection is disabled, is not available in hardware, or otherwise
>>> fails.
>>> +
>>> + Only newer revisions of the ClearFog product line support runtime
>>> + detection via additional EEPROM hardware. This option enables
>>> selecting
>>> + the Base variant for older hardware revisions.
>>> +
>>> +endmenu
>>> diff --git a/board/solidrun/clearfog/clearfog.c
>>> b/board/solidrun/clearfog/clearfog.c
>>> index e268ef55a2..e77b9465d4 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -47,7 +47,11 @@ static struct serdes_map board_serdes_map[] = {
>>> {SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>>> {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>>> {USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>>> +#if defined (CONFIG_TARGET_CLEARFOG_BASE)
>>> +   {USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>>> +#else
>>> {PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>>> +#endif
>>
>> I'd prefer run-time test instead of '#ifdefs' that IMO make the code harder
>> to
>> read. Something like this (build tested only):
>>
>> diff --git a/board/solidrun/clearfog/clearfog.c
>> b/board/solidrun/clearfog/clearfog.c
>> index e268ef55a2a0..202c60cb7841 100644
>> --- a/board/solidrun/clearfog/clearfog.c
>> +++ b/board/solidrun/clearfog/clearfog.c
>> @@ -55,7 +55,8 @@ int hws_board_topology_load(struct serdes_map
>> **serdes_map_array, u8 *count)
>>  {
>>  cf_read_tlv_data();
>>
>> -if (sr_product_is(_tlv_data, "Clearfog GTR")) {
>> +if (sr_product_is(_tlv_data, "Clearfog GTR") ||
>> +CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE)) {
>>  board_serdes_map[0].serdes_type = PEX0;
>>  board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
>>  board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
>> @@ -172,6 +173,9 @@ int checkboard(void)
>>  {
>>  char *board = "ClearFog";
>>
>> +if (CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
>> +board = "ClearFog Base";
>> +
>>  cf_read_tlv_data();
>>  if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
>>  board = cf_tlv_data.tlv_product_name[0];
>> @@ -194,7 +198,8 @@ int board_late_init(void)
>>  {
>>  cf_read_tlv_data();
>>
>> -if (sr_product_is(_tlv_data, "Clearfog Base"))
>> +if (sr_product_is(_tlv_data, "Clearfog Base") ||
>> +CONFIG_IS_ENABLED(TARGET_CLEARFOG_BASE))
>>  env_set("fdtfile", "armada-388-clearfog-base.dtb");
>>  else if (sr_product_is(_tlv_data, "Clearfog GTR S4"))
>>  env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
>>
>> What do you think?
>>
>> baruch
>
> I'll have to revisit and test to be sure, but I believe the reason I didn't go
> that route is because I wasn't able to get the CONFIG_IS_ENABLED macro version
> to trigger when building SPL, although it worked for the main path. I know
> that was the case for something I was working up, but I don't recall whether
> it was this patch 

[PATCH 1/2] armv8: ls1088a: Updates secure boot headers offset

[Priyanka Singh]

Updates the secure boot headers offsets of Kernel and other
firmware images for SD and QSPI boot sources used by
esbc_validate command.

Signed-off-by: Priyanka Singh 
---
 include/configs/ls1088aqds.h |  6 ++--
 include/configs/ls1088ardb.h | 60 ++--
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/include/configs/ls1088aqds.h b/include/configs/ls1088aqds.h
index 85e20617e6..f3a87df26a 100644
--- a/include/configs/ls1088aqds.h
+++ b/include/configs/ls1088aqds.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright 2017 NXP
+ * Copyright 2017, 2020 NXP
  */
 
 #ifndef __LS1088A_QDS_H
@@ -421,9 +421,9 @@ unsigned long get_board_ddr_clk(void);
"kernel_load=0xa000\0"  \
"kernel_size=0x280\0"   \
"mcinitcmd=sf probe 0:0;sf read 0xa0a0 0xa0 0x10;"  \
-   "sf read 0xa070 0x70 0x4000; esbc_validate 0xa070;" \
+   "sf read 0xa064 0x64 0x4000; esbc_validate 0xa064;" \
"sf read 0xa0e0 0xe0 0x10;" \
-   "sf read 0xa074 0x74 0x4000;esbc_validate 0xa074;"  \
+   "sf read 0xa068 0x68 0x4000;esbc_validate 0xa068;"  \
"fsl_mc start mc 0xa0a0 0xa0e0\0"   \
"mcmemsize=0x7000 \0"
 #else /* if !(CONFIG_SECURE_BOOT) */
diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h
index 50de658d2e..a5cccbd250 100644
--- a/include/configs/ls1088ardb.h
+++ b/include/configs/ls1088ardb.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright 2017 NXP
+ * Copyright 2017, 2020 NXP
  */
 
 #ifndef __LS1088A_RDB_H
@@ -309,19 +309,19 @@
"sf probe 0:0;sf read 0x8000 0xA0 0x10;"\
"sf read 0x8010 0xE0 0x10;" \
"env exists secureboot && " \
-   "sf read 0x8070 0x70 0x4 && "   \
-   "sf read 0x8074 0x74 0x4 && "   \
-   "esbc_validate 0x8070 && "  \
-   "esbc_validate 0x8074 ;"\
+   "sf read 0x8064 0x64 0x4 && "   \
+   "sf read 0x8068 0x68 0x4 && "   \
+   "esbc_validate 0x8064 && "  \
+   "esbc_validate 0x8068 ;"\
"fsl_mc start mc 0x8000 0x8010\0"
 #define SD_MC_INIT_CMD \
"mmcinfo;mmc read 0x8000 0x5000 0x800;" \
"mmc read 0x8010 0x7000 0x800;" \
"env exists secureboot && " \
-   "mmc read 0x8070 0x3800 0x20 && "   \
-   "mmc read 0x8074 0x3A00 0x20 && "   \
-   "esbc_validate 0x8070 && "  \
-   "esbc_validate 0x8074 ;"\
+   "mmc read 0x8064 0x3200 0x20 && "   \
+   "mmc read 0x8068 0x3400 0x20 && "   \
+   "esbc_validate 0x8064 && "  \
+   "esbc_validate 0x8068 ;"\
"fsl_mc start mc 0x8000 0x8010\0"
 #else
 #if defined(CONFIG_QSPI_BOOT)
@@ -329,10 +329,10 @@
"mcinitcmd=sf probe 0:0;sf read 0x8000 0xA0 0x10;"  \
"sf read 0x8010 0xE0 0x10;" \
"env exists secureboot && " \
-   "sf read 0x8070 0x70 0x4 && "   \
-   "sf read 0x8074 0x74 0x4 && "   \
-   "esbc_validate 0x8070 && "  \
-   "esbc_validate 0x8074 ;"\
+   "sf read 0x8064 0x64 0x4 && "   \
+   "sf read 0x8068 0x68 0x4 && "   \
+   "esbc_validate 0x8064 && "  \
+   "esbc_validate 0x8068 ;"\
"fsl_mc start mc 0x8000 0x8010\0"   \
"mcmemsize=0x7000\0"
 #elif defined(CONFIG_SD_BOOT)
@@ -340,10 +340,10 @@
"mcinitcmd=mmcinfo;mmc read 0x8000 0x5000 0x800;"   \
"mmc read 0x8010 0x7000 0x800;" \
"env exists secureboot && " \
-   "mmc read 0x8070 0x3800 0x20 && "   \
-   "mmc read 0x8074 0x3A00 0x20 && "   \
-   "esbc_validate 0x8070 && "  \
-   "esbc_validate 0x8074 ;"\
+   "mmc read 0x8064 0x3200 0x20 && "   \
+   "mmc read 0x8068 0x3400 0x20 && "   \
+   "esbc_validate 0x8064 && "  \
+   "esbc_validate 0x8068 ;"\
"fsl_mc start mc 0x8000 0x8010\0"   \
"mcmemsize=0x7000\0"
 #endif
@@ -361,13 +361,13 @@
"fdt_addr=0x64f0\0" \
"kernel_addr=0x100\0"   \

[PATCH 1/1] armv8: lx2160a: Updates secure boot headers offset

[Priyanka Singh]

Updates the secure boot headers offsets of Kernel and other
firmware images for SD and XSPI boot sources used by
esbc_validate command.

Signed-off-by: Priyanka Singh 
---
 include/configs/lx2160a_common.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h
index 909d047d7d..0b0075a406 100644
--- a/include/configs/lx2160a_common.h
+++ b/include/configs/lx2160a_common.h
@@ -207,18 +207,18 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
 /* Initial environment variables */
 #define XSPI_MC_INIT_CMD   \
"env exists secureboot && " \
-   "esbc_validate 0x2070 && "  \
-   "esbc_validate 0x2074 ;"\
+   "esbc_validate 0x2064 && "  \
+   "esbc_validate 0x2068 ;"\
"fsl_mc start mc 0x20a0 0x20e0\0"
 
 #define SD_MC_INIT_CMD \
"mmc read 0x80a0 0x5000 0x1200;"\
"mmc read 0x80e0 0x7000 0x800;" \
"env exists secureboot && " \
-   "mmc read 0x8070 0x3800 0x20 && "   \
-   "mmc read 0x8074 0x3A00 0x20 && "   \
-   "esbc_validate 0x8070 && "  \
-   "esbc_validate 0x8074 ;"\
+   "mmc read 0x8064 0x3200 0x20 && "   \
+   "mmc read 0x8068 0x3400 0x20 && "   \
+   "esbc_validate 0x8064 && "  \
+   "esbc_validate 0x8068 ;"\
"fsl_mc start mc 0x80a0 0x80e0\0"
 
 #define EXTRA_ENV_SETTINGS \
@@ -229,7 +229,7 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
"initrd_high=0x\0"  \
"fdt_addr=0x64f0\0" \
"kernel_start=0x100\0"  \
-   "kernelheader_start=0x7C\0" \
+   "kernelheader_start=0x60\0" \
"scriptaddr=0x8000\0"   \
"scripthdraddr=0x8008\0"\
"fdtheader_addr_r=0x8010\0" \
@@ -240,7 +240,7 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
"kernel_addr_sd=0x8000\0"   \
-   "kernelhdr_addr_sd=0x3E00\0"\
+   "kernelhdr_addr_sd=0x3000\0"\
"kernel_size_sd=0x1d000\0"  \
"kernelhdr_size_sd=0x20\0"  \
"console=ttyAMA0,38400n8\0" \
@@ -268,7 +268,7 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
 
 #define XSPI_NOR_BOOTCOMMAND   \
"env exists mcinitcmd && env exists secureboot "\
-   "&& esbc_validate 0x2078; " \
+   "&& esbc_validate 0x206C; " \
"env exists mcinitcmd && "  \
"fsl_mc lazyapply dpl 0x20d0; " \
"run distro_bootcmd;run xspi_bootcmd; " \
@@ -278,8 +278,8 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
"env exists mcinitcmd && mmcinfo; " \
"mmc read 0x80d0 0x6800 0x800; "\
"env exists mcinitcmd && env exists secureboot "\
-   " && mmc read 0x8078 0x3C00 0x20 "  \
-   "&& esbc_validate 0x8078;env exists mcinitcmd " \
+   " && mmc read 0x806C 0x3600 0x20 "  \
+   "&& esbc_validate 0x806C;env exists mcinitcmd " \
"&& fsl_mc lazyapply dpl 0x80d0;"   \
"run distro_bootcmd;run sd_bootcmd;"\
"env exists secureboot && esbc_halt;"
-- 
2.17.1

[PATCH 2/2] armv8: ls1012ardb: Updates secure boot headers offset

[Priyanka Singh]

Updates the secure boot headers offsets of Kernel and other
firmware images used by esbc_validate command.

Signed-off-by: Priyanka Singh 
---
 include/configs/ls1012ardb.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index 41e1bff15b..d217b943dd 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
+ * Copyright 2020 NXP
  * Copyright 2016 Freescale Semiconductor, Inc.
  */
 
@@ -66,7 +67,7 @@
"initrd_high=0x\0"  \
"fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
-   "kernelheader_addr=0x80\0"  \
+   "kernelheader_addr=0x60\0"  \
"scriptaddr=0x8000\0"   \
"scripthdraddr=0x8008\0"\
"fdtheader_addr_r=0x8010\0" \
-- 
2.17.1