Hi Javier,
On Thursday 26 May 2016 01:15 PM, Javier Martinez Canillas wrote:
> [adding Kevin and Sjoerd who also noticed issues with this patch]
>
> Hi Pankaj,
>
> On 05/25/2016 11:43 PM, pankaj.dubey wrote:
>> Hi Javier,
>>
>> On Wednesday 25 May 2016 08:32 PM, Javier Martinez Canillas wrote:
>>> Hello Pankaj,
>>>
>>> On 05/25/2016 04:33 AM, pankaj.dubey wrote:
>>>> Hi Javier,
>>>>
>>>>> Signed-off-by: Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx>
>>>>
>>>> Just noticed that, current krzk/for-next failed to boot on Exynos5880
>>>> based Chromebook device. Git bisect is showing culprit as this patch.
>>>
>>> Strange, krzk/for-next boots correctly on my Exynos5800 Peach Pi:
>>>
>>> $ git log --pretty=oneline --abbrev-commit HEAD
>>> 35e691cf5165 Merge branch 'fixes-v4.7' into for-next
>>>
>>
>> This is same as mine.
>>
>> My other build parameters are:
>> defconfig: exynos_defconfig
>> CROSS_COMPILE: gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux
>
> I'm also using exynos_defconfig and a similar compiler
> (gcc-linaro-arm-linux-gnueabihf-4.9-2015.01-3).
>
>> rootfs: small cramfs
>>
>>> $ uname -r
>>> 4.6.0-00073-g35e691cf5165
>>>
>>>> When I reverted this patch, its able to boot normally.
>>>> Is there any missing patches that we need to take on krzk/for-next to
>>>> boot on Chromebook.
>>>>
>>>
>>
>> Further I checked that, either I revert this patch OR do not reserve
>> memory for MFC in exynos_reserve using following changes, both cases I
>> am able to boot kernel on Chromebook (Exynos5800).
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index f977eea..e615e24 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -268,7 +268,7 @@ static char const *const exynos_dt_compat[]
>> __initconst = {
>>
>> static void __init exynos_reserve(void)
>> {
>> -#ifdef CONFIG_S5P_DEV_MFC
>> +#ifndef CONFIG_S5P_DEV_MFC
>> int i;
>> char *mfc_mem[] = {
>> "samsung,mfc-v5",
>> @@ -280,6 +280,8 @@ static void __init exynos_reserve(void)
>> for (i = 0; i < ARRAY_SIZE(mfc_mem); i++)
>> if (of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, mfc_mem[i]))
>> break;
>> +#else
>> + pr_err("*****exynos_reserve Bypassing Memory Reservation for MFC
>> ********\n");
>> #endif
>> }
>>
>>
>>> No that I'm aware of. I wonder why it boots for me but fails for
>>> you. Can you please share your complete boot log to see if there
>>> are any hints there?
>>>
>>
>> Following is failed boot log:
>> U-Boot 2013.04-g8e3e5ef (May 26 2015 - 16:11:36) for Peach
>>
>> CPU: Exynos5422@900MHz
>>
>> Board: Google Peach Pi, rev 11.6
>> I2C: ready
>> DRAM: 3.5 GiB
>> Relocation Offset dbd54000, base at ffb54000
>> SPL stack at 2072c00, used 3f0, free 10
>> PMIC max77802-pmic initialized
>> CPU: Exynos5422@1800MHz
>> TPS65090 PMIC EC init
>> MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
>> SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
>> In: cros-ec-keyb
>> Out: lcd
>> Err: lcd
>> SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
>> ELOG: Event(17) added with size 13
>> Net: No ethernet found.
>> Hit any key to stop autoboot: 0
>> mmc1 is current device
>> 4586144 bytes read in 242 ms (18.1 MiB/s)
>> 26583040 bytes read in 1166 ms (21.7 MiB/s)
>> ## Loading kernel from FIT Image at 20008000 ...
>> Using 'conf@2' configuration
>> Trying 'kernel@1' kernel subimage
>> Description: unavailable
>> Type: Kernel Image (no loading done)
>> Compression: uncompressed
>> Data Start: 0x200080c8
>> Data Size: 4459024 Bytes = 4.3 MiB
>> Verifying Hash Integrity ... OK
>> ## Loading fdt from FIT Image at 20008000 ...
>
> A difference I see is that I'm chain loading a non-verified u-boot and you
> are loading a signed FIT image directly. But Sjoerd also chain loads a nv
> u-boot and his Peach doesn't boot either so I don't think that's a cause.
>
>> Using 'conf@2' configuration
>> Trying 'fdt@2' fdt subimage
>> Description: exynos5800-peach-pi.dtb
>> Type: Flat Device Tree
>> Compression: uncompressed
>> Data Start: 0x20458148
>> Data Size: 63002 Bytes = 61.5 KiB
>> Architecture: ARM
>> Hash algo: sha1
>> Hash value: cd1c1703f744b44b1833ca61ec36b625665548de
>> Verifying Hash Integrity ... sha1+ OK
>> Booting using the fdt blob at 0x20458148
>> XIP Kernel Image (no loading done) ... OK
>> Loading Device Tree to 3ffe1000, end 3ffffb49 ... OK
>> boot_kernel.c: ft_board_setup: warning: Must pass exactly one of vboot
>> or cdata
>>
>> Starting kernel ...
>>
>> Timer summary in microseconds:
>> Mark Elapsed Stage
>> 0 0 reset
>> 122,793 122,793 board_init_f
>> 143,214 20,421 board_init_r
>> 238,069 94,855 id=64
>> 240,278 2,209 main_loop
>> 4,841,682 4,601,404 bootm_start
>> 4,841,683 1 id=1
>> 4,846,604 4,921 id=100
>> 4,846,607 3 id=101
>> 4,846,607 0 id=102
>> 4,850,208 3,601 id=110
>> 4,877,729 27,521 id=105
>> 4,877,731 2 id=106
>> 4,877,734 3 id=107
>> 4,877,735 1 id=108
>> 4,877,736 1 id=109
>> 4,882,406 4,670 id=90
>> 4,882,408 2 id=92
>> 4,882,408 0 id=91
>> 4,927,272 44,864 id=95
>> 4,927,274 2 id=96
>> 4,927,276 2 id=97
>> 4,927,277 1 id=98
>> 4,927,279 2 id=99
>> 4,937,617 10,338 id=7
>> 4,951,899 14,282 id=15
>> 4,955,112 3,213 start_kernel
>>
>> Accumulated time:
>> 6,948 SPI read
>> Uncompressing Linux... done, booting the kernel.
>> [ 0.000000] Booting Linux on physical CPU 0x0
>> [ 0.000000] Linux version 4.6.0-00073-g35e691c
>> (pankaj@chromebld-server) (gcc version 4.9.2 20140904 (prerelease)
>> (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC
>> 4.9-2014.09) ) #59 SMP PREEMPT Thu May 26 08:21:07 IST 2016
>> [ 0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7),
>> cr=10c5387d
>> [ 0.000000] CPU: div instructions available: patching division code
>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
>> cache
>> [ 0.000000] Machine model: Google Peach Pi Rev 10+
>> [ 0.000000] bootconsole [earlycon0] enabled
>> [ 0.000000] cma: Reserved 64 MiB at 0xfbc00000
>> [ 0.000000] Memory policy: Data cache writealloc
>> [ 0.000000] Samsung CPU ID: 0xe5422001
>> [ 0.000000] On node 0 totalpages: 913407
>> [ 0.000000] free_area_init_node: node 0, pgdat c0b42cc0, node_mem_map
>> ee3f7000
>> [ 0.000000] Normal zone: 1536 pages used for memmap
>> [ 0.000000] Normal zone: 0 pages reserved
>> [ 0.000000] Normal zone: 194560 pages, LIFO batch:31
>> [ 0.000000] HighMem zone: 718847 pages, LIFO batch:31
>> [ 0.000000] percpu: Embedded 12 pages/cpu @ee341000 s19392 r8192
>> d21568 u49152
>> [ 0.000000] pcpu-alloc: s19392 r8192 d21568 u49152 alloc=12*4096
>> [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 911871
>> [ 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.
Thanks,
Pankaj Dubey
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
