Re: [U-Boot-Users] i2c_reg_read() on 8xx
On Thu, Oct 23, 2008 at 1:49 AM, Wolfgang Denk [EMAIL PROTECTED] wrote:
That would mean to add even more #ifdef'ery to more common files - I
don;t think that this is a good odea.
I don't like #ifdefs in common code, either, but I think in this case
it's still an improvement. What do you think about this:
static inline u8 i2c_reg_read(u8 addr, u8 reg)
{
u8 buf;
#ifdef CONFIG_8xx
/* MPC8xx needs this. Maybe one day we can get rid of it. */
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
#endif
#ifdef DEBUG
printf(%s: addr=0x%02x, reg=0x%02x\n, __func__, addr, reg);
#endif
#ifdef CONFIG_BLACKFIN
/* This ifdef will become unneccessary in a future version of the
* blackfin I2C driver.
*/
i2c_read(addr, reg, 0, buf, 1);
#else
i2c_read(addr, reg, 1, buf, 1);
#endif
return buf;
}
--
Timur Tabi
Linux kernel developer at Freescale
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] i2c_reg_read() on 8xx
Wolfgang,
Mike Frysinger helped me resolve the problem with i2c_reg_read() on Blackfin, so
I'll be posting a new patch soon. However, I noticed that 8xx has a problem,
too:
uchar
i2c_reg_read(uchar i2c_addr, uchar reg)
{
uchar buf;
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
i2c_read(i2c_addr, reg, 1, buf, 1);
return (buf);
}
Is the call to i2c_init() necessary on 8xx boards? Shouldn't I2C have already
been initialized?
--
Timur Tabi
Linux kernel developer at Freescale
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] i2c_reg_read() on 8xx
Wolfgang Denk wrote: There are some 8xx boards where I2C is used very early so it might be necessary. I have to admit that I don't remember - that code is more than 6 years old. How early? Is there anyone with an 8xx board that can test this out for me? I2C is used for programming DDR on 8xxx boards, and that's pretty early, but 8xxx doesn't have this problem. It seems wrong that i2c_reg_read() needs to initialize I2C, but i2c_read() doesn't. I was going to CC: all the maintainers of 8xx boards, but they're too many of them. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] i2c_reg_read() on 8xx
Wolfgang Denk wrote: I guess there are other places where things like this are used. Some boards also come with a console over modem configuration which might use I2C very early, IIRC. I don't know much about 8xx, but on 8xxx, all the information needed for I2C configuration is in the board configuration files. Couldn't we just move i2c_init earlier? Is there a way to test on all the 8xx boards that U-Boot supports? If not, would it be okay to make a best-guess attempt at modifying the code to call i2c_init() earlier for those boards that need it (e.g. call it from scc_init() on the lwmon board), and hope someone else notices any bugs in other 8xx boards? -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] i2c_reg_read() on 8xx
Detlef Vollmann wrote: Very early. We have a board with the environment in EEPROM, and EEPROM at I2C. Which board is that? Do you use i2c_reg_read() to read EEPROM, or i2c_read()? -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Jon Smirl wrote: BTW, how do know which DT to dynamically interpret? If you are installing a universal uboot you still are going to have to install a different DT in each model. If you're installing a different DT you might as well install a different uboot. That's what I was thinking, too. Maybe on some boards, the DTB can be stored on some other type of memory that is easier to update during the manufacturing process. In that case, I can see how some vendors would like on u-boot.bin for all boards. Other than that, I don't see the point of having a generic u-boot.bin. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Why? One address is as good as any other. I think statistically you'll find that that isn't true. A built-in DTB is more likely to be present on the flash than an external DTB would be. Please present the data your statistics is based on. Give me a break, Wolfgang. I don't have any data, but what I'm saying makes sense. A system is more likely to have one binary blob present than two bloba. That has to be obvious. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk [EMAIL PROTECTED] wrote: If the DTB can be at any flash location, you can for example have a fall-back version which is used to bring up U-Boot in a minimal configuration for recovery mode if the new DTB fails to work. I think that a recovery DTB would have to be part of U-Boot itself to be effective. If the normal DTB is not available, then it's likely the backup one would also be unavailable. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely [EMAIL PROTECTED] wrote: Better to just not depend on the DTB at all for basic operation. ie. don't brick the board if the DTB is unavailable. Is it even possible to have a recovery mode U-Boot that is not tied to the specific board it's built for? Either U-Boot is reliable, or it's generic (i.e. uses the DTB for configuration). I just don't see how it can be both. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 12:32 PM, Scott Wood [EMAIL PROTECTED] wrote: I find a device tree much easier to figure out than a tangled mess of header files, #defines, and #ifdefs... Especially since the various config files 1) often define the CONFIG_ and CFG_ options is different order 2) are usually not designed to be flexible. That is, if you undefine a certain option, instead of handling it gracefully, U-Boot will just break. The device trees are heirarchal, organized, and well defined. I would not apply those attributes to the config files. Just the fact that we have CONFIG_ and CFG_ makes it too confusing. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 10:07 AM, Kumar Gala [EMAIL PROTECTED] wrote: One topic that come up during OLS in discussions and u-boot BOF was the idea of driving u-boot configuration from a device tree instead of from config.h. I was wondering if anyone has actually looked at doing this. What about creating a tool that parses a device tree and creates (or updates) the board header file? This will retain compatibility with other platforms, clean up the existing header files (they won't need to contain as much information), and reduce the amount of changes to U-Boot itself. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
Wolfgang Denk wrote: Which exact driver are you referring to? If any driver has such a bug, it should be fixed. drivers/i2c/fsl_i2c.c The function is i2c_init(). I recently posted a patch that added this line of code: i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); And this is what causes the problem. i2c_bus_speed[] is a global variable, and i2c_init() is called before relocation. Therefore, this function writes to flash the first time it's called. This is not the way to go. Hushing up problems has never been a solution. Instead, let's find and fix the culprit. I'm working on a patch that blocks i2c_init() from writing to global variables before relocation has occurred. But if you're saying that this patch should not be necessary, then that would be better. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
David Hawkins wrote: Whatever was written to i2c_bus_speed[0] was never actually written, since the write occurs to flash before relocation, so whatever the intent of the write was, needs to be fixed. Prior to relocation, the value of i2c_bus_speed[] is irrelevant. All that matter is that the I2C device is programmed for that speed. No code ever looks at i2c_bus_speed[] prior to relocation. Regardless, I'm testing a patch that prevents writes before relocation, so I'll be sending it out soon. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
Prevent i2c_init() in fsl_i2c.c from writing to the data segment before
relocation. Commit d8c82db4 added the ability for i2c_init() to program the
I2C bus speed and save the value in i2c_bus_speed[], which is a global
variable. It is an error to write to the data segment before relocation,
which is what i2c_init() does when it stores the bus speed in i2c_bus_speed[].
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Wolfgang, please apply this directly to fix the I2C bug we've been talking
about.
drivers/i2c/fsl_i2c.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 9f2c1ec..9d5df8a 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -143,12 +143,15 @@ void
i2c_init(int speed, int slaveadd)
{
struct fsl_i2c *dev;
+ unsigned int temp;
dev = (struct fsl_i2c *) (CFG_IMMR + CFG_I2C_OFFSET);
writeb(0, dev-cr);/* stop I2C controller */
udelay(5); /* let it shutdown in peace */
- i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed);
+ temp = set_i2c_bus_speed(dev, gd-i2c1_clk, speed);
+ if (gd-flags GD_FLG_RELOC)
+ i2c_bus_speed[0] = temp;
writeb(slaveadd 1, dev-adr); /* write slave address */
writeb(0x0, dev-sr); /* clear status register */
writeb(I2C_CR_MEN, dev-cr); /* start I2C controller */
@@ -158,7 +161,9 @@ i2c_init(int speed, int slaveadd)
writeb(0, dev-cr);/* stop I2C controller */
udelay(5); /* let it shutdown in peace */
- i2c_bus_speed[1] = set_i2c_bus_speed(dev, gd-i2c2_clk, speed);
+ temp = set_i2c_bus_speed(dev, gd-i2c2_clk, speed);
+ if (gd-flags GD_FLG_RELOC)
+ i2c_bus_speed[1] = temp;
writeb(slaveadd 1, dev-adr); /* write slave address */
writeb(0x0, dev-sr); /* clear status register */
writeb(I2C_CR_MEN, dev-cr); /* start I2C controller */
--
1.5.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
Jean-Christophe PLAGNIOL-VILLARD wrote: Maybe a macro will more clear like if(is_relacated()) i2c_bus_speed[0] = temp; I'm just following the same pattern as other code. The code if (gd-flags GD_FLG_RELOC) is used in a number of other places. Someone else can create that macro and update all the U-Boot code to use it, if he wants. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
David Hawkins wrote: Hi Timur, -i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); +temp = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); +if (gd-flags GD_FLG_RELOC) +i2c_bus_speed[0] = temp; Does i2c_init() get called again after relocation? Yes. I guess in some cases a board with fixed DDR would not need to initialize the I2C controller until after relocation. We're okay then, too. If you need I2C speed tracking code, why not just re-read the I2C controller registers, and determine the speed from there? That is independent of relocation. I suppose we could do that. I was planning on rewriting the I2C subsystem one day, anyway. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Update Freescale 85xx boards to sys_eeprom.c
The new sys_eeprom.c supports both the old CCID EEPROM format and the new NXID
format, and so it obsoletes board/freescale/common/cds_eeprom.c. Freescale
86xx boards already use sys_eeprom.c, so this patch migrates the remaining
Freescale 85xx boards to use it as well. cds_eeprom.c is deleted.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch was tested on an 8548CDS.
board/freescale/common/Makefile |1 -
board/freescale/common/cds_eeprom.c | 60 ---
include/configs/MPC8541CDS.h|9 -
include/configs/MPC8548CDS.h|9 -
include/configs/MPC8555CDS.h| 10 +-
5 files changed, 22 insertions(+), 67 deletions(-)
delete mode 100644 board/freescale/common/cds_eeprom.c
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 508e3b5..8e23b82 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -30,7 +30,6 @@ endif
LIB= $(obj)lib$(VENDOR).a
COBJS-${CONFIG_FSL_CADMUS} += cadmus.o
-COBJS-${CONFIG_FSL_CDS_EEPROM} += cds_eeprom.o
COBJS-${CONFIG_FSL_VIA}+= cds_via.o
COBJS-${CONFIG_FSL_DIU_FB} += fsl_diu_fb.o fsl_logo_bmp.o
COBJS-${CONFIG_FSL_PIXIS} += pixis.o
diff --git a/board/freescale/common/cds_eeprom.c
b/board/freescale/common/cds_eeprom.c
deleted file mode 100644
index 5034e0c..000
--- a/board/freescale/common/cds_eeprom.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright 2004 Freescale Semiconductor.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-
-#include common.h
-#include i2c.h
-
-#include eeprom.h
-
-
-typedef struct {
- char idee_pcbid[4]; /* CCID for CDC v1.X */
- u8 idee_major;
- u8 idee_minor;
- char idee_serial[10];
- char idee_errata[2];
- char idee_date[8]; /* mmdd */
- /* The rest of the EEPROM space is reserved */
-} id_eeprom_t;
-
-
-unsigned int
-get_cpu_board_revision(void)
-{
- uint major = 0;
- uint minor = 0;
-
- id_eeprom_t id_eeprom;
-
- i2c_read(CFG_I2C_EEPROM_ADDR, 0, 2,
-(uchar *) id_eeprom, sizeof(id_eeprom));
-
- major = id_eeprom.idee_major;
- minor = id_eeprom.idee_minor;
-
- if (major == 0xff minor == 0xff) {
- major = minor = 0;
- }
-
- return MPC85XX_CPU_BOARD_REV(major,minor);
-}
diff --git a/include/configs/MPC8541CDS.h b/include/configs/MPC8541CDS.h
index a64565d..f991360 100644
--- a/include/configs/MPC8541CDS.h
+++ b/include/configs/MPC8541CDS.h
@@ -50,7 +50,6 @@
#define CONFIG_FSL_LAW 1 /* Use common FSL init code */
#define CONFIG_FSL_VIA
-#define CONFIG_FSL_CDS_EEPROM
/*
* When initializing flash, if we cannot find the manufacturer ID,
@@ -324,11 +323,17 @@ extern unsigned long get_clock_freq(void);
#define CONFIG_HARD_I2C/* I2C with hardware support*/
#undef CONFIG_SOFT_I2C /* I2C bit-banged */
#define CFG_I2C_SPEED 40 /* I2C speed and slave address */
-#define CFG_I2C_EEPROM_ADDR0x57
#define CFG_I2C_SLAVE 0x7F
#define CFG_I2C_NOPROBES{0x69} /* Don't probe these addrs */
#define CFG_I2C_OFFSET 0x3000
+/* EEPROM */
+#define CONFIG_ID_EEPROM
+#define CFG_I2C_EEPROM_CCID
+#define CFG_ID_EEPROM
+#define CFG_I2C_EEPROM_ADDR 0x57
+#define CFG_I2C_EEPROM_ADDR_LEN 2
+
/*
* General PCI
* Memory space is mapped 1-1, but I/O space must start from 0.
diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h
index acf6f0d..b2007b6 100644
--- a/include/configs/MPC8548CDS.h
+++ b/include/configs/MPC8548CDS.h
@@ -58,7 +58,6 @@
#define CONFIG_FSL_LAW 1 /* Use common FSL init code */
#define CONFIG_FSL_VIA
-#define CONFIG_FSL_CDS_EEPROM
/*
* When initializing flash, if we cannot find the manufacturer ID,
@@ -349,11 +348,17 @@ extern unsigned long get_clock_freq(void);
#define CONFIG_HARD_I2C/* I2C with hardware support*/
#undef CONFIG_SOFT_I2C /* I2C bit-banged */
#define CFG_I2C_SPEED 40 /* I2C speed and slave address */
-#define CFG_I2C_EEPROM_ADDR0x57
#define
Re: [U-Boot-Users] Freescale MPC8349EMDS hang on boot
On Fri, Jul 18, 2008 at 8:52 PM, David Hawkins [EMAIL PROTECTED] wrote: FE00_9B90 is in the drivers/i2c/fsl_i2c.c code, which explains why Ira would see the 'I2C: ' line before lockup. Someone reported this problem last week while I was on vacation. The fix is to check if relocation has occurred, and only write the speed if it has. I guess I need to post a patch ASAP. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Update Freescale sys_eeprom.c to handle CCID formats
Jon, are you planning on picking this up? It is mostly an 86xx fix, since only 86xx uses sys_eeprom.c. Timur Tabi wrote: Timur Tabi wrote: Update the sys_eeprom.c file to handle both NXID and CCID EEPROM formats. The NXID format replaces the older CCID format, but it's important to support both since most boards out there still use the CCID format. This change is in preparation for using one file to handle both formats. This will also unify EEPROM support for all Freescale 85xx and 86xx boards. Also update the 86xx board header files to use the standard CFG_I2C_EEPROM_ADDR instead of ID_EEPROM_ADDR. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Jon, if you have no objections, would you please pick up this patch? -- Timur Tabi Linux kernel developer at Freescale - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Fix I2C for m547x/548x and m5445x processors.
On Jul 7, 2008, at 2:02 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: I just extended the fsl_i2c.c driver that already uses a precomputed Yes, I know. I never understood what such a complicated driver for sich a simple protocol was good for, especially as we don't do multimegabytepersecond transfers over such a bus. The driver is no more complicated than the hardware itself. The Freescale I2C controller has a complicated, screwball method for setting the I2C bus speed, and the driver tries to simplify that as much as possible. Setting the I2C bus speed *may* be important on some boards with flaky I2C devices. Accurate? There is no requirement to be accurate anywhere in the I2C protocol. Some devices cannot handle certain bus speeds, and some devices may work better at higher bus speeds, so it may be important to control the bus speed accurately. However, Luigi's patch is bad because it modifies a common file for a specific board. I'm going to NAK it. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Fix I2C for m547x/548x and m5445x processors.
On Jul 7, 2008, at 10:17 AM, Luigi 'Comio' Mantellini wrote:
---
drivers/i2c/fsl_i2c.c | 68
+
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 0690340..8fd73c0 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -78,6 +78,73 @@ static const struct fsl_i2c *i2c_dev[2] = {
* register. See the application note AN2919 Determining the I2C
Frequency
* Divider Ratio for SCL
*/
+#if defined(CONFIG_MCF547x_8x) || defined(CONFIG_MCF5445x)
+static const struct {
+ u8 fdr;
+ unsigned short divider;
+} fsl_i2c_speed_map[] = {
+ {.fdr=0x20, .divider= 20}, {.fdr=0x21, .divider= 22},
{.fdr=0x22, .divider= 24},
+ {.fdr=0x23, .divider= 26}, {.fdr=0x00, .divider= 28},
{.fdr=0x24, .divider= 28},
+ {.fdr=0x01, .divider= 30}, {.fdr=0x25, .divider= 32},
{.fdr=0x02, .divider= 34},
+ {.fdr=0x26, .divider= 36}, {.fdr=0x03, .divider= 40},
{.fdr=0x27, .divider= 40},
+ {.fdr=0x04, .divider= 44}, {.fdr=0x05, .divider= 48}, /
*{.fdr=0x28, .divider= 48},*/
+ {.fdr=0x06, .divider= 56}, /*{.fdr=0x29, .divider= 56},*/
{.fdr=0x2A, .divider= 64},
+ {.fdr=0x07, .divider= 68}, {.fdr=0x2B, .divider= 72},
{.fdr=0x08, .divider= 80},
+ /*{.fdr=0x2C, .divider= 80},*/ {.fdr=0x09, .divider= 88},
{.fdr=0x2D, .divider= 96},
+ {.fdr=0x0A, .divider= 104}, {.fdr=0x2E, .divider= 112},
{.fdr=0x0B, .divider= 128},
+ /*{.fdr=0x2F, .divider= 128},*/ {.fdr=0x0C, .divider= 144},
{.fdr=0x0D, .divider= 160},
+ /*{.fdr=0x30, .divider= 160},*/ {.fdr=0x0E, .divider= 192}, /
*{.fdr=0x31, .divider= 192},*/
+ {.fdr=0x32, .divider= 224}, {.fdr=0x0F, .divider= 240},
{.fdr=0x33, .divider= 256},
+ {.fdr=0x10, .divider= 288}, {.fdr=0x11, .divider= 320}, /
*{.fdr=0x34, .divider= 320},*/
+ {.fdr=0x12, .divider= 384}, /*{.fdr=0x35, .divider= 384},*/
{.fdr=0x36, .divider= 448},
+ /*{.fdr=0x13, .divider= 480},*/ {.fdr=0x37, .divider= 512},
{.fdr=0x14, .divider= 576},
+ {.fdr=0x15, .divider= 640}, /*{.fdr=0x38, .divider= 640},*/
{.fdr=0x16, .divider= 768},
+ /*{.fdr=0x39, .divider= 768},*/ {.fdr=0x3A, .divider= 896},
{.fdr=0x17, .divider= 960},
+ {.fdr=0x3B, .divider=1024}, {.fdr=0x18, .divider=1152},
{.fdr=0x19, .divider=1280},
+ /*{.fdr=0x3C, .divider=1280},*/ {.fdr=0x1A, .divider=1536}, /
*{.fdr=0x3D, .divider=1536},*/
+ {.fdr=0x3E, .divider=1792}, {.fdr=0x1B, .divider=1920},
{.fdr=0x3F, .divider=2048},
+ {.fdr=0x1C, .divider=2304}, {.fdr=0x1D, .divider=2560},
{.fdr=0x1E, .divider=3072},
+ {.fdr=0x1F, .divider=3840}, {.fdr=0x00, .divider=-1}
+};
NAK. There's a better way to do this. Don't just copy/paste my data
structures and comment-out specific fields like this.
I'm on vacation this week. Next week, I'll take a closer look at your
patch and suggest something better.
What is the reason you are commenting-out those specific entries in
fsl_i2c_speed_map[]?
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Unable to boot linux 2.6.25 with U-Boot 1.1.4
rohit h wrote: Hello everyone. I have got a modified u-boot source which boots vanilla 2.6.22 kernel, but is unable to boot vanilla 2.6.25. 1.1.4 is too old to boot such a modern kernel. -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Update Freescale sys_eeprom.c to handle CCID formats
Timur Tabi wrote: Update the sys_eeprom.c file to handle both NXID and CCID EEPROM formats. The NXID format replaces the older CCID format, but it's important to support both since most boards out there still use the CCID format. This change is in preparation for using one file to handle both formats. This will also unify EEPROM support for all Freescale 85xx and 86xx boards. Also update the 86xx board header files to use the standard CFG_I2C_EEPROM_ADDR instead of ID_EEPROM_ADDR. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Jon, if you have no objections, would you please pick up this patch? -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Update Freescale sys_eeprom.c to handle CCID formats
Ben Warren wrote: So are you saying that the plan is to move much of the configuration information from NOR flash to I2C EEPROMs on Freescale evaluation boards? No. The plan is to better support does boards that *do* have MAC addresses in EEPROM. (Actually, I have no idea what the board designers are planning on doing in the future. I just know what doesn't work today). One of the problems is that the CRC value in the EEPROM is not programmed during manufacturing, but the current version of the code will refuse to read MAC addresses if the CRC doesn't match. So out of the box, the BSPs never use the EEPROM for anything. The user has to rewrite the EEPROM. I'm not suggesting that it's a good or bad idea, but just keep in mind that the main raison d'etre for these boards is to serve as starting points for customer designs, and I'm not sure the majority of customers would use things this way. True, but it would be nice if the code worked properly. :-) -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Update Freescale sys_eeprom.c to handle CCID formats
Robert Schwebel wrote: Hi, On Fri, Jun 20, 2008 at 09:59:03AM -0500, Timur Tabi wrote: Update the sys_eeprom.c file to handle both NXID and CCID EEPROM formats. The NXID format replaces the older CCID format, but it's important to support both since most boards out there still use the CCID format. This change is in preparation for using one file to handle both formats. This will also unify EEPROM support for all Freescale 85xx and 86xx boards. Also update the 86xx board header files to use the standard CFG_I2C_EEPROM_ADDR instead of ID_EEPROM_ADDR. I don't know what NXID and CCID is, but have you seen Wolfram's proposal for sub-devicetrees? http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058263.html This doesn't apply. CCID and NXID are Freescale-custom layouts for data in an EEPROM. NXID replaces CCID. I suppose we could replace NXID with something FDT-based, like Wolfram's proposal, but for now my goal is clean up the code that supports the existing formats. Our aim here is to put device tree sniplets into eeproms or flash areas; we have several boards here that consist of - a module - a base board - maybe an extension board and having sub devicetrees would make it possible to simply put the devicetree for each component into a piece of storage *on the component*. So the bootloader and later Linux would be able to build the whole tree from these sniplets. Sounds complicated and interesting. I might think about it some more later. -- Timur Tabi Linux Kernel Developer @ Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Non-static global variables cause relocation to fail
Jerry Van Baren wrote:
That isn't a variable, that is the first line of a struct declaration.
I didn't include this part (although since the code compiles, it should be
obvious that it exists):
} e;
So I'm defining a global variable called 'e'. Perhaps the short name is part of
the problem.
You cut some pretty important information: what the struct is, the
actual variable in question, and whether it is initialized.
As Wolfgang pointed out, my assumption that this is a generic problem is flawed,
and it's most likely a problem with my specific implementation.
I'm guessing from the name eeprom that you have a non-zero initializer
on it???
No, no initializer.
Does it make a difference if it is uninitialized, initialized
to {0}, or initialized to non-zero values?
I don't know, I haven't considered it.
I did notice this code in fsl_i2c.c:
#ifdef CFG_SPD_BUS_NUM
static unsigned int i2c_bus_num __attribute__ ((section (data))) =
CFG_SPD_BUS_NUM;
#else
static unsigned int i2c_bus_num __attribute__ ((section (data))) = 0;
#endif
I wrote this code, but I don't remember why I added the __attribute__ ((section
(data))). I guess I should have commented it, but I wonder if it applies to
my current problem.
Does it make a difference if it is packed or not (my guess: much less
likely than initialization to cause works/broken).
It needs to be packed, otherwise the code won't work. Sadly, someone defined a
4-byte integer at address 0x72 in the EEPROM.
When I post the full patch, I'll revisit this problem. Sorry for all the noise.
--
Timur Tabi
Linux kernel developer at Freescale
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] Update Freescale sys_eeprom.c to handle CCID formats
Update the sys_eeprom.c file to handle both NXID and CCID EEPROM formats. The
NXID format replaces the older CCID format, but it's important to support both
since most boards out there still use the CCID format. This change is in
preparation for using one file to handle both formats. This will also unify
EEPROM support for all Freescale 85xx and 86xx boards.
Also update the 86xx board header files to use the standard CFG_I2C_EEPROM_ADDR
instead of ID_EEPROM_ADDR.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch is the first in a series to clean up the MAC address determination
in some of Freescale's board. The ultimate goal is to get rid of
CONFIG_ETHADDR and related macros in the board header files.
board/freescale/common/sys_eeprom.c | 754 ++-
include/configs/MPC8610HPCD.h |8 +-
include/configs/MPC8641HPCN.h |8 +-
3 files changed, 478 insertions(+), 292 deletions(-)
rewrite board/freescale/common/sys_eeprom.c (78%)
diff --git a/board/freescale/common/sys_eeprom.c
b/board/freescale/common/sys_eeprom.c
dissimilarity index 78%
index 8b13d06..d8631eb 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -1,284 +1,470 @@
-/*
- * Copyright 2006 Freescale Semiconductor
- * York Sun ([EMAIL PROTECTED])
- * Haiying Wang ([EMAIL PROTECTED])
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include common.h
-#include command.h
-#include i2c.h
-#include linux/ctype.h
-
-typedef struct {
- u8 id[4]; /* 0x - 0x0003 EEPROM Tag */
- u8 sn[12]; /* 0x0004 - 0x000F Serial Number */
- u8 errata[5]; /* 0x0010 - 0x0014 Errata Level */
- u8 date[6]; /* 0x0015 - 0x001a Build Date */
- u8 res_0; /* 0x001b Reserved */
- u8 version[4]; /* 0x001c - 0x001f Version */
- u8 tempcal[8]; /* 0x0020 - 0x0027 Temperature Calibration
Factors*/
- u8 tempcalsys[2]; /* 0x0028 - 0x0029 System Temperature
Calibration Factors*/
- u8 res_1[22]; /* 0x0020 - 0x003f Reserved */
- u8 mac_size;/* 0x0040 Mac table size */
- u8 mac_flag;/* 0x0041 Mac table flags */
- u8 mac[8][6]; /* 0x0042 - 0x0071 Mac addresses */
- u32 crc;/* 0x0072 crc32 checksum */
-} EEPROM_data;
-
-static EEPROM_data mac_data;
-
-int mac_show(void)
-{
- int i;
- u8 mac_size;
- unsigned char ethaddr[8][18];
- unsigned char enetvar[32];
-
- /* Show EEPROM tagID,
-* always the four characters 'NXID'.
-*/
- printf(ID );
- for (i = 0; i 4; i++)
- printf(%c, mac_data.id[i]);
- printf(\n);
-
- /* Show Serial number,
-* 0 to 11 charaters of errata information.
-*/
- printf(SN );
- for (i = 0; i 12; i++)
- printf(%c, mac_data.sn[i]);
- printf(\n);
-
- /* Show Errata Level,
-* 0 to 4 characters of errata information.
-*/
- printf(Errata );
- for (i = 0; i 5; i++)
- printf(%c, mac_data.errata[i]);
- printf(\n);
-
- /* Show Build Date,
-* BCD date values, as YYMMDDhhmmss.
-*/
- printf(Date 20%02x/%02x/%02x %02x:%02x:%02x\n,
- mac_data.date[0],
- mac_data.date[1],
- mac_data.date[2],
- mac_data.date[3],
- mac_data.date[4],
- mac_data.date[5]);
-
- /* Show MAC table size,
-* Value from 0 to 7 indicating how many MAC
-* addresses are stored in the system EEPROM.
-*/
- if((mac_data.mac_size 0) (mac_data.mac_size = 8))
- mac_size = mac_data.mac_size;
- else
- mac_size = 8; /* Set the max size */
- printf(MACSIZE %x\n, mac_size);
-
- /* Show Mac addresses */
- for (i = 0; i mac_size; i++) {
- sprintf((char *)ethaddr[i],
- %02x:%02x:%02x:%02x:%02x:%02x,
- mac_data.mac[i][0],
- mac_data.mac[i][1
[U-Boot-Users] Non-static global variables cause relocation to fail
I tried to find documentation on this, but couldn't. I've discovered, on PowerPC 85xx systems at least, that the mere presence of a non-static global variable, even if it isn't used by any code, will cause relocation to fail. Exactly how it fails, I can't say, but U-Boot does hang. If I make the global variable static, the problem goes away. Note that I have no code that actually references the variable. It just sits there, occupying space. Fortunately, the data structure doesn't need to be non-static. I just forgot to put 'static' in its definition. Of course, it would have been nice to know this up front. Can someone explain why this is the case? Do I need to do anything special in my code to access global variables, static or not static? -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Non-static global variables cause relocation to fail
Wolfgang Denk wrote:
You don't seriously expect any real help given such a vague
description? It would be somewhat helpful if you said exactly which
changes cause the code to work or fail...
I did say that. Simply making the global variable not static caused it to fail.
Works:
static struct __attribute__ ((__packed__)) eeprom {
Doesn't work:
struct __attribute__ ((__packed__)) eeprom {
Everything else is the same.
--
Timur Tabi
Linux kernel developer at Freescale
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 0/9] U-boot-V2: Introduce I2C support for SDP3430
Menon, Nishanth wrote: Hi Sascha, This series of patches introduce I2C support in U-Boot v2. This support is similar to the one in 2.6.26 rc5 kernel. i2ctools diagnostics introduced is based on http://www.lm-sensors.org/wiki/I2CTools The benefit is that we can backport drivers present in linux kernel to u-boot v2 with very little effort. Do we really want to bloat U-Boot with these huge Linux drivers? U-Boot already has I2C support that works pretty well. Your patchset is overkill, IMHO. -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-Boot 1.3.3 release
Wolfgang Denk wrote: Hi everybody, U-Boot v1.3.3 has been released and is available from the git repository and the FTP server. You didn't pick up this patch: Fix 8313ERDB board configuration from York Sun, so 1.3.3 is broken on the MPC8313ERDB. The Merge Window for v1.3.3 is open until June 03, 23:59:59 MET. Don't you mean 1.3.4? Top changeset contributors by employer DENX 223 (31.2%) Freescale 112 (15.7%) We're #2!! We're #2!!! -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Fix 8313ERDB board configuration
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Please also remove the default MAC address assignments. I think we need them, don't we? No, or you can install this U-Boot image exactly on one specific, single board. I understand your argument, but it's rather disingenuous when you allow this code to exist: #ifdef CONFIG_ETHADDR ethaddr= MK_STR(CONFIG_ETHADDR) \0 #endif #ifdef CONFIG_ETH1ADDR eth1addr= MK_STR(CONFIG_ETH1ADDR) \0 #endif #ifdef CONFIG_ETH2ADDR eth2addr= MK_STR(CONFIG_ETH2ADDR) \0 #endif #ifdef CONFIG_ETH3ADDR eth3addr= MK_STR(CONFIG_ETH3ADDR) \0 #endif #ifdef CONFIG_IPADDR ipaddr= MK_STR(CONFIG_IPADDR) \0 #endif #ifdef CONFIG_SERVERIP serverip= MK_STR(CONFIG_SERVERIP) \0 #endif If you get rid of this block, you'll solve the problem for all boards, instead of nagging people who post patches for unrelated bugs. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Fix 8313ERDB board configuration
Wolfgang Denk wrote: There are a few cases where exactly this is needed. The fact that some feature exists does not mean that you should use it without careful consideration of the effects and side-effects. Fair enough, but the changes that are in York's patch have been tested. Considering that the fix window for 1.3.3 is closing fast, we don't have the bandwidth for additional testing of the additional and unrelated changes that are being requested. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Fix 8313ERDB board configuration
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Fair enough, but the changes that are in York's patch have been tested. Considering that the fix window for 1.3.3 is closing fast, we don't have the bandwidth for additional testing of the additional and unrelated changes that are being requested. What exactly is the risk? Probably not much, but that isn't my point. I find it really annoying when someone posts a patch to fix a specific bug, and the reply is why don't you fix this other bug too, while you're at it? Right now, the 8313ERDB will generate a machine check if you boot it with the top-of-tree kernel. This patch fixes that. For 1.3.4, if you like, we can submit a patch that removes all MAC and IP address macros from all 83xx boards. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
[EMAIL PROTECTED] wrote: Hi, Thanks all for quick response. Actually we are having a huge application for video capture which is presently running on x86 based board having some DSPs. As per the data sheet of MPC8349E(e300 core), MPC8349E can be configured in true little endian mode. It would be a lot easier if you modified the application to work on big-endian and little-endian. Just look through the code in places where the endian matters, and add cpu_to_be32() and be32_to_cpu() (or similar functions). The only time this will be real problem is with DMA, since on 83xx you cannot modify the data during a DMA transfer. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
David Hawkins wrote: When you are dealing with a driver, register accesses need to be in a specific format. The MPC8349EA has some of its registers in big-endian format, and others in little-endian format. Regardless of the mode you operate your processor, you will *have* to use the correct byte-swap functions. That's why we use cpu_to_be32() to write to big-endian registers. On a big-endian processor, this macro doesn't modify the parameter. So, *p = be32_to_cpu(12); will be compiled to *p = 12; On a little-endian process, the macro will do a byte-swap. This macro, and others like it, eliminates the need to have two different versions of the code. DMA would be used to move a block of data, not to manipulate a register. I can see you've never written an audio driver before. The data itself has endianness, and the register may require the data to appear in one endian or another. If -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
David Hawkins wrote: So are you saying you would DMA to a register with a specific endianness. Typically, yes. Theoretically, a device could be programmed to handle any number of bit- and byte-endianness, but I haven't found one. Most of them time, it's just a shift register and so which means the bit and the bytes have to be in the same order. The result is that the endianness of the host processor has to to match the endianness of the audio samples. The Freescale SSI has this problem. When the SSI is on an i.MX, it only supports little-endian samples. On an MPC8610, it only supports big-endian samples. The two situations I can think of with a DMA controller moving data that requires a specific endianness are; 1) DMA controller scatter-gather descriptor entries. These would normally consist of source, destination, length, and next pointers in a specific endianness format. I don't think this applies. The descriptor entries are manually programmed; that is, you write to individual fields in the descriptor one at a time. 2) DMA from memory to a FIFO destination address that expects little-endian format 16-bit values. Yes, this is what audio drivers do. In either case, you would use the byte-conversion routines to serialize the descriptor entries in memory, or in the source buffer, into the correct endianness before performing enabling the DMA. Very true. However, this means that if the original data is in the wrong endian, you have to have a middle layer that modifies the data when copying from the source buffer to the DMA buffer. This adds overhead. If Vivek's application correctly serializes any endian-specific data before using the MPC8349EA DMA controller, then he should have no issues. Yes, but it may take him weeks to find all the places in the where the endianness matters. Does an audio driver differ in any respect to the above situations? Not really. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c for MPC8610HPCD board
Jon Loeliger wrote: So, I'm guessing, it came from the Ed. That is, it came that way from the Day One. So there. I just tested it without -O2, and it works fine. So the -O2 should be removed. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some 86xx chips
Wolfgang, I think you forgot this one. Jon Loeliger wrote: On Fri, 2008-04-18 at 06:14 +0200, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Some 86xx chips use CCB as the base clock for the I2C, and others used CCB/2. There is no pattern that can be used to determine which chips use which frequency, so the only way to determine is to look up the actual SOC designation and use the right value for that SOC. Signed-off-by: Timur Tabi [EMAIL PROTECTED] Will this goin through the 86xx custodian repo, or should I pull this directly? Best regards, Wolfgang Denk Please pick this up directly. Thanks, jdl -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Fix calculation of I2C clock for some 85xx chips
Some 85xx chips use CCB as the base clock for the I2C. Some use CCB/2, and
some use CCB/3. There is no pattern that can be used to determine which
chips use which frequency, so the only way to determine is to look up the
actual SOC designation and use the right value for that SOC.
Update immap_85xx.h to include the GUTS PORDEVSR2 register.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Yes, this is ugly and stupid, but the only alternative is to update each
board configuration file with another CONFIG_ option. And yes, this does
mean that as new 85xx variants are announced, cpu/mpc85xx/speed.c may need
to be updated.
cpu/mpc85xx/speed.c | 31 ++-
include/asm-ppc/immap_85xx.h |4 +++-
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/cpu/mpc85xx/speed.c b/cpu/mpc85xx/speed.c
index d90d397..699441b 100644
--- a/cpu/mpc85xx/speed.c
+++ b/cpu/mpc85xx/speed.c
@@ -65,6 +65,9 @@ void get_sys_info (sys_info_t * sysInfo)
int get_clocks (void)
{
sys_info_t sys_info;
+#ifdef CONFIG_MPC8544
+ volatile ccsr_gur_t *gur = (void *) CFG_MPC85xx_GUTS_ADDR;
+#endif
#if defined(CONFIG_CPM2)
volatile ccsr_cpm_t *cpm = (ccsr_cpm_t *)CFG_MPC85xx_CPM_ADDR;
uint sccr, dfbrg;
@@ -78,8 +81,34 @@ int get_clocks (void)
gd-cpu_clk = sys_info.freqProcessor;
gd-bus_clk = sys_info.freqSystemBus;
gd-mem_clk = sys_info.freqDDRBus;
+
+ /*
+* The base clock for I2C depends on the actual SOC. Unfortunately,
+* there is no pattern that can be used to determine the frequency, so
+* the only choice is to look up the actual SOC number and use the value
+* for that SOC. This information is taken from application note
+* AN2919.
+*/
+#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
+ defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555)
gd-i2c1_clk = sys_info.freqSystemBus;
- gd-i2c2_clk = sys_info.freqSystemBus;
+#elif defined(CONFIG_MPC8544)
+ /*
+* On the 8544, the I2C clock is the same as the SEC clock. This can be
+* either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See
+* 4.4.3.3 of the 8544 RM. Note that this might actually work for all
+* 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the
+* PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544.
+*/
+ if (gur-pordevsr2 MPC85xx_PORDEVSR2_SEC_CFG)
+ gd-i2c1_clk = sys_info.freqSystemBus / 3;
+ else
+ gd-i2c1_clk = sys_info.freqSystemBus / 2;
+#else
+ /* Most 85xx SOCs use CCB/2, so this is the default behavior. */
+ gd-i2c1_clk = sys_info.freqSystemBus / 2;
+#endif
+ gd-i2c2_clk = gd-i2c1_clk;
#if defined(CONFIG_CPM2)
gd-vco_out = 2*sys_info.freqSystemBus;
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index 3506aec..42c066e 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -1570,7 +1570,9 @@ typedef struct ccsr_gur {
#define MPC85xx_PORDEVSR_RIO_CTLS 0x0008
#define MPC85xx_PORDEVSR_RIO_DEV_ID0x0007
uintpordbgmsr; /* 0xe0010 - POR debug mode status register */
- charres1[12];
+ uintpordevsr2; /* 0xe0014 - POR I/O device status regsiter 2 */
+#define MPC85xx_PORDEVSR2_SEC_CFG 0x0020
+ charres1[8];
uintgpporcr;/* 0xe0020 - General-purpose POR configuration
register */
charres2[12];
uintgpiocr; /* 0xe0030 - GPIO control register */
--
1.5.4
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Fix calculation of I2C clock for some 86xx chips
Some 86xx chips use CCB as the base clock for the I2C, and others used CCB/2. There is no pattern that can be used to determine which chips use which frequency, so the only way to determine is to look up the actual SOC designation and use the right value for that SOC. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Yes, this is ugly and stupid, but the only alternative is to update each board configuration file with another CONFIG_ option. And yes, this does mean that as new 86xx variants are announced, cpu/mpc86xx/speed.c may need to be updated. cpu/mpc86xx/speed.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/cpu/mpc86xx/speed.c b/cpu/mpc86xx/speed.c index 7e884f8..da5b58b 100644 --- a/cpu/mpc86xx/speed.c +++ b/cpu/mpc86xx/speed.c @@ -105,8 +105,20 @@ int get_clocks(void) get_sys_info(sys_info); gd-cpu_clk = sys_info.freqProcessor; gd-bus_clk = sys_info.freqSystemBus; + + /* +* The base clock for I2C depends on the actual SOC. Unfortunately, +* there is no pattern that can be used to determine the frequency, so +* the only choice is to look up the actual SOC number and use the value +* for that SOC. This information is taken from application note +* AN2919. +*/ +#ifdef CONFIG_MPC8610 gd-i2c1_clk = sys_info.freqSystemBus; - gd-i2c2_clk = sys_info.freqSystemBus; +#else + gd-i2c1_clk = sys_info.freqSystemBus / 2; +#endif + gd-i2c2_clk = gd-i2c1_clk; if (gd-cpu_clk != 0) return 0; -- 1.5.4 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h
Andy Fleming wrote: Some systems have md5.h installed in /usr/include/. This isn't the desired file (we want the one in include/md5.h). This will avoid the conflict. This fixes the host tools building problem Signed-off-by: Andy Fleming [EMAIL PROTECTED] Acked-by: Timur Tabi [EMAIL PROTECTED] This fixes a build break for me. Please apply. -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 3/3] QE IO - Add pario command
David Saada wrote: As far as I managed to understand, reginfo just shows a dump of CPU based register values, while pario allows you to set and get the value of a GPIO port - two different things. We found this very useful for debugging our board, and I think it can be useful for many other processor families as well. There is also a qe command that takes sub-commands as a parameter. Currently, the only one is qe fw for uploading firmware. Perhaps you could do qe pario? -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Add support for setting the I2C bus speed in fsl_i2c.c
Luigi 'Comio' Mantellini wrote:
This patch should resolve the compilation issues on 547x/548x cpus.
Sorry, I didn't even think to check for anything outside of PowerPC. I had no
idea m68k used fsl_i2c.c.
@@ -47,6 +47,9 @@ typedef struct global_data {
unsigned long vco_clk;
unsigned long flb_clk;
#endif
+#ifdef CONFIG_MCF547x_8x
+ u32 i2c1_clk;
+#endif
unsigned long ram_size; /* RAM size */
unsigned long reloc_off; /* Relocation Offset */
unsigned long reset_status; /* reset status register at boot
*/
I suggest that you get rid of the #ifdef and always define i2c1_clk. The value
will be set to 0 on systems that don't have an I2C. I'm planning on submitting
patches to asm-ppc/global_data.h to get rid of a bunch of #ifdefs because it's
getting too messy.
Either way, I ACK this patch.
--
Timur Tabi
Linux kernel developer at Freescale
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Add support for setting the I2C bus speed in fsl_i2c.c
Timur Tabi wrote: Add support to the Freescale I2C driver (fsl_i2c.c) for setting and querying the I2C bus speed. Current 8[356]xx boards define the CFG_I2C_SPEED macro, but fsl_i2c.c ignores it and uses conservative value when programming the I2C bus speed. Kim and Jon, I tested this patch on 8360, 8568, and 8641. Could you review this patch and ack/nack? Andy said he'll pick it up if you guys ack it. -- Timur Tabi Linux kernel developer at Freescale - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Help with warning: 'alias' attribute ignored
I'm trying to write code that uses the pragma weak feature of gcc to define a
global variable that is used only if it isn't defined somewhere else. I thought
I had it working, but then I noticed this:
powerpc-linux-gnu-gcc -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__
-DTEXT_BASE=0xFE00 -I/temp/u-boot.281/include -fno-builtin -ffreestanding
-nostdinc -isystem
/opt/freescale/usr/local/gcc-4.2.72-eglibc-2.5.72-1/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.2.1/include
-pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC83XX -DCONFIG_E300 -ffixed-r2
-msoft-float -Wall -Wstrict-prototypes -c -o fsl_i2c.o fsl_i2c.c
fsl_i2c.c: In function 'get_fdr':
fsl_i2c.c:72: warning: 'alias' attribute ignored
Here's the code in question, which is in fsl_i2c.c:
#pragma weak fsl_i2c_speed_map = default_fsl_i2c_speed_map
struct fsl_i2c_speed_map default_fsl_i2c_speed_map[] = {
{0, 0x3F}, {-1, 0x3F}
};
static u8 get_fdr(unsigned int i2c_clk, unsigned int speed)
{
extern struct fsl_i2c_speed_map fsl_i2c_speed_map[];
...
Line 72 is the extern struct fsl... line.
In a platform-specific file, I have this:
struct fsl_i2c_speed_map fsl_i2c_speed_map[] = {
{0, 0x20},
...
What I'm trying to do is to make it so that you don't need to define the
fsl_i2c_speed_map[] array in your platform file. However, I get the warning
message if fsl_i2c_speed_map[] *is* defined in the platform file.
Am I just doing this wrong, or is there a way to avoid the compiler warning?
--
Timur Tabi
Linux kernel developer at Freescale
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] mpc83xx: make dtb basename file references equal those of linux
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: I don't think this is a good idea. File names and board config names should match as far as possible, and here is no good reason to deviate from this rule. But the DTS files have already been renamed. The DTS for the MPC832xE-MDS is called mpc832x_mds.dts, so the DTB is going to be called mpc832x_mds.dtb. Well, then undo that change, please? I'm not the one who renamed the files, but I don't think they're going to be changed back. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-Boot 1.3.2 release
Wolfgang Denk wrote: Top lines changed by employer Gentoo61912 (31.8%) Freescale 40796 (21.0%) How do you determine these numbers? By email address? -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] mpc83xx: make dtb basename file references equal those of linux
Wolfgang Denk wrote: - fdtfile=mpc832xemds.dtb\0 \ + fdtfile=mpc832x_mds.dtb\0 \ I don't think this is a good idea. File names and board config names should match as far as possible, and here is no good reason to deviate from this rule. But the DTS files have already been renamed. The DTS for the MPC832xE-MDS is called mpc832x_mds.dts, so the DTB is going to be called mpc832x_mds.dtb. Would you prefer that Kim also renamed MPC832XEMDS.h to MPC832X_MDS.h, as well as change the Makefile? -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] fix QE firmware uploading limit
Fix a typo in qe_upload_firmware() that prevented uploading firmware on
systems with more than one RISC core.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch is for 1.3.2. Andy, I know this isn't an 85xx-specific patch,
but I was hoping you'd take it for me anyway.
drivers/qe/qe.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c
index 63acfa3..7b6ecd7 100644
--- a/drivers/qe/qe.c
+++ b/drivers/qe/qe.c
@@ -334,7 +334,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
}
/* Validate some of the fields */
- if ((firmware-count 1) || (firmware-count = MAX_QE_RISC)) {
+ if ((firmware-count 1) || (firmware-count MAX_QE_RISC)) {
printf(Invalid data\n);
return -EINVAL;
}
--
1.5.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v5] QE IO: Add initial data to pin configuration + read/write functions
David Saada wrote: On the MPC83xx MPC85xx architectures that have QE, add initial data to the pin configuration table (qe_iop_conf_tab). This is relevant for GPIO pins defined as output. One can setup a value of -1 to leave the value unchanged. QE initialization tables in all relevant boards were also replaced. In addition, add IO pin read write functions. This patch also includes commands for reading and writing parallel I/O ports (pario command). Signed-off-by: David Saada [EMAIL PROTECTED] Acked-by: Timur Tabi [EMAIL PROTECTED] FYI David, I just noticed this patch yesterday. I would have noticed it and ack'd it back on the 7th if you had included my email address on the To: line. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 8610HPCD: Don't use VIDEO/CFB_CONSOLE by default.
Jon Loeliger wrote: diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 3920147..9e70198 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -24,7 +24,7 @@ #define CONFIG_FSL_DIU_FB1 /* FSL DIU */ /* video */ -#define CONFIG_VIDEO +#undef CONFIG_VIDEO #if defined(CONFIG_VIDEO) #define CONFIG_CFB_CONSOLE Wolfgang just applied a patch that removed unnecessary #undef DEBUG, and your patch adds an unnecessary #undef CONFIG_VIDEO. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] NET: Add Vitesse VSC7385 firmware uploading
Ben Warren wrote: Acked-by: Ben Warren [EMAIL PROTECTED] Kim - would you mind pulling this into your tree? Best to keep it with part 2. FYI, if the 83xx part is applied without the NET part, all 83xx platforms with the 7385 will fail to compile. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] QE: Move FDT support into a common file
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Move the flat device tree setup for QE related devices into a common file shared between 83xx 85xx platforms that have QE's. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Applied, thanks. Best regards, Wolfgang Denk Thanks for applying this. I have one more patch for 1.3.2 that you may have missed: 85xx, 86xx: Determine I2C clock frequencies and store in global_data. It's in Andy Fleming's tree: http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-mpc85xx.git -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 83xx: Add Vitesse VSC7385 firmware uploading
Ben Warren wrote: The problem is that you're artificially making this a PowerPC-only part. If you used 8-bit accessors endianness wouldn't matter and other architectures could use this without changes (notwithstanding the #includes...) Ok, I will try to figure out how to make 8-bit accesses work. I'll post an update later this week. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 83xx: Add Vitesse VSC7385 firmware uploading
Ben Warren wrote: Is this switch able to pass traffic in a default configuration without this firmware or is it dead? Without the firmware, the switch is completely dead. I'm not 100% convinced that this is network code, but my opinion isn't very strong and I can't really think of a better place (maybe device/misc or device/non_free?) I'll move it to device/misc if you want. device/non_free doesn't exist so I don't want to create it. +#include config.h +#include common.h +#include asm/io.h +#include asm/errno.h + I think Kim mentioned this will break some architectures. Just repeating it. Yeah, I'm still waiting for someone to tell me why. In the meantime, I've done this: #include config.h #ifdef CONFIG_VSC7385_ENET #include common.h #include asm/io.h #include asm/errno.h It looks to me that the data bus is 8 bits. Why are you defining registers as 32 bits and using 32-bit accessors? Beats me. The programming for this chip is really weird, the documentation is under NDA, and I didn't write the original code. Mine is a little prettier than the original (http://www.bitshrine.org/gpp/u-boot-1.2.0-mpc837xerdb-vsc7385-load.patch), but I'm not going to change the actual I/O operations. When you write to the device, can you express the value in hex? It's quicker for the reader (who has Vitesse datasheets, of course) to figure out what you're doing. Sure, I'll change it. Here you use mnemonics for describing the base register settings. I know it's not new code, but it would be nice to be consistent All of the Freescale header files could be scrubbed. I figured I was already making enough changes. They *should* be using mnemonics for everything. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/2] NET: Add Vitesse VSC7385 firmware uploading
The Vitesse VSC7385 is a 5-port switch found on the Freescale MPC8349E-mITX
and other boards. A small firwmare must be uploaded to its on-board memory
before it can be enabled. This patch adds the code which uploads firmware
(but not the firmware itself).
Previously, this feature was provided by a U-Boot application that was
made available only on Freescale BSPs. The VSC7385 firmware must still
be obtained separately, but at least there is no longer a need for a separate
application.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch is for U-Boot 1.3.3.
drivers/net/Makefile |1 +
drivers/net/vsc7385.c | 101 +
include/vsc7385.h | 13 ++
3 files changed, 115 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/vsc7385.c
create mode 100644 include/vsc7385.h
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index b9723fa..5ae7cb7 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -57,6 +57,7 @@ COBJS-y += tigon3.o
COBJS-y += tsec.o
COBJS-y += tsi108_eth.o
COBJS-y += uli526x.o
+COBJS-y += vsc7385.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/net/vsc7385.c b/drivers/net/vsc7385.c
new file mode 100644
index 000..f440ce0
--- /dev/null
+++ b/drivers/net/vsc7385.c
@@ -0,0 +1,101 @@
+/*
+ * Vitesse 7385 Switch Firmware Upload
+ *
+ * Author: Timur Tabi [EMAIL PROTECTED]
+ *
+ * Copyright 2008 Freescale Semiconductor, Inc. This file is licensed
+ * under the terms of the GNU General Public License version 2. This
+ * program is licensed as is without any warranty of any kind, whether
+ * express or implied.
+ *
+ * This module uploads proprietary firmware for the Vitesse VSC7385 5-port
+ * switch.
+ */
+
+#include config.h
+
+#ifdef CONFIG_VSC7385_ENET
+
+#include common.h
+#include asm/io.h
+#include asm/errno.h
+
+/*
+ * Upload a Vitesse VSC7385 firmware image to the hardware
+ *
+ * This function takes a pointer to a VSC7385 firmware image and a size, and
+ * uploads that firmware to the VSC7385.
+ *
+ * This firmware is typically located at a board-specific flash address,
+ * and the size is typically 8KB.
+ *
+ * The firmware is Vitesse proprietary.
+ *
+ * Further details on the register information can be obtained from Vitesse.
+ */
+int vsc7385_upload_firmware(void *firmware, unsigned int size)
+{
+ u8 *fw = firmware;
+ unsigned int i;
+
+ u32 *gloreset = (u32 *) (CFG_VSC7385_BASE + 0x1c050);
+ u32 *icpu_ctrl = (u32 *) (CFG_VSC7385_BASE + 0x1c040);
+ u32 *icpu_addr = (u32 *) (CFG_VSC7385_BASE + 0x1c044);
+ u32 *icpu_data = (u32 *) (CFG_VSC7385_BASE + 0x1c048);
+ u32 *icpu_rom_map = (u32 *) (CFG_VSC7385_BASE + 0x1c070);
+#ifdef DEBUG
+ u32 *chipid = (u32 *) (CFG_VSC7385_BASE + 0x1c060);
+#endif
+
+ out_be32(gloreset, 3);
+ udelay(200);
+
+ out_be32(icpu_ctrl, 0x8E);
+ udelay(20);
+
+ out_be32(icpu_rom_map, 1);
+ udelay(20);
+
+/* Write the firmware to I-RAM */
+ out_be32(icpu_addr, 0);
+ udelay(20);
+
+ for (i = 0; i size; i++) {
+ out_be32(icpu_data, fw[i]);
+ udelay(20);
+ if (ctrlc())
+ return -EINTR;
+ }
+
+ /* Read back and compare */
+ out_be32(icpu_addr, 0);
+ udelay(20);
+
+ for (i = 0; i size; i++) {
+ u8 value;
+
+ value = (u8) in_be32(icpu_data);
+ udelay(20);
+ if (value != fw[i]) {
+ debug(VSC7385: Upload mismatch: address 0x%x,
+ read value 0x%x, image value 0x%x\n,
+ i, value, fw[i]);
+
+ return -EIO;
+ }
+ if (ctrlc())
+ break;
+ }
+
+ out_be32(icpu_ctrl, 0x0B);
+ udelay(20);
+
+#ifdef DEBUG
+ printf(VSC7385: Chip ID is %08x\n, in_be32(chipid));
+ udelay(20);
+#endif
+
+ return 0;
+}
+
+#endif
diff --git a/include/vsc7385.h b/include/vsc7385.h
new file mode 100644
index 000..0432499
--- /dev/null
+++ b/include/vsc7385.h
@@ -0,0 +1,13 @@
+/*
+ * Header file for vsc7385.c
+ *
+ * Author: Timur Tabi [EMAIL PROTECTED]
+ *
+ * Copyright 2008 Freescale Semiconductor, Inc. This file is licensed
+ * under the terms of the GNU General Public License version 2. This
+ * program is licensed as is without any warranty of any kind, whether
+ * express or implied.
+ */
+
+int vsc7385_upload_firmware(void *firmware, unsigned int size);
+
--
1.5.2.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net
[U-Boot-Users] [PATCH 0/2] Vitesse VSC7385 firmware patches
These two patches add the ability to upload firmware to the Vitesse VSC7385 and update some Freescale 83xx board files to use them. These patches are for U-Boot 1.3.3. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/2] 83xx: Add Vitesse VSC7385 firmware uploading
Update the MPC8349E-mITX, MPC8313E-RDB, and MPC837XE-RDB board files to upload
the Vitesse VSC7385 firmware. Changed CONFIG_VSC7385 to CONFIG_VSC7385_ENET.
Cleaned up the board header files to make selecting the VSC7385 easier to
control.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch is for U-Boot 1.3.3
board/freescale/mpc8313erdb/mpc8313erdb.c | 21 +++
board/freescale/mpc8349itx/mpc8349itx.c | 15 +-
board/freescale/mpc837xerdb/mpc837xerdb.c | 27 +++--
include/configs/MPC8313ERDB.h | 88 +++--
include/configs/MPC8349ITX.h | 33 ---
include/configs/MPC837XERDB.h | 83 +++-
6 files changed, 196 insertions(+), 71 deletions(-)
diff --git a/board/freescale/mpc8313erdb/mpc8313erdb.c
b/board/freescale/mpc8313erdb/mpc8313erdb.c
index 42019fb..7cbdb7b 100644
--- a/board/freescale/mpc8313erdb/mpc8313erdb.c
+++ b/board/freescale/mpc8313erdb/mpc8313erdb.c
@@ -28,6 +28,7 @@
#endif
#include pci.h
#include mpc83xx.h
+#include vsc7385.h
DECLARE_GLOBAL_DATA_PTR;
@@ -98,6 +99,26 @@ void pci_init_board(void)
mpc83xx_pci_init(1, reg, warmboot);
}
+/*
+ * Miscellaneous late-boot configurations
+ *
+ * If a VSC7385 microcode image is present, then upload it.
+*/
+int misc_init_r(void)
+{
+ int rc = 0;
+
+#ifdef CONFIG_VSC7385_IMAGE
+ if (vsc7385_upload_firmware((void *) CONFIG_VSC7385_IMAGE,
+ CONFIG_VSC7385_IMAGE_SIZE)) {
+ puts(Failure uploading VSC7385 microcode.\n);
+ rc = 1;
+ }
+#endif
+
+ return rc;
+}
+
#if defined(CONFIG_OF_BOARD_SETUP)
void ft_board_setup(void *blob, bd_t *bd)
{
diff --git a/board/freescale/mpc8349itx/mpc8349itx.c
b/board/freescale/mpc8349itx/mpc8349itx.c
index 8c19ad6..5571248 100644
--- a/board/freescale/mpc8349itx/mpc8349itx.c
+++ b/board/freescale/mpc8349itx/mpc8349itx.c
@@ -26,6 +26,7 @@
#include i2c.h
#include spd.h
#include miiphy.h
+#include vsc7385.h
#ifdef CONFIG_PCI
#include asm/mpc8349_pci.h
@@ -183,7 +184,7 @@ int checkboard(void)
*/
int misc_init_f(void)
{
-#ifdef CONFIG_VSC7385
+#ifdef CONFIG_VSC7385_ENET
volatile u32 *vsc7385_cpuctrl;
/* 0x1c0c0 is the VSC7385 CPU Control (CPUCTRL) Register. The power up
@@ -245,6 +246,8 @@ int misc_init_f(void)
}
/*
+ * Miscellaneous late-boot configurations
+ *
* Make sure the EEPROM has the HRCW correctly programmed.
* Make sure the RTC is correctly programmed.
*
@@ -256,6 +259,8 @@ int misc_init_f(void)
*
* This function makes sure that the I2C EEPROM is programmed
* correctly.
+ *
+ * If a VSC7385 microcode image is present, then upload it.
*/
int misc_init_r(void)
{
@@ -381,6 +386,14 @@ int misc_init_r(void)
i2c_set_bus_num(orig_bus);
#endif
+#ifdef CONFIG_VSC7385_IMAGE
+ if (vsc7385_upload_firmware((void *) CONFIG_VSC7385_IMAGE,
+ CONFIG_VSC7385_IMAGE_SIZE)) {
+ puts(Failure uploading VSC7385 microcode.\n);
+ rc = 1;
+ }
+#endif
+
return rc;
}
diff --git a/board/freescale/mpc837xerdb/mpc837xerdb.c
b/board/freescale/mpc837xerdb/mpc837xerdb.c
index 2d42595..1ab7be4 100644
--- a/board/freescale/mpc837xerdb/mpc837xerdb.c
+++ b/board/freescale/mpc837xerdb/mpc837xerdb.c
@@ -16,6 +16,8 @@
#include i2c.h
#include spd.h
#include asm/io.h
+#include vsc7385.h
+
#if defined(CONFIG_SPD_EEPROM)
#include spd_sdram.h
#endif
@@ -59,11 +61,6 @@ testdram(void)
}
#endif
-int board_early_init_f(void)
-{
- return 0;
-}
-
#if defined(CONFIG_DDR_ECC) !defined(CONFIG_ECC_INIT_VIA_DDRC)
void ddr_enable_ecc(unsigned int dram_size);
#endif
@@ -138,6 +135,26 @@ int checkboard(void)
return 0;
}
+/*
+ * Miscellaneous late-boot configurations
+ *
+ * If a VSC7385 microcode image is present, then upload it.
+*/
+int misc_init_r(void)
+{
+ int rc = 0;
+
+#ifdef CONFIG_VSC7385_IMAGE
+ if (vsc7385_upload_firmware((void *) CONFIG_VSC7385_IMAGE,
+ CONFIG_VSC7385_IMAGE_SIZE)) {
+ puts(Failure uploading VSC7385 microcode.\n);
+ rc = 1;
+ }
+#endif
+
+ return rc;
+}
+
#if defined(CONFIG_OF_BOARD_SETUP)
void ft_board_setup(void *blob, bd_t *bd)
diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
index f12a3e6..9576fa5 100644
--- a/include/configs/MPC8313ERDB.h
+++ b/include/configs/MPC8313ERDB.h
@@ -38,6 +38,14 @@
#define CONFIG_PCI
#define CONFIG_83XX_GENERIC_PCI
+#define CONFIG_MISC_INIT_R
+
+/*
+ * On-board devices
+ */
+#define CONFIG_VSC7385_ENET
+
+
#ifdef CFG_66MHZ
#define CONFIG_83XX_CLKIN 6667/* in Hz */
#elif defined(CFG_33MHZ)
@@ -65,6 +73,22 @@
#define CFG_ACR_RPTCNT 3 /* Arbiter repeat count (0-7) */
/*
+ * Device configurations
+ */
+
+/* Vitesse 7385 */
+
+#ifdef CONFIG_VSC7385_ENET
+
+#define CONFIG_TSEC2
+
+/* The flash address and size of the VSC7385
Re: [U-Boot-Users] [PATCH v4] QE IO: Add initial data to pin configuration + read/write functions
David Saada wrote: Don't use volatile. Use the accessor functions: in_be32 and out_be32. This was copied from the qe_config_iopin function, which still used the volatile directive. I can fix it there as well, but I see that it's used everywhere. Yeah, and it's wrong everywhere, too. Maybe this needs a thorough change, but I'm not sure it should be in my humble patch. Well, we may not have the time to fix all the wrong usages, but we shouldn't make it worse. All new code should use the accessors. Put these in a header file. Will change as well. I think ioports.h is good enough for this purpose. So far, qe_config_iopin wasn't there as well, so it will also be moved there. I'm okay with that. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 83xx: Add Vitesse VSC7385 firmware uploading
Kim Phillips wrote: I'd prefer firmware uploading bits remain apps (perhaps in examples/?) but I don't know the U-Boot Philosophy for this area.. The whole point behind this patch is to get rid of the currently application and make this a native feature of U-Boot. In this regard, it is no different than my QE firmware patch. drivers/net bits go through net maintainer, Ben Warren (separate patch). I can break it into two patches. +#include config.h +#include common.h +#include asm/io.h +#include asm/errno.h This breaks some archs. Which ones? How? These header files look pretty harmless to me. What if I did this: #include config.h #ifdef CONFIG_VSC7385_ENET #include common.h #include asm/io.h #include asm/errno.h who is the original author of this code? One of our BSP developers. I took the code from his application and cleaned it up. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections
Wolfgang Denk wrote: Except for the declaration of the variable itself, *nothing* changes. What do you mean would become simpler? A normal global variable is simpler than one that's tied to a specific register, wouldn't you say? I wasn't trying to be that insightful. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PPC] PLEASE READ - was: [PATCH] Fix linker scripts: add NOLOAD atribute to .bss/.sbss sections
Wolfgang Denk wrote: A possible approach to this problem is to avoid using a global register variable and use a plain global variable instead. Sounds like a good idea to me. If the code works, then this would simplify things a great deal. The code that reads and writes the gd_t isn't time-critical anyway. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Please pull u-boot-mpc85xx.git
Wolfgang Denk wrote: Applied. Also tested on STX GP3SSA (8555 version) and TQM8540. Both work fine. Wolfgang, you forgot two patches. These patches were posted to this mailing list, but not included in any custodian repo: [PATCH] QE: Move FDT support into a common file [PATCH v2] Remove #undef DEBUGx and #define DEBUG from all board header files -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 85xx, 86xx: Determine I2C clock frequencies and store in global_data
Timur Tabi wrote: Update global_data to define i2c1_clk and i2c2_clk to 85xx and 86xx. Update the get_clocks() function in 85xx and 86xx to determine the I2C clock frequency and store it in gd-i2c1_clk and gd-i2c2_clk. Is there a reason why this patch was never picked up for the 1.3.2 merge window? I posted it on the ninth and emailed both of you a couple times about it. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v3] QE IO: Add initial data to pin configuration + read/write functions
David Saada wrote: Any feedback on this patch? Timur? It looks okay, but I haven't had a chance to review it thoroughly. I don't like the value of 2 for ignore. Since that type is an 'int', how about using -1 instead? -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-Boot version string in kernel/userspace
Gregoire Banderet wrote: Hi, Waht's the best way to get the U-Boot version string (the one returned by U-Boot cmd version) from userspace? Arg passed to the kernel? U-Boot env variables and use fw_getenv? U-Boot disappears when the kernel loads, so the only cross-platform option is to pass a command-line parameter to the kernel. Such a change would probably not be accepted into the mainline, however. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Remove #undef DEBUG from MPC83xx board header files
Kim Phillips wrote: ? Am I missing something? mpc83xx files aren't special in this area. it appears to be a problem for a lot of boards: I'm a Freescale employee (as are you), and so I'm not going to post a patch that makes an untested changed to someone else's boards. And since 83xx is separate from 85xx and 86xx, I have to keep the patches separate, too. -- Timur Tabi Linux kernel developer at Freescale - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Remove #undef DEBUGx from all board header files
Remove the #undef DEBUG and other DEBUG_xxx lines from all board header files. The inclusion of this line makes it impossible to enable debug code in other source files, because #define DEBUG typically needs to be defined before any header files are included. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- include/configs/AP1000.h |2 -- include/configs/BAB7xx.h |1 - include/configs/EB+MCF-EV123.h |1 - include/configs/ELPPC.h|1 - include/configs/IP860.h|1 - include/configs/IPHASE4539.h |2 -- include/configs/M5235EVB.h |2 -- include/configs/M5271EVB.h |2 -- include/configs/M5329EVB.h |2 -- include/configs/M54455EVB.h|2 -- include/configs/MPC8323ERDB.h |2 -- include/configs/MPC832XEMDS.h |2 -- include/configs/MPC8349EMDS.h |2 -- include/configs/MPC8360EMDS.h |2 -- include/configs/MPC8360ERDK.h |2 -- include/configs/MPC837XEMDS.h |2 -- include/configs/MPC8540EVAL.h |2 -- include/configs/MVBLUE.h |2 -- include/configs/QS823.h|4 include/configs/QS850.h|4 include/configs/QS860T.h |4 include/configs/Rattler.h |2 -- include/configs/ads5121.h |1 - include/configs/assabet.h |2 -- include/configs/ep8248.h |2 -- include/configs/ep82xxm.h |2 -- include/configs/gcplus.h |2 -- include/configs/gw8260.h |4 include/configs/mgcoge.h |2 -- include/configs/mpc7448hpc2.h |2 -- include/configs/ms7722se.h |1 - include/configs/ms7750se.h |1 - include/configs/ppmc7xx.h |1 - include/configs/pxa255_idp.h |7 --- include/configs/sacsng.h |4 include/configs/sbc8260.h |4 include/configs/sbc8349.h |2 -- 37 files changed, 0 insertions(+), 83 deletions(-) diff --git a/include/configs/AP1000.h b/include/configs/AP1000.h index d490b33..baa9741 100644 --- a/include/configs/AP1000.h +++ b/include/configs/AP1000.h @@ -22,8 +22,6 @@ * (easy to change) */ -#undef DEBUG - #define CONFIG_405 1 /* This is a PPC405 CPU */ #define CONFIG_4xx 1 /* ...member of PPC4xx family */ diff --git a/include/configs/BAB7xx.h b/include/configs/BAB7xx.h index c11e9c9..8ec70aa 100644 --- a/include/configs/BAB7xx.h +++ b/include/configs/BAB7xx.h @@ -28,7 +28,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG #define GTREGREAD(x) 0x /* needed for debug */ /* diff --git a/include/configs/EB+MCF-EV123.h b/include/configs/EB+MCF-EV123.h index dae5295..6e0269b 100644 --- a/include/configs/EB+MCF-EV123.h +++ b/include/configs/EB+MCF-EV123.h @@ -27,7 +27,6 @@ #define CONFIG_EB_MCF_EV123 -#undef DEBUG #undef CFG_HALT_BEFOR_RAM_JUMP #undef ET_DEBUG diff --git a/include/configs/ELPPC.h b/include/configs/ELPPC.h index bb77188..c64537f 100644 --- a/include/configs/ELPPC.h +++ b/include/configs/ELPPC.h @@ -28,7 +28,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG #define GTREGREAD(x) 0x /* needed for debug */ /* diff --git a/include/configs/IP860.h b/include/configs/IP860.h index bd961d8..d2c2ee5 100644 --- a/include/configs/IP860.h +++ b/include/configs/IP860.h @@ -189,7 +189,6 @@ #undef CFG_ENV_IS_IN_FLASH #undef CFG_ENV_IS_IN_NVRAM #undef CFG_ENV_IS_IN_NVRAM -#undef DEBUG_I2C #defineCFG_ENV_IS_IN_EEPROM #ifdef CFG_ENV_IS_IN_NVRAM diff --git a/include/configs/IPHASE4539.h b/include/configs/IPHASE4539.h index 6fee455..bb2c96a 100644 --- a/include/configs/IPHASE4539.h +++ b/include/configs/IPHASE4539.h @@ -30,8 +30,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG /* General debug */ - /*--- * High Level Configuration Options * (easy to change) diff --git a/include/configs/M5235EVB.h b/include/configs/M5235EVB.h index 7f544c8..3b4bff3 100644 --- a/include/configs/M5235EVB.h +++ b/include/configs/M5235EVB.h @@ -37,8 +37,6 @@ #define CONFIG_MCF523x /* define processor family */ #define CONFIG_M5235 /* define processor type */ -#undef DEBUG - #define CONFIG_MCFUART #define CFG_UART_PORT (0) #define CONFIG_BAUDRATE115200 diff --git a/include/configs/M5271EVB.h b/include/configs/M5271EVB.h index 798ec0c..47e1e03 100644 --- a/include/configs/M5271EVB.h +++ b/include/configs/M5271EVB.h @@ -31,8 +31,6 @@ #ifndef _M5271EVB_H #define _M5271EVB_H -#undef DEBUG - /* * High Level Configuration Options (easy to change) */ diff --git a/include/configs/M5329EVB.h b/include/configs/M5329EVB.h index 47d74a3..914ef38 100644 --- a/include/configs/M5329EVB.h +++ b/include/configs/M5329EVB.h @@ -37,8 +37,6 @@ #define CONFIG_MCF532x /* define processor family */ #define CONFIG_M5329 /* define processor
[U-Boot-Users] [PATCH] 83xx: add QE firmware node to device tree
Update 83xx platforms to create the 'firmware' node in the device tree if QE firmware was uploaded. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- This patch provides parity between 83xx and 85xx (which already has this feature). cpu/mpc83xx/fdt.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/cpu/mpc83xx/fdt.c b/cpu/mpc83xx/fdt.c index 909171f..73fe331 100644 --- a/cpu/mpc83xx/fdt.c +++ b/cpu/mpc83xx/fdt.c @@ -58,6 +58,7 @@ void ft_cpu_setup(void *blob, bd_t *bd) bus-frequency, gd-qe_clk, 1); do_fixup_by_compat_u32(blob, fsl,qe, brg-frequency, gd-brg_clk, 1); + fdt_fixup_qe_firmware(blob); #endif #ifdef CFG_NS16550 -- 1.5.2.4 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] Remove #undef DEBUG from MPC83xx board header files
Remove the #undef DEBUG line from all Freescale 83xx board header files. The inclusion of this line makes it impossible to enable debug code in other source files, because #define DEBUG typically needs to be defined before any header files are included. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Added MPC8360ERDK.h. include/configs/MPC8323ERDB.h |2 -- include/configs/MPC832XEMDS.h |2 -- include/configs/MPC8349EMDS.h |2 -- include/configs/MPC8360EMDS.h |2 -- include/configs/MPC8360ERDK.h |2 -- include/configs/MPC837XEMDS.h |2 -- 6 files changed, 0 insertions(+), 12 deletions(-) diff --git a/include/configs/MPC8323ERDB.h b/include/configs/MPC8323ERDB.h index 4ea8709..0e33fce 100644 --- a/include/configs/MPC8323ERDB.h +++ b/include/configs/MPC8323ERDB.h @@ -9,8 +9,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG - /* * High Level Configuration Options */ diff --git a/include/configs/MPC832XEMDS.h b/include/configs/MPC832XEMDS.h index 25ac58c..8cf0a5b 100644 --- a/include/configs/MPC832XEMDS.h +++ b/include/configs/MPC832XEMDS.h @@ -20,8 +20,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG - /* * High Level Configuration Options */ diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h index 437a9a5..2c6534c 100644 --- a/include/configs/MPC8349EMDS.h +++ b/include/configs/MPC8349EMDS.h @@ -29,8 +29,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG - /* * High Level Configuration Options */ diff --git a/include/configs/MPC8360EMDS.h b/include/configs/MPC8360EMDS.h index fdacb90..310d03f 100644 --- a/include/configs/MPC8360EMDS.h +++ b/include/configs/MPC8360EMDS.h @@ -22,8 +22,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG - /* * High Level Configuration Options */ diff --git a/include/configs/MPC8360ERDK.h b/include/configs/MPC8360ERDK.h index 0f6f8f1..72d36c1 100644 --- a/include/configs/MPC8360ERDK.h +++ b/include/configs/MPC8360ERDK.h @@ -17,8 +17,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG - /* * High Level Configuration Options */ diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h index 2b84e9c..61de084 100644 --- a/include/configs/MPC837XEMDS.h +++ b/include/configs/MPC837XEMDS.h @@ -21,8 +21,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#undef DEBUG - /* * High Level Configuration Options */ -- 1.5.2.4 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
