[PATCH 1/2] ARM: ux500: add an SMP enablement type and move cpu nodes
khilman at kernel.org
Thu Oct 22 15:17:58 PDT 2015
On Thu, Oct 22, 2015 at 3:13 PM, Kevin Hilman <khilman at kernel.org> wrote:
> On Thu, Oct 22, 2015 at 5:24 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Tue, Oct 20, 2015 at 6:52 AM, Kevin Hilman <khilman at kernel.org> wrote:
>>> On Mon, Aug 3, 2015 at 12:26 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
>>>> The "cpus" node cannot be inside the "soc" node, while this
>>>> works for the CoreSight blocks, the early boot code will look
>>>> for "cpus" directly under the root node, so this is a hard
>>>> convention. So move the CPU nodes.
>>>> Augment the "reg" property to match what is actually in the
>>>> hardware: 0x300 and 0x301 respectively.
>>>> Then add an SMP enablement type to be used by the SMP init
>>>> code, "ste,dbx500-smp".
>>>> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>>>> Hi ARM SoC people: please apply this as a fix for v4.2
>>>> as it is prerequisite for 2/2 which is a more proper fix
>>>> for the secondary CPU boot regression addressed by the
>>>> fixed remappings patch.
>>> kernelci.org has had the ste-snowall failing in v4.2 stable for
> Note the failure was for v4.2 stable...
>>> awhile, so I finally bisected it down to this patch, which is in
>>> mainline in the form of commit bf64dd262eaa (ARM: ux500: add an SMP
>>> enablement type and move cpu nodes). I confirmed that reverting that
>>> commit on top of v4.2 gets the snowball booting again.
>>>  http://kernelci.org/boot/all/job/stable/kernel/v4.2.3/
>>>  https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/102/console
>> OK I tested the u8500_defconfig and it still works fine on
>> Snowball. So I have no clue what is causing this :(
>> (See below for my bootlog.)
>> - I first thought it was a multiplatform issue but it seems
>> not AFAICT from the logs.
> It fails on both mutli_v7_defconfig and u8500_defconfig.
>> - Is the CI boot is using the latest device tree from
> Yes, it always uses the DT from the same tree that the kernel is built from.
>> 5070] starting kernel at 0x00008000, machine 3293
>> [ 0.000000] Booting Linux on physical CPU 0x300
>> [ 0.000000] Linux version 4.3.0-rc6-00001-gdff502ea54cb
> Ah, you're using mainline. The boot failure we found is in stable
> v4.2 (and v4.1) which suggests that there's a patch/fix that's
> upstream but not yet backported to stable.
Minor correction: the failure is only on v4.2 and stable v4.2.y.
stable v4.1.y is fine.
More information about the linux-arm-kernel