From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 4 Oct 2011 11:17:42 -0500 Subject: [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT In-Reply-To: <20111004153838.3CD0018E5B3A@gemini.denx.de> References: <1317741066-31121-1-git-send-email-aneesh@ti.com> <20111004153838.3CD0018E5B3A@gemini.denx.de> Message-ID: <4E8B31A6.6080104@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/04/2011 10:38 AM, Wolfgang Denk wrote: > 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. > > > U-Boot has not been designed to run complex code like file systemes > before relocation, and SPL code _is_ before relocation. SPL has its own relocation. If it were under the same restrictions as normal pre-relocation U-Boot, where would it load an image to? All SPL really is, is some makefile infrastructure to produce a second, special-purpose U-Boot image. The degree to which it is stripped down depends on the requirements of the particular target. -Scott