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

[swarren@wwwdotorg.org (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.