Re: [U-Boot] [PATCH U-BOOTV2] image.h: amd64 support
Hi Peter, On Tue, Oct 20, 2009 at 10:21:00PM +0200, Peter Korsgaard wrote: > Use IH_CPU_I386 for amd64 machines as well, so bootm.c is able to build > on amd64 sandbox. > > Signed-off-by: Peter Korsgaard Applied, thanks. Sascha > --- > 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 > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] TFTP: allow for adjustable retransmission timout
So far, TFTP negotiated a fixed retransmission timeout of 5 seconds. In some cases (busy networks, slow TFTP servers) this caused very slow transfers. Add new environment variable "tftptimeout" allows to set this timeout. Lowering this value may make downloads succeed faster in networks with high packet loss rates or with unreliable TFTP servers. Signed-off-by: Wolfgang Denk Cc: Ben Warren --- I'm not sure if this change is really a good thing. It seems to help a lot in a test case I had here, but I'm not sure if the previous timeout settings that also depended on TftpRRQTimeoutMSecs were simply wrong (and not well tested - in myunderstanding they should affect only the connection timeout, but not the packet retransmission timeout), or if these are actually useful or needed in some configurations. So far, TftpRRQTimeoutMSecs is used in common/update.c only. README | 19 --- net/tftp.c | 22 +- 2 files changed, 33 insertions(+), 8 deletions(-) diff --git a/README b/README index 744f6bf..18ca11f 100644 --- a/README +++ b/README @@ -2989,7 +2989,9 @@ environment. As long as you don't save the environment you are working with an in-memory copy. In case the Flash area containing the environment is erased by accident, a default environment is provided. -Some configuration options can be set using Environment Variables: +Some configuration options can be set using Environment Variables. + +List of environment variables (most likely not complete): baudrate - see CONFIG_BAUDRATE @@ -3101,7 +3103,7 @@ Some configuration options can be set using Environment Variables: available network interfaces. It just stays at the currently selected interface. - netretry- When set to "no" each network operation will + netretry - When set to "no" each network operation will either succeed or fail without retrying. When set to "once" the network operation will fail when all the available network interfaces @@ -3117,7 +3119,18 @@ Some configuration options can be set using Environment Variables: tftpdstport - If this is set, the value is used for TFTP's UDP destination port instead of the Well Know Port 69. - vlan- When set to a value < 4095 the traffic over + tftpblocksize - Block size to use for TFTP transfers; if not set, + we use the TFTP server's default block size + + tftptimeout - Retransmission timeout for TFTP packets (in milli- + seconds, minimum value is 1000 = 1 second). Defines + when a packet is considered to be lost so it has to + be retransmitted. The default is 5000 = 5 seconds. + Lowering this value may make downloads succeed + faster in networks with high packet loss rates or + with unreliable TFTP servers. + + vlan - When set to a value < 4095 the traffic over Ethernet is encapsulated/received over 802.1q VLAN tagged frames. diff --git a/net/tftp.c b/net/tftp.c index cc60a3b..f3ac54b 100644 --- a/net/tftp.c +++ b/net/tftp.c @@ -203,7 +203,7 @@ TftpSend (void) pkt += 5 /*strlen("octet")*/ + 1; strcpy ((char *)pkt, "timeout"); pkt += 7 /*strlen("timeout")*/ + 1; - sprintf((char *)pkt, "%lu", TIMEOUT / 1000); + sprintf((char *)pkt, "%lu", TftpTimeoutMSecs / 1000); debug("send option \"timeout %s\"\n", (char *)pkt); pkt += strlen((char *)pkt) + 1; #ifdef CONFIG_TFTP_TSIZE @@ -405,7 +405,6 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src, unsigned len) } TftpLastBlock = TftpBlock; - TftpTimeoutMSecs = TIMEOUT; TftpTimeoutCountMax = TIMEOUT_COUNT; NetSetTimeout (TftpTimeoutMSecs, TftpTimeout); @@ -504,10 +503,24 @@ TftpStart (void) { char *ep; /* Environment pointer */ - /* Allow the user to choose tftpblocksize */ + /* +* Allow the user to choose TFTP blocksize and timeout. +* TFTP protocol has a minimal timeout of 1 second. +*/ if ((ep = getenv("tftpblocksize")) != NULL) TftpBlkSizeOption = simple_strtol(ep, NULL, 10); - debug("tftp block size is %i\n", TftpBlkSizeOption); + + if ((ep = getenv("tftptimeout")) != NULL) + TftpTimeoutMSecs = simple_strtol(ep, NULL, 10); + + if (TftpTimeoutMSecs < 1000) { + printf("TFTP timeout (%ld ms) too low, " + "set minimum = 1000 ms\n); + TftpTimeoutMSecs = 1000; + } + + debug("TFTP blocksize = %i, timeout = %ld ms\n", + TftpBlkSizeOption, TftpTimeoutMSecs); TftpServerIP = NetServerIP; if (BootFile[0] ==
[U-Boot] pata support in u-boot
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ppc4xx: Update flash size in reg property of the NOR flash node
Hi Wolfgang, On Tuesday 20 October 2009 23:12:47 Wolfgang Denk wrote: > > 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 > > Cc: Wolfgang Denk > > --- > > Changes in v2: > > - NOR flash nodes are now scanned/detected via the compatible node. > > Thanks. > > Hm... thinking about it, this problem most probably affects other > (non-4xx boards as well). I guess there is no easy way to generalize > this code enough tomake it usable by other (or even all?) boards as > well? I see no way to easily fix the NOR flash "reg" property for all non-4xx boards as well. But what I can do is, move the fdt_update_nor_flash_node() function into some common code (commond/fdt_support.c). This way it could be used by other boards/platforms as well. Should I send an updated patch for this? Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] davinci_emac driver: modify to allow support for DA8xx
Paulraj, Sandeep wrote: > >> -Original Message- >> From: u-boot-boun...@lists.denx.de[mailto:s-paul...@ti.com] >> On Behalf Of Nick Thompson >> Sent: Tuesday, October 20, 2009 9:21 AM >> To: Ben Warren; u-boot@lists.denx.de >> Subject: [U-Boot] [PATCH 1/1] davinci_emac driver: modify to allow support >> for DA8xx >> >> 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 DM devices. >> >> Signed-off-by: Nick Thompson >> --- >> 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 >> >> + * >> + * Abstracted out code not common to all davinci class devices. >> + * >> * Copyright (C) 2007 Sergey Kubushyn >> * >> * 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); > > Dm6467 and DM365 uses a different set of registers to do this. > Some time back I had submitted a patch. > > It will be better if we modify this driver only once to support all DaVinci > SOCs. > > I submiited a patch for DM365 and DM6467 some time back > > http://www.mail-archive.com/u-boot@lists.denx.de/msg23031.html > > Ben can you comment on the above, I don't think I received any comments from > you. I think the two changes are largely compatible. The main difference (ignoring the gigabit changes) is that I've used static inlines rather than #ifdef. As I understand it, this is the preferred method. I think the Sandeep's changes could also be done with static inline "methods", which, in general, can derisk changes for one SoC from effecting another as the base code need not be changed. The disadvantage is that you may not have a method hook in place to make the changes you need, without changing several files to add one in and supply all the other SoC specific methods. Well, that and the fact the code is now stored in several files, rather than one. I'm happy to go either way (inlines or ifdef's), if someone wants to make a call on what is most acceptable (for u-boot). >> 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
Re: [U-Boot] pata support in u-boot
Dear "Lv Terry-R65388", In message <1ae74f652ecb1440b73dd7c2c20842d19a6...@zch01exm27.fsl.freescale.net> you wrote: > > I'm trying to add our ATA driver to u-boot. Fine. > But it seems that now u-boot only supports SATA. This is not correct. U-Boot also supports ATA/ATAPI, SCSI, USB, PCMCIA, Systemace, ... > ATA is mixed with ide in cmd_ide.c. Indeed. > There is no ata common interface in include. Hm... so include/ata.h is not what you are looking for> > Is this suitable? I'm afraid I don't understand what exactly your problem is. drivers/block/mg_disk.c, drivers/block/pata_bfin.c or drivers/block/sil680.c seem to show that the current code actually can be used with ATA interfaces. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The following statement is not true. The previous statement is true. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] Rearrange i386 Interupt Handling
Graeme Russ wrote on 20/10/2009 23:44:14: > > On Wed, Oct 21, 2009 at 1:35 AM, Joakim Tjernlund > wrote: > >> > >> In preperation for full relocation > >> > >> Signed-off-by: Graeme Russ > >> --- > >> cpu/i386/Makefile | 2 +- > >> cpu/i386/cpu.c | 1 - > >> cpu/i386/exceptions.c | 229 - > >> cpu/i386/interrupts.c | 431 > >> ++-- > >> include/asm-i386/interrupt.h | 27 --- > >> include/asm-i386/u-boot-i386.h | 3 - > >> lib_i386/interrupts.c | 4 +- > >> lib_i386/pcat_interrupts.c | 33 --- > >> 8 files changed, 420 insertions(+), 310 deletions(-) > >> delete mode 100644 cpu/i386/exceptions.c > > > > Don't know much about x86, but should not these new asm > > symbools be .hidden and .type , @function ? > > > > Yes > > >> > >> +#define DECLARE_INTERRUPT(x) \ > >> + ".globl irq_"#x"\n" \ > >> + "irq_"#x":\n" \ > >> + "pushl %ebp\n" \ > >> + "movl %esp,%ebp\n" \ > >> + "pusha\n" \ > >> + "pushl $"#x"\n" \ > >> + "jmp irq_common_entry\n" > > > > Done in patch 8 Ah, sorry for the noise. > > >> +asm(".globl irq_common_entry\n" \ > >> + "irq_common_entry:\n" \ > >> + "pushl $0\n" \ > >> + "pushl $0\n" \ > >> + "call irq_llsr\n" \ > >> + "popl %eax\n" \ > >> + "popl %eax\n" \ > > > > > > I missed this one - I will respin patch 8 after any further comments > have been made OK, at least something good came from this mail. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ppc4xx: Update flash size in reg property of the NOR flash node
Dear Stefan Roese, In message <200910211105.10055...@denx.de> you wrote: > > > Hm... thinking about it, this problem most probably affects other > > (non-4xx boards as well). I guess there is no easy way to generalize > > this code enough tomake it usable by other (or even all?) boards as > > well? > > I see no way to easily fix the NOR flash "reg" property for all non-4xx > boards > as well. But what I can do is, move the fdt_update_nor_flash_node() function > into some common code (commond/fdt_support.c). This way it could be used by > other boards/platforms as well. That's a good idea. > Should I send an updated patch for this? Yes, please do. And please add a comment that describes what it's good for. Thanks Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ATTENTION: Despite Any Other Listing of Product Contents Found Here- on, the Consumer is Advised That, in Actuality, This Product Consists Of 99.99% Empty Space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cmd_onenand.c, onenand_block_read (...)
Sorry, that was just printf format error. =) I've corrected everything, works fine. On Tuesday 20 October 2009 17:27:04 Tuma wrote: > 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 = 0x0026; > 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pata support in u-boot
Hi Denk, drivers/block/pata_bfin.c uses sata.h and can use commands in cmd_sata.c. drivers/block/mg_disk.c uses mg_disk.h and can use commands in cmd_mgdisk.c. drivers/block/sil680.c, hm.., I don't know what cmd it uses. There's also ATAPI in cmd_ide.c, which uses code in Pcs440ep.c. They are all ATAPI, But use different interface. There is no ata common function definitions. I just wonder if I should create a new interface, like cmd_pata.c and mxc_pata.h for my ata. Actually, sata interface is ok for use in my ata. But it may make customer confused. I don't want to add redundant code for ata, so I just ask if there is a better implementation for ata. Thanks~~ Yours Terry -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: 2009年10月21日 17:37 To: Lv Terry-R65388 Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] pata support in u-boot Dear "Lv Terry-R65388", In message <1ae74f652ecb1440b73dd7c2c20842d19a6...@zch01exm27.fsl.freescale.net> you wrote: > > I'm trying to add our ATA driver to u-boot. Fine. > But it seems that now u-boot only supports SATA. This is not correct. U-Boot also supports ATA/ATAPI, SCSI, USB, PCMCIA, Systemace, ... > ATA is mixed with ide in cmd_ide.c. Indeed. > There is no ata common interface in include. Hm... so include/ata.h is not what you are looking for> > Is this suitable? I'm afraid I don't understand what exactly your problem is. drivers/block/mg_disk.c, drivers/block/pata_bfin.c or drivers/block/sil680.c seem to show that the current code actually can be used with ATA interfaces. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The following statement is not true. The previous statement is true. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] Problem with exceptions in i.mx27.
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: 0x 0xe59ff00c LDR r15, [r15, #0xc] 0x0004 0xe51ff11c LDR r15, [r15, #-0x11c] 0x0008 0xe51ff11c LDR r15, [r15, #-0x11c] 0x000c 0xe51ff11c LDR r15, [r15, #-0x11c] 0x0010 0xe51ff11c LDR r15, [r15, #-0x11c] 0x0014 0xc000 ANDGT r0, r0, r0 0x0018 0xe51ff120 LDR r15, [r15, #-0x120] 0x001c 0xe51ff120 LDR r15, [r15, #-0x120] This means that u-boot exception vector address should be located in the internal vRAM (0x_4C00 - 0x_). 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 0xfef0, 0xa7f4 /* Undefined interrupt handler */ + write32 0xfef4, 0xa7f8 /* Software interrupt handler */ + write32 0xfef8, 0xa7fc /* Prefetch abort handler */ + write32 0xfefc, 0xa7f00010 /* Data abort handler */ + write32 0xff00, 0xa7f00018 /* Default IRQ handler */ + write32 0xff04, 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fdt: Add fdt_fixup_nor_flash_size() to fixup NOR FLASH size in dtb
This function can be used to update the size in the "reg" property of the NOR FLASH device nodes. This is necessary for boards with non-fixed NOR FLASH sizes. Signed-off-by: Stefan Roese Cc: Wolfgang Denk Cc: Gerald Van Baren --- common/fdt_support.c | 44 include/fdt_support.h |2 ++ 2 files changed, 46 insertions(+), 0 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index 89164a1..40ff00a 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -692,3 +692,47 @@ int fdt_pci_dma_ranges(void *blob, int phb_off, struct pci_controller *hose) { return 0; } #endif + +#ifdef CONFIG_FDT_FIXUP_NOR_FLASH_SIZE +/* + * This function can be used to update the size in the "reg" property + * of the NOR FLASH device nodes. This is necessary for boards with + * non-fixed NOR FLASH sizes. + */ +int fdt_fixup_nor_flash_size(void *blob, int cs, u32 size) +{ + char compat[][16] = { "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; +} +#endif diff --git a/include/fdt_support.h b/include/fdt_support.h index 16734c5..0a9dd0d 100644 --- a/include/fdt_support.h +++ b/include/fdt_support.h @@ -79,5 +79,7 @@ void ft_pci_setup(void *blob, bd_t *bd); void set_working_fdt_addr(void *addr); int fdt_resize(void *blob); +int fdt_fixup_nor_flash_size(void *blob, int cs, u32 size); + #endif /* ifdef CONFIG_OF_LIBFDT */ #endif /* ifndef __FDT_SUPPORT_H */ -- 1.6.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v3] ppc4xx: Update flash size in reg property of the NOR flash node
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. This size fixup is enabled for all AMCC eval board right now. Other 4xx boards may want to enable it as well, if this problem with multiple NOR FLASH sizes exists. Signed-off-by: Stefan Roese Cc: Wolfgang Denk --- Changes in v3: - Moved function fdt_fixup_nor_flash_size() to common/fdt_support.c so that other platforms/board may use it too. Changes in v2: - NOR flash nodes are now scanned/detected via the compatible node. cpu/ppc4xx/fdt.c |8 +++- include/configs/amcc-common.h |2 ++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/cpu/ppc4xx/fdt.c b/cpu/ppc4xx/fdt.c index 496e028..8cd3da1 100644 --- a/cpu/ppc4xx/fdt.c +++ b/cpu/ppc4xx/fdt.c @@ -59,11 +59,17 @@ void __ft_board_setup(void *blob, bd_t *bd) *p++ = 0; *p++ = bxcr & EBC_BXCR_BAS_MASK; *p++ = EBC_BXCR_BANK_SIZE(bxcr); + +#ifdef CONFIG_FDT_FIXUP_NOR_FLASH_SIZE + /* Try to update reg property in nor flash node too */ + fdt_fixup_nor_flash_size(blob, i, +EBC_BXCR_BANK_SIZE(bxcr)); +#endif } } /* 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); diff --git a/include/configs/amcc-common.h b/include/configs/amcc-common.h index 51128a3..8cd97b8 100644 --- a/include/configs/amcc-common.h +++ b/include/configs/amcc-common.h @@ -156,6 +156,8 @@ */ #define CONFIG_OF_LIBFDT #define CONFIG_OF_BOARD_SETUP +/* Update size in "reg" property of NOR FLASH device tree nodes */ +#define CONFIG_FDT_FIXUP_NOR_FLASH_SIZE /* * Booting and default environment -- 1.6.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Micrel KS8995MA 5 port managed switch initialise
We have the MPC5200 MAC connected to the Micrel KS8995MA MII-SW port. The configuration pins of the 8995 are set to: SPI slave PS0=0 PS1=1 PHY mode MII SCONF0=1 SCONF1=0 SCONF2=0 The MII and SPI ports are working, checked with the uboot mii and sspi commands. However, ethernet transmit and receive do not appear to work. Looks like the switch is not configured correctly and does not pass any data. The manual initialisation sequence we are using is: sspi 0 24 020100 sspi 0 24 02024c sspi 0 24 020305 sspi 0 24 0204F1 sspi 0 24 020620 sspi 0 24 021061 sspi 0 24 022061 sspi 0 24 023061 sspi 0 24 024061 sspi 0 24 025061 sspi 0 24 025B18 sspi 0 24 0260FF sspi 0 24 0261FF sspi 0 24 0262FF sspi 0 24 0263FF sspi 0 24 0264FF sspi 0 24 0265FF sspi 0 24 0266FF sspi 0 24 0267FE sspi 0 24 020101 This was taken from the example: https://dev.openwrt.org/browser/trunk/package/spi-ks8995/src/spi_ks8995.c Does anyone have an example that works? Regards to all uboot-ers, Chris ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Got trap No.23 when booting mips32
Hi all, I've got some problem when booting mips32 in kernel. I know this is uboot maillist , but I think people here may be more famililar with booting,so I post here for your help :D I got a No.23 trap when calling start_kernel ---> local_irq_enable : irq 23, desc: 802a98a0, depth: 1, count: 0, unhandled: 0 ->handle_irq(): 80148c6c, handle_bad_irq+0x0/0x2b4 ->chip(): 8029f738, 0x8029f738 ->action(): IRQ_DISABLED set unexpected IRQ # 23 No.23 trap is a Watch trap, which means that, when "Physical address of load/store matched enabled value in WatchLo/ WatahHi registers."--- happened, a No.23 trap was triggered by cpu. So I used macro __u32 watch_regh0= read_c0_watchhi0(); __u32 watch_regl0= read_c0_watchlo0(); to retrieve value from WatchHi and WatchLo register, found them 0x1 and 0x0 respectively,which mean that ,'r' together with 'w' bits were set to zero and no trap should be triggered. But now , I got a 23 trap, why ? At last , I used to set WatchHi to 0x0, but failed , and found it still 0x1 after calling write_c0_watchhi0(0) Any suggestion would be grateful. regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family
On Mon, 2009-10-19 at 16:45 -0600, John Rigby wrote: > Regarding 512x psc register maps: > > The register map for 5125 does not just change the size of the registers. > Some registers change locations. The issue is that the hardware guys > decided to "fix" the old broken register access. The 5200, 5121, 5123 had > some registers that were: > > Function A when read but function B when written. I would like to hear what the designer had for argument to justify that solution. Another favorite is the write only register. GPIO without set/reset registers that force a read/modify/write cycle. Then we have things that are more bugs than design The "god" register that is not affected by any reset turning a reboot/reset into a game of chance. The occasional write register. do { *reg =xx }while (*reg != xx) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] stopping u-boot from booting an old image in RAM.
If I boot this unit, then remove the SD card it booted from and reset it, it happily boots some Linux image which is lying around in memory. It even does it after a short power-off power-on sequence. I think that's horrible behaviour. I was told I could use && instead of ; between the commands in the bootcmd string to stop this, but that barfed, and then I was told that maybe && only existed if "scripting is enabled" Could anyone please talk me through the steps of either 1. doing what it takes to enable this && feature, so that if it fails to find the card, it doesn't go on and try to boot. or 2. something else that will do it, such as so effectively buggering up an image that has been booted from that it will never be re-used :-) TVM David Collier www.dexdyne.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] stopping u-boot from booting an old image in RAM.
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On > Behalf Of David Collier > Sent: 21 October 2009 16:08 > To: u-boot@lists.denx.de > Subject: [U-Boot] stopping u-boot from booting an old image in RAM. > > If I boot this unit, then remove the SD card it booted from and reset it, > it happily boots some Linux image which is lying around in memory. > > It even does it after a short power-off power-on sequence. > > I think that's horrible behaviour. > > I was told I could use && instead of ; between the commands in the > bootcmd string to stop this, but that barfed, and then I was told that > maybe && only existed if "scripting is enabled" > > Could anyone please talk me through the steps of either > > 1. doing what it takes to enable this && feature, so that if it fails to > find the card, it doesn't go on and try to boot. > > or > > 2. something else that will do it, such as so effectively buggering up an > image that has been booted from that it will never be re-used > > :-) > > TVM > > David Collier Probably a simple mw (memory write) to the entry point of linux, before You attempt to reload the image, would do the trick? Usage: mw [.b, .w, .l] address value [count] Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] return value from do_ext2load
the do_ext2load procedure returns the file length if it succeeds... which means you can't do #define CONFIG_BOOTCOMMAND "mmcinit && ext2load mmc 0:1 0x1040 /boot/uImage && bootm 0x1040" Is this part of some vast eternal plan and/or can anyone see a way to make it function as desired anyway? David Collier www.dexdyne.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OneNAND partial read/write support
Kyungmin Park wrote: > On Wed, Oct 21, 2009 at 7:48 AM, Scott Wood wrote: >> On Mon, Oct 12, 2009 at 04:27:10PM +0900, Kyungmin Park wrote: >>> Now OneNAND handles block operation only. >>> With this patch OneNAND handles all read/write size. >>> >>> Signed-off-by: Kyungmin Park >>> --- >>> diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c >>> index 9090940..2b8f01b 100644 >>> --- a/common/cmd_onenand.c >>> +++ b/common/cmd_onenand.c >>> @@ -36,7 +36,7 @@ static inline int str2long(char *p, ulong *num) >>> return (*p != '\0' && *endptr == '\0') ? 1 : 0; >>> } >>> >>> -static int arg_off_size(int argc, char *argv[], ulong *off, size_t *size) >>> +static int arg_off_size(int argc, char *argv[], ulong *off, ssize_t *size) >>> { >>> if (argc >= 1) { >>> if (!(str2long(argv[0], off))) { >> Are you expecting negative sizes? > > I don't know why these are implemented. it's existing one. I was asking about the change you were making... I guess it's because of the *off + *size check, though unsigned overflow should work as well. >>> struct onenand_chip *this = mtd->priv; >>> - int blocks = (int) len >> this->erase_shift; >>> int blocksize = (1 << this->erase_shift); >>> loff_t ofs = from; >>> struct mtd_oob_ops ops = { >>> .retlen = 0, >>> }; >>> + ssize_t thislen; >>> int ret; >>> >>> - if (oob) >>> - ops.ooblen = blocksize; >>> - else >>> - ops.len = blocksize; >>> + while (len > 0) { >>> + thislen = min_t(ssize_t, len, blocksize); >>> + thislen = ALIGN(thislen, mtd->writesize); >>> >>> - while (blocks) { >>> ret = mtd->block_isbad(mtd, ofs); >>> if (ret) { >>> printk("Bad blocks %d at 0x%x\n", >>> (u32)(ofs >> this->erase_shift), (u32)ofs); >>> - ofs += blocksize; >>> + ofs += thislen; >>> continue; >>> } >>> >>> - if (oob) >>> + if (oob) { >>> ops.oobbuf = buf; >>> - else >>> + ops.ooblen = thislen; >>> + } else { >>> ops.datbuf = buf; >>> + ops.len = thislen; >> thislen can be greater than len, in which case you'll be overflowing buf. > > No, len is unsigned int, but thislen is int. and can't overflow since. > it's size down with blocksize at min macro. I don't see what signedness has to do with it. You cap thislen at the lesser of len or blocksize, but then you round thislen *up* to the page size. Thus thislen can be greater than len. >> If you want to allow partial page reads, you need to allocate a temporary >> buffer at some point. If not (I don't see a huge need), the ALIGN() >> should be an error check instead. > > >> Does this code handle being given an offset that is not at a block (or >> page) boundary? It doesn't look like it (it will try to read across >> block boundaries). > > Basically it reads/writes data based on block. but last or first > partial read/writes support. Partial as in page-aligned but block-unaligned, or partial as in can start/stop on any byte? Either way, it doesn't seem to handle the partial first block properly. It will see that len is greater than the blocksize and not pay any attention to the alignment of ofs. >>> @@ -265,9 +276,10 @@ static int onenand_block_test(u32 start, u32 size) >>> goto next; >>> } >>> >>> - if (memcmp(buf, verify_buf, blocksize)) >>> + if (memcmp(buf, verify_buf, blocksize)) { >>> printk("\nRead/Write test failed at 0x%x\n", >>> (u32)ofs); >>> - >>> + break; >>> + } >>> @@ -322,6 +334,7 @@ static int onenand_dump(struct mtd_info *mtd, ulong >>> off, int only_oob) >>> p += 16; >>> } >>> puts("OOB:\n"); >>> + p = oobbuf; >>> i = mtd->oobsize >> 3; >>> while (i--) { >>> printf("\t%02x %02x %02x %02x %02x %02x %02x %02x\n", >>> @@ -339,7 +352,7 @@ int do_onenand(cmd_tbl_t * cmdtp, int flag, int argc, >>> char *argv[]) >>> struct onenand_chip *this; >>> int blocksize; >>> ulong addr, ofs; >>> - size_t len, retlen = 0; >>> + ssize_t len, retlen = 0; >>> int ret = 0; >>> char *cmd, *s; >>> >>> @@ -385,7 +398,8 @@ int do_onenand(cmd_tbl_t * cmdtp, int flag, int argc, >>> char *argv[]) >>> int erase; >>> >>> erase = strcmp(cmd, "erase") == 0; /* 1 = erase, 0 = >>> test */ >>> - printf("\nOneNAND %s: ", erase ? "erase" : "test"); >>> + printf("\nOneNAND %s %s: ", erase ? "erase" : "test", >>> + force ? "force" : ""); >> These seem to be unrelated changes. > > Right, but i
Re: [U-Boot] stopping u-boot from booting an old image in RAM.
Dear "David Collier", In message you wrote: > If I boot this unit, then remove the SD card it booted from and reset it, > it happily boots some Linux image which is lying around in memory. Maybe you should start reading the documentation? > It even does it after a short power-off power-on sequence. It takes time until memory loses it's content, and as long as the checksums are OK the image is still valid. It is up to you to provide a sane boot command which checks for error code. > I think that's horrible behaviour. Indeed - but that's not U-Boot's fault, it's horrible programming by the user, i. e. yourself. > I was told I could use && instead of ; between the commands in the > bootcmd string to stop this, but that barfed, and then I was told that You really should read the documentation, at least the FAQ, for example "14.2.16. How the Command Line Parsing Works" at http://www.denx.de/wiki/view/DULG/CommandLineParsing > maybe && only existed if "scripting is enabled" Whoever told you that used poor language. What he meant was: if the Hush shell is configured as command line parser for your board. > Could anyone please talk me through the steps of either > > 1. doing what it takes to enable this && feature, so that if it fails to > find the card, it doesn't go on and try to boot. To enable the hush shell, you have to set (at least) the CONFIG_SYS_HUSH_PARSER configuration option in your board config file. But even the old, simple command line parser can be used to do what you want. Just RTFM. > 2. something else that will do it, such as so effectively buggering up an > image that has been booted from that it will never be re-used I cannot parse that. If an image has been booted, U-Boot is gone and out of the way, and whatever code was in the image is running. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Just Say No." - Nancy Reagan "No."- Ronald Reagan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] stopping u-boot from booting an old image in RAM.
Dear "Thompson, Nick (GE EntSol, Intelligent Platforms)", In message <610d18d1f0bb204d8ab39bb1c42187e8041e7...@lonmlvem09.e2k.ad.ge.com> you wrote: > > > 2. something else that will do it, such as so effectively buggering up an > > image that has been booted from that it will never be re-used ... > Probably a simple mw (memory write) to the entry point of linux, before > You attempt to reload the image, would do the trick? This is not needed. Commands return return codes, and the command line parser provides ways to act on these. It's all written in the documentation. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Substitute "damn" every time you're inclined to write "very"; your editor will delete it and the writing will be just as it should be. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] return value from do_ext2load
Dear "David Collier", In message you wrote: > the do_ext2load procedure returns the file length if it succeeds... which > means you can't do You make a pretty definitive statement here. What makes you so sure? Let me tell you that you are wrong. > Is this part of some vast eternal plan and/or can anyone see a way to > make it function as desired anyway? It is working perfectly fine for me. Of course I don't use old, buggy code as you seem to be doing. My code contains this commit: commit 4b7511478b62a539e5b066d19a986b75e5d9a527 Author: Wolfgang Denk Date: Tue Jul 28 22:07:37 2009 +0200 Fix ext2load return code Make the ext2load command return 0 on success (instead of the file length). ... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the beginning there was nothing. And the Lord said "Let There Be Light!" And still there was nothing, but at least now you could see it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] stopping u-boot from booting an old image in RAM.
In article <610d18d1f0bb204d8ab39bb1c42187e8041e7...@lonmlvem09.e2k.ad.ge.com>, nick.thomp...@gefanuc.com (Thompson, Nick (GE EntSol, Intelligent Platforms)) wrote: > *From:* "Thompson, Nick (GE EntSol, Intelligent Platforms)" > > *To:* , > *Date:* Wed, 21 Oct 2009 16:39:18 +0100 > > > -Original Message- > > From: u-boot-boun...@lists.denx.de > > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of David Collier > > Sent: 21 October 2009 16:08 > > To: u-boot@lists.denx.de > > Subject: [U-Boot] stopping u-boot from booting an old image in > > RAM. > > > > If I boot this unit, then remove the SD card it booted from and > > reset it, > > it happily boots some Linux image which is lying around in memory. > > > > It even does it after a short power-off power-on sequence. > > > > I think that's horrible behaviour. > > > > I was told I could use && instead of ; between the commands in the > > bootcmd string to stop this, but that barfed, and then I was told > > that > > maybe && only existed if "scripting is enabled" > > > > Could anyone please talk me through the steps of either > > > > 1. doing what it takes to enable this && feature, so that if it > > fails to > > find the card, it doesn't go on and try to boot. > > > > or > > > > 2. something else that will do it, such as so effectively > > buggering up an > > image that has been booted from that it will never be re-used > > > > :-) > > > > TVM > > > > David Collier > > Probably a simple mw (memory write) to the entry point of linux, > before > You attempt to reload the image, would do the trick? > > Usage: > mw [.b, .w, .l] address value [count] > > Nick. so something like #define CONFIG_BOOTCOMMAND \ "mmcinit ; mw 0x1040 55 ; ext2load mmc 0:1 0x1040 /boot/uImage ; bootm 0x1040" That looks simple enough David Collier www.dexdyne.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] return value from do_ext2load
OK - I'll throw myself on the mercy of the community :-) I have installed hush in my u-boot. I want to fix the following command sequence so that the board only boots if an image was actually loaded from the mmc card bootcmd="mmcinit ; ext2load mmc 0:1 0x1040 /boot/uImage ; bootm 0x1040" I've tried using && but that doesn't seem to work as expected... for instance if I use bootcmd="mmcinit && ext2load mmc 0:1 0x1040 /boot/uImage && bootm 0x1040" the sequence stops if the mmc isn't found, but always stops after the ext2load, even if it's successful. I have tried bootcmd="mmcinit ; mw 0x1040 66 12345 ; ext2load mmc 0:1 0x1040 /boot/uImage ; bootm 0x1040" but the bootm still runs even if no card is inserted and I turn the power off for 1 second. So I'm missing something there!!! Can anyone help? TVM David In article , from_denx_ub...@dexdyne.com (David Collier) wrote: > *From:* "David Collier" > *To:* u-boot@lists.denx.de > *Date:* Wed, 21 Oct 2009 17:23 +0100 (BST) > > the do_ext2load procedure returns the file length if it succeeds... > which > means you can't do > > #define CONFIG_BOOTCOMMAND > "mmcinit && ext2load mmc 0:1 0x1040 /boot/uImage && bootm > 0x1040" > > Is this part of some vast eternal plan and/or can anyone see a way > to > make it function as desired anyway? > > David Collier > > www.dexdyne.com > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > David Collier www.dexdyne.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SD-Card boot from SPI SD-Card
Hi Wilfried, It's possible. Nevertheless, i don't know if the driver is already done. As far as i know all drivers developed doesn't make use of the SPI bus. Just in case, i wrote one for my board and it's working. It could be useful to you. if you want to add MMC drivers you must define CONFIG_MMC, CONFIG_CMD_FAT and CONFIG_DOS_PARTITION in your configuration file. Regards, Ivan Llopard. 2009/10/20 news.gmane.org : > I have a Coldfire MCF5235 Board and I want to boot the uclinux direct from > the sd-card connected to the spi-bus. > Is that possible ? > What do I have to configure ? > Any driver to write ? > > Regards > Wilfried > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] return value from do_ext2load
> Of course I don't use old, buggy code as you seem to be doing. > > My code contains this commit: > > commit 4b7511478b62a539e5b066d19a986b75e5d9a527 > Author: Wolfgang Denk > Date: Tue Jul 28 22:07:37 2009 +0200 > > Fix ext2load return code > > Make the ext2load command return 0 on success (instead of the > file > length). > ... Well that would improve things :-) I'm only using old code because when I last worked on u-boot the latest code couldn't write the AVR32 flash, so I had to back up to the most recent one that could. I don't have time today to do a complete update, but I'll try applying that patch in isolation. Thank you. D > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev > Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, > Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: > w...@denx.de > In the beginning there was nothing. > And the Lord said "Let There Be Light!" > And still there was nothing, but at least now you could see it. > David Collier www.dexdyne.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] return value from do_ext2load
Dear "David Collier", In message you wrote: > OK - I'll throw myself on the mercy of the community :-) > > I have installed hush in my u-boot. Which exact version (commit ID) are you running? And which platform / board is this? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. - Fred Allen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] My SPI driver not working in u-boot.
Dear All Im tryin to write a SPI Driver in u-boot-1.3.4 with SPI BUS 1 support for my processor AT91SAM9261 . I have defined the base macro for SPI bus 1 AT91SAM9261_BASE_SPI1 in /asm/arch/hardware.h and i av passed the bus id and chip select id . but im not getting any data or clock value on the pins . can any body let me what stupid mistake im committing? below is my source if this is not correct way to post plz let me know right way! #include #include #include #include #include #include "atmel_spi.h" void spi_init() { /* do some initialization of SPI bus pins*/ at91_set_A_periph(AT91_PIN_PA25, 0); /* SPI0_NPCS01 */ at91_set_A_periph(AT91_PIN_PB30, 0); /* SPI0_MISO */ at91_set_A_periph(AT91_PIN_PB31, 0); /* SPI0_MOSI */ at91_set_A_periph(AT91_PIN_PB29, 0); /* SPI0_SPCK */ /* Enable clock */ at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9261_ID_SPI1); /* Reset the SPI */ //spi_writel(ATMEL_SPI_SWRST, ATMEL_SPI_CR,1); } struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs, unsigned int max_hz, unsigned int mode) { struct atmel_spi_slave *as; unsigned int scbr; u32 csrx; void *regs; max_hz=1500;/* modified for AMOLED*/ mode=ATMEL_SPI_MR_MSTR; mode =0;/* falling edge of clock spi XFER*/ bus=AT91SAM9261_ID_SPI1; cs=AT91_PIN_PA25;/* chip select of the slave connected to . */ if (cs > 3 || !spi_cs_is_valid(bus, cs)) return NULL; regs = (void *)AT91SAM9261_BASE_SPI1; /* spi bus 1 ID of the */ /* Reset the SPI */ spi_writel(as,ATMEL_SPI_CR,ATMEL_SPI_SWRST); scbr = (AT91_MASTER_CLOCK/max_hz)<<8; /* configure serial clock baud rate*/ if (scbr > ATMEL_SPI_CSRx_SCBR_MAX) /* Too low max SCK rate */ return NULL; if (scbr < 1) scbr = 1; csrx = ATMEL_SPI_CSRx_SCBR(scbr); csrx |= ATMEL_SPI_CSRx_BITS(ATMEL_SPI_BITS_8); if (!(mode & SPI_CPHA)) csrx |= ATMEL_SPI_CSRx_NCPHA; if (mode & SPI_CPOL) csrx |= ATMEL_SPI_CSRx_CPOL; as = malloc(sizeof(struct atmel_spi_slave)); if (!as) return NULL; as->slave.bus = bus; as->slave.cs = cs; as->regs = regs; as->mr = ATMEL_SPI_MR_MSTR | ATMEL_SPI_MR_MODFDIS | ATMEL_SPI_MR_PCS(~(1 << cs) & 0xf); as->mr = ATMEL_SPI_CSRx_NCPHA | ATMEL_SPI_CSR(2) | ATMEL_SPI_MR_MSTR ;/* configure chipselect*/ spi_writel(as, CSR(cs), csrx); return &as->slave; } void spi_free_slave(struct spi_slave *slave) { struct atmel_spi_slave *as = to_atmel_spi(slave); free(as); } int spi_claim_bus(struct spi_slave *slave) { struct atmel_spi_slave *as = to_atmel_spi(slave); /* Enable the SPI hardware */ spi_writel(as, CR, ATMEL_SPI_CR_SPIEN); /* * Select the slave. This should set SCK to the correct * initial state, etc. */ spi_writel(as, MR, as->mr); return 0; } void spi_release_bus(struct spi_slave *slave) { struct atmel_spi_slave *as = to_atmel_spi(slave); /* Disable the SPI hardware */ spi_writel(as, CR, ATMEL_SPI_CR_SPIDIS); } int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout, void *din, unsigned long flags) { struct atmel_spi_slave *as = to_atmel_spi(slave); unsigned int len_tx; unsigned int len_rx; unsigned int len; int ret; u32 status; unsigned short mask ; const u8 *txp = dout; u8 *rxp = din; u8 value; unsigned int pol; bitlen=8; ret = 0; if (bitlen == 0) /* Finish any previously submitted transfers */ goto out; /* * TODO: The controller can do non-multiple-of-8 bit * transfers, but this driver currently doesn't support it. * * It's also not clear how such transfers are supposed to be * represented as a stream of bytes...this is a limitation of * the current SPI interface. */ if (bitlen % 8) { /* Errors always terminate an ongoing transfer */ flags |= SPI_XFER_END; goto out; } len = bitlen / 8; /* * The controller can do automatic CS control, but it is * somewhat quirky, and it doesn't really buy us much anyway * in the context of U-Boot. */ if (flags & SPI_XFER_BEGIN) spi_cs_activate(slave); for (len_tx = 0, len_rx = 0; len_rx < len; ) { status = spi_readl(as, SR); if (status & ATMEL_SPI_SR_OVRES) return -1; if (len_tx < len && (status & ATMEL_SPI_SR_TDRE)) { if (txp) value = *txp++; else value = 0; udelay(50); pol=spi_claim_bus(slave); spi_writel(as, TDR, value); /*write data into device */ spi_release_bus(slave) len_tx++; if (status & ATMEL_SPI_SR_RDRF) { value = spi_readl(as, RDR); if (rxp) *rxp++ = value; len_rx++; } } out: if (flags & SPI_XFER_END) { /* * Wait until the transfer is completely done before * we deactivate CS. */ do { status = spi_readl(as, SR); } while (!(status & ATMEL_SPI_SR_TXEMPTY)); //spi_writel(as,ATMEL_SPI_CSRx_CSAAT, value); spi_cs_deactivate(slave); } return 0; } -- View this message in context: http://www.nabble.com/My-SPI-driver-not-working-in-u-boot.-tp25998508p25998508.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] My SPI driver not working in u-boot.
On Wednesday 21 October 2009 15:16:05 sunr2007 wrote: > Im tryin to write a SPI Driver in u-boot-1.3.4 upgrade -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Warning - delayed mail
*** ** This is a warning only ** **No action is required by you ** *** Re: Message to tha...@pop.jaring.my Your message has not been delivered after 24 hours. Attempts to deliver your message will continue for a further 48 hours. If it has still not been delivered, it will be returned to you. The first few lines of your message are repeated below. The message headers follow: --- Begin Message --- - --- End Message --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DM9000 issue in DM355
Hi Sandeep, Paulraj, Sandeep wrote: > Ben, > > I was taking a closer look at the DM9000 driver by trying it on the DM355 > EVM. And it behaving a little different from before, i.e before we moved to > the NET_MULTI stuff. > > When the board comes after I reflash with a new U-boot image, I no longer see > the ethaddr being set. But when I do a tftp I can see the ethaddr being read. > tftp complains and says no ethaddr set. > > So then I goto the U-Boot prompt and can clearly see that after giving the > tftp command I have the ethaddr in my environment. > > I do a saveenv and set a static ip and then can boot the kernel. > > Even dhcp command does not work and times out. > > Is there any CONFIG flag I am missing? > > Just a couple months ago the DM9000 worked fine without any such issues. > > Thanks, > Sandeep > Sorry for taking so long to reply. It looks like the DM9000 driver doesn't follow proper MAC address etiquette. The proper way is to read from NVRAM in the initialize() function and stuff it in dev->enetaddress. I'm separately sending a patch that compiles fine for me, but I don't have hardware. Please give it a shot, and if it's good we'll look at pulling it in. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix DM9000 MAC address handling
Proper behavior is to pull MAC address from NVRAM in the initialization() and stuff it in dev->address, then program the device from dev->address in the init() function. Signed-off-by: Ben Warren --- drivers/net/dm9000x.c | 27 +++ 1 files changed, 15 insertions(+), 12 deletions(-) diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c index efe9135..d89488e 100644 --- a/drivers/net/dm9000x.c +++ b/drivers/net/dm9000x.c @@ -284,7 +284,6 @@ static int dm9000_init(struct eth_device *dev, bd_t *bd) int i, oft, lnk; u8 io_mode; struct board_info *db = &dm9000_info; - uchar enetaddr[6]; DM9000_DBG("%s\n", __func__); @@ -342,20 +341,11 @@ static int dm9000_init(struct eth_device *dev, bd_t *bd) /* Clear interrupt status */ DM9000_iow(DM9000_ISR, ISR_ROOS | ISR_ROS | ISR_PTS | ISR_PRS); - /* Set Node address */ - if (!eth_getenv_enetaddr("ethaddr", enetaddr)) { -#if !defined(CONFIG_DM9000_NO_SROM) - for (i = 0; i < 3; i++) - dm9000_read_srom_word(i, enetaddr + 2 * i); - eth_setenv_enetaddr("ethaddr", enetaddr); -#endif - } - - printf("MAC: %pM\n", enetaddr); + printf("MAC: %pM\n", dev->enetaddr); /* fill device MAC address registers */ for (i = 0, oft = DM9000_PAR; i < 6; i++, oft++) - DM9000_iow(oft, enetaddr[i]); + DM9000_iow(oft, dev->enetaddr[i]); for (i = 0, oft = 0x16; i < 8; i++, oft++) DM9000_iow(oft, 0xff); @@ -558,6 +548,16 @@ void dm9000_write_srom_word(int offset, u16 val) } #endif +void dm9000_get_enetaddr(struct eth_device *dev) +{ +#if !defined(CONFIG_DM9000_NO_SROM) + int i; + for (i = 0; i < 3; i++) { + dm9000_read_srom_word(i, dev->enetaddr + (2 * i)); + } +#endif +} + /* Read a byte from I/O port */ @@ -621,6 +621,9 @@ int dm9000_initialize(bd_t *bis) { struct eth_device *dev = &(dm9000_info.netdev); + /* Load MAC address from EEPROM */ + dm9000_get_enetaddr(dev); + dev->init = dm9000_init; dev->halt = dm9000_halt; dev->send = dm9000_send; -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix DM9000 MAC address handling
On Wednesday 21 October 2009 20:25:09 Ben Warren wrote: > +void dm9000_get_enetaddr(struct eth_device *dev) static ? > +#if !defined(CONFIG_DM9000_NO_SROM) > + int i; > + for (i = 0; i < 3; i++) { > + dm9000_read_srom_word(i, dev->enetaddr + (2 * i)); > + } dont need the braces ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix DM9000 MAC address handling
Mike Frysinger wrote: > On Wednesday 21 October 2009 20:25:09 Ben Warren wrote: > >> +void dm9000_get_enetaddr(struct eth_device *dev) >> > > static ? > > Yeah, this was thrown together pretty quickly... >> +#if !defined(CONFIG_DM9000_NO_SROM) >> +int i; >> +for (i = 0; i < 3; i++) { >> +dm9000_read_srom_word(i, dev->enetaddr + (2 * i)); >> +} >> > > dont need the braces ... > OK > -mike > thanks for the review, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fdt: Fix fdt padding issue for initrd mem_rsv
Its possible that we end up with a device tree that happens to be a particular size that after we call fdt_resize() we don't have any space left for the initrd mem_rsv. Fix this be adding a second mem_rsv into the size calculation. We had one to cover the fdt itself and we have the potential of adding a second for the initrd. Signed-off-by: Kumar Gala --- Wolfgang, this has been a long standing bug but only shows up if the fdt blob happens to be a particular size. Please include this for the v2009.11 release. - k common/fdt_support.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index 89164a1..fecd904 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -604,10 +604,11 @@ int fdt_resize(void *blob) /* * Calculate the actual size of the fdt -* plus the size needed for fdt_add_mem_rsv +* plus the size needed for two fdt_add_mem_rsv, one +* for the fdt itself and one for a possible initrd */ actualsize = fdt_off_dt_strings(blob) + - fdt_size_dt_strings(blob) + sizeof(struct fdt_reserve_entry); + fdt_size_dt_strings(blob) + 2*sizeof(struct fdt_reserve_entry); /* Make it so the fdt ends on a page boundary */ actualsize = ALIGN(actualsize + ((uint)blob & 0xfff), 0x1000); -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Fix DM9000 MAC address handling
Proper behavior is to pull MAC address from NVRAM in the initialization() an stuff it in dev->address, then program the device from dev->address in the init() function. Signed-off-by: Ben Warren --- v2: Made dm9000_get_enetaddr static and removed unnecessary brace in for loop drivers/net/dm9000x.c | 26 ++ 1 files changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c index efe9135..73dd335 100644 --- a/drivers/net/dm9000x.c +++ b/drivers/net/dm9000x.c @@ -284,7 +284,6 @@ static int dm9000_init(struct eth_device *dev, bd_t *bd) int i, oft, lnk; u8 io_mode; struct board_info *db = &dm9000_info; - uchar enetaddr[6]; DM9000_DBG("%s\n", __func__); @@ -342,20 +341,11 @@ static int dm9000_init(struct eth_device *dev, bd_t *bd) /* Clear interrupt status */ DM9000_iow(DM9000_ISR, ISR_ROOS | ISR_ROS | ISR_PTS | ISR_PRS); - /* Set Node address */ - if (!eth_getenv_enetaddr("ethaddr", enetaddr)) { -#if !defined(CONFIG_DM9000_NO_SROM) - for (i = 0; i < 3; i++) - dm9000_read_srom_word(i, enetaddr + 2 * i); - eth_setenv_enetaddr("ethaddr", enetaddr); -#endif - } - - printf("MAC: %pM\n", enetaddr); + printf("MAC: %pM\n", dev->enetaddr); /* fill device MAC address registers */ for (i = 0, oft = DM9000_PAR; i < 6; i++, oft++) - DM9000_iow(oft, enetaddr[i]); + DM9000_iow(oft, dev->enetaddr[i]); for (i = 0, oft = 0x16; i < 8; i++, oft++) DM9000_iow(oft, 0xff); @@ -558,6 +548,15 @@ void dm9000_write_srom_word(int offset, u16 val) } #endif +static void dm9000_get_enetaddr(struct eth_device *dev) +{ +#if !defined(CONFIG_DM9000_NO_SROM) + int i; + for (i = 0; i < 3; i++) + dm9000_read_srom_word(i, dev->enetaddr + (2 * i)); +#endif +} + /* Read a byte from I/O port */ @@ -621,6 +620,9 @@ int dm9000_initialize(bd_t *bis) { struct eth_device *dev = &(dm9000_info.netdev); + /* Load MAC address from EEPROM */ + dm9000_get_enetaddr(dev); + dev->init = dm9000_init; dev->halt = dm9000_halt; dev->send = dm9000_send; -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] My SPI driver not working in u-boot.
On Thu, Oct 22, 2009 at 1:04 AM, Mike Frysinger wrote: > On Wednesday 21 October 2009 15:16:05 sunr2007 wrote: > > Im tryin to write a SPI Driver in u-boot-1.3.4 > > >>upgrade > done. there's actually not much of diff between the drivers version in u-boot-1.3.4 and u-boot-2009-09 with respect to at91sam9261. Now could u tell me wats exactly the problem in my code? warm regards, Ravi Kulkarni. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to enable to print messages on serial port(ttyS0) in u-boot?
Dear all , Is there a option to print the message or some variable value which i av modified in code to print it on serial console to check whether it is getting executed or not? like we use printf in application programming . if yes how to enable it and use it? . thanks. warm regards, Ravi Kulkarni. -- View this message in context: http://www.nabble.com/How-to-enable-to--print-messages-on-serial-port%28ttyS0%29-in-u-boot--tp26004165p26004165.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] My SPI driver not working in u-boot.
On Thursday 22 October 2009 00:33:19 Ravi Kumar Kulkarni wrote: > On Thu, Oct 22, 2009 at 1:04 AM, Mike Frysinger wrote: > > On Wednesday 21 October 2009 15:16:05 sunr2007 wrote: > > > Im tryin to write a SPI Driver in u-boot-1.3.4 > > > > > >>upgrade > > done. there's actually not much of diff between the drivers version in > u-boot-1.3.4 and u-boot-2009-09 with respect to at91sam9261. except that there's now a common SPI framework for you to use (drivers/spi/) as well as an already existing atmel_spi.c driver -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] My SPI driver not working in u-boot.
On Thu, Oct 22, 2009 at 10:44 AM, Mike Frysinger wrote: > On Thursday 22 October 2009 00:33:19 Ravi Kumar Kulkarni wrote: > > On Thu, Oct 22, 2009 at 1:04 AM, Mike Frysinger > wrote: > > > On Wednesday 21 October 2009 15:16:05 sunr2007 wrote: > >> > > Im tryin to write a SPI Driver in u-boot-1.3.4 > >> > > > >> > >>upgrade > > > >> done. there's actually not much of diff between the drivers version in > >> u-boot-1.3.4 and u-boot-2009-09 with respect to at91sam9261. > > >>except that there's now a common SPI framework for you to use > (drivers/spi/) > >>as well as an already existing atmel_spi.c driver > Yeah exactly . Its also there in u-boot-1.3.4. anyways im using the same driver atmel_spi.c in /drivers/spi/ . atleast can u tell me how to printf to print on ttyS0 in my code so tat i see my flow is workin correct. thanks. warm regards, Ravi Kulkarni. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] My SPI driver not working in u-boot.
>> >>except that there's now a common SPI framework for you to use >> (drivers/spi/) >> >>as well as an already existing atmel_spi.c driver >> > Yeah exactly . Its also there in u-boot-1.3.4. anyways im using the same > driver atmel_spi.c in /drivers/spi/ . > atleast can u tell me how to printf to print on ttyS0 in my code so tat i > see my flow is workin correct. thanks. printf("%s:%d\n", __FILE__, __LINE__);? Given that printf and the UART works on your board that is. /Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regarding NAND flash support in IMX31 and bootm in ubootv2
Hai, I have populated ST 64MB chip and found that the nand flash commands work for ST 64MB chip.But the same NAND flash drivers does not work for SAMSUNG flash , Any Help? Also one more issue is that the linux kernel boot is not seen after the "booting the kernel." , even though the kernel image works fine in old u-boot version 2009-08 Any help Please? Arun The log is == == U-Boot 2.0.0-rc9 (Oct 21 2009 - 09:35:47) Board: Phytec phyCORE-i.MX31 NAND device: Manufacturer ID: 0x20, Chip ID: 0x76 (ST Micro NAND 64MiB 3,3V 8-bi t) Scanning device for bad blocks got MAC address from EEPROM: 00:08:EE:01:7B:56 mx31 cpu clock: 513MHz ipg clock : 64133247Hz Malloc space: 0x8000 -> 0x8040 (size 4 MB) Stack space : 0x8600 -> 0x8602 (size 128 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: 2 type update_kernel nand|nor [] to update kernel into flash type update_root nand|nor [] to update rootfs into flash uboot:/ devinfo devices: |cs0 |mem |nor0 |nand0 ||nand0.kernel ||`nand0.kernel.bb |`nand0.root ||`nand0.root.bb |eth0 |phy0 |ram0 |defaultenv |filesystem: / |filesystem: /dev drivers: imx_serial partition smc911x miiphy nand_device imx_nand cfi_flash mem ram rom nand_bb ramfs devfs uboot:/ update_kernel nand phy0: Link is up - 100/Full host 192.168.50.247 is alive protect: Function not implemented erasing partition /dev/nand0.kernel.bb flashing uImage to /dev/nand0.kernel.bb phy0: Link is up - 100/Full TFTP from server 192.168.50.247; our IP address is 192.168.50.182 Filename 'uImage'. Loading: T # # # # # ### done Bytes transferred = 1822068 (1bcd74 hex) uboot:/bootm /dev/nand0.kernel.bb Verifying Checksum ... OK Image Name: Linux-2.6.24 Created: 2009-10-20 11:06:36 UTC Data Size:1822004 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 OK commandline: console=ttymxc0 arch_number: 1673 Starting kernel ... ## Transferring control to Linux (at address 80008000) ... Uncompressing Linux. ... done, booting the kernel. == ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot