January 2004 - U-Boot

[U-Boot-Users] [Fwd: Intel LXT971A PHY support]
by listmember＠orkun.us 13 Jan '04

13 Jan '04

I did not get any comment for this. I was wondering the status of this patch. Best regards, Tolunay ---------------------------- Original Message ---------------------------- Hi, I am in the process of creating a U-Boot port for Cogent CSB272 board (PPC405) Working from U-Boot 1.0.0 tarball sources, I got CSB272 running. I still have some work done for it so I am not submitting CSB272 board support yet. Maybe next week or so after I complete work on it and make sure Linux boots OK. Anyway, CSB272 board has Intel LXT971A PHY. I could not get this PHY working initially. After investigation I have found: 1) LXT971A requires some recovery time (~300usec) before any register access after reset. This is documented in the datasheet on page 70, table 40. 2) LXT971A requires some time after command is issued before polling EMAC_STACR_OC is valid. I am not sure why this is needed but it is needed for this particular PHY or otherwise it does not work. I have found this to be minimum 32usec. I used 40usec for some safety margin. Thus, to get it working I had to patch two shared files: cpu/ppc4xx/miiphy.c common/miiphyutil.c The code added are conditional for each change and without those macro definitions it compiles exactly as it is right now. The macros are as follows (from my include/configs/csb272.h): #define CONFIG_PHY_CMD_DELAY 40 /* PHY COMMAND delay */ /* 32usec min. for LXT971A */ #define CONFIG_PHY_RESET_DELAY 300 /* PHY RESET recovery delay */ Here is the patch (I can resend it as an attachment if format is broken) --- u-boot-1.0.0/cpu/ppc4xx/miiphy.c 2003-09-02 18:08:13.000000000 -0500 +++ u-boot/cpu/ppc4xx/miiphy.c 2004-01-11 02:56:16.000000000 -0600 @@ -110,7 +110,9 @@ int miiphy_read (unsigned char addr, uns #if 0 /* test-only */ printf ("a2: write: EMAC_STACR=0x%0x\n", sta_reg); /* test-only */ #endif - +#if defined(CONFIG_PHY_CMD_DELAY) + udelay(CONFIG_PHY_CMD_DELAY); /* Intel LXT971A needs this */ +#endif sta_reg = in32 (EMAC_STACR); i = 0; while ((sta_reg & EMAC_STACR_OC) == 0) { @@ -166,6 +168,9 @@ int miiphy_write (unsigned char addr, un memcpy (&sta_reg, &value, 2); /* put in data */ out32 (EMAC_STACR, sta_reg); +#if defined(CONFIG_PHY_CMD_DELAY) + udelay(CONFIG_PHY_CMD_DELAY); /* Intel LXT971A needs this */ +#endif /* wait for completion */ i = 0; --- u-boot-1.0.0/common/miiphyutil.c 2003-10-08 17:33:00.000000000 -0500 +++ u-boot/common/miiphyutil.c 2004-01-11 22:42:42.249886108 -0600 @@ -103,6 +103,9 @@ int miiphy_reset (unsigned char addr) return (-1); } +#if defined(CONFIG_PHY_RESET_DELAY) + udelay(CONFIG_PHY_RESET_DELAY); /* Intel LXT971A needs this */ +#endif /* * Poll the control register for the reset bit to go to 0 (it is * auto-clearing). This should happen within 0.5 seconds per the

2 1

[Fwd: RE: [U-Boot-Users] Incorrect flash ids?]
by Tolunay Orkun 13 Jan '04

13 Jan '04

Well, there is no end to it. In my previous job, hardware engineer decided to use 64bit bus for flash so we had 4 of them to make 64bit bus(MPC755). So, the 32 bit ones is not enough to compare all 4 anyway. Another perfectly valid (but unusual) scheme is to map 4 devices each in byte mode. That 4 byte ID read would be different that the stored one if you wanted to compare them bus wide. > Because these flashes are 16bit wide and there are usually two of them (one for high order 16bits and one for the low order 16 bits) > >> >> Actually, it is 0x00180018. So, the question is why duplicate >> the id in the high and low order 16 bits? >> >

2 1

[U-Boot-Users] Statically assigned IP addresses
by Kerl, John 13 Jan '04

13 Jan '04

