[U-Boot] [PATCH v2] arm: cache: always flush cache line size for page table

[Stefan Agner]

From: Stefan Agner 

The page table is maintained by the CPU, hence it is safe to always
align cache flush to a whole cache line size. This allows to use
mmu_page_table_flush for a single page table, e.g. when configure
only small regions through mmu_set_region_dcache_behaviour.

Signed-off-by: Stefan Agner 
---
Changes since v1:
- Move cache line alignment from mmu_page_table_flush to
  mmu_set_region_dcache_behaviour

 arch/arm/lib/cache-cp15.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 1121dc3..bf79edd 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -62,6 +62,7 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
 enum dcache_option option)
 {
u32 *page_table = (u32 *)gd->arch.tlb_addr;
+   phys_addr_t startpt, stoppt;
unsigned long upto, end;
 
end = ALIGN(start + size, MMU_SECTION_SIZE) >> MMU_SECTION_SHIFT;
@@ -70,7 +71,17 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
  option);
for (upto = start; upto < end; upto++)
set_section_dcache(upto, option);
-   mmu_page_table_flush((u32)_table[start], (u32)_table[end]);
+
+   /*
+* Make sure range is cache line aligned
+* Only CPU maintains page tables, hence it is save to always
+* flush complete cache lines...
+*/
+   startpt = (phys_addr_t)_table[start];
+   startpt &= ~(CONFIG_SYS_CACHELINE_SIZE - 1);
+   stoppt = (phys_addr_t)_table[end];
+   stoppt = ALIGN(stoppt, CONFIG_SYS_CACHELINE_SIZE);
+   mmu_page_table_flush(startpt, stoppt);
 }
 
 __weak void dram_bank_mmu_setup(int bank)
-- 
2.9.0

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

Re: [U-Boot] A command to discard saved environments?

[Wolfgang Denk]

Dear James,

In message  you wrote:
> 
> > In your case, you could save the "erase" by overwriting the first 4
> > bytes (where the CRC32 checksum is stored) with 0x.

Wrong.  I meant writing 0x - as you can always write that,
setting any remaining 1 bits to 0 which does not require an erase of
the sector.

> In the case of my NOR flash storage, telling erase to do one byte 
> actually causes the erasure of an entire flash sector, which we've 
> reserved for the NV environment.  You are of course correct that 
> overwriting the CRC will have the same operational effect.

...and as the next "saveenv" will start with an erase, writing 0 to
the CRC 32 field saves you one erase cycle on that sector.

I know, this is nitpicking. Soryy.

> It's a rare occurrence that we need to do this, we don't use this sort 
> of operation as a normal part of doing business.

Agreed. This should never be part of regular operation.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Microsoft Multitasking:
 several applications can crash at the same time.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Marek Vasut]

On 08/03/2016 05:17 PM, 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 

Applied to the 01-arria10 branch , since this patch is useless in
mainline as-is .

btw do you ever plan to finish the Arria10 support in mainline ?

> ---
>  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
> index 000..411518d
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (C) 2016, Intel Corporation
> + *
> + * SPDX-License-Identifier:  GPL-2.0
> + */
> +
> +#ifndef _SOCFPGA_S10_BASE_HARDWARE_H_
> +#define _SOCFPGA_S10_BASE_HARDWARE_H_
> +
> +#define SOCFPGA_SMMU_ADDRESS 0xfa00
> +#define SOCFPGA_EMAC0_ADDRESS0xff80
> +#define SOCFPGA_EMAC1_ADDRESS0xff802000
> +#define SOCFPGA_EMAC2_ADDRESS0xff804000
> +#define SOCFPGA_SDMMC_ADDRESS0xff808000
> +#define SOCFPGA_USB0_ADDRESS 0xffb0
> +#define SOCFPGA_USB1_ADDRESS 0xffb4
> +#define SOCFPGA_NANDREGS_ADDRESS 0xffb8
> +#define SOCFPGA_NANDDATA_ADDRESS 0xffb9
> +#define SOCFPGA_UART0_ADDRESS0xffc02000
> +#define SOCFPGA_UART1_ADDRESS0xffc02100
> +#define SOCFPGA_I2C0_ADDRESS 0xffc02800
> +#define SOCFPGA_I2C1_ADDRESS 0xffc02900
> +#define SOCFPGA_I2C2_ADDRESS 0xffc02a00
> +#define SOCFPGA_I2C3_ADDRESS 0xffc02b00
> +#define SOCFPGA_I2C4_ADDRESS 0xffc02c00
> +#define SOCFPGA_SPTIMER0_ADDRESS 0xffc03000
> +#define SOCFPGA_SPTIMER1_ADDRESS 0xffc03100
> +#define SOCFPGA_GPIO0_ADDRESS0xffc03200
> +#define SOCFPGA_GPIO1_ADDRESS0xffc03300
> +#define SOCFPGA_SYSTIMER0_ADDRESS0xffd0
> +#define SOCFPGA_SYSTIMER0_ADDRESS0xffd00100
> +#define SOCFPGA_L4WD0_ADDRESS0xffd00200
> +#define SOCFPGA_L4WD0_ADDRESS0xffd00300
> +#define SOCFPGA_L4WD0_ADDRESS0xffd00400
> +#define SOCFPGA_L4WD0_ADDRESS0xffd00500
> +#define SOCFPGA_CLKMGR_ADDRESS   0xffd1
> +#define SOCFPGA_RSTMGR_ADDRESS   0xffd11000
> +#define SOCFPGA_SYSMGR_ADDRESS   0xffd12000
> +#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS  0xffd13000
> +#define SOCFPGA_DMANONSECURE_ADDRESS 0xffda
> +#define SOCFPGA_DMASECURE_ADDRESS0xffda1000
> +#define SOCFPGA_SPIS0_ADDRESS0xffda2000
> +#define SOCFPGA_SPIS1_ADDRESS0xffda3000
> +#define SOCFPGA_SPIM0_ADDRESS0xffda4000
> +#define SOCFPGA_SPIM1_ADDRESS0xffda5000
> +#define SOCFPGA_OCRAM_ADDRESS0xffe0
> +
> +#endif /* _SOCFPGA_S10_BASE_HARDWARE_H_ */
> 


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

[U-Boot] rockchip: SecureBoot Support?

[Gregory Ray]

Hello,

Is SecureBoot from the manufacturers u-boot distribution operational? When
I try to sign the loader using the SBC it complains "Sign loader failed!"

I did a standard make:

CROSS_COMPILE=/Developer/arm-eabi-4.8/bin/arm-eabi- make O=firefly
firefly-rk3288_defconfig all

Then generated the loader binary for SecureBootConsole by trying these
combinations, all failed with same error:

./firefly/tools/mkimage -n rk3288 -T rkimage -d \

  ./firefly/spl/u-boot-spl-nodtb.bin out && \

 cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 > sbc_in.bin


 ./firefly/tools/mkimage -n rk3288 -T rkspi -d \

  ./firefly/spl/u-boot-spl-nodtb.bin out && \

 cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 > sbc_in.bin

I also tried using the boot_merger tool from the manufacturer distribution
using the RK3288.ini with PATH=./firefly/spl/u-boot-spl-nodtb.bin. This
still failed with same error.


If this feature is not yet functional, is it on the roadmap?


Thanks,

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

Re: [U-Boot] [U-Boot, 1/3] mmc: fsl: reset to normal boot mode when eMMC fast boot

[Jaehoon Chung]

Hi Peng,

On 04/26/2016 03:54 PM, Peng Fan wrote:
> When booting in eMMC fast boot, MMC host does not exit from
> boot mode after bootrom loading image. So the first command
> 'CMD0' sent in uboot will pull down the CMD line to low and
> cause errors.
> 
> This patch cleans the MMC boot register in "mmc_init" to put the
> MMC host back to normal mode.

Could you resend the patch-set [1/3 - 3/3] on latest u-boot?
After that, I will check..

Best Regards,
Jaehoon Chung

> 
> Also clear DLL_CTRL delay line settings at USDHC initialization
> to eliminate the pre-settings from boot rom.
> 
> Signed-off-by: Peng Fan 
> Cc: Pantelis Antoniou 
> Cc: York Sun 
> Cc: Stefano Babic 
> ---
>  drivers/mmc/fsl_esdhc.c | 38 +-
>  include/fsl_esdhc.h |  6 ++
>  2 files changed, 35 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 65ecff5..15cd419 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -57,21 +57,27 @@ struct fsl_esdhc {
>   uintfevt;   /* Force event register */
>   uintadmaes; /* ADMA error status register */
>   uintadsaddr;/* ADMA system address register */
> - charreserved2[100]; /* reserved */
> - uintvendorspec; /* Vendor Specific register */
> - charreserved3[56];  /* reserved */
> + charreserved2[4];
> + uintdllctrl;
> + uintdllstat;
> + uintclktunectrlstatus;
> + charreserved3[84];
> + uintvendorspec;
> + uintmmcboot;
> + uintvendorspec2;
> + charreserved4[48];
>   uinthostver;/* Host controller version register */
> - charreserved4[4];   /* reserved */
> - uintdmaerraddr; /* DMA error address register */
>   charreserved5[4];   /* reserved */
> - uintdmaerrattr; /* DMA error attribute register */
> + uintdmaerraddr; /* DMA error address register */
>   charreserved6[4];   /* reserved */
> + uintdmaerrattr; /* DMA error attribute register */
> + charreserved7[4];   /* reserved */
>   uinthostcapblt2;/* Host controller capabilities register 2 */
> - charreserved7[8];   /* reserved */
> + charreserved8[8];   /* reserved */
>   uinttcr;/* Tuning control register */
> - charreserved8[28];  /* reserved */
> + charreserved9[28];  /* reserved */
>   uintsddirctl;   /* SD direction control register */
> - charreserved9[712]; /* reserved */
> + charreserved10[712];/* reserved */
>   uintscr;/* eSDHC control register */
>  };
>  
> @@ -618,6 +624,20 @@ static int esdhc_init(struct mmc *mmc)
>   while ((esdhc_read32(>sysctl) & SYSCTL_RSTA) && --timeout)
>   udelay(1000);
>  
> +#if defined(CONFIG_FSL_USDHC)
> + /* RSTA doesn't reset MMC_BOOT register, so manually reset it */
> + esdhc_write32(>mmcboot, 0x0);
> + /* Reset MIX_CTRL and CLK_TUNE_CTRL_STATUS regs to 0 */
> + esdhc_write32(>mixctrl, 0x0);
> + esdhc_write32(>clktunectrlstatus, 0x0);
> +
> + /* Put VEND_SPEC to default value */
> + esdhc_write32(>vendorspec, VENDORSPEC_INIT);
> +
> + /* Disable DLL_CTRL delay line */
> + esdhc_write32(>dllctrl, 0x0);
> +#endif
> +
>  #ifndef ARCH_MXC
>   /* Enable cache snooping */
>   esdhc_write32(>scr, 0x0040);
> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
> index fa760a5..78c67c8 100644
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc.h
> @@ -35,6 +35,12 @@
>  #define SYSCTL_RSTC  0x0200
>  #define SYSCTL_RSTD  0x0400
>  
> +#define VENDORSPEC_CKEN  0x4000
> +#define VENDORSPEC_PEREN 0x2000
> +#define VENDORSPEC_HCKEN 0x1000
> +#define VENDORSPEC_IPGEN 0x0800
> +#define VENDORSPEC_INIT  0x20007809
> +
>  #define IRQSTAT  0x0002e030
>  #define IRQSTAT_DMAE (0x1000)
>  #define IRQSTAT_AC12E(0x0100)
> 

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

Re: [U-Boot] Question on Enabling hypervisor mode in u-boot

[Keerthy]

On Thursday 04 August 2016 10:51 AM, Alexander Graf wrote:



On 02 Aug 2016, at 12:59, Keerthy  wrote:

Hi Alex,


On Tuesday 02 August 2016 07:24 AM, Keerthy wrote:



On Tuesday 02 August 2016 03:16 AM, Alexander Graf wrote:



On 01 Aug 2016, at 11:07, Keerthy  wrote:

Hi Alexander,

I am trying to enable hypervisor in u-boot for DRA7(A15 based) family
of SoCs which does not have LPAE support yet.

Is it mandatory for LPAE to be enabled before enabling hypervisor for
A15?


HYP mode shares the same page table layout as the LPAE one. I’m
actually surprised you managed to configure an A15 without LPAE. Are
you sure it doesn’t support it?


I meant CONFIG_LPAE not enabled yet in our defconfig. I was trying to
get hyp mode enabled and saw that enabling LPAE config seemed mandatory
as per your commit.


I am referring 
http://liris.cnrs.fr/~mmrissa/lib/exe/fetch.php?media=armv7-a-r-manual.pdf.

Attrm[3:0] bits for DCACHE_WRITEALLOC, DCACHE_WRITEBACK, DCACHE_WRITETHROUGH 
definitions.

DCACHE_WRITEBACK should have 0x3 << 2 to get 11RW for MAIRn.Attrm[3:0] encoding.

Correct me if i am wrong of referring a wrong document.


I’m not quite sure I understand your issue correctly. If you want to run in HYP 
mode, the only page table format available is the “long-descriptor” page table 
format, which is the same as the LPAE page table format. That’s the one that 
also puts the caching modes into MAIR registers instead of the PTEs.

So if you want to enable page tables (which you need to enable in order to 
enable caching), you have to write page tables in the LPAE format if you’re 
running in HYP mode. That’s why the config option is mandatory.

See sections B3.1.3 and B3.3 in the document you linked to:

   "the translation tables for the Non-secure PL2 stage 1 translations, and for the 
Non-secure PL1&0 stage 2 translations, must use the Long-descriptor translation table 
format."


Thanks for the confirmations and pointers. I will go through that part 
of ARM documentation.


Best Regards,
Keerthy





Alex


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

Re: [U-Boot] [PATCH v2] eth: asix88179: Add support for the driver model

[Marek Vasut]

On 08/03/2016 11:51 AM, Alban Bedel wrote:
> Adjust this driver to support driver model for Ethernet.
> 
> Signed-off-by: Alban Bedel 

Applied, thanks

-- 
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] malloc_simple: Add simple malloc free function

[Marek Vasut]

On 08/03/2016 05:22 PM, Chin Liang See wrote:

Hi,

[...]
>>> It's the fat driver which is utilizing the malloc.
>>
>> So fat is allocating stuff without freeing it ? I wonder if we should
>> either fix fat or use full malloc in SPL on A10 . I am not really
>> fond
>> of adding more stuff into simple malloc (to keep it small and 
>> simple).
> 
> Actually fat driver is good where it invoke malloc and free during the
> operation. Just that with existing malloc, there is no free
> implementation and memory keep "push" every time malloc invoked.

And I agree with Simon that we should look into the FAT driver and fix
it. Is that not possible ?

 Your design breaks in the scenario where someone does big malloc
 followed by two small mallocs if I understand it correctly. This
 doesn't scale and is a hack.

>>>
>>> Actually the proposed free is a simple implementation which acts as
>>> stack push and pop with depth of 2. This is to enhance existing
>>> implementation which don't handle the pop. This get worst
>>> especially
>>> dealing with fat driver.
>>
>> Well, how does it handle my example? It doesn't and it fails to help
>> in
>> such case, right ?
> 
> I was thinking what is the correct depth while trying to keep things
> simple. From the FAT access testing with SD and eMMC, depth of 2 works
> well by cutting lot of memory consumption by simple malloc
> implementation. Any thoughts whether should have more flexibility?

You still didn't answer my question -- how will this handle my example
usecase ?

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

Re: [U-Boot] Question on Enabling hypervisor mode in u-boot

[Alexander Graf]

> On 02 Aug 2016, at 12:59, Keerthy  wrote:
> 
> Hi Alex,
> 
> 
> On Tuesday 02 August 2016 07:24 AM, Keerthy wrote:
>> 
>> 
>> On Tuesday 02 August 2016 03:16 AM, Alexander Graf wrote:
>>> 
 On 01 Aug 2016, at 11:07, Keerthy  wrote:
 
 Hi Alexander,
 
 I am trying to enable hypervisor in u-boot for DRA7(A15 based) family
 of SoCs which does not have LPAE support yet.
 
 Is it mandatory for LPAE to be enabled before enabling hypervisor for
 A15?
>>> 
>>> HYP mode shares the same page table layout as the LPAE one. I’m
>>> actually surprised you managed to configure an A15 without LPAE. Are
>>> you sure it doesn’t support it?
>> 
>> I meant CONFIG_LPAE not enabled yet in our defconfig. I was trying to
>> get hyp mode enabled and saw that enabling LPAE config seemed mandatory
>> as per your commit.
> 
> I am referring 
> http://liris.cnrs.fr/~mmrissa/lib/exe/fetch.php?media=armv7-a-r-manual.pdf.
> 
> Attrm[3:0] bits for DCACHE_WRITEALLOC, DCACHE_WRITEBACK, DCACHE_WRITETHROUGH 
> definitions.
> 
> DCACHE_WRITEBACK should have 0x3 << 2 to get 11RW for MAIRn.Attrm[3:0] 
> encoding.
> 
> Correct me if i am wrong of referring a wrong document.

I’m not quite sure I understand your issue correctly. If you want to run in HYP 
mode, the only page table format available is the “long-descriptor” page table 
format, which is the same as the LPAE page table format. That’s the one that 
also puts the caching modes into MAIR registers instead of the PTEs.

So if you want to enable page tables (which you need to enable in order to 
enable caching), you have to write page tables in the LPAE format if you’re 
running in HYP mode. That’s why the config option is mandatory.

See sections B3.1.3 and B3.3 in the document you linked to:

  "the translation tables for the Non-secure PL2 stage 1 translations, and for 
the Non-secure PL1&0 stage 2 translations, must use the Long-descriptor 
translation table format."


Alex

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

Re: [U-Boot] [U-Boot,v3] mmc: add mmc partconf read capability

[Jaehoon Chung]

Hi Angelo,

On 04/15/2016 03:51 AM, Angelo Dureghello wrote:
> This patch allows to read back the EXT_CSD[179] partition_config
> register, just specifying the dev param:
> 
> U-Boot> mmc partconf 0
> EXT_CSD[179], PARTITION_CONFIG register:
> BOOT_ACK: 0
> BOOT_PARTITION_ENABLE: 0
> PARTITION_ACCESS: 0

I don't know this patch's history..
Could you resend the patch on latest u-boot?

This code should be moved from drivers/mmc/mmc.c to drivers/mmc/mmc_boot.c.

Refer to "commit c40704f4b13a19a95aa13965c0f1f6a93b5574c0"
- mmc: Move MMC boot code into its own file

Otherwise, I will drop this patch.

Best Regards,
Jaehoon Chung

