Re: [LEDE-DEV] QCA Dakota support

[K.Mani]

Initramfs image boots fine from the RAM.

Regards
Mani

On Thu, Mar 9, 2017 at 9:53 PM, Matthew McClintock
 wrote:
> On Thu, Mar 9, 2017 at 10:15 AM, K.Mani  wrote:
>> Hi Matthew,
>>
>> (IPQ40xx) # smeminfo
>> flash_type: 0x6
>> flash_index:0x0
>> flash_chip_select:  0x0
>> flash_block_size:   0x1
>> flash_density:  0x100
>> partition table offset  0x0
>> No.: Name AttributesStart Size
>>   0: 0:SBL1   0x  0x0  0x4
>>   1: 0:MIBIB  0x001040ff  0x4  0x2
>>   2: 0:QSEE   0x  0x6  0x6
>>   3: 0:CDT0x  0xc  0x1
>>   4: 0:DDRPARAMS  0x  0xd  0x1
>>   5: 0:APPSBLENV  0x  0xe  0x1
>>   6: 0:APPSBL 0x  0xf  0x8
>>   7: 0:ART0x 0x17  0x1
>>   8: 0:HLOS   0x 0x18 0x40
>>   9: rootfs   0x 0x58 0xa8
>>
>> Is this a nand or nor booting board?
>> Don't know.
>>
>> SF: MX25L25635E, it's spi-nor i guess.
>
> Sounds right.
>
>>
>> If i have to flash 'initramfs', should it be on HLOS partition start address?
>>
>> Also attached a old boot log.
>
> No you can just load to memory and boot from there, no need to mess
> with flash at this point.
>
> -M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

On Thu, Mar 9, 2017 at 10:15 AM, K.Mani  wrote:
> Hi Matthew,
>
> (IPQ40xx) # smeminfo
> flash_type: 0x6
> flash_index:0x0
> flash_chip_select:  0x0
> flash_block_size:   0x1
> flash_density:  0x100
> partition table offset  0x0
> No.: Name AttributesStart Size
>   0: 0:SBL1   0x  0x0  0x4
>   1: 0:MIBIB  0x001040ff  0x4  0x2
>   2: 0:QSEE   0x  0x6  0x6
>   3: 0:CDT0x  0xc  0x1
>   4: 0:DDRPARAMS  0x  0xd  0x1
>   5: 0:APPSBLENV  0x  0xe  0x1
>   6: 0:APPSBL 0x  0xf  0x8
>   7: 0:ART0x 0x17  0x1
>   8: 0:HLOS   0x 0x18 0x40
>   9: rootfs   0x 0x58 0xa8
>
> Is this a nand or nor booting board?
> Don't know.
>
> SF: MX25L25635E, it's spi-nor i guess.

Sounds right.

>
> If i have to flash 'initramfs', should it be on HLOS partition start address?
>
> Also attached a old boot log.

No you can just load to memory and boot from there, no need to mess
with flash at this point.

-M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

Can you share a full log? What is the flash_type from smem? Is this a
nand or nor booting board? I suggest using initramfs first until you
get things going.

-M

On Thu, Mar 9, 2017 at 7:11 AM, K.Mani  wrote:
> Hi Matthew,
>
> I built the qsdk, but the device flash failed & bricked.
> and i get the u-boot prompt only.
> Can you suggest me the flashing procedure for ipq40xx?
>
> https://source.codeaurora.org/quic/qsdk/releases/manifest/qstak/tree/?h=release
> --caf_AU_LINUX_QSDK_RELEASE_DAKOTA_CS_TARGET_ALL.3.0.1011.220.xml
>
> flashing ipq40xx:
>  flashed NOR Boot --- hlos & rootfs partition
>
> smeminfo:
> partition table offset  0x0
> No.: Name AttributesStart Size
>   0: 0:SBL1   0x  0x0  0x4
>   1: 0:MIBIB  0x001040ff  0x4  0x2
>   2: 0:QSEE   0x  0x6  0x6
>   3: 0:CDT0x  0xc  0x1
>   4: 0:DDRPARAMS  0x  0xd  0x1
>   5: 0:APPSBLENV  0x  0xe  0x1
>   6: 0:APPSBL 0x  0xf  0x8
>   7: 0:ART0x 0x17  0x1
>   8: 0:HLOS   0x 0x18 0x40
>   9: rootfs   0x 0x58 0xa8
>
>
> Thanks again
> Mani
>
> On Thu, Mar 9, 2017 at 12:32 PM, John Crispin  wrote:
>> Hi Matthew,
>>
>> can you point me at the tree to use on codeaurora ? i am also looking for
>> the AP145 dts file. this is ipq8062 based
>>
>> John
>>
>>
>>
>> On 08/03/17 15:49, Matthew McClintock wrote:
>>>
>>> Most of the support for the SoC should be in place, the various Dakota
>>> boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
>>> device tree's on codeaurora.org to compare the differences from a
>>> supported platform and this variant.
>>>
>>> -M
>>>
>>> On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:

 I have a target board based on IPQ40xx, I want to port LEDE on it.
 Does LEDE has support for the following type:

 Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
 Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
 SF: MX25L25635E

 Thanks
 Mani

 ___
 Lede-dev mailing list
 Lede-dev@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/lede-dev
>>>
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

Most of the QCA stuff should be here:

https://source.codeaurora.org/quic/qsdk

The linux tree should be here:

https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/

Searching for a likely branch, I'll go with 'release/dandelion' in
general though 'release/*' are good candidates since those are the
branches where the internal work get's pushed too eventually. And
you'll find:

https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/tree/arch/arm/boot/dts/qcom-ipq8064-ap145.dts?h=release/dandelion

-M

On Thu, Mar 9, 2017 at 1:02 AM, John Crispin  wrote:
> Hi Matthew,
>
> can you point me at the tree to use on codeaurora ? i am also looking for
> the AP145 dts file. this is ipq8062 based
>
> John
>
>
>
> On 08/03/17 15:49, Matthew McClintock wrote:
>>
>> Most of the support for the SoC should be in place, the various Dakota
>> boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
>> device tree's on codeaurora.org to compare the differences from a
>> supported platform and this variant.
>>
>> -M
>>
>> On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:
>>>
>>> I have a target board based on IPQ40xx, I want to port LEDE on it.
>>> Does LEDE has support for the following type:
>>>
>>> Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
>>> Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
>>> SF: MX25L25635E
>>>
>>> Thanks
>>> Mani
>>>
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[K.Mani]

