[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Timur Tabi]

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Timur Tabi]

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?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Leonid]

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.

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Timur Tabi]

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.


-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Leonid]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.mk
Type: application/octet-stream
Size: 23 bytes
Desc: config.mk
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070516/2b46080f/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: at91rm9200dk.h
Type: application/octet-stream
Size: 8800 bytes
Desc: at91rm9200dk.h
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070516/2b46080f/attachment-0001.obj 

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Jon Loeliger]

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

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is wanted is not the will to believe,  but the will to find out,
which is the exact opposite.
		        -- Bertrand Russell, "Skeptical Essays", 1928

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Leonid]

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.

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Morality is one thing.  Ratings are everything."
- A Network 23 executive on "Max Headroom"

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[David Hawkins]

> 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

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Timur Tabi]

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?


-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[David Hawkins]

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

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our business is run on trust.  We trust you will pay in advance.

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Florian Boelstler]

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

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson

[U-Boot-Users] CFG_MONITOR_BASE < CFG_FLASH_BASE

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Documentation is like sex: when it is good, it is  very,  very  good;
and when it is bad, it is better than nothing.         - Dick Brandon