What is the command line? What is the FDT load address from u-boot?
-M
> On Jun 23, 2016, at 11:20 AM, Sven Eckelmann <sven.eckelmann@xxxxxxxxxxxxx> wrote:
>
> Hi,
>
> I was trying to get a IPQ40xx/AP-DK01.1-C1 based board booting with Linux
> 4.7-rc3. It looks like it fails relative early in the boot process. One of the
> problems seems to be that the reserved memory is currently missing for this
> SoC. This crashes the system when early_alloc_aligned does the memset for
> vectors in devicemaps_init.
>
> I would have expected something like this in
> arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
>
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> rsvd1@87000000 {
> reg = <0x87000000 0x500000>;
> no-map;
> };
> wifi_dump@87500000 {
> reg = <0x87500000 0x600000>;
> no-map;
> };
> rsvd2@87B00000 {
> reg = <0x87B00000 0x500000>;
> no-map;
> };
> };
>
> But it looks that this is not yet enough. It also hangs slightly later
>
> Booting Linux on physical CPU 0x0
> Linux version 4.7.0-rc3 (sven@bentobox) (gcc version 5.3.0 (LEDE GCC 5.3.0 r611) ) #2 SMP PREEMPT Thu Jun 23 14:43:41 UTC 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: div instructions available: patching division code
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1
> bootconsole [earlycon0] enabled
> Memory policy: Data cache writealloc
> On node 0 totalpages: 28672
> free_area_init_node: node 0, pgdat c0ecdac0, node_mem_map c6f14000
> Normal zone: 256 pages used for memmap
> Normal zone: 0 pages reserved
> Normal zone: 28672 pages, LIFO batch:7
>
> So it hangs right before the highmem initialization information is printed. (So
> most likely crashed somewhere inside the highmem initialization)
>
> Is this a known problem? The same problem happens with the dtb taken from the
> precompiled QSDK image. So it looks right now like a problem in the kernel
> than in the DTS (but everything is possible).
>
> Is there any rough timeplan when the Dakota SoC (and the DK boards) is planned
> to be supported in mainline? I know this is rather hard to know because you
> also have to convince the maintainers to accept your patches ;)
> So maybe there is an overview of the missing parts in the kernel. Things which
> I definitely didn't see were the ethernet drivers. But my current experiment
> with 4.7-rc7 seemed to suggest that even more basic things are still missing.
>
> Kind regards,
> Sven
>
> PS: If anyone also wants to get the earlyprintk stuff working for this board
> (guessing the PHY+VIRT addresses combination without spec took a while...):
>
> CONFIG_DEBUG_QCOM_UARTDM=y
> CONFIG_DEBUG_UART_PHYS=0x78af000
> CONFIG_DEBUG_UART_VIRT=0xFA0AF000
> CONFIG_DEBUG_UNCOMPRESS=y
> # CONFIG_DEBUG_ICEDCC is not set
> # CONFIG_DEBUG_SEMIHOSTING is not set
> # CONFIG_DEBUG_LL_UART_8250 is not set
> # CONFIG_DEBUG_LL_UART_PL01X is not set
> CONFIG_DEBUG_LL_INCLUDE="debug/msm.S"
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