> 
> Signed-off-by: Angelo Dureghello 
> ---
> Changes for v2:
> - fixed commit message
> - added white lines in cmd/mmc.c
> - fixed help in cmd/mmc.c
> Changes for v3:
> - fixed command output to a single printf
> - fixed return codes
> - fixed macroes with parenthesis around parameter
> ---
>  cmd/mmc.c | 35 +--
>  drivers/mmc/mmc.c | 31 +++
>  include/mmc.h |  6 ++
>  3 files changed, 66 insertions(+), 6 deletions(-)
> 
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 39ef072..2bc7d42 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -697,6 +697,24 @@ static int do_mmc_boot_resize(cmd_tbl_t *cmdtp, int flag,
>   printf("EMMC RPMB partition Size %d MB\n", rpmbsize);
>   return CMD_RET_SUCCESS;
>  }
> +
> +static int do_mmc_partconf_read(struct mmc *mmc)
> +{
> + int err;
> + u8 ack, part_num, access;
> +
> + err = mmc_get_part_conf(mmc, , _num, );
> + if (err)
> + return CMD_RET_FAILURE;
> +
> + printf("EXT_CSD[179], PARTITION_CONFIG register:\n"
> + "BOOT_ACK: %d\n"
> + "BOOT_PARTITION_ENABLE: %d\n"
> + "PARTITION_ACCESS: %d\n", ack, part_num, access);
> +
> + return CMD_RET_SUCCESS;
> +}
> +
>  static int do_mmc_partconf(cmd_tbl_t *cmdtp, int flag,
>  int argc, char * const argv[])
>  {
> @@ -704,13 +722,10 @@ static int do_mmc_partconf(cmd_tbl_t *cmdtp, int flag,
>   struct mmc *mmc;
>   u8 ack, part_num, access;
>  
> - if (argc != 5)
> + if (argc != 2 && argc != 5)
>   return CMD_RET_USAGE;
>  
>   dev = simple_strtoul(argv[1], NULL, 10);
> - ack = simple_strtoul(argv[2], NULL, 10);
> - part_num = simple_strtoul(argv[3], NULL, 10);
> - access = simple_strtoul(argv[4], NULL, 10);
>  
>   mmc = init_mmc_device(dev, false);
>   if (!mmc)
> @@ -721,9 +736,17 @@ static int do_mmc_partconf(cmd_tbl_t *cmdtp, int flag,
>   return CMD_RET_FAILURE;
>   }
>  
> + if (argc == 2)
> + return do_mmc_partconf_read(mmc);
> +
> + ack = simple_strtoul(argv[2], NULL, 10);
> + part_num = simple_strtoul(argv[3], NULL, 10);
> + access = simple_strtoul(argv[4], NULL, 10);
> +
>   /* acknowledge to be sent during boot operation */
>   return mmc_set_part_conf(mmc, ack, part_num, access);
>  }
> +
>  static int do_mmc_rst_func(cmd_tbl_t *cmdtp, int flag,
>  int argc, char * const argv[])
>  {
> @@ -858,8 +881,8 @@ U_BOOT_CMD(
>   " - Set the BOOT_BUS_WIDTH field of the specified device\n"
>   "mmc bootpart-resize   \n"
>   " - Change sizes of boot and RPMB partitions of specified device\n"
> - "mmc partconf dev boot_ack boot_partition partition_access\n"
> - " - Change the bits of the PARTITION_CONFIG field of the specified 
> device\n"
> + "mmc partconf dev [boot_ack boot_partition partition_access]\n"
> + " - Show or change the bits of the PARTITION_CONFIG field of the 
> specified device\n"
>   "mmc rst-function dev value\n"
>   " - Change the RST_n_FUNCTION field of the specified device\n"
>   "   WARNING: This is a write-once field and 0 / 1 / 2 are the only 
> valid values.\n"
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d3c22ab..e4a0130 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1954,6 +1954,37 @@ int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 
> part_num, u8 access)
>  }
>  
>  /*
> + * Read EXT_CSD[179] which is PARTITION_CONFIG (formerly BOOT_CONFIG)
> + * and returning the extracted fields BOOT_ACK, BOOT_PARTITION_ENABLE and
> + * PARTITION_ACCESS.
> + */
> +int mmc_get_part_conf(struct mmc *mmc, u8 *ack, u8 *part_num, u8 *access)
> +{
> + int err;
> + u8 part_conf;
> +
> + ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> +
> + mmc->erase_grp_size = 1;
> + mmc->part_config = MMCPART_NOAVAILABLE;
> +
> + if (IS_SD(mmc) || (mmc->version < MMC_VERSION_4))
> + return CMD_RET_FAILURE;
> +
> + err = mmc_send_ext_csd(mmc, ext_csd);
> + if (err)
> + return err;
> +
> + part_conf = ext_csd[EXT_CSD_PART_CONF];
> +
> + *ack = EXT_CSD_EXTRACT_BOOT_ACK(part_conf);
> + *part_num = EXT_CSD_EXTRACT_BOOT_PART(part_conf);
> + *access = 

Re: [U-Boot] [PATCH v2] cmd: gpt: fix the wrong size parse for the last partition

[Michael Trimarchi]

Hi

On Aug 4, 2016 05:38, "Kever Yang"  wrote:
>
> Hi Michael,
>
> Do you think this patch is necessary?
>

Yes, I have checked it and fix the regression. Today I will confirm on hot
correctness but I think too

Michael

> Thanks,
> -Kever
>
> On 07/29/2016 11:12 AM, Kever Yang wrote:
>>
>> The calculation of "dev_desc->lba - 34  - 1 - offset" is not correct for
>> size '-', because both fist_usable_lba and last_usable_lba will remain
>> 34 sectors.
>>
>> We can simply use 0 for size '-' because the part_efi module will decode
>> the size and auto extend the size to maximum available size.
>>
>> Signed-off-by: Kever Yang 
>> ---
>>
>> Changes in v2:
>> - fix gpt verify error, do not check the extend partition size
>>
>>   cmd/gpt.c   | 4 ++--
>>   disk/part_efi.c | 4 
>>   2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/cmd/gpt.c b/cmd/gpt.c
>> index 3d9706b..897596a 100644
>> --- a/cmd/gpt.c
>> +++ b/cmd/gpt.c
>> @@ -298,8 +298,8 @@ static int set_gpt_info(struct blk_desc *dev_desc,
>> if (extract_env(val, ))
>> p = val;
>> if ((strcmp(p, "-") == 0)) {
>> -   /* remove first usable lba and last block */
>> -   parts[i].size = dev_desc->lba - 34  - 1 - offset;
>> +   /* Let part efi module to auto extend the size */
>> +   parts[i].size = 0;
>> } else {
>> size_ll = ustrtoull(p, , 0);
>> parts[i].size = lldiv(size_ll, dev_desc->blksz);
>> diff --git a/disk/part_efi.c b/disk/part_efi.c
>> index 0af1e92..4566cab 100644
>> --- a/disk/part_efi.c
>> +++ b/disk/part_efi.c
>> @@ -655,6 +655,10 @@ int gpt_verify_partitions(struct blk_desc *dev_desc,
>>   (unsigned long long)partitions[i].size);
>> if (le64_to_cpu(gpt_part_size) != partitions[i].size) {
>> +   /* We do not check the extend partition size */
>> +   if ((i == parts - 1) && (partitions[i].size ==
0))
>> +   continue;
>> +
>> error("Partition %s size: %llu does not match
%llu!\n",
>>   efi_str, (unsigned long long)gpt_part_size,
>>   (unsigned long long)partitions[i].size);
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-mpc86xx master

[york sun]

Tom,

The following changes since commit ad6a303c578b0087749510d20c1c46ae13f20367:

   Merge git://git.denx.de/u-boot-fsl-qoriq (2016-08-02 20:45:24 -0400)

are available in the git repository at:

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

for you to fetch changes up to e1efe43c710bec8d951c25f163cc8b0c5eb92294:

   powerpc/86xx: Increase boot map size to 256 MiB (2016-08-03 18:02:29 
-0700)


Scott Wood (1):
   powerpc/86xx: Increase boot map size to 256 MiB

  include/configs/MPC8610HPCD.h | 13 +++--
  include/configs/MPC8641HPCN.h |  9 +
  2 files changed, 12 insertions(+), 10 deletions(-)

Thanks.

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

Re: [U-Boot] [RESEND PATCH 2/2] rockchip: add usb mass storage feature support for rk3288

[Simon Glass]

On 3 August 2016 at 20:27, Simon Glass  wrote:
> On 2 August 2016 at 21:55, Ziyuan Xu  wrote:
>> Enable ums feature for rk3288 boards, so that we can mount the mmc
>> device to PC.
>>
>> Signed-off-by: Ziyuan Xu 
>> ---
>>
>>  include/configs/rk3288_common.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/include/configs/rk3288_common.h 
>> b/include/configs/rk3288_common.h
>> index fa37335..d3d4c68 100644
>> --- a/include/configs/rk3288_common.h
>> +++ b/include/configs/rk3288_common.h
>> @@ -96,6 +96,10 @@
>>  #define CONFIG_FASTBOOT_BUF_ADDR   CONFIG_SYS_LOAD_ADDR
>>  #define CONFIG_FASTBOOT_BUF_SIZE   0x0800
>>
>> +/* usb mass storage */
>> +#define CONFIG_USB_FUNCTION_MASS_STORAGE
>> +#define CONFIG_CMD_USB_MASS_STORAGE
>> +
>>  #define CONFIG_USB_GADGET_DOWNLOAD
>>  #define CONFIG_G_DNL_MANUFACTURER  "Rockchip"
>>  #define CONFIG_G_DNL_VENDOR_NUM0x2207
>> --
>> 2.9.2
>>
>>
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mmc: sdhci: remove the unused argument for sdhci_setup_cfg

[Simon Glass]

Hi Jaehoon,

On 3 August 2016 at 20:43, Jaehoon Chung  wrote:
> On 08/04/2016 11:40 AM, Simon Glass wrote:
>> Hi Jaehoon,
>>
>> On 3 August 2016 at 20:38, Jaehoon Chung  wrote:
>>> Hi Simon,
>>>
>>> On 08/04/2016 11:35 AM, Simon Glass wrote:
 Hi Jaehoon,

 On 31 July 2016 at 20:20, Simon Glass  wrote:
> On 26 July 2016 at 04:06, Jaehoon Chung  wrote:
>> buswidth isn't used anywhere in sdhci_setup_cfg.
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/msm_sdhci.c  | 4 ++--
>>  drivers/mmc/sdhci.c  | 4 ++--
>>  drivers/mmc/zynq_sdhci.c | 2 +-
>>  include/sdhci.h  | 3 +--
>>  4 files changed, 6 insertions(+), 7 deletions(-)
>
> Reviewed-by: Simon Glass 

 Are you going to pick this up? I suggest that it goes in now since it
 will affect people porting drivers.
>>>
>>> I think it's related with DM side. So if you can pick this, I'm ok.
>>> Otherwise, i will apply on u-boot-mmc, today..And tomorrow i will request 
>>> pull.
>>
>> Yes it is DM-related, but if you don't mind I think it would be good
>> for you to pick these up.
>
> Ok, I will do. And tomorrow, I will request pull to Tom for u-boot-mmc with 
> other mmc patches.
> How about?

Sounds good thank you.

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

Re: [U-Boot] [RESEND PATCH 1/2] rockchip: add basic partitions support for rk3288

[Simon Glass]

On 3 August 2016 at 20:27, Simon Glass  wrote:
> On 2 August 2016 at 21:55, Ziyuan Xu  wrote:
>> For compatibility with distro boot, fastboot, and mount the mmc deivce
>> to PC via usb mass storage feature, GPT partitions are essential.
>>
>> You should write the partitions to mmc device prior to use above
>> feature.
>>
>> => gpt write mmc 1 $partitions
>> GPT successfully written to block device!
>> success!
>>
>> Signed-off-by: Ziyuan Xu 
>> ---
>>
>>  include/configs/rk3288_common.h | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/include/configs/rk3288_common.h 
>> b/include/configs/rk3288_common.h
>> index 814116c..fa37335 100644
>> --- a/include/configs/rk3288_common.h
>> +++ b/include/configs/rk3288_common.h
>> @@ -113,6 +113,12 @@
>> "kernel_addr_r=0x0200\0" \
>> "ramdisk_addr_r=0x0400\0"
>>
>> +#define CONFIG_RANDOM_UUID
>> +#define PARTS_DEFAULT \
>> +   "uuid_disk=${uuid_gpt_disk};" \
>> +   "name=boot,start=8M,size=64M,bootable,uuid=${uuid_gpt_boot};" \
>> +   "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \
>> +
>>  /* First try to boot from SD (index 0), then eMMC (index 1 */
>>  #define BOOT_TARGET_DEVICES(func) \
>> func(MMC, mmc, 0) \
>> @@ -125,6 +131,7 @@
>>  #define CONFIG_EXTRA_ENV_SETTINGS \
>> "fdt_high=0x1fff\0" \
>> "initrd_high=0x1fff\0" \
>> +   "partitions=" PARTS_DEFAULT \
>> ENV_MEM_LAYOUT_SETTINGS \
>> ROCKCHIP_DEVICE_SETTINGS \
>> BOOTENV
>> --
>> 2.9.2
>>
>>
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rockchip: add support for rk3288 miniarm board

[Simon Glass]

On 31 July 2016 at 18:46, Ziyuan Xu  wrote:
> From: Xu Ziyuan 
>
> Miniarm is a rockchip rk3288 based development board, which has lots of
> interface such as HDMI, USB, micro-SD card, Audio etc.
>
> Signed-off-by: Ziyuan Xu 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2:
> - Sort soemthing in alpha order
>
>  arch/arm/dts/Makefile  |   1 +
>  arch/arm/dts/rk3288-miniarm.dts|  61 +++
>  arch/arm/dts/rk3288-miniarm.dtsi   | 533 
> +
>  arch/arm/mach-rockchip/rk3288/Kconfig  |  14 +-
>  board/rockchip/miniarm_rk3288/Kconfig  |  15 +
>  board/rockchip/miniarm_rk3288/MAINTAINERS  |   6 +
>  board/rockchip/miniarm_rk3288/Makefile |   7 +
>  board/rockchip/miniarm_rk3288/miniarm-rk3288.c |  15 +
>  configs/miniarm-rk3288_defconfig   |  65 +++
>  doc/README.rockchip|   9 +-
>  include/configs/miniarm_rk3288.h   |  26 ++
>  11 files changed, 746 insertions(+), 6 deletions(-)
>  create mode 100644 arch/arm/dts/rk3288-miniarm.dts
>  create mode 100644 arch/arm/dts/rk3288-miniarm.dtsi
>  create mode 100644 board/rockchip/miniarm_rk3288/Kconfig
>  create mode 100644 board/rockchip/miniarm_rk3288/MAINTAINERS
>  create mode 100644 board/rockchip/miniarm_rk3288/Makefile
>  create mode 100644 board/rockchip/miniarm_rk3288/miniarm-rk3288.c
>  create mode 100644 configs/miniarm-rk3288_defconfig
>  create mode 100644 include/configs/miniarm_rk3288.h

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] rk3399: add basic soc driver

[Simon Glass]

On 31 July 2016 at 21:34, Kever Yang  wrote:
> This patch add driver for:
> - clock driver including set_rate for cpu, mmc, vop, I2C.
> - sysreset driver
> - grf syscon driver
>
> Signed-off-by: Kever Yang 
> Acked-by: Simon Glass 
> ---
>
> Changes in v3:
> - use EINVAL instead of -1 for return value.
>
> Changes in v2:
> - include '_SHIFT_' in '_MASK' MACRO
> - fix comment style
> - use DIV_ROUND_UP instead of div_round_up
> - use uclass_get_device_by_driver in rockchip_get_cru
> - implement ofdata_to_platdata for priv->cru init
>
>  arch/arm/include/asm/arch-rockchip/cru_rk3399.h |  93 +++
>  arch/arm/mach-rockchip/rk3399/Makefile  |   2 +
>  arch/arm/mach-rockchip/rk3399/reset_rk3399.c|  45 ++
>  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c   |  20 +
>  drivers/clk/Makefile|   1 +
>  drivers/clk/clk_rk3399.c| 817 
> 
>  6 files changed, 978 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3399.h
>  create mode 100644 arch/arm/mach-rockchip/rk3399/reset_rk3399.c
>  create mode 100644 arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
>  create mode 100644 drivers/clk/clk_rk3399.c

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: rockchip, sdram-channel 0xff fix remaining dts

[Simon Glass]

Hi Ziyuan,

On 31 July 2016 at 20:36, Ziyuan Xu  wrote:
> Hi Simon,
>
>
>
> On 2016年08月01日 10:21, Simon Glass wrote:
>>
>> Hi Ziyuan,
>>
>> On 31 July 2016 at 20:13, Ziyuan Xu  wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>> On 2016年08月01日 09:51, Simon Glass wrote:

 Hi Sandy,

 On 28 July 2016 at 07:49, Sandy Patterson 
 wrote:
>
> Add an extra byte so that this data is not byteswapped.
>
> Signed-off-by: Sandy Patterson 
> ---
>
>arch/arm/dts/rk3288-rock2-square.dts | 2 +-
>arch/arm/dts/rk3288-veyron.dtsi  | 2 +-
>2 files changed, 2 insertions(+), 2 deletions(-)

 Acked-by: Simon Glass 

 Do these board use OF_PLATDATA? I thought not.
>>>
>>> Yes, only firefly-rk3288 board use OF_PLATDATA. But driver get
>>> rk3288_sdram_channel via fdtdec_get_byte_array with the size which is
>>> sizeof(struct rk3288_sdram_channel).
>>> In commit 9ca7e67 rockchip: Update the sdram-channel property to support
>>> of-platdata, you add dummy element in struct rk3288_sdram_channel and
>>> size
>>> was changed to 9.
>>> Without this fix, driver get rk3288_sdram_channel failed.
>>>
>>> Maybe add CONFIG_IS_ENABLED(OF_PLATDATA) for distinction is better, how
>>> about?
>>>
>>> struct rk3288_sdram_channel {
>>>  u8 rank;
>>>  u8 col;
>>>  u8 bk;
>>>  u8 bw;
>>>  u8 dbw;
>>>  u8 row_3_4;
>>>  u8 cs0_row;
>>>  u8 cs1_row;
>>> #if CONFIG_IS_ENABLED(OF_PLATDATA)
>>>  /*
>>>   * For of-platdata, which would otherwise convert this into two
>>>   * byte-swapped integers. With a size of 9 bytes, this struct will
>>>   * appear in of-platdata as a byte array.
>>>   */
>>>  u8 dummy;
>>> #endif
>>> };
>>>
>>>
>> Yes, but I'm happy with either solution. Your one may be a little
>> easier to understand, but if someone switches a board over to
>> OF_PLATDATA then it will be confusing... Please let me know which you
>> prefer.
>
> OF_PLATDATA is used to reduce the size of the SPL, right? In most cases,
> some rk3288 boards use OF_LIBFDT. If OF_PLATDATA is really required, I think
> your comment is very clear.
> I perfer my above opinion? :-)

I'm going to apply this patch, but please feel free to send a patch to
change this over if you wish.

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] move: rockchip: move clock drivers into a subdirectory

[Simon Glass]

On 29 July 2016 at 14:42, Heiko Stuebner  wrote:
> Am Freitag, 29. Juli 2016, 07:51:14 schrieb Simon Glass:
>> On 29 July 2016 at 06:47, Heiko Stuebner  wrote:
>> > With the number of Rockchip clock drivers increasing, don't clutter up
>> > the core drivers/clk directory with them and instead move them out of
>> > the way into a separate subdirectory.
>> >
>> > Suggested-by: Simon Glass 
>> > Signed-off-by: Heiko Stuebner 
>> > ---
>> >
>> >  drivers/clk/Makefile| 3 +--
>> >  drivers/clk/rockchip/Makefile   | 8 
>> >  drivers/clk/{ => rockchip}/clk_rk3036.c | 0
>> >  drivers/clk/{ => rockchip}/clk_rk3288.c | 0
>> >  4 files changed, 9 insertions(+), 2 deletions(-)
>> >  create mode 100644 drivers/clk/rockchip/Makefile
>> >  rename drivers/clk/{ => rockchip}/clk_rk3036.c (100%)
>> >  rename drivers/clk/{ => rockchip}/clk_rk3288.c (100%)
>>
>> Isn't this a v2 patch? Anyway:
>
> it seems I was in a bit of a rush, so yeah, this could also be labeled v2,
> although the only change is the "-M" for git format-patch. When rebasing on
> top of your rockchip-master, no changes were needed
>
>
>> Acked-by: Simon Glass 
>

Fixed up for rk3399 support, and:
Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: add fastboot support for rk3036 board

[Simon Glass]

On 31 July 2016 at 17:28, Simon Glass  wrote:
> On 27 July 2016 at 21:42, Ziyuan Xu  wrote:
>>
>> Enable fastboot feature on rk3036, please refer to doc/README.rockchip
>> for more detailed usage.
>>
>> Signed-off-by: Ziyuan Xu 
>> ---
>>
>>  arch/arm/dts/rk3036-sdk.dts|  2 --
>>  board/rockchip/evb_rk3036/evb_rk3036.c | 46 
>> ++
>>  board/rockchip/kylin_rk3036/kylin_rk3036.c | 46 
>> ++
>>  include/configs/rk3036_common.h| 21 +-
>>  4 files changed, 112 insertions(+), 3 deletions(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/3] clock: rk3399: add support for dwmmc 400K

[Kever Yang]

MMC core will use 400KHz for card initialize first and then switch to
higher frequency like 50MHz, we need to support both 400KHz and about
50MHz for dwmmc controller.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 drivers/clk/clk_rk3399.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk_rk3399.c b/drivers/clk/clk_rk3399.c
index 5d9bce0..802b8a1 100644
--- a/drivers/clk/clk_rk3399.c
+++ b/drivers/clk/clk_rk3399.c
@@ -142,6 +142,7 @@ enum {
CLK_EMMC_PLL_SHIFT  = 8,
CLK_EMMC_PLL_MASK   = 0x7 << CLK_EMMC_PLL_SHIFT,
CLK_EMMC_PLL_SEL_GPLL   = 0x1,
+   CLK_EMMC_PLL_SEL_24M= 0x5,
CLK_EMMC_DIV_CON_SHIFT  = 0,
CLK_EMMC_DIV_CON_MASK   = 0x7f << CLK_EMMC_DIV_CON_SHIFT,
 
@@ -640,9 +641,13 @@ static ulong rk3399_mmc_get_clk(struct rk3399_cru *cru, 
uint clk_id)
default:
return -EINVAL;
}
-   div = (con>>CLK_EMMC_DIV_CON_SHIFT) & CLK_EMMC_DIV_CON_MASK;
+   div = (con & CLK_EMMC_DIV_CON_MASK) >> CLK_EMMC_DIV_CON_SHIFT;
 
-   return DIV_TO_RATE(GPLL_HZ, div);
+   if ((con & CLK_EMMC_PLL_MASK) >> CLK_EMMC_PLL_SHIFT
+   == CLK_EMMC_PLL_SEL_24M)
+   return DIV_TO_RATE(24*1024*1024, div);
+   else
+   return DIV_TO_RATE(GPLL_HZ, div);
 }
 
 static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
@@ -653,14 +658,22 @@ static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
 
switch (clk_id) {
case SCLK_SDMMC:
-   /* Select clk_sdmmc source from GPLL too */
+   /* Select clk_sdmmc source from GPLL by default */
src_clk_div = GPLL_HZ / set_rate;
-   assert(src_clk_div - 1 < 127);
 
-   rk_clrsetreg(>clksel_con[16],
-CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
-CLK_EMMC_PLL_SEL_GPLL << CLK_EMMC_PLL_SHIFT |
-(src_clk_div - 1) << CLK_EMMC_DIV_CON_SHIFT);
+   if (src_clk_div > 127) {
+   /* use 24MHz source for 400KHz clock */
+   src_clk_div = 24*1024*1024 / set_rate;
+   rk_clrsetreg(>clksel_con[16],
+CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
+CLK_EMMC_PLL_SEL_24M << CLK_EMMC_PLL_SHIFT 
|
+(src_clk_div - 1) << 
CLK_EMMC_DIV_CON_SHIFT);
+   } else {
+   rk_clrsetreg(>clksel_con[16],
+CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
+CLK_EMMC_PLL_SEL_GPLL << 
CLK_EMMC_PLL_SHIFT |
+(src_clk_div - 1) << 
CLK_EMMC_DIV_CON_SHIFT);
+   }
break;
case SCLK_EMMC:
/* Select aclk_emmc source from GPLL */
-- 
1.9.1


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

[U-Boot] [PATCH v2 3/3] config: rk3399: enable dwmmc controller

[Kever Yang]

Enable the rockchip dwmmc driver for rk3399 and its evb.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2:
- add commit message

 configs/evb-rk3399_defconfig| 1 +
 include/configs/rk3399_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 0fcde3a..c6b0d4e 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -21,6 +21,7 @@ CONFIG_CLK=y
 CONFIG_FIT=y
 CONFIG_SYSRESET=y
 CONFIG_DM_MMC=y
+CONFIG_ROCKCHIP_DWMMC=y
 CONFIG_ROCKCHIP_SDHCI=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_PINCTRL=y
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index 1ed4641..6875308 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -30,6 +30,7 @@
 /* MMC/SD IP block */
 #define CONFIG_MMC
 #define CONFIG_GENERIC_MMC
+#define CONFIG_DWMMC
 #define CONFIG_SDHCI
 #define CONFIG_BOUNCE_BUFFER
 #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ 2
-- 
1.9.1


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

[U-Boot] [PATCH v2 0/3] rk3399: enable dwmmc controller for sdcard

[Kever Yang]

rk3399 using dwmmc controller for sdcard, let's enable it.
this patch set has been test on rk3399 evb.


Changes in v2:
- add commit message
- move the SCLK_SDMMC and its name to the first place
- add commit message

Kever Yang (3):
  clock: rk3399: add support for dwmmc 400K
  dts: rk3399: enable dwmmc for sdcard
  config: rk3399: enable dwmmc controller

 arch/arm/dts/rk3399-evb.dts |  4 
 arch/arm/dts/rk3399.dtsi|  4 ++--
 configs/evb-rk3399_defconfig|  1 +
 drivers/clk/clk_rk3399.c| 29 +
 include/configs/rk3399_common.h |  1 +
 5 files changed, 29 insertions(+), 10 deletions(-)

-- 
1.9.1


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

[U-Boot] [PATCH v2 2/3] dts: rk3399: enable dwmmc for sdcard

[Kever Yang]

rk3399 sdcard is using dwmmc controller, enable it for sdcard.
SCLK_SDMMC is the clock for controller operation clock, move it
to the first place.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2:
- add commit message
- move the SCLK_SDMMC and its name to the first place

 arch/arm/dts/rk3399-evb.dts | 4 
 arch/arm/dts/rk3399.dtsi| 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index bbcfcd0..e92a492 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -61,6 +61,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
bus-width = <8>;
mmc-hs400-1_8v;
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index fb5af54..a4c6e27 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -172,9 +172,9 @@
reg = <0x0 0xfe32 0x0 0x4000>;
interrupts = ;
clock-freq-min-max = <40 15000>;
-   clocks = < HCLK_SDMMC>, < SCLK_SDMMC>,
+   clocks = < SCLK_SDMMC>, < HCLK_SDMMC>,
 < SCLK_SDMMC_DRV>, < SCLK_SDMMC_SAMPLE>;
-   clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+   clock-names = "ciu", "biu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
status = "disabled";
};
-- 
1.9.1


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

[U-Boot] [PATCH v2] configs: rk3399: add gpt and fs support

[Kever Yang]

To compatible with distro boot, we need to add gpt and fs support,
including gpt table and vfat, ext2, ext4 support.

Signed-off-by: Kever Yang 
Reviewed-by: Simon Glass 
---

Changes in v2:
- remove some re-defined MACRO, comments from Ziyuan Xu

 include/configs/rk3399_common.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index a9c9d29..6875308 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -35,7 +35,11 @@
 #define CONFIG_BOUNCE_BUFFER
 #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ 2
 
+#define CONFIG_SUPPORT_VFAT
+#define CONFIG_FS_FAT
 #define CONFIG_FAT_WRITE
+#define CONFIG_FS_EXT4
+#define CONFIG_CMD_PART
 
 /* RAW SD card / eMMC locations. */
 #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR256
@@ -60,6 +64,14 @@
"kernel_addr_r=0x0200\0" \
"ramdisk_addr_r=0x0400\0"
 
+#define CONFIG_CMD_GPT
+#define CONFIG_RANDOM_UUID
+#define CONFIG_PARTITION_UUIDS
+#define PARTS_DEFAULT \
+   "uuid_disk=${uuid_gpt_disk};" \
+   "name=boot,start=16M,size=32M,bootable;" \
+   "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \
+
 /* First try to boot from SD (index 0), then eMMC (index 1) */
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
@@ -67,6 +79,8 @@
 
 #include 
 #define CONFIG_EXTRA_ENV_SETTINGS \
+   ENV_MEM_LAYOUT_SETTINGS \
+   "partitions=" PARTS_DEFAULT \
BOOTENV
 
 #endif
-- 
1.9.1


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

Re: [U-Boot] [PATCH v2] cmd: gpt: fix the wrong size parse for the last partition

[Kever Yang]

Hi Michael,

Do you think this patch is necessary?

Thanks,
-Kever
On 07/29/2016 11:12 AM, Kever Yang wrote:

The calculation of "dev_desc->lba - 34  - 1 - offset" is not correct for
size '-', because both fist_usable_lba and last_usable_lba will remain
34 sectors.

We can simply use 0 for size '-' because the part_efi module will decode
the size and auto extend the size to maximum available size.

Signed-off-by: Kever Yang 
---

Changes in v2:
- fix gpt verify error, do not check the extend partition size

  cmd/gpt.c   | 4 ++--
  disk/part_efi.c | 4 
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 3d9706b..897596a 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -298,8 +298,8 @@ static int set_gpt_info(struct blk_desc *dev_desc,
if (extract_env(val, ))
p = val;
if ((strcmp(p, "-") == 0)) {
-   /* remove first usable lba and last block */
-   parts[i].size = dev_desc->lba - 34  - 1 - offset;
+   /* Let part efi module to auto extend the size */
+   parts[i].size = 0;
} else {
size_ll = ustrtoull(p, , 0);
parts[i].size = lldiv(size_ll, dev_desc->blksz);
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 0af1e92..4566cab 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -655,6 +655,10 @@ int gpt_verify_partitions(struct blk_desc *dev_desc,
  (unsigned long long)partitions[i].size);
  
  		if (le64_to_cpu(gpt_part_size) != partitions[i].size) {

+   /* We do not check the extend partition size */
+   if ((i == parts - 1) && (partitions[i].size == 0))
+   continue;
+
error("Partition %s size: %llu does not match %llu!\n",
  efi_str, (unsigned long long)gpt_part_size,
  (unsigned long long)partitions[i].size);



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

[U-Boot] [Resend] Please pull u-boot-mpc86xx master

[york sun]

(Resend)

Tom,

The following changes since commit ad6a303c578b0087749510d20c1c46ae13f20367:

Merge git://git.denx.de/u-boot-fsl-qoriq (2016-08-02 20:45:24 -0400)

are available in the git repository at:

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

for you to fetch changes up to e1efe43c710bec8d951c25f163cc8b0c5eb92294:

powerpc/86xx: Increase boot map size to 256 MiB (2016-08-03 18:02:29 
-0700)


Scott Wood (1):
powerpc/86xx: Increase boot map size to 256 MiB

   include/configs/MPC8610HPCD.h | 13 +++--
   include/configs/MPC8641HPCN.h |  9 +
   2 files changed, 12 insertions(+), 10 deletions(-)

Thanks.

York

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

Re: [U-Boot] [PATCH] cmd: net: flush cache cacheline aligned

[Stefan Agner]

On 2016-08-03 16:18, Joe Hershberger wrote:
> On Tue, Aug 2, 2016 at 2:20 AM, Stefan Agner  wrote:
>> From: Stefan Agner 
>>
>> Flush loaded data cacheline aligned. This avoids warnings such as
>> CACHE: Misaligned operation at range [8100, 816d0fa8]
>>
>> Signed-off-by: Stefan Agner 
>> ---
> 
> This was already rejected once.
> http://lists.denx.de/pipermail/u-boot/2012-April/121564.html

Oh I see, and in the end the message was converted to a debug() call, in
essence turning the whole problem back under a stone... :-)

FWIW, I largely support Mike Frysinger's position in that discussion,
and think it should be fine to flush these extra bytes...

> 
>> Why do we actually have to flush caches after load? It seems to
>> have worked so far despite the caches did not get flushed (due to
>> missalignment).

Btw, I need to correct myself here: flush_dcache ultimately calls
v7_dcache_clean_inval_range, which does not bail out in the unaligned
case. Instead, afaict, it flushes until mva < stop, hence flushes the
last line anyway...

> 
> I'm not sure that we do, but it's been there since as far back as the
> git history goes. Maybe Wolfgang has memory of a reason.

The only reason why it might be preferable to have loaded stuff in main
memory is with nowadays heterogeneous architectures (e.g. i.MX 7 with
its secondary M4 core). In those cases we need to flush caches since
those two cores are no cache coherent. However, I don't think that all
load commands are doing the flush, so not sure if can rely on that
today...

--
Stefan

> 
> -Joe
> 
>> --
>> Stefan
>>
>>  cmd/net.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cmd/net.c b/cmd/net.c
>> index b2f3c7b..540daeb 100644
>> --- a/cmd/net.c
>> +++ b/cmd/net.c
>> @@ -244,7 +244,7 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
>> *cmdtp, int argc,
>> }
>>
>> /* flush cache */
>> -   flush_cache(load_addr, size);
>> +   flush_cache(load_addr, ALIGN(size, CONFIG_SYS_CACHELINE_SIZE));
>>
>> bootstage_mark(BOOTSTAGE_ID_NET_LOADED);
>>
>> --
>> 2.9.0
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mmc: sdhci: remove the unused argument for sdhci_setup_cfg

[Jaehoon Chung]

On 08/04/2016 11:40 AM, Simon Glass wrote:
> Hi Jaehoon,
> 
> On 3 August 2016 at 20:38, Jaehoon Chung  wrote:
>> Hi Simon,
>>
>> On 08/04/2016 11:35 AM, Simon Glass wrote:
>>> Hi Jaehoon,
>>>
>>> On 31 July 2016 at 20:20, Simon Glass  wrote:
 On 26 July 2016 at 04:06, Jaehoon Chung  wrote:
> buswidth isn't used anywhere in sdhci_setup_cfg.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/mmc/msm_sdhci.c  | 4 ++--
>  drivers/mmc/sdhci.c  | 4 ++--
>  drivers/mmc/zynq_sdhci.c | 2 +-
>  include/sdhci.h  | 3 +--
>  4 files changed, 6 insertions(+), 7 deletions(-)

 Reviewed-by: Simon Glass 
>>>
>>> Are you going to pick this up? I suggest that it goes in now since it
>>> will affect people porting drivers.
>>
>> I think it's related with DM side. So if you can pick this, I'm ok.
>> Otherwise, i will apply on u-boot-mmc, today..And tomorrow i will request 
>> pull.
> 
> Yes it is DM-related, but if you don't mind I think it would be good
> for you to pick these up.

Ok, I will do. And tomorrow, I will request pull to Tom for u-boot-mmc with 
other mmc patches.
How about? 

Best Regards,
Jaehoon Chung

> 
> Regards,
> Simon
> 
> 
> 

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

Re: [U-Boot] [PATCH 1/2] mmc: sdhci: remove the unused argument for sdhci_setup_cfg

[Simon Glass]

Hi Jaehoon,

On 3 August 2016 at 20:38, Jaehoon Chung  wrote:
> Hi Simon,
>
> On 08/04/2016 11:35 AM, Simon Glass wrote:
>> Hi Jaehoon,
>>
>> On 31 July 2016 at 20:20, Simon Glass  wrote:
>>> On 26 July 2016 at 04:06, Jaehoon Chung  wrote:
 buswidth isn't used anywhere in sdhci_setup_cfg.

 Signed-off-by: Jaehoon Chung 
 ---
  drivers/mmc/msm_sdhci.c  | 4 ++--
  drivers/mmc/sdhci.c  | 4 ++--
  drivers/mmc/zynq_sdhci.c | 2 +-
  include/sdhci.h  | 3 +--
  4 files changed, 6 insertions(+), 7 deletions(-)
>>>
>>> Reviewed-by: Simon Glass 
>>
>> Are you going to pick this up? I suggest that it goes in now since it
>> will affect people porting drivers.
>
> I think it's related with DM side. So if you can pick this, I'm ok.
> Otherwise, i will apply on u-boot-mmc, today..And tomorrow i will request 
> pull.

Yes it is DM-related, but if you don't mind I think it would be good
for you to pick these up.

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

Re: [U-Boot] [PATCH 2/2] mmc: sdhci: remove the unnecessary argumetns for sdhci_setup_cfg

[Jaehoon Chung]

Hi Simon,

On 08/04/2016 11:36 AM, Simon Glass wrote:
> On 31 July 2016 at 20:20, Simon Glass  wrote:
>> On 26 July 2016 at 04:06, Jaehoon Chung  wrote:
>>> Some arguments don't need to pass to sdhci_setup_cfg.
>>> Generic variable can be used in sdhci_setup_cfg, and some arguments are
>>> already included in sdhci_host struct.
>>>
>>> It's enough that just pass the board specific things to sdhci_setup_cfg().
>>> After removing the unnecessary arguments, it's more simpler than before.
>>> It doesn't consider "Version" and "Capabilities" anymore in each SoC
>>> driver.
>>>
>>> Signed-off-by: Jaehoon Chung 
>>> ---
>>>  drivers/mmc/msm_sdhci.c  |  4 +---
>>>  drivers/mmc/sdhci.c  | 28 +++-
>>>  drivers/mmc/zynq_sdhci.c |  9 ++---
>>>  include/sdhci.h  | 12 +++-
>>>  4 files changed, 21 insertions(+), 32 deletions(-)
>>
>> Reviewed-by: Simon Glass 
> 
> If you are applying this, can you please fix the typo in the subject?

Sure! Also i'm preparing other mmc patches..Thanks for reminding.

Best Regards,
Jaehoon Chung

> 
> - Simon
> 
> 
> 

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

Re: [U-Boot] [PATCH] powerpc/86xx: Increase boot map size to 256 MiB

[york sun]

On 07/19/2016 03:52 PM, Scott Wood wrote:
> This is what Linux maps on classic PPC during boot, and modern kernel
> images don't fit within the current 8 MiB uncompressed limit.
>
> Adjust image load addresses to be above this limit to avoid conflicts.
>
> Signed-off-by: Scott Wood 
> ---
>  include/configs/MPC8610HPCD.h | 13 +++--
>  include/configs/MPC8641HPCN.h |  9 +
>  2 files changed, 12 insertions(+), 10 deletions(-)
>

Applied to mpc86xx master, awaiting upstream.

Thanks.

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

Re: [U-Boot] [PATCH 1/2] mmc: sdhci: remove the unused argument for sdhci_setup_cfg

[Jaehoon Chung]

Hi Simon,

On 08/04/2016 11:35 AM, Simon Glass wrote:
> Hi Jaehoon,
> 
> On 31 July 2016 at 20:20, Simon Glass  wrote:
>> On 26 July 2016 at 04:06, Jaehoon Chung  wrote:
>>> buswidth isn't used anywhere in sdhci_setup_cfg.
>>>
>>> Signed-off-by: Jaehoon Chung 
>>> ---
>>>  drivers/mmc/msm_sdhci.c  | 4 ++--
>>>  drivers/mmc/sdhci.c  | 4 ++--
>>>  drivers/mmc/zynq_sdhci.c | 2 +-
>>>  include/sdhci.h  | 3 +--
>>>  4 files changed, 6 insertions(+), 7 deletions(-)
>>
>> Reviewed-by: Simon Glass 
> 
> Are you going to pick this up? I suggest that it goes in now since it
> will affect people porting drivers.

I think it's related with DM side. So if you can pick this, I'm ok.
Otherwise, i will apply on u-boot-mmc, today..And tomorrow i will request pull.

> 
> Regards,
> Simon
> 
> 
> 

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

Re: [U-Boot] [PATCH 2/2] mmc: sdhci: remove the unnecessary argumetns for sdhci_setup_cfg

[Simon Glass]

On 31 July 2016 at 20:20, Simon Glass  wrote:
> On 26 July 2016 at 04:06, Jaehoon Chung  wrote:
>> Some arguments don't need to pass to sdhci_setup_cfg.
>> Generic variable can be used in sdhci_setup_cfg, and some arguments are
>> already included in sdhci_host struct.
>>
>> It's enough that just pass the board specific things to sdhci_setup_cfg().
>> After removing the unnecessary arguments, it's more simpler than before.
>> It doesn't consider "Version" and "Capabilities" anymore in each SoC
>> driver.
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/msm_sdhci.c  |  4 +---
>>  drivers/mmc/sdhci.c  | 28 +++-
>>  drivers/mmc/zynq_sdhci.c |  9 ++---
>>  include/sdhci.h  | 12 +++-
>>  4 files changed, 21 insertions(+), 32 deletions(-)
>
> Reviewed-by: Simon Glass 

If you are applying this, can you please fix the typo in the subject?

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

Re: [U-Boot] [PATCH 1/2] mmc: sdhci: remove the unused argument for sdhci_setup_cfg

[Simon Glass]

Hi Jaehoon,

On 31 July 2016 at 20:20, Simon Glass  wrote:
> On 26 July 2016 at 04:06, Jaehoon Chung  wrote:
>> buswidth isn't used anywhere in sdhci_setup_cfg.
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/msm_sdhci.c  | 4 ++--
>>  drivers/mmc/sdhci.c  | 4 ++--
>>  drivers/mmc/zynq_sdhci.c | 2 +-
>>  include/sdhci.h  | 3 +--
>>  4 files changed, 6 insertions(+), 7 deletions(-)
>
> Reviewed-by: Simon Glass 

Are you going to pick this up? I suggest that it goes in now since it
will affect people porting drivers.

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

Re: [U-Boot] [RESEND PATCH 2/2] rockchip: add usb mass storage feature support for rk3288

[Simon Glass]

On 2 August 2016 at 21:55, Ziyuan Xu  wrote:
> Enable ums feature for rk3288 boards, so that we can mount the mmc
> device to PC.
>
> Signed-off-by: Ziyuan Xu 
> ---
>
>  include/configs/rk3288_common.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
> index fa37335..d3d4c68 100644
> --- a/include/configs/rk3288_common.h
> +++ b/include/configs/rk3288_common.h
> @@ -96,6 +96,10 @@
>  #define CONFIG_FASTBOOT_BUF_ADDR   CONFIG_SYS_LOAD_ADDR
>  #define CONFIG_FASTBOOT_BUF_SIZE   0x0800
>
> +/* usb mass storage */
> +#define CONFIG_USB_FUNCTION_MASS_STORAGE
> +#define CONFIG_CMD_USB_MASS_STORAGE
> +
>  #define CONFIG_USB_GADGET_DOWNLOAD
>  #define CONFIG_G_DNL_MANUFACTURER  "Rockchip"
>  #define CONFIG_G_DNL_VENDOR_NUM0x2207
> --
> 2.9.2
>
>

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

Re: [U-Boot] [RESEND PATCH 1/2] rockchip: add basic partitions support for rk3288

[Simon Glass]

On 2 August 2016 at 21:55, Ziyuan Xu  wrote:
> For compatibility with distro boot, fastboot, and mount the mmc deivce
> to PC via usb mass storage feature, GPT partitions are essential.
>
> You should write the partitions to mmc device prior to use above
> feature.
>
> => gpt write mmc 1 $partitions
> GPT successfully written to block device!
> success!
>
> Signed-off-by: Ziyuan Xu 
> ---
>
>  include/configs/rk3288_common.h | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
> index 814116c..fa37335 100644
> --- a/include/configs/rk3288_common.h
> +++ b/include/configs/rk3288_common.h
> @@ -113,6 +113,12 @@
> "kernel_addr_r=0x0200\0" \
> "ramdisk_addr_r=0x0400\0"
>
> +#define CONFIG_RANDOM_UUID
> +#define PARTS_DEFAULT \
> +   "uuid_disk=${uuid_gpt_disk};" \
> +   "name=boot,start=8M,size=64M,bootable,uuid=${uuid_gpt_boot};" \
> +   "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \
> +
>  /* First try to boot from SD (index 0), then eMMC (index 1 */
>  #define BOOT_TARGET_DEVICES(func) \
> func(MMC, mmc, 0) \
> @@ -125,6 +131,7 @@
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> "fdt_high=0x1fff\0" \
> "initrd_high=0x1fff\0" \
> +   "partitions=" PARTS_DEFAULT \
> ENV_MEM_LAYOUT_SETTINGS \
> ROCKCHIP_DEVICE_SETTINGS \
> BOOTENV
> --
> 2.9.2
>
>

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

Re: [U-Boot] [PATCH 2/4] ARM: AM57xx: Disable non-FIT based image loading for HS devices

[Simon Glass]

Hi Tom,

On 3 August 2016 at 19:48, Tom Rini  wrote:
> On Wed, Aug 03, 2016 at 07:16:12PM -0600, Simon Glass wrote:
>> Hi Andrew,
>>
>> On 1 August 2016 at 09:30, Andrew F. Davis  wrote:
>> > Disable support for loading non-FIT images for AM57xx platforms using
>> > the high-security (HS) device variant.
>> >
>> > Signed-off-by: Andrew F. Davis 
>> > ---
>> >  configs/am57xx_hs_evm_defconfig | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/configs/am57xx_hs_evm_defconfig 
>> > b/configs/am57xx_hs_evm_defconfig
>> > index a4bfdd5..e6f3ebc 100644
>> > --- a/configs/am57xx_hs_evm_defconfig
>> > +++ b/configs/am57xx_hs_evm_defconfig
>> > @@ -41,6 +41,7 @@ CONFIG_FIT=y
>> >  CONFIG_SPL_OF_LIBFDT=y
>> >  CONFIG_SPL_LOAD_FIT=y
>> >  CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
>> > +CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE=y
>> >  CONFIG_OF_LIST="am57xx-beagle-x15"
>> >  CONFIG_DM_I2C=y
>> >  CONFIG_DM_SPI=y
>>
>> Why do we need to panic? Can we use something like 
>> CONFIG_IMAGE_FORMAT_LEGACY?
>
> The need to panic is because if we cannot authenticate we are to fail as
> this is a secure device.

We already have a hang in board_init_r() (SPL: failed to boot from all
boot devices). I'm suggesting that instead of panic we just return an
error from spl_parse_image_header() and let things work in the normal
way.

Anyway, I don't mind if people prefer this approach.

It's strange that this patch does not seem to be in patchwork.

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

Re: [U-Boot] [PATCH] configs: rk3399: add gpt and fs support

[Simon Glass]

On 1 August 2016 at 21:03, Ziyuan Xu  wrote:
>
> On 2016年08月02日 10:56, Ziyuan Xu wrote:
>>
>> Hi kever,
>>
>>
>> On 2016年08月02日 10:29, Kever Yang wrote:
>>>
>>> To compatible with distro boot, we need to add gpt and fs support,
>>> including gpt table and vfat, ext2, ext4 support.
>>>
>>> Signed-off-by: Kever Yang 
>>> ---
>>>
>>>   include/configs/rk3399_common.h | 19 +++
>>>   1 file changed, 19 insertions(+)

Apart from the comments mentioned:

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

Re: [U-Boot] [PATCH v3 2/2] mmc: rockchip_sdhci: add clock init

[Simon Glass]

On 31 July 2016 at 21:34, Kever Yang  wrote:
> Initialize the maximum clock with CMU, before setting the rockchip sdhci
> host controller.
>
> Signed-off-by: Kever Yang 
> Reviewed-by: Jaehoon Chung 
> ---
>
> Changes in v3:
> - update commit message
>
> Changes in v2:
> - update base on comments from Jaehoon Chung
>
>  drivers/mmc/rockchip_sdhci.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH 2/4] ARM: AM57xx: Disable non-FIT based image loading for HS devices

[Tom Rini]

On Wed, Aug 03, 2016 at 07:16:12PM -0600, Simon Glass wrote:
> Hi Andrew,
> 
> On 1 August 2016 at 09:30, Andrew F. Davis  wrote:
> > Disable support for loading non-FIT images for AM57xx platforms using
> > the high-security (HS) device variant.
> >
> > Signed-off-by: Andrew F. Davis 
> > ---
> >  configs/am57xx_hs_evm_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/configs/am57xx_hs_evm_defconfig 
> > b/configs/am57xx_hs_evm_defconfig
> > index a4bfdd5..e6f3ebc 100644
> > --- a/configs/am57xx_hs_evm_defconfig
> > +++ b/configs/am57xx_hs_evm_defconfig
> > @@ -41,6 +41,7 @@ CONFIG_FIT=y
> >  CONFIG_SPL_OF_LIBFDT=y
> >  CONFIG_SPL_LOAD_FIT=y
> >  CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
> > +CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE=y
> >  CONFIG_OF_LIST="am57xx-beagle-x15"
> >  CONFIG_DM_I2C=y
> >  CONFIG_DM_SPI=y
> 
> Why do we need to panic? Can we use something like CONFIG_IMAGE_FORMAT_LEGACY?

The need to panic is because if we cannot authenticate we are to fail as
this is a secure device.

-- 
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] [PATCH] arm: cache: always flush cache line size for page table

