| 03:32 | MikeSeth | um, is uboot hdmi code a port of the BSP drivers? |
| 05:48 | jnettlet | funny, after talking with _rmk_ about flashing the front LED in linux I realized that we can use that in the boot loader to help people with the non-serial enabled boxes to debug. |
| 05:49 | MikeSeth | i was just looking at uboot's initialization half an hour ago and i thought, maybe you could use this led to blink or something |
| 05:50 | jnettlet | yeah, I will be sure to add that feature to barebox |
| 05:51 | MikeSet | 05:51 * MikeSeth discovers barebox |
| 05:52 | jnettlet | MikeSeth, it uses a kernel driver model |
| 05:52 | MikeSeth | so stuff like mxc drivers needs less porting? |
| 05:54 | jnettlet | yep. Someone has already supported basica Cubox-i/Hummingboard support |
| 05:59 | MikeSeth | welp, I think time to get a HB |
| 06:02 | jnettlet | MikeSeth, are you still not able to boot your U1? |
| 06:03 | MikeSeth | oh no, I am able to boot it just fine, I just put together a custom debian rootfs and that won't boot for some reason |
| 06:03 | MikeSeth | I can't see why because of uboot hdmi clocking bug |
| 06:04 | MikeSeth | I need to set up a custom debian envo so that I can play with deb packaging |
| 06:04 | MikeSeth | I spent several hours contemplating the BSP documentation and uboot's hdmi code |
| 06:05 | MikeSeth | I'm curious what causes the clocking issue |
| 06:05 | MikeSeth | tbh I should've paid more attention and just order i4pro instead |
| 06:10 | jnettlet | hmmm, freescale seems a bit flaky this morning |
| 06:11 | MikeSeth | their site's been slow and glitchy for several days |
| 06:11 | MikeSeth | should I get a pcduino board to play with? |
| 06:11 | jnettlet | sorry freenode |
| 06:11 | jnettle | 06:11 * jnettlet is still just a few sips of coffee in at 6AM |
| 06:11 | MikeSeth | well, make that weeks then ;) |
| 06:11 | MikeSeth | 7 am here |
| 06:12 | MikeSeth | gonna go to work and hack on credit card processing |
| 06:13 | MikeSeth | jnettlet: can you point me to cubox patches for barebox? |
| 06:19 | jnettlet | Marmotte, |
| 06:19 | jnettlet | woops, sorry |
| 06:19 | jnettlet | yeah hold on I am going to try and reconnect |
| 06:21 | jnettlet | Any better. |
| 06:21 | jnettlet | ah yes |
| 06:21 | jnettlet | MikeSeth, it is commit f87af10fb158033 |
| 06:21 | jnettlet | It is just a flash-header, and then a .dts |
| 06:22 | jnettlet | barebox uses device-tree like the kernel |
| 06:48 | jnettlet | blah, barebox has SPL compatibility but doesn't support the initial bootstrap. |
| 06:55 | MikeSeth | jnettlet: I will look |
| 06:55 | MikeSeth | this is somewhat exciting |
| 07:35 | jnettle | 07:35 * jnettlet is in heaven. The barebox code is so much nicer to read. |
| 08:16 | hste | jnettlet: so u think its easier to get it working? |
| 08:17 | jnettlet | hste, well basic support is already there. I think I can have SPL working by the end of the day. USB already works, will need to add HDMI |
| 08:18 | jnettlet | but that should take less than an hour |
| 08:18 | jnettlet | oh and support for the LED, so we can flash error codes for the Cubox-i users that don't have serial ports |
| 08:19 | jnettlet | and it is all based off kernel drivers/device-tree model. Yet another reason to extract the kernels .dts files out to a separate repository |
| 08:20 | jnettlet | Stop the duplication! |
| 08:20 | hste | :) |
| 08:30 | jnettle | 08:30 * jnettlet saw jaz-hacks ask about a Mutex deadlock. wonders what he was doing to trigger that. My alpha kernel might not have all the recent patches as well |
| 08:32 | hste | jnettlet: jas-hacks working on a kernel for udoo |
| 08:34 | hste | jnettlet: do u think your kernel will be ready this month? |
| 08:35 | jnettlet | hste, yep. I think _rmk_ and companies upstream work resolved a couple of the steps I had to look at. |
| 09:49 | jnettle | 09:49 * jnettlet regrets not doing barebox earlier their PBL is such a nicer implementation than SPL. |
| 09:50 | dv_ | jnettlet: nice |
| 09:50 | dv_ | jnettlet: please mention this to the meta-fsl guys too :) |
| 09:51 | jnettlet | will do once I get something working and posted |
| 09:51 | dv_ | alright |
| 09:51 | dv_ | I think a bootloader that is easier to patch and work with is also in their interest |
| 09:54 | dv_ | dshankar: I can send the patches today. I dont have much time for detailed instructions though |
| 09:55 | dshankar | dv_: awesome! |
| 09:55 | dshankar | that's fine. is it more complex than just a git diff patch? |
| 09:56 | dv_ | yeah. it involves several parts in chromium and openembedded recipes |
| 09:56 | dv_ | the latter are straightforward to read though |
| 09:56 | dshankar | ok |
| 09:56 | dshankar | would a chromium binary be simpler? |
| 09:57 | dv_ | oh hell no. chromium binaries are huge, and probably have hidden dependencies that would bite you |
| 09:57 | dshankar | hahaha true |
| 09:58 | dshankar | the chromium src is quite the monstrosity. i've been hacking around for the past month. kind of a nightmare |
| 09:59 | dv_ | yeah. and if you have less than 16 GB RAM, dont plan on developing much on it |
| 10:00 | dshankar | that's the worst part. i have no cross compile platform. I'm working right on the 1GB i.mx6Q :( |
| 10:00 | dv_ | you build chromium on the imx6?? |
| 10:00 | dshankar | yeah |
| 10:00 | dv_ | that is insane! |
| 10:01 | dshankar | took a very, very long time |
| 10:01 | dv_ | ehm .... why not use something like yocto/openembedded? |
| 10:01 | dshankar | because I'm still a noob ;-) |
| 10:02 | dv_ | honestly, look into yocto, and meta-fsl-arm |
| 10:02 | dv_ | it will save you SO much time |
| 10:02 | dshankar | hm ok I will |
| 10:05 | dshankar | After the first chromium build, subsequent patching & rebuilding didn't take very long. testing your previous patch just took a few minutes to make a new build. I was pleasantly surprised :-) |
| 10:05 | dshankar | But for the future, I'll have to look into OE |
| 10:06 | dv_ | easiest option is to use yocto, which gives you a ready-to-use OE version |
| 10:07 | dshankar | cool |
| 10:08 | dshankar | the previous VPU patch you sent -- the display kept crashing after ~2 minutes of decoding a video. have you seen that problem before? |
| 10:09 | dv_ | hmm no |
| 10:09 | dshankar | if I stopped the video playback, the display resumed normally. |
| 10:41 | jnettlet | jas-hacks, ping |
| 10:42 | dv_ | dshankar: when I get the chance I will try it out again |
| 10:42 | dv_ | I am curious about chromium on the cubox-i |
| 10:42 | dshankar | dv_: thanks |
| 10:43 | MikeSeth | beside the hb, any other interesting imx6 board to play with for driver development and such? |
| 10:44 | jnettlet | dv_, I have chromium on the cubox-i....it uses a lot of RAM. Make sure you have the i4pro model :-) |
| 11:01 | jas-hacks | jnettlet: hi |
| 11:01 | jnettlet | jas-hacks, were you using my kernel and you got the mutex stall error? |
| 11:01 | jnettlet | if so what were you doing? |
| 11:04 | jas-hacks | jnettlet: I used the vanilla 3.10.17_1.0.0_beta. Seems there is problem with initialising hdmi detection in uboot and it causing hangs in the kernel, my symptoms were a mutex deadlock in galcore |
| 11:05 | jnettlet | jas-hacks, oh yeah. I have that fixed. |
| 11:06 | jas-hacks | jnettlet: oh good, point me to the patches and I can test. |
| 11:07 | jnettlet | jas-hacks, I will be posting my updated linux-linaro lts kernel with merged upstream patches along with mine and fsl's 17-beta code later today. |
| 11:07 | jnettlet | you can play with it then |
| 11:11 | jas-hacks | jnettlet: any ideas on how you declare gpio settings when powering down the imx6 in the dts? |
| 11:56 | jnettlet | jas-hacks, why do you want to declare gpio settings when you are powering down the SOC? |
| 11:57 | MarcusVinter | hey jas-hacks, thanks for the debian |
| 11:58 | jas-hacks | jnettlet: on the UDOO the SAM3X chip needs to be power down and its done through a gpio pin |
| 11:59 | jnettlet | jas-hacks, what initializes the sam3x chip? |
| 11:59 | jnettlet | does it have a driver in the kernel? if so then you would want to shut it down from there. Same as if you rmmod'd the module |
| 12:03 | jas-hacks | jnettlet: I create a driver but it seems a bit over the top for 1/2 pins. I was going to declare a regulator with a gpio pin however I only see a property 'enable-at-boot'. |
| 12:03 | jas-hacks | s/I/I can |
| 13:16 | jnettle | 13:16 * jnettlet is somewhat relieved that the mutex hang is on the default kernel and not the updated driver. |
| 14:24 | dv_ | jnettlet: "There are already barebox users in meta-fsl-arm." |
| 14:29 | jnettlet | dv_, excellent |
| 14:39 | jnettle | 5v - 12v DC convert with multiple breakout cables that can accept various tips |
| 17:03 | MarcusVinter | quiet here today. |
| 17:04 | jnettlet | MarcusVinter, how did things go today? |
| 17:19 | MarcusVinter | My boss is still in talks with a possible partner/investor in a meeting the last 6 hours. He loved the cubox anyway and what we are doing with it so I will see later on today when my boss surfaces lol. |
| 17:20 | MarcusVinter | It's looking good though. |
| 17:21 | MarcusVinter | He was asking about the wireless bluetooth stuff but I just told him it's possible but still needs a little bit of work lol |
| 17:21 | MarcusVinter | He seemed to accept that though. |
| 17:21 | MarcusVinter | :P |
| 17:21 | dv_ | cubox-i you mean? |
| 17:22 | jnettle | 17:22 * jnettlet thinks that is a losing battle |
| 17:22 | dv_ | why? |
| 17:23 | dv_ | is imx6 bluetooth that bad? |
| 17:23 | jnettlet | no battling between people calling it the cubox vs cubox-i |
| 17:23 | jnettlet | the bluetooth shouldn't be a problem. Just will take some time and config. |
| 17:23 | dv_ | ah :) |
| 17:24 | jnettle | 17:24 * jnettlet is battling with getting his trimslice back up and running |
| 17:27 | MarcusVinter | :o hes out hte meeting. |
| 17:27 | MarcusVinter | the* |
| 17:27 | MarcusVinter | well this guy will possibly be leading us to a client of over 4000 emplyees. and thats for starters. |
| 17:27 | MarcusVinter | all of which will be getting cubox-i |
| 17:27 | MarcusVinter | If all goes to plan. |
| 17:28 | MarcusVinter | I'm a bit out of my depth but still swimming lol |
| 17:28 | jnettlet | sounds good. whats my cut :-) |
| 17:29 | MarcusVinter | You get the warm feeling knowing you helped a product you worked on get around the world |
| 17:29 | MarcusVinter | haha |
| 17:29 | MarcusVinter | so nothing |
| 17:29 | MarcusVinter | a kick in the teeth |
| 17:29 | MarcusVinter | lol |
| 17:30 | _rmk_ | meh. see, open sauce is soo overrated :) |
| 17:32 | jnettlet | yep weak sauce |
| 17:33 | _rmk_ | probably with lots of sugar in. |
| 17:35 | jnettlet | sounds like Danish sauce to me |
| 17:52 | jas-hacks | mxc_hdmi has a mind of its own, it sets the resolution to 1280x720, then 640x480 and back to 1280x720 |
| 17:56 | _rmk_ | sounds like I'm doing the right thing then, not using the fbdev stuff :) |
| 17:59 | jas-hacks | _rmk_: yeah, it also decides to reconfigure it again when I start X |
| 18:11 | MarcusVinter | Wow I've just been givem company shares. |
| 18:11 | MarcusVinter | Winning |
| 18:11 | MarcusVinter | given* |
| 19:58 | jmontleon | _rmk_, using your diff from 20140120 against 3.13.0 leaves me with only the top usb port functioning; going back to the older rc7 stuff gets it back; haven't tried mixing and matching kernel/dtb |
| 20:21 | _rmk_ | jmontleon: ok, thanks for letting me know, let me have a prod |
| 20:22 | _rmk_ | did you boot with something plugged in to the lower port? |
| 20:22 | jmontleon | _rmk_, yes |
| 20:23 | jmontleon | can try again with it removed |
| 20:23 | jmontleon | or verify, that was the case either way |
| 20:24 | _rmk_ | just wanting to try to reproduce in the same way |
| 20:26 | _rmk_ | jmontleon: which device? hummingboard or cubox-i* ? |
| 20:26 | _rmk_ | root@cubox-i4:~# lsusb |
| 20:26 | _rmk_ | Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver |
| 20:26 | _rmk_ | Bus 002 Device 002: ID 04b4:0001 Cypress Semiconductor Corp. Mouse |
| 20:27 | jmontleon | cubox-i4 |
| 20:28 | _rmk_ | yep, my wired cypress mouse seems to work in the lower socket |
| 20:29 | _rmk_ | what does cat /sys/kernel/debug/gpio say - the first&second lines will do |
| 20:30 | jmontleon | one moment, rebooting |
| 20:34 | jmontleon | and now it's working |
| 20:34 | jmontleon | smh, i rebooted at least a couple times |
| 20:34 | jmontleon | oh well, if I see it again I'll cat /sys/kernel/debug/gpio for you |
| 20:34 | _rmk_ | weird |
| 20:34 | _rmk_ | it should look like this: |
| 20:34 | _rmk_ | GPIOs 0-31, platform/209c000.gpio, 209c000.gpio: gpio-0 (usb_h1_vbus ) out hi |
| 20:34 | jmontleon | let me try with nothing plugged in this time |
| 20:35 | _rmk_ | gah |
| 20:35 | _rmk_ | GPIOs 0-31, platform/209c000.gpio, 209c000.gpio: |
| 20:35 | _rmk_ | gpio-0 (usb_h1_vbus ) out hi |
| 20:35 | _rmk_ | the "hi" bit being the important thing - that turns the power on to the port |
| 20:36 | jmontleon | oh, there we go |
| 20:36 | jmontleon | with nothing plugged in it is gone |
| 20:37 | _rmk_ | so you mean it doesn't detect when you plug in... |
| 20:38 | _rmk | 20:38 * _rmk_ tries... so what - unplug all usb, power up, wait for boot to finish, plug into lower socket, and nothing is detected? |
| 20:38 | jmontleon | upper is the one acting flaky, but yes |
| 20:38 | jmontleon | lower seems to work no matter what |
| 20:42 | jmontleon | http://ur1.ca/gh1uu |
| 20:43 | _rmk_ | that's interesting... why is gpio 86 low... |
| 20:44 | _rmk_ | for the non-working one, can you provide a dmesg log please? |
| 20:44 | jmontleon | sure |
| 20:44 | _rmk_ | also: ls -al /sys/bus/platform/drivers/ci_hdrc too |
| 20:46 | NetScr1be | anyone able to build etnaviv drivers and cgminer? |
| 20:48 | NetScr1be | for original cubox |
| 21:03 | jmontleon | _rmk_, dmesg: http://ur1.ca/gh244 ls: http://ur1.ca/gh246 |
| 21:06 | jmontleon | using new kernel with old dtb seems to be ok |
| 21:07 | _rmk_ | I'm looking at around line 363, it looks like it hasn't found the 1st USB |
| 21:09 | jmontleon | possible it's a difference in u-boot? I have 2013.10-rc4-g920ea0f |
| 21:09 | _rmk_ | found the problem. |
| 21:10 | jmontleon | operator error? :) |
| 21:10 | _rmk_ | something missing... |
| 21:10 | _rmk_ | append to arch/arm/boot/dts/imx6qdl-microsom.dtsi: |
| 21:10 | _rmk_ | &usbotg { |
| 21:10 | _rmk_ | pinctrl-names = "default"; |
| 21:10 | _rmk_ | pinctrl-0 = <&pinctrl_microsom_usbotg>; |
| 21:10 | _rmk_ | }; |
| 21:17 | _rmk_ | can you try adding that and checking that it fixes the problem please? |
| 21:20 | jmontleon | interestingly that just put me back to the -110 errors booting that jnettlet was able to fix by adding MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1f071 under pinctrl_cubox_i_usdhc2: cubox-i-usdhc2 { |
| 21:23 | dv_ | hey what was that command to accelerate the VPU? it did something to its bus access I think |
| 21:24 | dv_ | I vaguely remember it being a devmem2 command |
| 21:25 | rabeeh | dv_: devmem 0x020e0018 32 0xffffffff |
| 21:25 | dv_ | thanks |
| 21:25 | rabeeh | http://server.vijge.net/static/cubox/irclog/201311/cubox-20131127.html |
| 21:26 | _rmk_ | jmontleon: hmm, that's interesting... KEY_ROW1 according to rabeeh's github is aud5_rxd... |
| 21:29 | rabeeh | KEY_ROW1 is SD2_VSELECT for CuBox-i |
| 21:29 | rabeeh | HB doesn't have audio select |
| 21:29 | rabeeh | HB doesn't have voltage select |
| 21:30 | jmontleon | I honestly have no idea how he came up with that - just that he was having trouble booting, and it fixed it for both of us. this time around, not so much though |
| 21:31 | _rmk_ | rabeeh: ah, so, is https://github.com/SolidRun/linux-imx6/blob/imx_3.0.35_4.1.0/arch/arm/mach-mx6/board-mx6q_microsom.h incorrect? |
| 21:32 | _rmk_ | or should I be looking elsewhere? |
| 21:33 | rabeeh | _rmk_: you are in the right place; it's a bug |
| 21:34 | _rmk_ | now, I wonder why jnettlet used 0x1f071 |
| 21:36 | rabeeh | _rmk_: sorry; i'm a bit scattered; where is 0x1f071? |
| 21:36 | _rmk_ | that's: hys | 22K_UP | PUE | PKE | SPEED_LOW | DSE_40ohm | SLOW |
| 21:36 | _rmk_ | see jmontleon's comment above |
| 21:37 | rabeeh | ok. |
| 21:37 | _rmk_ | does that look reasonable for sd2_vselect? |
| 21:37 | _rmk_ | ergh, not SLOW... it's FAST |
| 21:37 | _rmk_ | HYS | 22K_UP | PUE | PKE | SPEED_LOW | DSE_40ohm | FAST |
| 21:38 | rabeeh | on the board there is a 10kohm pull down to force 3.3v on boot (R3011) |
| 21:38 | rabeeh | that's on the carrier board |
| 21:39 | _rmk_ | we're talking about the Cubox-i configuration for SD2_VSELECT |
| 21:39 | rabeeh | i understand |
| 21:39 | rabeeh | what was the failing configuration? |
| 21:39 | cbxbiker61 | rabeeh, my micro-usb power plug pulled away from the board, i can just push power in on the header pins, can't i? |
| 21:40 | rabeeh | cbxbiker61: what? |
| 21:40 | _rmk_ | I'm just trying to work out whether that's a correct config to put into DT for configuring iomux |
| 21:40 | cbxbiker61 | on the humming board the usb power connect failed/pulled away from the board, not soldered very effectively |
| 21:41 | rabeeh | cbxbiker61: ok; i thought that was cubox-i |
| 21:41 | rabeeh | you can apply voltage on the +5V and GND on the header |
| 21:41 | cbxbiker61 | good |
| 21:41 | rabeeh | notice that this power bypasses some filters and a 5A fuse :) |
| 21:41 | rabeeh | well.. 2A in the old HB case |
| 21:43 | rabeeh | _rmk_: i'm looking at the SPDT switchover for the 3.3v / 1.8v switchover and i think i found an issue |
| 21:43 | rabeeh | the VIH for the switchover is 0.8v |
| 21:44 | rabeeh | so given that the supply is 3.3v, external pull down of 10kohm and internal pullup of 22kohm would give 1V |
| 21:45 | rabeeh | so the SPDT might think that it needs to switch to 1.8v voltage rail !!! |
| 21:46 | rabeeh | so a good idea is to keep the pullup value to 100kohm; or instead of 22k_up use the internal pull down |
| 21:51 | _rmk_ | ok, so that's PUS_100K | PUE | PKE | SPEED_LOW | DSE_40ohm | SRE_FAST |
| 21:51 | _rmk_ | I guess keep HYS too |
| 21:55 | _rmk_ | jmontleon: can you try adding this: http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.13-20140120-errata.diff please? |
| 21:56 | jmontleon | definitely |
| 21:56 | _rmk_ | I wonder what other changes jnettlet has... |
| 21:58 | _rmk_ | okay, my mmc still seems to work, and I still get two usb ports |
| 22:02 | jmontleon | _rmk_, thanks, now it boots and I get 2x USB :D |
| 22:02 | _rmk_ | yay, thanks for testing... I'll merge those changes into the original two commits |
| 22:04 | rabeeh | _rmk_: notice that the power up value of the pad is 100k pullup, which is 0.3V |
| 22:04 | jmontleon | does mmc go at UHS speed now? I don't see the message it used to give about not being able to go full speed; /me isn't sure when that disappeared |
| 22:06 | jmontleon | snow-- |
| 22:06 | _rmk_ | I have no UHS cards to check with |
| 22:10 | jmontleon | oh, no, there it is: sdhci-esdhc-imx 2194000.usdhc: could not get ultra high speed state, work on normal mode |
| 22:10 | jmontleon | still seems pretty fast though |
| 22:14 | _rmk_ | ah, I need to add the 100 and 200mhz pinctrl states |
| 22:33 | _rmk_ | jmontleon: have another patch to go on top of that previous one: http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.13-20140120-errata-usd.diff |
| 22:34 | jmontleon | cool, trying now |
| 22:46 | jmontleon | _rmk_, http://paste.fedoraproject.org/70487/40758139/ |
| 22:53 | _rmk_ | wonder if it doesn't like the pinctrl values for cd etc being specified in the other states |
| 23:00 | jmontleon | which ones are those, I can delete them and try again, if it's that simple |
| 23:01 | _rmk_ | try dropping &pinctrl_cubox_i_usdhc2_aux from pinctrl-1 and pinctrl-2 |
| 23:05 | jmontleon | same error |