Re: [U-Boot] [PATCH] armv8: ls1043a: Extend the size for SPL

2016-09-07 Thread Q.Y. Gong
Hi York,

> -Original Message-
> From: york sun
> Sent: Wednesday, September 07, 2016 11:36 PM
> To: Q.Y. Gong ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Vincent Hu
> 
> Subject: Re: [PATCH] armv8: ls1043a: Extend the size for SPL
> 
> On 09/07/2016 03:33 AM, Gong Qianyu wrote:
> > The SPL images are growing much bigger especially when DEBUG is ON.
> > So need to fix the values for them.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> >  include/configs/ls1043a_common.h | 25 -
> >  1 file changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/configs/ls1043a_common.h
> > b/include/configs/ls1043a_common.h
> > index e55fcb2..fa20e6d 100644
> > --- a/include/configs/ls1043a_common.h
> > +++ b/include/configs/ls1043a_common.h
> > @@ -69,16 +69,22 @@
> >  #define CONFIG_SPL_SERIAL_SUPPORT
> >  #define CONFIG_SPL_DRIVERS_MISC_SUPPORT  #define
> > CONFIG_SPL_MMC_SUPPORT
> > -#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>   0xf0
> > +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>   0x110
> >  #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x500
> >
> >  #define CONFIG_SPL_TEXT_BASE   0x1000
> > -#define CONFIG_SPL_MAX_SIZE0x1d000
> > -#define CONFIG_SPL_STACK   0x1001e000
> > -#define CONFIG_SPL_PAD_TO  0x1d000
> > +/*
> > + * CONFIG_SPL_MAX_SIZE is limited by OCRAM memory size(128 KiB) and
> > + * a reserved stack size(4 KiB).
> > + * So notice that even if DEBUG is ON, the SPL
> > +image(spl/u-boot-spl.bin)
> > + * should not be > 124 KiB.
> > + */
> 
> Qianyu,
> 
> It is good to see comment here. However, I am concerned about your 
> calculation.
> Beside the image and stack, the early MMU tables are at the beginning of 
> OCRAM.
> Did you count them?
> 
> York

No. We don't set up MMU tables in SPL stage on LS1043A/LS1046A.
Seems so far only LS2080A has done that in SPL.


Regards,
Qianyu

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


Re: [U-Boot] [PATCH V4 1/2] mmc: sd: extracting erase related information from sd status

2016-09-07 Thread Peng Fan
On Thu, Sep 08, 2016 at 10:49:53AM +0900, Jaehoon Chung wrote:
>Hi Peng,
>
>On 09/08/2016 10:42 AM, Peng Fan wrote:
>> Hi Jaehoon,
>> On Wed, Sep 07, 2016 at 03:52:53PM +0900, Jaehoon Chung wrote:
>>> Hi Peng,
>>>
>>> On 09/01/2016 12:13 PM, Peng Fan wrote:
 Add function to read SD_STATUS information.
 According to the information, get erase_timeout/erase_size/erase_offset.
 Add a structure sd_ssr to include the erase related information.
>>>
>>> Sorry for late..I'm testing with your patch on my SD-card.
>>> After that, I will apply yours. Before applied this, i will check more 
>>> carefully for not doing previous my mistake.
>> 
>> The issue in the previous patch set is that linux/size.h is not included in 
>> sandbox.h.
>> In this patchset, I include linux/size.h in mmc.h:)
>
>Right, i have checked the test of building with your patch.
>There is no problem..just i want to run your patch for erasing SD-card. Could 
>you wait for one day?

Yeah. Ok for me :)

Thanks,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V4 1/2] mmc: sd: extracting erase related information from sd status

2016-09-07 Thread Jaehoon Chung
Hi Peng,

On 09/08/2016 10:42 AM, Peng Fan wrote:
> Hi Jaehoon,
> On Wed, Sep 07, 2016 at 03:52:53PM +0900, Jaehoon Chung wrote:
>> Hi Peng,
>>
>> On 09/01/2016 12:13 PM, Peng Fan wrote:
>>> Add function to read SD_STATUS information.
>>> According to the information, get erase_timeout/erase_size/erase_offset.
>>> Add a structure sd_ssr to include the erase related information.
>>
>> Sorry for late..I'm testing with your patch on my SD-card.
>> After that, I will apply yours. Before applied this, i will check more 
>> carefully for not doing previous my mistake.
> 
> The issue in the previous patch set is that linux/size.h is not included in 
> sandbox.h.
> In this patchset, I include linux/size.h in mmc.h:)

Right, i have checked the test of building with your patch.
There is no problem..just i want to run your patch for erasing SD-card. Could 
you wait for one day?

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Peng.
> 
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Signed-off-by: Peng Fan 
>>> Cc: Jaehoon Chung 
>>> Cc: Simon Glass 
>>> Cc: Bin Meng 
>>> Cc: Stefan Wahren 
>>> Cc: Clemens Gruber 
>>> Cc: Kever Yang 
>>> Cc: Eric Nelson 
>>> Cc: Stephen Warren 
>>> ---
>>>
>>> V4:
>>>  include linux/sizes.h in mmc.h to avoid build break.
>>>
>>> I dropped patch [2,3,4]/5 in V2, which is not a must in this optimization 
>>> case.
>>>
>>> V3:
>>>  No change.
>>>
>>> V2:
>>>  Address Jaehoon's comments for V1
>>>  drivers/mmc/mmc.c | 68 
>>> +++
>>>  include/mmc.h |  9 
>>>  2 files changed, 77 insertions(+)
>>>
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index 43ea0bb..0312da9 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -21,6 +21,14 @@
>>>  #include 
>>>  #include "mmc_private.h"
>>>  
>>> +static const unsigned int sd_au_size[] = {
>>> +   0,  SZ_16K / 512,   SZ_32K / 512,
>>> +   SZ_64K / 512,   SZ_128K / 512,  SZ_256K / 512,
>>> +   SZ_512K / 512,  SZ_1M / 512,SZ_2M / 512,
>>> +   SZ_4M / 512,SZ_8M / 512,(SZ_8M + SZ_4M) / 512,
>>> +   SZ_16M / 512,   (SZ_16M + SZ_8M) / 512, SZ_32M / 512,   SZ_64M / 512,
>>> +};
>>> +
>>>  #ifndef CONFIG_DM_MMC_OPS
>>>  __weak int board_mmc_getwp(struct mmc *mmc)
>>>  {
>>> @@ -945,6 +953,62 @@ retry_scr:
>>> return 0;
>>>  }
>>>  
>>> +static int sd_read_ssr(struct mmc *mmc)
>>> +{
>>> +   int err, i;
>>> +   struct mmc_cmd cmd;
>>> +   ALLOC_CACHE_ALIGN_BUFFER(uint, ssr, 16);
>>> +   struct mmc_data data;
>>> +   int timeout = 3;
>>> +   unsigned int au, eo, et, es;
>>> +
>>> +   cmd.cmdidx = MMC_CMD_APP_CMD;
>>> +   cmd.resp_type = MMC_RSP_R1;
>>> +   cmd.cmdarg = mmc->rca << 16;
>>> +
>>> +   err = mmc_send_cmd(mmc, , NULL);
>>> +   if (err)
>>> +   return err;
>>> +
>>> +   cmd.cmdidx = SD_CMD_APP_SD_STATUS;
>>> +   cmd.resp_type = MMC_RSP_R1;
>>> +   cmd.cmdarg = 0;
>>> +
>>> +retry_ssr:
>>> +   data.dest = (char *)ssr;
>>> +   data.blocksize = 64;
>>> +   data.blocks = 1;
>>> +   data.flags = MMC_DATA_READ;
>>> +
>>> +   err = mmc_send_cmd(mmc, , );
>>> +   if (err) {
>>> +   if (timeout--)
>>> +   goto retry_ssr;
>>> +
>>> +   return err;
>>> +   }
>>> +
>>> +   for (i = 0; i < 16; i++)
>>> +   ssr[i] = be32_to_cpu(ssr[i]);
>>> +
>>> +   au = (ssr[2] >> 12) & 0xF;
>>> +   if ((au <= 9) || (mmc->version == SD_VERSION_3)) {
>>> +   mmc->ssr.au = sd_au_size[au];
>>> +   es = (ssr[3] >> 24) & 0xFF;
>>> +   es |= (ssr[2] & 0xFF) << 8;
>>> +   et = (ssr[3] >> 18) & 0x3F;
>>> +   if (es && et) {
>>> +   eo = (ssr[3] >> 16) & 0x3;
>>> +   mmc->ssr.erase_timeout = (et * 1000) / es;
>>> +   mmc->ssr.erase_offset = eo * 1000;
>>> +   }
>>> +   } else {
>>> +   debug("Invalid Allocation Unit Size.\n");
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  /* frequency bases */
>>>  /* divided by 10 to be nice to platforms without floating point */
>>>  static const int fbase[] = {
>>> @@ -1350,6 +1414,10 @@ static int mmc_startup(struct mmc *mmc)
>>> mmc_set_bus_width(mmc, 4);
>>> }
>>>  
>>> +   err = sd_read_ssr(mmc);
>>> +   if (err)
>>> +   return err;
>>> +
>>> if (mmc->card_caps & MMC_MODE_HS)
>>> mmc->tran_speed = 5000;
>>> else
>>> diff --git a/include/mmc.h b/include/mmc.h
>>> index aa6d5d1..e815eb3 100644
>>> --- a/include/mmc.h
>>> +++ b/include/mmc.h
>>> @@ -11,6 +11,7 @@
>>>  #define _MMC_H_
>>>  
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -102,6 +103,7 @@
>>>  #define SD_CMD_SWITCH_UHS18V   11
>>>  
>>>  

Re: [U-Boot] [PATCH V4 1/2] mmc: sd: extracting erase related information from sd status

2016-09-07 Thread Peng Fan
Hi Jaehoon,
On Wed, Sep 07, 2016 at 03:52:53PM +0900, Jaehoon Chung wrote:
>Hi Peng,
>
>On 09/01/2016 12:13 PM, Peng Fan wrote:
>> Add function to read SD_STATUS information.
>> According to the information, get erase_timeout/erase_size/erase_offset.
>> Add a structure sd_ssr to include the erase related information.
>
>Sorry for late..I'm testing with your patch on my SD-card.
>After that, I will apply yours. Before applied this, i will check more 
>carefully for not doing previous my mistake.

The issue in the previous patch set is that linux/size.h is not included in 
sandbox.h.
In this patchset, I include linux/size.h in mmc.h:)

Thanks,
Peng.

>
>Best Regards,
>Jaehoon Chung
>
>> 
>> Signed-off-by: Peng Fan 
>> Cc: Jaehoon Chung 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> Cc: Stefan Wahren 
>> Cc: Clemens Gruber 
>> Cc: Kever Yang 
>> Cc: Eric Nelson 
>> Cc: Stephen Warren 
>> ---
>> 
>> V4:
>>  include linux/sizes.h in mmc.h to avoid build break.
>> 
>> I dropped patch [2,3,4]/5 in V2, which is not a must in this optimization 
>> case.
>> 
>> V3:
>>  No change.
>> 
>> V2:
>>  Address Jaehoon's comments for V1
>>  drivers/mmc/mmc.c | 68 
>> +++
>>  include/mmc.h |  9 
>>  2 files changed, 77 insertions(+)
>> 
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 43ea0bb..0312da9 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -21,6 +21,14 @@
>>  #include 
>>  #include "mmc_private.h"
>>  
>> +static const unsigned int sd_au_size[] = {
>> +0,  SZ_16K / 512,   SZ_32K / 512,
>> +SZ_64K / 512,   SZ_128K / 512,  SZ_256K / 512,
>> +SZ_512K / 512,  SZ_1M / 512,SZ_2M / 512,
>> +SZ_4M / 512,SZ_8M / 512,(SZ_8M + SZ_4M) / 512,
>> +SZ_16M / 512,   (SZ_16M + SZ_8M) / 512, SZ_32M / 512,   SZ_64M / 512,
>> +};
>> +
>>  #ifndef CONFIG_DM_MMC_OPS
>>  __weak int board_mmc_getwp(struct mmc *mmc)
>>  {
>> @@ -945,6 +953,62 @@ retry_scr:
>>  return 0;
>>  }
>>  
>> +static int sd_read_ssr(struct mmc *mmc)
>> +{
>> +int err, i;
>> +struct mmc_cmd cmd;
>> +ALLOC_CACHE_ALIGN_BUFFER(uint, ssr, 16);
>> +struct mmc_data data;
>> +int timeout = 3;
>> +unsigned int au, eo, et, es;
>> +
>> +cmd.cmdidx = MMC_CMD_APP_CMD;
>> +cmd.resp_type = MMC_RSP_R1;
>> +cmd.cmdarg = mmc->rca << 16;
>> +
>> +err = mmc_send_cmd(mmc, , NULL);
>> +if (err)
>> +return err;
>> +
>> +cmd.cmdidx = SD_CMD_APP_SD_STATUS;
>> +cmd.resp_type = MMC_RSP_R1;
>> +cmd.cmdarg = 0;
>> +
>> +retry_ssr:
>> +data.dest = (char *)ssr;
>> +data.blocksize = 64;
>> +data.blocks = 1;
>> +data.flags = MMC_DATA_READ;
>> +
>> +err = mmc_send_cmd(mmc, , );
>> +if (err) {
>> +if (timeout--)
>> +goto retry_ssr;
>> +
>> +return err;
>> +}
>> +
>> +for (i = 0; i < 16; i++)
>> +ssr[i] = be32_to_cpu(ssr[i]);
>> +
>> +au = (ssr[2] >> 12) & 0xF;
>> +if ((au <= 9) || (mmc->version == SD_VERSION_3)) {
>> +mmc->ssr.au = sd_au_size[au];
>> +es = (ssr[3] >> 24) & 0xFF;
>> +es |= (ssr[2] & 0xFF) << 8;
>> +et = (ssr[3] >> 18) & 0x3F;
>> +if (es && et) {
>> +eo = (ssr[3] >> 16) & 0x3;
>> +mmc->ssr.erase_timeout = (et * 1000) / es;
>> +mmc->ssr.erase_offset = eo * 1000;
>> +}
>> +} else {
>> +debug("Invalid Allocation Unit Size.\n");
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  /* frequency bases */
>>  /* divided by 10 to be nice to platforms without floating point */
>>  static const int fbase[] = {
>> @@ -1350,6 +1414,10 @@ static int mmc_startup(struct mmc *mmc)
>>  mmc_set_bus_width(mmc, 4);
>>  }
>>  
>> +err = sd_read_ssr(mmc);
>> +if (err)
>> +return err;
>> +
>>  if (mmc->card_caps & MMC_MODE_HS)
>>  mmc->tran_speed = 5000;
>>  else
>> diff --git a/include/mmc.h b/include/mmc.h
>> index aa6d5d1..e815eb3 100644
>> --- a/include/mmc.h
>> +++ b/include/mmc.h
>> @@ -11,6 +11,7 @@
>>  #define _MMC_H_
>>  
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -102,6 +103,7 @@
>>  #define SD_CMD_SWITCH_UHS18V11
>>  
>>  #define SD_CMD_APP_SET_BUS_WIDTH6
>> +#define SD_CMD_APP_SD_STATUS13
>>  #define SD_CMD_ERASE_WR_BLK_START   32
>>  #define SD_CMD_ERASE_WR_BLK_END 33
>>  #define SD_CMD_APP_SEND_OP_COND 41
>> @@ -392,6 +394,12 @@ struct mmc_config {
>>  unsigned char part_type;
>>  };
>>  
>> +struct sd_ssr {
>> +unsigned 

Re: [U-Boot] [PATCH 21/21] arm: imx: add i.MX6ULL 14x14 EVK board support

2016-09-07 Thread Peng Fan
Hi Jagan,
On Wed, Sep 07, 2016 at 08:21:07PM +0530, Jagan Teki wrote:
>On Thu, Aug 11, 2016 at 11:32 AM, Peng Fan  wrote:
>> Add i.MX6ULL EVK board support:
>> Add device tree file, which is copied from NXP Linux.
>> Enabled DM_MMC, DM_GPIO, DM_I2C, DM_SPI, PINCTRL, DM_REGULATOR.
>> The uart iomux settings are still keeped in board file.
>>
>> Boot Log:
>> U-Boot 2016.09-rc1-00366-gbb419ef-dirty (Aug 11 2016 - 13:08:58 +0800)
>>
>> CPU:   Freescale i.MX6ULL rev1.0 at 396MHz
>> CPU:   Commercial temperature grade (0C to 95C) at 15C
>> Reset cause: POR
>> Model: Freescale i.MX6 ULL 14x14 EVK Board
>> Board: MX6ULL 14x14 EVK
>> DRAM:  512 MiB
>> MMC:   initialized IMX pinctrl driver
>> FSL_SDHC: 0, FSL_SDHC: 1
>
>
>
>> diff --git a/board/freescale/mx6ullevk/mx6ullevk.c 
>> b/board/freescale/mx6ullevk/mx6ullevk.c
>> new file mode 100644
>> index 000..489bf21
>> --- /dev/null
>> +++ b/board/freescale/mx6ullevk/mx6ullevk.c
>> @@ -0,0 +1,99 @@
>> +/*
>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +#define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |\
>> +   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
>> +   PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
>> +
>> +int dram_init(void)
>> +{
>> +   gd->ram_size = imx_ddr_size();
>> +
>> +   return 0;
>> +}
>> +
>> +static iomux_v3_cfg_t const uart1_pads[] = {
>> +   MX6_PAD_UART1_TX_DATA__UART1_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
>> +   MX6_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
>> +};
>> +
>> +static void setup_iomux_uart(void)
>> +{
>> +   imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
>> +}
>> +
>> +int board_mmc_get_env_dev(int devno)
>> +{
>> +   return devno;
>> +}
>> +
>> +int mmc_map_to_kernel_blk(int devno)
>> +{
>> +   return devno;
>> +}
>> +
>> +int board_early_init_f(void)
>> +{
>> +   setup_iomux_uart();
>
>Don't we need iomux settings for sdhc? I guess pinctrl for SD not
>supporting now.

The pinctrl driver will configure the pinmux, no need to add iomux settings
in board file. In this patchset, I enabled PINCTRL, DM_MMC, DM_GPIO and etc.

Thanks,
Peng.

>
>thanks!
>-- 
>Jagan Teki
>Free Software Engineer | www.openedev.com
>U-Boot, Linux | Upstream Maintainer
>Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] config USB_STORAGE: defconfig vs include header

2016-09-07 Thread Masahiro Yamada
Hi Stephen


2016-09-08 1:15 GMT+09:00 Stephen Warren :
> Masahiro,
>
> In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you added
> "config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just
> #defined by many include/configs/*.h rather than being defined in
> configs/*_defconfig. Is that a problem? It seems to work in practice, but
> leads people adding new boards to put the definition in configs/*_defconfig
> which then may be inconsistent with similar existing boards which have it
> defined in include/configs/*.h.

Once we create an entry in Kconfig,
all the defines in include/configs/*.h should be moved.





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


Re: [U-Boot] [PATCH 5/5] ARM: omap5: add fdt secure dram reservation fixup

2016-09-07 Thread Andrew F. Davis
On 09/02/2016 12:40 AM, Daniel Allred wrote:
> Adds a secure dram reservation fixup for secure
> devices, when a region in the emif has been set aside
> for secure world use. The size is defined by the
> CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE config option.
> 
> Signed-off-by: Daniel Allred 
> ---
>  arch/arm/cpu/armv7/omap5/fdt.c | 64 
> --
>  1 file changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap5/fdt.c b/arch/arm/cpu/armv7/omap5/fdt.c
> index 0493cd1..da8d59b 100644
> --- a/arch/arm/cpu/armv7/omap5/fdt.c
> +++ b/arch/arm/cpu/armv7/omap5/fdt.c
> @@ -153,13 +153,73 @@ static int ft_hs_fixup_sram(void *fdt, bd_t *bd)
>  static int ft_hs_fixup_sram(void *fdt, bd_t *bd) { return 0; }
>  #endif
>  
> +#if (CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE != 0)
> +static int ft_hs_fixup_dram(void *fdt, bd_t *bd)
> +{
> + const char *path, *subpath;
> + int offs;
> + u32 sec_mem_start = CONFIG_TI_SECURE_EMIF_REGION_START;
> + u32 sec_mem_size = CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE;
> + fdt64_t temp[2];
> +
> + /* If start address is zero, place at end of DRAM */
> + if (0 == sec_mem_start)
> + sec_mem_start =
> + (CONFIG_SYS_SDRAM_BASE +
> + (omap_sdram_size() - sec_mem_size));
> +
> + /* Delete any original secure_reserved node */
> + path = "/reserved-memory/secure_reserved";
> + offs = fdt_path_offset(fdt, path);
> + if (offs >= 0)
> + fdt_del_node(fdt, offs);
> +
> + /* Add new secure_reserved node */
> + path = "/reserved-memory";
> + offs = fdt_path_offset(fdt, path);
> + if (offs < 0) {
> + debug("Node %s not found\n", path);
> + path = "/";
> + subpath = "reserved-memory";
> + fdt_path_offset(fdt, path);

Are we supposed to be doing something with the result of this call? Who
sets 'offs' in this case?

> + offs = fdt_add_subnode(fdt, offs, subpath);
> + if (offs < 0) {
> + printf("Could not create %s%s node.\n", path, subpath);
> + return 1;
> + }
> + path = "/reserved-memory";
> + offs = fdt_path_offset(fdt, path);
> + }
> +
> + subpath = "secure_reserved";
> + offs = fdt_add_subnode(fdt, offs, subpath);
> + if (offs < 0) {
> + printf("Could not create %s%s node.\n", path, subpath);
> + return 1;
> + }
> +
> + temp[0] = cpu_to_fdt64(((u64)sec_mem_start));
> + temp[1] = cpu_to_fdt64(((u64)sec_mem_size));
> + fdt_setprop_string(fdt, offs, "compatible",
> +"ti,dra7-secure-memory");
> + fdt_setprop_string(fdt, offs, "status", "okay");
> + fdt_setprop(fdt, offs, "no-map", NULL, 0);
> + fdt_setprop(fdt, offs, "reg", temp, sizeof(temp));
> +
> + return 0;
> +}
> +#else
> +static int ft_hs_fixup_dram(void *fdt, bd_t *bd) { return 0; }
> +#endif
> +
>  static void ft_hs_fixups(void *fdt, bd_t *bd)
>  {
>   /* Check we are running on an HS/EMU device type */
>   if (GP_DEVICE != get_device_type()) {
>   if ((ft_hs_fixup_crossbar(fdt, bd) == 0) &&
>   (ft_hs_disable_rng(fdt, bd) == 0) &&
> - (ft_hs_fixup_sram(fdt, bd) == 0))
> + (ft_hs_fixup_sram(fdt, bd) == 0) &&
> + (ft_hs_fixup_dram(fdt, bd) == 0))
>   return;
>   } else {
>   printf("ERROR: Incorrect device type (GP) detected!");
> @@ -171,7 +231,7 @@ static void ft_hs_fixups(void *fdt, bd_t *bd)
>  static void ft_hs_fixups(void *fdt, bd_t *bd)
>  {
>  }
> -#endif
> +#endif /* #ifdef CONFIG_TI_SECURE_DEVICE */
>  
>  /*
>   * Place for general cpu/SoC FDT fixups. Board specific
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Various, accumulated typos collected from around the tree.

2016-09-07 Thread Jagan Teki
On Wed, Sep 7, 2016 at 11:57 PM, Robert P. J. Day  wrote:
>
> Fix various misspellings of:
>
>  * deprecated
>  * partition
>  * preceding,preceded
>  * preparation
>  * its versus it's
>  * export
>  * existing
>  * scenario
>  * redundant
>  * remaining
>  * value
>  * architecture
>
> Signed-off-by: Robert P. J. Day 

On spi

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] spi: ti_qspi: use 128 bit transfer mode when writing to flash

2016-09-07 Thread Jagan Teki
On Wed, Sep 7, 2016 at 3:18 PM, Vignesh R  wrote:
> TI QSPI has four 32 bit data registers which can be used to transfer 16
> bytes of data at once. The register group QSPI_SPI_DATA_REG_3,
> QSPI_SPI_DATA_REG_2, QSPI_SPI_DATA_REG_1 and QSPI_SPI_DATA_REG is
> treated as a single 128-bit word for shifting data in and out. The bit
> at QSPI_SPI_DATA_REG_3[31] position is the first bit to be shifted out
> in case of 128 bit transfer mode. Therefore the first byte to be written
> to flash should be at QSPI_SPI_DATA_REG_3[31-25] position.
> Instead of writing 1 byte at a time when interacting with SPI NOR flash,
> make use of all the four registers so that 16 bytes can be transferred
> in one go.
>
> With this patch, the flash write speed increases from ~250KBs/ to
> ~650KB/s on DRA74 EVM.
>
> Signed-off-by: Vignesh R 
> Reviewed-by: Tom Rini 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] armv8: ls1043a: Extend the size for SPL

2016-09-07 Thread york sun
On 09/07/2016 03:33 AM, Gong Qianyu wrote:
> The SPL images are growing much bigger especially when DEBUG is ON.
> So need to fix the values for them.
>
> Signed-off-by: Gong Qianyu 
> ---
>  include/configs/ls1043a_common.h | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/include/configs/ls1043a_common.h 
> b/include/configs/ls1043a_common.h
> index e55fcb2..fa20e6d 100644
> --- a/include/configs/ls1043a_common.h
> +++ b/include/configs/ls1043a_common.h
> @@ -69,16 +69,22 @@
>  #define CONFIG_SPL_SERIAL_SUPPORT
>  #define CONFIG_SPL_DRIVERS_MISC_SUPPORT
>  #define CONFIG_SPL_MMC_SUPPORT
> -#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR  0xf0
> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR  0x110
>  #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS   0x500
>
>  #define CONFIG_SPL_TEXT_BASE 0x1000
> -#define CONFIG_SPL_MAX_SIZE  0x1d000
> -#define CONFIG_SPL_STACK 0x1001e000
> -#define CONFIG_SPL_PAD_TO0x1d000
> +/*
> + * CONFIG_SPL_MAX_SIZE is limited by OCRAM memory size(128 KiB) and
> + * a reserved stack size(4 KiB).
> + * So notice that even if DEBUG is ON, the SPL image(spl/u-boot-spl.bin)
> + * should not be > 124 KiB.
> + */

Qianyu,

It is good to see comment here. However, I am concerned about your 
calculation. Beside the image and stack, the early MMU tables are at the 
beginning of OCRAM. Did you count them?

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


Re: [U-Boot] UBI and UBIFS on ARM64

2016-09-07 Thread Adam Oleksy
Hello Heiko,

2016-09-07 12:26 GMT+02:00 Heiko Schocher :
> Sounds risky to me, as I think you have some problem with your nand
> driver or io functions ...
It sounds risky to me also. I'm going to resolve this problem by
myself. I'll let you know about results.

-- 
Adam Oleksy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] UBI and UBIFS on ARM64

2016-09-07 Thread Adam Oleksy
Hi Heiko,
Thank you, and I understand that you can't say nothing more about this.
Anyway, I've found workaround... I've just disabled compression for
ubifs, and problem disappeared.
I believe I can live with it:).

2016-09-07 6:49 GMT+02:00 Heiko Schocher :
> Hello Adam,
>
>
> Am 07.09.2016 um 06:39 schrieb Heiko Schocher:
>>
>> Hello Adam,
>>
>> Am 06.09.2016 um 16:44 schrieb Adam Oleksy:
>>>
>>> Dear U-Boot community,
>>> I'm developing software for Xilinx ZynqMP platform, which is made in
>>> 64-bit architecture. I would like to store every artifact needed to
>>> boot up on the UBIFS partition. I faced problem, that u-boot does not
>>> want to compile with enabled UBI/UBIFS support, due to lack of some
>>> atomic operations on longs. So, I've written them (see
>>> http://pastebin.com/ibp0Zt99). Please note, that I've written only
>>> that functions, which are needed by UBI/UBIFS. Then UBIFS started work
>>> on the target. Almost... because I've found that large files (~20MiB)
>>> can't be read. I've enabled debug messages, but I don't know how to
>>> interpret them (please see http://pastebin.com/gByDcdvw). Maybe you
>>> are able to help me?
>>> I've also checked how the UBIFS behaves in the Linux, and the result
>>> is that everything works as expected. It means that I can write large
>>> files to UBIFS, and read them back successfully.
>>> Should you need any further information, please do not hesitate to
>>> contact me.
>>
>>
>> Hard to say ... here an extract of your debug log:
>>
>> UBI DBG io (pid 1): read 509 bytes from PEB 1059:10040
>> UBIFS error (ubi0:0 pid 0): ubifs_check_node: bad magic 0x61018ce,
>> expected 0x6101831
>>
>> Here begin your problem ... for some reasons you do not read the
>> correct magic number ... I tend to say some problem with your nand
>> driver and/or io functions, maybe cache setup? Sorry, more I cannot say
>> ...
>
>
> I am quite sure now:
> bad magic 0x61018ce, expected 0x6101831
>  ^^  ^^
>
> 0xce = !0x31
>
> You have read problems ...
>
> bye,
> Heiko
>
>
>> UBIFS error (ubi0:0 pid 0): ubifs_check_node: bad node at LEB 417:9912
>> Not a node, first 24 bytes:UBIFS error (ubi0:0 pid 0): ubifs_read_node:
>> expected node type 1
>> UBIFS DBG tnc: key (67, data, 4679)
>> UBIFS error (ubi0:0 pid 0): do_readpage: cannot read page 4679 of inode
>> 67, error -117
>> Error reading file 'rfsw-image_ramdisk.itb'
>> UBI DBG gen (pid 1): close device 0, volume 0, mode 1
>>
>> bye,
>> Heiko
>
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany



-- 
Pozdrawiam,
Adam Oleksy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] treewide: compress lines for immediate return

2016-09-07 Thread Masahiro Yamada
Hi Stefano,

2016-09-06 18:25 GMT+09:00 Stefano Babic :

>
> Nothing against, but it looks to me just a different and allowed coding
> style - where is the advantages of this ?
>

This had already been superseded.
Please check v3, where I mostly transformed
simple wrapper functions only.


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


Re: [U-Boot] [PATCH] treewide: compress lines for immediate return

2016-09-07 Thread Masahiro Yamada
Hi Stephen,

2016-09-07 1:09 GMT+09:00 Stephen Warren :

>>> All child function calls are structured the same, so someone reading the
>>> code will always see the same structure irrespective of where in a
>>> function
>>> a child function is called. This gives uniformity. This also yields a few
>>> maintenance advantages below, and helps keep all code uniform even if any
>>> of
>>> the maintenance operations below have been applied to some functions and
>>> aren't needed in others.
>>
>>
>>
>> Did you think I ran a semantic patch with Coccinelle
>> and then sent it blindly?
>>
>> No, this patch passed my eyes' check, at least.
>>
>> Please notice this patch did not transform
>> the following function in arch/arm/cpu/armv7/am33xx/clk_synthesizer.c
>
> ...
>
> The patch description clearly stated that the patch was purely the result of
> applying the Coccinelle script. If there were exceptions or other edits,
> they should have been explicitly mentioned too.

Right.
The git-log implied a semantic patch, but I did not mention that
I sent the output of Coccinelle as is.

Actually, I cherry-picked reasonable hunks.

Coccinelle may sometimes do false positive jobs (or undesirable output
like this case),
so I think "Coccinelle + checking by eyes" is a good practice.


I dropped a semantic patch snippet from v3 git-log.



>> If we start to consider things that may happen or may not happen,
>> we end up with adding redundancy all the time.
>>
>> Are you positive or negative for the following hunk?
>>
>>> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c
>>> b/drivers/mtd/nand/fsl_elbc_nand.c
>>> index f621f14..b27a6af 100644
>>> --- a/drivers/mtd/nand/fsl_elbc_nand.c
>>> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
>>> @@ -788,11 +788,7 @@ static int fsl_elbc_chip_init(int devnum, u8 *addr)
>>> if (ret)
>>> return ret;
>>>
>>> -   ret = nand_register(devnum, mtd);
>>> -   if (ret)
>>> -   return ret;
>>> -
>>> -   return 0;
>>> +   return nand_register(devnum, mtd);
>>>  }
>
>
> I'd probably tend not to do that particular conversion, for consistency with
> the immediately preceding nand_scan_tail() case. Still, this one isn't such
> an obvious call so I wouldn't feel particularly strongly about it,
> especially as it isn't a driver I work on.
>
>> I think probe/init function can return a value
>> of register function directly, from my best common sense.
>>
>> This change will lose 2)
>> in case fsl_elbc_chip_init() fails to do nand_register, though.

