Re: [U-Boot] [PATCH] ARM: add __aeabi_unwind_cpp_pr0() function to avoid linker complaints
Hello Wolfgang,
On 05/10/10 21:08, Wolfgang Denk wrote:
> Signed-off-by: Wolfgang Denk
> ---
> arch/arm/lib/eabi_compat.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c
> index 86eacf1..eb3e26d 100644
> --- a/arch/arm/lib/eabi_compat.c
> +++ b/arch/arm/lib/eabi_compat.c
> @@ -16,3 +16,8 @@ int raise (int signum)
> printf("raise: Signal # %d caught\n", signum);
> return 0;
> }
> +
> +/* Dummy function to avoid linker complaints */
> +void __aeabi_unwind_cpp_pr0(void)
> +{
> +};
Thanks for the patch.
Compiled for and tested on Devkit8000
Tested-by: Thomas Weber
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Devkit8000: Fix compilation after changes in dm9000
Hello Marek,
On 05/11/10 04:25, Marek Vasut wrote:
> Dne Út 11. května 2010 05:47:40 Marek Vasut napsal(a):
>> Dne Út 11. května 2010 05:28:38 Marek Vasut napsal(a):
>>> Dne Pá 7. května 2010 18:58:34 Thomas Weber napsal(a):
On 07.05.2010 17:15, Wolfgang Denk wrote:
Dear Thomas Weber,
In message <1273242366-6552-1-git-send-email-we...@corscience.de>
<1273242366-6552-1-git-send-email-we...@corscience.de> you wrote:
In commit a45dde2293c816138e53c26eca6fd0322583f9a6 the I/O accessor
for
the DM9000 is changed.
The definition of __io is required to use the standard I/O accessors
from asm/io.h.
Signed-off-by: Thomas Weber
---
include/configs/devkit8000.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/devkit8000.h
b/include/configs/devkit8000.h index 7d1332f..6e53c0d 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -31,6 +31,7 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+
Unrelated (und unneeded) change. Please omit this.
/* High Level Configuration Options */
#define CONFIG_ARMCORTEXA81 /* This is an ARM V7 CPU core */
#define CONFIG_OMAP 1 /* in a TI OMAP core */
@@ -79,6 +80,7 @@
#define CONFIG_DM9000_USE_16BIT 1
#define CONFIG_DM9000_NO_SROM 1
#undefCONFIG_DM9000_DEBUG
+#define __io
Hm... the commit message says "__io is required to use the standard
I/O accessors" - but I don't see any of these in this definition here?
Best regards,
Wolfgang Denk
Hi,
thanks for reviewing the patch.
In
dm9000.c is included and outb, etc. used
and in
arch/arm/include/asm/io.h +201
I found #ifdef __io
but __io wasn't defined.
I also think, that all arm-boards that uses the dm9000 will have this
problem at the moment. I tried to compile at91sam9261 and got the same
problem.
Because I have an other problem with gcc I cannot compile completely.
Thomas
>>>
>>> 52dbac69c27dee67a4c051b1055d93b0ac4e2062 <-- this one probably causes the
>>> other errors
>>
>> Interesting ... the commit 'doesn't seem to be there'
>>
>> It seems someone made some inccorect operation with git and some patches
>> were forgotten/rewritten by old files.
>
> I take what I said back, it's there, I mislooked.
>
> But, here's a workaround-patch (unapplicable obviously). Conclusion from why
> it
> works with this is up to you:
>
> diff --git a/include/common.h b/include/common.h
> index 8bca04f..ce67403 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -218,7 +218,7 @@ voidhang(void) __attribute__
> ((noreturn));
> /* */
> phys_size_t initdram (int);
> intdisplay_options (void);
> -void print_size(unsigned long long, const char *);
> +void print_size(unsigned /*long*/ long, const char *);
> intprint_buffer (ulong addr, void* data, uint width, uint count, uint
> linelen);
>
> /* common/main.c */
> diff --git a/lib/display_options.c b/lib/display_options.c
> index 86df05d..146e50a 100644
> --- a/lib/display_options.c
> +++ b/lib/display_options.c
> @@ -43,11 +43,11 @@ int display_options (void)
> * xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string
> * (like "\n")
> */
> -void print_size(unsigned long long size, const char *s)
> +void print_size(unsigned /*long*/ long size, const char *s)
> {
> unsigned long m = 0, n;
> - static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
> - unsigned long long d = 1ULL << (10 * ARRAY_SIZE(names));
> + static const char names[] = {/*'E', 'P', 'T',*/ 'G', 'M', 'K'};
> + unsigned long /*long*/ d = 1ULL << (10 * ARRAY_SIZE(names));
> char c = 0;
> unsigned int i;
>
> @@ -59,7 +59,7 @@ void print_size(unsigned long long size, const char *s)
> }
>
> if (!c) {
> - printf("%llu Bytes%s", size, s);
> + printf("%lu Bytes%s", size, s);
> return;
> }
I think you need:
Message-Id: <1273525682-27308-1-git-send-email...@denx.de>
Thomas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AX88180: add missing init prototype
Ben: ive pushed all these AX88180 patches to here so you can pull them in order easier: git://git.denx.de/u-boot-blackfin.git for-net -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AX88180: use standard I/O accessors
The current dm9000x driver accesses its memory mapped registers directly
instead of using the standard I/O accessors. This can cause problems on
Blackfin systems as the accesses can get out of order. So convert the
direct volatile dereferences to use the normal in/out macros.
Signed-off-by: Mike Frysinger
Tested-by: Hoan Hoang
---
drivers/net/ax88180.h | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ax88180.h b/drivers/net/ax88180.h
index 9a324bd..7d75eb8 100644
--- a/drivers/net/ax88180.h
+++ b/drivers/net/ax88180.h
@@ -19,6 +19,7 @@
#ifndef _AX88180_H_
#define _AX88180_H_
+#include
#include
#include
@@ -354,7 +355,7 @@ struct ax88180_private {
static inline unsigned short INW (struct eth_device *dev, unsigned long addr)
{
- return le16_to_cpu (*(volatile unsigned short *) (addr + dev->iobase));
+ return le16_to_cpu(inw(addr + dev->iobase));
}
/*
@@ -363,32 +364,32 @@ static inline unsigned short INW (struct eth_device *dev,
unsigned long addr)
#if defined (CONFIG_DRIVER_AX88180_16BIT)
static inline void OUTW (struct eth_device *dev, unsigned short command,
unsigned long addr)
{
- *(volatile unsigned short *) ((addr + dev->iobase)) = cpu_to_le16
(command);
+ outw(cpu_to_le16(command), addr + dev->iobase);
}
static inline unsigned short READ_RXBUF (struct eth_device *dev)
{
- return le16_to_cpu (*(volatile unsigned short *) (RXBUFFER_START +
dev->iobase));
+ return le16_to_cpu(inw(RXBUFFER_START + dev->iobase));
}
static inline void WRITE_TXBUF (struct eth_device *dev, unsigned short data)
{
- *(volatile unsigned short *) ((TXBUFFER_START + dev->iobase)) =
cpu_to_le16 (data);
+ outw(cpu_to_le16(data), dev->iobase + TXBUFFER_START);
}
#else
static inline void OUTW (struct eth_device *dev, unsigned short command,
unsigned long addr)
{
- *(volatile unsigned long *) ((addr + dev->iobase)) = cpu_to_le32
(command);
+ outl(cpu_to_le32(command), addr + dev->iobase);
}
static inline unsigned long READ_RXBUF (struct eth_device *dev)
{
- return le32_to_cpu (*(volatile unsigned long *) (RXBUFFER_START +
dev->iobase));
+ return le32_to_cpu(inl(RXBUFFER_START + dev->iobase));
}
static inline void WRITE_TXBUF (struct eth_device *dev, unsigned long data)
{
- *(volatile unsigned long *) ((TXBUFFER_START + dev->iobase)) =
cpu_to_le32 (data);
+ outl(cpu_to_le32(data), dev->iobase + TXBUFFER_START);
}
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AX88180: make OUTW handle 32bit/16bit defines too
From: Hoan Hoang
The current OUTW function is always defined as a 16bit function, but this
doesn't work correctly when using the 32bit access mode. So define it as
a 32bit function when in 32bit mode so things work correctly on Blackfin
32bit LE systems.
Signed-off-by: Hoan Hoang
Signed-off-by: Mike Frysinger
---
drivers/net/ax88180.h | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ax88180.h b/drivers/net/ax88180.h
index f26a91b..9a324bd 100644
--- a/drivers/net/ax88180.h
+++ b/drivers/net/ax88180.h
@@ -357,15 +357,15 @@ static inline unsigned short INW (struct eth_device *dev,
unsigned long addr)
return le16_to_cpu (*(volatile unsigned short *) (addr + dev->iobase));
}
+/*
+ Access RXBUFFER_START/TXBUFFER_START to read RX buffer/write TX buffer
+*/
+#if defined (CONFIG_DRIVER_AX88180_16BIT)
static inline void OUTW (struct eth_device *dev, unsigned short command,
unsigned long addr)
{
*(volatile unsigned short *) ((addr + dev->iobase)) = cpu_to_le16
(command);
}
-/*
- Access RXBUFFER_START/TXBUFFER_START to read RX buffer/write TX buffer
-*/
-#if defined (CONFIG_DRIVER_AX88180_16BIT)
static inline unsigned short READ_RXBUF (struct eth_device *dev)
{
return le16_to_cpu (*(volatile unsigned short *) (RXBUFFER_START +
dev->iobase));
@@ -376,6 +376,11 @@ static inline void WRITE_TXBUF (struct eth_device *dev,
unsigned short data)
*(volatile unsigned short *) ((TXBUFFER_START + dev->iobase)) =
cpu_to_le16 (data);
}
#else
+static inline void OUTW (struct eth_device *dev, unsigned short command,
unsigned long addr)
+{
+ *(volatile unsigned long *) ((addr + dev->iobase)) = cpu_to_le32
(command);
+}
+
static inline unsigned long READ_RXBUF (struct eth_device *dev)
{
return le32_to_cpu (*(volatile unsigned long *) (RXBUFFER_START +
dev->iobase));
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AX88180: add support for the Marvell 88E1118 phy
From: Hoan Hoang
Some places in the current code equate the Marvell 88E PHY as the family
when in reality it's a subpart of the Alaska family. So once we generalize
that, add support for the 88E1118 PHY.
Signed-off-by: Hoan Hoang
Signed-off-by: Mike Frysinger
---
drivers/net/ax88180.c | 33 -
drivers/net/ax88180.h | 30 +++---
2 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ax88180.c b/drivers/net/ax88180.c
index fa2e212..bc3e6ad 100644
--- a/drivers/net/ax88180.c
+++ b/drivers/net/ax88180.c
@@ -267,20 +267,35 @@ static int ax88180_phy_initial (struct eth_device *dev)
{
priv->PhyAddr = phyaddr;
priv->PhyID0 = ax88180_mdio_read(dev, MII_PHYSID1);
+ priv->PhyID1 = ax88180_mdio_read(dev, MII_PHYSID2);
switch (priv->PhyID0) {
- case MARVELL_88E_PHYSID0:
- debug("ax88180: Found Marvell 88E PHY."
+ case MARVELL_ALASKA_PHYSID0:
+ debug("ax88180: Found Marvell Alaska PHY family."
" (PHY Addr=0x%x)\n", priv->PhyAddr);
- tmp_regval = ax88180_mdio_read(dev, M88_EXT_SSR);
- if ((tmp_regval & HWCFG_MODE_MASK) !=
RGMII_COPPER_MODE) {
- ax88180_mdio_write(dev, M88_EXT_SCR,
DEFAULT_EXT_SCR);
- if (ax88180_phy_reset(dev) < 0)
- return 0;
- ax88180_mdio_write(dev, M88_IER,
LINK_CHANGE_INT);
+ switch (priv->PhyID1) {
+ case MARVELL_88E1118_PHYSID1:
+ ax88180_mdio_write(dev, M88E1118_PAGE_SEL, 2);
+ ax88180_mdio_write(dev, M88E1118_CR,
+ M88E1118_CR_DEFAULT);
+ ax88180_mdio_write(dev, M88E1118_PAGE_SEL, 3);
+ ax88180_mdio_write(dev, M88E1118_LEDCTL,
+ M88E1118_LEDCTL_DEFAULT);
+ ax88180_mdio_write(dev, M88E1118_LEDMIX,
+ M88E1118_LEDMIX_LED050 |
M88E1118_LEDMIX_LED150 | 0x15);
+ ax88180_mdio_write(dev, M88E1118_PAGE_SEL, 0);
+ default: /* Default to 88E Phy */
+ tmp_regval = ax88180_mdio_read(dev,
M88E_EXT_SSR);
+ if ((tmp_regval & HWCFG_MODE_MASK) !=
RGMII_COPPER_MODE)
+ ax88180_mdio_write(dev,
M88E_EXT_SCR,
+ DEFAULT_EXT_SCR);
}
+ if (ax88180_phy_reset(dev) < 0)
+ return 0;
+ ax88180_mdio_write(dev, M88_IER, LINK_CHANGE_INT);
+
return 1;
case CICADA_CIS8201_PHYSID0:
@@ -358,7 +373,7 @@ static void ax88180_media_config (struct eth_device *dev)
/* Get real media mode here */
switch (priv->PhyID0) {
- case MARVELL_88E_PHYSID0:
+ case MARVELL_ALASKA_PHYSID0:
RealMediaMode = get_MarvellPHY_media_mode(dev);
break;
case CICADA_CIS8201_PHYSID0:
diff --git a/drivers/net/ax88180.h b/drivers/net/ax88180.h
index c793e92..f26a91b 100644
--- a/drivers/net/ax88180.h
+++ b/drivers/net/ax88180.h
@@ -33,6 +33,7 @@ struct ax88180_private {
unsigned char PadSize;
unsigned short PhyAddr;
unsigned short PhyID0;
+ unsigned short PhyID1;
unsigned short FirstTxDesc;
unsigned short NextTxDesc;
ax88180_link_state LinkState;
@@ -63,7 +64,8 @@ struct ax88180_private {
/* Max Rx Jumbo size is 15K Bytes */
#define MAX_RX_SIZE0x3C00
-#define MARVELL_88E_PHYSID00x0141
+#define MARVELL_ALASKA_PHYSID0 0x141
+#define MARVELL_88E1118_PHYSID10xE40
#define CICADA_CIS8201_PHYSID0 0x000F
@@ -296,14 +298,36 @@ struct ax88180_private {
#define LINK_CHANGE_INT 0x0400
#define M88_ISR0x0013
#define LINK_CHANGE_STATUS 0x0400
-#define M88_EXT_SCR0x0014
+#define M88E_EXT_SCR 0x0014
#define RGMII_RXCLK_DELAY0x0080
#define RGMII_TXCLK_DELAY0x0002
#define DEFAULT_EXT_SCR (RGMII_TXCLK_DELAY | RGMII_RXCLK_DELAY)
-#define M88_EXT_SSR0x001B
+#define M88E_EXT_SSR 0x001B
#define HWCFG_MODE_MASK 0x000F
#define RGMII_COPPER_MODE0x000B
+/* Marvell 88E1118 Gigabit PHY Register Definition */
+#define M88E1118_CR0x14
+ #define M88E1118_CR_RGMII_RXCLK_DELAY0x0020
+ #define M88E1118_CR_RGMII_TXCLK_DELAY0x0010
+ #define
Re: [U-Boot] [PATCH v3] Support for devices with FAT32 PBR
Dear Sergei,
I have readen git-format-patch commands manual and I don't find any
option to create a single patch, by default creates a patch per commit
change.
How can I create a single patch?
I would apreciate any help.
Best regards.
El lun, 10-05-2010 a las 19:22 +0400, Sergei Shtylyov escribió:
> Hello.
>
> Igor Luri wrote:
>
> > Signed-off-by: Igor Luri
> > ---
> > disk/part_dos.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/disk/part_dos.c b/disk/part_dos.c
> > index 887b75e..d91f773 100644
> > --- a/disk/part_dos.c
> > +++ b/disk/part_dos.c
> > @@ -77,7 +77,8 @@ static int test_block_type(unsigned char *buffer)
> > (buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) ) {
> > return (-1);
> > } /* no DOS Signature at all */
> > - if(strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0)
> > + if((strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0) ||
> > + (strncmp((char *)&buffer[DOS_PBR_FAT32_FSTYPE_OFFSET],"FAT32",5)==0)
> > )
> > return DOS_PBR; /* is PBR */
> > return DOS_MBR; /* Is MBR */
> > }
> >
>
>This was not a single patch, that was tree patches in the single
> email. :-)
>
> WBR, Sergei
>
>
--
Igor Luri
R&D Software Department
Fagor Aotek S. Coop.
P. O. Box 144
E-20500 Mondragón-Arrasate
Tel.++34 943 71 92 00
++34 943 71 92 01 (Ext. 44268)
Fax.++34 943 79 92 03
www.aotek.es
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V3 1/2] AM35x: Add support for AM3517EVM
> -Original Message- > From: Hiremath, Vaibhav > Sent: Thursday, May 06, 2010 10:53 PM > To: u-boot@lists.denx.de > Cc: w...@denx.de; t...@bumblecow.com; Paulraj, Sandeep; Hiremath, Vaibhav; > Premi, Sanjeev > Subject: [PATCH-V3 1/2] AM35x: Add support for AM3517EVM > > From: Vaibhav Hiremath > > This patch adds basic support for the AM3517EVM. > It includes: > - Board int file (.c and .h) > - Default configuration file > - Updates for Makefile > > Changes from V2: > - Removed trailing spaces > - Updated MAINTAINERS & MAKEALL for am3517_evm > [Hiremath, Vaibhav] Denk, If we do not have any further comments, can we merge these patches? Thanks, Vaibhav > Signed-off-by: Vaibhav Hiremath > Signed-off-by: Sanjeev Premi > --- > MAINTAINERS |4 + > MAKEALL |1 + > Makefile |3 + > arch/arm/include/asm/arch-omap3/mux.h | 38 +++- > board/logicpd/am3517evm/Makefile | 46 > board/logicpd/am3517evm/am3517evm.c | 76 ++ > board/logicpd/am3517evm/am3517evm.h | 405 > + > board/logicpd/am3517evm/config.mk | 30 +++ > include/configs/am3517_evm.h | 296 > 9 files changed, 898 insertions(+), 1 deletions(-) > create mode 100644 board/logicpd/am3517evm/Makefile > create mode 100644 board/logicpd/am3517evm/am3517evm.c > create mode 100644 board/logicpd/am3517evm/am3517evm.h > create mode 100644 board/logicpd/am3517evm/config.mk > create mode 100644 include/configs/am3517_evm.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5cbc845..0bc65e1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -798,6 +798,10 @@ Alex Z > lartSA1100 > dnp1110 SA1110 > > +Vaibhav Hiremath > + > + am3517_evm ARM CORTEX-A8 (AM35x SoC) > + > - > > Unknown / orphaned boards: > diff --git a/MAKEALL b/MAKEALL > index bb09627..cd59daa 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -641,6 +641,7 @@ LIST_ARM11=" \ > ## ARM Cortex-A8 Systems > # > LIST_ARM_CORTEX_A8=" \ > + am3517_evm \ > devkit8000 \ > mx51evk \ > omap3_beagle\ > diff --git a/Makefile b/Makefile > index 2d96574..57b3491 100644 > --- a/Makefile > +++ b/Makefile > @@ -3155,6 +3155,9 @@ SMN42_config: unconfig > ## ARM CORTEX Systems > # > > +am3517_evm_config : unconfig > + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 am3517evm logicpd omap3 > + > devkit8000_config : unconfig > @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 timll omap3 > > diff --git a/arch/arm/include/asm/arch-omap3/mux.h > b/arch/arm/include/asm/arch-omap3/mux.h > index 0c01c73..ffeb982 100644 > --- a/arch/arm/include/asm/arch-omap3/mux.h > +++ b/arch/arm/include/asm/arch-omap3/mux.h > @@ -283,7 +283,7 @@ > /*Control and debug */ > #define CONTROL_PADCONF_SYS_32K 0x0A04 > #define CONTROL_PADCONF_SYS_CLKREQ 0x0A06 > -#define CONTROL_PADCONF_SYS_NIRQ 0x01E0 > +#define CONTROL_PADCONF_SYS_NRESWARM 0x0A08 > #define CONTROL_PADCONF_SYS_BOOT00x0A0A > #define CONTROL_PADCONF_SYS_BOOT10x0A0C > #define CONTROL_PADCONF_SYS_BOOT20x0A0E > @@ -337,6 +337,7 @@ > #define CONTROL_PADCONF_ETK_D14_ES2 0x05F8 > #define CONTROL_PADCONF_ETK_D15_ES2 0x05FA > /*Die to Die */ > +#define CONTROL_PADCONF_SYS_NIRQ 0x01E0 > #define CONTROL_PADCONF_D2D_MCAD00x01E4 > #define CONTROL_PADCONF_D2D_MCAD10x01E6 > #define CONTROL_PADCONF_D2D_MCAD20x01E8 > @@ -403,6 +404,41 @@ > #define CONTROL_PADCONF_D2D_SBUSFLAG 0x0260 > #define CONTROL_PADCONF_SDRC_CKE00x0262 > #define CONTROL_PADCONF_SDRC_CKE10x0264 > +/* AM3517 specific */ > +#define CONTROL_PADCONF_CCDC_PCLK0x01E4 > +#define CONTROL_PADCONF_CCDC_FIELD 0x01E6 > +#define CONTROL_PADCONF_CCDC_HD 0x01E8 > +#define CONTROL_PADCONF_CCDC_VD 0x01EA > +#define CONTROL_PADCONF_CCDC_WEN 0x01EC > +#define CONTROL_PADCONF_CCDC_DATA0 0x01EE > +#define CONTROL_PADCONF_CCDC_DATA1 0x01F0 > +#define CONTROL_PADCONF_CCDC_DATA2 0x01F2 > +#define CONTROL_PADCONF_CCDC_DATA3 0x01F4 > +#define CONTROL_PADCONF_CCDC_DATA4 0x01F6 > +#define CONTROL_PADCONF_CCDC_DATA5 0x01F8 > +#define CONTROL_PADCONF_CCDC_DATA6 0x01FA > +#define CONTROL_PADCONF_CCDC_DATA7 0x01FC > +#define CONTROL_PADCONF_RMII_MDIO_DATA 0x01FE > +#define CONTROL_PADCONF_RMII_MDIO_CLK0x0200 > +#define CONTROL_PADCONF_RMII_RXD00x0202 > +#define CONTROL_PADCONF_RMII_RXD10x0204 > +#define CONTROL_PADCONF_RMII_CRS_DV 0x0206 > +#define CONTROL_PADCONF_RMII_RXER0x0208 > +#define CONTROL_P
Re: [U-Boot] [PATCH-V3 1/2] omap3: Calculate CS1 size only when SDRC is initialized for CS1
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Thursday, May 06, 2010 10:52 PM
> To: u-boot@lists.denx.de
> Cc: w...@denx.de; t...@bumblecow.com; Paulraj, Sandeep; Hiremath, Vaibhav;
> Premi, Sanjeev
> Subject: [PATCH-V3 1/2] omap3: Calculate CS1 size only when SDRC is
> initialized for CS1
>
> From: Vaibhav Hiremath
>
> The patch makes sure that size for SDRC CS1 gets calculated
> only when the CS1 SDRC is initialized.
>
[Hiremath, Vaibhav] Denk,
If we do not have any further comments, can we merge these patches?
Thanks,
Vaibhav
> Signed-off-by: Vaibhav Hiremath
> Signed-off-by: Sanjeev Premi
> ---
> arch/arm/cpu/arm_cortexa8/omap3/board.c |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/arm_cortexa8/omap3/board.c
> b/arch/arm/cpu/arm_cortexa8/omap3/board.c
> index 7b78fa4..69a08fd 100644
> --- a/arch/arm/cpu/arm_cortexa8/omap3/board.c
> +++ b/arch/arm/cpu/arm_cortexa8/omap3/board.c
> @@ -282,6 +282,8 @@ int dram_init(void)
> DECLARE_GLOBAL_DATA_PTR;
> unsigned int size0 = 0, size1 = 0;
>
> + size0 = get_sdr_cs_size(CS0);
> +
> /*
>* If a second bank of DDR is attached to CS1 this is
>* where it can be started. Early init code will init
> @@ -290,10 +292,9 @@ int dram_init(void)
> if ((sysinfo.mtype == DDR_COMBO) || (sysinfo.mtype == DDR_STACKED)) {
> do_sdrc_init(CS1, NOT_EARLY);
> make_cs1_contiguous();
> - }
>
> - size0 = get_sdr_cs_size(CS0);
> - size1 = get_sdr_cs_size(CS1);
> + size1 = get_sdr_cs_size(CS1);
> + }
>
> gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> gd->bd->bi_dram[0].size = size0;
> --
> 1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V5] OMAP3EVM: Added NAND support
> -Original Message- > From: Hiremath, Vaibhav > Sent: Thursday, May 06, 2010 10:49 PM > To: u-boot@lists.denx.de > Cc: w...@denx.de; t...@bumblecow.com; Paulraj, Sandeep; Hiremath, Vaibhav > Subject: [PATCH-V5] OMAP3EVM: Added NAND support > > From: Vaibhav Hiremath > > The EVMS have been shipping with NAND (instead of OneNAND) as default. > So, this patch sets NAND as default. > > To choose OneNAND, define CMD_ONENAND instead of CMD_NAND in the > config file omap3_evm.h, > > Changes From V4 :- > - Removed #undef ONENAND line (comment from Denk) > Changes from V3 :- > - Refreshed against latest u-boot/master > Changes from V2 :- > - Added undef statement for CMD_ONENAND. > [Hiremath, Vaibhav] Denk, If we do not have any further comments, can we merge these patches? Thanks, Vaibhav > Signed-off-by: Vaibhav Hiremath > --- > include/configs/omap3_evm.h |8 +++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h > index 0d99f7d..88af492 100644 > --- a/include/configs/omap3_evm.h > +++ b/include/configs/omap3_evm.h > @@ -151,7 +151,7 @@ > > #define CONFIG_CMD_I2C /* I2C serial bus support */ > #define CONFIG_CMD_MMC /* MMC support */ > -#define CONFIG_CMD_ONENAND /* ONENAND support */ > +#define CONFIG_CMD_NAND /* NAND support */ > #define CONFIG_CMD_DHCP > #define CONFIG_CMD_PING > > @@ -306,7 +306,13 @@ > #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE > #define CONFIG_SYS_ONENAND_BASE ONENAND_MAP > > +#if defined(CONFIG_CMD_NAND) > +#define CONFIG_NAND_OMAP_GPMC > +#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 > +#define CONFIG_ENV_IS_IN_NAND > +#elif defined(CONFIG_CMD_ONENAND) > #define CONFIG_ENV_IS_IN_ONENAND 1 > +#endif > #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ > #define SMNAND_ENV_OFFSET0x26 /* environment starts here */ > > -- > 1.6.2.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Devkit8000: Fix compilation after changes in dm9000
Dne Út 11. května 2010 05:47:40 Marek Vasut napsal(a):
> Dne Út 11. května 2010 05:28:38 Marek Vasut napsal(a):
> > Dne Pá 7. května 2010 18:58:34 Thomas Weber napsal(a):
> > > On 07.05.2010 17:15, Wolfgang Denk wrote:
> > > Dear Thomas Weber,
> > >
> > > In message <1273242366-6552-1-git-send-email-we...@corscience.de>
> > >
> > > <1273242366-6552-1-git-send-email-we...@corscience.de> you wrote:
> > > In commit a45dde2293c816138e53c26eca6fd0322583f9a6 the I/O accessor
> > > for
> > >
> > > the DM9000 is changed.
> > >
> > > The definition of __io is required to use the standard I/O accessors
> > > from asm/io.h.
> > >
> > > Signed-off-by: Thomas Weber
> > > ---
> > >
> > > include/configs/devkit8000.h |2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/include/configs/devkit8000.h
> > > b/include/configs/devkit8000.h index 7d1332f..6e53c0d 100644
> > > --- a/include/configs/devkit8000.h
> > > +++ b/include/configs/devkit8000.h
> > > @@ -31,6 +31,7 @@
> > >
> > > #ifndef __CONFIG_H
> > > #define __CONFIG_H
> > >
> > > +
> > >
> > > Unrelated (und unneeded) change. Please omit this.
> > >
> > > /* High Level Configuration Options */
> > >
> > > #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */
> > > #define CONFIG_OMAP 1 /* in a TI OMAP core */
> > >
> > > @@ -79,6 +80,7 @@
> > >
> > > #define CONFIG_DM9000_USE_16BIT 1
> > > #define CONFIG_DM9000_NO_SROM1
> > > #undef CONFIG_DM9000_DEBUG
> > >
> > > +#define __io
> > >
> > > Hm... the commit message says "__io is required to use the standard
> > >
> > > I/O accessors" - but I don't see any of these in this definition here?
> > >
> > > Best regards,
> > >
> > > Wolfgang Denk
> > >
> > > Hi,
> > >
> > > thanks for reviewing the patch.
> > >
> > > In
> > > dm9000.c is included and outb, etc. used
> > > and in
> > > arch/arm/include/asm/io.h +201
> > > I found #ifdef __io
> > > but __io wasn't defined.
> > >
> > > I also think, that all arm-boards that uses the dm9000 will have this
> > > problem at the moment. I tried to compile at91sam9261 and got the same
> > > problem.
> > >
> > > Because I have an other problem with gcc I cannot compile completely.
> > >
> > > Thomas
> >
> > 52dbac69c27dee67a4c051b1055d93b0ac4e2062 <-- this one probably causes the
> > other errors
>
> Interesting ... the commit 'doesn't seem to be there'
>
> It seems someone made some inccorect operation with git and some patches
> were forgotten/rewritten by old files.
I take what I said back, it's there, I mislooked.
But, here's a workaround-patch (unapplicable obviously). Conclusion from why it
works with this is up to you:
diff --git a/include/common.h b/include/common.h
index 8bca04f..ce67403 100644
--- a/include/common.h
+++ b/include/common.h
@@ -218,7 +218,7 @@ voidhang(void) __attribute__
((noreturn));
/* */
phys_size_t initdram (int);
intdisplay_options (void);
-void print_size(unsigned long long, const char *);
+void print_size(unsigned /*long*/ long, const char *);
intprint_buffer (ulong addr, void* data, uint width, uint count, uint
linelen);
/* common/main.c */
diff --git a/lib/display_options.c b/lib/display_options.c
index 86df05d..146e50a 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -43,11 +43,11 @@ int display_options (void)
* xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string
* (like "\n")
*/
-void print_size(unsigned long long size, const char *s)
+void print_size(unsigned /*long*/ long size, const char *s)
{
unsigned long m = 0, n;
- static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
- unsigned long long d = 1ULL << (10 * ARRAY_SIZE(names));
+ static const char names[] = {/*'E', 'P', 'T',*/ 'G', 'M', 'K'};
+ unsigned long /*long*/ d = 1ULL << (10 * ARRAY_SIZE(names));
char c = 0;
unsigned int i;
@@ -59,7 +59,7 @@ void print_size(unsigned long long size, const char *s)
}
if (!c) {
- printf("%llu Bytes%s", size, s);
+ printf("%lu Bytes%s", size, s);
return;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Devkit8000: Fix compilation after changes in dm9000
Dne Út 11. května 2010 05:28:38 Marek Vasut napsal(a): > Dne Pá 7. května 2010 18:58:34 Thomas Weber napsal(a): > > On 07.05.2010 17:15, Wolfgang Denk wrote: > > Dear Thomas Weber, > > > > In message <1273242366-6552-1-git-send-email-we...@corscience.de> > > > > <1273242366-6552-1-git-send-email-we...@corscience.de> you wrote: > > In commit a45dde2293c816138e53c26eca6fd0322583f9a6 the I/O accessor for > > > > the DM9000 is changed. > > > > The definition of __io is required to use the standard I/O accessors from > > asm/io.h. > > > > Signed-off-by: Thomas Weber > > --- > > > > include/configs/devkit8000.h |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h > > index 7d1332f..6e53c0d 100644 > > --- a/include/configs/devkit8000.h > > +++ b/include/configs/devkit8000.h > > @@ -31,6 +31,7 @@ > > > > #ifndef __CONFIG_H > > #define __CONFIG_H > > > > + > > > > Unrelated (und unneeded) change. Please omit this. > > > > /* High Level Configuration Options */ > > > > #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ > > #define CONFIG_OMAP1 /* in a TI OMAP core */ > > > > @@ -79,6 +80,7 @@ > > > > #defineCONFIG_DM9000_USE_16BIT 1 > > #define CONFIG_DM9000_NO_SROM 1 > > #undef CONFIG_DM9000_DEBUG > > > > +#define __io > > > > Hm... the commit message says "__io is required to use the standard > > > > I/O accessors" - but I don't see any of these in this definition here? > > > > Best regards, > > > > Wolfgang Denk > > > > Hi, > > > > thanks for reviewing the patch. > > > > In > > dm9000.c is included and outb, etc. used > > and in > > arch/arm/include/asm/io.h +201 > > I found #ifdef __io > > but __io wasn't defined. > > > > I also think, that all arm-boards that uses the dm9000 will have this > > problem at the moment. I tried to compile at91sam9261 and got the same > > problem. > > > > Because I have an other problem with gcc I cannot compile completely. > > > > Thomas > > 52dbac69c27dee67a4c051b1055d93b0ac4e2062 <-- this one probably causes the > other errors Interesting ... the commit 'doesn't seem to be there' It seems someone made some inccorect operation with git and some patches were forgotten/rewritten by old files. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: Fix cache_flush() error and correct cpu_init_crit() comments
Hello Dirk,
On Mon, May 10, 2010 at 10:02 AM, Dirk Behme wrote:
>
> Hi George,
>
> On 05.05.2010 23:09, George G. Davis wrote:
>>
>> The ARM1136 cache_flush() function uses the "mcr p15, 0, rn, c7, c7, 0"
>> instruction which means "Invalidate Both Caches
>
> ... Also flushes the branch target cache"
>
>> " when in fact the intent
>> is to "Clean and Invalidate Entire Data Cache".
>
> Why don't we have to invalidate/flush the I- and BT-Cache here? I.e. why is
> it sufficient to clean & invalidate the D-Cache here, only, and remove the
> existing I- and BT-Cache invalidation/flushing?
Quite frankly I thought for sure that it was handled elsewhere but now
that I look I see that it's not. Meanwhile, I don't think U-Boot is
typically susceptible to self-modifying-code issues anyway (?) and
this isn't likely required but I suppose lack of I+BTB invalidation
could be an issue in some cases, e.g. loading and running a new
version of U-Boot from RAM? So better to be safe and restore the
I+BTB invalidation here.
>
> What's about just adding an additional clean of the data cache before the
> 'invalidate all':
>
> + asm ("mcr p15, 0, %0, c7, c10, 0": :"r" (i)); /* clean entire data cache */
> asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both caches and
> flush btb */
> asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync things */
>
> ?
That works for me.
If there is no more feedback, I'll resubmit an updated patch.
Thansk!
--
Regards,
George
>
> Thanks for finding this and best regards
>
> Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Devkit8000: Fix compilation after changes in dm9000
Dne Pá 7. května 2010 18:58:34 Thomas Weber napsal(a): > On 07.05.2010 17:15, Wolfgang Denk wrote: > > Dear Thomas Weber, > > In message <1273242366-6552-1-git-send-email-we...@corscience.de> > <1273242366-6552-1-git-send-email-we...@corscience.de> you wrote: > > > In commit a45dde2293c816138e53c26eca6fd0322583f9a6 the I/O accessor for > the DM9000 is changed. > > The definition of __io is required to use the standard I/O accessors from > asm/io.h. > > Signed-off-by: Thomas Weber > --- > include/configs/devkit8000.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h > index 7d1332f..6e53c0d 100644 > --- a/include/configs/devkit8000.h > +++ b/include/configs/devkit8000.h > @@ -31,6 +31,7 @@ > #ifndef __CONFIG_H > #define __CONFIG_H > > + > > > Unrelated (und unneeded) change. Please omit this. > > > > /* High Level Configuration Options */ > #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ > #define CONFIG_OMAP 1 /* in a TI OMAP core */ > @@ -79,6 +80,7 @@ > #define CONFIG_DM9000_USE_16BIT 1 > #define CONFIG_DM9000_NO_SROM1 > #undef CONFIG_DM9000_DEBUG > +#define __io > > > Hm... the commit message says "__io is required to use the standard > I/O accessors" - but I don't see any of these in this definition here? > > Best regards, > > Wolfgang Denk > > > > Hi, > thanks for reviewing the patch. > > In > dm9000.c is included and outb, etc. used > and in > arch/arm/include/asm/io.h +201 > I found #ifdef __io > but __io wasn't defined. > > I also think, that all arm-boards that uses the dm9000 will have this > problem at the moment. I tried to compile at91sam9261 and got the same > problem. > > Because I have an other problem with gcc I cannot compile completely. > > Thomas 52dbac69c27dee67a4c051b1055d93b0ac4e2062 <-- this one probably causes the other errors ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Devkit8000: Fix compilation after changes in dm9000
Dne Pá 7. května 2010 18:58:34 Thomas Weber napsal(a): > On 07.05.2010 17:15, Wolfgang Denk wrote: > > Dear Thomas Weber, > > In message <1273242366-6552-1-git-send-email-we...@corscience.de> > <1273242366-6552-1-git-send-email-we...@corscience.de> you wrote: > > > In commit a45dde2293c816138e53c26eca6fd0322583f9a6 the I/O accessor for > the DM9000 is changed. > > The definition of __io is required to use the standard I/O accessors from > asm/io.h. > > Signed-off-by: Thomas Weber > --- > include/configs/devkit8000.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h > index 7d1332f..6e53c0d 100644 > --- a/include/configs/devkit8000.h > +++ b/include/configs/devkit8000.h > @@ -31,6 +31,7 @@ > #ifndef __CONFIG_H > #define __CONFIG_H > > + > > > Unrelated (und unneeded) change. Please omit this. > > > > /* High Level Configuration Options */ > #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ > #define CONFIG_OMAP 1 /* in a TI OMAP core */ > @@ -79,6 +80,7 @@ > #define CONFIG_DM9000_USE_16BIT 1 > #define CONFIG_DM9000_NO_SROM1 > #undef CONFIG_DM9000_DEBUG > +#define __io > > > Hm... the commit message says "__io is required to use the standard > I/O accessors" - but I don't see any of these in this definition here? > > Best regards, > > Wolfgang Denk > > > > Hi, > thanks for reviewing the patch. > > In > dm9000.c is included and outb, etc. used > and in > arch/arm/include/asm/io.h +201 > I found #ifdef __io > but __io wasn't defined. > > I also think, that all arm-boards that uses the dm9000 will have this > problem at the moment. I tried to compile at91sam9261 and got the same > problem. > > Because I have an other problem with gcc I cannot compile completely. > > Thomas It's not a problem with GCC ... I get the same problem as well. And the problem appeared recently. btw. for me, DM9000 is buggered as well. 3699c28e6d16b563629c285311a0ce62a2c4c5d0 still worked fine. I'm bisecting it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2][mpc83xx] Removal of checkboard from spl bootstrap build for SIMPC8313
This patch removes the checkboard function from the build of the 4k bootstrap
section for the SIMPC8313 as it is not needed in the spl build. This will
allow > 100 bytes of extra room for other uses.
Signed-off-by: Ron Madrid
---
board/sheldon/simpc8313/simpc8313.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/sheldon/simpc8313/simpc8313.c
b/board/sheldon/simpc8313/simpc8313.c
index 0235545..cb30b48 100644
--- a/board/sheldon/simpc8313/simpc8313.c
+++ b/board/sheldon/simpc8313/simpc8313.c
@@ -33,13 +33,13 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifndef CONFIG_NAND_SPL
int checkboard(void)
{
puts("Board: Sheldon Instruments SIMPC8313\n");
return 0;
}
-#ifndef CONFIG_NAND_SPL
static struct pci_region pci_regions[] = {
{
bus_start: CONFIG_SYS_PCI1_MEM_BASE,
--
1.5.5.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][mpc83xx] Removal of checkboard from spl bootstrap build for SIMPC8313
--- On Mon, 5/10/10, Ron Madrid wrote: > From: Ron Madrid > Subject: [PATCH][mpc83xx] Removal of checkboard from spl bootstrap build for > SIMPC8313 > To: u-boot@lists.denx.de > Cc: "Ron Madrid" > Date: Monday, May 10, 2010, 3:02 PM > This patch removes the checkboard > function from the build of the 4k bootstrap > section for the SIMPC8313 as it is not needed in the spl > build. This will > allow > 100 bytes of extra room for other uses. Please disregard this patch. There's a little line spacing problem with it. I'm sending a new patch in a few moments. Ron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][mpc83xx] Removal of checkboard from spl bootstrap build for SIMPC8313
This patch removes the checkboard function from the build of the 4k bootstrap
section for the SIMPC8313 as it is not needed in the spl build. This will
allow > 100 bytes of extra room for other uses.
Signed-off-by: Ron Madrid
---
board/sheldon/simpc8313/simpc8313.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/sheldon/simpc8313/simpc8313.c
b/board/sheldon/simpc8313/simpc8313.c
index 0235545..53329af 100644
--- a/board/sheldon/simpc8313/simpc8313.c
+++ b/board/sheldon/simpc8313/simpc8313.c
@@ -33,13 +33,13 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifndef CONFIG_NAND_SPL
+
int checkboard(void)
{
puts("Board: Sheldon Instruments SIMPC8313\n");
return 0;
}
-
-#ifndef CONFIG_NAND_SPL
static struct pci_region pci_regions[] = {
{
bus_start: CONFIG_SYS_PCI1_MEM_BASE,
--
1.5.5.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Read-only env variables
On Mon, May 10, 2010 at 3:43 PM, Wolfgang Denk wrote: >> l - list delimited by ';' (special behavior for setenv) > > Don't do this. ';' has a clear meaning. Using it for other purposes Fair enough... ',' then. >> That seems pretty reasonable. I think I'd like to see the access >> control codes more role based than limitation based. Such as: >> >> u - unique board configuration (mac addr, ser#)... set if not >> set, default override >> s - script in env var... read only, default >> r - runtime variable (ip addr)... set in env, not saveable to flash. > > This is most probably less flexible and more cumbersome to use. It's > easier to define what exactly you want to do (don't allow over- > writing) that finding a role that happens to include this behaviour. > Think also about the end user who wonders why variable "foo" is > considered to be a "unique board configuration" when all you wanted > is to apply certain behaviour. The primary reason for wanting this sort of comes back to the reason I wanted bitmasks in the first place. I want to be able to mix certain access control attributes for different variables. I've added a command called "defaultenv" which comes in really handy in practice here. Basically what it does is revert everything in memory to a default env except for certain (currently hard coded) variables such as ethaddr and serial#. This means that if I rebuild and change a script or boot command, my people can simply load the new u-boot and run "defaultenv;saveenv" to get the updated scripts but not have to redefine all the board unique variables like they would if they just erased their env sectors. I'd like to specify that a variable should be preserved on reverting to default env independent of being read-only or not. Perhaps you would prefer to have each permutation defined as a sum of attributes instead of a role. It's the same thing with a different name. >> > What would be your use of such list vatiables? >> >> Specifically for manipulating the acl and any other list that a user >> may need. Because it will self reference and define its type as a >> list, > > Why would that be needed? > > See my example above: > > setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr The idea was that if you wanted to remove "ethaddr:mo" from the list for instance, you could do so without dealing with the rest of the items in the list. See below. > [Implementation note: the implementation should allow for and ignore > repeated or trailing ',' separators - i.e. something like > "delay:d,,,address:a,ipaddr:i,ethaddr:mo,,serial#:sr,," should work > as well. Reason: see below about incremental building.] I agree. It will be tolerant of this. > Well, we have the editenv command, which makes editing pretty easy. > I fear/feal that adding lists is (1) not really needed and thus most > likely more overhead than benefit, and (2) holds a lot of potential > for causing confusion and conflicts. I haven't used the editenv command, so I'll play with that a bit. It sounds like it will make my concern about removal less of an issue. I'll try it and see how usability feels. > We don't have lists vailables in bash either (or do we?) Not that I'm aware of. Arrays, yes, but that's not what I'm going for here. >> > OK, the "remove entry" function is not that easy here, but which usage >> > do you have in mind that needs that? I never ran into that before. >> >> Consider the case where a variable is defined as a runtime variable, >> but the user would like to change the value and commit that change to >> flash. It would be much more usable if there were a simple way to >> remove an element from a list. > > What to you mean by "runtime variable" or by "change to flash"? I > don;t understand what these terms are supposed to mean. As mentioned > before, "editenv" seems a pretty straightforward way to edit the > settings. What I'm referring to here is being able to specify a variable as r/w while running in u-boot, but that that value will not be written to flash. If the value was defined in flash, then the existing value in flash will be retained when saveenv is called. Again, I'm considering the case with "ipaddr" and family. If the user wishes to change the static IP, then that change should be written to flash. If the user wishes to use dhcp to configure all the network settings, those settings should not be saved to flash (and then used as though they were static settings). Currently if you use dhcp and then want to save some other change in the env, you save all the dhcp settings and the next time the board is powered, you use an address that you have no lease for and probably conflict with another machine. > I feel we should try to make this not overly complicated - don't add > bells and whistles without real need. Also keep in mind that a lot of > power results from being able to dynamically build such settings from > smaller blocks. I
Re: [U-Boot] [PATCH 2/3] libfdt: make fdt_increase_size() available to everyone
On Mon, May 10, 2010 at 4:26 PM, Timur Tabi wrote: > The function fdt_increase_size() increases the size of the device tree by the > given amount. This is useful for any code that wants to add a node or large > property, to avoid the possibility of running out of space. It's much smarter > to have U-Boot increase the size of device tree when it knows it's going to > add data, instead of hoping that the DTS was compiled with the right -p value. > > Signed-off-by: Timur Tabi Please ignore the "2/3". This patch is not part of a series. Wolfgang, we have code (not yet ready to be published) that needs this change. Please apply if you don't have any objections. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] libfdt: make fdt_increase_size() available to everyone
The function fdt_increase_size() increases the size of the device tree by the
given amount. This is useful for any code that wants to add a node or large
property, to avoid the possibility of running out of space. It's much smarter
to have U-Boot increase the size of device tree when it knows it's going to
add data, instead of hoping that the DTS was compiled with the right -p value.
Signed-off-by: Timur Tabi
---
common/fdt_support.c | 20 ++--
include/fdt_support.h |1 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b6f252a..01d635b 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -645,6 +645,16 @@ int fdt_resize(void *blob)
return actualsize;
}
+int fdt_increase_size(void *fdt, int add_len)
+{
+ int newlen;
+
+ newlen = fdt_totalsize(fdt) + add_len;
+
+ /* Open in place with a new len */
+ return fdt_open_into(fdt, fdt, newlen);
+}
+
#ifdef CONFIG_PCI
#define CONFIG_SYS_PCI_NR_INBOUND_WIN 4
@@ -792,16 +802,6 @@ int fdt_del_subnodes(const void *blob, int parent_offset)
return 0;
}
-int fdt_increase_size(void *fdt, int add_len)
-{
- int newlen;
-
- newlen = fdt_totalsize(fdt) + add_len;
-
- /* Open in place with a new len */
- return fdt_open_into(fdt, fdt, newlen);
-}
-
int fdt_del_partitions(void *blob, int parent_offset)
{
const void *prop;
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 9a453af..d70627d 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -78,6 +78,7 @@ void ft_pci_setup(void *blob, bd_t *bd);
void set_working_fdt_addr(void *addr);
int fdt_resize(void *blob);
+int fdt_increase_size(void *fdt, int add_len);
int fdt_fixup_nor_flash_size(void *blob, int cs, u32 size);
--
1.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AX88180: add missing init prototype
sorry Louis, forgot to cc you. ive posted some AX88180 patches for u-boot you might want to review. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
Dear Timur Tabi, In message <4be43218.2060...@freescale.com> you wrote: > > > /home/smcnutt/27xx/u-boot.git/lib/display_options.c:66: undefined > > reference to `__udivdi3' > > /home/smcnutt/27xx/u-boot.git/lib/display_options.c:69: undefined > > reference to `__umoddi3' > > /home/smcnutt/27xx/u-boot.git/lib/display_options.c:70: undefined > > reference to `__udivdi3' > > Man, I knew ARM sucked, but I didn't know it was this bad :-) Heh. Wait. So far we don't even deal with things like caches ;-) > which means that in order to support support printing 64-bit numbers on ARM, > we might need to completely rewrite print_size() to avoid division on 64-bit > numbers. This actually makes little sense to me. Avoiding this here will just make the problem pop up somewhare else later. > Wolfgang, do you have any suggestions? Not really. The thing is that I don't see any such problem: Not really. The thing is that I don't see any such problem: $ ./MAKEALL da830evm Configuring for da830evm board... textdata bss dec hex filename 1556104876 295320 455806 6f47e /work/wd/tmp-da830evm/u-boot - SUMMARY Boards compiled: 1 -- Seems to be a toolchain issue. [ELDK rulez :-)] Ah. With "USE_PRIVATE_LIBGCC=yes" I see this one: undefined reference to `__aeabi_uldivmod' Note that this is __aeabi_uldivmod, not __udivdi3. Which version of compiler / which tool chain are you using? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Sorry, but my karma just ran over your dogma. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 83xx build errors
On Mon, 10 May 2010 14:11:20 -0700 Ron Madrid wrote: > --- On Mon, 5/10/10, Wolfgang Denk wrote: > > are you aware of these MPC8315ERDB_NAND and SIMPC8313_LP > > build errors > > in current mainline code: > > > > NAND bootstrap too big > > I was not aware of this as the last patch I submitted to > mpc83xx built fine with both _LP_ and _SP_ configs. I'm > not quite so git savy, so how am I able to know what's > been changed recently that would have caused this? As it > stands right now my build is 8 bytes too big in > mainstream and in mpc83xx. I git bisected it to this commit: commit 167cdad1372917bc11c636c359aad02625291fa9 Author: Graeme Russ Date: Sat Apr 24 00:05:46 2010 +1000 SERIAL: Enable port-mapped access which (admittedly legitimately) converts NS16550_init to use io accessors, which expanded the size of the generated code. We should find more candidates to delete from the nand_spl code... Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 83xx build errors
--- On Mon, 5/10/10, Wolfgang Denk wrote: > are you aware of these MPC8315ERDB_NAND and SIMPC8313_LP > build errors > in current mainline code: > > NAND bootstrap too big I was not aware of this as the last patch I submitted to mpc83xx built fine with both _LP_ and _SP_ configs. I'm not quite so git savy, so how am I able to know what's been changed recently that would have caused this? As it stands right now my build is 8 bytes too big in mainstream and in mpc83xx. Ron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: add __aeabi_unwind_cpp_pr0() function to avoid linker complaints
Signed-off-by: Wolfgang Denk
---
arch/arm/lib/eabi_compat.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c
index 86eacf1..eb3e26d 100644
--- a/arch/arm/lib/eabi_compat.c
+++ b/arch/arm/lib/eabi_compat.c
@@ -16,3 +16,8 @@ int raise (int signum)
printf("raise: Signal # %d caught\n", signum);
return 0;
}
+
+/* Dummy function to avoid linker complaints */
+void __aeabi_unwind_cpp_pr0(void)
+{
+};
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
Dear Timur Tabi,
In message <4be42d45.9020...@freescale.com> you wrote:
>
> I don't know what __aeabi_unwind_cpp_pr0 is, but it doesn't look like it's
> related to integers.
__aeabi_unwind_cpp_pr0 is part of the stack unwinding support for ARM;
we can probably just copy the Linux kernel's code which looks pretty
much straightforward:
/* Dummy functions to avoid linker complaints */
void __aeabi_unwind_cpp_pr0(void)
{
};
EXPORT_SYMBOL(__aeabi_unwind_cpp_pr0);
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"I refuse to have a battle of wits with an unarmed person."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 83xx build errors
Hi Ron, Dave, are you aware of these MPC8315ERDB_NAND and SIMPC8313_LP build errors in current mainline code: NAND bootstrap too big Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager. - T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PLU405 build error
Dear Matthias, are you aware of this PLU405 build error in current mainline code: ppc_4xx-ld: u-boot: section .resetvec lma 0xfffc overlaps previous sections Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always try to do things in chronological order; it's less confusing that way. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AX88180: switch to common mii.h header
No compiled code change here, just drop the local PHY defines in favor of
the common standard ones.
Signed-off-by: Mike Frysinger
---
drivers/net/ax88180.c | 31 ---
drivers/net/ax88180.h | 48 ++--
2 files changed, 18 insertions(+), 61 deletions(-)
diff --git a/drivers/net/ax88180.c b/drivers/net/ax88180.c
index 6e788a0..fa2e212 100644
--- a/drivers/net/ax88180.c
+++ b/drivers/net/ax88180.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include "ax88180.h"
/*
@@ -112,10 +113,10 @@ static int ax88180_phy_reset (struct eth_device *dev)
{
unsigned short delay_cnt = 500;
- ax88180_mdio_write (dev, BMCR, (PHY_RESET | AUTONEG_EN));
+ ax88180_mdio_write (dev, MII_BMCR, (BMCR_RESET | BMCR_ANENABLE));
/* Wait for the reset to complete, or time out (500 ms) */
- while (ax88180_mdio_read (dev, BMCR) & PHY_RESET) {
+ while (ax88180_mdio_read (dev, MII_BMCR) & BMCR_RESET) {
udelay (1000);
if (--delay_cnt == 0) {
printf ("Failed to reset PHY!\n");
@@ -265,10 +266,10 @@ static int ax88180_phy_initial (struct eth_device *dev)
#endif
{
priv->PhyAddr = phyaddr;
- priv->PhyID0 = ax88180_mdio_read(dev, PHYIDR0);
+ priv->PhyID0 = ax88180_mdio_read(dev, MII_PHYSID1);
switch (priv->PhyID0) {
- case MARVELL_88E_PHYIDR0:
+ case MARVELL_88E_PHYSID0:
debug("ax88180: Found Marvell 88E PHY."
" (PHY Addr=0x%x)\n", priv->PhyAddr);
@@ -282,7 +283,7 @@ static int ax88180_phy_initial (struct eth_device *dev)
return 1;
- case CICADA_CIS8201_PHYIDR0:
+ case CICADA_CIS8201_PHYSID0:
debug("ax88180: Found CICADA CIS8201 PHY"
" chipset. (PHY Addr=0x%x)\n", priv->PhyAddr);
@@ -321,20 +322,20 @@ static void ax88180_media_config (struct eth_device *dev)
/* Waiting 2 seconds for PHY link stable */
for (i = 0; i < 2; i++) {
- bmsr_val = ax88180_mdio_read (dev, BMSR);
- if (bmsr_val & LINKOK) {
+ bmsr_val = ax88180_mdio_read (dev, MII_BMSR);
+ if (bmsr_val & BMSR_LSTATUS) {
break;
}
udelay (100);
}
- bmsr_val = ax88180_mdio_read (dev, BMSR);
+ bmsr_val = ax88180_mdio_read (dev, MII_BMSR);
debug ("ax88180: BMSR=0x%04x\n", (unsigned int)bmsr_val);
- if (bmsr_val & LINKOK) {
- bmcr_val = ax88180_mdio_read (dev, BMCR);
+ if (bmsr_val & BMSR_LSTATUS) {
+ bmcr_val = ax88180_mdio_read (dev, MII_BMCR);
- if (bmcr_val & AUTONEG_EN) {
+ if (bmcr_val & BMCR_ANENABLE) {
/*
* Waiting for Auto-negotiation completion, this may
@@ -343,8 +344,8 @@ static void ax88180_media_config (struct eth_device *dev)
debug ("ax88180: Auto-negotiation is "
"enabled. Waiting for NWay completion..\n");
for (i = 0; i < 5; i++) {
- bmsr_val = ax88180_mdio_read (dev, BMSR);
- if (bmsr_val & AUTONEG_COMPLETE) {
+ bmsr_val = ax88180_mdio_read (dev, MII_BMSR);
+ if (bmsr_val & BMSR_ANEGCOMPLETE) {
break;
}
udelay (100);
@@ -357,10 +358,10 @@ static void ax88180_media_config (struct eth_device *dev)
/* Get real media mode here */
switch (priv->PhyID0) {
- case MARVELL_88E_PHYIDR0:
+ case MARVELL_88E_PHYSID0:
RealMediaMode = get_MarvellPHY_media_mode(dev);
break;
- case CICADA_CIS8201_PHYIDR0:
+ case CICADA_CIS8201_PHYSID0:
RealMediaMode = get_CicadaPHY_media_mode(dev);
break;
default:
diff --git a/drivers/net/ax88180.h b/drivers/net/ax88180.h
index 77bab5f..c793e92 100644
--- a/drivers/net/ax88180.h
+++ b/drivers/net/ax88180.h
@@ -63,9 +63,9 @@ struct ax88180_private {
/* Max Rx Jumbo size is 15K Bytes */
#define MAX_RX_SIZE0x3C00
-#define MARVELL_88E_PHYIDR00x0141
+#define MARVELL_88E_PHYSID00x0141
-#define CICADA_CIS8201_PHYIDR0 0x000F
+#define CICADA_CIS8201_PHYSID0 0x000F
#define MEDIA_AUTO 0
#define MEDIA_1000FULL 1
@@ -276,50 +276,6 @@ struct ax88180_private {
#define SOFTRST_NORMAL 0x0003
#define SOFTRS
Re: [U-Boot] Read-only env variables
Dear Joe Hershberger, In message you wrote: > On Mon, May 10, 2010 at 1:56 AM, Wolfgang Denk wrote: > > Well, we could go for a simple type scheme, something like > > > >d - decimal number > >i - IP address > >m - mac address > >s - string > >x - hex number > >... > >l - list delimited by ';' (special behavior for setenv) Don't do this. ';' has a clear meaning. Using it for other purposes > That seems pretty reasonable. I think I'd like to see the access > control codes more role based than limitation based. Such as: > > u - unique board configuration (mac addr, ser#)... set if not > set, default override > s - script in env var... read only, default > r - runtime variable (ip addr)... set in env, not saveable to flash. This is most probably less flexible and more cumbersome to use. It's easier to define what exactly you want to do (don't allow over- writing) that finding a role that happens to include this behaviour. Think also about the end user who wonders why variable "foo" is considered to be a "unique board configuration" when all you wanted is to apply certain behaviour. > > What would be your use of such list vatiables? > > Specifically for manipulating the acl and any other list that a user > may need. Because it will self reference and define its type as a > list, Why would that be needed? See my example above: setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr [Implementation note: the implementation should allow for and ignore repeated or trailing ',' separators - i.e. something like "delay:d,,,address:a,ipaddr:i,ethaddr:mo,,serial#:sr,," should work as well. Reason: see below about incremental building.] > There's nothing wrong with that, but the issue is with removal... and > if you are making the behavior special for lists, then this is cleaner > than dereferencing the original list every time. Well, we have the editenv command, which makes editing pretty easy. I fear/feal that adding lists is (1) not really needed and thus most likely more overhead than benefit, and (2) holds a lot of potential for causing confusion and conflicts. We don't have lists vailables in bash either (or do we?) > > OK, the "remove entry" function is not that easy here, but which usage > > do you have in mind that needs that? I never ran into that before. > > Consider the case where a variable is defined as a runtime variable, > but the user would like to change the value and commit that change to > flash. It would be much more usable if there were a simple way to > remove an element from a list. What to you mean by "runtime variable" or by "change to flash"? I don;t understand what these terms are supposed to mean. As mentioned before, "editenv" seems a pretty straightforward way to edit the settings. I feel we should try to make this not overly complicated - don't add bells and whistles without real need. Also keep in mind that a lot of power results from being able to dynamically build such settings from smaller blocks. I can imagine scripts that run things like setenv acl "$acl_net,$acl_hw_id,$acl_foo,$acl_bar" Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de That's the thing about people who think they hate computers. What they really hate is lousy programmers. - Larry Niven and Jerry Pournelle in "Oath of Fealty" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/19] SPEAr : Network support configured for spear SoCs
Hi Vipin,
Sorry for weighing in so late on this...
On 5/6/2010 4:18 AM, Vipin KUMAR wrote:
> Signed-off-by: Vipin Kumar
> ---
> arch/arm/include/asm/arch-spear/hardware.h |1 +
> board/spear/spear300/spear300.c| 10 ++
> board/spear/spear310/spear310.c| 10 ++
> board/spear/spear320/spear320.c| 10 ++
> board/spear/spear600/spear600.c| 10 ++
> include/configs/spear-common.h | 14 --
> include/configs/spear3xx.h |3 +++
> 7 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-spear/hardware.h
> b/arch/arm/include/asm/arch-spear/hardware.h
> index 818f36c..39d64b6 100644
> --- a/arch/arm/include/asm/arch-spear/hardware.h
> +++ b/arch/arm/include/asm/arch-spear/hardware.h
> @@ -31,6 +31,7 @@
> #define CONFIG_SPEAR_SYSCNTLBASE(0xFCA0)
> #define CONFIG_SPEAR_TIMERBASE (0xFC80)
> #define CONFIG_SPEAR_MISCBASE (0xFCA8)
> +#define CONFIG_SPEAR_ETHBASE (0xE080)
>
> #define CONFIG_SYS_NAND_CLE (1<< 16)
> #define CONFIG_SYS_NAND_ALE (1<< 17)
> diff --git a/board/spear/spear300/spear300.c b/board/spear/spear300/spear300.c
> index 60ee544..774f466 100644
> --- a/board/spear/spear300/spear300.c
> +++ b/board/spear/spear300/spear300.c
> @@ -22,6 +22,7 @@
>*/
>
> #include
> +#include
> #include
> #include
> #include
> @@ -56,3 +57,12 @@ int board_nand_init(struct nand_chip *nand)
>
> return -1;
> }
> +
> +int board_eth_init(bd_t *bis)
> +{
> +#if defined(CONFIG_DESIGNWARE_ETH)
> + return designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY);
> +#else
> + return -1;
> +#endif
> +}
>
Returning -1 isn't really the right thing to do here. I apologize that
this is really confusing, and needs to be cleaned up. Next release - I
promise. If you want to call cpu_eth_init() here, call it directly.
Otherwise, return the number of devices found (0 or more). If there's
an error in designware_initialize(), you should handle it here, either
by asserting, printing a failure banner, etc.
The original intent in net/eth.c was something like this:
/* Try board-specific initialization first. If it fails or isn't
* present, try the cpu-specific initialization */
if (board_eth_init(bis) *is weak* )
cpu_eth_init(bis);
but the easiest way to check for weakness was to return -1. This is of
course an inappropriate number to use since it's the almost-universal
return code for failure.
Again, sorry for bringing this up after so many of your iterations.
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AX88180: improve phy searching
Rather than hardcode specific phy addresses, search the possible phy
address space to find the first available phy. Also respect the normal
CONFIG_PHY_ADDR option for board porters to pick a specific address.
Signed-off-by: Mike Frysinger
---
drivers/net/ax88180.c | 89
drivers/net/ax88180.h |2 -
2 files changed, 52 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ax88180.c b/drivers/net/ax88180.c
index 5d12fcf..6e788a0 100644
--- a/drivers/net/ax88180.c
+++ b/drivers/net/ax88180.c
@@ -255,49 +255,60 @@ static int ax88180_phy_initial (struct eth_device *dev)
{
struct ax88180_private *priv = (struct ax88180_private *)dev->priv;
unsigned long tmp_regval;
+ unsigned short phyaddr;
- /* Check avaliable PHY chipset */
- priv->PhyAddr = MARVELL_88E_PHYADDR;
- priv->PhyID0 = ax88180_mdio_read (dev, PHYIDR0);
-
- if (priv->PhyID0 == MARVELL_88E_PHYIDR0) {
-
- debug ("ax88180: Found Marvell 88E PHY."
- " (PHY Addr=0x%x)\n", priv->PhyAddr);
-
- tmp_regval = ax88180_mdio_read (dev, M88_EXT_SSR);
- if ((tmp_regval & HWCFG_MODE_MASK) == RGMII_COPPER_MODE) {
-
- ax88180_mdio_write (dev, M88_EXT_SCR, DEFAULT_EXT_SCR);
- if (ax88180_phy_reset (dev) < 0)
- return 0;
- ax88180_mdio_write (dev, M88_IER, LINK_CHANGE_INT);
- }
- } else {
+ /* Search for first avaliable PHY chipset */
+#ifdef CONFIG_PHY_ADDR
+ phyaddr = CONFIG_PHY_ADDR;
+#else
+ for (phyaddr = 0; phyaddr < 32; ++phyaddr)
+#endif
+ {
+ priv->PhyAddr = phyaddr;
+ priv->PhyID0 = ax88180_mdio_read(dev, PHYIDR0);
+
+ switch (priv->PhyID0) {
+ case MARVELL_88E_PHYIDR0:
+ debug("ax88180: Found Marvell 88E PHY."
+ " (PHY Addr=0x%x)\n", priv->PhyAddr);
+
+ tmp_regval = ax88180_mdio_read(dev, M88_EXT_SSR);
+ if ((tmp_regval & HWCFG_MODE_MASK) !=
RGMII_COPPER_MODE) {
+ ax88180_mdio_write(dev, M88_EXT_SCR,
DEFAULT_EXT_SCR);
+ if (ax88180_phy_reset(dev) < 0)
+ return 0;
+ ax88180_mdio_write(dev, M88_IER,
LINK_CHANGE_INT);
+ }
- priv->PhyAddr = CICADA_CIS8201_PHYADDR;
- priv->PhyID0 = ax88180_mdio_read (dev, PHYIDR0);
+ return 1;
- if (priv->PhyID0 == CICADA_CIS8201_PHYIDR0) {
+ case CICADA_CIS8201_PHYIDR0:
+ debug("ax88180: Found CICADA CIS8201 PHY"
+ " chipset. (PHY Addr=0x%x)\n", priv->PhyAddr);
- debug ("ax88180: Found CICADA CIS8201 PHY"
- " chipset. (PHY Addr=0x%x)\n", priv->PhyAddr);
- ax88180_mdio_write (dev, CIS_IMR,
+ ax88180_mdio_write(dev, CIS_IMR,
(CIS_INT_ENABLE | LINK_CHANGE_INT));
/* Set CIS_SMI_PRIORITY bit before force the media mode
*/
- tmp_regval =
- ax88180_mdio_read (dev, CIS_AUX_CTRL_STATUS);
+ tmp_regval = ax88180_mdio_read(dev,
CIS_AUX_CTRL_STATUS);
tmp_regval &= ~CIS_SMI_PRIORITY;
- ax88180_mdio_write (dev, CIS_AUX_CTRL_STATUS,
- tmp_regval);
- } else {
- printf ("ax88180: Unknown PHY chipset!!\n");
- return 0;
+ ax88180_mdio_write(dev, CIS_AUX_CTRL_STATUS,
tmp_regval);
+
+ return 1;
+
+ case 0x:
+ /* No PHY at this addr */
+ break;
+
+ default:
+ printf("ax88180: Unknown PHY chipset %#x at addr %#x\n",
+ priv->PhyID0, priv->PhyAddr);
+ break;
}
}
- return 1;
+ printf("ax88180: Unknown PHY chipset!!\n");
+ return 0;
}
static void ax88180_media_config (struct eth_device *dev)
@@ -345,12 +356,16 @@ static void ax88180_media_config (struct eth_device *dev)
(unsigned int)bmcr_val, (unsigned int)bmsr_val);
/* Get real media mode here */
- if (priv->PhyID0 == MARVELL_88E_PHYIDR0) {
- RealMediaMode = get_MarvellPHY_media_mode (dev);
- } else if (priv->PhyID0 == CICADA_CIS8201_PHYIDR0) {
- RealMediaMode = get_CicadaPHY_media_mode (dev);
- } else {
+
[U-Boot] [PATCH] AX88180: fix media typos
From: Hoan Hoang
Signed-off-by: Hoan Hoang
Signed-off-by: Mike Frysinger
---
drivers/net/ax88180.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ax88180.c b/drivers/net/ax88180.c
index d843397..5d12fcf 100644
--- a/drivers/net/ax88180.c
+++ b/drivers/net/ax88180.c
@@ -50,9 +50,9 @@
*/
static void ax88180_rx_handler (struct eth_device *dev);
static int ax88180_phy_initial (struct eth_device *dev);
-static void ax88180_meidia_config (struct eth_device *dev);
-static unsigned long get_CicadaPHY_meida_mode (struct eth_device *dev);
-static unsigned long get_MarvellPHY_meida_mode (struct eth_device *dev);
+static void ax88180_media_config (struct eth_device *dev);
+static unsigned long get_CicadaPHY_media_mode (struct eth_device *dev);
+static unsigned long get_MarvellPHY_media_mode (struct eth_device *dev);
static unsigned short ax88180_mdio_read (struct eth_device *dev,
unsigned long regaddr);
static void ax88180_mdio_write (struct eth_device *dev,
@@ -300,7 +300,7 @@ static int ax88180_phy_initial (struct eth_device *dev)
return 1;
}
-static void ax88180_meidia_config (struct eth_device *dev)
+static void ax88180_media_config (struct eth_device *dev)
{
struct ax88180_private *priv = (struct ax88180_private *)dev->priv;
unsigned long bmcr_val, bmsr_val;
@@ -346,9 +346,9 @@ static void ax88180_meidia_config (struct eth_device *dev)
/* Get real media mode here */
if (priv->PhyID0 == MARVELL_88E_PHYIDR0) {
- RealMediaMode = get_MarvellPHY_meida_mode (dev);
+ RealMediaMode = get_MarvellPHY_media_mode (dev);
} else if (priv->PhyID0 == CICADA_CIS8201_PHYIDR0) {
- RealMediaMode = get_CicadaPHY_meida_mode (dev);
+ RealMediaMode = get_CicadaPHY_media_mode (dev);
} else {
RealMediaMode = MEDIA_1000FULL;
}
@@ -424,7 +424,7 @@ static void ax88180_meidia_config (struct eth_device *dev)
return;
}
-static unsigned long get_MarvellPHY_meida_mode (struct eth_device *dev)
+static unsigned long get_MarvellPHY_media_mode (struct eth_device *dev)
{
unsigned long m88_ssr;
unsigned long MediaMode;
@@ -457,7 +457,7 @@ static unsigned long get_MarvellPHY_meida_mode (struct
eth_device *dev)
return MediaMode;
}
-static unsigned long get_CicadaPHY_meida_mode (struct eth_device *dev)
+static unsigned long get_CicadaPHY_media_mode (struct eth_device *dev)
{
unsigned long tmp_regval;
unsigned long MediaMode;
@@ -522,7 +522,7 @@ static int ax88180_init (struct eth_device *dev, bd_t * bd)
dev->enetaddr[4] | (((unsigned short)dev->enetaddr[5]) << 8);
OUTW (dev, tmp_regval, MACID2);
- ax88180_meidia_config (dev);
+ ax88180_media_config (dev);
OUTW (dev, DEFAULT_RXFILTER, RXFILTER);
@@ -558,7 +558,7 @@ static int ax88180_recv (struct eth_device *dev)
if (ISR_Status & ISR_PHY) {
/* Read ISR register once to clear PHY interrupt bit */
tmp_regval = ax88180_mdio_read (dev, M88_ISR);
- ax88180_meidia_config (dev);
+ ax88180_media_config (dev);
}
if ((ISR_Status & ISR_RX) || (ISR_Status & ISR_RXBUFFOVR)) {
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AX88180: add missing init prototype
Signed-off-by: Mike Frysinger --- include/netdev.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/netdev.h b/include/netdev.h index 882642a..99344ce 100644 --- a/include/netdev.h +++ b/include/netdev.h @@ -43,6 +43,7 @@ int cpu_eth_init(bd_t *bis); /* Driver initialization prototypes */ int altera_tse_initialize(u8 dev_num, int mac_base, int sgdma_rx_base, int sgdma_tx_base); +int ax88180_initialize(bd_t *bis); int au1x00_enet_initialize(bd_t*); int at91emac_register(bd_t *bis, unsigned long iobase); int bfin_EMAC_initialize(bd_t *bis); -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid use of divides in print_size.
Here's a more revealing test:
unsigned int i;
for (i = 0; i < 60; i++) {
unsigned long long l = 45ULL << i;
printf("%llu - ", l);
print_size(l, "\n");
}
prints:
45 - 45 Bytes
90 - 90 Bytes
180 - 180 Bytes
360 - 360 Bytes
720 - 720 Bytes
1440 - 1.9 KiB
2880 - 3.3 KiB
5760 - 6.1 KiB
11520 - 11.7 KiB
23040 - 23 KiB
46080 - 45 KiB
92160 - 90 KiB
184320 - 180 KiB
368640 - 360 KiB
737280 - 720 KiB
1474560 - 1.9 MiB
2949120 - 3.3 MiB
5898240 - 6.1 MiB
11796480 - 11.7 MiB
23592960 - 23 MiB
47185920 - 45 MiB
94371840 - 90 MiB
188743680 - 180 MiB
377487360 - 360 MiB
754974720 - 720 MiB
1509949440 - 1.9 GiB
3019898880 - 3.3 GiB
6039797760 - 6.1 GiB
12079595520 - 11.7 GiB
24159191040 - 23 GiB
48318382080 - 45 GiB
96636764160 - 90 GiB
193273528320 - 180 GiB
386547056640 - 360 GiB
773094113280 - 720 GiB
1546188226560 - 1.4 TiB
3092376453120 - 2.8 TiB
6184752906240 - 5.6 TiB
12369505812480 - 11.2 TiB
24739011624960 - 22.5 TiB
49478023249920 - 45 TiB
98956046499840 - 90 TiB
197912092999680 - 180 TiB
395824185999360 - 360 TiB
791648371998720 - 720 TiB
1583296743997440 - 1.4 PiB
3166593487994880 - 2.8 PiB
6333186975989760 - 5.6 PiB
12666373951979520 - 11.2 PiB
25332747903959040 - 22.5 PiB
50665495807918080 - 45 PiB
101330991615836160 - 90 PiB
202661983231672320 - 180 PiB
405323966463344640 - 360 PiB
810647932926689280 - 720 PiB
1621295865853378560 - 1.4 EiB
3242591731706757120 - 2.8 EiB
6485183463413514240 - 5.6 EiB
12970366926827028480 - 11.2 EiB
7493989779944505344 - 6.5 EiB
That last one is probably an overflow.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Read-only env variables
On Mon, May 10, 2010 at 1:56 AM, Wolfgang Denk wrote: > Well, we could go for a simple type scheme, something like > > d - decimal number > i - IP address > m - mac address > s - string > x - hex number > ... l - list delimited by ';' (special behavior for setenv) > plus similarly simple access control codes: > > d - no change except reset to default possible > o - one-time setting, no changes afterward > r - read-only > (none) - unrestricted access > > Then we could do something like: > > setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr > > The only disadvantage is that the meaning of the qualifiers is > position dependent, but I think this is acceptable for the purposes we > have in mind. That seems pretty reasonable. I think I'd like to see the access control codes more role based than limitation based. Such as: u - unique board configuration (mac addr, ser#)... set if not set, default override s - script in env var... read only, default r - runtime variable (ip addr)... set in env, not saveable to flash. > I think bitmasks is probably overkill - we probably don't need that > many options. The scheme above could be extended for more qualifiers > as well. I think I will at least use bitmasks to define each of the commands that are available in the acl env var. That will make defining new commands simple. >> Another thing that would make dealing with the lists in env variables easier >> would be to support slightly different behavior for setenv... here's what I >> have in mind: if an env variable called "myList" contains >> "varName1;varName2" and you call "setenv myList varName3", then the result >> is myList contains "varName1;varName2;varName3". If you then call "setenv > > That would be incompatible to existing use. Not a good idea, IMHO. > >> myList -varName2", then myList would contain "varName1;varName3". The >> behavior would be available in general by having a list variable type (just >> like numeric or IP addr). I'm not set on using semi-colons as list >> delimiters or the "-" to signify remove-from-list in setenv, but those seem >> natural. I'm interested if there are any foreseeable issues with those >> selections or if there are more appropriate options. > > What would be your use of such list vatiables? Specifically for manipulating the acl and any other list that a user may need. Because it will self reference and define its type as a list, > And what's wrong with > > setenv myList "varName1;varName2" > setenv myList "$myList;varName3" > > to do the same as above, using only the existing feature set? There's nothing wrong with that, but the issue is with removal... and if you are making the behavior special for lists, then this is cleaner than dereferencing the original list every time. > OK, the "remove entry" function is not that easy here, but which usage > do you have in mind that needs that? I never ran into that before. Consider the case where a variable is defined as a runtime variable, but the user would like to change the value and commit that change to flash. It would be much more usable if there were a simple way to remove an element from a list. >> --0016e640d1748106790486378cdb >> Content-Type: text/html; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable > > Please stop this. Apologies. Best regards, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] query about USB gadget framework
Hi, 2010/5/10 Detlev Zundel : > Hi Dmitry, > >> Looks like there were attempts [2] to do so but I failed to figure out >> why it was not actually merged. Or was it dropped at some point later? >> Interesting why. > > Well this is strange. From the link you provide, it seems like Wolfgang > applied that to mainline, but I also cannot find any trace here of the > commits of the pull-request. It has been reverted quite fast after merging into mainline, since it touched some ARM code that conflicted with other work in progress at that time. I planned to push it back in later but did not had the time to do it properly, and I have to say that there were not many requests last year to move it forward ;-) The current status of the CDC branch in the u-boot-usb tree is that it is fully operational to provide CDC-ECM support (ethernet-over-USB) on Atmel at91based cores, but it need to be worked up for mainline integration. > Whereas Remy asked Wolfgang to pull the next branch. Maybe this was a > misunderstanding and nobody (except you) found out nope, it was just reverted... > Remy, what do you think? I do not expect to have some time for it soon, so if you want to work it up for mainline inclusion, go ahead! Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid use of divides in print_size.
On Mon, May 10, 2010 at 4:51 AM, Nick Thompson wrote: > Modification of print_size to avoid use of divides and especially > long long divides. Keep the binary scale factor in terms of bit > shifts instead. This should be faster, since the previous code > gave the compiler no clues that the divides where always powers > of two, preventing optimisation. > > Signed-off-by: Nick Thompson This code almost works. It seems to have trouble printing fractional values. Using this loop: unsigned int i; for (i = 0; i < 63; i++) print_size(3ULL << i, "\n"); I get this output. Notice that it rounds 1.5 to 2 on sizes less than a terabyte. 3 Bytes 6 Bytes 12 Bytes 24 Bytes 48 Bytes 96 Bytes 192 Bytes 384 Bytes 768 Bytes 2 KiB 3 KiB 6 KiB 12 KiB 24 KiB 48 KiB 96 KiB 192 KiB 384 KiB 768 KiB 2 MiB 3 MiB 6 MiB 12 MiB 24 MiB 48 MiB 96 MiB 192 MiB 384 MiB 768 MiB 2 GiB 3 GiB 6 GiB 12 GiB 24 GiB 48 GiB 96 GiB 192 GiB 384 GiB 768 GiB 1.5 TiB 3 TiB 6 TiB 12 TiB 24 TiB 48 TiB 96 TiB 192 TiB 384 TiB 768 TiB 1.5 PiB 3 PiB 6 PiB 12 PiB 24 PiB 48 PiB 96 PiB 192 PiB 384 PiB 768 PiB 1.5 EiB 3 EiB 6 EiB 12 EiB -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tftp not working for larger rootfs image
Dear Navaneethan P, In message you wrote: > > >> You could flash your rootfs.jffs2 directly to NAND and mount it from > there, > No idea how to do it. Is there any way, I can directly load the data to > NAND through tftp or any other command? Yes, there is - using an appropriate JTAG debugger for example, or using Linux or another OS of your choice. > >> or if you have access to the FEC you could mount your rootfs via NFS. > I have tried boot to linux, and i am using nandwrite utility to flash the > root file system. There also it hangs up after some time. Ah, now this is interesting. Are you sure your memory is really cionfigured correctly (and is there really as much RAM as you believe there is)? > nandwrite writes from offset 0 to 288. Then it gives "Unable to handle > kernel paging request at virtual address 0100" error (kernel panic). > > Any help would be appreciated. We cannot help you with custom hardware and unknown code - that's a really bad combination. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "What is wanted is not the will to believe, but the will to find out, which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_, 1928 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tftp not working for larger rootfs image
Dear Navaneethan P, In message you wrote: > > I am using Freescale's iMX51 based custom board with NAND flash size of > 128MB. This code is not in mainline, so how should we able to know where or how you (mis)configured your system? > My root file system image size happens to be 75MB. > I have DDR RAM of 128MB. > My DDR Start Address is 0x9000_. I am trying to load my root file > system to 0x9080_.(8MB after the starting location). > But when i execute the tftp command, it loads some amount after that it > hangs up. That's not really a surprise on ARM, if the system configuration does not match the hardware. > 1. How much memory does the u-boot requires? Is 8MB enough? U-Boot needs only a few 100 kB for itself; 1 MB should be more than enough for most configurations. > 2. Since I have 128MB of RAM, I should be able to load 120MB of image > file. Why does it hangs up? Maybe you misconfigured U-Boot so the U-Boot image sits right in the middle of your RAM? > Why these behavior? Is this behavior is correct? Is there anything wrong > with my DDR Initialization? You don't provide any information about where your code comes from, or how you configured it, so it's difficult to make even educated guesses. How did you configure TEXT_BASE? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The manager will be continually amazed that policies he took for com- mon knowledge are totally unknown by some member of his team. Since his fundamental job is to keep everybody going in the same direction, his chief daily task will be communication, not decision-making. - Fred Brooks, "The Mythical Man Month" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tftp not working for larger rootfs image
Thanks for reply...! >> You could flash your rootfs.jffs2 directly to NAND and mount it from there, No idea how to do it. Is there any way, I can directly load the data to NAND through tftp or any other command? >> or if you have access to the FEC you could mount your rootfs via NFS. I have tried boot to linux, and i am using nandwrite utility to flash the root file system. There also it hangs up after some time. nandwrite writes from offset 0 to 288. Then it gives "Unable to handle kernel paging request at virtual address 0100" error (kernel panic). Any help would be appreciated. Thanks & Regards, Navaneethan P Fabio Estevam 05/10/2010 08:52 PM To "u-boot@lists.denx.de" , Navaneethan P cc Subject Re: [U-Boot] tftp not working for larger rootfs image --- On Mon, 5/10/10, Navaneethan P wrote: > From: Navaneethan P > Subject: [U-Boot] tftp not working for larger rootfs image > To: "u-boot@lists.denx.de" > Date: Monday, May 10, 2010, 12:11 PM > Hi All, > > I am using Freescale's iMX51 based custom board with NAND > flash size of > 128MB. > My root file system image size happens to be 75MB. > I have DDR RAM of 128MB. > My DDR Start Address is 0x9000_. I am trying to load my > root file > system to 0x9080_.(8MB after the starting location). > But when i execute the tftp command, it loads some amount > after that it > hangs up. > U-Boot> tftp 0x9080 rootfs.jffs2 ... You could flash your rootfs.jffs2 directly to NAND and mount it from there, or if you have access to the FEC you could mount your rootfs via NFS. Can't you use one of these approaches instead? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] remove useless free(ptr) calls on NULL ptr
the subject should probably have a qualifier like "net:" or "smsc:", but other than that, this looks good. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Support for devices with FAT32 PBR
Hello.
Igor Luri wrote:
> Signed-off-by: Igor Luri
> ---
> disk/part_dos.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 887b75e..d91f773 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -77,7 +77,8 @@ static int test_block_type(unsigned char *buffer)
> (buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) ) {
> return (-1);
> } /* no DOS Signature at all */
> - if(strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0)
> + if((strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0) ||
> +(strncmp((char *)&buffer[DOS_PBR_FAT32_FSTYPE_OFFSET],"FAT32",5)==0)
> )
> return DOS_PBR; /* is PBR */
> return DOS_MBR; /* Is MBR */
> }
>
This was not a single patch, that was tree patches in the single
email. :-)
WBR, Sergei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tftp not working for larger rootfs image
--- On Mon, 5/10/10, Navaneethan P wrote: > From: Navaneethan P > Subject: [U-Boot] tftp not working for larger rootfs image > To: "u-boot@lists.denx.de" > Date: Monday, May 10, 2010, 12:11 PM > Hi All, > > I am using Freescale's iMX51 based custom board with NAND > flash size of > 128MB. > My root file system image size happens to be 75MB. > I have DDR RAM of 128MB. > My DDR Start Address is 0x9000_. I am trying to load my > root file > system to 0x9080_.(8MB after the starting location). > But when i execute the tftp command, it loads some amount > after that it > hangs up. > U-Boot> tftp 0x9080 rootfs.jffs2 ... You could flash your rootfs.jffs2 directly to NAND and mount it from there, or if you have access to the FEC you could mount your rootfs via NFS. Can't you use one of these approaches instead? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] tftp not working for larger rootfs image
Hi All, I am using Freescale's iMX51 based custom board with NAND flash size of 128MB. My root file system image size happens to be 75MB. I have DDR RAM of 128MB. My DDR Start Address is 0x9000_. I am trying to load my root file system to 0x9080_.(8MB after the starting location). But when i execute the tftp command, it loads some amount after that it hangs up. U-Boot> tftp 0x9080 rootfs.jffs2 1. How much memory does the u-boot requires? Is 8MB enough? 2. Since I have 128MB of RAM, I should be able to load 120MB of image file. Why does it hangs up? 3. I tried to write the byte data to 0x97ff_ (the very last location of my RAM). It is working U-Boot > md.b 0x97ff 1 97ff: 04. U-Boot > mm.b 0x97ff 97ff: 04 ? 32 U-Boot > md.b 0x97ff 1 97ff: 32. Now I tried to write the data to the next locations. I expected it to hang up. but it writes. Then i read the starting locations. But the data was written to there. Why these behavior? Is this behavior is correct? Is there anything wrong with my DDR Initialization? U-Boot > mm.b 0x97ff 97ff: 04 ? 32 9800: 09 ? 32 9801: 00 ? 21 9802: 0c ? 12 9803: 00 ? 12 9804: 08 ? U-Boot > md.b 0x9000 4 9000: 32 21 12 122!.. A reply would be greatly appreciated. Thanks in advance. Thanks & Regards, Navaneethan P___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] remove useless free(ptr) calls on NULL ptr
Signed-off-by: Serge Ziryukin
---
drivers/net/lan91c96.c |1 -
drivers/net/smc911x.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/lan91c96.c b/drivers/net/lan91c96.c
index 90e4002..810079f 100644
--- a/drivers/net/lan91c96.c
+++ b/drivers/net/lan91c96.c
@@ -795,7 +795,6 @@ int lan91c96_initialize(u8 dev_num, int base_addr)
dev = malloc(sizeof(*dev));
if (!dev) {
- free(dev);
return 0;
}
memset(dev, 0, sizeof(*dev));
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index f2fc88b..3da4c35 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -242,7 +242,6 @@ int smc911x_initialize(u8 dev_num, int base_addr)
dev = malloc(sizeof(*dev));
if (!dev) {
- free(dev);
return -1;
}
memset(dev, 0, sizeof(*dev));
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.
Hi,
I got the root cause. It was the DDR related issue while reading the DMC
registers.
Now the problem is solved. I am not not getting exception error after
enabling MSR_EE.
I am moving to use the latest u-boot code (2010.03) believing that there
might be fixup for timing issue I am facing when I am adding the printf
functions.
Hi Stefan,
Thansk for your help so far.
Regards,
Prakash Bedge
On Fri, May 7, 2010 at 8:47 PM, Wolfgang Denk wrote:
> Dear prakash bedge,
>
> In message
> you wrote:
> >
> > while debugging the u-boot I observed that the u-boot hangs when it call
> > getenv("loadaddr") function.
> > if ((s = getenv ("loadaddr")) != NULL) { }
> >
> > Is it because of loadaddr parameter passed to getenv?
>
> No. All this code is running on zillions other devices perfectly well.
> The reason it's not working for you is most likely because your memory
> is not working correctly, so you're working with corrupted code and
> corrupted data.
>
> > Do I really need to check the DDR3 initialization setup or there is
> > something other stuff I should check?
>
> Yes, you really should concentrate on fixing your memory
> intialization.
>
> No matter how often you are going to repeat that question, the
> reply will remain the same.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> In the bathtub of history the truth is harder to hold than the soap,
> and much more difficult to find ... - Terry Pratchett, _Sourcery_
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1136: Fix cache_flush() error and correct cpu_init_crit() comments
Hi George,
On 05.05.2010 23:09, George G. Davis wrote:
> The ARM1136 cache_flush() function uses the "mcr p15, 0, rn, c7, c7, 0"
> instruction which means "Invalidate Both Caches
... Also flushes the branch target cache"
> " when in fact the intent
> is to "Clean and Invalidate Entire Data Cache".
Why don't we have to invalidate/flush the I- and BT-Cache here? I.e.
why is it sufficient to clean & invalidate the D-Cache here, only, and
remove the existing I- and BT-Cache invalidation/flushing?
What's about just adding an additional clean of the data cache before
the 'invalidate all':
+ asm ("mcr p15, 0, %0, c7, c10, 0": :"r" (i)); /* clean entire data
cache */
asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both
caches and flush btb */
asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync
things */
?
Thanks for finding this and best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] POST cleanup.
Combine previously submitted POST cleanup patch series
into single patch. Fix plain POST support introduced recently
for mpc812x arch.
- Revives POST for blackfin arch;
- Removes redundant code:
arch/blackfin/lib/post.c
board/ssv/common/post.c
arch/powerpc/cpu/ppc4xx/commproc.c
arch/powerpc/cpu/mpc512x/common.c
- fixes up the post_word_{load|store} usage;
Signed-off-by: Michael Zaidman
Acked-by: Detlev Zundel
Tested-by: Anatolij Gustschin
List of the maintainers of the affected by patch boards:
Cc: Stephan Linz
Cc: Travis Sawyer
Cc: Denis Peter
Cc: Matthias Fuchs
Cc: Peter Tyser
Cc: Stefan Roese
Cc: Mike Frysinger
Cc: Niklaus Giger
Cc: Larry Johnson
Cc: Feng Kan
---
arch/blackfin/lib/Makefile |2 +-
arch/blackfin/lib/board.c |1 -
arch/blackfin/lib/post.c| 421 ---
arch/powerpc/cpu/mpc512x/Makefile |1 -
arch/powerpc/cpu/mpc512x/common.c | 25 --
arch/powerpc/cpu/mpc8260/commproc.c | 20 --
arch/powerpc/cpu/mpc85xx/commproc.c | 20 --
arch/powerpc/cpu/mpc8xx/commproc.c | 20 --
arch/powerpc/cpu/ppc4xx/Makefile|1 -
arch/powerpc/cpu/ppc4xx/commproc.c | 53 -
board/barco/barco.c |9 -
board/bc3450/bc3450.c | 20 --
board/bf537-stamp/Makefile |2 +-
board/bf537-stamp/post.c| 14 --
board/cm5200/cm5200.c | 16 --
board/ssv/common/post.c | 44
board/tqc/tqm5200/tqm5200.c | 19 --
board/xes/xpedite1000/xpedite1000.c | 16 --
include/common.h|5 +-
include/configs/ADNPESC1.h |3 +-
include/configs/KAREF.h |3 +-
include/configs/METROBOX.h |3 +-
include/configs/MIP405.h|4 -
include/configs/PMC440.h|3 +-
include/configs/TB5200.h|2 +-
include/configs/XPEDITE1000.h |3 +-
include/configs/alpr.h |3 +-
include/configs/barco.h |2 +
include/configs/bf537-stamp.h |1 +
include/configs/bfin_adi_common.h |1 +
include/configs/hcu4.h |3 +-
include/configs/hcu5.h |5 +-
include/configs/hmi1001.h |6 +-
include/configs/icon.h |3 +-
include/configs/inka4x0.h |6 +-
include/configs/katmai.h|3 +-
include/configs/kilauea.h |3 +-
include/configs/korat.h |3 +-
include/configs/lwmon5.h|2 +-
include/configs/makalu.h|3 +-
include/configs/mcu25.h |3 +-
include/configs/mpc5121-common.h|3 +-
include/configs/ocotea.h|3 +-
include/configs/redwood.h |3 +-
include/configs/sequoia.h |3 +-
include/configs/taishan.h |3 +-
include/configs/yucca.h |3 +-
include/configs/zeus.h |7 +-
include/post.h | 57 +-
post/Makefile |3 +-
50 files changed, 103 insertions(+), 759 deletions(-)
delete mode 100644 arch/blackfin/lib/post.c
delete mode 100644 arch/powerpc/cpu/mpc512x/common.c
delete mode 100644 arch/powerpc/cpu/ppc4xx/commproc.c
delete mode 100644 board/ssv/common/post.c
diff --git a/arch/blackfin/lib/Makefile b/arch/blackfin/lib/Makefile
index 3bdba75..a18bbd6 100644
--- a/arch/blackfin/lib/Makefile
+++ b/arch/blackfin/lib/Makefile
@@ -46,7 +46,7 @@ COBJS-y += clocks.o
COBJS-$(CONFIG_CMD_CACHE_DUMP) += cmd_cache_dump.o
COBJS-$(CONFIG_CMD_KGDB) += kgdb.o
COBJS-y+= muldi3.o
-COBJS-$(CONFIG_POST) += post.o tests.o
+COBJS-$(CONFIG_POST_ALT_LIST) += tests.o
COBJS-y+= string.o
SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index 4e9bb19..00a2041 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -321,7 +321,6 @@ void board_init_r(gd_t * id, ulong dest_addr)
#if defined(CONFIG_POST)
post_output_backlog();
- post_reloc();
#endif
/* initialize malloc() area */
diff --git a/arch/blackfin/lib/post.c b/arch/blackfin/lib/post.c
deleted file mode 100644
index faf6b96..000
--- a/arch/blackfin/lib/post.c
+++ /dev/null
@@ -1,421 +0,0 @@
-/*
- * (C) Copyright 2002
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-
[U-Boot] [PATCH v3] Support for devices with FAT32 PBR
Signed-off-by: Igor Luri
---
disk/part_dos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 887b75e..d91f773 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -77,7 +77,8 @@ static int test_block_type(unsigned char *buffer)
(buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) ) {
return (-1);
} /* no DOS Signature at all */
- if(strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0)
+ if((strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0) ||
+ (strncmp((char *)&buffer[DOS_PBR_FAT32_FSTYPE_OFFSET],"FAT32",5)==0)
)
return DOS_PBR; /* is PBR */
return DOS_MBR; /* Is MBR */
}
--
1.5.4.3
---
disk/part_dos.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/disk/part_dos.h b/disk/part_dos.h
index ac93f20..6383c58 100644
--- a/disk/part_dos.h
+++ b/disk/part_dos.h
@@ -35,6 +35,7 @@
#define DOS_PART_TBL_OFFSET0x1be
#define DOS_PART_MAGIC_OFFSET 0x1fe
#define DOS_PBR_FSTYPE_OFFSET 0x36
+#define DOS_PBR_FAT32_FSTYPE_OFFSET0x52
#define DOS_PBR_MEDIA_TYPE_OFFSET 0x15
#define DOS_MBR0
#define DOS_PBR1
--
1.5.4.3
---
fs/fat/fat.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 2445f1e..4da4351 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -50,6 +50,7 @@ static int cur_part = 1;
#define DOS_PART_TBL_OFFSET0x1be
#define DOS_PART_MAGIC_OFFSET 0x1fe
#define DOS_FS_TYPE_OFFSET 0x36
+#define DOS_FS_FAT32_TYPE_OFFSET 0x52
int disk_read (__u32 startblock, __u32 getsize, __u8 * bufptr)
{
@@ -94,7 +95,8 @@ fat_register_device(block_dev_desc_t *dev_desc, int part_no)
if (!get_partition_info (dev_desc, part_no, &info)) {
part_offset = info.start;
cur_part = part_no;
- } else if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET], "FAT", 3)) {
+ } else if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET], "FAT", 3) ||
+ !strncmp((char *)&buffer[DOS_FS_FAT32_TYPE_OFFSET],
"FAT32", 5)) {
/* ok, we assume we are on a PBR only */
cur_part = 1;
part_offset = 0;
@@ -105,7 +107,8 @@ fat_register_device(block_dev_desc_t *dev_desc, int part_no)
}
#else
- if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET],"FAT",3)) {
+ if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET],"FAT",3) ||
+ !strncmp((char *)&buffer[DOS_FS_FAT32_TYPE_OFFSET], "FAT32", 5)
) {
/* ok, we assume we are on a PBR only */
cur_part = 1;
part_offset = 0;
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Support for devices with FAT32 PBR
Dear Wolfgang, El lun, 10-05-2010 a las 13:54 +0200, Wolfgang Denk escribió: > It makes no sense to split these patches. Please merge them into one, > as Sergei asked before. Sorry, I'll do it inmediately. > > Also, I doubt that this fixes all current problems with FAT32 code. > Did you - just for example - try reading a long directory (say, more > than 128 entries) ? With this patch aplied, only detects correctly this type of devices, making posible reading files from this kinf of devices. Otherwaise it detects as a MBR device, reading a bogus partition table and imposible to read device contents. Best regards. -- Igor Luri R&D Software Department Fagor Aotek S. Coop. P. O. Box 144 E-20500 Mondragón-Arrasate Tel.++34 943 71 92 00 ++34 943 71 92 01 (Ext. 44268) Fax.++34 943 79 92 03 www.aotek.es ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] POST cleanup.
On Mon, May 10, 2010 at 2:17 PM, Detlev Zundel wrote: > > It would have been really nice if you put the maintainers on CC (simply > include a CC: ... in the patch git-send-email does the rest) of the > boards that you change config files. This way they knew that there was > a change which they should test and ack. > The following boards are not mentioned in the MAINTAINERS file: TB5200 barco hmi1001 yucca Regards, Michael. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] POST cleanup.
On Mon, May 10, 2010 at 2:51 PM, Anatolij Gustschin wrote: ... > mpc512x related changes are OK. I tested them on mpc5121 > based pdm360ng board. Thanks again for this work! > For mpc5121 part you can add > Tested-by: Anatolij Gustschin > Ok, thanks for testing. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Support for devices with FAT32 PBR
Dear Igor Luri, In message <1273491334-10693-2-git-send-email-il...@aotek.es> you wrote: > > Signed-off-by: Igor Luri > --- > fs/fat/fat.c |7 +-- > 1 files changed, 5 insertions(+), 2 deletions(-) It makes no sense to split these patches. Please merge them into one, as Sergei asked before. Also, I doubt that this fixes all current problems with FAT32 code. Did you - just for example - try reading a long directory (say, more than 128 entries) ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The number you have dialed is imaginary. Please divide by 0 and try again. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] POST cleanup.
On Sun, 9 May 2010 18:27:10 +0300
Michael Zaidman wrote:
> Combine previously submitted POST cleanup patch series
> into single patch. Fix plain POST support introduced recently
> for mpc812x arch.
>
> - Revives POST for blackfin arch;
> - Removes redundant code:
> arch/blackfin/lib/post.c
> board/ssv/common/post.c
> arch/powerpc/cpu/ppc4xx/commproc.c
> arch/powerpc/cpu/mpc512x/common.c
> - fixes up the post_word_{load|store} usage;
mpc512x related changes are OK. I tested them on mpc5121
based pdm360ng board. Thanks again for this work!
For mpc5121 part you can add
Tested-by: Anatolij Gustschin
Best regards,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] POST cleanup.
On Mon, May 10, 2010 at 2:17 PM, Detlev Zundel wrote:
> Hi Michael,
>
>> Combine previously submitted POST cleanup patch series
>> into single patch. Fix plain POST support introduced recently
>> for mpc812x arch.
>>
>> - Revives POST for blackfin arch;
>> - Removes redundant code:
>> arch/blackfin/lib/post.c
>> board/ssv/common/post.c
>> arch/powerpc/cpu/ppc4xx/commproc.c
>> arch/powerpc/cpu/mpc512x/common.c
>> - fixes up the post_word_{load|store} usage;
>
> Thanks for the big work.
>
> It would have been really nice if you put the maintainers on CC (simply
> include a CC: ... in the patch git-send-email does the rest) of the
> boards that you change config files. This way they knew that there was
> a change which they should test and ack.
>
> For the powerpc parts, you have my
>
> Acked-by: Detlev Zundel
>
Ok, will be done.
>> diff --git a/board/barco/barco.c b/board/barco/barco.c
>> index c5fe8c4..2d01f1b 100644
>> --- a/board/barco/barco.c
>> +++ b/board/barco/barco.c
>> @@ -348,12 +348,3 @@ int serial_tstc (void)
>> {
>> return 0;
>> }
>> -
>> -unsigned long post_word_load (void)
>> -{
>> - return 0l;
>> -}
>> -void post_word_store (unsigned long val)
>> -{
>> - return;
>> -}
>
> This never worked :) The config file has no trace of any POST, so the
> change you do is pretty useless:
These changes are necessary for CONFIG_LOGBUFFER which barco board
defines that in turn requires the post_word_load and post_word_store
support.
>
>> diff --git a/include/configs/barco.h b/include/configs/barco.h
>> index e00f84a..b1af701 100644
>> --- a/include/configs/barco.h
>> +++ b/include/configs/barco.h
>> @@ -136,6 +136,8 @@
>> #define CONFIG_LOGBUFFER
>> #ifdef CONFIG_LOGBUFFER
>> #define CONFIG_SYS_STDOUT_ADDR 0x1FFC000
>> +#define CONFIG_SYS_POST_WORD_ADDR \
>> + (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_MAX_RAM_SIZE - 4)
>> #else
>> #define CONFIG_SYS_STDOUT_ADDR 0x2B9000
>> #endif
>
> But then again, it doesn't matter.
This matters for the CONFIG_LOGBUFFER support as I explained above.
Thanks,
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] Support for devices with FAT32 PBR
Signed-off-by: Igor Luri
---
fs/fat/fat.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 2445f1e..4da4351 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -50,6 +50,7 @@ static int cur_part = 1;
#define DOS_PART_TBL_OFFSET0x1be
#define DOS_PART_MAGIC_OFFSET 0x1fe
#define DOS_FS_TYPE_OFFSET 0x36
+#define DOS_FS_FAT32_TYPE_OFFSET 0x52
int disk_read (__u32 startblock, __u32 getsize, __u8 * bufptr)
{
@@ -94,7 +95,8 @@ fat_register_device(block_dev_desc_t *dev_desc, int part_no)
if (!get_partition_info (dev_desc, part_no, &info)) {
part_offset = info.start;
cur_part = part_no;
- } else if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET], "FAT", 3)) {
+ } else if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET], "FAT", 3) ||
+ !strncmp((char *)&buffer[DOS_FS_FAT32_TYPE_OFFSET],
"FAT32", 5)) {
/* ok, we assume we are on a PBR only */
cur_part = 1;
part_offset = 0;
@@ -105,7 +107,8 @@ fat_register_device(block_dev_desc_t *dev_desc, int part_no)
}
#else
- if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET],"FAT",3)) {
+ if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET],"FAT",3) ||
+ !strncmp((char *)&buffer[DOS_FS_FAT32_TYPE_OFFSET], "FAT32", 5)
) {
/* ok, we assume we are on a PBR only */
cur_part = 1;
part_offset = 0;
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] Support for devices with FAT32 PBR
Signed-off-by: Igor Luri
---
disk/part_dos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 887b75e..d91f773 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -77,7 +77,8 @@ static int test_block_type(unsigned char *buffer)
(buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) ) {
return (-1);
} /* no DOS Signature at all */
- if(strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0)
+ if((strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0) ||
+ (strncmp((char *)&buffer[DOS_PBR_FAT32_FSTYPE_OFFSET],"FAT32",5)==0)
)
return DOS_PBR; /* is PBR */
return DOS_MBR; /* Is MBR */
}
--
1.5.4.3
---
disk/part_dos.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/disk/part_dos.h b/disk/part_dos.h
index ac93f20..6383c58 100644
--- a/disk/part_dos.h
+++ b/disk/part_dos.h
@@ -35,6 +35,7 @@
#define DOS_PART_TBL_OFFSET0x1be
#define DOS_PART_MAGIC_OFFSET 0x1fe
#define DOS_PBR_FSTYPE_OFFSET 0x36
+#define DOS_PBR_FAT32_FSTYPE_OFFSET0x52
#define DOS_PBR_MEDIA_TYPE_OFFSET 0x15
#define DOS_MBR0
#define DOS_PBR1
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 8640D Errata
Dear "Thirumalai", In message you wrote: > > Is 8640D all errata has fixed on the u-boot-2009.06 version ? Or it is > the responsible for end user ? > Kindly clarify me. I am not working on 8640D processors, I have no idea. Please check yourself. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 8 Catfish = 1 Octo-puss ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] POST cleanup.
Hi Michael,
> Combine previously submitted POST cleanup patch series
> into single patch. Fix plain POST support introduced recently
> for mpc812x arch.
>
> - Revives POST for blackfin arch;
> - Removes redundant code:
> arch/blackfin/lib/post.c
> board/ssv/common/post.c
> arch/powerpc/cpu/ppc4xx/commproc.c
> arch/powerpc/cpu/mpc512x/common.c
> - fixes up the post_word_{load|store} usage;
Thanks for the big work.
It would have been really nice if you put the maintainers on CC (simply
include a CC: ... in the patch git-send-email does the rest) of the
boards that you change config files. This way they knew that there was
a change which they should test and ack.
For the powerpc parts, you have my
Acked-by: Detlev Zundel
> diff --git a/board/barco/barco.c b/board/barco/barco.c
> index c5fe8c4..2d01f1b 100644
> --- a/board/barco/barco.c
> +++ b/board/barco/barco.c
> @@ -348,12 +348,3 @@ int serial_tstc (void)
> {
> return 0;
> }
> -
> -unsigned long post_word_load (void)
> -{
> - return 0l;
> -}
> -void post_word_store (unsigned long val)
> -{
> - return;
> -}
This never worked :) The config file has no trace of any POST, so the
change you do is pretty useless:
> diff --git a/include/configs/barco.h b/include/configs/barco.h
> index e00f84a..b1af701 100644
> --- a/include/configs/barco.h
> +++ b/include/configs/barco.h
> @@ -136,6 +136,8 @@
> #define CONFIG_LOGBUFFER
> #ifdef CONFIG_LOGBUFFER
> #define CONFIG_SYS_STDOUT_ADDR 0x1FFC000
> +#define CONFIG_SYS_POST_WORD_ADDR\
> + (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_MAX_RAM_SIZE - 4)
> #else
> #define CONFIG_SYS_STDOUT_ADDR 0x2B9000
> #endif
But then again, it doesn't matter.
Cheers
Detlev
--
If you currently have a 32-bit UNIX system, you are advised to
trade it in for a 64-bit one sometime before the year 2106.
-- Andrew S. Tanenbaum: Modern Operating Systems, 2nd Edition
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] query about USB gadget framework
Hi Dmitry, > I'm curious what are the current plans for merging the USB gadget > framework [1] into mainline tree? You should address this question to the USB custodian Remy Bohmer (I put him on CC). > Looks like there were attempts [2] to do so but I failed to figure out > why it was not actually merged. Or was it dropped at some point later? > Interesting why. Well this is strange. From the link you provide, it seems like Wolfgang applied that to mainline, but I also cannot find any trace here of the commits of the pull-request. Around the time in question, I can only find this commit: commit f97db54d7e773a32100247ee002686b6a014a87d Merge: 0c24dec faa14ba Author: Wolfgang Denk Date: Tue Jun 9 22:53:03 2009 +0200 Merge branch 'master' of git://git.denx.de/u-boot-usb Whereas Remy asked Wolfgang to pull the next branch. Maybe this was a misunderstanding and nobody (except you) found out Remy, what do you think? Cheers Detlev -- He who can properly define and divide is to be considered a god. -- Plato -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Support for devices with FAT32 PBR
Hello.
Igor Luri wrote:
> Signed-off-by: Igor Luri
> ---
> disk/part_dos.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 887b75e..d91f773 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -77,7 +77,8 @@ static int test_block_type(unsigned char *buffer)
> (buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) ) {
> return (-1);
> } /* no DOS Signature at all */
> - if(strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0)
> + if((strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0) ||
> +(strncmp((char *)&buffer[DOS_PBR_FAT32_FSTYPE_OFFSET],"FAT32",5)==0)
> )
>
You #define DOS_PBR_FAT32_FSTYPE_OFFSET only in patch 2. That way,
patch 1 is uncompilable. Merge the patches please.
WBR, Sergei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/8] mpc5121: add support for PDM360NG board
On Sun, 9 May 2010 11:01:45 +0300 Michael Zaidman wrote: > On Sat, Apr 24, 2010 at 8:27 PM, Anatolij Gustschin wrote: > > PDM360NG is a MPC5121E based board by ifm ecomatic gmbh. > > > > [snip] > > +#define CONFIG_SYS_INIT_RAM_ENDCONFIG_SYS_SRAM_SIZE > /* End of area */ > + > +#define CONFIG_SYS_GBL_DATA_SIZE 0x100 /* num bytes of initial data > */ > +#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END - \ > +CONFIG_SYS_GBL_DATA_SIZE) > +#define CONFIG_SYS_POST_WORD_ADDR (CONFIG_SYS_GBL_DATA_OFFSET - 0x4) > > The CONFIG_SYS_POST_WORD_ADDR is not defined correctly. The base > address is absent. This is true. This macro is slightly confusing and for some other boards it actually means the post word offset. I should have defined _POST_ADDR as (CONFIG_SYS_SRAM_BASE + CONFIG_SYS_POST_WORD_ADDR) in .../mpc5121/common.c file. Since the post test on this board runs quite late (in RAM and not before relocation), this bug didn't show up. Thanks for reporting it! > This will be fixed by POST cleanup consolidated patch anyway. Thanks for this work! Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
On 07/05/10 16:30, Timur Tabi wrote: > Scott McNutt wrote: >> lib/libgeneric.a(display_options.o): In function `print_size': >> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:66: undefined >> reference to `__udivdi3' >> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:69: undefined >> reference to `__umoddi3' >> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:70: undefined >> reference to `__udivdi3' > > Man, I knew ARM sucked, but I didn't know it was this bad :-) > > I was going to suggestion replacing the division operations with calls to > lldiv(), but we're actually doing a 64-by-64 bit division here: > > n = size / d; > > which means that in order to support support printing 64-bit numbers on ARM, > we might need to completely rewrite print_size() to avoid division on 64-bit > numbers. > > Wolfgang, do you have any suggestions? > I'm not sure if it is the correct way to "fix" this issue, But I have submitted a patch in "[U-Boot] [PATCH] Avoid use of divides in print_size." It allows ARM to rebuild again (here at least), but really it modifies the function to use bit shifts as an optimisation over calling lengthy div library functions. This side steps the linker issue. It you have chance to test or review it I would be grateful. I tested the code on x86 Linux PC, not by running it in U-Boot. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Support for devices with FAT32 PBR
Signed-off-by: Igor Luri
---
fs/fat/fat.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 2445f1e..4da4351 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -50,6 +50,7 @@ static int cur_part = 1;
#define DOS_PART_TBL_OFFSET0x1be
#define DOS_PART_MAGIC_OFFSET 0x1fe
#define DOS_FS_TYPE_OFFSET 0x36
+#define DOS_FS_FAT32_TYPE_OFFSET 0x52
int disk_read (__u32 startblock, __u32 getsize, __u8 * bufptr)
{
@@ -94,7 +95,8 @@ fat_register_device(block_dev_desc_t *dev_desc, int part_no)
if (!get_partition_info (dev_desc, part_no, &info)) {
part_offset = info.start;
cur_part = part_no;
- } else if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET], "FAT", 3)) {
+ } else if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET], "FAT", 3) ||
+ !strncmp((char *)&buffer[DOS_FS_FAT32_TYPE_OFFSET],
"FAT32", 5)) {
/* ok, we assume we are on a PBR only */
cur_part = 1;
part_offset = 0;
@@ -105,7 +107,8 @@ fat_register_device(block_dev_desc_t *dev_desc, int part_no)
}
#else
- if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET],"FAT",3)) {
+ if (!strncmp((char *)&buffer[DOS_FS_TYPE_OFFSET],"FAT",3) ||
+ !strncmp((char *)&buffer[DOS_FS_FAT32_TYPE_OFFSET], "FAT32", 5)
) {
/* ok, we assume we are on a PBR only */
cur_part = 1;
part_offset = 0;
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] Support for devices with FAT32 PBR
Signed-off-by: Igor Luri --- disk/part_dos.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/disk/part_dos.h b/disk/part_dos.h index ac93f20..6383c58 100644 --- a/disk/part_dos.h +++ b/disk/part_dos.h @@ -35,6 +35,7 @@ #define DOS_PART_TBL_OFFSET0x1be #define DOS_PART_MAGIC_OFFSET 0x1fe #define DOS_PBR_FSTYPE_OFFSET 0x36 +#define DOS_PBR_FAT32_FSTYPE_OFFSET0x52 #define DOS_PBR_MEDIA_TYPE_OFFSET 0x15 #define DOS_MBR0 #define DOS_PBR1 -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] Support for devices with FAT32 PBR
Signed-off-by: Igor Luri
---
disk/part_dos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 887b75e..d91f773 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -77,7 +77,8 @@ static int test_block_type(unsigned char *buffer)
(buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) ) {
return (-1);
} /* no DOS Signature at all */
- if(strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0)
+ if((strncmp((char *)&buffer[DOS_PBR_FSTYPE_OFFSET],"FAT",3)==0) ||
+ (strncmp((char *)&buffer[DOS_PBR_FAT32_FSTYPE_OFFSET],"FAT32",5)==0)
)
return DOS_PBR; /* is PBR */
return DOS_MBR; /* Is MBR */
}
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Avoid use of divides in print_size.
Modification of print_size to avoid use of divides and especially
long long divides. Keep the binary scale factor in terms of bit
shifts instead. This should be faster, since the previous code
gave the compiler no clues that the divides where always powers
of two, preventing optimisation.
Signed-off-by: Nick Thompson
---
This patch should make print_size a little faster, but perhaps
nobody cares about that too much. What it also does though is
reenable U-Boot linking for ARM with standard toolchains.
(e.g. CodeSourcery and MontaVista).
lib/display_options.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 86df05d..636916d 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -46,13 +46,14 @@ int display_options (void)
void print_size(unsigned long long size, const char *s)
{
unsigned long m = 0, n;
+ unsigned long long f;
static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
- unsigned long long d = 1ULL << (10 * ARRAY_SIZE(names));
+ unsigned long d = 10 * ARRAY_SIZE(names);
char c = 0;
unsigned int i;
- for (i = 0; i < ARRAY_SIZE(names); i++, d >>= 10) {
- if (size >= d) {
+ for (i = 0; i < ARRAY_SIZE(names); i++, d -= 10) {
+ if (size >> d) {
c = names[i];
break;
}
@@ -63,11 +64,12 @@ void print_size(unsigned long long size, const char *s)
return;
}
- n = size / d;
+ n = size >> d;
+ f = size & ((1ULL << d) - 1);
/* If there's a remainder, deal with it */
- if(size % d) {
- m = (10 * (size - (n * d)) + (d / 2) ) / d;
+ if (f) {
+ m = (10ULL * (f + (1 << (d - 1 >> d;
if (m >= 10) {
m -= 10;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 8640D Errata
Hi denx, Is 8640D all errata has fixed on the u-boot-2009.06 version ? Or it is the responsible for end user ? Kindly clarify me. -Thirumalai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Which Board name in u-boot similar to NIC card?
Dear Hari Babu, In message you wrote: > > Can u help on u-boot source code to find which board name is similar to NIC > card,irrespective of cpu and other hardware devices.Thank u. This request is preposterous - it is exactly the "cpu and other hardware devices" which makes the differences between boards. If you ignore these, all boards are the same. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Where would we be without rhetorical questions? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
