October 2007 - U-Boot

[U-Boot-Users] Low power mode in 85xx
by robert lazarski 03 Oct '07

03 Oct '07

Hi all, Can anyone tell me how it is possible for the e500 core to enter power management modes very early in the u-boot code? Note here that this session shows the MRE[WE] bit to be set in the first few lines in of start.S - and the exact address this happens is seemingly random: ATUM>ti Target CPU : MPC85xx (e500v2 rev.2) Core state : halted Debug entry cause : single step Current PC : 0xfffff020 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000 ATUM>ti - Core status is 0x0041 *** Core is stopped, no debugging possible # PPC: timeout while waiting for halt ATUM> Target CPU : MPC85xx (e500v2 rev.2) Core state : halted Debug entry cause : COP freeze Current PC : 0xfffff020 Current CR : 0x0105941c Current MSR : 0x01064744 Current LR : 0x00021f3a Current CCSRBAR : 0x0_e0000000 # Step timeout detected Disassembly shows fffff020 to be way be the tlb1_entry. What is setting this bit? My understanding is it just doesn't happen by itself - something must be setting it right? BDI support tells me that this has been a known issue for 85xx, and while a fix was tested for 8560 they are unsure if the fix was ever tested on 8548. Thanks, Robert

1 1

[U-Boot-Users] a problem about PCI initialization
by Lucas Jin 03 Oct '07

03 Oct '07

