public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection
Date: Wed, 11 Jul 2012 03:46:46 -0700	[thread overview]
Message-ID: <4FFD5996.3050103@ti.com> (raw)
In-Reply-To: <20120711104036.GB27810@Hardy>

On 07/11/2012 03:40 AM, Sughosh Ganu wrote:
> On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
>> On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
>>> On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
>>>> On Wed, 11 Jul 2012 00:09:06 +0530
>>>> Sughosh Ganu <urwithsughosh@gmail.com> wrote:
>>>>>> diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
>>>>>> b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
>>>>>> --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
>>>>>> +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
>>>>>
>>>>> <snip>
>>>>>
>>>>>>  void board_init_r(gd_t *id, ulong dummy)
>>>>>>  {
>>>>>> -#ifdef CONFIG_SPL_NAND_LOAD
>>>>>> -	nand_init();
>>>>>> -	puts("Nand boot...\n");
>>>>>> -	nand_boot();
>>>>>> -#endif
>>>>>> -#ifdef CONFIG_SPL_SPI_LOAD
>>>>>> -	mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
>>>>>> -			CONFIG_SYS_MALLOC_LEN);
>>>>>> +	u32 boot_device;
>>>>>> +	void (*uboot)(void) __noreturn;
>>>>>> +
>>>>>> +	mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
>>>>>> +			CONFIG_SYS_SPL_MALLOC_SIZE);
>>>>>
>>>>> We do not need any heap for the spl on the hawkboard, so can you
>>>>> please explain why do we need the heap allocation for all spl
>>>>> images. Can't this be made configurable.
>>>>
>>>> this is needed at least for:
>>>>   * MMC support
>>>>   * SPI support
>>>>   * gunzip support (see next patch)
>>>>
>>>> it can be configurable, but is it reasonable?
>>>
>>> I would think so -- i guess it should be fine to include this only for
>>> boards/configurations that actually need the heap.
>>
>> Shouldn't "load u-boot.img from vfat SD card" be a common case at least
>> for developers?
> 
> Yes, it should be, but what i meant was that things that are not
> needed for certain boards or configurations need not be made
> common. Like in this case, why does setting up a heap, which is not
> needed at least on my board need to be common for all spl images. If a
> particular board/configuration needs it, then use it.

Wouldn't load from SD be a common case on hawkboard, esp once the ones
that can load from SD, from the ROM become more available?  I'm fine
saying that we should wrap the call around an #if, but I would expect it
to be set in the common case and only not set in custom production boards.

-- 
Tom

  reply	other threads:[~2012-07-11 10:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 18:53 [U-Boot] [PATCH V3 1/3] MMC: u-boot-spl may be compiled without partition support Mikhail Kshevetskiy
2012-07-09 18:53 ` [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection Mikhail Kshevetskiy
2012-07-09 19:41   ` Tom Rini
2012-07-09 19:57     ` Mikhail Kshevetskiy
2012-07-09 20:08       ` Tom Rini
2012-07-09 20:10         ` Mikhail Kshevetskiy
2012-07-10 18:39   ` Sughosh Ganu
2012-07-10 19:20     ` Mikhail Kshevetskiy
2012-07-11  6:38       ` Sughosh Ganu
2012-07-11  8:19         ` Tom Rini
2012-07-11 10:40           ` Sughosh Ganu
2012-07-11 10:46             ` Tom Rini [this message]
2012-07-11 11:05               ` Sughosh Ganu
2012-07-11 11:43                 ` Tom Rini
2012-07-11 12:08                   ` Sughosh Ganu
2012-07-11 12:15                     ` Tom Rini
2012-07-09 18:53 ` [U-Boot] [PATCH V3 3/3] arm/davinci: spl - add compressed u-boot image support Mikhail Kshevetskiy
2012-07-10 18:49   ` Sughosh Ganu
2012-07-10 19:29     ` Mikhail Kshevetskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FFD5996.3050103@ti.com \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox