Re: [PATCH 01/38] ARM: ux500: Remove PrimeCell IDs from Nomadik I2CDT nodes

From: Olof Johansson
Date: Wed Sep 11 2013 - 16:36:50 EST


On Wed, Sep 11, 2013 at 4:13 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> On Wed, Sep 11, 2013 at 11:39 AM, Lee Jones <lee.jones@xxxxxxxxxx> wrote:
>> On 11 Sep 2013 10:33, "Linus Walleij" <linus.walleij@xxxxxxxxxx> wrote:
>
>>> No it was something transient, after a clean rebuild it boots
>>> just fine. :-/
>>>
>>> I'll see if I can boot the same uImage on the Snowball too.
>
> Yeah Snowball boots the same DT image with just some random
> dmesg noise from Torvalds HEAD:
>
> U8500 $ mmc rescan 1 ; fat load mmc 1 0x0 /uImage ; bootm 0x0
> Partition info retrieved
> Reading /uImage
>
> 8997342 bytes read
> ## Booting kernel from Legacy Image at 00000000 ...
> Image Name: Ux500 Device Tree kernel
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 8997278 Bytes = 8.6 MB
> Load Address: 00008000
> Entry Point: 00008000
> Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x300
> Linux version 3.11.0-09031-ga22a0fd (linus@xxxxxxxxxxxxxxxxxxxxx) (gcc
> version 4.8.2 20130805 (prerelease) (crosstool-NG
> linaro-1.13.1-4.8-2013.08 - Linaro GCC 2013.08) ) #48 SMP PREEMPT Wed
> Sep 11 11:14:36 CEST 2013
> CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine: ST-Ericsson Ux5x0 platform (Device Tree Support), model:
> ST-Ericsson HREF (v60+) platform with Device Tree
> Only cachepolicy=writeback supported on ARMv6 and later
> Memory policy: ECC disabled, Data cache writealloc
> DB8500 v2.1 [0x008500b1]
> (...)
>
> I don't know what is the problem with Olof's machine :-/

Oh! Well, to start with apparantly u8500_defconfig doesn't have
APPENDED_DTB enabled, which explains some of the confusion here.

With that fixed (and the appropriate options to get the bootargs from
the atags), I get as far as console probing where output stops, if I
have DEBUG_LL on. With it disabled I get all the way up.

Not sure what was going on earlier here. Maybe just as in your case it
was a matter of cleaning out and starting fresh.

multi_v7_defconfig still doesn't boot though, but the failure seems to
be lower level than any of the others, no output with DEBUG_LL on.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/