Hi Matthew,

I built the qsdk, but the device flash failed & bricked.
and i get the u-boot prompt only.
Can you suggest me the flashing procedure for ipq40xx?

https://source.codeaurora.org/quic/qsdk/releases/manifest/qstak/tree/?h=release
--caf_AU_LINUX_QSDK_RELEASE_DAKOTA_CS_TARGET_ALL.3.0.1011.220.xml

flashing ipq40xx:
 flashed NOR Boot --- hlos & rootfs partition

smeminfo:
partition table offset  0x0
No.: Name AttributesStart Size
  0: 0:SBL1   0x  0x0  0x4
  1: 0:MIBIB  0x001040ff  0x4  0x2
  2: 0:QSEE   0x  0x6  0x6
  3: 0:CDT0x  0xc  0x1
  4: 0:DDRPARAMS  0x  0xd  0x1
  5: 0:APPSBLENV  0x  0xe  0x1
  6: 0:APPSBL 0x  0xf  0x8
  7: 0:ART0x 0x17  0x1
  8: 0:HLOS   0x 0x18 0x40
  9: rootfs   0x 0x58 0xa8


Thanks again
Mani

On Thu, Mar 9, 2017 at 12:32 PM, John Crispin  wrote:
> Hi Matthew,
>
> can you point me at the tree to use on codeaurora ? i am also looking for
> the AP145 dts file. this is ipq8062 based
>
> John
>
>
>
> On 08/03/17 15:49, Matthew McClintock wrote:
>>
>> Most of the support for the SoC should be in place, the various Dakota
>> boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
>> device tree's on codeaurora.org to compare the differences from a
>> supported platform and this variant.
>>
>> -M
>>
>> On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:
>>>
>>> I have a target board based on IPQ40xx, I want to port LEDE on it.
>>> Does LEDE has support for the following type:
>>>
>>> Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
>>> Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
>>> SF: MX25L25635E
>>>
>>> Thanks
>>> Mani
>>>
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[John Crispin]

Hi Matthew,

can you point me at the tree to use on codeaurora ? i am also looking 
for the AP145 dts file. this is ipq8062 based


John


On 08/03/17 15:49, Matthew McClintock wrote:

Most of the support for the SoC should be in place, the various Dakota
boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
device tree's on codeaurora.org to compare the differences from a
supported platform and this variant.

-M

On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:

I have a target board based on IPQ40xx, I want to port LEDE on it.
Does LEDE has support for the following type:

Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
SF: MX25L25635E

Thanks
Mani

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] QCA Dakota support

[K.Mani]

I have a target board based on IPQ40xx, I want to port LEDE on it.
Does LEDE has support for the following type:

Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
SF: MX25L25635E

Thanks
Mani

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Mehlis]

Hi Christian,

do you plan to integrate the IPQ40XX support for Asus, ZyXEL and AVM 
from https://github.com/chunkeey/LEDE-IPQ40XX/commits/staging in the 
next days?

I can provide support for Compex WPJ428 afterwards.

Best,
Christian


Am 2017-02-17 19:22, schrieb John Crispin:

On 17/02/2017 17:06, Matthew McClintock wrote:
Cool, still personally missing a Dakota board myself. Maybe I'll get 
one soon.


-M



i used your v4.7-rc for-next tree as basis for the 4.9 support ;)

John


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[John Crispin]

On 17/02/2017 17:06, Matthew McClintock wrote:
> Cool, still personally missing a Dakota board myself. Maybe I'll get one soon.
> 
> -M
> 

i used your v4.7-rc for-next tree as basis for the 4.9 support ;)

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Friday, February 17, 2017 4:29:51 PM CET John Crispin wrote:
> On 17/02/2017 15:46, Christian Lamparter wrote:
> > On Monday, October 31, 2016 10:38:18 PM CET Christian Mehlis wrote:
> >> Hi,
> >>
> >> is there someone working on QCA Dakota support for lede?
> > Heads-up!
> > 
> > 
> > 
> > John has silently integrated Matthew McClintock's patches
> > for the ipq40xx platform into the ipq806x target.
> > 
> > John: Do you have plan for a IPQ40xx subtarget? And what's the plan
> > for the essedma (ethernet), ar40xx/qca8075 (switch),
> > qca-adhoc-bus, scm, ... drivers?
> > 
> > Regards,
> > Christian
> > 
> 
> yes, we are currently fixing support for missing patches.
> dissent1 is working on this.
That's great. Last time I talk to   dissent1 about ath10k
related stuff, he got very defensive. I presume, he had
already plans for his own implementation. 
(That's fine too.)

> there will be a dakota subtarget, i have a ap145 (?)
> reference board on my desk.
Pavel/dissent1, do a you have a public repository with the
subtarget and the rest of the patches and fixes ready?
Because I would like to move the Fritz!Box 4040 there.
I haven't seen any message on the forum/wiki/ML/github, so
where are these updates posted? Or is the plan that it will
just be added to the repository like the platform support
without any change of a discussion?

Regards,
Christian

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[John Crispin]

On 17/02/2017 15:46, Christian Lamparter wrote:
> On Monday, October 31, 2016 10:38:18 PM CET Christian Mehlis wrote:
>> Hi,
>>
>> is there someone working on QCA Dakota support for lede?
> Heads-up!
> 
> 
> 
> John has silently integrated Matthew McClintock's patches
> for the ipq40xx platform into the ipq806x target.
> 
> John: Do you have plan for a IPQ40xx subtarget? And what's the plan
> for the essedma (ethernet), ar40xx/qca8075 (switch),
> qca-adhoc-bus, scm, ... drivers?
> 
> Regards,
> Christian
> 

yes, we are currently fixing support for missing patches. dissent1 is
working on this. there will be a dakota subtarget, i have a ap145 (?)
reference board on my desk

JOhn

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Alexis Green]

Hi Christian,

Thank you for the usb wireless device hint! I had an ath9k-htc dongle
kicking about and I'm seeing memory wastage with that device as well
(albeit slower and only happening while I'm pumping a lot of traffic
through it), so ath10k is likely off the hook for this one. In fact, I
went even farther, checking to see if sending traffic via ethernet
port causes problems and, again, there's memory wastage. Maybe it's a
kernel bug after all. One potential thing to try is to roll kernel to
an older version.

Best regards,

Alexis

On Mon, Nov 28, 2016 at 9:37 AM, Christian Lamparter
 wrote:
> Hello Alexis,
>
> On Sunday, November 27, 2016 12:18:00 PM CET Alexis Green wrote:
>> Could you post .config for your build? I cloned your repo and
>> successfully built and installed an image, but I'm seeing some rather
>> weird behavior.
> I added it, but I don't have any magic values in the .config. I played
> around with adding LPAE for KVM but as it turns out the DMA driver doesn't
> like that.
>
> And there are definitely bugs. If you are looking for support, your best
> option is to ask: Matthew McClintock. Since developed most of the platform
> code while he was working for QCA, so he more familiar with the hardware
> and drivers as I just got this and put a port together for just my hardware...
> It's too bad that he didn't get to keep his board.
>
>> I get kernel oops (null derefrence) in bridge code when I connect a
>> client to WPA2 AP that is bridged. The oops is gone after I removed
>> the following patches (I'm sure it's just one of them, but I have not
>> had a chance  to figure out which one exactly it is).
>> target/linux/generic/patches-4.8/120-bridge_allow_receiption_on_disabled_port.patch
>> target/linux/generic/patches-4.8/640-bridge_no_eap_forward.patch
>> target/linux/generic/patches-4.8/641-bridge_always_accept_eap.patch
> I have to add Alvaro for this (I'm using his experimental 4.8-rc series
> which he is using for his raspberrypi 3 code). As for which one causes
> the issue: I think 640-bridge_no_eap_forward.patch is the one. It looks
> like the following patch in 4.8. changed the way the skb and skb2 works:
>
> commit b35c5f632b630183396a2ea2e2247ff8bbf2c94f
> Author: Nikolay Aleksandrov 
> Date:   Thu Jul 14 06:10:01 2016 +0300
>
> net: bridge: drop skb2/skb0 variables and use a local_rcv boolean [0]
>
> Looking at this commit and the original patch [1]:
> I think we can drop the skb = NULL there (and maybe put the comment
> in front of the local_rcv = true;)
>
>> I'm also seeing rather fast memory leak/wastage when wireless devices
>> are up - takes 10-15 min to run out of memory. I tried using kmemleak,
>> but it doesn't report any suspected leaks. I guess I'll try some
>> tracing next.
> I've added a few new patches to mac80211-package from the current
> wireless-testing.git. If the issue persists, can you report this to
> the ath10k-devel mailing list?
>
> Note: You should check, if it's really the ath10k driver. This can
> be done by plugging in a usb-wifi device and setting it up. If it
> also fails then there's probably another issue with the patchset.
>
> Regards,
> Christian
>
> [0] 
> 
>
> [1] 
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hello Alexis,

On Sunday, November 27, 2016 12:18:00 PM CET Alexis Green wrote:
> Could you post .config for your build? I cloned your repo and
> successfully built and installed an image, but I'm seeing some rather
> weird behavior.
I added it, but I don't have any magic values in the .config. I played
around with adding LPAE for KVM but as it turns out the DMA driver doesn't
like that.

And there are definitely bugs. If you are looking for support, your best
option is to ask: Matthew McClintock. Since developed most of the platform
code while he was working for QCA, so he more familiar with the hardware
and drivers as I just got this and put a port together for just my hardware...
It's too bad that he didn't get to keep his board.  
 
> I get kernel oops (null derefrence) in bridge code when I connect a
> client to WPA2 AP that is bridged. The oops is gone after I removed
> the following patches (I'm sure it's just one of them, but I have not
> had a chance  to figure out which one exactly it is).
> target/linux/generic/patches-4.8/120-bridge_allow_receiption_on_disabled_port.patch
> target/linux/generic/patches-4.8/640-bridge_no_eap_forward.patch
> target/linux/generic/patches-4.8/641-bridge_always_accept_eap.patch
I have to add Alvaro for this (I'm using his experimental 4.8-rc series
which he is using for his raspberrypi 3 code). As for which one causes 
the issue: I think 640-bridge_no_eap_forward.patch is the one. It looks
like the following patch in 4.8. changed the way the skb and skb2 works:

commit b35c5f632b630183396a2ea2e2247ff8bbf2c94f
Author: Nikolay Aleksandrov 
Date:   Thu Jul 14 06:10:01 2016 +0300

net: bridge: drop skb2/skb0 variables and use a local_rcv boolean [0]

Looking at this commit and the original patch [1]: 
I think we can drop the skb = NULL there (and maybe put the comment
in front of the local_rcv = true;)

> I'm also seeing rather fast memory leak/wastage when wireless devices
> are up - takes 10-15 min to run out of memory. I tried using kmemleak,
> but it doesn't report any suspected leaks. I guess I'll try some
> tracing next.
I've added a few new patches to mac80211-package from the current
wireless-testing.git. If the issue persists, can you report this to
the ath10k-devel mailing list? 

Note: You should check, if it's really the ath10k driver. This can
be done by plugging in a usb-wifi device and setting it up. If it
also fails then there's probably another issue with the patchset.

Regards,
Christian

[0] 


[1] 


config-4.8.xz
Description: application/xz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Alexis Green]

Hi Christian,

Could you post .config for your build? I cloned your repo and
successfully built and installed an image, but I'm seeing some rather
weird behavior.

I get kernel oops (null derefrence) in bridge code when I connect a
client to WPA2 AP that is bridged. The oops is gone after I removed
the following patches (I'm sure it's just one of them, but I have not
had a chance  to figure out which one exactly it is).
target/linux/generic/patches-4.8/120-bridge_allow_receiption_on_disabled_port.patch
target/linux/generic/patches-4.8/640-bridge_no_eap_forward.patch
target/linux/generic/patches-4.8/641-bridge_always_accept_eap.patch

