Re: [LEDE-DEV] ipq806x Netgear R7500 uboot

2018-01-17 Thread Matthew McClintock 
On Wed, Jan 17, 2018 at 4:28 AM, Thomas Reifferscheid
 wrote:
> Hi, I've lost my original uboot environment settings and would like to ask
> for your help.
> Since it's been a while from when I was playing with the hardware the uboot
> env is all messed up and I'd like to start over from scratch.
>
> Would someone please send me "env print" from within the bootloader from any
> ipq806x, preferrably Netgear R7500 but anything close would probably do.

Does resetting it to default not work? What are you trying to do? Most
IPQ boards have a custom u-boot command callde bootipq that will boot
the board from some semi-default flash configuration assuming all
other things are sane.

-M

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

Re: [LEDE-DEV] [PATCH 1/4] firmware: ath10k-firmware: update QCA4019 firmware to 10.4-3.2.1-00058

2017-12-21 Thread Matthew McClintock 
On Thu, Dec 21, 2017 at 11:36 AM, Roman Yeryomin <ro...@advem.lv> wrote:
> On 2017-12-20 23:35, Matthew McClintock wrote:
>>
>> On Tue, Nov 21, 2017 at 9:06 AM, Roman Yeryomin <ro...@advem.lv> wrote:
>>>>>
>>>>>
>>>>> 2. the pre-cal-ahb-a80.wifi.bin and pre-cal-ahb-a00.wifi.bin
>>>>>don't get loaded or the pre-cal* data is
>>>>> shifted/trimmed/mangled/bad.
>>>>>
>>>>> For 2. you should check if the firmware hotplug 11-ath10k-caldata
>>>>> script
>>>>> is correctly extracting the pre-cal from the "ART" Partition of your
>>>>> device
>>>
>>>
>>>
>>> I would first look at this ^^^
>>
>>
>> Hello Roman,
>>
>> Do you know what the bmi-board-id is for your dk01 you were testing?
>
>
> Yes, it's 17, and board file is included in official firmware from
> ath10k-firmware repository, so it works out of the box.

Yea, I appear to have boards without the board id properly written. So
I'm a little confused.

-M

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

Re: [LEDE-DEV] LEDE layerscape hangs with squash rootfs on QSPI flash

2017-12-20 Thread Matthew McClintock 
On Sun, Dec 17, 2017 at 9:20 PM, Y.b. Lu  wrote:
> Hi,
>
> (Resent the email since HTML format email was rejected by mailing list...)
>
> Has anyone seen below issue when LEDE started up. The system would hang when 
> created jffs2 area.
> This issue occurred on QSPI flash on layerscape like ls1046ardb, but Nor 
> flash worked fine with same rootfs like ls1043ardb.
>
> [2.298409] fsl-quadspi 155.quadspi: s25fl512s (65536 Kbytes)
> [2.304658] 9 cmdlinepart partitions found on MTD device 155.quadspi
> [2.311674] Creating 9 MTD partitions on "155.quadspi":
> [2.317676] 0x-0x0010 : "rcw"
> [2.327552] 0x0010-0x0030 : "u-boot"
> [2.337822] 0x0030-0x0040 : "u-boot-env"
> [2.348446] 0x0040-0x0090 : "reserved-1"
> [2.359001] 0x0090-0x0094 : "fman"
> [2.369017] 0x0094-0x00f0 : "reserved-2"
> [2.379597] 0x00f0-0x0100 : "dtb"
> [2.389523] 0x0100-0x0200 : "kernel"
> [2.399723] 0x0200-0x0400 : "rootfs"
> [2.409917] mtd: device 8 (rootfs) set to be root filesystem
>
> Actually jffs2 rootfs worked fine on QSPI flash, but we don't know why it 
> failed with LEDE squashfs when create jffs2 area.
> Any suggestion to find out the root casue? Or any config may casue this issue?
>
> Appreciate your help.

Do you have a more complete log?

-M

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

Re: [LEDE-DEV] [PATCH 1/4] firmware: ath10k-firmware: update QCA4019 firmware to 10.4-3.2.1-00058

2017-11-20 Thread Matthew McClintock 
On Mon, Nov 20, 2017 at 2:59 PM, Christian Lamparter <chunk...@gmail.com> wrote:
> On Monday, November 20, 2017 11:23:18 AM CET Matthew McClintock wrote:
>> On Mon, Nov 20, 2017 at 10:53 AM, Christian Lamparter
>> <chunk...@gmail.com> wrote:
>> > On Monday, November 20, 2017 9:45:28 AM CET Matthew McClintock wrote:
>> >> Did you get ath10k working on ipq4019?
>> >
>> > Yes, I managed to upstream the wifi dts changes some time ago and they
>> > all have been accepted. In fact the new 4.14 does ships with those.
>> >
>> > https://patchwork.kernel.org/patch/9858197/
>> >
>> > How is your upstreaming progess going?
>> >
>> >> I'm having issues with the board data files? I've never messed with this.
>> >
>> > What do you want to know?
>> >
>> > I'm assuming that you are looking for a way to package the two board.bin
>> > (2GHz and 5GHz) into a board-2.bin. You can just use the ath10k-bdencoder
>> > tool from the <https://github.com/qca/qca-swiss-army-knife>
>> >
>> > Note: ath10k-bdencoder can also unpack existing board-2.bin that are
>> > currently shipped with any of the the ipq-wifi packages. So the fastest way
>> > would be to unpack a existing board-2.bin (this will create a .json file 
>> > and
>> > the individual .bins). Then you just have to replace the two board.bin 
>> > files
>> > and repack it (the repack process will need the created .json file again.)
>> >
>> > If this isn't what you are looking for, you might find it in the
>> > "firmware: add custom IPQ wifi board definitions" commit message.
>> >
>>
>> Caveat: I'm using an older version of ath10k at the moment, but
> This is can be a big caveat. Depending on how "old" the ath10k /
> compat-wireless / backports really is. On OpenWRT/older LEDE versions
> QCA4019 was broken by a patch: 936-ath10k_skip_otp_check.patch.
>
> You should definitely go for a recent version.

I'm stuck on some other backport for the time being, will sort out
LEDE after I get a complete grasp. Actually this is all good info for
getting upstream working.

>
>> I think it's complaining that it can't find the right board info from
>> the board-2.bin file which is just multiple board files wrapped up
>> together?
>>
>> [  233.761660] ath10k_ahb a00.wifi: failed to fetch board data for
>> bus=ahb,vendor=,device=,subsystem-vendor=,subsystem-device=
>> from ath10k/QCA4019/hw1.0/board-2.bin
> The device identifcation doesn't work.
>
> The driver is thinking it has a non-sensical "ahb pci(e)" device.
> Just look at the fact that the driver is looking for "bus=ahb" but also
> "vendor=0,device=0...,subsystem...=...,..."(which is used to identify
> pcie devices). If it was looking for a bmi device, the board search string
> would look something like "bus=ahb,bmi-chip-id=0,bmi-board-id=16"

I think this is the root of the problem.

> I can only guess what's really going on, since this is such a short extract.
>
> But there at least two likely scenarios:
> 1. 936-ath10k_skip_otp_check.patch is present / ath10k is too old

This is not present.

>
> 2. the pre-cal-ahb-a80.wifi.bin and pre-cal-ahb-a00.wifi.bin
>don't get loaded or the pre-cal* data is shifted/trimmed/mangled/bad.
>
> For 2. you should check if the firmware hotplug 11-ath10k-caldata script
> is correctly extracting the pre-cal from the "ART" Partition of your device
> to /lib/firmware/ath10k. I posted one of the RT-AC58U's pre-cal files on the
> linux-wireless / ath10k-devel mailing-list.
> If you need something to compare to, look for the cal-file attachment:
> <https://www.mail-archive.com/ath10k@lists.infradead.org/msg05911.html>
>
> (Note: Netgear used to ship the source from which these .bin files are
> created by the calibration utility in thier GPL source of the R7800 / D7800)
>
>> This is the first pass, it moves onto board.bin but still fails (the
>> file is not present).
>>
>> Where is a description of the which board.bin files to use for which
>> radios? Where does this info come from? Somewhere in the radio or OTP?
> I don't think this was actually documented anywhere officially by
> Qualcomm Atheros. The best resource I currently know of, is this write-up
> from Sven Eckelmann:
> <http://lists.infradead.org/pipermail/ath10k/2017-January/009025.html>
>
> followed by the response from Adrian Chadd (he used to work for QCA, but
> no longer does):
> <http://lists.infradead.org/pipermail/ath10k/20

