QCA IPQ4019 support in mainline linux

[Sven Eckelmann <sven.eckelmann@open-mesh.com>]

[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]

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"

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]