Hi I am debugging a board based on Sandpoint8245. sandpoint8245.h has these defination: ( #define PCI_ENET0_IOADDR 0x80000000 #define PCI_ENET0_MEMADDR 0x80000000 #define PCI_ENET1_IOADDR 0x81000000 #define PCI_ENET1_MEMADDR 0x81000000 #define PCI_ENET2_IOADDR 0x00000000 #define PCI_ENET2_MEMADDR 0x82000000 ) sandpoint.c has this defination: static struct pci_config_table pci_sandpoint_config_table[] = { { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x0f, PCI_ANY_ID, pci_cfgfunc_config_device, { PCI_ENET0_IOADDR, PCI_ENET0_MEMADDR, PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER }}, { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x10, PCI_ANY_ID, pci_cfgfunc_config_device, { PCI_ENET1_IOADDR, PCI_ENET1_MEMADDR, PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER }}, { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x18, PCI_ANY_ID, pci_cfgfunc_config_device, { PCI_ENET2_IOADDR, PCI_ENET2_MEMADDR, PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER }}, { } }; After calling pci_init() I output a value to address 0x80000000 and then CPU goes wront. I am so confused. If any of you can give me some hint, I will appreciate that very much! Best Wishes Jinlu

1 0

[U-Boot-Users] {pharm_subj}
by Vonda Monroe 03 Oct '07

03 Oct '07

Special internet pricing!* Men`s Health* Anti-depressants* Weight Loss* Women`s Health* Anti-diabetics* Blood Pressure/Cholesterol* Anti-Allergic/Asthma preparations* Anti Intragastric AcidityWe ship WorldWide directly to your home!No Doctor visit,prescription is not required. http://abxbev.fruitby.cn/?539712989496Come and See our Newly-opened Discount Shop and HUSBAND YOUR cash!!! are no pyjamas for officers or men in these "crawls," as they are after another turned toward the harbour's entrance. A third man was the best illustration of shell-destructiveness. Bullets and his Britons in the most trying and picturesque adventure of its Americans, learn that we do not act individually in such cases? That adaptability to the kind of warfare which was the one kind that the and the American. This is the vital point of similarity which is the A writer can make a lot of the burst of a single shell; a photographer

1 0

[U-Boot-Users] [PATCH] Remove magic numbers from cache related operations for mpc85xx
by Kumar Gala 02 Oct '07

02 Oct '07

The mpc85xx start code uses some magic numbers that we actually have #defines for in <config.h> so use those instead. Signed-off-by: Kumar Gala <galak(a)kernel.crashing.org> --- cpu/mpc85xx/start.S | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S index 2c98c2a..02c0a65 100644 --- a/cpu/mpc85xx/start.S +++ b/cpu/mpc85xx/start.S @@ -266,13 +266,13 @@ _start_e500: */ lis r3,CFG_INIT_RAM_ADDR@h ori r3,r3,CFG_INIT_RAM_ADDR@l - li r2,512 /* 512*32=16K */ + li r2,(CFG_DCACHE_SIZE / (2 * CFG_CACHELINE_SIZE)) mtctr r2 li r0,0 1: dcbz r0,r3 dcbtls 0,r0,r3 - addi r3,r3,32 + addi r3,r3,CFG_CACHELINE_SIZE bdnz 1b /* Jump out the last 4K page and continue to 'normal' start */ @@ -1061,11 +1061,11 @@ unlock_ram_in_cache: /* invalidate the INIT_RAM section */ lis r3,(CFG_INIT_RAM_ADDR & ~31)@h ori r3,r3,(CFG_INIT_RAM_ADDR & ~31)@l - li r4,512 + li r4,(CFG_DCACHE_SIZE / (2 * CFG_CACHELINE_SIZE)) mtctr r4 1: icbi r0,r3 dcbi r0,r3 - addi r3,r3,32 + addi r3,r3,CFG_CACHELINE_SIZE bdnz 1b sync /* Wait for all icbi to complete on bus */ isync -- 1.5.2.4

1 0

[U-Boot-Users] [PATCH] Bugfix: Use only one PTD for one endpoint
by Timo Ketola 02 Oct '07

02 Oct '07

Original isp116x-hcd code prepared multiple PTDs for longer than 16 byte transfers for one endpoint. That is unnecessary because the ISP116x is able to split long data from one PTD into multiple transactions based on the buffer size of the endpoint. It also caused serious problems if the endpoint NAKed some of the transactions. In that case ISP116x wouldn't notice that the other PTDs were for the same endpoint and would try the other PTDs possibly out of order. That would break the whole transfer. This patch makes isp116x_submit_job to use one PTD for one transfer. Signed-off-by: Timo Ketola <timo.ketola(a)exertus.fi> --- --- a/drivers/isp116x-hcd.c 2007-09-07 18:43:36.000000000 +0300 +++ b/drivers/isp116x-hcd.c 2007-09-24 13:10:50.000000000 +0300 @@ -113,9 +113,9 @@ static const char hcd_name[] = "isp116x- struct isp116x isp116x_dev; struct isp116x_platform_data isp116x_board; -int got_rhsc = 0; /* root hub status change */ +static int got_rhsc; /* root hub status change */ struct usb_device *devgone; /* device which was disconnected */ -int rh_devnum = 0; /* address of Root Hub endpoint */ +static int rh_devnum; /* address of Root Hub endpoint */ /* ------------------------------------------------------------------------- */ @@ -522,11 +522,13 @@ static int unpack_fifo(struct isp116x *i done += PTD_GET_LEN(&ptd[i]); cc = PTD_GET_CC(&ptd[i]); - if (cc == TD_DATAUNDERRUN) { /* underrun is no error... */ - DBG("allowed data underrun"); - cc = TD_CC_NOERROR; - } - if (cc != TD_CC_NOERROR && ret == TD_CC_NOERROR) + + /* Data underrun means basically that we had more buffer space than + * the function had data. It is perfectly normal but upper levels have + * to know how much we actually transferred. + */ + if (cc == TD_NOTACCESSED || + (cc != TD_CC_NOERROR && (ret == TD_CC_NOERROR || ret == TD_DATAUNDERRUN))) ret = cc; } @@ -592,11 +594,19 @@ static int isp116x_interrupt(struct isp1 return ret; } -#define PTD_NUM 64 /* it should be enougth... */ -struct ptd ptd[PTD_NUM]; +/* With one PTD we can transfer almost 1K in one go; + * HC does the splitting into endpoint digestible transactions + */ +struct ptd ptd[1]; + static inline int max_transfer_len(struct usb_device *dev, unsigned long pipe) { - return min(PTD_NUM * usb_maxpacket(dev, pipe), PTD_NUM * 16); + unsigned mpck = usb_maxpacket(dev, pipe); + + /* One PTD can transfer 1023 bytes but try to always + * transfer multiples of endpoint buffer size + */ + return 1023 / mpck * mpck; } /* Do an USB transfer @@ -610,13 +620,21 @@ static int isp116x_submit_job(struct usb int max = usb_maxpacket(dev, pipe); int dir_out = usb_pipeout(pipe); int speed_low = usb_pipeslow(pipe); - int i, done, stat, timeout, cc; - int retries = 10; + int i, done = 0, stat, timeout, cc; + + /* 500 frames or 0.5s timeout when function is busy and NAKs transactions for a while */ + int retries = 500; DBG("------------------------------------------------"); dump_msg(dev, pipe, buffer, len, "SUBMIT"); DBG("------------------------------------------------"); + if (len >= 1024) { + ERR("Too big job"); + dev->status = USB_ST_CRC_ERR; + return -1; + } + if (isp116x->disabled) { ERR("EPIPE"); dev->status = USB_ST_CRC_ERR; @@ -653,29 +671,15 @@ static int isp116x_submit_job(struct usb isp116x_write_reg32(isp116x, HCINTSTAT, 0xff); /* Prepare the PTD data */ - done = 0; - i = 0; - do { - ptd[i].count = PTD_CC_MSK | PTD_ACTIVE_MSK | - PTD_TOGGLE(usb_gettoggle(dev, epnum, dir_out)); - ptd[i].mps = PTD_MPS(max) | PTD_SPD(speed_low) | PTD_EP(epnum); - ptd[i].len = PTD_LEN(max > len - done ? len - done : max) | - PTD_DIR(dir); - ptd[i].faddr = PTD_FA(usb_pipedevice(pipe)); - - usb_dotoggle(dev, epnum, dir_out); - done += PTD_GET_LEN(&ptd[i]); - i++; - if (i >= PTD_NUM) { - ERR("****** Cannot pack buffer! ******"); - dev->status = USB_ST_BUF_ERR; - return -1; - } - } while (done < len); - ptd[i - 1].mps |= PTD_LAST_MSK; + ptd->count = PTD_CC_MSK | PTD_ACTIVE_MSK | + PTD_TOGGLE(usb_gettoggle(dev, epnum, dir_out)); + ptd->mps = PTD_MPS(max) | PTD_SPD(speed_low) | PTD_EP(epnum) | PTD_LAST_MSK; + ptd->len = PTD_LEN(len) | PTD_DIR(dir); + ptd->faddr = PTD_FA(usb_pipedevice(pipe)); +retry_same: /* Pack data into FIFO ram */ - pack_fifo(isp116x, dev, pipe, ptd, i, buffer, len); + pack_fifo(isp116x, dev, pipe, ptd, 1, buffer, len); #ifdef EXTRA_DELAY wait_ms(EXTRA_DELAY); #endif @@ -738,17 +742,42 @@ static int isp116x_submit_job(struct usb } /* Unpack data from FIFO ram */ - cc = unpack_fifo(isp116x, dev, pipe, ptd, i, buffer, len); + cc = unpack_fifo(isp116x, dev, pipe, ptd, 1, buffer, len); + + i = PTD_GET_COUNT(ptd); + done += i; + buffer += i; + len -= i; - /* Mmm... sometime we get 0x0f as cc which is a non sense! - * Just retry the transfer... + /* There was some kind of real problem; Prepare the PTD again + * and retry from the failed transaction on */ - if (cc == 0x0f && retries-- > 0) { - usb_dotoggle(dev, epnum, dir_out); - goto retry; + if (cc && cc != TD_NOTACCESSED && cc != TD_DATAUNDERRUN) { + if (retries >= 100) { + retries -= 100; + /* The chip will have toggled the toggle bit for the failed + * transaction too. We have to toggle it back. + */ + usb_settoggle(dev, epnum, dir_out, !PTD_GET_TOGGLE(ptd)); + goto retry; + } + } + /* "Normal" errors; TD_NOTACCESSED would mean in effect that the function have NAKed + * the transactions from the first on for the whole frame. It may be busy and we retry + * with the same PTD. PTD_ACTIVE (and not TD_NOTACCESSED) would mean that some of the + * PTD didn't make it because the function was busy or the frame ended before the PTD + * finished. We prepare the rest of the data and try again. + */ + else if (cc == TD_NOTACCESSED || PTD_GET_ACTIVE(ptd) || (cc != TD_DATAUNDERRUN && PTD_GET_COUNT(ptd) < PTD_GET_LEN(ptd))) { + if (retries) { + --retries; + if (cc == TD_NOTACCESSED && PTD_GET_ACTIVE(ptd) && !PTD_GET_COUNT(ptd)) goto retry_same; + usb_settoggle(dev, epnum, dir_out, PTD_GET_TOGGLE(ptd)); + goto retry; + } } - if (cc != TD_CC_NOERROR) { + if (cc != TD_CC_NOERROR && cc != TD_DATAUNDERRUN) { DBG("****** completition code error %x ******", cc); switch (cc) { case TD_CC_BITSTUFFING: @@ -766,6 +795,7 @@ static int isp116x_submit_job(struct usb } return -cc; } + else usb_settoggle(dev, epnum, dir_out, PTD_GET_TOGGLE(ptd)); dump_msg(dev, pipe, buffer, len, "SUBMIT(ret)"); @@ -1369,6 +1399,8 @@ int usb_lowlevel_init(void) DBG(""); + got_rhsc = rh_devnum = 0; + /* Init device registers addr */ isp116x->addr_reg = (u16 *) ISP116X_HCD_ADDR; isp116x->data_reg = (u16 *) ISP116X_HCD_DATA;

2 2

[U-Boot-Users] [PATCH] Add definition of SA1110 register for PXA2xx processors.
by Thierry Reding 02 Oct '07

02 Oct '07

This patch adds the SA1110 register definition for PXA2xx processors. I could only get my hands on a PXA27x developer's manual, but I'm assuming the register is available on previous generations as well. If not it should be moved into a CONFIG_PXA27X section. Cheers, Thierry --- include/asm-arm/arch-pxa/pxa-regs.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 9b4da3a..099db5a 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -2211,6 +2211,7 @@ typedef void (*ExcpHndlr) (void) ; #define MCIO1 __REG(0x4800003C) /* Card interface I/O Space Socket 1 Timing Configuration */ #define MDMRS __REG(0x48000040) /* MRS value to be written to SDRAM */ #define BOOT_DEF __REG(0x48000044) /* Read-Only Boot-Time Register. Contains BOOT_SEL and PKG_SEL */ +#define SA1110 __REG(0x48000064) /* Static Memory SA-1110 Compatibility Configuration Register */ #define MDREFR_K2FREE (1 << 25) /* SDRAM Free-Running Control */ #define MDREFR_K1FREE (1 << 24) /* SDRAM Free-Running Control */

2 3

[U-Boot-Users] PATCH trunk request
by Jean-Christophe PLAGNIOL-VILLARD 02 Oct '07

02 Oct '07

Hi Wolfgang, Could you add the following patch the tree : Re: [U-Boot-Users] Missing File ssi.h [U-Boot-Users] Fix warning differ in signedness in cpu/pxa/mmc.c [U-Boot-Users] Fix warning differ in signedness in board/mpl/vcma9/vcma9.c Best Regards

1 0

[U-Boot-Users] Get your first look at the next Fearless Yacht
by navneetsaini07＠zeus.mgmt.wits.ac.za 02 Oct '07

02 Oct '07

Heavy Trading Begins On FRLE As New Designs Hit Street Fearless International FRLE.OB $0.20 Brokers push share prices down and grab shares in anticipation of a investor frenzy. This one is going on high alert for investors who want huge returns. This thing is building. Get ahead on this one and grab FRLE Tuesday morning.

1 0

[U-Boot-Users] a problem about rtl8139 driver on sandpoint8245 board
by Lucas Jin 01 Oct '07

01 Oct '07

Hi, all I am debuging RTL8139 driver for a board based on Sandpoint8245 and I have a problem. The CPU panic on line 529 in rtl8139.c. (outb(CmdReset, ioaddr + ChipCmd);) Serial port displayed: ( Bad trap at PC: fffffffc, SR: 1000, vector=800 NIP: FFFFFFFC XER: 20000000 LR: 00001288 REGS: 077ceb30 TRAP: 0800 DAR: 077CECC0 MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 00000010 077CEC20 FFFFFF1F 00000000 0000000A 00000010 FFFFFFFB 00000000 GPR08: 00000040 81000000 00000000 FFFFFFFF 00000020 A7AC5E24 07FFD000 080D1000 GPR16: 31380950 8E109020 05808002 55D84040 00003032 00000001 00000000 00000001 GPR24: 00000000 077CEEA8 077CEFC8 00000005 07FF80C8 077CEF94 07FFD6D8 00000000 Call backtrace: Exception in kernel pc fffffffc signal 0 ) The value of ioaddr is 0x80000000 The value of _IO_BASE outb uses is defined as 0 Thank you all Jinlu

3 3

[U-Boot-Users] DP83848 PHY for AT91RM9200 board
by Marco Cavallini 01 Oct '07

01 Oct '07

Hi, I'm using u-boot-1.1.4 (quite old but I must use it) with my AT91RM9200 based board. I replaced DM9161 with a new DP83848 PHY ethernet physical layer transceiver. So I'm backporting Sergey Kubushyn's driver National Semiconductor DP83848 PHY Driver for TI DaVinci (TMS320DM644x) adapting it for my AT91RM9200 based board. I left eth_init() like it was for DM9161 because connections are the same. The problem I'm facing to is that PHY is not detected when I call dp83848_is_phy_connected (see below). I wonder if anybody used DP83848 PHY before and maybe could give me a hint. int dp83848_is_phy_connected(AT91PS_EMAC phy_addr) { u_int16_t id1, id2; printf ("*** dp83848_is_phy_connected\n"); at91rm9200_EmacEnableMDIO (phy_addr); at91rm9200_EmacReadPhy(phy_addr, DP83848_PHYID1_REG, &id1) ; at91rm9200_EmacReadPhy(phy_addr, DP83848_PHYID2_REG, &id2) ; at91rm9200_EmacDisableMDIO (phy_addr); printf ("phy_addr=%X - id1=%X - id2=%X\n", phy_addr, id1, id2); // here I always get 0xFFFBC000 0xFFFF 0xFFFF if ((id1 == DP83848_PHYID1_OUI) && (id2 == DP83848_PHYID2_OUI)) return(1); return(0); } TIA -- Marco Cavallini Koan s.a.s. - Bergamo - Italia Embedded and Real-Time Software Engineering http://www.KoanSoftware.com - http://www.KaeilOS.com

2 3