Hello, This is my first time using U-boot and I have what I am sure is a newbie question. However, I am getting an error while attempting to access the archives at SourceForge, so I'll go ahead and post the following. 1. On my Chameleon 405EP board, it appears the Ethernet interface is off by default. While the board is running Linux, the Ethernet interface is *not* brought up by default -- rather, I must type 'ifconfig eth0 up'. This seems strange, but I can live with it. While the board is running U-boot, on the other hand, there does not appear to be a 'bring up Ethernet' command. I have MAC address and IP address set in environment variables, so what else do I need to do to get the board to answer a ping??? 2. Probably the same as the first question -- assigning a static IP address. In our lab, we do not use DHCP; addresses are statically assigned. Is setenv ipaddr {n.n.n.n} sufficient? If not, what else do I need to do? 3. Is this standard U-boot behavior, or is it peculiar to the Chameleon board? On the boards we manufacture (and in our firmware), Ethernet comes up by default. Thanks.

3 3

RE: [U-Boot-Users] Statically assigned IP addresses
by Demke, Torsten 13 Jan '04

13 Jan '04

Hello > > 1. On my Chameleon 405EP board, it appears the Ethernet > interface is off by default. While the board is > running Linux, the Ethernet interface is *not* > brought up by default -- rather, I must type > 'ifconfig eth0 up'. This seems strange, but I can > live with it. While the board is running U-boot, > on the other hand, there does not appear to be a > 'bring up Ethernet' command. I have MAC address and > IP address set in environment variables, so what else > do I need to do to get the board to answer a ping??? U-boot will not answer to a remote ping (no interrupt etc). But you can send a ping from U-boot to a remote target if you have CFG_CMD_PING enabled in your configuration. Did you enable "IP: kernel level autoconfiguration" in your Linux kernel? I use the "bootargs" to give the Linux kernel the appropriate parameters for the eth interfaces. ( setenv bootargs ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):eth0:off ) Regards, Torsten

1 0

[U-Boot-Users] after_reloc
by Neelakantan 13 Jan '04

13 Jan '04

Hi all, I have a doubt.Who is calling the function after_reloc located in board specific c files.What does the assembly command bl mean? What does the line bl board_init_f do? If u anyone of u find time please clear my doubt. ________________________________________________ With Grace, N.S.Neelakantan Extn:88 mailto:neelakantan@isofttech.com

3 2

RE: [U-Boot-Users] Incorrect flash ids?
by Rune Torgersen 13 Jan '04

13 Jan '04

Because these flashes are 16bit wide and there are usually two of them (one for high order 16bits and one for the low order 16 bits) > > Actually, it is 0x00180018. So, the question is why duplicate > the id in the high and low order 16 bits? >

1 0

[U-Boot-Users] Incorrect flash ids?
by listmember＠orkun.us 13 Jan '04

13 Jan '04

Taken from include/flash.c... #define INTEL_ID_28F128J3 0x89189818 /* 16M = 8M x 16 x 128 */ #define INTEL_ID_28F320J5 0x00140014 /* 32M = 128K x 32 */ #define INTEL_ID_28F640J5 0x00150015 /* 64M = 128K x 64 */ #define INTEL_ID_28F320J3A 0x00160016 /* 32M = 128K x 32 */ #define INTEL_ID_28F640J3A 0x00170017 /* 64M = 128K x 64 */ #define INTEL_ID_28F128J3A 0x00180018 /* 128M = 128K x 128 */ If I understand correctly, it seems to me that these definitions are incorrect. I think correct definitions should be as follows: #define INTEL_ID_28F128J3 0x89188918 /* 16M = 8M x 16 x 128 */ #define INTEL_ID_28F320J5 0x89148914 /* 32M = 128K x 32 */ #define INTEL_ID_28F640J5 0x89158915 /* 64M = 128K x 64 */ #define INTEL_ID_28F320J3A 0x89168916 /* 32M = 128K x 32 */ #define INTEL_ID_28F640J3A 0x89178917 /* 64M = 128K x 64 */ #define INTEL_ID_28F128J3A 0x89188918 /* 128M = 128K x 128 */ #define INTEL_ID_28F256L18T 0x880D880D /* 256M = 128K x 255 + 32k x 4 */ Please note that INTEL_ID_28F128J3 also changed (0x89189818 => 0x89188918). I think 8 and 9 changed places due to a typo. Best regards, Tolunay Here is the patch: --- u-boot-1.0.0/include/flash.h 2003-08-29 17:00:48.000000000 -0500 +++ u-boot/include/flash.h 2004-01-12 18:14:33.061103106 -0600 @@ -207,12 +207,12 @@ extern int flash_real_protect(flash_info #define INTEL_ID_28F640C3T 0x88CC88CC /* 64M = 4M x 16 top boot sector */ #define INTEL_ID_28F640C3B 0x88CD88CD /* 64M = 4M x 16 bottom boot sector */ -#define INTEL_ID_28F128J3 0x89189818 /* 16M = 8M x 16 x 128 */ -#define INTEL_ID_28F320J5 0x00140014 /* 32M = 128K x 32 */ -#define INTEL_ID_28F640J5 0x00150015 /* 64M = 128K x 64 */ -#define INTEL_ID_28F320J3A 0x00160016 /* 32M = 128K x 32 */ -#define INTEL_ID_28F640J3A 0x00170017 /* 64M = 128K x 64 */ -#define INTEL_ID_28F128J3A 0x00180018 /* 128M = 128K x 128 */ +#define INTEL_ID_28F128J3 0x89188918 /* 16M = 8M x 16 x 128 */ +#define INTEL_ID_28F320J5 0x89148914 /* 32M = 128K x 32 */ +#define INTEL_ID_28F640J5 0x89158915 /* 64M = 128K x 64 */ +#define INTEL_ID_28F320J3A 0x89168916 /* 32M = 128K x 32 */ +#define INTEL_ID_28F640J3A 0x89178917 /* 64M = 128K x 64 */ +#define INTEL_ID_28F128J3A 0x89188918 /* 128M = 128K x 128 */ #define INTEL_ID_28F256L18T 0x880D880D /* 256M = 128K x 255 + 32k x 4 */ #define INTEL_ID_28F160S3 0x00D000D0 /* 16M = 512K x 32 (64kB x 32) */

2 5

[U-Boot-Users] PCI Enumeration
by John Manby 13 Jan '04

13 Jan '04

Hi, I'm having an issue with U-Boot failing to recognize PCI devices on bootup. I have a CompactPCI chassis with a PowerPC 405GP card and a Valleytech PCI carrier board with a TI 6415 DSP on it. The Valleytech board has an Intel non-transparent PCI bridge chip on it. I also have a PCI carrier board with two custom mezzanine boards that have TI 6415 DSPs on them. We access the DSP PCI interfaces directly on these boards. My problem is that the PCI bus fails to find one of the boards when both are plugged in at the same time. If I only use the Valleytech board, I can talk to it fine; conversely, if I only use our custom, board, it works. When both are plugged in, U-Boot only lists the card device ID for the card furthest from the PPC. The PCI initialization also fails when I boot the Debian kernel in this case. I need to be able to access both cards at the same time so I need to resolve this. I have a lot of experience with commercial RTOSes such at VxWorks, pSos, and OSE, but this is my first embedded Linux project so I am not so sure where to start looking for an answer. Thanks for any and all help!! -John

1 0

Re: [U-Boot-Users] SDRAM Burst Read/Write Test
by Wolfgang Denk 13 Jan '04

13 Jan '04

In message <20040113135842.79885.qmail(a)web41401.mail.yahoo.com> you wrote: > I am talking about initally booting U-Boot. The crash > comes right after initializing the SDRAM, when it is > moving U-Boot from the flash into SDRAM. So I can't > run Linux. I have verified that this is a burst You asked hot to verify that burst mode accesses are working correctly - the test with the best ratio of efficiency vs. reliability is to boot Linux :-) > read/write problem by inhibiting burst operations in > the ORx register for the SDRAM. When I set OR_BI > (SDRAM Burst Inhibit) U-Boot will move on to detecting > the flash. If I allow bursts, I don't get to where > U-Boot detects the flash, and the last printout I see > is: New Stack Pointer is: 00f9ef78. ... For the N+1st time: > > As pointed out several hundret times before, this usually has nothing > > to do with the UPM setup, but is a consequence of missing or bad > > initialization sequence of your SDRAM chips. Implement the chip init sequence as documented in the RAM chip documentation. Best regards, Wolfgang Denk -- See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440 Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. - Frederick Brooks Jr., "The Mythical Man Month"

1 0

RE: [U-Boot-Users] why is USB so slow
by VanBaren, Gerald (AGRE) 13 Jan '04

13 Jan '04

IDE = 16 parallel bus (8MHz? => 128Mbits/second with very little overhead) USB = serial bus with a lot of overhead USB-1.1 == 12Mbits/second USB-2.0 = 480Mbits/second I'm guessing you are running USB-1.1 based on your numbers. gvb > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Laurent > Mohin > Sent: Tuesday, January 13, 2004 2:33 AM > To: U-Boot-Users@Lists. Sourceforge. Net > Subject: [U-Boot-Users] why is USB so slow > > > Hello all, > > I want to submit a question about USB performance. > I'm designing a board with a 405GPr and an Intel PIIX4E Southbridge. > For upgrade purpose, I'm dowloading linux and initrd image > which size is > about 9M bytes. > > With a compact flash on the IDE bus, I issued the command : > fatload ide 2:0 800000 pMulti > and had the file downloaded in 10 seconds > > With a memory key on the USB bus, I sent the command : > fatload usb 0:0 800000 pMulti > and had the file downloaded in 150 seconds > > Has somebody else noticed this behaviour? What is the explanation? > > Laurent MOHIN > ACTERNA > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0