[U-Boot-Users] Use reset CMD to start another u-boot failed.

[Detlev Zundel]

Hi Leon,

You could help us a little answer your questions by giving some more
details - pretty obvious things like architecture or board name come to
mind...

> The original u-boot running on board was burn AT 0xFFF00000,
> (Flash is mapped to 0xFE000000-0xFFFFFFFF)
> The CFG_RESET_ADDRESS = 0xFE000000

What was the original U-Boot?  Was that a configuration in mainline?

Why on earth are you trying to tamper with CFG_RESET_ADDRESS?  This
should really not be changed as it is only used to do force a reset of a
board *for certain architectures*.  I am not even sure that
CFG_RESET_ADDRESS is relevant for your board.  Moreover if you read the
source code, this address is usually a *nonexistant* address to force a
machine check exception.  It is definitely not a hook to start a
different incarnation of U-Boot.

> The original and new u-boot file difference is only two place.
> 1. CONFIG_AUTOBOOT_PROMPT (use it to verify the new u-boot startup correctly)
> 2. board/myboard/config.mk->TEXT_BASE = 0xFE000000
> Then I place the new u-boot.bin file to the 0xFE000000,
> and then run the "reset" cmd from original u-boot's prompt.
>
> but it's seem the new u-boot was not startup.
> the console still print the original u-boot's CONFIG_AUTOBOOT_PROMPT.
>
> Am I miss some step? Or some where need to pay attention to?

The short answer is - only change what you need in your configuration
and replace the "original u-boot".  I have no idea why changing
CONFIG_AUTOBOOT_PROMPT needs a separate U-Boot at all.

> The original u-boot flinfo.
> Original u-boot.bin was place to the FFF00000-FFF3FFFF(2 sector)
> CFG_ENV_ADDR = FFF40000(1 sector),CFG_RESET_ADDRESS = 0xFE000000
>
>
> cilon=> flinfo
>
> Bank # 1: Intel 28F128J3A (16 Mbit, 128 x 128K)
>   Size: 16 MB in 128 Sectors
>   Sector Start Addresses:
>     FE000000      FE020000      FE040000      FE060000      FE080000     

[....]

Without any details about your board, this information is pretty useless
to us.

Cheers
  Detlev

-- 
In short: much of our country's [USA] counterterrorism security spending is
not designed to protect us from the terrorists,  but instead to protect our
public officials from criticism when another attack occurs.
                                   -- Bruce Schneier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de