OK.  I dropped those changes in v2.

(I still personally believe "return *_register();" is good coding style, though.
This might be a matter of preference...)


In v3, I only fixed drivers/video/vidconsole-uclass.c
because I thought it is simple enough.
http://patchwork.ozlabs.org/patch/666560/

and it was acked by Anatolij.




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


[U-Boot] [PATCH] Various, accumulated typos collected from around the tree.

2016-09-07 Thread Robert P. J. Day

Fix various misspellings of:

 * deprecated
 * partition
 * preceding,preceded
 * preparation
 * its versus it's
 * export
 * existing
 * scenario
 * redundant
 * remaining
 * value
 * architecture

Signed-off-by: Robert P. J. Day 

---

  just rebased against master so it should apply, tried to CC various
relevant people depending on location of typos.

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 1864ab9..6b46078 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -45,7 +45,7 @@ static inline void *phys_to_virt(unsigned long x)
 /*
  * Virtual <-> DMA view memory address translations
  * Again, these are *only* valid on the kernel direct mapped RAM
- * memory.  Use of these is *depreciated*.
+ * memory.  Use of these is *deprecated*.
  */
 #define virt_to_bus(x) (__virt_to_bus((unsigned long)(x)))
 #define bus_to_virt(x) ((void *)(__bus_to_virt((unsigned long)(x
@@ -127,7 +127,7 @@ static inline void *phys_to_virt(unsigned long x)
 #endif

 /*
- * We should really eliminate virt_to_bus() here - it's depreciated.
+ * We should really eliminate virt_to_bus() here - it's deprecated.
  */
 #define page_to_bus(page)  (virt_to_bus(page_address(page)))

diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 78a7fac..3a4e902 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -132,7 +132,7 @@ struct tag_ramdisk {
 /* describes where the compressed ramdisk image lives (virtual address) */
 /*
  * this one accidentally used virtual addresses - as such,
- * its depreciated.
+ * it's deprecated.
  */
 #define ATAG_INITRD0x54410005

diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index ef08489..cabf64c 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -489,7 +489,7 @@ static void dump_spd_ddr_reg(void)
for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++)
fsl_ddr_get_spd(spd[i], i, CONFIG_DIMM_SLOTS_PER_CTLR);

-   puts("SPD data of all dimms (zero vaule is omitted)...\n");
+   puts("SPD data of all dimms (zero value is omitted)...\n");
puts("Byte (hex)  ");
k = 1;
for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++) {
@@ -543,7 +543,7 @@ static void dump_spd_ddr_reg(void)
}
}
printf("DDR registers dump for all controllers "
-   "(zero vaule is omitted)...\n");
+   "(zero value is omitted)...\n");
puts("Offset (hex)   ");
for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++)
printf(" Base + 0x%04x", (u32)ddr[i] & 0x);
diff --git a/board/technexion/twister/twister.c 
b/board/technexion/twister/twister.c
index 48d207f..4a3d094 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -140,7 +140,7 @@ int board_mmc_init(bd_t *bis)

 #ifdef CONFIG_SPL_OS_BOOT
 /*
- * Do board specific preperation before SPL
+ * Do board specific preparation before SPL
  * Linux boot
  */
 void spl_board_prepare_for_linux(void)
diff --git a/board/timll/devkit8000/devkit8000.c 
b/board/timll/devkit8000/devkit8000.c
index 965252f..f785dbe 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -157,7 +157,7 @@ int board_eth_init(bd_t *bis)

 #ifdef CONFIG_SPL_OS_BOOT
 /*
- * Do board specific preperation before SPL
+ * Do board specific preparation before SPL
  * Linux boot
  */
 void spl_board_prepare_for_linux(void)
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index b67563b..9ca5cb5 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -15,7 +15,7 @@
  *
  * The "environment" is stored on external storage as a list of '\0'
  * terminated "name=value" strings. The end of the list is marked by
- * a double '\0'. The environment is preceeded by a 32 bit CRC over
+ * a double '\0'. The environment is preceded by a 32 bit CRC over
  * the data part and, in case of redundant environment, a byte of
  * flags.
  *
@@ -838,7 +838,7 @@ static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
  * With "-c" and size is NOT given, then the export command will
  * format the data as currently used for the persistent storage,
  * i. e. it will use CONFIG_ENV_SECT_SIZE as output block size and
- * prepend a valid CRC32 checksum and, in case of resundant
+ * prepend a valid CRC32 checksum and, in case of redundant
  * environment, a "current" redundancy flag. If size is given, this
  * value will be used instead of CONFIG_ENV_SECT_SIZE; again, CRC32
  * checksum and redundancy flag will be inserted.
@@ -847,12 +847,12 @@ static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
  * terminating '\0' byte) will be written; here the optional size
  * argument will be used to make sure not to overflow the user
  * provided buffer; the command will abort if the size is not
- * sufficient. Any remainign space will be '\0' padded.
+ * 

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

2016-09-07 Thread york sun
On 09/06/2016 07:42 PM, Prabhakar Kushwaha wrote:
>
>> -Original Message-
>> From: york sun
>> Sent: Tuesday, September 06, 2016 9:10 PM
>> To: Prabhakar Kushwaha ; u-
>> b...@lists.denx.de
>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
>>
>> On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
>>> IFC IP clock is always a constant divisor of platform clock
>>> pre-defined per SoC. Clock Control register (CCR) used in
>>> current implementation governs IFC IP output clock.
>>>
>>> So update IFC IP clock to be defined as per predefined clock
>>> divisor of platform clock.
>>>
>>> Signed-off-by: Prabhakar Kushwaha 
>>> ---
>>>  README  |  3 +++
>>>  arch/arm/cpu/armv7/ls102xa/clock.c  | 10 ++
>>>  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++
>>>  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++
>>>  arch/arm/include/asm/arch-fsl-layerscape/config.h   |  3 +++
>>>  arch/arm/include/asm/arch-ls102xa/config.h  |  1 +
>>>  arch/powerpc/cpu/mpc85xx/speed.c| 10 ++
>>>  arch/powerpc/include/asm/config_mpc85xx.h   |  9 +
>>>  8 files changed, 24 insertions(+), 32 deletions(-)
>>
>> Prabkahar,
>>
>> Two concerns here
>>
>> 1, it is not only IFC for powerpc. Older SoCs have local bus. That's why
>> the variable is named freq_localbus..
>>
>
> As per my understanding, Issue is valid for eLBC SoC also.
> Just wanted to confirm from internal IP team before spinning patch to fix it.
>
>> 2, what's the reason for this change? Is it wrong to use ccr to
>> calculate the clock? Or is it because recent Layerscape SoCs have
>> platform PLL different from platform clock? If the latter, can we limit
>> the fix to platform clock and not changing powerpc?
>>
>
> CCR governs the IFC output clock.
> This clock is used for synchronous NOR, NAND flashes. It is nowhere govern 
> IFC IP internal clock.
>
> It is true since conception of IFC. Unfortunately code written is wrong since 
> P1010.
> It is confusing everyone.
>

Are you saying the freq_localbus should be the internal clock, not 
output clock? As far as I can remember, this variable has always be used 
for output clock since 85xx. I am open to the idea to change to internal 
clock only if it makes sense. Browsing the code, I see this variable is 
used for information only, except for setting arch.lbc_clk.

York

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


[U-Boot] [PATCH] ARM64: Add support for some of atomic64 operations

2016-09-07 Thread Adam Oleksy
These functions are needed in UBI/UBIFS on ZynqMP platform (ARM64).
---
 arch/arm/include/asm/atomic.h | 66 +++
 1 file changed, 66 insertions(+)

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 9b79506..57914fd 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -21,6 +21,11 @@
 #endif
 
 typedef struct { volatile int counter; } atomic_t;
+#if BITS_PER_LONG == 32
+typedef struct { volatile long long counter; } atomic64_t;
+#else /* BIT_PER_LONG == 32 */
+typedef struct { volatile long counter; } atomic64_t;
+#endif
 
 #define ATOMIC_INIT(i) { (i) }
 
@@ -29,6 +34,8 @@ typedef struct { volatile int counter; } atomic_t;
 
 #define atomic_read(v) ((v)->counter)
 #define atomic_set(v,i)(((v)->counter) = (i))
+#define atomic64_read(v)   atomic_read(v)
+#define atomic64_set(v,i)  atomic_set(v,i)
 
 static inline void atomic_add(int i, volatile atomic_t *v)
 {
@@ -101,6 +108,65 @@ static inline void atomic_clear_mask(unsigned long mask, 
unsigned long *addr)
local_irq_restore(flags);
 }
 
+#if BITS_PER_LONG == 32
+
+static inline void atomic64_add(long long i, volatile atomic64_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter += i;
+   local_irq_restore(flags);
+}
+
+static inline void atomic64_sub(long long i, volatile atomic64_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter -= i;
+   local_irq_restore(flags);
+}
+
+#else /* BIT_PER_LONG == 32 */
+
+static inline void atomic64_add(long i, volatile atomic64_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter += i;
+   local_irq_restore(flags);
+}
+
+static inline void atomic64_sub(long i, volatile atomic64_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter -= i;
+   local_irq_restore(flags);
+}
+#endif
+
+static inline void atomic64_inc(volatile atomic64_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter += 1;
+   local_irq_restore(flags);
+}
+
+static inline void atomic64_dec(volatile atomic64_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter -= 1;
+   local_irq_restore(flags);
+}
+
 /* Atomic operations are already serializing on ARM */
 #define smp_mb__before_atomic_dec()barrier()
 #define smp_mb__after_atomic_dec() barrier()
-- 
2.6.2

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


Re: [U-Boot] [PATCH v4 10/10] defconfig: Add a config for AM335x High Security EVM with SD Boot support

2016-09-07 Thread Andrew F. Davis
On 09/02/2016 09:58 AM, Tom Rini wrote:
> On Fri, Sep 02, 2016 at 09:57:10AM -0500, Andrew F. Davis wrote:
>> On 09/02/2016 09:54 AM, Tom Rini wrote:
>>> On Tue, Aug 30, 2016 at 02:06:29PM -0500, Andrew F. Davis wrote:
>>>
 Add a new defconfig file for the AM335x High Security EVM. This config
 is specific for the case of SD card booting, we the boot types to be
 seperate defconfigs as some options change depending on boot type, in
 addition this allows us to trim the SPL size as we only need to support
 one boot media.

 This defconfig is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_ISW_ENTRY_ADDR updated for secure images.
CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_SPL_SD_BOOT option set to 'y' so we will build an MMC
  compatible SPL
CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size
NAND removed from CONFIG_SYS_EXTRA_OPTIONS as this adds NAND
  support to SPL, not just U-Boot proper, when this is fixed
  this can be added back

 Signed-off-by: Andrew F. Davis 
>>>
>>> Reviewed-by: Tom Rini 
>>>
>>
>> Just a heads up, this defconfig will probably not build until Simon's
>> SPL_*_SUPPORT kconfig series is taken.
>>
>> I would be okay if this didn't get taken right now, I can re-post this
>> and the other boot mode defconfigs when I can test that they build/boot
>> correctly.
> 
> OK, then yeah, it'll probably need at least one more spin once Simon's
> series is done.
> 

Yeah, this defconfig will probably change, the rest of the series is
still good to be taken whenever you feel it is ready.

Thanks,
Andrew
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] board: ks2: README: Update to add K2G support

2016-09-07 Thread Tom Rini
On Tue, Sep 06, 2016 at 09:10:37AM +0530, Lokesh Vutla wrote:

> Update the README to add support for K2G EVM. Also
> - Add steps on how to use MMC boot
> - Fix load address when using CCS
> - Update build target to u-boot.bin from u-boot-dtb.bin as all ks2
>   platforms uses DT.
> 
> Signed-off-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] efi_loader: provide efi_mem_desc version

2016-09-07 Thread Tom Rini
On Mon, Sep 05, 2016 at 11:59:22PM +0200, Mian Yousaf Kaukab wrote:

> Provide version of struct efi_mem_desc in efi_get_memory_map().
> 
> EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines
> memory descriptor version to 1. Linux kernel also expects descriptor
> version to be 1 and prints following warning during boot if its not:
> 
> Unexpected EFI_MEMORY_DESCRIPTOR version 0
> 
> Signed-off-by: Mian Yousaf Kaukab 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

2016-09-07 Thread Tom Rini
On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:

> ENOLINK is not required by POSIX and does not exist on OpenBSD
> and likely other systems.
> 
> Signed-off-by: Jonathan Gray 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] compiler.h: use system endian macros on OpenBSD

2016-09-07 Thread Tom Rini
On Sat, Sep 03, 2016 at 08:26:55AM +1000, Jonathan Gray wrote:

> The u-boot endian macros map directly to system endian
> macros on OpenBSD.
> 
> Signed-off-by: Jonathan Gray 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, V2] board: am57xx: Fix missing check for beagle_x15

2016-09-07 Thread Tom Rini
On Fri, Sep 02, 2016 at 01:51:33PM -0500, Nishanth Menon wrote:

> When beagleboard-X15 is booted, we see the following log:
> Unidentified board claims BBRDX15_ in eeprom header
> 
> This is because of the missing check for x15 (the default) and reports
> an error for a valid board configuration. Fix the same.
> 
> Signed-off-by: Nishanth Menon 
> Reviewed-by: Tom Rini 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 1/2] omap3_pandora: Fix mmc loading of autoboot script to use correct syntax.

2016-09-07 Thread Tom Rini
On Mon, Aug 29, 2016 at 12:56:05AM -0700, Vagrant Cascadian wrote:

> fatload/ext2load both require that the device and partition be
> specified after specifying the device type. Specify the first
> partition on mmc device 0, which is the only mmc device currently
> configured on the pandora.
> 
> Signed-off-by: Vagrant Cascadian 
> Acked-by: Grazvydas Ignotas 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] board: am57xx: MAINTAINERS: Update for current maintainer

2016-09-07 Thread Tom Rini
On Fri, Sep 02, 2016 at 02:51:45AM -0500, Nishanth Menon wrote:

> Felipe Balbi has move on from TI and the current email ID is no longer
> valid. So, replacing with Lokesh.
> 
> While at it, update missing config file which was untracked.
> 
> Signed-off-by: Nishanth Menon 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2] global_data.h: Standardize tabs and alignment for comments

2016-09-07 Thread Tom Rini
On Thu, Sep 01, 2016 at 12:54:32PM -0400, Robert P. J. Day wrote:

> Line up comments for readibility.
> 
> Signed-off-by: Robert P. J. Day 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v3, 2/2] pxe: Modify README to add the description about FIT image

2016-09-07 Thread Tom Rini
On Thu, Sep 01, 2016 at 04:28:22PM +0800, Wenbin Song wrote:

> Use environment variable "kernel_addr_r" to indicate the location
> in RAM where FIT image will be stored.
> Use label command "kernel" to indicate which  the FIT image at.
> 
> Signed-off-by: Wenbin Song 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] regulator: fixed: obey startup delay

2016-09-07 Thread Tom Rini
On Mon, Aug 22, 2016 at 03:10:09PM +0100, John Keeping wrote:

> When enabling a fixed regulator, it may take some time to rise to the
> correct voltage.  If we do not delay here then subsequent operations
> will fail.
> 
> Signed-off-by: John Keeping 
> Reviewed-by: Tom Rini 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot,v3,1/2] pxe: Fix pxe boot with FIT image

2016-09-07 Thread Tom Rini
On Thu, Sep 01, 2016 at 04:28:21PM +0800, Wenbin Song wrote:

> From: York Sun 
> 
> When FIT image is used, a single image provides kernel, device
> tree and optionally ramdisk. Argc and argv need to be adjusted
> to support this.
> 
> Test cases:
>   1. Booting with legacy images
>   2. Booting with legacy images without initrd
>   3. Booting with FIT image
> Test commands:
>   1. pxe get && pxe boot
>   2. sysboot
> 
> Signed-off-by: York Sun 
> Signed-off-by: Wenbin Song 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 1/2] omap3_pandora: Switch to use config_distro_bootcmd.

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 01:16:31PM -0700, Vagrant Cascadian wrote:

> Add support for using distro_bootcmd to the omap3_pandora target,
> falling back to prior behavior.
> 
> Signed-off-by: Vagrant Cascadian 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] common/Kconfig: Fix various innocuous typos.

2016-09-07 Thread Tom Rini
On Wed, Aug 31, 2016 at 12:49:13PM -0400, Robert P. J. Day wrote:

> Correct a small number of spelling mistakes.
> 
> Signed-off-by: Robert P. J. Day 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 2/2] omap3_pandora: Only set bootargs if distro_bootcmd failed to load.

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 01:16:32PM -0700, Vagrant Cascadian wrote:

> As bootargs is hard-coded for the default behavior on the
> omap3_pandora, only set the bootargs if distro_bootcmd fails to
> load. This leaves distro_bootcmd free to use alternate boot arguments.
> 
> Signed-off-by: Vagrant Cascadian 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] ARM: am335x: select DM_GPIO

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 06:51:40PM +0900, Masahiro Yamada wrote:

> We are supposed to not add config entries with only "default y"
> in board/SoC Kconfig files.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Enric Balletbo i Serra 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Increase default of CONFIG_SYS_MALLOC_F_LEN for SPL_OF_CONTROL

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 06:50:36PM +0900, Masahiro Yamada wrote:

> If both SPL_DM and SPL_OF_CONTROL are enabled, SPL needs to bind
> several devices, but CONFIG_SYS_MALLOC_F_LEN=0x400 is apparently
> not enough.  Increase the default to 0x2000 for the case.  This
> will be helpful for shorter defconfigs.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 4/4] ARM: armv7: move ARMV7_PSCI_NR_CPUS to Kconfig

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 04:22:23PM +0900, Masahiro Yamada wrote:

> Move this option to Kconfig and set its default value to 4; this
> increases the number of supported CPUs for some boards.
> 
> It consumes 1KB memory per CPU for PSCI stack, but it should not
> be a big deal, given the amount of memory used for the modern OSes.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 3/4] ARM: armv7: move CONFIG_ARMV7_PSCI to Kconfig

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 04:22:22PM +0900, Masahiro Yamada wrote:

> Add ARCH_SUPPORT_PSCI as a non-configurable option that platforms
> can select.  Then, move CONFIG_ARMV7_PSCI, which is automatically
> enabled if both ARMV7_NONSEC and ARCH_SUPPORT_PSCI are enabled.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 3/4] ARM: armv7: move CONFIG_ARMV7_PSCI to Kconfig

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 04:22:22PM +0900, Masahiro Yamada wrote:

> Add ARCH_SUPPORT_PSCI as a non-configurable option that platforms
> can select.  Then, move CONFIG_ARMV7_PSCI, which is automatically
> enabled if both ARMV7_NONSEC and ARCH_SUPPORT_PSCI are enabled.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 1/4] ARM: tegra: remove wrong dependency on SPL_BUILD

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 04:22:20PM +0900, Masahiro Yamada wrote:

> SPL_BUILD is not a CONFIG in Kconfig, so !SPL_BUILD is always true.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2, 2/4] ARM: armv7: guard memory reserve for PSCI with #ifdef CONFIG_ARMV7_PSCI

2016-09-07 Thread Tom Rini
On Tue, Aug 30, 2016 at 04:22:21PM +0900, Masahiro Yamada wrote:

> If CONFIG_ARMV7_NONSEC is enabled, the linker script requires
> CONFIG_ARMV7_PSCI_NR_CPUS regardless of CONFIG_ARMV7_PSCI.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 2/2] omap3_pandora: Switch to using "load" command to load the autoboot script.

2016-09-07 Thread Tom Rini
On Mon, Aug 29, 2016 at 12:56:06AM -0700, Vagrant Cascadian wrote:

> CONFIG_CMD_FS_GENERIC is enabled; use it to load the autoboot script,
> rather than first attempting with fatload and falling back to
> ext2load.
> 
> Signed-off-by: Vagrant Cascadian 
> Acked-by: Grazvydas Ignotas 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] TI: Rework SRAM definitions and maximums

2016-09-07 Thread Tom Rini
On Fri, Aug 26, 2016 at 01:30:43PM -0400, Tom Rini wrote:

> On all TI platforms the ROM defines a "downloaded image" area at or near
> the start of SRAM which is followed by a reserved area.  As it is at
> best bad form and at worst possibly harmful in corner cases to write in
> this reserved area, we stop doing that by adding in the define
> NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
> area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
> At current we define the end of scratch space at 0x228 bytes past the
> start of scratch space this this gives us a lot of room to grow.  As
> these scratch uses are non-optional today, all targets are modified to
> respect this boundary.
> 
> Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
> 
> Cc: Albert Aribaud 
> Cc: Nagendra T S 
> Cc: Vaibhav Hiremath 
> Cc: Lokesh Vutla 
> Cc: Felipe Balbi 
> Cc: Igor Grinberg 
> Cc: Nikita Kiryanov 
> Cc: Paul Kocialkowski 
> Cc: Enric Balletbo i Serra 
> Cc: Adam Ford 
> Cc: Steve Sakoman 
> Cc: Stefan Roese 
> Cc: Thomas Weber 
> Cc: Hannes Schmelzer 
> Cc: Thomas Chou 
> Cc: Masahiro Yamada 
> Cc: Simon Glass 
> Cc: Joe Hershberger 
> Cc: Sam Protsenko 
> Cc: Heiko Schocher 
> Cc: Samuel Egli 
> Cc: Michal Simek 
> Cc: Wolfgang Denk 
> Cc: Mateusz Kulikowski 
> Cc: Ben Whitten 
> Cc: Stefano Babic 
> Cc: Bin Meng 
> Cc: Sekhar Nori 
> Cc: Mugunthan V N 
> Cc: "B, Ravi" 
> Cc: "Matwey V. Kornilov" 
> Cc: Ladislav Michl 
> Cc: Ash Charles 
> Cc: "Kipisz, Steven" 
> Cc: Daniel Allred 
> Signed-off-by: Tom Rini 
> Tested-by: Lokesh Vutla 
> Acked-by: Lokesh Vutla 
> Tested-by: Ladislav Michl 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] omap3logic: Fix PBIAS Bug

2016-09-07 Thread Tom Rini
On Fri, Aug 26, 2016 at 07:53:53AM -0500, Adam Ford wrote:

> From: Adam Ford 
> 
> The PBIAS fixing is done in the MMC driver, and doing it in the
> the board file conflicts with the driver causing intermittent
> hangs on reboot.  Remove this from the board file and let
> the driver do it.
> 
> Signed-off-by: Adam Ford 
> Reviewed-by: Tom Rini 
> 
> diff --git a/board/logicpd/omap3som/omap3logic.c 
> b/board/logicpd/omap3som/omap3logic.c
> index 51d2987..c2bb730 100644

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] board/BuR/common: increase NET_RETRY_COUNT to 10

2016-09-07 Thread Tom Rini
On Thu, Aug 25, 2016 at 09:18:56AM +0200, Hannes Schmelzer wrote:

> Sometimes boards may need more time to become stable network connection
> due to several reasons:
> 
> - phy speed
> - link-partner (switch)
> 
> Therefore we increase the retry-count to 10 for making sure that network
> connection works always.
> 
> Signed-off-by: Hannes Schmelzer 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] README: add cmd directory description

2016-09-07 Thread Tom Rini
On Fri, Aug 26, 2016 at 07:54:49PM +0800, Xu Ziyuan wrote:

> All of the command files have moved to cmd directory, add description to
> Directory Hierarchy.
> 
> Signed-off-by: Ziyuan Xu 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 3/3] ARM: AM57xx: Enable post-processing of FIT artifacts loaded by U-Boot

2016-09-07 Thread Tom Rini
On Wed, Aug 24, 2016 at 02:32:18PM -0500, Andrew F. Davis wrote:

> From: Andreas Dannenberg 
> 
> Enable the platform-specific post-processing of FIT-extracted blobs such
> as Kernel, DTB, and initramfs on TI AM57xx high-security (HS) devices
> which will ultimately invoke a ROM-based API call that performs secure
> processing such as blob authentication.
> 
> Signed-off-by: Andreas Dannenberg 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 2/3] ARM: DRA7xx: Enable post-processing of FIT artifacts loaded by U-Boot

2016-09-07 Thread Tom Rini
On Wed, Aug 24, 2016 at 02:32:17PM -0500, Andrew F. Davis wrote:

> From: Andreas Dannenberg 
> 
> Enable the platform-specific post-processing of FIT-extracted blobs such
> as Kernel, DTB, and initramfs on TI DRA7xx high-security (HS) devices
> which will ultimately invoke a ROM-based API call that performs secure
> processing such as blob authentication.
> 
> Signed-off-by: Andreas Dannenberg 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 1/3] ARM: AM43xx: Enable post-processing of FIT artifacts loaded by U-Boot

2016-09-07 Thread Tom Rini
On Wed, Aug 24, 2016 at 02:32:16PM -0500, Andrew F. Davis wrote:

> From: Andreas Dannenberg 
> 
> Enable the platform-specific post-processing of FIT-extracted blobs such
> as Kernel, DTB, and initramfs on TI AM43xx high-security (HS) devices
> which will ultimately invoke a ROM-based API call that performs secure
> processing such as blob authentication.
> 
> Signed-off-by: Andreas Dannenberg 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 4/4] tools: moveconfig: add --spl option to move options for SPL build

2016-09-07 Thread Tom Rini
On Mon, Aug 22, 2016 at 10:18:22PM +0900, Masahiro Yamada wrote:

> Prior to this commit, the tool could not move options guarded by
> CONFIG_SPL_BUILD ifdef conditionals because they do not show up in
> include/autoconf.mk.  This new option, if given, makes the tool
> parse spl/include/autoconf.mk instead of include/autoconf.mk,
> which is probably preferred behavior when moving options for SPL.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 3/4] tools: moveconfig: warn loudly if moved option has no entry in Kconfig

2016-09-07 Thread Tom Rini
On Mon, Aug 22, 2016 at 10:18:21PM +0900, Masahiro Yamada wrote:

> Currently, the tool gives up moving an option quietly if its entry
> was not found in Kconfig.
> 
> If the option is not defined in the config header in the first
> place, it is no problem (as the Kconfig entry may have been hidden
> by reasonable "depends on").
> 
> However, if the option is defined in the config header, the missing
> Kconfig entry is a sign of possible behavior change.  It is highly
> recommended to manually check if the option has been moved as
> expected.  In this case, let's add "suspicious" in the log and
> change the log color (if --color option is given) to make it stand
> out.
> 
> This was suggested by Tom in [1].
> 
> [1] http://lists.denx.de/pipermail/u-boot/2016-July/261988.html
> 
> Signed-off-by: Masahiro Yamada 
> Suggested-by: Tom Rini 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 1/4] tools: moveconfig: remove document about deprecated error message

2016-09-07 Thread Tom Rini
On Mon, Aug 22, 2016 at 10:18:19PM +0900, Masahiro Yamada wrote:

> Since commit cc008299f852 ("tools: moveconfig: do not rely on type
> and default value given by users"), we do not have this error case.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 2/4] tools: moveconfig: use sets instead of lists for failed/suspicious boards

2016-09-07 Thread Tom Rini
On Mon, Aug 22, 2016 at 10:18:20PM +0900, Masahiro Yamada wrote:

> The sets feature is handier for adding unique elements.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 3/4] pinctrl: add driver for meson-gxbb pin controller

2016-09-07 Thread Tom Rini
On Tue, Aug 16, 2016 at 11:49:49AM +0200, Beniamino Galvani wrote:

> Add a pin controller driver for Meson GXBB adapted from Linux kernel.
> 
> Signed-off-by: Beniamino Galvani 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 4/4] meson: odroid-c2: enable Ethernet support through the device tree

2016-09-07 Thread Tom Rini
On Tue, Aug 16, 2016 at 11:49:50AM +0200, Beniamino Galvani wrote:

> Remove the device definition from board file, update the driver with
> the new compatible property and update config with necessary options.
> 
> Signed-off-by: Beniamino Galvani 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 3/4] pinctrl: add driver for meson-gxbb pin controller

2016-09-07 Thread Tom Rini
On Tue, Aug 16, 2016 at 11:49:49AM +0200, Beniamino Galvani wrote:

> Add a pin controller driver for Meson GXBB adapted from Linux kernel.
> 
> Signed-off-by: Beniamino Galvani 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 2/4] arm: dts: update DTS files for meson-gxbb and odroid-c2

2016-09-07 Thread Tom Rini
On Tue, Aug 16, 2016 at 11:49:48AM +0200, Beniamino Galvani wrote:

> Import DTS files and dt-bindings includes from Linux 4.8-rc1.
> 
> Signed-off-by: Beniamino Galvani 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 1/4] pinctrl: generic: scan for "pins" and "groups" properties in sub-nodes

2016-09-07 Thread Tom Rini
On Tue, Aug 16, 2016 at 11:49:47AM +0200, Beniamino Galvani wrote:

> In cases where the pins and groups definitions are in a sub-node, as:
> 
>   uart_a {
>   mux {
>   groups = "uart_tx_a", "uart_rx_a";
>   function = "uart_a";
>   };
>   };
> 
> pinctrl_generic_set_state_subnode() returns an error for the top-level
> node and pinctrl_generic_set_state() fails. Instead, return success so
> that the child nodes are tried.
> 
> Signed-off-by: Beniamino Galvani 
> Reviewed-by: Simon Glass 
> Reviewed-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] configs: am4xhs: Modify SPL load address to fix UART boot issue

2016-09-07 Thread Tom Rini
On Wed, Aug 24, 2016 at 04:41:22PM -0400, Srinivas, Madan wrote:

> From: Madan Srinivas 
> 
> An issue in the TI secure image generation tool causes the ROM to
> load the SPL at a different load address than what is specified by
> CONFIG_ISW_ENTRY_ADDR while doing a peripheral boot on HS devices.
> 
> This causes the SPL to fail on secure devices during peripheral
> boot.
> 
> The TI secure image generation tool has been fixed so that the SPL
> will always be loaded at 0x403018E0 by the ROM code for both
> peripheral and memory boot modes.
> 
> Signed-off-by: Madan Srinivas 
> Reviewed-by: Nishanth Menon 
> Acked-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v4, 2/2] serial: bcm283x_mu: Detect disabled serial device

