08:34 | jnettle | 08:34 * jnettlet wonders if we need to host custom repositories for the major distributions to make adoption a bit easier. |
09:04 | MikeSeth | jnettlet: you mean package wise? |
09:19 | jnettlet | MikeSeth, yeah. basically .debs, .rpms and whatever ARCH uses. pacman I think. |
09:25 | MikeSeth | jnettlet: packing up imx-specific exotics into .deb is on my todo list |
09:25 | MikeSeth | I'm waiting for the new kernel to be ready, meanwhile studying kernel hacking and a bit of hardware |
09:26 | MikeSeth | the way I look at it, there should be cubox-specific kernel & module & userland libs packages for major distros |
09:26 | MikeSeth | RPMs might take a while though, haven't touched RPM distros for a decade |
09:27 | MikeSeth | this sabich sandwich just made my day so much better |
09:28 | hste | MikeSeth: What is a sabich sandwich? :) |
09:29 | MikeSeth | hste: it's fried eggplant and hard boiled eggs, with tahini and other stuff |
09:30 | MikeSeth | ...now I want another one |
09:30 | hste | Now I got hungry. Guess I'll have to find sth to eat :) |
09:38 | davorin | morning.. |
10:05 | Coolgeek | jnettlet: for arch, you don't need a repo, juste use AUR to host a PKGBUILD :) (it's a file that hold all of the instructions to build a package) |
10:06 | jnettlet | Coolgeek, but what about binaries? I know most people build their own, but doesn't it also support binaries? |
10:07 | Coolgeek | jnettlet: binaries ? if you can compile it, it will dl the sources and make the binaries |
10:07 | Coolgeek | basically, a PKGBUILD is just shell commands |
10:07 | Coolgeek | so, you have a function that will be called to build a package |
10:07 | MikeSeth | aw shit' |
10:07 | MikeSeth | uh wrong channel |
10:08 | patrickg | still holds true then? |
10:08 | Coolgeek | in there, if you want to dl a binarie to include inside a package, it's fine |
10:08 | Coolgeek | but, the arch way is to be able to build all from sources |
10:08 | jnettlet | but on smaller embedded systems with low amounts of RAM that is not really a great situation. I guess ARCH really isn't a good distribution for that. |
10:09 | patrickg | and yet they provide a binary-only route |
10:09 | Coolgeek | jnettlet: I suppose, it's to provide a custum kernel ? |
10:09 | patrickg | for those that find no satisfaction to see a compiler running all the time |
10:09 | jnettlet | patrickg, they do provide a binary only route. that is what I wanted to know |
10:10 | Coolgeek | jnettlet: if needed, there is a way to take a .deb or .rpm, extract it and make an arch package |
10:13 | Coolgeek | jnettlet: https://aur.archlinux.org/packages/to/toyunda-manager/PKGBUILD <== example to build an arch package from a deb one |
10:14 | jnettlet | Coolgeek, thanks. Although I was not envisioning myself doing the packaging. Just wondering if it would help adoption if we hosted external repos while the distros catch up. |
10:15 | jnettlet | It seems like even after multiple years ARM support in most the distros is not very cohesive |
10:15 | patrickg | as for archlinux, there's the http://archlinuxarm.org/ project |
10:15 | Coolgeek | yeah, because there is not much people who have a board |
10:15 | Coolgeek | mostly it's dev board |
10:15 | rabeeh | which we are trying to change !!! |
10:16 | rabeeh | :) |
10:16 | patrickg | and distro support in general certainly isn't helped by the messy boot/configuration situation (devicetrees are a hot topic after how many years?) |
10:16 | davorin | ah rabeeh: thanks for the doc (o; |
10:16 | rabeeh | good morning |
10:16 | rabeeh | davorin: no problem. |
10:17 | rabeeh | Coolgeek and others; this is actually phase two that we are entering; mainline support from major distros; and there is the infinite flamewar which distro to support first |
10:19 | Coolgeek | I should say (and it hurt me a lot): ubuntu / debian |
10:19 | davorin | that's why i love freebsd (o; |
10:19 | davorin | just one distro ... |
10:20 | Coolgeek | they are the most world wide spread distro I think |
10:20 | Coolgeek | and they have a (really ?) good reputation |
10:20 | Coolgeek | the just my 2 cents |
10:20 | Coolgee | 10:20 * Coolgeek return to idle state |
10:20 | rabeeh | freebsd/netbsd/openbsd ... - really one distro? |
10:21 | davorin | they have different purposes... |
10:21 | jnettle | 10:21 * jnettlet questions the ubuntu reputation at this point. debian is a bit more reputable. The only plus with ubuntu is that Linaro uses that as a base |
10:21 | davorin | netbsd -> embedded.. |
10:21 | davorin | openbsd -> security |
10:21 | davorin | freebsd -> mainline |
10:21 | Coolgeek | jnettlet: for newbies, ubuntu have a good reputation |
10:22 | Coolgeek | and if you want a good spread, focus the newbies I think |
10:22 | davorin | and companies like freebsd as they don't have to release any sources, like juniper (o; |
10:22 | patrickg | rabeeh: those are different kernels and userlands (with some overlap) |
10:22 | patrickg | rabeeh: while linux distros are boringly similar |
10:23 | jnettlet | they don't have to release any sources so they can provide NSA backdoors, like juniper :-P |
10:23 | Coolgeek | haha |
10:25 | davorin | in the good old days cisco had the port 1999 hack....damn i can't find the source anymore... |
10:25 | davorin | the first routers went to finland...and the us were scared they could end up in russia |
10:25 | davorin | so if you telnet to those router on port 1999, they replied with "cisco" |
10:26 | patrickg | jnettlet: I doubt very many people compare their support enabled RHEL kernel binary to the sources they ship with it |
10:26 | davorin | and the us were assrued they were still in finland (o; |
10:26 | davorin | that was in ios 11.x sources though... |
10:29 | davori | 10:29 * davorin compiled new arch kernel with rfkill set for bt.... |
10:29 | davorin | time for breakfast |
11:09 | davorin | for the linux distros...debian should be definitively be supported... |
11:09 | davorin | makes easier for raspberry pi users to upgrade to hummingboard (o; |
11:10 | davorin | dunno how easy it is to port wiringpi lib to hb |
11:16 | MikeSeth | davorin: uhm, cubox gpios aren't exposed |
11:16 | davorin | i'm talking about hb (o; |
11:17 | MikeSeth | yeah, but hb is hb.. and I should really get a hb |
11:17 | davorin | i'm still waiting for a feedback when i get mine (o; |
11:17 | davorin | and a cb wihout schematics is of not much use ;-) |
11:18 | davori | 11:18 * davorin wants to start developing add-on boards pretty soon.. |
11:18 | davorin | sad dsi will be dropped...and rgb lcd not included *sniff |
11:20 | davorin | and an add-on tft connected via spi or gpio is too slow... |
11:20 | davorin | rpi is still not ready with using the dsi port...so this would have been a big advantage... |
11:21 | davorin | though dsi displays are hard to get and also only available as phone/tablet spare parts.. |
11:21 | davorin | at least lvds and usb internally available...that's big advantage over rpi... |
11:23 | dshankar | uh oh. is libavcodec (avcodec_decode_video2) not hw accelerated on imx6? :( |
11:27 | _rmk_ | when stuff like overlay support starts working in mainline, I'll start looking at vlc/libav, but until then I've enough to do with the mainline kernel. I believe there's patches around somewhere for libav. |
11:28 | dshankar | _rmk_: ah I see |
11:29 | _rmk_ | my CEC driver is now working (to the point of being able to communicate properly) for mainline last night |
11:30 | _rmk_ | I still need to sort out passing the phys cec address and connect/disconnect events to it |
11:37 | davorin | hmm..git kernel won't finish booting... |
11:38 | dshankar | _rmk_: I thought imx6 had hw decode of vp8 streams via libvpx? doesn't libav use libvpx // should be able to decode vp8 natively? |
11:47 | davorin | weired...plain vanilla arch kernel stops loggin on serial console with "starting kernel":..then hands over to screen.. |
11:47 | davorin | built kernel from git stops on serial console at "console [tty0] enabled, bootconsole disabled" and nothing on screen then.. |
11:48 | Coolgeek | I think there is some patch on arch kernel |
11:48 | davorin | well..i took the one frmo rabeeh's git repo |
11:49 | davorin | Linux version 3.0.35-g5c73417 (root@alarm) |
11:50 | davorin | can be both enabled? screen and serial console in kernel config? |
12:13 | _rmk_ | dshankar: it's the same problem as with vmeta on dove - libav likes to do some pre-processing of the stream, but vmeta and the imx6 vpu both like to have an elementary stream.... which would need to be reconstructed. It's possible to do that for some stream times but not h264. |
12:35 | _rmk_ | dshankar: it's the same problem as with vmeta on dove - libav likes to do some pre-processing of the stream, but vmeta and the imx6 vpu both like to have an elementary stream.... which would need to be reconstructed. It's possible to do that for some stream types but not h264. |
12:36 | dshankar | _rmk_: I'm working with vp8 if it makes a difference? |
13:28 | _505 | anyone can give some feedback on http://imx.solid-run.com/wiki/index.php?title=U-Boot |
13:28 | _505 | still a bit confused, especially when dd u-boot to a non-partition, e.g. as done in openelec |
13:29 | _505 | so I suspect not all info on the wiki is correct |
13:58 | _dab_ | _505: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard#U-Boot_Upstream might help |
14:06 | _505 | but what exactly happens when dd'ing these files to an SD? they do not end up as files you can read on the SD |
14:09 | _dab_ | They are written to unoccupied sectors. The boot loader just loads from the offsets defined. The first part of any disk is reserved for bootloaders and partition information. I can give you a reference if you like |
14:12 | _dab_ | They end up as raw offsets on the disk that you can read |
14:12 | _dab_ | hope that helps |
14:12 | _dab_ | http://en.wikipedia.org/wiki/Master_boot_record |
14:18 | _505 | on some images, there are files /boot/SPL and /boot/u-boot.img, on some not and then they are written to unoccupied sectors. Correct? |
14:19 | _505 | any differences between these, in terms of building/functioning? |
14:21 | _dab_ | correct, I thought the SPL had to always be written to a sector, it in turn loads the uboot image. the uboot image can be on a sector or in the file system as you describe. |
14:21 | _dab_ | I am not sure which one rabeeh prefers |
14:23 | _dab_ | checking... |
14:24 | _dab_ | yes the SPL is at offset 1K and the uboot.img is as 42K. |
14:26 | _dab_ | the reason for the two files is that the same SPL and uboot can be used for all of the cubox-i range, rather than have different uboots for each box |
14:29 | jnettlet | SPL would always need to live on the raw sectors of the boot medium, as I don't know of any SOC's that have machine code for the FAT filesystem burned into them. |
14:30 | jnettlet | but after that the rest of the pieces can live anywhere, the biggest limiting factor being the memory available to execute SPL in. |
14:30 | MikeSeth | SPL is the newer approach, older images have a single image, newer ones two, and they don't have to actually be visible to the root filesystem |
14:32 | jnettlet | SPL isn't a new approach, it is just new to the MX6 architecture in u-boot. All SPL is, is minimal first chunk of code responsible for at a minimum setting up DRAM and the CPU to execute the second stage. |
14:32 | _dab_ | I presume the SPL looks at offset 42K 'before' the file system? yes/no? |
14:33 | MikeSeth | _dab_: yeah, I usually create a blank partition to cover the boot image space |
14:34 | jnettlet | SPL only looks at the 42K right now. We do compile in vfat support but haven't enabled it yet. |
14:35 | _dab_ | I would not bother with the vfat support. Anything which makes the documentation larger is a bad thing. |
14:36 | jnettlet | really that 84sector offset is a little excessive as we only have 128K of SDRAM so the first SPL stage can not be larger than that |
14:36 | _dab_ | ref : 505 questions above |
14:42 | _dab_ | I just keep praying for a working uboot (incl. NFS) |
14:46 | MikeSeth | _dab_: uboot doesn't work for you? |
14:46 | MikeSeth | I understand there was something screwy with its network boot because it had an issue with the ethernet controller on cuboxes |
15:44 | davorin | does it matter compiling the kernel with eabi or eabihf? |
15:48 | _rmk_ | absolutely no difference |
15:48 | _rmk_ | the kernel doesn't use floating point internally |
15:48 | davorin | then i wonder why git kernel doesn't show anything on the screen... |
15:49 | davorin | console is ttymxc1,115200? |
15:49 | davorin | or will it be overrided by the kernel to print on screen? |
15:54 | davorin | ah hear it stops: |
15:54 | davorin | i2c-core: driver [max17135] using legacy suspend method |
15:54 | davorin | i2c-core: driver [max17135] using legacy resume method |
15:54 | davorin | Switching to clocksource mxc_timer1 |
15:54 | davorin | Unable to handle kernel paging request at virtual address ffffffff |
15:54 | davorin | pgd = 80004000 |
15:54 | davorin | [ffffffff] *pgd=79ffe821, *pte=00000000, *ppte=00000000 |
15:54 | davorin | Internal error: Oops: 17 [#1] PREEMPT SMP |
15:54 | davorin | Modules linked in: |
15:54 | davorin | CPU: 0 Not tainted (3.0.35-g5c73417 #1) |
15:54 | davorin | PC is at kmem_cache_alloc+0xa8/0x100 |
15:54 | davorin | LR is at con_insert_unipair+0xb8/0x104 |
15:54 | davorin | pc : [<800fd5a0>] lr : [<802c7f7c>] psr: 60000093 |
15:54 | davorin | can you boot successfully the git kernel from rabeeh? |
15:56 | davori | 15:56 * davorin needs to setup tftp again for developing... |
15:57 | MikeSeth | davorin: what kernel is that? |
15:58 | davorin | the one from the wiki: git clone https://github.com/SolidRun/linux-imx6.git |
15:58 | MikeSeth | 3.0.35? |
15:58 | MikeSeth | wait, the one I use is from /rabeeh/ |
15:58 | davorin | 3.0.35-g5c73417 |
15:58 | MikeSeth | uhh, and that is on hb? |
15:59 | davorin | nope..i4p |
15:59 | davorin | i just enabled rfkill for bt...haven't tried vanilla version though |
15:59 | MikeSeth | this branch is never than the one I use |
15:59 | davorin | so the kernel mentioned on the wiki is too old? or never updated again? |
15:59 | MikeSeth | I wasnt even aware that there's a SolidRun branch |
16:00 | davorin | well..officialy documented on: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard |
16:00 | MikeSeth | no, to the contrary, the one you use is much never, rabeeh added some patches that dont exist in the tree that I use |
16:01 | MikeSeth | newer* |
16:01 | davorin | and rabeeh git version is 3.0.35-6? |
16:01 | MikeSeth | -4 iirc |
16:02 | MikeSeth | wait |
16:02 | MikeSeth | durr |
16:02 | davorin | i just saw that some people are complaining on the forum about bluetooth not visible on i2u and i4p, so i thought i try to compile one with support built-in (o; |
16:03 | davorin | and i want to test ble as well for cubox-i to be used as small ble beacon... |
16:03 | MikeSeth | you probably should ignore what I just said.. |
16:03 | davorin | ehm..the version number? |
16:04 | MikeSeth | all of it, I need to get home and actually look what branch I use |
16:04 | davorin | well..would be good if all here would use the same kernel repo (o; |
16:04 | MikeSeth | but yes the one you use is with recent patches |
16:05 | davorin | the one with kernel panic? (o; |
16:05 | MikeSeth | 14:24 Switching to clocksource mxc_timer1 |
16:05 | MikeSeth | 14:24 Unable to handle kernel paging request at virtual address ffffffff |
16:05 | MikeSeth | something funny definitely going on there |
16:05 | MikeSeth | I wish I was a proper kernel hacker to figure out what |
16:05 | davorin | being a long time i did kernel drivers..back in the 2.4, 2.6 days... |
16:05 | davorin | with drivers calling drivers within kerenl (o; |
16:06 | davorin | and misuse serial port attached radio modems as ethernet devices ;-) |
16:07 | MikeSeth | gtg, sorry |
16:07 | davorin | no probs (o; |
16:12 | davorin | hmm..so which defconfig it is now in rabeeh's repo... |
16:13 | rabeeh | imx6_cubox-i_hummingboard_defconfig |
16:14 | davorin | not in your repo /rabeeh/linux.git |
16:14 | davorin | the repo from repo solidrun gets me a kernel panic.. |
16:15 | rabeeh | https://github.com/SolidRun/linux-imx6 |
16:15 | davorin | that one gives me: |
16:15 | davorin | i2c-core: driver [max17135] using legacy suspend method |
16:15 | davorin | i2c-core: driver [max17135] using legacy resume method |
16:15 | davorin | Switching to clocksource mxc_timer1 |
16:15 | davorin | Unable to handle kernel paging request at virtual address ffffffff |
16:15 | davorin | pgd = 80004000 |
16:15 | davorin | [ffffffff] *pgd=79ffe821, *pte=00000000, *ppte=00000000 |
16:15 | davorin | Internal error: Oops: 17 [#1] PREEMPT SMP |
16:15 | davorin | Modules linked in: |
16:15 | davorin | CPU: 0 Not tainted (3.0.35-g5c73417 #1) |
16:15 | davorin | PC is at kmem_cache_alloc+0xa8/0x100 |
16:15 | davorin | LR is at con_insert_unipair+0xb8/0x104 |
16:15 | davorin | pc : [<800fd5a0>] lr : [<802c7f7c>] psr: 60000093 |
16:15 | rabeeh | the one you have pointed to is for the older CuBox-i |
16:16 | davorin | the one from the wiki is the right one then... |
16:16 | davorin | but crashes for me on my i4p |
16:19 | rabeeh | random or consistent crash? |
16:19 | davorin | consistent.. |
16:19 | rabeeh | which toolchain? |
16:19 | davorin | well, only added this option, though haven't tried without... |
16:19 | rabeeh | there were reports about gcc 4.8.x issues |
16:19 | davorin | CONFIG_MACH_IMX_BLUETOOTH_RFKILL=y |
16:19 | rabeeh | oh; please try as-is first |
16:19 | rabeeh | although should really matter |
16:20 | davorin | CONFIG_MACH_IMX_BLUETOOTH_RFKILL=y |
16:20 | davorin | ehm.. |
16:20 | davorin | gcc version is 4.7.2 |
16:22 | davori | 16:22 * davorin compiling without now... |
16:24 | MikeSeth | rabeeh: could you elaborate the difference between github /SolidRun/ and /rabeeh/ linux-imx6 trees? |
16:25 | MikeSeth | also I put together a vagrant recipe for kernel cross-compiler if it helps anybody |
16:25 | rabeeh | the rabeeh/linux-imx6 is the old (and needs to be removed) |
16:26 | rabeeh | the /SolidRun/ what holds; so the linux was under my name and got to SolidRun; the same will happen to u-boot once it becomes ready (missing SPL mysterious bug that I can't reproduce) |
16:26 | rabeeh | or maybe barebox :) |
16:26 | MikeSeth | so I should switch to /SolidRun/ is what you're saying |
16:28 | davorin | MikeSeth: can you post your recipe on the forum, or send it to rabeeh for including onto the wiki? |
16:29 | MikeSeth | davorin: sure, just needs a bit of a cleanup |
16:30 | davori | 16:30 * davorin likes to have a wiki account (o; |
16:33 | davorin | wtf...where did this come from: |
16:33 | davorin | root=/dev/mtdblock2 rw rootfstype=jffs2 |
16:34 | rabeeh | MikeSeth: yes. and I should be completely removing that repo |
16:34 | davorin | but looks better without rfkill set... |
16:34 | davorin | comes up to where it coudn't find rootfs |
16:34 | davorin | No filesystem could mount root, tried: jffs2 |
16:34 | davorin | Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) |
16:34 | davorin | but that's obvious... |
16:34 | davorin | so something gets borked with CONFIG_MACH_IMX_BLUETOOTH_RFKILL |
16:35 | davorin | hmm..is mtdblock2 hardcoded somewhere in the kernel configs? |
16:38 | MikeSeth | errr, on my system, which is cloned from hste's squeeze rootfs, this is configured in uEnv.txt |
16:39 | MikeSeth | uboot picks it up in both SPL and non-SPL variants |
16:39 | rabeeh | MikeSeth: repo removed |
16:40 | MikeSeth | rabeeh: great, I'm compiling the new one |
16:42 | davorin | rabeeh: boots fine without rfkill set |
16:43 | davorin | rfkill kills (o; |
16:43 | rabeeh | hehe |
16:43 | rabeeh | interesting though; the same driver works ok on Android |
16:43 | davorin | some other option dependant on rfkill? |
16:44 | davorin | in kernel it is just the bcm wlan driver, right? |
16:44 | davorin | no specific bt driver |
16:44 | davori | 16:44 * davorin used to work for bt, gives him the shiver (o; |
16:47 | davorin | anyway...good to be back in kernel stuff... |
16:49 | davorin | otoh...it doesn't get me paid (o; |
16:49 | MikeSeth | rabeeh: I posted a note on the forums about repo switchover |
16:49 | rabee | 16:49 * rabeeh looks for that |
16:50 | davori | 16:50 * davorin controls that.. |
16:51 | rabeeh | ok. thanks |
16:51 | rabeeh | i'm not sure how much people did that mistake; the wiki was clear enough with that; or wasn't it? |
16:51 | MikeSeth | I picked it up from somewhere |
16:52 | davorin | well...i started with the wiki, but since it crashed i thought i try your repo (o; |
16:52 | MikeSeth | maybe some old forum post or wiki page |
16:52 | MikeSeth | the important thing is that kernel worked ;) |
16:52 | davorin | yes, when you don't need bt (o; |
16:54 | davorin | btw: are the vivante in the archlinux repo? |
16:54 | davorin | or do i need to grab them elsewhere? |
16:56 | davori | coffee and :-! |
17:01 | kuguar | what name have wifi adapter in debian? |
17:02 | rabeeh | wlan0 |
17:02 | kuguar | tnx |
17:02 | davorin | rabeeh: you mentioned of other changes besides rfkill option bein as default you want to publish... |
17:06 | rabeeh | yes. mainly usb wifi adapters, ppp support etc... |
17:06 | rabeeh | nothing major; just making it more standardized .config file for common usage |
17:07 | rabeeh | i'm mainly now banging my head in the wall on how to get support from a major distribution |
17:07 | rabeeh | s/in/on |
17:08 | rabeeh | by support i mean kernel packages (once we have either 3.10 lts or upstream); all the gpu stuff to be installed by packages (and installing mesa won't break it), java etc... |
17:08 | kuguar | why wired usb mouse does not work in android? I could not turn on bluetooch using the keyboard to use a wireless mouse. |
17:08 | rabeeh | kugar: there were some models reported not being supported |
17:10 | rabeeh | which brand is it? |
17:11 | kuguar | rabeeh ok, which models are supported? my mouse is a4tech glaser |
17:11 | rabeeh | have 'lsusb'? |
17:12 | rabeeh | most of the mouse / kbd we tried worked; except one branded as GP |
17:12 | kuguar | I have already removed the android while trying Debian |
17:12 | rabeeh | kugar: is it working under Debian? |
17:13 | kuguar | yes |
17:16 | kuguar | input: A4Tech USB Mouse as /devices/platform/fsl-ehci.0/usb1/1-1/1-1:1.0/input/input1 a4tech 0003:09DA:000A.0001: input,hidraw0: USB HID v1.10 Mouse [A4Tech USB Mouse] on usb-fsl-ehci.0-1/input0 |
17:24 | davorin | weired... |
17:24 | davorin | really weired... |
17:25 | davorin | fecking weired... |
17:25 | davorin | just spread some printk over mx6_bt_rfkill.c, recompiled...and now.. |
17:25 | davorin | [root@alarm ~]# rfkill list |
17:25 | davorin | 0: mxc-bt: Bluetooth |
17:25 | davorin | Soft blocked: no |
17:25 | davorin | Hard blocked: no |
17:25 | davorin | 1: phy0: Wireless LAN |
17:25 | davorin | Soft blocked: no |
17:25 | davorin | Hard blocked: no |
17:28 | davorin | still no bt device showing up... |
17:32 | davorin | and ifconfig wlan0 with ip addresses freezes the system.. |
17:32 | davorin | ah no..just throws me out... |
17:33 | rabeeh | davorin: which distro? |
17:33 | davorin | archlinux with todays kernel.. |
17:33 | rabeeh | you need to send the bt firmware first |
17:33 | rabeeh | look for package similar to brcm pathram plus |
17:33 | davorin | ah right...knew you mentioned something yesterday (o; |
17:33 | rabeeh | brcm patchram plus |
17:33 | davorin | this part of modules? |
17:34 | rabeeh | then send the bcm4329 hcd drive via it; and make sure brcm_patchram_plus calls hciattach too |
17:35 | rabeeh | or get it from here - |
17:35 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/bcm4329.hcd |
17:37 | davorin | this patchram_plus is an application or a module? |
17:38 | davorin | ah... |
17:38 | davorin | https://code.google.com/p/broadcom-bluetooth/source/browse/brcm_patchram_plus.c |
17:42 | _rmk_ | jnettlet: did we come to any conclusion wrt my change for gpio for card detect? |
17:50 | davorin | rabeeh: and just invoke ./brcm_patchram_plus bcm4329.hcd ? |
17:59 | davorin | so..just need to know which /dev/* it is... |
18:32 | rabeeh | davorin: it's /dev/ttymxc3 |
18:32 | rabeeh | (uart4) |
18:34 | davorin_mbp | baudrate? 115200? |
18:34 | rabeeh | 115200bps 8N1 without hw/sw flow control |
18:34 | rabeeh | oh; sorry |
18:35 | rabeeh | you can go up to 3Mbps, with hw flow control |
18:35 | rabeeh | brcm_patchram_plus -d --patchram /tmp/bcm4330.hcd --baudrate 3000000 --enable_hci --use_baudrate_for_download /dev/ttymxc3 --no2bytes --enable_lpm --tosleep=50000 |
18:35 | rabeeh | this is an example for bcm4330 (the newer broadcom chip) |
18:38 | davorin_mbp | hmmm...hangs at |
18:38 | davorin_mbp | received 7 |
18:38 | davorin_mbp | 04 0e 04 01 03 0c 00 |
18:38 | davorin_mbp | writing |
18:38 | davorin_mbp | 01 18 fc 06 00 00 c0 c6 2d 00 |
18:44 | rabeeh | do you have 'Bluetooth power on' on your kernel messages? |
18:44 | davorin_mbp | rfkill says so... |
18:45 | davorin_mbp | and dmesg: |
18:45 | davorin_mbp | [ 0.000000] usom_bt_power_change : Bluetooth power on |
18:45 | rabeeh | that's a kernel message from the microsom board support |
18:46 | rabeeh | davorin_mbp: you need to find the magical brcm_patchram_plus command (for instance the --enable_lpm shouldn't be there for bcm4329) |
19:35 | _rmk_ | rabeeh: looking at your git tree... |
19:35 | _rmk_ | MX6Q_PAD_DISP0_DAT21__GPIO_5_15, /* XTAL power up */ |
19:36 | _rmk_ | #define USOM_XTAL_ON IMX_GPIO_NR(5, 5) |
19:36 | _rmk_ | is it gpio5 bit 15 or bit 5? |
19:44 | rabeeh | _rmk_: it should be MX6Q_PAD_DISP0_DAT11__GPIO_5_5 |
19:44 | rabeeh | the reason it worked since the default of the pad is GPIO and DISP0_DAT21 is not connected to anything. |
19:44 | rabeeh | _rmk_: good catch... again |
20:28 | tlw | Linux4Me |
20:28 | tlw | nevermind me! |
20:36 | _rmk_ | rabeeh: is there an nvram configuration file available for the cubox-i's wireless? |
20:37 | _rmk_ | I've got it to the point (by hacking up a script to manipulate the gpios and reprobing the sdhci driver) of spitting out this: |
20:37 | _rmk_ | brcmfmac: brcmf_sdbrcm_get_fw: fail to request firmware brcm/brcmfmac4329-sdio.txt (-2) |
20:41 | pepedog | Look, I am here, even though I hate typing. If wife didn't have tv so load might try iPhone speech to text |
20:41 | pepedog | So what module is required for cbi pro |
20:44 | _rmk_ | pepedog: are you asking about kernel modules or something else? |
20:44 | pepedog | Yes, kernel |
20:44 | pepedog | Sorry, Bluetooth |
20:45 | pepedog | Missed that |
20:45 | _rmk_ | I've just got it up and running on a mainline kernel (through some hacks) and I seem to have ended up with these modules loaded: |
20:45 | _rmk_ | bluetooth 246598 14 btsdio,bnep,rfcomm |
20:45 | _rmk_ | rfcomm 32639 0 |
20:45 | _rmk_ | fuse 79040 2 |
20:45 | _rmk_ | brcmutil 7224 1 brcmfmac |
20:45 | _rmk_ | brcmfmac 159415 0 |
20:46 | _rmk_ | btsdio 2924 0 |
20:46 | _rmk_ | and the desktop is now showing a bluetooth icon |
20:48 | pepedog | Thanks for that, utilite uses btmrvl_sdio |
21:10 | jnettlet | _rmk_, I think we are go on the switch to gpio-cd |
21:12 | jnettlet | but if you are going to push that change upstream we should include my changes to the esdhc-imx driver. Freescale has pushed the uhs support but I have yet to find anyone that has successfully used a uhs card at uhs speeds |
21:13 | jnettlet | Even the people boasting online about the uhs speeds are only getting 20MB/s which you can get under normal 3.3v SD at 50Mhz |
21:13 | _rmk_ | okay, I seem to have wifi working :) |
21:14 | jnettlet | excellent |
21:14 | _rmk_ | it's only a hack |
21:14 | _rmk_ | I'm using a shell script to kick it into working |
21:14 | _rmk_ | not sure about bluetooth yet though |
21:15 | jnettlet | what needs to be kicked in? a gpio need to be tweaked? |
21:15 | _rmk_ | jnettlet: the old problem that I can't specify this stuff in DT yet |
21:16 | _rmk_ | ok, the desktop thinks there's BT available, it pops up an icon in the notification area which says that BT is enabled... but when you go to the BT settings, it says it's disabled! |
21:18 | jnettlet | are you using the gnome bluetooth? |
21:18 | _rmk_ | yea |
21:18 | jnettlet | you may want to check with hcitool and hciscan |
21:19 | jnettlet | do you have any bluetooth devices to scan for? |
21:19 | _rmk_ | I can have. |
21:20 | _rmk_ | hmm |
21:20 | _rmk_ | root@cubox-i4:~# hciconfig |
21:20 | _rmk_ | hci0: Type: BR/EDR Bus: SDIO |
21:20 | _rmk_ | BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 |
21:20 | _rmk_ | DOWN |
21:20 | _rmk_ | root@cubox-i4:~# hciconfig hci0 up |
21:20 | _rmk_ | Can't init device hci0: Input/output error (5) |
21:20 | jnettle | 21:20 * jnettlet wonders if this has to do with the rfkill config options rabeeh was pointing out earlier |
21:21 | jnettlet | _rmk_, do you get anything with rfkill list? |
21:24 | _rmk_ | 5: phy1: Wireless LAN |
21:24 | _rmk_ | Soft blocked: no |
21:24 | _rmk_ | Hard blocked: no |
21:24 | _rmk_ | 6: hci0: Bluetooth |
21:24 | _rmk_ | Soft blocked: no |
21:24 | _rmk_ | Hard blocked: no |
21:24 | _rmk_ | ah, found it in the scrollback |
21:31 | davorin_mb | 21:31 * davorin_mbp too...but brcm_patchram_plus fails |
21:32 | _rmk_ | do you see lots of this: |
21:32 | _rmk_ | writing |
21:32 | _rmk_ | 01 03 0c 00 |
21:33 | davorin_mbp | just a few...then it hangs... |
21:33 | davorin_mbp | option use_baudrate_for_download |
21:33 | davorin_mbp | /dev/ttymxc3 |
21:33 | davorin_mbp | writing |
21:33 | davorin_mbp | 01 03 0c 00 |
21:33 | davorin_mbp | received 7 |
21:33 | davorin_mbp | 04 0e 04 01 03 0c 00 |
21:33 | davorin_mbp | writing |
21:34 | davorin_mbp | 01 18 fc 06 00 00 00 c2 01 00 |
21:34 | _rmk_ | I don't get that "received 7" |
21:34 | _rmk_ | hmm. |
21:37 | davorin_mbp | received 7 is weired |
21:39 | _rmk | 21:39 * _rmk_ tries with serial dma disabled |
21:40 | _rmk_ | another interesting thing is... the cubox-i doesn't find any of the other networks around here which my laptop can |
21:41 | _rmk_ | but maybe that's because it hasn't got a very good antenna inside the small box :) |
21:42 | davorin_mbp | (o; |
21:42 | davorin_mbp | i'm happy kernel crashes anymore with rfkill set... |
21:43 | davorin_mbp | gonna check more 2morrow |
21:43 | hste | _rmk_: a faraday cage? :) |
21:44 | _rmk_ | heh. well, the network it's picking up at full strength is only about 4ft away |
21:45 | _rmk_ | what arguments were you using with that program? |
21:47 | davorin_mbp | me? |
21:47 | _rmk_ | yep |
21:48 | davorin_mbp | brcm_patchram_plus -d --patchram bcm4329.hcd --baudrate 115200 --enable_hci --use_baudrate_for_download /dev/ttymxc3 |
21:48 | _rmk_ | thanks... hmm, mine still doesn't want to play ball |
21:49 | hste | what about bluetooth coexist on wifi? isn't that sth that could interfere? |
21:50 | _rmk_ | well, I've got wifi disabled atm |
21:54 | _rmk_ | ah, four characters missing from the DT |
21:55 | _rmk_ | jnettlet as a hologram? |
21:55 | hste | :) and mobile |
21:56 | jnettlet_mobile | Just trying another irc app for my phone |
21:56 | _rmk_ | "Please state the nature of the technical emergency" ? |
21:57 | _rmk_ | ooh. |
21:57 | _rmk_ | lots of stuff |
21:57 | _rmk_ | Done setting baudrate |
21:57 | _rmk_ | Done setting line discpline |
21:57 | jnettlet_mobile | You playing with DSL again? |
21:57 | _rmk_ | no, that's BT |
21:58 | hste | and not BT as in British Telecom :) |
21:59 | jnettlet_mobile | :-) |
22:00 | _rmk | 22:00 * _rmk_ grabs phone |
22:00 | davorin_mb | 22:00 * davorin_mbp shiver...glad i don't work @ bt anymore... |
22:00 | _rmk_ | davorin: you mean you used to? if so, this is good, I can moan at you about my crappy line :) |
22:01 | davorin_mbp | (o; |
22:15 | davorin_mb | 22:15 * davorin_mbp off for 2day... |
22:15 | davorin_mbp | cya 2morrow (o; |
23:26 | _rmk | 23:26 * _rmk_ managed to associate his phone with the cubox-i :) |