December 2006 - U-Boot

[U-Boot-Users] [PATCH] Infineon ADM5120 support
by Robert Deliën 11 Dec '06

11 Dec '06

Hi, The patch attached adds support for the Infineon ADM5120 (formerly ADMtek ADM5120) SoC to U-Boot. This SoC can be found in countless low-end router products. See http://www.linux-mips.org/wiki/Adm5120#Products_based_on_the_ADM5120 for a list of devices using the ADM5120. This patch applies cleanly if my previous patches have been applied: 1. pnx8550support.diff 2. nxp_i2c.diff 3. mips_timer2.diff 4. nxp_pci.diff 5. serial_pl010.patch (required) This U-Boot port for ADM5120 is a private project of mine. With kind regards, Robert.

1 0

[U-Boot-Users] (no subject)
by Robert Deliën 11 Dec '06

11 Dec '06

Hi, The patch attached adds support for the Infineon ADM5120 (formerly ADMtek ADM5120) SoC to U-Boot. This SoC can be found in countless low-end router products. See http://www.linux-mips.org/wiki/Adm5120#Products_based_on_the_ADM5120 for a list of devices using the ADM5120. This patch applies cleanly if my previous patches have been applied: 1. pnx8550support.diff 2. nxp_i2c.diff 3. mips_timer2.diff 4. nxp_pci.diff 5. serial_pl010.patch (required) This U-Boot port for ADM5120 is a private project of mine. With kind regards, Robert.

1 0

[U-Boot-Users] [PATCH] NXP Semiconductors PCI IP block driver
by Robert Deliën 11 Dec '06

11 Dec '06

Hi, The patch attached contains a driver for the NXP Semiconductors A051 PCI IP block as present on the PNX8550, PNX8535 and PNX8536. The configuration for the SilverBox development target has been updated for PCI support. This patch applies cleanly if my previous patches have been applied: 1. pnx8550support.diff 2. nxp_i2c.diff 3. mips_timer2.diff 4. nxp_pci.diff Either the driver drivers/pci_indirect.c is not processor endianness independent or the IO functionality for MIPS is a bit outdated. In order to satisfy the need of drivers/pci_indirect.c for prototypes of out_le32 etc, I have added externals for those in include/asm-mips/io.h. With kind regards, Robert.

1 0

[U-Boot-Users] Porting U-Boot to AMCC 440 Spe
by William Oppermann 11 Dec '06

11 Dec '06

Has anybody ported U-Boot to the AMCC 440-Spe processor at PVR version 53421891. 1. We have an AMCC Yucca board using a processor with PVR 53421890 (revA silicon), the start.s code runs fine. 2. When running this same code on our board with PVR version 53421891 (revB silicon) we always have an ESR set to 0x8000000, as soon as we enable the MSR[ME] Bit is set we of course get a machine check. 3. We have tried a Denx patch to write all three words of the TLB table (to make sure no parity errors are occuring) however we still have the problem. 4. We have applied a Denx patch to write the TLB table depending on whether its revA or revB silicon. Neither patch has cured the problem? Has anybody seen this issue ? William Oppermann -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.15/581 - Release Date: 09/12/2006

2 1

[U-Boot-Users] U-boot - Access to files
by Ram 11 Dec '06

11 Dec '06

Hi, Im trying to provide something like an audio interface to the bootloader. I want to play some audio - (It could be name of the command or simply "Downloading the kernel") - something like that. Basically, What i want is access to some sound data in flash, i have an small audio driver in place in the boot loader, All i want is to download the audio data file sitting somewhere in the flash and access it. It could be a file or it could be some data flashed at some predetermined location in the flash. Does u-boot provide any facility to do that or has anyone tried that in u-boot?. I know this is some kinda of a wired requirement. Please Advice, Regards, sriram

2 1

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

11 Dec '06

