September 2007 - U-Boot

[U-Boot-Users] [PATCH 0/4] Some patches for the TQM885D board
by Martin Krause 05 Oct '07

05 Oct '07

The following series implements some patches and updates for the TQM885D board. -- Martin Krause

3 18

[U-Boot-Users] Q) Anyone know how to debug u-boot on AT91SMA9263-EK using J-Link from Segger?
by Jeff Franks 04 Oct '07

04 Oct '07

Does anyone have a recipe for debugging u-boot on AT91SAM9263-EK target? Our proprietary board is very similar, but can't see what goes wrong. Atmel has a bootstrap that inits SDRAM, and loads u-boot image from Flash device into SDRAM. It jumps to the proper address in the SDRAM and dies. All we have to debug is J-Link from Segger along gdbserver from Segger which is an application that runs on Windows and talks via Usb to the J-Link Pod. We can talk to Windows as if it were gdbserver from a Linux host. The bootup sequence provided by Atmel looks different from u-boot in that u-boot does not move itself into SDRAM, this is done by the Atmel bootstrap. Don't know how to init SDRAM from J-Link. Has anyone done that? --jlf

3 3

[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] 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] litekit mx31 u-boot port successly.
by Andy 01 Oct '07

01 Oct '07

Hi, I have successly ported u-boot to litekit mx31 board. It run at 532MHz and include LAN driver. The u-boot version is 1.2.0. If anyone is interested in this. e-mail to ting0609(a)yahoo.com.tw for detail. Best Regards. ____________________________________________________________________________________ 設定安全圖章，保護您的 Yahoo!奇摩帳號不被駭客盜用！ http://tw.info.yahoo.com/seal/index.html

4 3

[U-Boot-Users] This yacht is in every magazine out there
by eki11＠enersur.com.pe 30 Sep '07

30 Sep '07

FRLE Facility Hits 75% Capacity Of production On Orders Fearless International FRLE.OB Current: $0.32 Fearless International released the Porsche Designed "Fearless 28" as the feature yacht this year in Miami. Since the release, fearless has nearly maxed their production line to fill orders. Media coverage has been extensive, including GQ, Bloomberg Markets, Time, and many more. Go to fearlessyachts dot com to watch the video and see all the media coverage. It will blow you away. This will be one of the top trades this year, get on it first thing Monday.

1 0

[U-Boot-Users] Need help understanding cpu/mpc85xx/start.S
by robert lazarski 29 Sep '07

29 Sep '07