[Stefan Agner]

On 2016-08-03 18:22, Simon Glass wrote:
> Hi,
> 
> On 3 August 2016 at 10:32, Fabio Estevam  wrote:
>> On Tue, Aug 2, 2016 at 4:07 AM, Stefan Agner  wrote:
>>> From: Stefan Agner 
>>>
>>> The page table is maintained by the CPU, hence it is safe to always
>>> align cache flush to a whole cache line size. This allows to use
>>> mmu_page_table_flush for a single page table, e.g. when configure
>>> only small regions through mmu_set_region_dcache_behaviour.
>>>
>>> Signed-off-by: Stefan Agner 
>>
>> Tested-by: Fabio Estevam 
> 
> I'm OK with this, or a change in mmu_set_region_dcache_behaviour() to
> align he addresses.

Ok will move to mmu_set_region_dcache_behaviour as Marek seems to prefer
that solution.

--
Stefan

> 
> Reviewed-by: Simon Glass 
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: cache: always flush cache line size for page table

[Simon Glass]

Hi,

On 3 August 2016 at 10:32, Fabio Estevam  wrote:
> On Tue, Aug 2, 2016 at 4:07 AM, Stefan Agner  wrote:
>> From: Stefan Agner 
>>
>> The page table is maintained by the CPU, hence it is safe to always
>> align cache flush to a whole cache line size. This allows to use
>> mmu_page_table_flush for a single page table, e.g. when configure
>> only small regions through mmu_set_region_dcache_behaviour.
>>
>> Signed-off-by: Stefan Agner 
>
> Tested-by: Fabio Estevam 