Re: [LEDE-DEV] [PATCH 1/4] firmware: ath10k-firmware: update QCA4019 firmware to 10.4-3.2.1-00058

2017-11-20 Thread Matthew McClintock 
On Mon, Nov 20, 2017 at 10:53 AM, Christian Lamparter
<chunk...@gmail.com> wrote:
> On Monday, November 20, 2017 9:45:28 AM CET Matthew McClintock wrote:
>> Did you get ath10k working on ipq4019?
>
> Yes, I managed to upstream the wifi dts changes some time ago and they
> all have been accepted. In fact the new 4.14 does ships with those.
>
> https://patchwork.kernel.org/patch/9858197/
>
> How is your upstreaming progess going?
>
>> I'm having issues with the board data files? I've never messed with this.
>
> What do you want to know?
>
> I'm assuming that you are looking for a way to package the two board.bin
> (2GHz and 5GHz) into a board-2.bin. You can just use the ath10k-bdencoder
> tool from the <https://github.com/qca/qca-swiss-army-knife>
>
> Note: ath10k-bdencoder can also unpack existing board-2.bin that are
> currently shipped with any of the the ipq-wifi packages. So the fastest way
> would be to unpack a existing board-2.bin (this will create a .json file and
> the individual .bins). Then you just have to replace the two board.bin files
> and repack it (the repack process will need the created .json file again.)
>
> If this isn't what you are looking for, you might find it in the
> "firmware: add custom IPQ wifi board definitions" commit message.
>

Caveat: I'm using an older version of ath10k at the moment, but

I think it's complaining that it can't find the right board info from
the board-2.bin file which is just multiple board files wrapped up
together?

[  233.761660] ath10k_ahb a00.wifi: failed to fetch board data for
bus=ahb,vendor=,device=,subsystem-vendor=,subsystem-device=
from ath10k/QCA4019/hw1.0/board-2.bin

This is the first pass, it moves onto board.bin but still fails (the
file is not present).

Where is a description of the which board.bin files to use for which
radios? Where does this info come from? Somewhere in the radio or OTP?

Interestingly, PCI is complaining too:

[  236.712965] ath10k_pci :01:00.0: failed to fetch board data for
bus=pci,bmi-chip-id=0,bmi-board-id=19 from
ath10k/QCA9888/hw2.0/board-2.bin

Is my board just not setup right? Missing OTP id? I guess I can force
a working radio with a board.bin file?

Thanks again,
-M

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

Re: [LEDE-DEV] [RFC 2/3] ipq: Don't force selection of the IPQ4019 firmware.

2017-11-14 Thread Matthew McClintock 
What ever came of this? Did something upstream or in LEDE/OpenWrt
resolve what files should be loaded from where?

-M

On Sat, Nov 4, 2017 at 11:38 AM, Ben Greear  wrote:
>
>
> On 11/04/2017 08:14 AM, Christian Lamparter wrote:
>>
>> On Friday, November 3, 2017 8:15:00 PM CET Ben Greear wrote:
>>>
>>>
>>> On 11/03/2017 05:58 PM, Christian Lamparter wrote:

 On Friday, November 3, 2017 5:05:39 PM CET gree...@candelatech.com
 wrote:
>
> From: Ben Greear 
>
> This will allow us to select the CT IPQ4019 firmware instead if
> desired.
>
> Signed-off-by: Ben Greear 
> ---
>  package/firmware/ipq-wifi/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/firmware/ipq-wifi/Makefile
> b/package/firmware/ipq-wifi/Makefile
> index aec8bf2..31d0fbf 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -20,7 +20,7 @@ define Package/ipq-wifi-default
>SUBMENU:=ath10k IPQ4019 Boarddata
>SECTION:=firmware
>CATEGORY:=Firmware
> -  DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
> +  DEPENDS:=@TARGET_ipq806x

 Hm, this would break the WIFI in the default configuration for the
 FritzBox 4040 image. Currently it only has a dependency on the
 ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)

 Please also note that the ipq-wifi boards need to overwrite the
 board-2.bin provided by the ath10k-firmware-qca4019(-ct) packages.
 So switching (or up-/downgrading) these wifi-firmwares will always
 require the (manual) reinstallation of the ipq-wifi board
 (if available).
>>>
>>>
>>> Maybe have the custom board.data file named slightly differently
>>> and then have an early fixup script to copy it into the proper place
>>> on first boot?  And, we could hack the driver to look for a custom
>>> board-2.bin first and just install both board-x.bin images.
>>
>> Depends, can you convince the ath10k upstream to do that?
>
>
> Upstream is unlikely to accept such a patch, but I can at least
> patch my driver, and we can patch lede's 'upstream' driver too if
> we need to.
>
> We can also have a ath10k-pre-startup.sh that copies a custom board
> file into place when starting LEDE, with no driver modifications needed
> at all.  I think several targets do something like this already by grabbing
> the board file
> from a flash location on the AP, for instance.
>
>>>
>>> And, can we have the IPQ boards select the stock 4019 firmware by default
>>> but still allow it to be de-selected so CT firmware can be selected?
>>>
>>> Or if not, then I can call my firmware something different, and have my
>>> driver look for it before the firmware-5.bin.
>>
>>
>> I think there's a another way to do this. But it will require to break
>> with
>> the existing convention of adding the board-2.bin that comes with the
>> firmware repository to the ath10k-firmware-qca4019 file.
>>
>> This way, the custom board-2.bin will stay in place when you switch/update
>> the firmware-5.bin.
>
>
> That seems fine to me.  Then targets could select a custom board file or
> a stock board file, independent of the firmware and driver.
>
>>
>> (The board-2.bin for the reference boards can simply be packaged just like
>> one of the ipq-wifi board firmwares). And furhtermore, you could provide a
>> "easy to use/install" custom ipq-wifi.ipk for the board-2.bin you
>> currently
>> host on your webside.
>
>
> The only board-2.bin that I (might?) have on my web site is one modified for
> some newer 9984 NICs from Compex.  The 'ath10k-ct' firmware target just uses
> the
> default board-2.bin file from upstream.
>
> I guess someone could host/build ath10k-ct firmware ipks, but I think that
> might
> be more useful for some more standard LEDE build-farm to host since the goal
> is to
> have all of this in LEDE anyway.
>
> Thanks,
> Ben
>
> --
> 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

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

Re: [LEDE-DEV] [PATCH] uboot-envtools: Add support for IPQ806x AP148 and DB149

2017-06-27 Thread Matthew McClintock 
On Mon, Jun 26, 2017 at 6:55 AM, Ram Chandra Jangir
 wrote:
> IPQ806x AP148 and DB149 boards didn't have the UCI ubootenv
> section initialized, so the usage of fw_printenv required manual
> configuration. With this change, the "fw_printenv" and "fw_setenv"
> command will automatically work on NOR and NAND based platforms.
>
> Signed-off-by: Ram Chandra Jangir 
> ---
>  package/boot/uboot-envtools/files/ipq | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/package/boot/uboot-envtools/files/ipq 
> b/package/boot/uboot-envtools/files/ipq
> index 16c7ba6..01ae220 100644
> --- a/package/boot/uboot-envtools/files/ipq
> +++ b/package/boot/uboot-envtools/files/ipq
> @@ -13,7 +13,29 @@ touch /etc/config/ubootenv
>
>  board=$(ipq806x_board_name)
>
> +default_uboot_env () {

Is there a better name for this? It's really just for boards that can
boot NOR or NAND to decide where the env is?

> +   UBOOTENV_PART=$(cat /proc/mtd | grep APPSBLENV)
> +   mtd_dev=$(echo $UBOOTENV_PART | awk '{print $1}' | sed 's/:$//')
> +   mtd_size=0x$(echo $UBOOTENV_PART | awk '{print $2}')
> +   mtd_erase=0x$(echo $UBOOTENV_PART | awk '{print $3}')
> +   nor_flash=`find /sys/bus/spi/devices/*/mtd -name ${mtd_dev}`

Can you stick with one syntax here? $(...)

> +
> +   if [ -n "$nor_flash" ]; then
> +   uboot_env_size=$mtd_size
> +   else
> +   # size is fixed to 0x4 in u-boot
> +   uboot_env_size=0x4
> +   fi
> +
> +   sectors=$(( $uboot_env_size / $mtd_erase ))
> +   echo /dev/$mtd_dev 0x0 $uboot_env_size $mtd_erase $sectors
> +}
> +
>  case "$board" in
> +ap148 | db149)
> +   env=$(default_uboot_env)
> +   [ -n "${env}" ] && ubootenv_add_uci_config $env

When is it ever not defined?

> +   ;;
>  ea8500)
> ubootenv_add_uci_config "/dev/mtd10" "0x0" "0x2" "0x2"
> ;;
> --
> 2.7.2
>
>
> ___
> 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] [PATCH] build: add V=e option for extended build info

2017-06-18 Thread Matthew McClintock 
On Sat, Jun 17, 2017 at 7:35 AM, Felix Fietkau <n...@nbd.name> wrote:
> On 2017-06-16 20:58, Matthew McClintock wrote:
>> This will output when a job starts and stops:
>>
>> $ make -j24 V=e
>> [ snip ]
>>  make[3] -C package/network/config/firewall compile
>>  make -r -C package/network/config/firewall 
>> BUILD_SUBDIR=package/network/config/firewall BUILD_VARIANT= compile finished
>>
>> It's quite useful for debugging parallel builds to see what actually
>> failed without having to re-run -j1 V=s when the issue may not occur at
>> all.
>>
>> Signed-off-by: Matthew McClintock <msm-...@mcclintock.net>
> I think this is a good idea. Could you please make the following changes
> to it:
>
> - clean up the "make ... finished" part to look like the earlier msg
> that indicated the start of the build. Preferably both should indicate
> which build variant is being used (where present).
>
> - print the "make ... failed" message by default

How about this? Print a started, and always print the finished message.

 make -r -C package/network/config/firewall
BUILD_SUBDIR=package/network/config/firewall BUILD_VARIANT= compile
started
 make[3] -C package/network/config/firewall compile
 make -r -C package/network/config/firewall
BUILD_SUBDIR=package/network/config/firewall BUILD_VARIANT= compile
finished

SUBMAKE:=cmd() { printf "$(_Y) make $$* started$(_N)\n" >&8; $(MAKE)
$$* || { printf "$(_Y) make $$* failed$(_N)\n" >&8; false; }; printf
"$(_Y) make $$* finished$(_N)\n" >&8; }; cmd

Getting a bit ugly ;)

-M

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

Re: [LEDE-DEV] QCA Dakota support

2017-03-09 Thread 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

2017-03-09 Thread 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 <sailorm...@gmail.com> 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 <j...@phrozen.org> 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 <sailorm...@gmail.com> 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

2017-03-09 Thread 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 <j...@phrozen.org> 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 <sailorm...@gmail.com> 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] ubus network restart issue?

2017-01-16 Thread Matthew McClintock 
All,

I've seen a pretty easy to reproduce ubus issue related to network
restart. I've tested this on various releases include the recently
release LEDE branch as well as OpenWrt CC. I've also tested on more
than one target and with various delays including as long as 2
minutes.

Before:

root@lede:/# ubus list
dhcp
file
iwinfo
log
network
network.device
network.interface
network.interface.lan
network.interface.loopback
network.interface.wan
network.interface.wan6
network.wireless
service
session
system
uci

root@lede:/# while true; do ubus call network restart; sleep 10; ubus list | gre
p network || { echo network failed; ubus list; break; }; done

[ snip - always about 6-7 iterations of the while loop ]

network failed
dhcp
file
iwinfo
log
service
session
system
uci

The end result is that we're unable to make ubus calls to all the
missing objects and we're stuck in this state getting an 'Object not
found' message if we try to operate on the missing items. Running
/etc/init.d/network restart will recover from this state.

Any one have ideas? Any ideas on where to start?

-M

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

Re: [LEDE-DEV] QCA Dakota support

2016-11-21 Thread 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

2016-11-21 Thread 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

2016-11-12 Thread 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

2016-11-07 Thread 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