[U-Boot] SD-Card boot from SPI SD-Card
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
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 jac...@sunsite.dk 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 w...@denx.de
Cc: Ben Warren biggerbadder...@gmail.com
---
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 s...@denx.de Cc: Wolfgang Denk w...@denx.de --- 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 nick.thomp...@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.thomp...@gefanuc.com
+ *
+ * Abstracted out code not common to all davinci class devices.
+ *
* Copyright (C) 2007 Sergey Kubushyn k...@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);
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 = 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
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 graeme.r...@gmail.com wrote on 20/10/2009 23:44:14: On Wed, Oct 21, 2009 at 1:35 AM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: In preperation for full relocation Signed-off-by: Graeme Russ graeme.r...@gmail.com --- 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 fun, @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 s...@denx.de
Cc: Wolfgang Denk w...@denx.de
Cc: Gerald Van Baren vanba...@cideas.com
---
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 s...@denx.de Cc: Wolfgang Denk w...@denx.de --- 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.---see mips sun 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 scottw...@freescale.com 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 kyungmin.p...@samsung.com
---
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 it's for exact display for user.
Ideally, you should put minor unrelated changes in a separate patch from
more siginficant changes. At least note them in the changelog.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] stopping u-boot from booting an old image in RAM.
Dear David Collier, In message memo.20091021160842.44...@postmaster+dexdyne.com.cix.co.uk 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 memo.20091021172317.44...@postmaster+dexdyne.com.cix.co.uk 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 w...@denx.de 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) nick.thomp...@gefanuc.com *To:* from_denx_ub...@dexdyne.com, u-boot@lists.denx.de *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 memo.20091021172317.44...@postmaster+dexdyne.com.cix.co.uk, from_denx_ub...@dexdyne.com (David Collier) wrote: *From:* David Collier from_denx_ub...@dexdyne.com *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 w.busal...@lancier-monitoring.de: 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 w...@denx.de 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 memo.20091021190618.44...@postmaster+dexdyne.com.cix.co.uk 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 common.h
#include spi.h
#include malloc.h
#include asm/io.h
#include asm/arch/hardware.h
#include asm/arch/at91_spi.h
#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: ---BeginMessage--- - ---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 biggerbadder...@gmail.com
---
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 ga...@kernel.crashing.org --- 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 biggerbadder...@gmail.com
---
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 vap...@gentoo.org 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 vap...@gentoo.org 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 vap...@gentoo.org wrote: On Thursday 22 October 2009 00:33:19 Ravi Kumar Kulkarni wrote: On Thu, Oct 22, 2009 at 1:04 AM, Mike Frysinger vap...@gentoo.org 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
