Re: [U-Boot] [PATCH v4 0/9] LS2080ARDB: Enable EFI boot support

[Prabhakar Kushwaha]

Hi Alex,

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Tuesday, June 21, 2016 4:37 AM
> To: u-boot@lists.denx.de
> Cc: york sun ; Prabhakar Kushwaha
> 
> Subject: [PATCH v4 0/9] LS2080ARDB: Enable EFI boot support
> 
> We now have EFI support in U-Boot which worked out of the box on all
> systems that I tried it on so far. Except for the LS2080ARDB. With this patch
> set I can successfully boot grub2 and Linux from there on such a system -
> even using PXE.
> 
> v3 -> v4:
> 
>   - Add CONFIG_CMD_FS_GENERIC to defconfig
>   - Move code into generic quiesce weak function
>   - Exit device for real when going to Linux
>   - Only apply DPL if we have something to apply
>   - New: armv8: ls2080a: Declare spin tables as reserved for efi loader
>   - New: efi_loader: Allow boards to implement get_time and reset_system
>   - New: armv8: fsl-layerscape: Add support for efi_loader RTS reset
>   - New: efi_loader: Declare secure memory as reserved
>   - New: efi_loader: Allow bouncing for network
> 
> Alexander Graf (9):
>   ls2080: Exit dpaa only right before exiting U-Boot
>   efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3
>   ls2080ardb: Reserve DP-DDR RAM
>   ls2080ardb: Convert to distro boot
>   armv8: ls2080a: Declare spin tables as reserved for efi loader
>   efi_loader: Allow boards to implement get_time and reset_system
>   armv8: fsl-layerscape: Add support for efi_loader RTS reset
>   efi_loader: Declare secure memory as reserved
>   efi_loader: Allow bouncing for network
> 
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c  |  33 +-
>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c  |   6 ++
>  arch/arm/include/asm/armv8/mmu.h |  19 +++---
>  arch/arm/include/asm/u-boot-arm.h|   1 +
>  arch/arm/lib/bootm.c |   7 +++
>  board/freescale/ls2080a/ls2080a.c|   6 +-
>  board/freescale/ls2080aqds/ls2080aqds.c  |  11 ++--
> board/freescale/ls2080ardb/ls2080ardb.c  |  20 --
>  cmd/bootefi.c|  15 +
>  configs/ls2080a_emu_defconfig|   1 +
>  configs/ls2080a_simu_defconfig   |   1 +
>  configs/ls2080aqds_SECURE_BOOT_defconfig |   1 +
>  configs/ls2080aqds_defconfig |   1 +
>  configs/ls2080aqds_nand_defconfig|   1 +
>  configs/ls2080ardb_SECURE_BOOT_defconfig |   1 +
>  configs/ls2080ardb_defconfig |   1 +
>  configs/ls2080ardb_nand_defconfig|   1 +
>  drivers/net/fsl-mc/mc.c  |  24 +++-
>  include/configs/ls2080ardb.h |  26 +++-
>  include/efi_loader.h |  18 ++
>  lib/efi_loader/efi_boottime.c|   2 +
>  lib/efi_loader/efi_memory.c  |  15 +
>  lib/efi_loader/efi_net.c |   7 +++
>  lib/efi_loader/efi_runtime.c | 101 +++-
> ---

