All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sricharan R <sricharan@codeaurora.org>
To: Sven Eckelmann <sven.eckelmann@openmesh.com>,
	linux-arm-msm@vger.kernel.org
Cc: simon.wunderlich@openmesh.com
Subject: Re: IPQ8068 support
Date: Wed, 26 Apr 2017 16:48:17 +0530	[thread overview]
Message-ID: <cb0f49b7-511b-e03f-689a-42744b476b90@codeaurora.org> (raw)
In-Reply-To: <2798304.oiRXTY8cqN@bentobox>

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

  reply	other threads:[~2017-04-26 11:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26  8:26 IPQ8068 support Sven Eckelmann
2017-04-26 11:18 ` Sricharan R [this message]
2017-04-26 12:57   ` Sven Eckelmann
2017-04-27 14:26     ` Sricharan R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cb0f49b7-511b-e03f-689a-42744b476b90@codeaurora.org \
    --to=sricharan@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=simon.wunderlich@openmesh.com \
    --cc=sven.eckelmann@openmesh.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.