> The above is not true for all MIPS. A lot (almost all) of older MIPS > parts run the cpu CP0 counter at half the core clock rate. Thanks for your feedback; I wasn't aware of this. I've encountered a couple of /2 constructions in some configurations, but I though that was just a quick fix that degrades the granularity of the timer by half in order to prevent overflows in net.c. > I would suggest changing CPU_CLOCK_RATE to CPU_CP0_COUNT_RATE since > they are not always the same. I have changed it to CFG_CP0_COUNT_RATE, if you don't mind. The IncaIP and Purple platform seem to have cores with half-speed COUNT registers so those have been fixed too. Behold the new patch ;-)

1 0

Re: [U-Boot-Users] location independence
by TXEMA LOPEZ 11 Dec '06

11 Dec '06

Is the part of the U-Boot code that is executed from flash "location independent"? By "location independent" I mean code that can be executed from any address range (in flash) without any modification. The target is MPC85xx. I don't know the details of the MPC85xx architecture, I'm only familiar with the MPC5200 architecture but I think both cases could be familiar. The U-Boot code running from flash is linker address dependent, so you can not, by example, put an image of U-Boot in a different address that it was linked and jump to it from a smaller boot. It is because you must reassign the GOT and the FIXUP sections in a similar way It's done when U-Boot is relocated in RAM.

1 0

Re: [U-Boot-Users] new gatherin
by Korbin Mascarenas 10 Dec '06

10 Dec '06

VfAGRA from $3. 30 and other goods. http://www.zaseruijintunhfeunhans.com through that school of his. So watch out for the Durmstrang champion as well. Okay, said Harry slowly. But... are you saying Karkaroff put my name

1 0

[U-Boot-Users] BDI2000 CFG file for 8560
by Dig Dis 10 Dec '06

10 Dec '06

Hello, Got U-boot programmed on a custom board with the MPC8560 CPU (the board is actually derived from the sbc8560 EVB). I'm tryin to debug it with BDI2000, but I'm facing some startup problems. Before diving in, I'd like to make sure I have the proper configuration file for the BDI. Browsed the denx ftp site, but it only holds some PQ2 based files. Can anyone post a proper 8560 (preferably sbc8560 or ads8560 compatible) cfg file? If there is one, I'd kindly ask to update the ftp as well. Regards, D.

2 2

[U-Boot-Users] AM29LV160DB flash + cfi-driver
by Andre Puschmann 10 Dec '06

10 Dec '06