I'm OK with this, or a change in mmu_set_region_dcache_behaviour() to
align he addresses.

Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH] cmd: net: flush cache cacheline aligned

[Simon Glass]

Hi Joe,

On 3 August 2016 at 17:18, Joe Hershberger  wrote:
> On Tue, Aug 2, 2016 at 2:20 AM, Stefan Agner  wrote:
>> From: Stefan Agner 
>>
>> Flush loaded data cacheline aligned. This avoids warnings such as
>> CACHE: Misaligned operation at range [8100, 816d0fa8]
>>
>> Signed-off-by: Stefan Agner 
>> ---
>
> This was already rejected once.
> http://lists.denx.de/pipermail/u-boot/2012-April/121564.html
>
>> Why do we actually have to flush caches after load? It seems to
>> have worked so far despite the caches did not get flushed (due to
>> missalignment).
>
> I'm not sure that we do, but it's been there since as far back as the
> git history goes. Maybe Wolfgang has memory of a reason.

I think this is the correct solution. If you load something to memory
you have to flush the cache. If someone is brave enough to load an
image that finishes immediately before something where there is data
that will be overwritten by the flush, then they deserve some pain.

Anytime we flush the cache we have to do it according the rules of the
cache. One of those rules is that cache lines are larger than one
byte. So either we don't flush or we do, and if we do, we must align.

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

Re: [U-Boot] [PATCH] malloc_simple: Add simple malloc free function

[Simon Glass]

Hi,

On 2 August 2016 at 21:24, Chin Liang See  wrote:
> Enable a simple malloc implementation which will minimize
> memory usage prior relocation. This is essential as memory
> available prior location is internal memory and limited in
> size.
>
> This implementation will stored last 2 usage of malloc. When
> free is invoked and the free address matched, we shall revert
> to previous value of gd->malloc_ptr that we stored.

I'm really not keen on this patch. Can we not adjust the FAT code to
avoid repeated malloc()/free()?


>
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Simon Glass 
> Cc: Tom Rini 
> Cc: Dinh Nguyen 
> Cc: Tien Fong Chee 
> ---
>  common/dlmalloc.c |  6 --
>  common/malloc_simple.c| 34 ++
>  include/asm-generic/global_data.h |  2 ++
>  include/malloc.h  |  3 ++-
>  4 files changed, 42 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH 1/2] rockchip: add basic partitions support for rk3288

[Simon Glass]

On 2 August 2016 at 21:50, Ziyuan Xu  wrote:
> For compatibility with distro boot, fastboot, and mount the mmc deivce
> to PC via usb mass storage feature, GPT partitions are essential.
>
> You should write the partitions to mmc device prior to use above
> feature.
>
> => gpt write mmc 1 $partitions
> GPT successfully written to block device!
> success!
>
> Signed-off-by: Ziyuan Xu 
> ---
>
>  include/configs/rk3288_common.h | 7 +++
>  1 file changed, 7 insertions(+)

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

Re: [U-Boot] [PATCH] tegra: config: Add 'pci enum' to preboot when PCI is enabled

[Simon Glass]

Hi,

On 3 August 2016 at 09:37, Stephen Warren  wrote:
> On 08/03/2016 03:35 AM, Alban Bedel wrote:
>>
>> For simplicity and backward compatibility automatically run 'pci enum'
>> via preboot when PCI is enabled. As preboot is already used for the
>> USB keyboard support this rework how CONFIG_PREBOOT is set to allow
>> combining several commands.
>
>
> For better or worse, this was a deliberate change, so I don't think this
> patch will be accepted.
>
> If it is, then you should apply it to all boards, not just Tegra boards, and
> adjust include/config_distro_bootcmd.h since it will no longer need to run
> "pci enum", and also test/py/tests/test_net.py won't need to either.

The boards which need PCI to boot are still few... we've talked about
this before. It would be great if we could find a way to detect or be
told that boot devices are on PCI and probe it accordingly. Perhaps we
should have a driver flag?

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

Re: [U-Boot] [PATCH] net: e1000: Allow to use e1000 SPI command with DM

[Simon Glass]

On 2 August 2016 at 20:42, Yaroslav K.  wrote:
> Fix compile errors when enabling CONFIG_DM_ETH,
> CONFIG_CMD_E1000 and CONFIG_E1000_SPI.
>
> Signed-off-by: Yaroslav K. 
> ---
>  drivers/net/e1000.c |  6 -
>  drivers/net/e1000_spi.c | 60 
> -
>  2 files changed, 35 insertions(+), 31 deletions(-)

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

Re: [U-Boot] [PATCH v2] eth: asix88179: Add support for the driver model

[Simon Glass]

On 3 August 2016 at 03:51, Alban Bedel  wrote:
> Adjust this driver to support driver model for Ethernet.
>
> Signed-off-by: Alban Bedel 
> ---
>  drivers/usb/eth/asix88179.c | 184 
> 
>  1 file changed, 184 insertions(+)

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

Re: [U-Boot] [PATCH v2 08/10] arm: dts: imx7: add Ricoh RN5T567 PMIC node

[Simon Glass]

On 1 August 2016 at 23:50, Stefan Agner  wrote:
> From: Stefan Agner 
>
> Add device tree node for Ricoh RN5T567. Currently we do not need
> the individual DC/DC converters or LDO's (and they are also not
> yet supported by the driver).
>
> Signed-off-by: Stefan Agner 
> ---
>
>  arch/arm/dts/imx7-colibri.dts | 5 +
>  1 file changed, 5 insertions(+)

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

Re: [U-Boot] [PATCH 3/3] config: rk3399: enable dwmmc controller

[Simon Glass]

On 1 August 2016 at 21:00, Kever Yang  wrote:
> Signed-off-by: Kever Yang 

Commit message please.

> ---
>
>  configs/evb-rk3399_defconfig| 1 +
>  include/configs/rk3399_common.h | 1 +
>  2 files changed, 2 insertions(+)

Acked-by: Simon Glass 

>
> diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
> index 3f9b47e..18f6ae6 100644
> --- a/configs/evb-rk3399_defconfig
> +++ b/configs/evb-rk3399_defconfig
> @@ -22,6 +22,7 @@ CONFIG_FIT=y
>  CONFIG_SYSRESET=y
>  CONFIG_DM_MMC=y
>  CONFIG_ROCKCHIP_SDHCI=y
> +CONFIG_ROCKCHIP_DWMMC=y
>  CONFIG_PINCTRL=y
>  CONFIG_RAM=y
>  CONFIG_SYS_NS16550=y
> diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
> index ca05e5c..12327d5 100644
> --- a/include/configs/rk3399_common.h
> +++ b/include/configs/rk3399_common.h
> @@ -30,6 +30,7 @@
>  /* MMC/SD IP block */
>  #define CONFIG_MMC
>  #define CONFIG_GENERIC_MMC
> +#define CONFIG_DWMMC
>  #define CONFIG_SDHCI
>  #define CONFIG_BOUNCE_BUFFER
>  #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ 2
> --
> 1.9.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] net/ethoc: add CONFIG_DM_ETH support

[Simon Glass]

On 2 August 2016 at 05:31, Max Filippov  wrote:
> Extract reusable parts from ethoc_init, ethoc_set_mac_address,
> ethoc_send and ethoc_receive, move the rest under #ifdef CONFIG_DM_ETH.
> Add U_BOOT_DRIVER, eth_ops structure and implement required methods.
>
> Signed-off-by: Max Filippov 
> ---
>  drivers/net/ethoc.c  | 221 
> +++
>  include/dm/platform_data/net_ethoc.h |  20 
>  2 files changed, 194 insertions(+), 47 deletions(-)
>  create mode 100644 include/dm/platform_data/net_ethoc.h

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

Re: [U-Boot] [PATCH] x86: bayleybay: Add PS/2 keyboard and mouse to ASL file

[Simon Glass]

On 1 August 2016 at 21:53, Bin Meng  wrote:
> Without PS/2 keyboard and mouse in the ASL file, Windows does not
> see them. No problem for Linux as it probes keyboard and mouse via
> the legacy 8042 I/O port.
>
> Signed-off-by: Bin Meng 
> ---
>
>  board/intel/bayleybay/acpi/mainboard.asl | 38 
> 
>  1 file changed, 38 insertions(+)

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

Re: [U-Boot] [PATCH 2/3] dts: rk3399: enable dwmmc for sdcard

[Simon Glass]

Hi Kever,

On 1 August 2016 at 21:00, Kever Yang  wrote:
> Signed-off-by: Kever Yang 

Please add a commit message.

> ---
>
>  arch/arm/dts/rk3399-evb.dts | 4 
>  arch/arm/dts/rk3399.dtsi| 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>

Acked-by: Simon Glass 

> diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> index bbcfcd0..e92a492 100644
> --- a/arch/arm/dts/rk3399-evb.dts
> +++ b/arch/arm/dts/rk3399-evb.dts
> @@ -61,6 +61,10 @@
> status = "okay";
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> bus-width = <8>;
> mmc-hs400-1_8v;
> diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
> index fb5af54..9547627 100644
> --- a/arch/arm/dts/rk3399.dtsi
> +++ b/arch/arm/dts/rk3399.dtsi
> @@ -172,7 +172,7 @@
> reg = <0x0 0xfe32 0x0 0x4000>;
> interrupts = ;
> clock-freq-min-max = <40 15000>;
> -   clocks = < HCLK_SDMMC>, < SCLK_SDMMC>,
> +   clocks = < SCLK_SDMMC>, < HCLK_SDMMC>,
>  < SCLK_SDMMC_DRV>, < SCLK_SDMMC_SAMPLE>;
> clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> fifo-depth = <0x100>;
> --
> 1.9.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 07/10] power: pmic: add Ricoh RN5T567 PMIC support

[Simon Glass]

+Stephen as an example of a simple PMIC driver.

- Simon

