[U-Boot] Can u-Boot Ran from RAM?

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.
Regards,
Bud

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.

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.
The FAQ really means "is it possible to load u-boot from u-boot" ... which is possible in some cases, but officially unsupported.
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.
Yep, MX53 is well supported by mainline u-boot.
M
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Dear Marek Vasut,
In message 201202011112.28009.marek.vasut@gmail.com you wrote:
The FAQ really means "is it possible to load u-boot from u-boot" ... which is possible in some cases, but officially unsupported.
This is your interpretation, and it is not quite correct.
Best regards,
Wolfgang Denk

On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded u-boot, and then want to load another copy of u-boot into ram and then execute that directly.
so the question is "can u-boot be *started in ram*" and the answer is "no". normally u-boot is bootstrapped from non-ram storage (via a bootrom, or some bit of code being latched in at a hardcoded address, or some other cpu-specific magic). -mike

On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded u-boot, and then want to load another copy of u-boot into ram and then execute that directly.
so the question is "can u-boot be *started in ram*" and the answer is "no".
The answer is "yes if you know how to do it" ;-)
normally u-boot is bootstrapped from non-ram storage (via a bootrom, or some bit of code being latched in at a hardcoded address, or some other cpu-specific magic). -mike

Dear Marek Vasut,
In message 201202011111.09465.marek.vasut@gmail.com you wrote:
On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded u-boot, and then want to load another copy of u-boot into ram and then execute that directly.
so the question is "can u-boot be *started in ram*" and the answer is "no".
The answer is "yes if you know how to do it" ;-)
The answer is "NO". You cannot load the _normal_ U-Boot image to RAM and start it. You must prepare a _special_ image which omits all the initializations that are normally included.
This FAQ addresses the situation where people want to load and run their _normal_ images before burning these to flash. And this CANNOT be done like that.
Best regards,
Wolfgang Denk

Dear Marek Vasut,
In message 201202011111.09465.marek.vasut@gmail.com you wrote:
On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded u-boot, and then want to load another copy of u-boot into ram and then execute that directly.
so the question is "can u-boot be *started in ram*" and the answer is "no".
The answer is "yes if you know how to do it" ;-)
The answer is "NO". You cannot load the _normal_ U-Boot image to RAM and start it. You must prepare a _special_ image which omits all the initializations that are normally included.
You can on PXA ;-)
This FAQ addresses the situation where people want to load and run their _normal_ images before burning these to flash. And this CANNOT be done like that.
You're certainly right this is true for general case, but there are special cases where you can load u-boot from u-boot without any harm (PXA is the example).
Best regards,
Wolfgang Denk

I am newbie in this. Anybody done it?
Any lead is appreciated.
Cheers, Bud Miljkovic
-----Original Message----- From: Marek Vasut [mailto:marek.vasut@gmail.com] Sent: Wednesday, 1 February 2012 11:58 p.m. To: Wolfgang Denk Cc: u-boot@lists.denx.de; Bud Miljkovic Subject: Re: [U-Boot] Can u-Boot Ran from RAM?
Dear Marek Vasut,
In message 201202011111.09465.marek.vasut@gmail.com you wrote:
On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded
u-boot, and
then want to load another copy of u-boot into ram and then execute
that
directly.
so the question is "can u-boot be *started in ram*" and the answer
is
"no".
The answer is "yes if you know how to do it" ;-)
The answer is "NO". You cannot load the _normal_ U-Boot image to RAM and start it. You must prepare a _special_ image which omits all the initializations that are normally included.
You can on PXA ;-)
This FAQ addresses the situation where people want to load and run their _normal_ images before burning these to flash. And this CANNOT be done like that.
You're certainly right this is true for general case, but there are special cases where you can load u-boot from u-boot without any harm (PXA is the
example).
Best regards,
Wolfgang Denk

On Thursday 02 February 2012 16:40:45 Bud Miljkovic wrote:
I am newbie in this. Anybody done it?
Any lead is appreciated.
please do not hijack threads. do not just pick a random e-mail and hit "reply". start a new one from scratch.
as for your question, check out the latest git. yaffs2 is already in u-boot and has been for some time. -mike

Bud
Last time I looked, the yaffs code in u-boot is pretty old and I would recommend refreshing it.
-- Charles
On Friday 03 February 2012 10:40:45 Bud Miljkovic wrote:
I am newbie in this. Anybody done it?
Any lead is appreciated.
Cheers, Bud Miljkovic
-----Original Message----- From: Marek Vasut [mailto:marek.vasut@gmail.com] Sent: Wednesday, 1 February 2012 11:58 p.m. To: Wolfgang Denk Cc: u-boot@lists.denx.de; Bud Miljkovic Subject: Re: [U-Boot] Can u-Boot Ran from RAM?
Dear Marek Vasut,
In message 201202011111.09465.marek.vasut@gmail.com you wrote:
On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded
u-boot, and
then want to load another copy of u-boot into ram and then execute
that
directly.
so the question is "can u-boot be *started in ram*" and the answer
is
"no".
The answer is "yes if you know how to do it" ;-)
The answer is "NO". You cannot load the _normal_ U-Boot image to RAM and start it. You must prepare a _special_ image which omits all the initializations that are normally included.
You can on PXA ;-)
This FAQ addresses the situation where people want to load and run their _normal_ images before burning these to flash. And this CANNOT be done like that.
You're certainly right this is true for general case, but there are special cases where you can load u-boot from u-boot without any harm (PXA is the
example).
Best regards,
Wolfgang Denk
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

