From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Tue, 31 Jan 2012 07:12:19 -0700 Subject: [U-Boot] Can u-Boot Ran from RAM? In-Reply-To: References: Message-ID: <4F27F6C3.8030205@boundarydevices.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 01/30/2012 09:07 PM, Bud Miljkovic wrote: > Hi there, > > > > While getting acquainted with possible u-Boot development issues, I read > FAQ "14.2.1. Can U-Boot be configured such that it can be started in > RAM?" and was puzzled to learn that u-Boot cannot run from RAM. > > > > Considering a custom platform, using i.MX536, I understand that the > i.MX53x processor has its own ROM-based code that performs boot time > essential devices initialisation, etc. In the case when NAND flash is > the program-image medium at the boot stage, first, the ROM-based code > checks for Discovered Bad Blocks Table (DBBT) presence and searches for > valid Firmware Configuration Block (FCB) on external NAND Flash. > > > > If FCB is found that points to the NAND Flash page(s) that contain the > first 4K of initial firmware to be loaded from NAND Flash. Then, it > loads the 4K of data, pointed by FCB, into the NFC RAM buffer. These > data contain a valid Image Vector Table (IVT). Then, the ROM-based code > processes IVT, executes the Device Configuration Data (DCD) sequences to > initialize boot-related integrated peripherals (typically, these are > IOMUX, SDRAM controller and boot memory controller), then copies the > application code, also contained in IVT, to target memory (typically, > SDRAM) and jumps to it. Typically, this application code is the custom > primary bootloader that completes loading the application code (e.g. > main OS bootloader) and passes the control to it. > > > > If FCB is not found the ROM-based code starts executing a download > protocol over UART or USB port in an attempt to get a valid IVT from a > host. If the IVT is eventually obtained it is processed as before. > > > > So the question is can this "custom primary bootloader" role, in fact, > be played by u-Boot. Reading your text of FAQ 14.2.1., it seems to me > that it cannot. On the other hand I know of some Freescale i.MX53x demo > boards (e.g. ARD, LOCO) that use u-Boot. > > > > I wonder what I'm missing here. > I think that FAQ is a bit misleading and really refers to using another boot loader to load U-Boot. On all i.MX processors I've had the pleasure of using, U-Boot runs only from RAM. I think you probably knew this because very few i.MX designs even have other memory (i.e. NOR flash) that allows XIP. For instance, the LOCO certainly isn't running __from__ SD card. Take a look at the link maps for builds of these platforms to clarify.