All of lore.kernel.org
 help / color / mirror / Atom feed
* IPQ8068 support
@ 2017-04-26  8:26 Sven Eckelmann
  2017-04-26 11:18 ` Sricharan R
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Eckelmann @ 2017-04-26  8:26 UTC (permalink / raw)
  To: linux-arm-msm; +Cc: simon.wunderlich

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

Hi,

(the next paragraph is just an explanation of the situation - can be skipped 
to get to the actual question)

I've received a board (either called EWS370 or EWS870AP in their firmware) 
which was announced as AP148 based. But the initial booting up with LEDE 
wasn't working and even the serial port didn't start up. And some tests with 
the standard earlycon registers for the IPQ8064 also didn't work. But then I 
saw that the original firmware used some registers at 0x16640000 for ttyHSL0. 
A quick test showed that this is really the correct address for the serial 
console. I found in the Linux sources that apq8064 is the only one which 
actually uses this register offset. Unsure whether this is actually an APQ8064, 
I've removed the antennas, heatsinks and shielding to find a CPU with the name 
IPQ8068 on it.

It looks like the support for this CPU was never upstreamed by QCA. A quick 
search in the linux-msm tree in codeaurora also showed only uninteresting 
mentions of this CPU [1]. I already know from Dakota that the upstreaming 
effort from some QCA developers were suddenly stopped. Some of the Dakota 
drivers were therefore waiting in some branch of some repository [2] or 
hanging around in an unfinished state on some mailing list. So maybe there are 
similar things somewhere for the IPQ8068. Can someone maybe point me in the 
right direction?

Kind regards,
	Sven

[1] https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=1fc998bf276c7407e03953d8c306cda25b29b6b5
    https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=5ae236e30ff401f4600125ad452e93973ddc205b
    https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=613c5a41ed666383c778129c7b172987aa16f31c
    https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=4aa6962af93bf32dd5c5e6b2313c80f4732b3286
    https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=8b2089087088e08f5e68b83ba04af44ecc3f9e9d
[2] https://source.codeaurora.org/quic/qsdk/mmcclint-qca/log/?h=for-next

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IPQ8068 support
  2017-04-26  8:26 IPQ8068 support Sven Eckelmann
@ 2017-04-26 11:18 ` Sricharan R
  2017-04-26 12:57   ` Sven Eckelmann
  0 siblings, 1 reply; 4+ messages in thread
From: Sricharan R @ 2017-04-26 11:18 UTC (permalink / raw)
  To: Sven Eckelmann, linux-arm-msm; +Cc: simon.wunderlich

Hi Sven,

On 4/26/2017 1:56 PM, Sven Eckelmann wrote:
> Hi,
> 
> (the next paragraph is just an explanation of the situation - can be skipped 
> to get to the actual question)
> 
> I've received a board (either called EWS370 or EWS870AP in their firmware) 
> which was announced as AP148 based. But the initial booting up with LEDE 
> wasn't working and even the serial port didn't start up. And some tests with 
> the standard earlycon registers for the IPQ8064 also didn't work. But then I 
> saw that the original firmware used some registers at 0x16640000 for ttyHSL0. 
> A quick test showed that this is really the correct address for the serial 
> console. I found in the Linux sources that apq8064 is the only one which 
> actually uses this register offset. Unsure whether this is actually an APQ8064, 
> I've removed the antennas, heatsinks and shielding to find a CPU with the name 
> IPQ8068 on it.
> 
> It looks like the support for this CPU was never upstreamed by QCA. A quick 
> search in the linux-msm tree in codeaurora also showed only uninteresting 
> mentions of this CPU [1]. I already know from Dakota that the upstreaming 
> effort from some QCA developers were suddenly stopped. Some of the Dakota 
> drivers were therefore waiting in some branch of some repository [2] or 
> hanging around in an unfinished state on some mailing list. So maybe there are 
> similar things somewhere for the IPQ8068. Can someone maybe point me in the 
> right direction?

So when you mentioned console not working, the kernel console did not come up ?
Whats the bootloader version that is there ?

Given that its ipq8068, not sure which variant of AP148 it is. Atleast i see that
AP148 uses uart4 at 0x16340000 as console. Since you are observing that
bootloaders have configured console at 0x16640000 which is uart7, is it possible
that you can try the below change and see if its only a console issue ?

 qcom-ipq8064.dtsi

                gsbi7: gsbi@16600000 {
                        compatible = "qcom,gsbi-v1.0.0";
                        cell-index = <7>;
                        reg = <0x16640000 0x100>;
                        clocks = <&gcc GSBI7_H_CLK>;
                        clock-names = "iface";
                        #address-cells = <1>;
                        #size-cells = <1>;
                        ranges;
                        status = "disabled";

                        syscon-tcsr = <&tcsr>;

                        gsbi7_serial: serial@16640000 {
                                compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
                                reg = <0x16640000 0x1000>,
                                      <0x16600000 0x1000>;
                                interrupts = <0 158 0x0>;
                                clocks = <&gcc GSBI7_UART_CLK>, <&gcc GSBI7_H_CLK>;
                                clock-names = "core", "iface";
                                status = "disabled";
                        };
                };

qcom-ipq8064-ap148.dts

        	aliases {
                	serial0 = &gsbi7_serial;
        	};
        	
                gsbi@16600000 {
                        qcom,mode = <GSBI_PROT_I2C_UART>;
                        status = "ok";
                        serial@16640000 {
                                status = "ok";
                        };
		};

Regards,
 Sricharan


> 
> Kind regards,
> 	Sven
> 
> [1] https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=1fc998bf276c7407e03953d8c306cda25b29b6b5
>     https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=5ae236e30ff401f4600125ad452e93973ddc205b
>     https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=613c5a41ed666383c778129c7b172987aa16f31c
>     https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=4aa6962af93bf32dd5c5e6b2313c80f4732b3286
>     https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=8b2089087088e08f5e68b83ba04af44ecc3f9e9d
> [2] https://source.codeaurora.org/quic/qsdk/mmcclint-qca/log/?h=for-next
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IPQ8068 support
  2017-04-26 11:18 ` Sricharan R