Hey Folks, we got a custom PPC-based board with a 2MB AM29LV160DB flash chip. I am trying to use U-Boots CFI driver but it seems that there are still some problems with this configuration, reading e.g. the wrong vendor id. This is my output if I boot the board: 0.01> U-Boot 1.1.6-ge4bbd8da-dirty (Dec 8 2006 - 12:25:48) 0.01> 0.01> CPU: MPC5200 v1.2, Core v1.1 at 396 MHz 0.03> Bus 132 MHz, IPB 132 MHz, PCI 33 MHz 0.03> Board: MPC5200 ECU 0.03> I2C: 85 kHz, ready 0.03> DRAM: 8 MB 0.03> Top of RAM usable for U-Boot at: 00800000 0.03> Reserving 164k for U-Boot at: 007d6000 0.04> Reserving 129k for malloc() at: 007b5c00 0.04> Reserving 68 Bytes for Board Info at: 007b5bbc 0.04> Reserving 56 Bytes for Global Data at: 007b5b84 0.04> Stack Pointer at: 007b5b68 0.06> New Stack Pointer is: 007b5b68 0.10> Now running in RAM - U-Boot at: 007d6000 0.10> FLASH: flash detect cfi 0.12> fwc addr ffe00000 cmd 0 0 8bit x 8 bit 0.12> fwc addr ffe00055 cmd 98 98 8bit x 8 bit 0.12> is= cmd 51(Q) addr ffe00010 is= ff 51 0.12> fwc addr ffe00000 cmd 0 0000 16bit x 8 bit 0.14> fwc addr ffe000aa cmd 98 9898 16bit x 8 bit 0.14> is= cmd 51(Q) addr ffe00020 is= ffff 5151 0.14> fwc addr ffe00000 cmd 0 0000 16bit x 16 bit 0.14> fwc addr ffe000aa cmd 98 0098 16bit x 16 bit 0.15> is= cmd 51(Q) addr ffe00020 is= ffff 0051 0.15> fwc addr ffe00000 cmd 0 00000000 32bit x 8 bit 0.15> fwc addr ffe00154 cmd 98 98989898 32bit x 8 bit 0.15> is= cmd 51(Q) addr ffe00040 is= ffffffff 51515151 0.17> fwc addr ffe00000 cmd 0 00000000 32bit x 16 bit 0.17> fwc addr ffe00154 cmd 98 00980098 32bit x 16 bit 0.17> is= cmd 51(Q) addr ffe00040 is= ffffffff 00510051 0.18> fwc addr ffe00000 cmd 0 00000000 32bit x 32 bit 0.18> fwc addr ffe00154 cmd 98 00000098 32bit x 32 bit 0.18> is= cmd 51(Q) addr ffe00040 is= ffffffff 00000051 0.18> fwrite addr ffe00000 cmd 0 0000000000000000 64 bit x 8 bit 0.20> fwrite addr ffe002a8 cmd 98 9898989898989898 64 bit x 8 bit 0.20> is= cmd 51(Q) addr ffe00080 is= ffffffffffffffff 5151515151515151 0.21> fwrite addr ffe00000 cmd 0 0000000000000000 64 bit x 16 bit 0.21> fwrite addr ffe002a8 cmd 98 0098009800980098 64 bit x 16 bit 0.21> is= cmd 51(Q) addr ffe00080 is= ffffffffffffffff 0051005100510051 0.23> fwrite addr ffe00000 cmd 0 0000000000000000 64 bit x 32 bit 0.23> fwrite addr ffe002a8 cmd 98 0000009800000098 64 bit x 32 bit 0.23> is= cmd 51(Q) addr ffe00080 is= ffffffffffffffff 0000005100000051 0.25> fwrite addr ffe00000 cmd 0 0000000000000000 64 bit x 64 bit 0.25> fwrite addr ffe002a8 cmd 98 0000000000000098 64 bit x 64 bit 0.25> is= cmd 51(Q) addr ffe00080 is= ffffffffffffffff 0000000000000051 0.26> not found 0.26> ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB 0.26> flash_protect ON: from 0xFFF00000 to 0xFFF23FFF 0.26> flash_protect ON: from 0xFFE0FA00 to 0xFFE0FDFF 0.26> *** failed *** 0.28> ### ERROR ### Please RESET the board ### There already was a discussion about this flash chip and u-boot but this thread doesn't came to an end. http://www.nabble.com/Help%3A-flash-driver-for-CFI-complient-flash-t893564.… Any hints? Best regards, Andre

1 0

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

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

07 Dec '06

Hello, I'm ready to re-submit a hard SPI driver for some members of the MPC83xx family of CPUs, but am unsure where to put it. While designed for the MPC834x chips, it should also work with the upcoming MPC8313, if the online datasheet is accurate. The other 83xx chips handle SPI with a CPM, so this driver won't work there. Should I put it in cpu/mpc83xx/, drivers/, or somewhere else? And given the unusual chip compatibilities, what should the file be called? Suggestions? regards, Ben

5 5

[U-Boot-Users] possible ELDK4 gcc compiler bug
by Matthias Fuchs 07 Dec '06

07 Dec '06

