| 00:01 | _rmk_ | neofob_home: when we go to the local, we have a brew called Shere Drop - http://www.surreyhills.co.uk/9089.html |
| 00:10 | _rmk_ | Ok, I think I'll look at this tomorrow when there's better light. |
| 00:14 | _rmk_ | rabeeh: ok, so it needs to be cut between U304 and CN501? |
| 00:15 | _rmk_ | as it's on the corner pin of U304, that should be easier than I was expecting :) |
| 00:16 | _rmk_ | err, not CN501, J3 |
| 00:31 | _rmk_ | rabeeh: it would also be nice to know where this has been fixed - on the microsom or on the carrier1 board? |
| 00:32 | _rmk_ | that detail is useful for working out what should be where in the DT files |
| 00:35 | _rmk_ | well, it still appears to boot with the pinmux changes :) |
| 13:06 | rabeeh | _rmk_: another option to rework CEC is by sacrificing an HDMI cable for that |
| 13:06 | rabeeh | remove the black plastic, then shield and then cut the CEC line and rewire to the 8 pin header |
| 13:07 | rabeeh | i think that hdmi cable signals are color coded |
| 13:07 | rabeeh | so you can identify which wire to cut and rewire |
| 13:10 | _rmk_ | rabeeh: I've no problem with modding the board |
| 13:11 | _rmk_ | I just need confirmation that I need to cut that track between U304 and J3. |
| 13:11 | _rmk_ | because I notice that it also goes to a via in the middle of J3 |
| 13:16 | _rmk_ | bah |
| 13:19 | jnettlet_ | _rmk_, are you modding the board to prove that it fixes the problem? |
| 13:20 | _rmk_ | jnettlet: and so that it can be tested :) |
| 13:22 | jnettlet_ | _rmk_, I have an hdmi cable tester that will give me the status of the CEC line |
| 13:22 | _rmk_ | once the mod is done, it'll be accessible on the 8 pin header |
| 13:23 | _rmk_ | and I've already updated the DT files for this |
| 13:23 | jnettlet_ | okay |
| 13:25 | _rmk_ | I'm not un-used to SMT rework - I've replaced such things as a 52 pin TSSOP flash chip in the past for example. I've re-worked one of those SMT 8pin resistor packs after two pins grew a lead-free solder whisker between them... I'm not unfamiliar with this kind of stuff |
| 13:26 | _rmk_ | and I have various gauges of enameled copper wire which I can use for this (I've wound my own flyback SMPS transformers) |
| 13:27 | jnettlet_ | I have never doubted it. Just figured if rabeeh had already fixed it on the board he could just ship out new boards. |
| 13:31 | _rmk_ | ah, rabeeh is back, guess you didn't see my reply |
| 13:31 | _rmk_ | rabeeh: I've no problem with modding the board |
| 13:31 | _rmk_ | I just need confirmation that I need to cut that track between U304 and J3. |
| 13:31 | _rmk_ | because I notice that it also goes to a via in the middle of J3 |
| 13:53 | dv | 13:53 * dv_ just found out that the carrier one's connectors are not exactly on the same place as they are on the rpi |
| 13:53 | dv_ | which kinda sucks if you wanna use an rpi case |
| 14:16 | jnettlet_ | dv_, rabeeh has fixed that in the "next gen" but the dev boards require some case modding |
| 14:31 | _rmk_ | yea, see my post on g+ :) |
| 15:09 | taz | hi |
| 15:09 | taz | I made a video about "u-boot restore" : http://www.youtube.com/watch?v=-gBoELdllnY :) |
| 15:11 | taz | thanks rabeeh your new uImage is working !!! |
| 15:11 | taz | i write about it on the forum |
| 15:36 | _rmk | 15:36 * _rmk_ hmms, rabeeh isn't confirming, so I'm not cutting. |
| 15:55 | neofob_home | just so you all know, i cross-compiled linux-stable v3.12 and it works fine for me |
| 15:55 | _rmk | 15:55 * _rmk_ wonders what D303 and R308 are other than a schottky diode and a 10k resistor |
| 15:56 | neofob_home | till I try to mount an LVM drive, I get some mlock: fail to allocate memory? |
| 15:56 | _rmk_ | neofob: it sort of does, except you won't have working SD card detection |
| 15:56 | _rmk_ | and if you try and use imx-drm, you won't have HDMI output |
| 15:57 | neofob_home | _rmk_: i use the usb serial for console so it's ok for me |
| 15:57 | _rmk_ | that's kind'a the point: at the simplest level, it's just another i.MX6 SoC, and it will boot as just another i.MX6 SoC. |
| 15:57 | neofob_home | oh, this is the cubox with marvell chip |
| 15:58 | _rmk_ | ah. yes, shesselba has been working on that with mainline |
| 15:58 | neofob_home | the main line still doesn't have support for jumbo frame for this marvell |
| 16:00 | neofob_home | so this marvell 510 does not do hardware offload checksum fr mtu greater than 1600, so we need to turn that off for mtu greater than 1600 |
| 16:00 | _rmk_ | ok, D303 / R308 is to pull the CEC line up to 3.3v but not load it when powered off |
| 16:00 | neofob_home | is that the same for other marvell chips? |
| 16:06 | _rmk_ | don't know off hand, I'd have to check the info I have. |
| 16:09 | neofob_home | rabeeh has the patch for it from his 2.6.32 tree but it didn't make it to mainstream |
| 16:09 | neofob_home | I save it here: https://gist.github.com/neofob/3158055 |
| 16:33 | _rmk_ | rabeeh? |
| 17:23 | rabeeh | _rmk_: here |
| 17:25 | rabeeh | the otherside of the board with the schotky diode is important as you said |
| 17:25 | rabeeh | to pull the line to 3.3v but not get it loaded from other devices when the C1 is powered off |
| 17:25 | rabeeh | (otherwise 3.3v will be available on the board while 5v isn't which might burn imx6 io pads) |
| 17:26 | _rmk_ | so the the idea is to leave the pin on the SOM connector J3 disconnected from both U304 and D303 |
| 17:27 | rabeeh | yes. but then you must keep C1 powered up all the time |
| 17:27 | rabeeh | so; if you look at my other notes that you can do the same trick on the hdmi cable itself |
| 17:28 | rabeeh | i.e. remove the black plastic on the hdmi cable; remove the shielding and then find the cec line |
| 17:28 | rabeeh | cut it and rewire to key_row2 |
| 17:28 | _rmk_ | So, disconnect J3 65:L from U304 and D303, connect U304 to D303 to CON502 pin 5 |
| 17:28 | rabeeh | this is equivalent |
| 17:30 | rabeeh | yes. this is the full solution if you want also to be able to protect the 3.3v rail on the board |
| 17:30 | rabeeh | there is another option to wait a week and get a new board :) |
| 17:30 | rabeeh | the fixed microsom and CuBox-i carriers |
| 17:34 | rabeeh | _rmk_: i would go for cutting the hdmi cable; it's much more easier |
| 17:35 | lioka | using something like pulse-eight adapter is even more easy |
| 17:37 | rabeeh | lioka: but the idea is using the native cec |
| 17:37 | rabeeh | _rmk_ is suspect cares only about the challenge |
| 17:37 | rabeeh | _rmk_ i suspect cares only about the challenge |
| 17:45 | rabeeh | neofob: some Marvell devices has TCP checksum with jumbo frames and some doesn't |
| 17:45 | rabeeh | Armada 510 does support that |
| 17:45 | _rmk_ | well, you did set me a challenge last night :) |
| 17:46 | rabeeh | _rmk_: you can ruin the board if you want |
| 17:47 | rabeeh | this weekend we refilled the C1 inventory; i can send you more :) |
| 17:47 | rabeeh | but given the navy blue color it makes it a bit more tough to pick the right traces and remove them. |
| 17:50 | jnettlet_ | rabeeh, I may need to request a new board seeing as mine has a hard soldered wire to power it, and that main fuse removed. |
| 17:51 | jnettlet_ | oh and it won't hard reset. |
| 17:51 | jnettlet_ | sorry soft reset, hard reset does work |
| 17:51 | rabeeh | hard soldered to wire the power? |
| 17:51 | rabeeh | your micro usb was ripped off? |
| 17:51 | _rmk_ | one more connection to go :) |
| 17:51 | _rmk_ | and its the easy one |
| 17:52 | jnettlet_ | yep. My micro-usb connector sheared off at the board level. |
| 17:52 | rabeeh | was it soldered beneath in the 4 mechanical connectors? |
| 17:52 | rabeeh | i mean do you recall that or not? |
| 17:52 | jnettlet_ | yeah my fixup soldering job was intact. The feet were still soldered underneath. It had weakend and broken off from excessive sdhc card removal. |
| 17:53 | rabeeh | so; is this something we need to worry about? |
| 17:53 | rabeeh | i mean from board build point of view? |
| 17:53 | rabeeh | should we change micro USB vendor? because for now we had minor issues with it |
| 17:53 | rabeeh | (all previous CuBoxes were sent with that connector) |
| 17:54 | jnettlet_ | I don't think so. I think it was an excessive use case from me working on u-boot |
| 17:54 | rabeeh | ok. great |
| 17:54 | rabeeh | jnettlet_: will requeue you another C1 |
| 17:55 | jnettlet_ | not many people are going to "hack on uboot" pick up board, remove card, flash card, pick up board, plug in, test. repeat 500 times :-) |
| 17:55 | _rmk_ | yep, pin 13 on the hdmi is now connected to pin 5 on the 8pin header |
| 17:55 | rabeeh | _rmk_ picture please :) |
| 17:56 | jas-hacks_ | a 2/4 pin header so that a (on/off) switch or reset button could be attached would be very useful |
| 17:56 | _rmk_ | I still have the track to cut on the top side... pic after that |
| 17:56 | jnettlet_ | jas-hacks_, there is a reset pin |
| 17:56 | rabeeh | jas-hacks_: reset or on/off? |
| 17:56 | jnettlet_ | jas-hacks_, pin 7 on the 8pin header |
| 17:56 | jnettlet_ | you need to pull it low |
| 17:56 | jas-hacks_ | pin 7 is reset? |
| 17:56 | jnettlet_ | yep |
| 17:56 | rabeeh | http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware |
| 17:57 | rabeeh | jas-hacks_: you can short 7 and 6 |
| 17:57 | jas-hacks_ | good to know, especially when I get my uboot script wrong |
| 17:57 | rabeeh | but jas-hacks_: what's really important for you? getting reset done or getting power on/off? |
| 17:58 | jas-hacks_ | power on/off would be useful, not many boards have one |
| 17:58 | rabeeh | but would you use it to get power cycle or you would really want it to power off? |
| 17:59 | jas-hacks_ | power off is useful when you have devices attached |
| 17:59 | rabeeh | i mean power cycling it to test more u-boots and kernels? or you really want it to power down |
| 17:59 | rabeeh | attached where? usb |
| 17:59 | rabeeh | you can power down the usb |
| 17:59 | rabeeh | and keep the system alive |
| 17:59 | rabeeh | that's the usb_pwr_en gpio |
| 18:01 | jas-hacks_ | power down is useful if you interface with other boards through the headers |
| 18:01 | jas-hacks_ | can the board be powered through the header? Not a fan of micro usb |
| 18:03 | rabeeh | you can drive the 5V in directly i think |
| 18:04 | rabeeh | it would probably work on the solo |
| 18:05 | rabeeh | jas-hacks_: yes. it works; just booted with +5v attached to pin 1 on the 8 pin header |
| 18:05 | rabeeh | but notice this is +5V of the board after being filtered and after the fuse |
| 18:06 | rabeeh | means over voltage and the board is dead ! |
| 18:07 | jas-hacks_ | any plans to add some pins for power? |
| 18:07 | rabee | 18:07 * rabeeh wonders if _rmk_ disappearing means cec is working or he is on his way to the hospital after cutting his finger |
| 18:07 | rabeeh | jas-hacks_: for what? |
| 18:08 | rabeeh | like two pin header for +5V and GND? |
| 18:08 | jas-hacks_ | yes |
| 18:08 | rabeeh | yes. there is an assembly option for a bigger DC jack |
| 18:08 | jas-hacks_ | or even better support 5-12V |
| 18:08 | jnettlet_ | or hacking was temporarily postponed due to dinner |
| 18:09 | rabeeh | jas-hacks_: we kept the micro USB so people won't do mistakes and put > 5V |
| 18:09 | rabeeh | (and that's why DC jack also is not assembled) |
| 18:10 | rabeeh | but there is a bigger issue that quad + 2 power usb is ~2.5A |
| 18:10 | rabeeh | which makes it very challenging to get a micro USB psu for that (given that the spec for those connectors is also 2A) |
| 18:10 | jas-hacks_ | rabeeh: that's why 12v is good |
| 18:10 | jnettlet_ | but that is peak. |
| 18:10 | rabeeh | jnettlet_: it's sustain |
| 18:11 | rabeeh | peak is even higher |
| 18:11 | jnettlet_ | oh. |
| 18:11 | rabeeh | jnettlet_: for instance if you run xbmc gui; it endlessly uses the gpu to render (given dirty regions is disabled) |
| 18:12 | rabeeh | if you have some heavy indexing of a new content directory then it will hog the processor for a long time too |
| 18:12 | rabeeh | so it's not a micro / msec peak; it can take seconds and more |
| 18:12 | jnettlet_ | okay, but that should just need the 3d core enabled and probably running at the lowest frequency |
| 18:13 | rabeeh | jnettlet_: in our approach we treat C1 as a desktop rather than battery powered |
| 18:13 | rabeeh | meaning worst case power consumption must be handled in power dissipation wise |
| 18:13 | jnettlet_ | oh...not in my driver :-) |
| 18:13 | rabeeh | XO? |
| 18:14 | rabeeh | in the imx6 there is is some sort of protection that when it comes to 90c it lowers the processors to 800mhz and gpu to 1/64 of it's full clock speed |
| 18:14 | jnettlet_ | C1 right now. Don't get me started on the XO because of the way the scaling is implemented I have to keep it at fixed frequency. |
| 18:14 | jnettlet_ | but I am trying to work around that. |
| 18:15 | rabeeh | jnettlet_: but how would you decide when to scale the frequency? |
| 18:15 | jnettlet_ | based on number of events to process |
| 18:15 | rabeeh | i mean there is xbmc that is hogging the gpu and trying to squeeze it to get maximum fps |
| 18:16 | jas-hacks_ | rabeeh: would it not have been better to have ethernet + usb + hdmi + audio ports on the same side of the pcb? |
| 18:16 | _rmk_ | I have CEC data on pin 5 :) |
| 18:16 | jnettlet_ | _rmk_, hurrah! |
| 18:16 | rabeeh | _rmk_: bravo |
| 18:16 | rabeeh | you are my hero |
| 18:17 | _rmk_ | and photos too |
| 18:17 | rabee | 18:17 * rabeeh opens a bottle of Champagne and offers it to the devs on #cubox |
| 18:18 | rabeeh | oh; i guess _rmk_ prefers beer |
| 18:19 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/IMG_1559.JPG |
| 18:19 | _rmk_ | bottom side |
| 18:19 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/IMG_1558.JPG |
| 18:19 | _rmk_ | top side |
| 18:19 | _rmk_ | and yes, it did take some patience and steady hands to do the top side |
| 18:21 | jnettlet_ | looks good |
| 18:23 | rabeeh | _rmk_: did you expose some vias too? |
| 18:23 | _rmk_ | no, I left the vias alone. |
| 18:23 | _rmk_ | the cuts are right at the corner of U304 and right next to D303 on the bottom side |
| 18:24 | rabeeh | i'm referring to the vias where the 'E310444' silk is |
| 18:24 | rabeeh | what have you been doing to the board? |
| 18:24 | _rmk_ | no, didn't touch those at all |
| 18:24 | rabeeh | the whole surface looks dirty |
| 18:25 | _rmk_ | there's some isopropyl alcohol around there to clean the flux away |
| 18:25 | rabeeh | ok |
| 18:25 | rabeeh | it's not generated because of heat - right? |
| 18:25 | _rmk_ | nope |
| 18:25 | rabeeh | even if you super heat the microsom there is no way heat can get transffered to the bottom board and damage it |
| 18:28 | _rmk_ | so what I've done is equivalent to your solution? |
| 18:28 | rabeeh | yes |
| 18:29 | rabeeh | well.. almost |
| 18:29 | rabeeh | the original signal hdmi_tx_ddc_cec is wired to gnd now |
| 18:29 | rabeeh | on the micrsom |
| 18:29 | rabeeh | _rmk_ did you change anything on the micro USB? |
| 18:30 | _rmk_ | no |
| 18:30 | rabeeh | did you solder anything on it? |
| 18:30 | _rmk_ | I left that signal floating at the moment, which probably isn't good for the long run |
| 18:30 | _rmk_ | btw... /sys/class/thermal/thermal_zone0/temp:67952 |
| 18:30 | rabeeh | it looks like resoldered to make it more mechanically |
| 18:31 | rabeeh | ? |
| 18:31 | rabeeh | what about the thermal diode? |
| 18:32 | rabeeh | _rmk_ i can see that the silk T401 near the micro USB has changed color |
| 18:33 | rabeeh | it was probably touched by a soldering iron; is it you or it was us? |
| 18:33 | _rmk_ | that was me - when you told us about the micro USB not being properly soldered, I made sure mine was :) |
| 18:33 | rabeeh | oh ok. |
| 18:34 | rabeeh | i referred to solder it on the print side |
| 18:34 | rabeeh | but thats great. |
| 18:34 | rabeeh | as an update; the C1 version 1.1 has most of things on top |
| 18:34 | rabeeh | on component side |
| 18:34 | _rmk_ | I looked at both sides, and decided there was the possibility to make it more secure with some careful attention on the top side |
| 18:35 | rabeeh | pci-e, DPAK and power management are all on top side |
| 18:35 | rabeeh | the main component on the print side is the msata |
| 18:35 | rabeeh | which would probably violate part of the pi's cases |
| 19:14 | dv_ | pengutronix presentation from the gstreamer conference: http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2013/GStreamer%20Conference%202013%20-%20Michael%20Olbrich%20-%20Multimedia%20on%20Embedded%20Linux:%20Pushing%20GStreamer%20to%20its%20Limits.pdf |
| 19:15 | dv_ | looks very cool on the surface, but some key points are vague |
| 19:18 | jas-hacks_ | dv_: Is it coming to imx6? |
| 19:18 | dv_ | well, they mention the imx53 |
| 19:19 | dv_ | so I guess yes |
| 19:19 | dv_ | but their todo list makes me skeptical that will be usable soon |
| 19:20 | dv_ | they are right though that the VPU API will never be mainlined , partially because its reliance on physical addresses is a huge security hole |
| 19:23 | _rmk_ | so basically the same mistake |
| 19:47 | dv_ | _rmk_: what do you mean? |
| 20:01 | _rmk_ | exposing physical addresses to userspace |
| 20:15 | taz_ | hi |
| 20:15 | taz_ | I write a post on my blog about u-boot repair : http://popax.blogspot.fr/2013/11/solidrun-cubox-v2-1gb-ram-repair-u-boot.html |
| 20:31 | rabeeh | taz_: great |
| 20:32 | taz_ | hi rabeeh ! |
| 20:32 | rabeeh | i will prepare a new cubox installer version 0.5 for that |
| 20:32 | taz_ | thanks a lot for your patience and your help :) |
| 20:32 | rabeeh | we need first to do some testing |
| 20:32 | taz_ | ok |
| 20:32 | taz_ | no problem |
| 20:32 | taz_ | i can do all tests you want |
| 20:32 | rabeeh | first if it works on hdmi also? |
| 20:32 | taz_ | (after my meal) |
| 20:32 | rabeeh | bon apetit |
| 20:32 | taz_ | hdmi : ok |
| 20:33 | taz_ | usb mouse dans keyboard ok |
| 20:33 | taz_ | h�h� merci :) |
| 20:33 | rabeeh | please install ubuntu 13.04 from sources (since it uses https) |
| 20:33 | taz_ | ok i notes |
| 20:34 | taz_ | i'll be back in 2H, is it ok ? |
| 20:38 | rabeeh | yes |
| 20:39 | rabeeh | taz_: i'm looking at your blog and make me blush |
| 21:00 | _rmk_ | rabeeh: have you been able to test CEC at all? |
| 21:05 | rabeeh | _rmk_: only that the KEY_ROW2 signals togles |
| 21:05 | rabeeh | but never connected to a real TV |
| 21:05 | rabeeh | there wasn't any risk in that at all |
| 21:06 | _rmk_ | yes, it does toggle... at about the right rate |
| 21:06 | _rmk_ | but occasionally it's out of spec |
| 21:06 | shesselba | neofob_home: If you come up with a patch, I will have a look at it |
| 21:06 | _rmk_ | genereally toggles at a bit period of 2.3ms (allowable is 2.05 to 2.75ms) |
| 21:07 | _rmk_ | occasionally I see a toggle at 1.9ms |
| 21:07 | rabeeh | ? |
| 21:07 | rabeeh | mSec |
| 21:07 | rabeeh | ? |
| 21:08 | _rmk_ | yep |
| 21:09 | rabeeh | why do i recall usec? |
| 21:09 | rabeeh | let me check |
| 21:09 | _rmk_ | consequently, its transmissions aren't recognised, and it doesn't recognise other transmissions |
| 21:09 | _rmk_ | CEC 5.2.2 definitely says msec |
| 21:10 | shesselba | rabeeh: _rmk_ is right, msec is the correct unit |
| 21:11 | _rmk_ | this is where I wish I had a logic analyser to capture this :) |
| 21:11 | _rmk_ | been thinking about getting one of these - http://www.bitscope.com/ |
| 21:13 | rabeeh | _rmk_: geexbox already supports c1 |
| 21:13 | rabeeh | and has imx6 cec already ported |
| 21:13 | rabeeh | so if you want to really test with a tv then this is a way |
| 21:13 | rabeeh | for the msec / usec; i was confused with the core clock |
| 21:13 | rabeeh | the cec core runs in mhz |
| 21:16 | rabeeh | _rmk_ are you measuring with your 50mhz scope? |
| 21:16 | rabeeh | could it be that the 1.9msec vs. min 2.05 is scope sampling rate issue? |
| 21:17 | _rmk_ | 60mhz analog scope |
| 21:18 | _rmk_ | does your kernel have nfsroot support? |
| 21:21 | rabeeh | yes |
| 21:22 | _rmk_ | ok, I'll try it with your kernel then |
| 21:37 | taz_ | hi i'm back |
| 21:38 | taz_ | rabeeh: i'm here :) what you would like i try ? |
| 21:38 | rabeeh | taz_: hi |
| 21:39 | rabeeh | please install ubuntu 13.04 from sources (since it uses https) |
| 21:39 | taz_ | ok |
| 21:40 | rabeeh | you don't need to do full installation; only the basic stuff |
| 21:41 | taz_ | ok |
| 21:41 | taz_ | booting the installer.. |
| 21:45 | sver | 21:45 * svere has send the email to DHL regarding customs |
| 21:45 | sver | 21:45 * svere crosses fingers |
| 21:46 | taz_ | "grabbing ubuntu core base image" |
| 21:46 | taz_ | download kernel module... |
| 21:46 | taz_ | progressing... |
| 21:47 | taz_ | the installation is running... |
| 22:01 | _rmk_ | rabeeh: I see a similar thing with your kernel too |
| 22:07 | taz_ | rabeeh: installation of ubuntu 13.04 : success ! |
| 22:07 | rabeeh | great |
| 22:07 | rabeeh | do you have a new cubox by a chance? |
| 22:07 | rabeeh | with the new SPI flash? |
| 22:08 | taz_ | a new ? what do you mean please? |
| 22:08 | rabeeh | ok. i will test the newer spi flash |
| 22:08 | rabeeh | if that passes then it can be released |
| 22:08 | rabeeh | i will prepare the package probably tonight / monday |
| 22:09 | rabeeh | taz_: thanks for testing |
| 22:09 | taz_ | rabeeh: the burn of u-boot success <- is your question ? |
| 22:11 | taz_ | rabeeh: do you want I do other tests ? |
| 22:12 | rabeeh | taz_: no; i think those are fine |
| 22:12 | taz_ | ok |
| 22:13 | taz_ | rabeeh: what about the binary tools to repair the cubox state about power (ftdi-bitbang-read/write). do you need I create an account on github to push it or will you put it on github ? |
| 22:19 | rabeeh | taz_: i'll do that. |
| 22:19 | taz_ | ok |
| 22:21 | taz_ | rabeeh: do you know if openbsd can run on my cubox v2 ? |
| 22:24 | dv_ | _rmk_: well the pengutronix solution relies on dmabuf, so no physical addresses. which is why their way could be mainlined, at least in theory. |
| 22:24 | dv_ | I didnt know v4l can be used for en/decoding though |
| 22:25 | dv_ | perhaps it cant, and that is what they mean by "extending v4l apis" |
| 22:25 | rabeeh | taz_: there is openbsd work on cubox-i |
| 22:26 | rabeeh | unclear where there will be something ready |
| 22:26 | taz_ | ok for cubox-i, but what about classic cubox ? :) |
| 22:26 | rabeeh | there isn't |
| 22:28 | taz_ | ok thanks |
| 22:43 | rabeeh | jnettlet_: i think we previously discussed the reset issue |
| 22:43 | rabeeh | i'v seen it today on your u-boot (no reset) but on my original u-boot it resets without issues |
| 22:44 | rabeeh | and there is no extra hardware that deals with reset function on the board level; everything is done in the imx6 chip |
| 22:44 | rabeeh | so i'm assuming it's software issue then. |
| 22:57 | _rmk_ | ok, I'm putting imx6 CEC stuff down as being hellishly unreliable and jittery |
| 22:57 | _rmk_ | I can get a response from my DVD/PVR on logical address 4 only if the imx6 decides to jitter towards a longer message |
| 22:59 | rabeeh | _rmk_: oh; so you see issues then |
| 22:59 | rabeeh | it's not that you want to play with it |
| 22:59 | rabeeh | maybe then the floating pin is what is causing it to refuse to properly work then |
| 23:00 | _rmk_ | you grounded the HDMI_DDC_CEC signal? |
| 23:00 | svere | rabeeh: i guess the alternative is cut the hdmi cable and connect the CEC wire to key row2 directly? |
| 23:00 | rabeeh | yes. |
| 23:01 | rabeeh | _rmk_ on the microsom hdmi_tx_ddccec pin is grounded |
| 23:01 | rabeeh | _rmk_: this might be an easy one though |
| 23:01 | rabeeh | do you want to solder it? |
| 23:01 | rabeeh | :) |
| 23:02 | _rmk_ | is that because pin 63 is ground? |
| 23:02 | dv_ | rabeeh: btw I have checked the imx6 docs, and 3D content in h264 is supported by the VPU |
| 23:02 | rabeeh | yes |
| 23:03 | rabeeh | _rmk_: let me triple check from the sources. |
| 23:03 | rabeeh | hold on |
| 23:03 | rabeeh | dv_: the spec says that; but the question is which resolutions / bitrates etc... |
| 23:06 | rabeeh | _rmk_: yes. confirmed from the layout |
| 23:06 | rabeeh | pin 63 is gnd; but now this is really tricky |
| 23:06 | _rmk_ | oh? |
| 23:07 | rabeeh | soldering that with flux is no issue (lots of flux) |
| 23:07 | rabeeh | just make sure you never touch the b2b itself |
| 23:07 | rabeeh | the plastic might deform and you would never be able to put the microsom back again |
| 23:07 | rabeeh | well... unless you want to try a dremel with it :) |
| 23:07 | _rmk_ | there's a safer solution - I've still got the via on the other side next to that diode |
| 23:08 | _rmk_ | that's still connected to pin 65, I can ground that. |
| 23:09 | rabeeh | is the via exposed? |
| 23:09 | rabeeh | if it's exposed then you can hook it to C5001 near it |
| 23:10 | _rmk_ | it's visible, and the resist can be removed |
| 23:10 | rabeeh | the pad of C5001 that is towards that via is GND |
| 23:11 | rabeeh | _rmk_: want a screenshot? |
| 23:13 | _rmk_ | I'm fine, thanks. :) |
| 23:14 | rabeeh | _rmk_: following screenshot in case you need it - |
| 23:14 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/ddccec-via-to-gnd.jpg |
| 23:15 | _rmk_ | yep. |
| 23:15 | rabeeh | notice that the snapshot is already mirrored (i.e. bottom view exactly like what you see) |
| 23:16 | _rmk_ | the D303 silkscreen is slightly over the via but that's no problem |
| 23:30 | _rmk | 23:30 * _rmk_ boots it back up... |
| 23:33 | _rmk_ | better but not reliable |
| 23:49 | _rmk_ | rabeeh: it's better but still not reliable - doesn't always elicit a response |