@ 2017-04-26 12:57   ` Sven Eckelmann
  2017-04-27 14:26     ` Sricharan R
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Eckelmann @ 2017-04-26 12:57 UTC (permalink / raw)
  To: Sricharan R; +Cc: linux-arm-msm, simon.wunderlich


[-- Attachment #1.1: Type: text/plain, Size: 4613 bytes --]

Thanks for the fast reply,

now follows a lot of extra information. The interesting part is in the last 
three paragraphs.

On Mittwoch, 26. April 2017 16:48:17 CEST Sricharan R wrote:
[...]
> > It looks like the support for this CPU was never upstreamed by QCA. A quick 
> > search in the linux-msm tree in codeaurora also showed only uninteresting 
> > mentions of this CPU [1]. I already know from Dakota that the upstreaming 
> > effort from some QCA developers were suddenly stopped. Some of the Dakota 
> > drivers were therefore waiting in some branch of some repository [2] or 
> > hanging around in an unfinished state on some mailing list. So maybe there are 
> > similar things somewhere for the IPQ8068. Can someone maybe point me in the 
> > right direction?
> 
> So when you mentioned console not working, the kernel console did not come up ?

Yes, initially the console was not starting. Then I've disabled the gsbi for 
the serial and simply used the earlycon with address 0x16640000. Just to check 
how far it boots with the wrong device tree. (It looked basically like the 
results from ap148-testbootup.txt with the minor difference that I had 
gsbi4_serial disabled and no gsbi7_serial).

> Whats the bootloader version that is there ?

The version shown on this board is
U-Boot 2012.07-EWS370_370_870_871AP-uboot_version:V1.0.0 [Attitude Adjustment 12.09.1,0a49277] (Aug 30 2016 - 17:29:46)


My boot commands for the test are:

    (IPQ) # printenv
    active_fw=1
    app_part=0
    athaddr=00:aa:bb:cc:dd:13
    baudrate=115200
    bootargs=loglevel=8 earlycon=msm_serial_dm,0x16640000 console=ttyMSM0,115200
    bootcmd=bootipq
    bootdelay=4
    bundle_ap_mac=00:aa:bb:cc:dd:15
    country=000
    ddwrt_sw=0
    debug=0
    domain=0
    ethact=eth0
    ethaddr=88:DC:96:4A:BA:78
    fwaddr=00:aa:bb:cc:dd:14
    hw_id=0101007D
    hw_ver=0.0.1
    ipaddr=192.168.2.3
    language_code=00
    lederam=tftpboot 0x44000000 lede-ipq806x-AP148-initramfs-fit-uImage.itb && set fdt_high 0x6f800000 && bootm 0x44000000
    machid=1260
    oled_on=0
    op_mode=0
    pro_id=000
    serverip=192.168.2.227
    service_tag=000000000000000
    sn=163216875
    snextra=00000000000000000000
    stderr=serial
    stdin=serial
    stdout=serial
    uboot_ver=1.0.0
    wanaddr=00:aa:bb:cc:dd:11
    wlanaddr=00:aa:bb:cc:dd:12
    (IPQ) # run lederam

> 
> Given that its ipq8068, not sure which variant of AP148 it is.

It is definitely not an AP148. I would guess Engenius simply didn't change
the name when they incorporated all the other changes for their firmware.
And then it ended up here with the info that it is an AP148-like board
and I was given the false hope that is should actually be easy to get it
booting because AP148 is already supported.

> Atleast i see that
> AP148 uses uart4 at 0x16340000 as console. Since you are observing that
> bootloaders have configured console at 0x16640000 which is uart7, is it possible
> that you can try the below change and see if its only a console issue ?
[...]

Already did something similar before (not correctly correct as it seems). It
still had the problem that the system freezed during the boot (and never
switched to the actual msm_serial driver as noticed later). Same problem
was observed with your suggested changes.

The system basically freezes (or the console freezes) during bootup somewhere 
near the resource power manager initialization - thus my question about the 
missing IPQ8068 support. I didn't expected that it is really the rpm power 
management but without any  knowledge about the IPQ8068, it is rather hard to 
know and therefore it was better to simply ask about the state of IPQ8068 in 
upstream Linux.



I've looked at your version and my older version. Both seemed to show similar 
problems but it seems that we both had typos in it. You're version had a wrong 
register value in gsbi@16600000 - mine had some typo under serial@16640000

I've now used my version (+fix) which is based on the APQ8064 qsbi7 entry.
This seems to fix the boot and I get an actual serial console without
earlycon. The ethernet is still dead and fails to reset the DMA engine. Not
sure how it is currently connected on that CPU anyway.

Ok, after now getting it to boot, my question would still be what is missing 
for the IPQ8068 support and how it should be correctly integrated. At least
the qsbi7 part seems to be missing (as we found out with your help). Should it 
be added as part of qcom-ipq8064.dtsi (there doesn't seem to be any other
qcom-ipq806*.dtsi for the other CPUs) or a new CPUs specific dtsi?

Kind regards,
	Sven

[-- Attachment #1.2: ap148-testbootup.txt --]
[-- Type: text/plain, Size: 19227 bytes --]


U-Boot 2012.07-EWS370_370_870_871AP-uboot_version:V1.0.0 [Attitude Adjustment 12.09.1,0a49277] (Aug 30 2016 - 17:29:46)

smem ram ptable found: ver: 0 len: 5
DRAM:  1003 MB
NAND:  Manufacturer ID: c2,Device ID: ac
unknown NAND device manufacturer: c2 device: ac
ipq_nand: page_size: 0x800, sector_size: 0x20000, oobsize: 0x70, size: 0x20000000
512 MB
FLASH:  SF: Detected S25FL256S 
ipq_spi: page_size: 0x100, sector_size: 0x10000, size: 0x2000000
32 MB
MMC:   
In:    serial
Out:   serial
Err:   serial
cdp: get part failed for 0:HLOS
cdp: get part failed for rootfs
Net:   board_eth_init:
MAC0 addr:88:dc:96:4a:ba:7a
MAC2 addr:88:dc:96:4a:ba:78
eth0, eth1

Please choose the operation: 
   2: Load Linux System code then write to Flash via TFTP. 
   4: Entr boot command line interface.
   6: Load Linux Kernel then write to Flash via TFTP. 
   7: Load Linux filesystem then write to Flash via TFTP. 
   8: Load Linux uboot then write to Flash via TFTP. 
   9: Load Boot Loader code then write to Flash via TFTP. 
   e: Erase Boot Loader ENV config. 
   ESC: Please input ESC to run Burn-in testing.

\rYou choosed 4

\b\b\b 0 
   
4: System Enter Boot Command Line Interface. 

U-Boot 2012.07-EWS370_370_870_871AP-uboot_version:V1.0.0 [Attitude Adjustment 12.09.1,0a49277] (Aug 30 2016 - 17:29:46)
Hit any key to stop autoboot:  4 \b\b\b 0 
(IPQ) # run lederam
Full duplex link
Link 0 up, Phy_status = bc1c
Port:0 speed 1000Mbps
Using eth0 device
TFTP from server 192.168.2.227; our IP address is 192.168.2.3
Filename 'lede-ipq806x-AP148-initramfs-fit-uImage.itb'.
Load address: 0x44000000
Loading: *\b#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ###########################################
done
Bytes transferred = 6348448 (60dea0 hex)
## Booting kernel from FIT Image at 44000000 ...
   Using 'config@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  ARM OpenWrt Linux-4.9.20
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x440000e4
     Data Size:    6322848 Bytes = 6 MB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x42208000
     Entry Point:  0x42208000
     Hash algo:    crc32
     Hash value:   9ca5b807
     Hash algo:    sha1
     Hash value:   ddb160a441c134fd77314b748544a47f264fe9f4
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Flattened Device Tree from FIT Image at 44000000
   Using 'config@1' configuration
   Trying 'fdt@1' FDT blob subimage
     Description:  ARM OpenWrt AP148 device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x44607cb4
     Data Size:    24262 Bytes = 23.7 KB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   879d68f3
     Hash algo:    sha1
     Hash value:   65384b5867713d8d466d5c427743eadbfada283e
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x44607cb4
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 6f7f7000, end 6f7ffec5 ... OK
Using machid 0x1260 from environment

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.20 (sven@bentobox) (gcc version 5.4.0 (LEDE GCC 5.4.0 r4002-7f3887cd44) ) #0 SMP Wed Apr 19 19:00:52 2017
[    0.000000] CPU: ARMv7 Processor [512f04d0] revision 0 (ARMv7), cr=10c5787d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt:Machine model: Qualcomm IPQ8064/AP148
[    0.000000] OF: fdt:Ignoring memory range 0x40000000 - 0x42000000
[    0.000000] earlycon: msm_serial_dm0 at MMIO 0x16640000 (options '')
[    0.000000] bootconsole [msm_serial_dm0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 253952
[    0.000000] free_area_init_node: node 0, pgdat c0ea8ec0, node_mem_map ef839000
[    0.000000]   Normal zone: 1536 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 196608 pages, LIFO batch:31
[    0.000000]   HighMem zone: 57344 pages, LIFO batch:15
[    0.000000] percpu: Embedded 13 pages/cpu @ef80a000 s20940 r8192 d24116 u53248
[    0.000000] pcpu-alloc: s20940 r8192 d24116 u53248 alloc=13*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 252416
[    0.000000] Kernel command line: loglevel=8 earlycon=msm_serial_dm,0x16640000 console=ttyHSL0,115200
[    0.000000] Bootloader command line not present
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 993644K/1015808K available (3819K kernel code, 245K rwdata, 1224K rodata, 7512K init, 242K bss, 22164K reserved, 0K cma-reserved, 229376K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0208000 - 0xc05c3110   (3821 kB)
[    0.000000]       .init : 0xc0716000 - 0xc0e6c000   (7512 kB)
[    0.000000]       .data : 0xc0e6c000 - 0xc0ea97c0   ( 246 kB)
[    0.000000]        .bss : 0xc0eab000 - 0xc0ee7928   ( 243 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] clocksource: dg_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 305801671480 ns
[    0.000006] sched_clock: 32 bits at 6MHz, resolution 160ns, wraps every 343597383600ns
[    0.009457] Switching to timer-based delay loop, resolution 160ns
[    0.017434] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.50 BogoMIPS (lpj=62500)
[    0.031224] pid_max: default: 32768 minimum: 301
[    0.033499] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.038276] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.045339] CPU: Testing write buffer coherency: ok
[    0.056464] Setting up static identity map for 0x42208280 - 0x422082d8
[    0.059849] Brought up 2 CPUs
[    0.063095] SMP: Total of 2 processors activated (25.00 BogoMIPS).
[    0.066133] CPU: All CPU(s) started in SVC mode.
[    0.082748] VFP support v0.3: implementor 51 architecture 64 part 4d variant 2 rev 0
[    0.084855] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.089307] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.099520] pinctrl core: initialized pinctrl subsystem
[    0.106656] NET: Registered protocol family 16
[    0.110749] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.141528] cpuidle: using governor ladder
[    0.172543] cpuidle: using governor menu
[    0.225303] msm_bus_fabric_init_driver
[    0.226520] usbcore: registered new interface driver usbfs
[    0.228020] usbcore: registered new interface driver hub
[    0.233481] usbcore: registered new device driver usb
[    0.239027] pps_core: LinuxPPS API ver. 1 registered
[    0.243824] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.248891] PTP clock support registered
[    0.260012] clocksource: Switched to clocksource dg_timer
[    0.265968] NET: Registered protocol family 2
[    0.267760] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.271760] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    0.278729] TCP: Hash tables configured (established 8192 bind 8192)
[    0.285130] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.291501] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.297236] NET: Registered protocol family 1
[    0.303774] PCI: CLS 0 bytes, default 64
[    0.489091] No memory allocated for crashlog
[    0.489637] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[    0.503313] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.503351] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.517601] bounce: pool size: 64 pages
[    0.517676] io scheduler noop registered
[    0.521670] io scheduler deadline registered (default)
[    0.528207] 1b500000.pci supply vdda not found, using dummy regulator
[    0.530846] 1b500000.pci supply vdda_phy not found, using dummy regulator
[    0.537247] 1b500000.pci supply vdda_refclk not found, using dummy regulator
[    0.545030] OF: PCI: host bridge /soc/pci@1b500000 ranges:
[    0.551141] OF: PCI:    IO 0x0fe00000..0x0fefffff -> 0x0fe00000
[    0.556326] OF: PCI:   MEM 0x08000000..0x0fdfffff -> 0x08000000
[    0.572233] qcom-pcie 1b500000.pci: PCI host bridge to bus 0000:00
[    0.572285] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.577321] pci_bus 0000:00: root bus resource [io  0x0000-0xfffff] (bus address [0xfe00000-0xfefffff])
[    0.582892] pci_bus 0000:00: root bus resource [mem 0x08000000-0x0fdfffff]
[    0.592167] pci_bus 0000:00: scanning bus
[    0.599057] pci 0000:00:00.0: [17cb:0101] type 01 class 0x060400
[    0.603282] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x3c
[    0.609248] pci 0000:00:00.0: supports D1
[    0.615235] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[    0.619248] pci 0000:00:00.0: PME# disabled
[    0.625464] pci_bus 0000:00: fixups for bus
[    0.628968] PCI: bus0: Fast back to back transfers disabled
[    0.633238] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
[    0.638884] pci_bus 0000:01: scanning bus
[    0.645905] pci 0000:01:00.0: [168c:0040] type 00 class 0x028000
[    0.649770] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
[    0.656168] pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x3c
[    0.663051] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    0.668404] pci 0000:01:00.0: PME# disabled
[    0.675091] pci_bus 0000:01: fixups for bus
[    0.678585] PCI: bus1: Fast back to back transfers disabled
[    0.682774] pci_bus 0000:01: bus scan returning with max=01
[    0.688259] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
[    0.693905] pci_bus 0000:00: bus scan returning with max=01
[    0.701035] pci 0000:00:00.0: fixup irq: got 134
[    0.706042] pci 0000:00:00.0: assigning IRQ 134
[    0.711072] pci 0000:01:00.0: fixup irq: got 134
[    0.715155] pci 0000:01:00.0: assigning IRQ 134
[    0.720088] pci 0000:00:00.0: BAR 8: assigned [mem 0x08000000-0x081fffff]
[    0.724371] pci 0000:01:00.0: BAR 0: assigned [mem 0x08000000-0x081fffff 64bit]
[    0.731444] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.738346] pci 0000:00:00.0:   bridge window [mem 0x08000000-0x081fffff]
[    0.744197] aer 0000:00:00.0:pcie002: service driver aer loaded
[    0.750806] 1b700000.pci supply vdda not found, using dummy regulator
[    0.756068] 1b700000.pci supply vdda_phy not found, using dummy regulator
[    0.762775] 1b700000.pci supply vdda_refclk not found, using dummy regulator
[    0.770411] OF: PCI: host bridge /soc/pci@1b700000 ranges:
[    0.776472] OF: PCI:    IO 0x31e00000..0x31efffff -> 0x31e00000
[    0.781848] OF: PCI:   MEM 0x2e000000..0x31dfffff -> 0x2e000000
[    0.798560] qcom-pcie 1b700000.pci: PCI host bridge to bus 0001:00
[    0.798610] pci_bus 0001:00: root bus resource [bus 00-ff]
[    0.803761] pci_bus 0001:00: root bus resource [mem 0x2e000000-0x31dfffff]
[    0.809112] pci_bus 0001:00: scanning bus
[    0.816088] pci 0001:00:00.0: [17cb:0101] type 01 class 0x060400
[    0.820133] pci 0001:00:00.0: calling pci_fixup_ide_bases+0x0/0x3c
[    0.826262] pci 0001:00:00.0: supports D1
[    0.832205] pci 0001:00:00.0: PME# supported from D0 D1 D3hot
[    0.836198] pci 0001:00:00.0: PME# disabled
[    0.842396] pci_bus 0001:00: fixups for bus
[    0.845920] PCI: bus0: Fast back to back transfers disabled
[    0.850086] pci 0001:00:00.0: scanning [bus 01-01] behind bridge, pass 0
[    0.855914] pci_bus 0001:01: scanning bus
[    0.862835] pci 0001:01:00.0: [168c:0040] type 00 class 0x028000
[    0.866720] pci 0001:01:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
[    0.873124] pci 0001:01:00.0: calling pci_fixup_ide_bases+0x0/0x3c
[    0.879924] pci 0001:01:00.0: PME# supported from D0 D3hot D3cold
[    0.885430] pci 0001:01:00.0: PME# disabled
[    0.892037] pci_bus 0001:01: fixups for bus
[    0.895540] PCI: bus1: Fast back to back transfers disabled
[    0.899647] pci_bus 0001:01: bus scan returning with max=01
[    0.905307] pci 0001:00:00.0: scanning [bus 01-01] behind bridge, pass 1
[    0.910868] pci_bus 0001:00: bus scan returning with max=01
[    0.917766] pcieport 0000:00:00.0: fixup irq: got 134
[    0.923072] pcieport 0000:00:00.0: assigning IRQ 134
[    0.928296] pci 0000:01:00.0: fixup irq: got 134
[    0.933321] pci 0000:01:00.0: assigning IRQ 134
[    0.938026] pci 0001:00:00.0: fixup irq: got 167
[    0.942191] pci 0001:00:00.0: assigning IRQ 167
[    0.947041] pci 0001:01:00.0: fixup irq: got 167
[    0.951281] pci 0001:01:00.0: assigning IRQ 167
[    0.956125] pci 0001:00:00.0: BAR 8: assigned [mem 0x2e000000-0x2e1fffff]
[    0.960429] pci 0001:01:00.0: BAR 0: assigned [mem 0x2e000000-0x2e1fffff 64bit]
[    0.967388] pci 0001:00:00.0: PCI bridge to [bus 01]
[    0.974471] pci 0001:00:00.0:   bridge window [mem 0x2e000000-0x2e1fffff]
[    0.980113] aer 0001:00:00.0:pcie002: service driver aer loaded
[    0.990622] L2 @ QSB rate. Forcing new rate.
[    0.992257] L2 @ 384000 KHz
[    0.996695] CPU0 @ 800000 KHz
[    0.999032] CPU1 @ QSB rate. Forcing new rate.
[    1.002508] CPU1 @ 384000 KHz
[    1.010767] gsbi 16300000.gsbi: GSBI port protocol: 6 crci: 0
[    1.011931] gsbi 1a200000.gsbi: GSBI port protocol: 3 crci: 0
[    1.016407] gsbi 16640000.gsbi: GSBI port protocol: 6 crci: 0
[    1.023244] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    1.028319] msm_serial 16340000.serial: msm_serial: detected port #0
[    1.033604] msm_serial 16340000.serial: uartclk = 25000000
[    1.039809] 16340000.serial: ttyMSM0 at MMIO 0x16340000 (irq = 168, base_baud = 1562500) is a MSM
[    1.045498] msm_serial 16640000.serial: msm_serial: detected port #0
[    1.054138] msm_serial 16640000.serial: uartclk = 7372800
[    1.060553] msm_serial: probe of 16640000.serial failed with error -22
[    1.065747] msm_serial: driver initialized
[    1.085628] loop: module loaded
[    1.088502] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xac
[    1.088542] nand: Macronix MX30UF4G28AB
[    1.094282] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 112
[    1.097760] nand: WARNING: qcom_nand.0: the ECC used on your system is too weak compared to the one required by the NAND chip
[    1.108363] spi_qup 1a280000.spi: IN:block:16, fifo:64, OUT:block:16, fifo:64
[    1.119211] m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
[    1.124167] 12 qcom-smem partitions found on MTD device spi32766.0
[    1.129342] Creating 12 MTD partitions on "spi32766.0":
[    1.135419] 0x000000000000-0x000000020000 : "0:SBL1"
[    1.142363] 0x000000020000-0x000000040000 : "0:MIBIB"
[    1.147473] 0x000000040000-0x000000080000 : "0:SBL2"
[    1.152513] 0x000000080000-0x000000100000 : "0:SBL3"
[    1.157441] 0x000000100000-0x000000110000 : "0:DDRCONFIG"
[    1.162509] 0x000000110000-0x000000120000 : "0:SSD"
[    1.167694] 0x000000120000-0x0000001a0000 : "0:TZ"
[    1.172608] 0x0000001a0000-0x000000220000 : "0:RPM"
[    1.177254] 0x000000220000-0x0000002a0000 : "0:APPSBL"
[    1.182129] 0x0000002a0000-0x0000002e0000 : "0:APPSBLENV"
[    1.187157] 0x0000002e0000-0x000000320000 : "0:ART"
[    1.192770] 0x000000320000-0x0000003a0000 : "0:USERCONFIG"
[    1.198680] libphy: GPIO Bitbanged MDIO: probed
[    1.205953] libphy: Fixed MDIO Bus: probed
[    1.205989] libphy: mdio_driver_register: qca8k
[    1.226234] stmmac - user ID: 0x10, Synopsys ID: 0x37
[    1.226271]  Ring mode enabled
[    1.230354]  DMA HW capability register supported[    1.233221]  Enhanced/Alternate descriptors
[    1.238859] 	Enabled extended descriptors
[    1.241901]  RX Checksum Offload Engine supported
[    1.245984] 	COE Type 2
[    1.250743]  TX Checksum insertion supported
[    1.252926]  Wake-Up On Lan supported
[    1.257443]  Enable RX Mitigation via HW Watchdog Timer
[    1.281167] stmmac - user ID: 0x10, Synopsys ID: 0x37
[    1.281205]  Ring mode enabled
[    1.285200]  DMA HW capability register supported[    1.288155]  Enhanced/Alternate descriptors
[    1.293794] 	Enabled extended descriptors
[    1.296747]  RX Checksum Offload Engine supported
[    1.301056] 	COE Type 2
[    1.305600]  TX Checksum insertion supported
[    1.307860]  Wake-Up On Lan supported
[    1.312473]  Enable RX Mitigation via HW Watchdog Timer
[    1.317293] i2c /dev entries driver
[    1.322456] Calibration not found.
[    1.324453] qcom-tsens 900000.thermal-sensor: tsens calibration failed
[    1.329540] Speed bin: 0
[    1.334500] PVS bin: 1
[    1.339830] cpuidle: enable-method property 'qcom,kpss-acc-v1' found operations
[    1.339943] cpuidle: enable-method property 'qcom,kpss-acc-v1' found operations
[    1.347360] sdhci: Secure Digital Host Controller Interface driver
[    1.353863] sdhci: Copyright(c) Pierre Ossman
[    1.360033] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.367320] NET: Registered protocol family 10
[    1.372710] NET: Registered protocol family 17
[    1.374889] 8021q: 802.1Q VLAN Support v1.8
[    1.379011] Registering SWP/SWPB emulation handler
[    1.401088] qcom_rpm 108000.rpm: RPM firmware 3.0.16777342
[    1.414702] s1a: Bringing 0uV into 1050000-1050000uV
[    1.415226] s1b: Bringing 0uV into 1050000-1050000uV
[    1.419204] s2a: Bringing 0uV into 800000-800000uV
[    1.424288] s2b: Bringing 0uV into 800000-800000uV
[    1.432398] of: dev_pm_opp_of_cpumask_add_table: couldn't find opp table for cpu:0, -19
[    1.433863] of: dev_pm_opp_of_cpumask_add_table: couldn't find opp table for cpu:1, -1

[-- Attachment #1.3: orig-fw-boot.txt.zip --]
[-- Type: application/zip, Size: 21093 bytes --]

[-- Attachment #1.4: 999-ews370.patch --]
[-- Type: text/x-patch, Size: 1481 bytes --]

--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -20,7 +20,7 @@
 	};
 
 	aliases {
-		serial0 = &gsbi4_serial;
+		serial0 = &gsbi7_serial;
 		mdio-gpio0 = &mdio0;
 	};
 
@@ -89,9 +89,9 @@
 
 		gsbi@16300000 {
 			qcom,mode = <GSBI_PROT_I2C_UART>;
-			status = "ok";
+			status = "disabled";
 			serial@16340000 {
-				status = "ok";
+				status = "disabled";
 			};
 
 			/*
@@ -127,6 +127,14 @@
 			};
 		};
 
+		gsbi@16600000 {
+			qcom,mode = <GSBI_PROT_I2C_UART>;
+			status = "ok";
+			serial@16640000 {
+				status = "ok";
+			};
+		};
+
 		sata-phy@1b400000 {
 			status = "ok";
 		};
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -845,6 +845,29 @@
 			};
 		};
 
+		gsbi7: gsbi@16600000 {
+			status = "disabled";
+			compatible = "qcom,gsbi-v1.0.0";
+			cell-index = <7>;
+			reg = <0x16600000 0x100>;
+			clocks = <&gcc GSBI7_H_CLK>;
+			clock-names = "iface";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			syscon-tcsr = <&tcsr>;
+
+			gsbi7_serial: serial@16640000 {
+				compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
+				reg = <0x16640000 0x1000>,
+				      <0x16600000 0x1000>;
+				interrupts = <0 158 0x0>;
+				clocks = <&gcc GSBI7_UART_CLK>, <&gcc GSBI7_H_CLK>;
+				clock-names = "core", "iface";
+				status = "disabled";
+			};
+		};
+
 		sata_phy: sata-phy@1b400000 {
 			compatible = "qcom,ipq806x-sata-phy";
 			reg = <0x1b400000 0x200>;

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IPQ8068 support
  2017-04-26 12:57   ` Sven Eckelmann
@ 2017-04-27 14:26     ` Sricharan R
  0 siblings, 0 replies; 4+ messages in thread
From: Sricharan R @ 2017-04-27 14:26 UTC (permalink / raw)
  To: Sven Eckelmann; +Cc: linux-arm-msm, simon.wunderlich

Hi,

On 4/26/2017 6:27 PM, Sven Eckelmann wrote:
> Thanks for the fast reply,
> 
> now follows a lot of extra information. The interesting part is in the last 
> three paragraphs.
> 
> On Mittwoch, 26. April 2017 16:48:17 CEST Sricharan R wrote:
> [...]
>>> It looks like the support for this CPU was never upstreamed by QCA. A quick 
>>> search in the linux-msm tree in codeaurora also showed only uninteresting 
>>> mentions of this CPU [1]. I already know from Dakota that the upstreaming 
>>> effort from some QCA developers were suddenly stopped. Some of the Dakota 
>>> drivers were therefore waiting in some branch of some repository [2] or 
>>> hanging around in an unfinished state on some mailing list. So maybe there are 
>>> similar things somewhere for the IPQ8068. Can someone maybe point me in the 
>>> right direction?
>>
>> So when you mentioned console not working, the kernel console did not come up ?
> 
> Yes, initially the console was not starting. Then I've disabled the gsbi for 
> the serial and simply used the earlycon with address 0x16640000. Just to check 
> how far it boots with the wrong device tree. (It looked basically like the 
> results from ap148-testbootup.txt with the minor difference that I had 
> gsbi4_serial disabled and no gsbi7_serial).
> 

ok, atleast it means serial was the problem for the basic bootup and good that
the fix is there.

>> Whats the bootloader version that is there ?
> 
> The version shown on this board is
> U-Boot 2012.07-EWS370_370_870_871AP-uboot_version:V1.0.0 [Attitude Adjustment 12.09.1,0a49277] (Aug 30 2016 - 17:29:46)
> 
> 
> My boot commands for the test are:
> 
>     (IPQ) # printenv
>     active_fw=1
>     app_part=0
>     athaddr=00:aa:bb:cc:dd:13
>     baudrate=115200
>     bootargs=loglevel=8 earlycon=msm_serial_dm,0x16640000 console=ttyMSM0,115200
>     bootcmd=bootipq
>     bootdelay=4
>     bundle_ap_mac=00:aa:bb:cc:dd:15
>     country=000
>     ddwrt_sw=0
>     debug=0
>     domain=0
>     ethact=eth0
>     ethaddr=88:DC:96:4A:BA:78
>     fwaddr=00:aa:bb:cc:dd:14
>     hw_id=0101007D
>     hw_ver=0.0.1
>     ipaddr=192.168.2.3
>     language_code=00
>     lederam=tftpboot 0x44000000 lede-ipq806x-AP148-initramfs-fit-uImage.itb && set fdt_high 0x6f800000 && bootm 0x44000000
>     machid=1260
>     oled_on=0
>     op_mode=0
>     pro_id=000
>     serverip=192.168.2.227
>     service_tag=000000000000000
>     sn=163216875
>     snextra=00000000000000000000
>     stderr=serial
>     stdin=serial
>     stdout=serial
>     uboot_ver=1.0.0
>     wanaddr=00:aa:bb:cc:dd:11
>     wlanaddr=00:aa:bb:cc:dd:12
>     (IPQ) # run lederam
> 
>>
>> Given that its ipq8068, not sure which variant of AP148 it is.
> 
> It is definitely not an AP148. I would guess Engenius simply didn't change
> the name when they incorporated all the other changes for their firmware.
> And then it ended up here with the info that it is an AP148-like board
> and I was given the false hope that is should actually be easy to get it
> booting because AP148 is already supported.
> 
>> Atleast i see that
>> AP148 uses uart4 at 0x16340000 as console. Since you are observing that
>> bootloaders have configured console at 0x16640000 which is uart7, is it possible
>> that you can try the below change and see if its only a console issue ?
> [...]
> 
> Already did something similar before (not correctly correct as it seems). It
> still had the problem that the system freezed during the boot (and never
> switched to the actual msm_serial driver as noticed later). Same problem
> was observed with your suggested changes.
> 
> The system basically freezes (or the console freezes) during bootup somewhere 
> near the resource power manager initialization - thus my question about the 
> missing IPQ8068 support. I didn't expected that it is really the rpm power 
> management but without any  knowledge about the IPQ8068, it is rather hard to 
> know and therefore it was better to simply ask about the state of IPQ8068 in 
> upstream Linux.
> 
> 
> 
> I've looked at your version and my older version. Both seemed to show similar 
> problems but it seems that we both had typos in it. You're version had a wrong 
> register value in gsbi@16600000 - mine had some typo under serial@16640000
> 
> I've now used my version (+fix) which is based on the APQ8064 qsbi7 entry.
> This seems to fix the boot and I get an actual serial console without
> earlycon. The ethernet is still dead and fails to reset the DMA engine. Not
> sure how it is currently connected on that CPU anyway.
> 

ok, uart7 is fixing the issue. Not sure why you will have to disable uart4 though.
Apart from that, for the ethernet, looking at the downstream code, we are using
"qcom,ipq806x-gmac" glue layer (which is there in upstream as well). I think that
would enable minimal ethernet support. I am not 100 % sure on this part
though, atleast would have to test it to confirm and see if there are any other
dependencies missing apart from DTS.


> Ok, after now getting it to boot, my question would still be what is missing 
> for the IPQ8068 support and how it should be correctly integrated. At least
> the qsbi7 part seems to be missing (as we found out with your help). Should it 
> be added as part of qcom-ipq8064.dtsi (there doesn't seem to be any other
> qcom-ipq806*.dtsi for the other CPUs) or a new CPUs specific dtsi?

ipq8068 looks to be an variant of ipq8064, so would expect that most of the
ipq8064 should be applicable here as well. For eg, gsbi7 is missing in
ipq8064.dtsi as well. So as you said, should be added to ipq8064 itself.
In the end, i expect that whatever is done for getting features on ipq8064
should work on ipq8068 as well mostly, plus the additional dts board files
needed for the board that you have.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-04-27 14:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-26  8:26 IPQ8068 support Sven Eckelmann
2017-04-26 11:18 ` Sricharan R
2017-04-26 12:57   ` Sven Eckelmann
2017-04-27 14:26     ` Sricharan R

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.