Hi, I noticed some strange behavior when using the ELDK4 gcc for compiling U-Boot for a (new) 405 target based on the current PMC405 board. The code needs to read-modify-write a memory mapped FPGA internal register. But the FPGA access does not appear in the object and therefore it is never done. Here are some code snippets: 1) my 'fifo' BSP command: int do_fifo(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) { struct pmc405v2_fpga_s *fpga = (struct pmc405v2_fpga_s *)FPGA_BA; int i; int n = 0; u32 ctrl, data, f; char str[] = "\\|/-"; int abort = 0; int count = 0; int count2 = 0; switch(argc) { case 2: /* completely read out fifo 'n' */ if (!strcmp(argv[1],"read")) { printf(" # fifo level data\n"); printf("__________________________________\n"); for (i=0; i<FIFO_COUNT; i++) { dump_fifo(fpga, i, &n); } } else if (!strcmp(argv[1],"wait")) { got_fifoirq = 0; irq_install_handler (FPGA_IRQ, (interrupt_handler_t *)fpga_interrupt, (void*)fpga); printf(" # fifo level data\n"); printf("__________________________________\n"); fpga->ctrl |= CTRL_FIFO_IE; for (i=0; i<FIFO_COUNT; i++) { /* enable interrupts from all fifos */ printf("DEBUG1: %p:%08x\n", &(fpga->fifo[i].ctrl), fpga->fifo[i].ctrl); --> These RMW-ops do not appear in the object and is never done! --> fpga->fifo[i].ctrl |= 0x8000; printf("DEBUG2: %p:%08x\n", &(fpga->fifo[i].ctrl), fpga->fifo[i].ctrl); } while (1) { /* wait loop */ while(!got_fifoirq) { ... 2) Here are the used structs for the fpga variable: struct pmc405v2_fifo_s { volatile u32 data; volatile u32 ctrl; }; /* fifo ctrl register */ #define FIFO_OVERFLOW 0x00000400 #define FIFO_EMPTY 0x00000200 #define FIFO_FULL 0x00000100 #define FIFO_IE 0x00008000 #define FIFO_LEVEL_MASK 0x000000ff #define FIFO_COUNT 4 struct pmc405v2_fpga_s { volatile u32 ctrl; volatile u32 status; volatile u32 test1; volatile u32 test2; u32 pad1[0x60 / sizeof(u32) - 4]; volatile u32 hostctrl; /* 0x0060 */ u32 pad2[0x20 / sizeof(u32) - 1]; struct pmc405v2_fifo_s fifo[FIFO_COUNT]; /* 0x0080..0x009f */ }; 3) Here are some lines from the objectdump. I do not find anything from the RMW-op to the FPGA register (fpga->fifo[i].ctrl |= 0x8000;). /data/home/matthias/projects/pmc405/V2_u-boot.git/board/esd/pmc405v2/cmd_pmc405v2.c:556 dd8: 48 00 00 01 bl dd8 <do_fifo+0x178> dd8: R_PPC_PLTREL24 printf /data/home/matthias/projects/pmc405/V2_u-boot.git/board/esd/pmc405v2/cmd_pmc405v2.c:558 ddc: 3d 20 ef 00 lis r9,-4352 de0: 80 09 00 00 lwz r0,0(r9) de4: 3b 40 00 00 li r26,0 de8: 60 00 02 00 ori r0,r0,512 dec: 90 09 00 00 stw r0,0(r9) df0: 7f 7f db 78 mr r31,r27 /data/home/matthias/projects/pmc405/V2_u-boot.git/board/esd/pmc405v2/cmd_pmc405v2.c:561 for (i=0; i<FIFO_COUNT; i++) { /* enable interrupts from all fifos */ printf("DEBUG1: %p:%08x\n", df4: 83 9b 00 00 lwz r28,0(r27) df8: 80 7e 80 cc lwz r3,-32564(r30) dfc: 7f e4 fb 78 mr r4,r31 e00: 7f 85 e3 78 mr r5,r28 e04: 48 00 00 01 bl e04 <do_fifo+0x1a4> e04: R_PPC_PLTREL24 printf /data/home/matthias/projects/pmc405/V2_u-boot.git/board/esd/pmc405v2/cmd_pmc405v2.c:564 &(fpga->fifo[i].ctrl), fpga->fifo[i].ctrl); fpga->fifo[i].ctrl |= 0x8000; printf("DEBUG2: %p:%08x\n", e08: 80 7e 80 d0 lwz r3,-32560(r30) e0c: 7f e4 fb 78 mr r4,r31 e10: 7f 85 e3 78 mr r5,r28 e14: 48 00 00 01 bl e14 <do_fifo+0x1b4> e14: R_PPC_PLTREL24 printf /data/home/matthias/projects/pmc405/V2_u-boot.git/board/esd/pmc405v2/cmd_pmc405v2.c:559 e18: 2f 9a 00 03 cmpwi cr7,r26,3 e1c: 3b ff 00 08 addi r31,r31,8 e20: 3b 7b 00 08 addi r27,r27,8 e24: 3b 5a 00 01 addi r26,r26,1 e28: 40 9e ff cc bne+ cr7,df4 <do_fifo+0x194> e2c: 3b e0 00 00 li r31,0 e30: 48 00 00 6c b e9c <do_fifo+0x23c> /data/home/matthias/projects/pmc405/V2_u-boot.git/board/esd/pmc405v2/cmd_pmc405v2.c:571 &(fpga->fifo[i].ctrl), fpga->fifo[i].ctrl); } while (1) { /* wait loop */ while(!got_fifoirq) { count++; e34: 3b ff 00 01 addi r31,r31,1 /data/home/matthias/projects/pmc405/V2_u-boot.git/board/esd/pmc405v2/cmd_pmc405v2.c:572 4) This is how the compiler is called for the code file: ppc_4xx-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0xFFF80000 -I/data/home/matthias/projects/pmc405/V2_u-boot.git/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/eldk_400/usr/bin/../lib/gcc/powerpc-linux/4.0.0/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 -mstring -Wa,-m405 -mcpu=405 -msoft-float -Wall -Wstrict-prototypes -c -o cmd_pmc405v2.o cmd_pmc405v2.c Any idea about what I am doing wrong? BTW: Using -O0 instead of -Os makes everything fine - at least for the code above. Matthias -- ----------------------------------------------------------------------- Dipl.-Ing. Matthias Fuchs esd electronic system design gmbh http://www.esd-electronics.com Vahrenwalder Str. 207 phone: +49-511-37298-0, fax: -68 30165 Hannover, Germany -----------------------------------------------------------------------

5 9

Re: [U-Boot-Users] [PATCH] 83xx: Put the version (and magic) after the HRCW.
by Joakim Tjernlund 07 Dec '06

07 Dec '06

> -----Original Message----- > From: u-boot-users-bounces(a)lists.sourceforge.net > [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf > Of Jerry Van Baren > Sent: 07 December 2006 14:23 > To: Joakim Tjernlund > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] [PATCH] 83xx: Put the version > (and magic) after the HRCW. > > Joakim Tjernlund wrote: > >> Sam Song wrote: > >>> Jerry Van Baren <gerald.vanbaren(a)comcast.net> wrote: > >>>> 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. > >>> Nice effort. Space saving and better version check. > >>> > >>> I guess the same change could apply for MPC8260/47/8. > >>> > >>> Thanks, > >>> > >>> Sam > >> Yes. Most boards have the version in the first bytes of > >> flash, but this > >> was not possible on the 82xx because of the HRCW, so it was put in > >> .data. This set up was copied for the 83xx (which also has a > >> HRCW). My > >> change moves it back to .text just after the HRCW. I put also the > >> u-boot magic number back in in honor of Wolfgang. ;-) > >> > >> If you change the file names in the patch, it probably would > >> apply. :-) > >> I intend to do this (perhaps literally), but ran out of > >> ambition tonight. > >> > > > > Looks almost the same as the patch I sent the other day. I am good > > with either version. > > > > Jocke > > Hi Jocke, > > Yes, your patch, and my objection to its removal of the HRCW, was the > genesis of this one. The two differences are (a) I kept the HRCW and > (b) I put the "u-boot magic number" in (no known reason to do > this, but > it Just Seemed Right[tm]). The result of (b) is that the > version starts > at flash offset 0x44 rather than 0x40. Should be NBD. (a) yeah, I don't really need this either, I just added that to give others a choice. (b) uh, I want the "u-boot magic number". If I didn't have it in my patch then it was a typo. Thanks Jocke

1 0

Re: [U-Boot-Users] [DNX#2006120742000027] [PATCH] Add support for 8641 Rev 2 silicon.
by DENX Support System 07 Dec '06

07 Dec '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006120742000027] was created: <snip> > From: Ed Swarthout <ed.swarthout(a)freescale.com> > > Without this patch, I am unable to get to the prompt on rev 2 silicon. > Only set ddrioovcr for rev1. > > Signed-off-by: Ed Swarthout<ed.swarthout(a)freescale.com> > Signed-off-by: Jon Loeliger <jdl(a)freescale.com> > --- > cpu/mpc86xx/spd_sdram.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/cpu/mpc86xx/spd_sdram.c b/cpu/mpc86xx/spd_sdram.c > index b18e822..ac9ff81 100644 > --- a/cpu/mpc86xx/spd_sdram.c > +++ b/cpu/mpc86xx/spd_sdram.c > @@ -284,9 +284,9 @@ #endif > } > > /* > - * Adjust DDR II IO voltage biasing. It just makes it work. > + * Adjust DDR II IO voltage biasing. Rev1 only > */ > - if (spd.mem_type == SPD_MEMTYPE_DDR2) { > + if (((get_svr() & 0xf0) == 0x10) && (spd.mem_type == > SPD_MEMTYPE_DDR2)) { > gur->ddrioovcr = (0 > | 0x80000000 /* Enable */ > | 0x10000000 /* VSEL to 1.8V */ > -- > 1.4.2.3 </snip> Your U-Boot support team

1 0

Re: [U-Boot-Users] [DNX#2006120742000036] [PATCH] Set Rev 2.x 86xx PIC in mixed mode.
by DENX Support System 07 Dec '06

07 Dec '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006120742000036] was created: <snip> > From: Haiying Wang <haiying.wang(a)freescale.com> > > Prevent false interrupt from hanging Linux as MSR[EE] is set > to enable interrupts by changing the PIC out of the default > pass through mode into mixed mode. > > Signed-off-by: Haiying Wang <haiying.wang(a)freescale.com> > Signed-off-by: Jon Loeliger <jdl(a)freescale.com> > --- > cpu/mpc86xx/interrupts.c | 20 ++++++++++++++++++++ > include/asm-ppc/immap_86xx.h | 2 ++ > 2 files changed, 22 insertions(+), 0 deletions(-) > > diff --git a/cpu/mpc86xx/interrupts.c b/cpu/mpc86xx/interrupts.c > index 1df6cdc..49820bb 100644 > --- a/cpu/mpc86xx/interrupts.c > +++ b/cpu/mpc86xx/interrupts.c > @@ -80,6 +80,26 @@ int interrupt_init(void) > { > int ret; > > + /* > + * The IRQ0 on Rev 2 is pulled high (low in Rev 1.x) to > + * implement PEX10 errata. As INT is active high, it > + * will cause core to take 0x500 interrupt. > + * > + * Due to the PIC's default pass through mode, as soon > + * as interrupts are enabled (MSR[EE] = 1), an interrupt > + * will be taken and u-boot will hang. This is due to a > + * hardware change (per an errata fix) on new revisions > + * of the board with Rev 2.x parts. > + * > + * Setting the PIC to mixed mode prevents the hang. > + */ > + if ((get_svr() & 0xf0) == 0x20) { > + volatile immap_t *immr = (immap_t *)CFG_IMMR; > + immr->im_pic.gcr = MPC86xx_PICGCR_RST; > + while (immr->im_pic.gcr & MPC86xx_PICGCR_RST); > + immr->im_pic.gcr = MPC86xx_PICGCR_MODE; > + } > + > /* call cpu specific function from $(CPU)/interrupts.c */ > ret = interrupt_init_cpu(&decrementer_count); > > diff --git a/include/asm-ppc/immap_86xx.h b/include/asm-ppc/immap_86xx.h > index a5552c4..0e3fc34 100644 > --- a/include/asm-ppc/immap_86xx.h > +++ b/include/asm-ppc/immap_86xx.h > @@ -721,6 +721,8 @@ typedef struct ccsr_pic { > uint frr; /* 0x41000 - Feature Reporting Register */ > char res10[28]; > uint gcr; /* 0x41020 - Global Configuration Register */ > +#define MPC86xx_PICGCR_RST 0x80000000 > +#define MPC86xx_PICGCR_MODE 0x20000000 > char res11[92]; > uint vir; /* 0x41080 - Vendor Identification Register */ > char res12[12]; > -- > 1.4.2.3 </snip> Your U-Boot support team

1 0