Re: [U-Boot] [PATCH ARM] updates the at91 main_clock calculation
Am 16.02.2010 16:23, schrieb Tom: > Daniel Gorsulowski wrote: >> Jens Scharsig wrote: >>> * updates the conditional main_clock calculation (if AT91_MAIN_CLOCK >>> defined) to c structure SoC access >>> * add need register flags >>> >>> >>> Signed-off-by: Jens Scharsig >>> --- >>> cpu/arm926ejs/at91/clock.c |7 --- >>> include/asm-arm/arch-at91/at91_pmc.h |3 +++ >>> 2 files changed, 7 insertions(+), 3 deletions(-) >>> >> ... >> >> Thank you, now the updated otc570 builds without errors. >> I didn't check, whether the board boots, but I guess it does. >> > Were you going to check in the next couple of days ? > Tom > > Checked... board boots. Btw. there are some warnings during build: mkimage.c: In function ‘main’: mkimage.c:204: warning: dereferencing type-punned pointer will break strict-aliasing rules mkimage.c:222: warning: dereferencing type-punned pointer will break strict-aliasing rules soft_i2c.c: In function 'send_reset': soft_i2c.c:103: warning: unused variable 'pio' soft_i2c.c: In function 'send_start': soft_i2c.c:130: warning: unused variable 'pio' soft_i2c.c: In function 'send_stop': soft_i2c.c:147: warning: unused variable 'pio' soft_i2c.c: In function 'send_ack': soft_i2c.c:166: warning: unused variable 'pio' soft_i2c.c: In function 'write_byte': soft_i2c.c:185: warning: unused variable 'pio' soft_i2c.c: In function 'read_byte': soft_i2c.c:259: warning: unused variable 'pio' atmel_dataflash_spi.c:25:2: warning: #warning Please update to use C structur SoC access ! atmel_usart.c:21:2: warning: #warning Please update to use C structur SoC access ! ohci-at91.c:30:2: warning: #warning Please update to use C structur SoC access ! Regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] s5pc1xx: support the GPIO interface
On 12 February 2010 18:29, Minkyu Kang wrote: > This patch adds support the GPIO interface > > Signed-off-by: Minkyu Kang > --- > cpu/arm_cortexa8/s5pc1xx/Makefile | 1 + > cpu/arm_cortexa8/s5pc1xx/gpio.c | 143 > +++ > include/asm-arm/arch-s5pc1xx/gpio.h | 29 +++ > 3 files changed, 173 insertions(+), 0 deletions(-) > create mode 100644 cpu/arm_cortexa8/s5pc1xx/gpio.c > applied to u-boot-samsung Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] s5pc1xx: update the README file
On 12 February 2010 18:29, Minkyu Kang wrote: > Because adds support the GPIO Interface, README file is updated. > > Signed-off-by: Minkyu Kang > --- > doc/README.s5pc1xx | 18 +- > 1 files changed, 17 insertions(+), 1 deletions(-) > applied to u-boot-samsung Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] newbie mailing list (WAS Re: [U-Boot-Users] test program crashing)
Dear Michael Trimarchi, please note that the old list at SourceForge is dead. Don;t use it any more. In message <4b7b95eb.4030...@gandalf.sssup.it> you wrote: > What do you think about a mailing list for newbie? So people can ask > there and someone can help them > in the startup. The welcome message can give them all the info to init: What would that help? Nothing. Guess how many people I refer to documents like http://catb.org/esr/faqs/smart-questions.html or http://www.netmeister.org/news/learn2quote.html do actually _read_ this stuff? The problem was not a newbie issue, but ignorance - not bothering to think a second how anybody could provide help based on zero information. I feel 42 is a perfectly reasonable answer to the question :-) 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 Experience is what causes a person to make new mistakes instead of old ones. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] s5pc1xx: update the README file
Dear Minkyu Kang, In message <1f3430fb1002170236q7bdb3262q1eb929fdafab2...@mail.gmail.com> you wrote: > On 12 February 2010 18:29, Minkyu Kang wrote: > > Because adds support the GPIO Interface, README file is updated. > > > > Signed-off-by: Minkyu Kang > > --- > > doc/README.s5pc1xx | =A0 18 +- > > 1 files changed, 17 insertions(+), 1 deletions(-) > > applied to u-boot-samsung Would it be possible to squash these two commits into one? They actually are one change and should not be split apart. 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 amount of time between slipping on the peel and landing on the pavement is precisely 1 bananosecond. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] newbie mailing list (WAS Re: [U-Boot-Users] test program crashing)
Hi Wolfgang Denk wrote: > Dear Michael Trimarchi, > > please note that the old list at SourceForge is dead. Don;t use it any > more. > I know that. I didn't check before sending > In message <4b7b95eb.4030...@gandalf.sssup.it> you wrote: > > >> What do you think about a mailing list for newbie? So people can ask >> there and someone can help them >> in the startup. The welcome message can give them all the info to init: >> > > What would that help? Nothing. > Some people use u-boot and do little change and some people contribute a lot to the project. So a lot of these mails can go there. In a long term I think that is good for the project but this is my personal opinion > Guess how many people I refer to documents like > http://catb.org/esr/faqs/smart-questions.html or > http://www.netmeister.org/news/learn2quote.html > do actually _read_ this stuff? > > > The problem was not a newbie issue, but ignorance - not bothering to > think a second how anybody could provide help based on zero > information. > > I feel 42 is a perfectly reasonable answer to the question :-) > Agree > Best regards, > > Wolfgang Denk > Best Regards Michael Trimarchi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] s5pc1xx: update the README file
Dear Wolfgang, On 17 February 2010 20:58, Wolfgang Denk wrote: > Dear Minkyu Kang, > > In message <1f3430fb1002170236q7bdb3262q1eb929fdafab2...@mail.gmail.com> you > wrote: >> On 12 February 2010 18:29, Minkyu Kang wrote: >> > Because adds support the GPIO Interface, README file is updated. >> > >> > Signed-off-by: Minkyu Kang >> > --- >> > doc/README.s5pc1xx | =A0 18 +- >> > 1 files changed, 17 insertions(+), 1 deletions(-) >> >> applied to u-boot-samsung > > Would it be possible to squash these two commits into one? They > actually are one change and should not be split apart. Thanks. I already pushed these patches. Do I need to revert the patchset? Or, give me your opinion, if you have any idea. > > 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 amount of time between slipping on the peel and landing on the > pavement is precisely 1 bananosecond. > Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
Hello Matthias. > i found some more information about the precharge workaround: > [...] > please test the below patch on your board when you get a chance. it > should be pretty much the same sequence that worked for you, i just > removed the *workaround* that makes my boards hang and restructured > the code a little It boots, but it takes one second more than my code -- don't know why. And neither the ethernet nor usb work properly any more. I suggest it's best if you leave your previous code here, and I'll have mine for my board in a different directory. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add explicit bbt creation to commandline
Scott Wood-2 wrote:
>
> On Fri, Feb 12, 2010 at 06:14:51PM -0800, Steven Zedeck wrote:
>> Its in board/atmel/at91sam9rlek/nand.c
>>
>> It doesn't do much but set up the various GPIO connections. Here's the
>> function:
>>
>> int board_nand_init(struct nand_chip *nand)
>> {
>> nand->ecc.mode = NAND_ECC_SOFT;
>> #ifdef CFG_NAND_DBW_16
>> nand->options = NAND_BUSWIDTH_16;
>> #endif
>> nand->cmd_ctrl = at91sam9rlek_nand_hwcontrol;
>> nand->dev_ready = at91sam9rlek_nand_ready;
>> nand->chip_delay = 20;
>>
>> return 0;
>> }
>
> Add "nand->options |= NAND_USE_FLASH_BBT;".
>
> -Scott
>
>
Scott,
I really appreciate your help. I added what you suggested, except since we
are using an 8 bit wide bus and not 16 I had to do the following:
#ifdef CFG_NAND_DBW_8
nand->options |= NAND_USE_FLASH_BBT;
#endif
CFG_NAND_DBW_8 is set in my configs.h file.
Now when my board boots I get this and then it just stops:
NAND: Entering nand_init
Nand Base 0x4000
Bad block table not found for chip 0
Bad block table not found for chip 0
That comes from nand_bbt.c
Clearly there is something I'm missing regarding how the BBT is created and
utilized in Uboot.
thanks,
Steve
--
View this message in context:
http://old.nabble.com/-PATCH--add-explicit-bbt-creation-to-commandline-tp18299804p27625639.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: Added support for taskit Stamp9G20 and PortuxG20
Signed-off-by: Achim Ehrlich
---
Makefile |9 ++
board/taskit/stamp9G20/Makefile| 56 ++
board/taskit/stamp9G20/config.mk |1 +
board/taskit/stamp9G20/led.c | 35 ++
board/taskit/stamp9G20/partition.c | 40 +++
board/taskit/stamp9G20/stamp9G20.c | 200
include/configs/stamp9G20.h| 197 +++
7 files changed, 538 insertions(+), 0 deletions(-)
create mode 100644 board/taskit/stamp9G20/Makefile
create mode 100644 board/taskit/stamp9G20/config.mk
create mode 100644 board/taskit/stamp9G20/led.c
create mode 100644 board/taskit/stamp9G20/partition.c
create mode 100644 board/taskit/stamp9G20/stamp9G20.c
create mode 100644 include/configs/stamp9G20.h
diff --git a/Makefile b/Makefile
index 524b9da..ef1a7d4 100644
--- a/Makefile
+++ b/Makefile
@@ -2906,6 +2906,15 @@ TNY_A9260_config : unconfig
@echo "#define CONFIG_$(@:_config=) 1" >$(obj)include/config.h
@$(MKCONFIG) -a tny_a9260 arm arm926ejs tny_a9260 calao at91
+portuxG20_config \
+stamp9G20_config : unconfig
+ @mkdir -p $(obj)include
+ @if [ "$(findstring portux,$@)" ] ; then \
+ echo "#define CONFIG_PORTUXG20 1" >$(obj)include/config.h; \
+ $(XECHO) "... PortuxG20";\
+ fi;
+ @$(MKCONFIG) -a stamp9G20 arm arm926ejs stamp9G20 taskit at91
+
## ARM Integrator boards - see doc/README-integrator for more info.
integratorap_config\
diff --git a/board/taskit/stamp9G20/Makefile b/board/taskit/stamp9G20/Makefile
new file mode 100644
index 000..ef82428
--- /dev/null
+++ b/board/taskit/stamp9G20/Makefile
@@ -0,0 +1,56 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop
+# Lead Tech Design
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y+= stamp9G20.o
+COBJS-y+= led.o
+COBJS-$(CONFIG_HAS_DATAFLASH) += partition.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/taskit/stamp9G20/config.mk b/board/taskit/stamp9G20/config.mk
new file mode 100644
index 000..ff2cfd1
--- /dev/null
+++ b/board/taskit/stamp9G20/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x23f0
diff --git a/board/taskit/stamp9G20/led.c b/board/taskit/stamp9G20/led.c
new file mode 100644
index 000..dc6ac63
--- /dev/null
+++ b/board/taskit/stamp9G20/led.c
@@ -0,0 +1,35 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop
+ * Lead Tech Design
+ *
+ * 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
+#include
+
+void coloured_LED_init(void)
+{
+ /* Enable clock */
+ at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_PIOC);
+}
diff --git a/board/taskit/stam
Re: [U-Boot] [PATCH 1/4 v4] arm: add support for the mgcoge2_arm_p1a board from keymile
> -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Monday, February 15, 2010 1:37 PM > To: Prafulla Wadaskar > Cc: U-Boot user list; Wolfgang Denk; Scott Wood; Stefan Roese > Subject: Re: [PATCH 1/4 v4] arm: add support for the > mgcoge2_arm_p1a board from keymile > > Hello Prafulla, > > Prafulla Wadaskar wrote: > >> -Original Message- > >> From: Heiko Schocher [mailto:h...@denx.de] > >> Sent: Friday, February 12, 2010 1:36 PM > >> To: U-Boot user list > >> Cc: Wolfgang Denk; Prafulla Wadaskar; Scott Wood; Stefan Roese > >> Subject: [PATCH 1/4 v4] arm: add support for the > >> mgcoge2_arm_p1a board from keymile > >> > >> Add support for the ARM part of the mgcoge2. This board > >> is based on the Marvell Kirkwood (88F6281) SoC. As there > >> come more board variants, common code is stored in > >> board/keymile/km_arm/km_arm.c > >> > >> Signed-off-by: Holger Brunck > >> Signed-off-by: Stefan Roese > >> Signed-off-by: Heiko Schocher ...snip... > >> diff --git a/board/keymile/common/common.c > >> b/board/keymile/common/common.c > >> index ec27bda..7b4eefd 100644 > >> --- a/board/keymile/common/common.c > >> +++ b/board/keymile/common/common.c > >> @@ -35,6 +35,7 @@ > >> #include > >> #endif > >> > >> +#include "../common/common.h" > > > > Can't you use "common.h" here ? > > No, this is "just" a keymile specific header for including > functions, which are "common" for all keymile boards ... More important common.h that you are referring here is missing in this patch. Secondly, since you are in the same folder you should use "common.h" instead of absolute path" ...snip... > >> + > >> + /* > >> + * arch number of board > >> + */ > >> + gd->bd->bi_arch_number = MACH_TYPE_SUEN3; > > > > This does not match with the board you are supporting, > better to use similar name > > As I said above, this boards are all the same, just different > hardwarerevisions, so theys all have one MACH_TYPE_ ... To me, two boards are two different hardware and must have associated with two different machine ids. How will you manage picking different board setups in kernel for same machine ID? If not Machine ID, you can think of using EEPROM available on board to store board version info and use it selectively. > > >> + > >> + /* address of boot parameters */ > >> + gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100; > >> + > >> +#if defined(CONFIG_KIRKWOOD_GPIO) > > > > Avoid this at least for this board patch > > Don;t understand this! Why? The board uses this pins for > I2C bitbang, so I must initialize the pins ... why you need to ifdef this? For this particular board it should be hard coded, I think you can do this for other board support if needed. First patch in this series has to be clean standard board support without any ifdefs, subsequent patches add support for different hardware version, there if you use ifdef it makes more sense > > >> + /* init the GPIO for I2C Bitbang driver */ > >> + kw_gpio_set_valid(SUEN3_SDA_PIN, 1); > >> + kw_gpio_set_valid(SUEN3_SCL_PIN, 1); > >> + kw_gpio_direction_output(SUEN3_SDA_PIN, 0); > >> + kw_gpio_direction_output(SUEN3_SCL_PIN, 0); > >> +#if defined(CONFIG_SYS_EEPROM_WREN) > >> + kw_gpio_set_valid(SUEN3_ENV_WP, 38); > >> + kw_gpio_direction_output(SUEN3_ENV_WP, 1); > >> +#endif > >> +#endif > >> + return 0; > >> +} Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v4] arm: add support for the suen3_p1a board from keymile
> -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Monday, February 15, 2010 1:40 PM > To: Prafulla Wadaskar > Cc: U-Boot user list; Wolfgang Denk; Scott Wood; Stefan Roese > Subject: Re: [PATCH 3/4 v4] arm: add support for the > suen3_p1a board from keymile > > Hello Prafulla, > > Prafulla Wadaskar wrote: > >> -Original Message- > >> From: Heiko Schocher [mailto:h...@denx.de] > >> Sent: Friday, February 12, 2010 1:36 PM > >> To: U-Boot user list > >> Cc: Wolfgang Denk; Prafulla Wadaskar; Scott Wood; Stefan Roese > >> Subject: [PATCH 3/4 v4] arm: add support for the suen3_p1a > >> board from keymile > >> > >> This patch adds support for the Keymile suen3_p1a board which > >> is based on the Marvell Kirkwood (88F6281) SoC. As this > >> is a variant of the mgcoge2_arm_p1a board, this board > >> also uses common code stored in board/keymile/km_arm/km_arm.c > > > > I hope each board that you are supporting have registered > MACHIN_ID, if not pls do it and code it in C file. > > No, this 4 boards are all the same, just different > hardwarerevisions ... Hi Heiko If these boards are all same, why don't you add single board support? That will resolve all issues and even MACHINE_ID issue. To me, any hardware revision is new board entity. If the hardware changes are very minimal those can be addressed by passing additional build arguments like "BOARDREV=V1" or handle them by reading h/w version from hardware itself, as I said earlier using EEPROM. At least you can have first board patch clean and complete. Regards.. Prafulla . . > > bye, > heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM] updates the at91 main_clock calculation
Daniel Gorsulowski wrote: >>> Jens Scharsig wrote: > soft_i2c.c: In function 'send_reset': > soft_i2c.c:103: warning: unused variable 'pio' --snip-- > soft_i2c.c: In function 'read_byte': > soft_i2c.c:259: warning: unused variable 'pio' There are two ways to define I2C_ macros: gpio or direct SoC access if you are using gpio to define macros, I think you get this warnings. If you are using direct SoC access (no gpio driver needed) there are no warnings e.g. #define I2C_ACTIVE writel(AT91_PMX_AA_TWD, &pio->pioa.mddr); #define I2C_TRISTATEwritel(AT91_PMX_AA_TWD, &pio->pioa.mder); and so on > atmel_dataflash_spi.c:25:2: warning: #warning Please update to use C structur > SoC access ! > atmel_usart.c:21:2: warning: #warning Please update to use C structur SoC > access ! > ohci-at91.c:30:2: warning: #warning Please update to use C structur SoC > access ! We need some volunteers, which convert the drivers. Regards Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add explicit bbt creation to commandline
Steven Zedeck wrote:
> Scott Wood-2 wrote:
>> On Fri, Feb 12, 2010 at 06:14:51PM -0800, Steven Zedeck wrote:
>>> int board_nand_init(struct nand_chip *nand)
>>> {
>>> nand->ecc.mode = NAND_ECC_SOFT;
>>> #ifdef CFG_NAND_DBW_16
>>> nand->options = NAND_BUSWIDTH_16;
>>> #endif
>>> nand->cmd_ctrl = at91sam9rlek_nand_hwcontrol;
>>> nand->dev_ready = at91sam9rlek_nand_ready;
>>> nand->chip_delay = 20;
>>>
>>> return 0;
>>> }
>> Add "nand->options |= NAND_USE_FLASH_BBT;".
[snip]
> I really appreciate your help. I added what you suggested, except since we
> are using an 8 bit wide bus and not 16 I had to do the following:
>
> #ifdef CFG_NAND_DBW_8
> nand->options |= NAND_USE_FLASH_BBT;
> #endif
I don't see why the ifdef is needed -- just don't put it inside (or
before) the other ifdef.
> Now when my board boots I get this and then it just stops:
> NAND: Entering nand_init
> Nand Base 0x4000
> Bad block table not found for chip 0
> Bad block table not found for chip 0
The messages are expected on the first boot -- but it should then create
the bad block table.
You'll have to debug to find out why it's hanging. If you don't set
NAND_USE_FLASH_BBT, does ordinary nand read/write from the u-boot prompt
work?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH kup4-boards: minor configuration changes
Dear Heydeck, Klaus-Jürgen,
In message
you wrote:
> also preparation for using hwconfig and device tree support
>
> Signed-off-by: Klaus Heydeck
Please consider using git-format-patch / git-send-email for submitting
patches.
> diff -purN u-boot.git/board/kup/common/kup.c u-boot/board/kup/common/kup.c
> --- u-boot.git/board/kup/common/kup.c 2010-02-16 09:02:08.0 +0100
> +++ u-boot/board/kup/common/kup.c 2010-02-17 13:03:51.0 +0100
> @@ -24,6 +24,24 @@
> #include
> #include
> #include "kup.h"
> +#ifdef CONFIG_KUP4_LOGO
> + #include "s1d13706.h"
> +#endif
> +
> +#undef DEBUG
> +#ifdef DEBUG
> +# define debugk(fmt,args...)printf(fmt ,##args)
> +#else
> +# define debugk(fmt,args...)
> +#endif
Please drop this. Use the standard debug() macro instead which does
the same.
> +#define PRINTF(fmt,args...)printf(fmt ,##args)
This seems bogus to me. Please drop it.
> @@ -31,7 +49,7 @@ int misc_init_f (void)
> volatile sysconf8xx_t *siu = &immap->im_siu_conf;
>
> while (siu->sc_sipend & 0x2000) {
> - /* printf("waiting for 5V VCC\n"); */
> +debugk("waiting for 5V VCC\n");
Please use TABs only for indentation.
> @@ -40,6 +58,14 @@ int misc_init_f (void)
> immap->im_ioport.iop_papar &= ~(PA_RS485);
> immap->im_ioport.iop_paodr &= ~(PA_RS485);
> immap->im_ioport.iop_padir |= (PA_RS485);
> +
> + /* IO Reset min 1 msec */
> + immap->im_ioport.iop_padat |= (PA_RESET_IO_01 | PA_RESET_IO_02);
> + immap->im_ioport.iop_papar &= ~(PA_RESET_IO_01 | PA_RESET_IO_02);
> + immap->im_ioport.iop_paodr &= ~(PA_RESET_IO_01 | PA_RESET_IO_02);
> + immap->im_ioport.iop_padir |= (PA_RESET_IO_01 | PA_RESET_IO_02);
> + udelay(1000);
> + immap->im_ioport.iop_padat &= ~(PA_RESET_IO_01 | PA_RESET_IO_02);
I am aware that the rest of the existing code is not any better, but we
should consider changing all this to using proper I/O accessors.
> +unsigned char swapbyte(unsigned char c)
> +{
> + unsigned char result=0;
> + int i=0;
> + for(i=0;i<8;++i){
> + result=result<<1;
> + result|=(c&1);
> + c=c>>1;
> + }
> + return result;
> +}
Please make this and similar functions "static".
> +/*>
> - */
> +/* Initialize the chip and the frame buffer driver. */
> +/*>
> - */
Incorrect multiline comment style.
> + /*
> +* Init ChipSelect #5 (S1D13768)
> +*/
> + memctl->memc_or5 = CONFIG_SYS_OR5;
> + memctl->memc_br5 = CONFIG_SYS_BR5;
> + __asm__ ("eieio");
Please use I/O accessors instead.
> + fb_info.VmemAddr = (unsigned char *) (S1D_PHYSICAL_VMEM_ADDR);
> + fb_info.RegAddr = (unsigned char *) (S1D_PHYSICAL_REG_ADDR);
> +
> + if S1D_VALUE *) fb_info.RegAddr)[0] != 0x28)
> + || (((S1D_VALUE *) fb_info.RegAddr)[1] != 0x14)) {
Please use I/O accessors instead. Please fix globally.
> + ((S1D_VALUE*)fb_info.RegAddr)[0xA8] = 0x00;
> + ((S1D_VALUE*)fb_info.RegAddr)[0xA9] = 0x80;
> + unsigned char s1d1gpio = ((S1D_VALUE*)fb_info.RegAddr)[0xAC];
Please do not declare variables in the middle of the code.
> + /* printf("s1d1gpio:0x%02X\n",s1d1gpio); */
Please do not add dead code. Drop this.
> + switch (s1d1gpio){
> +
> + case 0x02: /* STN */
> + for (i = 0; i < sizeof (aS1DRegs_stn) / sizeof (aS1DRegs_>
> stn[0]); i++)
> + {
> + s1dReg = aS1DRegs_stn[i].Index;
> + s1dValue = aS1DRegs_stn[i].Value;
> + ((S1D_VALUE *) fb_info.RegAddr)[s1dReg / sizeof (S1>
> D_VALUE)] = s1dValue;
> + }
Incorrect brace style / indentation. Please fix globally.
Lines too long. Please fix globally.
> + switch (bd->bi_busfreq){
> + case 4000:
> + ((S1D_VALUE *) fb_info.RegAddr)[0x05] = 0x32;
> + ((S1D_VALUE *) fb_info.RegAddr)[0x12] = 0x41;
> + break;
> + case 4800:
> + ((S1D_VALUE *) fb_info.RegAddr)[0x05] = 0x22;
> + ((S1D_VALUE *) fb_info.RegAddr)[0x12] = 0x34;
> + break;
What happens in case of rounding errors or the like?
> + default:
> + printf ("KUP4 S1D1: unknown busfrequency: %ld assum>
> ing 64 MHz\n", bd->bi_busfreq);
> + case 6400:
> + ((S1D_VALUE *) fb_info.RegAddr)[0x05] = 0x32;
> + ((S1D_VALUE *) fb_info.RegAddr)[0x12] = 0x66;
For conistency, please move the default case down.
All these magic indexes and values make not much sense to me.
Please convert the code to use a proper C str
Re: [U-Boot] [PATCH 2/2] s5pc1xx: update the README file
Dear Minkyu Kang, In message <1f3430fb1002170629p2528fdd2x3ffa396775715...@mail.gmail.com> you wrote: > > > Would it be possible to squash these two commits into one? They > > actually are one change and should not be split apart. =A0Thanks. > > I already pushed these patches. > Do I need to revert the patchset? > Or, give me your opinion, if you have any idea. If you agree, you can "git rebase -i" your branch and squash the two commits into one. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Microsoft Multitasking: several applications can crash at the same time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM] updates the at91 main_clock calculation
Daniel Gorsulowski wrote: > Am 16.02.2010 16:23, schrieb Tom: >> Daniel Gorsulowski wrote: >>> Jens Scharsig wrote: * updates the conditional main_clock calculation (if AT91_MAIN_CLOCK defined) to c structure SoC access * add need register flags Signed-off-by: Jens Scharsig --- cpu/arm926ejs/at91/clock.c |7 --- include/asm-arm/arch-at91/at91_pmc.h |3 +++ 2 files changed, 7 insertions(+), 3 deletions(-) >>> ... >>> >>> Thank you, now the updated otc570 builds without errors. >>> I didn't check, whether the board boots, but I guess it does. >>> >> Were you going to check in the next couple of days ? >> Tom >> >> > Checked... board boots. > Thanks! > Btw. there are some warnings during build: > mkimage.c: In function ‘main’: > mkimage.c:204: warning: dereferencing type-punned pointer will break > strict-aliasing rules > mkimage.c:222: warning: dereferencing type-punned pointer will break In general I look for new compiler warnings and errors. Any old warnings should be fixed but it is unlikely that this change introduced them. Of course results will vary depending on toolchain. Thanks, Tom > > Regards, > Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request
Dear Tom, In message <4b75b4e1.8050...@windriver.com> you wrote: > > The following changes since commit 0b692dcb190655c7eb96b6b8003bee163e3b58dd: >Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-net > > are available in the git repository at: > >git://git.denx.de/u-boot-arm master > > Alessandro Rubini (3): >EP93xx: fix syscon_regs definition >edb93xx: change calculation un early_udelay.h >edb93xx: enable the uart in devicecfg register > > Daniel Gorsulowski (1): >at91: Add esd gmbh OTC570 board support > > Jens Scharsig (9): >add new CONFIG_AT91_LEGACY >add c structures for SoC access >add a new AT91 GPIO driver >convert all at91 files to use at91_gpio driver syntax >convert common files to new SoC access >update at91sam9263ek board to new SoC access >prepare joining at91rm9200 into at91 >new at91_emac network driver (NET_MULTI api) >new board (eb_cpux9k2) > > Ladislav Michl (3): >NetStar: Disable CONFIG_CMD_JFFS2 >NetStar: make crcit utility more readable >NetStar: Remove debug junk leaked into eeprom utility > > Magnus Lilja (1): >SPI: Fix 32 bit transfers in mxc_spi.c > > Matthias Kaehlcke (2): >Add support for EDB93xx boards >ARM: Add support for EP93xx SoCs > > Nick Thompson (3): >da830evm: Use table driven pin mux configuration >Davinci: Add EMIF-A macros for setting chip select parameters >DA830 EVM: Enable NAND support on Spectrum Digital EVM > > Sanjeev Premi (1): >OMAP3: Avoid re-write to PRM_CLKSRC_CTRL > > Scott Ellis (1): >Overo GPMC registers > > Sekhar Nori (1): >TI DaVinci: Driver for the davinci SPI controller > > Tom Rix (1): >OMAP3 Move declaration of gpmc_cfg. > > MAINTAINERS | 15 + > MAKEALL | 10 + > Makefile| 16 + > board/BuS/eb_cpux9k2/Makefile | 50 +++ > board/BuS/eb_cpux9k2/config.mk |1 + > board/BuS/eb_cpux9k2/cpux9k2.c | 387 + > board/atmel/at91sam9263ek/at91sam9263ek.c | 151 > board/atmel/at91sam9263ek/led.c | 21 +- > board/davinci/da830evm/da830evm.c | 72 +++- > board/edb93xx/Makefile | 50 +++ > board/edb93xx/config.mk | 33 ++ > board/edb93xx/early_udelay.h| 34 ++ > board/edb93xx/edb93xx.c | 110 + > board/edb93xx/flash_cfg.c | 38 ++ > board/edb93xx/pll_cfg.c | 58 +++ > board/edb93xx/pll_cfg.h | 72 > board/edb93xx/sdram_cfg.c | 123 ++ > board/edb93xx/sdram_cfg.h | 144 +++ > board/esd/otc570/Makefile | 55 +++ > board/esd/otc570/config.mk |1 + > board/esd/otc570/otc570.c | 365 > board/esd/otc570/partition.c| 37 ++ > board/netstar/crcit.c |9 +- > board/netstar/eeprom.c |8 +- > board/netstar/eeprom_start.S| 166 + > board/overo/overo.c | 14 +- > board/overo/overo.h |9 + > cpu/arm920t/at91/Makefile | 47 +++ > cpu/arm920t/at91/lowlevel_init.S| 164 > cpu/arm920t/at91/reset.c| 59 +++ > cpu/arm920t/at91/timer.c| 163 > cpu/arm920t/cpu.c |4 + > cpu/arm920t/ep93xx/Makefile | 56 +++ > cpu/arm920t/ep93xx/cpu.c| 51 +++ > cpu/arm920t/ep93xx/led.c| 101 + > cpu/arm920t/ep93xx/lowlevel_init.S | 65 +++ > cpu/arm920t/ep93xx/speed.c | 110 + > cpu/arm920t/ep93xx/timer.c | 168 > cpu/arm920t/ep93xx/u-boot.lds | 59 +++ > cpu/arm926ejs/at91/at91cap9_devices.c | 128 --- > cpu/arm926ejs/at91/at91sam9260_devices.c| 124 +++--- > cpu/arm926ejs/at91/at91sam9261_devices.c| 84 +++-- > cpu/arm926ejs/at91/at91sam9263_devices.c| 137 --- > cpu/arm926ejs/at91/at91sam9m10g45_devices.c | 120 +++--- > cpu/arm926ejs/at91/at91sam9rl_devices.c | 58 ++-- > cpu/arm926ejs/at91/clock.c | 51 ++- > cpu/arm926ejs/at91/cpu.c|4 + > cpu/arm926ejs/at91/led.c|1 + > cpu/arm926ejs/at91/lowlevel_init.S | 95 ++--- > cpu/arm926ejs/at91/reset.c |8 +- > cpu/arm926ejs/at91/timer.c | 17 +- > cpu/arm_cortexa8/omap3/clock.c | 20 +-
[U-Boot] Boot based on I2C EEPROM value
Hello, The modem I am working on contains two software images in flash memory: 1. Default image 2. Backup image Typically, the Default image will get loaded. If the application software determines that the Default image is causing issues, it will set a value of 1 in an address in the I2C EEPROM and reboot the board. So, U-boot will need to read this EEPROM value and determine whether it should boot the Default or Backup image i.e. if EEPROM data == 0 bootm $default_addr else bootm $backup_addr How can I read and parse the EEPROM data from U-boot? U-boot has the facility to read the I2C device from the command line as in (EEPROM dev num = 50, address = 2, count = 1): => i2c md 50 2 1 0002: 01. How do I parse this from within a U-boot command that can be run at boot-up? Thank you, Srivatsan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] s5pc1xx: update the README file
Dear Wolfgang, On 18 February 2010 05:26, Wolfgang Denk wrote: > Dear Minkyu Kang, > > In message <1f3430fb1002170629p2528fdd2x3ffa396775715...@mail.gmail.com> you > wrote: >> >> > Would it be possible to squash these two commits into one? They >> > actually are one change and should not be split apart. =A0Thanks. >> >> I already pushed these patches. >> Do I need to revert the patchset? >> Or, give me your opinion, if you have any idea. > > If you agree, you can "git rebase -i" your branch and squash the two > commits into one. I did it. But, there are remained old two commits. Did I something wrong? I appreciate your help. Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] DaVinci: Adding entry to MAKEALL for DM365 EVM
From: Sandeep Paulraj The patch adds an entry for the DM365 EVM to MAKEALL Signed-off-by: Sandeep Paulraj --- MAKEALL |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/MAKEALL b/MAKEALL index 1e660b6..6ddf7e0 100755 --- a/MAKEALL +++ b/MAKEALL @@ -599,6 +599,7 @@ LIST_ARM9=" \ davinci_sonata \ davinci_dm355evm\ davinci_dm355leopard\ + davinci_dm365evm\ davinci_dm6467evm \ " -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da830evm: Add support for TI EMAC
> > Adds support for ethernet networking on the da830evm platform. > > This platform uses an SoC EMAC interface and a 3 port ethernet > switch as a PHY with an RMII interface. The PHY also has a i2c > interface for configuring the switch functions. > > Signed-off-by: Nick Thompson > --- > board/davinci/da830evm/da830evm.c| 64 > +- > include/asm-arm/arch-davinci/emac_defs.h |1 + > include/configs/da830evm.h |1 + > 3 files changed, 64 insertions(+), 2 deletions(-) Pushed to u-boot-ti. I verified that the EMAC driver worked fine on the DM365. Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] netstar.h: do not exceed 80 columns
> > From: Ladislav Michl > > Limit line length to 80 characters mostly by removing obvious and > sometimes > misleading comments. Fix indentation, too. > > Signed-off-by: Ladislav Michl > --- > netstar.h | 65 +--- > -- > 1 file changed, 31 insertions(+), 34 deletions(-) > Pushed to u-boot-ti It built fine. Maybe you can test it as well. I have rebased with Wolfgang. Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DaVinci: Adding entry to MAKEALL for DM365 EVM
> Subject: [PATCH] DaVinci: Adding entry to MAKEALL for DM365 EVM > > From: Sandeep Paulraj > > The patch adds an entry for the DM365 EVM to MAKEALL > > Signed-off-by: Sandeep Paulraj > --- > MAKEALL |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/MAKEALL b/MAKEALL > index 1e660b6..6ddf7e0 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -599,6 +599,7 @@ LIST_ARM9=" \ > davinci_sonata \ > davinci_dm355evm\ > davinci_dm355leopard\ > + davinci_dm365evm\ > davinci_dm6467evm \ > " > > -- I have pushed this patch to u-boot-ti Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] VoiceBlue: limit line lenght to 80 characters
> Subject: [PATCH] VoiceBlue: limit line lenght to 80 characters > > From: Ladislav Michl > > Reindent configuration header to limit line lenght to 80 characters by > removing obvious and sometimes misleading comments. > > Signed-off-by: Ladislav Michl > --- > voiceblue.h | 164 +- > -- > 1 file changed, 80 insertions(+), 84 deletions(-) > Pushed Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
The following changes since commit 77e7273c40315abd2f3c17ad8d46a78950e3e65f: Jens Scharsig (1): new board (eb_cpux9k2) are available in the git repository at: git://git.denx.de/u-boot-ti.git master Ladislav Michl (8): NetStar: eeprom - undefined reference to `memset' NetStar: eeprom - be less verbose NetStar: eeprom - fix linker error NetStar: fix default environment NetStar: make mtdparts default ready for recent kernels netstar.h: do not exceed 80 columns VoiceBlue: limit line lenght to 80 characters VoiceBlue: fix linker errors Nick Thompson (1): da830evm: Add support for TI EMAC Sandeep Paulraj (1): DaVinci: Adding entry to MAKEALL for DM365 EVM MAKEALL |1 + board/davinci/da830evm/da830evm.c| 65 +++- board/netstar/Makefile | 54 +- board/netstar/eeprom.c | 95 + board/netstar/eeprom.lds | 51 - board/netstar/eeprom_start.S | 13 --- board/voiceblue/Makefile | 33 +++--- board/voiceblue/eeprom.c | 97 + board/voiceblue/eeprom.lds | 51 - board/voiceblue/eeprom_start.S | 11 -- include/asm-arm/arch-davinci/emac_defs.h |1 + include/configs/da830evm.h |1 + include/configs/netstar.h| 114 ++--- include/configs/voiceblue.h | 168 +++--- 14 files changed, 343 insertions(+), 412 deletions(-) delete mode 100644 board/netstar/eeprom.lds delete mode 100644 board/netstar/eeprom_start.S delete mode 100644 board/voiceblue/eeprom.lds delete mode 100644 board/voiceblue/eeprom_start.S ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to random my mac in u-boot
On 9 February 2010 17:29, Wolfgang Denk wrote: > In general, such a solution is not needed at all. When you can > automate writes to an EEPROM, you can do the same for writes to flash > memory (which is what I pointed out in my posting refering to the > tqm8xx boards). True, but not for our case. We put the same EEPROMs and an I2C bus on all sub-boards in our products. These EEPROMs contain detailed version and build number information about each board. At startup the application scans the system for each EEPROM and builds a configuration profile of everything in the system. This allows our main application to load the correct FPGA image, configure GPIO ports, etc. The main requirement was to allow a technician, with minimal equipment, to completely audit every board in our product (e.g.retrieve the serial numbers for RMA and warranty purposes) without cracking open the case. Since the I2C bus can be powered externally, we don't need to power up the system in order to read the memory device. So it will still work on a broken sub-board - assuming the I2C bus is still intact. Aras ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v4] arm: add support for the mgcoge2_arm_p1a board from keymile
Hello Prafulla, Prafulla Wadaskar wrote: >> -Original Message- >> From: Heiko Schocher [mailto:h...@denx.de] >> Sent: Monday, February 15, 2010 1:37 PM >> To: Prafulla Wadaskar >> Cc: U-Boot user list; Wolfgang Denk; Scott Wood; Stefan Roese >> Subject: Re: [PATCH 1/4 v4] arm: add support for the >> mgcoge2_arm_p1a board from keymile >> >> Hello Prafulla, >> >> Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Friday, February 12, 2010 1:36 PM To: U-Boot user list Cc: Wolfgang Denk; Prafulla Wadaskar; Scott Wood; Stefan Roese Subject: [PATCH 1/4 v4] arm: add support for the mgcoge2_arm_p1a board from keymile Add support for the ARM part of the mgcoge2. This board is based on the Marvell Kirkwood (88F6281) SoC. As there come more board variants, common code is stored in board/keymile/km_arm/km_arm.c Signed-off-by: Holger Brunck Signed-off-by: Stefan Roese Signed-off-by: Heiko Schocher > > ...snip... > diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c index ec27bda..7b4eefd 100644 --- a/board/keymile/common/common.c +++ b/board/keymile/common/common.c @@ -35,6 +35,7 @@ #include #endif +#include "../common/common.h" >>> Can't you use "common.h" here ? >> No, this is "just" a keymile specific header for including >> functions, which are "common" for all keymile boards ... > > More important common.h that you are referring here is missing in this patch. No, it is in mainline, see: http://git.denx.de/?p=u-boot.git;a=blob;f=board/keymile/common/common.h;h=a38c72772ce75f4659c50378c8d16c4098ec2b6c;hb=77e7273c40315abd2f3c17ad8d46a78950e3e65f > Secondly, since you are in the same folder you should use "common.h" instead > of absolute path" This is a header common for all keymile boards, so it sit in the board/manufacturer/common/ directory. This is used also used for some ppc based boards. > ...snip... + + /* + * arch number of board + */ + gd->bd->bi_arch_number = MACH_TYPE_SUEN3; >>> This does not match with the board you are supporting, >> better to use similar name >> >> As I said above, this boards are all the same, just different >> hardwarerevisions, so theys all have one MACH_TYPE_ ... > > To me, two boards are two different hardware and must have associated with > two different machine ids. > How will you manage picking different board setups in kernel for same machine > ID? They all use the *same* kernel! > If not Machine ID, you can think of using EEPROM available on board to store > board version info and use it selectively. > + + /* address of boot parameters */ + gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100; + +#if defined(CONFIG_KIRKWOOD_GPIO) >>> Avoid this at least for this board patch >> Don;t understand this! Why? The board uses this pins for >> I2C bitbang, so I must initialize the pins ... > > why you need to ifdef this? For this particular board it should be hard > coded, I think you can do this for other board support if needed. > > First patch in this series has to be clean standard board support without any > ifdefs, subsequent patches add support for different hardware version, there > if you use ifdef it makes more sense Ok, I delete this. 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
