Dear Wolfgang Denk,
On 17 May 2011 17:46, Wolfgang Denk wrote:
> Dear Chander Kashyap,
>
> In message <1302843918-1105-1-git-send-email-chander.kash...@linaro.org> you
> wrote:
>> SROM config code is made common for S5P series of boards.
>> smdkc100.c now refers to s5p-common/sromc.c for SROM re
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue on srv-01.kinhteviet.com.
The message identifier is: 1QM9ew-0002CZ-0r
The subject of the message is: w...@
Dear Aneesh V,
In message <4dd352ea.3090...@ti.com> you wrote:
>
> > What you are doing here is defining an image format. Such an image
> > format must be good enough not only for OMAP4 and for loading U-Boot
> > as second stage, but for all other architectures and use cases as
> > well.
>
> I a
Hi Reinhard,
Le 17/05/2011 18:44, Reinhard Meyer a écrit :
> Hi Albert,
>> Incidentally, I see a new master-arm branch on u-boot-atmel. If it is one
>> you created locally to track u-boot-arm/master and pushed by accident, then
>> you can unpublish it from your public git repo by 'git push
>> s
>
> unsigned long get_tbus (void)
> {
> unsigned long tbl=0;
> unsigned long tbu1=0, tbu2=0;
> unsigned long us=0;
> unsigned long long tmp=0;
>
> unsigned long tbclk = os_get_tbclk();
>
> // get the timebase ticks
> do {
> __asm__ __volatile__ ("mftbu %0":"=r"
Hi Scott,
On Tuesday 17 May 2011 12:09 AM, Scott Wood wrote:
> On Mon, 16 May 2011 19:40:30 +0530
> Aneesh V wrote:
>
>> Hi Wolfgang,
>>
>> On Monday 16 May 2011 01:22 AM, Wolfgang Denk wrote:
>>> I think, in the first step of this series, we should move the existing
>>> code from nand_spl and on
Hi Wolfgang,
On Monday 16 May 2011 01:39 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-19-git-send-email-ane...@ti.com> you wrote:
>> Embed the u-boot flash image size at a known offset from the
>> start of u-boot so that SPL can use it while loading u-boot
>> from a no
Hi Scott,
On Tuesday 17 May 2011 12:26 AM, Scott Wood wrote:
> On Sun, 15 May 2011 20:51:36 +0530
> Aneesh V wrote:
>
>> Embed the u-boot flash image size at a known offset from the
>> start of u-boot so that SPL can use it while loading u-boot
>> from a non-XIP media.
>>
>> Signed-off-by: Aneesh
Dear Simon Glass,
In message you wrote:
>
> > Maybe we can agree to use these existing macros then instead of
> > inventing new ones with the same functionality.
>
> The existing macros do not have enough functionality in my view. If we
> seriously want people to use these then I believe they ne
Dear Luuk Paulussen,
In message you wrote:
> From: Luuk Paulussen
>
> Signed-off-by: Luuk Paulussen
> Acked-by: Chris Packham
> Cc: Prafulla Wadaskar
> ---
> Changes since v2:
> - Fixed Month setting/getting. Month was off by one due to difference
> between linux and u-boot time rtc time s
On Mon, May 16, 2011 at 10:27 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message you wrote:
>>
>> There are a few very primitive macros in setbits and clrbits. I would
>> very much like to see at least:
>
> Maybe we can agree to use these existing macros then instead of
> inventing new o
Hi Wolfgang,
On Wednesday 18 May 2011 03:24 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd2858e.2000...@ti.com> you wrote:
>>
>> I had the same concerns too. So, I have provided a CONFIG option -
>> CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can
>> provide the reg
Hi Scott,
On Tuesday 17 May 2011 10:20 PM, Scott Wood wrote:
> On Tue, 17 May 2011 12:24:34 +0530
> Aneesh V wrote:
>
>> On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote:
>>> On Sun, 15 May 2011 20:51:24 +0530
>>> Aneesh V wrote:
diff --git a/arch/arm/include/asm/global_data.h
b/arc
From: Luuk Paulussen
Signed-off-by: Luuk Paulussen
Acked-by: Chris Packham
Cc: Prafulla Wadaskar
---
Changes since v2:
- Fixed Month setting/getting. Month was off by one due to difference
between linux and u-boot time rtc time structure.
Changes since v1:
- run through checkpatch.pl and fix
From: Luuk Paulussen
Signed-off-by: Luuk Paulussen
Acked-by: Chris Packham
Cc: Prafulla Wadaskar
---
Changes since v2:
- Fixed Month setting/getting. Month was off by one due to difference
between linux and u-boot time rtc time structure.
Changes since v1:
- run through checkpatch.pl and fix
unsigned long get_tbus (void)
{
unsigned long tbl=0;
unsigned long tbu1=0, tbu2=0;
unsigned long us=0;
unsigned long long tmp=0;
unsigned long tbclk = os_get_tbclk();
// get the timebase ticks
do {
__asm__ __volatile__ ("mftbu %0":"=r" (tbu1):);
__asm__
Hi Simon,
>
> Hi Detlev and Wolfgang,
>
> Thanks for your comments. I understand a little bit of healthy inertia
> and do appreciate the constraints.
>
> I believe I have covered this ground very thoroughly and would like
> advice please on what to do next. The options I can see are:
>
> - change
Dear Aneesh V,
In message <4dd2858e.2000...@ti.com> you wrote:
>
> I had the same concerns too. So, I have provided a CONFIG option -
> CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can
> provide the register values, so no computation will be done.
Ah, great. Sorry, I have missed
Dear Aneesh V,
In message <4dd28296.2060...@ti.com> you wrote:
>
> > Can you please explain why you think this is the right place for it?
>
> This is roughly the sequence I followed.
> 1. Make the basic infrastructure.
> 2. Have a working skeleton of SPL(Just boots but doesn't do the loading par
Dear Aneesh V,
In message <4dd27893.5000...@ti.com> you wrote:
>
> > It appears this might be part of or taken from some bigger scope
> > clocks framework. Otherwise it's diffcult for me to understand why
> > OMAP4 needs 1400+ lines of code, when other SoCs appear to do with
> > considerably les
Dear Aneesh V,
In message <4dd27819.7010...@ti.com> you wrote:
>
> > I was especially talking about the loading from external storage, not
> > primarily relocation. This will even be mnore important if we had
> > (much) bigger images - like when loading an OS kernel as second stage
> > payload i
Hi Andreas, Wolfgang,
On 05/17/2011 11:04 AM, Andreas Pretzsch wrote:
> Am Montag, den 16.05.2011, 22:24 +0200 schrieb Wolfgang Denk:
>> Hi everybody,
>>
>> I would like to get our -rc1 within the next 2 days or so.
>>
>> Please drop me (and the respective custodian) a note if you have any
>> patc
On Tue, 17 May 2011 17:15:50 -0400
Alex Waterman wrote:
> > Is there any currently working host-big-endian platform with 16-bit NAND
> > that doesn't override these functions?
>
> I really can't say. I haven't looked through the source of any of the other
> boards. As Stefan said, all previous 4
Scott,
> If readw() is returning the bytes in the correct endianness, then that
> means the register is little-endian.
>
> It's not clear to me what the default assumption in nand_base.c is,
> though. read_byte16() suggests the default is native endian, but
> read_buf() and read_word() suggest i
On Tue, 17 May 2011 13:49:44 -0400
Alex Waterman wrote:
>
> Scott,
>
> On 05/17/2011 01:05 PM, Scott Wood wrote:
> > On Tue, 17 May 2011 10:11:14 -0400
> > Alex Waterman wrote:
> >
> >> I have seen issues with the nand_read_byte16() function in nand_base.c; it
> >> seems like the cpu_to_le16
The following changes since commit 535abb96fb665402894b820f934deaca61ce3d3e:
Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2011-05-15
23:23:36 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-nand-flash.git master
Stefan Roese (1):
nand_spl: nan
Scott,
On 05/17/2011 01:05 PM, Scott Wood wrote:
> On Tue, 17 May 2011 10:11:14 -0400
> Alex Waterman wrote:
>
>> I have seen issues with the nand_read_byte16() function in nand_base.c; it
>> seems like the cpu_to_le16() should be the other way around: le16_to_cpu().
>> Other than that no bug
On Tue, 17 May 2011 10:11:14 -0400
Alex Waterman wrote:
> I have seen issues with the nand_read_byte16() function in nand_base.c; it
> seems like the cpu_to_le16() should be the other way around: le16_to_cpu().
> Other than that no bugs as far as I am aware.
What is the specific problem you're
Am Montag, den 16.05.2011, 22:24 +0200 schrieb Wolfgang Denk:
> Hi everybody,
>
> I would like to get our -rc1 within the next 2 days or so.
>
> Please drop me (and the respective custodian) a note if you have any
> patches that are supposed to go in.
I'd like to request the inclusion of my patc
On Tue, May 17, 2011 at 1:20 AM, Detlev Zundel wrote:
> Hi Simon and Wolfgang,
>
> [...]
>
>> In terms of all this discussion I can see your point :-) I did have
>> expressions of interest from two people including one I thought was at your
>> company, which I why I went to the effort to clean up
On Tue, 17 May 2011 12:24:34 +0530
Aneesh V wrote:
> On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote:
> > On Sun, 15 May 2011 20:51:24 +0530
> > Aneesh V wrote:
> >> diff --git a/arch/arm/include/asm/global_data.h
> >> b/arch/arm/include/asm/global_data.h
> >> index 2a84d27..2ce020e 100644
>
Hi Albert,
> Incidentally, I see a new master-arm branch on u-boot-atmel. If it is one you
> created locally to track u-boot-arm/master and pushed by accident, then you
> can unpublish it from your public git repo by 'git push
> ssh://gu-at...@git.denx.de/u-boot-atmel :master-arm'.
No, that was
Hi Reinhard,
Le 17/05/2011 17:34, Reinhard Meyer a écrit :
> Hello Albert,
>> Yes, it is even trivial; but I expect pull request to be from 'master'
>> branches, which contain patches accepted by the custodian for the upcoming
>> version, not from 'next' branches, which are a waiting queue for p
Alex,
On Tuesday 17 May 2011 16:11:14 Alex Waterman wrote:
> > What changes did you have to make? Some 8/16 bit related changes? Or
> > something else?
>
> I changed the hard coded value of EBC0_CFG; I forced the chip->options
> field to have the 16 bit bus width flag set; in board_nand_select_de
Hello Albert,
> Yes, it is even trivial; but I expect pull request to be from 'master'
> branches, which contain patches accepted by the custodian for the upcoming
> version, not from 'next' branches, which are a waiting queue for patches that
> will only go into the next merge window -- as per
Hi Prafulla,
Prafulla Wadaskar wrote:
>
>> -Original Message-
>> From: Valentin Longchamp [mailto:valentin.longch...@keymile.com]
>> Sent: Wednesday, May 11, 2011 8:52 PM
>> To: Prafulla Wadaskar
>> Cc: u-boot@lists.denx.de; holger.bru...@keymile.com
>> Subject: Re: [PATCH v3 0/8] keymile
Hi Wolfgang,
On Monday 16 May 2011 01:36 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-18-git-send-email-ane...@ti.com> you wrote:
>> Identify SDRAM devices connected to EMIF automatically:
>> LPDDR2 devices have some Mode Registers that provide details
>> about the dev
Hi Mans,
On Monday 16 May 2011 02:12 AM, Måns Rullgård wrote:
> Wolfgang Denk writes:
>
>> Dear Aneesh V,
>>
>> In message<1305472900-4004-17-git-send-email-ane...@ti.com> you wrote:
>>> Calculate EMIF register values based on AC timing parameters
>>> from the SDRAM datasheet and the DDR frequen
Hi Wolfgang,
On Monday 16 May 2011 01:35 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-17-git-send-email-ane...@ti.com> you wrote:
>> Calculate EMIF register values based on AC timing parameters
>> from the SDRAM datasheet and the DDR frequency rather than
>> using the
On Monday 16 May 2011 01:31 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-16-git-send-email-ane...@ti.com> you wrote:
>> Add support for the SDRAM controller (EMIF).
>>
>> Signed-off-by: Aneesh V
>> V2:
>> * Changes for makefile changes
>> * Minor corrections in do_lpd
Stefan,
On 05/17/2011 09:41 AM, Stefan Roese wrote:
> What changes did you have to make? Some 8/16 bit related changes? Or
> something
> else?
I changed the hard coded value of EBC0_CFG; I forced the chip->options field to
have the 16 bit bus width flag set; in board_nand_select_device() I mo
Hi Wolfgang,
On Tuesday 17 May 2011 06:03 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd26719.5090...@ti.com> you wrote:
>>
>> I was thinking that it may be faster. More number of registers at
>> disposal may mean less number of pushes to the stack, right? I am not
>> sure if this w
Hi Alex,
On Tuesday 17 May 2011 15:00:45 Alex Waterman wrote:
> I am working on porting U-Boot to a sequoia based PPC440 board. It boots
> off NAND flash via the NDFC on the PPC440. Our NAND chip has a 16 bit bus
> which has presented some minor problems.
Yes, until now, all 4xx boards use 8bit N
Hi Wolfgang,
On Monday 16 May 2011 12:30 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-14-git-send-email-ane...@ti.com> you wrote:
>> Add support for:
>> 1. DPLL locking
>> 2. Initialization of clock domains and clock modules
>>
>> This work draws upon previous work don
Hi Wolfgang,
On Tuesday 17 May 2011 05:58 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd264b7.9060...@ti.com> you wrote:
>>
>> In ARM literature this kind of situations are also referred to as "self-
>> modifying". Here is an excerpt from ARM manual gloassary:
>
> I see. Thanks.
>
>
On 05/17/2011 02:58 PM, Fabio Estevam wrote:
> I think what Jason mentions is the fact that I added:
> #define CS1_BASE_ADDR 0xF400 and this was only for MX53 because it is
> protected by
> "elif defined(CONFIG_MX53)"
Ah ok, agree.
>
> I can add the CS1_BASE_ADDR for MX51 as well on my v3
On 05/17/2011 12:29 AM, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam
Hi Fabio,
> +#define ETHERNET_INT (1*32 + 31) /* GPIO2_31 */
^-- missing space
If you want to write in this form, it should be "1 * 32 + 31".
> +void weim_cs1_settings()
> +{
>
Dear List,
I am working on porting U-Boot to a sequoia based PPC440 board. It boots off
NAND flash via the NDFC on the PPC440. Our NAND chip has a 16 bit bus which has
presented some minor problems.
The NDFC code is pretty much what we need except for a few functions that I
made some changes
Hi Stefano,
On 5/17/2011 9:44 AM, Stefano Babic wrote:
> On 05/17/2011 07:06 AM, Jason Liu wrote:
>> Hi, Fabio,
>>
>> 2011/5/17 Fabio Estevam :
>>> Make the weim register set complete for MX51/MX53.
>>>
>>> While at it also add the weim chip select 1 address definition.
>>>
>>
>> From the code, yo
On 05/17/2011 12:29 AM, Fabio Estevam wrote:
Hi Fabio,
> +struct iomuxc {
> + u32 gpr0;
> + u32 gpr1;
> + u32 gpr2;
> + u32 omux0;
> + u32 omux1;
> + u32 omux2;
> + u32 omux3;
> + u32 omux4;
> +};
It seems to me that the MX51 and th
Dear Aneesh V,
In message <4dd26b36.4050...@ti.com> you wrote:
>
> And how do you distinguish between the two cases at the top level
> Makefile? Using a CONFIG flag or on a per platform basis?
The decision should not be make in the top level makefile, but in
spl/Makefile. And this can simply ch
On 05/17/2011 07:06 AM, Jason Liu wrote:
> Hi, Fabio,
>
> 2011/5/17 Fabio Estevam :
>> Make the weim register set complete for MX51/MX53.
>>
>> While at it also add the weim chip select 1 address definition.
>>
>
> From the code, you just add the cs for mx53 not for mx51, so,
> Had better specify
This patch add support for the Network Space v2 board and parents, based
on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
and Internet Space v2.
Additional information is available at:
http://lacie-nas.org/doku.php?id=network_space_v2
Signed-off-by: Simon Guinot
---
Changes
On 05/17/2011 12:29 AM, Fabio Estevam wrote:
> Make the weim register set complete for MX51/MX53.
>
> While at it also add the weim chip select 1 address definition.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Make the weim struct complete
>
> arch/arm/include/asm/arch-mx5/i
Sandeep,
Any comments?
On 05/01/11 13:10, Igor Grinberg wrote:
> CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR were not defined for
> this board thus breaking its build.
>
> Signed-off-by: Igor Grinberg
> Cc: Sandeep Paulraj
> Cc: Nishant Kamat
> Cc: Kshitij Gupta
> ---
> include/conf
Hi Wolfgang,
On Tuesday 17 May 2011 01:49 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd21fb9.6070...@ti.com> you wrote:
>>
>> The top-level make rule being the following, we will need a Makefile in
>> the board directory, right?
>>
>> +SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depe
Dear Aneesh V,
In message <4dd26719.5090...@ti.com> you wrote:
>
> I was thinking that it may be faster. More number of registers at
> disposal may mean less number of pushes to the stack, right? I am not
> sure if this will make a significant difference.
It does not make a significant differenc
Dear Aneesh V,
In message <4dd2657f.3020...@ti.com> you wrote:
>
> +struct ch_toc {
> +uint32_t section_offset;
> +uint32_t section_size;
> +uint8_t unused[12];
> +uint8_t section_name[12];
> +} __attribute__ ((__packed__));
> +
>
Dear Aneesh V,
In message <4dd264b7.9060...@ti.com> you wrote:
>
> In ARM literature this kind of situations are also referred to as "self-
> modifying". Here is an excerpt from ARM manual gloassary:
I see. Thanks.
> > Well, all the data copy will also use cached writes, which are much
>
> You
Hi Wolfgang,
On Tuesday 17 May 2011 04:47 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd24e63.3020...@ti.com> you wrote:
>>
>>> But that's not what you are doing. You are not changing the storage
>>> of the global data itself, you are changing the storage of the POINTER
>>> TO the
Hi Wolfgang,
On Monday 16 May 2011 05:18 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd0f98a.2040...@ti.com> you wrote:
>>
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_FLATDT, "flat_dt","Flat Device Tree",
},
>
Hi Wolfgang,
On Tuesday 17 May 2011 04:44 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd24bd6.5060...@ti.com> you wrote:
>>
>>> Would it be possible to do this even _before_ relocation, so to speed
>>> up memory accesses during relocation? Of course, proper invalidates/
>>> flushes
get_reset_cause() should not be exported. Drop code in the function
after return statement that can generate warnings due to unreachable code.
Signed-off-by: Stefano Babic
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/arm1136/mx31/generic.c |6 +-
1 files changed, 1 insertions(+), 5 del
Dear Aneesh V,
In message <4dd24e63.3020...@ti.com> you wrote:
>
> > But that's not what you are doing. You are not changing the storage
> > of the global data itself, you are changing the storage of the POINTER
> > TO the global data - and this makes no sense to me. The pointer can
> > certain
On 05/17/2011 08:25 AM, Jason Liu wrote:
> Hi, Stefano,
Hi Jason,
> I use array here just for the case we will have another element in the array
> (currently we only have one) in the future. Currently, we use 24MHz as ref.
Understood, thanks.
>>> /*
>>> + * Clock config code start here
>>> + *
Dear Aneesh V,
In message <4dd24cc2.9040...@ti.com> you wrote:
>
> You mean "__packed__" should be removed from "struct gp_header" alone,
> not from the other structs?
>From all of them.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB
Dear Aneesh V,
In message <4dd24bd6.5060...@ti.com> you wrote:
>
> > Would it be possible to do this even _before_ relocation, so to speed
> > up memory accesses during relocation? Of course, proper invalidates/
> > flushes will be needed before jumping to the RAM address, but I guess
> > this w
Hi Rienhard,
Le 16/05/2011 21:30, Reinhard Meyer a écrit :
> Dear Albert,
>> Hi Reinhard,
>>
>> Le 13/05/2011 10:46, Reinhard Meyer a écrit :
>>> Dear Albert,
>>>
>>> The following changes since commit
>>> 2e73808ee97d75400881d1fe144b062f427cfcb9:
>>> Clint Adams (1):
>>> Enable multiple fs option
Dear Aneesh V,
In message <4dd24715.4010...@ti.com> you wrote:
>
> > Please fix all these names.
>
> Ok. Including the existing CONFIG_SYS_NO_DCACHE and
> CONFIG_SYS_NO_ICACHE too, right?
yes, please. Thanks a lot!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolf
Hi Aneesh,
On Tuesday 17 May 2011 01:45 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd21baa.6000...@ti.com> you wrote:
>>
>>> What is MLO?
>>
>> MLO is the name of SPL created for OMAP. ROM code expects a file with
>> this name as the first image when it boots from FAT.
>
> What doe
Hi Wolfgang,
On Monday 16 May 2011 05:18 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
...
>
+struct ch_toc {
+ uint32_t section_offset;
+ uint32_t section_size;
+ uint8_t unused[12];
+ uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct c
Hi Wolfgang,
On Monday 16 May 2011 12:25 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305202276-27784-6-git-send-email-ane...@ti.com> you wrote:
>> - Enable I-cache on bootup
>> - Enable MMU and D-cache immediately after relocation
>> - Do necessary initialization before enablin
Hi, good day!
With the buzz of Android, Android phone come to be so popular. A professional
Android phone manufacturer here introduce you some quite hot now:
A2000 Quad Band Smart Phone Android 2.2 OS Support GPS WIFI Analog TV 4.3 Inch
Touch Screen 146usd
Mozart V9 Android 2.2 Dual
Signed-off-by: Luca Ceresoli
Cc: Wolfgang Denk
---
Changes in v3: this patch is new in v3.
net/tftp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 6d44298..a893e02 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -458,7 +458,7 @@ TftpHandle
Signed-off-by: Luca Ceresoli
Cc: Wolfgang Denk
---
Changes in v2: none.
Changes in v3:
- rebased on top of the net/tftp.c cleanup;
- removed all #ifdefs that used to remove negligible amounts of compiled code,
at the cost of a much less readable source file; after measurements, it
turne
Signed-off-by: Luca Ceresoli
Cc: Wolfgang Denk
---
Changes in v2: none.
Changes in v3:
- rebased on top of the net/tftp.c cleanup;
- made do_tftpsrv() static;
- improved tftpsrv command help;
- removed all #ifdefs that used to remove negligible amounts of compiled code,
at the cost of a
With the upcoming TFTP server implementation, requests can be either
outgoing or incoming, so avoid ambiguities.
Signed-off-by: Luca Ceresoli
Cc: Wolfgang Denk
---
Changes in v2: none.
Changes in v3:
- rebased on top of the net/tftp.c cleanup.
net/tftp.c | 12 ++--
1 files changed
With the upcoming TFTP server implementation, the remote node can be
either a client or a server, so avoid ambiguities.
Signed-off-by: Luca Ceresoli
Cc: Wolfgang Denk
---
Changes in v2:
- fixed checkpatch issues.
Changes in v3:
- rebased on top of the net/tftp.c cleanup;
- renamed also loca
This patch series adds to U-Boot the ability to receive a file via TFTP acting
as a server, instead of a client.
I rebased v3 on top of the net/tftp.c cleanup work that I submitted recently
(http://lists.denx.de/pipermail/u-boot/2011-May/092599.html) and removed all
the cleanups from this patchset
Hi Wolfgang,
On Monday 16 May 2011 12:23 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305202276-27784-5-git-send-email-ane...@ti.com> you wrote:
>> replace all occurences of CONFIG_L2_OFF with a more appropriate
>> CONFIG_SYS_NO_L2CACHE
>>
>> CONFIG_SYS_NO_L2CACHE has been chosen to
Hi Wolfgang,
On Tuesday 17 May 2011 03:01 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd23d3a.4010...@ti.com> you wrote:
>>
>>> How much of this is actually needed in the context of U-Boot?
>>
>> Please see above. As far as I know OMAP doesn't do DMA in U-Boot.
>
> Devices like USB
On 05/17/2011 07:10 AM, Jason Liu wrote:
> Hi, Stefano,
>
Hi Jason,
> But looking at the code bellow, beside we need make the function static,
> do we need to remove the break after the return statement? Otherwise,
> some complier may warn un-reachable code, IMHO.
You are right, and the break s
Hi Luca,
[...]
>> Hm, I have to admit that I do not really like adding so many ifdefs into
>> the tftp code and even into the state machine code. Can you give me a
>> number on how much larger u-boot gets on your platform with and without
>> the server support? If this is not too much, maybe we
On Tuesday 17 May 2011 03:01 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd23d3a.4010...@ti.com> you wrote:
>>
>>> How much of this is actually needed in the context of U-Boot?
>>
>> Please see above. As far as I know OMAP doesn't do DMA in U-Boot.
>
> Devices like USB oth Ethernet d
Hi Luca,
[...]
> I removed the checkpatch-related changes: they are now on the tftp
> cleanup patch series that I submitted on saturday, and on top of which
> v3 of the TFTP server will be based.
Thanks for your persistence - it is very much appreciated!
Detlev
--
The proprietary-Unix player
Dear Aneesh V,
In message <4dd23d3a.4010...@ti.com> you wrote:
>
> > How much of this is actually needed in the context of U-Boot?
>
> Please see above. As far as I know OMAP doesn't do DMA in U-Boot.
Devices like USB oth Ethernet don't use DMA for data transfers?
> > Please do not add dead co
Dear Aneesh V,
In message <4dd23561.70...@ti.com> you wrote:
>
> In fact I had searched for a macro for similar needs as my
> set_bit_field() is addressing in Linux Kernel too but didn't find any.
...
> I couldn't find any utility macros/functions for doing something like
> this.
>
> Please some
On Monday 16 May 2011 12:21 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305202276-27784-4-git-send-email-ane...@ti.com> you wrote:
>> - Add a framework for layered cache maintenance
>> - separate out SOC specific outer cache maintenance from
>>maintenance of caches kno
Hi Wolfgang,
On Tuesday 17 May 2011 10:57 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message you wrote:
>>
>> There are a few very primitive macros in setbits and clrbits. I would
>> very much like to see at least:
>
> Maybe we can agree to use these existing macros then instead of
> inv
Dear Chander Kashyap,
In message <1302843918-1105-1-git-send-email-chander.kash...@linaro.org> you
wrote:
> SROM config code is made common for S5P series of boards.
> smdkc100.c now refers to s5p-common/sromc.c for SROM related
> subroutines.
>
> Signed-off-by: Chander Kashyap
It appears this
Dear Minkyu Kang,
In message <4dd23309.1080...@samsung.com> you wrote:
> Add missing header file.
This should not be handled separately, but rather be squashed into the
patch that now creates the problem, i. e.
04/15 Chander Kashyap[U-Boot] [PATCH] S5P:SROM config code moved to
s5p-common d
Add missing header file.
Signed-off-by: Minkyu Kang
Signed-off-by: Chander Kashyap
---
arch/arm/include/asm/arch-s5pc2xx/sromc.h | 51 +
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-s5pc2xx/sromc.h
diff --git a/ar
Hi Chris,
> From: Luuk Paulussen
>
> When we use the ntpserverip environment variable argv[1] may not be set.
> Printing the error message using the NetNtpServerIP variable ensures the
> correct output in both cases.
>
> Signed-off-by: Luuk Paulussen
> Acked-by: Chris Packham
> Cc: Ben Warren
Dear Chander Kashyap,
Sorry to late review.
On 21 April 2011 16:02, Chander Kashyap wrote:
> Added MMC SPL boot support for SMDKV310. This framework design is
> based on nand_spl support.
>
> Signed-off-by: Chander Kashyap
> ---
> Makefile | 9 ++
> sp
Hi Simon and Wolfgang,
[...]
> In terms of all this discussion I can see your point :-) I did have
> expressions of interest from two people including one I thought was at your
> company, which I why I went to the effort to clean up and submit this. At
> that time I didn't realise it would be suc
Dear Aneesh V,
In message <4dd21fb9.6070...@ti.com> you wrote:
>
> The top-level make rule being the following, we will need a Makefile in
> the board directory, right?
>
> +SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
> +$(MAKE) -C spl/board/$(BOARDDIR) all
Maybe this needs to be
Dear Aneesh V,
In message <4dd21cd8.2080...@ti.com> you wrote:
>
> > There are common, board independent parts both in spl/nand and
> > spl/onenand.
>
> How about having them at the root level in 'spl/' ?
Why? It seems more logical to me to group nand and onenand related
files in their own subd
Dear Aneesh V,
In message <4dd21baa.6000...@ti.com> you wrote:
>
> > What is MLO?
>
> MLO is the name of SPL created for OMAP. ROM code expects a file with
> this name as the first image when it boots from FAT.
What does MLO mean?
> >> +#ifdef CONFIG_PRELOADER
> >> +/* SPL works from internal
Dear Aneesh V,
In message <4dd21961.7070...@ti.com> you wrote:
>
> >> SPL has access to .data right from the beginning. Besides this is too
> >> early. global data is not initialized yet.
> >
> > Please keep in mind that this is a special situation then. The code
> > will not work as intended for
Dear Aneesh V,
In message <4dd21843.4060...@ti.com> you wrote:
>
> > you could use
> >
> > #define OMAP4430_ES1_0 10
> > #define OMAP4430_ES2_0 20
> > #define OMAP4430_ES2_1 21
> > #define OMAP4430_ES2_2 22
> >
> > And then use a plain
> >
> > sprintf(omap4_rev, "OMAP4430 ES%d
1 - 100 of 104 matches
Mail list logo