On 1 August 2016 at 23:50, Stefan Agner  wrote:
> From: Stefan Agner 
>
> Add device model enabled PMIC driver for Ricoh RN5T567 PMIC used
> on Colibri iMX7.
>
> Signed-off-by: Stefan Agner 
> Reviewed-by: Simon Glass 
> ---
>
>  doc/device-tree-bindings/pmic/rn5t567.txt |  17 +
>  drivers/power/pmic/Kconfig|   8 +++
>  drivers/power/pmic/Makefile   |   1 +
>  drivers/power/pmic/rn5t567.c  |  64 +
>  include/power/rn5t567_pmic.h  | 113 
> ++
>  5 files changed, 203 insertions(+)
>  create mode 100644 doc/device-tree-bindings/pmic/rn5t567.txt
>  create mode 100644 drivers/power/pmic/rn5t567.c
>  create mode 100644 include/power/rn5t567_pmic.h
>
> diff --git a/doc/device-tree-bindings/pmic/rn5t567.txt 
> b/doc/device-tree-bindings/pmic/rn5t567.txt
> new file mode 100644
> index 000..e9e6885
> --- /dev/null
> +++ b/doc/device-tree-bindings/pmic/rn5t567.txt
> @@ -0,0 +1,17 @@
> +Ricoh RN5T567 PMIC
> +
> +This file describes the binding info for the PMIC driver.
> +
> +Required properties:
> +- compatible: "ricoh,rn5t567"
> +- reg: depending on strapping, e.g. 0x33
> +
> +With those two properties, the PMIC device can be used to read/write
> +registers.
> +
> +Example:
> +
> +rn5t567@33 {
> +   compatible = "ricoh,rn5t567";
> +   reg = <0x33>;
> +};
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 69f8d51..13d293a 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -127,6 +127,14 @@ config PMIC_S5M8767
> driver provides basic register access and sets up the attached
> regulators if regulator support is enabled.
>
> +config PMIC_RN5T567
> +   bool "Enable driver for Ricoh RN5T567 PMIC"
> +   depends on DM_PMIC
> +   ---help---
> +   The RN5T567 is a PMIC with 4 step-down DC/DC converters, 5 LDO
> +   regulators Real-Time Clock and 4 GPIOs. This driver provides
> +   register access only.
> +
>  config PMIC_TPS65090
> bool "Enable driver for Texas Instruments TPS65090 PMIC"
> depends on DM_PMIC
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 52b4f71..37d9eb5 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
>  obj-$(CONFIG_PMIC_ACT8846) += act8846.o
>  obj-$(CONFIG_PMIC_PM8916) += pm8916.o
>  obj-$(CONFIG_PMIC_RK808) += rk808.o
> +obj-$(CONFIG_PMIC_RN5T567) += rn5t567.o
>  obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
>  obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o
>
> diff --git a/drivers/power/pmic/rn5t567.c b/drivers/power/pmic/rn5t567.c
> new file mode 100644
> index 000..001e695
> --- /dev/null
> +++ b/drivers/power/pmic/rn5t567.c
> @@ -0,0 +1,64 @@
> +/*
> + * Copyright (C) 2016 Toradex AG
> + * Stefan Agner 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int rn5t567_reg_count(struct udevice *dev)
> +{
> +   return RN5T567_NUM_OF_REGS;
> +}
> +
> +static int rn5t567_write(struct udevice *dev, uint reg, const uint8_t *buff,
> + int len)
> +{
> +   int ret;
> +
> +   ret = dm_i2c_write(dev, reg, buff, len);
> +   if (ret) {
> +   debug("write error to device: %p register: %#x!", dev, reg);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +static int rn5t567_read(struct udevice *dev, uint reg, uint8_t *buff, int 
> len)
> +{
> +   int ret;
> +
> +   ret = dm_i2c_read(dev, reg, buff, len);
> +   if (ret) {
> +   debug("read error from device: %p register: %#x!", dev, reg);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +static struct dm_pmic_ops rn5t567_ops = {
> +   .reg_count = rn5t567_reg_count,
> +   .read = rn5t567_read,
> +   .write = rn5t567_write,
> +};
> +
> +static const struct udevice_id rn5t567_ids[] = {
> +   { .compatible = "ricoh,rn5t567" },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(pmic_rn5t567) = {
> +   .name = "rn5t567 pmic",
> +   .id = UCLASS_PMIC,
> +   .of_match = rn5t567_ids,
> +   .ops = _ops,
> +};
> diff --git a/include/power/rn5t567_pmic.h b/include/power/rn5t567_pmic.h
> new file mode 100644
> index 000..9ce601f
> --- /dev/null
> +++ b/include/power/rn5t567_pmic.h
> @@ -0,0 +1,113 @@
> +/*
> + * Copyright (C) 2016 Toradex AG
> + * Stefan Agner 
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +#ifndef __RN5T567_PMIC_H_
> +#define __RN5T567_PMIC_H_
> +
> +/* RN5T567 registers */
> +enum {
> +   RN5T567_LSIVER  = 0x00,
> +  

Re: [U-Boot] [PATCH 1/3] clock: rk3399: add support for dwmmc 400K

[Simon Glass]

On 1 August 2016 at 20:47, Kever Yang  wrote:
> MMC core will use 400KHz for card initialize first and then switch to
> higher frequency like 50MHz, we need to support both 400KHz and about
> 50MHz for dwmmc controller.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/clk/clk_rk3399.c | 29 +
>  1 file changed, 21 insertions(+), 8 deletions(-)

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

Re: [U-Boot] [PATCH 8/9] mmc: tegra: port to standard clock/reset APIs

[Simon Glass]

Hi Stephen,

On 1 August 2016 at 09:50, Stephen Warren  wrote:
> On 07/31/2016 08:20 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 27 July 2016 at 15:24, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> Tegra186 supports the new standard clock and reset APIs. Older Tegra SoCs
>>> still use custom APIs. Enhance the Tegra MMC driver so that it can
>>> operate
>>> with either set of APIs.
>>>
>>> Signed-off-by: Stephen Warren 
>>> Cc: Pantelis Antoniou 
>>> ---
>>>  arch/arm/include/asm/arch-tegra/tegra_mmc.h |  8 -
>>>  drivers/mmc/tegra_mmc.c | 55
>>> -
>>>  2 files changed, 53 insertions(+), 10 deletions(-)
>>
>>
>> Shouldn't we fix up the code to all use the new APIs?
>
>
> Eventually yes. However, that's something that will take a lot of work. When
> similar common APIs were introduced into Linux, there was a transition
> period of 1-2 years where new code was immediately written to the new APIs,
> and old code (e.g. legacy clock API implementation, and its callers) was
> slowly converted. I would expect the same thing in U-Boot; any other
> approach means preventing new work until the conversions are complete, which
> would be rather stagnating.

I still don't like the #ifdefs? Does Linux have #ifdefs in the mmc driver?

Also the work to convert to CONFIG_BLK, CONFIG_DM_MMC_OPS is not a lot of work.

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

Re: [U-Boot] [PATCH 6/7] ARM: tegra: enable SD card on p2771-0000

[Simon Glass]

Hi Stephen,

On 1 August 2016 at 10:02, Stephen Warren  wrote:
> On 07/31/2016 07:04 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 29 July 2016 at 13:15, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> Now that clock and reset drivers exist for Tegra186, we can enable the SD
>>> card controller. Now that a BPMP I2C driver exists for Tegra186, we can
>>> communicate with the PMIC to enable power to the SD card. Hook up the DT
>>> content and board code required to make the SD card work.
>
>
>>> diff --git a/board/nvidia/p2771-/p2771-.c
>>> b/board/nvidia/p2771-/p2771-.c
>
>
>>> +int tegra_board_init(void)
>>> +{
>>> +   struct udevice *dev;
>>> +   uchar val;
>>> +   int ret;
>>> +
>>> +   /* Turn on MAX77620 LDO3 to 3.3V for SD card power */
>>> +   debug("%s: Set LDO3 for VDDIO_SDMMC_AP power to 3.3V\n",
>>> __func__);
>>> +   ret = i2c_get_chip_for_busnum(0, MAX77620_I2C_ADDR_7BIT, 1,
>>> );
>>> +   if (ret) {
>>> +   printf("%s: Cannot find MAX77620 I2C chip\n", __func__);
>>> +   return ret;
>>> +   }
>>> +   /* 0xF2 for 3.3v, enabled: bit7:6 = 11 = enable, bit5:0 = voltage
>>> */
>>> +   val = 0xF2;
>>> +   ret = dm_i2c_write(dev, MAX77620_CNFG1_L3_REG, , 1);
>>> +   if (ret) {
>>> +   printf("i2c_write 0 0x3c 0x27 failed: %d\n", ret);
>>> +   return ret;
>>> +   }
>>
>>
>> Can you add a simple pmic driver for this? It's really easy and avoids
>> the horrible busnum stuff. The i2c_get_chip_for_busnum() should
>> ideally not be used.
>
>
> Perhaps we can defer that until later?
>
> FWIW, this current approach is used by all/most Tegra boards and works great
> for now. If converting this kind of code to use the PMIC infra-structure,
> I'd rather take a pass and do all Tegra boards at once, but equally I'd
> rather not hold up the Tegra186 patches behind yet another common API
> conversion; there are already 3 new common APIs introduced for Tegra in the
> Tegra186 support...

OK, will I remember this coming up previously, so I look forward to it
getting sorted out. It really isn't that much work to write a PMIC
driver.

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

Re: [U-Boot] [PATCH 2/4] ARM: AM57xx: Disable non-FIT based image loading for HS devices

[Simon Glass]

Hi Andrew,

On 1 August 2016 at 09:30, Andrew F. Davis  wrote:
> Disable support for loading non-FIT images for AM57xx platforms using
> the high-security (HS) device variant.
>
> Signed-off-by: Andrew F. Davis 
> ---
>  configs/am57xx_hs_evm_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
> index a4bfdd5..e6f3ebc 100644
> --- a/configs/am57xx_hs_evm_defconfig
> +++ b/configs/am57xx_hs_evm_defconfig
> @@ -41,6 +41,7 @@ CONFIG_FIT=y
>  CONFIG_SPL_OF_LIBFDT=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
> +CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE=y
>  CONFIG_OF_LIST="am57xx-beagle-x15"
>  CONFIG_DM_I2C=y
>  CONFIG_DM_SPI=y
> --
> 2.9.2
>

Why do we need to panic? Can we use something like CONFIG_IMAGE_FORMAT_LEGACY?

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

Re: [U-Boot] [PATCH 1/5] pci: tegra: port to standard clock/reset/pwr domain APIs

[Simon Glass]

Hi Stephen,

On 1 August 2016 at 09:22, Stephen Warren  wrote:
> On 07/31/2016 07:02 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 27 July 2016 at 15:48, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> Tegra186 supports the new standard clock, reset, and power domain APIs.
>>> Older Tegra SoCs still use custom APIs. Enhance the Tegra PCIe driver so
>>> that it can operate with either set of APIs.
>>>
>>> On Tegra186, the BPMP handles all aspects of PCIe PHY (UPHY) programming.
>>> Consequently, this logic is disabled too.
>>>
>>> Signed-off-by: Stephen Warren 
>>> ---
>>> This whole series builds on the other Tegra186 series that I just sent.
>>>
>>>  drivers/pci/Kconfig |   1 +
>>>  drivers/pci/pci_tegra.c | 154
>>> ++--
>>>  2 files changed, 150 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>>> index 26aa2b0930a0..669e37bb5dc5 100644
>>> --- a/drivers/pci/Kconfig
>>> +++ b/drivers/pci/Kconfig
>>> @@ -31,6 +31,7 @@ config PCI_SANDBOX
>>>  config PCI_TEGRA
>>> bool "Tegra PCI support"
>>> depends on TEGRA
>>> +   depends on (TEGRA186 && POWER_DOMAIN) || (!TEGRA186)
>>> help
>>>   Enable support for the PCIe controller found on some
>>> generations of
>>>   Tegra. Tegra20 has 2 root ports with a total of 4 lanes,
>>> Tegra30 has
>>> diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
>>> index 352cdef56ab4..a6785ad0bbee 100644
>>> --- a/drivers/pci/pci_tegra.c
>>> +++ b/drivers/pci/pci_tegra.c
>>> @@ -13,22 +13,26 @@
>>>  #define pr_fmt(fmt) "tegra-pcie: " fmt
>>>
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>
>>>  #include 
>>>  #include 
>>>
>>> +#include 
>>> +
>>> +#ifndef CONFIG_TEGRA186
>>>  #include 
>>>  #include 
>>>  #include 
>>> -
>>> -#include 
>>> -
>>>  #include 
>>> +#endif
>>>
>>>  DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -103,6 +107,9 @@ DECLARE_GLOBAL_DATA_PTR;
>>>  #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222   (0x1 << 20)
>>>  #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_X4_X1 (0x1 << 20)
>>>  #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411   (0x2 << 20)
>>> +#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_401  (0x0 << 20)
>>> +#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_211  (0x1 << 20)
>>> +#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_111  (0x2 << 20)
>>>
>>>  #define AFI_FUSE   0x104
>>>  #define  AFI_FUSE_PCIE_T0_GEN2_DIS (1 << 2)
>>> @@ -110,6 +117,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>>  #define AFI_PEX0_CTRL  0x110
>>>  #define AFI_PEX1_CTRL  0x118
>>>  #define AFI_PEX2_CTRL  0x128
>>> +#define AFI_PEX2_CTRL_T186 0x19c
>>>  #define  AFI_PEX_CTRL_RST  (1 << 0)
>>>  #define  AFI_PEX_CTRL_CLKREQ_EN(1 << 1)
>>>  #define  AFI_PEX_CTRL_REFCLK_EN(1 << 3)
>>> @@ -173,6 +181,7 @@ enum tegra_pci_id {
>>> TEGRA30_PCIE,
>>> TEGRA124_PCIE,
>>> TEGRA210_PCIE,
>>> +   TEGRA186_PCIE,
>>>  };
>>>
>>>  struct tegra_pcie_port {
>>> @@ -189,6 +198,7 @@ struct tegra_pcie_soc {
>>> unsigned int num_ports;
>>> unsigned long pads_pll_ctl;
>>> unsigned long tx_ref_sel;
>>> +   unsigned long afi_pex2_ctrl;
>>> u32 pads_refclk_cfg0;
>>> u32 pads_refclk_cfg1;
>>> bool has_pex_clkreq_en;
>>> @@ -209,7 +219,17 @@ struct tegra_pcie {
>>> unsigned long xbar;
>>>
>>> const struct tegra_pcie_soc *soc;
>>> +
>>> +#ifdef CONFIG_TEGRA186
>>> +   struct clk clk_afi;
>>> +   struct clk clk_pex;
>>> +   struct reset_ctl reset_afi;
>>> +   struct reset_ctl reset_pex;
>>> +   struct reset_ctl reset_pcie_x;
>>> +   struct power_domain pwrdom;
>>> +#else
>>
>>
>> Eek. This is a compile-time driver configuration. Can you use the
>> device tree compatible string to detect which to use?
>
>
> No. The legacy APIs are simply not available (not compiled in) on the newer
> SoCs, so there must be a compile-time condition.
>
> It is theoretically possible to convert all the old SoCs to the new APIs so
> that this conditional goes away in the future, but we don't have that work
> scheduled at present.

What did you do with Linux?

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

Re: [U-Boot] [PATCH] ARM64: zynqmp: Do not enable DM_MMC by default

[Simon Glass]

On 1 August 2016 at 01:05, Michal Simek  wrote:
> The patch:
> "dm: mmc: zynq: Convert zynq to use driver model for MMC"
> (sha1: 329a449f2c289b4de8f892fca1d9379ce5fd81b8)
> added dependency on enabling some MMC options by default.
> There are minimal ZynqMP configurations which require
> only minimal configurations to be enabled to keep u-boot size
> as lower as possible.
>
> Move options to defconfig instead.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/Kconfig | 3 ---
>  configs/xilinx_zynqmp_ep_defconfig   | 2 ++
>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 2 ++
>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 2 ++
>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 2 ++
>  configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 2 ++
>  configs/xilinx_zynqmp_zcu102_defconfig   | 2 ++
>  configs/xilinx_zynqmp_zcu102_revB_defconfig  | 2 ++
>  8 files changed, 14 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH] mmc: s5p_sdhci: support the Driver model for Exynos

[Jaehoon Chung]

Hi, 

On 08/04/2016 09:38 AM, Minkyu Kang wrote:
> On 21/07/16 21:30, Jaehoon Chung wrote:
>> This patch support the driver model for s5p_sdhci controller.
>> To support the legacy model, maintained the existing code.
>>
>> Note: If use the Driver Model, it needs to modify the device-tree.
>> In future, will update the Device-tree and enable the configuratioin.
>> (CONFIG_BLK, CONFIG_DM_MMC and CONFING_DM_MMC_OPS)
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/s5p_sdhci.c | 73 
>> +
>>  1 file changed, 73 insertions(+)
>>
> 
> Because this patch has dependency with your patch, I delegate this patch to 
> you.

I will rebase this patch, and send the patch v2.
At that time, i will add with your acked-by and Simon's reviewd-by tags.

Best Regards,
Jaehoon Chung

> 
> Acked-by: Minkyu Kang 
> 
> Thanks,
> Minkyu Kang.
> 
> 
> 

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

Re: [U-Boot] [PATCH] mmc: s5p_sdhci: support the Driver model for Exynos

[Minkyu Kang]

On 21/07/16 21:30, Jaehoon Chung wrote:
> This patch support the driver model for s5p_sdhci controller.
> To support the legacy model, maintained the existing code.
> 
> Note: If use the Driver Model, it needs to modify the device-tree.
> In future, will update the Device-tree and enable the configuratioin.
> (CONFIG_BLK, CONFIG_DM_MMC and CONFING_DM_MMC_OPS)
> 
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/mmc/s5p_sdhci.c | 73 
> +
>  1 file changed, 73 insertions(+)
> 

Because this patch has dependency with your patch, I delegate this patch to you.

Acked-by: Minkyu Kang 

Thanks,
Minkyu Kang.

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

Re: [U-Boot] [PATCH] cmd: net: flush cache cacheline aligned

[Joe Hershberger]

On Tue, Aug 2, 2016 at 2:20 AM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> Flush loaded data cacheline aligned. This avoids warnings such as
> CACHE: Misaligned operation at range [8100, 816d0fa8]
>
> Signed-off-by: Stefan Agner 
> ---

This was already rejected once.
http://lists.denx.de/pipermail/u-boot/2012-April/121564.html

> Why do we actually have to flush caches after load? It seems to
> have worked so far despite the caches did not get flushed (due to
> missalignment).

I'm not sure that we do, but it's been there since as far back as the
git history goes. Maybe Wolfgang has memory of a reason.

-Joe

> --
> Stefan
>
>  cmd/net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmd/net.c b/cmd/net.c
> index b2f3c7b..540daeb 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -244,7 +244,7 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
> *cmdtp, int argc,
> }
>
> /* flush cache */
> -   flush_cache(load_addr, size);
> +   flush_cache(load_addr, ALIGN(size, CONFIG_SYS_CACHELINE_SIZE));
>
> bootstage_mark(BOOTSTAGE_ID_NET_LOADED);
>
> --
> 2.9.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] nitrogen6x : Use generic distro configuration

[Troy Kisky]

On 8/3/2016 12:54 AM, Stefano Babic wrote:
> Hi Fabien,
> 
> 
> On 02/08/2016 09:31, Fabien Lahoudere wrote:
>> In order to simplify the use of various images on various media
>> for nitrogen6x, the configuration of the board must follow the
>> generic distro configuration (doc/README.distro).
>>
>> In order to boot your old rootfs, move your kernel and your device
>> tree in /boot/. Then create /boot/extlinux/extlinux.conf with for
>> example:
>>
>> default Buildroot
>>
>> label Buildroot
>> kernel /boot/zImage
>> append console=ttymxc1,115200 root=/dev/mmcblk0p1 rootwait rw
>> fdtdir /boot
>>
>> Signed-off-by: Fabien Lahoudere 
>> ---
>> Changes for V2:
>> - reintegration of deleted env
>> - changes are applied only if CONFIG_DISTRO_DEFAULTS=y
>>
>> Changes for V3:
>> - remove undefined device tree
>>
>> Changes for v4:
>> - remove default definition of CONFIG_FDTADDR in mx6_common.h
>>
>>  configs/mx6qsabrelite_defconfig |  1 +
>>  configs/nitrogen6dl2g_defconfig |  1 +
>>  configs/nitrogen6dl_defconfig   |  1 +
>>  configs/nitrogen6q2g_defconfig  |  1 +
>>  configs/nitrogen6q_defconfig|  1 +
>>  configs/nitrogen6s1g_defconfig  |  1 +
>>  configs/nitrogen6s_defconfig|  1 +
>>  doc/README.imx6 | 47
>> +
>>  include/configs/mx6_common.h| 22 +++
>>  include/configs/nitrogen6x.h| 38 +++--
>>  10 files changed, 108 insertions(+), 6 deletions(-)
>>
>> diff --git a/configs/mx6qsabrelite_defconfig
>> b/configs/mx6qsabrelite_defconfig
>> index fa6139a..27b64c4 100644
>> --- a/configs/mx6qsabrelite_defconfig
>> +++ b/configs/mx6qsabrelite_defconfig
>> @@ -36,3 +36,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_OF_LIBFDT=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> \ No newline at end of file
>> diff --git a/configs/nitrogen6dl2g_defconfig
>> b/configs/nitrogen6dl2g_defconfig
>> index 02b2462..b1344c6 100644
>> --- a/configs/nitrogen6dl2g_defconfig
>> +++ b/configs/nitrogen6dl2g_defconfig
>> @@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_OF_LIBFDT=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> \ No newline at end of file
>> diff --git a/configs/nitrogen6dl_defconfig b/configs/nitrogen6dl_defconfig
>> index 52553f6..f794c08 100644
>> --- a/configs/nitrogen6dl_defconfig
>> +++ b/configs/nitrogen6dl_defconfig
>> @@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_OF_LIBFDT=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> \ No newline at end of file
>> diff --git a/configs/nitrogen6q2g_defconfig
>> b/configs/nitrogen6q2g_defconfig
>> index 11188b7..56cebe0 100644
>> --- a/configs/nitrogen6q2g_defconfig
>> +++ b/configs/nitrogen6q2g_defconfig
>> @@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_OF_LIBFDT=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> \ No newline at end of file
>> diff --git a/configs/nitrogen6q_defconfig b/configs/nitrogen6q_defconfig
>> index 05bf140..c150b97 100644
>> --- a/configs/nitrogen6q_defconfig
>> +++ b/configs/nitrogen6q_defconfig
>> @@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_OF_LIBFDT=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> \ No newline at end of file
>> diff --git a/configs/nitrogen6s1g_defconfig
>> b/configs/nitrogen6s1g_defconfig
>> index bb081a2..dfd096d 100644
>> --- a/configs/nitrogen6s1g_defconfig
>> +++ b/configs/nitrogen6s1g_defconfig
>> @@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_OF_LIBFDT=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> \ No newline at end of file
>> diff --git a/configs/nitrogen6s_defconfig b/configs/nitrogen6s_defconfig
>> index 08e91c9..5e2e693 100644
>> --- a/configs/nitrogen6s_defconfig
>> +++ b/configs/nitrogen6s_defconfig
>> @@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_OF_LIBFDT=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> \ No newline at end of file
>> diff --git a/doc/README.imx6 b/doc/README.imx6
>> index 1823fb2..36452f6 100644
>> --- a/doc/README.imx6
>> +++ b/doc/README.imx6
>> @@ -138,3 +138,50 @@ c
>>  The last "c" command tells kermit (from ckermit package in most distros)
>>  to switch from command line mode to communication mode, and when the
>>  script is finished, the U-Boot prompt is shown in the same shell.
>> +
>> +3. Using generic distro configuration
>> +-
>> +
>> +In order to simplify the use of various images on various media
>> +for imx6 boards, the configuration of the board must follow the
>> 

Re: [U-Boot] [PATCH 1/2] fdt_support: fdt_translate_address() blob const correctness

[Simon Glass]

On 1 August 2016 at 14:52, Stephen Warren  wrote:
>
> From: Stephen Warren 
>
> The next patch will call fdt_translate_address() from somewhere with a
> "const void *blob" rather than a "void *blob", so fdt_translate_address()
> must accept a const pointer too. Constify the minimum number of function
> parameters to achieve this.
>
> Signed-off-by: Stephen Warren 
> ---
>  common/fdt_support.c  | 19 ++-
>  include/fdt_support.h |  5 +++--
>  2 files changed, 13 insertions(+), 11 deletions(-)

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

Re: [U-Boot] [PATCH] cmd: net: flush cache cacheline aligned

[Simon Glass]

On 2 August 2016 at 01:20, Stefan Agner  wrote:
> From: Stefan Agner 
>
> Flush loaded data cacheline aligned. This avoids warnings such as
> CACHE: Misaligned operation at range [8100, 816d0fa8]
>
> Signed-off-by: Stefan Agner 
> ---
> Why do we actually have to flush caches after load? It seems to
> have worked so far despite the caches did not get flushed (due to
> missalignment).
>
> --
> Stefan
>
>  cmd/net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH] ARM: non-sec: flush code cacheline aligned

[Fabio Estevam]

Hi Stefan,

On Wed, Aug 3, 2016 at 5:08 PM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> Flush operations need to be cacheline aligned to take effect, make
> sure to flush always complete cachelines. This avoids messages such
> as:
> CACHE: Misaligned operation at range [0090, 009004d9]
>
> Signed-off-by: Stefan Agner 

This fixes the cache warnings:

Tested-by: Fabio Estevam 

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

Re: [U-Boot] [PATCH] cmd: net: flush cache cacheline aligned

[Fabio Estevam]

Hi Stefan,

On Tue, Aug 2, 2016 at 4:20 AM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> Flush loaded data cacheline aligned. This avoids warnings such as
> CACHE: Misaligned operation at range [8100, 816d0fa8]
>
> Signed-off-by: Stefan Agner 

This fixes the cache warnings:

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

Re: [U-Boot] A command to discard saved environments?

[James Chargin]

Dear Wolfgang,

On 08/03/2016 12:59 PM, Wolfgang Denk wrote:

Dear James,

In message  you wrote:

I know my non-volatile copy of the environment is in NOR flash so I use
the command

protect all off;erase  +1

But, of course this is specific to NOR flash.

I'm not aware of a way to do this in the general case, independent of NV
environment storage media and redundancy.


The idea applies to all kinds of persistent storage: just overwrite a
few (4 or more) bytes at the beginning of each copy of the persistent
envrionment.

In your case, you could save the "erase" by overwriting the first 4
bytes (where the CRC32 checksum is stored) with 0x.


In the case of my NOR flash storage, telling erase to do one byte 
actually causes the erasure of an entire flash sector, which we've 
reserved for the NV environment.  You are of course correct that 
overwriting the CRC will have the same operational effect.


In my shop, time is not critical, whereas simplicity of commands is 
valued by those I have to instruct to get this sort of operation done.


It's a rare occurrence that we need to do this, we don't use this sort 
of operation as a normal part of doing business.





I'd be supportive of having a way to do this.


No, I don't think we want to support this.  The persistent copy of the
environment is a precious resource, and I cannot think of a regular
use case to invalidate this.  If you do, the result is that you will
use the default settings at next boot - and the samve effect can be
acchieved by using "env reset" + "env save" as already recommended.
[The only difference is that you will not see the "invalid CRC, using
the default env" warning then, but I consider this a pro, not a con.]


Thank you for this perspective. I often feel a bit isolated in my way of 
doing things and I find it valuable to read things like this.


I agree that there is not a regular use for an operation of this sort.

During development and debug, I will occasionally need to restore a 
particular system to the physical state it would be in had we just 
received it from our contract manufacturer, which would include a blank 
area in NOR flash where the U-Boot environment is kept. This is done 
usually to "prove" that processes will work on those systems from the CM 
when production starts.


Up to now, I've used the erase command to do this and I will continue to 
do things this way. I guess I've been at this long enough that the rare 
times I need to erase this area of flash has become noticeable as a pattern.


Again, thank you for your reply.

Regards,
Jim



Best regards,

Wolfgang Denk



--
Jim Chargin
AJA Video Systems   j...@aja.com
(530) 271-3334  http://www.aja.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: non-sec: flush code cacheline aligned

[Stefan Agner]

From: Stefan Agner 

Flush operations need to be cacheline aligned to take effect, make
sure to flush always complete cachelines. This avoids messages such
as:
CACHE: Misaligned operation at range [0090, 009004d9]

Signed-off-by: Stefan Agner 
---

 arch/arm/cpu/armv7/virt-v7.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 9c53306..d33e5c6 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -54,10 +54,12 @@ static void relocate_secure_section(void)
 {
 #ifdef CONFIG_ARMV7_SECURE_BASE
size_t sz = __secure_end - __secure_start;
+   unsigned long szflush = ALIGN(sz + 1, CONFIG_SYS_CACHELINE_SIZE);
 
memcpy((void *)CONFIG_ARMV7_SECURE_BASE, __secure_start, sz);
+
flush_dcache_range(CONFIG_ARMV7_SECURE_BASE,
-  CONFIG_ARMV7_SECURE_BASE + sz + 1);
+  CONFIG_ARMV7_SECURE_BASE + szflush);
protect_secure_section();
invalidate_icache_all();
 #endif
-- 
2.9.0

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

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Hannes Schmelzer]

On 08/03/2016 08:09 PM, Tom Rini wrote:

On Wed, Aug 03, 2016 at 02:39:47PM -0300, Fabio Estevam wrote:

On Wed, Aug 3, 2016 at 1:13 PM, Stefan Agner  wrote:


As you noted, this particular case is due to cache flush of the page
table and should be fixed with:
arm: cache: always flush cache line size for page table

Yes, just noticed that on a imx7d-sdb I still get these cache warnings
even with "arm: cache: always flush cache line size for page table"
applied:


Filename 'zImage'.
Load address: 0x8080
Loading: #
  #
  #
  #
  #
  #
  #
  #
  9.1 MiB/s
done
Bytes transferred = 7334512 (6fea70 hex)
CACHE: Misaligned operation at range [8080, 80efea70]

I feel like we must have done something wrong of late, can you bisect
when these came in?  Thanks!
The mistake(s) must have been long time ago, but since commit 
bcc53bf095893fbdae531a9a7b5d4ef4a125a7fc it comes out visible.


I think we have to check every those warning for correct alignment.

cheers,
Hannes

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

Re: [U-Boot] A command to discard saved environments?

[Wolfgang Denk]

Dear James,

In message  you wrote:
> I know my non-volatile copy of the environment is in NOR flash so I use 
> the command
> 
> protect all off;erase  +1
> 
> But, of course this is specific to NOR flash.
> 
> I'm not aware of a way to do this in the general case, independent of NV 
> environment storage media and redundancy.

The idea applies to all kinds of persistent storage: just overwrite a
few (4 or more) bytes at the beginning of each copy of the persistent
envrionment.

In your case, you could save the "erase" by overwriting the first 4
bytes (where the CRC32 checksum is stored) with 0x.

> I'd be supportive of having a way to do this.

No, I don't think we want to support this.  The persistent copy of the
environment is a precious resource, and I cannot think of a regular
use case to invalidate this.  If you do, the result is that you will
use the default settings at next boot - and the samve effect can be
acchieved by using "env reset" + "env save" as already recommended.
[The only difference is that you will not see the "invalid CRC, using
the default env" warning then, but I consider this a pro, not a con.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Test everything. Hold on to the good.  - 1 Thessalonians 5:21
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Stefan Agner]

On 2016-08-03 12:08, Simon Glass wrote:
> Hi Fabio,
> 
> On 3 August 2016 at 12:44, Fabio Estevam  wrote:
>> Hi Simon,
>>
>> On Wed, Aug 3, 2016 at 3:35 PM, Simon Glass  wrote:
>>
>>> Actually I think these are bugs and should be fixed. In this case,
>>> from what I can tell netboot_common() should cache-align the size in
>>> the call to:
>>>
>>> /* flush cache */
>>> flush_cache(load_addr, size);
>>
>> Do you mean like this?
>>
>> --- a/cmd/net.c
>> +++ b/cmd/net.c
>> @@ -244,6 +244,8 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
>> *cmd
>> }
>>
>> /* flush cache */
>> +   load_addr &= ~(CONFIG_SYS_CACHELINE_SIZE - 1);
>> +   size = ALIGN(size, CONFIG_SYS_CACHELINE_SIZE);
>> flush_cache(load_addr, size);
>>
>> bootstage_mark(BOOTSTAGE_ID_NET_LOADED);
>>
>> This makes the net warnings go away.
>>
>> There is still this one that I am seeing:
>>
>> Kernel image @ 0x8080 [ 0x00 - 0x6fea70 ]
>> ## Flattened Device Tree blob at 8300
>>Booting using the fdt blob at 0x8300
>>Using Device Tree in place at 8300, end 83009c5d
>>
>> Starting kernel ...
>>
>> CACHE: Misaligned operation at range [0090, 00900529]
>> [0.00] Booting Linux on physical CPU 0x0
>>
>> Any ideas where it may come from?
> 
> Not really...maybe boot_ramdisk_high()?
> 
> It's clearly pretty late in the process.