I'm also seeing rather fast memory leak/wastage when wireless devices
are up - takes 10-15 min to run out of memory. I tried using kmemleak,
but it doesn't report any suspected leaks. I guess I'll try some
tracing next.

Best regards,

Alexis

On Wed, Nov 23, 2016 at 3:45 PM, Christian Lamparter
 wrote:
> Hi Christian,
>
> On Wednesday, November 23, 2016 10:13:45 PM CET Christian Mehlis wrote:
>> your current staging tree works for me, it generates an itb and a trx
>> file!
>> I added some files to support the Compex board I own:
>> https://github.com/mehlis/source/commits/compex-wpj428
>>
>> Feel free to include some bits in your tree. I had to add dk04-c5
>> support, perhaps you know some other way?
>> My commit is compile tested only.
> I looked at it. But you need to consider what I previously wrote (in the
> second to last mail?):
>
> "the kernel devicetree maintainers frown upon "catch-all" compatible strings 
> [0]."
>
> This means that you have to replace all the generic "qcom,*ipq40xx*" with
> "qcom,*ipq4028*" in your dts and dtsi. Next, you have to add the bindings
> to the kernel platform and driver code, so the device-tree will find the
> driver for hardware definitions in your dtb. (Alternatively, you can
> add the appropriate "qcom,*ipq4019*" binding)
>
>> Please be more precise on the flashing steps. I would like to flash from
>> uboot. I never had a board running ubifs. QCA provides a img file, so
>> I'm a bit lost here.
> I added an entry on how to boot the initramfs on the ASUS. And since that's
> the only IPQ40XX device I have, I can only give "precise informations" for
> it.
>
> For the Asus RT-AC58U, it's very simple. During boot, you have this 1-2 Second
> window to select the following option:
>
> Please choose the operation:
>1: Load System code to SDRAM via TFTP.
>2: Load System code then write to Flash via TFTP.
>3: Boot System code via Flash (default).
>4: Entr boot command line interface.
>7: Load Boot Loader code then write to Flash via Serial.
>9: Load Boot Loader code then write to Flash via TFTP.
>
> And for the initramfs image. you just hit (1). It then continues to ask
> about the IP, tftp server ip and tftp image name (obviously that's the
> lede-ipq40xx-RT-AC58U-initramfs-fit-uImage.itb file in the tftp's server
> directory). and that's it: it automatically boots.
>
> Note: Currently, a working flash image is not implemented. But, you don't
> need to flash the image in order to test it. The initramfs image is simply
> loaded into the SDRAM and it boots from there. (The rootfs is part
> of the initramfs image). Using initramfs is much better for development,
> since you don't need to wait it to flash (The SPINAND is very slow and
> also you'll burn through the NAND quite quickly)
>
> Regards,
> Christian
>
> [0] 
>
> BTW: If you have any questions, you can also find me on google hangouts
> (with the same gmail). Note: If you have an "unusual mail/nick"* there,
> just let me know beforehand via email as I tend to ignore unknown
> requests :-) )
>
> * not something that resembles your name.
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hi Christian,

On Wednesday, November 23, 2016 10:13:45 PM CET Christian Mehlis wrote:
> your current staging tree works for me, it generates an itb and a trx 
> file!
> I added some files to support the Compex board I own:
> https://github.com/mehlis/source/commits/compex-wpj428
> 
> Feel free to include some bits in your tree. I had to add dk04-c5 
> support, perhaps you know some other way?
> My commit is compile tested only.
I looked at it. But you need to consider what I previously wrote (in the
second to last mail?):

"the kernel devicetree maintainers frown upon "catch-all" compatible strings 
[0]."

This means that you have to replace all the generic "qcom,*ipq40xx*" with 
"qcom,*ipq4028*" in your dts and dtsi. Next, you have to add the bindings
to the kernel platform and driver code, so the device-tree will find the
driver for hardware definitions in your dtb. (Alternatively, you can
add the appropriate "qcom,*ipq4019*" binding)

> Please be more precise on the flashing steps. I would like to flash from 
> uboot. I never had a board running ubifs. QCA provides a img file, so 
> I'm a bit lost here.
I added an entry on how to boot the initramfs on the ASUS. And since that's
the only IPQ40XX device I have, I can only give "precise informations" for
it.

For the Asus RT-AC58U, it's very simple. During boot, you have this 1-2 Second
window to select the following option:

Please choose the operation: 
   1: Load System code to SDRAM via TFTP.
   2: Load System code then write to Flash via TFTP.
   3: Boot System code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.

And for the initramfs image. you just hit (1). It then continues to ask
about the IP, tftp server ip and tftp image name (obviously that's the
lede-ipq40xx-RT-AC58U-initramfs-fit-uImage.itb file in the tftp's server
directory). and that's it: it automatically boots.

Note: Currently, a working flash image is not implemented. But, you don't
need to flash the image in order to test it. The initramfs image is simply
loaded into the SDRAM and it boots from there. (The rootfs is part
of the initramfs image). Using initramfs is much better for development,
since you don't need to wait it to flash (The SPINAND is very slow and
also you'll burn through the NAND quite quickly)

Regards,
Christian

[0] 

BTW: If you have any questions, you can also find me on google hangouts
(with the same gmail). Note: If you have an "unusual mail/nick"* there,
just let me know beforehand via email as I tend to ignore unknown 
requests :-) )

* not something that resembles your name.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Mehlis]

Hi Christian,

your current staging tree works for me, it generates an itb and a trx 
file!

I added some files to support the Compex board I own:
https://github.com/mehlis/source/commits/compex-wpj428

Feel free to include some bits in your tree. I had to add dk04-c5 
support, perhaps you know some other way?

My commit is compile tested only.

Please be more precise on the flashing steps. I would like to flash from 
uboot. I never had a board running ubifs. QCA provides a img file, so 
I'm a bit lost here.


Regards,
Christian

Am 2016-11-23 00:58, schrieb Christian Lamparter:

Hello Christian,

On Tuesday, November 22, 2016 11:54:44 PM CET Christian Mehlis wrote:

I updated to your current staging branch 947e53a1 (which includes the
musl update). Now compile stops in a problem with the backports 
package,

which does not match the "new" kernel?!

