Re: [U-Boot] [PATCH] OpenRD: Bring PCIe endpoint out of reset
-Original Message- From: Tanmay Upadhyay [mailto:tanmay.upadh...@einfochips.com] Sent: Tuesday, April 20, 2010 11:21 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Tanmay Upadhyay; Dhaval Vasa Subject: [PATCH] OpenRD: Bring PCIe endpoint out of reset There exists PCIe endpoints(not all) that remains in reset state till PERST# line (A11 on the PCIe connector) is hold low. They come out of reset only when this line is high. In case of OpenRD, this line was in tri-state. So, some of the PCIe devices would never appear on the PCIe bus. This patch makes PERST# line high while booting to bring such PCIe devices out of reset. XGI Vollari Z11 GPU and Intel WiFi 4965 are the ones who doesn't care about this line. Where as Broadcom's BCM970012 won't appear on the PCIe bus until PERST# is high. With this patch both kinds of device would appear on the PCIe bus. Well, there is some problem indeed on OpenRD board regarding PCIe. This patch did not helped me to test the hardware that I have. I have Matrox 550 graphics card on PCIe, I have enabled respective support in the kernel and tried to bring it up. This patch did not helped me for successful bring up. Whereas, if I use u-boot from official release (that comes with board) everything works fine. And that does not have this patch. So I think this is not perfect resolution for this problem. We need to dig more into the issue. Copying Simon.. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SystemAce not ready under XUPV2P and XUPV5
Hi, I have a problem with accessing the cf-card under u-boot. I use the XUPV2P with a ppc + microblaze and the XUPV5 with mb only. None of my eval-bords work with cf. This is the error-message under the xupv2p with ppc: t001-ppc405:/# fatinfo ace 0:0 ACE CompactFlash not found. SystemACE not ready. ** Can't read from device 0 ** ** Unable to use ace 0:0 for fatinfo ** After searching with google I found this: http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2008/10/msg00144.html It seems this is the same prob. This are the defines of my xilinx-ppc405-generic.h: /*SystemACE*/ #define CONFIG_SYSTEMACE #define CONFIG_DOS_PARTITION #define CONFIG_SYS_SYSTEMACE_BASE 0x8360 #define CONFIG_SYS_SYSTEMACE_WIDTH 16 #define SYSTEMACE_CONFIG_FPGA #define DEBUG_SYSTEMACE Under microblaze i have the same problems. Greets, Oliver -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/17] Network support for spear platform and spear1300 support
Hello Tom/Wolfgang,
Didn't see any feedbacks on this patchset.
Please let me know if the patch is good or should I make changes and resubmit
Thanks in advance
Regards
Vipin
On 4/26/2010 8:26 AM, Vipin KUMAR wrote:
Hi,
The following subpatches incorporate review comments given on patch-set v1.
Please consider it for inclusion in mainline
Thanks and Regards
Vipin
Vipin Kumar (17):
u-boot.img file not created when srctree and objtree are different
change_bit routine defined
SPEAr : SMI erase and write timeouts increased
SPEAr : Placing ethaddr write and read within CONFIG_CMD_NET
SPEAr : Reducing the max RAM size to 128MB
SPEAr : Basic arch related support added for SPEAr SoCs
SPEAr : Network driver support added
SPEAr : Network support configured for spear SoCs
SPEAr : macb driver support added for spear310 and spear320
SPEAr : FSMC driver support added
SPEAr : Configuring FSMC driver for NAND interface
SPEAr : i2c driver moved completely into drivers/i2c
SPEAr : smi driver moved completely into drivers/mtd
SPEAr : USBD driver support added
SPEAr : Basic spear1300 architecture support added
SPEAr : spear1300 SoC support added
SPEAr : Supporting various configurations for spear3xx and spear6xx
boards
Makefile | 24 +-
arch/arm/cpu/arm926ejs/spear/Makefile |3 +-
arch/arm/cpu/arm926ejs/spear/cpu.c | 76 +++
arch/arm/cpu/arm_cortexa8/spear13xx/Makefile | 52 ++
arch/arm/cpu/arm_cortexa8/spear13xx/cache.S| 112
arch/arm/cpu/arm_cortexa8/spear13xx/cpu.c | 99
.../arm_cortexa8/spear13xx/reset.c}| 50 +--
arch/arm/cpu/arm_cortexa8/spear13xx/timer.c| 136 +
arch/arm/include/asm/arch-spear/clk.h | 27 +
arch/arm/include/asm/arch-spear/hardware.h | 16 +-
arch/arm/include/asm/arch-spear/spr_misc.h |5 +
arch/arm/include/asm/arch-spear13xx/hardware.h | 40 ++
arch/arm/include/asm/arch-spear13xx/spr_gpt.h | 85 +++
arch/arm/include/asm/arch-spear13xx/spr_misc.h | 317
arch/arm/include/asm/arch-spear13xx/sys_proto.h| 32 ++
arch/arm/include/asm/bitops.h | 11 +-
board/spear/common/Makefile| 10 +-
board/spear/common/spr_misc.c | 23 +-
board/spear/spear1300/Makefile | 51 ++
board/spear/spear1300/config.mk| 28 +
board/spear/spear1300/spear1300.c | 86
.../spear/spear1300/spr_lowlevel_init.S| 49 +--
board/spear/spear300/config.mk | 11 -
board/spear/spear300/spear300.c| 10 +-
board/spear/spear310/config.mk | 11 -
board/spear/spear310/spear310.c| 17 +-
board/spear/spear320/config.mk | 11 -
board/spear/spear320/spear320.c| 14 +-
board/spear/spear600/config.mk | 11 -
board/spear/spear600/spear600.c| 10 +-
drivers/i2c/Makefile |2 +-
drivers/i2c/{spr_i2c.c = designware_i2c.c}|4 +-
.../spr_i2c.h = drivers/i2c/designware_i2c.h |6 +-
drivers/mtd/Makefile |2 +-
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/fsmc_nand.c | 365 +
drivers/mtd/nand/spr_nand.c| 124 -
drivers/mtd/{spr_smi.c = st_smi.c}| 10 +-
.../arch-spear/spr_smi.h = drivers/mtd/st_smi.h | 10 +-
drivers/net/Makefile |1 +
drivers/net/designware.c | 537
drivers/net/designware.h | 264 ++
drivers/serial/usbtty.h|4 +-
drivers/usb/gadget/Makefile|2 +-
drivers/usb/gadget/{spr_udc.c = designware_udc.c} | 116 +++--
include/configs/spear-common.h | 27 +-
include/configs/spear13xx.h| 199
include/configs/spear3xx.h | 30 ++
include/configs/spear6xx.h | 13 +
include/linux/mtd/fsmc_nand.h | 104
include/netdev.h |1 +
include/usb/{spr_udc.h = designware_udc.h}|8 +-
52 files changed, 2918 insertions(+), 340 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/spear/cpu.c
create mode 100644 arch/arm/cpu/arm_cortexa8/spear13xx/Makefile
create mode 100644 arch/arm/cpu/arm_cortexa8/spear13xx/cache.S
create mode 100644 arch/arm/cpu/arm_cortexa8/spear13xx/cpu.c
copy arch/arm/{include/asm/arch-spear/spr_nand.h =
Re: [U-Boot] [PATCH] Blackfin: bfin_mac: hook up new write_hwaddr function
Hi Mike and Ben, if the new direction is to have the OS booted with the current correct MAC address programmed regardless of any net funcs being called, then the current logic in eth_initialize() will probably need to be replicated back into cmd_nvedit (see commit 56b555a644). then the logic in eth_init() here can be dropped, and drivers themselves can lose the MAC programming in their init() funcs. For the direction we have taken, I consider this to be a completion of the path. Actually I did not realize that we had such a mac-programming in setenv at all and that Mike explicitely took it out, but I realized that we certainly would need such a thing. I considered it to be much easier hoewever once we have such a method of the netdevice. however, considering the number of drivers and thrashing this policy is causing, and the intent for this to be a stop gap measure, i'm not sure we should change the init() func in drivers to stop programming the MAC address. otherwise we're going to have to do this same thing yet again but in the reverse direction. We are aiming at a level of consitency which we never had before, so I expect some changes. They are quite small however and the amount of ongoing patches to adopt the new policy encourage me to be optimistic here ;) Cheers Detlev -- We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely. --- Oscar Wilde -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 v2] spi_flash: support old STMicro parts with RES
On Thursday 29 April 2010 23:34:17 Thomas Chou wrote: --- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c @@ -147,6 +147,7 @@ struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs, #endif #ifdef CONFIG_SPI_FLASH_STMICRO case 0x20: + case 0xff: flash = spi_flash_probe_stmicro(spi, idcode); break; #endif hrm, this kind of sucks, but i guess for now it's fine. stick a comment in there about why we're sending the normal error byte to the stmicro function. /* Let the stmicro func handle non-JEDEC ids */ -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 v2 00/17] Network support for spear platform and spear1300 support
Vipin KUMAR wrote:
Hello Tom/Wolfgang,
Didn't see any feedbacks on this patchset.
Please let me know if the patch is good or should I make changes and resubmit
Vipin,
I will provide you with complete review of your patch set this weekend.
Please use MAKEALL arm to check for regressions.
There is a compile error for spear310 and spear320.
Here is the spear310 error, spear320 is similar
spear310.c: In function 'board_eth_init':
spear310.c:64: warning: implicit declaration of function
'dw_mii_initialize'
board/spear/spear310/libspear310.a(spear310.o): In function
`board_eth_init':
.../u-boot/src/u-boot-arm/board/spear/spear310/spear310.c:64: undefined
reference to `dw_mii_initialize'
This error must be resolved.
FYI my email address has changed to t...@bumblecow.com.
Tom
Thanks in advance
Regards
Vipin
On 4/26/2010 8:26 AM, Vipin KUMAR wrote:
Hi,
The following subpatches incorporate review comments given on patch-set v1.
Please consider it for inclusion in mainline
Thanks and Regards
Vipin
Vipin Kumar (17):
u-boot.img file not created when srctree and objtree are different
change_bit routine defined
SPEAr : SMI erase and write timeouts increased
SPEAr : Placing ethaddr write and read within CONFIG_CMD_NET
SPEAr : Reducing the max RAM size to 128MB
SPEAr : Basic arch related support added for SPEAr SoCs
SPEAr : Network driver support added
SPEAr : Network support configured for spear SoCs
SPEAr : macb driver support added for spear310 and spear320
SPEAr : FSMC driver support added
SPEAr : Configuring FSMC driver for NAND interface
SPEAr : i2c driver moved completely into drivers/i2c
SPEAr : smi driver moved completely into drivers/mtd
SPEAr : USBD driver support added
SPEAr : Basic spear1300 architecture support added
SPEAr : spear1300 SoC support added
SPEAr : Supporting various configurations for spear3xx and spear6xx
boards
Makefile | 24 +-
arch/arm/cpu/arm926ejs/spear/Makefile |3 +-
arch/arm/cpu/arm926ejs/spear/cpu.c | 76 +++
arch/arm/cpu/arm_cortexa8/spear13xx/Makefile | 52 ++
arch/arm/cpu/arm_cortexa8/spear13xx/cache.S| 112
arch/arm/cpu/arm_cortexa8/spear13xx/cpu.c | 99
.../arm_cortexa8/spear13xx/reset.c}| 50 +--
arch/arm/cpu/arm_cortexa8/spear13xx/timer.c| 136 +
arch/arm/include/asm/arch-spear/clk.h | 27 +
arch/arm/include/asm/arch-spear/hardware.h | 16 +-
arch/arm/include/asm/arch-spear/spr_misc.h |5 +
arch/arm/include/asm/arch-spear13xx/hardware.h | 40 ++
arch/arm/include/asm/arch-spear13xx/spr_gpt.h | 85 +++
arch/arm/include/asm/arch-spear13xx/spr_misc.h | 317
arch/arm/include/asm/arch-spear13xx/sys_proto.h| 32 ++
arch/arm/include/asm/bitops.h | 11 +-
board/spear/common/Makefile| 10 +-
board/spear/common/spr_misc.c | 23 +-
board/spear/spear1300/Makefile | 51 ++
board/spear/spear1300/config.mk| 28 +
board/spear/spear1300/spear1300.c | 86
.../spear/spear1300/spr_lowlevel_init.S| 49 +--
board/spear/spear300/config.mk | 11 -
board/spear/spear300/spear300.c| 10 +-
board/spear/spear310/config.mk | 11 -
board/spear/spear310/spear310.c| 17 +-
board/spear/spear320/config.mk | 11 -
board/spear/spear320/spear320.c| 14 +-
board/spear/spear600/config.mk | 11 -
board/spear/spear600/spear600.c| 10 +-
drivers/i2c/Makefile |2 +-
drivers/i2c/{spr_i2c.c = designware_i2c.c}|4 +-
.../spr_i2c.h = drivers/i2c/designware_i2c.h |6 +-
drivers/mtd/Makefile |2 +-
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/fsmc_nand.c | 365 +
drivers/mtd/nand/spr_nand.c| 124 -
drivers/mtd/{spr_smi.c = st_smi.c}| 10 +-
.../arch-spear/spr_smi.h = drivers/mtd/st_smi.h | 10 +-
drivers/net/Makefile |1 +
drivers/net/designware.c | 537
drivers/net/designware.h | 264 ++
drivers/serial/usbtty.h|4 +-
drivers/usb/gadget/Makefile|2 +-
drivers/usb/gadget/{spr_udc.c = designware_udc.c} | 116 +++--
include/configs/spear-common.h | 27 +-
include/configs/spear13xx.h| 199
[U-Boot] Debugging into the kernel from u-boot
Hi all- I - more or less - successfully got U-Boot up and running on our custom designed board. U-Boot leaves its premices in boot_jump_linux and this is the last I see on the console: ## Booting kernel from Legacy Image at 0200 ... Image Name: Linux-2.6.29.6-rt23 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1830522 Bytes = 1.7 MB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0040 Booting using the fdt blob at 0x40 Uncompressing Kernel Image ... OK ## Transferring control to Linux (at address )... Booting using OF flat tree... When I halt the board using the BDI3000 debugger, I find the PC somewhere in 0xc000c96c in __delay. Accessing 0xc000 makes no sense, as we don't even have mapped memory there. Using HW breakpoints I can see the single instructions from 0x0 on, but I get no link to the source. Where can I get a meaningful starting point in the kernel? Why are all the symbols in vmlinux located at 0xc0... and how does the relocation take place? I saw some comment in arch/powerpc/kernel/setup_32.c but yet I have no clue where to start practically? Any help would be appreciated! Have a nice weekend! Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
Some old STMicro parts do not support JEDEC ID (0x9f). This patch
uses RES (0xab) to get Electronic ID and translates it to JEDEC ID.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
v3: add comment as Mike suggested for 0xff id switch.
v2: move the logic to stmicro's probe function
drivers/mtd/spi/spi_flash.c |1 +
drivers/mtd/spi/stmicro.c | 21 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 612f819..c8e4bdd 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -147,6 +147,7 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
#endif
#ifdef CONFIG_SPI_FLASH_STMICRO
case 0x20:
+ case 0xff: /* Let the stmicro func handle non-JEDEC ids */
flash = spi_flash_probe_stmicro(spi, idcode);
break;
#endif
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index ae0d047..21e9b00 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -46,6 +46,7 @@
#define CMD_M25PXX_DP 0xb9/* Deep Power-down */
#define CMD_M25PXX_RES 0xab/* Release from DP, and Read Signature
*/
+#define STM_ID_M25P10 0x11
#define STM_ID_M25P16 0x15
#define STM_ID_M25P20 0x12
#define STM_ID_M25P32 0x16
@@ -78,6 +79,13 @@ static inline struct stmicro_spi_flash
*to_stmicro_spi_flash(struct spi_flash
static const struct stmicro_spi_flash_params stmicro_spi_flash_table[] = {
{
+ .idcode1 = STM_ID_M25P10,
+ .page_size = 256,
+ .pages_per_sector = 128,
+ .nr_sectors = 4,
+ .name = M25P10,
+ },
+ {
.idcode1 = STM_ID_M25P16,
.page_size = 256,
.pages_per_sector = 256,
@@ -316,6 +324,19 @@ struct spi_flash *spi_flash_probe_stmicro(struct spi_slave
*spi, u8 * idcode)
struct stmicro_spi_flash *stm;
unsigned int i;
+ if (idcode[0] == 0xff) {
+ i = spi_flash_cmd(spi, CMD_M25PXX_RES,
+ idcode, 4);
+ if (i)
+ return NULL;
+ if ((idcode[3] 0xf0) == 0x10) {
+ idcode[0] = 0x20;
+ idcode[1] = 0x20;
+ idcode[2] = idcode[3] + 1;
+ } else
+ return NULL;
+ }
+
for (i = 0; i ARRAY_SIZE(stmicro_spi_flash_table); i++) {
params = stmicro_spi_flash_table[i];
if (params-idcode1 == idcode[2]) {
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Blackfin: bfin_mac: hook up new write_hwaddr function
On Friday 30 April 2010 08:40:21 Detlev Zundel wrote: if the new direction is to have the OS booted with the current correct MAC address programmed regardless of any net funcs being called, then the current logic in eth_initialize() will probably need to be replicated back into cmd_nvedit (see commit 56b555a644). then the logic in eth_init() here can be dropped, and drivers themselves can lose the MAC programming in their init() funcs. For the direction we have taken, I consider this to be a completion of the path. Actually I did not realize that we had such a mac-programming in setenv at all and that Mike explicitely took it out, but I realized that we certainly would need such a thing. I considered it to be much easier hoewever once we have such a method of the netdevice. you seem to be confused by what that code actually did. it never programmed the mac in the hardware, it synced the eth_device and the environment. the behavior we have today is exactly the same before that series of commits i referenced. i simply standardized things across the board and unified heavily duplicated behavior. what i'm talking about adding here is different from what used to be there ... it's just that the mechanism is the same. however, considering the number of drivers and thrashing this policy is causing, and the intent for this to be a stop gap measure, i'm not sure we should change the init() func in drivers to stop programming the MAC address. otherwise we're going to have to do this same thing yet again but in the reverse direction. We are aiming at a level of consitency which we never had before, so I expect some changes. They are quite small however and the amount of ongoing patches to adopt the new policy encourage me to be optimistic here ;) there's going to be one patch for every driver. just because only a few people have submitted patches for drivers they're interested in doesnt mean the overall thrashing is small. a quick grep counts about 35 drivers that need updating. -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 5/6 v2] spi_flash: support old STMicro parts with RES
On 04/30/2010 08:48 PM, Mike Frysinger wrote: On Thursday 29 April 2010 23:34:17 Thomas Chou wrote: --- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c @@ -147,6 +147,7 @@ struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs, #endif #ifdef CONFIG_SPI_FLASH_STMICRO case 0x20: +case 0xff: flash = spi_flash_probe_stmicro(spi, idcode); break; #endif hrm, this kind of sucks, but i guess for now it's fine. stick a comment in there about why we're sending the normal error byte to the stmicro function. /* Let the stmicro func handle non-JEDEC ids */ -mike Hi Mike, I added the comment. Thank you very much. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Save environment data to mmc.
Hi Terry, [Ty]: env_ptr is defined in env_mmc.c and the value is assigned in env_common.c. Correct me if I'm wrong. No, you are right - env_relocate() called malloc and initialize the pointer. Best regards, Stefano -- = 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] Splash screen problem
Ok, i solved it witch preboot envinment variable. Thansk for advice. Best Regards Radovan Vapenik Původní zpráva Od: Wolfgang Denk w...@denx.de Předmět: Re: Re: Re: [U-Boot] Splash screen problem Datum: 29.4.2010 22:57:31 Dear =?iso-8859-2?Q?Radovan=20V=E1pen=EDk?=, In message 56295.4069.1007-22739-950867926-1272543...@seznam.cz you wrote: The environment variable preboot runs after splashimage, which other env variablecan I use, which runs before splashimage? You cannot. But you can fake the actions by using nand read and bmp as preboot command. Not perfect, but close. 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 People are always a lot more complicated than you think. It's very important to remember that. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
On Friday 30 April 2010 09:11:20 Thomas Chou wrote: Some old STMicro parts do not support JEDEC ID (0x9f). This patch uses RES (0xab) to get Electronic ID and translates it to JEDEC ID. Signed-off-by: Thomas Chou tho...@wytron.com.tw Acked-by: Mike Frysinger vap...@gentoo.org if we want to do non-jedec stuff in other parts, we can worry about refactoring this code then -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] [PATCH v2] sf: move useful messages from debug to printf
At the moment, the default SPI flash subsystem is quite terse. Errors and
successes both result in a generic message. So move the useful errors and
useful successes to printf output by default.
While we're here, also convert the messages to use print_size().
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v2
- use print_size() per Wolfgang
drivers/mtd/spi/atmel.c |7 ---
drivers/mtd/spi/macronix.c |5 +++--
drivers/mtd/spi/spansion.c |5 +++--
drivers/mtd/spi/spi_flash.c |4 ++--
drivers/mtd/spi/sst.c |5 +++--
drivers/mtd/spi/stmicro.c |5 +++--
drivers/mtd/spi/winbond.c |7 ---
7 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/spi/atmel.c b/drivers/mtd/spi/atmel.c
index 8306c00..8d02169 100644
--- a/drivers/mtd/spi/atmel.c
+++ b/drivers/mtd/spi/atmel.c
@@ -467,7 +467,7 @@ out:
struct spi_flash *spi_flash_probe_atmel(struct spi_slave *spi, u8 *idcode)
{
const struct atmel_spi_flash_params *params;
- unsigned long page_size;
+ unsigned page_size;
unsigned int family;
struct atmel_spi_flash *asf;
unsigned int i;
@@ -540,8 +540,9 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave
*spi, u8 *idcode)
* params-blocks_per_sector
* params-nr_sectors;
- debug(SF: Detected %s with page size %lu, total %u bytes\n,
- params-name, page_size, asf-flash.size);
+ printf(SF: Detected %s with page size %u, total ,
+ params-name, page_size);
+ print_size(asf-flash.size, \n);
return asf-flash;
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
index fe1310b..76d5284 100644
--- a/drivers/mtd/spi/macronix.c
+++ b/drivers/mtd/spi/macronix.c
@@ -330,8 +330,9 @@ struct spi_flash *spi_flash_probe_macronix(struct spi_slave
*spi, u8 *idcode)
mcx-flash.size = params-page_size * params-pages_per_sector
* params-sectors_per_block * params-nr_blocks;
- printf(SF: Detected %s with page size %u, total %u bytes\n,
- params-name, params-page_size, mcx-flash.size);
+ printf(SF: Detected %s with page size %u, total ,
+ params-name, params-page_size);
+ print_size(mcx-flash.size, \n);
return mcx-flash;
}
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index fdb7917..d6c1a5f 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -343,8 +343,9 @@ struct spi_flash *spi_flash_probe_spansion(struct spi_slave
*spi, u8 *idcode)
spsn-flash.size = params-page_size * params-pages_per_sector
* params-nr_sectors;
- debug(SF: Detected %s with page size %u, total %u bytes\n,
- params-name, params-page_size, spsn-flash.size);
+ printf(SF: Detected %s with page size %u, total ,
+ params-name, params-page_size);
+ print_size(spsn-flash.size, \n);
return spsn-flash;
}
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 612f819..bbb194e 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -106,7 +106,7 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
spi = spi_setup_slave(bus, cs, max_hz, spi_mode);
if (!spi) {
- debug(SF: Failed to set up slave\n);
+ printf(SF: Failed to set up slave\n);
return NULL;
}
@@ -156,7 +156,7 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
break;
#endif
default:
- debug(SF: Unsupported manufacturer %02X\n, idcode[0]);
+ printf(SF: Unsupported manufacturer %02X\n, idcode[0]);
flash = NULL;
break;
}
diff --git a/drivers/mtd/spi/sst.c b/drivers/mtd/spi/sst.c
index 50e9299..2557891 100644
--- a/drivers/mtd/spi/sst.c
+++ b/drivers/mtd/spi/sst.c
@@ -364,8 +364,9 @@ spi_flash_probe_sst(struct spi_slave *spi, u8 *idcode)
stm-flash.read = sst_read_fast;
stm-flash.size = SST_SECTOR_SIZE * params-nr_sectors;
- debug(SF: Detected %s with page size %u, total %u bytes\n,
- params-name, SST_SECTOR_SIZE, stm-flash.size);
+ printf(SF: Detected %s with page size %u, total ,
+ params-name, SST_SECTOR_SIZE);
+ print_size(stm-flash.size, \n);
/* Flash powers up read-only, so clear BP# bits */
sst_unlock(stm-flash);
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index ae0d047..6c52f6a 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -344,8 +344,9 @@ struct spi_flash *spi_flash_probe_stmicro(struct spi_slave
*spi, u8 * idcode)
stm-flash.size = params-page_size * params-pages_per_sector
* params-nr_sectors;
- debug(SF: Detected %s with page size %u, total %u
[U-Boot] [OT] - Seeking information Re: Memory Mapped CF Card (IDE) and Linux
Hi All, I'm looking for information on how to access a Compact Flash card which is memory-mapped (from 0x20001000) From what I have read, there a 3 address lines (8 addresses) which access IDE registers within the CF chip My question is, how do I access such a custom address range within Linux? I'm looking at the 'OF-platform PATA driver' which appears to be what I want (a very basic IDE driver) but I am a bit lost on how to set up a specific base address. Where should I look for examples of CF cards mapped to specific address spaces? TIA Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6 v3] nios2: add gpio support to nios2-generic board
Thomas Chou wrote: This patch adds gpio support of Altera PIO component to the nios2-generic board. Though it drives only gpio_led at the moment, it supports bidirectional port to control bit-banging I2C, NAND flash busy status or button switches, etc. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- v3: split patches for gpio and spi, based gpio on altera pio core. v2: remove mmc_spi_init() board/altera/nios2-generic/Makefile |1 + board/altera/nios2-generic/gpio.c | 55 +++ include/configs/nios2-generic.h |6 ++-- 3 files changed, 59 insertions(+), 3 deletions(-) create mode 100644 board/altera/nios2-generic/gpio.c diff --git a/board/altera/nios2-generic/Makefile b/board/altera/nios2-generic/Makefile index 6780872..d1fca70 100644 --- a/board/altera/nios2-generic/Makefile +++ b/board/altera/nios2-generic/Makefile @@ -32,6 +32,7 @@ LIB = $(obj)lib$(BOARD).a COBJS-y := $(BOARD).o COBJS-$(CONFIG_CMD_IDE) += ../common/cfide.o COBJS-$(CONFIG_EPLED) += ../common/epled.o +COBJS-$(CONFIG_GPIO) += gpio.o COBJS-$(CONFIG_SEVENSEG) += ../common/sevenseg.o This will build a u-boot image that will not work with any of the standard configurations ... correct? ... since the GPIO component is custom (not supplied by the vendor)? --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting kernel from SD/MMC cards
Hi, Does u-boot support booting linux kernel from SD/MMC cards. regards vibi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting kernel from SD/MMC cards
Which processor? Regards Poonam -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of vibi sreenivasan Sent: Friday, April 30, 2010 8:17 PM To: u-boot@lists.denx.de Subject: [U-Boot] Booting kernel from SD/MMC cards Hi, Does u-boot support booting linux kernel from SD/MMC cards. regards vibi ___ 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] [PATCH 3/6 v3] nios2: add gpio support to nios2-generic board
On 04/30/2010 10:24 PM, Scott McNutt wrote: Thomas Chou wrote: This patch adds gpio support of Altera PIO component to the nios2-generic board. Though it drives only gpio_led at the moment, it supports bidirectional port to control bit-banging I2C, NAND flash busy status or button switches, etc. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- v3: split patches for gpio and spi, based gpio on altera pio core. v2: remove mmc_spi_init() board/altera/nios2-generic/Makefile |1 + board/altera/nios2-generic/gpio.c | 55 +++ include/configs/nios2-generic.h |6 ++-- 3 files changed, 59 insertions(+), 3 deletions(-) create mode 100644 board/altera/nios2-generic/gpio.c diff --git a/board/altera/nios2-generic/Makefile b/board/altera/nios2-generic/Makefile index 6780872..d1fca70 100644 --- a/board/altera/nios2-generic/Makefile +++ b/board/altera/nios2-generic/Makefile @@ -32,6 +32,7 @@ LIB= $(obj)lib$(BOARD).a COBJS-y:= $(BOARD).o COBJS-$(CONFIG_CMD_IDE) += ../common/cfide.o COBJS-$(CONFIG_EPLED) += ../common/epled.o +COBJS-$(CONFIG_GPIO) += gpio.o COBJS-$(CONFIG_SEVENSEG) += ../common/sevenseg.o This will build a u-boot image that will not work with any of the standard configurations ... correct? ... since the GPIO component is custom (not supplied by the vendor)? Hi Scott, The board gpio.c driver works on Altera PIO component. It will behave exactly the same as the epled driver. I have tested it on EP1C20 an EP2C35 board with standard configuration. I believe it will work with the standard configuration on EP1S10 and EP1S40. I don't want to break anything. It was actually the first gpio driver I wrote for nios2-linux before the custom gpio core. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6 v3] nios2: add gpio support to nios2-generic board
Thomas Chou wrote: On 04/30/2010 10:24 PM, Scott McNutt wrote: Thomas Chou wrote: This patch adds gpio support of Altera PIO component to the nios2-generic board. Though it drives only gpio_led at the moment, it supports bidirectional port to control bit-banging I2C, NAND flash busy status or button switches, etc. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- v3: split patches for gpio and spi, based gpio on altera pio core. v2: remove mmc_spi_init() board/altera/nios2-generic/Makefile |1 + board/altera/nios2-generic/gpio.c | 55 +++ include/configs/nios2-generic.h |6 ++-- 3 files changed, 59 insertions(+), 3 deletions(-) create mode 100644 board/altera/nios2-generic/gpio.c diff --git a/board/altera/nios2-generic/Makefile b/board/altera/nios2-generic/Makefile index 6780872..d1fca70 100644 --- a/board/altera/nios2-generic/Makefile +++ b/board/altera/nios2-generic/Makefile @@ -32,6 +32,7 @@ LIB= $(obj)lib$(BOARD).a COBJS-y:= $(BOARD).o COBJS-$(CONFIG_CMD_IDE) += ../common/cfide.o COBJS-$(CONFIG_EPLED) += ../common/epled.o +COBJS-$(CONFIG_GPIO) += gpio.o COBJS-$(CONFIG_SEVENSEG) += ../common/sevenseg.o This will build a u-boot image that will not work with any of the standard configurations ... correct? ... since the GPIO component is custom (not supplied by the vendor)? Hi Scott, The board gpio.c driver works on Altera PIO component. It will behave exactly the same as the epled driver. I have tested it on EP1C20 an EP2C35 board with standard configuration. I believe it will work with the standard configuration on EP1S10 and EP1S40. I don't want to break anything. Ok. I'll try to test over the weekend as well. Thanks, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] i have problem with u-boot-2010.03
Dear everyone i'm Phuong i living vietnamesepresent, i research chip's atmel (AT91SAM9260) and i want to install u-boot on chip AT91SAM9260 but i have some problem with it, so that i need help from you this is my step build u-boot: step 1: i configure it for chip AT91SAM9260 technical information: Basetext :21f0 set At45DB041D 0x1C Bus with sdram to 16Bitsstep 2: i build it with gcc,toolchain make 0=/tmp/build distclean make 0=/tmp/build at91sam9260ek_dataflash_cs1_config make 0=/tmp/build allstep 3 : i open samba v2.9 in windows i puts bootstrap v.1.5 in 0x0 i puts u-boot.bin in 8400final: i'm reset my board but i get cksum bad. i don't understand it. can you help me ??? note: i use linux OS(ubuntu 9.04) I am looking forward to hear from you soon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] problem with u-boot 2010.03
Dear everyone i'm Phuong i living vietnamesepresent, i research chip's atmel (AT91SAM9260) and i want to install u-boot on chip AT91SAM9260 but i have some problem with it, so that i need help from you this is my step build u-boot: step 1: i configure it for chip AT91SAM9260 technical information: Basetext :21f0 set At45DB041D 0x1C Bus with sdram to 16Bits step 2: i build it with gcc,toolchain make 0=/tmp/build distclean make 0=/tmp/build at91sam9260ek_dataflash_cs1_config make 0=/tmp/build all step 3 : i open samba v2.9 in windows i puts bootstrap v.1.5 in 0x0 i puts u-boot.bin in 8400 final: i'm reset my board but i get cksum bad. i don't understand it. can you help me ??? note: i use linux OS(ubuntu 9.04) I am looking forward to hear from you soon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] - Seeking information Re: Memory Mapped CF Card (IDE) and Linux
On Friday 30 April 2010 10:11:53 Graeme Russ wrote: I'm looking for information on how to access a Compact Flash card which is memory-mapped (from 0x20001000) From what I have read, there a 3 address lines (8 addresses) which access IDE registers within the CF chip My question is, how do I access such a custom address range within Linux? wouldnt this be a better question posted to lkml and/or the linux-ide lists ? I'm looking at the 'OF-platform PATA driver' which appears to be what I want (a very basic IDE driver) but I am a bit lost on how to set up a specific base address. Where should I look for examples of CF cards mapped to specific address spaces? we do it on the Blackfin quite a bit using the pata platform driver: http://docs.blackfin.uclinux.org/doku.php?id=hw:cards:cf-ide-nand -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] ARM1176: Coexist with other ARM1176 platforms
Hi Tom, [...] +#ifndef CONFIG_SKIP_LOWLEVEL_INIT CONFIG_SKIP_LOWLEVEL_INIT is not used in the other patches. Why is this needed ? board/samsung/samsung/smdk6400 has a lowlevel_init.o function. It is confusing why this function is being if-def and not the real lowlevel_init.. Will remove. +#ifdef CONFIG_ENABLE_MMU This logic is may not be quite correct From include/configs/smdk6400.h #if !defined(CONFIG_NAND_SPL) (TEXT_BASE = 0xc000) #define CONFIG_ENABLE_MMU #endif Please check Thanks. This logic was broken. I have reworked this logic as follows, and removed the ifdef: - adr r1, mmu_disable_phys - /* We presume we're within the first 1024 bytes */ - and r1, r1, #0x3fc - ldr r2, _TEXT_PHY_BASE - ldr r3, =0xfff0 - and r2, r2, r3 - orr r2, r2, r1 + adr r2, mmu_disable_phys + sub r2, r2, #(CONFIG_SYS_PHY_UBOOT_BASE - TEXT_BASE) The earlier implementation was masking out too many bits in trying to convert the jump address from virtual to physical. Any comments on this change? [...] /* Prepare to disable the MMU */ adr r1, mmu_disable_phys /* We presume we're within the first 1024 bytes */ @@ -187,20 +189,60 @@ mmu_disable: nop nop mov pc, r2 +mmu_disable_phys: +#else +mcr p15, 0, r0, c1, c0, 0 Are the noop's above needed here? I think the original author's intent was to entirely occupy one cache line. I don't know enough about the s3c64xx architecture to comment. [...] mcr p15,0,r0,c15,c2,4 @ 256M (0x7000 - 0x7fff) This comment '@ 256 .. ' is no longer valid. Thanks. Will fix. [...] -/* move to reserved a couple spots for abort stack */ +/* reserved a couple spots for abort stack */ The old comment makes more sense. Revert this. Thanks. Will fix. [...] +#define CONFIG_SKIP_RELOCATE_UBOOT There is logic later in this file to undef this value. This is likely an error. If it isn't, add a comment. I have removed the subsequent undef and verified that the generated disassembly of start.S remains the same (with the exception of the address computation change above) for both usb and non-usb smdk6400 builds. Thanks Cyril. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi/master
Dear Stefan Roese, In message 201004281006.14834...@denx.de you wrote: The following changes since commit 3699c28e6d16b563629c285311a0ce62a2c4c5d0: Merge branch 'master' of git://git.denx.de/u-boot-video (2010-04-28 00:10:41 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-ubi.git master Stefano Babic (1): ubifsmount fails due to not initialized list fs/ubifs/super.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Applied, 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 I object to intellect without discipline; I object to power without constructive purpose. -- Spock, The Squire of Gothos, stardate 2124.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mtdparts: fix write through NULL pointer
Dear Stefano Babic, In message 4bd81816.2050...@denx.de you wrote: I have already sent a patch fixing this issue, I've seen it (unfortunately only after running into this myself). http://lists.denx.de/pipermail/u-boot/2010-April/070347.html However, I preferred (easier way) to fix the calling function as the device_parse(). I do not know if Stefan has already merged it. I tend to prefer my version, as it seems to be more defensive, and it also adds an assert() for the 3rd parameter. If you agree, I'll apply my version? 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 Don't you know anything? I should have thought anyone knows that who knows anything about anything... - Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RFC: U-Boot OneNAND IPL TEXT_BASE
Hey, I've been tinkering with OneNAND IPL in uboot. I found out it wan't to load itself to the address specified in board/$(BOARDDIR)/config.mk . That's fine in most cases, but in my case that wasn't possible. In my case, SDRAM init didn't fit into the IPL, so I had to copy U-Boot into SRAM, then execute it and let it relocate itself into SDRAM. One more time: IPL: OneNAND-SRAM U-Boot: SRAM-SDRAM It all works fine, but when compiling the IPL, I had to alter TEXT_BASE not to point into SDRAM but SRAM too (because of stack). I introduced a variable called IPL which allows using config.mk from (for example) onenand- ipl/board/$(BOARDDIR)/config.mk rather than the board/$(BOARDDIR)/config.mk one, which is in my opinion a correct behaviour. Any opinions? Thanks in advance. diff --git a/config.mk b/config.mk index 73b5195..8639580 100644 --- a/config.mk +++ b/config.mk @@ -130,9 +130,13 @@ BOARDDIR = $(VENDOR)/$(BOARD) else BOARDDIR = $(BOARD) endif +ifdef IPL +sinclude $(TOPDIR)/$(IPL)/board/$(BOARDDIR)/config.mk # include IPL specific rules +else ifdef BOARD sinclude $(TOPDIR)/board/$(BOARDDIR)/config.mk # include board specific rules endif +endif # ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] - Seeking information Re: Memory Mapped CF Card (IDE) and Linux
Dne Pá 30. dubna 2010 16:11:53 Graeme Russ napsal(a): Hi All, I'm looking for information on how to access a Compact Flash card which is memory-mapped (from 0x20001000) From what I have read, there a 3 address lines (8 addresses) which access IDE registers within the CF chip My question is, how do I access such a custom address range within Linux? I'm looking at the 'OF-platform PATA driver' which appears to be what I want (a very basic IDE driver) but I am a bit lost on how to set up a specific base address. Where should I look for examples of CF cards mapped to specific address spaces? TIA Hey, look at pata_platform.c driver. Without any additional setup, your drive will work. You just specify IRQ line (if any) and CTL and CMD addresses. Cheers Graeme ___ 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
