December 2006 - U-Boot

Re: [U-Boot-Users] [DNX#2006120942000014] new morticia
by U-Boot patch tracking system 09 Dec '06

09 Dec '06

Dear Mr. U. Boot, thank you for your contribution to the U-Boot project. Your e-mail was registered at our system under the ticket number [DNX#2006120942000014]. Please keep this ticket ID string in the subject line of any e-mail replies!!! Your U-Boot support team Powered by OTRS (http://otrs.org/)

1 0

[U-Boot-Users] [PATCH] 83xx: Put the version (and magic) after the HRCW.
by Jerry Van Baren 08 Dec '06

08 Dec '06

Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the start of flash but as close as we can get. Signed-off-by: Jerry Van Baren <vanbaren(a)cideas.com> Put the version (and magic) after the HRCW. This puts it in a fixed location in flash, not at the start of flash but as close as we can get. Signed-off-by: Jerry Van Baren <vanbaren(a)cideas.com> --- cpu/mpc83xx/start.S | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-) diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S index 0f27bb6..6ee9ec9 100644 --- a/cpu/mpc83xx/start.S +++ b/cpu/mpc83xx/start.S @@ -77,19 +77,11 @@ END_GOT /* - * Version string - must be in data segment because MPC83xx uses the - * first 256 bytes for the Hard Reset Configuration Word table (see - * below). Similarly, can't have the U-Boot Magic Number as the first - * thing in the image - don't know how this will affect the image tools, - * but I guess I'll find out soon. + * The Hard Reset Configuration Word (HRCW) table is in the first 64 + * (0x40) bytes of flash. It has 8 bytes, but each byte is repeated 8 + * times so the processor can fetch it out of flash whether the flash + * is 8, 16, 32, or 64 bits wide (hardware trickery). */ - .data - .globl version_string -version_string: - .ascii U_BOOT_VERSION - .ascii " (", __DATE__, " - ", __TIME__, ")" - .ascii " ", CONFIG_IDENT_STRING, "\0" - .text #define _HRCW_TABLE_ENTRY(w) \ .fill 8,1,(((w)>>24)&0xff); \ @@ -100,6 +92,18 @@ version_string: _HRCW_TABLE_ENTRY(CFG_HRCW_LOW) _HRCW_TABLE_ENTRY(CFG_HRCW_HIGH) +/* + * Magic number and version string - put it after the HRCW since it + * cannot be first in flash like it is in many other processors. + */ + .long 0x27051956 /* U-Boot Magic Number */ + + .globl version_string +version_string: + .ascii U_BOOT_VERSION + .ascii " (", __DATE__, " - ", __TIME__, ")" + .ascii " ", CONFIG_IDENT_STRING, "\0" + #ifndef CONFIG_DEFAULT_IMMR #error CONFIG_DEFAULT_IMMR must be defined -- 1.4.3.3

4 9

[U-Boot-Users] [PATCH] MIPS time.c fix
by Robert Deliën 08 Dec '06

08 Dec '06

Hi, The patch attached makes the MIPS timer function get_timer return time in CFG_HZ ticks, where CFG_HZ is set to 1000 per default. The functions get_ticks and get_tbclk still work using the actual number of COUNT register increments per second, which is equal to the cpu clock frequency for MIPS processors. With kind regards, Robert.

2 1

[U-Boot-Users] (no subject)
by s.maiti＠tcs.com 08 Dec '06

08 Dec '06

Hi All, I am using linux-2.4.25 kernel and ELDK3.1 toolchain for my Custom PPC(MPC8260) board. I am using the ramdisk image which is come along with the ELDK. With this board is coming up. Now I wanted to upgrade my busybox-0.65 to busybox-1.1.3 So I installed the new busy box and copied the bin sbin and usr directories to the filesytem . When i tried to do tftp it is giving following errors. Looking up port of RPC 100005/1 on 172.18.18.59 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 56k init kmod: runaway modprobe loop assumed and stopped kmod: runaway modprobe loop assumed and stopped kmod: failed to exec /sbin/modprobe -s -k binfmt-4c46, errno = 8 (endless loop) With the old busybox it is working fine. Please kindly help me in this regard. Thanks and regards, Souvik Maiti Tata Consultancy Services Mailto: s.maiti(a)tcs.com Website: http://www.tcs.com =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

2 1

[U-Boot-Users] get_timer versus get_ticks
by Robert Deliën 08 Dec '06

08 Dec '06

Hello, I am currently straightening out lib-mips/time.c to make its granularity defined by CFG_HZ (=1000) instead of the processors frequency at which MIPS counters normally run. Can somebody explain me what the difference between get_timer and get_ticks is? Get_timer returns the current value of the timer in 1/CFG_HZ units, as I would expect. I would expect get_ticks to return the raw counter value, but that value would useless because theres no way to tell what speed its running at: get_tbclk is returning CFG_HZ and not the actual counter incremental frequency. In common/main.c get_ticks is used in conjuction with get_tbclk as if it were get_timer. This indicates either get_tbclk should be returning the actual counter incremental frequency, or get_ticks to return the same value as get_timer(0). I have looked at the PPC implementation, but that wasnt of much help because there a hardware time base is used so that solution always correct. Thanks in advance! With kind regards, Robert.

1 0

Re: [U-Boot-Users] [DNX#2006120842000016] frontwis VIAttGRA
by DENX Support System 08 Dec '06

08 Dec '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006120842000016] was created: <snip> > Hi, your V / AGRA from $ 3, 30 http://www.plontunhandfenhadesin.com > - > Floyd, said Floyd. </snip> Your U-Boot support team

1 0

Re: [U-Boot-Users] [DNX#2006120842000016] frontwis VIAttGRA
by U-Boot patch tracking system 08 Dec '06

08 Dec '06

Dear Mr. U. Boot, thank you for your contribution to the U-Boot project. Your e-mail was registered at our system under the ticket number [DNX#2006120842000016]. Please keep this ticket ID string in the subject line of any e-mail replies!!! Your U-Boot support team Powered by OTRS (http://otrs.org/)

1 0

[U-Boot-Users] usbtty windows driver
by Chris Boger 08 Dec '06

08 Dec '06

Hello all, I *think* that I have properly ported the usbtty functionality to my XScale-based board, but I'm having some issues using it via a Windows host. I started off thinking that once implemented, this would be recognized by Windows (using the proper INF file) and use the built-in usbser.sys driver on my Windows XP host. But, I've been having a heck of a time getting that to work. My device is enumerates and passes the USB-IF chapter 9 compliance tools just fine. It shows up in the Device Manager under the Ports section as a COM port with a yellow slash over it. After digging deeper into the code and the USB documentation, I see that u-boot's usbtty doesn't seem follow the Serial Emulation Abstract Control Model (section 3.6.2.1 of the CDC spec) like I thought it did. In fact, USBTTY_INTERFACE_CLASS is defined as 0xFF (vendor specific) and not 0x02 (communication class). I also noticed that we don't use the interrupt IN endpoint at all. So, am I totally wrong here or does our usbtty require a custom Windows device driver? Best Regards, Crhis

1 0

Re: [U-Boot-Users] MPC83xx SPI driver
by Ben Warren 08 Dec '06

08 Dec '06

On Thu, 2006-12-07 at 23:49 +0100, Joakim Tjernlund wrote: > > Didn't find any other SPI driver. Looked at the docs > for SPI in CPU mode for 832x and I don't get the command register > where one is supposed to set a bit if the char one is about to TX is > the last one in a frame. Should I just set that bit at driver > init and be done with it? > > Jocke Maybe somebody from Freescale can weigh in on this one. The 83xx driver that's in the Linux kernel doesn't touch this bit (LTS). The 834x manual says that if LTS is set before the last character is written, an LT event will occur after physical transmission is complete. In my experience LT never fires regardless of LTS state. With the 834x the LTS scheme seems a bit pointless since there's only one transmit buffer. I'm guessing the LTS isn't really implemented and the documentation was cut'n'pasted from another chip. On CPM-based chips like yours, it might be useful to queue a bunch of buffers, start them off and then be interrupted when transmission's complete, just as you would with Ethernet, HDLC or whatever. I guess it depends how big your messages are. If they're short and fit in a single buffer, you could probably just ignore LTS, mask off the LT interrupt and move on. regards, Ben

1 0

Re: [U-Boot-Users] MPC83xx SPI driver
by Ben Warren 07 Dec '06

07 Dec '06

On Thu, 2006-12-07 at 23:31 +0100, Joakim Tjernlund wrote: > > Doubtful, since the 834x and 8313 don't have QUICC engines. While the > > control registers appear to be common among all 83xx chips, on these > > ones transmit and receive are handled by dedicated 32-bit registers > > rather than the RAM-based descriptor types found in CPMs. > > Ahh, that's probably why the 83xx spi driver in linux won't work > on 8321 either. Could you comment on that? Yes, that's correct. I don't know for sure, but it looks to me that the SPI engine on the 8321/8360 chips has more in common with the traditional PowerQUICC chips like 8xx and 82xx. Maybe there's a Linux driver for them that you could tweak? regards, Ben

1 0