/home/c/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/linux-ipq40xx/compat-wireless-2016-10-08/backport-include/linux/cred.h:7:44:
error: 'struct nsproxy' has no member named 'user_ns'
  #define current_user_ns() (current->nsproxy->user_ns)

Ah, the quick fix is to "Enable kernel namespaces" and
"User namespaces" in the Global build setting of LEDE's
config. Just check that the following options are present in
the .config file:

CONFIG_KERNEL_NAMESPACES=y
CONFIG_KERNEL_USER_NS=y

This error is caused by the #ifdef in the compat code. As of
commit "cred/userns: define current_user_ns() as a function" [0]
the current_user_ns is no longer a macro in the !CONFIG_USER_NS
case, so the code tries to define it (but this is not needed as
there's a static inline function for it).

Anyway, I put a crude ifdef guard around it for now. Let's see
what else breaks.

We are getting closer:) I hope to add the Compex WPJ428 and the AVM
Fritz!Box 4040 support after the basics are working!

Did someone on the list requested the gpl sources for the Fritz!Box 
4040

so far?

Not that I know, but if you are going on a buying spree, you could
also look into the Zyxel NBG6617 (has no public sources either).
Netgear has published sources for their RBR50 / RBS50 (Orbi) right
here[1].

Regards,
Christian

[0] 
[1]



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hello Christian,

On Tuesday, November 22, 2016 11:54:44 PM CET Christian Mehlis wrote:
> I updated to your current staging branch 947e53a1 (which includes the 
> musl update). Now compile stops in a problem with the backports package, 
> which does not match the "new" kernel?!
> 
> /home/c/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/linux-ipq40xx/compat-wireless-2016-10-08/backport-include/linux/cred.h:7:44:
>  
> error: 'struct nsproxy' has no member named 'user_ns'
>   #define current_user_ns() (current->nsproxy->user_ns)
Ah, the quick fix is to "Enable kernel namespaces" and
"User namespaces" in the Global build setting of LEDE's
config. Just check that the following options are present in
the .config file:

CONFIG_KERNEL_NAMESPACES=y
CONFIG_KERNEL_USER_NS=y

This error is caused by the #ifdef in the compat code. As of
commit "cred/userns: define current_user_ns() as a function" [0]
the current_user_ns is no longer a macro in the !CONFIG_USER_NS
case, so the code tries to define it (but this is not needed as
there's a static inline function for it).

Anyway, I put a crude ifdef guard around it for now. Let's see
what else breaks.
> We are getting closer:) I hope to add the Compex WPJ428 and the AVM 
> Fritz!Box 4040 support after the basics are working!
> 
> Did someone on the list requested the gpl sources for the Fritz!Box 4040 
> so far?
Not that I know, but if you are going on a buying spree, you could
also look into the Zyxel NBG6617 (has no public sources either). 
Netgear has published sources for their RBR50 / RBS50 (Orbi) right 
here[1].

Regards,
Christian
 
[0] 
[1] 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Heiner Kallweit]

Am 22.11.2016 um 23:54 schrieb Christian Mehlis:
> Hi Christian,
> 
> I updated to your current staging branch 947e53a1 (which includes the musl 
> update). Now compile stops in a problem with the backports package, which 
> does not match the "new" kernel?!
> 
> /home/c/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/linux-ipq40xx/compat-wireless-2016-10-08/backport-include/linux/cred.h:7:44:
>  error: 'struct nsproxy' has no member named 'user_ns'
>  #define current_user_ns() (current->nsproxy->user_ns)
> 
I stumbled across this error too when making LEDE work with a recent kernel on 
mpc85xx.
Simply deleting the cred.h from the backports package solved it for me.

> We are getting closer:) I hope to add the Compex WPJ428 and the AVM Fritz!Box 
> 4040 support after the basics are working!
> 
> Did someone on the list requested the gpl sources for the Fritz!Box 4040 so 
> far?
> 
> Regards,
> Christian
> 
> Am 2016-11-22 02:11, schrieb Christian Lamparter:
>> Hello,
>>
>> On Monday, November 21, 2016 2:57:59 PM CET Christian Mehlis wrote:
>>> I found your repo/branch. I think you did a great job! Unfortunately I
>>> can't compile your staging branch:
>>>
>>> [  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
>>> In file included from
>>> /home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
>>> /home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
>>> error: expected identifier before numeric constant
>>>IFF_UP= 1<<0,  /* sysfs */
>>>
>>> Do you see the same problem? Rebasing your staging branch on top of
>>> lede/master did not help.
>>
>> Yes, I did get the same error for netifd (and for ppp later on).
>> After a dirclean these showed up here too. I traced the netifd
>> error down to the following patch:
>> "include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and
>> linux/in6.h" [0]
>>
>> For now, I reverted the change (in the v4.8.10), but I think this
>> needs to be fixed
>> in musl (to that end, I updated to musl.git - and that was enough to fix
>> the ppp error).  Anyway, let me know, if this fixes the compile errors
>> but don't forget run make dirclean.
>>
>> It would be great to add support for a IPQ4028 device too. However, the
>> dtsi files for the IPQ4028 never landed in upstream vanilla?! Also, the
>> kernel devicetree maintainers frown upon "catch-all" compatible strings [1].
>> So, you'll need to replace all the "qcom,ipq40xx" with either "qcom,ipq4028"
>> or stick with the "qcom,ipq4019" for now (you can add it as the second
>> compatible string.) Also note: the qcom,ipq4019.dtsi doesn't have a
>> memory-node. However, this node is essential for booting.
>>
>> Best Regards,
>> Christian
>>
>> [0]
>> 
>> [1] 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Mehlis]

Hi Christian,

I updated to your current staging branch 947e53a1 (which includes the 
musl update). Now compile stops in a problem with the backports package, 
which does not match the "new" kernel?!


/home/c/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/linux-ipq40xx/compat-wireless-2016-10-08/backport-include/linux/cred.h:7:44: 
error: 'struct nsproxy' has no member named 'user_ns'

 #define current_user_ns() (current->nsproxy->user_ns)

We are getting closer:) I hope to add the Compex WPJ428 and the AVM 
Fritz!Box 4040 support after the basics are working!


Did someone on the list requested the gpl sources for the Fritz!Box 4040 
so far?


Regards,
Christian

Am 2016-11-22 02:11, schrieb Christian Lamparter:

Hello,

On Monday, November 21, 2016 2:57:59 PM CET Christian Mehlis wrote:

I found your repo/branch. I think you did a great job! Unfortunately I
can't compile your staging branch:

[  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
In file included from
/home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
/home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
error: expected identifier before numeric constant
   IFF_UP= 1<<0,  /* sysfs */

Do you see the same problem? Rebasing your staging branch on top of
lede/master did not help.


Yes, I did get the same error for netifd (and for ppp later on).
After a dirclean these showed up here too. I traced the netifd
error down to the following patch:
"include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and
linux/in6.h" [0]

For now, I reverted the change (in the v4.8.10), but I think this
needs to be fixed
in musl (to that end, I updated to musl.git - and that was enough to 
fix

the ppp error).  Anyway, let me know, if this fixes the compile errors
but don't forget run make dirclean.

It would be great to add support for a IPQ4028 device too. However, the
dtsi files for the IPQ4028 never landed in upstream vanilla?! Also, the
kernel devicetree maintainers frown upon "catch-all" compatible strings 
[1].
So, you'll need to replace all the "qcom,ipq40xx" with either 
"qcom,ipq4028"

or stick with the "qcom,ipq4019" for now (you can add it as the second
compatible string.) Also note: the qcom,ipq4019.dtsi doesn't have a
memory-node. However, this node is essential for booting.

Best Regards,
Christian

[0]

[1] 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

On Mon, Nov 21, 2016 at 7:11 PM, Christian Lamparter
 wrote:
> On Monday, November 21, 2016 2:57:59 PM CET Christian Mehlis wrote:
>> I found your repo/branch. I think you did a great job! Unfortunately I
>> can't compile your staging branch:
>>
>> [  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
>> In file included from
>> /home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
>> /home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
>> error: expected identifier before numeric constant
>>IFF_UP= 1<<0,  /* sysfs */
>>
>> Do you see the same problem? Rebasing your staging branch on top of
>> lede/master did not help.
>
> Yes, I did get the same error for netifd (and for ppp later on).
> After a dirclean these showed up here too. I traced the netifd
> error down to the following patch:
> "include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and 
> linux/in6.h" [0]
>
> For now, I reverted the change (in the v4.8.10), but I think this needs to be 
> fixed
> in musl (to that end, I updated to musl.git - and that was enough to fix
> the ppp error).  Anyway, let me know, if this fixes the compile errors
> but don't forget run make dirclean.
>
> It would be great to add support for a IPQ4028 device too. However, the
> dtsi files for the IPQ4028 never landed in upstream vanilla?! Also, the
> kernel devicetree maintainers frown upon "catch-all" compatible strings [1].
> So, you'll need to replace all the "qcom,ipq40xx" with either "qcom,ipq4028"
> or stick with the "qcom,ipq4019" for now (you can add it as the second
> compatible string.) Also note: the qcom,ipq4019.dtsi doesn't have a
> memory-node. However, this node is essential for booting.

Also note, I don't have a board as QCA did not want to give me one as
I was exiting.

-M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hello,

On Monday, November 21, 2016 2:57:59 PM CET Christian Mehlis wrote:
> I found your repo/branch. I think you did a great job! Unfortunately I 
> can't compile your staging branch:
> 
> [  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
> In file included from 
> /home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
> /home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
>  
> error: expected identifier before numeric constant
>IFF_UP= 1<<0,  /* sysfs */
> 
> Do you see the same problem? Rebasing your staging branch on top of 
> lede/master did not help.

Yes, I did get the same error for netifd (and for ppp later on).
After a dirclean these showed up here too. I traced the netifd
error down to the following patch:
"include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and 
linux/in6.h" [0]

For now, I reverted the change (in the v4.8.10), but I think this needs to be 
fixed
in musl (to that end, I updated to musl.git - and that was enough to fix
the ppp error).  Anyway, let me know, if this fixes the compile errors
but don't forget run make dirclean.

It would be great to add support for a IPQ4028 device too. However, the
dtsi files for the IPQ4028 never landed in upstream vanilla?! Also, the
kernel devicetree maintainers frown upon "catch-all" compatible strings [1].
So, you'll need to replace all the "qcom,ipq40xx" with either "qcom,ipq4028"
or stick with the "qcom,ipq4019" for now (you can add it as the second
compatible string.) Also note: the qcom,ipq4019.dtsi doesn't have a
memory-node. However, this node is essential for booting.

Best Regards,
Christian

[0] 

[1] 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

That doesn't seem related to my changes. I was building with OpenWrt
CC release I believe and a really stripped down rootfs/kernel for
bring up. Maybe look for newer GCC fixups?

-M

On Mon, Nov 21, 2016 at 7:57 AM, Christian Mehlis  wrote:
> Hi Christian,
>
> I found your repo/branch. I think you did a great job! Unfortunately I can't
> compile your staging branch:
>
> [  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
> In file included from
> /home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
> /home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
> error: expected identifier before numeric constant
>   IFF_UP= 1<<0,  /* sysfs */
>
> Do you see the same problem? Rebasing your staging branch on top of
> lede/master did not help.
>
> Best Regards,
> Christian
>
>
> Am 2016-11-14 07:04, schrieb Christian Lamparter:
>>
>> Hello,
>>
>> On Saturday, November 12, 2016 12:03:54 AM CET Christian Mehlis wrote:
>>>
>>> I took your patches to my tree. They are for Linux 4.7, so I tried to
>>> make Lede build with that Linux version.
>>> I ran into some trouble with musl+netifd (fixed it). Now compat-wireless
>>> seems to expect an older Kernel:
>>>
>>> compat-wireless-2016-10-08/backport-include/linux/netdevice.h:337:5:
>>> error: 'struct net_device' has no member named 'trans_start'
>>>dev->trans_start = jiffies;
>>>
>>> The member was kicked in 4.7.
>>>
>>> In case someone is willing to help, I'm open for code.
>>
>>
>> I also got a IPQ40XX device. It's a Asus RT-AC58U. I played around with
>> it. The kernel is 4.8.6 (Since 4.7 is EOL).
>>
>> The initramfs image boots. serial and SPI(nor and nand) is working.
>> ath10k needs caldata (I'm not familiar with the new pre-cal and cal
>> data stuff). However no ethernet, no usb3, no cpufreq, no leds,
>> no crypto, ... (yet).
>>
>> Are you still interested?
>> https://github.com/chunkeey/LEDE-AC58U
>>
>> Regards,
>> Christian
>>
>> ---
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Linux version 4.8.6 (chuck@debian64) (gcc version 5.4.0
>> (LEDE GCC 5.4.0 r2109+1) ) #0 SMP Mon Nov 14 04:32:17 2016
>> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
>> cr=10c5387d
>> [0.00] CPU: div instructions available: patching division code
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [0.00] OF: fdt:Machine model: Asus AC58U
>> [0.00] Memory policy: Data cache writealloc
>> [0.00] On node 0 totalpages: 32256
>> [0.00] free_area_init_node: node 0, pgdat c092f340,
>> node_mem_map c7cf9000
>> [0.00]   Normal zone: 256 pages used for memmap
>> [0.00]   Normal zone: 0 pages reserved
>> [0.00]   Normal zone: 32256 pages, LIFO batch:7
>> [0.00] percpu: Embedded 13 pages/cpu @c7cae000 s20608 r8192
>> d24448 u53248
>> [0.00] pcpu-alloc: s20608 r8192 d24448 u53248 alloc=13*4096
>> [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 32000
>> [0.00] Kernel command line: root_rfs=0x
>> flash_type=norplusnand
>> [0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
>> [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536
>> bytes)
>> [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768
>> bytes)
>> [0.00] Memory: 119596K/129024K available (43K kernel code,
>> 227K rwdata, 752K rodata, 2480K init, 290K bss, 9428K reserved, 0K
>> cma-reserved, 0K highmem)
>> [0.00] Virtual kernel memory layout:
>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>> [0.00] vmalloc : 0xc880 - 0xff80   ( 880 MB)
>> [0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
>> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
>> [0.00]   .text : 0xc0208000 - 0xc0213198   (  45 kB)
>> [0.00]   .init : 0xc06be000 - 0xc092a000   (2480 kB)
>> [0.00]   .data : 0xc092a000 - 0xc0962dcc   ( 228 kB)
>> [0.00].bss : 0xc0964000 - 0xc09aca7c   ( 291 kB)
>> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
>> [0.00] Hierarchical RCU implementation.
>> [0.00] NR_IRQS:16 nr_irqs:16 16
>> [0.00] arm_arch_timer: Architected cp15 timer(s) running at
>> 48.00MHz (virt).
>> [0.00] clocksource: arch_sys_counter: mask: 0xff
>> max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
>> [0.08] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps
>> every 4398046511096ns
>> [0.22] Switching to timer-based 

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hello,

On Saturday, November 12, 2016 12:03:54 AM CET Christian Mehlis wrote:
> I took your patches to my tree. They are for Linux 4.7, so I tried to 
> make Lede build with that Linux version.
> I ran into some trouble with musl+netifd (fixed it). Now compat-wireless 
> seems to expect an older Kernel:
> 
> compat-wireless-2016-10-08/backport-include/linux/netdevice.h:337:5: 
> error: 'struct net_device' has no member named 'trans_start'
>dev->trans_start = jiffies;
> 
> The member was kicked in 4.7.
> 
> In case someone is willing to help, I'm open for code.

I also got a IPQ40XX device. It's a Asus RT-AC58U. I played around with
it. The kernel is 4.8.6 (Since 4.7 is EOL).

The initramfs image boots. serial and SPI(nor and nand) is working.
ath10k needs caldata (I'm not familiar with the new pre-cal and cal
data stuff). However no ethernet, no usb3, no cpufreq, no leds,
no crypto, ... (yet).

Are you still interested?
https://github.com/chunkeey/LEDE-AC58U

Regards,
Christian

---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.8.6 (chuck@debian64) (gcc version 5.4.0 (LEDE 
GCC 5.4.0 r2109+1) ) #0 SMP Mon Nov 14 04:32:17 2016
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt:Machine model: Asus AC58U
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 32256
[0.00] free_area_init_node: node 0, pgdat c092f340, node_mem_map 
c7cf9000
[0.00]   Normal zone: 256 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 32256 pages, LIFO batch:7
[0.00] percpu: Embedded 13 pages/cpu @c7cae000 s20608 r8192 d24448 
u53248
[0.00] pcpu-alloc: s20608 r8192 d24448 u53248 alloc=13*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32000
[0.00] Kernel command line: root_rfs=0x flash_type=norplusnand
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 119596K/129024K available (43K kernel code, 227K rwdata, 
752K rodata, 2480K init, 290K bss, 9428K reserved, 0K cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc880 - 0xff80   ( 880 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0208000 - 0xc0213198   (  45 kB)
[0.00]   .init : 0xc06be000 - 0xc092a000   (2480 kB)
[0.00]   .data : 0xc092a000 - 0xc0962dcc   ( 228 kB)
[0.00].bss : 0xc0964000 - 0xc09aca7c   ( 291 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] arm_arch_timer: Architected cp15 timer(s) running at 48.00MHz 
(virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
[0.08] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps every 
4398046511096ns
[0.22] Switching to timer-based delay loop, resolution 20ns
[0.000107] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 96.00 BogoMIPS (lpj=48)
[0.000126] pid_max: default: 32768 minimum: 301
[0.000219] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.000234] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.000870] CPU: Testing write buffer coherency: ok
[0.001219] Setting up static identity map for 0x80208280 - 0x802082d8
[0.005322] Brought up 4 CPUs
[0.005343] SMP: Total of 4 processors activated (384.00 BogoMIPS).
[0.005352] CPU: All CPU(s) started in SVC mode.
...
[8.686004] ath10k_ahb a00.wifi: Direct firmware load for 
ath10k/pre-cal-ahb-a00.wifi.bin failed with error -2
[8.686053] ath10k_ahb a00.wifi: Falling back to user helper
[8.723599] firmware ath10k!pre-cal-ahb-a00.wifi.bin: 
firmware_loading_store: map pages failed
[8.723936] ath10k_ahb a00.wifi: Direct firmware load for 
ath10k/cal-ahb-a00.wifi.bin failed with error -2
[8.731569] ath10k_ahb a00.wifi: Falling back to user helper
[8.780565] ath10k_ahb a00.wifi: qca4019 hw1.0 target 0x0100 chip_id 
0x003b00ff sub :
[

Re: [LEDE-DEV] QCA Dakota support

[Ben Greear]

Have you tried the ath10k-ct driver?  I think it should at least
support the radios if you put on the right firmware.  Not sure about the rest 
of the board.

Thanks,
Ben

On 11/12/2016 09:42 AM, Matthew McClintock wrote:

On Fri, Nov 11, 2016 at 5:03 PM, Christian Mehlis  wrote:

Hi Matthew,

I took your patches to my tree. They are for Linux 4.7, so I tried to make
Lede build with that Linux version.
I ran into some trouble with musl+netifd (fixed it). Now compat-wireless
seems to expect an older Kernel:

compat-wireless-2016-10-08/backport-include/linux/netdevice.h:337:5: error:
'struct net_device' has no member named 'trans_start'
   dev->trans_start = jiffies;

The member was kicked in 4.7.

In case someone is willing to help, I'm open for code.


I can't help much, since QCA declined to give me a board. Did you try
regenerating the compat-wireless against the newer kernel? I never did
much on the wifi side, was alway doing everything else.

If you compare the ChromeOS tree I shared it's a backport to 3.18, so
some subset of patches in that list will backport to 4.4 pretty
easily.

-M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

On Fri, Nov 11, 2016 at 5:03 PM, Christian Mehlis  wrote:
> Hi Matthew,
>
> I took your patches to my tree. They are for Linux 4.7, so I tried to make
> Lede build with that Linux version.
> I ran into some trouble with musl+netifd (fixed it). Now compat-wireless
> seems to expect an older Kernel:
>
> compat-wireless-2016-10-08/backport-include/linux/netdevice.h:337:5: error:
> 'struct net_device' has no member named 'trans_start'
>   dev->trans_start = jiffies;
>
> The member was kicked in 4.7.
>
> In case someone is willing to help, I'm open for code.

I can't help much, since QCA declined to give me a board. Did you try
regenerating the compat-wireless against the newer kernel? I never did
much on the wifi side, was alway doing everything else.

If you compare the ChromeOS tree I shared it's a backport to 3.18, so
some subset of patches in that list will backport to 4.4 pretty
easily.

-M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Mehlis]

Hi Matthew,

I took your patches to my tree. They are for Linux 4.7, so I tried to 
make Lede build with that Linux version.
I ran into some trouble with musl+netifd (fixed it). Now compat-wireless 
seems to expect an older Kernel:


compat-wireless-2016-10-08/backport-include/linux/netdevice.h:337:5: 
error: 'struct net_device' has no member named 'trans_start'

  dev->trans_start = jiffies;

The member was kicked in 4.7.

In case someone is willing to help, I'm open for code.

-> It's unclear to me how to generate a config-4.7 from config-4.4 and 
store it. build system asks for the new flags every time.

-> why does netifd not handle musl c properly or vice versa?
 include/linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
 struct in6_addr {

-> how to disable compat-wireless and exclude it from build?

Code: https://github.com/mehlis/source/commits/ipq40xx

Regards,
Christian

Am 2016-11-08 05:05, schrieb Matthew McClintock:
On Mon, Nov 7, 2016 at 3:49 PM, Christian Mehlis  
wrote:

Dakota kernel support done by QCA is public here:
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=release/collard_cc_cs=2e6acfb58dceee5baf746a9ed37a8efbad8a7626


For a little bit cleaner tree's take a look here:

https://source.codeaurora.org/quic/qsdk/mmcclint-qca/
https://chromium-review.googlesource.com/#/q/status:merged+project:chromiumos/third_party/kernel+branch:chromeos-3.18

-M


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

On Mon, Nov 7, 2016 at 3:49 PM, Christian Mehlis  wrote:
> Dakota kernel support done by QCA is public here:
> https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=release/collard_cc_cs=2e6acfb58dceee5baf746a9ed37a8efbad8a7626

For a little bit cleaner tree's take a look here:

https://source.codeaurora.org/quic/qsdk/mmcclint-qca/
https://chromium-review.googlesource.com/#/q/status:merged+project:chromiumos/third_party/kernel+branch:chromeos-3.18

-M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Mehlis]

Hi Again,

I received multiple private mails in the last days, please always 
include this mailing list on reply!


Current situation from my perspective:
Dakota kernel support done by QCA is public here: 
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=release/collard_cc_cs=2e6acfb58dceee5baf746a9ed37a8efbad8a7626


This branch contains all code and drivers to build a Linux kernel for 
Dakota CPUs.
But this kernel tree is based on 3.14 and has more that 2400 commits on 
top. Including kernel updates, other HW support and so on.


-> someone needs to find the relevant parts (device drivers?) and 
extract and rebase them to 4.4 (current LEDE ipq Linux kernel version).
---> I have no idea how to do that in a way that we can extract the 
newest bits, but not lose relevant parts at the same time, input/advice 
from others needed!


With that kernel support we can build LEDE build targets, I started here 
https://github.com/lede-project/source/compare/master...mehlis:ipq40xx 
but this is more or less a copy on ipq806x with dk01 and dk04 dts files, 
no real support.


Feedback and ideas are welcome!

Christian

Reminder: I'm doing this in my spare time :)


Am 2016-10-31 22:38, schrieb Christian Mehlis:

Hi,

is there someone working on QCA Dakota support for lede?

Linux 4.4 already has support for the dakota ref board:
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts

I received a Compex WPJ428 board containing QSDK (which is in fact
openwrt based) and I want to make lede work on it.
Unfortunately there is no support for DK01 QCA refboard in lede, I
think WPJ428 is almost the same.

Regards,
Christian


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] QCA Dakota support

[Christian Mehlis]

Hi,

is there someone working on QCA Dakota support for lede?

Linux 4.4 already has support for the dakota ref board: 
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts


I received a Compex WPJ428 board containing QSDK (which is in fact 
openwrt based) and I want to make lede work on it.
Unfortunately there is no support for DK01 QCA refboard in lede, I think 
WPJ428 is almost the same.


Regards,
Christian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev