[U-Boot] [Patch] [Version 2] Disable/Enab le Flat I²C Commands
This is the seconded version of "Disable/Enable Flat I²C Commands" Patch. It has invert logic, that means a new define disables the flat command instaed of reenable. Since CONFIG_I2C_CMD_TREE are defined, the old flat i2c commands are still present. This patch disables the old flat command by default, if both CONFIG_I2C_CMD_TREE and CONFIG_I2C_CMD_FLAT are defined. The new option CONFIG_I2C_CMD_NO_FLAT makes it possible to dissable the flat, when tree commands are used. Signed-off-by: Jens Scharsig --- diff --git a/README b/README index 86c1304..0568352 100644 --- a/README +++ b/README @@ -1306,6 +1306,9 @@ The following options need to be configured: older 'imm', 'imd', 'iprobe' etc. commands are considered deprecated and may disappear in the future. + CONFIG_I2C_CMD_NO_FLAT enables the old flat i2c commands like + 'imm', 'imd', 'iprobe' etc. if CONFIG_I2C_CMD_TREE is defined. + CONFIG_HARD_I2C selects a hardware I2C controller. CONFIG_SOFT_I2C configures u-boot to use a software (aka diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c index 16439ac..cf99428 100644 --- a/common/cmd_i2c.c +++ b/common/cmd_i2c.c @@ -1324,6 +1324,7 @@ U_BOOT_CMD( #endif ); #endif /* CONFIG_I2C_CMD_TREE */ +#if (!defined(CONFIG_I2C_CMD_NO_FLAT) || !defined(CONFIG_I2C_CMD_TREE)) U_BOOT_CMD( imd,4, 1, do_i2c_md, \ "i2c memory display", \ @@ -1369,6 +1370,7 @@ U_BOOT_CMD( "chip address[.0, .1, .2] [# of objects]\n" "- loop, reading a set of addresses\n" ); +#endif /* CONFIG_I2C_CMD_FLAT/TREE */ #if defined(CONFIG_CMD_SDRAM) U_BOOT_CMD( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Com mands
Dear Wolfgang Denk, > Please either add the needed CONFIG_I2C_CMD_FLAT to all affected > boards so the current behaviour remains the same, or make it such > that it gets activated only for new boards. i will invert the logic of the patch and post it as version 2. The new patch disables flat commands if CONFIG_I2C_CMD_NO_FLAT defined. Best regards, Jens Scharsig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix ext2 non-working
Hello, all?
Currently ext2ls, ext2load not working (I think sometimes it will work.)
The reason is incorrect operations of ext2fs_read_inode and ext2fs_blockgroup.
I fix miscalculated block number(blkno) and offset (blkoff), and some
hard coded values.
unsik Kim
Signed-off-by: unsik Kim
---
diff --git a/Makefile b/Makefile
index d26a004..9e9ba36 100644
--- a/Makefile
+++ b/Makefile
@@ -403,6 +403,7 @@ TAG_SUBDIRS += fs/fat
TAG_SUBDIRS += fs/fdos
TAG_SUBDIRS += fs/jffs2
TAG_SUBDIRS += fs/yaffs2
+TAG_SUBDIRS += fs/ext2
TAG_SUBDIRS += net
TAG_SUBDIRS += disk
TAG_SUBDIRS += common
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index 436f4a4..4ac2bdd 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -110,6 +110,7 @@ struct ext2_block_group {
uint32_t inode_table_id;
uint16_t free_blocks;
uint16_t free_inodes;
+ uint16_t used_dir_cnt;
uint16_t pad;
uint32_t reserved[3];
};
@@ -182,14 +183,22 @@ int indir2_blkno = -1;
static int ext2fs_blockgroup
(struct ext2_data *data, int group, struct ext2_block_group *blkgrp) {
+ unsigned int blkno;
+ unsigned int blkoff;
+ unsigned int desc_per_blk;
+
+ desc_per_blk = EXT2_BLOCK_SIZE(data) / sizeof(struct ext2_block_group);
+
+ blkno = __le32_to_cpu(data->sblock.first_data_block) + 1 +
+ group / desc_per_blk;
+ blkoff = (group % desc_per_blk) * sizeof(struct ext2_block_group);
#ifdef DEBUG
- printf ("ext2fs read blockgroup\n");
+ printf ("ext2fs read %d group descriptor (blkno %d blkoff %d)\n",
+group, blkno, blkoff);
#endif
return (ext2fs_devread
- (((__le32_to_cpu (data->sblock.first_data_block) +
- 1) << LOG2_EXT2_BLOCK_SIZE (data)),
-group * sizeof (struct ext2_block_group),
-sizeof (struct ext2_block_group), (char *) blkgrp));
+ (blkno << LOG2_EXT2_BLOCK_SIZE(data),
+blkoff, sizeof(struct ext2_block_group), (char *)blkgrp));
}
@@ -203,11 +212,11 @@ static int ext2fs_read_inode
unsigned int blkno;
unsigned int blkoff;
- /* It is easier to calculate if the first inode is 0. */
- ino--;
#ifdef DEBUG
printf ("ext2fs read inode %d\n", ino);
#endif
+ /* It is easier to calculate if the first inode is 0. */
+ ino--;
status = ext2fs_blockgroup (data,
ino /
__le32_to_cpu (sblock->inodes_per_group),
@@ -215,19 +224,16 @@ static int ext2fs_read_inode
if (status == 0) {
return (0);
}
- inodes_per_block = EXT2_BLOCK_SIZE (data) / 128;
- blkno = (ino % __le32_to_cpu (sblock->inodes_per_group)) /
- inodes_per_block;
- blkoff = (ino % __le32_to_cpu (sblock->inodes_per_group)) %
- inodes_per_block;
+ inodes_per_block = EXT2_BLOCK_SIZE(data) /
__le32_to_cpu(sblock->inode_size);
+ blkno = blkgrp.inode_table_id +
+ (ino % __le32_to_cpu(sblock->inodes_per_group)) /
inodes_per_block;
+ blkoff = (ino % inodes_per_block) * __le32_to_cpu(sblock->inode_size);
#ifdef DEBUG
printf ("ext2fs read inode blkno %d blkoff %d\n", blkno, blkoff);
#endif
/* Read the inode. */
- status = ext2fs_devread (((__le32_to_cpu (blkgrp.inode_table_id) +
- blkno) << LOG2_EXT2_BLOCK_SIZE (data)),
-sizeof (struct ext2_inode) * blkoff,
-sizeof (struct ext2_inode), (char *) inode);
+ status = ext2fs_devread (blkno << LOG2_EXT2_BLOCK_SIZE (data), blkoff,
+ sizeof (struct ext2_inode), (char *) inode);
if (status == 0) {
return (0);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling POST for canyonlands board
Hi Stefan, Thanks for the reply. I looked into the file that you mentioned and also the README as well as the POST directory. I could not go into the details very minutely. From this I have understood that 1. Support for POST for canyonlands board is present. 2. To enable POST for canyonlands board, I only have to define the required macros. 3. I do not have to add / modify code to test the peripherals on the canyonlands board. Could you please let me know if I have understood it correctly? Thanks a lot. I am hard pressed for time and your suggestions are invaluable. Regards, Afzal Nadirshah -Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Thursday, January 29, 2009 9:17 PM To: u-boot@lists.denx.de Cc: Afzal Nadirshah Subject: Re: [U-Boot] Enabling POST for canyonlands board Hi Afzal, On Thursday 29 January 2009, Afzal Nadirshah wrote: >Is the Power On Self Test enabled for the canyonlands board? A quick look at the canyonlands config header shows that it's not enabled. >What I > want to know is whether I need to set any macro while compiling, to enable > POST. Yes. I suggest you take a look at the kilauea.h header. Here POST is enabled by default. > I saw that there are some hot keys defined to start POST for certain > boards. Is there anything defined like that for canyonlands board.How do I > start the POST. Some POST tests are run always after poweron, and some (longer) tests are only run under certain conditions. doc/README.POST should give you an overview here. Best regards, 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 = http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Thursday 29 January 2009 17:18:00 Wolfgang Denk wrote: > In message <200901291648.02480.vap...@gentoo.org> you wrote: > > > > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt > > > > > set already and sets bi_enetaddr in global data > > > > > - board_eth_init() calls the driver init > > > > > (bfin_EMAC_initialize() in your case) > > > > > - driver init looks up ethaddr in env or bi_enetaddr > > > > > > What is wrong with using bi_enetaddr? What sort of "handling/parsing > > > code" (in addition to a plain simple memcpy(...,6) is needed? > > > > converting the envvar to the raw 6 bytes and back again is duplicated all > > over the tree. and you suggest that both the board-specific misc_initr() > > and the driver init should handle this. > > No, I don't. I suggest that it gets done once (for example in > misc_initr()), and that you then use the binary data in bi_enetaddr. you said: - driver init looks up ethaddr in env or bi_enetaddr at any rate, i'm fine with having the driver assume bi_enetaddr is sane. so the series of patches i just posted starts unifying the things i whined about earlier and does what you suggested. unfortunately, with this small review i noticed another layer of confusion ;). every ethernet device is represented as struct eth_device, and that device has an enetaddr member. the board makes sure ethaddr is set in the environment during misc init. then when the network is actually used, the eth layer calls the board init which calls the driver init which registers a new eth_device. then the eth layer sets up dev->enetaddr based on the appropriate ethaddr env var. so imo, no eth driver should be touching the global data (and thus the bi_enetaddr's contained in there). going back a step, i dont think the board itself should be touching the global bi_enetaddr. when the board sets the ethaddr env var, the common code in cmd_nvedit.c syncs the value to the global data. if i were to document this mess, where would be the best place ? start a new doc/README.enetaddr as i dont see any document that covers the eth layer ? that way in the future we can all easily agree on how things should be done. -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] MIPS: Fix compile warning in au1x00_eth.c
Stefan Roese wrote:
>> skuri...@ubuntu:u-boot.git$ mips-linux-gnu-gcc --version
>> mips-linux-gnu-gcc (Sourcery G++ Lite 4.2-177) 4.2.3
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> skuri...@ubuntu:u-boot.git$
>> skuri...@ubuntu:u-boot.git$ CROSS_COMPILE=mips-linux-gnu- ./MAKEALL
>> dbau1000 Configuring for dbau1x00 board...
>> au1x00_eth.c: In function 'au1x00_send':
>> au1x00_eth.c:158: warning: passing argument 1 of 'virt_to_phys' discards
>> qualifiers from pointer target type au1x00_eth.c: In function
>> 'au1x00_recv':
>> au1x00_eth.c:211: warning: passing argument 1 of 'virt_to_phys' discards
>> qualifiers from pointer target type au1x00_eth.c: In function
>> 'au1x00_init':
>> au1x00_eth.c:252: warning: passing argument 1 of 'virt_to_phys' discards
>> qualifiers from pointer target type au1x00_eth.c: In function
>> 'au1x00_recv':
>> au1x00_eth.c:211: warning: passing argument 1 of 'virt_to_phys' discards
>> qualifiers from pointer target type au1x00_eth.c: In function
>> 'au1x00_init':
>> au1x00_eth.c:252: warning: passing argument 1 of 'virt_to_phys' discards
>> qualifiers from pointer target type au1x00_eth.c: In function
>> 'au1x00_send':
>> au1x00_eth.c:158: warning: passing argument 1 of 'virt_to_phys' discards
>> qualifiers from pointer target type textdata bss dec hex
>> filename
>> 1187805264 20648 144692 23534 ./u-boot
>
> Those errors occur twice. Seems that you are compiling this file twice.
> Any idea why?
Probably it's due to the GCC 4.2.x minor version difference.
Googling[1][2] and playing for a while, I finally managed to quiet the
GCC with the following patch.
diff --git a/cpu/mips/au1x00_eth.c b/cpu/mips/au1x00_eth.c
index 6272a3a..c2c76ac 100644
--- a/cpu/mips/au1x00_eth.c
+++ b/cpu/mips/au1x00_eth.c
@@ -155,7 +155,7 @@ static int au1x00_send(struct eth_device* dev, volatile
void *packet, int length
/* tx fifo should always be idle */
fifo_tx[next_tx].len = length;
- fifo_tx[next_tx].addr = (virt_to_phys(packet))|TX_DMA_ENABLE;
+ fifo_tx[next_tx].addr = (virt_to_phys((void *)(unsigned
long)packet))|TX_DMA_ENABLE;
au_sync();
udelay(1);
@@ -208,7 +208,7 @@ static int au1x00_recv(struct eth_device* dev){
NetReceive(NetRxPackets[next_rx], length - 4);
}
- fifo_rx[next_rx].addr =
(virt_to_phys(NetRxPackets[next_rx]))|RX_DMA_ENABLE;
+ fifo_rx[next_rx].addr = (virt_to_phys((void *)(unsigned
long)NetRxPackets[next_rx]))|RX_DMA_ENABLE;
next_rx++;
if(next_rx>=NO_OF_FIFOS){
@@ -249,7 +249,7 @@ static int au1x00_init(struct eth_device* dev, bd_t * bd){
for(i=0;ihttp://lists.denx.de/pipermail/u-boot/2008-December/044960.html
[PATCH 01/11] powerpc: fix io.h build warning with CONFIG_PHYS_64BIT
[2] http://lkml.org/lkml/2009/1/27/67
Interestingly, this only happens with gcc-4.2; gcc <= 4.1 and gcc-4.3 are
OK.
--
Shinya Kuribayashi
NEC Electronics
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Blackfin: bf537-stamp: rewrite MAC-in-flash handling
Use the common net eth functions to setup the env/global data with the MAC
address, and properly handle the case where CONFIG_SYS_NO_FLASH is defined.
Signed-off-by: Mike Frysinger
---
board/bf537-stamp/bf537-stamp.c | 79 +++---
include/asm-blackfin/net.h | 28 ++
2 files changed, 84 insertions(+), 23 deletions(-)
create mode 100644 include/asm-blackfin/net.h
diff --git a/board/bf537-stamp/bf537-stamp.c b/board/bf537-stamp/bf537-stamp.c
index 63992f6..49d3f46 100644
--- a/board/bf537-stamp/bf537-stamp.c
+++ b/board/bf537-stamp/bf537-stamp.c
@@ -1,7 +1,7 @@
/*
- * U-boot - BF537.c
+ * U-boot - main board file
*
- * Copyright (c) 2005-2007 Analog Devices Inc.
+ * Copyright (c) 2005-2008 Analog Devices Inc.
*
* (C) Copyright 2000-2004
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
@@ -29,7 +29,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -105,22 +105,63 @@ phys_size_t initdram(int board_type)
return gd->bd->bi_memsize;
}
+void board_reset(void)
+{
+ /* workaround for weak pull ups on ssel */
+ if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_SPI_MASTER) {
+ bfin_write_PORTF_FER(bfin_read_PORTF_FER() & ~PF10);
+ bfin_write_PORTFIO_SET(PF10);
+ udelay(1);
+ }
+}
+
+#ifdef CONFIG_BFIN_MAC
+static void board_init_enetaddr(uchar *mac_addr)
+{
+#ifdef CONFIG_SYS_NO_FLASH
+# define USE_MAC_IN_FLASH 0
+#else
+# define USE_MAC_IN_FLASH 1
+#endif
+ bool valid_mac = false;
+
+ if (USE_MAC_IN_FLASH) {
+ /* we cram the MAC in the last flash sector */
+ uchar *board_mac_addr = (uchar *)0x203F;
+ if (is_valid_ether_addr(board_mac_addr)) {
+ memcpy(mac_addr, board_mac_addr, 6);
+ valid_mac = true;
+ }
+ }
+
+ if (!valid_mac) {
+ puts("Warning: Generating 'random' MAC address\n");
+ bfin_gen_rand_mac(mac_addr);
+ }
+
+ eth_setenv_enetaddr("ethaddr", mac_addr);
+}
+
+int board_eth_init(bd_t *bis)
+{
+ return bfin_EMAC_initialize(bis);
+}
+#endif
+
#if defined(CONFIG_MISC_INIT_R)
/* miscellaneous platform dependent initialisations */
int misc_init_r(void)
{
-#if defined(CONFIG_CMD_NET)
- char nid[32];
- unsigned char *pMACaddr = (unsigned char *)0x203F;
-
- /* The 0xFF check here is to make sure we don't use the address
-* in flash if it's simply been erased (aka all 0xFF values) */
- if (getenv("ethaddr") == NULL && is_valid_ether_addr(pMACaddr)) {
- sprintf(nid, "%02x:%02x:%02x:%02x:%02x:%02x",
- pMACaddr[0], pMACaddr[1],
- pMACaddr[2], pMACaddr[3], pMACaddr[4], pMACaddr[5]);
- setenv("ethaddr", nid);
- }
+#ifndef CONFIG_SYS_NO_FLASH
+ /* we use the last sector for the MAC address / POST LDR */
+ extern flash_info_t flash_info[];
+ flash_protect(FLAG_PROTECT_SET, 0x203F, 0x203F, &flash_info[0]);
+#endif
+
+#ifdef CONFIG_BFIN_MAC
+ uchar *enetaddr = bis->bi_enetaddr;
+ if (!eth_getenv_enetaddr("ethaddr", enetaddr))
+ board_init_enetaddr(enetaddr);
#endif
#if defined(CONFIG_BFIN_IDE)
@@ -143,14 +184,6 @@ int misc_init_r(void)
}
#endif /* CONFIG_MISC_INIT_R */
-#if defined(CONFIG_BFIN_MAC)
-
-int board_eth_init(bd_t *bis)
-{
- return bfin_EMAC_initialize(bis);
-}
-#endif
-
#ifdef CONFIG_POST
/* Using sw10-PF5 as the hotkey */
int post_hotkeys_pressed(void)
diff --git a/include/asm-blackfin/net.h b/include/asm-blackfin/net.h
new file mode 100644
index 000..97cb466
--- /dev/null
+++ b/include/asm-blackfin/net.h
@@ -0,0 +1,28 @@
+/*
+ * net.h - misc Blackfin network helpers
+ *
+ * Copyright (c) 2008-2009 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef __ASM_BFIN_RAND_MAC__
+#define __ASM_BFIN_RAND_MAC__
+
+/* If the board does not have a real MAC assigned to it, then generate a
+ * locally administrated pseudo-random one based on CYCLES and compile date.
+ */
+static inline void bfin_gen_rand_mac(uchar *mac_addr)
+{
+ /* make something up */
+ const char s[] = __DATE__;
+ size_t i;
+ u32 cycles;
+ for (i = 0; i < 6; ++i) {
+ asm("%0 = CYCLES;" : "=r" (cycles));
+ mac_addr[i] = cycles ^ s[i];
+ }
+ mac_addr[0] = (mac_addr[0] | 0x02) & ~0x01; /* make it local unicast */
+}
+
+#endif
--
1.6.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/27 v3] Blackfin: bfin_mac: force boards to setup the MAC themselves
Since the on-chip MAC does not have an eeprom or similar interface, force
all Blackfin boards that use this driver to setup the board data with a
proper MAC.
Signed-off-by: Mike Frysinger
CC: Ben Warren
---
v3
- do no work -- make the boards do it themselves
v2
- drop CONFIG_ETHADDR handling
lib_blackfin/board.c | 31 ++-
1 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/lib_blackfin/board.c b/lib_blackfin/board.c
index 01b71d4..c1fa61b 100644
--- a/lib_blackfin/board.c
+++ b/lib_blackfin/board.c
@@ -378,35 +378,6 @@ void board_init_r(gd_t * id, ulong dest_addr)
/* relocate environment function pointers etc. */
env_relocate();
-#ifdef CONFIG_CMD_NET
- /* board MAC address */
- s = getenv("ethaddr");
- if (s == NULL) {
-# ifndef CONFIG_ETHADDR
-# if 0
- if (!board_get_enetaddr(bd->bi_enetaddr)) {
- char nid[20];
- sprintf(nid, "%02X:%02X:%02X:%02X:%02X:%02X",
- bd->bi_enetaddr[0], bd->bi_enetaddr[1],
- bd->bi_enetaddr[2], bd->bi_enetaddr[3],
- bd->bi_enetaddr[4], bd->bi_enetaddr[5]);
- setenv("ethaddr", nid);
- }
-# endif
-# endif
- } else {
- int i;
- char *e;
- for (i = 0; i < 6; ++i) {
- bd->bi_enetaddr[i] = simple_strtoul(s, &e, 16);
- s = (*e) ? e + 1 : e;
- }
- }
-
- /* IP Address */
- bd->bi_ip_addr = getenv_IPaddr("ipaddr");
-#endif
-
/* Initialize devices */
devices_init();
jumptable_init();
@@ -433,6 +404,8 @@ void board_init_r(gd_t * id, ulong dest_addr)
#endif
#ifdef CONFIG_CMD_NET
+ /* IP Address */
+ bd->bi_ip_addr = getenv_IPaddr("ipaddr");
printf("Net: ");
eth_initialize(gd->bd);
if (getenv("ethaddr"))
--
1.6.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc8xx_pcmcia: move CONFIG_8xx out of .c file and into Makefile
Move the CONFIG_8xx mpc8xx_pcmcia.c protection out of the C file and into the Makefile so we avoid pointless compiling of the file. Signed-off-by: Mike Frysinger --- drivers/pcmcia/Makefile|2 +- drivers/pcmcia/mpc8xx_pcmcia.c |6 ++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/pcmcia/Makefile b/drivers/pcmcia/Makefile index ba251d0..babe3ec 100644 --- a/drivers/pcmcia/Makefile +++ b/drivers/pcmcia/Makefile @@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk LIB:= $(obj)libpcmcia.a COBJS-$(CONFIG_I82365) += i82365.o -COBJS-y += mpc8xx_pcmcia.o +COBJS-$(CONFIG_8xx) += mpc8xx_pcmcia.o COBJS-$(CONFIG_PXA_PCMCIA) += pxa_pcmcia.o COBJS-y += rpx_pcmcia.o COBJS-$(CONFIG_IDE_TI_CARDBUS) += ti_pci1410a.o diff --git a/drivers/pcmcia/mpc8xx_pcmcia.c b/drivers/pcmcia/mpc8xx_pcmcia.c index 95ea5e9..7030574 100644 --- a/drivers/pcmcia/mpc8xx_pcmcia.c +++ b/drivers/pcmcia/mpc8xx_pcmcia.c @@ -1,7 +1,5 @@ #include -#if defined(CONFIG_8xx) #include -#endif #include #undef CONFIG_PCMCIA @@ -14,7 +12,7 @@ #defineCONFIG_PCMCIA #endif -#if defined(CONFIG_8xx)&& defined(CONFIG_PCMCIA) +#if defined(CONFIG_PCMCIA) #ifdefined(CONFIG_IDE_8xx_PCCARD) extern int check_ide_device (int slot); @@ -301,4 +299,4 @@ static u_int m8xx_get_speed(u_int ns, u_int is_io) } #endif /* 0 */ -#endif /* CONFIG_8xx && CONFIG_PCMCIA */ +#endif /* CONFIG_PCMCIA */ -- 1.6.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] disk: convert part_* files to COBJ-$(CONFIG_XXX) style
Move the CONFIG_XXX out of the part_XXX.c file and into Makefile to avoid pointless compiles. Signed-off-by: Mike Frysinger --- disk/Makefile | 10 +- disk/part_amiga.c | 10 +- disk/part_dos.c | 12 ++-- disk/part_efi.c | 12 ++-- disk/part_iso.c | 12 ++-- disk/part_mac.c | 12 ++-- 6 files changed, 34 insertions(+), 34 deletions(-) diff --git a/disk/Makefile b/disk/Makefile index c479145..128db77 100644 --- a/disk/Makefile +++ b/disk/Makefile @@ -28,11 +28,11 @@ include $(TOPDIR)/config.mk LIB= $(obj)libdisk.a COBJS-y += part.o -COBJS-y += part_mac.o -COBJS-y += part_dos.o -COBJS-y += part_iso.o -COBJS-y += part_amiga.o -COBJS-y += part_efi.o +COBJS-$(CONFIG_MAC_PARTITION) += part_mac.o +COBJS-$(CONFIG_DOS_PARTITION) += part_dos.o +COBJS-$(CONFIG_ISO_PARTITION) += part_iso.o +COBJS-$(CONFIG_AMIGA_PARTITION) += part_amiga.o +COBJS-$(CONFIG_EFI_PARTITION) += part_efi.o COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) diff --git a/disk/part_amiga.c b/disk/part_amiga.c index 6c3d748..c2daf6a 100644 --- a/disk/part_amiga.c +++ b/disk/part_amiga.c @@ -26,11 +26,11 @@ #include #include "part_amiga.h" -#if (defined(CONFIG_CMD_IDE) || \ - defined(CONFIG_CMD_SCSI) || \ - defined(CONFIG_CMD_USB) || \ - defined(CONFIG_MMC) || \ - defined(CONFIG_SYSTEMACE) ) && defined(CONFIG_AMIGA_PARTITION) +#if defined(CONFIG_CMD_IDE) || \ +defined(CONFIG_CMD_SCSI) || \ +defined(CONFIG_CMD_USB) || \ +defined(CONFIG_MMC) || \ +defined(CONFIG_SYSTEMACE) #undef AMIGA_DEBUG diff --git a/disk/part_dos.c b/disk/part_dos.c index 4d778ec..4ab0b40 100644 --- a/disk/part_dos.c +++ b/disk/part_dos.c @@ -35,12 +35,12 @@ #include #include "part_dos.h" -#if (defined(CONFIG_CMD_IDE) || \ - defined(CONFIG_CMD_SATA) || \ - defined(CONFIG_CMD_SCSI) || \ - defined(CONFIG_CMD_USB) || \ - defined(CONFIG_MMC) || \ - defined(CONFIG_SYSTEMACE) ) && defined(CONFIG_DOS_PARTITION) +#if defined(CONFIG_CMD_IDE) || \ +defined(CONFIG_CMD_SATA) || \ +defined(CONFIG_CMD_SCSI) || \ +defined(CONFIG_CMD_USB) || \ +defined(CONFIG_MMC) || \ +defined(CONFIG_SYSTEMACE) /* Convert char[4] in little endian format to the host format integer */ diff --git a/disk/part_efi.c b/disk/part_efi.c index d8a8111..70f62cc 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -36,12 +36,12 @@ #include #include "part_efi.h" -#if (defined(CONFIG_CMD_IDE) || \ - defined(CONFIG_CMD_SATA) || \ - defined(CONFIG_CMD_SCSI) || \ - defined(CONFIG_CMD_USB) || \ - defined(CONFIG_MMC) || \ - defined(CONFIG_SYSTEMACE) ) && defined(CONFIG_EFI_PARTITION) +#if defined(CONFIG_CMD_IDE) || \ +defined(CONFIG_CMD_SATA) || \ +defined(CONFIG_CMD_SCSI) || \ +defined(CONFIG_CMD_USB) || \ +defined(CONFIG_MMC) || \ +defined(CONFIG_SYSTEMACE) /* Convert char[2] in little endian format to the host format integer */ diff --git a/disk/part_iso.c b/disk/part_iso.c index 72ff868..719b949 100644 --- a/disk/part_iso.c +++ b/disk/part_iso.c @@ -25,12 +25,12 @@ #include #include "part_iso.h" -#if (defined(CONFIG_CMD_IDE) || \ - defined(CONFIG_CMD_SCSI) || \ - defined(CONFIG_CMD_SATA) || \ - defined(CONFIG_CMD_USB) || \ - defined(CONFIG_MMC) || \ - defined(CONFIG_SYSTEMACE) ) && defined(CONFIG_ISO_PARTITION) +#if defined(CONFIG_CMD_IDE) || \ +defined(CONFIG_CMD_SCSI) || \ +defined(CONFIG_CMD_SATA) || \ +defined(CONFIG_CMD_USB) || \ +defined(CONFIG_MMC) || \ +defined(CONFIG_SYSTEMACE) /* #define ISO_PART_DEBUG */ diff --git a/disk/part_mac.c b/disk/part_mac.c index 1922fe5..c1afc8c 100644 --- a/disk/part_mac.c +++ b/disk/part_mac.c @@ -34,12 +34,12 @@ #include #include "part_mac.h" -#if (defined(CONFIG_CMD_IDE) || \ - defined(CONFIG_CMD_SCSI) || \ - defined(CONFIG_CMD_SATA) || \ - defined(CONFIG_CMD_USB) || \ - defined(CONFIG_MMC) || \ - defined(CONFIG_SYSTEMACE) ) && defined(CONFIG_MAC_PARTITION) +#if defined(CONFIG_CMD_IDE) || \ +defined(CONFIG_CMD_SCSI) || \ +defined(CONFIG_CMD_SATA) || \ +defined(CONFIG_CMD_USB) || \ +defined(CONFIG_MMC) || \ +defined(CONFIG_SYSTEMACE) /* stdlib.h causes some compatibility problems; should fixe these! -- wd */ #ifndef __ldiv_t_defined -- 1.6.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: new utility functions eth_{parse, {get, set}env}_enetaddr()
Declare new utility functions for converting between the environment
variables (eth*addr) and the binary MAC address representation. This way
we can unify all the random places that already do this kind of thing.
Signed-off-by: Mike Frysinger
CC: Ben Warren
---
include/net.h |3 ++
net/eth.c | 76 +---
2 files changed, 48 insertions(+), 31 deletions(-)
diff --git a/include/net.h b/include/net.h
index d2d394f..23892fe 100644
--- a/include/net.h
+++ b/include/net.h
@@ -119,6 +119,9 @@ extern struct eth_device *eth_get_dev(void);/* get
the current device MAC */
extern struct eth_device *eth_get_dev_by_name(char *devname); /* get device
*/
extern int eth_get_dev_index (void); /* get the device index
*/
extern void eth_set_enetaddr(int num, char* a);/* Set new MAC address
*/
+extern void eth_parse_enetaddr(char *addr, uchar *enetaddr);
+extern bool eth_getenv_enetaddr(char *name, uchar *enetaddr);
+extern int eth_setenv_enetaddr(char *name, uchar *enetaddr);
extern int eth_init(bd_t *bis);/* Initialize the
device*/
extern int eth_send(volatile void *packet, int length); /* Send a
packet */
diff --git a/net/eth.c b/net/eth.c
index b7ef09f..cf6a678 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -127,12 +127,29 @@ int eth_register(struct eth_device* dev)
return 0;
}
+static void str_enetaddr(char *buf, uchar *enetaddr)
+{
+ sprintf(buf, "%02X:%02X:%02X:%02X:%02X:%02X\n",
+ enetaddr[0], enetaddr[1], enetaddr[2],
+ enetaddr[3], enetaddr[4], enetaddr[5]);
+}
+
+void eth_parse_enetaddr(char *addr, uchar *enetaddr)
+{
+ char *end;
+ int i;
+ for (i = 0; i < 6; ++i) {
+ enetaddr[i] = addr ? simple_strtoul(addr, &end, 16) : 0;
+ if (addr)
+ addr = (*end) ? end + 1 : end;
+ }
+}
+
int eth_initialize(bd_t *bis)
{
char enetvar[32];
unsigned char env_enetaddr[6];
- int i, eth_number = 0;
- char *tmp, *end;
+ int eth_number = 0;
eth_devices = NULL;
eth_current = NULL;
@@ -172,13 +189,7 @@ int eth_initialize(bd_t *bis)
}
sprintf(enetvar, eth_number ? "eth%daddr" : "ethaddr",
eth_number);
- tmp = getenv (enetvar);
-
- for (i=0; i<6; i++) {
- env_enetaddr[i] = tmp ? simple_strtoul(tmp,
&end, 16) : 0;
- if (tmp)
- tmp = (*end) ? end+1 : end;
- }
+ eth_parse_enetaddr(getenv(enetvar), env_enetaddr);
if (memcmp(env_enetaddr, "\0\0\0\0\0\0", 6)) {
if (memcmp(dev->enetaddr, "\0\0\0\0\0\0", 6) &&
@@ -186,16 +197,10 @@ int eth_initialize(bd_t *bis)
{
printf ("\nWarning: %s MAC addresses
don't match:\n",
dev->name);
- printf ("Address in SROM is "
-
"%02X:%02X:%02X:%02X:%02X:%02X\n",
- dev->enetaddr[0],
dev->enetaddr[1],
- dev->enetaddr[2],
dev->enetaddr[3],
- dev->enetaddr[4],
dev->enetaddr[5]);
- printf ("Address in environment is "
-
"%02X:%02X:%02X:%02X:%02X:%02X\n",
- env_enetaddr[0], env_enetaddr[1],
- env_enetaddr[2], env_enetaddr[3],
- env_enetaddr[4],
env_enetaddr[5]);
+ str_enetaddr(enetvar, dev->enetaddr);
+ printf ("Address in SROM is
%s\n", enetvar);
+ str_enetaddr(enetvar, env_enetaddr);
+ printf ("Address in environment is
%s\n", enetvar);
}
memcpy(dev->enetaddr, env_enetaddr, 6);
@@ -221,22 +226,33 @@ int eth_initialize(bd_t *bis)
return eth_number;
}
+bool eth_getenv_enetaddr(char *name, uchar *enetaddr)
+{
+ char *addr = getenv(name);
+ if (!addr)
+ return false;
+ eth_parse_enetaddr(addr, enetaddr);
+ return true;
+}
+
+int eth_setenv_enetaddr(char *name, uchar *enetaddr)
+{
+ char addr[20];
+ str_enetaddr(addr, enetaddr);
+ return setenv(name, addr);
+}
+
void eth_set_enetaddr(int num, char *addr) {
struct eth_device *dev;
Re: [U-Boot] [PATCH/RFC, 0/2] I2C rework -- what do you think?
On Thu, 29 Jan 2009, Heiko Schocher wrote: [dd] >> That means that that "i2c bus" command in nothing more than a > shortcut. It >> can be easily implemented even as U-Boot environmental variable that > one >> can >> run... > > Hmm.. so we need no i2c mux support? Yep. It can be emulated by a couple of existing commands. --- ** * k...@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger, In message <200901291648.02480.vap...@gentoo.org> you wrote: > > > > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt > > > > set already and sets bi_enetaddr in global data > > > > - board_eth_init() calls the driver init > > > > (bfin_EMAC_initialize() in your case) > > > > - driver init looks up ethaddr in env or bi_enetaddr ... > > What is wrong with using bi_enetaddr? What sort of "handling/parsing > > code" (in addition to a plain simple memcpy(...,6) is needed? > > converting the envvar to the raw 6 bytes and back again is duplicated all > over > the tree. and you suggest that both the board-specific misc_initr() and the > driver init should handle this. No, I don't. I suggest that it gets done once (for example in misc_initr()), and that you then use the binary data in bi_enetaddr. 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 PoB = "Prisoner of Bill" -- those held captive, unwillingly or other- wise, by the contemptible Microsoft monopoly. -- Tom Christiansen in <6abo45$3l...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] SX1: add hardware V2 support
In the V2 the 2 flash has been replace by one 32MB flash Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD --- include/configs/SX1.h |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/include/configs/SX1.h b/include/configs/SX1.h index 9bfefc6..78c5152 100644 --- a/include/configs/SX1.h +++ b/include/configs/SX1.h @@ -169,11 +169,15 @@ /*--- * FLASH and environment organization + * V1 + * PHYS_FLASH_SIZE_1 (16 << 10) 16 MB + * PHYS_FLASH_SIZE_2 (8 << 10)8 MB + * V2 only 1 flash + * PHYS_FLASH_SIZE_1 (32 << 10) 32 MB */ #define CONFIG_SYS_MAX_FLASH_BANKS 2 /* max number of memory banks */ -#define PHYS_FLASH_SIZE(16 << 10) /* 16 MB */ #define PHYS_FLASH_SECT_SIZE (128*1024) /* Size of a sector (128kB) */ -#define CONFIG_SYS_MAX_FLASH_SECT (128) /* max number of sectors on one chip */ +#define CONFIG_SYS_MAX_FLASH_SECT (256) /* max number of sectors on one chip */ #define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + PHYS_FLASH_SECT_SIZE) /* addr of environment */ #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE /* Monitor at beginning of flash */ #define CONFIG_SYS_MONITOR_LEN PHYS_FLASH_SECT_SIZE/* Reserve 1 sector */ -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] SX1: Fix second flash mapping
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
include/configs/SX1.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/SX1.h b/include/configs/SX1.h
index 34a5999..9bfefc6 100644
--- a/include/configs/SX1.h
+++ b/include/configs/SX1.h
@@ -177,7 +177,7 @@
#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + PHYS_FLASH_SECT_SIZE)
/* addr of environment */
#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE /* Monitor at
beginning of flash */
#define CONFIG_SYS_MONITOR_LEN PHYS_FLASH_SECT_SIZE/* Reserve 1
sector */
-#define CONFIG_SYS_FLASH_BANKS_LIST{ CONFIG_SYS_FLASH_BASE,
CONFIG_SYS_FLASH_BASE + PHYS_FLASH_SIZE }
+#define CONFIG_SYS_FLASH_BANKS_LIST{ CONFIG_SYS_FLASH_BASE, PHYS_FLASH_2 }
/*---
* FLASH driver setup
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] SX1: add CONFIG_STDOUT_USBTTY to enable preboot stdout redirect to usbtty
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD --- Makefile | 13 +++-- include/configs/SX1.h |2 ++ 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 5e7bd63..9e820c4 100644 --- a/Makefile +++ b/Makefile @@ -2820,8 +2820,17 @@ smdk2400_config : unconfig smdk2410_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 samsung s3c24x0 -SX1_config : unconfig - @$(MKCONFIG) $(@:_config=) arm arm925t sx1 +SX1_stdout_serial_config \ +SX1_config:unconfig + @mkdir -p $(obj)include + @if [ "$(findstring _stdout_serial_, $@)" ] ; then \ + echo "#undef CONFIG_STDOUT_USBTTY" >> $(obj)include/config.h ; \ + $(XECHO) "... configured for stdout serial"; \ + else \ + echo "#define CONFIG_STDOUT_USBTTY" >> $(obj)include/config.h ; \ + $(XECHO) "... configured for stdout usbtty"; \ + fi; + @$(MKCONFIG) SX1 arm arm925t sx1 # TRAB default configuration: 8 MB Flash, 32 MB RAM xtract_trab = $(subst _bigram,,$(subst _bigflash,,$(subst _old,,$(subst _config,,$1 diff --git a/include/configs/SX1.h b/include/configs/SX1.h index fd1a3bd..34a5999 100644 --- a/include/configs/SX1.h +++ b/include/configs/SX1.h @@ -116,7 +116,9 @@ #include #define CONFIG_BOOTARGS"mem=16M console=ttyS0,115200n8 root=/dev/mtdblock3 rw" +#ifdef CONFIG_STDOUT_USBTTY #define CONFIG_PREBOOT "setenv stdout usbtty;setenv stdin usbtty" +#endif /* * Miscellaneous configurable options -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SX1 update
Hi, The following patchset will update the u-boot support for the Siemens SX1 cellphone sell on the market Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] move ARM Ltd. to verdor dir
On 14:48 Thu 29 Jan , Peter Pearse wrote: > Jean-Christophe > > Thanks. > > Will help me align our new boards I'm finishing patch to move armltd board to cfi drivers send before next week I'll also update qemu support to have the flash support on it and allow us to use u-boot on it Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Thursday 29 January 2009 16:17:09 Wolfgang Denk wrote: > In message <200901291605.09474.vap...@gentoo.org> you wrote: > > > Rather: > > > > > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt > > > set already and sets bi_enetaddr in global data > > > - board_eth_init() calls the driver init > > > (bfin_EMAC_initialize() in your case) > > > - driver init looks up ethaddr in env or bi_enetaddr > > > > well this gets us into the realm of what i was trying to avoid/fix in the > > first place: duplication of the env/ethaddr handling/parsing code. i get > > What is wrong with using bi_enetaddr? What sort of "handling/parsing > code" (in addition to a plain simple memcpy(...,6) is needed? converting the envvar to the raw 6 bytes and back again is duplicated all over the tree. and you suggest that both the board-specific misc_initr() and the driver init should handle this. -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] move Samsung's board to board/samsung
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
Makefile |4 ++--
board/{ => samsung}/smdk2400/Makefile|0
board/{ => samsung}/smdk2400/config.mk |0
board/{ => samsung}/smdk2400/flash.c |0
board/{ => samsung}/smdk2400/lowlevel_init.S |0
board/{ => samsung}/smdk2400/smdk2400.c |0
board/{ => samsung}/smdk2400/u-boot.lds |0
board/{ => samsung}/smdk2410/Makefile|0
board/{ => samsung}/smdk2410/config.mk |0
board/{ => samsung}/smdk2410/flash.c |0
board/{ => samsung}/smdk2410/lowlevel_init.S |0
board/{ => samsung}/smdk2410/smdk2410.c |0
board/{ => samsung}/smdk2410/u-boot.lds |0
13 files changed, 2 insertions(+), 2 deletions(-)
rename board/{ => samsung}/smdk2400/Makefile (100%)
rename board/{ => samsung}/smdk2400/config.mk (100%)
rename board/{ => samsung}/smdk2400/flash.c (100%)
rename board/{ => samsung}/smdk2400/lowlevel_init.S (100%)
rename board/{ => samsung}/smdk2400/smdk2400.c (100%)
rename board/{ => samsung}/smdk2400/u-boot.lds (100%)
rename board/{ => samsung}/smdk2410/Makefile (100%)
rename board/{ => samsung}/smdk2410/config.mk (100%)
rename board/{ => samsung}/smdk2410/flash.c (100%)
rename board/{ => samsung}/smdk2410/lowlevel_init.S (100%)
rename board/{ => samsung}/smdk2410/smdk2410.c (100%)
rename board/{ => samsung}/smdk2410/u-boot.lds (100%)
diff --git a/Makefile b/Makefile
index 5b1e568..5e7bd63 100644
--- a/Makefile
+++ b/Makefile
@@ -2815,10 +2815,10 @@ scb9328_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t scb9328 NULL imx
smdk2400_config: unconfig
- @$(MKCONFIG) $(@:_config=) arm arm920t smdk2400 NULL s3c24x0
+ @$(MKCONFIG) $(@:_config=) arm arm920t smdk2400 samsung s3c24x0
smdk2410_config: unconfig
- @$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 NULL s3c24x0
+ @$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 samsung s3c24x0
SX1_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm925t sx1
diff --git a/board/smdk2400/Makefile b/board/samsung/smdk2400/Makefile
similarity index 100%
rename from board/smdk2400/Makefile
rename to board/samsung/smdk2400/Makefile
diff --git a/board/smdk2400/config.mk b/board/samsung/smdk2400/config.mk
similarity index 100%
rename from board/smdk2400/config.mk
rename to board/samsung/smdk2400/config.mk
diff --git a/board/smdk2400/flash.c b/board/samsung/smdk2400/flash.c
similarity index 100%
rename from board/smdk2400/flash.c
rename to board/samsung/smdk2400/flash.c
diff --git a/board/smdk2400/lowlevel_init.S
b/board/samsung/smdk2400/lowlevel_init.S
similarity index 100%
rename from board/smdk2400/lowlevel_init.S
rename to board/samsung/smdk2400/lowlevel_init.S
diff --git a/board/smdk2400/smdk2400.c b/board/samsung/smdk2400/smdk2400.c
similarity index 100%
rename from board/smdk2400/smdk2400.c
rename to board/samsung/smdk2400/smdk2400.c
diff --git a/board/smdk2400/u-boot.lds b/board/samsung/smdk2400/u-boot.lds
similarity index 100%
rename from board/smdk2400/u-boot.lds
rename to board/samsung/smdk2400/u-boot.lds
diff --git a/board/smdk2410/Makefile b/board/samsung/smdk2410/Makefile
similarity index 100%
rename from board/smdk2410/Makefile
rename to board/samsung/smdk2410/Makefile
diff --git a/board/smdk2410/config.mk b/board/samsung/smdk2410/config.mk
similarity index 100%
rename from board/smdk2410/config.mk
rename to board/samsung/smdk2410/config.mk
diff --git a/board/smdk2410/flash.c b/board/samsung/smdk2410/flash.c
similarity index 100%
rename from board/smdk2410/flash.c
rename to board/samsung/smdk2410/flash.c
diff --git a/board/smdk2410/lowlevel_init.S
b/board/samsung/smdk2410/lowlevel_init.S
similarity index 100%
rename from board/smdk2410/lowlevel_init.S
rename to board/samsung/smdk2410/lowlevel_init.S
diff --git a/board/smdk2410/smdk2410.c b/board/samsung/smdk2410/smdk2410.c
similarity index 100%
rename from board/smdk2410/smdk2410.c
rename to board/samsung/smdk2410/smdk2410.c
diff --git a/board/smdk2410/u-boot.lds b/board/samsung/smdk2410/u-boot.lds
similarity index 100%
rename from board/smdk2410/u-boot.lds
rename to board/samsung/smdk2410/u-boot.lds
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Co mmands
On Thu, 2009-01-29 at 22:15 +0100, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1233262578.19784.19.ca...@localhost.localdomain> you wrote: > > > > Its actually already on the wiki page. > > Ah, good. Sometimes I'm better than I think myself ;-) > > > I submitted the following patch to add it a new > > doc/feature-removal-schedule.txt with a similar timeframe: > > > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/48429 > > Hm... > > > It seems like it would be a good idea to add the > > doc/feature_removal.txt. Did the above mentioned patch slip through the > > cracks or do you prefer to only use the wiki for feature removals? > > Must have slipped through. Can you please repost so have it here in > current context?nks. Sure, will do shortly. I'll add the autoscr and legacy NAND deprecation/removal while I'm at it. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger, In message <200901291605.09474.vap...@gentoo.org> you wrote: > > > Rather: > > > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt > > set already and sets bi_enetaddr in global data > > - board_eth_init() calls the driver init > > (bfin_EMAC_initialize() in your case) > > - driver init looks up ethaddr in env or bi_enetaddr > > well this gets us into the realm of what i was trying to avoid/fix in the > first place: duplication of the env/ethaddr handling/parsing code. i get What is wrong with using bi_enetaddr? What sort of "handling/parsing code" (in addition to a plain simple memcpy(...,6) is needed? > tired of auditing every board/driver just to find the same simple bugs were > duplicated and/or not handled properly. I lost you here. 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 Conquest is easy. Control is not. -- Kirk, "Mirror, Mirror", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Com mands
Dear Peter Tyser, In message <1233262578.19784.19.ca...@localhost.localdomain> you wrote: > > Its actually already on the wiki page. Ah, good. Sometimes I'm better than I think myself ;-) > I submitted the following patch to add it a new > doc/feature-removal-schedule.txt with a similar timeframe: > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/48429 Hm... > It seems like it would be a good idea to add the > doc/feature_removal.txt. Did the above mentioned patch slip through the > cracks or do you prefer to only use the wiki for feature removals? Must have slipped through. Can you please repost so have it here in current context?nks. 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 If you think the problem is bad now, just wait until we've solved it. Epstein's Law ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Thursday 29 January 2009 15:41:31 Wolfgang Denk wrote: > In message <200901291525.03553.vap...@gentoo.org> you wrote: > > so how exactly are $ethaddr in the env and bi_enetaddr in the global data > > supposed to interact ? this is a mess in the current tree and i dont see > > any notes that indicate how things are supposed to be handled. and i'd > > like to make these changes once and get it right the first time ;). > > Can't you just ask some simple and easy questions for a change? ;-) > > > i see it as: > > - common net code calls board_eth_init() > > - board_eth_init() sets up ethaddr in env if it isnt set already > > - board_eth_init() calls the driver init (bfin_EMAC_initialize() in my > > case) - driver init looks up ethaddr in env and sets bi_enetaddr in > > global data - all other code uses bi_enetaddr to get the MAC address > > This doesn't work, as in the case that you don;t use any network > commands in U-Boot, board_eth_init() will not run and consequently you > don't know the MAC address so you cannot pass it to Linux either. > > Rather: > > - misc_init_r() [or similar] sets up ethaddr in env if it isnt > set already and sets bi_enetaddr in global data > - board_eth_init() calls the driver init > (bfin_EMAC_initialize() in your case) > - driver init looks up ethaddr in env or bi_enetaddr well this gets us into the realm of what i was trying to avoid/fix in the first place: duplication of the env/ethaddr handling/parsing code. i get tired of auditing every board/driver just to find the same simple bugs were duplicated and/or not handled properly. i guess i can mitigate this by making functions in include/asm-blackfin/net.h and having the boards/drivers call those. -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] Disable/Enable Flat I²C Com mands
Peter Tyser wrote: > Hi Wolfgang, > > On Thu, 2009-01-29 at 21:37 +0100, Wolfgang Denk wrote: > >> Dear Ben Warren, >> >> In message <498203bd.3000...@gmail.com> you wrote: >> >>> From README: >>> >>> >>> CONFIG_I2C_CMD_TREE is a recommended option that places >>> all I2C commands under a single 'i2c' root command. The >>> older 'imm', 'imd', 'iprobe' etc. commands are considered >>> deprecated and may disappear in the future. >>> >>> I guess this isn't explicit enough. Let's say it gets removed in the >>> release after v2009.03. >>> >> Indeed. We should add it to doc/feature_removal.txt and the wiki page. >> > > Its actually already on the wiki page. > > http://www.denx.de/wiki/U-Boot/TaskFeatureRemovalSchedule > > I submitted the following patch to add it a new > doc/feature-removal-schedule.txt with a similar timeframe: > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/48429 > > It seems like it would be a good idea to add the > doc/feature_removal.txt. Did the above mentioned patch slip through the > cracks or do you prefer to only use the wiki for feature removals? > > This is perfect. The patches without an obvious custodian sometimes take a bit longer to find a home, I guess. Anway, full ACK from me. > Best, > Peter > > regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Com mands
Wolfgang Denk wrote: > Dear Ben Warren, > > In message <498203bd.3000...@gmail.com> you wrote: > >> From README: >> >> >> CONFIG_I2C_CMD_TREE is a recommended option that places >> all I2C commands under a single 'i2c' root command. The >> older 'imm', 'imd', 'iprobe' etc. commands are considered >> deprecated and may disappear in the future. >> >> I guess this isn't explicit enough. Let's say it gets removed in the >> release after v2009.03. >> > > Indeed. We should add it to doc/feature_removal.txt and the wiki page. > > OK. I'l make it so. > Best regards, > > Wolfgang Denk > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Co mmands
Hi Wolfgang, On Thu, 2009-01-29 at 21:37 +0100, Wolfgang Denk wrote: > Dear Ben Warren, > > In message <498203bd.3000...@gmail.com> you wrote: > > > > From README: > > > > > > CONFIG_I2C_CMD_TREE is a recommended option that places > > all I2C commands under a single 'i2c' root command. The > > older 'imm', 'imd', 'iprobe' etc. commands are considered > > deprecated and may disappear in the future. > > > > I guess this isn't explicit enough. Let's say it gets removed in the > > release after v2009.03. > > Indeed. We should add it to doc/feature_removal.txt and the wiki page. Its actually already on the wiki page. http://www.denx.de/wiki/U-Boot/TaskFeatureRemovalSchedule I submitted the following patch to add it a new doc/feature-removal-schedule.txt with a similar timeframe: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/48429 It seems like it would be a good idea to add the doc/feature_removal.txt. Did the above mentioned patch slip through the cracks or do you prefer to only use the wiki for feature removals? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger, In message <200901291525.03553.vap...@gentoo.org> you wrote: > > so how exactly are $ethaddr in the env and bi_enetaddr in the global data > supposed to interact ? this is a mess in the current tree and i dont see any > notes that indicate how things are supposed to be handled. and i'd like to > make these changes once and get it right the first time ;). Can't you just ask some simple and easy questions for a change? ;-) > i see it as: > - common net code calls board_eth_init() > - board_eth_init() sets up ethaddr in env if it isnt set already > - board_eth_init() calls the driver init (bfin_EMAC_initialize() in my case) > - driver init looks up ethaddr in env and sets bi_enetaddr in global data > - all other code uses bi_enetaddr to get the MAC address This doesn't work, as in the case that you don;t use any network commands in U-Boot, board_eth_init() will not run and consequently you don't know the MAC address so you cannot pass it to Linux either. Rather: - misc_init_r() [or similar] sets up ethaddr in env if it isnt set already and sets bi_enetaddr in global data - board_eth_init() calls the driver init (bfin_EMAC_initialize() in your case) - driver init looks up ethaddr in env or bi_enetaddr 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 It's a small world, but I wouldn't want to paint it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Com mands
Dear Ben Warren, In message <498203bd.3000...@gmail.com> you wrote: > > From README: > > > CONFIG_I2C_CMD_TREE is a recommended option that places > all I2C commands under a single 'i2c' root command. The > older 'imm', 'imd', 'iprobe' etc. commands are considered > deprecated and may disappear in the future. > > I guess this isn't explicit enough. Let's say it gets removed in the > release after v2009.03. Indeed. We should add it to doc/feature_removal.txt and the wiki page. 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 universe is all a spin-off of the Big Bang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Thursday 29 January 2009 14:03:36 Wolfgang Denk wrote: > In message <200901291135.32632.vap...@gentoo.org> you wrote: > > the driver isnt really generic. it's specific to the hardware that > > exists inside of Blackfin chips. the hardware has no support at all for > > storing the > > Well, the same applies for many other Ethernet drivers as well, be it > the FEC ethernet driver for the MPC8xx, the FCC for the MPC82xx or the > TSEC for the 8xxx, etc. > > > what you propose wouldnt have been possible before, but with Ben's work > > it should be easy to move to board_eth_init(). > > So lat's do this, then, please. so how exactly are $ethaddr in the env and bi_enetaddr in the global data supposed to interact ? this is a mess in the current tree and i dont see any notes that indicate how things are supposed to be handled. and i'd like to make these changes once and get it right the first time ;). i see it as: - common net code calls board_eth_init() - board_eth_init() sets up ethaddr in env if it isnt set already - board_eth_init() calls the driver init (bfin_EMAC_initialize() in my case) - driver init looks up ethaddr in env and sets bi_enetaddr in global data - all other code uses bi_enetaddr to get the MAC address -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] Disable/Enable Flat I²C Com mands
Wolfgang Denk wrote: > Dear Ben Warren, > > In message <4981f273.2030...@gmail.com> you wrote: > >> Controversial, maybe, but why not just get rid of the flat commands? >> When I introduced the tree probably a couple of years ago, we said it >> would deprecate the flat commands and that they'd go away in a couple of >> releases. >> > > We should at least announce such a feature removal, and declare a > deadline in public. > > Best regards, > > Wolfgang Denk > > From README: CONFIG_I2C_CMD_TREE is a recommended option that places all I2C commands under a single 'i2c' root command. The older 'imm', 'imd', 'iprobe' etc. commands are considered deprecated and may disappear in the future. I guess this isn't explicit enough. Let's say it gets removed in the release after v2009.03. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Com mands
Dear Ben Warren, In message <4981f273.2030...@gmail.com> you wrote: > > Controversial, maybe, but why not just get rid of the flat commands? > When I introduced the tree probably a couple of years ago, we said it > would deprecate the flat commands and that they'd go away in a couple of > releases. We should at least announce such a feature removal, and declare a deadline in public. 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 "A great many people think they are thinking when they are merely re- arranging their prejudices." - William James ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exclude certain ns16550 functions from NAND_SPL builds
Dear Ron Madrid, In message <697520.19982...@web83507.mail.sp1.yahoo.com> you wrote: > > I understand your concern. I am not sure what other #define would work. > Are you suggesting the creation of a new #define such as #define > CONFIG_NS16550_BASIC_OPS or something like that which can be put into the > board specific config files? Yes. The name should make clear that this is a minimal configuration only, i. e. something that restricts the recular functions. 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 There's no future in time travel. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger, In message <200901291135.32632.vap...@gentoo.org> you wrote: > > the driver isnt really generic. it's specific to the hardware that exists > inside of Blackfin chips. the hardware has no support at all for storing the Well, the same applies for many other Ethernet drivers as well, be it the FEC ethernet driver for the MPC8xx, the FCC for the MPC82xx or the TSEC for the 8xxx, etc. > what you propose wouldnt have been possible before, but with Ben's work it > should be easy to move to board_eth_init(). So lat's do this, then, please. > as for generic code, i'd point out that lib_ppc/board.c is a much worse > offender in this regard ... I take this as an indication that we can learn from errors made in the past, instead of repeating them. 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 "You know, after a woman's raised a family and so on, she wants to start living her own life." "Whose life she's _been_ living, then?" - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 31/31] 83xx, kmeter1: added bootcount feature
Dear Kim Phillips, In message <20090129102814.6e267b96.kim.phill...@freescale.com> you wrote: > > you thinking is right, I just can't think of another place to put it - > and I suspect this isn't something that can be put in memory that lies > outside the IMMR. We could use any registers that are guaranteed to maintaion their current values through a core reset. Documentation usually gives little or no guarantees, though. 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 Microsoft Multimedia: You have nice graphics, sound and animations when the system crashes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Co mmands
Dear Jens Scharsig, In message you wrote: > Since CONFIG_I2C_CMD_TREE are defined, the old flat i2c commands are > still present. > This patch disables the old flat command by default, if > CONFIG_I2C_CMD_TREE is defined. > The new option CONFIG_I2C_CMD_FLAT makes it possible to use the flat > commands in addition of tree commands. I don't like that this changes the behavious of many boards without having the go form the board maintainers, actually without even noticing them in advance. Please either add the needed CONFIG_I2C_CMD_FLAT to all affected boards so the current behaviour remains the same, or make it such that it gets activated only for new boards. 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 Christianity neither morality nor religion come into contact with reality at any point." - Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Co mmands
On Thu, 2009-01-29 at 10:16 -0800, Ben Warren wrote: > Jens Scharsig wrote: > > Since CONFIG_I2C_CMD_TREE are defined, the old flat i2c commands are > > still present. > > This patch disables the old flat command by default, if > > CONFIG_I2C_CMD_TREE is defined. > > The new option CONFIG_I2C_CMD_FLAT makes it possible to use the flat > > commands in addition of tree commands. > > > > > Controversial, maybe, but why not just get rid of the flat commands? > When I introduced the tree probably a couple of years ago, we said it > would deprecate the flat commands and that they'd go away in a couple of > releases. > We discussed this a few months ago as well and came to the same conclusion as Ben. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/47755 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/48429 Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] Disable/Enable Flat I²C Com mands
Jens Scharsig wrote: > Since CONFIG_I2C_CMD_TREE are defined, the old flat i2c commands are > still present. > This patch disables the old flat command by default, if > CONFIG_I2C_CMD_TREE is defined. > The new option CONFIG_I2C_CMD_FLAT makes it possible to use the flat > commands in addition of tree commands. > > Controversial, maybe, but why not just get rid of the flat commands? When I introduced the tree probably a couple of years ago, we said it would deprecate the flat commands and that they'd go away in a couple of releases. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] AVR32: macb - Search for PHY id
Olav Morken wrote: > On Thu, Jan 29, 2009 at 09:27, Ben Warren wrote: > >> Added to net repo. >> > > Great! > Does this mean that we shouldn't include this patch and the patch for > volatile IP_t in the next version of the patch series? > > Best regards, > Olav Morken > Correct. You've done a good job of making them orthogonal to the rest of your code, so the net repo is where they belong. I'll issue a pull request after doing a bit of testing. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Wed, Jan 28, 2009 at 09:43:31PM -0800, Ben Warren wrote:
> Mike Frysinger wrote:
> > + if (ethaddr == NULL) {
> > + char nid[20];
> > + board_get_enetaddr(bd->bi_enetaddr);
> > + sprintf(nid, "%02X:%02X:%02X:%02X:%02X:%02X",
> >
> How about snprintf()
Doesn't exist in u-boot, unfortunately.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exclude certain ns16550 functions from NAND_SPL builds
--- On Thu, 1/29/09, Wolfgang Denk wrote: > From: Wolfgang Denk > Subject: Re: [U-Boot] [PATCH] Exclude certain ns16550 functions from NAND_SPL > builds > To: "Ron Madrid" > Cc: u-boot@lists.denx.de > Date: Thursday, January 29, 2009, 2:24 AM > Dear Ron Madrid, > > In message > <1233187331-20244-1-git-send-email-ron_mad...@sbcglobal.net> > you wrote: > > This patch will exclude all functions from > drivers/serial/ns16550.c from > > NAND_SPL builds with exception of NS16550_putc and > NS16550_init. This will save > > space and remove unused code from already tightly > constrained bootstrap images > > for NAND_SPL builds. > > > > Signed-off-by: Ron Madrid > > > --- > > drivers/serial/ns16550.c |5 - > > 1 files changed, 4 insertions(+), 1 deletions(-) > > This is a global file, so maybe we could use a less > specific #define > than CONFIG_NAND_SPL for this? Eventually we need this > later to boot > from device FOO, and I don't want to see this grow into > > if !defined(CONFIG_NAND_SPL) && > !defined(CONFIG_FOO) && !defined(CONFIG_BAR) > && ... I understand your concern. I am not sure what other #define would work. Are you suggesting the creation of a new #define such as #define CONFIG_NS16550_BASIC_OPS or something like that which can be put into the board specific config files? Ron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CompactFlash support
Hi, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 14:59 Thu 29 Jan , Ritesh Mehta wrote: >> Is there any support for CompactFlash in any version of u-boot ? > yes please note that CF is see as any IDE > > Best Regards, > J. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Just a few note: - adjust the timing on the bank where the compact flash is mounted - register the device like a standard ide and put insw outsw function if there aren't in u-boot. Regards MIchael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Thursday 29 January 2009 05:45:23 Wolfgang Denk wrote: > In message <1233212358-27956-1-git-send-email-vap...@gentoo.org> you wrote: > > Since the on-chip MAC does not have an eeprom or similar interface, force > > all Blackfin boards that use this to define their own > > board_get_enetaddr() function. > > I still think this belongs into board specific code, not into a > generic driver. the driver isnt really generic. it's specific to the hardware that exists inside of Blackfin chips. the hardware has no support at all for storing the MAC in eeprom or any other place. thus it forces boards to declare some method for finding the MAC since there is literally no way for the hardware itself to do it. what you propose wouldnt have been possible before, but with Ben's work it should be easy to move to board_eth_init(). as for generic code, i'd point out that lib_ppc/board.c is a much worse offender in this regard ... -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 31/31] 83xx, kmeter1: added bootcount feature
On Thu, 29 Jan 2009 10:22:06 +0100 Heiko Schocher wrote: > Hello Kim, > > Kim Phillips wrote: > > On Wed, 28 Jan 2009 10:41:02 +0100 > > Heiko Schocher wrote: > > > >> diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c > > > >> +#ifdef CONFIG_BOOTCOUNT_LIMIT > >> + > >> +#if !defined(CONFIG_BOOTCOUNT_ADDR) > >> +#define CONFIG_BOOTCOUNT_ADDR 0x11bff8 > > > > it's CONFIG_SYS and magic number, but now that I've found it, sorry, I > > can't accept this - not all 83xx have a QE and thus this MURAM. Even > > Hmm.. maybe we make this dependent on CONFIG_QE ? still, the 8323 and 8360 would need different address values...so not only CONFIG_QE. > > if they did this would require changing the device tree muram node > > property, to indicate its size has shrunk 8 bytes, right? In fact, not > > Yes, we should do this. I hope the QE drivers don't significantly drop their performance given a muram size is not a multiple of a power of 2. > > all QE's have 48Kbytes of MURAM either - the 8323 only has 16Kbytes. > > Thats why you could define it with CONFIG_BOOTCOUNT_ADDR, where > exactly this 8 bytes are. it would be nice if all 83xx had the same address though. > > Problem is, I don't know of a better place to put the > > bootcount. Ideas? > > I thought to make it as on 82xx (using parameter Ram of SCC1), because > UCC5 should be compatible to the SCC1 see 8360ERM.pdf Table 19-11 on > page 19-20. But on the 8360, after reset, the complete parameter RAM is > initialized with 0 ... so that didn't work. Other places I couldn't > found for this feature :-( you thinking is right, I just can't think of another place to put it - and I suspect this isn't something that can be put in memory that lies outside the IMMR. if you really want this, make it only for the QE based chips, and include the device tree modification. I still don't know if this should be enabled by default in the configs, however - debugging QE performance down to this change would be relatively hard to find. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling POST for canyonlands board
Hi Afzal, On Thursday 29 January 2009, Afzal Nadirshah wrote: >Is the Power On Self Test enabled for the canyonlands board? A quick look at the canyonlands config header shows that it's not enabled. >What I > want to know is whether I need to set any macro while compiling, to enable > POST. Yes. I suggest you take a look at the kilauea.h header. Here POST is enabled by default. > I saw that there are some hot keys defined to start POST for certain > boards. Is there anything defined like that for canyonlands board.How do I > start the POST. Some POST tests are run always after poweron, and some (longer) tests are only run under certain conditions. doc/README.POST should give you an overview here. Best regards, 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] no flush_cache() call at the end of do_fat_fsload?
Hi Scott, On Thursday 29 January 2009, Scott Coulter wrote: > Maybe a stupid question, but does anyone no why there is no call to > flush_cache() at the end of do_fat_fsload()? A bug perhaps? > I haven't tried it on the > latest u-boot, but I had an issue the other day where I was trying to > load a VxWorks image from a Compact Flash card on a MPC8572-based board. > The same image booted fine with tftpboot, but when I loaded the image > off of the CF card using the fatload command, the image didn't boot. I > confirmed that image was copied faithfully into DRAM. I then noticed > that the tftpload command (netboot_common) has a call to flush_cache() > after the download to memory completes, so I added the following to the > end of do_fat_fsload(): > > ... > > /* flush cache */ > flush_cache(offset, size); > > return 0; > } > > Then the image booted... Makes perfect sense. Best would be if you could send a proper patch to fix this. Thanks. Best regards, 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] include/image.h: Ease grepping of image_* functions
On Thursday 29 January 2009 03:35:40 Petri Lehtinen wrote: > Because the functions have been defined using macros, grepping for > their definitions is not possible. This patch adds the real function > names in comments. > > Signed-off-by: Petri Lehtinen Acked-by: Mike Frysinger -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] move ARM Ltd. to verdor dir
Jean-Christophe Thanks. Will help me align our new boards Regards Peter > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of > Jean-Christophe PLAGNIOL-VILLARD > Sent: 28 January 2009 23:04 > To: u-boot@lists.denx.de > Subject: [U-Boot] [PATCH 1/1] move ARM Ltd. to verdor dir > ---snip--- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] no flush_cache() call at the end of do_fat_fsload?
Hi all, Maybe a stupid question, but does anyone no why there is no call to flush_cache() at the end of do_fat_fsload()? I haven't tried it on the latest u-boot, but I had an issue the other day where I was trying to load a VxWorks image from a Compact Flash card on a MPC8572-based board. The same image booted fine with tftpboot, but when I loaded the image off of the CF card using the fatload command, the image didn't boot. I confirmed that image was copied faithfully into DRAM. I then noticed that the tftpload command (netboot_common) has a call to flush_cache() after the download to memory completes, so I added the following to the end of do_fat_fsload(): ... /* flush cache */ flush_cache(offset, size); return 0; } Then the image booted... Thanks, Scott ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CompactFlash support
On 14:59 Thu 29 Jan , Ritesh Mehta wrote: > Is there any support for CompactFlash in any version of u-boot ? yes please note that CF is see as any IDE Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CompactFlash support for AT91SAM9263 microcontroller based customised board
On 15:09 Thu 29 Jan , Ritesh Mehta wrote: > Is there any support for CompactFlash for AT91SAM9263 microcontroller based > customised board in any version of u-boot ? not in the mainline IIRC atmel have some code about it Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CompactFlash support
Is there any support for CompactFlash in any version of u-boot ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Enabling POST for canyonlands board
Hi, Is the Power On Self Test enabled for the canyonlands board? What I want to know is whether I need to set any macro while compiling, to enable POST. I saw that there are some hot keys defined to start POST for certain boards. Is there anything defined like that for canyonlands board.How do I start the POST. Thanks in advance. Regards, Afzal Nadirshah http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AT91SAM9263 Board with DM9161A
Hi, I designed a new AT91SAM9263 Board using the schematics of the Atmel AT91SAM9263-EK EVAL Board. I have a problem in the ethernet path. Running auto negotiation (Davicom DM9161A PHY) creates a connection with 100MBit/Half - Duplex. With the original Atmel Board Full duplex is possible. I tried this with U-Boot 2008/10 and Linux 2.6.24. TFTP from Host to our Board is ok, PING from Board to Host too, but not from Host to our Board. Reading back the auto-negotiation advertisment register (ANAR 0x04) shows 0x00a1, when writing 0x01c1 before. What's wrong? best regards Josef Baumann Prime Mess- und Regeltechnik Prinz-Eugen-Str. 65 94034 Passau Tel.: +49-851-41041 Fax.: +49-851-41042 web: www.prime-micro.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CompactFlash support for AT91SAM9263 microcontroller based customised board
Is there any support for CompactFlash for AT91SAM9263 microcontroller based customised board in any version of u-boot ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the digsy MTC board.
Wolfgang Denk wrote: > Dear Grzegorz Bernacki, > > In message <49816f40.3000...@semihalf.com> you wrote: [snip] * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License >>> Please don't arbitrarily reformat the code. >> I think this tab was inserted by mistake. In u-boot code there are both >> versions of license with and without this tab. Do you really want to >> leave it? > > The original form of the code has 2 spaces there, as usual after a > full stop. It seems this file has been run through "unexpand -a" (or > an equivalent command), which inserted a TAB instead of the two > spaces. This seems no problem to me, as the text still looks exactly > the same (and we same one byte of disk storage :-). Ahh, but two spaces vs. one tab have different meanings. They just happen to look the same at the moment (blithely ignoring the fact that this particular line of text isn't likely to change). IMHO, replacing the two spaces with a tab was inadvertent whitespace damage apparently due to a whitespace cleanup and should be fixed back to being two spaces in all the header files. > Your patch makes the text look different, and the change is to the > worse. > > Best regards, > > Wolfgang Denk Painting the bike shed, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] AVR32: CPU support for AT32UC3A0xxx CPUs
Olav Morken wrote: > On Mon, Jan 26, 2009 at 21:03, Wolfgang Denk wrote: > > Dear =?ISO-8859-1?Q?Gunnar_Rang=F8y?=, > > > > In message > > you wrote: > [] > >> > > >> > It would be nice if you used readable names instead of all these > >> > magic hardcoded constants. > >> > >> Each bit in the masks represents a single pin on the microcontroller. > >> The readable names would therefore become something like: > >> #define EBI_PINS_PORT0 (0x0003C000 | 0x1E00) > >> #define EBI_PINS_PORT1 (0x0010 | 0x7C00 | ...) > > > > Um, no. You didn't get it. You use magic numbers again. > > > > That should be some > > > > #define FOO_PIN_XXX 0x0003C000 > > #define FOO_PIN_YYY 0x1E00 > > #define BAR_PIN_XXX 0x0010 > > #DEFINE BAR_PIN_YYY 0x7C00 > > > > in one place and > > > > #define EBI_PINS_PORT0 (FOO_PIN_XXX | FOO_PIN_YYY) > > #define EBI_PINS_PORT1 ((BAR_PIN_XXX| BAR_PIN_YYY) > > > > elsewhere, using readable names for the defines. > > Sorry, but the bitwise or's in the code are a bit misleading. The only > function of them is to make it more readable in the presence of the > datasheet for the microcontroller. Each single bit in the bitmask is > one pin on the microcontroller. In this case, it would become something > like: > #define EBI_PIN_NCS0(1<<14) > #define EBI_PIN_ADDR20 (1<<15) > #define EBI_PIN_ADDR21 (1<<16) > #define EBI_PIN_ADDR22 (1<<17) > () > #define EBI_PINS_PORT0 (EBI_PIN_NCS0 | EBI_PIN_ADDR20 | EBI_PIN_ADDR21 \ > | EBI_PIN_ADDR22 | ()) I don't think that would be much of an improvement. It would make the code much larger, and the pin definitions themselves would still need some magic number...and you'll need to know which GPIO port they belong to in order to actually use them. > >> I'm not certain that that would make it much more readable. The > >> bitmasks are more or less based on reading the datasheet and counting > >> which pins are used. > > > > This is exactly what should NOT be necessary to read and understand > > the code. > > [] > > But in this case, this is code which should never be changed without > looking at the datasheet, and probably schematics for the board in > question. Exactly. At some point, you need code which encapsulates the definitions in the data sheet, and that's the whole purpose of these functions. > > This is simply not acceptable. > > > >> Maybe adding a comment before the code would be just as useful? > > > > No, a comment can't fix this, especially as you just have to wait a > > few months to see the comment and the code getting out of sync. > > > > Please fix the code. > > How about something like this: > /* > * These bitmasks represents the pins used by the EBI on this board. > * Please refer to the datasheet for the UC3A-series microcontrollers > * for a description of the individual pins. > */ > #define EBI_PINS_PORT0 0x1E03C000 > #define EBI_PINS_PORT1 0xE0037C10 > () > > And in the portmux-configuration-function: > portmux_select_peripheral(PORTMUX_PORT(0), EBI_PINS_PORT0, > PORTMUX_FUNC_C, 0); > () > > When looking at this code I can see that we need a way for each > individual board to change the bitmasks, since the same pin in some > cases can be routed out to several places (depending on the board). > Maybe a CONFIG_UC3A0xxx_EBI_PINS_PORT0 option or something like that > could be added... I think you need to actually use the parameters passed to that function in order to set up the correct address, data and chip select lines. Now, the alternative mappings for some of the pins are tricky...but you could perhaps add a few more flags to cover those possibilities... Once you do that, the whole function becomes a matter of shifting bits into position, and I very much doubt a bunch of defines can make that sort of code any clearer. Think of this function as the executable equivalent of a pin definition. > >> As most of the needed functionality is embedded in the microcontroller, > >> there are very few external peripherals used by U-Boot. Apart from > >> external memory, and oscillator, and level-shifters for the serial-port, > >> there is only the ethernet PHY, and that one shouldn't need a reset. > > > > Famous last words. What if exactrly the PHY is stuck and needs a > > reset? > > The only reset we can do on the PHY is a software reset, by sending a > reset command over the (R)MII bus, and I don't believe that the generic > chip code is the place to do that. If it should be done, I believe it > should be done by the macb-driver after the reset. This would allow it > to recover even if the microcontroller wasn't reset by the > reset-command, but for example by a watchdog timer. I suppose this might be a good idea. But I haven't heard of any problems with other boards because of this...and wasn't there a generic PHY layer in the works anyway? > > Hmmm... "apart from external memory" ... does externam memory also > >
[U-Boot] [Patch] Disable/Enable Flat I²C Co mmands
Since CONFIG_I2C_CMD_TREE are defined, the old flat i2c commands are still present. This patch disables the old flat command by default, if CONFIG_I2C_CMD_TREE is defined. The new option CONFIG_I2C_CMD_FLAT makes it possible to use the flat commands in addition of tree commands. Signed-off-by: Jens Scharsig --- diff --git a/README b/README index 86c1304..3ad6d34 100644 --- a/README +++ b/README @@ -1306,6 +1306,9 @@ The following options need to be configured: older 'imm', 'imd', 'iprobe' etc. commands are considered deprecated and may disappear in the future. + CONFIG_I2C_CMD_FLAT enable the old flat i2c commands like + 'imm', 'imd', 'iprobe' etc. if CONFIG_I2C_CMD_TREE is defined. + CONFIG_HARD_I2C selects a hardware I2C controller. CONFIG_SOFT_I2C configures u-boot to use a software (aka diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c index 16439ac..5fec13c 100644 --- a/common/cmd_i2c.c +++ b/common/cmd_i2c.c @@ -1324,6 +1324,7 @@ U_BOOT_CMD( #endif ); #endif /* CONFIG_I2C_CMD_TREE */ +#if (defined(CONFIG_I2C_CMD_FLAT) || !defined(CONFIG_I2C_CMD_TREE)) U_BOOT_CMD( imd,4, 1, do_i2c_md, \ "i2c memory display", \ @@ -1369,6 +1370,7 @@ U_BOOT_CMD( "chip address[.0, .1, .2] [# of objects]\n" "- loop, reading a set of addresses\n" ); +#endif /* CONFIG_I2C_CMD_FLAT/TREE */ #if defined(CONFIG_CMD_SDRAM) U_BOOT_CMD( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] AVR32: macb - Search for PHY id
On Thu, Jan 29, 2009 at 09:27, Ben Warren wrote: > Added to net repo. Great! Does this mean that we shouldn't include this patch and the patch for volatile IP_t in the next version of the patch series? Best regards, Olav Morken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] AVR32: CPU support for AT32UC3A0xxx CPUs
On Mon, Jan 26, 2009 at 21:03, Wolfgang Denk wrote: > Dear =?ISO-8859-1?Q?Gunnar_Rang=F8y?=, > > In message you > wrote: [] >> > >> > It would be nice if you used readable names instead of all these >> > magic hardcoded constants. >> >> Each bit in the masks represents a single pin on the microcontroller. >> The readable names would therefore become something like: >> #define EBI_PINS_PORT0 (0x0003C000 | 0x1E00) >> #define EBI_PINS_PORT1 (0x0010 | 0x7C00 | ...) > > Um, no. You didn't get it. You use magic numbers again. > > That should be some > > #define FOO_PIN_XXX 0x0003C000 > #define FOO_PIN_YYY 0x1E00 > #define BAR_PIN_XXX 0x0010 > #DEFINE BAR_PIN_YYY 0x7C00 > > in one place and > > #define EBI_PINS_PORT0 (FOO_PIN_XXX | FOO_PIN_YYY) > #define EBI_PINS_PORT1 ((BAR_PIN_XXX| BAR_PIN_YYY) > > elsewhere, using readable names for the defines. Sorry, but the bitwise or's in the code are a bit misleading. The only function of them is to make it more readable in the presence of the datasheet for the microcontroller. Each single bit in the bitmask is one pin on the microcontroller. In this case, it would become something like: #define EBI_PIN_NCS0(1<<14) #define EBI_PIN_ADDR20 (1<<15) #define EBI_PIN_ADDR21 (1<<16) #define EBI_PIN_ADDR22 (1<<17) () #define EBI_PINS_PORT0 (EBI_PIN_NCS0 | EBI_PIN_ADDR20 | EBI_PIN_ADDR21 \ | EBI_PIN_ADDR22 | ()) >> I'm not certain that that would make it much more readable. The >> bitmasks are more or less based on reading the datasheet and counting >> which pins are used. > > This is exactly what should NOT be necessary to read and understand > the code. [] But in this case, this is code which should never be changed without looking at the datasheet, and probably schematics for the board in question. > This is simply not acceptable. > >> Maybe adding a comment before the code would be just as useful? > > No, a comment can't fix this, especially as you just have to wait a > few months to see the comment and the code getting out of sync. > > Please fix the code. How about something like this: /* * These bitmasks represents the pins used by the EBI on this board. * Please refer to the datasheet for the UC3A-series microcontrollers * for a description of the individual pins. */ #define EBI_PINS_PORT0 0x1E03C000 #define EBI_PINS_PORT1 0xE0037C10 () And in the portmux-configuration-function: portmux_select_peripheral(PORTMUX_PORT(0), EBI_PINS_PORT0, PORTMUX_FUNC_C, 0); () When looking at this code I can see that we need a way for each individual board to change the bitmasks, since the same pin in some cases can be routed out to several places (depending on the board). Maybe a CONFIG_UC3A0xxx_EBI_PINS_PORT0 option or something like that could be added... >> > Instead of using offsets everywhere I would appreciate if the code >> > could be changed to use C structs instead (like we do in PPC land). >> >> It was done like this because it was done in the existing AVR32 code >> which we based our work on. Since we used parts of that code, it made >> most sense to use the same coding style. >> >> We can change it if you think it is necessary. > > Yes, please change it. And patches to fix the existing code that doe > sthis are welcome, too. OK, will do this. I do however think that we will leave the code for other chips and boards as it is, since changing it would require very much time, and we don't have any way to test the changes in any case. Do you have any specific files we could use as a style-guide for such structs? >> As most of the needed functionality is embedded in the microcontroller, >> there are very few external peripherals used by U-Boot. Apart from >> external memory, and oscillator, and level-shifters for the serial-port, >> there is only the ethernet PHY, and that one shouldn't need a reset. > > Famous last words. What if exactrly the PHY is stuck and needs a > reset? The only reset we can do on the PHY is a software reset, by sending a reset command over the (R)MII bus, and I don't believe that the generic chip code is the place to do that. If it should be done, I believe it should be done by the macb-driver after the reset. This would allow it to recover even if the microcontroller wasn't reset by the reset-command, but for example by a watchdog timer. > Hmmm... "apart from external memory" ... does externam memory also > include NOR flash? Eventually the NOR flash you are booting from? > Assume the NOR flash is in query mode when you reset the board - how > does it get reset, then? External memory in this case would be SRAM or SDRAM. Best regards, Olav Morken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the digsy MTC board.
Wolfgang Denk wrote: > Dear Grzegorz Bernacki, > > In message <49816f40.3000...@semihalf.com> you wrote: >>> General comment: there is a lot of code which could use a few comments >>> so the reader has a chance to understand what exactly you are doing. >>> >> Could you point me out which parts of code except eeprom defines needs >> more comments? > > Hm... ther eare longish code sequences without a single line of > comment what you are doing, or why. > I looked over the code again and still don't find the place with long code sequence without any line of comment (except eeprom defines which I'm going to comment). Could you be more specific about where I should add the comments? regards, Grzesiek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
Dear Mark Jackson, In message <49817e75.7060...@mimc.co.uk> you wrote: > >> + bmap += (padded_line - width) * 2; > >> + fb -= (width * 2 + lcd_line_length); > > > > Is it intentional that you reverse padded_line and width here, i.e. > > you are sure it's not > > > > bmap += (width - padded_line) * 2; > > ? > > The "bmap += ..." line is to step forward to the start of the next line of > bmp > data, taking into account any padding bytes. > > If I read the code correct, padded_line is defined as ... > > padded_line = (width&0x3) ? ((width&~0x3)+4) : (width); > > ... so it will always be >= width. Correct ? > > If so, then ... > > bmap += (width - padded_line) * 2; > > ... will be <= 0, and so will actually step bmap back into the data you've > just used, whereas ... > > bmap += (padded_line - width) * 2; > > ... will be >= 0, and will step forward to the start of the next line as > required. > > Or have I misunderstood the bmp format and the existing code ? I don't know - I'm just asking because the 16 bpp case is different from the 1 and 8 bpp cases where the operands are swapped. 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 Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the digsy MTC board.
Dear Grzegorz Bernacki, In message <49816f40.3000...@semihalf.com> you wrote: > > > General comment: there is a lot of code which could use a few comments > > so the reader has a chance to understand what exactly you are doing. > > > > Could you point me out which parts of code except eeprom defines needs > more comments? Hm... ther eare longish code sequences without a single line of comment what you are doing, or why. > >> * This program is distributed in the hope that it will be useful, > >> * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> * GNU General Public License for more details. > >> * > >> * You should have received a copy of the GNU General Public License > > > > Please don't arbitrarily reformat the code. > > I think this tab was inserted by mistake. In u-boot code there are both > versions of license with and without this tab. Do you really want to > leave it? The original form of the code has 2 spaces there, as usual after a full stop. It seems this file has been run through "unexpand -a" (or an equivalent command), which inserted a TAB instead of the two spaces. This seems no problem to me, as the text still looks exactly the same (and we same one byte of disk storage :-). Your patch makes the text look different, and the change is to the worse. 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 light at the end of the tunnel is usually a "No Exit" sign. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Establishing connection via Ethernet
Dear Piyush Shah, In message you wrote: > > Is it feasible to send u-boot commands via Ethernet instead of UART? yes it it. > I know that there is no such support right now. But can it be added? You are wrong. The support is right there, and has been there for a long, long time. > Moreover how am I supposed to transmit UDP or TCP packets from u-boot? UDP only. There is no TCP capable stack in U-Boot. 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 "An organization dries up if you don't challenge it with growth." - Mark Shepherd, former President and CEO of Texas Instruments ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger, In message <1233212358-27956-1-git-send-email-vap...@gentoo.org> you wrote: > Since the on-chip MAC does not have an eeprom or similar interface, force > all Blackfin boards that use this to define their own board_get_enetaddr() > function. I still think this belongs into board specific code, not into a generic driver. The driver should be able to rely on environment settings - or bail out. 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 O Staat! Wie tief dir alle Besten fluchen! Du bist kein Ziel. Der Mensch muß weiter suchen. - Christian Morgenstern ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger, In message <200901290116.59104.vap...@gentoo.org> you wrote: > > if that's the case, shouldnt we at least mark the README as "these options > are > discouraged / deprecated" ? Maybe discouraged and deprecated are not really optimal terms here, but what is? Fact is, that ther eare very few legitimate uses of CONFIG_ETHADDR, but then these uses *are* legitimate (but then this is strictly board-specific code, definitely not in any global files). We currently handle this through code reviews - if you use CONFIG_ETHADDR, we ask you why. In your case, it seems CONFIG_ETHADDR should not be used at all. 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 There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] IP_t should be a "packed" struct
> Now study the data structures used for netwrking - they are all
> carefully crafted that the natural aligment "just fits", i. e. there
> are no gaps between variables if they are aligned naturally.
Actually, a packed structure not only doesn't have gaps, but can live
at any address. So the compiler must access it byte-by-byte
regardless. This means that a naturally-aligned structure performs
much worse if declared as packed. And single-word loads and stores are
not atomic any more.
I tried with eldk-4.2 for arm and an older gcc for mips, I have
no ppc or other archs handy right now:
#include
#include
#ifdef PACKEDTEST
# define P __attribute__ ((packed))
#else
# define P
#endif
struct {uint32_t i; uint16_t s; uint8_t c, d;} P datum;
uint32_t i;
uint16_t s;
uint8_t c;
int main(int argc, char **argv)
{
printf("ih\n");
i = datum.i;
printf("oh\n");
s = datum.s;
printf("ah\n");
c = datum.c;
return 0;
}
Compilation: ARM non-packed (only interesting lines):
8378: e5942000ldr r2, [r4]
8384: e5832000str r2, [r3]
838c: e1d420b4ldrhr2, [r4, #4]
8398: e1c320b0strhr2, [r3]
83a0: e5d42006ldrbr2, [r4, #6]
83ac: e5c32000strbr2, [r3]
Compilation: ARM packed (only interesting lines):
8378: e5d42001ldrbr2, [r4, #1]
837c: e5d43000ldrbr3, [r4]
8380: e5d40002ldrbr0, [r4, #2]
8384: e5d41003ldrbr1, [r4, #3]
8388: e1833402orr r3, r3, r2, lsl #8
838c: e1833800orr r3, r3, r0, lsl #16
8394: e1833c01orr r3, r3, r1, lsl #24
8398: e5823000str r3, [r2]
83a4: e5d43005ldrbr3, [r4, #5]
83a8: e5d42004ldrbr2, [r4, #4]
83b0: e1822403orr r2, r2, r3, lsl #8
83b8: e1c320b0strhr2, [r3]
83c0: e5d42006ldrbr2, [r4, #6]
83cc: e5c32000strbr2, [r3]
Compilation: MIPS non-packed (only interesting lines):
44: 8e03lw v1,0(s0)
5c: ac23sw v1,0(at)
74: 96030004lhu v1,4(s0)
8c: a423sh v1,0(at)
a4: 92030006lbu v1,6(s0)
bc: a023sb v1,0(at)
Compilation: MIPS packed (only interesting lines):
44: 8a030003lwl v1,3(s0)
48: 9a03lwr v1,0(s0)
60: ac23sw v1,0(at)
78: 92030005lbu v1,5(s0)
7c: 92020004lbu v0,4(s0)
80: 00031a00sll v1,v1,0x8
84: 00621825or v1,v1,v0
9c: a423sh v1,0(at)
b4: 92030006lbu v1,6(s0)
cc: a023sb v1,0(at)
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] jedec_flash: Only use manufacturer defines from common flash.h
This patch removes the double defined manufacturer defines from
jedec_flash.c. Since the common defines in flash.h are 32bit
we now need the (16) cast. This patch also removes the compilation
warning (e.g. seen on hcu5):
./MAKEALL hcu5
Configuring for hcu5 board...
jedec_flash.c:219: warning: large integer implicitly truncated to unsigned type
Signed-off-by: Stefan Roese
---
This patch replaces the patch "[PATCH] jedec_flash: Fix compilation warning in
jedec_flash.c" sent on 2009-01-26.
drivers/mtd/jedec_flash.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 2d99d4d..e48acec 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -37,10 +37,6 @@
#define P_ID_AMD_STD CFI_CMDSET_AMD_LEGACY
-/* Manufacturers */
-#define MANUFACTURER_AMD 0x0001
-#define MANUFACTURER_SST 0x00BF
-
/* AMD */
#define AM29DL800BB0x22CB
#define AM29DL800BT0x224A
@@ -172,7 +168,7 @@ struct amd_flash_info {
static const struct amd_flash_info jedec_table[] = {
#ifdef CONFIG_SYS_FLASH_LEGACY_256Kx8
{
- .mfr_id = MANUFACTURER_SST,
+ .mfr_id = (u16)SST_MANUFACT,
.dev_id = SST39LF020,
.name = "SST 39LF020",
.uaddr = {
@@ -188,7 +184,7 @@ static const struct amd_flash_info jedec_table[] = {
#endif
#ifdef CONFIG_SYS_FLASH_LEGACY_512Kx8
{
- .mfr_id = MANUFACTURER_AMD,
+ .mfr_id = (u16)AMD_MANUFACT,
.dev_id = AM29LV040B,
.name = "AMD AM29LV040B",
.uaddr = {
@@ -202,7 +198,7 @@ static const struct amd_flash_info jedec_table[] = {
}
},
{
- .mfr_id = MANUFACTURER_SST,
+ .mfr_id = (u16)SST_MANUFACT,
.dev_id = SST39LF040,
.name = "SST 39LF040",
.uaddr = {
@@ -216,7 +212,7 @@ static const struct amd_flash_info jedec_table[] = {
}
},
{
- .mfr_id = STM_MANUFACT,
+ .mfr_id = (u16)STM_MANUFACT,
.dev_id = STM_ID_M29W040B,
.name = "ST Micro M29W040B",
.uaddr = {
@@ -232,7 +228,7 @@ static const struct amd_flash_info jedec_table[] = {
#endif
#ifdef CONFIG_SYS_FLASH_LEGACY_512Kx16
{
- .mfr_id = MANUFACTURER_AMD,
+ .mfr_id = (u16)AMD_MANUFACT,
.dev_id = AM29LV400BB,
.name = "AMD AM29LV400BB",
.uaddr = {
@@ -249,7 +245,7 @@ static const struct amd_flash_info jedec_table[] = {
}
},
{
- .mfr_id = MANUFACTURER_AMD,
+ .mfr_id = (u16)AMD_MANUFACT,
.dev_id = AM29LV800BB,
.name = "AMD AM29LV800BB",
.uaddr = {
--
1.6.1.1.230.gdfb04
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger,
In message <1233187416-22378-2-git-send-email-vap...@gentoo.org> you wrote:
> Since the on-chip MAC does not have an eeprom or similar interface, force
> all Blackfin boards that use this to define their own board_get_enetaddr()
> function.
This patch makes littel sense to me.
> + const char *ethaddr;
> struct eth_device *dev;
> dev = (struct eth_device *)malloc(sizeof(*dev));
> if (dev == NULL)
> @@ -89,6 +90,27 @@ int bfin_EMAC_initialize(bd_t *bis)
>
> eth_register(dev);
>
> + ethaddr = getenv("ethaddr");
> +#ifndef CONFIG_ETHADDR
> + if (ethaddr == NULL) {
> + char nid[20];
> + board_get_enetaddr(bd->bi_enetaddr);
> + sprintf(nid, "%02X:%02X:%02X:%02X:%02X:%02X",
> + bd->bi_enetaddr[0], bd->bi_enetaddr[1],
> + bd->bi_enetaddr[2], bd->bi_enetaddr[3],
> + bd->bi_enetaddr[4], bd->bi_enetaddr[5]);
> + setenv("ethaddr", nid);
> + } else
> +#endif
Why don't you simply do the setenv("ethaddr",...) in some board init
code, like other boards do?
> + {
> + int i;
> + char *e;
> + for (i = 0; i < 6; ++i) {
> + bd->bi_enetaddr[i] = simple_strtoul(ethaddr, &e, 16);
> + ethaddr = (*e) ? e + 1 : e;
> + }
> + }
Please no nested blocks without real need.
> diff --git a/include/common.h b/include/common.h
> index afee188..d4c361a 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -354,7 +354,7 @@ void board_ether_init (void);
> #if defined(CONFIG_RPXCLASSIC) || defined(CONFIG_MBX) || \
> defined(CONFIG_IAD210) || defined(CONFIG_XPEDITE1K) || \
> defined(CONFIG_METROBOX)|| defined(CONFIG_KAREF) || \
> -defined(CONFIG_V38B)
> +defined(CONFIG_V38B)|| defined(CONFIG_BFIN_MAC)
Please keep lists sorted.
> --- a/lib_blackfin/board.c
> +++ b/lib_blackfin/board.c
> @@ -378,35 +378,6 @@ void board_init_r(gd_t * id, ulong dest_addr)
> /* relocate environment function pointers etc. */
> env_relocate();
>
> -#ifdef CONFIG_CMD_NET
> - /* board MAC address */
> - s = getenv("ethaddr");
> - if (s == NULL) {
> -# ifndef CONFIG_ETHADDR
> -# if 0
> - if (!board_get_enetaddr(bd->bi_enetaddr)) {
> - char nid[20];
> - sprintf(nid, "%02X:%02X:%02X:%02X:%02X:%02X",
> - bd->bi_enetaddr[0], bd->bi_enetaddr[1],
> - bd->bi_enetaddr[2], bd->bi_enetaddr[3],
> - bd->bi_enetaddr[4], bd->bi_enetaddr[5]);
> - setenv("ethaddr", nid);
> - }
> -# endif
> -# endif
> - } else {
> - int i;
> - char *e;
> - for (i = 0; i < 6; ++i) {
> - bd->bi_enetaddr[i] = simple_strtoul(s, &e, 16);
> - s = (*e) ? e + 1 : e;
> - }
> - }
> -
> - /* IP Address */
> - bd->bi_ip_addr = getenv_IPaddr("ipaddr");
> -#endif
To me this seems to be a better place for the code (which needs
fixing, of course).
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 really hate this damned machine It never does quite what I want
I wish that they would sell it. But only what I tell it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exclude certain ns16550 functions from NAND_SPL builds
Dear Ron Madrid, In message <1233187331-20244-1-git-send-email-ron_mad...@sbcglobal.net> you wrote: > This patch will exclude all functions from drivers/serial/ns16550.c from > NAND_SPL builds with exception of NS16550_putc and NS16550_init. This will > save > space and remove unused code from already tightly constrained bootstrap images > for NAND_SPL builds. > > Signed-off-by: Ron Madrid > --- > drivers/serial/ns16550.c |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) This is a global file, so maybe we could use a less specific #define than CONFIG_NAND_SPL for this? Eventually we need this later to boot from device FOO, and I don't want to see this grow into if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_FOO) && !defined(CONFIG_BAR) && ... 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 People with narrow minds usually have broad tongues. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] move ARM Ltd. to verdor dir
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <1233183851-11044-1-git-send-email-plagn...@jcrosoft.com> you wrote: > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Please fix type (s/verdor/vendor/) in subject before applying. 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 "To IBM, 'open' means there is a modicum of interoperability among some of their equipment."- Harv Masterson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] IP_t should be a "packed" struct
Dear Luigi Mantellini,
In message you
wrote:
>
> > We (i. e. all of us except you) do not have a problem.
>
> my question is: how can you be sure on this? I haven't used strange
Because I read the documentation?
> compilers or strange CFLAGS.. I just do "make" on a supported target
> (qemu_mips).
> I haven't any problem to correct my local source tree. I ask myself
> why gcc offers a packed atribute, ms-vc offers pragma packed, ...
There are cases where it makes a difference. Assume someting like
this:
struct foo {/* offset normalpacked */
longl; /* 0 0 */
charc; /* 4 4 */
longx; /* 8 5 */
};
Here the alignment requirements are 4 byte for "l", 1 byte for "c",
and 4 byte for "x". The compiler will align all variables on 4 byte
addresses normaly, i. e. the offsets are 0, 4 and 8. With ""packed",
the natural alignment of "x" on a 4 byte border will be ignored, and
instead it will be "packed" immediately following the storage for the
"c" variable, i. e. resulting in offset 5. This may easily cause
problems on some architectures, but that's what you get when you ask
for it.
Now study the data structures used for netwrking - they are all
carefully crafted that the natural aligment "just fits", i. e. there
are no gaps between variables if they are aligned naturally.
Your compiler must be doing really stupid things here.
> the behavior is clear: in my environment, the default choice is to
> align fields on 32bit for speed reasons... and I like this by default
> for my applications.
What makes you think it would be faster if a 16 bit ("short") data
type was no aligned on a 32 bit border, but only on a 16 bit one?
I am not aware of a system where that would make any speed difference.
Same for 8 bit (char) data types - for these, alignment at 32 bit
offsets makes zero sense to me.
> I can ignore the problem using options like -Os (I will try tomorrow)
> or -fpack-struct or other global mechanisms or, pay attention on
> structures definitions to be sure that the structure size is compiler
> and cflags independent.
The currentcode has no such problems, standard conforming compilers
assumed.
> I see. I would like to understand why this structure is
> optimization-prof. I will study tomorrow...
Please read the docs.
> iso C doensn't require packing by default of the structures. To assume
We are not talking about "packing" here. We are just talking about
alignment and insertion of gaps to ensure natural alignment of data
types. This is a well documented area.
> that a structure is packed by default is not a good assumption. All
This is NOT packing! Please do not mix unrelated terms.
> which documentation should I read? iso c documents? gcc manuals? I
ISO C or GCC, whatever is more handy.
> Anyway, I don't want to talk about philosophy. I just noticed an
> anomaly and I wanted to share with the ML.
Sorry, but there is no anomaly. This is normal, (mostly) standard
conforming C code.
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
"When anyone says `theoretically,' they really mean `not really.'"
- David Parnas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] AVR32: macb - Disable 100mbps if clock is slow
Olav Morken wrote: > > Yes, AP7000 have two Ethernet MACs. And if I got this right you want to > > make a generic config about it, so then I guess it should open up for > > having more than one MAC. > > OK, how about adding a CONFIG_MACB_ADVERTISE(id)-option, where id is > the id of the MACB (passed to the macb_eth_initialize-function). This > makes it possible to add this without touching anything but the > macb-driver (i.e. without changing the macb_eth_initialize-prototype). > > In the config-files, one could then have: > #define CONFIG_MACB_ADVERTISE(id) ( \ > (id == 0) ? ( \ > ADVERTISE_ALL | ADVERTISE_CSMA \ > ) : ( \ > ADVERTISE_CSMA | ADVERTISE_10HALF | \ > ADVERTISE_10FULL\ > )) > > Or in the simple (and probably mose usual case (only one set of options > advertised): > #define CONFIG_MACB_ADVERTISE(id) ( \ > (ADVERTISE_CSMA | ADVERTISE_10HALF | ADVERTISE_10FULL) > > > This would require saving the id to the macb_device struct. If this is > unacceptable, it could be changed to using the regs-offset instead of > the id. > > Any thoughts about this? Sounds good to me. The board decides the id, so it makes sense to pass it back to the board code. Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] AVR32: macb - Disable 100mbps if clock is slow
On Thu, Jan 29, 2009 at 07:28, Hans-Christian Egtvedt wrote: > On Wed, 28 Jan 2009 15:40:49 -0800 > Ben Warren wrote: > >> Jean-Christophe PLAGNIOL-VILLARD wrote: >> > On 22:42 Wed 28 Jan , Haavard Skinnemoen wrote: >> > > > > >> >> As for a better name, how about CONFIG_MACB_ADVERTISE? >> >> >> > why not >> > >> I like it too. One of the common checkbox items, though: do any >> Atmel chips have more than one MACB, in which case this should be >> CONFIG_MACBx_ADVERTISE or something like that? >> > > Yes, AP7000 have two Ethernet MACs. And if I got this right you want to > make a generic config about it, so then I guess it should open up for > having more than one MAC. OK, how about adding a CONFIG_MACB_ADVERTISE(id)-option, where id is the id of the MACB (passed to the macb_eth_initialize-function). This makes it possible to add this without touching anything but the macb-driver (i.e. without changing the macb_eth_initialize-prototype). In the config-files, one could then have: #define CONFIG_MACB_ADVERTISE(id) ( \ (id == 0) ? ( \ ADVERTISE_ALL | ADVERTISE_CSMA \ ) : ( \ ADVERTISE_CSMA | ADVERTISE_10HALF | \ ADVERTISE_10FULL\ )) Or in the simple (and probably mose usual case (only one set of options advertised): #define CONFIG_MACB_ADVERTISE(id) ( \ (ADVERTISE_CSMA | ADVERTISE_10HALF | ADVERTISE_10FULL) This would require saving the id to the macb_device struct. If this is unacceptable, it could be changed to using the regs-offset instead of the id. Any thoughts about this? Best regards, Olav Morken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ppc4xx] Please pull git://www.denx.de/git/u-boot-ppc4xx.git
The following changes since commit c1b7c70083fc8d0bb77db20dd47bb6c988f3dc67: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-nand-flash are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Larry Johnson (2): ppc4xx: Add variable "korat_usbcf" for Korat board ppc4xx: Clean up configuration file for Korat board board/korat/korat.c | 23 - doc/README.korat| 14 include/configs/korat.h | 84 --- 3 files changed, 86 insertions(+), 35 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
Wolfgang Denk wrote: > Dear Mark Jackson, > > In message <497f1732.6050...@mimc.co.uk> you wrote: >> This patch adds 16bpp BMP support to the common lcd code. >> >> Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code. >> >> At the moment it's only been tested on the MIMC200 AVR32 board, but >> extending >> this to other platforms should be a simple task !! >> >> Signed-off-by: Mark Jackson >> --- >> >> common/lcd.c | 49 +++-- >> 1 files changed, 39 insertions(+), 10 deletions(-) >> >> diff --git a/common/lcd.c b/common/lcd.c >> index ae79051..16d6f2a 100644 >> --- a/common/lcd.c >> +++ b/common/lcd.c >> +bmap += (padded_line - width) * 2; >> +fb -= (width * 2 + lcd_line_length); > > Is it intentional that you reverse padded_line and width here, i.e. > you are sure it's not > > bmap += (width - padded_line) * 2; > ? The "bmap += ..." line is to step forward to the start of the next line of bmp data, taking into account any padding bytes. If I read the code correct, padded_line is defined as ... padded_line = (width&0x3) ? ((width&~0x3)+4) : (width); ... so it will always be >= width. Correct ? If so, then ... bmap += (width - padded_line) * 2; ... will be <= 0, and so will actually step bmap back into the data you've just used, whereas ... bmap += (padded_line - width) * 2; ... will be >= 0, and will step forward to the start of the next line as required. Or have I misunderstood the bmp format and the existing code ? Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Clean up configuration file for Korat board
On Wednesday 28 January 2009, Larry Johnson wrote: > This patch updates the default environmental variables for the > Korat PPC 440EPx board, and makes additional minor fixes. Applied to 4xx/master. Thanks. Best regards, 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] ppc4xx: Add variable "korat_usbcf" for Korat board
On Wednesday 28 January 2009, Larry Johnson wrote: > The new environment variable "korat_usbcf" selects the USB > port used by the Korat board's CompactFlash controller. Applied to 4xx/master. Thanks. Best regards, 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 v2 5/9] AVR32: macb - Disable 100mbps if clock is slow
Ben Warren wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: > > make sense > > so I'll put a 10Mpbs phy personnaly instead or a 10/100 that can be put in a > > 10 mode instead to avoid to manage it in the code > > > I haven't shopped for PHYs in a while, but imagine it's probably hard to > find one that's 10Mb only, and if so it's probably more expensive than > 10/100 Especially when the board really is _supposed_ to do 100Mbps just fine. > >> No need to disable autonegotiation -- you still want to select between > >> half an full duplex, for example. But you'll need to limit the > >> available options to the ones that actually work. > >> > > I do not mean the autoneg but to specify to the phy, if possible, to never > > accept the 100Mps instead of do it in the code > > > That's basically why the advertise register is r/w, so you can limit > autonegotiation through software and don't have to allocate pins for > strapping. Yeah, I thought the advertise register was the correct way of informing the phy about what modes you support... I suppose we could move the initialization of the advertise register to board code, but that's going to be a lot uglier since the board code would have to access the MACB hardware to drive the MDIO pins. Perhaps some boards don't need any initialization at all, but then again, isn't it safer to unconditionally write the correct value? And when we're going to write the register _anyway_, we might as well allow the board code to influence the value we're going to write. The more I think of this, the more I'm convinced we should have allowed that from the beginning. The current driver is making assumptions it shouldn't be making. > >> That said, I kind of like Ben's suggestion -- it's a more general > >> solution to all sorts of board/phy/chip/whatever limitations. > >> > >> As for a better name, how about CONFIG_MACB_ADVERTISE? > >> > > why not > > > I like it too. One of the common checkbox items, though: do any Atmel > chips have more than one MACB, in which case this should be > CONFIG_MACBx_ADVERTISE or something like that? Yes, AT32AP7000 has two MACBs, so that's probably a good idea. Better yet, make it CONFIG_MACB_ADVERTISE(macb) so that the board can distinguish between various instances if it has to, and the driver doesn't have to do a long sequence of #ifdefs to find the correct value. Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Establishing connection via Ethernet
Hi Ben On Thu, Jan 29, 2009 at 2:03 PM, Ben Warren wrote: > Hi Piyush, > > Piyush Shah wrote: >> >> Hi all, >> Is it feasible to send u-boot commands via Ethernet instead of UART? >> I know that there is no such support right now. But can it be added? >> Moreover how am I supposed to transmit UDP or TCP packets from u-boot? >> >> >> > > Look into netconsole for control over Ethernet. I haven't used it > personally, but it's supported in U-boot. This is what I wanted Thanks a lot > > What kind of UDP or TCP packets do you want to send? Many of the common > UDP-based protocols have some support (NFS, TFTP and some others), but keep > in mind that U-boot is not a multitasking environment and so there is no > concept of 'servers'. Apart from netconsole, all network communications > must start from the target. > > regards, > Ben > -- -PIYUSH ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 31/31] 83xx, kmeter1: added bootcount feature
Hello Kim, Kim Phillips wrote: > On Wed, 28 Jan 2009 10:41:02 +0100 > Heiko Schocher wrote: > >> diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c > >> +#ifdef CONFIG_BOOTCOUNT_LIMIT >> + >> +#if !defined(CONFIG_BOOTCOUNT_ADDR) >> +#define CONFIG_BOOTCOUNT_ADDR 0x11bff8 > > it's CONFIG_SYS and magic number, but now that I've found it, sorry, I > can't accept this - not all 83xx have a QE and thus this MURAM. Even Hmm.. maybe we make this dependent on CONFIG_QE ? > if they did this would require changing the device tree muram node > property, to indicate its size has shrunk 8 bytes, right? In fact, not Yes, we should do this. > all QE's have 48Kbytes of MURAM either - the 8323 only has 16Kbytes. Thats why you could define it with CONFIG_BOOTCOUNT_ADDR, where exactly this 8 bytes are. > Problem is, I don't know of a better place to put the > bootcount. Ideas? I thought to make it as on 82xx (using parameter Ram of SCC1), because UCC5 should be compatible to the SCC1 see 8360ERM.pdf Table 19-11 on page 19-20. But on the 8360, after reset, the complete parameter RAM is initialized with 0 ... so that didn't work. Other places I couldn't found for this feature :-( bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 28/31] 8xx: add support for new keymile kmsupx4 board.
Hello Kim, Kim Phillips wrote: > On Wed, 28 Jan 2009 10:40:50 +0100 > Heiko Schocher wrote: > >> Signed-off-by: Heiko Schocher >> --- >> Makefile |9 +- >> board/keymile/common/common.c|6 +++- >> board/keymile/km8xx/km8xx.c |7 - >> cpu/mpc8xx/cpu_init.c|2 + >> cpu/mpc8xx/start.S |3 +- >> drivers/i2c/soft_i2c.c |3 ++ >> include/commproc.h |2 +- >> include/configs/keymile-common.h |2 +- >> include/configs/km8xx.h | 54 >> ++--- >> lib_ppc/board.c |3 +- >> 10 files changed, 73 insertions(+), 18 deletions(-) > > you're missing MAINTAINERS, MAKEALL, doc/README file bits. ok, I add this. thanks Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 22/31] mpc83xx, kmeter1, mtd: set the default partition table
Hello Kim, Kim Phillips wrote: > On Wed, 28 Jan 2009 10:40:24 +0100 > Heiko Schocher wrote: > >> diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h >> index d66ba8b..feb6150 100644 >> --- a/include/configs/kmeter1.h >> +++ b/include/configs/kmeter1.h >> @@ -322,6 +322,11 @@ >> #define CONFIG_SYS_DTT_BUS_NUM (2) >> #define CONFIG_SYS_DTT_BOARD_INIT 1 >> >> +#define MTDIDS_DEFAULT "nor0=app" >> +#define MTDPARTS_DEFAULT ( \ >> + "mtdparts=app:256k(u-boot),128k(env),128k(envred)," \ >> + >> "1536k(esw0),8704k(rootfs0),1536k(esw1),2432k(rootfs1),640k(var),768k(cfg)") >> + >> #if defined(CONFIG_PCI) >> #define CONFIG_CMD_PCI >> #endif >> @@ -448,6 +453,10 @@ >> "ramdisk_addr_r=F1\0" \ >> "EEprom_ivm=pca9547:70:9\0" \ >> "DTT_bus=pca9547:70:a\0"\ >> +"mtdids=nor0=app \0"\ >> +"mtdparts=mtdparts=app:256k(u-boot),128k(env),128k(envred),"\ >> +"1536k(esw0),8704k(rootfs0),1536k(esw1)," \ >> +"2432k(rootfs1),640k(var),768k(cfg)\0" \ >> "" > > instead of repeating strings, can we employ xstr here? Ok. thanks Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/31] mpc83xx, kmeter1: autodetect size of DDR II Ram.
Hello Kim,
Kim Phillips wrote:
> On Wed, 28 Jan 2009 10:40:20 +0100
> Heiko Schocher wrote:
>
>> Signed-off-by: Heiko Schocher
>> ---
>
> please be more verbose in your commit messages.
>
>> @@ -135,6 +128,24 @@ int fixed_sdram(void)
>> udelay (200);
>> im->ddr.sdram_cfg |= SDRAM_CFG_MEM_EN;
>>
>> +msize = CONFIG_SYS_DDR_SIZE;
>> +msize *= 1024;
>> +msize *= 1024;
>
> can we make these 3 lines one line?
Yes.
>> +disable_addr_trans ();
>> +msize = get_ram_size (CONFIG_SYS_DDR_BASE, msize);
>> +enable_addr_trans ();
>> +msize /= (1024 * 1024);
>> +if (CONFIG_SYS_DDR_SIZE != msize) {
>> +for (ddr_size = msize << 20, ddr_size_log2 = 0;
>> + (ddr_size > 1); ddr_size = ddr_size >> 1, ddr_size_log2++)
>> {
>> +if (ddr_size & 1)
>> +return -1;
>> +}
>
> I realize they existed before, but the braces are not necessary here.
OK
thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/31] mpc83xx, kmeter1: extract common I2C options in keymile header
Hello Kim, Kim Phillips wrote: > On Wed, 28 Jan 2009 10:40:16 +0100 > Heiko Schocher wrote: > >> Signed-off-by: Heiko Schocher >> --- >> include/configs/keymile-common.h |8 >> include/configs/kmeter1.h| 19 --- > > a lot of patches in this patchseries touch a lot of the same files - > can you please reorganize the series so that we don't have to review > something that's going to change again in a subsequent patch? Yes, I will reorganize this patchset complete. >> 2 files changed, 4 insertions(+), 23 deletions(-) >> >> diff --git a/include/configs/keymile-common.h >> b/include/configs/keymile-common.h >> index 99c3380..4ff6fb7 100644 >> --- a/include/configs/keymile-common.h >> +++ b/include/configs/keymile-common.h >> @@ -42,8 +42,6 @@ >> #define CONFIG_CMD_IMMAP >> #define CONFIG_CMD_MII >> #define CONFIG_CMD_PING >> - >> -/* should go away, if kmeter I2C support is enabled */ >> #define CONFIG_CMD_DTT >> #define CONFIG_CMD_EEPROM >> #define CONFIG_CMD_I2C > > the comment alludes that something should go away yet nothing's going > away but the comment itself. > > If there is indeed nothing to take away, then these are the types of > things you need to state why in your commit message. Ok. >> @@ -101,7 +99,6 @@ >> #define CONFIG_SYS_SLOT_ID_OFF (0x07) /* register offset */ >> #define CONFIG_SYS_SLOT_ID_MASK (0x3f) /* mask for slot ID >> bits */ >> >> -#if defined(CONFIG_MGCOGE) || defined(CONFIG_MGSUVD) >> #define CONFIG_I2C_MULTI_BUS1 >> #define CONFIG_I2C_CMD_TREE 1 >> #define CONFIG_SYS_MAX_I2C_BUS 2 >> @@ -109,7 +106,11 @@ >> #define CONFIG_I2C_MUX 1 >> >> /* EEprom support */ >> +#if defined(CONFIG_MGCOGE) || defined(CONFIG_MGSUVD) >> #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 >> +#else >> +#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 2 >> +#endif > > if this differs per board, shouldn't it be set in the board config, and > not the common config? Yes, that would be the right place. thanks Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/31] mpc83xx, kmeter1: add I2C, dtt, eeprom support
Hello Kim,
Kim Phillips wrote:
> On Wed, 28 Jan 2009 10:40:04 +0100
> Heiko Schocher wrote:
>
>> +static int board_init_i2c_busses (void)
>> +{
>> +I2C_MUX_DEVICE *dev = NULL;
>> +uchar *buf;
>> +
>> +/* Set up the Bus for the DTTs */
>> +buf = (unsigned char *) getenv ("DTT_bus");
>
> the environment is case sensitive; can we be more case-consistent
> with names we expect from it?
Ok.
>> +if (buf != NULL)
>> +dev = i2c_mux_ident_muxstring (buf);
>> +if (dev == NULL) {
>> +printf ("Error couldnt add Bus for DTT\n");
>
> s/couldnt/couldn't/, add something like "please setenv dtt_bus
> "
Ok.
>> +return 0;
>
> are you sure you shouldn't be returning an error code? otherwise this
> line is not necessary.
thanks,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/31] mpc83xx kmeter1: change some register settings
Hello Kim, Kim Phillips wrote: > On Wed, 28 Jan 2009 10:39:12 +0100 > Heiko Schocher wrote: > >> Signed-off-by: Heiko Schocher >> --- > > can we get a better commit title & message here please? Yes. bye heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/31] netloop: speed up NetLoop
Hello Kim,
Kim Phillips:
> On Wed, 28 Jan 2009 10:38:42 +0100
> Heiko Schocher wrote:
>> +++ b/common/cmd_nvedit.c
>> @@ -75,7 +75,12 @@ DECLARE_GLOBAL_DATA_PTR;
>> static const unsigned long baudrate_table[] = CONFIG_SYS_BAUDRATE_TABLE;
>> #define N_BAUDRATES (sizeof(baudrate_table) / sizeof(baudrate_table[0]))
>>
>> +static int env_id = 1;
>>
>> +int get_env_id (void)
>> +{
>> +return env_id;
>> +}
>
> does getting env_id really need be a function?
not absolute, but accesing this var from another file by a
function seems better to me.
>> diff --git a/net/eth.c b/net/eth.c
>> index b7ef09f..d1d73cb 100644
>> --- a/net/eth.c
>> +++ b/net/eth.c
>> @@ -28,7 +28,11 @@
>>
>> #if defined(CONFIG_CMD_NET) && defined(CONFIG_NET_MULTI)
>>
>> +static char *act = 0;
>> +static int env_changed_id = 0;
>> +
>> /*
>> +*
>
> please don't mess with the already good comment coding style.
Argh, sorry.
>> * CPU and board-specific Ethernet initializations. Aliased function
>> * signals caller to move on
>> */
>> @@ -439,13 +443,16 @@ void eth_try_another(int first_restart)
>> #ifdef CONFIG_NET_MULTI
>> void eth_set_current(void)
>> {
>> -char *act;
>> struct eth_device* old_current;
>>
>> if (!eth_current) /* XXX no current */
>> return;
>>
>> -act = getenv("ethact");
>> +if ((*act == 0) || (env_changed_id < get_env_id()))
>
> If I'm not mistaken, this will unintentionally dereference address 0
> the first time this is executed.
Hmm.. must think about it.
thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the digsy MTC board.
Wolfgang Denk wrote: > Dear Grzegorz, > > In message <12331552753467-git-send-email-...@semihalf.com> you wrote: >> This is the InterControl custom device based on the MPC5200B chip. > ... > > General comment: there is a lot of code which could use a few comments > so the reader has a chance to understand what exactly you are doing. > Could you point me out which parts of code except eeprom defines needs more comments? > >> diff --git a/cpu/mpc5xxx/ide.c b/cpu/mpc5xxx/ide.c >> index df5b4ac..07d33e3 100644 >> --- a/cpu/mpc5xxx/ide.c >> +++ b/cpu/mpc5xxx/ide.c >> @@ -12,7 +12,7 @@ >> * >> * This program is distributed in the hope that it will be useful, >> * but WITHOUT ANY WARRANTY; without even the implied warranty of >> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> * GNU General Public License for more details. >> * >> * You should have received a copy of the GNU General Public License > > Please don't arbitrarily reformat the code. > I think this tab was inserted by mistake. In u-boot code there are both versions of license with and without this tab. Do you really want to leave it? pozdrawiam, Grzesiek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Interrupts
Hi all, Iam using custamized bootlaoder for the ARM board . the interrupt handlers are not working in my bootloader can any body tell how to give supprt to interrupts handlers . I tried by giving handler registration in the cpu/24xx/interrupts.c file but failed can anyone help me in this issue. Regards, kishore. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC, 0/2] I2C rework -- what do you think?
Hello ksi, k...@koi8.net wrote: > On Wed, 28 Jan 2009, Heiko Schocher wrote: >> Hello ksi, >> k...@koi8.net schrieb: >>> On Tue, 27 Jan 2009, Heiko Schocher wrote: k...@koi8.net wrote: [...] >> OK,. But if I look in your patch you delete the "i2c bus" command, and >> this breaks at least 2 boards. > > Yep. As I said it was not a real patch, just a request for comments. I will > take care to make the real one work. Ok. >>> As a matter of fact I can only see 2 boards that use that existing mux >>> code, >>> namely mgsuvd and mgcoge. That will be trivial to rework. >> >> Yes, for those I made the "i2c bus" command. And it will follow soon >> 2 more boards ... > > OK, I will look at those boards and make sure they work. Anyway it is > just a > work in progress; no actual patch submitted so far... [...] >> It is needed! If, for example an EEprom, is not always on the same >> virtual >> bus. Some boards have no mux, some 1, some 2 ... and if we have this >> virtual >> busses statically, we must have for all boards an extra u-boot binary. >> The only Hardware difference for this boards is, how things are >> connected >> to the I2C bus ... and it is not OK for this manufacturer, to have >> for every board a different u-boot binary! >> >> So, why shouldnt it possible to add to your proposal a possibility to >> add virtual i2c busses dynamically? (using a list instead of a fix table >> for example) > > It is definitely a possibility but it would break uniformity. One can not > use lists while U-Boot is running out of ROM and DRAM is not active. That > means we should use an additional mechanism for those busses added later > on. > > One solution is to make num_i2c_busses (or whatever) a variable initially > set by config file define and then modified when new busses are added. It > also means we should use pointers instead of just array of structures and > bring in the whole bunch of list management functions like find_next, > find_prev, find_first etc. It might make board developer's life slightly > easier but would add complexity to U-Boot and increase its memory > footprint. OK, let us think a little about it. > I'm not sure yet that that little convenience is worth that. > > OK, I will return to it after I have that template driven multibus soft I2C > driver done. Ok. > All busses are explicitely defined in boards' config files so we >> know > exactly where all accesses are going. > Actual Code too. Make a "i2c dev" and you get the actual bus number, >> if it is a virtual bus, you can use "i2c bus" to get a list of this virtual busses. > I did test it on MPC8548CDS system and it works OK. There is a patch for > MPC8548CDS.h in the patchset that changes it to the new I2C code and >> a > speculative example of multiadapter multibus configuration with 3 adapters > and 5 busses 3 of which are connected with I2C muxes, 2 from them >> are > multihop. > Nice, but why you ignored the existing interface for handling with muxes? I think it is easier to extend the existing interface to support multiple "real" interfaces ... > > It steers us into a bunch of board-specific hacks and quirks instead of > making something uniform. We do not have a luxury of working DRAM when we > starting up and that code is required to bring up DRAM. I'm trying to avoid > separate code for startup and full blown operation. Yes, I know, this is a problem. >>> I don't think it is needed at all. One has some number of busses on >> the >>> board and all of them are active. Just switch to another bus and >> you're >>> good >>> to talk to that bus. If one needs something special, he can easily >> achieve >>> it with writing to those muxes with existing read/write commands. >> >> But it is in the code, because it is needed! > > I will return to it when it comes to the real patch. Ok, thanks. [...] So, maybe you could integrate your "multiple hardware I2C Bus" concept (which looks good at a first look) in the existing code? I vote for accesing the I2C Bus over a mux with the actual way: - defining with the "i2c bus" command a new "virtual" i2c device and - accesing this with the standard command "i2c dev" because this is a more flexible way. > > It is more flexible, I agree. But it multiplies entities. And doesn't add > anything that couldn't be achieved with other existing commands. > > Look, I2C bus behind muxes is just an already defined bus and a set of > regular single-register I2C chips connected to that bus. In order to "add" > that virtual bus one can simply switch to the appropriate existing bus and > write a byte or two to those chips with existing i2c write commands. > > That means that that "i2c bus" command in nothing more than a shortcut. It > can be easily implemented even as U-Boot environmental variable that one > can > run... Hmm.. so we need no i2c mux support? >>> CLI is ea
[U-Boot] [PATCH] include/image.h: Ease grepping of image_* functions
Because the functions have been defined using macros, grepping for
their definitions is not possible. This patch adds the real function
names in comments.
Signed-off-by: Petri Lehtinen
---
include/image.h | 44 ++--
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/include/image.h b/include/image.h
index 4609200..74a1240 100644
--- a/include/image.h
+++ b/include/image.h
@@ -338,23 +338,23 @@ static inline uint32_t image_get_header_size (void)
{ \
return uimage_to_cpu (hdr->ih_##f); \
}
-image_get_hdr_l (magic);
-image_get_hdr_l (hcrc);
-image_get_hdr_l (time);
-image_get_hdr_l (size);
-image_get_hdr_l (load);
-image_get_hdr_l (ep);
-image_get_hdr_l (dcrc);
+image_get_hdr_l (magic); /* image_get_magic */
+image_get_hdr_l (hcrc);/* image_get_hcrc */
+image_get_hdr_l (time);/* image_get_time */
+image_get_hdr_l (size);/* image_get_size */
+image_get_hdr_l (load);/* image_get_load */
+image_get_hdr_l (ep); /* image_get_ep */
+image_get_hdr_l (dcrc);/* image_get_dcrc */
#define image_get_hdr_b(f) \
static inline uint8_t image_get_##f(image_header_t *hdr) \
{ \
return hdr->ih_##f; \
}
-image_get_hdr_b (os);
-image_get_hdr_b (arch);
-image_get_hdr_b (type);
-image_get_hdr_b (comp);
+image_get_hdr_b (os); /* image_get_os */
+image_get_hdr_b (arch);/* image_get_arch */
+image_get_hdr_b (type);/* image_get_type */
+image_get_hdr_b (comp);/* image_get_comp */
static inline char *image_get_name (image_header_t *hdr)
{
@@ -396,23 +396,23 @@ static inline ulong image_get_image_end (image_header_t
*hdr)
{ \
hdr->ih_##f = cpu_to_uimage (val); \
}
-image_set_hdr_l (magic);
-image_set_hdr_l (hcrc);
-image_set_hdr_l (time);
-image_set_hdr_l (size);
-image_set_hdr_l (load);
-image_set_hdr_l (ep);
-image_set_hdr_l (dcrc);
+image_set_hdr_l (magic); /* image_set_magic */
+image_set_hdr_l (hcrc);/* image_set_hcrc */
+image_set_hdr_l (time);/* image_set_time */
+image_set_hdr_l (size);/* image_set_size */
+image_set_hdr_l (load);/* image_set_load */
+image_set_hdr_l (ep); /* image_set_ep */
+image_set_hdr_l (dcrc);/* image_set_dcrc */
#define image_set_hdr_b(f) \
static inline void image_set_##f(image_header_t *hdr, uint8_t val) \
{ \
hdr->ih_##f = val; \
}
-image_set_hdr_b (os);
-image_set_hdr_b (arch);
-image_set_hdr_b (type);
-image_set_hdr_b (comp);
+image_set_hdr_b (os); /* image_set_os */
+image_set_hdr_b (arch);/* image_set_arch */
+image_set_hdr_b (type);/* image_set_type */
+image_set_hdr_b (comp);/* image_set_comp */
static inline void image_set_name (image_header_t *hdr, const char *name)
{
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Establishing connection via Ethernet
Hi Piyush, Piyush Shah wrote: > Hi all, > Is it feasible to send u-boot commands via Ethernet instead of UART? > I know that there is no such support right now. But can it be added? > Moreover how am I supposed to transmit UDP or TCP packets from u-boot? > > > Look into netconsole for control over Ethernet. I haven't used it personally, but it's supported in U-boot. What kind of UDP or TCP packets do you want to send? Many of the common UDP-based protocols have some support (NFS, TFTP and some others), but keep in mind that U-boot is not a multitasking environment and so there is no concept of 'servers'. Apart from netconsole, all network communications must start from the target. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] AVR32: macb - Search for PHY id
Gunnar Rangoy wrote:
> This patch adds support for searching through available PHY-addresses in
> the macb-driver. This is needed for the ATEVK1100 evaluation board,
> where the PHY-address will be initialized to either 1 or 7.
>
> This patch adds a config option, CONFIG_MACB_SEARCH_PHY, which when
> enabled tells the driver to search for the PHY address.
>
> Signed-off-by: Gunnar Rangoy
> Signed-off-by: Paul Driveklepp
> Signed-off-by: Olav Morken
> ---
> drivers/net/macb.c | 31 +++
> 1 files changed, 31 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index d47a052..c8beb82 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -327,6 +327,30 @@ static void macb_phy_reset(struct macb_device *macb)
> netdev->name, status);
> }
>
> +#ifdef CONFIG_MACB_SEARCH_PHY
> +static int macb_phy_find(struct macb_device *macb)
> +{
> + int i;
> + u16 phy_id;
> +
> + /* Search for PHY... */
> + for (i = 0; i < 32; i++) {
> + macb->phy_addr = i;
> + phy_id = macb_mdio_read(macb, MII_PHYSID1);
> + if (phy_id != 0x) {
> + printf("%s: PHY present at %d\n", macb->netdev.name, i);
> + return 1;
> + }
> + }
> +
> + /* PHY isn't up to snuff */
> + printf("%s: PHY not found", macb->netdev.name);
> +
> + return 0;
> +}
> +#endif /* CONFIG_MACB_SEARCH_PHY */
> +
> +
> static int macb_phy_init(struct macb_device *macb)
> {
> struct eth_device *netdev = &macb->netdev;
> @@ -335,6 +359,13 @@ static int macb_phy_init(struct macb_device *macb)
> int media, speed, duplex;
> int i;
>
> +#ifdef CONFIG_MACB_SEARCH_PHY
> + /* Auto-detect phy_addr */
> + if (!macb_phy_find(macb)) {
> + return 0;
> + }
> +#endif /* CONFIG_MACB_SEARCH_PHY */
> +
> /* Check if the PHY is up to snuff... */
> phy_id = macb_mdio_read(macb, MII_PHYSID1);
> if (phy_id == 0x) {
>
Added to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] Fix IP alignement problem
Gunnar Rangoy wrote:
> From: Olav Morken
>
> This patch removes volatile from:
> volatile IP_t *ip = (IP_t *)xip;
>
> Due to a bug, avr32-gcc will assume that ip is aligned on a word boundary when
> using volatile, which causes an exception since xip isn't aligned on a word
> boundary.
>
> Signed-off-by: Gunnar Rangoy
> Signed-off-by: Paul Driveklepp
> Signed-off-by: Olav Morken
> ---
> net/net.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/net.c b/net/net.c
> index 313d5d8..405ca6e 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1685,7 +1685,7 @@ NetSetEther(volatile uchar * xet, uchar * addr, uint
> prot)
> void
> NetSetIP(volatile uchar * xip, IPaddr_t dest, int dport, int sport, int len)
> {
> - volatile IP_t *ip = (IP_t *)xip;
> + IP_t *ip = (IP_t *)xip;
>
> /*
>* If the data is an odd number of bytes, zero the
>
Applied to net repo (fixed typo in title )
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Marvell 88E1118 interrupt fix
Ron Madrid wrote:
> This patch adjusts the LED control so that interrupt lines are not reading
> LEDs
> and effectively causing indefinite interrupts to the controller.
>
> Signed-off-by: Ron Madrid
> ---
> drivers/net/tsec.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> index d7da081..c9aa29d 100644
> --- a/drivers/net/tsec.c
> +++ b/drivers/net/tsec.c
> @@ -1141,6 +1141,9 @@ struct phy_info phy_info_M88E1118 = {
> {MIIM_CONTROL, MIIM_CONTROL_RESET, NULL},
> {0x16, 0x0002, NULL}, /* Change Page Number */
> {0x15, 0x1070, NULL}, /* Delay RGMII TX and RX */
> + {0x16, 0x0003, NULL}, /* Change Page Number */
> + {0x10, 0x021e, NULL}, /* Adjust LED control */
> + {0x16, 0x, NULL}, /* Change Page Number */
> {MIIM_GBIT_CONTROL, MIIM_GBIT_CONTROL_INIT, NULL},
> {MIIM_ANAR, MIIM_ANAR_INIT, NULL},
> {MIIM_CONTROL, MIIM_CONTROL_RESET, NULL},
> @@ -1152,6 +1155,7 @@ struct phy_info phy_info_M88E1118 = {
> /* Status is read once to clear old link state */
> {MIIM_STATUS, miim_read, NULL},
> /* Auto-negotiate */
> + {MIIM_STATUS, miim_read, &mii_parse_sr},
> /* Read the status */
> {MIIM_88E1011_PHY_STATUS, miim_read,
>&mii_parse_88E1011_psr},
>
Applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Establishing connection via Ethernet
Hi all, Is it feasible to send u-boot commands via Ethernet instead of UART? I know that there is no such support right now. But can it be added? Moreover how am I supposed to transmit UDP or TCP packets from u-boot? -- -PIYUSH ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: smc911x.c: Add LAN9211 to chip_ids[] array
Stefan Roese wrote:
> Signed-off-by: Stefan Roese
> ---
> drivers/net/smc911x.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 648c94c..268a630 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -381,6 +381,7 @@ void pkt_data_push(u32 addr, u32 val) \
> #define CHIP_91160x116
> #define CHIP_91170x117
> #define CHIP_91180x118
> +#define CHIP_92110x9211
> #define CHIP_92150x115a
> #define CHIP_92160x116a
> #define CHIP_92170x117a
> @@ -396,6 +397,7 @@ static const struct chip_id chip_ids[] = {
> { CHIP_9116, "LAN9116" },
> { CHIP_9117, "LAN9117" },
> { CHIP_9118, "LAN9118" },
> + { CHIP_9211, "LAN9211" },
> { CHIP_9215, "LAN9215" },
> { CHIP_9216, "LAN9216" },
> { CHIP_9217, "LAN9217" },
>
Applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move is_valid_ether_addr() to include/net.h
Mike Frysinger wrote:
> Import the is_valid_ether_addr() function from the Linux kernel.
>
> Signed-off-by: Mike Frysinger
> CC: Ben Warren
> ---
> board/bf537-stamp/bf537-stamp.c | 16
> include/net.h | 16
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/board/bf537-stamp/bf537-stamp.c b/board/bf537-stamp/bf537-stamp.c
> index 7303f1b..cec2b26 100644
> --- a/board/bf537-stamp/bf537-stamp.c
> +++ b/board/bf537-stamp/bf537-stamp.c
> @@ -34,22 +34,6 @@
> #include
> #include
>
> -/**
> - * is_valid_ether_addr - Determine if the given Ethernet address is valid
> - * @addr: Pointer to a six-byte array containing the Ethernet address
> - *
> - * Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not
> - * a multicast address, and is not FF:FF:FF:FF:FF:FF.
> - *
> - * Return true if the address is valid.
> - */
> -static inline int is_valid_ether_addr(const u8 * addr)
> -{
> - /* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to
> - * explicitly check for it here. */
> - return !is_multicast_ether_addr(addr) && !is_zero_ether_addr(addr);
> -}
> -
> DECLARE_GLOBAL_DATA_PTR;
>
> #define POST_WORD_ADDR 0xFF903FFC
> diff --git a/include/net.h b/include/net.h
> index d2d394f..bbe0d4b 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -474,6 +474,22 @@ static inline int is_multicast_ether_addr(const u8 *addr)
> return (0x01 & addr[0]);
> }
>
> +/**
> + * is_valid_ether_addr - Determine if the given Ethernet address is valid
> + * @addr: Pointer to a six-byte array containing the Ethernet address
> + *
> + * Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not
> + * a multicast address, and is not FF:FF:FF:FF:FF:FF.
> + *
> + * Return true if the address is valid.
> + */
> +static inline int is_valid_ether_addr(const u8 * addr)
> +{
> + /* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to
> + * explicitly check for it here. */
> + return !is_multicast_ether_addr(addr) && !is_zero_ether_addr(addr);
> +}
> +
> /* Convert an IP address to a string */
> extern void ip_to_string (IPaddr_t x, char *s);
>
>
Applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: Sort Makefile labels
mon...@monstr.eu wrote: > From: Michal Simek > > > Signed-off-by: Michal Simek > --- > drivers/net/Makefile |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > index 631336a..128dc11 100644 > --- a/drivers/net/Makefile > +++ b/drivers/net/Makefile > @@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk > LIB := $(obj)libnet.a > > COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o > +COBJS-$(CONFIG_PPC4xx_EMAC) += 4xx_enet.o > COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o > COBJS-$(CONFIG_BCM570x) += bcm570x.o bcm570x_autoneg.o 5701rls.o > COBJS-$(CONFIG_BFIN_MAC) += bfin_mac.o > @@ -54,11 +55,11 @@ COBJS-$(CONFIG_NS8382X) += ns8382x.o > COBJS-$(CONFIG_DRIVER_NS9750_ETHERNET) += ns9750_eth.o > COBJS-$(CONFIG_PCNET) += pcnet.o > COBJS-$(CONFIG_PLB2800_ETHER) += plb2800_eth.o > -COBJS-$(CONFIG_PPC4xx_EMAC) += 4xx_enet.o > COBJS-$(CONFIG_DRIVER_RTL8019) += rtl8019.o > COBJS-$(CONFIG_RTL8139) += rtl8139.o > COBJS-$(CONFIG_RTL8169) += rtl8169.o > COBJS-$(CONFIG_DRIVER_S3C4510_ETH) += s3c4510b_eth.o > +COBJS-$(CONFIG_SH_ETHER) += sh_eth.o > COBJS-$(CONFIG_DRIVER_SMC9) += smc9.o > COBJS-$(CONFIG_DRIVER_SMC911X) += smc911x.o > COBJS-$(CONFIG_TIGON3) += tigon3.o bcm570x_autoneg.o 5701rls.o > @@ -68,7 +69,6 @@ COBJS-$(CONFIG_ULI526X) += uli526x.o > COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o > COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o > COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o > -COBJS-$(CONFIG_SH_ETHER) += sh_eth.o > > COBJS:= $(COBJS-y) > SRCS := $(COBJS:.o=.c) > Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