Hi all, My custom 85xx board code off of the latest u-boot git repo is dying - or locking up the bdi somehow - and I've spent the last few days trying to understand the code and how the bdi can tell me what the registers are doing. Starting with the basics: R1 has a 4K stack from 0xfffff000-0xffffffff and the stack grows down? Here's the part of the code I'm crashing in and which I trying to understand, shown here from vim with lines enabled: 158 bl tlb1_entry 159 mr r5,r0 160 lwzu r4,0(r5) /* how many TLB1 entries we actually use */ 161 mtctr r4 162 163 0: lwzu r6,4(r5) 164 lwzu r7,4(r5) 165 lwzu r8,4(r5) 166 lwzu r9,4(r5) 167 mtspr MAS0,r6 168 mtspr MAS1,r7 169 mtspr MAS2,r8 170 mtspr MAS3,r9 171 isync 172 msync 173 tlbwe 174 isync 175 bdnz 0b 176 177 1: Are lines 158-171 setting up the TLB's as defined by 'bl tlb1_entry' ? Line 160 is disassembled to be address fffff0b8 , which I can set a breakpoint to and analyze as follows: ATUM>bi 0xfffff0b8 Breakpoint identification is 0 ATUM>go - TARGET: stopped ATUM>info Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : instruction breakpoint Current PC : 0xfffff0b8 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0xfffff0b4 Current CCSRBAR : 0x0_e0000000 ATUM>rd GPR00: fffff210 fffff0b4 00010001 00000000 GPR04: 00000000 fffff210 00000000 00000000 GPR08: 00000000 00000000 00000000 00000000 GPR12: 00000000 00000000 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 GPR20: 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 00000000 00000000 GPR28: 00000000 00000000 00000000 00000000 CR : 00000000 MSR: 00000200 ATUM>mdh 0xfffff210 2 0_fffff210 : 0x0000 0 .. 0_fffff212 : 0x000b 11 .. I read the above to say that the 'rd' command shows all Rx registers as zero based, and R5 is fffff210. Line 160's 'lwzu r4,0(r5)' will read a 16bit word of a value of 'b' and assign it to R4, confirmed by the next 'ti' : ATUM>ti Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : single step Current PC : 0xfffff0bc Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0xfffff0b4 Current CCSRBAR : 0x0_e0000000 ATUM>rd GPR00: fffff210 fffff0b4 00010001 00000000 GPR04: 0000000b fffff210 00000000 00000000 GPR08: 00000000 00000000 00000000 00000000 GPR12: 00000000 00000000 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 GPR20: 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 00000000 00000000 GPR28: 00000000 00000000 00000000 00000000 CR : 00000000 MSR: 00000200 Here's the part where my code or the bdi is crashing, line 163 which is mapped as fffff0c0 : 163 0: lwzu r6,4(r5) I can single step or set a breakpoint as shown below: ATUM>info Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : instruction breakpoint Current PC : 0xfffff0c0 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0xfffff0b4 Current CCSRBAR : 0x0_e0000000 ATUM>rd GPR00: fffff210 fffff0b4 00010001 00000000 GPR04: 0000000b fffff210 00000000 00000000 GPR08: 00000000 00000000 00000000 00000000 GPR12: 00000000 00000000 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 GPR20: 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 00000000 00000000 GPR28: 00000000 00000000 00000000 00000000 CR : 00000000 MSR: 00000200 'lwzu r6,4(r5)' as I read it says: load a word from R5 + 4 bytes, ie, address fffff214: ATUM>mdh 0xfffff214 2 0_fffff214 : 0x0000 0 .. 0_fffff216 : 0x0000 0 .. Disassembled u-boot in both my code _and_ current MPC8548CDS shows: fffff214: 00 00 00 00 .long 0x0 Is my problem is that I am assigning zero here? I'm confused since the CDS code seems to work the same way. The result of single stepping consistently results in: ATUM>info Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : instruction breakpoint Current PC : 0xfffff0c0 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0xfffff0b4 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) Target state : running # Step timeout detected I sent a question to Abatron technical support about this in the case its a bdi issue - still waiting to see what they say. Any clues please? Robert

3 7

[U-Boot-Users] Missing File ssi.h
by Jean-Christophe PLAGNIOL-VILLARD 29 Sep '07

29 Sep '07

Hi, I've a missing file "ssh.h" needs by board/sc520_spunk/sc520_spunk.c cpu/i386/sc520.c drivers/eeprom/mw_eeprom.c drivers/hwmon/ds1722.c If someone know why? Best Regards

1 0

[U-Boot-Users] BUG on board adsvix
by Jean-Christophe PLAGNIOL-VILLARD 29 Sep '07

29 Sep '07

Hi, I've the following bug on adsvix common/libcommon.a(cmd_ide.o): dans la fonction « __ide_inb »: /home/git/repos/u-boot-build/common/cmd_ide.c:821: référence indéfinie vers « inb » common/libcommon.a(cmd_ide.o): dans la fonction « __ide_outb »: /home/git/repos/u-boot-build/common/cmd_ide.c:812: référence indéfinie vers « outb » make: *** [u-boot] Erreur 1 I'm currently investigating on It.

1 0

[U-Boot-Users] [MIPS] Make mips_io_port_base more generic
by Shinya Kuribayashi 29 Sep '07

29 Sep '07

From: Shinya Kuribayashi <skuribay(a)ruby.dti.ne.jp> Although mips_io_port_base is currently a part of IDE command, but it is quite fundamental for MIPS memory mapped I/O port access such as in[bwl] and out[bwl]. So let's move it to MIPS generic part. This patch adds a helper routine for mips_io_port_base from Linux, and fixes two multiple definition of this variable, tb0229 and gth2. This change is triggered by gth2 build error: board/gth2/libgth2.a(gth2.o): In function `log_serial_char': /home/skuribay/devel/u-boot.git/board/gth2/gth2.c:47: multiple definition of `mips_io_port_base' common/libcommon.a(cmd_ide.o):/home/skuribay/devel/u-boot.git/common/cmd_ide.c:712: first defined here make: *** [u-boot] Error 1 Signed-off-by: Shinya Kuribayashi <skuribay(a)ruby.dti.ne.jp> --- board/gth2/gth2.c | 4 ++-- board/tb0229/tb0229.c | 6 ++---- common/cmd_ide.c | 4 ---- include/asm-mips/io.h | 16 +++++++++++++++- lib_mips/board.c | 5 +++++ 5 files changed, 24 insertions(+), 11 deletions(-) diff --git a/board/gth2/gth2.c b/board/gth2/gth2.c index ffeaf58..3c5563e 100644 --- a/board/gth2/gth2.c +++ b/board/gth2/gth2.c @@ -26,14 +26,13 @@ #include <asm/au1x00.h> #include <asm/addrspace.h> #include <asm/mipsregs.h> +#include <asm/io.h> #include <watchdog.h> #include "ee_access.h" static int wdi_status = 0; -unsigned long mips_io_port_base = 0; - #define SDRAM_SIZE ((64*1024*1024)-(12*4096)) @@ -90,6 +89,7 @@ long int initdram(int board_type) /* If memory could be changed, we should return the true value here */ WATCHDOG_RESET(); + set_io_port_base(0); return (SDRAM_SIZE); } diff --git a/board/tb0229/tb0229.c b/board/tb0229/tb0229.c index e7914bd..c80db56 100644 --- a/board/tb0229/tb0229.c +++ b/board/tb0229/tb0229.c @@ -13,10 +13,9 @@ #include <command.h> #include <asm/addrspace.h> #include <asm/inca-ip.h> +#include <asm/io.h> #include <pci.h> -unsigned long mips_io_port_base = 0; - #if defined(CONFIG_PCI) static struct pci_controller hose; @@ -26,17 +25,16 @@ void pci_init_board (void) } #endif - long int initdram(int board_type) { return get_ram_size (CFG_SDRAM_BASE, 0x8000000); } - int checkboard (void) { printf("Board: TANBAC TB0229 "); printf("(CPU Speed %d MHz)\n", (int)CPU_CLOCK_RATE/1000000); + set_io_port_base(0); return 0; } diff --git a/common/cmd_ide.c b/common/cmd_ide.c index bb064ea..feb89d6 100644 --- a/common/cmd_ide.c +++ b/common/cmd_ide.c @@ -54,10 +54,6 @@ #ifndef __PPC__ #include <asm/io.h> -#ifdef __MIPS__ -/* Macros depend on this variable */ -unsigned long mips_io_port_base = 0; -#endif #endif #ifdef CONFIG_IDE_8xx_DIRECT diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h index cd4d5dc..1e060f7 100644 --- a/include/asm-mips/io.h +++ b/include/asm-mips/io.h @@ -71,7 +71,21 @@ * instruction, so the lower 16 bits must be zero. Should be true on * on any sane architecture; generic code does not use this assumption. */ -extern unsigned long mips_io_port_base; +extern const unsigned long mips_io_port_base; + +/* + * Gcc will generate code to load the value of mips_io_port_base after each + * function call which may be fairly wasteful in some cases. So we don't + * play quite by the book. We tell gcc mips_io_port_base is a long variable + * which solves the code generation issue. Now we need to violate the + * aliasing rules a little to make initialization possible and finally we + * will need the barrier() to fight side effects of the aliasing chat. + * This trickery will eventually collapse under gcc's optimizer. Oh well. + */ +static inline void set_io_port_base(unsigned long base) +{ + * (unsigned long *) &mips_io_port_base = base; +} /* * Thanks to James van Artsdalen for a better timing-fix than diff --git a/lib_mips/board.c b/lib_mips/board.c index 91ccec0..c1a0acf 100644 --- a/lib_mips/board.c +++ b/lib_mips/board.c @@ -62,6 +62,11 @@ static ulong mem_malloc_start; static ulong mem_malloc_end; static ulong mem_malloc_brk; +/* + * mips_io_port_base is the begin of the address space to which x86 style + * I/O ports are mapped. + */ +unsigned long mips_io_port_base = -1; /* * The Malloc area is immediately below the monitor copy in DRAM

2 2