00:32 | Bluerise | *sigh* |
00:32 | Bluerise | I still have this weird problem that the SD card is recognized, but single (maybe also multi?) block reads don't work. |
00:33 | Bluerise | On two other i.MX6 devices, it works fine. |
00:33 | Bluerise | It could be a wrongly initialized IOMUXC, as I still don't do that and rely on u-boot having configured that. |
00:33 | Bluerise | Which is utterly wrong, of course. |
00:45 | _rmk_ | jmontleon: if you're still around, try re-getting that previous patch and giving that a spin |
01:52 | jmontleon | _rmk_, sure, will be a few before I can try, but I will do it before the night is out and get back to you |
01:54 | _rmk_ | ok, I'll pick up the results tomorrow morning then :) |
02:00 | jmontleon | sounds good. thanks again for working on it :) |
02:20 | NetScr1be | still looking for help building etnaviv |
02:20 | NetScr1be | libetnaviv |
02:21 | NetScr1be | I think muy problem is setting the environment up GCABI (and profile?) |
02:46 | NetScr1be | missing gcc-arm-linux-gnueabi and g++-arm-linux-gnueabi |
02:46 | NetScr1be | need a repository for those packages |
04:10 | jmontleon | _rmk_, that one kicks out mmc0: error -110 whilst initialising SD card errors very fast; would probably amount to 100's a minute |
05:11 | jnettlet | jmontleon, you need another patch to get the mmc driver to obey the device-tree properly |
08:06 | jnettlet | rabeeh, so you found a problem with the 3.3v to 1.8v switchover? |
08:07 | jnettlet | that would explain why I couldn't get a successful switch |
08:49 | MikeSeth | oh wow |
08:49 | MikeSeth | there's an usbtty driver in uboot |
08:49 | MikeSeth | anyone knows if it works? can I plug a serial dongle into my -i1 for uboot console? |
09:32 | jnettlet | _rmk_, I will rebase my patch to get uhs-1 cards working properly to 3.13 after I get back from walking the dogs |
09:52 | adamBB | hey guys, I just put ubutnu on my cubox-i, I am trying to ssh into it, whats the default password? I tried all the generic ones like cubox, root, toor, password, pass |
09:53 | davorin | did you try as "ubuntu:temppwd" for login? |
09:54 | adamBB | yeah, still no go :( |
09:54 | adamBB | I would have thought this would be documented somewhere? |
09:55 | davorin | ssh -l ubuntu host, right? (o; |
09:55 | adamBB | yeah, tried that |
09:55 | davorin | and with ubuntu:ubuntu? |
09:55 | davorin | where did you get that version? |
09:56 | adamBB | http://download.solid-run.com/pub/solidrun/cubox-i/Ubuntu/ubuntu-oneiric-freescale/ this one |
09:56 | adamBB | still nothing with ubuntu:ubuntu |
09:57 | davorin | linaro:linaro? |
09:57 | davorin | or just root:empty password? |
09:58 | adamBB | sadly neither, I did try the empty pass along side other generic passwords |
09:59 | adamBB | has no one else had this issue? i mean I couldnt find a single post on the forums with someone posting about this or the correct auth |
09:59 | davorin | when you mount the sd card on your linux pc and see what inside /etc/passwd to check for valid user names? |
10:01 | adamBB | 1min ill go check it out |
10:09 | adamBB | i cant get to my linux machine, I am currently on windows, any others things I can do? |
10:11 | davorin | and the older version works? |
10:11 | adamBB | I havent tried, got my cubox-i4 today :D |
10:11 | adamBB | ill give it a go |
10:12 | davorin | let me fire up another virtual machine here (o; |
10:16 | davorin | uncompressing the image tells me: unexpected EOF |
10:16 | rabeeh | for ubuntu; it's linaro/linaro |
10:17 | rabeeh | davorin: i'm uploading a new image; the old one is under the old directory |
10:17 | rabeeh | the newer one supports u-boot SPL |
10:17 | davorin | ah, the upload isn't finshed then (o; |
10:17 | davorin | that explains |
10:17 | davori | 10:17 * davorin coffe... |
12:06 | rabeeh | davorin: ubuntu image with SPL uploaded |
12:06 | davorin | ah great, thanks |
12:06 | davorin | with x11 and all fancy stuff? |
12:06 | davorin | though i don't like x11 on embedded stuff (o; |
12:06 | davorin | just need gcc and stuff |
12:07 | davorin | ah right, what i wanted to ask... |
12:07 | davorin | is there a video player like omxplayer? |
12:07 | rabeeh | that's an ubuntu image prepared by freescale |
12:07 | rabeeh | it's way too heavy for the i1; but runs ok on the others |
12:07 | rabeeh | it's also armel and not armhf |
12:07 | rabeeh | they have totem |
12:08 | rabeeh | (gstreamer based) |
12:23 | jnettlet | davorin, why do you need a video player if you don't like x11? |
12:23 | jnettlet | but I think it is time to accept that ARM != embedded necessarily |
12:23 | davorin | prefer console based player for testing drm |
12:24 | jnettlet | gst-launch |
12:24 | davorin | *shiver |
12:24 | davori | 12:24 * davorin doesn't like anything starting with g (o; |
12:25 | jnettlet | well use whatever KDE thing you like. I just don't know of anyone working on anything with that here. |
12:26 | davorin | i thought freescale would provide a simple player in their bsp to test vpu... |
12:26 | davorin | any1 looked at kivy? |
12:27 | davorin | nothing to do with video though (o; |
12:27 | davorin | just runs sort of acceptable on rpi... |
12:30 | davorin | rabeeh: the image still uploading? |
12:32 | davorin | wget reports a length of 384822720, whereas downloading from safari tells me its length is: 578273496 |
12:33 | davorin | any1 else having this? |
12:33 | davorin | go with a browser to: http://download.solid-run.com/pub/solidrun/cubox-i/Ubuntu/ubuntu-oneiric-freescale/ |
12:33 | davorin | and do a few reloads, the size changes every time |
12:33 | davorin | also the time stamp |
12:34 | _rmk_ | morning jnettlet |
12:34 | jnettlet | _rmk_, or afternoon |
12:35 | jnettlet | so you started playing with uhs last night? |
12:40 | jnettlet | did your fixed voice line cause FTTC performance to drop? |
12:44 | _rmk_ | it's still morning here :) |
12:44 | _rmk_ | only just though |
12:44 | _rmk_ | only because jmontleon has such a card and was testing for me |
12:45 | _rmk_ | and yes, the voice line is now fixed... and fttc hasn't lost any speed, which makes me even more suspicious |
12:46 | _rmk_ | maybe they didn't take the adsl service off the fttc line before connecting the line to the cabinet (the voice part of the line still gets carried back to the exchange on a copper pair from the cabinet) |
12:50 | _rmk_ | and I've noticed that some apps don't work very well over fttc because of the slower upstream, so I'm going to have to tweak my routing to chuck that stuff up the adsl line instead |
12:51 | jnettlet | _rmk_, well there are a couple of bugs in the uhs handshake and setup. |
12:52 | _rmk_ | would be good to get those upstream |
12:53 | jnettlet | well I have only fixed 2 of the 3 known. One is a general problem with using DAT3 for card detection. |
12:53 | jnettlet | secondly is once you enable the gpio turning off the D3CD interrupts off. |
12:54 | _rmk_ | yea, that last patch, I switched it to using gpio stuff for card detection |
12:54 | jnettlet | lastly the recovery of a uhs card that failed the 1.8v transition. That I have not finished yet because my i4pro was having some issues. |
12:57 | jnettlet | I realized there is one other patch you need. Which is if you don't have a gpio-cd property then don't even try to setup uhs |
13:01 | rabeeh | davorin: i'v uploaded to one server; the second is probably doing rsync :) |
13:02 | davorin | that's why i see two sizes with the same url |
13:02 | rabee | 13:02 * rabeeh hates uploading images |
13:05 | jnettlet | rabeeh, hint from a long time sysadmin. Upload them to a private directory and then do a mv command to make them accessible to the users. |
13:05 | jnettlet | fixes the partial image download problem |
13:06 | rabeeh | jnettlet: you did IT too? :) |
13:06 | rabee | 13:06 * rabeeh wonders what else you have done |
13:07 | jnettlet | cabinet making, metal fabrication, automotive restoration :-) |
13:08 | davori | 13:08 * davorin needs to fire up his cnc and lathe again some time (o; |
13:09 | rabeeh | davorin: oh; Aluminum cage for the CuBox-i :) |
13:09 | davorin | why not (o; |
13:09 | rabeeh | brushed metal.... |
13:09 | rabeeh | you have all the finishing tools too? |
13:09 | davorin | though i still have two 3d printing heads lying around to be tested on my smaller cnc machine |
13:10 | davorin | well..lathe is manual only so far... |
13:10 | davorin | but big milling machine i have modified myself to be cnc |
13:10 | davorin | with a 4-axis round table |
13:10 | davorin | s/4/4th/ |
13:11 | davorin | actually my plan is to test my round tft display with the som... |
13:11 | rabeeh | round tft? |
13:11 | davorin | sort of a small, round desktop device...to be used as clock, informational fisplay, radio,.... |
13:11 | davorin | yepp..have plenty of samples... |
13:11 | jnettlet | a round tft would be big. Everyone wants a round watchface. |
13:11 | davorin | 220x220 rgb tft |
13:11 | davorin | i know ;-) |
13:12 | davorin | i thought of bringing up a kickstarter project.. |
13:12 | davorin | to start production the costs are high..as minimum quantity is 5000 pieces |
13:12 | davorin | wait, i have somewhere an image |
13:12 | davorin | better..a video clip |
13:12 | davorin | https://shop.klingler.net/round_tft_clock.mp4 |
13:20 | MikeSeth | rabeeh: how loaded is your order queue? if I order a cubox, how soon'd it ship? |
13:23 | jnettlet | _rmk_, I think this patch is sufficient. http://fpaste.org/70624/13903933/ |
13:23 | jnettlet | I have one more patch that forcibly turns off D3CD but I am not sure if that is necessary. I found another bug in my test code that may have been the problem. |
13:24 | jnettlet | I will test in a bit, but my HB is running something right now |
13:25 | jnettle | 13:25 * jnettlet still needs to figure out why the card reset after failing vselect does not bring the card back to a working state |
13:26 | jnettlet | jmontleon, can you test ^ that patch when you get a chance? |
13:28 | _rmk_ | jnettlet: thanks, will look later today |
13:39 | davorin | rabeeh: all cubox-i are tested before shipping? |
13:39 | rabeeh | ofcourse |
13:39 | davorin | one customer complains nothing works (o; |
13:39 | davorin | though i suspect he plugged in the sd card the wrong way (o; |
13:40 | rabeeh | how can u plug the sd card the wrong way? |
13:40 | davorin | i'll upload your image to my server now so he can download faster and test again |
13:40 | davorin | dunno...with a hammer? |
13:40 | davorin | mine works fine with your image frmo today..and is form the same shipping |
13:40 | rabeeh | it won't fit |
13:41 | rabeeh | there are reports about flashing issues; but then it works |
13:41 | rabeeh | there are also reports about SPL u-boot failing to boot |
13:41 | davori | 13:41 * davorin doesn't like the wording flashing (o; |
13:41 | rabeeh | like this - http://imx.solid-run.com/forums/viewtopic.php?f=10&t=333&start=10#p2381 |
13:41 | davorin | flashing for me is bitbanging a parallel port and control the pins via jtag (o; |
13:41 | rabeeh | hehe |
13:42 | rabeeh | oh; i thought about different flashing :) |
13:42 | davorin | there are even some hidden jtag features on altera fpga... |
13:48 | davorin | uploaded here as well temporarly for people within europe area: http://shop.klingler.net/download/ubuntu-oneiric-freescale.img.xz |
13:50 | jnettlet | rabeeh, I think I know what is causing that on SPL. |
13:51 | rabeeh | what would that be? |
13:51 | rabeeh | the bss issue you have mentioned? |
13:52 | jnettlet | nope, occasionally I would see instances where the boot_device wasn't detected properly. |
13:52 | jnettlet | I fixed that by just changing the code so the default boot device was always MMC2 |
13:53 | rabeeh | hmm.. that's really awkward |
13:53 | rabeeh | the boot device should be the most reliable thing; maybe detecting the boot device already points to the issue? |
13:54 | rabeeh | (uninitialized memory) |
13:54 | rabeeh | MikeSeth: the queue is long... sorry |
13:55 | hste | rabeeh: a long queue is good :) means a lot of orders :) |
13:55 | rabeeh | hste: it's good and bad |
13:56 | rabeeh | but i think mainly bad; because it makes people wait a lot --> we are not Apple :) |
13:57 | jnettlet | rabeeh, but the boot device is read from the soc_sbmr, I guess if the global boot_dev is getting overwritten that would lead to this. |
13:57 | jnettle | 13:57 * jnettlet celebrates that they are not Apple |
14:04 | _rmk_ | rabeeh: when you've seen that people can plug a 37 way D plug the wrong way round into a 37 way D socket, you don't ask questions about how people can put things in the wrong way round... :) |
14:07 | jnettlet | the one I heard about recently is USB into RG45. I had never even thought to try, but with enough conviction it can be done without tools |
14:18 | _rmk_ | the sillyness which used to irk me was when I worked for a bit in a tv/video repair shop... |
14:19 | _rmk_ | you'd get people bring their video recorder in saying that it wouldn't load any VHS tapes anymore... or it had a tape stuck in the machine (normally with the tape still round the heads) |
14:19 | _rmk_ | and they'd used a screwdriver to try and force the tape out the machine... because they had to return it to the video rental shop to avoid the fine... |
14:19 | _rmk_ | but in doing so, they wreck the loading mechanism and the cassette |
14:21 | _rmk_ | if they hadn't had a go at getting the thing out, you could normally take the covers off, maybe click a solenoid, and then spin some gears to retract the pulleys/release the pinch roller, take up the slack tape, and then eject the cassette with no damage. |
14:22 | _rmk_ | and then it'd be something like a circuit protector/fuse had failed, or maybe a dead capstan motor |
14:23 | _rmk_ | the former taking less than five minutes to repair... the latter or the broken carriage taking the time to order replacement parts etc... and a customer having to explain to the video rental store why the cassette is useless |
14:23 | davori | 14:23 * davorin learned tv/radio repair man... |
14:23 | davorin | good old times with vacuum tunes (o; |
14:24 | _rmk_ | never did have any come in with a peanut butter sandwich... |
14:24 | jnettle | 14:24 * jnettlet learned vacuum tubes but that was for vintage guitar amps |
14:24 | _rmk_ | I was repairing TVs while I was still at school... so from the age of 14 or so. |
14:24 | jnettlet | you always want the Russian tubes if you can find them. They sound warmer |
14:27 | davori | 14:27 * davorin likes those old display tubes... |
14:27 | davorin | the russian had some funny ones for the tanks |
14:29 | davorin | maybe they needed the warmer sounding tubes in the cold (o; |
14:29 | _rmk | 14:29 * _rmk_ remembers vacuum tube TVs... we had a black&white one, which had to be turned on about 1 minute before the programme you wanted to watch so the tubes could warm up. :) |
14:29 | davorin | i had a tv to repair with one of the first remote controls... |
14:30 | davorin | just two different long aluminum tubes.. |
14:32 | _rmk | 14:32 * _rmk_ tsks... these youngers don't know they're born when they can just turn their led tv on and a picture appears immediately :) |
14:33 | _rmk_ | someone should build a vacuum tube ipad... |
14:33 | _rmk_ | ok, it might need a continent... |
14:44 | MikeSeth | not really, just make it cost $10000 |
14:45 | jmontleon | jnettlet, sure |
14:46 | jnettlet | jmontleon, thanks. if it doesn't work I have another patch I am not sure if I still need |
14:47 | jnettlet | if you have time I may also request you enable the monster we call CONFIG_MMC_DEBUG and let me peruse the first 500 or so lines |
14:48 | _rmk_ | jnettlet: I don't see why we can't use gpio for cd - it seems that rabeeh's repository is a little obscure |
14:48 | _rmk_ | jnettlet: rabeeh's git sets the pad to be routed to the esdhc interface, not the gpio, but then goes to tell the mmc driver that it should use the gpio |
14:49 | _rmk_ | that last patch I asked jmontleon to test switches to using the gpio for card detection only |
14:50 | jmontleon | jnettlet, sure thing |
14:51 | jnettlet | _rmk_, I think we have to use gpio for cd if we want to enable the 1.8v switching because according to the spec a successful switch is signalled by pulling down DAT3 which we then read as a card ejection |
14:51 | jnettlet | at least that is what I was seeing in the logs |
14:52 | jnettlet | and causes the MMC layer to get unhappy and produces the error, card removed during read |
14:55 | jnettlet | but I will admit I have not verified that the gpio-cd is working properly. That is on my testing todo list. |
14:55 | jmontleon | ok, patch applied, debugging enabled in config, rebuilding |
14:56 | _rmk_ | jnettlet: it seems to work here |
14:56 | jnettlet | jmontleon, you probably don't want the debugging enabled yet. It makes the machine basically unusable :-) |
14:56 | jmontleon | ah, ok, good to know :) |
14:56 | jnettlet | _rmk_, oh great! |
14:56 | _rmk_ | I see the gpio line go high/low on card removal/insertion... and it appears to trigger the mmc layer as expected |
14:56 | jnettlet | was there a question if it wouldn't work? |
14:57 | jnettlet | question if it would work I should say |
14:57 | _rmk_ | well, it means that the gpio is having to be polled by a timer several times a second |
14:58 | _rmk_ | actually... it is using an interrupt for that, so ignore that comment |
14:58 | jnettlet | which is what we want |
14:59 | jnettlet | gpio triggered by IRQ...good for MMC |
15:06 | davorin | speaking of gpio..faster than on rpi? |
15:06 | davorin | haven't looked exactly on the specs yet and if direct parallel i/o is supported... |
15:06 | davorin | with rpi i get slow framerate on my round tft (o; |
15:07 | _rmk_ | the hardware supports setting multiple GPIOs at the same time (provided they're within the same bank) |
15:08 | _rmk_ | that's not to say that the kernel does though |
15:08 | davorin | current models i have support 8/16 bit only..parallel rgb is possible..but need to order 5000 pcs (o; |
15:09 | davorin | hmm..lvds on c1 is published i think...got to test some lvds lying around here... |
15:09 | davorin | and since dsi is dropped i can throw those away (o; |
15:17 | davorin | hmmm...long time heard frmo my customer with his i4p not working...good thing or bad thing? (o; |
15:18 | eyal | Hi guys |
15:34 | jnettlet | wow, most the MX6 users are all stuck on a 3.0.35 kernel. They will be very happy with upstream support |
15:35 | _rmk_ | "very happy" ? |
15:36 | xraxor | rabeeh: not major for me, but when will xbmc support 24p movie format for playback? i read that it has to come from them |
15:37 | _rmk_ | I see that a version of imx-hdmi is now in mainline |
15:37 | jnettlet | the one in drivers/mfd/ ? |
15:38 | _rmk_ | no, Fabio's imx-drm one |
15:38 | _rmk_ | which is almost-but-not-quite-the-same as the version I have |
15:38 | jnettlet | oh the KMS version |
15:38 | jnettlet | but does it work, that is the question |
15:40 | _rmk_ | jnettlet: well, we'll see when I get around to updating my imx-drm branch |
15:41 | jnettlet | _rmk_, so my connection crapped out for a bit. Did you say that your SD card is working properly with the device-tree changes you posted last night? |
15:41 | _rmk_ | yes, mine seems to, but I don't think my card is a UHS card |
15:42 | jnettlet | no, but I was having problems with non-uhs cards recovering if you didn't explicitely have no-1-8-v specified in the device-tree |
15:42 | jnettlet | although that could be a problem with Freescale's custom rate detection code. |
16:05 | davorin | hmm..no sound in totem on ubuntu image frmo today.. |
16:06 | jnettlet | over hdmi? |
16:06 | jnettlet | or spdif? |
16:07 | davorin | yepp..on desktop its fine... |
16:13 | _rmk_ | remember that hdmi and spdif are separate audio devices |
16:15 | davorin | hmm..usb console is not on by default on this image, right? |
16:16 | jmontleon | i have never been able to get sound over hdmi, but i suspect that's at least in part because im relying on fbdev for video |
16:16 | davorin | customer write me he gets nothing on his i4pro with todays image... |
16:40 | jnettlet | jmontleon, for the mainline kernel that is correct. You need _rmk_'s hdmi audio patches for KMS |
16:40 | jnettlet | for the 3.10 kernel you need either KMS or the hdmi mfd device, and fsl-hdmi audio drivers |
16:41 | jnettlet | if we can get uhs support straightened out then my 3.10 kernel should be fully functional at this point. |
16:43 | _rmk_ | jnettlet: I still need to work out why audio is bubbly on the cubox-i4 but not the hummingboard... I suspect it has something to do with pulseaudio |
16:44 | jnettlet | _rmk_, consistently bubbly or sporadicly? |
16:46 | _rmk_ | consistently |
16:48 | _rmk_ | as I expected... avoiding pulseaudio, it works |
16:49 | jnettlet | oh but you probably have an old version of pulseaudio |
16:50 | jnettlet | who knows the bugs that lurk |
16:50 | _rmk_ | in theory, because this is LTS, bugs should get fixed... but then I know debian likes to have the policy that "stable" means "bug compatible" |
16:52 | _rmk_ | what I don't know is whether that broken thinking applies to ubuntu too |
16:53 | jnettlet | or the end of a buffer is consistently not getting filled and the popping is random stuff in memory trying to be turned into sound |
16:55 | _rmk_ | hmm, well, it appears to work from rhythmbox too, so... |
16:56 | jnettlet | perhaps gstreamer is auto-selecting a supported format, vs PA direct is not. |
16:56 | _rmk_ | oh, this will be via pulseaudio |
16:57 | dv_ | gstreamer always tries to autoselect something |
16:57 | dv_ | unless you really want it not to |
16:57 | jnettlet | ha, gstreamer is mentioned and dv_'s ears perk up |
16:58 | dv_ | :) i actually just wanted to see if something new about uboot / barebox came up |
16:58 | dv_ | then I see this |
16:58 | _rmk_ | interesting, clicking around on the desktop interrupts audio |
16:58 | dv_ | oh, short ringbuffer + not high enough process priority? |
17:00 | dv_ | or perhaps the buffers sent to alsa are not large enough. some applications try to send tiny sample packets to alsa to reduce latency, but cause higher CPU% and such glitches |
17:01 | jnettlet | _rmk_, fsl has some code that used to be chip 1.2 specific. They set HDMI as the SDMA event2. |
17:02 | jnettlet | They have changed that setting for all versions of the SOC now. That tends to suggest there is a difference between v1.2 which is in the i4Pro, and I believe the HB is v1.1 |
17:02 | _rmk_ | hmm, same think happens when not using pulse and twiddling stuff on the desktop |
17:02 | dv_ | jnettlet: btw do you think I can try out barebox mainline with the HB and the cubox-i ? |
17:03 | jnettlet | dv_, as long as you don't need hdmi then sure. It supports ethernet, uart, and usb |
17:03 | dv_ | yeah thats okay. I only need hdmi later in userspace |
17:04 | jnettlet | should be good to go |
17:04 | dv_ | because, then I will switch to it in my meta-fsl patches so I can send them to the mailing list |
17:04 | dv_ | what about SPL-like functionality? |
17:04 | jnettlet | I am working on that. |
17:04 | dv_ | okay, so in mainstream, I do have to specify i1,i2,i2ultra,i4pro,hb etc. |
17:04 | jnettlet | still familiarizing myself with all their knobs |
17:05 | dv_ | err mainline |
17:05 | dv_ | and your impression so far is still positive? |
17:05 | jnettlet | I think they only support HB1 right now, even though their patch suggests all CBi models are supported |
17:06 | jnettlet | yeah, I am real happy with what I have gone through so far. The drivers look better, the code organization and hardware init sequences look very sane and simple |
17:14 | dv_ | cool |
17:14 | dv_ | well if you think it is the better choice I am all for it |
17:14 | dv_ | oh, and rabeeh, is there a boot logo for the cubox-i and hummingboard that I can integrate into my meta-fsl patches? |
17:26 | _5051 | dv_, this one? https://github.com/rabeeh/u-boot-imx6/blob/imx6/tools/logos/solidrun.bmp |
17:28 | jnettlet | dv_, is this for the framebuffer while linux is loading? |
17:28 | jnettlet | that solidrun.bmp is very limited so u-boot can handle it |
17:31 | jmontleon | kernel build is finishing up, should be able to test mmc in a moment |
17:31 | jmontleon | really need to figure out what's wrong with cross-compiler config; last time i built a kernel using distcc it booted but it was not working right |
17:32 | jnettlet | oh you are building on the CBi? Make sure and specify at least -j4 |
17:39 | jmontleon | jnettlet, http://paste.fedoraproject.org/70710/40875813/ |
17:39 | jmontleon | it's not dozens or hundreds like last night before you patch :) that's all it spat out before giving up |
17:40 | jnettlet | jmontleon, can you post the the rest of the top of the log? |
17:41 | jmontleon | http://paste.fedoraproject.org/70712/13904088/ |
17:42 | jnettlet | oh. that is why. do you have the "quiet" option on your kernel commandline? |
17:44 | jnettlet | and I think I will need to get the output of a kernel compiled with CONFIG_MMC_DEBUG=y |
17:44 | jmontleon | http://paste.fedoraproject.org/70715/13904090/ |
17:45 | jmontleon | ya, I realized that about 3 seconds after I pasted you probably wanted without quiet ;) |
17:45 | jmontleon | sure, I'll build with debug |
17:51 | jnettlet | jmontleon, oh I know the bug you are hitting. It is the one I haven't fixed yet :-) If you can give me the debug output I would appreciate it, and then I will tell you how to fix it for now. It won't get UHS working, but will give you a properly working 50mhz high-speed clock. |
17:52 | dv_ | jnettlet: yeah, the logo that shows up while the kernel and the rootfs boot |
17:52 | jnettlet | dv_, it would be nice if we could use the same animation for android and linux |
18:01 | jmontleon | jnettlet, cool. I will get that for you |
18:03 | dv_ | jnettlet, is the mxc_hdmi-dont-require-cea-mode.patch still necessary for resolutions larger than 1024x768? |
18:03 | dv_ | (if I use a DVI monitor and an HDMI-to-DVI cable) |
18:04 | jnettlet | dv_, good question. let me take a look |
18:04 | jnettlet | which kernel? |
18:04 | dv_ | 3.0.35 |
18:04 | jnettlet | most likely. I haven't pushed any changes |
18:04 | dv_ | git://github.com/SolidRun/linux-imx6.git branch imx_3.0.35_4.1.0 |
18:04 | dv_ | okay |
18:09 | dv_ | I vaguely remember seeing similar hdmi related patches somewhere else. |
18:09 | dv_ | I currently include this patch in my meta-fsl stuff, but am aware that it is not really a clean solution.. |
18:13 | jnettle | 18:13 * jnettlet doesn't consider 3.0.35 a clean solution :-P |
18:13 | dv_ | hehe |
18:16 | _rmk_ | jnettlet: we may have sdma on the hummingboard too |
18:16 | _rmk_ | for hdmi audio |
18:16 | jnettlet | _rmk_, I believe we do. |
18:17 | jnettlet | is you HB's SOC rev 1.2? |
18:17 | _rmk_ | CPU identified as i.MX6DL, silicon rev 1.1 |
18:18 | rabeeh | _rmk_ ??? |
18:18 | _rmk_ | but... the fsl code says: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mfd/mxc-hdmi-core.c?h=imx_3.0.35_4.0.0#n519 |
18:18 | jnettlet | yeah you have rev 1.1 also |
18:18 | _rmk_ | which implies rev 1.1 has it |
18:19 | _rmk_ | so... I guess I should add this to my mainline hdmi audio driver |
18:19 | jnettlet | that function is reverse. it should be < 1.2 |
18:19 | jnettlet | hold on |
18:19 | _rmk_ | it returns true if sdma is usable |
18:19 | jnettlet | they have removed that now, and are just setting hdmi as sdma 2 for all versions of the chipset |
18:20 | _rmk_ | bah, how did I end up on fsl 4.0.0 again |
18:20 | jnettlet | so you need to write |= 0x1 to regmap |
18:21 | jnettlet | I have no idea if it will fix your problem, but I assume they have done this for a reason |
18:21 | _rmk_ | yea, 4.1.0 is similar - > rev 1.1 for 6Q or > rev 1.0 for 6DL |
18:21 | _rmk | 18:21 * _rmk_ takes rabeeh's ??? and turns it into a ??? :) |
18:22 | rabeeh | _rmk_: try ||| :) |
18:22 | jnettlet | _rmk_, ENGR00276321 HDMI Audio: Set HDMI event as SDMA event2 |
18:22 | jnettlet | |
18:22 | jnettlet | - Remove chip revision check code. |
18:22 | jnettlet | - Set HDMI event as SDMA event2 for HDMI audio. |
18:24 | _rmk_ | where did that come from? |
18:24 | jnettlet | 3.10.17 beta |
18:24 | _rmk_ | they're saying sdma is supported on all imx6 then? |
18:25 | jnettlet | that is the latest patch, so yes |
18:25 | jnettlet | and I have tested on both HB1 and CBi4p |
18:25 | _rmk_ | okay, so I don't have to make it conditional on anything :) |
18:25 | jnettlet | just do it! |
18:25 | dv_ | is sdma this other thing that requires firmware? |
18:26 | _rmk_ | yes... I wonder if firmware 1.1 is required for this rather than the built-in firmware |
18:26 | _rmk_ | I can test that by building sdma into the kernel |
18:26 | jnettlet | I think they are on version 2 |
18:28 | jnettlet | oh interesting you can use imx-sdma to allocate mem from sram so you can shut down DDR |
18:30 | rabeeh | dv_: still looking for a high res logo? |
18:30 | rabeeh | http://cubox-i.com/wp-content/uploads/2014/01/SolidRun_Logo-1170x390.png |
18:37 | jmontleon | jnettlet, does this have what you need? To my untrained eye it doesn't look a whole lot different. http://paste.fedoraproject.org/70739/41216013/ |
18:39 | jnettlet | jmontleon, add "debug" to your kernel commandline |
18:41 | davorin | feckin ubuntu...can't even shutdown from menu..just ignores (o; |
18:41 | davorin | and my external esata case just fried my harddrive... |
18:41 | davorin | time to go for 2day (o; |
18:42 | jmontleon | jnettlet, http://paste.fedoraproject.org/70744/12564139/ |
18:42 | jmontleon | looks more interesting that way |
18:43 | jnettlet | jmontleon, yep that is the good stuff |
18:44 | rabeeh | davorin: no fan in the case? |
18:47 | jnettlet | jmontleon, okay so adding no-1-8-v; to the usdhc entry in device-tree should allow your CBi to fallback to SD speeds and work for now. |
18:48 | jmontleon | ok, cool |
18:52 | jnettlet | oh I see what is not happening. The CMD11 to switch to 1.8V is happening, but the driver isn't trying to switch the pins |
18:52 | jnettlet | jmontleon, let me see what is missing in the upstream kernel. 1 sec |
18:54 | jmontleon | sure - that worked, but the way, it booted |
18:54 | jnettlet | great. |
18:55 | jmontleon | let me double check with the kernel built with your other patch /me should have probably done that |
18:56 | mhoney_work | is it possible to run debian on the i4 pro yet? |
18:56 | jmontleon | wow... you weren't kidding about being basically unusable |
18:57 | jnettle | 18:57 * jnettlet didn't know it wasn't possible. |
18:57 | jnettlet | :-) |
18:57 | jnettlet | remove the debug from your kernel commandline |
18:57 | jmontleon | yep - it's booting, im finally seeing systemd output |
19:00 | jmontleon | ok, removing debug made it go a lot faster, booted |
19:09 | jnettlet | jmontleon, if you want to test uhs support again. I think you need this patch http://fpaste.org/70750/14137139/ |
19:16 | _rmk_ | jnettlet: it looks like the sdma support may need improving to do this hdmi audio stuff |
19:16 | jnettlet | _rmk_, let me check the patch difference between mainline and 3.10, see anything that jumps out at me |
19:17 | _rmk_ | 3.13 has nothing in it to take the context data block into the sdma code necessary for doing this |
19:18 | jnettlet | _rmk_, yep it is missing the hdmi audio support patch |
19:21 | _rmk_ | lol. government wants to bring "computing" into schools... and "coding". which sounds like they're going to be teaching everyone python. |
19:21 | jmontleon | jnettlet, sure |
19:21 | jnettlet | hey! nothing wrong with teaching python to the youngsters |
19:21 | jmontleon | jnettlet, do I leave no-1-8-v or leave it? |
19:22 | jnettlet | jmontleon, remove it. be prepared it may not boot. |
19:22 | jmontleon | heh. story of my life lately :) |
19:22 | jmontleon | all in the name of saving some other poor souls from suffering |
19:23 | _rmk_ | jnettlet: sure, if it gets them interested in computing - but it should be balanced with at least an introduction into some of the other languages |
19:24 | jnettlet | yeah, like javascript and html :-) |
19:24 | jmontleon | lol |
19:24 | _rmk_ | jnettlet: don't you mean xml? :) |
19:25 | jnettle | 19:25 * jnettlet doesn't care about the language. Just as long as they use OSS. |
19:25 | jnettlet | Schools using anything but OSS is ridiculous! Automatically adding a learning golden gate where you need to pay more money to learn more and dig deeper is ridiculous |
19:26 | jnettlet | give a CBi, or an XO laptop and let them dig down as deep as their brain can handle. |
19:26 | _rmk_ | yep |
19:26 | jnettle | 19:26 * jnettlet steps down from soapbox |
19:29 | rabeeh | jnettlet: any idea how to tell SPL to boot the kernel directly? |
19:29 | jnettlet | rabeeh, you need to enable Falcon mode I believe. |
19:35 | rabeeh | damn it... i can't get SPL to fail |
19:36 | rabeeh | jnettlet: you and others had issues with SPL; but for me it boots 100% of the times |
19:36 | jnettlet | rabeeh, well my setup was hardly a fair test. I was just saying I have seen problems. |
19:37 | jmontleon | jnettlet, didn't boot; let me get you the debug again. without debug enabled it looks about the same though |
19:37 | jnettlet | but I have seen the memory corruption |
19:37 | jnettlet | jmontleon, yeah debug output would be great thanks. |
19:39 | jmontleon | http://fpaste.org/70757/39041598/ |
19:41 | jnettlet | jmontleon, yeah still not trying to change the pinctrl properly. I would stick with no-1-8-v; for now and I will debug this when I get my new hardware. |
19:42 | jmontleon | cool, works for me |
19:42 | jmontleon | thanks for looking :) |
19:43 | jnettlet | _rmk_, if you are bored these two patches may/may not be enough to get sdma working for hdmi audio. https://www.dropbox.com/sh/ck0xsrdjvin16v8/Uol6rr0Azk/rmk |
19:49 | mhoney_work | is the serial settings for cubox i4pro 8-n-1 at 115200 ? |
19:50 | jnettlet | yep |
19:50 | mhoney_work | bummer. When I use that on putty I get nothing ;( |
19:53 | jnettlet | mhoney_work, do you have an SDHC card inserted? |
19:56 | mhoney_work | Yes, I have the Jan 2nd hessie image inserted |
19:56 | mhoney_work | *Jessie |
19:56 | jnettlet | and it boots? |
19:56 | jnettlet | just saying that if the CBi can't find u-boot you wont' get any output on the serial console |
19:56 | mhoney_work | I have two other cuboxes so unless this version is supposed to act different... |
19:57 | jnettlet | are they the same model? |
19:57 | jnettlet | The old images u-boot was different for each model. New images should boot on any model. |
19:58 | mhoney_work | I see, I'll create another image and cross my fingers |
20:04 | mhoney_work | another odd thing i just noticed is the red light doesnt come on for the ir port |
20:05 | mhoney_work | but I see light from the spdif port |
20:06 | jnettlet | yep that means that u-boot isn't loading. |
20:06 | jnettlet | sounds like you have the wrong version. try a new image and report back |
20:06 | mhoney_work | im downloading the new ubuntu image... will give that a go |
20:47 | mhoney_work | got it going with ubuntu.. impressive little box |
20:52 | mhoney_work | are the video drivers in oncelot accelerated? |
21:05 | dv_ | jnettlet: I am adding a brief description for the dvi cea mode patch |
21:05 | jnettle | 21:05 * jnettlet hopes it contains lots of expletives about freescale fixing their "stable" code |
21:06 | dv_ | :) |
21:06 | dv_ | "With dvi monitors, the list of CEA modes is always zero, preventing modes higher than 1024x768 to be used. This patch disables the CEA mode check." |
21:07 | dv_ | is that ok? |
21:08 | jnettlet | I think that is fine. Let me look at that code again quick. |
21:09 | dv_ | https://github.com/dv1/meta-fsl-arm-extra/blob/master/recipes-kernel/linux/linux-imx-3.0.35/cubox-i/mxc_hdmi-dont-require-cea-mode.patch |
21:09 | dv_ | (I will rebase this repository soon, so dont assume the link to be valid much longer) |
21:25 | jnettlet | dv_, yeah it is going to be too much to patch that now. I will fix it in my 3.10 kernel |
21:25 | dv_ | no problem. I will use the aforementioned text for the patch description then. |
21:33 | kalasmannen | anyone running xbmc on arch on cubox-i? |
21:37 | jnettlet | I think most the arch users are on the forums. I actually don't think I have talked to anyone on irc that was using ARCH |
21:37 | kalasmannen | ah, i see |
21:38 | kalasmannen | just got mine to boot, but wanted to exchange experiences regarding different things that work/don't work |
21:38 | kalasmannen | i'll see what i can find on the forums then, thank you! |
23:30 | rabeeh | _rmk_: can you please 'i2cdump -f 2 0x68' ? |
23:31 | rabeeh | (or anyone else running with LK >= 3.10) |
23:38 | MikeSeth | mmh |
23:39 | MikeSeth | the wifi on my i1 doesn't see my AP, and about 20 other APs |
23:39 | MikeSeth | it does show some, but i can't tell what's common |
23:39 | MikeSeth | anything special about that broadcom chip? |
23:42 | rabeeh | MikeSeth: what does 'iwconfig' shows? |
23:42 | rabeeh | which OS are you running now? |
23:42 | MikeSeth | debian testing with 3.0.35 |
23:43 | MikeSeth | iwconfig shows the iface normally |
23:43 | MikeSeth | iwconfig shows the iface normally |
23:43 | MikeSeth | now i switched the AP to b mode only andset fixed channel to 11, and it shows |
23:44 | MikeSeth | maybe crda excludes channels > 11 IDK |
23:46 | MikeSeth | yep, channels 12 and 13 aren't visible, this is probably a crda problem |
23:53 | MikeSeth | there also appears to be a driver problem, it craps out if I reset the AP and the scans no longer work |