All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT
Date: Tue, 04 Oct 2011 21:30:07 +0530	[thread overview]
Message-ID: <4E8B2D87.9050403@ti.com> (raw)
In-Reply-To: <20111004153838.3CD0018E5B3A@gemini.denx.de>

Dear Wolfgang,

On Tuesday 04 October 2011 09:08 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1317741066-31121-1-git-send-email-aneesh@ti.com>  you wrote:
>> From: a0393566local (none)<a0393566local@ula0393566>
>>
>> FAT library now uses malloc() and free(). But SPL doesn't
>> have heap until now. Setup a heap in SDRAM to fix this issue.
>>
>> However this increases SPL footprint beyond the available SRAM
>> budget. So, compile out some fancy features in the SDARM init
>> bring back footprint under control
>>
>> CC: Sandeep Paulraj<s-paulraj@ti.com>
>> CC: Wolfgang Denk<wd@denx.de>
>> Signed-off-by: Aneesh V<aneesh@ti.com>
>
> I think it is a bad idea to go this way.
>
> We should face the fact that SPL code is running before proper
> relocation to RAM, and thus there are certain limitations.
>
> Certain parts of the code, including file system code, has not been
> written with such limitations in mind.  It makes use of functions that
> are not available in SPL code, or of features that are not available
> in SPL code (like a heap, or a virtually unlimited stack).
>
> You may be lucky here, and your test cases with the FFAT code may
> actually work.  But I would not bet on it.
>

I have mentioned why FAT is inevitable for us in a separate mail in
this thread.

>
> U-Boot has not been designed to run complex code like file systemes
> before relocation, and SPL code _is_ before relocation.

Please note that SPL is not as restricted as it seems(at least the way
it is now). For instance, OMAP SPL has
1. gd in SRAM
2. .bss in SDRAM and
3. heap in SDRAM(with this patch)
So, we have everything that takes for any driver to function as long as
the .text fits in the SRAM.

I think the same principles apply to all platforms not just OMAP. These
complex drivers are likely to be used only after SDRAM is initialized.
After SDRAM is initialized you have plenty of space for .bss and heap.
So the only limitation for an SPL should be .text and .data size.

best regards,
Aneesh

  reply	other threads:[~2011-10-04 16:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 18:50 [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) Aguirre, Sergio
2011-10-04 14:15 ` Aneesh V
2011-10-04 14:51   ` Wolfgang Denk
2011-10-04 15:37     ` Aneesh V
2011-10-04 18:05       ` Wolfgang Denk
2011-10-05  9:42         ` Aneesh V
2011-10-07  1:40     ` Tom Rini
2011-10-07  5:27       ` Wolfgang Denk
2011-10-04 15:11 ` [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT Aneesh V
2011-10-04 15:38   ` Wolfgang Denk
2011-10-04 16:00     ` Aneesh V [this message]
2011-10-04 16:17     ` Scott Wood

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=4E8B2D87.9050403@ti.com \
    --to=aneesh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.