Hi, Wolfgang & Wolfgang:
The question of running u-boot from RAM has been discussed several times
in this forum and I agree with Wolfgang Denk that for "classical" ppc
CPUs (like mine ppc440epx) there almost no need to resort to such
tricks.
However my case - initial programming of NAND flash using BDI2000 while
NOR flash is not present - gives some justification to such
configuration. Certainly u-boot is overkill for such a task, but if it
can be used instead of creating special application - why not? BDI is
widely accepted, rather chip tool and other tools either too expensive
(Corellus) or don't support ppc4xx.
I have succeed in creating such a configuration for AMCC ppc4440epx
Sequoia board (Sequoia itself features NOR flash additionally to NAND,
but my board, based on it, doesn't). I provide my method below - it may
be useful for some members of this community as NAND flashes become more
popular. It's certainly better to have such feature supported by
standard u-boot if possible...
1. Set TEXT_BASE to some RAM address (I used 0x1000000) in
board/amcc/sequoia/config.mk file.
2. Disable memory initialization. Practically, initdram() function
mustn't be called OR it must do nothing, just return memory size (256MB
for Sequoia).
Wolfgang Denk suggested that much in his e-mail:
> All you need to do is to create a configuration which
> (1) has a modified TEXT_BASE and
> (2) skips the memory initialization.
Something more is required however:
3. After analyzing init.S file, I found it necessary to add two
following TLB entries to BDI config file (sequoia.cfg):
WTLB 0xD000000D 0x1D00003F ;NAND flash 1K
WTLB 0xEEC00005 0x1EEC003F ;PCI Registers 1K
The first one is essential; second can be avoided if you exclude PCI
from u-boot configuration, but I didn't bother.
3. I have replaced board/amcc/sequoia/u-boot.lds by
board/xilinx/ml403/u-boot.lds which doesn't set reset vector to
0xfffffffc.
With these changes image is ready to go on Sequoia even if both NOR and
NAND flashes are wiped clean. But since we considering to run it on the
board where NOR flash is not present at all, we should exclude all
accesses to NOR flash.
4. I have added CFG_NO_FLASH to sequoia.h and also disabled the
following command flags:
(CFG_CMD_FLASH | CFG_CMD_IMLS | CFG_CMD_FAT).
5. File board/amcc/sequoia.c had to be modified little bit since it
tries to access NOR flash unconditionally.
Now u-boot RAM image boots on Sequoia. First one must load it via BDI to
the RAM of course:
440EPx>load 0x1000000 sequoia/uboot/u-boot-ram.bin
Loading sequoia/uboot/u-boot-ram.bin , please wait ....
Loading program file passed
440EPx>rm pc 0x1000100
440EPx>go
CPU: AMCC PowerPC 440EPx Rev. A at 333.333 MHz (PLB=133, OPB=66,
EBC=66 MHz)
Security/Kasumi support
I2C boot EEPROM disabled
Bootstrap Option B - Boot ROM Location EBC (16 bits)
Internal PCI arbiter disabled, PCI async ext clock used
32 kB I-Cache 32 kB D-Cache
Board: Sequoia - AMCC PPC440EPx Evaluation Board
I2C: ready
DTT: 1 FAILED INIT
DRAM: 256 MB
Top of RAM usable for U-Boot at: 10000000 Reserving 392k for U-Boot at:
0ff9d000 Reserving 256k for malloc() at: 0ff5d000 Reserving 144 Bytes
for Board Info at: 0ff5cf70 Reserving 48 Bytes for Global Data at:
0ff5cf40 Stack Pointer at: 0ff5cf28 New Stack Pointer is: 0ff5cf28 Now
running in RAM - U-Boot at: 0ff9d000
NAND: 32 MiB
*** Warning - bad CRC, using default environment
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
USB: Host(int phy) Device(ext phy)
U-Boot relocated to 0ff9d000
Net: No ethernet found.
Type run flash_nfs to mount root filesystem over NFS
U-Boot$
It's is not a problem it doesn't have Ethernet. It can be added easily,
but probably this is not necessary - image for burning can be loaded to
RAM via the very same BDI.
Thanks,
Leonid.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Wolfgang Denk
Sent: Sunday, March 09, 2008 7:42 AM
To: [EMAIL PROTECTED]
Cc: u-boot-users@lists.sourceforge.net
Subject: Re: [U-Boot-Users] NAND flash programming via BDI2000 for
ppc440epx.
In message <[EMAIL PROTECTED]> you wrote:
>
> > You can as well use the BDI2000 to program the standard U-Boot image
> > to NOR flash, boot from NOR and then use U-Boot...
>
> the problem is that this is not suitable for production use.
OK. Then you gotta spend some effort...
> It would be a very elegant solution to have U-Boot run from RAM with
> an environment in RAM to tell it what and where to flash... You could
> set up the environment while loading the data and would have a
flexible
> flashing tool.
To set up the environment you normally just load and run a script.
> The only thing missing for this is a working CONFIG_MONITOR_IS_IN_RAM
> as far as I can see.
Actually this is not missing. All you need to do is to create a
configuration which (1) has a modfied TEXT_BASE and (2) skips the
memory initialization. But see
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeSta
rtedInRAM
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: [EMAIL PROTECTED]
"At least they're __________EXPERIENCED incompetents"
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
