Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY
Hi Stefan and Victor,
Stefan Roese wrote:
On Wednesday 03 September 2008, Victor Gallardo wrote:
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
A good idea is to keep a history of what changed in the patch revisions here
in this area (after the ---). Something like:
v2:
- Added comments to GPCS PHY setup
- Minor coding style cleanup
v3:
- Generalized the PHY-less configuration even more
Please find some more comments below.
cpu/ppc4xx/4xx_enet.c | 162
- cpu/ppc4xx/miiphy.c |
41 -
include/ppc4xx_enet.h |3 +
3 files changed, 201 insertions(+), 5 deletions(-)
diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..e137bac 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -198,6 +198,7 @@
#define BI_PHYMODE_RMII 8
#endif
#endif
+#define BI_PHYMODE_SGMII 9
#if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
@@ -216,6 +217,52 @@
#define MAL_RX_CHAN_MUL 1
#endif
+/*+
+ * PHY-less support for Ethernet Ports.
+ **/
+
+/*
+ * Some boards do not have a PHY for each ethernet port.
+ * For example on Arches board (2 CPU system) eth0 does not have
+ * a PHY, both CPU's are wired directly together (AC coupled)
+ * using SGMII0.
+ *
+ * In these cases :
+ *1) set the appropriate CONFIG_PHY_ADDR equal to CONFIG_PHY_LESS
+ * to detect that the specified ethernet port does not have a PHY.
+ *2) Then define CFG_PHY_LESS_PORT and CFG_PHY_LESS_PORTS in board
+ * configuration file. For example on the Arches board we would do
+ * the following.
+ * #define CFG_PHY_LESS_PORT(devnum,speed,duplex) \
+ * { devnum, speed, duplex},
+ * #define CFG_PHY_LESS_PORTS \
+ * CFG_PHY_LESS_PORT(0,1000,FULL)
+ */
+#if !defined(CONFIG_PHY_LESS)
+#define CONFIG_PHY_LESS 0x /* PHY-less mode */
+#endif
If we agree that this is a good generic approach for this PHY-less handling,
then we should probably move this to a common header so that other ethernet
driver can use this too.
Ben, what do you think?
And the description should be moved to a common place too. Either the
toplevel
README, or a new README.xxx in the doc directory.
I like the idea very much, but am not sure about the implementation.
This problem has been around for a while (just search the archives for
people wondering how to deal with a switch chip connected via rvMII or
whatever). The trickiest part of this is how to get the information to
the driver. I've always thought that the best way would be for board
code to initialize each controller through proper C code (i.e. not
CONFIG macros). But there's definitely something to be said for doing
it all through macros, since that's how Kconfig works. Please have a
look at the code that Andy Fleming recently submitted for the TSEC
driver (it's in the main branch now). He passes a tsec_info_struct into
each call of tsec_initialize(), allowing all type of custom information
to go in. In my mind, that could be generalized to something that more
than just TSEC, but let's take baby steps.
Incidentally, the term Fixed PHY has already been coined for what
you're calling PHY-less. I suggest we standardize.
Anyway, I have to go to bed. Eyes are starting to close and brain's
sloowwwiing doowwn.
cheers,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ads5121: Set offset of NFC registers in device tree.
On Wed, 2008-09-03 at 22:41 +0200, Wolfgang Denk wrote: Dear John Rigby, In message [EMAIL PROTECTED] you wrote: I'm not sure this right way to deal with this. Even with the modified offset the 1.5 silicon linux nand driver will not work correctly with the 2.0 silicon nand controller. That's right - but al least the Linux kernel will not crash if used on one or the other board. yes but due to the large difference you will probably never se one driver supporting both version so just changing the name of the hardware node is probably easier. I think we should fix the NFC base address on the device tree level - having to support different Linux kernel configurations depending on if you are on old or new hardware is pretty painful. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] USB EHCI: reset root hub
On Thu, Sep 04, 2008 at 11:19:05AM +0200, Detlev Zundel wrote: From: Yuri Tikhonov [EMAIL PROTECTED] Some of multi-function USB controllers (e.g. ISP1562) allow root hub resetting only via EHCI registers. So, this patch adds the corresponding kind of reset to OHCI's hc_reset() if the newly introduced CONFIG_PCI_EHCI_DEVNO option is set (e.g. for Socrates board). Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Acked-by: Markus Klotzbuecher [EMAIL PROTECTED] Wolfgang, please pick up directly (I consider this a bugfix). Best regards Markus -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppx4xx: Fix broken DASA_SIM board
Hi Wolfgang,
you are right. But currently I do not have any suitable IOP480 based
hardware on my desk to test bigger changes.
Matthias
On Wednesday 03 September 2008 22:58, Wolfgang Denk wrote:
Dear Matthias Fuchs,
In message [EMAIL PROTECTED] you wrote:
This patch adds initdram() to DASA_SIM boards that has been
removed accidentally by a previous commit.
Signed-off-by: Matthias Fuchs [EMAIL PROTECTED]
---
board/esd/dasa_sim/dasa_sim.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/board/esd/dasa_sim/dasa_sim.c b/board/esd/dasa_sim/dasa_sim.c
index def0354..4cc3a2f 100644
--- a/board/esd/dasa_sim/dasa_sim.c
+++ b/board/esd/dasa_sim/dasa_sim.c
@@ -202,3 +202,8 @@ int checkboard (void)
return 0;
}
+
+phys_size_t initdram (int board_type)
+{
+ return (16 * 1024 * 1024);
+}
We should really get rid of hard-coded memory sizes and auto-size all
boards.
Best regards,
Wolfgang Denk
--
-
Dipl.-Ing. Matthias Fuchs
Head of System Design
esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Phone: +49-511-37298-0 - Fax: +49-511-37298-68
Please visit our homepage http://www.esd.eu
Quality Products - Made in Germany
-
Geschäftsführer: Klaus Detering, Dr. Werner Schulze
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] fw_env: add NAND support
Add support for environment in NAND with automatic NOR / NAND recognition,
including unaligned environment, bad-block skipping, redundant environment
copy.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
Changes since v1: multiple style updates, added Copyright, restored
flash_io() function, fixed NAND flag handling. Thanks for all the
comments.
diff --git a/tools/env/README b/tools/env/README
index f8a644e..91e679a 100644
--- a/tools/env/README
+++ b/tools/env/README
@@ -22,9 +22,11 @@ following lines are relevant:
#define DEVICE1_OFFSET0x
#define ENV1_SIZE 0x4000
#define DEVICE1_ESIZE 0x4000
+#define DEVICE1_ENVSECTORS 2
#define DEVICE2_OFFSET0x
#define ENV2_SIZE 0x4000
#define DEVICE2_ESIZE 0x4000
+#define DEVICE2_ENVSECTORS 2
Current configuration matches the environment layout of the TRAB
board.
@@ -46,3 +48,7 @@ then 1 sector.
DEVICEx_ESIZE defines the size of the first sector in the flash
partition where the environment resides.
+
+DEVICEx_ENVSECTORS defines the number of sectors that may be used for
+this environment instance. On NAND this is used to limit the range
+within which bad blocks are skipped, on NOR it is not used.
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index e4fc02d..b6036c8 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -2,6 +2,9 @@
* (C) Copyright 2000-2008
* Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
*
+ * (C) Copyright 2008
+ * Guennadi Liakhovetski, DENX Software Engineering, [EMAIL PROTECTED]
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -45,36 +48,75 @@
#defineCMD_GETENV fw_printenv
#defineCMD_SETENV fw_setenv
-typedef struct envdev_s {
+#define min(x, y) ({ \
+ typeof(x) _min1 = (x); \
+ typeof(y) _min2 = (y); \
+ (void) (_min1 == _min2); \
+ _min1 _min2 ? _min1 : _min2; })
+
+struct envdev_s {
char devname[16]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
-} envdev_t;
+ ulong env_sectors; /* number of environment sectors */
+ uint8_t mtd_type; /* type of the MTD device */
+};
-static envdev_t envdevices[2];
-static int curdev;
+static struct envdev_s envdevices[2] =
+{
+ {
+ .mtd_type = MTD_ABSENT,
+ }, {
+ .mtd_type = MTD_ABSENT,
+ },
+};
+static int dev_current;
#define DEVNAME(i)envdevices[(i)].devname
#define DEVOFFSET(i) envdevices[(i)].devoff
#define ENVSIZE(i)envdevices[(i)].env_size
#define DEVESIZE(i) envdevices[(i)].erase_size
+#define ENVSECTORS(i) envdevices[(i)].env_sectors
+#define DEVTYPE(i)envdevices[(i)].mtd_type
-#define CFG_ENV_SIZE ENVSIZE(curdev)
+#define CFG_ENV_SIZE ENVSIZE(dev_current)
#define ENV_SIZE getenvsize()
-typedef struct environment_s {
- ulong crc; /* CRC32 over data bytes*/
- unsigned char flags;/* active or obsolete */
- char *data;
-} env_t;
+struct env_image_single {
+ uint32_tcrc;/* CRC32 over data bytes*/
+ chardata[];
+};
-static env_t environment;
+struct env_image_redundant {
+ uint32_tcrc;/* CRC32 over data bytes*/
+ unsigned char flags; /* active or obsolete */
+ chardata[];
+};
+
+enum flag_scheme {
+ FLAG_NONE,
+ FLAG_BOOLEAN,
+ FLAG_INCREMENTAL,
+};
+
+struct environment {
+ void*image;
+ uint32_t*crc;
+ unsigned char *flags;
+ char*data;
+ enum flag_schemeflag_scheme;
+};
+
+static struct environment environment = {
+ .flag_scheme = FLAG_NONE,
+};
static int HaveRedundEnv = 0;
static unsigned char active_flag = 1;
+/* obsolete_flag must be 0 to efficiently set it on NOR flash without erasing
*/
static unsigned char obsolete_flag = 0;
@@ -157,7 +199,7 @@ static char default_environment[] = {
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
- \0/* Termimate env_t data with 2 NULs */
+ \0/* Termimate struct environment data with 2 NULs */
};
static int flash_io (int mode);
@@ -186,7 +228,7 @@ char *fw_getenv (char *name)
char *env, *nxt;
if (env_init ())
- return (NULL);
+ return NULL;
for (env = environment.data; *env; env = nxt + 1) {
char *val;
@@ -195,15 +237,15 @@ char *fw_getenv (char *name)
if (nxt = environment.data[ENV_SIZE]) {
fprintf (stderr, ##
[U-Boot] running u-boot from SDRAM
Hello, I need to port U-Boot on the platform, consisting of master and daughter boards. Master boards runs WinCE; daughter board features SoC, based on ARM926EJ-S, on-chip SDRAM and ROM. Master launches daughter board by downloading binary image of bootcode in to the on-chip SDRAM, then does remap (i.e. 0x0 points at SDRAM) and boot loader starts off. Therefore I'm wondering -- will U-Boot be fine with such a boot mode, usually systems start from flash (NOR or NAND), but here it's in RAM. I believe it should be OK, but just want to make sure. Looking forward to receiving feedback from you. Thanks. -- Roman Mashak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot-Users] Boot from Jffs2 filesystem problem
Hi Pedro,
the SourceForge mailing list is deprecated, please use the one at
lists.denx.de.
[This time, the new address is correct]
The u-boot version I'm using is 1.3.1 (self compiled) and Linux Kernel
2.6.23.1.
It is possible to boot it with a stored kernel uImage and the oftree in the
flash using a nfs filesystem,
but I can't not boot it using the jffs2 image.
I've read a lot of documentation from denx.de and this is my configuration at
the moment:
mtdparts=mtdparts=TQM5200-0:512k(uboot),256k(environment),3328k(kernel),20m(jffs2),256k(oftree)
bootargs_mtd=setenv bootargs ${bootargs} ${mtdparts}
bootargs_flash=setenv bootargs ${bootargs} root=/dev/mtdblock4 rw
rootfstype=jffs2
(even tried with root=/dev/mtdblock3, I'm not sure if 0 counts or not)
bootargs_base=setenv bootargs console=ttyPSC0,115200
bootcmd_flash=run bootargs_base bootargs_flash bootargs_mtd;bootm fC0C –
fD80
I've defined the partitions myself and double checked the numbers, first
myself, then using the mtdparts command.
The kernel image, oftree, and jffs2 filesystem are stored in the flash.
The problem comes at booting. Even when root=/dev/mtdblock4 rw
rootfstype=jffs2 is passed to the kernel,
it always tries to boot from a Ramdisk image. This is the output when I run
bootcmd_flash command:
= run bootcmd_flash
## Booting image at fc0c ...
Image Name: Linux-2.6.23.1-rt5-pcm030-1trunk
Created: 2008-09-02 11:48:23 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1534856 Bytes = 1.5 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ...
Bad Magic Number
It seems to me that U-boot is trying to boot from RAMDisk instead of booting
the kernel, but I'm not sure.
Yes, indeed. It looks like the bootm fc0c - fd80 is not
evaluated properly. In v1.3.1 code the code lines were
(common/cmd_bootm.c:622)
#if defined(CONFIG_OF_FLAT_TREE) || defined(CONFIG_OF_LIBFDT)
/* Look for a '-' which indicates to ignore the ramdisk argument
*/
if (argc = 3 strcmp(argv[2], -) == 0) {
debug (Skipping initrd\n);
len = data = 0;
}
else
#endif
So The upstream v1.3.1 config for TQM5200 also has CONFIG_OF_LIBFDT
defined:
$ git-show v1.3.1:include/configs/TQM5200.h | grep CONFIG_OF_LIBFDT
#define CONFIG_OF_LIBFDT 1
So if you did not change that, my last explanation is that you have
hidden escape characters in the definition of bootcmd_flash. Check with
'md' on the environment sectors to find out.
Cheers
Detlev
--
Shin: a device for finding furniture in the dark.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] running u-boot from SDRAM
Dear Roman Mashak, In message [EMAIL PROTECTED] you wrote: I need to port U-Boot on the platform, consisting of master and daughter boards. Master boards runs WinCE; daughter board features SoC, based on ARM926EJ-S, on-chip SDRAM and ROM. Master launches daughter board by downloading binary image of bootcode in to the on-chip SDRAM, then does remap (i.e. 0x0 points at SDRAM) and boot loader starts off. I guess you are aware that SRDAM cannot just be used, instead it must initialized correctly before you can access it. Your master is also performing this initialization procedure, then? Therefore I'm wondering -- will U-Boot be fine with such a boot mode, usually systems start from flash (NOR or NAND), but here it's in RAM. I believe it should be OK, but just want to make sure. It doesn't hurt when the device where U-Boot is booting from is writable. You have to take care not to try tF12o re-initialize the RAM in U-Boot, though. 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: [EMAIL PROTECTED] You don't need a weatherman to know which way the wind blows. - Bob Dylan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Boot from jffs2 filesystem problem
[Previously posted in the wrong mail list, sorry]
Hello everybody,
I'm finding some problems trying to boot a TQM5200 board using a jffs2 image as
filesystem.
The u-boot version I'm using is 1.3.1 (self compiled) and Linux Kernel 2.6.23.1.
It is possible to boot it with a stored kernel uImage and the oftree in the
flash using a nfs filesystem,
but I can't not boot it using the jffs2 image.
I've read a lot of documentation from denx.de and this is my configuration at
the moment:
mtdparts=mtdparts=TQM5200-0:512k(uboot),256k(environment),3328k(kernel),20m(jffs2),256k(oftree)
bootargs_mtd=setenv bootargs ${bootargs} ${mtdparts}
bootargs_flash=setenv bootargs ${bootargs} root=/dev/mtdblock4 rw
rootfstype=jffs2
(even tried with root=/dev/mtdblock3, I'm not sure if 0 counts or not)
bootargs_base=setenv bootargs console=ttyPSC0,115200
bootcmd_flash=run bootargs_base bootargs_flash bootargs_mtd;bootm fC0C –
fD80
I've defined the partitions myself and double checked the numbers, first
myself, then using the mtdparts command.
The kernel image, oftree, and jffs2 filesystem are stored in the flash.
The problem comes at booting. Even when root=/dev/mtdblock4 rw
rootfstype=jffs2 is passed to the kernel,
it always tries to boot from a Ramdisk image. This is the output when I run
bootcmd_flash command:
= run bootcmd_flash
## Booting image at fc0c ...
Image Name: Linux-2.6.23.1-rt5-pcm030-1trunk
Created: 2008-09-02 11:48:23 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1534856 Bytes = 1.5 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ...
Bad Magic Number
It seems to me that U-boot is trying to boot from RAMDisk instead of booting
the kernel, but I'm not sure.
The same kernel is working properly on a phytec board and 1.2.0 U-boot,
so it's not a problem with jffs2 support within the kernel.
Any hint how to boot from jffs2 filesystem? The example in U-Boot documentation
doesn't use oftree and so,
bootm ${kernel_addr} is used, but TQM5200 requieres FDT description to boot
linux as you'll know.
Maybe should I compile the U-boot using some CONFIG_ parameter?
Thanks in advance.
Pedro L. Dominguez.
_
Prueba los prototipos de los últimos en MSN Motor
http://motor.es.msn.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TQM5200 HIGHBOOT Makefile patch
Hi,
I don't know the normal procedure, if I should send the patch to Wolfgang or
someone else, but I found a problem with Makefile and TQM5200 HIGHBOOT config
in Makefile. I think this problem is also in previous versions since tqm boards
where moved under tqc folder.
The patch is:
--- a/Makefile 2008-09-04 14:55:05.0 +0200
+++ b/Makefile 2008-09-04 14:56:14.0 +0200
@@ -755,7 +755,7 @@
echo #define CONFIG_TQM5200_B
$(obj)include/config.h ; \
}
@[ -z $(findstring HIGHBOOT,$@) ] || \
- { echo TEXT_BASE = 0xFFF0$(obj)board/tqm5200/config.tmp
; \
+ { echo TEXT_BASE =
0xFFF0$(obj)board/tqc/tqm5200/config.tmp ; \
}
@$(MKCONFIG) -n $@ -a TQM5200 ppc mpc5xxx tqm5200 tqc
Regards,
Pedro.
_
Prueba los prototipos de los últimos en MSN Motor
http://motor.es.msn.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CFG_64BIT_xxx and friends
Hi all,
after testing the recent U-Boot code on a couple of 405EP boards I noticed,
that the memsize in the output of the bdinfo command is always 0x.
This is caused by using 64 types and format directives in printf that only
work when CFG_64BIT_VSPRINTF is defined.
So what's the best way to fix this?
Here are four solutions. My favorite is no. 2.
1) Define CFG_64BIT_STRTOUL for all effected board.
Currently all 405 boards have memsize output as 0 in bdinfo.
2) Define CFG_64BIT_VSPRINTF and CFG_64BIT_STRTOUL for all 4xx boards in
include/ppc4xx.h:
diff --git a/include/ppc4xx.h b/include/ppc4xx.h
index 59a3b06..f0dfa38 100644
--- a/include/ppc4xx.h
+++ b/include/ppc4xx.h
@@ -102,13 +102,14 @@
#endif /* 440EP/EPX 440GR/GRX 440SP/SPE 460EX/GT/SX 405EX*/
-#if defined(CONFIG_440)
/*
* Enable long long (%ll ...) printf format on 440 PPC's since most of
* them support 36bit physical addressing
*/
#define CFG_64BIT_VSPRINTF
#define CFG_64BIT_STRTOUL
+
+#if defined(CONFIG_440)
#include ppc440.h
#else
#include ppc405.h
3) Generally define CFG_64BIT_VSPRINTF and CFG_64BIT_STRTOUL for all boards.
4) Use an (ugly) workaround in common/cmd_bdinfo.c:
static void print_lnum(const char *name, u64 value)
{
#ifdef CFG_64BIT_VSPRINTF
printf (%-12s= 0x%.8llX\n, name, value);
#else
u32 *value32 = (u32*)value;
if (value32[0])
printf (%-12s= 0x%lX%.8lX\n, name, value32[0], value32[1]);
else
printf (%-12s= 0x%.8lX\n, name, value32[1]);
#endif
}
So what do you think?
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TQM5200 HIGHBOOT Makefile patch
Hi Pedro, Hi, I don't know the normal procedure, if I should send the patch to Wolfgang or someone else, but I found a problem with Makefile and TQM5200 HIGHBOOT config in Makefile. I think this problem is also in previous versions since tqm boards where moved under tqc folder. The normal procedure is to prepare a patch with git (use git-format-patch) against top of tree version so that it can be applied without any hassle (use git-send-email if you want to save a few iterations). Search the archives on more details on how to do this and be sure not to forget your Signed-off-by line. Apart from that, the patch looks good. Cheers Detlev -- If you currently have a 32-bit UNIX system, you are advised to trade it in for a 64-bit one sometime before the year 2106. -- Andrew S. Tanenbaum: Modern Operating Systems, 2nd Edition -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ads5121: Set offset of NFC registers in device tree.
On Thu, Sep 04, 2008 at 10:13:49AM +0200, Kenneth Johansson wrote: On Wed, 2008-09-03 at 22:41 +0200, Wolfgang Denk wrote: Dear John Rigby, In message [EMAIL PROTECTED] you wrote: I'm not sure this right way to deal with this. Even with the modified offset the 1.5 silicon linux nand driver will not work correctly with the 2.0 silicon nand controller. That's right - but al least the Linux kernel will not crash if used on one or the other board. yes but due to the large difference you will probably never se one driver supporting both version so just changing the name of the hardware node is probably easier. s/name/compatible/ -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Boot from jffs2 filesystem problem
On Thu, Sep 04, 2008 at 02:04:42PM +0200, Pedro Luis D. L. wrote:
It seems to me that U-boot is trying to boot from RAMDisk instead of booting
the kernel, but I'm not sure.
The same kernel is working properly on a phytec board and 1.2.0 U-boot,
so it's not a problem with jffs2 support within the kernel.
Any hint how to boot from jffs2 filesystem? The example in U-Boot
documentation doesn't use oftree and so,
bootm ${kernel_addr} is used, but TQM5200 requieres FDT description to boot
linux as you'll know.
Maybe should I compile the U-boot using some CONFIG_ parameter?
Sounds like maybe you're trying to pass the FDT address as the second
bootm parameter? It needs to be the third parameter, and you pass - as
the second parameter if there's no initrd.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY
On Thursday 04 September 2008, Ben Warren wrote: I like the idea very much, but am not sure about the implementation. This problem has been around for a while (just search the archives for people wondering how to deal with a switch chip connected via rvMII or whatever). The trickiest part of this is how to get the information to the driver. I've always thought that the best way would be for board code to initialize each controller through proper C code (i.e. not CONFIG macros). But there's definitely something to be said for doing it all through macros, since that's how Kconfig works. Please have a look at the code that Andy Fleming recently submitted for the TSEC driver (it's in the main branch now). He passes a tsec_info_struct into each call of tsec_initialize(), allowing all type of custom information to go in. In my mind, that could be generalized to something that more than just TSEC, but let's take baby steps. Yes, this looks like a good approach. Not sure if we should go all the way or accept Victors approach for now. Moving to this parameter based initialization is a different matter that should really be done soon. Incidentally, the term Fixed PHY has already been coined for what you're calling PHY-less. I suggest we standardize. Yes. Is there already a define available? Anyway, I have to go to bed. Eyes are starting to close and brain's sloowwwiing doowwn. Heh :) Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Boot from jffs2 filesystem problem
On Thu, Sep 04, 2008 at 05:21:57PM +0200, Pedro Luis D. L. wrote:
I've already tried with:
- bootm ${kernel_addr} - ${fdt_addr}
This is the correct one.
And always with the same result...
Are you sure it's exactly the same? How could u-boot fail when loading
the initrd if there is none specified?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY
Hi Stefan and Ben, I saw what Andy Fleming's did. This is a bit to much work for what I have time for. I aggree, we need to take baby steps.. For now I'll change PHY-less to Fixed PHY and update some style issues. -Victor Gallardo -Original Message- From: Stefan Roese [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2008 8:34 AM To: Ben Warren Cc: u-boot@lists.denx.de; Victor Gallardo Subject: Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY On Thursday 04 September 2008, Ben Warren wrote: I like the idea very much, but am not sure about the implementation. This problem has been around for a while (just search the archives for people wondering how to deal with a switch chip connected via rvMII or whatever). The trickiest part of this is how to get the information to the driver. I've always thought that the best way would be for board code to initialize each controller through proper C code (i.e. not CONFIG macros). But there's definitely something to be said for doing it all through macros, since that's how Kconfig works. Please have a look at the code that Andy Fleming recently submitted for the TSEC driver (it's in the main branch now). He passes a tsec_info_struct into each call of tsec_initialize(), allowing all type of custom information to go in. In my mind, that could be generalized to something that more than just TSEC, but let's take baby steps. Yes, this looks like a good approach. Not sure if we should go all the way or accept Victors approach for now. Moving to this parameter based initialization is a different matter that should really be done soon. Incidentally, the term Fixed PHY has already been coined for what you're calling PHY-less. I suggest we standardize. Yes. Is there already a define available? Anyway, I have to go to bed. Eyes are starting to close and brain's sloowwwiing doowwn. Heh :) Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fix dev_print for when it is called from usb_stor_info (usb storage command)
Hello people, here is a quick fix for the output of the command usb storage. It was printing Device 0: not available because the IF_TYPE_USB was not included into the switch statement. --- u-boot-1.3.4.original/disk/part.c 2008-08-12 11:08:38.0 -0300 +++ u-boot-1.3.4/disk/part.c2008-09-04 14:48:55.0 -0300 @@ -124,6 +124,12 @@ void dev_print (block_dev_desc_t *dev_de dev_desc-revision, dev_desc-product); break; + case IF_TYPE_USB: + printf (Vendor: %s Rev: %s Prod: %s\n, + dev_desc-vendor, + dev_desc-revision, + dev_desc-product); + break; case IF_TYPE_UNKNOWN: default: puts (not available\n); -- Now, for example, with my usb kingston datatraveller, it correctly prints: U-Boot usb storage Device 0: Vendor: Kingston Rev: 1.00 Prod: DataTraveler 2.0 Type: Removable Hard Disk Capacity: 1956.5 MB = 1.9 GB (4006912 x 512) Regards, Nícolas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ppc4xx: glacier broken with latest u-boot
Hello Stefan, I just pulled the latest u-boot (git://git.denx.de/u-boot-ppc4xx.git) and glacier is broken. It builds, but if load the u-boot it hangs. This is far as it gets. U-Boot 1.3.4-03965-g7deb3b3 (Sep 4 2008 - 16:26:55) CPU: AMCC PowerPC 460GT Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Glacier - AMCC PPC460GT Evaluation Board, 2*PCIe, Rev. 13 I2C: ready DTT: 1 is 35 C DRAM: 256 MB (ECC not enabled, 400 MHz, CL3) FLASH: 64 MB NAND: 32 MiB PCI: Bus Dev VenId DevId Class Int PCIE0: link is not up. PCIE0: initialization as root-complex failed PCIE1: link is not up. PCIE1: initialization as root-complex failed Regards, Victor Gallardo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc4xx: glacier broken with latest u-boot
Stefan,
I took a quick look at this problem and tracked the problem down to the
serial console initialization area for the AMCC Glacier and Canyonlands
boards.
description PPC4xx U-Boot Custodian Tree
owner Stefan Roese
last change Wed, 3 Sep 2008 15:21:38 +
URL git://git.denx.de/u-boot-ppc4xx.git
The problem was introduced 4 days ago with the commit
committer Wolfgang Denk [EMAIL PROTECTED]
Sun, 31 Aug 2008 22:16:29 + (00:16 +0200)
commit e99e9575bbeba1b7c48e046547cae065ec0071de
tree c08553c4d06725bd6013a46068df0059c5b49a00
parent a13b2d937941f6b525abfcfad96c034f94421188
parent 08ab4e1780fa63c88dd5a5ab52f4ff4ed1ee1878
If one were to rebase their git tree to the prior commit, U-Boot will
boot all the way up on the Glacier and Canyonlands boards.
committer Wolfgang Denk [EMAIL PROTECTED]
Sun, 31 Aug 2008 22:06:05 + (00:06 +0200)
commit a13b2d937941f6b525abfcfad96c034f94421188
tree 56e5bdaf62397b2f8cc2be9b17a035d9b059bf8a
parent e155c9e00b5f21a6de28479259c440ba71289d00
parent d6e04258be8f2408845468d3cf722a4cf0433445
The problem happens within the console_init_r() routine called from the
board_init_r() function.
common/console.c
#else /* CFG_CONSOLE_IS_IN_ENV */
/* Called after the relocation - use desired console functions */
int console_init_r (void)
{
device_t *inputdev = NULL, *outputdev = NULL;
int i;
struct list_head *list = device_get_list();
struct list_head *pos;
device_t *dev;
#ifdef CONFIG_SPLASH_SCREEN
/* suppress all output if splash screen is enabled and we have
a bmp to display
*/
if (getenv(splashimage) != NULL)
gd-flags |= GD_FLG_SILENT;
#endif
/* Scan devices looking for input and output devices */
list_for_each(pos, list) {
dev = list_entry(pos, device_t, list);
if ((dev-flags DEV_FLAGS_INPUT) (inputdev ==
NULL)) {
inputdev = dev;
}
if ((dev-flags DEV_FLAGS_OUTPUT) (outputdev ==
NULL)) {
outputdev = dev;
}
if(inputdev outputdev)
break;
}
/* Initializes output console first */
if (outputdev != NULL) {
console_setfile (stdout, outputdev);
console_setfile (stderr, outputdev);
}
/* Initializes input console */
if (inputdev != NULL) {
console_setfile (stdin, inputdev);
}
gd-flags |= GD_FLG_DEVINIT;/* device initialization
completed */
(Problem happens here- no more console output)
There are 4 elements in the device_get_list() list. I did a quick print
of their flags field:
list_head 0x1ffef2a0
dev-flags = 0x8003
dev-flags = 0x0003
dev-flags = 0x0003
dev-flags = 0x8003
Is the dev-flags for each console serial device have both
DEV_FLAGS_INPUT and the DEV_FLAGS_OUTPUT set?
There was a change in the e99e9575bbeba1b7c48e046547cae065ec0071de
commit with the list processing of the console devices
(common/console.c, common/devices.c).
Unfortunately I can not investigate further tonight (family engagement),
but I hope this helps.
Adam Graham
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Victor Gallardo
Sent: Thursday, September 04, 2008 4:47 PM
To: Stefan Roese; u-boot@lists.denx.de
Subject: [U-Boot] ppc4xx: glacier broken with latest u-boot
Hello Stefan,
I just pulled the latest u-boot (git://git.denx.de/u-boot-ppc4xx.git)
and glacier is broken. It builds, but if load the u-boot it
hangs. This is far as it gets.
U-Boot 1.3.4-03965-g7deb3b3 (Sep 4 2008 - 16:26:55)
CPU: AMCC PowerPC 460GT Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100
MHz)
Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter disabled
32 kB I-Cache 32 kB D-Cache
Board: Glacier - AMCC PPC460GT Evaluation Board, 2*PCIe, Rev. 13
I2C: ready
DTT: 1 is 35 C
DRAM: 256 MB (ECC not enabled, 400 MHz, CL3)
FLASH: 64 MB
NAND: 32 MiB
PCI: Bus Dev VenId DevId Class Int
PCIE0: link is not up.
PCIE0: initialization as root-complex failed
PCIE1: link is not up.
PCIE1: initialization as root-complex failed
Regards,
Victor Gallardo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Paid A Full-Time Job's Salary To Play Video Games
If you buy a new MMORPG that crashes every time your character jumps while running, chances are you will not like the game and tell all of your friends not to buy it. This is a serious setback for the game company. The customers that bought their product will not buy it again and neither will their friends. This company now will have invested millions of dollars in game development, manufacturing, shipping, and marketing costs but no one will buy their game because of one glitch. What if a game company creates a new way to play online, but it's just too complicated? This is a serious setback, the company executives might of thought that the this new system was cool but in fact, from the gamer's perspective, there's nothing cool about trying to figure out how to login to play the game online. Again, no one will buy this game and the manufacturing company will lose millions! http://gametesterwd.blogspot.com/# --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lucky Win Big Casino group. To post to this group, send email to Lucky-Win-Big-Casino@goot; hasn't been fixed. It would be nice to have this fixed in 2008.10. Indeed, this must go in. 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: [EMAIL PROTECTED] Our management frequently gets lost in thought. That's because it's unfamiliar territory. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
