Hi Kumar,
I have tried using "fsl_ddr_set_memctl_regs()".
But this can't get fit into 4K NAND_SPL Loader.
Regards,
Dipen
>
> On Oct 9, 2009, at 12:42 PM, Dipen Dudhat wrote:
>
>> +void initsdram(void)
>> +{
>> +
>> +volatile ccsr_ddr_t *ddr= (ccsr_ddr_t
> *)CONFIG_SYS_MPC85xx_DDR_ADDR;
Hi Alessandro,
Alessandro Rubini a écrit :
>>> + unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
>>>
>
>
>> Nitpick: Are you sure the casts are necessary here ?
>>
>
> Without the one on src it complains because of "const". So I write
> both for symetry.
>
Dear kevin.morfitt
2009/10/10 kevin.morf...@fearnside-systems.co.uk
:
> This patch re-formats the arm920t s3c24x0 driver files, excluding the nand
> driver, in preparation for changes to add support for the Embest SBC2440-II
> Board.
>
> The changes are as follows:
> - re-indent the code using Li
Dear kevin.morfitt
2009/10/10 kevin.morf...@fearnside-systems.co.uk
:
> This patch re-formats the code in cpu/arm920t and cpu/arm920t/23c24x0 in
> preparation for changes to add support for the Embest SBC2440-II Board.
>
> The changes are as follows:
> - re-indent the code using Lindent
> - make s
Dear kevin.morfitt
2009/10/10 kevin.morf...@fearnside-systems.co.uk
:
> This patch re-formats the arm920t s3c24x0 nand driver in preparation for
> changes
> to add support for the Embest SBC2440-II Board.
>
> The changes are as follows:
> - re-indent the code using Lindent
> - make sure register
Dear kevin.morfitt
2009/10/10 kevin.morf...@fearnside-systems.co.uk
:
> This patch re-formats the arm920t s3c24x0 header files in preparation for
> changes to add support for the Embest SBC2440-II Board.
>
> The changes are as follows:
> - re-indent the code using Lindent
> - make sure register la
Hi Wilbur,
wilbur.chan wrote:
> mips64 , xlr732
>
> I've added a test command in uboot, say,
> U_BOOT_CMD(test_globa,...do_test_global) ,which is in cmd_command.c
>
> And in cmd_command.c, there is also a global string array ,say ,char*
> p = "test";
>
> In do_test_global, I used pointer to
After OneNAND IPL updated, apollon boot code exceeds 1KiB size,
This patch reduces the apollon boot code
Signed-off-by: Kyungmin Park
---
diff --git a/onenand_ipl/board/apollon/apollon.c
b/onenand_ipl/board/apollon/apollon.c
index 4936e00..4d4564c 100644
--- a/onenand_ipl/board/apollon/apollon.
For this task:
http://www.denx.de/wiki/U-Boot/TaskSetEnvironmentDefaults
was the end goal to group all environment commands under a new
"environment" command, in addition to adding the new "clear" and
"default" commands?
eg:
setenv becomes "env set"
printenv becomes "env print"
askenv becomes "env
I have merged arm/next into arm/master.
There are new warnings in
CPU9260 , CONFIG_SYS_64BIT_VSPRINTF
CPU9G20 , CONFIG_SYS_64BIT_VSPRINTF
GPUAT91 , CONFIG_NET_MULTI,
davinci_dm355evm , CONFIG_SYS_64BIT_VSPRINTF, generic_set_bit
I have ack-ed patches for these..
openrd_base , kwgbe_init bre
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> This patch adds the initial support for DM6467 EVM.
>
> Signed-off-by: Sandeep Paulraj
> ---
> Changes since the initial version
> - Add entries to MAKEALL and MAINTAINERS as suggested by Tom
> - Fix whitespace issues as pointed ou
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> This patch adds support for the leopard board which is
> based on the DM355 SOC.
>
> Signed-off-by: Sandeep Paulraj
This looks fine.
Ack-ed
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://li
Paulraj, Sandeep wrote:
>
>> -Original Message-
>> From: Tom Rix [mailto:t...@bumblecow.com]
>> Sent: Sunday, October 11, 2009 1:26 PM
>> To: Paulraj, Sandeep; u-boot@lists.denx.de
>> Subject: Re: [PATCH] TI DaVinci DVEVM: Add Config option for 64 bit
>> Support
>>
>> s-paul...@ti.com wrot
> -Original Message-
> From: Tom Rix [mailto:t...@bumblecow.com]
> Sent: Sunday, October 11, 2009 1:26 PM
> To: Paulraj, Sandeep; u-boot@lists.denx.de
> Subject: Re: [PATCH] TI DaVinci DVEVM: Add Config option for 64 bit
> Support
>
> s-paul...@ti.com wrote:
> > From: Sandeep Paulraj
>
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> Adding entries to the MAINTAINERS directory for the
> DM355 and DM365 EVM.
>
> Signed-off-by: Sandeep Paulraj
> ---
> MAINTAINERS |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> inde
s-paul...@ti.com wrote:
> From: Sandeep Paulraj
>
> Adding the CONFIG_SYS_64BIT_VSPRINTF in the DVEVM config.
>
> Signed-off-by: Sandeep Paulraj
> ---
> include/configs/davinci_dvevm.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/davinci_dvevm.
Paulraj, Sandeep wrote:
>> The offset to the chip select is incorrect.
>>
>> The change 187af954cf7958c24efcf0fd62289bbdb4f1f24e,
>>
>> omap3: embedd gpmc_cs into gpmc config struct
>>
>> introduced a problem with the serial gpmc setup.
>>
>> This patch reverts the chip select to its previous value
Paulraj, Sandeep wrote:
>>
>> The technical change is better handling of address setting on the
>> usb handshaking setup phase.
>>
>> Other changes from Jean's comments
>>
>> 2/8 USB add macros for debugging usb device setup.
>>
>> static inline function replacing debug macros
>>
>> 3/8 TWL4030 Add
>
>
> The technical change is better handling of address setting on the
> usb handshaking setup phase.
>
> Other changes from Jean's comments
>
> 2/8 USB add macros for debugging usb device setup.
>
> static inline function replacing debug macros
>
> 3/8 TWL4030 Add usb PHY support
>
> add
> The offset to the chip select is incorrect.
>
> The change 187af954cf7958c24efcf0fd62289bbdb4f1f24e,
>
> omap3: embedd gpmc_cs into gpmc config struct
>
> introduced a problem with the serial gpmc setup.
>
> This patch reverts the chip select to its previous value.
>
> The symptoms of this
>
> On Sun, Oct 11, 2009 at 7:16 AM, Steve Sakoman wrote:
>
> > Compile and run test of the Overo build was fine with Tobi card.
> > Later today I will try some of the other daughter cards to make sure
> > it works with all of them.
>
> Heh, I spoke too soon!
>
> U-boot appeared to run fine,
Steve Sakoman wrote:
> On Sat, Oct 10, 2009 at 12:38 PM, Paulraj, Sandeep wrote:
>> All,
>>
>> I've updated the u-boot-ti next tree with quite a few patches.
>> There are instances were multiple patches modify the same file.
>> Can the OMAP 3 boards be tested to see if things are ok?
>
> Compile
On Sun, Oct 11, 2009 at 7:16 AM, Steve Sakoman wrote:
> Compile and run test of the Overo build was fine with Tobi card.
> Later today I will try some of the other daughter cards to make sure
> it works with all of them.
Heh, I spoke too soon!
U-boot appeared to run fine, but it fails in it's m
Paulraj, Sandeep said the following on 10/11/2009 09:48 AM:
>
>> Dirk Behme said the following on 10/11/2009 02:54 AM:
>>
>>> Nishanth Menon wrote:
>>>
>>>
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
>>> Hav
>
> Dirk Behme said the following on 10/11/2009 02:54 AM:
> > Nishanth Menon wrote:
> >
> >> gpmc_config should not be a variant as it is board specific
> >> hence make it a const parameter
> >>
> >
> > Having this in u-boot-ti/next results in
> >
> > - All non-SDP3430 boards have
> >
> > mem.c:
Dirk Behme said the following on 10/11/2009 02:54 AM:
> Nishanth Menon wrote:
>
>> gpmc_config should not be a variant as it is board specific
>> hence make it a const parameter
>>
>
> Having this in u-boot-ti/next results in
>
> - All non-SDP3430 boards have
>
> mem.c: In function 'gpmc_in
On Sat, Oct 10, 2009 at 12:38 PM, Paulraj, Sandeep wrote:
> All,
>
> I've updated the u-boot-ti next tree with quite a few patches.
> There are instances were multiple patches modify the same file.
> Can the OMAP 3 boards be tested to see if things are ok?
Compile and run test of the Overo build
From: Sandeep Paulraj
Adding the CONFIG_SYS_64BIT_VSPRINTF in the DVEVM config.
Signed-off-by: Sandeep Paulraj
---
include/configs/davinci_dvevm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h
index f7
From: Sandeep Paulraj
Adding the CONFIG_SYS_64BIT_VSPRINTF fot the DM644x based Sonata
Signed-off-by: Sandeep Paulraj
---
Previous patch incorrectly said that it was meant for the DM355 EVM
include/configs/davinci_sonata.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
From: Sandeep Paulraj
Adding the CONFIG_SYS_64BIT_VSPRINTF in the DM355 EVM config.
Signed-off-by: Sandeep Paulraj
---
include/configs/davinci_sonata.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/davinci_sonata.h b/include/configs/davinci_sonata.h
i
>
> Nishanth Menon wrote:
> > gpmc_config should not be a variant as it is board specific
> > hence make it a const parameter
>
> Having this in u-boot-ti/next results in
>
> - All non-SDP3430 boards have
>
> mem.c: In function 'gpmc_init':
> mem.c:250: warning: assignment discards qualifiers f
On Sun, Oct 11, 2009 at 2:38 AM, Joakim Tjernlund
wrote:
> Graeme Russ wrote on 10/10/2009 13:21:10:
>>
>> On Sat, Oct 10, 2009 at 9:47 PM, Joakim Tjernlund
>> wrote:
>> >
>> >
>> > Graeme Russ wrote on 10/10/2009 12:38:19:
>> >>
>> >> On Sat, Oct 10, 2009 at 8:27 PM, Joakim Tjernlund
>> >> wr
Nishanth Menon wrote:
> From: David Brownell
>
>
> Sandeep pointed me to:
> http://lists.denx.de/pipermail/u-boot/2009-October/062086.html
> so the v3 of patch with size fixes
>
> Start of support of
> Texas Instruments Software Development Platform(SDP)
> for OMAP3430 - SDP3430
Having
Nishanth Menon wrote:
> gpmc_config should not be a variant as it is board specific
> hence make it a const parameter
Having this in u-boot-ti/next results in
- All non-SDP3430 boards have
mem.c: In function 'gpmc_init':
mem.c:250: warning: assignment discards qualifiers from pointer target
typ
Paulraj, Sandeep wrote:
> All,
>
> I've updated the u-boot-ti next tree with quite a few patches.
> There are instances were multiple patches modify the same file.
> Can the OMAP 3 boards be tested to see if things are ok?
Compile test of u-boot-ti/next (head
c27339b41e49cd89c2ea802a490b175ac7ad
Mike Frysinger a écrit :
> On Friday 09 October 2009 06:11:16 Mark Jackson wrote:
>
>> Chris Moore wrote:
>>
>>> I agree wholeheartedly with the idea but shouldn't it be more like this
>>> (untested) code :
>>>
>>> void * memcpy(void *dest, const void *src, size_t count)
>>>
>>> {
>>> c
36 matches
Mail list logo
