[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE
In several board config files (namely 8xxx boards), I see code that looks like this:
#if (CFG_MONITOR_BASE < CFG_FLASH_BASE) #define CFG_RAMBOOT #else #undef CFG_RAMBOOT #endif
...
#ifndef CFG_RAMBOOT #define CFG_ENV_IS_IN_FLASH 1 #define CFG_ENV_ADDR (CFG_MONITOR_BASE + CFG_MONITOR_LEN) #define CFG_ENV_SECT_SIZE 0x40000 /* 256K(one sector) for env */ #define CFG_ENV_SIZE 0x2000 #else #define CFG_NO_FLASH 1 /* Flash is not usable now */ #define CFG_ENV_IS_NOWHERE 1 /* Store ENV in memory only */ #define CFG_ENV_ADDR (CFG_MONITOR_BASE - 0x1000) #define CFG_ENV_SIZE 0x2000 #endif
So CFG_RAMBOOT is defined if U-Boot is located in RAM instead of in Flash.
On a system that has flash, why would we ever support this configuration? It doesn't even make any sense, because a whole bunch of DDR and LAWBAR setup needs to happen before RAM can even be accessed, so you can't copy u-boot to RAM and reset the system.
In message 464B6DCC.4030203@freescale.com you wrote:
On a system that has flash, why would we ever support this configuration? It doesn't even make any sense, because a whole bunch of DDR and LAWBAR setup needs to happen before RAM can even be accessed, so you can't copy u-boot to RAM and reset the system.
Did you read the FAQ? You just wrote another version of "14.2.1. Can U-Boot be configured such that it can be started in RAM?"
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 464B6DCC.4030203@freescale.com you wrote:
On a system that has flash, why would we ever support this configuration? It doesn't even make any sense, because a whole bunch of DDR and LAWBAR setup needs to happen before RAM can even be accessed, so you can't copy u-boot to RAM and reset the system.
Did you read the FAQ? You just wrote another version of "14.2.1. Can U-Boot be configured such that it can be started in RAM?"
Yes, I have read it, but it doesn't really answer my question. I'm not asking if I can boot from RAM, I'm asking why would someone think it could be done? If anything, 14.2.1 re-inforces my point: if booting from RAM doesn't make sense, why are so many board header files configured to enable it?
On Wednesday, May 16, 2007 3:11 PM Timur Tabi wrote:
I'm not asking if I can boot from RAM, I'm asking why would someone think it could be done?
If
anything, 14.2.1 re-inforces my point: if booting from RAM doesn't make sense, why are
so
many board header files configured to enable it?
It's too strong a statement "booting from RAM doesn't make sense". Of course, under "booting from RAM" I mean that u-boot runs from RAM and thus its image must be compiled this way. U-boot image and environment variables can be still on the flash (I assume the system has one) and some other (first stage) bootloader fetches u-boot from there, copies to RAM and starts it. Note that u-boot environment variables stay on the flash all the time.
As a matter of fact, such scheme is widely used for Xilinx FPGA embedded cores (both Microblaze and PPC) as well as for ARM CPUs. It's not approved by many experts and I don't wish to start discussion here whether such approach is the best in certain circumstances, but it definitely makes a lot of sense.
Thanks,
Leonid.
Leonid wrote:
As a matter of fact, such scheme is widely used for Xilinx FPGA embedded cores (both Microblaze and PPC) as well as for ARM CPUs.
Can you give me some details as to how this works? I'm trying to figure out if this approach is meaningful for boards based on Freescale 8xxx CPUs. I'm guessing it's not, and that the code I see in the board header files is some left-over legacy from a completely different CPU that no one ever bothered to think about.
On Wednesday, May 16, 2007 4:11 PM Timur Tabi wrote:
Leonid wrote:
As a matter of fact, such scheme is widely used for Xilinx FPGA
embedded
cores (both Microblaze and PPC) as well as for ARM CPUs.
Can you give me some details as to how this works?
I am not sure what you are asking about. If the question is what RAM booting scheme looks like - I think we've been through that already. U-boot image is compiled to run from some place in RAM (TEXT_BASE in config.mk makes sure of that), yet it's environment and binary shall be on the flash. First stage bootloader fetches u-boot from there, copies it to RAM and starts.
Such a scheme proves to be useful when for some reason you should have a small code, taking control over your CPU right after reset and u-boot is too big to do the job. This is the case of CPU core running in FPGA or ARM CPU. Yet I don't claim this is the only way to go in such cases - the Emperor August used to say that there are many ways of skinning a cat to which Sir Kipling added that there are 78 methods of composing songs of tribes and all of them are correct.
Such 2 stage booting may be useless for Freescale - I don't have much experience with it - it's certainly not needed for AMCC PPC CPUs.
If you ask regarding specific configuration flags, all those ...RAMBOOT - I'm not sure how to use them and suspect that in many practical cases they are simply ignored. Look for example .h and config.mk file for ATMEL reference board which is using 2-stage booting scheme (tiny boot.bin is expected to be located in the beginning of flash, address 0x10000000).
Regards,
Leonid.
On Wed, 2007-05-16 at 18:11, Timur Tabi wrote:
Can you give me some details as to how this works? I'm trying to figure out if this approach is meaningful for boards based on Freescale 8xxx CPUs. I'm guessing it's not, and that the code I see in the board header files is some left-over legacy from a completely different CPU that no one ever bothered to think about.
Timur,
There are test-bed environments, for example, that are capable of setting up some LAWs, configuring DDR, and injecting a new test image into RAM via a JTAG or scan device. From there it is an obvious "boot from RAM" situation useful for rapid turn testing.
jdl
In message 406A31B117F2734987636D6CCC93EE3C017BA2D5@ehost011-3.exch011.intermedia.net you wrote:
RAM and starts it. Note that u-boot environment variables stay on the flash all the time.
No, that's not correct. They get relocated to RAM like all other U-Boot code and data.
Not to mentions boards where the environment resides in EEPROM or similar ;-)
cores (both Microblaze and PPC) as well as for ARM CPUs. It's not approved by many experts and I don't wish to start discussion here whether such approach is the best in certain circumstances, but it definitely makes a lot of sense.
It certainly does.
Actually the situation is very simple: if you know how to do it, just use it - you will then also know when it does not make sense. If you have to ask questions to get booting from RAM goind, then keep your fingers off, as you don;t have the qualification to use it.
Best regards,
Wolfgang Denk
On Wednesday, May 16, 2007 5:12 PM Wolfgang Denk wrote:
In message <406A31B117F2734987636D6CCC93EE3C017BA2D5@ehost011- 3.exch011.intermedia.net> you wrote:
RAM and starts it. Note that u-boot environment variables stay on
the
flash all the time.
No, that's not correct. They get relocated to RAM like all other U-Boot code and data.
Well, I cannot answer for all possible boards, but on 3 boards I have here (Spartan FPGA Microblaze core, Virtex FPGA PPC405 core, at91rm9200-ek ATMEL board) u-boot is configured to be compiled to run from RAM, gets loaded to RAM by another bootloader and runs there, yet u-boot looks for environment on the flash and "saveenv" saves environment onto flash. May be it's not a "canonical" way of running from RAM, but it's convenient for me.
Actually the situation is very simple: if you know how to do it, just use it - you will then also know when it does not make sense. If you have to ask questions to get booting from RAM goind, then keep your fingers off, as you don;t have the qualification to use it.
I cannot agree more.
Best regards,
Leonid.
In message 406A31B117F2734987636D6CCC93EE3C017BA2FB@ehost011-3.exch011.intermedia.net you wrote:
Well, I cannot answer for all possible boards, but on 3 boards I have here (Spartan FPGA Microblaze core, Virtex FPGA PPC405 core, at91rm9200-ek ATMEL board) u-boot is configured to be compiled to run from RAM, gets loaded to RAM by another bootloader and runs there, yet u-boot looks for environment on the flash and "saveenv" saves environment onto flash. May be it's not a "canonical" way of running from RAM, but it's convenient for me.
The environment gets loaded into RAM from some persistent storage (often flash) into RAM when U-Boot initializes; then alloperations (setenv, references) are running on the in-RAM copy, and you can explicitely save the current settings to persistent storage using the "saveenv" command.
Is this difficult to understand?
Best regards,
Wolfgang Denk
Yes, I have read it, but it doesn't really answer my question. I'm not asking if I can boot from RAM, I'm asking why would someone think it could be done? If anything, 14.2.1 re-inforces my point: if booting from RAM doesn't make sense, why are so many board header files configured to enable it?
Ok, I don't want to be flamed here ... but I can think of a potential method of booting to RAM ... but whether or not it is considered useful in the context of U-Boot is debatable.
The MPC8349E can be booted such that the core is held in reset, and the processor registers can be configured over PCI by another host computer. Therefore it is conceivable that the host can program the SDRAM controller on the MPC8349E and take the core out of reset. If the core is configured to boot from an address mapped to SDRAM, then U-Boot could have been copied to SDRAM by the host. Once U-Boot boots, it could then use FTP etc to boot the kernel blah blah ...
Yeah yeah, its contrived ...
Of course if the host is configuring all the registers, then there is probably no reason for the bootloader ... just boot to Linux directly from SDRAM.
Dave
David Hawkins wrote:
The MPC8349E can be booted such that the core is held in reset, and the processor registers can be configured over PCI by another host computer. Therefore it is conceivable that the host can program the SDRAM controller on the MPC8349E and take the core out of reset. If the core is configured to boot from an address mapped to SDRAM, then U-Boot could have been copied to SDRAM by the host. Once U-Boot boots, it could then use FTP etc to boot the kernel blah blah ...
Ok fine, but you're talking about an 8349 on a different board. I have a *board* header file for the MPC8349E-mITX, which comes with 16MB of flash and works just fine. I've done the hard work of getting U-Boot running on that board with flash. So the question is, am I going to upset someone if I remove support for booting from RAM on that board?
Hi Timur,
The MPC8349E can be booted such that the core is held in reset, and the processor registers can be configured over PCI by another host computer. Therefore it is conceivable that the host can program the SDRAM controller on the MPC8349E and take the core out of reset. If the core is configured to boot from an address mapped to SDRAM, then U-Boot could have been copied to SDRAM by the host. Once U-Boot boots, it could then use FTP etc to boot the kernel blah blah ...
Ok fine, but you're talking about an 8349 on a different board. I have a *board* header file for the MPC8349E-mITX, which comes with 16MB of flash and works just fine. I've done the hard work of getting U-Boot running on that board with flash. So the question is, am I going to upset someone if I remove support for booting from RAM on that board?
In that instance, since its a board you are personally supporting, I think its your choice, so go ahead and remove it. If someone decides that they want to add RAM boot support, then they can supply the patch. If someone asks how to do it, then point them to the MPC8349E-MDS-PB source (where I assume it exists). If they get it to work on the -mITX, then they can submit a patch along with a clear explanation of why they thought it was necessary to support it.
Of course the fact that this code sounds like its being copied from BSP to BSP, when its quite possibly general code, is not that desirable. So deleting it from this BSP will hopefully discourage that practice.
Cheers, Dave
In message 464C6CFC.7020602@freescale.com you wrote:
Ok fine, but you're talking about an 8349 on a different board. I have a *board* header file for the MPC8349E-mITX, which comes with 16MB of flash and works just fine. I've done the hard work of getting U-Boot running on that board with flash. So the question is, am I going to upset someone if I remove support for booting from RAM on that board?
If you are the board maintainer? No.
Best regards,
Wolfgang Denk
Hi,
yes, it's an old thread -- just for the record:
David Hawkins wrote:
The MPC8349E can be booted such that the core is held in reset, and the processor registers can be configured over PCI by another host computer. Therefore it is conceivable that the host can program the SDRAM controller on the MPC8349E and take the core out of reset. If the core is configured to boot from an address mapped to SDRAM, then U-Boot could have been copied to SDRAM by the host. Once U-Boot boots, it could then use FTP etc to boot the kernel blah blah ...
Yeah yeah, its contrived ...
Not really, we almost do it in that way on a custom MPC8540 and a MPC8541 board. Basic hardware settings are done using Boot Sequencer EEPROM. Settings can be concluded with settings written over PCI by host (PCSRBAR on BAR0). U-Boot and Linux are directly written over PCI into RAM. The boards itself didn't got flash memory at all. U-Boot environment is contained in I2C-EEPROM as well (can be concluded with a specially crafted environment found in RAM -- which is another hack though).
Of course if the host is configuring all the registers, then there is probably no reason for the bootloader ... just boot to Linux directly from SDRAM.
No, we don't want to get rid of this nice U-Boot... :)
Cheers,
Florian
In message fa1cio$vqv$1@sea.gmane.org you wrote:
yes, it's an old thread -- just for the record:
David Hawkins wrote:
The MPC8349E can be booted such that the core is held in reset, and the processor registers can be configured over PCI by another host computer. Therefore it is conceivable that the host can program the SDRAM controller on the MPC8349E and take the core out of reset. If the core is configured to boot from an address mapped to SDRAM, then U-Boot could have been copied to SDRAM by the host. Once U-Boot boots, it could then use FTP etc to boot the kernel blah blah ...
Yeah yeah, its contrived ...
Not really, we almost do it in that way on a custom MPC8540 and a MPC8541 board.
There are several boards that do this.
IIRC the "PN62" was the first one to implement this feature. There U-Boot is running on a flash-less PCI card, too.
Best regards,
Wolfgang Denk
In message 464B818F.60509@freescale.com you wrote:
Yes, I have read it, but it doesn't really answer my question. I'm not asking if I can boot from RAM, I'm asking why would someone think it could be done? If anything, 14.2.1
It can be done. And in some situations it may even be the fastest way to get a running system. But you have to understand *exactly* what you are doing.
re-inforces my point: if booting from RAM doesn't make sense, why are so many board header files configured to enable it?
I cannot answer this.
Best regards,
Wolfgang Denk
participants (6)
-
David Hawkins -
Florian Boelstler -
Jon Loeliger -
Leonid -
Timur Tabi -
Wolfgang Denk