Re: [U-Boot] [Bug] IXP425 and e1000 network driver
Dear Ben, In message <4a7fb519.6040...@gmail.com> you wrote: > > I thought I brought this up already, but maybe not. Won't this break > PowerPC? I'm pretty sure (value) != (cpu_to_le32(value)), isn't it? Right. > Isn't the problem that writel() and readl() aren't byte-swapped on BE ARM? Right. writel() and readl() are not a good choice for architecture independent code. AFAIK ioreadX(), iowriteX() are supposed to be architecture independent I/O accessors, but unfortunately not all architectures implement these yet. 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 Computers make excellent and efficient servants, but I have no wish to serve under them. Captain, a starship also runs on loyalty to one man. And nothing can replace it or him. -- Spock, "The Ultimate Computer", stardate 4729.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add Intel E1000 PCIE card support
Dear Roy Zang, In message <1249018442.19764.4.ca...@rock.ap.freescale.net> you wrote: > > Based on Intel PRO/1000 Network Driver 7.3.20-k2 > Add Intel E1000 PCIE card support. The following cards are added: > INTEL_82571EB_COPPER > INTEL_82571EB_FIBER, > INTEL_82571EB_SERDES > INTEL_82571EB_QUAD_COPPER > INTEL_82571PT_QUAD_COPPER > INTEL_82571EB_QUAD_FIBER > INTEL_82571EB_QUAD_COPPER_LOWPROFILE > INTEL_82571EB_SERDES_DUAL > INTEL_82571EB_SERDES_QUAD > INTEL_82572EI_COPPER > INTEL_82572EI_FIBER > INTEL_82572EI_SERDES > INTEL_82572EI > INTEL_82573E > INTEL_82573E_IAMT > INTEL_82573L > INTEL_82546GB_QUAD_COPPER_KSP3 > INTEL_80003ES2LAN_COPPER_DPT > INTEL_80003ES2LAN_SERDES_DPT > INTEL_80003ES2LAN_COPPER_SPT > INTEL_80003ES2LAN_SERDES_SPT > > 82571EB_COPPER dual ports, > 82572EI single port, > 82572EI_COPPER single port PCIE cards > and > 82545EM_COPPER, > 82541GI_LF > pci cards are tested on both P2020 board > and MPC8544DS board. > > Signed-off-by: Roy Zang Unfortunately your driver causes build warnings on the AP1000 board: e1000.c:131: warning: 'e1000_read_eeprom' used but never defined e1000.c:2012: warning: 'e1000_set_phy_mode' defined but not used Please provide a fix. Thanks in advance. 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 Suffocating together ... would create heroic camaraderie. -- Khan Noonian Singh, "Space Seed", stardate 3142.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 85xx: MPC8536DS board does not build
Dear Kumar, I cannot build the MPC8536DS board any more using the ELDK 4.2 tool chain (gcc 4.2.2): ppc_85xx-ld: section .bootpg [e000 -> e1cb] overlaps section .data.rel.local [efffe5d0 -> e c7b] ppc_85xx-ld: section .resetvec [effc -> efff] overlaps section .u_boot_cmd [ec9c -> f3e b] ppc_85xx-ld: u-boot: section .bootpg lma 0xe000 overlaps previous sections ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xec7c overlaps previous sections ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xec9c overlaps previous sections ppc_85xx-ld: u-boot: section .resetvec lma 0xeffc overlaps previous sections Could you please have a look? 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 "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?"- Steve Elias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/tftp.c: fix warning: pointer targets differ in signedness
tftp.c:294: warning: pointer targets in passing argument 1 of 'strlen'
differ in signedness
This was only visible for the utx8245 board which seems to have DEBUG
enabled.
Signed-off-by: Wolfgang Denk
---
net/tftp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 74d9e42..fb98a34 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -291,7 +291,9 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
break;
case TFTP_OACK:
- debug("Got OACK: %s %s\n", pkt, pkt+strlen(pkt)+1);
+ debug("Got OACK: %s %s\n",
+ pkt,
+ pkt + strlen((char *)pkt) + 1);
TftpState = STATE_OACK;
TftpServerPort = src;
/*
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] net: phy: bugfixes: mv88E61xx multichip addressing support
Dear Prafulla Wadaskar, In message <1247758084-12296-4-git-send-email-prafu...@marvell.com> you wrote: > With these fixes, this driver works properly for multi chip > addressging mode > > Bugfixes: > 1. Build error fixed for function mv88e61xx_busychk_multic-fixed > 2. PHY dev address error detection- fixed > 3. wrong busy bit was refered in function mv88e61xx_busychk -fixed > 4. invalid data read ptr was refered for RD_PHY in case of > multichip addressing mode -fixed > > The Multichip Address mode is tested with RD6281A board having > MV88E6165 switch on it > > Signed-off-by: Prafulla Wadaskar > --- > drivers/net/phy/mv88e61xx.c | 18 +- > drivers/net/phy/mv88e61xx.h |2 +- > 2 files changed, 10 insertions(+), 10 deletions(-) This patch causes compiler warnings: mv88e61xx.c: In function 'mv88e61xx_busychk_multic': mv88e61xx.c:46: warning: passing argument 4 of 'miiphy_read' from incompatible pointer type mv88e61xx.c: In function 'mv88e61xx_wr_phy': mv88e61xx.c:61: warning: passing argument 4 of 'miiphy_read' from incompatible pointer type mv88e61xx.c:57: warning: unused variable 'reg' mv88e61xx.c: In function 'mv88e61xx_rd_phy': mv88e61xx.c:80: warning: passing argument 4 of 'miiphy_read' from incompatible pointer type mv88e61xx.c:76: warning: unused variable 'reg' (when building for the rd6281a board using ELDK 4.2, i. e. gcc-4.2.2) Also, the rd6281a board throws this warning: nand_util.c:45:2: warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! Could you please provide fixes? Thanks in advance. 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 "One thing they don't tell you about doing experimental physics is that sometimes you must work under adverse conditions... like a state of sheer terror."- W. K. Hartmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] export SPI functions to standalone apps
Dear Mike, In message <1248381468-29618-1-git-send-email-vap...@gentoo.org> you wrote: > While we're here, fix the broken #ifdef handling in _exports.h. > > Signed-off-by: Mike Frysinger > --- > v3 > - tweak code style > > common/exports.c |8 > include/_exports.h | 14 ++ > include/exports.h |3 ++- > 3 files changed, 20 insertions(+), 5 deletions(-) This patch causes a build error on the "trab" board: board/trab/../../examples/standalone/libstubs.a(stubs.o): In function `dummy': include/_exports.h:27: multiple definition of `spi_init' board/trab/tsc2000.o:board/trab/tsc2000.c:52: first defined here make[1]: *** [board/trab/trab_fkt.srec] Error 1 make: *** [board/trab/libtrab.a] Error 2 Please provide a fix. 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 Another dream that failed. There's nothing sadder. -- Kirk, "This side of Paradise", stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/8] tools: mkimage : bugfix returns correct value for list command
List command always return "EXIT_SUCCESS" even in case of
failure by any means.
This patch return 0 if list command is sucessful,
returns negative value reported by check_header functions
Signed-off-by: Prafulla Wadaskar
---
Change log:
v2: added code rewritten to look it better as per review feedback for v1
tools/mkimage.c | 26 ++
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 02cdb95..dc42924 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -28,7 +28,7 @@
extern unsigned long crc32 (unsigned long crc, const char *buf, unsigned int
len);
static voidcopy_file (int, const char *, int);
static voidusage (void);
-static voidimage_verify_header (char *, int);
+static int image_verify_header (char *, int);
static voidfit_handle_file (void);
char *datafile;
@@ -60,6 +60,7 @@ main (int argc, char **argv)
struct stat sbuf;
unsigned char *ptr;
char *name = "";
+ int retval;
cmdname = *argv;
@@ -219,24 +220,24 @@ NXTARG: ;
exit (EXIT_FAILURE);
}
- if (fdt_check_header (ptr)) {
- /* old-style image */
- image_verify_header ((char *)ptr, sbuf.st_size);
- image_print_contents ((image_header_t *)ptr);
- } else {
+ if (!(retval = fdt_check_header (ptr))) {
/* FIT image */
fit_print_contents (ptr);
+ } else if (!(retval = image_verify_header ((char *)ptr,
+ sbuf.st_size))) {
+ /* old-style image */
+ image_print_contents ((image_header_t *)ptr);
}
(void) munmap((void *)ptr, sbuf.st_size);
(void) close (ifd);
- exit (EXIT_SUCCESS);
+ exit (retval);
} else if (fflag) {
/* Flattened Image Tree (FIT) format handling */
debug ("FIT format handling\n");
fit_handle_file ();
- exit (EXIT_SUCCESS);
+ exit (retval);
}
/*
@@ -480,7 +481,7 @@ usage ()
exit (EXIT_FAILURE);
}
-static void
+static int
image_verify_header (char *ptr, int image_size)
{
int len;
@@ -500,7 +501,7 @@ image_verify_header (char *ptr, int image_size)
fprintf (stderr,
"%s: Bad Magic Number: \"%s\" is no valid image\n",
cmdname, imagefile);
- exit (EXIT_FAILURE);
+ return -FDT_ERR_BADMAGIC;
}
data = (char *)hdr;
@@ -513,7 +514,7 @@ image_verify_header (char *ptr, int image_size)
fprintf (stderr,
"%s: ERROR: \"%s\" has bad header checksum!\n",
cmdname, imagefile);
- exit (EXIT_FAILURE);
+ return -FDT_ERR_BADSTATE;
}
data = ptr + sizeof(image_header_t);
@@ -523,8 +524,9 @@ image_verify_header (char *ptr, int image_size)
fprintf (stderr,
"%s: ERROR: \"%s\" has corrupted data!\n",
cmdname, imagefile);
- exit (EXIT_FAILURE);
+ return -FDT_ERR_BADSTRUCTURE;
}
+ return 0;
}
/**
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] net: phy: bugfixes: mv88E61xx multichip addressing support
Dear Prafulla Wadaskar,
In message <1247758084-12296-4-git-send-email-prafu...@marvell.com> you wrote:
> With these fixes, this driver works properly for multi chip
> addressging mode
>
> Bugfixes:
> 1. Build error fixed for function mv88e61xx_busychk_multic-fixed
> 2. PHY dev address error detection- fixed
> 3. wrong busy bit was refered in function mv88e61xx_busychk -fixed
> 4. invalid data read ptr was refered for RD_PHY in case of
> multichip addressing mode -fixed
>
> The Multichip Address mode is tested with RD6281A board having
> MV88E6165 switch on it
>
> Signed-off-by: Prafulla Wadaskar
> ---
> drivers/net/phy/mv88e61xx.c | 18 +-
> drivers/net/phy/mv88e61xx.h |2 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
With ELDK 4.1 (gcc 4.0.0) I also get this compiler warning:
mv88e61xx.c: In function 'mv88e61xx_switch_initialize':
mv88e61xx.c:346: warning: 'idstr' may be used uninitialized in this function
when building for the mv88f6281gtw_ge board.
This looks reasonabme, as
361 if (reg == 0x1610)
362 idstr = "88E6161";
363 if (reg == 0x1650)
364 idstr = "88E6165";
365 if (reg == 0x1210) {
366 idstr = "88E6123";
367 /* ports 2,3,4 not available */
368 swconfig->ports_enabled &= 0x023;
369 }
may ideed leave "idstr" uninitialized; you may want to change this
into a switch() construct and add a default: case.
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] arm: rd6281a: Fixed NAND specific warning
It is recommended to define the macro CONFIG_SYS_64BIT_VSPRINTF for NAND specific warning removal, same is done in this patch Signed-off-by: Prafulla Wadaskar --- include/configs/rd6281a.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/rd6281a.h b/include/configs/rd6281a.h index 3d8e25c..3f4d42c 100644 --- a/include/configs/rd6281a.h +++ b/include/configs/rd6281a.h @@ -107,6 +107,7 @@ #define NAND_MAX_CHIPS 1 #define CONFIG_SYS_NAND_BASE 0xD800 /* KW_DEFADR_NANDF */ #define NAND_ALLOW_ERASE_ALL 1 +#define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */ #endif /* -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker script to handle all rodata sections
Dear Trent Piepho, In message <1234999325-13456-1-git-send-email-tpie...@freescale.com> you wrote: > > A recent gcc added a new unaligned rodata section called '.rodata.str1.1', > which needs to be added the the linker script. Instead of just adding this > one section, we use a wildcard ".rodata*" to get all rodata linker section > gcc has now and might add in the future. ... > I change this to: > > *(.text) > . = ALIGN(16); > *(.eh_frame) > *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) Unfortunately it turns out that this breaks some older tool chains. For example, using ELDK 3.1 (binutils 2.14-5) we get: arm-linux-ld:/home/wd/git/u-boot/work/cpu/s3c44b0/u-boot.lds:39: parse error It seems this old version of ld does not understand the *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) line yet. Do you see any want to make this backward compatible with older versions of ld? Thanks in advance. 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 Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] net: phy: bugfixes: mv88E61xx multichip addressing support
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Monday, August 10, 2009 1:39 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; > Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert > Buijtenhek; Ben Warren; Jean-Christophe Plagniol-Villard > Subject: Re: [U-Boot] [PATCH 4/6] net: phy: bugfixes: > mv88E61xx multichip addressing support > > Dear Prafulla Wadaskar, > > In message > <1247758084-12296-4-git-send-email-prafu...@marvell.com> you wrote: > > With these fixes, this driver works properly for multi chip > > addressging mode > Also, the rd6281a board throws this warning: > > nand_util.c:45:2: warning: #warning Please define > CONFIG_SYS_64BIT_VSPRINTF for correct output! Patch posted for this Regards.. Prafulla . . > > > Could you please provide fixes? > > Thanks in advance. > > 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 "One thing they don't tell you about doing > experimental physics is that sometimes you must work under > adverse conditions... like a state > of sheer terror."- W. K. Hartmann > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.08-rc2 is out
Hi everybody... v2009.08-rc2 has just been released. Please help testing, and submit fixes to the remaining problems. Things still missing should be submitted ASAP. v2009.08-rc2 is also be the base for the "next" branch which I just created (still empty so far). Please use the "next" branch as base for any new work. Note: Please keep in mind that it may be rebased against master every now and then without warning, but I will usually try to avoid this. Summary of current status: * Many boards now throw the (expected) #warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI messages. * ARM and PowerPC: mostly compile clean; there are a few issues, responsible s have been notified Biggest problem area for me is curtrently ARM, where I lose more time trying to moderate patch submissions than I can spend on actually working on code. We need to overcome this situation ASAP. Comments and ideas welcome. 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 Chapter 1 -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: phy: bugfixes: mv88E61xx compiler warnings fixed
1. mv88E61xx driver compiler warnings fixed
2. idstr if-else statements changed to switch() construct
and added default case too.
This fixed idstr may be uninitialized warning
Signed-off-by: Prafulla Wadaskar
---
drivers/net/phy/mv88e61xx.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 29630f5..3754e8b 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -38,7 +38,7 @@
*/
static int mv88e61xx_busychk_multic(char *name, u32 devaddr)
{
- u32 reg = 0;
+ u16 reg = 0;
u32 timeout = MV88E61XX_PHY_TIMEOUT;
/* Poll till SMIBusy bit is clear */
@@ -54,8 +54,7 @@ static int mv88e61xx_busychk_multic(char *name, u32 devaddr)
static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 data)
{
- u16 reg;
- u32 mii_dev_addr;
+ u16 mii_dev_addr;
/* command to read PHY dev address */
if (miiphy_read(name, 0xEE, 0xEE, &mii_dev_addr)) {
@@ -73,8 +72,7 @@ static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32
reg_ofs, u16 data)
static void mv88e61xx_rd_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 * data)
{
- u16 reg;
- u32 mii_dev_addr;
+ u16 mii_dev_addr;
/* command to read PHY dev address */
if (miiphy_read(name, 0xEE, 0xEE, &mii_dev_addr)) {
@@ -357,15 +355,22 @@ int mv88e61xx_switch_initialize(struct mv88e61xx_config
*swconfig)
}
RD_PHY(name, MV88E61XX_PRT_OFST, PHY_PHYIDR2, ®);
- reg &= 0xfff0;
- if (reg == 0x1610)
+ switch (reg &= 0xfff0) {
+ case 0x1610:
idstr = "88E6161";
- if (reg == 0x1650)
+ break;
+ case 0x1650:
idstr = "88E6165";
- if (reg == 0x1210) {
+ break;
+ case 0x1210:
idstr = "88E6123";
/* ports 2,3,4 not available */
swconfig->ports_enabled &= 0x023;
+ break;
+ default:
+ /* Could not detect switch id */
+ idstr = "88E61??";
+ break;
}
/* Port based VLANs configuration */
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] net: phy: bugfixes: mv88E61xx multichip addressing support
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Monday, August 10, 2009 1:56 PM
> To: Prafulla Wadaskar
> Cc: Manas Saksena; Ronen Shitrit; Nicolas Pitre; Ben Warren;
> u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik;
> Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 4/6] net: phy: bugfixes:
> mv88E61xx multichip addressing support
>
> Dear Prafulla Wadaskar,
>
> In message
> <1247758084-12296-4-git-send-email-prafu...@marvell.com> you wrote:
> > With these fixes, this driver works properly for multi chip
> > addressging mode
> >
> > Bugfixes:
> > 1. Build error fixed for function mv88e61xx_busychk_multic-fixed 2.
> > PHY dev address error detection- fixed 3. wrong busy bit
> was refered
> > in function mv88e61xx_busychk -fixed 4. invalid data read ptr was
> > refered for RD_PHY in case of
> > multichip addressing mode -fixed
> >
> > The Multichip Address mode is tested with RD6281A board having
> > MV88E6165 switch on it
> >
> > Signed-off-by: Prafulla Wadaskar
> > ---
> > drivers/net/phy/mv88e61xx.c | 18 +-
> > drivers/net/phy/mv88e61xx.h |2 +-
> > 2 files changed, 10 insertions(+), 10 deletions(-)
>
> With ELDK 4.1 (gcc 4.0.0) I also get this compiler warning:
>
> mv88e61xx.c: In function 'mv88e61xx_switch_initialize':
> mv88e61xx.c:346: warning: 'idstr' may be used uninitialized
> in this function
>
> when building for the mv88f6281gtw_ge board.
>
> This looks reasonabme, as
>
> 361 if (reg == 0x1610)
> 362 idstr = "88E6161";
> 363 if (reg == 0x1650)
> 364 idstr = "88E6165";
> 365 if (reg == 0x1210) {
> 366 idstr = "88E6123";
> 367 /* ports 2,3,4 not available */
> 368 swconfig->ports_enabled &= 0x023;
> 369 }
>
> may ideed leave "idstr" uninitialized; you may want to change
> this into a switch() construct and add a default: case.
Thanks
Bugfix patch posted for this
Regards..
Prafulla . .
>
> 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
Re: [U-Boot] [STATUS] v2009.08-rc2 is out
On 10:55 Mon 10 Aug , Wolfgang Denk wrote: > Hi everybody... > > v2009.08-rc2 has just been released. > > Please help testing, and submit fixes to the remaining problems. > Things still missing should be submitted ASAP. > > v2009.08-rc2 is also be the base for the "next" branch which I just > created (still empty so far). > > Please use the "next" branch as base for any new work. Note: Please > keep in mind that it may be rebased against master every now and then > without warning, but I will usually try to avoid this. > > > Summary of current status: > > * Many boards now throw the (expected) > > #warning Ethernet driver is deprecated. Please update to use > CONFIG_NET_MULTI > > messages. > > * ARM and PowerPC: mostly compile clean; there are a few issues, > responsible s have been notified nearly all ppc have warning with gcc 4 and a lots of them fail to build > > Biggest problem area for me is curtrently ARM, where I lose more time > trying to moderate patch submissions than I can spend on actually > working on code. We need to overcome this situation ASAP. > > Comments and ideas welcome yes please let me manage the ARM myself and please pull my patch I do known what I do on ARM very well Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/8] tools: mkimage : bugfix returns correct value for list command
Dear Prafulla Wadaskar, In message <1249910377-17974-1-git-send-email-prafu...@marvell.com> you wrote: > List command always return "EXIT_SUCCESS" even in case of > failure by any means. > > This patch return 0 if list command is sucessful, > returns negative value reported by check_header functions > > Signed-off-by: Prafulla Wadaskar > --- > Change log: > v2: added code rewritten to look it better as per review feedback for v1 > > tools/mkimage.c | 26 ++ > 1 files changed, 14 insertions(+), 12 deletions(-) Thanks. To make some (visible) progress I decided to check in patches where we have full agreement into the (new) "mkimage" branch. This way we can gradually reduce the amount of stuff we need to discuss. This patch has been applied to the "mkimage" branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. - Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] net: kirkwood: updates: used eth_setenv_enetaddr api
eth_setenv_enetaddr is avaible by upper layer
using this saves 204 bytes on total image size
used Local OUI instead of Marvell OUI for
random MAC address generation logic
Signed-off-by: Prafulla Wadaskar
---
Change log
v2: updated as per feedback for v1
private MAC address used
typos corrected
drivers/net/kirkwood_egiga.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 701812b..e3580af 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -592,7 +592,7 @@ int kirkwood_egiga_initialize(bd_t * bis)
struct kwgbe_device *dkwgbe;
struct eth_device *dev;
int devnum;
- char *s, buf[NAMESIZE * 2];
+ char *s;
u8 used_ports[MAX_KWGBE_DEVS] = CONFIG_KIRKWOOD_EGIGA_PORTS;
for (devnum = 0; devnum < MAX_KWGBE_DEVS; devnum++) {
@@ -650,11 +650,14 @@ int kirkwood_egiga_initialize(bd_t * bis)
}
while (!eth_getenv_enetaddr(s, dev->enetaddr)) {
- /* Generate Ramdom MAC addresses if not set */
- sprintf(buf, "00:50:43:%02x:%02x:%02x",
- get_random_hex(), get_random_hex(),
- get_random_hex());
- setenv(s, buf);
+ /* Generate Random Private MAC addr if not set */
+ dev->enetaddr[0] = 0x02;
+ dev->enetaddr[1] = 0x50;
+ dev->enetaddr[2] = 0x43;
+ dev->enetaddr[3] = get_random_hex();
+ dev->enetaddr[4] = get_random_hex();
+ dev->enetaddr[5] = get_random_hex();
+ eth_setenv_enetaddr(s, dev->enetaddr);
}
dev->init = (void *)kwgbe_init;
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/8] tools: mkimage : bugfix returns correct value for list command
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Monday, August 10, 2009 2:37 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik > Subject: Re: [U-Boot] [PATCH v2 1/8] tools: mkimage : bugfix > returns correct value for list command > > Dear Prafulla Wadaskar, > > In message > <1249910377-17974-1-git-send-email-prafu...@marvell.com> you wrote: > > List command always return "EXIT_SUCCESS" even in case of > failure by > > any means. > > > > This patch return 0 if list command is sucessful, returns negative > > value reported by check_header functions > > > > Signed-off-by: Prafulla Wadaskar > > --- > > Change log: > > v2: added code rewritten to look it better as per review > feedback for > > v1 > > > > tools/mkimage.c | 26 ++ > > 1 files changed, 14 insertions(+), 12 deletions(-) > > Thanks. To make some (visible) progress I decided to check in > patches where we have full agreement into the (new) "mkimage" > branch. This way we can gradually reduce the amount of stuff > we need to discuss. > > This patch has been applied to the "mkimage" branch. Thanks. Dear Wolfgang Thanks Regards.. Prafulla . . > > > 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 Fools ignore complexity. Pragmatists suffer it. > Some can avoid it. > Geniuses remove it. > - Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] zlib: updated to v.1.2.3
Giuseppe CONDORELLI wrote: > Now I hope this patch will be part of best so far u-boot tree. > > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of rhabarber1848 > Sent: Wednesday, July 29, 2009 6:14 PM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v5] zlib: updated to v.1.2.3 > > Giuseppe CONDORELLI wrote: > >> This patch updates zlib to the latest stable version. > > this patch finally works for me, thank you. > > Reviewed-by: rhabarber1848 Hi, @Wolfgang: Are there any chances this patch will be included in U-Boot 2009.08? Cheers, rhabarber1848 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.08-rc2 is out
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090810085443.gi17...@game.jcrosoft.org> you wrote: > > > * ARM and PowerPC: mostly compile clean; there are a few issues, > > responsible s have been notified > nearly all ppc have warning with gcc 4 > and a lots of them fail to build I built all PowerPC boards with ELDK 4.0 (gcc4.0.0), ELDK 4.1 (gcc 4.0.0) and ELDK 4.2 (gcc 4.2.2). Not a sinlge board failed, and only very few had unexpected warnings (I consider the "#warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULT" warning to be an expected one - and even this affects only 1 or 2 PowerPC boards - but about every ARM board). So could you *please* start providing clear facts? Which board do you claim to fail to build? Which exact tool chain are you using? And what are the exact error messages? D*mn... I'm asking you these very same questions for at least the 4th time in the last 2 or 3 days. Please provide FACTS. > > Comments and ideas welcome > yes please let me manage the ARM myself > and please pull my patch I do known what I do on ARM very well Even as a custodian you are supposed to accept that you do not have unlimited power. 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 Der Horizont vieler Menschen ist ein Kreis mit Radius Null -- und das nennen sie ihren Standpunkt. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: mkimage: Makefile sorted
The tools/Makefile is sorted for all entries, Signed-off-by: Prafulla Wadaskar --- tools/Makefile | 50 +- 1 files changed, 25 insertions(+), 25 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index b5a1e39..6f36f23 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -66,8 +66,8 @@ endif include $(TOPDIR)/config.mk # Generated executable files -BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX) -BIN_FILES-y += mkimage$(SFX) +BIN_FILES-$(CONFIG_LCD_LOGO) += bmp_logo$(SFX) +BIN_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo$(SFX) BIN_FILES-$(CONFIG_ENV_IS_EMBEDDED) += envcrc$(SFX) BIN_FILES-$(CONFIG_ENV_IS_IN_DATAFLASH) += envcrc$(SFX) BIN_FILES-$(CONFIG_ENV_IS_IN_EEPROM) += envcrc$(SFX) @@ -76,31 +76,31 @@ BIN_FILES-$(CONFIG_ENV_IS_IN_ONENAND) += envcrc$(SFX) BIN_FILES-$(CONFIG_ENV_IS_IN_NAND) += envcrc$(SFX) BIN_FILES-$(CONFIG_ENV_IS_IN_NVRAM) += envcrc$(SFX) BIN_FILES-$(CONFIG_ENV_IS_IN_SPI_FLASH) += envcrc$(SFX) -BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX) BIN_FILES-$(CONFIG_CMD_NET) += gen_eth_addr$(SFX) -BIN_FILES-$(CONFIG_LCD_LOGO) += bmp_logo$(SFX) -BIN_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo$(SFX) +BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX) BIN_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes$(SFX) +BIN_FILES-y += mkimage$(SFX) BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX) +BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX) # Source files which exist outside the tools directory EXT_OBJ_FILES-y += common/env_embedded.o +EXT_OBJ_FILES-y += common/image.o EXT_OBJ_FILES-y += lib_generic/crc32.o EXT_OBJ_FILES-y += lib_generic/md5.o EXT_OBJ_FILES-y += lib_generic/sha1.o -EXT_OBJ_FILES-y += common/image.o # Source files located in the tools directory -OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o -OBJ_FILES-y += mkimage.o -OBJ_FILES-$(CONFIG_ENV_IS_EMBEDDED) += envcrc.o -OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o -OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o OBJ_FILES-$(CONFIG_LCD_LOGO) += bmp_logo.o OBJ_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo.o +OBJ_FILES-$(CONFIG_ENV_IS_EMBEDDED) += envcrc.o +OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o +OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o +OBJ_FILES-y += mkimage.o OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o OBJ_FILES-y += os_support.o +OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o # Don't build by default #ifeq ($(ARCH),ppc) @@ -160,30 +160,22 @@ MAKEDEPEND = makedepend all: $(obj).depend $(BINS) $(LOGO-y) subdirs -$(obj)envcrc$(SFX):$(obj)envcrc.o $(obj)crc32.o $(obj)env_embedded.o $(obj)sha1.o - $(CC) $(CFLAGS) -o $@ $^ - -$(obj)ubsha1$(SFX):$(obj)ubsha1.o $(obj)sha1.o $(obj)os_support.o - $(CC) $(CFLAGS) -o $@ $^ - -$(obj)img2srec$(SFX): $(obj)img2srec.o +$(obj)bin2header$(SFX): $(obj)bin2header.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@ -$(obj)mkimage$(SFX): $(obj)mkimage.o $(obj)crc32.o $(obj)image.o $(obj)md5.o \ - $(obj)sha1.o $(LIBFDT_OBJS) $(obj)os_support.o +$(obj)bmp_logo$(SFX): $(obj)bmp_logo.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@ -$(obj)ncb$(SFX): $(obj)ncb.o - $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ - $(STRIP) $@ +$(obj)envcrc$(SFX):$(obj)crc32.o $(obj)env_embedded.o $(obj)envcrc.o $(obj)sha1.o + $(CC) $(CFLAGS) -o $@ $^ $(obj)gen_eth_addr$(SFX): $(obj)gen_eth_addr.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@ -$(obj)bmp_logo$(SFX): $(obj)bmp_logo.o +$(obj)img2srec$(SFX): $(obj)img2srec.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@ @@ -191,14 +183,22 @@ $(obj)inca-swap-bytes$(SFX): $(obj)inca-swap-bytes.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@ +$(obj)mkimage$(SFX): $(obj)crc32.o $(obj)mkimage.o $(obj)image.o $(obj)md5.o $(obj)mkimage.o \ + $(obj)os_support.o $(obj)sha1.o $(LIBFDT_OBJS) + $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ + $(STRIP) $@ + $(obj)mpc86x_clk$(SFX):$(obj)mpc86x_clk.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@ -$(obj)bin2header$(SFX): $(obj)bin2header.o +$(obj)ncb$(SFX): $(obj)ncb.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@ +$(obj)ubsha1$(SFX):$(obj)os_support.o $(obj)sha1.o $(obj)ubsha1.o + $(CC) $(CFLAGS) -o $@ $^ + # Some files complain if compiled with -pedantic, use FIT_CFLAGS $(obj)image.o: $(SRCTREE)/common/image.c $(CC) -g $(FIT_CFLAGS) -c -o $@ $< -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage: Makefile sorted
Dear Prafulla Wadaskar, In message <1249917246-20224-1-git-send-email-prafu...@marvell.com> you wrote: > The tools/Makefile is sorted for all entries, > > Signed-off-by: Prafulla Wadaskar > --- > tools/Makefile | 50 +- > 1 files changed, 25 insertions(+), 25 deletions(-) Applied to mkimage branch, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: unused code removal mpc86x_clk.c
It is observed that tools/mpc86x_clk.c is not referred anywhere
the build entry was commented in Makefile,
all the references related to this file are removed
Signed-off-by: Prafulla Wadaskar
---
tools/Makefile | 10 ---
tools/mpc86x_clk.c | 218
2 files changed, 0 insertions(+), 228 deletions(-)
delete mode 100644 tools/mpc86x_clk.c
diff --git a/tools/Makefile b/tools/Makefile
index 6f36f23..7036b34 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -102,12 +102,6 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
OBJ_FILES-y += os_support.o
OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o
-# Don't build by default
-#ifeq ($(ARCH),ppc)
-#BIN_FILES-y += mpc86x_clk$(SFX)
-#OBJ_FILES-y += mpc86x_clk.o
-#endif
-
# Flattened device tree objects
LIBFDT_OBJ_FILES-y += fdt.o
LIBFDT_OBJ_FILES-y += fdt_ro.o
@@ -188,10 +182,6 @@ $(obj)mkimage$(SFX): $(obj)crc32.o $(obj)mkimage.o
$(obj)image.o $(obj)md5.o $(o
$(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^
$(STRIP) $@
-$(obj)mpc86x_clk$(SFX):$(obj)mpc86x_clk.o
- $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^
- $(STRIP) $@
-
$(obj)ncb$(SFX): $(obj)ncb.o
$(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^
$(STRIP) $@
diff --git a/tools/mpc86x_clk.c b/tools/mpc86x_clk.c
deleted file mode 100644
index 8dfbd4e..000
--- a/tools/mpc86x_clk.c
+++ /dev/null
@@ -1,218 +0,0 @@
-/*
- * (C) Copyright 2003 Intracom S.A.
- * Pantelis Antoniou
- *
- * This little program makes an exhaustive search for the
- * correct terms of pdf, mfi, mfn, mfd, s, dbrmo, in PLPRCR.
- * The goal is to produce a gclk2 from a xin input, while respecting
- * all the restrictions on their combination.
- *
- * Generaly you select the first row of the produced table.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-
-#include
-#include
-
-#define DPREF_MIN 1000
-#define DPREF_MAX 3200
-
-#define DPGDCK_MAX 32000
-#define DPGDCK_MIN 16000
-
-#define S_MIN 0
-#define S_MAX 2
-
-#define MFI_MIN5
-#define MFI_MAX15
-
-#define MFN_MIN0
-#define MFN_MAX15
-
-#define MFD_MIN0
-#define MFD_MAX31
-
-#define MF_MIN 5
-#define MF_MAX 15
-
-#define PDF_MIN0
-#define PDF_MAX15
-
-#define GCLK2_MAX 15000
-
-static int calculate (int xin, int target_clock,
- int ppm, int pdf, int mfi, int mfn, int mfd, int s,
- int *dprefp, int *dpgdckp, int *jdbckp,
- int *gclk2p, int *dbrmop)
-{
- unsigned int dpref, dpgdck, jdbck, gclk2, t1, t2, dbrmo;
-
- /* valid MFI? */
- if (mfi < MFI_MIN)
- return -1;
-
- /* valid num, denum? */
- if (mfn > 0 && mfn >= mfd)
- return -1;
-
- dpref = xin / (pdf + 1);
-
- /* valid dpef? */
- if (dpref < DPREF_MIN || dpref > DPREF_MAX)
- return -1;
-
- if (mfn == 0) {
- dpgdck = (2 * mfi * xin) / (pdf + 1) ;
- dbrmo = 0;
- } else {
- /* 5 <= mfi + (mfn / mfd + 1) <= 15 */
- t1 = mfd + 1;
- t2 = mfi * t1 + mfn;
- if ( MF_MIN * t1 > t2 || MF_MAX * t1 < t2)
- return -1;
-
- dpgdck = (unsigned int)(2 * (mfi * mfd + mfi + mfn) *
- (unsigned int)xin) /
- ((mfd + 1) * (pdf + 1));
-
- dbrmo = 10 * mfn < (mfd + 1);
- }
-
- /* valid dpgclk? */
- if (dpgdck < DPGDCK_MIN || dpgdck > DPGDCK_MAX)
- return -1;
-
- jdbck = dpgdck >> s;
- gclk2 = jdbck / 2;
-
- /* valid gclk2 */
- if (gclk2 > GCLK2_MAX)
- return -1;
-
- t1 = abs(gclk2 - target_clock);
-
- /* XXX max 1MHz dev. in clock */
- if (t1 > 100)
- return -1;
-
- /* dev within range (XXX gclk2 scaled to avoid overflow) */
- if (t1 * 1000 > (unsigned int)ppm * (gclk2 / 1000))
- return -1;
-
- *dpref
Re: [U-Boot] [PATCH] tools: unused code removal mpc86x_clk.c
Dear Prafulla Wadaskar, In message <1249917879-26559-1-git-send-email-prafu...@marvell.com> you wrote: > It is observed that tools/mpc86x_clk.c is not referred anywhere > the build entry was commented in Makefile, > all the references related to this file are removed > > Signed-off-by: Prafulla Wadaskar Why are you removing this tool? Even though it does not get build by default, it is still pretty useful when you have to design the clock system on a MPC8xx processor. 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 "There are three principal ways to lose money: wine, women, and engi- neers. While the first two are more pleasant, the third is by far the more certain." - Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: unused code removal mpc86x_clk.c
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Monday, August 10, 2009 4:49 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik > Subject: Re: [U-Boot] [PATCH] tools: unused code removal mpc86x_clk.c > > Dear Prafulla Wadaskar, > > In message > <1249917879-26559-1-git-send-email-prafu...@marvell.com> you wrote: > > It is observed that tools/mpc86x_clk.c is not referred anywhere the > > build entry was commented in Makefile, all the references > related to > > this file are removed > > > > Signed-off-by: Prafulla Wadaskar > > Why are you removing this tool? Even though it does not get > build by default, it is still pretty useful when you have to > design the clock system on a MPC8xx processor. I agree, but why it is not build by default? can someone provide the fix to build it? even conditional build is okay. Regards.. Prafulla .. > > 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 "There are three principal ways to lose money: > wine, women, and engi- neers. While the first two are more > pleasant, the third is by far the > more certain." - Baron Rothschild, ca. 1800 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.08-rc2 is out
Wolfgang Denk wrote: > Summary of current status: > > * Many boards now throw the (expected) > > #warning Ethernet driver is deprecated. Please update to use > CONFIG_NET_MULTI > > messages. I found qemu_mips_config is spotted by it: Configuring for qemu-mips board... eth.c:497:2: warning: #warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI But I don't follow the recent changes including that CONFIG_NET_MULTI migration, nor I don't have enough spare time to look into it, so gave up this time, sorry. > * ARM and PowerPC: mostly compile clean; there are a few issues, > responsible s have been notified For the rest, MIPS builds are pretty in good shape as follows. skuri...@ubuntu:u-boot.git$ ./MAKEALL mips mips_el Configuring for incaip board... textdata bss dec hex filename 1470326476 20240 173748 2a6b4 ./u-boot Configuring for qemu-mips board... eth.c:497:2: warning: #warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI textdata bss dec hex filename 1717446340 221768 399852 619ec ./u-boot ... on Platinum board variant Configuring for vct board... textdata bss dec hex filename 199916 12568 284420 496904 79508 ./u-boot ... on Platinum board variant ... stripped down image variant Configuring for vct board... textdata bss dec hex filename 882964196 13716 106208 19ee0 ./u-boot ... on Platinum board variant ... on OneNAND board variant Configuring for vct board... textdata bss dec hex filename 296608 13728 289764 600100 92824 ./u-boot ... on Platinum board variant ... on OneNAND board variant ... stripped down image variant Configuring for vct board... textdata bss dec hex filename 1840165344 19080 208440 32e38 ./u-boot ... on PlatinumAVC board variant Configuring for vct board... textdata bss dec hex filename 1185085112 14944 138564 21d44 ./u-boot ... on PlatinumAVC board variant ... stripped down image variant Configuring for vct board... textdata bss dec hex filename 878164196 13716 105728 19d00 ./u-boot ... on PlatinumAVC board variant ... on OneNAND board variant Configuring for vct board... textdata bss dec hex filename 2152646268 20308 241840 3b0b0 ./u-boot ... on PlatinumAVC board variant ... on OneNAND board variant ... stripped down image variant Configuring for vct board... textdata bss dec hex filename 1835285344 19080 207952 32c50 ./u-boot ... on Premium board variant Configuring for vct board... textdata bss dec hex filename 199916 12568 284420 496904 79508 ./u-boot ... on Premium board variant ... stripped down image variant Configuring for vct board... textdata bss dec hex filename 882964196 13716 106208 19ee0 ./u-boot ... on Premium board variant ... on OneNAND board variant Configuring for vct board... textdata bss dec hex filename 296608 13728 289764 600100 92824 ./u-boot ... on Premium board variant ... on OneNAND board variant ... stripped down image variant Configuring for vct board... textdata bss dec hex filename 1840165344 19080 208440 32e38 ./u-boot Configuring for purple board... textdata bss dec hex filename 1476886168 18956 172812 2a30c ./u-boot Configuring for dbau1x00 board... textdata bss dec hex filename 1209285172 20680 146780 23d5c ./u-boot Configuring for dbau1x00 board... textdata bss dec hex filename 1209285172 20680 146780 23d5c ./u-boot Configuring for dbau1x00 board... textdata bss dec hex filename 1209285172 20680 146780 23d5c ./u-boot Configuring for dbau1x00 board... textdata bss dec hex filename 1169365256 23352 145544 23888 ./u-boot Configuring for dbau1x00 board... textdata bss dec hex filename 1169365256 23352 145544 23888 ./u-boot Configuring for gth2 board... textdata bss dec hex filename 1116565140 18376 135172 21004 ./u-boot Configuring for dbau1x00 board... textdata bss dec hex filename 1169365256 23352 145544 23888 ./u-boot Configuring for pb1x00 board... textdata bss dec hex filename 1064606004 20488 132952 20758 ./u-boot skuri...@ubuntu:u-boot.git$ skuri...@ubuntu:u-boot.git$ skuri...@ubuntu:u-boot.git$ mips-linux-gnu-gcc --version mips-linux-gnu-gcc (Sourcery G++ Lite 4.3-154) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. skuri...@ubuntu:u-boot.git$ mips-linux-gnu-as --version GNU assemb
Re: [U-Boot] smc91111 net_multi update
On 11:11 Mon 27 Jul , Ben Warren wrote: > Hi Mike, > > Mike Frysinger wrote: > > On Monday 27 July 2009 05:26:07 Wolfgang Denk wrote: > > > >> * Many boards now throw the (expected) > >> > >> #warning Ethernet driver is deprecated. Please update to use > >> CONFIG_NET_MULTI > >> > >> messages. > >> > > > > i see this on a bunch of Blackfin boards all due to the SMC9 driver. > > do > > you have any immediate/midterm plans to port this driver Ben ? i'm > > assuming > > the SMC911X driver doesnt support all the parts that the SMC9 driver > > does, > > so simply jumping away to the SMC911X driver isnt an option ... > > -mike > > > I have it completely ported, and plan to post it as soon as I get a > chance. The only thing left to do is port all of the eeprom.c > standalone apps (I have one done already so the others shouldn't take > much time). > I've also done it and the eeprom is working I'll post it later today wish 2 other patch for net Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: unused code removal mpc86x_clk.c
Dear Prafulla Wadaskar, In message <73173d32e9439e4abb5151606c3e19e202e370b...@sc-vexch1.marvell.com> you wrote: > > > Why are you removing this tool? Even though it does not get=20 > > build by default, it is still pretty useful when you have to=20 > > design the clock system on a MPC8xx processor. > I agree, but why it is not build by default? It just adds to the build time, and probably nobody ever uses it. > can someone provide the fix to build it? > even conditional build is okay. What exactly is the problem you're tryting to address? Some commented out code in the Makefile? 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 One possible reason that things aren't going according to plan is that there never was a plan in the first place. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 2:56 AM, Wolfgang Denk wrote: > Dear Kumar, > > I cannot build the MPC8536DS board any more using the ELDK 4.2 tool > chain (gcc 4.2.2): > > ppc_85xx-ld: section .bootpg [e000 -> e1cb] overlaps > section .data.rel.local [efffe5d0 -> e > c7b] > ppc_85xx-ld: section .resetvec [effc -> efff] overlaps > section .u_boot_cmd [ec9c -> f3e > b] > ppc_85xx-ld: u-boot: section .bootpg lma 0xe000 overlaps > previous sections > ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xec7c overlaps > previous sections > ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xec9c overlaps > previous sections > ppc_85xx-ld: u-boot: section .resetvec lma 0xeffc overlaps > previous sections > > > Could you please have a look? The e1000 driver updates seem to contribute a bit to code bloat. text data bss dec hex filename 427664 52160 300093 779917 be68d u-boot new e1000 417628 51980 300093 769701 bbea5 u-boot old e1000 Not sure what we can do about it. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Compilation erros while trying at compile ARM DaVinci
I get the following compilation errors when I try to compile DaVinci DM355 on the latest U-Boot source. I thought I saw similar issues on the mailing list some time back. Have these been resolved? 3.2/libgcc.a(_udivsi3.o) has EABI version 5, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_udivsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_divsi3.o) has EABI version 5, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_divsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_umodsi3.o) has EABI version 5, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_umodsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_modsi3.o) has EABI version 5, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_modsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o) has EABI version 5, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o) /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o): In function `__aeabi_ldiv0': (.text+0x8): undefined reference to `raise Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compilation erros while trying at compile ARM DaVinci
Hi, aulraj, Sandeep a écrit : > I get the following compilation errors when I try to compile DaVinci DM355 on > the latest U-Boot source. I thought I saw similar issues on the mailing list > some time back. Have these been resolved? > > > 3.2/libgcc.a(_udivsi3.o) has EABI version 5, but target u-boot has EABI > version 0 > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_udivsi3.o) > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_divsi3.o) > has EABI version 5, but target u-boot has EABI version 0 > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_divsi3.o) > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_umodsi3.o) > has EABI version 5, but target u-boot has EABI version 0 > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_umodsi3.o) > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_modsi3.o) > has EABI version 5, but target u-boot has EABI version 0 > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_modsi3.o) > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o) > has EABI version 5, but target u-boot has EABI version 0 > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o) > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o): > In function `__aeabi_ldiv0': > (.text+0x8): undefined reference to `raise > try to add USE_PRIVATE_LIBGCC=yes to you make commande. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compilation erros while trying at compile ARM DaVinci
> -Original Message- > From: Eric Bénard [mailto:e...@eukrea.com] > Sent: Monday, August 10, 2009 11:26 AM > To: Paulraj, Sandeep > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] Compilation erros while trying at compile ARM > DaVinci > > Hi, > > aulraj, Sandeep a écrit : > > I get the following compilation errors when I try to compile DaVinci > DM355 on the latest U-Boot source. I thought I saw similar issues on the > mailing list some time back. Have these been resolved? > > > > > > 3.2/libgcc.a(_udivsi3.o) has EABI version 5, but target u-boot has EABI > version 0 > > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_udivsi3.o) > > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_divsi3.o) has EABI version 5, but target u-boot > has EABI version 0 > > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_divsi3.o) > > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_umodsi3.o) has EABI version 5, but target u-boot > has EABI version 0 > > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_umodsi3.o) > > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_modsi3.o) has EABI version 5, but target u-boot > has EABI version 0 > > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_modsi3.o) > > arm-none-linux-gnueabi-ld: ERROR: Source object > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o) has EABI version 5, but target u-boot > has EABI version 0 > > arm-none-linux-gnueabi-ld: failed to merge target specific data of file > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o) > > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux- > gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o): In function `__aeabi_ldiv0': > > (.text+0x8): undefined reference to `raise > > > try to add USE_PRIVATE_LIBGCC=yes to you make commande. [Sandeep] It compiles. Is this some kind of a permanent solution? I see lots of e-mails on arm not including libgcc. > > Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compilation erros while trying at compile ARM DaVinci
Hi Sandeep, >> try to add USE_PRIVATE_LIBGCC=yes to you make commande. > [Sandeep] It compiles. Is this some kind of a permanent solution? > I see lots of e-mails on arm not including libgcc. It should not be a permanent solution. It is need however as long as a) ARM on U-Boot forces the ABI to be compiled for to be "-mabi=apcs-gnu" (check cpu/arm*/config.mk) in contrast to the newer GNUEABI and b) your toolchain does not have a libgcc compiled for this ABI version (true for recent toolchains which use the newer GNUEABI. This is my take on the situation. I lost track however why a) is the case. Maybe someone can help my memory here. Cheers Detlev -- The mathematician's patterns, like the painter's or the poet's, must be beautiful; the ideas, like the colours or the words, must fit together in a harmonious way. Beauty is the first test: there is no permanent place in the world for ugly mathematics. -- G. H. Hardy -- 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
[U-Boot] [PATCH] ARM: Davinci DM355: Enabling DM9000 on DM355 EVM
From: Sandeep Paulraj
Due to recent changes to the NET support on U-boot, DM9000
is no longer detected on the DM355 EVM.
This minor update enables DM9000 on the DM355 EVM.
Tested on the DM355 EVM
Signed-off-by: Sandeep Paulraj
---
board/davinci/dm355evm/dm355evm.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/board/davinci/dm355evm/dm355evm.c
b/board/davinci/dm355evm/dm355evm.c
index 398f527..0a44748 100644
--- a/board/davinci/dm355evm/dm355evm.c
+++ b/board/davinci/dm355evm/dm355evm.c
@@ -23,7 +23,8 @@
#include
#include
#include "../common/misc.h"
-
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -79,6 +80,13 @@ int board_init(void)
return 0;
}
+#ifdef CONFIG_DRIVER_DM9000
+int board_eth_init(bd_t *bis)
+{
+ return dm9000_initialize(bis);
+}
+#endif
+
#ifdef CONFIG_NAND_DAVINCI
static void nand_dm355evm_select_chip(struct mtd_info *mtd, int chip)
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3 and Cortex A8 status
As with recent git head, v2009.08-rc2, all OMAP3 and Cortex A8 patches I had in my pending patches list are in mainline now* :) If you think your patch isn't applied yet, or you have something depending on the patches applied now, re-base it against recent head and please (re-) send (again). Thanks to everybody who helped, especially Wolfgang, Dirk * Except dcache_flush patch still under discussion ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
Kumar Gala wrote: > On Aug 10, 2009, at 2:56 AM, Wolfgang Denk wrote: > > >> Dear Kumar, >> >> I cannot build the MPC8536DS board any more using the ELDK 4.2 tool >> chain (gcc 4.2.2): >> >> ppc_85xx-ld: section .bootpg [e000 -> e1cb] overlaps >> section .data.rel.local [efffe5d0 -> e >> c7b] >> ppc_85xx-ld: section .resetvec [effc -> efff] overlaps >> section .u_boot_cmd [ec9c -> f3e >> b] >> ppc_85xx-ld: u-boot: section .bootpg lma 0xe000 overlaps >> previous sections >> ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xec7c overlaps >> previous sections >> ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xec9c overlaps >> previous sections >> ppc_85xx-ld: u-boot: section .resetvec lma 0xeffc overlaps >> previous sections >> >> >> Could you please have a look? >> > > The e1000 driver updates seem to contribute a bit to code bloat. > > text data bss dec hex filename > 42766452160 300093 779917 be68d u-boot new > e1000 > 41762851980 300093 769701 bbea5 u-boot old > e1000 > > Not sure what we can do about it. > > - k > Adding PCI-E support to this driver added an astounding 3000+ lines to the driver. I asked Roy to pare it back, but it was still pretty huge. If this size increase is a serious issue, I support backing this patch out and refactoring it to include only the features that are necessary for a bootloader. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: unused code removal mpc86x_clk.c
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Monday, August 10, 2009 6:30 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik > Subject: Re: [U-Boot] [PATCH] tools: unused code removal mpc86x_clk.c > > Dear Prafulla Wadaskar, > > In message > <73173d32e9439e4abb5151606c3e19e202e370b...@sc-vexch1.marvell. > com> you wrote: > > > > > Why are you removing this tool? Even though it does not > get=20 build > > > by default, it is still pretty useful when you have to=20 > design the > > > clock system on a MPC8xx processor. > > I agree, but why it is not build by default? > > It just adds to the build time, and probably nobody ever uses it. > > > can someone provide the fix to build it? > > even conditional build is okay. > > What exactly is the problem you're tryting to address? Some > commented out code in the Makefile? Exactly, let's remove this dead code or support it properly. What do you think? Copying Pantelis Antoniou, writer of this code Regards.. Prafulla . . > > 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 One possible reason that things aren't going > according to plan is that there never was a plan in the > first place. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc91111 net_multi update
Jean-Christophe PLAGNIOL-VILLARD wrote: > On 11:11 Mon 27 Jul , Ben Warren wrote: > >> Hi Mike, >> >> Mike Frysinger wrote: >> >>> On Monday 27 July 2009 05:26:07 Wolfgang Denk wrote: >>> >>> * Many boards now throw the (expected) #warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI messages. >>> i see this on a bunch of Blackfin boards all due to the SMC9 driver. >>> do >>> you have any immediate/midterm plans to port this driver Ben ? i'm >>> assuming >>> the SMC911X driver doesnt support all the parts that the SMC9 driver >>> does, >>> so simply jumping away to the SMC911X driver isnt an option ... >>> -mike >>> >>> >> I have it completely ported, and plan to post it as soon as I get a >> chance. The only thing left to do is port all of the eeprom.c >> standalone apps (I have one done already so the others shouldn't take >> much time). >> >> > I've also done it and the eeprom is working > > I'll post it later today wish 2 other patch for net > > Best Regards, > J. > What are you planning on posting? It looks to me like you say it works OK. Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache
Dirk Behme wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: >> On 16:35 Sat 08 Aug , Dirk Behme wrote: >>> Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:47 Sat 08 Aug , Dirk Behme wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: >> On 12:46 Sat 08 Aug , Dirk Behme wrote: >>> Since there is only one version of flushing the dcache for >>> arm_cortex8, rename v7_flush_dcache_all to the the generic >>> name flush_dcache. Because the function is intended for >>> only omap3 boards, move the function to the new file >>> cache_flush.S. >>> >>> Signed-off-by: Tom Rix >>> Signed-off-by: Dirk Behme >>> --- >> NACK keep the arm arch version in the name > NACK the NACK, see below. > >> and as request to Tom remove the non need device_type >> and we can safely use the v7 cache flush for omap3 and other >> cortex a8 > This can be done easily (later?) by an additional patch (when people > have time for it?). > > Applying the basic functionality (function move) now allows others > to finally go on with their long waiting patches. no this code is omap3 specific and there is no need ot this rename or move the function make no sense >>> Yes, it is OMAP3 specific (as already mentioned in the patch >>> description). So it's totally fine to move it to an OMAP3 specific >>> file. So it's totally fine that others (!= OMAP3, e.g Samsung) can >>> re-use arm_cortexa8 stuff without the burden of OMAP3 stuff. >> the flush MUST NOT be soc specific as there is NO need to do this >> at all >> >> so NACK > > Let's summarize: > > - First, you NACK because of device_type and function name > - Then, you mention "this code is omap3 specific" > - Then, you mention "this code is not needed at all" > > Sorry, but this sounds somehow confusing, better let us stop here. > > As already mentioned, let us apply the patch so that other Cortex A8 > patches are not stalled any more. At the weekend, I missed the point why this code is OMAP3 specific and why it has to be moved to omap3 directory, so short update: It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g. Samsung. That is, it must be moved to not stall others any more. (Thanks to Tom for remembering this!) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2009.08-rc2 is out
Hi Shinya, Shinya Kuribayashi wrote: > Wolfgang Denk wrote: > >> Summary of current status: >> >> * Many boards now throw the (expected) >> >> #warning Ethernet driver is deprecated. Please update to use >> CONFIG_NET_MULTI >> >> messages. >> > > I found qemu_mips_config is spotted by it: > Configuring for qemu-mips board... > eth.c:497:2: warning: #warning Ethernet driver is deprecated. Please update > to use CONFIG_NET_MULTI > > But I don't follow the recent changes including that CONFIG_NET_MULTI > migration, nor I don't have enough spare time to look into it, so gave > up this time, sorry. > > The DM9000 driver uses the old networking API, and needs to be updated. I have it partly done and will be submitting to the ML soon. Hopefully you'll be able to test my patch :) regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] NAND: ADD page Parameter to all read_page/read_page_raw API's
From: Sandeep Paulraj
This patch adds a new "page" parameter to all NAND read_page/read_page_raw
APIs. The read_page API for the new mode ECC_HW_OOB_FIRST requires the
page information to send the READOOB command and read the OOB area before
the data area.
This patch has been accepted by Andrew Morton and can be found at
http://userweb.kernel.org/~akpm/mmotm/broken-out/mtd-nand-add-page-parameter-to-all-read_page-read_page_raw-apis.patch
WE would like this to become part of the u-boot GIT as well
Signed-off-by: Sandeep Paulraj
Signed-off-by: Sneha Narnakaje
---
drivers/mtd/nand/fsl_elbc_nand.c |2 +-
drivers/mtd/nand/nand_base.c | 16 +---
include/linux/mtd/nand.h |4 ++--
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 77a33c0..50cb4aa 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -662,7 +662,7 @@ static int fsl_elbc_wait(struct mtd_info *mtd, struct
nand_chip *chip)
static int fsl_elbc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
fsl_elbc_read_buf(mtd, buf, mtd->writesize);
fsl_elbc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 360b070..ca02628 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -895,7 +895,7 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip
*this)
* @buf: buffer to store read data
*/
static int nand_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
chip->read_buf(mtd, buf, mtd->writesize);
chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -909,7 +909,7 @@ static int nand_read_page_raw(struct mtd_info *mtd, struct
nand_chip *chip,
* @buf: buffer to store read data
*/
static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
@@ -919,7 +919,7 @@ static int nand_read_page_swecc(struct mtd_info *mtd,
struct nand_chip *chip,
uint8_t *ecc_code = chip->buffers->ecccode;
uint32_t *eccpos = chip->ecc.layout->eccpos;
- chip->ecc.read_page_raw(mtd, chip, buf);
+ chip->ecc.read_page_raw(mtd, chip, buf, page);
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
chip->ecc.calculate(mtd, p, &ecc_calc[i]);
@@ -1032,7 +1032,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct
nand_chip *chip, uint3
* Not for syndrome calculating ecc controllers which need a special oob layout
*/
static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
@@ -1077,7 +1077,7 @@ static int nand_read_page_hwecc(struct mtd_info *mtd,
struct nand_chip *chip,
* we need a special oob layout and handling.
*/
static int nand_read_page_syndrome(struct mtd_info *mtd, struct nand_chip
*chip,
- uint8_t *buf)
+ uint8_t *buf, int page)
{
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
@@ -1219,11 +1219,13 @@ static int nand_do_read_ops(struct mtd_info *mtd,
loff_t from,
/* Now read the page into the buffer */
if (unlikely(ops->mode == MTD_OOB_RAW))
- ret = chip->ecc.read_page_raw(mtd, chip,
bufpoi);
+ ret = chip->ecc.read_page_raw(mtd, chip,
+ bufpoi, page);
else if (!aligned && NAND_SUBPAGE_READ(chip) && !oob)
ret = chip->ecc.read_subpage(mtd, chip, col,
bytes, bufpoi);
else
- ret = chip->ecc.read_page(mtd, chip, bufpoi);
+ ret = chip->ecc.read_page(mtd, chip, bufpoi,
+ page);
if (ret < 0)
break;
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 3e0044b..d6aa392 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -268,13 +268,13 @@ struct nand_ecc_ctrl {
uint8_t *calc_ecc);
int (*read_page_raw)(struct mtd_info *mtd,
[U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST
From: Sandeep Paulraj
This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
chips. This ECC mode is similar to NAND_ECC_HW, with the exception of
read_page API that first reads the OOB area, reads the data in chunks,
feeds the ECC from OOB area to the ECC hw engine and perform any
correction on the data as per the ECC status reported by the engine.
This patch has been accepted by Andrew Morton and can be found at
http://userweb.kernel.org/~akpm/mmotm/broken-out/mtd-nand-add-new-ecc-mode-ecc_hw_oob_first.patch
Signed-off-by: Sandeep Paulraj
Signed-off-by: Sneha Narnakaje
---
drivers/mtd/nand/nand_base.c | 59 ++
include/linux/mtd/nand.h |1 +
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ca02628..426bb95 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1068,6 +1068,54 @@ static int nand_read_page_hwecc(struct mtd_info *mtd,
struct nand_chip *chip,
}
/**
+ * nand_read_page_hwecc_oob_first - [REPLACABLE] hw ecc, read oob first
+ * @mtd: mtd info structure
+ * @chip: nand chip info structure
+ * @buf: buffer to store read data
+ *
+ * Hardware ECC for large page chips, require OOB to be read first.
+ * For this ECC mode, the write_page method is re-used from ECC_HW.
+ * These methods read/write ECC from the OOB area, unlike the
+ * ECC_HW_SYNDROME support with multiple ECC steps, follows the
+ * "infix ECC" scheme and reads/writes ECC from the data area, by
+ * overwriting the NAND manufacturer bad block markings.
+ */
+static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
+ struct nand_chip *chip, uint8_t *buf, int page)
+{
+ int i, eccsize = chip->ecc.size;
+ int eccbytes = chip->ecc.bytes;
+ int eccsteps = chip->ecc.steps;
+ uint8_t *p = buf;
+ uint8_t *ecc_code = chip->buffers->ecccode;
+ uint32_t *eccpos = chip->ecc.layout->eccpos;
+ uint8_t *ecc_calc = chip->buffers->ecccalc;
+
+ /* Read the OOB area first */
+ chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
+ chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+ chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+
+ for (i = 0; i < chip->ecc.total; i++)
+ ecc_code[i] = chip->oob_poi[eccpos[i]];
+
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
+ int stat;
+
+ chip->ecc.hwctl(mtd, NAND_ECC_READ);
+ chip->read_buf(mtd, p, eccsize);
+ chip->ecc.calculate(mtd, p, &ecc_calc[i]);
+
+ stat = chip->ecc.correct(mtd, p, &ecc_code[i], NULL);
+ if (stat < 0)
+ mtd->ecc_stats.failed++;
+ else
+ mtd->ecc_stats.corrected += stat;
+ }
+ return 0;
+}
+
+/**
* nand_read_page_syndrome - [REPLACABLE] hardware ecc syndrom based page read
* @mtd: mtd info structure
* @chip: nand chip info structure
@@ -2730,6 +2778,17 @@ int nand_scan_tail(struct mtd_info *mtd)
chip->ecc.write_page_raw = nand_write_page_raw;
switch (chip->ecc.mode) {
+ case NAND_ECC_HW_OOB_FIRST:
+ /* Similar to NAND_ECC_HW, but a separate read_page handle */
+ if (!chip->ecc.calculate || !chip->ecc.correct ||
+!chip->ecc.hwctl) {
+ printk(KERN_WARNING "No ECC functions supplied, "
+ "Hardware ECC not possible\n");
+ BUG();
+ }
+ if (!chip->ecc.read_page)
+ chip->ecc.read_page = nand_read_page_hwecc_oob_first;
+
case NAND_ECC_HW:
/* Use standard hwecc read page function ? */
if (!chip->ecc.read_page)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index d6aa392..cb7c19a 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -128,6 +128,7 @@ typedef enum {
NAND_ECC_SOFT,
NAND_ECC_HW,
NAND_ECC_HW_SYNDROME,
+ NAND_ECC_HW_OOB_FIRST,
} nand_ecc_modes_t;
/*
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Ping on u-boot patch status
Hi Ben, Just ping-ing the status of these patches to u-boot. If I have sent them badly, please let me know and I can repost. 1. 83xx: UEC: Added support for bitBang MII driver access to PHYs http://www.mail-archive.com/u-boot@lists.denx.de/msg16588.html >> I am aware of peter tyser's comment and will /s CONFIG_MPC83XX with >> CONFIG_MPC83xx << 2. UEC FIXED PHY: Determine fixed-phy port using UEC interface name === http://www.mail-archive.com/u-boot@lists.denx.de/msg16587.html 3. Assigned a static SMI address to all UECs TBIPA address == http://www.mail-archive.com/u-boot@lists.denx.de/msg16586.html Thanks very much for your time - Richard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
Dear Kumar Gala, In message <0e1a5eeb-51e5-488d-9457-993f95553...@kernel.crashing.org> you wrote: > > > Could you please have a look? > > The e1000 driver updates seem to contribute a bit to code bloat. ... > Not sure what we can do about it. Allocate more space for U-Boot? 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 You Earth people glorified organized violence for forty centuries. But you imprison those who employ it privately. -- Spock, "Dagger of the Mind", stardate 2715.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 12:59 PM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message > <0e1a5eeb-51e5-488d-9457-993f95553...@kernel.crashing.org> you wrote: >> >>> Could you please have a look? >> >> The e1000 driver updates seem to contribute a bit to code bloat. > ... >> Not sure what we can do about it. > > Allocate more space for U-Boot? I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
Dear Kumar Gala, In message <0eb7516a-2f14-42f7-a6ed-555adfab3...@kernel.crashing.org> you wrote: > > > Allocate more space for U-Boot? > > I might turn of BEDBUG as its never been properly enabled on e500/85xx > platforms. Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector, and that's it. 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 easiest way to figure the cost of living is to take your income and add ten percent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <0EB7516A-2F14-42F7- > a6ed-555adfab3...@kernel.crashing.org> you wrote: >> >>> Allocate more space for U-Boot? >> >> I might turn of BEDBUG as its never been properly enabled on >> e500/85xx >> platforms. > > Is there any problem with the bigger image which I don't understand > yet? Normally we just move down the TEXT_BASE by a sector, and that's > it. Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Monday, August 10, 2009 13:41 PM > To: Wolfgang Denk > Cc: U-Boot-Users ML; Zang Roy-R61911 > Subject: Re: 85xx: MPC8536DS board does not build > > > On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: > > > Dear Kumar Gala, > > > > In message <0EB7516A-2F14-42F7- > > a6ed-555adfab3...@kernel.crashing.org> you wrote: > >> > >>> Allocate more space for U-Boot? > >> > >> I might turn of BEDBUG as its never been properly enabled on > >> e500/85xx > >> platforms. > > > > Is there any problem with the bigger image which I don't understand > > yet? Normally we just move down the TEXT_BASE by a sector, > and that's > > it. > > Not specifically, its just that ever 85xx image to date has been > 512k. I'm just trying to avoid this being the first one that > changes > that historic fact. Especially since compilers like gcc-4.3 seem to > be able to fit the size in 512k. We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some plan for this? Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2][PATCH 2/2] Removed CONFIG_NUM_CPUS from 85xx/86xx
Tried it on a 8641 and seems to work fine. - k On Aug 8, 2009, at 8:23 AM, Aggrwal Poonam-B10812 wrote: > Kumar, > > I could not test these changes on any 86xx(build I have checked), > Can u test them or can I get access to some remote setup for this. > Just > to make sure the changes do not break anything. > > Regards > Poonam > >> -Original Message- >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >> Sent: Friday, August 07, 2009 10:15 PM >> To: Aggrwal Poonam-B10812 >> Cc: u-boot@lists.denx.de >> Subject: Re: [U-Boot] [v2][PATCH 2/2] Removed CONFIG_NUM_CPUS >> from 85xx/86xx >> >> >> On Jul 31, 2009, at 1:38 AM, Poonam Aggrwal wrote: >> >>> The number of CPUs are getting detected dynamically by checking the >>> processor SVR value. >>> Also removed CONFIG_NUM_CPUS references from all the platforms with >>> 85xx/86xx processors. >>> >>> This can help to use the same u-boot image across the platforms. >>> >>> Also revamped and corrected few Freescale Copyright messages. >>> >>> Signed-off-by: Poonam Aggrwal >>> --- >>> - based of 2009.08-rc1 >>> - depends on the patch >>> "[PATCH 1/2] Refactored common cpu specific code for 85xx and 86xx >>> into one file." >>> - Changes over v1: >>> Incorporated Wolfgang's comments >>> common/cmd_mp.c |6 +- >>> cpu/mpc85xx/cpu.c | 21 - >>> cpu/mpc85xx/mp.c |6 +- >>> cpu/mpc85xx/release.S | 25 +++- >>> cpu/mpc85xx/speed.c |4 +- >>> cpu/mpc86xx/cpu.c | 10 +++-- >>> cpu/mpc86xx/cpu_init.c|4 +- >>> cpu/mpc8xxx/cpu.c | 93 + >>> +--- >>> include/asm-ppc/config.h |7 +++ >>> include/asm-ppc/global_data.h |1 + >>> include/asm-ppc/processor.h |5 +- >>> include/common.h |2 + >>> include/configs/MPC8572DS.h |1 - >>> include/configs/MPC8610HPCD.h |1 - >>> include/configs/MPC8641HPCN.h |1 - >>> include/configs/P2020DS.h |1 - >>> include/configs/XPEDITE5170.h |1 - >>> include/configs/XPEDITE5370.h |1 - >>> include/configs/sbc8641d.h|1 - >>> include/e500.h|6 +-- >>> lib_ppc/board.c |3 + >>> lib_ppc/bootm.c |2 +- >>> 22 files changed, 127 insertions(+), 75 deletions(-) >> >> applied to 85xx next >> >> - k >> >> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how big is the NOR flash on 85xx boards?
I was wondering if we can see how big the NOR flash is on the XES & TQM boards. thanks. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote: > > >> -Original Message- >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >> Sent: Monday, August 10, 2009 13:41 PM >> To: Wolfgang Denk >> Cc: U-Boot-Users ML; Zang Roy-R61911 >> Subject: Re: 85xx: MPC8536DS board does not build >> >> >> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: >> >>> Dear Kumar Gala, >>> >>> In message <0EB7516A-2F14-42F7- >>> a6ed-555adfab3...@kernel.crashing.org> you wrote: > Allocate more space for U-Boot? I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms. >>> >>> Is there any problem with the bigger image which I don't understand >>> yet? Normally we just move down the TEXT_BASE by a sector, >> and that's >>> it. >> >> Not specifically, its just that ever 85xx image to date has been >> 512k. I'm just trying to avoid this being the first one that >> changes >> that historic fact. Especially since compilers like gcc-4.3 seem to >> be able to fit the size in 512k. > We may have more requirements to support graphic in u-boot. > Sooner and later, the size will exceed 512K. Should we have some plan > for this? So if we are going to increase the limit from 512k do we go to 768k or 1M? (Sector size on the board appears to 128k) I would also like to know how big the flashes are on some of the other 85xx boards that u-boot supports. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how big is the NOR flash on 85xx boards?
On Mon, 2009-08-10 at 14:07 -0500, Kumar Gala wrote: > I was wondering if we can see how big the NOR flash is on the XES & > TQM boards. XES's 85xx and 86xx boards should all have U-Boot located in a NOR flash that is either 64MB or 128MB. Sector sizes are generally 128KB. Out of curiosity, how does XES and TQM's flash size affect what Freescale does for its reference platforms? XES's preference would be to maintain the current 512KB size to maintain continuity with documentation, programming scripts, fdts, etc. Would it be possible to trim down some of the enabled config options in the larger Freescale boards? The XPedite5370 (mpc8572-based board) has quite a few features enabled, and it has a lot of room to spare: textdata bss dec hex filename 307948 26920 37384 372252 5ae1c u-boot Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
Kumar Gala wrote: > On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote: > >> >>> -Original Message- >>> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >>> Sent: Monday, August 10, 2009 13:41 PM >>> To: Wolfgang Denk >>> Cc: U-Boot-Users ML; Zang Roy-R61911 >>> Subject: Re: 85xx: MPC8536DS board does not build >>> >>> >>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: >>> Dear Kumar Gala, In message <0EB7516A-2F14-42F7- a6ed-555adfab3...@kernel.crashing.org> you wrote: >> Allocate more space for U-Boot? > I might turn of BEDBUG as its never been properly enabled on > e500/85xx > platforms. Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector, >>> and that's it. >>> Not specifically, its just that ever 85xx image to date has been >>> 512k. I'm just trying to avoid this being the first one that >>> changes >>> that historic fact. Especially since compilers like gcc-4.3 seem to >>> be able to fit the size in 512k. >> We may have more requirements to support graphic in u-boot. >> Sooner and later, the size will exceed 512K. Should we have some plan >> for this? > > So if we are going to increase the limit from 512k do we go to 768k or > 1M? (Sector size on the board appears to 128k) > > I would also like to know how big the flashes are on some of the other > 85xx boards that u-boot supports. > > - k Hi Kumar, Roy, 512K is pretty big for u-boot (not unheard of, but still...). Is it really 512K or is it using a full page to hold the boot page (top 4K of memory) and one page for the env (unavoidable): + 0x1__ | One sector dedicated for the power up page (only using 4K) + 0x0_F800_ | One sector dedicated for the env + 0x0_F000_ | Two sectors of u-boot + 0x0_E800_ | + 0x0_E000_ If that is the case, you can gain a sector (less 4K) by rearranging your memory map: + 0x1__ | One page (4K) of power up vector, the rest is u-boot + 0x0_F800_ | + 0x0_F000_ | Three sectors (less 4K) of u-boot + 0x0_E800_ | One sector dedicated for the env + 0x0_E000_ This also makes reprogramming u-boot nicer because your power up vector and u-boot itself are contiguous. Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Monday, August 10, 2009 14:06 PM > To: Zang Roy-R61911 > Cc: Wolfgang Denk; U-Boot-Users ML > Subject: Re: 85xx: MPC8536DS board does not build > > > On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote: > > > > > > >> -Original Message- > >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] > >> Sent: Monday, August 10, 2009 13:41 PM > >> To: Wolfgang Denk > >> Cc: U-Boot-Users ML; Zang Roy-R61911 > >> Subject: Re: 85xx: MPC8536DS board does not build > >> > >> > >> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: > >> > >>> Dear Kumar Gala, > >>> > >>> In message <0EB7516A-2F14-42F7- > >>> a6ed-555adfab3...@kernel.crashing.org> you wrote: > > > Allocate more space for U-Boot? > > I might turn of BEDBUG as its never been properly enabled on > e500/85xx > platforms. > >>> > >>> Is there any problem with the bigger image which I don't > understand > >>> yet? Normally we just move down the TEXT_BASE by a sector, > >> and that's > >>> it. > >> > >> Not specifically, its just that ever 85xx image to date has been > >> 512k. I'm just trying to avoid this being the first one that > >> changes > >> that historic fact. Especially since compilers like > gcc-4.3 seem to > >> be able to fit the size in 512k. > > We may have more requirements to support graphic in u-boot. > > Sooner and later, the size will exceed 512K. Should we have > some plan > > for this? > > So if we are going to increase the limit from 512k do we go > to 768k or > 1M? (Sector size on the board appears to 128k) If there is no special reason, I'd like to expand it to 768K. But my concern here is that it is better to limit 8536DS image to 512K. For SD/NAND boot code, the u-boot will be copy to L2 cache. It is only 512K. > > I would also like to know how big the flashes are on some of > the other > 85xx boards that u-boot supports. >From 8540ads board, at lease we may have 4M flash to use considering the swap. Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how big is the NOR flash on 85xx boards?
Dear Kumar Gala, In message you wrote: > I was wondering if we can see how big the NOR flash is on the XES & > TQM boards. Including the old MPC8xx? They usually have 4 or 8 MB NOR. Anything else usually has 32...128 MB. If I remember correctly, there are configurations of the TQM8548 with 4 GB NOR flash - no kidding. Why do you ask? 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 Do you suppose the reason the ends of the `Intel Inside' logo don't match up is that it was drawn on a Pentium? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Sat 8 Aug 2009 05:50, Ben Warren pondered: > Allesandro, > > Alessandro Rubini wrote: > > I finally fixed the defrag code, testing with NFS as well. > > Didn't take performance figures, tough, for lack of time. Checking out performance with tftp - server is Linux 2.6.27 located in Germany, client (U-Boot running net/next) is located in the USA. Packets fragmented, and arriving out of order. U-Boot image (214268 bytes) tftpblocksize download rate (bytes) (ms) (bytes/second) 512 48,246 4,441 1024 24,482 8,752 1468 ( 1MTU) 17,24312,426 2048 12,51717,118 2948 ( 2MTU) 8,91224,042 4428 ( 3MTU) 6,16734,744 4096 6,60832,425 5908 ( 4MTU) 4,84044,270 7388 ( 5MTU) 4,04253,010 8192 3,64158,848 8868 ( 6MTU) 3,42562,560 10348 ( 7MTU) 2,97472,047 11828 ( 8MTU) 2,73678,314 13308 ( 9MTU) 2,50885,433 14788 (10MTU) 2,28193,935 16000 2,23395,955 16268 (11MTU) 2,17498,559 So, that is 17-seconds (default - on the master), to 2 seconds. Wow - a 87% reduction! Doing the same with a larger image (default kernel + ext2 file system == 12Meg), gets similar results - goes from 928,688 ms / 12,493 bytes/second (yeah, that is 15 minutes with a tftpblocksize == 1468) to 107,626 ms / 107,866 bytes/second (that is under two minutes with a tftpblocksize == 16000)... Again - an 88% reduction in time spent waiting... So - I think this is well worth the effort for those people who want to use tftp outside of a local network. (on a local network - things do not change that drastically - An 18Meg file with default tftpblocksize (1468 bytes) took 5084ms to download, and with a tftpblocksize of 16268, it about half the time - 2625 ms... Thanks to Alessandro for putting it together. Feel free to add my Signed-off (once the docs have been updated explaining what this is all for). -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix E1000 build warning on AP1000 board
From: Roy Zang
Fix E1000 build warning on AP1000 board
Fix the build warning on AP1000 board:
e1000.c:131: warning: 'e1000_read_eeprom' used but never defined
e1000.c:2012: warning: 'e1000_set_phy_mode' defined but not used
Signed-off-by: Roy Zang
---
drivers/net/e1000.c | 88 +-
1 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index e3c6cea..83a 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -126,9 +126,6 @@ static int e1000_write_phy_reg(struct e1000_hw *hw,
uint32_t reg_addr,
static int32_t e1000_phy_hw_reset(struct e1000_hw *hw);
static int e1000_phy_reset(struct e1000_hw *hw);
static int e1000_detect_gig_phy(struct e1000_hw *hw);
-static int32_t e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
- uint16_t words,
- uint16_t *data);
static void e1000_put_hw_eeprom_semaphore(struct e1000_hw *hw);
static void e1000_set_media_type(struct e1000_hw *hw);
@@ -143,6 +140,9 @@ static int32_t e1000_check_phy_reset_block(struct e1000_hw
*hw);
#define E1000_WRITE_FLUSH(a) {uint32_t x; x = E1000_READ_REG(a, STATUS);}
#ifndef CONFIG_AP1000 /* remove for warnings */
+static int32_t e1000_read_eeprom(struct e1000_hw *hw, uint16_t offset,
+ uint16_t words,
+ uint16_t *data);
/**
* Raises the EEPROM's clock input.
*
@@ -896,6 +896,47 @@ e1000_validate_eeprom_checksum(struct eth_device *nic)
return -E1000_ERR_EEPROM;
}
}
+
+/*
+ * Set PHY to class A mode
+ * Assumes the following operations will follow to enable the new class mode.
+ * 1. Do a PHY soft reset
+ * 2. Restart auto-negotiation or force link.
+ *
+ * hw - Struct containing variables accessed by shared code
+ /
+static int32_t
+e1000_set_phy_mode(struct e1000_hw *hw)
+{
+ int32_t ret_val;
+ uint16_t eeprom_data;
+
+ DEBUGFUNC();
+
+ if ((hw->mac_type == e1000_82545_rev_3) &&
+ (hw->media_type == e1000_media_type_copper)) {
+ ret_val = e1000_read_eeprom(hw, EEPROM_PHY_CLASS_WORD,
+ 1, &eeprom_data);
+ if (ret_val)
+ return ret_val;
+
+ if ((eeprom_data != EEPROM_RESERVED_WORD) &&
+ (eeprom_data & EEPROM_PHY_CLASS_A)) {
+ ret_val = e1000_write_phy_reg(hw,
+ M88E1000_PHY_PAGE_SELECT, 0x000B);
+ if (ret_val)
+ return ret_val;
+ ret_val = e1000_write_phy_reg(hw,
+ M88E1000_PHY_GEN_CONTROL, 0x8104);
+ if (ret_val)
+ return ret_val;
+
+ hw->phy_reset_disable = FALSE;
+ }
+ }
+
+ return E1000_SUCCESS;
+}
#endif /* #ifndef CONFIG_AP1000 */
/***
@@ -1999,47 +2040,6 @@ e1000_setup_fiber_link(struct eth_device *nic)
return 0;
}
-/*
- * Set PHY to class A mode
- * Assumes the following operations will follow to enable the new class mode.
- * 1. Do a PHY soft reset
- * 2. Restart auto-negotiation or force link.
- *
- * hw - Struct containing variables accessed by shared code
- /
-static int32_t
-e1000_set_phy_mode(struct e1000_hw *hw)
-{
- int32_t ret_val;
- uint16_t eeprom_data;
-
- DEBUGFUNC();
-
- if ((hw->mac_type == e1000_82545_rev_3) &&
- (hw->media_type == e1000_media_type_copper)) {
- ret_val = e1000_read_eeprom(hw, EEPROM_PHY_CLASS_WORD,
- 1, &eeprom_data);
- if (ret_val)
- return ret_val;
-
- if ((eeprom_data != EEPROM_RESERVED_WORD) &&
- (eeprom_data & EEPROM_PHY_CLASS_A)) {
- ret_val = e1000_write_phy_reg(hw,
- M88E1000_PHY_PAGE_SELECT, 0x000B);
- if (ret_val)
- return ret_val;
- ret_val = e1000_write_phy_reg(hw,
- M88E1000_PHY_GEN_CONTROL, 0x8104);
- if (ret_val)
- return ret_val;
-
- hw->phy_reset_disable = FALSE;
- }
- }
-
- return E1000_SUCCESS;
-}
-
/*
Re: [U-Boot] [PATCH 0/4] Network defrag
Robin Getz wrote: > On Sat 8 Aug 2009 05:50, Ben Warren pondered: > >> Allesandro, >> >> Alessandro Rubini wrote: >> >>> I finally fixed the defrag code, testing with NFS as well. >>> Didn't take performance figures, tough, for lack of time. >>> > > Checking out performance with tftp - server is Linux 2.6.27 located in > Germany, client (U-Boot running net/next) is located in the USA. Packets > fragmented, and arriving out of order. > > U-Boot image (214268 bytes) > > tftpblocksize download rate > (bytes) (ms) (bytes/second) >512 48,246 4,441 > 1024 24,482 8,752 > 1468 ( 1MTU) 17,24312,426 > 2048 12,51717,118 > 2948 ( 2MTU) 8,91224,042 > 4428 ( 3MTU) 6,16734,744 > 4096 6,60832,425 > 5908 ( 4MTU) 4,84044,270 > 7388 ( 5MTU) 4,04253,010 > 8192 3,64158,848 > 8868 ( 6MTU) 3,42562,560 > 10348 ( 7MTU) 2,97472,047 > 11828 ( 8MTU) 2,73678,314 > 13308 ( 9MTU) 2,50885,433 > 14788 (10MTU) 2,28193,935 > 16000 2,23395,955 > 16268 (11MTU) 2,17498,559 > > So, that is 17-seconds (default - on the master), to 2 seconds. Wow - a 87% > reduction! > > Wicked cool. > Doing the same with a larger image (default kernel + ext2 file system == > 12Meg), gets similar results - goes from 928,688 ms / 12,493 bytes/second > (yeah, that is 15 minutes with a tftpblocksize == 1468) to 107,626 ms / > 107,866 bytes/second (that is under two minutes with a tftpblocksize == > 16000)... Again - an 88% reduction in time spent waiting... > > So - I think this is well worth the effort for those people who want to use > tftp outside of a local network. (on a local network - things do not change > that drastically - An 18Meg file with default tftpblocksize (1468 bytes) took > 5084ms to download, and with a tftpblocksize of 16268, it about half the > time - 2625 ms... > > Thanks to Alessandro for putting it together. > > Feel free to add my Signed-off (once the docs have been updated explaining > what this is all for). > > I'll do that. Thanks for all your help. > -Robin > regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
Dear Robin Getz, In message <200908101551.52052.rg...@blackfin.uclinux.org> you wrote: > > Checking out performance with tftp - server is Linux 2.6.27 located in > Germany, client (U-Boot running net/next) is located in the USA. Packets > fragmented, and arriving out of order. ... > So, that is 17-seconds (default - on the master), to 2 seconds. Wow - a 87% > reduction! Thanks for testing & reporting! 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 Hi there! This is just a note from me, to you, to tell you, the per- son reading this note, that I can't think up any more famous quotes, jokes, nor bizarre stories, so you may as well go home. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote: > Kumar Gala wrote: > > On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote: > > > >> > >>> -Original Message- > >>> From: Kumar Gala [mailto:ga...@kernel.crashing.org] > >>> Sent: Monday, August 10, 2009 13:41 PM > >>> To: Wolfgang Denk > >>> Cc: U-Boot-Users ML; Zang Roy-R61911 > >>> Subject: Re: 85xx: MPC8536DS board does not build > >>> > >>> > >>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: > >>> > Dear Kumar Gala, > > In message <0EB7516A-2F14-42F7- > a6ed-555adfab3...@kernel.crashing.org> you wrote: > >> Allocate more space for U-Boot? > > I might turn of BEDBUG as its never been properly enabled on > > e500/85xx > > platforms. > Is there any problem with the bigger image which I don't understand > yet? Normally we just move down the TEXT_BASE by a sector, > >>> and that's > it. > >>> Not specifically, its just that ever 85xx image to date has been > >>> 512k. I'm just trying to avoid this being the first one that > >>> changes > >>> that historic fact. Especially since compilers like gcc-4.3 seem to > >>> be able to fit the size in 512k. > >> We may have more requirements to support graphic in u-boot. > >> Sooner and later, the size will exceed 512K. Should we have some plan > >> for this? > > > > So if we are going to increase the limit from 512k do we go to 768k or > > 1M? (Sector size on the board appears to 128k) > > > > I would also like to know how big the flashes are on some of the other > > 85xx boards that u-boot supports. > > > > - k > > Hi Kumar, Roy, > > 512K is pretty big for u-boot (not unheard of, but still...). Is it > really 512K or is it using a full page to hold the boot page (top 4K of > memory) and one page for the env (unavoidable): > > + 0x1__ > | One sector dedicated for the power up page (only using 4K) > + 0x0_F800_ > | One sector dedicated for the env > + 0x0_F000_ > | Two sectors of u-boot > + 0x0_E800_ > | > + 0x0_E000_ > > > If that is the case, you can gain a sector (less 4K) by rearranging your > memory map: > + 0x1__ > | One page (4K) of power up vector, the rest is u-boot > + 0x0_F800_ > | > + 0x0_F000_ > | Three sectors (less 4K) of u-boot > + 0x0_E800_ > | One sector dedicated for the env > + 0x0_E000_ > > This also makes reprogramming u-boot nicer because your power up vector > and u-boot itself are contiguous. Hi Jerry, Currently a sector shouldn't be wasted just for the 4K boot page. Your second diagram above is similar to current operation - a chunk of the 4k bootpage is wasted/unused, but other u-boot code shares the same flash sector with the 4K boot page. So a little space may be wasted, but not too much (ie less than 4K). Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how big is the NOR flash on 85xx boards?
On Aug 10, 2009, at 2:48 PM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message b134-92031a125...@kernel.crashing.org> you wrote: >> I was wondering if we can see how big the NOR flash is on the XES & >> TQM boards. > > Including the old MPC8xx? They usually have 4 or 8 MB NOR. > > Anything else usually has 32...128 MB. > > If I remember correctly, there are configurations of the TQM8548 with > 4 GB NOR flash - no kidding. > > Why do you ask? I'm asking this just see if we bump up in size if it should be to 768k or 1M. While this doesn't directly impact the TQM or XES boards I just wanted to get a sense of how much flash people are putting on boards today to see if 1M is a burden or in the noise w/regards to the size of things. My desire is if we support a different size on 8536DS that its a size other boards would be ok with if they needed to grow. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 3:00 PM, Peter Tyser wrote: > On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote: >> Kumar Gala wrote: >>> On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote: >>> > -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Monday, August 10, 2009 13:41 PM > To: Wolfgang Denk > Cc: U-Boot-Users ML; Zang Roy-R61911 > Subject: Re: 85xx: MPC8536DS board does not build > > > On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: > >> Dear Kumar Gala, >> >> In message <0EB7516A-2F14-42F7- >> a6ed-555adfab3...@kernel.crashing.org> you wrote: Allocate more space for U-Boot? >>> I might turn of BEDBUG as its never been properly enabled on >>> e500/85xx >>> platforms. >> Is there any problem with the bigger image which I don't >> understand >> yet? Normally we just move down the TEXT_BASE by a sector, > and that's >> it. > Not specifically, its just that ever 85xx image to date has been > 512k. I'm just trying to avoid this being the first one that > changes > that historic fact. Especially since compilers like gcc-4.3 > seem to > be able to fit the size in 512k. We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some plan for this? >>> >>> So if we are going to increase the limit from 512k do we go to >>> 768k or >>> 1M? (Sector size on the board appears to 128k) >>> >>> I would also like to know how big the flashes are on some of the >>> other >>> 85xx boards that u-boot supports. >>> >>> - k >> >> Hi Kumar, Roy, >> >> 512K is pretty big for u-boot (not unheard of, but still...). Is it >> really 512K or is it using a full page to hold the boot page (top >> 4K of >> memory) and one page for the env (unavoidable): >> >> + >> 0x1__ >> | One sector dedicated for the power up page (only using 4K) >> + >> 0x0_F800_ >> | One sector dedicated for the env >> + >> 0x0_F000_ >> | Two sectors of u-boot >> + >> 0x0_E800_ >> | >> + >> 0x0_E000_ >> >> >> If that is the case, you can gain a sector (less 4K) by rearranging >> your >> memory map: >> + >> 0x1__ >> | One page (4K) of power up vector, the rest is u-boot >> + >> 0x0_F800_ >> | >> + >> 0x0_F000_ >> | Three sectors (less 4K) of u-boot >> + >> 0x0_E800_ >> | One sector dedicated for the env >> + >> 0x0_E000_ >> >> This also makes reprogramming u-boot nicer because your power up >> vector >> and u-boot itself are contiguous. > > Hi Jerry, > Currently a sector shouldn't be wasted just for the 4K boot page. > Your > second diagram above is similar to current operation - a chunk of > the 4k > bootpage is wasted/unused, but other u-boot code shares the same flash > sector with the 4K boot page. So a little space may be wasted, but > not > too much (ie less than 4K). Here's a readelf dump for the MPC8536DS built w/gcc 4.3.2: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITSeff8 80 0596f0 00 AX 0 0 16 [ 2] .rodata PROGBITSeffd96f0 059770 00f158 00 A 0 0 4 [ 3] .relocPROGBITSeffe8900 068980 002d24 00 WA 0 0 4 [ 4] .data PROGBITSeffeb628 06b6a8 004d84 00 WA 0 0 8 [ 5] .data.rel.ro.loca PROGBITSefff03ac 07042c 3c 00 WA 0 0 4 [ 6] .data.rel PROGBITSefff03e8 070468 003378 00 WA 0 0 4 [ 7] .data.rel.local PROGBITSefff3760 0737e0 0016ac 00 WA 0 0 4 [ 8] .data.rel.ro PROGBITSefff4e0c 074e8c 20 00 WA 0 0 4 [ 9] .u_boot_cmd PROGBITSefff4e2c 074eac 000750 00 WA 0 0 4 [10] .bootpg PROGBITSe000 07f080 0001cc 00 AX 0 0 1 [11] .resetvec PROGBITSeffc 08007c 04 00 AX 0 0 1 We do waste a bit of space in the bootpg (~3.5k). Here's an idea on where space is being used: u-boot:053c T radeon_setmode_9200 u-boot:0568 T ft_cpu_setup u-boot:058c T compute_lowest_common_dimm_parameters u-boot:05ac t ehci_submit_async u
[U-Boot] [PATCH] Make TFTP Quiet
>From bca49fb5e3045bc175e924999a4015804c39c5c6 Mon Sep 17 00:00:00 2001
From: Robin Getz
I was using this when I was looking at some other recent tftp performance,
and thought I would share. I really don't think it belongs, as it is
(a) trivial and (b) mostly debug... (but I'm trying out some more things
with git).
This adds the ability to make tftp a little quieter, which saves some
time printing hash marks on the console. It also has the ability to
print some download stats for debugging network issues.
Signed-off-by: Robin Getz
---
net/tftp.c | 29 -
1 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 0fa7033..9544691 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -22,6 +22,16 @@
/* (for checking the image size)
*/
#define HASHES_PER_LINE65 /* Number of "loading" hashes
per line */
+#ifdef CONFIG_TFTP_QUIET
+#define puts_quiet(fmt)
+#else
+#define puts_quiet(fmt)puts(fmt);
+#endif
+
+#ifdef CONFIG_TFTP_TIME
+static ulong start_time, end_time;
+#endif
+
/*
* TFTP operations.
*/
@@ -340,9 +350,9 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
printf ("\n\t %lu MB received\n\t ",
TftpBlockWrapOffset>>20);
} else {
if (((TftpBlock - 1) % 10) == 0) {
- putc ('#');
+ puts_quiet("#");
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) {
- puts ("\n\t ");
+ puts_quiet("\n\t ");
}
}
@@ -432,7 +442,12 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
* We received the whole thing. Try to
* run it.
*/
- puts ("\ndone\n");
+ puts_quiet("\ndone\n");
+#ifdef CONFIG_TFTP_TIME
+ end_time = get_timer(0);
+ printf("Time to download == %ld ms\n", end_time -
start_time);
+ printf("Download rate = %lld bytes/second\n", (long
long)(NetBootFileXferSize) * 1000 / (end_time - start_time));
+#endif
NetState = NETLOOP_SUCCESS;
}
break;
@@ -460,7 +475,7 @@ TftpTimeout (void)
#endif
NetStartAgain ();
} else {
- puts ("T ");
+ puts_quiet("T ");
NetSetTimeout (TftpTimeoutMSecs, TftpTimeout);
TftpSend ();
}
@@ -530,7 +545,11 @@ TftpStart (void)
printf ("Load address: 0x%lx\n", load_addr);
- puts ("Loading: *\b");
+ puts_quiet("Loading: *\b");
+
+#ifdef CONFIG_TFTP_TIME
+ start_time = get_timer(0);
+#endif
TftpTimeoutMSecs = TftpRRQTimeoutMSecs;
TftpTimeoutCountMax = TftpRRQTimeoutCountMax;
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make TFTP Quiet
On Mon, Aug 10, 2009 at 3:26 PM, Robin Getz wrote: > From bca49fb5e3045bc175e924999a4015804c39c5c6 Mon Sep 17 00:00:00 2001 > From: Robin Getz > > I was using this when I was looking at some other recent tftp performance, > and thought I would share. I really don't think it belongs, as it is > (a) trivial and (b) mostly debug... (but I'm trying out some more things > with git). > > This adds the ability to make tftp a little quieter, which saves some > time printing hash marks on the console. It also has the ability to > print some download stats for debugging network issues. > > Signed-off-by: Robin Getz > > --- > net/tftp.c | 29 - > 1 files changed, 24 insertions(+), 5 deletions(-) > > diff --git a/net/tftp.c b/net/tftp.c > index 0fa7033..9544691 100644 > --- a/net/tftp.c > +++ b/net/tftp.c > @@ -22,6 +22,16 @@ > /* (for checking the image size) > */ > #define HASHES_PER_LINE 65 /* Number of "loading" hashes > per line */ > > +#ifdef CONFIG_TFTP_QUIET > +#define puts_quiet(fmt) > +#else > +#define puts_quiet(fmt) puts(fmt); > +#endif This looks backwards to me. I would do this: #ifdef CONFIG_TFTP_QUIET #define puts(x) puts_quiet(x) #endif That way, you don't need to change all of the puts calls to puts_quiet. Plus, having the normal calls be "puts_quiet" that changes to puts when QUIET is *not* enabled just feels wrong. -- 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] 85xx: MPC8536DS board does not build
On Mon, 10 Aug 2009, Kumar Gala wrote: > > On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: > > > Dear Kumar Gala, > > > > In message <0EB7516A-2F14-42F7- > > a6ed-555adfab3...@kernel.crashing.org> you wrote: > >> > >>> Allocate more space for U-Boot? > >> > >> I might turn of BEDBUG as its never been properly enabled on > >> e500/85xx > >> platforms. > > > > Is there any problem with the bigger image which I don't understand > > yet? Normally we just move down the TEXT_BASE by a sector, and that's > > it. > > Not specifically, its just that ever 85xx image to date has been > 512k. I'm just trying to avoid this being the first one that changes > that historic fact. Especially since compilers like gcc-4.3 seem to > be able to fit the size in 512k. Off of 512K something like 1/3 is empty in e.g. MPC8548CDS. The very last sector contains fixed location power-on boot vector, the beginning of those 512K has actual U-Boot code and the hole between them is big enough to fit an entire sector for environment. --- ** * k...@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how big is the NOR flash on 85xx boards?
Dear Kumar Gala, In message <07da25c3-1f4f-431e-bf8a-61c11cd41...@kernel.crashing.org> you wrote: > > I'm asking this just see if we bump up in size if it should be to 768k > or 1M. While this doesn't directly impact the TQM or XES boards I > just wanted to get a sense of how much flash people are putting on > boards today to see if 1M is a burden or in the noise w/regards to the > size of things. So far we have many systems that are well below 256 kB. 512 kB al- ready seems to a a LOT for just a boot loader. Yes, features like UBI and graphics support cost a price, but these are still non-standard, right? > My desire is if we support a different size on 8536DS that its a size > other boards would be ok with if they needed to grow. I think this is only a Freescale internal issue. 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 Inside every old person is a young person wondering what happened. - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 85xx: MPC8536DS board does not build
On Mon, 10 Aug 2009, Peter Tyser wrote: > On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote: > > Kumar Gala wrote: > > > On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote: > > > > > >> > > >>> -Original Message- > > >>> From: Kumar Gala [mailto:ga...@kernel.crashing.org] > > >>> Sent: Monday, August 10, 2009 13:41 PM > > >>> To: Wolfgang Denk > > >>> Cc: U-Boot-Users ML; Zang Roy-R61911 > > >>> Subject: Re: 85xx: MPC8536DS board does not build > > >>> > > >>> > > >>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote: > > >>> > > Dear Kumar Gala, > > > > In message <0EB7516A-2F14-42F7- > > a6ed-555adfab3...@kernel.crashing.org> you wrote: > > >> Allocate more space for U-Boot? > > > I might turn of BEDBUG as its never been properly enabled on > > > e500/85xx > > > platforms. > > Is there any problem with the bigger image which I don't > understand > > yet? Normally we just move down the TEXT_BASE by a sector, > > >>> and that's > > it. > > >>> Not specifically, its just that ever 85xx image to date has been > > >>> 512k. I'm just trying to avoid this being the first one that > > >>> changes > > >>> that historic fact. Especially since compilers like gcc-4.3 seem > to > > >>> be able to fit the size in 512k. > > >> We may have more requirements to support graphic in u-boot. > > >> Sooner and later, the size will exceed 512K. Should we have some > plan > > >> for this? > > > > > > So if we are going to increase the limit from 512k do we go to 768k > or > > > 1M? (Sector size on the board appears to 128k) > > > > > > I would also like to know how big the flashes are on some of the > other > > > 85xx boards that u-boot supports. > > > > > > - k > > > > Hi Kumar, Roy, > > > > 512K is pretty big for u-boot (not unheard of, but still...). Is it > > really 512K or is it using a full page to hold the boot page (top 4K > of > > memory) and one page for the env (unavoidable): > > > > + > 0x1__ > > | One sector dedicated for the power up page (only using 4K) > > + > 0x0_F800_ > > | One sector dedicated for the env > > + > 0x0_F000_ > > | Two sectors of u-boot > > + > 0x0_E800_ > > | > > + > 0x0_E000_ > > > > > > If that is the case, you can gain a sector (less 4K) by rearranging > your > > memory map: > > + > 0x1__ > > | One page (4K) of power up vector, the rest is u-boot > > + > 0x0_F800_ > > | > > + > 0x0_F000_ > > | Three sectors (less 4K) of u-boot > > + > 0x0_E800_ > > | One sector dedicated for the env > > + > 0x0_E000_ > > > > This also makes reprogramming u-boot nicer because your power up > vector > > and u-boot itself are contiguous. > > Hi Jerry, > Currently a sector shouldn't be wasted just for the 4K boot page. Your > second diagram above is similar to current operation - a chunk of the 4k > bootpage is wasted/unused, but other u-boot code shares the same flash > sector with the 4K boot page. So a little space may be wasted, but not > too much (ie less than 4K). That is where top boot block flashes come handy... It is not just that 128K sector is a huge waste for 4K boot block, the same is true for environment... --- ** * k...@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how big is the NOR flash on 85xx boards?
On Aug 10, 2009, at 4:25 PM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <07DA25C3-1F4F-431E- > bf8a-61c11cd41...@kernel.crashing.org> you wrote: >> >> I'm asking this just see if we bump up in size if it should be to >> 768k >> or 1M. While this doesn't directly impact the TQM or XES boards I >> just wanted to get a sense of how much flash people are putting on >> boards today to see if 1M is a burden or in the noise w/regards to >> the >> size of things. > > So far we have many systems that are well below 256 kB. 512 kB al- > ready seems to a a LOT for just a boot loader. Yes, features like UBI > and graphics support cost a price, but these are still non-standard, > right? > >> My desire is if we support a different size on 8536DS that its a size >> other boards would be ok with if they needed to grow. > > I think this is only a Freescale internal issue. And thus my desire is to just disable BEDBUG as its not something we really use and its anywhere near correct for e500. I'm not even sure how it got enabled. Its also a little weird in that its enabled based on having PCI enabled: #if defined(CONFIG_PCI) #define CONFIG_CMD_PCI #define CONFIG_CMD_BEDBUG #define CONFIG_CMD_NET #define CONFIG_CMD_SCSI #define CONFIG_CMD_EXT2 #endif - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 85xx: Removed BEDBUG support from FSL 85xx boards
For some reason the MPC8544 enabled BEDBUG if PCI was enabled and that got copied int the MPC8536, MPC8572 and P2020 DS boards. The BEDBUG support has never been made to work completely on e500/85xx so we just disable it to save space and match the other FSL 85xx boards. Signed-off-by: Kumar Gala --- include/configs/MPC8536DS.h |1 - include/configs/MPC8544DS.h |1 - include/configs/MPC8572DS.h |1 - include/configs/P2020DS.h |1 - 4 files changed, 0 insertions(+), 4 deletions(-) diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h index 0aaab4a..9d2b860 100644 --- a/include/configs/MPC8536DS.h +++ b/include/configs/MPC8536DS.h @@ -534,7 +534,6 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #if defined(CONFIG_PCI) #define CONFIG_CMD_PCI -#define CONFIG_CMD_BEDBUG #define CONFIG_CMD_NET #endif diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h index 2de3139..0caf456 100644 --- a/include/configs/MPC8544DS.h +++ b/include/configs/MPC8544DS.h @@ -433,7 +433,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #if defined(CONFIG_PCI) #define CONFIG_CMD_PCI -#define CONFIG_CMD_BEDBUG #define CONFIG_CMD_NET #define CONFIG_CMD_SCSI #define CONFIG_CMD_EXT2 diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index 64f5c4b..d0933ba 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -585,7 +585,6 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #if defined(CONFIG_PCI) #define CONFIG_CMD_PCI -#define CONFIG_CMD_BEDBUG #define CONFIG_CMD_NET #define CONFIG_CMD_SCSI #define CONFIG_CMD_EXT2 diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h index 5c2c5cb..ad24e0c 100644 --- a/include/configs/P2020DS.h +++ b/include/configs/P2020DS.h @@ -614,7 +614,6 @@ extern unsigned long calculate_board_ddr_clk(unsigned long dummy); #if defined(CONFIG_PCI) #define CONFIG_CMD_PCI -#define CONFIG_CMD_BEDBUG #define CONFIG_CMD_NET #define CONFIG_CMD_SCSI #define CONFIG_CMD_EXT2 -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx - master branch
The following changes since commit eb1a4d0a471505c169bef19a73a60f8641f0b875: Wolfgang Denk (1): Prepare 2009.08-rc2 are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kumar Gala (1): 85xx: Removed BEDBUG support from FSL 85xx boards include/configs/MPC8536DS.h |1 - include/configs/MPC8544DS.h |1 - include/configs/MPC8572DS.h |1 - include/configs/P2020DS.h |1 - 4 files changed, 0 insertions(+), 4 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] arm: A320: driver for FTMAC100 ethernet controller
Hello Po-Yu, ratbert.chu...@gmail.com wrote: > From: Po-Yu Chuang > > This patch adds an FTMAC100 ethernet driver for Faraday A320 evaluation board. > > Signed-off-by: Po-Yu Chuang > --- Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/tftp.c: fix warning: pointer targets differ in signedness
Wolfgang,
Wolfgang Denk wrote:
> tftp.c:294: warning: pointer targets in passing argument 1 of 'strlen'
> differ in signedness
>
> This was only visible for the utx8245 board which seems to have DEBUG
> enabled.
>
> Signed-off-by: Wolfgang Denk
> ---
> net/tftp.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/net/tftp.c b/net/tftp.c
> index 74d9e42..fb98a34 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -291,7 +291,9 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
> unsigned len)
> break;
>
> case TFTP_OACK:
> - debug("Got OACK: %s %s\n", pkt, pkt+strlen(pkt)+1);
> + debug("Got OACK: %s %s\n",
> + pkt,
> + pkt + strlen((char *)pkt) + 1);
> TftpState = STATE_OACK;
> TftpServerPort = src;
> /*
>
Applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: bugfixes: mv88E61xx compiler warnings fixed
Prafulla, Prafulla Wadaskar wrote: > 1. mv88E61xx driver compiler warnings fixed > 2. idstr if-else statements changed to switch() construct >and added default case too. >This fixed idstr may be uninitialized warning > > Signed-off-by: Prafulla Wadaskar > --- Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix E1000 build warning on AP1000 board
Roy, Roy Zang wrote: > From: Roy Zang > > Fix E1000 build warning on AP1000 board > Fix the build warning on AP1000 board: > e1000.c:131: warning: 'e1000_read_eeprom' used but never defined > e1000.c:2012: warning: 'e1000_set_phy_mode' defined but not used > > Signed-off-by: Roy Zang > --- Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request - net
Wolfgang, The following changes since commit eb1a4d0a471505c169bef19a73a60f8641f0b875: Wolfgang Denk (1): Prepare 2009.08-rc2 are available in the git repository at: git://git.denx.de/u-boot-net.git master Po-Yu Chuang (1): arm: A320: driver for FTMAC100 ethernet controller Prafulla Wadaskar (2): net: phy: bugfixes: mv88E61xx compiler warnings fixed net: kirkwood: updates: used eth_setenv_enetaddr api Roy Zang (1): Fix E1000 build warning on AP1000 board Sandeep Paulraj (1): ARM: Davinci DM355: Enabling DM9000 on DM355 EVM board/davinci/dm355evm/dm355evm.c | 10 ++- drivers/net/Makefile |1 + drivers/net/e1000.c | 88 ++-- drivers/net/ftmac100.c| 278 + drivers/net/ftmac100.h| 154 drivers/net/kirkwood_egiga.c | 15 ++- drivers/net/phy/mv88e61xx.c | 23 ++-- include/netdev.h |1 + 8 files changed, 510 insertions(+), 60 deletions(-) create mode 100644 drivers/net/ftmac100.c create mode 100644 drivers/net/ftmac100.h regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Davinci DM355: Enabling DM9000 on DM355 EVM
Sandeep, s-paul...@ti.com wrote: > From: Sandeep Paulraj > > Due to recent changes to the NET support on U-boot, DM9000 > is no longer detected on the DM355 EVM. > This minor update enables DM9000 on the DM355 EVM. > Tested on the DM355 EVM > > Signed-off-by: Sandeep Paulraj > --- applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
This patch adds support for i.MX27-LITEKIT development board from LogicPD. This board uses i.MX27 SoC and has 2MB NOR flash, 64MB NAND flash, FEC ethernet controller integrated into i.MX27. Signed-off-by: Ilya Yanok --- MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/logicpd/imx27lite/Makefile| 51 ++ board/logicpd/imx27lite/config.mk |1 + board/logicpd/imx27lite/imx27lite.c | 73 + board/logicpd/imx27lite/lowlevel_init.S | 170 + cpu/arm926ejs/mx27/generic.c| 65 include/asm-arm/arch-mx27/imx-regs.h| 12 ++ include/configs/imx27lite.h | 252 +++ 10 files changed, 629 insertions(+), 0 deletions(-) create mode 100644 board/logicpd/imx27lite/Makefile create mode 100644 board/logicpd/imx27lite/config.mk create mode 100644 board/logicpd/imx27lite/imx27lite.c create mode 100644 board/logicpd/imx27lite/lowlevel_init.S create mode 100644 include/configs/imx27lite.h diff --git a/MAINTAINERS b/MAINTAINERS index 620604c..60185ab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -539,6 +539,7 @@ George G. Davis gcplus SA1100 Wolfgang Denk + imx27lite i.MX27 qongi.MX31 Thomas Elste diff --git a/MAKEALL b/MAKEALL index edebaea..3b0fd56 100755 --- a/MAKEALL +++ b/MAKEALL @@ -515,6 +515,7 @@ LIST_ARM9=" \ cp926ejs\ cp946es \ cp966 \ + imx27lite \ lpd7a400\ mv88f6281gtw_ge \ mx1ads \ diff --git a/Makefile b/Makefile index 329e0f5..c0f30d1 100644 --- a/Makefile +++ b/Makefile @@ -2879,6 +2879,9 @@ davinci_sonata_config : unconfig davinci_dm355evm_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs dm355evm davinci davinci +imx27lite_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 + lpd7a400_config \ lpd7a404_config: unconfig @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x diff --git a/board/logicpd/imx27lite/Makefile b/board/logicpd/imx27lite/Makefile new file mode 100644 index 000..c404cef --- /dev/null +++ b/board/logicpd/imx27lite/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2004 +# 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 +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := imx27lite.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# + diff --git a/board/logicpd/imx27lite/config.mk b/board/logicpd/imx27lite/config.mk new file mode 100644 index 000..a2e7768 --- /dev/null +++ b/board/logicpd/imx27lite/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0xA7F0 diff --git a/board/logicpd/imx27lite/imx27lite.c b/board/logicpd/imx27lite/imx27lite.c new file mode 100644 index 000..63375d5 --- /dev/null +++ b/board/logicpd/imx27lite/imx27lite.c @@ -0,0 +1,73 @@ +/* + * Copyright (C) 2007 Sascha Hauer, Pengutronix + * Copyright (C) 2008,2009 Eric Jarrige + * Copyright (C) 2009 Ilya Yanok + * + * 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. Se
[U-Boot] [PATCH] mxc_nand: add nand driver for MX2/MX3
Driver for NFC NAND controller found on Freescale's MX2 and MX3
processors. Ported from Linux. Tested only with i.MX27 but should
works with other MX2 and MX3 processors too.
Signed-off-by: Ilya Yanok
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/mxc_nand.c | 880 +++
2 files changed, 881 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/mxc_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 89ccec2..ea8572f 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
COBJS-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
COBJS-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
COBJS-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o
+COBJS-$(CONFIG_NAND_MXC) += mxc_nand.o
COBJS-$(CONFIG_NAND_NDFC) += ndfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
new file mode 100644
index 000..647be0b
--- /dev/null
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -0,0 +1,880 @@
+/*
+ * Copyright 2004-2007 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2008 Sascha Hauer, ker...@pengutronix.de
+ * Copyright 2009 Ilya Yanok,
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include
+#include
+#include
+#include
+#ifdef CONFIG_MX27
+#include
+#endif
+
+#define DRIVER_NAME "mxc_nand"
+
+struct nfc_regs {
+/* NFC RAM BUFFER Main area 0 */
+ uint8_t main_area0[0x200];
+ uint8_t main_area1[0x200];
+ uint8_t main_area2[0x200];
+ uint8_t main_area3[0x200];
+/* SPARE BUFFER Spare area 0 */
+ uint8_t spare_area0[0x10];
+ uint8_t spare_area1[0x10];
+ uint8_t spare_area2[0x10];
+ uint8_t spare_area3[0x10];
+ uint8_t pad[0x5c0];
+/* NFC registers */
+ uint16_t nfc_buf_size;
+ uint16_t reserved;
+ uint16_t nfc_buf_addr;
+ uint16_t nfc_flash_addr;
+ uint16_t nfc_flash_cmd;
+ uint16_t nfc_config;
+ uint16_t nfc_ecc_status_result;
+ uint16_t nfc_rsltmain_area;
+ uint16_t nfc_rsltspare_area;
+ uint16_t nfc_wrprot;
+ uint16_t nfc_unlockstart_blkaddr;
+ uint16_t nfc_unlockend_blkaddr;
+ uint16_t nfc_nf_wrprst;
+ uint16_t nfc_config1;
+ uint16_t nfc_config2;
+};
+
+/*
+ * Set INT to 0, FCMD to 1, rest to 0 in NFC_CONFIG2 Register
+ * for Command operation
+ */
+#define NFC_CMD0x1
+
+/*
+ * Set INT to 0, FADD to 1, rest to 0 in NFC_CONFIG2 Register
+ * for Address operation
+ */
+#define NFC_ADDR 0x2
+
+/*
+ * Set INT to 0, FDI to 1, rest to 0 in NFC_CONFIG2 Register
+ * for Input operation
+ */
+#define NFC_INPUT 0x4
+
+/*
+ * Set INT to 0, FDO to 001, rest to 0 in NFC_CONFIG2 Register
+ * for Data Output operation
+ */
+#define NFC_OUTPUT 0x8
+
+/*
+ * Set INT to 0, FD0 to 010, rest to 0 in NFC_CONFIG2 Register
+ * for Read ID operation
+ */
+#define NFC_ID 0x10
+
+/*
+ * Set INT to 0, FDO to 100, rest to 0 in NFC_CONFIG2 Register
+ * for Read Status operation
+ */
+#define NFC_STATUS 0x20
+
+/*
+ * Set INT to 1, rest to 0 in NFC_CONFIG2 Register for Read
+ * Status operation
+ */
+#define NFC_INT0x8000
+
+#define NFC_SP_EN (1 << 2)
+#define NFC_ECC_EN (1 << 3)
+#define NFC_BIG (1 << 5)
+#define NFC_RST (1 << 6)
+#define NFC_CE (1 << 7)
+#define NFC_ONE_CYCLE (1 << 8)
+
+typedef enum {false, true} bool;
+
+struct mxc_nand_host {
+ struct mtd_info mtd;
+ struct nand_chip*nand;
+
+ struct nfc_regs __iomem *regs;
+ int spare_only;
+ int status_request;
+ int pagesize_2k;
+ int clk_act;
+ uint16_tcol_addr;
+};
+
+static struct mxc_nand_host mxc_host;
+static struct mxc_nand_host *host = &mxc_host;
+
+/* Define delays in microsec for NAND device operations */
+#define TROP_US_DELAY 2000
+/* Macros to get byte and bit positions of ECC */
+#define COLPOS(x) ((x) >> 3)
+#define BITPOS(x) ((x) & 0xf)
+
+/* Define single bit Error positions in Main &
Re: [U-Boot] [PATCH v2] net: kirkwood: updates: used eth_setenv_enetaddr api
Prafulla, Prafulla Wadaskar wrote: > eth_setenv_enetaddr is avaible by upper layer > using this saves 204 bytes on total image size > > used Local OUI instead of Marvell OUI for > random MAC address generation logic > > Signed-off-by: Prafulla Wadaskar > --- Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Ping on u-boot patch status
Hi Richard, Sorry, thought I'd taken care of these. Richard Retanubun wrote: > Hi Ben, > > Just ping-ing the status of these patches to u-boot. > If I have sent them badly, please let me know and I can repost. > > > 1. 83xx: UEC: Added support for bitBang MII driver access to PHYs > > http://www.mail-archive.com/u-boot@lists.denx.de/msg16588.html > >> I am aware of peter tyser's comment and will /s CONFIG_MPC83XX with > CONFIG_MPC83xx << We shouldn't be adding more CPU-conditional logic to a common driver, so NAK. I'm pretty sure I commented on this one already. > > 2. UEC FIXED PHY: Determine fixed-phy port using UEC interface name > === > http://www.mail-archive.com/u-boot@lists.denx.de/msg16587.html > Applied to net repo after some manual tweaking and adding of SOB > 3. Assigned a static SMI address to all UECs TBIPA address > == > http://www.mail-archive.com/u-boot@lists.denx.de/msg16586.html > Applied to net repo after some manual tweaking and adding of SOB > > Thanks very much for your time > No problem. Sorry they didn't get in earlier. > - Richard regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make TFTP Quiet
On Mon, Aug 10, 2009 at 03:55:20PM -0500, Timur Tabi wrote: > > +#ifdef CONFIG_TFTP_QUIET > > +#define puts_quiet(fmt) > > +#else > > +#define puts_quiet(fmt) puts(fmt); > > +#endif > > This looks backwards to me. I would do this: > > #ifdef CONFIG_TFTP_QUIET > #define puts(x) puts_quiet(x) > #endif > > That way, you don't need to change all of the puts calls to > puts_quiet. Plus, having the normal calls be "puts_quiet" that > changes to puts when QUIET is *not* enabled just feels wrong. I think the point was to establish two different functions a caller may use -- puts() which always prints, and puts_quiet() which only prints when the user hasn't asked for silence. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make TFTP Quiet
On Mon 10 Aug 2009 16:55, Timur Tabi pondered:
> On Mon, Aug 10, 2009 at 3:26 PM, Robin Getz wrote:
> > --- a/net/tftp.c
> > +++ b/net/tftp.c
> > @@ -22,6 +22,16 @@
> > /* (for checking the image size)
> > */
> > #define HASHES_PER_LINE 65 /* Number of "loading"
> > hashes per line */
> >
> > +#ifdef CONFIG_TFTP_QUIET
> > +#define puts_quiet(fmt)
> > +#else
> > +#define puts_quiet(fmt) puts(fmt);
> > +#endif
>
> This looks backwards to me. I would do this:
>
> #ifdef CONFIG_TFTP_QUIET
> #define puts(x) puts_quiet(x)
> #endif
>
> That way, you don't need to change all of the puts calls to
> puts_quiet. Plus, having the normal calls be "puts_quiet" that
> changes to puts when QUIET is *not* enabled just feels wrong.
There are other puts that you don't want quiet...
puts ("Starting again\n\n");
puts ("\nRetry count exceeded; starting again\n");
Otherwise - if you have a bad network - it will never output anything...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: mkimage: Fixed build warnings
uninitialized retval variable warning fixed
crc32 api moved to crc.h(new) and build warnings fixed
Signed-off-by: Prafulla Wadaskar
---
include/common.h |4 +---
include/u-boot/crc.h | 33 +
tools/mkimage.c | 14 +++---
3 files changed, 41 insertions(+), 10 deletions(-)
create mode 100644 include/u-boot/crc.h
diff --git a/include/common.h b/include/common.h
index a6922fd..c0db3ff 100644
--- a/include/common.h
+++ b/include/common.h
@@ -622,9 +622,7 @@ int vsprintf(char *buf, const char *fmt, va_list args);
char * strmhz(char *buf, long hz);
/* lib_generic/crc32.c */
-uint32_t crc32 (uint32_t, const unsigned char *, uint);
-uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
-uint32_t crc32_no_comp (uint32_t, const unsigned char *, uint);
+#include
/* common/console.c */
intconsole_init_f(void); /* Before relocation; uses the serial stuff
*/
diff --git a/include/u-boot/crc.h b/include/u-boot/crc.h
new file mode 100644
index 000..61bce67
--- /dev/null
+++ b/include/u-boot/crc.h
@@ -0,0 +1,33 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor
+ * Written-by: Prafulla Wadaskar
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef _UBOOT_CRC_H
+#define _UBOOT_CRC_H
+
+/* lib_generic/crc32.c */
+uint32_t crc32 (uint32_t, const unsigned char *, uint);
+uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
+uint32_t crc32_no_comp (uint32_t, const unsigned char *, uint);
+
+#endif /* _UBOOT_CRC_H */
diff --git a/tools/mkimage.c b/tools/mkimage.c
index dc42924..33709b1 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -24,8 +24,8 @@
#include "mkimage.h"
#include
+#include
-extern unsigned long crc32 (unsigned long crc, const char *buf, unsigned int
len);
static voidcopy_file (int, const char *, int);
static voidusage (void);
static int image_verify_header (char *, int);
@@ -60,7 +60,7 @@ main (int argc, char **argv)
struct stat sbuf;
unsigned char *ptr;
char *name = "";
- int retval;
+ int retval = 0;
cmdname = *argv;
@@ -334,7 +334,7 @@ NXTARG: ;
hdr = (image_header_t *)ptr;
checksum = crc32 (0,
- (const char *)(ptr + image_get_header_size ()),
+ (const uint8_t *)(ptr + image_get_header_size ()),
sbuf.st_size - image_get_header_size ()
);
@@ -352,7 +352,7 @@ NXTARG: ;
image_set_name (hdr, name);
- checksum = crc32 (0, (const char *)hdr, image_get_header_size ());
+ checksum = crc32 (0, (const uint8_t *)hdr, image_get_header_size ());
image_set_hcrc (hdr, checksum);
@@ -485,7 +485,7 @@ static int
image_verify_header (char *ptr, int image_size)
{
int len;
- char *data;
+ uint8_t *data;
uint32_t checksum;
image_header_t header;
image_header_t *hdr = &header;
@@ -504,7 +504,7 @@ image_verify_header (char *ptr, int image_size)
return -FDT_ERR_BADMAGIC;
}
- data = (char *)hdr;
+ data = (uint8_t *)hdr;
len = sizeof(image_header_t);
checksum = be32_to_cpu(hdr->ih_hcrc);
@@ -517,7 +517,7 @@ image_verify_header (char *ptr, int image_size)
return -FDT_ERR_BADSTATE;
}
- data = ptr + sizeof(image_header_t);
+ data = (uint8_t *)ptr + sizeof(image_header_t);
len = image_size - sizeof(image_header_t) ;
if (crc32 (0, data, len) != be32_to_cpu(hdr->ih_dcrc)) {
--
1.5.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
