Re: [U-Boot] uImage load address and entry point with Minnowboard
Dear Mr.Wolfgang Denk, On Wed, Jun 22, 2016 at 8:41 PM, Wolfgang Denk wrote: > 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. Thanks for your explanation. But I still have some questions , sorry if it is naive: 1) What's the address in the bootcmd corresponds to , I think it is the address where we want the u-boot to load the Linux kernel image into RAM For ex: fatload mmc 0:1 0100 bzImage; zboot 0100 Here 0100 is the address and bzImage is the compressed Linux kernel stored in mmc0 partition1. Once the Kernel is copied to RAM we are using zboot command to start the kernel, so after it Kernel unpacks itself and starts running 2) I want to use uncompressed Kernel(vmlinux) instead of bzImage. U-boot directly doesn't support running vmlinux, so I need to generate the uImage using the mkImage tool. So the payload in my case in uncompressed kernel. To generate this I want two addresses , load address and entry point address. You have mentioned that the addresses are often fixed. How can I get these addresses? I am using the same address in bootcmd: fatload mmc 0:1 0100 uImage; bootm 0100 > 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] [PATCH v4 0/9] LS2080ARDB: Enable EFI boot support
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 : x5 : fff897b0 x6 : 0008
Re: [U-Boot] [RFC 9/9] ti: omap-common: Update to generate secure FIT
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 target (QPSI, NOR flash) >> >> > u-boot-spl_HS_X-LOADER: $(obj)/u-boot-spl.bin >> >> > $(call if_changed,mkomapsecimg) >> >
[U-Boot] [PATCH] kbuild: avoid race between dtbs and dt/dt.dtb targets
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
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", &len); > > + 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; > > + > >
Re: [U-Boot] [PATCHv6 2/6] ARMv8: add the secure monitor firmware framework
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
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 = &gur->bootlocptrl; > > + boot_loc_ptr_h = &gur->bootlocptrh; > > +#elif defined(CONFIG_FSL_LSCH2) > > + struct ccsr_scfg __iomem *scfg = (void *)(CONFIG_SYS_FSL_SCFG_ADDR); > > + boot_loc_ptr_l = &scfg->scratchrw[1]; > > + boot_loc_ptr_h = &scfg->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
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
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
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
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 providing a clear indication that the device has locked up. The usb device in the initial thread app
Re: [U-Boot] [PATCH 2/9] spl: fit: add support for post-processing of images
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
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
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
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
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
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(&mmdc1->mpwldectrl1)); > > /* We must force a readback of these values, to get them to stick */ > - readl(&mmdc0->mpwldectrl0); > - readl(&mmdc0->mpwldectrl1); > - readl(&mmdc1->mpwldectrl0); > - readl(&mmdc1->mpwldectrl1); > + if (calib) { > + calib->p0_mpwldectrl0 = readl(&mmdc0->mpwldectrl0); > + calib->p0_mpwldectrl1 = readl(&mmdc0->mpwldectrl1); > + calib->p1_mpwldectrl0 = readl(&mmdc1->mpwldectrl0); > + calib->p1_mpwldectrl1 = readl(&mmdc1->mpwldectrl1); > + } else { > + readl(&mmdc0->mpwldectrl0); > + readl(&mmdc0->mpwldectrl1); > + readl(&mmdc1->mpwldectrl0); > + readl(&mmdc1->mpwldectrl1); > + } > > /* enable DDR logic power down timer: */ > setbits_le32(&mmdc0->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(&mmdc0->mpdgctrl0); > + calib->p0_mpdgctrl1 = readl(&mmdc0->mpdgctrl1); > + calib->p1_mpdgctrl0 = readl(&mmdc1->mpdgctrl0); > + calib->p1_mpdgctrl1 = readl(&mmdc1->mpdgctrl1); > + calib->p0_mprddlctl = readl(&mmdc0->mprddlctl); > + calib->p1_mprddlctl = readl(&mmdc1->mprddlctl); > + calib->p0_mpwrdlctl = readl(&mmdc0->mpwrdlctl); > + calib->p1_mpwrdlctl = readl(&mmdc1->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
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
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
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
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)
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
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)
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
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
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
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
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
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
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", &len); > + 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 +42,7 @@ int arch_fixup_fdt(void *blob) >
Re: [U-Boot] [PATCH] ARM: vexpress: Remove virt and nonsec support for TC2
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
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
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
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
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
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 = &gur->bootlocptrl; > + boot_loc_ptr_h = &gur->bootlocptrh; > +#elif defined(CONFIG_FSL_LSCH2) > + struct ccsr_scfg __iomem *scfg = (void *)(CONFIG_SYS_FSL_SCFG_ADDR); > + boot_loc_ptr_l = &scfg->scratchrw[1]; > + boot_loc_ptr_h = &scfg->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
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
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
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
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
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
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
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
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
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
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); > > > >> > > > >> Uart boot will break because o
Re: [U-Boot] Pull request: u-boot-net.git master
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)
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
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
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 then U-Boot itself via UART and Y-MODEM
Re: [U-Boot] [PATCH 5/9] arm: omap-common: secure ROM signature verify API
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 acceptable? Or is there a better way?
[U-Boot] Válasz: Továbbítás: u-boot
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
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
> > 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 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
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 BOOTDELAY depends on AUTOBOOT
Re: [U-Boot] [PATCH 3/6] autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK
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
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= &i2c_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= &i2c_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)
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
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
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
Rename B&R 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&R KWB Board + * Board functions for B&R 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[] = { &cmwkup->wkup_adctscctrl, &cmper->spi1clkctrl, &cmper->dcan0clkctrl, @@ -113,7 +113,7 @@ void am33xx_spl_board_init(void) &cmper->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 2bddc6b..11f56bf 100644 --- a/include/configs/kwb.h +++ b/include/configs/
[U-Boot] [PATCH v1 0/2] Rename all B&R boards to more meaningful name
We've internally decided to name all B&R 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
[U-Boot] [PATCH v1 1/2] board/BuR: rename tseries board to brppt1
Rename B&R 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&R LEIT Board + * Board functions for B&R 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&R LEIT Board(s) + * Pinmux Setting for B&R 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 --- a/configs/tseries_mmc_defconfig +++ b/configs/brppt1_mmc_defconfig @@ -1,5 +1,5 @@ CONFIG_ARM=y -CONFIG_TARGET_TS
Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128
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
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
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
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
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
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
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()
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, &hub); +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
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
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
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), - &actual_len, - USB_BULK_SEND_TIMEOUT); + err = usb_bulk_msg(udev, usb_sndbulkpipe(udev, ueth->ep_out), + (void *)msg, length + sizeof(struct tx_desc), + &actual_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(&tp->ueth, packet, length); +} + +int r8152_eth_recv(struct udevice *dev, int flags, uchar **packetp) +{ + struct r8152 *tp = dev_get_priv(dev); + struct ueth_data *ueth = &tp->ueth; + uint8_t *ptr; +