Re: About DM6467_config

> Yes. Others in TI are supposed to add the support. If they don't start I will start by adding the basic framework.

About when are you scheduling to open it to the public?
I am very interested.

Regards,
Kazuaki Ichinohe

2009/9/30 Paulraj, Sandeep <s-paulraj <at> ti.com>:
>
>
>>
>> hmmm...to bad...i planned to use a newer uboot version than the one
>> delivered with my dm6467 (its v1.2).
>>
>> do you think there will be support any time soon?
> Yes. Others in TI are supposed to add the support. If they don't start I will start by adding the basic framework.
>>
>> and how far do you think are you with dm365? because i will switch to
>> this plattform sooner or later anyway!
> If you are in a hurry you can clone
> http://arago-project.org/git/people/?p=sandeep/u-boot-davinci.git;a=summary
>
> or a slightly older version
>
> http://arago-project.org/git/people/?p=sandeep/u-boot-davinci.git;a=shortlog;h=refs/heads/u-boot-davinci-2009-06
>
>
>> i see you are doing a lot of progress there...
>>

Re: [PATCH v2] ppc/85xx: PIO Support for FSL eSDHC Controller Driver

Hi Bin,

We can know the block transfer complete using IRQSTAT(Transfer
Complete).
But reading & writing in PIO mode takes time for byte by byte transfers
and there is no way to poll that transfer, that's why I have added delay
there. 

I can add comment like,
\* Wait before last byte transfer complete *\
Is that ok ??

Regards,
 Dipen

-----Original Message-----
From: Bin Meng [mailto:bmeng.cn <at> gmail.com] 
Sent: Monday, September 28, 2009 4:41 AM
To: Dudhat Dipen-B09055
Cc: u-boot <at> lists.denx.de
Subject: Re: [U-Boot] [PATCH v2] ppc/85xx: PIO Support for FSL eSDHC
Controller Driver

On Thu, Sep 10, 2009 at 9:37 PM, Dipen Dudhat
<dipen.dudhat <at> freescale.com> wrote:
> +                       while (size && (!(irqstat & IRQSTAT_TC))) {
> +                               udelay(100);
> +                               irqstat = in_be32(&regs->irqstat);
> +                               databuf = in_le32(&regs->datport);

Re: [PATCH] new default shortcut to config & build a board

On Monday 24 August 2009 17:28:26 Mike Frysinger wrote:
> The majority of the time that I build things in U-Boot, I want to just
> build for the board.  I don't make board config tweaks after selecting the
> board.  So add a new pattern rule that allows people to combine two steps
> in one go:
> 	`make foo_config && make` => `make foo`
> 
> This shouldn't conflict with any existing make rules as the pattern rule
> is used only the rule doesn't already exist.

ping
-mike

_______________________________________________
U-Boot mailing list
U-Boot <at> lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH 2/2 v2] Blackfin: tweak embedded env config option

On Tuesday 15 September 2009 16:49:42 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > Use the common config option for extracting the environment for embedding
> > into LDR files.
> >  $(obj)u-boot.ldr:	$(obj)u-boot
> > -		$(obj)tools/envcrc --binary > $(obj)env-ldr.o
> > +		$(CREATE_LDR_ENV)
> >  		$(LDR) -T $(CONFIG_BFIN_CPU) -c $ <at>  $< $(LDR_FLAGS)
> 
> This is all BF specific stuff, right? Maybe we should move this into
> some BF Makefile, then, instead of adding more and more references to
> magic variables that have no meaning anywhere except for BF.

here's what i'm thinking (it wont apply to mainline, so it's just an idea).
from what i can see, there shouldnt be *anything* related to Blackfin left in
the top level files now (except for MAKEALL, but that's another day).
-mike

diff --git a/Makefile b/Makefile
index 40cca2e..61210e8 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -305,16 +305,6  <at>  <at>  $(obj)u-boot.srec:	$(obj)u-boot
 $(obj)u-boot.bin:	$(obj)u-boot
 		$(OBJCOPY) ${OBJCFLAGS} -O binary $< $ <at> 

-$(obj)u-boot.ldr:	$(obj)u-boot
-		$(CREATE_LDR_ENV)
-		$(LDR) -T $(CONFIG_BFIN_CPU) -c $ <at>  $< $(LDR_FLAGS)
-

[PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems

Using -mabi=apcs-gnu allows Marvell Kirkwood-based boards to boot with
the EABI changes introduced in commit
f772acf8a584067033eff1e231fcd1fb3a00d3d9.

Signed-off-by: Simon Kagstrom <simon.kagstrom <at> netinsight.net>
---
Wolfgang can live with this change to make Kirkwood builds work again:

On Wed, 30 Sep 2009 22:32:08 +0200
Wolfgang Denk <wd <at> denx.de> wrote:

> > -PLATFORM_CPPFLAGS += -march=armv5te
> > +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu
> 
> I could live with this part, if it was thoroughly tested and does not
> cause problems with the most frequently used tool chains (which I'm
> afraid it would - I think I remember that I saw errors or unexpected
> behaviour when using multiple, different "-mabi" settings).

It would be nice though if owners of other arm926ejs-boards could test
the patch and see that it doesn't break things. Depending on the
compiler, you might want to build with USE_PRIVATE_LIBGCC=yes.

I've tested on a OpenRD-base board.

 cpu/arm926ejs/config.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk
index f8ef90f..466ccff 100644

[PATCH v3] AT91: Add SD/MMC controller support

Hello there,

I tried to get mmc working on a board using an at91sam9g20. The mmc-card 
is wired on slotb.

I applied the patches:

http://lists.denx.de/pipermail/u-boot/2009-September/060053.html
http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
http://lists.denx.de/pipermail/u-boot/2009-September/060243.html

It didn't work as I always got (apart from the message of a too low 
clock which I avoided by setting f_min / f_max on my own):

mmc: command 8 failed (status: 0x0010c1e5)
mmc: command 55 failed (status: 0x0010c1e5)
mmc: command 1 failed (status: 0x0010c1e5)
Card did not respond to voltage select!

So I had a look at linux sources and discovered that the MCI selected 
the wrong slot. After modifying atmel_mci_set_ios() to set SDCR to use 
slotb ("mmci_writel(SDCR, sdcr | 1);") I got my card working.

Hope this helps someone.

Regards

Sebastian Heutling

Re: [PATCH] arm: Correct build with CONFIG_SYS_HUSH_PARSER set

________________________________________
From: u-boot-bounces <at> lists.denx.de [u-boot-bounces <at> lists.denx.de] On Behalf Of Prafulla Wadaskar [prafulla <at> marvell.com]
Sent: Thursday, September 24, 2009 10:38 PM
To: Simon Kagstrom
Cc: U-Boot ML
Subject: Re: [U-Boot] [PATCH] arm: Correct build with CONFIG_SYS_HUSH_PARSER set

> -----Original Message-----
> From: Simon Kagstrom [mailto:simon.kagstrom <at> netinsight.net]
> Sent: Thursday, September 24, 2009 7:54 PM
> To: Simon Kagstrom; Prafulla Wadaskar
> Cc: U-Boot ML
> Subject: Re: [U-Boot] [PATCH] arm: Correct build with
> CONFIG_SYS_HUSH_PARSER set
>
> Hi Prafulla!
>
> Small reminder . Perhaps you missed this patch - and I also forgot
> to add you under To:. It's a simple one-liner to get kirkwood/cpu.c to
> build when CONFIG_SYS_HUSH_PARSER is set.
>

Applied to u-boot-marvell.git/next

Regards..
Prafulla . .

AT91 working SD with u-boot

Hi,

for me this is working:

Downloaded u-boot 2009.08

file cpu/arm926ejs/at91/at91sam9260_devices.c
> 
> changed:
> >#if defined(CONFIG_HAS_DATAFLASH)
> to:
> >#if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI)

patches:

SOC headers:
http://lists.denx.de/pipermail/u-boot/2009-September/060053.html

SD Patch V3
http://lists.denx.de/pipermail/u-boot/2009-September/060243.html

MCI support
http://lists.denx.de/pipermail/u-boot/2009-August/059595.html

add to board init code:

at91_mciX_hw_init (X for mci unit 0 / 1) for parameters have a look at cpu/arm926ejs/at91/at91sam9260_devices.c

bye
Konrad Mattheis

Merge Window

Hi,

I already read that the merge window is closed.

My question is, can I also send now patches to the list and somebody collect them for the next release, or is it
better to wait for the next merge window?

bye
Konrad Mattheis

_______________________________________________
U-Boot mailing list
U-Boot <at> lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: Merge Window

Hi Konrad,

On Thursday 01 October 2009 10:01:58 Konrad Mattheis wrote:
> I already read that the merge window is closed.
> 
> My question is, can I also send now patches to the list and somebody
>  collect them for the next release, or is it better to wait for the next
>  merge window?

Please send your patches always right away. If the patches are bug fixes, they 
will most likely make it into the upcoming release. And if not, they usually 
are added to the "next" branches of the responsible custodian.

Cheers,
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: office <at> denx.de