* [U-Boot] Fwd: [PATCH] arm/lib: Add get_effective_memsize() to board.c
[not found] <1392069859-24805-1-git-send-email-yorksun@freescale.com>
@ 2014-02-10 22:18 ` York Sun
[not found] ` <1392070794.6733.362.camel@snotra.buserror.net>
1 sibling, 0 replies; 8+ messages in thread
From: York Sun @ 2014-02-10 22:18 UTC (permalink / raw)
To: u-boot
-------- Original Message --------
Subject: [PATCH] arm/lib: Add get_effective_memsize() to board.c
Date: Mon, 10 Feb 2014 14:04:19 -0800
From: York Sun <yorksun@freescale.com>
To: <albert.u.boot@aribaud.net>
CC: <scottwood@freescale.com>, York Sun <yorksun@freescale.com>
This function has been around for powerpc. It is used for systems with
memory more than CONFIG_MAX_MEM_MAPPED. In case of non-contiguous memory,
this feature can limit U-boot to one block without going over the limit.
Signed-off-by: York Sun <yorksun@freescale.com>
---
arch/arm/lib/board.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index b770e25..b31c8ff 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -263,6 +263,24 @@ init_fnc_t *init_sequence[] = {
NULL,
};
+phys_size_t get_effective_memsize(void)
+{
+#ifndef CONFIG_VERY_BIG_RAM
+ return gd->ram_size;
+#else
+ /* limit stack to what we can reasonable map */
+ return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
+ CONFIG_MAX_MEM_MAPPED : gd->ram_size);
+#endif
+}
+
+#ifdef CONFIG_LOGBUFFER
+unsigned long logbuffer_base(void)
+{
+ return CONFIG_SYS_SDRAM_BASE + get_effective_memsize() - LOGBUFF_LEN;
+}
+#endif
+
void board_init_f(ulong bootflag)
{
bd_t *bd;
@@ -322,7 +340,7 @@ void board_init_f(ulong bootflag)
gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
#endif
- addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size;
+ addr = CONFIG_SYS_SDRAM_BASE + get_effective_memsize();
#ifdef CONFIG_LOGBUFFER
#ifndef CONFIG_ALT_LB_ADDR
--
1.7.9.5
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH] arm/lib: Add get_effective_memsize() to board.c
[not found] ` <1392070794.6733.362.camel@snotra.buserror.net>
@ 2014-02-10 22:33 ` York Sun
2014-02-10 22:37 ` Scott Wood
0 siblings, 1 reply; 8+ messages in thread
From: York Sun @ 2014-02-10 22:33 UTC (permalink / raw)
To: u-boot
On 02/10/2014 02:19 PM, Scott Wood wrote:
> On Mon, 2014-02-10 at 14:04 -0800, York Sun wrote:
>> This function has been around for powerpc. It is used for systems with
>> memory more than CONFIG_MAX_MEM_MAPPED. In case of non-contiguous memory,
>> this feature can limit U-boot to one block without going over the limit.
>>
>> Signed-off-by: York Sun <yorksun@freescale.com>
>> ---
>> arch/arm/lib/board.c | 20 +++++++++++++++++++-
>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>> index b770e25..b31c8ff 100644
>> --- a/arch/arm/lib/board.c
>> +++ b/arch/arm/lib/board.c
>> @@ -263,6 +263,24 @@ init_fnc_t *init_sequence[] = {
>> NULL,
>> };
>>
>> +phys_size_t get_effective_memsize(void)
>> +{
>> +#ifndef CONFIG_VERY_BIG_RAM
>
> Whitespace
I think I have put a tab instead of a space.
>
>> + return gd->ram_size;
>> +#else
>> + /* limit stack to what we can reasonable map */
>> + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
>> + CONFIG_MAX_MEM_MAPPED : gd->ram_size);
>> +#endif
>> +}
>
> Is there anything really arch-specific about this function?
>
Not at all. It is not called by any other file either. I tried to move the
function phys_size_t get_effective_memsize(void) out, but I don't see which
common file fits this purpose.
York
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH] arm/lib: Add get_effective_memsize() to board.c
2014-02-10 22:33 ` [U-Boot] " York Sun
@ 2014-02-10 22:37 ` Scott Wood
2014-02-10 22:55 ` York Sun
0 siblings, 1 reply; 8+ messages in thread
From: Scott Wood @ 2014-02-10 22:37 UTC (permalink / raw)
To: u-boot
On Mon, 2014-02-10 at 14:33 -0800, York Sun wrote:
> On 02/10/2014 02:19 PM, Scott Wood wrote:
> > On Mon, 2014-02-10 at 14:04 -0800, York Sun wrote:
> >> This function has been around for powerpc. It is used for systems with
> >> memory more than CONFIG_MAX_MEM_MAPPED. In case of non-contiguous memory,
> >> this feature can limit U-boot to one block without going over the limit.
> >>
> >> Signed-off-by: York Sun <yorksun@freescale.com>
> >> ---
> >> arch/arm/lib/board.c | 20 +++++++++++++++++++-
> >> 1 file changed, 19 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> >> index b770e25..b31c8ff 100644
> >> --- a/arch/arm/lib/board.c
> >> +++ b/arch/arm/lib/board.c
> >> @@ -263,6 +263,24 @@ init_fnc_t *init_sequence[] = {
> >> NULL,
> >> };
> >>
> >> +phys_size_t get_effective_memsize(void)
> >> +{
> >> +#ifndef CONFIG_VERY_BIG_RAM
> >
> > Whitespace
>
> I think I have put a tab instead of a space.
Yes.
> >> + return gd->ram_size;
> >> +#else
> >> + /* limit stack to what we can reasonable map */
> >> + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
> >> + CONFIG_MAX_MEM_MAPPED : gd->ram_size);
> >> +#endif
> >> +}
> >
> > Is there anything really arch-specific about this function?
> >
>
> Not at all. It is not called by any other file either. I tried to move the
> function phys_size_t get_effective_memsize(void) out, but I don't see which
> common file fits this purpose.
Not having an obvious place to put it isn't a good reason to keep it
duplicated in arch code. Moving it to generic code would let you also
avoid overriding things like logbuffer_base().
-Scott
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH] arm/lib: Add get_effective_memsize() to board.c
2014-02-10 22:37 ` Scott Wood
@ 2014-02-10 22:55 ` York Sun
2014-02-10 23:00 ` Scott Wood
2014-02-11 8:21 ` Wolfgang Denk
0 siblings, 2 replies; 8+ messages in thread
From: York Sun @ 2014-02-10 22:55 UTC (permalink / raw)
To: u-boot
On 02/10/2014 02:37 PM, Scott Wood wrote:
> On Mon, 2014-02-10 at 14:33 -0800, York Sun wrote:
>> On 02/10/2014 02:19 PM, Scott Wood wrote:
>>> On Mon, 2014-02-10 at 14:04 -0800, York Sun wrote:
>>>> This function has been around for powerpc. It is used for systems with
>>>> memory more than CONFIG_MAX_MEM_MAPPED. In case of non-contiguous memory,
>>>> this feature can limit U-boot to one block without going over the limit.
>>>>
>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>> ---
>>>> arch/arm/lib/board.c | 20 +++++++++++++++++++-
>>>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>>>> index b770e25..b31c8ff 100644
>>>> --- a/arch/arm/lib/board.c
>>>> +++ b/arch/arm/lib/board.c
>>>> @@ -263,6 +263,24 @@ init_fnc_t *init_sequence[] = {
>>>> NULL,
>>>> };
>>>>
>>>> +phys_size_t get_effective_memsize(void)
>>>> +{
>>>> +#ifndef CONFIG_VERY_BIG_RAM
>>>
>>> Whitespace
>>
>> I think I have put a tab instead of a space.
>
> Yes.
>
>>>> + return gd->ram_size;
>>>> +#else
>>>> + /* limit stack to what we can reasonable map */
>>>> + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
>>>> + CONFIG_MAX_MEM_MAPPED : gd->ram_size);
>>>> +#endif
>>>> +}
>>>
>>> Is there anything really arch-specific about this function?
>>>
>>
>> Not at all. It is not called by any other file either. I tried to move the
>> function phys_size_t get_effective_memsize(void) out, but I don't see which
>> common file fits this purpose.
>
> Not having an obvious place to put it isn't a good reason to keep it
> duplicated in arch code. Moving it to generic code would let you also
> avoid overriding things like logbuffer_base().
>
I see the benefit of putting the code to common file and modify the
common/cmd_log.c for logbuffer_base(). Can you suggest a location for
get_effective_memsize(void)? Only powerpc uses this function before this patch.
Putting into common.h seems too generic.
York
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH] arm/lib: Add get_effective_memsize() to board.c
2014-02-10 22:55 ` York Sun
@ 2014-02-10 23:00 ` Scott Wood
2014-02-10 23:03 ` York Sun
2014-02-11 8:21 ` Wolfgang Denk
1 sibling, 1 reply; 8+ messages in thread
From: Scott Wood @ 2014-02-10 23:00 UTC (permalink / raw)
To: u-boot
On Mon, 2014-02-10 at 14:55 -0800, York Sun wrote:
> On 02/10/2014 02:37 PM, Scott Wood wrote:
> > On Mon, 2014-02-10 at 14:33 -0800, York Sun wrote:
> >> On 02/10/2014 02:19 PM, Scott Wood wrote:
> >>> On Mon, 2014-02-10 at 14:04 -0800, York Sun wrote:
> >>>> This function has been around for powerpc. It is used for systems with
> >>>> memory more than CONFIG_MAX_MEM_MAPPED. In case of non-contiguous memory,
> >>>> this feature can limit U-boot to one block without going over the limit.
> >>>>
> >>>> Signed-off-by: York Sun <yorksun@freescale.com>
> >>>> ---
> >>>> arch/arm/lib/board.c | 20 +++++++++++++++++++-
> >>>> 1 file changed, 19 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> >>>> index b770e25..b31c8ff 100644
> >>>> --- a/arch/arm/lib/board.c
> >>>> +++ b/arch/arm/lib/board.c
> >>>> @@ -263,6 +263,24 @@ init_fnc_t *init_sequence[] = {
> >>>> NULL,
> >>>> };
> >>>>
> >>>> +phys_size_t get_effective_memsize(void)
> >>>> +{
> >>>> +#ifndef CONFIG_VERY_BIG_RAM
> >>>
> >>> Whitespace
> >>
> >> I think I have put a tab instead of a space.
> >
> > Yes.
> >
> >>>> + return gd->ram_size;
> >>>> +#else
> >>>> + /* limit stack to what we can reasonable map */
> >>>> + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
> >>>> + CONFIG_MAX_MEM_MAPPED : gd->ram_size);
> >>>> +#endif
> >>>> +}
> >>>
> >>> Is there anything really arch-specific about this function?
> >>>
> >>
> >> Not at all. It is not called by any other file either. I tried to move the
> >> function phys_size_t get_effective_memsize(void) out, but I don't see which
> >> common file fits this purpose.
> >
> > Not having an obvious place to put it isn't a good reason to keep it
> > duplicated in arch code. Moving it to generic code would let you also
> > avoid overriding things like logbuffer_base().
> >
>
> I see the benefit of putting the code to common file and modify the
> common/cmd_log.c for logbuffer_base(). Can you suggest a location for
> get_effective_memsize(void)? Only powerpc uses this function before this patch.
> Putting into common.h seems too generic.
What's wrong with common.h? That's where get_ram_size() is.
-Scott
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH] arm/lib: Add get_effective_memsize() to board.c
2014-02-10 23:00 ` Scott Wood
@ 2014-02-10 23:03 ` York Sun
0 siblings, 0 replies; 8+ messages in thread
From: York Sun @ 2014-02-10 23:03 UTC (permalink / raw)
To: u-boot
On 02/10/2014 03:00 PM, Scott Wood wrote:
> On Mon, 2014-02-10 at 14:55 -0800, York Sun wrote:
>> On 02/10/2014 02:37 PM, Scott Wood wrote:
>>> On Mon, 2014-02-10 at 14:33 -0800, York Sun wrote:
>>>> On 02/10/2014 02:19 PM, Scott Wood wrote:
>>>>> On Mon, 2014-02-10 at 14:04 -0800, York Sun wrote:
>>>>>> This function has been around for powerpc. It is used for systems with
>>>>>> memory more than CONFIG_MAX_MEM_MAPPED. In case of non-contiguous memory,
>>>>>> this feature can limit U-boot to one block without going over the limit.
>>>>>>
>>>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>>> ---
>>>>>> arch/arm/lib/board.c | 20 +++++++++++++++++++-
>>>>>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>>>>>> index b770e25..b31c8ff 100644
>>>>>> --- a/arch/arm/lib/board.c
>>>>>> +++ b/arch/arm/lib/board.c
>>>>>> @@ -263,6 +263,24 @@ init_fnc_t *init_sequence[] = {
>>>>>> NULL,
>>>>>> };
>>>>>>
>>>>>> +phys_size_t get_effective_memsize(void)
>>>>>> +{
>>>>>> +#ifndef CONFIG_VERY_BIG_RAM
>>>>>
>>>>> Whitespace
>>>>
>>>> I think I have put a tab instead of a space.
>>>
>>> Yes.
>>>
>>>>>> + return gd->ram_size;
>>>>>> +#else
>>>>>> + /* limit stack to what we can reasonable map */
>>>>>> + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
>>>>>> + CONFIG_MAX_MEM_MAPPED : gd->ram_size);
>>>>>> +#endif
>>>>>> +}
>>>>>
>>>>> Is there anything really arch-specific about this function?
>>>>>
>>>>
>>>> Not at all. It is not called by any other file either. I tried to move the
>>>> function phys_size_t get_effective_memsize(void) out, but I don't see which
>>>> common file fits this purpose.
>>>
>>> Not having an obvious place to put it isn't a good reason to keep it
>>> duplicated in arch code. Moving it to generic code would let you also
>>> avoid overriding things like logbuffer_base().
>>>
>>
>> I see the benefit of putting the code to common file and modify the
>> common/cmd_log.c for logbuffer_base(). Can you suggest a location for
>> get_effective_memsize(void)? Only powerpc uses this function before this patch.
>> Putting into common.h seems too generic.
>
> What's wrong with common.h? That's where get_ram_size() is.
>
You are right. I will put the function in common/memsize.c and put the prototype
in common.h.
York
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH] arm/lib: Add get_effective_memsize() to board.c
2014-02-10 22:55 ` York Sun
2014-02-10 23:00 ` Scott Wood
@ 2014-02-11 8:21 ` Wolfgang Denk
2014-02-11 17:40 ` York Sun
1 sibling, 1 reply; 8+ messages in thread
From: Wolfgang Denk @ 2014-02-11 8:21 UTC (permalink / raw)
To: u-boot
Dear York Sun,
In message <52F958D0.4050004@freescale.com> you wrote:
>
> I see the benefit of putting the code to common file and modify the
> common/cmd_log.c for logbuffer_base(). Can you suggest a location for
> get_effective_memsize(void)? Only powerpc uses this function before this patch.
> Putting into common.h seems too generic.
common/memsize.c ?
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: wd at denx.de
Software suppliers are trying to make their software packages more
``user-friendly''. . . . Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover. - Bill Gates
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] [PATCH] arm/lib: Add get_effective_memsize() to board.c
2014-02-11 8:21 ` Wolfgang Denk
@ 2014-02-11 17:40 ` York Sun
0 siblings, 0 replies; 8+ messages in thread
From: York Sun @ 2014-02-11 17:40 UTC (permalink / raw)
To: u-boot
On 02/11/2014 12:21 AM, Wolfgang Denk wrote:
> Dear York Sun,
>
> In message <52F958D0.4050004@freescale.com> you wrote:
>>
>> I see the benefit of putting the code to common file and modify the
>> common/cmd_log.c for logbuffer_base(). Can you suggest a location for
>> get_effective_memsize(void)? Only powerpc uses this function before this patch.
>> Putting into common.h seems too generic.
>
> common/memsize.c ?
>
Yes. Thanks. I am working on this file.
York
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-02-11 17:40 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1392069859-24805-1-git-send-email-yorksun@freescale.com>
2014-02-10 22:18 ` [U-Boot] Fwd: [PATCH] arm/lib: Add get_effective_memsize() to board.c York Sun
[not found] ` <1392070794.6733.362.camel@snotra.buserror.net>
2014-02-10 22:33 ` [U-Boot] " York Sun
2014-02-10 22:37 ` Scott Wood
2014-02-10 22:55 ` York Sun
2014-02-10 23:00 ` Scott Wood
2014-02-10 23:03 ` York Sun
2014-02-11 8:21 ` Wolfgang Denk
2014-02-11 17:40 ` York Sun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox