Re: [U-Boot] any patch?
You can google and you can find some patches. If I well remember the last one is a patch for uboot 1.3.3 by olimex for a board based on that processor (cs-e9302). I recently ported uboot to a recent version starting from that version, there are only some adjustment to do especially about timer functions (in addition to the customization for your board, of course). There are other two patches, one from Cirrus logic (the older one) and one for edb9302a for uboot 1.3.2. Regards, Marco 2009/4/7 prashant sangal prashantsan...@yahoo.co.in: Hello .. I am new to this mailing list. Is there any patch available for Cyrrus Logic EP9302 based baords? regards, Prashant Sangal Bollywood news, movie reviews, film trailers and more! Go to http://in.movies.yahoo.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Marvell Kirkwood family SOC support
Kirkwood family controllers are highly integrated SOCs
based on Feroceon-88FR131/Sheeva-88SV131 cpu core.
SOC versions supported:-
1) 88F6281-Z0 define CONFIG_KW88F6281_Z0
2) 88F6281-A0 define CONFIG_KW88F6281_A0
3) 88F6192-A0 define CONFIG_KW88F6192_A0
Other supported features:-
1) get_random_hex() fucntion
2) SPI port controller driver
3) PCI Express port initialization
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Reviewed-by: Ronen Shitrit rshit...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Changelog:
v2: crated arch-kirkwood and moved some header files there
renamed and moved spi.c to drivers/spi/
renamed and moved serial.c to drivers/serial/
doimage utility removed
soc_init.S renamed as lowlevel_init.S
debug prints removed
board/Marvell/include/core.h |4 +
cpu/arm926ejs/kirkwood/Makefile | 50 ++
cpu/arm926ejs/kirkwood/config.mk | 25 +++
cpu/arm926ejs/kirkwood/dram.c | 55 +++
cpu/arm926ejs/kirkwood/kwcore.c | 250 +
cpu/arm926ejs/kirkwood/kwcore.h | 47 ++
cpu/arm926ejs/kirkwood/lowlevel_init.S| 183 +
cpu/arm926ejs/kirkwood/timer.c| 165 +++
drivers/serial/Makefile |1 +
drivers/serial/kirkwood_serial.c | 187 +
drivers/spi/Makefile |1 +
drivers/spi/kirkwood_spi.c| 199 +++
include/asm-arm/arch-kirkwood/kirkwood.h | 142
include/asm-arm/arch-kirkwood/kw88f6192.h | 37 +
include/asm-arm/arch-kirkwood/kw88f6281.h | 43 +
include/asm-arm/config.h |4 +
16 files changed, 1393 insertions(+), 0 deletions(-)
create mode 100644 cpu/arm926ejs/kirkwood/Makefile
create mode 100644 cpu/arm926ejs/kirkwood/config.mk
create mode 100644 cpu/arm926ejs/kirkwood/dram.c
create mode 100644 cpu/arm926ejs/kirkwood/kwcore.c
create mode 100644 cpu/arm926ejs/kirkwood/kwcore.h
create mode 100644 cpu/arm926ejs/kirkwood/lowlevel_init.S
create mode 100644 cpu/arm926ejs/kirkwood/timer.c
create mode 100644 drivers/serial/kirkwood_serial.c
create mode 100644 drivers/spi/kirkwood_spi.c
create mode 100644 include/asm-arm/arch-kirkwood/kirkwood.h
create mode 100644 include/asm-arm/arch-kirkwood/kw88f6192.h
create mode 100644 include/asm-arm/arch-kirkwood/kw88f6281.h
diff --git a/board/Marvell/include/core.h b/board/Marvell/include/core.h
index c413439..ecc4682 100644
--- a/board/Marvell/include/core.h
+++ b/board/Marvell/include/core.h
@@ -12,9 +12,11 @@ space). The macros take care of Big/Little endian
conversions.
#ifndef __INCcoreh
#define __INCcoreh
+#ifndef CONFIG_KIRKWOOD
#include mv_gen_reg.h
extern unsigned int INTERNAL_REG_BASE_ADDR;
+#endif /* CONFIG_KIRKWOOD */
//
/* GENERAL Definitions */
@@ -91,10 +93,12 @@ extern unsigned int INTERNAL_REG_BASE_ADDR;
#define _1G0x4000
#define _2G0x8000
+#ifndef __ASSEMBLY__
#ifndefBOOL_WAS_DEFINED
#define BOOL_WAS_DEFINED
typedef enum _bool{false,true} bool;
#endif
+#endif
/* Little to Big endian conversion macros */
diff --git a/cpu/arm926ejs/kirkwood/Makefile b/cpu/arm926ejs/kirkwood/Makefile
new file mode 100644
index 000..c917f0d
--- /dev/null
+++ b/cpu/arm926ejs/kirkwood/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Prafulla Wadaskar prafu...@marvell.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# 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
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).a
+
+COBJS-y= dram.o
+COBJS-y+= kwcore.o
+COBJS-y+= timer.o
+
+SOBJS = lowlevel_init.o
+
+SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS-y))
+
+all: $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
Re: [U-Boot] Help about a simplified bootloader.
On Wed, Apr 8, 2009 at 2:42 PM, Shankar Ganesh shankargane...@gmail.com wrote: On Tue, Apr 7, 2009 at 11:02 AM, os user gnuse...@gmail.com wrote: Hi, The data in NAND chip(linux kernel and RootFS) is the same when booting linux from U-Boot and from the simple loader. :-( On Sat, Apr 4, 2009 at 12:53 AM, Scott Wood scottw...@freescale.com wrote: On Fri, Apr 03, 2009 at 02:44:03PM +0800, os user wrote: I want to boot linux by a simplified bootloader. I use Atmel's ARM chip (AT91SAM9RL64EK board). Now, I can boot linux with my small program. The small program will parse the image generaed by mkimage and copy the kernel bianry from NAND flash to SDRAM, construct the tag list, disable I/D cache, disable interrupt and then jump to kernel entry point. The system can startup, but when accessing rootfile system(the rootfile system was also in the NAND chip), a lot of CRC errors were found. See below, mtd-read(0x1fb2c bytes from 0x1804d4) returned ECC error mtd-read(0x1fa38 bytes from 0x3e05c8) returned ECC error mtd-read(0x1f7dc bytes from 0x7c0824) returned ECC error jffs2_scan_inode_node(): CRC failed on node at 0x007c37a4: Read 0xd9b2bc33, calculated 0xda4805c1 and sometimes the sytem even crashed when R/W filesystem. But with the same linux kernel and rootfile system, if I use U-Boot to boot linux, everything seems OK. Can anyone tell is there any trick that's related with linux NAND driver in U-Boot? Or any suggestion to help me moving on? How about ECC calculation ? is it h/w (GPMC) or s/w ECC ? I used software ECC. I don't think this problem is related to ECC calculation. As metioned before, I used the same OS kernel image and root filesystem image(JFFS2). Both are stored in NAND flash. For the good case, Atmel's bootstrap code will launch U-Boot, and U-Boot will copy kernel image from NAND chip to SDRAM, build tag list, do some clean job(diable interrupt, flush/disable cache), and then jump to kernel entry point. If I follow this path, everything is OK. This means my linux kernel(2.6.27) and root filesystem are OK. But In my small loader(based on Atmel's bootstrap), I also copy kernel image from NAND chip to SDRAM, build tag list, do some clean job(diable interrupt, flush/disable cache), and then jump to kernel entry point. The kernel image can be decompressed without any error and can startup sometimes. But I can see a lot of errors complained by MTD layer. And sometimes, the system even crashed. Hope to receive your suggestions, Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to build u-boot environment
Hi, May i know how to build the u-boot environment for my board? Whats the different below. I would like to know how to build u-boot environment. As i know its different with u-boot.bin. make distclean make at91sam9263ek_config make CROSS_COMPILE=path_to_cross-compiler/cross-compiler-prefix- make distclean make at91sam9263ek_dataflash_cs0_config make CROSS_COMPILE=path_to_cross-compiler/cross-compiler-prefix- /Ong ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Fixup chip-selects in dtb for NAND-booting Sequoia
Currently the NOR NAND support in Linux only works for the standard
Sequoia, the version booting for NOR flash. The NAND-booting version
has the chip-selects swapped. Here the chip-select mappings:
Standard NOR-booting version:
CS0 NOR
CS3 NAND
NAND-booting version:
CS0 NAND
CS3 NOR
With this path the dtb gets fixed-up, so that the correct chip-select
numbers are patched in the dtb enabling correct NOR NAND support
in Linux on the NAND-booting Sequoia version.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/sequoia/sequoia.c | 58 -
1 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/board/amcc/sequoia/sequoia.c b/board/amcc/sequoia/sequoia.c
index d6668e2..e824b8f 100644
--- a/board/amcc/sequoia/sequoia.c
+++ b/board/amcc/sequoia/sequoia.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2006-2007
+ * (C) Copyright 2006-2009
* Stefan Roese, DENX Software Engineering, s...@denx.de.
*
* (C) Copyright 2006
@@ -35,7 +35,8 @@ DECLARE_GLOBAL_DATA_PTR;
extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH
chips */
-ulong flash_get_size (ulong base, int banknum);
+extern void __ft_board_setup(void *blob, bd_t *bd);
+ulong flash_get_size(ulong base, int banknum);
int board_early_init_f(void)
{
@@ -513,3 +514,56 @@ int post_hotkeys_pressed(void)
return 0; /* No hotkeys supported */
}
#endif /* CONFIG_POST */
+
+#if defined(CONFIG_NAND_U_BOOT)
+/*
+ * On NAND-booting sequoia, we need to patch the chips select numbers
+ * in the dtb (CS0 - NAND, CS3 - NOR)
+ */
+void ft_board_setup(void *blob, bd_t *bd)
+{
+ int rc;
+ int len;
+ int nodeoffset;
+ struct fdt_property *prop;
+ u32 *reg;
+ char path[32];
+
+ /* First do common fdt setup */
+ __ft_board_setup(blob, bd);
+
+ /* And now configure NOR chip select to 3 instead of 0 */
+ strcpy(path, /plb/opb/ebc/nor_fl...@0,0);
+ nodeoffset = fdt_path_offset(blob, path);
+ prop = fdt_get_property_w(blob, nodeoffset, reg, len);
+ if (prop == NULL) {
+ printf(Unable to update NOR chip select for NAND booting\n);
+ return;
+ }
+ reg = (u32 *)prop-data[0];
+ reg[0] = 3;
+ rc = fdt_find_and_setprop(blob, path, reg, reg, 3 * sizeof(u32), 1);
+ if (rc) {
+ printf(Unable to update property NOR mappings, err=%s\n,
+ fdt_strerror(rc));
+ return;
+ }
+
+ /* And now configure NAND chip select to 0 instead of 3 */
+ strcpy(path, /plb/opb/ebc/n...@3,0);
+ nodeoffset = fdt_path_offset(blob, path);
+ prop = fdt_get_property_w(blob, nodeoffset, reg, len);
+ if (prop == NULL) {
+ printf(Unable to update NDFC chip select for NAND booting\n);
+ return;
+ }
+ reg = (u32 *)prop-data[0];
+ reg[0] = 0;
+ rc = fdt_find_and_setprop(blob, path, reg, reg, 3 * sizeof(u32), 1);
+ if (rc) {
+ printf(Unable to update property NDFC mappings, err=%s\n,
+ fdt_strerror(rc));
+ return;
+ }
+}
+#endif /* CONFIG_NAND_U_BOOT */
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple Flash devices
On Wednesday 08 April 2009 05:48:19 Ravula Kishor wrote: I have a NOR Flash used as a boot flash (16MB) and a NAND flash (128MB)to store kernel/rfs on coldfire based custom board . The u-boot is running out of NOR flash but I have problems in enabling NAND support from u-boot. Need clarity on couple of definitions in the board configuration file. CFG_FLASH_SIZE : CFG_MAX_FLASH_BANKS: CFG_FLASH_BANKS_LIST : these defines have nothing to do with NAND -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Marvell MV88F6281GTW_GE Board support
From: prafulla_wadaskar prafu...@marvell.com This is Marvell's 88F6281_A0 based custom board developed for wireless access point product This patch is tested for- 1. Boot from DRAM/SPI flash/NFS 2. File transfer using tftp and loadb 3. SPI flash read/write/erase 4. Booting Linux kernel and RFS from SPI flash Note: doImage utility needed to convert u-boot.bin to u-boot-spiflash.bin, DRAM configuration will be part of this utility Reviewed-by: Ronen Shitrit rshit...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Changelog v2: updated as per first review comments by Wolfgang Denk debug_prints updated to debug MAKEALL |1 + Makefile|3 + board/Marvell/mv88f6281gtw_ge/Makefile | 52 +++ board/Marvell/mv88f6281gtw_ge/config.mk | 25 +++ board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 118 ++ board/Marvell/mv88f6281gtw_ge/u-boot.lds| 53 +++ include/configs/mv88f6281gtw_ge.h | 185 +++ 7 files changed, 437 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/Makefile create mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c create mode 100644 board/Marvell/mv88f6281gtw_ge/u-boot.lds create mode 100644 include/configs/mv88f6281gtw_ge.h diff --git a/MAKEALL b/MAKEALL index e4eb42b..1caf81d 100755 --- a/MAKEALL +++ b/MAKEALL @@ -504,6 +504,7 @@ LIST_ARM9= \ cp946es \ cp966 \ lpd7a400\ + mv88f6281gtw_ge \ mx1ads \ mx1fs2 \ netstar \ diff --git a/Makefile b/Makefile index d2c7c3f..709e4be 100644 --- a/Makefile +++ b/Makefile @@ -2792,6 +2792,9 @@ lpd7a400_config \ lpd7a404_config: unconfig @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x +mv88f6281gtw_ge_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + mx1ads_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t mx1ads NULL imx diff --git a/board/Marvell/mv88f6281gtw_ge/Makefile b/board/Marvell/mv88f6281gtw_ge/Makefile new file mode 100644 index 000..1b8cc6f --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/Makefile @@ -0,0 +1,52 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Prafulla Wadaskar prafu...@marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# 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 +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := mv88f6281gtw_ge.o +COBJS += ../common/mv88e61xx.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/mv88f6281gtw_ge/config.mk b/board/Marvell/mv88f6281gtw_ge/config.mk new file mode 100644 index 000..fb29a1b --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Prafulla Wadaskar prafu...@marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# 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 +# GNU General Public License for more details. +# +# You
Re: [U-Boot] Booting kernel from jffs2
Currently, I have two partitions one for U- Boot and the rest for application(kernel + application) Total 16MB Flash 1MB U Boot 15MB JFFS2 Application The U boot loads the kernel from jffs2 using fsload and the system works fine. Sometimes, during software upgrade, the problem comes when jffs2 is almost full, the files could not be deleted to freeup space because of jffs2 limitation. The entire partition needs to be reflashed which is not a practical solution . Is there any better way to recover from this failure situation where we can boot a minimum kernel and can format the jffs2 partition and copy the application image? On Tue, Apr 7, 2009 at 2:26 PM, Wolfgang Denk w...@denx.de wrote: Dear Rams Subramanian, In message 4e031cb50904070515u797beb03o23ad89c15362c...@mail.gmail.com you wrote: I have an requirement to have three partitions in the Flash 1. U Boot 2. JFFS2(GoldenImage) (Mininum Kernel Image ) 3. JFFS2(Application Image) (Kernel + Application) The idea of Golden image is to use this partition to boot in case the application image fails after software upgrade due to corruption of the filesystem in this partition if any during upgrade. When the system is up with Golden image, partition 3 can be updated. Is this method feasible. Kindly let me know if you have better ideas or suggestions? Yes, this is possible (actually, it's trivial). Without knowing your exact requirements and restrictions it's difficult to recommend better ideas... 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 Stupidity, like virtue, is its own reward - William E. Davidsen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Uboot on Realview_pb11MPcore, Using Mpcore onchip timer, access onchip private memory region.
Hello Dear, I am porting Uboot to our platform which is similiar to Realview_pb11MPcore, with the difference in Timer : Using the ARM11 MPcore onchip timer instead of offchip SP804 Timer. As a result, i have to access the MPCore private memory region. According to the ARM11MPcore Technical Reference Manual, I can access the private memory region by using pins PERIPHBASE[18:0], which is 19 bits. I shift the PERIPHBASE 13 bits to the right then plus the 13 bits offset for the Onchip timer, use this address to modify the CONFIG_SYS_TIMERBASE macro in realview_pb.h. But when I initialize the Uboot, it just halted with nothing in the console.( If I dont use such addresses, the system wont halt but come to the stand that timer cannot downcount: Hit any key to stop autoboot: 2 ) Is there anyone know if it is the right way to access MPCore private memory region? BR, George ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] smc911x: add support for LAN9220
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
---
drivers/net/smc911x.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 80d2ce0..2b01cf5 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -382,6 +382,7 @@ static inline void smc911x_reg_write(u32 addr, u32 val)
#define CHIP_9216 0x116a
#define CHIP_9217 0x117a
#define CHIP_9218 0x118a
+#define CHIP_9220 0x9220
struct chip_id {
u16 id;
@@ -398,6 +399,7 @@ static const struct chip_id chip_ids[] = {
{ CHIP_9216, LAN9216 },
{ CHIP_9217, LAN9217 },
{ CHIP_9218, LAN9218 },
+ { CHIP_9220, LAN9220 },
{ 0, NULL },
};
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
If the MAX address is given by the environment, write it back to the
hardware.
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
---
drivers/net/smc911x.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 30f2dc2..8c9a2a8 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -41,8 +41,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
unsigned long addrh, addrl;
uchar m[6];
- /* if the environment has a valid mac address then use it */
- if (!eth_getenv_enetaddr(ethaddr, m)) {
+ if (eth_getenv_enetaddr(ethaddr, m)) {
+ /* if the environment has a valid mac address then use it */
+ addrl = m[0] | (m[1] 8) | (m[2] 16) | (m[3] 24);
+ addrh = m[4] | (m[5] 8);
+ smc911x_set_mac_csr(ADDRL, addrl);
+ smc911x_set_mac_csr(ADDRH, addrh);
+ } else {
/* if not, try to get one from the eeprom */
addrh = smc911x_get_mac_csr(ADDRH);
addrl = smc911x_get_mac_csr(ADDRL);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On boards without EEPROMs, don't reset the chip on U-Boot's exit so that
the MAC set by environment settings can be used by the OS later.
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
---
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 8c9a2a8..f777ae9 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -225,7 +225,9 @@ int eth_send(volatile void *packet, int length)
void eth_halt(void)
{
+#ifndef CONFIG_DRIVER_SMC911X_NO_EEPROM
smc911x_reset();
+#endif
}
int eth_rx(void)
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Interrupt handlers in u-boot
Hi, I am working on u-boot 1.1.6 version for PowerPC 440.I am using the hello world application from the examples folder. I had no issues in loading and executing it. Now I have enabled SPI interrupt in the application. I have written for SPI loopback. My issue is, as there is no interrupt handler defined for the SPI in uboot, whenever i execute my application, it says Masking bogus interrupt for Vector 0x08. I am calling install_irq_handler function for assigning my own interrupt handler for SPI as part of my application itself. I can understand that, there is no exclusive handler for SPI in uboot, so it is disabling the SPI interrupt and printing the BOGUS INTERRUPT message. Now how do I get rid of this and have my own interrupt handler?? Some one please help. Thanks all in advance. Thanks Regards, Prathika R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Multiple Flash devices
I have a NOR Flash used as a boot flash (16MB) and a NAND flash (128MB)to store kernel/rfs on coldfire based custom board . The u-boot is running out of NOR flash but I have problems in enabling NAND support from u-boot. Need clarity on couple of definitions in the board configuration file. CFG_FLASH_SIZE : Should it include both NOR+NAND size CFG_MAX_FLASH_BANKS: If there are two flash devices, is it correct to give as 2. Is NAND flash identified as a seperate Bank. CFG_FLASH_BANKS_LIST : Should it include both Flash base addresses. Welcome any other pointers when working with both NOR/NAND Flash. Thanks in adv. //Kishor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Interrupt handlers in u-boot
On Wednesday 08 April 2009, prathika wrote: I am working on u-boot 1.1.6 version for PowerPC 440. First of all. v1.1.6 is really old. I suggest that you use the current (latest) version instead. I am using the hello world application from the examples folder. I had no issues in loading and executing it. Now I have enabled SPI interrupt in the application. I have written for SPI loopback. My issue is, as there is no interrupt handler defined for the SPI in uboot, whenever i execute my application, it says Masking bogus interrupt for Vector 0x08. I am calling install_irq_handler function for assigning my own interrupt handler for SPI as part of my application itself. I can understand that, there is no exclusive handler for SPI in uboot, so it is disabling the SPI interrupt and printing the BOGUS INTERRUPT message. Now how do I get rid of this and have my own interrupt handler?? You just need to install you own interrupt handler. This is done via install_hdlr(). See examples/interrupt.c. 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
[U-Boot] porting u-boot and linux for ARM9 on WinXP
Hi Guys, I have few querries. 1 I want to port u-boot and linux for ARM9 architecture on Wndows XP. is it possible? 2 If yes, please let me know how. 3 and also let me know which ARM toolchain I would use, and from where I wud download the kernel source tree? 4 How to unzip on windows XP (tar,.bz2 files) Kindly find some time for reolve it. With Regards Ranjan Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Ping on Coldfire patch status
Hi John, Just wanted to ping on the status of the Coldfire patches I submitted, I noticed the submission window is closed on 2009.06 :) http://www.nabble.com/-U-Boot---PATCH--Coldfire-M5271%3A-Activate-u-boot-system-timer-interrupt.-td22729407.html#a22729407 http://www.nabble.com/-U-Boot---PATCH--Coldfire%3A-interrupts%3A-Add-watchdog-auto-reset-to-dtimer_interrupt-td22629836.html#a22629836 http://www.nabble.com/-U-Boot---PATCH--Coldfire%3A-cleanup-compiler-warning-for-lib-m68k-unused-variables.-td22665336.html#a22665336 http://www.nabble.com/-U-Boot---PATCH--Coldfire%3A-I2C%3A-Update-I2CFDR-frequency-divider-0x0E-value-from-192-to-204-td22583796.html#a22583796 Thanks for your time - Richard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support
Chips supprted:-
1. 88E6161 6 port gbe swtich with 5 integrated PHYs
2. 88E6165 6 port gbe swtich with 5 integrated PHYs
Note: This driver is supported and tested against
kirkwood egiga interface, other interfaces can be added
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Reviewed by: Ronen Shitrit rshit...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Changelog:-
v2: updated as per review comments by Wolfgand Denk
removed other two drivers form earlier patch
debug_prints removed
driver moved to drivers/net/
drivers/net/Makefile|1 +
drivers/net/mv88e61xx.c | 291 +++
2 files changed, 292 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/mv88e61xx.c
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index f0c5654..7482327 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_MACB) += macb.o
COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
COBJS-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
+COBJS-$(CONFIG_SWITCH_MV88E61XX) += mv88e61xx.o
COBJS-$(CONFIG_NATSEMI) += natsemi.o
COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
diff --git a/drivers/net/mv88e61xx.c b/drivers/net/mv88e61xx.c
new file mode 100644
index 000..8167919
--- /dev/null
+++ b/drivers/net/mv88e61xx.c
@@ -0,0 +1,291 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor www.marvell.com
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+
+#if defined (CONFIG_SWITCH_MV88E61XX)
+
+/* Enabled ports can be enabled in board header file */
+#if defined (CONFIG_MV88E61XX_ENABLED_PORTS)
+#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS
+#else
+#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \
+ BIT3 | BIT4 | BIT5)
+#endif
+
+#if defined (CONFIG_88E6161)
+#define MV88E61XX_NAME 88E6161
+#elif defined (CONFIG_88E6165)
+#define MV88E61XX_NAME 88E6165
+#else
+#define MV88E61XX_NAME 88E61XX
+#endif
+
+#define MV88E61XX_PHY_TIMEOUT 10
+#define MV88E61XX_MAX_PORTS_NUM0x6
+/* CPU port can be configured in board header file */
+#if defined (CONFIG_MV88E61XX_CPU_PORT)
+#define MV88E61XX_CPU_PORT CONFIG_MV88E61XX_CPU_PORT
+#else
+#define MV88E61XX_CPU_PORT 0x5
+#endif
+
+#define MV88E61XX_PRT_STS_REG 0x1
+#define MV88E61XX_PRT_CTRL_REG 0x4
+#define MV88E61XX_PRT_VMAP_REG 0x6
+#define MV88E61XX_PRT_VID_REG 0x7
+
+#define MV88E61XX_PRT_OFST 0x10
+#define MV88E61XX_PHY_CMD 0x18
+#define MV88E61XX_PHY_DATA 0x19
+#define MV88E61XX_GLOBAL2_REG_DEVADR 0x1C
+
+#ifdef CONFIG_KIRKWOOD_EGIGA
+#define smi_wr_reg eth_smi_reg_write
+#define smi_rd_reg eth_smi_reg_read
+#else /* add new interface above this */
+#error Unsupported interface
+#endif
+
+/* Chip Address mode
+ * The Switch support two modes of operation
+ * 1. single chip mode and
+ * 2. Multi-chip mode
+ * Refer chip documentation for more details
+ *
+ * By default single chip mode is configured
+ * multichip mode operation can be configured in board header
+ */
+#ifndef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
+#define mv88e61xx_wr_phy smi_wr_reg
+#define mv88e61xx_rd_phy smi_rd_reg
+#else
+void mv88e61xx_wr_phy(u32 port, u32 phy_adr, u32 reg_ofs, u16 data)
+{
+ u16 reg;
+ u32 smi_dev_addr;
+
+ smi_dev_addr = KW_REG_READ(KW_ETH_PHY_ADDR_REG(port));
+ do {
+ smi_rd_reg(port, smi_dev_addr, 0x0, reg);
+ } while ((reg BIT15));
+ /* Poll till SMIBusy bit is clear */
+ smi_wr_reg(port, smi_dev_addr, 0x1, data);
+ /* Write data to Switch indirect data register */
+ smi_wr_reg(port, smi_dev_addr, 0x0,
+ reg_ofs | (phy_adr 5) | BIT10 | BIT12 | BIT15);
+ /* Write command to Switch indirect command register (write) */
+}
+
+void mv88e61xx_rd_phy(u32 port, u32 phy_adr, u32 reg_ofs, u16 * data)
+{
+
Re: [U-Boot] Data cache breaks U-Boot on ARM
On Wed, Apr 8, 2009 at 2:44 PM, Wolfgang Denk w...@denx.de wrote: Dear Drasko, please post U-Boot related questions on the mailing list Hi Wolfgang, sorry for sending e-mail to your private adress, it was metter of reply and not reply to all. Sorry for the misstake. Please see http://en.wikipedia.org/wiki/Memory_barrier Thank you very much for your time and help. With the pointers and examples you gave I corrected the code (it was problem of DCaching perpiheral device registers region, as you pointed out), and now it works fine and fast (after more than one week of torture)! Best regards, Drasko DRASKOVIC ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Data cache breaks U-Boot on ARM
Dear Drasko, in message 5ec3d7930904080651g5328ad12g3df2f28ae340...@mail.gmail.com you wrote: Thank you very much for your time and help. With the pointers and examples you gave I corrected the code (it was problem of DCaching perpiheral device registers region, as you pointed out), and now it works fine and fast (after more than one week of torture)! Great. Maybe you want to post your patches so others can benefit from that acchievement, too? Umm... is it correct to assume that you do not use USB on your system (resp. did not test USB yet) ? 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 Accident: A condition in which presence of mind is good, but absence of body is better. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Data cache breaks U-Boot on ARM
On Wed, Apr 8, 2009 at 5:00 PM, Wolfgang Denk w...@denx.de wrote: Great. Maybe you want to post your patches so others can benefit from that acchievement, too? It will be my pleasure, so I will take a look how can I make a usefull patch as soon as I clean the code. Umm... is it correct to assume that you do not use USB on your system (resp. did not test USB yet) ? It is corrrect, no USB used. Best Regards, Drasko DRASKOVIC ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] dtb merge
Any ideas on how to merge device tree binaries from slave devices ? Having a PowerPC based board with various extension boards on e.g. the local bus with each board having some kind of PROM device (I2C, SPI etc.) containing a dtb ... is it possible to merge this into the existing boards dtb into the local bus node ? Is it already working - have I missed it ? If not - is someone thinking/working on it ? Any suggestions on how to do it ? Regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dtb merge
Hi Andre, Andre Schwarz wrote: Any ideas on how to merge device tree binaries from slave devices ? Having a PowerPC based board with various extension boards on e.g. the local bus with each board having some kind of PROM device (I2C, SPI etc.) containing a dtb ... is it possible to merge this into the existing boards dtb into the local bus node ? Yes. Is it already working - have I missed it ? No - no. If not - is someone thinking/working on it ? We have thought about it, nobody is working on it that I am aware of. Any suggestions on how to do it ? See limited thoughts in http://www.denx.de/wiki/U-Boot/UBootFdtInfo 4. Proposed additional fdt commands * merge - merge two trees. Need a conflict resolution: source tree #1 has priority? o David Gibson has talked about creating a graft function for libfdt. Link to David's graft function thoughts: http://article.gmane.org/gmane.linux.ports.ppc64.devel/35740 Regards, Andre Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [resolved] UBIFS - Reading superblock error
Stefan Roese wrote: Hi Marcelo, On Tuesday 31 March 2009, DATACOM - Mallmann wrote: I'm trying to use UBI and UBIFS over a nand device. I want to create a mtd partition in u-boot (with ubi part command), save a ubifs image (with mkfs.ubifs), mount and load it with ubifs commands. The easiest way to write an UBIFS image in U-Boot is to generate an UBI image with includes the UBIFS volume. This is done after mkfs.ubifs using the ubinize command. This creates an UBI image which can be written to FLASH via the normal commands (cp.b for NOR, nand write for NAND). Here a link for some background: http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mkfubifs snip By the way, is a volume created in u-boot able to be used in linux kernel in read-write mode? Sure. You can write an UBIFS image in U-Boot and use it read-only here. And later in Linux you can mount it read-write and write to it. Next time in U-Boot you will see the changes. 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 = Hi Stefan, Thanks a lot for the tip. It works fine and pretty fast, like I expected. =D -- Marcelo MALLMANN Dias DATACOM Av.França,735-Porto Alegre,RS-90230-220 Fone 3358.1332 Fax 3358.0101 Site: www.datacom.ind.br e-mail: mallm...@datacom.ind.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
k...@koi8.net wrote: OK, this is _NOT_ just multiple I2C adapters... The entire thing is fundamentally broken. One supposed to have _THE_ device and only this device is somehow supported. Now it is USB. Each and every USB driver exports the same set of functions, submit_XXX_msg(...) That means there can be one and only one USB device in the system. [snip the badly scorched spot ;-)] USB keyboard is another grand kludge deserving its own chapter... As of now one can only switch to it from command line because USB is not even initialized until do_usb() from cmd_usb.c is called... What if we do NOT have a serial console at all? Dumb question because I have not looked seriously at the v2 fork of u-boot: how does the v2 fork handle this? Better? Since the v2 fork uses (or is close to) the linux driver model, I would expect it to be better. Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Data cache breaks U-Boot on ARM
Dear Drasko, in message 5ec3d7930904080854k2db159d3rc889ce80a8d0b...@mail.gmail.com you wrote: Umm... is it correct to assume that you do not use USB on your system (resp. did not test USB yet) ? It is corrrect, no USB used. Do you have USB on your board, so you can test it? I'm interested if USB still works for you with DCache on. Our experience is that you either have caches on *or* working USB on ARM, but this might be just a single case, so I'm interestedin other experiences. 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 Heavier than air flying machines are impossible. -- Lord Kelvin, President, Royal Society, c. 1895 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
On Wed, 8 Apr 2009, Jerry Van Baren wrote: k...@koi8.net wrote: OK, this is _NOT_ just multiple I2C adapters... The entire thing is fundamentally broken. One supposed to have _THE_ device and only this device is somehow supported. Now it is USB. Each and every USB driver exports the same set of functions, submit_XXX_msg(...) That means there can be one and only one USB device in the system. [snip the badly scorched spot ;-)] USB keyboard is another grand kludge deserving its own chapter... As of now one can only switch to it from command line because USB is not even initialized until do_usb() from cmd_usb.c is called... What if we do NOT have a serial console at all? Dumb question because I have not looked seriously at the v2 fork of u-boot: how does the v2 fork handle this? Better? Since the v2 fork uses (or is close to) the linux driver model, I would expect it to be better. Nothing's changed here... And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is stiff, inflexible, everything written in stone and that stone is permanently set in concrete. --- ** * 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] use of C99
Dear Kumar Gala, In message 4a0b9aaa-4714-4c27-84a7-22fce4d91...@freescale.com you wrote: I was wondering if there was any reason we avoid C99 features in u- boot source. Specifically the ability to declare variables in the middle of functions. One reason is that I consider such code extremely ugly and hard to read and understand. There are a slew of places that we have something like: ... #ifdef CONFIG_COOL_FEATURE u32 myvarrocks = foo * bar * bar; gd-neato = myvarrocks #endif It would be even better to avoid such #ifdef's, or at least the need for such special local variables. 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 Life is a process, not a principle, a mystery to be lived, not a problem to be solved. - Gerard Straub, television producer and author (stolen from Frank Herbert??) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Hi Wolfgang,
Wolfgang Denk wrote:
Dear Kumar Gala,
In message 4a0b9aaa-4714-4c27-84a7-22fce4d91...@freescale.com you wrote:
I was wondering if there was any reason we avoid C99 features in u-
boot source.
Specifically the ability to declare variables in the middle of
functions.
One reason is that I consider such code extremely ugly and hard to
read and understand.
ACK. I don't expect to see variables spring into life in the middle of
nowhere.
There are a slew of places that we have something like:
...
#ifdef CONFIG_COOL_FEATURE
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
#endif
It would be even better to avoid such #ifdef's, or at least the need
for such special local variables.
Sometimes (often?) that is impossible.
Best regards,
Wolfgang Denk
If I'm not confused, I've seen block-local u-boot variables, has the
advantages of being more distinctive and limits the lifetime of the
variable.
#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
}
#endif
Is this an acceptable compromise?
Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
Hi Jerry, On Wed, Apr 08, 2009 at 03:19:19PM -0400, Jerry Van Baren wrote: k...@koi8.net wrote: OK, this is _NOT_ just multiple I2C adapters... The entire thing is fundamentally broken. One supposed to have _THE_ device and only this device is somehow supported. Now it is USB. Each and every USB driver exports the same set of functions, submit_XXX_msg(...) That means there can be one and only one USB device in the system. [snip the badly scorched spot ;-)] USB keyboard is another grand kludge deserving its own chapter... As of now one can only switch to it from command line because USB is not even initialized until do_usb() from cmd_usb.c is called... What if we do NOT have a serial console at all? Dumb question because I have not looked seriously at the v2 fork of u-boot: how does the v2 fork handle this? Better? Since the v2 fork uses (or is close to) the linux driver model, I would expect it to be better. Right, we use something close to the driver model, so no problem with that in v2 land. Other than linux, we have per-device parameters. Example, with a freshly checked out tree: r...@thebe:u-boot-v2$ make sandbox_defconfig r...@thebe:u-boot-v2$ make r...@thebe:u-boot-v2$ ./scripts/ubootenv -s -p 0x1 examples/environment/ env.bin That gets you an u-boot-v2 (user mode u-boot) plus the example environment. Let's start it: r...@thebe:u-boot-v2-denx$ ./uboot -e env.bin add file env.bin() U-Boot 2.0.0-rc8-00084-g97568fd (Apr 8 2009 - 21:54:30) Board: sandbox Malloc space: 0xb761f008 - 0xb7e1f008 (size 8 MB) Open /dev/env0 Function not implemented running /env/bin/init... not found uboot:/ Let's check which devices we have: uboot:/ devinfo devices: |env0 |console0 |mem |eth0 |filesystem: / |filesystem: /dev drivers: console cfi_flash mem ram rom cramfs ramfs devfs hostfile Let's check what parameters are there: uboot:/ devinfo /dev/console0 base : 0x size : 0x driver: console no info available for console0 Parameters: active = ioe So you can have as many devices as you want, plus each device has parameters attached to it, so it's completely object oriented, without any global variable crap. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
On Wed, Apr 08, 2009 at 12:25:16PM -0700, k...@koi8.net wrote: On Wed, 8 Apr 2009, Jerry Van Baren wrote: k...@koi8.net wrote: OK, this is _NOT_ just multiple I2C adapters... The entire thing is fundamentally broken. One supposed to have _THE_ device and only this device is somehow supported. Now it is USB. Each and every USB driver exports the same set of functions, submit_XXX_msg(...) That means there can be one and only one USB device in the system. [snip the badly scorched spot ;-)] USB keyboard is another grand kludge deserving its own chapter... As of now one can only switch to it from command line because USB is not even initialized until do_usb() from cmd_usb.c is called... What if we do NOT have a serial console at all? Dumb question because I have not looked seriously at the v2 fork of u-boot: how does the v2 fork handle this? Better? Since the v2 fork uses (or is close to) the linux driver model, I would expect it to be better. Nothing's changed here... And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is stiff, inflexible, everything written in stone and that stone is permanently set in concrete. I suppose you didn't look in the right place. We don't even have support for i2c and spi in v2 :-) rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
On Wed, 8 Apr 2009, Robert Schwebel wrote: On Wed, Apr 08, 2009 at 12:25:16PM -0700, k...@koi8.net wrote: On Wed, 8 Apr 2009, Jerry Van Baren wrote: k...@koi8.net wrote: OK, this is _NOT_ just multiple I2C adapters... The entire thing is fundamentally broken. One supposed to have _THE_ device and only this device is somehow supported. Now it is USB. Each and every USB driver exports the same set of functions, submit_XXX_msg(...) That means there can be one and only one USB device in the system. [snip the badly scorched spot ;-)] USB keyboard is another grand kludge deserving its own chapter... As of now one can only switch to it from command line because USB is not even initialized until do_usb() from cmd_usb.c is called... What if we do NOT have a serial console at all? Dumb question because I have not looked seriously at the v2 fork of u-boot: how does the v2 fork handle this? Better? Since the v2 fork uses (or is close to) the linux driver model, I would expect it to be better. Nothing's changed here... And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is stiff, inflexible, everything written in stone and that stone is permanently set in concrete. I suppose you didn't look in the right place. We don't even have support for i2c and spi in v2 :-) Ah, that's that forked one! Sorry, my bad... I thought about the new version of a legacy one that just shuffled source files to put device drivers under devices/*... Can you tell me where it lives to clone the repository? I'd rather give up on v1 entirely because it is not going anywhere... Do you have a separate mailing list for v2? --- ** * 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] use of C99
On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren gerald.vanba...@ge.com wrote:
ACK. I don't expect to see variables spring into life in the middle of
nowhere.
I don't see what's wrong with that. The advantage is that the
variable is close to where it's being used, so that you can see the
context more easily.
If I'm not confused, I've seen block-local u-boot variables, has the
advantages of being more distinctive and limits the lifetime of the
variable.
I don't see what the value is of limiting the lifetime of the
variable. The compiler isn't going to use that as a hint, anyway.
It's just going to use this for syntax checking. If you define and
initialize a variable at the top of the function, but don't use that
variable until a hundred lines later, the compiler is going to
initialize the variable when it's first used, not when the function is
first entered. Chances are it's not even going to define stack space
for it.
#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
}
#endif
Is this an acceptable compromise?
This is what we do today, and I think it's ugly.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Query: console.c
Hi, While browsing common/console.c, I found 2 banners: - U-Boot INITIAL CONSOLE-NOT COMPATIBLE FUNCTIONS - U-Boot INITIAL CONSOLE-COMPATIBLE FUNCTION What does this indicate? One first pass, I also appeared that some functionality is duplicated e.g. serial_puts, puts, serial_printf, printf, et. Is there a specific reason for it? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
On Wed, Apr 08, 2009 at 01:18:45PM -0700, k...@koi8.net wrote: I suppose you didn't look in the right place. We don't even have support for i2c and spi in v2 :-) Ah, that's that forked one! Sorry, my bad... I thought about the new version of a legacy one that just shuffled source files to put device drivers under devices/*... Can you tell me where it lives to clone the repository? I'd rather give up on v1 entirely because it is not going anywhere... git clone git://www.denx.de/git/u-boot-v2 Do you have a separate mailing list for v2? No, just use this one. As long as the traffic keeps low, I suppose there is no need for a separate list. However, it's probably a good idea to have Sascha on Cc: :-) rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi
Sent: Thursday, April 09, 2009 1:55 AM
To: Jerry Van Baren
Cc: U-Boot-Users ML; Kumar Gala
Subject: Re: [U-Boot] use of C99
On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren
gerald.vanba...@ge.com wrote:
ACK. I don't expect to see variables spring into life in
the middle of
nowhere.
I don't see what's wrong with that. The advantage is that the
variable is close to where it's being used, so that you can see the
context more easily.
If I'm not confused, I've seen block-local u-boot variables, has the
advantages of being more distinctive and limits the lifetime of the
variable.
I don't see what the value is of limiting the lifetime of the
variable. The compiler isn't going to use that as a hint, anyway.
It's just going to use this for syntax checking. If you define and
initialize a variable at the top of the function, but don't use that
variable until a hundred lines later, the compiler is going to
initialize the variable when it's first used, not when the function is
first entered. Chances are it's not even going to define stack space
for it.
One of the biggest problem is uncontrolled variable definitions that
gets even nasty when variables have same names with different types;
though under different set of #ifdefs. Quite possible for commonly
used variable names - i, ptr, tmp, etc.
I feel, here, ifdefs provide a false sense of 'enclosure' with possibility
of frequent breaches - in code (while implementing) and in simple reading
(for understanding).
~sanjeev
#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
}
#endif
Is this an acceptable compromise?
This is what we do today, and I think it's ugly.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Timur Tabi wrote:
On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren gerald.vanba...@ge.com
wrote:
ACK. I don't expect to see variables spring into life in the middle of
nowhere.
I don't see what's wrong with that. The advantage is that the
variable is close to where it's being used, so that you can see the
context more easily.
Agreed. In many cases it reduces clutter by eliminating the need for
separate declaration and assignment.
I don't see what the value is of limiting the lifetime of the
variable.
It frees the variable up for later such blocks to use. As does
declaring iterators inside a for loop, but I guess that's forbidden as
well. :-)
It's just going to use this for syntax checking. If you define and
initialize a variable at the top of the function, but don't use that
variable until a hundred lines later, the compiler is going to
initialize the variable when it's first used, not when the function is
first entered. Chances are it's not even going to define stack space
for it.
Chances are it will allocate all stack space for all variables up front,
regardless of where they're declared.
#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
}
#endif
Is this an acceptable compromise?
This is what we do today, and I think it's ugly.
Yes. But not as ugly as having two #ifdef blocks.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Premi, Sanjeev wrote: One of the biggest problem is uncontrolled variable definitions that gets even nasty when variables have same names with different types; though under different set of #ifdefs. Quite possible for commonly used variable names - i, ptr, tmp, etc. Then let's just say that if you're going to define a variable in the middle of a function, it can't have the same name as another variable in that function. I feel, here, ifdefs provide a false sense of 'enclosure' with possibility of frequent breaches - in code (while implementing) and in simple reading (for understanding). Sorry, I don't understand what you're talking about. The #ifdefs are used to enable feature-specific code on platforms that have that feature. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Scott Wood wrote: It frees the variable up for later such blocks to use. As does declaring iterators inside a for loop, but I guess that's forbidden as well. :-) I'm not sure whether we want to allow the same variable to be defined more than once, even with the same type, inside a function. Chances are it will allocate all stack space for all variables up front, regardless of where they're declared. Yes, but it many cases it won't allocate any stack space at all because it will just keep the variable in a register. My point was that if a variable is defined later in a function, then it's more likely to have limited scope, so the compiler will be more likely to use a register instead of stack to store it. This is what we do today, and I think it's ugly. Yes. But not as ugly as having two #ifdef blocks. Agreed, but I don't consider it to be much of a compromise. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
On Wed, 8 Apr 2009, Robert Schwebel wrote: On Wed, Apr 08, 2009 at 01:18:45PM -0700, k...@koi8.net wrote: I suppose you didn't look in the right place. We don't even have support for i2c and spi in v2 :-) Ah, that's that forked one! Sorry, my bad... I thought about the new version of a legacy one that just shuffled source files to put device drivers under devices/*... Can you tell me where it lives to clone the repository? I'd rather give up on v1 entirely because it is not going anywhere... git clone git://www.denx.de/git/u-boot-v2 Do you have a separate mailing list for v2? No, just use this one. As long as the traffic keeps low, I suppose there is no need for a separate list. However, it's probably a good idea to have Sascha on Cc: :-) OK, thanks. Cloning now :) --- ** * 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] Multiple device support -- sorry state :(
On Wed, 8 Apr 2009, k...@koi8.net wrote: On Wed, 8 Apr 2009, Robert Schwebel wrote: On Wed, Apr 08, 2009 at 01:18:45PM -0700, k...@koi8.net wrote: I suppose you didn't look in the right place. We don't even have support for i2c and spi in v2 :-) Ah, that's that forked one! Sorry, my bad... I thought about the new version of a legacy one that just shuffled source files to put device drivers under devices/*... Can you tell me where it lives to clone the repository? I'd rather give up on v1 entirely because it is not going anywhere... git clone git://www.denx.de/git/u-boot-v2 Do you have a separate mailing list for v2? No, just use this one. As long as the traffic keeps low, I suppose there is no need for a separate list. However, it's probably a good idea to have Sascha on Cc: :-) OK, thanks. Cloning now :) OK, got a look at it. Looks promising but it is in very early stage yet... I wouldn't say in pre-conception stage, but definitely on a very beginning of the first trimester :) I have the first prototype of MPC8548E-based big motherboard sitting on my desk right now and it is in full bringup stage. All the hardware is checked, bunch of smoked parts replaced and fixed, all clocks are ticking, CPU fetching etc. I will definitely join V2 development but for now I'll probably make a huge set of horrible hacks over V1 to test everything and get my revision 2 started. Then I will be able to work on U-Boot V2 while my revision 2 is made (schematic rework, re-layout, PCB, missing parts sourcing, assembly etc.) --- ** * 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] use of C99
-Original Message- From: Timur Tabi [mailto:ti...@freescale.com] Sent: Thursday, April 09, 2009 2:28 AM To: Premi, Sanjeev Cc: Jerry Van Baren; U-Boot-Users ML; Kumar Gala Subject: Re: [U-Boot] use of C99 Premi, Sanjeev wrote: One of the biggest problem is uncontrolled variable definitions that gets even nasty when variables have same names with different types; though under different set of #ifdefs. Quite possible for commonly used variable names - i, ptr, tmp, etc. Then let's just say that if you're going to define a variable in the middle of a function, it can't have the same name as another variable in that function. I feel, here, ifdefs provide a false sense of 'enclosure' with possibility of frequent breaches - in code (while implementing) and in simple reading (for understanding). Sorry, I don't understand what you're talking about. The #ifdefs are used to enable feature-specific code on platforms that have that feature. I was referring to declaring variable within #ifdefs with belief that use will be contained. e.g. #ifdef CONFIG_COOL_FEATURE int i; int* ptr ; ... ... #endif ... ... 2 screenful down; in same function... ... #ifdef CONFIG_HOT_FEATURE u32 i; void* ptr; ... ... #endif Maybe for sometime the usage seems contained. Until someone decides to have both the COOL and HOT feature. ~sanjeev -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
-Original Message- From: Ben Warren [mailto:biggerbadder...@gmail.com] Sent: Thursday, April 09, 2009 2:33 AM To: Premi, Sanjeev Cc: Timur Tabi; Jerry Van Baren; U-Boot-Users ML; Kumar Gala Subject: Re: [U-Boot] use of C99 Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi Sent: Thursday, April 09, 2009 1:55 AM To: Jerry Van Baren Cc: U-Boot-Users ML; Kumar Gala Subject: Re: [U-Boot] use of C99 On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren gerald.vanba...@ge.com wrote: ACK. I don't expect to see variables spring into life in the middle of nowhere. I don't see what's wrong with that. The advantage is that the variable is close to where it's being used, so that you can see the context more easily. If I'm not confused, I've seen block-local u-boot variables, has the advantages of being more distinctive and limits the lifetime of the variable. I don't see what the value is of limiting the lifetime of the variable. The compiler isn't going to use that as a hint, anyway. It's just going to use this for syntax checking. If you define and initialize a variable at the top of the function, but don't use that variable until a hundred lines later, the compiler is going to initialize the variable when it's first used, not when the function is first entered. Chances are it's not even going to define stack space for it. One of the biggest problem is uncontrolled variable definitions that gets even nasty when variables have same names with different types; though under different set of #ifdefs. Quite possible for commonly used variable names - i, ptr, tmp, etc. I'm showing extreme ignorance here, but does C99 let you do this? for (int i = 0; i x ; i++) ? That's much better contained than declaring in a ifdef. Doing a lot of C++ has rotted my brain, but this is one thing I like. I love C++; still avoid declare as you go. Iterators (as you mention above) are only exception. ~sanjeev regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Dear Jerry Van Baren,
In message 49dcff1d.6080...@ge.com you wrote:
If I'm not confused, I've seen block-local u-boot variables, has the
advantages of being more distinctive and limits the lifetime of the
variable.
#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
}
#endif
Is this an acceptable compromise?
Yes, if really necessary, this can be done.
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
Of all the things I've lost, I miss my mind the most.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Dear Timur Tabi,
In message ed82fe3e0904081325s560fb99cg83b6aaa9176cd...@mail.gmail.com you
wrote:
I don't see what's wrong with that. The advantage is that the
variable is close to where it's being used, so that you can see the
context more easily.
Bear with an old man like me. I am used to the habit that variables
get decleared at the begin of a block, not in the middle of it. When
searching for the declaration of a variable, I find it a major PITA if
I have to scan the whole source file instea dof just looking at the
first few lines of a block.
I don't see what the value is of limiting the lifetime of the
variable. The compiler isn't going to use that as a hint, anyway.
Not the compiler, but humans like me. I have just a small window of
lines I can really focus on, and the smaller a block of code
(including the needed variable declarations), the easier I get the
impression I understand it.
It's just going to use this for syntax checking. If you define and
initialize a variable at the top of the function, but don't use that
variable until a hundred lines later, the compiler is going to
initialize the variable when it's first used, not when the function is
first entered. Chances are it's not even going to define stack space
for it.
Keep in mind that we don't write the code for the compiler, but for
the human being that comes after us and that has to maintain that
code.
#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
}
#endif
Is this an acceptable compromise?
This is what we do today, and I think it's ugly.
It is ugly, but much less ugly than variable declarations right in the
middle of 200 lines of 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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Premi, Sanjeev wrote: Maybe for sometime the usage seems contained. Until someone decides to have both the COOL and HOT feature. And that's why I said that U-Boot can allow in-function variable declarations, but all variables must have unique names. The only exception to that rule can be variables declared at the top of iterators. That's just my two cents. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple device support -- sorry state :(
On Wed, Apr 08, 2009 at 02:25:57PM -0700, k...@koi8.net wrote: OK, thanks. Cloning now :) OK, got a look at it. Looks promising but it is in very early stage yet... I wouldn't say in pre-conception stage, but definitely on a very beginning of the first trimester :) Well, you are free to send patches. We use it mainly for ARM systems which happen to be flash based (NAND, NOR), without PCI. So what was implemented was what we needed. No reason for you not to send us your favourite and fancy new features :-) I have the first prototype of MPC8548E-based big motherboard sitting on my desk right now and it is in full bringup stage. All the hardware is checked, bunch of smoked parts replaced and fixed, all clocks are ticking, CPU fetching etc. I will definitely join V2 development but for now I'll probably make a huge set of horrible hacks over V1 to test everything and get my revision 2 started. Then I will be able to work on U-Boot V2 while my revision 2 is made (schematic rework, re-layout, PCB, missing parts sourcing, assembly etc.) Go ahead, we definitely are looking forward to more community contribution. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Wolfgang Denk wrote: Bear with an old man like me. I am used to the habit that variables get decleared at the begin of a block, not in the middle of it. When searching for the declaration of a variable, I find it a major PITA if I have to scan the whole source file instea dof just looking at the first few lines of a block. This is why I use an advanced programmer's editor that brings me to the definition of the variable under the cursor with a single keystroke. Not the compiler, but humans like me. I have just a small window of lines I can really focus on, and the smaller a block of code (including the needed variable declarations), the easier I get the impression I understand it. In this case, it would be easier for you if the variable were declared next to the code that uses it. This is what we do today, and I think it's ugly. It is ugly, but much less ugly than variable declarations right in the middle of 200 lines of code. This is where I disagree. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Marvell MV88F6281GTW_GE Board support
On Wednesday 08 April 2009 12:18:11 Prafulla Wadaskar wrote: From: prafulla_wadaskar prafu...@marvell.com this part should be fixed as well -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] Multiple device support -- sorry state :(
On Wed, 8 Apr 2009, Robert Schwebel wrote: On Wed, Apr 08, 2009 at 02:25:57PM -0700, k...@koi8.net wrote: OK, thanks. Cloning now :) OK, got a look at it. Looks promising but it is in very early stage yet... I wouldn't say in pre-conception stage, but definitely on a very beginning of the first trimester :) Well, you are free to send patches. We use it mainly for ARM systems which happen to be flash based (NAND, NOR), without PCI. So what was implemented was what we needed. No reason for you not to send us your favourite and fancy new features :-) Sure I will :) Ah, ARM, my old love, still remeber that talk -- ldmia, stmfd... Romantic times, eh... I have the first prototype of MPC8548E-based big motherboard sitting on my desk right now and it is in full bringup stage. All the hardware is checked, bunch of smoked parts replaced and fixed, all clocks are ticking, CPU fetching etc. I will definitely join V2 development but for now I'll probably make a huge set of horrible hacks over V1 to test everything and get my revision 2 started. Then I will be able to work on U-Boot V2 while my revision 2 is made (schematic rework, re-layout, PCB, missing parts sourcing, assembly etc.) Go ahead, we definitely are looking forward to more community contribution. OK, I probably will. V1, IMHO, is beyond repair; I even contemplated forking off my own... --- ** * 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 3/3] smc911x: do net reset the chip if no EEPROM is connected
On Wednesday 08 April 2009 07:23:39 Daniel Mack wrote: On boards without EEPROMs, don't reset the chip on U-Boot's exit so that the MAC set by environment settings can be used by the OS later. that isnt how the MAC is passed to the OS ... this change is incorrect the OS must be able to get the MAC address regardless of the state of the network controller -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] use of C99
Timur Tabi wrote:
Scott Wood wrote:
It frees the variable up for later such blocks to use. As does
declaring iterators inside a for loop, but I guess that's forbidden as
well. :-)
I'm not sure whether we want to allow the same variable to be defined
more than once, even with the same type, inside a function.
What's wrong with this:?
for (i = 0; i n; i++) {
int j;
...
}
for (i = 0; i m; i++) {
int j;
...
}
Chances are it will allocate all stack space for all variables up front,
regardless of where they're declared.
Yes, but it many cases it won't allocate any stack space at all because
it will just keep the variable in a register. My point was that if a
variable is defined later in a function, then it's more likely to have
limited scope, so the compiler will be more likely to use a register
instead of stack to store it.
I don't think it will make a difference. The compiler knows what the
lifetime of the variable is, regardless of where you declare it.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Wolfgang Denk wrote: It is ugly, but much less ugly than variable declarations right in the middle of 200 lines of code. 200-line functions are ugly no matter what variable declaration style you use. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support
On Wed, Apr 8, 2009 at 1:30 PM, Prafulla Wadaskar prafu...@marvell.com wrote: Chips supprted:- 1. 88E6161 6 port gbe swtich with 5 integrated PHYs 2. 88E6165 6 port gbe swtich with 5 integrated PHYs Note: This driver is supported and tested against kirkwood egiga interface, other interfaces can be added We are going to be using this chip in a project, so I'm happy to see this code come by :-) A few comments sprinkled around below. Contributors: Yotam Admon yo...@marvell.com Michael Blostein michae...@marvell.com Reviewed by: Ronen Shitrit rshit...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Changelog:- v2: updated as per review comments by Wolfgand Denk It's always good to spell the name of the guy with commit access right :-) removed other two drivers form earlier patch debug_prints removed driver moved to drivers/net/ drivers/net/Makefile | 1 + drivers/net/mv88e61xx.c | 291 +++ 2 files changed, 292 insertions(+), 0 deletions(-) create mode 100644 drivers/net/mv88e61xx.c diff --git a/drivers/net/Makefile b/drivers/net/Makefile index f0c5654..7482327 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -47,6 +47,7 @@ COBJS-$(CONFIG_MACB) += macb.o COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o COBJS-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o +COBJS-$(CONFIG_SWITCH_MV88E61XX) += mv88e61xx.o COBJS-$(CONFIG_NATSEMI) += natsemi.o COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o diff --git a/drivers/net/mv88e61xx.c b/drivers/net/mv88e61xx.c new file mode 100644 index 000..8167919 --- /dev/null +++ b/drivers/net/mv88e61xx.c @@ -0,0 +1,291 @@ +/* + * (C) Copyright 2009 + * Marvell Semiconductor www.marvell.com + * Prafulla Wadaskar prafu...@marvell.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * 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 + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#include common.h + +#if defined (CONFIG_SWITCH_MV88E61XX) + +/* Enabled ports can be enabled in board header file */ +#if defined (CONFIG_MV88E61XX_ENABLED_PORTS) +#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS +#else +#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \ + BIT3 | BIT4 | BIT5) +#endif + +#if defined (CONFIG_88E6161) +#define MV88E61XX_NAME 88E6161 +#elif defined (CONFIG_88E6165) +#define MV88E61XX_NAME 88E6165 +#else +#define MV88E61XX_NAME 88E61XX +#endif + +#define MV88E61XX_PHY_TIMEOUT 10 +#define MV88E61XX_MAX_PORTS_NUM 0x6 +/* CPU port can be configured in board header file */ +#if defined (CONFIG_MV88E61XX_CPU_PORT) +#define MV88E61XX_CPU_PORT CONFIG_MV88E61XX_CPU_PORT +#else +#define MV88E61XX_CPU_PORT 0x5 +#endif + +#define MV88E61XX_PRT_STS_REG 0x1 +#define MV88E61XX_PRT_CTRL_REG 0x4 +#define MV88E61XX_PRT_VMAP_REG 0x6 +#define MV88E61XX_PRT_VID_REG 0x7 + +#define MV88E61XX_PRT_OFST 0x10 +#define MV88E61XX_PHY_CMD 0x18 +#define MV88E61XX_PHY_DATA 0x19 +#define MV88E61XX_GLOBAL2_REG_DEVADR 0x1C + +#ifdef CONFIG_KIRKWOOD_EGIGA +#define smi_wr_reg eth_smi_reg_write +#define smi_rd_reg eth_smi_reg_read +#else /* add new interface above this */ +#error Unsupported interface +#endif As far as I understand it, SMI for the 88E6161 is really just the physical MII layer with some changes in the register definitions. Would it not make more sense to use the existing u-boot miiphy code in common/miiphyutil.c to define the access functions? This allows for platform code to register mii access functions and gets platform specific stuff like this out of the driver. + +/* Chip Address mode + * The Switch support two modes of operation + * 1. single chip mode and + * 2. Multi-chip mode + * Refer chip documentation for more details + * + * By default single chip mode is configured + * multichip mode operation can be configured in board header + */ +#ifndef
Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support
Dear Andrew Dyer, In message c166aa9f0904081532r7583585esc5cdcc384382d...@mail.gmail.com you wrote: v2: updated as per review comments by Wolfgand Denk It's always good to spell the name of the guy with commit access right :-) He. I'm not Russell King. 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 This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
On Thu, Apr 9, 2009 at 7:38 AM, Timur Tabi ti...@freescale.com wrote: Wolfgang Denk wrote: Bear with an old man like me. I am used to the habit that variables get decleared at the begin of a block, not in the middle of it. When searching for the declaration of a variable, I find it a major PITA if I have to scan the whole source file instea dof just looking at the first few lines of a block. I'll second that This is why I use an advanced programmer's editor that brings me to the definition of the variable under the cursor with a single keystroke. What if _MY_ favourite editor doesn't. Or what if I don't have access to it because I'm looking at the code at work, or on a friends computer? Not the compiler, but humans like me. I have just a small window of lines I can really focus on, and the smaller a block of code (including the needed variable declarations), the easier I get the impression I understand it. That is the key - half the time #ifdef COOL_FEATURE in the middle of a function really means that the feature needs to be put in another function In this case, it would be easier for you if the variable were declared next to the code that uses it. True and correct, but it can often be done so in another function This is what we do today, and I think it's ugly. It is ugly, but much less ugly than variable declarations right in the middle of 200 lines of code. 200 lines of code is much more ugly Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Graeme Russ wrote: What if _MY_ favourite editor doesn't. The point I'm trying to make is that I have tools at my disposal that make certain tasks easier for me, allowing me to alter my coding style and get the best of both worlds. Or what if I don't have access to it because I'm looking at the code at work, or on a friends computer? Then it will be more difficult for you. I have this problem sometimes. That's why I try to avoid using another tool as much as possible. It's like complaining to someone who has a car that you only have a bicycle and you have to commute 20 miles to get to work. The person who has a car is obviously going to tell you that your life will be easier if you get a car also. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Dear Timur Tabi, In message 49dd290a.9010...@freescale.com you wrote: It's like complaining to someone who has a car that you only have a bicycle and you have to commute 20 miles to get to work. The person who has a car is obviously going to tell you that your life will be easier if you get a car also. The person with the bicycle might ask you why you require him to contribute to air pollution and climate changes and all these things when you could as well put the target he has to reach just 200 meters from his home. Not everything that can be done is a good thing to do. 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 Computers are not intelligent. They only think they are. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Wolfgang Denk wrote: Dear Timur Tabi, In message 49dd290a.9010...@freescale.com you wrote: It's like complaining to someone who has a car that you only have a bicycle and you have to commute 20 miles to get to work. The person who has a car is obviously going to tell you that your life will be easier if you get a car also. The person with the bicycle might ask you why you require him to contribute to air pollution and climate changes and all these things when you could as well put the target he has to reach just 200 meters from his home. Not everything that can be done is a good thing to do. Indeed, having the variable declaration close by to where it's used *does* make things easier. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support
On Wed, Apr 8, 2009 at 1:30 PM, Prafulla Wadaskar prafu...@marvell.com wrote: --- /dev/null +++ b/drivers/net/mv88e61xx.c @@ -0,0 +1,291 @@ +/* + * (C) Copyright 2009 + * Marvell Semiconductor www.marvell.com + * Prafulla Wadaskar prafu...@marvell.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * 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 + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#include common.h + +#if defined (CONFIG_SWITCH_MV88E61XX) + +/* Enabled ports can be enabled in board header file */ +#if defined (CONFIG_MV88E61XX_ENABLED_PORTS) +#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS +#else +#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \ + BIT3 | BIT4 | BIT5) +#endif + +#if defined (CONFIG_88E6161) +#define MV88E61XX_NAME 88E6161 +#elif defined (CONFIG_88E6165) +#define MV88E61XX_NAME 88E6165 +#else +#define MV88E61XX_NAME 88E61XX +#endif Is this discoverable at runtime? What if there's a system that supports using multiple different types of MV88E61xx? I know it's a bit of a crazy idea, but board designers like to screw around with software developers like that. + +#define MV88E61XX_PHY_TIMEOUT 10 +#define MV88E61XX_MAX_PORTS_NUM 0x6 Is this a limitation of the 88e61xx architecture, or just the max number on all of the currently shipping versions? + +#ifdef CONFIG_KIRKWOOD_EGIGA +#define smi_wr_reg eth_smi_reg_write +#define smi_rd_reg eth_smi_reg_read +#else /* add new interface above this */ +#error Unsupported interface +#endif This sort of thing is discouraged. Why does this driver need to know about the ethernet controller? Perhaps function pointers are needed? Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Marvell MV88E61XX Switch Driver support
Hi Prafulla, Prafulla Wadaskar wrote: Chips supprted:- 1. 88E6161 6 port gbe swtich with 5 integrated PHYs 2. 88E6165 6 port gbe swtich with 5 integrated PHYs Note: This driver is supported and tested against kirkwood egiga interface, other interfaces can be added Contributors: Yotam Admon yo...@marvell.com Michael Blostein michae...@marvell.com Reviewed by: Ronen Shitrit rshit...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Changelog:- v2: updated as per review comments by Wolfgand Denk removed other two drivers form earlier patch debug_prints removed driver moved to drivers/net/ drivers/net/Makefile|1 + drivers/net/mv88e61xx.c | 291 +++ 2 files changed, 292 insertions(+), 0 deletions(-) create mode 100644 drivers/net/mv88e61xx.c diff --git a/drivers/net/Makefile b/drivers/net/Makefile index f0c5654..7482327 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -47,6 +47,7 @@ COBJS-$(CONFIG_MACB) += macb.o COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o COBJS-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o +COBJS-$(CONFIG_SWITCH_MV88E61XX) += mv88e61xx.o Please change this to CONFIG_MV88E61XX_SWITCH COBJS-$(CONFIG_NATSEMI) += natsemi.o COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o diff --git a/drivers/net/mv88e61xx.c b/drivers/net/mv88e61xx.c new file mode 100644 index 000..8167919 --- /dev/null +++ b/drivers/net/mv88e61xx.c @@ -0,0 +1,291 @@ +/* + * (C) Copyright 2009 + * Marvell Semiconductor www.marvell.com + * Prafulla Wadaskar prafu...@marvell.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * 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 + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#include common.h + +#if defined (CONFIG_SWITCH_MV88E61XX) This is not needed - the makefile takes care of the conditional compilation + +/* Enabled ports can be enabled in board header file */ +#if defined (CONFIG_MV88E61XX_ENABLED_PORTS) +#define MV88E61XX_ENABLED_PORTS CONFIG_MV88E61XX_ENABLED_PORTS +#else +#define MV88E61XX_ENABLED_PORTS (BIT0 | BIT1 | BIT2 | \ + BIT3 | BIT4 | BIT5) +#endif + +#if defined (CONFIG_88E6161) +#define MV88E61XX_NAME 88E6161 +#elif defined (CONFIG_88E6165) +#define MV88E61XX_NAME 88E6165 +#else +#define MV88E61XX_NAME 88E61XX +#endif + There doesn't appear to be any code difference between the different chips. What's the point of differentiating them here? If it is meaningful, you should at least #warning if none of the known-about variants is mentioned. +#define MV88E61XX_PHY_TIMEOUT10 +#define MV88E61XX_MAX_PORTS_NUM 0x6 +/* CPU port can be configured in board header file */ +#if defined (CONFIG_MV88E61XX_CPU_PORT) +#define MV88E61XX_CPU_PORT CONFIG_MV88E61XX_CPU_PORT +#else +#define MV88E61XX_CPU_PORT 0x5 +#endif + +#define MV88E61XX_PRT_STS_REG0x1 +#define MV88E61XX_PRT_CTRL_REG 0x4 +#define MV88E61XX_PRT_VMAP_REG 0x6 +#define MV88E61XX_PRT_VID_REG0x7 + +#define MV88E61XX_PRT_OFST 0x10 +#define MV88E61XX_PHY_CMD0x18 +#define MV88E61XX_PHY_DATA 0x19 +#define MV88E61XX_GLOBAL2_REG_DEVADR 0x1C + +#ifdef CONFIG_KIRKWOOD_EGIGA +#define smi_wr_reg eth_smi_reg_write +#define smi_rd_reg eth_smi_reg_read +#else /* add new interface above this */ +#error Unsupported interface +#endif + Please find a better way to do this. Board-specific code doesn't belong in a driver. +/* Chip Address mode + * The Switch support two modes of operation + * 1. single chip mode and + * 2. Multi-chip mode + * Refer chip documentation for more details + * + * By default single chip mode is configured + * multichip mode operation can be configured in board header + */ +#ifndef CONFIG_MV88E61XX_MULTICHIP_ADRMODE +#define mv88e61xx_wr_phy smi_wr_reg +#define mv88e61xx_rd_phy smi_rd_reg +#else +void mv88e61xx_wr_phy(u32 port, u32 phy_adr, u32 reg_ofs,
Re: [U-Boot] use of C99
Kumar Gala wrote: I was wondering if there was any reason we avoid C99 features in u- boot source. Maybe the best reason is that the Linux kernel avoids them, and staying consistent with the Linux coding style saves a lot of time and headaches. IMO, this is worth the occasional clumsiness that results. BTW, the Linux kernel does not avoid all C99 features. For example, it relies heavily on named initialization of structs. However, AFAICT, it shuns those C99 feature that originated in C++. Best regards, Larry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Larry Johnson wrote: Kumar Gala wrote: I was wondering if there was any reason we avoid C99 features in u- boot source. Maybe the best reason is that the Linux kernel avoids them, Linux has a lot more inertia than a smaller project such as u-boot. and staying consistent with the Linux coding style saves a lot of time and headaches. IMO, this is worth the occasional clumsiness that results. Code seems to flow from Linux to u-boot more than the reverse -- I don't see much of a problem with being more permissive. BTW, the Linux kernel does not avoid all C99 features. For example, it relies heavily on named initialization of structs. However, AFAICT, it shuns those C99 feature that originated in C++. I suspect that has more to do with people's feelings toward C++ than any unbiased assessment of the merits of the features. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Premi, Sanjeev sez, I was referring to declaring variable within #ifdefs with belief that use will be contained. e.g. #ifdef CONFIG_COOL_FEATURE int i; int* ptr ; ... ... #endif ... ... 2 screenful down; in same function... ... #ifdef CONFIG_HOT_FEATURE u32 i; void* ptr; ... ... #endif Maybe for sometime the usage seems contained. Until someone decides to have both the COOL and HOT feature. Pops out of hole, looks at shadow, 6 more weeks till we ship... Um... my feeling is that if one is going to declare a variable inside a #ifdef then that variable ought to be called something like int indx_CONFIG_COOL_FEATURE and u32 indx_CONFIG_HOT_FEATURE Matt Harper Tehama Wireless ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
Pink Boy wrote: [snip] Pops out of hole, looks at shadow, 6 more weeks till we ship... Um... my feeling is that if one is going to declare a variable inside a #ifdef then that variable ought to be called something like int indx_CONFIG_COOL_FEATURE and u32 indx_CONFIG_HOT_FEATURE Matt Harper Tehama Wireless Ewww. Quoting from Documentation/CodingStyle: Chapter 4: Naming C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand. [snip] LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called i. Calling it loop_counter is non-productive, if there is no chance of it being mis-understood. Similarly, tmp can be just about any type of variable that is used to hold a temporary value. If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See chapter 6 (Functions). Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Which U-Boot releases have Device Tree support
We bought a MPC8360E-RDK development kit to develop applications under MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP that the U-Boot version that came with the development kit did not have device tree support. The consultant upgraded the U-Boot to a version that has device tree support, but he says he doesn't have the source code for the U-Boot version. I need the source to make certain updates. Which U-Boot version can I download that has device tree support? Thanks. Christopher M. Fairfax Sr. Software Engineer Rockwell Collins +1 540-428-3344 +1 540-428-3301 cmfai...@rockwellcollins.com This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee(s) named above. Any disclosure, distribution, copying or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Which U-Boot releases have Device Tree support
cmfai...@rockwellcollins.com wrote: We bought a MPC8360E-RDK development kit to develop applications under MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP that the U-Boot version that came with the development kit did not have device tree support. The consultant upgraded the U-Boot to a version that has device tree support, but he says he doesn't have the source code for the U-Boot version. I need the source to make certain updates. Which U-Boot version can I download that has device tree support? Thanks. Hi Christopher, The tip of the tree is the best. The mpc8360erdk is supported. If you want a released version, the latest is v2009.03. http://www.denx.de/wiki/U-Boot/ReleaseCycle Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On Wednesday 08 April 2009 20:08:38 Daniel Mack wrote: On Wed, Apr 08, 2009 at 06:00:40PM -0400, Mike Frysinger wrote: On Wednesday 08 April 2009 07:23:39 Daniel Mack wrote: On boards without EEPROMs, don't reset the chip on U-Boot's exit so that the MAC set by environment settings can be used by the OS later. that isnt how the MAC is passed to the OS ... this change is incorrect the OS must be able to get the MAC address regardless of the state of the network controller Not if the MAC is stored in the volatile smc911x registers. Issuing a soft reset flushes these values - if U-Boot does that, the OS has no change getting them. then either your u-boot or your OS is misconfigured and you need to fix that. as clearly stated in docs/README.enetaddr, the environment is the place where mac addresses live when there is no dedicated storage (like an eeprom). ignoring that, the mac address doesnt magically get programmed. if no network operation was initiated, then the part wouldnt have been programmed anyways, so you're still left with an OS that cant get itself functional. That's what I saw here and it is also stated in the datasheet. sounds like the driver and hardware is operating correctly then -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Which U-Boot releases have Device Tree support
On Wed, 2009-04-08 at 22:40 -0400, cmfai...@rockwellcollins.com wrote: We bought a MPC8360E-RDK development kit to develop applications under MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP that the U-Boot version that came with the development kit did not have device tree support. The consultant upgraded the U-Boot to a version that has device tree support, but he says he doesn't have the source code for the U-Boot version. I need the source to make certain updates. Which U-Boot version can I download that has device tree support? If you've registered your MPC8360E-RDK with Logic, you should be able to login to the Logic website and download the entire LTIB source that includes a version of u-boot with full source/patches that fully support dealing with device tree binary (dtb) files, and also includes a kernel for the MPC8360E-RDK, and the build process generates an appropriate device tree binary for the board... -- Peter Barada pet...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Which U-Boot releases have Device Tree support
On Apr 8, 2009, at 11:13 PM, Peter Barada wrote: On Wed, 2009-04-08 at 22:40 -0400, cmfai...@rockwellcollins.com wrote: We bought a MPC8360E-RDK development kit to develop applications under MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP that the U-Boot version that came with the development kit did not have device tree support. The consultant upgraded the U-Boot to a version that has device tree support, but he says he doesn't have the source code for the U-Boot version. I need the source to make certain updates. Which U-Boot version can I download that has device tree support? If you've registered your MPC8360E-RDK with Logic, you should be able to login to the Logic website and download the entire LTIB source that includes a version of u-boot with full source/patches that fully support dealing with device tree binary (dtb) files, and also includes a kernel for the MPC8360E-RDK, and the build process generates an appropriate device tree binary for the board... Additionally any recent u-boot (v2009.03) and kernel (v2.6.29) have in tree support for the RDK board. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
I'm glad to see I started this week's flame thread :) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB EHCI driver
Hi Francesco, Could you make any progress? Regards Maneesh -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Michael Trimarchi Sent: Monday, March 23, 2009 2:46 PM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, Rendine Francesco wrote: Hi, I've already tried that define, but nothing is changed... What can I see in the USB driver to resolve issue? Thanks. -Original Message- From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it] Sent: Fri 3/20/2009 9:36 AM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, FrancescoVT wrote: usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 dev=1ffebb08, pipe=8883, buffer=1f9a671a, length=64, req=1ffea214 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI fail timeout STD_ASS reset usb_new_device: usb_get_descriptor() failed #define CONFIG_LEGACY_USB_INIT_SEQ Michael Sorry I can't help you without the board :( and now I don't have another board to test to verify it. I'm working on android, and some migor issue. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Interrupt handlers in u-boot
hi, Thanks for that reply.I am right away checking those functions install_hdlr() and free_hdlr()..will get back about the results in few minutes.. Thanks Regards, Prathika R Stefan Roese wrote: On Wednesday 08 April 2009, prathika wrote: I am working on u-boot 1.1.6 version for PowerPC 440. First of all. v1.1.6 is really old. I suggest that you use the current (latest) version instead. I am using the hello world application from the examples folder. I had no issues in loading and executing it. Now I have enabled SPI interrupt in the application. I have written for SPI loopback. My issue is, as there is no interrupt handler defined for the SPI in uboot, whenever i execute my application, it says Masking bogus interrupt for Vector 0x08. I am calling install_irq_handler function for assigning my own interrupt handler for SPI as part of my application itself. I can understand that, there is no exclusive handler for SPI in uboot, so it is disabling the SPI interrupt and printing the BOGUS INTERRUPT message. Now how do I get rid of this and have my own interrupt handler?? You just need to install you own interrupt handler. This is done via install_hdlr(). See examples/interrupt.c. 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] use of C99
Dear Pink Boy, In message 139940.41801...@web31807.mail.mud.yahoo.com you wrote: Um... my feeling is that if one is going to declare a variable inside a #ifdef then that variable ought to be called something like int indx_CONFIG_COOL_FEATURE and u32 indx_CONFIG_HOT_FEATURE Then please read the Coding Style about how to chose variable names. 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 Imitation is the sincerest form of plagarism. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Which U-Boot releases have Device Tree support
Dear Peter Barada, In message 1239250418.4414.72.ca...@blackhole you wrote: On Wed, 2009-04-08 at 22:40 -0400, cmfai...@rockwellcollins.com wrote: We bought a MPC8360E-RDK development kit to develop applications under MontaVista CGE5.0. We were toldby the consultant whose doing our board LSP that the U-Boot version that came with the development kit did not have device tree support. The consultant upgraded the U-Boot to a version that has device tree support, but he says he doesn't have the source code for the U-Boot version. I need the source to make certain updates. Which U-Boot version can I download that has device tree support? If you've registered your MPC8360E-RDK with Logic, you should be able to login to the Logic website and download the entire LTIB source that includes a version of u-boot with full source/patches that fully support dealing with device tree binary (dtb) files, and also includes a kernel for the MPC8360E-RDK, and the build process generates an appropriate device tree binary for the board... On the other hand there is zero reason to stick with such an out-of-tree port when the board is supported in mainline. 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] USB EHCI driver
Hi, Gupta Maneesh-B18878 wrote: Hi Francesco, Could you make any progress? Regards Maneesh -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Michael Trimarchi Sent: Monday, March 23, 2009 2:46 PM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, Rendine Francesco wrote: Hi, I've already tried that define, but nothing is changed... What can I see in the USB driver to resolve issue? Thanks. -Original Message- From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it] Sent: Fri 3/20/2009 9:36 AM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, FrancescoVT wrote: usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 dev=1ffebb08, pipe=8883, buffer=1f9a671a, length=64, req=1ffea214 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI fail timeout STD_ASS reset usb_new_device: usb_get_descriptor() failed #define CONFIG_LEGACY_USB_INIT_SEQ Michael Sorry I can't help you without the board :( and now I don't have another board to test to verify it. I'm working on android, and some migor issue. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot I don't ask anymore because I'm busy, BTW good question Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
