Re: [U-Boot] [PATCH] 0/12 Multiadapter/multibus I2C
Hello ksi,
k...@koi8.net wrote:
On Sat, 14 Feb 2009, Heiko Schocher wrote:
Hello ksi,
k...@koi8.net wrote:
On Fri, 13 Feb 2009, Heiko Schocher wrote:
k...@koi8.net wrote:
Here is the second attempt for initial portion of multibus/multiadapter
I2C support.
Can you please send your patches with some better commit messages.
You only send your Signed-off-by, without any explanation. Please
change this.
There is not much sense in extensive commit messages in this case, IMHO. It
is not a bug fix or added feature at one particular place; it is a major
rework. The only message I can give is something like Changes for
multiadapter/multibus I2C support...
I'll add it to the second attempt that I will make later today.
This includes a set of common files, all drivers in drivers/i2c and all
boards affected by these changes (config files, board files, and lib_xx
files.)
There is an illustrative example of multiadapter multibus I2C config in
MPC8548CDS.h config file (#if 0'd.) Definitions in that example are
bogus so please don't expect it to work. It will compile though...
This set also includes big rework for soft_i2c.c that makes it template
version that allows up to 4 bitbanged adapters. This number can be
Didn;t you try my suggestion? This is a really big define monster now,
which I think, we can avoid, and without to change nearly all lines of
the existing driver.
We can not avoid it. At least I can not see an easy way to do this. SOFT_I2C
Yes, we can. Look again deeper in my approach, this _is_ an easy way!
I also looked again in your changes in the fsl_i2c.c driver, and we
can make this also simplier, by using cur_adap_nr-hwadapnr!
OK, please explain how that cur_adap_nr-hwadapnr gets assigned. Please also
When running from ram, this is no problem. It should be set in
i2c_set_bus_num().
explain how can one invoke a function on other adapter than current.
Is this needed? If so, you must before call a i2c_set_bus_num(), and after
you finished call it again with the old busnumber. So it is done for example
in do_date () common/cmd_date.c
Remember, i2c_init is quite often called BEFORE the code is relocated to RAM
so you can NOT change current adapter.
Yes, thats a point. But do we need this before running from ram (except
one hardwareadapter)?
Please also note that you will loose a capability of working with more than
one adapter before the code is relocated to RAM.
Do we really need this?
We have not to define for both hardware adapter each function in
i2c_adap_t! For example:
You did:
static void fsl_i2c1_init(int speed, int slaveadd)
{
__i2c_init(0, speed, slaveadd);
}
instead we only need
i2c_init(cur_adap_nr-hwadapnr, speed, slaveadd);
with
i2c_adap_t fsl_i2c_adap[] = {
{
.init = i2c_init,
[...]
.hwadapnr = 0,
.name = FSL_NAME(CONFIG_SYS_FSL_I2C_OFFSET)
},
#ifdef CONFIG_SYS_FSL_I2C2_OFFSET
{
.init = i2c_init,
[...]
.hwadapnr = 1,
.name = FSL_NAME(CONFIG_SYS_FSL_I2C2_OFFSET)
},
#endif
It would've been easy if we had had this pointer. That would allow us to
find out what adapter we are running on by using something like
this-hwadapnr. Unfortunately we do NOT have such a pointer, we're plain
C. Function in a structure does not have a way to find out how to access a
member of that structure. The only way to somehow find which hwadapnr we
are running at is using a global variable, cur_i2c_bus as a starting point.
But that is meaningless until the code is relocated to RAM and that variable
became writable. And that robs us of added possibility of using any adapter
other than a single one preset in config file before relocating to RAM.
Yes, I know. But again, do we need this?
That is if we want to keep the original I2C API. The other, simpler way is
to add an argument to each and every function, a pointer to i2c_adap_t
structure or its index or something similar. But that defeats the entire
purpose of this code by requiring to find and change each and every call to
any I2C function in the entire U-Boot source thus totally breaking ALL
existing code 99.99% of which only use single I2C adapter/bus...
That would be a hard way.
Please change this driver also!
I can't. Please read above.
If I think more, we never even need to change the function parameters
like you did for example for i2c_int ()! We can use at the beginning
of every function who go in i2c_adap_t, the cur_adap_nr-hwadapnr
and make the settings we need for this function... and wow we saved
one function parameter.
Devil is in the details... Please read above.
Thats why we discuss it ;-)
is special.
[U-Boot] How to implement a starting logo
Hi all, I want to display a starting logo on LCD when my board power up, does anyone has done this work on a ARM9 board. The U-Boot version I using is 1.1.1, the processor is AT91RM9200, and the display controller is SAMSUNG S1D13506. Can I implement this if I add SPLSH SCREEN support according to the U-Boot document README. Any suggestion will be helpful! Best regards, Lizhihao ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-usb
The following changes since commit 6b67962fd69ac0bcdf1a982669a029c2f0a7bcc1: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-ppc4xx are available in the git repository at: git://git.denx.de/u-boot-usb.git master Abraham, Thomas (1): USB: Remove LUN number from CDB Atin Malaviya (1): Added usbtty_configured() check. Fixed attribute(packed) warnings. common/usb_storage.c|5 - drivers/serial/usbtty.c | 18 +++--- 2 files changed, 11 insertions(+), 12 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to implement a starting logo
Dear =?gb2312?B?wO7WvrrG?=, In message blu144-w18e695cd5da276c42b0048dc...@phx.gbl you wrote: I want to display a starting logo on LCD when my board power up, does anyone has done this work on a ARM9 board. The U-Boot version I using is 1.1.1, the processor is AT91RM9200, and the display controller is SAMSUNG S1D13506. Can I implement this if I add SPLSH SCREEN support according to the U-Boot document README. Indeed splash screen is the feature to look for - but probably only after updating ypur code to a recent version. U-Boot 1.1.1 is prehistroic and unsupported. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Cleanup PMC405 board support
This patch fixes coding style for PMC405 board support.
Also some unneeded features/code is removed.
Signed-off-by: Matthias Fuchs matthias.fu...@esd-electronics.com
---
board/esd/pmc405/pmc405.c | 95 ---
include/configs/PMC405.h | 285 ++---
2 files changed, 165 insertions(+), 215 deletions(-)
diff --git a/board/esd/pmc405/pmc405.c b/board/esd/pmc405/pmc405.c
index 975b6d6..dd58d01 100644
--- a/board/esd/pmc405/pmc405.c
+++ b/board/esd/pmc405/pmc405.c
@@ -40,7 +40,6 @@ const unsigned char fpgadata[] =
};
int filesize = sizeof(fpgadata);
-
int board_early_init_f (void)
{
/*
@@ -55,23 +54,23 @@ int board_early_init_f (void)
* IRQ 30 (EXT IRQ 5) PCI INTA; active low; level sensitive
* IRQ 31 (EXT IRQ 6) COMPACT FLASH; active high; level sensitive
*/
- mtdcr(uicsr, 0x); /* clear all ints */
- mtdcr(uicer, 0x); /* disable all ints */
- mtdcr(uiccr, 0x); /* set all to be non-critical*/
- mtdcr(uicpr, 0xFF81); /* set int polarities */
- mtdcr(uictr, 0x1000); /* set int trigger levels */
- mtdcr(uicvcr, 0x0001); /* set vect base=0,INT0 highest
priority*/
- mtdcr(uicsr, 0x); /* clear all ints */
+ mtdcr(uicsr, 0x); /* clear all ints */
+ mtdcr(uicer, 0x); /* disable all ints */
+ mtdcr(uiccr, 0x); /* set all to be non-critical*/
+ mtdcr(uicpr, 0xFF81); /* set int polarities */
+ mtdcr(uictr, 0x1000); /* set int trigger levels */
+ mtdcr(uicvcr, 0x0001); /* set vect base=0, INT0 highest priority */
+ mtdcr(uicsr, 0x); /* clear all ints */
/*
-* EBC Configuration Register: set ready timeout to 512 ebc-clks - ca.
15 us
+* EBC Configuration Register:
+* set ready timeout to 512 ebc-clks - ca. 15 us
*/
mtebc (epcr, 0xa840);
/*
* Setup GPIO pins
*/
-
mtdcr(cntrl0, mfdcr(cntrl0) | ((CONFIG_SYS_FPGA_INIT | \
CONFIG_SYS_FPGA_DONE | \
CONFIG_SYS_XEREADY | \
@@ -85,26 +84,26 @@ int board_early_init_f (void)
}
out32(GPIO0_OR, 0);
- out32(GPIO0_TCR, CONFIG_SYS_FPGA_PRG | CONFIG_SYS_FPGA_CLK |
CONFIG_SYS_FPGA_DATA | CONFIG_SYS_XEREADY); /* setup for output */
+ /* setup for output */
+ out32(GPIO0_TCR, CONFIG_SYS_FPGA_PRG | CONFIG_SYS_FPGA_CLK | \
+ CONFIG_SYS_FPGA_DATA | CONFIG_SYS_XEREADY);
- /* - check if rev1_2 is low, then:
-* - set/reset CONFIG_SYS_INTA_FAKE/CONFIG_SYS_SELF_RST in TCR to
assert INTA# or SELFRST#
+ /*
+* - check if rev1_2 is low, then:
+* - set/reset CONFIG_SYS_INTA_FAKE/CONFIG_SYS_SELF_RST
+* in TCR to assert INTA# or SELFRST#
*/
-
return 0;
}
-
-/* - */
-
-
int misc_init_r (void)
{
/* adjust flash start and offset */
gd-bd-bi_flashstart = 0 - gd-bd-bi_flashsize;
gd-bd-bi_flashoffset = 0;
- out32(GPIO0_OR, in32(GPIO0_OR) | CONFIG_SYS_XEREADY); /* deassert
EREADY# */
+ /* deassert EREADY# */
+ out32(GPIO0_OR, in32(GPIO0_OR) | CONFIG_SYS_XEREADY);
return (0);
}
@@ -113,16 +112,16 @@ ushort pmc405_pci_subsys_deviceid(void)
ulong val;
val = in32(GPIO0_IR);
if (!(val CONFIG_SYS_REV1_2)) { /* low=rev1.2 */
- if (val CONFIG_SYS_NONMONARCH) { /* monarch# signal */
+ /* check monarch# signal */
+ if (val CONFIG_SYS_NONMONARCH)
return CONFIG_SYS_PCI_SUBSYS_DEVICEID_NONMONARCH;
- }
return CONFIG_SYS_PCI_SUBSYS_DEVICEID_MONARCH;
}
return CONFIG_SYS_PCI_SUBSYS_DEVICEID_NONMONARCH;
}
/*
- * Check Board Identity:
+ * Check Board Identity
*/
int checkboard (void)
{
@@ -133,29 +132,25 @@ int checkboard (void)
puts (Board: );
- if (i == -1) {
+ if (i == -1)
puts (### No HW ID - assuming PMC405);
- } else {
+ else
puts(str);
- }
val = in32(GPIO0_IR);
if (!(val CONFIG_SYS_REV1_2)) { /* low=rev1.2 */
puts( rev1.2 ();
- if (val CONFIG_SYS_NONMONARCH) { /* monarch# signal */
+ if (val CONFIG_SYS_NONMONARCH) /* monarch# signal */
puts(non-);
- }
puts(monarch));
- } else {
+ } else
puts( =rev1.1);
- }
putc ('\n');
return 0;
}
-/* - */
void reset_phy(void)
{
#ifdef CONFIG_LXT971_NO_SLEEP
@@ -166,43 +161,3 @@ void reset_phy(void)
[U-Boot] [PATCH] ppc4xx: Update PMC405 board support
This patch prepares the good old PMC405 board support for
upcoming PMC405V2 patches.
Signed-off-by: Matthias Fuchs matthias.fu...@esd-electronics.com
---
board/esd/pmc405/config.mk |6 +
board/esd/pmc405/pmc405.c | 18 +++--
include/configs/PMC405.h | 58 ++--
3 files changed, 40 insertions(+), 42 deletions(-)
diff --git a/board/esd/pmc405/config.mk b/board/esd/pmc405/config.mk
index fc2794d..5a3fc4b 100644
--- a/board/esd/pmc405/config.mk
+++ b/board/esd/pmc405/config.mk
@@ -21,8 +21,4 @@
# MA 02111-1307 USA
#
-#
-# esd PMC405 boards
-#
-
-TEXT_BASE = 0xFFFC
+TEXT_BASE = 0xFFF8
diff --git a/board/esd/pmc405/pmc405.c b/board/esd/pmc405/pmc405.c
index dd58d01..10e7ce4 100644
--- a/board/esd/pmc405/pmc405.c
+++ b/board/esd/pmc405/pmc405.c
@@ -2,7 +2,7 @@
* (C) Copyright 2001-2003
* Stefan Roese, DENX Software Engineering, s...@denx.de.
*
- * (C) Copyright 2005
+ * (C) Copyright 2005-2009
* Matthias Fuchs, esd gmbh germany, matthias.fu...@esd-electronics.com
*
* See file CREDITS for list of people who contributed to this
@@ -26,6 +26,7 @@
#include common.h
#include asm/processor.h
+#include asm/io.h
#include command.h
#include malloc.h
@@ -77,16 +78,16 @@ int board_early_init_f (void)
CONFIG_SYS_NONMONARCH | \
CONFIG_SYS_REV1_2) 5));
- if (!(in32(GPIO0_IR) CONFIG_SYS_REV1_2)) {
+ if (!(in_be32((void*)GPIO0_IR) CONFIG_SYS_REV1_2)) {
/* rev 1.2 boards */
mtdcr(cntrl0, mfdcr(cntrl0) | ((CONFIG_SYS_INTA_FAKE | \
CONFIG_SYS_SELF_RST) 5));
}
- out32(GPIO0_OR, 0);
+ out_be32((void*)GPIO0_OR, CONFIG_SYS_VPEN);
/* setup for output */
- out32(GPIO0_TCR, CONFIG_SYS_FPGA_PRG | CONFIG_SYS_FPGA_CLK | \
- CONFIG_SYS_FPGA_DATA | CONFIG_SYS_XEREADY);
+ out_be32((void*)GPIO0_TCR, CONFIG_SYS_FPGA_PRG | CONFIG_SYS_FPGA_CLK | \
+ CONFIG_SYS_FPGA_DATA | CONFIG_SYS_XEREADY | CONFIG_SYS_VPEN);
/*
* - check if rev1_2 is low, then:
@@ -103,14 +104,15 @@ int misc_init_r (void)
gd-bd-bi_flashoffset = 0;
/* deassert EREADY# */
- out32(GPIO0_OR, in32(GPIO0_OR) | CONFIG_SYS_XEREADY);
+ out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) | CONFIG_SYS_XEREADY);
return (0);
}
ushort pmc405_pci_subsys_deviceid(void)
{
ulong val;
- val = in32(GPIO0_IR);
+ val = in_be32((void*)GPIO0_IR);
if (!(val CONFIG_SYS_REV1_2)) { /* low=rev1.2 */
/* check monarch# signal */
if (val CONFIG_SYS_NONMONARCH)
@@ -137,7 +139,7 @@ int checkboard (void)
else
puts(str);
- val = in32(GPIO0_IR);
+ val = in_be32((void*)GPIO0_IR);
if (!(val CONFIG_SYS_REV1_2)) { /* low=rev1.2 */
puts( rev1.2 ();
if (val CONFIG_SYS_NONMONARCH) /* monarch# signal */
diff --git a/include/configs/PMC405.h b/include/configs/PMC405.h
index 7fbdeb0..c598d00 100644
--- a/include/configs/PMC405.h
+++ b/include/configs/PMC405.h
@@ -40,11 +40,20 @@
#define CONFIG_BAUDRATE9600
#define CONFIG_BOOTDELAY 3 /* autoboot after 3 seconds */
+/* Only interrupt boot if space is pressed. */
+#define CONFIG_AUTOBOOT_KEYED 1
+#define CONFIG_AUTOBOOT_PROMPT \
+ Press SPACE to abort autoboot in %d seconds\n, bootdelay
+#undef CONFIG_AUTOBOOT_DELAY_STR
+#define CONFIG_AUTOBOOT_STOP_STR
+
#undef CONFIG_BOOTARGS
#undef CONFIG_BOOTCOMMAND
#define CONFIG_PREBOOT /* enable preboot variable */
+#define CFG_BOOTM_LEN 0x100 /* support booting of huge images */
+
#define CONFIG_LOADS_ECHO 1 /* echo on for serial download */
#define CONFIG_SYS_LOADS_BAUD_CHANGE 1 /* allow baudrate change*/
@@ -106,7 +115,7 @@
#if defined(CONFIG_CMD_KGDB)
#define CONFIG_SYS_CBSIZE 1024/* Console I/O Buffer Size */
#else
-#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */
+#define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */
#endif
#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
#define CONFIG_SYS_MAXARGS 16 /* max number of command args */
@@ -122,18 +131,18 @@
#define CONFIG_SYS_MEMTEST_END 0x0C0 /* 4 ... 12 MB in DRAM */
#undef CONFIG_SYS_EXT_SERIAL_CLOCK /* no external serial clock */
-#define CONFIG_SYS_BASE_BAUD 691200
+#define CONFIG_SYS_BASE_BAUD 806400
/* The following table includes the supported baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE \
- { 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, \
-57600, 115200, 230400, 460800, 921600 }
+ {300, 600, 1200, 2400, 4800, 9600, 19200, 38400,
[U-Boot] [PATCH] fpga: Fix Spartan II FPGA booting
This patch does some minor fixing of the Xilinx Spartan II
FPGA boot code:
- Fixed call order of post configuration callback and
success message printing (result of copy-paste?)
- relocate post configuration callback only when it
is implemented
- remove obsolete comment
- minor coding style cleanup
Signed-off-by: Matthias Fuchs matthias.fu...@esd-electronics.com
---
drivers/fpga/spartan2.c | 32 +++-
1 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/fpga/spartan2.c b/drivers/fpga/spartan2.c
index f5ba7fc..d745334 100644
--- a/drivers/fpga/spartan2.c
+++ b/drivers/fpga/spartan2.c
@@ -260,8 +260,6 @@ static int Spartan2_sp_load (Xilinx_desc * desc, void *buf,
size_t bsize)
ts = get_timer (0); /* get current time */
ret_val = FPGA_SUCCESS;
while ((*fn-done) (cookie) == FPGA_FAIL) {
- /* XXX - we should have a check in here somewhere to
-* make sure we aren't busy forever... */
CONFIG_FPGA_DELAY ();
(*fn-clk) (FALSE, TRUE, cookie); /* Deassert the
clock pin */
@@ -276,23 +274,18 @@ static int Spartan2_sp_load (Xilinx_desc * desc, void
*buf, size_t bsize)
}
}
- if (ret_val == FPGA_SUCCESS) {
-#ifdef CONFIG_SYS_FPGA_PROG_FEEDBACK
- puts (Done.\n);
-#endif
- }
/*
* Run the post configuration function if there is one.
*/
- if (*fn-post) {
+ if (*fn-post)
(*fn-post) (cookie);
- }
- else {
#ifdef CONFIG_SYS_FPGA_PROG_FEEDBACK
+ if (ret_val == FPGA_SUCCESS)
+ puts (Done.\n);
+ else
puts (Fail.\n);
#endif
- }
} else {
printf (%s: NULL Interface function table!\n, __FUNCTION__);
@@ -412,8 +405,10 @@ static int Spartan2_sp_reloc (Xilinx_desc * desc, ulong
reloc_offset)
addr = (ulong) (fn-abort) + reloc_offset;
fn_r-abort = (Xilinx_abort_fn) addr;
- addr = (ulong) (fn-post) + reloc_offset;
- fn_r-post = (Xilinx_post_fn) addr;
+ if (fn-post) {
+ addr = (ulong) (fn-post) + reloc_offset;
+ fn_r-post = (Xilinx_post_fn) addr;
+ }
fn_r-relocated = TRUE;
@@ -541,8 +536,6 @@ static int Spartan2_ss_load (Xilinx_desc * desc, void *buf,
size_t bsize)
(*fn-wr) (TRUE, TRUE, cookie);
while (! (*fn-done) (cookie)) {
- /* XXX - we should have a check in here somewhere to
-* make sure we aren't busy forever... */
CONFIG_FPGA_DELAY ();
(*fn-clk) (FALSE, TRUE, cookie); /* Deassert the
clock pin */
@@ -562,17 +555,14 @@ static int Spartan2_ss_load (Xilinx_desc * desc, void
*buf, size_t bsize)
/*
* Run the post configuration function if there is one.
*/
- if (*fn-post) {
+ if (*fn-post)
(*fn-post) (cookie);
- }
#ifdef CONFIG_SYS_FPGA_PROG_FEEDBACK
- if (ret_val == FPGA_SUCCESS) {
+ if (ret_val == FPGA_SUCCESS)
puts (Done.\n);
- }
- else {
+ else
puts (Fail.\n);
- }
#endif
} else {
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fpga: Fix Spartan III FPGA booting
This patch does some minor fixing of the Xilinx Spartan III
FPGA boot code:
- Fixed call order of post configuration callback and
success message printing (result of copy-paste?)
- remove obsolete comment
- minor coding style cleanup
Signed-off-by: Matthias Fuchs matthias.fu...@esd-electronics.com
---
drivers/fpga/spartan3.c | 22 +++---
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/fpga/spartan3.c b/drivers/fpga/spartan3.c
index 9ce41f1..8bb2449 100644
--- a/drivers/fpga/spartan3.c
+++ b/drivers/fpga/spartan3.c
@@ -281,23 +281,18 @@ static int Spartan3_sp_load (Xilinx_desc * desc, void
*buf, size_t bsize)
}
}
- if (ret_val == FPGA_SUCCESS) {
-#ifdef CONFIG_SYS_FPGA_PROG_FEEDBACK
- puts (Done.\n);
-#endif
- }
/*
* Run the post configuration function if there is one.
*/
- if (*fn-post) {
+ if (*fn-post)
(*fn-post) (cookie);
- }
- else {
#ifdef CONFIG_SYS_FPGA_PROG_FEEDBACK
+ if (ret_val == FPGA_SUCCESS)
+ puts (Done.\n);
+ else
puts (Fail.\n);
#endif
- }
} else {
printf (%s: NULL Interface function table!\n, __FUNCTION__);
@@ -567,17 +562,14 @@ static int Spartan3_ss_load (Xilinx_desc * desc, void
*buf, size_t bsize)
/*
* Run the post configuration function if there is one.
*/
- if (*fn-post) {
+ if (*fn-post)
(*fn-post) (cookie);
- }
#ifdef CONFIG_SYS_FPGA_PROG_FEEDBACK
- if (ret_val == FPGA_SUCCESS) {
+ if (ret_val == FPGA_SUCCESS)
puts (Done.\n);
- }
- else {
+ else
puts (Fail.\n);
- }
#endif
} else {
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Please pull git://git.denx.de/u-boot-i2c.git
Dear Heiko Schocher,
In message 4993d54c.2010...@denx.de you wrote:
The following changes since commit f15c6515fc23f83c51f3de272ca23d86b80e81b1:
Wolfgang Denk (1):
Coding style cleanup; update CHANGELOG
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
Mike Frysinger (1):
i2c.h: drop i2c_reg_{read, write} hack for Blackfin parts
include/i2c.h | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Brain fried - Core dumped
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Please pull git://git.denx.de/u-boot-i2c.git
Dear Heiko Schocher,
In message 499689a8.8080...@denx.de you wrote:
The following changes since commit f15c6515fc23f83c51f3de272ca23d86b80e81b1:
Wolfgang Denk (1):
Coding style cleanup; update CHANGELOG
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
Guennadi Liakhovetski (1):
i.MX31: Start the I2C clock on driver initialisation
Mike Frysinger (1):
i2c.h: drop i2c_reg_{read, write} hack for Blackfin parts
drivers/i2c/mxc_i2c.c |6 ++
include/i2c.h | 14 --
2 files changed, 6 insertions(+), 14 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Genitiv ins Wasser, weil's Dativ ist!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-usb
Dear Remy Bohmer, In message 3efb10970902150818vb2ab3beueb814c6f76007...@mail.gmail.com you wrote: The following changes since commit 6b67962fd69ac0bcdf1a982669a029c2f0a7bcc1: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-ppc4xx are available in the git repository at: git://git.denx.de/u-boot-usb.git master Abraham, Thomas (1): USB: Remove LUN number from CDB Atin Malaviya (1): Added usbtty_configured() check. Fixed attribute(packed) warnings. common/usb_storage.c|5 - drivers/serial/usbtty.c | 18 +++--- 2 files changed, 11 insertions(+), 12 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Vitesse Phy not recognized VSC8211
Andy Fleming wrote: On Fri, Feb 13, 2009 at 6:36 AM, hendrik hendrik.vast...@gmail.com wrote: Hi all When i included the struct as is the my board with the MPC8548 ver1 cpu worked correctly but the board with ver2 CPU does not work. A would appeciate any help In what way does it not work? the cpu version shouldn't affect PHY recognition. Is the board different? Does it have different PHYs? On both boards (CPU v1 and CPU v2 ) the phys are detected as the Vitesse VSC821, but someware in the the miiphy_register function in miiphyutil.c thinkgs go wrong on the board with the v2 CPU. The first symptom was the mesage: miiphy_register: non unique device name on deeper investigation i found that the phy names were jumbled garbage, as the lines below show: the NET name should reed Tsec0. PHY is Vitesse VSC8211 (fc4b1) miiphy_register: added '��...@��v|�� ��n', read=0x1ffb2e7c, write=0x1ffb2e14 after a bit more digging I now thing the problem is in the Memory manager of the CPU but i do not know how to go about finding the problem. My first step is to look at the DDR setup then try to understand the differences between the v1 and v2 CPUs If you have any links or help i would greatly appreciate it. thanks hedrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] tftp not working
Hi All, I have compiled u-boot-nand.bin for the canyonlands board.I flashed this image onto the nand flash and did a boot from NAND.I interrupted the u-boot and tried to do a tftp. But i get this error : No ethernet found. Could someone tell me where to enable ethernet in the u-boot source code? Regards, Afzal Nadirshah http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4
On Sun, 15 Feb 2009, Heiko Schocher wrote:
Hello ksi,
k...@koi8.net wrote:
On Sat, 14 Feb 2009, Heiko Schocher wrote:
Hello ksi,
k...@koi8.net wrote:
On Fri, 13 Feb 2009, Heiko Schocher wrote:
k...@koi8.net wrote:
Signed-off-by: Sergey Kubushyn k...@koi8.net
---
diff -purN u-boot-i2c.orig/drivers/i2c/soft_i2c.c
u-boot-i2c/drivers/i2c/soft_i2c.c
--- u-boot-i2c.orig/drivers/i2c/soft_i2c.c 2009-02-12
10:43:41.0 -0800
+++ u-boot-i2c/drivers/i2c/soft_i2c.c 2009-02-12 10:46:00.0
-0800
@@ -1,4 +1,8 @@
/*
+ * Copyright (c) 2009 Sergey Kubushyn k...@koi8.net
+ *
+ * Changes for multibus/multiadapter I2C support.
+ *
* (C) Copyright 2001, 2002
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
[...]
The following patch is based on your patches without 7/12 and
adds multibus support for the soft_i2c driver without doing such
a big change as you did. Maybe it is not yet perfect, because
it is just a fast try, but I think we should go this way. What
do you/others think?
The reason behind this patch is making SEVERAL different SOFT_I2C ADAPTERS
available. Not BUSSES but separate PHYSICAL I2C ADAPTERS made of different
pin pairs from different chips.
This you can also do with my suggestion ...
OK, please explain how are you going to make different functions for
different adapters? Let's say you want to use 2 on-SoC GPIO pins for
You can do now the following for example in your
include/configs/MPC8548CDS.h example:
you only have to define
#define I2C_SDA(bit) (printf(hwadap: %d sda1: %d,
cur_adap_nr-hwadapnr, bit))
if this is a real driver you can make a function in your board code
say (just a fast thought):
void i2c_soft_sda (int bit)
{
switch(cur_adap_nr-hwadapnr) {
case 0:
/* adapter specfic code 0 */
break;
case 1:
/* adapter specfic code 1 */
break;
[...]
}
}
and define in config file
#define I2C_SDA(bit) i2c_soft_sda (bit)
That means you have to make changes in two places instead of one -- config
file AND $(BOARD).c. Also you use functions instead of macros and you can
Yes. But that was just a thought, it should be possible to do this also
in macros.
Not if you want to make functions in $(BOARD).c.
NOT make them inline because they come from a separate object file. This
essentially defeats the very purpose of that common soft_i2c.c driver. If
you want to make functions for bitbanged I2C into the $(BOARD).c there is no
reason to have them as a base for that driver. It is much more logical to do
Maybe more logical, but not needed.
everything in reverse, i.e. instead of having soft_i2c.c as a bona fide
drivers and those I2C_SDA and friends as its building blocks make those
i2c_soft_sda() etc. in each and every $(BOARD).c into primary entities and
build the actual driver in the $(BOARD).c itself. Just convert that
soft_i2c.c into a header file with macros for real functions (soft_i2c_read
etc.) and instantiate them in the $(BOARD).c.
The only problem with that is it breaks uniformity and makes another mess.
Just, if we do this, but we don;t need to do it so.
The whole idea was to bring _ALL_ I2C drivers to a single place and make
them totally transparent and uniform. Something like e.g. Linux VFS.
And remember, the devil is in details. How are you going to assign
(initialize) that innocent looking cur_adap_nr-hwadapnr? How are you
going to work on an adapter other that current in a situation when you can
NOT change current adapter (e.g. perform all I2C layer initialization
while still running from flash?) Remember, this is plain C and there is no
Yes, good point. But do we need more then one i2c adapter when running
from flash? I see only one reason to use i2c when running from flash:
accessing SPD EEprom ... and this bus could always be the first
hw adapter. All other accesses to i2c should be moved to run when
we are in ram.
You can have, e.g. TWO SPD EEPROMs on different busses. And please remember
that infamous 640K ought to be enough for anybody...
this pointer... And that is just a tip of an iceberg...
And the million dollar question -- what is the potential gain?
I want to avoid such a big change in soft_i2c.c. Also if you have
4 bitbang instances with your version you have 3 times more code.
There is almost NO change in soft_i2c.c. It is simply templetized and 4
#ifdef'ed instances are added. If you only have one bitbanged adapter in the
system it generates _EXACTLY_ the same source code as original one did after
CPP pass.
But if others are on your side, I have no problem with your approach.
I don't think there is a viable reason
Re: [U-Boot] tftp not working
Dear Afzal Nadirshah, In message 174230991e95d743b0c91df471ef44e8434329c...@mtw02msg02.mindtree.com you wrote: I have compiled u-boot-nand.bin for the canyonlands board.I flashed this image onto the nand flash and did a boot from NAND.I interrupted the u-boot and tried to do a tftp. But i get this error : No ethernet found. Could someone tell me where to enable ethernet in the u-boot source code? You probably forgot to set a MAC address (ethaddr environment variable). Set one, then saveenv, then reset, then try again. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Data is a lot like humans: It is born. Matures. Gets married to other data, divorced. Gets old. One thing that it doesn't do is die. It has to be killed. - Arthur Miller ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 0/12 Multiadapter/multibus I2C
On Sun, 15 Feb 2009, Heiko Schocher wrote:
Hello ksi,
k...@koi8.net wrote:
On Sat, 14 Feb 2009, Heiko Schocher wrote:
Hello ksi,
k...@koi8.net wrote:
On Fri, 13 Feb 2009, Heiko Schocher wrote:
k...@koi8.net wrote:
Here is the second attempt for initial portion of multibus/multiadapter
I2C support.
Can you please send your patches with some better commit messages.
You only send your Signed-off-by, without any explanation. Please
change this.
There is not much sense in extensive commit messages in this case, IMHO.
It
is not a bug fix or added feature at one particular place; it is a major
rework. The only message I can give is something like Changes for
multiadapter/multibus I2C support...
I'll add it to the second attempt that I will make later today.
This includes a set of common files, all drivers in drivers/i2c and all
boards affected by these changes (config files, board files, and lib_xx
files.)
There is an illustrative example of multiadapter multibus I2C config in
MPC8548CDS.h config file (#if 0'd.) Definitions in that example are
bogus so please don't expect it to work. It will compile though...
This set also includes big rework for soft_i2c.c that makes it template
version that allows up to 4 bitbanged adapters. This number can be
Didn;t you try my suggestion? This is a really big define monster now,
which I think, we can avoid, and without to change nearly all lines of
the existing driver.
We can not avoid it. At least I can not see an easy way to do this.
SOFT_I2C
Yes, we can. Look again deeper in my approach, this _is_ an easy way!
I also looked again in your changes in the fsl_i2c.c driver, and we
can make this also simplier, by using cur_adap_nr-hwadapnr!
OK, please explain how that cur_adap_nr-hwadapnr gets assigned. Please also
When running from ram, this is no problem. It should be set in
i2c_set_bus_num().
Yep. But nobody's perfect and you can have a situation when you need to
access several busses before relocation. It is not hardware for U-Boot, it
is U-Boot for hardware. When hardware designers design their hardware they
don't make their decisions based on U-Boot limitation. That is us who should
accomodate what they designed.
There is also another consideration -- when having several adapters which
one should be initialized at boot time, before relocation? Another problem
is init() function that can be unique for each adapter. To make the lower
layer transparent I'm reprogramming muxes if any when switching busses. It
is necessary to make I2C API simple and uniform between muxed and non-muxed
busses. That essentially means that we can NOT do i2c_set_bus_num() to
execute init() for a particular adapter -- adapter MUST be initialized for
i2c_set_bus_num() to succeed.
Your suggestion requires total LOGIC change.
explain how can one invoke a function on other adapter than current.
Is this needed? If so, you must before call a i2c_set_bus_num(), and after
you finished call it again with the old busnumber. So it is done for example
in do_date () common/cmd_date.c
You can not do it before all adapters are initialized. And you WON'T be able
to initialize adapters because you will not be able to switch busses.
Remember, i2c_init is quite often called BEFORE the code is relocated to RAM
so you can NOT change current adapter.
Yes, thats a point. But do we need this before running from ram (except
one hardwareadapter)?
Yes, see above.
Please also note that you will loose a capability of working with more than
one adapter before the code is relocated to RAM.
Do we really need this?
Eh, 640K ought to be enough to anybody...
We have not to define for both hardware adapter each function in
i2c_adap_t! For example:
You did:
static void fsl_i2c1_init(int speed, int slaveadd)
{
__i2c_init(0, speed, slaveadd);
}
instead we only need
i2c_init(cur_adap_nr-hwadapnr, speed, slaveadd);
with
i2c_adap_t fsl_i2c_adap[] = {
{
.init = i2c_init,
[...]
.hwadapnr = 0,
.name = FSL_NAME(CONFIG_SYS_FSL_I2C_OFFSET)
},
#ifdef CONFIG_SYS_FSL_I2C2_OFFSET
{
.init = i2c_init,
[...]
.hwadapnr = 1,
.name = FSL_NAME(CONFIG_SYS_FSL_I2C2_OFFSET)
},
#endif
It would've been easy if we had had this pointer. That would allow us to
find out what adapter we are running on by using something like
this-hwadapnr. Unfortunately we do NOT have such a pointer, we're plain
C. Function in a structure does not have a way to find out how to access a
member of that structure. The only way to somehow find which hwadapnr we
are running at is using a
