kernel.org - master not booting on keystone (ARM v7 Cortex A15 SoC) EVMs
santosh.shilimkar at oracle.com
santosh.shilimkar at oracle.com
Tue Dec 23 10:05:47 PST 2014
+RMK
On 12/23/14 9:36 AM, Murali Karicheri wrote:
> CC + Santosh (Keystone maintainer)
>
Thanks Murali !!
> On 12/23/2014 09:22 AM, Grygorii.Strashko at linaro.org wrote:
>> On 12/22/2014 05:04 PM, Murali Karicheri wrote:
>>> On 12/21/2014 05:29 AM, Uwe Kleine-König wrote:
>>>> Hello,
>>>>
>>>> I cannot say anything here, but maybe the people being involved in
>>>> 1e6b48116a950 can. I added them to Cc and didn't trim the mail for
>>>> them.
>>> Uwe,
>>>
>>> Thanks for copying the commit owners. Looking forward for a response
>>> from them.
>>>
>>> Murali
>>>>
>>>> Best regards
>>>> Uwe
>>>>
>>>> On Fri, Dec 19, 2014 at 06:48:02PM -0500, Murali Karicheri wrote:
>>>>> On 12/19/2014 04:25 PM, Tyler Baker wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On 19 December 2014 at 13:18, Uwe Kleine-König
>>>>>> <u.kleine-koenig at pengutronix.de> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> On Fri, Dec 19, 2014 at 03:55:50PM -0500, Murali Karicheri wrote:
>>>>>>>> I have pulled the latest master from
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>>>>>> and
>>>>>>>> tried booting on keystone k2hk and k2e EVM. The boot hangs with
>>>>>>>> following log. Has anyone seen this? Keystone is an ARM v7 cortex
>>>>>>>> A15 SMP platform. I am assuming master branch is broken for ARM v7
>>>>>>>> and someone is working to address this. v3.18 booted up fine on my
>>>>>>>> EVM.
>>>>>>>>
>>>>>>>> Any idea?
>>>>>>> You forgot to attach the log?! So no, I don't have any idea. Did you
>>>>>>> bisect?
>>>>>
>>>>> This was my first git bisect work. git bisect showed me below commit
>>>>> as bad commit. But it is pretty old commit. I tried reverting the
>>>>> commit and my board booted up fine. The boot log attached below. I
>>>>> did following until I got the bad commit. v3.18 also worked fine.
>>>>>
>>>>> git bisect start
>>>>> git bisect good<working commit>
>>>>> git bisect bad<non working commit>
>>>>>
>>>>> I build and test. If boots fine, I did git bisect good and if not,
>>>>> git bisect bad until I got the bad commit. Can someone comment if my
>>>>> bisect steps look sane? If so, what is wrong with the below commit?
>>>>> Ours is a LPAE SoC.
>>>>>
>>>>> commit 1e6b48116a95046ec51f3d40f83aff8b006674d7
>>>>> Author: Kees Cook<keescook at chromium.org>
>>>>> Date: Thu Apr 3 17:28:11 2014 -0700
>>>>>
>>>>> ARM: mm: allow non-text sections to be non-executable
>>>>>
>>>>> Adds CONFIG_ARM_KERNMEM_PERMS to separate the kernel memory
>>>>> regions
>>>>> into section-sized areas that can have different permisions.
>>>>> Performs
>>>>> the NX permission changes during free_initmem, so that init
>>>>> memory can be
>>>>> reclaimed.
>>>>>
>>>>> This uses section size instead of PMD size to reduce memory
>>>>> lost to
>>>>> padding on non-LPAE systems.
>>>>>
>>>>> Based on work by Brad Spengler, Larry Bassel, and Laura Abbott.
>>>>>
>>>>> Signed-off-by: Kees Cook<keescook at chromium.org>
>>>>> Tested-by: Laura Abbott<lauraa at codeaurora.org>
>>>>> Acked-by: Nicolas Pitre<nico at linaro.org>
>>>>>
>>
>> Looks like kernel_x_start, kernel_x_end are calculated wrongly in LPAE
>> case.
>> kernel_x_start == 0x0000 0000
>> kernel_x_end == 0x0080 0000
>>
>> but should be:
>> kernel_x_start == 0x0000 0008 0000 0000
>> kernel_x_end == 0x0000 0008 0080 0000
>>
>> Below diff restores boot for me:
>>
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index cda7c40..4e6ef89 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -1329,8 +1329,8 @@ static void __init kmap_init(void)
>> static void __init map_lowmem(void)
>> {
>> struct memblock_region *reg;
>> - unsigned long kernel_x_start = round_down(__pa(_stext),
>> SECTION_SIZE);
>> - unsigned long kernel_x_end = round_up(__pa(__init_end),
>> SECTION_SIZE);
>> + phys_addr_t kernel_x_start = round_down(__pa(_stext),
>> SECTION_SIZE);
>> + phys_addr_t kernel_x_end = round_up(__pa(__init_end),
>> SECTION_SIZE);
>>
>> /* Map all the lowmem memory banks. */
>> for_each_memblock(memory, reg) {
>
Uwe,
The fix looks straight forward to me. Can you please comment if you
think otherwise.
Regards,
Santosh
More information about the linux-arm-kernel
mailing list