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 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 Acked-by: Ian Campbell Regards, Hans ___ 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 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 Signed-off-by: Hans de Goede + /* 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] [RFC PATCH] arm: Enable CONFIG_USE_ARCH_MEMSET/MEMCPY globally
Hello Tom, On Tue, 3 Feb 2015 15:21:53 -0500, Tom Rini 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 > Signed-off-by: Tom Rini 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
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] [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 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 Signed-off-by: Hans de Goede 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] mx6: Add initial SPL support for HummingBoard-i2eX
Hi Fabio, On 15/04/2015 22:57, Fabio Estevam wrote: > From: Fabio Estevam > > 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 > --- > 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 > +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 > +# > +# (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 > + * Copyright (C) 2013 Jon Nettleton > + * > + * Based on SPL code from Solidrun tree, which is: > + * Author: Tungyi Lin > + * > + * Derived from EDM_CF_IMX6 code by TechNexion,Inc > + * Ported to SolidRun microSOM by Rabeeh Khoury > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include
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 > --- > 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
[U-Boot] [PATCH v2] f_thor: Dont perform reset at the end of thor
From: Siva Durga Prasad Paladugu 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 Signed-off-by: Michal Simek --- 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] [ANN] U-Boot v2015.04 released
Hello Tom, On Mon, 13 Apr 2015 13:20:47 -0400, Tom Rini 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
[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] arm: implement find_next_zero_bit function
Hello Vitaly, On Thu, 5 Feb 2015 11:24:46 -0500, Vitaly Andrianov 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 > --- > > 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 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 > >> > >> 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 > >> Signed-off-by: Hans de Goede > > > >> + /* 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] Armv8: Initializing CNTVOFF_EL2
Hello feng...@phytium.com.cn, On Mon, 2 Mar 2015 15:29:34 +0800, feng...@phytium.com.cn wrote: > From: David Feng > > 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 > --- > 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
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 > > 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 > Signed-off-by: Michal Simek 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
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
[U-Boot] [PATCH] zynq: timer: Fix wrong timer calculation
From: Siva Durga Prasad Paladugu 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 Signed-off-by: Michal Simek --- 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 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 >> >> 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 >> Signed-off-by: Michal Simek > > 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] 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 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 > > > > > > 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 > > > Signed-off-by: Michal Simek > > > --- > > > > > > 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 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 > >> > >> 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 > >> Signed-off-by: Michal Simek > > > > 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] [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 wrote: > Signed-off-by: Alexander Merkle > --- > > 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 > #include > > -#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 wrote: > Signed-off-by: Alexander Merkle > --- > > 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
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
[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 --- 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] ARM: cpu: Add ARMv7 barrier operations support
Hello Vladimir, On Fri, 20 Mar 2015 18:16:17 +0300, Vladimir Barinov wrote: > From: Valentine Barshak > > 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 > > Signed-off-by: Vladimir Barinov > Reviewed-by: Tom Rini > --- > 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
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 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 Tested-by: Albert ARIBAUD 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 > > 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 [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] mx6: Add initial SPL support for HummingBoard-i2eX
On Wed, Apr 15, 2015 at 05:57:55PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > 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 [snip] > +#ifdef CONFIG_SPL_BUILD > +#include > +#include 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] zynq: timer: Fix wrong timer calculation
Hello Michal, Michal Simek wrote on 2015-04-16: > From: Siva Durga Prasad Paladugu > > 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 > Signed-off-by: Michal Simek > --- > > 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 26/34] imx: ventana: add DT fixup for GW54xx compatibility with older kernels
On Thu, Apr 16, 2015 at 12:46 AM, Stefano Babic 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 >> --- >> 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/1] ARMv7 TLB: Fixed TTBR0 and Table Descriptors to allow caching
Hello Bryan, On Tue, 24 Mar 2015 11:25:12 -0500, Bryan Brinsko 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 > --- > 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 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 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 > --- > 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 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 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 > --- > 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 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 1/3] driver/ddr/altera: Add DDR driver for Altera's SDRAM controller
From: Dinh Nguyen 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 --- 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 SDR_CTRLGRP_DRAMTIMING1_TCL_MASK 0x3e00 +#define SDR_CTRL
[U-Boot] [PATCH RESEND 3/3] arm: socfpga: enable the Altera SDRAM controller driver
From: Dinh Nguyen Enable the Altera SDRAM driver for the SoCFPGA platform. Signed-off-by: Dinh Nguyen --- 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] [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 > 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 > > --- > > 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 > 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] [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 > >> > >> 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] fw_env.h: include autoconf.h
On Tue, Apr 14, 2015 at 09:50:47PM +0200, Marcel Ziswiler wrote: > From: Max Krummenacher > > 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 > Signed-off-by: Marcel Ziswiler > --- > 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] [PULL] u-boot-usb/master
Hi Tom, On 15 April 2015 at 12:16, Marek Vasut 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 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 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 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 > --- > > 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 wrote: > From: Siva Durga Prasad Paladugu > > Added the SPI driver support for ZynqMP > The controller is same as zynq SPI controller > > Signed-off-by: Siva Durga Prasad Paladugu > Signed-off-by: Michal Simek > --- > > 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 --- 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 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
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: > 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 > > +#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 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] mpc85xx/T104xD4RDB: Add T104xD4RDB boards support
On 03/25/2015 07:46 AM, Vijay Rai wrote: > 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 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 > --- > v4: squashed ddr patch to this one. > v3: updated readme. > v2: updated the printout of serdes refclk. > > 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] 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 > --- > 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] 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 > --- > 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] [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 > --- > Changes for v3: >- Replace space with tab for macro definition > Changes for v2: >- New patch > --- Reviewed-by: Marek Vasut 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 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 Reviewed-by: Marek Vasut 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 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 > --- > 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 ___ 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 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
[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 Cc: Fabio Estevam Cc: Stefano Babic Cc: Tim Harvey Cc: Eric Nelson --- 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 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 Signed-off-by: Radha Mohan Chintakuntla --- 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 +#include +#include +#include +#include + +#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 +#include + #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 Signed-off-by: Radha Mohan Chintakuntla --- 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 +#include +#include +#include + +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_STRING"Diagnostics" + +#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 CONFIG_SYS_VA_BITS 48 +#define CONFIG_SYS_PTL
[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 Signed-off-by: Radha Mohan Chintakuntla --- 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 + */ + +#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 Signed-off-by: Radha Mohan Chintakuntla --- 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 + +0: + ldr x1, =0xfdfff
[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 Signed-off-by: Radha Mohan Chintakuntla --- 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(®s->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
[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 Signed-off-by: Radha Mohan Chintakuntla --- 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 +#include + +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 Signed-off-by: Radha Mohan Chintakuntla --- 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 +#include + +#include +#include +#include +#include + +#include + +#include + +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(®s); + + 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(®s); + + return regs.regs[0]; +} + +ssize_t atf_get_pcount(void) +{ + struct pt_regs regs; + regs.regs[0] = THUNDERX_PART_COUNT; + + smc_call(®s); + + 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(®s); + + 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(®s); + + 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(®s); + + 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(®s); + + 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(®s); + + return regs.regs[0]; +} + +ssize_t atf_node_count(void) +{ + struct pt_regs regs; + regs.regs[0] = THUNDERX_NODE_COUNT; + + smc_call(®s); + + return regs.regs[0]; +} + +ssize_t atf_env_count(void) +{ + struct pt_regs regs; + regs.regs[0] = THUNDERX_ENV_COUNT; + + smc_call(®s); + + 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(®s); + + 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(®s); + + printf("ARM Std FW version: %ld.%ld\n", regs.regs[0], regs.regs[1]); + + regs.regs[0] = THUNDERX_SVC_VERSION; + + smc_call(®s); + + 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 long i; + int ret; + char *ptype; + + struct storage_partition *part = (void *)CONFIG_SYS_LOWMEM_BASE; + + pcount = atf_get_pcount(); + +
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 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 > Cc: Fabio Estevam > Cc: Stefano Babic > Cc: Tim Harvey > Cc: Eric Nelson It does looks way nicer. It is much easier to understand what is going behind the scenes. Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx6sabresd: Fix SPL memory description
From: Fabio Estevam 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 --- 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 RTT_NOM_120OHM is not defined, so remove its ifdef. Signed-off-by: Fabio Estevam --- 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 --- 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
Re: [U-Boot] Please pull u-boot-dm
Hi Tom, On 16 April 2015 at 11:43, Tom Rini 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
[U-Boot] [PATCH v2] mx6: Add initial SPL support for HummingBoard-i2eX
From: Fabio Estevam 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 --- 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 +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 +# +# (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 + * + * Copyright (C) 2013 Jon Nettleton + * + * Based on SPL code from Solidrun tree, which is: + * Author: Tungyi Lin + * + * Derived from EDM_CF_IMX6 code by TechNexion,Inc + * Ported to SolidRun microSOM by Rabeeh Khoury + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ +
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 : > 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 >> --- >> >> 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
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 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 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 >> --- >> >> 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] 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
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 > > > > > > > > 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 > > > > Signed-off-by: Michal Simek > > > > --- > > > > > > > > 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.den
[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 Cc: York Sun --- 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 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 Cc: York Sun --- 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 #define CONFIG_SYS_FSL_IFC
[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 Cc: York Sun --- 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: + break; + case QIXIS_ESDHC_ADA
[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 Cc: York Sun --- 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 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 wrote: >> From: Siva Durga Prasad Paladugu >> >> Added the SPI driver support for ZynqMP >> The controller is same as zynq SPI controller >> >> Signed-off-by: Siva Durga Prasad Paladugu >> Signed-off-by: Michal Simek >> --- >> >> 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
Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix
On 2015-04-14 16:30, Ian Campbell wrote: > On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote: >> On 2015-04-14 16:06, Stephen Warren wrote: >>> On 04/14/2015 07:46 AM, Tom Rini wrote: On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote: > Changes in v6: > - rebased over master > - included Thierry's SMMU enabling patch > - moved activation patch at the end so that it can be held back > > This version can also be found at > https://github.com/siemens/u-boot/tree/jetson-tk1-v6. So what level of coordination do we need on applying this series so that kernels (both old and new) can continue to function? And perhaps README updates or similar? Thanks! >>> >>> Hopefully this series doesn't change anything by default, and simply >>> allows people to turn on support for booting kernels in non-secure mode >>> if they want to? If so, there shouldn't be any co-ordination required. >>> If it changes the default behaviour, co-ordination is probably required, >>> and that'd be a bad thing. >> >> Sorry, forgot to mention: I can't flip the default behaviour to leave >> virtualization support off only for the TK1. That's a generic default. > > Would enabling it in the compile but adding "bootm_boot_mode=sec" to the > default environment (so it isn't used by default) be considered > sufficiently backwards compatible? This turned out to not work as expected: booting in secure mode seems to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be expected or a bug, but I will now take a different route: diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig index 61e7c82..e5d4dcc 100644 --- a/arch/arm/cpu/armv7/Kconfig +++ b/arch/arm/cpu/armv7/Kconfig @@ -27,7 +27,7 @@ config ARMV7_BOOT_SEC_DEFAULT config ARMV7_VIRT boolean "Enable support for hardware virtualization" if EXPERT depends on CPU_V7_HAS_VIRT && ARMV7_NONSEC - default y + default y if !TEGRA ---help--- Say Y here to boot in hypervisor (HYP) mode when booting non-secure. A patch to be inserted before the last one (and to be reverted once Linux is fixed) will follow. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot][PATCH 0/2] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA
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 >> >> 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. Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14.5/15] tegra: Keep virt support disabled by default
Upstream Linux is broken with default configs when PSCI is enabled. So the user should explicitly enable virtualization, e.g. when she disabled CONFIG_CPU_IDLE in Linux (in which case it's safe to use). We can revert this workaround once Linux got fixed. Signed-off-by: Jan Kiszka --- arch/arm/cpu/armv7/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig index 61e7c82..e5d4dcc 100644 --- a/arch/arm/cpu/armv7/Kconfig +++ b/arch/arm/cpu/armv7/Kconfig @@ -27,7 +27,7 @@ config ARMV7_BOOT_SEC_DEFAULT config ARMV7_VIRT boolean "Enable support for hardware virtualization" if EXPERT depends on CPU_V7_HAS_VIRT && ARMV7_NONSEC - default y + default y if !TEGRA ---help--- Say Y here to boot in hypervisor (HYP) mode when booting non-secure. -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot