[LEDE-DEV] QCA Dakota support

Alexis Green alexis at cessp.it
Sun Nov 27 12:18:00 PST 2016


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
<chunkeey at googlemail.com> 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] <https://patchwork.kernel.org/patch/7062591/>
>
> 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



More information about the Lede-dev mailing list