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] unassigned-patches/25: [PATCH] USB EHCI: reset root hub
Dear Yuri,
On Fri, Aug 15, 2008 at 03:45:02PM +0200, [EMAIL PROTECTED] wrote:
> 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]>
>
> ---
> Added to GNATS database as unassigned-patches/25
> >Responsible:patch-coord
> >Message-Id: <[EMAIL PROTECTED]>
> >In-Reply-To:<[EMAIL PROTECTED]>
> >References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> >Patch-Date: Fri Aug 15 15:42:10 +0200 2008
> ---
> drivers/usb/usb_ohci.c | 31 +++
> drivers/usb/usb_ohci.h |3 +++
> include/configs/socrates.h |1 +
> 3 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
> index fd60edb..0f5bd06 100644
> --- a/drivers/usb/usb_ohci.c
> +++ b/drivers/usb/usb_ohci.c
> @@ -1571,11 +1571,42 @@ int submit_int_msg(struct usb_device *dev, unsigned
> long pipe, void *buffer,
>
> static int hc_reset (ohci_t *ohci)
> {
> +#ifdef CONFIG_PCI_EHCI_DEVNO
> + pci_dev_t pdev;
> + struct pci_device_id ehci_pci_ids[] = {
> + {0x1131, 0x1562}, /* Philips 1562 PCI EHCI module ids */
> + {0, 0}
> + };
Please move this out of the function, preferrably next to the OHCI
device ids.
Thanks!
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] u-boot for BMW board
hi Wolfgang, i used BMW configuration and now o/p is U-Boot 1.1.6 (Sep 3 2008 - 21:48:59) CPU: MPC8245 Revision 1.2 at 198 MHz: 16 kB I-Cache 16 kB D-Cache Board: BMW MPC8245/KAHLUA2 - CHRP (MAP B) Built: Sep 3 2008 at 21:48:59 Local Bus at 99 MHz DRAM: 64 MB FLASH: *** failed *** ### ERROR ### Please RESET the board ### What are macros i have to look at to pass the FLASH test.and actual DRAM is 256 MB but its showing 64 MB. Regards, Ramji On Wed, Sep 3, 2008 at 9:00 PM, John W. Linville <[EMAIL PROTECTED]>wrote: > On Wed, Sep 03, 2008 at 08:44:37PM +0530, Ramji PanchaReddy wrote: > > Hi Wolfgang, > > Thanks a lot for your response .. > > > > I also tried BMW_config and used cross-compiler as ppc_82xx-* .When i > load > > this i did not get any thing on console. > > My processor is MPC8245. > > From what I recall about BMW, you probably want to go through the > BMW-related configuration bits and verify all the clock settings, > memory settings, etc for your exact version of the board. IIRC the > vendor was a bit prone to changing such things between different > versions. > > Good luck! > > John > -- > John W. Linville > [EMAIL PROTECTED] > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] USB EHCI: reset root hub
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]>
---
drivers/usb/usb_ohci.c | 35 +++
drivers/usb/usb_ohci.h |3 +++
include/configs/socrates.h |1 +
3 files changed, 39 insertions(+), 0 deletions(-)
This new version addresses Markus feedback.
diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
index fd60edb..ce13866 100644
--- a/drivers/usb/usb_ohci.c
+++ b/drivers/usb/usb_ohci.c
@@ -108,6 +108,14 @@ static struct pci_device_id ohci_pci_ids[] = {
};
#endif
+#ifdef CONFIG_PCI_EHCI_DEVNO
+static struct pci_device_id ehci_pci_ids[] = {
+ {0x1131, 0x1562}, /* Philips 1562 PCI EHCI module ids */
+ /* Please add supported PCI EHCI controller ids here */
+ {0, 0}
+};
+#endif
+
#ifdef DEBUG
#define dbg(format, arg...) printf("DEBUG: " format "\n", ## arg)
#else
@@ -1571,11 +1579,38 @@ int submit_int_msg(struct usb_device *dev, unsigned
long pipe, void *buffer,
static int hc_reset (ohci_t *ohci)
{
+#ifdef CONFIG_PCI_EHCI_DEVNO
+ pci_dev_t pdev;
+#endif
int timeout = 30;
int smm_timeout = 50; /* 0,5 sec */
dbg("%s\n", __FUNCTION__);
+#ifdef CONFIG_PCI_EHCI_DEVNO
+ /*
+* Some multi-function controllers (e.g. ISP1562) allow root hub
+* resetting via EHCI registers only.
+*/
+ pdev = pci_find_devices(ehci_pci_ids, CONFIG_PCI_EHCI_DEVNO);
+ if (pdev != -1) {
+ u32 base;
+ int timeout = 1000;
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &base);
+ writel (readl(base + EHCI_USBCMD_OFF) | EHCI_USBCMD_HCRESET,
+ base + EHCI_USBCMD_OFF);
+
+ while (readl(base + EHCI_USBCMD_OFF) & EHCI_USBCMD_HCRESET) {
+ if (timeout-- <= 0) {
+ printf("USB RootHub reset timed out!");
+ break;
+ }
+ udelay(1);
+ }
+ } else
+ printf("No EHCI func at %d index!\n", CONFIG_PCI_EHCI_DEVNO);
+#endif
if (readl (&ohci->regs->control) & OHCI_CTRL_IR) { /* SMM owns the HC */
writel (OHCI_OCR, &ohci->regs->cmdstatus); /* request ownership
*/
info("USB HC TakeOver from SMM");
diff --git a/drivers/usb/usb_ohci.h b/drivers/usb/usb_ohci.h
index 380cb4c..7a04bf5 100644
--- a/drivers/usb/usb_ohci.h
+++ b/drivers/usb/usb_ohci.h
@@ -195,6 +195,9 @@ struct ohci_regs {
} roothub;
} __attribute((aligned(32)));
+/* Some EHCI controls */
+#define EHCI_USBCMD_OFF0x20
+#define EHCI_USBCMD_HCRESET(1 << 1)
/* OHCI CONTROL AND STATUS REGISTER MASKS */
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index 8a64942..fdc1557 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -403,6 +403,7 @@
#define CONFIG_USB_OHCI_NEW1
#define CONFIG_PCI_OHCI1
#define CONFIG_PCI_OHCI_DEVNO 3 /* Number in PCI list */
+#define CONFIG_PCI_EHCI_DEVNO (CONFIG_PCI_OHCI_DEVNO / 2)
#define CFG_USB_OHCI_MAX_ROOT_PORTS15
#define CFG_USB_OHCI_SLOT_NAME "ohci_pci"
#define CFG_OHCI_SWAP_REG_ACCESS 1
--
1.5.6.1
___
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 (
[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 to 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
#else
#include
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] Boot from jffs2 filesystem problem
> On Thu, 4 Sep 2008 10:09:57 -0500 Scott wrote:
>
> 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.
>
I've already tried with:
- bootm ${kernel_addr} - ${fdt_addr}
- bootm ${kernel_addr} ${fdt_addr}
- bootm ${kernel_addr} ${jffs2_addr} ${fdt_addr}
- bootm ${kernel_addr} ${fdt_addr} ${jffs2_addr}
And always with the same result...
Pedro.
> -Scott
_
¿Sigue el calor? Consulta MSN El tiempo
http://eltiempo.es.msn.com/
___
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
Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY
Hi Victor, Victor Gallardo wrote: > 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 understand completely. > 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 > > Sounds like a good idea. If you do that we can have this in 1.3.5 release and then come up with a more unified approach for maybe the next release. regards, Ben ___ 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
Re: [U-Boot] [PATCH] mpc83xx: fix mpc8313 in-tree building with NAND
On 16:04 Wed 03 Sep , Kim Phillips wrote: > From: Nick Spence <[EMAIL PROTECTED]> > > and add mpc8313 NAND build to MAKEALL > > Signed-off-by: Nick Spence <[EMAIL PROTECTED]> > Signed-off-by: Kim Phillips <[EMAIL PROTECTED]> > --- > MAKEALL |2 +- > Makefile |3 +++ > 2 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/MAKEALL b/MAKEALL > index e382947..e49f994 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -320,7 +320,7 @@ LIST_8260=" \ > > LIST_83xx=" \ > MPC8313ERDB_33 \ > - MPC8313ERDB_66 \ > + MPC8313ERDB_NAND_66 \ why do you remove MPC8313ERDB_66? Best Regards, J. ___ 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
[U-Boot] No Partition in Flash Memoery under MTD
Greetings,
i am using ELDK 2.6.26 distribution on MPC8349emds,
arch = powerpc, cross_compile = ppc_6xx-
i've tried with uImage + FDT blob .dtb + uRamdisk
and i've added flash mapping in .dts as follow:
[EMAIL PROTECTED] {
compatible = "amd,am29lv128ml", "cfi-flash";
reg = <0xfc00 0x0400>;
bank-width = <2>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
[EMAIL PROTECTED] {
label = "u-boot";
reg = <0 0x4>;
};
[EMAIL PROTECTED] {
label = "uImage";
reg = <0x0008 0x0010>;
};
[EMAIL PROTECTED] {
label = "uRamdisk";
reg = <0x0018 0x0020>;
};
[EMAIL PROTECTED] {
label = "MDS Device Tree";
reg = <0x0038 0x0080>;
};
};
when i boot up the kernel on the board, i tried
# cat /proc/mtd
dev:size erasesize name
mtd0: 0400 0002 "physmap-flash.0"
and
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/ram0 5040 3756 1284 75% /
it does not shows flash device with df, and no partition under /proc/mtd,
can anybody help?
in advance, thank you.
--
View this message in context:
http://www.nabble.com/No-Partition-in-Flash-Memoery-under-MTD-tp19322708p19322708.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
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.
I agree, here are the two device tree entries: Original silicon rev 1 and 1.5: compatible = "fsl,mpc5121-nfc"; rev 2: compatible = "fsl,mpc5121rev2-nfc"; On Thu, Sep 4, 2008 at 9:05 AM, Scott Wood <[EMAIL PROTECTED]> wrote: > 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] 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
Re: [U-Boot] [U-boot] [PATCHv2 1/2] NET: QE: UEC: Make uec_miiphy_read() and uec_miiphy_write() use the devname arg.
Hi Richard, richardretanubun wrote: > Hi Ben, > > Thanks for the feedback. I've made the changes you suggested. > Here is the patch re-pasted (please let me know if this is not the > proper way to submit patch v2). > > I starte to fix this up so that it would apply, but it's been badly mangled by your mailer. Would you mind please re-sending? If you're using Thunderbird or Evolution, select the "preformat" text type when you paste the patch. If using something else, please just attach the patch file. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.
Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
v2:
- Added comments to GPCS PHY setup
- Minor coding style cleanup
v3:
- Generalized the PHY-less configuration even more
v4:
- Change "PHY-less" to "Fixed PHY" to standardize
cpu/ppc4xx/4xx_enet.c | 159 -
cpu/ppc4xx/miiphy.c | 41 -
include/ppc4xx_enet.h |3 +
3 files changed, 198 insertions(+), 5 deletions(-)
diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..071ac0a 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_MUL1
#endif
+/*+
+ * Fixed PHY (PHY-less) support for Ethernet Ports.
+ **/
+
+/*
+ * Some boards do not have a PHY for each ethernet port. These ports
+ * are known as Fixed PHY (or PHY-less) ports. For such ports, set
+ * the appropriate CONFIG_PHY_ADDR equal to CONFIG_FIXED_PHY and
+ * then define CFG_FIXED_PHY_PORTS to define what the speed and
+ * duplex should be for these ports in the board configuration
+ * file.
+ *
+ * For Example:
+ * #define CONFIG_FIXED_PHY 0x
+ *
+ * #define CONFIG_PHY_ADDRCONFIG_FIXED_PHY
+ * #define CONFIG_PHY1_ADDR 1
+ * #define CONFIG_PHY2_ADDR CONFIG_FIXED_PHY
+ * #define CONFIG_PHY3_ADDR 3
+ *
+ * #define CFG_FIXED_PHY_PORT(devnum,speed,duplex) \
+ * {devnum, speed, duplex},
+ *
+ * #define CFG_FIXED_PHY_PORTS \
+ * CFG_FIXED_PHY_PORT(0,1000,FULL) \
+ * CFG_FIXED_PHY_PORT(2,100,HALF)
+ */
+
+#ifndef CONFIG_FIXED_PHY
+#define CONFIG_FIXED_PHY 0x /* Fixed PHY (PHY-less) */
+#endif
+
+#ifndef CFG_FIXED_PHY_PORTS
+#define CFG_FIXED_PHY_PORTS/* default is an empty array */
+#endif
+
+struct fixed_phy_port {
+ unsigned int devnum;/* ethernet port */
+ unsigned int speed; /* specified speed 10,100 or 1000 */
+ unsigned int duplex;/* specified duplex FULL or HALF */
+};
+
+static const struct fixed_phy_port fixed_phy_port[] = {
+ CFG_FIXED_PHY_PORTS /* defined in board configuration file */
+};
+
/*-+
* Global variables. TX and RX descriptors and buffers.
*-*/
@@ -611,8 +658,17 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
#if defined(CONFIG_460EX)
mode = 9;
+ mfsdr(SDR0_ETH_CFG, eth_cfg);
+ if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+ ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0))
+ mode = 11; /* config SGMII */
#else
mode = 10;
+ mfsdr(SDR0_ETH_CFG, eth_cfg);
+ if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+ ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0) &&
+ ((eth_cfg & SDR0_ETH_CFG_SGMII2_ENABLE) > 0))
+ mode = 12; /* config SGMII */
#endif
/* TODO:
@@ -635,6 +691,8 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
/*
* Right now only 2*RGMII is supported. Please extend when needed.
* sr - 2008-02-19
+* Add SGMII support.
+* vg - 2008-07-28
*/
switch (mode) {
case 1:
@@ -761,6 +819,20 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
bis->bi_phymode[2] = BI_PHYMODE_RGMII;
bis->bi_phymode[3] = BI_PHYMODE_RGMII;
break;
+ case 11:
+ /* 2 SGMII - 460EX */
+ bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[2] = BI_PHYMODE_NONE;
+ bis->bi_phymode[3] = BI_PHYMODE_NONE;
+ break;
+ case 12:
+ /* 3 SGMII - 460GT */
+ bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[2] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[3] = BI_PHYMODE_NONE;
+ break;
default:
break;
}
@@ -945,6 +1017,48 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t
* bis)
out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
#endif /* defined(CONFIG_440GX) || defined(CONFIG_440SP) */
+#if defined(CONFIG_GPCS_PHY_ADDR) || defined(CONFIG_GPCS_PHY1_ADDR) || \
+defined(CONFIG_GPCS_PHY2_ADDR) || defined(CONFIG_GPCS_PHY3_ADDR)
+ if (bis->bi_phymode[d
[U-Boot] [PATCH 1/1 v4] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.
Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
v2:
- Added comments to GPCS PHY setup
- Minor coding style cleanup
v3:
- Generalized the PHY-less configuration even more
v4:
- Change "PHY-less" to "Fixed PHY" to standardize
cpu/ppc4xx/4xx_enet.c | 159 -
cpu/ppc4xx/miiphy.c | 41 -
include/ppc4xx_enet.h |3 +
3 files changed, 198 insertions(+), 5 deletions(-)
diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..071ac0a 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_MUL1
#endif
+/*+
+ * Fixed PHY (PHY-less) support for Ethernet Ports.
+ **/
+
+/*
+ * Some boards do not have a PHY for each ethernet port. These ports
+ * are known as Fixed PHY (or PHY-less) ports. For such ports, set
+ * the appropriate CONFIG_PHY_ADDR equal to CONFIG_FIXED_PHY and
+ * then define CFG_FIXED_PHY_PORTS to define what the speed and
+ * duplex should be for these ports in the board configuration
+ * file.
+ *
+ * For Example:
+ * #define CONFIG_FIXED_PHY 0x
+ *
+ * #define CONFIG_PHY_ADDRCONFIG_FIXED_PHY
+ * #define CONFIG_PHY1_ADDR 1
+ * #define CONFIG_PHY2_ADDR CONFIG_FIXED_PHY
+ * #define CONFIG_PHY3_ADDR 3
+ *
+ * #define CFG_FIXED_PHY_PORT(devnum,speed,duplex) \
+ * {devnum, speed, duplex},
+ *
+ * #define CFG_FIXED_PHY_PORTS \
+ * CFG_FIXED_PHY_PORT(0,1000,FULL) \
+ * CFG_FIXED_PHY_PORT(2,100,HALF)
+ */
+
+#ifndef CONFIG_FIXED_PHY
+#define CONFIG_FIXED_PHY 0x /* Fixed PHY (PHY-less) */
+#endif
+
+#ifndef CFG_FIXED_PHY_PORTS
+#define CFG_FIXED_PHY_PORTS/* default is an empty array */
+#endif
+
+struct fixed_phy_port {
+ unsigned int devnum;/* ethernet port */
+ unsigned int speed; /* specified speed 10,100 or 1000 */
+ unsigned int duplex;/* specified duplex FULL or HALF */
+};
+
+static const struct fixed_phy_port fixed_phy_port[] = {
+ CFG_FIXED_PHY_PORTS /* defined in board configuration file */
+};
+
/*-+
* Global variables. TX and RX descriptors and buffers.
*-*/
@@ -611,8 +658,17 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
#if defined(CONFIG_460EX)
mode = 9;
+ mfsdr(SDR0_ETH_CFG, eth_cfg);
+ if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+ ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0))
+ mode = 11; /* config SGMII */
#else
mode = 10;
+ mfsdr(SDR0_ETH_CFG, eth_cfg);
+ if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+ ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0) &&
+ ((eth_cfg & SDR0_ETH_CFG_SGMII2_ENABLE) > 0))
+ mode = 12; /* config SGMII */
#endif
/* TODO:
@@ -635,6 +691,8 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
/*
* Right now only 2*RGMII is supported. Please extend when needed.
* sr - 2008-02-19
+* Add SGMII support.
+* vg - 2008-07-28
*/
switch (mode) {
case 1:
@@ -761,6 +819,20 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
bis->bi_phymode[2] = BI_PHYMODE_RGMII;
bis->bi_phymode[3] = BI_PHYMODE_RGMII;
break;
+ case 11:
+ /* 2 SGMII - 460EX */
+ bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[2] = BI_PHYMODE_NONE;
+ bis->bi_phymode[3] = BI_PHYMODE_NONE;
+ break;
+ case 12:
+ /* 3 SGMII - 460GT */
+ bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[2] = BI_PHYMODE_SGMII;
+ bis->bi_phymode[3] = BI_PHYMODE_NONE;
+ break;
default:
break;
}
@@ -945,6 +1017,48 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t
* bis)
out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
#endif /* defined(CONFIG_440GX) || defined(CONFIG_440SP) */
+#if defined(CONFIG_GPCS_PHY_ADDR) || defined(CONFIG_GPCS_PHY1_ADDR) || \
+defined(CONFIG_GPCS_PHY2_ADDR) || defined(CONFIG_GPCS_PHY3_ADDR)
+ if (bis->bi_phymode[d
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
