October 2009 - U-Boot

[U-Boot] [u-boot] Problem with exceptions in i.mx27.
by javier Martin 21 Oct '09

21 Oct '09

In my custom i.mx27 based board am having data_abort exceptions. As I could find from arm library code, a simple dump showing last register values should happen to the console, since it is coded so in data_abort handler. So, why is not i.mx27 triggering the data_abort exception handler? I did some tests on i.mx27 litekit board, where I forced a data_abort exception trying to access to a NULL pointer. What I found is that dump wasn't shown on this board neither. Then, I disassembled code in the internal ROM of the i.MX27 where lowest level exception vectors should be placed and I found the following: 0x00000000 0xe59ff00c LDR r15, [r15, #0xc] 0x00000004 0xe51ff11c LDR r15, [r15, #-0x11c] 0x00000008 0xe51ff11c LDR r15, [r15, #-0x11c] 0x0000000c 0xe51ff11c LDR r15, [r15, #-0x11c] 0x00000010 0xe51ff11c LDR r15, [r15, #-0x11c] 0x00000014 0xc0000000 ANDGT r0, r0, r0 0x00000018 0xe51ff120 LDR r15, [r15, #-0x120] 0x0000001c 0xe51ff120 LDR r15, [r15, #-0x120] This means that u-boot exception vector address should be located in the internal vRAM (0xFFFF_4C00 - 0xFFFF_FFFF). I solved the problem adding an assembler macro in lowlevel_init.S for the imx27lite board: -- diff --git a/board/logicpd/imx27lite/lowlevel_init.S b/board/logicpd/imx27lite/lowlevel_init.S index e2cdecb..8419471 100644 --- a/board/logicpd/imx27lite/lowlevel_init.S +++ b/board/logicpd/imx27lite/lowlevel_init.S @@ -40,6 +40,19 @@ SDRAM_LOADMODE_CMD_W: .word (ESDCTL_SDE | ESDCTL_SMODE_LOAD_MODE | \ ESDCTL_ROW13 | ESDCTL_COL10) SDRAM_NORMAL_CMD_W: .word SDRAM_ESDCTL_REGISTER_VAL +.macro init_vram_vectors + /* TODO: + * - Find a proper place to do this for all i.mx27 chips. + * - Calculate Exception vector address in RAM using some parameter. + */ + write32 0xfffffef0, 0xa7f00004 /* Undefined interrupt handler */ + write32 0xfffffef4, 0xa7f00008 /* Software interrupt handler */ + write32 0xfffffef8, 0xa7f0000c /* Prefetch abort handler */ + write32 0xfffffefc, 0xa7f00010 /* Data abort handler */ + write32 0xffffff00, 0xa7f00018 /* Default IRQ handler */ + write32 0xffffff04, 0xa7f0001c /* Default FIQ handler */ +.endm /* init vram vectors */ + .macro init_aipi /* * setup AIPI1 and AIPI2 @@ -167,4 +180,6 @@ lowlevel_init: sdram_init + init_vram_vectors + mov pc,r10 -- I am aware that this patch is not probably the proper way of doing this but I'd like to know: Has anyone got the same problem? Please, try to force and exception and see if a dump is generated, if not, apply this patch and confirm results. If this is a generalized problem, which would be a good place to do it? Comments are much appreciated. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com

1 0

[U-Boot] pata support in u-boot
by Lv Terry-R65388 21 Oct '09

21 Oct '09

Hi, I'm trying to add our ATA driver to u-boot. But it seems that now u-boot only supports SATA. ATA is mixed with ide in cmd_ide.c. There is no ata common interface in include. Is this suitable? Yours Terry

2 2

[U-Boot] [PATCH v2] ppc4xx: Update flash size in reg property of the NOR flash node
by Stefan Roese 21 Oct '09

21 Oct '09

Till now only the ranges in the ebc node are updated with the values currently configured in the PPC4xx EBC controller. With this patch now the NOR flash size is updated in the device tree blob as well. This is done by scanning the compatible nodes "cfi-flash" and "jedec-flash" for the correct chip select number. Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Wolfgang Denk <wd(a)denx.de> --- Changes in v2: - NOR flash nodes are now scanned/detected via the compatible node. cpu/ppc4xx/fdt.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 42 insertions(+), 1 deletions(-) diff --git a/cpu/ppc4xx/fdt.c b/cpu/ppc4xx/fdt.c index 496e028..2688af1 100644 --- a/cpu/ppc4xx/fdt.c +++ b/cpu/ppc4xx/fdt.c @@ -35,6 +35,43 @@ DECLARE_GLOBAL_DATA_PTR; +static int fdt_update_nor_flash_node(void *blob, int cs, u32 size) +{ + char *compat[] = { "cfi-flash", "jedec-flash" }; + int off; + int len; + struct fdt_property *prop; + u32 *reg; + int i; + + for (i = 0; i < 2; i++) { + off = fdt_node_offset_by_compatible(blob, -1, compat[i]); + while (off != -FDT_ERR_NOTFOUND) { + /* + * Found one compatible node, now check if this one + * has the correct CS + */ + prop = fdt_get_property_w(blob, off, "reg", &len); + if (prop) { + reg = (u32 *)&prop->data[0]; + if (reg[0] == cs) { + reg[2] = size; + fdt_setprop(blob, off, "reg", reg, + 3 * sizeof(u32)); + + return 0; + } + } + + /* Move to next compatible node */ + off = fdt_node_offset_by_compatible(blob, off, + compat[i]); + } + } + + return -1; +} + void __ft_board_setup(void *blob, bd_t *bd) { int rc; @@ -59,11 +96,15 @@ void __ft_board_setup(void *blob, bd_t *bd) *p++ = 0; *p++ = bxcr & EBC_BXCR_BAS_MASK; *p++ = EBC_BXCR_BANK_SIZE(bxcr); + + /* Try to update reg property in nor flash node too */ + fdt_update_nor_flash_node(blob, i, + EBC_BXCR_BANK_SIZE(bxcr)); } } /* Some 405 PPC's have EBC as direct PLB child in the dts */ - if (fdt_path_offset(blob, "/plb/opb/ebc") < 0) + if (fdt_path_offset(blob, ebc_path) < 0) strcpy(ebc_path, "/plb/ebc"); rc = fdt_find_and_setprop(blob, ebc_path, "ranges", ranges, (p - ranges) * sizeof(u32), 1); -- 1.6.5.1

2 3

[U-Boot] cmd_onenand.c, onenand_block_read (...)
by Tuma 21 Oct '09

21 Oct '09

Hi, All! It seems I have a trouble. I want to use onenand_block_read function. So I've written a cover for it: int OneNANDBlockRead (loff_t _from, ssize_t _len, ssize_t *_retlen, u_char *_buf, int _oob) { int lRet; return lRet; } When I do from this fuction: printf ("Reading from: 0x%X, Length: 0x%X\n", _from, _len); I get _len and _form swapped. What's wrong? I tryed to pass _from and _len as pointers - pointer addresses are correct but printf ("Reading from: 0x%X\n", *_from); printf ("Reading Length: 0x%X\n", *_len); return swapped result again. This is how I call OneNANDBlockRead function: static const ssize_t lLen = 0x20; static const ulong lLT = 0x00260000; OneNANDBlockRead (&lLT, &lLen, &retlen, lEnvironment, 0); I don't understand it. Can someone help me please. Of course if you need some more information on my problem - you can ask me. -- Software Developer General Satellite Corp.

2 2

[U-Boot] [PATCH 1/1] davinci_emac driver: modify to allow support for DA8xx
by Nick Thompson 21 Oct '09

21 Oct '09

