Re: [U-Boot] [PATCHv3 15/17] arm: socfpga: spl: update pll_config for dev kit
On Wednesday, April 15, 2015 at 10:49:11 PM, Dinh Nguyen wrote: On 04/02/2015 08:54 PM, Marek Vasut wrote: On Tuesday, March 31, 2015 at 12:01:16 AM, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com This sets the CPU clocks to 925MHz and DDR to 400MHz, and the correct CONFIG_HPS_MAINPLLGRP_VCO_NUMER should be 79. Didn't various CV SX run at 800MHz only ? I think only some of them ran at 925MHz, not all of them. Ah yes, I think I'm lucky to have a 925MHz devkit on my desk. But I think CONFIG_HPS_MAINPLLGRP_VCO_NUMER should be 79, as I cannot get a correct baudrate without it. Yep, you and me are both lucky. The AV is also 925MHz part. I have some SoCrates and MCV SoMs which are 800 MHz parts, so I'd like to keep those parts operational, but I think I'll just have to figure something out on a per-board basis. I'll check the subsequent patch and see if I can pick it up now. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot][PATCH 0/2] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA
On Wednesday, April 15, 2015 at 11:14:50 PM, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Hello, The following 2 patches adds the DDR controller driver that is in the Altera SoCFPGA platform. This driver is needed for the SPL on the platform. Hi, current u-boot-socfpga/master doesn't build. Can you please send me a patch(set) for it, so it builds, so I can send it upstream before I start digging in these DRAM patches ? Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 0/3] Add SPL support for SoCFPGA
On Wednesday, April 15, 2015 at 11:44:30 PM, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Hello, The following 3 patches are updates to SPL patches that Marek has already applied to his tree. I have split out the DDR driver patches into a separate patch series to make it more convenient to review. Thanks, Applied all three to u-boot-socfpga/master, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] ARM: vf610: Initial integration for Colibri VF50/VF61
On 2015-04-15 12:54, Sanchayan Maity wrote: This adds initial support for Colibri VF50/VF61 based on Freescale Vybrid SoC. - CPU clocked at 396/500 MHz - DDR3 at 396MHz - for VF50, use PLL2 as memory clock (synchronous mode) - for VF61, use PLL1 as memory clock (asynchronous mode) - Console on UART0 (Colibri UART_A) - Ethernet on FEC1 - PLL5 based RMII clocking (E.g. No external crystal) - UART_A and UART_C I/O muxing - Boot from NAND by default Tested on Colibri VF50/VF61 booting using serial loader over UART. Signed-off-by: Sanchayan Maity maitysancha...@gmail.com Acked-by: Stefan Agner ste...@agner.ch Thanks for the patchset, Sanchayan! -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: implement find_next_zero_bit function
Hello Vitaly,
On Thu, 5 Feb 2015 11:24:46 -0500, Vitaly Andrianov vita...@ti.com
wrote:
This commit copies implementation of the find_next_zero_bit() from
git://git.denx.de/u-boot.git/arch/mips/include/asm/bitops.h. v2014.07
The function is required to enable MCAST_TFTP support for ARM platforms.
Signed-off-by: Vitaly Andrianov vita...@ti.com
---
arch/arm/include/asm/bitops.h | 43
---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index 597dafb..9b78043 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -95,9 +95,6 @@ static inline int __test_and_change_bit(int nr, volatile
void *addr)
return (old mask) != 0;
}
-extern int find_first_zero_bit(void * addr, unsigned size);
-extern int find_next_zero_bit(void * addr, int size, int offset);
-
/*
* This routine doesn't need to be atomic.
*/
@@ -129,6 +126,43 @@ static inline unsigned long ffz(unsigned long word)
return k;
}
+static inline int find_next_zero_bit(void *addr, int size, int offset)
+{
+ unsigned long *p = ((unsigned long *)addr) + (offset 5);
+ unsigned long result = offset ~31UL;
+ unsigned long tmp;
+
+ if (offset = size)
+ return size;
+ size -= result;
+ offset = 31UL;
+ if (offset) {
+ tmp = *(p++);
+ tmp |= ~0UL (32-offset);
+ if (size 32)
+ goto found_first;
+ if (~tmp)
+ goto found_middle;
+ size -= 32;
+ result += 32;
+ }
+ while (size ~31UL) {
+ tmp = *(p++);arm: implement find_next_zero_bit function
+ if (~tmp)
+ goto found_middle;
+ result += 32;
+ size -= 32;
+ }
+ if (!size)
+ return result;
+ tmp = *p;
+
+found_first:
+ tmp |= ~0UL size;
+found_middle:
+ return result + ffz(tmp);
+}
+
/*
* hweightN: returns the hamming weight (i.e. the number
* of bits set) of a N-bit word
@@ -138,6 +172,9 @@ static inline unsigned long ffz(unsigned long word)
#define hweight16(x) generic_hweight16(x)
#define hweight8(x) generic_hweight8(x)
+#define find_first_zero_bit(addr, size) \
+ find_next_zero_bit((addr), (size), 0)
+
#define ext2_set_bit test_and_set_bit
#define ext2_clear_bit test_and_clear_bit
#define ext2_test_bittest_bit
--
1.9.1
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] f_thor: Dont perform reset at the end of thor
On Thursday, April 16, 2015 at 11:41:30 AM, Michal Simek wrote: Hi, On 04/16/2015 11:31 AM, Marek Vasut wrote: On Thursday, April 16, 2015 at 10:38:34 AM, Michal Simek wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Dont perform reset at the end of thor download if configured to do reset off. Reset may not be required in all cases and hence provided an option to do so. The case would be to download the images to DDR instead of flash device. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com And the documentation for this new config option is where exactly ? ;-) ok. We will write it. It means there is no problem from your point of view about adding this feature to u-boot. It is great to know it. You need ACK from Lukasz on these kinds of patches. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: Enable CONFIG_USE_ARCH_MEMSET/MEMCPY globally
Hello Tom, On Tue, 3 Feb 2015 15:21:53 -0500, Tom Rini tr...@ti.com wrote: - Move the obj- lines for memset.S/memcpy.S to outside of an SPL check so that SPL can use them as well. - Make sure memset() / memcpy() end up in a text.fn section for garbage collection in SPL. - Update examples/api/Makefile to get memset() again on ARM. - Drop Y-MODEM SPL from am335x_evm and USB SPL so that it fits within size constraints again. - Always set CONFIG_USE_ARCH_MEMSET/MEMCPY on ARM !ARM64 Cc: Albert Aribaud albert.u.b...@aribaud.net Signed-off-by: Tom Rini tr...@ti.com Really small nitpick: the comment before the YMODEM undef is not that informative, and possibly unneeded if all space-saving undefs can be grouped under a single global comment. If there are no comments apart from mine, maybe we don't need this to be reposted as non-RFC, and I can directly apply it? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Commit d3cfcb3 breaks beagle_x15 build
Hello, Commit d3cfcb3 (ARM: DRA7: Enable clocks for USB OTGSS and USB PHY) breaks beagle_x15 build: Building current source for 1 boards (1 thread, 8 jobs per thread) arm: + beagle_x15 +board/ti/beagle_x15/board.c: In function 'board_usb_init': +board/ti/beagle_x15/board.c:393:1: error: 'const struct prcm_regs' has no member named 'cm_l3init_usb_otg_ss_clkctrl' +make[2]: *** [board/ti/beagle_x15/board.o] Error 1 +make[1]: *** [board/ti/beagle_x15] Error 2 +make: *** [sub-make] Error 2 Cc:ing the committer and author. Kishon, can you look into this? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] f_thor: Dont perform reset at the end of thor
Hi, On 04/16/2015 11:31 AM, Marek Vasut wrote: On Thursday, April 16, 2015 at 10:38:34 AM, Michal Simek wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Dont perform reset at the end of thor download if configured to do reset off. Reset may not be required in all cases and hence provided an option to do so. The case would be to download the images to DDR instead of flash device. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com And the documentation for this new config option is where exactly ? ;-) ok. We will write it. It means there is no problem from your point of view about adding this feature to u-boot. It is great to know it. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] sunxi: Fix end of kernel memory alignment for A33
Hi, On 15-04-15 21:57, Ian Campbell wrote: On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote: For unknown reasons the A33 needs the end of the memory we report to the kernel to be aligned to a multiple of 4 MiB. Do you really mean the A33 needs (as in the processor itself) or do you actually mean the A33 kernel port? If the latter than can't that be investigated/fixed instead of hacked here? That would be far more preferable. I mean the former, it seems that the SoC itself cannot handle dram ranges with different cache policies which are not aligned to 4 MiB, at least that is my WAG what is going on here. I've been using an a23 dtb + generic multi-platform kernel for my testing (as said before the a33 really is almost the same design), and that boots fine without this alignment hack on an actual A23 device, so this is not a kernel limitation. I'm not entirely happy with this semi-magic workaround either, but it took me a day to find it, and then I tried to find a better solution / more satisfying answer as to why for another day, so at this point my vision on this is that we will just have to live with it. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.04 released
Hello Tom, On Mon, 13 Apr 2015 13:20:47 -0400, Tom Rini tr...@ti.com wrote: Hey all, I've pushed v2015.04 out to the repository and tarballs should exist soon. The Kconfig migration is moving along nicely as is the DM work. This has been a good all-around nice set of updates, bug fixes and new board and feature support. Two last things, to repeat what I said last release. First, really, we're going to deprecate and then remove MAKEALL. If you've got a use-case that's not working with buildman please start yelling now so that we can get it addressed (and note that there's stuff ready to come in once the merge window is open). One thing that just hit me is that when a buildman target fails to build, buildman returns an exist code of 128, which wrecks git bisect. IOW, I cannot do things like git bisect start $bad-commit-id $good-commit-id git bisect run tools/buildman/buildman $broken-target because the first trial where the target fails to build will cause git bisect to terminate with the message bisect run failed: exit code 128 from 'tools/buildman/buildman -o ../build/u-boot/ beagle_x15' is 0 or = 128 I haven't seen this mentioned so far, but I may have missed it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10] sunxi: Add a33 dram init code
On Thu, 2015-04-16 at 09:27 +0200, Hans de Goede wrote: Hi, On 15-04-15 21:56, Ian Campbell wrote: On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote: From: Vishnu Patekar vishnupatekar0...@gmail.com Based on Allwinner dram init code from the a33 bsp: https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/bsp/bsp_for_a33/init_dram/mctl_hal.c Initial u-boot port by Vishnu Patekar, major cleanup / rewrite by Hans de Goede. Signed-off-by: Vishnu Patekar vishnupatekar0...@gmail.com Signed-off-by: Hans de Goede hdego...@redhat.com + /* Set dram timing */ + reg_val = (twtp 24) | (tfaw 16) | (trasmax 8) | (tras 0); + writel(reg_val, mctl_ctl-dramtmg0); + reg_val = (txp 16) | (trtp 8) | (trc 0); + writel(reg_val, mctl_ctl-dramtmg1); + reg_val = (tcwl 24) | (tcl 16) | (trd2wr 8) | (twr2rd 0); + writel(reg_val, mctl_ctl-dramtmg2); + reg_val = (tmrw 16) | (tmrd 12) | (tmod 0); + writel(reg_val, mctl_ctl-dramtmg3); + reg_val = (trcd 24) | (tccd 16) | (trrd 8) | (trp 0); + writel(reg_val, mctl_ctl-dramtmg4); + reg_val = (tcksrx 24) | (tcksre 16) | (tckesr 8) | (tcke 0); + writel(reg_val, mctl_ctl-dramtmg5); There's a lot of magic numbers here (and in the following code), although in this particular context (with the named var) unless they are the same elsewhere I'm not sure #defines would improve things much, but I think some of the other stuff likely would. Assuming you have any idea what the bits are, I suppose that per usual we don't really know because -ENODOC? Right the problem here is -ENODOC, the magic values come from the allwinnner code and in the cases where we do not have named variables (as we do in the above blurb) we've no clue what we're doing really, so I think adding defines there will only obfuscate things. Can you give a short description of the cases where you believe that adding defines would be a good idea ? Anywhere where we know the meanings ;-) If that's nowhere then the magic numbers are fine (which is what my final paragraph was trying to say, but not very clearly). Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
Hello Masahiro, Your patch clashes with Pavel's already committed break-if-private-libgcc-and-thumb, causing many boards to fail building. I am putting your patch in 'under review' state until I can have a look at what happens with private libgcc and thumb. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] sunxi: Introduce a hidden ARCH_SUN6I Kconfig bool
Hi, On 15-04-15 21:47, Ian Campbell wrote: On Wed, 2015-04-15 at 10:45 +0200, Michal Suchanek wrote: It is not obvious which MACH_SUN?I are ARCH_SUN6I derived. So if you can come up with a descriptive name for 'a number of things in common, such as having separate ahb reset registers in the ccm' that's fine otherwise this obfuscates the code, not clarifies. I don't particularly object to the patch but this occurred to me too. I suppose the rule is first sunxi to look this way. How about we call groups of similar SoCs a generation, i.e. ARCH_SUNXI_GEN2 is what is called ARCH_SUN6I here, meaning GEN1 would be SUN4/5/7I. I like the GEN idea, but not the numbering as it is a bit too arbitrary how about: ARCH_SUNXI_GEN_SUN6I or (better I think) just SUNXI_GEN_SUN6I ? I know that does not solve the fact that MACH_SUN7I is SUNXI_GEN_SUN4I but we cannot fix that, at least this way it will be explicit. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add initial SPL support for HummingBoard-i2eX
Hi Fabio, On 15/04/2015 22:57, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Add the initial SPL support for HummingBoard-i2eX, which is based on a MX6 Dual. For more information about HummingBoard, please check: http://www.solid-run.com/products/hummingboard/ Based on the work from Jon Nettleton and Rabeeh Khoury. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Currently only HummingBoard-i2eX is supported. After this initial patch is accepted, then we can add the other Hummingboard and Cubox-i variants as well. arch/arm/Kconfig | 6 + board/solidrun/mx6cuboxi/Kconfig | 15 ++ board/solidrun/mx6cuboxi/MAINTAINERS | 6 + board/solidrun/mx6cuboxi/Makefile| 9 + board/solidrun/mx6cuboxi/README | 23 +++ board/solidrun/mx6cuboxi/mx6cuboxi.c | 336 +++ configs/mx6cuboxi_spl_defconfig | 6 + include/configs/mx6cuboxi.h | 257 +++ 8 files changed, 658 insertions(+) create mode 100644 board/solidrun/mx6cuboxi/Kconfig create mode 100644 board/solidrun/mx6cuboxi/MAINTAINERS create mode 100644 board/solidrun/mx6cuboxi/Makefile create mode 100644 board/solidrun/mx6cuboxi/README create mode 100644 board/solidrun/mx6cuboxi/mx6cuboxi.c create mode 100644 configs/mx6cuboxi_spl_defconfig create mode 100644 include/configs/mx6cuboxi.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7ed0e20..7c383cb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -523,6 +523,11 @@ config TARGET_MX6SABRESD select CPU_V7 select SUPPORT_SPL +config TARGET_MX6CUBOXI + bool Support Solid-run mx6 boards + select CPU_V7 + select SUPPORT_SPL + config TARGET_MX6SLEVK bool Support mx6slevk select CPU_V7 @@ -856,6 +861,7 @@ source board/siemens/draco/Kconfig source board/siemens/pxm2/Kconfig source board/siemens/rut/Kconfig source board/silica/pengwyn/Kconfig +source board/solidrun/mx6cuboxi/Kconfig source board/solidrun/hummingboard/Kconfig source board/spear/spear300/Kconfig source board/spear/spear310/Kconfig diff --git a/board/solidrun/mx6cuboxi/Kconfig b/board/solidrun/mx6cuboxi/Kconfig new file mode 100644 index 000..31d88b2 --- /dev/null +++ b/board/solidrun/mx6cuboxi/Kconfig @@ -0,0 +1,15 @@ +if TARGET_MX6CUBOXI + +config SYS_BOARD + default mx6cuboxi + +config SYS_VENDOR + default solidrun + +config SYS_SOC + default mx6 + +config SYS_CONFIG_NAME + default mx6cuboxi + +endif diff --git a/board/solidrun/mx6cuboxi/MAINTAINERS b/board/solidrun/mx6cuboxi/MAINTAINERS new file mode 100644 index 000..3d468ed --- /dev/null +++ b/board/solidrun/mx6cuboxi/MAINTAINERS @@ -0,0 +1,6 @@ +MX6CUBOXI BOARD +M: Fabio Estevam fabio.este...@freescale.com +S: Maintained +F: board/solidrun/mx6cuboxi/ +F: include/configs/mx6cuboxi.h +F: configs/mx6cuboxi_spl_defconfig diff --git a/board/solidrun/mx6cuboxi/Makefile b/board/solidrun/mx6cuboxi/Makefile new file mode 100644 index 000..df425ac --- /dev/null +++ b/board/solidrun/mx6cuboxi/Makefile @@ -0,0 +1,9 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski l...@denx.de +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := mx6cuboxi.o diff --git a/board/solidrun/mx6cuboxi/README b/board/solidrun/mx6cuboxi/README new file mode 100644 index 000..29bff2b --- /dev/null +++ b/board/solidrun/mx6cuboxi/README @@ -0,0 +1,23 @@ +How to use U-boot on Solid-run mx6 hummingboard +--- + +- Build U-boot for hummingboard: + +$ make mrproper +$ make mx6cuboxi_spl_defconfig +$ make + +This will generate the SPL image called SPL and the u-boot.img. + +- Flash the SPL image into the SD card: + +sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync + +- Flash the u-boot.img image into the SD card: + +sudo dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69; sync + +- Insert the SD card in the hummingboard, power it up and U-boot messages +should come up. + + diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c new file mode 100644 index 000..4cbd832 --- /dev/null +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -0,0 +1,336 @@ +/* + * Copyright (C) 2015 Freescale Semiconductor, Inc. + * + * Author: Fabio Estevam fabio.este...@freescale.com + * Copyright (C) 2013 Jon Nettleton jon.nettle...@gmail.com + * + * Based on SPL code from Solidrun tree, which is: + * Author: Tungyi Lin tungyilin1...@gmail.com + * + * Derived from EDM_CF_IMX6 code by TechNexion,Inc + * Ported to SolidRun microSOM by Rabeeh Khoury rab...@solid-run.com + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include asm/arch/clock.h +#include asm/arch/imx-regs.h +#include asm/arch/iomux.h +#include asm/arch/mx6-pins.h
Re: [U-Boot] [PATCH 26/34] imx: ventana: add DT fixup for GW54xx compatibility with older kernels
Hi Tim,
I have no problem with the whole series, I will start to apply. Just a
couple of questions:
On 08/04/2015 21:54, Tim Harvey wrote:
Certain older kernels in use by some customers erroneously define a uart3
for GW54xx with a pinmux that conflicts with NAND. This will remove
that node to avoid such conflicts.
Signed-off-by: Tim Harvey thar...@gateworks.com
---
board/gateworks/gw_ventana/gw_ventana.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/gateworks/gw_ventana/gw_ventana.c
b/board/gateworks/gw_ventana/gw_ventana.c
index 068c726..06611b5 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -1599,6 +1599,17 @@ int ft_board_setup(void *blob, bd_t *bd)
strlen((const char *)info-model) + 1);
/*
+ * disable serial2 node for GW54xx for compatibility with older
+ * 3.10.x kernel that improperly had this node enabled in the DT
+ */
I understand the issue, but I guess you have a dtb file for your
(Freescale) 3.10 kernel and another one for kernel mainline. So why this
issue should be fixed here and not in the related DTS file ?
+ if (board_type == GW54xx) {
+ i = fdt_path_offset(blob,
+ /soc/aips-bus@0210/serial@021ec000);
+ if (i)
+ fdt_del_node(blob, i);
+ }
+
+ /*
* disable wdog1/wdog2 nodes for GW51xx below revC to work around
* errata causing wdog timer to be unreliable.
*/
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] sunxi: s/sun8i/sun8i_a23/
Hi, On 15-04-15 21:49, Ian Campbell wrote: On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote: This is a preparation patch for adding A33 support, which will have a mach name of sun8i-a33. And, presumably, differs substantially from sun8i-a23, to the extent it should likely have been a new sunNi but we are stuck with what AW did, sigh, oh well. Actually other then having a different DRAM controller / MBUS setup, the differences are very minor (what I know sofar is a few slightly different bits in the otg controller/phy, and the SID is back inside the SoC). Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell ian.campb...@citrix.com Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] sunxi: Add basic A33 basic support
Hi, On 15-04-15 22:00, Ian Campbell wrote: On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote: From: Vishnu Patekar vishnupatekar0...@gmail.com A quick comment on what basic here means, i.e. prcm, rsb, clocks as per sun6i, etc would be good. Actually the Basic is misleading here, since this adds full support, usb controller, display output, etc. everything works, so I'll drop the Basic from the Subject and add a proper commit message. Signed-off-by: Vishnu Patekar vishnupatekar0...@gmail.com Signed-off-by: Hans de Goede hdego...@redhat.com Did you make non-trivial mods or is this S-o-b just a passing it along one? (In the latter case I won't bother to review deeply myself unless you want me to) I made non-trivial mods, both the display driver and usb driver changes are all from my hand. @@ -103,6 +107,10 @@ static void usb_phy_write(struct sunxi_usbc_hcd *sunxi_usbc, int addr, int j = 0, usbc_bit = 0; void *dest = sunxi_usbc_get_io_base(0) + SUNXI_USB_CSR; +#ifdef CONFIG_MACH_SUN8I_A33 + writel(0, dest); +#endif Some undocumented/commented magic? Pretty much, I took this from the Allwinner sources which have a comment along the lines of this needs to be explicitly initialized to 0 on A33, I can add such a comment if you want me to. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] Move board_init_f_mem() into a common location
Hello Simon,
On 16-04-15 03:14, Simon Glass wrote:
+
+DECLARE_GLOBAL_DATA_PTR;
+
+ulong board_init_f_mem(ulong top)
+{
+ /* TODO(s...@chromium.org): Figure out how x86 can use this */
+#ifndef CONFIG_X86
+ /* Leave space for the stack we are running with now */
+ top -= 0x40;
+
+ top -= sizeof(struct global_data);
+ top = ALIGN(top, 16);
+ gd = (struct global_data *)top;
+ memset((void *)gd, '\0', sizeof(*gd));
+
Above piece of code is on my TODO list as well. Like x86, clang cannot
directly assign gd. What I still need to check is why this reassignment is
needed in the first place. Typically, at least for ARM, allocating an
initial
gd in _main and copying it over in relocate suffices for common boards.
This doesn't work if there is a valid use case for needing gd before calling
main, but I am not aware of any (but haven't found time to google for any
as well, so it doesn't mean there isn't any).
That said, if there is valid reason to reassign gd, clang could do that
if there
was a macro e.g. set_gd(new_gd) instead of a direct assignment. Since
this is a
cross arch patchset, that might be something to consider (and likely
solves the
Figure out how x86 can use this as well).
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] f_thor: Dont perform reset at the end of thor
On Thursday, April 16, 2015 at 10:38:34 AM, Michal Simek wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Dont perform reset at the end of thor download if configured to do reset off. Reset may not be required in all cases and hence provided an option to do so. The case would be to download the images to DDR instead of flash device. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com And the documentation for this new config option is where exactly ? ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] f_thor: Dont perform reset at the end of thor
From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com
Dont perform reset at the end of thor download
if configured to do reset off.
Reset may not be required in all cases and hence
provided an option to do so.
The case would be to download the images to DDR instead
of flash device.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2:
- Update commit message with additional description
drivers/usb/gadget/f_thor.c | 7 +++
drivers/usb/gadget/f_thor.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index e9a690eff5f1..5c8f6768519c 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -123,6 +123,9 @@ static int process_rqt_cmd(const struct rqt_box *rqt)
send_rsp(rsp);
g_dnl_unregister();
dfu_free_entities();
+#ifdef CONFIG_THOR_RESET_OFF
+ return RESET_DONE;
+#endif
run_command(reset, 0);
break;
case RQT_CMD_POWEROFF:
@@ -728,6 +731,10 @@ int thor_handle(void)
if (ret 0) {
ret = process_data();
+#ifdef CONFIG_THOR_RESET_OFF
+ if (ret == RESET_DONE)
+ break;
+#endif
if (ret 0)
return ret;
} else {
diff --git a/drivers/usb/gadget/f_thor.h b/drivers/usb/gadget/f_thor.h
index 833a9d24ae7e..83412851dd17 100644
--- a/drivers/usb/gadget/f_thor.h
+++ b/drivers/usb/gadget/f_thor.h
@@ -121,4 +121,7 @@ struct f_thor {
#define F_NAME_BUF_SIZE 32
#define THOR_PACKET_SIZE SZ_1M /* 1 MiB */
#define THOR_STORE_UNIT_SIZE SZ_32M /* 32 MiB */
+#ifdef CONFIG_THOR_RESET_OFF
+#define RESET_DONE 0x
+#endif
#endif /* _USB_THOR_H_ */
--
2.3.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10] sunxi: Add a33 dram init code
Hi, On 15-04-15 21:56, Ian Campbell wrote: On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote: From: Vishnu Patekar vishnupatekar0...@gmail.com Based on Allwinner dram init code from the a33 bsp: https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/bsp/bsp_for_a33/init_dram/mctl_hal.c Initial u-boot port by Vishnu Patekar, major cleanup / rewrite by Hans de Goede. Signed-off-by: Vishnu Patekar vishnupatekar0...@gmail.com Signed-off-by: Hans de Goede hdego...@redhat.com + /* Set dram timing */ + reg_val = (twtp 24) | (tfaw 16) | (trasmax 8) | (tras 0); + writel(reg_val, mctl_ctl-dramtmg0); + reg_val = (txp 16) | (trtp 8) | (trc 0); + writel(reg_val, mctl_ctl-dramtmg1); + reg_val = (tcwl 24) | (tcl 16) | (trd2wr 8) | (twr2rd 0); + writel(reg_val, mctl_ctl-dramtmg2); + reg_val = (tmrw 16) | (tmrd 12) | (tmod 0); + writel(reg_val, mctl_ctl-dramtmg3); + reg_val = (trcd 24) | (tccd 16) | (trrd 8) | (trp 0); + writel(reg_val, mctl_ctl-dramtmg4); + reg_val = (tcksrx 24) | (tcksre 16) | (tckesr 8) | (tcke 0); + writel(reg_val, mctl_ctl-dramtmg5); There's a lot of magic numbers here (and in the following code), although in this particular context (with the named var) unless they are the same elsewhere I'm not sure #defines would improve things much, but I think some of the other stuff likely would. Assuming you have any idea what the bits are, I suppose that per usual we don't really know because -ENODOC? Right the problem here is -ENODOC, the magic values come from the allwinnner code and in the cases where we do not have named variables (as we do in the above blurb) we've no clue what we're doing really, so I think adding defines there will only obfuscate things. Can you give a short description of the cases where you believe that adding defines would be a good idea ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Armv8: Initializing CNTVOFF_EL2
Hello feng...@phytium.com.cn, On Mon, 2 Mar 2015 15:29:34 +0800, feng...@phytium.com.cn feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn Linux-arm64 require that CNTVOFF_EL2 should be programmed with a consistent value on all cpus. Initializing CNTVOFF_EL2 at state transition instead of start.S could prevent potential different value on cpus if ATF exist and u-boot runs at only one cpu. Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/include/asm/macro.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 1c8c425..39df86a 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -113,6 +113,9 @@ lr.reqx30 mov \xreg1, #0x33ff msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */ + /* Initialize Generic Timers */ + msr cntvoff_el2, xzr + /* Initialize SCTLR_EL2 * * setting RES1 bits (29,28,23,22,18,16,11,5,4) to 1 -- 1.7.9.5 Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] zynq: timer: Fix wrong timer calculation
From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com
Fix wrong timer calculation in get_timer_masked incase of
overflow.
This fixes the issue of getting wrong time from get_timer()
calls.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
arch/arm/cpu/armv7/zynq/timer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/zynq/timer.c b/arch/arm/cpu/armv7/zynq/timer.c
index 303dbcfceafb..5ed9642df9b3 100644
--- a/arch/arm/cpu/armv7/zynq/timer.c
+++ b/arch/arm/cpu/armv7/zynq/timer.c
@@ -93,7 +93,9 @@ ulong get_timer_masked(void)
gd-arch.tbl += gd-arch.lastinc - now;
} else {
/* We have an overflow ... */
- gd-arch.tbl += gd-arch.lastinc + TIMER_LOAD_VAL - now + 1;
+ gd-arch.tbl += gd-arch.lastinc + (TIMER_LOAD_VAL /
+ (gd-arch.timer_rate_hz / CONFIG_SYS_HZ)) -
+ now + 1;
}
gd-arch.lastinc = now;
--
2.3.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add initial SPL support for HummingBoard-i2eX
Hi Fabio, On 04/16/2015 04:27 AM, Fabio Estevam wrote: Hi Nikolay, On Wed, Apr 15, 2015 at 10:24 PM, Nikolay Dimitrov picmas...@mail.bg wrote: imx6 supports up to 528 MHz DDR3 clock as per datasheet, which makes 1058 MT/s data rate. Unfortunately such comments (like above) in the code doesn't help to clarify the differences. Which is a nice way to say the comments are wrong :). Here's what happens - chip specs say that the chip supports 1600 MT/s (800 MHz DDR3 clock). The imx6 ddr code looks up in the switch/case and calculates timings for 800 MHz, while in reality the imx6 MMDC officially supports up to 528 MHz. What should happen - mem_speed should be clamped to imx6 model-specific speed limit, so the MMDC code can calculate valid timings. Care to submit a patch with your proposal? Yes. This should be independent of this hummingboard support patch. OK. Thanks, Fabio Estevam Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush
On Thu, Apr 16, 2015 at 06:17:59AM +0100, Siva Durga Prasad Paladugu wrote: Hi Mark. -Original Message- From: Mark Rutland [mailto:mark.rutl...@arm.com] Sent: Wednesday, April 15, 2015 6:41 PM To: Michal Simek Cc: u-boot@lists.denx.de; Tom Rini; Siva Durga Prasad Paladugu; Varun Sethi; Arnab Basu; York Sun Subject: Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush On Wed, Apr 15, 2015 at 12:33:00PM +0100, Michal Simek wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Always disable dcache after the flush operation The following sequence is advisable while disabling d-cache: 1. disable_dcache() - flushes and disables d-cache 2. invalidate_dcache_all() - invalid any entry that came to the cache in the short period after the cache was flushed but before the cache got disabled For reasons I have described previously (see [1,2,3]), this is unsafe. The first cache flush may achieve nothing. If you need data out at the PoC before disabling the cache, then you should first use maintenance by VA to push that data out. Thanks, Mark. [1] http://lists.denx.de/pipermail/u-boot/2015-February/204403.html [2] http://lists.denx.de/pipermail/u-boot/2015-February/204407.html [3] http://lists.denx.de/pipermail/u-boot/2015-February/204702.html Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/arm/cpu/armv8/cache_v8.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index c5ec5297cd39..2a0492fbef52 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -128,10 +128,10 @@ void dcache_disable(void) if (!(sctlr CR_C)) return; - set_sctlr(sctlr ~(CR_C|CR_M)); - flush_dcache_all(); __asm_invalidate_tlb_all(); + + set_sctlr(sctlr ~(CR_C|CR_M)); I got your point. But here in this scenario also there is an issue with disable first and then flush_dcache_all(). This is because when we disable the cache and invoke the c routine flush_dcache_all() then the return address of this is stored in a stack(in memory as dcache is disabled). Which is why this sequence cannot be written in C, and needs to be performed in assembly, without any memory accesses between the write to the SCTLR and the cache flush. Now in the flush_dcache_all we are invoking the actual asm call to flush dcache which may wipeout the stored return value in stack with cahe contents(main memory). Hence the return from the flush_dcahe_all will fail. To confirm this I modified the dcache_disable in the below way and it worked fine. 1. Disable the dcache. 2. Now I called the __asm_flush_dcache_all(); and then flush_l3_cache(); instead of calling the flush_dcache_all(). That also is unsafe; implicit (e.g. stack) accesses at any point after SCTLR.C is cleared and before flush_l3_cache() has completed may see stale data, or get overwritten by stale data. Set/Way ops only flush the CPU-local caches, so you only guarantee that these are clean (and potentially dirty cache lines for the stack could be sat in L3 and written back at any time). So your flush_l3_cache() function might not work. Per ARMv8 the L3 _must_ respect maintenance by VA, so after disabling the MMU you can flush the memory region corresponding to your stack (and any other data you need) by VA to the PoC before executing flush_l3_cache(), in addition to the Set/Way ops used to empty the CPU-local caches. Thanks, Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: cpu: Add ARMv7 barrier operations support
Hello Vladimir, On Fri, 20 Mar 2015 18:16:17 +0300, Vladimir Barinov vladimir.bari...@cogentembedded.com wrote: From: Valentine Barshak valentine.bars...@cogentembedded.com This enables ARMv7 barrier operations support when march=armv7-a is enabled. Using CP15 barriers causes U-Boot bootm command crash when transferring control to the loaded image on Renesas R8A7794 Cortex A7 CPU. Using ARMv7 barrier operations instead of the deprecated CP15 barriers helps to avoid these issues. Signed-off-by: Valentine Barshak valentine.barshak+rene...@cogentembedded.com Signed-off-by: Vladimir Barinov vladimir.barinov+rene...@cogentembedded.com Reviewed-by: Tom Rini tr...@konsulko.com --- arch/arm/cpu/armv7/cache_v7.c | 14 +++--- arch/arm/include/asm/armv7.h | 10 ++ 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c index 0f9d837..e8ee875 100644 --- a/arch/arm/cpu/armv7/cache_v7.c +++ b/arch/arm/cpu/armv7/cache_v7.c @@ -68,7 +68,7 @@ static void v7_inval_dcache_level_setway(u32 level, u32 num_sets, } } /* DSB to make sure the operation is complete */ - CP15DSB; + DSB; } static void v7_clean_inval_dcache_level_setway(u32 level, u32 num_sets, @@ -96,7 +96,7 @@ static void v7_clean_inval_dcache_level_setway(u32 level, u32 num_sets, } } /* DSB to make sure the operation is complete */ - CP15DSB; + DSB; } static void v7_maint_dcache_level_setway(u32 level, u32 operation) @@ -215,7 +215,7 @@ static void v7_dcache_maint_range(u32 start, u32 stop, u32 range_op) } /* DSB to make sure the operation is complete */ - CP15DSB; + DSB; } /* Invalidate TLB */ @@ -228,9 +228,9 @@ static void v7_inval_tlb(void) /* Invalidate entire instruction TLB */ asm volatile (mcr p15, 0, %0, c8, c5, 0 : : r (0)); /* Full system DSB - make sure that the invalidation is complete */ - CP15DSB; + DSB; /* Full system ISB - make sure the instruction stream sees it */ - CP15ISB; + ISB; } void invalidate_dcache_all(void) @@ -343,10 +343,10 @@ void invalidate_icache_all(void) asm volatile (mcr p15, 0, %0, c7, c5, 6 : : r (0)); /* Full system DSB - make sure that the invalidation is complete */ - CP15DSB; + DSB; /* ISB - make sure the instruction stream sees it */ - CP15ISB; + ISB; } #else void invalidate_icache_all(void) diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h index a13da23..189f3f0 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -70,6 +70,16 @@ #define CP15DSB asm volatile (mcr p15, 0, %0, c7, c10, 4 : : r (0)) #define CP15DMB asm volatile (mcr p15, 0, %0, c7, c10, 5 : : r (0)) +#ifdef __ARM_ARCH_7A__ +#define ISB asm volatile (isb : : : memory) +#define DSB asm volatile (dsb : : : memory) +#define DMB asm volatile (dmb : : : memory) +#else +#define ISB CP15ISB +#define DSB CP15DSB +#define DMB CP15DMB +#endif + /* * Workaround for ARM errata # 798870 * Set L2ACTLR[7] to reissue any memory transaction in the L2 that has been -- 1.9.3 Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot PATCH] ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
Commit d3cfcb3 (ARM: DRA7: Enable clocks for USB OTGSS and USB PHY)
changed the member names of prcm_regs from cm_l3init_usb_otg_ss_clkctrl
to cm_l3init_usb_otg_ss1_clkctrl and from cm_coreaon_usb_phy_core_clkctrl
to cm_coreaon_usb_phy1_core_clkctrl in order to differentiate between
the two dwc3 controllers present in dra7xx/am43xx and enabled these
clocks in enable_basic_clocks() in hw_data.c. However these clocks
continued to be enabled in board files/driver files for dwc3 host
mode functionality causing compilation break with few configs.
Fixed it here by making all the clocks enabled in enable_basic_clocks()
and removing it from board files/driver files here.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Tested host mode functionality in beagle_x15, dra72-evm and am43xx evm
in order to make sure this patch doesn't break host mode functioanlity.
arch/arm/cpu/armv7/omap5/hw_data.c |4 ++--
board/ti/beagle_x15/board.c| 10 --
drivers/usb/phy/omap_usb_phy.c | 16
3 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index e4abb25..868415d 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -460,7 +460,7 @@ void enable_basic_clocks(void)
(*prcm)-cm_l4per_gpio6_clkctrl,
(*prcm)-cm_l4per_gpio7_clkctrl,
(*prcm)-cm_l4per_gpio8_clkctrl,
-#ifdef CONFIG_USB_DWC3
+#if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
(*prcm)-cm_l3init_ocp2scp1_clkctrl,
(*prcm)-cm_l3init_usb_otg_ss1_clkctrl,
#endif
@@ -495,7 +495,7 @@ void enable_basic_clocks(void)
setbits_le32((*prcm)-cm_l3init_hsmmc2_clkctrl,
HSMMC_CLKCTRL_CLKSEL_MASK);
-#ifdef CONFIG_USB_DWC3
+#if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
/* Enable 960 MHz clock for dwc3 */
setbits_le32((*prcm)-cm_l3init_usb_otg_ss1_clkctrl,
OPTFCLKEN_REFCLK960M);
diff --git a/board/ti/beagle_x15/board.c b/board/ti/beagle_x15/board.c
index 3a7e04d..ac0d22c 100644
--- a/board/ti/beagle_x15/board.c
+++ b/board/ti/beagle_x15/board.c
@@ -385,13 +385,3 @@ int board_eth_init(bd_t *bis)
return ret;
}
#endif
-
-#ifdef CONFIG_USB_XHCI_OMAP
-int board_usb_init(int index, enum usb_init_type init)
-{
- setbits_le32((*prcm)-cm_l3init_usb_otg_ss_clkctrl,
- OTG_SS_CLKCTRL_MODULEMODE_HW | OPTFCLKEN_REFCLK960M);
-
- return 0;
-}
-#endif
diff --git a/drivers/usb/phy/omap_usb_phy.c b/drivers/usb/phy/omap_usb_phy.c
index 52a3664..63d9301 100644
--- a/drivers/usb/phy/omap_usb_phy.c
+++ b/drivers/usb/phy/omap_usb_phy.c
@@ -131,17 +131,6 @@ static void omap_enable_usb3_phy(struct omap_xhci *omap)
{
u32 val;
- /* Setting OCP2SCP1 register */
- setbits_le32((*prcm)-cm_l3init_ocp2scp1_clkctrl,
-OCP2SCP1_CLKCTRL_MODULEMODE_HW);
-
- /* Turn on 32K AON clk */
- setbits_le32((*prcm)-cm_coreaon_usb_phy_core_clkctrl,
-USBPHY_CORE_CLKCTRL_OPTFCLKEN_CLK32K);
-
- /* Setting CM_L3INIT_CLKSTCTRL to 0x0 i.e NO sleep */
- writel(0x0, (*prcm)-cm_l3init_clkstctrl);
-
val = (USBOTGSS_DMADISABLE |
USBOTGSS_STANDBYMODE_SMRT_WKUP |
USBOTGSS_IDLEMODE_NOIDLE);
@@ -169,11 +158,6 @@ static void omap_enable_usb3_phy(struct omap_xhci *omap)
writel(val, omap-otg_wrapper-irqstatus_1);
val = readl(omap-otg_wrapper-irqstatus_0);
writel(val, omap-otg_wrapper-irqstatus_0);
-
- /* Enable the USB OTG Super speed clocks */
- val = (OPTFCLKEN_REFCLK960M | OTG_SS_CLKCTRL_MODULEMODE_HW);
- setbits_le32((*prcm)-cm_l3init_usb_otg_ss_clkctrl, val);
-
};
#endif /* CONFIG_OMAP_USB3PHY1_HOST */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] armv8/cache: Fix page table creation
Hello Thierry, I assume there will be a v2 series? (asking so that I can mark the series Changes Requested) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: lpc32xx: Use priv_data instead of platdata
Hello Axel, On Tue, 14 Apr 2015 14:55:24 +0800, Axel Lin axel@ingics.com wrote: The LPC32XX GPIO driver platdata currently contains GPIO state information, which should go into priv_data. Thus rename lpc32xx_gpio_platdata to lpc32xx_gpio_priv and convert to use dev_get_priv() instead. Signed-off-by: Axel Lin axel@ingics.com Tested-by: Albert ARIBAUD albert.arib...@3adev.fr Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add initial SPL support for HummingBoard-i2eX
On Wed, Apr 15, 2015 at 05:57:55PM -0300, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Add the initial SPL support for HummingBoard-i2eX, which is based on a
MX6 Dual.
For more information about HummingBoard, please check:
http://www.solid-run.com/products/hummingboard/
Based on the work from Jon Nettleton and Rabeeh Khoury.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
[snip]
+static void ccgr_init(void)
+{
+ struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ writel(0x00C03F3F, ccm-CCGR0);
+ writel(0x0030FC03, ccm-CCGR1);
+ writel(0x0FFFC000, ccm-CCGR2);
+ writel(0x3FF0, ccm-CCGR3);
+ writel(0x00FFF300, ccm-CCGR4);
+ writel(0x0FC3, ccm-CCGR5);
+ writel(0x03FF, ccm-CCGR6);
+}
+
+static void gpr_init(void)
+{
+ struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
+
+ /* enable AXI cache for VDOA/VPU/IPU */
+ writel(0xF0CF, iomux-gpr[4]);
+ /* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
+ writel(0x007F007F, iomux-gpr[6]);
+ writel(0x007F007F, iomux-gpr[7]);
+}
As a later clean-up maybe we should move these as default weak functions
to arch/arm/cpu/armv7/mx6/soc.c ?
+void reset_cpu(ulong addr)
+{
+}
Not needed?
+#endif
diff --git a/configs/mx6cuboxi_spl_defconfig b/configs/mx6cuboxi_spl_defconfig
new file mode 100644
index 000..9847a9b
--- /dev/null
+++ b/configs/mx6cuboxi_spl_defconfig
@@ -0,0 +1,6 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6Q
Shouldn't need SPL listed here.
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
Don't need both.
+/* Ethernet Configuration */
+#define CONFIG_FEC_MXC
+#ifdef CONFIG_FEC_MXC
Just define it?
+ fdt_high=0x\0 \
+ initrd_high=0x\0 \
No, we need to use bootm_size here instead.
+#define CONFIG_ARP_TIMEOUT 200UL
Do we really need this?
+#define CONFIG_SYS_PROMPT_HUSH_PS2
Don't need.
+#define CONFIG_SYS_MEMTEST_START 0x1000
+#define CONFIG_SYS_MEMTEST_END 0x1001
+#define CONFIG_SYS_MEMTEST_SCRATCH 0x1080
Probably shouldn't set..
+#define CONFIG_STACKSIZE (128 * 1024)
Unused, iirc.
+#define PHYS_SDRAM MMDC0_ARB_BASE_ADDR
+
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM
Just use MMDC0_ARB_BASE_ADDR directly.
+/* FLASH and environment organization */
+#define CONFIG_SYS_NO_FLASH
+#define CONFIG_ENV_SIZE (8 * 1024)
+#define CONFIG_ENV_IS_IN_MMC
+
+#if defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_ENV_OFFSET(8 * 64 * 1024)
+#endif
Just define things, don't test.
+#define CONFIG_DEFAULT_FDT_FILE imx6q-hummingboard.dtb
Group this with the rest of the env parts?
+#define PHYS_SDRAM_SIZE (1u * 1024 * 1024 * 1024)
Unused.
+#if defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_SYS_MMC_ENV_DEV 0 /* SDHC2 */
+#endif
Again, just define, and group with the others.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: timer: Fix wrong timer calculation
Hello Michal,
Michal Simek wrote on 2015-04-16:
From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com
Fix wrong timer calculation in get_timer_masked incase of overflow. This
fixes the issue of getting wrong time from get_timer() calls.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
arch/arm/cpu/armv7/zynq/timer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/zynq/timer.c
b/arch/arm/cpu/armv7/zynq/timer.c index 303dbcfceafb..5ed9642df9b3
100644 --- a/arch/arm/cpu/armv7/zynq/timer.c +++
b/arch/arm/cpu/armv7/zynq/timer.c @@ -93,7 +93,9 @@ ulong
get_timer_masked(void)
gd-arch.tbl += gd-arch.lastinc - now;
} else {
/* We have an overflow ... */
- gd-arch.tbl += gd-arch.lastinc + TIMER_LOAD_VAL - now + 1;
+ gd-arch.tbl += gd-arch.lastinc + (TIMER_LOAD_VAL /
+ (gd-arch.timer_rate_hz / CONFIG_SYS_HZ))
-
+ now + 1;
}
gd-arch.lastinc = now;
I had similar problems with the MIPS timer code some time ago.
I solved it by switching to the common timer implementation:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=a18a477147ce2493ef9ee93b8981b34929fc48a5
I don't know the arm/zynq hardware in detail, but if you use some free running
counter for this,
the switch should be simple.
As you can see from the diff, the previous code was also doing some complex
checks to detect an overflow.
With the common code, it could be reduced to two simple functions (where one
could be removed,
if we update all configs to define a different macro for the timer rate).
Best Regards,
Thomas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add initial SPL support for HummingBoard-i2eX
On Wed, Apr 15, 2015 at 05:57:55PM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Add the initial SPL support for HummingBoard-i2eX, which is based on a MX6 Dual. For more information about HummingBoard, please check: http://www.solid-run.com/products/hummingboard/ Based on the work from Jon Nettleton and Rabeeh Khoury. Signed-off-by: Fabio Estevam fabio.este...@freescale.com [snip] +#ifdef CONFIG_SPL_BUILD +#include spl.h +#include libfdt.h Oh and we don't need either of these includes (we aren't doing the FDT stuff the Solid Run codebase was). And why yes, I was looking at the same code base and doing a similar thing when you posted your patches :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fix ARM DCC support for ARMv7 based cores (e.g. CortexA)
Hello Alexander, On Thu, 19 Mar 2015 18:37:19 +0100, Alexander Merkle alexander.mer...@lauterbach.com wrote: Signed-off-by: Alexander Merkle alexander.mer...@lauterbach.com --- drivers/serial/arm_dcc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c index 5dfb02f..e37 100644 --- a/drivers/serial/arm_dcc.c +++ b/drivers/serial/arm_dcc.c @@ -29,9 +29,9 @@ #include common.h #include serial.h -#if defined(CONFIG_CPU_V6) +#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V7) /* - * ARMV6 + * ARMV6 ARMV7 */ #define DCC_RBIT (1 30) #define DCC_WBIT (1 29) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] [PATCH v2] fix ARM DCC support for ARMv7 based cores (e.g. CortexA)
Hello Alexander, On Thu, 19 Mar 2015 18:37:20 +0100, Alexander Merkle alexander.mer...@lauterbach.com wrote: Signed-off-by: Alexander Merkle alexander.mer...@lauterbach.com --- include/configs/zynq-common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index 87b4fff..789e437 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -34,7 +34,6 @@ /* DCC driver */ #if defined(CONFIG_ZYNQ_DCC) # define CONFIG_ARM_DCC -# define CONFIG_CPU_V6 /* Required by CONFIG_ARM_DCC */ #else # define CONFIG_ZYNQ_SERIAL #endif -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND 1/3] driver/ddr/altera: Add DDR driver for Altera's SDRAM controller
From: Dinh Nguyen dingu...@opensource.altera.com
This patch enables the SDRAM controller that is used on Altera's SoCFPGA
family. This patch configures the SDRAM controller based on a configuration
file that is generated from the Quartus tool, sdram_config.h.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
Makefile | 1 +
arch/arm/include/asm/arch-socfpga/sdram.h| 294
arch/arm/include/asm/arch-socfpga/sdram_config.h | 100 +++
drivers/ddr/altera/sdram.c | 827 +++
scripts/Makefile.spl | 1 +
5 files changed, 1223 insertions(+)
create mode 100644 arch/arm/include/asm/arch-socfpga/sdram.h
create mode 100644 arch/arm/include/asm/arch-socfpga/sdram_config.h
create mode 100644 drivers/ddr/altera/sdram.c
diff --git a/Makefile b/Makefile
index 0f7d583..163d530 100644
--- a/Makefile
+++ b/Makefile
@@ -649,6 +649,7 @@ libs-y += drivers/power/ \
libs-y += drivers/spi/
libs-$(CONFIG_FMAN_ENET) += drivers/net/fm/
libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
+libs-$(CONFIG_ALTERA_SDRAM) += drivers/ddr/altera/
libs-y += drivers/serial/
libs-y += drivers/usb/dwc3/
libs-y += drivers/usb/eth/
diff --git a/arch/arm/include/asm/arch-socfpga/sdram.h
b/arch/arm/include/asm/arch-socfpga/sdram.h
new file mode 100644
index 000..f46c5f4
--- /dev/null
+++ b/arch/arm/include/asm/arch-socfpga/sdram.h
@@ -0,0 +1,294 @@
+/*
+ * Copyright Altera Corporation (C) 2014-2015
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef_SDRAM_H_
+#define_SDRAM_H_
+
+#ifndef __ASSEMBLY__
+
+/* function declaration */
+unsigned long sdram_calculate_size(void);
+unsigned sdram_mmr_init_full(unsigned int sdr_phy_reg);
+int sdram_calibration_full(void);
+
+extern int sdram_calibration(void);
+
+#define SDR_CTRLGRP_ADDRESS 0x5000
+
+struct socfpga_sdr_ctrl {
+ u32 ctrl_cfg;
+ u32 dram_timing1;
+ u32 dram_timing2;
+ u32 dram_timing3;
+ u32 dram_timing4; /* 0x10 */
+ u32 lowpwr_timing;
+ u32 dram_odt;
+ u32 __padding0[4];
+ u32 dram_addrw; /* 0x2c */
+ u32 dram_if_width; /* 0x30 */
+ u32 dram_dev_width;
+ u32 dram_sts;
+ u32 dram_intr;
+ u32 sbe_count; /* 0x40 */
+ u32 dbe_count;
+ u32 err_addr;
+ u32 drop_count;
+ u32 drop_addr; /* 0x50 */
+ u32 lowpwr_eq;
+ u32 lowpwr_ack;
+ u32 static_cfg;
+ u32 ctrl_width; /* 0x60 */
+ u32 cport_width;
+ u32 cport_wmap;
+ u32 cport_rmap;
+ u32 rfifo_cmap; /* 0x70 */
+ u32 wfifo_cmap;
+ u32 cport_rdwr;
+ u32 port_cfg;
+ u32 fpgaport_rst; /* 0x80 */
+ u32 __padding1;
+ u32 fifo_cfg;
+ u32 protport_default;
+ u32 prot_rule_addr; /* 0x90 */
+ u32 prot_rule_id;
+ u32 prot_rule_data;
+ u32 prot_rule_rdwr;
+ u32 __padding2[3];
+ u32 mp_priority;/* 0xac */
+ u32 mp_weight0; /* 0xb0 */
+ u32 mp_weight1;
+ u32 mp_weight2;
+ u32 mp_weight3;
+ u32 mp_pacing0; /* 0xc0 */
+ u32 mp_pacing1;
+ u32 mp_pacing2;
+ u32 mp_pacing3;
+ u32 mp_threshold0; /* 0xd0 */
+ u32 mp_threshold1;
+ u32 mp_threshold2;
+ u32 __padding3[29];
+ u32 phy_ctrl0; /* 0x150 */
+ u32 phy_ctrl1;
+ u32 phy_ctrl2;
+};
+
+#define SDR_CTRLGRP_CTRLCFG_NODMPINS_LSB 23
+#define SDR_CTRLGRP_CTRLCFG_NODMPINS_MASK 0x0080
+#define SDR_CTRLGRP_CTRLCFG_DQSTRKEN_LSB 22
+#define SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK 0x0040
+#define SDR_CTRLGRP_CTRLCFG_STARVELIMIT_LSB 16
+#define SDR_CTRLGRP_CTRLCFG_STARVELIMIT_MASK 0x003f
+#define SDR_CTRLGRP_CTRLCFG_REORDEREN_LSB 15
+#define SDR_CTRLGRP_CTRLCFG_REORDEREN_MASK 0x8000
+#define SDR_CTRLGRP_CTRLCFG_ECCCORREN_LSB 11
+#define SDR_CTRLGRP_CTRLCFG_ECCCORREN_MASK 0x0800
+#define SDR_CTRLGRP_CTRLCFG_ECCEN_LSB 10
+#define SDR_CTRLGRP_CTRLCFG_ECCEN_MASK 0x0400
+#define SDR_CTRLGRP_CTRLCFG_ADDRORDER_LSB 8
+#define SDR_CTRLGRP_CTRLCFG_ADDRORDER_MASK 0x0300
+#define SDR_CTRLGRP_CTRLCFG_MEMBL_LSB 3
+#define SDR_CTRLGRP_CTRLCFG_MEMBL_MASK 0x00f8
+#define SDR_CTRLGRP_CTRLCFG_MEMTYPE_LSB 0
+#define SDR_CTRLGRP_CTRLCFG_MEMTYPE_MASK 0x0007
+/* Register template: sdr::ctrlgrp::dramtiming1*/
+#define SDR_CTRLGRP_DRAMTIMING1_TRFC_LSB 24
+#define SDR_CTRLGRP_DRAMTIMING1_TRFC_MASK 0xff00
+#define SDR_CTRLGRP_DRAMTIMING1_TFAW_LSB 18
+#define SDR_CTRLGRP_DRAMTIMING1_TFAW_MASK 0x00fc
+#define SDR_CTRLGRP_DRAMTIMING1_TRRD_LSB 14
+#define SDR_CTRLGRP_DRAMTIMING1_TRRD_MASK 0x0003c000
+#define SDR_CTRLGRP_DRAMTIMING1_TCL_LSB 9
+#define
Re: [U-Boot] [PATCH 26/34] imx: ventana: add DT fixup for GW54xx compatibility with older kernels
On Thu, Apr 16, 2015 at 12:46 AM, Stefano Babic sba...@denx.de wrote: Hi Tim, I have no problem with the whole series, I will start to apply. Just a couple of questions: On 08/04/2015 21:54, Tim Harvey wrote: Certain older kernels in use by some customers erroneously define a uart3 for GW54xx with a pinmux that conflicts with NAND. This will remove that node to avoid such conflicts. Signed-off-by: Tim Harvey thar...@gateworks.com --- board/gateworks/gw_ventana/gw_ventana.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/board/gateworks/gw_ventana/gw_ventana.c b/board/gateworks/gw_ventana/gw_ventana.c index 068c726..06611b5 100644 --- a/board/gateworks/gw_ventana/gw_ventana.c +++ b/board/gateworks/gw_ventana/gw_ventana.c @@ -1599,6 +1599,17 @@ int ft_board_setup(void *blob, bd_t *bd) strlen((const char *)info-model) + 1); /* + * disable serial2 node for GW54xx for compatibility with older + * 3.10.x kernel that improperly had this node enabled in the DT + */ I understand the issue, but I guess you have a dtb file for your (Freescale) 3.10 kernel and another one for kernel mainline. So why this issue should be fixed here and not in the related DTS file ? Stefano, I only have a single dtb but in this case a customer has an older kernel with a bug in the dtb and for various reasons required a bootloader fix (rest of firmware was locked down). In their opinion a previous bootloader worked (and I never dug in to find out just why... likely a bootloader bug at the time) and the new one received on newer boards did not (with their locked down software). I can work around this in a bootloader script for them if you want to drop this particular one. Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] image: fix build when CONFIG_NR_DRAM_BANKS is disabled on ARM
Hello Matt, On Tue, 14 Apr 2015 14:07:17 -0400, Matt Porter mpor...@konsulko.com wrote: common/image.c currently implicitly depends on CONFIG_NR_DRAM_BANKS when CONFIG_ARM is enabled. Make this requirement explicit. Signed-off-by: Matt Porter mpor...@konsulko.com --- common/image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/image.c b/common/image.c index 162b682..73c24f5 100644 --- a/common/image.c +++ b/common/image.c @@ -461,7 +461,7 @@ phys_size_t getenv_bootm_size(void) tmp = 0; -#if defined(CONFIG_ARM) +#if defined(CONFIG_ARM) defined(CONFIG_NR_DRAM_BANKS) return gd-bd-bi_dram[0].size - tmp; #else return gd-bd-bi_memsize - tmp; -- 2.1.0 I am not entirely fond of a symbol's existence conditioning some code which does not actually use the symbol. I do understand the dependency here -- that bi_dram[0] is meaningful only if CONFIG_NR_DRAM_BANKS is 1 or more -- but then, why does this code not depend on the value of the symbol? Makes me think the patch is not complete and the code should be fixed to depend on the value of CONFIG_NR_DRAM_BANKS. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] image: fix build when CONFIG_NR_DRAM_BANKS is disabled on ARM
On Thu, Apr 16, 2015 at 03:52:16PM +0200, Albert ARIBAUD wrote: Hello Matt, On Tue, 14 Apr 2015 14:07:17 -0400, Matt Porter mpor...@konsulko.com wrote: common/image.c currently implicitly depends on CONFIG_NR_DRAM_BANKS when CONFIG_ARM is enabled. Make this requirement explicit. Signed-off-by: Matt Porter mpor...@konsulko.com --- common/image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/image.c b/common/image.c index 162b682..73c24f5 100644 --- a/common/image.c +++ b/common/image.c @@ -461,7 +461,7 @@ phys_size_t getenv_bootm_size(void) tmp = 0; -#if defined(CONFIG_ARM) +#if defined(CONFIG_ARM) defined(CONFIG_NR_DRAM_BANKS) return gd-bd-bi_dram[0].size - tmp; #else return gd-bd-bi_memsize - tmp; I am not entirely fond of a symbol's existence conditioning some code which does not actually use the symbol. I do understand the dependency here -- that bi_dram[0] is meaningful only if CONFIG_NR_DRAM_BANKS is 1 or more -- but then, why does this code not depend on the value of the symbol? Makes me think the patch is not complete and the code should be fixed to depend on the value of CONFIG_NR_DRAM_BANKS. The problem is that CONFIG_NR_DRAM_BANKS means both I have DRAM and I have X number of DRAM banks. In turn include/asm-generic/u-boot.h will only say we have gd-bd-bi_dram if CONFIG_NR_DRAM_BANKS is set so we can only reference that field when it's also set. Otherwise we get a compile error about no such member. There's a further argument (as I read and re-read getenv_bootm_size()) that getenv_bootm_clsize() should be cleaned-up / re-worked as it defaults to too large of a value (which is why stuff gets relocated high and then Linux doesn't see it and then people do initrd_high=0x and fdt_high=0x) but that's unrelated to this patch I think. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] common/cmd_boot: keep ARM v7M in thumb mode during do_go_exec()
On Thu, Apr 16, 2015 at 03:53:56PM +0200, Albert ARIBAUD wrote: Hello Matt, On Tue, 14 Apr 2015 14:07:18 -0400, Matt Porter mpor...@konsulko.com wrote: On ARM v7M, the processor will return to ARM mode when executing a blx instruction with bit 0 of the address == 0. Always set it to 1 to stay in thumb mode. This should be done for all targets which build with Thumb instruction set, not only ARMv7M, should it not? No, because it's not a problem on CPUs where we can do Thumb or non-Thumb instructions, only on CPUs where we can _only_ do Thumb instructions (or the special subset of other instructions the core allows). On ARM v7M trying to do the blx in ARM mode isn't allowed and causes an abort (or some other exception, I forget which) to happen upon execution. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env.h: include autoconf.h
On Tue, Apr 14, 2015 at 09:50:47PM +0200, Marcel Ziswiler wrote: From: Max Krummenacher max.krummenac...@toradex.com Without this, when CONFIG_ENV_VARS_UBOOT_CONFIG is active we get a compile time error when doing 'make env'. In file included from tools/env/fw_env.c:117:0: include/env_default.h:110:11: error: expected ‘}’ before ‘CONFIG_SYS_ARCH’ When building U-Boot this is included indirectly by the compiler switch -include /home/trdx/git.toradex.com/u-boot-2014.10-toradex/include/linux/kconfig.h Signed-off-by: Max Krummenacher max.krummenac...@toradex.com Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com --- This is an issue on all tegra boards due CONFIG_ENV_VARS_UBOOT_CONFIG being defined in the tegra-common.h header file. I already did reported this once last November but did not get any useful insights back then: Ug. I'm cc'ing a few distro people since this makes it further clear that by whatever name a distro packages fw_setenv/fw_getenv these are really machine (to the extent U-Boot is built) specific applications due to the need to include a copy of the default environment so that we can support making sure that variables that aren't supposed to be overwritten are not overwritten (see the fw_getdefenv call in tools/env/fw_env.c::fw_env_write). I'll let Masahiro comment on if this is the best way to fix the compile problem. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot][PATCH 0/2] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA
On Thursday, April 16, 2015 at 03:41:49 PM, Dinh Nguyen wrote: On 4/16/15 1:32 AM, Marek Vasut wrote: On Wednesday, April 15, 2015 at 11:14:50 PM, dingu...@opensource.altera.com wrote: From: Dinh Nguyen dingu...@opensource.altera.com Hello, The following 2 patches adds the DDR controller driver that is in the Altera SoCFPGA platform. This driver is needed for the SPL on the platform. Hi, current u-boot-socfpga/master doesn't build. Can you please send me a patch(set) for it, so it builds, so I can send it upstream before I start digging in these DRAM patches ? Oops, apologize for that, will rebase and resend. Resend what ? It does not build right now, as it is ... Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARMv7 TLB: Fixed TTBR0 and Table Descriptors to allow caching
Hello Bryan,
On Tue, 24 Mar 2015 11:25:12 -0500, Bryan Brinsko
bryan.brin...@rockwellcollins.com wrote:
The TTBR0 register and Table Descriptors of the ARMv7 TLB weren't being
properly set to allow for the configuration specified caching modes to
be active over DRAM. This commit fixes those issues.
Signed-off-by: Bryan Brinsko bryan.brin...@rockwellcollins.com
---
arch/arm/include/asm/system.h | 37 +
arch/arm/lib/cache-cp15.c | 14 ++
2 files changed, 51 insertions(+)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 2a5bed2..9cd2f1e 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -196,6 +196,28 @@ static inline void set_dacr(unsigned int val)
isb();
}
+#ifdef CONFIG_ARMV7
+/* Short-Descriptor Translation Table Level 1 Bits */
+#define TTB_SECT_NS_MASK (1 19)
+#define TTB_SECT_NG_MASK (1 17)
+#define TTB_SECT_S_MASK (1 16)
+/* Note: TTB AP bits are set elsewhere */
+#define TTB_SECT_TEX(x) ((x 0x7) 12)
+#define TTB_SECT_DOMAIN(x) ((x 0xf) 5)
+#define TTB_SECT_XN_MASK (1 4)
+#define TTB_SECT_C_MASK (1 3)
+#define TTB_SECT_B_MASK (1 2)
+#define TTB_SECT (2 0)
+
+/* options available for data cache on each page */
+enum dcache_option {
+ DCACHE_OFF = TTB_SECT_S_MASK | TTB_SECT_DOMAIN(0) |
+ TTB_SECT_XN_MASK | TTB_SECT,
+ DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
+ DCACHE_WRITEBACK = DCACHE_WRITETHROUGH | TTB_SECT_B_MASK,
+ DCACHE_WRITEALLOC = DCACHE_WRITEBACK | TTB_SECT_TEX(1),
+};
+#else
/* options available for data cache on each page */
enum dcache_option {
DCACHE_OFF = 0x12,
@@ -203,6 +225,7 @@ enum dcache_option {
DCACHE_WRITEBACK = 0x1e,
DCACHE_WRITEALLOC = 0x16,
};
+#endif
/* Size of an MMU section */
enum {
@@ -210,6 +233,20 @@ enum {
MMU_SECTION_SIZE= 1 MMU_SECTION_SHIFT,
};
+#ifdef CONFIG_ARMV7
+/* TTBR0 bits */
+#define TTBR0_BASE_ADDR_MASK 0xC000
+#define TTBR0_RGN_NC (0 3)
+#define TTBR0_RGN_WBWA (1 3)
+#define TTBR0_RGN_WT (2 3)
+#define TTBR0_RGN_WB (3 3)
+/* TTBR0[6] is IRGN[0] and TTBR[0] is IRGN[1] */
+#define TTBR0_IRGN_NC(0 0 | 0 6)
+#define TTBR0_IRGN_WBWA (0 0 | 1 6)
+#define TTBR0_IRGN_WT(1 0 | 0 6)
+#define TTBR0_IRGN_WB(1 0 | 1 6)
+#endif
+
/**
* Change the cache settings for a region.
*
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 0291afa..c65e068 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -96,9 +96,23 @@ static inline void mmu_setup(void)
dram_bank_mmu_setup(i);
}
+#ifdef CONFIG_ARMV7
+ /* Set TTBR0 */
+ reg = gd-arch.tlb_addr TTBR0_BASE_ADDR_MASK;
+#if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH)
+ reg |= TTBR0_RGN_WT | TTBR0_IRGN_WT;
+#elif defined(CONFIG_SYS_ARM_CACHE_WRITEALLOC)
+ reg |= TTBR0_RGN_WBWA | TTBR0_IRGN_WBWA;
+#else
+ reg |= TTBR0_RGN_WB | TTBR0_IRGN_WB;
+#endif
+ asm volatile(mcr p15, 0, %0, c2, c0, 0
+ : : r (reg) : memory);
+#else
/* Copy the page table address to cp15 */
asm volatile(mcr p15, 0, %0, c2, c0, 0
: : r (gd-arch.tlb_addr) : memory);
+#endif
/* Set the access control to all-supervisor */
asm volatile(mcr p15, 0, %0, c3, c0, 0
: : r (~0));
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] common/cmd_boot: keep ARM v7M in thumb mode during do_go_exec()
Hello Matt, On Tue, 14 Apr 2015 14:07:18 -0400, Matt Porter mpor...@konsulko.com wrote: On ARM v7M, the processor will return to ARM mode when executing a blx instruction with bit 0 of the address == 0. Always set it to 1 to stay in thumb mode. This should be done for all targets which build with Thumb instruction set, not only ARMv7M, should it not? Signed-off-by: Matt Porter mpor...@konsulko.com --- common/cmd_boot.c | 4 1 file changed, 4 insertions(+) diff --git a/common/cmd_boot.c b/common/cmd_boot.c index 8f2e070..20ce652 100644 --- a/common/cmd_boot.c +++ b/common/cmd_boot.c @@ -38,6 +38,10 @@ static int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) * pass address parameter as argv[0] (aka command name), * and all remaining args */ +#ifdef CONFIG_CPU_V7M + /* For ARM V7M, set bit zero to stay in Thumb mode */ + addr++; +#endif rc = do_go_exec ((void *)addr, argc - 1, argv + 1); if (rc != 0) rcode = 1; -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND 0/3] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA
From: Dinh Nguyen dingu...@opensource.altera.com Hi, This is a resend of the patch series that adds the DDR controller driver for Altera's SoCFPGA platform. This resend contains a new patch: arm: socfpga: enable the Altera SDRAM controller driver This new patch is necessary for the driver to build against u-boot-socfpga/master. Thanks, Dinh Nguyen (3): driver/ddr/altera: Add DDR driver for Altera's SDRAM controller driver/ddr/altera/: Add the sdram calibration portion arm: socfpga: enable the Altera SDRAM controller driver Makefile |1 + arch/arm/include/asm/arch-socfpga/sdram.h| 294 ++ arch/arm/include/asm/arch-socfpga/sdram_config.h | 100 + drivers/ddr/altera/Makefile | 12 + drivers/ddr/altera/sdram.c | 827 + drivers/ddr/altera/sequencer.c | 3907 ++ drivers/ddr/altera/sequencer.h | 328 ++ drivers/ddr/altera/sequencer_auto.h | 128 + drivers/ddr/altera/sequencer_auto_ac_init.c | 85 + drivers/ddr/altera/sequencer_auto_inst_init.c| 270 ++ drivers/ddr/altera/sequencer_defines.h | 121 + include/configs/socfpga_common.h |5 + scripts/Makefile.spl |1 + 13 files changed, 6079 insertions(+) create mode 100644 arch/arm/include/asm/arch-socfpga/sdram.h create mode 100644 arch/arm/include/asm/arch-socfpga/sdram_config.h create mode 100644 drivers/ddr/altera/Makefile create mode 100644 drivers/ddr/altera/sdram.c create mode 100644 drivers/ddr/altera/sequencer.c create mode 100644 drivers/ddr/altera/sequencer.h create mode 100644 drivers/ddr/altera/sequencer_auto.h create mode 100644 drivers/ddr/altera/sequencer_auto_ac_init.c create mode 100644 drivers/ddr/altera/sequencer_auto_inst_init.c create mode 100644 drivers/ddr/altera/sequencer_defines.h -- 2.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND 3/3] arm: socfpga: enable the Altera SDRAM controller driver
From: Dinh Nguyen dingu...@opensource.altera.com Enable the Altera SDRAM driver for the SoCFPGA platform. Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com --- include/configs/socfpga_common.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index cae744d..9b52050 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -77,6 +77,11 @@ #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESS /* + * SDRAM controller + */ +#define CONFIG_ALTERA_SDRAM + +/* * EPCS/EPCQx1 Serial Flash Controller */ #ifdef CONFIG_ALTERA_SPI -- 2.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi Tom, On 15 April 2015 at 12:16, Marek Vasut ma...@denx.de wrote: On Wednesday, April 15, 2015 at 03:43:37 PM, Tom Rini wrote: On Wed, Apr 15, 2015 at 07:29:41AM -0600, Simon Glass wrote: Hi Tom, On 15 April 2015 at 07:08, Tom Rini tr...@konsulko.com wrote: On Tue, Apr 14, 2015 at 05:50:50AM +0200, Marek Vasut wrote: The following changes since commit f33cdaa4c3da4a8fd35aa2f9a3172f31cc887b35: Prepare v2015.04 (2015-04-13 10:53:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git HEAD for you to fetch changes up to 7704fdbda3afb3d3bb0749378f444c71f92fb9ca: usb: gadget: thor: Claim EP after allocating it in thor gadget (2015-04-14 05:48:12 +0200) So this and the DM pull request conflict pretty badly. I can fixup everything but common/usb_storage.c with a pretty good degree of confidence. But in that case it looks like DM is trying to do something similar to what came in also via the USB tree (better / wider probing, roughly). How do you guys want to handle this? Thanks! If it is mostly this patch: usb_storage : scan all interfaces to find a storage device then you could drop it and I could tidy it up and resend. But I'm not sure what the conflicts are. There's a lot of non-USB stuff in the DM pull request so I'm reluctant to unpick and retest. But we'll have to do something. Marek what do you think? Dropping that patch makes the rest of the rejects much easier to understand, FWIW. Feel free to drop it then, but please notify the author to rebase it and repost . Is this looking OK? Do you need me to do anything to get the two pull requests in? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] sunxi: Fix end of kernel memory alignment for A33
On Thu, Apr 16, 2015 at 08:32:03AM +0100, Hans de Goede wrote: Hi, On 15-04-15 21:57, Ian Campbell wrote: On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote: For unknown reasons the A33 needs the end of the memory we report to the kernel to be aligned to a multiple of 4 MiB. Do you really mean the A33 needs (as in the processor itself) or do you actually mean the A33 kernel port? If the latter than can't that be investigated/fixed instead of hacked here? That would be far more preferable. I mean the former, it seems that the SoC itself cannot handle dram ranges with different cache policies which are not aligned to 4 MiB, at least that is my WAG what is going on here. That sounds incredibly suspicious. What do you mean w.r.t. different cache policies -- what does that have to do with the end of DRAM? What problem do you see? It would be worth reporting this on lakml. I've been using an a23 dtb + generic multi-platform kernel for my testing (as said before the a33 really is almost the same design), and that boots fine without this alignment hack on an actual A23 device, so this is not a kernel limitation. Not necessarily. Is RAM at the same location on both SoCs? What about other devices and carevouts? It could be htat the stars happen to align and we're finally caught out by some dodgy maths. Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
On Tue, Apr 14, 2015 at 12:11:00PM -0600, Simon Glass wrote: Hi Tom, Here are the driver model changes that have been queued up on u-boot-dm/next. The main changes are: - Ethernet driver model support - USB driver model support - PCI driver model support - Network cosmetic changes - Masahiro's driver model Kconfig changes - Chromebox panther support - Moving cros_ec fully to driver model - Moving various sandbox CONFIGs to Kconfig Since this has wide impact on the code base I'd like to get this in early in the merge window to minimise the pain of rebase, etc. So, yeah, rebase pain. Setting aside the USB scan changes (that're in as I didn't see u-boot-dfu included u-boot-usb, my fault), the rest of the USB conflicts are a little tricky too now that I read them harder. Please rebase and I'll grab it ASAP. Sorry! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,PULL] u-boot-usb/master
On Tue, Apr 14, 2015 at 05:50:50AM +0200, Marek Vasut wrote: The following changes since commit f33cdaa4c3da4a8fd35aa2f9a3172f31cc887b35: Prepare v2015.04 (2015-04-13 10:53:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git HEAD for you to fetch changes up to 7704fdbda3afb3d3bb0749378f444c71f92fb9ca: usb: gadget: thor: Claim EP after allocating it in thor gadget (2015-04-14 05:48:12 +0200) As this was part of u-boot-dfu PR as well and I didn't notice (oops..), applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] powerpc/t1023rdb: Add T1023 RDB board support
On 03/27/2015 12:48 AM, Shengzhou Liu wrote: T1023RDB is a Freescale Reference Design Board that hosts the T1023 SoC. T1023RDB board Overview --- - T1023 SoC integrating two 64-bit e5500 cores up to 1.4GHz - CoreNet fabric supporting coherent and noncoherent transactions with prioritization and bandwidth allocation - Memory: 2GB Micron MT40A512M8HX unbuffered 32-bit fixed DDR4 without ECC - Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC - Ethernet interfaces: - one 1G RGMII port on-board(RTL8211F PHY) - one 1G SGMII port on-board(RTL8211F PHY) - one 2.5G SGMII port on-board(AQR105 PHY) - PCIe: Two Mini-PCIe connectors on-board. - SerDes: 4 lanes up to 10.3125GHz - NOR: 128MB S29GL01GS110TFIV10 Spansion NOR Flash - NAND: 512MB S34MS04G200BFI000 Spansion NAND Flash - eSPI: 64MB S25FL512SAGMFI010 Spansion SPI flash. - USB: one Type-A USB 2.0 port with internal PHY - eSDHC: support SD/MMC card and eMMC on-board - 256Kbit M24256 I2C EEPROM - RTC: Real-time clock DS1339 on I2C bus - UART: one serial port on-board with RJ45 connector - Debugging: JTAG/COP for T1023 debugging As well updated T1024RDB to add T1023RDB. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v4: squashed ddr patch to this one. v3: updated readme. v2: updated the printout of serdes refclk. snip diff --git a/configs/T1023RDB_NAND_defconfig b/configs/T1023RDB_NAND_defconfig new file mode 100644 index 000..23c2f03 --- /dev/null +++ b/configs/T1023RDB_NAND_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1023,T1023RDB,RAMBOOT_PBL,SPL_FSL_PBL,NAND ++S:CONFIG_PPC=y ++S:CONFIG_MPC85xx=y ++S:CONFIG_TARGET_T102XRDB=y Please do not use CONFIG_SYS_EXTRA_OPTIONS for new boards. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] tools: mxsboot: Calculate ECC strength dynamically
On Wednesday, April 15, 2015 at 09:27:23 AM, Jörg Krause wrote: Calculating the ECC strength dynamically to be aligned with the mxs NAND driver and the Linux Kernel. Signed-off-by: Jörg Krause joerg.krause@embedded.rocks Reviewed-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] mtd: nand: mxs: Replace magic number for bits per ECC level with macro
On Wednesday, April 15, 2015 at 09:27:22 AM, Jörg Krause wrote: Signed-off-by: Jörg Krause joerg.krause@embedded.rocks --- Changes for v3: - Replace space with tab for macro definition Changes for v2: - New patch --- Reviewed-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:ls1021a: Reserve secure code into RAM instead of OCRAM
On 03/24/2015 02:27 AM, Zhuoyu Zhang wrote: For ls1021a, Reserve secure code in to memory in case OCRAM is needed by other usage. Signed-off-by: Zhuoyu Zhang zhuoyu.zh...@freescale.com --- include/configs/ls1021aqds.h | 1 - include/configs/ls1021atwr.h | 1 - 2 files changed, 2 deletions(-) diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 3dc4da3..42439a4 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -554,7 +554,6 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_LS102XA_NS_ACCESS #define CONFIG_SMP_PEN_ADDR 0x01ee0200 #define CONFIG_TIMER_CLK_FREQ1250 -#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR #define CONFIG_HWCONFIG #define HWCONFIG_BUFFER_SIZE 128 diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index a13876b..dccc661 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -347,7 +347,6 @@ #define CONFIG_LS102XA_NS_ACCESS #define CONFIG_SMP_PEN_ADDR 0x01ee0200 #define CONFIG_TIMER_CLK_FREQ1250 -#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR #define CONFIG_HWCONFIG #define HWCONFIG_BUFFER_SIZE 128 Zhuoyu, I don't see how the secure code is reserved in RAM. You only remove CONFIG_ARMV7_SECURE_BASE. Did I miss something? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot PATCH] ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
On Thu, Apr 16, 2015 at 05:17:00PM +0530, Kishon Vijay Abraham I wrote: Commit d3cfcb3 (ARM: DRA7: Enable clocks for USB OTGSS and USB PHY) changed the member names of prcm_regs from cm_l3init_usb_otg_ss_clkctrl to cm_l3init_usb_otg_ss1_clkctrl and from cm_coreaon_usb_phy_core_clkctrl to cm_coreaon_usb_phy1_core_clkctrl in order to differentiate between the two dwc3 controllers present in dra7xx/am43xx and enabled these clocks in enable_basic_clocks() in hw_data.c. However these clocks continued to be enabled in board files/driver files for dwc3 host mode functionality causing compilation break with few configs. Fixed it here by making all the clocks enabled in enable_basic_clocks() and removing it from board files/driver files here. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master
On Wed, Apr 15, 2015 at 05:05:02PM +0200, Hans de Goede wrote: Hi Tom, Please pull u-boot-sunxi/master into master for the first series of sunxi patches for v2015.07. This consists of a mix of bug-fixes, improvements and new boards. The following changes since commit f33cdaa4c3da4a8fd35aa2f9a3172f31cc887b35: Prepare v2015.04 (2015-04-13 10:53:03 -0400) are available in the git repository at: http://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 6c739c5d8a3466f8ef2f8543636484957bcca6ee: sunxi: Complete i2c support for each supported platform (2015-04-15 16:33:17 +0200) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] boards/t2080rdb: update ddr frequency from 1600MT/s to 1867MT/s
Shengzhou,
On 03/31/2015 11:45 PM, Shengzhou Liu wrote:
T2080RDB RevC uses new SODIMM 1867MT/s instead of previous 1600MT/s.
So update RCW to support new DDR frequency i.e 1867MT/s
This patch updates RCW. The subject is not clear.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
board/freescale/t208xrdb/t2080_rcw.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/freescale/t208xrdb/t2080_rcw.cfg
b/board/freescale/t208xrdb/t2080_rcw.cfg
index 59025ea..7c55150 100644
--- a/board/freescale/t208xrdb/t2080_rcw.cfg
+++ b/board/freescale/t208xrdb/t2080_rcw.cfg
@@ -9,8 +9,8 @@ aa55aa55 010e0100
# 0004
#For T2080 v1.1
-#SerDes=0x66_0x15, Core:1800MHz, DDR:1600MT/s
-1206001b 1500
+#SerDes=0x66_0x15, Core:1800MHz, DDR:1867MT/s
+1207001b 1500
66150002 e8104000 c100
0080 000307fc
0004
Are previous version boards still in use? Maybe you should consider to keep the
old value in comment so users can choose if needed?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx/T104xD4RDB: Add T104xD4RDB boards support
On 03/25/2015 07:46 AM, Vijay Rai wrote: snip diff --git a/configs/T1040D4RDB_NAND_defconfig b/configs/T1040D4RDB_NAND_defconfig new file mode 100644 index 000..8212b34 --- /dev/null +++ b/configs/T1040D4RDB_NAND_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1040,T1040D4RDB,RAMBOOT_PBL,SPL_FSL_PBL,NAND,T104XD4RDB,SYS_FSL_DDR4 ++S:CONFIG_PPC=y ++S:CONFIG_MPC85xx=y ++S:CONFIG_TARGET_T104XRDB=y diff --git a/configs/T1040D4RDB_SDCARD_defconfig b/configs/T1040D4RDB_SDCARD_defconfig new file mode 100644 index 000..d45c60c --- /dev/null +++ b/configs/T1040D4RDB_SDCARD_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1040,T1040D4RDB,RAMBOOT_PBL,SPL_FSL_PBL,SDCARD,T104XD4RDB,SYS_FSL_DDR4 ++S:CONFIG_PPC=y ++S:CONFIG_MPC85xx=y ++S:CONFIG_TARGET_T104XRDB=y diff --git a/configs/T1040D4RDB_SPIFLASH_defconfig b/configs/T1040D4RDB_SPIFLASH_defconfig new file mode 100644 index 000..d7ccacf --- /dev/null +++ b/configs/T1040D4RDB_SPIFLASH_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1040,T1040D4RDB,RAMBOOT_PBL,SPL_FSL_PBL,SPIFLASH,T104XD4RDB,SYS_FSL_DDR4 ++S:CONFIG_PPC=y ++S:CONFIG_MPC85xx=y ++S:CONFIG_TARGET_T104XRDB=y diff --git a/configs/T1040D4RDB_defconfig b/configs/T1040D4RDB_defconfig new file mode 100644 index 000..f9a23cf --- /dev/null +++ b/configs/T1040D4RDB_defconfig @@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1040,T1040D4RDB,T104XD4RDB,SYS_FSL_DDR4 +CONFIG_PPC=y +CONFIG_MPC85xx=y +CONFIG_TARGET_T104XRDB=y diff --git a/configs/T1042D4RDB_NAND_defconfig b/configs/T1042D4RDB_NAND_defconfig new file mode 100644 index 000..2ab2b15 --- /dev/null +++ b/configs/T1042D4RDB_NAND_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1042,T1042D4RDB,RAMBOOT_PBL,SPL_FSL_PBL,NAND,T104XD4RDB,SYS_FSL_DDR4 ++S:CONFIG_PPC=y ++S:CONFIG_MPC85xx=y ++S:CONFIG_TARGET_T104XRDB=y diff --git a/configs/T1042D4RDB_SDCARD_defconfig b/configs/T1042D4RDB_SDCARD_defconfig new file mode 100644 index 000..daba6b7 --- /dev/null +++ b/configs/T1042D4RDB_SDCARD_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1042,T1042D4RDB,RAMBOOT_PBL,SPL_FSL_PBL,SDCARD,T104XD4RDB,SYS_FSL_DDR4 ++S:CONFIG_PPC=y ++S:CONFIG_MPC85xx=y ++S:CONFIG_TARGET_T104XRDB=y diff --git a/configs/T1042D4RDB_SPIFLASH_defconfig b/configs/T1042D4RDB_SPIFLASH_defconfig new file mode 100644 index 000..0aa5178 --- /dev/null +++ b/configs/T1042D4RDB_SPIFLASH_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1042,T1042D4RDB,RAMBOOT_PBL,SPL_FSL_PBL,SPIFLASH,T104XD4RDB,SYS_FSL_DDR4 ++S:CONFIG_PPC=y ++S:CONFIG_MPC85xx=y ++S:CONFIG_TARGET_T104XRDB=y diff --git a/configs/T1042D4RDB_defconfig b/configs/T1042D4RDB_defconfig new file mode 100644 index 000..3802637 --- /dev/null +++ b/configs/T1042D4RDB_defconfig @@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS=PPC_T1042,T1042D4RDB,T104XD4RDB,SYS_FSL_DDR4 +CONFIG_PPC=y +CONFIG_MPC85xx=y +CONFIG_TARGET_T104XRDB=y Please do not use CONFIG_SYS_EXTRA_OPTIONS for new boards. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mmc: fsl_esdhc: Add adapter card type identification support
On 03/25/2015 10:52 PM, Yangbo Lu wrote: snip diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h index 313fa1e..5462b4c 100644 --- a/include/fsl_esdhc.h +++ b/include/fsl_esdhc.h @@ -16,6 +16,10 @@ /* needed for the mmc_cfg definition */ #include mmc.h +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT +#include ../board/freescale/common/qixis.h +#endif + /* FSL eSDHC-specific constants */ #define SYSCTL 0x0002e02c #define SYSCTL_INITA 0x0800 Please document CONFIG_FSL_ESDHC_ADAPTER_IDENT. If CONFIG_FSL_ESDHC_ADAPTER_IDENT implies QIXIS, please point it out. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] colibri_vf: Enable USB support for Colibri Vybrid
On Wednesday, April 15, 2015 at 12:54:28 PM, Sanchayan Maity wrote: Enable USB support on Toradex Colibri Vybrid Modules. Signed-off-by: Sanchayan Maity maitysancha...@gmail.com --- board/toradex/colibri_vf/colibri_vf.c | 25 +-- include/configs/colibri_vf.h | 37 +++ 2 files changed, 60 insertions(+), 2 deletions(-) diff --git a/board/toradex/colibri_vf/colibri_vf.c b/board/toradex/colibri_vf/colibri_vf.c index e7bc6c1..054e6f9 100644 --- a/board/toradex/colibri_vf/colibri_vf.c +++ b/board/toradex/colibri_vf/colibri_vf.c @@ -197,7 +197,8 @@ static void clock_init(void) clrsetbits_le32(ccm-ccgr0, CCM_REG_CTRL_MASK, CCM_CCGR0_UART0_CTRL_MASK); clrsetbits_le32(ccm-ccgr1, CCM_REG_CTRL_MASK, - CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK); + CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK | + CCM_CCGR1_USBC0_CTRL_MASK); You probably want to flip these CCM regs only if CONFIG_CI_UDC is enabled or something along those lines, right ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/13] Add Marvell Armada A38x 88F6820 SoC support
On 04/14/2015 05:46 AM, Stefan Roese wrote: This patch series adds support for the Marvell Armada A38x SoC's. Specifically the 88F6820 / 88F6828. Basic support for the DB-88F6820-GP evaluation board is added. Supporting the following interfaces: - UART - SPI (including SPI NOR flash) - I2C - Ethernet (neta) One big part of this new SoC support is the move of the already exisiting Armada XP support into the mach-mvebu directory. With this move its easier to re-use this code for the A38x, which is pretty similar to the AXP. Thanks, Stefan Tested-by: Kevin Smith kevin.sm...@elecsyscorp.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] sunxi: Fix end of kernel memory alignment for A33
Hi, On 16-04-15 19:35, Mark Rutland wrote: On Thu, Apr 16, 2015 at 08:32:03AM +0100, Hans de Goede wrote: Hi, On 15-04-15 21:57, Ian Campbell wrote: On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote: For unknown reasons the A33 needs the end of the memory we report to the kernel to be aligned to a multiple of 4 MiB. Do you really mean the A33 needs (as in the processor itself) or do you actually mean the A33 kernel port? If the latter than can't that be investigated/fixed instead of hacked here? That would be far more preferable. I mean the former, it seems that the SoC itself cannot handle dram ranges with different cache policies which are not aligned to 4 MiB, at least that is my WAG what is going on here. That sounds incredibly suspicious. What do you mean w.r.t. different cache policies -- what does that have to do with the end of DRAM? We carve out a framebuffer at the end of DRAM, and then report less DRAM then we actually have to the kernel. This framebuffer then gets picked up by the kernel through simplefb, which will map it with a different cache policy then the normal part of the DRAM has. What problem do you see? Depending on the framebuffer-size the kernel either boots or does not boot, when it does not boot it does nothing (I've a serial console) earlyprintk does not help, I was looking into setting up an early console (should be a matter of just putting in the right parameters) when I found out that if I modify the framebuffer size that fixes things. After experimenting more it seems that keeping the last pixel of the framebuffer at the very end of DRAM is not a problem (so this does not seem to be a display engine problem), things start to work when I make the carve out at the end bigger. On the very similar A23 giving the kernel all of the DRAM except for the framebuffer (aligned to a multiple of 4k) works just fine. Sometimes I can get away with just making the carve-out bigger without aligning it to a multiple of 4 MiB, but an alignment to 4 MiB seems to always work independent of the framebuffer size. It would be worth reporting this on lakml. If you still think that after the above explanation I'll start a new thread on lakml with contents more targeted at kernel devs. I've been using an a23 dtb + generic multi-platform kernel for my testing (as said before the a33 really is almost the same design), and that boots fine without this alignment hack on an actual A23 device, so this is not a kernel limitation. Not necessarily. Is RAM at the same location on both SoCs? What about other devices and carevouts? Everything is the same on both SoCs except that one has 2 Cortex A7 cores and the new one with the problem has 4 Cortex A7 cores, and a new dram controller / mbus subsystem to keep the 4 cores fed. It could be htat the stars happen to align and we're finally caught out by some dodgy maths. I don't think that that is the case here. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] ARM: zynq: use separate configuration for ZC702 and ZC706
Hi Sören,
2015-04-15 1:03 GMT+09:00 Sören Brinkmann soren.brinkm...@xilinx.com:
On Tue, 2015-04-14 at 04:50PM +0900, Masahiro Yamada wrote:
Separate CONFIG_TARGET_ZYNQ_{ZC702,ZC706} which is necessary
for the next commit. Adjust doc/README.zynq too.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
Changes in v2: None
arch/arm/cpu/armv7/zynq/Kconfig| 9 ++---
configs/{zynq_zc70x_defconfig = zynq_zc702_defconfig} | 2 +-
configs/zynq_zc706_defconfig | 11 +++
doc/README.zynq| 15 ---
4 files changed, 22 insertions(+), 15 deletions(-)
rename configs/{zynq_zc70x_defconfig = zynq_zc702_defconfig} (88%)
create mode 100644 configs/zynq_zc706_defconfig
diff --git a/arch/arm/cpu/armv7/zynq/Kconfig
b/arch/arm/cpu/armv7/zynq/Kconfig
index 3a52535..ab4768a 100644
--- a/arch/arm/cpu/armv7/zynq/Kconfig
+++ b/arch/arm/cpu/armv7/zynq/Kconfig
@@ -9,8 +9,11 @@ config TARGET_ZYNQ_ZED
config TARGET_ZYNQ_MICROZED
bool Zynq MicroZed
-config TARGET_ZYNQ_ZC70X
- bool Zynq ZC702/ZC706 Board
+config TARGET_ZYNQ_ZC702
+ bool Zynq ZC702 Board
+
+config TARGET_ZYNQ_ZC706
+ bool Zynq ZC706 Board
Is there a good way to make this more friendly towards a user who is
familiar with the current flow? By simply removing it, we'll get plenty
of support requests asking what happened. Also, it would void all the
documentation we have in wikis etc. A more soft migration path would be
better.
Currently, the difference between ZC702 and ZC706 is just their device trees.
So, we can use $(DEVICE_TREE) for distinguishing one from the other. Like this.
8---
DEVICE_TREE ?= $(CONFIG_DEFAULT_DEVICE_TREE:%=%)
hw-platform-$(CONFIG_TARGET_ZYNQ_ZED) := zed_hw_platform
hw-platform-$(CONFIG_TARGET_ZYNQ_MICROZED) := MicroZed_hw_platform
hw-platform-$(CONFIG_TARGET_ZYNQ_ZC70X) := $(if $(filter
zynq-zc702 $(DEVICE_TREE)), ZC702_hw_platform, ZC706_hw_platform)
8---
Another option is to reject this series and stick to the current work-flow.
It is up to you and Michal, of course.
The path to ps7_init_gpl.[ch] will change, anyway.
If it is troublesome, I do not persist on this series.
--
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 2/4] powerpc/t2080qds: enable eSDHC adapter card type identification
Enable eSDHC adapter card type identification and this will do some corresponding operations and set 'adapter-type' property for device tree according SDHC Card ID. Signed-off-by: Yangbo Lu yangbo...@freescale.com Cc: York Sun york...@freescale.com --- include/configs/T208xQDS.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h index ff6d2c1..8d6918a 100644 --- a/include/configs/T208xQDS.h +++ b/include/configs/T208xQDS.h @@ -764,6 +764,7 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION +#define CONFIG_FSL_ESDHC_ADAPTER_IDENT #endif -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] mmc: fsl_esdhc: Add adapter card type identification support
Add adapter card type identification support by reading
FPGA STAT_PRES1 register SDHC Card ID[0:2] bits. To use this function,
define CONFIG_FSL_ESDHC_ADAPTER_IDENT.
Signed-off-by: Yangbo Lu yangbo...@freescale.com
Cc: York Sun york...@freescale.com
---
Changes for v2:
- Document CONFIG_FSL_ESDHC_ADAPTER_IDENT
---
arch/powerpc/include/asm/global_data.h | 3 +++
board/freescale/common/qixis.h | 14 +
doc/README.fsl-esdhc | 25 ++
drivers/mmc/fsl_esdhc.c| 38 +-
drivers/mmc/mmc.c | 6 ++
drivers/mmc/mmc_private.h | 3 +++
include/fsl_esdhc.h| 4
7 files changed, 88 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/global_data.h
b/arch/powerpc/include/asm/global_data.h
index c57d9c0..4090975 100644
--- a/arch/powerpc/include/asm/global_data.h
+++ b/arch/powerpc/include/asm/global_data.h
@@ -15,6 +15,9 @@
struct arch_global_data {
#if defined(CONFIG_FSL_ESDHC)
u32 sdhc_clk;
+#if defined(CONFIG_FSL_ESDHC_ADAPTER_IDENT)
+ u8 sdhc_adapter;
+#endif
#endif
#if defined(CONFIG_8xx)
unsigned long brg_clk;
diff --git a/board/freescale/common/qixis.h b/board/freescale/common/qixis.h
index 52d2021..51ce9c3 100644
--- a/board/freescale/common/qixis.h
+++ b/board/freescale/common/qixis.h
@@ -115,4 +115,18 @@ void qixis_write_i2c(unsigned int reg, u8 value);
qixis_write_i2c(offsetof(struct qixis, reg), value)
#endif
+/* Use for SDHC adapter card type identification and operation */
+#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
+#define QIXIS_SDID_MASK 0x07
+#define QIXIS_ESDHC_ADAPTER_TYPE_EMMC45 0x1/* eMMC Card Rev4.5 */
+#define QIXIS_ESDHC_ADAPTER_TYPE_SDMMC_LEGACY 0x2/* SD/MMC Legacy Card */
+#define QIXIS_ESDHC_ADAPTER_TYPE_EMMC44 0x3/* eMMC Card Rev4.4 */
+#define QIXIS_ESDHC_ADAPTER_TYPE_RSV0x4/* Reserved */
+#define QIXIS_ESDHC_ADAPTER_TYPE_MMC0x5/* MMC Card */
+#define QIXIS_ESDHC_ADAPTER_TYPE_SD 0x6/* SD Card Rev2.0 3.0 */
+#define QIXIS_ESDHC_NO_ADAPTER 0x7/* No Card is Present*/
+#define QIXIS_SDCLKIN 0x08
+#define QIXIS_SDCLKOUT 0x02
+#endif
+
#endif
diff --git a/doc/README.fsl-esdhc b/doc/README.fsl-esdhc
index b70f271..29cc661 100644
--- a/doc/README.fsl-esdhc
+++ b/doc/README.fsl-esdhc
@@ -1,5 +1,22 @@
-CONFIG_SYS_FSL_ESDHC_LE means ESDHC IP is in little-endian mode.
-CONFIG_SYS_FSL_ESDHC_BE means ESDHC IP is in big-endian mode.
+Freescale esdhc-specific options
-Accessing ESDHC registers can be determined by ESDHC IP's endian
-mode or processor's endian mode.
+ - CONFIG_FSL_ESDHC_ADAPTER_IDENT
+ Support Freescale adapter card type identification. This is
implemented by
+ operating Qixis FPGA relevant registers. The STAT_PRES1
register has SDHC
+ Card ID[0:2] bits showing the type of card installed in the
SDHC Adapter Slot.
+
+ SDHC Card ID[0:2] Adapter Card Type
+ 0b000 reserved
+ 0b001 eMMC Card Rev4.5
+ 0b010 SD/MMC Legacy Card
+ 0b011 eMMC Card Rev4.4
+ 0b100 reserved
+ 0b101 MMC Card
+ 0b110 SD Card Rev2.0/3.0
+ 0b111 No card is present
+ - CONFIG_SYS_FSL_ESDHC_LE
+ ESDHC IP is in little-endian mode. Accessing ESDHC registers
can be
+ determined by ESDHC IP's endian mode or processor's endian mode.
+ - CONFIG_SYS_FSL_ESDHC_BE
+ ESDHC IP is in big-endian mode. Accessing ESDHC registers can
be determined
+ by ESDHC IP's endian mode or processor's endian mode.
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index f5d2ccb..355cada 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -643,6 +643,39 @@ int fsl_esdhc_mmc_init(bd_t *bis)
return fsl_esdhc_initialize(bis, cfg);
}
+#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
+void mmc_adapter_card_type_ident(void)
+{
+ u8 card_id;
+ u8 value;
+
+ card_id = QIXIS_READ(present) QIXIS_SDID_MASK;
+ gd-arch.sdhc_adapter = card_id;
+
+ switch (card_id) {
+ case QIXIS_ESDHC_ADAPTER_TYPE_EMMC45:
+ break;
+ case QIXIS_ESDHC_ADAPTER_TYPE_SDMMC_LEGACY:
+ break;
+ case QIXIS_ESDHC_ADAPTER_TYPE_EMMC44:
+ value = QIXIS_READ(brdcfg[5]);
+ value |= (QIXIS_SDCLKIN | QIXIS_SDCLKOUT);
+ QIXIS_WRITE(brdcfg[5], value);
+ break;
+ case QIXIS_ESDHC_ADAPTER_TYPE_RSV:
+ break;
+ case QIXIS_ESDHC_ADAPTER_TYPE_MMC:
+
[U-Boot] [PATCH v2 4/4] powerpc/t2080qds: enable eSDHC peripheral clock support for kernel
Enable eSDHC peripheral clock support for kernel, and linux will use SD clock generated by peripheral clock instead of platform clock. Signed-off-by: Yangbo Lu yangbo...@freescale.com Cc: York Sun york...@freescale.com --- include/configs/T208xQDS.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h index 8d6918a..ea8f89a 100644 --- a/include/configs/T208xQDS.h +++ b/include/configs/T208xQDS.h @@ -757,6 +757,7 @@ unsigned long get_board_ddr_clk(void); #ifdef CONFIG_MMC #define CONFIG_CMD_MMC #define CONFIG_FSL_ESDHC +#define define CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK #define CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_MPC85xx_ESDHC_ADDR #define CONFIG_SYS_FSL_ESDHC_BROKEN_TIMEOUT #define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33 -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush
Hi Mark, -Original Message- From: Mark Rutland [mailto:mark.rutl...@arm.com] Sent: Thursday, April 16, 2015 3:29 PM To: Siva Durga Prasad Paladugu Cc: Michal Simek; u-boot@lists.denx.de; Tom Rini; Varun Sethi; Arnab Basu; York Sun Subject: Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush On Thu, Apr 16, 2015 at 06:17:59AM +0100, Siva Durga Prasad Paladugu wrote: Hi Mark. -Original Message- From: Mark Rutland [mailto:mark.rutl...@arm.com] Sent: Wednesday, April 15, 2015 6:41 PM To: Michal Simek Cc: u-boot@lists.denx.de; Tom Rini; Siva Durga Prasad Paladugu; Varun Sethi; Arnab Basu; York Sun Subject: Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush On Wed, Apr 15, 2015 at 12:33:00PM +0100, Michal Simek wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Always disable dcache after the flush operation The following sequence is advisable while disabling d-cache: 1. disable_dcache() - flushes and disables d-cache 2. invalidate_dcache_all() - invalid any entry that came to the cache in the short period after the cache was flushed but before the cache got disabled For reasons I have described previously (see [1,2,3]), this is unsafe. The first cache flush may achieve nothing. If you need data out at the PoC before disabling the cache, then you should first use maintenance by VA to push that data out. Thanks, Mark. [1] http://lists.denx.de/pipermail/u-boot/2015-February/204403.html [2] http://lists.denx.de/pipermail/u-boot/2015-February/204407.html [3] http://lists.denx.de/pipermail/u-boot/2015-February/204702.html Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/arm/cpu/armv8/cache_v8.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index c5ec5297cd39..2a0492fbef52 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -128,10 +128,10 @@ void dcache_disable(void) if (!(sctlr CR_C)) return; - set_sctlr(sctlr ~(CR_C|CR_M)); - flush_dcache_all(); __asm_invalidate_tlb_all(); + + set_sctlr(sctlr ~(CR_C|CR_M)); I got your point. But here in this scenario also there is an issue with disable first and then flush_dcache_all(). This is because when we disable the cache and invoke the c routine flush_dcache_all() then the return address of this is stored in a stack(in memory as dcache is disabled). Which is why this sequence cannot be written in C, and needs to be performed in assembly, without any memory accesses between the write to the SCTLR and the cache flush. Now in the flush_dcache_all we are invoking the actual asm call to flush dcache which may wipeout the stored return value in stack with cahe contents(main memory). Hence the return from the flush_dcahe_all will fail. To confirm this I modified the dcache_disable in the below way and it worked fine. 1. Disable the dcache. 2. Now I called the __asm_flush_dcache_all(); and then flush_l3_cache(); instead of calling the flush_dcache_all(). That also is unsafe; implicit (e.g. stack) accesses at any point after SCTLR.C is cleared and before flush_l3_cache() has completed may see stale data, or get overwritten by stale data. Set/Way ops only flush the CPU-local caches, so you only guarantee that these are clean (and potentially dirty cache lines for the stack could be sat in L3 and written back at any time). So your flush_l3_cache() function might not work. Per ARMv8 the L3 _must_ respect maintenance by VA, so after disabling the MMU you can flush the memory region corresponding to your stack (and any other data you need) by VA to the PoC before executing flush_l3_cache(), in addition to the Set/Way ops used to empty the CPU-local caches. Thanks for explanation. So in that case, the flushing of the required stack or any other data which needs to be flushed should be part of board specific. Am I correct? If yes, then this disable_dcache() should contain a asm call to a routine() (which might be board specific) after disabling the cache to flush the required data and then flush_dcache_all() followed by flush L3 cache.. The current implementation just didn't work. It worked for me with the changes i mentioned in my last mail as I don't have L3 cache in my case. Regards, Siva Thanks, Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] mmc: fsl_esdhc: Add peripheral clock support for kernel
The SD clock could be generated by platform clock or peripheral
clock for some platforms. This patch adds peripheral clock
support for kernel for T1024/T1040/T2080. To enable it,
define CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK.
Signed-off-by: Yangbo Lu yangbo...@freescale.com
Cc: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/speed.c | 49 ++-
arch/powerpc/include/asm/config_mpc85xx.h | 10 +--
drivers/mmc/fsl_esdhc.c | 5
include/e500.h| 1 +
4 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 7e69873..79202bb 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -69,7 +69,8 @@ void get_sys_info(sys_info_t *sys_info)
[14] = 4, /* CC4 PPL / 4 */
};
uint i, freq_c_pll[CONFIG_SYS_FSL_NUM_CC_PLLS];
-#if !defined(CONFIG_FM_PLAT_CLK_DIV) || !defined(CONFIG_PME_PLAT_CLK_DIV)
+#if !defined(CONFIG_FM_PLAT_CLK_DIV) || !defined(CONFIG_PME_PLAT_CLK_DIV) || \
+ defined(CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK)
uint rcw_tmp;
#endif
uint ratio[CONFIG_SYS_FSL_NUM_CC_PLLS];
@@ -313,6 +314,48 @@ void get_sys_info(sys_info_t *sys_info)
#endif
#endif
+#ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
+#if defined(CONFIG_PPC_T2080)
+#define ESDHC_CLK_SEL 0x0007
+#define ESDHC_CLK_SHIFT0
+#define ESDHC_CLK_RCWSR15
+#else /* Support T1040 T1024 by now */
+#define ESDHC_CLK_SEL 0xe000
+#define ESDHC_CLK_SHIFT29
+#define ESDHC_CLK_RCWSR7
+#endif
+ rcw_tmp = in_be32(gur-rcwsr[ESDHC_CLK_RCWSR]);
+ switch ((rcw_tmp ESDHC_CLK_SEL) ESDHC_CLK_SHIFT) {
+ case 1:
+ sys_info-freq_sdhc = freq_c_pll[CONFIG_SYS_SDHC_CLK];
+ break;
+ case 2:
+ sys_info-freq_sdhc = freq_c_pll[CONFIG_SYS_SDHC_CLK] / 2;
+ break;
+ case 3:
+ sys_info-freq_sdhc = freq_c_pll[CONFIG_SYS_SDHC_CLK] / 3;
+ break;
+#if defined(CONFIG_SYS_SDHC_CLK_2_PLL)
+ case 4:
+ sys_info-freq_sdhc = freq_c_pll[CONFIG_SYS_SDHC_CLK] / 4;
+ break;
+#if defined(CONFIG_PPC_T2080)
+ case 5:
+ sys_info-freq_sdhc = freq_c_pll[1 - CONFIG_SYS_SDHC_CLK];
+ break;
+#endif
+ case 6:
+ sys_info-freq_sdhc = freq_c_pll[1 - CONFIG_SYS_SDHC_CLK] / 2;
+ break;
+ case 7:
+ sys_info-freq_sdhc = freq_c_pll[1 - CONFIG_SYS_SDHC_CLK] / 3;
+ break;
+#endif
+ default:
+ sys_info-freq_sdhc = 0;
+ printf(Error: Unknown SDHC peripheral clock select!\n);
+ }
+#endif
#else /* CONFIG_SYS_FSL_QORIQ_CHASSIS2 */
for_each_cpu(i, cpu, cpu_numcores(), cpu_mask()) {
@@ -520,12 +563,16 @@ int get_clocks (void)
gd-arch.i2c2_clk = gd-arch.i2c1_clk;
#if defined(CONFIG_FSL_ESDHC)
+#ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
+ gd-arch.sdhc_clk = sys_info.freq_sdhc / 2;
+#else
#if defined(CONFIG_MPC8569) || defined(CONFIG_P1010) ||\
defined(CONFIG_P1014)
gd-arch.sdhc_clk = gd-bus_clk;
#else
gd-arch.sdhc_clk = gd-bus_clk / 2;
#endif
+#endif
#endif /* defined(CONFIG_FSL_ESDHC) */
#if defined(CONFIG_CPM2)
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 01b0905..24c593b 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -757,7 +757,6 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
#endif
#define CONFIG_SYS_FSL_NUM_CC_PLLS 2
#define CONFIG_SYS_FSL_CLUSTER_CLOCKS { 1, 1, 1, 1 }
-#define CONFIG_SYS_SDHC_CLOCK 0
#define CONFIG_SYS_FSL_NUM_LAWS16
#define CONFIG_SYS_FSL_SRDS_1
#define CONFIG_SYS_FSL_SEC_COMPAT 5
@@ -773,6 +772,9 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
#define CONFIG_SYS_FMAN_V3
#define CONFIG_FM_PLAT_CLK_DIV 1
#define CONFIG_SYS_FM1_CLK CONFIG_FM_PLAT_CLK_DIV
+#define CONFIG_SYS_SDHC_CLK0/* Select SDHC CLK begining from PLL1
+ per rcw field value */
+#define CONFIG_SYS_SDHC_CLK_2_PLL /* Select SDHC CLK from 2 PLLs */
#define CONFIG_SYS_FM_MURAM_SIZE 0x3
#define CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
#define CONFIG_SYS_FSL_TBCLK_DIV 16
@@ -805,7 +807,6 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
#endif
#define CONFIG_SYS_FSL_NUM_CC_PLL 2
#define CONFIG_SYS_FSL_CLUSTER_CLOCKS { 1, 1, 1, 1 }
-#define CONFIG_SYS_SDHC_CLOCK 0
#define CONFIG_SYS_FSL_NUM_LAWS16
#define CONFIG_SYS_FSL_SRDS_1
#define CONFIG_SYS_FSL_SEC_COMPAT 5
@@ -818,6 +819,8 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
#define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0
Re: [U-Boot] [PATCH 4/6] zynqmp: Add SPI driver support for ZynqMP
On 04/16/2015 08:13 PM, Jagan Teki wrote: On 15 April 2015 at 19:03, Michal Simek michal.si...@xilinx.com wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Added the SPI driver support for ZynqMP The controller is same as zynq SPI controller Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/arm/include/asm/arch-zynqmp/hardware.h | 3 +++ include/configs/xilinx_zynqmp.h | 8 2 files changed, 11 insertions(+) diff --git a/arch/arm/include/asm/arch-zynqmp/hardware.h b/arch/arm/include/asm/arch-zynqmp/hardware.h index 1fedb1bb4b94..c9dc49d78317 100644 --- a/arch/arm/include/asm/arch-zynqmp/hardware.h +++ b/arch/arm/include/asm/arch-zynqmp/hardware.h @@ -11,6 +11,9 @@ #define ZYNQ_SERIAL_BASEADDR0 0xFF00 #define ZYNQ_SERIAL_BASEADDR1 0xFF001000 +#define ZYNQ_SPI_BASEADDR0 0xFF04 +#define ZYNQ_SPI_BASEADDR1 0xFF05 + #define ZYNQ_I2C_BASEADDR0 0xFF02 #define ZYNQ_I2C_BASEADDR1 0xFF03 diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 54bca6d47b72..df7541b85baf 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -71,6 +71,14 @@ #define CONFIG_CMD_ELF #define CONFIG_MP +/* SPI */ +#ifdef CONFIG_ZYNQ_SPI +# define CONFIG_SPI_FLASH +# define CONFIG_SPI_FLASH_SST +# define CONFIG_CMD_SPI CMD_SPI is never been verified I suppose, if so not required at this point of time. It is enabled on 75 platforms that's why I can't see any problem with it. If something is not verified then it should be verified. If it is completely broken it should be removed. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] armv8:Add SMC calls infrastructure
This commit adds functions issuing calls to firmware. This allows
to use services such as PSCI provided by firmware, e.g. ATF
Signed-off-by: Sergey Temerkhanov s.temerkha...@gmail.com
Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
---
arch/arm/cpu/armv8/Makefile | 1 +
arch/arm/cpu/armv8/fwcall.c | 79 +++
arch/arm/include/asm/system.h | 8 +
3 files changed, 88 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fwcall.c
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index dee5e25..208d012 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -14,6 +14,7 @@ obj-y += exceptions.o
obj-y += cache.o
obj-y += tlb.o
obj-y += transition.o
+obj-y += fwcall.o
obj-$(CONFIG_FSL_LSCH3) += fsl-lsch3/
obj-$(CONFIG_TARGET_XILINX_ZYNQMP) += zynqmp/
diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
new file mode 100644
index 000..fde3c06
--- /dev/null
+++ b/arch/arm/cpu/armv8/fwcall.c
@@ -0,0 +1,79 @@
+/**
+ * (C) Copyright 2014, Cavium Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+**/
+
+#include asm-offsets.h
+#include config.h
+#include version.h
+#include asm/macro.h
+#include asm/system.h
+
+#define __asmeq(x, y) .ifnc x , y ; .err ; .endif\n\t
+
+/*
+ * void hvc_call(arg0, arg1...arg7)
+ *
+ * issue the hypervisor call
+ *
+ * x0~x7: argument list
+ */
+void hvc_call(struct pt_regs *args)
+{
+ asm volatile(
+ ldr x0, %0\n
+ ldr x1, %1\n
+ ldr x2, %2\n
+ ldr x3, %3\n
+ ldr x4, %4\n
+ ldr x5, %5\n
+ ldr x6, %6\n
+ ldr x7, %7\n
+ hvc#0\n
+ str x0, %0\n
+ str x1, %1\n
+ str x2, %2\n
+ str x3, %3\n
+ : +m (args-regs[0]), +m (args-regs[1]),
+ +m (args-regs[2]), +m (args-regs[3])
+ : m (args-regs[0]), m (args-regs[1]),
+ m (args-regs[2]), m (args-regs[3]),
+ m (args-regs[4]), m (args-regs[5]),
+ m (args-regs[6]), m (args-regs[7])
+ : x0, x1, x2, x3, x4, x5, x6, x7);
+}
+
+/*
+ * void smc_call(arg0, arg1...arg7)
+ *
+ * issue the secure monitor call
+ *
+ * x0~x7: argument list
+ */
+
+void smc_call(struct pt_regs *args)
+{
+ asm volatile(
+ ldr x0, %0\n
+ ldr x1, %1\n
+ ldr x2, %2\n
+ ldr x3, %3\n
+ ldr x4, %4\n
+ ldr x5, %5\n
+ ldr x6, %6\n
+ ldr x7, %7\n
+ smc#0\n
+ str x0, %0\n
+ str x1, %1\n
+ str x2, %2\n
+ str x3, %3\n
+ : +m (args-regs[0]), +m (args-regs[1]),
+ +m (args-regs[2]), +m (args-regs[3])
+ : m (args-regs[0]), m (args-regs[1]),
+ m (args-regs[2]), m (args-regs[3]),
+ m (args-regs[4]), m (args-regs[5]),
+ m (args-regs[6]), m (args-regs[7])
+ : x0, x1, x2, x3, x4, x5, x6, x7);
+}
+
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index b778a6c..aac15cc 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -1,6 +1,9 @@
#ifndef __ASM_ARM_SYSTEM_H
#define __ASM_ARM_SYSTEM_H
+#include common.h
+#include linux/compiler.h
+
#ifdef CONFIG_ARM64
/*
@@ -85,6 +88,11 @@ void smp_kick_all_cpus(void);
void flush_l3_cache(void);
+#define __asmeq(x, y) .ifnc x , y ; .err ; .endif\n\t
+
+void hvc_call(struct pt_regs *args);
+void smc_call(struct pt_regs *args);
+
#endif /* __ASSEMBLY__ */
#else /* CONFIG_ARM64 */
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] armv8: cavium: Add ThunderX 88xx board definition
This commit adds basic Cavium ThunderX 88xx board definitions and support.
Signed-off-by: Sergey Temerkhanov s.temerkha...@gmail.com
Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
---
arch/arm/Kconfig | 4 +
board/cavium/thunderx/Kconfig| 19 +
board/cavium/thunderx/Makefile | 8 ++
board/cavium/thunderx/thunderx.c | 59 +
configs/thunderx_88xx_defconfig | 3 +
include/configs/thunderx_88xx.h | 173 +++
6 files changed, 266 insertions(+)
create mode 100644 board/cavium/thunderx/Kconfig
create mode 100644 board/cavium/thunderx/Makefile
create mode 100644 board/cavium/thunderx/thunderx.c
create mode 100644 configs/thunderx_88xx_defconfig
create mode 100644 include/configs/thunderx_88xx.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7ed0e20..858a15a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -727,6 +727,9 @@ config ARCH_UNIPHIER
select SPL
select OF_CONTROL
+config TARGET_THUNDERX_88XX
+ bool Support ThunderX 88xx
+
endchoice
source arch/arm/mach-at91/Kconfig
@@ -887,6 +890,7 @@ source board/work-microwave/work_92105/Kconfig
source board/xaeniax/Kconfig
source board/xilinx/zynqmp/Kconfig
source board/zipitz2/Kconfig
+source board/cavium/thunderx/Kconfig
source arch/arm/Kconfig.debug
diff --git a/board/cavium/thunderx/Kconfig b/board/cavium/thunderx/Kconfig
new file mode 100644
index 000..3e62abf
--- /dev/null
+++ b/board/cavium/thunderx/Kconfig
@@ -0,0 +1,19 @@
+if TARGET_THUNDERX_88XX
+
+config SYS_CPU
+ string
+ default armv8
+
+config SYS_BOARD
+ string
+ default thunderx
+
+config SYS_VENDOR
+ string
+ default cavium
+
+config SYS_CONFIG_NAME
+ string
+ default thunderx_88xx
+
+endif
diff --git a/board/cavium/thunderx/Makefile b/board/cavium/thunderx/Makefile
new file mode 100644
index 000..306044a
--- /dev/null
+++ b/board/cavium/thunderx/Makefile
@@ -0,0 +1,8 @@
+#
+#
+# (C) Copyright 2014, Cavium Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := thunderx.o
diff --git a/board/cavium/thunderx/thunderx.c b/board/cavium/thunderx/thunderx.c
new file mode 100644
index 000..5a5e259
--- /dev/null
+++ b/board/cavium/thunderx/thunderx.c
@@ -0,0 +1,59 @@
+/**
+ * (C) Copyright 2014, Cavium Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+**/
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include linux/compiler.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+ /*
+* Clear spin table so that secondary processors
+* observe the correct value after waken up from wfe.
+*/
+ *(unsigned long *)CPU_RELEASE_ADDR = 0;
+
+ gd-ram_size = PHYS_SDRAM_1_SIZE;
+ return 0;
+}
+
+int timer_init(void)
+{
+ return 0;
+}
+
+/*
+ * Board specific reset that is system reset.
+ */
+void reset_cpu(ulong addr)
+{
+}
+
+/*
+ * Board specific ethernet initialization routine.
+ */
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+
+ return rc;
+}
+
+#ifdef CONFIG_PCI
+void pci_init_board(void)
+{
+ printf(DEBUG: PCI Init TODO *\n);
+}
+#endif
+
diff --git a/configs/thunderx_88xx_defconfig b/configs/thunderx_88xx_defconfig
new file mode 100644
index 000..79fa65a
--- /dev/null
+++ b/configs/thunderx_88xx_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS=ARM64
+CONFIG_ARM=y
+CONFIG_TARGET_THUNDERX_88XX=y
diff --git a/include/configs/thunderx_88xx.h b/include/configs/thunderx_88xx.h
new file mode 100644
index 000..d5f5a6c
--- /dev/null
+++ b/include/configs/thunderx_88xx.h
@@ -0,0 +1,173 @@
+/**
+ * (C) Copyright 2014, Cavium Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+**/
+
+#ifndef __THUNDERX_88XX_H__
+#define __THUNDERX_88XX_H__
+
+#define CONFIG_REMAKE_ELF
+
+/*#define CONFIG_GICV3*/
+
+/*#define CONFIG_ARMV8_SWITCH_TO_EL1*/
+
+#define CONFIG_SYS_GENERIC_BOARD
+
+#define CONFIG_SYS_NO_FLASH
+
+/*#define CONFIG_SUPPORT_RAW_INITRD */
+
+/* Cache Definitions */
+/*
+#define CONFIG_SYS_DCACHE_OFF
+#define CONFIG_SYS_ICACHE_OFF
+*/
+
+#define CONFIG_IDENT_STRING\
+for Cavium Thunder CN88XX ARM v8 Multi-Core
+#define CONFIG_BOOTP_VCI_STRINGDiagnostics
+
+#define MEM_BASE 0x0050
+
+#define CONFIG_SYS_MEM_MAP {{0xUL, 0x400UL, \
+ MT_NORMAL}, \
+{0x8000UL, 0x400UL, \
+ MT_DEVICE_NGNRNE}, \
+{0x8400UL, 0x400UL, \
+ MT_DEVICE_NGNRNE}, \
+{0xUL, 0xfffUL, \
+ MT_DEVICE_NGNRNE},}
+
+#define CONFIG_SYS_MEM_MAP_SIZE3
+
+#define
[U-Boot] [PATCH 3/7] armv8:Add psci.h from the Linux kernel
This commit adds the psci.h header file from Linux kernel which contains definitions related to the PSCI interface provided by firmware Signed-off-by: Sergey Temerkhanov s.temerkha...@gmail.com Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com --- include/linux/psci.h | 90 1 file changed, 90 insertions(+) create mode 100644 include/linux/psci.h diff --git a/include/linux/psci.h b/include/linux/psci.h new file mode 100644 index 000..310d83e --- /dev/null +++ b/include/linux/psci.h @@ -0,0 +1,90 @@ +/* + * ARM Power State and Coordination Interface (PSCI) header + * + * This header holds common PSCI defines and macros shared + * by: ARM kernel, ARM64 kernel, KVM ARM/ARM64 and user space. + * + * Copyright (C) 2014 Linaro Ltd. + * Author: Anup Patel anup.pa...@linaro.org + */ + +#ifndef _UAPI_LINUX_PSCI_H +#define _UAPI_LINUX_PSCI_H + +/* + * PSCI v0.1 interface + * + * The PSCI v0.1 function numbers are implementation defined. + * + * Only PSCI return values such as: SUCCESS, NOT_SUPPORTED, + * INVALID_PARAMS, and DENIED defined below are applicable + * to PSCI v0.1. + */ + +/* PSCI v0.2 interface */ +#define PSCI_0_2_FN_BASE 0x8400 +#define PSCI_0_2_FN(n) (PSCI_0_2_FN_BASE + (n)) +#define PSCI_0_2_64BIT 0x4000 +#define PSCI_0_2_FN64_BASE \ + (PSCI_0_2_FN_BASE + PSCI_0_2_64BIT) +#define PSCI_0_2_FN64(n) (PSCI_0_2_FN64_BASE + (n)) + +#define PSCI_0_2_FN_PSCI_VERSION PSCI_0_2_FN(0) +#define PSCI_0_2_FN_CPU_SUSPENDPSCI_0_2_FN(1) +#define PSCI_0_2_FN_CPU_OFFPSCI_0_2_FN(2) +#define PSCI_0_2_FN_CPU_ON PSCI_0_2_FN(3) +#define PSCI_0_2_FN_AFFINITY_INFO PSCI_0_2_FN(4) +#define PSCI_0_2_FN_MIGRATEPSCI_0_2_FN(5) +#define PSCI_0_2_FN_MIGRATE_INFO_TYPE PSCI_0_2_FN(6) +#define PSCI_0_2_FN_MIGRATE_INFO_UP_CPUPSCI_0_2_FN(7) +#define PSCI_0_2_FN_SYSTEM_OFF PSCI_0_2_FN(8) +#define PSCI_0_2_FN_SYSTEM_RESET PSCI_0_2_FN(9) + +#define PSCI_0_2_FN64_CPU_SUSPEND PSCI_0_2_FN64(1) +#define PSCI_0_2_FN64_CPU_ON PSCI_0_2_FN64(3) +#define PSCI_0_2_FN64_AFFINITY_INFOPSCI_0_2_FN64(4) +#define PSCI_0_2_FN64_MIGRATE PSCI_0_2_FN64(5) +#define PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU PSCI_0_2_FN64(7) + +/* PSCI v0.2 power state encoding for CPU_SUSPEND function */ +#define PSCI_0_2_POWER_STATE_ID_MASK 0x +#define PSCI_0_2_POWER_STATE_ID_SHIFT 0 +#define PSCI_0_2_POWER_STATE_TYPE_SHIFT16 +#define PSCI_0_2_POWER_STATE_TYPE_MASK \ + (0x1 PSCI_0_2_POWER_STATE_TYPE_SHIFT) +#define PSCI_0_2_POWER_STATE_AFFL_SHIFT24 +#define PSCI_0_2_POWER_STATE_AFFL_MASK \ + (0x3 PSCI_0_2_POWER_STATE_AFFL_SHIFT) + +/* PSCI v0.2 affinity level state returned by AFFINITY_INFO */ +#define PSCI_0_2_AFFINITY_LEVEL_ON 0 +#define PSCI_0_2_AFFINITY_LEVEL_OFF1 +#define PSCI_0_2_AFFINITY_LEVEL_ON_PENDING 2 + +/* PSCI v0.2 multicore support in Trusted OS returned by MIGRATE_INFO_TYPE */ +#define PSCI_0_2_TOS_UP_MIGRATE0 +#define PSCI_0_2_TOS_UP_NO_MIGRATE 1 +#define PSCI_0_2_TOS_MP2 + +/* PSCI version decoding (independent of PSCI version) */ +#define PSCI_VERSION_MAJOR_SHIFT 16 +#define PSCI_VERSION_MINOR_MASK\ + ((1U PSCI_VERSION_MAJOR_SHIFT) - 1) +#define PSCI_VERSION_MAJOR_MASK~PSCI_VERSION_MINOR_MASK +#define PSCI_VERSION_MAJOR(ver)\ + (((ver) PSCI_VERSION_MAJOR_MASK) PSCI_VERSION_MAJOR_SHIFT) +#define PSCI_VERSION_MINOR(ver)\ + ((ver) PSCI_VERSION_MINOR_MASK) + +/* PSCI return values (inclusive of all PSCI versions) */ +#define PSCI_RET_SUCCESS 0 +#define PSCI_RET_NOT_SUPPORTED -1 +#define PSCI_RET_INVALID_PARAMS-2 +#define PSCI_RET_DENIED-3 +#define PSCI_RET_ALREADY_ON-4 +#define PSCI_RET_ON_PENDING-5 +#define PSCI_RET_INTERNAL_FAILURE -6 +#define PSCI_RET_NOT_PRESENT -7 +#define PSCI_RET_DISABLED -8 + +#endif /* _UAPI_LINUX_PSCI_H */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] armv8:New MMU setup code allowing to set up 2-level page tables
This patch adds code which sets up 2-level page tables on ARM64 thus
extending available VA space. CPUs implementing 64k translation
granule are able to use direct PA-VA mapping of the whole 48 bit
address space.
It also adds the ability to reset the SCTRL register at the very beginning
of execution to avoid interference from stale mappings set up by early
firmware/loaders/etc.
Signed-off-by: Sergey Temerkhanov s.temerkha...@gmail.com
Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
---
arch/arm/cpu/armv8/cache_v8.c | 95 ++
arch/arm/cpu/armv8/start.S | 36 +++
arch/arm/include/asm/armv8/mmu.h | 79 ---
arch/arm/include/asm/global_data.h | 1 +
arch/arm/include/asm/system.h | 6 +++
arch/arm/lib/board.c | 6 ++-
6 files changed, 215 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index c5ec529..1264caa 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -12,6 +12,8 @@
DECLARE_GLOBAL_DATA_PTR;
#ifndef CONFIG_SYS_DCACHE_OFF
+
+#ifndef CONFIG_SYS_FULL_VA
void set_pgtable_section(u64 *page_table, u64 index, u64 section,
u64 memory_type)
{
@@ -65,6 +67,99 @@ static void mmu_setup(void)
set_sctlr(get_sctlr() | CR_M);
}
+#else
+
+static void set_ptl1_entry(u64 index, u64 ptl2_entry)
+{
+ u64 *pgd = (u64 *)gd-arch.tlb_addr;
+ u64 value;
+
+ value = ptl2_entry | PTL1_TYPE_TABLE;
+ pgd[index] = value;
+}
+
+static void set_ptl2_block(u64 ptl1, u64 bfn, u64 address, u64 memory_type)
+{
+ u64 *pmd = (u64 *)ptl1;
+ u64 value;
+
+ value = address | PTL2_TYPE_BLOCK | PTL2_BLOCK_AF;
+ value |= PMD_ATTRINDX(memory_type);
+ pmd[bfn] = value;
+}
+
+static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP;
+
+#define PTL1_ENTRIES CONFIG_SYS_PTL1_ENTRIES
+#define PTL2_ENTRIES CONFIG_SYS_PTL2_ENTRIES
+
+static void setup_pgtables(void)
+{
+ int l1_e, l2_e;
+ unsigned long pmd = 0;
+ unsigned long address;
+
+ /* Setup the PMD pointers */
+ for (l1_e = 0; l1_e CONFIG_SYS_MEM_MAP_SIZE; l1_e++) {
+ gd-arch.pmd_addr[l1_e] = gd-arch.tlb_addr +
+ PTL1_ENTRIES * sizeof(u64);
+ gd-arch.pmd_addr[l1_e] += PTL2_ENTRIES * sizeof(u64) * l1_e;
+ gd-arch.pmd_addr[l1_e] += 0xUL;
+ gd-arch.pmd_addr[l1_e] = ~0xUL;
+ }
+
+/* Setup the page tables */
+ for (l1_e = 0; l1_e PTL1_ENTRIES; l1_e++) {
+ if (mem_map[pmd].base ==
+ (uintptr_t)l1_e PTL1_BITS) {
+ set_ptl1_entry(l1_e, gd-arch.pmd_addr[pmd]);
+
+ for (l2_e = 0; l2_e PTL2_ENTRIES; l2_e++) {
+ address = mem_map[pmd].base
+ + (uintptr_t)l2_e * BLOCK_SIZE;
+ set_ptl2_block(gd-arch.pmd_addr[pmd], l2_e,
+ address, mem_map[pmd].attrs);
+ }
+
+ pmd++;
+ } else {
+ set_ptl1_entry(l1_e, 0);
+ }
+}
+}
+
+/* to activate the MMU we need to set up page tables */
+static void mmu_setup(void)
+{
+ int el;
+ unsigned long coreid = read_mpidr() CONFIG_COREID_MASK;
+
+ /* Set up page tables only on BSP */
+ if (coreid == BSP_COREID)
+ setup_pgtables();
+
+ /* load TTBR0 */
+ el = current_el();
+
+ if (el == 1) {
+ set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
+ TCR_FLAGS | TCR_EL1_IPS_BITS,
+ MEMORY_ATTRIBUTES);
+ } else if (el == 2) {
+ set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
+ TCR_FLAGS | TCR_EL2_IPS_BITS,
+ MEMORY_ATTRIBUTES);
+ } else {
+ set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
+ TCR_FLAGS | TCR_EL3_IPS_BITS,
+ MEMORY_ATTRIBUTES);
+ }
+ /* enable the mmu */
+ set_sctlr(get_sctlr() | CR_M);
+}
+
+#endif
+
/*
* Performs a invalidation of the entire data cache at all levels
*/
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index e5f2766..ea686de 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -19,6 +19,9 @@
.globl _start
_start:
+#ifdef CONFIG_SYS_RESET_SCTRL
+ bl reset_sctrl
+#endif
b reset
.align 3
@@ -97,6 +100,39 @@ master_cpu:
bl _main
+#ifdef CONFIG_SYS_RESET_SCTRL
+reset_sctrl:
+ switch_el x1, 3f, 2f, 1f
+3:
+ mrs x0, sctlr_el3
+ b 0f
+2:
+ mrs x0, sctlr_el2
+ b 0f
+1:
+ mrs x0, sctlr_el1
+
[U-Boot] [PATCH 0/7] Add Cavium ThunderX support
This patch series adds support for Cavium ThunderX 88xx SoC family (http://www.cavium.com/ThunderX_ARM_Processors.html). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] arm: uart: Add ability to use pre-initialized UARTs
On some systems, UART initialization is performed before running U-Boot.
This commit allows to skip UART re-initializaion on those systems
Signed-off-by: Sergey Temerkhanov s.temerkha...@gmail.com
Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
---
drivers/serial/serial_pl01x.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index 75eb6bd..be9a14a 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -69,7 +69,7 @@ static int pl01x_tstc(struct pl01x_regs *regs)
return !(readl(regs-fr) UART_PL01x_FR_RXFE);
}
-static int pl01x_generic_serial_init(struct pl01x_regs *regs,
+static __used int pl01x_generic_serial_init(struct pl01x_regs *regs,
enum pl01x_type type)
{
switch (type) {
@@ -204,7 +204,9 @@ static void pl01x_serial_init_baud(int baudrate)
#endif
base_regs = (struct pl01x_regs *)port[CONFIG_CONS_INDEX];
+#ifndef CONFIG_PL010_SERIAL_PREINIT
pl01x_generic_serial_init(base_regs, pl01x_type);
+#endif
pl01x_generic_setbrg(base_regs, pl01x_type, clock, baudrate);
}
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: mx6: Clamp MMDC and DDR3 clocks for timing calculations
On Thu, Apr 16, 2015 at 7:36 PM, Nikolay Dimitrov picmas...@mail.bg wrote: This is proposal for clamping the MMDC/DDR3 clocks to the maximum supported frequencies as per imx6 SOC models, and for dynamically calculating valid clock value based on mem_speed. Currently the code uses impossible values for mem_speed (1333, 1600 MT/s) for calculating the DDR timings, and uses fixed clock (528 or 400 MHz) which doesn't take into account DDR3 memory limitations. Signed-off-by: Nikolay Dimitrov picmas...@mail.bg Cc: Fabio Estevam feste...@gmail.com Cc: Stefano Babic sba...@denx.de Cc: Tim Harvey thar...@gateworks.com Cc: Eric Nelson eric.nel...@boundarydevices.com It does looks way nicer. It is much easier to understand what is going behind the scenes. Acked-by: Otavio Salvador ota...@ossystems.com.br -- 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] Please pull u-boot-dm
Hi Tom, On 16 April 2015 at 11:43, Tom Rini tr...@konsulko.com wrote: On Tue, Apr 14, 2015 at 12:11:00PM -0600, Simon Glass wrote: Hi Tom, Here are the driver model changes that have been queued up on u-boot-dm/next. The main changes are: - Ethernet driver model support - USB driver model support - PCI driver model support - Network cosmetic changes - Masahiro's driver model Kconfig changes - Chromebox panther support - Moving cros_ec fully to driver model - Moving various sandbox CONFIGs to Kconfig Since this has wide impact on the code base I'd like to get this in early in the merge window to minimise the pain of rebase, etc. So, yeah, rebase pain. Setting aside the USB scan changes (that're in as I didn't see u-boot-dfu included u-boot-usb, my fault), the rest of the USB conflicts are a little tricky too now that I read them harder. Please rebase and I'll grab it ASAP. Sorry! Sorry about this...I did wonder whether that USB patches were going to trip us up. As you said the main issue seems to be one of the usb_stor patches. In fact I think we should reconsider commit cd749658. To me it does not seem quite right. I'd like to revert it and resend it. I may be mistaken though. I just finished a build, but I see there are more commits in master. So I'll do one more spin and send a pull request (with that commit reverttd) after that. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/9] sf: Update SST flash params
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a sector by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is
64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
64K sector erase through flags.
Linux does follow the same-
/* SST -- large erase sizes are overlays, sectors are 4K */
{ sst25vf040b, INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K |
SST_WRITE) },
{ sst25vf080b, INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
{ sst25vf016b, INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
{ sst25vf032b, INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
SST_WRITE) },
Please check it.
Yes, I know this pretty well. And I want to change this behavior, as
my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while
the actual erase command is 4KB granularity, which is inconsistent and
causes confusion.
On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote:
Update SST25VF064C read command to RD_EXTN per datasheet.
Also change flash sector size to 4KiB to match SECT_4K.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/mtd/spi/sf_params.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 30875b3..5482700 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] =
{
{N25Q1024A, 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL,
WR_QPP | E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST/* SST */
- {SST25VF040B,0xbf258d, 0x0, 64 * 1024, 8, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF080B,0xbf258e, 0x0, 64 * 1024,16, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF016B,0xbf2541, 0x0, 64 * 1024,32, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF032B,0xbf254a, 0x0, 64 * 1024,64, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF064C,0xbf254b, 0x0, 64 * 1024, 128, RD_NORM,
SECT_4K},
- {SST25WF512, 0xbf2501, 0x0, 64 * 1024, 1, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF010, 0xbf2502, 0x0, 64 * 1024, 2, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF020, 0xbf2503, 0x0, 64 * 1024, 4, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF040, 0xbf2504, 0x0, 64 * 1024, 8, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF080, 0xbf2505, 0x0, 64 * 1024,16, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF040B,0xbf258d, 0x0,4 * 1024, 128, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF080B,0xbf258e, 0x0,4 * 1024, 256, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF016B,0xbf2541, 0x0,4 * 1024, 512, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF032B,0xbf254a, 0x0,4 * 1024, 1024, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF064C,0xbf254b, 0x0,4 * 1024, 2048, RD_EXTN,
SECT_4K},
+ {SST25WF512, 0xbf2501, 0x0,4 * 1024,16, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF010, 0xbf2502, 0x0,4 * 1024,32, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF020, 0xbf2503, 0x0,4 * 1024,64, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF040, 0xbf2504, 0x0,4 * 1024, 128, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF080, 0xbf2505, 0x0,4 * 1024, 256, RD_NORM,
SECT_4K | SST_WR},
#endif
#ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
{W25P80, 0xef2014, 0x0, 64 * 1024,16, RD_NORM,
0},
--
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] arm: mx6: Clamp MMDC and DDR3 clocks for timing calculations
This is proposal for clamping the MMDC/DDR3 clocks to the maximum supported
frequencies as per imx6 SOC models, and for dynamically calculating valid
clock value based on mem_speed.
Currently the code uses impossible values for mem_speed (1333, 1600 MT/s) for
calculating the DDR timings, and uses fixed clock (528 or 400 MHz) which
doesn't take into account DDR3 memory limitations.
Signed-off-by: Nikolay Dimitrov picmas...@mail.bg
Cc: Fabio Estevam feste...@gmail.com
Cc: Stefano Babic sba...@denx.de
Cc: Tim Harvey thar...@gateworks.com
Cc: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/cpu/armv7/mx6/ddr.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index fef2231..9daa180 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -265,7 +265,7 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *sysinfo,
u16 tdllk = 0x1ff; /* DLL locking time: 512 cycles (JEDEC DDR3) */
u8 coladdr;
int clkper; /* clock period in picoseconds */
- int clock; /* clock freq in mHz */
+ int clock; /* clock freq in MHz */
int cs;
mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
@@ -273,16 +273,31 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *sysinfo,
mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
#endif
- /* MX6D/MX6Q: 1066 MHz memory clock, clkper = 1.894ns = 1894ps */
+ /* Limit mem_speed for MX6D/MX6Q */
if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D)) {
- clock = 528;
+ if (ddr3_cfg-mem_speed 1066)
+ ddr3_cfg-mem_speed = 1066; /* 1066 MT/s */
+
tcwl = 4;
}
- /* MX6S/MX6DL: 800 MHz memory clock, clkper = 2.5ns = 2500ps */
+ /* Limit mem_speed for MX6S/MX6DL */
else {
- clock = 400;
+ if (ddr3_cfg-mem_speed 800)
+ ddr3_cfg-mem_speed = 800; /* 800 MT/s */
+
tcwl = 3;
}
+
+ clock = ddr3_cfg-mem_speed / 2;
+ /*
+* Data rate of 1066 MT/s requires 533 MHz DDR3 clock, but MX6D/Q
supports
+* up to 528 MHz, so reduce the clock to fit chip specs
+*/
+ if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D)) {
+ if (clock 528)
+ clock = 528; /* 528 MHz */
+ }
+
clkper = (1000 * 1000) / clock; /* pico seconds */
todtlon = tcwl;
taxpd = tcwl;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] armv8: cavium: Get DRAM size from ATF
Change the dram_init() function on ThunderXto query ATF services for
the real installed DRAM size
Signed-off-by: Sergey Temerkhanov s.temerkha...@gmail.com
Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
---
board/cavium/thunderx/Makefile | 2 +-
board/cavium/thunderx/dram.c | 35 +++
board/cavium/thunderx/thunderx.c | 12
3 files changed, 36 insertions(+), 13 deletions(-)
create mode 100644 board/cavium/thunderx/dram.c
diff --git a/board/cavium/thunderx/Makefile b/board/cavium/thunderx/Makefile
index c78c414..9200dd6 100644
--- a/board/cavium/thunderx/Makefile
+++ b/board/cavium/thunderx/Makefile
@@ -5,4 +5,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y := thunderx.o atf.o
+obj-y := thunderx.o atf.o dram.o
diff --git a/board/cavium/thunderx/dram.c b/board/cavium/thunderx/dram.c
new file mode 100644
index 000..858699d
--- /dev/null
+++ b/board/cavium/thunderx/dram.c
@@ -0,0 +1,35 @@
+/**
+ * (C) Copyright 2014, Cavium Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+**/
+
+#include common.h
+#include cavium/atf.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int dram_init(void)
+{
+ ssize_t node_count = atf_node_count();
+ ssize_t dram_size;
+ int node;
+
+ printf(Initializing\nNodes in system: %zd\n, node_count);
+
+ gd-ram_size = 0;
+
+ for (node = 0; node node_count; node++) {
+ dram_size = atf_dram_size(node);
+ printf(Node %d: %zd MBytes of DRAM\n, node, dram_size 20);
+ gd-ram_size += dram_size;
+ }
+
+ gd-ram_size -= MEM_BASE;
+
+ *(unsigned long *)CPU_RELEASE_ADDR = 0;
+
+ puts(DRAM size:);
+
+ return 0;
+}
diff --git a/board/cavium/thunderx/thunderx.c b/board/cavium/thunderx/thunderx.c
index 5a5e259..a5cf7c5 100644
--- a/board/cavium/thunderx/thunderx.c
+++ b/board/cavium/thunderx/thunderx.c
@@ -16,18 +16,6 @@ int board_init(void)
return 0;
}
-int dram_init(void)
-{
- /*
-* Clear spin table so that secondary processors
-* observe the correct value after waken up from wfe.
-*/
- *(unsigned long *)CPU_RELEASE_ADDR = 0;
-
- gd-ram_size = PHYS_SDRAM_1_SIZE;
- return 0;
-}
-
int timer_init(void)
{
return 0;
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] armv8: cavium: Add an implementation of ATF calling functions
This commit adds functions issuing calls to the product-specific ATF
services
Signed-off-by: Sergey Temerkhanov s.temerkha...@gmail.com
Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com
---
board/cavium/thunderx/Makefile | 2 +-
board/cavium/thunderx/atf.c | 312
include/cavium/atf.h| 22 +++
include/cavium/atf_part.h | 26
include/cavium/thunderx_svc.h | 67 +
include/configs/thunderx_88xx.h | 2 +
6 files changed, 430 insertions(+), 1 deletion(-)
create mode 100644 board/cavium/thunderx/atf.c
create mode 100644 include/cavium/atf.h
create mode 100644 include/cavium/atf_part.h
create mode 100644 include/cavium/thunderx_svc.h
diff --git a/board/cavium/thunderx/Makefile b/board/cavium/thunderx/Makefile
index 306044a..c78c414 100644
--- a/board/cavium/thunderx/Makefile
+++ b/board/cavium/thunderx/Makefile
@@ -5,4 +5,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y := thunderx.o
+obj-y := thunderx.o atf.o
diff --git a/board/cavium/thunderx/atf.c b/board/cavium/thunderx/atf.c
new file mode 100644
index 000..6ab9de9
--- /dev/null
+++ b/board/cavium/thunderx/atf.c
@@ -0,0 +1,312 @@
+/**
+ * (C) Copyright 2014, Cavium Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+**/
+
+#include common.h
+#include asm/io.h
+
+#include asm/system.h
+#include cavium/thunderx_svc.h
+#include cavium/atf.h
+#include cavium/atf_part.h
+
+#include asm/psci.h
+
+#include malloc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+ssize_t atf_read_mmc(uintptr_t offset, void *buffer, size_t size)
+{
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_MMC_READ;
+ regs.regs[1] = offset;
+ regs.regs[2] = size;
+ regs.regs[3] = (uintptr_t)buffer;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_read_nor(uintptr_t offset, void *buffer, size_t size)
+{
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_NOR_READ;
+ regs.regs[1] = offset;
+ regs.regs[2] = size;
+ regs.regs[3] = (uintptr_t)buffer;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_get_pcount(void)
+{
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_PART_COUNT;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_get_part(struct storage_partition *part, unsigned int index)
+{
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_GET_PART;
+ regs.regs[1] = (uintptr_t)part;
+ regs.regs[2] = index;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_erase_nor(uintptr_t offset, size_t size)
+{
+ struct pt_regs regs;
+
+ regs.regs[0] = THUNDERX_NOR_ERASE;
+ regs.regs[1] = offset;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_write_nor(uintptr_t offset, const void *buffer, size_t size)
+{
+ struct pt_regs regs;
+
+ regs.regs[0] = THUNDERX_NOR_WRITE;
+ regs.regs[1] = offset;
+ regs.regs[2] = size;
+ regs.regs[3] = (uintptr_t)buffer;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_write_mmc(uintptr_t offset, const void *buffer, size_t size)
+{
+ struct pt_regs regs;
+
+ regs.regs[0] = THUNDERX_MMC_WRITE;
+ regs.regs[1] = offset;
+ regs.regs[2] = size;
+ regs.regs[3] = (uintptr_t)buffer;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_dram_size(unsigned int node)
+{
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_DRAM_SIZE;
+ regs.regs[1] = node;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_node_count(void)
+{
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_NODE_COUNT;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_env_count(void)
+{
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_ENV_COUNT;
+
+ smc_call(regs);
+
+ return regs.regs[0];
+}
+
+ssize_t atf_env_string(size_t index, char *str)
+{
+ uint64_t *buf = (void *)str;
+ struct pt_regs regs;
+ regs.regs[0] = THUNDERX_ENV_STRING;
+ regs.regs[1] = index;
+
+ smc_call(regs);
+
+ if (regs.regs 0) {
+ buf[0] = regs.regs[0];
+ buf[1] = regs.regs[1];
+ buf[2] = regs.regs[2];
+ buf[3] = regs.regs[3];
+
+ return 1;
+ } else {
+ return regs.regs[0];
+ }
+}
+
+#ifdef CONFIG_CMD_ATF
+
+static void atf_print_ver(void)
+{
+ struct pt_regs regs;
+ regs.regs[0] = ARM_STD_SVC_VERSION;
+
+ smc_call(regs);
+
+ printf(ARM Std FW version: %ld.%ld\n, regs.regs[0], regs.regs[1]);
+
+ regs.regs[0] = THUNDERX_SVC_VERSION;
+
+ smc_call(regs);
+
+ printf(ThunderX OEM ver: %ld.%ld\n, regs.regs[0], regs.regs[1]);
+}
+
+static void atf_print_uid(void)
+{
+}
+
+static void atf_print_part_table(void)
+{
+ size_t pcount;
+ unsigned
[U-Boot] [PATCH 1/2] mx6sabresd: Fix SPL memory description
From: Fabio Estevam fabio.este...@freescale.com
mx6sabresd has four MT41K128M16JT-125 chips. Each memory has 16-bit bus
and 2GiB, so fix the width and density fields accordingly.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index bb2dd96..a4f3a94 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -753,10 +753,11 @@ const struct mx6_mmdc_calibration mx6_mmcd_calib = {
.p1_mpwrdlctl = 0x48254A36,
};
+/* MT41K128M16JT-125 */
static struct mx6_ddr3_cfg mem_ddr = {
.mem_speed = 1600,
- .density = 4,
- .width = 64,
+ .density = 2,
+ .width = 16,
.banks = 8,
.rowaddr = 14,
.coladdr = 10,
@@ -798,7 +799,7 @@ static void spl_dram_init(void)
{
struct mx6_ddr_sysinfo sysinfo = {
/* width of data bus:0=16,1=32,2=64 */
- .dsize = mem_ddr.width/32,
+ .dsize = 2,
/* config for full 4GB range so that get_mem_size() works */
.cs_density = 32, /* 32Gb per CS */
/* single chip select */
@@ -818,7 +819,7 @@ static void spl_dram_init(void)
.rst_to_cke = 0x23, /* 33 cycles, 500us (JEDEC default) */
};
- mx6dq_dram_iocfg(mem_ddr.width, mx6_ddr_ioregs, mx6_grp_ioregs);
+ mx6dq_dram_iocfg(64, mx6_ddr_ioregs, mx6_grp_ioregs);
mx6_dram_cfg(sysinfo, mx6_mmcd_calib, mem_ddr);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6sabresd: Remove uneeded ifdef
From: Fabio Estevam fabio.este...@freescale.com RTT_NOM_120OHM is not defined, so remove its ifdef. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/freescale/mx6sabresd/mx6sabresd.c | 4 1 file changed, 4 deletions(-) diff --git a/board/freescale/mx6sabresd/mx6sabresd.c b/board/freescale/mx6sabresd/mx6sabresd.c index a4f3a94..23f8f6b 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -806,11 +806,7 @@ static void spl_dram_init(void) .ncs = 1, .cs1_mirror = 0, .rtt_wr = 1 /*DDR3_RTT_60_OHM*/,/* RTT_Wr = RZQ/4 */ -#ifdef RTT_NOM_120OHM - .rtt_nom = 2 /*DDR3_RTT_120_OHM*/, /* RTT_Nom = RZQ/2 */ -#else .rtt_nom = 1 /*DDR3_RTT_60_OHM*/, /* RTT_Nom = RZQ/4 */ -#endif .walat = 1, /* Write additional latency */ .ralat = 5, /* Read additional latency */ .mif3_mode = 3, /* Command prediction working mode */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Licenses: fix a typo in README
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Licenses/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Licenses/README b/Licenses/README index fe6dadc..9b9a462 100644 --- a/Licenses/README +++ b/Licenses/README @@ -47,7 +47,7 @@ used under the terms of either of these licenses, i. e. with SPDX-License-Identifier:GPL-2.0+BSD-3-Clause -you can chose between GPL-2.0+ and BSD-3-Clause licensing. +you can choose between GPL-2.0+ and BSD-3-Clause licensing. We use the SPDX Unique License Identifiers here; these are available at [2]. -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mx6: Add initial SPL support for HummingBoard-i2eX
From: Fabio Estevam fabio.este...@freescale.com Add the initial SPL support for HummingBoard-i2eX, which is based on a MX6 Dual. For more information about HummingBoard, please check: http://www.solid-run.com/products/hummingboard/ Based on the work from Jon Nettleton and Rabeeh Khoury. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Currently only HummingBoard-i2eX is supported. After this initial patch is accepted, then we can add the other Hummingboard and Cubox-i variants as well. Changes since v1: - Addressed several comments made by Tom Rini - Remove empty lines from README as pointed out by Nikolay Dimitrov - Fixed sparse warnings - Fixed DDR settings arch/arm/Kconfig | 6 + board/solidrun/mx6cuboxi/Kconfig | 15 ++ board/solidrun/mx6cuboxi/MAINTAINERS | 6 + board/solidrun/mx6cuboxi/Makefile| 9 + board/solidrun/mx6cuboxi/README | 21 +++ board/solidrun/mx6cuboxi/mx6cuboxi.c | 330 +++ configs/mx6cuboxi_spl_defconfig | 6 + include/configs/mx6cuboxi.h | 205 ++ 8 files changed, 598 insertions(+) create mode 100644 board/solidrun/mx6cuboxi/Kconfig create mode 100644 board/solidrun/mx6cuboxi/MAINTAINERS create mode 100644 board/solidrun/mx6cuboxi/Makefile create mode 100644 board/solidrun/mx6cuboxi/README create mode 100644 board/solidrun/mx6cuboxi/mx6cuboxi.c create mode 100644 configs/mx6cuboxi_spl_defconfig create mode 100644 include/configs/mx6cuboxi.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7ed0e20..7c383cb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -523,6 +523,11 @@ config TARGET_MX6SABRESD select CPU_V7 select SUPPORT_SPL +config TARGET_MX6CUBOXI + bool Support Solid-run mx6 boards + select CPU_V7 + select SUPPORT_SPL + config TARGET_MX6SLEVK bool Support mx6slevk select CPU_V7 @@ -856,6 +861,7 @@ source board/siemens/draco/Kconfig source board/siemens/pxm2/Kconfig source board/siemens/rut/Kconfig source board/silica/pengwyn/Kconfig +source board/solidrun/mx6cuboxi/Kconfig source board/solidrun/hummingboard/Kconfig source board/spear/spear300/Kconfig source board/spear/spear310/Kconfig diff --git a/board/solidrun/mx6cuboxi/Kconfig b/board/solidrun/mx6cuboxi/Kconfig new file mode 100644 index 000..31d88b2 --- /dev/null +++ b/board/solidrun/mx6cuboxi/Kconfig @@ -0,0 +1,15 @@ +if TARGET_MX6CUBOXI + +config SYS_BOARD + default mx6cuboxi + +config SYS_VENDOR + default solidrun + +config SYS_SOC + default mx6 + +config SYS_CONFIG_NAME + default mx6cuboxi + +endif diff --git a/board/solidrun/mx6cuboxi/MAINTAINERS b/board/solidrun/mx6cuboxi/MAINTAINERS new file mode 100644 index 000..3d468ed --- /dev/null +++ b/board/solidrun/mx6cuboxi/MAINTAINERS @@ -0,0 +1,6 @@ +MX6CUBOXI BOARD +M: Fabio Estevam fabio.este...@freescale.com +S: Maintained +F: board/solidrun/mx6cuboxi/ +F: include/configs/mx6cuboxi.h +F: configs/mx6cuboxi_spl_defconfig diff --git a/board/solidrun/mx6cuboxi/Makefile b/board/solidrun/mx6cuboxi/Makefile new file mode 100644 index 000..df425ac --- /dev/null +++ b/board/solidrun/mx6cuboxi/Makefile @@ -0,0 +1,9 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski l...@denx.de +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := mx6cuboxi.o diff --git a/board/solidrun/mx6cuboxi/README b/board/solidrun/mx6cuboxi/README new file mode 100644 index 000..0f1d514 --- /dev/null +++ b/board/solidrun/mx6cuboxi/README @@ -0,0 +1,21 @@ +How to use U-boot on Solid-run mx6 hummingboard +--- + +- Build U-boot for hummingboard: + +$ make mrproper +$ make mx6cuboxi_spl_defconfig +$ make + +This will generate the SPL image called SPL and the u-boot.img. + +- Flash the SPL image into the SD card: + +sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync + +- Flash the u-boot.img image into the SD card: + +sudo dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69; sync + +- Insert the SD card in the hummingboard, power it up and U-boot messages +should come up. diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c new file mode 100644 index 000..b696dcb --- /dev/null +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -0,0 +1,330 @@ +/* + * Copyright (C) 2015 Freescale Semiconductor, Inc. + * + * Author: Fabio Estevam fabio.este...@freescale.com + * + * Copyright (C) 2013 Jon Nettleton jon.nettle...@gmail.com + * + * Based on SPL code from Solidrun tree, which is: + * Author: Tungyi Lin tungyilin1...@gmail.com + * + * Derived from EDM_CF_IMX6 code by TechNexion,Inc + * Ported to SolidRun microSOM by Rabeeh Khoury rab...@solid-run.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm/arch/clock.h +#include asm/arch/imx-regs.h +#include asm/arch/iomux.h +#include asm/arch/mx6-pins.h
[U-Boot] Please pull u-boot-dm.git [take 2]
Hi Tom, As mentioned I reverted this patch as it conflicted with the dm tree and I suspect it might be buggy: cd749658 usb_storage : scan all interfaces to find a storage device Assuming this is OK and applies successfully I will rebase and resend this patch, then reply with some comments I have on the patch. The following changes since commit 4564faeafbf11feb839e2e3f927be2f1a919ba96: ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c (2015-04-16 15:08:36 -0400) are available in the git repository at: http://git.denx.de/u-boot-dm.git for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784: sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16 20:47:57 -0600) haikun.w...@freescale.com (5): dm: arm: Bring in skeleton64 device tree file from Linux dm: ls1021a: dts: Update DSPI node to support DM SPI dm: ls1021a: dts: Add QSPI dts node dm: spi: Convert Freescale DSPI driver to driver model dm: spi: Convert Freescale QSPI driver to driver model Joe Hershberger (51): test: dm: Reorder the objects to build common: Make sure arch-specific map_sysmem() is defined net: Provide a function to get the current MAC address net: Rename helper function to be more clear net: Remove unneeded extern in net.h net: Refactor in preparation for driver model net: Change return codes from net/eth.c to use errorno constants net: Use int instead of u8 for boolean flag net: Remove the bd* parameter from net stack functions net: Make netretry actually do something net: Access mapped physmem in net functions cmd: net: Clean up return codes dm: eth: Add basic driver model support to Ethernet stack net: Clean up network stack names used in DM drivers dm: eth: Pass the packet pointer as a parameter to recv sandbox: eth: Add network support to sandbox sandbox: eth: Add ARP and PING response to sandbox driver test: dm: eth: Add tests for the eth dm implementation dm: eth: Add support for aliases dm: eth: Add support for ethprime env var test: dm: eth: Add testing for ethrotate env var sandbox: eth: Add ability to disable ping reply in sandbox eth driver test: dm: net: Add a test of the netretry behavior sandbox: eth: Add a bridge to a real network for sandbox sandbox: Enable DHCP and IP defrag sandbox: eth: Add support for using the 'lo' interface net: Improve error handling dm: eth: Provide a way for drivers to manage packet buffers net: cosmetic: Change IPaddr_t to struct in_addr net: cosmetic: Fixup var names related to boot file net: cosmetic: Fixup var names for DHCP strings net: cosmetic: Name ethaddr variables consistently net: cosmetic: Cleanup internal packet buffer names net: cosmetic: Fix var naming net - eth drivers net: cosmetic: Clean up TFTP variables and functions net: cosmetic: Clean up ARP variables and functions net: cosmetic: Clean up DHCP variables and functions net: cosmetic: Clean up NFS variables and functions net: cosmetic: Clean up RARP variables and functions net: cosmetic: Clean up SNTP variables and functions net: cosmetic: Clean up ping variables and functions net: cosmetic: Clean up CDP variables and functions net: cosmetic: Clean up DNS variables and functions net: cosmetic: Clean up netconsole variables and functions net: cosmetic: Clean up cmd_net variables and functions net: cosmetic: Fix checkpatch.pl failures in linklocal net: cosmetic: Fix checkpatch.pl failures in eth.c net: cosmetic: Fix checkpatch.pl failures in net.h net: cosmetic: Fix checkpatch.pl failures in net.c net: Fix compile errors when SNTP enabled and not DATE sandbox: Enable more network features for sandbox Masahiro Yamada (12): dm: spi_flash: fix wrong dependency dm: select CONFIG_DM* options ARM: UniPhier: use select instead of default value in defconfig ARM: zynq: use select instead of default value in defconfig ARM: rmobile: use select instead of default value in defconfig ARM: snapper9260: use select instead of default value in defconfig ARM: mx6: use select instead of default value in defconfig ARM: socfpga: use select instead of default value in defconfig ARM: bav335x: use select instead of default value in defconfig ARM: stv0991: use select instead of default value in defconfig ARM: cm_fx6: use select instead of default value in defconfig powerpc: ids8313: use select instead of default value in defconfig Przemyslaw Marczak (3): dm: gpio: request list: return the count if requests max_count reached Kconfig: i2c: fix help message related to dm i2c dm: i2c: add i2c-gpio driver Sergey
Re: [U-Boot] [PATCH v3 1/9] sf: Update SST flash params
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
* necessarily called a sector by the vendor.
*/
Say for example SST25VF040B has 8 sectors of which each sector size is
64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
64K sector erase through flags.
Linux does follow the same-
/* SST -- large erase sizes are overlays, sectors are 4K */
{ sst25vf040b, INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K |
SST_WRITE) },
{ sst25vf080b, INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
{ sst25vf016b, INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
{ sst25vf032b, INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
SST_WRITE) },
Please check it.
On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote:
Update SST25VF064C read command to RD_EXTN per datasheet.
Also change flash sector size to 4KiB to match SECT_4K.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/mtd/spi/sf_params.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 30875b3..5482700 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
{N25Q1024A, 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL,
WR_QPP | E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST/* SST */
- {SST25VF040B,0xbf258d, 0x0, 64 * 1024, 8, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF080B,0xbf258e, 0x0, 64 * 1024,16, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF016B,0xbf2541, 0x0, 64 * 1024,32, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF032B,0xbf254a, 0x0, 64 * 1024,64, RD_NORM,
SECT_4K | SST_WR},
- {SST25VF064C,0xbf254b, 0x0, 64 * 1024, 128, RD_NORM,
SECT_4K},
- {SST25WF512, 0xbf2501, 0x0, 64 * 1024, 1, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF010, 0xbf2502, 0x0, 64 * 1024, 2, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF020, 0xbf2503, 0x0, 64 * 1024, 4, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF040, 0xbf2504, 0x0, 64 * 1024, 8, RD_NORM,
SECT_4K | SST_WR},
- {SST25WF080, 0xbf2505, 0x0, 64 * 1024,16, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF040B,0xbf258d, 0x0,4 * 1024, 128, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF080B,0xbf258e, 0x0,4 * 1024, 256, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF016B,0xbf2541, 0x0,4 * 1024, 512, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF032B,0xbf254a, 0x0,4 * 1024, 1024, RD_NORM,
SECT_4K | SST_WR},
+ {SST25VF064C,0xbf254b, 0x0,4 * 1024, 2048, RD_EXTN,
SECT_4K},
+ {SST25WF512, 0xbf2501, 0x0,4 * 1024,16, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF010, 0xbf2502, 0x0,4 * 1024,32, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF020, 0xbf2503, 0x0,4 * 1024,64, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF040, 0xbf2504, 0x0,4 * 1024, 128, RD_NORM,
SECT_4K | SST_WR},
+ {SST25WF080, 0xbf2505, 0x0,4 * 1024, 256, RD_NORM,
SECT_4K | SST_WR},
#endif
#ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
{W25P80, 0xef2014, 0x0, 64 * 1024,16, RD_NORM,
0},
--
1.8.2.1
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] zynqmp: Add SPI driver support for ZynqMP
On 15 April 2015 at 19:03, Michal Simek michal.si...@xilinx.com wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Added the SPI driver support for ZynqMP The controller is same as zynq SPI controller Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/arm/include/asm/arch-zynqmp/hardware.h | 3 +++ include/configs/xilinx_zynqmp.h | 8 2 files changed, 11 insertions(+) diff --git a/arch/arm/include/asm/arch-zynqmp/hardware.h b/arch/arm/include/asm/arch-zynqmp/hardware.h index 1fedb1bb4b94..c9dc49d78317 100644 --- a/arch/arm/include/asm/arch-zynqmp/hardware.h +++ b/arch/arm/include/asm/arch-zynqmp/hardware.h @@ -11,6 +11,9 @@ #define ZYNQ_SERIAL_BASEADDR0 0xFF00 #define ZYNQ_SERIAL_BASEADDR1 0xFF001000 +#define ZYNQ_SPI_BASEADDR0 0xFF04 +#define ZYNQ_SPI_BASEADDR1 0xFF05 + #define ZYNQ_I2C_BASEADDR0 0xFF02 #define ZYNQ_I2C_BASEADDR1 0xFF03 diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 54bca6d47b72..df7541b85baf 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -71,6 +71,14 @@ #define CONFIG_CMD_ELF #define CONFIG_MP +/* SPI */ +#ifdef CONFIG_ZYNQ_SPI +# define CONFIG_SPI_FLASH +# define CONFIG_SPI_FLASH_SST +# define CONFIG_CMD_SPI CMD_SPI is never been verified I suppose, if so not required at this point of time. +# define CONFIG_CMD_SF +#endif + #if defined(CONFIG_ZYNQ_SDHCI0) || defined(CONFIG_ZYNQ_SDHCI1) # define CONFIG_MMC # define CONFIG_GENERIC_MMC -- 2.3.5 thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nitrogen6x: allow gzipped bitmap display
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/configs/nitrogen6x.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 8ef4b73..0ca02e9 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -142,6 +142,9 @@ #define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE #define CONFIG_VIDEO_BMP_RLE8 #define CONFIG_SPLASH_SCREEN +#define CONFIG_SPLASH_SCREEN_ALIGN +#define CONFIG_VIDEO_BMP_GZIP +#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (6 * 1024 * 1024) #define CONFIG_BMP_16BPP #define CONFIG_IPUV3_CLK 26000 #define CONFIG_CMD_HDMIDETECT -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi and block bits
On 9 February 2015 at 04:57, Michael Walle mich...@walle.cc wrote: Hi there, I stumbled across a situation where the SPI flash on my board was write protected and i could not unlock it in the bootloader. This is especially unfortunate because the recovery mechanism relies on the bootloader to be able to erase the environment. Which flash vendor it is? seems like there is a hardware write protected mechanism in ST MICRON flashes. Please refer that, may be this looks similar to that W#/Vpp CONFIG_SYS_SPI_ST_ENABLE_WP_PIN So any ideas how to fix this? I didn't see any code which unlocks the sectors yet. We could add a lock/unlock function to the spi system, then call unlock in the beginning of saveenv() and lock at the end of saveenv(). Eg. lockbits = read_status() LOCK_BITS spi_unlock_all() saveenv() spi_lock(lockbits) Also this should be exposed to the CLI somehow. sf lock/unlock? thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