That looks like a SRAM address, and it is used for the secure stuff for
instance (CONFIG_ARMV7_SECURE_BASE).

I bet its from relocate_secure_section in arch/arm/cpu/armv7/virt-v7.c.

Will send out a patch for that.

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

[U-Boot] [PATCH] armv8: ls2080a: Remove debug server support

[York Sun]

Debug server feature has been dropped from roadmap.

Signed-off-by: York Sun 
---

 README |   6 -
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   5 -
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |   9 -
 board/freescale/ls2080a/ls2080a.c  |   5 -
 board/freescale/ls2080aqds/ls2080aqds.c|   4 -
 board/freescale/ls2080ardb/ls2080ardb.c|   4 -
 drivers/misc/Makefile  |   1 -
 drivers/misc/fsl_debug_server.c| 250 -
 include/configs/ls2080a_common.h   |   8 +-
 include/fsl_debug_server.h |  32 ---
 10 files changed, 1 insertion(+), 323 deletions(-)
 delete mode 100644 drivers/misc/fsl_debug_server.c
 delete mode 100644 include/fsl_debug_server.h

diff --git a/README b/README
index cadb571..37c19c6 100644
--- a/README
+++ b/README
@@ -4946,12 +4946,6 @@ The Freescale Layerscape Debug Server Support supports 
the loading of
 "Debug Server firmware" and triggering SP boot-rom.
 This firmware often needs to be loaded during U-Boot booting.
 
-- CONFIG_FSL_DEBUG_SERVER
-   Enable the Debug Server for Layerscape SoCs.
-
-- CONFIG_SYS_DEBUG_SERVER_DRAM_BLOCK_MIN_SIZE
-   Define minimum DDR size required for debug server image
-
 - CONFIG_SYS_MC_RSV_MEM_ALIGN
Define alignment of reserved memory MC requires
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index e12b773..5fbd848 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -18,7 +18,6 @@
 #include 
 #endif
 #include 
-#include 
 #include 
 #ifdef CONFIG_FSL_ESDHC
 #include 
@@ -457,10 +456,6 @@ phys_size_t board_reserve_ram_top(phys_size_t ram_size)
 #ifdef CONFIG_SYS_MEM_TOP_HIDE
 #error CONFIG_SYS_MEM_TOP_HIDE not to be used together with this function
 #endif
-/* Carve the Debug Server private DRAM block from the end of DRAM */
-#ifdef CONFIG_FSL_DEBUG_SERVER
-   ram_top -= debug_server_get_dram_block_size();
-#endif
 
 /* Carve the MC private DRAM block from the end of DRAM */
 #ifdef CONFIG_FSL_MC_ENET
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 93e26c1..7acba27 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -33,15 +33,6 @@
 #define CONFIG_SYS_FSL_WRIOP1_MDIO2(CONFIG_SYS_FSL_WRIOP1_ADDR + 0x17000)
 #define CONFIG_SYS_FSL_LSCH3_SERDES_ADDR   (CONFIG_SYS_IMMR + 0xEA)
 
-/* SP (Cortex-A5) related */
-#define CONFIG_SYS_FSL_SP_ADDR (CONFIG_SYS_IMMR + 0x00F0)
-#define CONFIG_SYS_FSL_SP_VSG_GIC_ADDR (CONFIG_SYS_FSL_SP_ADDR)
-#define CONFIG_SYS_FSL_SP_VSG_GIC_VIGR1(CONFIG_SYS_FSL_SP_ADDR)
-#define CONFIG_SYS_FSL_SP_VSG_GIC_VIGR2\
-   (CONFIG_SYS_FSL_SP_ADDR + 0x0008)
-#define CONFIG_SYS_FSL_SP_LOOPBACK_DUART   \
-   (CONFIG_SYS_FSL_SP_ADDR + 0x1000)
-
 #define CONFIG_SYS_FSL_DCSR_DDR_ADDR   0x70012c000ULL
 #define CONFIG_SYS_FSL_DCSR_DDR2_ADDR  0x70012d000ULL
 #define CONFIG_SYS_FSL_DCSR_DDR3_ADDR  0x700132000ULL
diff --git a/board/freescale/ls2080a/ls2080a.c 
b/board/freescale/ls2080a/ls2080a.c
index 00337d7..d0a88d4 100644
--- a/board/freescale/ls2080a/ls2080a.c
+++ b/board/freescale/ls2080a/ls2080a.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -60,10 +59,6 @@ int dram_init(void)
 #if defined(CONFIG_ARCH_MISC_INIT)
 int arch_misc_init(void)
 {
-#ifdef CONFIG_FSL_DEBUG_SERVER
-   debug_server_init();
-#endif
-
return 0;
 }
 #endif
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c 
b/board/freescale/ls2080aqds/ls2080aqds.c
index 7d95deb..ca4a2e5 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -265,9 +264,6 @@ int dram_init(void)
 #if defined(CONFIG_ARCH_MISC_INIT)
 int arch_misc_init(void)
 {
-#ifdef CONFIG_FSL_DEBUG_SERVER
-   debug_server_init();
-#endif
 #ifdef CONFIG_FSL_CAAM
sec_init();
 #endif
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index a65cd4a..7d8a711 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -229,9 +228,6 @@ int dram_init(void)
 #if defined(CONFIG_ARCH_MISC_INIT)
 int arch_misc_init(void)
 {
-#ifdef CONFIG_FSL_DEBUG_SERVER
-   debug_server_init();
-#endif
 #ifdef CONFIG_FSL_CAAM
sec_init();
 #endif
diff --git a/drivers/misc/Makefile 

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Stefan Agner]

On 2016-08-03 11:44, Fabio Estevam wrote:
> Hi Simon,
> 
> On Wed, Aug 3, 2016 at 3:35 PM, Simon Glass  wrote:
> 
>> Actually I think these are bugs and should be fixed. In this case,

I am completely with you Simon!

check_cache_range return 0, which actually leads to the cache operation
not being executed at all! Depending on the situation this can be quite
catastrophic...


>> from what I can tell netboot_common() should cache-align the size in
>> the call to:
>>
>> /* flush cache */
>> flush_cache(load_addr, size);
> 
> Do you mean like this?
> 
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -244,6 +244,8 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
> *cmd
> }
> 
> /* flush cache */
> +   load_addr &= ~(CONFIG_SYS_CACHELINE_SIZE - 1);
> +   size = ALIGN(size, CONFIG_SYS_CACHELINE_SIZE);
> flush_cache(load_addr, size);
> 
> bootstage_mark(BOOTSTAGE_ID_NET_LOADED);
> 
> This makes the net warnings go away.

Yes, see my patch too.
https://patchwork.ozlabs.org/patch/654585/

So up until now, that stuff did not get flushed whenever the file size
was not cache line aligned, and nobody noticed... Is that cache flush
necessary at all?


> 
> There is still this one that I am seeing:
> 
> Kernel image @ 0x8080 [ 0x00 - 0x6fea70 ]
> ## Flattened Device Tree blob at 8300
>Booting using the fdt blob at 0x8300
>Using Device Tree in place at 8300, end 83009c5d
> 
> Starting kernel ...
> 
> CACHE: Misaligned operation at range [0090, 00900529]
> [0.00] Booting Linux on physical CPU 0x0
> 
> Any ideas where it may come from?

I did not had that one on i.MX 7

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

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Simon Glass]

Hi Fabio,

On 3 August 2016 at 12:44, Fabio Estevam  wrote:
> Hi Simon,
>
> On Wed, Aug 3, 2016 at 3:35 PM, Simon Glass  wrote:
>
>> Actually I think these are bugs and should be fixed. In this case,
>> from what I can tell netboot_common() should cache-align the size in
>> the call to:
>>
>> /* flush cache */
>> flush_cache(load_addr, size);
>
> Do you mean like this?
>
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -244,6 +244,8 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
> *cmd
> }
>
> /* flush cache */
> +   load_addr &= ~(CONFIG_SYS_CACHELINE_SIZE - 1);
> +   size = ALIGN(size, CONFIG_SYS_CACHELINE_SIZE);
> flush_cache(load_addr, size);
>
> bootstage_mark(BOOTSTAGE_ID_NET_LOADED);
>
> This makes the net warnings go away.
>
> There is still this one that I am seeing:
>
> Kernel image @ 0x8080 [ 0x00 - 0x6fea70 ]
> ## Flattened Device Tree blob at 8300
>Booting using the fdt blob at 0x8300
>Using Device Tree in place at 8300, end 83009c5d
>
> Starting kernel ...
>
> CACHE: Misaligned operation at range [0090, 00900529]
> [0.00] Booting Linux on physical CPU 0x0
>
> Any ideas where it may come from?

Not really...maybe boot_ramdisk_high()?

It's clearly pretty late in the process.

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

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Fabio Estevam]

Hi Simon,

On Wed, Aug 3, 2016 at 3:35 PM, Simon Glass  wrote:

> Actually I think these are bugs and should be fixed. In this case,
> from what I can tell netboot_common() should cache-align the size in
> the call to:
>
> /* flush cache */
> flush_cache(load_addr, size);

Do you mean like this?

--- a/cmd/net.c
+++ b/cmd/net.c
@@ -244,6 +244,8 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t *cmd
}

/* flush cache */
+   load_addr &= ~(CONFIG_SYS_CACHELINE_SIZE - 1);
+   size = ALIGN(size, CONFIG_SYS_CACHELINE_SIZE);
flush_cache(load_addr, size);

bootstage_mark(BOOTSTAGE_ID_NET_LOADED);

This makes the net warnings go away.

There is still this one that I am seeing:

Kernel image @ 0x8080 [ 0x00 - 0x6fea70 ]
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
   Using Device Tree in place at 8300, end 83009c5d

Starting kernel ...

CACHE: Misaligned operation at range [0090, 00900529]
[0.00] Booting Linux on physical CPU 0x0

Any ideas where it may come from?

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

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Simon Glass]

Hi,

On 3 August 2016 at 12:29, Fabio Estevam  wrote:
> Hi Tom,
>
> On Wed, Aug 3, 2016 at 3:09 PM, Tom Rini  wrote:
>
>> I feel like we must have done something wrong of late, can you bisect
>> when these came in?  Thanks!
>
> This cache warnings start to appear since commit:
>
> commit bcc53bf095893fbdae531a9a7b5d4ef4a125a7fc
> Author: Simon Glass 
> Date:   Sun Jun 19 19:43:05 2016 -0600
>
> arm: Show cache warnings in U-Boot proper only
>
> Avoid bloating the SPL image size.
>
> Signed-off-by: Simon Glass 
>
> Prior to this commit the cache warnings would be printed only with
> DEBUG enabled. Now they are always enabled when we build a non-spl
> target.
>
> We could restore the original behavior and also keep Simon's intention
> of not bloating the SPL image size with the following change:
>
> --- a/arch/arm/lib/cache.c
> +++ b/arch/arm/lib/cache.c
> @@ -60,10 +60,11 @@ int check_cache_range(unsigned long start, unsigned long 
> sto
> if (stop & (CONFIG_SYS_CACHELINE_SIZE - 1))
> ok = 0;
>
> -   if (!ok) {
> -   warn_non_spl("CACHE: Misaligned operation at range [%08lx, 
> %08lx
> -start, stop);
> -   }
> +#ifndef CONFIG_SPL_BUILD
> +   if (!ok)
> +   debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
> + start, stop);
> +#endif
>
> return ok;
>  }
>
> If this looks OK, I can submit a formal patch.

Actually I think these are bugs and should be fixed. In this case,
from what I can tell netboot_common() should cache-align the size in
the call to:

/* flush cache */
flush_cache(load_addr, size);

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

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Fabio Estevam]

Hi Tom,

On Wed, Aug 3, 2016 at 3:09 PM, Tom Rini  wrote:

> I feel like we must have done something wrong of late, can you bisect
> when these came in?  Thanks!

This cache warnings start to appear since commit:

commit bcc53bf095893fbdae531a9a7b5d4ef4a125a7fc
Author: Simon Glass 
Date:   Sun Jun 19 19:43:05 2016 -0600

arm: Show cache warnings in U-Boot proper only

Avoid bloating the SPL image size.

Signed-off-by: Simon Glass 

Prior to this commit the cache warnings would be printed only with
DEBUG enabled. Now they are always enabled when we build a non-spl
target.

We could restore the original behavior and also keep Simon's intention
of not bloating the SPL image size with the following change:

--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -60,10 +60,11 @@ int check_cache_range(unsigned long start, unsigned long sto
if (stop & (CONFIG_SYS_CACHELINE_SIZE - 1))
ok = 0;

-   if (!ok) {
-   warn_non_spl("CACHE: Misaligned operation at range [%08lx, %08lx
-start, stop);
-   }
+#ifndef CONFIG_SPL_BUILD
+   if (!ok)
+   debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
+ start, stop);
+#endif

return ok;
 }

If this looks OK, I can submit a formal patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Tom Rini]

On Wed, Aug 03, 2016 at 02:39:47PM -0300, Fabio Estevam wrote:
> On Wed, Aug 3, 2016 at 1:13 PM, Stefan Agner  wrote:
> 
> > As you noted, this particular case is due to cache flush of the page
> > table and should be fixed with:
> > arm: cache: always flush cache line size for page table
> 
> Yes, just noticed that on a imx7d-sdb I still get these cache warnings
> even with "arm: cache: always flush cache line size for page table"
> applied:
> 
> 
> Filename 'zImage'.
> Load address: 0x8080
> Loading: #
>  #
>  #
>  #
>  #
>  #
>  #
>  #
>  9.1 MiB/s
> done
> Bytes transferred = 7334512 (6fea70 hex)
> CACHE: Misaligned operation at range [8080, 80efea70]

I feel like we must have done something wrong of late, can you bisect
when these came in?  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] [PATCH] net: asix: Fix ASIX 88772B with driver model

[Marcel Ziswiler]

On Wed, 2016-08-03 at 15:51 +0200, Marek Vasut wrote:
> On 08/03/2016 11:46 AM, Alban Bedel wrote:
> > 
> > On Wed, 3 Aug 2016 09:00:42 +0200
> > Marek Vasut  wrote:
> > 
> > > 
> > > On 08/03/2016 07:32 AM, Alban Bedel wrote:
> > > > 
> > > > Commit 147271209a9d ("net: asix: fix operation without eeprom")
> > > > added a special handling for ASIX 88772B that enable another
> > > > type of header. This break the driver in DM mode as the extra
> > > > handling
> > > > needed in the receive path is missing.
> > > So add the extra handling ?
> > I can do that too, but I though u-boot preferred to avoid useless
> > code.
> Yes, if it is useless.
> 
> > 
> > > 
> > > > 
> > > > However this new header mode is not required and only seems to
> > > > increase the code complexity, so this patch revert this part of
> > > > commit 147271209a9d.
> > > Why is it not required ?
> > It works fine without, since 2012. In fact this change is not even
> > mentioned in the log of commit 147271209a9d, so I really don't know
> > why
> > it was added in the first place. As can be seen in the revert all
> > it
> > does is adding 2 bytes to the USB packets that are then just
> > skipped.
> > Seems pretty useless to me.
> I would like to get some feedback on this from Marcel, since he added
> this stuff.

Yes, sorry. I just came back from vacation and started looking into it
now. As far as I remember on our hardware without this Ethernet did not
quite work reliably. This also means that with driver model so far it
does not work for us which I fed back to Simon once but so far this has
not been resolved. That fix came from some early U-Boot work done by
Antmicro way back and I am missing some of the history.

Cheers

Marcel

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

[U-Boot] [PATCH] net: e1000: Allow to use e1000 SPI command with DM

[Yaroslav K.]

Fix compile errors when enabling CONFIG_DM_ETH,
CONFIG_CMD_E1000 and CONFIG_E1000_SPI.

Signed-off-by: Yaroslav K. 
---
 drivers/net/e1000.c |  6 -
 drivers/net/e1000_spi.c | 60 -
 2 files changed, 35 insertions(+), 31 deletions(-)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 196989b..09d6870 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5513,7 +5513,8 @@ static int do_e1000(cmd_tbl_t *cmdtp, int flag,
struct udevice *dev;
char name[30];
int ret;
-#else
+#endif
+#if !defined(CONFIG_DM_ETH) || defined(CONFIG_E1000_SPI)
struct e1000_hw *hw;
 #endif
int cardnum;
@@ -5532,6 +5533,9 @@ static int do_e1000(cmd_tbl_t *cmdtp, int flag,
plat = dev_get_platdata(dev);
mac = plat->enetaddr;
}
+#ifdef CONFIG_E1000_SPI
+   hw = dev_get_priv(dev);
+#endif
 #else
hw = e1000_find_card(cardnum);
if (hw)
diff --git a/drivers/net/e1000_spi.c b/drivers/net/e1000_spi.c
index 576ddb8..78f4f15 100644
--- a/drivers/net/e1000_spi.c
+++ b/drivers/net/e1000_spi.c
@@ -94,29 +94,29 @@ struct spi_slave *spi_setup_slave(unsigned int
bus, unsigned int cs,

/* Make sure it has an SPI chip */
if (hw->eeprom.type != e1000_eeprom_spi) {
-   E1000_ERR(hw->nic, "No attached SPI EEPROM found!\n");
+   E1000_ERR(hw, "No attached SPI EEPROM found!\n");
return NULL;
}

/* Argument sanity checks */
if (cs != 0) {
-   E1000_ERR(hw->nic, "No such SPI chip: %u\n", cs);
+   E1000_ERR(hw, "No such SPI chip: %u\n", cs);
return NULL;
}
if (mode != SPI_MODE_0) {
-   E1000_ERR(hw->nic, "Only SPI MODE-0 is supported!\n");
+   E1000_ERR(hw, "Only SPI MODE-0 is supported!\n");
return NULL;
}

/* TODO: Use max_hz somehow */
-   E1000_DBG(hw->nic, "EEPROM SPI access requested\n");
+   E1000_DBG(hw, "EEPROM SPI access requested\n");
return >spi;
 }

 void spi_free_slave(struct spi_slave *spi)
 {
__maybe_unused struct e1000_hw *hw = e1000_hw_from_spi(spi);
-   E1000_DBG(hw->nic, "EEPROM SPI access released\n");
+   E1000_DBG(hw, "EEPROM SPI access released\n");
 }

 int spi_claim_bus(struct spi_slave *spi)
@@ -124,7 +124,7 @@ int spi_claim_bus(struct spi_slave *spi)
struct e1000_hw *hw = e1000_hw_from_spi(spi);

if (e1000_acquire_eeprom(hw)) {
-   E1000_ERR(hw->nic, "EEPROM SPI cannot be acquired!\n");
+   E1000_ERR(hw, "EEPROM SPI cannot be acquired!\n");
return -1;
}

@@ -342,41 +342,41 @@ static int do_e1000_spi_show(cmd_tbl_t *cmdtp,
struct e1000_hw *hw,

/* Extra sanity checks */
if (!length) {
-   E1000_ERR(hw->nic, "Requested zero-sized dump!\n");
+   E1000_ERR(hw, "Requested zero-sized dump!\n");
return 1;
}
if ((0x1 < length) || (0x1 - length < offset)) {
-   E1000_ERR(hw->nic, "Can't dump past 0x!\n");
+   E1000_ERR(hw, "Can't dump past 0x!\n");
return 1;
}

/* Allocate a buffer to hold stuff */
buffer = malloc(length);
if (!buffer) {
-   E1000_ERR(hw->nic, "Out of Memory!\n");
+   E1000_ERR(hw, "Out of Memory!\n");
return 1;
}

/* Acquire the EEPROM and perform the dump */
if (e1000_acquire_eeprom(hw)) {
-   E1000_ERR(hw->nic, "EEPROM SPI cannot be acquired!\n");
+   E1000_ERR(hw, "EEPROM SPI cannot be acquired!\n");
free(buffer);
return 1;
}
err = e1000_spi_eeprom_dump(hw, buffer, offset, length, true);
e1000_release_eeprom(hw);
if (err) {
-   E1000_ERR(hw->nic, "Interrupted!\n");
+   E1000_ERR(hw, "Interrupted!\n");
free(buffer);
return 1;
}

/* Now hexdump the result */
printf("%s: = Intel e1000 EEPROM (0x%04hX - 0x%04hX) =",
-   hw->nic->name, offset, offset + length - 1);
+   hw->name, offset, offset + length - 1);
for (i = 0; i < length; i++) {
if ((i & 0xF) == 0)
-   printf("\n%s: %04hX: ", hw->nic->name, offset + i);
+   printf("\n%s: %04hX: ", hw->name, offset + i);
else if ((i & 0xF) == 0x8)
printf(" ");
printf(" %02hx", buffer[i]);
@@ -407,29 +407,29 @@ static int do_e1000_spi_dump(cmd_tbl_t *cmdtp,
struct e1000_hw *hw,

/* Extra sanity checks */
if (!length) {
-   E1000_ERR(hw->nic, "Requested zero-sized dump!\n");
+   E1000_ERR(hw, "Requested zero-sized dump!\n");
  

Re: [U-Boot] Regarding source code of u-boot

[Jagan Teki]

On 2 August 2016 at 14:35, kirti kumbhar  wrote:
> Sir,
>  I have download the source of  u-boot,but there is one problem when I
> installing   cross complier there are many dependency of assembly code I
> try to remove it but not working correctly  so,sir please send some command
> or source code.

Did you tried the latest? [1] are you creating cross compiler manually
or took it from sourcery bench? Once you have a proper cross compiler
in your host these are the steps for building

export PATH=/to/cross_compler_patch/../bin:$PATH
export CROSS_COMPILE=arm-none-linux-gnueabi-

$ make *_defconfig; make

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

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] mtd: nand: mxs: fix cache alignment for cache lines >32

[Fabio Estevam]

On Wed, Aug 3, 2016 at 1:13 PM, Stefan Agner  wrote:

> As you noted, this particular case is due to cache flush of the page
> table and should be fixed with:
> arm: cache: always flush cache line size for page table

Yes, just noticed that on a imx7d-sdb I still get these cache warnings
even with "arm: cache: always flush cache line size for page table"
applied:


Filename 'zImage'.
Load address: 0x8080
Loading: #
 #
 #
 #
 #
 #
 #
 #
 9.1 MiB/s
done
Bytes transferred = 7334512 (6fea70 hex)
CACHE: Misaligned operation at range [8080, 80efea70]
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
DHCP client bound to address 10.29.244.54 (356 ms)
Using FEC0 device
TFTP from server 10.29.244.110; our IP address is 10.29.244.54
Filename 'imx7d-sdb.dtb'.
Load address: 0x8300
Loading: ##
 376 KiB/s
done
Bytes transferred = 27742 (6c5e hex)
CACHE: Misaligned operation at range [8300, 83006c5e]
Kernel image @ 0x8080 [ 0x00 - 0x6fea70 ]
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
   Using Device Tree in place at 8300, end 83009c5d

Starting kernel ...

CACHE: Misaligned operation at range [0090, 00900529]
[0.00] Booting Linux on physical CPU 0x0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: socfpga: stratix10: Add SOCFPGA Stratix10 base address

[Chin Liang See]

Add base address header file for Stratix10 SoC

Signed-off-by: Chin Liang See 
Cc: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Ley Foon Tan 
---
 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
index 000..411518d
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2016, Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef _SOCFPGA_S10_BASE_HARDWARE_H_
+#define _SOCFPGA_S10_BASE_HARDWARE_H_
+
+#define SOCFPGA_SMMU_ADDRESS   0xfa00
+#define SOCFPGA_EMAC0_ADDRESS  0xff80
+#define SOCFPGA_EMAC1_ADDRESS  0xff802000
+#define SOCFPGA_EMAC2_ADDRESS  0xff804000
+#define SOCFPGA_SDMMC_ADDRESS  0xff808000
+#define SOCFPGA_USB0_ADDRESS   0xffb0
+#define SOCFPGA_USB1_ADDRESS   0xffb4
+#define SOCFPGA_NANDREGS_ADDRESS   0xffb8
+#define SOCFPGA_NANDDATA_ADDRESS   0xffb9
+#define SOCFPGA_UART0_ADDRESS  0xffc02000
+#define SOCFPGA_UART1_ADDRESS  0xffc02100
+#define SOCFPGA_I2C0_ADDRESS   0xffc02800
+#define SOCFPGA_I2C1_ADDRESS   0xffc02900
+#define SOCFPGA_I2C2_ADDRESS   0xffc02a00
+#define SOCFPGA_I2C3_ADDRESS   0xffc02b00
+#define SOCFPGA_I2C4_ADDRESS   0xffc02c00
+#define SOCFPGA_SPTIMER0_ADDRESS   0xffc03000
+#define SOCFPGA_SPTIMER1_ADDRESS   0xffc03100
+#define SOCFPGA_GPIO0_ADDRESS  0xffc03200
+#define SOCFPGA_GPIO1_ADDRESS  0xffc03300
+#define SOCFPGA_SYSTIMER0_ADDRESS  0xffd0
+#define SOCFPGA_SYSTIMER0_ADDRESS  0xffd00100
+#define SOCFPGA_L4WD0_ADDRESS  0xffd00200
+#define SOCFPGA_L4WD0_ADDRESS  0xffd00300
+#define SOCFPGA_L4WD0_ADDRESS  0xffd00400
+#define SOCFPGA_L4WD0_ADDRESS  0xffd00500
+#define SOCFPGA_CLKMGR_ADDRESS 0xffd1
+#define SOCFPGA_RSTMGR_ADDRESS 0xffd11000
+#define SOCFPGA_SYSMGR_ADDRESS 0xffd12000
+#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS0xffd13000
+#define SOCFPGA_DMANONSECURE_ADDRESS   0xffda
+#define SOCFPGA_DMASECURE_ADDRESS  0xffda1000
+#define SOCFPGA_SPIS0_ADDRESS  0xffda2000
+#define SOCFPGA_SPIS1_ADDRESS  0xffda3000
+#define SOCFPGA_SPIM0_ADDRESS  0xffda4000
+#define SOCFPGA_SPIM1_ADDRESS  0xffda5000
+#define SOCFPGA_OCRAM_ADDRESS  0xffe0
+
+#endif /* _SOCFPGA_S10_BASE_HARDWARE_H_ */
-- 
2.2.2

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

Re: [U-Boot] [PATCH] arm: cache: always flush cache line size for page table

[Fabio Estevam]

On Tue, Aug 2, 2016 at 4:07 AM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> The page table is maintained by the CPU, hence it is safe to always
> align cache flush to a whole cache line size. This allows to use
> mmu_page_table_flush for a single page table, e.g. when configure
> only small regions through mmu_set_region_dcache_behaviour.
>
> Signed-off-by: Stefan Agner 

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

Re: [U-Boot] [PATCH] mtd: nand: mxs: fix cache alignment for cache lines >32

[Stefan Agner]

On 2016-08-03 06:51, Fabio Estevam wrote:
> On Tue, Aug 2, 2016 at 3:55 AM, Stefan Agner  wrote:
>> From: Stefan Agner 
>>
>> Currently the command buffer gets allocated with a size of 32 bytes.
>> This causes warning messages on systems with cache lines bigger than
>> 32 bytes:
>> CACHE: Misaligned operation at range [9df17a00, 9df17a20]
>>
>> Define command buffer to be at least 32 bytes, but more if cache
>> line is bigger.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>> This appeared after Simon enable the message in check_cache_range
>> by default...
> 
> On mx6ul pico I also get similar warnings even though NAND is not used
> on this board:
> 
> U-Boot 2016.09-rc1-00245-gad6a303 (Aug 03 2016 - 10:31:52 -0300)
> 
> CPU:   Freescale i.MX6UL rev1.0 at 396 MHz
> Reset cause: WDOG
> Board: PICO-IMX6UL-EMMC
> I2C:   ready
> DRAM:  256 MiB
> CACHE: Misaligned operation at range [8fff, 8fff0004]
> CACHE: Misaligned operation at range [8fff0024, 8fff0028]
> PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> MMC:   FSL_SDHC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0
> 
> Looks like we need a more generic fix?

As you noted, this particular case is due to cache flush of the page
table and should be fixed with:
arm: cache: always flush cache line size for page table

Afaik, there is no such thing as a generic fix for cache line alignment
issues... Every call site need to make sure to keep data cache line
aligned, especially in case a external device (DMA) are modifying the
same data...

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

Re: [U-Boot] [PATCH v4] nitrogen6x : Use generic distro configuration

[Fabio Estevam]

On Tue, Aug 2, 2016 at 4:31 AM, Fabien Lahoudere
 wrote:

>  #define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_I2C_MXC_I2C1/* enable I2C bus 1 */
> -#define CONFIG_SYS_I2C_MXC_I2C2/* enable I2C bus 2 */
> -#define CONFIG_SYS_I2C_MXC_I2C3/* enable I2C bus 3 */
> +#define CONFIG_SYS_I2C_MXC_I2C1/* enable I2C bus 1 */
> +#define CONFIG_SYS_I2C_MXC_I2C2/* enable I2C bus 2 */
> +#define CONFIG_SYS_I2C_MXC_I2C3/* enable I2C bus 3 */

This change is unrelated and should not be part of this patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] malloc_simple: Add simple malloc free function

[Chin Liang See]

On Wed, 2016-08-03 at 15:57 +0200, Marek Vasut wrote:
> On 08/03/2016 03:41 PM, Chin Liang See wrote:
> > On Wed, 2016-08-03 at 09:53 +0200, Marek Vasut wrote:
> > > On 08/03/2016 09:30 AM, Chin Liang See wrote:
> > > > Hi Marek,
> > > 
> > > Hi,
> > > 
> > > > On Wed, 2016-08-03 at 08:58 +0200, Marek Vasut wrote:
> > > > > On 08/03/2016 05:24 AM, Chin Liang See wrote:
> > > > > > Enable a simple malloc implementation which will minimize
> > > > > > memory usage prior relocation. This is essential as memory
> > > > > > available prior location is internal memory and limited in
> > > > > > size.
> > > > > > 
> > > > > > This implementation will stored last 2 usage of malloc.
> > > > > > When
> > > > > > free is invoked and the free address matched, we shall
> > > > > > revert
> > > > > > to previous value of gd->malloc_ptr that we stored.
> > > > > 
> > > > > This looks unnecessarily convoluted and fragile design.
> > > > > What problem do you observe and on what platform ?
> > > > 
> > > > Actually this for our Arria10 SoC device. In order to get DDR
> > > > working,
> > > > we need to program FPGA. To improve the usability, we put the
> > > > FPGA
> > > > programming file (RBF) into FAT partition.
> > > > 
> > > > In that sense, we would need to use FAT driver prior relocation
> > > > /
> > > > DDR
> > > > available. Due to that, the malloc usage is high and memory
> > > > available
> > > > is limited prior DDR available. 
> > > 
> > > I was under the impression that you have 256kiB of SRAM on the
> > > A10.
> > > SPL should consume about 64 kiB tops, including support for
> > > loading
> > > from VFAT. So you have 192 kiB available, how is that not enough
> > > ?
> > 
> > But I presume we won't want to limit that minimum 256MB of internal
> > memory needed for simple malloc usage, right?
> 
> Err, 256 MiB ? I think 192k of malloc area must be _plenty_ for SPL
> either way you slice it.
> 
> > > 
> > > > The simple malloc helps but without the free, its consumed way
> > > > too
> > > > much
> > > > memory than saving. Hence this simple malloc free patch help.
> > > > So I
> > > > believe this would benefits those who are executing complex
> > > > operation
> > > > prior relocation :) 
> > > 
> > > I believe you need to identify who is calling malloc() to obtain
> > > big
> > > buffers without recycling them.
> > > 
> > 
> > It's the fat driver which is utilizing the malloc.
> 
> So fat is allocating stuff without freeing it ? I wonder if we should
> either fix fat or use full malloc in SPL on A10 . I am not really
> fond
> of adding more stuff into simple malloc (to keep it small and 
> simple).

Actually fat driver is good where it invoke malloc and free during the
operation. Just that with existing malloc, there is no free
implementation and memory keep "push" every time malloc invoked.

> 
> > > Your design breaks in the scenario where someone does big malloc
> > > followed by two small mallocs if I understand it correctly. This
> > > doesn't scale and is a hack.
> > > 
> > 
> > Actually the proposed free is a simple implementation which acts as
> > stack push and pop with depth of 2. This is to enhance existing
> > implementation which don't handle the pop. This get worst
> > especially
> > dealing with fat driver.
> 
> Well, how does it handle my example? It doesn't and it fails to help
> in
> such case, right ?

I was thinking what is the correct depth while trying to keep things
simple. From the FAT access testing with SD and eMMC, depth of 2 works
well by cutting lot of memory consumption by simple malloc
implementation. Any thoughts whether should have more flexibility?

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH] tegra: config: Add 'pci enum' to preboot when PCI is enabled