Abstract out $ARCH specific parts of the davinci_emac driver. Some Davinci devices contain an EMAC implemetation that has small differences from the devices currently supported by the driver. Abstrating those sections into static inlines in the $ARCH include files allows those parts to be modified per $ARCH. Specifically this patch will allow DA830 and DA850 devices to use the same driver as many DMXXXX devices. Signed-off-by: Nick Thompson <nick.thompson(a)gefanuc.com> --- Applies to u-boot-ti Only tested on DA830 drivers/net/davinci_emac.c | 61 ++++++++++++------------------ include/asm-arm/arch-davinci/emac_defs.h | 35 +++++++++++++++++ 2 files changed, 59 insertions(+), 37 deletions(-) diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index fa8cee4..0d61b9f 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -1,6 +1,10 @@ /* * Ethernet driver for TI TMS320DM644x (DaVinci) chips. * + * Copyright (C) 2009 Nick Thompson, GE Fanuc Ltd <nick.thompson(a)gefanuc.com> + * + * Abstracted out code not common to all davinci class devices. + * * Copyright (C) 2007 Sergey Kubushyn <ksi(a)koi8.net> * * Parts shamelessly stolen from TI's dm644x_emac.c. Original copyright @@ -119,7 +123,8 @@ static int davinci_eth_phy_detect(void) active_phy_addr = 0xff; - if ((phy_act_state = adap_mdio->ALIVE) == 0) + phy_act_state = adap_mdio->ALIVE & EMAC_MDIO_PHY_MASK; + if (phy_act_state == 0) return(0); /* No active PHYs */ debug_emac("davinci_eth_phy_detect(), ALIVE = 0x%08x\n", phy_act_state); @@ -261,10 +266,7 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis) /* Reset EMAC module and disable interrupts in wrapper */ adap_emac->SOFTRESET = 1; while (adap_emac->SOFTRESET != 0) {;} - adap_ewrap->EWCTL = 0; - for (cnt = 0; cnt < 5; cnt++) { - clkdiv = adap_ewrap->EWCTL; - } + davinci_reset_emac_wrapper(adap_ewrap); rx_desc = emac_rx_desc; @@ -272,30 +274,11 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis) adap_emac->RXCONTROL = 0x01; /* Set MAC Addresses & Init multicast Hash to 0 (disable any multicast receive) */ - /* Using channel 0 only - other channels are disabled */ - adap_emac->MACINDEX = 0; - adap_emac->MACADDRHI = - (davinci_eth_mac_addr[3] << 24) | - (davinci_eth_mac_addr[2] << 16) | - (davinci_eth_mac_addr[1] << 8) | - (davinci_eth_mac_addr[0]); - adap_emac->MACADDRLO = - (davinci_eth_mac_addr[5] << 8) | - (davinci_eth_mac_addr[4]); + davinci_emac_set_mac_addr(adap_emac, davinci_eth_mac_addr); adap_emac->MACHASH1 = 0; adap_emac->MACHASH2 = 0; - /* Set source MAC address - REQUIRED */ - adap_emac->MACSRCADDRHI = - (davinci_eth_mac_addr[3] << 24) | - (davinci_eth_mac_addr[2] << 16) | - (davinci_eth_mac_addr[1] << 8) | - (davinci_eth_mac_addr[0]); - adap_emac->MACSRCADDRLO = - (davinci_eth_mac_addr[4] << 8) | - (davinci_eth_mac_addr[5]); - /* Set DMA 8 TX / 8 RX Head pointers to 0 */ addr = &adap_emac->TX0HDP; for(cnt = 0; cnt < 16; cnt++) @@ -341,7 +324,7 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis) adap_emac->RXUNICASTSET = 0x01; /* Enable MII interface and Full duplex mode */ - adap_emac->MACCONTROL = (EMAC_MACCONTROL_MIIEN_ENABLE | EMAC_MACCONTROL_FULLDUPLEX_ENABLE); + davinci_enable_mii(adap_emac); /* Init MDIO & get link state */ clkdiv = (EMAC_MDIO_BUS_FREQ / EMAC_MDIO_CLOCK_FREQ) - 1; @@ -374,9 +357,9 @@ static void davinci_eth_ch_teardown(int ch) * Note: A task delay can be called here to pend rather than * occupying CPU cycles - anyway it has been found that teardown * takes very few cpu cycles and does not affect functionality */ - dly--; - udelay(1); - if (dly == 0) + dly--; + udelay(1); + if (dly == 0) break; } adap_emac->TX0CP = cnt; @@ -389,9 +372,9 @@ static void davinci_eth_ch_teardown(int ch) * Note: A task delay can be called here to pend rather than * occupying CPU cycles - anyway it has been found that teardown * takes very few cpu cycles and does not affect functionality */ - dly--; - udelay(1); - if (dly == 0) + dly--; + udelay(1); + if (dly == 0) break; } adap_emac->RX0CP = cnt; @@ -411,7 +394,7 @@ static void davinci_eth_close(struct eth_device *dev) /* Reset EMAC module and disable interrupts in wrapper */ adap_emac->SOFTRESET = 1; - adap_ewrap->EWCTL = 0; + davinci_reset_emac_wrapper(adap_ewrap); debug_emac("- emac_close\n"); } @@ -445,9 +428,9 @@ static int davinci_eth_send_packet (struct eth_device *dev, emac_tx_desc->buffer = (u_int8_t *) packet; emac_tx_desc->buff_off_len = (length & 0xffff); emac_tx_desc->pkt_flag_len = ((length & 0xffff) | - EMAC_CPPI_SOP_BIT | - EMAC_CPPI_OWNERSHIP_BIT | - EMAC_CPPI_EOP_BIT); + EMAC_CPPI_SOP_BIT | + EMAC_CPPI_OWNERSHIP_BIT | + EMAC_CPPI_EOP_BIT); /* Send the packet */ adap_emac->TX0HDP = (unsigned int) emac_tx_desc; @@ -485,7 +468,7 @@ static int davinci_eth_rcv_packet (struct eth_device *dev) printf ("WARN: emac_rcv_pkt: Error in packet\n"); } else { NetReceive (rx_curr_desc->buffer, - (rx_curr_desc->buff_off_len & 0xffff)); + (rx_curr_desc->buff_off_len & 0xffff)); ret = rx_curr_desc->buff_off_len & 0xffff; } @@ -596,6 +579,7 @@ int davinci_emac_initialize(void) phy_id |= tmp & 0x0000ffff; switch (phy_id) { +#ifdef PHY_LXT972 case PHY_LXT972: sprintf(phy.name, "LXT972 @ 0x%02x", active_phy_addr); phy.init = lxt972_init_phy; @@ -603,6 +587,8 @@ int davinci_emac_initialize(void) phy.get_link_speed = lxt972_get_link_speed; phy.auto_negotiate = lxt972_auto_negotiate; break; +#endif +#ifdef PHY_DP83848 case PHY_DP83848: sprintf(phy.name, "DP83848 @ 0x%02x", active_phy_addr); phy.init = dp83848_init_phy; @@ -610,6 +596,7 @@ int davinci_emac_initialize(void) phy.get_link_speed = dp83848_get_link_speed; phy.auto_negotiate = dp83848_auto_negotiate; break; +#endif default: sprintf(phy.name, "GENERIC @ 0x%02x", active_phy_addr); phy.init = gen_init_phy; diff --git a/include/asm-arm/arch-davinci/emac_defs.h b/include/asm-arm/arch-davinci/emac_defs.h index 96bc80e..fc70a31 100644 --- a/include/asm-arm/arch-davinci/emac_defs.h +++ b/include/asm-arm/arch-davinci/emac_defs.h @@ -338,4 +338,39 @@ int dp83848_get_link_speed(int phy_addr); int dp83848_init_phy(int phy_addr); int dp83848_auto_negotiate(int phy_addr); +static inline void davinci_emac_set_mac_addr(volatile emac_regs *adap_emac, + u_init8 *mac_addr) +{ + unsigned long mac_hi; + unsigned long mac_lo; + + mac_hi = (mac_addr[3] << 24) | (mac_addr[2] << 16) | + (mac_addr[1] << 8) | (mac_addr[0]); + mac_lo = (mac_addr[5] << 8) | (mac_addr[4]); + + /* Using channel 0 only - other channels are disabled */ + adap_emac->MACINDEX = 0; + adap_emac->MACADDRHI = mac_hi; + adap_emac->MACADDRLO = mac_lo; + + /* Set source MAC address - REQUIRED */ + adap_emac->MACSRCADDRHI = mac_hi; + adap_emac->MACSRCADDRLO = mac_lo; +} + +static inline void davinci_enable_mii(volatile emac_regs *adap_emac) +{ + adap_emac->MACCONTROL = (EMAC_MACCONTROL_MIIEN_ENABLE | + EMAC_MACCONTROL_FULLDUPLEX_ENABLE); +} + +static inline void davinci_reset_emac_wrapper(volatile ewrap_regs *adap_ewrap) +{ + u_int32_t dummy; + + adap_ewrap->EWCTL = 0; + for (cnt = 0; cnt < 5; cnt++) + dummy = adap_ewrap->EWCTL; +} + #endif /* _DM644X_EMAC_H_ */

2 2

[U-Boot] [PATCH U-BOOTV2] image.h: amd64 support
by Peter Korsgaard 21 Oct '09

21 Oct '09

Use IH_CPU_I386 for amd64 machines as well, so bootm.c is able to build on amd64 sandbox. Signed-off-by: Peter Korsgaard <jacmet(a)sunsite.dk> --- include/image.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/image.h b/include/image.h index 0d2f472..5524f84 100644 --- a/include/image.h +++ b/include/image.h @@ -84,7 +84,7 @@ #define IH_CPU IH_CPU_PPC #elif defined(__ARM__) #define IH_CPU IH_CPU_ARM -#elif defined(__I386__) +#elif defined(__I386__) || defined(__x86_64__) #define IH_CPU IH_CPU_I386 #elif defined(__mips__) #define IH_CPU IH_CPU_MIPS -- 1.6.3.3

2 1

[U-Boot] [PATCH 2/2] tools: Use override when changing CC, CFLAGS, etc.
by Scott Wood 21 Oct '09

21 Oct '09

If the user has specified a CC or similar on the command line, that is the cross compiler, not the host compiler. Override is needed to keep these assignments from being ignored in that case. Signed-off-by: Scott Wood <scottwood(a)freescale.com> --- tools/Makefile | 10 +++++----- tools/gdb/Makefile | 6 +++--- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 2a9a9fd..6bf3fde 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -139,21 +139,21 @@ LIBFDT_OBJS := $(addprefix $(obj),$(LIBFDT_OBJ_FILES-y)) # Use native tools and options # Define __KERNEL_STRICT_NAMES to prevent typedef overlaps # -CPPFLAGS = -idirafter $(SRCTREE)/include \ +override CPPFLAGS = -idirafter $(SRCTREE)/include \ -idirafter $(OBJTREE)/include2 \ -idirafter $(OBJTREE)/include \ -I $(SRCTREE)/libfdt \ -I $(SRCTREE)/tools \ -DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC \ -D__KERNEL_STRICT_NAMES -CFLAGS = $(HOSTCFLAGS) $(CPPFLAGS) -O +override CFLAGS = $(HOSTCFLAGS) $(CPPFLAGS) -O # No -pedantic switch to avoid libfdt compilation warnings FIT_CFLAGS = -Wall $(CPPFLAGS) -O -AFLAGS = -D__ASSEMBLY__ $(CPPFLAGS) -CC = $(HOSTCC) -STRIP = $(HOSTSTRIP) +override AFLAGS = -D__ASSEMBLY__ $(CPPFLAGS) +override CC = $(HOSTCC) +override STRIP = $(HOSTSTRIP) MAKEDEPEND = makedepend all: $(obj).depend $(BINS) $(LOGO-y) subdirs diff --git a/tools/gdb/Makefile b/tools/gdb/Makefile index 0a5687d..dca97f4 100644 --- a/tools/gdb/Makefile +++ b/tools/gdb/Makefile @@ -37,9 +37,9 @@ BINS := $(addprefix $(obj),$(BINS)) # # Use native tools and options # -CPPFLAGS = -I$(BFD_ROOT_DIR)/include -CFLAGS = $(HOSTCFLAGS) -O $(CPPFLAGS) -CC = $(HOSTCC) +override CPPFLAGS = -I$(BFD_ROOT_DIR)/include +override CFLAGS = $(HOSTCFLAGS) -O $(CPPFLAGS) +override CC = $(HOSTCC) MAKEDEPEND = makedepend HOSTOS := $(shell uname -s | sed -e 's/$[Cc][Yy][Gg][Ww][Ii][Nn]$.*/cygwin/') -- 1.6.4.4

3 6

Re: [U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family
by m stan 20 Oct '09

20 Oct '09

> > Yes but the default has constants like CONFIG_SYS_MICRON_INIT_DEV_OP > > ... must I then declare this if I am using > > CONFIG_SYS_ELPIDA_INIT_DEV_OP ? > Well, the ideas was that this was the default setting that fits most > boards, and if it doesn't fit it will be overwritten by another array. > Adding #ifdef's here is a strict No-No. How do I override a default array of 30 ulong elements that is declared static in common code from my board code ? I declare my own and use it exclusively so the one in common code is a waste of space. Besides which it puts constraints that all the elements need a declaration. Why if I'm not using it ? > > The default constants are a large mem array that just plain doesn't need > > to be there if you must override it anyway. I don't understand the > > impetus to save on printf strings, for example, and not wanting to save > > here ??? > Feel free to implement something that needs less memory, but do not > add #ifdef's here. > > >> +#ifdef CONFIG_MPC5125 > > >> + out_8(&im->io_ctrl.io_control_mem, IOCTRL_MUX_DDR); > > >> +#else > > >> out_be32(&im->io_ctrl.io_control_mem, IOCTRL_MUX_DDR); > > >> +#endif > > > > > This is something which happens a lot in the remaining code - so often > > > that it is plain unacceptable. As mentioned above, I know that you are > > > just a victim here, but we need a less ugly implementation. > > > > Actually .. since I redid the entire iopin_initialize function to a > > separate one for the mpc5125 this is the only place where an ugly > > #ifdef'ed iopin init occurs now. > > I think it's not the only place, and it's just a symptom of the > problem. I think we should try to avoid duplicating structs that are > more or less the same, except for the data type. If they had been left as an array with indices as when the 5121 was first implemented these differences would be trivial ... now that each iopin is an elemnet in a struct there are over 50 different namesbesides the ordering by the 3rd element is off for the few names at the beginning that are the same. Also the init code still treats it like an array. I believe you NAKed me on doing this a week or two ago. Perhaps I should take it back to that implementation ??? > > > As I said .. since I redid the iopin_initialize (there are now 2 > > different functions) I don't think this is necessary ... it's not > > just a size difference ... there is also a bit configuration > > difference. I redid the #define for this too. Also .. the elements > > within the struct are all different. > > It's primarily and issue of being able to read and maintain the code. > Duplicating the structs makes no sense if they are essentially the > same except for the u8 versus u32 difference. > > You claim the elements are all different? I didn't get this impression > from reading either your code or the RefMan. I've read and reread the manual Wolfgang ... I could recite page numbers at this point ... I believe you 've glanced at it and have the wrong impression. > > ... > > >> +#ifndef CONFIG_MPC5125 > > >> /* set MR register to point to MR1 */ > > >> out_8(&psc->command, PSC_SEL_MODE_REG_1); > > >> > > >> @@ -93,12 +93,25 @@ int serial_init(void) > > >> /* switch to UART mode */ > > >> out_be32(&psc->sicr, 0); > > >> > > >> - /* mode register points to mr1 */ > > >> /* configure parity, bit length and so on in mode register 1*/ > > >> + /* mode register points to mr1 */ > > >> out_8(&psc->mode, PSC_MODE_8_BITS | PSC_MODE_PARNONE); > > >> /* now, mode register points to mr2 */ > > >> out_8(&psc->mode, PSC_MODE_1_STOPBIT); > > >> +#else > > >> + /* disable Tx/Rx */ > > >> + out_8(&psc->command, PSC_TX_DISABLE | PSC_RX_DISABLE); > > >> + > > >> + /* choose the prescaler the Tx/Rx clock generation */ > > >> + out_8(&psc->psc_clock_select, 0xdd); > > >> + > > >> + /* switch to UART mode */ > > >> + out_be32(&psc->sicr, 0); > > >> > > >> + /* configure parity, bit length and so on in mode registers */ > > >> + out_8(&psc->mr1, PSC_MODE_8_BITS | PSC_MODE_PARNONE); > > >> + out_8(&psc->mr2, PSC_MODE_1_STOPBIT); > > >> +#endif > > >> /* set baudrate */ > > >> serial_setbrg(); > > > I think we should move the differing code into separate functions. > > > > Fine .. but I'll have to check the processor type to see which one > > to call at some point if I take out the ifdefs ??? > > No. You can build either one implementation of the function or the > other one, depending of the config settings. Are you talking about pulling one or the other in at the make ? SO to share the 8 functions or so like putc and getc I have one file, 5121 init another and 5125 init a third -- all that to bypass an if statement ?? You're not making any sense to me. > > > > diff --git a/drivers/net/mpc512x_fec.c b/drivers/net/mpc512x_fec.c > > >> index fb2c19a..9f839a1 100644 > > >> --- a/drivers/net/mpc512x_fec.c > > >> +++ b/drivers/net/mpc512x_fec.c > > >> @@ -41,7 +41,12 @@ static int rx_buff_idx = 0; > > >> static void mpc512x_fec_phydump (char *devname) > > >> { > > >> u16 phyStatus, i; >> >> - u8 phyAddr = CONFIG_PHY_ADDR; >> >> +#ifdef CONFIG_MPC5125 > > >> + uint8 phyAddr = ((devname[3] == '2') ? CONFIG_PHY2_ADDR : > >> > + CONFIG_PHY_ADDR); > > >> +#else > > >> + uint8 phyAddr = CONFIG_PHY_ADDR; > > >> +#endif > > > Can we not do without this #ifdef here? > > > > I'm open to suggestions ... there are possibly two active FECS and >> this seemed to be the best solution ... The MPC5125 code will work > I'm not sure what you mean. In U-Boot, there cannot be 'two active > FECs'; at any point of time, no more than one network interface will > be enabled - if any at all. > > > I'm not talking about any printed messages here. I smell a basic > misunderstaning in your comments - there cannot be more than one > network interface active and in use in U-Boot. Can't I initialize both and switch between them ? I do it now and want to keep this functionality. > > > As far as the Clock on the 2nd FEC .. I check it to see if it's ON > > .. Only the 1st FEC is necessary in u-boot while the 2nd is > > optional. ... > > Umm... Why should we care about this? See bullet # 2 at > http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#2_Keep_it_Fast > > U-Boot should not care about these things, unless you run a network > command on the second Ethernet interface. > Yes but since you can switch midstream they both need to be initialized and the code needs to determine which one it's using ??? Very Best, Martha

2 1

[U-Boot] Linux boot using bootz
by R Arun Kumar 20 Oct '09

20 Oct '09

Hai I am trying to boot linux in ubootv2.0.0 rc9 using the command bootz and not printing any kernel messages after *booting the kernel *messages. , Any help My log ================= U-Boot 2.0.0-rc10-00322-g146f9b6-dirty (Oct 20 2009 - 12:58:32) Board: Phytec phyCORE-i.MX31 NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bi t) got MAC address from EEPROM: 00:08:EE:01:86:71 Malloc space: 0x87b00000 -> 0x87f00000 (size 4 MB) Stack space : 0x87af8000 -> 0x87b00000 (size 32 kB) Open /dev/env0 No such file or directory no valid environment found on /dev/env0. Using default environment running /env/bin/init... Hit any key to stop autoboot: 3 type update_kernel nand|nor [<imagename>] to update kernel into flash type update_root nand|nor [<imagename>] to update rootfs into flash uboot:/ bootargs="noinitrd console=ttymxc0 root=/dev/nfs nfsroot= 192.168.50.247: /home/arun/ltib-imx31ads-20071008/rootfs rw ip=192.168.50.182:192 .168.50.1:192.1 68.50.1:255.255.255.0" uboot:/ printenv locals: kernel=net root=net uimage=zImage_pico_final jffs2=root-pcm037.jffs2 autoboot_timeout=3 nfsroot=/home/arun/ltib-imx31ads-20071008/rootfs bootargs=noinitrd console=ttymxc0 root=/dev/nfs nfsroot=192.168.50.247: /home/aru n/ltib-imx31ads-20071008/rootfs rw ip=192.168.50.182:192.168.50.1: 192.168.50.1:2 55.255.255.0 globals: PATH=/env/bin uboot:/ tftp zImage_arun phy0: Link is up - 100/Full TFTP from server 192.168.50.247; our IP address is 192.168.50.182 Filename 'zImage_arun'. Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################## done Bytes transferred = 1813660 (1bac9c hex) uboot:/ bootz zImage_arun loaded zImage from zImage_arun with size 1813660 Uncompressing Linux............................................................. .............................................................. done, booting the kernel. ===================================================================================

1 0

[U-Boot] trouble with u-boot and bist fail on pcie adapter
by Ayman El-Khashab 20 Oct '09

20 Oct '09

I am using a recent version of u-boot (git from the past couple of weeks) and have an LSI SAS adapter on a canyonlands board. What I see happening is that u-boot reads the bist bit, then does numerous bar accesses, then sets the bist fail and latency words. Once the bist is set to fail, the lsi adapter doesn't respond to anything else and so Linux fails to see it when it boots. I've tried turning off pcie support in u-boot, in that case the bist did not get written but Linux kernel crashed during the init of the adapter. The LSI adapter does work fine in a ubuntu PC, so the hardware is likely good. This adapter is an LSISAS2008 gen 2 pcie board. On the PC it uses both IO and MEM spaces. I am unsure what to try next -- Linux should not assume any state about the adapter -- on the other hand, if u-boot does cause the board to go into an unrecoverable state, there isn't much the kernel can do about that. any help / suggestions / experiments would be much appreciated. Thanks Ayman

4 3