Re: [U-Boot] [PATCH] x86: minnowmax: add GPIO mapping support
Hi Bin, On 02/26/2015 07:30 PM, Bin Meng wrote: Hi Gabriel, On Thu, Feb 26, 2015 at 12:27 AM, Gabriel Huau wrote: Hi Bin, On 02/24/2015 11:52 PM, Bin Meng wrote: Hi Gabriel, On Mon, Feb 16, 2015 at 5:55 AM, Gabriel Huau wrote: Configure the pinctrl as it required to make some IO controllers working (USB/UART/I2C/...). The idea would be in the next version to modify the pch GPIO driver and configure these pins through the device tree. These modifications are ported from the coreboot project. Signed-off-by: Gabriel Huau --- arch/x86/cpu/baytrail/Makefile| 1 + arch/x86/cpu/baytrail/gpio.c | 206 +++ arch/x86/include/asm/arch-baytrail/gpio.h | 364 ++ arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++ arch/x86/include/asm/arch-baytrail/irq.h | 119 + arch/x86/include/asm/arch-baytrail/irqroute.h | 67 + arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++ arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++ board/intel/minnowmax/minnowmax.c | 212 +++ include/configs/minnowmax.h | 11 + 10 files changed, 1450 insertions(+) create mode 100644 arch/x86/cpu/baytrail/gpio.c create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h [snip] diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h index 823e051..738c6fa 100644 --- a/include/configs/minnowmax.h +++ b/include/configs/minnowmax.h @@ -69,4 +69,15 @@ /* Avoid a warning in the Realtek Ethernet driver */ #define CONFIG_SYS_CACHELINE_SIZE 16 +/* + * Baytrail has 3 GPIOs bank over PCI, there is no + * driver at the moment so let's disable the command + * and the default x86 driver to avoid any collision + * with the GPIO mapping code. + * @TODO: adding a baytrail-gpio driver and configure + * the muxing through the device tree + */ +#undef CONFIG_INTEL_ICH6_GPIO +#undef CONFIG_CMD_GPIO + Why undef these two? The BayTrail SoC does support GPIO banks in the legacy bridge. I might misunderstood the GPIO subsystem but I thought there was 2 banks available through the PCU iLB GPIO controller which contains the SCORE and SSUS (102 / 44 pins). The intel_ich6_gpio has a limitation of 32 GPIOs per bank and I thought it was just a different controller from the Baytrail, but if I can use it to control all the GPIOs + doing the IO mapping, I'll be glad to do it! I checked the BayTrail datasheet. Its GPIO is in the iLB (legacy bridge), which is the same as other IA chipset (Ivybridge, TunnelCreek, Quark). It has 4 banks in core domain and 2 banks in sus domain. So 6 banks in total. You need define 6 gpio nodes in the minnowmax board dts file. You should be able to use the existing gpio driver to configure. Thanks for the clarification! Actually, I saw it today when I was doing some tests and I configured the 6 banks in the devices tree. I also fixed the GPIO base address to 0x48 but I got some issues like the fact I'm reading only 0 from all the registers. The registers are configured to be in the IO Space (0x500), I checked the PCI configuration space to make sure that everything is enabled correctly, but I'm still missing something. Once I'll be able to use these GPIOs, I will update the entire patch to remove the port from Coreboot as this is not necessary. #endif /* __CONFIG_H */ -- Regards, Bin Regards, Gabriel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI3000 U-Boot debugging questions (MX51/MX53)
Hi Dave, On Thu, Feb 26, 2015 at 9:05 PM, DaveKucharczyk wrote: > I would like to debug from the earliest possible point pre-relocation (for > educational reasons). Couple questions > > In the Makefile, where do I place the following flags... > -Os #-fomit-frame-pointer -g -fno-schedule-insns -fno-schedule-insns2 > > I've added the flags in a few different spots, but I still can't break on > cpu_init_f. > Here's the output... > (gdb) b cpu_init_f > Function "cpu_init_f" not defined. > Make breakpoint pending on future shared library load? (y or [n]) y > > I assume the flags didn't get set, specifically -g. > > To backup a little here is what I get when I do target remote... > > (gdb) target remote 169.254.21.13:2001 > Remote debugging using 169.254.21.13:2001 > warning: Unable to find dynamic linker breakpoint function. > GDB will be unable to debug shared library initializers > and track explicitly loaded dynamic code. > 0x in ?? () > (gdb) > > I assume those warning are related to my issue above? You have to load the symbols from the unstripped U-Boot ELF file: https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#Files You can use 'symbol-file' first. The loaded symbols will match the PC values only until relocation. Then, you can use 'add-symbol-file' to specify the relocation address. If needed, 'set sysroot' can be used for the shared libraries, but this does not apply to U-Boot. Note that very early after boot, the PC will be in the boot ROM, so there won't be any matching symbols. > Also, when I power on the target, u-boot just starts loading. How do I halt > it? I tried to set a breakpoint at text base in the BDI, but it doesn't > halt. You must have a configuration file for your JTAG probe. In this file, you can choose between hardware and software breakpoints, select the default action (run, run for some time, halt, etc.), set breakpoints, etc. With all these settings, you should be able to halt early. You can also use the JTAG probe Telnet to issue a manual break when needed. Avoid setting breakpoints directly onto exception vectors like reset; sometimes it does not work well, so it is better to set it on a known function executed a bit later. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Hi Dave, On Thu, Feb 26, 2015 at 3:19 PM, DaveKucharczyk wrote: > Benoît Thébaudeau-2 wrote >> Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm >> wondering if it's not set too high, resulting in an overlap of the >> pre- and post-relocation addresses occupied by your binary in the >> 256-MiB case. > > BINGO!!! Good catch Benoît, thank you. I changed it from 9FF8 to > 9F00 and now it boots. > > Looking at the original log...it relocated 90KB above text base. Not quite > enough room... > > U-Boot code: 9FF8 -> 9FFA6840 BSS: -> 9FFD944C > . > Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0 > -- You're welcome. > On a side note, how involved would it be to convert to 2015.01? I've already > ported 3 boards for 2014.07. Will everything I've done work perfectly fine > with 2015.01? You will probably have to make a few adjustments, but that should not be too heavy. There have been many changes in the infrastructure of U-Boot lately, mainly revolving around the integration of Kconfig, Kbuild and the driver model. At worst, you should have to upgrade your config / make / maintainers files, and maybe adjust your code for a few changes in the driver APIs. To have an idea: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=history;f=board/freescale/mx51evk;hpb=refs/tags/v2014.07;hb=refs/tags/v2015.01 Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: Add Xilinx ZynqMP support
Hi, On 02/24/2015 09:02 AM, Michal Simek wrote: > Add basic Xilinx ZynqMP arm64 support. > Serial and SD is supported. > It supports emulation platfrom ep108 and QEMU. > > Signed-off-by: Michal Simek > --- > > MAINTAINERS | 6 ++ > arch/arm/Kconfig | 5 + > arch/arm/cpu/armv8/Makefile | 1 + > arch/arm/cpu/armv8/zynqmp/Makefile | 9 ++ > arch/arm/cpu/armv8/zynqmp/clk.c | 49 ++ > arch/arm/cpu/armv8/zynqmp/cpu.c | 28 ++ > arch/arm/include/asm/arch-zynqmp/clk.h | 13 +++ > arch/arm/include/asm/arch-zynqmp/hardware.h | 52 +++ > arch/arm/include/asm/arch-zynqmp/sys_proto.h | 15 +++ > board/xilinx/zynqmp/Kconfig | 15 +++ > board/xilinx/zynqmp/MAINTAINERS | 6 ++ > board/xilinx/zynqmp/Makefile | 8 ++ > board/xilinx/zynqmp/zynqmp.c | 90 ++ > configs/xilinx_zynqmp_defconfig | 14 +++ > include/configs/xilinx_zynqmp.h | 134 > +++ > 15 files changed, 445 insertions(+) > create mode 100644 arch/arm/cpu/armv8/zynqmp/Makefile > create mode 100644 arch/arm/cpu/armv8/zynqmp/clk.c > create mode 100644 arch/arm/cpu/armv8/zynqmp/cpu.c > create mode 100644 arch/arm/include/asm/arch-zynqmp/clk.h > create mode 100644 arch/arm/include/asm/arch-zynqmp/hardware.h > create mode 100644 arch/arm/include/asm/arch-zynqmp/sys_proto.h > create mode 100644 board/xilinx/zynqmp/Kconfig > create mode 100644 board/xilinx/zynqmp/MAINTAINERS > create mode 100644 board/xilinx/zynqmp/Makefile > create mode 100644 board/xilinx/zynqmp/zynqmp.c > create mode 100644 configs/xilinx_zynqmp_defconfig > create mode 100644 include/configs/xilinx_zynqmp.h Any comment on this one? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: minnowmax: add GPIO mapping support
Hi Gabriel, On Thu, Feb 26, 2015 at 12:27 AM, Gabriel Huau wrote: > Hi Bin, > > > On 02/24/2015 11:52 PM, Bin Meng wrote: >> >> Hi Gabriel, >> >> On Mon, Feb 16, 2015 at 5:55 AM, Gabriel Huau >> wrote: >>> >>> Configure the pinctrl as it required to make some IO controllers >>> working (USB/UART/I2C/...). >>> The idea would be in the next version to modify the pch GPIO driver and >>> configure these pins through the device tree. >>> >>> These modifications are ported from the coreboot project. >>> >>> Signed-off-by: Gabriel Huau >>> --- >>> arch/x86/cpu/baytrail/Makefile| 1 + >>> arch/x86/cpu/baytrail/gpio.c | 206 +++ >>> arch/x86/include/asm/arch-baytrail/gpio.h | 364 >>> ++ >>> arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++ >>> arch/x86/include/asm/arch-baytrail/irq.h | 119 + >>> arch/x86/include/asm/arch-baytrail/irqroute.h | 67 + >>> arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++ >>> arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++ >>> board/intel/minnowmax/minnowmax.c | 212 +++ >>> include/configs/minnowmax.h | 11 + >>> 10 files changed, 1450 insertions(+) >>> create mode 100644 arch/x86/cpu/baytrail/gpio.c >>> create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h >>> >> [snip] >> >>> diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h >>> index 823e051..738c6fa 100644 >>> --- a/include/configs/minnowmax.h >>> +++ b/include/configs/minnowmax.h >>> @@ -69,4 +69,15 @@ >>> /* Avoid a warning in the Realtek Ethernet driver */ >>> #define CONFIG_SYS_CACHELINE_SIZE 16 >>> >>> +/* >>> + * Baytrail has 3 GPIOs bank over PCI, there is no >>> + * driver at the moment so let's disable the command >>> + * and the default x86 driver to avoid any collision >>> + * with the GPIO mapping code. >>> + * @TODO: adding a baytrail-gpio driver and configure >>> + * the muxing through the device tree >>> + */ >>> +#undef CONFIG_INTEL_ICH6_GPIO >>> +#undef CONFIG_CMD_GPIO >>> + >> >> Why undef these two? The BayTrail SoC does support GPIO banks in the >> legacy bridge. > > I might misunderstood the GPIO subsystem but I thought there was 2 banks > available through the PCU iLB GPIO controller which contains the SCORE and > SSUS (102 / 44 pins). > The intel_ich6_gpio has a limitation of 32 GPIOs per bank and I thought it > was just a different controller from the Baytrail, but if I can use it to > control all the GPIOs + doing the IO mapping, I'll be glad to do it! I checked the BayTrail datasheet. Its GPIO is in the iLB (legacy bridge), which is the same as other IA chipset (Ivybridge, TunnelCreek, Quark). It has 4 banks in core domain and 2 banks in sus domain. So 6 banks in total. You need define 6 gpio nodes in the minnowmax board dts file. You should be able to use the existing gpio driver to configure. >> >>> #endif /* __CONFIG_H */ >>> -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] unassigned-patches/135: Re: [PATCH] x86: minnowmax: add GPIO mapping support
Hi Gabriel, On Thu, Feb 26, 2015 at 12:27 AM, Gabriel Huau wrote: > Hi Bin, > > > On 02/24/2015 11:52 PM, Bin Meng wrote: >> >> Hi Gabriel, >> >> On Mon, Feb 16, 2015 at 5:55 AM, Gabriel Huau >> wrote: >>> >>> Configure the pinctrl as it required to make some IO controllers >>> working (USB/UART/I2C/...). >>> The idea would be in the next version to modify the pch GPIO driver and >>> configure these pins through the device tree. >>> >>> These modifications are ported from the coreboot project. >>> >>> Signed-off-by: Gabriel Huau >>> --- >>> arch/x86/cpu/baytrail/Makefile| 1 + >>> arch/x86/cpu/baytrail/gpio.c | 206 +++ >>> arch/x86/include/asm/arch-baytrail/gpio.h | 364 >>> ++ >>> arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++ >>> arch/x86/include/asm/arch-baytrail/irq.h | 119 + >>> arch/x86/include/asm/arch-baytrail/irqroute.h | 67 + >>> arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++ >>> arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++ >>> board/intel/minnowmax/minnowmax.c | 212 +++ >>> include/configs/minnowmax.h | 11 + >>> 10 files changed, 1450 insertions(+) >>> create mode 100644 arch/x86/cpu/baytrail/gpio.c >>> create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h >>> create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h >>> >> [snip] >> >>> diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h >>> index 823e051..738c6fa 100644 >>> --- a/include/configs/minnowmax.h >>> +++ b/include/configs/minnowmax.h >>> @@ -69,4 +69,15 @@ >>> /* Avoid a warning in the Realtek Ethernet driver */ >>> #define CONFIG_SYS_CACHELINE_SIZE 16 >>> >>> +/* >>> + * Baytrail has 3 GPIOs bank over PCI, there is no >>> + * driver at the moment so let's disable the command >>> + * and the default x86 driver to avoid any collision >>> + * with the GPIO mapping code. >>> + * @TODO: adding a baytrail-gpio driver and configure >>> + * the muxing through the device tree >>> + */ >>> +#undef CONFIG_INTEL_ICH6_GPIO >>> +#undef CONFIG_CMD_GPIO >>> + >> >> Why undef these two? The BayTrail SoC does support GPIO banks in the >> legacy bridge. > > I might misunderstood the GPIO subsystem but I thought there was 2 banks > available through the PCU iLB GPIO controller which contains the SCORE and > SSUS (102 / 44 pins). > The intel_ich6_gpio has a limitation of 32 GPIOs per bank and I thought it > was just a different controller from the Baytrail, but if I can use it to > control all the GPIOs + doing the IO mapping, I'll be glad to do it! I checked the BayTrail datasheet. Its GPIO is in the iLB (legacy bridge), which is the same as other IA chipset (Ivybridge, TunnelCreek, Quark). It has 4 banks in core domain and 2 banks in sus domain. So 6 banks in total. You need define 6 gpio nodes in the minnowmax board dts file. You should be able to use the existing gpio driver to configure. >> >>> #endif /* __CONFIG_H */ >>> -- Regards, Bin --- Added to GNATS database as unassigned-patches/135 >Responsible:patch-coord >Message-Id: > >In-Reply-To:<54edf800.8060...@huau-gabriel.fr> >References: <1424037328-31636-1-git-send-email-cont...@huau-gabriel.fr> > ><54edf800.8060...@huau-gabriel.fr> >Patch-Date: Fri Feb 27 04:30:19 +0100 2015 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
On Thu, 2015-02-26 at 22:35 -0600, Bansal Aneesh-B39320 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Thursday, February 26, 2015 3:43 AM
> > To: Bansal Aneesh-B39320
> > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > secure boot target for P3041
> >
> > [Reposting comment on v4 as York requested]
> >
> > On Wed, Feb 25, 2015 at 02:17:56PM +0530, Aneesh Bansal wrote:
> > > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > index 4cf8853..ef56cc0 100644
> > > --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > @@ -843,6 +843,23 @@ int cpu_init_r(void)
> > > setup_mp();
> > > #endif
> > >
> > > +#if defined(CONFIG_SYS_RAMBOOT) &&
> > defined(CONFIG_SYS_INIT_L3_ADDR) && \
> > > + defined(CONFIG_SECURE_BOOT)
> > > + /* Disable the TLB Created for L3 and create the TLB required for
> > > + * PCIE (CONFIG_SYS_PCIE1_MEM_VIRT) which was not created
> > earlier.
> > > + */
> > > + int tlb_index;
> > > + tlb_index = find_tlb_idx((void *)CONFIG_BPTR_VIRT_ADDR, 1);
> > > + if (tlb_index != -1) {
> > > + disable_tlb(tlb_index);
> > > +
> > > + set_tlb(1, CONFIG_SYS_PCIE1_MEM_VIRT,
> > > + CONFIG_SYS_PCIE1_MEM_PHYS,
> > > + MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> > > + 0, tlb_index, BOOKE_PAGESZ_1G, 1);
> > > + }
> > > +#endif
> >
> > Why are you assuming in generic 85xx code that the TLB for PCIE1 needs to
> > be created? e500mc should have enough TLB1 entries that you don't need to
> > share (or if it's due to address conflicts, a board may have PCI at a
> > different
> > address), and PCI may not exist at all on some boards.
> >
> > -Scott
>
> TLB's are created in freescale/common/p_corenet/tlb.c
Which doesn't apply to all 85xx boards (even custom corenet-based boards
might not use it -- or if that's not the case, it should be moved out of
the board directory). It's also not obvious to anyone modifying that
tlb.c file or the address of PCIE1 that this would be affected.
> In case of Secure Boot, L3 is used as 1M SRAM and the address of the SRAM is
> at 0xbff0.
Is this hardcoded into the silicon, or determined by PBI or something
similar? If it's not hardcoded, can we choose a less problematic
address?
If it is hardcoded, and we don't want to change the PCIE1 virtual
address, at least create defines for the entry to be created once SRAM
goes away, rather than hardcoding PCIE1 here.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] mx6sabre: Select CMD_EXT4 options
Hi Otavio, On 02/26/2015 11:02 PM, Otavio Salvador wrote: On Thu, Feb 26, 2015 at 4:58 PM, Fabio Estevam wrote: Add EXT4 support. Signed-off-by: Fabio Estevam Acked-by: Otavio Salvador And sorry for not notice the mistake in the commit log. There's no reason for anyone to feel sorry. This is a team work and for me it's an honor to be able to help you guys in any possible way. Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v2] rsa : Compile Modular Exponentiation files based on CONFIG_RSA_SOFTWARE_EXP
Remove dependency of rsa_mod_exp from CONFIG_FIT_SIGNATURE. As rsa modular exponentiation is an independent module and can be invoked independently. Signed-off-by: Gaurav Rana Reviewed-by: Simon Glass CC: Simon Glass --- Changes in v2: add elaborated commit message. drivers/crypto/rsa_mod_exp/Makefile | 3 ++- lib/rsa/Makefile| 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/rsa_mod_exp/Makefile b/drivers/crypto/rsa_mod_exp/Makefile index 915b751..ae3dcf3 100644 --- a/drivers/crypto/rsa_mod_exp/Makefile +++ b/drivers/crypto/rsa_mod_exp/Makefile @@ -4,4 +4,5 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-$(CONFIG_RSA) += mod_exp_uclass.o mod_exp_sw.o +obj-$(CONFIG_RSA) += mod_exp_uclass.o +obj-$(CONFIG_RSA_SOFTWARE_EXP) += mod_exp_sw.o diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index cc25b3c..6867e50 100644 --- a/lib/rsa/Makefile +++ b/lib/rsa/Makefile @@ -7,4 +7,5 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o rsa-mod-exp.o +obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o +obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, February 26, 2015 3:43 AM
> To: Bansal Aneesh-B39320
> Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> secure boot target for P3041
>
> [Reposting comment on v4 as York requested]
>
> On Wed, Feb 25, 2015 at 02:17:56PM +0530, Aneesh Bansal wrote:
> > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > index 4cf8853..ef56cc0 100644
> > --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > @@ -843,6 +843,23 @@ int cpu_init_r(void)
> > setup_mp();
> > #endif
> >
> > +#if defined(CONFIG_SYS_RAMBOOT) &&
> defined(CONFIG_SYS_INIT_L3_ADDR) && \
> > + defined(CONFIG_SECURE_BOOT)
> > + /* Disable the TLB Created for L3 and create the TLB required for
> > +* PCIE (CONFIG_SYS_PCIE1_MEM_VIRT) which was not created
> earlier.
> > +*/
> > + int tlb_index;
> > + tlb_index = find_tlb_idx((void *)CONFIG_BPTR_VIRT_ADDR, 1);
> > + if (tlb_index != -1) {
> > + disable_tlb(tlb_index);
> > +
> > + set_tlb(1, CONFIG_SYS_PCIE1_MEM_VIRT,
> > + CONFIG_SYS_PCIE1_MEM_PHYS,
> > + MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> > + 0, tlb_index, BOOKE_PAGESZ_1G, 1);
> > + }
> > +#endif
>
> Why are you assuming in generic 85xx code that the TLB for PCIE1 needs to
> be created? e500mc should have enough TLB1 entries that you don't need to
> share (or if it's due to address conflicts, a board may have PCI at a
> different
> address), and PCI may not exist at all on some boards.
>
> -Scott
TLB's are created in freescale/common/p_corenet/tlb.c
In case of Secure Boot, L3 is used as 1M SRAM and the address of the SRAM is at
0xbff0.
The PCIE TLB entry conflicts with the above entry and so the entry for PCIE was
not created
at that point of time.
This is why it is being created here in cpu_init_r() when U-Boot has relocated
to DDR and the
TLB entry for SRAM is not required.
Proper comments have been added in tlb.c to explain why it is being done.
If address for PCI is changed than this also will have to be taken care of.
The code is protected by relevant macros (CONFIG_SYS_RAMBOOT,
CONFIG_SYS_INIT_L3_ADDR,
CONFIG_SECURE_BOOT)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] mx6sabre: Select CMD_EXT4 options
On Thu, Feb 26, 2015 at 9:19 PM, Nikolay Dimitrov wrote: > Hi Otavio, > > On 02/26/2015 11:02 PM, Otavio Salvador wrote: >> >> On Thu, Feb 26, 2015 at 4:58 PM, Fabio Estevam >> wrote: >>> >>> Add EXT4 support. >>> >>> Signed-off-by: Fabio Estevam >> >> >> Acked-by: Otavio Salvador >> >> And sorry for not notice the mistake in the commit log. > > > There's no reason for anyone to feel sorry. This is a team work and for me > it's an honor to be able to help you guys in any possible way. +1 :-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, February 27, 2015 10:22 AM
> To: Bansal Aneesh-B39320
> Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> secure boot target for P3041
>
> On Thu, 2015-02-26 at 22:35 -0600, Bansal Aneesh-B39320 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, February 26, 2015 3:43 AM
> > > To: Bansal Aneesh-B39320
> > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > > secure boot target for P3041
> > >
> > > [Reposting comment on v4 as York requested]
> > >
> > > On Wed, Feb 25, 2015 at 02:17:56PM +0530, Aneesh Bansal wrote:
> > > > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > > b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > > index 4cf8853..ef56cc0 100644
> > > > --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> > > > @@ -843,6 +843,23 @@ int cpu_init_r(void)
> > > > setup_mp();
> > > > #endif
> > > >
> > > > +#if defined(CONFIG_SYS_RAMBOOT) &&
> > > defined(CONFIG_SYS_INIT_L3_ADDR) && \
> > > > + defined(CONFIG_SECURE_BOOT)
> > > > + /* Disable the TLB Created for L3 and create the TLB required
> > > > for
> > > > +* PCIE (CONFIG_SYS_PCIE1_MEM_VIRT) which was not created
> > > earlier.
> > > > +*/
> > > > + int tlb_index;
> > > > + tlb_index = find_tlb_idx((void *)CONFIG_BPTR_VIRT_ADDR, 1);
> > > > + if (tlb_index != -1) {
> > > > + disable_tlb(tlb_index);
> > > > +
> > > > + set_tlb(1, CONFIG_SYS_PCIE1_MEM_VIRT,
> > > > + CONFIG_SYS_PCIE1_MEM_PHYS,
> > > > + MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> > > > + 0, tlb_index, BOOKE_PAGESZ_1G, 1);
> > > > + }
> > > > +#endif
> > >
> > > Why are you assuming in generic 85xx code that the TLB for PCIE1
> > > needs to be created? e500mc should have enough TLB1 entries that
> > > you don't need to share (or if it's due to address conflicts, a
> > > board may have PCI at a different address), and PCI may not exist
> > > at all on
> some boards.
> > >
> > > -Scott
> >
> > TLB's are created in freescale/common/p_corenet/tlb.c
>
> Which doesn't apply to all 85xx boards (even custom corenet-based
> boards might not use it -- or if that's not the case, it should be
> moved out of the board directory). It's also not obvious to anyone
> modifying that tlb.c file or the address of PCIE1 that this would be affected.
>
> > In case of Secure Boot, L3 is used as 1M SRAM and the address of the
> SRAM is at 0xbff0.
>
> Is this hardcoded into the silicon, or determined by PBI or something similar?
> If it's not hardcoded, can we choose a less problematic address?
It is not hardcoded but we have a restriction of choosing the address within 0
- 3.5G.
0xbff0 seemed to be the least problematic at this point of time.
> If it is hardcoded, and we don't want to change the PCIE1 virtual
> address, at least create defines for the entry to be created once SRAM
> goes away, rather than hardcoding PCIE1 here.
>
Are you suggesting something like this in cpu_init_r() set_tlb(1,
CONFIG_SECBOOT_TLB_VIRT_ADDR,
CONFIG_SECBOOT_TLB_PHYS_ADDR,
CONFIG_SECBOOT_TLB_PERM, CONFIG_SECBOOT_TLB_ATTR,
0, tlb_index, CONFIG_SECBOOT_TLB_PAGESZ, 1);
I plan to define these macros in tlb.c where we have added the code for these
TLBS creation
#define CONFIG_SECBOOT_TLB_VIRT_ADDRCONFIG_SYS_PCIE1_MEM_VIRT
#define CONFIG_SECBOOT_TLB_PHYS_ADDRCONFIG_SYS_PCIE1_MEM_PHYS
#define CONFIG_SECBOOT_TLB_PERM MAS3_SW|MAS3_SR
#define CONFIG_SECBOOT_TLB_ATTR MAS2_I|MAS2_G
#define CONFIG_SECBOOT_TLB_PAGESZ BOOKE_PAGESZ_1G
> -Scott
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Hi Albert, On Thu, Feb 26, 2015 at 11:38 AM, Albert ARIBAUD wrote: > Hello Benoît, > > On Thu, 26 Feb 2015 00:56:00 +0100, Benoît Thébaudeau > wrote: >> Dear Dave Kucharczyk, >> >> On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk >> wrote: >> > Fabio Estevam-2 wrote >> >> Also, you said that your 512MB board version works fine, but the 256MB >> >> fails. >> >> >> >> I suppose you are using two different binaries for each board, right? >> >> You can't have a single binary for the two boards, unless you use the >> >> SPL approach. >> > >> > Fabio, we use one binary. It has runtime memory discovery via gpio's >> > (resistor reads). DRAM size is reported correctly from both boards. It just >> > hangs on the 256MB board. >> > >> > We do not have SPL setup. >> >> You should try with 2015.01 as Fabio suggested. >> >> Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm >> wondering if it's not set too high, resulting in an overlap of the >> pre- and post-relocation addresses occupied by your binary in the >> 256-MiB case. > > /me wonders whether we should not add a test for this situation, with > a conspicuous error message on the console stating that relocation will > probably fail due to overlap. Yes, that would be very helpful in such a case, which must occur very often for new boards being ported to U-Boot. Besides that, it would be great if CONFIG_SYS_TEXT_BASE could be automatically set to a sensible value for most boards, from the configured internal/external RAM base addresses. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4][v3] SECURE_BOOT : enable esbc_validate command for powerpc and arm platforms.
esbc_validate command uses various IP Blocks: Security Monitor, CAAM block
and SFP registers. Hence the respective CONFIG's are enabled.
Apart from these CONFIG_SHA_PROG_HW_ACCEL and CONFIG_RSA are also enabled.
Signed-off-by: Gaurav Rana
---
Changes in v3:
No change. Change in other patches of the patch set.
Changes in v2:
Merge patches of enablement for powerpc and enablement for arm.
arch/arm/include/asm/arch-ls102xa/config.h | 20 +
arch/powerpc/include/asm/config_mpc85xx.h | 1 +
arch/powerpc/include/asm/fsl_secure_boot.h | 35 ++
arch/powerpc/include/asm/immap_85xx.h | 6 -
board/freescale/common/Makefile| 6 +
5 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index 7915518..5d81280 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -27,6 +27,8 @@
#define CONFIG_SYS_FSL_SCFG_ADDR (CONFIG_SYS_IMMR + 0x0057)
#define CONFIG_SYS_FSL_SEC_ADDR(CONFIG_SYS_IMMR +
0x70)
#define CONFIG_SYS_FSL_JR0_ADDR(CONFIG_SYS_IMMR +
0x71)
+#define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR +
0x00e9)
+#define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0x00e80200)
#define CONFIG_SYS_FSL_SERDES_ADDR (CONFIG_SYS_IMMR + 0x00ea)
#define CONFIG_SYS_FSL_GUTS_ADDR (CONFIG_SYS_IMMR + 0x00ee)
#define CONFIG_SYS_FSL_LS1_CLK_ADDR(CONFIG_SYS_IMMR + 0x00ee1000)
@@ -80,7 +82,25 @@
#define CONFIG_SYS_FSL_DSPI_BE
#define CONFIG_SYS_FSL_QSPI_BE
#define CONFIG_SYS_FSL_DCU_BE
+#define CONFIG_SYS_FSL_SEC_MON_LE
#define CONFIG_SYS_FSL_SEC_LE
+#define CONFIG_SYS_FSL_SFP_VER_3_2
+#define CONFIG_SYS_FSL_SFP_BE
+#define CONFIG_SYS_FSL_SRK_LE
+#define CONFIG_KEY_REVOCATION
+#define CONFIG_FSL_ISBC_KEY_EXT
+
+#ifdef CONFIG_SECURE_BOOT
+#define CONFIG_CMD_ESBC_VALIDATE
+#define CONFIG_FSL_SEC_MON
+#define CONFIG_SHA_PROG_HW_ACCEL
+#define CONFIG_DM
+#define CONFIG_RSA
+#define CONFIG_RSA_FREESCALE_EXP
+#ifndef CONFIG_FSL_CAAM
+#define CONFIG_FSL_CAAM
+#endif
+#endif
#define DCU_LAYER_MAX_NUM 16
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 7fc352e..f93c19c 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -26,6 +26,7 @@
#define CONFIG_SYS_FSL_IFC_BE
#define CONFIG_SYS_FSL_SEC_BE
#define CONFIG_SYS_FSL_SFP_BE
+#define CONFIG_SYS_FSL_SEC_MON_BE
/* Number of TLB CAM entries we have on FSL Book-E chips */
#if defined(CONFIG_E500MC)
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h
b/arch/powerpc/include/asm/fsl_secure_boot.h
index b4c0c99..49f6814 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -6,6 +6,19 @@
#ifndef __FSL_SECURE_BOOT_H
#define __FSL_SECURE_BOOT_H
+#include
+
+#ifdef CONFIG_SECURE_BOOT
+#define CONFIG_CMD_ESBC_VALIDATE
+#define CONFIG_FSL_SEC_MON
+#define CONFIG_SHA_PROG_HW_ACCEL
+#define CONFIG_DM
+#define CONFIG_RSA
+#define CONFIG_RSA_FREESCALE_EXP
+#ifndef CONFIG_FSL_CAAM
+#define CONFIG_FSL_CAAM
+#endif
+#endif
#ifdef CONFIG_SECURE_BOOT
#if defined(CONFIG_FSL_CORENET)
@@ -28,9 +41,31 @@
defined(CONFIG_PPC_T1023) || \
defined(CONFIG_PPC_T1024)
#define CONFIG_SYS_CPC_REINIT_F
+#define CONFIG_KEY_REVOCATION
#undef CONFIG_SYS_INIT_L3_ADDR
#define CONFIG_SYS_INIT_L3_ADDR0xbff0
#endif
+#if defined(CONFIG_C29XPCIE)
+#define CONFIG_KEY_REVOCATION
+#endif
+
+#if defined(CONFIG_PPC_P3041) || \
+ defined(CONFIG_PPC_P4080) ||\
+ defined(CONFIG_PPC_P5020) ||\
+ defined(CONFIG_PPC_P5040) ||\
+ defined(CONFIG_PPC_P2041)
+ #define CONFIG_FSL_TRUST_ARCH_v1
+#endif
+
+#if defined(CONFIG_FSL_CORENET)
+/* The key used for verification of next level images
+ * is picked up from an Extension Table which has
+ * been verified by the ISBC (Internal Secure boot Code)
+ * in boot ROM of the SoC
+ */
+#define CONFIG_FSL_ISBC_KEY_EXT
+#endif
+
#endif
#endif
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index f89b90b..0c9d85e 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -2883,6 +2883,7 @@ struct ccsr_pman {
#define CONFIG_SYS_MPC85xx_SATA2_OFFSET0x221000
#define CONFIG_SYS_FSL_SEC_OFFSET 0x30
#define CONFIG_SYS_FSL_JR0_OFFSET 0x301000
+#define CONFIG_SYS_SEC_MON_OFFSET 0x314000
#define CONFIG_SYS_FSL_CORENET_PME_OFFSET 0x316000
#define CONFIG_SYS_FSL_QMAN_OFFSET 0x318000
#define CONFIG_SYS_FSL_BMAN_OFFSET 0x31a000
@@ -2950,7 +2951,7 @@ struct ccsr_pman
[U-Boot] [PATCH 3/4][v3] SECURE BOOT: Add command for validation of images
1. esbc_validate command is meant for validating header and
signature of images (Boot Script and ESBC uboot client).
SHA-256 and RSA operations are performed using SEC block in HW.
This command works on both PBL based and Non PBL based Freescale
platforms.
Command usage:
esbc_validate img_hdr_addr [pub_key_hash]
2. ESBC uboot client can be linux. Additionally, rootfs and device
tree blob can also be signed.
3. In the event of header or signature failure in validation,
ITS and ITF bits determine further course of action.
4. In case of soft failure, appropriate error is dumped on console.
5. In case of hard failure, SoC is issued RESET REQUEST after
dumping error on the console.
6. KEY REVOCATION Feature:
QorIQ platforms like B4/T4 have support of srk key table and key
revocation in ISBC code in Silicon.
The srk key table allows the user to have a key table with multiple
keys and revoke any key in case of particular key gets compromised.
In case the ISBC code uses the key revocation and srk key table to
verify the u-boot code, the subsequent chain of trust should also
use the same.
6. ISBC KEY EXTENSION Feature:
This feature allows large number of keys to be used for esbc validation
of images. A set of public keys is being signed and validated by ISBC
which can be further used for esbc validation of images.
Signed-off-by: Ruchika Gupta
Signed-off-by: Gaurav Rana
---
Changes in v3:
No change. Change in other patches of the patch set.
Changes in v2:
Copyright is changed in all the files in the patch.
board/freescale/common/cmd_esbc_validate.c | 34 ++
board/freescale/common/fsl_validate.c | 840 +
doc/README.esbc_validate | 41 ++
include/fsl_secboot_err.h | 128 +
include/fsl_validate.h | 199 +++
5 files changed, 1242 insertions(+)
create mode 100644 board/freescale/common/cmd_esbc_validate.c
create mode 100644 board/freescale/common/fsl_validate.c
create mode 100644 doc/README.esbc_validate
create mode 100644 include/fsl_secboot_err.h
create mode 100644 include/fsl_validate.h
diff --git a/board/freescale/common/cmd_esbc_validate.c
b/board/freescale/common/cmd_esbc_validate.c
new file mode 100644
index 000..8500ba5
--- /dev/null
+++ b/board/freescale/common/cmd_esbc_validate.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+
+static int do_esbc_validate(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ if (argc < 2)
+ return cmd_usage(cmdtp);
+
+ return fsl_secboot_validate(cmdtp, flag, argc, argv);
+}
+
+/***/
+static char esbc_validate_help_text[] =
+ "esbc_validate hdr_addr - Validates signature using\n"
+ " RSA verification\n"
+ " $hdr_addr Address of header of the image\n"
+ " to be validated.\n"
+ " $hash_val -Optional\n"
+ " It provides Hash of public/srk key to be\n"
+ " used to verify signature.\n";
+
+U_BOOT_CMD(
+ esbc_validate, 3, 0, do_esbc_validate,
+ "Validates signature on a given image using RSA verification",
+ esbc_validate_help_text
+);
diff --git a/board/freescale/common/fsl_validate.c
b/board/freescale/common/fsl_validate.c
new file mode 100644
index 000..5283648
--- /dev/null
+++ b/board/freescale/common/fsl_validate.c
@@ -0,0 +1,840 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifndef CONFIG_MPC85xx
+#include
+#endif
+
+#define SHA256_BITS256
+#define SHA256_BYTES (256/8)
+#define SHA256_NIBBLES (256/4)
+#define NUM_HEX_CHARS (sizeof(ulong) * 2)
+
+/* This array contains DER value for SHA-256 */
+static const u8 hash_identifier[] = { 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60,
+ 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00,
+ 0x04, 0x20
+ };
+
+static u8 hash_val[SHA256_BYTES];
+static const u8 barker_code[ESBC_BARKER_LEN] = { 0x68, 0x39, 0x27, 0x81 };
+
+void branch_to_self(void) __attribute__ ((noreturn));
+
+/*
+ * This function will put core in infinite loop.
+ * This will be called when the ESBC can not proceed further due
+ * to some unknown errors.
+ */
+void branch_to_self(void)
+{
+ printf("Core is in infinite loop due to errors.\n");
+self:
+ goto self;
+}
+
+#if defined(CONFIG_FSL_ISBC_KEY_EXT)
+static u
[U-Boot] [PATCH 1/4][v3] fsl_sfp : Move ccsr_sfp_regs definition to common include
Freescale sfp has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the CCSR defintion of
sfp_regs to common include.
This patch also defines ccsr_sfp_regs definition for newer
versions of SFP.
Signed-off-by: Ruchika Gupta
Signed-off-by: Gaurav Rana
---
Changes in v3:
Modify copyright in include/fsl_sfp.h.
Changes in v2:
No change. Change in other patches of the patch set.
arch/powerpc/include/asm/config_mpc85xx.h | 1 +
arch/powerpc/include/asm/immap_85xx.h | 16 +-
include/fsl_sfp.h | 85 +++
3 files changed, 87 insertions(+), 15 deletions(-)
create mode 100644 include/fsl_sfp.h
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 01b0905..7fc352e 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -25,6 +25,7 @@
/* IP endianness */
#define CONFIG_SYS_FSL_IFC_BE
#define CONFIG_SYS_FSL_SEC_BE
+#define CONFIG_SYS_FSL_SFP_BE
/* Number of TLB CAM entries we have on FSL Book-E chips */
#if defined(CONFIG_E500MC)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index ace1d12..f89b90b 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2823,21 +2824,6 @@ struct ccsr_pman {
u8 res_f4[0xf0c];
};
#endif
-#ifdef CONFIG_SYS_FSL_SFP_VER_3_0
-struct ccsr_sfp_regs {
- u32 ospr; /* 0x200 */
- u32 reserved0[14];
- u32 srk_hash[8];/* 0x23c Super Root Key Hash */
- u32 oem_uid;/* 0x9c OEM Unique ID */
- u8 reserved2[0x04];
- u32 ovpr; /* 0xA4 Intent To Secure */
- u8 reserved4[0x08];
- u32 fsl_uid;/* 0xB0 FSL Unique ID */
- u8 reserved5[0x04];
- u32 fsl_spfr0; /* Scratch Pad Fuse Register 0 */
- u32 fsl_spfr1; /* Scratch Pad Fuse Register 1 */
-};
-#endif
#ifdef CONFIG_FSL_CORENET
#define CONFIG_SYS_FSL_CORENET_CCM_OFFSET 0x
diff --git a/include/fsl_sfp.h b/include/fsl_sfp.h
new file mode 100644
index 000..353a123
--- /dev/null
+++ b/include/fsl_sfp.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _FSL_SFP_SNVS_
+#define _FSL_SFP_SNVS_
+
+#include
+#include
+#include
+
+#ifdef CONFIG_SYS_FSL_SRK_LE
+#define srk_in32(a) in_le32(a)
+#else
+#define srk_in32(a) in_be32(a)
+#endif
+
+#ifdef CONFIG_SYS_FSL_SFP_LE
+#define sfp_in32(a) in_le32(a)
+#define sfp_out32(a, v) out_le32(a, v)
+#define sfp_in16(a) in_le16(a)
+#elif defined(CONFIG_SYS_FSL_SFP_BE)
+#define sfp_in32(a) in_be32(a)
+#define sfp_out32(a, v) out_be32(a, v)
+#define sfp_in16(a) in_be16(a)
+#else
+#error Neither CONFIG_SYS_FSL_SFP_LE nor CONFIG_SYS_FSL_SFP_BE is defined
+#endif
+
+/* Number of SRKH registers */
+#define NUM_SRKH_REGS 8
+
+#ifdef CONFIG_SYS_FSL_SFP_VER_3_2
+struct ccsr_sfp_regs {
+ u32 ospr; /* 0x200 */
+ u32 ospr1; /* 0x204 */
+ u32 reserved1[4];
+ u32 fswpr; /* 0x218 FSL Section Write Protect */
+ u32 fsl_uid;/* 0x21c FSL UID 0 */
+ u32 fsl_uid_1; /* 0x220 FSL UID 0 */
+ u32 reserved2[12];
+ u32 srk_hash[8];/* 0x254 Super Root Key Hash */
+ u32 oem_uid;/* 0x274 OEM UID 0*/
+ u32 oem_uid_1; /* 0x278 OEM UID 1*/
+ u32 oem_uid_2; /* 0x27c OEM UID 2*/
+ u32 oem_uid_3; /* 0x280 OEM UID 3*/
+ u32 oem_uid_4; /* 0x284 OEM UID 4*/
+ u32 reserved3[8];
+};
+#elif defined(CONFIG_SYS_FSL_SFP_VER_3_0)
+struct ccsr_sfp_regs {
+ u32 ospr; /* 0x200 */
+ u32 reserved0[14];
+ u32 srk_hash[NUM_SRKH_REGS];/* 0x23c Super Root Key Hash */
+ u32 oem_uid;/* 0x9c OEM Unique ID */
+ u8 reserved2[0x04];
+ u32 ovpr; /* 0xA4 Intent To Secure */
+ u8 reserved4[0x08];
+ u32 fsl_uid;/* 0xB0 FSL Unique ID */
+ u8 reserved5[0x04];
+ u32 fsl_spfr0; /* Scratch Pad Fuse Register 0 */
+ u32 fsl_spfr1; /* Scratch Pad Fuse Register 1 */
+
+};
+#else
+struct ccsr_sfp_regs {
+ u8 reserved0[0x40];
+ u32 ospr; /* 0x40 OEM Security Policy Register */
+ u8 reserved2[0x38];
+ u32 srk_hash[8];/* 0x7c Super Root Key Hash */
+ u32 oem_uid;/* 0x9c OEM Unique ID */
+ u8 reserved4[0x4];
+ u32 ovpr; /* 0xA4 OEM Validation Policy Register */
+ u8 reserved8[0x8];
+ u32 fsl_uid;/* 0xB0 FSL Unique ID */
+};
+#endif
+#define ITS_MASK 0x0004
+#de
[U-Boot] [PATCH 2/4][v3] fsl_sec_mon: Add driver for Security Monitor block of Freescale
The Security Monitor is the SOC’s central reporting point for
security-relevant events such as the success or failure of boot
software validation and the detection of potential security compromises.
The API's for transition of Security states have been added
which will be used in case of SECURE BOOT.
Signed-off-by: Ruchika Gupta
Signed-off-by: Gaurav Rana
---
Changes in v3:
Modify copyright in include/fsl_sec_mon.h and drivers/misc/fsl_sec_mon.c.
Changes in v2:
Commit message is changed.
drivers/misc/Kconfig | 8 +++
drivers/misc/Makefile | 1 +
drivers/misc/fsl_sec_mon.c | 146 +
include/fsl_sec_mon.h | 58 ++
4 files changed, 213 insertions(+)
create mode 100644 drivers/misc/fsl_sec_mon.c
create mode 100644 include/fsl_sec_mon.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0df25c3..36a8f0d 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -53,3 +53,11 @@ config DM_CROS_EC
but otherwise makes few changes. Since cros_ec also supports
LPC (which doesn't support driver model yet), a full
conversion is not yet possible.
+
+config CONFIG_FSL_SEC_MON
+ bool "Enable FSL SEC_MON Driver"
+ help
+ Freescale Security Monitor block is responsible for monitoring
+ system states.
+ Security Monitor can be transitioned on any security failures,
+ like software violations or hardware security violations.
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index a34972d..6028cd4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o
obj-$(CONFIG_STATUS_LED) += status_led.o
obj-$(CONFIG_TWL4030_LED) += twl4030_led.o
obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
+obj-$(CONFIG_FSL_SEC_MON) += fsl_sec_mon.o
diff --git a/drivers/misc/fsl_sec_mon.c b/drivers/misc/fsl_sec_mon.c
new file mode 100644
index 000..d482a7d
--- /dev/null
+++ b/drivers/misc/fsl_sec_mon.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+
+int change_sec_mon_state(u32 initial_state, u32 final_state)
+{
+ struct ccsr_sec_mon_regs *sec_mon_regs = (void *)
+ (CONFIG_SYS_SEC_MON_ADDR);
+ u32 sts = sec_mon_in32(&sec_mon_regs->hp_stat);
+ int timeout = 10;
+
+ if ((sts & HPSR_SSM_ST_MASK) != initial_state)
+ return -1;
+
+ if (initial_state == HPSR_SSM_ST_TRUST) {
+ switch (final_state) {
+ case HPSR_SSM_ST_NON_SECURE:
+ printf("SEC_MON state transitioning to Soft Fail.\n");
+ sec_mon_setbits32(&sec_mon_regs->hp_com, HPCOMR_SW_SV);
+
+ /*
+* poll till SEC_MON is in
+* Soft Fail state
+*/
+ while (((sts & HPSR_SSM_ST_MASK) !=
+ HPSR_SSM_ST_SOFT_FAIL)) {
+ while (timeout) {
+ sts = sec_mon_in32
+ (&sec_mon_regs->hp_stat);
+
+ if ((sts & HPSR_SSM_ST_MASK) ==
+ HPSR_SSM_ST_SOFT_FAIL)
+ break;
+
+ udelay(10);
+ timeout--;
+ }
+ }
+
+ if (timeout == 0) {
+ printf("SEC_MON state transition timeout.\n");
+ return -1;
+ }
+
+ timeout = 10;
+
+ printf("SEC_MON state transitioning to Non Secure.\n");
+ sec_mon_setbits32(&sec_mon_regs->hp_com, HPCOMR_SSM_ST);
+
+ /*
+* poll till SEC_MON is in
+* Non Secure state
+*/
+ while (((sts & HPSR_SSM_ST_MASK) !=
+ HPSR_SSM_ST_NON_SECURE)) {
+ while (timeout) {
+ sts = sec_mon_in32
+ (&sec_mon_regs->hp_stat);
+
+ if ((sts & HPSR_SSM_ST_MASK) ==
+ HPSR_SSM_ST_NON_SECURE)
+ break;
+
+ udelay(10);
+ timeout--;
+ }
+ }
+
+ if (timeout == 0) {
+ printf("SEC_MON state transition timeout.
Re: [U-Boot] "Writing to MMC(%d)... failed"
I think I've been able to narrow down, a bit, where the issue is coming from. "mmc_set_blocklen" led me to "mmc_send_cmd" which showed that there is the "CONFIG_MMC_TRACE" I could use. A notable difference between hardkernel's u-boot and mainline was the "uint flags;" was no longer in the "mmc_cmd" struct. I did see that this removal was noted as being a problem back in 2012: http://lists.denx.de/pipermail/u-boot/2012-September/133409.html The result from "saveenv": Odroid # saveenv Saving Environment to MMC... Writing to MMC(0)... CMD_SEND:16 ARG 0x0200 ret: -19 MMC_RSP_R1,5,6,7 0x I added the "printf" for "ret". ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
.Hi Fabio, On Wed, Feb 25, 2015 at 11:05 PM, Fabio Estevam wrote: > I have just tested top of tree U-boot and my mx53loco board boots fine. That's because CONFIG_HAS_VBAR is set for ARMv7. There may be an issue, though: according to Freescale, the TrustZone security extensions are present on i.MX514/515/516/53x, but not on i.MX512/513. According to ARM, the security extensions seem to always be implemented on Cortex-A8, so it's not clear what Freescale means for i.MX512/513, and if the non-secure VBAR is still available on these. If not, 0x is the boot ROM, and 0x is reserved, just like on i.MX25/27/31/35, so disabling CONFIG_HAS_VBAR for i.MX512/513 would not help, and your vector relocation patch would be required here too. It would be nice if someone could test the latest U-Boot on i.MX512/513. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] mx6sabre: Select CMD_EXT4 options
On Thu, Feb 26, 2015 at 4:58 PM, Fabio Estevam wrote: > Add EXT4 support. > > Signed-off-by: Fabio Estevam Acked-by: Otavio Salvador And sorry for not notice the mistake in the commit log. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BDI3000 U-Boot debugging questions (MX51/MX53)
I would like to debug from the earliest possible point pre-relocation (for educational reasons). Couple questions In the Makefile, where do I place the following flags... -Os #-fomit-frame-pointer -g -fno-schedule-insns -fno-schedule-insns2 I've added the flags in a few different spots, but I still can't break on cpu_init_f. Here's the output... (gdb) b cpu_init_f Function "cpu_init_f" not defined. Make breakpoint pending on future shared library load? (y or [n]) y I assume the flags didn't get set, specifically -g. To backup a little here is what I get when I do target remote... (gdb) target remote 169.254.21.13:2001 Remote debugging using 169.254.21.13:2001 warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. 0x in ?? () (gdb) I assume those warning are related to my issue above? Also, when I power on the target, u-boot just starts loading. How do I halt it? I tried to set a breakpoint at text base in the BDI, but it doesn't halt. -- View this message in context: http://u-boot.10912.n7.nabble.com/BDI3000-U-Boot-debugging-questions-MX51-MX53-tp206985.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] added defconfig for Jesurun Q5
On Thu, 26 Feb 2015 12:08:15 +0100 Gábor Nyers wrote: > The Jesurun Q5 has a black plastic casing with the approximate dimensions of > 100mm x 100mm x 24mm with rounded edges. In terms of hardware it features an > Allwinner A10 SoC with 1GB RAM and 8GB of NAND flash. The storage capacity can > be extended up to 32GB with a MicroSD card. The external connectors are: 2x > USB-A female supporting USB2.0, 3.5mm female jack for audio, HDMI female, > SPDIF, RJ45 LAN and Power. In addition the device has 1x red LED (hard wired > to > power) and an programmable green led. On the board there is also an > unpopulated > IR receiver and the UART. The devices is equipped with an AXP209 PMU. > > For more details see: http://linux-sunxi.org/Jesurun_Q5 > > Signed-off-by: Gábor Nyers > --- > configs/jesurun_q5_defconfig | 9 + > 1 file changed, 9 insertions(+) > create mode 100644 configs/jesurun_q5_defconfig > > diff --git a/configs/jesurun_q5_defconfig b/configs/jesurun_q5_defconfig > new file mode 100644 > index 000..7ef35f2 > --- /dev/null > +++ b/configs/jesurun_q5_defconfig > @@ -0,0 +1,9 @@ > +CONFIG_SPL=y > +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_EMAC,USB_EHCI,MACPWR=SUNXI_GPH(19)" > +CONFIG_FDTFILE="sun4i-a10-jesurun-q5.dtb" > ++S:CONFIG_ARM=y > ++S:CONFIG_ARCH_SUNXI=y > ++S:CONFIG_MACH_SUN4I=y > ++S:CONFIG_DRAM_CLK=312 > ++S:CONFIG_DRAM_ZQ=123 > ++S:CONFIG_DRAM_EMR1=0 This patch is missing the "sunxi:" prefix in the summary line and also an entry in the "board/sunxi/MAINTAINERS" file. Additionally, it may be a good idea to have a reference to the http://linux-sunxi.org/Jesurun_Q5 page as a comment in the defconfig file. And eventually do the same for all sunxi defconfigs. Right now the u-boot "configs" directory is a growing pile of unsorted stuff. And it may be difficult for a user to decide, which defconfig would be the right one for his device (considering that some devices are not perfectly labelled with exactly the same name as the defconfig file). -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] mx6sabre: Select CMD_EXT4 options
Add EXT4 support. Signed-off-by: Fabio Estevam --- Changes since v2: - Fix subject and commit log to only mention ext4 Changes since v1: - Newly introduced in this series include/configs/mx6sabre_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index 337b865..67d74d0 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -56,6 +56,8 @@ #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER #define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_EXT4_WRITE #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] mx6sabre: Enable User Mass Storage
User Mass Storage is very useful for flashing the on-board eMMC. Add support for it. Signed-off-by: Fabio Estevam Acked-by: Otavio Salvador --- Changes since v2: - None Changes since v1: - Remove EXT2/EXT4 and BOUNCE_BUFFER support include/configs/mx6sabre_common.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index f0f721e..337b865 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -279,4 +279,18 @@ #define CONFIG_IMX_HDMI #define CONFIG_IMX_VIDEO_SKIP +#define CONFIG_CI_UDC +#define CONFIG_USBD_HS +#define CONFIG_USB_GADGET_DUALSPEED + +#define CONFIG_USB_GADGET +#define CONFIG_CMD_USB_MASS_STORAGE +#define CONFIG_USB_GADGET_MASS_STORAGE +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_USB_GADGET_VBUS_DRAW2 + +#define CONFIG_G_DNL_VENDOR_NUM0x0525 +#define CONFIG_G_DNL_PRODUCT_NUM 0xa4a5 +#define CONFIG_G_DNL_MANUFACTURER "FSL" + #endif /* __MX6QSABRE_COMMON_CONFIG_H */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mx6sabre: Select BOUNCE_BUFFER and CMD_EXT options
Hi Fabio, On 02/26/2015 06:50 PM, Fabio Estevam wrote: Add EXT2/EXT4 and BOUNCE_BUFFER support. Signed-off-by: Fabio Estevam --- Changes since v1: - Newly introduced in this series include/configs/mx6sabre_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index 337b865..67d74d0 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -56,6 +56,8 @@ #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER #define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_EXT4_WRITE #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION I don't see the BOUNCE_BUFFER config option changed, and also no change related to EXT2. Kind regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS UHI spec
Hi, On Thu, Feb 26, 2015 at 4:37 AM, Daniel Schwierzeck wrote: > 2015-02-26 11:17 GMT+01:00 Paul Burton : >> On Thu, Feb 19, 2015 at 01:50:23PM +, Matthew Fortune wrote: >>> Hi Daniel, >>> >>> The spec for MIPS Unified Hosting Interface is available here: >>> >>> http://prplfoundation.org/wiki/MIPS_documentation >>> >>> As we have previously discussed, this is an ideal place to >>> define the handover of device tree data from bootloader to >>> kernel. Using a0 == -2 and defining which register(s) you >>> need for the actual data will fit nicely. I'll happily >>> include whatever is decided into the next version of the spec. > > this originates from an off-list discussion some months ago started by > John Crispin. > > (CC +John, Ralf, Jonas, linux-mips) > >> >> (CC +Andrew, Ezequiel, James, James) >> >> On the talk of DT handover, this recent patchset adding support for a >> system doing so to Linux is relevant: >> >> http://www.linux-mips.org/archives/linux-mips/2015-02/msg00312.html >> >> I'm also working on a system for which I'll need to implement DT >> handover very soon. It would be very nice if we could agree on some >> standard way of doing so (and eventually if the code on the Linux side >> can be generic enough to allow a multiplatform kernel). +1. I would like to see this happen as well. > to be conformant with UHI I propose $a0 == -2 and $a1 == address of DT > blob. It is a simple extension and should not interfere with the > various legacy boot interfaces. > > U-Boot mainline code is almost ready for DT handover. I have prepared > a patch [1] which completes it by implementing my proposal. Hmm... we decided to follow the ARM convention here ($a0 = 0, $a1 = -1, $a2 = physical address of DTB), which is also what the BMIPS platform (submitted by Kevin) is using for DT handover. Is there already a platform using the protocol you described? It's still early enough that we could change the DT handover for Pistachio, but it would be good to agree on something soon. Thanks, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mx6sabre: Enable User Mass Storage
On Thu, Feb 26, 2015 at 1:50 PM, Fabio Estevam wrote: > User Mass Storage is very useful for flashing the on-board eMMC. > > Add support for it. > > Signed-off-by: Fabio Estevam Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mx6sabre: Select BOUNCE_BUFFER and CMD_EXT options
On Thu, Feb 26, 2015 at 1:50 PM, Fabio Estevam wrote: > Add EXT2/EXT4 and BOUNCE_BUFFER support. > > Signed-off-by: Fabio Estevam Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: tbs2910: Enable USB Mass Storage support
Add USB Mass Storage support. This is useful for flashing the on-board eMMC. Signed-off-by: Soeren Moch --- Cc: Stefano Babic --- include/configs/tbs2910.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/configs/tbs2910.h b/include/configs/tbs2910.h index c097b98..7089378 100644 --- a/include/configs/tbs2910.h +++ b/include/configs/tbs2910.h @@ -165,6 +165,19 @@ #define CONFIG_USB_MAX_CONTROLLER_COUNT 2 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) #define CONFIG_USB_STORAGE +#define CONFIG_CMD_USB_MASS_STORAGE +#ifdef CONFIG_CMD_USB_MASS_STORAGE +#define CONFIG_CI_UDC +#define CONFIG_USBD_HS +#define CONFIG_USB_GADGET +#define CONFIG_USB_GADGET_MASS_STORAGE +#define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_VBUS_DRAW0 +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_G_DNL_VENDOR_NUM0x0525 +#define CONFIG_G_DNL_PRODUCT_NUM 0xa4a5 +#define CONFIG_G_DNL_MANUFACTURER "TBS" +#endif /* CONFIG_CMD_USB_MASS_STORAGE */ #define CONFIG_USB_KEYBOARD #ifdef CONFIG_USB_KEYBOARD #define CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/T104xD4RDB: Add T1040/T1042D4RDB boards support
On 02/03/2015 06:00 AM, Vijay Rai wrote: > T1040D4RDB is a Freescale reference board that hosts the T1040 SoC. > It is similar to T1040RDB board with the following differences : > - Has DDR4 memory > - PHY ports have different PHY addresses > - RTC support > - Both QE-TDM and DIU connector > > T1040D4RDB supports 0x66 serdes protocol with following interfaces > - 2 RGMII's on DTSEC4, DTSEC5 > - 1 SGMII on DTSEC3 > > T1042D4RDB is variant of T1040D4RDB which hosts T1042 SoC > (Personality of T1040 without L2 switch) > T1042D4RDB supports 0x86 serdes protocol with following interfaces > - 2 RGMII's on DTSEC4, DTSEC5 > - 3 SGMII on DTSEC1, DTSEC2 & DTSEC3 > > Signed-off-by: Vijay Rai > Signed-off-by: Priyanka Jain > --- > board/freescale/t104xrdb/MAINTAINERS |8 ++ > board/freescale/t104xrdb/ddr.c |7 + > board/freescale/t104xrdb/ddr.h | 12 > board/freescale/t104xrdb/eth.c | 20 +++-- > board/freescale/t104xrdb/t1040d4_rcw.cfg |7 + > board/freescale/t104xrdb/t1042d4_rcw.cfg |7 + > configs/T1040D4RDB_NAND_defconfig|5 > configs/T1040D4RDB_SDCARD_defconfig |5 > configs/T1040D4RDB_SPIFLASH_defconfig|5 > configs/T1040D4RDB_defconfig |4 +++ > configs/T1042D4RDB_NAND_defconfig|5 > configs/T1042D4RDB_SDCARD_defconfig |5 > configs/T1042D4RDB_SPIFLASH_defconfig|5 > configs/T1042D4RDB_defconfig |4 +++ > include/configs/T104xRDB.h | 46 > -- > 15 files changed, 134 insertions(+), 11 deletions(-) > create mode 100644 board/freescale/t104xrdb/t1040d4_rcw.cfg > create mode 100644 board/freescale/t104xrdb/t1042d4_rcw.cfg > create mode 100644 configs/T1040D4RDB_NAND_defconfig > create mode 100644 configs/T1040D4RDB_SDCARD_defconfig > create mode 100644 configs/T1040D4RDB_SPIFLASH_defconfig > create mode 100644 configs/T1040D4RDB_defconfig > create mode 100644 configs/T1042D4RDB_NAND_defconfig > create mode 100644 configs/T1042D4RDB_SDCARD_defconfig > create mode 100644 configs/T1042D4RDB_SPIFLASH_defconfig > create mode 100644 configs/T1042D4RDB_defconfig > > diff --git a/board/freescale/t104xrdb/MAINTAINERS > b/board/freescale/t104xrdb/MAINTAINERS > index 13d9be9..32e044f 100644 > --- a/board/freescale/t104xrdb/MAINTAINERS > +++ b/board/freescale/t104xrdb/MAINTAINERS > @@ -6,7 +6,13 @@ F: include/configs/T104xRDB.h > F: configs/T1040RDB_defconfig > F: configs/T1040RDB_NAND_defconfig > F: configs/T1040RDB_SPIFLASH_defconfig > +F: configs/T1040D4RDB_defconfig > +F: configs/T1040D4RDB_NAND_defconfig > +F: configs/T1040D4RDB_SPIFLASH_defconfig > F: configs/T1042RDB_defconfig > +F: configs/T1042D4RDB_defconfig > +F: configs/T1042D4RDB_NAND_defconfig > +F: configs/T1042D4RDB_SPIFLASH_defconfig > F: configs/T1042RDB_PI_defconfig > F: configs/T1042RDB_PI_NAND_defconfig > F: configs/T1042RDB_PI_SPIFLASH_defconfig > @@ -15,6 +21,8 @@ T1040RDB_SDCARD BOARD > #M: - > S: Maintained > F: configs/T1040RDB_SDCARD_defconfig > +F: configs/T1040D4RDB_SDCARD_defconfig > +F: configs/T1042D4RDB_SDCARD_defconfig > F: configs/T1042RDB_PI_SDCARD_defconfig > > T1040RDB_SECURE_BOOT BOARD > diff --git a/board/freescale/t104xrdb/ddr.c b/board/freescale/t104xrdb/ddr.c > index e1148e5..217c8ea 100644 > --- a/board/freescale/t104xrdb/ddr.c > +++ b/board/freescale/t104xrdb/ddr.c > @@ -91,9 +91,16 @@ found: > popts->zq_en = 1; > > /* DHC_EN =1, ODT = 75 Ohm */ > +#ifdef CONFIG_SYS_FSL_DDR4 > + popts->ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_80ohm); > + popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_80ohm) | > + DDR_CDR2_VREF_OVRD(70); /* Vref = 70% */ > +#else > popts->ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_75ohm); > popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_75ohm); > +#endif > } > +#endif > > #if defined(CONFIG_DEEP_SLEEP) > void board_mem_sleep_setup(void) You added extra #endif. Did you miss something? Please check your local code and make sure it compiles when sending patches. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: move -march=* and -mtune= options to arch/arm/Makefile
Hi Albert, 2015-02-26 6:14 GMT+09:00 Albert ARIBAUD : > > I'm fine with the patch's goal and principle, but it does not seem to > apply properly to u-boot-arm/master. Can you have a look? Sure. I've just posted v2: http://patchwork.ozlabs.org/patch/444028/ It should apply cleanly to u-boot-arm. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: move -march=* and -mtune= options to arch/arm/Makefile
My main motivations for this commit are: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada Acked-by: Marek Vasut Acked-by: Stefan Roese --- Changes in v2: - Rebased onto u-boot-arm/master (commit 419fa9ae) arch/arm/Makefile| 32 arch/arm/cpu/arm1136/config.mk | 9 - arch/arm/cpu/arm1176/config.mk | 9 - arch/arm/cpu/arm720t/config.mk | 9 - arch/arm/cpu/arm920t/config.mk | 8 arch/arm/cpu/arm926ejs/config.mk | 8 arch/arm/cpu/arm946es/config.mk | 8 arch/arm/cpu/armv7/config.mk | 5 - arch/arm/cpu/armv8/config.mk | 2 -- arch/arm/cpu/pxa/config.mk | 2 -- arch/arm/cpu/sa1100/config.mk| 9 - 11 files changed, 32 insertions(+), 69 deletions(-) delete mode 100644 arch/arm/cpu/arm1136/config.mk delete mode 100644 arch/arm/cpu/arm1176/config.mk delete mode 100644 arch/arm/cpu/arm720t/config.mk delete mode 100644 arch/arm/cpu/arm920t/config.mk delete mode 100644 arch/arm/cpu/arm926ejs/config.mk delete mode 100644 arch/arm/cpu/arm946es/config.mk delete mode 100644 arch/arm/cpu/sa1100/config.mk diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 878ae26..275c817 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -2,6 +2,38 @@ # SPDX-License-Identifier: GPL-2.0+ # +# This selects which instruction set is used. +arch-$(CONFIG_CPU_ARM720T) =-march=armv4 +arch-$(CONFIG_CPU_ARM920T) =-march=armv4 +arch-$(CONFIG_CPU_ARM926EJS) =-march=armv5te +arch-$(CONFIG_CPU_ARM946ES)=-march=armv4 +arch-$(CONFIG_CPU_SA1100) =-march=armv4 +arch-$(CONFIG_CPU_PXA) = +arch-$(CONFIG_CPU_ARM1136) =-march=armv5 +arch-$(CONFIG_CPU_ARM1176) =-march=armv5t +arch-$(CONFIG_CPU_V7) =$(call cc-option, -march=armv7-a, -march=armv5) +arch-$(CONFIG_ARM64) =-march=armv8-a + +# Evaluate arch cc-option calls now +arch-y := $(arch-y) + +# This selects how we optimise for the processor. +tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7tdmi +tune-$(CONFIG_CPU_ARM920T) = +tune-$(CONFIG_CPU_ARM926EJS) = +tune-$(CONFIG_CPU_ARM946ES)= +tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100 +tune-$(CONFIG_CPU_PXA) =-mcpu=xscale +tune-$(CONFIG_CPU_ARM1136) = +tune-$(CONFIG_CPU_ARM1176) = +tune-$(CONFIG_CPU_V7) = +tune-$(CONFIG_ARM64) = + +# Evaluate tune cc-option calls now +tune-y := $(tune-y) + +PLATFORM_CPPFLAGS += $(arch-y) $(tune-y) + # Machine directory name. This list is sorted alphanumerically # by CONFIG_* macro name. machine-$(CONFIG_ARCH_AT91)+= at91 diff --git a/arch/arm/cpu/arm1136/config.mk b/arch/arm/cpu/arm1136/config.mk deleted file mode 100644 index a82c6ce..000 --- a/arch/arm/cpu/arm1136/config.mk +++ /dev/null @@ -1,9 +0,0 @@ -# -# (C) Copyright 2002 -# Gary Jennejohn, DENX Software Engineering, -# -# SPDX-License-Identifier: GPL-2.0+ -# - -# Make ARMv5 to allow more compilers to work, even though its v6. -PLATFORM_CPPFLAGS += -march=armv5 diff --git a/arch/arm/cpu/arm1176/config.mk b/arch/arm/cpu/arm1176/config.mk deleted file mode 100644 index 5dc2ebb..000 --- a/arch/arm/cpu/arm1176/config.mk +++ /dev/null @@ -1,9 +0,0 @@ -# -# (C) Copyright 2002 -# Gary Jennejohn, DENX Software Engineering, -# -# SPDX-License-Identifier: GPL-2.0+ -# - -# Make ARMv5 to allow more compilers to work, even though its v6. -PLATFORM_CPPFLAGS += -march=armv5t diff --git a/arch/arm/cpu/arm720t/config.mk b/arch/arm/cpu/arm720t/config.mk deleted file mode 100644 index 772fb41..000 --- a/arch/arm/cpu/arm720t/config.mk +++ /dev/null @@ -1,9 +0,0 @@ -# -# (C) Copyright 2002 -# Sysgo Real-Time Solutions, GmbH -# Marius Groeger -# -# SPDX-License-Identifier: GPL-2.0+ -# - -PLATFORM_CPPFLAGS += -march=armv4 -mtune=arm7tdmi diff --git a/arch/arm/cpu/arm920t/config.mk b/arch/arm/cpu/arm920t/config.mk deleted file mode 100644 index 799afff..000 --- a/arch/arm/cpu/arm920t/config.mk +++ /dev/null @@ -1,8 +0,0 @@ -# -# (C) Copyright 2002 -# Gary Jennejohn, DENX Software Engineering, -# -# SPDX-License-Identifier: GPL-2.0+ -# - -PLATFORM_CPPFLAGS += -march=armv4 diff --git a/arch/arm/cpu/arm926ejs/config.mk b/arch/arm/
[U-Boot] [PATCH v5 17/26] ARM: UniPhier: enable xHCI and GIO cores for PH1-Pro4
This is necessary to use the USB 3.0 host controllers on PH1-Pro4. Signed-off-by: Masahiro Yamada --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/mach-uniphier/include/mach/sc-regs.h | 11 ++- arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c | 15 +++ 2 files changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-uniphier/include/mach/sc-regs.h b/arch/arm/mach-uniphier/include/mach/sc-regs.h index f0467bb..caec6c2 100644 --- a/arch/arm/mach-uniphier/include/mach/sc-regs.h +++ b/arch/arm/mach-uniphier/include/mach/sc-regs.h @@ -1,7 +1,7 @@ /* * UniPhier SC (System Control) block registers * - * Copyright (C) 2011-2014 Panasonic Corporation + * Copyright (C) 2011-2015 Panasonic Corporation * * SPDX-License-Identifier:GPL-2.0+ */ @@ -38,19 +38,28 @@ #define SC_VPLL27BCTRL3(SC_BASE_ADDR | 0x1298) #define SC_RSTCTRL (SC_BASE_ADDR | 0x2000) +#define SC_RSTCTRL_NRST_USB3B0 (0x1 << 17) /* USB3 #0 bus */ +#define SC_RSTCTRL_NRST_USB3C0 (0x1 << 16) /* USB3 #0 core */ #define SC_RSTCTRL_NRST_ETHER (0x1 << 12) #define SC_RSTCTRL_NRST_STDMAC (0x1 << 10) +#define SC_RSTCTRL_NRST_GIO(0x1 << 6) #define SC_RSTCTRL_NRST_UMC1 (0x1 << 5) #define SC_RSTCTRL_NRST_UMC0 (0x1 << 4) #define SC_RSTCTRL_NRST_NAND (0x1 << 2) #define SC_RSTCTRL2(SC_BASE_ADDR | 0x2004) +#define SC_RSTCTRL2_NRST_USB3B1(0x1 << 17) /* USB3 #1 bus */ +#define SC_RSTCTRL2_NRST_USB3C1(0x1 << 16) /* USB3 #1 core */ + #define SC_RSTCTRL3(SC_BASE_ADDR | 0x2008) #define SC_CLKCTRL (SC_BASE_ADDR | 0x2104) +#define SC_CLKCTRL_CEN_USB31 (0x1 << 17) /* USB3 #1 */ +#define SC_CLKCTRL_CEN_USB30 (0x1 << 16) /* USB3 #0 */ #define SC_CLKCTRL_CEN_ETHER (0x1 << 12) #define SC_CLKCTRL_CEN_MIO (0x1 << 11) #define SC_CLKCTRL_CEN_STDMAC (0x1 << 10) +#define SC_CLKCTRL_CEN_GIO (0x1 << 6) #define SC_CLKCTRL_CEN_UMC (0x1 << 4) #define SC_CLKCTRL_CEN_NAND(0x1 << 2) #define SC_CLKCTRL_CEN_SBC (0x1 << 1) diff --git a/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c b/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c index 4ac5411..054efa6 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c @@ -14,6 +14,10 @@ void clkrst_init(void) /* deassert reset */ tmp = readl(SC_RSTCTRL); +#ifdef CONFIG_USB_XHCI_UNIPHIER + tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_USB3C0 | + SC_RSTCTRL_NRST_GIO; +#endif #ifdef CONFIG_UNIPHIER_ETH tmp |= SC_RSTCTRL_NRST_ETHER; #endif @@ -26,8 +30,19 @@ void clkrst_init(void) writel(tmp, SC_RSTCTRL); readl(SC_RSTCTRL); /* dummy read */ +#ifdef CONFIG_USB_XHCI_UNIPHIER + tmp = readl(SC_RSTCTRL2); + tmp |= SC_RSTCTRL2_NRST_USB3B1 | SC_RSTCTRL2_NRST_USB3C1; + writel(tmp, SC_RSTCTRL2); + readl(SC_RSTCTRL2); /* dummy read */ +#endif + /* privide clocks */ tmp = readl(SC_CLKCTRL); +#ifdef CONFIG_USB_XHCI_UNIPHIER + tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 | + SC_CLKCTRL_CEN_GIO; +#endif #ifdef CONFIG_UNIPHIER_ETH tmp |= SC_CLKCTRL_CEN_ETHER; #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 14/26] ARM: UniPhier: move uniphier_ehci_reset() function
Because uniphier_ehci_reset() is only called from ehci-uniphier.c,
it can be a static function there.
Signed-off-by: Masahiro Yamada
Acked-by: Marek Vasut
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../arm/mach-uniphier/include/mach/ehci-uniphier.h | 27 --
drivers/usb/host/ehci-uniphier.c | 15 +++-
2 files changed, 14 insertions(+), 28 deletions(-)
delete mode 100644 arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
diff --git a/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
b/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
deleted file mode 100644
index 3ba3183..000
--- a/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * Copyright (C) 2014-2015 Panasonic Corporation
- * Author: Masahiro Yamada
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __PLAT_UNIPHIER_EHCI_H
-#define __PLAT_UNIPHIER_EHCI_H
-
-#include
-#include
-#include "mio-regs.h"
-
-static inline void uniphier_ehci_reset(int index, int on)
-{
- u32 tmp;
-
- tmp = readl(MIO_USB_RSTCTRL(index));
- if (on)
- tmp &= ~MIO_USB_RSTCTRL_XRST;
- else
- tmp |= MIO_USB_RSTCTRL_XRST;
- writel(tmp, MIO_USB_RSTCTRL(index));
-}
-
-#endif /* __PLAT_UNIPHIER_EHCI_H */
diff --git a/drivers/usb/host/ehci-uniphier.c b/drivers/usb/host/ehci-uniphier.c
index 68959ef..b5ec296 100644
--- a/drivers/usb/host/ehci-uniphier.c
+++ b/drivers/usb/host/ehci-uniphier.c
@@ -7,8 +7,9 @@
#include
#include
+#include
#include
-#include
+#include
#include
#include "ehci.h"
@@ -35,6 +36,18 @@ static int get_uniphier_ehci_base(int index, struct
ehci_hccr **base)
return -ENODEV; /* not found */
}
+static void uniphier_ehci_reset(int index, int on)
+{
+ u32 tmp;
+
+ tmp = readl(MIO_USB_RSTCTRL(index));
+ if (on)
+ tmp &= ~MIO_USB_RSTCTRL_XRST;
+ else
+ tmp |= MIO_USB_RSTCTRL_XRST;
+ writel(tmp, MIO_USB_RSTCTRL(index));
+}
+
int ehci_hcd_init(int index, enum usb_init_type init, struct ehci_hccr **hccr,
struct ehci_hcor **hcor)
{
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 11/26] ARM: UniPhier: reset NAND core in SPL for non-NAND boot mode
For all the UniPhier SoCs so far, the reset signal of the NAND core is automatically deasserted after the PLL gets stabled. (The bit 2 of SC_RSTCTRL is default to one.) This causes a fatal problem on the NAND controller of PH1-LD4. For that SoC, the NAND I/O pins are not set up yet at the power-on reset except the NAND boot mode. As a result, the NAND controller begins automatic device scanning with wrong I/O pins and finally hangs up. Actually, U-Boot dies after printing "NAND:" on the console unless the boot mode latch detected the NAND boot mode. To work around this problem, reset the NAND core in SPL for non-NAND boot modes. If CONFIG_NAND_DENALI is enabled, the reset signal is deasserted again in U-Boot proper. At this time, I/O pins have been correctly set up, the device scanning should succeed. Signed-off-by: Masahiro Yamada --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: - Added arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c b/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c index ae4185f..37bb79e 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c @@ -5,6 +5,8 @@ * SPDX-License-Identifier:GPL-2.0+ */ +#include +#include #include #include @@ -14,7 +16,10 @@ void early_clkrst_init(void) /* deassert reset */ tmp = readl(SC_RSTCTRL); + tmp |= SC_RSTCTRL_NRST_UMC1 | SC_RSTCTRL_NRST_UMC0; + if (spl_boot_device() != BOOT_DEVICE_NAND) + tmp &= ~SC_RSTCTRL_NRST_NAND; writel(tmp, SC_RSTCTRL); readl(SC_RSTCTRL); /* dummy read */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 10/26] ARM: UniPhier: split clkrst_init() into two functions
Split the current clkrst_init() into two functions:
- early_clkrst_init(): called from SPL
Deassert the reset signals of the memory controller and some other
basic cores.
- clkrst_init(): called from main U-boot
Deassert the reset signals that are necessary for the access to
peripherals etc.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/mach-uniphier/board_early_init_f.c| 5
arch/arm/mach-uniphier/ph1-ld4/Makefile| 4 +--
arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c | 22 +++-
arch/arm/mach-uniphier/ph1-ld4/early_clkrst_init.c | 1 +
arch/arm/mach-uniphier/ph1-pro4/Makefile | 4 +--
arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c | 22 +++-
.../arm/mach-uniphier/ph1-pro4/early_clkrst_init.c | 26 +++
arch/arm/mach-uniphier/ph1-sld8/Makefile | 4 +--
arch/arm/mach-uniphier/ph1-sld8/clkrst_init.c | 30 +-
.../arm/mach-uniphier/ph1-sld8/early_clkrst_init.c | 1 +
arch/arm/mach-uniphier/spl.c | 4 +--
11 files changed, 74 insertions(+), 49 deletions(-)
create mode 100644 arch/arm/mach-uniphier/ph1-ld4/early_clkrst_init.c
create mode 100644 arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c
create mode 100644 arch/arm/mach-uniphier/ph1-sld8/early_clkrst_init.c
diff --git a/arch/arm/mach-uniphier/board_early_init_f.c
b/arch/arm/mach-uniphier/board_early_init_f.c
index bf81345..7108740 100644
--- a/arch/arm/mach-uniphier/board_early_init_f.c
+++ b/arch/arm/mach-uniphier/board_early_init_f.c
@@ -9,6 +9,7 @@
#include
void pin_init(void);
+void clkrst_init(void);
int board_early_init_f(void)
{
@@ -18,5 +19,9 @@ int board_early_init_f(void)
led_write(U, 1, , );
+ clkrst_init();
+
+ led_write(U, 2, , );
+
return 0;
}
diff --git a/arch/arm/mach-uniphier/ph1-ld4/Makefile
b/arch/arm/mach-uniphier/ph1-ld4/Makefile
index 72f4663..927640a 100644
--- a/arch/arm/mach-uniphier/ph1-ld4/Makefile
+++ b/arch/arm/mach-uniphier/ph1-ld4/Makefile
@@ -4,10 +4,10 @@
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_DEBUG_LL) += lowlevel_debug.o
-obj-y += bcu_init.o sbc_init.o sg_init.o pll_init.o clkrst_init.o \
+obj-y += bcu_init.o sbc_init.o sg_init.o pll_init.o early_clkrst_init.o \
pll_spectrum.o umc_init.o ddrphy_init.o
else
-obj-$(CONFIG_BOARD_EARLY_INIT_F) += pinctrl.o
+obj-$(CONFIG_BOARD_EARLY_INIT_F) += pinctrl.o clkrst_init.o
obj-$(if $(CONFIG_OF_CONTROL),,y) += platdevice.o
endif
diff --git a/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c
b/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c
index eaa45f9..f5fc418 100644
--- a/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c
+++ b/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c
@@ -1,11 +1,10 @@
/*
- * Copyright (C) 2011-2014 Panasonic Corporation
+ * Copyright (C) 2011-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
*/
-#include
#include
#include
@@ -15,15 +14,26 @@ void clkrst_init(void)
/* deassert reset */
tmp = readl(SC_RSTCTRL);
- tmp |= SC_RSTCTRL_NRST_ETHER | SC_RSTCTRL_NRST_UMC1
- | SC_RSTCTRL_NRST_UMC0 | SC_RSTCTRL_NRST_NAND;
+#ifdef CONFIG_UNIPHIER_ETH
+ tmp |= SC_RSTCTRL_NRST_ETHER;
+#endif
+#ifdef CONFIG_NAND_DENALI
+ tmp |= SC_RSTCTRL_NRST_NAND;
+#endif
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
/* privide clocks */
tmp = readl(SC_CLKCTRL);
- tmp |= SC_CLKCTRL_CEN_ETHER | SC_CLKCTRL_CEN_MIO | SC_CLKCTRL_CEN_UMC
-| SC_CLKCTRL_CEN_NAND | SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI;
+#ifdef CONFIG_UNIPHIER_ETH
+ tmp |= SC_CLKCTRL_CEN_ETHER;
+#endif
+#ifdef CONFIG_USB_EHCI_UNIPHIER
+ tmp |= SC_CLKCTRL_CEN_MIO;
+#endif
+#ifdef CONFIG_NAND_DENALI
+ tmp |= SC_CLKCTRL_CEN_NAND;
+#endif
writel(tmp, SC_CLKCTRL);
readl(SC_CLKCTRL); /* dummy read */
}
diff --git a/arch/arm/mach-uniphier/ph1-ld4/early_clkrst_init.c
b/arch/arm/mach-uniphier/ph1-ld4/early_clkrst_init.c
new file mode 100644
index 000..d7ef16b
--- /dev/null
+++ b/arch/arm/mach-uniphier/ph1-ld4/early_clkrst_init.c
@@ -0,0 +1 @@
+#include "../ph1-pro4/early_clkrst_init.c"
diff --git a/arch/arm/mach-uniphier/ph1-pro4/Makefile
b/arch/arm/mach-uniphier/ph1-pro4/Makefile
index e330fda..0390506 100644
--- a/arch/arm/mach-uniphier/ph1-pro4/Makefile
+++ b/arch/arm/mach-uniphier/ph1-pro4/Makefile
@@ -4,10 +4,10 @@
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_DEBUG_LL) += lowlevel_debug.o
-obj-y += sbc_init.o sg_init.o pll_init.o clkrst_init.o \
+obj-y += sbc_init.o sg_init.o pll_init.o early_clkrst_init.o \
pll_spectrum.o umc_init.o ddrphy_init.o
else
-obj-$(CONFIG_BOARD_EARLY_INIT_F) += pinctrl.o
+obj-$(CONFIG_BOARD_EARLY_INIT_F) += pinctrl.o clkrst_init.o
obj-$(if $(CONFIG_OF_CONTROL),,y) += platdevice.o
endif
diff -
[U-Boot] [PATCH v5 4/5] arm: spl: Allow board_init_r() to run with a larger stack
At present SPL uses a single stack, either CONFIG_SPL_STACK or CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and environment) require a lot of stack, some boards set CONFIG_SPL_STACK to point into SDRAM. They then set up SDRAM very early, before board_init_f(), so that the larger stack can be used. This is an abuse of lowlevel_init(). That function should only be used for essential start-up code which cannot be delayed. An example of a valid use is when only part of the SPL code is visible/executable, and the SoC must be set up so that board_init_f() can be reached. It should not be used for SDRAM init, console init, etc. Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new address before board_init_r() is called in SPL. The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README. Signed-off-by: Simon Glass For version 1: Acked-by: Albert ARIBAUD Reviewed-by: Stefan Roese Tested-by: Bo Shen Acked-by: Bo Shen Acked-by: Heiko Schocher Tested-by: Heiko Schocher --- Changes in v5: - Rebase to master Changes in v4: - Adjust README to mention that lowlevel_init() should have no stack Changes in v3: None Changes in v2: - Move docs to top-level README file and expand them to cover U-Boot proper - Add Kconfig settings Kconfig | 18 ++ README | 69 + arch/arm/lib/crt0.S | 13 +++--- common/spl/spl.c| 35 +++ 4 files changed, 132 insertions(+), 3 deletions(-) diff --git a/Kconfig b/Kconfig index 91a0618..8de731d 100644 --- a/Kconfig +++ b/Kconfig @@ -96,6 +96,24 @@ config SPL help If you want to build SPL as well as the normal image, say Y. +config CONFIG_SPL_STACK_R + depends on SPL + bool "Enable SDRAM location for SPL stack" + help + SPL starts off execution in SRAM and thus typically has only a small + stack available. Since SPL sets up DRAM while in its board_init_f() + function, it is possible for the stack to move there before + board_init_r() is reached. This option enables a special SDRAM + location for the SPL stack. U-Boot SPL switches to this after + board_init_f() completes, and before board_init_r() starts. + +config CONFIG_SPL_STACK_R_ADDR + depends on CONFIG_SPL_STACK_R + hex "SDRAM location for SPL stack" + help + Specify the address in SDRAM for the SPL stack. This will be set up + before board_init_r() is called. + config TPL bool depends on SPL && SUPPORT_TPL diff --git a/README b/README index febefb5..3547ead 100644 --- a/README +++ b/README @@ -273,6 +273,75 @@ run some of U-Boot's tests. See board/sandbox/README.sandbox for more details. +Board Initialisation Flow: +-- + +This is the intended start-up flow for boards. This should apply for both +SPL and U-Boot proper (i.e. they both follow the same rules). At present SPL +mostly uses a separate code path, but the funtion names and roles of each +function are the same. Some boards or architectures may not conform to this. +At least most ARM boards which use CONFIG_SPL_FRAMEWORK conform to this. + +Execution starts with start.S with three functions called during init after +that. The purpose and limitations of each is described below. + +lowlevel_init(): + - purpose: essential init to permit execution to reach board_init_f() + - no global_data or BSS + - there is no stack (ARMv7 may have one but it will soon be removed) + - must not set up SDRAM or use console + - must only do the bare minimum to allow execution to continue to + board_init_f() + - this is almost never needed + - return normally from this function + +board_init_f(): + - purpose: set up the machine ready for running board_init_r(): + i.e. SDRAM and serial UART + - global_data is available + - stack is in SRAM + - BSS is not available, so you cannot use global/static variables, + only stack variables and global_data + + Non-SPL-specific notes: + - dram_init() is called to set up DRAM. If already done in SPL this + can do nothing + + SPL-specific notes: + - you can override the entire board_init_f() function with your own + version as needed. + - preloader_console_init() can be called here in extremis + - should set up SDRAM, and anything needed to make the UART work + - these is no need to clear BSS, it will be done by crt0.S + - must return normally from this function (don't call board_init_r() + directly) + +Here the BSS is cleared. For SPL, if CONFIG_SPL_STACK_R is defined, then at +this point the stack and global_data are relocated to below +CONFIG_SPL_STACK_R_ADDR. For non-SPL, U-Boot is relocated to run at the top of +memory. +
[U-Boot] [PATCH v5 22/26] ARM: UniPhier: switch to 1CS support card
The 3CS support card (CONFIG_DCC_MICRO_SUPPORT_CARD) used to be used very often before, but it is recently getting a minority. Swith to the 1CS support card (CONFIG_PFC_MICRO_SUPPORT_CARD). Signed-off-by: Masahiro Yamada --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: - Added configs/ph1_ld4_defconfig | 2 +- configs/ph1_pro4_defconfig | 2 +- configs/ph1_sld8_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig index edfdafa..292f2ca 100644 --- a/configs/ph1_ld4_defconfig +++ b/configs/ph1_ld4_defconfig @@ -4,7 +4,7 @@ CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DM_I2C=y CONFIG_MACH_PH1_LD4=y -CONFIG_DCC_MICRO_SUPPORT_CARD=y +CONFIG_PFC_MICRO_SUPPORT_CARD=y CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref" CONFIG_FIT=y CONFIG_FIT_VERBOSE=y diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig index ace5fc5..2021862 100644 --- a/configs/ph1_pro4_defconfig +++ b/configs/ph1_pro4_defconfig @@ -4,7 +4,7 @@ CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DM_I2C=y CONFIG_MACH_PH1_PRO4=y -CONFIG_DCC_MICRO_SUPPORT_CARD=y +CONFIG_PFC_MICRO_SUPPORT_CARD=y CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref" CONFIG_FIT=y CONFIG_FIT_VERBOSE=y diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig index 0d437c6..cf229ae 100644 --- a/configs/ph1_sld8_defconfig +++ b/configs/ph1_sld8_defconfig @@ -4,7 +4,7 @@ CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DM_I2C=y CONFIG_MACH_PH1_SLD8=y -CONFIG_DCC_MICRO_SUPPORT_CARD=y +CONFIG_PFC_MICRO_SUPPORT_CARD=y CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref" CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 20/26] ARM: UniPhier: switch to xHCI for PH1-Pro4
PH1-Pro4 includes both EHCI and xHCI IP cores. Unfortunately, U-Boot cannot enable EHCI and xHCI support simultaneously. Some users may wish Super-Speed connection. Disable CONFIG_USB_EHCI_HCD and enable CONFIG_USB_XHCI_HCD. Signed-off-by: Masahiro Yamada --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None configs/ph1_pro4_defconfig | 2 +- include/configs/uniphier.h | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig index f1fb7b7..ace5fc5 100644 --- a/configs/ph1_pro4_defconfig +++ b/configs/ph1_pro4_defconfig @@ -38,5 +38,5 @@ CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 CONFIG_SPL_NAND_DENALI=y CONFIG_UNIPHIER_SERIAL=y CONFIG_USB=y -CONFIG_USB_EHCI_HCD=y +CONFIG_USB_XHCI_HCD=y CONFIG_USB_STORAGE=y diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h index 3f738fb..df89d14 100644 --- a/include/configs/uniphier.h +++ b/include/configs/uniphier.h @@ -88,6 +88,8 @@ /* #define CONFIG_SYS_ICACHE_OFF */ /* #define CONFIG_SYS_DCACHE_OFF */ +#define CONFIG_SYS_CACHELINE_SIZE 32 + /* Comment out the following to enable L2 cache */ #define CONFIG_UNIPHIER_L2CACHE_ON @@ -186,6 +188,7 @@ /* USB */ #define CONFIG_USB_MAX_CONTROLLER_COUNT2 +#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 4 #define CONFIG_CMD_FAT #define CONFIG_FAT_WRITE #define CONFIG_DOS_PARTITION -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 25/26] ARM: UniPhier: remove SSC_WAY_SIZE and SSC_NUM_ENTRIES macros
Each way of the system cache has 256 entries for PH1-Pro4 and older SoCs, whereas 512 entries for PH1-Pro5 and newer SoCs. The line size is still 128 byte. Thus, the way size is 32KB/64KB for old/new SoCs. To keep lowlevel_init SoC-independent, set BOOT_RAM_SIZE to the constant value 32KB. It is large enough for temporary RAM and should work for all the SoCs of UniPhier family. Signed-off-by: Masahiro Yamada --- Changes in v5: - Newly added Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/mach-uniphier/include/mach/ssc-regs.h | 2 -- arch/arm/mach-uniphier/lowlevel_init.S | 10 +++--- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-uniphier/include/mach/ssc-regs.h b/arch/arm/mach-uniphier/include/mach/ssc-regs.h index 77b3470..02fca3b 100644 --- a/arch/arm/mach-uniphier/include/mach/ssc-regs.h +++ b/arch/arm/mach-uniphier/include/mach/ssc-regs.h @@ -60,8 +60,6 @@ #define SSCOQCE0 0x506c0270 #define SSC_LINE_SIZE 128 -#define SSC_NUM_ENTRIES256 -#define SSC_WAY_SIZE ((SSC_LINE_SIZE) * (SSC_NUM_ENTRIES)) #define SSC_RANGE_OP_MAX_SIZE (0x0040 - (SSC_LINE_SIZE)) #endif /* ARCH_SSC_REGS_H */ diff --git a/arch/arm/mach-uniphier/lowlevel_init.S b/arch/arm/mach-uniphier/lowlevel_init.S index 4b8b623..92299fe 100644 --- a/arch/arm/mach-uniphier/lowlevel_init.S +++ b/arch/arm/mach-uniphier/lowlevel_init.S @@ -7,10 +7,12 @@ #include #include +#include #include #include #include #include +#include ENTRY(lowlevel_init) mov r8, lr @ persevere link reg across call @@ -122,9 +124,11 @@ ENTRY(enable_mmu) mov pc, lr ENDPROC(enable_mmu) -#include - -#define BOOT_RAM_SIZE(SSC_WAY_SIZE) +/* + * For PH1-Pro4 or older SoCs, the size of WAY is 32KB. + * It is large enough for tmp RAM. + */ +#define BOOT_RAM_SIZE(SZ_32K) #define BOOT_WAY_BITS(0x0100) /* way 8 */ ENTRY(setup_init_ram) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 26/26] ARM: UniPhier: move CONFIG_SYS_TEXT_BASE to Kconfig
Signed-off-by: Masahiro Yamada --- Changes in v5: - Newly added Changes in v4: None Changes in v3: None Changes in v2: None Kconfig| 2 +- arch/arm/mach-uniphier/Kconfig | 3 +++ include/configs/uniphier.h | 2 -- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/Kconfig b/Kconfig index 91a0618..e259aaa 100644 --- a/Kconfig +++ b/Kconfig @@ -142,7 +142,7 @@ config SYS_EXTRA_OPTIONS new boards should not use this option. config SYS_TEXT_BASE - depends on SPARC || ARC + depends on SPARC || ARC || ARCH_UNIPHIER hex "Text Base" help TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig index 8335685..dd6120b 100644 --- a/arch/arm/mach-uniphier/Kconfig +++ b/arch/arm/mach-uniphier/Kconfig @@ -48,6 +48,9 @@ config DCC_MICRO_SUPPORT_CARD endchoice +config SYS_TEXT_BASE + default 0x8400 + config SYS_MALLOC_F default y diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h index df89d14..9f5f9aa 100644 --- a/include/configs/uniphier.h +++ b/include/configs/uniphier.h @@ -266,8 +266,6 @@ #define CONFIG_SYS_SDRAM_SIZE (CONFIG_SDRAM0_SIZE) #endif -#define CONFIG_SYS_TEXT_BASE 0x8400 - #if defined(CONFIG_MACH_PH1_LD4) || defined(CONFIG_MACH_PH1_SLD8) #define CONFIG_SPL_TEXT_BASE 0x0004 #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/5] Clean out SPL and enable driver model
This series includes a few more patches aimed at getting rid of gdata, the parallel global_data structure introduced on some ARM boards. It also collects together the other patches which have been sent previously, so that everything is in one place. I would like get this agreed and applied to u-boot-dm this week if possible so that we will at last have driver model available in SPL. This series is available at u-boot-dm/spl-working. Changes in v5: - Rebase to master Changes in v4: - Squash the gdata revert patch into this one - Allow gdata to survive unless CONFIG_DM is defined, for now - Rebase on top of dm/master - Adjust README to mention that lowlevel_init() should have no stack - Add new patch to make the export interface support CONFIG_SYS_MALLOC_SIMPLE Changes in v3: - Drop extra blank line Changes in v2: - Remove gdata definition from ARM spl header file also - Rebase on top of the SPI series - Move docs to top-level README file and expand them to cover U-Boot proper - Add Kconfig settings Simon Glass (5): arm: Reduce the scope of lowlevel_init() arm: spl: Avoid setting up a duplicate global data structure dm: tegra: Enable driver model in SPL and adjust the GPIO driver arm: spl: Allow board_init_r() to run with a larger stack Make export interface support CONFIG_SYS_MALLOC_SIMPLE Kconfig| 18 ++ README | 69 ++ arch/arm/cpu/armv7/lowlevel_init.S | 23 +++-- arch/arm/include/asm/spl.h | 2 ++ arch/arm/lib/crt0.S| 13 +-- arch/arm/lib/spl.c | 4 +++ arch/arm/mach-tegra/Kconfig| 3 ++ board/nvidia/seaboard/seaboard.c | 4 +-- common/spl/spl.c | 35 +++ drivers/gpio/Makefile | 4 +++ drivers/gpio/tegra_gpio.c | 27 ++- include/_exports.h | 2 ++ include/configs/tegra-common.h | 6 include/exports.h | 2 ++ 14 files changed, 174 insertions(+), 38 deletions(-) -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 13/26] ARM: UniPhier: remove EHCI platform devices
Now UniPhier platform highly depends on Device Tree configuration
(CONFIG_OF_CONTROL is select'ed by Kconfig). Since the EHCI is only
used on main U-Boot, we can drop platform devices of the EHCI
controllers. We still keep UART platform devices because they might
be useful for SPL.
Signed-off-by: Masahiro Yamada
Acked-by: Marek Vasut
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/mach-uniphier/include/mach/ehci-uniphier.h | 8 +---
arch/arm/mach-uniphier/include/mach/platdevice.h| 2 --
arch/arm/mach-uniphier/ph1-ld4/platdevice.c | 14 +-
arch/arm/mach-uniphier/ph1-pro4/platdevice.c| 11 +--
arch/arm/mach-uniphier/ph1-sld8/platdevice.c| 14 +-
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/ehci-uniphier.c| 14 +-
7 files changed, 6 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
b/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
index e9c5fb4..3ba3183 100644
--- a/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
+++ b/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2014-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -12,12 +12,6 @@
#include
#include "mio-regs.h"
-struct uniphier_ehci_platform_data {
- unsigned long base;
-};
-
-extern struct uniphier_ehci_platform_data uniphier_ehci_platdata[];
-
static inline void uniphier_ehci_reset(int index, int on)
{
u32 tmp;
diff --git a/arch/arm/mach-uniphier/include/mach/platdevice.h
b/arch/arm/mach-uniphier/include/mach/platdevice.h
index b004c2f..cdf7d13 100644
--- a/arch/arm/mach-uniphier/include/mach/platdevice.h
+++ b/arch/arm/mach-uniphier/include/mach/platdevice.h
@@ -21,6 +21,4 @@ U_BOOT_DEVICE(serial##n) = {
\
.platdata = &serial_device##n \
};
-#include
-
#endif /* ARCH_PLATDEVICE_H */
diff --git a/arch/arm/mach-uniphier/ph1-ld4/platdevice.c
b/arch/arm/mach-uniphier/ph1-ld4/platdevice.c
index 5a3fbdc..c0e6294 100644
--- a/arch/arm/mach-uniphier/ph1-ld4/platdevice.c
+++ b/arch/arm/mach-uniphier/ph1-ld4/platdevice.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2014-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -13,15 +13,3 @@ SERIAL_DEVICE(0, 0x54006800, UART_MASTER_CLK)
SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK)
SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK)
SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK)
-
-struct uniphier_ehci_platform_data uniphier_ehci_platdata[] = {
- {
- .base = 0x5a800100,
- },
- {
- .base = 0x5a810100,
- },
- {
- .base = 0x5a820100,
- },
-};
diff --git a/arch/arm/mach-uniphier/ph1-pro4/platdevice.c
b/arch/arm/mach-uniphier/ph1-pro4/platdevice.c
index 5fc5d38..7440ced 100644
--- a/arch/arm/mach-uniphier/ph1-pro4/platdevice.c
+++ b/arch/arm/mach-uniphier/ph1-pro4/platdevice.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2014-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -13,12 +13,3 @@ SERIAL_DEVICE(0, 0x54006800, UART_MASTER_CLK)
SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK)
SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK)
SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK)
-
-struct uniphier_ehci_platform_data uniphier_ehci_platdata[] = {
- {
- .base = 0x5a800100,
- },
- {
- .base = 0x5a810100,
- },
-};
diff --git a/arch/arm/mach-uniphier/ph1-sld8/platdevice.c
b/arch/arm/mach-uniphier/ph1-sld8/platdevice.c
index ee6d3e2..aa334a1 100644
--- a/arch/arm/mach-uniphier/ph1-sld8/platdevice.c
+++ b/arch/arm/mach-uniphier/ph1-sld8/platdevice.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2014-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -13,15 +13,3 @@ SERIAL_DEVICE(0, 0x54006800, UART_MASTER_CLK)
SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK)
SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK)
SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK)
-
-struct uniphier_ehci_platform_data uniphier_ehci_platdata[] = {
- {
- .base = 0x5a800100,
- },
- {
- .base = 0x5a810100,
- },
- {
- .base = 0x5a820100,
- },
-};
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 30d1457..0e005c2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -47,7 +47,7 @@ if USB_EHCI_HCD
config USB_EHCI_UNIPHIER
bool "Support for Panasonic UniPhier on-c
[U-Boot] [PATCH v5 16/26] ARM: UniPhier: add I/O pin settings for xHCI on PH1-Pro4
This is necessary to use the xHCI cores for PH1-Pro4. Signed-off-by: Masahiro Yamada --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/mach-uniphier/ph1-pro4/pinctrl.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-uniphier/ph1-pro4/pinctrl.c b/arch/arm/mach-uniphier/ph1-pro4/pinctrl.c index c8c0267..f382ef4 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/pinctrl.c +++ b/arch/arm/mach-uniphier/ph1-pro4/pinctrl.c @@ -41,6 +41,13 @@ void pin_init(void) sg_set_pinsel(54, 0); /* NRYBY0 -> NRYBY0 */ #endif +#ifdef CONFIG_USB_XHCI_UNIPHIER + sg_set_pinsel(180, 0); /* USB0VBUS -> USB0VBUS */ + sg_set_pinsel(181, 0); /* USB0OD -> USB0OD */ + sg_set_pinsel(182, 0); /* USB1VBUS -> USB1VBUS */ + sg_set_pinsel(183, 0); /* USB1OD -> USB1OD */ +#endif + #ifdef CONFIG_USB_EHCI_UNIPHIER sg_set_pinsel(184, 0); /* USB2VBUS -> USB2VBUS */ sg_set_pinsel(185, 0); /* USB2OD -> USB2OD */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 24/26] ARM: UniPhier: remove stop_mpll() from PH1-Pro4 PLL initialization
This function was intended for MN2WS0235 (what we call PH1-Pro4TV).
On that SoC, MPLL is already running on the power-on reset and it
makes sense to stop the PLL at early boot-up.
On the other hand, PH1-Pro4(R) does not have SC_MPLLOSCCTL register,
so this function has no point.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Newly added
Changes in v2: None
arch/arm/mach-uniphier/include/mach/sc-regs.h | 4
arch/arm/mach-uniphier/ph1-pro4/pll_init.c| 17 -
2 files changed, 21 deletions(-)
diff --git a/arch/arm/mach-uniphier/include/mach/sc-regs.h
b/arch/arm/mach-uniphier/include/mach/sc-regs.h
index caec6c2..20878e2 100644
--- a/arch/arm/mach-uniphier/include/mach/sc-regs.h
+++ b/arch/arm/mach-uniphier/include/mach/sc-regs.h
@@ -11,10 +11,6 @@
#define SC_BASE_ADDR 0x6184
-#define SC_MPLLOSCCTL (SC_BASE_ADDR | 0x1184)
-#define SC_MPLLOSCCTL_MPLLEN (0x1 << 0)
-#define SC_MPLLOSCCTL_MPLLST (0x1 << 1)
-
#define SC_DPLLCTRL(SC_BASE_ADDR | 0x1200)
#define SC_DPLLCTRL_SSC_EN (0x1 << 31)
#define SC_DPLLCTRL_FOUTMODE_MASK(0xf << 16)
diff --git a/arch/arm/mach-uniphier/ph1-pro4/pll_init.c
b/arch/arm/mach-uniphier/ph1-pro4/pll_init.c
index 3d29548..2a965a5 100644
--- a/arch/arm/mach-uniphier/ph1-pro4/pll_init.c
+++ b/arch/arm/mach-uniphier/ph1-pro4/pll_init.c
@@ -46,22 +46,6 @@ static void dpll_init(void)
writel(tmp, SC_DPLLCTRL2);
}
-static void stop_mpll(void)
-{
- u32 tmp;
-
- tmp = readl(SC_MPLLOSCCTL);
-
- if (!(tmp & SC_MPLLOSCCTL_MPLLST))
- return; /* already stopped */
-
- tmp &= ~SC_MPLLOSCCTL_MPLLEN;
- writel(tmp, SC_MPLLOSCCTL);
-
- while (readl(SC_MPLLOSCCTL) & SC_MPLLOSCCTL_MPLLST)
- ;
-}
-
static void vpll_init(void)
{
u32 tmp, clk_mode_axosel;
@@ -157,7 +141,6 @@ static void vpll_init(void)
void pll_init(void)
{
dpll_init();
- stop_mpll();
vpll_init();
/*
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 23/26] ARM: UniPhier: consolidate MEMCONF setting code
This code is duplicated in ph1-ld4/sg_init.c and ph1-pro4/sg_init.c.
Merge the same code into a new file, memconf.c.
The helper functions no longer have to be placed in the header file.
Also, move them into memconf.c.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/mach-uniphier/Makefile | 1 +
arch/arm/mach-uniphier/include/mach/sg-regs.h | 119 +-
arch/arm/mach-uniphier/memconf.c | 104 ++
arch/arm/mach-uniphier/ph1-ld4/sg_init.c | 11 +--
arch/arm/mach-uniphier/ph1-pro4/sg_init.c | 11 +--
arch/arm/mach-uniphier/spl.c | 11 ++-
6 files changed, 116 insertions(+), 141 deletions(-)
create mode 100644 arch/arm/mach-uniphier/memconf.c
diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
index df418dd..e7a801b 100644
--- a/arch/arm/mach-uniphier/Makefile
+++ b/arch/arm/mach-uniphier/Makefile
@@ -7,6 +7,7 @@ ifdef CONFIG_SPL_BUILD
obj-y += lowlevel_init.o
obj-y += init_page_table.o
obj-y += spl.o
+obj-y += memconf.o
obj-y += ddrphy_training.o
else
diff --git a/arch/arm/mach-uniphier/include/mach/sg-regs.h
b/arch/arm/mach-uniphier/include/mach/sg-regs.h
index 4ae67c8..63408d5 100644
--- a/arch/arm/mach-uniphier/include/mach/sg-regs.h
+++ b/arch/arm/mach-uniphier/include/mach/sg-regs.h
@@ -1,7 +1,7 @@
/*
* UniPhier SG (SoC Glue) block registers
*
- * Copyright (C) 2011-2014 Panasonic Corporation
+ * Copyright (C) 2011-2015 Panasonic Corporation
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -108,7 +108,6 @@
#else
#include
-#include
#include
static inline void sg_set_pinsel(int n, int value)
@@ -117,122 +116,6 @@ static inline void sg_set_pinsel(int n, int value)
| SG_PINSEL_MODE(n, value), SG_PINSEL_ADDR(n));
}
-static inline u32 sg_memconf_val_ch0(unsigned long size, int num)
-{
- int size_mb = size / num;
- u32 ret;
-
- switch (size_mb) {
- case SZ_64M:
- ret = SG_MEMCONF_CH0_SZ_64M;
- break;
- case SZ_128M:
- ret = SG_MEMCONF_CH0_SZ_128M;
- break;
- case SZ_256M:
- ret = SG_MEMCONF_CH0_SZ_256M;
- break;
- case SZ_512M:
- ret = SG_MEMCONF_CH0_SZ_512M;
- break;
- case SZ_1G:
- ret = SG_MEMCONF_CH0_SZ_1G;
- break;
- default:
- BUG();
- break;
- }
-
- switch (num) {
- case 1:
- ret |= SG_MEMCONF_CH0_NUM_1;
- break;
- case 2:
- ret |= SG_MEMCONF_CH0_NUM_2;
- break;
- default:
- BUG();
- break;
- }
- return ret;
-}
-
-static inline u32 sg_memconf_val_ch1(unsigned long size, int num)
-{
- int size_mb = size / num;
- u32 ret;
-
- switch (size_mb) {
- case SZ_64M:
- ret = SG_MEMCONF_CH1_SZ_64M;
- break;
- case SZ_128M:
- ret = SG_MEMCONF_CH1_SZ_128M;
- break;
- case SZ_256M:
- ret = SG_MEMCONF_CH1_SZ_256M;
- break;
- case SZ_512M:
- ret = SG_MEMCONF_CH1_SZ_512M;
- break;
- case SZ_1G:
- ret = SG_MEMCONF_CH1_SZ_1G;
- break;
- default:
- BUG();
- break;
- }
-
- switch (num) {
- case 1:
- ret |= SG_MEMCONF_CH1_NUM_1;
- break;
- case 2:
- ret |= SG_MEMCONF_CH1_NUM_2;
- break;
- default:
- BUG();
- break;
- }
- return ret;
-}
-
-static inline u32 sg_memconf_val_ch2(unsigned long size, int num)
-{
- int size_mb = size / num;
- u32 ret;
-
- switch (size_mb) {
- case SZ_64M:
- ret = SG_MEMCONF_CH2_SZ_64M;
- break;
- case SZ_128M:
- ret = SG_MEMCONF_CH2_SZ_128M;
- break;
- case SZ_256M:
- ret = SG_MEMCONF_CH2_SZ_256M;
- break;
- case SZ_512M:
- ret = SG_MEMCONF_CH2_SZ_512M;
- break;
- default:
- BUG();
- break;
- }
-
- switch (num) {
- case 1:
- ret |= SG_MEMCONF_CH2_NUM_1;
- break;
- case 2:
- ret |= SG_MEMCONF_CH2_NUM_2;
- break;
- default:
- BUG();
- break;
- }
- return ret;
-}
#endif /* __ASSEMBLY__ */
#endif /* ARCH_SG_REGS_H */
diff --git a/arch/arm/mach-uniphier/memconf.c b/arch/arm/mach-uniphier/memconf.c
new file mode 100644
index 000..bf3c177
--- /dev/null
+++ b/arch/arm/mach-uniphier/memconf.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2011-2015 Panasonic Corporati
[U-Boot] [PATCH v5 21/26] ARM: UniPhier: support 1CS support card for all the UniPhier SoCs
Two support card variants are used with UniPhier reference boards:
- 1 chip select support card (original CPLD)
- 3 chip selects support card (ARIMA-compatible CPLD)
Currently, the former is only supported on PH1-Pro4, but it can be
expanded to PH1-LD4, PH1-sLD8 with a little code change.
Signed-off-by: Masahiro Yamada
---
Changes in v5:
- Bug fix. LD4 and sLD8 need PC0CTRL setting.
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/mach-uniphier/ph1-ld4/Makefile| 4 +-
arch/arm/mach-uniphier/ph1-ld4/sbc_init.c | 56
arch/arm/mach-uniphier/ph1-ld4/sbc_init_3cs.c | 50 ++
arch/arm/mach-uniphier/ph1-pro4/Makefile | 4 +-
arch/arm/mach-uniphier/ph1-pro4/sbc_init.c | 32 --
arch/arm/mach-uniphier/ph1-pro4/sbc_init_3cs.c | 43 +++
arch/arm/mach-uniphier/ph1-sld8/Makefile | 4 +-
arch/arm/mach-uniphier/ph1-sld8/sbc_init.c | 59 +-
arch/arm/mach-uniphier/ph1-sld8/sbc_init_3cs.c | 58 +
9 files changed, 189 insertions(+), 121 deletions(-)
create mode 100644 arch/arm/mach-uniphier/ph1-ld4/sbc_init_3cs.c
create mode 100644 arch/arm/mach-uniphier/ph1-pro4/sbc_init_3cs.c
create mode 100644 arch/arm/mach-uniphier/ph1-sld8/sbc_init_3cs.c
diff --git a/arch/arm/mach-uniphier/ph1-ld4/Makefile
b/arch/arm/mach-uniphier/ph1-ld4/Makefile
index 927640a..5ce3d8a 100644
--- a/arch/arm/mach-uniphier/ph1-ld4/Makefile
+++ b/arch/arm/mach-uniphier/ph1-ld4/Makefile
@@ -4,8 +4,10 @@
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_DEBUG_LL) += lowlevel_debug.o
-obj-y += bcu_init.o sbc_init.o sg_init.o pll_init.o early_clkrst_init.o \
+obj-y += bcu_init.o sg_init.o pll_init.o early_clkrst_init.o \
pll_spectrum.o umc_init.o ddrphy_init.o
+obj-$(CONFIG_PFC_MICRO_SUPPORT_CARD) += sbc_init.o
+obj-$(CONFIG_DCC_MICRO_SUPPORT_CARD) += sbc_init_3cs.o
else
obj-$(CONFIG_BOARD_EARLY_INIT_F) += pinctrl.o clkrst_init.o
obj-$(if $(CONFIG_OF_CONTROL),,y) += platdevice.o
diff --git a/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
b/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
index 374a8c0..00f8461 100644
--- a/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
+++ b/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
@@ -19,32 +19,32 @@ void sbc_init(void)
tmp &= 0xfcff;
writel(tmp, PC0CTRL);
- /* XECS1: sub/boot memory (boot swap = off/on) */
- writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL10);
- writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL11);
- writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL12);
- writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL14);
-
- /* XECS0: boot/sub memory (boot swap = off/on) */
- writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL00);
- writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL01);
- writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL02);
- writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL04);
-
- /* XECS3: peripherals */
- writel(SBCTRL0_SAVEPIN_PERI_VALUE, SBCTRL30);
- writel(SBCTRL1_SAVEPIN_PERI_VALUE, SBCTRL31);
- writel(SBCTRL2_SAVEPIN_PERI_VALUE, SBCTRL32);
- writel(SBCTRL4_SAVEPIN_PERI_VALUE, SBCTRL34);
-
- /* base address regsiters */
- writel(0xbc01, SBBASE0);
- writel(0x0400bc01, SBBASE1);
- writel(0x0800bf01, SBBASE3);
-
- /* enable access to sub memory when boot swap is on */
- if (boot_is_swapped())
- sg_set_pinsel(155, 1); /* PORT24 -> XECS0 */
-
- sg_set_pinsel(156, 1); /* PORT25 -> XECS3 */
+ /*
+* Only CS1 is connected to support card.
+* BKSZ[1:0] should be set to "01".
+*/
+ writel(SBCTRL0_SAVEPIN_PERI_VALUE, SBCTRL10);
+ writel(SBCTRL1_SAVEPIN_PERI_VALUE, SBCTRL11);
+ writel(SBCTRL2_SAVEPIN_PERI_VALUE, SBCTRL12);
+ writel(SBCTRL4_SAVEPIN_PERI_VALUE, SBCTRL14);
+
+ if (boot_is_swapped()) {
+ /*
+* Boot Swap On: boot from external NOR/SRAM
+* 0x0200-0x03ff is a mirror of 0x-0x01ff.
+*
+* 0x-0x01ef, 0x0200-0x03ef: memory bank
+* 0x01f0-0x01ff, 0x03f0-0x03ff: peripherals
+*/
+ writel(0xbc01, SBBASE0);
+ } else {
+ /*
+* Boot Swap Off: boot from mask ROM
+* 0x-0x01ff: mask ROM
+* 0x0200-0x03ef: memory bank (31MB)
+* 0x03f0-0x03ff: peripherals (1MB)
+*/
+ writel(0xbe01, SBBASE0); /* dummy */
+ writel(0x0200be01, SBBASE1);
+ }
}
diff --git a/arch/arm/mach-uniphier/ph1-ld4/sbc_init_3cs.c
b/arch/arm/mach-uniphier/ph1-ld4/sbc_init_3cs.c
new file mode 100644
index 000..374a8c0
--- /dev/null
+++ b/arch/arm/mach-uniphier/ph1-ld4/sbc_init_3cs.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2011-2015 Panasonic Corporation
+ * Author: Masa
[U-Boot] [PATCH v5 19/26] usb: UniPhier: add UniPhier on-chip xHCI host driver support
Support xHCI host driver used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada
Acked-by: Marek Vasut
---
Changes in v5: None
Changes in v4:
- use fdtdec_find_aliases_for_id() to get the offset to the node
Changes in v3: None
Changes in v2:
- add the error check of fdtdec_get_addr()
doc/README.uniphier | 3 +-
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile| 1 +
drivers/usb/host/xhci-uniphier.c | 85
include/fdtdec.h | 1 +
lib/fdtdec.c | 1 +
6 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/host/xhci-uniphier.c
diff --git a/doc/README.uniphier b/doc/README.uniphier
index aaeb50c..4902533 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -73,7 +73,8 @@ Supported devices
- UART (on-chip)
- NAND
- - USB (2.0)
+ - USB 2.0 (EHCI)
+ - USB 3.0 (xHCI)
- LAN (on-board SMSC9118)
- I2C
- EEPROM (connected to the on-board I2C bus)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0e005c2..24a595f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -17,6 +17,14 @@ config USB_XHCI
if USB_XHCI_HCD
+config USB_XHCI_UNIPHIER
+ bool "Support for Panasonic UniPhier on-chip xHCI USB controller"
+ depends on ARCH_UNIPHIER
+ default y
+ ---help---
+ Enables support for the on-chip xHCI controller on Panasonic
+ UniPhier SoCs.
+
endif
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 66d6e9a..eb6f34b 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o
obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_UNIPHIER) += xhci-uniphier.o
# designware
obj-$(CONFIG_USB_DWC2) += dwc2.o
diff --git a/drivers/usb/host/xhci-uniphier.c b/drivers/usb/host/xhci-uniphier.c
new file mode 100644
index 000..08b15e0
--- /dev/null
+++ b/drivers/usb/host/xhci-uniphier.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2015 Panasonic Corporation
+ * Author: Masahiro Yamada
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include "xhci.h"
+
+static int get_uniphier_xhci_base(int index, struct xhci_hccr **base)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ int node_list[2];
+ fdt_addr_t addr;
+ int count;
+
+ count = fdtdec_find_aliases_for_id(gd->fdt_blob, "usb",
+ COMPAT_PANASONIC_XHCI, node_list,
+ ARRAY_SIZE(node_list));
+
+ if (index >= count)
+ return -ENODEV;
+
+ addr = fdtdec_get_addr(gd->fdt_blob, node_list[index], "reg");
+ if (addr == FDT_ADDR_T_NONE)
+ return -ENODEV;
+
+ *base = (struct xhci_hccr *)addr;
+
+ return 0;
+}
+
+#define USB3_RST_CTRL 0x00100040
+#define IOMMU_RST_N(1 << 5)
+#define LINK_RST_N (1 << 4)
+
+static void uniphier_xhci_reset(void __iomem *base, int on)
+{
+ u32 tmp;
+
+ tmp = readl(base + USB3_RST_CTRL);
+
+ if (on)
+ tmp &= ~(IOMMU_RST_N | LINK_RST_N);
+ else
+ tmp |= IOMMU_RST_N | LINK_RST_N;
+
+ writel(tmp, base + USB3_RST_CTRL);
+}
+
+int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor)
+{
+ int ret;
+ struct xhci_hccr *cr;
+ struct xhci_hcor *or;
+
+ ret = get_uniphier_xhci_base(index, &cr);
+ if (ret < 0)
+ return ret;
+
+ uniphier_xhci_reset(cr, 0);
+
+ or = (void *)cr + HC_LENGTH(xhci_readl(&cr->cr_capbase));
+
+ *hccr = cr;
+ *hcor = or;
+
+ return 0;
+}
+
+void xhci_hcd_stop(int index)
+{
+ int ret;
+ struct xhci_hccr *cr;
+
+ ret = get_uniphier_xhci_base(index, &cr);
+ if (ret < 0)
+ return;
+
+ uniphier_xhci_reset(cr, 1);
+}
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 1bc70db..1233dfb 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -168,6 +168,7 @@ enum fdt_compat_id {
COMPAT_AMS_AS3722, /* AMS AS3722 PMIC */
COMPAT_INTEL_ICH_SPI, /* Intel ICH7/9 SPI controller */
COMPAT_INTEL_QRK_MRC, /* Intel Quark MRC */
+ COMPAT_PANASONIC_XHCI, /* Panasonic UniPhier xHCI */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index dd58bbb..21933e4 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -76,6 +76,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(AMS_AS3722, "ams,as3722"),
COMPAT(INTEL_ICH_SPI, "intel,ich-spi"),
COMPAT(INTEL_QRK_MRC, "intel,quark-mrc"),
+ COMPAT(PANASONIC_XHCI, "panasonic,uniphier-xhci")
[U-Boot] [PATCH v5 18/26] ARM: UniPhier: add xHCI device nodes to PH1-Pro4 device tree
Each USB port corresponds to the following IP core:
port0: xHCI (0x65a0) SS+HS
port1: xHCI (0x65c0) HS (SS PHY is not implemented)
port2: EHCI (0x5a800100) HS
port3: EHCI (0x5a810100) HS
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/uniphier-ph1-pro4-ref.dts | 5 +
arch/arm/dts/uniphier-ph1-pro4.dtsi| 16 ++--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index d9e7a8c..5bec92b 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -36,6 +36,7 @@
i2c3 = &i2c3;
i2c5 = &i2c5;
i2c6 = &i2c6;
+ usb0 = &usb0;
};
};
@@ -54,7 +55,3 @@
&usb0 {
status = "okay";
};
-
-&usb1 {
- status = "okay";
-};
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index 3f1001b..1247779 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -119,18 +119,30 @@
status = "ok";
};
- usb0: usb@5a800100 {
+ usb2: usb@5a800100 {
compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a800100 0x100>;
};
- usb1: usb@5a810100 {
+ usb3: usb@5a810100 {
compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a810100 0x100>;
};
+ usb0: usb@65a0 {
+ compatible = "panasonic,uniphier-xhci", "generic-xhci";
+ status = "disabled";
+ reg = <0x65a0 0x100>;
+ };
+
+ usb1: usb@65c0 {
+ compatible = "panasonic,uniphier-xhci", "generic-xhci";
+ status = "disabled";
+ reg = <0x65c0 0x100>;
+ };
+
nand: nand@6800 {
compatible = "denali,denali-nand-dt";
reg = <0x6800 0x20>, <0x6810 0x1000>;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 15/26] ARM: UniPhier: replace "usb-ehci" with "generic-ehci"
EHCI host controllers have a common register interface.
We may wish to implement a generic EHCI driver someday.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/uniphier-ph1-ld4.dtsi | 8
arch/arm/dts/uniphier-ph1-pro4.dtsi | 6 +++---
arch/arm/dts/uniphier-ph1-sld3.dtsi | 10 +-
arch/arm/dts/uniphier-ph1-sld8.dtsi | 8
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index 2a3dd73..8ed7bbf 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -1,7 +1,7 @@
/*
* Device Tree Source for UniPhier PH1-LD4 SoC
*
- * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2014-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -94,19 +94,19 @@
};
usb0: usb@5a800100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a800100 0x100>;
};
usb1: usb@5a810100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a810100 0x100>;
};
usb2: usb@5a820100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a820100 0x100>;
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index 49e375e..3f1001b 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -1,7 +1,7 @@
/*
* Device Tree Source for UniPhier PH1-Pro4 SoC
*
- * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2014-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -120,13 +120,13 @@
};
usb0: usb@5a800100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a800100 0x100>;
};
usb1: usb@5a810100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a810100 0x100>;
};
diff --git a/arch/arm/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/dts/uniphier-ph1-sld3.dtsi
index f5529d2..88322c6 100644
--- a/arch/arm/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/dts/uniphier-ph1-sld3.dtsi
@@ -1,7 +1,7 @@
/*
* Device Tree Source for UniPhier PH1-sLD3 SoC
*
- * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2014-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -93,25 +93,25 @@
};
usb0: usb@5a800100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a800100 0x100>;
};
usb1: usb@5a810100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a810100 0x100>;
};
usb2: usb@5a820100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a820100 0x100>;
};
usb3: usb@5a830100 {
- compatible = "panasonic,uniphier-ehci", "usb-ehci";
+ compatible = "panasonic,uniphier-ehci", "generic-ehci";
status = "disabled";
reg = <0x5a830100 0x100>;
};
diff --git a/arch/arm/dts/uniphier-ph1-sld8.dtsi
b/arch/arm/dts/uniphier-ph1-sld8.dtsi
index 0ea76e5..1b3eb22 100644
--- a/arch/arm/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/dts/uniphier-ph1-sld8.dtsi
@@ -1,7 +1,7 @@
/*
* Device Tree Source for UniPhier PH1-sLD8 SoC
*
- *
[U-Boot] [PATCH v5 01/26] ARM: UniPhier: move SoC sources to mach-uniphier
Move
arch/arm/cpu/armv7/uniphier/* -> arch/arm/mach-uniphier/*
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Newly added
Changes in v2: None
MAINTAINERS | 2 +-
arch/arm/Kconfig| 2 +-
arch/arm/Makefile | 1 +
arch/arm/cpu/armv7/Makefile | 1 -
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/Kconfig | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/Makefile | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/board_common.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/board_early_init_f.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/board_early_init_r.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/board_late_init.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/cache_uniphier.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/cmd_ddrphy.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/cmd_pinmon.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/cpu_info.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ddrphy_training.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/dram_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/init_page_table.S| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/lowlevel_init.S | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/Makefile | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/bcu_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/boot-mode.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/clkrst_init.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/ddrphy_init.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/lowlevel_debug.S | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/pinctrl.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/platdevice.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/pll_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/pll_spectrum.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/sbc_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/sg_init.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-ld4/umc_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/Makefile| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/boot-mode.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/clkrst_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/ddrphy_init.c | 0
.../arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/lowlevel_debug.S | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/pinctrl.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/platdevice.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/pll_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/pll_spectrum.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/sbc_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/sg_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-pro4/umc_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/Makefile| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/bcu_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/boot-mode.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/clkrst_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/ddrphy_init.c | 0
.../arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/lowlevel_debug.S | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/pinctrl.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/platdevice.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/pll_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/pll_spectrum.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/sbc_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/sg_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/ph1-sld8/umc_init.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/print_misc_info.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/reset.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/smp.S| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/spl.c| 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/support_card.c | 0
arch/arm/{cpu/armv7/uniphier => mach-uniphier}/timer.c | 0
62 files changed, 3
[U-Boot] [PATCH v5 03/26] ARM: UniPhier: include instead of
Since commit 0e7368c6c426 (kbuild: prepare for moving headers into
mach-*/include/mach), we can replace #include with
so we do not need to create the symbolic link during the
build.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Newly added
Changes in v2: None
arch/arm/mach-uniphier/board_common.c| 2 +-
arch/arm/mach-uniphier/board_early_init_f.c | 4 ++--
arch/arm/mach-uniphier/board_early_init_r.c | 2 +-
arch/arm/mach-uniphier/cache_uniphier.c | 2 +-
arch/arm/mach-uniphier/cmd_ddrphy.c | 2 +-
arch/arm/mach-uniphier/cmd_pinmon.c | 4 ++--
arch/arm/mach-uniphier/cpu_info.c| 2 +-
arch/arm/mach-uniphier/ddrphy_training.c | 2 +-
arch/arm/mach-uniphier/include/mach/platdevice.h | 2 +-
arch/arm/mach-uniphier/lowlevel_init.S | 8
arch/arm/mach-uniphier/ph1-ld4/bcu_init.c| 2 +-
arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c | 2 +-
arch/arm/mach-uniphier/ph1-ld4/ddrphy_init.c | 2 +-
arch/arm/mach-uniphier/ph1-ld4/lowlevel_debug.S | 4 ++--
arch/arm/mach-uniphier/ph1-ld4/pinctrl.c | 2 +-
arch/arm/mach-uniphier/ph1-ld4/platdevice.c | 2 +-
arch/arm/mach-uniphier/ph1-ld4/pll_init.c| 4 ++--
arch/arm/mach-uniphier/ph1-ld4/sbc_init.c| 4 ++--
arch/arm/mach-uniphier/ph1-ld4/sg_init.c | 2 +-
arch/arm/mach-uniphier/ph1-ld4/umc_init.c| 4 ++--
arch/arm/mach-uniphier/ph1-pro4/boot-mode.c | 6 +++---
arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c| 2 +-
arch/arm/mach-uniphier/ph1-pro4/ddrphy_init.c| 2 +-
arch/arm/mach-uniphier/ph1-pro4/lowlevel_debug.S | 6 +++---
arch/arm/mach-uniphier/ph1-pro4/pinctrl.c| 2 +-
arch/arm/mach-uniphier/ph1-pro4/platdevice.c | 2 +-
arch/arm/mach-uniphier/ph1-pro4/pll_init.c | 4 ++--
arch/arm/mach-uniphier/ph1-pro4/pll_spectrum.c | 2 +-
arch/arm/mach-uniphier/ph1-pro4/sbc_init.c | 4 ++--
arch/arm/mach-uniphier/ph1-pro4/sg_init.c| 2 +-
arch/arm/mach-uniphier/ph1-pro4/umc_init.c | 4 ++--
arch/arm/mach-uniphier/ph1-sld8/clkrst_init.c| 2 +-
arch/arm/mach-uniphier/ph1-sld8/ddrphy_init.c| 2 +-
arch/arm/mach-uniphier/ph1-sld8/lowlevel_debug.S | 4 ++--
arch/arm/mach-uniphier/ph1-sld8/pinctrl.c| 2 +-
arch/arm/mach-uniphier/ph1-sld8/platdevice.c | 2 +-
arch/arm/mach-uniphier/ph1-sld8/pll_init.c | 4 ++--
arch/arm/mach-uniphier/ph1-sld8/sbc_init.c | 4 ++--
arch/arm/mach-uniphier/ph1-sld8/umc_init.c | 4 ++--
arch/arm/mach-uniphier/print_misc_info.c | 2 +-
arch/arm/mach-uniphier/reset.c | 2 +-
arch/arm/mach-uniphier/smp.S | 4 ++--
arch/arm/mach-uniphier/spl.c | 4 ++--
arch/arm/mach-uniphier/support_card.c| 4 ++--
arch/arm/mach-uniphier/timer.c | 2 +-
drivers/usb/host/ehci-uniphier.c | 2 +-
46 files changed, 69 insertions(+), 69 deletions(-)
diff --git a/arch/arm/mach-uniphier/board_common.c
b/arch/arm/mach-uniphier/board_common.c
index 3fb26c6..5f2d5f6 100644
--- a/arch/arm/mach-uniphier/board_common.c
+++ b/arch/arm/mach-uniphier/board_common.c
@@ -6,7 +6,7 @@
*/
#include
-#include
+#include
/*
* Routine: board_init
diff --git a/arch/arm/mach-uniphier/board_early_init_f.c
b/arch/arm/mach-uniphier/board_early_init_f.c
index d25bbae..bf81345 100644
--- a/arch/arm/mach-uniphier/board_early_init_f.c
+++ b/arch/arm/mach-uniphier/board_early_init_f.c
@@ -5,8 +5,8 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#include
-#include
+#include
+#include
void pin_init(void);
diff --git a/arch/arm/mach-uniphier/board_early_init_r.c
b/arch/arm/mach-uniphier/board_early_init_r.c
index cb7e04f..579fe70 100644
--- a/arch/arm/mach-uniphier/board_early_init_r.c
+++ b/arch/arm/mach-uniphier/board_early_init_r.c
@@ -6,7 +6,7 @@
*/
#include
-#include
+#include
int board_early_init_r(void)
{
diff --git a/arch/arm/mach-uniphier/cache_uniphier.c
b/arch/arm/mach-uniphier/cache_uniphier.c
index e47f977..52f3c7c 100644
--- a/arch/arm/mach-uniphier/cache_uniphier.c
+++ b/arch/arm/mach-uniphier/cache_uniphier.c
@@ -8,7 +8,7 @@
#include
#include
#include
-#include
+#include
#ifdef CONFIG_UNIPHIER_L2CACHE_ON
static void uniphier_cache_maint_all(u32 operation)
diff --git a/arch/arm/mach-uniphier/cmd_ddrphy.c
b/arch/arm/mach-uniphier/cmd_ddrphy.c
index 431d901..5f44927 100644
--- a/arch/arm/mach-uniphier/cmd_ddrphy.c
+++ b/arch/arm/mach-uniphier/cmd_ddrphy.c
@@ -7,7 +7,7 @@
#include
#include
-#include
+#include
/* Select either decimal or hexadecimal */
#if 1
diff --git a/arch/arm/mach-uniphier/cmd_pinmon.c
b/arch/arm/mach-uniphier/cmd_pinmon.c
index 3c1b325..8be2ed4 100644
--- a/arch/arm/mach-uniphier/cmd_pinmon.c
+++ b/arch/arm/mach-uniphier/cmd_pinmon.c
@@ -6,8 +6,8 @@
*/
#include
-#include
-#include
+#include
+#includ
[U-Boot] [PATCH v5 12/26] ARM: UniPhier: enable STDMAC for EHCI
Deassert the reset signal and provide the clock for STDMAC core. This is necessary for the USB 2.0 host controllers. Signed-off-by: Masahiro Yamada --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/mach-uniphier/include/mach/sc-regs.h | 2 ++ arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c | 5 - arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c | 5 - 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-uniphier/include/mach/sc-regs.h b/arch/arm/mach-uniphier/include/mach/sc-regs.h index 7726530..f0467bb 100644 --- a/arch/arm/mach-uniphier/include/mach/sc-regs.h +++ b/arch/arm/mach-uniphier/include/mach/sc-regs.h @@ -39,6 +39,7 @@ #define SC_RSTCTRL (SC_BASE_ADDR | 0x2000) #define SC_RSTCTRL_NRST_ETHER (0x1 << 12) +#define SC_RSTCTRL_NRST_STDMAC (0x1 << 10) #define SC_RSTCTRL_NRST_UMC1 (0x1 << 5) #define SC_RSTCTRL_NRST_UMC0 (0x1 << 4) #define SC_RSTCTRL_NRST_NAND (0x1 << 2) @@ -49,6 +50,7 @@ #define SC_CLKCTRL (SC_BASE_ADDR | 0x2104) #define SC_CLKCTRL_CEN_ETHER (0x1 << 12) #define SC_CLKCTRL_CEN_MIO (0x1 << 11) +#define SC_CLKCTRL_CEN_STDMAC (0x1 << 10) #define SC_CLKCTRL_CEN_UMC (0x1 << 4) #define SC_CLKCTRL_CEN_NAND(0x1 << 2) #define SC_CLKCTRL_CEN_SBC (0x1 << 1) diff --git a/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c b/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c index f5fc418..4ac5411 100644 --- a/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c @@ -17,6 +17,9 @@ void clkrst_init(void) #ifdef CONFIG_UNIPHIER_ETH tmp |= SC_RSTCTRL_NRST_ETHER; #endif +#ifdef CONFIG_USB_EHCI_UNIPHIER + tmp |= SC_RSTCTRL_NRST_STDMAC; +#endif #ifdef CONFIG_NAND_DENALI tmp |= SC_RSTCTRL_NRST_NAND; #endif @@ -29,7 +32,7 @@ void clkrst_init(void) tmp |= SC_CLKCTRL_CEN_ETHER; #endif #ifdef CONFIG_USB_EHCI_UNIPHIER - tmp |= SC_CLKCTRL_CEN_MIO; + tmp |= SC_CLKCTRL_CEN_MIO | SC_CLKCTRL_CEN_STDMAC; #endif #ifdef CONFIG_NAND_DENALI tmp |= SC_CLKCTRL_CEN_NAND; diff --git a/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c b/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c index f5fc418..4ac5411 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c @@ -17,6 +17,9 @@ void clkrst_init(void) #ifdef CONFIG_UNIPHIER_ETH tmp |= SC_RSTCTRL_NRST_ETHER; #endif +#ifdef CONFIG_USB_EHCI_UNIPHIER + tmp |= SC_RSTCTRL_NRST_STDMAC; +#endif #ifdef CONFIG_NAND_DENALI tmp |= SC_RSTCTRL_NRST_NAND; #endif @@ -29,7 +32,7 @@ void clkrst_init(void) tmp |= SC_CLKCTRL_CEN_ETHER; #endif #ifdef CONFIG_USB_EHCI_UNIPHIER - tmp |= SC_CLKCTRL_CEN_MIO; + tmp |= SC_CLKCTRL_CEN_MIO | SC_CLKCTRL_CEN_STDMAC; #endif #ifdef CONFIG_NAND_DENALI tmp |= SC_CLKCTRL_CEN_NAND; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 04/26] ARM: UniPhier: update defconfigs using savedefconfig
Signed-off-by: Masahiro Yamada --- Changes in v5: - Newly added Changes in v4: None Changes in v3: None Changes in v2: None configs/ph1_ld4_defconfig | 18 +- configs/ph1_pro4_defconfig | 18 +- configs/ph1_sld8_defconfig | 18 +- 3 files changed, 27 insertions(+), 27 deletions(-) diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig index fa8d291..edfdafa 100644 --- a/configs/ph1_ld4_defconfig +++ b/configs/ph1_ld4_defconfig @@ -1,9 +1,13 @@ +CONFIG_ARM=y +CONFIG_ARCH_UNIPHIER=y +CONFIG_DM=y +CONFIG_DM_SERIAL=y +CONFIG_DM_I2C=y +CONFIG_MACH_PH1_LD4=y +CONFIG_DCC_MICRO_SUPPORT_CARD=y +CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref" CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -+S:CONFIG_ARM=y -+S:CONFIG_ARCH_UNIPHIER=y -+S:CONFIG_MACH_PH1_LD4=y -+S:CONFIG_DCC_MICRO_SUPPORT_CARD=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BDI=y CONFIG_CMD_CONSOLE=y @@ -28,15 +32,11 @@ CONFIG_CMD_TFTPPUT=y CONFIG_CMD_NFS=y CONFIG_CMD_PING=y CONFIG_CMD_TIME=y -CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref" -CONFIG_DM=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 -CONFIG_DM_SERIAL=y +CONFIG_SPL_NAND_DENALI=y CONFIG_UNIPHIER_SERIAL=y -CONFIG_DM_I2C=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y -CONFIG_SPL_NAND_DENALI=y diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig index 12f0694..f1fb7b7 100644 --- a/configs/ph1_pro4_defconfig +++ b/configs/ph1_pro4_defconfig @@ -1,9 +1,13 @@ +CONFIG_ARM=y +CONFIG_ARCH_UNIPHIER=y +CONFIG_DM=y +CONFIG_DM_SERIAL=y +CONFIG_DM_I2C=y +CONFIG_MACH_PH1_PRO4=y +CONFIG_DCC_MICRO_SUPPORT_CARD=y +CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref" CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -+S:CONFIG_ARM=y -+S:CONFIG_ARCH_UNIPHIER=y -+S:CONFIG_MACH_PH1_PRO4=y -+S:CONFIG_DCC_MICRO_SUPPORT_CARD=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BDI=y CONFIG_CMD_CONSOLE=y @@ -28,15 +32,11 @@ CONFIG_CMD_TFTPPUT=y CONFIG_CMD_NFS=y CONFIG_CMD_PING=y CONFIG_CMD_TIME=y -CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref" -CONFIG_DM=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 -CONFIG_DM_SERIAL=y +CONFIG_SPL_NAND_DENALI=y CONFIG_UNIPHIER_SERIAL=y -CONFIG_DM_I2C=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y -CONFIG_SPL_NAND_DENALI=y diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig index e66d166..0d437c6 100644 --- a/configs/ph1_sld8_defconfig +++ b/configs/ph1_sld8_defconfig @@ -1,9 +1,13 @@ +CONFIG_ARM=y +CONFIG_ARCH_UNIPHIER=y +CONFIG_DM=y +CONFIG_DM_SERIAL=y +CONFIG_DM_I2C=y +CONFIG_MACH_PH1_SLD8=y +CONFIG_DCC_MICRO_SUPPORT_CARD=y +CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref" CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -+S:CONFIG_ARM=y -+S:CONFIG_ARCH_UNIPHIER=y -+S:CONFIG_MACH_PH1_SLD8=y -+S:CONFIG_DCC_MICRO_SUPPORT_CARD=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BDI=y CONFIG_CMD_CONSOLE=y @@ -28,15 +32,11 @@ CONFIG_CMD_TFTPPUT=y CONFIG_CMD_NFS=y CONFIG_CMD_PING=y CONFIG_CMD_TIME=y -CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref" -CONFIG_DM=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 -CONFIG_DM_SERIAL=y +CONFIG_SPL_NAND_DENALI=y CONFIG_UNIPHIER_SERIAL=y -CONFIG_DM_I2C=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y -CONFIG_SPL_NAND_DENALI=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 09/26] ARM: UniPhier: rename SC_CLKCTRL_CLK_* to SC_SCLKCTRL_CEN_*
Follow the register macros in the LSI specification book. Signed-off-by: Masahiro Yamada --- Changes in v5: - Newly added Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/mach-uniphier/include/mach/sc-regs.h| 12 ++-- arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c | 4 ++-- arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c| 4 ++-- arch/arm/mach-uniphier/ph1-pro4/lowlevel_debug.S | 2 +- arch/arm/mach-uniphier/ph1-sld8/clkrst_init.c| 4 ++-- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-uniphier/include/mach/sc-regs.h b/arch/arm/mach-uniphier/include/mach/sc-regs.h index 1197bb5..7726530 100644 --- a/arch/arm/mach-uniphier/include/mach/sc-regs.h +++ b/arch/arm/mach-uniphier/include/mach/sc-regs.h @@ -47,12 +47,12 @@ #define SC_RSTCTRL3(SC_BASE_ADDR | 0x2008) #define SC_CLKCTRL (SC_BASE_ADDR | 0x2104) -#define SC_CLKCTRL_CLK_ETHER (0x1 << 12) -#define SC_CLKCTRL_CLK_MIO (0x1 << 11) -#define SC_CLKCTRL_CLK_UMC (0x1 << 4) -#define SC_CLKCTRL_CLK_NAND(0x1 << 2) -#define SC_CLKCTRL_CLK_SBC (0x1 << 1) -#define SC_CLKCTRL_CLK_PERI(0x1 << 0) +#define SC_CLKCTRL_CEN_ETHER (0x1 << 12) +#define SC_CLKCTRL_CEN_MIO (0x1 << 11) +#define SC_CLKCTRL_CEN_UMC (0x1 << 4) +#define SC_CLKCTRL_CEN_NAND(0x1 << 2) +#define SC_CLKCTRL_CEN_SBC (0x1 << 1) +#define SC_CLKCTRL_CEN_PERI(0x1 << 0) /* System reset control register */ #define SC_IRQTIMSET (SC_BASE_ADDR | 0x3000) diff --git a/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c b/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c index 6a9d144..eaa45f9 100644 --- a/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c @@ -22,8 +22,8 @@ void clkrst_init(void) /* privide clocks */ tmp = readl(SC_CLKCTRL); - tmp |= SC_CLKCTRL_CLK_ETHER | SC_CLKCTRL_CLK_MIO | SC_CLKCTRL_CLK_UMC -| SC_CLKCTRL_CLK_NAND | SC_CLKCTRL_CLK_SBC | SC_CLKCTRL_CLK_PERI; + tmp |= SC_CLKCTRL_CEN_ETHER | SC_CLKCTRL_CEN_MIO | SC_CLKCTRL_CEN_UMC +| SC_CLKCTRL_CEN_NAND | SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI; writel(tmp, SC_CLKCTRL); readl(SC_CLKCTRL); /* dummy read */ } diff --git a/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c b/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c index 6a9d144..eaa45f9 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-pro4/clkrst_init.c @@ -22,8 +22,8 @@ void clkrst_init(void) /* privide clocks */ tmp = readl(SC_CLKCTRL); - tmp |= SC_CLKCTRL_CLK_ETHER | SC_CLKCTRL_CLK_MIO | SC_CLKCTRL_CLK_UMC -| SC_CLKCTRL_CLK_NAND | SC_CLKCTRL_CLK_SBC | SC_CLKCTRL_CLK_PERI; + tmp |= SC_CLKCTRL_CEN_ETHER | SC_CLKCTRL_CEN_MIO | SC_CLKCTRL_CEN_UMC +| SC_CLKCTRL_CEN_NAND | SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI; writel(tmp, SC_CLKCTRL); readl(SC_CLKCTRL); /* dummy read */ } diff --git a/arch/arm/mach-uniphier/ph1-pro4/lowlevel_debug.S b/arch/arm/mach-uniphier/ph1-pro4/lowlevel_debug.S index 45aef7a..fcaf6d1 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/lowlevel_debug.S +++ b/arch/arm/mach-uniphier/ph1-pro4/lowlevel_debug.S @@ -17,7 +17,7 @@ ENTRY(setup_lowlevel_debug) ldr r0, =SC_CLKCTRL ldr r1, [r0] - orr r1, r1, #SC_CLKCTRL_CLK_PERI + orr r1, r1, #SC_CLKCTRL_CEN_PERI str r1, [r0] init_debug_uart r0, r1, r2 diff --git a/arch/arm/mach-uniphier/ph1-sld8/clkrst_init.c b/arch/arm/mach-uniphier/ph1-sld8/clkrst_init.c index 6a9d144..eaa45f9 100644 --- a/arch/arm/mach-uniphier/ph1-sld8/clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-sld8/clkrst_init.c @@ -22,8 +22,8 @@ void clkrst_init(void) /* privide clocks */ tmp = readl(SC_CLKCTRL); - tmp |= SC_CLKCTRL_CLK_ETHER | SC_CLKCTRL_CLK_MIO | SC_CLKCTRL_CLK_UMC -| SC_CLKCTRL_CLK_NAND | SC_CLKCTRL_CLK_SBC | SC_CLKCTRL_CLK_PERI; + tmp |= SC_CLKCTRL_CEN_ETHER | SC_CLKCTRL_CEN_MIO | SC_CLKCTRL_CEN_UMC +| SC_CLKCTRL_CEN_NAND | SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI; writel(tmp, SC_CLKCTRL); readl(SC_CLKCTRL); /* dummy read */ } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/5] arm: spl: Avoid setting up a duplicate global data structure
This is already set up in crt0.S. We don't need a new structure and don't
really want one in the 'data' section of the image, since it will be empty
and crt0.S's changes will be ignored.
As an interim measure, remove it only if CONFIG_DM is not defined. This
allows us to press ahead with driver model in SPL and allow the stragglers
to catch up.
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4:
- Squash the gdata revert patch into this one
- Allow gdata to survive unless CONFIG_DM is defined, for now
Changes in v3: None
Changes in v2:
- Remove gdata definition from ARM spl header file also
arch/arm/include/asm/spl.h | 2 ++
arch/arm/lib/spl.c | 4
2 files changed, 6 insertions(+)
diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h
index 17b6f54..6db405d 100644
--- a/arch/arm/include/asm/spl.h
+++ b/arch/arm/include/asm/spl.h
@@ -37,6 +37,8 @@ void spl_board_load_image(void);
/* Linker symbols. */
extern char __bss_start[], __bss_end[];
+#ifndef CONFIG_DM
extern gd_t gdata;
+#endif
#endif
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index c41850a..bd8c7d2 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -13,6 +13,7 @@
#include
#include
+#ifndef CONFIG_DM
/* Pointer to as well as the global data structure for SPL */
DECLARE_GLOBAL_DATA_PTR;
@@ -21,6 +22,7 @@ DECLARE_GLOBAL_DATA_PTR;
* pafches that rely on it. The global_data area is set up in crt0.S.
*/
gd_t gdata __attribute__ ((section(".data")));
+#endif
/*
* In the context of SPL, board_init_f must ensure that any clocks/etc for
@@ -33,8 +35,10 @@ void __weak board_init_f(ulong dummy)
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
+#ifndef CONFIG_DM
/* TODO: Remove settings of the global data pointer here */
gd = &gdata;
+#endif
board_init_r(NULL, 0);
}
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 07/26] ARM: UniPhier: fix comments in PH1-Pro4 SBC code
Signed-off-by: Masahiro Yamada --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/mach-uniphier/ph1-pro4/sbc_init.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c b/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c index 37acfb5..6940559 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c +++ b/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2011-2014 Panasonic Corporation + * Copyright (C) 2011-2015 Panasonic Corporation * Author: Masahiro Yamada * * SPDX-License-Identifier:GPL-2.0+ @@ -35,8 +35,8 @@ void sbc_init(void) /* * Boot Swap Off: boot from mask ROM * 0x-0x01ff: mask ROM -* 0x0200-0x3eff: memory bank (31MB) -* 0x03f0-0x3fff: peripherals (1MB) +* 0x0200-0x03ef: memory bank (31MB) +* 0x03f0-0x03ff: peripherals (1MB) */ writel(0xbe01, SBBASE0); /* dummy */ writel(0x0200be01, SBBASE1); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 08/26] ARM: UniPhier: fix SBC init code
Now UniPhier SoCs only work with CONFIG_SPL and the function
sbc_init() is called from SPL.
The conditional #if !defined(CONFIG_SPL_BUILD) has no point
any more.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/mach-uniphier/ph1-ld4/sbc_init.c | 11 +--
arch/arm/mach-uniphier/ph1-pro4/sbc_init.c | 10 +-
arch/arm/mach-uniphier/ph1-sld8/sbc_init.c | 28 ++--
3 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
b/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
index f44195d..374a8c0 100644
--- a/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
+++ b/arch/arm/mach-uniphier/ph1-ld4/sbc_init.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2011-2014 Panasonic Corporation
+ * Copyright (C) 2011-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -25,13 +25,12 @@ void sbc_init(void)
writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL12);
writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL14);
-#if !defined(CONFIG_SPL_BUILD)
/* XECS0: boot/sub memory (boot swap = off/on) */
writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL00);
writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL01);
writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL02);
writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL04);
-#endif
+
/* XECS3: peripherals */
writel(SBCTRL0_SAVEPIN_PERI_VALUE, SBCTRL30);
writel(SBCTRL1_SAVEPIN_PERI_VALUE, SBCTRL31);
@@ -43,9 +42,9 @@ void sbc_init(void)
writel(0x0400bc01, SBBASE1);
writel(0x0800bf01, SBBASE3);
-#if !defined(CONFIG_SPL_BUILD)
/* enable access to sub memory when boot swap is on */
- sg_set_pinsel(155, 1); /* PORT24 -> XECS0 */
-#endif
+ if (boot_is_swapped())
+ sg_set_pinsel(155, 1); /* PORT24 -> XECS0 */
+
sg_set_pinsel(156, 1); /* PORT25 -> XECS3 */
}
diff --git a/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c
b/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c
index 6940559..4cc5e75 100644
--- a/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c
+++ b/arch/arm/mach-uniphier/ph1-pro4/sbc_init.c
@@ -42,13 +42,12 @@ void sbc_init(void)
writel(0x0200be01, SBBASE1);
}
#elif defined(CONFIG_DCC_MICRO_SUPPORT_CARD)
-#if !defined(CONFIG_SPL_BUILD)
/* XECS0: boot/sub memory (boot swap = off/on) */
writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL00);
writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL01);
writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL02);
writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL04);
-#endif
+
/* XECS1: sub/boot memory (boot swap = off/on) */
writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL10);
writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL11);
@@ -65,9 +64,10 @@ void sbc_init(void)
writel(0x0400bc01, SBBASE1); /* sub memory */
writel(0x0800bf01, SBBASE3); /* peripherals */
-#if !defined(CONFIG_SPL_BUILD)
- sg_set_pinsel(318, 5); /* PORT22 -> XECS0 */
-#endif
+ /* enable access to sub memory when boot swap is on */
+ if (boot_is_swapped())
+ sg_set_pinsel(318, 5); /* PORT22 -> XECS0 */
+
sg_set_pinsel(313, 5); /* PORT15 -> XECS3 */
writel(0x0001, SG_LOADPINCTRL);
diff --git a/arch/arm/mach-uniphier/ph1-sld8/sbc_init.c
b/arch/arm/mach-uniphier/ph1-sld8/sbc_init.c
index febd0e4..fdef88e 100644
--- a/arch/arm/mach-uniphier/ph1-sld8/sbc_init.c
+++ b/arch/arm/mach-uniphier/ph1-sld8/sbc_init.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2011-2014 Panasonic Corporation
+ * Copyright (C) 2011-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -19,18 +19,18 @@ void sbc_init(void)
tmp &= 0xfcff;
writel(tmp, PC0CTRL);
-#if !defined(CONFIG_SPL_BUILD)
- /* XECS0 : dummy */
- writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL00);
- writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL01);
- writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL02);
- writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL04);
-#endif
- /* XECS1 : boot memory (always boot swap = on) */
- writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL10);
- writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL11);
- writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL12);
- writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL14);
+ /*
+* SBCTRL0* does not need settings because PH1-sLD8 has no support for
+* XECS0. The boot swap must be enabled to boot from the support card.
+*/
+
+ if (boot_is_swapped()) {
+ /* XECS1 : boot memory if boot swap is on */
+ writel(SBCTRL0_SAVEPIN_MEM_VALUE, SBCTRL10);
+ writel(SBCTRL1_SAVEPIN_MEM_VALUE, SBCTRL11);
+ writel(SBCTRL2_SAVEPIN_MEM_VALUE, SBCTRL12);
+ writel(SBCTRL4_SAVEPIN_MEM_VALUE, SBCTRL14);
+ }
/* XECS4 : sub memory */
writel(SBCTRL0_SAVEPIN_MEM_
[U-Boot] [PATCH v5 0/26] ARM: UniPhier: bug fixes, refactorings and new features
This series contains:
- bug fixes and refactoring of SBC init code
- add missing reset controls
- support 1CS support card for all the SoCs
- add xHCI driver
Masahiro Yamada (26):
ARM: UniPhier: move SoC sources to mach-uniphier
ARM: UniPhier: move SoC headers to mach-uniphier/include/mach
ARM: UniPhier: include instead of
ARM: UniPhier: update defconfigs using savedefconfig
serial: UniPhier: use 32 bit register access
serial: UniPhier: move LCR register setting to probe function
ARM: UniPhier: fix comments in PH1-Pro4 SBC code
ARM: UniPhier: fix SBC init code
ARM: UniPhier: rename SC_CLKCTRL_CLK_* to SC_SCLKCTRL_CEN_*
ARM: UniPhier: split clkrst_init() into two functions
ARM: UniPhier: reset NAND core in SPL for non-NAND boot mode
ARM: UniPhier: enable STDMAC for EHCI
ARM: UniPhier: remove EHCI platform devices
ARM: UniPhier: move uniphier_ehci_reset() function
ARM: UniPhier: replace "usb-ehci" with "generic-ehci"
ARM: UniPhier: add I/O pin settings for xHCI on PH1-Pro4
ARM: UniPhier: enable xHCI and GIO cores for PH1-Pro4
ARM: UniPhier: add xHCI device nodes to PH1-Pro4 device tree
usb: UniPhier: add UniPhier on-chip xHCI host driver support
ARM: UniPhier: switch to xHCI for PH1-Pro4
ARM: UniPhier: support 1CS support card for all the UniPhier SoCs
ARM: UniPhier: switch to 1CS support card
ARM: UniPhier: consolidate MEMCONF setting code
ARM: UniPhier: remove stop_mpll() from PH1-Pro4 PLL initialization
ARM: UniPhier: remove SSC_WAY_SIZE and SSC_NUM_ENTRIES macros
ARM: UniPhier: move CONFIG_SYS_TEXT_BASE to Kconfig
Kconfig| 2 +-
MAINTAINERS| 3 +-
arch/arm/Kconfig | 2 +-
arch/arm/Makefile | 1 +
arch/arm/cpu/armv7/Makefile| 1 -
arch/arm/cpu/armv7/uniphier/ph1-ld4/sg_init.c | 28 -
arch/arm/cpu/armv7/uniphier/ph1-pro4/clkrst_init.c | 29 -
arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c| 75 -
arch/arm/cpu/armv7/uniphier/ph1-pro4/sg_init.c | 28 -
arch/arm/cpu/armv7/uniphier/ph1-sld8/clkrst_init.c | 29 -
arch/arm/dts/uniphier-ph1-ld4.dtsi | 8 +-
arch/arm/dts/uniphier-ph1-pro4-ref.dts | 5 +-
arch/arm/dts/uniphier-ph1-pro4.dtsi| 22 +++-
arch/arm/dts/uniphier-ph1-sld3.dtsi| 10 +-
arch/arm/dts/uniphier-ph1-sld8.dtsi| 8 +-
arch/arm/include/asm/arch-uniphier/ehci-uniphier.h | 33 --
.../{cpu/armv7/uniphier => mach-uniphier}/Kconfig | 3 +
.../{cpu/armv7/uniphier => mach-uniphier}/Makefile | 1 +
.../uniphier => mach-uniphier}/board_common.c | 2 +-
.../board_early_init_f.c | 9 +-
.../board_early_init_r.c | 2 +-
.../uniphier => mach-uniphier}/board_late_init.c | 0
.../uniphier => mach-uniphier}/cache_uniphier.c| 2 +-
.../armv7/uniphier => mach-uniphier}/cmd_ddrphy.c | 2 +-
.../armv7/uniphier => mach-uniphier}/cmd_pinmon.c | 4 +-
.../armv7/uniphier => mach-uniphier}/cpu_info.c| 2 +-
.../uniphier => mach-uniphier}/ddrphy_training.c | 2 +-
.../armv7/uniphier => mach-uniphier}/dram_init.c | 0
.../include/mach}/arm-mpcore.h | 0
.../include/mach}/bcu-regs.h | 0
.../include/mach}/board.h | 0
.../include/mach}/boot-device.h| 0
.../include/mach}/ddrphy-regs.h| 0
.../include/mach}/debug-uart.S | 0
.../include/mach}/led.h| 0
.../include/mach}/mio-regs.h | 0
.../include/mach}/platdevice.h | 2 -
.../include/mach}/sbc-regs.h | 0
.../include/mach}/sc-regs.h| 29 +++--
.../include/mach}/sg-regs.h| 119 +
.../include/mach}/ssc-regs.h | 2 -
.../include/mach}/umc-regs.h | 0
.../uniphier => mach-uniphier}/init_page_table.S | 0
.../uniphier => mach-uniphier}/lowlevel_init.S | 16 +--
arch/arm/mach-uniphier/memconf.c | 104 ++
.../ph1-pro4 => mach-uniphier/ph1-ld4}/Makefile| 6 +-
.../uniphier => mach-uniphier}/ph1-ld4/bcu_init.c | 2 +-
.../uniphier => mach-uniphier}/ph1-ld4/boot-mode.c | 0
arch/arm/mach-uniphier/ph1-ld4/clkrst_init.c | 42
.../ph1-ld4/ddrphy_init.c | 2 +-
arch/arm/mach-uniphier/ph1-ld4/early_clkrst_init.c | 1 +
.../ph1-ld4/lowlevel_debug.S | 4 +-
.../uniphier => mach-uniphier}/ph1-ld4/pinctrl.c | 2 +-
.../ph1-ld4/platdevice.c | 16 +--
.../uniphier => mach-uniphier}/ph1-ld4/pll_init.c | 4 +-
.../ph1-ld4/
[U-Boot] [PATCH v5 06/26] serial: UniPhier: move LCR register setting to probe function
We do not have to set the LCR register every time we change the
baud-rate. We just need to set it up once in the probe function.
Signed-off-by: Masahiro Yamada
---
Changes in v5:
- Newly addd
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/serial/serial_uniphier.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/serial/serial_uniphier.c b/drivers/serial/serial_uniphier.c
index 327e0dc..a6bd27f 100644
--- a/drivers/serial/serial_uniphier.c
+++ b/drivers/serial/serial_uniphier.c
@@ -45,12 +45,6 @@ static int uniphier_serial_setbrg(struct udevice *dev, int
baudrate)
struct uniphier_serial __iomem *port = uniphier_serial_port(dev);
const unsigned int mode_x_div = 16;
unsigned int divisor;
- u32 tmp;
-
- tmp = readl(&port->lcr_mcr);
- tmp &= ~LCR_MASK;
- tmp |= UART_LCR_WLEN8 << LCR_SHIFT;
- writel(tmp, &port->lcr_mcr);
divisor = DIV_ROUND_CLOSEST(plat->uartclk, mode_x_div * baudrate);
@@ -93,14 +87,22 @@ static int uniphier_serial_pending(struct udevice *dev,
bool input)
static int uniphier_serial_probe(struct udevice *dev)
{
+ u32 tmp;
struct uniphier_serial_private_data *priv = dev_get_priv(dev);
struct uniphier_serial_platform_data *plat = dev_get_platdata(dev);
+ struct uniphier_serial __iomem *port;
- priv->membase = map_sysmem(plat->base, sizeof(struct uniphier_serial));
-
- if (!priv->membase)
+ port = map_sysmem(plat->base, sizeof(struct uniphier_serial));
+ if (!port)
return -ENOMEM;
+ priv->membase = port;
+
+ tmp = readl(&port->lcr_mcr);
+ tmp &= ~LCR_MASK;
+ tmp |= UART_LCR_WLEN8 << LCR_SHIFT;
+ writel(tmp, &port->lcr_mcr);
+
return 0;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 02/26] ARM: UniPhier: move SoC headers to mach-uniphier/include/mach
Move arch/arm/include/asm/arch-uniphier/*
-> arch/arm/mach-uniphier/include/mach/*
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Newly added
Changes in v2: None
MAINTAINERS | 1 -
.../asm/arch-uniphier => mach-uniphier/include/mach}/arm-mpcore.h| 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/bcu-regs.h | 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/board.h| 0
.../asm/arch-uniphier => mach-uniphier/include/mach}/boot-device.h | 0
.../asm/arch-uniphier => mach-uniphier/include/mach}/ddrphy-regs.h | 0
.../asm/arch-uniphier => mach-uniphier/include/mach}/debug-uart.S| 0
.../asm/arch-uniphier => mach-uniphier/include/mach}/ehci-uniphier.h | 0
arch/arm/{include/asm/arch-uniphier => mach-uniphier/include/mach}/led.h | 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/mio-regs.h | 0
.../asm/arch-uniphier => mach-uniphier/include/mach}/platdevice.h| 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/sbc-regs.h | 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/sc-regs.h | 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/sg-regs.h | 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/ssc-regs.h | 0
.../{include/asm/arch-uniphier => mach-uniphier/include/mach}/umc-regs.h | 0
16 files changed, 1 deletion(-)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/arm-mpcore.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/bcu-regs.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/board.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/boot-device.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/ddrphy-regs.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/debug-uart.S (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/ehci-uniphier.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/led.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/mio-regs.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/platdevice.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/sbc-regs.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/sc-regs.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/sg-regs.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/ssc-regs.h (100%)
rename arch/arm/{include/asm/arch-uniphier =>
mach-uniphier/include/mach}/umc-regs.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index f9d1987..5881b38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -163,7 +163,6 @@ M: Masahiro Yamada
S: Maintained
T: git git://git.denx.de/u-boot-uniphier.git
F: arch/arm/mach-uniphier/
-F: arch/arm/include/asm/arch-uniphier/
F: configs/ph1_*_defconfig
N: uniphier
diff --git a/arch/arm/include/asm/arch-uniphier/arm-mpcore.h
b/arch/arm/mach-uniphier/include/mach/arm-mpcore.h
similarity index 100%
rename from arch/arm/include/asm/arch-uniphier/arm-mpcore.h
rename to arch/arm/mach-uniphier/include/mach/arm-mpcore.h
diff --git a/arch/arm/include/asm/arch-uniphier/bcu-regs.h
b/arch/arm/mach-uniphier/include/mach/bcu-regs.h
similarity index 100%
rename from arch/arm/include/asm/arch-uniphier/bcu-regs.h
rename to arch/arm/mach-uniphier/include/mach/bcu-regs.h
diff --git a/arch/arm/include/asm/arch-uniphier/board.h
b/arch/arm/mach-uniphier/include/mach/board.h
similarity index 100%
rename from arch/arm/include/asm/arch-uniphier/board.h
rename to arch/arm/mach-uniphier/include/mach/board.h
diff --git a/arch/arm/include/asm/arch-uniphier/boot-device.h
b/arch/arm/mach-uniphier/include/mach/boot-device.h
similarity index 100%
rename from arch/arm/include/asm/arch-uniphier/boot-device.h
rename to arch/arm/mach-uniphier/include/mach/boot-device.h
diff --git a/arch/arm/include/asm/arch-uniphier/ddrphy-regs.h
b/arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
similarity index 100%
rename from arch/arm/include/asm/arch-uniphier/ddrphy-regs.h
rename to arch/arm/mach-uniphier/include/mach/ddrphy-regs.h
diff --git a/arch/arm/include/asm/arch-uniphier/debug-uart.S
b/arch/arm/mach-uniphier/include/mach/debug-uart.S
similarity index 100%
rename from arch/arm/include/asm/arch-uniphier/debug-uart.S
rename to arch/arm/mach-uniphier/include/mach/debug-uart.S
diff --git a/arch/arm/include/asm/arch-uniphier/ehci-uniphier.h
b/arch/arm/mach-uniphier/include/mach/ehci-uniphier.h
similarity index 100%
rename from arch/arm/include/asm/arch-uniphier/ehci-uniphier.h
rename to arch/arm/mach-uniphier
[U-Boot] [PATCH v5 05/26] serial: UniPhier: use 32 bit register access
For PH1-Pro4, the 8 bit write access to LCR register (offset = 0x11)
is not working correctly. As a side effect, it also modifies MCR
register (offset = 0x10) and results in unexpected behavior.
Signed-off-by: Masahiro Yamada
---
Changes in v5:
- Newly added
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/serial/serial_uniphier.c | 54 +++-
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/serial/serial_uniphier.c b/drivers/serial/serial_uniphier.c
index e8a1608..327e0dc 100644
--- a/drivers/serial/serial_uniphier.c
+++ b/drivers/serial/serial_uniphier.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012-2014 Panasonic Corporation
+ * Copyright (C) 2012-2015 Panasonic Corporation
* Author: Masahiro Yamada
*
* SPDX-License-Identifier:GPL-2.0+
@@ -13,31 +13,25 @@
#include
#include
-#define UART_REG(x)\
- u8 x; \
- u8 postpad_##x[3];
-
/*
* Note: Register map is slightly different from that of 16550.
*/
struct uniphier_serial {
- UART_REG(rbr); /* 0x00 */
- UART_REG(ier); /* 0x04 */
- UART_REG(iir); /* 0x08 */
- UART_REG(fcr); /* 0x0c */
- u8 mcr; /* 0x10 */
- u8 lcr;
- u16 __postpad;
- UART_REG(lsr); /* 0x14 */
- UART_REG(msr); /* 0x18 */
- u32 __none1;
- u32 __none2;
- u16 dlr;
- u16 __postpad2;
+ u32 rx; /* In: Receive buffer */
+#define tx rx /* Out: Transmit buffer */
+ u32 ier;/* Interrupt Enable Register */
+ u32 iir;/* In: Interrupt ID Register */
+ u32 char_fcr; /* Charactor / FIFO Control Register */
+ u32 lcr_mcr;/* Line/Modem Control Register */
+#define LCR_SHIFT 8
+#define LCR_MASK (0xff << (LCR_SHIFT))
+ u32 lsr;/* In: Line Status Register */
+ u32 msr;/* In: Modem Status Register */
+ u32 __rsv0;
+ u32 __rsv1;
+ u32 dlr;/* Divisor Latch Register */
};
-#define thr rbr
-
struct uniphier_serial_private_data {
struct uniphier_serial __iomem *membase;
};
@@ -51,12 +45,16 @@ static int uniphier_serial_setbrg(struct udevice *dev, int
baudrate)
struct uniphier_serial __iomem *port = uniphier_serial_port(dev);
const unsigned int mode_x_div = 16;
unsigned int divisor;
+ u32 tmp;
- writeb(UART_LCR_WLEN8, &port->lcr);
+ tmp = readl(&port->lcr_mcr);
+ tmp &= ~LCR_MASK;
+ tmp |= UART_LCR_WLEN8 << LCR_SHIFT;
+ writel(tmp, &port->lcr_mcr);
divisor = DIV_ROUND_CLOSEST(plat->uartclk, mode_x_div * baudrate);
- writew(divisor, &port->dlr);
+ writel(divisor, &port->dlr);
return 0;
}
@@ -65,20 +63,20 @@ static int uniphier_serial_getc(struct udevice *dev)
{
struct uniphier_serial __iomem *port = uniphier_serial_port(dev);
- if (!(readb(&port->lsr) & UART_LSR_DR))
+ if (!(readl(&port->lsr) & UART_LSR_DR))
return -EAGAIN;
- return readb(&port->rbr);
+ return readl(&port->rx);
}
static int uniphier_serial_putc(struct udevice *dev, const char c)
{
struct uniphier_serial __iomem *port = uniphier_serial_port(dev);
- if (!(readb(&port->lsr) & UART_LSR_THRE))
+ if (!(readl(&port->lsr) & UART_LSR_THRE))
return -EAGAIN;
- writeb(c, &port->thr);
+ writel(c, &port->tx);
return 0;
}
@@ -88,9 +86,9 @@ static int uniphier_serial_pending(struct udevice *dev, bool
input)
struct uniphier_serial __iomem *port = uniphier_serial_port(dev);
if (input)
- return readb(&port->lsr) & UART_LSR_DR;
+ return readl(&port->lsr) & UART_LSR_DR;
else
- return !(readb(&port->lsr) & UART_LSR_THRE);
+ return !(readl(&port->lsr) & UART_LSR_THRE);
}
static int uniphier_serial_probe(struct udevice *dev)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/5] arm: Reduce the scope of lowlevel_init()
This function has grown into something of a monster. Some boards are setting
up a console and DRAM here in SPL. This requires global_data which should be
set up in one place (crt0.S).
There is no need for SPL to use s_init() for anything since board_init_f()
is called immediately afterwards.
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/cpu/armv7/lowlevel_init.S | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/lowlevel_init.S
b/arch/arm/cpu/armv7/lowlevel_init.S
index f1aea05..4803150 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -17,24 +17,27 @@
ENTRY(lowlevel_init)
/*
-* Setup a temporary stack
+* Setup a temporary stack. Global data is not available yet.
*/
ldr sp, =CONFIG_SYS_INIT_SP_ADDR
- bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
-#ifdef CONFIG_SPL_BUILD
- ldr r9, =gdata
-#else
- sub sp, sp, #GD_SIZE
- bic sp, sp, #7
- mov r9, sp
-#endif
+ mov r9, #0
/*
* Save the old lr(passed in ip) and the current lr to stack
*/
push{ip, lr}
/*
-* go setup pll, mux, memory
+* Call the very early init function. This should do only the
+* absolute bare minimum to get started. It should not:
+*
+* - set up DRAM
+* - use global_data
+* - clear BSS
+* - try to start a console
+*
+* For boards with SPL this should be empty since SPL can do all of
+* this init in the SPL board_init_f() function which is called
+* immediately after this.
*/
bl s_init
pop {ip, pc}
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/5] dm: tegra: Enable driver model in SPL and adjust the GPIO driver
Use the full driver model GPIO and serial drivers in SPL now that these are
supported. Since device tree is not available they will use platform data.
Remove the special SPL GPIO function as it is no longer needed.
This is all in one commit to maintain bisectability.
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4:
- Rebase on top of dm/master
Changes in v3:
- Drop extra blank line
Changes in v2:
- Rebase on top of the SPI series
arch/arm/mach-tegra/Kconfig | 3 +++
board/nvidia/seaboard/seaboard.c | 4 +---
drivers/gpio/Makefile| 4
drivers/gpio/tegra_gpio.c| 27 +++
include/configs/tegra-common.h | 6 --
5 files changed, 19 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 8615248..fccfd79 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -29,6 +29,9 @@ config USE_PRIVATE_LIBGCC
config DM
default y
+config SPL_DM
+ default y
+
config DM_SERIAL
default y
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index 11472eb..25480e4 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -20,10 +20,8 @@
void gpio_early_init_uart(void)
{
/* Enable UART via GPIO_PI3 (port 8, bit 3) so serial console works */
-#ifndef CONFIG_SPL_BUILD
gpio_request(GPIO_PI3, NULL);
-#endif
- tegra_spl_gpio_direction_output(GPIO_PI3, 0);
+ gpio_direction_output(GPIO_PI3, 0);
}
#endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index aa11f15..fe9a3b2 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -8,6 +8,10 @@
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_DM_GPIO) += gpio-uclass.o
endif
+/* TODO(s...@chromium.org): Only tegra supports driver model in SPL */
+ifdef CONFIG_TEGRA_GPIO
+obj-$(CONFIG_DM_GPIO) += gpio-uclass.o
+endif
obj-$(CONFIG_AT91_GPIO)+= at91_gpio.o
obj-$(CONFIG_INTEL_ICH6_GPIO) += intel_ich6_gpio.o
diff --git a/drivers/gpio/tegra_gpio.c b/drivers/gpio/tegra_gpio.c
index 43928b8..f870cdb 100644
--- a/drivers/gpio/tegra_gpio.c
+++ b/drivers/gpio/tegra_gpio.c
@@ -132,21 +132,6 @@ static void set_level(unsigned gpio, int high)
writel(u, &bank->gpio_out[GPIO_PORT(gpio)]);
}
-/* set GPIO pin 'gpio' as an output, with polarity 'value' */
-int tegra_spl_gpio_direction_output(int gpio, int value)
-{
- /* Configure as a GPIO */
- set_config(gpio, 1);
-
- /* Configure GPIO output value. */
- set_level(gpio, value);
-
- /* Configure GPIO direction as output. */
- set_direction(gpio, 1);
-
- return 0;
-}
-
/*
* Generic_GPIO primitives.
*/
@@ -338,12 +323,19 @@ static int gpio_tegra_bind(struct udevice *parent)
int bank_count;
int bank;
int ret;
- int len;
/* If this is a child device, there is nothing to do here */
if (plat)
return 0;
+ /* TODO(s...@chromium.org): Remove once SPL supports device tree */
+#ifdef CONFIG_SPL_BUILD
+ ctlr = (struct gpio_ctlr *)NV_PA_GPIO_BASE;
+ bank_count = TEGRA_GPIO_BANKS;
+#else
+ {
+ int len;
+
/*
* This driver does not make use of interrupts, other than to figure
* out the number of GPIO banks
@@ -353,6 +345,8 @@ static int gpio_tegra_bind(struct udevice *parent)
bank_count = len / 3 / sizeof(u32);
ctlr = (struct gpio_ctlr *)fdtdec_get_addr(gd->fdt_blob,
parent->of_offset, "reg");
+ }
+#endif
for (bank = 0; bank < bank_count; bank++) {
int port;
@@ -388,4 +382,5 @@ U_BOOT_DRIVER(gpio_tegra) = {
.probe = gpio_tegra_probe,
.priv_auto_alloc_size = sizeof(struct tegra_port_info),
.ops= &gpio_tegra_ops,
+ .flags = DM_FLAG_PRE_RELOC,
};
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index 005fc6a..fa6ccc1 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -43,13 +43,7 @@
/*
* NS16550 Configuration
*/
-#ifdef CONFIG_SPL_BUILD
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE(-4)
-#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
-#else
#define CONFIG_TEGRA_SERIAL
-#endif
#define CONFIG_SYS_NS16550
/*
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 5/5] Make export interface support CONFIG_SYS_MALLOC_SIMPLE
When CONFIG_SYS_MALLOC_SIMPLE is defined, free() is a static inline. Make sure that the export interface still builds in this case. Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: - Add new patch to make the export interface support CONFIG_SYS_MALLOC_SIMPLE Changes in v3: None Changes in v2: None include/_exports.h | 2 ++ include/exports.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/include/_exports.h b/include/_exports.h index 5944703..279017e 100644 --- a/include/_exports.h +++ b/include/_exports.h @@ -23,7 +23,9 @@ EXPORT_FUNC(dummy, void, free_hdlr, void) #endif EXPORT_FUNC(malloc, void *, malloc, size_t) +#ifndef CONFIG_SYS_MALLOC_SIMPLE EXPORT_FUNC(free, void, free, void *) +#endif EXPORT_FUNC(udelay, void, udelay, unsigned long) EXPORT_FUNC(get_timer, unsigned long, get_timer, unsigned long) EXPORT_FUNC(vprintf, int, vprintf, const char *, va_list) diff --git a/include/exports.h b/include/exports.h index 205affe..1a01e43 100644 --- a/include/exports.h +++ b/include/exports.h @@ -15,7 +15,9 @@ int printf(const char* fmt, ...); void install_hdlr(int, interrupt_handler_t, void*); void free_hdlr(int); void *malloc(size_t); +#ifndef CONFIG_SYS_MALLOC_SIMPLE void free(void*); +#endif void __udelay(unsigned long); unsigned long get_timer(unsigned long); int vprintf(const char *, va_list); -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] usb: ci_udc: Fix set address to work with older controllers
On 02/26/2015 10:03 AM, Alban Bedel wrote: On Tue, 24 Feb 2015 12:25:50 -0700 Stephen Warren wrote: On 02/24/2015 10:41 AM, Alban Bedel wrote: On Tue, 24 Feb 2015 10:00:43 -0700 Stephen Warren wrote: On 02/24/2015 09:44 AM, Alban Bedel wrote: Older controllers don't implement "Device Address Advance" which allow to pass the device address to the controller when it is received. To support such controller we need to store the requested address and only apply it after the next IN transfer completed on EP0. diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c case SETUP(USB_RECIP_DEVICE, USB_REQ_SET_ADDRESS): - /* -* write address delayed (will take effect -* after the next IN txn) -*/ - writel((r.wValue << 25) | (1 << 24), &udc->devaddr); + /* The device address must be updated after the next IN +* request completed */ + controller.set_address = r.wValue; Presumably, bit 24 is the "device address advance" feature? Yes, bit 24 is the "device address advance" feature I'd prefer it if new controllers used the existing code, but we deferred the write only for older controllers that don't support "device address advance". That reduces the possibility of regressions on controller HW that's already working. Presumably, there is some advantage using the new feature, rather than deferring the address change manually, e.g. it solves some race condition? I'm no USB expert, but AFAIU it is only a convenience to make the driver code simpler. I though that having less code path and ifdef would make the whole thing easier to maintain. However if that is preferred I can implement it as you suggested. Is there not a race condition? 1) USB device controller completes the set address's IN transaction (which I assume is the status stage of a control transaction) 2) USB device re-programs address register according to the address that was set 3) USB host controller sends a USB transaction to the new address. (1) must always happen first, but are (2) and (3) always guaranteed to happen in the desired order? I would have assumed the "auto advance" feature was so that the HW could atomically switch to responding to the new address while it completes the set address transaction, to avoid any window where it doesn't respond to the new address. There is such a small window, however it is handled by the standard as the host must wait at least 2 ms after set address, so that shouldn't be a problem. Ah. That should certainly be enough time for your modified code to work then. > However I saw that it should also be possible to unset the address, this is not possible any more with my patch but should be easy to fix. Of course, this is just pure conjecture. The HW solution is a bit better, but it shouldn't make a difference with compliant hosts. I would leave it to the maintainer to choose if we should support both mode or spare some ifdef. One data point that would be very useful - if maintainers of some non-Tegra boards that contain SoCs that contain ci_udc could test your changes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Clean out SPL ready for driver model
Hello Simon, On Thu, 26 Feb 2015 08:57:05 -0700, Simon Glass wrote: > Hi Albert, > > On 26 February 2015 at 03:34, Albert ARIBAUD > wrote: > > Hello Albert, > > > > On Wed, 25 Feb 2015 21:57:36 +0100, Albert ARIBAUD > > wrote: > >> Hello Simon, > >> > >> On Wed, 25 Feb 2015 07:00:23 -0700, Simon Glass > >> wrote: > >> > Hi Albert, > >> > > >> > On 25 February 2015 at 06:27, Simon Glass wrote: > >> > > Hi Albert, > >> > > > >> > > On 24 February 2015 at 23:28, Albert ARIBAUD > >> > > wrote: > >> > >> Hello Simon, > >> > >> > >> > >> I'm a bit (read: almost completely) lost re all the gdata removal > >> > >> stuff; > >> > >> seems like there is/was this series, and there is the 9-patch series > >> > >> too, and possibly others... Right now, what patch( seri)es should be > >> > >> applied exactly? > >> > > > >> > > I picked up everything I thought was relevant and sent a v4 series > >> > > starting here: > >> > > > >> > > http://patchwork.ozlabs.org/patch/438581/ > >> > > > >> > > The cover letter is here: > >> > > > >> > > http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/211429 > >> > > > >> > > So that is all now. > >> > > >> > It does need a rebase due to the mach-tegra file move, but the > >> > conflict is trivial. Just in case, I have updated u-boo-dm/spl-working > >> > with a rebased version. Let me know if I should send v5. > >> > >> No need for a v5 just for the mach-* move IMO. I'll look at v4. > > > > V4 seems not to apply properly on u-boot[-arm]/master ATM. I'll give a > > try at u-boot-dm/spl-working. > > OK, I used mainline and also I rebased so git may have tidied > something up. I can resend if you like. Well, if you can re-send rebase over current u-boot[-arm]/master, that would be nice. :) > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Clean out SPL ready for driver model
Hi Albert, On 26 February 2015 at 10:06, Albert ARIBAUD wrote: > Hello Simon, > > On Thu, 26 Feb 2015 08:57:05 -0700, Simon Glass > wrote: >> Hi Albert, >> >> On 26 February 2015 at 03:34, Albert ARIBAUD >> wrote: >> > Hello Albert, >> > >> > On Wed, 25 Feb 2015 21:57:36 +0100, Albert ARIBAUD >> > wrote: >> >> Hello Simon, >> >> >> >> On Wed, 25 Feb 2015 07:00:23 -0700, Simon Glass >> >> wrote: >> >> > Hi Albert, >> >> > >> >> > On 25 February 2015 at 06:27, Simon Glass wrote: >> >> > > Hi Albert, >> >> > > >> >> > > On 24 February 2015 at 23:28, Albert ARIBAUD >> >> > > wrote: >> >> > >> Hello Simon, >> >> > >> >> >> > >> I'm a bit (read: almost completely) lost re all the gdata removal >> >> > >> stuff; >> >> > >> seems like there is/was this series, and there is the 9-patch series >> >> > >> too, and possibly others... Right now, what patch( seri)es should be >> >> > >> applied exactly? >> >> > > >> >> > > I picked up everything I thought was relevant and sent a v4 series >> >> > > starting here: >> >> > > >> >> > > http://patchwork.ozlabs.org/patch/438581/ >> >> > > >> >> > > The cover letter is here: >> >> > > >> >> > > http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/211429 >> >> > > >> >> > > So that is all now. >> >> > >> >> > It does need a rebase due to the mach-tegra file move, but the >> >> > conflict is trivial. Just in case, I have updated u-boo-dm/spl-working >> >> > with a rebased version. Let me know if I should send v5. >> >> >> >> No need for a v5 just for the mach-* move IMO. I'll look at v4. >> > >> > V4 seems not to apply properly on u-boot[-arm]/master ATM. I'll give a >> > try at u-boot-dm/spl-working. >> >> OK, I used mainline and also I rebased so git may have tidied >> something up. I can resend if you like. > > Well, if you can re-send rebase over current u-boot[-arm]/master, that > would be nice. :) But that doesn't include Masahiro's SPL config change, so it doesn't build. Can you either resync to mainline, or I can apply via the driver model tree if you add your Ack. I will send v5 just so that it is clean. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad colors on BMP display on LCD
Hi Guillaume, which imageformat (bpp) do you have? which u-boot framebuffer driver is used ? best regards, HAnnes On 2015-02-26 17:52, Guillaume Gardet wrote: Hi, I am trying to display a BMP image on a Samsung Chromebook (snow), but I get wrong colors. The image is displayed but colors are bad. I used my own image and images provided in tools/logos/ folder, thay are all ok on the Sabrelite board (HDMI output) but displayed in bad colors on the samsung chromebook (LCD screen). What could be wrong? What am I missing? Guillaume ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] mx6sabre: Enable User Mass Storage
User Mass Storage is very useful for flashing the on-board eMMC. Add support for it. Signed-off-by: Fabio Estevam --- Changes since v1: - Remove EXT2/EXT4 and BOUNCE_BUFFER support include/configs/mx6sabre_common.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index f0f721e..337b865 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -279,4 +279,18 @@ #define CONFIG_IMX_HDMI #define CONFIG_IMX_VIDEO_SKIP +#define CONFIG_CI_UDC +#define CONFIG_USBD_HS +#define CONFIG_USB_GADGET_DUALSPEED + +#define CONFIG_USB_GADGET +#define CONFIG_CMD_USB_MASS_STORAGE +#define CONFIG_USB_GADGET_MASS_STORAGE +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_USB_GADGET_VBUS_DRAW2 + +#define CONFIG_G_DNL_VENDOR_NUM0x0525 +#define CONFIG_G_DNL_PRODUCT_NUM 0xa4a5 +#define CONFIG_G_DNL_MANUFACTURER "FSL" + #endif /* __MX6QSABRE_COMMON_CONFIG_H */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] usb: ci_udc: Fix set address to work with older controllers
On Tue, 24 Feb 2015 12:25:50 -0700 Stephen Warren wrote: > On 02/24/2015 10:41 AM, Alban Bedel wrote: > > On Tue, 24 Feb 2015 10:00:43 -0700 > > Stephen Warren wrote: > > > >> On 02/24/2015 09:44 AM, Alban Bedel wrote: > >>> Older controllers don't implement "Device Address Advance" which allow > >>> to pass the device address to the controller when it is received. > >>> To support such controller we need to store the requested address and > >>> only apply it after the next IN transfer completed on EP0. > >> > >>> diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c > >> > >>> case SETUP(USB_RECIP_DEVICE, USB_REQ_SET_ADDRESS): > >>> - /* > >>> - * write address delayed (will take effect > >>> - * after the next IN txn) > >>> - */ > >>> - writel((r.wValue << 25) | (1 << 24), &udc->devaddr); > >>> + /* The device address must be updated after the next IN > >>> + * request completed */ > >>> + controller.set_address = r.wValue; > >> > >> Presumably, bit 24 is the "device address advance" feature? > > > > Yes, bit 24 is the "device address advance" feature > > > >> I'd prefer it if new controllers used the existing code, but we deferred > >> the write only for older controllers that don't support "device address > >> advance". That reduces the possibility of regressions on controller HW > >> that's already working. Presumably, there is some advantage using the > >> new feature, rather than deferring the address change manually, e.g. it > >> solves some race condition? > > > > I'm no USB expert, but AFAIU it is only a convenience to make the > > driver code simpler. I though that having less code path and ifdef > > would make the whole thing easier to maintain. However if that is > > preferred I can implement it as you suggested. > > Is there not a race condition? > > 1) USB device controller completes the set address's IN transaction > (which I assume is the status stage of a control transaction) > > 2) USB device re-programs address register according to the address that > was set > > 3) USB host controller sends a USB transaction to the new address. > > (1) must always happen first, but are (2) and (3) always guaranteed to > happen in the desired order? I would have assumed the "auto advance" > feature was so that the HW could atomically switch to responding to the > new address while it completes the set address transaction, to avoid any > window where it doesn't respond to the new address. There is such a small window, however it is handled by the standard as the host must wait at least 2 ms after set address, so that shouldn't be a problem. However I saw that it should also be possible to unset the address, this is not possible any more with my patch but should be easy to fix. > Of course, this is just pure conjecture. The HW solution is a bit better, but it shouldn't make a difference with compliant hosts. I would leave it to the maintainer to choose if we should support both mode or spare some ifdef. Alban signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Bad colors on BMP display on LCD
Hi, I am trying to display a BMP image on a Samsung Chromebook (snow), but I get wrong colors. The image is displayed but colors are bad. I used my own image and images provided in tools/logos/ folder, thay are all ok on the Sabrelite board (HDMI output) but displayed in bad colors on the samsung chromebook (LCD screen). What could be wrong? What am I missing? Guillaume ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] mx6sabre: Select BOUNCE_BUFFER and CMD_EXT options
Add EXT2/EXT4 and BOUNCE_BUFFER support. Signed-off-by: Fabio Estevam --- Changes since v1: - Newly introduced in this series include/configs/mx6sabre_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index 337b865..67d74d0 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -56,6 +56,8 @@ #define CONFIG_GENERIC_MMC #define CONFIG_BOUNCE_BUFFER #define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_EXT4_WRITE #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 0/11] ARM: OMAP3-DRA7: CP15 erratum workarounds and improvements
On Thu, 26 Feb 2015 08:50:09 -0600 Nishanth Menon wrote: > On Thu, Feb 26, 2015 at 1:40 AM, Siarhei Siamashka > wrote: > > On Wed, 25 Feb 2015 14:55:08 -0600 > > Nishanth Menon wrote: > > > >> Hi, > >> > >> The third incarnation of this series to address various ideas of > >> previous V2 series. I will skip the full blurb and point to V1/V2 > >> links for the usual blurb. > >> > >> Changes since V2: > >> - Added documentation revisioning info with ARM erratums > >> - patch series are split up to address ARM erratums first followed > >> by TI > >> OMAP conversion > >> - More OMAP3 now get erratum implementation - had to redo rx51 a > >> little > >> - I think is better helps exynos: > >> https://patchwork.ozlabs.org/patch/443271/ > >> https://patchwork.ozlabs.org/patch/441863/ > >> - Rearranged the series to address generic ARM first followed by > >> rest. > >> > >> V2: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/213060 > >> V1: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/212174 > >> > >> Nishanth Menon (10): > >> ARM: Introduce erratum workaround for 798870 > >> ARM: Introduce erratum workaround for 454179 > >> ARM: Introduce erratum workaround for 430973 > >> ARM: Introduce erratum workaround for 621766 > >> ARM: OMAP: Change set_pl310_ctrl_reg to be generic > >> ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs > >> ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with > >> omap_smc1 > >> ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended > >> configuration > >> ARM: OMAP3: Enable workaround for ARM errata 454179, 430973, 621766 > >> ARM: OMAP3: rx51: Enable workaround for ARM errata 454179, 430973, > >> 621766 > >> > >> Praveen Rao (1): > >> ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870 > > > > Could you perhaps also pick up a workaround for "725233: PLD > > instructions executed with PLD data forwarding enabled can result > > in a processor deadlock" for old OMAP3 (r1pX revision of Cortex-A8)? > > > > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=041d42e789aba20296ffcde92173f100a9592880 > > > > This used to be in U-Boot earlier, but seems to have vanished from the > > current U-Boot code. I would probably submit a patch myself, but I > > don't have such hardware anymore to test it. > > Could I have a review by - I think I screwed up r1-r3 handling in > start.S when multiple erratas are enabled - which by some luck, I > have'nt hit.. I should probably fix that. Sadly, I don't have this old hardware anymore. I have lent my first generation beagleboard to another person several years ago and have no idea where it is now. Maybe I should try to get it back one day :) But taking the "formal" route, I checked who is the current beagleboard maintainer and looks like that's Tom Rini, who is already quite conveniently in the CC ;-) Basically, this old hardware is either maintained or not. If it is maintained, then probably the board maintainer is the best person to review and test the errata patches. > I will hold off adding more erratas or changes for now and look for > the current series getting in.. in fact, I am tempted to remove omap3 > entirely from this list for now, given the multiple platforms impacted > and unless folks are willing to help test those, I am more than happy > to just focus on a15 erratum in the first series which benefits my > immediate needs and potentially helping exynos as well. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Clean out SPL ready for driver model
Hi Albert, On 26 February 2015 at 03:34, Albert ARIBAUD wrote: > Hello Albert, > > On Wed, 25 Feb 2015 21:57:36 +0100, Albert ARIBAUD > wrote: >> Hello Simon, >> >> On Wed, 25 Feb 2015 07:00:23 -0700, Simon Glass >> wrote: >> > Hi Albert, >> > >> > On 25 February 2015 at 06:27, Simon Glass wrote: >> > > Hi Albert, >> > > >> > > On 24 February 2015 at 23:28, Albert ARIBAUD >> > > wrote: >> > >> Hello Simon, >> > >> >> > >> I'm a bit (read: almost completely) lost re all the gdata removal stuff; >> > >> seems like there is/was this series, and there is the 9-patch series >> > >> too, and possibly others... Right now, what patch( seri)es should be >> > >> applied exactly? >> > > >> > > I picked up everything I thought was relevant and sent a v4 series >> > > starting here: >> > > >> > > http://patchwork.ozlabs.org/patch/438581/ >> > > >> > > The cover letter is here: >> > > >> > > http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/211429 >> > > >> > > So that is all now. >> > >> > It does need a rebase due to the mach-tegra file move, but the >> > conflict is trivial. Just in case, I have updated u-boo-dm/spl-working >> > with a rebased version. Let me know if I should send v5. >> >> No need for a v5 just for the mach-* move IMO. I'll look at v4. > > V4 seems not to apply properly on u-boot[-arm]/master ATM. I'll give a > try at u-boot-dm/spl-working. OK, I used mainline and also I rebased so git may have tidied something up. I can resend if you like. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl_mem_init.c : Added support for mDDR in SPL for i.MX28
Hi Marco,
On Mon, Feb 23, 2015 at 11:34 AM, Marco Cavallini
wrote:
Please provide a commit log.
> Signed-off-by: Marco Cavallini
> ---
> arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> index a744e5d..9e11288 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> @@ -315,9 +315,27 @@ static void mx28_mem_init(void)
>
> debug("SPL: Initialising mx28 SDRAM Controller\n");
>
> +#ifndef CONFIG_SYS_MXS_mDDR
Currently there is no user for this config option.
I suggest that you document it and add a board that makes use of it.
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv8: Bug fix of dcache_disable()
hi Mark, You did very detailed analysis of the cache beheaviour. Yes, this patch is not perfect. But it did fix the actually existed bug. I will try to describe it more clearly in the following. > -Original Messages- > From: "Mark Rutland" > Sent Time: 2015-02-11 23:51:15 (Wednesday) > To: FengHua > Cc: "u-boot@lists.denx.de" , "albert.u.boot" > > Subject: Re: Re: [U-Boot] [PATCH] ARMv8: Bug fix of dcache_disable() > > On Wed, Feb 11, 2015 at 03:26:06AM +, FengHua wrote: > > > > hi Mark, > > Thank you review this patch. > > > > > -Original Messages- > > > From: "Mark Rutland" > > > Sent Time: 2015-02-09 19:05:54 (Monday) > > > To: "feng...@phytium.com.cn" > > > Cc: "u-boot@lists.denx.de" > > > Subject: Re: [U-Boot] [PATCH] ARMv8: Bug fix of dcache_disable() > > > > > > On Mon, Feb 09, 2015 at 08:51:59AM +, feng...@phytium.com.cn wrote: > > > > From: David Feng > > > > > > > > The cache disable operation shoud be performed after flush_dcache_all(). > > > > If cache disable operation is performed before > > > > flush_dcache_all(), flush_dcache_all() store data directly to memory > > > > and may be overrided by data copy in cache. > > > > > > The reasoning above (and hence this patch) is wrong. > > > > > > While the caches are on, they can allocate lines for any portion of the > > > address space with cacheable attributes, and can acquire dirty cache > > > lines from other CPUs. Additionally, there is no restriction preventing > > > lines from migrating between levels of cache while they are active. > > > > > > So calling flush_dcache_all (which performs maintenance by Set/Way) > > > while the caches are enabled is wrong. Per the architecture it provides > > > no guarantee whatsoever. > > > > > > To empty the caches by Set/Way, they must first be disabled. Note that > > > this only guarantees that the caches are empty; not where the data went. > > > Other CPUs might acquire dirty lines, or the data might only reach a > > > system cache rather than memory. > > > > > > If you need certain portions of data to be flushed out to memory, then > > > those must be flushed by VA. If flush_dcache_all performs any memory > > > accesses before it has completed Set/Way maintenance, it is buggy. > > > > > > Thanks, > > > Mark. > > You are right. If data acess exist when flushing cache when cache is > > enabled, > > the data may be brought to cache again. In normal circumstance we can not do > > like this. > > But the problem is flush_dcahe_all is a C routine, it will preserve return > > address in stack. If disable cache first the return address will be directly > > store in memory, and if the stack has a copy in cache the data will be > > covered > > when flushing cache, then flush_dcache_all will get wrong return address. > > > > There should be no data access between disabling cache and flushing cache. > > U-boot for aarch64 runs at only one processor and the data flush_dcache_all > > manipulated > > will not be used by following routines. By simply adjusting the sequence > > can fix this > > bug although it's not the best solution. > > I don't follow: > > * The compiler may generate writes between flush_dcache_all and > set_sctlr (even in the absence of any explicit writes in source code), > so the cache might allocate dirty lines that could be written back > asynchronously later (when the cache id sieabled), clobbering data we > are using. Yes, the memory access between flush_dcache_all and set_sctlr is why we talk about this here. If no memory access between flush_dcache_all and set_sctlr, there will be no bug. This need the flush_dcache_all is implemented in assembly. > > * The cache can allocate clean lines at any point before it is disabled > (even in the middle of flush_dcache_all), so the cache will almost > certainly not be empty once disabled. It won't write back clean lines, > but these could mask data later if not invalidated. > > * Set/Way operations aren't guaranteed to flush data to the PoC in the > presence of a system cache like CCN, so we have no guarantee that > we've pushed any data to the PoC. Per ARMv8 only maintenance by VA > guarantees this (but luckily maintenance by VA is mandated to be > respected by such system caches). flush_dcache_all should flush both cache existed in architecture defined cache hierachy and outer cache(such as L3 in CCN), a previous patch did this. > > * While the cache is enabled lines could theoretically migrate between > set/way slots mid-sequence (e.g. with speculative accesses and an > exclusive L1/L2 configuration). I don't believe this currently happens > in practice, but the architecture does not prevent this. > > So I don't see that moving this maintenance solves any existing problem, > and it introduces new ones. The bug actually exist when flush_dcache_all is after of set_sctlr. I try to describe it more detailed. flush_dcache_all is a C routine, it will prese
Re: [U-Boot] [PATCH V3 0/11] ARM: OMAP3-DRA7: CP15 erratum workarounds and improvements
On Thu, Feb 26, 2015 at 1:40 AM, Siarhei Siamashka wrote: > On Wed, 25 Feb 2015 14:55:08 -0600 > Nishanth Menon wrote: > >> Hi, >> >> The third incarnation of this series to address various ideas of >> previous V2 series. I will skip the full blurb and point to V1/V2 >> links for the usual blurb. >> >> Changes since V2: >> - Added documentation revisioning info with ARM erratums >> - patch series are split up to address ARM erratums first followed by >> TI >> OMAP conversion >> - More OMAP3 now get erratum implementation - had to redo rx51 a little >> - I think is better helps exynos: >> https://patchwork.ozlabs.org/patch/443271/ >> https://patchwork.ozlabs.org/patch/441863/ >> - Rearranged the series to address generic ARM first followed by rest. >> >> V2: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/213060 >> V1: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/212174 >> >> Nishanth Menon (10): >> ARM: Introduce erratum workaround for 798870 >> ARM: Introduce erratum workaround for 454179 >> ARM: Introduce erratum workaround for 430973 >> ARM: Introduce erratum workaround for 621766 >> ARM: OMAP: Change set_pl310_ctrl_reg to be generic >> ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs >> ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with >> omap_smc1 >> ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended >> configuration >> ARM: OMAP3: Enable workaround for ARM errata 454179, 430973, 621766 >> ARM: OMAP3: rx51: Enable workaround for ARM errata 454179, 430973, >> 621766 >> >> Praveen Rao (1): >> ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870 > > Could you perhaps also pick up a workaround for "725233: PLD > instructions executed with PLD data forwarding enabled can result > in a processor deadlock" for old OMAP3 (r1pX revision of Cortex-A8)? > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=041d42e789aba20296ffcde92173f100a9592880 > > This used to be in U-Boot earlier, but seems to have vanished from the > current U-Boot code. I would probably submit a patch myself, but I > don't have such hardware anymore to test it. Could I have a review by - I think I screwed up r1-r3 handling in start.S when multiple erratas are enabled - which by some luck, I have'nt hit.. I should probably fix that. I will hold off adding more erratas or changes for now and look for the current series getting in.. in fact, I am tempted to remove omap3 entirely from this list for now, given the multiple platforms impacted and unless folks are willing to help test those, I am more than happy to just focus on a15 erratum in the first series which benefits my immediate needs and potentially helping exynos as well. -- --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] added defconfig for Jesurun Q5
Hi, On 26-02-15 12:08, Gábor Nyers wrote: The Jesurun Q5 has a black plastic casing with the approximate dimensions of 100mm x 100mm x 24mm with rounded edges. In terms of hardware it features an Allwinner A10 SoC with 1GB RAM and 8GB of NAND flash. The storage capacity can be extended up to 32GB with a MicroSD card. The external connectors are: 2x USB-A female supporting USB2.0, 3.5mm female jack for audio, HDMI female, SPDIF, RJ45 LAN and Power. In addition the device has 1x red LED (hard wired to power) and an programmable green led. On the board there is also an unpopulated IR receiver and the UART. The devices is equipped with an AXP209 PMU. For more details see: http://linux-sunxi.org/Jesurun_Q5 Signed-off-by: Gábor Nyers Thanks, queued up in u-boot-sunxi/next for merging upstream. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Benoît Thébaudeau-2 wrote > Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm > wondering if it's not set too high, resulting in an overlap of the > pre- and post-relocation addresses occupied by your binary in the > 256-MiB case. BINGO!!! Good catch Benoît, thank you. I changed it from 9FF8 to 9F00 and now it boots. Looking at the original log...it relocated 90KB above text base. Not quite enough room... U-Boot code: 9FF8 -> 9FFA6840 BSS: -> 9FFD944C . Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0 -- On a side note, how involved would it be to convert to 2015.01? I've already ported 3 boards for 2014.07. Will everything I've done work perfectly fine with 2015.01? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206924.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS UHI spec
2015-02-26 11:17 GMT+01:00 Paul Burton : > On Thu, Feb 19, 2015 at 01:50:23PM +, Matthew Fortune wrote: >> Hi Daniel, >> >> The spec for MIPS Unified Hosting Interface is available here: >> >> http://prplfoundation.org/wiki/MIPS_documentation >> >> As we have previously discussed, this is an ideal place to >> define the handover of device tree data from bootloader to >> kernel. Using a0 == -2 and defining which register(s) you >> need for the actual data will fit nicely. I'll happily >> include whatever is decided into the next version of the spec. this originates from an off-list discussion some months ago started by John Crispin. (CC +John, Ralf, Jonas, linux-mips) > > (CC +Andrew, Ezequiel, James, James) > > On the talk of DT handover, this recent patchset adding support for a > system doing so to Linux is relevant: > > http://www.linux-mips.org/archives/linux-mips/2015-02/msg00312.html > > I'm also working on a system for which I'll need to implement DT > handover very soon. It would be very nice if we could agree on some > standard way of doing so (and eventually if the code on the Linux side > can be generic enough to allow a multiplatform kernel). > to be conformant with UHI I propose $a0 == -2 and $a1 == address of DT blob. It is a simple extension and should not interfere with the various legacy boot interfaces. U-Boot mainline code is almost ready for DT handover. I have prepared a patch [1] which completes it by implementing my proposal. [1] http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commitdiff;h=3464e8de491c640d14d72853a741cc367ebabc79 -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAINTAINERS: Add F: drivers/usb/gadget to DFU custodian responsibility
After discussion during the last u-boot mini summit with USB maintainer - Marek Vasut - it has been decided, that gadget development should be coordinated by DFU custodian. Such patch formalizes current development status. Signed-off-by: Lukasz Majewski --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1f77359..7ee87c0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -214,6 +214,7 @@ M: Lukasz Majewski S: Maintained T: git git://git.denx.de/u-boot-dfu.git F: drivers/dfu/ +F: drivers/usb/gadget/ DRIVER MODEL M: Simon Glass -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/12] tegra124: Add PSCI support for Tegra124
On 2015-02-26 10:08, Thierry Reding wrote: > On Wed, Feb 18, 2015 at 09:14:03AM +0100, Jan Kiszka wrote: > [...] >> +ENTRY(psci_cpu_off) >> +bl psci_cpu_off_common >> + >> +mrc p15, 0, r1, c0, c0, 5 @ MPIDR >> +and r1, r1, #7 @ number of CPUs in cluster >> + >> +get_csr_reg r1, r2, r3 >> + >> +ldr r6, =TEGRA_FLOW_CTRL_BASE >> +mov r5, #(CSR_ENABLE) >> +add r5, r1, lsl #CSR_WAIT_WFI_SHIFT > > This puts the wrong value into the WAIT_WFI field. The value of that > field is supposed to be a mask, not the index of the CPU. I've used this > to fix it: > > mov r4, #(1 << CSR_WAIT_WFI_SHIFT) > add r5, r4, lsl r1 > > With that fixed I see that with CPU hotplugging the power partition for > the CPU that's taken offline is gated. To verify: > > # cat /sys/kernel/debug/powergate > # echo 0 > /sys/devices/system/cpu/cpu1/online > # cat /sys/kernel/debug/powergate Ah, good catch. Will include your fix. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] added defconfig for Jesurun Q5
Hans, I've resubmitted the patch with the Sign-off line included. Thanks a lot for your help! Regards, Gábor On Thu, 26 Feb 2015 09:56:58 +0100 Hans de Goede wrote: > Hi Gábor, > > On 26-02-15 00:16, Gábor Nyers wrote: > > The Jesurun Q5 has a black plastic casing with the approximate > > dimensions of 100mm x 100mm x 24mm with rounded edges. In terms of > > hardware it features an Allwinner A10 SoC with 1GB RAM and 8GB of NAND > > flash. The storage capacity can be extended up to 32GB with a MicroSD > > card. The external connectors are: 2x USB-A female supporting USB2.0, > > 3.5mm female jack for audio, HDMI female, SPDIF, RJ45 LAN and Power. In > > addition the device has a red (hard wired to power) and a programmable > > green LED. The pins for the UART are easily located on the PCB. The > > devices is equipped with an AXP209 PMU. > > > > For more details see: http://linux-sunxi.org/Jesurun_Q5 > > You're missing a: > > Signed-off-by: Gábor Nyers > > At the end of you're commit msg here (my bad I forgot that when we > we're discussing how to submit patches). > > Can you please resend with that line added to the end of the commit msg? > > For you're next patch(es) you can do "git commit -s" to make git > automatically add the Signed-off-by. > > Thanks & Regards, > > Hans > > > > --- > > configs/jesurun_q5_defconfig | 9 + > > 1 file changed, 9 insertions(+) > > create mode 100644 configs/jesurun_q5_defconfig > > > > diff --git a/configs/jesurun_q5_defconfig b/configs/jesurun_q5_defconfig > > new file mode 100644 > > index 000..7ef35f2 > > --- /dev/null > > +++ b/configs/jesurun_q5_defconfig > > @@ -0,0 +1,9 @@ > > +CONFIG_SPL=y > > +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_EMAC,USB_EHCI,MACPWR=SUNXI_GPH(19)" > > +CONFIG_FDTFILE="sun4i-a10-jesurun-q5.dtb" > > ++S:CONFIG_ARM=y > > ++S:CONFIG_ARCH_SUNXI=y > > ++S:CONFIG_MACH_SUN4I=y > > ++S:CONFIG_DRAM_CLK=312 > > ++S:CONFIG_DRAM_ZQ=123 > > ++S:CONFIG_DRAM_EMR1=0 > > > -- Gábor Nyers | Sr. Sales Engineer at SUSE mob: +31-6-22-377588 | tel: +31-172-50 | fax: +31-172-505551 address: Raoul Wallenbergplein 23, 2404 ND Alphen a/d Rijn, Netherlands ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] added defconfig for Jesurun Q5
The Jesurun Q5 has a black plastic casing with the approximate dimensions of 100mm x 100mm x 24mm with rounded edges. In terms of hardware it features an Allwinner A10 SoC with 1GB RAM and 8GB of NAND flash. The storage capacity can be extended up to 32GB with a MicroSD card. The external connectors are: 2x USB-A female supporting USB2.0, 3.5mm female jack for audio, HDMI female, SPDIF, RJ45 LAN and Power. In addition the device has 1x red LED (hard wired to power) and an programmable green led. On the board there is also an unpopulated IR receiver and the UART. The devices is equipped with an AXP209 PMU. For more details see: http://linux-sunxi.org/Jesurun_Q5 Signed-off-by: Gábor Nyers --- configs/jesurun_q5_defconfig | 9 + 1 file changed, 9 insertions(+) create mode 100644 configs/jesurun_q5_defconfig diff --git a/configs/jesurun_q5_defconfig b/configs/jesurun_q5_defconfig new file mode 100644 index 000..7ef35f2 --- /dev/null +++ b/configs/jesurun_q5_defconfig @@ -0,0 +1,9 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_EMAC,USB_EHCI,MACPWR=SUNXI_GPH(19)" +CONFIG_FDTFILE="sun4i-a10-jesurun-q5.dtb" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN4I=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=123 ++S:CONFIG_DRAM_EMR1=0 -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Hello Benoît, On Thu, 26 Feb 2015 00:56:00 +0100, Benoît Thébaudeau wrote: > Dear Dave Kucharczyk, > > On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk > wrote: > > Fabio Estevam-2 wrote > >> Also, you said that your 512MB board version works fine, but the 256MB > >> fails. > >> > >> I suppose you are using two different binaries for each board, right? > >> You can't have a single binary for the two boards, unless you use the > >> SPL approach. > > > > Fabio, we use one binary. It has runtime memory discovery via gpio's > > (resistor reads). DRAM size is reported correctly from both boards. It just > > hangs on the 256MB board. > > > > We do not have SPL setup. > > You should try with 2015.01 as Fabio suggested. > > Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm > wondering if it's not set too high, resulting in an overlap of the > pre- and post-relocation addresses occupied by your binary in the > 256-MiB case. /me wonders whether we should not add a test for this situation, with a conspicuous error message on the console stating that relocation will probably fail due to overlap. > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Clean out SPL ready for driver model
Hello Albert, On Wed, 25 Feb 2015 21:57:36 +0100, Albert ARIBAUD wrote: > Hello Simon, > > On Wed, 25 Feb 2015 07:00:23 -0700, Simon Glass > wrote: > > Hi Albert, > > > > On 25 February 2015 at 06:27, Simon Glass wrote: > > > Hi Albert, > > > > > > On 24 February 2015 at 23:28, Albert ARIBAUD > > > wrote: > > >> Hello Simon, > > >> > > >> I'm a bit (read: almost completely) lost re all the gdata removal stuff; > > >> seems like there is/was this series, and there is the 9-patch series > > >> too, and possibly others... Right now, what patch( seri)es should be > > >> applied exactly? > > > > > > I picked up everything I thought was relevant and sent a v4 series > > > starting here: > > > > > > http://patchwork.ozlabs.org/patch/438581/ > > > > > > The cover letter is here: > > > > > > http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/211429 > > > > > > So that is all now. > > > > It does need a rebase due to the mach-tegra file move, but the > > conflict is trivial. Just in case, I have updated u-boo-dm/spl-working > > with a rebased version. Let me know if I should send v5. > > No need for a v5 just for the mach-* move IMO. I'll look at v4. V4 seems not to apply properly on u-boot[-arm]/master ATM. I'll give a try at u-boot-dm/spl-working. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] fastboot: add support for reboot-bootloader command
Hi Alexey,
> The "fastboot reboot-bootloader" command is defined to
> re-enter into fastboot mode after rebooting into
> bootloader. This command is usually used after updating
> bootloader via fastboot.
>
> This commit implements only a generic side of the
> command - setting of the reset flag and then resetting.
> Setting of the reset flag is implemented using __weak
> fb_set_reboot_flag() function. The actual setting and
> checking of the reset flag should be implemented by
> a boot script and/or board/SoC specific code.
>
> Signed-off-by: Alexey Firago
> ---
>
> Changes in v3:
> - return -ENOSYS from default fb_set_reboot_flag()
>
> Changes in v2:
> - return error in default fb_set_reboot_flag()
>
> drivers/usb/gadget/f_fastboot.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/usb/gadget/f_fastboot.c
> b/drivers/usb/gadget/f_fastboot.c index 310175a..a000c25 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -122,6 +122,7 @@ static struct usb_gadget_strings
> *fastboot_strings[] = { };
>
> static void rx_handler_command(struct usb_ep *ep, struct usb_request
> *req); +static int strcmp_l1(const char *s1, const char *s2);
>
> static void fastboot_complete(struct usb_ep *ep, struct usb_request
> *req) {
> @@ -317,8 +318,20 @@ static void compl_do_reset(struct usb_ep *ep,
> struct usb_request *req) do_reset(NULL, 0, 0, NULL);
> }
>
> +int __weak fb_set_reboot_flag(void)
> +{
> + return -ENOSYS;
> +}
> +
> static void cb_reboot(struct usb_ep *ep, struct usb_request *req)
> {
> + char *cmd = req->buf;
> + if (!strcmp_l1("reboot-bootloader", cmd)) {
> + if (fb_set_reboot_flag()) {
> + fastboot_tx_write_str("FAILCannot set reboot
> flag");
> + return;
> + }
> + }
> fastboot_func->in_req->complete = compl_do_reset;
> fastboot_tx_write_str("OKAY");
> }
Applied to u-boot-dfu.
Thanks for patch!
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS UHI spec
On Thu, Feb 19, 2015 at 01:50:23PM +, Matthew Fortune wrote: > Hi Daniel, > > The spec for MIPS Unified Hosting Interface is available here: > > http://prplfoundation.org/wiki/MIPS_documentation > > As we have previously discussed, this is an ideal place to > define the handover of device tree data from bootloader to > kernel. Using a0 == -2 and defining which register(s) you > need for the actual data will fit nicely. I'll happily > include whatever is decided into the next version of the spec. (CC +Andrew, Ezequiel, James, James) On the talk of DT handover, this recent patchset adding support for a system doing so to Linux is relevant: http://www.linux-mips.org/archives/linux-mips/2015-02/msg00312.html I'm also working on a system for which I'll need to implement DT handover very soon. It would be very nice if we could agree on some standard way of doing so (and eventually if the code on the Linux side can be generic enough to allow a multiplatform kernel). Thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] checkarmreloc error for AArch64 (using vexpress_aemv8a_defconfig)
Hi, While building vexpress_aemv8a_defconfig, I get the following error: u-boot contains unexpected relocations: R_AARCH64_ABS64 R_AARCH64_RELATIVE Makefile:1258: recipe for target 'checkarmreloc' failed Should we update the Makefile to handle this case? Or is it a bug somewhere? Guillaume ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on raspberry 2: booting in SVC secure mode
Oh and I don't think there is a TZ Address space controller on the raspberry, or at least I am not aware of any. 2015-02-26 10:32 GMT+01:00 Vincent : > I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE to > 0x0 (with kernel_old=1) does not work: the board display some garbage on > the uart then hangs. The content of the garbage makes me thinks that > nothing is done to handle the four cores in this setting which ends up > badly. I expected this since raspberry's "firmware" only let one core run > free. I think I need to configure U-boot so that it deals with this SMP > scenario (I just don't know how). > > My goal is to use U-boot to load some small homemade baremetal kernels on > the raspberry (using serial or tftp loading), in *secure mode*, so I need > U-boot to stay in secure mode, or at least let me install my own > secure_monitor code before switching to non-secure mode. > > I made a couple attempts of adding secure mode support by adding options > in configs/rpi_2_defconfig but they don't seem to be taken into account. > Where do you suggest I put ARMV7_virt and ARMV7_NONSEC ? > > Best, > Vincent > > 2015-02-26 10:17 GMT+01:00 Andre Przywara : > >> Hi Vincent, >> >> On 26/02/15 08:27, Vincent wrote: >> > Hi, >> > I finally hacked my way through U-boot and I managed to add raspberry's >> > boot code inside U-boot so that it can start as usual when using >> kernel_old >> > = 1. I don't think >> > we want this as a final solution but it made me understand a few things >> > about U-boot architecture (in short: I added a new section located at >> 0x0 >> > which executes raspberry's code, and >> > then jump to the usual _start entry point). I didn't try to modify >> > CONFIG_SYS_TEXT_BASE yet, I'll try this morning. >> > >> > From what I gathered from the source code, I think I have to activate >> some >> > options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot >> starts >> > in secure mode, >> > but adding them to rpi_2_defconfig doesn't seem to change anything in >> > .config, so I'm not sure that my current U-boot is "secure boot aware". >> > Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like >> > that ? >> >> AFAIK you don't need to tell U-Boot that it runs in secure: unless it >> accesses any secure/non-secure specific peripherals it should work fine >> in both modes. >> Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into >> non-sec, but there is no real reason to do so - at least not for Linux. >> >> You should do away with the original Raspi firmware snippet - not only >> from a legal point of view. >> Thanks to Marc U-Boot has now a much better implementation than my >> original HYP-mode switcher, also this gives you PSCI support basically >> for free. So just select ARMV7_VIRT and ARMV7_NONSEC. >> >> Do you know if there is a TrustZone Controller in that SoC? That would >> be needed to guard the resident U-Boot code from the OS. Some SoCs have >> secure on-chip SRAM usable for that purpose, that would do it, too. >> But skimming through the BCM2835 .pdf I don't spot any of those, >> unfortunately. >> >> Cheers, >> Andre. >> >> > >> > 2015-02-25 19:38 GMT+01:00 Stephen Warren : >> > >> >> On 02/25/2015 02:30 AM, Vincent wrote: >> >> >> >>> Hi, >> >>> as explained here http://community.arm.com/message/25127, it is >> possible >> >>> to >> >>> boot the raspberry 2 in secure mode, by adding the kernel_old=1 >> option in >> >>> config.txt. The main effects of this option are: >> >>> - all 4 cores start executing in secure SVC mode instead of >> non-secure SVC >> >>> mode >> >>> - all 4 cores start at 0x instead of 0x8000 >> >>> - the initial boot code that setup SMP and exits secure mode is not >> >>> executed >> >>> >> >>> After browsing u-boot's source code, it seems that their boot code is >> more >> >>> or less extracted from what u-boot is doing. However I didn't manage >> to >> >>> compile u-boot for the raspberry 2 supporting this secure mode. >> >>> >> >>> Could anyone explain me what options I need to configure in >> >>> rpi_2_defconfig >> >>> so that u-boot supports secure boot for the raspberry 2 and what the >> boot >> >>> sequence will be in this case ? I don't mind fixing the code if >> necessary >> >>> but I'm a bit lost in the order of events in the initialization. >> >>> >> >> >> >> (Luckily I just happened to notice this message while looking at >> another >> >> one nearby. CCing the relevant board maintainer(s) explicitly would >> help >> >> your messages be noticed) >> >> >> >> To modify U-Boot to support the alternate entry point/load address, >> you'd >> >> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in >> >> include/configs/rpi*.h. >> >> >> >> I wasn't aware of the thread/option you mention, so I have not >> attempted >> >> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself >> will >> >> "just work" once TEXT_BASE is fixed. >> >> >> >> To boot a kernel, you'
Re: [U-Boot] u-boot on raspberry 2: booting in SVC secure mode
I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE to 0x0 (with kernel_old=1) does not work: the board display some garbage on the uart then hangs. The content of the garbage makes me thinks that nothing is done to handle the four cores in this setting which ends up badly. I expected this since raspberry's "firmware" only let one core run free. I think I need to configure U-boot so that it deals with this SMP scenario (I just don't know how). My goal is to use U-boot to load some small homemade baremetal kernels on the raspberry (using serial or tftp loading), in *secure mode*, so I need U-boot to stay in secure mode, or at least let me install my own secure_monitor code before switching to non-secure mode. I made a couple attempts of adding secure mode support by adding options in configs/rpi_2_defconfig but they don't seem to be taken into account. Where do you suggest I put ARMV7_virt and ARMV7_NONSEC ? Best, Vincent 2015-02-26 10:17 GMT+01:00 Andre Przywara : > Hi Vincent, > > On 26/02/15 08:27, Vincent wrote: > > Hi, > > I finally hacked my way through U-boot and I managed to add raspberry's > > boot code inside U-boot so that it can start as usual when using > kernel_old > > = 1. I don't think > > we want this as a final solution but it made me understand a few things > > about U-boot architecture (in short: I added a new section located at 0x0 > > which executes raspberry's code, and > > then jump to the usual _start entry point). I didn't try to modify > > CONFIG_SYS_TEXT_BASE yet, I'll try this morning. > > > > From what I gathered from the source code, I think I have to activate > some > > options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot > starts > > in secure mode, > > but adding them to rpi_2_defconfig doesn't seem to change anything in > > .config, so I'm not sure that my current U-boot is "secure boot aware". > > Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like > > that ? > > AFAIK you don't need to tell U-Boot that it runs in secure: unless it > accesses any secure/non-secure specific peripherals it should work fine > in both modes. > Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into > non-sec, but there is no real reason to do so - at least not for Linux. > > You should do away with the original Raspi firmware snippet - not only > from a legal point of view. > Thanks to Marc U-Boot has now a much better implementation than my > original HYP-mode switcher, also this gives you PSCI support basically > for free. So just select ARMV7_VIRT and ARMV7_NONSEC. > > Do you know if there is a TrustZone Controller in that SoC? That would > be needed to guard the resident U-Boot code from the OS. Some SoCs have > secure on-chip SRAM usable for that purpose, that would do it, too. > But skimming through the BCM2835 .pdf I don't spot any of those, > unfortunately. > > Cheers, > Andre. > > > > > 2015-02-25 19:38 GMT+01:00 Stephen Warren : > > > >> On 02/25/2015 02:30 AM, Vincent wrote: > >> > >>> Hi, > >>> as explained here http://community.arm.com/message/25127, it is > possible > >>> to > >>> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option > in > >>> config.txt. The main effects of this option are: > >>> - all 4 cores start executing in secure SVC mode instead of non-secure > SVC > >>> mode > >>> - all 4 cores start at 0x instead of 0x8000 > >>> - the initial boot code that setup SMP and exits secure mode is not > >>> executed > >>> > >>> After browsing u-boot's source code, it seems that their boot code is > more > >>> or less extracted from what u-boot is doing. However I didn't manage to > >>> compile u-boot for the raspberry 2 supporting this secure mode. > >>> > >>> Could anyone explain me what options I need to configure in > >>> rpi_2_defconfig > >>> so that u-boot supports secure boot for the raspberry 2 and what the > boot > >>> sequence will be in this case ? I don't mind fixing the code if > necessary > >>> but I'm a bit lost in the order of events in the initialization. > >>> > >> > >> (Luckily I just happened to notice this message while looking at another > >> one nearby. CCing the relevant board maintainer(s) explicitly would help > >> your messages be noticed) > >> > >> To modify U-Boot to support the alternate entry point/load address, > you'd > >> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in > >> include/configs/rpi*.h. > >> > >> I wasn't aware of the thread/option you mention, so I have not attempted > >> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself > will > >> "just work" once TEXT_BASE is fixed. > >> > >> To boot a kernel, you'll probably need to at least configure the ARM > >> architected timers CNTFRQ register for the kernel. Perhaps there are a > few > >> other things like that missing? > >> > >> It might be interesting to enable U-Boot's PSCI support on the RPi2, so > >> that an upstream kernel could gain SMP support
Re: [U-Boot] u-boot on raspberry 2: booting in SVC secure mode
Hi Vincent, On 26/02/15 08:27, Vincent wrote: > Hi, > I finally hacked my way through U-boot and I managed to add raspberry's > boot code inside U-boot so that it can start as usual when using kernel_old > = 1. I don't think > we want this as a final solution but it made me understand a few things > about U-boot architecture (in short: I added a new section located at 0x0 > which executes raspberry's code, and > then jump to the usual _start entry point). I didn't try to modify > CONFIG_SYS_TEXT_BASE yet, I'll try this morning. > > From what I gathered from the source code, I think I have to activate some > options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot starts > in secure mode, > but adding them to rpi_2_defconfig doesn't seem to change anything in > .config, so I'm not sure that my current U-boot is "secure boot aware". > Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like > that ? AFAIK you don't need to tell U-Boot that it runs in secure: unless it accesses any secure/non-secure specific peripherals it should work fine in both modes. Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into non-sec, but there is no real reason to do so - at least not for Linux. You should do away with the original Raspi firmware snippet - not only from a legal point of view. Thanks to Marc U-Boot has now a much better implementation than my original HYP-mode switcher, also this gives you PSCI support basically for free. So just select ARMV7_VIRT and ARMV7_NONSEC. Do you know if there is a TrustZone Controller in that SoC? That would be needed to guard the resident U-Boot code from the OS. Some SoCs have secure on-chip SRAM usable for that purpose, that would do it, too. But skimming through the BCM2835 .pdf I don't spot any of those, unfortunately. Cheers, Andre. > > 2015-02-25 19:38 GMT+01:00 Stephen Warren : > >> On 02/25/2015 02:30 AM, Vincent wrote: >> >>> Hi, >>> as explained here http://community.arm.com/message/25127, it is possible >>> to >>> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option in >>> config.txt. The main effects of this option are: >>> - all 4 cores start executing in secure SVC mode instead of non-secure SVC >>> mode >>> - all 4 cores start at 0x instead of 0x8000 >>> - the initial boot code that setup SMP and exits secure mode is not >>> executed >>> >>> After browsing u-boot's source code, it seems that their boot code is more >>> or less extracted from what u-boot is doing. However I didn't manage to >>> compile u-boot for the raspberry 2 supporting this secure mode. >>> >>> Could anyone explain me what options I need to configure in >>> rpi_2_defconfig >>> so that u-boot supports secure boot for the raspberry 2 and what the boot >>> sequence will be in this case ? I don't mind fixing the code if necessary >>> but I'm a bit lost in the order of events in the initialization. >>> >> >> (Luckily I just happened to notice this message while looking at another >> one nearby. CCing the relevant board maintainer(s) explicitly would help >> your messages be noticed) >> >> To modify U-Boot to support the alternate entry point/load address, you'd >> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in >> include/configs/rpi*.h. >> >> I wasn't aware of the thread/option you mention, so I have not attempted >> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself will >> "just work" once TEXT_BASE is fixed. >> >> To boot a kernel, you'll probably need to at least configure the ARM >> architected timers CNTFRQ register for the kernel. Perhaps there are a few >> other things like that missing? >> >> It might be interesting to enable U-Boot's PSCI support on the RPi2, so >> that an upstream kernel could gain SMP support without the need for >> explicit BCM2836 SMP support code. >> >> So far, I haven't attempted anything with an (upstream) kernel on RPi2, >> just U-Boot. >> > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/20] Add Chrome OS config header
Hello Stephen, >> diff --git a/include/configs/chromeos.h b/include/configs/chromeos.h >> >> +/* Stringify a token */ >> +#ifndef STRINGIFY >> +#define _STRINGIFY(x) #x >> +#define STRINGIFY(x)_STRINGIFY(x) >> +#endif > > Shouldn't that be in some common header so it isn't ever duplicated? > U-Boot has already __stringify(), so this should not be necessary at all. Best Regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/12] tegra124: Add PSCI support for Tegra124
On Wed, Feb 18, 2015 at 09:14:03AM +0100, Jan Kiszka wrote:
[...]
> diff --git a/arch/arm/cpu/armv7/tegra124/ap.c
> b/arch/arm/cpu/armv7/tegra124/ap.c
[...]
> +void ap_pm_init(void)
> +{
> + struct flow_ctlr *flow = (struct flow_ctlr *)NV_PA_FLOW_BASE;
> + struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
> +
> + writel((u32)park_cpu, EXCEP_VECTOR_CPU_RESET_VECTOR);
> +
> + tegra_powergate_power_on(TEGRA_POWERGATE_CPU1);
> + tegra_powergate_power_on(TEGRA_POWERGATE_CPU2);
> + tegra_powergate_power_on(TEGRA_POWERGATE_CPU3);
> +
> + writel((2 << CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, &flow->cpu1_csr);
> + writel((4 << CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, &flow->cpu2_csr);
> + writel((8 << CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, &flow->cpu3_csr);
> +
> + writel(EVENT_MODE_STOP, &flow->halt_cpu1_events);
> + writel(EVENT_MODE_STOP, &flow->halt_cpu2_events);
> + writel(EVENT_MODE_STOP, &flow->halt_cpu3_events);
> +
> + while (readl(&pmc->pmc_pwrgate_status) & ((1 << TEGRA_POWERGATE_CPU1) |
> + (1 << TEGRA_POWERGATE_CPU2) |
> + (1 << TEGRA_POWERGATE_CPU3)))
> + /* wait */;
> +}
As discussed previously I don't quite understand why the sequence:
1) program CSR registers
2) program halt events
3) power on CPUs
does not work. Testing shows that PSCI will work with that sequence once
the kernel is loaded. However I can also confirm that U-Boot doesn't see
the power partition status updated to "off", so I assume the partitions
will indeed still be powered on if we change the sequence.
So until we find out why that's happening I think it's safe to go with
the above sequence, since it does what we want. Perhaps add a comment
describing the ambiguity?
Also as a cosmetic cleanup, perhaps rather than checking the PMC power
gate status register you check bit 16 of each CPU's CSR register, which
should mirror the corresponding power gate status bit. That way you
don't need to access the PMC registers but restrict register accesses to
a single IP block in this code.
Thierry
pgpPDCiAgIFjD.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/12] tegra124: Add PSCI support for Tegra124
On Wed, Feb 18, 2015 at 09:14:03AM +0100, Jan Kiszka wrote: [...] > +ENTRY(psci_cpu_off) > + bl psci_cpu_off_common > + > + mrc p15, 0, r1, c0, c0, 5 @ MPIDR > + and r1, r1, #7 @ number of CPUs in cluster > + > + get_csr_reg r1, r2, r3 > + > + ldr r6, =TEGRA_FLOW_CTRL_BASE > + mov r5, #(CSR_ENABLE) > + add r5, r1, lsl #CSR_WAIT_WFI_SHIFT This puts the wrong value into the WAIT_WFI field. The value of that field is supposed to be a mask, not the index of the CPU. I've used this to fix it: mov r4, #(1 << CSR_WAIT_WFI_SHIFT) add r5, r4, lsl r1 With that fixed I see that with CPU hotplugging the power partition for the CPU that's taken offline is gated. To verify: # cat /sys/kernel/debug/powergate # echo 0 > /sys/devices/system/cpu/cpu1/online # cat /sys/kernel/debug/powergate Thierry pgpFMehkmVUYA.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] added defconfig for Jesurun Q5
Hi Gábor, On 26-02-15 00:16, Gábor Nyers wrote: The Jesurun Q5 has a black plastic casing with the approximate dimensions of 100mm x 100mm x 24mm with rounded edges. In terms of hardware it features an Allwinner A10 SoC with 1GB RAM and 8GB of NAND flash. The storage capacity can be extended up to 32GB with a MicroSD card. The external connectors are: 2x USB-A female supporting USB2.0, 3.5mm female jack for audio, HDMI female, SPDIF, RJ45 LAN and Power. In addition the device has a red (hard wired to power) and a programmable green LED. The pins for the UART are easily located on the PCB. The devices is equipped with an AXP209 PMU. For more details see: http://linux-sunxi.org/Jesurun_Q5 You're missing a: Signed-off-by: Gábor Nyers At the end of you're commit msg here (my bad I forgot that when we we're discussing how to submit patches). Can you please resend with that line added to the end of the commit msg? For you're next patch(es) you can do "git commit -s" to make git automatically add the Signed-off-by. Thanks & Regards, Hans --- configs/jesurun_q5_defconfig | 9 + 1 file changed, 9 insertions(+) create mode 100644 configs/jesurun_q5_defconfig diff --git a/configs/jesurun_q5_defconfig b/configs/jesurun_q5_defconfig new file mode 100644 index 000..7ef35f2 --- /dev/null +++ b/configs/jesurun_q5_defconfig @@ -0,0 +1,9 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_EMAC,USB_EHCI,MACPWR=SUNXI_GPH(19)" +CONFIG_FDTFILE="sun4i-a10-jesurun-q5.dtb" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN4I=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=123 ++S:CONFIG_DRAM_EMR1=0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on raspberry 2: booting in SVC secure mode
Hi, I finally hacked my way through U-boot and I managed to add raspberry's boot code inside U-boot so that it can start as usual when using kernel_old = 1. I don't think we want this as a final solution but it made me understand a few things about U-boot architecture (in short: I added a new section located at 0x0 which executes raspberry's code, and then jump to the usual _start entry point). I didn't try to modify CONFIG_SYS_TEXT_BASE yet, I'll try this morning. >From what I gathered from the source code, I think I have to activate some options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot starts in secure mode, but adding them to rpi_2_defconfig doesn't seem to change anything in .config, so I'm not sure that my current U-boot is "secure boot aware". Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like that ? Thank you for your feedback ! Best, Vincent 2015-02-25 19:38 GMT+01:00 Stephen Warren : > On 02/25/2015 02:30 AM, Vincent wrote: > >> Hi, >> as explained here http://community.arm.com/message/25127, it is possible >> to >> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option in >> config.txt. The main effects of this option are: >> - all 4 cores start executing in secure SVC mode instead of non-secure SVC >> mode >> - all 4 cores start at 0x instead of 0x8000 >> - the initial boot code that setup SMP and exits secure mode is not >> executed >> >> After browsing u-boot's source code, it seems that their boot code is more >> or less extracted from what u-boot is doing. However I didn't manage to >> compile u-boot for the raspberry 2 supporting this secure mode. >> >> Could anyone explain me what options I need to configure in >> rpi_2_defconfig >> so that u-boot supports secure boot for the raspberry 2 and what the boot >> sequence will be in this case ? I don't mind fixing the code if necessary >> but I'm a bit lost in the order of events in the initialization. >> > > (Luckily I just happened to notice this message while looking at another > one nearby. CCing the relevant board maintainer(s) explicitly would help > your messages be noticed) > > To modify U-Boot to support the alternate entry point/load address, you'd > hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in > include/configs/rpi*.h. > > I wasn't aware of the thread/option you mention, so I have not attempted > to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself will > "just work" once TEXT_BASE is fixed. > > To boot a kernel, you'll probably need to at least configure the ARM > architected timers CNTFRQ register for the kernel. Perhaps there are a few > other things like that missing? > > It might be interesting to enable U-Boot's PSCI support on the RPi2, so > that an upstream kernel could gain SMP support without the need for > explicit BCM2836 SMP support code. > > So far, I haven't attempted anything with an (upstream) kernel on RPi2, > just U-Boot. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: common: provide a _weak board_usb_cleanup() function
Hi Marek, > On Wednesday, February 25, 2015 at 10:15:24 AM, Lukasz Majewski wrote: > > Hi Marek, > > Hi! > > > > On Tuesday, February 24, 2015 at 05:05:29 PM, Lukasz Majewski > > > wrote: > > > > Hi Lukasz, > > > > > [...] > > > > I'll stick with your recommendation, though I'd like to -- > > > somehow -- work in Inha's credit into those patches too. What do > > > you think please ? > > > > Rob Herring had some comments to Inha original patches, so now I'm > > confused. > > > > Lets see if Inha fixes issues with original patch. > > It is also possible to drop only one patch from Kishon, namely > > "common: cmd_dfu: invoke board_usb_cleanup() for cleaning up" > > Gah, we're loosing traction here. Maybe we need to sync up and we > surely need to apply something, otherwise this will become a chaotic > mess. > > I placed all of the patches into u-boot-usb branch topic/dwc3 . Can > you please check if it's working and what is possibly missing ? Let's > work on top of that please, OK ? Thanks for preparing the branch. However, some fixes - those collected by me need some extra rework, since there were some comments regarding them (mostly from Kishon). Moreover, we could also add to this branch (on top of Kishon's dwc3 patch set) the linux compatibility rework. On top of that I would like to add next version of dwc3 fixes. > > Best regards, > Marek Vasut -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
