From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@oracle.com (santosh.shilimkar at oracle.com) Date: Tue, 23 Dec 2014 10:13:17 -0800 Subject: kernel.org - master not booting on keystone (ARM v7 Cortex A15 SoC) EVMs In-Reply-To: <5499AEFB.8060208@oracle.com> References: <549490D6.3090804@ti.com> <20141219211816.GH10857@pengutronix.de> <5494B932.6060602@ti.com> <20141221102925.GJ10857@pengutronix.de> <54983304.3080302@ti.com> <54997AC2.1040507@linaro.org> <5499A823.4020704@ti.com> <5499AEFB.8060208@oracle.com> Message-ID: <5499B0BD.5010507@oracle.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 12/23/14 10:05 AM, santosh.shilimkar at oracle.com wrote: > +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 >>>>>>> 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 >>>>>> git bisect bad >>>>>> >>>>>> 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 >>>>>> 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 >>>>>> Tested-by: Laura Abbott >>>>>> Acked-by: Nicolas Pitre >>>>>> >>> >>> 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, Sorry Uwe !! I mean to ask this question to Nicolas and RMK. > The fix looks straight forward to me. Can you please comment if you > think otherwise. > Grygorii, Can you please add the formatted patch to RMK's patch system ? Regards, Santosh