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