Hi, Alec,
On Oct 25, 2012, at 5:29 PM , Alec Rust wrote:
> Correction: To get the new macros to load one must also erase another section
> of flash. This can be done in one step so please replace the instruction in
> 4b with: "setenv writeuboot protect off 0xfff40000 0xffffffff\; era
> 0xfff40000 0xffffffff\; cp.b 0x4000000 0xfff80000 \$\{filesize\}"
>
> On Thu, Oct 25, 2012 at 4:55 PM, Alec Rust <[email protected]> wrote:
>> 4. NB! Do not skip this step: The u-boot macro to reprogram u-boot is
>> incorrect, you must define a new one (once the new u-boot is flashed the
>> macro will be correct). Using the current macro bricks the board (can be
>> recovered by reprogram u-boot via setting up a test machine and sending a
>> xmodem receiver to the PPC via JTAG and then sending the binary)
>> a) Boot into u-boot (reset the board and press any key to stop autoboot)
>> b) type: "setenv writeuboot protect off 0xfff80000 0xffffffff\; era
>> 0xfff80000 0xffffffff\; cp.b 0x4000000 0xfff80000 \$\{filesize\}" at the
>> u-boot prompt without the quotes. Note this is the same as the current macro
>> but the current cp.b 0x400000 is missing a 0! Leave the protect on bit, the
>> U-boot command line is too short to add it and the macro will be overwritten
>> anyway when the new u-boot loads.
I notice that the writeuboot macro in the new u-boot environment has the
correct address for the cp.b command, but it has the "old" (4:55 PM) "protect
off 0xfff80000 0xffffffff" range (and protect on, too) rather than the "new"
(5:29 PM) "protect off 0xfff40000 0xffffffff" range. Will I have to change it
to use the "new" range when I next program another u-boot image?
BTW, the "flinfo" command surprisingly shows that the sectors 0xfff40000
through 0xffffffff are protected even though I never explicitly protected them.
Weird, but I'm not complaining.
Thanks,
Dave
