Re: [U-Boot] [PATCH] OMAP3: Define 64bit vsprintf for NAND
This patch is obsolete now with http://git.denx.de/?p=u-boot.git;a=commit;h=2eb99ca8029b44c988d5f6312f97e68d3b9cb2bd Thanks Dirk Dirk Behme wrote: > With commit 8d2effea23e938631126a7888008a0637e13b389 "mtd: Update > MTD infrastructure to support 64bit device size" > CONFIG_SYS_64BIT_VSPRINTF needs to be defined to get correct output > and to remove annoying warning > > warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! > > Add CONFIG_SYS_64BIT_VSPRINTF to all OMAP3 configurations. > > Signed-off-by: Dirk Behme > > --- > > This patch is against recent mainline "MAINTAINERS: fix sorting, > remove duplicates." 3672cd5c3b53d219d33345eebad4e25ad5bf6d52. > > Compile tested with ./MAKEALL ARM_CORTEX_A8 and boot tested on > Beagle board. > > To be able to compile it independent of tool chain (libgcc) the > following patches were applied for this: > > http://lists.denx.de/pipermail/u-boot/2009-July/055599.html > http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=07a6acbe20357ebc2af36ac32e7029828d895a62 > http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e2a7f3af809f828878fe > > include/configs/omap3_beagle.h |1 + > include/configs/omap3_evm.h |1 + > include/configs/omap3_overo.h |1 + > include/configs/omap3_pandora.h |1 + > include/configs/omap3_zoom1.h |1 + > include/configs/omap3_zoom2.h |1 + > 6 files changed, 6 insertions(+) > > Index: omap3_patches/include/configs/omap3_zoom2.h > === > --- omap3_patches.orig/include/configs/omap3_zoom2.h > +++ omap3_patches/include/configs/omap3_zoom2.h > @@ -150,6 +150,7 @@ > * Board NAND Info. > */ > #define CONFIG_NAND_OMAP_GPMC > +#define CONFIG_SYS_64BIT_VSPRINTF > #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ > /* to access nand */ > #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ > Index: omap3_patches/include/configs/omap3_zoom1.h > === > --- omap3_patches.orig/include/configs/omap3_zoom1.h > +++ omap3_patches/include/configs/omap3_zoom1.h > @@ -129,6 +129,7 @@ > * Board NAND Info. > */ > #define CONFIG_NAND_OMAP_GPMC > +#define CONFIG_SYS_64BIT_VSPRINTF > #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ > /* to access nand */ > #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ > Index: omap3_patches/include/configs/omap3_evm.h > === > --- omap3_patches.orig/include/configs/omap3_evm.h > +++ omap3_patches/include/configs/omap3_evm.h > @@ -130,6 +130,7 @@ > /* > * Board NAND Info. > */ > +#define CONFIG_SYS_64BIT_VSPRINTF > #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ > /* to access nand */ > #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ > Index: omap3_patches/include/configs/omap3_pandora.h > === > --- omap3_patches.orig/include/configs/omap3_pandora.h > +++ omap3_patches/include/configs/omap3_pandora.h > @@ -122,6 +122,7 @@ > * Board NAND Info. > */ > #define CONFIG_NAND_OMAP_GPMC > +#define CONFIG_SYS_64BIT_VSPRINTF > #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ > /* to access nand */ > #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ > Index: omap3_patches/include/configs/omap3_beagle.h > === > --- omap3_patches.orig/include/configs/omap3_beagle.h > +++ omap3_patches/include/configs/omap3_beagle.h > @@ -133,6 +133,7 @@ > * Board NAND Info. > */ > #define CONFIG_NAND_OMAP_GPMC > +#define CONFIG_SYS_64BIT_VSPRINTF > #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ > /* to access nand */ > #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ > Index: omap3_patches/include/configs/omap3_overo.h > === > --- omap3_patches.orig/include/configs/omap3_overo.h > +++ omap3_patches/include/configs/omap3_overo.h > @@ -119,6 +119,7 @@ > * Board NAND Info. > */ > #define CONFIG_NAND_OMAP_GPMC > +#define CONFIG_SYS_64BIT_VSPRINTF > #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ > /* to access nand */ > #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ > ___ U-
Re: [U-Boot] [PATCH] - add dns
Dear Robin Getz, In message <200907172120.50413.rg...@blackfin.uclinux.org> you wrote: > On Fri 17 Jul 2009 16:55, Wolfgang Denk pondered: > > > Index: net/Makefile > > > === > > > --- net/Makefile (revision 1968) > > > +++ net/Makefile (working copy) > > > @@ -34,6 +34,7 @@ > > > COBJS-y += eth.o > > > COBJS-y += nfs.o > > > COBJS-$(CONFIG_CMD_SNTP) += sntp.o > > > +COBJS-$(CONFIG_CMD_DNS) += dns.o > > > > Please keep list sorted. > > sorted how? What we have today is: > > COBJS-y += net.o > COBJS-y += tftp.o > COBJS-y += bootp.o > COBJS-y += rarp.o > COBJS-y += eth.o > COBJS-y += nfs.o > COBJS-$(CONFIG_CMD_SNTP) += sntp.o > > It is not sorted alphabetically... ??? I see. Sorry. Well, please use the opportunity to sort that list, then. Alphabetically. > Seems to be sorted by date added, with the last ones on the bottom. Indeed. But that's not what I meant :-) Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add "cpu_config" command for PPC4xx bootstrap configuration
Dear Matthias Fuchs, In message <4a619c0f.20...@esd.eu> you wrote: > > When writing more bytes to an eeprom than it's actual pagesize you have > to take special care. This is done in eeprom_write(). i2c_write() to > an eeprom only works with up to pagesize bytes! > > Either we use eeprom_write() or we use multiple call of i2c_write(). > If we do not change this, Stefan's code does not work with 405EP cpus. > On these you have 0x20 strapping bytes and typicall EEPROMs with 8 or 16 > bytes pagesize (24W01/02/04/08/16). I see. So we should probably enable and export eeprom_write() in this case, and then use it. 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 Sex is like air. It's only a big deal if you can't get any. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] OMAP3 Fix compiler warning for v7_flush_dcache_all
Dear Dirk Behme, In message <4a62bc56.1060...@googlemail.com> you wrote: > > >> The functions v7_flush_dcache_all and get_device_type are declared > >> in include/asm-arm/arch-omap3/sys_proto.h, so use this file to > >> declare the functions. ... > > Applied, thanks. ... > I'm not sure, Tom will have the details, but there might be a newer > version of this patch? Yes, there is. I expect it to go in through the ARM repository. The part I pulled (adding "#include " for the needed prototypes) is still valid though: it fixes the current problem with the mainline code, and does not conflict with the future change coming (later?) from ARM either. 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 C++ is the best example of second-system effect since OS/360. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] I2C Add initial support for TWL4030
Dear Heiko, In message <1244638432-30893-3-git-send-email-tom@windriver.com> Tom Rix wrote: > The TWL4030 supplies many peripheral for OMAP3 boards. These include > power management, usb and, keyboard. > > The product description is found here: > > http://focus.ti.com/docs/prod/folders/print/tps65950.html > > Product reference document, tps65950.pdf, is found here: > > http://www.ti.com/lit/gpn/tps65950 > > Signed-off-by: Tom Rix > --- > drivers/i2c/Makefile |1 + > drivers/i2c/twl4030_i2c.c | 37 > include/twl4030.h | 221 > + > 3 files changed, 259 insertions(+), 0 deletions(-) > create mode 100644 drivers/i2c/twl4030_i2c.c > create mode 100644 include/twl4030.h I think this is supposed to go through the i2c repo, but I haven't seen any comments yet. Can you please check the state of this patch? Thanks in advance. 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 Philosophy is a game with objectives and no rules. Mathematics is a game with rules and no objectives. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the Tundra TSI148 VME-bridge
Dear Stefan Roese, In message <1244653780-615-1-git-send-email...@denx.de> you wrote: > From: Reinhard Arlt > > From: Reinhard Arlt > > This patch adds support for the Tundra TSI148 VME-bridge. It's used on > the upcoming esd VME8349 board. > > Signed-off-by: Reinhard Arlt > Signed-off-by: Stefan Roese > --- > common/Makefile |1 + > common/cmd_tsi148.c | 488 > +++ > include/tsi148.h| 218 +++ > 3 files changed, 707 insertions(+), 0 deletions(-) > create mode 100644 common/cmd_tsi148.c > create mode 100644 include/tsi148.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly dis- appear and be replaced by something even more bizarre and inexpli- cable. There is another theory which states that this has already happened.-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Canyonlands SATA harddisk driver
Dear Kazuaki Ichinohe,
In message <4a321b74.8040...@fsi.co.jp> you wrote:
> This patch adds a SATA harddisk driver for the canyonlands.
> This patch is kernel driver's porting.
> This patch corresponded to not cmd_scsi but cmd_sata.
> This patch divided an unused member with ifndef __U_BOOT__ in the structure.
>
> [environment variable, boot script]
> setenv bootargs root=/dev/sda7 rw
> setenv bootargs ${bootargs} console=ttyS0,115200
> ext2load sata 0:2 0x40 /canyonlands/uImage
> ext2load sata 0:2 0x80 /canyonlands/canyonlands.dtb
> fdt addr 0x80 0x4000
> bootm 0x40 - 0x80
>
> If you drive SATA-2 disk on Canyonlands, you must change parts from
> PI2PCIE212 to PI2PCIE2212 on U25. We confirmed to boot by using following
> disk.
>
> 1.Vender: Fujitsu Type: MHW2040BS
> 2.Vender: Fujitsu Type: MHW2060BK
> 3.Vendor: HAGIWARA SYS-COM:HFD25S-032GT
> 4.Vender: WesternDigital Type: WD3200BJKT (CONFIG_LBA48 required)
> 5.Vender: WesternDigital Type: WD3200BEVT (CONFIG_LBA48 required)
> 6.Vender: hitachi Type: HTS543232L9A300 (CONFIG_LBA48 required)
> 7.Vender: Seagate Type: ST31000333AS (CONFIG_LBA48 required)
> 8.Vender: Transcend Type: TS32GSSD25S-M
> 9.Vender: MTRON Type: MSD-SATA1525-016
>
> Signed-off-by: Kazuaki Ichinohe
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
War isn't a good life, but it's life.
-- Kirk, "A Private Little War", stardate 4211.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add inverted clock polarity support for Atmel LCD driver
> This definition in struct vidinfo for Atmel LCD
> /* LCD configuration register */
> u_long vl_sync; /* Horizontal / vertical sync */
> u_long vl_bpix; /* Bits per pixel, 0 = 1, 1 = 2, 2 = 4, 3 = 8,
>4 = 16 */
> u_long vl_tft; /* 0 = passive, 1 = TFT */
>
> is confusing. If these fields are supposed to contain flags
> for LCD configuration register LCDCON2 then we should define
> only one "u_long lcdcon2" field containing all the flags/fields
> for sync polarity, bpp, clock polarity, scan mode, display type,
> interface width, LCDD, LCDDEN polarities, LCDDOTCLK mode and memory
> ordering format. We are wasting tree u_longs here and are not even
> able to use half of the possible settings for LCDCON2 register.
> I would rather fix the struct vidinfo for Atmel LCD so that
> people could set needed flags in the board code, e.g.:
>
> vidinfo_t panel_info = {
> ...
> lcdcon2:ATMEL_LCDC_INVLINE_INVERTED |
> ATMEL_LCDC_INVFRAME_INVERTED |
> ATMEL_LCDC_INVCLK_INVERTED;
> ...
> }
I disagree here we must not make the panel_info atmel specific that way
we can add fields to pass atmel specific info which are pass via
struct atmel_lcdfb_info in Linux
But we need to be sync with linux as possible to simplify port and bugfix.
btw on Linux you do not specify it directly you specific this
FB_SYNC_HOR_HIGH_ACT=> ATMEL_LCDC_INVLINE_INVERTED
FB_SYNC_VERT_HIGH_ACT => ATMEL_LCDC_INVFRAME_INVERTED
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8]: Define test_and_set/clear_bit for ARM
On 15:58 Tue 07 Jul , Simon Kagstrom wrote: > Signed-off-by: Simon Kagstrom > --- > include/asm-arm/bitops.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > NACK the test_and_set_bit and co must be endianless specific which is not the case here rename it atomic_test_and_set_bit if you want but not test_and_set_bit Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8]: Move __set/clear_bit from ubifs.h to bitops.h
On 15:56 Tue 07 Jul , Simon Kagstrom wrote: > Move __set/clear_bit from ubifs.h to bitops.h > > __set_bit and __clear_bit are defined in ubifs.h as well as in > asm/include/bitops.h for some architectures. This patch moves > the generic implementation to include/linux/bitops.h and uses > that unless it's defined by the architecture. > > Signed-off-by: Simon Kagstrom > --- > fs/ubifs/ubifs.h | 32 > include/asm-avr32/bitops.h |3 +++ > include/asm-m68k/bitops.h |3 +++ > include/asm-nios/bitops.h |3 +++ > include/asm-nios2/bitops.h |3 +++ > include/asm-ppc/bitops.h |3 +++ > include/asm-sh/bitops.h|4 > include/asm-sparc/bitops.h |3 +++ > include/linux/bitops.h | 30 ++ IIRC it's not include/linux/bitops.h but include/asm-generic/bitops/non-atomic.h Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pcm030: fix out-of-tree building
Commit 0a87dd90 that was supposed to fix out-of-tree building for the
pcm030 board was unfortunately incomplete.
Signed-off-by: Wolfgang Denk
---
Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index e427bc0..1eb3177 100644
--- a/Makefile
+++ b/Makefile
@@ -696,6 +696,7 @@ o2dnt_config: unconfig
pcm030_config \
pcm030_LOWBOOT_config: unconfig
+ @mkdir -p $(obj)include $(obj)board/phytec/pcm030
@ >$(obj)include/config.h
@[ -z "$(findstring LOWBOOT_,$@)" ] || \
{ echo "TEXT_BASE = 0xFF00"
>$(obj)board/phytec/pcm030/config.tmp ; \
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c
This adds gpio and i2c support for the Nomadik evaluation kit. They are needed to turn on the LCD backlight in order to later add LCD support. I have one doubt and some questions on gpio: To use soft_i2c I need to define some macros in the config file. Instead of writing hard numbers there I called the gpio functions, but the config file is inluded from asm sources as well. I don't think my approach is beautiful at all (both #ifndef __ASSEMBLY__ and #include "../board/"), but I didn't find a better solution. I would like to add a gpio command, and I've found no generic gpio stuff. Only one board (cm-bf527) has a gpio commands, but quite a few have similar commands to set leds or other bits. Is time ripe for a generic gpio driver with board-specific limits and operations? Would that be interesting for u-boot-next? Should I process with a board-specific gpio command by now? /alessandro Alessandro Rubini (2): arm nomadik: add gpio support arm nomadik: add i2c board/st/nhk8815/Makefile |2 +- board/st/nhk8815/gpio.c| 99 board/st/nhk8815/gpio.h| 42 ++ board/st/nhk8815/nhk8815.c | 16 ++- include/configs/nhk8815.h | 18 - 5 files changed, 173 insertions(+), 4 deletions(-) create mode 100644 board/st/nhk8815/gpio.c create mode 100644 board/st/nhk8815/gpio.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm nomadik: add gpio support
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/Makefile |2 +-
board/st/nhk8815/gpio.c | 99 +
board/st/nhk8815/gpio.h | 42 +++
3 files changed, 142 insertions(+), 1 deletions(-)
create mode 100644 board/st/nhk8815/gpio.c
create mode 100644 board/st/nhk8815/gpio.h
diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile
index b37fe53..80a1ab6 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/st/nhk8815/Makefile
@@ -29,7 +29,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := nhk8815.o
+COBJS := nhk8815.o gpio.o
SOBJS := platform.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/st/nhk8815/gpio.c b/board/st/nhk8815/gpio.c
new file mode 100644
index 000..e0857b6
--- /dev/null
+++ b/board/st/nhk8815/gpio.c
@@ -0,0 +1,99 @@
+/*
+ * (C) Copyright 2009 Alessandro Rubini
+ *
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include "gpio.h"
+
+static unsigned long gpio_base[4] = {
+ NOMADIK_GPIO0_BASE,
+ NOMADIK_GPIO1_BASE,
+ NOMADIK_GPIO2_BASE,
+ NOMADIK_GPIO3_BASE
+};
+
+enum gpio_registers {
+ GPIO_DAT = 0x00, /* data register */
+ GPIO_DATS = 0x04, /* data set */
+ GPIO_DATC = 0x08, /* data clear */
+ GPIO_PDIS = 0x0c, /* pull disable */
+ GPIO_DIR = 0x10, /* direction */
+ GPIO_DIRS = 0x14, /* direction set */
+ GPIO_DIRC = 0x18, /* direction clear */
+ GPIO_AFSLA =0x20, /* alternate function select A */
+ GPIO_AFSLB =0x24, /* alternate function select B */
+};
+
+static inline unsigned long gpio_to_base(int gpio)
+{
+ return gpio_base[gpio / 32];
+}
+
+static inline u32 gpio_to_bit(int gpio)
+{
+ return 1 << (gpio & 0x1f);
+}
+
+void nmk_gpio_af(int gpio, int alternate_function)
+{
+ unsigned long base = gpio_to_base(gpio);
+ u32 bit = gpio_to_bit(gpio);
+ u32 afunc, bfunc;
+
+ /* alternate function is 0..3, with one bit per register */
+ afunc = readl(base + GPIO_AFSLA) & ~bit;
+ bfunc = readl(base + GPIO_AFSLB) & ~bit;
+ if (alternate_function & 1) afunc |= bit;
+ if (alternate_function & 2) bfunc |= bit;
+ writel(afunc, base + GPIO_AFSLA);
+ writel(bfunc, base + GPIO_AFSLB);
+}
+
+void nmk_gpio_dir(int gpio, int dir)
+{
+ unsigned long base = gpio_to_base(gpio);
+ u32 bit = gpio_to_bit(gpio);
+
+ if (dir)
+ writel(bit, base + GPIO_DIRS);
+ else
+ writel(bit, base + GPIO_DIRC);
+}
+
+void nmk_gpio_set(int gpio, int val)
+{
+ unsigned long base = gpio_to_base(gpio);
+ u32 bit = gpio_to_bit(gpio);
+
+ if (val)
+ writel(bit, base + GPIO_DATS);
+ else
+ writel(bit, base + GPIO_DATC);
+}
+
+int nmk_gpio_get(int gpio)
+{
+ unsigned long base = gpio_to_base(gpio);
+ u32 bit = gpio_to_bit(gpio);
+
+ return readl(base + GPIO_DAT) & bit;
+}
diff --git a/board/st/nhk8815/gpio.h b/board/st/nhk8815/gpio.h
new file mode 100644
index 000..1d3c9ce
--- /dev/null
+++ b/board/st/nhk8815/gpio.h
@@ -0,0 +1,42 @@
+/*
+ * (C) Copyright 2009 Alessandro Rubini
+ *
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifnde
[U-Boot] [PATCH 2/2] arm nomadik: add i2c
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/nhk8815.c | 16 ++--
include/configs/nhk8815.h | 18 +-
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index 085a5e0..2215ef9 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -27,6 +27,7 @@
#include
#include
+#include "gpio.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -61,9 +62,20 @@ int board_init(void)
return 0;
}
-int misc_init_r(void)
+int board_late_init(void)
{
- setenv("verify", "n");
+ /* Set the two I2C gpio lines to be gpio high */
+ nmk_gpio_set(__SCL, 1); nmk_gpio_set(__SDA, 1);
+ nmk_gpio_dir(__SCL, 1); nmk_gpio_dir(__SDA, 1);
+ nmk_gpio_af(__SCL, GPIO_GPIO); nmk_gpio_af(__SDA, GPIO_GPIO);
+
+ /* Reset the I2C port expander, on GPIO77 */
+ nmk_gpio_af(77, GPIO_GPIO);
+ nmk_gpio_dir(77, 1);
+ nmk_gpio_set(77, 0);
+ udelay(10);
+ nmk_gpio_set(77, 1);
+
return 0;
}
diff --git a/include/configs/nhk8815.h b/include/configs/nhk8815.h
index 3e2e09f..165d465 100644
--- a/include/configs/nhk8815.h
+++ b/include/configs/nhk8815.h
@@ -93,7 +93,7 @@
#define CONFIG_SYS_GBL_DATA_SIZE 128 /* for initial data */
#define CONFIG_SYS_64BIT_VSPRINTF /* mtd desires this */
-#define CONFIG_MISC_INIT_R /* call misc_init_r during start up */
+#define BOARD_LATE_INIT/* call board_late_init during start up
*/
/* timing informazion */
#define CONFIG_SYS_HZ 1000 /* Mandatory... */
@@ -110,6 +110,22 @@
#define CONFIG_PL01x_PORTS { (void *)CFG_SERIAL0, (void *)CFG_SERIAL1 }
#define CONFIG_PL011_CLOCK 4800
+/* i2c, for the port extenders (uses gpio.c in board directory) */
+#ifndef __ASSEMBLY__
+#include "../board/st/nhk8815/gpio.h"
+#define CONFIG_CMD_I2C
+#define CONFIG_SOFT_I2C
+#define CONFIG_SYS_I2C_SPEED 40
+#define __SDA 63
+#define __SCL 62
+#define I2C_SDA(x) nmk_gpio_set(__SDA, x)
+#define I2C_SCL(x) nmk_gpio_set(__SCL, x)
+#define I2C_READ (nmk_gpio_get(__SDA)!=0)
+#define I2C_ACTIVE nmk_gpio_dir(__SDA, 1)
+#define I2C_TRISTATE nmk_gpio_dir(__SDA, 0)
+#define I2C_DELAY (udelay(2))
+#endif /* __ASSEMBLY__ */
+
/* Ethernet */
#define PCI_MEMORY_VADDR 0xe800
#define PCI_IO_VADDR 0xee00
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add "cpu_config" command for PPC4xx bootstrap configuration
Stefan, On Sunday 19 July 2009 09:55:10 Wolfgang Denk wrote: > Dear Matthias Fuchs, > > In message <4a619c0f.20...@esd.eu> you wrote: > > When writing more bytes to an eeprom than it's actual pagesize you have > > to take special care. This is done in eeprom_write(). i2c_write() to > > an eeprom only works with up to pagesize bytes! > > > > Either we use eeprom_write() or we use multiple call of i2c_write(). > > If we do not change this, Stefan's code does not work with 405EP cpus. > > On these you have 0x20 strapping bytes and typicall EEPROMs with 8 or 16 > > bytes pagesize (24W01/02/04/08/16). > > I see. So we should probably enable and export eeprom_write() in this > case, and then use it. I see no other way. Stefan, could you then please also a a further CONFIG option "CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET" to give a starting address of the bootstrap data inside the EEPROM other than 0. On some 4xx CPUs you can select between different EEPROM offsets by external CPU pins. So bootstrap data could start at an address other than 0. It could also be helpful to pass this address somehow to the cpu_config during runtime. Let's say you have a 405EP based PCI adapter board that my use 33 or 66MHZ PCI clock dependant from the PCI M66EN signal. You could use that signal to make the bootstrap controller select between two configurations. In this case to have to call cpu_config on two EEPROM ranges with diffenrent arguments. But to get cpu_config finally done, please add the _OFFSET option and I am happy. It could have a default of 0. Matthias > > Best regards, > > Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8]: Define test_and_set/clear_bit for ARM
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090719094713.ge31...@game.jcrosoft.org> you wrote: > On 15:58 Tue 07 Jul , Simon Kagstrom wrote: > > Signed-off-by: Simon Kagstrom > > --- > > include/asm-arm/bitops.h |4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > NACK > > the test_and_set_bit and co must be endianless specific > which is not the case here > > rename it atomic_test_and_set_bit if you want but not test_and_set_bit Please explain. What has atomicity dto do with the fact if the implementation depends on the byte order or not? I agree that such macros should be independet of the byteorder, but this applies to test_and_set_bit as well as to atomic_test_and_set_bit - why should adding "atomic_" here make such a difference? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I am a computer. I am dumber than any human and smarter than any ad- ministrator. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to reduce size of U-Boot image (i.MX31, NAND-Flash)
Hello, I'm trying to optimize the u-boot image I get after compiling. It's size is 13XkB depending on the features I define. I'm using a i.MX31 processor and only NAND-Flash. I think it should be possible to get a smaller Image. Are there some common tricks, or do you have some suggestions how to reduce the size of u-boot? Thanks in advance. Best Regards Ulrich Gerster ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_onenand: fix compiler warning for error message
From: Alessandro Rubini
Since env_addr is a loff_t (long long), "%08lx" is not a good format;
this uses "%08llx" (not "%016llx"), to get 8 or more hex digits. I
tnknk padding to 8 digits makes things more readable for "small"
numbers, and the unlikely values over 4GB are reported correctly
anyways.
Signed-off-by: Alessandro Rubini
---
I found this during "./MAKEALL arm", and it affects my nhk8815 as
well. The warning was already reported today by Dirk Behme, thus this is
reply to his message.
common/env_onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/env_onenand.c b/common/env_onenand.c
index 476fdbc..0b03537 100644
--- a/common/env_onenand.c
+++ b/common/env_onenand.c
@@ -101,7 +101,7 @@ int saveenv(void)
instr.addr = env_addr;
instr.mtd = mtd;
if (mtd->erase(mtd, &instr)) {
- printf("OneNAND: erase failed at 0x%08lx\n", env_addr);
+ printf("OneNAND: erase failed at 0x%08llx\n", (u64)env_addr);
return 1;
}
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] I2C Add initial support for TWL4030
Hello Wolfgang, Wolfgang Denk wrote: > In message <1244638432-30893-3-git-send-email-tom@windriver.com> Tom Rix > wrote: >> The TWL4030 supplies many peripheral for OMAP3 boards. These include >> power management, usb and, keyboard. >> >> The product description is found here: >> >> http://focus.ti.com/docs/prod/folders/print/tps65950.html >> >> Product reference document, tps65950.pdf, is found here: >> >> http://www.ti.com/lit/gpn/tps65950 >> >> Signed-off-by: Tom Rix >> --- >> drivers/i2c/Makefile |1 + >> drivers/i2c/twl4030_i2c.c | 37 >> include/twl4030.h | 221 >> + >> 3 files changed, 259 insertions(+), 0 deletions(-) >> create mode 100644 drivers/i2c/twl4030_i2c.c >> create mode 100644 include/twl4030.h > > I think this is supposed to go through the i2c repo, but I haven't > seen any comments yet. Hmm.. there are responses, see for example: http://lists.denx.de/pipermail/u-boot/2009-June/054086.html > Can you please check the state of this patch? Thanks in advance. Hmm.. it is a little long to follow this ... it ended first here: http://lists.denx.de/pipermail/u-boot/2009-June/054654.html waiting for an Ack that it works on omap2 ... (I Acked the resulting 3 patches, see: http://lists.denx.de/pipermail/u-boot/2009-June/054585.html ) Ah, found one more answer from Tom: http://lists.denx.de/pipermail/u-boot/2009-June/054801.html ended in: http://lists.denx.de/pipermail/u-boot/2009-June/055071.html with a new patchset of 6 patches, starting with: http://lists.denx.de/pipermail/u-boot/2009-June/055072.html but state of omap2 is still pending ... see: http://lists.denx.de/pipermail/u-boot/2009-June/055087.html then Tom wrote, he has setup a git repo, see: http://lists.denx.de/pipermail/u-boot/2009-July/055328.html but I think, the state of the omap2 is pending ... so I (and I think Jean-Christophe also) wait for, that this pending state is going away ... Tom, do you have an update? (added Jean-Christophe to cc:) bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch] bootelf should allow arguments passing to called program
The bootelf command is written to pass the command line arguments to the called program, but the command list entry limits the number of arguments to 2 (including the command itself and the image address). Changing the command list entry allows passing command line arguments to the called program. Signed-off-by: Thomas Doerfler --- diff --git a/common/cmd_elf.c b/common/cmd_elf.c index abec7dd..e67938f 100644 --- a/common/cmd_elf.c +++ b/common/cmd_elf.c @@ -311,9 +311,10 @@ unsigned long load_elf_image (unsigned long addr) /* == */ U_BOOT_CMD( - bootelf, 2, 0, do_bootelf, + bootelf,CONFIG_SYS_MAXARGS, 0, do_bootelf, "Boot from an ELF image in memory", - " [address] - load address of ELF image." + " [address] [arg ...] - load address of ELF image.\n" + " passing 'arg' as arguments" ); U_BOOT_CMD( --- Embedded Brains GmbH Thomas DoerflerObere Lagerstrasse 30 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Bugfix: mpc512x_fec MII accesses fail after ethernet transfers
The mpc512x FEC network driver resets the FEC before transferring
packets. With this reset, the FEC clears the previous setting of MII
transfer speed. This patch ensures, that it is set again to a reasonable
value after a FEC reset.
Signed-off-by: Thomas Doerfler
--
diff --git a/drivers/net/mpc512x_fec.c b/drivers/net/mpc512x_fec.c
index fb2c19a..f3d76ba 100644
--- a/drivers/net/mpc512x_fec.c
+++ b/drivers/net/mpc512x_fec.c
@@ -446,6 +446,19 @@ static void mpc512x_fec_halt (struct eth_device *dev)
* wait at least 16 clock cycles
*/
udelay (10);
+ /*
+* NOTE: reset will also clear the MII speed register
+* we should reinitialize it ASAP
+*/
+ if (fec->xcv_type != SEVENWIRE) {
+ /*
+* Set MII_SPEED = (1/(mii_speed * 2)) * System Clock
+* and do not drop the Preamble.
+*/
+ fec->eth->mii_speed = gd->ips_clk / 100) / 5)
+ + 1)
+ << 1);
+ }
#if (DEBUG & 0x3)
printf ("Ethernet task stopped\n");
#endif
--
Embedded Brains GmbH
Thomas DoerflerObere Lagerstrasse 30
D-82178 Puchheim Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18908079-2
Fax: +49-89-18908079-9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: move extern declarations from C to headers
From: Alessandro Rubini
This moves some extern declaration from lcd.c to lcd.h, removing
unneeded ifdef around a pair of them. Additionally, since
gunzip_bmp() was declared static in cmd_bmp.c but extern in lcd.c, I
removed the static. The extra "#include " in cmd_bmp.c is
added to ensure the header is consistent with the source.
This has been compile-tested on both ARM (at91 boards) and PowerPC
(HH405_config, TQM823L_LCD_config, mcc200_config), to test all use
combinations.
Signed-off-by: Alessandro Rubini
---
common/cmd_bmp.c |5 +++--
common/lcd.c | 16
include/lcd.h| 12
3 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index fc8462e..faa10a4 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -26,6 +26,7 @@
*/
#include
+#include
#include
#include
#include
@@ -46,7 +47,7 @@ int gunzip(void *, int, unsigned char *, unsigned long *);
* didn't contain a valid BMP signature.
*/
#ifdef CONFIG_VIDEO_BMP_GZIP
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
void *dst;
unsigned long len;
@@ -85,7 +86,7 @@ static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned
long *lenp)
return bmp;
}
#else
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
return NULL;
}
diff --git a/common/lcd.c b/common/lcd.c
index c87de0b..dc8fea6 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -79,25 +79,13 @@ static inline void lcd_putc_xy (ushort x, ushort y, uchar
c);
static int lcd_init (void *lcdbase);
static int lcd_clear (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[]);
-extern void lcd_ctrl_init (void *lcdbase);
-extern void lcd_enable (void);
static void *lcd_logo (void);
-
-#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16)
-extern void lcd_setcolreg (ushort regno,
- ushort red, ushort green, ushort blue);
-#endif
-#if LCD_BPP == LCD_MONOCHROME
-extern void lcd_initcolregs (void);
-#endif
-
static int lcd_getbgcolor (void);
static void lcd_setfgcolor (int color);
static void lcd_setbgcolor (int color);
char lcd_is_enabled = 0;
-extern vidinfo_t panel_info;
#ifdef NOT_USED_SO_FAR
static void lcd_getcolreg (ushort regno,
@@ -815,10 +803,6 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
#endif
-#ifdef CONFIG_VIDEO_BMP_GZIP
-extern bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp);
-#endif
-
static void *lcd_logo (void)
{
#ifdef CONFIG_SPLASH_SCREEN
diff --git a/include/lcd.h b/include/lcd.h
index f054cac..2de36ab 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -43,6 +43,18 @@ extern void *lcd_console_address;/* Start of console
buffer */
extern short console_col;
extern short console_row;
+extern struct vidinfo panel_info;
+
+extern void lcd_ctrl_init (void *lcdbase);
+extern void lcd_enable (void);
+
+/* setcolreg used in 8bpp/16bpp; initcolregs used in monochrome */
+extern void lcd_setcolreg (ushort regno,
+ ushort red, ushort green, ushort blue);
+extern void lcd_initcolregs (void);
+
+/* gunzip_bmp used if CONFIG_VIDEO_BMP_GZIP */
+extern struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp);
#if defined CONFIG_MPC823
/*
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - add dns
On Sun 19 Jul 2009 03:48, Wolfgang Denk pondered: > Dear Robin Getz, > In message <200907172120.50413.rg...@blackfin.uclinux.org> you wrote: > > On Fri 17 Jul 2009 16:55, Wolfgang Denk pondered: > > > Please keep list sorted. > > > > sorted how? What we have today is: > > > > COBJS-y += net.o > > COBJS-y += tftp.o > > COBJS-y += bootp.o > > COBJS-y += rarp.o > > COBJS-y += eth.o > > COBJS-y += nfs.o > > COBJS-$(CONFIG_CMD_SNTP) += sntp.o > > > > It is not sorted alphabetically... ??? > > I see. Sorry. Well, please use the opportunity to sort that list, > then. Alphabetically. > Ok -- what I have is this then. I'll wrap it up tomorrow and send to Ben, assuming he doesn't have anything else... diff --git a/net/Makefile b/net/Makefile index d341874..835a04a 100644 --- a/net/Makefile +++ b/net/Makefile @@ -27,13 +27,14 @@ include $(TOPDIR)/config.mk LIB= $(obj)libnet.a -COBJS-y += net.o -COBJS-y += tftp.o COBJS-y += bootp.o -COBJS-y += rarp.o +COBJS-$(CONFIG_CMD_DNS) += dns.o COBJS-y += eth.o +COBJS-y += net.o COBJS-y += nfs.o +COBJS-y += rarp.o COBJS-$(CONFIG_CMD_SNTP) += sntp.o +COBJS-y += tftp.o COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_flash.c: fix compile error for boards with DataFlash
From: Alessandro Rubini
The local variables addr_first and addr_last are used if HAS_DATAFLASH
even if SYS_NO_FLASH (meaning no NOR flash). This adds the definitions
withing the brace where the names are used, to avoid cluttering the
initial ifdef.
Signed-off-by: Alessandro Rubini
---
5 boards were not compiling with "./MAKEALL arm", now they all work.
Actually, even at91sam9263ek_nandflash_config was in error, but it's
not one of the MAKEALL targets. Should MAKEALL test all possible configs or not?
common/cmd_flash.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/cmd_flash.c b/common/cmd_flash.c
index bc651fa..4f12bbc 100644
--- a/common/cmd_flash.c
+++ b/common/cmd_flash.c
@@ -496,6 +496,8 @@ int do_protect (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
#ifdef CONFIG_HAS_DATAFLASH
if ((strcmp(argv[2], "all") != 0) && (strcmp(argv[2], "bank") != 0)) {
+ ulong addr_first, addr_last;
+
addr_first = simple_strtoul(argv[2], NULL, 16);
addr_last = simple_strtoul(argv[3], NULL, 16);
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add "cpu_config" command for PPC4xx bootstrap configuration
On Sunday 19 July 2009 13:23:49 Matthias Fuchs wrote: > > > Either we use eeprom_write() or we use multiple call of i2c_write(). > > > If we do not change this, Stefan's code does not work with 405EP cpus. > > > On these you have 0x20 strapping bytes and typicall EEPROMs with 8 or > > > 16 bytes pagesize (24W01/02/04/08/16). > > > > I see. So we should probably enable and export eeprom_write() in this > > case, and then use it. > > I see no other way. > > Stefan, could you then please also a a further CONFIG option > "CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET" to give a starting address of the > bootstrap data inside the EEPROM other than 0. On some 4xx CPUs you can > select between different EEPROM offsets by external CPU pins. So bootstrap > data could start at an address other than 0. It could also be helpful to > pass this address somehow to the cpu_config during runtime. Let's say you > have a 405EP based PCI adapter board that my use 33 or 66MHZ PCI clock > dependant from the PCI M66EN signal. You could use that signal to make the > bootstrap controller select between two configurations. In this case to > have to call cpu_config on two EEPROM ranges with diffenrent arguments. > > But to get cpu_config finally done, please add the _OFFSET option and I am > happy. It could have a default of 0. OK, I'll try wrap up a new patch version tomorrow which uses eeprom_write() if available and this new ..._EEPROM_OFFSET define. And then let's please get this patch in. We can always add functionality later on. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] I2C Add initial support for TWL4030
Omap2 is still pending. I was hoping to help Richard out with this last week but he was on travel. There is not much more I think I can do wrt omap2. All my targets are omap3. The nearest I can find online is the nokia n8xx which uses a another bootloader. The options as I see them are. 1. Get a pass on omap2 testing 2. Rewrite i2c init to have a omap3 specific init 3. Hack n8xx and try to convience you the results are reasonable 4. Wait for omap2 testing. I vote for #1. Tom Heiko Schocher wrote: > Hello Wolfgang, > > Wolfgang Denk wrote: > >> In message <1244638432-30893-3-git-send-email-tom@windriver.com> Tom Rix >> wrote: >> >>> The TWL4030 supplies many peripheral for OMAP3 boards. These include >>> power management, usb and, keyboard. >>> >>> The product description is found here: >>> >>> http://focus.ti.com/docs/prod/folders/print/tps65950.html >>> >>> Product reference document, tps65950.pdf, is found here: >>> >>> http://www.ti.com/lit/gpn/tps65950 >>> >>> Signed-off-by: Tom Rix >>> --- >>> drivers/i2c/Makefile |1 + >>> drivers/i2c/twl4030_i2c.c | 37 >>> include/twl4030.h | 221 >>> + >>> 3 files changed, 259 insertions(+), 0 deletions(-) >>> create mode 100644 drivers/i2c/twl4030_i2c.c >>> create mode 100644 include/twl4030.h >>> >> I think this is supposed to go through the i2c repo, but I haven't >> seen any comments yet. >> > > > Hmm.. there are responses, see for example: > > http://lists.denx.de/pipermail/u-boot/2009-June/054086.html > > >> Can you please check the state of this patch? Thanks in advance. >> > > Hmm.. it is a little long to follow this ... it ended > first here: > > http://lists.denx.de/pipermail/u-boot/2009-June/054654.html > > waiting for an Ack that it works on omap2 ... > > (I Acked the resulting 3 patches, see: > http://lists.denx.de/pipermail/u-boot/2009-June/054585.html > ) > > Ah, found one more answer from Tom: > > http://lists.denx.de/pipermail/u-boot/2009-June/054801.html > > ended in: > > http://lists.denx.de/pipermail/u-boot/2009-June/055071.html > > with a new patchset of 6 patches, starting with: > http://lists.denx.de/pipermail/u-boot/2009-June/055072.html > > but state of omap2 is still pending ... see: > > http://lists.denx.de/pipermail/u-boot/2009-June/055087.html > > then Tom wrote, he has setup a git repo, see: > http://lists.denx.de/pipermail/u-boot/2009-July/055328.html > > but I think, the state of the omap2 is pending ... so > I (and I think Jean-Christophe also) wait for, that this > pending state is going away ... > > Tom, do you have an update? > > (added Jean-Christophe to cc:) > bye > Heiko > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c
Dear Alessandro Rubini, In message you wrote: > > To use soft_i2c I need to define some macros in the config file. > Instead of writing hard numbers there I called the gpio functions, but > the config file is inluded from asm sources as well. I don't think my > approach is beautiful at all (both #ifndef __ASSEMBLY__ and #include > "../board/"), but I didn't find a better solution. Agreed. It's a bit intricate to get this done, but I don't see a better way either. > I would like to add a gpio command, and I've found no generic gpio > stuff. Only one board (cm-bf527) has a gpio commands, but quite a few > have similar commands to set leds or other bits. Is time ripe for a > generic gpio driver with board-specific limits and operations? Would > that be interesting for u-boot-next? Should I process with a board-specific > gpio command by now? Well, my opinion on that is a clear "yes, but..." :-) Yes, some generic gpio framework would be nice - for example, if it would allow us to get rid of the 14 largely similar "led.c" files, to name just one. On the other hand, the design of such a framework should be lean and not necessarily try to cover 100% of all possible use cases - I'd rather have a small and beautiful solution that covers 90% of the cases and use board-specific exceptions where really needed, instead of a fat thing that solves each and every problem but costs 50 kB. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The years of peak mental activity are undoubtedly between the ages of four and eighteen. At four we know all the questions, at eighteen all the answers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to reduce size of U-Boot image (i.MX31, NAND-Flash)
Dear "Ulrich Gerster", In message <4a63456c024d00014...@hochblauen.ba-loerrach.de> you wrote: > > I'm trying to optimize the u-boot image I get after compiling. It's size is > 13XkB depending on the features I define. I'm using a i.MX31 processor and > only NAND-Flash. I think it should be possible to get a smaller Image. Your lines are way too long. Please restrict your line length to some 70 characters or so. Some 130 KiB are pretty normal (and actually even small) for a current version of U-Boot. > Are there some common tricks, or do you have some suggestions how to reduce > the size of u-boot? Undefine features you don't need to get any significant savings, and use a more recent tool chain version to get the last few percent. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can do this in a number of ways. IBM chose to do all of them. Why do you find that funny?-- D. Taylor, Computer Science 350 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_onenand: fix compiler warning for error message
Dear Alessandro Rubini, In message <20090719151345.ga17...@mail.gnudd.com> you wrote: > From: Alessandro Rubini > > Since env_addr is a loff_t (long long), "%08lx" is not a good format; > this uses "%08llx" (not "%016llx"), to get 8 or more hex digits. I > tnknk padding to 8 digits makes things more readable for "small" > numbers, and the unlikely values over 4GB are reported correctly > anyways. But %llx needs CONFIG_SYS_64BIT_VSPRINTF - are we sure that this is #define'd on all boards that use onenand? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "In the face of entropy and nothingness, you kind of have to pretend it's not there if you want to keep writing good code." - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Bugfix: mpc512x_fec MII accesses fail after ethernet transfers
Dear =?ISO-8859-15?Q?Thomas_D=F6rfler?=, In message <4a633d5a.3060...@embedded-brains.de> you wrote: > The mpc512x FEC network driver resets the FEC before transferring > packets. With this reset, the FEC clears the previous setting of MII > transfer speed. This patch ensures, that it is set again to a reasonable > value after a FEC reset. Hmmm... what is the exact effect of the bug you are trying to fix here? Do you have any example how to trigger erroneous behaviour? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I can have honesty, it's easier to overlook mistakes. -- Kirk, "Space Seed", stardate 3141.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_flash.c: fix compile error for boards with DataFlash
Dear Alessandro Rubini,
In message <20090719163317.ga18...@mail.gnudd.com> you wrote:
> From: Alessandro Rubini
>
> The local variables addr_first and addr_last are used if HAS_DATAFLASH
> even if SYS_NO_FLASH (meaning no NOR flash). This adds the definitions
> withing the brace where the names are used, to avoid cluttering the
> initial ifdef.
>
> Signed-off-by: Alessandro Rubini
Yes, I ran into this myself, too. Unfortunaltely I must have
overlooked these ARM error messages when I tested commit 5669ed45
("cmd_flash.c: fix warning: unused variable 'addr_first'/'addr_last'").
Instead of adding another declaration for these variables as you are
doing here, I prefer to change the #ifdef mess^H^H^H^Hlogic earlier in
the file:
>From 567d30367322b6aa76f788ce33ac224e4f1a94da Mon Sep 17 00:00:00 2001
From: Wolfgang Denk
Date: Sun, 19 Jul 2009 19:32:37 +0200
Subject: [PATCH] cmd_flash.c: fix fix compile error for boards with DataFlash
Commit 5669ed45 ("cmd_flash.c: fix warning: unused variable
'addr_first'/'addr_last'") changed the #ifdef logic areound the
declaration of these variables and missed a combination of settings
of HAS_DATAFLASH with SYS_NO_FLASH; this patch fixes this.
Also spotted by Alessandro Rubini
Signed-off-by: Wolfgang Denk
---
common/cmd_flash.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/common/cmd_flash.c b/common/cmd_flash.c
index bc651fa..3773412 100644
--- a/common/cmd_flash.c
+++ b/common/cmd_flash.c
@@ -467,8 +467,10 @@ int do_protect (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
flash_info_t *info;
ulong bank;
int i, n, sect_first, sect_last;
- ulong addr_first, addr_last;
#endif /* CONFIG_SYS_NO_FLASH */
+#if !defined(CONFIG_SYS_NO_FLASH) || defined(CONFIG_HAS_DATAFLASH)
+ ulong addr_first, addr_last;
+#endif
#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
struct mtd_device *dev;
struct part_info *part;
--
1.6.0.6
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
What about WRITING it first and rationalizing it afterwords? :-)
- Larry Wall in <8...@jpl-devvax.jpl.nasa.gov>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix boards broken after removal of legacy NAND and DoC support
Commit 2419169f removed support for legacy NAND and disk on chip but
missed to update the code for a few boards. This patch fixes the
resulting build issues.
Signed-off-by: Wolfgang Denk
---
board/bmw/bmw.c|2 ++
board/pcippc2/pcippc2.c|2 ++
board/rbc823/rbc823.c |2 ++
include/configs/NETPHONE.h |1 -
include/configs/NETTA.h|1 -
include/configs/NETTA2.h |1 -
include/configs/NETVIA.h |2 +-
7 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/board/bmw/bmw.c b/board/bmw/bmw.c
index 870011e..4039145 100644
--- a/board/bmw/bmw.c
+++ b/board/bmw/bmw.c
@@ -117,6 +117,7 @@ sys_led_msg(char* msg)
LED_REG(3) = msg[0];
}
+#ifdef CONFIG_CMD_DOC
/*
* Map onboard TSOP-16MB DOC FLASH chip.
*/
@@ -124,6 +125,7 @@ void doc_init (void)
{
doc_probe(DOC_BASE_ADDR);
}
+#endif
#define NV_ADDR((volatile unsigned char *) CONFIG_ENV_ADDR)
diff --git a/board/pcippc2/pcippc2.c b/board/pcippc2/pcippc2.c
index 7985f7d..6ee44d6 100644
--- a/board/pcippc2/pcippc2.c
+++ b/board/pcippc2/pcippc2.c
@@ -147,10 +147,12 @@ void pci_init_board (void)
cpc710_pci_enable_timeout ();
}
+#ifdef CONFIG_CMD_DOC
void doc_init (void)
{
doc_probe (pcippc2_fpga1_phys + HW_FPGA1_DOC);
}
+#endif
void pcippc2_cpci3264_init (void)
{
diff --git a/board/rbc823/rbc823.c b/board/rbc823/rbc823.c
index b294906..e10d9f9 100644
--- a/board/rbc823/rbc823.c
+++ b/board/rbc823/rbc823.c
@@ -256,6 +256,7 @@ static long int dram_size (long int mamr_value, long int
*base,
return (get_ram_size (base, maxsize));
}
+#ifdef CONFIG_CMD_DOC
void doc_init (void)
{
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
@@ -267,3 +268,4 @@ void doc_init (void)
doc_probe (FLASH_BASE1_PRELIM);
}
+#endif
diff --git a/include/configs/NETPHONE.h b/include/configs/NETPHONE.h
index 8a197ad..76ca916 100644
--- a/include/configs/NETPHONE.h
+++ b/include/configs/NETPHONE.h
@@ -120,7 +120,6 @@
*/
#include
-#define CONFIG_CMD_NAND
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_PING
#define CONFIG_CMD_MII
diff --git a/include/configs/NETTA.h b/include/configs/NETTA.h
index dda6179..4f9f9fe 100644
--- a/include/configs/NETTA.h
+++ b/include/configs/NETTA.h
@@ -134,7 +134,6 @@
#define CONFIG_CMD_IDE
#define CONFIG_CMD_JFFS2
#define CONFIG_CMD_MII
-#define CONFIG_CMD_NAND
#define CONFIG_CMD_NFS
#define CONFIG_CMD_PCMCIA
#define CONFIG_CMD_PING
diff --git a/include/configs/NETTA2.h b/include/configs/NETTA2.h
index 167285e..d060cb7 100644
--- a/include/configs/NETTA2.h
+++ b/include/configs/NETTA2.h
@@ -121,7 +121,6 @@
*/
#include
-#define CONFIG_CMD_NAND
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_PING
#define CONFIG_CMD_MII
diff --git a/include/configs/NETVIA.h b/include/configs/NETVIA.h
index b9cf621..a18b480 100644
--- a/include/configs/NETVIA.h
+++ b/include/configs/NETVIA.h
@@ -107,7 +107,7 @@
#define CONFIG_CMD_PING
#if defined(CONFIG_NETVIA_VERSION) && CONFIG_NETVIA_VERSION >= 2
-#define CONFIG_CMD_NAND
+/* #define CONFIG_CMD_NAND */ /* disabled */
#endif
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Bugfix: mpc512x_fec MII accesses fail after ethernet transfers
Hello, on our custom MPC5121 board I used the following sequence to see the bug: - After U-Boot stated, I could inspect the status of the PHY with "mii info". This works fine even if repeated. - then I trigger some network activity, for example with "ping" - if I try to get the PHY status with "mii info" AFTER that network activity, the command fails (it does not even detect, that a PHY is connected). The reason I could track down is, that: - the FEC driver performs a FEC reset before the initial packet is transmitted - this reset also clears the MII speed register, which defines the communication speed on MDC/MDIO - the PHY access works again, when the MII speed register is set to its proper value. I have tested this behaviour on a old (M34K) mask, but I am sure it applies also to the current M36P. wkr, Thomas Doerfler. Wolfgang Denk wrote: > Dear =?ISO-8859-15?Q?Thomas_D=F6rfler?=, > > In message <4a633d5a.3060...@embedded-brains.de> you wrote: >> The mpc512x FEC network driver resets the FEC before transferring >> packets. With this reset, the FEC clears the previous setting of MII >> transfer speed. This patch ensures, that it is set again to a reasonable >> value after a FEC reset. > > Hmmm... what is the exact effect of the bug you are trying to fix > here? Do you have any example how to trigger erroneous behaviour? > > Best regards, > > Wolfgang Denk > -- Embedded Brains GmbH Thomas DoerflerObere Lagerstrasse 30 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18908079-2 Fax: +49-89-18908079-9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Bugfix: mpc512x_fec MII accesses fail after ethernet transfers
Dear =?ISO-8859-1?Q?Thomas_D=F6rfler?=, In message <4a635d1f.9030...@embedded-brains.de> you wrote: > > on our custom MPC5121 board I used the following sequence to see the bug: > > - After U-Boot stated, I could inspect the status of the PHY with "mii > info". This works fine even if repeated. > > - then I trigger some network activity, for example with "ping" > > - if I try to get the PHY status with "mii info" AFTER that network > activity, the command fails (it does not even detect, that a PHY is > connected). Thanks for the explanation; I can reproduce this problem on the boards we have in our lab, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "A great many people think they are thinking when they are merely re- arranging their prejudices." - William James ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] unify HOST_CFLAGS and HOSTCFLAGS
The top build system sets up HOSTCFLAGS a bit and exports it, but other places use HOST_CFLAGS instead. Unify the two as HOSTCFLAGS so that the values stay in sync. Signed-off-by: Mike Frysinger --- Makefile |2 +- board/fads/config.mk |2 +- board/netstar/Makefile |8 board/spc1920/config.mk |2 +- board/xilinx/ml300/Makefile |2 +- board/xilinx/ppc405-generic/Makefile |2 +- board/xilinx/ppc440-generic/Makefile |2 +- cpu/ixp/npe/Makefile |2 +- drivers/bios_emulator/Makefile |2 +- drivers/net/sk98lin/Makefile |2 +- rules.mk |2 +- tools/Makefile | 12 ++-- tools/gdb/Makefile |2 +- tools/imls/Makefile |4 ++-- 14 files changed, 23 insertions(+), 23 deletions(-) diff --git a/Makefile b/Makefile index e427bc0..37a4564 100644 --- a/Makefile +++ b/Makefile @@ -469,7 +469,7 @@ $(obj)include/autoconf.mk.dep: $(obj)include/config.h include/common.h @$(XECHO) Generating $@ ; \ set -e ; \ : Generate the dependancies ; \ - $(CC) -x c -DDO_DEPS_ONLY -M $(HOST_CFLAGS) $(CPPFLAGS) \ + $(CC) -x c -DDO_DEPS_ONLY -M $(HOSTCFLAGS) $(CPPFLAGS) \ -MQ $(obj)include/autoconf.mk include/common.h > $@ $(obj)include/autoconf.mk: $(obj)include/config.h diff --git a/board/fads/config.mk b/board/fads/config.mk index 621b9a2..6106090 100644 --- a/board/fads/config.mk +++ b/board/fads/config.mk @@ -30,5 +30,5 @@ TEXT_BASE = 0xFE00 PLATFORM_CPPFLAGS += -I$(TOPDIR)/board/fads -HOST_CFLAGS += -I$(TOPDIR)/board/fads +HOSTCFLAGS += -I$(TOPDIR)/board/fads HOST_ENVIRO_CFLAGS += -I$(TOPDIR)/board/fads diff --git a/board/netstar/Makefile b/board/netstar/Makefile index 91bac38..d5fe819 100644 --- a/board/netstar/Makefile +++ b/board/netstar/Makefile @@ -42,7 +42,7 @@ LOAD_ADDR = 0x1040 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds lnk = $(if $(obj),$(obj),.) -HOST_CFLAGS = -Wall -pedantic -I$(TOPDIR)/include +HOSTCFLAGS = -Wall -pedantic -I$(TOPDIR)/include all: $(obj).depend $(LIB) $(obj)eeprom.srec $(obj)eeprom.bin \ $(obj)crcek.srec $(obj)crcek.bin $(obj)crcit @@ -70,13 +70,13 @@ $(obj)crcek.bin:$(obj)crcek.srec $(OBJCOPY) -I srec -O binary $< $@ 2>/dev/null $(obj)crcit: $(obj)crcit.o $(obj)crc32.o - $(HOSTCC) $(HOST_CFLAGS) -o $@ $^ + $(HOSTCC) $(HOSTCFLAGS) -o $@ $^ $(obj)crcit.o: crcit.c - $(HOSTCC) $(HOST_CFLAGS) -o $@ -c $< + $(HOSTCC) $(HOSTCFLAGS) -o $@ -c $< $(obj)crc32.o: $(SRCTREE)/lib_generic/crc32.c - $(HOSTCC) $(HOST_CFLAGS) -DUSE_HOSTCC -o $@ -c $< + $(HOSTCC) $(HOSTCFLAGS) -DUSE_HOSTCC -o $@ -c $< clean: rm -f $(SOBJS) $(OBJS) $(obj)eeprom $(obj)eeprom.srec \ diff --git a/board/spc1920/config.mk b/board/spc1920/config.mk index e361694..8dacc17 100644 --- a/board/spc1920/config.mk +++ b/board/spc1920/config.mk @@ -31,5 +31,5 @@ #TEXT_BASE = 0xFE00 TEXT_BASE = 0xFFF0 PLATFORM_CPPFLAGS += -I$(TOPDIR)/board/spc1920 -HOST_CFLAGS += -I$(TOPDIR)/board/spc1920 +HOSTCFLAGS += -I$(TOPDIR)/board/spc1920 HOST_ENVIRO_CFLAGS += -I$(TOPDIR)/board/spc1920 diff --git a/board/xilinx/ml300/Makefile b/board/xilinx/ml300/Makefile index 9215d77..b8a2d64 100644 --- a/board/xilinx/ml300/Makefile +++ b/board/xilinx/ml300/Makefile @@ -30,7 +30,7 @@ endif INCS := -I../common -I../xilinx_enet -I../xilinx_iic CFLAGS += $(INCS) -HOST_CFLAGS+= $(INCS) +HOSTCFLAGS += $(INCS) LIB= $(obj)lib$(BOARD).a diff --git a/board/xilinx/ppc405-generic/Makefile b/board/xilinx/ppc405-generic/Makefile index b56bb49..4e87e4b 100644 --- a/board/xilinx/ppc405-generic/Makefile +++ b/board/xilinx/ppc405-generic/Makefile @@ -31,7 +31,7 @@ endif INCS := CFLAGS += $(INCS) -HOST_CFLAGS+= $(INCS) +HOSTCFLAGS += $(INCS) LIB= $(obj)lib$(BOARD).a diff --git a/board/xilinx/ppc440-generic/Makefile b/board/xilinx/ppc440-generic/Makefile index bf0a6ba..11a8f69 100644 --- a/board/xilinx/ppc440-generic/Makefile +++ b/board/xilinx/ppc440-generic/Makefile @@ -31,7 +31,7 @@ endif INCS := CFLAGS += $(INCS) -HOST_CFLAGS+= $(INCS) +HOSTCFLAGS += $(INCS) LIB= $(obj)lib$(BOARD).a diff --git a/cpu/ixp/npe/Makefile b/cpu/ixp/npe/Makefile index f4f97bd..8fefd29 100644 --- a/cpu/ixp/npe/Makefile +++ b/cpu/ixp/npe/Makefile @@ -27,7 +27,7 @@ LIB := $(obj)libnpe.a LOCAL_CFLAGS += -I$(TOPDIR)/cpu/ixp/npe/include -DCONFIG_IXP425_COMPONENT_ETHDB -D__linux CFLAGS += $(LOCAL_CFLAGS) -HOST_CFLAGS += $(LOCAL_CFLAGS) +HOSTCFLAGS += $(LOCAL_CFLAGS) COBJS-$(CONFIG_IXP4XX_NPE) := npe.o \ miiphy.o \ diff --git a/drivers/bios_emulator/Makefile b/drivers/bios_emulator/Makefile index c73da97..dd9c102 100644 --- a/drivers/bios_emu
Re: [U-Boot] [PATCH] Bugfix: mpc512x_fec MII accesses fail after ethernet transfers
Dear =?ISO-8859-15?Q?Thomas_D=F6rfler?=,
In message <4a633d5a.3060...@embedded-brains.de> you wrote:
> The mpc512x FEC network driver resets the FEC before transferring
> packets. With this reset, the FEC clears the previous setting of MII
> transfer speed. This patch ensures, that it is set again to a reasonable
> value after a FEC reset.
>
> Signed-off-by: Thomas Doerfler
> --
> diff --git a/drivers/net/mpc512x_fec.c b/drivers/net/mpc512x_fec.c
> index fb2c19a..f3d76ba 100644
> --- a/drivers/net/mpc512x_fec.c
> +++ b/drivers/net/mpc512x_fec.c
> @@ -446,6 +446,19 @@ static void mpc512x_fec_halt (struct eth_device *dev)
> * wait at least 16 clock cycles
> */
> udelay (10);
> + /*
> +* NOTE: reset will also clear the MII speed register
> +* we should reinitialize it ASAP
> +*/
> + if (fec->xcv_type != SEVENWIRE) {
> + /*
> +* Set MII_SPEED = (1/(mii_speed * 2)) * System Clock
> +* and do not drop the Preamble.
> +*/
> + fec->eth->mii_speed = gd->ips_clk / 100) / 5)
> + + 1)
> + << 1);
> + }
> #if (DEBUG & 0x3)
> printf ("Ethernet task stopped\n");
> #endif
> --
This patch is white-space corrupted. Please fix your mailer settings.
Also, you should use I/O accessors instead of direct pointer accesses
like we do it in the rest of the code (maybe you are using an obsolete
code base?).
Finally I disagree with the solution: I think it is actually correct
to disable the MII clock, too, when we stop the Ethernet interface.
However, we should make sure that the PHY gets (re-) initialized (by
running mpc512x_fec_init_phy()) if needed when a MII command is run.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A person who is more than casually interested in computers should be
well schooled in machine language, since it is a fundamental part of
a computer. -- Donald Knuth
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] malloc.h: protect it against multiple include
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <1244890537-9997-1-git-send-email-plagn...@jcrosoft.com> you wrote: > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD > --- > include/malloc.h |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The first 90% of a project takes 90% of the time, the last 10% takes the other 90% of the time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] push CROSS_COMPILE out to $(ARCH)_config.mk
Dear Mike Frysinger, In message <1245036794-7396-1-git-send-email-vap...@gentoo.org> you wrote: > Each arch should handle setting a proper default CROSS_COMPILE value in > their own config.mk file rather than having to maintain a large ugly list > in the Makefile. By using conditional assignment, we don't have to worry > about the variable already being set (env/cmdline/etc...). > > The common config.mk file takes care of exporting CROSS_COMPILE already, > and while a few variables (toolchain ones) utilize CROSS_COMPILE before > including the arch config.mk, they do so with deferred assignment. > > Signed-off-by: Mike Frysinger > --- > Makefile | 44 ++-- > arm_config.mk|2 ++ > avr32_config.mk |2 ++ > blackfin_config.mk |2 ++ > i386_config.mk |2 ++ > m68k_config.mk |2 ++ > microblaze_config.mk |2 ++ > mips_config.mk |2 ++ > nios2_config.mk |2 ++ > nios_config.mk |2 ++ > ppc_config.mk|2 ++ > sh_config.mk |2 ++ > sparc_config.mk |2 ++ > 13 files changed, 26 insertions(+), 42 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I read part of it all the way through. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common: fix 'dummy' is used uninitialized in this function warning
Dear Kim Phillips, In message <20090615115040.5932bd21.kim.phill...@freescale.com> you wrote: > fix this gcc 4.4 warning: > > xyzModem.c: In function 'xyzModem_stream_open': > xyzModem.c:564: warning: 'dummy' is used uninitialized in this function > > Signed-off-by: Kim Phillips > --- > common/xyzModem.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I perceive a possibility of an immediate chronological sequence of events which includes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] compiler.h: unify system ifdef cruft here
Dear Mike Frysinger, In message <1246577005-10928-1-git-send-email-vap...@gentoo.org> you wrote: > Shove a lot of the HOSTCC and related #ifdef checking crap into the new > compiler.h header so that we can keep all other headers nice and clean. > > Also introduce custom uswap functions so we don't have to rely on the non > standard implementations that a host may (or may not in the case of OS X) > provide. This allows mkimage to finally build cleanly on an OS X system. > > Signed-off-by: Mike Frysinger > --- > this version has been tested with Blackfin targets on Linux, Darwin, and > now MinGW host systems. needed a small fix in image.h to use the cpu > funcs rather than ntoh/hton. > > include/compiler.h| 125 > + > include/elf.h | 10 + > include/environment.h |6 +-- > include/image.h | 13 ++--- > include/libfdt_env.h | 53 ++--- > include/u-boot/md5.h |2 +- > lib_generic/md5.c |8 +-- > tools/bmp_logo.c | 13 +- > tools/img2srec.c |3 +- > tools/mingw_support.h |3 - > tools/mkimage.c | 14 ++ > tools/mkimage.h | 33 - > tools/os_support.c|1 + > tools/os_support.h|2 + > tools/ubsha1.c| 13 - > 15 files changed, 150 insertions(+), 149 deletions(-) > create mode 100644 include/compiler.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always borrow money from a pessimist; they don't expect to be paid back. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] digsy mtc: Enable command line history.
Dear Grzegorz Bernacki, In message <1245248414-84498-1-git-send-email-...@semihalf.com> you wrote: > > Signed-off-by: Grzegorz Bernacki > --- > include/configs/digsy_mtc.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Nature is very un-American. Nature never hurries." - William George Jordan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add support for C5000 thermostimulator
Dear Giulio Benetti,
In message you wrote:
> Based on at91sam9263.
> It is a thermostimulator for hair styling.
> Subsection of
> Software is based on at91sam9263ek one.
>
> Signed-off-by: giulio.bene...@micronovasrl.com
Please use git-format-patch to prepare patches.
Entries for MAINTAINERS and MAKEALL files are missing.
Please use TABs (instead of spaces) for vertical alignment.
> diff -urpN b/board/micronova/c5000/c5000.c a/board/micronova/c5000/c5000.c
> --- b/board/micronova/c5000/c5000.c 1970-01-01 01:00:00.0 +0100
> +++ a/board/micronova/c5000/c5000.c 2009-06-18 12:57:52.0 +0200
...
> + at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_LCDC);
> +
> + gd->fb_base = PHYS_SDRAM + 0x3FB5000; /* mapped into sdram @
> 0x2000 +
> (64 MByte - (640x480) 8bpp) */
Line too long. Please fix globally.
> +int dram_init(void)
> +{
> + gd->bd->bi_dram[0].start = PHYS_SDRAM;
> + gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
> + return 0;
> +}
How about using get_ram_size() for auto-sizing and memory testing?
> diff -urpN b/board/micronova/c5000/config.mk
> a/board/micronova/c5000/config.mk
> --- b/board/micronova/c5000/config.mk 1970-01-01 01:00:00.0 +0100
> +++ a/board/micronova/c5000/config.mk 2009-06-18 12:55:19.0 +0200
> @@ -0,0 +1 @@
> +TEXT_BASE = 0x23f0
Copyright entry missing.
> diff -urpN b/Makefile a/Makefile
> --- b/Makefile 2009-06-14 21:30:39.0 +0200
> +++ a/Makefile 2009-06-18 12:55:19.0 +0200
> @@ -2752,6 +2752,9 @@ at91sam9rlek_config : unconfig
> pm9263_config : unconfig
> @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91
>
> +c5000_config : unconfig
> + @$(MKCONFIG) $(@:_config=) arm arm926ejs c5000 micronova at91
> +
Please keep lists sorted.
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 message was made from 100% recycled electrons.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add WATCHDOG_RESET() on nand write and read
Dear Scott,
In message Giulio Benetti wrote:
> I think it's better to put Watchdog reset also inside read and write nand.
> What do you think?
>
> Signed-off-by: giulio.bene...@micronovasrl.com
>
> diff -urpN b/drivers/mtd/nand/nand_util.c a/drivers/mtd/nand/nand_util.c
> --- b/drivers/mtd/nand/nand_util.c 2009-06-14 21:30:39.0 +0200
> +++ a/drivers/mtd/nand/nand_util.c 2009-06-18 17:13:19.0 +0200
> @@ -505,6 +505,8 @@ int nand_write_skip_bad(nand_info_t *nan
> size_t block_offset = offset & (nand->erasesize - 1);
> size_t write_size;
>
> + WATCHDOG_RESET ();
> +
> if (nand_block_isbad (nand, offset & ~(nand->erasesize - 1)))
> {
> printf ("Skip bad block 0x%08zx\n",
> offset & ~(nand->erasesize - 1));
> @@ -575,6 +577,8 @@ int nand_read_skip_bad(nand_info_t *nand
> size_t block_offset = offset & (nand->erasesize - 1);
> size_t read_length;
>
> + WATCHDOG_RESET ();
> +
> if (nand_block_isbad (nand, offset & ~(nand->erasesize - 1)))
> {
> printf ("Skipping bad block 0x%08zx\n",
> offset & ~(nand->erasesize - 1));
Acked-by: Wolfgang Denk
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"It's like deja vu all over again." - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config.mk: Remove unused HPATH
Dear Shinya Kuribayashi, In message <4a3cb689.6090...@pobox.com> you wrote: > This variable is not unused anywhere. > > Signed-off-by: Shinya Kuribayashi > --- > config.mk |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de panic: kernel trap (ignored) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Bugfix: mpc512x_fec MII accesses fail after ethernet transfers
Hello,
thank you for your feedback. Sorry for the "newbie" problems, I should
have checked this before sending the patch.
But I doubt that (re-)calling mpc512x_fec_init_phy before a MII command
is run is really a good idea. Using the same code for initial init and
repeated init makes sense, but this function in its current
implementation also resets the PHY, which forces a new line negotiation
to occur. IMHO this is NOT needed when we e.g. query the PHY status and
it would even be contraproductive, if we would change some PHY register
settings, because these changes would also be reset.
What COULD make sense is to extract the MII speed register setting
operation from mpc512x_fec_init_phy() and move it to the
mpc512x_fec_mii_read/write functions. because this is where it is really
needed.
Does this make sense to you?
wkr,
Thomas Doerfler.
Wolfgang Denk wrote:
> Dear =?ISO-8859-15?Q?Thomas_D=F6rfler?=,
>
> In message <4a633d5a.3060...@embedded-brains.de> you wrote:
>> The mpc512x FEC network driver resets the FEC before transferring
>> packets. With this reset, the FEC clears the previous setting of MII
>> transfer speed. This patch ensures, that it is set again to a reasonable
>> value after a FEC reset.
>>
>> Signed-off-by: Thomas Doerfler
>> --
>> diff --git a/drivers/net/mpc512x_fec.c b/drivers/net/mpc512x_fec.c
>> index fb2c19a..f3d76ba 100644
>> --- a/drivers/net/mpc512x_fec.c
>> +++ b/drivers/net/mpc512x_fec.c
>> @@ -446,6 +446,19 @@ static void mpc512x_fec_halt (struct eth_device *dev)
>> * wait at least 16 clock cycles
>> */
>> udelay (10);
>> + /*
>> +* NOTE: reset will also clear the MII speed register
>> +* we should reinitialize it ASAP
>> +*/
>> + if (fec->xcv_type != SEVENWIRE) {
>> + /*
>> +* Set MII_SPEED = (1/(mii_speed * 2)) * System Clock
>> +* and do not drop the Preamble.
>> +*/
>> + fec->eth->mii_speed = gd->ips_clk / 100) / 5)
>> + + 1)
>> + << 1);
>> + }
>> #if (DEBUG & 0x3)
>> printf ("Ethernet task stopped\n");
>> #endif
>> --
>
> This patch is white-space corrupted. Please fix your mailer settings.
>
> Also, you should use I/O accessors instead of direct pointer accesses
> like we do it in the rest of the code (maybe you are using an obsolete
> code base?).
>
> Finally I disagree with the solution: I think it is actually correct
> to disable the MII clock, too, when we stop the Ethernet interface.
>
> However, we should make sure that the PHY gets (re-) initialized (by
> running mpc512x_fec_init_phy()) if needed when a MII command is run.
>
>
> Best regards,
>
> Wolfgang Denk
>
--
Embedded Brains GmbH
Thomas DoerflerObere Lagerstrasse 30
D-82178 Puchheim Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18908079-2
Fax: +49-89-18908079-9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] S5PC100: serial driver for SMDKC100 support
Dear HeungJun Kim,
In message <350d1ec30906250109s34355cbex5a2e59e181a5d...@mail.gmail.com> you
wrote:
> This patch is the serial driver for S5PC100 & SMDKC100.
>
> Signed-off-by: HeungJun, Kim
I think this patch should be merged with the patch(es) that add the
rest of the code.
> diff --git a/drivers/serial/serial_s5pc100.c b/drivers/serial/serial_s5pc100.c
> new file mode 100644
> index 000..9394e77
> --- /dev/null
> +++ b/drivers/serial/serial_s5pc100.c
...
> +void serial_setbrg(void)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> + s5pc1xx_uart_t *const uart = s5pc1xx_get_base_uart(UART_NR);
> + u32 pclk = get_PCLK();
> + u32 baudrate = gd->baudrate;
> + int i;
> +
> + i = (pclk / baudrate) % 16;
> +
> + uart->UBRDIV = pclk / baudrate / 16 - 1;
> + uart->UDIVSLOT = udivslot[i];
Please use I/O accessors instead of register writes. [Here and
everywhere.]
> + for (i = 0; i < 100; i++);
> + barrier();
What's this? This should not be needed.
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
Unix is supported by IBM, like a hanging man is supported by rope.
- Don Libes & Sandy Ressler: _Life With Unix_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1247935062.9174.14.ca...@ptyser-laptop> you wrote: > > > > I'd still vote for changing the directory structure in this release, > > NAK. Such heavily restructuring changes should be prepared and > submitted at (or even before) the begin of the merge window, not at > it's very end. > > For this release it's too late for such a change. Any interest in picking up the following patches from this series for the upcoming release: 1/6 Move architecture specific config.mk files into subdirs 5/6 Move examples/ to examples/standalone 6/6 Move api_examples to examples/api They're pretty straightforward and are 3 less changes to carry around. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] S5PC100: Add onenand_ipl for SMDKC100 support
Dear HeungJun Kim,
In message <350d1ec30906250121q4e860812s35054aaee8c20...@mail.gmail.com> you
wrote:
> The SMDKC100 Board has 256MB onenand.
> So, It's bootable, if this patch is adapted thus the board use onenand_ipl.
>
> Signed-off-by: HeungJun, Kim
>
> ---
>
> This patch support onenand boot on SMDKC100 Board.
...
> diff --git a/onenand_ipl/board/samsung/smdkc100/Makefile
> b/onenand_ipl/board/samsung/smdkc100/Makefile
> new file mode 100644
> index 000..4301938
> --- /dev/null
> +++ b/onenand_ipl/board/samsung/smdkc100/Makefile
...
> +ALL = $(onenandobj)onenand-ipl $(onenandobj)onenand-ipl.bin
> $(onenandobj)onenand-ipl-2k.bin $(onenandobj)onenand-ipl-4k.bin
This patch is white-space corrupted. I gues this happened here because
the line was way too long.
> --- a/onenand_ipl/onenand_read.c
> +++ b/onenand_ipl/onenand_read.c
> @@ -37,10 +37,24 @@
> extern void *memcpy32(void *dest, void *src, int size);
> #endif
>
> +
> +
Please do not arbitrary empty lines.
> /* read a page with ECC */
> static inline int onenand_read_page(ulong block, ulong page,
> u_char * buf, int pagesize)
> {
> +#ifdef CONFIG_S5PC1XX
> + unsigned int *p = (unsigned int *) buf;
> + int mem_addr, i;
> +
> + mem_addr = MEM_ADDR(block, page, 0);
> +
> + pagesize >>= 2;
> +
> + for (i = 0; i < pagesize; i++)
> + *p++ = *(volatile unsigned int *)(CMD_MAP_01(mem_addr));
> +#else/* CONFIG_S5PC1XX */
> +
> unsigned long *base;
I don't like to see such board specific code in global files.
Also, please use I/O accessor functions instead of register accesses.
> @@ -114,6 +129,9 @@ int onenand_read_block(unsigned char *buf)
>
> erasesize = ONENAND_PAGES_PER_BLOCK * pagesize;
> nblocks = (CONFIG_SYS_MONITOR_LEN + erasesize - 1) >> erase_shift;
> +#ifdef CONFIG_S5PC1XX
> + nblocks = 1;
> +#endif
Again: why do we need such board specific code here?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I have a very small mind and must live with it.-- Edsger Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: set bus width to 1 and clock to minimum early during initialization
Dear Ilya Yanok, In message <1246283596-1259-1-git-send-email-ya...@emcraft.com> you wrote: > We need to switch back to 1-bit before initialization or SD 2.0 cards > will fail to send SCR if we've switched to 4-bit already. > > Signed-off-by: Ilya Yanok > --- > drivers/mmc/mmc.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Just think of a computer as hardware you can program." - Nigel de la Tierre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] This patch adds support for Fujitsu MB86R01 'JADE' SOC
Dear Matthias Weisser, In message <1246368064-4957-1-git-send-email-matthias.weis...@graf-syteco.de> you wrote: > Signed-off-by: Matthias Weisser > --- > cpu/arm926ejs/jade/Makefile | 47 + > cpu/arm926ejs/jade/timer.c | 129 > include/asm-arm/arch-jade/hardware.h | 31 ++ > include/asm-arm/arch-jade/jade.h | 182 > ++ > 4 files changed, 389 insertions(+), 0 deletions(-) > create mode 100755 cpu/arm926ejs/jade/Makefile > create mode 100755 cpu/arm926ejs/jade/timer.c > create mode 100755 include/asm-arm/arch-jade/hardware.h > create mode 100755 include/asm-arm/arch-jade/jade.h Entries to MAKEALL and MAINTAINERS are missing. > diff --git a/include/asm-arm/arch-jade/jade.h > b/include/asm-arm/arch-jade/jade.h > new file mode 100755 > index 000..0ab96e1 > --- /dev/null > +++ b/include/asm-arm/arch-jade/jade.h ... > +typedef volatile unsigned int JREG; /* Hardware register definition > */ You don't need this. We don't use register accesses, but I/O accessor functions. > +/* > + * Physical Address Defines > + */ > +#define JADE_GDC_PHYS_BASE 0xf1fc /* GDC phys */ > +#define JADE_GDC_PHYS_DISP_BASE 0xf1fd /* GDC > DisplayBase phys */ > +#define JADE_CCNT_PHYS_BASE 0xfff42000 /* Chip Control Module > */ > +#define JADE_CAN0_PHYS_BASE 0xfff54000 /* CAN 0 phys */ > +#define JADE_CAN1_PHYS_BASE 0xfff55000 /* CAN 1 phys */ > +#define JADE_I2C0_PHYS_BASE 0xfff56000 /* I2C 0 phys */ > +#define JADE_I2C1_PHYS_BASE 0xfff57000 /* I2C 1 phys */ > +#define JADE_EHCI_PHYS_BASE 0xfff8 /* EHCI phys */ > +#define JADE_OHCI_PHYS_BASE 0xfff81000 /* OHCI phys */ > +#define JADE_IRC1_PHYS_BASE 0xfffb /* Jade cascaded > Interrupt Controller phys */ > +#define JADE_TIMER_PHYS_BASE 0xfffe /* Counter/Timers JADE > phys */ > +#define JADE_UART0_PHYS_BASE 0xfffe1000 /* UART 0 phys */ > +#define JADE_UART1_PHYS_BASE 0xfffe2000 /* UART 1 phys */ > +#define JADE_IRCE_PHYS_BASE 0xfffe4000 /* Extended Interrupt > Controller */ > +#define JADE_CRG_PHYS_BASE 0xfffe7000 /* Clock Reset > Generator */ > +#define JADE_IRC0_PHYS_BASE 0xfffe8000 /* Jade Interrupt > Controller phys */ > +#define JADE_GPIO_PHYS_BASE 0xfffe9000 /* GPIO phys */ > + > + > +/* DRAMC_DRIC : (DRAMC Offset: 0x0) DRAM Controller Mode Register > */ > + > +/ > + * REGISTER ADDRESS DEFINITION FOR DRAMC PERIPHERAL >* > + > / > +#define JREGC_DRAMC_DRIC ((JREG *) 0xF300) /* DRAM Controller > Initialization control register */ > +#define JREGC_DRAMC_DRIC1 ((JREG *) 0xF302) /* DRAM > Controller Init control command register 1 */ > +#define JREGC_DRAMC_DRIC2 ((JREG *) 0xF304) /* DRAM > Controller Init control command register 2 */ > +#define JREGC_DRAMC_DRCA((JREG *) 0xF306) /* DRAM > Controller Address control register */ > +#define JREGC_DRAMC_DRCM((JREG *) 0xF308) /* DRAM > Controller Modal control register */ > +#define JREGC_DRAMC_DRCST1 ((JREG *) 0xF30A) /* DRAM > Controller Timing setting register 1 */ > +#define JREGC_DRAMC_DRCST2 ((JREG *) 0xF30C) /* DRAM > Controller Timing setting register 2 */ > +#define JREGC_DRAMC_DRCR((JREG *) 0xF30E) /* DRAM > Controller Refresh control register */ > +#define JREGC_DRAMC_DRCS ((JREG *) 0xF320) /* DRAM Controller > Status control register */ > +#define JREGC_DRAMC_DRASR((JREG *) 0xF330) /* DRAM Controller AXI > operation setting register */ > +#define JREGC_DRAMC_DRIMS1 ((JREG *) 0xF342) /* DRAM Controller IF > control register 1 */ ... NAK. We don't allow such a base address + offset approach. Please define C structs for the peripherals, and use I/O accessors. 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 All these theories, diverse as they are, have two things in common: they explain the observed facts, and they are completeley and utterly wrong. - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link
On Wed, 2009-02-04 at 15:14 -0600, Peter Tyser wrote: > Previously, waiting for auto-negotiation would only occur if a valid > link had been detected. Problems arose when attempting to use a > tsec immediately after bootup but before link was achieved, eg: > => dhcp > Auto-neg error, defaulting to 10BT/HD > eTSEC1: No link. > Auto-neg error, defaulting to 10BT/HD > eTSEC2: No link. > => > > With this patch applied the same operation as above resulted in: > => dhcp > Waiting for PHY auto negotiation to complete. done > Enet starting in 1000BT/FD > Speed: 1000, full duplex > > Signed-off-by: Peter Tyser This patch originally spawned a lot of discussion but nothing came of it. Could we get it applied? If not, what do I need to do to get a similar change in? Right now if you have autoboot enabled that uses network operation, you have to add an arbitrary delay to the boot process to give autonegotiation time to complete, which is annoying. The negotiation time varies depending on switch too, so the delay can never be exact. Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
Dear Peter Tyser, In message <1248033674.15400.9.ca...@ptyser-laptop> you wrote: > On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote: > > Dear Peter Tyser, > > > > In message <1247935062.9174.14.ca...@ptyser-laptop> you wrote: > > > > > > I'd still vote for changing the directory structure in this release, > > > > NAK. Such heavily restructuring changes should be prepared and > > submitted at (or even before) the begin of the merge window, not at > > it's very end. > > > > For this release it's too late for such a change. > > Any interest in picking up the following patches from this series for > the upcoming release: > 1/6 Move architecture specific config.mk files into subdirs > 5/6 Move examples/ to examples/standalone > 6/6 Move api_examples to examples/api > > They're pretty straightforward and are 3 less changes to carry around. I will look into this patch series ASAP (still fighting with some backlog; just completed June's patches) - it was submitted while the merge window was open, so there is no reason to ignore them without at least carefully checking. 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 "Who is the oldest inhabitant of this village?" "We haven't got one; we had one, but he died three weeks ago." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] Merge Window Closed
Hi, the Merge Window for release 2009.08 is closed (well, it will be closed in 24 minutes or so). I will need 2...3 more days to work through the backlog of patches; this will alos give some custodians who are late a chance to send some pull requests. I intend to have a -rc1 out before the end of this week. 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 "Though a program be but three lines long, someday it will have to be maintained." - The Tao of Programming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] No reply to USB related questions
> > I've posted a few questions to the list for which I didn't get any > response. > > Your posting is less than 24 hours old, and you did not pay your > premium support contract fee yet. > > See http://catb.org/esr/faqs/smart-questions.html Ouch. That smarts. :-) I honestly was wondering whether my address might have been in a spam list or something. But having said that, I concede your point. Should have been a bit more patient. D ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - add dns
On Sat 18 Jul 2009 21:15, Mike Frysinger pondered: > On Saturday 18 July 2009 20:27:00 Robin Getz wrote: > > On Sat 18 Jul 2009 18:11, Mike Frysinger pondered: > > > keep the modulus something with only 1 bit set so gcc will optimize into > > > a simple and operation. probably add a comment about it too: > > > /* make src port a little random, but use something trivial to compute > > > */ > > > > OK - So, this would give three different variations: > > So, these are definitality ugly... > > net/tftp.c: TftpOurPort = 1024 + (get_timer(0) % 3072); <_random_port>: 0: 78 05 [--SP] = (R7:7); 2: 67 01 [--SP] = RETS; 4: a6 6f SP += -0xc; /* (-12) */ 6: 00 60 R0 = 0x0 (X); /* R0=0x0( 0) */ 8: ff e3 fc ff CALL 0x0 <_random_port>; a: R_BFIN_PCREL24 _get_timer c: 41 e1 aa aa R1.H = 0x; /* (-21846) R1=0x000c(-1431699444) */ 10: 01 e1 ab aa R1.L = 0xaaab; /* (-21845) R1=0xaaab(-1431655765) */ 14: 38 30 R7 = R0; 16: ff e3 f5 ff CALL 0x0 <_random_port>; 18: R_BFIN_PCREL24 ___umulsi3_highpart 1a: 58 4e R0 >>= 0xb; 1c: 21 e1 00 0c R1 = 0xc00 (X); /* R1=0xc00(3072) */ 20: c8 40 R0 *= R1; 22: 66 6c SP += 0xc; /* ( 12) */ 24: c7 53 R7 = R7 - R0; 26: 20 e1 00 04 R0 = 0x400 (X); /* R0=0x400(1024) */ 2a: c7 51 R7 = R7 + R0; 2c: 27 01 RETS = [SP++]; 2e: 07 30 R0 = R7; 30: 38 05 (R7:7) = [SP++]; 32: 10 00 RTS; Disassembly of section .text.NetSetTimeout: > > net/nfs.c: NfsOurPort = 4096 + (get_ticks() % 3072); <_random_port>: 0: 67 01 [--SP] = RETS; 2: 86 6f SP += -0x10;/* (-16) */ 4: ff e3 fe ff CALL 0x0 <_random_port>; 6: R_BFIN_PCREL24 _get_ticks 8: 02 60 R2 = 0x0 (X); /* R2=0x0( 0) */ a: f2 b0 [SP + 0xc] = R2; c: 22 e1 00 0c R2 = 0xc00 (X); /* R2=0xc00(3072) */ 10: ff e3 f8 ff CALL 0x0 <_random_port>; 12: R_BFIN_PCREL24 ___umoddi3 14: 86 6c SP += 0x10; /* ( 16) */ 16: 08 30 R1 = R0; 18: 27 01 RETS = [SP++]; 1a: 20 e1 00 10 R0 = 0x1000 (X);/* R0=0x1000(4096) */ 1e: 01 50 R0 = R1 + R0; 20: 10 00 RTS; > > net/sntp.c: SntpOurPort = 1 + (get_timer(0) % 4096); <_random_port>: 0: 67 01 [--SP] = RETS; 2: a6 6f SP += -0xc; /* (-12) */ 4: 00 60 R0 = 0x0 (X); /* R0=0x0( 0) */ 6: ff e3 fd ff CALL 0x0 <_random_port>; 8: R_BFIN_PCREL24 _get_timer a: 21 e1 ff 0f R1 = 0xfff (X); /* R1=0xfff(4095) */ e: 66 6c SP += 0xc; /* ( 12) */ 10: 08 54 R0 = R0 & R1; 12: 27 01 RETS = [SP++]; 14: 21 e1 10 27 R1 = 0x2710 (X);/* R1=0x2710(1) */ 18: 08 50 R0 = R0 + R1; 1a: 10 00 RTS; Disassembly of section .text.NetSetTimeout: > 1024 + (get_timer(0) % 0x8000); <_random_port>: 0: 67 01 [--SP] = RETS; 2: a6 6f SP += -0xc; /* (-12) */ 4: 00 60 R0 = 0x0 (X); /* R0=0x0( 0) */ 6: ff e3 fd ff CALL 0x0 <_random_port>; 8: R_BFIN_PCREL24 _get_timer a: 21 e1 ff 7f R1 = 0x7fff (X);/* R1=0x7fff(32767) */ e: 66 6c SP += 0xc; /* ( 12) */ 10: 08 54 R0 = R0 & R1; 12: 27 01 RETS = [SP++]; 14: 21 e1 00 04 R1 = 0x400 (X); /* R1=0x400(1024) */ 18: 08 50 R0 = R0 + R1; 1a: 10 00 RTS; Disassembly of section .text.NetSetTimeout: > > Does it make sense to have 4 different ones? (not to me)... > > > > Or something new & common in ./net.c:random_port() > > i would make a new patch that adds a new random_port() function and converts > existing consumers to that, and then have the dns code rely on that. > > and you should adopt my implementation because the generated code is > much much nicer than the others ;) At least on Blackfin - the sntp version and yours are computationally equal - although I think yours ends up being more random - so yeah, I'll use that one. > a quick google shows: > - sntp - any non-zero source port is OK > - tftp - "between 0 and 65535" > - nfs - couldnt find anything, but i'm pretty sure there isnt o
Re: [U-Boot] No reply to USB related questions
Hi, Dushara Jayasinghe wrote: >>> I've posted a few questions to the list for which I didn't get any >>> >> response. >> >> Your posting is less than 24 hours old, and you did not pay your >> premium support contract fee yet. >> >> See http://catb.org/esr/faqs/smart-questions.html >> > > Ouch. That smarts. :-) > > I honestly was wondering whether my address might have been in a spam list or > something. > > But having said that, I concede your point. Should have been a bit more > patient. > > D > BTW, I think that u-boot community offers a good support and I have always a good feedback with the people here. So many thanks to the Mantainers and to the developers 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
[U-Boot] [PATCH 2/3] xpedite5370: Fix I2C GPIO initialization typo
From: Peter Tyser Signed-off-by: Peter Tyser --- board/xes/xpedite5370/xpedite5370.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/xes/xpedite5370/xpedite5370.c b/board/xes/xpedite5370/xpedite5370.c index 22cf294..d54c699 100644 --- a/board/xes/xpedite5370/xpedite5370.c +++ b/board/xes/xpedite5370/xpedite5370.c @@ -84,8 +84,8 @@ int board_early_init_r(void) /* Initialize PCA9557 devices */ pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR0, 0xff, 0); pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR1, 0xff, 0); - pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR0, 0xff, 0); - pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR0, 0xff, 0); + pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR2, 0xff, 0); + pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR3, 0xff, 0); /* * Remap NOR flash region to caching-inhibited -- 1.6.2-rc2.GIT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] xpedite5200, 5370: Use buffered NOR flash writes
From: Peter Tyser
Buffered writes are possible on the XPedite5200 and XPedite5370 and greatly
improve NOR flash write speeds
Signed-off-by: Peter Tyser
---
I miscalculated the merge window close time... I hope to slip these last 3
trivial changes in the upcoming release if possible.
Thanks,
Peter
include/configs/XPEDITE5200.h |1 +
include/configs/XPEDITE5370.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/XPEDITE5200.h b/include/configs/XPEDITE5200.h
index 89ab692..617f514 100644
--- a/include/configs/XPEDITE5200.h
+++ b/include/configs/XPEDITE5200.h
@@ -129,6 +129,7 @@
#define CONFIG_SYS_FLASH_WRITE_TOUT500 /* Flash Write Timeout
(ms) */
#define CONFIG_FLASH_CFI_DRIVER
#define CONFIG_SYS_FLASH_CFI
+#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
#define CONFIG_SYS_FLASH_AUTOPROTECT_LIST { {0xfff4, 0xc}, \
{0xfbf4, 0xc} }
#define CONFIG_SYS_MONITOR_BASETEXT_BASE /* start of monitor */
diff --git a/include/configs/XPEDITE5370.h b/include/configs/XPEDITE5370.h
index 536e063..d00448b 100644
--- a/include/configs/XPEDITE5370.h
+++ b/include/configs/XPEDITE5370.h
@@ -137,6 +137,7 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy);
#define CONFIG_SYS_FLASH_WRITE_TOUT500 /* Flash Write Timeout
(ms) */
#define CONFIG_FLASH_CFI_DRIVER
#define CONFIG_SYS_FLASH_CFI
+#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
#define CONFIG_SYS_FLASH_AUTOPROTECT_LIST { {0xfff4, 0xc}, \
{0xf7f4, 0xc} }
#define CONFIG_SYS_MONITOR_BASETEXT_BASE /* start of monitor */
--
1.6.2-rc2.GIT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Remove last remanants of unused CONFIG_I2C_CMD_TREE
From: Peter Tyser Signed-off-by: Peter Tyser --- include/configs/P2020DS.h |1 - include/configs/XPEDITE5170.h |1 - include/configs/aria.h|1 - include/configs/mecp5123.h|1 - 4 files changed, 0 insertions(+), 4 deletions(-) diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h index 676f013..70ab96f 100644 --- a/include/configs/P2020DS.h +++ b/include/configs/P2020DS.h @@ -412,7 +412,6 @@ extern unsigned long calculate_board_ddr_clk(unsigned long dummy); #define CONFIG_HARD_I2C/* I2C with hardware support */ #undef CONFIG_SOFT_I2C /* I2C bit-banged */ #define CONFIG_I2C_MULTI_BUS -#define CONFIG_I2C_CMD_TREE #define CONFIG_SYS_I2C_SPEED 40 /* I2C speed and slave address */ #define CONFIG_SYS_I2C_EEPROM_ADDR 0x57 #define CONFIG_SYS_I2C_SLAVE 0x7F diff --git a/include/configs/XPEDITE5170.h b/include/configs/XPEDITE5170.h index 2553293..985b589 100644 --- a/include/configs/XPEDITE5170.h +++ b/include/configs/XPEDITE5170.h @@ -254,7 +254,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_SYS_I2C_OFFSET 0x3000 #define CONFIG_SYS_I2C2_OFFSET 0x3100 #define CONFIG_I2C_MULTI_BUS -#define CONFIG_I2C_CMD_TREE /* PEX8518 slave I2C interface */ #define CONFIG_SYS_I2C_PEX8518_ADDR0x70 diff --git a/include/configs/aria.h b/include/configs/aria.h index e7e238d..423 100644 --- a/include/configs/aria.h +++ b/include/configs/aria.h @@ -376,7 +376,6 @@ #define CONFIG_HARD_I2C/* I2C with hardware support */ #undef CONFIG_SOFT_I2C /* so disable bit-banged I2C */ #define CONFIG_I2C_MULTI_BUS -#define CONFIG_I2C_CMD_TREE /* I2C speed and slave address */ #define CONFIG_SYS_I2C_SPEED 10 diff --git a/include/configs/mecp5123.h b/include/configs/mecp5123.h index e00859a..1ecae00 100644 --- a/include/configs/mecp5123.h +++ b/include/configs/mecp5123.h @@ -249,7 +249,6 @@ #define CONFIG_HARD_I2C/* I2C with hardware support */ #undef CONFIG_SOFT_I2C /* so disable bit-banged I2C */ #define CONFIG_I2C_MULTI_BUS -#define CONFIG_I2C_CMD_TREE #define CONFIG_SYS_I2C_SPEED 40 /* I2C speed */ #define CONFIG_SYS_I2C_SLAVE 0x7F/* slave address */ -- 1.6.2-rc2.GIT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [OneNAND] Fix compiler warnings after loff_t change
Now 'env_addr' type is loff_t so use correct field type.
Signed-off-by: Kyungmin Park
---
diff --git a/common/env_onenand.c b/common/env_onenand.c
index 476fdbc..dcf09de 100644
--- a/common/env_onenand.c
+++ b/common/env_onenand.c
@@ -101,7 +101,7 @@ int saveenv(void)
instr.addr = env_addr;
instr.mtd = mtd;
if (mtd->erase(mtd, &instr)) {
- printf("OneNAND: erase failed at 0x%08lx\n", env_addr);
+ printf("OneNAND: erase failed at 0x%08llx\n", env_addr);
return 1;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env_onenand compiler warning
Hi, Thank you for pointing compiler warning. I post the patch. Thank you, Kyungmin Park On Sun, Jul 19, 2009 at 3:47 PM, Dirk Behme wrote: > > Testing recent mainline git head for omap3_evm_config I get compiler > warning > > env_onenand.c: In function 'saveenv': > env_onenand.c:104: warning: format '%08lx' expects type 'long unsigned > int', but argument 2 has type 'loff_t' > > Is there already a fix available? > > Thanks > > Dirk > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - add dns
On Sunday 19 July 2009 19:30:43 Robin Getz wrote: > On Sat 18 Jul 2009 21:15, Mike Frysinger pondered: > > On Saturday 18 July 2009 20:27:00 Robin Getz wrote: > > > Does it make sense to have 4 different ones? (not to me)... > > > > > > Or something new & common in ./net.c:random_port() > > > > i would make a new patch that adds a new random_port() function and > > converts existing consumers to that, and then have the dns code rely on > > that. > > > > and you should adopt my implementation because the generated code is > > much much nicer than the others ;) > > At least on Blackfin - the sntp version and yours are computationally > equal - although I think yours ends up being more random - so yeah, I'll > use that one. any arch that has an instruction for doing the "and" operation should end up being computationally as simple as the Blackfin code. afaik, pretty much all do, and the ones who dont are screwed anyways, so nothing to be done for them. -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] ARM Cortex A8: Move OMAP3 specific reset handler
Because of the reset_cpu is soc specific, should be move to soc
Cc: Dirk Behme
Signed-off-by: Minkyu Kang
---
cpu/arm_cortexa8/omap3/Makefile |1 +
cpu/arm_cortexa8/omap3/reset.S | 36
cpu/arm_cortexa8/start.S| 14 --
3 files changed, 37 insertions(+), 14 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/reset.S
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index 1fbd0dc..eef165c 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++ b/cpu/arm_cortexa8/omap3/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).a
SOBJS := lowlevel_init.o
+SOBJS += reset.o
COBJS += board.o
COBJS += cache.o
diff --git a/cpu/arm_cortexa8/omap3/reset.S b/cpu/arm_cortexa8/omap3/reset.S
new file mode 100644
index 000..a53c408
--- /dev/null
+++ b/cpu/arm_cortexa8/omap3/reset.S
@@ -0,0 +1,36 @@
+/*
+ * Copyright (c) 2009 Samsung Electronics.
+ * Minkyu Kang
+ *
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+
+.global reset_cpu
+reset_cpu:
+ ldr r1, rstctl @ get addr for global reset
+ @ reg
+ mov r3, #0x2@ full reset pll + mpu
+ str r3, [r1]@ force reset
+ mov r0, r0
+_loop_forever:
+ b _loop_forever
+rstctl:
+ .word PRM_RSTCTRL
diff --git a/cpu/arm_cortexa8/start.S b/cpu/arm_cortexa8/start.S
index 66b4820..6bd6552 100644
--- a/cpu/arm_cortexa8/start.S
+++ b/cpu/arm_cortexa8/start.S
@@ -500,17 +500,3 @@ finished_inval:
@ but we compile with armv5
ldmfd r13!, {r0 - r5, r7, r9 - r12, pc}
-
-
- .align 5
-.global reset_cpu
-reset_cpu:
- ldr r1, rstctl @ get addr for global reset
- @ reg
- mov r3, #0x2@ full reset pll + mpu
- str r3, [r1]@ force reset
- mov r0, r0
-_loop_forever:
- b _loop_forever
-rstctl:
- .word PRM_RSTCTRL
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler
Hi,
It's already discussed. Actually it's required for adding new S5PC1xx
series based on arm cortext8.
Please apply it.
Thank you,
Kyungmin Park
On Mon, Jul 20, 2009 at 11:40 AM, Minkyu Kang wrote:
> Because of the reset_cpu is soc specific, should be move to soc
>
> Cc: Dirk Behme
> Signed-off-by: Minkyu Kang
> ---
> cpu/arm_cortexa8/omap3/Makefile | 1 +
> cpu/arm_cortexa8/omap3/reset.S | 36
> cpu/arm_cortexa8/start.S | 14 --
> 3 files changed, 37 insertions(+), 14 deletions(-)
> create mode 100644 cpu/arm_cortexa8/omap3/reset.S
>
> diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
> index 1fbd0dc..eef165c 100644
> --- a/cpu/arm_cortexa8/omap3/Makefile
> +++ b/cpu/arm_cortexa8/omap3/Makefile
> @@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
> LIB = $(obj)lib$(SOC).a
>
> SOBJS := lowlevel_init.o
> +SOBJS += reset.o
>
> COBJS += board.o
> COBJS += cache.o
> diff --git a/cpu/arm_cortexa8/omap3/reset.S b/cpu/arm_cortexa8/omap3/reset.S
> new file mode 100644
> index 000..a53c408
> --- /dev/null
> +++ b/cpu/arm_cortexa8/omap3/reset.S
> @@ -0,0 +1,36 @@
> +/*
> + * Copyright (c) 2009 Samsung Electronics.
> + * Minkyu Kang
> + *
> + * 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., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +
> +.global reset_cpu
> +reset_cpu:
> + ldr r1, rstctl @ get addr for global reset
> + @ reg
> + mov r3, #0x2 @ full reset pll + mpu
> + str r3, [r1] @ force reset
> + mov r0, r0
> +_loop_forever:
> + b _loop_forever
> +rstctl:
> + .word PRM_RSTCTRL
> diff --git a/cpu/arm_cortexa8/start.S b/cpu/arm_cortexa8/start.S
> index 66b4820..6bd6552 100644
> --- a/cpu/arm_cortexa8/start.S
> +++ b/cpu/arm_cortexa8/start.S
> @@ -500,17 +500,3 @@ finished_inval:
> @ but we compile with armv5
>
> ldmfd r13!, {r0 - r5, r7, r9 - r12, pc}
> -
> -
> - .align 5
> -.global reset_cpu
> -reset_cpu:
> - ldr r1, rstctl @ get addr for global reset
> - @ reg
> - mov r3, #0x2 @ full reset pll + mpu
> - str r3, [r1] @ force reset
> - mov r0, r0
> -_loop_forever:
> - b _loop_forever
> -rstctl:
> - .word PRM_RSTCTRL
> --
> 1.5.4.3
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] S5PC100: Add onenand_ipl for SMDKC100 support
Hi,
On Mon, Jul 20, 2009 at 5:04 AM, Wolfgang Denk wrote:
> Dear HeungJun Kim,
>
> In message <350d1ec30906250121q4e860812s35054aaee8c20...@mail.gmail.com> you
> wrote:
>> The SMDKC100 Board has 256MB onenand.
>> So, It's bootable, if this patch is adapted thus the board use onenand_ipl.
>>
>> Signed-off-by: HeungJun, Kim
>>
>> ---
>>
>> This patch support onenand boot on SMDKC100 Board.
> ...
>> diff --git a/onenand_ipl/board/samsung/smdkc100/Makefile
>> b/onenand_ipl/board/samsung/smdkc100/Makefile
>> new file mode 100644
>> index 000..4301938
>> --- /dev/null
>> +++ b/onenand_ipl/board/samsung/smdkc100/Makefile
> ...
>> +ALL = $(onenandobj)onenand-ipl $(onenandobj)onenand-ipl.bin
>> $(onenandobj)onenand-ipl-2k.bin $(onenandobj)onenand-ipl-4k.bin
>
> This patch is white-space corrupted. I gues this happened here because
> the line was way too long.
>
>> --- a/onenand_ipl/onenand_read.c
>> +++ b/onenand_ipl/onenand_read.c
>> @@ -37,10 +37,24 @@
>> extern void *memcpy32(void *dest, void *src, int size);
>> #endif
>>
>> +
>> +
>
> Please do not arbitrary empty lines.
>
>> /* read a page with ECC */
>> static inline int onenand_read_page(ulong block, ulong page,
>> u_char * buf, int pagesize)
>> {
>> +#ifdef CONFIG_S5PC1XX
>> + unsigned int *p = (unsigned int *) buf;
>> + int mem_addr, i;
>> +
>> + mem_addr = MEM_ADDR(block, page, 0);
>> +
>> + pagesize >>= 2;
>> +
>> + for (i = 0; i < pagesize; i++)
>> + *p++ = *(volatile unsigned int *)(CMD_MAP_01(mem_addr));
>> +#else /* CONFIG_S5PC1XX */
>> +
>> unsigned long *base;
>
> I don't like to see such board specific code in global files.
I think it's not board specific code. S3C64XX and S5PC1XX series have
own OneNAND controller and to access the OneNAND, it should use the
this controller.
If you don't like the ifdef. we can separate the function but I'm not
sure it's really required.
>
> Also, please use I/O accessor functions instead of register accesses.
readl(...)? If yes, I agree it.
>
>> @@ -114,6 +129,9 @@ int onenand_read_block(unsigned char *buf)
>>
>> erasesize = ONENAND_PAGES_PER_BLOCK * pagesize;
>> nblocks = (CONFIG_SYS_MONITOR_LEN + erasesize - 1) >> erase_shift;
>> +#ifdef CONFIG_S5PC1XX
>> + nblocks = 1;
>> +#endif
>
> Again: why do we need such board specific code here?
>
It should be fixed.
Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] CONFIG naming convetion
On Sat 18 Jul 2009 18:25, Wolfgang Denk pondered: > > > > I guess we could back up a step and look at the users, and defined things > > as things that should be changed by: > > - arch maintainers (Core/CPU specific) > > - SoC maintainer (SoC specific) > > - Board maintainer (PCB specific) > > - End user of the above (changes options, but nothing from the above > list?) > > Frankly, this makes no sense to me. I have yet to see any such clear > split of roles and functions. When you bring up a new board, you > usually have to check everything. > > The only split that made, and still makes, kind of sense to me is the > split into normal users (CONFIG_) versus "root" (CONFIG_SYS_) groups. I guess I still don't understand how you are making the distinction between "normal users" and "root" - I think there are more categories of users between those two... People responsible for the archicture/CPU core may set things up, and not want anyone to change things - on any SoC or Board. People responsible for SoC developments should be able to take what the arch provider delivers, write a few device drivers, make some specific choices that anyone who implements that SoC is going to have to live with. People responsible for Board porting, should be able to take what the SoC provider delivers, customise things for their platform, and move on. Then there are end users - which must live with the choices that all three have made, until they get their own hardware back, or in the case where the hardware is a module - just change some non-hardware related options. So maybe it is core, chip, PCB, and user. In some cases - all 4 categories are the same person - in many cases they are not. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] Add "chip_config" command for PPC4xx bootstrap configuration
This patch adds a generic command for programming I2C bootstrap
eeproms on PPC4xx. An implementation for Canyonlands board is
included.
The command name is intentionally chosen not to be PPC4xx specific.
This way other CPU's/SoC's can implement a similar command under
the same name, perhaps with a different syntax.
Usage on Canyonlands:
=> chip_config
Available configurations (I2C address 0x52):
600-nor - NOR CPU: 600 PLB: 200 OPB: 100 EBC: 100
600-nand - NAND CPU: 600 PLB: 200 OPB: 100 EBC: 100
800-nor - NOR CPU: 800 PLB: 200 OPB: 100 EBC: 100
800-nand - NAND CPU: 800 PLB: 200 OPB: 100 EBC: 100
1000-nor - NOR CPU:1000 PLB: 200 OPB: 100 EBC: 100
1000-nand- NAND CPU:1000 PLB: 200 OPB: 100 EBC: 100
1066-nor - NOR CPU:1066 PLB: 266 OPB: 88 EBC: 88 ***
1066-nand- NAND CPU:1066 PLB: 266 OPB: 88 EBC: 88
=> chip_config 600-nor
Using configuration:
600-nor - NOR CPU: 600 PLB: 200 OPB: 100 EBC: 100
done (dump via 'i2c md 52 0.1 10')
Reset the board for the changes to take effect
Other 4xx boards will be migrated to use this command soon
as well.
Signed-off-by: Stefan Roese
Signed-off-by: Dirk Eibach
Cc: Matthias Fuchs
sdfsdf
Signed-off-by: Stefan Roese
sdfsdf
Signed-off-by: Stefan Roese
---
v4:
- Command name changed from cpu_config to chip_config
- Used eeprom_read/eeprom_write if available
- Added CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET
v3:
- Line length of one printf reduced
v2:
- Patch authorship changes to Stefan
- s-o-b from Dirk added
- Added current configuration detection
- Minor coding style cleanup
board/amcc/canyonlands/Makefile |5 +-
board/amcc/canyonlands/bootstrap.c | 195 --
board/amcc/canyonlands/chip_config.c | 55 ++
cpu/ppc4xx/Makefile |3 +
cpu/ppc4xx/cmd_chip_config.c | 142
include/asm-ppc/ppc4xx_config.h | 42 +++
include/configs/canyonlands.h|6 +
7 files changed, 251 insertions(+), 197 deletions(-)
delete mode 100644 board/amcc/canyonlands/bootstrap.c
create mode 100644 board/amcc/canyonlands/chip_config.c
create mode 100644 cpu/ppc4xx/cmd_chip_config.c
create mode 100644 include/asm-ppc/ppc4xx_config.h
diff --git a/board/amcc/canyonlands/Makefile b/board/amcc/canyonlands/Makefile
index 2aeead6..12f8a64 100644
--- a/board/amcc/canyonlands/Makefile
+++ b/board/amcc/canyonlands/Makefile
@@ -25,10 +25,11 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := $(BOARD).o
-COBJS += bootstrap.o
+COBJS-y:= $(BOARD).o
+COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.o
SOBJS := init.o
+COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
SOBJS := $(addprefix $(obj),$(SOBJS))
diff --git a/board/amcc/canyonlands/bootstrap.c
b/board/amcc/canyonlands/bootstrap.c
deleted file mode 100644
index 6dc2cca..000
--- a/board/amcc/canyonlands/bootstrap.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * (C) Copyright 2008
- * Stefan Roese, DENX Software Engineering, s...@denx.de.
- *
- * 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., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- */
-
-#include
-#include
-#include
-#include
-
-/*
- * NOR and NAND boot options change bytes 5, 6, 8, 9, 11. The
- * values are independent of the rest of the clock settings.
- */
-
-#define NAND_COMPATIBLE0x01
-#define NOR_COMPATIBLE 0x02
-
-#define I2C_EEPROM_ADDR 0x52
-
-static char *config_labels[] = {
- "CPU: 600 PLB: 200 OPB: 100 EBC: 100",
- "CPU: 800 PLB: 200 OPB: 100 EBC: 100",
- "CPU:1000 PLB: 200 OPB: 100 EBC: 100",
- "CPU:1066 PLB: 266 OPB: 88 EBC: 88",
- NULL
-};
-
-static u8 boot_configs[][17] = {
- {
- (NAND_COMPATIBLE | NOR_COMPATIBLE),
- 0x86, 0x80, 0xce, 0x1f, 0x79, 0x80, 0x00, 0xa0, 0x40, 0x08,
- 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
- },
- {
- (NAND_COMPATIBLE | NOR_COMPATIBLE),
- 0x86, 0x80, 0xba, 0x14, 0x99, 0x80, 0x00, 0xa0, 0x40, 0x08,
- 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
- },
- {
- (NAND_COMPATIBLE | NOR_COMPATIBLE),
-
Re: [U-Boot] [PATCH v4] Add "chip_config" command for PPC4xx bootstrap configuration
> Other 4xx boards will be migrated to use this command soon > as well. > > Signed-off-by: Stefan Roese > Signed-off-by: Dirk Eibach > Cc: Matthias Fuchs > > sdfsdf > > Signed-off-by: Stefan Roese > > sdfsdf > > Signed-off-by: Stefan Roese Hi Stefan, Looks like there's some squashed commit remnants above? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Add "chip_config" command for PPC4xx bootstrap configuration
On Monday 20 July 2009 07:24:41 Peter Tyser wrote: > > > > Other 4xx boards will be migrated to use this command soon > > as well. > > > > Signed-off-by: Stefan Roese > > Signed-off-by: Dirk Eibach > > Cc: Matthias Fuchs > > > > sdfsdf > > > > Signed-off-by: Stefan Roese > > > > sdfsdf > > > > Signed-off-by: Stefan Roese > > Hi Stefan, > Looks like there's some squashed commit remnants above? Ups. Will resend in a short while. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use
Hi, On Sun, Jul 12, 2009 at 9:58 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 17:10 Sat 11 Jul , Kyungmin Park wrote: >> Use the common OneNAND linker script. >> >> Signed-off-by: Kyungmin Park >> --- >> diff --git a/onenand_ipl/board/apollon/u-boot.onenand.lds >> b/onenand_ipl/u-boot-onenand.lds >> similarity index 100% >> rename from onenand_ipl/board/apollon/u-boot.onenand.lds >> rename to onenand_ipl/u-boot-onenand.lds > this is arch specific > please move it to lib_arm/ > I want to make a conclusion. Don't you change your mind? Please give your opinion. Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to reduce size of U-Boot image (i.MX31, NAND-Flash)
Hello, I'm trying to optimize the u-boot image I get after compiling. It's size is 13XkB depending on the features I define. I'm using a i.MX31 processor and only NAND-Flash. I think it should be possible to get a smaller Image. Are there some common tricks, or do you have some suggestions how to reduce the size of u-boot? Thanks in advance. Best Regards Ulrich Gerster ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot image support
From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] On Behalf Of
Prafulla Wadaskar [prafu...@marvell.com]
Sent: Sunday, July 19, 2009 10:57 AM
To: Wolfgang Denk
Cc: Manas Saksena; Ronen Shitrit; Nicolas Pitre; u-boot@lists.denx.de; Ashish
Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
Subject: Re: [U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot
image support
Dear Wolfgang
Thanks for your quick feedback
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Sunday, July 19, 2009 3:33 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit;
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 2/3] tools: mkimage
> (type=kwbimage) kirkwood boot image support
> > diff --git a/tools/kwbimage.h b/tools/kwbimage.h new file
> mode 100644
> > index 000..c54b701
> > --- /dev/null
> > +++ b/tools/kwbimage.h
> > ...
> > +/* typedefs */
> > +typedef char s8;
> > +typedef unsigned char u8;
> > +
> > +typedef int s32;
> > +typedef unsigned int u32;
> > +
> > +typedef short s16;
> > +typedef unsigned short u16;
> > +
> > +typedef long s64;
> > +typedef unsigned long u64;
>
> Please get rid of these.
Hi Wolfgang
Any suggestions for this?
I could used or but these typedefs are ifdefed
under __KERNEL_STRICT_NAMES and __KERNEL__.
I don't wish to redefine or disturb them for kwbimage support
Regards..
Prafulla . .
>
> > diff --git a/tools/mkimage.c b/tools/mkimage.c index
> c5b593c..9a11071
> > 100644
> > --- a/tools/mkimage.c
> > +++ b/tools/mkimage.c
> > @@ -24,6 +24,7 @@
> >
> > #include "mkimage.h"
> > #include
> > +#include "kwbimage.h"
> >
> > extern int errno;
> >
> > @@ -251,7 +252,13 @@ NXTARG:;
> > * write dummy header, to be fixed later
> > */
> > int hdr_size;
> > - hdr_size = image_get_header_size ();
> > +
> > + if (opt_type == IH_TYPE_KWBIMAGE) {
> > + hdr = kwbimage_get_header_ptr();
> > + hdr_size = kwbimage_get_header_size ();
> > + } else
> > + hdr_size = image_get_header_size ();
> > +
> > memset (hdr, 0, hdr_size);
> > if (write(ifd, hdr, hdr_size) != hdr_size) {
> > fprintf (stderr, "%s: Write error on %s: %s\n",
> > @@ -339,6 +346,19 @@ NXTARG:;
> >
> > hdr = (image_header_t *)ptr;
> >
> > + /* Build new header */
> > + if (opt_type == IH_TYPE_KWBIMAGE) {
> > + checksum = kwbimage_checksum32((void *)ptr,
> sbuf.st_size, 0);
> > +
> > + if (write(ifd, &checksum, sizeof(uint32_t))
> > + != sizeof(uint32_t)) {
> > + fprintf (stderr, "%s: Checksum wr err
> on %s: %s\n",
> > + cmdname, imagefile, strerror(errno));
> > + exit (EXIT_FAILURE);
> > + }
> > + sbuf.st_size += sizeof(uint32_t);
> > + kwbimage_set_header (hdr, &sbuf, addr, ep, name);
> > + } else {
> > checksum = crc32 (0,
> > (const char *)(ptr + hdr_size),
> > sbuf.st_size - hdr_size);
> > @@ -361,6 +381,7 @@ NXTARG: ;
> >
> > image_print_contents (hdr);
> >
> > + }
> > (void) munmap((void *)ptr, sbuf.st_size);
> >
> > /* We're a bit of paranoid */
>
> Hmm... it seems you add only image creation code. But "mkimage -l"
> should work on such an image, too. And "imls" in U-Boot
> should be working, too.
Well I will disable other generic mkimage options including -l for kwbimage ;-)
Can we add this in second part which is not required too?
For me great thing is that we can support kwimage generation through mkimage.
Regards..
Prafulla . .
>
> 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 "Plan to throw one away. You will anyway."
> - Fred Brooks, "The Mythical Man Month"
>
___
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 v5] Add "chip_config" command for PPC4xx bootstrap configuration
This patch adds a generic command for programming I2C bootstrap
eeproms on PPC4xx. An implementation for Canyonlands board is
included.
The command name is intentionally chosen not to be PPC4xx specific.
This way other CPU's/SoC's can implement a similar command under
the same name, perhaps with a different syntax.
Usage on Canyonlands:
=> chip_config
Available configurations (I2C address 0x52):
600-nor - NOR CPU: 600 PLB: 200 OPB: 100 EBC: 100
600-nand - NAND CPU: 600 PLB: 200 OPB: 100 EBC: 100
800-nor - NOR CPU: 800 PLB: 200 OPB: 100 EBC: 100
800-nand - NAND CPU: 800 PLB: 200 OPB: 100 EBC: 100
1000-nor - NOR CPU:1000 PLB: 200 OPB: 100 EBC: 100
1000-nand- NAND CPU:1000 PLB: 200 OPB: 100 EBC: 100
1066-nor - NOR CPU:1066 PLB: 266 OPB: 88 EBC: 88 ***
1066-nand- NAND CPU:1066 PLB: 266 OPB: 88 EBC: 88
=> chip_config 600-nor
Using configuration:
600-nor - NOR CPU: 600 PLB: 200 OPB: 100 EBC: 100
done (dump via 'i2c md 52 0.1 10')
Reset the board for the changes to take effect
Other 4xx boards will be migrated to use this command soon
as well.
Signed-off-by: Stefan Roese
Signed-off-by: Dirk Eibach
Cc: Matthias Fuchs
---
v5:
- Removed bogus lines from commit text
v4:
- Command name changed from cpu_config to chip_config
- Used eeprom_read/eeprom_write if available
- Added CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET
v3:
- Line length of one printf reduced
v2:
- Patch authorship changes to Stefan
- s-o-b from Dirk added
- Added current configuration detection
- Minor coding style cleanup
board/amcc/canyonlands/Makefile |5 +-
board/amcc/canyonlands/bootstrap.c | 195 --
board/amcc/canyonlands/chip_config.c | 55 ++
cpu/ppc4xx/Makefile |3 +
cpu/ppc4xx/cmd_chip_config.c | 142
include/asm-ppc/ppc4xx_config.h | 42 +++
include/configs/canyonlands.h|6 +
7 files changed, 251 insertions(+), 197 deletions(-)
delete mode 100644 board/amcc/canyonlands/bootstrap.c
create mode 100644 board/amcc/canyonlands/chip_config.c
create mode 100644 cpu/ppc4xx/cmd_chip_config.c
create mode 100644 include/asm-ppc/ppc4xx_config.h
diff --git a/board/amcc/canyonlands/Makefile b/board/amcc/canyonlands/Makefile
index 2aeead6..12f8a64 100644
--- a/board/amcc/canyonlands/Makefile
+++ b/board/amcc/canyonlands/Makefile
@@ -25,10 +25,11 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := $(BOARD).o
-COBJS += bootstrap.o
+COBJS-y:= $(BOARD).o
+COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.o
SOBJS := init.o
+COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
SOBJS := $(addprefix $(obj),$(SOBJS))
diff --git a/board/amcc/canyonlands/bootstrap.c
b/board/amcc/canyonlands/bootstrap.c
deleted file mode 100644
index 6dc2cca..000
--- a/board/amcc/canyonlands/bootstrap.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * (C) Copyright 2008
- * Stefan Roese, DENX Software Engineering, s...@denx.de.
- *
- * 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., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- */
-
-#include
-#include
-#include
-#include
-
-/*
- * NOR and NAND boot options change bytes 5, 6, 8, 9, 11. The
- * values are independent of the rest of the clock settings.
- */
-
-#define NAND_COMPATIBLE0x01
-#define NOR_COMPATIBLE 0x02
-
-#define I2C_EEPROM_ADDR 0x52
-
-static char *config_labels[] = {
- "CPU: 600 PLB: 200 OPB: 100 EBC: 100",
- "CPU: 800 PLB: 200 OPB: 100 EBC: 100",
- "CPU:1000 PLB: 200 OPB: 100 EBC: 100",
- "CPU:1066 PLB: 266 OPB: 88 EBC: 88",
- NULL
-};
-
-static u8 boot_configs[][17] = {
- {
- (NAND_COMPATIBLE | NOR_COMPATIBLE),
- 0x86, 0x80, 0xce, 0x1f, 0x79, 0x80, 0x00, 0xa0, 0x40, 0x08,
- 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
- },
- {
- (NAND_COMPATIBLE | NOR_COMPATIBLE),
- 0x86, 0x80, 0xba, 0x14, 0x99, 0x80, 0x00, 0xa0, 0x40, 0x08,
- 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
- },
- {
- (NAND_COMPATIBLE | NOR_COMPATIBLE),
- 0x86, 0x82, 0x96, 0x19, 0xb9,
Re: [U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot image support
From: Jean-Christophe PLAGNIOL-VILLARD [plagn...@jcrosoft.com] Sent: Sunday, July 19, 2009 2:55 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek Subject: Re: [U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot image support On 07:15 Sun 19 Jul , Prafulla Wadaskar wrote: > For more details refer docs/README.kwbimage > > Signed-off-by: Prafulla Wadaskar > --- > Makefile|5 ++ > common/image.c |1 + > doc/README.kwbimage | 77 ++ > include/image.h |1 + > tools/Makefile |1 + > tools/kwbimage.c| 181 > +++ > tools/kwbimage.h| 105 + > tools/mkimage.c | 23 ++- > 8 files changed, 393 insertions(+), 1 deletions(-) > create mode 100644 doc/README.kwbimage > create mode 100644 tools/kwbimage.c > create mode 100644 tools/kwbimage.h > > diff --git a/Makefile b/Makefile > index 55fc2a3..b9e45ed 100644 > --- a/Makefile > +++ b/Makefile > @@ -339,6 +339,10 @@ $(obj)u-boot.img:$(obj)u-boot.bin > sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \ > -d $< $@ > > +$(obj)u-boot.kwb:$(obj)u-boot.bin > + ./tools/mkimage -n ./board/$(BOARDDIR)/kwbimage.cfg \ > + -T kwbimage -a $(TEXT_BASE) -e $(TEXT_BASE) -d $< $@ It will be better to make it a few more generic (and btw fix the out of tree support) as this MKIMAGE = $(OBJTREE)/tools/mkimage [prafulla] this is generic change and should be done for other mkimage references too. for kwbimage patch I am skipping this, I will issue separate patch for this. $(obj)u-boot.kwb: $(obj)u-boot.bin $(MKIMAGE) -n $(KWD_CONFIG) -T kwbimage -a $(TEXT_BASE) \ -e $(TEXT_BASE) -d $< $@ [prafulla] done.. and in the board config.mk or soc anyother config.mk KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg [prafulla] done in board config.mk, thanks for this suggestion, this will add more flexibility to share kwbimage config file for multiple boards Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] new video driver for bus vcxk framebuffers
Hello Anatolij, >> +initialize the reset line to vcxk hardware and release it from reset > > Looking on the changes to board configuration file > "include/configs/EB+MCF-EV123.h" in the second patch of this series > I now realize that most of these CONFIG_SYS_ macros above expand to > C code, so these are not configuration options any more. > I tend to reject all this. CONFIG_SYS_ options are supposed to be options > and not board specific code. VCxK.c driver you removed by this patch > series did it in more correct way, I think. > What about moving this code to functions which use board specific macros? > These functions should be placed in this new video driver then. > I will complete review the code. I think, i can sent a new patch set within one week Best regards, Jens Scharsig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