[Stephen Warren]

On 08/03/2016 03:35 AM, Alban Bedel wrote:

For simplicity and backward compatibility automatically run 'pci enum'
via preboot when PCI is enabled. As preboot is already used for the
USB keyboard support this rework how CONFIG_PREBOOT is set to allow
combining several commands.


For better or worse, this was a deliberate change, so I don't think this 
patch will be accepted.


If it is, then you should apply it to all boards, not just Tegra boards, 
and adjust include/config_distro_bootcmd.h since it will no longer need 
to run "pci enum", and also test/py/tests/test_net.py won't need to either.

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

Re: [U-Boot] [PATCH v1 1/4] usb: host: ehci-vf: Migrate Vybrid USB to driver model

[Marek Vasut]

On 08/03/2016 01:58 PM, Sanchayan Maity wrote:
> Add driver model support for Vybrid USB driver.
> 
> Signed-off-by: Sanchayan Maity 

CCing Lukasz.

> ---
> Hello,
> 
> I am trying to migrate the Vybrid USB driver to driver model.
> Patches are based on top of uboot master branch. With this
> implementation, host works perfectly fine on both USB ports
> but I have problems using it in client mode.
> 
> I tried DFU to test client mode and I get the following
> 
> Colibri VFxx # version
> 
> U-Boot 2016.09-rc1-00235-g4e8c122 (Aug 03 2016 - 17:07:48 +0530)
> arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
> GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10
> Colibri VFxx # dfu 0 nand 4
> using id 'nand0,0'
> using id 'nand0,1'
> using id 'nand0,3'
> g_dnl_register: failed!, error: -19
> data abort
> pc : [<8ff80f18>]  lr : [<8ff612a9>]
> reloc pc : [<3f431f18>]lr : [<3f4122a9>]
> sp : 8fd15000  ip :  fp : 2710
> r10: 8ffb50cc  r9 : 8fd16ee8 r8 : 8ffbc574
> r7 :   r6 :  r5 :   r4 : 
> r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> It seems to return ENODEV from usb_setup_ehci_gadget after calling
> uclass_find_device_by_seq. I am not sure what I am missing in the
> current implementation. Can someone point me in the correct direction?
> Since host works on both ports I would assume the device tree nodes
> are correct.
> 
> Tried to look in documentation and usb-info.txt mentions that gadget
> framework does not use driver model. Does this imply I cannot use
> any usb gadget functionality if I am using USB DM? However the function
> usb_gadget_register_driver in ci_udc.c does have a CONFIG_DM_USB and
> calls into usb_setup_ehci_gadget which is in usb-uclass.c.
> 
> Regards,
> Sanchayan.
> ---
>  drivers/usb/host/ehci-vf.c | 123 
> ++---
>  1 file changed, 117 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
> index 61789dd..8c5c593 100644
> --- a/drivers/usb/host/ehci-vf.c
> +++ b/drivers/usb/host/ehci-vf.c
> @@ -8,6 +8,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -131,6 +132,24 @@ int __weak board_ehci_hcd_init(int port)
>   return 0;
>  }
>  
> +int ehci_vf_common_init(struct usb_ehci *ehci, int index)
> +{
> + int ret;
> +
> + /* Do board specific initialisation */
> + ret = board_ehci_hcd_init(index);
> + if (ret)
> + return ret;
> +
> + usb_power_config(index);
> + usb_oc_config(index);
> + usb_internal_phy_clock_gate(index);
> + usb_phy_enable(index, ehci);
> +
> + return 0;
> +}
> +
> +#ifndef CONFIG_DM_USB
>  int ehci_hcd_init(int index, enum usb_init_type init,
>   struct ehci_hccr **hccr, struct ehci_hcor **hcor)
>  {
> @@ -143,12 +162,9 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>   ehci = (struct usb_ehci *)nc_reg_bases[index];
>  
>   /* Do board specific initialisation */
> - board_ehci_hcd_init(index);
> -
> - usb_power_config(index);
> - usb_oc_config(index);
> - usb_internal_phy_clock_gate(index);
> - usb_phy_enable(index, ehci);
> + ret = ehci_vf_common_init(index);
> + if (ret)
> + return ret;
>  
>   *hccr = (struct ehci_hccr *)((uint32_t)>caplength);
>   *hcor = (struct ehci_hcor *)((uint32_t)*hccr +
> @@ -175,3 +191,98 @@ int ehci_hcd_stop(int index)
>  {
>   return 0;
>  }
> +#else
> +struct ehci_vf_priv_data {
> + struct ehci_ctrl ctrl;
> + struct usb_ehci *ehci;
> + enum usb_init_type init_type;
> + int portnr;
> +};
> +
> +static int vf_init_after_reset(struct ehci_ctrl *dev)
> +{
> + struct ehci_vf_priv_data *priv = dev->priv;
> + enum usb_init_type type = priv->init_type;
> + struct usb_ehci *ehci = priv->ehci;
> + int ret;
> +
> + ret = ehci_vf_common_init(priv->ehci, priv->portnr);
> + if (ret)
> + return ret;
> +
> + if (type == USB_INIT_DEVICE)
> + return 0;
> +
> + setbits_le32(>usbmode, CM_HOST);
> + writel((PORT_PTS_UTMI | PORT_PTS_PTW), >portsc);
> + setbits_le32(>portsc, USB_EN);
> +
> + mdelay(10);
> +
> + return 0;
> +}
> +
> +static const struct ehci_ops vf_ehci_ops = {
> + .init_after_reset = vf_init_after_reset
> +};
> +
> +static int ehci_usb_probe(struct udevice *dev)
> +{
> + struct usb_platdata *plat = dev_get_platdata(dev);
> + struct usb_ehci *ehci = (struct usb_ehci *)dev_get_addr(dev);
> + struct ehci_vf_priv_data *priv = dev_get_priv(dev);
> + struct ehci_hccr *hccr;
> + struct ehci_hcor *hcor;
> + int ret;
> +
> + priv->ehci = ehci;
> + priv->portnr = dev->seq;
> + priv->init_type = plat->init_type;
> +
> + ret = ehci_vf_common_init(ehci, 

Re: [U-Boot] A command to discard saved environments?

[James Chargin]

I know my non-volatile copy of the environment is in NOR flash so I use 
the command


protect all off;erase  +1

But, of course this is specific to NOR flash.

I'm not aware of a way to do this in the general case, independent of NV 
environment storage media and redundancy.


I'd be supportive of having a way to do this.

Jim

On 08/02/2016 08:31 PM, Masahiro Yamada wrote:

Hi.


I am looking for a command
that discards the saved environments,
and takes me back to the
"*** Warning - bad CRC, using default environment" state.


In my case, the environment data is saved
at sector 0x400 of the MMC device on my board.


So, I can just do

 > mmc erase 400 10


But, beforehand, I need to know

CONFIG_ENV_IS_IN_MMC
CONFIG_ENV_OFFSET 0x8

in order to confirm if the above command is doing the right thing.
(If I make a mistake in calculating the offset value,
other data would be damaged.)



Is there a nice command to do that?





--
Jim Chargin
AJA Video Systems   j...@aja.com
(530) 271-3334  http://www.aja.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] malloc_simple: Add simple malloc free function

[Marek Vasut]

On 08/03/2016 03:41 PM, Chin Liang See wrote:
> On Wed, 2016-08-03 at 09:53 +0200, Marek Vasut wrote:
>> On 08/03/2016 09:30 AM, Chin Liang See wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Wed, 2016-08-03 at 08:58 +0200, Marek Vasut wrote:
 On 08/03/2016 05:24 AM, Chin Liang See wrote:
> Enable a simple malloc implementation which will minimize
> memory usage prior relocation. This is essential as memory
> available prior location is internal memory and limited in
> size.
>
> This implementation will stored last 2 usage of malloc. When
> free is invoked and the free address matched, we shall revert
> to previous value of gd->malloc_ptr that we stored.

 This looks unnecessarily convoluted and fragile design.
 What problem do you observe and on what platform ?
>>>
>>> Actually this for our Arria10 SoC device. In order to get DDR
>>> working,
>>> we need to program FPGA. To improve the usability, we put the FPGA
>>> programming file (RBF) into FAT partition.
>>>
>>> In that sense, we would need to use FAT driver prior relocation /
>>> DDR
>>> available. Due to that, the malloc usage is high and memory
>>> available
>>> is limited prior DDR available. 
>>
>> I was under the impression that you have 256kiB of SRAM on the A10.
>> SPL should consume about 64 kiB tops, including support for loading
>> from VFAT. So you have 192 kiB available, how is that not enough ?
> 
> But I presume we won't want to limit that minimum 256MB of internal
> memory needed for simple malloc usage, right?

Err, 256 MiB ? I think 192k of malloc area must be _plenty_ for SPL
either way you slice it.

>>
>>> The simple malloc helps but without the free, its consumed way too
>>> much
>>> memory than saving. Hence this simple malloc free patch help. So I
>>> believe this would benefits those who are executing complex
>>> operation
>>> prior relocation :) 
>>
>> I believe you need to identify who is calling malloc() to obtain big
>> buffers without recycling them.
>>
> 
> It's the fat driver which is utilizing the malloc.

So fat is allocating stuff without freeing it ? I wonder if we should
either fix fat or use full malloc in SPL on A10 . I am not really fond
of adding more stuff into simple malloc (to keep it small and simple).

>> Your design breaks in the scenario where someone does big malloc
>> followed by two small mallocs if I understand it correctly. This
>> doesn't scale and is a hack.
>>
> 
> Actually the proposed free is a simple implementation which acts as
> stack push and pop with depth of 2. This is to enhance existing
> implementation which don't handle the pop. This get worst especially
> dealing with fat driver.

Well, how does it handle my example? It doesn't and it fails to help in
such case, right ?

> Thanks
> Chin Liang
> 
>>> Thanks
>>> Chin Liang
>>>
>>
>>


-- 
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] net: asix: Fix ASIX 88772B with driver model

[Marek Vasut]

On 08/03/2016 11:46 AM, Alban Bedel wrote:
> On Wed, 3 Aug 2016 09:00:42 +0200
> Marek Vasut  wrote:
> 
>> On 08/03/2016 07:32 AM, Alban Bedel wrote:
>>> Commit 147271209a9d ("net: asix: fix operation without eeprom")
>>> added a special handling for ASIX 88772B that enable another
>>> type of header. This break the driver in DM mode as the extra handling
>>> needed in the receive path is missing.
>>
>> So add the extra handling ?
> 
> I can do that too, but I though u-boot preferred to avoid useless code.

Yes, if it is useless.

>>> However this new header mode is not required and only seems to
>>> increase the code complexity, so this patch revert this part of
>>> commit 147271209a9d.
>>
>> Why is it not required ?
> 
> It works fine without, since 2012. In fact this change is not even
> mentioned in the log of commit 147271209a9d, so I really don't know why
> it was added in the first place. As can be seen in the revert all it
> does is adding 2 bytes to the USB packets that are then just skipped.
> Seems pretty useless to me.

I would like to get some feedback on this from Marcel, since he added
this stuff.

> Alban
> 


-- 
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] mtd: nand: mxs: fix cache alignment for cache lines >32

[Fabio Estevam]

On Tue, Aug 2, 2016 at 3:55 AM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> Currently the command buffer gets allocated with a size of 32 bytes.
> This causes warning messages on systems with cache lines bigger than
> 32 bytes:
> CACHE: Misaligned operation at range [9df17a00, 9df17a20]
>
> Define command buffer to be at least 32 bytes, but more if cache
> line is bigger.
>
> Signed-off-by: Stefan Agner 
> ---
> This appeared after Simon enable the message in check_cache_range
> by default...

On mx6ul pico I also get similar warnings even though NAND is not used
on this board:

U-Boot 2016.09-rc1-00245-gad6a303 (Aug 03 2016 - 10:31:52 -0300)

CPU:   Freescale i.MX6UL rev1.0 at 396 MHz
Reset cause: WDOG
Board: PICO-IMX6UL-EMMC
I2C:   ready
DRAM:  256 MiB
CACHE: Misaligned operation at range [8fff, 8fff0004]
CACHE: Misaligned operation at range [8fff0024, 8fff0028]
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0

Looks like we need a more generic fix?

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

Re: [U-Boot] [PATCH] arm: cache: always flush cache line size for page table

[Fabio Estevam]

Hi Stefan,

On Tue, Aug 2, 2016 at 4:07 AM, Stefan Agner  wrote:
> From: Stefan Agner 
>
> The page table is maintained by the CPU, hence it is safe to always
> align cache flush to a whole cache line size. This allows to use
> mmu_page_table_flush for a single page table, e.g. when configure
> only small regions through mmu_set_region_dcache_behaviour.
>
> Signed-off-by: Stefan Agner 
> ---
> This avoids two messages observed on a i.MX 7 based system:
> CACHE: Misaligned operation at range [9fff, 9fff0004]
> CACHE: Misaligned operation at range [9fff0024, 9fff0028]
>
> Those were caused by two calls to mmu_set_region_dcache_behaviour
> in arch/arm/imx-common/cache.c (enable_caches).
>
> Not sure if this is the right way to fix this... Also, we could
> do the alignment in mmu_set_region_dcache_behaviour.

I am also getting similar warnings on a mx6ul pico board:

U-Boot 2016.09-rc1-00245-gad6a303 (Aug 03 2016 - 10:31:52 -0300)

CPU:   Freescale i.MX6UL rev1.0 at 396 MHz
Reset cause: WDOG
Board: PICO-IMX6UL-EMMC
I2C:   ready
DRAM:  256 MiB
CACHE: Misaligned operation at range [8fff, 8fff0004]
CACHE: Misaligned operation at range [8fff0024, 8fff0028]
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0

Applying your patch makes these cache warnings go away.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] malloc_simple: Add simple malloc free function

[Chin Liang See]

On Wed, 2016-08-03 at 09:53 +0200, Marek Vasut wrote:
> On 08/03/2016 09:30 AM, Chin Liang See wrote:
> > Hi Marek,
> 
> Hi,
> 
> > On Wed, 2016-08-03 at 08:58 +0200, Marek Vasut wrote:
> > > On 08/03/2016 05:24 AM, Chin Liang See wrote:
> > > > Enable a simple malloc implementation which will minimize
> > > > memory usage prior relocation. This is essential as memory
> > > > available prior location is internal memory and limited in
> > > > size.
> > > > 
> > > > This implementation will stored last 2 usage of malloc. When
> > > > free is invoked and the free address matched, we shall revert
> > > > to previous value of gd->malloc_ptr that we stored.
> > > 
> > > This looks unnecessarily convoluted and fragile design.
> > > What problem do you observe and on what platform ?
> > 
> > Actually this for our Arria10 SoC device. In order to get DDR
> > working,
> > we need to program FPGA. To improve the usability, we put the FPGA
> > programming file (RBF) into FAT partition.
> > 
> > In that sense, we would need to use FAT driver prior relocation /
> > DDR
> > available. Due to that, the malloc usage is high and memory
> > available
> > is limited prior DDR available. 
> 
> I was under the impression that you have 256kiB of SRAM on the A10.
> SPL should consume about 64 kiB tops, including support for loading
> from VFAT. So you have 192 kiB available, how is that not enough ?

But I presume we won't want to limit that minimum 256MB of internal
memory needed for simple malloc usage, right?

> 
> > The simple malloc helps but without the free, its consumed way too
> > much
> > memory than saving. Hence this simple malloc free patch help. So I
> > believe this would benefits those who are executing complex
> > operation
> > prior relocation :) 
> 
> I believe you need to identify who is calling malloc() to obtain big
> buffers without recycling them.
> 

It's the fat driver which is utilizing the malloc.

> Your design breaks in the scenario where someone does big malloc
> followed by two small mallocs if I understand it correctly. This
> doesn't scale and is a hack.
> 

Actually the proposed free is a simple implementation which acts as
stack push and pop with depth of 2. This is to enhance existing
implementation which don't handle the pop. This get worst especially
dealing with fat driver.

Thanks
Chin Liang

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

Re: [U-Boot] Disable command at runtime

[Wolfgang Denk]

Dear Petr,

In message <201343a2-69c2-6c3e-442b-a228190a8...@elnico.cz> you wrote:
> 
> > attacker?  How could you perform such a "switch" between modes?  By
> > setting some bit somewhere.  And it has to be in some persistent
> > storage.  And the source code of your image is available to the
> > public.  What should prevent an attacker from undoing your bit
> > setting and switching back to "full" mode?
> If it was to be an irreversible switch, a reliable way might be to 
> effectively remove some parts of the program by overwriting them. Not 
> that I ever have done that, perhaps it's not that easy as I imagine, but 
> I believe it's possible.

If you are able to overwrite the code, what would an attacker prevent
from doing the same?  Note that an in-memory modification (life patch)
is sufficient.

> You are absolutely right, whoever has access to U-Boot, can easily 
> destroy the system. The main problem is perhaps in my understanding of 

Not only destroy,  He can take control.

> the concept. I'm always tempted to keep access to U-Boot "for future 
> sakes", but have not found a reliable way to deny the access to the 
> others. Is there a "correct approach"?

If security is an issue, then you should 1) use signed images (with
sufficient hardware support), and 2) prevent the execution of
user-defined, unchecked commands (disable the CLI).

> By the way, once I read in some conversation that bad security is no 
> security, so that's why U-Boot does not implement bad security. From my 
> point of view, bad security (e.g. password stored in env) is strong 
> enough to keep away the amateurs who just want to play with it and don't 
> really know they might destroy the system. Of course it does not secure 
> the system from the really evil attackers, but what does?

As the very first step, you have to define which security level you
need.  Only then you can access which risks are acceptable and which
not.  In general it is a good approach to consider an open CLI
interface in U-Boot as a mighty tool for all kinds of use.

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."   - Doug Gwyn

Same holds for U-Boot...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Never ascribe to malice that which can  adequately  be  explained  by
stupidity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

On Tue, Aug 02, 2016 at 11:42:46PM +, york sun wrote:

> Tom,
> 
> The following changes since commit 26fb8db0f4d1e7c118b5e8f3a8849f359b91c166:
> 
>Merge git://git.denx.de/u-boot-rockchip (2016-07-31 20:31:13 -0400)
> 
> are available in the git repository at:
> 
>git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to ab01ef5fa617444fd95543ee04ea53ccda273269:
> 
>ARMv8/fsl-ppa: Consolidate PPA image stored-media flag for XIP 
> (2016-08-02 09:51:29 -0700)
> 

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