I have a pile of changes to u-boot that make yaffs work w/mtdparts (I.e. "ymount /<partition>" looks through mtdparts to find start/end blocks, etc) that works in u-boot-2011.06), and want to refresh that for a current u-boot, but it's gonna take time to get it into acceptable shape for submission.
If anyone wants the raw changes to get a head start I'm happy to pass them along...
Splat-fingered from my iPhone
On Feb 2, 2012, at 5:20 PM, "Charles Manning" manningc2@actrix.gen.nz wrote:
Bud
Last time I looked, the yaffs code in u-boot is pretty old and I would recommend refreshing it.
-- Charles
On Friday 03 February 2012 10:40:45 Bud Miljkovic wrote:
I am newbie in this. Anybody done it?
Any lead is appreciated.
Cheers, Bud Miljkovic
-----Original Message----- From: Marek Vasut [mailto:marek.vasut@gmail.com] Sent: Wednesday, 1 February 2012 11:58 p.m. To: Wolfgang Denk Cc: u-boot@lists.denx.de; Bud Miljkovic Subject: Re: [U-Boot] Can u-Boot Ran from RAM?
Dear Marek Vasut,
In message 201202011111.09465.marek.vasut@gmail.com you wrote:
On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded
u-boot, and
then want to load another copy of u-boot into ram and then execute
that
directly.
so the question is "can u-boot be *started in ram*" and the answer
is
"no".
The answer is "yes if you know how to do it" ;-)
The answer is "NO". You cannot load the _normal_ U-Boot image to RAM and start it. You must prepare a _special_ image which omits all the initializations that are normally included.
You can on PXA ;-)
This FAQ addresses the situation where people want to load and run their _normal_ images before burning these to flash. And this CANNOT be done like that.
You're certainly right this is true for general case, but there are special cases where you can load u-boot from u-boot without any harm (PXA is the
example).
Best regards,
Wolfgang Denk
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Dear Charles Manning,
In message 201202031119.57323.manningc2@actrix.gen.nz you wrote:
Last time I looked, the yaffs code in u-boot is pretty old and I would recommend refreshing it.
Patches are welcome!
Best regards,
Wolfgang Denk

Here is another go on this issue!
The following is a response from Freescale technical support with my questions inserted: ----------> The "initial bootloader" code (including IVT, DCD and application code itself) should be very small to fit into 4Kb space that is read out from NAND Flash during the first stage of NAND boot. The typical use case of NAND boot in i.MX53-based systems is as follows. 1. Internal BootROM code finds the valid initial 4Kb space within NAND Flash memory and loads it into the NAND Flash Controller's (NFC's) RAM buffer.
2. Internal BootROM code finds a valid IVT in just loaded data, processes it, finds DCD and performs the initialization of integrated peripherals (typically, SDRAM controller, IOMUX and, if required, other peripherals) according to it.
3. Internal BootROM code finds an application code (typically, "initial bootloader"), copies it into target memory (typically SDRAM) and passes control to it.
4. The "initial bootloader" code copies a main bootloader (e.g. uBoot) from NAND Flash to SDRAM and passes control to it. Bud_Q1> This is issue: will the uBoot run correctly if it starts from SDRAM as suggested?
Bud_Q2> Based on my understanding of how the u-Boot runs, the "initial bootloader" should just pass control to the u-Boot in NAND? This would cause for all integrated peripherals to re-initialized but should not be a problem.
5. The boot process continues under the control of main bootloader.
So, at the moment when main bootloader (uBoot) starts working, most of the primarily required integrated peripherals (SDRAM controller, NAND Flash controller) are already initialized and working, so, a main bootloader has no need to re-initialize them. Bud_Q3> Is there maybe a version of a u-Boot that skips initialization phase, i.e. just relocates itself to RAM?
<------------
Can you please respond to my questions? -bud
-----Original Message----- From: Marek Vasut [mailto:marek.vasut@gmail.com] Sent: Wednesday, 1 February 2012 11:58 p.m. To: Wolfgang Denk Cc: u-boot@lists.denx.de; Bud Miljkovic Subject: Re: [U-Boot] Can u-Boot Ran from RAM?
Dear Marek Vasut,
In message 201202011111.09465.marek.vasut@gmail.com you wrote:
On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
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.
you misread it. the question is for people who have loaded
u-boot, and
then want to load another copy of u-boot into ram and then execute
that
directly.
so the question is "can u-boot be *started in ram*" and the answer
is
"no".
The answer is "yes if you know how to do it" ;-)
The answer is "NO". You cannot load the _normal_ U-Boot image to RAM and start it. You must prepare a _special_ image which omits all the initializations that are normally included.
You can on PXA ;-)
This FAQ addresses the situation where people want to load and run their _normal_ images before burning these to flash. And this CANNOT be done like that.
You're certainly right this is true for general case, but there are special cases where you can load u-boot from u-boot without any harm (PXA is the
example).
Best regards,
Wolfgang Denk

On Tuesday 31 January 2012 17:07:05 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.
This is clearly not true.
The omap devices and davinci devices both use rom boot loaders to load uboot into ram for further execution.
In the case of omaps it is often even more complex using a rom boot loader to load x-load (or cut down u-boot) to load the real uboot which then loads Linux.
-- Charles
participants (7)
-
Bud Miljkovic
-
Charles Manning
-
Eric Nelson
-
Marek Vasut
-
Mike Frysinger
-
Peter Barada
-
Wolfgang Denk