| 11:32 | cbxbiker61 | jnettlet, rabeeh, any word on the imx6 plus chips yet? |
| 11:36 | jnettlet | cbxbiker61, still working on stabilizing the first sample. The kernel is done but still sorting through u-boot |
| 11:37 | cbxbiker61 | sounds good, it looks like the microsom will be the only thing that has to change? |
| 11:37 | jnettlet | well the power consumption/thermal footprint a bit. The die is about 20% larger |
| 11:37 | jnettlet | but the some is a snap in replacement, and a u-boot/kernel upgrade |
| 11:39 | jnettlet | right now I am trying to sort out memcpy in glibc. They merged a version optimized for the Cortex-A15 and I found that on the A9 you get 50-100% performance degradation on memcpy's greater than 22KB |
| 11:40 | jnettlet | performance starts dropping after 16KB, but 22KB is where a straight neon memcpy outperforms glibc |
| 11:40 | mk01 | jnettlet: hopefully not 100% ;-) |
| 11:40 | jnettlet | sorry, I was processing my numbers backwards |
| 11:41 | jnettlet | I have been on conference calls for hours and my mind is jello'd |
| 11:41 | mk01 | sure... just kidding a bit |
| 11:42 | jnettlet | at peak performance glibc's memcpy good up until 22K. With it hitting maximum performance at 8KB |
| 11:44 | cbxbiker61 | jnettlet, does that affect glibc 2.22 or just the git version? |
| 11:45 | mk01 | perhaps a stupid Q, but couldn't one choose an implementation based on the actual memcpy size_t param ? |
| 11:49 | cbxbiker61 | i think you'd want to select the implementation like it's done in x86/glibc, which handles it quite automatically |
| 12:01 | jnettlet | cbxbiker61, all new glibc's for a while |
| 12:01 | jnettlet | mk01, it already does that |
| 12:01 | mk01 | ah ok |
| 12:03 | cbxbiker61 | jnettlet, i'd like a patch for 2.22 if you don't mind. I'd like to roll it in here. |
| 12:37 | jnettlet | cbxbiker61, certainly |
| 12:38 | jnettlet | mk01, generally the split is for much smaller transfers, less than 16 or 64 bits/bytes |
| 12:38 | jnettlet | the slowdown I am seeing is at the KB size |
| 12:38 | jnettlet | sorry about the delay was in another CC |
| 12:41 | mk01 | jnettlet: so back to the original Q then - 2x32k memcpy's would perform like one 64k memcpy or not ? |
| 12:42 | mk01 | ((on continuos 64k block in that case)) |
| 12:44 | jnettlet | well they would hit the same copy path |
| 12:44 | jnettlet | but they would behave differently because they would be parallel copies |
| 12:44 | jnettlet | I haven't tested parallel performance |
| 12:45 | jnettlet | I guess I can run the benchmark two times in a row and see what happens. |
| 12:49 | jnettlet | mk01, parallel performance sees a small drop but is still much faster than the default glibc |
| 12:53 | mk01 | jnettlet: the "perfect alignment case" means page aligned ? |
| 12:55 | jnettlet | mk01, nope 64 byte alignment |
| 12:56 | jnettlet | so page align would work, but you only need 64 bytes alignment. just like mmdcprof shows the Cortex-A9 really likes things in 64-byte chunks |
| 13:01 | mk01 | understand |
| 13:08 | mk01 | what would happen if we play with the bank alignment bits in galcore ? |
| 13:10 | mk01 | too much wasted memory ? |
| 13:12 | mk01 | ((that was parallel thought - sure doesn't help with glibc problem)) |
| 13:13 | jnettlet | mk01, Freescale already tweaks things to what I guess is optimal. Although I haven't verified if that is true. |
| 13:13 | jnettlet | I think if I can get this sorted out we will see what a difference it makes. |
| 13:14 | jnettlet | 600MB/s is a lot of memory bandwidth for this board. |
| 13:17 | mk01 | looking at the numbers again - there are practically two issues open, right ? (one is the block size issue, second the glibc implementation itself (lacking behind neon/bionic)). |
| 16:02 | vko | Hello! does anyone managed to bring up wifi on microsom module? I have microsom i1 with sdio broadcom wifi onboard. Kernel (3.14.14) and rootfs are build from sources. After I issue modprobe b43 I see |
| 16:02 | vko | "Broadcom 43xx driver loaded [ Features: PMNLS ]". |
| 16:02 | vko | But I dont see wlan interface present. The broadcom firmware (brcmfmac4330-sdio.bin) is present in /lib/firmware/brcm. |
| 16:05 | mk01 | vko: the module is brcmfmac |
| 16:11 | vko | mk01: Thanks, I tried brcmfmac also. The output was a bit different: |
| 16:11 | vko | [ 1148.656013] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50 |
| 16:11 | vko | [ 1149.672013] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50 |
| 16:11 | vko | And no effect also. |
| 16:13 | mk01 | vko: there needs to be usdhc1 allowed in DT including sdio clock |
| 16:13 | vko | mk01: don't you who should load the firmware? Driver itself or me with some hotplug? |
| 16:13 | mk01 | driver itself |
| 16:14 | mk01 | [ 14.168815] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 4329 rev 3 pmurev 6 |
| 16:14 | mk01 | [ 14.384005] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 2 2011 14:48:19 version 4.220.48 |
| 16:14 | mk01 | [ 14.411015] brcmfmac: brcmf_fws_init: failed to set bdcv2 tlv signaling |
| 16:14 | mk01 | [ 14.424121] brcmfmac: brcmf_setup_wiphybands: rxchain error (-52) |
| 16:14 | mk01 | [ 14.435618] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code |
| 16:15 | mk01 | and this is the sdio part |
| 16:15 | mk01 | [ 1.680661] sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO |
| 16:15 | mk01 | [ 1.681120] sdhci-esdhc-imx 2194000.usdhc: No vqmmc regulator found |
| 16:15 | mk01 | [ 1.714176] mmc0: queuing unknown CIS tuple 0x80 (50 bytes) |
| 16:15 | mk01 | [ 1.722962] mmc0: queuing unknown CIS tuple 0x80 (7 bytes) |
| 16:15 | mk01 | [ 1.725074] mmc0: queuing unknown CIS tuple 0x80 (4 bytes) |
| 16:15 | mk01 | [ 1.755138] mmc0: queuing unknown CIS tuple 0x02 (1 bytes) |
| 16:15 | mk01 | [ 1.764255] mmc0: new SDIO card at address 0001 |
| 16:16 | mk01 | in firmware/brcm do you also have the .txt files ? |
| 16:18 | vko | mko1: no, .bin |
| 16:20 | mk01 | http://paste.debian.net/348999/ |
| 16:21 | vko | usdh1 seems to be enabled: status = "okay" |
| 16:25 | vko | mk01: sorry, it's not clear for me what it is:) kind of firmware config file? |
| 16:28 | mk01 | vko: it is NVRAM |
| 16:28 | mk01 | both files (bin, txt) needs to be there (firmware/brcm) |
| 16:30 | vko | mk01: ok, thanks. The name should be brcmfmac4330-sdio.txt? |
| 16:31 | mk01 | same as .bin, yes |
| 16:31 | mk01 | (just extension is .txt) |
| 16:32 | bencoh | (but not the same content ;) |
| 16:46 | vko | mk01: thanks, it works! I can scan SSIDs. |
| 16:48 | mk01 | vko: welcome |
| 17:14 | jnettlet | vko, I would highly recommend you switch to the linux-fslc repository. |
| 17:14 | jnettlet | really the simplest method for testing is to use our debian jessie images. |