* QCA IPQ4019 support in mainline linux
@ 2016-06-23 16:20 Sven Eckelmann
2016-06-23 16:55 ` Matthew McClintock
0 siblings, 1 reply; 10+ messages in thread
From: Sven Eckelmann @ 2016-06-23 16:20 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: QCA IPQ4019 support in mainline linux 2016-06-23 16:20 QCA IPQ4019 support in mainline linux Sven Eckelmann @ 2016-06-23 16:55 ` Matthew McClintock 2016-06-24 7:24 ` Sven Eckelmann 0 siblings, 1 reply; 10+ messages in thread From: Matthew McClintock @ 2016-06-23 16:55 UTC (permalink / raw) To: Sven Eckelmann; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner 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@open-mesh.com> 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" ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-23 16:55 ` Matthew McClintock @ 2016-06-24 7:24 ` Sven Eckelmann 2016-06-24 16:37 ` Matthew McClintock 0 siblings, 1 reply; 10+ messages in thread From: Sven Eckelmann @ 2016-06-24 7:24 UTC (permalink / raw) To: Matthew McClintock; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner [-- Attachment #1: Type: text/plain, Size: 6060 bytes --] On Thursday 23 June 2016 11:55:46 Matthew McClintock wrote: > What is the command line? What is the FDT load address from u-boot? Format: Log Type - Time(microsec) - Message - Optional Info Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.1.1-00072 S - IMAGE_VARIANT_STRING=DAABANAZA S - OEM_IMAGE_VERSION_STRING=CRM S - Boot Config, 0x00000021 S - Core 0 Frequency, 0 MHz B - 261 - PBL, Start B - 1339 - bootable_media_detect_entry, Start B - 1679 - bootable_media_detect_success, Start B - 1692 - elf_loader_entry, Start B - 5068 - auth_hash_seg_entry, Start B - 7212 - auth_hash_seg_exit, Start B - 568520 - elf_segs_hash_verify_entry, Start B - 682592 - PBL, End B - 682616 - SBL1, Start B - 772516 - pm_device_init, Start D - 6 - pm_device_init, Delta B - 773957 - boot_flash_init, Start D - 52725 - boot_flash_init, Delta B - 830856 - boot_config_data_table_init, Start D - 3805 - boot_config_data_table_init, Delta - (419 Bytes) B - 838058 - clock_init, Start D - 7583 - clock_init, Delta B - 850162 - CDT version:2,Platform ID:8,Major ID:1,Minor ID:2,Subtype:0 B - 853653 - sbl1_ddr_set_params, Start B - 858644 - cpr_init, Start D - 2 - cpr_init, Delta B - 863030 - Pre_DDR_clock_init, Start D - 4 - Pre_DDR_clock_init, Delta D - 13154 - sbl1_ddr_set_params, Delta B - 876854 - pm_driver_init, Start D - 2 - pm_driver_init, Delta B - 883505 - sbl1_wait_for_ddr_training, Start D - 31 - sbl1_wait_for_ddr_training, Delta B - 902916 - Image Load, Start D - 138201 - QSEE Image Loaded, Delta - (267732 Bytes) B - 1041617 - Image Load, Start D - 1448 - SEC Image Loaded, Delta - (2048 Bytes) B - 1051836 - Image Load, Start D - 173993 - APPSBL Image Loaded, Delta - (353891 Bytes) B - 1226254 - QSEE Execution, Start D - 66 - QSEE Execution, Delta B - 1232440 - SBL1, End D - 551938 - SBL1, Delta S - Flash Throughput, 1991 KB/s (624090 Bytes, 313384 us) S - DDR Fre� U-Boot 2012.07 [Barrier Breaker r40864,r40864] (Feb 16 2016 - 23:33:08) smem ram ptable found: ver: 1 len: 3 DRAM: 128 MiB WARNING: Caches not enabled machid : 0x8010200 NAND: SF: Detected Spansion with page size 64 KiB, total 32 MiB ipq_spi: page_size: 0x100, sector_size: 0x10000, size: 0x2000000 32 MiB MMC: *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial machid: 8010200 Net: OM3 standard: change gpio 59 -> 63 MAC0 addr:0:3:7f:ba:db:ad ipq40xx_ess_sw_init done PHY ID1: 0x4d PHY ID2: 0xd0b2 eth0 Hit any key to stop autoboot: 0 (IPQ40xx) # (IPQ40xx) # (IPQ40xx) # setenv serverip 192.168.2.227 (IPQ40xx) # setenv ipaddr 192.168.2.3 (IPQ40xx) # setenv bootargs loglevel=8 earlyprintk console=ttyS0,115200 (IPQ40xx) # tftpboot 0x81000000 lede-ipq806x-APDK01-initramfs-fit-uImage.itb eth0 PHY0 Down Speed :10 Half duplex eth0 PHY1 Down Speed :10 Half duplex eth0 PHY2 Down Speed :10 Half duplex eth0 PHY3 Down Speed :10 Half duplex eth0 PHY4 up Speed :1000 Full duplex Using eth0 device TFTP from server 192.168.2.227; our IP address is 192.168.2.3 Filename 'lede-ipq806x-APDK01-initramfs-fit-uImage.itb'. Load address: 0x81000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ########################################### done Bytes transferred = 6347916 (60dc8c hex) (IPQ40xx) # bootm 0x81000000 ## Booting kernel from FIT Image at 81000000 ... Using 'config@1' configuration Trying 'kernel@1' kernel subimage Description: ARM OpenWrt Linux-4.7-rc3 Type: Kernel Image Compression: gzip compressed Data Start: 0x810000e4 Data Size: 6340562 Bytes = 6 MiB Architecture: ARM OS: Linux Load Address: 0x80208000 Entry Point: 0x80208000 Hash algo: crc32 Hash value: d12421ed Hash algo: sha1 Hash value: b25692f363b076c63134e3d452316117002c3c85 Verifying Hash Integrity ... crc32+ sha1+ OK ## Flattened Device Tree from FIT Image at 81000000 Using 'config@1' configuration Trying 'fdt@1' FDT blob subimage Description: ARM OpenWrt APDK01 device tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x8160c1e8 Data Size: 6014 Bytes = 5.9 KiB Architecture: ARM Hash algo: crc32 Hash value: 337abac9 Hash algo: sha1 Hash value: 8193d932fb65464c0f12822f777aa220638a9e0f Verifying Hash Integrity ... crc32+ sha1+ OK Booting using the fdt blob at 0x8160c1e8 Uncompressing Kernel Image ... OK Loading Device Tree to 8722b000, end 8722f77d ... OK ipq: fdt fixup unable to find compatible node eth0 MAC Address from ART is not valid eth1 MAC Address from ART is not valid Using machid 0x8010200 from environment Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.7.0-rc3 (sven@bentobox) (gcc version 5.3.0 (LEDE GCC 5.3.0 r611) ) #4 SMP PREEMPT Thu Jun 23 15:38:04 UTC 2016 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1 [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: Data cache writealloc [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-24 7:24 ` Sven Eckelmann @ 2016-06-24 16:37 ` Matthew McClintock 2016-06-27 7:59 ` Sven Eckelmann 0 siblings, 1 reply; 10+ messages in thread From: Matthew McClintock @ 2016-06-24 16:37 UTC (permalink / raw) To: Sven Eckelmann; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner On Jun 24, 2016, at 2:24 AM, Sven Eckelmann <sven.eckelmann@open-mesh.com> wrote: > > On Thursday 23 June 2016 11:55:46 Matthew McClintock wrote: >> What is the command line? What is the FDT load address from u-boot? > > Format: Log Type - Time(microsec) - Message - Optional Info > Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic > S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.1.1-00072 > S - IMAGE_VARIANT_STRING=DAABANAZA > S - OEM_IMAGE_VERSION_STRING=CRM > S - Boot Config, 0x00000021 > S - Core 0 Frequency, 0 MHz > B - 261 - PBL, Start > B - 1339 - bootable_media_detect_entry, Start > B - 1679 - bootable_media_detect_success, Start > B - 1692 - elf_loader_entry, Start > B - 5068 - auth_hash_seg_entry, Start > B - 7212 - auth_hash_seg_exit, Start > B - 568520 - elf_segs_hash_verify_entry, Start > B - 682592 - PBL, End > B - 682616 - SBL1, Start > B - 772516 - pm_device_init, Start > D - 6 - pm_device_init, Delta > B - 773957 - boot_flash_init, Start > D - 52725 - boot_flash_init, Delta > B - 830856 - boot_config_data_table_init, Start > D - 3805 - boot_config_data_table_init, Delta - (419 Bytes) > B - 838058 - clock_init, Start > D - 7583 - clock_init, Delta > B - 850162 - CDT version:2,Platform ID:8,Major ID:1,Minor ID:2,Subtype:0 > B - 853653 - sbl1_ddr_set_params, Start > B - 858644 - cpr_init, Start > D - 2 - cpr_init, Delta > B - 863030 - Pre_DDR_clock_init, Start > D - 4 - Pre_DDR_clock_init, Delta > D - 13154 - sbl1_ddr_set_params, Delta > B - 876854 - pm_driver_init, Start > D - 2 - pm_driver_init, Delta > B - 883505 - sbl1_wait_for_ddr_training, Start > D - 31 - sbl1_wait_for_ddr_training, Delta > B - 902916 - Image Load, Start > D - 138201 - QSEE Image Loaded, Delta - (267732 Bytes) > B - 1041617 - Image Load, Start > D - 1448 - SEC Image Loaded, Delta - (2048 Bytes) > B - 1051836 - Image Load, Start > D - 173993 - APPSBL Image Loaded, Delta - (353891 Bytes) > B - 1226254 - QSEE Execution, Start > D - 66 - QSEE Execution, Delta > B - 1232440 - SBL1, End > D - 551938 - SBL1, Delta > S - Flash Throughput, 1991 KB/s (624090 Bytes, 313384 us) > S - DDR Fre� > > U-Boot 2012.07 [Barrier Breaker r40864,r40864] (Feb 16 2016 - 23:33:08) > > smem ram ptable found: ver: 1 len: 3 > DRAM: 128 MiB > WARNING: Caches not enabled > machid : 0x8010200 > NAND: SF: Detected Spansion with page size 64 KiB, total 32 MiB > ipq_spi: page_size: 0x100, sector_size: 0x10000, size: 0x2000000 > 32 MiB > MMC: > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > machid: 8010200 > Net: > OM3 standard: change gpio 59 -> 63 > MAC0 addr:0:3:7f:ba:db:ad > ipq40xx_ess_sw_init done > PHY ID1: 0x4d > PHY ID2: 0xd0b2 > eth0 > Hit any key to stop autoboot: 0 > (IPQ40xx) # > (IPQ40xx) # > (IPQ40xx) # setenv serverip 192.168.2.227 > (IPQ40xx) # setenv ipaddr 192.168.2.3 > (IPQ40xx) # setenv bootargs loglevel=8 earlyprintk console=ttyS0,115200 > (IPQ40xx) # tftpboot 0x81000000 lede-ipq806x-APDK01-initramfs-fit-uImage.itb > eth0 PHY0 Down Speed :10 Half duplex > eth0 PHY1 Down Speed :10 Half duplex > eth0 PHY2 Down Speed :10 Half duplex > eth0 PHY3 Down Speed :10 Half duplex > eth0 PHY4 up Speed :1000 Full duplex > Using eth0 device > TFTP from server 192.168.2.227; our IP address is 192.168.2.3 > Filename 'lede-ipq806x-APDK01-initramfs-fit-uImage.itb'. > Load address: 0x81000000 > Loading: ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ########################################### > done > Bytes transferred = 6347916 (60dc8c hex) > (IPQ40xx) # bootm 0x81000000 > ## Booting kernel from FIT Image at 81000000 ... > Using 'config@1' configuration > Trying 'kernel@1' kernel subimage > Description: ARM OpenWrt Linux-4.7-rc3 > Type: Kernel Image > Compression: gzip compressed > Data Start: 0x810000e4 > Data Size: 6340562 Bytes = 6 MiB > Architecture: ARM > OS: Linux > Load Address: 0x80208000 > Entry Point: 0x80208000 > Hash algo: crc32 > Hash value: d12421ed > Hash algo: sha1 > Hash value: b25692f363b076c63134e3d452316117002c3c85 > Verifying Hash Integrity ... crc32+ sha1+ OK > ## Flattened Device Tree from FIT Image at 81000000 > Using 'config@1' configuration > Trying 'fdt@1' FDT blob subimage > Description: ARM OpenWrt APDK01 device tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x8160c1e8 > Data Size: 6014 Bytes = 5.9 KiB > Architecture: ARM > Hash algo: crc32 > Hash value: 337abac9 > Hash algo: sha1 > Hash value: 8193d932fb65464c0f12822f777aa220638a9e0f > Verifying Hash Integrity ... crc32+ sha1+ OK > Booting using the fdt blob at 0x8160c1e8 > Uncompressing Kernel Image ... OK > Loading Device Tree to 8722b000, end 8722f77d ... OK > ipq: fdt fixup unable to find compatible node > eth0 MAC Address from ART is not valid > eth1 MAC Address from ART is not valid > Using machid 0x8010200 from environment > > Starting kernel ... > > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.7.0-rc3 (sven@bentobox) (gcc version 5.3.0 (LEDE GCC 5.3.0 r611) ) #4 SMP PREEMPT Thu Jun 23 15:38:04 UTC 2016 > [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d > [ 0.000000] CPU: div instructions available: patching division code > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > [ 0.000000] Machine model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1 > [ 0.000000] bootconsole [earlycon0] enabled > [ 0.000000] Memory policy: Data cache writealloc Can you compare to this? https://gist.github.com/anonymous/38a44876ff4d2033e16e941408561b64 This is loading an initramfs image, also the earlycon cmdline bits should work properly as well. -M ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-24 16:37 ` Matthew McClintock @ 2016-06-27 7:59 ` Sven Eckelmann 2016-06-27 15:18 ` Matthew McClintock 0 siblings, 1 reply; 10+ messages in thread From: Sven Eckelmann @ 2016-06-27 7:59 UTC (permalink / raw) To: Matthew McClintock; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner [-- Attachment #1: Type: text/plain, Size: 628 bytes --] On Friday 24 June 2016 11:37:59 Matthew McClintock wrote: [...] > Can you compare to this? > > https://gist.github.com/anonymous/38a44876ff4d2033e16e941408561b64 > > This is loading an initramfs image, also the earlycon cmdline bits should work properly as well. What exactly should I compare? This is 3.18 - so it is definitely not the mainstream Linux version of the patches but most likely your own codeaurora fork with the 2k or 4k patchbomb. But I've tried your bootargs. These broke the earlyprintk and didn't boot with v4.7-rc3. So the difference here doesn't seem to be the fdt load address. Kind regards, Sven [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-27 7:59 ` Sven Eckelmann @ 2016-06-27 15:18 ` Matthew McClintock 2016-06-27 15:44 ` Sven Eckelmann 0 siblings, 1 reply; 10+ messages in thread From: Matthew McClintock @ 2016-06-27 15:18 UTC (permalink / raw) To: Sven Eckelmann; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner > On Jun 27, 2016, at 2:59 AM, Sven Eckelmann <sven.eckelmann@open-mesh.com> wrote: > >> https://gist.github.com/anonymous/38a44876ff4d2033e16e941408561b64 >> >> This is loading an initramfs image, also the earlycon cmdline bits should > work properly as well. > > What exactly should I compare? This is 3.18 - so it is definitely not the > mainstream Linux version of the patches but most likely your own codeaurora > fork with the 2k or 4k patch bomb. This is an upstream clean tree, but I did not realize the log was crashing though also that it was a back port to 3.18. I’m searching on gists for a working log here since I don’t have access to a board. Here is one that might be relevant: https://gist.github.com/anonymous/97d752ff8d50f45b8bbc > But I've tried your bootargs. These broke the earlyprintk and didn't boot with > v4.7-rc3. So the difference here doesn't seem to be the fdt load address. I’m sure this command line works around the 4.6 timeframe. Are you sure you need the earlyprintk cmdline bit? -M-- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-27 15:18 ` Matthew McClintock @ 2016-06-27 15:44 ` Sven Eckelmann 2016-06-27 16:08 ` Matthew McClintock 0 siblings, 1 reply; 10+ messages in thread From: Sven Eckelmann @ 2016-06-27 15:44 UTC (permalink / raw) To: Matthew McClintock; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner [-- Attachment #1: Type: text/plain, Size: 1367 bytes --] On Monday 27 June 2016 10:18:12 Matthew McClintock wrote: [..] > This is an upstream clean tree, but I did not realize the log was crashing though also that it was a back port to 3.18. I’m searching on gists for a working log here since I don’t have access to a board. Here is one that might be relevant: > > https://gist.github.com/anonymous/97d752ff8d50f45b8bbc > > > But I've tried your bootargs. These broke the earlyprintk and didn't boot with > > v4.7-rc3. So the difference here doesn't seem to be the fdt load address. > > I’m sure this command line works around the 4.6 timeframe. Ok, will test again tomorrow with an older kernel version. But it is just really odd that your arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi + qcom-ipq4019-ap.dk01.1-c1.dts was added with v4.7-rc1 and now the board should already have worked with a clean(?) Linux-4.5.0-rc4. > Are you sure you need the earlyprintk cmdline bit? At least I need it to see anything on the serial (until it starts to hang somewhere in the page code - or earlier without the reserved memory dts snipped posted in the first mail). Back to the second part of the question: Is there a roadmap for Dakota support in upstream kernel.org support? And is there a list of things which still have to be integrated in the kernel.org Linux kernel? Kind regards, Sven [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-27 15:44 ` Sven Eckelmann @ 2016-06-27 16:08 ` Matthew McClintock 2016-06-28 15:02 ` Sven Eckelmann 0 siblings, 1 reply; 10+ messages in thread From: Matthew McClintock @ 2016-06-27 16:08 UTC (permalink / raw) To: Sven Eckelmann; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner > On Jun 27, 2016, at 10:44 AM, Sven Eckelmann <sven.eckelmann@open-mesh.com> wrote: > >> I’m sure this command line works around the 4.6 timeframe. > > Ok, will test again tomorrow with an older kernel version. But it is > just really odd that your arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi > + qcom-ipq4019-ap.dk01.1-c1.dts was added with v4.7-rc1 and now the > board should already have worked with a clean(?) Linux-4.5.0-rc4. Fair enough, checkout this tree as well: https://source.codeaurora.org/quic/qsdk/mmcclint-qca/log/?h=for-next -M -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-27 16:08 ` Matthew McClintock @ 2016-06-28 15:02 ` Sven Eckelmann 2016-06-28 15:57 ` Matthew McClintock 0 siblings, 1 reply; 10+ messages in thread From: Sven Eckelmann @ 2016-06-28 15:02 UTC (permalink / raw) To: Matthew McClintock; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner [-- Attachment #1: Type: text/plain, Size: 831 bytes --] On Monday 27 June 2016 11:08:04 Matthew McClintock wrote: > > > On Jun 27, 2016, at 10:44 AM, Sven Eckelmann <sven.eckelmann@open-mesh.com> wrote: > > > >> I’m sure this command line works around the 4.6 timeframe. > > > > Ok, will test again tomorrow with an older kernel version. But it is > > just really odd that your arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi > > + qcom-ipq4019-ap.dk01.1-c1.dts was added with v4.7-rc1 and now the > > board should already have worked with a clean(?) Linux-4.5.0-rc4. > > Fair enough, checkout this tree as well: https://source.codeaurora.org/quic/qsdk/mmcclint-qca/log/?h=for-next Just tried the branch you gave me. But it has the two exact same problems. Do you have by any chance the .config which you've used to build the working kernel? Kind regards, Sven [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: QCA IPQ4019 support in mainline linux 2016-06-28 15:02 ` Sven Eckelmann @ 2016-06-28 15:57 ` Matthew McClintock 0 siblings, 0 replies; 10+ messages in thread From: Matthew McClintock @ 2016-06-28 15:57 UTC (permalink / raw) To: Sven Eckelmann; +Cc: linux-arm-msm, Mathieu Olivari, Marek Lindner > On Jun 28, 2016, at 10:02 AM, Sven Eckelmann <sven.eckelmann@open-mesh.com> wrote: > > On Monday 27 June 2016 11:08:04 Matthew McClintock wrote: >> >>> On Jun 27, 2016, at 10:44 AM, Sven Eckelmann <sven.eckelmann@open-mesh.com> wrote: >>> >>>> I’m sure this command line works around the 4.6 timeframe. >>> >>> Ok, will test again tomorrow with an older kernel version. But it is >>> just really odd that your arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi >>> + qcom-ipq4019-ap.dk01.1-c1.dts was added with v4.7-rc1 and now the >>> board should already have worked with a clean(?) Linux-4.5.0-rc4. >> >> Fair enough, checkout this tree as well: https://source.codeaurora.org/quic/qsdk/mmcclint-qca/log/?h=for-next > > Just tried the branch you gave me. But it has the two exact same problems. > > Do you have by any chance the .config which you've used to build the > working kernel? I don’t anymore, can you share yours and I can look over it? -M ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-06-28 15:57 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-23 16:20 QCA IPQ4019 support in mainline linux Sven Eckelmann 2016-06-23 16:55 ` Matthew McClintock 2016-06-24 7:24 ` Sven Eckelmann 2016-06-24 16:37 ` Matthew McClintock 2016-06-27 7:59 ` Sven Eckelmann 2016-06-27 15:18 ` Matthew McClintock 2016-06-27 15:44 ` Sven Eckelmann 2016-06-27 16:08 ` Matthew McClintock 2016-06-28 15:02 ` Sven Eckelmann 2016-06-28 15:57 ` Matthew McClintock
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.