Re: [U-Boot] [PATCH v2] usb: increase non-bulk timeout for slow chipsets.
Hi, 2011/8/4 Jason : > Remy, > > I neglected to include you in my original submission, could you please > take a look at this for u-boot-usb? Original email is here [1]. And > the commit I'm referring to is here [2]. No problem... I am subscribed to the list, and I have seen it already. (I am a bit slow lately due to summer vacation, but I am catching up...) Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, usb, davinci: make USBPHY_CTL register configurable
Hi,
2011/8/2 Heiko Schocher :
> Define CONFIG_DV_USBPHY_CTL for setting the USB PHY control
> register.
> Signed-off-by: Heiko Schocher
> cc: Sandeep Paulraj
> cc: Remy Bohmer
> ---
> drivers/usb/musb/davinci.c | 6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
> index f56f2df..98c2c62 100644
> --- a/drivers/usb/musb/davinci.c
> +++ b/drivers/usb/musb/davinci.c
> @@ -26,6 +26,10 @@
> #include "davinci.h"
> #include
>
> +#if !defined(CONFIG_DV_USBPHY_CTL)
> +#define CONFIG_DV_USBPHY_CTL (USBPHY_SESNDEN | USBPHY_VBDTCTEN)
> +#endif
> +
> /* MUSB platform configuration */
> struct musb_config musb_cfg = {
> .regs = (struct musb_regs *)MENTOR_USB0_BASE,
> @@ -50,7 +54,7 @@ static u8 phy_on(void)
> writel(USBPHY_PHY24MHZ | USBPHY_SESNDEN |
> USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
> #else
> - writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
> + writel(CONFIG_DV_USBPHY_CTL, USBPHY_CTL_PADDR);
> #endif
> timeout = musb_cfg.timeout;
What does it fix, why do you want this?
Kind regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-usb
The following changes since commit fa82f871c8dbc9a15e8dc274b3f99dd5fa0da458: Convert ISO-8859 files to UTF-8 (2011-08-04 23:34:02 +0200) are available in the git repository at: git://git.denx.de/u-boot-usb.git master Jason Cooper (1): usb: increase non-bulk timeout for slow chipsets. Marek Vasut (2): USB: Set portnr so USB1.1 and 1.0 devices work on EHCI controllers USB: Move USB_PRINTF() out of ifdef in usb_scan_devices() Nobuhiro Iwamatsu (1): usb: r8a66597: Fix argument mistake of inl Simon Glass (4): Add support for SMSC95XX USB 2.0 10/100MBit Ethernet Adapter Add Ethernet hardware MAC address framework to usbnet Add documentation for USB Host Networking Put common autoload code into auto_load() function board/davinci/common/misc.c |2 +- common/usb.c|3 +- doc/README.usb | 157 - drivers/net/designware.c|2 +- drivers/usb/eth/Makefile|1 + drivers/usb/eth/smsc95xx.c | 879 +++ drivers/usb/eth/usb_ether.c | 16 +- drivers/usb/host/r8a66597.h |2 +- include/net.h | 25 ++- include/usb.h |2 +- include/usb_ether.h | 13 + net/bootp.c | 76 ++--- net/eth.c | 64 ++-- 13 files changed, 1165 insertions(+), 77 deletions(-) create mode 100644 drivers/usb/eth/smsc95xx.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] usb: increase non-bulk timeout for slow chipsets.
Hi, 2011/7/31 Jason Cooper : > If you take a look at 96820a35, you'll see the original timeout was > CONFIG_SYS_HZ. Which is 1000. After the mentioned change, non-bulk timeout > was changed to 100. This causes timeout failures on the dreamplug platform > when trying to initialize the usb microsd reader. > > Signed-off-by: Jason Cooper Applied to u-boot-usb Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem with mpc837x start.S
On 08/04/2011 06:37 AM, shawn Bai wrote: > When enlarging Nor Flash to 4GiB, the AM in OR0 is 0x_0, where the number > of zero is 17. > > According to what is said in datasheet, if the bit value of some bit in > address mask is 0, > then the corresponding bit in address will be masked. > > So, the higher 17 bits in address will be masked, is it right ? > > If so, the range accessed in flash is just 32KBytes from the BA in BR0. > Is that right ? But Not the same with what you mean. The address mask applies only to matching a chip select. Once it's been matched, the full address goes to the device -- minus the bits that the device does not implement. An bit whose address mask is zero is treated the same as the least-significant 15 bits. > And from what you replied before in this question, may I say the 32KBytes > will repeat through 4GiB address space ? not 8MBytes ? No. > then, what is the effect of CONFIG_SYS_MONITOR_BASE in this ABSOLUTE branch > as uboot comment indicates ? The effect is that the program counter contains "CONFIG_SYS_MONITOR_BASE + in_flash", so that when the code later shrinks the chipselect it will still be executing from flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2][v2] powerpc/85xx: Add ULPI and UTMI USB Phy support for P1010/P1014
From: Ramneek Mehresh
Add UTMI and ULPI PHY support for USB controller on qoriq series of
processors with internal UTMI PHY implemented, for example P1010/P1014
- Use both getenv() and hwconfig to get USB phy type till getenv()
is depricated
- Introduce CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY to specify if soc
has internal UTMI phy
Signed-off-by: Ramneek Mehresh
CC: Remy Bohmer
Signed-off-by: Kumar Gala
---
* Add whitespace and formatting fixes
arch/powerpc/include/asm/config_mpc85xx.h |2 +
drivers/usb/host/ehci-fsl.c | 39 ++--
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 04ca989..d9d04e7 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -97,6 +97,7 @@
#define CONFIG_NUM_DDR_CONTROLLERS 1
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.2"
+#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
/* P1011 is single core version of P1020 */
#elif defined(CONFIG_P1011)
@@ -141,6 +142,7 @@
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_NUM_DDR_CONTROLLERS 1
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
+#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
/* P1015 is single core version of P1024 */
#elif defined(CONFIG_P1015)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 6e0043a..5a65d92 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * (C) Copyright 2009, 2011 Freescale Semiconductor, Inc.
*
* (C) Copyright 2008, Excito Elektronik i Sk=E5ne AB
*
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "ehci.h"
#include "ehci-core.h"
@@ -39,6 +40,11 @@
int ehci_hcd_init(void)
{
struct usb_ehci *ehci;
+ char usb_phy[5];
+ const char *phy_type = NULL;
+ size_t len;
+
+ usb_phy[0] = '\0';
ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
@@ -52,10 +58,37 @@ int ehci_hcd_init(void)
out_be32(&ehci->snoop2, 0x8000 | SNOOP_SIZE_2GB);
/* Init phy */
- if (!strcmp(getenv("usb_phy_type"), "utmi"))
- out_le32(&(hcor->or_portsc[0]), PORT_PTS_UTMI);
+ if (hwconfig_sub("usb1", "phy_type"))
+ phy_type = hwconfig_subarg("usb1", "phy_type", &len);
else
+ phy_type = getenv("usb_phy_type");
+
+ if (!phy_type) {
+#ifdef CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
+ /* if none specified assume internal UTMI */
+ strcpy(usb_phy, "utmi");
+ phy_type = usb_phy;
+#else
+ printf("WARNING: USB phy type not defined !!\n");
+ return -1;
+#endif
+ }
+
+ if (!strcmp(phy_type, "utmi")) {
+#if defined(CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY)
+ setbits_be32(&ehci->control, PHY_CLK_SEL_UTMI);
+ setbits_be32(&ehci->control, UTMI_PHY_EN);
+ udelay(1000); /* delay required for PHY Clk to appear */
+#endif
+ out_le32(&(hcor->or_portsc[0]), PORT_PTS_UTMI);
+ } else {
+#if defined(CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY)
+ clrbits_be32(&ehci->control, UTMI_PHY_EN);
+ setbits_be32(&ehci->control, PHY_CLK_SEL_ULPI);
+ udelay(1000); /* delay required for PHY Clk to appear */
+#endif
out_le32(&(hcor->or_portsc[0]), PORT_PTS_ULPI);
+ }
/* Enable interface. */
setbits_be32(&ehci->control, USB_EN);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc/85xx: Add ULPI and UTMI USB Phy support for P1010/P1014
On Aug 8, 2011, at 3:15 PM, Remy Bohmer wrote:
> Hi,
>
> 2011/7/1 Kumar Gala :
>> From: Ramneek Mehresh
>>
>> Add UTMI and ULPI PHY support for USB controller on qoriq series of
>> processors with internal UTMI PHY implemented, for example P1010/P1014
>> - Use both getenv() and hwconfig to get USB phy type till getenv()
>> is depricated
>> - Introduce CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY to specify if soc
>> has internal UTMI phy
>>
>> Signed-off-by: Ramneek Mehresh
>> CC: Remy Bohmer
>> Signed-off-by: Kumar Gala
>> ---
>> arch/powerpc/include/asm/config_mpc85xx.h |2 +
>> drivers/usb/host/ehci-fsl.c | 37
>> ++--
>> 2 files changed, 36 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
>> b/arch/powerpc/include/asm/config_mpc85xx.h
>> index 04ca989..d9d04e7 100644
>> --- a/arch/powerpc/include/asm/config_mpc85xx.h
>> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
>> @@ -97,6 +97,7 @@
>> #define CONFIG_NUM_DDR_CONTROLLERS 1
>> #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
>> #define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.2"
>> +#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>>
>> /* P1011 is single core version of P1020 */
>> #elif defined(CONFIG_P1011)
>> @@ -141,6 +142,7 @@
>> #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
>> #define CONFIG_NUM_DDR_CONTROLLERS 1
>> #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
>> +#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>>
>> /* P1015 is single core version of P1024 */
>> #elif defined(CONFIG_P1015)
>> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
>> index 6e0043a..66b7da5 100644
>> --- a/drivers/usb/host/ehci-fsl.c
>> +++ b/drivers/usb/host/ehci-fsl.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * (C) Copyright 2009 Freescale Semiconductor, Inc.
>> + * (C) Copyright 2009, 2011 Freescale Semiconductor, Inc.
>> *
>> * (C) Copyright 2008, Excito Elektronik i Sk=E5ne AB
>> *
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "ehci.h"
>> #include "ehci-core.h"
>> @@ -39,6 +40,11 @@
>> int ehci_hcd_init(void)
>> {
>>struct usb_ehci *ehci;
>> + char usb_phy[5];
>> + const char *phy_type = NULL;
>> + size_t len;
>> +
>> + usb_phy[0] = '\0';
>>
>>ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
>>hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
>> @@ -52,10 +58,35 @@ int ehci_hcd_init(void)
>>out_be32(&ehci->snoop2, 0x8000 | SNOOP_SIZE_2GB);
>>
>>/* Init phy */
>> - if (!strcmp(getenv("usb_phy_type"), "utmi"))
>> - out_le32(&(hcor->or_portsc[0]), PORT_PTS_UTMI);
>> + if (hwconfig_sub("usb1", "phy_type"))
>> + phy_type = hwconfig_subarg("usb1", "phy_type", &len);
>>else
>> + phy_type = getenv("usb_phy_type");
>
> Please insert an empty line here for readability.
>
>> + if (!phy_type) {
>> +#ifdef CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>> + /* if none specified assume internal UTMI */
>> + strcpy(usb_phy, "utmi");
>> + phy_type = usb_phy;
>> +#else
>> + printf("WARNING: USB phy type not defined !!\n");
>> + return -1;
>> +#endif
>> + }
>
> Alignment is messy due to this patch. Please fix.
>
>> + if (!strcmp(phy_type, "utmi")) {
>> +#if defined(CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY)
>> + setbits_be32(&ehci->control, PHY_CLK_SEL_UTMI);
>> + setbits_be32(&ehci->control, UTMI_PHY_EN);
>> + udelay(1000); /* delay required for PHY Clk to appear */
>> +#endif
>> + out_le32(&(hcor->or_portsc[0]), PORT_PTS_UTMI);
>> + } else {
>> +#if defined(CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY)
>> + clrbits_be32(&ehci->control, UTMI_PHY_EN);
>> + setbits_be32(&ehci->control, PHY_CLK_SEL_ULPI);
>> + udelay(1000); /* delay required for PHY Clk to appear */
>> +#endif
>>out_le32(&(hcor->or_portsc[0]), PORT_PTS_ULPI);
>> + }
>
> The ifdef-ery makes the code somewhat messy as well. Can it be written
> somewhat else?
> Apart from that and the style issues, no remarks or concerns.
Not really sure how to do that. The patch is a bit more messy than the actual
code.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc/85xx: Add ULPI and UTMI USB Phy support for P1010/P1014
Hi, >> The ifdef-ery makes the code somewhat messy as well. Can it be written >> somewhat else? >> Apart from that and the style issues, no remarks or concerns. > > Not really sure how to do that. The patch is a bit more messy than the > actual code. I was talking about the actual code, not the patch... I did not see a quick solution myself either. So, I will pull it in as-is... Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] Add basic clock and pinmux functions to the Tegra2
Hi Albert, Are we getting closer with this patch series? Does anyone have any more comments at this stage? Regards, Simon On Thu, Jul 28, 2011 at 9:11 PM, Simon Glass wrote: > This patch series adds basic clock and pinmux functions to the Tegra2, and > modifies the ap20 and board code to use them. > > Changes in v2: > - Removed use of bitfield access macros > - Now uses manual shifts and masks > > Changes in v3: > - Removed bitfield shift/mask macros and write these out manually > - Rebased to take account to new MMC patches > - Remove future time function > - No microsecond timing changes as I am unsure of the state of this in U-Boot > > Simon Glass (4): > Tegra2: Add microsecond timer function > Tegra2: Add more clock support > Tegra2: Add additional pin multiplexing features > Tegra2: Use clock and pinmux functions to simplify code > > arch/arm/cpu/armv7/tegra2/Makefile | 2 +- > arch/arm/cpu/armv7/tegra2/ap20.c | 91 +++--- > arch/arm/cpu/armv7/tegra2/clock.c | 158 + > arch/arm/cpu/armv7/tegra2/pinmux.c | 53 ++ > arch/arm/cpu/armv7/tegra2/timer.c | 18 ++- > arch/arm/include/asm/arch-tegra2/clk_rst.h | 127 ++ > arch/arm/include/asm/arch-tegra2/clock.h | 264 > > arch/arm/include/asm/arch-tegra2/pinmux.h | 161 -- > arch/arm/include/asm/arch-tegra2/timer.h | 34 > board/nvidia/common/board.c | 117 - > 10 files changed, 784 insertions(+), 241 deletions(-) > create mode 100644 arch/arm/cpu/armv7/tegra2/clock.c > create mode 100644 arch/arm/cpu/armv7/tegra2/pinmux.c > create mode 100644 arch/arm/include/asm/arch-tegra2/clock.h > create mode 100644 arch/arm/include/asm/arch-tegra2/timer.h > > -- > 1.7.3.1 > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Aspire Collection Magazine London Autumn 2011 edition - advertising open
Hi there We're delighted to inform you that your organisation has been invited to participate in the Aspire Collection Magazine London, for the Autumn 2011 edition. As the brainchild of Aspire Estate Agents, SW London, this quarterly magazine features some of the most appealing properties for sale in the SW London region, with exclusive advertisers around these. The magazine is four times annually, and is distributed accordingly, with now 15,000 copies per edition hand-delivered to property buyers, accompanying professions (e.g. surveyors, interior designers, legal firms etc), and plenty of sought-after private and commercial addresses within the SW London region, from Knightsbridge to Chelsea to Wimbledon. Sporting a long 'shelf-life' too, this means it is an outstanding vehicle for you to reach this financially capable AB1/high net worth property buying demographic for your direct sales and marketing. Regarding your potential participation, we're pleased to tell you that the Special Introductory Rate for booking for the Autumn 2011 Edition is now open, and until 30th August 2011 we would like to offer you the improved reduced 'trial' rate of just £999.00 total for a full A4 page advertisement (list price £1250.00 premium position), or a double page spread at £1750.00 (usual media sheet through links below). To book for this attractive trial rate offer, simply reply to this email with the words '[insert ad size here] - Yes please' no later than 30th August to begin reaching this high net worth audience for your business. Hope to hear from you soon! Kind regards Chris Brown for ASPIRE COLLECTION MAGAZINE, LONDON T: +44 (0)203 286 8737 ddi (or via accts team +44 (0) 207 607 0717) F: +44 (0)207 183 4752 W: http://www.aspire.co.uk Current Edition Aspire Magazine here : http://www.aspire.co.uk/aspire-magazine.php Downloads: Media Kit : http://www.sksassociates.co.uk/aspire/AspireAdRates.pdf AdSpecs : http://www.sksassociates.co.uk/aspire/AspireAdSpec.pdf Contracted exclusively by: SKS Media Trusted UK Agents "Bringing the top drawer to you!" ** You were subscribed to this offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 4/9] spl: add NAND Library to new SPL
On 08/08/2011 08:11 AM, Simon Schwarz wrote: > Adds NAND library to SPL. > > Signed-off-by: Simon Schwarz > --- Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache
Hi Marek Vasut,
On 08/09/2011 01:34 AM, Marek Vasut wrote:
> On Monday, August 08, 2011 10:01:19 AM Albert ARIBAUD wrote:
>> Hi Hong Xu,
>>
>> Le 08/08/2011 05:20, Hong Xu a écrit :
>>> After DMA operation, we need to maintain D-Cache coherency.
>>> So that the DCache must be invalidated (hence CPU will fetch
>>> data written by DMA controller from RAM).
>>>
>>> Tested on AT91SAM9261EK with Peripheral DMA controller.
>>>
>>> Signed-off-by: Hong Xu
>>> Tested-by: Elen Song
>>> CC: Albert Aribaud
>>> CC: Aneesh V
>>> CC: Reinhard Meyer
>>> CC: Heiko Schocher
>>> ---
>>>
>>> V2:
>>> Per Albert's suggestion, add invalidate_dcache_range
>>>
>>> V3:
>>> invalidate_dcache_range emits warning when detecting unaligned buffer
>>>
>>> invalidate_dcache_range won't clean any adjacent cache line when
>>> detecting unaligned buffer and only round up/down the buffer address
>>>
>>> + mva = start;
>>> + if ((mva& (cache_line_len - 1)) != 0) {
>>> + printf("WARNING: %s - unaligned buffer detected, starting "
>>
>> I'd rather have a message about "cache", not "buffer", e.g.
>>
>> printf("WARNING: %s - start address %x is not aligned\n"
>> __FUNCTION__, start);
>
> __func__ is prefered in linux kernel :-)
__func__ is C99 standard. __FUNCTION__ appears more in U-Boot. ;-)
GCC manual says some older GCC only recognize __FUNCTION__ .
If we rely on GCC, it looks __FUNCTION__ will reduce troubles.
BR,
Eric
>>
>>> + mva&= ~(cache_line_len - 1);
>>> + }
>>> + if ((stop& (cache_line_len - 1)) != 0) {
>>> + printf("WARNING: %s - unaligned buffer detected, ending "
>>> + "address: 0x%08x\n", __FUNCTION__, stop);
>>
>> Ditto.
>
> Ditto.
>
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] i2c:gpio:s5p: I2C GPIO Software implementation (via soft_i2c)
Dear Lukasz Majewski,
On 20 July 2011 17:35, Lukasz Majewski wrote:
> This patch adds support for software I2C for GONI reference target.
> It adds support for access to GPIOs by number, not as it is present,
> by bank and offset.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> Cc: Minkyu Kang
> Cc: Heiko Schocher
>
> ---
> Changes for v2:
> - Generic GPIO code added to arch/arm/gpio.h
> - Platform dependent GPIO code added to board/samsung/goni.c
> - Code cleanup
> ---
> arch/arm/include/asm/arch-s5pc1xx/gpio.h | 36
> ++
> board/samsung/goni/goni.c | 30 +++-
> include/configs/s5p_goni.h | 13 ++
> 3 files changed, 77 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-s5pc1xx/gpio.h
> b/arch/arm/include/asm/arch-s5pc1xx/gpio.h
> index 903de9c..8d2e2e9 100644
> --- a/arch/arm/include/asm/arch-s5pc1xx/gpio.h
> +++ b/arch/arm/include/asm/arch-s5pc1xx/gpio.h
please add s5pc2xx also.
> diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
> index e24cd29..d1ff956 100644
> --- a/board/samsung/goni/goni.c
> +++ b/board/samsung/goni/goni.c
> @@ -1,7 +1,8 @@
> /*
> - * Copyright (C) 2008-2009 Samsung Electronics
> + * Copyright (C) 2008-2011 Samsung Electronics
> * Minkyu Kang
> * Kyungmin Park
> + * Lukasz Majewski
> *
> * See file CREDITS for list of people who contributed to this
> * project.
> @@ -28,7 +29,7 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -static struct s5pc110_gpio *s5pc110_gpio;
> +struct s5pc110_gpio *s5pc110_gpio;
Why?
>
> int board_init(void)
> {
> @@ -96,3 +97,28 @@ int board_mmc_init(bd_t *bis)
> return s5p_mmc_init(0, 4);
> }
> #endif
> +
> +#ifdef CONFIG_SOFT_I2C
> +void i2c_init_board(void) {}
> +/* Platform dependent functions for extracting GPIO number */
> +int s5p_gpio_get_nr(void *gp_ptr, int gpio)
> +{
> + unsigned int offset = gp_ptr - (void *) s5pc110_gpio;
> + offset /= sizeof(struct s5p_gpio_bank);
> +
> + return (offset * GPIO_PER_BANK) + gpio;
> +}
> +
> +struct s5p_gpio_bank *s5p_gpio_get_bank(int nr)
> +{
> + int bank = nr / GPIO_PER_BANK;
> + bank *= sizeof(struct s5p_gpio_bank);
> +
> + return (struct s5p_gpio_bank *) ((void *) s5pc110_gpio + bank);
> +}
> +
> +int s5p_gpio_get_pin(int nr)
> +{
> + return nr % GPIO_PER_BANK;
> +}
> +#endif
I think these codes are not board specific.
Please make common file for I2C gpio for s5p.
Thanks
Minkyu Kang
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, usb, davinci: make USBPHY_CTL register configurable
Hello Remy,
Remy Bohmer wrote:
> Hi,
>
> 2011/8/2 Heiko Schocher :
>> Define CONFIG_DV_USBPHY_CTL for setting the USB PHY control
>> register.
>> Signed-off-by: Heiko Schocher
>> cc: Sandeep Paulraj
>> cc: Remy Bohmer
>> ---
>> drivers/usb/musb/davinci.c |6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
>> index f56f2df..98c2c62 100644
>> --- a/drivers/usb/musb/davinci.c
>> +++ b/drivers/usb/musb/davinci.c
>> @@ -26,6 +26,10 @@
>> #include "davinci.h"
>> #include
>>
>> +#if !defined(CONFIG_DV_USBPHY_CTL)
>> +#define CONFIG_DV_USBPHY_CTL (USBPHY_SESNDEN | USBPHY_VBDTCTEN)
>> +#endif
>> +
>> /* MUSB platform configuration */
>> struct musb_config musb_cfg = {
>>.regs = (struct musb_regs *)MENTOR_USB0_BASE,
>> @@ -50,7 +54,7 @@ static u8 phy_on(void)
>>writel(USBPHY_PHY24MHZ | USBPHY_SESNDEN |
>>USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
>> #else
>> - writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
>> + writel(CONFIG_DV_USBPHY_CTL, USBPHY_CTL_PADDR);
>> #endif
>>timeout = musb_cfg.timeout;
>
> What does it fix, why do you want this?
I posted the cam_enc_4xx board support. Now adding USB support, and I
have to configure this register as:
#define CONFIG_DV_USBPHY_CTL (USBPHY_SESNDEN | USBPHY_VBDTCTEN | \
USBPHY_PHY24MHZ)
so I need a possibility to configure this register ... and I could not
use DAVINCI_DM365EVM! (BTW: This define (so it seems to me) hides
board specific code, which should be cleaned up ... Sandeep?)
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 3/9] omap-common: add nand spl support
Hi Aneesh,
On 08/05/2011 09:30 AM, Aneesh V wrote:
> Hi Simon,
>
> Sorry if my response is late. I was not in office for couple of days.
First day in office since vacation - so no you are not late ;)
>
> On Tuesday 02 August 2011 09:29 PM, Simon Schwarz wrote:
>> Add NAND support for the new SPL structure.
>>
>> Signed-off-by: Simon Schwarz
>> ---
>> This patch didn't exist before V2!
>>
>> V2 changes:
>> ADD Some define-barriers for OMAP3 to only use NAND
>> ADD nand_load_image() - inits the OMAP gpmc, loads the images - parses
>> the
>> header
>> CHG cosmetic
>> ADD do_reset() implementation for omap-common spl
>> ADD nand_copy_image to nand.h
>> ADD CPP barriers for mmc and nand support. The parts depending on library
>> support are only compiled if the respective library is included.
>>
>> V3 changes:
>> ADD Comment why setup_clocks_for_console() isn't called for OMAP3
>> CHG cosmetic (deleted empty line)
>> CHG rename of NAND_MODE_HW to NAND_MODE_HW_ECC
>> DEL NAND_MODE_SW. Not used.
>>
>> V4 changes:
>> CHG cosmetic - style problems
>>
>> V5 changes:
>> CHG renamed nand_copy_image to nand_spl_load_image
>> CHG offs paramter of nand_spl_load_image is of type loff_t now
>>
>> V6 changes:
>> ADD call to nand_deselect after loading the images
>> ADD nand_deselect to nand.h
>>
>> V7 changes:
>> DEL some CONFIG_SPL_* relying on garbage collection now
>> ADD mmc_load_image and nand_load_image now have
>> __attribute__((unused)) to
>> prevent warnings when the lib is not added to SPL
>> DEL do_reset() isn't used anymore
>> CHG header based loading in SPL
>>
>> V8 changes:
>> DEL nand_spl_read_page is replaced by nand_spl_load_image with
>> size=page size
>>
>> Transition from V1 to V2 also includes that this patch is now based on
>> - the new SPL layout by Aneesh V and Daniel Schwierzeck
>> - the OMAP4 SPL patches by Aneesh V
>> ---
>> arch/arm/cpu/armv7/omap-common/spl.c | 46
>> +-
>> arch/arm/include/asm/omap_common.h | 1 +
>> include/nand.h | 3 ++
>> 3 files changed, 49 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
>> b/arch/arm/cpu/armv7/omap-common/spl.c
>> index 1d301f4..53d10bf 100644
>> --- a/arch/arm/cpu/armv7/omap-common/spl.c
>> +++ b/arch/arm/cpu/armv7/omap-common/spl.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -173,7 +174,7 @@ end:
>> hang();
>> }
>> }
>> -
>> +static void mmc_load_image(void) __attribute__((unused));
>> static void mmc_load_image(void)
>> {
>> struct mmc *mmc;
>> @@ -207,12 +208,48 @@ static void mmc_load_image(void)
>> }
>> }
>>
>> +#ifdef CONFIG_SPL_NAND_SUPPORT
>> +static void nand_load_image(void) __attribute__ ((unused));
>> +static void nand_load_image(void)
>> +{
>> + struct image_header *header;
>> +
>> + gpmc_init();
>> + nand_init();
>> +
>> + /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
>> + header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
>> +
>> +#ifdef CONFIG_NAND_ENV_DST
>> + nand_spl_load_image(CONFIG_ENV_OFFSET,
>> + CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
>> + parse_image_header(header);
>> + nand_spl_load_image(CONFIG_ENV_OFFSET, image_size,
>> + (void *)image_load_addr);
>> +#ifdef CONFIG_ENV_OFFSET_REDUND
>> + nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
>> + CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
>> + parse_image_header(header);
>> + nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, image_size,
>> + (void *)image_load_addr);
>> +#endif
>> +#endif
>
> Can you please explain the logic here. What are you loading here?
This is from the old nand_spl.c. AFAIK this is to load the environment
from NAND to RAM. I kept this to not break boards using it - although
there has to be some other mechanism for this because it is only used in
smdk6400.h.
The REDUND part does the same for a redundant copy. (docs say: to have a
working copy if power fails while doing saveenv).
>
> br,
> Aneesh
Regards
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache
Hi Hong Xu,
Le 08/08/2011 05:20, Hong Xu a écrit :
> After DMA operation, we need to maintain D-Cache coherency.
> So that the DCache must be invalidated (hence CPU will fetch
> data written by DMA controller from RAM).
>
> Tested on AT91SAM9261EK with Peripheral DMA controller.
>
> Signed-off-by: Hong Xu
> Tested-by: Elen Song
> CC: Albert Aribaud
> CC: Aneesh V
> CC: Reinhard Meyer
> CC: Heiko Schocher
> ---
> V2:
>Per Albert's suggestion, add invalidate_dcache_range
>
> V3:
>invalidate_dcache_range emits warning when detecting unaligned buffer
>
>invalidate_dcache_range won't clean any adjacent cache line when detecting
>unaligned buffer and only round up/down the buffer address
> + mva = start;
> + if ((mva& (cache_line_len - 1)) != 0) {
> + printf("WARNING: %s - unaligned buffer detected, starting "
I'd rather have a message about "cache", not "buffer", e.g.
printf("WARNING: %s - start address %x is not aligned\n"
__FUNCTION__, start);
> + mva&= ~(cache_line_len - 1);
> + }
> + if ((stop& (cache_line_len - 1)) != 0) {
> + printf("WARNING: %s - unaligned buffer detected, ending "
> + "address: 0x%08x\n", __FUNCTION__, stop);
Ditto.
> + stop = (stop | (cache_line_len - 1)) + 1;
> + }
> +
> + while (mva< stop) {
> + asm("mcr p15, 0, %0, c7, c6, 1" : : "r"(mva));
> + mva += cache_line_len;
> + }
Thinking more about the degenerate case -- why not round *up* the start
address, and round *down* the stop address, that is, *reduce* the area
to the aligned portion rather than *expand* it into the unknown? That
would make data in "partially owned" cache lines safe from unwanted
invalidation. OTOH, it would not completely invalidate the caller's
data, but at least the malfunction would appear in the faulty calling
code, not elsewhere.
Opinions?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 8/9] omap3: implement boot parameter saving
Hi Aneesh,
On 08/05/2011 09:41 AM, Aneesh V wrote:
> Hi Simon,
>
> On Tuesday 02 August 2011 09:29 PM, Simon Schwarz wrote:
>> Implements the saving of boot params passed by OMAP3 ROM code.
>>
>> Signed-off-by: Simon Schwarz
>> ---
>> Didn't exist before V8
>> ---
>> arch/arm/cpu/armv7/omap-common/spl.c | 6 +-
>> arch/arm/cpu/armv7/omap3/lowlevel_init.S | 9 +++--
>> arch/arm/include/asm/omap_common.h | 10 ++
>> 3 files changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
>> b/arch/arm/cpu/armv7/omap-common/spl.c
>> index 53d10bf..3dd8e0d 100644
>> --- a/arch/arm/cpu/armv7/omap-common/spl.c
>> +++ b/arch/arm/cpu/armv7/omap-common/spl.c
>> @@ -194,8 +194,12 @@ static void mmc_load_image(void)
>> printf("spl: mmc init failed: err - %d\n", err);
>> hang();
>> }
>> -
>> +/* For OMAP3 there is no automatic boot mode detection */
>> +#ifdef CONFIG_OMAP34XX
>> + boot_mode = CONFIG_SYS_MMC_SD_BOOTMODE;
>> +#else
>> boot_mode = omap_boot_mode();
>> +#endif
>
> Why boot mode detection is not supported? You seem to be saving
> bootparams below that has boot mode information. Why don't you use it?
>
Because you wrote: "What I have done for OMAP4 will not work for OMAP3.
For OMAP3 you will
get only the boot-device(eMMC, MMC/SD, nand etc) and *not* the bootmode(raw
vs FAT)."
http://mid.gmane.org/4e256783.5080...@ti.com
Did I understand you wrong here?
> best regards,
> Aneesh
Regards
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix wrong loop bound in flush_cache() when "size" is zero.
The issue is found when calling flush_cache() with zero "size" argument.
The bound of loop is miscalculated in this case and flush_cache() enters a
wrong flushing loop.
To fix this issue I skipped the operations when "size" is found to be zero.
Signed-off-by: Yao Cheng
Cc: Shinya Kuribayashi
---
arch/mips/cpu/mips32/cpu.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/mips/cpu/mips32/cpu.c b/arch/mips/cpu/mips32/cpu.c
index 3ae397c..1bf0094 100644
--- a/arch/mips/cpu/mips32/cpu.c
+++ b/arch/mips/cpu/mips32/cpu.c
@@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
void flush_cache(ulong start_addr, ulong size)
{
+ /* aend will be miscalculated when size is zero, so we need return here */
+ if (size == 0) {
+return;
+ }
+
unsigned long lsize = CONFIG_SYS_CACHELINE_SIZE;
unsigned long addr = start_addr & ~(lsize - 1);
unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] new tool mkenvimage: generates an env image from an arbitrary config file
Hi,
On 08/06/2011 01:18 PM, Mike Frysinger wrote:
> On Fri, Aug 5, 2011 at 09:23, David Wagner wrote:
>> +#include
>
> this is not portable. include compiler.h and use the already existing
> uswap/cpu_to/to_cpu/etc... helpers.
>
>> +static void usage(void)
>> +{
>> + printf("envcrc [-h] [-r] [-b] -s -o "
>
> funny, "envcrc" isnt what the filename actually is ...
ah, yes, it began as an attempt to extend envcrc but ended up fairly
different.
> seems like this should also take a padding byte so people can use a
> more sensible 0xff rather than 0x00
Thomas told me that when padding with 0xff, his environment image
wouldn't be taken into account anymore.
I'll add the option anyway, but do you know what could be happening ?
Also, I guess this makes necessary making sure there is a \0 after the
last configuration line.
>> + if (fwrite(dataptr, 1, datasize, bin_file) != datasize) {
>
> funny enough, you got the size/nemb args in the right order here ;)
> -mike
I wasn't sure whether the proper way of doing it was "read/write 1 byte,
N times" or "read/write the size of the file, 1 time". I probably
changed my mine in between.
Thanks for reviewing ;
David.
--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Hi Albert, On Sunday 07 August 2011 12:25 PM, Albert ARIBAUD wrote: > Hi Aneesh, > > (cutting quotation for readability) > > Le 05/08/2011 16:59, Aneesh V a écrit : >> Hi Albert, > >> I don't dispute that having buffers aligned is the ideal scenario. The >> question is about error-handling the situation when this requirement is >> not met. > > I understand what you're trying to achieve in this respect, that is, > make the code as correct as it can be under unspecified conditions. I > believe we are differing in how we construe 'as correct as it can be': > you want to make the implementation of the called function as correct as > it can be' at the expense of introducing a non-intuitive behavior (flush > while invalidating), while I prefer the overall system to be as correct > as it can be by 'doing exactly what it says on the tin', i.e. > invalidating only. I understand your point of view now. I shall update my cache fix series to invalidate only the aligned part of the buffer and to print a big warning when the buffer is not aligned. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem with mpc837x start.S
> From: programas...@hotmail.com > To: scottw...@freescale.com > CC: u-boot@lists.denx.de > Subject: RE: [U-Boot] problem with mpc837x start.S > Date: Thu, 4 Aug 2011 11:37:02 + > > > > > > > Date: Wed, 3 Aug 2011 10:48:39 -0500 > > From: scottw...@freescale.com > > To: programas...@hotmail.com > > CC: u-boot@lists.denx.de > > Subject: Re: [U-Boot] problem with mpc837x start.S > > > > On Wed, 3 Aug 2011 00:48:32 + > > shawn Bai wrote: > > > > > > > > > Date: Tue, 2 Aug 2011 10:21:09 -0500 > > > > From: scottw...@freescale.com > > > > To: programas...@hotmail.com > > > > CC: u-boot@lists.denx.de > > > > Subject: Re: [U-Boot] problem with mpc837x start.S > > > > > > > > On Tue, 2 Aug 2011 04:11:25 + > > > > shawn Bai wrote: > > > > > > > > > > When flash is enlarged to 4GiB, it repeats throughout the address > > > > > > space. > > > > > > > > > > After flash is enlarged to 4GiB, why will it repeat through the > > > > > address space? the whole 4GiB address space?How does it happen? > > > > > > > > It's just how the hardware works -- the flash chip only sees the address > > > > bits that are relevant to its size. The higher address lines can be > > > There must be something needed to learnt by myself to understand "how the > > > hardware works". > > > And, when you mention "its size", you mean 8MBytes,or 4GiB? > > > > If the flash is 8MiB (as determined by physical reality, not OR0), it only > > decodes the low 23 bits of the address. The upper bits must hit in BR0/OR0, > > but after that they are discarded. So for example, if OR0 maps a 4GiB > > window, 0x00123456, 0x00923456, 0xff123456, and 0xe0123456 all point to the > > same location in flash, because the flash only sees 0x123456. > > > > -Scott > > > > When enlarging Nor Flash to 4GiB, the AM in OR0 is 0x_0, where the number > of zero is 17. > > According to what is said in datasheet, if the bit value of some bit in > address mask is 0, > then the corresponding bit in address will be masked. > > So, the higher 17 bits in address will be masked, is it right ? > > If so, the range accessed in flash is just 32KBytes from the BA in BR0. > Is that right ? But Not the same with what you mean. > > And from what you replied before in this question, may I say the 32KBytes > will repeat through 4GiB address space ? not 8MBytes ? > > And with the effect of address mask in OR, as you say above, the higher bits > is masked. > Now, we go back to CONFIG_SYS_MONITOR_BASE + in_flash, whatever value of the > sum is, higher of it will be masked, > > so the label 'in_flash' will be located in flash, that is, > both "in_flash" and "CONFIG_SYS_MONITOR_BASE + in_flash" can locate at where > in_flash is in flash. > > Even branching to location CONFIG_SYS_MONITOR_BASE + in_flash, it's the > instruction that locates at "in_flash" to be run. > > then, what is the effect of CONFIG_SYS_MONITOR_BASE in this ABSOLUTE branch > as uboot comment indicates ? > > Thanks. > > -Shawn > Hello, Scott, are you there? Or is there anyone else who can help me With this question? I become confused... Come on, guys. -Shawn > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] new tool mkenvimage: generates an env image from an arbitrary config file
Hi David,
Le 08/08/2011 10:16, David Wagner a écrit :
>>> +static void usage(void)
>>> +{
>>> + printf("envcrc [-h] [-r] [-b] -s size> -o "
>>
>> funny, "envcrc" isnt what the filename actually is ...
>
> ah, yes, it began as an attempt to extend envcrc but ended up fairly
> different.
Maybe passing argv[0] to usage() would help deal with the current name
of the executable?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 8/9] omap3: implement boot parameter saving
Hi Simon,
On Monday 08 August 2011 01:33 PM, Simon Schwarz wrote:
> Hi Aneesh,
>
> On 08/05/2011 09:41 AM, Aneesh V wrote:
>> Hi Simon,
>>
>> On Tuesday 02 August 2011 09:29 PM, Simon Schwarz wrote:
>>> Implements the saving of boot params passed by OMAP3 ROM code.
>>>
>>> Signed-off-by: Simon Schwarz
>>> ---
>>> Didn't exist before V8
>>> ---
>>> arch/arm/cpu/armv7/omap-common/spl.c | 6 +-
>>> arch/arm/cpu/armv7/omap3/lowlevel_init.S | 9 +++--
>>> arch/arm/include/asm/omap_common.h | 10 ++
>>> 3 files changed, 22 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
>>> b/arch/arm/cpu/armv7/omap-common/spl.c
>>> index 53d10bf..3dd8e0d 100644
>>> --- a/arch/arm/cpu/armv7/omap-common/spl.c
>>> +++ b/arch/arm/cpu/armv7/omap-common/spl.c
>>> @@ -194,8 +194,12 @@ static void mmc_load_image(void)
>>> printf("spl: mmc init failed: err - %d\n", err);
>>> hang();
>>> }
>>> -
>>> +/* For OMAP3 there is no automatic boot mode detection */
>>> +#ifdef CONFIG_OMAP34XX
>>> + boot_mode = CONFIG_SYS_MMC_SD_BOOTMODE;
>>> +#else
>>> boot_mode = omap_boot_mode();
>>> +#endif
>>
>> Why boot mode detection is not supported? You seem to be saving
>> bootparams below that has boot mode information. Why don't you use it?
>>
>
> Because you wrote: "What I have done for OMAP4 will not work for OMAP3.
> For OMAP3 you will
> get only the boot-device(eMMC, MMC/SD, nand etc) and *not* the bootmode(raw
> vs FAT)."
> http://mid.gmane.org/4e256783.5080...@ti.com
>
> Did I understand you wrong here?
Sorry for the noise. I mistook 'boot_mode' for 'boot_device'. Anyway,
instead of hard-coding this, I would prefer the following approach
taken by x-loader.
1. For eMMC - raw mode
2. For external MMC/SD card - FAT mode.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] new tool mkenvimage: generates an env image from an arbitrary config file
On 08/08/2011 10:46 AM, Albert ARIBAUD wrote:
> Hi David,
>
> Le 08/08/2011 10:16, David Wagner a écrit :
>
+static void usage(void)
+{
+ printf("envcrc [-h] [-r] [-b] -s> size> -o "
>>>
>>> funny, "envcrc" isnt what the filename actually is ...
>>
>> ah, yes, it began as an attempt to extend envcrc but ended up fairly
>> different.
>
> Maybe passing argv[0] to usage() would help deal with the current name
> of the executable?
>
> Amicalement,
Indeed, merci.
--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache
Hi Albert,
On 08/08/2011 04:01 PM, Albert ARIBAUD wrote:
> Hi Hong Xu,
>
> Le 08/08/2011 05:20, Hong Xu a écrit :
>> After DMA operation, we need to maintain D-Cache coherency.
>> So that the DCache must be invalidated (hence CPU will fetch
[...]
>> unaligned buffer and only round up/down the buffer address
>
>> + mva = start;
>> + if ((mva& (cache_line_len - 1)) != 0) {
>> + printf("WARNING: %s - unaligned buffer detected, starting "
>
> I'd rather have a message about "cache", not "buffer", e.g.
>
> printf("WARNING: %s - start address %x is not aligned\n"
> __FUNCTION__, start);
OK
>> + mva&= ~(cache_line_len - 1);
>> + }
>> + if ((stop& (cache_line_len - 1)) != 0) {
>> + printf("WARNING: %s - unaligned buffer detected, ending "
>> + "address: 0x%08x\n", __FUNCTION__, stop);
>
> Ditto.
OK
>> + stop = (stop | (cache_line_len - 1)) + 1;
>> + }
>> +
>> + while (mva< stop) {
>> + asm("mcr p15, 0, %0, c7, c6, 1" : : "r"(mva));
>> + mva += cache_line_len;
>> + }
>
> Thinking more about the degenerate case -- why not round *up* the start
> address, and round *down* the stop address, that is, *reduce* the area
> to the aligned portion rather than *expand* it into the unknown? That
> would make data in "partially owned" cache lines safe from unwanted
> invalidation. OTOH, it would not completely invalidate the caller's
> data, but at least the malfunction would appear in the faulty calling
> code, not elsewhere.
>
> Opinions?
Agree :)
BR,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 3/9] omap-common: add nand spl support
Hi Simon,
On Monday 08 August 2011 01:20 PM, Simon Schwarz wrote:
> Hi Aneesh,
>
> On 08/05/2011 09:30 AM, Aneesh V wrote:
>> Hi Simon,
>>
>> Sorry if my response is late. I was not in office for couple of days.
>
> First day in office since vacation - so no you are not late ;)
>
>>
>> On Tuesday 02 August 2011 09:29 PM, Simon Schwarz wrote:
>>> Add NAND support for the new SPL structure.
>>>
>>> Signed-off-by: Simon Schwarz
>>> ---
>>> This patch didn't exist before V2!
>>>
>>> V2 changes:
>>> ADD Some define-barriers for OMAP3 to only use NAND
>>> ADD nand_load_image() - inits the OMAP gpmc, loads the images - parses
>>> the
>>> header
>>> CHG cosmetic
>>> ADD do_reset() implementation for omap-common spl
>>> ADD nand_copy_image to nand.h
>>> ADD CPP barriers for mmc and nand support. The parts depending on
>>> library
>>> support are only compiled if the respective library is included.
>>>
>>> V3 changes:
>>> ADD Comment why setup_clocks_for_console() isn't called for OMAP3
>>> CHG cosmetic (deleted empty line)
>>> CHG rename of NAND_MODE_HW to NAND_MODE_HW_ECC
>>> DEL NAND_MODE_SW. Not used.
>>>
>>> V4 changes:
>>> CHG cosmetic - style problems
>>>
>>> V5 changes:
>>> CHG renamed nand_copy_image to nand_spl_load_image
>>> CHG offs paramter of nand_spl_load_image is of type loff_t now
>>>
>>> V6 changes:
>>> ADD call to nand_deselect after loading the images
>>> ADD nand_deselect to nand.h
>>>
>>> V7 changes:
>>> DEL some CONFIG_SPL_* relying on garbage collection now
>>> ADD mmc_load_image and nand_load_image now have
>>> __attribute__((unused)) to
>>> prevent warnings when the lib is not added to SPL
>>> DEL do_reset() isn't used anymore
>>> CHG header based loading in SPL
>>>
>>> V8 changes:
>>> DEL nand_spl_read_page is replaced by nand_spl_load_image with
>>> size=page size
>>>
>>> Transition from V1 to V2 also includes that this patch is now based on
>>> - the new SPL layout by Aneesh V and Daniel Schwierzeck
>>> - the OMAP4 SPL patches by Aneesh V
>>> ---
>>> arch/arm/cpu/armv7/omap-common/spl.c | 46
>>> +-
>>> arch/arm/include/asm/omap_common.h | 1 +
>>> include/nand.h | 3 ++
>>> 3 files changed, 49 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
>>> b/arch/arm/cpu/armv7/omap-common/spl.c
>>> index 1d301f4..53d10bf 100644
>>> --- a/arch/arm/cpu/armv7/omap-common/spl.c
>>> +++ b/arch/arm/cpu/armv7/omap-common/spl.c
>>> @@ -26,6 +26,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -173,7 +174,7 @@ end:
>>> hang();
>>> }
>>> }
>>> -
>>> +static void mmc_load_image(void) __attribute__((unused));
>>> static void mmc_load_image(void)
>>> {
>>> struct mmc *mmc;
>>> @@ -207,12 +208,48 @@ static void mmc_load_image(void)
>>> }
>>> }
>>>
>>> +#ifdef CONFIG_SPL_NAND_SUPPORT
>>> +static void nand_load_image(void) __attribute__ ((unused));
>>> +static void nand_load_image(void)
>>> +{
>>> + struct image_header *header;
>>> +
>>> + gpmc_init();
>>> + nand_init();
>>> +
>>> + /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
>>> + header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
>>> +
>>> +#ifdef CONFIG_NAND_ENV_DST
>>> + nand_spl_load_image(CONFIG_ENV_OFFSET,
>>> + CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
>>> + parse_image_header(header);
>>> + nand_spl_load_image(CONFIG_ENV_OFFSET, image_size,
>>> + (void *)image_load_addr);
>>> +#ifdef CONFIG_ENV_OFFSET_REDUND
>>> + nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
>>> + CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
>>> + parse_image_header(header);
>>> + nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, image_size,
>>> + (void *)image_load_addr);
>>> +#endif
>>> +#endif
>>
>> Can you please explain the logic here. What are you loading here?
>
> This is from the old nand_spl.c. AFAIK this is to load the environment
> from NAND to RAM. I kept this to not break boards using it - although
> there has to be some other mechanism for this because it is only used in
> smdk6400.h.
>
> The REDUND part does the same for a redundant copy. (docs say: to have a
> working copy if power fails while doing saveenv).
Hmm. Looks like this was a support added by the commit b74ab737. So, we
are pre-loading the ENV for u-boot here.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Le 08/08/2011 10:24, Aneesh V a écrit : > Hi Albert, > > On Sunday 07 August 2011 12:25 PM, Albert ARIBAUD wrote: >> Hi Aneesh, >> >> (cutting quotation for readability) >> >> Le 05/08/2011 16:59, Aneesh V a écrit : >>> Hi Albert, >> >>> I don't dispute that having buffers aligned is the ideal scenario. The >>> question is about error-handling the situation when this requirement is >>> not met. >> >> I understand what you're trying to achieve in this respect, that is, >> make the code as correct as it can be under unspecified conditions. I >> believe we are differing in how we construe 'as correct as it can be': >> you want to make the implementation of the called function as correct as >> it can be' at the expense of introducing a non-intuitive behavior (flush >> while invalidating), while I prefer the overall system to be as correct >> as it can be by 'doing exactly what it says on the tin', i.e. >> invalidating only. > > I understand your point of view now. I shall update my cache fix series > to invalidate only the aligned part of the buffer and to print a big > warning when the buffer is not aligned. Thanks Aneesh. Another point I raised with Hong Xu's patch: for range-limited operations, in case of a misalignment, why not try to *reduce* to aligned addresses rather than *expand* it? Moving start up to the next cache line boundary, and moving stop down, would still cause an imperfect situation (can't help it anyway) but it would not affect third party data any more, only the data which the cache range operation was supposed to affect. What do you (and others) think? > best regards, > Aneesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Hi Albert, On Monday 08 August 2011 03:09 PM, Albert ARIBAUD wrote: > Le 08/08/2011 10:24, Aneesh V a écrit : >> Hi Albert, >> >> On Sunday 07 August 2011 12:25 PM, Albert ARIBAUD wrote: >>> Hi Aneesh, >>> >>> (cutting quotation for readability) >>> >>> Le 05/08/2011 16:59, Aneesh V a écrit : Hi Albert, >>> I don't dispute that having buffers aligned is the ideal scenario. The question is about error-handling the situation when this requirement is not met. >>> >>> I understand what you're trying to achieve in this respect, that is, >>> make the code as correct as it can be under unspecified conditions. I >>> believe we are differing in how we construe 'as correct as it can be': >>> you want to make the implementation of the called function as correct as >>> it can be' at the expense of introducing a non-intuitive behavior (flush >>> while invalidating), while I prefer the overall system to be as correct >>> as it can be by 'doing exactly what it says on the tin', i.e. >>> invalidating only. >> >> I understand your point of view now. I shall update my cache fix series >> to invalidate only the aligned part of the buffer and to print a big >> warning when the buffer is not aligned. > > Thanks Aneesh. > > Another point I raised with Hong Xu's patch: for range-limited > operations, in case of a misalignment, why not try to *reduce* to > aligned addresses rather than *expand* it? Moving start up to the next > cache line boundary, and moving stop down, would still cause an > imperfect situation (can't help it anyway) but it would not affect third > party data any more, only the data which the cache range operation was > supposed to affect. > > What do you (and others) think? I agree. Indeed this is what I meant when I wrote this above: "invalidate *only the aligned part* of the buffer" best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Assalamualaikum
Dear I'm Rosenani binti abd rahman,i work as Marketing Officer with a Gemstones Processing Company in London. i will like to introduce you to this business opportunity. i need your urgent assistance, which will be a benefit to both of us financially. i am contacting you because i don't want to lose this contract provided by our company because we both going to get a good profit from this business in the coming future. That's why i am requesting you to be the supplier to our company so that we can both take advantage of this business opportunity in the company now. Currently our company needs a three(3)years constant supplier of a product called (ANDRADITE SOLID FLUID ) which is a new scientific chemical fluid substance, its of lubricant, mainly used in the gemological laboratory for the purification of diamonds clarity treatment, generally what this fluid does is to penetrate deep into diamond and vaporizes out black inclusions in Diamonds and other precious stones.The original l supplier of these product is in (Malaysia) and former supplier of this product to our company has finished his contract and our company is looking for any other person who can be able to supply the (Andradite solid fluid) in large quantity so that to meet the demand of our consumers and merge into partnership with the company presently. The main reason why i am writing you seeking your interest for assistance, i just want you to act as an intermediary agent to stand the gap between the (sellers of the product in Malaysia and the buyers) (our company). this is a big business, which will be of good dividends to both of us. i only need your cooperation to make this business successful. I will give you more information about this if you are willing to stand as the agent to supply my company the product.Firstly, i will like to secure a supply contract deal for you as a supplier to the company where i work. Based on percentage, originally the actual purchasing price of this chemical by the company per carton is about USD4,000.00 if i convert it to US dollars while in Malaysia the local selling price is USD2,100.00 and our company needs not less than 200 cartons. The reason why i want you to be our agent is to be the link connecting the local seller in Malaysia directly to the buying company then the profit margin will be shared by both of us 60% to you while 40% to me. Your major assistance for me is just for you to talk to our company director that you can supply the company the product and to also go in details in terms of price and mode of payment then we can pick up from that point. Please get back to me as soon as you receive my email if you are interested and willing to do business with me so that i can give you the local seller's contact in Malaysia so that you can contact her to ask if she has this product in stock to supply to you. Before our company sends the purchasing manager down to Malaysia to purchase the product from you directly. Thanks for your co-operation. am waiting to hear from you soon. Regard's Rosenani binti abd rahman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Dear Albert, Aneesh, Hong, There seem to be functions of type xxx(start, end) and xxx(start, size). Can't it be somehow decided to use only one variant in all cases (flush, invalidate)? On a personal taste, I'd prefer (start, size) :) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SMDKV310: MMC SPL: Remove unwanted dummy functions
Dear Chander Kashyap, On 28 July 2011 15:36, Chander Kashyap wrote: > Removed dummy functions in "mmc_spl/board/samsung/smdkv310/mmc_boot.c", > @mmc_boot.c > void do_undefined_instruction(struct pt_regs *pt_regs); > void do_software_interrupt(struct pt_regs *pt_regs); > void do_prefetch_abort(struct pt_regs *pt_regs); > void do_data_abort(struct pt_regs *pt_regs); > void do_not_used(struct pt_regs *pt_regs); > void do_fiq(struct pt_regs *pt_regs); > void do_irq(struct pt_regs *pt_regs); > > not required as called conditionally in start.S > @start.S > \#ifdef CONFIG_SPL_BUILD > _undefined_instruction: .word _undefined_instruction > _software_interrupt: .word _software_interrupt > _prefetch_abort: .word _prefetch_abort > _data_abort: .word _data_abort > _not_used: .word _not_used > _irq: .word _irq > _fiq: .word _fiq > _pad: .word 0x12345678 /* now 16*4=64 */ > \#else > _undefined_instruction: .word undefined_instruction > _software_interrupt: .word software_interrupt > _prefetch_abort: .word prefetch_abort > _data_abort: .word data_abort > _not_used: .word not_used > _irq: .word irq > _fiq: .word fiq > _pad: .word 0x12345678 /* now 16*4=64 */ > \#endif > e.g. > undefined_instruction: > get_bad_stack > bad_save_user_regs > bl do_undefined_instruction > > Signed-off-by: Chander Kashyap > --- > mmc_spl/board/samsung/smdkv310/Makefile | 1 + > mmc_spl/board/samsung/smdkv310/mmc_boot.c | 30 > - > 2 files changed, 1 insertions(+), 30 deletions(-) > applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Hi Reinhard, On Monday 08 August 2011 03:29 PM, Reinhard Meyer wrote: > Dear Albert, Aneesh, Hong, > > There seem to be functions of type > > xxx(start, end) and xxx(start, size). > > Can't it be somehow decided to use only one variant > in all cases (flush, invalidate)? The u-boot standard seems to be xxx(start, end) where the operation will be done on the range [start, end). This is what I figured out by looking at the prototypes and existing implementations when I did the armv7 work and I have stuck to this standard. Hong also seems to be following the same standard. If there is no objection, I shall add this definition to the README I am adding. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Hi Aneesh, > On Monday 08 August 2011 03:29 PM, Reinhard Meyer wrote: >> Dear Albert, Aneesh, Hong, >> >> There seem to be functions of type >> >> xxx(start, end) and xxx(start, size). >> >> Can't it be somehow decided to use only one variant >> in all cases (flush, invalidate)? > > The u-boot standard seems to be xxx(start, end) where the operation > will be done on the range [start, end). This is what I figured out by > looking at the prototypes and existing implementations when I did the > armv7 work and I have stuck to this standard. > > Hong also seems to be following the same standard. > > If there is no objection, I shall add this definition to the README I > am adding. Maybe its arch specific, I just saw this in another thread, thats why I asked: +++ b/arch/mips/cpu/mips32/cpu.c @@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) void flush_cache(ulong start_addr, ulong size) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Hi Reinhard, On Monday 08 August 2011 03:55 PM, Reinhard Meyer wrote: > Hi Aneesh, >> On Monday 08 August 2011 03:29 PM, Reinhard Meyer wrote: >>> Dear Albert, Aneesh, Hong, >>> >>> There seem to be functions of type >>> >>> xxx(start, end) and xxx(start, size). >>> >>> Can't it be somehow decided to use only one variant >>> in all cases (flush, invalidate)? >> >> The u-boot standard seems to be xxx(start, end) where the operation >> will be done on the range [start, end). This is what I figured out by >> looking at the prototypes and existing implementations when I did the >> armv7 work and I have stuck to this standard. >> >> Hong also seems to be following the same standard. >> >> If there is no objection, I shall add this definition to the README I >> am adding. > > Maybe its arch specific, I just saw this in another thread, thats why I asked: > > > +++ b/arch/mips/cpu/mips32/cpu.c > @@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * > const argv[]) > > void flush_cache(ulong start_addr, ulong size) I think the confusion about flush_cache() is because in include/common.h the prototype for flush_cache() doesn't have names for the paramaeters. It's like this: voidflush_cache (unsigned long, unsigned long); However, the invalidate and flush range functions are clearly defined: voidflush_dcache_range(unsigned long start, unsigned long stop); voidinvalidate_dcache_range(unsigned long start, unsigned long stop); I don't know what to do about flush_cache() now that it seems to have conflicting implementations. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 8/9] omap3: implement boot parameter saving
On 08/08/2011 10:44 AM, Aneesh V wrote:
> Hi Simon,
>
> On Monday 08 August 2011 01:33 PM, Simon Schwarz wrote:
>> Hi Aneesh,
>>
>> On 08/05/2011 09:41 AM, Aneesh V wrote:
>>> Hi Simon,
>>>
>>> On Tuesday 02 August 2011 09:29 PM, Simon Schwarz wrote:
Implements the saving of boot params passed by OMAP3 ROM code.
Signed-off-by: Simon Schwarz
---
Didn't exist before V8
---
arch/arm/cpu/armv7/omap-common/spl.c | 6 +-
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 9 +++--
arch/arm/include/asm/omap_common.h | 10 ++
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index 53d10bf..3dd8e0d 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -194,8 +194,12 @@ static void mmc_load_image(void)
printf("spl: mmc init failed: err - %d\n", err);
hang();
}
-
+/* For OMAP3 there is no automatic boot mode detection */
+#ifdef CONFIG_OMAP34XX
+ boot_mode = CONFIG_SYS_MMC_SD_BOOTMODE;
+#else
boot_mode = omap_boot_mode();
+#endif
>>>
>>> Why boot mode detection is not supported? You seem to be saving
>>> bootparams below that has boot mode information. Why don't you use it?
>>>
>>
>> Because you wrote: "What I have done for OMAP4 will not work for OMAP3.
>> For OMAP3 you will
>> get only the boot-device(eMMC, MMC/SD, nand etc) and *not* the
>> bootmode(raw
>> vs FAT)."
>> http://mid.gmane.org/4e256783.5080...@ti.com
>>
>> Did I understand you wrong here?
>
> Sorry for the noise. I mistook 'boot_mode' for 'boot_device'. Anyway,
> instead of hard-coding this, I would prefer the following approach
> taken by x-loader.
>
> 1. For eMMC - raw mode
> 2. For external MMC/SD card - FAT mode.
done.
> best regards,
> Aneesh
Regards
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Hi Aneesh, On 08/08/2011 12:27, Aneesh V wrote: > Hi Reinhard, > > On Monday 08 August 2011 03:55 PM, Reinhard Meyer wrote: >> Hi Aneesh, >>> On Monday 08 August 2011 03:29 PM, Reinhard Meyer wrote: Dear Albert, Aneesh, Hong, There seem to be functions of type xxx(start, end) and xxx(start, size). Can't it be somehow decided to use only one variant in all cases (flush, invalidate)? >>> >>> The u-boot standard seems to be xxx(start, end) where the operation >>> will be done on the range [start, end). This is what I figured out by >>> looking at the prototypes and existing implementations when I did the >>> armv7 work and I have stuck to this standard. >>> >>> Hong also seems to be following the same standard. >>> >>> If there is no objection, I shall add this definition to the README I >>> am adding. >> >> Maybe its arch specific, I just saw this in another thread, thats why >> I asked: >> >> >> +++ b/arch/mips/cpu/mips32/cpu.c >> @@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, >> char * const argv[]) >> >> void flush_cache(ulong start_addr, ulong size) > > I think the confusion about flush_cache() is because in > include/common.h the prototype for flush_cache() doesn't have names for > the paramaeters. It's like this: > > void flush_cache (unsigned long, unsigned long); > > However, the invalidate and flush range functions are clearly defined: > > void flush_dcache_range(unsigned long start, unsigned long stop); > void invalidate_dcache_range(unsigned long start, unsigned long stop); > > I don't know what to do about flush_cache() now that it seems to have > conflicting implementations. My opinion is that global cache functions should not have arguments at all and should act on the full cache. Note that drivers should only use range versions, not global versions; the only places I see global cache actions occurring are initialization when invalidating the whole cache just before enabling it, and control transfer to an OS where the whole cache should be flushed, invalidated and then disabled before jumping to the OS. So here, if any arch has cache functions that are non-global but don't have "range" in their names, that should be changed. Also, any function with only parameter types have parameter names added (cosmetic patch welcome for anything of this kind in ARM). > best regards, > Aneesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: Fix 'Unknown OMAP image type - 5'
Hi Dirk, On Saturday 06 August 2011 12:12 AM, Dirk Behme wrote: > From: Dirk Behme > > Using mkimage with e.g. > > tools/mkimage -A arm -T firmware -O u-boot -d u-boot.bin foo.img > > gives a warning > > "Unknown OMAP image type - 5" > > while it seems that the image itself is created successfully. > > This does come from the patch "mkimage: Add OMAP boot image support". > > Reordering the init_xx_image_type() sequence does make this > message go away. This solves the problem for me too. Tested-by: Aneesh V best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix wrong loop bound in flush_cache() when "size" is zero.
Hello.
On 08-08-2011 12:07, Yao Cheng wrote:
> The issue is found when calling flush_cache() with zero "size" argument.
> The bound of loop is miscalculated in this case and flush_cache() enters a
> wrong flushing loop.
> To fix this issue I skipped the operations when "size" is found to be zero.
> Signed-off-by: Yao Cheng
> Cc: Shinya Kuribayashi
> ---
> arch/mips/cpu/mips32/cpu.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
> diff --git a/arch/mips/cpu/mips32/cpu.c b/arch/mips/cpu/mips32/cpu.c
> index 3ae397c..1bf0094 100644
> --- a/arch/mips/cpu/mips32/cpu.c
> +++ b/arch/mips/cpu/mips32/cpu.c
> @@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
> const argv[])
>
> void flush_cache(ulong start_addr, ulong size)
> {
> + /* aend will be miscalculated when size is zero, so we need return here */
> + if (size == 0) {
> +return;
> + }
> +
Please indent with tabs, not spaces. Also, doesn't this code generate
warning (code before declarations)?
> unsigned long lsize = CONFIG_SYS_CACHELINE_SIZE;
> unsigned long addr = start_addr& ~(lsize - 1);
> unsigned long aend = (start_addr + size - 1)& ~(lsize - 1);
WBR, Sergei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V9 0/9] OMAP3 and devkit8000 SPL support
V1 Initial SPL support for OMAP3 was based on the old SPL V2 Introduced major changes. It is based on the OMAP4-SPL patch by Aneesh V and the new SPL Framework by Daniel Schwierzeck and Aneesh V V3 Some small bug fixes and correct placed SOB. V4 Corrected one bugfix and some style problems V5 Exclude some nand objects from SPL, interface change for nand_spl V6 Added nand_spl.c - git add mistake, some small changes V7 integrates "[PATCH V0] omap-common: move early UART clock setup to board.c", rewrite of image loading to use image headers, removed many #ifdefs, use read functions from nand_base.c, some smaller changes V8 added boot parameter saving (was not implemented before V8!), added define CONFIG_SPL_NAND_SIMPLE, reorganization of omap-common SPL V9 added missing file. Changes in boot_mode This is based on the following patches: - New SPL framework (in u-boot-ti) - OMAP4 SPL (in u-boot-ti) Simon Schwarz (9): omap-common/omap4: relocate early UART clock setup omap3: Configure RAM bank 0 if in SPL omap-common: add nand spl support spl: add NAND Library to new SPL spl: Add POWER library to new spl omap3: new SPL structure support devkit8000: Add nand-spl support for new SPL omap3: implement boot parameter saving omap-common: reorganize spl.c arch/arm/cpu/armv7/omap-common/Makefile |6 + arch/arm/cpu/armv7/omap-common/spl.c| 165 +++--- arch/arm/cpu/armv7/omap-common/spl_mmc.c| 150 arch/arm/cpu/armv7/omap-common/spl_nand.c | 71 arch/arm/cpu/armv7/omap3/board.c| 50 ++- arch/arm/cpu/armv7/omap3/config.mk | 30 arch/arm/cpu/armv7/omap3/lowlevel_init.S| 10 + arch/arm/cpu/armv7/omap3/sdrc.c | 32 - arch/arm/cpu/armv7/omap4/board.c|1 + arch/arm/include/asm/arch-omap3/mem.h | 36 arch/arm/include/asm/arch-omap3/sys_proto.h |1 + arch/arm/include/asm/omap_common.h | 31 board/timll/devkit8000/devkit8000.c |2 +- doc/README.SPL |2 + drivers/mtd/nand/Makefile | 10 +- drivers/mtd/nand/nand_base.c|4 +- drivers/mtd/nand/nand_spl_simple.c | 245 +++ drivers/mtd/nand/omap_gpmc.c| 27 +++ include/configs/devkit8000.h| 46 + include/nand.h |6 + spl/Makefile|2 + 21 files changed, 782 insertions(+), 145 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/spl_mmc.c create mode 100644 arch/arm/cpu/armv7/omap-common/spl_nand.c create mode 100644 arch/arm/cpu/armv7/omap3/config.mk create mode 100644 drivers/mtd/nand/nand_spl_simple.c -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V9 1/9] omap-common/omap4: relocate early UART clock setup
Moves the early UART clock setup setup_clocks_for_console() from
preloader_console_init() to s_init() of OMAP4.
This is done to prepare for OMAP3 integration.
This patch was posted seperatly to the mailinglist but I decidet - since it is
a prereqesit for this patch to add it. Former port to ML:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/104395
Signed-off-by: Simon Schwarz
---
Did not exist before V7.
V8 changes:
nothing
V9 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl.c |2 +-
arch/arm/cpu/armv7/omap4/board.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index d177652..1d301f4 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -249,6 +249,7 @@ void board_init_r(gd_t *id, ulong dummy)
}
}
+/* This requires UART clocks to be enabled */
void preloader_console_init(void)
{
const char *u_boot_rev = U_BOOT_VERSION;
@@ -259,7 +260,6 @@ void preloader_console_init(void)
gd->flags |= GD_FLG_RELOC;
gd->baudrate = CONFIG_BAUDRATE;
- setup_clocks_for_console();
serial_init(); /* serial communications setup */
/* Avoid a second "U-Boot" coming from this string */
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c
index 5943d61..a9e90de 100644
--- a/arch/arm/cpu/armv7/omap4/board.c
+++ b/arch/arm/cpu/armv7/omap4/board.c
@@ -196,6 +196,7 @@ void s_init(void)
watchdog_init();
set_mux_conf_regs();
#ifdef CONFIG_SPL_BUILD
+ setup_clocks_for_console();
preloader_console_init();
#endif
prcm_init();
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V9 2/9] omap3: Configure RAM bank 0 if in SPL
OMAP3 relied on the memory config done by X-loader or Configuration Header. This
has to be reworked for the implementation of a SPL. This patch configures RAM
bank 0 if CONFIG_SPL_BUILD is set. Settings for Micron-RAM used by devkit8000
are added to mem.h
Signed-off-by: Simon Schwarz
---
V1 changes:
ADD Settings for Micron RAM
V2 changes:
DEL spl_debug outputs if mem test fails/passes
CHG CONFIG_PRELOADER to CONFIG_SPL_BUILD
V3 changes:
nothing
V4 changes:
nothing
V5 changes:
nothing
V6 changes:
nothing
V7 changes:
DEL unnecessary #fidef CONFIG_SPL_BUILD
ADD comment on why we need the ifdef in sdrc.c
V8 changes:
nothing
V9 changes:
nothing
Transition from V1 to V2 also includes that this patch is now based on
- the new SPL layout by Aneesh V and Daniel Schwierzeck
- the OMAP4 SPL patches by Aneesh V
This is the successor of "[U-Boot,3/5] devkit8000 nand_spl: Add RAM
configuration independent of x-loader or CH"
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102114)
---
arch/arm/cpu/armv7/omap3/sdrc.c | 32 -
arch/arm/include/asm/arch-omap3/mem.h | 36 +
2 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c
index 2a7970b..0dd1955 100644
--- a/arch/arm/cpu/armv7/omap3/sdrc.c
+++ b/arch/arm/cpu/armv7/omap3/sdrc.c
@@ -8,6 +8,9 @@
* Copyright (C) 2004-2010
* Texas Instruments Incorporated - http://www.ti.com/
*
+ * Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz
+ *
* Author :
* Vaibhav Hiremath
*
@@ -133,13 +136,40 @@ void do_sdrc_init(u32 cs, u32 early)
sdelay(0x2);
}
+/* As long as V_MCFG and V_RFR_CTRL is not defined for all OMAP3 boards we need
+ * to prevent this to be build in non-SPL build */
+#ifdef CONFIG_SPL_BUILD
+ /* If we use a SPL there is no x-loader nor config header so we have
+* to do the job ourselfs
+*/
+ if (cs == CS0) {
+ sdrc_actim_base0 = (struct sdrc_actim *)SDRC_ACTIM_CTRL0_BASE;
+
+ /* General SDRC config */
+ writel(V_MCFG, &sdrc_base->cs[cs].mcfg);
+ writel(V_RFR_CTRL, &sdrc_base->cs[cs].rfr_ctrl);
+
+ /* AC timings */
+ writel(V_ACTIMA_165, &sdrc_actim_base0->ctrla);
+ writel(V_ACTIMB_165, &sdrc_actim_base0->ctrlb);
+
+ /* Initialize */
+ writel(CMD_NOP, &sdrc_base->cs[cs].manual);
+ writel(CMD_PRECHARGE, &sdrc_base->cs[cs].manual);
+ writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
+ writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
+
+ writel(V_MR, &sdrc_base->cs[cs].mr);
+ }
+#endif
+
/*
* SDRC timings are set up by x-load or config header
* We don't need to redo them here.
* Older x-loads configure only CS0
* configure CS1 to handle this ommission
*/
- if (cs) {
+ if (cs == CS1) {
sdrc_actim_base0 = (struct sdrc_actim *)SDRC_ACTIM_CTRL0_BASE;
sdrc_actim_base1 = (struct sdrc_actim *)SDRC_ACTIM_CTRL1_BASE;
writel(readl(&sdrc_base->cs[CS0].mcfg),
diff --git a/arch/arm/include/asm/arch-omap3/mem.h
b/arch/arm/include/asm/arch-omap3/mem.h
index f165949..8e28f77 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -128,6 +128,33 @@ enum {
(MICRON_XSR_165 << 0) | (MICRON_TXP_165 << 8) | \
(MICRON_TWTR_165 << 16))
+#define MICRON_RAMTYPE 0x1
+#define MICRON_DDRTYPE 0x0
+#define MICRON_DEEPPD 0x1
+#define MICRON_B32NOT160x1
+#define MICRON_BANKALLOCATION 0x2
+#define MICRON_RAMSIZE ((PHYS_SDRAM_1_SIZE/(1024*1024))/2)
+#define MICRON_ADDRMUXLEGACY 0x1
+#define MICRON_CASWIDTH0x5
+#define MICRON_RASWIDTH0x2
+#define MICRON_LOCKSTATUS 0x0
+#define MICRON_V_MCFG ((MICRON_LOCKSTATUS << 30) | (MICRON_RASWIDTH << 24) | \
+ (MICRON_CASWIDTH << 20) | (MICRON_ADDRMUXLEGACY << 19) | \
+ (MICRON_RAMSIZE << 8) | (MICRON_BANKALLOCATION << 6) | \
+ (MICRON_B32NOT16 << 4) | (MICRON_DEEPPD << 3) | \
+ (MICRON_DDRTYPE << 2) | (MICRON_RAMTYPE))
+
+#define MICRON_ARCV2030
+#define MICRON_ARE 0x1
+#define MICRON_V_RFR_CTRL ((MICRON_ARCV << 8) | (MICRON_ARE))
+
+#define MICRON_BL 0x2
+#define MICRON_SIL 0x0
+#define MICRON_CASL0x3
+#define MICRON_WBST0x0
+#define MICRON_V_MR ((MICRON_WBST << 9) | (MICRON_CASL << 4) | \
+ (MICRON_SIL << 3) | (MICRON_BL))
+
/*
* NUMONYX part of IGEP v2 (165MHz optimized) 6.06ns
[U-Boot] [PATCH V9 3/9] omap-common: add nand spl support
Add NAND support for the new SPL structure.
Signed-off-by: Simon Schwarz
---
This patch didn't exist before V2!
V2 changes:
ADD Some define-barriers for OMAP3 to only use NAND
ADD nand_load_image() - inits the OMAP gpmc, loads the images - parses the
header
CHG cosmetic
ADD do_reset() implementation for omap-common spl
ADD nand_copy_image to nand.h
ADD CPP barriers for mmc and nand support. The parts depending on library
support are only compiled if the respective library is included.
V3 changes:
ADD Comment why setup_clocks_for_console() isn't called for OMAP3
CHG cosmetic (deleted empty line)
CHG rename of NAND_MODE_HW to NAND_MODE_HW_ECC
DEL NAND_MODE_SW. Not used.
V4 changes:
CHG cosmetic - style problems
V5 changes:
CHG renamed nand_copy_image to nand_spl_load_image
CHG offs paramter of nand_spl_load_image is of type loff_t now
V6 changes:
ADD call to nand_deselect after loading the images
ADD nand_deselect to nand.h
V7 changes:
DEL some CONFIG_SPL_* relying on garbage collection now
ADD mmc_load_image and nand_load_image now have __attribute__((unused)) to
prevent warnings when the lib is not added to SPL
DEL do_reset() isn't used anymore
CHG header based loading in SPL
V8 changes:
DEL nand_spl_read_page is replaced by nand_spl_load_image with size=page size
V9 changes:
ADD comment to mark eMMC
ADD omap_boot_mode-function like in OMAP4
CHG boot_mode is now selected based on the boot device used
Based on:
- the new SPL layout by Aneesh V and Daniel Schwierzeck
- the OMAP4 SPL patches by Aneesh V
---
arch/arm/cpu/armv7/omap-common/spl.c | 46 ++-
arch/arm/cpu/armv7/omap3/board.c | 50 -
arch/arm/include/asm/omap_common.h | 31 +
include/nand.h |3 ++
4 files changed, 127 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index 1d301f4..53d10bf 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -173,7 +174,7 @@ end:
hang();
}
}
-
+static void mmc_load_image(void) __attribute__((unused));
static void mmc_load_image(void)
{
struct mmc *mmc;
@@ -207,12 +208,48 @@ static void mmc_load_image(void)
}
}
+#ifdef CONFIG_SPL_NAND_SUPPORT
+static void nand_load_image(void) __attribute__ ((unused));
+static void nand_load_image(void)
+{
+ struct image_header *header;
+
+ gpmc_init();
+ nand_init();
+
+ /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+
+#ifdef CONFIG_NAND_ENV_DST
+ nand_spl_load_image(CONFIG_ENV_OFFSET,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ parse_image_header(header);
+ nand_spl_load_image(CONFIG_ENV_OFFSET, image_size,
+ (void *)image_load_addr);
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ parse_image_header(header);
+ nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, image_size,
+ (void *)image_load_addr);
+#endif
+#endif
+ /* Load u-boot */
+ nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ parse_image_header(header);
+ nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+ image_size, (void *)image_load_addr);
+ nand_deselect();
+}
+#endif /* CONFIG_SPL_NAND_SUPPORT */
void jump_to_image_no_args(void)
{
typedef void (*image_entry_noargs_t)(void)__attribute__ ((noreturn));
image_entry_noargs_t image_entry =
(image_entry_noargs_t) image_entry_point;
+ debug("image entry point: 0x%X\n", image_entry_point);
image_entry();
}
@@ -228,10 +265,17 @@ void board_init_r(gd_t *id, ulong dummy)
boot_device = omap_boot_device();
debug("boot device - %d\n", boot_device);
switch (boot_device) {
+#ifdef CONFIG_SPL_MMC_SUPPORT
case BOOT_DEVICE_MMC1:
case BOOT_DEVICE_MMC2:
mmc_load_image();
break;
+#endif
+#ifdef CONFIG_SPL_NAND_SUPPORT
+ case BOOT_DEVICE_NAND:
+ nand_load_image();
+ break;
+#endif
default:
printf("SPL: Un-supported Boot Device - %d!!!\n", boot_device);
hang();
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 4aaf97b..39a17bc 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
/* Declarations */
extern omap3_sysinfo sysinfo;
@@ -56,6 +57,41 @@ static const struct gpio_bank gpio_bank_3
[U-Boot] [PATCH V9 5/9] spl: Add POWER library to new spl
Adds power library to the new spl Signed-off-by: Simon Schwarz --- Didn't exist before V7 V8 changes: nothing V9 changes: nothing --- doc/README.SPL |1 + spl/Makefile |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/doc/README.SPL b/doc/README.SPL index ef946ce..2987f43 100644 --- a/doc/README.SPL +++ b/doc/README.SPL @@ -60,4 +60,5 @@ CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o) CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o) CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o) CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o) +CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o) CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o) diff --git a/spl/Makefile b/spl/Makefile index 17d4f7f..0c0d3c4 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -46,6 +46,7 @@ LIBS-$(CONFIG_SPL_SPI_FLASH_SUPPORT) += drivers/mtd/spi/libspi_flash.o LIBS-$(CONFIG_SPL_SPI_SUPPORT) += drivers/spi/libspi.o LIBS-$(CONFIG_SPL_FAT_SUPPORT) += fs/fat/libfat.o LIBS-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/libgeneric.o +LIBS-$(CONFIG_SPL_POWER_SUPPORT) += drivers/power/libpower.o LIBS-$(CONFIG_SPL_NAND_SUPPORT) += drivers/mtd/nand/libnand.o ifeq ($(SOC),omap3) -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V9 6/9] omap3: new SPL structure support
Support for the new spl structure. Using the interface defined by Aneesh V for
OMAP4
Signed-off-by: Simon Schwarz
---
V1 changes:
ADD support for early console output in SPL
V2 changes:
ADD include omap_common.h in board.c
ADD implement new omap common interface omap_boot_device, omap_boot_mode and
omap_rev_string (very basic)
CHG cosmetic
CHG Don't add ecc switch command in SPL
ADD save_boot_params stump with warning to implement it
V3 changes:
none
V4 changes:
CHG cosmetic - corrected style problem
V5 changes:
nothing
V6 changes:
nothing
V7 changes:
ADD copied config.mk from OMAP4 to OMAP3
V8 changes:
CHG boot_mode can't be detected on OMAP3 so the function is not needed
V9 changes:
nothing
Transition from V1 to V2 also includes that this patch is now based on
- the new SPL layout by Aneesh V and Daniel Schwierzeck
- the OMAP4 SPL patches by Aneesh V
This is in some parts a anccesstor of "[U-Boot,2/5] devkit8000 nand_spl: omap3
support nand_spl boot"
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102114) in V1
---
arch/arm/cpu/armv7/omap3/config.mk | 30 +++
arch/arm/cpu/armv7/omap3/lowlevel_init.S|5
arch/arm/include/asm/arch-omap3/sys_proto.h |1 +
3 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/armv7/omap3/config.mk
diff --git a/arch/arm/cpu/armv7/omap3/config.mk
b/arch/arm/cpu/armv7/omap3/config.mk
new file mode 100644
index 000..b34fa64
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap3/config.mk
@@ -0,0 +1,30 @@
+#
+# Copyright 2011 Linaro Limited
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# (C) Copyright 2010
+# Texas Instruments,
+#
+# Aneesh V
+#
+# 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
+#
+ifdef CONFIG_SPL_BUILD
+ALL-y += $(OBJTREE)/MLO
+else
+ALL-y += $(obj)u-boot.img
+endif
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 67e8ceb..48a7ec6 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -35,6 +35,11 @@
_TEXT_BASE:
.word CONFIG_SYS_TEXT_BASE/* sdram load addr from config.mk */
+.global save_boot_params
+save_boot_params:
+ #warning "Please implement save_boot_params for OMAP3"
+ bx lr
+
.global omap3_gp_romcode_call
omap3_gp_romcode_call:
PUSH {r4-r12, lr} @ Save all registers from ROM code!
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index 995e7cb..7b60051 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -71,4 +71,5 @@ void power_init_r(void);
void dieid_num_r(void);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
void omap3_gp_romcode_call(u32 service_id, u32 parameter);
+void omap_rev_string(char *omap_rev_string);
#endif
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V9 4/9] spl: add NAND Library to new SPL
Adds NAND library to SPL.
Signed-off-by: Simon Schwarz
---
V1 changes:
CHG Default to HW ecc in SPL build
ADD nand_read_buf16 function, read buffer
ADD omap_dev_ready function, indicte if chip is ready
V2 changes:
DEL GPMC_WAIT0_PIN_ACTIVE define
CHG omap_dev_ready() renamed to omap_spl_dev_ready(), does not use the
GPMC_WAIT0_PIN_ACTIVE-define anymore
CHG ogpmc_read_buf16 renamed omap_spl_read_buf16
ADD omap_spl_read_buf, 8x buf read function
ADD CONFIG_SPL_POWER_SUPPORT and CONFIG_SPL_NAND_SUPPORT to SPL
CHG cosmetic
CHG nand_base and nand_bbt aren't needed for SPL anymore
CHG omap_nand_switch_ecc is not compiled for SPL
ADD entry for CONFIG_SPL_POWER_SUPPORT and CONFIG_SPL_NAND_SUPPORT to README.SPL
V3 changes:
DEL cosmetic (empty line)
V4 changes:
nothing
V5 changes:
CHG nand_ecc.o is only compiled for SPL if CONFIG_OMAP34XX is set
V6 changes:
ADD nand_spl.c - git add, finally
DEL nand_ecc barrier ifdef for OMAP3
V7 changes:
CHG nand_read_buf and nand_read_buf16 - removed static modifier
ADD nand_base.c to SPL
DEL omap_spl_read_buf16 and omap_spl_read_buf from omap_gpmc - now use the
functions of nand_base.de
ADD nand_read_buf and nand_read_buf16 to nand.h
CHG commit message to reflect that also POWER library is added
CHG renamed nand_spl.c to nand_spl_simple.c
CHG removed mtd from all interfaces of the nand_spl_simple
CHG nand_load image is now nand_spl_load_image
CHG removed comment on the transition from nand_boot to nand_spl_simple
CHG all offset parameters are now of type loff_t
CHG moved power library adding to an own patch
V8 changes:
CHG Added CONFIG_SPL_NAND_SIMPLE
DEL nand_spl_read_page is replaced by nand_spl_load_image with size=page size
V9 changes:
FIX readded config_spl_simple.c - somehow sneaked off the repo...
Transition from V1 to V2 also includes that this patch is now based on
- the new SPL layout by Aneesh V and Daniel Schwierzeck
- the OMAP4 SPL patches by Aneesh V
This Patch is related to "[U-Boot,4/5] devkit8000 nand_spl: Add SPL NAND support
to omap_gpmc driver"
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102115) in V1
---
doc/README.SPL |1 +
drivers/mtd/nand/Makefile | 10 ++-
drivers/mtd/nand/nand_base.c |4 +-
drivers/mtd/nand/nand_spl_simple.c | 245
drivers/mtd/nand/omap_gpmc.c | 27
include/nand.h |5 +-
spl/Makefile |1 +
7 files changed, 288 insertions(+), 5 deletions(-)
create mode 100644 drivers/mtd/nand/nand_spl_simple.c
diff --git a/doc/README.SPL b/doc/README.SPL
index ce8e19f..ef946ce 100644
--- a/doc/README.SPL
+++ b/doc/README.SPL
@@ -60,3 +60,4 @@ CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o)
CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o)
CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o)
CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o)
+CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o)
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 8b598f6..b6a7886 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -26,12 +26,18 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libnand.o
ifdef CONFIG_CMD_NAND
+ifdef CONFIG_SPL_BUILD
+ifdef CONFIG_SPL_NAND_SIMPLE
+COBJS-y += nand_spl_simple.o
+endif
+else
COBJS-y += nand.o
-COBJS-y += nand_base.o
COBJS-y += nand_bbt.o
-COBJS-y += nand_ecc.o
COBJS-y += nand_ids.o
COBJS-y += nand_util.o
+endif
+COBJS-y += nand_ecc.o
+COBJS-y += nand_base.o
COBJS-$(CONFIG_NAND_ATMEL) += atmel_nand.o
COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1a95a91..e7dfcb1 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -213,7 +213,7 @@ static void nand_write_buf(struct mtd_info *mtd, const
uint8_t *buf, int len)
*
* Default read function for 8bit buswith
*/
-static void nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+void nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
{
int i;
struct nand_chip *chip = mtd->priv;
@@ -269,7 +269,7 @@ static void nand_write_buf16(struct mtd_info *mtd, const
uint8_t *buf, int len)
*
* Default read function for 16bit buswith
*/
-static void nand_read_buf16(struct mtd_info *mtd, uint8_t *buf, int len)
+void nand_read_buf16(struct mtd_info *mtd, uint8_t *buf, int len)
{
int i;
struct nand_chip *chip = mtd->priv;
diff --git a/drivers/mtd/nand/nand_spl_simple.c
b/drivers/mtd/nand/nand_spl_simple.c
new file mode 100644
index 000..71491d4
--- /dev/null
+++ b/drivers/mtd/nand/nand_spl_simple.c
@@ -0,0 +1,245 @@
+/*
+ * (C) Copyright 2006-2008
+ * Stefan Roese, DENX Software Engineering, s...@denx.de.
+ *
+ * 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 versio
[U-Boot] [PATCH V9 8/9] omap3: implement boot parameter saving
Implements the saving of boot params passed by OMAP3 ROM code.
Signed-off-by: Simon Schwarz
---
Didn't exist before V8
V9 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl.c |6 +-
arch/arm/cpu/armv7/omap3/lowlevel_init.S |9 +++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index 53d10bf..3dd8e0d 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -194,8 +194,12 @@ static void mmc_load_image(void)
printf("spl: mmc init failed: err - %d\n", err);
hang();
}
-
+/* For OMAP3 there is no automatic boot mode detection */
+#ifdef CONFIG_OMAP34XX
+ boot_mode = CONFIG_SYS_MMC_SD_BOOTMODE;
+#else
boot_mode = omap_boot_mode();
+#endif
if (boot_mode == MMCSD_MODE_RAW) {
debug("boot mode - RAW\n");
mmc_load_image_raw(mmc);
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 48a7ec6..a308ebd 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -37,8 +37,13 @@ _TEXT_BASE:
.global save_boot_params
save_boot_params:
- #warning "Please implement save_boot_params for OMAP3"
- bx lr
+#ifdef CONFIG_SPL_BUILD
+ ldr r4, =omap3_boot_device
+ ldr r5, [r0, #0x4]
+ and r5, r5, #0xff
+ str r5, [r4]
+#endif
+ bx lr
.global omap3_gp_romcode_call
omap3_gp_romcode_call:
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V9 7/9] devkit8000: Add nand-spl support for new SPL
Add NAND SPL support to the devkit8000 config
Signed-off-by: Simon Schwarz
---
V1 changes:
ADD devkit8000_nand to board.cfg
ADD nand_spl Makefile, llinker script, spl-devkit8000.c
ADD config ecc, SRAM, SPL to board config
ADD CONFIG_SYS_SRAM_START and _SIZE to board config
ADD CONFIG_SYS_SPL_TEXT_BASE, _MAX_SIZE and SPL_STACK to board config
V2 changes:
ADD CONFIG_SPL and LIBCOMMON, LIBDISK, I2C, LIBGENERIC, SERIAL, POWER, NAND and
CONFIG_SPL_LDSCRIPT to board config
CHG renamed CONFIG_SYS_SPL_* to CONFIG_SPL_*
ADD CONFIG_SYS_NAND_U_BOOT_START, _OFFS, _SIZE, _DST to board config: Where to
expect u-boot and where to load it.
ADD some barrier to not build board_eth_init in SPL
DEL no changes to board.cfg
DEL everything used the old nand_spl layout (Makefile, linker script,
spl-devkit8000.c)
CHG cosmetic
V3 changes:
CHG Deleted wrong comment
V4 changes:
CHG CONFIG_SYS_SRAM_SIZE NOW has the right value
CHG cosmetic - corrected style problems
V5 changes:
nothing
V6 changes:
nothing
V7 changes:
ADD MMC dummy defines to prevent #ifedf clutter in spl.c
DEL CONFIG_SYS_NAND_U_BOOT_DST
V8 changes:
ADD CONFIG_SPL_NAND_SIMPLE
V9 changes:
DEL unused and untested MMC bootconfig
Transition from V1 to V2 also includes that this patch is now based on
- the new SPL layout by Aneesh V and Daniel Schwierzeck
- the OMAP4 SPL patches by Aneesh V
This is the successor of "[U-Boot,5/5] devkit8000 nand_spl: add nand_spl
support"
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102111)
---
board/timll/devkit8000/devkit8000.c |2 +-
include/configs/devkit8000.h| 46 +++
2 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/board/timll/devkit8000/devkit8000.c
b/board/timll/devkit8000/devkit8000.c
index 95afaaa..9b53742 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -119,7 +119,7 @@ void set_muxconf_regs(void)
MUX_DEVKIT8000();
}
-#ifdef CONFIG_DRIVER_DM9000
+#if defined(CONFIG_DRIVER_DM9000) & !defined(CONFIG_SPL_BUILD)
/*
* Routine: board_eth_init
* Description: Setting up the Ethernet hardware.
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 125c690..9cbdb5d 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -307,4 +307,50 @@
CONFIG_SYS_INIT_RAM_SIZE - \
GENERATED_GBL_DATA_SIZE)
+/* SRAM config */
+#define CONFIG_SYS_SRAM_START 0x4020
+#define CONFIG_SYS_SRAM_SIZE 0x1
+
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SPL_NAND_SIMPLE
+
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBDISK_SUPPORT
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_POWER_SUPPORT
+#define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_LDSCRIPT"$(CPUDIR)/omap-common/u-boot-spl.lds"
+
+#define CONFIG_SPL_TEXT_BASE 0x4020 /*CONFIG_SYS_SRAM_START*/
+#define CONFIG_SPL_MAX_SIZE0xB400 /* 45 K */
+#define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
+
+#define CONFIG_SPL_BSS_START_ADDR 0x8000 /*CONFIG_SYS_SDRAM_BASE*/
+#define CONFIG_SPL_BSS_MAX_SIZE0x8
+
+/* NAND boot config */
+#define CONFIG_SYS_NAND_PAGE_COUNT 64
+#define CONFIG_SYS_NAND_PAGE_SIZE 2048
+#define CONFIG_SYS_NAND_OOBSIZE64
+#define CONFIG_SYS_NAND_BLOCK_SIZE (128*1024)
+#define CONFIG_SYS_NAND_BAD_BLOCK_POS 0
+#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9,\
+ 10, 11, 12, 13}
+
+#define CONFIG_SYS_NAND_ECCSIZE512
+#define CONFIG_SYS_NAND_ECCBYTES 3
+
+#define CONFIG_SYS_NAND_ECCSTEPS (CONFIG_SYS_NAND_PAGE_SIZE / \
+ CONFIG_SYS_NAND_ECCSIZE)
+#define CONFIG_SYS_NAND_ECCTOTAL (CONFIG_SYS_NAND_ECCBYTES * \
+ CONFIG_SYS_NAND_ECCSTEPS)
+
+#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE
+
+#define CONFIG_SYS_NAND_U_BOOT_OFFS0x8
+#define CONFIG_SYS_NAND_U_BOOT_SIZE0x20
+
#endif /* __CONFIG_H */
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V9 9/9] omap-common: reorganize spl.c
split-up spl.c into spl.c, spl_mmc.c and spl_nand.c. This avoids problems
with missing defines if a board does not use mmc or nand. This includes
adding spl_ prefix to some functions which are now public. spl_image_t is now
a public type. Added some of the common functions to omap-common.h
Signed-off-by: Simon Schwarz
---
Didn't exist before V8
V9 changes:
FIX typo in commit message
ADD using omap_boot_mode() now
---
arch/arm/cpu/armv7/omap-common/Makefile |6 +
arch/arm/cpu/armv7/omap-common/spl.c | 197 +++--
arch/arm/cpu/armv7/omap-common/spl_mmc.c | 150 ++
arch/arm/cpu/armv7/omap-common/spl_nand.c | 71 +++
4 files changed, 247 insertions(+), 177 deletions(-)
create mode 100644 arch/arm/cpu/armv7/omap-common/spl_mmc.c
create mode 100644 arch/arm/cpu/armv7/omap-common/spl_nand.c
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index ea9f8ec..0b96b47 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -33,6 +33,12 @@ COBJS+= gpio.o
ifdef CONFIG_SPL_BUILD
COBJS += spl.o
+ifdef CONFIG_SPL_NAND_SUPPORT
+COBJS += spl_nand.o
+endif
+ifdef CONFIG_SPL_MMC_SUPPORT
+COBJS += spl_mmc.o
+endif
endif
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index 3dd8e0d..c76fea6 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -38,14 +38,11 @@
DECLARE_GLOBAL_DATA_PTR;
+struct spl_image_info spl_image;
+
/* Define global data structure pointer to it*/
static gd_t gdata __attribute__ ((section(".data")));
static bd_t bdata __attribute__ ((section(".data")));
-static const char *image_name;
-static u8 image_os;
-static u32 image_load_addr;
-static u32 image_entry_point;
-static u32 image_size;
inline void hang(void)
{
@@ -66,194 +63,40 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
}
-#ifdef CONFIG_GENERIC_MMC
-int board_mmc_init(bd_t *bis)
-{
- switch (omap_boot_device()) {
- case BOOT_DEVICE_MMC1:
- omap_mmc_init(0);
- break;
- case BOOT_DEVICE_MMC2:
- omap_mmc_init(1);
- break;
- }
- return 0;
-}
-#endif
-
-static void parse_image_header(const struct image_header *header)
+void spl_parse_image_header(const struct image_header *header)
{
u32 header_size = sizeof(struct image_header);
if (__be32_to_cpu(header->ih_magic) == IH_MAGIC) {
- image_size = __be32_to_cpu(header->ih_size) + header_size;
- image_entry_point = __be32_to_cpu(header->ih_load);
+ spl_image.size = __be32_to_cpu(header->ih_size) + header_size;
+ spl_image.entry_point = __be32_to_cpu(header->ih_load);
/* Load including the header */
- image_load_addr = image_entry_point - header_size;
- image_os = header->ih_os;
- image_name = (const char *)&header->ih_name;
+ spl_image.load_addr = spl_image.entry_point - header_size;
+ spl_image.os = header->ih_os;
+ spl_image.name = (const char *)&header->ih_name;
debug("spl: payload image: %s load addr: 0x%x size: %d\n",
- image_name, image_load_addr, image_size);
+ spl_image.name, spl_image.load_addr, spl_image.size);
} else {
/* Signature not found - assume u-boot.bin */
printf("mkimage signature not found - ih_magic = %x\n",
header->ih_magic);
puts("Assuming u-boot.bin ..\n");
/* Let's assume U-Boot will not be more than 200 KB */
- image_size = 200 * 1024;
- image_entry_point = CONFIG_SYS_TEXT_BASE;
- image_load_addr = CONFIG_SYS_TEXT_BASE;
- image_os = IH_OS_U_BOOT;
- image_name = "U-Boot";
- }
-}
-
-static void mmc_load_image_raw(struct mmc *mmc)
-{
- u32 image_size_sectors, err;
- const struct image_header *header;
-
- header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
- sizeof(struct image_header));
-
- /* read image header to find the image size & load address */
- err = mmc->block_dev.block_read(0,
- CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, 1,
- (void *)header);
-
- if (err <= 0)
- goto end;
-
- parse_image_header(header);
-
- /* convert size to sectors - round up */
- image_size_sectors = (image_size + MMCSD_SECTOR_SIZE - 1) /
- MMCSD_SECTOR_SIZE;
-
- /* Read the header too to avoid extra memcpy */
- err = mmc->block_dev.block_read(0,
-
Re: [U-Boot] [PATCH] Fix wrong loop bound in flush_cache() when "size" is zero.
Hi Sergei, thanks for your comments.
I will submit the patch v2.
2011/8/8 Sergei Shtylyov
> Hello.
>
>
> On 08-08-2011 12:07, Yao Cheng wrote:
>
> The issue is found when calling flush_cache() with zero "size" argument.
>> The bound of loop is miscalculated in this case and flush_cache() enters a
>> wrong flushing loop.
>> To fix this issue I skipped the operations when "size" is found to be
>> zero.
>>
>
> Signed-off-by: Yao Cheng
>> Cc: Shinya Kuribayashi
>> ---
>> arch/mips/cpu/mips32/cpu.c |5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>
> diff --git a/arch/mips/cpu/mips32/cpu.c b/arch/mips/cpu/mips32/cpu.c
>> index 3ae397c..1bf0094 100644
>> --- a/arch/mips/cpu/mips32/cpu.c
>> +++ b/arch/mips/cpu/mips32/cpu.c
>> @@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char
>> * const argv[])
>>
>> void flush_cache(ulong start_addr, ulong size)
>> {
>> + /* aend will be miscalculated when size is zero, so we need return here
>> */
>> + if (size == 0) {
>> +return;
>> + }
>>
> > +
>
> Please indent with tabs, not spaces. Also, doesn't this code generate
> warning (code before declarations)?
>
>
> unsigned long lsize = CONFIG_SYS_CACHELINE_SIZE;
>>unsigned long addr = start_addr& ~(lsize - 1);
>>unsigned long aend = (start_addr + size - 1)& ~(lsize - 1);
>>
>
> WBR, Sergei
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Fix wrong loop bound in flush_cache() when "size" is zero
The issue is found when calling flush_cache() with zero "size" argument.
The bound of loop is miscalculated in this case and flush_cache() enters a
wrong flushing loop.
To fix this issue I skipped the operations when "size" is found to be zero.
Signed-off-by: Yao Cheng
Cc: Shinya Kuribayashi
---
Changes for v2:
- Coding style cleanup
- Move code after declarations to avoid warning
arch/mips/cpu/mips32/cpu.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/mips/cpu/mips32/cpu.c b/arch/mips/cpu/mips32/cpu.c
index 3ae397c..8fa53ba 100644
--- a/arch/mips/cpu/mips32/cpu.c
+++ b/arch/mips/cpu/mips32/cpu.c
@@ -56,6 +56,11 @@ void flush_cache(ulong start_addr, ulong size)
unsigned long addr = start_addr & ~(lsize - 1);
unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
+ /* aend will be miscalculated when size is zero, so we return here */
+ if (size == 0) {
+ return;
+ }
+
while (1) {
cache_op(Hit_Writeback_Inv_D, addr);
cache_op(Hit_Invalidate_I, addr);
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master -- updated
Dear Albert Am 04.08.2011 19:04, schrieb Albert ARIBAUD: > Hi Wolfgang, > > Here is my pull request for u-boot-arm/master, from which I did remove > the wrongly applied commits that you indicated and in which all patches > submitted before the merge window closure are taken into account. > > Developers, please direct complaints to me for any ARM-directed patches > submitted before the window closure, and which is not accounted for at > this point. I still missing http://patchwork.ozlabs.org/patch/96842/ Thanks Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4: increase SRAM budget to fix build error
On 08.08.2011 08:05, Aneesh V wrote: > Signed-off-by: Aneesh V > Cc: Dirk Behme > Cc: Sandeep Paulraj Acked-by: Dirk Behme > --- > include/configs/omap4_panda.h |2 +- > include/configs/omap4_sdp4430.h |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h > index e313231..814f15c 100644 > --- a/include/configs/omap4_panda.h > +++ b/include/configs/omap4_panda.h > @@ -245,7 +245,7 @@ > /* Defines for SPL */ > #define CONFIG_SPL > #define CONFIG_SPL_TEXT_BASE0x40304350 > -#define CONFIG_SPL_MAX_SIZE 0x8000 /* 32 K */ > +#define CONFIG_SPL_MAX_SIZE (38 * 1024) > #define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK > > #define CONFIG_SPL_BSS_START_ADDR 0x8000 > diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h > index 5b3110c..1a5d7a6 100644 > --- a/include/configs/omap4_sdp4430.h > +++ b/include/configs/omap4_sdp4430.h > @@ -251,7 +251,7 @@ > /* Defines for SPL */ > #define CONFIG_SPL > #define CONFIG_SPL_TEXT_BASE0x40304350 > -#define CONFIG_SPL_MAX_SIZE 0x8000 /* 32 K */ > +#define CONFIG_SPL_MAX_SIZE (38 * 1024) > #define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK > > #define CONFIG_SPL_BSS_START_ADDR 0x8000 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap: fix gpio related build breaks
On 01.08.2011 08:30, Aneesh V wrote:
> Signed-off-by: Aneesh V
Acked-by: Dirk Behme
> ---
> Hi Sandeep,
> This is an incremental patch to fix the build issues created
> by "[PATCH 3/5] omap: reuse omap3 gpio support in omap4"
> in the omap4460 series.
> ---
> arch/arm/cpu/armv7/omap-common/gpio.c |2 +-
> arch/arm/cpu/armv7/omap3/board.c|2 +-
> arch/arm/cpu/armv7/omap4/board.c|2 +-
> arch/arm/include/asm/arch-omap3/gpio.h | 50
> +++
> arch/arm/include/asm/arch-omap3/omap3.h |8 -
> arch/arm/include/asm/arch-omap4/gpio.h | 50
> +++
> arch/arm/include/asm/arch-omap4/omap4.h |8 -
> board/pandora/pandora.c |1 +
> 8 files changed, 104 insertions(+), 19 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-omap3/gpio.h
> create mode 100644 arch/arm/include/asm/arch-omap4/gpio.h
>
> diff --git a/arch/arm/cpu/armv7/omap-common/gpio.c
> b/arch/arm/cpu/armv7/omap-common/gpio.c
> index f4c3479..2fcaf5a 100644
> --- a/arch/arm/cpu/armv7/omap-common/gpio.c
> +++ b/arch/arm/cpu/armv7/omap-common/gpio.c
> @@ -36,7 +36,7 @@
>* published by the Free Software Foundation.
>*/
> #include
> -#include
> +#include
> #include
> #include
>
> diff --git a/arch/arm/cpu/armv7/omap3/board.c
> b/arch/arm/cpu/armv7/omap3/board.c
> index 4aaf97b..bce3ee6 100644
> --- a/arch/arm/cpu/armv7/omap3/board.c
> +++ b/arch/arm/cpu/armv7/omap3/board.c
> @@ -38,7 +38,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> /* Declarations */
> extern omap3_sysinfo sysinfo;
> diff --git a/arch/arm/cpu/armv7/omap4/board.c
> b/arch/arm/cpu/armv7/omap4/board.c
> index 5943d61..8e90545 100644
> --- a/arch/arm/cpu/armv7/omap4/board.c
> +++ b/arch/arm/cpu/armv7/omap4/board.c
> @@ -33,7 +33,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include "omap4_mux_data.h"
>
> DECLARE_GLOBAL_DATA_PTR;
> diff --git a/arch/arm/include/asm/arch-omap3/gpio.h
> b/arch/arm/include/asm/arch-omap3/gpio.h
> new file mode 100644
> index 000..8bba3b0
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-omap3/gpio.h
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright (c) 2009 Wind River Systems, Inc.
> + * Tom Rix
> + *
> + * 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
> + *
> + * This work is derived from the linux 2.6.27 kernel source
> + * To fetch, use the kernel repository
> + * git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> + * Use the v2.6.27 tag.
> + *
> + * Below is the original's header including its copyright
> + *
> + * linux/arch/arm/plat-omap/gpio.c
> + *
> + * Support functions for OMAP GPIO
> + *
> + * Copyright (C) 2003-2005 Nokia Corporation
> + * Written by Juha Yrjölä
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef _GPIO_OMAP3_H
> +#define _GPIO_OMAP3_H
> +
> +#include
> +
> +#define OMAP34XX_GPIO1_BASE 0x4831
> +#define OMAP34XX_GPIO2_BASE 0x4905
> +#define OMAP34XX_GPIO3_BASE 0x49052000
> +#define OMAP34XX_GPIO4_BASE 0x49054000
> +#define OMAP34XX_GPIO5_BASE 0x49056000
> +#define OMAP34XX_GPIO6_BASE 0x49058000
> +
> +#endif /* _GPIO_OMAP3_H */
> diff --git a/arch/arm/include/asm/arch-omap3/omap3.h
> b/arch/arm/include/asm/arch-omap3/omap3.h
> index d9d49da..230eaad 100644
> --- a/arch/arm/include/asm/arch-omap3/omap3.h
> +++ b/arch/arm/include/asm/arch-omap3/omap3.h
> @@ -100,14 +100,6 @@ struct s32ktimer {
>
> #endif /* __ASSEMBLY__ */
>
> -/* OMAP3 GPIO registers */
> -#define OMAP34XX_GPIO1_BASE 0x4831
> -#define OMAP34XX_GPIO2_BASE 0x4905
> -#define OMAP34XX_GPIO3_BASE 0x49052000
> -#define OMAP34XX_GPIO4_BASE 0x49054000
> -#define OMAP34XX_GPIO5_BASE 0x49056000
> -#define OMAP34XX_GPIO6_BASE 0x49058000
> -
> #ifndef __ASSEMBLY__
> struct gpio {
> unsigned char res1[0x34];
> diff --git a/arch/arm/include/asm/arch-omap4/gpio.h
> b/arch/arm/include/asm/arch-omap4/gpio.h
> new file mode 100644
> index 000..26f19d1
> --
Re: [U-Boot] [PATCH] OMAP3: Fix gpio.h usage
On 05.08.2011 20:31, Dirk Behme wrote:
> From: Dirk Behme
>
> The patch "omap: reuse omap3 gpio support in omap4" moves
> arch/arm/include/asm/arch-omap3/gpio.h to
> arch/arm/include/asm/omap_gpio.h but misses to touch all
> users of arch-omap3/gpio.h. This results in various build
> failures like
>
> : error: asm/arch/gpio.h: No such file or directory
>
> Fix this by correcting the now wrong includes.
>
> Signed-off-by: Dirk Behme
> CC: Aneesh V
> CC: Sandeep Paulraj
Please ignore this patch and use
http://patchwork.ozlabs.org/patch/107678/
instead.
Thanks
Dirk
> ---
> "omap: reuse omap3 gpio support in omap4" is commit
>
> http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=25223a68e5f7cc32eebb44313efe8ff15a0f5fd6
>
> board/cm_t35/leds.c |2 +-
> board/comelit/dig297/dig297.c |2 +-
> board/isee/igep0020/igep0020.c|2 +-
> board/logicpd/zoom2/debug_board.c |2 +-
> board/logicpd/zoom2/led.c |2 +-
> board/logicpd/zoom2/zoom2.c |2 +-
> board/overo/overo.c |2 +-
> board/ti/beagle/beagle.c |2 +-
> board/ti/beagle/led.c |2 +-
> board/ti/evm/evm.c|2 +-
> 10 files changed, 10 insertions(+), 10 deletions(-)
>
> Index: u-boot.git/board/cm_t35/leds.c
> ===
> --- u-boot.git.orig/board/cm_t35/leds.c
> +++ u-boot.git/board/cm_t35/leds.c
> @@ -20,7 +20,7 @@
>*/
> #include
> #include
> -#include
> +#include
>
> static unsigned int leds[] = { GREEN_LED_GPIO };
>
> Index: u-boot.git/board/comelit/dig297/dig297.c
> ===
> --- u-boot.git.orig/board/comelit/dig297/dig297.c
> +++ u-boot.git/board/comelit/dig297/dig297.c
> @@ -41,7 +41,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include "dig297.h"
>
> Index: u-boot.git/board/isee/igep0020/igep0020.c
> ===
> --- u-boot.git.orig/board/isee/igep0020/igep0020.c
> +++ u-boot.git/board/isee/igep0020/igep0020.c
> @@ -24,7 +24,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> Index: u-boot.git/board/logicpd/zoom2/debug_board.c
> ===
> --- u-boot.git.orig/board/logicpd/zoom2/debug_board.c
> +++ u-boot.git/board/logicpd/zoom2/debug_board.c
> @@ -22,7 +22,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #define DEBUG_BOARD_CONNECTED 1
> #define DEBUG_BOARD_NOT_CONNECTED 0
> Index: u-boot.git/board/logicpd/zoom2/led.c
> ===
> --- u-boot.git.orig/board/logicpd/zoom2/led.c
> +++ u-boot.git/board/logicpd/zoom2/led.c
> @@ -22,7 +22,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> static unsigned int saved_state[2] = {STATUS_LED_OFF, STATUS_LED_OFF};
>
> Index: u-boot.git/board/logicpd/zoom2/zoom2.c
> ===
> --- u-boot.git.orig/board/logicpd/zoom2/zoom2.c
> +++ u-boot.git/board/logicpd/zoom2/zoom2.c
> @@ -35,7 +35,7 @@
> #endif
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> Index: u-boot.git/board/overo/overo.c
> ===
> --- u-boot.git.orig/board/overo/overo.c
> +++ u-boot.git/board/overo/overo.c
> @@ -36,7 +36,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include "overo.h"
>
> Index: u-boot.git/board/ti/beagle/beagle.c
> ===
> --- u-boot.git.orig/board/ti/beagle/beagle.c
> +++ u-boot.git/board/ti/beagle/beagle.c
> @@ -38,7 +38,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #ifdef CONFIG_USB_EHCI
> #include
> Index: u-boot.git/board/ti/beagle/led.c
> ===
> --- u-boot.git.orig/board/ti/beagle/led.c
> +++ u-boot.git/board/ti/beagle/led.c
> @@ -22,7 +22,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> static unsigned int saved_state[2] = {STATUS_LED_OFF, STATUS_LED_OFF};
>
> Index: u-boot.git/board/ti/evm/evm.c
> ===
> --- u-boot.git.orig/board/ti/evm/evm.c
> +++ u-boot.git/board/ti/evm/evm.c
> @@ -33,7 +33,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include "evm.h"
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache
On Monday, August 08, 2011 10:01:19 AM Albert ARIBAUD wrote:
> Hi Hong Xu,
>
> Le 08/08/2011 05:20, Hong Xu a écrit :
> > After DMA operation, we need to maintain D-Cache coherency.
> > So that the DCache must be invalidated (hence CPU will fetch
> > data written by DMA controller from RAM).
> >
> > Tested on AT91SAM9261EK with Peripheral DMA controller.
> >
> > Signed-off-by: Hong Xu
> > Tested-by: Elen Song
> > CC: Albert Aribaud
> > CC: Aneesh V
> > CC: Reinhard Meyer
> > CC: Heiko Schocher
> > ---
> >
> > V2:
> >Per Albert's suggestion, add invalidate_dcache_range
> >
> > V3:
> >invalidate_dcache_range emits warning when detecting unaligned buffer
> >
> >invalidate_dcache_range won't clean any adjacent cache line when
> >detecting unaligned buffer and only round up/down the buffer address
> >
> > + mva = start;
> > + if ((mva& (cache_line_len - 1)) != 0) {
> > + printf("WARNING: %s - unaligned buffer detected, starting "
>
> I'd rather have a message about "cache", not "buffer", e.g.
>
>printf("WARNING: %s - start address %x is not aligned\n"
> __FUNCTION__, start);
__func__ is prefered in linux kernel :-)
>
> > + mva&= ~(cache_line_len - 1);
> > + }
> > + if ((stop& (cache_line_len - 1)) != 0) {
> > + printf("WARNING: %s - unaligned buffer detected, ending "
> > + "address: 0x%08x\n", __FUNCTION__, stop);
>
> Ditto.
Ditto.
>
> > + stop = (stop | (cache_line_len - 1)) + 1;
> > + }
> > +
> > + while (mva< stop) {
> > + asm("mcr p15, 0, %0, c7, c6, 1" : : "r"(mva));
> > + mva += cache_line_len;
> > + }
>
> Thinking more about the degenerate case -- why not round *up* the start
> address, and round *down* the stop address, that is, *reduce* the area
> to the aligned portion rather than *expand* it into the unknown? That
> would make data in "partially owned" cache lines safe from unwanted
> invalidation. OTOH, it would not completely invalidate the caller's
> data, but at least the malfunction would appear in the faulty calling
> code, not elsewhere.
That'd introduce even stranger behaviour and it'd be even more sickening to
debug
>
> Opinions?
>
> Amicalement,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache
Le 08/08/2011 19:34, Marek Vasut a écrit : >> Thinking more about the degenerate case -- why not round *up* the start >> address, and round *down* the stop address, that is, *reduce* the area >> to the aligned portion rather than *expand* it into the unknown? That >> would make data in "partially owned" cache lines safe from unwanted >> invalidation. OTOH, it would not completely invalidate the caller's >> data, but at least the malfunction would appear in the faulty calling >> code, not elsewhere. > > That'd introduce even stranger behaviour and it'd be even more sickening to > debug I tend to agree neither on the "stranger" part, nor on the "sickening". Can you develop your viewpoint? For your reference, here is mine: As for "stranger": for me, an unexpected value (either a modification or an absence thereof) in a variable that no code is using right now, that is stranger than an unexpected value in a DMA buffer we just happen to have recently invalidated. As for "sickening": for me, when a bug occurs, one of the requisites is to look up the console output, where a message about an unaligned cache invalidate address will stand out and quite quickly point at the root cause for that weird DMA buffer content problem -- OTOH, with "expanded" invalidates, the DMA buffer is OK so one might disregard the warning and not link it far later with that weird problem where an obscure global variable couldn't keep its value. I do understand though that I dismissed flush-in-invalidate with an argument of "does what it says on the tin", and that one could say my proposal makes the function do less of what it says on the tin; my point was about the nature of the action, not its extent. IOW, the sticker on the tin also says "use only with cacheline-aligned start and stop", so fair's fair: if you pass unaligned ranges, don't expect the invalidate to extend beyond the aligned part. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Fix wrong loop bound in flush_cache() when "size" is zero
in the future, please prefix your patches. since this is mips-specific, your summary would read: mips: fix wrong loop bound in flush_cache() when "size" is zero or perhaps: mips32: fix wrong loop bound in flush_cache() when "size" is zero -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] new tool mkenvimage: generates an env image from an arbitrary config file
On Mon, Aug 8, 2011 at 04:16, David Wagner wrote: > On 08/06/2011 01:18 PM, Mike Frysinger wrote: >> seems like this should also take a padding byte so people can use a >> more sensible 0xff rather than 0x00 > > Thomas told me that when padding with 0xff, his environment image > wouldn't be taken into account anymore. > I'll add the option anyway, but do you know what could be happening ? sorry, but i dont know what you're referring to. perhaps you wrote out the padding before calculating the crc ? ive been using `tools/envcrc --binary` for a while now and it pads things with 0xff. > Also, I guess this makes necessary making sure there is a \0 after the > last configuration line. two to be exact ... one for the config opt, and one to tell u-boot that it's the end of the env. > I wasn't sure whether the proper way of doing it was "read/write 1 byte, > N times" or "read/write the size of the file, 1 time". I probably > changed my mine in between. dont think of it in terms of bytes. in fact, forget about that completely. think of it in terms of "elements". in this case, the element is a "char" which means you want to read a bunch of "char" elements and the size of each is 1. you could also do: fwrite(dataptr, sizeof(*dataptr), datasize, bin_file); then you dont need to think "how many bytes is one element". -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: Fix 'Unknown OMAP image type - 5'
Hi Dirk, Le 05/08/2011 20:42, Dirk Behme a écrit : > From: Dirk Behme > > Using mkimage with e.g. > > tools/mkimage -A arm -T firmware -O u-boot -d u-boot.bin foo.img > > gives a warning > > "Unknown OMAP image type - 5" > > while it seems that the image itself is created successfully. > > This does come from the patch "mkimage: Add OMAP boot image support". > > Reordering the init_xx_image_type() sequence does make this > message go away. > > Signed-off-by: Dirk Behme > CC: John Rigby > CC: Aneesh V > CC: Sandeep Paulraj > > --- > > This is reproducable with the recent mainline mkimage where the > patch "mkimage: Add OMAP boot image support" is applied: > > http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=3decb14abe76d244ba98fd158ef95f89e7e37d70 > > tools/mkimage.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Index: u-boot.git/tools/mkimage.c > === > --- u-boot.git.orig/tools/mkimage.c > +++ u-boot.git/tools/mkimage.c > @@ -156,12 +156,12 @@ main (int argc, char **argv) > init_imx_image_type (); > /* Init FIT image generation/list support */ > init_fit_image_type (); > - /* Init TI OMAP Boot image generation/list support */ > - init_omap_image_type(); > /* Init Default image generation/list support */ > init_default_image_type (); > /* Init Davinci UBL support */ > init_ubl_image_type(); > + /* Init TI OMAP Boot image generation/list support */ > + init_omap_image_type(); > > params.cmdname = *argv; > params.addr = params.ep = 0; > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Any idea why reordering fixes the issue? Seems to me like init functions are not / should not be dependent on order, so the "fix" seems fragile to me, at least as long as we cannot add a good explanation. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MUSB timeout broken
Hi, 2011/7/4 Orjan Friberg : > Use pre-decrement to leave timeout at 0 when the timeout happens (which is > what > the timeout detecting code expects). > > Signed-off-by: Orjan Friberg > --- > drivers/usb/musb/musb_hcd.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c > index 974bb31..adcf7f7 100644 > --- a/drivers/usb/musb/musb_hcd.c > +++ b/drivers/usb/musb/musb_hcd.c > @@ -1114,7 +1114,7 @@ int usb_lowlevel_init(void) > * should be a usb device connected. > */ > timeout = musb_cfg.timeout; > - while (timeout--) > + while (--timeout) > if (readb(&musbr->devctl) & MUSB_DEVCTL_HM) > break; > Applied to u-boot-usb Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MUSB timeout broken
Hi, > 2011/7/4 Orjan Friberg : >> Use pre-decrement to leave timeout at 0 when the timeout happens (which is >> what >> the timeout detecting code expects). >> >> Signed-off-by: Orjan Friberg >> --- >> drivers/usb/musb/musb_hcd.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c >> index 974bb31..adcf7f7 100644 >> --- a/drivers/usb/musb/musb_hcd.c >> +++ b/drivers/usb/musb/musb_hcd.c >> @@ -1114,7 +1114,7 @@ int usb_lowlevel_init(void) >> * should be a usb device connected. >> */ >> timeout = musb_cfg.timeout; >> - while (timeout--) >> + while (--timeout) >> if (readb(&musbr->devctl) & MUSB_DEVCTL_HM) >> break; >> > > Applied to u-boot-usb Whoops... Not applied to u-boot-usb, since the timeout code is broken. It should wait for a certain time, not a certain count. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: r8a66597: Fix argument mistake of inl
Hi, 2011/7/11 Nobuhiro Iwamatsu : > Fail in build, because argument of inl used in r8a66597_read_fifo is wrong. > > r8a66597.h:441:35: error: macro "inl" passed 2 arguments, but takes just 1 > In file included from r8a66597-hcd.c:25: > r8a66597.h: In function ‘r8a66597_read_fifo’: > r8a66597.h:441: error: ‘inl’ undeclared (first use in this function) > r8a66597.h:441: error: (Each undeclared identifier is reported only once > r8a66597.h:441: error: for each function it appears in.) > > Signed-off-by: Nobuhiro Iwamatsu Applied to u-boot-usb. Thanks. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] USB: Set portnr so USB1.1 and 1.0 devices work on EHCI controllers
Hi,
2011/7/12 Marek Vasut :
> Signed-off-by: Marek Vasut
> ---
> common/usb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/common/usb.c b/common/usb.c
> index 8e84266..a401c09 100644
> --- a/common/usb.c
> +++ b/common/usb.c
> @@ -1166,6 +1166,7 @@ void usb_hub_port_connect_change(struct usb_device
> *dev, int port)
>
> dev->children[port] = usb;
> usb->parent = dev;
> + usb->portnr = port + 1;
> /* Run it through the hoops (find a driver, etc) */
> if (usb_new_device(usb)) {
> /* Woops, disable the port */
>
Applied to u-boot-usb. Thanks.
Kind regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fat: fix crash with big sector size
Apple iPod nanos have sector sizes of 2 or 4 KiB, which crashes U-Boot when it
tries to read the boot sector into 512-byte buffer situated on stack. Make the
FAT code indifferent to the sector size.
Signed-off-by: Sergei Shtylyov
---
fs/fat/fat.c | 97 +++---
include/fat.h | 20 ---
2 files changed, 67 insertions(+), 50 deletions(-)
Index: u-boot/fs/fat/fat.c
===
--- u-boot.orig/fs/fat/fat.c
+++ u-boot/fs/fat/fat.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
@@ -69,8 +70,7 @@ static int disk_read (__u32 startblock,
int fat_register_device (block_dev_desc_t * dev_desc, int part_no)
{
- unsigned char buffer[SECTOR_SIZE];
-
+ unsigned char buffer[dev_desc->blksz];
disk_partition_t info;
if (!dev_desc->block_read)
@@ -209,12 +209,12 @@ static __u32 get_fatent (fsdata *mydata,
/* Read a new block of FAT entries into the cache. */
if (bufnum != mydata->fatbufnum) {
- __u32 getsize = FATBUFSIZE / FS_BLOCK_SIZE;
+ __u32 getsize = FATBUFSIZE / mydata->sect_size;
__u8 *bufptr = mydata->fatbuf;
__u32 fatlength = mydata->fatlength;
__u32 startblock = bufnum * FATBUFBLOCKS;
- fatlength *= SECTOR_SIZE; /* We want it in bytes now */
+ fatlength *= mydata->sect_size; /* We want it in bytes now */
startblock += mydata->fat_sect; /* Offset from start of disk */
if (getsize > fatlength)
@@ -291,21 +291,21 @@ get_cluster (fsdata *mydata, __u32 clust
debug("gc - clustnum: %d, startsect: %d\n", clustnum, startsect);
- if (disk_read(startsect, size / FS_BLOCK_SIZE, buffer) < 0) {
+ if (disk_read(startsect, size / mydata->sect_size, buffer) < 0) {
debug("Error reading data\n");
return -1;
}
- if (size % FS_BLOCK_SIZE) {
- __u8 tmpbuf[FS_BLOCK_SIZE];
+ if (size % mydata->sect_size) {
+ __u8 tmpbuf[mydata->sect_size];
- idx = size / FS_BLOCK_SIZE;
+ idx = size / mydata->sect_size;
if (disk_read(startsect + idx, 1, tmpbuf) < 0) {
debug("Error reading data\n");
return -1;
}
- buffer += idx * FS_BLOCK_SIZE;
+ buffer += idx * mydata->sect_size;
- memcpy(buffer, tmpbuf, size % FS_BLOCK_SIZE);
+ memcpy(buffer, tmpbuf, size % mydata->sect_size);
return 0;
}
@@ -322,7 +322,7 @@ get_contents (fsdata *mydata, dir_entry
unsigned long maxsize)
{
unsigned long filesize = FAT2CPU32(dentptr->size), gotsize = 0;
- unsigned int bytesperclust = mydata->clust_size * SECTOR_SIZE;
+ unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
__u32 curclust = START(dentptr);
__u32 endclust, newclust;
unsigned long actsize;
@@ -441,7 +441,7 @@ get_vfatname (fsdata *mydata, int curclu
dir_slot *slotptr = (dir_slot *)retdent;
__u8 *buflimit = cluster + ((curclust == 0) ?
LINEAR_PREFETCH_SIZE :
- (mydata->clust_size * SECTOR_SIZE)
+ (mydata->clust_size * mydata->sect_size)
);
__u8 counter = (slotptr->id & ~LAST_LONG_ENTRY_MASK) & 0xff;
int idx = 0;
@@ -473,7 +473,7 @@ get_vfatname (fsdata *mydata, int curclu
}
if (get_cluster(mydata, curclust, get_vfatname_block,
- mydata->clust_size * SECTOR_SIZE) != 0) {
+ mydata->clust_size * mydata->sect_size) != 0) {
debug("Error: reading directory block\n");
return -1;
}
@@ -555,7 +555,7 @@ static dir_entry *get_dentfromdir (fsdat
int i;
if (get_cluster(mydata, curclust, get_dentfromdir_block,
- mydata->clust_size * SECTOR_SIZE) != 0) {
+ mydata->clust_size * mydata->sect_size) != 0) {
debug("Error: reading directory block\n");
return NULL;
}
@@ -702,13 +702,24 @@ static dir_entry *get_dentfromdir (fsdat
static int
read_bootsectandvi (boot_sector *bs, volume_info *volinfo, int *fatsize)
{
- __u8 block[FS_BLOCK_SIZE];
-
+ __u8 *block;
volume_info *vistart;
+ int ret = 0;
+
+ if (cur_dev == NULL) {
+ debug("Error: no device selected\n");
+ return -1;
+ }
+
+ block = malloc(cur_dev->blksz);
+ if (block == NULL) {
+
[U-Boot] [PATCH 2/2] fat: cannot compare bytes and sectors
The code multiples the FAT size in sectors by the sector size and then tries to
compare that to the number of sectors in the 'getsize' variable. While fixing
this, also change the initial value of 'getsize' as the division of FATBUFSIZE
by the sector size gets us FATBUFBLOCKS.
Signed-off-by: Sergei Shtylyov
---
fs/fat/fat.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: u-boot/fs/fat/fat.c
===
--- u-boot.orig/fs/fat/fat.c
+++ u-boot/fs/fat/fat.c
@@ -209,16 +209,17 @@ static __u32 get_fatent (fsdata *mydata,
/* Read a new block of FAT entries into the cache. */
if (bufnum != mydata->fatbufnum) {
- __u32 getsize = FATBUFSIZE / mydata->sect_size;
+ __u32 getsize = FATBUFBLOCKS;
__u8 *bufptr = mydata->fatbuf;
__u32 fatlength = mydata->fatlength;
__u32 startblock = bufnum * FATBUFBLOCKS;
+ if (getsize > fatlength)
+ getsize = fatlength;
+
fatlength *= mydata->sect_size; /* We want it in bytes now */
startblock += mydata->fat_sect; /* Offset from start of disk */
- if (getsize > fatlength)
- getsize = fatlength;
if (disk_read(startblock, getsize, bufptr) < 0) {
debug("Error reading FAT blocks\n");
return ret;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] USB: Move USB_PRINTF() out of ifdef in usb_scan_devices()
Hi, 2011/7/13 Marek Vasut : > On Wednesday, July 13, 2011 03:49:00 PM Stefano Babic wrote: >> On 07/12/2011 02:16 AM, Marek Vasut wrote: >> > Signed-off-by: Marek Vasut >> > --- >> > >> > common/usb.c | 2 +- >> > 1 files changed, 1 insertions(+), 1 deletions(-) >> > >> > diff --git a/common/usb.c b/common/usb.c >> > index 4f7c520..8e84266 100644 >> >> Hi Marek, >> >> this should be checked by the USB maintainer, also if it is part of the >> Efikamx patchset - I set him in CC. > > Yea of course ... I sent this to Remy some time ago already, got no response > so > far ... Hey.. It is a holiday season... ;-) Acked-by: Remy Bohmer (It can go with the rest of the series) Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] USB: Move USB_PRINTF() out of ifdef in usb_scan_devices()
Hi, >> Yea of course ... I sent this to Remy some time ago already, got no response >> so >> far ... > > Hey.. It is a holiday season... ;-) > > Acked-by: Remy Bohmer > (It can go with the rest of the series) Seems that it time to go again on a next vacation... I just pulled in 5/5 of this series, so I can pull this one in myself as well ;-) Applied to u-boot-usb. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix wrong loop bound in flush_cache() when "size" is zero.
On 08/08/2011 07:23 AM, Sergei Shtylyov wrote: > Please indent with tabs, not spaces. Also, doesn't this code generate > warning (code before declarations)? Only with -Wdeclaration-after-statement, which U-boot doesn't set. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc/85xx: Add ULPI and UTMI USB Phy support for P1010/P1014
Hi,
2011/7/1 Kumar Gala :
> From: Ramneek Mehresh
>
> Add UTMI and ULPI PHY support for USB controller on qoriq series of
> processors with internal UTMI PHY implemented, for example P1010/P1014
> - Use both getenv() and hwconfig to get USB phy type till getenv()
> is depricated
> - Introduce CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY to specify if soc
> has internal UTMI phy
>
> Signed-off-by: Ramneek Mehresh
> CC: Remy Bohmer
> Signed-off-by: Kumar Gala
> ---
> arch/powerpc/include/asm/config_mpc85xx.h | 2 +
> drivers/usb/host/ehci-fsl.c | 37 ++--
> 2 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
> b/arch/powerpc/include/asm/config_mpc85xx.h
> index 04ca989..d9d04e7 100644
> --- a/arch/powerpc/include/asm/config_mpc85xx.h
> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
> @@ -97,6 +97,7 @@
> #define CONFIG_NUM_DDR_CONTROLLERS 1
> #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
> #define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.2"
> +#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>
> /* P1011 is single core version of P1020 */
> #elif defined(CONFIG_P1011)
> @@ -141,6 +142,7 @@
> #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
> #define CONFIG_NUM_DDR_CONTROLLERS 1
> #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
> +#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>
> /* P1015 is single core version of P1024 */
> #elif defined(CONFIG_P1015)
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index 6e0043a..66b7da5 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -1,5 +1,5 @@
> /*
> - * (C) Copyright 2009 Freescale Semiconductor, Inc.
> + * (C) Copyright 2009, 2011 Freescale Semiconductor, Inc.
> *
> * (C) Copyright 2008, Excito Elektronik i Sk=E5ne AB
> *
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ehci.h"
> #include "ehci-core.h"
> @@ -39,6 +40,11 @@
> int ehci_hcd_init(void)
> {
> struct usb_ehci *ehci;
> + char usb_phy[5];
> + const char *phy_type = NULL;
> + size_t len;
> +
> + usb_phy[0] = '\0';
>
> ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
> hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
> @@ -52,10 +58,35 @@ int ehci_hcd_init(void)
> out_be32(&ehci->snoop2, 0x8000 | SNOOP_SIZE_2GB);
>
> /* Init phy */
> - if (!strcmp(getenv("usb_phy_type"), "utmi"))
> - out_le32(&(hcor->or_portsc[0]), PORT_PTS_UTMI);
> + if (hwconfig_sub("usb1", "phy_type"))
> + phy_type = hwconfig_subarg("usb1", "phy_type", &len);
> else
> + phy_type = getenv("usb_phy_type");
Please insert an empty line here for readability.
> + if (!phy_type) {
> +#ifdef CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
> + /* if none specified assume internal UTMI */
> + strcpy(usb_phy, "utmi");
> + phy_type = usb_phy;
> +#else
> + printf("WARNING: USB phy type not defined !!\n");
> + return -1;
> +#endif
> + }
Alignment is messy due to this patch. Please fix.
> + if (!strcmp(phy_type, "utmi")) {
> +#if defined(CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY)
> + setbits_be32(&ehci->control, PHY_CLK_SEL_UTMI);
> + setbits_be32(&ehci->control, UTMI_PHY_EN);
> + udelay(1000); /* delay required for PHY Clk to appear */
> +#endif
> + out_le32(&(hcor->or_portsc[0]), PORT_PTS_UTMI);
> + } else {
> +#if defined(CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY)
> + clrbits_be32(&ehci->control, UTMI_PHY_EN);
> + setbits_be32(&ehci->control, PHY_CLK_SEL_ULPI);
> + udelay(1000); /* delay required for PHY Clk to appear */
> +#endif
> out_le32(&(hcor->or_portsc[0]), PORT_PTS_ULPI);
> + }
The ifdef-ery makes the code somewhat messy as well. Can it be written
somewhat else?
Apart from that and the style issues, no remarks or concerns.
Kind regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