2016-09-07 Thread Tom Rini
On Mon, Aug 15, 2016 at 05:48:51PM +0200, Alexander Graf wrote:

> On the raspberry pi, you can disable the serial port to gain dynamic frequency
> scaling which can get handy at times.
> 
> However, in such a configuration the serial controller gets its rx queue 
> filled
> up with zero bytes which then happily get transmitted on to whoever calls
> getc() today.
> 
> This patch adds detection logic for that case by checking whether the RX pin 
> is
> mapped to GPIO15 and disables the mini uart if it is not mapped properly.
> 
> That way we can leave the driver enabled in the tree and can determine during
> runtime whether serial is usable or not, having a single binary that allows 
> for
> uart and non-uart operation.
> 
> Signed-off-by: Alexander Graf 
> Acked-by: Stephen Warren 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] image-fit: fix fit_image_load() OS check

2016-09-07 Thread Tom Rini
On Sun, Aug 14, 2016 at 08:31:24PM +0200, Andreas Bießmann wrote:

> Commit 62afc601883e788f3f22291202d5b2a23c1a8b06 introduced fpga image load via
> bootm but broke the OS check in fit_image_load().
> 
> This commit removes following compiler warning:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot,1/2] bcm2835_gpio: Implement GPIOF_FUNC

2016-09-07 Thread Tom Rini
On Thu, Aug 11, 2016 at 01:38:31PM +0200, Alexander Graf wrote:

> So far we could only tell the gpio framework that a GPIO was mapped as input 
> or
> output, not as alternative function.
> 
> This patch adds support for determining whether a function is mapped as
> alternative.
> 
> Signed-off-by: Alexander Graf 
> Reviewed-by: Simon Glass 
> Acked-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 9/9] MIPS: Malta: Enable CM & L2 support

2016-09-07 Thread Paul Burton
Enable support for the MIPS Coherence Manager & L2 caches on the MIPS
Malta board, removing the need for us to attempt to bypass the L2 during
boot (which would fail with recent CPUs that expose L2 config via the CM
anyway).

Signed-off-by: Paul Burton 

---

 arch/mips/Kconfig  | 2 ++
 board/imgtec/malta/lowlevel_init.S | 6 --
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 8f97727..4edb258 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -26,6 +26,8 @@ config TARGET_MALTA
select DM
select DM_SERIAL
select DYNAMIC_IO_PORT_BASE
+   select MIPS_CM
+   select MIPS_L2_CACHE
select OF_CONTROL
select OF_ISA_BUS
select SUPPORTS_BIG_ENDIAN
diff --git a/board/imgtec/malta/lowlevel_init.S 
b/board/imgtec/malta/lowlevel_init.S
index 3d48cdc..6df4d9f 100644
--- a/board/imgtec/malta/lowlevel_init.S
+++ b/board/imgtec/malta/lowlevel_init.S
@@ -28,12 +28,6 @@
 
.globl  lowlevel_init
 lowlevel_init:
-   /* disable any L2 cache for now */
-   sync
-   mfc0t0, CP0_CONFIG, 2
-   ori t0, t0, 0x1 << 12
-   mtc0t0, CP0_CONFIG, 2
-
/* detect the core card */
PTR_LI  t0, CKSEG1ADDR(MALTA_REVISION)
lw  t0, 0(t0)
-- 
2.9.3

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


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

2016-09-07 Thread Tom Rini
On Tue, Sep 06, 2016 at 06:54:52PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> apart of patches that I should put to -next and not in -master, there
> was something wrong in my tree. I had to rebase it (sorry for that..)
> and I moved all new features into -next. Just bug fixes remain, with the
> exception of:
> 
> Akshay Bhat (1):
>   arm: imx: Add support for Advantech DMS-BA16 board
> 
> I applied this one month ago, I do not know why it was slipped in
> previous PR.
> 
> -master builds clean - I will check then in -next the breakage. Sorry
> for inconvenience.
> 
> The following changes since commit b615267633996a9410a88b54a55965d8b021f6f8:
> 
>   ARM: tegra: Add support for TK1-SOM board from Colorado Engineering
> (2016-09-01 09:24:30 -0700)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to d4ee5043f36e7a418c3fb5be2e76eb5f6ee2cd9f:
> 
>   warp7: Print secure/non-secure mode info (2016-09-06 18:22:48 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 8/9] MIPS: L2 cache support

2016-09-07 Thread Paul Burton
This patch adds support for initialising & maintaining L2 caches on MIPS
systems. The L2 cache configuration may be advertised through either
coprocessor 0 or the MIPS Coherence Manager depending upon the system,
and support for both is included.

If the L2 can be bypassed then we bypass it early in boot & initialise
the L1 caches first, such that we can start making use of the L1
instruction cache as early as possible. Otherwise we initialise the L2
first such that the L1s have no opportunity to generate access to the
uninitialised L2.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig   |   6 ++
 arch/mips/include/asm/cm.h  |  38 
 arch/mips/include/asm/global_data.h |   3 +
 arch/mips/include/asm/mipsregs.h|   5 +
 arch/mips/lib/cache.c   |  62 -
 arch/mips/lib/cache_init.S  | 180 +++-
 6 files changed, 288 insertions(+), 6 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 732d129..8f97727 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -301,6 +301,12 @@ config MIPS_L1_CACHE_SHIFT
default "4" if MIPS_L1_CACHE_SHIFT_4
default "5"
 
+config MIPS_L2_CACHE
+   bool
+   help
+ Select this if your system includes an L2 cache and you want U-Boot
+ to initialise & maintain it.
+
 config DYNAMIC_IO_PORT_BASE
bool
 
diff --git a/arch/mips/include/asm/cm.h b/arch/mips/include/asm/cm.h
index 0261733..62ecef2 100644
--- a/arch/mips/include/asm/cm.h
+++ b/arch/mips/include/asm/cm.h
@@ -12,8 +12,46 @@
 #define GCR_BASE   0x0008
 #define GCR_BASE_UPPER 0x000c
 #define GCR_REV0x0030
+#define GCR_L2_CONFIG  0x0130
+#define GCR_L2_TAG_ADDR0x0600
+#define GCR_L2_TAG_ADDR_UPPER  0x0604
+#define GCR_L2_TAG_STATE   0x0608
+#define GCR_L2_TAG_STATE_UPPER 0x060c
+#define GCR_L2_DATA0x0610
+#define GCR_L2_DATA_UPPER  0x0614
 
 /* GCR_REV CM versions */
 #define GCR_REV_CM30x0800
 
+/* GCR_L2_CONFIG fields */
+#define GCR_L2_CONFIG_ASSOC_SHIFT  0
+#define GCR_L2_CONFIG_ASSOC_BITS   8
+#define GCR_L2_CONFIG_LINESZ_SHIFT 8
+#define GCR_L2_CONFIG_LINESZ_BITS  4
+#define GCR_L2_CONFIG_SETSZ_SHIFT  12
+#define GCR_L2_CONFIG_SETSZ_BITS   4
+#define GCR_L2_CONFIG_BYPASS   (1 << 20)
+
+#ifndef __ASSEMBLY__
+
+#include 
+
+static inline void *mips_cm_base(void)
+{
+   return (void *)CKSEG1ADDR(CONFIG_MIPS_CM_BASE);
+}
+
+static inline unsigned long mips_cm_l2_line_size(void)
+{
+   unsigned long l2conf, line_sz;
+
+   l2conf = __raw_readl(mips_cm_base() + GCR_L2_CONFIG);
+
+   line_sz = l2conf >> GCR_L2_CONFIG_LINESZ_SHIFT;
+   line_sz &= GENMASK(GCR_L2_CONFIG_LINESZ_BITS - 1, 0);
+   return line_sz ? (2 << line_sz) : 0;
+}
+
+#endif /* !__ASSEMBLY__ */
+
 #endif /* __MIPS_ASM_CM_H__ */
diff --git a/arch/mips/include/asm/global_data.h 
b/arch/mips/include/asm/global_data.h
index 8533b69..0078bbe 100644
--- a/arch/mips/include/asm/global_data.h
+++ b/arch/mips/include/asm/global_data.h
@@ -25,6 +25,9 @@ struct arch_global_data {
unsigned short l1i_line_size;
unsigned short l1d_line_size;
 #endif
+#ifdef CONFIG_MIPS_L2_CACHE
+   unsigned short l2_line_size;
+#endif
 };
 
 #include 
diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index cd4f952..b4c2dff 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -485,9 +485,13 @@
 #define MIPS_CONF1_TLBS_SIZE(6)
 #define MIPS_CONF1_TLBS (_ULCAST_(63) << MIPS_CONF1_TLBS_SHIFT)
 
+#define MIPS_CONF2_SA_SHF  0
 #define MIPS_CONF2_SA  (_ULCAST_(15) << 0)
+#define MIPS_CONF2_SL_SHF  4
 #define MIPS_CONF2_SL  (_ULCAST_(15) << 4)
+#define MIPS_CONF2_SS_SHF  8
 #define MIPS_CONF2_SS  (_ULCAST_(15) << 8)
+#define MIPS_CONF2_L2B (_ULCAST_(1) << 12)
 #define MIPS_CONF2_SU  (_ULCAST_(15) << 12)
 #define MIPS_CONF2_TA  (_ULCAST_(15) << 16)
 #define MIPS_CONF2_TL  (_ULCAST_(15) << 20)
@@ -551,6 +555,7 @@
 #define MIPS_CONF5_MVH (_ULCAST_(1) << 5)
 #define MIPS_CONF5_FRE (_ULCAST_(1) << 8)
 #define MIPS_CONF5_UFE (_ULCAST_(1) << 9)
+#define MIPS_CONF5_L2C (_ULCAST_(1) << 10)
 #define MIPS_CONF5_MSAEN   (_ULCAST_(1) << 27)
 #define MIPS_CONF5_EVA (_ULCAST_(1) << 28)
 #define MIPS_CONF5_CV  (_ULCAST_(1) << 29)
diff --git a/arch/mips/lib/cache.c b/arch/mips/lib/cache.c
index d8baf08..bd14ba6 100644
--- a/arch/mips/lib/cache.c
+++ b/arch/mips/lib/cache.c
@@ -7,10 +7,44 @@
 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+static void probe_l2(void)
+{
+#ifdef CONFIG_MIPS_L2_CACHE
+   unsigned long conf2, sl;
+   bool l2c = 

[U-Boot] [PATCH 7/9] MIPS: Map CM Global Control Registers

2016-09-07 Thread Paul Burton
Map the Global Control Registers (GCRs) provided by the MIPS Coherence
Manager (CM) in preparation for using some of them in later patches.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig  | 16 
 arch/mips/cpu/Makefile |  2 ++
 arch/mips/cpu/cm_init.S| 45 +
 arch/mips/cpu/start.S  |  6 ++
 arch/mips/include/asm/cm.h | 19 +++
 5 files changed, 88 insertions(+)
 create mode 100644 arch/mips/cpu/cm_init.S
 create mode 100644 arch/mips/include/asm/cm.h

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 34eb404..732d129 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -307,6 +307,22 @@ config DYNAMIC_IO_PORT_BASE
 config MACH_CPU_INIT
bool
 
+config MIPS_CM
+   bool
+   help
+ Select this if your system contains a MIPS Coherence Manager and you
+ wish U-Boot to configure it or make use of it to retrieve system
+ information such as cache configuration.
+
+config MIPS_CM_BASE
+   hex
+   default 0x1fbf8000
+   help
+ The physical base address at which to map the MIPS Coherence Manager
+ Global Configuration Registers (GCRs). This should be set such that
+ the GCRs occupy a region of the physical address space which is
+ otherwise unused, or at minimum that software doesn't need to access.
+
 endif
 
 endmenu
diff --git a/arch/mips/cpu/Makefile b/arch/mips/cpu/Makefile
index fc6b455..429fd3a 100644
--- a/arch/mips/cpu/Makefile
+++ b/arch/mips/cpu/Makefile
@@ -7,3 +7,5 @@ extra-y = start.o
 obj-y += time.o
 obj-y += interrupts.o
 obj-y += cpu.o
+
+obj-$(CONFIG_MIPS_CM)  += cm_init.o
diff --git a/arch/mips/cpu/cm_init.S b/arch/mips/cpu/cm_init.S
new file mode 100644
index 000..ddcaa49
--- /dev/null
+++ b/arch/mips/cpu/cm_init.S
@@ -0,0 +1,45 @@
+/*
+ * MIPS Coherence Manager (CM) Initialisation
+ *
+ * Copyright (c) 2016 Imagination Technologies Ltd.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+LEAF(mips_cm_map)
+   /* Config3 must exist for a CM to be present */
+   mfc0t0, CP0_CONFIG, 1
+   bgezt0, 2f
+   mfc0t0, CP0_CONFIG, 2
+   bgezt0, 2f
+
+   /* Check Config3.CMGCR to determine CM presence */
+   mfc0t0, CP0_CONFIG, 3
+   and t0, t0, MIPS_CONF3_CMGCR
+   beqzt0, 2f
+
+   /* Find the current physical GCR base address */
+1: MFC0t0, CP0_CMGCRBASE
+   PTR_SLL t0, t0, 4
+
+   /* If the GCRs are where we want, we're done */
+   PTR_LI  t1, CONFIG_MIPS_CM_BASE
+   beq t0, t1, 2f
+
+   /* Move the GCRs to our configured base address */
+   PTR_LI  t2, CKSEG1
+   PTR_ADDUt0, t0, t2
+   sw  zero, GCR_BASE_UPPER(t0)
+   sw  t1, GCR_BASE(t0)
+
+   /* Re-check the GCR base */
+   b   1b
+
+2: jr  ra
+   END(mips_cm_map)
diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
index 6f1d219..c157d03 100644
--- a/arch/mips/cpu/start.S
+++ b/arch/mips/cpu/start.S
@@ -141,6 +141,12 @@ reset:
 1:
PTR_L   gp, 0(ra)
 
+#ifdef CONFIG_MIPS_CM
+   PTR_LA  t9, mips_cm_map
+   jalrt9
+nop
+#endif
+
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
 # ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD
/* Initialize any external memory */
diff --git a/arch/mips/include/asm/cm.h b/arch/mips/include/asm/cm.h
new file mode 100644
index 000..0261733
--- /dev/null
+++ b/arch/mips/include/asm/cm.h
@@ -0,0 +1,19 @@
+/*
+ * MIPS Coherence Manager (CM) Register Definitions
+ *
+ * Copyright (c) 2016 Imagination Technologies Ltd.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef __MIPS_ASM_CM_H__
+#define __MIPS_ASM_CM_H__
+
+/* Global Control Register (GCR) offsets */
+#define GCR_BASE   0x0008
+#define GCR_BASE_UPPER 0x000c
+#define GCR_REV0x0030
+
+/* GCR_REV CM versions */
+#define GCR_REV_CM30x0800
+
+#endif /* __MIPS_ASM_CM_H__ */
-- 
2.9.3

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


[U-Boot] [PATCH 6/9] MIPS: Define register names for cache init

2016-09-07 Thread Paul Burton
Define names for registers holding cache sizes throughout
mips_cache_reset, in order to make the code easier to read & allow for
changing register assignments more easily.

Signed-off-by: Paul Burton 
---

 arch/mips/lib/cache_init.S | 42 +++---
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S
index c3fb249..2df3a82 100644
--- a/arch/mips/lib/cache_init.S
+++ b/arch/mips/lib/cache_init.S
@@ -98,19 +98,23 @@
  * RETURNS: N/A
  *
  */
+#define R_IC_SIZE  t2
+#define R_IC_LINE  t8
+#define R_DC_SIZE  t3
+#define R_DC_LINE  t9
 LEAF(mips_cache_reset)
 #ifndef CONFIG_SYS_CACHE_SIZE_AUTO
-   li  t2, CONFIG_SYS_ICACHE_SIZE
-   li  t8, CONFIG_SYS_ICACHE_LINE_SIZE
+   li  R_IC_SIZE, CONFIG_SYS_ICACHE_SIZE
+   li  R_IC_LINE, CONFIG_SYS_ICACHE_LINE_SIZE
 #else
-   l1_info t2, t8, MIPS_CONF1_IA_SHF
+   l1_info R_IC_SIZE, R_IC_LINE, MIPS_CONF1_IA_SHF
 #endif
 
 #ifndef CONFIG_SYS_CACHE_SIZE_AUTO
-   li  t3, CONFIG_SYS_DCACHE_SIZE
-   li  t9, CONFIG_SYS_DCACHE_LINE_SIZE
+   li  R_DC_SIZE, CONFIG_SYS_DCACHE_SIZE
+   li  R_DC_LINE, CONFIG_SYS_DCACHE_LINE_SIZE
 #else
-   l1_info t3, t9, MIPS_CONF1_DA_SHF
+   l1_info R_DC_SIZE, R_DC_LINE, MIPS_CONF1_DA_SHF
 #endif
 
 #ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD
@@ -123,9 +127,9 @@ LEAF(mips_cache_reset)
li  v0, CONFIG_SYS_DCACHE_SIZE
 #endif
 #else
-   movev0, t2
-   sltut1, t2, t3
-   movnv0, t3, t1
+   movev0, R_IC_SIZE
+   sltut1, R_IC_SIZE, R_DC_SIZE
+   movnv0, R_DC_SIZE, t1
 #endif
/*
 * Now clear that much memory starting from zero.
@@ -158,18 +162,18 @@ LEAF(mips_cache_reset)
/*
 * Initialize the I-cache first,
 */
-   blezt2, 1f
+   blezR_IC_SIZE, 1f
PTR_LI  t0, INDEX_BASE
-   PTR_ADDUt1, t0, t2
+   PTR_ADDUt1, t0, R_IC_SIZE
/* clear tag to invalidate */
-   cache_loop  t0, t1, t8, INDEX_STORE_TAG_I
+   cache_loop  t0, t1, R_IC_LINE, INDEX_STORE_TAG_I
 #ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD
/* fill once, so data field parity is correct */
PTR_LI  t0, INDEX_BASE
-   cache_loop  t0, t1, t8, FILL
+   cache_loop  t0, t1, R_IC_LINE, FILL
/* invalidate again - prudent but not strictly neccessary */
PTR_LI  t0, INDEX_BASE
-   cache_loop  t0, t1, t8, INDEX_STORE_TAG_I
+   cache_loop  t0, t1, R_IC_LINE, INDEX_STORE_TAG_I
 #endif
 
/* Enable use of the I-cache by setting Config.K0 */
@@ -187,20 +191,20 @@ LEAF(mips_cache_reset)
/*
 * then initialize D-cache.
 */
-1: blezt3, 3f
+1: blezR_DC_SIZE, 3f
PTR_LI  t0, INDEX_BASE
-   PTR_ADDUt1, t0, t3
+   PTR_ADDUt1, t0, R_DC_SIZE
/* clear all tags */
-   cache_loop  t0, t1, t9, INDEX_STORE_TAG_D
+   cache_loop  t0, t1, R_DC_LINE, INDEX_STORE_TAG_D
 #ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD
/* load from each line (in cached space) */
PTR_LI  t0, INDEX_BASE
 2: LONG_L  zero, 0(t0)
-   PTR_ADDUt0, t9
+   PTR_ADDUt0, R_DC_LINE
bne t0, t1, 2b
/* clear all tags */
PTR_LI  t0, INDEX_BASE
-   cache_loop  t0, t1, t9, INDEX_STORE_TAG_D
+   cache_loop  t0, t1, R_DC_LINE, INDEX_STORE_TAG_D
 #endif
 
 3: jr  ra
-- 
2.9.3

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


[U-Boot] [PATCH 5/9] MIPS: If we don't need DDR for cache init, init cache first

2016-09-07 Thread Paul Burton
On systems where cache initialisation doesn't require zeroed memory (ie.
systems where CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD is not defined)
perform cache initialisation prior to lowlevel_init & DDR
initialisation. This allows for DDR initialisation code to run cached &
thus significantly faster.

Signed-off-by: Paul Burton 
---

 arch/mips/cpu/start.S | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
index 6aec430..6f1d219 100644
--- a/arch/mips/cpu/start.S
+++ b/arch/mips/cpu/start.S
@@ -142,15 +142,24 @@ reset:
PTR_L   gp, 0(ra)
 
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
+# ifdef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD
/* Initialize any external memory */
PTR_LA  t9, lowlevel_init
jalrt9
 nop
+# endif
 
/* Initialize caches... */
PTR_LA  t9, mips_cache_reset
jalrt9
 nop
+
+# ifndef CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD
+   /* Initialize any external memory */
+   PTR_LA  t9, lowlevel_init
+   jalrt9
+nop
+# endif
 #endif
 
/* Set up temporary stack */
-- 
2.9.3

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


[U-Boot] [PATCH 4/9] MIPS: Preserve Config implementation-defined bits

2016-09-07 Thread Paul Burton
The coprocessor 0 Config register includes 9 implementation defined
bits, which in some processors do things like enable write combining or
other functionality. We ought not to wipe them to 0 during boot. Rather
than doing so, preserve their value & only clear the bits standardised
by the MIPS architecture.