I am testing your patch set on ls2080ardb. 
Observation:-
1. Linux boot no more crashing with e1000#0, DPMAC5@XSGMII. Even tried with 
default bootcmd. 
2. Grub2 crash while booting :(

I have applied your patch on top of commit " 
9f823615af919c6b89f0b80197f009f78299dcde"

Please find log below.


=> usb start
starting USB...
USB0:   Register 200017f NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   Register 200017f NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
=> edit ethact
edit: DPMAC5@xgmii
=> tftp 0x8000 fsl-ls2080a-rdb.dtb; fdt addr 0x8000; fdt 
boardsetup;tftp 0xa000 grubaa64.efi; bootefi a000 0x8000
Using DPMAC5@xgmii device
TFTP from server 192.168.1.1; our IP address is 192.168.1.34
Filename 'fsl-ls2080a-rdb.dtb'.
Load address: 0x8000
Loading: ###
 2 KiB/s
done
Bytes transferred = 10549 (2935 hex)
WARNING: could not set reg FDT_ERR_NOSPACE.
ERROR: could not set fsl,usb-erratum-a008751 for snps,dwc3: FDT_ERR_NOSPACE.
ERROR: could not set fsl,usb-erratum-a008751 for snps,dwc3: FDT_ERR_NOSPACE.
Using DPMAC5@xgmii device
TFTP from server 192.168.1.1; our IP address is 192.168.1.34
Filename 'grubaa64.efi'.
Load address: 0xa000
Loading: #
 #
 ###
 85.9 KiB/s
done
Bytes transferred = 884224 (d7e00 hex)
## Starting EFI application at 0xa000 ...
Scanning disks on scsi...
Scanning disks on usb...
Scanning disks on mmc...
MMC: no card present
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 4 disks
"Synchronous Abort" handler, esr 0x8a00
ELR: 97ffeee9d5033fdf
LR:  fff03d0c
x0 : fff87250 x1 : fff90720
x2 : 97ffeee9d5033fdf x3 : fff897a0
x4 : 

Re: [U-Boot] [RFC 9/9] ti: omap-common: Update to generate secure FIT

[Masahiro Yamada]

2016-06-21 11:35 GMT+09:00 Andreas Dannenberg :
> Hi Simon,
> thanks for the continued feedback. Comments below...
>
> On Mon, Jun 20, 2016 at 04:40:10PM -0600, Simon Glass wrote:
>> +Masahiro for the Makefile question
>>
>> Hi Andreas,
>>
>> On 17 June 2016 at 10:13, Andreas Dannenberg  wrote:
>> > Hi Simon,
>> > many thanks for your feedback on the series... I know it takes a lot of
>> > effort to digest all that stuff. We'll see how we can tackle the
>> > feedback one by one and send out an updated series.
>> >
>> > Regarding this patch, please see below...
>> >
>> > On Thu, Jun 16, 2016 at 09:52:52PM -0600, Simon Glass wrote:
>> >> Hi Andreas,
>> >>
>> >> On 15 June 2016 at 13:26, Andreas Dannenberg  wrote:
>> >> > From: Daniel Allred 
>> >> >
>> >> > Adds commands so that when a secure device is in use and the SPL is
>> >> > built to load a FIT image (with combined u-boot binary and various
>> >> > DTBs), these components that get fed into the FIT are all processed to
>> >> > be signed/encrypted/etc. as per the operations performed by the
>> >> > secure-binary-image script of the TI SECDEV package.
>> >> >
>> >> > Signed-off-by: Daniel Allred 
>> >> > Signed-off-by: Andreas Dannenberg 
>> >> > ---
>> >> >  arch/arm/cpu/armv7/omap-common/config_secure.mk | 57 
>> >> > -
>> >> >  arch/arm/cpu/armv7/omap5/config.mk  |  3 ++
>> >> >  2 files changed, 58 insertions(+), 2 deletions(-)
>> >>
>> >> Reviewed-by: Simon Glass 
>> >>
>> >> But please can you add a README for this somewhere?
>> >>
>> >> Also, can this tool be added to U-Boot instead of being external?
>> >
>> > Yes we will definitely enhance the readme in the PATCH version, this
>> > wasn't quite ready yet by the time we submitted the RFC.
>> >
>> > Also regarding the external singing/encryption tool this is only
>> > available from TI under NDA after customers engage with TI just like the
>> > high-secure (HS) devices themselves (you can't just buy them on
>> > Digi-Key). Personally I hope that we eventually lower this barrier of
>> > entry (and this has been brought up more than once) but as many things
>> > in the corporate world there is a complex decision process behind it. So
>> > until this strategy changes (if ever) our poor developer's hands are
>> > tied. All we can do for now is trying to allow this external tool to get
>> > hooked into the U-Boot build process in the easiest way possible which
>> > is already done today by way of the $TI_SECURE_DEV_PKG environmental
>> > variable during SPL build.
>>
>> OK. That's odd because it should be the keys that are secure, not the
>> tool! If anything, the tool should have as many eyes on it as
>> possible.
>
> Yes that's the ideal-world case I was also arguing we should follow...
> But as indicated decision processes in the corporate world sometimes are
> complex :)
>
>> >> >
>> >> > diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk 
>> >> > b/arch/arm/cpu/armv7/omap-common/config_secure.mk
>> >> > index c7bb101..c4514ad 100644
>> >> > --- a/arch/arm/cpu/armv7/omap-common/config_secure.mk
>> >> > +++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
>> >> > @@ -12,8 +12,8 @@ cmd_mkomapsecimg = 
>> >> > $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
>> >> > $(if $(KBUILD_VERBOSE:1=), >/dev/null)
>> >> >  else
>> >> >  cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
>> >> > -$(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
>> >> > -$(if $(KBUILD_VERBOSE:1=), >/dev/null)
>> >> > +   $(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
>> >> > +   $(if $(KBUILD_VERBOSE:1=), >/dev/null)
>> >> >  endif
>> >> >  else
>> >> >  cmd_mkomapsecimg = echo "WARNING:" \
>> >> > @@ -25,6 +25,26 @@ cmd_mkomapsecimg = echo "WARNING: TI_SECURE_DEV_PKG 
>> >> > environment" \
>> >> > "variable must be defined for TI secure devices. $@ was NOT 
>> >> > created!"
>> >> >  endif
>> >> >
>> >> > +ifdef CONFIG_SPL_LOAD_FIT
>> >> > +quiet_cmd_omapsecureimg = SECURE  $@
>> >> > +ifneq ($(TI_SECURE_DEV_PKG),)
>> >> > +ifneq ($(wildcard 
>> >> > $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),)
>> >> > +cmd_omapsecureimg = 
>> >> > $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
>> >> > +   $< $@ \
>> >> > +   $(if $(KBUILD_VERBOSE:1=), >/dev/null)
>> >> > +else
>> >> > +cmd_omapsecureimg = echo "WARNING:" \
>> >> > +   "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not 
>> >> > found." \
>> >> > +   "$@ was NOT created!"; cp $< $@
>> >> > +endif
>> >> > +else
>> >> > +cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
>> >> > +   "variable must be defined for TI secure devices." \
>> >> > +   "$@ was NOT created!"; cp $< $@
>> >> > +endif
>> >> > +endif
>> >> > +
>> >> > +
>> >> >  # Standard X-LOADER 

[U-Boot] [PATCH] kbuild: avoid race between dtbs and dt/dt.dtb targets

[Masahiro Yamada]

If the final targets depend on both "dtbs" and "dts/dt.dtb",
and -j option is given to the command line, multiple threads
descend into the dts/ directory, which causes build error.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index d0e7a8a..ad434c7 100644
--- a/Makefile
+++ b/Makefile
@@ -810,7 +810,9 @@ ifeq ($(CONFIG_DM_I2C_COMPAT),y)
 endif
 
 PHONY += dtbs
-dtbs dts/dt.dtb: checkdtc u-boot
+dtbs: dts/dt.dtb
+   @:
+dts/dt.dtb: checkdtc u-boot
$(Q)$(MAKE) $(build)=dts dtbs
 
 quiet_cmd_copy = COPY$@
-- 
1.9.1

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

Re: [U-Boot] [PATCHv6 5/6] ARMv8/PSCI: Fixup the device tree for PSCI

[Zhiqiang Hou]

Hi York,

Thanks for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年6月23日 0:52
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; scottw...@freescale.com;
> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> prabha...@freescale.com; bhupesh.sha...@freescale.com
> Subject: Re: [PATCHv6 5/6] ARMv8/PSCI: Fixup the device tree for PSCI
> 
> On 06/21/2016 08:42 PM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Set the enable-method in the cpu node to PSCI, and create device node
> > for PSCI, when PSCI was enabled.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> > V6:
> >   - Removed PSCI version 0.1 support.
> >
> > V5:
> >   - Moved the weak func sec_firmware_support_psci_version to sec_firmware.c.
> >   - Correct the PSCI version value in switch-case. The right version format 
> > is
> marjor[31:16]:minor[15:0].
> >
> >   arch/arm/cpu/armv8/Makefile |   1 +
> >   arch/arm/cpu/armv8/cpu-dt.c | 122
> 
> >   arch/arm/lib/bootm-fdt.c|   2 +-
> >   3 files changed, 124 insertions(+), 1 deletion(-)
> >   create mode 100644 arch/arm/cpu/armv8/cpu-dt.c
> >
> > diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> > index ee9e009..33e6db0 100644
> > --- a/arch/arm/cpu/armv8/Makefile
> > +++ b/arch/arm/cpu/armv8/Makefile
> > @@ -15,6 +15,7 @@ obj-y += cache.o
> >   obj-y += tlb.o
> >   obj-y += transition.o
> >   obj-y += fwcall.o
> > +obj-y  += cpu-dt.o
> >   obj-$(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o
> > sec_firmware_asm.o
> >
> >   obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/ diff --git
> > a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c new file
> > mode 100644 index 000..6b9aa77
> > --- /dev/null
> > +++ b/arch/arm/cpu/armv8/cpu-dt.c
> > @@ -0,0 +1,122 @@
> > +/*
> > + * Copyright 2016 NXP Semiconductor, Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT #include
> > + #endif
> > +
> > +#ifdef CONFIG_MP
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#if defined(CONFIG_ARMV8_PSCI)
> > +static int cpu_update_dt_psci(void *fdt) {
> > +   int nodeoff;
> > +   unsigned int psci_ver;
> > +   char *psci_compt;
> > +   int tmp;
> > +
> > +   nodeoff = fdt_path_offset(fdt, "/cpus");
> > +   if (nodeoff < 0) {
> > +   printf("couldn't find /cpus\n");
> > +   return nodeoff;
> > +   }
> > +
> > +   /* add 'enable-method = "psci"' to each cpu node */
> > +   for (tmp = fdt_first_subnode(fdt, nodeoff);
> > +tmp >= 0;
> > +tmp = fdt_next_subnode(fdt, tmp)) {
> > +   const struct fdt_property *prop;
> > +   int len;
> > +
> > +   prop = fdt_get_property(fdt, tmp, "device_type", );
> > +   if (!prop)
> > +   continue;
> > +   if (len < 4)
> > +   continue;
> > +   if (strcmp(prop->data, "cpu"))
> > +   continue;
> > +
> > +   /*
> > +* Not checking rv here, our approach is to skip over errors in
> > +* individual cpu nodes, hopefully some of the nodes are
> > +* processed correctly and those will boot
> > +*/
> > +   fdt_setprop_string(fdt, tmp, "enable-method", "psci");
> > +   }
> > +
> > +   /*
> > +* The PSCI node might be called "/psci" or might be called something
> > +* else but contain either of the compatible strings
> > +* "arm,psci"/"arm,psci-0.2"
> > +*/
> > +   nodeoff = fdt_path_offset(fdt, "/psci");
> > +   if (nodeoff >= 0)
> > +   goto init_psci_node;
> > +
> > +   nodeoff = fdt_node_offset_by_compatible(fdt, -1, "arm,psci");
> > +   if (nodeoff >= 0)
> > +   goto init_psci_node;
> > +
> > +   nodeoff = fdt_node_offset_by_compatible(fdt, -1, "arm,psci-0.2");
> > +   if (nodeoff >= 0)
> > +   goto init_psci_node;
> > +
> > +   nodeoff = fdt_node_offset_by_compatible(fdt, -1, "arm,psci-1.0");
> > +   if (nodeoff >= 0)
> > +   goto init_psci_node;
> > +
> > +   nodeoff = fdt_path_offset(fdt, "/");
> > +   if (nodeoff < 0)
> > +   return nodeoff;
> > +
> > +   nodeoff = fdt_add_subnode(fdt, nodeoff, "psci");
> > +   if (nodeoff < 0)
> > +   return nodeoff;
> > +
> > +init_psci_node:
> > +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> > +   psci_ver = sec_firmware_support_psci_version();
> > +#endif
> > +   switch (psci_ver) {
> > +   case 0x0001:
> > +   psci_compt = "arm,psci-1.0";
> > +   break;
> > +   case 0x0002:
> > +   psci_compt = "arm,psci-0.2";
> > +   break;
> > +   default:
> > +   psci_compt = "arm,psci-0.2";
> > +   break;
> > +   }
> > +
> > +   tmp = fdt_setprop_string(fdt, nodeoff, "compatible", 

Re: [U-Boot] [PATCHv6 2/6] ARMv8: add the secure monitor firmware framework

[Zhiqiang Hou]

Hi York,

Thanks for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年6月23日 0:11
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; scottw...@freescale.com;
> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> prabha...@freescale.com; bhupesh.sha...@freescale.com
> Subject: Re: [PATCHv6 2/6] ARMv8: add the secure monitor firmware framework
> 
> On 06/21/2016 08:42 PM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > This framework is introduced for ARMv8 secure monitor mode firmware.
> > The main functions of the framework are, on EL3, verify the firmware,
> > load it to the secure memory and jump into it, and while it returned
> > to U-Boot, do some necessary setups at the 'target exception level'
> > that is determined by the respective secure firmware.
> >
> > So far, the framework support only FIT format image, and need to
> > define the name of which config node should be used in
> > 'configurations' and the name of property for the raw secure firmware image 
> > in
> that config.
> > The FIT image should be stored in Byte accessing memory, such as NOR
> > Flash, or else it should be copied to main memory to use this framework.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> > V6:
> >   - Abstracted more code from PPA to this framework.
> >   - Introduced gd->sec_firmware to hold the load address.
> >   - Refactor the func sec_firmware_support_psci_version().
> 
> A lot of change in this version.

Yes, take a lot time to refactor the code, just hope more code can be reused.

> >
> > V5:
> >   - Added c file sec_firmware.c.
> >   - Added declaration of sec_firmware_init().
> >   - Renamed the func sec_firmware_validate().
> >
> > V4:
> >   - Reordered this patch.
> >   - Removed the FSL PPA related items.
> >
> >   arch/arm/cpu/armv8/Makefile   |   1 +
> >   arch/arm/cpu/armv8/sec_firmware.c | 262
> ++
> >   arch/arm/cpu/armv8/sec_firmware_asm.S |  53 ++
> >   arch/arm/include/asm/armv8/sec_firmware.h |  18 ++
> >   include/asm-generic/global_data.h |  11 ++
> >   5 files changed, 346 insertions(+)
> >   create mode 100644 arch/arm/cpu/armv8/sec_firmware.c
> >   create mode 100644 arch/arm/cpu/armv8/sec_firmware_asm.S
> >   create mode 100644 arch/arm/include/asm/armv8/sec_firmware.h
> >
> > diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> > index bf8644c..ee9e009 100644
> > --- a/arch/arm/cpu/armv8/Makefile
> > +++ b/arch/arm/cpu/armv8/Makefile
> > @@ -15,6 +15,7 @@ obj-y += cache.o
> >   obj-y += tlb.o
> >   obj-y += transition.o
> >   obj-y += fwcall.o
> > +obj-$(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o
> > +sec_firmware_asm.o
> >
> >   obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
> >   obj-$(CONFIG_S32V234) += s32v234/
> > diff --git a/arch/arm/cpu/armv8/sec_firmware.c
> > b/arch/arm/cpu/armv8/sec_firmware.c
> > new file mode 100644
> > index 000..986df48
> > --- /dev/null
> > +++ b/arch/arm/cpu/armv8/sec_firmware.c
> > @@ -0,0 +1,266 @@
> > +/*
> > + * Copyright 2016 NXP Semiconductor, Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +extern void c_runtime_cpu_setup(void);
> > +
> > +static int sec_firmware_get_data(void *sec_firmware_img,
> > +   const void **data, size_t *size)
> 
> Throughout this patch, sec_firmware_img is used as read-only. How about add
> "const" to it?

Yes, will add it next version.

> 
> > +{
> > +   void *fit_hdr;
> 
> Variable fit_hdr doesn't serve more purpose. You can use sec_firmware_img
> directly.

Yes, will fix it next version. 

> 
> > +   int conf_node_off, fw_node_off;
> > +   char *conf_node_name = NULL;
> > +   char *desc;
> > +   int ret;
> > +
> > +   fit_hdr = sec_firmware_img;
> > +   conf_node_name = SEC_FIRMEWARE_FIT_CNF_NAME;
> > +
> > +   conf_node_off = fit_conf_get_node(fit_hdr, conf_node_name);
> > +   if (conf_node_off < 0) {
> > +   printf("SEC Firmware: %s: no such config\n", conf_node_name);
> > +   return -ENOENT;
> > +   }
> > +
> > +   fw_node_off = fit_conf_get_prop_node(fit_hdr, conf_node_off,
> > +   SEC_FIRMWARE_FIT_IMAGE);
> > +   if (fw_node_off < 0) {
> > +   printf("SEC Firmware: No '%s' in config\n",
> > +   SEC_FIRMWARE_FIT_IMAGE);
> 
> You have many of this alignment issues throughout this patch.
> 

Will fix the alignment issues next version.

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

Re: [U-Boot] [PATCHv6 3/6] ARMv8/layerscape: Add FSL PPA support

[Zhiqiang Hou]

Hi York,

Thanks for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年6月23日 0:13
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; scottw...@freescale.com;
> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> prabha...@freescale.com; bhupesh.sha...@freescale.com
> Subject: Re: [PATCHv6 3/6] ARMv8/layerscape: Add FSL PPA support
> 
> On 06/21/2016 08:41 PM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The FSL Primary Protected Application (PPA) is a software component
> > loaded during boot which runs in TrustZone and remains resident after
> > boot.
> >
> > Use the secure firmware framework to integrate FSL PPA into U-Boot.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> > V6:
> >   - Use the secure firmware framework to integrate PPA.
> >
> > V5:
> >   - Added API sec_firmware_init() implementation.
> >
> > V4:
> >   - Moved secure firmware validation API to this patch.
> >   - Moved secure firmware getting supported PSCI version API to this patch.
> >
> > V3:
> >   - Refactor the code.
> >   - Add PPA firmware version info output.
> >
> >   arch/arm/cpu/armv8/fsl-layerscape/Makefile |  1 +
> >   arch/arm/cpu/armv8/fsl-layerscape/ppa.c| 48
> ++
> >   arch/arm/include/asm/arch-fsl-layerscape/ppa.h | 16 +
> >   arch/arm/include/asm/armv8/sec_firmware.h  |  4 +++
> >   4 files changed, 69 insertions(+)
> >   create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> >   create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/ppa.h
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > index eb2cbc3..bcf6b48 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> > @@ -10,6 +10,7 @@ obj-y += soc.o
> >   obj-$(CONFIG_MP) += mp.o
> >   obj-$(CONFIG_OF_LIBFDT) += fdt.o
> >   obj-$(CONFIG_SPL) += spl.o
> > +obj-$(CONFIG_FSL_LS_PPA) += ppa.o
> >
> >   ifneq ($(CONFIG_FSL_LSCH3),)
> >   obj-y += fsl_lsch3_speed.o
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > new file mode 100644
> > index 000..ae7d364
> > --- /dev/null
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > @@ -0,0 +1,48 @@
> > +/*
> > + * Copyright 2016 NXP Semiconductor, Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#ifdef CONFIG_FSL_LSCH3
> > +#include 
> > +#elif defined(CONFIG_FSL_LSCH2)
> > +#include 
> > +#endif
> > +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT #include
> > + #endif
> > +
> > +int ppa_init(void)
> > +{
> > +   void *ppa_fit_addr;
> > +   u32 *boot_loc_ptr_l, *boot_loc_ptr_h;
> > +   int ret;
> > +
> > +#ifdef CONFIG_SYS_LS_PPA_FW_IN_NOR
> > +   ppa_fit_addr = (void *)CONFIG_SYS_LS_PPA_FW_ADDR; #else #error "No
> > +CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
> > +#endif
> > +
> > +#ifdef CONFIG_FSL_LSCH3
> > +   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
> > +   boot_loc_ptr_l = >bootlocptrl;
> > +   boot_loc_ptr_h = >bootlocptrh;
> > +#elif defined(CONFIG_FSL_LSCH2)
> > +   struct ccsr_scfg __iomem *scfg = (void *)(CONFIG_SYS_FSL_SCFG_ADDR);
> > +   boot_loc_ptr_l = >scratchrw[1];
> > +   boot_loc_ptr_h = >scratchrw[0]; #endif
> > +
> > +   debug("fsl-ppa: boot_loc_ptr_l = 0x%p, boot_loc_ptr_h =0x%p\n",
> > +   boot_loc_ptr_l, boot_loc_ptr_h);
> 
> Alignment issue. Didn't checkpatch remind you about this?

Will fix it.

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

Re: [U-Boot] [PATCHv6 4/6] ARMv8/Layerscape: switch SMP method accordingly

[Zhiqiang Hou]

Hi York,

Thanks for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年6月23日 0:22
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; scottw...@freescale.com;
> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> prabha...@freescale.com; bhupesh.sha...@freescale.com
> Subject: Re: [PATCHv6 4/6] ARMv8/Layerscape: switch SMP method accordingly
> 
> On 06/21/2016 08:45 PM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > If the PSCI and PPA is ready, skip the fixup for spin-table and waking
> > secondary cores. Otherwise, change SMP method to spin-table, and the
> > device node of PSCI will be removed.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> > V6:
> >   - no change
> >
> > V5:
> >   - Changed the checking if the PSCI feature is ready to read the psci 
> > version.
> >
> > V4:
> >   - Reordered this patch.
> >
> >   arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 17 ++---
> >   arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 34
> +
> >   2 files changed, 48 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > index d5bcf67..f284b77 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > @@ -23,6 +23,9 @@
> >   #ifdef CONFIG_FSL_ESDHC
> >   #include 
> >   #endif
> > +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT #include
> > + #endif
> >
> >   DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -622,6 +625,7 @@ int arch_early_init_r(void)
> >   {
> >   #ifdef CONFIG_MP
> > int rv = 1;
> > +   bool psci_support = false;
> >   #endif
> >
> >   #ifdef CONFIG_SYS_FSL_ERRATUM_A009635 @@ -629,9 +633,16 @@ int
> > arch_early_init_r(void)
> >   #endif
> >
> >   #ifdef CONFIG_MP
> > -   rv = fsl_layerscape_wake_seconday_cores();
> > -   if (rv)
> > -   printf("Did not wake secondary cores\n");
> > +#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) &&
> defined(CONFIG_ARMV8_PSCI)
> > +   /* Check the psci version to determine if the psci is supported */
> > +   psci_support = sec_firmware_support_psci_version() != 0x ?
> > +   true : false;
> 
> If the only error code is 0x, you can delete the "? true :
> false" part. The logical operation results "true" or "false" already.
> 

Yes, will fix it.

> > +#endif
> > +   if (!psci_support) {
> > +   rv = fsl_layerscape_wake_seconday_cores();
> > +   if (rv)
> > +   printf("Did not wake secondary cores\n");
> > +   }
> >   #endif
> 
> 

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

Re: [U-Boot] [PATCHv6 2/6] ARMv8: add the secure monitor firmware framework

[Zhiqiang Hou]

Hi York,

Thanks for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年6月23日 0:20
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; scottw...@freescale.com;
> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> prabha...@freescale.com; bhupesh.sha...@freescale.com
> Subject: Re: [PATCHv6 2/6] ARMv8: add the secure monitor firmware framework
> 
> On 06/21/2016 08:42 PM, Zhiqiang Hou wrote:
> 
> 
> 
> > +
> > +#ifdef CONFIG_ARMV8_PSCI
> > +/*
> > + * The PSCI_VERSION function is added from PSCI v0.2. When the PSCI
> > + * v0.1 received this function, the NOT_SUPPORTED (0x_) error
> > + * number will be returned according to SMC Calling Conventions. But
> > + * when getting the NOT_SUPPORTED error number, we cannot ensure if
> > + * the PSCI version is v0.1 or other error occurred. So, PSCI v0.1
> > + * won't be supported by this framework.
> > + * And if the secure firmware isn't running, return NOT_SUPPORTED.
> > + *
> > + * The return value on success is PSCI version in format
> > + * major[31:16]:minor[15:0].
> > + */
> > +unsigned int sec_firmware_support_psci_version(void)
> > +{
> > +   if (gd->sec_firmware & SEC_FIRMWARE_RUNNING)
> > +   return _sec_firmware_support_psci_version();
> > +
> > +   return 0x;
> > +}
> > +#endif
> 
> Does _sec_firmware_support_psci_version() always return version numbers?
> Any chance it returns an error code?

If the PSCI_VERSION was supported in current PSCI version, it will return the 
version,
otherwise, the SMC will return the value 0x_ to indicate the 
PSCI_VERSION isn't
supported.
There isn't any description for returning error code in the PSCI spec.

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

Re: [U-Boot] [PATCHv6 5/6] ARMv8/PSCI: Fixup the device tree for PSCI

[Zhiqiang Hou]

Hi ChenYu,

Thanks for your comments!

> -Original Message-
> From: Chen-Yu Tsai [mailto:w...@csie.org]
> Sent: 2016年6月22日 12:05
> To: Zhiqiang Hou 
> Cc: U-Boot Mailing List ; Albert ARIBAUD
> ; Scott Wood ;
> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> prabha...@freescale.com; bhupesh.sha...@freescale.com
> Subject: Re: [U-Boot] [PATCHv6 5/6] ARMv8/PSCI: Fixup the device tree for PSCI
> 
> On Wed, Jun 22, 2016 at 11:30 AM, Zhiqiang Hou  wrote:
> > From: Hou Zhiqiang 
> >
> > Set the enable-method in the cpu node to PSCI, and create device node
> > for PSCI, when PSCI was enabled.
> 
> ARMv7 also has a similar function. Is it possible to move that one under
> arch/arm(/common)?
> 

Yes, that could be arranged.

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

Re: [U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks

[Matthew Bright]

On 06/23/2016 01:02 AM, Marek Vasut wrote:
>
>On 06/22/2016 08:36 AM, Rajesh Bhagat wrote:
>> 
>> From: Matthew Bright [mailto:matthew.bri...@alliedtelesis.co.nz] 
>> Sent: Wednesday, June 22, 2016 11:42 AM
>> To: Rajesh Bhagat ; ma...@denx.de
>> Cc: u-boot@lists.denx.de; Chris Packham ; 
>> Mark Tomlinson 
>> Subject: testing: [PATCH v7 0/3] common: usb_storage: Implement logic to 
>> calculate optimal usb maximum trasfer blocks
>> 
>> On 06/16/2016 12:35 PM, Rajesh Bhagat wrote:
>>> Performs code cleanup by making common function for usb_stor_read/write
>>> and implements the logic to calculate the optimal usb maximum trasfer blocks
>>> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
>>> of EHCI and other USB protocols respectively.
>>>  
>>> Rajesh Bhagat (3):
>>>   common: usb_storage: Make common function for usb_read_10/usb_write_10
>>>   common: usb_storage: Make common function for
>>> usb_stor_read/usb_stor_write
>>>   common: usb_storage : Implement logic to calculate optimal usb maximum
>>> trasfer blocks
>>>  
>>>  common/usb_storage.c | 213 
>>> +++
>>>  include/usb.h|   1 +
>>>  2 files changed, 98 insertions(+), 116 deletions(-)
>>>  
>>>
>>> Hi Rajesh & Marek
>>>
>>> I have spend the last couple of days testing these patches on the
>>> v2016.05 release, with an usb mass storage device that is able to
>>> consistently reproduce the USB_MAX_XFER_BLK issue as described in
>>> the "Issue with USB mass storage (thumb drives)" u-boot thread.
>>>
>>> http://lists.denx.de/pipermail/u-boot/2016-February/244464.html​
>>>
>> 
>> Hello Matt, 
>> 
>>> I can confirm the patch correctly increases the max transfer bocks
>>> after a successful read, and decreases the max transfer bocks after
>>> a read failure. However, I have noticed that once the ehci time out
>>> error occurs, the usb device appears to lock up. When in this state
>>> the usb device will stop responding to any further transfers. This
>>> behavior is independent of the number of blocks, and will continue
>>> until the ehci has been reset.
>>>
>> 
>> I believe the lockup behavior mentioned by you to be device specific quirk. 
>> I tested 3 pen drives, which recovered from EHCI timeout behavior by 
>> reducing the number of blocks (check below output): 
>> 
>
>3 devices is not a representative sample.
>
>-- 
>Best regards,
>Marek Vasut

I agree.

Several others on the u-boot threads have also reported the same ehci
time out issue related to the max transfer blocks. Perhaps we could
kindly ask if they could also test the patch ...

Schrempf Frieder
http://lists.denx.de/pipermail/u-boot/2016-February/244464.html
http://lists.denx.de/pipermail/u-boot/2016-February/245893.html

Hannes Schmelzer (han...@schmelzer.or.at)
http://lists.denx.de/pipermail/u-boot/2016-February/244621.html

Maxime Jayat
http://lists.denx.de/pipermail/u-boot/2016-February/246267.html

Diego
http://lists.denx.de/pipermail/u-boot/2016-April/251799.html

Nicolas Chauvet
http://lists.denx.de/pipermail/u-boot/2016-May/256117.html

As a side note, there appears to be a subtle a difference in the
output when the usb device locks up:

CASE 1: EHCI Time Out - Device Remains Responsive:

=> fatload usb 0 0x1800 test.file
EHCI timed out on TD - token=0x2c008d80
EHCI timed out on TD - token=0xac008d80
EHCI timed out on TD - token=0xac008d80
Error reading cluster
** Unable to read file test.file **
=>

The three time out errors are caused by three attempts to send the
over-sized transfer before giving up.

CASE 2: EHCI Time Out - Device Locks Up:

=> fatload usb 0:auto 0x100 test.rel
reading test.rel
EHCI timed out on TD - token=0x26008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
Error reading cluster
** Unable to read file test.rel **
=>

The additional time out errors are caused because the usb device also
fails to respond to several reset messages after the initial time out;
therefore 

Re: [U-Boot] [PATCH 2/9] spl: fit: add support for post-processing of images

[Masahiro Yamada]

2016-06-21 12:34 GMT+09:00 Andreas Dannenberg :
> From: Daniel Allred 
>
> The next stage boot loader image and the selected FDT can be
> post-processed by board/platform/device-specific code, which can include
> modifying the size and altering the starting source address before
> copying these binary blobs to their final desitination. This might be
> desired to do things like strip headers or footers attached to the
> images before they were packeaged into the FIT, or to perform operations
> such as decryption or authentication.
>
> Signed-off-by: Daniel Allred 
> Signed-off-by: Andreas Dannenberg 
> ---

Typos?

desitination -> destination
packeaged-> packaged


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

Re: [U-Boot] [PATCH] x86: coreboot: Remove the dummy pch driver

[Bin Meng]

Hi Simon,

On Wed, Jun 22, 2016 at 10:36 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 22 June 2016 at 03:30, Bin Meng  wrote:
>> There is a dummy pch driver in the coreboot directory. This causes
>> drivers of its children fail to function due to empty ops. Remove
>> the whole file since it is no longer needed.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/coreboot/Makefile |  1 -
>>  arch/x86/cpu/coreboot/pci.c| 26 --
>>  2 files changed, 27 deletions(-)
>>  delete mode 100644 arch/x86/cpu/coreboot/pci.c
>
> That was intended to support a PCH where U-Boot did not have to set it
> up (when booting from coreboot). Is it not needed now?
>

This is not needed now. The pch7 and pch7 driver are built for
coreboot too so that they can be used.

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

Re: [U-Boot] [RFC PATCH 01/12] imx: mx6: ddr: return output of calibration routines

[Eric Nelson]

On 06/22/2016 04:57 PM, Marek Vasut wrote:
> On 06/23/2016 01:52 AM, Eric Nelson wrote:
>> Hi Marek,
>>
>> On 06/22/2016 04:18 PM, Marek Vasut wrote:
>>> On 06/21/2016 08:41 PM, Eric Nelson wrote:
 Allow the calibration data from mmdc_do_write_level_calibration
 and mmdc_do_dqs_calibration to be returned to the caller for
 display.

 Signed-off-by: Eric Nelson 
>>>
>>> Why don't you create a separate function to read those params ?
>>>
>>
>> Probably because in my implementation, the calibration routine
>> didn't actually write the registers. It was left to the caller
>> to hand them to mx6_dram_cfg.
>>
>> You're right though. A routine to gather calibration data would
>> be simpler and prevent the "if (calibration)" junk in the two
>> routines.
> 
> Try avoiding polluting the code with the if (calib) junk more :)
> 

Will fix in V2 with the addition of a routine to gather the
calibration data.

This will also remove the need for patch 2/12, but the remainder
could still use some review.


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

Re: [U-Boot] [RFC PATCH 01/12] imx: mx6: ddr: return output of calibration routines

[Marek Vasut]

On 06/23/2016 01:52 AM, Eric Nelson wrote:
> Hi Marek,
> 
> On 06/22/2016 04:18 PM, Marek Vasut wrote:
>> On 06/21/2016 08:41 PM, Eric Nelson wrote:
>>> Allow the calibration data from mmdc_do_write_level_calibration
>>> and mmdc_do_dqs_calibration to be returned to the caller for
>>> display.
>>>
>>> Signed-off-by: Eric Nelson 
>>
>> Why don't you create a separate function to read those params ?
>>
> 
> Probably because in my implementation, the calibration routine
> didn't actually write the registers. It was left to the caller
> to hand them to mx6_dram_cfg.
> 
> You're right though. A routine to gather calibration data would
> be simpler and prevent the "if (calibration)" junk in the two
> routines.

Try avoiding polluting the code with the if (calib) junk more :)


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

Re: [U-Boot] [RFC PATCH 01/12] imx: mx6: ddr: return output of calibration routines

[Eric Nelson]

Hi Marek,

On 06/22/2016 04:18 PM, Marek Vasut wrote:
> On 06/21/2016 08:41 PM, Eric Nelson wrote:
>> Allow the calibration data from mmdc_do_write_level_calibration
>> and mmdc_do_dqs_calibration to be returned to the caller for
>> display.
>>
>> Signed-off-by: Eric Nelson 
> 
> Why don't you create a separate function to read those params ?
> 

Probably because in my implementation, the calibration routine
didn't actually write the registers. It was left to the caller
to hand them to mx6_dram_cfg.

You're right though. A routine to gather calibration data would
be simpler and prevent the "if (calibration)" junk in the two
routines.

Regards,


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

Re: [U-Boot] [RFC PATCH 01/12] imx: mx6: ddr: return output of calibration routines

[Marek Vasut]

On 06/21/2016 08:41 PM, Eric Nelson wrote:
> Allow the calibration data from mmdc_do_write_level_calibration
> and mmdc_do_dqs_calibration to be returned to the caller for
> display.
> 
> Signed-off-by: Eric Nelson 

Why don't you create a separate function to read those params ?

> ---
>  arch/arm/cpu/armv7/mx6/ddr.c| 29 +++--
>  arch/arm/include/asm/arch-mx6/mx6-ddr.h |  4 ++--
>  2 files changed, 25 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
> index 1e7ae28..bde6fe3 100644
> --- a/arch/arm/cpu/armv7/mx6/ddr.c
> +++ b/arch/arm/cpu/armv7/mx6/ddr.c
> @@ -86,7 +86,7 @@ static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, 
> u32 *reg_ctrl)
>   writel(val_ctrl, reg_ctrl);
>  }
>  
> -int mmdc_do_write_level_calibration(void)
> +int mmdc_do_write_level_calibration(struct mx6_mmdc_calibration *calib)
>  {
>   struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
>   struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
> @@ -195,10 +195,17 @@ int mmdc_do_write_level_calibration(void)
> readl(>mpwldectrl1));
>  
>   /* We must force a readback of these values, to get them to stick */
> - readl(>mpwldectrl0);
> - readl(>mpwldectrl1);
> - readl(>mpwldectrl0);
> - readl(>mpwldectrl1);
> + if (calib) {
> + calib->p0_mpwldectrl0 = readl(>mpwldectrl0);
> + calib->p0_mpwldectrl1 = readl(>mpwldectrl1);
> + calib->p1_mpwldectrl0 = readl(>mpwldectrl0);
> + calib->p1_mpwldectrl1 = readl(>mpwldectrl1);
> + } else {
> + readl(>mpwldectrl0);
> + readl(>mpwldectrl1);
> + readl(>mpwldectrl0);
> + readl(>mpwldectrl1);
> + }
>  
>   /* enable DDR logic power down timer: */
>   setbits_le32(>mdpdc, 0x5500);
> @@ -212,7 +219,7 @@ int mmdc_do_write_level_calibration(void)
>   return errors;
>  }
>  
> -int mmdc_do_dqs_calibration(void)
> +int mmdc_do_dqs_calibration(struct mx6_mmdc_calibration *calib)
>  {
>   struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
>   struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
> @@ -548,6 +555,16 @@ int mmdc_do_dqs_calibration(void)
>  
>   debug("Final do_dqs_calibration error mask: 0x%x\n", errors);
>  
> + if (calib) {
> + calib->p0_mpdgctrl0 = readl(>mpdgctrl0);
> + calib->p0_mpdgctrl1 = readl(>mpdgctrl1);
> + calib->p1_mpdgctrl0 = readl(>mpdgctrl0);
> + calib->p1_mpdgctrl1 = readl(>mpdgctrl1);
> + calib->p0_mprddlctl = readl(>mprddlctl);
> + calib->p1_mprddlctl = readl(>mprddlctl);
> + calib->p0_mpwrdlctl = readl(>mpwrdlctl);
> + calib->p1_mpwrdlctl = readl(>mpwrdlctl);
> + }
>   return errors;
>  }
>  #endif
> diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
> b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
> index 12c30d2..948862c 100644
> --- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
> +++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
> @@ -457,8 +457,8 @@ void mx6sl_dram_iocfg(unsigned width,
> const struct mx6sl_iomux_grp_regs *);
>  
>  #if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
> -int mmdc_do_write_level_calibration(void);
> -int mmdc_do_dqs_calibration(void);
> +int mmdc_do_write_level_calibration(struct mx6_mmdc_calibration *calib);
> +int mmdc_do_dqs_calibration(struct mx6_mmdc_calibration *calib);
>  #endif
>  
>  /* configure mx6 mmdc registers */
> 


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

[U-Boot] [PATCH] efi_loader: Fix typo in distro script

[Alexander Graf]

The distro script is supposed to use the internal fdt as fallback if we
find no viable other option. However, we're missing a space key to actually
make that work.

Add the space, so we can successfully load an EFI blob even when there is
no device tree provided on the target device.

Signed-off-by: Alexander Graf 
---
 include/config_distro_bootcmd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 4db6faa..9ecaf38 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -120,7 +120,7 @@
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; "  \
"if fdt addr ${fdt_addr_r}; then "\
"bootefi ${kernel_addr_r} ${fdt_addr_r};" \
-   "else"\
+   "else "\
"bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
"fi\0"\
\
-- 
1.8.5.6

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

Re: [U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks

[Marek Vasut]

On 06/22/2016 08:36 AM, Rajesh Bhagat wrote:
> 
> 
> From: Matthew Bright [mailto:matthew.bri...@alliedtelesis.co.nz] 
> Sent: Wednesday, June 22, 2016 11:42 AM
> To: Rajesh Bhagat ; ma...@denx.de
> Cc: u-boot@lists.denx.de; Chris Packham ; 
> Mark Tomlinson 
> Subject: testing: [PATCH v7 0/3] common: usb_storage: Implement logic to 
> calculate optimal usb maximum trasfer blocks
> 
> On 06/16/2016 12:35 PM, Rajesh Bhagat wrote:
>> Performs code cleanup by making common function for usb_stor_read/write
>> and implements the logic to calculate the optimal usb maximum trasfer blocks
>> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
>> of EHCI and other USB protocols respectively.
>>  
>> Rajesh Bhagat (3):
>>   common: usb_storage: Make common function for usb_read_10/usb_write_10
>>   common: usb_storage: Make common function for
>> usb_stor_read/usb_stor_write
>>   common: usb_storage : Implement logic to calculate optimal usb maximum
>> trasfer blocks
>>  
>>  common/usb_storage.c | 213 
>> +++
>>  include/usb.h|   1 +
>>  2 files changed, 98 insertions(+), 116 deletions(-)
>>  
>>
>> Hi Rajesh & Marek
>>
>> I have spend the last couple of days testing these patches on the
>> v2016.05 release, with an usb mass storage device that is able to
>> consistently reproduce the USB_MAX_XFER_BLK issue as described in
>> the "Issue with USB mass storage (thumb drives)" u-boot thread.
>>
>> http://lists.denx.de/pipermail/u-boot/2016-February/244464.html​
>>
> 
> Hello Matt, 
> 
>> I can confirm the patch correctly increases the max transfer bocks
>> after a successful read, and decreases the max transfer bocks after
>> a read failure. However, I have noticed that once the ehci time out
>> error occurs, the usb device appears to lock up. When in this state
>> the usb device will stop responding to any further transfers. This
>> behavior is independent of the number of blocks, and will continue
>> until the ehci has been reset.
>>
> 
> I believe the lockup behavior mentioned by you to be device specific quirk. 
> I tested 3 pen drives, which recovered from EHCI timeout behavior by 
> reducing the number of blocks (check below output): 
> 

3 devices is not a representative sample.

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

[U-Boot] [PATCH v2] ARM: AM437x: Align HS device variant defconfig filename

[Andreas Dannenberg]

Align the name of the defconfig file for high-security (HS) device variants
from the AM43xx family of SoCs with the corresponding name used for the
general purpose devices. This allows for easier cross-association of those
files and also provides room to grow from an HS device part number
perspective.

Furthermore, update and cleanup associated MAINTAINERS file.

Signed-off-by: Andreas Dannenberg 
Cc: Lokesh Vutla 
Cc: Madan Srinivas 
---

Update since last patch: Added defconfig file to MAINTAINERS doc. Also took
the liberty to swap two entries in said MAINTAINERS file so that the list
of defconfig files is in alphabetical order (allows for easier comparison
with the associated directory contents).


 board/ti/am43xx/MAINTAINERS |  3 ++-
 configs/am437x_hs_evm_defconfig | 59 -
 configs/am43xx_hs_evm_defconfig | 59 +
 3 files changed, 61 insertions(+), 60 deletions(-)
 delete mode 100644 configs/am437x_hs_evm_defconfig
 create mode 100644 configs/am43xx_hs_evm_defconfig

diff --git a/board/ti/am43xx/MAINTAINERS b/board/ti/am43xx/MAINTAINERS
index 3d40b17..83645ac 100644
--- a/board/ti/am43xx/MAINTAINERS
+++ b/board/ti/am43xx/MAINTAINERS
@@ -4,6 +4,7 @@ S:  Maintained
 F: board/ti/am43xx/
 F: include/configs/am43xx_evm.h
 F: configs/am43xx_evm_defconfig
-F: configs/am43xx_evm_qspiboot_defconfig
 F: configs/am43xx_evm_ethboot_defconfig
+F: configs/am43xx_evm_qspiboot_defconfig
 F: configs/am43xx_evm_usbhost_boot_defconfig
+F: configs/am43xx_hs_evm_defconfig
diff --git a/configs/am437x_hs_evm_defconfig b/configs/am437x_hs_evm_defconfig
deleted file mode 100644
index 4856a19..000
--- a/configs/am437x_hs_evm_defconfig
+++ /dev/null
@@ -1,59 +0,0 @@
-CONFIG_ARM=y
-CONFIG_AM43XX=y
-CONFIG_TI_SECURE_DEVICE=y
-CONFIG_TARGET_AM43XX_EVM=y
-CONFIG_DM_SERIAL=y
-CONFIG_DM_GPIO=y
-CONFIG_SPL_STACK_R_ADDR=0x8200
-# Device tree file can be same on HS evm
-CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
-CONFIG_SPL=y
-CONFIG_ISW_ENTRY_ADDR=0x40302ae0
-CONFIG_SPL_STACK_R=y
-CONFIG_FIT=y
-CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-# CONFIG_CMD_IMLS is not set
-CONFIG_CMD_ASKENV=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_MMC=y
-CONFIG_CMD_SF=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_USB=y
-CONFIG_CMD_DFU=y
-CONFIG_CMD_GPIO=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_OF_CONTROL=y
-CONFIG_OF_LIST="am437x-gp-evm"
-CONFIG_DM=y
-CONFIG_DM_MMC=y
-CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_MACRONIX=y
-CONFIG_SYS_NS16550=y
-CONFIG_TI_QSPI=y
-CONFIG_TIMER=y
-CONFIG_OMAP_TIMER=y
-CONFIG_USB=y
-CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_DWC3=y
-CONFIG_USB_DWC3_GADGET=y
-CONFIG_USB_DWC3_OMAP=y
-CONFIG_USB_DWC3_PHY_OMAP=y
-CONFIG_USB_GADGET=y
-CONFIG_USB_GADGET_DOWNLOAD=y
-CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
-CONFIG_G_DNL_VENDOR_NUM=0x0403
-CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
new file mode 100644
index 000..4856a19
--- /dev/null
+++ b/configs/am43xx_hs_evm_defconfig
@@ -0,0 +1,59 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+# Device tree file can be same on HS evm
+CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
+CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_SPL_STACK_R=y
+CONFIG_FIT=y
+CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIST="am437x-gp-evm"
+CONFIG_DM=y
+CONFIG_DM_MMC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SYS_NS16550=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
+CONFIG_G_DNL_VENDOR_NUM=0x0403
+CONFIG_G_DNL_PRODUCT_NUM=0xbd00
+CONFIG_SPL_OF_LIBFDT=y
-- 
2.6.4

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

Re: [U-Boot] [PATCH] ARM: AM43xx: Align HS device variant defconfig filename

[Andreas Dannenberg]

On Tue, Jun 21, 2016 at 07:50:36PM -0400, Tom Rini wrote:
> On Tue, Jun 21, 2016 at 02:41:06PM -0500, Andreas Dannenberg wrote:
> 
> > Align the name of the defconfig file for high-security (HS) device variants
> > from the AM43xx family of SoCs with the corresponding names used for the
> > general purpose devices. This allows for easier cross-association of those
> > files and also provides room to grow from an HS device part number
> > perspective.
> > 
> > Signed-off-by: Andreas Dannenberg 
> > Cc: Madan Srinivas 
> > ---
> > 
> > While renaming files is always a tricky thing due to possible side effects
> > in this case there is likely virtually no user of this defconfig file yet
> > as it is rather new and the HS devices are not widely available in the
> > first place. Hence, go ahead and make this alignment rather sooner than
> > later.
> > 
> >  configs/am437x_hs_evm_defconfig | 59 
> > -
> >  configs/am43xx_hs_evm_defconfig | 59 
> > +
> 
> Please update board/ti/am43xx/MAINTAINERS as well, thanks!

Good point, will send out an updated version shortly.

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

Re: [U-Boot] [PATCH v2 2/5] fastboot: sparse: resync common/image-sparse.c (part 1)

[Tom Rini]

On Wed, Jun 22, 2016 at 09:36:23PM +0200, Maxime Ripard wrote:
> On Thu, Jun 16, 2016 at 10:29:39AM -0700, Steve Rae wrote:
> > On Wed, Jun 15, 2016 at 1:18 AM, Maxime Ripard
> >  wrote:
> > >
> > > On Tue, Jun 07, 2016 at 11:19:36AM -0700, Steve Rae wrote:
> > > > This file originally came from upstream code.
> > > >
> > > > While retaining the storage abstraction feature, this is the first
> > > > set of the changes required to resync with the
> > > >   cmd_flash_mmc_sparse_img()
> > > > in the file
> > > >   aboot.c
> > > > from
> > > >   
> > > > https://us.codeaurora.org/cgit/quic/la/kernel/lk/plain/app/aboot/aboot.c?h=LE.BR.1.2.1
> > > >
> > > > Signed-off-by: Steve Rae 
> > >
> > > Again, please split that in several patches to have one patch
> > > per-change you're doing.
> > >
> > > This is just impossible to review.
> > 
> > And I think you just reinforced the point:
> >this code was so far away from the original upstream code that it
> > is not even recognizable anymore
> 
> I think the only point that was made is that a different bootloader
> has a different implementation of the same protocol, just like for any
> other protocol.
> 
> An implementation relying on a 120 lines switch statement, and a 250
> lines functions, that hardcodes the backing storage device.
> 
> I'm not sure this is such a good inspiration.

True.  But do we want to have a compatible implementation, or match the
canonical implementation?  Especially since there's many existing 3rd
party tools that will test against the upstream version of things.

-- 
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 v2 5/5] fastboot: sparse: improve CHUNK_TYPE_FILL write performance

[Maxime Ripard]

On Thu, Jun 16, 2016 at 10:34:37AM -0700, Steve Rae wrote:
> On Wed, Jun 15, 2016 at 1:36 AM, Maxime Ripard
>  wrote:
> > On Tue, Jun 07, 2016 at 11:19:39AM -0700, Steve Rae wrote:
> >> - increase the size of the fill buffer
> >> - testing has shown a 10x improvement when the sparse image
> >>   has large CHUNK_TYPE_FILL chunks
> >>
> >> Signed-off-by: Steve Rae 
> >> ---
> >>
> >> Changes in v2: None
> >>
> >>  common/image-sparse.c | 37 +++--
> >>  1 file changed, 27 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/common/image-sparse.c b/common/image-sparse.c
> >> index 9632c6f..ddf5772 100644
> >> --- a/common/image-sparse.c
> >> +++ b/common/image-sparse.c
> >> @@ -1,4 +1,3 @@
> >> -
> >>  /*
> >>   * Copyright (c) 2009, Google Inc.
> >>   * All rights reserved.
> >> @@ -46,6 +45,10 @@
> >>
> >>  #include 
> >>
> >> +#ifndef CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE
> >> +#define CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE (1024 * 512)
> >
> > I wonder whether that would be better to just put the number of blocks
> > there.
> 
> I wanted to imply that this is not just a random value (even though
> the code does values which are not a multiple of the  info->blksz)

I know, but what I was saying is that NAND block size are usually a
couple of kilobytes, while the benefit here probably comes from the
number of blocks, not the actual size they take, which, for the same
benefits, will probably be the same number of blocks, but implies a
bigger size.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v2 2/5] fastboot: sparse: resync common/image-sparse.c (part 1)

[Maxime Ripard]

On Thu, Jun 16, 2016 at 10:29:39AM -0700, Steve Rae wrote:
> On Wed, Jun 15, 2016 at 1:18 AM, Maxime Ripard
>  wrote:
> >
> > On Tue, Jun 07, 2016 at 11:19:36AM -0700, Steve Rae wrote:
> > > This file originally came from upstream code.
> > >
> > > While retaining the storage abstraction feature, this is the first
> > > set of the changes required to resync with the
> > >   cmd_flash_mmc_sparse_img()
> > > in the file
> > >   aboot.c
> > > from
> > >   
> > > https://us.codeaurora.org/cgit/quic/la/kernel/lk/plain/app/aboot/aboot.c?h=LE.BR.1.2.1
> > >
> > > Signed-off-by: Steve Rae 
> >
> > Again, please split that in several patches to have one patch
> > per-change you're doing.
> >
> > This is just impossible to review.
> 
> And I think you just reinforced the point:
>this code was so far away from the original upstream code that it
> is not even recognizable anymore

I think the only point that was made is that a different bootloader
has a different implementation of the same protocol, just like for any
other protocol.

An implementation relying on a 120 lines switch statement, and a 250
lines functions, that hardcodes the backing storage device.

I'm not sure this is such a good inspiration.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH 3/3] ARM: configs: cm_fx6: add mtd support

[Christopher Spinrath]

Hi Igor,

On 06/22/2016 06:15 PM, Igor Grinberg wrote:
> On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
>> The cm-fx6 module has an on-board spi flash chip. Enable mtd support
>> and the mtdparts command. Also define a default partitioning, add
>> it to the default environment, and enable support to overwrite the
>> partitioning defined in a device tree by it.
>>
>> These changes move the effective default partitioning from the device
>> tree shipped with the vendor kernels to u-boot which becomes the single
>> point of definition for the partitioning for all device tree based
>> kernels (in particular, for the upstream linux kernel which does not
>> have a default partitioning defined in its device tree).
>>
>> Signed-off-by: Christopher Spinrath 
>> ---
>>  include/configs/cm_fx6.h | 19 ++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
>> index f054ca8..c839b03 100644
>> --- a/include/configs/cm_fx6.h
>> +++ b/include/configs/cm_fx6.h
> 
> [...]
> 
>> @@ -157,7 +174,7 @@
>>  "run setupnandboot;" \
>>  "run nandboot;"
>>  
>> -#define CONFIG_PREBOOT  "usb start"
>> +#define CONFIG_PREBOOT  "usb start;sf probe"
> 
> Probably, this is really needed.
> Care to explain?
>
The sf probe command probes for the spi flash and registers (on success)
the device as nor0. This device is used by mtdparts (cf. the mtdids
variable; it maps the U-Boot name nor0 to the kernel name spi0.0) and
the mtd fixup code in patch 2 (cf. the nodes array; it specifies the
compatible of the flash chip of type NOR #0, i.e. nor0).

Without this all mtdparts commands will fail and the fixup code won't
work because there is nor0 device.

Cheers,
Christopher

>>  
>>  /* SPI */
>>  #define CONFIG_SPI
>>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt

[Christopher Spinrath]

Hi Igor,

On 06/22/2016 06:02 PM, Igor Grinberg wrote:
> Hi Christopher,
> 
> On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
>> The cm-fx6 module has an on-board st,m25p compatible spi flash chip
>> used for u-boot (binary & environment). Overwrite the partitions in
>> the device tree by the partition table provided in the mtdparts
>> environment variable, if it is set.
>>
>> This allows to specify a kernel independent partitioning in the
>> environment and provides a convient way for the user to adapt the
>> partition table.
>>
>> Signed-off-by: Christopher Spinrath 
>> ---
>>  board/compulab/cm_fx6/cm_fx6.c | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
>> index 712057a..81a7ae2 100644
>> --- a/board/compulab/cm_fx6/cm_fx6.c
>> +++ b/board/compulab/cm_fx6/cm_fx6.c
>> @@ -12,6 +12,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -28,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Why is this needed?
> 
The MTD_DEV_TYPE_NOR constant is defined in this header. I agree that it
is a bit ugly but this header is used for the same purpose in other
board files, too (e.g.board/pdm360ng/pdm360ng.c).

>>  #include "common.h"
>>  #include "../common/eeprom.h"
>>  #include "../common/common.h"
>> @@ -581,6 +583,13 @@ int cm_fx6_setup_ecspi(void) { return 0; }
>>  
>>  #ifdef CONFIG_OF_BOARD_SETUP
>>  #define USDHC3_PATH "/soc/aips-bus@0210/usdhc@02198000/"
>> +
>> +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
>> +struct node_info nodes[] = {
>> +{ "st,m25p",MTD_DEV_TYPE_NOR,   },
>> +};
>> +#endif
>> +
>>  int ft_board_setup(void *blob, bd_t *bd)
>>  {
>>  u32 baseboard_rev;
>> @@ -589,6 +598,8 @@ int ft_board_setup(void *blob, bd_t *bd)
>>  char baseboard_name[16];
>>  int err;
>>  
>> +fdt_shrink_to_minimum(blob); /* Make room for new properties */
>> +
>>  /* MAC addr */
>>  if (eth_getenv_enetaddr("ethaddr", enetaddr)) {
>>  fdt_find_and_setprop(blob,
>> @@ -607,7 +618,6 @@ int ft_board_setup(void *blob, bd_t *bd)
>>  return 0; /* Assume not an early revision SB-FX6m baseboard */
>>  
>>  if (!strncmp("SB-FX6m", baseboard_name, 7) && baseboard_rev <= 120) {
>> -fdt_shrink_to_minimum(blob); /* Make room for new properties */
>>  nodeoffset = fdt_path_offset(blob, USDHC3_PATH);
>>  fdt_delprop(blob, nodeoffset, "cd-gpios");
>>  fdt_find_and_setprop(blob, USDHC3_PATH, "broken-cd",
>> @@ -616,6 +626,10 @@ int ft_board_setup(void *blob, bd_t *bd)
>>   NULL, 0, 1);
>>  }
>>  
>> +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
>> +fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
>> +#endif
> 
> I really dislike the ifdeffery inside functions.
> Care to introduce a stub for the !CONFIG_FDT_FIXUP_PARTITIONS case in
> include/fdt_support.h for this one?
> 
Sure. Is the header the correct place for this or should I add a #else
case in the .c file?

Cheers,
Christopher

>> +
>>  return 0;
>>  }
>>  #endif
>>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] ARM: imx: enhance support for the cm-fx6 module

[Christopher Spinrath]

Hi Igor,

thanks for your review!

On 06/22/2016 05:46 PM, Igor Grinberg wrote:
> Hi Christopher,
> 
> Thanks for doing this work.
> 
> On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
>> Hi,
>>
>> this series aims at enhancing support for the cm-fx6 module. In
>> particular, with respect to the upstream linux kernel.
>>
>> The first patch improves the default environment. It is non-functional
>> but makes it more convenient to adapt certain settings.
>>
>> The later two patches add mtd partition support for the on-board spi
>> flash chip. They pick up the discussion about specifying a default
>> partitioning in the device tree from here [1]. In short: adding the
>> default partitioning to the device tree was rejected by the linux/
>> device tree community during mainlining large parts of the device tree.
>> It was proposed to implement the partition/mtd handling in u-boot.
>> On the other hand, it was argued that the flash chip becomes some
>> kind of "black-box" since there will be no partition labeling (in
>> particular, with old u-boot versions).
>>
>> IMHO defining the mtd partitioning has the following (dis-)advantages:
> 
> You mean defining it in U-Boot instead of upstream DT.
>

Yes.

>>
>> Advantages:
>> - It is easier for the user to change the partitioning (e.g. to use
>>   the unsued 1MB free space).
> 
> I know it says reserved, but that is not exactly unused...
> It is intended to hold a splash screen of up to 1MB size and may be other
> things (like dtb, etc.).
> By the time the partitioning layout was defined, it was still unclear
> what requirements of that additional space will be.
> So it was called reserved to provide a kind of warning to the users as
> it might be used at some point.
> 
Good to know. So this would be a use case for this series. People can
rename the last partition to e.g. uboot-splash.

>>
>> - The flash ship is used entirely for u-boot.
> 
> Close, but not precise...
> The spi flash chip is used for all boot purposes, so it might be beyond
> U-Boot.
> 
Ok. But still it is U-Boot (or another bootloader) that relies on the
memory layout.

>>   So it is quite natural
>>   that u-boot manages it. Also, moving the partition table to it
>>   allows us to change the layout in future versions of u-boot (almost
>>   independently of the kernel - there are still non-device tree kernels).
> 
> Please don't change the layout as it will break backwards compatibility.
> Also, there is not much you can change.
> 
I have no intention do so but users may want to change it (and now, can
do so easily). For example, choose a better name for the "reserved"
partition.

>>
>> - U-Boot becomes the single point of definition for all device tree
>>   kernels. Otherwise, each kernel (vendor vs. upstream + version)
>>   would ship its own partitioning.
> 
> True.
> 
>>   Moreover, u-boot has to know
>>   something about the partitioning, too, because it has to know where
>>   the environment is saved.
> 
> It does, although the env address is hardcoded, but it should not be
> changed.
> The reason for providing a partition for it is purely for Linux to able
> to change the environment variables.
> 
Indeed, but moving both definitions into one project reduces the risk of
having conflicts and allows (advanced) users to change it by adapting
only one project (e.g. another bootloader may use another partitioning).

Cheers,
Christopher

>>
>> Disadvantages:
>> - Users of the upstream linux kernel have to use a recent u-boot
>>   version to avoid the "black box" effect. A concrete impact is
>>   that the update routine (described/proposed by CompuLab) does
>>   not work out of the box with older u-boot versions.
> 
> True.
> 
>>
>> - Updating u-boot is something users might not want or miss to do.
>>
>> However, I think nowadays it is ok to demand a recent u-boot in
>> combination with the upstream kernel. The cm-fx6 wouldn't be
>> the first board doing so. Hence, I propose these patches here.
>>
>> Cheers,
>> Christopher
>>
>> [1] 
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/434562.html
>>
>>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uImage load address and entry point with Minnowboard

[Wolfgang Denk]

Dear vinoth,

In message 
 you 
wrote:
> 
> I tried creating the uImage from the vmlinux --but I did not
> understand what does the -a (load address) and -e (entry point )
> points to? I assume that it is the same load address used when loading
> the kernel image from sd card to RAM.

No, it is not.

There are actually two "load addresses". Uusally I prefer to call the
first the "download address": this is the address in memory space
where you download the uImage file to, i. e. the first address of the
uImage file in the system memory (RAM or parallel NOR flash etc.).

The payload of the uImage is often a _compressed_ kernel image.  To
boot it, U-Boot will have to uncompress and _load_ it to some other
address in RAM.  This is the "load address", given by the "-a" option
to mkimage.  Afther that, you have the uncompressed, executable kerl
image sitting in RAM, starting at the "load address" - but this is not
necessarily the same as the entry point address - the latter is given
by the "-e" argument.

While you can download and store the uImage file at an arbitrary
address in memory, the addresses for the executable (uncompressed)
image and for the entry point are often fixed - this is why they re
registered in the uImage file.


Note that because you usually uncompress and load (copy) the image to
the load address, you must not download the uImage to the load
address; this will usually result in memory corruptuin and boot
failure.

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
There is nothing in this world constant but inconstancy.  - Swift
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv6 2/6] ARMv8: add the secure monitor firmware framework

[york sun]

On 06/21/2016 08:42 PM, Zhiqiang Hou wrote:



> +
> +#ifdef CONFIG_ARMV8_PSCI
> +/*
> + * The PSCI_VERSION function is added from PSCI v0.2. When the PSCI
> + * v0.1 received this function, the NOT_SUPPORTED (0x_) error
> + * number will be returned according to SMC Calling Conventions. But
> + * when getting the NOT_SUPPORTED error number, we cannot ensure if
> + * the PSCI version is v0.1 or other error occurred. So, PSCI v0.1
> + * won't be supported by this framework.
> + * And if the secure firmware isn't running, return NOT_SUPPORTED.
> + *
> + * The return value on success is PSCI version in format
> + * major[31:16]:minor[15:0].
> + */
> +unsigned int sec_firmware_support_psci_version(void)
> +{
> + if (gd->sec_firmware & SEC_FIRMWARE_RUNNING)
> + return _sec_firmware_support_psci_version();
> +
> + return 0x;
> +}
> +#endif

Does _sec_firmware_support_psci_version() always return version numbers? 
Any chance it returns an error code?

York


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

Re: [U-Boot] [PATCHv6 5/6] ARMv8/PSCI: Fixup the device tree for PSCI

[york sun]

On 06/21/2016 08:42 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Set the enable-method in the cpu node to PSCI, and create device
> node for PSCI, when PSCI was enabled.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V6:
>   - Removed PSCI version 0.1 support.
>
> V5:
>   - Moved the weak func sec_firmware_support_psci_version to sec_firmware.c.
>   - Correct the PSCI version value in switch-case. The right version format 
> is marjor[31:16]:minor[15:0].
>
>   arch/arm/cpu/armv8/Makefile |   1 +
>   arch/arm/cpu/armv8/cpu-dt.c | 122 
> 
>   arch/arm/lib/bootm-fdt.c|   2 +-
>   3 files changed, 124 insertions(+), 1 deletion(-)
>   create mode 100644 arch/arm/cpu/armv8/cpu-dt.c
>
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index ee9e009..33e6db0 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -15,6 +15,7 @@ obj-y   += cache.o
>   obj-y   += tlb.o
>   obj-y   += transition.o
>   obj-y   += fwcall.o
> +obj-y+= cpu-dt.o
>   obj-$(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o 
> sec_firmware_asm.o
>
>   obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
> diff --git a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c
> new file mode 100644
> index 000..6b9aa77
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/cpu-dt.c
> @@ -0,0 +1,122 @@
> +/*
> + * Copyright 2016 NXP Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> +#include 
> +#endif
> +
> +#ifdef CONFIG_MP
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#if defined(CONFIG_ARMV8_PSCI)
> +static int cpu_update_dt_psci(void *fdt)
> +{
> + int nodeoff;
> + unsigned int psci_ver;
> + char *psci_compt;
> + int tmp;
> +
> + nodeoff = fdt_path_offset(fdt, "/cpus");
> + if (nodeoff < 0) {
> + printf("couldn't find /cpus\n");
> + return nodeoff;
> + }
> +
> + /* add 'enable-method = "psci"' to each cpu node */
> + for (tmp = fdt_first_subnode(fdt, nodeoff);
> +  tmp >= 0;
> +  tmp = fdt_next_subnode(fdt, tmp)) {
> + const struct fdt_property *prop;
> + int len;
> +
> + prop = fdt_get_property(fdt, tmp, "device_type", );
> + if (!prop)
> + continue;
> + if (len < 4)
> + continue;
> + if (strcmp(prop->data, "cpu"))
> + continue;
> +
> + /*
> +  * Not checking rv here, our approach is to skip over errors in
> +  * individual cpu nodes, hopefully some of the nodes are
> +  * processed correctly and those will boot
> +  */
> + fdt_setprop_string(fdt, tmp, "enable-method", "psci");
> + }
> +
> + /*
> +  * The PSCI node might be called "/psci" or might be called something
> +  * else but contain either of the compatible strings
> +  * "arm,psci"/"arm,psci-0.2"
> +  */
> + nodeoff = fdt_path_offset(fdt, "/psci");
> + if (nodeoff >= 0)
> + goto init_psci_node;
> +
> + nodeoff = fdt_node_offset_by_compatible(fdt, -1, "arm,psci");
> + if (nodeoff >= 0)
> + goto init_psci_node;
> +
> + nodeoff = fdt_node_offset_by_compatible(fdt, -1, "arm,psci-0.2");
> + if (nodeoff >= 0)
> + goto init_psci_node;
> +
> + nodeoff = fdt_node_offset_by_compatible(fdt, -1, "arm,psci-1.0");
> + if (nodeoff >= 0)
> + goto init_psci_node;
> +
> + nodeoff = fdt_path_offset(fdt, "/");
> + if (nodeoff < 0)
> + return nodeoff;
> +
> + nodeoff = fdt_add_subnode(fdt, nodeoff, "psci");
> + if (nodeoff < 0)
> + return nodeoff;
> +
> +init_psci_node:
> +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> + psci_ver = sec_firmware_support_psci_version();
> +#endif
> + switch (psci_ver) {
> + case 0x0001:
> + psci_compt = "arm,psci-1.0";
> + break;
> + case 0x0002:
> + psci_compt = "arm,psci-0.2";
> + break;
> + default:
> + psci_compt = "arm,psci-0.2";
> + break;
> + }
> +
> + tmp = fdt_setprop_string(fdt, nodeoff, "compatible", psci_compt);
> + if (tmp)
> + return tmp;
> +
> + tmp = fdt_setprop_string(fdt, nodeoff, "method", "smc");
> + if (tmp)
> + return tmp;
> +
> + return 0;
> +}
> +#endif
> +#endif
> +
> +int psci_update_dt(void *fdt)
> +{
> +#ifdef CONFIG_MP
> +#if defined(CONFIG_ARMV8_PSCI)
> + cpu_update_dt_psci(fdt);
> +#endif
> +#endif
> + return 0;
> +}
> diff --git a/arch/arm/lib/bootm-fdt.c b/arch/arm/lib/bootm-fdt.c
> index 7677358..c642ff8 100644
> --- a/arch/arm/lib/bootm-fdt.c
> +++ b/arch/arm/lib/bootm-fdt.c
> @@ -42,7 

Re: [U-Boot] [PATCH] ARM: vexpress: Remove virt and nonsec support for TC2

[Jon Medhurst (Tixy)]

On Wed, 2016-06-22 at 15:53 +0100, Andre Przywara wrote:
> Hi,
> 
> On 22/06/16 15:34, Jon Medhurst (Tixy) wrote:
> > When CPU's come out of reset they are in secure state supervisor mode,
> > so this is the state Linux kernel entry point is called in when it
> > brings up secondary CPU cores or the primary CPU restarts after power
> > management has sent it through an off/on transition.
> > 
> > As U-Boot starts the kernel in hypervisor mode and the kernel expects
> > and checks that CPUs start in the same state as initial boot this
> > results in a dead system. Specifically, it crashes early in boot when
> > the primary CPU runs the MCPM test [1] and even if power management
> > features are disabled it will still refuse to bring up any secondary
> > CPUs.
> > 
> > Fix this problem by removing U-Boot support for virt and nonsec
> > support on TC2.
> 
> So this disables any kind of virtualization support for TC2, which is a
> bit unfortunate.
> If I get this (and Sudeep's explanations) correctly, this new behaviour
> comes from the per-CPU-mailboxes setting in SCC 0x700, which is a
> setting in boot.txt on the uSD card.

Right, so I got the current U-Boot to boot Linux OK with all CPU's
coming up in hyp mode by:

- Clearing bits 12 and 13 in SCC 0x700 to disable per-cpu mailboxes and
  keep the secondary CPU powered up.

- Removing kernel configs
CONFIG_ARCH_VEXPRESS_TC2_PM
CONFIG_MCPM

I believe this works because the SCC change means that all CPU will be
running and waiting in the bootmonitor holding pen, from which they are
released when U-Boot calls smp_set_core_boot_addr. These secondary CPUs
then execute U-Boot code to switch to hypervisor mode, then enter a new
holding pen. (Running in RAM that can't get overwritten by Linux I hope!
)

Then when kernel boots and releases cores from holding pen they are in
hyp mode, like the main CPU. As we've also disabled power management in
the kernel, CPU's aren't ever powered down again and so stay in hyp
mode.

Actually, I just tried hotplugging a CPU which obviously the kernel
didn't like, so there is probably other kernel configs that need
tweaking to make things work.

> I wonder if we could make this virt/secure support a runtime decision
> then based on that register?
> So that a user can select whether she wants virtualisation or power
> management by changing the boot.txt setting and U-Boot transparently
> adapts to it, entering the kernel in either secure SVC or HYP.
>
> Does that make sense?
> I can look into a fix if this approach is fine.

Anything that gets U-Boot in it's default config working with vexpress
firmware and Linux kernel in their default config would be good
start :-)

I'm not sure that having an automatic selection in U-Boot is worth it,
given that anyone booting in hyp mode also needs to modify the firmware
and kernel configs to get things working. But I wouldn't object to such
an automatic selection either. After all, it's not like anyone really
uses or cares about this stuff, and if they are, they probably have
there own customised setup rather than using upstream defaults.

-- 
Tixy

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

Re: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

[Christian Didriksson]

Hi Marek,

[..]

I skipped booting from QSPI and started all over with a vanilla 2016.05 and 
built the u-boot-with-spl.sfp. Put it on an SD-card and booted:

U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
drivers/ddr/altera/sequencer.c: Calibration complete
Trying to boot from MMC1

This printout is repeated forever.

I then connected DS5 via the USB-Blaster cable and single stepped through the 
SPL and after a while, down in mmc_init, I loose connection to the target and 
when I interrupt it the PC is here:

#ifdef CONFIG_SPL_BUILD

.align  5
undefined_instruction:
software_interrupt:
prefetch_abort:
data_abort:
not_used:
irq:
fiq:

1:
bl  1b  /* hang and never return */

#else   /* !CONFIG_SPL_BUILD */

I will send you my binary for test on your Rev c board if you can find the time.

I also tested the binary you sent me last week and it behaves identically 
regarding the printouts and reboot.

Best regards,

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

Re: [U-Boot] [PATCHv6 4/6] ARMv8/Layerscape: switch SMP method accordingly

[york sun]

On 06/21/2016 08:45 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> If the PSCI and PPA is ready, skip the fixup for spin-table and
> waking secondary cores. Otherwise, change SMP method to spin-table,
> and the device node of PSCI will be removed.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V6:
>   - no change
>
> V5:
>   - Changed the checking if the PSCI feature is ready to read the psci 
> version.
>
> V4:
>   - Reordered this patch.
>
>   arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 17 ++---
>   arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 34 
> +
>   2 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index d5bcf67..f284b77 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -23,6 +23,9 @@
>   #ifdef CONFIG_FSL_ESDHC
>   #include 
>   #endif
> +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> +#include 
> +#endif
>
>   DECLARE_GLOBAL_DATA_PTR;
>
> @@ -622,6 +625,7 @@ int arch_early_init_r(void)
>   {
>   #ifdef CONFIG_MP
>   int rv = 1;
> + bool psci_support = false;
>   #endif
>
>   #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
> @@ -629,9 +633,16 @@ int arch_early_init_r(void)
>   #endif
>
>   #ifdef CONFIG_MP
> - rv = fsl_layerscape_wake_seconday_cores();
> - if (rv)
> - printf("Did not wake secondary cores\n");
> +#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) && defined(CONFIG_ARMV8_PSCI)
> + /* Check the psci version to determine if the psci is supported */
> + psci_support = sec_firmware_support_psci_version() != 0x ?
> + true : false;

If the only error code is 0x, you can delete the "? true : 
false" part. The logical operation results "true" or "false" already.

> +#endif
> + if (!psci_support) {
> + rv = fsl_layerscape_wake_seconday_cores();
> + if (rv)
> + printf("Did not wake secondary cores\n");
> + }
>   #endif



York

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

Re: [U-Boot] [PATCH 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt

[Igor Grinberg]

On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
> The cm-fx6 module has an on-board st,m25p compatible spi flash chip
> used for u-boot (binary & environment). Overwrite the partitions in
> the device tree by the partition table provided in the mtdparts
> environment variable, if it is set.
> 
> This allows to specify a kernel independent partitioning in the
> environment and provides a convient way for the user to adapt the
> partition table.
> 
> Signed-off-by: Christopher Spinrath 
> ---
>  board/compulab/cm_fx6/cm_fx6.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
> index 712057a..81a7ae2 100644
> --- a/board/compulab/cm_fx6/cm_fx6.c
> +++ b/board/compulab/cm_fx6/cm_fx6.c

[...]

> +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
> +struct node_info nodes[] = {
> + { "st,m25p",MTD_DEV_TYPE_NOR,   },

Nikita, is this enough for all flashes we assemble on cm-fx6?

> +};
> +#endif
> +

[...]

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

Re: [U-Boot] [PATCH 3/3] ARM: configs: cm_fx6: add mtd support

[Igor Grinberg]

On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
> The cm-fx6 module has an on-board spi flash chip. Enable mtd support
> and the mtdparts command. Also define a default partitioning, add
> it to the default environment, and enable support to overwrite the
> partitioning defined in a device tree by it.
> 
> These changes move the effective default partitioning from the device
> tree shipped with the vendor kernels to u-boot which becomes the single
> point of definition for the partitioning for all device tree based
> kernels (in particular, for the upstream linux kernel which does not
> have a default partitioning defined in its device tree).
> 
> Signed-off-by: Christopher Spinrath 
> ---
>  include/configs/cm_fx6.h | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
> index f054ca8..c839b03 100644
> --- a/include/configs/cm_fx6.h
> +++ b/include/configs/cm_fx6.h

[...]

> @@ -157,7 +174,7 @@
>   "run setupnandboot;" \
>   "run nandboot;"
>  
> -#define CONFIG_PREBOOT   "usb start"
> +#define CONFIG_PREBOOT   "usb start;sf probe"

Probably, this is really needed.
Care to explain?

>  
>  /* SPI */
>  #define CONFIG_SPI
> 

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

Re: [U-Boot] [PATCHv6 3/6] ARMv8/layerscape: Add FSL PPA support

[york sun]

On 06/21/2016 08:41 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> The FSL Primary Protected Application (PPA) is a software component
> loaded during boot which runs in TrustZone and remains resident
> after boot.
>
> Use the secure firmware framework to integrate FSL PPA into U-Boot.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V6:
>   - Use the secure firmware framework to integrate PPA.
>
> V5:
>   - Added API sec_firmware_init() implementation.
>
> V4:
>   - Moved secure firmware validation API to this patch.
>   - Moved secure firmware getting supported PSCI version API to this patch.
>
> V3:
>   - Refactor the code.
>   - Add PPA firmware version info output.
>
>   arch/arm/cpu/armv8/fsl-layerscape/Makefile |  1 +
>   arch/arm/cpu/armv8/fsl-layerscape/ppa.c| 48 
> ++
>   arch/arm/include/asm/arch-fsl-layerscape/ppa.h | 16 +
>   arch/arm/include/asm/armv8/sec_firmware.h  |  4 +++
>   4 files changed, 69 insertions(+)
>   create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ppa.c
>   create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/ppa.h
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
> b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> index eb2cbc3..bcf6b48 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> @@ -10,6 +10,7 @@ obj-y += soc.o
>   obj-$(CONFIG_MP) += mp.o
>   obj-$(CONFIG_OF_LIBFDT) += fdt.o
>   obj-$(CONFIG_SPL) += spl.o
> +obj-$(CONFIG_FSL_LS_PPA) += ppa.o
>
>   ifneq ($(CONFIG_FSL_LSCH3),)
>   obj-y += fsl_lsch3_speed.o
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> new file mode 100644
> index 000..ae7d364
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright 2016 NXP Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#ifdef CONFIG_FSL_LSCH3
> +#include 
> +#elif defined(CONFIG_FSL_LSCH2)
> +#include 
> +#endif
> +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> +#include 
> +#endif
> +
> +int ppa_init(void)
> +{
> + void *ppa_fit_addr;
> + u32 *boot_loc_ptr_l, *boot_loc_ptr_h;
> + int ret;
> +
> +#ifdef CONFIG_SYS_LS_PPA_FW_IN_NOR
> + ppa_fit_addr = (void *)CONFIG_SYS_LS_PPA_FW_ADDR;
> +#else
> +#error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
> +#endif
> +
> +#ifdef CONFIG_FSL_LSCH3
> + struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
> + boot_loc_ptr_l = >bootlocptrl;
> + boot_loc_ptr_h = >bootlocptrh;
> +#elif defined(CONFIG_FSL_LSCH2)
> + struct ccsr_scfg __iomem *scfg = (void *)(CONFIG_SYS_FSL_SCFG_ADDR);
> + boot_loc_ptr_l = >scratchrw[1];
> + boot_loc_ptr_h = >scratchrw[0];
> +#endif
> +
> + debug("fsl-ppa: boot_loc_ptr_l = 0x%p, boot_loc_ptr_h =0x%p\n",
> + boot_loc_ptr_l, boot_loc_ptr_h);

Alignment issue. Didn't checkpatch remind you about this?

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

Re: [U-Boot] [PATCHv6 2/6] ARMv8: add the secure monitor firmware framework

[york sun]

On 06/21/2016 08:42 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> This framework is introduced for ARMv8 secure monitor mode firmware.
> The main functions of the framework are, on EL3, verify the firmware,
> load it to the secure memory and jump into it, and while it returned
> to U-Boot, do some necessary setups at the 'target exception level'
> that is determined by the respective secure firmware.
>
> So far, the framework support only FIT format image, and need to define
> the name of which config node should be used in 'configurations' and
> the name of property for the raw secure firmware image in that config.
> The FIT image should be stored in Byte accessing memory, such as NOR
> Flash, or else it should be copied to main memory to use this framework.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V6:
>   - Abstracted more code from PPA to this framework.
>   - Introduced gd->sec_firmware to hold the load address.
>   - Refactor the func sec_firmware_support_psci_version().

A lot of change in this version.

>
> V5:
>   - Added c file sec_firmware.c.
>   - Added declaration of sec_firmware_init().
>   - Renamed the func sec_firmware_validate().
>
> V4:
>   - Reordered this patch.
>   - Removed the FSL PPA related items.
>
>   arch/arm/cpu/armv8/Makefile   |   1 +
>   arch/arm/cpu/armv8/sec_firmware.c | 262 
> ++
>   arch/arm/cpu/armv8/sec_firmware_asm.S |  53 ++
>   arch/arm/include/asm/armv8/sec_firmware.h |  18 ++
>   include/asm-generic/global_data.h |  11 ++
>   5 files changed, 346 insertions(+)
>   create mode 100644 arch/arm/cpu/armv8/sec_firmware.c
>   create mode 100644 arch/arm/cpu/armv8/sec_firmware_asm.S
>   create mode 100644 arch/arm/include/asm/armv8/sec_firmware.h
>
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index bf8644c..ee9e009 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -15,6 +15,7 @@ obj-y   += cache.o
>   obj-y   += tlb.o
>   obj-y   += transition.o
>   obj-y   += fwcall.o
> +obj-$(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o sec_firmware_asm.o
>
>   obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
>   obj-$(CONFIG_S32V234) += s32v234/
> diff --git a/arch/arm/cpu/armv8/sec_firmware.c 
> b/arch/arm/cpu/armv8/sec_firmware.c
> new file mode 100644
> index 000..986df48
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/sec_firmware.c
> @@ -0,0 +1,266 @@
> +/*
> + * Copyright 2016 NXP Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +extern void c_runtime_cpu_setup(void);
> +
> +static int sec_firmware_get_data(void *sec_firmware_img,
> + const void **data, size_t *size)

Throughout this patch, sec_firmware_img is used as read-only. How about 
add "const" to it?

> +{
> + void *fit_hdr;

Variable fit_hdr doesn't serve more purpose. You can use 
sec_firmware_img directly.


> + int conf_node_off, fw_node_off;
> + char *conf_node_name = NULL;
> + char *desc;
> + int ret;
> +
> + fit_hdr = sec_firmware_img;
> + conf_node_name = SEC_FIRMEWARE_FIT_CNF_NAME;
> +
> + conf_node_off = fit_conf_get_node(fit_hdr, conf_node_name);
> + if (conf_node_off < 0) {
> + printf("SEC Firmware: %s: no such config\n", conf_node_name);
> + return -ENOENT;
> + }
> +
> + fw_node_off = fit_conf_get_prop_node(fit_hdr, conf_node_off,
> + SEC_FIRMWARE_FIT_IMAGE);
> + if (fw_node_off < 0) {
> + printf("SEC Firmware: No '%s' in config\n",
> + SEC_FIRMWARE_FIT_IMAGE);

You have many of this alignment issues throughout this patch.



York

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

Re: [U-Boot] [PATCH 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt

[Igor Grinberg]

Hi Christopher,

On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
> The cm-fx6 module has an on-board st,m25p compatible spi flash chip
> used for u-boot (binary & environment). Overwrite the partitions in
> the device tree by the partition table provided in the mtdparts
> environment variable, if it is set.
> 
> This allows to specify a kernel independent partitioning in the
> environment and provides a convient way for the user to adapt the
> partition table.
> 
> Signed-off-by: Christopher Spinrath 
> ---
>  board/compulab/cm_fx6/cm_fx6.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
> index 712057a..81a7ae2 100644
> --- a/board/compulab/cm_fx6/cm_fx6.c
> +++ b/board/compulab/cm_fx6/cm_fx6.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -28,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Why is this needed?

>  #include "common.h"
>  #include "../common/eeprom.h"
>  #include "../common/common.h"
> @@ -581,6 +583,13 @@ int cm_fx6_setup_ecspi(void) { return 0; }
>  
>  #ifdef CONFIG_OF_BOARD_SETUP
>  #define USDHC3_PATH  "/soc/aips-bus@0210/usdhc@02198000/"
> +
> +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
> +struct node_info nodes[] = {
> + { "st,m25p",MTD_DEV_TYPE_NOR,   },
> +};
> +#endif
> +
>  int ft_board_setup(void *blob, bd_t *bd)
>  {
>   u32 baseboard_rev;
> @@ -589,6 +598,8 @@ int ft_board_setup(void *blob, bd_t *bd)
>   char baseboard_name[16];
>   int err;
>  
> + fdt_shrink_to_minimum(blob); /* Make room for new properties */
> +
>   /* MAC addr */
>   if (eth_getenv_enetaddr("ethaddr", enetaddr)) {
>   fdt_find_and_setprop(blob,
> @@ -607,7 +618,6 @@ int ft_board_setup(void *blob, bd_t *bd)
>   return 0; /* Assume not an early revision SB-FX6m baseboard */
>  
>   if (!strncmp("SB-FX6m", baseboard_name, 7) && baseboard_rev <= 120) {
> - fdt_shrink_to_minimum(blob); /* Make room for new properties */
>   nodeoffset = fdt_path_offset(blob, USDHC3_PATH);
>   fdt_delprop(blob, nodeoffset, "cd-gpios");
>   fdt_find_and_setprop(blob, USDHC3_PATH, "broken-cd",
> @@ -616,6 +626,10 @@ int ft_board_setup(void *blob, bd_t *bd)
>NULL, 0, 1);
>   }
>  
> +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
> + fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
> +#endif

I really dislike the ifdeffery inside functions.
Care to introduce a stub for the !CONFIG_FDT_FIXUP_PARTITIONS case in
include/fdt_support.h for this one?

> +
>   return 0;
>  }
>  #endif
> 

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

Re: [U-Boot] [PATCH 0/3] ARM: imx: enhance support for the cm-fx6 module

[Igor Grinberg]

Hi Christopher,

Thanks for doing this work.

On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
> Hi,
> 
> this series aims at enhancing support for the cm-fx6 module. In
> particular, with respect to the upstream linux kernel.
> 
> The first patch improves the default environment. It is non-functional
> but makes it more convenient to adapt certain settings.
> 
> The later two patches add mtd partition support for the on-board spi
> flash chip. They pick up the discussion about specifying a default
> partitioning in the device tree from here [1]. In short: adding the
> default partitioning to the device tree was rejected by the linux/
> device tree community during mainlining large parts of the device tree.
> It was proposed to implement the partition/mtd handling in u-boot.
> On the other hand, it was argued that the flash chip becomes some
> kind of "black-box" since there will be no partition labeling (in
> particular, with old u-boot versions).
> 
> IMHO defining the mtd partitioning has the following (dis-)advantages:

You mean defining it in U-Boot instead of upstream DT.

> 
> Advantages:
> - It is easier for the user to change the partitioning (e.g. to use
>   the unsued 1MB free space).

I know it says reserved, but that is not exactly unused...
It is intended to hold a splash screen of up to 1MB size and may be other
things (like dtb, etc.).
By the time the partitioning layout was defined, it was still unclear
what requirements of that additional space will be.
So it was called reserved to provide a kind of warning to the users as
it might be used at some point.

> 
> - The flash ship is used entirely for u-boot.

Close, but not precise...
The spi flash chip is used for all boot purposes, so it might be beyond
U-Boot.

>   So it is quite natural
>   that u-boot manages it. Also, moving the partition table to it
>   allows us to change the layout in future versions of u-boot (almost
>   independently of the kernel - there are still non-device tree kernels).

Please don't change the layout as it will break backwards compatibility.
Also, there is not much you can change.

> 
> - U-Boot becomes the single point of definition for all device tree
>   kernels. Otherwise, each kernel (vendor vs. upstream + version)
>   would ship its own partitioning.

True.

>   Moreover, u-boot has to know
>   something about the partitioning, too, because it has to know where
>   the environment is saved.

It does, although the env address is hardcoded, but it should not be
changed.
The reason for providing a partition for it is purely for Linux to able
to change the environment variables.

> 
> Disadvantages:
> - Users of the upstream linux kernel have to use a recent u-boot
>   version to avoid the "black box" effect. A concrete impact is
>   that the update routine (described/proposed by CompuLab) does
>   not work out of the box with older u-boot versions.

True.

> 
> - Updating u-boot is something users might not want or miss to do.
> 
> However, I think nowadays it is ok to demand a recent u-boot in
> combination with the upstream kernel. The cm-fx6 wouldn't be
> the first board doing so. Hence, I propose these patches here.
> 
> Cheers,
> Christopher
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/434562.html
> 
> 

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

Re: [U-Boot] [PATCH 1/3] ARM: configs: cm_fx6: improve default environment

[Igor Grinberg]

On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
> Currently, entire script segments have to be changed in the default
> environment to change the kernel image location or to append kernel
> cmdline parameters. In the later case this has to be changed for
> every possible boot device.
> 
> Introduce new variables for kernel image locations and boot device
> independent kernel parameters to make it easier to change these
> settings.
> 
> Signed-off-by: Christopher Spinrath 

Reviewed-by: Igor Grinberg 

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

[U-Boot] [PATCH] ARM: vexpress: Remove virt and nonsec support for TC2

[Jon Medhurst (Tixy)]

When CPU's come out of reset they are in secure state supervisor mode,
so this is the state Linux kernel entry point is called in when it
brings up secondary CPU cores or the primary CPU restarts after power
management has sent it through an off/on transition.

As U-Boot starts the kernel in hypervisor mode and the kernel expects
and checks that CPUs start in the same state as initial boot this
results in a dead system. Specifically, it crashes early in boot when
the primary CPU runs the MCPM test [1] and even if power management
features are disabled it will still refuse to bring up any secondary
CPUs.

Fix this problem by removing U-Boot support for virt and nonsec
support on TC2.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3592d7e002438980f9ce4a399f21ec94cbf071ea

Signed-off-by: Jon Medhurst 
---
 arch/arm/Kconfig|  2 --
 board/armltd/vexpress/vexpress_common.c | 15 ---
 2 files changed, 17 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e9d2fc9..2e48568 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -293,8 +293,6 @@ config ARCH_BCM283X
 config TARGET_VEXPRESS_CA15_TC2
bool "Support vexpress_ca15_tc2"
select CPU_V7
-   select CPU_V7_HAS_NONSEC
-   select CPU_V7_HAS_VIRT
 
 config TARGET_VEXPRESS_CA5X2
bool "Support vexpress_ca5x2"
diff --git a/board/armltd/vexpress/vexpress_common.c 
b/board/armltd/vexpress/vexpress_common.c
index d3b3b31..fe5d163 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -180,18 +180,3 @@ void lowlevel_init(void)
 ulong get_board_rev(void){
return readl((u32 *)SYS_ID);
 }
-
-#ifdef CONFIG_ARMV7_NONSEC
-/* Setting the address at which secondary cores start from.
- * Versatile Express uses one address for all cores, so ignore corenr
- */
-void smp_set_core_boot_addr(unsigned long addr, int corenr)
-{
-   /* The SYSFLAGS register on VExpress needs to be cleared first
-* by writing to the next address, since any writes to the address
-* at offset 0 will only be ORed in
-*/
-   writel(~0, CONFIG_SYSFLAGS_ADDR + 4);
-   writel(addr, CONFIG_SYSFLAGS_ADDR);
-}
-#endif
-- 
2.1.4



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

Re: [U-Boot] [PATCH v4 4/9] ls2080ardb: Convert to distro boot

[york sun]

On 06/21/2016 09:53 PM, Alexander Graf wrote:
>
>
>> Am 21.06.2016 um 23:49 schrieb york sun :
>>
>>> On 06/20/2016 04:07 PM, Alexander Graf wrote:
>>> Most new systems in U-Boot these days make use of the generic "distro"
>>> framework which allows a user to have U-Boot scan for a bootable OS
>>> on all available media types.
>>>
>>> This patch extends the LS2080ARDB board to use that framework if the
>>> hard coded NOR flash location does not contain a bootable image.
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v1 -> v2:
>>>
>>>- Boot NOR flash before distro boot
>>>
>>> v2 -> v3:
>>>
>>>- Actually run distro boot (s/&&/||/ after bootm)
>>>
>>> v3 -> v4:
>>>
>>>- Add CONFIG_CMD_FS_GENERIC to defconfig
>>> ---
>>>   configs/ls2080a_emu_defconfig|  1 +
>>>   configs/ls2080a_simu_defconfig   |  1 +
>>>   configs/ls2080aqds_SECURE_BOOT_defconfig |  1 +
>>>   configs/ls2080aqds_defconfig |  1 +
>>>   configs/ls2080aqds_nand_defconfig|  1 +
>>>   configs/ls2080ardb_SECURE_BOOT_defconfig |  1 +
>>>   configs/ls2080ardb_defconfig |  1 +
>>>   configs/ls2080ardb_nand_defconfig|  1 +
>>>   include/configs/ls2080ardb.h | 26 +-
>>>   9 files changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configs/ls2080a_emu_defconfig b/configs/ls2080a_emu_defconfig
>>> index 21a0283..c55feb5 100644
>>> --- a/configs/ls2080a_emu_defconfig
>>> +++ b/configs/ls2080a_emu_defconfig
>>> @@ -27,3 +27,4 @@ CONFIG_CMD_CACHE=y
>>>   CONFIG_SYS_NS16550=y
>>>   CONFIG_OF_LIBFDT=y
>>>   CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
>>> +CONFIG_CMD_FS_GENERIC=y
>>> diff --git a/configs/ls2080a_simu_defconfig b/configs/ls2080a_simu_defconfig
>>> index 1b670b0..edb267d 100644
>>> --- a/configs/ls2080a_simu_defconfig
>>> +++ b/configs/ls2080a_simu_defconfig
>>> @@ -30,3 +30,4 @@ CONFIG_NET_RANDOM_ETHADDR=y
>>>   CONFIG_SYS_NS16550=y
>>>   CONFIG_OF_LIBFDT=y
>>>   CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
>>> +CONFIG_CMD_FS_GENERIC=y
>>
>> For simulator and emulator targets, probably the filesystem commands
>> don't get used, due to the physical limitation.
>
> Why not? You can still attach some storage to the simulator, no?

Well, it doesn't hurt to include FS command. But there is no storage 
device for our simulator/emulator.

York

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

Re: [U-Boot] [PATCH] ARM: vexpress: Remove virt and nonsec support for TC2

[Andre Przywara]

Hi,

On 22/06/16 15:34, Jon Medhurst (Tixy) wrote:
> When CPU's come out of reset they are in secure state supervisor mode,
> so this is the state Linux kernel entry point is called in when it
> brings up secondary CPU cores or the primary CPU restarts after power
> management has sent it through an off/on transition.
> 
> As U-Boot starts the kernel in hypervisor mode and the kernel expects
> and checks that CPUs start in the same state as initial boot this
> results in a dead system. Specifically, it crashes early in boot when
> the primary CPU runs the MCPM test [1] and even if power management
> features are disabled it will still refuse to bring up any secondary
> CPUs.
> 
> Fix this problem by removing U-Boot support for virt and nonsec
> support on TC2.

So this disables any kind of virtualization support for TC2, which is a
bit unfortunate.
If I get this (and Sudeep's explanations) correctly, this new behaviour
comes from the per-CPU-mailboxes setting in SCC 0x700, which is a
setting in boot.txt on the uSD card.
I wonder if we could make this virt/secure support a runtime decision
then based on that register?
So that a user can select whether she wants virtualisation or power
management by changing the boot.txt setting and U-Boot transparently
adapts to it, entering the kernel in either secure SVC or HYP.

Does that make sense?
I can look into a fix if this approach is fine.

Cheers,
Andre.

> 
> [1] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3592d7e002438980f9ce4a399f21ec94cbf071ea
> 
> Signed-off-by: Jon Medhurst 
> ---
>  arch/arm/Kconfig|  2 --
>  board/armltd/vexpress/vexpress_common.c | 15 ---
>  2 files changed, 17 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e9d2fc9..2e48568 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -293,8 +293,6 @@ config ARCH_BCM283X
>  config TARGET_VEXPRESS_CA15_TC2
>   bool "Support vexpress_ca15_tc2"
>   select CPU_V7
> - select CPU_V7_HAS_NONSEC
> - select CPU_V7_HAS_VIRT
>  
>  config TARGET_VEXPRESS_CA5X2
>   bool "Support vexpress_ca5x2"
> diff --git a/board/armltd/vexpress/vexpress_common.c 
> b/board/armltd/vexpress/vexpress_common.c
> index d3b3b31..fe5d163 100644
> --- a/board/armltd/vexpress/vexpress_common.c
> +++ b/board/armltd/vexpress/vexpress_common.c
> @@ -180,18 +180,3 @@ void lowlevel_init(void)
>  ulong get_board_rev(void){
>   return readl((u32 *)SYS_ID);
>  }
> -
> -#ifdef CONFIG_ARMV7_NONSEC
> -/* Setting the address at which secondary cores start from.
> - * Versatile Express uses one address for all cores, so ignore corenr
> - */
> -void smp_set_core_boot_addr(unsigned long addr, int corenr)
> -{
> - /* The SYSFLAGS register on VExpress needs to be cleared first
> -  * by writing to the next address, since any writes to the address
> -  * at offset 0 will only be ORed in
> -  */
> - writel(~0, CONFIG_SYSFLAGS_ADDR + 4);
> - writel(addr, CONFIG_SYSFLAGS_ADDR);
> -}
> -#endif
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] clk: sandbox: don't check clk ID against 0

[Simon Glass]

On 21 June 2016 at 13:32, Stephen Warren  wrote:
> From: Stephen Warren 
>
> clk->id is unsigned, so it can't be < 0. Remove the check for that.
>
> FWIW, this issue was introduced when the clock API converted e.g.
> clk_get_rate()'s clock ID parameter from an int to an unsigned long
> (with a struct clk), without removing this check.
>
> Fixes: 135aa9500264 ("clk: convert API to match reset/mailbox style")
> Reported-by: Coverity Scan
> Signed-off-by: Stephen Warren 
> ---
>  drivers/clk/clk_sandbox.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

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

[U-Boot] uImage load address and entry point with Minnowboard

[vinoth eswaran]

Hello,

 I am working on an embedded project to optimize the boot time on minnowboard.
Currently I am working with the u-boot. With compressed kernel
(bzImage) everything works fine, I want to check the performance with
uncompressed kernel (vmlinux).

I have found that u-boot cannot support the raw vmlinux and I need to
generate the uImage using the u-boot tools.

I tried creating the uImage from the vmlinux --but I did not
understand what does the -a (load address) and -e (entry point )
points to? I assume that it is the same load address used when loading
the kernel image from sd card to RAM.

uImage creation:

mkimage -A x86 -O linux -T kernel -a 0x0100 -e 0x0100 -n Linux
-d vmlinux uImage
Image Name:   Linux
Created:  Wed Jun 22 16:31:07 2016
Image Type:   Intel x86 Linux Kernel Image (gzip compressed)
Data Size:21966248 Bytes = 21451.41 kB = 20.95 MB
Load Address: 0100
Entry Point:  0100

Now at start up I am seeing that the kernel is not running, Seeing the
following error messages,

reading uImage
21966312 bytes read in 481 ms (43.6 MiB/s)
Wrong Image Format for bootm command
ERROR: can't get kernel image!

The bootcmd is "bootcmd=fatload mmc 0:1 0100 uImage ; bootm 0100"

Do you have any idea why it is happening?

Mit Freundlichen Grüßen
VinothKumar
+49 1798909072
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/9] arm: omap-common: secure ROM signature verify API

[Andreas Dannenberg]

On Wed, Jun 22, 2016 at 10:36:27AM -0400, Tom Rini wrote:
> On Wed, Jun 22, 2016 at 09:21:28AM -0500, Andreas Dannenberg wrote:
> > On Wed, Jun 22, 2016 at 03:13:04PM +0530, Lokesh Vutla wrote:
> > > 
> > > 
> > > On Wednesday 22 June 2016 05:26 AM, Tom Rini wrote:
> > > > On Tue, Jun 21, 2016 at 10:01:54AM +0530, Lokesh Vutla wrote:
> > > >>
> > > >>
> > > >> On Tuesday 21 June 2016 09:04 AM, Andreas Dannenberg wrote:
> > > >>> Adds an API that verifies a signature attached to an image (binary
> > > >>> blob). This API is basically a entry to a secure ROM service provided 
> > > >>> by
> > > >>> the device and accessed via an SMC call, using a particular calling
> > > >>> convention.
> > > >>>
> > > >>> Signed-off-by: Daniel Allred 
> > > >>> Signed-off-by: Andreas Dannenberg 
> > > >>> ---
> > > >>>  arch/arm/cpu/armv7/omap-common/sec-common.c | 76 
> > > >>> +
> > > >>>  arch/arm/include/asm/omap_common.h  |  9 
> > > >>>  2 files changed, 85 insertions(+)
> > > >>>
> > > >>> diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c 
> > > >>> b/arch/arm/cpu/armv7/omap-common/sec-common.c
> > > >>> index b9c0a42..dbb9078 100644
> > > >>> --- a/arch/arm/cpu/armv7/omap-common/sec-common.c
> > > >>> +++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
> > > >>> @@ -16,6 +16,9 @@
> > > >>>  #include 
> > > >>>  #include 
> > > >>>  
> > > >>> +/* Index for signature verify ROM API */
> > > >>> +#define API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX  (0x000E)
> > > >>> +
> > > >>>  static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
> > > >>>  
> > > >>>  u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
> > > >>> @@ -47,3 +50,76 @@ u32 secure_rom_call(u32 service, u32 proc_id, u32 
> > > >>> flag, ...)
> > > >>>  
> > > >>>   return omap_smc_sec(service, proc_id, flag, 
> > > >>> secure_rom_call_args);
> > > >>>  }
> > > >>> +
> > > >>> +static u32 find_sig_start(char *image, size_t size)
> > > >>> +{
> > > >>> + char *image_end = image + size;
> > > >>> + char *sig_start_magic = "CERT_";
> > > >>> + int magic_str_len = strlen(sig_start_magic);
> > > >>> + char *ch;
> > > >>> +
> > > >>> + while (--image_end > image) {
> > > >>> + if (*image_end == '_') {
> > > >>> + ch = image_end - magic_str_len + 1;
> > > >>> + if (!strncmp(ch, sig_start_magic, 
> > > >>> magic_str_len))
> > > >>> + return (u32)ch;
> > > >>> + }
> > > >>> + }
> > > >>> + return 0;
> > > >>> +}
> > > >>> +
> > > >>> +int secure_boot_verify_image(void **image, size_t *size)
> > > >>> +{
> > > >>> + int result = 1;
> > > >>> + u32 cert_addr, sig_addr;
> > > >>> + size_t cert_size;
> > > >>> +
> > > >>> + /* Perform cache writeback on input buffer */
> > > >>> + flush_dcache_range(
> > > >>> + (u32)*image,
> > > >>> + (u32)*image + roundup(*size, ARCH_DMA_MINALIGN));
> > > >>> +
> > > >>> + cert_addr = (uint32_t)*image;
> > > >>> + sig_addr = find_sig_start((char *)*image, *size);
> > > >>> +
> > > >>> + if (sig_addr == 0) {
> > > >>> + printf("No signature found in image.\n");
> > > >>> + result = 1;
> > > >>> + goto auth_exit;
> > > >>> + }
> > > >>> +
> > > >>> + *size = sig_addr - cert_addr;   /* Subtract out the signature 
> > > >>> size */
> > > >>> + cert_size = *size;
> > > >>> +
> > > >>> + /* Check if image load address is 32-bit aligned */
> > > >>> + if (0 != (0x3 & cert_addr)) {
> > > >>
> > > >>if (!IS_ALIGNED(cert_addr, 4)) { ?
> > > >>
> > > >>> + printf("Image is not 4-byte aligned.\n");
> > > >>> + result = 1;
> > > >>> + goto auth_exit;
> > > >>> + }
> > > >>> +
> > > >>> + /* Image size also should be multiple of 4 */
> > > >>> + if (0 != (0x3 & cert_size)) {
> > > >>
> > > >>if (!IS_ALIGNED(cert_size, 4)) { ?
> > > >>
> > > >>> + printf("Image size is not 4-byte aligned.\n");
> > > >>> + result = 1;
> > > >>> + goto auth_exit;
> > > >>> + }
> > > >>> +
> > > >>> + /* Call ROM HAL API to verify certificate signature */
> > > >>> + debug("%s: load_addr = %x, size = %x, sig_addr = %x\n", 
> > > >>> __func__,
> > > >>> +   cert_addr, cert_size, sig_addr);
> > > >>> +
> > > >>> + result = secure_rom_call(
> > > >>> + API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX, 0, 0,
> > > >>> + 4, cert_addr, cert_size, sig_addr, 0x);
> > > >>> +auth_exit:
> > > >>> + if (result != 0) {
> > > >>> + printf("Authentication failed!\n");
> > > >>> + printf("Return Value = %08X\n", result);
> > > >>> + hang();
> > > >>> + }
> > > >>> +
> > > >>> + printf("Authentication passed: %s\n", (char *)sig_addr);
> > > >>
> 

Re: [U-Boot] Pull request: u-boot-net.git master

[Tom Rini]

On Tue, Jun 21, 2016 at 05:04:04PM -0500, Joe Hershberger wrote:

> Hi Tom,
> 
> The following changes since commit 9f823615af919c6b89f0b80197f009f78299dcde:
> 
>   Kconfig: Add a new DISTRO_DEFAULTS Kconfig option (2016-06-20 21:30:13 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to 69fd0d4131c73a3b8a199a8d88fb4e5c688b58d5:
> 
>   NFS: Add error message when U-Boot NFS version (V2) is not supported by NFS 
> server (2016-06-21 17:01:52 -0500)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] pull request: u-boot-uniphier/master (moveconfig)

[Tom Rini]

On Wed, Jun 22, 2016 at 09:27:26AM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> Please pull some udpates of moveconfig.py tool.
> 
> 
> The following changes since commit 9f823615af919c6b89f0b80197f009f78299dcde:
> 
>   Kconfig: Add a new DISTRO_DEFAULTS Kconfig option (2016-06-20 21:30:13 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to fc2661eebe9e788aee61dcb0c9c8337cda1ae93b:
> 
>   tools: moveconfig: show suspicious boards with possible
> misconversion (2016-06-22 09:23:00 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] x86: coreboot: Remove the dummy pch driver

[Simon Glass]

Hi Bin,

On 22 June 2016 at 03:30, Bin Meng  wrote:
> There is a dummy pch driver in the coreboot directory. This causes
> drivers of its children fail to function due to empty ops. Remove
> the whole file since it is no longer needed.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/coreboot/Makefile |  1 -
>  arch/x86/cpu/coreboot/pci.c| 26 --
>  2 files changed, 27 deletions(-)
>  delete mode 100644 arch/x86/cpu/coreboot/pci.c

That was intended to support a PCH where U-Boot did not have to set it
up (when booting from coreboot). Is it not needed now?

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

Re: [U-Boot] [PATCH 5/9] arm: omap-common: secure ROM signature verify API

[Tom Rini]

On Wed, Jun 22, 2016 at 09:21:28AM -0500, Andreas Dannenberg wrote:
> On Wed, Jun 22, 2016 at 03:13:04PM +0530, Lokesh Vutla wrote:
> > 
> > 
> > On Wednesday 22 June 2016 05:26 AM, Tom Rini wrote:
> > > On Tue, Jun 21, 2016 at 10:01:54AM +0530, Lokesh Vutla wrote:
> > >>
> > >>
> > >> On Tuesday 21 June 2016 09:04 AM, Andreas Dannenberg wrote:
> > >>> Adds an API that verifies a signature attached to an image (binary
> > >>> blob). This API is basically a entry to a secure ROM service provided by
> > >>> the device and accessed via an SMC call, using a particular calling
> > >>> convention.
> > >>>
> > >>> Signed-off-by: Daniel Allred 
> > >>> Signed-off-by: Andreas Dannenberg 
> > >>> ---
> > >>>  arch/arm/cpu/armv7/omap-common/sec-common.c | 76 
> > >>> +
> > >>>  arch/arm/include/asm/omap_common.h  |  9 
> > >>>  2 files changed, 85 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c 
> > >>> b/arch/arm/cpu/armv7/omap-common/sec-common.c
> > >>> index b9c0a42..dbb9078 100644
> > >>> --- a/arch/arm/cpu/armv7/omap-common/sec-common.c
> > >>> +++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
> > >>> @@ -16,6 +16,9 @@
> > >>>  #include 
> > >>>  #include 
> > >>>  
> > >>> +/* Index for signature verify ROM API */
> > >>> +#define API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX(0x000E)
> > >>> +
> > >>>  static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
> > >>>  
> > >>>  u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
> > >>> @@ -47,3 +50,76 @@ u32 secure_rom_call(u32 service, u32 proc_id, u32 
> > >>> flag, ...)
> > >>>  
> > >>> return omap_smc_sec(service, proc_id, flag, 
> > >>> secure_rom_call_args);
> > >>>  }
> > >>> +
> > >>> +static u32 find_sig_start(char *image, size_t size)
> > >>> +{
> > >>> +   char *image_end = image + size;
> > >>> +   char *sig_start_magic = "CERT_";
> > >>> +   int magic_str_len = strlen(sig_start_magic);
> > >>> +   char *ch;
> > >>> +
> > >>> +   while (--image_end > image) {
> > >>> +   if (*image_end == '_') {
> > >>> +   ch = image_end - magic_str_len + 1;
> > >>> +   if (!strncmp(ch, sig_start_magic, 
> > >>> magic_str_len))
> > >>> +   return (u32)ch;
> > >>> +   }
> > >>> +   }
> > >>> +   return 0;
> > >>> +}
> > >>> +
> > >>> +int secure_boot_verify_image(void **image, size_t *size)
> > >>> +{
> > >>> +   int result = 1;
> > >>> +   u32 cert_addr, sig_addr;
> > >>> +   size_t cert_size;
> > >>> +
> > >>> +   /* Perform cache writeback on input buffer */
> > >>> +   flush_dcache_range(
> > >>> +   (u32)*image,
> > >>> +   (u32)*image + roundup(*size, ARCH_DMA_MINALIGN));
> > >>> +
> > >>> +   cert_addr = (uint32_t)*image;
> > >>> +   sig_addr = find_sig_start((char *)*image, *size);
> > >>> +
> > >>> +   if (sig_addr == 0) {
> > >>> +   printf("No signature found in image.\n");
> > >>> +   result = 1;
> > >>> +   goto auth_exit;
> > >>> +   }
> > >>> +
> > >>> +   *size = sig_addr - cert_addr;   /* Subtract out the signature 
> > >>> size */
> > >>> +   cert_size = *size;
> > >>> +
> > >>> +   /* Check if image load address is 32-bit aligned */
> > >>> +   if (0 != (0x3 & cert_addr)) {
> > >>
> > >>  if (!IS_ALIGNED(cert_addr, 4)) { ?
> > >>
> > >>> +   printf("Image is not 4-byte aligned.\n");
> > >>> +   result = 1;
> > >>> +   goto auth_exit;
> > >>> +   }
> > >>> +
> > >>> +   /* Image size also should be multiple of 4 */
> > >>> +   if (0 != (0x3 & cert_size)) {
> > >>
> > >>  if (!IS_ALIGNED(cert_size, 4)) { ?
> > >>
> > >>> +   printf("Image size is not 4-byte aligned.\n");
> > >>> +   result = 1;
> > >>> +   goto auth_exit;
> > >>> +   }
> > >>> +
> > >>> +   /* Call ROM HAL API to verify certificate signature */
> > >>> +   debug("%s: load_addr = %x, size = %x, sig_addr = %x\n", 
> > >>> __func__,
> > >>> + cert_addr, cert_size, sig_addr);
> > >>> +
> > >>> +   result = secure_rom_call(
> > >>> +   API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX, 0, 0,
> > >>> +   4, cert_addr, cert_size, sig_addr, 0x);
> > >>> +auth_exit:
> > >>> +   if (result != 0) {
> > >>> +   printf("Authentication failed!\n");
> > >>> +   printf("Return Value = %08X\n", result);
> > >>> +   hang();
> > >>> +   }
> > >>> +
> > >>> +   printf("Authentication passed: %s\n", (char *)sig_addr);
> > >>
> > >> Uart boot will break because of these prints during the FIT loading. Can
> > >> you make this as debug?
> > > 
> > > Are you sure it will break?  There's usually a print in between loading
> > > SPL via UART and 

Re: [U-Boot] [PATCH 5/9] arm: omap-common: secure ROM signature verify API

[Andreas Dannenberg]

On Wed, Jun 22, 2016 at 03:13:04PM +0530, Lokesh Vutla wrote:
> 
> 
> On Wednesday 22 June 2016 05:26 AM, Tom Rini wrote:
> > On Tue, Jun 21, 2016 at 10:01:54AM +0530, Lokesh Vutla wrote:
> >>
> >>
> >> On Tuesday 21 June 2016 09:04 AM, Andreas Dannenberg wrote:
> >>> Adds an API that verifies a signature attached to an image (binary
> >>> blob). This API is basically a entry to a secure ROM service provided by
> >>> the device and accessed via an SMC call, using a particular calling
> >>> convention.
> >>>
> >>> Signed-off-by: Daniel Allred 
> >>> Signed-off-by: Andreas Dannenberg 
> >>> ---
> >>>  arch/arm/cpu/armv7/omap-common/sec-common.c | 76 
> >>> +
> >>>  arch/arm/include/asm/omap_common.h  |  9 
> >>>  2 files changed, 85 insertions(+)
> >>>
> >>> diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c 
> >>> b/arch/arm/cpu/armv7/omap-common/sec-common.c
> >>> index b9c0a42..dbb9078 100644
> >>> --- a/arch/arm/cpu/armv7/omap-common/sec-common.c
> >>> +++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
> >>> @@ -16,6 +16,9 @@
> >>>  #include 
> >>>  #include 
> >>>  
> >>> +/* Index for signature verify ROM API */
> >>> +#define API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX  (0x000E)
> >>> +
> >>>  static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
> >>>  
> >>>  u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
> >>> @@ -47,3 +50,76 @@ u32 secure_rom_call(u32 service, u32 proc_id, u32 
> >>> flag, ...)
> >>>  
> >>>   return omap_smc_sec(service, proc_id, flag, secure_rom_call_args);
> >>>  }
> >>> +
> >>> +static u32 find_sig_start(char *image, size_t size)
> >>> +{
> >>> + char *image_end = image + size;
> >>> + char *sig_start_magic = "CERT_";
> >>> + int magic_str_len = strlen(sig_start_magic);
> >>> + char *ch;
> >>> +
> >>> + while (--image_end > image) {
> >>> + if (*image_end == '_') {
> >>> + ch = image_end - magic_str_len + 1;
> >>> + if (!strncmp(ch, sig_start_magic, magic_str_len))
> >>> + return (u32)ch;
> >>> + }
> >>> + }
> >>> + return 0;
> >>> +}
> >>> +
> >>> +int secure_boot_verify_image(void **image, size_t *size)
> >>> +{
> >>> + int result = 1;
> >>> + u32 cert_addr, sig_addr;
> >>> + size_t cert_size;
> >>> +
> >>> + /* Perform cache writeback on input buffer */
> >>> + flush_dcache_range(
> >>> + (u32)*image,
> >>> + (u32)*image + roundup(*size, ARCH_DMA_MINALIGN));
> >>> +
> >>> + cert_addr = (uint32_t)*image;
> >>> + sig_addr = find_sig_start((char *)*image, *size);
> >>> +
> >>> + if (sig_addr == 0) {
> >>> + printf("No signature found in image.\n");
> >>> + result = 1;
> >>> + goto auth_exit;
> >>> + }
> >>> +
> >>> + *size = sig_addr - cert_addr;   /* Subtract out the signature size */
> >>> + cert_size = *size;
> >>> +
> >>> + /* Check if image load address is 32-bit aligned */
> >>> + if (0 != (0x3 & cert_addr)) {
> >>
> >>if (!IS_ALIGNED(cert_addr, 4)) { ?
> >>
> >>> + printf("Image is not 4-byte aligned.\n");
> >>> + result = 1;
> >>> + goto auth_exit;
> >>> + }
> >>> +
> >>> + /* Image size also should be multiple of 4 */
> >>> + if (0 != (0x3 & cert_size)) {
> >>
> >>if (!IS_ALIGNED(cert_size, 4)) { ?
> >>
> >>> + printf("Image size is not 4-byte aligned.\n");
> >>> + result = 1;
> >>> + goto auth_exit;
> >>> + }
> >>> +
> >>> + /* Call ROM HAL API to verify certificate signature */
> >>> + debug("%s: load_addr = %x, size = %x, sig_addr = %x\n", __func__,
> >>> +   cert_addr, cert_size, sig_addr);
> >>> +
> >>> + result = secure_rom_call(
> >>> + API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX, 0, 0,
> >>> + 4, cert_addr, cert_size, sig_addr, 0x);
> >>> +auth_exit:
> >>> + if (result != 0) {
> >>> + printf("Authentication failed!\n");
> >>> + printf("Return Value = %08X\n", result);
> >>> + hang();
> >>> + }
> >>> +
> >>> + printf("Authentication passed: %s\n", (char *)sig_addr);
> >>
> >> Uart boot will break because of these prints during the FIT loading. Can
> >> you make this as debug?
> > 
> > Are you sure it will break?  There's usually a print in between loading
> > SPL via UART and then U-Boot itself via UART and Y-MODEM is smart enough
> > to re-transmit.
> > 
> 
> Yes, if the print is in between while Y-MODEM is transferring. The above
> print falls in this case.

Tom et al.,
so if this really breaks stuff I need to do something about it. As said
I'd really like to keep the "Authentication passed: "
message in the boot log. So if I implement something along the lines
what Lokesh suggested:

"...you can check if (spl_boot_device() != BOOT_DEVICE_UART) under the  
 
config CONFIG_SPL_YMODEM_SUPPORT. Not sure if it is a good way to do..."

to selectivly suppress the message in case of UART boot, would this be

[U-Boot] Válasz: Továbbítás: u-boot

[kri...@nmdps.net]

Git bisect turned out this commit as first bad. I will try to revert it on 
master, and give it a try.

Thanks,

Küldve az én HTC-mről

- Válaszüzenet -
Feladó: "Heiko Schocher" 
Címzett: 
Másolat: 
Tárgy: [U-Boot] Továbbítás: u-boot
Dátum: Sze, jún. 22, 2016 08:01

Hello Richard,

Am 21.06.2016 um 23:03 schrieb kri...@nmdps.net:
> Dear Heiko,
>
> Sorry for being late.
>
> It seems that code in sunxi_gpio_set_cfgbank is causing the panic.

Hmm.. I see no reason here ... can you debug into it?
I have no bananapi m2, so I could not help much.

you wrote:
>>> I own a bananapi m2, on which u-boot does not boot up since commit
>>> 90b7fc924adfe7f1745dcf6a1dabb9e77aa762a7.

How did you find out, that this commit broke your hw?
If this commit is the reason, can you try to revert this patch?

bye,
Heiko
>
> regards,
>
> 2016-06-09 06:38 időpontban Heiko Schocher ezt írta:
>> Hello,
>>
>> Am 08.06.2016 um 21:50 schrieb kri...@nmdps.net:
>>> Küldve az én HTC-mről
>>>
>>> - Továbbított üzenet -
>>> Feladó: kri...@nmdps.net
>>> Címzett: 
>>> Tárgy: u-boot
>>> Dátum: Sze, jún. 8, 2016 19:12
>>>
>>> Dear developer,
>>>
>>> I own a bananapi m2, on which u-boot does not boot up since commit
>>> 90b7fc924adfe7f1745dcf6a1dabb9e77aa762a7.
>>>
>>> The console is repeating:
>>>
>>> U-Boot 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34 +0200) Allwinner
>>> Technology
>>>
>>> CPU:   Allwinner A31s (SUN6I)
>>> Model: Sinovoip BPI-M2
>>> DRAM:  1 GiB
>>> MMC:   SUNXI SD/MMC: 0
>>> *** Warning - bad CRC, using default environment
>>>
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   data abort
>>> pc : [<7ef5f6f4>]  lr : [<7ef80b94>]
>>> reloc pc : [<4a0016f4>]lr : [<4a022b94>]
>>
>> It seems its in the network init ...
>>
>> Do you have the System.map file for the image? Then you can
>> look into it and find out, which function crashes @0x4a0016f4.
>>
>> bye,
>> Heiko
>>> sp : 7af36f80  ip :  fp : 0017
>>> r10: 7efab5e8  r9 : 7af3dee8 r8 : 40a0
>>> r7 : 7ef9ee0c  r6 :  r5 : 0001  r4 : 
>>> r3 : 7ef80b70  r2 : 0001 r1 :   r0 : ea0e
>>> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
>>> Resetting CPU ...
>>>
>>> resetting ...
>>>
>>> U-Boot SPL 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34)
>>> DRAM: 1024 MiB
>>> Trying to boot from MMC1
>>>
>>>
>>> U-Boot 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34 +0200) Allwinner
>>> Technology
>>>
>>> CPU:   Allwinner A31s (SUN6I)
>>> Model: Sinovoip BPI-M2
>>> DRAM:  1 GiB
>>> MMC:   SUNXI SD/MMC: 0
>>> *** Warning - bad CRC, using default environment
>>>
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   data abort
>>> pc : [<7ef5f6f4>]  lr : [<7ef80b94>]
>>> reloc pc : [<4a0016f4>]lr : [<4a022b94>]
>>> sp : 7af36f80  ip :  fp : 0017
>>> r10: 7efab5e8  r9 : 7af3dee8 r8 : 40a0
>>> r7 : 7ef9ee0c  r6 :  r5 : 0001  r4 : 
>>> r3 : 7ef80b70  r2 : 0001 r1 :   r0 : ea0e
>>> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
>>> Resetting CPU ...
>>>
>>> resetting ...
>>>
>>> U-Boot SPL 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34)
>>> DRAM: 1024 MiB
>>> Trying to boot from MMC1
>>>
>>>
>>> U-Boot 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34 +0200) Allwinner
>>> Technology
>>>
>>> CPU:   Allwinner A31s (SUN6I)
>>> Model: Sinovoip BPI-M2
>>> DRAM:  1 GiB
>>> MMC:   SUNXI SD/MMC: 0
>>> *** Warning - bad CRC, using default environment
>>>
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   data abort
>>> pc : [<7ef5f6f4>]  lr : [<7ef80b94>]
>>> reloc pc : [<4a0016f4>]lr : [<4a022b94>]
>>> sp : 7af36f80  ip :  fp : 0017
>>> r10: 7efab5e8  r9 : 7af3dee8 r8 : 40a0
>>> r7 : 7ef9ee0c  r6 :  r5 : 0001  r4 : 
>>> r3 : 7ef80b70  r2 : 0001 r1 :   r0 : ea0e
>>> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
>>>
>>> and so on.
>>>
>>> How could I help debugging, resolving this issue?
>>>
>>> Regards,
>>> Richard Kojedzinszky
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot-x86 sf probe fail

[杜睿哲_Pegatron]

Hi Bin,

As the earlier post, do you have any comments? Thanks.

Regards,
Hilbert
This e-mail and its attachment may contain PEGATRON Corp information that is 
confidential or privileged, and are solely for the use of the individual to 
whom this e-mail is addressed. If you are not the intended recipient or have 
received it accidentally, please immediately notify the sender by reply e-mail 
and destroy all copies of this email and its attachment. Please be advised that 
any unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK

[Hannes Schmelzer]

> 
> As the help message of CONFIG_BOOTDELAY says, CONFIG_BOOTDELAY=-2
> means the autoboot with no delay, with no abort check even if
> CONFIG_ZERO_BOOTDELAY_CHECK is defined.
> 
> To sum up, the autoboot behaves as follows:
> 
>  [1] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=y
> autoboot with no delay, but you can abort it by key input
> 
>  [2] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
> autoboot with no delay, with no check for abort
> 
>  [3] CONFIG_BOOTDELAY=-1
> disable autoboot
> 
>  [4] CONFIG_BOOTDELAY=-2
> autoboot with no delay, with no check for abort
> 
> As you notice, [2] and [4] come to the same result, which means we
> do not need CONFIG_ZERO_BOOTDELAY_CHECK.  We can control all the
> cases only by CONFIG_BOOTDELAY, like this:
> 
>  [1] CONFIG_BOOTDELAY=0
> autoboot with no delay, but you can abort it by key input
> 
>  [2] CONFIG_BOOTDELAY=-1
> disable autoboot
> 
>  [3] CONFIG_BOOTDELAY=-2
> autoboot with no delay, with no check for abort
> 
> This commit converts the logic as follow:
>   CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
> --> CONFIG_BOOTDELAY=-2
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  common/Kconfig   | 2 +-
>  common/autoboot.c| 6 +-
>  configs/cairo_defconfig  | 2 +-
>  configs/controlcenterd_TRAILBLAZER_DEVELOP_defconfig | 2 +-
>  configs/controlcenterd_TRAILBLAZER_defconfig | 2 +-
>  configs/kwb_defconfig| 2 +-
>  configs/omap3_evm_quick_mmc_defconfig| 2 +-
>  configs/omap3_evm_quick_nand_defconfig   | 2 +-
>  configs/tseries_mmc_defconfig| 2 +-
>  configs/tseries_nand_defconfig   | 2 +-
>  configs/tseries_spi_defconfig| 2 +-
>  doc/README.autoboot  | 8 
>  include/configs/CPCI2DP.h| 1 -
>  include/configs/CPCI4052.h   | 1 -
>  include/configs/MIP405.h | 1 -
>  include/configs/PIP405.h | 1 -
>  include/configs/PLU405.h | 1 -
>  include/configs/PMC405DE.h   | 1 -
>  include/configs/PMC440.h | 1 -
>  include/configs/VCMA9.h  | 1 -
>  include/configs/VOM405.h | 1 -
>  include/configs/a3m071.h | 1 -
>  include/configs/amcc-common.h| 1 -
>  include/configs/apf27.h  | 1 -
>  include/configs/calimain.h   | 1 -
>  include/configs/cm_t35.h | 1 -
>  include/configs/cm_t3517.h   | 1 -
>  include/configs/cm_t43.h | 1 -
>  include/configs/devkit3250.h | 1 -
>  include/configs/digsy_mtc.h  | 1 -
>  include/configs/dlvision-10g.h   | 1 -
>  include/configs/exynos-common.h  | 1 -
>  include/configs/gdppc440etx.h| 1 -
>  include/configs/hrcon.h  | 1 -
>  include/configs/intip.h  | 1 -
>  include/configs/io.h | 1 -
>  include/configs/io64.h   | 1 -
>  include/configs/iocon.h  | 1 -
>  include/configs/legoev3.h| 1 -
>  include/configs/meesc.h  | 1 -
>  include/configs/omap3_logic.h| 1 -
>  include/configs/pcm030.h | 1 -
>  include/configs/r7780mp.h| 1 -
>  include/configs/s5p_goni.h   | 1 -
>  include/configs/smdk2410.h   | 1 -
>  include/configs/smdkc100.h   | 1 -
>  include/configs/snapper9260.h| 1 -
>  include/configs/snapper9g45.h| 1 -
>  include/configs/spear-common.h   | 1 -
>  include/configs/strider.h| 1 -
>  include/configs/theadorable.h| 1 -
>  include/configs/tricorder.h  | 1 -
>  include/configs/uniphier.h   | 1 -
>  include/configs/vinco.h  | 1 -
>  include/configs/work_92105.h | 1 -
>  include/configs/x600.h   | 1 -
>  include/configs/xilinx-ppc.h | 1 -
>  57 files changed, 11 insertions(+), 68 deletions(-)

For tseries board

Acked-by: Hannes Schmelzer 


___
U-Boot mailing list

Re: [U-Boot] [PATCH 3/6] autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK

[Heiko Schocher]

Hello Masahiro,

Am 21.06.2016 um 07:32 schrieb Masahiro Yamada:

As the help message of CONFIG_BOOTDELAY says, CONFIG_BOOTDELAY=-2
means the autoboot with no delay, with no abort check even if
CONFIG_ZERO_BOOTDELAY_CHECK is defined.

To sum up, the autoboot behaves as follows:

  [1] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=y
 autoboot with no delay, but you can abort it by key input

  [2] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
 autoboot with no delay, with no check for abort

  [3] CONFIG_BOOTDELAY=-1
 disable autoboot

  [4] CONFIG_BOOTDELAY=-2
 autoboot with no delay, with no check for abort

As you notice, [2] and [4] come to the same result, which means we
do not need CONFIG_ZERO_BOOTDELAY_CHECK.  We can control all the
cases only by CONFIG_BOOTDELAY, like this:

  [1] CONFIG_BOOTDELAY=0
 autoboot with no delay, but you can abort it by key input

  [2] CONFIG_BOOTDELAY=-1
 disable autoboot

  [3] CONFIG_BOOTDELAY=-2
 autoboot with no delay, with no check for abort

This commit converts the logic as follow:
   CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
 --> CONFIG_BOOTDELAY=-2

Signed-off-by: Masahiro Yamada 
---

  common/Kconfig   | 2 +-
  common/autoboot.c| 6 +-
  configs/cairo_defconfig  | 2 +-
  configs/controlcenterd_TRAILBLAZER_DEVELOP_defconfig | 2 +-
  configs/controlcenterd_TRAILBLAZER_defconfig | 2 +-
  configs/kwb_defconfig| 2 +-
  configs/omap3_evm_quick_mmc_defconfig| 2 +-
  configs/omap3_evm_quick_nand_defconfig   | 2 +-
  configs/tseries_mmc_defconfig| 2 +-
  configs/tseries_nand_defconfig   | 2 +-
  configs/tseries_spi_defconfig| 2 +-
  doc/README.autoboot  | 8 
  include/configs/CPCI2DP.h| 1 -
  include/configs/CPCI4052.h   | 1 -
  include/configs/MIP405.h | 1 -
  include/configs/PIP405.h | 1 -
  include/configs/PLU405.h | 1 -
  include/configs/PMC405DE.h   | 1 -
  include/configs/PMC440.h | 1 -
  include/configs/VCMA9.h  | 1 -
  include/configs/VOM405.h | 1 -
  include/configs/a3m071.h | 1 -
  include/configs/amcc-common.h| 1 -
  include/configs/apf27.h  | 1 -
  include/configs/calimain.h   | 1 -
  include/configs/cm_t35.h | 1 -
  include/configs/cm_t3517.h   | 1 -
  include/configs/cm_t43.h | 1 -
  include/configs/devkit3250.h | 1 -
  include/configs/digsy_mtc.h  | 1 -
  include/configs/dlvision-10g.h   | 1 -
  include/configs/exynos-common.h  | 1 -
  include/configs/gdppc440etx.h| 1 -
  include/configs/hrcon.h  | 1 -
  include/configs/intip.h  | 1 -
  include/configs/io.h | 1 -
  include/configs/io64.h   | 1 -
  include/configs/iocon.h  | 1 -
  include/configs/legoev3.h| 1 -
  include/configs/meesc.h  | 1 -
  include/configs/omap3_logic.h| 1 -
  include/configs/pcm030.h | 1 -
  include/configs/r7780mp.h| 1 -
  include/configs/s5p_goni.h   | 1 -
  include/configs/smdk2410.h   | 1 -
  include/configs/smdkc100.h   | 1 -
  include/configs/snapper9260.h| 1 -
  include/configs/snapper9g45.h| 1 -
  include/configs/spear-common.h   | 1 -
  include/configs/strider.h| 1 -
  include/configs/theadorable.h| 1 -
  include/configs/tricorder.h  | 1 -
  include/configs/uniphier.h   | 1 -
  include/configs/vinco.h  | 1 -
  include/configs/work_92105.h | 1 -
  include/configs/x600.h   | 1 -
  include/configs/xilinx-ppc.h | 1 -
  57 files changed, 11 insertions(+), 68 deletions(-)


Thanks!

Reviewed-by: Heiko Schocher 

bye,
Heiko


diff --git a/common/Kconfig b/common/Kconfig
index a94c7b9..aae754b 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -103,9 +103,9 @@ config 

Re: [U-Boot] [PATCH 3/6] autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK

[Vladimir Zapolskiy]

On 21.06.2016 08:32, Masahiro Yamada wrote:
> As the help message of CONFIG_BOOTDELAY says, CONFIG_BOOTDELAY=-2
> means the autoboot with no delay, with no abort check even if
> CONFIG_ZERO_BOOTDELAY_CHECK is defined.
> 
> To sum up, the autoboot behaves as follows:
> 
>  [1] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=y
> autoboot with no delay, but you can abort it by key input
> 
>  [2] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
> autoboot with no delay, with no check for abort
> 
>  [3] CONFIG_BOOTDELAY=-1
> disable autoboot
> 
>  [4] CONFIG_BOOTDELAY=-2
> autoboot with no delay, with no check for abort
> 
> As you notice, [2] and [4] come to the same result, which means we
> do not need CONFIG_ZERO_BOOTDELAY_CHECK.  We can control all the
> cases only by CONFIG_BOOTDELAY, like this:
> 
>  [1] CONFIG_BOOTDELAY=0
> autoboot with no delay, but you can abort it by key input
> 
>  [2] CONFIG_BOOTDELAY=-1
> disable autoboot
> 
>  [3] CONFIG_BOOTDELAY=-2
> autoboot with no delay, with no check for abort
> 
> This commit converts the logic as follow:
>   CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
> --> CONFIG_BOOTDELAY=-2
> 
> Signed-off-by: Masahiro Yamada 
> ---

>  include/configs/devkit3250.h | 1 -

For devikit3250 board

Acked-by: Vladimir Zapolskiy 

> diff --git a/include/configs/devkit3250.h b/include/configs/devkit3250.h
> index 73f53d4..22f4322 100644
> --- a/include/configs/devkit3250.h
> +++ b/include/configs/devkit3250.h
> @@ -178,7 +178,6 @@
>   */
>  #define CONFIG_CMDLINE_TAG
>  #define CONFIG_SETUP_MEMORY_TAGS
> -#define CONFIG_ZERO_BOOTDELAY_CHECK
>  
>  #define CONFIG_BOOTFILE  "uImage"
>  #define CONFIG_BOOTARGS  "console=ttyS0,115200n8"

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

[U-Boot] [PATCH v2] i2c_eeprom: Add reading support

[Mario Six]

From: "mario@gdsys.cc" 

This patch implements the reading functionality for the generic I2C
EEPROM driver, which was just a non-functional stub until now.

Since the page size will be of importance for the writing support, we
add suitable members to the private data structure to keep track of it.

Compatibility strings for a range of at24c* chips are added.

Signed-off-by: Mario Six 
---

Changes in v2:
 - Simplified and documented the i2c_eeprom struct
 - Simplified the read function
 - Corrected Kconfig dependency (from DM to MISC)

---
 drivers/misc/Kconfig  |  5 +
 drivers/misc/i2c_eeprom.c | 39 +++
 include/i2c_eeprom.h  |  4 
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 2373037..b84e351 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -144,4 +144,9 @@ config QFW
  Hidden option to enable QEMU fw_cfg interface. This will be selected 
by
  either CONFIG_CMD_QFW or CONFIG_GENERATE_ACPI_TABLE.

+config I2C_EEPROM
+   bool "Enable driver for generic I2C-attached EEPROMs"
+   depends on MISC
+   help
+ Enable a generic driver for EEPROMs attached via I2C.
 endmenu
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
index 814134a..c9f4174 100644
--- a/drivers/misc/i2c_eeprom.c
+++ b/drivers/misc/i2c_eeprom.c
@@ -13,7 +13,7 @@
 static int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf,
   int size)
 {
-   return -ENODEV;
+   return dm_i2c_read(dev, offset, buf, size);
 }

 static int i2c_eeprom_write(struct udevice *dev, int offset,
@@ -27,23 +27,46 @@ struct i2c_eeprom_ops i2c_eeprom_std_ops = {
.write  = i2c_eeprom_write,
 };

+static int i2c_eeprom_std_ofdata_to_platdata(struct udevice *dev)
+{
+   struct i2c_eeprom *priv = dev_get_priv(dev);
+   u64 data = dev_get_driver_data(dev);
+
+   /* 6 bit -> page size of up to 2^63 (should be sufficient) */
+   priv->pagewidth = data & 0x3F;
+   priv->pagesize = (1 << priv->pagewidth);
+
+   return 0;
+}
+
 int i2c_eeprom_std_probe(struct udevice *dev)
 {
return 0;
 }

 static const struct udevice_id i2c_eeprom_std_ids[] = {
-   { .compatible = "i2c-eeprom" },
+   { .compatible = "i2c-eeprom", .data = 0 },
+   { .compatible = "atmel,24c01a", .data = 3 },
+   { .compatible = "atmel,24c02", .data = 3 },
+   { .compatible = "atmel,24c04", .data = 4 },
+   { .compatible = "atmel,24c08a", .data = 4 },
+   { .compatible = "atmel,24c16a", .data = 4 },
+   { .compatible = "atmel,24c32", .data = 5 },
+   { .compatible = "atmel,24c64", .data = 5 },
+   { .compatible = "atmel,24c128", .data = 6 },
+   { .compatible = "atmel,24c256", .data = 6 },
+   { .compatible = "atmel,24c512", .data = 6 },
{ }
 };

 U_BOOT_DRIVER(i2c_eeprom_std) = {
-   .name   = "i2c_eeprom",
-   .id = UCLASS_I2C_EEPROM,
-   .of_match   = i2c_eeprom_std_ids,
-   .probe  = i2c_eeprom_std_probe,
-   .priv_auto_alloc_size = sizeof(struct i2c_eeprom),
-   .ops= _eeprom_std_ops,
+   .name   = "i2c_eeprom",
+   .id = UCLASS_I2C_EEPROM,
+   .of_match   = i2c_eeprom_std_ids,
+   .probe  = i2c_eeprom_std_probe,
+   .ofdata_to_platdata = i2c_eeprom_std_ofdata_to_platdata,
+   .priv_auto_alloc_size   = sizeof(struct i2c_eeprom),
+   .ops= _eeprom_std_ops,
 };

 UCLASS_DRIVER(i2c_eeprom) = {
diff --git a/include/i2c_eeprom.h b/include/i2c_eeprom.h
index ea6c962..0452892 100644
--- a/include/i2c_eeprom.h
+++ b/include/i2c_eeprom.h
@@ -14,6 +14,10 @@ struct i2c_eeprom_ops {
 };

 struct i2c_eeprom {
+   /* The EEPROM's page size in byte */
+   unsigned long pagesize;
+   /* The EEPROM's page width in bits (pagesize = 2^pagewidth) */
+   unsigned pagewidth;
 };

 #endif
--
2.7.0.GIT

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

[U-Boot] Booting imx7d from qspi using spansion flash (WAS Re: [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128)

[Michael Trimarchi]

Hi Ye.Li

On Wed, Jun 22, 2016 at 10:14:29AM +, Yao Yuan wrote:
> On 06/22/2016 06:08 PM, Michael Trimarchi wrote:
> > On Wed, Jun 22, 2016 at 10:00:49AM +, Yao Yuan wrote:
> > > On 06/22/2016 03:59 PM, Michael Trimarchi wrote:
> > > > The S25FS128 is part of S25FS-S family physical sectors may be
> > > > configured as a hybrid combination of eight 4-kB parameter sectors
> > > > at the top or bottom of the address space with all but one of the
> > > > remaining sectors being uniform size. This rework a bit commit
> > > >
> > > > 80c1bfd2332e71dfe669cac53ba06b7435a7ca39
> > > >
> > > > and add this jedec part number
> > > >
> > > > Signed-off-by: Michael Trimarchi 
> > > > ---
> > > >  drivers/mtd/spi/spi_flash.c | 18 --
> > > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/mtd/spi/spi_flash.c
> > > > b/drivers/mtd/spi/spi_flash.c index
> > > > 64d4e0f..c993588 100644
> > > > --- a/drivers/mtd/spi/spi_flash.c
> > > > +++ b/drivers/mtd/spi/spi_flash.c
> > > > @@ -972,6 +972,21 @@ int spi_flash_decode_fdt(const void *blob,
> > > > struct spi_flash *flash)  #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
> > > >
> > > >  #ifdef CONFIG_SPI_FLASH_SPANSION
> > > > +
> > > > +inline int is_spansion_s25fss_family(u16 jedec, u16 ext_jedec) {
> > > > +   switch (jedec) {
> > > > +   case 0x0219:
> > > > +   case 0x0220:
> > > > +   case 0x2018:
> > > > +   if ((ext_jedec & 0xff00) == 0x4d00)
> > > > +   return 1;
> > > > +   default:;
> > > > +   }
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > >  static int spansion_s25fss_disable_4KB_erase(struct spi_slave *spi)  {
> > > > u8 cmd[4];
> > > > @@ -1072,8 +1087,7 @@ int spi_flash_scan(struct spi_flash *flash)
> > > >  * sector that is not overlaid by the parameter sectors.
> > > >  * The uniform sector erase command has no effect on parameter
> > > > sectors.
> > > >  */
> > > > -   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> > > > -   (ext_jedec & 0xff00) == 0x4d00) {
> > > > +   if (is_spansion_s25fss_family(jedec, ext_jedec)) {
> > > > int ret;
> > > > u8 id[6];
> > > >
> > > > --
> > >
> > > Hi Michael,
> > > From some datasheet for spansion flash, it seems all the spansion
> > > S25FS family should disable 4kb.
> > > So how about just judge the idcode[0]?
> > >
> > 
> > I understand your point but I don't have enough part number and I can only 
> > to
> > test on this one. I will verify this patch too and put my review and drop my
> > personal one. Anyway can you ask if the first 0x8000 are considered by boot
> > rom? I'm trying to boot from qspi an imx7d board and I create the parameter
> > using the files/qspi-nor-spansion-s25fl128s-config but not sure if I need 
> > to flash
> > from 0x400 or from 0x8400. And then I think that bootloader should go from
> > 0x1000 or from 0x9000 correct?
> > Then from BOOT_FROM I choose qspi but what is the DEFAULT_ADDRESS
> > 0x1000 or 0x400?
> > 
> 
> I'm not sure what's the offset for imx7d, but for NXP LS series SOC.
> The RCW_PBI offset: 0x0
> The Uboot offset is defined by RCW_PBI code.(Such as 0x1)
> 

I have seen that the booting from QSPI come from you. Do you have an idea about
imx7d booting from QSPI?

Michael

> > > Like:
> > > diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> > > index 64d4e0f..cfe3649 100644
> > > --- a/drivers/mtd/spi/spi_flash.c
> > > +++ b/drivers/mtd/spi/spi_flash.c
> > > @@ -1072,8 +1072,7 @@ int spi_flash_scan(struct spi_flash *flash)
> > >  * sector that is not overlaid by the parameter sectors.
> > >  * The uniform sector erase command has no effect on parameter 
> > > sectors.
> > >  */
> > > -   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> > > -   (ext_jedec & 0xff00) == 0x4d00) {
> > > +   if (idcode[0] == SPI_FLASH_CFI_MFR_SPANSION) {
> > > int ret;
> > > u8 id[6];
> > >
> > >
> > > How about your think?
> > 
> > For me is fine if you are sure
> > 
> > Michael
> > 
> > >
> > >
> > >
> > 
> > --
> > | Michael Nazzareno Trimarchi Amarula Solutions BV |
> > | COO  -  Founder  Cruquiuskade 47 |
> > | +31(0)851119172 Amsterdam 1018 AM NL |
> > |  [`as] http://www.amarulasolutions.com   |

-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work with MX6 duallite

[Hannes Schmelzer]

if we build for an i.mx6 (d)ual(l)ite CONFIC_MX6DL we shall use
MX6DL_PAD instead the common MX6_PAD.

Signed-off-by: Hannes Schmelzer 
---

 arch/arm/include/asm/arch-mx6/mx6-pins.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/mx6-pins.h 
b/arch/arm/include/asm/arch-mx6/mx6-pins.h
index 4b6bb18..3465205 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-pins.h
@@ -18,7 +18,7 @@ enum {
 #include "mx6q_pins.h"
 #undef MX6_PAD_DECL
 #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
-   MX6_PAD_DECLARE(MX6DL_PAD_,name, pco, mc, mm, sio, si, pc),
+   MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
 #include "mx6dl_pins.h"
 };
 #elif defined(CONFIG_MX6Q)
@@ -30,7 +30,7 @@ enum {
 #elif defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
 enum {
 #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
-   MX6_PAD_DECLARE(MX6_PAD_,name, pco, mc, mm, sio, si, pc),
+   MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
 #include "mx6dl_pins.h"
 };
 #elif defined(CONFIG_MX6SL)
-- 
1.9.1

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

[U-Boot] [PATCH] driver/net/fec: support fixed speed connection

[Hannes Schmelzer]

If MAC is directly connected to another MAC (like a switch for example)
we don't need to probe for a phy, autoneogation and so on. We simply
have to setup speed.

Signed-off-by: Hannes Schmelzer 
---

 doc/README.fec_mxc| 5 +
 drivers/net/fec_mxc.c | 4 
 2 files changed, 9 insertions(+)

diff --git a/doc/README.fec_mxc b/doc/README.fec_mxc
index ed7e47d..9ca6ac2 100644
--- a/doc/README.fec_mxc
+++ b/doc/README.fec_mxc
@@ -27,6 +27,11 @@ CONFIG_FEC_MXC_PHYADDR
Optional, selects the exact phy address that should be connected
and function fecmxc_initialize will try to initialize it.
 
+CONFIG_FEC_FIXED_SPEED
+   Optional, selects a fixed speed on the MAC interface without asking some
+   phy. This is usefull if there is a direct MAC <-> MAC connection, for
+   example if the CPU is connected directly via the RGMII interface to a
+   ethernet-switch.
 
 Reading the ethaddr from the SoC eFuses:
 if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 360f8e4..e871b3e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -233,6 +233,7 @@ static int miiphy_restart_aneg(struct eth_device *dev)
return ret;
 }
 
+#ifndef CONFIG_FEC_FIXED_SPEED
 static int miiphy_wait_aneg(struct eth_device *dev)
 {
uint32_t start;
@@ -260,6 +261,7 @@ static int miiphy_wait_aneg(struct eth_device *dev)
 
return 0;
 }
+#endif /* CONFIG_FEC_FIXED_SPEED */
 #endif
 
 static int fec_rx_task_enable(struct fec_priv *fec)
@@ -502,6 +504,8 @@ static int fec_open(struct eth_device *edev)
}
speed = fec->phydev->speed;
}
+#elif CONFIG_FEC_FIXED_SPEED
+   speed = CONFIG_FEC_FIXED_SPEED;
 #else
miiphy_wait_aneg(edev);
speed = miiphy_speed(edev->name, fec->phy_id);
-- 
1.9.1

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

[U-Boot] [PATCH v1 2/2] board/BuR: rename kwb board to brxre1

[Hannes Schmelzer]

Rename B kwb board to brxre1

Signed-off-by: Hannes Schmelzer 
---

 arch/arm/Kconfig| 6 +++---
 board/BuR/{kwb => brxre1}/Kconfig   | 6 +++---
 board/BuR/brxre1/MAINTAINERS| 6 ++
 board/BuR/{kwb => brxre1}/Makefile  | 0
 board/BuR/{kwb => brxre1}/board.c   | 6 +++---
 board/BuR/{kwb => brxre1}/mux.c | 0
 board/BuR/kwb/MAINTAINERS   | 6 --
 configs/{kwb_defconfig => brxre1_defconfig} | 2 +-
 include/configs/{kwb.h => brxre1.h} | 8 
 9 files changed, 20 insertions(+), 20 deletions(-)
 rename board/BuR/{kwb => brxre1}/Kconfig (68%)
 create mode 100644 board/BuR/brxre1/MAINTAINERS
 rename board/BuR/{kwb => brxre1}/Makefile (100%)
 rename board/BuR/{kwb => brxre1}/board.c (98%)
 rename board/BuR/{kwb => brxre1}/mux.c (100%)
 delete mode 100644 board/BuR/kwb/MAINTAINERS
 rename configs/{kwb_defconfig => brxre1_defconfig} (97%)
 rename include/configs/{kwb.h => brxre1.h} (97%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3c2c755..3237a74 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -304,8 +304,8 @@ config TARGET_VEXPRESS_CA9X4
bool "Support vexpress_ca9x4"
select CPU_V7
 
-config TARGET_KWB
-   bool "Support kwb"
+config TARGET_BRXRE1
+   bool "Support BRXRE1"
select CPU_V7
select SUPPORT_SPL
 
@@ -908,7 +908,7 @@ source "arch/arm/cpu/armv8/Kconfig"
 source "arch/arm/imx-common/Kconfig"
 
 source "board/bosch/shc/Kconfig"
-source "board/BuR/kwb/Kconfig"
+source "board/BuR/brxre1/Kconfig"
 source "board/BuR/brppt1/Kconfig"
 source "board/CarMediaLab/flea3/Kconfig"
 source "board/Marvell/aspenite/Kconfig"
diff --git a/board/BuR/kwb/Kconfig b/board/BuR/brxre1/Kconfig
similarity index 68%
rename from board/BuR/kwb/Kconfig
rename to board/BuR/brxre1/Kconfig
index 4beefbf..389e523 100644
--- a/board/BuR/kwb/Kconfig
+++ b/board/BuR/brxre1/Kconfig
@@ -1,7 +1,7 @@
-if TARGET_KWB
+if TARGET_BRXRE1
 
 config SYS_BOARD
-   default "kwb"
+   default "brxre1"
 
 config SYS_VENDOR
default "BuR"
@@ -10,6 +10,6 @@ config SYS_SOC
default "am33xx"
 
 config SYS_CONFIG_NAME
-   default "kwb"
+   default "brxre1"
 
 endif
diff --git a/board/BuR/brxre1/MAINTAINERS b/board/BuR/brxre1/MAINTAINERS
new file mode 100644
index 000..a10d9c1
--- /dev/null
+++ b/board/BuR/brxre1/MAINTAINERS
@@ -0,0 +1,6 @@
+BRXRE1 BOARD
+M: Hannes Schmelzer 
+S: Maintained
+F: board/BuR/brxre1/
+F: include/configs/brxre1.h
+F: configs/brxre1_defconfig
diff --git a/board/BuR/kwb/Makefile b/board/BuR/brxre1/Makefile
similarity index 100%
rename from board/BuR/kwb/Makefile
rename to board/BuR/brxre1/Makefile
diff --git a/board/BuR/kwb/board.c b/board/BuR/brxre1/board.c
similarity index 98%
rename from board/BuR/kwb/board.c
rename to board/BuR/brxre1/board.c
index ad74ff2..f4bfa41 100644
--- a/board/BuR/kwb/board.c
+++ b/board/BuR/brxre1/board.c
@@ -1,7 +1,7 @@
 /*
  * board.c
  *
- * Board functions for B KWB Board
+ * Board functions for B BRXRE1 Board
  *
  * Copyright (C) 2013 Hannes Schmelzer 
  * Bernecker & Rainer Industrieelektronik GmbH - http://www.br-automation.com
@@ -101,7 +101,7 @@ void am33xx_spl_board_init(void)
 */
u32 *const clk_domains[] = { 0 };
 
-   u32 *const clk_modules_kwbspecific[] = {
+   u32 *const clk_modules_xre1specific[] = {
>wkup_adctscctrl,
>spi1clkctrl,
>dcan0clkctrl,
@@ -113,7 +113,7 @@ void am33xx_spl_board_init(void)
>lcdcclkstctrl,
0
};
-   do_enable_clocks(clk_domains, clk_modules_kwbspecific, 1);
+   do_enable_clocks(clk_domains, clk_modules_xre1specific, 1);
/* setup LCD-Pixel Clock */
writel(0x2, CM_DPLL + 0x34);
/* power-OFF LCD-Display */
diff --git a/board/BuR/kwb/mux.c b/board/BuR/brxre1/mux.c
similarity index 100%
rename from board/BuR/kwb/mux.c
rename to board/BuR/brxre1/mux.c
diff --git a/board/BuR/kwb/MAINTAINERS b/board/BuR/kwb/MAINTAINERS
deleted file mode 100644
index ca7d329..000
--- a/board/BuR/kwb/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-KWB BOARD
-M: Hannes Schmelzer 
-S: Maintained
-F: board/BuR/kwb/
-F: include/configs/kwb.h
-F: configs/kwb_defconfig
diff --git a/configs/kwb_defconfig b/configs/brxre1_defconfig
similarity index 97%
rename from configs/kwb_defconfig
rename to configs/brxre1_defconfig
index 790292e..13617d3 100644
--- a/configs/kwb_defconfig
+++ b/configs/brxre1_defconfig
@@ -1,5 +1,5 @@
 CONFIG_ARM=y
-CONFIG_TARGET_KWB=y
+CONFIG_TARGET_BRXRE1=y
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1"
 CONFIG_BOOTDELAY=0
diff --git a/include/configs/kwb.h b/include/configs/brxre1.h
similarity index 97%
rename from include/configs/kwb.h
rename to include/configs/brxre1.h
index 

[U-Boot] [PATCH v1 1/2] board/BuR: rename tseries board to brppt1

[Hannes Schmelzer]

Rename B tseries board to brppt1

Signed-off-by: Hannes Schmelzer 
---

 arch/arm/Kconfig  | 6 +++---
 board/BuR/{tseries => brppt1}/Kconfig | 6 +++---
 board/BuR/brppt1/MAINTAINERS  | 8 
 board/BuR/{tseries => brppt1}/Makefile| 0
 board/BuR/{tseries => brppt1}/board.c | 2 +-
 board/BuR/{tseries => brppt1}/mux.c   | 2 +-
 board/BuR/tseries/MAINTAINERS | 8 
 configs/{tseries_mmc_defconfig => brppt1_mmc_defconfig}   | 2 +-
 configs/{tseries_nand_defconfig => brppt1_nand_defconfig} | 2 +-
 configs/{tseries_spi_defconfig => brppt1_spi_defconfig}   | 2 +-
 include/configs/{tseries.h => brppt1.h}   | 8 
 11 files changed, 23 insertions(+), 23 deletions(-)
 rename board/BuR/{tseries => brppt1}/Kconfig (67%)
 create mode 100644 board/BuR/brppt1/MAINTAINERS
 rename board/BuR/{tseries => brppt1}/Makefile (100%)
 rename board/BuR/{tseries => brppt1}/board.c (99%)
 rename board/BuR/{tseries => brppt1}/mux.c (99%)
 delete mode 100644 board/BuR/tseries/MAINTAINERS
 rename configs/{tseries_mmc_defconfig => brppt1_mmc_defconfig} (97%)
 rename configs/{tseries_nand_defconfig => brppt1_nand_defconfig} (97%)
 rename configs/{tseries_spi_defconfig => brppt1_spi_defconfig} (97%)
 rename include/configs/{tseries.h => brppt1.h} (98%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e9d2fc9..3c2c755 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -309,8 +309,8 @@ config TARGET_KWB
select CPU_V7
select SUPPORT_SPL
 
-config TARGET_TSERIES
-   bool "Support tseries"
+config TARGET_BRPPT1
+   bool "Support BRPPT1"
select CPU_V7
select SUPPORT_SPL
 
@@ -909,7 +909,7 @@ source "arch/arm/imx-common/Kconfig"
 
 source "board/bosch/shc/Kconfig"
 source "board/BuR/kwb/Kconfig"
-source "board/BuR/tseries/Kconfig"
+source "board/BuR/brppt1/Kconfig"
 source "board/CarMediaLab/flea3/Kconfig"
 source "board/Marvell/aspenite/Kconfig"
 source "board/Marvell/gplugd/Kconfig"
diff --git a/board/BuR/tseries/Kconfig b/board/BuR/brppt1/Kconfig
similarity index 67%
rename from board/BuR/tseries/Kconfig
rename to board/BuR/brppt1/Kconfig
index ed48300..e006c80 100644
--- a/board/BuR/tseries/Kconfig
+++ b/board/BuR/brppt1/Kconfig
@@ -1,7 +1,7 @@
-if TARGET_TSERIES
+if TARGET_BRPPT1
 
 config SYS_BOARD
-   default "tseries"
+   default "brppt1"
 
 config SYS_VENDOR
default "BuR"
@@ -10,6 +10,6 @@ config SYS_SOC
default "am33xx"
 
 config SYS_CONFIG_NAME
-   default "tseries"
+   default "brppt1"
 
 endif
diff --git a/board/BuR/brppt1/MAINTAINERS b/board/BuR/brppt1/MAINTAINERS
new file mode 100644
index 000..9eddab4
--- /dev/null
+++ b/board/BuR/brppt1/MAINTAINERS
@@ -0,0 +1,8 @@
+BRPPT1 BOARD
+M: Hannes Schmelzer 
+S: Maintained
+F: board/BuR/brppt1/
+F: include/configs/brppt1.h
+F: configs/brppt1_mmc_defconfig
+F: configs/brppt1_nand_defconfig
+F: configs/brppt1_spi_defconfig
diff --git a/board/BuR/tseries/Makefile b/board/BuR/brppt1/Makefile
similarity index 100%
rename from board/BuR/tseries/Makefile
rename to board/BuR/brppt1/Makefile
diff --git a/board/BuR/tseries/board.c b/board/BuR/brppt1/board.c
similarity index 99%
rename from board/BuR/tseries/board.c
rename to board/BuR/brppt1/board.c
index bc119e6..a227221 100644
--- a/board/BuR/tseries/board.c
+++ b/board/BuR/brppt1/board.c
@@ -1,7 +1,7 @@
 /*
  * board.c
  *
- * Board functions for B LEIT Board
+ * Board functions for B BRPPT1
  *
  * Copyright (C) 2013 Hannes Schmelzer 
  * Bernecker & Rainer Industrieelektronik GmbH - http://www.br-automation.com
diff --git a/board/BuR/tseries/mux.c b/board/BuR/brppt1/mux.c
similarity index 99%
rename from board/BuR/tseries/mux.c
rename to board/BuR/brppt1/mux.c
index 349788a..ab3788f 100644
--- a/board/BuR/tseries/mux.c
+++ b/board/BuR/brppt1/mux.c
@@ -1,7 +1,7 @@
 /*
  * mux.c
  *
- * Pinmux Setting for B LEIT Board(s)
+ * Pinmux Setting for B BRPPT1 Board(s)
  *
  * Copyright (C) 2013 Hannes Schmelzer 
  * Bernecker & Rainer Industrieelektronik GmbH - http://www.br-automation.com
diff --git a/board/BuR/tseries/MAINTAINERS b/board/BuR/tseries/MAINTAINERS
deleted file mode 100644
index e2e67e6..000
--- a/board/BuR/tseries/MAINTAINERS
+++ /dev/null
@@ -1,8 +0,0 @@
-TSERIES BOARD
-M: Hannes Schmelzer 
-S: Maintained
-F: board/BuR/tseries/
-F: include/configs/tseries.h
-F: configs/tseries_mmc_defconfig
-F: configs/tseries_nand_defconfig
-F: configs/tseries_spi_defconfig
diff --git a/configs/tseries_mmc_defconfig b/configs/brppt1_mmc_defconfig
similarity index 97%
rename from configs/tseries_mmc_defconfig
rename to configs/brppt1_mmc_defconfig
index 337404b..f8d9de5 100644
--- 

[U-Boot] [PATCH v1 0/2] Rename all B boards to more meaningful name

[Hannes Schmelzer]

We've internally decided to name all B boards to be related in the
final product where they are built in, which is more meaningful than the
name of the circuit board itself.


Hannes Schmelzer (2):
  board/BuR: rename tseries board to brppt1
  board/BuR: rename kwb board to brxre1

 arch/arm/Kconfig  | 12 ++--
 board/BuR/{kwb => brppt1}/Kconfig |  6 +++---
 board/BuR/brppt1/MAINTAINERS  |  8 
 board/BuR/{tseries => brppt1}/Makefile|  0
 board/BuR/{tseries => brppt1}/board.c |  2 +-
 board/BuR/{tseries => brppt1}/mux.c   |  2 +-
 board/BuR/{tseries => brxre1}/Kconfig |  6 +++---
 board/BuR/brxre1/MAINTAINERS  |  6 ++
 board/BuR/{kwb => brxre1}/Makefile|  0
 board/BuR/{kwb => brxre1}/board.c |  6 +++---
 board/BuR/{kwb => brxre1}/mux.c   |  0
 board/BuR/kwb/MAINTAINERS |  6 --
 board/BuR/tseries/MAINTAINERS |  8 
 configs/{tseries_mmc_defconfig => brppt1_mmc_defconfig}   |  2 +-
 configs/{tseries_nand_defconfig => brppt1_nand_defconfig} |  2 +-
 configs/{tseries_spi_defconfig => brppt1_spi_defconfig}   |  2 +-
 configs/{kwb_defconfig => brxre1_defconfig}   |  2 +-
 include/configs/{tseries.h => brppt1.h}   |  8 
 include/configs/{kwb.h => brxre1.h}   |  8 
 19 files changed, 43 insertions(+), 43 deletions(-)
 rename board/BuR/{kwb => brppt1}/Kconfig (68%)
 create mode 100644 board/BuR/brppt1/MAINTAINERS
 rename board/BuR/{tseries => brppt1}/Makefile (100%)
 rename board/BuR/{tseries => brppt1}/board.c (99%)
 rename board/BuR/{tseries => brppt1}/mux.c (99%)
 rename board/BuR/{tseries => brxre1}/Kconfig (67%)
 create mode 100644 board/BuR/brxre1/MAINTAINERS
 rename board/BuR/{kwb => brxre1}/Makefile (100%)
 rename board/BuR/{kwb => brxre1}/board.c (98%)
 rename board/BuR/{kwb => brxre1}/mux.c (100%)
 delete mode 100644 board/BuR/kwb/MAINTAINERS
 delete mode 100644 board/BuR/tseries/MAINTAINERS
 rename configs/{tseries_mmc_defconfig => brppt1_mmc_defconfig} (97%)
 rename configs/{tseries_nand_defconfig => brppt1_nand_defconfig} (97%)
 rename configs/{tseries_spi_defconfig => brppt1_spi_defconfig} (97%)
 rename configs/{kwb_defconfig => brxre1_defconfig} (97%)
 rename include/configs/{tseries.h => brppt1.h} (98%)
 rename include/configs/{kwb.h => brxre1.h} (97%)

-- 
1.9.1

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

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

[Yao Yuan]

On 06/22/2016 06:08 PM, Michael Trimarchi wrote:
> On Wed, Jun 22, 2016 at 10:00:49AM +, Yao Yuan wrote:
> > On 06/22/2016 03:59 PM, Michael Trimarchi wrote:
> > > The S25FS128 is part of S25FS-S family physical sectors may be
> > > configured as a hybrid combination of eight 4-kB parameter sectors
> > > at the top or bottom of the address space with all but one of the
> > > remaining sectors being uniform size. This rework a bit commit
> > >
> > > 80c1bfd2332e71dfe669cac53ba06b7435a7ca39
> > >
> > > and add this jedec part number
> > >
> > > Signed-off-by: Michael Trimarchi 
> > > ---
> > >  drivers/mtd/spi/spi_flash.c | 18 --
> > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mtd/spi/spi_flash.c
> > > b/drivers/mtd/spi/spi_flash.c index
> > > 64d4e0f..c993588 100644
> > > --- a/drivers/mtd/spi/spi_flash.c
> > > +++ b/drivers/mtd/spi/spi_flash.c
> > > @@ -972,6 +972,21 @@ int spi_flash_decode_fdt(const void *blob,
> > > struct spi_flash *flash)  #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
> > >
> > >  #ifdef CONFIG_SPI_FLASH_SPANSION
> > > +
> > > +inline int is_spansion_s25fss_family(u16 jedec, u16 ext_jedec) {
> > > + switch (jedec) {
> > > + case 0x0219:
> > > + case 0x0220:
> > > + case 0x2018:
> > > + if ((ext_jedec & 0xff00) == 0x4d00)
> > > + return 1;
> > > + default:;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > >  static int spansion_s25fss_disable_4KB_erase(struct spi_slave *spi)  {
> > >   u8 cmd[4];
> > > @@ -1072,8 +1087,7 @@ int spi_flash_scan(struct spi_flash *flash)
> > >* sector that is not overlaid by the parameter sectors.
> > >* The uniform sector erase command has no effect on parameter
> > > sectors.
> > >*/
> > > - if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> > > - (ext_jedec & 0xff00) == 0x4d00) {
> > > + if (is_spansion_s25fss_family(jedec, ext_jedec)) {
> > >   int ret;
> > >   u8 id[6];
> > >
> > > --
> >
> > Hi Michael,
> > From some datasheet for spansion flash, it seems all the spansion
> > S25FS family should disable 4kb.
> > So how about just judge the idcode[0]?
> >
> 
> I understand your point but I don't have enough part number and I can only to
> test on this one. I will verify this patch too and put my review and drop my
> personal one. Anyway can you ask if the first 0x8000 are considered by boot
> rom? I'm trying to boot from qspi an imx7d board and I create the parameter
> using the files/qspi-nor-spansion-s25fl128s-config but not sure if I need to 
> flash
> from 0x400 or from 0x8400. And then I think that bootloader should go from
> 0x1000 or from 0x9000 correct?
> Then from BOOT_FROM I choose qspi but what is the DEFAULT_ADDRESS
> 0x1000 or 0x400?
> 

I'm not sure what's the offset for imx7d, but for NXP LS series SOC.
The RCW_PBI offset: 0x0
The Uboot offset is defined by RCW_PBI code.(Such as 0x1)

> > Like:
> > diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> > index 64d4e0f..cfe3649 100644
> > --- a/drivers/mtd/spi/spi_flash.c
> > +++ b/drivers/mtd/spi/spi_flash.c
> > @@ -1072,8 +1072,7 @@ int spi_flash_scan(struct spi_flash *flash)
> >  * sector that is not overlaid by the parameter sectors.
> >  * The uniform sector erase command has no effect on parameter 
> > sectors.
> >  */
> > -   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> > -   (ext_jedec & 0xff00) == 0x4d00) {
> > +   if (idcode[0] == SPI_FLASH_CFI_MFR_SPANSION) {
> > int ret;
> > u8 id[6];
> >
> >
> > How about your think?
> 
> For me is fine if you are sure
> 
> Michael
> 
> >
> >
> >
> 
> --
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO  -  Founder  Cruquiuskade 47 |
> | +31(0)851119172 Amsterdam 1018 AM NL |
> |  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

[Michael Trimarchi]

Hi

On Wed, Jun 22, 2016 at 10:00:49AM +, Yao Yuan wrote:
> On 06/22/2016 03:59 PM, Michael Trimarchi wrote:
> > The S25FS128 is part of S25FS-S family physical sectors may be configured 
> > as a
> > hybrid combination of eight 4-kB parameter sectors at the top or bottom of 
> > the
> > address space with all but one of the remaining sectors being uniform size. 
> > This
> > rework a bit commit
> > 
> > 80c1bfd2332e71dfe669cac53ba06b7435a7ca39
> > 
> > and add this jedec part number
> > 
> > Signed-off-by: Michael Trimarchi 
> > ---
> >  drivers/mtd/spi/spi_flash.c | 18 --
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index
> > 64d4e0f..c993588 100644
> > --- a/drivers/mtd/spi/spi_flash.c
> > +++ b/drivers/mtd/spi/spi_flash.c
> > @@ -972,6 +972,21 @@ int spi_flash_decode_fdt(const void *blob, struct
> > spi_flash *flash)  #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
> > 
> >  #ifdef CONFIG_SPI_FLASH_SPANSION
> > +
> > +inline int is_spansion_s25fss_family(u16 jedec, u16 ext_jedec) {
> > +   switch (jedec) {
> > +   case 0x0219:
> > +   case 0x0220:
> > +   case 0x2018:
> > +   if ((ext_jedec & 0xff00) == 0x4d00)
> > +   return 1;
> > +   default:;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  static int spansion_s25fss_disable_4KB_erase(struct spi_slave *spi)  {
> > u8 cmd[4];
> > @@ -1072,8 +1087,7 @@ int spi_flash_scan(struct spi_flash *flash)
> >  * sector that is not overlaid by the parameter sectors.
> >  * The uniform sector erase command has no effect on parameter
> > sectors.
> >  */
> > -   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> > -   (ext_jedec & 0xff00) == 0x4d00) {
> > +   if (is_spansion_s25fss_family(jedec, ext_jedec)) {
> > int ret;
> > u8 id[6];
> > 
> > --
> 
> Hi Michael, 
> From some datasheet for spansion flash,
> it seems all the spansion S25FS family should disable 4kb.
> So how about just judge the idcode[0]?
> 

I understand your point but I don't have enough part number and
I can only to test on this one. I will verify this patch too and 
put my review and drop my personal one. Anyway can you ask if
the first 0x8000 are considered by boot rom? I'm trying to boot
from qspi an imx7d board and I create the parameter using
the files/qspi-nor-spansion-s25fl128s-config but not sure if I need
to flash from 0x400 or from 0x8400. And then I think that bootloader
should go from 0x1000 or from 0x9000 correct?
Then from BOOT_FROM I choose qspi but what is the DEFAULT_ADDRESS
0x1000 or 0x400? 

> Like:
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 64d4e0f..cfe3649 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -1072,8 +1072,7 @@ int spi_flash_scan(struct spi_flash *flash)
>  * sector that is not overlaid by the parameter sectors.
>  * The uniform sector erase command has no effect on parameter 
> sectors.
>  */
> -   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> -   (ext_jedec & 0xff00) == 0x4d00) {
> +   if (idcode[0] == SPI_FLASH_CFI_MFR_SPANSION) {
> int ret;
> u8 id[6];
> 
> 
> How about your think?

For me is fine if you are sure

Michael

> 
> 
> 

-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

[Yao Yuan]

On 06/22/2016 03:59 PM, Michael Trimarchi wrote:
> The S25FS128 is part of S25FS-S family physical sectors may be configured as a
> hybrid combination of eight 4-kB parameter sectors at the top or bottom of the
> address space with all but one of the remaining sectors being uniform size. 
> This
> rework a bit commit
> 
> 80c1bfd2332e71dfe669cac53ba06b7435a7ca39
> 
> and add this jedec part number
> 
> Signed-off-by: Michael Trimarchi 
> ---
>  drivers/mtd/spi/spi_flash.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index
> 64d4e0f..c993588 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -972,6 +972,21 @@ int spi_flash_decode_fdt(const void *blob, struct
> spi_flash *flash)  #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
> 
>  #ifdef CONFIG_SPI_FLASH_SPANSION
> +
> +inline int is_spansion_s25fss_family(u16 jedec, u16 ext_jedec) {
> + switch (jedec) {
> + case 0x0219:
> + case 0x0220:
> + case 0x2018:
> + if ((ext_jedec & 0xff00) == 0x4d00)
> + return 1;
> + default:;
> + }
> +
> + return 0;
> +}
> +
>  static int spansion_s25fss_disable_4KB_erase(struct spi_slave *spi)  {
>   u8 cmd[4];
> @@ -1072,8 +1087,7 @@ int spi_flash_scan(struct spi_flash *flash)
>* sector that is not overlaid by the parameter sectors.
>* The uniform sector erase command has no effect on parameter
> sectors.
>*/
> - if ((jedec == 0x0219 || (jedec == 0x0220)) &&
> - (ext_jedec & 0xff00) == 0x4d00) {
> + if (is_spansion_s25fss_family(jedec, ext_jedec)) {
>   int ret;
>   u8 id[6];
> 
> --

Hi Michael, 
>From some datasheet for spansion flash,
it seems all the spansion S25FS family should disable 4kb.
So how about just judge the idcode[0]?

Like:
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 64d4e0f..cfe3649 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1072,8 +1072,7 @@ int spi_flash_scan(struct spi_flash *flash)
 * sector that is not overlaid by the parameter sectors.
 * The uniform sector erase command has no effect on parameter sectors.
 */
-   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
-   (ext_jedec & 0xff00) == 0x4d00) {
+   if (idcode[0] == SPI_FLASH_CFI_MFR_SPANSION) {
int ret;
u8 id[6];


How about your think?



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

Re: [U-Boot] [PATCH 5/9] arm: omap-common: secure ROM signature verify API

[Lokesh Vutla]

On Wednesday 22 June 2016 05:26 AM, Tom Rini wrote:
> On Tue, Jun 21, 2016 at 10:01:54AM +0530, Lokesh Vutla wrote:
>>
>>
>> On Tuesday 21 June 2016 09:04 AM, Andreas Dannenberg wrote:
>>> Adds an API that verifies a signature attached to an image (binary
>>> blob). This API is basically a entry to a secure ROM service provided by
>>> the device and accessed via an SMC call, using a particular calling
>>> convention.
>>>
>>> Signed-off-by: Daniel Allred 
>>> Signed-off-by: Andreas Dannenberg 
>>> ---
>>>  arch/arm/cpu/armv7/omap-common/sec-common.c | 76 
>>> +
>>>  arch/arm/include/asm/omap_common.h  |  9 
>>>  2 files changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c 
>>> b/arch/arm/cpu/armv7/omap-common/sec-common.c
>>> index b9c0a42..dbb9078 100644
>>> --- a/arch/arm/cpu/armv7/omap-common/sec-common.c
>>> +++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
>>> @@ -16,6 +16,9 @@
>>>  #include 
>>>  #include 
>>>  
>>> +/* Index for signature verify ROM API */
>>> +#define API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX(0x000E)
>>> +
>>>  static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
>>>  
>>>  u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
>>> @@ -47,3 +50,76 @@ u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, 
>>> ...)
>>>  
>>> return omap_smc_sec(service, proc_id, flag, secure_rom_call_args);
>>>  }
>>> +
>>> +static u32 find_sig_start(char *image, size_t size)
>>> +{
>>> +   char *image_end = image + size;
>>> +   char *sig_start_magic = "CERT_";
>>> +   int magic_str_len = strlen(sig_start_magic);
>>> +   char *ch;
>>> +
>>> +   while (--image_end > image) {
>>> +   if (*image_end == '_') {
>>> +   ch = image_end - magic_str_len + 1;
>>> +   if (!strncmp(ch, sig_start_magic, magic_str_len))
>>> +   return (u32)ch;
>>> +   }
>>> +   }
>>> +   return 0;
>>> +}
>>> +
>>> +int secure_boot_verify_image(void **image, size_t *size)
>>> +{
>>> +   int result = 1;
>>> +   u32 cert_addr, sig_addr;
>>> +   size_t cert_size;
>>> +
>>> +   /* Perform cache writeback on input buffer */
>>> +   flush_dcache_range(
>>> +   (u32)*image,
>>> +   (u32)*image + roundup(*size, ARCH_DMA_MINALIGN));
>>> +
>>> +   cert_addr = (uint32_t)*image;
>>> +   sig_addr = find_sig_start((char *)*image, *size);
>>> +
>>> +   if (sig_addr == 0) {
>>> +   printf("No signature found in image.\n");
>>> +   result = 1;
>>> +   goto auth_exit;
>>> +   }
>>> +
>>> +   *size = sig_addr - cert_addr;   /* Subtract out the signature size */
>>> +   cert_size = *size;
>>> +
>>> +   /* Check if image load address is 32-bit aligned */
>>> +   if (0 != (0x3 & cert_addr)) {
>>
>>  if (!IS_ALIGNED(cert_addr, 4)) { ?
>>
>>> +   printf("Image is not 4-byte aligned.\n");
>>> +   result = 1;
>>> +   goto auth_exit;
>>> +   }
>>> +
>>> +   /* Image size also should be multiple of 4 */
>>> +   if (0 != (0x3 & cert_size)) {
>>
>>  if (!IS_ALIGNED(cert_size, 4)) { ?
>>
>>> +   printf("Image size is not 4-byte aligned.\n");
>>> +   result = 1;
>>> +   goto auth_exit;
>>> +   }
>>> +
>>> +   /* Call ROM HAL API to verify certificate signature */
>>> +   debug("%s: load_addr = %x, size = %x, sig_addr = %x\n", __func__,
>>> + cert_addr, cert_size, sig_addr);
>>> +
>>> +   result = secure_rom_call(
>>> +   API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX, 0, 0,
>>> +   4, cert_addr, cert_size, sig_addr, 0x);
>>> +auth_exit:
>>> +   if (result != 0) {
>>> +   printf("Authentication failed!\n");
>>> +   printf("Return Value = %08X\n", result);
>>> +   hang();
>>> +   }
>>> +
>>> +   printf("Authentication passed: %s\n", (char *)sig_addr);
>>
>> Uart boot will break because of these prints during the FIT loading. Can
>> you make this as debug?
> 
> Are you sure it will break?  There's usually a print in between loading
> SPL via UART and then U-Boot itself via UART and Y-MODEM is smart enough
> to re-transmit.
> 

Yes, if the print is in between while Y-MODEM is transferring. The above
print falls in this case.

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

Re: [U-Boot] u-boot-x86 sf probe fail

[Bin Meng]

Hi Hilbert,

On Wed, Jun 22, 2016 at 2:24 PM, Hilbert Tu(杜睿哲_Pegatron)
 wrote:
> Hi Bin,
>
> As the earlier post, do you have any comments? Thanks.
>

Can you try this patch [1] and let me know if it fixes the issue?

[1]: http://patchwork.ozlabs.org/patch/639039/

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

[U-Boot] [PATCH] dm: Sort the uclass id in alphabetical order

[Bin Meng]

Some uclass ids are out of order. Per the comments, sort them
in alphabetical order.

Signed-off-by: Bin Meng 
---

 include/dm/uclass-id.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index b768660..c5cdfc7 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -33,7 +33,6 @@ enum uclass_id {
UCLASS_CROS_EC, /* Chrome OS EC */
UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
UCLASS_DMA, /* Direct Memory Access */
-   UCLASS_RAM, /* RAM controller */
UCLASS_ETH, /* Ethernet device */
UCLASS_GPIO,/* Bank of general-purpose I/O pins */
UCLASS_I2C, /* I2C bus */
@@ -56,11 +55,12 @@ enum uclass_id {
UCLASS_PCH, /* x86 platform controller hub */
UCLASS_PCI, /* PCI bus */
UCLASS_PCI_GENERIC, /* Generic PCI bus device */
-   UCLASS_PINCTRL, /* Pinctrl (pin muxing/configuration) device */
UCLASS_PINCONFIG,   /* Pin configuration node device */
+   UCLASS_PINCTRL, /* Pinctrl (pin muxing/configuration) device */
UCLASS_PMIC,/* PMIC I/O device */
UCLASS_PWM, /* Pulse-width modulator */
UCLASS_PWRSEQ,  /* Power sequence device */
+   UCLASS_RAM, /* RAM controller */
UCLASS_REGULATOR,   /* Regulator device */
UCLASS_REMOTEPROC,  /* Remote Processor device */
UCLASS_RESET,   /* Reset controller device */
-- 
2.7.4

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

[U-Boot] [PATCH] x86: coreboot: Remove the dummy pch driver

[Bin Meng]

There is a dummy pch driver in the coreboot directory. This causes
drivers of its children fail to function due to empty ops. Remove
the whole file since it is no longer needed.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/coreboot/Makefile |  1 -
 arch/x86/cpu/coreboot/pci.c| 26 --
 2 files changed, 27 deletions(-)
 delete mode 100644 arch/x86/cpu/coreboot/pci.c

diff --git a/arch/x86/cpu/coreboot/Makefile b/arch/x86/cpu/coreboot/Makefile
index b6e870a..d663656 100644
--- a/arch/x86/cpu/coreboot/Makefile
+++ b/arch/x86/cpu/coreboot/Makefile
@@ -18,4 +18,3 @@ obj-y += coreboot.o
 obj-y += tables.o
 obj-y += sdram.o
 obj-y += timestamp.o
-obj-$(CONFIG_PCI) += pci.o
diff --git a/arch/x86/cpu/coreboot/pci.c b/arch/x86/cpu/coreboot/pci.c
deleted file mode 100644
index 7f5087a..000
--- a/arch/x86/cpu/coreboot/pci.c
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * Copyright (c) 2011 The Chromium OS Authors.
- * (C) Copyright 2008,2009
- * Graeme Russ, 
- *
- * (C) Copyright 2002
- * Daniel Engström, Omicron Ceti AB, 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-
-static const struct udevice_id generic_pch_ids[] = {
-   { .compatible = "intel,pch7" },
-   { .compatible = "intel,pch9" },
-   { }
-};
-
-U_BOOT_DRIVER(generic_pch_drv) = {
-   .name   = "pch",
-   .id = UCLASS_PCH,
-   .of_match   = generic_pch_ids,
-};
-- 
2.7.4

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

[U-Boot] usb: hub enumeration and potential NULL ptr dereference in usb_device_info()

[Bernhard Nortmann]

Starting with commit b19236fd1c1ef289bab9e243ee5b50d658fcac3f I am observing
a breakage of the "usb info" command on my BananaPi (Allwinner A20, sun7i),
while "usb tree" and dm commands ("dm tree", "dm uclass") are fine.
See attached usb-info-breakage.log

Tracing back the error positon from pc and lr registers pointed me to the
device_get_uclass_id() call within usb_device_info(), and suggested the
problem is caused by trying to dereference a NULL struct udevice *hub.

Therefore I added a diagnostic printf and a safeguard to this routine:

diff --git a/cmd/usb.c b/cmd/usb.c
index b83d323..a5e2463 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -610,6 +610,12 @@ static int usb_device_info(void)
 struct udevice *hub;

 device_find_first_child(bus, );
+printf("bus %p, uclass %d, hub %p: ",
+bus, device_get_uclass_id(bus), hub);
+if (!hub) {
+printf("\n");
+continue;
+}
 if (device_get_uclass_id(hub) == UCLASS_USB_HUB &&
 device_active(hub)) {
 show_info(hub);

And it became apparent that hub actually receives NULL values during the
device enumeration. The safeguard prevented the "data abort" error and got
"usb info" working again - see attached usb-info-fixed.log

I'm not sure why this particular problem didn't manifest earlier and
only now became apparent with the change in SPL header size /
CONFIG_SPL_TEXT_BASE. But it seems that accessing a NULL hub with
device_get_uclass_id() is clearly wrong and should be avoided.
Which brings me to two questions:

1. Is getting a NULL hub value legit when iterating UCLASS_USB devices
   the way that usb_device_info() does? If yes, the code seems to be
   lacking protection against passing it to device_get_uclass_id().

2. Why does usb_device_info() choose to enumerate hubs this way at all?
   If the routine is aiming at UCLASS_USB_HUB - which seems to be the
   purpose of the subsequent device_get_uclass_id(hub) test - and the
   device tree already provides this information (as suggested by the
   output of "dm uclass"), then why not enumerate UCLASS_USB_HUB directly?

Regards, B. Nortmann



usb-info-breakage.log
Description: Binary data


usb-info-fixed.log
Description: Binary data
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot-x86 sf probe fail

[Bin Meng]

On Wed, Jun 22, 2016 at 1:19 PM, Yaroslav  wrote:
> Hello.
>
> I have a similar problem with U-Boot on Intel Atom C2000.
> And I have found that the issue with the SPI flash is caused by a file
> x86/cpu/coreboot/pci.c which contains an empty driver claiming to be
> compatible with intel,pch7 and intel,pch9. After commenting it out the SPI
> flash is being probed and works just fine.
> Maybe the file contains outdated code or something. U-boot maintainers
> should check it.

Yes, this is the issue! Will prepare a patch soon.

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

[U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

[Michael Trimarchi]

The S25FS128 is part of S25FS-S family physical sectors may be
configured as a hybrid combination of eight 4-kB parameter sectors
at the top or bottom of the address space with all but one of the
remaining sectors being uniform size. This rework a bit commit

80c1bfd2332e71dfe669cac53ba06b7435a7ca39

and add this jedec part number

Signed-off-by: Michael Trimarchi 
---
 drivers/mtd/spi/spi_flash.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 64d4e0f..c993588 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -972,6 +972,21 @@ int spi_flash_decode_fdt(const void *blob, struct 
spi_flash *flash)
 #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
 
 #ifdef CONFIG_SPI_FLASH_SPANSION
+
+inline int is_spansion_s25fss_family(u16 jedec, u16 ext_jedec)
+{
+   switch (jedec) {
+   case 0x0219:
+   case 0x0220:
+   case 0x2018:
+   if ((ext_jedec & 0xff00) == 0x4d00)
+   return 1;
+   default:;
+   }
+
+   return 0;
+}
+
 static int spansion_s25fss_disable_4KB_erase(struct spi_slave *spi)
 {
u8 cmd[4];
@@ -1072,8 +1087,7 @@ int spi_flash_scan(struct spi_flash *flash)
 * sector that is not overlaid by the parameter sectors.
 * The uniform sector erase command has no effect on parameter sectors.
 */
-   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
-   (ext_jedec & 0xff00) == 0x4d00) {
+   if (is_spansion_s25fss_family(jedec, ext_jedec)) {
int ret;
u8 id[6];
 
-- 
2.9.0

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

[U-Boot] [PATCH] net: usb: r8152: Add DM support

[Stefan Roese]

Add support for driver model, so that CONFIG_DM_ETH can be defined and
used with this driver.

This patch also adds the read_rom_hwaddr() callback so that the ROM MAC
address will be used to the DM part of this driver.

Signed-off-by: Stefan Roese 
Cc: Stephen Warren 
Cc: Ted Chen 
Cc: Simon Glass 
Cc: Joe Hershberger 
---
 drivers/usb/eth/r8152.c| 235 -
 drivers/usb/eth/r8152.h|   4 +
 drivers/usb/eth/r8152_fw.c |   2 +
 3 files changed, 219 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/eth/r8152.c b/drivers/usb/eth/r8152.c
index 325b70c..a148267 100644
--- a/drivers/usb/eth/r8152.c
+++ b/drivers/usb/eth/r8152.c
@@ -3,9 +3,10 @@
  *
  * SPDX-License-Identifier:GPL-2.0
  *
-  */
+ */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,6 +16,7 @@
 #include "usb_ether.h"
 #include "r8152.h"
 
+#ifndef CONFIG_DM_ETH
 /* local vars */
 static int curr_eth_dev; /* index for name of next device detected */
 
@@ -23,12 +25,6 @@ struct r8152_dongle {
unsigned short product;
 };
 
-struct r8152_version {
-   unsigned short tcr;
-   unsigned short version;
-   bool   gmii;
-};
-
 static const struct r8152_dongle const r8152_dongles[] = {
/* Realtek */
{ 0x0bda, 0x8050 },
@@ -54,6 +50,13 @@ static const struct r8152_dongle const r8152_dongles[] = {
/* Nvidia */
{ 0x0955, 0x09ff },
 };
+#endif
+
+struct r8152_version {
+   unsigned short tcr;
+   unsigned short version;
+   bool   gmii;
+};
 
 static const struct r8152_version const r8152_versions[] = {
{ 0x4c00, RTL_VER_01, 0 },
@@ -1176,11 +1179,8 @@ static int rtl_ops_init(struct r8152 *tp)
return ret;
 }
 
-static int r8152_init(struct eth_device *eth, bd_t *bd)
+static int r8152_init_common(struct r8152 *tp)
 {
-   struct ueth_data *dev = (struct ueth_data *)eth->priv;
-   struct r8152 *tp = (struct r8152 *)dev->dev_priv;
-
u8 speed;
int timeout = 0;
int link_detected;
@@ -1210,14 +1210,11 @@ static int r8152_init(struct eth_device *eth, bd_t *bd)
return 0;
 }
 
-static int r8152_send(struct eth_device *eth, void *packet, int length)
+static int r8152_send_common(struct ueth_data *ueth, void *packet, int length)
 {
-   struct ueth_data *dev = (struct ueth_data *)eth->priv;
-
+   struct usb_device *udev = ueth->pusb_dev;
u32 opts1, opts2 = 0;
-
int err;
-
int actual_len;
unsigned char msg[PKTSIZE + sizeof(struct tx_desc)];
struct tx_desc *tx_desc = (struct tx_desc *)msg;
@@ -1231,18 +1228,31 @@ static int r8152_send(struct eth_device *eth, void 
*packet, int length)
 
memcpy(msg + sizeof(struct tx_desc), (void *)packet, length);
 
-   err = usb_bulk_msg(dev->pusb_dev,
-   usb_sndbulkpipe(dev->pusb_dev, dev->ep_out),
-   (void *)msg,
-   length + sizeof(struct tx_desc),
-   _len,
-   USB_BULK_SEND_TIMEOUT);
+   err = usb_bulk_msg(udev, usb_sndbulkpipe(udev, ueth->ep_out),
+  (void *)msg, length + sizeof(struct tx_desc),
+  _len, USB_BULK_SEND_TIMEOUT);
debug("Tx: len = %zu, actual = %u, err = %d\n",
  length + sizeof(struct tx_desc), actual_len, err);
 
return err;
 }
 
+#ifndef CONFIG_DM_ETH
+static int r8152_init(struct eth_device *eth, bd_t *bd)
+{
+   struct ueth_data *dev = (struct ueth_data *)eth->priv;
+   struct r8152 *tp = (struct r8152 *)dev->dev_priv;
+
+   return r8152_init_common(tp);
+}
+
+static int r8152_send(struct eth_device *eth, void *packet, int length)
+{
+   struct ueth_data *dev = (struct ueth_data *)eth->priv;
+
+   return r8152_send_common(dev, packet, length);
+}
+
 static int r8152_recv(struct eth_device *eth)
 {
struct ueth_data *dev = (struct ueth_data *)eth->priv;
@@ -1454,3 +1464,184 @@ int r8152_eth_get_info(struct usb_device *dev, struct 
ueth_data *ss,
debug("MAC %pM\n", eth->enetaddr);
return 1;
 }
+#endif /* !CONFIG_DM_ETH */
+
+#ifdef CONFIG_DM_ETH
+static int r8152_eth_start(struct udevice *dev)
+{
+   struct r8152 *tp = dev_get_priv(dev);
+
+   debug("** %s (%d)\n", __func__, __LINE__);
+
+   return r8152_init_common(tp);
+}
+
+void r8152_eth_stop(struct udevice *dev)
+{
+   struct r8152 *tp = dev_get_priv(dev);
+
+   debug("** %s (%d)\n", __func__, __LINE__);
+
+   tp->rtl_ops.disable(tp);
+}
+
+int r8152_eth_send(struct udevice *dev, void *packet, int length)
+{
+   struct r8152 *tp = dev_get_priv(dev);
+
+   return r8152_send_common(>ueth, packet, length);
+}
+
+int r8152_eth_recv(struct udevice *dev, int flags, uchar **packetp)
+{
+   struct r8152 *tp = 

Re: [U-Boot] [PATCH 3/6] autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK

[Christian Riesch]

On Tue, Jun 21, 2016 at 7:32 AM, Masahiro Yamada
 wrote:
> As the help message of CONFIG_BOOTDELAY says, CONFIG_BOOTDELAY=-2
> means the autoboot with no delay, with no abort check even if
> CONFIG_ZERO_BOOTDELAY_CHECK is defined.
>
> To sum up, the autoboot behaves as follows:
>
>  [1] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=y
> autoboot with no delay, but you can abort it by key input
>
>  [2] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
> autoboot with no delay, with no check for abort
>
>  [3] CONFIG_BOOTDELAY=-1
> disable autoboot
>
>  [4] CONFIG_BOOTDELAY=-2
> autoboot with no delay, with no check for abort
>
> As you notice, [2] and [4] come to the same result, which means we
> do not need CONFIG_ZERO_BOOTDELAY_CHECK.  We can control all the
> cases only by CONFIG_BOOTDELAY, like this:
>
>  [1] CONFIG_BOOTDELAY=0
> autoboot with no delay, but you can abort it by key input
>
>  [2] CONFIG_BOOTDELAY=-1
> disable autoboot
>
>  [3] CONFIG_BOOTDELAY=-2
> autoboot with no delay, with no check for abort
>
> This commit converts the logic as follow:
>   CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
> --> CONFIG_BOOTDELAY=-2
>
> Signed-off-by: Masahiro Yamada 

For the calimain board

Acked-by: Christian Riesch 

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

Re: [U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks

[Rajesh Bhagat]

From: Matthew Bright [mailto:matthew.bri...@alliedtelesis.co.nz] 
Sent: Wednesday, June 22, 2016 11:42 AM
To: Rajesh Bhagat ; ma...@denx.de
Cc: u-boot@lists.denx.de; Chris Packham ; 
Mark Tomlinson 
Subject: testing: [PATCH v7 0/3] common: usb_storage: Implement logic to 
calculate optimal usb maximum trasfer blocks

On 06/16/2016 12:35 PM, Rajesh Bhagat wrote:
> Performs code cleanup by making common function for usb_stor_read/write
> and implements the logic to calculate the optimal usb maximum trasfer blocks
> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
> of EHCI and other USB protocols respectively.
> 
> Rajesh Bhagat (3):
>   common: usb_storage: Make common function for usb_read_10/usb_write_10
>   common: usb_storage: Make common function for
>     usb_stor_read/usb_stor_write
>   common: usb_storage : Implement logic to calculate optimal usb maximum
>     trasfer blocks
> 
>  common/usb_storage.c | 213 
> +++
>  include/usb.h        |   1 +
>  2 files changed, 98 insertions(+), 116 deletions(-)
> 
>
> Hi Rajesh & Marek
>
> I have spend the last couple of days testing these patches on the
> v2016.05 release, with an usb mass storage device that is able to
> consistently reproduce the USB_MAX_XFER_BLK issue as described in
> the "Issue with USB mass storage (thumb drives)" u-boot thread.
>
> http://lists.denx.de/pipermail/u-boot/2016-February/244464.html​
>

Hello Matt, 

> I can confirm the patch correctly increases the max transfer bocks
> after a successful read, and decreases the max transfer bocks after
> a read failure. However, I have noticed that once the ehci time out
> error occurs, the usb device appears to lock up. When in this state
> the usb device will stop responding to any further transfers. This
> behavior is independent of the number of blocks, and will continue
> until the ehci has been reset.
>

I believe the lockup behavior mentioned by you to be device specific quirk. 
I tested 3 pen drives, which recovered from EHCI timeout behavior by 
reducing the number of blocks (check below output): 

USB write: device 0 block # 0, count 524288 ... 
usb_stor_read_write: retry #2, cur_xfer_blks 4095, smallblks 4095
usb_stor_read_write: retry #2, cur_xfer_blks 8191, smallblks 8191
usb_stor_read_write: retry #2, cur_xfer_blks 16383, smallblks 16383
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 65535, smallblks 65535
EHCI timed out on TD - token=0xa6008c80
usb_stor_read_write: retry #1, cur_xfer_blks 32767, smallblks 32767 <== 
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 4114
524288 blocks write: OK

USB read: device 0 block # 0, count 524288 ... 
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 65535, smallblks 65535
EHCI timed out on TD - token=0x2c008d80
usb_stor_read_write: retry #1, cur_xfer_blks 32767, smallblks 32767 <== 
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 32767, smallblks 32767
usb_stor_read_write: retry #2, cur_xfer_blks 

[U-Boot] comments: [PATCH v7 3/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks

[Matthew Bright]

Hi Rajesh & Marek

I have spend the last couple of days testing this patch and have a few review 
comments:

On 06/16/2016 12:35 PM, Rajesh Bhagat wrote:
> Implements the logic to calculate the optimal usb maximum trasfer blocks
> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
> of EHCI and other USB protocols respectively.
>
> It defines USB_MIN_XFER_BLK/USB_MAX_XFER_BLK trasfer blocks that should
> be checked for success starting from minimum to maximum, and rest of the
> read/write are performed with that optimal value. It tries to increase/
> decrease the blocks in follwing scenarios:
>
> 1.decrease blocks: when read/write for a particular number of blocks
> fails.
> 2. increase blocks: when read/write for a particular number of blocks
> pass and amount left to trasfer is greater than current number of
> blocks.
>
> Currently changes are done for EHCI where min = 4096 and max = 65535
> is taken. And for other cases code is left unchanged by keeping min
> = max = 20.
>
> Signed-off-by: Sriram Dash 
> Signed-off-by: Rajesh Bhagat 
> Reviewed-by: Simon Glass 
> ---
> Changes in v7:
>  - None
>
> Changes in v6:
>  - Adds paranthesis around macro variables
>  - Removes extra ternary operator from dec_cur_xfer_blks
>  - Clamps the size to min(blks, USB_MAX_XFER_BLK) in inc_cur_xfer_blks
>
> Changes in v5:
>  - None
>
> Changes in v4:
>  - Adds udev paramater in dec/inc_cur_xfer_blks function and adds
>sanity check on it.
>  - Changes type of pos varible to unsigned int in dec/inc_cur_xfer_blks
>  - Removes usage of pos varible from usb_stor_read/write
>
> Changes in v3:
>  - Adds cur_xfer_blks in struct usb_device to retain values
>  - Adds functions dec/inc_cur_xfer_blks to remove code duplication
>  - Moves check from macro to calling functions
>
> Changes in v2:
>  - Removes table to store blocks and use formula (1 << (12 + n)) - 1
>  - Adds logic to start from minimum, go to maximum in each read/write
>
>  common/usb_storage.c | 66 
> 
>  include/usb.h|  1 +
>  2 files changed, 62 insertions(+), 5 deletions(-)
>
> diff --git a/common/usb_storage.c b/common/usb_storage.c
> index a7d84bf..93b901c 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -106,11 +106,16 @@ struct us_data {
>   * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands 
> are
>   * limited to 65535 blocks.
>   */

Should this also include CONFIG_USB_XHCI? It appears
that it is currently limited to the fixed 20 blocks.

> +#define USB_MIN_XFER_BLK 4095

Where did this number 4095 come from; is 4095 blocks low enough?
It surprises me that USB_MIN_XFER_BLK has been set so high, when
the linux default is 240 blocks and the windows default is 128
blocks. Further, there appears to be some devices that will only
support up to 64 blocks.

http://lists.denx.de/pipermail/u-boot/2016-February/246250.html

Maybe we could define a mid value for the transfer to start at;
giving room to move in both directions dependent on the outcome
of the transfer:

#define USB_MIN_XFER_BLK64
#define USB_MID_XFER_BLK4095
#define USB_MAX_XFER_BLK65535

However the 5 second delay incurred for each ehci timeout would
make working all the way down to 64 blocks painfully slow. Maybe
if the first transfer fails (at 4095 blocks) then it should jump
straight to 64 blocks and work its way up on each success.

>  #define USB_MAX_XFER_BLK 65535
>  #else
> +#define USB_MIN_XFER_BLK 20
>  #define USB_MAX_XFER_BLK 20
>  #endif
>
> +#define GET_CUR_XFER_BLKS(blks)  (LOG2(((blks) + 1) / (USB_MIN_XFER_BLK 
> + 1)))
> +#define CALC_CUR_XFER_BLKS(pos)  ((1 << (12 + (pos))) - 1)
> +
>  #ifndef CONFIG_BLK
>  static struct us_data usb_stor[USB_MAX_STOR_DEV];
>  #endif
> @@ -141,6 +146,44 @@ static void usb_show_progress(void)
>   debug(".");
>  }
>
> +static int dec_cur_xfer_blks(struct usb_device *udev)
> +{
> + /* decrease the cur_xfer_blks */
> + unsigned int pos;
> + unsigned short size;
> +
> + if (!udev)
> + return -EINVAL;
> +
> + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
> + size  = CALC_CUR_XFER_BLKS(pos - 1);
> +
> + if (size < USB_MIN_XFER_BLK)
> + return -EINVAL;
> +
> + udev->cur_xfer_blks = size;
> + return 0;
> +}
> +
> +static int inc_cur_xfer_blks(struct usb_device *udev, lbaint_t blks)
> +{
> + /* try to increase the cur_xfer_blks */
> + unsigned int pos;
> + unsigned short size;
> +
> + if (!udev)
> + return -EINVAL;
> +
> + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
> + size = CALC_CUR_XFER_BLKS(pos + 1);
> +
> + if (size > min(blks, (lbaint_t)USB_MAX_XFER_BLK))
> + return -EINVAL;
> +
> + udev->cur_xfer_blks = size;
> + return 0;
> +}
> +
>  
> /***
>   * show info on storage devices; 

[U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks

[Matthew Bright]

On 06/16/2016 12:35 PM, Rajesh Bhagat wrote:
> Performs code cleanup by making common function for usb_stor_read/write
> and implements the logic to calculate the optimal usb maximum trasfer blocks
> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
> of EHCI and other USB protocols respectively.
>
> Rajesh Bhagat (3):
>   common: usb_storage: Make common function for usb_read_10/usb_write_10
>   common: usb_storage: Make common function for
> usb_stor_read/usb_stor_write
>   common: usb_storage : Implement logic to calculate optimal usb maximum
> trasfer blocks
>
>  common/usb_storage.c | 213 
> +++
>  include/usb.h|   1 +
>  2 files changed, 98 insertions(+), 116 deletions(-)
>

Hi Rajesh & Marek

I have spend the last couple of days testing these patches on the
v2016.05 release, with an usb mass storage device that is able to
consistently reproduce the USB_MAX_XFER_BLK issue as described in
the "Issue with USB mass storage (thumb drives)" u-boot thread.

http://lists.denx.de/pipermail/u-boot/2016-February/244464.html​

I can confirm the patch correctly increases the max transfer bocks
after a successful read, and decreases the max transfer bocks after
a read failure. However, I have noticed that once the ehci time out
error occurs, the usb device appears to lock up. When in this state
the usb device will stop responding to any further transfers. This
behavior is independent of the number of blocks, and will continue
until the ehci has been reset.

The following debug output demonstrates this behavior:

(note: the retry attempts has been set to 4)

--

=> fatload usb 0:auto 0x100 test.rel

--
(where test.rel is dd if=/dev/urandom of=test.rel bs=32M count=2)
--

usb_stor_read_write: udev 0

usb_stor_read_write: dev 0 startblk 0, blccnt 1 buffer 7fb0d980
usb_stor_read_write: retry #4, cur_xfer_blks 4095, smallblks 1
usb_read_write_10: start 0 blocks 1
usb_stor_read_write: end startblk 1, blccnt 1 buffer 7fb0db80

--
(40 further transfers occur with blccnt bewteen 1 and 8 blocks)
--

usb_stor_read_write: udev 0

usb_stor_read_write: dev 0 startblk 169a0, blccnt 2 buffer 100
usb_stor_read_write: retry #4, cur_xfer_blks 4095, smallblks 4095
usb_read_write_10: start 169a0 blocks 4095
usb_stor_read_write: retry #4, cur_xfer_blks 8191, smallblks 8191
usb_read_write_10: start 1799f blocks 8191
usb_stor_read_write: retry #4, cur_xfer_blks 16383, smallblks 16383
usb_read_write_10: start 1999e blocks 16383
usb_stor_read_write: retry #4, cur_xfer_blks 32767, smallblks 32767
usb_read_write_10: start 1d99d blocks 32767
usb_stor_read_write: retry #4, cur_xfer_blks 65535, smallblks 65535
usb_read_write_10: start 2599c blocks 65535
EHCI timed out on TD - token=0x26008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
usb_stor_read_write: retry #3, cur_xfer_blks 32767, smallblks 32767
usb_read_write_10: start 2599c blocks 32767
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
usb_stor_read_write: retry #2, cur_xfer_blks 16383, smallblks 16383
usb_read_write_10: start 2599c blocks 16383
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
usb_stor_read_write: retry #1, cur_xfer_blks 8191, smallblks 8191
usb_read_write_10: start 2599c blocks 8191
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
usb_stor_read_write: retry #0, cur_xfer_blks 4095, smallblks 4095
usb_read_write_10: start 2599c blocks 4095
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
usb_stor_read_write: end startblk 2599c, blccnt fff buffer 2dff800

Re: [U-Boot] Továbbítás: u-boot

[Heiko Schocher]

Hello Richard,

Am 21.06.2016 um 23:03 schrieb kri...@nmdps.net:

Dear Heiko,

Sorry for being late.

It seems that code in sunxi_gpio_set_cfgbank is causing the panic.


Hmm.. I see no reason here ... can you debug into it?
I have no bananapi m2, so I could not help much.

you wrote:
>>> I own a bananapi m2, on which u-boot does not boot up since commit
>>> 90b7fc924adfe7f1745dcf6a1dabb9e77aa762a7.

How did you find out, that this commit broke your hw?
If this commit is the reason, can you try to revert this patch?

bye,
Heiko


regards,

2016-06-09 06:38 időpontban Heiko Schocher ezt írta:

Hello,

Am 08.06.2016 um 21:50 schrieb kri...@nmdps.net:

Küldve az én HTC-mről

- Továbbított üzenet -
Feladó: kri...@nmdps.net
Címzett: 
Tárgy: u-boot
Dátum: Sze, jún. 8, 2016 19:12

Dear developer,

I own a bananapi m2, on which u-boot does not boot up since commit
90b7fc924adfe7f1745dcf6a1dabb9e77aa762a7.

The console is repeating:

U-Boot 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34 +0200) Allwinner
Technology

CPU:   Allwinner A31s (SUN6I)
Model: Sinovoip BPI-M2
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   data abort
pc : [<7ef5f6f4>]  lr : [<7ef80b94>]
reloc pc : [<4a0016f4>]lr : [<4a022b94>]


It seems its in the network init ...

Do you have the System.map file for the image? Then you can
look into it and find out, which function crashes @0x4a0016f4.

bye,
Heiko

sp : 7af36f80  ip :  fp : 0017
r10: 7efab5e8  r9 : 7af3dee8 r8 : 40a0
r7 : 7ef9ee0c  r6 :  r5 : 0001  r4 : 
r3 : 7ef80b70  r2 : 0001 r1 :   r0 : ea0e
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

U-Boot SPL 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34)
DRAM: 1024 MiB
Trying to boot from MMC1


U-Boot 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34 +0200) Allwinner
Technology

CPU:   Allwinner A31s (SUN6I)
Model: Sinovoip BPI-M2
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   data abort
pc : [<7ef5f6f4>]  lr : [<7ef80b94>]
reloc pc : [<4a0016f4>]lr : [<4a022b94>]
sp : 7af36f80  ip :  fp : 0017
r10: 7efab5e8  r9 : 7af3dee8 r8 : 40a0
r7 : 7ef9ee0c  r6 :  r5 : 0001  r4 : 
r3 : 7ef80b70  r2 : 0001 r1 :   r0 : ea0e
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

U-Boot SPL 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34)
DRAM: 1024 MiB
Trying to boot from MMC1


U-Boot 2016.05-00393-g90b7fc9 (Jun 08 2016 - 18:57:34 +0200) Allwinner
Technology

CPU:   Allwinner A31s (SUN6I)
Model: Sinovoip BPI-M2
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   data abort
pc : [<7ef5f6f4>]  lr : [<7ef80b94>]
reloc pc : [<4a0016f4>]lr : [<4a022b94>]
sp : 7af36f80  ip :  fp : 0017
r10: 7efab5e8  r9 : 7af3dee8 r8 : 40a0
r7 : 7ef9ee0c  r6 :  r5 : 0001  r4 : 
r3 : 7ef80b70  r2 : 0001 r1 :   r0 : ea0e
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32

and so on.

How could I help debugging, resolving this issue?

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





--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot