Re: [U-Boot] [PATCH 1/4] USB: ohci-at91: support sama5d3x devices
Dear Bo Shen, On 28.02.13 08:00, Bo Shen wrote: Add OHCI support for sama5d3x devices Signed-off-by: Bo Shen voice.s...@atmel.com --- drivers/usb/host/ohci-at91.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index efd711d..35a282e 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -42,7 +42,7 @@ int usb_cpu_init(void) while ((readl(pmc-sr) AT91_PMC_LOCKB) != AT91_PMC_LOCKB) ; #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9X5) || defined(CONFIG_SAMA5D3) I think these ifdeffery increases alarmingly here and there. Can we find a better solution like #if defined(ATMEL_OHCI_NEEDS_UPLL) or whatever we can call it. I mean to classify this and enable it in the respective SoC headers. Maybe here we can distinguish upon the IP version? /* Enable UPLL */ writel(readl(pmc-uckr) | AT91_PMC_UPLLEN | AT91_PMC_BIASEN, pmc-uckr); @@ -54,7 +54,12 @@ int usb_cpu_init(void) #endif /* Enable USB host clock. */ +#if defined(CONFIG_SAMA5D3) I think this ifdef is Ok instead. + writel(1 (ATMEL_ID_UHP - 32), pmc-pcer1); +#else writel(1 ATMEL_ID_UHP, pmc-pcer); +#endif + #ifdef CONFIG_AT91SAM9261 writel(ATMEL_PMC_UHP | AT91_PMC_HCK0, pmc-scer); #else @@ -69,7 +74,12 @@ int usb_cpu_stop(void) at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC; /* Disable USB host clock. */ +#if defined(CONFIG_SAMA5D3) + writel(1 (ATMEL_ID_UHP - 32), pmc-pcdr1); +#else writel(1 ATMEL_ID_UHP, pmc-pcdr); +#endif + #ifdef CONFIG_AT91SAM9261 writel(ATMEL_PMC_UHP | AT91_PMC_HCK0, pmc-scdr); #else @@ -83,7 +93,7 @@ int usb_cpu_stop(void) while ((readl(pmc-sr) AT91_PMC_LOCKB) != 0) ; #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9X5) || defined(CONFIG_SAMA5D3) /* Disable UPLL */ writel(readl(pmc-uckr) (~AT91_PMC_UPLLEN), pmc-uckr); while ((readl(pmc-sr) AT91_PMC_LOCKU) == AT91_PMC_LOCKU) I think the ifdef comment above is no show stopper for this patch but should be considered at least for a future patch. The rest looks sane to me. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] NET: macb: support sama5d3x devices
Dear Bo Shen, On 28.02.13 08:00, Bo Shen wrote: Add macb support for sama5d3x devices Signed-off-by: Bo Shen voice.s...@atmel.com --- drivers/net/macb.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 8bacbda..9e7fbc6 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -469,7 +469,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) || \ + defined(CONFIG_SAMA5D3) macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, 0); @@ -478,7 +479,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9XE) || defined(CONFIG_AT91SAM9X5) || \ + defined(CONFIG_SAMA5D3) macb_writel(macb, USRIO, MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, MACB_BIT(MII)); same about the ifdeffery as in '[PATCH 1/4] USB: ohci-at91: support sama5d3x devices'. No concrete denial to get sama5 working, but we should really cleanup this mess. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
Is there anyone that can support me with enforcing GPL compliance on company that ships product with binary u-boot? Or did that in the past? We can try. They're made (branded is probably better word) by local companies, and my guess is that most of them is violating GPL. Guesses are not good enough in such legal affairs. I can't do much myself (except for nagging them for source code), as it's not my copyrights that they're infringing. So did you contact the vendor and ask for the source code? And did they answer, and what exactly? Technically... he should have got source code or written offer for it with the device. So they are already breaking GPL. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7 09/10] COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition
Dear Wolfgang, Thank you for the comments. Ok, I will make this code conditional. I will prepare a new patch and post the same. Thanks Regards Amarendra On 6 March 2013 02:12, Wolfgang Denk w...@denx.de wrote: Dear Amar, In message 1362489090-7745-10-git-send-email-amarendra...@samsung.com you wrote: This patch adds commands to access(open/close) and resize boot partitions on EMMC. Signed-off-by: Amar amarendra...@samsung.com Acked-by: Simon Glass s...@chromium.org Can you please make this code conditional, so only boards that want this feature (and actually use EMMC) suffer from the increased memory footprint? Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A dog always bit deepest on the veterinary hand. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7 07/10] MMC: APIs to support resize of EMMC boot partition
Dear Wolfgang, Thank you for the comments. Ok, I will make this code conditional. I will prepare a new patch and post the same. Thanks Regards Amarendra On 6 March 2013 02:13, Wolfgang Denk w...@denx.de wrote: Dear Amar, In message 1362489090-7745-8-git-send-email-amarendra...@samsung.com you wrote: This patch adds APIs to access(open / close) and to resize boot partiton of EMMC. Can you please make this code conditional, so only boards that want this feature (and actually use EMMC) suffer from the increased memory footprint? Thanks. Viele Grüße, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The price of success is hard work, dedication to the job at hand, and the determination that whether we win or lose, we have applied the best of ourselves to the task at hand. - Vince Lombardi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 27/31] avr32: Fix cast warning in board.c
Dear Simon Glass, On 06.03.13 01:40, Simon Glass wrote: The frame buffer pointer in global_data is not a pointer, so we should remove these casts. Is this series intended for 2013.04? I'm asking cause there is still a patch [1] in patchwork which I would apply then. If this series will make it into 2013.04 I will give you my Acked-by: Andreas Bießmann andreas.de...@googlemail.com and set the other patch to superseded. A runtime test of this series on avr32 would be good (cause of the section changes). I try my best to do it these days. Best regards Andreas Bießmann [1] http://patchwork.ozlabs.org/patch/220413/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Wolfgang Denk, On Thursday, March 7, 2013 7:57:13 AM, Wolfgang Denk wrote: Dear Benoît Thébaudeau, In message 1362596377-5827-15-git-send-email-benoit.thebaud...@advansee.com you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. I don't think so. They're indeed not supposed to be used, but there are perhaps exceptions somewhere, and it's not the purpose of this script to enforce such a rule. Also, note that lowercase letters are used in the main line filter of this script too. But if this is a strong requirement from you to remove lowercase letters here, just tell me, and I'll make the change. In that case, should the main line filter be changed too? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 v2] ppc4xx: Add lcd4_lwmon5 support
This patch adds the fast booting LWMON5 derivat lcd4_lwmon5.
Its a stripped down version of the full blown lwmon5 support,
without ECC, USB, POST and some other stuff. It used the newly
introduced SPL infrastrucure for SPL from NOR flash booting
on the PPC4xx.
By setting the environment variable boot_os to yes, Linux
will be started from the SPL version. If not, the normal
U-Boot will be started.
Signed-off-by: Stefan Roese s...@denx.de
---
v2:
- Call board_init_f() from spl_board_init(). This initializes
the PFC registers needed for example for working ethernet in Linux.
board/lwmon5/lwmon5.c| 69 ++--
board/lwmon5/sdram.c | 4 ++-
boards.cfg | 1 +
include/configs/lwmon5.h | 68 ---
4 files changed, 136 insertions(+), 6 deletions(-)
diff --git a/board/lwmon5/lwmon5.c b/board/lwmon5/lwmon5.c
index ecd9536..db49c19 100644
--- a/board/lwmon5/lwmon5.c
+++ b/board/lwmon5/lwmon5.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2007-2010
+ * (C) Copyright 2007-2013
* Stefan Roese, DENX Software Engineering, s...@denx.de.
*
* This program is free software; you can redistribute it and/or
@@ -200,9 +200,11 @@ int misc_init_r(void)
u32 pbcr;
int size_val = 0;
u32 reg;
+#ifndef CONFIG_LCD4_LWMON5
unsigned long usb2d0cr = 0;
unsigned long usb2phy0cr, usb2h0cr = 0;
unsigned long sdr0_pfc1, sdr0_srst;
+#endif
/*
* FLASH stuff...
@@ -233,6 +235,7 @@ int misc_init_r(void)
CONFIG_ENV_ADDR_REDUND + 2 * CONFIG_ENV_SECT_SIZE - 1,
flash_info[cfi_flash_num_flash_banks - 1]);
+#ifndef CONFIG_LCD4_LWMON5
/*
* USB suff...
*/
@@ -306,6 +309,7 @@ int misc_init_r(void)
/* 7. Reassert internal PHY reset: */
mtsdr(SDR0_SRST1, SDR0_SRST1_USB20PHY);
udelay(1000);
+#endif
/*
* Clear resets
@@ -313,7 +317,9 @@ int misc_init_r(void)
mtsdr(SDR0_SRST1, 0x);
mtsdr(SDR0_SRST0, 0x);
+#ifndef CONFIG_LCD4_LWMON5
printf(USB: Host(int phy) Device(ext phy)\n);
+#endif
/*
* Clear PLB4A0_ACR[WRP]
@@ -323,10 +329,12 @@ int misc_init_r(void)
reg = mfdcr(PLB4A0_ACR) ~PLB4Ax_ACR_WRP_MASK;
mtdcr(PLB4A0_ACR, reg);
+#ifndef CONFIG_LCD4_LWMON5
/*
* Init matrix keyboard
*/
misc_init_r_kbd();
+#endif
return 0;
}
@@ -336,7 +344,7 @@ int checkboard(void)
char buf[64];
int i = getenv_f(serial#, buf, sizeof(buf));
- puts(Board: lwmon5);
+ printf(Board: %s, __stringify(CONFIG_HOSTNAME));
if (i 0) {
puts(, serial# );
@@ -495,3 +503,60 @@ void board_reset(void)
{
gpio_write_bit(CONFIG_SYS_GPIO_BOARD_RESET, 1);
}
+
+#ifdef CONFIG_SPL_OS_BOOT
+/*
+ * lwmon5 specific implementation of spl_start_uboot()
+ *
+ * RETURN
+ * 0 if booting into OS is selected (default)
+ * 1 if booting into U-Boot is selected
+ */
+int spl_start_uboot(void)
+{
+ char s[8];
+
+ env_init();
+ getenv_f(boot_os, s, sizeof(s));
+ if ((s != NULL) (strcmp(s, yes) == 0))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * This function is called from the SPL U-Boot version for
+ * early init stuff, that needs to be done for OS (e.g. Linux)
+ * booting. Doing it later in the real U-Boot would not work
+ * in case that the SPL U-Boot boots Linux directly.
+ */
+void spl_board_init(void)
+{
+ const gdc_regs *regs = board_get_regs();
+
+ /*
+* Setup PFC registers, mainly for ethernet support
+* later on in Linux
+*/
+ board_early_init_f();
+
+ /*
+* Reset Lime controller
+*/
+ gpio_write_bit(CONFIG_SYS_GPIO_LIME_S, 1);
+ udelay(500);
+ gpio_write_bit(CONFIG_SYS_GPIO_LIME_RST, 1);
+
+ out_be32((void *)CONFIG_SYS_LIME_SDRAM_CLOCK, CONFIG_SYS_MB862xx_CCF);
+ udelay(300);
+ out_be32((void *)CONFIG_SYS_LIME_MMR, CONFIG_SYS_MB862xx_MMR);
+
+ while (regs-index) {
+ out_be32((void *)(CONFIG_SYS_LIME_BASE_0 + GC_DISP_BASE) +
+regs-index, regs-value);
+ regs++;
+ }
+
+ board_backlight_brightness(DEFAULT_BRIGHTNESS);
+}
+#endif
diff --git a/board/lwmon5/sdram.c b/board/lwmon5/sdram.c
index b64b35a..78b8fbc 100644
--- a/board/lwmon5/sdram.c
+++ b/board/lwmon5/sdram.c
@@ -6,7 +6,7 @@
* Alain Saurel, AMCC/IBM, alain.sau...@fr.ibm.com
* Robert Snyder, AMCC/IBM, rob.sny...@fr.ibm.com
*
- * (C) Copyright 2007-2008
+ * (C) Copyright 2007-2013
* Stefan Roese, DENX Software Engineering, s...@denx.de.
*
* This program is free software; you can redistribute it and/or
@@ -160,6 +160,7 @@ static void program_ecc(u32 start_address,
/
Re: [U-Boot] driver for davicom dm9601 usb-ethernet NIC
Beagle == Beagle board beagleboar...@gmail.com writes:
Beagle Hello Everyone,
Beagle I'm working on Beagleboard C3, and i'm trying to do an nfs-boot.
Beagle Please find below my bootup log. I'm getting the below error.
Beagle After digging into the details of the error, could make out that my
Beagle Ethernet NIC is not there in the supported drivers list of U-Boot
Beagle {drivers/usb/eth/}
Beagle I'm using Davicom DM9601 USB-Ethernet NIC. I would like to
Beagle check with u guys whether u've got any drivers for the same?
No, there's no driver for the dm9601 in U-Boot (only for asix/smsc95xx
based devices). The dm9601 is quite simple, so you could write a driver
for it or alternative buy an asix/smsc95xx based dongle.
--
Bye, Peter Korsgaard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] PHY: micrel.c: add support for KSZ9031
Hi David,
On 06.02.2013 22:18, David Andrey wrote:
Add support for Micrel PHY KSZ9031 in phylib,
including small rework for KSZ9021 to avoid
code duplication
Signed-off-by: David Andrey david.and...@netmodule.com
Cc: Troy Kisky troy.ki...@boundarydevices.com
Cc: Joe Herschberger joe.hershber...@gmail.com
Cc: Andy Fleming aflem...@freescale.com
---
Changes for v2:
- Same startup function for KSZ9021 and 9031
---
drivers/net/phy/micrel.c | 79
++
1 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 30f3264..2a8b6cb 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -18,6 +18,7 @@
*
* Copyright 2010-2011 Freescale Semiconductor, Inc.
* author Andy Fleming
+ * (C) 2012 NetModule AG, David Andrey, added KSZ9031
*
*/
#include config.h
@@ -52,16 +53,46 @@ static struct phy_driver KS8721_driver = {
};
#endif
+
+/**
+ * KSZ9021 - KSZ9031 common
+ */
+
+#define MII_KSZ90xx_PHY_CTL 0x1f
+#define MIIM_KSZ90xx_PHYCTL_1000 (1 6)
+#define MIIM_KSZ90xx_PHYCTL_100 (1 5)
+#define MIIM_KSZ90xx_PHYCTL_10 (1 4)
+#define MIIM_KSZ90xx_PHYCTL_DUPLEX (1 3)
+
+static int ksz90xx_startup(struct phy_device *phydev)
+{
+ unsigned phy_ctl;
+ genphy_update_link(phydev);
+ phy_ctl = phy_read(phydev, MDIO_DEVAD_NONE, MII_KSZ90xx_PHY_CTL);
+
+ if (phy_ctl MIIM_KSZ90xx_PHYCTL_DUPLEX)
+ phydev-duplex = DUPLEX_FULL;
+ else
+ phydev-duplex = DUPLEX_HALF;
+
+ if (phy_ctl MIIM_KSZ90xx_PHYCTL_1000)
+ phydev-speed = SPEED_1000;
+ else if (phy_ctl MIIM_KSZ90xx_PHYCTL_100)
+ phydev-speed = SPEED_100;
+ else if (phy_ctl MIIM_KSZ90xx_PHYCTL_10)
+ phydev-speed = SPEED_10;
+ return 0;
+}
#ifdef CONFIG_PHY_MICREL_KSZ9021
-/* ksz9021 PHY Registers */
+
+/*
+ * KSZ9021
+ */
+
+/* PHY Registers */
#define MII_KSZ9021_EXTENDED_CTRL0x0b
#define MII_KSZ9021_EXTENDED_DATAW 0x0c
#define MII_KSZ9021_EXTENDED_DATAR 0x0d
-#define MII_KSZ9021_PHY_CTL 0x1f
-#define MIIM_KSZ9021_PHYCTL_1000 (1 6)
-#define MIIM_KSZ9021_PHYCTL_100 (1 5)
-#define MIIM_KSZ9021_PHYCTL_10 (1 4)
-#define MIIM_KSZ9021_PHYCTL_DUPLEX (1 3)
#define CTRL1000_PREFER_MASTER (1 10)
#define CTRL1000_CONFIG_MASTER (1 11)
@@ -106,37 +137,30 @@ static int ksz9021_config(struct phy_device *phydev)
return 0;
}
-static int ksz9021_startup(struct phy_device *phydev)
-{
- unsigned phy_ctl;
- genphy_update_link(phydev);
- phy_ctl = phy_read(phydev, MDIO_DEVAD_NONE, MII_KSZ9021_PHY_CTL);
-
- if (phy_ctl MIIM_KSZ9021_PHYCTL_DUPLEX)
- phydev-duplex = DUPLEX_FULL;
- else
- phydev-duplex = DUPLEX_HALF;
-
- if (phy_ctl MIIM_KSZ9021_PHYCTL_1000)
- phydev-speed = SPEED_1000;
- else if (phy_ctl MIIM_KSZ9021_PHYCTL_100)
- phydev-speed = SPEED_100;
- else if (phy_ctl MIIM_KSZ9021_PHYCTL_10)
- phydev-speed = SPEED_10;
- return 0;
-}
-
static struct phy_driver ksz9021_driver = {
.name = Micrel ksz9021,
.uid = 0x221610,
.mask = 0xf0,
Why don't you just change the mask to support both PHY's with one struct
here? Something like this:
static struct phy_driver ksz9021_driver = {
- .name = Micrel ksz9021,
+ .name = Micrel ksz90x1,
.uid = 0x221610,
- .mask = 0xf0,
+ .mask = 0xc0,
This would be much simpler. Does it work for you?
Best regards,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] Exynos5: Pinmux: Add fdt for pinmux
This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.
Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO numbering feature
URL: http://lists.denx.de/pipermail/u-boot/2013-February/146151.html
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Device tree bindings changed to linux style.
- Added documentation for samsung pinctrl.
Changes since v2:
- Rebased as per new version of GPIO numbering patch-set.
Changes since v3:
- Added comments to reduce ambiguity and increase readability.
- Fixed few other nits.
Changes since v4:
- Added support for reading peripheral pinctrl subnode names from
preipheral's node instead of hard coding.
arch/arm/cpu/armv7/exynos/pinmux.c | 357 +++---
arch/arm/dts/exynos5250-pinctrl.dtsi | 675 +++
arch/arm/dts/exynos5250.dtsi | 92
board/samsung/dts/exynos5250-smdk5250.dts| 11 +
doc/device-tree-bindings/samsung-pinctrl.txt | 253 ++
include/fdtdec.h | 4 +
lib/fdtdec.c | 4 +
7 files changed, 1231 insertions(+), 165 deletions(-)
create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi
create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index a01ce0c..119db82 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -23,10 +23,20 @@
#include common.h
#include fdtdec.h
+#include linux/ctype.h
#include asm/arch/gpio.h
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Struct for temporarily storing pin related info */
+struct pin_group {
+ uint8_t function; /* Pin function */
+ uint8_t pull_mode; /* Pin pull mode */
+ uint8_t drive_strength; /* Pin drive strength */
+};
+
struct gpio_name_num_table exynos5_gpio_table[] = {
{ 'a', GPIO_A00 },
{ 'b', GPIO_B00 },
@@ -42,252 +52,271 @@ struct gpio_name_num_table exynos5_gpio_table[] = {
{ 'z', GPIO_Z0 },
};
-static void exynos5_uart_config(int peripheral)
+/* Extract and set pins in a particular pinctrl node */
+static void pinmux_set_pins(const char *fprop_data,
+ struct pin_group *pingrp)
{
- int i, start, count;
+ int i;
+ char gpio[5];
+
+ /*
+* Get all the pin names from fdt and fill the gpio array
+* with corresponding enum values(Pin numbers).
+*/
+ for (i = 0; !(fprop_data[i] == (int)NULL
+ fprop_data[i+1] == (int)NULL); i += 7) {
+ int pin_num = -1;
+
+ /*
+* Modify pin name retrieved from fdt,
+* so that name_to_gpio may understand.
+*/
+ gpio[0] = fprop_data[i];
+ gpio[1] = fprop_data[i + 1];
+ gpio[2] = fprop_data[i + 2];
+ gpio[3] = fprop_data[i + 3];
+ gpio[4] = fprop_data[i + 5];
+
+ pin_num = name_to_gpio(gpio);
+
+ /*
+* If pin number is valid, add it to the pin array
+* and increment pin count.
+*/
+ if (pin_num = 0) {
+ gpio_cfg_pin(pin_num,
+ S5P_GPIO_FUNC(pingrp-function));
+ gpio_set_pull(pin_num, pingrp-pull_mode);
+ gpio_set_drv(pin_num, pingrp-drive_strength);
+ }
+ }
+}
+
+/* Extract all the config info from pinctrl periph subnodei */
+static int pinmux_do_config(struct pin_group *pingrp, const char * dev_name)
+{
+ int node, subnode;
+ const char *fprop_data;
+
+ /* Loop for all pinctrl nodes in fdt */
+ for (node = fdtdec_next_compatible(gd-fdt_blob, 0,
+ COMPAT_SAMSUNG_PINCTRL); node = 0;
+ node = fdtdec_next_compatible(gd-fdt_blob, node,
+ COMPAT_SAMSUNG_PINCTRL)) {
+ /* Get the subnode from FDT for this peripheral*/
+ subnode = fdt_subnode_offset(gd-fdt_blob,
+ node, dev_name);
+ if (subnode 0)
+ continue;
+
+ /* Get names of pins to be configured from fdt */
+ fprop_data = fdt_getprop(gd-fdt_blob,
+ subnode, samsung,pins, NULL);
+
+ /* Get the pin function from fdt */
+ pingrp-function = fdtdec_get_int(gd-fdt_blob,
+
Re: [U-Boot] [PATCH v4 1/2] usb: ehci: exynos: Fix multiple FDT decode
On Wed, Mar 6, 2013 at 12:48 AM, Vivek Gautam gautam.vi...@samsung.com wrote: With current FDT support driver tries to parse device node twice in ehci_hcd_init() and ehci_hcd_stop(), which shouldn't happen ideally. Making provision to store data in a global structure and thereby passing its pointer when needed. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes from v3: - Checking for error return in exynos_usb_parse_dt() and returning there only in case of failure for DT systems. - Removed unnecesassry parentheses. Changes from v2: - Using hcd as struct ehci_hccr * rather than unsigned int to avoid unnecessary typecasting later in the code. - Further using local variable of type fdt_addr_t in exynos_usb_parse_dt() and modifying the code as required. Changes from v1: - Added patch to fix problem of multiple FDT decode. drivers/usb/host/ehci-exynos.c | 44 ++- 1 files changed, 16 insertions(+), 28 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v5] Exynos: Add hardware accelerated SHA256 and SHA1
On Wed, Mar 6, 2013 at 6:18 AM, Akshay Saraswat aksha...@samsung.com wrote: SHA-256 and SHA-1 accelerated using ACE hardware. Signed-off-by: ARUN MANKUZHI aru...@samsung.com Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes since v1: - Moved code to drivers/crypto. - Fixed few other nits. Changes since v2: - Added falling back to software sha256 in case length exceeds buffer limit. - Reduced one tab at lines 533, 559 and 571 in this patch. - Removed space after a cast at line 506 in this patch. - Removed blank line at line 561 in this patch. - Removed space before semicolon at line 576 in this patch. Changes since v3: - Removed buffer limit since there are 2 regs for address hash_msg_size_high and low. That means buffer length could go upto 2^64 bits which is practically - Removed falling back to software sha256 because there is no buffer limit. - Removed / 4 to sha1 and sha256 lengths and added increment to 4 in for loop at line 573. - Timed out still kept to be 100 ms since this is enough for hardware to switch status to idle from busy. In case it couldn't that means h/w is faulty. Changes since v4: - Added include for clk.h. - Added define for MAX_FREQ. - Added timeout calculation as per frequency. - Changed i+=4 to i++ and len to len/4 in for loop at line 591 in this patch. - Added two new functions ace_sha256 and ace_sha1. Makefile | 1 + arch/arm/include/asm/arch-exynos/cpu.h | 4 + drivers/crypto/Makefile| 47 + drivers/crypto/ace_sfr.h | 310 + drivers/crypto/ace_sha.c | 138 +++ include/ace_sha.h | 67 +++ 6 files changed, 567 insertions(+) create mode 100644 drivers/crypto/Makefile create mode 100644 drivers/crypto/ace_sfr.h create mode 100644 drivers/crypto/ace_sha.c create mode 100644 include/ace_sha.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v5] gen: Add ACE acceleration to hash
On Wed, Mar 6, 2013 at 6:18 AM, Akshay Saraswat aksha...@samsung.com wrote: ACE H/W acceleration support is added to hash which can be used to test SHA 256 hash algorithm. Signed-off-by: ARUN MANKUZHI aru...@samsung.com Signed-off-by: Akshay Saraswat aksha...@samsung.com From my side this looks good, thanks. Acked-by: Simon Glass s...@chomium.org --- Changes since v1: - Added sha256 support to hash command instead of new sha256 command. Changes sice v2: - Added new nodes for SHA1 and SHA256 in struct hash_algo for the case when ACE is enabled. - Added new declaration for function pointer hash_func_ws with different return type. Changes sice v3: - Changed command names to lower case in algo struct. - Added generic ace_sha config. Changes sice v4: - Changed function names in struct algo. - Replaced ACE_SHA_TYPE to CHUNSZ in struct algo. common/hash.c | 14 ++ 1 file changed, 14 insertions(+) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length
When working on RAW partitions, it's possible that the whole area
is larger than DDR. So what we need to do is make sure that the length
we are given is aligned with the LBA block size, then pass that length
in as our count of LBA blocks to operate on. In doing this, we no
longer need to modify *len on read operations.
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Tom Rini tr...@ti.com
---
drivers/dfu/dfu_mmc.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 083d745..0bed405 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -34,14 +34,21 @@ static int mmc_block_op(enum dfu_mmc_op op, struct
dfu_entity *dfu,
{
char cmd_buf[DFU_CMD_BUF_SIZE];
- sprintf(cmd_buf, mmc %s 0x%x %x %x,
- op == DFU_OP_READ ? read : write,
- (unsigned int) buf,
- dfu-data.mmc.lba_start,
- dfu-data.mmc.lba_size);
+ /*
+* We must ensure that we read in lba_blk_size chunks, so ALIGN
+* this value.
+*/
+ *len = ALIGN(*len, dfu-data.mmc.lba_blk_size);
+
+ if (*len (dfu-data.mmc.lba_size * dfu-data.mmc.lba_blk_size)) {
+ puts(Request would exceed designated area!\n);
+ return -EINVAL;
+ }
- if (op == DFU_OP_READ)
- *len = dfu-data.mmc.lba_blk_size * dfu-data.mmc.lba_size;
+ sprintf(cmd_buf, mmc %s 0x%x %x %lx,
+ op == DFU_OP_READ ? read : write,
+ (unsigned int) buf, dfu-data.mmc.lba_start,
+ *len / dfu-data.mmc.lba_blk_size);
debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
return run_command(cmd_buf, 0);
--
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] mtd: nand: fix the written length when nand_write_skip_bad failed
Hi, Scott
On Thu, Mar 7, 2013 at 2:22 AM, Scott Wood scottw...@freescale.com wrote:
On 03/06/2013 08:56:56 AM, htbegin wrote:
Hi, Scott
Thanks for your review.
On Tue, Mar 5, 2013 at 9:58 AM, Scott Wood scottw...@freescale.com
wrote:
On 03/02/2013 03:01:10 AM, Tao Hou wrote:
When the data has been partially written into the NAND Flash,
returning the written length instead of 0. The written length
may be useful when the upper level decides to continue the writing
after skipping the block causing the write failure.
We already do that in some code paths.
Signed-off-by: Tao Hou hotfor...@gmail.com
Cc: Scott Wood scottw...@freescale.com
Cc: Ben Gardiner bengardi...@nanometrics.ca
Cc: Lei Wen lei...@marvell.com
---
drivers/mtd/nand/nand_util.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
Could you rebase this on top of this patch:
http://patchwork.ozlabs.org/patch/224842/
Do you mean a V2 patch ?
Yes.
I will send a V2 patch once we reach an agreement on the
written_length problem.
BTW, are you actually using WITH_YAFFS_OOB? I think there are some
other
things wrong with it at the moment, as mentioned here:
http://lists.denx.de/pipermail/u-boot/2013-March/148378.html
No, I don't use it.
Changes to that code should be tested by someone...
Sorry, I can't help.
if (rval != 0) {
printf(NAND write to offset %llx failed %d\n,
offset, rval);
- *length -= left_to_write;
+ *length -= left_to_write - written_size;
return rval;
}
...but I don't see why this part is needed (or correct). Why doesn't
*length -= left_to_write already get you what you want?
-Scott
I just use *length -= left_to_write - written_size to tell the upper
level that what
had been actually happened. For the current block, written_size has
been written to the NAND Flash yet, so left_to_write should be
subtracted by written_size.
But left_to_write isn't decreased until after this error return, so that's
already the case. Subtracting written_size from left_to_write has the
effect of increasing length by written_size, so the return value will now
look like the error page has been written.
-Scott
No, the returned value doesn't include the length of the error page.
In no-WITH_YAFFS_OOB case, when nand_write failed,
truncated_write_size has been
updated by nand_write to the length which has been successfully
written , so it's OK to subtract written_size from left_to_write.
In WITH_YAFFS_OOB case, when nand-write_oob failed, written_size is
also the length which has been successfully written.
Cheers,
Hou
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] RX-51: Add support for bootmenu
Hi, I'm sending new version of patch which try to use also ext filesystem (not
only fat)
From 4798e0c932577012ccde38f6b23413109f4b2fba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= pali.ro...@gmail.com
Date: Sat, 14 Jan 2012 18:57:31 +0100
Subject: [PATCH] RX-51: Add support for bootmenu
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* default bootmenu entries:
attached kernel, internal eMMC memory, external SD card, u-boot boot order
* in CONFIG_PREBOOT try load bootmenu.scr from first partition of internal
eMMC memory (also known as MyDocs) which (should) overwrite default bootmenu
entries
* when keyboard slide is closed boot first menu entry
* when keyborad slide is open show bootmenu
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
include/configs/nokia_rx51.h | 40 +---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 8506604..965330a 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -148,6 +148,7 @@
#define CONFIG_CMDLINE_EDITING /* add command line history */
#define CONFIG_AUTO_COMPLETE /* add autocompletion support */
+#define CONFIG_CMD_BOOTMENU/* ANSI terminal Boot Menu */
#define CONFIG_CMD_CLEAR /* ANSI terminal clear screen command */
#ifdef ONENAND_SUPPORT
@@ -287,8 +288,6 @@ int rx51_kp_getc(void);
#endif
/* Environment information */
-#define CONFIG_BOOTDELAY 3
-
#define CONFIG_EXTRA_ENV_SETTINGS \
mtdparts= MTDPARTS_DEFAULT \0 \
usbtty=cdc_acm\0 \
@@ -360,10 +359,40 @@ int rx51_kp_getc(void);
fi\0 \
emmcboot=setenv mmcnum 1; run trymmcboot\0 \
sdboot=setenv mmcnum 0; run trymmcboot\0 \
+ menucmd=bootmenu\0 \
+ bootmenu_0=Attached kernel=run attachboot\0 \
+ bootmenu_1=Internal eMMC=run emmcboot\0 \
+ bootmenu_2=External SD card=run sdboot\0 \
+ bootmenu_3=U-Boot boot order=boot\0 \
+ bootmenu_delay=30\0 \
#define CONFIG_PREBOOT \
- if run slide; then true; else run attachboot; fi; \
+ setenv mmcnum 1; setenv mmcpart 1; \
+ setenv mmcscriptfile bootmenu.scr; \
+ if run switchmmc; then \
+ setenv mmcdone true; \
+ setenv mmctype fat; \
+ if run scriptload; then true; else \
+ setenv mmctype ext2; \
+ if run scriptload; then true; else \
+ setenv mmctype ext4; \
+ if run scriptload; then true; else \
+ setenv mmcdone false; \
+ fi; \
+ fi; \
+ fi; \
+ if ${mmcdone}; then \
+ run scriptboot; \
+ fi; \
+ fi; \
+ if run slide; then true; else \
+ setenv bootmenu_delay 0; \
+ setenv bootdelay 0; \
+ fi
+
+#define CONFIG_POSTBOOTMENU \
+ echo; \
echo Extra commands:; \
echo run sercon - Use serial port for control.; \
echo run usbcon - Use usbtty for control.; \
@@ -379,6 +408,11 @@ int rx51_kp_getc(void);
run attachboot; \
echo
+#define CONFIG_BOOTDELAY 30
+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_MENU
+#define CONFIG_MENU_SHOW
+
/*
* Miscellaneous configurable options
*/
--
1.7.10.4
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
Dear Pavel, In message 20130307091729.GA24807@xo-6d-61-c0.localdomain you wrote: So did you contact the vendor and ask for the source code? And did they answer, and what exactly? Technically... he should have got source code or written offer for it with the device. So they are already breaking GPL. Of course you are correct. But there is a wide ange of possibilies; some vendors just don't know what they are supposed to do, and are appreciative for a friendly hint. Of course there are also those where you need a fully charged blaster - but in my experience these are very few. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The evolution of the human race will not be accomplished in the ten thousand years of tame animals, but in the million years of wild animals, because man is and will always be a wild animal. - Charles Galton Darwin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] mx23/mxs pending patches
On 02/03/2013 21:58, Otavio Salvador wrote: On Sat, Mar 2, 2013 at 5:41 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, This patchset includes the pending patches we have in our tree. It fixes issues for mx23evk and mx23_olinuxino boards. This depends on Marek's patchset which has included most of the previous patches in this patchset. Changes in v5: - Adapt code to newer multiport support - Adapt code to newer multiport support Changes in v2: - Add changes for allow use of the USB hub - Remove extra newline Otavio Salvador (3): mx23evk: Enable USB support mx23_olinuxino: Enable USB support mx23_olinuxino: Add ethernet support I fail to understand what happened with that flurry of patches that was in V4. But maybe this is V5 for other series? I'm confused. The other patches of this serie you picked in your last pull request so I did not resend them to avoid making it more confusing for Stefano. Oh, I am stil lquite confused ;-) I admit I cannot follow the ML in the lastr two weeks due to a urgent project, and I get a flood in my mailbox. Anyway, I have no problems with this series, and no comments are open. I apply it now. Regards, Stefano So these are the 3 other ones. -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] mx23/mxs pending patches
Dear Stefano Babic, On 02/03/2013 21:58, Otavio Salvador wrote: On Sat, Mar 2, 2013 at 5:41 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, This patchset includes the pending patches we have in our tree. It fixes issues for mx23evk and mx23_olinuxino boards. This depends on Marek's patchset which has included most of the previous patches in this patchset. Changes in v5: - Adapt code to newer multiport support - Adapt code to newer multiport support Changes in v2: - Add changes for allow use of the USB hub - Remove extra newline Otavio Salvador (3): mx23evk: Enable USB support mx23_olinuxino: Enable USB support mx23_olinuxino: Add ethernet support I fail to understand what happened with that flurry of patches that was in V4. But maybe this is V5 for other series? I'm confused. The other patches of this serie you picked in your last pull request so I did not resend them to avoid making it more confusing for Stefano. Oh, I am stil lquite confused ;-) I admit I cannot follow the ML in the lastr two weeks due to a urgent project, and I get a flood in my mailbox. No kidding, same here. Anyway, I have no problems with this series, and no comments are open. I apply it now. Check u-boot-testing :: mx233 if it helps, I picked all patches that shall be applied in there. Regards, Stefano So these are the 3 other ones. 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 v5 0/3] mx23/mxs pending patches
On Thu, Mar 7, 2013 at 1:20 PM, Marek Vasut ma...@denx.de wrote: Dear Stefano Babic, On 02/03/2013 21:58, Otavio Salvador wrote: On Sat, Mar 2, 2013 at 5:41 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, This patchset includes the pending patches we have in our tree. It fixes issues for mx23evk and mx23_olinuxino boards. This depends on Marek's patchset which has included most of the previous patches in this patchset. Changes in v5: - Adapt code to newer multiport support - Adapt code to newer multiport support Changes in v2: - Add changes for allow use of the USB hub - Remove extra newline Otavio Salvador (3): mx23evk: Enable USB support mx23_olinuxino: Enable USB support mx23_olinuxino: Add ethernet support I fail to understand what happened with that flurry of patches that was in V4. But maybe this is V5 for other series? I'm confused. The other patches of this serie you picked in your last pull request so I did not resend them to avoid making it more confusing for Stefano. Oh, I am stil lquite confused ;-) I admit I cannot follow the ML in the lastr two weeks due to a urgent project, and I get a flood in my mailbox. No kidding, same here. Anyway, I have no problems with this series, and no comments are open. I apply it now. Check u-boot-testing :: mx233 if it helps, I picked all patches that shall be applied in there. There're patches which where not send for review there (as Makefile change) -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] mx23/mxs pending patches
On 07/03/2013 17:23, Otavio Salvador wrote: Check u-boot-testing :: mx233 if it helps, I picked all patches that shall be applied in there. There're patches which where not send for review there (as Makefile change) Of course, such patches (I have find only what you mention) cannot be picked up at all if not reviewed here. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] mxs: Reset the EMI block on mx23
On 23/02/2013 13:42, Marek Vasut wrote: The real reason for memory instability was the fact that the EMI block was gated and not reset throughout the boards' operation. This patch resets the EMI block properly while also reverts the memory voltage bump. The memory stability issues were caused by the EMI not being reset properly and thus there is no longer need to run the memory at higher voltage than it ought to run at. This partly reverts 8303ed128a55519f19c5f11087032d4bc4e0537a . Signed-off-by: Marek Vasut ma...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Cc: Otavio Salvador ota...@ossystems.com.br Cc: Stefano Babic sba...@denx.de --- Applied (whole series) to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/3] mx23_olinuxino: Enable USB support
On 02/03/2013 16:17, Otavio Salvador wrote: This enabled USB support for the mx23_olinuxino board. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Applied to u-boot-imx, but... /* SSP0 clock at 96MHz */ mxs_set_sspclk(MXC_SSPCLK0, 96000, 0); +#ifdef CONFIG_CMD_USB + /* Enable LAN9512 */ + gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1); +#endif ...the header for gpio is missing. Please send the patch to fix the warning. mx23_olinuxino.c: In function 'board_early_init_f': mx23_olinuxino.c:50:2: warning: implicit declaration of function 'gpio_direction_output' [-Wimplicit-function-declaration] Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] mx23_olinuxino: Add ethernet support
On 02/03/2013 16:17, Otavio Salvador wrote: This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] mx23evk: Enable USB support
On 02/03/2013 16:17, Otavio Salvador wrote: This enabled USB support for the mx23evk board. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6: Provide a structure for accessing HDMI registers
On 01/03/2013 01:35, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Provide a structure for accessing HDMI registers, so that we can use proper read/write accessors. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Tested-by: Eric Nelson eric.nel...@boundarydevices.com --- Applied to u-boot-imx, thanks Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: tegra: enable workaround for ARM erratum 716044
Stephen/Albert, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Monday, March 04, 2013 4:30 PM To: u-boot@lists.denx.de; Albert Aribaud Cc: Simon Glass; Tom Warren; Stephen Warren Subject: [PATCH 2/2] ARM: tegra: enable workaround for ARM erratum 716044 From: Stephen Warren swar...@nvidia.com Tegra20 requires the workaround for this erratum. Enable it. Signed-off-by: Stephen Warren swar...@nvidia.com --- include/configs/tegra20-common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20- common.h index e464e06..395a657 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -28,6 +28,7 @@ /* * Errata configuration */ +#define CONFIG_ARM_ERRATA_716044 #define CONFIG_ARM_ERRATA_742230 #define CONFIG_ARM_ERRATA_751472 The two sets of ARM erratum patches are currently assigned to Albert. I can take just the Tegra patches, since adding these #defines won't affect anything w/o the corresponding ARM code. Let me know if you (Albert) want me to take the 2 ARM: tegra: errata patches in thru the Tegra tree, or if you'll take 'em whole hog in thru ARM. Tom -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: mx6: use common CPU errata config options
On 26/02/2013 23:28, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Now that U-Boot has common CONFIG_ options to work around some ARM CPU errata, enable the relevant options on MX6, and remove the custom lowlevel_init.S, since it's just duplicated code now. Signed-off-by: Stephen Warren swar...@nvidia.com --- Hi Stephen, applied to u-boot-imx. It is not effective until Alber apply 1/3, but it does not hurt. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel 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] mx23_olinuxino: Fix warning for implicit declaration
Fixes a build warning of implicit declaration of gpio_direction_output, as bellow: , | mx23_olinuxino.c: In function 'board_early_init_f': | mx23_olinuxino.c:51:2: warning: implicit declaration | of function 'gpio_direction_output' | [-Wimplicit-function-declaration] ` Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- board/olimex/mx23_olinuxino/mx23_olinuxino.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 9252717..9ed7718 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -23,6 +23,7 @@ */ #include common.h +#include asm/gpio.h #include asm/io.h #include asm/arch/iomux-mx23.h #include asm/arch/imx-regs.h -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx23_olinuxino: Add missing gpio header
Add missing gpio header in order to fix the following build warning: mx23_olinuxino.c:50:2: warning: implicit declaration of function 'gpio_direction_output' [-Wimplicit-function-declaration] Reported-by: Stefano Babic sba...@denx.de Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/olimex/mx23_olinuxino/mx23_olinuxino.c |1 + 1 file changed, 1 insertion(+) diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 9252717..8cc215d 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -28,6 +28,7 @@ #include asm/arch/imx-regs.h #include asm/arch/clock.h #include asm/arch/sys_proto.h +#include asm/gpio.h #ifdef CONFIG_STATUS_LED #include status_led.h #endif -- 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 v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Wolfgang Denk, On Thursday, March 7, 2013 12:38:04 PM, Benoît Thébaudeau wrote: Dear Wolfgang Denk, On Thursday, March 7, 2013 7:57:13 AM, Wolfgang Denk wrote: Dear Benoît Thébaudeau, In message 1362596377-5827-15-git-send-email-benoit.thebaud...@advansee.com you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. I don't think so. They're indeed not supposed to be used, but there are perhaps exceptions somewhere, and it's not the purpose of this script to enforce such a rule. Also, note that lowercase letters are used in the main line filter of this script too. But if this is a strong requirement from you to remove lowercase letters here, just tell me, and I'll make the change. In that case, should the main line filter be changed too? I've just performed a quick search, and there are many exceptions: CONFIG_100MHz CONFIG_200MHz CONFIG_266MHz CONFIG_300MHz CONFIG_44x CONFIG_4x CONFIG_4xx CONFIG_4xx_CONFIG_BLOCKSIZE CONFIG_4xx_CONFIG_I2C_EEPROM_ADDR CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET CONFIG_4xx_DCACHE CONFIG_50MHz CONFIG_5xx CONFIG_5xx_CONS_SCI1 CONFIG_5xx_CONS_SCI2 CONFIG_5xx_GCLK_FREQ CONFIG_66MHz CONFIG_74x CONFIG_74xx CONFIG_74xx_7xx CONFIG_75MHz CONFIG_75x CONFIG_7xx CONFIG_80MHz CONFIG_82xx_CONS_SMC1 CONFIG_82xx_CONS_SMC2 CONFIG_8xx CONFIG_8xx_BOOTDELAY CONFIG_8xx_BUSCLOCK CONFIG_8xx_CONS_ CONFIG_8xx_CONS_NONE CONFIG_8xx_CONS_SCC1 CONFIG_8xx_CONS_SCC2 CONFIG_8xx_CONS_SCC3 CONFIG_8xx_CONS_SCC4 CONFIG_8xx_CONS_SCCx CONFIG_8xx_CONS_SMC1 CONFIG_8xx_CONS_SMC2 CONFIG_8xx_CONS_SMCx CONFIG_8xx_CPUCLK_DEFAULT CONFIG_8xx_CPUCLOCK CONFIG_8xx_GCLK_FREQ CONFIG_8xx_OSCLK CONFIG_8xx_TFTP_MODE CONFIG_ARCH_GTA02_v1 CONFIG_ARCH_GTA02_v2 CONFIG_AT32UC3A0xxx CONFIG_BAB7xx CONFIG_BF50x CONFIG_BF51x CONFIG_BF52x CONFIG_BF54x CONFIG_BF60x CONFIG_BOARD_EARLY_INIT_f CONFIG_BUSMODE_60x CONFIG_CCLK_DIV_not_defined_properly CONFIG_CF_V4e CONFIG_CLKIN_66MHz CONFIG_CM41xx CONFIG_DB_CR826_J30x_ON CONFIG_DISPLAY_AER_ CONFIG_EBC_PPC4xx_IBM_VER1 CONFIG_EB_CPUx9K2_H_ CONFIG_ETHER_ON_FCCx CONFIG_eTSEC_MDIO_BUS CONFIG_FEL8xx_AT CONFIG_galaxy5200_LOWBOOT CONFIG_IB62x0_H CONFIG_IDE_8xx_DIRECT CONFIG_IDE_8xx_PCCARD CONFIG_IP86x CONFIG_M520x CONFIG_M5301x CONFIG_M547x CONFIG_M548x CONFIG_MB86R0x CONFIG_MB86R0x_IOCLK CONFIG_MCF520x CONFIG_MCF5227x CONFIG_MCF523x CONFIG_MCF52x2 CONFIG_MCF5301x CONFIG_MCF532x CONFIG_MCF537x CONFIG_MCF5441x CONFIG_MCF5445x CONFIG_MCF547x_8x CONFIG_MPC512x_FEC CONFIG_MPC5xxx CONFIG_MPC5xxx_FEC CONFIG_MPC5xxx_FEC_MII10 CONFIG_MPC5xxx_FEC_MII100 CONFIG_MPC5xxx_FEC_SEVENWIRE CONFIG_MPC5xxx_MII10 CONFIG_MPC830x CONFIG_MPC831x CONFIG_MPC832x CONFIG_MPC834x CONFIG_MPC837x CONFIG_MPC83xx CONFIG_MPC85xx CONFIG_MPC86x CONFIG_MPC86xADS CONFIG_MPC86xx CONFIG_MPC8xxx_DISABLE_BPTR CONFIG_nand CONFIG_P3Mx CONFIG_PCI_4xx_PTM_OVERWRITE CONFIG_PDSP188x CONFIG_PHYx_ADDR CONFIG_PL01x_PORTS CONFIG_PPC4xx_DDR_AUTOCALIBRATION CONFIG_PPC4xx_DDR_METHOD_A CONFIG_PPC4xx_EMAC CONFIG_RTC_DS164x CONFIG_RTC_DS174x CONFIG_RTC_MPC8xx CONFIG_SACSng CONFIG_SDRAM_PPC4xx_DENALI_DDR2 CONFIG_SDRAM_PPC4xx_IBM_DDR CONFIG_SDRAM_PPC4xx_IBM_DDR2 CONFIG_SDRAM_PPC4xx_IBM_SDRAM CONFIG_SHARP_16x9 CONFIG_SHEEVA_88SV331xV5 CONFIG_spear300 CONFIG_spear310 CONFIG_spear320 CONFIG_SVM_SC8xx CONFIG_SYS_4xx_CHIP_21_405EX_NO_SECURITY CONFIG_SYS_4xx_CHIP_21_405EXr_NO_SECURITY CONFIG_SYS_4xx_CHIP_21_405EXr_SECURITY CONFIG_SYS_4xx_CHIP_21_405EX_SECURITY CONFIG_SYS_4xx_CHIP_21_ERRATA CONFIG_SYS_4xx_GPIO_TABLE CONFIG_SYS_4xx_RESET_TYPE CONFIG_SYS_60x_BR CONFIG_SYS_60x_OR CONFIG_SYS_8xx_CPUCLK_MAX CONFIG_SYS_8xx_CPUCLK_MIN CONFIG_SYS_BCR_60x CONFIG_SYS_BRx_PRELIM CONFIG_SYS_CMA_CSn_ CONFIG_SYS_CSn_BASE CONFIG_SYS_CSn_CTRL CONFIG_SYS_CSn_MASK CONFIG_SYS_CSx_BASE CONFIG_SYS_CSx_RO CONFIG_SYS_CSx_SIZE CONFIG_SYS_CSx_WIDTH CONFIG_SYS_CSx_WS CONFIG_SYS_DM36x_AB1CR CONFIG_SYS_DM36x_AB2CR CONFIG_SYS_DM36x_AWCCR CONFIG_SYS_DM36x_DDR2_DDRPHYCR CONFIG_SYS_DM36x_DDR2_PBBPR CONFIG_SYS_DM36x_DDR2_SDBCR CONFIG_SYS_DM36x_DDR2_SDRCR CONFIG_SYS_DM36x_DDR2_SDTIMR CONFIG_SYS_DM36x_DDR2_SDTIMR2 CONFIG_SYS_DM36x_PERI_CLK_CTRL CONFIG_SYS_DM36x_PINMUX0 CONFIG_SYS_DM36x_PINMUX1 CONFIG_SYS_DM36x_PINMUX2 CONFIG_SYS_DM36x_PINMUX3 CONFIG_SYS_DM36x_PINMUX4 CONFIG_SYS_DM36x_PLL1_PLLDIV1 CONFIG_SYS_DM36x_PLL1_PLLDIV2 CONFIG_SYS_DM36x_PLL1_PLLDIV3 CONFIG_SYS_DM36x_PLL1_PLLDIV4 CONFIG_SYS_DM36x_PLL1_PLLDIV5 CONFIG_SYS_DM36x_PLL1_PLLDIV6 CONFIG_SYS_DM36x_PLL1_PLLDIV7 CONFIG_SYS_DM36x_PLL1_PLLDIV8 CONFIG_SYS_DM36x_PLL1_PLLDIV9 CONFIG_SYS_DM36x_PLL1_PLLM CONFIG_SYS_DM36x_PLL1_PREDIV CONFIG_SYS_DM36x_PLL2_PLLDIV1 CONFIG_SYS_DM36x_PLL2_PLLDIV2 CONFIG_SYS_DM36x_PLL2_PLLDIV3 CONFIG_SYS_DM36x_PLL2_PLLDIV4 CONFIG_SYS_DM36x_PLL2_PLLDIV5 CONFIG_SYS_DM36x_PLL2_PLLM CONFIG_SYS_DM36x_PLL2_PREDIV CONFIG_SYS_FLASH_LEGACY_256Kx8 CONFIG_SYS_FLASH_LEGACY_512Kx16 CONFIG_SYS_FLASH_LEGACY_512Kx8
Re: [U-Boot] [PATCH] mx23_olinuxino: Add missing gpio header
On Thu, Mar 7, 2013 at 2:28 PM, Fabio Estevam fabio.este...@freescale.com wrote: Add missing gpio header in order to fix the following build warning: mx23_olinuxino.c:50:2: warning: implicit declaration of function 'gpio_direction_output' [-Wimplicit-function-declaration] Reported-by: Stefano Babic sba...@denx.de Signed-off-by: Fabio Estevam fabio.este...@freescale.com heh; we both did the same. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx23_olinuxino: Add missing gpio header
On 07/03/2013 18:28, Fabio Estevam wrote: Add missing gpio header in order to fix the following build warning: mx23_olinuxino.c:50:2: warning: implicit declaration of function 'gpio_direction_output' [-Wimplicit-function-declaration] Reported-by: Stefano Babic sba...@denx.de Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Add workaround for errata USB-14 (enable on P204x/P3041/P50x0)
On Mar 5, 2013, at 2:40 PM, Wolfgang Denk wrote:
Dear Xu Lei-B33228,
Please do not top post / full quote. Thanks.
In message
8cb6a38adf9e994697ff8a45e96e0853388...@039-sn1mpn1-004.039d.mgd.msft.net
you wrote:
Thank you and I agree with you. It is a little ugly but because these
registers info are not publicly, so I did not use C struct to describe them,
for this case is it ok, or other method such as define a struct but keep all
other registers and bits in this register reserved? Thank you.
I'm not throwing in a formal NAK here, but for reasons of consistency
(and because others are just too eager to quote such patches as
authoritative precedent) I'd prefer the use of a struct.
While I'd prefer a struct as well, unfortunately this isn't something FSL has
documented and we publish the erratum write ups with address like this. So
when a customer comes and looks for the code its more inline with the erratum
writeup.
I'm not sure what value a dummy struct would provide above the explicit
addressing utilized in the patch.
Again, I'm not happy about the situation, just not sure what additional value
doing something like:
struct dummy_usb_dscr {
u8 res[0x520];
u32 erratum_usb14_reg;
u8 res[4096-0x524];
};
Its going to be a bit more error prone than the method used when the struct
needs updating for a new register field and when someone screws up getting the
res[] sizes correct.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] mx23/mxs pending patches
Dear Stefano Babic, On 07/03/2013 17:23, Otavio Salvador wrote: Check u-boot-testing :: mx233 if it helps, I picked all patches that shall be applied in there. There're patches which where not send for review there (as Makefile change) Of course, such patches (I have find only what you mention) cannot be picked up at all if not reviewed here. Sorry about that, that one convenience patch slipped in. I see you managed to pick the rest of those, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: mx6: use common CPU errata config options
On 03/07/2013 10:24 AM, Stefano Babic wrote: On 26/02/2013 23:28, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Now that U-Boot has common CONFIG_ options to work around some ARM CPU errata, enable the relevant options on MX6, and remove the custom lowlevel_init.S, since it's just duplicated code now. Signed-off-by: Stephen Warren swar...@nvidia.com --- Hi Stephen, applied to u-boot-imx. It is not effective until Alber apply 1/3, but it does not hurt. If you do that, then won't the imx6-specific WAR code be removed before the generic implementation is added, so that there will be a period where the WAR won't be enabled? I suppose if you send your pull request after Albert has merged the generic implementation there won't be an issue in u-boot-arm, but until u-boot-imx picks up the latest u-boot-arm, the issue will exist there. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra30: Cardhu: Add pad config tables/code based on pinmux code
On 03/06/2013 04:51 PM, Tom Warren wrote:
Pad config registers exist in APB_MISC_GP space, and control slew
rate, drive strengh, schmidt, high-speed, and low-power modes for
all of the pingroups in Tegra30. This builds off of the pinmux
way of constructing init tables to configure select pads (SDIOCFG,
for instance) during pinmux_init().
Currently, only SDIO1CFG is changed as per the TRM to work with
the SD-card slot on Cardhu.
Thanks to StephenW for the suggestion/original idea.
As a general rule, I'd expect the pinmux driver implementation to be a
separate patch from the changes to the Cardhu board file to use the new
features, but I guess you're replacing an existing
pinmux_sdio_pad_cfg(), so that isn't possible. So it's fine.
diff --git a/board/nvidia/cardhu/pinmux-config-cardhu.h
b/board/nvidia/cardhu/pinmux-config-cardhu.h
+static struct padctrl_config cardhu_padctrl[] = {
+ /* (_padgrp, _slwf, _slwr, _drvup, _drvdn, _lpmd, _schmt, _hsm) */
+ DEFAULT_PADCFG(SDIO1, SDIOCFG_DRVUP_SLWF, SDIOCFG_DRVDN_SLWR, \
+ SDIOCFG_DRVUP, SDIOCFG_DRVDN, NONE, DISABLE, DISABLE),
+};
+#endif /* _PINMUX_CONFIG_CARDHU_H_ */
I didn't quite get why there wasn't an SDIO3 entry in that table, since
the original pinmux_sdio_pad_cfg() set up both SDIO1 and SDIO3 pin
groups, and SDIO3 appears to be used on Cardhu for SDIO-based WiFi.
Aside from that,
Reviewed-by: Stephen Warren swar...@nvidia.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra30: Cardhu: Add pad config tables/code based on pinmux code
Stephen,
On Thu, Mar 7, 2013 at 1:27 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 03/06/2013 04:51 PM, Tom Warren wrote:
Pad config registers exist in APB_MISC_GP space, and control slew
rate, drive strengh, schmidt, high-speed, and low-power modes for
all of the pingroups in Tegra30. This builds off of the pinmux
way of constructing init tables to configure select pads (SDIOCFG,
for instance) during pinmux_init().
Currently, only SDIO1CFG is changed as per the TRM to work with
the SD-card slot on Cardhu.
Thanks to StephenW for the suggestion/original idea.
As a general rule, I'd expect the pinmux driver implementation to be a
separate patch from the changes to the Cardhu board file to use the new
features, but I guess you're replacing an existing
pinmux_sdio_pad_cfg(), so that isn't possible. So it's fine.
OK. Thanks.
diff --git a/board/nvidia/cardhu/pinmux-config-cardhu.h
b/board/nvidia/cardhu/pinmux-config-cardhu.h
+static struct padctrl_config cardhu_padctrl[] = {
+ /* (_padgrp, _slwf, _slwr, _drvup, _drvdn, _lpmd, _schmt, _hsm) */
+ DEFAULT_PADCFG(SDIO1, SDIOCFG_DRVUP_SLWF, SDIOCFG_DRVDN_SLWR, \
+ SDIOCFG_DRVUP, SDIOCFG_DRVDN, NONE, DISABLE, DISABLE),
+};
+#endif /* _PINMUX_CONFIG_CARDHU_H_ */
I didn't quite get why there wasn't an SDIO3 entry in that table, since
the original pinmux_sdio_pad_cfg() set up both SDIO1 and SDIO3 pin
groups, and SDIO3 appears to be used on Cardhu for SDIO-based WiFi.
The previous code did check for SDMMC1 or SDMMC3, but on Cardhu,
SDMMC1 is called out in the dts file, and SDMMC3 isn't (you had said
earlier when reviewing some Ventana changes that leaving out a SDIO
WIFI node was ok as U-Boot wouldn't be using it, so I didn't add it to
Cardhu). So the old code would only have called the pad init code for
SDMMC1 and SDMMC4, and SDMMC4 would have been rejected since it's not
SDIO. So I only added SDIO1 to the table. I can add an entry for
SDIO3 (even if it's not in the dts file for Cardhu), since it does no
harm to set those pad cfg registers as per the TRM (I assume the TRM
is calling out cal numbers that will work with both an SD-card slot
and a WIFI device?).
Let me know if you'd like to see either the WIFI node added to the
Cardhu DT file, or the SDIO3 entry added to the cardhu_padctrl table,
or both.
Tom
Aside from that,
Reviewed-by: Stephen Warren swar...@nvidia.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra30: Cardhu: Add pad config tables/code based on pinmux code
On 03/07/2013 02:13 PM, Tom Warren wrote: Stephen, On Thu, Mar 7, 2013 at 1:27 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/06/2013 04:51 PM, Tom Warren wrote: Pad config registers exist in APB_MISC_GP space, and control slew rate, drive strengh, schmidt, high-speed, and low-power modes for all of the pingroups in Tegra30. This builds off of the pinmux way of constructing init tables to configure select pads (SDIOCFG, for instance) during pinmux_init(). Currently, only SDIO1CFG is changed as per the TRM to work with the SD-card slot on Cardhu. ... I didn't quite get why there wasn't an SDIO3 entry in that table, since the original pinmux_sdio_pad_cfg() set up both SDIO1 and SDIO3 pin groups, and SDIO3 appears to be used on Cardhu for SDIO-based WiFi. The previous code did check for SDMMC1 or SDMMC3, but on Cardhu, SDMMC1 is called out in the dts file, and SDMMC3 isn't (you had said earlier when reviewing some Ventana changes that leaving out a SDIO WIFI node was ok as U-Boot wouldn't be using it, so I didn't add it to Cardhu). So the old code would only have called the pad init code for SDMMC1 and SDMMC4, and SDMMC4 would have been rejected since it's not SDIO. So I only added SDIO1 to the table. I can add an entry for SDIO3 (even if it's not in the dts file for Cardhu), since it does no harm to set those pad cfg registers as per the TRM (I assume the TRM is calling out cal numbers that will work with both an SD-card slot and a WIFI device?). Let me know if you'd like to see either the WIFI node added to the Cardhu DT file, or the SDIO3 entry added to the cardhu_padctrl table, or both. Ah OK, now I understand. This is fine for now; we can add the extra table entries if we need them. The kernel does set them up for its own use of WiFi. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx28evk: Introduce a new target for saving env vars to NAND
Introduce 'mx28evk_nand' target for saving environment variables into NAND. The mx28evk board does not come with a NAND flash populated from the factory. It comes with an empty slot (U23), which allows the insertion of a 48-pin TSOP flash device. Tested with a K9LBG08U0D. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- boards.cfg|3 ++- doc/README.mx28evk| 18 ++ include/configs/mx28evk.h | 31 ++- 3 files changed, 50 insertions(+), 2 deletions(-) diff --git a/boards.cfg b/boards.cfg index 7a0b79d..a9a061b 100644 --- a/boards.cfg +++ b/boards.cfg @@ -195,7 +195,8 @@ mx23_olinuxino arm arm926ejs mx23_olinuxino olimex apx4devkit arm arm926ejs apx4devkit bluegiga mxsapx4devkit mx23evk arm arm926ejs mx23evk freescale mxsmx23evk m28evk arm arm926ejs m28evk denx mxsm28evk -mx28evk arm arm926ejs mx28evk freescale mxsmx28evk +mx28evk arm arm926ejs mx28evk freescale mxsmx28evk:ENV_IS_IN_MMC +mx28evk_nand arm arm926ejs mx28evk freescale mxsmx28evk:ENV_IS_IN_NAND sc_sps_1 arm arm926ejs sc_sps_1 schulercontrol mxs nhk8815 arm arm926ejs nhk8815 st nomadik nhk8815_onenand arm arm926ejs nhk8815 st nomadik nhk8815:BOOT_ONENAND diff --git a/doc/README.mx28evk b/doc/README.mx28evk index 2fc5069..d0c5ae8 100644 --- a/doc/README.mx28evk +++ b/doc/README.mx28evk @@ -23,6 +23,24 @@ To boot MX28EVK from an SD card, set the boot mode DIP switches as: * VDD 5V: To the left (off) * Hold Button: Down (off) + +Environment Storage +--- + +There are two targets for mx28evk: + +make mx28evk_config - store enviroment variables into MMC + +or + +make mx28evk_nand_config - store enviroment variables into NAND flash + +Choose the target accordingly. + +Note: The mx28evk board does not come with a NAND flash populated from the +factory. It comes with an empty slot (U23), which allows the insertion of a +48-pin TSOP flash device. + Follow the instructions from doc/README.mx28_common to generate a bootable SD card. diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 0d918a1..9cc236f 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -69,6 +69,7 @@ #define CONFIG_CMD_USB #define CONFIG_CMD_BOOTZ #define CONFIG_CMD_I2C +#define CONFIG_CMD_NAND /* * Memory configurations @@ -132,7 +133,6 @@ /* * MMC Driver */ -#define CONFIG_ENV_IS_IN_MMC #ifdef CONFIG_ENV_IS_IN_MMC #define CONFIG_ENV_OFFSET (256 * 1024) #define CONFIG_ENV_SIZE (16 * 1024) @@ -149,11 +149,40 @@ /* * NAND Driver */ +#define CONFIG_ENV_SIZE(16 * 1024) #ifdef CONFIG_CMD_NAND #define CONFIG_NAND_MXS #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_BASE 0x6000 #define CONFIG_SYS_NAND_5_ADDR_CYCLE + +/* Environment is in NAND */ +#define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE +#define CONFIG_ENV_SECT_SIZE (128 * 1024) +#define CONFIG_ENV_RANGE (512 * 1024) +#ifndef CONFIG_ENV_OFFSET +#define CONFIG_ENV_OFFSET 0x30 +#endif +#define CONFIG_ENV_OFFSET_REDUND \ + (CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE) + +#define CONFIG_CMD_UBI +#define CONFIG_CMD_UBIFS +#define CONFIG_CMD_MTDPARTS +#define CONFIG_RBTREE +#define CONFIG_LZO +#define CONFIG_MTD_DEVICE +#define CONFIG_MTD_PARTITIONS +#define MTDIDS_DEFAULT nand0=gpmi-nand +#define MTDPARTS_DEFAULT \ + mtdparts=gpmi-nand: \ + 3m(bootloader)ro, \ + 512k(environment),\ + 512k(redundant-environment), \ + 4m(kernel), \ + 128k(fdt),\ + 8m(ramdisk), \ + -(filesystem) #endif /* -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/6] Tegra30: MMC: Add DT-based MMC driver for Tegra30/Cardhu
This patchset adds SDMMC device-tree support to the Tegra30 dts files, and enables the Tegra MMC driver on Tegra30 Cardhu. I've tested this on my Cardhu-A04 and everything works fine, including card detect. All Tegra boards also build w/o error, and Seaboard MMC functionality is unchanged. Changes in v2: - Use mmc_id instead of base address in pad_init_mmc - Remove all TEGRA_SDMMCx_BASE defines, no longer used - Add/use compatible entry for Tegra30 SDMMC driver Changes in v3: - Remove GP SDIO pad cfg writes - done in pinmux/padctrl init tables Tom Warren (6): Tegra30: fdt: Add SDMMC (sdhci) nodes for T30 boards (Cardhu for now) Tegra: MMC: Added/update SDMMC registers/base addresses for T20/T30 Tegra30: MMC: Add SD bus power-rail and SDMMC pad init routines mmc: Tegra: Add SD bus power/voltage function and MMC pad init call. Tegra30: mmc: Add Tegra30 SDMMC compatible entry to fdtdec driver Tegra30: MMC: Enable DT MMC driver support for Tegra30 Cardhu boards arch/arm/dts/tegra30.dtsi | 32 ++ arch/arm/include/asm/arch-tegra/tegra_mmc.h | 35 --- board/nvidia/cardhu/cardhu.c| 51 + board/nvidia/common/board.c | 31 +- board/nvidia/dts/tegra30-cardhu.dts | 15 ++ drivers/mmc/tegra_mmc.c | 63 +++--- include/configs/cardhu.h| 20 - include/configs/tegra30-common.h|3 + include/fdtdec.h|3 +- lib/fdtdec.c|1 + 10 files changed, 237 insertions(+), 17 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/6] Tegra30: fdt: Add SDMMC (sdhci) nodes for T30 boards (Cardhu for now)
Took these values directly from the kernel dts files.
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2:
- no change
v3:
- no change
arch/arm/dts/tegra30.dtsi | 32
board/nvidia/dts/tegra30-cardhu.dts | 15 +++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index 9483e80..ccf154f 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -184,4 +184,36 @@
clocks = tegra_car 105;
status = disabled;
};
+
+ sdhci@7800 {
+ compatible = nvidia,tegra30-sdhci;
+ reg = 0x7800 0x200;
+ interrupts = 0 14 0x04;
+ clocks = tegra_car 14;
+ status = disabled;
+ };
+
+ sdhci@78000200 {
+ compatible = nvidia,tegra30-sdhci;
+ reg = 0x78000200 0x200;
+ interrupts = 0 15 0x04;
+ clocks = tegra_car 9;
+ status = disabled;
+ };
+
+ sdhci@78000400 {
+ compatible = nvidia,tegra30-sdhci;
+ reg = 0x78000400 0x200;
+ interrupts = 0 19 0x04;
+ clocks = tegra_car 69;
+ status = disabled;
+ };
+
+ sdhci@78000600 {
+ compatible = nvidia,tegra30-sdhci;
+ reg = 0x78000600 0x200;
+ interrupts = 0 31 0x04;
+ clocks = tegra_car 15;
+ status = disabled;
+ };
};
diff --git a/board/nvidia/dts/tegra30-cardhu.dts
b/board/nvidia/dts/tegra30-cardhu.dts
index 48039c9..4d22b48 100644
--- a/board/nvidia/dts/tegra30-cardhu.dts
+++ b/board/nvidia/dts/tegra30-cardhu.dts
@@ -12,6 +12,8 @@
i2c2 = /i2c@7000c400;
i2c3 = /i2c@7000c500;
i2c4 = /i2c@7000c700;
+ sdhci0 = /sdhci@78000600;
+ sdhci1 = /sdhci@7800;
};
memory {
@@ -48,4 +50,17 @@
status = okay;
spi-max-frequency = 2500;
};
+
+ sdhci@7800 {
+ status = okay;
+ cd-gpios = gpio 69 1; /* gpio PI5 */
+ wp-gpios = gpio 155 0; /* gpio PT3 */
+ power-gpios = gpio 31 0; /* gpio PD7 */
+ bus-width = 4;
+ };
+
+ sdhci@78000600 {
+ status = okay;
+ bus-width = 8;
+ };
};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/6] Tegra: MMC: Added/update SDMMC registers/base addresses for T20/T30
Removed SDMMC base addresses from tegra.h since they're no longer used.
Added additional vendor-specific SD/MMC registers and bus power defines.
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2:
- change pad_init_mmc prototype
- remove all TEGRA_SDMMCx_BASE defines
v3:
- remove GP padctrl SDIOCFG defines, done in previous padctrl patch
arch/arm/include/asm/arch-tegra/tegra_mmc.h | 35 ++
1 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
index bd18f5f..2a3f830 100644
--- a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
+++ b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
@@ -22,10 +22,7 @@
#ifndef __TEGRA_MMC_H_
#define __TEGRA_MMC_H_
-#define TEGRA_SDMMC1_BASE 0xC800
-#define TEGRA_SDMMC2_BASE 0xC8000200
-#define TEGRA_SDMMC3_BASE 0xC8000400
-#define TEGRA_SDMMC4_BASE 0xC8000600
+#include fdtdec.h
#define MAX_HOSTS 4 /* Max number of 'hosts'/controllers */
@@ -64,12 +61,30 @@ struct tegra_mmc {
unsigned char admaerr;/* offset 54h */
unsigned char res4[3];/* RESERVED, offset 55h-57h */
unsigned long admaaddr; /* offset 58h-5Fh */
- unsigned char res5[0x9c]; /* RESERVED, offset 60h-FBh */
+ unsigned char res5[0xa0]; /* RESERVED, offset 60h-FBh */
unsigned short slotintstatus; /* offset FCh */
unsigned short hcver; /* HOST Version */
- unsigned char res6[0x100];/* RESERVED, offset 100h-1FFh */
+ unsigned intvenclkctl; /* _VENDOR_CLOCK_CNTRL_0,100h */
+ unsigned intvenspictl; /* _VENDOR_SPI_CNTRL_0, 104h */
+ unsigned intvenspiintsts; /* _VENDOR_SPI_INT_STATUS_0, 108h */
+ unsigned intvenceatactl;/* _VENDOR_CEATA_CNTRL_0,10Ch */
+ unsigned intvenbootctl; /* _VENDOR_BOOT_CNTRL_0, 110h */
+ unsigned intvenbootacktout; /* _VENDOR_BOOT_ACK_TIMEOUT, 114h */
+ unsigned intvenbootdattout; /* _VENDOR_BOOT_DAT_TIMEOUT, 118h */
+ unsigned intvendebouncecnt; /* _VENDOR_DEBOUNCE_COUNT_0, 11Ch */
+ unsigned intvenmiscctl; /* _VENDOR_MISC_CNTRL_0, 120h */
+ unsigned intres6[47]; /* 0x124 ~ 0x1DC */
+ unsigned intsdmemcmppadctl; /* _SDMEMCOMPPADCTRL_0, 1E0h */
+ unsigned intautocalcfg; /* _AUTO_CAL_CONFIG_0, 1E4h */
+ unsigned intautocalintval; /* _AUTO_CAL_INTERVAL_0, 1E8h */
+ unsigned intautocalsts; /* _AUTO_CAL_STATUS_0, 1ECh */
};
+#define TEGRA_MMC_PWRCTL_SD_BUS_POWER (1 0)
+#define TEGRA_MMC_PWRCTL_SD_BUS_VOLTAGE_V1_8 (5 1)
+#define TEGRA_MMC_PWRCTL_SD_BUS_VOLTAGE_V3_0 (6 1)
+#define TEGRA_MMC_PWRCTL_SD_BUS_VOLTAGE_V3_3 (7 1)
+
#define TEGRA_MMC_HOSTCTL_DMASEL_MASK (3 3)
#define TEGRA_MMC_HOSTCTL_DMASEL_SDMA (0 3)
#define TEGRA_MMC_HOSTCTL_DMASEL_ADMA2_32BIT (2 3)
@@ -119,6 +134,12 @@ struct tegra_mmc {
#define TEGRA_MMC_NORINTSIGEN_XFER_COMPLETE(1 1)
+/* SDMMC1/3 settings from section 24.6 of T30 TRM */
+#define MEMCOMP_PADCTRL_VREF 7
+#define AUTO_CAL_ENABLED (1 29)
+#define AUTO_CAL_PD_OFFSET (0x70 8)
+#define AUTO_CAL_PU_OFFSET (0x62 0)
+
struct mmc_host {
struct tegra_mmc *reg;
int id; /* device id/number, 0-3 */
@@ -132,5 +153,7 @@ struct mmc_host {
unsigned int clock; /* Current clock (MHz) */
};
+void pad_init_mmc(struct mmc_host *host);
+
#endif /* __ASSEMBLY__ */
#endif /* __TEGRA_MMC_H_ */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/6] Tegra30: MMC: Add SD bus power-rail and SDMMC pad init routines
T30 requires specific SDMMC pad programming, and bus power-rail bringup.
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2:
- rewrite pad_init_mmc to use mmc_id instead of SDMMC base address
- add PMU-specific comments to board_sdmmc_voltage_init sequence
v3:
- removed GP_SDIOCFG writes, now done during pinmux init via table
board/nvidia/cardhu/cardhu.c | 51 ++
board/nvidia/common/board.c | 31 -
2 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/board/nvidia/cardhu/cardhu.c b/board/nvidia/cardhu/cardhu.c
index 08e9b7b..3544b41 100644
--- a/board/nvidia/cardhu/cardhu.c
+++ b/board/nvidia/cardhu/cardhu.c
@@ -25,6 +25,10 @@
#include asm/arch/pinmux.h
#include asm/arch/gp_padctrl.h
#include pinmux-config-cardhu.h
+#include i2c.h
+
+#define PMU_I2C_ADDRESS0x2D
+#define MAX_I2C_RETRY 3
/*
* Routine: pinmux_init
@@ -41,3 +45,50 @@ void pinmux_init(void)
/* Initialize any non-default pad configs (APB_MISC_GP regs) */
padgrp_config_table(cardhu_padctrl, ARRAY_SIZE(cardhu_padctrl));
}
+
+#if defined(CONFIG_TEGRA_MMC)
+/*
+ * Do I2C/PMU writes to bring up SD card bus power
+ *
+ */
+void board_sdmmc_voltage_init(void)
+{
+ uchar reg, data_buffer[1];
+ int i;
+
+ i2c_set_bus_num(0); /* PMU is on bus 0 */
+
+ /* TPS659110: LDO5_REG = 3.3v, ACTIVE to SDMMC1 */
+ data_buffer[0] = 0x65;
+ reg = 0x32;
+
+ for (i = 0; i MAX_I2C_RETRY; ++i) {
+ if (i2c_write(PMU_I2C_ADDRESS, reg, 1, data_buffer, 1))
+ udelay(100);
+ }
+
+ /* TPS659110: GPIO7_REG = PDEN, output a 1 to EN_3V3_SYS */
+ data_buffer[0] = 0x09;
+ reg = 0x67;
+
+ for (i = 0; i MAX_I2C_RETRY; ++i) {
+ if (i2c_write(PMU_I2C_ADDRESS, reg, 1, data_buffer, 1))
+ udelay(100);
+ }
+}
+
+/*
+ * Routine: pin_mux_mmc
+ * Description: setup the MMC muxes, power rails, etc.
+ */
+void pin_mux_mmc(void)
+{
+ /*
+* NOTE: We don't do mmc-specific pin muxes here.
+* They were done globally in pinmux_init().
+*/
+
+ /* Bring up the SDIO1 power rail */
+ board_sdmmc_voltage_init();
+}
+#endif /* MMC */
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index babbe08..7d9f361 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -49,6 +49,7 @@
#include asm/arch-tegra/usb.h
#endif
#ifdef CONFIG_TEGRA_MMC
+#include asm/arch-tegra/tegra_mmc.h
#include asm/arch-tegra/mmc.h
#endif
#include i2c.h
@@ -245,4 +246,32 @@ int board_mmc_init(bd_t *bd)
return 0;
}
-#endif
+
+void pad_init_mmc(struct mmc_host *host)
+{
+#if defined(CONFIG_TEGRA30)
+ enum periph_id id = host-mmc_id;
+ u32 val;
+
+ debug(%s: sdmmc address = %08x, id = %d\n, __func__,
+ (unsigned int)host-reg, id);
+
+ /* Set the pad drive strength for SDMMC1 or 3 only */
+ if (id != PERIPH_ID_SDMMC1 id != PERIPH_ID_SDMMC3) {
+ debug(%s: settings are only valid for SDMMC1/SDMMC3!\n,
+ __func__);
+ return;
+ }
+
+ val = readl(host-reg-sdmemcmppadctl);
+ val = 0xFFF0;
+ val |= MEMCOMP_PADCTRL_VREF;
+ writel(val, host-reg-sdmemcmppadctl);
+
+ val = readl(host-reg-autocalcfg);
+ val = 0x;
+ val |= AUTO_CAL_PU_OFFSET | AUTO_CAL_PD_OFFSET | AUTO_CAL_ENABLED;
+ writel(val, host-reg-autocalcfg);
+#endif /* T30 */
+}
+#endif /* MMC */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/6] Tegra30: mmc: Add Tegra30 SDMMC compatible entry to fdtdec driver
Tegra30 SD/MMC controller differs enough from Tegra20 that it
needs its own entry in the compat_names/compat_id tables and in
the Tegra MMC driver.
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2: new
v3:
- no change
include/fdtdec.h |3 ++-
lib/fdtdec.c |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 32730d2..2189483 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -71,7 +71,8 @@ enum fdt_compat_id {
COMPAT_NVIDIA_TEGRA20_NAND, /* Tegra2 NAND controller */
COMPAT_NVIDIA_TEGRA20_PWM, /* Tegra 2 PWM controller */
COMPAT_NVIDIA_TEGRA20_DC, /* Tegra 2 Display controller */
- COMPAT_NVIDIA_TEGRA20_SDMMC,/* Tegra SDMMC controller */
+ COMPAT_NVIDIA_TEGRA30_SDMMC,/* Tegra30 SDMMC controller */
+ COMPAT_NVIDIA_TEGRA20_SDMMC,/* Tegra20 SDMMC controller */
COMPAT_NVIDIA_TEGRA20_SFLASH, /* Tegra 2 SPI flash controller */
COMPAT_NVIDIA_TEGRA20_SLINK,/* Tegra 2 SPI SLINK controller */
COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 000130f..43f29f5 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -46,6 +46,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(NVIDIA_TEGRA20_NAND, nvidia,tegra20-nand),
COMPAT(NVIDIA_TEGRA20_PWM, nvidia,tegra20-pwm),
COMPAT(NVIDIA_TEGRA20_DC, nvidia,tegra20-dc),
+ COMPAT(NVIDIA_TEGRA30_SDMMC, nvidia,tegra30-sdhci),
COMPAT(NVIDIA_TEGRA20_SDMMC, nvidia,tegra20-sdhci),
COMPAT(NVIDIA_TEGRA20_SFLASH, nvidia,tegra20-sflash),
COMPAT(NVIDIA_TEGRA20_SLINK, nvidia,tegra20-slink),
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/6] mmc: Tegra: Add SD bus power/voltage function and MMC pad init call.
Tegra30 requires the SD Bus Voltage Power bits be set in the SD
Power Control register. Tegra20 works w/o them set, but do it anyway
for those SoCs as it's part of the SD spec. Also call a common
board pad init routine (pad_init_mmc) in mmc_reset(), used by
Tegra30 only for now.
Note that Tegra20 SD/MMC HW differs enough from Tegra20 that a
new compatible entry is used in the fdt compat_names/id tables.
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2:
- pass mmc 'host' struct to pad_init_mmc
- probe for Tegra30 SDMMC id in tegra_mmc_init
V3:
- no change
drivers/mmc/tegra_mmc.c | 63 +--
1 files changed, 55 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
index 6063d08..8f5f1a5 100644
--- a/drivers/mmc/tegra_mmc.c
+++ b/drivers/mmc/tegra_mmc.c
@@ -21,7 +21,6 @@
#include bouncebuf.h
#include common.h
-#include fdtdec.h
#include asm/gpio.h
#include asm/io.h
#include asm/arch/clock.h
@@ -38,6 +37,38 @@ struct mmc_host mmc_host[MAX_HOSTS];
#error Please enable device tree support to use this driver
#endif
+static void mmc_set_power(struct mmc_host *host, unsigned short power)
+{
+ u8 pwr = 0;
+ debug(%s: power = %x\n, __func__, power);
+
+ if (power != (unsigned short)-1) {
+ switch (1 power) {
+ case MMC_VDD_165_195:
+ pwr = TEGRA_MMC_PWRCTL_SD_BUS_VOLTAGE_V1_8;
+ break;
+ case MMC_VDD_29_30:
+ case MMC_VDD_30_31:
+ pwr = TEGRA_MMC_PWRCTL_SD_BUS_VOLTAGE_V3_0;
+ break;
+ case MMC_VDD_32_33:
+ case MMC_VDD_33_34:
+ pwr = TEGRA_MMC_PWRCTL_SD_BUS_VOLTAGE_V3_3;
+ break;
+ }
+ }
+ debug(%s: pwr = %X\n, __func__, pwr);
+
+ /* Set the bus voltage first (if any) */
+ writeb(pwr, host-reg-pwrcon);
+ if (pwr == 0)
+ return;
+
+ /* Now enable bus power */
+ pwr |= TEGRA_MMC_PWRCTL_SD_BUS_POWER;
+ writeb(pwr, host-reg-pwrcon);
+}
+
static void mmc_prepare_data(struct mmc_host *host, struct mmc_data *data,
struct bounce_buffer *bbstate)
{
@@ -334,8 +365,7 @@ static void mmc_change_clock(struct mmc_host *host, uint
clock)
debug( mmc_change_clock called\n);
/*
-* Change Tegra SDMMCx clock divisor here. Source is 216MHz,
-* PLLP_OUT0
+* Change Tegra SDMMCx clock divisor here. Source is PLLP_OUT0
*/
if (clock == 0)
goto out;
@@ -410,7 +440,7 @@ static void mmc_set_ios(struct mmc *mmc)
debug(mmc_set_ios: hostctl = %08X\n, ctrl);
}
-static void mmc_reset(struct mmc_host *host)
+static void mmc_reset(struct mmc_host *host, struct mmc *mmc)
{
unsigned int timeout;
debug( mmc_reset called\n);
@@ -436,6 +466,14 @@ static void mmc_reset(struct mmc_host *host)
timeout--;
udelay(1000);
}
+
+ /* Set SD bus voltage enable bus power */
+ mmc_set_power(host, fls(mmc-voltages) - 1);
+ debug(%s: power control = %02X, host control = %02X\n, __func__,
+ readb(host-reg-pwrcon), readb(host-reg-hostctl));
+
+ /* Make sure SDIO pads are set up */
+ pad_init_mmc(host);
}
static int mmc_core_init(struct mmc *mmc)
@@ -444,7 +482,7 @@ static int mmc_core_init(struct mmc *mmc)
unsigned int mask;
debug( mmc_core_init called\n);
- mmc_reset(host);
+ mmc_reset(host, mmc);
host-version = readw(host-reg-hcver);
debug(host version = %x\n, host-version);
@@ -641,12 +679,21 @@ void tegra_mmc_init(void)
const void *blob = gd-fdt_blob;
debug(%s entry\n, __func__);
+ /* See if any Tegra30 MMC controllers are present */
count = fdtdec_find_aliases_for_id(blob, sdhci,
- COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
- debug(%s: count of sdhci nodes is %d\n, __func__, count);
+ COMPAT_NVIDIA_TEGRA30_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of T30 sdhci nodes is %d\n, __func__, count);
+ if (process_nodes(blob, node_list, count)) {
+ printf(%s: Error processing T30 mmc node(s)!\n, __func__);
+ return;
+ }
+ /* Now look for any Tegra20 MMC controllers */
+ count = fdtdec_find_aliases_for_id(blob, sdhci,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of T20 sdhci nodes is %d\n, __func__, count);
if (process_nodes(blob, node_list, count)) {
- printf(%s: Error processing mmc node(s)!\n, __func__);
+ printf(%s: Error processing T20 mmc node(s)!\n, __func__);
return;
}
}
--
1.7.0.4
___
U-Boot mailing list
[U-Boot] [PATCH v3 6/6] Tegra30: MMC: Enable DT MMC driver support for Tegra30 Cardhu boards
Tested on my Cardhu-A04 tablet, eMMC and SD-Card work fine, can load a kernel off of an SD card OK, card detect works, and the env is now stored in eMMC (end of the 2nd 'boot' sector, same as Tegra20). Signed-off-by: Tom Warren twar...@nvidia.com --- v2: - no change v3: - no change include/configs/cardhu.h | 20 +++- include/configs/tegra30-common.h |3 +++ 2 files changed, 22 insertions(+), 1 deletions(-) diff --git a/include/configs/cardhu.h b/include/configs/cardhu.h index 1616b39..18c7eb8 100644 --- a/include/configs/cardhu.h +++ b/include/configs/cardhu.h @@ -47,7 +47,25 @@ #define CONFIG_SYS_I2C_SPEED 10 #define CONFIG_CMD_I2C -#define CONFIG_ENV_IS_NOWHERE +/* SD/MMC */ +#define CONFIG_MMC +#define CONFIG_GENERIC_MMC +#define CONFIG_TEGRA_MMC +#define CONFIG_CMD_MMC + +#define CONFIG_DOS_PARTITION +#define CONFIG_EFI_PARTITION +#define CONFIG_FS_EXT4 +#define CONFIG_FS_FAT +#define CONFIG_CMD_EXT2 +#define CONFIG_CMD_FAT +#define CONFIG_CMD_FS_GENERIC + +/* Environment in eMMC, at the end of 2nd boot sector */ +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_ENV_OFFSET ((512 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_SYS_MMC_ENV_DEV 0 +#define CONFIG_SYS_MMC_ENV_PART2 /* SPI */ #define CONFIG_TEGRA_SLINK diff --git a/include/configs/tegra30-common.h b/include/configs/tegra30-common.h index 04517e1..bd1dfe8 100644 --- a/include/configs/tegra30-common.h +++ b/include/configs/tegra30-common.h @@ -86,4 +86,7 @@ /* Total I2C ports on Tegra30 */ #define TEGRA_I2C_NUM_CONTROLLERS 5 +/* Misc utility code */ +#define CONFIG_BOUNCE_BUFFER + #endif /* _TEGRA30_COMMON_H_ */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
I have had to deal with this a bit so I'll give my 2c. Under the GPL2, the company only has to provide source, or make an offer to do so, to customers buying the product containing the GPL code. The flip side to this is that the teeth in the GPL come from copyright law and the only person who can force anything is the copyright holder. So that really means: 1) If you buy a product containing GPL code, but the company does not supply the code, then - in general - you cannot force the company to supply you with code. You need to get the collaboration of an infringed copyright holder to force the issue. 2) If you are the copyright holder of some GPL code, you cannot - in general - demand that the company supply you with code. You have to either buy a product or get the collaboration of someone that has bought a product. In the cases I have been involved with (as an infringed copyright holder), the lawyers bought a product on our behalf and made requests for code and then when none was forthcoming they pressed the case. It really isn't as easy as it should be... On Fri, Mar 8, 2013 at 4:28 AM, Wolfgang Denk w...@denx.de wrote: Dear Pavel, In message 20130307091729.GA24807@xo-6d-61-c0.localdomain you wrote: So did you contact the vendor and ask for the source code? And did they answer, and what exactly? Technically... he should have got source code or written offer for it with the device. So they are already breaking GPL. Of course you are correct. But there is a wide ange of possibilies; some vendors just don't know what they are supposed to do, and are appreciative for a friendly hint. Of course there are also those where you need a fully charged blaster - but in my experience these are very few. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The evolution of the human race will not be accomplished in the ten thousand years of tame animals, but in the million years of wild animals, because man is and will always be a wild animal. - Charles Galton Darwin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
Dear Charles, In message CAE21AQoqC8_sJarKmSAa2f-3=3YDPL9gK7rxL7pXUx3aa=n...@mail.gmail.com you wrote: 1) If you buy a product containing GPL code, but the company does not supply the code, then - in general - you cannot force the company to supply you with code. You need to get the collaboration of an infringed copyright holder to force the issue. Just for the record: I'm always willing to help out as such. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I don't want to be young again, I just don't want to get any older. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: fix the written length when nand_write_skip_bad failed
On 03/07/2013 09:02:27 AM, htbegin wrote: Hi, Scott On Thu, Mar 7, 2013 at 2:22 AM, Scott Wood scottw...@freescale.com wrote: On 03/06/2013 08:56:56 AM, htbegin wrote: BTW, are you actually using WITH_YAFFS_OOB? I think there are some other things wrong with it at the moment, as mentioned here: http://lists.denx.de/pipermail/u-boot/2013-March/148378.html No, I don't use it. Changes to that code should be tested by someone... Sorry, I can't help. It's moot because I don't think this change should be made, but this is a case where you could enable it temporarily in your board config for some basic testing. I just use *length -= left_to_write - written_size to tell the upper level that what had been actually happened. For the current block, written_size has been written to the NAND Flash yet, so left_to_write should be subtracted by written_size. But left_to_write isn't decreased until after this error return, so that's already the case. Subtracting written_size from left_to_write has the effect of increasing length by written_size, so the return value will now look like the error page has been written. -Scott No, the returned value doesn't include the length of the error page. In no-WITH_YAFFS_OOB case, when nand_write failed, truncated_write_size has been updated by nand_write to the length which has been successfully written , so it's OK to subtract written_size from left_to_write. OK, but that doesn't explain why the change is needed. You said you wanted to find the block with the error. We only write one block at a time in the loop. Why do you need the specific page within the block that failed? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/2] usb: ehci: exynos: Fixes for non-fdt systems
Dear Vivek Gautam, Based on 'master' branch of u-boot-samsung. Changes from v3: - Adding necesasry check for return error of exynos_usb_parse_dt() and returning accordingly from ehci_hcd_init(). - Removing unnecessary parentheses around ctx-hcd. Vivek Gautam (2): usb: ehci: exynos: Fix multiple FDT decode usb: ehci: exynos: Enable non-dt path drivers/usb/host/ehci-exynos.c | 51 ++-- 1 files changed, 23 insertions(+), 28 deletions(-) applied both, please check u-boot-usb.git if all your patches are in place. If not, let me know ASAP. 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] dfu:mmc: When doing block operations, operate on the given length
I was just bitten in this area today but in a different way.
Larger than DDR? Any update larger than the default 4MB dfu_buf[] fails too.
(As a hack I redefined dfu_buf[] to be a cast of I think
CONFIG_SYS_SDRAM_BASE.) But I'd love to hear more about being able to handle
updates larger than DDR.
But on the code below, (both before and after the patch) the amount written is
the size of the mmc partition. Why write more data than was received from the
host? Why isn't the incoming len value used?
Lastly, I encountered a zero dfu-data.mmc.lba_blk_size. This gets initialized
in the mmc_init() path from the card meta data. But if you just do dfu mmc 0
right after booting that won't have been done. The MMC controller is ready but
the card structures have not been read.
I have a hack there to do do the a mmc 0 rescan command subordinate to the
dfu command but that feels gross. There has to be a better way.
Thoughts? Have you not seen dfu-data.mmc.lba_blk_size be zero?
-Mike
On Mar 7, 2013, at 9:25 AM, Tom Rini tr...@ti.com wrote:
When working on RAW partitions, it's possible that the whole area
is larger than DDR. So what we need to do is make sure that the length
we are given is aligned with the LBA block size, then pass that length
in as our count of LBA blocks to operate on. In doing this, we no
longer need to modify *len on read operations.
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Tom Rini tr...@ti.com
---
drivers/dfu/dfu_mmc.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 083d745..0bed405 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -34,14 +34,21 @@ static int mmc_block_op(enum dfu_mmc_op op, struct
dfu_entity *dfu,
{
char cmd_buf[DFU_CMD_BUF_SIZE];
- sprintf(cmd_buf, mmc %s 0x%x %x %x,
- op == DFU_OP_READ ? read : write,
- (unsigned int) buf,
- dfu-data.mmc.lba_start,
- dfu-data.mmc.lba_size);
+ /*
+ * We must ensure that we read in lba_blk_size chunks, so ALIGN
+ * this value.
+ */
+ *len = ALIGN(*len, dfu-data.mmc.lba_blk_size);
+
+ if (*len (dfu-data.mmc.lba_size * dfu-data.mmc.lba_blk_size)) {
+ puts(Request would exceed designated area!\n);
+ return -EINVAL;
+ }
- if (op == DFU_OP_READ)
- *len = dfu-data.mmc.lba_blk_size * dfu-data.mmc.lba_size;
+ sprintf(cmd_buf, mmc %s 0x%x %x %lx,
+ op == DFU_OP_READ ? read : write,
+ (unsigned int) buf, dfu-data.mmc.lba_start,
+ *len / dfu-data.mmc.lba_blk_size);
debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
return run_command(cmd_buf, 0);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
On Fri, Mar 8, 2013 at 11:23 AM, Wolfgang Denk w...@denx.de wrote: Dear Charles, In message CAE21AQoqC8_sJarKmSAa2f-3=3YDPL9gK7rxL7pXUx3aa=n...@mail.gmail.com you wrote: 1) If you buy a product containing GPL code, but the company does not supply the code, then - in general - you cannot force the company to supply you with code. You need to get the collaboration of an infringed copyright holder to force the issue. Just for the record: I'm always willing to help out as such. One of the problems with pursuing these actions is that it can be somewhat hard to prove that you have contributed materially to claim copyright over some code. There are some places where this is clear (eg. much of Wolfgang's u-boot work) or in my case Yaffs (where I have written all the core yaffs code). In much of open source though, there have been many major contributors and even more minor contributors and it can be hard to claim to be a legitimate copyright holder. In theory, I guess you could claim copyright on a three line patch, but the harsh reality of lawyer land would probably want to see something far more substantial. #disclaimer I'm not a lawyer -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2013 06:19 PM, Michael Cashwell wrote: I was just bitten in this area today but in a different way. Larger than DDR? Any update larger than the default 4MB dfu_buf[] fails too. (As a hack I redefined dfu_buf[] to be a cast of I think CONFIG_SYS_SDRAM_BASE.) But I'd love to hear more about being able to handle updates larger than DDR. Yes, as another problem, we can only write in chunks of DFU_DATA_BUF_SIZE. And for files, since we like the infrastructure to seek in existing files, filesystem writes need to be whole, and raw writes can be chunks. I've taken a patch from Pantelis Antoniou that solved half of this problem and made it buffer filesystem writes and chunk raw writes. It seems to be working even but I just finished it and need to test it in a few more places before posting. But on the code below, (both before and after the patch) the amount written is the size of the mmc partition. Why write more data than was received from the host? Why isn't the incoming len value used? Er, that's not right. It was before but *len is the length we've been given. We must make it lba_blk_size aligned, but that's typically small (512 bytes), not the whole partition like it was before :) Lastly, I encountered a zero dfu-data.mmc.lba_blk_size. This gets initialized in the mmc_init() path from the card meta data. But if you just do dfu mmc 0 right after booting that won't have been done. The MMC controller is ready but the card structures have not been read. What platform are you looking on? I'll go and re-produce this on mine tomorrow, but I'd have sworn I had done dfu mmc 0 prior to any mmc rescan/etc. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJROSO1AAoJENk4IS6UOR1Wg5EP/RBY4QFlNrj47S2KLtQFA1sl 5EEN25yC0LGFPwZ118GwXLinRzgE89ALbMeXq3dPdljlyIFLD4LFjM/7mmpB80sI GR5xcml89cFnDq4+7lhrFeqNW3jqg68soQSvVjaxdYe9sPvkDLzuNwQ77WeJFtal 7fdNOvl1ZrSHoeDQuCjqFYHuDRz+4oso5fKZcDPdhKL4mrqWhmRfrZ7RJX2iKsuC aySnkIfh/I4dtANLvQTZta3Nqidrb4PX8kE11XNrKcTKu4yLxq/Q+sHOWlXMbqfy oW3O0zxQD3cVedPO8T2G14gQwonG61R+XCyBlrxJqtL+ZPlzKZxJWNxiP1Sa5HUM Axz0vDjwfB84jsK+dzJspR0UTZHZdraoWnCYOnXF2bGxxCrCAPUSbS0A1BCpZfuT A5ayIPUQRnLgITrBip+DsYn5sHAXxRFeE6OHP3mR2PFW87ioT9iK1xFU8jVchybU 73bckJZorarUBEhSDBgaC1DScS5gF/8nPqfFiRZX/ur70opq946hMWNZNzN5kOYs haU1r88k98jm6ktW2uFvQVxzI5LiXdrPpbCYCf1vF8+VLmTGLAezLTk4Oce+8Q4t /A+wPKu6Xm03O87uW10kqmitAhkmbm9deFRt78oBA3ChqqR0EopuYH6FQhyboyvH ZMjtUebCZUAJRlgb0L4F =WWas -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length
On Mar 7, 2013, at 6:33 PM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2013 06:19 PM, Michael Cashwell wrote: I was just bitten in this area today but in a different way. Larger than DDR? Any update larger than the default 4MB dfu_buf[] fails too. (As a hack I redefined dfu_buf[] to be a cast of I think CONFIG_SYS_SDRAM_BASE.) But I'd love to hear more about being able to handle updates larger than DDR. Yes, as another problem, we can only write in chunks of DFU_DATA_BUF_SIZE. I guess what I'm not seeing is how it can chunk at all. Without being able to seek how (with dfu-util driving things) can it not just overwrite the start of the partition over and over? I suspect I'm missing a bunch of patches. I'm just on denx mainline. The only place DFU_DATA_BUF_SIZE is used is in the definition of dfu_buf[]. I just put it at the base of SDRAM. (I've moved u-boot to the high end for other reasons so that would work for me.) But on the code below, (both before and after the patch) the amount written is the size of the mmc partition. Why write more data than was received from the host? Why isn't the incoming len value used? Er, that's not right. It was before but *len is the length we've been given. We must make it lba_blk_size aligned, but that's typically small (512 bytes), not the whole partition like it was before :) Whoops! I hadn't looked at your patch closely enough. I was still recovering from the shock of what the code did originally! I went with a (*len + dfu-data.mmc.lba_blk_size - 1) / dfu-data.mmc.lba_blk_size approach rather than ALIGN but the result is the same. I found the dfu-data.mmc.lba_blk_size being zero because the division threw a signal #8. Lastly, I encountered a zero dfu-data.mmc.lba_blk_size. This gets initialized in the mmc_init() path from the card meta data. But if you just do dfu mmc 0 right after booting that won't have been done. The MMC controller is ready but the card structures have not been read. What platform are you looking on? I'll go and re-produce this on mine tomorrow, but I'd have sworn I had done dfu mmc 0 prior to any mmc rescan/etc. Pandaboard ES1.1 (which is OMAP4460 with 1GB SDRAM) with a vastly different config.h. :-) Please do let me know. If you can do dfu mmc 0 as the first command and it works I'd love to know why your card geometry is being read but mine isn't. (Hmmm... My environment is nowhere. Is your's (or something else) being read from the MMC card? That would do it. But dfu shouldn't rely on that.) Thanks for the info and assistance! -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] Tegra30: MMC: Enable DT MMC driver support for Tegra30 Cardhu boards
On 03/07/2013 02:47 PM, Tom Warren wrote: Tested on my Cardhu-A04 tablet, eMMC and SD-Card work fine, can load a kernel off of an SD card OK, card detect works, and the env is now stored in eMMC (end of the 2nd 'boot' sector, same as Tegra20). The series, Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
On Wed, 6 Mar 2013 18:08:21 -0800
Simon Glass s...@chromium.org wrote:
On Wed, Mar 6, 2013 at 5:22 PM, Kim Phillips kim.phill...@freescale.com
wrote:
On Tue, 5 Mar 2013 22:22:09 -0800
Simon Glass s...@chromium.org wrote:
On Tue, Mar 5, 2013 at 9:04 PM, Kim Phillips kim.phill...@freescale.com
wrote:
On Tue, 5 Mar 2013 17:51:00 -0800
Simon Glass s...@chromium.org wrote:
Changes sice v3:
- Changed command names to lower case in algo struct.
- Added generic ace_sha config.
I wouldn't call ace a generic name - crypto units other than
ACE should be able to use this code.
I don't really understand this comment. A new CONFIG has been added,
and this is specific to that unit. Are you suggesting that it be
right, and that's the problem - it needn't be specific to that unit.
Really? I think here we have a patch for an ACE unit, and currently
the only implementation is in an Exynos chip. It can easily be
so make the ace_sha.o build depend on whichever level of chip config
applies - CONFIG_S5P, CONFIG_EXYNOS5, or CONFIG_SMDK5250. No need
for a new define specifically for ACE, right?
No, the ACE may appear in multiple chips, and anyway we may want to
enable it or disable it. Drivers tend to have their own configs since
some boards want to use (for example) USB, crypto, mmc, and some
don't.
ok, if you really need the ACE define, restrict it to platform code
and the driver, but not common code.
extended later when someone else has one.
maybe, but we can try to avoid people copying existing code patterns,
i.e. polluting common code when adding crypto routines for their h/w
which are basically the same function declarations but with different
names.
Are you referring to adding code in into the hash algorithm table in
hash.c? I specifically designed it so that people could add their
yes.
algorithms in there. Once we have device model in place then I'm sure
we can do better, but for now that's the U-Boot way.
the problem is there are only two algorithms for all - the
accelerated, and the non-. Presumably we get the acceleration for
free, so we always will prefer to use the accelerated version, and
if it doesn't work, then the core s/w implementation. The
common/hash.c infrastructure currently doesn't support that: it
assumes the existence of multiple heterogeneous crypto units will
exist on a single u-boot instance, each used depending on its
priority, which is not the case.
The primary objective here is to not add h/w vendor dependencies in
common areas when they can easily be avoided.
Please can you point specifically to the lines of code you are wanting
changed?
common/hash.c and include/ace_sha.h should have all occurrences of
'ace' and 'ACE' replaced with something like 'hw' or
'accel'...including the ace_sha.h filename itself.
Since it's probably common enough, the 0-length handler could move
into the common code, and be enabled iff the hw-accelerated config is
set.
Also, can we try to leave the existing void return type for the hash
functions for the rest of u-boot. What do you think about changing
common/hash.c to do the s/w fallback if h/w failed instead of in the
driver(s)?
Something like CONFIG_HW_SHA{1,256} ought to do it.
But I don't think crypto units other than ACE will use the code in
this patch - it is intended to implement ACE support, and put it ahead
of software support in terms of priority.
the same priority that any h/w accelerated device would get - higher
than that of software crypto.
Another question for Akshay wrt the timeout (since I never got a
reply re: documentation): how can the h/w fault?
[...]
Regards,
Simon
Kim
you're doing it again :)
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
Hi Kim, On Thu, Mar 7, 2013 at 4:25 PM, Kim Phillips kim.phill...@freescale.com wrote: On Wed, 6 Mar 2013 18:08:21 -0800 Simon Glass s...@chromium.org wrote: On Wed, Mar 6, 2013 at 5:22 PM, Kim Phillips kim.phill...@freescale.com wrote: On Tue, 5 Mar 2013 22:22:09 -0800 Simon Glass s...@chromium.org wrote: On Tue, Mar 5, 2013 at 9:04 PM, Kim Phillips kim.phill...@freescale.com wrote: On Tue, 5 Mar 2013 17:51:00 -0800 Simon Glass s...@chromium.org wrote: Changes sice v3: - Changed command names to lower case in algo struct. - Added generic ace_sha config. I wouldn't call ace a generic name - crypto units other than ACE should be able to use this code. I don't really understand this comment. A new CONFIG has been added, and this is specific to that unit. Are you suggesting that it be right, and that's the problem - it needn't be specific to that unit. Really? I think here we have a patch for an ACE unit, and currently the only implementation is in an Exynos chip. It can easily be so make the ace_sha.o build depend on whichever level of chip config applies - CONFIG_S5P, CONFIG_EXYNOS5, or CONFIG_SMDK5250. No need for a new define specifically for ACE, right? No, the ACE may appear in multiple chips, and anyway we may want to enable it or disable it. Drivers tend to have their own configs since some boards want to use (for example) USB, crypto, mmc, and some don't. ok, if you really need the ACE define, restrict it to platform code and the driver, but not common code. That is in the design of the hash.c module. It is intended to permit insertion of different algorithm implementations. We could perhaps introduce a hash_register() function to deal with this, but that's the way it is at present. extended later when someone else has one. maybe, but we can try to avoid people copying existing code patterns, i.e. polluting common code when adding crypto routines for their h/w which are basically the same function declarations but with different names. Are you referring to adding code in into the hash algorithm table in hash.c? I specifically designed it so that people could add their yes. algorithms in there. Once we have device model in place then I'm sure we can do better, but for now that's the U-Boot way. the problem is there are only two algorithms for all - the accelerated, and the non-. Presumably we get the acceleration for free, so we always will prefer to use the accelerated version, and if it doesn't work, then the core s/w implementation. The common/hash.c infrastructure currently doesn't support that: it assumes the existence of multiple heterogeneous crypto units will exist on a single u-boot instance, each used depending on its priority, which is not the case. Fair enough, and that might be a good idea, but that is an issue for the hash infrastructure. It would be good to get a second hardware accelerator upstream so we can judge where to take this. If you have one in a Freescale SOC can I please request that you send some patches upstream and we can then evaluate how best to arrange the code. The primary objective here is to not add h/w vendor dependencies in common areas when they can easily be avoided. Please can you point specifically to the lines of code you are wanting changed? common/hash.c and include/ace_sha.h should have all occurrences of 'ace' and 'ACE' replaced with something like 'hw' or 'accel'...including the ace_sha.h filename itself. Since it's probably common enough, the 0-length handler could move into the common code, and be enabled iff the hw-accelerated config is set. To be honest I think we are getting ahead of ourselves. We are dealing here with a patch to enable hardware acceleration in one SOC, with a few lines of changes to common code, changing it in a way that fits nicely with how hash.c was designed. Also, can we try to leave the existing void return type for the hash functions for the rest of u-boot. What do you think about changing common/hash.c to do the s/w fallback if h/w failed instead of in the driver(s)? Yes I was thinking about that - probably something for a follow-on patch though. I have just finished getting crc32 in, so will add it to the queue to think about. Patches welcome. Regards, Simon [...] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] USB: ohci-at91: support sama5d3x devices
On 3/7/2013 17:12, Andreas Bießmann wrote: Dear Bo Shen, On 28.02.13 08:00, Bo Shen wrote: Add OHCI support for sama5d3x devices Signed-off-by: Bo Shen voice.s...@atmel.com --- drivers/usb/host/ohci-at91.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index efd711d..35a282e 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -42,7 +42,7 @@ int usb_cpu_init(void) while ((readl(pmc-sr) AT91_PMC_LOCKB) != AT91_PMC_LOCKB) ; #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9X5) || defined(CONFIG_SAMA5D3) I think these ifdeffery increases alarmingly here and there. Can we find a better solution like #if defined(ATMEL_OHCI_NEEDS_UPLL) or whatever we can call it. I mean to classify this and enable it in the respective SoC headers. Maybe here we can distinguish upon the IP version? /* Enable UPLL */ writel(readl(pmc-uckr) | AT91_PMC_UPLLEN | AT91_PMC_BIASEN, pmc-uckr); @@ -54,7 +54,12 @@ int usb_cpu_init(void) #endif /* Enable USB host clock. */ +#if defined(CONFIG_SAMA5D3) I think this ifdef is Ok instead. + writel(1 (ATMEL_ID_UHP - 32), pmc-pcer1); +#else writel(1 ATMEL_ID_UHP, pmc-pcer); +#endif + #ifdef CONFIG_AT91SAM9261 writel(ATMEL_PMC_UHP | AT91_PMC_HCK0, pmc-scer); #else @@ -69,7 +74,12 @@ int usb_cpu_stop(void) at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC; /* Disable USB host clock. */ +#if defined(CONFIG_SAMA5D3) + writel(1 (ATMEL_ID_UHP - 32), pmc-pcdr1); +#else writel(1 ATMEL_ID_UHP, pmc-pcdr); +#endif + #ifdef CONFIG_AT91SAM9261 writel(ATMEL_PMC_UHP | AT91_PMC_HCK0, pmc-scdr); #else @@ -83,7 +93,7 @@ int usb_cpu_stop(void) while ((readl(pmc-sr) AT91_PMC_LOCKB) != 0) ; #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \ - defined(CONFIG_AT91SAM9X5) + defined(CONFIG_AT91SAM9X5) || defined(CONFIG_SAMA5D3) /* Disable UPLL */ writel(readl(pmc-uckr) (~AT91_PMC_UPLLEN), pmc-uckr); while ((readl(pmc-sr) AT91_PMC_LOCKU) == AT91_PMC_LOCKU) I think the ifdef comment above is no show stopper for this patch but should be considered at least for a future patch. OK. I will consider this for a future patch, not in this one. Best Regards, Bo Shen The rest looks sane to me. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
On Thu, 7 Mar 2013 17:05:15 -0800 Simon Glass s...@chromium.org wrote: On Thu, Mar 7, 2013 at 4:25 PM, Kim Phillips kim.phill...@freescale.com wrote: On Wed, 6 Mar 2013 18:08:21 -0800 Simon Glass s...@chromium.org wrote: On Wed, Mar 6, 2013 at 5:22 PM, Kim Phillips kim.phill...@freescale.com wrote: On Tue, 5 Mar 2013 22:22:09 -0800 Simon Glass s...@chromium.org wrote: On Tue, Mar 5, 2013 at 9:04 PM, Kim Phillips kim.phill...@freescale.com wrote: On Tue, 5 Mar 2013 17:51:00 -0800 Simon Glass s...@chromium.org wrote: Changes sice v3: - Changed command names to lower case in algo struct. - Added generic ace_sha config. I wouldn't call ace a generic name - crypto units other than ACE should be able to use this code. I don't really understand this comment. A new CONFIG has been added, and this is specific to that unit. Are you suggesting that it be right, and that's the problem - it needn't be specific to that unit. Really? I think here we have a patch for an ACE unit, and currently the only implementation is in an Exynos chip. It can easily be so make the ace_sha.o build depend on whichever level of chip config applies - CONFIG_S5P, CONFIG_EXYNOS5, or CONFIG_SMDK5250. No need for a new define specifically for ACE, right? No, the ACE may appear in multiple chips, and anyway we may want to enable it or disable it. Drivers tend to have their own configs since some boards want to use (for example) USB, crypto, mmc, and some don't. ok, if you really need the ACE define, restrict it to platform code and the driver, but not common code. That is in the design of the hash.c module. It is intended to permit insertion of different algorithm implementations. We could perhaps introduce a hash_register() function to deal with this, but that's the way it is at present. ok, well this is the first time a new alternate algorithm implementation is being posted, and it's bringing up a flaw in the design - no vendor-specific stuff in common areas. the problem is there are only two algorithms for all - the accelerated, and the non-. Presumably we get the acceleration for free, so we always will prefer to use the accelerated version, and if it doesn't work, then the core s/w implementation. The common/hash.c infrastructure currently doesn't support that: it assumes the existence of multiple heterogeneous crypto units will exist on a single u-boot instance, each used depending on its priority, which is not the case. Fair enough, and that might be a good idea, but that is an issue for the hash infrastructure. It would be good to get a second hardware accelerator upstream so we can judge where to take this. well right now as it stands the 2nd h/w accelerator would have to duplicate hash entry point function signatures, just changing the ACE in the name to that of its h/w, and then spin on a tough decision: what priority does my h/w have vs. Samsung's ACE?? If you have one in a Freescale SOC can I please request that you send some patches upstream and we can then evaluate how best to arrange the code. they'll come, eventually I hope. Other than the driver internals, the only thing different from the ACE functional capacity provided in this patchseries for the analogous Freescale parts is that the hash infrastructure would need to be adapted for runtime detection of the crypto unit's existence. But let's not use this as an excuse to let things slide, please. this is new infrastructure, right? It's common to make mistakes without seeing the entire picture, and this patchset represents the next piece. The primary objective here is to not add h/w vendor dependencies in common areas when they can easily be avoided. Please can you point specifically to the lines of code you are wanting changed? common/hash.c and include/ace_sha.h should have all occurrences of 'ace' and 'ACE' replaced with something like 'hw' or 'accel'...including the ace_sha.h filename itself. Since it's probably common enough, the 0-length handler could move into the common code, and be enabled iff the hw-accelerated config is set. To be honest I think we are getting ahead of ourselves. We are dealing here with a patch to enable hardware acceleration in one SOC, with a few lines of changes to common code, changing it in a way that fits nicely with how hash.c was designed. sorry, I disagree: This is a brand new driver class that's being added, and the design enforces adding h/w vendor specific symbols in common code. This tells me the design is broken. Net doesn't do this - why should crypto get away with it? Plus, as I explain above, it's not that hard to fix (well, for now at least): just change the common ace parts to have a generic name. Kim ___ U-Boot mailing list U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 4/5 v4] gen: Add ACE acceleration to hash
Hi Kim, On Thu, Mar 7, 2013 at 6:18 PM, Kim Phillips kim.phill...@freescale.com wrote: On Thu, 7 Mar 2013 17:05:15 -0800 Simon Glass s...@chromium.org wrote: On Thu, Mar 7, 2013 at 4:25 PM, Kim Phillips kim.phill...@freescale.com wrote: On Wed, 6 Mar 2013 18:08:21 -0800 Simon Glass s...@chromium.org wrote: On Wed, Mar 6, 2013 at 5:22 PM, Kim Phillips kim.phill...@freescale.com wrote: On Tue, 5 Mar 2013 22:22:09 -0800 Simon Glass s...@chromium.org wrote: On Tue, Mar 5, 2013 at 9:04 PM, Kim Phillips kim.phill...@freescale.com wrote: On Tue, 5 Mar 2013 17:51:00 -0800 Simon Glass s...@chromium.org wrote: Changes sice v3: - Changed command names to lower case in algo struct. - Added generic ace_sha config. I wouldn't call ace a generic name - crypto units other than ACE should be able to use this code. I don't really understand this comment. A new CONFIG has been added, and this is specific to that unit. Are you suggesting that it be right, and that's the problem - it needn't be specific to that unit. Really? I think here we have a patch for an ACE unit, and currently the only implementation is in an Exynos chip. It can easily be so make the ace_sha.o build depend on whichever level of chip config applies - CONFIG_S5P, CONFIG_EXYNOS5, or CONFIG_SMDK5250. No need for a new define specifically for ACE, right? No, the ACE may appear in multiple chips, and anyway we may want to enable it or disable it. Drivers tend to have their own configs since some boards want to use (for example) USB, crypto, mmc, and some don't. ok, if you really need the ACE define, restrict it to platform code and the driver, but not common code. That is in the design of the hash.c module. It is intended to permit insertion of different algorithm implementations. We could perhaps introduce a hash_register() function to deal with this, but that's the way it is at present. ok, well this is the first time a new alternate algorithm implementation is being posted, and it's bringing up a flaw in the design - no vendor-specific stuff in common areas. OK so let's look at adding the hash_register() idea. But not in this series. That should come later in a revision of the hash.c infrastructure, since it needs to adjust sha1, sha255 and crc32. the problem is there are only two algorithms for all - the accelerated, and the non-. Presumably we get the acceleration for free, so we always will prefer to use the accelerated version, and if it doesn't work, then the core s/w implementation. The common/hash.c infrastructure currently doesn't support that: it assumes the existence of multiple heterogeneous crypto units will exist on a single u-boot instance, each used depending on its priority, which is not the case. Fair enough, and that might be a good idea, but that is an issue for the hash infrastructure. It would be good to get a second hardware accelerator upstream so we can judge where to take this. well right now as it stands the 2nd h/w accelerator would have to duplicate hash entry point function signatures, just changing the ACE in the name to that of its h/w, and then spin on a tough decision: what priority does my h/w have vs. Samsung's ACE?? I thought you said that only one h/w accelerator would be used on a board? If you have one in a Freescale SOC can I please request that you send some patches upstream and we can then evaluate how best to arrange the code. they'll come, eventually I hope. Other than the driver internals, the only thing different from the ACE functional capacity provided in this patchseries for the analogous Freescale parts is that the hash infrastructure would need to be adapted for runtime detection of the crypto unit's existence. But let's not use this as an excuse to let things slide, please. this is new infrastructure, right? It's common to make mistakes without seeing the entire picture, and this patchset represents the next piece. I would prefer to invent new infrastructure when we have two users, not one, otherwise we run the risk of over-engineering. I already hit a code size snag with crc32 integration. This is just the first user and there is not yet a clear picture of what other users will want. If you are saying that Freescale will need things to be done a particular way, please post the patches and we can take a look at something that fits both SOCs. The primary objective here is to not add h/w vendor dependencies in common areas when they can easily be avoided. Please can you point specifically to the lines of code you are wanting changed? common/hash.c and include/ace_sha.h should have all occurrences of 'ace' and 'ACE' replaced with something like 'hw' or 'accel'...including the ace_sha.h filename itself. Since it's probably common enough, the 0-length handler could move into the
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Wolfgang Denk, Dear Benoît Thébaudeau, In message 1362596377-5827-15-git-send-email-benoit.thebaud...@advansee.com you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) 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 2/2 v2] Exynos5: spl: Reduce clock init in spl
+ Albert, Tom who might know about this Hi Akshay, On Wed, Mar 6, 2013 at 7:36 AM, Akshay Saraswat aksha...@samsung.com wrote: Hi Simon, Hi Akshay, On Tue, Mar 5, 2013 at 2:53 AM, Akshay Saraswat aksha...@samsung.com wrote: This patch subtracts a part of clock init from spl and executes it after relocation. spl_clock_init executes in spl and system_clock_init executes after relocation in u-boot. This is done to gain some space by removing initially not necessary code. Signed-off-by: Akshay Saraswat aksha...@samsung.com --- Looks good - just one question below. Changes since v1: - Rebased on ToT. board/samsung/smdk5250/Makefile | 3 +- board/samsung/smdk5250/clock_init.c | 429 + board/samsung/smdk5250/clock_init.h | 2 + board/samsung/smdk5250/lowlevel_init.S | 4 +- board/samsung/smdk5250/setup.h | 1 + board/samsung/smdk5250/smdk5250.c | 4 + board/samsung/smdk5250/spl_clock_init.c | 469 7 files changed, 482 insertions(+), 430 deletions(-) create mode 100644 board/samsung/smdk5250/spl_clock_init.c diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile index 47c6a5a..3ceb7e2 100644 --- a/board/samsung/smdk5250/Makefile +++ b/board/samsung/smdk5250/Makefile @@ -26,12 +26,13 @@ LIB = $(obj)lib$(BOARD).o SOBJS := lowlevel_init.o -COBJS := clock_init.o +COBJS := spl_clock_init.o Shouldn't this only be included in the SPL build? I tried to do that but, since other files are using some of the data defined in this file, we need it in u-boot as well. Please tell me if it's required I'll make another file for common data. Are you saying that U-Boot proper is using the same data as SPL? I'm not sure, but I believe that we should not access SPL data from U-Boot, since they should be setting up separate things. Can you please be more specific about what is being shared? COBJS += dmc_common.o dmc_init_ddr3.o COBJS += tzpc_init.o COBJS += smdk5250_spl.o ifndef CONFIG_SPL_BUILD +COBJS += clock_init.o COBJS += smdk5250.o endif ... Regards, Simon Thanks Regards, Akshay Saraswat Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v3] Exynos5: spl: Reorganize mem_timing struct to gain space in spl
Hi Akshay, On Wed, Mar 6, 2013 at 6:22 AM, Akshay Saraswat aksha...@samsung.com wrote: Distributes struct mem_timings into new different structures to gain space in spl by removing necessity of maintaining two big and almost similar mem_timings instances. Signed-off-by: Akshay Saraswat aksha...@samsung.com --- Changes since v1: - None. Changes since v2: - Replaced non_spl_clock_div with clock_div. - Replaced ns_clk_div with clk_div. - Added few new comments. - Modified few comments. board/samsung/smdk5250/clock_init.c| 177 - board/samsung/smdk5250/clock_init.h| 74 ++ board/samsung/smdk5250/dmc_common.c| 40 board/samsung/smdk5250/dmc_init_ddr3.c | 116 +++-- board/samsung/smdk5250/setup.h | 15 ++- 5 files changed, 211 insertions(+), 211 deletions(-) Is it possible to move the non-spl code into a separate file? I think it would be better if SPL includes one clock_init (memory, boot peripheral) and U-Boot includes the other, and that there is nothing in common. Would that work? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Exynos5: Pinmux: Add fdt for pinmux
Hi Akshay,
On Thu, Mar 7, 2013 at 6:09 AM, Akshay Saraswat aksha...@samsung.com wrote:
This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.
Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO numbering feature
URL: http://lists.denx.de/pipermail/u-boot/2013-February/146151.html
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Device tree bindings changed to linux style.
- Added documentation for samsung pinctrl.
Changes since v2:
- Rebased as per new version of GPIO numbering patch-set.
Changes since v3:
- Added comments to reduce ambiguity and increase readability.
- Fixed few other nits.
Changes since v4:
- Added support for reading peripheral pinctrl subnode names from
preipheral's node instead of hard coding.
Well I have to say this is looking really nice. From what I can tell
you are using the Linux binding for samsung,pinctrl-names - please can
you add in that binding information to your binding file - I can't see
it there?
The interesting thing is that you should at some point (further patch)
be able to remove the alias stuff and have the driver's pass their
node offset into this function. Then we can drop the peripheral IDs
altogether perhaps?
arch/arm/cpu/armv7/exynos/pinmux.c | 357 +++---
arch/arm/dts/exynos5250-pinctrl.dtsi | 675
+++
arch/arm/dts/exynos5250.dtsi | 92
board/samsung/dts/exynos5250-smdk5250.dts| 11 +
doc/device-tree-bindings/samsung-pinctrl.txt | 253 ++
include/fdtdec.h | 4 +
lib/fdtdec.c | 4 +
7 files changed, 1231 insertions(+), 165 deletions(-)
create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi
create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt
[..]
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 77f244f..26692e5 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -81,6 +81,10 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+ COMPAT_SAMSUNG_EXYNOS_UART, /* Exynos serial */
+ COMPAT_SAMSUNG_EXYNOS_MSHC, /* Exynos MMC controller */
+ COMPAT_SAMSUNG_EXYNOS_I2S, /* Exynos MMC controller */
+ COMPAT_SAMSUNG_PINCTRL, /* PINCTRL */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 3ae348d..88dd669 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -56,6 +56,10 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(SAMSUNG_EXYNOS_UART, samsung,exynos-uart),
+ COMPAT(SAMSUNG_EXYNOS_MSHC, samsung,exynos-mshc),
+ COMPAT(SAMSUNG_EXYNOS_I2S, samsung,exynos-i2s),
+ COMPAT(SAMSUNG_PINCTRL, samsung,pinctrl),
Do these match the kernel names?
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.8.0
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 07/31] Define CONFIG_SYS_LEGACY_BOARD everywhere
Hi Wolfgang, On Wed, Mar 6, 2013 at 10:45 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1362530405-10824-8-git-send-email-...@chromium.org you wrote: We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first. ... +- CONFIG_SYS_GENERIC_BOARD ... +CONFIG_SYS_LEGACY_BOARD := y Documentation and code mismatch: subject talks about CONFIG_SYS_LEGACY_BOARD, and this is what I also see in the code, but in the README you add a description for CONFIG_SYS_GENERIC_BOARD, but none for CONFIG_SYS_LEGACY_BOARD Yes, this is an internal CONFIG and I thought I might not mention it to avoid confusing board authors. I will add a description to the README. Best regards, Wolfgang Denk Regards, SImon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 07/31] Define CONFIG_SYS_LEGACY_BOARD everywhere
We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v7: - Add description of CONFIG_SYS_LEGACY_BOARD to README Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None README| 21 + arch/arm/config.mk| 3 +++ arch/avr32/config.mk | 3 +++ arch/blackfin/config.mk | 3 +++ arch/m68k/config.mk | 3 +++ arch/microblaze/config.mk | 3 +++ arch/mips/config.mk | 3 +++ arch/nds32/config.mk | 3 +++ arch/nios2/config.mk | 3 +++ arch/powerpc/config.mk| 3 +++ arch/sandbox/config.mk| 3 +++ arch/sh/config.mk | 3 +++ arch/sparc/config.mk | 3 +++ arch/x86/config.mk| 3 +++ config.mk | 8 15 files changed, 68 insertions(+) diff --git a/README b/README index 42544ce..47aa719 100644 --- a/README +++ b/README @@ -3211,6 +3211,27 @@ Configuration Settings: If defined, don't allow the -f switch to env set override variable access flags. +- CONFIG_SYS_GENERIC_BOARD + This selects the architecture-generic board system instead of the + architecture-specific board files. It is intended to move boards + to this new framework over time. Defining this will disable the + arch/foo/lib/board.c file and use common/board_f.c and + common/board_r.c instead. To use this option your architecture + must support it (i.e. must NOT define CONFIG_SYS_LEGACY_BOARD in + its config.mk file). If you find problems enabling this option on + your board please report the problem and send patches! + +- CONFIG_SYS_LEGACY_BOARD + This option should not be defined by board config files. + This is an internal CONFIG defined by architectures which do not + support CONFIG_SYS_GENERIC_BOARD. It is used as a check that boards + don't accidentally define CONFIG_SYS_GENERIC_BOARD when their + architecture cannot support it, and U-Boot would then either not + build or not work. When an architecture supports generic board, + then CONFIG_SYS_LEGACY_BOARD can be removed from the architecture's + config.mk file so that generic board becomes available. + + The following definitions that deal with the placement and management of environment data (variable area); in general, we support the following configurations: diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 24b9d7c..c159675 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -49,6 +49,9 @@ ifneq ($(CONFIG_SPL_BUILD),y) ALL-$(CONFIG_SYS_THUMB_BUILD) += checkthumb endif +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y + # Try if EABI is supported, else fall back to old API, # i. e. for example: # - with ELDK 4.2 (EABI supported), use: diff --git a/arch/avr32/config.mk b/arch/avr32/config.mk index a751a3d..bd5703e 100644 --- a/arch/avr32/config.mk +++ b/arch/avr32/config.mk @@ -29,3 +29,6 @@ PLATFORM_RELFLAGS += -ffixed-r5 -fPIC -mno-init-got -mrelax PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections LDFLAGS_u-boot = --gc-sections --relax + +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y diff --git a/arch/blackfin/config.mk b/arch/blackfin/config.mk index 3595aa2..972afb1 100644 --- a/arch/blackfin/config.mk +++ b/arch/blackfin/config.mk @@ -37,6 +37,9 @@ CONFIG_BFIN_BOOT_MODE := $(strip $(subst ,,$(CONFIG_BFIN_BOOT_MODE))) PLATFORM_RELFLAGS += -ffixed-P3 -fomit-frame-pointer -mno-fdpic PLATFORM_CPPFLAGS += -DCONFIG_BLACKFIN +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y + LDFLAGS_FINAL += --gc-sections LDFLAGS += -m elf32bfin PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections diff --git a/arch/m68k/config.mk b/arch/m68k/config.mk index 11ba334..11ad9a5 100644 --- a/arch/m68k/config.mk +++ b/arch/m68k/config.mk @@ -29,3 +29,6 @@ PLATFORM_CPPFLAGS += -DCONFIG_M68K -D__M68K__ PLATFORM_LDFLAGS += -n PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections LDFLAGS_FINAL += --gc-sections + +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y diff --git a/arch/microblaze/config.mk b/arch/microblaze/config.mk index b4935f0..300e3c5 100644 --- a/arch/microblaze/config.mk +++ b/arch/microblaze/config.mk @@ -33,3 +33,6 @@ PLATFORM_CPPFLAGS += -ffixed-r31 -D__microblaze__ LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds CONFIG_ARCH_DEVICE_TREE := microblaze + +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y diff --git a/arch/mips/config.mk b/arch/mips/config.mk index aaa94e8..7a0275a 100644 --- a/arch/mips/config.mk +++ b/arch/mips/config.mk @@ -41,6 +41,9 @@ ENDIANNESS ?= -EB PLATFORM_CPPFLAGS += -DCONFIG_MIPS -D__MIPS__ +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y +
Re: [U-Boot] [PATCH v4 0/2] usb: ehci: exynos: Fixes for non-fdt systems
Hi Marek, On Fri, Mar 8, 2013 at 4:47 AM, Marek Vasut ma...@denx.de wrote: Dear Vivek Gautam, Based on 'master' branch of u-boot-samsung. Changes from v3: - Adding necesasry check for return error of exynos_usb_parse_dt() and returning accordingly from ehci_hcd_init(). - Removing unnecessary parentheses around ctx-hcd. Vivek Gautam (2): usb: ehci: exynos: Fix multiple FDT decode usb: ehci: exynos: Enable non-dt path drivers/usb/host/ehci-exynos.c | 51 ++-- 1 files changed, 23 insertions(+), 28 deletions(-) applied both, please check u-boot-usb.git if all your patches are in place. If not, let me know ASAP. Patches have been applied fine. Thanks :-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Thanks Regards Vivek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/2] usb: ehci: exynos: Fixes for non-fdt systems
On Fri, Mar 8, 2013 at 9:51 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: Hi Marek, On Fri, Mar 8, 2013 at 4:47 AM, Marek Vasut ma...@denx.de wrote: Dear Vivek Gautam, Based on 'master' branch of u-boot-samsung. Changes from v3: - Adding necesasry check for return error of exynos_usb_parse_dt() and returning accordingly from ehci_hcd_init(). - Removing unnecessary parentheses around ctx-hcd. Vivek Gautam (2): usb: ehci: exynos: Fix multiple FDT decode usb: ehci: exynos: Enable non-dt path drivers/usb/host/ehci-exynos.c | 51 ++-- 1 files changed, 23 insertions(+), 28 deletions(-) applied both, please check u-boot-usb.git if all your patches are in place. If not, let me know ASAP. Patches have been applied fine. Thanks :-) [PATCH v4 1/2] usb: ehci: exynos: Fix multiple FDT decode is just missing Simon's Ack which he gave. ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Thanks Regards Vivek -- Thanks Regards Vivek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/44] RFC: Verified boot implementation based on FIT
Hi, On Fri, Jan 4, 2013 at 5:51 PM, Simon Glass s...@chromium.org wrote: This series implemented a verified boot system based around FIT images as discussed on the U-Boot mailing list, including on this thread: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/147830 RSA is used to implement the encryption. Images are signed by mkimage using private keys created by the user. Public keys are written into U-Boot control FDT (CONFIG_OF_CONTROL) for access by bootm etc. at run-time. The control FDT must be stored in a secure place where it cannot be changed after manufacture. Some notes are provided in the documentaion on how this can be achieved. When images are loaded, they are verified with the public keys. Some minor restructuring of the image code is included in this series, since we now support signatures as well as hashes. It is important to have a test framework for this series. For this, sandbox is used, and a script is provided which signs images and gets sandbox to load them using a script, to check that all is well. So some of the patches here release to adding image support for sandbox. This series is not quite in final form since it still needs rollback support, using a TPM or some other mechanism to make sure that an attacker cannot boot your system with an old image that has been compromised. Also a few more tests are needed to check that image corruption has the desired effect, some proofreading is required, another review of error checking, etc. This series relies on two previous series: sandbox filesystem and sandbox memory. Without these, it is (at best) not possible to run the verified boot test on sandbox. This series and its dependencies are available at: http://git.denx.de/u-boot-x86.git in the branch 'vboot'. Comments welcome. I know are few people are trying this out. Are there any comments at this stage? Che-Liang Chiou has posted a patch for the TPM command that are referenced above. These include rollback support. http://patchwork.ozlabs.org/patch/224163/ I intend to respin this soon to tidy up a few issues. Simon Glass (44): sandbox: config: Enable CONFIG_FIT and CONFIG_CMD_FIT bootstage: Don't build for HOSTCC mkimage: Move ARRAY_SIZE to header file libfdt: Add fdt_next_subnode() to permit easy subnode iteration image: Move timestamp #ifdefs to header file image: Export fit_check_ramdisk() image: Split FIT code into new image-fit.c image: Move HOSTCC image code to tools/ image: Split hash node processing into its own function image: Convert fit_image_hash_set_value() to static, and rename image: Rename fit_image_check_hashes() to fit_image_verify() image: Move hash checking into its own functions image: Move error! string to common place image: Export fit_conf_get_prop_node() image: Rename fit_add_hashes() to fit_add_verification_data() image: Rename hash printing to fit_image_print_verification_data() sandbox: Add CONFIG_OF_HOSTFILE to read FDT from host file fdt: Add a parameter to fdt_valid() Add getenv_hex() to return an environment variable as hex fdt: Allow fdt command to check and update control FDT sandbox: fdt: Support fdt command for sandbox env: Fix minor comment typos in cmd_nvedit fdt: Skip checking FDT if the pointer is NULL Revert fdt- Tell the FDT library where the device tree is Add stdarg to vsprintf.h Add minor updates to README.fdt-control hash: Add a way to calculate a hash for any algortihm sandbox: config: Enable FIT signatures with RSA sandbox: Provide a way to map from host RAM to U-Boot RAM sandbox: image: Add support for booting images in sandbox image: Add signing infrastructure image: Support signing of images image: Verify signatures in FIT images image: Add RSA support for image signing mkimage: Put FIT loading in function and tidy error handling mkimage: Add -k option to specify key directory mkimage: Add -K to write public keys to an FDT blob mkimage: Add -F option to modify an existing .fit file mkimage: Add -c option to specify a comment for key signing mkimage: Add -r option to specify keys that must be verified libfdt: Add fdt_find_regions() image: Add support for signing of FIT configurations Add verified boot information and test WIP: sandbox: config: Add test config for verified boot Makefile |1 + README | 15 + arch/sandbox/cpu/cpu.c |5 + arch/sandbox/cpu/start.c |7 + arch/sandbox/include/asm/io.h|2 + arch/sandbox/include/asm/state.h |1 + arch/sandbox/lib/board.c | 42 +- common/Makefile |2 + common/cmd_bootm.c | 37 +- common/cmd_fdt.c | 83 ++- common/cmd_fpga.c|2 +- common/cmd_nvedit.c | 19 +- common/cmd_source.c |2
Re: [U-Boot] [PATCH 0/15] Enhance SPI/SPI flash probing, add support for Intel ICH controller
Hi, On Wed, Dec 26, 2012 at 2:28 PM, Simon Glass s...@chromium.org wrote: Adding new fields to struct spi_slave and struct spi_flash is painful, because most drivers don't zero the fields they don't use. Anyway it seems better to have the SPI/SPI flash infrastructure provide a simple way of doing this that all drivers can use. So the first part of this series adds spi_alloc_slave(), for SPI, and spi_flash_alloc() for SPI flash. Support is added for the Intel ICH SPI controller, possibly the oddest SPI controller in U-Boot. It is designed for use with SPI flash only, and has a number of high-level features which are dedicated to flash. As such it is a bit of a challenge to get it to behave just like a normal U-Boot SPI device. The ICH driver has two interesting features. Firstly it is impossible to read or write more than 64 bytes at a time! For SPI reading it is possible to hide this within the SPI driver. For SPI writing it unfortunately isn't, since the spi_flash layer has to send an unlock command and a new address for every write. It would be an egregious hack to try to fake this in the driver. So a new property is added to spi_flash to allow the maximum transfer size to be set. Secondly, the ICH SPI flash can be memory mapped. On a lot of x86 devices this improves performance significantly. For example, the standard driver gets maybe 12Mbps throughput from a 33Mbps dual interface, roughly 20% utilisation. With memory mapping, many platforms can achieve about 40Mbps. To implement memory mapping, a new property is provided in the device tree to set the memory map address, which varies by platform. Some x86 platforms will see a speed increase with memory mapping, some won't. The memory mapping feature only works for reading. When in use, the spi_flash layer bypasses the SPI driver completely, and just copies the flash data from the correct place in the memory map. This series includes some generic changes to the SPI and SPI flash layers. It also includes an x86 SPI driver for Intel. Are there any comments, particularlly on the addition of spi_alloc_aloc() and spi_flsah_alloc()? This affects all SPI flash drivers. The first patch needs to be dropped since it seems we are sticking with cpp. Simon Glass (15): fdt: Use sed instead of cpp to pre-process the dtc fdt: Add fdtdec_get_addr_size() to read reg properties spi: Add function to allocate a new SPI slave spi: Use spi_alloc_slave() in each SPI driver sf: Add spi_flash_alloc() to create a new SPI flash struct sf: Use spi_flash_alloc() in each SPI flash driver x86: spi: Add Intel ICH driver spi: Add parameter for maximum write size sf: Respect maximum SPI write size x86: spi: Set maximum write size for ICH sf: Enable FDT-based configuration and memory mapping x86: Move PCI init before SPI init x86: Add FDT SPI node for link x86: Enable SPI flash support for coreboot x86: Enable time command for coreboot arch/x86/lib/board.c |8 +- board/chromebook-x86/dts/link.dts | 11 + drivers/mtd/spi/atmel.c |8 +- drivers/mtd/spi/eon.c |8 +- drivers/mtd/spi/macronix.c|8 +- drivers/mtd/spi/ramtron.c |4 +- drivers/mtd/spi/spansion.c|8 +- drivers/mtd/spi/spi_flash.c | 81 - drivers/mtd/spi/sst.c |8 +- drivers/mtd/spi/stmicro.c |8 +- drivers/mtd/spi/winbond.c |8 +- drivers/spi/Makefile |4 + drivers/spi/altera_spi.c |4 +- drivers/spi/andes_spi.c |4 +- drivers/spi/armada100_spi.c |4 +- drivers/spi/atmel_spi.c |4 +- drivers/spi/bfin_spi.c|4 +- drivers/spi/cf_qspi.c |4 +- drivers/spi/cf_spi.c |4 +- drivers/spi/davinci_spi.c |4 +- drivers/spi/fsl_espi.c|4 +- drivers/spi/ich.c | 752 + drivers/spi/ich.h | 144 +++ drivers/spi/kirkwood_spi.c|5 +- drivers/spi/mpc52xx_spi.c |5 +- drivers/spi/mpc8xxx_spi.c |5 +- drivers/spi/mxc_spi.c |4 +- drivers/spi/mxs_spi.c |4 +- drivers/spi/oc_tiny_spi.c |5 +- drivers/spi/omap3_spi.c | 27 +- drivers/spi/sh_spi.c |4 +- drivers/spi/soft_spi.c|4 +- drivers/spi/spi.c | 39 ++ drivers/spi/tegra_spi.c |4 +- drivers/spi/xilinx_spi.c |4 +- dts/Makefile | 10 +- include/configs/coreboot.h| 13 +- include/fdtdec.h | 16 + include/spi.h | 44 +++ include/spi_flash.h | 39 ++ lib/fdtdec.c | 27 ++- 41 files changed, 1208 insertions(+), 147 deletions(-) create mode
Re: [U-Boot] Possible GPL violation
Dear Charles Manning, In message CAE21AQpUuFOAfwRk=7rsQHL5p_EVhiNQUAT4QKY=px0svxo...@mail.gmail.com you wrote: 1) If you buy a product containing GPL code, but the company does not supply the code, then - in general - you cannot force the company to supply you with code. You need to get the collaboration of an infringed copyright holder to force the issue. Just for the record: I'm always willing to help out as such. One of the problems with pursuing these actions is that it can be somewhat hard to prove that you have contributed materially to claim copyright over some code. I think I should be in a pretty good position to prove that. This is why I always offer help in such situations. In much of open source though, there have been many major contributors and even more minor contributors and it can be hard to claim to be a legitimate copyright holder. In theory, I guess you could claim copyright on a three line patch, but the harsh reality of lawyer land would probably want to see something far more substantial. This is one of the reasons why the FSF asks for / recommends copyright assignments, see for example [1]. [1] http://www.gnu.org/licenses/why-assign.html Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A Stanford research group advertised for participants in a study of obsessive-compulsive disorder. They were looking for therapy clients who had been diagnosed with this disorder. The response was grati- fying; they got 3,000 responses about three days after the ad came out. All from the same person. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Marek Vasut, In message 201303080429.00780.ma...@denx.de you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) ...and has the same issue of including the unwanted lower case letters. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. - Frederick Brooks Jr., The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mtdparts not agreeing wiht fw_printenv
Dear Wolfgang Denk , On Thu, 2013-03-07 at 07:52 +0100, Wolfgang Denk wrote: Dear John Stile, In message 1362532855.20183.135.camel@genx you wrote: I am quite confused about partitions in my NAND flash. Linux can mount my rootfs, so partitions make sense to the kernel, but from the shell fw_printenv can't read the uboot environment, not matter what I use in /etc/fw_env.config. That means that all settings were incorrect. All settings where not incorrect. dev:size erasesize name mtd0: 0002 0002 bootstrap1 mtd1: 0004 0002 uboot1 mtd2: 001a 0002 env1 ^^ mtd2 mtd3: 0020 0002 linux1 mtd4: 07c0 0002 rootfs1 mtd5: 0002 0002 bootstrap2 mtd6: 0004 0002 uboot2 mtd7: 001a 0002 env2 ^^ mtd7 mtd8: 0020 0002 linux2 mtd9: 07c0 0002 rootfs2 mtd10: 4200 0420 bootstrap3 mtd11: 4200 0420 env3 ^^ mtd11 mtd12: 00039c00 0420 uboot3 mtd13: 00252000 0420 linux3 mtd14: 005ac000 0420 rootfs3 What's that? This makes no sense to me - either you have a single copy of the environment, or two (in case of redudant env). Three copies is not a supported configuration. I purposefully created more /dev/mtd devices than mtdparts would require, in order to find which partitions actually contain the uboot env. mtdparts does not require anything. You configure your systems as needed, and then set mtdparts to match that setting. SO the setting comes first (starting in your head or - probably better - on a sheet of paper), and then you set mtdparts as needed. Right. Even without the /dev/mtd character device files, the system boots. This post comes way after a lot of work on paper. /dev/mtd4 and /dev/mtd5 create binary equivalent dumps of env1 /dev/mtd14 and /dev/mtd15 create binary equivalent dumps of env2. The names and use of your partitions is in serious mismatch. Fix this first! The problem turned out to be due to my /dev/mtd character device files had sequential minor numbers. /etc/fw_env.config does not like either of those, saying the crc does not checkout. /etc/fw_env.config: /dev/mtd2 0x0 0x2 0x2 /dev/mtd2 0x2 0x2 0x2 Well, if you find the environment in /dev/mtd4 and /dev/mtd5, then you should use these in the fw_env.config Best regards, Wolfgang Denk Like I said, I think, even those did not work. When I created my /dev/mtd character device files to use even minor numbers, I was able to see my env in /dev/mtd2 /dev/mtd7 using od: od -t xz /dev/mtd2 od -t xz /dev/mtd7 And fw_printenv also worked. One site said read-write device will have even minor numbers. Since I am using a 2.6.30 kernel, without tmpdevfs, I rely on buildroot's target/generic/device_table_dev.txt to generate my devices, and it was there I had not set the proper values: # MTD stuff # nametype mode uid gid major minor start inc count /dev/mtdc 640 0 0 90 0 0 2 20 Thank you for your help. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: at91sam9x5: Using CPU string directly
As the CPU name is not configurable, using CPU string directly
Signed-off-by: Bo Shen voice.s...@atmel.com
---
arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c | 14 +++---
arch/arm/include/asm/arch-at91/at91sam9x5.h |6 --
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
index 0448c0b..29e8aa4 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
@@ -61,20 +61,20 @@ char *get_cpu_name()
if (cpu_is_at91sam9x5()) {
switch (extension_id) {
case ARCH_EXID_AT91SAM9G15:
- return CONFIG_SYS_AT91_G15_CPU_NAME;
+ return AT91SAM9G15;
case ARCH_EXID_AT91SAM9G25:
- return CONFIG_SYS_AT91_G25_CPU_NAME;
+ return AT91SAM9G25;
case ARCH_EXID_AT91SAM9G35:
- return CONFIG_SYS_AT91_G35_CPU_NAME;
+ return AT91SAM9G35;
case ARCH_EXID_AT91SAM9X25:
- return CONFIG_SYS_AT91_X25_CPU_NAME;
+ return AT91SAM9X25;
case ARCH_EXID_AT91SAM9X35:
- return CONFIG_SYS_AT91_X35_CPU_NAME;
+ return AT91SAM9X35;
default:
- return CONFIG_SYS_AT91_UNKNOWN_CPU;
+ return Unknown CPU type;
}
} else {
- return CONFIG_SYS_AT91_UNKNOWN_CPU;
+ return Unknown CPU type;
}
}
diff --git a/arch/arm/include/asm/arch-at91/at91sam9x5.h
b/arch/arm/include/asm/arch-at91/at91sam9x5.h
index de0f1b1..b7d1932 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9x5.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9x5.h
@@ -140,12 +140,6 @@
/*
* Cpu Name
*/
-#define CONFIG_SYS_AT91_G15_CPU_NAME AT91SAM9G15
-#define CONFIG_SYS_AT91_G25_CPU_NAME AT91SAM9G25
-#define CONFIG_SYS_AT91_G35_CPU_NAME AT91SAM9G35
-#define CONFIG_SYS_AT91_X25_CPU_NAME AT91SAM9X25
-#define CONFIG_SYS_AT91_X35_CPU_NAME AT91SAM9X35
-#define CONFIG_SYS_AT91_UNKNOWN_CPUUnknown CPU type
#define ATMEL_CPU_NAME get_cpu_name()
/*
--
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 4/4] ARM: atmel: add sama5d3xek support
Hi Bo,
On 08.03.13 04:31, Bo Shen wrote:
Hi Andreas,
Thansk for your comments.
On 3/7/2013 18:58, Andreas Bießmann wrote:
Dear Bo Shen,
On 28.02.13 08:00, Bo Shen wrote:
Add sama5d3xek support with following feature
- boot from NAND flash, PMECC support, 4bit ECC @ 512 bytes sector
- boot from SPI flash support
- boot from SD card support
- LCD support
- EMAC support
- USB support
Signed-off-by: Bo Shen voice.s...@atmel.com
---
snip
diff --git a/arch/arm/cpu/armv7/at91/clock.c
b/arch/arm/cpu/armv7/at91/clock.c
new file mode 100644
index 000..5fdefcc
--- /dev/null
+++ b/arch/arm/cpu/armv7/at91/clock.c
@@ -0,0 +1,116 @@
snip
+static u32 at91_pll_rate(u32 freq, u32 reg)
+{
+unsigned mul, div;
+
+div = reg 0xff;
+mul = (reg 18) 0x7ff;
The CKGR_PLLAR states that the MULA is 8 bit wide. Is the mask here
intended?
I see, it is stolen from the arm926ejs variant, has anyone checked that
before ;)
at91sam9g20, at91sam9g45, the MULA is 8 bit wide
And other at91 serials is 11 bit wide.
sama5d3x, the MULA is only 7 bit wide. I will correct it.
You are right, it is just 7 bit wide (not 8 bit as I said) ...
snip
+void at91_periph_clk_enable(int id)
+{
+struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
The write protect is meant to be right here?
I am sorry, I don't get the right means.
Well, this seems to be the first SoC from Atmel which has write
protection bit WPEN in pmc-wpmr for write access to pmc-pcer{0|1}. My
question here is, should we rely on reset state of the WPEN bit or
should we explicitly disable write protection on every call to
at91_periph_clk_enable() or should we do this conditional?
Additionally we may ask if we should enable write protection afterwards.
snip
diff --git a/arch/arm/cpu/armv7/at91/sama5d3_devices.c
b/arch/arm/cpu/armv7/at91/sama5d3_devices.c
new file mode 100644
index 000..e5474e0
--- /dev/null
+++ b/arch/arm/cpu/armv7/at91/sama5d3_devices.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) 2012-2013 Atmel Corporation
Your email here?
OK, I will add it.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/arch/sama5d3.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/clk.h
+#include asm/arch/gpio.h
+#include asm/io.h
+
+/*
+ * if CONFIG_AT91_GPIO_PULLUP ist set, keep pullups on on all
+ * peripheral pins. Good to have if hardware is soldered optionally
+ * or in case of SPI no slave is selected. Avoid lines to float
+ * needlessly. Use a short local PUP define.
+ *
+ * Due to errata TXD floats when CTS is inactive pullups are always
+ * on for TXD pins.
+ */
+#ifdef CONFIG_AT91_GPIO_PULLUP
+# define PUP CONFIG_AT91_GPIO_PULLUP
+#else
+# define PUP 0
+#endif
+
snip
+
+void at91_serial0_hw_init(void)
+{
+at91_set_a_periph(AT91_PIO_PORTD, 18, 1);/* TXD0 */
Why enabling PUP here for TX ...
I will correct it to use PUP.
Don't get me wrong, please do not use the PUP define which is
conditional. We should enable pullup for each TX line _unconditional_
which means place a '1' at last argument for each TX line (also for the
serial1_hw line which didn't had it in this patch). I don't know if the
mentioned errata (in comment above) also hits the sama5, but I think it
is good to have the TX line pulled up even if some external PU exists.
The internal PU is about 100 to 300 kOhms, a typical external PU is
about 10kOhms or 100kOhms, so the resulting resistance is nearly 10kOhm
(for 10k external) or about 50k to 75k, depending on concrete internal
resistance. I think this is ok.
The RX line instead should be conditional with PUP define, how do you
think about?
+at91_set_a_periph(AT91_PIO_PORTD, 17, PUP);/* RXD0 */
+
+/* Enable clock */
+at91_periph_clk_enable(ATMEL_ID_USART0);
+}
+
+void at91_serial1_hw_init(void)
+{
+at91_set_a_periph(AT91_PIO_PORTB, 28, 0);/* TXD1 */
... but not here?
I will add PUP for it.
+at91_set_a_periph(AT91_PIO_PORTB, 29, PUP);/* RXD1 */
+
+/* Enable clock */
+at91_periph_clk_enable(ATMEL_ID_USART1);
+}
+
+void