Signed-off-by: Paul Burton 
---

 arch/mips/cpu/start.S| 5 +++--
 arch/mips/include/asm/mipsregs.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
index 827a544..6aec430 100644
--- a/arch/mips/cpu/start.S
+++ b/arch/mips/cpu/start.S
@@ -123,8 +123,9 @@ reset:
mtc0zero, CP0_COMPARE
 
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
-   /* CONFIG0 register */
-   li  t0, CONF_CM_UNCACHED
+   mfc0t0, CP0_CONFIG
+   and t0, t0, MIPS_CONF_IMPL
+   or  t0, t0, CONF_CM_UNCACHED
mtc0t0, CP0_CONFIG
 #endif
 
diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index 3185dc7..cd4f952 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -450,6 +450,7 @@
 #define MIPS_CONF_MT_FTLB  (_ULCAST_(4) <<  7)
 #define MIPS_CONF_AR   (_ULCAST_(7) << 10)
 #define MIPS_CONF_AT   (_ULCAST_(3) << 13)
+#define MIPS_CONF_IMPL (_ULCAST_(0x1ff) << 16)
 #define MIPS_CONF_M(_ULCAST_(1) << 31)
 
 /*
-- 
2.9.3

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


[U-Boot] [PATCH 2/9] MIPS: Probe cache line sizes once during boot

2016-09-07 Thread Paul Burton
Rather than probing the cache line sizes on every call of any cache
maintenance function, probe them once during boot & store the values in
the global data structure for later use. This will reduce the overhead
of the cache maintenance functions, which isn't a big deal yet but
becomes more important once L2 caches which may expose their properties
via coprocessor 2 or the CM are supported.

Signed-off-by: Paul Burton 
---

 arch/mips/cpu/cpu.c |  2 ++
 arch/mips/include/asm/cache.h   |  9 
 arch/mips/include/asm/global_data.h |  4 
 arch/mips/lib/cache.c   | 43 +
 4 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/arch/mips/cpu/cpu.c b/arch/mips/cpu/cpu.c
index 5ee80dd..a82c3c4 100644
--- a/arch/mips/cpu/cpu.c
+++ b/arch/mips/cpu/cpu.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -38,6 +39,7 @@ void write_one_tlb(int index, u32 pagemask, u32 hi, u32 low0, 
u32 low1)
 
 int arch_cpu_init(void)
 {
+   mips_cache_probe();
mach_cpu_init();
return 0;
 }
diff --git a/arch/mips/include/asm/cache.h b/arch/mips/include/asm/cache.h
index 0cea581..669c362 100644
--- a/arch/mips/include/asm/cache.h
+++ b/arch/mips/include/asm/cache.h
@@ -19,4 +19,13 @@
  */
 #define CONFIG_SYS_CACHELINE_SIZE ARCH_DMA_MINALIGN
 
+/**
+ * mips_cache_probe() - Probe the properties of the caches
+ *
+ * Call this to probe the properties such as line sizes of the caches
+ * present in the system, if any. This must be done before cache maintenance
+ * functions such as flush_cache may be called.
+ */
+void mips_cache_probe(void);
+
 #endif /* __MIPS_CACHE_H__ */
diff --git a/arch/mips/include/asm/global_data.h 
b/arch/mips/include/asm/global_data.h
index 37f8ed5..8533b69 100644
--- a/arch/mips/include/asm/global_data.h
+++ b/arch/mips/include/asm/global_data.h
@@ -21,6 +21,10 @@ struct arch_global_data {
unsigned long rev;
unsigned long ver;
 #endif
+#ifdef CONFIG_SYS_CACHE_SIZE_AUTO
+   unsigned short l1i_line_size;
+   unsigned short l1d_line_size;
+#endif
 };
 
 #include 
diff --git a/arch/mips/lib/cache.c b/arch/mips/lib/cache.c
index db81953..d8baf08 100644
--- a/arch/mips/lib/cache.c
+++ b/arch/mips/lib/cache.c
@@ -9,32 +9,39 @@
 #include 
 #include 
 
-static inline unsigned long icache_line_size(void)
-{
-   unsigned long conf1, il;
+DECLARE_GLOBAL_DATA_PTR;
 
-   if (!config_enabled(CONFIG_SYS_CACHE_SIZE_AUTO))
-   return CONFIG_SYS_ICACHE_LINE_SIZE;
+void mips_cache_probe(void)
+{
+#ifdef CONFIG_SYS_CACHE_SIZE_AUTO
+   unsigned long conf1, il, dl;
 
conf1 = read_c0_config1();
+
il = (conf1 & MIPS_CONF1_IL) >> MIPS_CONF1_IL_SHF;
-   if (!il)
-   return 0;
-   return 2 << il;
+   dl = (conf1 & MIPS_CONF1_DL) >> MIPS_CONF1_DL_SHF;
+
+   gd->arch.l1i_line_size = il ? (2 << il) : 0;
+   gd->arch.l1d_line_size = dl ? (2 << dl) : 0;
+#endif
 }
 
-static inline unsigned long dcache_line_size(void)
+static inline unsigned long icache_line_size(void)
 {
-   unsigned long conf1, dl;
-
-   if (!config_enabled(CONFIG_SYS_CACHE_SIZE_AUTO))
-   return CONFIG_SYS_DCACHE_LINE_SIZE;
+#ifdef CONFIG_SYS_CACHE_SIZE_AUTO
+   return gd->arch.l1i_line_size;
+#else
+   return CONFIG_SYS_ICACHE_LINE_SIZE;
+#endif
+}
 
-   conf1 = read_c0_config1();
-   dl = (conf1 & MIPS_CONF1_DL) >> MIPS_CONF1_DL_SHF;
-   if (!dl)
-   return 0;
-   return 2 << dl;
+static inline unsigned long dcache_line_size(void)
+{
+#ifdef CONFIG_SYS_CACHE_SIZE_AUTO
+   return gd->arch.l1d_line_size;
+#else
+   return CONFIG_SYS_DCACHE_LINE_SIZE;
+#endif
 }
 
 #define cache_loop(start, end, lsize, ops...) do { \
-- 
2.9.3

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


[U-Boot] [PATCH 3/9] MIPS: Enable use of the instruction cache earlier

2016-09-07 Thread Paul Burton
Enable use of the instruction cache immediately after it has been
initialised. This will only take effect if U-Boot was linked to run from
kseg0 rather than kseg1, but when this is the case the data cache
initialisation code will run cached & thus significantly faster.

Signed-off-by: Paul Burton 
---

 arch/mips/cpu/start.S  |  8 
 arch/mips/lib/cache_init.S | 12 
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
index fc6dd66..827a544 100644
--- a/arch/mips/cpu/start.S
+++ b/arch/mips/cpu/start.S
@@ -12,10 +12,6 @@
 #include 
 #include 
 
-#ifndef CONFIG_SYS_MIPS_CACHE_MODE
-#define CONFIG_SYS_MIPS_CACHE_MODE CONF_CM_CACHABLE_NONCOHERENT
-#endif
-
 #ifndef CONFIG_SYS_INIT_SP_ADDR
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + \
CONFIG_SYS_INIT_SP_OFFSET)
@@ -154,10 +150,6 @@ reset:
PTR_LA  t9, mips_cache_reset
jalrt9
 nop
-
-   /* ... and enable them */
-   li  t0, CONFIG_SYS_MIPS_CACHE_MODE
-   mtc0t0, CP0_CONFIG
 #endif
 
/* Set up temporary stack */
diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S
index bc8ab27..c3fb249 100644
--- a/arch/mips/lib/cache_init.S
+++ b/arch/mips/lib/cache_init.S
@@ -172,6 +172,18 @@ LEAF(mips_cache_reset)
cache_loop  t0, t1, t8, INDEX_STORE_TAG_I
 #endif
 
+   /* Enable use of the I-cache by setting Config.K0 */
+   mfc0t0, CP0_CONFIG
+   li  t1, CONFIG_SYS_MIPS_CACHE_MODE
+#if __mips_isa_rev >= 2
+   ins t0, t1, 0, 3
+#else
+   ori t0, t0, CONF_CM_CMASK
+   xorit0, t0, CONF_CM_CMASK
+   or  t0, t0, t1
+#endif
+   mtc0t0, CP0_CONFIG
+
/*
 * then initialize D-cache.
 */
-- 
2.9.3

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


[U-Boot] [PATCH 1/9] MIPS: Add arch-wide arch_cpu_init

2016-09-07 Thread Paul Burton
Add an implementation of arch_cpu_init that covers all MIPS boards, in
preparation for performing various pieces of initialisation there in
later patches.

In order to allow the ath79 code to continue performing initialisation
at this point in the boot, it's converted to use a new mach_cpu_init
function which is called from arch_cpu_init.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig   |  4 
 arch/mips/cpu/cpu.c |  6 ++
 arch/mips/include/asm/u-boot-mips.h | 12 
 arch/mips/mach-ath79/cpu.c  |  3 +--
 4 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 21066f0..34eb404 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -67,6 +67,7 @@ config ARCH_ATH79
bool "Support QCA/Atheros ath79"
select OF_CONTROL
select DM
+   select MACH_CPU_INIT
 
 config MACH_PIC32
bool "Support Microchip PIC32"
@@ -303,6 +304,9 @@ config MIPS_L1_CACHE_SHIFT
 config DYNAMIC_IO_PORT_BASE
bool
 
+config MACH_CPU_INIT
+   bool
+
 endif
 
 endmenu
diff --git a/arch/mips/cpu/cpu.c b/arch/mips/cpu/cpu.c
index 391feb3..5ee80dd 100644
--- a/arch/mips/cpu/cpu.c
+++ b/arch/mips/cpu/cpu.c
@@ -35,3 +35,9 @@ void write_one_tlb(int index, u32 pagemask, u32 hi, u32 low0, 
u32 low1)
write_c0_index(index);
tlb_write_indexed();
 }
+
+int arch_cpu_init(void)
+{
+   mach_cpu_init();
+   return 0;
+}
diff --git a/arch/mips/include/asm/u-boot-mips.h 
b/arch/mips/include/asm/u-boot-mips.h
index 1f527bb..0eaf32b 100644
--- a/arch/mips/include/asm/u-boot-mips.h
+++ b/arch/mips/include/asm/u-boot-mips.h
@@ -5,4 +5,16 @@
 #ifndef _U_BOOT_MIPS_H_
 #define _U_BOOT_MIPS_H_
 
+/**
+ * mach_cpu_init() - Perform SoC/machine-specific CPU initialisation
+ *
+ * This is called from arch_cpu_init() to allow for SoC/machine-level code to
+ * perform any CPU initialisation it may require.
+ */
+#ifdef CONFIG_MACH_CPU_INIT
+void mach_cpu_init(void);
+#else
+static inline void mach_cpu_init(void) {}
+#endif
+
 #endif /* _U_BOOT_MIPS_H_ */
diff --git a/arch/mips/mach-ath79/cpu.c b/arch/mips/mach-ath79/cpu.c
index 5756a06..a556b73 100644
--- a/arch/mips/mach-ath79/cpu.c
+++ b/arch/mips/mach-ath79/cpu.c
@@ -46,7 +46,7 @@ static const struct ath79_soc_desc desc[] = {
{ATH79_SOC_QCA9561, "9561", REV_ID_MAJOR_QCA9561,   0},
 };
 
-int arch_cpu_init(void)
+void mach_cpu_init(void)
 {
void __iomem *base;
enum ath79_soc_type soc = ATH79_SOC_UNKNOWN;
@@ -98,7 +98,6 @@ int arch_cpu_init(void)
gd->arch.soc = soc;
gd->arch.rev = rev;
gd->arch.ver = ver;
-   return 0;
 }
 
 int print_cpuinfo(void)
-- 
2.9.3

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


[U-Boot] [PATCH 0/9] MIPS L2 cache support

2016-09-07 Thread Paul Burton
This series introduces support for initialising & maintaining L2 caches
on MIPS systems. This allows U-Boot to function correctly on systems
where such caches are present, whereas without performing L2 maintenance
it is likely to fail with cache coherence issues when writing code or
performing DMA transfers.

Paul Burton (9):
  MIPS: Add arch-wide arch_cpu_init
  MIPS: Probe cache line sizes once during boot
  MIPS: Enable use of the instruction cache earlier
  MIPS: Preserve Config implementation-defined bits
  MIPS: If we don't need DDR for cache init, init cache first
  MIPS: Define register names for cache init
  MIPS: Map CM Global Control Registers
  MIPS: L2 cache support
  MIPS: Malta: Enable CM & L2 support

 arch/mips/Kconfig   |  28 +
 arch/mips/cpu/Makefile  |   2 +
 arch/mips/cpu/cm_init.S |  45 +++
 arch/mips/cpu/cpu.c |   8 ++
 arch/mips/cpu/start.S   |  26 +++--
 arch/mips/include/asm/cache.h   |   9 ++
 arch/mips/include/asm/cm.h  |  57 +
 arch/mips/include/asm/global_data.h |   7 ++
 arch/mips/include/asm/mipsregs.h|   6 +
 arch/mips/include/asm/u-boot-mips.h |  12 ++
 arch/mips/lib/cache.c   | 101 +---
 arch/mips/lib/cache_init.S  | 226 
 arch/mips/mach-ath79/cpu.c  |   3 +-
 board/imgtec/malta/lowlevel_init.S  |   6 -
 14 files changed, 482 insertions(+), 54 deletions(-)
 create mode 100644 arch/mips/cpu/cm_init.S
 create mode 100644 arch/mips/include/asm/cm.h

-- 
2.9.3

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


Re: [U-Boot] [PATCH 0/4] sunxi: Pine64 fixes

2016-09-07 Thread Andre Przywara
Hi,

On 07/09/16 17:12, Tom Rini wrote:
> On Wed, Sep 07, 2016 at 04:55:53PM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 07/09/16 16:48, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 07-09-16 17:18, Andre Przywara wrote:
 Hi,

 On 07/09/16 16:13, Hans de Goede wrote:
> Hi,
>
> On 05-09-16 02:32, Andre Przywara wrote:
>> Some patches to fix the Pine64 support:
>> The first two patches revert two patches that actually broke booting
>> Pine64 via the boot0 blob, already in 2016.07.
>> This has been discussed on IRC before, the commit messages contain
>> some details on the reasons for the revert. As the intent of those
>> original fixes was to help the (not yet upstream) SPL support, we don't
>> loose anything as the Pine64 uses the U-Boot proper only at the moment.
>>
>> Patch 3/4 removes the usage of a non-existing config symbol.
>> Patch 4/4 fixes a compiler warning when compiling sunxi's board.c
>> with a 64-bit compiler.
>>
>> Please apply for the 2016.09 release to allow booting Pine64s with
>> a recent U-Boot.
>
> I've send out a pull-req with patches 1, 3 and 4 yesterday and
> this has been merged.

 Thanks a lot! That's very helpful.

 Cheers,
 Andre.

 P.S. I have the SPL support with proper sunxi DRAM init mostly working,
 I am fighting with some bugs still (FIT loading related), but I am
 confident that this will be ready for the upcoming merge window.
>>>
>>> Cool, so do we then still need some closed firmware bits, or is everything
>>> open then ?
>>
>> Everything is proper FOSS, thanks to Jens, who took the existing U-Boot
>> H3 DRAM init bits and ported them to support the A64 as well.
>>
>> Also we don't need any boot0img anymore, mksunxiboot works as expected.
>> Appending the U-Boot proper directly to the SPL image works already, but
>> leaves out the ATF and thus SMP :-(
>> So I have improved SPL FIT support to load multiple images: load both
>> U-Boot and ATF, but jump to ATF, which in turn drops to U-Boot.
>> I chose the have the SPL in AArch64 (with a handful of AArch32
>> instructions in the beginning), which greatly simplifies the build
>> process. The drawback is increased code size, but I think we can cope
>> with that.
> 
> Nice!  Will it all also work with FEL mode?  That's how I'm integrating
> sunxi boards into my test farm.  Thanks!

Kind of ;-) Be assured that due to it's convenience FEL is quite
important to me too - especially when hacking on firmware.

I have some code which saves the FEL state before switching to AArch64,
and restores it after having switched back to AArch32 just after the SPL
calls return_to_fel(). That scheme worked with some experimental code (I
saw a UART character written by AArch64 code), but not with the real
SPL, I guess due to some stack trouble (IIRC FEL put some data into SRAM
C on the A64) or some state which the SPL has changed.
I have to revisit this, but wouldn't hold back a post if FEL is still
broken. If I can't fix it myself, I will put it somewhere and leave it
up to the pros to attack this.

Cheers,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] config USB_STORAGE: defconfig vs include header

2016-09-07 Thread Stephen Warren

Masahiro,

In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you added 
"config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just 
#defined by many include/configs/*.h rather than being defined in 
configs/*_defconfig. Is that a problem? It seems to work in practice, 
but leads people adding new boards to put the definition in 
configs/*_defconfig which then may be inconsistent with similar existing 
boards which have it defined in include/configs/*.h.

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


Re: [U-Boot] [PATCH 1/2][v2] arch: powerpc: update the IFC IP input clock

2016-09-07 Thread york sun
On 09/07/2016 01:36 AM, Prabhakar Kushwaha wrote:
> IFC IP clock is always a constant divisor of platform clock
> pre-defined per SoC. Clock control register (CCR) used in
> current implementation governs IFC IP output clock.
>
> So update IFC IP clock to be defined as per predefined clock
> divisor of platform clock.
>
> Signed-off-by: Prabhakar Kushwaha 
> ---
> Changes for v2: Split the patch in 2 patch set
>
>  README|  3 +++
>  arch/powerpc/cpu/mpc85xx/speed.c  | 10 ++
>  arch/powerpc/include/asm/config_mpc85xx.h |  9 +
>  3 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/README b/README
> index 30d7ee3..873a24c 100644
> --- a/README
> +++ b/README
> @@ -533,6 +533,9 @@ The following options need to be configured:
>   CONFIG_SYS_FSL_IFC_LE
>   Defines the IFC controller register space as Little Endian
>
> + CONFIG_SYS_FSL_IFC_CLK_DIV
> + Defines divider of platform clock(clock input to IFC 
> controller).
> +
>   CONFIG_SYS_FSL_PBL_PBI
>   It enables addition of RCW (Power on reset configuration) in 
> built image.
>   Please refer doc/README.pblimage for more details
> diff --git a/arch/powerpc/cpu/mpc85xx/speed.c 
> b/arch/powerpc/cpu/mpc85xx/speed.c
> index e732969..ea92ff3 100644
> --- a/arch/powerpc/cpu/mpc85xx/speed.c
> +++ b/arch/powerpc/cpu/mpc85xx/speed.c
> @@ -27,10 +27,6 @@ DECLARE_GLOBAL_DATA_PTR;
>  void get_sys_info(sys_info_t *sys_info)
>  {
>   volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> -#ifdef CONFIG_FSL_IFC
> - struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
> - u32 ccr;
> -#endif
>  #ifdef CONFIG_FSL_CORENET
>   volatile ccsr_clk_t *clk = (void *)(CONFIG_SYS_FSL_CORENET_CLK_ADDR);
>   unsigned int cpu;
> @@ -641,10 +637,8 @@ void get_sys_info(sys_info_t *sys_info)
>  #endif
>
>  #if defined(CONFIG_FSL_IFC)
> - ccr = ifc_in32(_regs.gregs->ifc_ccr);
> - ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
> -
> - sys_info->freq_localbus = sys_info->freq_systembus / ccr;
> + sys_info->freq_localbus = sys_info->freq_systembus /
> + CONFIG_SYS_FSL_IFC_CLK_DIV;
>  #endif
>  }
>

Prabhakar,

With these changes, you change the freq_localbus from the output of 
localbus to the internal clock. As far as I can tell, this variable is 
only used for display in U-Boot, and fixup bus-frequency in device tree 
for "fsl,elbc" and "fsl,pq3-localbus". I don't think kernel uses the 
clock though. The same variable is also used for mpc86xx. It may be a 
good idea to document this change in commit message and inline comment.

York

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


Re: [U-Boot] [PATCH 0/4] sunxi: Pine64 fixes

2016-09-07 Thread Tom Rini
On Wed, Sep 07, 2016 at 04:55:53PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 07/09/16 16:48, Hans de Goede wrote:
> > Hi,
> > 
> > On 07-09-16 17:18, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 07/09/16 16:13, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 05-09-16 02:32, Andre Przywara wrote:
>  Some patches to fix the Pine64 support:
>  The first two patches revert two patches that actually broke booting
>  Pine64 via the boot0 blob, already in 2016.07.
>  This has been discussed on IRC before, the commit messages contain
>  some details on the reasons for the revert. As the intent of those
>  original fixes was to help the (not yet upstream) SPL support, we don't
>  loose anything as the Pine64 uses the U-Boot proper only at the moment.
> 
>  Patch 3/4 removes the usage of a non-existing config symbol.
>  Patch 4/4 fixes a compiler warning when compiling sunxi's board.c
>  with a 64-bit compiler.
> 
>  Please apply for the 2016.09 release to allow booting Pine64s with
>  a recent U-Boot.
> >>>
> >>> I've send out a pull-req with patches 1, 3 and 4 yesterday and
> >>> this has been merged.
> >>
> >> Thanks a lot! That's very helpful.
> >>
> >> Cheers,
> >> Andre.
> >>
> >> P.S. I have the SPL support with proper sunxi DRAM init mostly working,
> >> I am fighting with some bugs still (FIT loading related), but I am
> >> confident that this will be ready for the upcoming merge window.
> > 
> > Cool, so do we then still need some closed firmware bits, or is everything
> > open then ?
> 
> Everything is proper FOSS, thanks to Jens, who took the existing U-Boot
> H3 DRAM init bits and ported them to support the A64 as well.
> 
> Also we don't need any boot0img anymore, mksunxiboot works as expected.
> Appending the U-Boot proper directly to the SPL image works already, but
> leaves out the ATF and thus SMP :-(
> So I have improved SPL FIT support to load multiple images: load both
> U-Boot and ATF, but jump to ATF, which in turn drops to U-Boot.
> I chose the have the SPL in AArch64 (with a handful of AArch32
> instructions in the beginning), which greatly simplifies the build
> process. The drawback is increased code size, but I think we can cope
> with that.

Nice!  Will it all also work with FEL mode?  That's how I'm integrating
sunxi boards into my test farm.  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCHv5 4/4] Add support the Avionic Design Meerkat COM and Kein Baseboard

2016-09-07 Thread Stephen Warren

On 09/07/2016 12:08 AM, Julian Scheel wrote:

On 06.09.2016 20:58, Stephen Warren wrote:

On 09/06/2016 12:14 PM, Julian Scheel wrote:

On 06.09.16 19:15, Stephen Warren wrote:

On 09/05/2016 07:29 AM, Julian Scheel wrote:

Add support for platforms based on the Meerkat COM module. Includes support
for the minimal reference platform called Kein Baseboard, which in fact is
sufficient to run most existing Meerkat carriers.



+CONFIG_USB_STORAGE=y


For Jetson TK1, this is defined in include/configs/jetson-tk1.h. I'd
expect the two board configs to work the same way.


Actually we have moved this to defconfig, as we decided that all options
that are Kconfig options by now shall be selectable via Kconfig by the
user.


Who's "we" here; has this conversion happened in mainline? If so, it
looks like the author of the conversion commit forgot to convert all the
existing configuration headers and defconfigs, so someone should go back
and fix up that commit. If the conversion hasn't happened in mainline, I
imagine it would be welcome so feel free to send it, but if this series
gets submitted before t conversion is submitted, it can't assume the
conversion has happened.


Sorry the wording might have been misleading. In this case "we" refers
to Avionic Design developers. And the discussion was not meant to be
applicable to u-boot in general, but for our board. We simply found it
to be useful to allow a maximum grade of u-boot customisation without
having to change source files.
If you would like to have this discussed in general beforehands, I'd be
happy to start the discussion on the list. But in that case we might
resubmit the patch, having the config options synced with jetson-tk1.h,
just to get these patches finally in.


Hmm. It looks like CONFIG_USB_STORAGE is defined in Kconfig in mainline, 
so this patch (at least this part) is actually OK. The patch which added 
it to Kconfig in mainline didn't convert all the board config files 
properly, which is why it's still set in many include/configs/*.h. I'll 
contact the author of that patch...

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


Re: [U-Boot] [U-Boot-DM] FPGA driver over PCI bus

2016-09-07 Thread Max Ruttenberg
Hi Simon,

Are you starting up PCI? For example, with:
>
> ret = uclass_get_device(UCLASS_PCI, 0, );
>
> If you are, then it should scan the bus and find and bind all the
> devices, in pci_bind_bus_devices(). You can add DEBUG to the very top
> of that file to see.
>
> But if you know the device is there, you may as well create a device
> tree-node for it. See chromebook_link.dts 'pci' node for an example.
> Then you can request the device directly, and PCI will be started up
> automatically.
>

I'm not calling uclass_get_device, which could be the source of my
troubles. I've made progress by calling pci_find_devices(ids, index)
directly in some non-static function and sticking a call to it in my
board's misc_init_r() function.
Something a clueless person might do. I'll the device tree node pointer
because that strikes me as the correct thing to do.


On Fri, Sep 2, 2016 at 6:52 PM, Simon Glass  wrote:

> Hi Max,
>
> On 1 September 2016 at 08:46, Max Ruttenberg
>  wrote:
> >
> > Hi,
> >
>
> (we should probably close down the u-boot-dm list - please use the main
> one)
>
> > I'm find myself clueless in regards to writing a driver for an FPGA over
> a
> > PCI bus. This U-Boot is running on an NXP t102xrdb board family, if that
> > matters.
> >
> > The documentation in doc/driver-model/pci-info.txt mentions that I can
> use
> > a macro named U_BOOT_PCI_DEVICE as alternative to listing my device in a
> > device tree.
> >
> > I found an example of this in drivers/net/e1000.c, and I tried to follow
> it
> > as much as was applicable (this is an ethernet driver, which my driver is
> > not).
> >
> > But when U-Boot starts up, my "bind" function is never called, even
> though
> > I can tell that my device with the corresponding vendor and device id is
> > detected using the "pci [bus]" command.
> >
> > I appreciate any help I can get.
>
> Are you starting up PCI? For example, with:
>
> ret = uclass_get_device(UCLASS_PCI, 0, );
>
> If you are, then it should scan the bus and find and bind all the
> devices, in pci_bind_bus_devices(). You can add DEBUG to the very top
> of that file to see.
>
> But if you know the device is there, you may as well create a device
> tree-node for it. See chromebook_link.dts 'pci' node for an example.
> Then you can request the device directly, and PCI will be started up
> automatically.
>
> Regards,
> Simon
>



-- 
Max Ruttenberg,
Member of the Technical Staff
Emu *Technology*
1400 E Angela Blvd, Unit 101
South Bend, IN 46617
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCHv5 4/4] Add support the Avionic Design Meerkat COM and Kein Baseboard

2016-09-07 Thread Stephen Warren

On 09/07/2016 12:03 AM, Julian Scheel wrote:

On 06.09.2016 20:53, Stephen Warren wrote:

On 09/05/2016 07:29 AM, Julian Scheel wrote:

Add support for platforms based on the Meerkat COM module. Includes
support
for the minimal reference platform called Kein Baseboard, which in
fact is
sufficient to run most existing Meerkat carriers.



diff --git a/board/avionic-design/common/meerkat.c
b/board/avionic-design/common/meerkat.c



+int tegra_pcie_board_init(void)



+err = as3722_init(, 4, 0x40);


Thinking about this more: Why I2C bus 4 not 0? All other boards set up
the PMIC I2C bus to be I2C bus 0 in U-Boot's numbering scheme. I'm not
sure we should deviate from that since it will provide users (running
the i2c command at the U-Boot shell) with an inconsistent experience.


Please see the discussion from earlier this year, when I initially sent
this patches:
http://lists.denx.de/pipermail/u-boot/2016-February/246952.html

Still if you're too unhappy about it now we would change it, but if not
we'd rather keep it that way. Having a user being confused because of
different mapping in our l4t kernel and uboot seems to be more likely
than a user being confused because of different mappings on different
boards to me.


OK, I guess that's fine. As I mentioned before, let's make sure there 
are aliases for the I2C controllers in the kernel DT file - otherwise, 
there's no guarantee of a particular ordering of I2C adapter IDs.

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


Re: [U-Boot] [PATCH 0/4] sunxi: Pine64 fixes

2016-09-07 Thread Andre Przywara
Hi,

On 07/09/16 16:48, Hans de Goede wrote:
> Hi,
> 
> On 07-09-16 17:18, Andre Przywara wrote:
>> Hi,
>>
>> On 07/09/16 16:13, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 05-09-16 02:32, Andre Przywara wrote:
 Some patches to fix the Pine64 support:
 The first two patches revert two patches that actually broke booting
 Pine64 via the boot0 blob, already in 2016.07.
 This has been discussed on IRC before, the commit messages contain
 some details on the reasons for the revert. As the intent of those
 original fixes was to help the (not yet upstream) SPL support, we don't
 loose anything as the Pine64 uses the U-Boot proper only at the moment.

 Patch 3/4 removes the usage of a non-existing config symbol.
 Patch 4/4 fixes a compiler warning when compiling sunxi's board.c
 with a 64-bit compiler.

 Please apply for the 2016.09 release to allow booting Pine64s with
 a recent U-Boot.
>>>
>>> I've send out a pull-req with patches 1, 3 and 4 yesterday and
>>> this has been merged.
>>
>> Thanks a lot! That's very helpful.
>>
>> Cheers,
>> Andre.
>>
>> P.S. I have the SPL support with proper sunxi DRAM init mostly working,
>> I am fighting with some bugs still (FIT loading related), but I am
>> confident that this will be ready for the upcoming merge window.
> 
> Cool, so do we then still need some closed firmware bits, or is everything
> open then ?

Everything is proper FOSS, thanks to Jens, who took the existing U-Boot
H3 DRAM init bits and ported them to support the A64 as well.

Also we don't need any boot0img anymore, mksunxiboot works as expected.
Appending the U-Boot proper directly to the SPL image works already, but
leaves out the ATF and thus SMP :-(
So I have improved SPL FIT support to load multiple images: load both
U-Boot and ATF, but jump to ATF, which in turn drops to U-Boot.
I chose the have the SPL in AArch64 (with a handful of AArch32
instructions in the beginning), which greatly simplifies the build
process. The drawback is increased code size, but I think we can cope
with that.

Cheers,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/4] sunxi: Pine64 fixes

2016-09-07 Thread Hans de Goede

Hi,

On 07-09-16 17:18, Andre Przywara wrote:

Hi,

On 07/09/16 16:13, Hans de Goede wrote:

Hi,

On 05-09-16 02:32, Andre Przywara wrote:

Some patches to fix the Pine64 support:
The first two patches revert two patches that actually broke booting
Pine64 via the boot0 blob, already in 2016.07.
This has been discussed on IRC before, the commit messages contain
some details on the reasons for the revert. As the intent of those
original fixes was to help the (not yet upstream) SPL support, we don't
loose anything as the Pine64 uses the U-Boot proper only at the moment.

Patch 3/4 removes the usage of a non-existing config symbol.
Patch 4/4 fixes a compiler warning when compiling sunxi's board.c
with a 64-bit compiler.

Please apply for the 2016.09 release to allow booting Pine64s with
a recent U-Boot.


I've send out a pull-req with patches 1, 3 and 4 yesterday and
this has been merged.


Thanks a lot! That's very helpful.

Cheers,
Andre.

P.S. I have the SPL support with proper sunxi DRAM init mostly working,
I am fighting with some bugs still (FIT loading related), but I am
confident that this will be ready for the upcoming merge window.


Cool, so do we then still need some closed firmware bits, or is everything
open then ?

Regards,

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


[U-Boot] [PATCH v2] fsl-ifc-nand : Corrected the programming of chip select

2016-09-07 Thread Matt Weber
Corrected the chip selection in IFC_NAND_CSEL register. Due to this
issue in multi-chip nand use-case, IFC was always pointing to the last
probed chip even though the user select another device through "nand
device " command.

Also, remove the usage of ifc_ctrl->cs_nand from driver as chipselect
is a property of the chip not the controller.

Signed-off-by: Matthew Weber 
Signed-off-by: Ronak Desai 

---
v1 -> v2
[ Scott W
 - Update fsl_ifc_sram_init() with correct csel and
   cs_nand removed.
---
 drivers/mtd/nand/fsl_ifc_nand.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 7001cbd..1912fc1 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -48,7 +48,6 @@ struct fsl_ifc_ctrl {
/* device info */
struct fsl_ifc regs;
void __iomem *addr;  /* Address of assigned IFC buffer*/
-   unsigned int cs_nand;/* On which chipsel NAND is connected*/
unsigned int page;   /* Last page written to / read from  */
unsigned int read_bytes; /* Number of bytes read during command   */
unsigned int column; /* Saved column from SEQIN   */
@@ -296,7 +295,7 @@ static int fsl_ifc_run_command(struct mtd_info *mtd)
int i;
 
/* set the chip select for NAND Transaction */
-   ifc_out32(>ifc_nand.nand_csel, ifc_ctrl->cs_nand);
+   ifc_out32(>ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT);
 
/* start read/write seq */
ifc_out32(>ifc_nand.nandseq_strt,
@@ -798,7 +797,7 @@ static void fsl_ifc_select_chip(struct mtd_info *mtd, int 
chip)
 {
 }
 
-static int fsl_ifc_sram_init(uint32_t ver)
+static int fsl_ifc_sram_init(uint32_t ver, struct fsl_ifc_mtd *priv)
 {
struct fsl_ifc_runtime *ifc = ifc_ctrl->regs.rregs;
uint32_t cs = 0, csor = 0, csor_8k = 0, csor_ext = 0;
@@ -823,7 +822,7 @@ static int fsl_ifc_sram_init(uint32_t ver)
return 1;
}
 
-   cs = ifc_ctrl->cs_nand >> IFC_NAND_CSEL_SHIFT;
+   cs = priv->bank;
 
/* Save CSOR and CSOR_ext */
csor = ifc_in32(_ctrl->regs.gregs->csor_cs[cs].csor);
@@ -850,7 +849,7 @@ static int fsl_ifc_sram_init(uint32_t ver)
ifc_out32(>ifc_nand.col0, 0x0);
 
/* set the chip select for NAND Transaction */
-   ifc_out32(>ifc_nand.nand_csel, ifc_ctrl->cs_nand);
+   ifc_out32(>ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT);
 
/* start read seq */
ifc_out32(>ifc_nand.nandseq_strt, IFC_NAND_SEQ_STRT_FIR_STRT);
@@ -912,7 +911,6 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
 
if ((cspr & CSPR_V) && (cspr & CSPR_MSEL) == CSPR_MSEL_NAND &&
(cspr & CSPR_BA) == CSPR_PHYS_ADDR(phys_addr)) {
-   ifc_ctrl->cs_nand = priv->bank << IFC_NAND_CSEL_SHIFT;
break;
}
}
@@ -1029,7 +1027,7 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
 
ver = ifc_in32(>ifc_rev);
if (ver >= FSL_IFC_V1_1_0)
-   ret = fsl_ifc_sram_init(ver);
+   ret = fsl_ifc_sram_init(ver, priv);
if (ret)
return ret;
 
-- 
1.9.1

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


Re: [U-Boot] [PATCH 06/11] arm: socfpga: misc: Segregate the misc.c for Stratix 10

2016-09-07 Thread Marek Vasut
On 09/07/2016 03:28 PM, Chin Liang See wrote:
> On Tue, 2016-09-06 at 14:09 +0200, Marek Vasut wrote:
>> On 09/06/2016 08:19 AM, Chin Liang See wrote:
>>> On Mon, 2016-09-05 at 18:01 +0200, Marek Vasut wrote:
 On 08/22/2016 05:02 PM, Chin Liang See wrote:
> Segregate the misc.c to support both GEN5 SoC and Stratix 10
> SoC.
>
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Ley Foon Tan 
> ---
>  arch/arm/mach-socfpga/misc.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach
> -socfpga/misc.c
> index 5cbd8a4..295121f 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -24,6 +24,8 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> +
>  static struct pl310_regs *const pl310 =
>   (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
>  static struct socfpga_system_manager *sysmgr_regs =
> @@ -34,6 +36,7 @@ static struct nic301_registers *nic301_regs =
>   (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
>  static struct scu_registers *scu_regs =
>   (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
> +#endif
>  
>  int dram_init(void)
>  {
> @@ -41,6 +44,7 @@ int dram_init(void)
>   return 0;
>  }
>  
> +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
>  void enable_caches(void)
>  {
>  #ifndef CONFIG_SYS_ICACHE_OFF
> @@ -246,6 +250,7 @@ static int socfpga_fpga_id(const bool
> print_id)
>  socfpga_fpga_model[i].name, version);
>   return i;
>  }
> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>  
>  /*
>   * Print CPU information
> @@ -253,14 +258,20 @@ static int socfpga_fpga_id(const bool
> print_id)
>  #if defined(CONFIG_DISPLAY_CPUINFO)
>  int print_cpuinfo(void)
>  {
> +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
>   const u32 bsel = readl(_regs->bootinfo) & 0x7;
>   puts("CPU:   Altera SoCFPGA Platform\n");
>   socfpga_fpga_id(1);
>   printf("BOOT:  %s\n", bsel_str[bsel].name);
> +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> + puts("CPU:   Altera SoCFPGA Platform\n");
> + puts("FPGA:  Altera Stratix 10\n");
> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */

 Can't you decode the boot mode and FPGA type instead ?
>>>
>>> That is a good question. This is now not available in SOC Virtual
>>> Platform. But will definitely enhance this in later stage with
>>> hardware
>>> available.
>>
>> What do you mean not available ? Does the VT not emulate the SoC
>> precisely ?
>>
> 
> The VT doesn't emulate the Secure Device Manager (SDM) part as its
> focusing on ARM64 for this phase.

And the SDM is now the place from which you fish out the information
about the FPGA and bootmode ?


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


Re: [U-Boot] [PATCH 11/11] arm: socfpga: Add support for Stratix 10 SoC dev kit

2016-09-07 Thread Marek Vasut
On 09/07/2016 03:33 PM, Chin Liang See wrote:
> On Tue, 2016-09-06 at 14:15 +0200, Marek Vasut wrote:
>> On 09/06/2016 11:18 AM, Chin Liang See wrote:
>>> On Mon, 2016-09-05 at 18:06 +0200, Marek Vasut wrote:
 On 08/22/2016 05:02 PM, Chin Liang See wrote:
> Add support for Stratix 10 SoC development kit
>
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Ley Foon Tan 
> ---
>  arch/arm/Kconfig  |   7 +-
>  arch/arm/mach-socfpga/Kconfig |  10 +++
>  configs/socfpga_stratix10_defconfig   |  14 
>  include/configs/socfpga_stratix10_socdk.h | 135
> ++
>  4 files changed, 163 insertions(+), 3 deletions(-)
>  create mode 100755 configs/socfpga_stratix10_defconfig
>  create mode 100644 include/configs/socfpga_stratix10_socdk.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index aef901c..c8e8767 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -600,10 +600,11 @@ config ARCH_SNAPDRAGON
>
>  config ARCH_SOCFPGA
> bool "Altera SOCFPGA family"
> -   select CPU_V7
> -   select SUPPORT_SPL
> +   select CPU_V7 if !TARGET_SOCFPGA_STRATIX10
> +   select ARM64 if TARGET_SOCFPGA_STRATIX10
> +   select SUPPORT_SPL if !TARGET_SOCFPGA_STRATIX10
> select OF_CONTROL
> -   select SPL_OF_CONTROL
> +   select SPL_OF_CONTROL if !TARGET_SOCFPGA_STRATIX10

 Why is the SPL disabled ?
>>>
>>> We will be having SPL for Stratix 10. It will added in later days
>>> as
>>> SPL main function is for DDR setup. This is not needed for SOC
>>> Virtual
>>> Platform now.
>>
>> Please do things right from the start, add the SPL and skip the DRAM
>> init if it's not needed.
> 
> That is my next to do list as I am enabling the Stratix 10 by phases.
> In this case, I shall repost this series once getting SPL available.

That's fine. When do you see that happening ?

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


Re: [U-Boot] [PATCH 07/11] arm: socfpga: sysmgr: Fix casting warning when enabling ARM64

2016-09-07 Thread Marek Vasut
On 09/07/2016 03:31 PM, Chin Liang See wrote:
> On Tue, 2016-09-06 at 14:12 +0200, Marek Vasut wrote:
>> On 09/06/2016 11:41 AM, Chin Liang See wrote:
>>> On Mon, 2016-09-05 at 18:02 +0200, Marek Vasut wrote:
 On 08/22/2016 05:02 PM, Chin Liang See wrote:
> Fix casting warning to pointer from integer of different size
> when enabling ARM64 support

 What sort of error did you observe ?
>>>
>>> The warning is triggered as ARM64 has build flag -Wpointer-to-int
>>> -cast
>>> and similar. Here is the build error log
>>>
>>> arch/arm/mach-socfpga/system_manager.c: In function
>>> sysmgr_pinmux_init:
>>>
>>> 
>>>   arch/arm/mach-socfpga/system_manager.c:59:18: warning:
>>> cast
>>> from pointer to integer of different size [-Wpointer-to-int-cast]  
>>> 
>>>   uint32_t regs = (uint32_t)_regs
>>> ->emacio[0];   
>>> 
>>>   ^
>>> 
>>>
>>> 
>>>   In file
>>> included from arch/arm/mach-socfpga/system_manager.c:8:0:  
>>> 
>>>
>>> 
>>>   ./arch/arm/include/asm/io.h:78:29: warning: cast to pointer
>>> from
>>> integer of different size [-Wint-to-pointer-cast]  
>>> 
>>> #define __arch_putl(v,a)  (*(volatile unsigned
>>> int
>>> *)(a) = (v))   
>>> 
>>
>> I see ... Except the code below does regs += sizeof(regs); , which in
>> the original case increments the address by 4 , but with your change,
>> the increment would be 16 . So this patch breaks things.
>>
> 
> Relook back, this portion is not being used and hence not being
> validated. Will put #ifdef in place to skip out these code.

Which portion is not used ? I don't understand why this patch is valid,
in fact I think it is wrong.

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


Re: [U-Boot] [PATCH 04/11] arm: socfpga: clkmgr: Segregate the Clock Manager for Stratix 10

2016-09-07 Thread Marek Vasut
On 09/07/2016 03:26 PM, Chin Liang See wrote:
> On Tue, 2016-09-06 at 14:08 +0200, Marek Vasut wrote:
>> On 09/06/2016 07:14 AM, Chin Liang See wrote:
>>> On Mon, 2016-09-05 at 17:58 +0200, Marek Vasut wrote:
 On 08/22/2016 05:02 PM, Chin Liang See wrote:
> Segregate the Clock Manager to support both GEN5 SoC and
> Stratix 10 SoC.
>
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Ley Foon Tan 
> ---
>  arch/arm/mach-socfpga/clock_manager.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/clock_manager.c
> b/arch/arm/mach
> -socfpga/clock_manager.c
> index aa71636..0d67b3c 100644
> --- a/arch/arm/mach-socfpga/clock_manager.c
> +++ b/arch/arm/mach-socfpga/clock_manager.c
> @@ -10,6 +10,7 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  static const struct socfpga_clock_manager *clock_manager_base
> =
>   (struct socfpga_clock_manager
> *)SOCFPGA_CLKMGR_ADDRESS;
>  
> @@ -446,9 +447,11 @@ unsigned int cm_get_l4_sp_clk_hz(void)
>  
>   return clock;
>  }
> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>  
>  unsigned int cm_get_mmc_controller_clk_hz(void)
>  {
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>   uint32_t reg, clock = 0;
>  
>   /* identify the source of MMC clock */
> @@ -475,8 +478,12 @@ unsigned int
> cm_get_mmc_controller_clk_hz(void)
>   /* further divide by 4 as we have fixed divider at
> wrapper
> */
>   clock /= 4;
>   return clock;
> +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> + return 2500;
> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>  }
>  
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  unsigned int cm_get_qspi_controller_clk_hz(void)

 Are you sure this won't cause build breakage ? I believe this is
 still
 used by the cadence qspi driver.
>>>
>>> That is a good question. As for SOC Virtual Platform, we are not
>>> enabling the QSPI controller.
>>
>> When stratix 10 ships, this will be left broken then ?
>>
> 
> Definitely not as we will enable and validate this against emulation in
> coming weeks.

Great, thanks. U-Boot 2016.09 is out on sept. 12 , so that should give
you some space to clean this up.

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


Re: [U-Boot] [PATCH 0/4] sunxi: Pine64 fixes

2016-09-07 Thread Andre Przywara
Hi,

On 07/09/16 16:13, Hans de Goede wrote:
> Hi,
> 
> On 05-09-16 02:32, Andre Przywara wrote:
>> Some patches to fix the Pine64 support:
>> The first two patches revert two patches that actually broke booting
>> Pine64 via the boot0 blob, already in 2016.07.
>> This has been discussed on IRC before, the commit messages contain
>> some details on the reasons for the revert. As the intent of those
>> original fixes was to help the (not yet upstream) SPL support, we don't
>> loose anything as the Pine64 uses the U-Boot proper only at the moment.
>>
>> Patch 3/4 removes the usage of a non-existing config symbol.
>> Patch 4/4 fixes a compiler warning when compiling sunxi's board.c
>> with a 64-bit compiler.
>>
>> Please apply for the 2016.09 release to allow booting Pine64s with
>> a recent U-Boot.
> 
> I've send out a pull-req with patches 1, 3 and 4 yesterday and
> this has been merged.

Thanks a lot! That's very helpful.

Cheers,
Andre.

P.S. I have the SPL support with proper sunxi DRAM init mostly working,
I am fighting with some bugs still (FIT loading related), but I am
confident that this will be ready for the upcoming merge window.

>>
>>
>> Andre Przywara (4):
>>   Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"
>>   Revert "sunxi: Downclock AHB1 to 100MHz on Allwinner A64"
>>   sunxi: Kconfig: rename non-existent SUN50I_A64 config symbol
>>   sunxi: fix 64-bit compiler warning for SPL header parsing
>>
>>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 -
>>  board/sunxi/Kconfig   | 2 +-
>>  board/sunxi/board.c   | 2 +-
>>  include/configs/sunxi-common.h| 5 +++--
>>  4 files changed, 5 insertions(+), 9 deletions(-)
>>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/4] sunxi: Pine64 fixes

2016-09-07 Thread Hans de Goede

Hi,

On 05-09-16 02:32, Andre Przywara wrote:

Some patches to fix the Pine64 support:
The first two patches revert two patches that actually broke booting
Pine64 via the boot0 blob, already in 2016.07.
This has been discussed on IRC before, the commit messages contain
some details on the reasons for the revert. As the intent of those
original fixes was to help the (not yet upstream) SPL support, we don't
loose anything as the Pine64 uses the U-Boot proper only at the moment.

Patch 3/4 removes the usage of a non-existing config symbol.
Patch 4/4 fixes a compiler warning when compiling sunxi's board.c
with a 64-bit compiler.

Please apply for the 2016.09 release to allow booting Pine64s with
a recent U-Boot.


I've send out a pull-req with patches 1, 3 and 4 yesterday and
this has been merged.

Regards,

Hans




Thanks,
Andre.


Andre Przywara (4):
  Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"
  Revert "sunxi: Downclock AHB1 to 100MHz on Allwinner A64"
  sunxi: Kconfig: rename non-existent SUN50I_A64 config symbol
  sunxi: fix 64-bit compiler warning for SPL header parsing

 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 -
 board/sunxi/Kconfig   | 2 +-
 board/sunxi/board.c   | 2 +-
 include/configs/sunxi-common.h| 5 +++--
 4 files changed, 5 insertions(+), 9 deletions(-)


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


Re: [U-Boot] [PATCH 21/21] arm: imx: add i.MX6ULL 14x14 EVK board support

2016-09-07 Thread Jagan Teki
On Thu, Aug 11, 2016 at 11:32 AM, Peng Fan  wrote:
> Add i.MX6ULL EVK board support:
> Add device tree file, which is copied from NXP Linux.
> Enabled DM_MMC, DM_GPIO, DM_I2C, DM_SPI, PINCTRL, DM_REGULATOR.
> The uart iomux settings are still keeped in board file.
>
> Boot Log:
> U-Boot 2016.09-rc1-00366-gbb419ef-dirty (Aug 11 2016 - 13:08:58 +0800)
>
> CPU:   Freescale i.MX6ULL rev1.0 at 396MHz
> CPU:   Commercial temperature grade (0C to 95C) at 15C
> Reset cause: POR
> Model: Freescale i.MX6 ULL 14x14 EVK Board
> Board: MX6ULL 14x14 EVK
> DRAM:  512 MiB
> MMC:   initialized IMX pinctrl driver
> FSL_SDHC: 0, FSL_SDHC: 1



> diff --git a/board/freescale/mx6ullevk/mx6ullevk.c 
> b/board/freescale/mx6ullevk/mx6ullevk.c
> new file mode 100644
> index 000..489bf21
> --- /dev/null
> +++ b/board/freescale/mx6ullevk/mx6ullevk.c
> @@ -0,0 +1,99 @@
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |\
> +   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
> +   PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
> +
> +int dram_init(void)
> +{
> +   gd->ram_size = imx_ddr_size();
> +
> +   return 0;
> +}
> +
> +static iomux_v3_cfg_t const uart1_pads[] = {
> +   MX6_PAD_UART1_TX_DATA__UART1_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
> +   MX6_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
> +};
> +
> +static void setup_iomux_uart(void)
> +{
> +   imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
> +}
> +
> +int board_mmc_get_env_dev(int devno)
> +{
> +   return devno;
> +}
> +
> +int mmc_map_to_kernel_blk(int devno)
> +{
> +   return devno;
> +}
> +
> +int board_early_init_f(void)
> +{
> +   setup_iomux_uart();

Don't we need iomux settings for sdhc? I guess pinctrl for SD not
supporting now.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 01/11] arm: socfpga: stratix10: Add SOCFPGA Stratix10 base address

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 09:29 -0500, Dinh Nguyen wrote:
> 
> On 09/06/2016 05:03 AM, Chin Liang See wrote:
> > Add base address header file for Stratix10 SoC
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > Acked-by: Marek Vasut 
> > ---
> >  arch/arm/mach-socfpga/include/mach/base_addr_s10.h | 48
> > ++
> >  1 file changed, 48 insertions(+)
> >  create mode 100755 arch/arm/mach
> > -socfpga/include/mach/base_addr_s10.h
> > 
> > diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > new file mode 100755
> 
> Shouldn't this be 644?

Good catch as seems my editor is using this mode when creating new
files. Will chmod and fix it

Thanks
Chin Liang

> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 11/11] arm: socfpga: Add support for Stratix 10 SoC dev kit

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 14:15 +0200, Marek Vasut wrote:
> On 09/06/2016 11:18 AM, Chin Liang See wrote:
> > On Mon, 2016-09-05 at 18:06 +0200, Marek Vasut wrote:
> > > On 08/22/2016 05:02 PM, Chin Liang See wrote:
> > > > Add support for Stratix 10 SoC development kit
> > > >
> > > > Signed-off-by: Chin Liang See 
> > > > Cc: Marek Vasut 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Ley Foon Tan 
> > > > ---
> > > >  arch/arm/Kconfig  |   7 +-
> > > >  arch/arm/mach-socfpga/Kconfig |  10 +++
> > > >  configs/socfpga_stratix10_defconfig   |  14 
> > > >  include/configs/socfpga_stratix10_socdk.h | 135
> > > > ++
> > > >  4 files changed, 163 insertions(+), 3 deletions(-)
> > > >  create mode 100755 configs/socfpga_stratix10_defconfig
> > > >  create mode 100644 include/configs/socfpga_stratix10_socdk.h
> > > >
> > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > index aef901c..c8e8767 100644
> > > > --- a/arch/arm/Kconfig
> > > > +++ b/arch/arm/Kconfig
> > > > @@ -600,10 +600,11 @@ config ARCH_SNAPDRAGON
> > > >
> > > >  config ARCH_SOCFPGA
> > > > bool "Altera SOCFPGA family"
> > > > -   select CPU_V7
> > > > -   select SUPPORT_SPL
> > > > +   select CPU_V7 if !TARGET_SOCFPGA_STRATIX10
> > > > +   select ARM64 if TARGET_SOCFPGA_STRATIX10
> > > > +   select SUPPORT_SPL if !TARGET_SOCFPGA_STRATIX10
> > > > select OF_CONTROL
> > > > -   select SPL_OF_CONTROL
> > > > +   select SPL_OF_CONTROL if !TARGET_SOCFPGA_STRATIX10
> > >
> > > Why is the SPL disabled ?
> >
> > We will be having SPL for Stratix 10. It will added in later days
> > as
> > SPL main function is for DDR setup. This is not needed for SOC
> > Virtual
> > Platform now.
>
> Please do things right from the start, add the SPL and skip the DRAM
> init if it's not needed.

That is my next to do list as I am enabling the Stratix 10 by phases.
In this case, I shall repost this series once getting SPL available.

Thanks
Chin Liang

>
> > > > select DM
> > > > select DM_SPI_FLASH
> > > > select DM_SPI
> > > > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach
> > > > -socfpga/Kconfig
> > > > index 1a43c7b..4e3b238 100644
> > > > --- a/arch/arm/mach-socfpga/Kconfig
> > > > +++ b/arch/arm/mach-socfpga/Kconfig
> > > > @@ -11,6 +11,9 @@ config TARGET_SOCFPGA_CYCLONE5
> > > >  config TARGET_SOCFPGA_GEN5
> > > > bool
> > > >
> > > > +config TARGET_SOCFPGA_STRATIX10
> > > > +   bool
> > > > +
> > > >  choice
> > > > prompt "Altera SOCFPGA board select"
> > > > optional
> > > > @@ -51,6 +54,10 @@ config TARGET_SOCFPGA_TERASIC_SOCKIT
> > > > bool "Terasic SoCkit (Cyclone V)"
> > > > select TARGET_SOCFPGA_CYCLONE5
> > > >
> > > > +config TARGET_SOCFPGA_STRATIX10_SOCDK
> > > > +   bool "Altera SOCFPGA SoCDK (Stratix 10)"
> > > > +   select TARGET_SOCFPGA_STRATIX10
> > > > +
> > > >  endchoice
> > > >
> > > >  config SYS_BOARD
> > > > @@ -63,6 +70,7 @@ config SYS_BOARD
> > > > default "socrates" if TARGET_SOCFPGA_EBV_SOCRATES
> > > > default "sr1500" if TARGET_SOCFPGA_SR1500
> > > > default "vining_fpga" if
> > > > TARGET_SOCFPGA_SAMTEC_VINING_FPGA
> > > > +   default "stratix10-socdk" if
> > > > TARGET_SOCFPGA_STRATIX10_SOCDK
> > >
> > > Keep all the lists sorted .
> >
> > Noted, will fix this.
> >
> > >
> > > >  config SYS_VENDOR
> > > > default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
> > > > @@ -72,6 +80,7 @@ config SYS_VENDOR
> > > > default "samtec" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
> > > > default "terasic" if TARGET_SOCFPGA_TERASIC_DE0_NANO
> > > > default "terasic" if TARGET_SOCFPGA_TERASIC_SOCKIT
> > > > +   default "altera" if TARGET_SOCFPGA_STRATIX10_SOCDK
> > > >
> > > >  config SYS_SOC
> > > > default "socfpga"
> > > > @@ -86,5 +95,6 @@ config SYS_CONFIG_NAME
> > > > default "socfpga_socrates" if
> > > > TARGET_SOCFPGA_EBV_SOCRATES
> > > > default "socfpga_sr1500" if TARGET_SOCFPGA_SR1500
> > > > default "socfpga_vining_fpga" if
> > > > TARGET_SOCFPGA_SAMTEC_VINING_FPGA
> > > > +   default "socfpga_stratix10_socdk" if
> > > > TARGET_SOCFPGA_STRATIX10_SOCDK
> > > >
> > > >  endif
> > >
> > > [...]
> > >
> > > btw. what about Arria 10 ? Will it ever land ?
> > > And will I ever get a kit ? :)
> >
> > Since S10 is good, I will help out the A10 upstreaming once S10 is
> > intergrated. While for dev kit, let me work that out as we have A10
> > dev
> > kit with production silicon :)
>
> The production silicon a10 is still not available ?
>
> > Thanks
> > Chin Liang
> >
> > >
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 09/11] arm: socfpga: stratix10: Add board directory for Stratix 10 socdk

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 09:30 -0500, Dinh Nguyen wrote:
> 
> On 09/06/2016 05:03 AM, Chin Liang See wrote:
> > Add board folder for Stratix 10 SoC development kit
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > ---
> >  board/altera/stratix10-socdk/MAINTAINERS | 7 +++
> >  board/altera/stratix10-socdk/Makefile| 7 +++
> >  board/altera/stratix10-socdk/socfpga.c   | 7 +++
> >  3 files changed, 21 insertions(+)
> >  create mode 100755 board/altera/stratix10-socdk/MAINTAINERS
> >  create mode 100755 board/altera/stratix10-socdk/Makefile
> >  create mode 100755 board/altera/stratix10-socdk/socfpga.c
> > 
> > diff --git a/board/altera/stratix10-socdk/MAINTAINERS
> > b/board/altera/stratix10-socdk/MAINTAINERS
> > new file mode 100755
> 
> 644?

Will chmod 

> 
> > index 000..596933c
> > --- /dev/null
> > +++ b/board/altera/stratix10-socdk/MAINTAINERS
> > @@ -0,0 +1,7 @@
> > +SOCFPGA BOARD
> > +M: Chin-Liang See 
> > +M: Dinh Nguyen 
> > +S: Maintained
> > +F: board/altera/stratix10-socdk/
> > +F: include/configs/socfpga_stratix10_socdk.h
> > +F: configs/socfpga_stratix10_defconfig
> > diff --git a/board/altera/stratix10-socdk/Makefile
> > b/board/altera/stratix10-socdk/Makefile
> > new file mode 100755
> 
> 644?
> 

Will chmod too

Thanks
Chin Liang

> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 11/11] arm: socfpga: Add support for Stratix 10 SoC dev kit

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 09:32 -0500, Dinh Nguyen wrote:
> 
> On 09/06/2016 05:03 AM, Chin Liang See wrote:
> > Add support for Stratix 10 SoC development kit
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > ---
> > Changes for v2
> > - Sorting the config alphabetically
> > ---
> 
> Please re-check all of your new file attributes for this series.
> 

Yup, definitely :)

Thanks
Chin Liang

> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 10/11] arm: dts: socfpga: Add dts for Stratix 10 socdk

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 09:14 -0500, Dinh Nguyen wrote:
> 
> On 09/06/2016 05:03 AM, Chin Liang See wrote:
> > Add device tree for Stratix 10 SoC development kit
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > Acked-by: Marek Vasut 
> > ---
> >  arch/arm/dts/Makefile|  3 +-
> >  arch/arm/dts/socfpga_stratix10_socdk.dts | 63
> > 
> >  2 files changed, 65 insertions(+), 1 deletion(-)
> >  create mode 100755 arch/arm/dts/socfpga_stratix10_socdk.dts
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 223124e..c5e2d3c 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -127,7 +127,8 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
> > \
> > socfpga_cyclone5_sockit.dtb \
> > socfpga_cyclone5_socrates.dtb   \
> > socfpga_cyclone5_sr1500.dtb \
> > -   socfpga_cyclone5_vining_fpga.dtb
> > +   socfpga_cyclone5_vining_fpga.dtb\
> > +   socfpga_stratix10_socdk.dtb
> >  
> >  dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb
> >  dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
> > diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
> > b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > new file mode 100755
> > index 000..7465358
> > --- /dev/null
> > +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > @@ -0,0 +1,63 @@
> > +/*
> > + *  Copyright (C) 2016 Intel Corporation
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +/dts-v1/;
> > +/* First 4KB has trampoline code for secondary cores. */
> > +/memreserve/ 0x 0x0001000;
> 
> ARM64 should be using PSCI for SMP. I don't think the trampoline code
> is
> needed.
> 

You are right and will remove this

> > +#include "skeleton.dtsi"
> > +
> > +/ {
> > +   model = "Altera SOCFPGA Stratix 10 SoC Development Kit";
> > +   compatible = "altr,socfpga-stratix10", "altr,socfpga";
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   chosen {
> > +   bootargs = "console=ttyS0,115200";
> > +   };
> > +
> > +   memory {
> > +   name = "memory";
> > +   device_type = "memory";
> > +   reg = <0x0 0x4000>; /* 1GB */
> > +   };
> 
> are you sure we still have only 1GB?
> 

Good catch as SOCVP has 2GB. But we should have more than 2GB per spec
and will investigate more.

> > +
> > +   regulator_3_3v: 3-3-v-regulator {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "3.3V";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   };
> > +
> > +   soc {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "simple-bus";
> > +   device_type = "soc";
> > +   ranges;
> > +
> > +   mmc0: dwmmc0@0xff808000 {
> > +   compatible = "altr,socfpga-dw-mshc";
> > +   reg = <0xff808000 0x1000>;
> > +   interrupts = <0 139 4>;
> 
> This interrupt number is not correct. Copy/paste error from Cyclone5?
> For S10, I think it's 96.
> 

Yup, my bad as overlook this when enabling the SDMMC. Will fix this.

Thanks
Chin Liang

> > +   num-slots = <1>;
> > +   broken-cd;
> > +   bus-width = <4>;
> > +   fifo-depth = <0x400>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   cap-mmc-highspeed;
> > +   cap-sd-highspeed;
> > +   drvsel = <3>;
> > +   smplsel = <0>;
> > +   status = "okay";
> > +   u-boot,dm-pre-reloc;
> > +   vmmc-supply = <_3_3v>;
> > +   vqmmc-supply = <_3_3v>;
> > +   };
> > +   };
> > +};
> > 
> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 07/11] arm: socfpga: sysmgr: Fix casting warning when enabling ARM64

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 14:12 +0200, Marek Vasut wrote:
> On 09/06/2016 11:41 AM, Chin Liang See wrote:
> > On Mon, 2016-09-05 at 18:02 +0200, Marek Vasut wrote:
> > > On 08/22/2016 05:02 PM, Chin Liang See wrote:
> > > > Fix casting warning to pointer from integer of different size
> > > > when enabling ARM64 support
> > > 
> > > What sort of error did you observe ?
> > 
> > The warning is triggered as ARM64 has build flag -Wpointer-to-int
> > -cast
> > and similar. Here is the build error log
> > 
> > arch/arm/mach-socfpga/system_manager.c: In function
> > sysmgr_pinmux_init:
> >
> > 
> >   arch/arm/mach-socfpga/system_manager.c:59:18: warning:
> > cast
> > from pointer to integer of different size [-Wpointer-to-int-cast]  
> > 
> >   uint32_t regs = (uint32_t)_regs
> > ->emacio[0];   
> > 
> >   ^
> > 
> >
> > 
> >   In file
> > included from arch/arm/mach-socfpga/system_manager.c:8:0:  
> > 
> >
> > 
> >   ./arch/arm/include/asm/io.h:78:29: warning: cast to pointer
> > from
> > integer of different size [-Wint-to-pointer-cast]  
> > 
> > #define __arch_putl(v,a)  (*(volatile unsigned
> > int
> > *)(a) = (v))   
> > 
> 
> I see ... Except the code below does regs += sizeof(regs); , which in
> the original case increments the address by 4 , but with your change,
> the increment would be 16 . So this patch breaks things.
> 

Relook back, this portion is not being used and hence not being
validated. Will put #ifdef in place to skip out these code.

Thanks
Chin Liang


> btw it's not worth reposting patches while there is still ongoing
> discussion.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 06/11] arm: socfpga: misc: Segregate the misc.c for Stratix 10

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 14:09 +0200, Marek Vasut wrote:
> On 09/06/2016 08:19 AM, Chin Liang See wrote:
> > On Mon, 2016-09-05 at 18:01 +0200, Marek Vasut wrote:
> > > On 08/22/2016 05:02 PM, Chin Liang See wrote:
> > > > Segregate the misc.c to support both GEN5 SoC and Stratix 10
> > > > SoC.
> > > > 
> > > > Signed-off-by: Chin Liang See 
> > > > Cc: Marek Vasut 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Ley Foon Tan 
> > > > ---
> > > >  arch/arm/mach-socfpga/misc.c | 12 
> > > >  1 file changed, 12 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach
> > > > -socfpga/misc.c
> > > > index 5cbd8a4..295121f 100644
> > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > @@ -24,6 +24,8 @@
> > > >  
> > > >  DECLARE_GLOBAL_DATA_PTR;
> > > >  
> > > > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > > > +
> > > >  static struct pl310_regs *const pl310 =
> > > > (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> > > >  static struct socfpga_system_manager *sysmgr_regs =
> > > > @@ -34,6 +36,7 @@ static struct nic301_registers *nic301_regs =
> > > > (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
> > > >  static struct scu_registers *scu_regs =
> > > > (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
> > > > +#endif
> > > >  
> > > >  int dram_init(void)
> > > >  {
> > > > @@ -41,6 +44,7 @@ int dram_init(void)
> > > > return 0;
> > > >  }
> > > >  
> > > > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > > >  void enable_caches(void)
> > > >  {
> > > >  #ifndef CONFIG_SYS_ICACHE_OFF
> > > > @@ -246,6 +250,7 @@ static int socfpga_fpga_id(const bool
> > > > print_id)
> > > >socfpga_fpga_model[i].name, version);
> > > > return i;
> > > >  }
> > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > >  
> > > >  /*
> > > >   * Print CPU information
> > > > @@ -253,14 +258,20 @@ static int socfpga_fpga_id(const bool
> > > > print_id)
> > > >  #if defined(CONFIG_DISPLAY_CPUINFO)
> > > >  int print_cpuinfo(void)
> > > >  {
> > > > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > > > const u32 bsel = readl(_regs->bootinfo) & 0x7;
> > > > puts("CPU:   Altera SoCFPGA Platform\n");
> > > > socfpga_fpga_id(1);
> > > > printf("BOOT:  %s\n", bsel_str[bsel].name);
> > > > +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > > > +   puts("CPU:   Altera SoCFPGA Platform\n");
> > > > +   puts("FPGA:  Altera Stratix 10\n");
> > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > 
> > > Can't you decode the boot mode and FPGA type instead ?
> > 
> > That is a good question. This is now not available in SOC Virtual
> > Platform. But will definitely enhance this in later stage with
> > hardware
> > available.
> 
> What do you mean not available ? Does the VT not emulate the SoC
> precisely ?
> 

The VT doesn't emulate the Secure Device Manager (SDM) part as its
focusing on ARM64 for this phase.

Thanks
Chin Liang

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


Re: [U-Boot] [PATCH 04/11] arm: socfpga: clkmgr: Segregate the Clock Manager for Stratix 10

2016-09-07 Thread Chin Liang See
On Tue, 2016-09-06 at 14:08 +0200, Marek Vasut wrote:
> On 09/06/2016 07:14 AM, Chin Liang See wrote:
> > On Mon, 2016-09-05 at 17:58 +0200, Marek Vasut wrote:
> > > On 08/22/2016 05:02 PM, Chin Liang See wrote:
> > > > Segregate the Clock Manager to support both GEN5 SoC and
> > > > Stratix 10 SoC.
> > > > 
> > > > Signed-off-by: Chin Liang See 
> > > > Cc: Marek Vasut 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Ley Foon Tan 
> > > > ---
> > > >  arch/arm/mach-socfpga/clock_manager.c | 8 
> > > >  1 file changed, 8 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/clock_manager.c
> > > > b/arch/arm/mach
> > > > -socfpga/clock_manager.c
> > > > index aa71636..0d67b3c 100644
> > > > --- a/arch/arm/mach-socfpga/clock_manager.c
> > > > +++ b/arch/arm/mach-socfpga/clock_manager.c
> > > > @@ -10,6 +10,7 @@
> > > >  
> > > >  DECLARE_GLOBAL_DATA_PTR;
> > > >  
> > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > >  static const struct socfpga_clock_manager *clock_manager_base
> > > > =
> > > > (struct socfpga_clock_manager
> > > > *)SOCFPGA_CLKMGR_ADDRESS;
> > > >  
> > > > @@ -446,9 +447,11 @@ unsigned int cm_get_l4_sp_clk_hz(void)
> > > >  
> > > > return clock;
> > > >  }
> > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > >  
> > > >  unsigned int cm_get_mmc_controller_clk_hz(void)
> > > >  {
> > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > > uint32_t reg, clock = 0;
> > > >  
> > > > /* identify the source of MMC clock */
> > > > @@ -475,8 +478,12 @@ unsigned int
> > > > cm_get_mmc_controller_clk_hz(void)
> > > > /* further divide by 4 as we have fixed divider at
> > > > wrapper
> > > > */
> > > > clock /= 4;
> > > > return clock;
> > > > +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > > > +   return 2500;
> > > > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > > >  }
> > > >  
> > > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> > > >  unsigned int cm_get_qspi_controller_clk_hz(void)
> > > 
> > > Are you sure this won't cause build breakage ? I believe this is
> > > still
> > > used by the cadence qspi driver.
> > 
> > That is a good question. As for SOC Virtual Platform, we are not
> > enabling the QSPI controller.
> 
> When stratix 10 ships, this will be left broken then ?
> 

Definitely not as we will enable and validate this against emulation in
coming weeks.

Thanks
Chin Liang

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


[U-Boot] [PATCH 2/3] fastboot: add support for writing MBR

2016-09-07 Thread Petr Kulhavy
Add special target "mbr" (otherwise configurable via CONFIG_FASTBOOT_MBR_NAME)
to write MBR partition table.
Partitions are now searched using the generic function which finds any
partiiton by name. For MBR the partition names hda1, sda1, etc. are used.

Signed-off-by: Petr Kulhavy 
---
 README  |  7 +++
 common/fb_mmc.c | 40 ++--
 disk/part_dos.c | 20 
 doc/README.android-fastboot | 37 +
 include/part.h  | 23 +++
 5 files changed, 121 insertions(+), 6 deletions(-)

diff --git a/README b/README
index 30d7ee3..f6ef8b8 100644
--- a/README
+++ b/README
@@ -1682,6 +1682,13 @@ The following options need to be configured:
"fastboot flash" command line matches this value.
Default is GPT_ENTRY_NAME (currently "gpt") if undefined.
 
+   CONFIG_FASTBOOT_MBR_NAME
+   The fastboot "flash" command supports writing the downloaded
+   image to DOS MBR.
+   This occurs when the "partition name" specified on the
+   "fastboot flash" command line matches this value.
+   If not defined the default value "mbr" is used.
+
 - Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF, 
CONFIG_JFFS2_NAND_SIZE,
CONFIG_JFFS2_NAND_DEV
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index a0a4a83..4bc68a7 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -14,15 +14,20 @@
 #include 
 #include 
 
-#ifndef CONFIG_FASTBOOT_GPT_NAME
+#if defined(CONFIG_EFI_PARTITION) && !defined(CONFIG_FASTBOOT_GPT_NAME)
 #define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
 #endif
 
+
+#if defined(CONFIG_DOS_PARTITION) && !defined(CONFIG_FASTBOOT_MBR_NAME)
+#define CONFIG_FASTBOOT_MBR_NAME "mbr"
+#endif
+
 struct fb_mmc_sparse {
struct blk_desc *dev_desc;
 };
 
-static int part_get_info_efi_by_name_or_alias(struct blk_desc *dev_desc,
+static int part_get_info_by_name_or_alias(struct blk_desc *dev_desc,
const char *name, disk_partition_t *info)
 {
int ret;
@@ -103,6 +108,7 @@ void fb_mmc_flash_write(const char *cmd, void 
*download_buffer,
return;
}
 
+#ifdef CONFIG_EFI_PARTITION
if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
printf("%s: updating MBR, Primary and Backup GPT(s)\n",
   __func__);
@@ -114,14 +120,36 @@ void fb_mmc_flash_write(const char *cmd, void 
*download_buffer,
}
if (write_mbr_and_gpt_partitions(dev_desc, download_buffer)) {
printf("%s: writing GPT partitions failed\n", __func__);
-   fastboot_fail(
- "writing GPT partitions failed");
+   fastboot_fail("writing GPT partitions failed");
return;
}
printf(" success\n");
fastboot_okay("");
return;
-   } else if (part_get_info_efi_by_name_or_alias(dev_desc, cmd, )) {
+   }
+#endif
+
+#ifdef CONFIG_DOS_PARTITION
+   if (strcmp(cmd, CONFIG_FASTBOOT_MBR_NAME) == 0) {
+   printf("%s: updating MBR\n", __func__);
+   if (is_valid_dos_buf(download_buffer)) {
+   printf("%s: invalid MBR - refusing to write to flash\n",
+  __func__);
+   fastboot_fail("invalid MBR partition");
+   return;
+   }
+   if (write_mbr_partition(dev_desc, download_buffer)) {
+   printf("%s: writing MBR partition failed\n", __func__);
+   fastboot_fail("writing MBR partition failed");
+   return;
+   }
+   printf(" success\n");
+   fastboot_okay("");
+   return;
+   }
+#endif
+
+   if (part_get_info_by_name_or_alias(dev_desc, cmd, )) {
error("cannot find partition: '%s'\n", cmd);
fastboot_fail("cannot find partition");
return;
@@ -172,7 +200,7 @@ void fb_mmc_erase(const char *cmd)
return;
}
 
-   ret = part_get_info_efi_by_name_or_alias(dev_desc, cmd, );
+   ret = part_get_info_by_name_or_alias(dev_desc, cmd, );
if (ret) {
error("cannot find partition: '%s'", cmd);
fastboot_fail("cannot find partition");
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 8226601..8e6aae5 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -297,6 +297,26 @@ int part_get_info_dos(struct blk_desc *dev_desc, int part,
return part_get_info_extended(dev_desc, 0, 0, 1, part, info, 0);
 }
 
+int is_valid_dos_buf(void *buf)
+{
+   return test_block_type(buf) == DOS_MBR ? 0 : -1;
+}
+
+int 

[U-Boot] [PATCH 0/3] Fastboot MBR and generic partition support

2016-09-07 Thread Petr Kulhavy
This set extends the Fastboot implementation from GPT-only to any partition
support.  Further it adds a special target "mbr" (configurable) to write the
DOS MBR.

Petr Kulhavy (3):
  disk: part: implement generic function part_get_info_by_name()
  fastboot: add support for writing MBR
  disk: part: refactor generic name creation for DOS and ISO

 README  |  7 +
 common/fb_mmc.c | 44 +++--
 disk/part.c | 58 +
 disk/part_amiga.c   |  1 +
 disk/part_dos.c | 52 +++---
 disk/part_efi.c | 20 +
 disk/part_iso.c | 26 ++---
 disk/part_mac.c |  1 +
 doc/README.android-fastboot | 38 +
 include/part.h  | 69 +
 10 files changed, 224 insertions(+), 92 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH 3/3] disk: part: refactor generic name creation for DOS and ISO

2016-09-07 Thread Petr Kulhavy
In both DOS and ISO partition tables the same code to create partition name
like "hda1" was repeated.

Code moved to into a new function part_set_generic_name() in part.c and 
optimized.
Added recognition of MMC and SD types, name is like "mmcsda1".

Signed-off-by: Petr Kulhavy 
---
 disk/part.c | 32 
 disk/part_dos.c | 31 ++-
 disk/part_iso.c | 25 +
 doc/README.android-fastboot |  1 +
 include/part.h  | 14 ++
 5 files changed, 50 insertions(+), 53 deletions(-)

diff --git a/disk/part.c b/disk/part.c
index 8317e80..9f51a07 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -641,3 +641,35 @@ int part_get_info_by_name(struct blk_desc *dev_desc, const 
char *name,
}
return -1;
 }
+
+void part_set_generic_name(const struct blk_desc *dev_desc,
+   int part_num, char *name)
+{
+   char *devtype;
+
+   switch (dev_desc->if_type) {
+   case IF_TYPE_IDE:
+   case IF_TYPE_SATA:
+   case IF_TYPE_ATAPI:
+   devtype = "hd";
+   break;
+   case IF_TYPE_SCSI:
+   devtype = "sd";
+   break;
+   case IF_TYPE_USB:
+   devtype = "usbd";
+   break;
+   case IF_TYPE_DOC:
+   devtype = "docd";
+   break;
+   case IF_TYPE_MMC:
+   case IF_TYPE_SD:
+   devtype = "mmcsd";
+   break;
+   default:
+   devtype = "xx";
+   break;
+   }
+
+   sprintf(name, "%s%c%d", devtype, 'a' + dev_desc->devnum, part_num);
+}
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 8e6aae5..ed78334 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -209,35 +209,8 @@ static int part_get_info_extended(struct blk_desc 
*dev_desc,
info->start = (lbaint_t)(ext_part_sector +
le32_to_int(pt->start4));
info->size  = (lbaint_t)le32_to_int(pt->size4);
-   switch(dev_desc->if_type) {
-   case IF_TYPE_IDE:
-   case IF_TYPE_SATA:
-   case IF_TYPE_ATAPI:
-   sprintf((char *)info->name, "hd%c%d",
-   'a' + dev_desc->devnum,
-   part_num);
-   break;
-   case IF_TYPE_SCSI:
-   sprintf((char *)info->name, "sd%c%d",
-   'a' + dev_desc->devnum,
-   part_num);
-   break;
-   case IF_TYPE_USB:
-   sprintf((char *)info->name, "usbd%c%d",
-   'a' + dev_desc->devnum,
-   part_num);
-   break;
-   case IF_TYPE_DOC:
-   sprintf((char *)info->name, "docd%c%d",
-   'a' + dev_desc->devnum,
-   part_num);
-   break;
-   default:
-   sprintf((char *)info->name, "xx%c%d",
-   'a' + dev_desc->devnum,
-   part_num);
-   break;
-   }
+   part_set_generic_name(dev_desc, part_num,
+ (char *)info->name);
/* sprintf(info->type, "%d, pt->sys_ind); */
strcpy((char *)info->type, "U-Boot");
info->bootable = is_bootable(pt);
diff --git a/disk/part_iso.c b/disk/part_iso.c
index 78fc97e..bb8ed65 100644
--- a/disk/part_iso.c
+++ b/disk/part_iso.c
@@ -137,30 +137,7 @@ int part_get_info_iso_verb(struct blk_desc *dev_desc, int 
part_num,
entry_num=1;
offset=0x20;
strcpy((char *)info->type, "U-Boot");
-   switch(dev_desc->if_type) {
-   case IF_TYPE_IDE:
-   case IF_TYPE_SATA:
-   case IF_TYPE_ATAPI:
-   sprintf ((char *)info->name, "hd%c%d",
-   'a' + dev_desc->devnum, part_num);
-   break;
-   case IF_TYPE_SCSI:
-   sprintf ((char *)info->name, "sd%c%d",
-   'a' + dev_desc->devnum, part_num);
-   break;
-   case IF_TYPE_USB:
-   sprintf ((char 

[U-Boot] [PATCH 1/3] disk: part: implement generic function part_get_info_by_name()

2016-09-07 Thread Petr Kulhavy
So far partition search by name has been supported only on the EFI partition
table. This patch extends the search to all partition tables.

Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from
part_efi.c into part.c and make it a generic function which traverses all part
drivers and searches all partitions (in the order given by the linked list).

For this a new variable struct part_driver.max_entries is added, which limits
the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS.
Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables.

Signed-off-by: Petr Kulhavy 
---
 common/fb_mmc.c   |  4 ++--
 disk/part.c   | 26 ++
 disk/part_amiga.c |  1 +
 disk/part_dos.c   |  1 +
 disk/part_efi.c   | 20 +---
 disk/part_iso.c   |  1 +
 disk/part_mac.c   |  1 +
 include/part.h| 32 
 8 files changed, 53 insertions(+), 33 deletions(-)

diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 8d0524d..a0a4a83 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -27,7 +27,7 @@ static int part_get_info_efi_by_name_or_alias(struct blk_desc 
*dev_desc,
 {
int ret;
 
-   ret = part_get_info_efi_by_name(dev_desc, name, info);
+   ret = part_get_info_by_name(dev_desc, name, info);
if (ret) {
/* strlen("fastboot_partition_alias_") + 32(part_name) + 1 */
char env_alias_name[25 + 32 + 1];
@@ -38,7 +38,7 @@ static int part_get_info_efi_by_name_or_alias(struct blk_desc 
*dev_desc,
strncat(env_alias_name, name, 32);
aliased_part_name = getenv(env_alias_name);
if (aliased_part_name != NULL)
-   ret = part_get_info_efi_by_name(dev_desc,
+   ret = part_get_info_by_name(dev_desc,
aliased_part_name, info);
}
return ret;
diff --git a/disk/part.c b/disk/part.c
index 6a1c02d..8317e80 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -615,3 +615,29 @@ cleanup:
free(dup_str);
return ret;
 }
+
+int part_get_info_by_name(struct blk_desc *dev_desc, const char *name,
+   disk_partition_t *info)
+{
+   struct part_driver *first_drv =
+   ll_entry_start(struct part_driver, part_driver);
+   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
+   struct part_driver *part_drv;
+
+   for (part_drv = first_drv; part_drv != first_drv + n_drvs; part_drv++) {
+   int ret;
+   int i;
+   for (i = 1; i < part_drv->max_entries; i++) {
+   ret = part_drv->get_info(dev_desc, i, info);
+   if (ret != 0) {
+   /* no more entries in table */
+   break;
+   }
+   if (strcmp(name, (const char *)info->name) == 0) {
+   /* matched */
+   return 0;
+   }
+   }
+   }
+   return -1;
+}
diff --git a/disk/part_amiga.c b/disk/part_amiga.c
index d4316b8..25fe56c 100644
--- a/disk/part_amiga.c
+++ b/disk/part_amiga.c
@@ -381,6 +381,7 @@ static void part_print_amiga(struct blk_desc *dev_desc)
 U_BOOT_PART_TYPE(amiga) = {
.name   = "AMIGA",
.part_type  = PART_TYPE_AMIGA,
+   .max_entries= AMIGA_ENTRY_NUMBERS,
.get_info   = part_get_info_amiga,
.print  = part_print_amiga,
.test   = part_test_amiga,
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 511917a..8226601 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -300,6 +300,7 @@ int part_get_info_dos(struct blk_desc *dev_desc, int part,
 U_BOOT_PART_TYPE(dos) = {
.name   = "DOS",
.part_type  = PART_TYPE_DOS,
+   .max_entries= DOS_ENTRY_NUMBERS,
.get_info   = part_get_info_ptr(part_get_info_dos),
.print  = part_print_ptr(part_print_dos),
.test   = part_test_dos,
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 8d67c09..1924338 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -296,25 +296,6 @@ int part_get_info_efi(struct blk_desc *dev_desc, int part,
return 0;
 }
 
-int part_get_info_efi_by_name(struct blk_desc *dev_desc,
-   const char *name, disk_partition_t *info)
-{
-   int ret;
-   int i;
-   for (i = 1; i < GPT_ENTRY_NUMBERS; i++) {
-   ret = part_get_info_efi(dev_desc, i, info);
-   if (ret != 0) {
-   /* no more entries in table */
-   return -1;
-   }
-   if (strcmp(name, (const char *)info->name) == 0) {
-   /* matched */
-   return 0;
-   }
-   }
-   return -2;
-}
-
 static int part_test_efi(struct blk_desc 

  1   2   >