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 -- 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
