[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <869bee66-9aa8-6c17-d140-3e6644acaf91@osg.samsung.com>
Date: Thu, 26 May 2016 08:14:29 -0400
From: Javier Martinez Canillas <javier@....samsung.com>
To: "pankaj.dubey" <pankaj.dubey@...sung.com>,
linux-kernel@...r.kernel.org
Cc: Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
linux-samsung-soc@...r.kernel.org,
Russell King <linux@....linux.org.uk>,
Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Rob Herring <robh+dt@...nel.org>,
Kukjin Kim <kgene@...nel.org>,
Kumar Gala <galak@...eaurora.org>,
linux-arm-kernel@...ts.infradead.org,
Sjoerd Simons <sjoerd.simons@...labora.co.uk>,
Kevin Hilman <khilman@...libre.com>
Subject: Re: ARM: dts: exynos: Add MFC memory banks for Peach boards
Hello Pankaj,
On 05/26/2016 05:10 AM, pankaj.dubey wrote:
[snip]
>>> [ 0.000000] Kernel command line: cros_legacy console=ttySAC3,115200
>>> debug earlyprintk cros_debug no_console_suspend root=/dev/ram0 rw
>>> ramdisk=32768 initrd=0x42000000,3
>>> 2M
>>
>> I see that you are loading an initrd at 0x42000000 with size of 32 MiB.
>>
>> [...]
>>
>>> [ 1.121421] Trying to unpack rootfs image as initramfs...
>>> [ 1.126940] rootfs image is not initramfs (junk in compressed
>>> archive); looks like an initrd
>>> [ 1.160139] Unable to handle kernel paging request at virtual address
>>> e3000000
>>
>> So I wonder if the problem is that the memblock_remove() is called very
>> early and so the kernel is not able to copy the initrd from 0x42000000
>> to 0x44000000 since overlaps with the mfc-r mem (0x43000000-0x43800000).
>>
>> Specially since the NULL pointer dereference below happens in the
>> populate_rootfs() function when calling xwrite() to do the copy.
>>
>> Could you please try to change the load address for your initrd, or
>> change the mfc-r start address to see if that prevents the issue?
>>
>
> Yes, you are correct. This was the case.
> I changed initrd location from 0x42000000 to 0x44000000, and it is able
> to boot without any crash.
>
Great, good to confirm that this was causing your boot failure.
> Thanks,
> Pankaj Dubey
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Powered by blists - more mailing lists