From: grygorii.strashko@linaro.org (Grygorii.Strashko@linaro.org)
To: linux-arm-kernel@lists.infradead.org
Subject: kernel.org - master not booting on keystone (ARM v7 Cortex A15 SoC) EVMs
Date: Tue, 23 Dec 2014 16:22:58 +0200 [thread overview]
Message-ID: <54997AC2.1040507@linaro.org> (raw)
In-Reply-To: <54983304.3080302@ti.com>
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@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@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@chromium.org>
>>> Tested-by: Laura Abbott<lauraa@codeaurora.org>
>>> Acked-by: Nicolas Pitre<nico@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) {
--
regards,
-grygorii
next prev parent reply other threads:[~2014-12-23 14:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 20:55 kernel.org - master not booting on keystone (ARM v7 Cortex A15 SoC) EVMs Murali Karicheri
2014-12-19 21:17 ` Murali Karicheri
2014-12-19 21:18 ` Uwe Kleine-König
2014-12-19 21:25 ` Tyler Baker
2014-12-19 23:48 ` Murali Karicheri
2014-12-21 10:29 ` Uwe Kleine-König
2014-12-22 15:04 ` Murali Karicheri
2014-12-23 14:22 ` Grygorii.Strashko@linaro.org [this message]
2014-12-23 15:39 ` Murali Karicheri
2014-12-23 16:23 ` Murali Karicheri
2014-12-23 17:36 ` Murali Karicheri
2014-12-23 18:05 ` santosh.shilimkar at oracle.com
2014-12-23 18:13 ` santosh.shilimkar at oracle.com
2014-12-23 18:17 ` Grygorii.Strashko@linaro.org
2014-12-23 18:43 ` Grygorii.Strashko@linaro.org
2014-12-23 19:07 ` santosh.shilimkar at oracle.com
2015-01-02 15:33 ` Murali Karicheri
2015-01-02 19:25 ` santosh.shilimkar at oracle.com
2015-01-05 20:01 ` Kees Cook
2014-12-19 22:00 ` Murali Karicheri
2014-12-19 23:26 ` Nishanth Menon
2014-12-19 23:49 ` Murali Karicheri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54997AC2.1040507@linaro.org \
--to=grygorii.strashko@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).