"ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

"ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Paul Walmsley]

Hello Geert,

Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: 
multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 
multi_v7_defconfig boot.  

Boot log before:

http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt

Boot log after:

http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt


Any ideas?  Stephen Warren thinks there might be an initcall that might 
not check to see what kind of device it's running on.


- Paul

commit 4a3a6f86693922b29cf829c63f652b057f14619e
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Feb 24 15:14:45 2015 +0100

    ARM: multi_v7_defconfig: Enable shmobile platforms
    
    Enable support for shmobile platforms that became multi-platform aware.
    Several non-critical drivers and subsystems are built as modules, to keep
    kernel size reasonable.
    
    Tested on:
      - r8a73a4/ape6evm:
          - U-Boot fails with "Error: unrecognized/unsupported machine ID",
          - kexec works.
      - r8a7740/armadillo:
          - Hermit boot loader fails (larger image, more memory corruption),
          - kexec works.
      - r8a7791/koelsch,
      - sh73a0/kzm9g:
          - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n,
          - kexec works.
      - am335x/boneblack.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Tyler Baker]

Hi Paul,

On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
>
> Hello Geert,
>
> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
> multi_v7_defconfig boot.
>
> Boot log before:
>
> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>
> Boot log after:
>
> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>
>
> Any ideas?  Stephen Warren thinks there might be an initcall that might
> not check to see what kind of device it's running on.

Can you try to shift your kernel load address around a bit? From
experience with the boards from kernelci.org we find that as the multi
v7 kernel size increases they can clobber memory when they get
decompressed.

>
>
> - Paul
>
> commit 4a3a6f86693922b29cf829c63f652b057f14619e
> Author: Geert Uytterhoeven <geert+renesas@glider.be>
> Date:   Tue Feb 24 15:14:45 2015 +0100
>
>     ARM: multi_v7_defconfig: Enable shmobile platforms
>
>     Enable support for shmobile platforms that became multi-platform aware.
>     Several non-critical drivers and subsystems are built as modules, to keep
>     kernel size reasonable.
>
>     Tested on:
>       - r8a73a4/ape6evm:
>           - U-Boot fails with "Error: unrecognized/unsupported machine ID",
>           - kexec works.
>       - r8a7740/armadillo:
>           - Hermit boot loader fails (larger image, more memory corruption),
>           - kexec works.
>       - r8a7791/koelsch,
>       - sh73a0/kzm9g:
>           - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n,
>           - kexec works.
>       - am335x/boneblack.
>
>     Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>     Acked-by: Simon Horman <horms+renesas@verge.net.au>
>     Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Cheers,

Tyler

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Geert Uytterhoeven]

Hi Paul, Tyler,

On Wed, Mar 25, 2015 at 7:28 PM, Tyler Baker <tyler.baker@linaro.org> wrote:
> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
>> multi_v7_defconfig boot.
>>
>> Boot log before:
>>
>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>>
>> Boot log after:
>>
>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt

So it just hangs when booting the kernel. Do you have any early debugging
support (earlycon, DEBUG_LL) for your kernel?

>> Any ideas?  Stephen Warren thinks there might be an initcall that might
>> not check to see what kind of device it's running on.

Always possible of course, but it didn't trigger on my boneblack.

> Can you try to shift your kernel load address around a bit? From
> experience with the boards from kernelci.org we find that as the multi
> v7 kernel size increases they can clobber memory when they get
> decompressed.

Kernel size can indeed be an issue. I believe the failure to boot on ape6evm
from U-Boot mentioned in the commit is caused by that, too.
Note that the error message only shows up with DEBUG_LL enabled (and
some manual editing of Kconfig.debug to make that work).

I'll try changing the kernel load address on ape6evm, too.

>> commit 4a3a6f86693922b29cf829c63f652b057f14619e
>> Author: Geert Uytterhoeven <geert+renesas@glider.be>
>> Date:   Tue Feb 24 15:14:45 2015 +0100
>>
>>     ARM: multi_v7_defconfig: Enable shmobile platforms
>>
>>     Enable support for shmobile platforms that became multi-platform aware.
>>     Several non-critical drivers and subsystems are built as modules, to keep
>>     kernel size reasonable.
>>
>>     Tested on:
>>       - r8a73a4/ape6evm:
>>           - U-Boot fails with "Error: unrecognized/unsupported machine ID",
>>           - kexec works.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Paul Walmsley]

Hi Tyler

On Wed, 25 Mar 2015, Tyler Baker wrote:

> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
>
> > Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
> > multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
> > multi_v7_defconfig boot.
> >
> > Boot log before:
> >
> > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
> >
> > Boot log after:
> >
> > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
> >
> >
> > Any ideas?  Stephen Warren thinks there might be an initcall that might
> > not check to see what kind of device it's running on.
> 
> Can you try to shift your kernel load address around a bit? From
> experience with the boards from kernelci.org we find that as the multi
> v7 kernel size increases they can clobber memory when they get
> decompressed.

Thanks, that was it:

http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt

Should have guessed when absolutely no debug output was emitted by the 
board...

Sorry for the false alarm, Geert!


- Paul

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Stephen Warren]

On 03/25/2015 04:00 PM, Paul Walmsley wrote:
> Hi Tyler
> 
> On Wed, 25 Mar 2015, Tyler Baker wrote:
> 
>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
>>
>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
>>> multi_v7_defconfig boot.
>>>
>>> Boot log before:
>>>
>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>>>
>>> Boot log after:
>>>
>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>>>
>>>
>>> Any ideas?  Stephen Warren thinks there might be an initcall that might
>>> not check to see what kind of device it's running on.
>>
>> Can you try to shift your kernel load address around a bit? From
>> experience with the boards from kernelci.org we find that as the multi
>> v7 kernel size increases they can clobber memory when they get
>> decompressed.
> 
> Thanks, that was it:
> 
> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
> 
> Should have guessed when absolutely no debug output was emitted by the 
> board...
> 
> Sorry for the false alarm, Geert!

Interesting. Do the values in U-Boot's default environment work
correctly ("env default -f -a" will reset the environment to default, in
case some old values are saved in flash); I put some effort into picking
them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r},
${ramdisk_addr_r}.

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Paul Walmsley]

On Wed, 25 Mar 2015, Stephen Warren wrote:

> On 03/25/2015 04:00 PM, Paul Walmsley wrote:
> > On Wed, 25 Mar 2015, Tyler Baker wrote:
> >> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
> >>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
> >>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
> >>> multi_v7_defconfig boot.
> >>>
> >>> Boot log before:
> >>>
> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
> >>>
> >>> Boot log after:
> >>>
> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
> >>>
> >>>
> >>> Any ideas?  Stephen Warren thinks there might be an initcall that might
> >>> not check to see what kind of device it's running on.
> >>
> >> Can you try to shift your kernel load address around a bit? From
> >> experience with the boards from kernelci.org we find that as the multi
> >> v7 kernel size increases they can clobber memory when they get
> >> decompressed.
> > 
> > Thanks, that was it:
> > 
> > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
> > 
> > Should have guessed when absolutely no debug output was emitted by the 
> > board...
> > 
> > Sorry for the false alarm, Geert!
> 
> Interesting. Do the values in U-Boot's default environment work
> correctly

No idea, I haven't tried.  (The load addresses I used are observable in 
the boot logs above.)

> ("env default -f -a" will reset the environment to default, in
> case some old values are saved in flash); I put some effort into picking
> them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r},
> ${ramdisk_addr_r}.

According to the tegra20-common.h file in the u-boot source here, 
kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000.  If one assumes 
the problem is that the kernel decompressor is overwriting the DTB, then 
I suspect they wouldn't work either, since the gap between the addresses 
is the same as what I used (0x01000000).


- Paul

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Stephen Warren]

On 03/26/2015 12:35 PM, Paul Walmsley wrote:
> On Wed, 25 Mar 2015, Stephen Warren wrote:
>
>> On 03/25/2015 04:00 PM, Paul Walmsley wrote:
>>> On Wed, 25 Mar 2015, Tyler Baker wrote:
>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
>>>>> multi_v7_defconfig boot.
>>>>>
>>>>> Boot log before:
>>>>>
>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>>>>>
>>>>> Boot log after:
>>>>>
>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>>>>>
>>>>>
>>>>> Any ideas?  Stephen Warren thinks there might be an initcall that might
>>>>> not check to see what kind of device it's running on.
>>>>
>>>> Can you try to shift your kernel load address around a bit? From
>>>> experience with the boards from kernelci.org we find that as the multi
>>>> v7 kernel size increases they can clobber memory when they get
>>>> decompressed.
>>>
>>> Thanks, that was it:
>>>
>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
>>>
>>> Should have guessed when absolutely no debug output was emitted by the
>>> board...
>>>
>>> Sorry for the false alarm, Geert!
>>
>> Interesting. Do the values in U-Boot's default environment work
>> correctly
>
> No idea, I haven't tried.  (The load addresses I used are observable in
> the boot logs above.)

Sure. I was hoping you'd try it out since you already had the setup to 
repro the issue.

It'd be good if your test-bed used the built-in U-Boot variables too, so 
we're testing them.

>> ("env default -f -a" will reset the environment to default, in
>> case some old values are saved in flash); I put some effort into picking
>> them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r},
>> ${ramdisk_addr_r}.
>
> According to the tegra20-common.h file in the u-boot source here,
> kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000.  If one assumes
> the problem is that the kernel decompressor is overwriting the DTB, then
> I suspect they wouldn't work either, since the gap between the addresses
> is the same as what I used (0x01000000).

I expect the issue is more how close the uncompressed kernel and/or DTB 
are to the start of RAM (where the decompressor writes to). IIRC, if the 
decompressor is going to overwrite the compressed kernel during 
decompression, it moves itself first. I can't remember where the 
destination of the move is, but perhaps the relocation can over-write 
the DTB. By pushing the location of the compressed kernel away from the 
start of RAM, this relocation won't happen. IIRC when the decompression 
happens, or relocation prior to decompression, there's no protection of 
the DTB being overwritten.

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Stephen Warren]

On 03/26/2015 12:57 PM, Stephen Warren wrote:
> On 03/26/2015 12:35 PM, Paul Walmsley wrote:
>> On Wed, 25 Mar 2015, Stephen Warren wrote:
>>
>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote:
>>>> On Wed, 25 Mar 2015, Tyler Baker wrote:
>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
>>>>>> multi_v7_defconfig boot.
...
>>>>> Can you try to shift your kernel load address around a bit? From
>>>>> experience with the boards from kernelci.org we find that as the multi
>>>>> v7 kernel size increases they can clobber memory when they get
>>>>> decompressed.
>>>>
>>>> Thanks, that was it:
>>>>
>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
...
>>> Interesting. Do the values in U-Boot's default environment work
>>> correctly
>>
>> No idea, I haven't tried.  (The load addresses I used are observable in
>> the boot logs above.)
>
> Sure. I was hoping you'd try it out since you already had the setup to
> repro the issue.
>
> It'd be good if your test-bed used the built-in U-Boot variables too, so
> we're testing them.

I've reproduced the original problem, and then validated that using the 
addresses from U-Boot's default environment (at least with a ToT U-Boot 
that I just built) does indeed solve it.

I'd like to re-iterate that the test bed should be using the values from 
U-Boot's environment rather than making up its own. That way:

* The value the test bed uses for the kernel load address likely 
overlaps where the kernel decompressor writes to for even slightly large 
kernels. This means the decompressor must move itself before 
decompressing. IIUC, there's zero guarantee that moving the decompressor 
won't overwrite the DTB, since IIUC the decompressor uses zero knowledge 
of the DTB location. In other words, if the compressed kernel is loaded 
somewhere that's likely to require it to move itself, there's a real 
risk of the exact same problem cropping up again in the future if the 
kernel happens to overwrite the DTB during relocation.

* The values are part of every Tegra U-Boot port (and hopefully for 
other SoCs too given any distro using boot.scr with 
config_distro_bootcmd.h will expect the variables to exist), so for 
future (Tegra) chips you won't have to adjust the test bed if RAM layout 
changes.

* Those values get testing, so we'll find out if the ever don't work. We 
get more test coverage.

Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot

[Paul Walmsley]

On 04/01/2015 11:14 AM, Stephen Warren wrote:
> On 03/26/2015 12:57 PM, Stephen Warren wrote:
>> On 03/26/2015 12:35 PM, Paul Walmsley wrote:
>>> On Wed, 25 Mar 2015, Stephen Warren wrote:
>>>
>>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote:
>>>>> On Wed, 25 Mar 2015, Tyler Baker wrote:
>>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote:
>>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
>>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
>>>>>>> multi_v7_defconfig boot.
> ...
>>>>>> Can you try to shift your kernel load address around a bit? From
>>>>>> experience with the boards from kernelci.org we find that as the 
>>>>>> multi
>>>>>> v7 kernel size increases they can clobber memory when they get
>>>>>> decompressed.
>>>>>
>>>>> Thanks, that was it:
>>>>>
>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt 
>>>>>
> ...
>>>> Interesting. Do the values in U-Boot's default environment work
>>>> correctly
>>>
>>> No idea, I haven't tried.  (The load addresses I used are observable in
>>> the boot logs above.)
>>
>> Sure. I was hoping you'd try it out since you already had the setup to
>> repro the issue.
>>
>> It'd be good if your test-bed used the built-in U-Boot variables too, so
>> we're testing them.
>
> I've reproduced the original problem, and then validated that using 
> the addresses from U-Boot's default environment (at least with a ToT 
> U-Boot that I just built) does indeed solve it.
>
> I'd like to re-iterate that the test bed should be using the values 
> from U-Boot's environment rather than making up its own. That way:
>
> * The value the test bed uses for the kernel load address likely 
> overlaps where the kernel decompressor writes to for even slightly 
> large kernels. This means the decompressor must move itself before 
> decompressing. IIUC, there's zero guarantee that moving the 
> decompressor won't overwrite the DTB, since IIUC the decompressor uses 
> zero knowledge of the DTB location. In other words, if the compressed 
> kernel is loaded somewhere that's likely to require it to move itself, 
> there's a real risk of the exact same problem cropping up again in the 
> future if the kernel happens to overwrite the DTB during relocation.
>
> * The values are part of every Tegra U-Boot port (and hopefully for 
> other SoCs too given any distro using boot.scr with 
> config_distro_bootcmd.h will expect the variables to exist), so for 
> future (Tegra) chips you won't have to adjust the test bed if RAM 
> layout changes.
>
> * Those values get testing, so we'll find out if the ever don't work. 
> We get more test coverage.

Sounds reasonable, I'll try to get to this at some point soon.

BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the 
value you define for kernel_addr_r.  That would reinforce to folks who 
aren't using the U-boot scripts that they should use that address for 
loading their kernel.


- Paul


- Paul