[PATCH 1/2] ARM: ux500: add an SMP enablement type and move cpu nodes
khilman at kernel.org
Thu Oct 22 15:13:11 PDT 2015
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.
More information about the linux-arm-kernel