08:11 | ralix | moring @ all |
08:11 | ralix | +s |
08:16 | jnettlet | morning ralix |
08:18 | ralix | Do you know if there is progress, the archlinux running on the new CUBOX-i |
08:18 | jnettlet | My Cubox-i scheduled for delivery today. |
08:18 | jnettlet | ralix, not yet developer units just getting to the community this week. |
08:18 | ralix | oh coool! |
08:20 | ralix | I have to save some money, I definitely want a CUBOX-i ;-) |
08:20 | jnettle | 08:20 * jnettlet will have to clear a space on my hardware dev shelf for it. |
08:21 | Juggie | ouya set the bar pretty low so can only get better from here :) |
08:22 | jnettlet | I didn't get an ouya. What was wrong with it? |
08:23 | Juggie | the xbmc expirience is suboptimal from what i understand |
08:23 | Juggie | and its also locked down, android market not supported |
08:24 | jnettlet | well XBMC on Android is just hitting it's stride. Real bummer about the android market. |
08:25 | Juggie | getting close yeah |
08:25 | Juggie | still without a proper video framework |
08:25 | Juggie | its not quite there |
08:26 | jnettlet | until they make it a proper replacement launcher I just don't see the point. |
08:27 | Juggie | they are working on that |
08:27 | Juggie | but not quite there |
08:27 | Juggie | openelec for me on cubox would be the ideal solution |
08:28 | Juggie | one embedded image |
08:28 | Juggie | nothing else |
08:28 | jnettle | 08:28 * jnettlet google openelec |
08:28 | Juggie | openelec is a minimal linux + xbmc distribution |
08:28 | Juggie | sort of like xbmcubuntu or raspbmc |
08:28 | Juggie | except without all the suck |
08:29 | jnettlet | that should run on the old Cubox and the Cubox-i without a problem. |
08:29 | Juggie | hope so ;) |
08:29 | Juggie | once its proven to work well and not choke on skins/fanart etc |
08:29 | Juggie | lots of people will buy |
08:29 | Juggie | i would use 2-3 |
08:30 | Juggie | rpi is ok but slow |
08:31 | jnettlet | I plan on updating all my TV stuff to Cubox-i's. My mk808 died. I would rather get hardware from a company with a good community around it. |
08:31 | jnettlet | My Boxee Box is a brick. Don't even get me started on that company. |
08:33 | Juggie | i'm hoping theres a nice heatsink inside the cubox |
08:33 | Juggie | all the imx6 sticks die from heat |
08:33 | Juggie | hence why the manafacturers clock them down to 720p only |
08:36 | jnettlet | Juggie, have you seen rabeeh's video? The temp's are not too bad. |
08:38 | rabeeh | Juggie: the CuBox-i has an internal heat spreader |
08:38 | jnettlet | rabeeh, you took your video down. |
08:38 | rabeeh | yes. Waseem did |
08:38 | rabeeh | he doesn't like it anymore and wants more professional one |
08:39 | rabeeh | i'll ask him to get it back online back again until we have a more professional one |
08:40 | purch | yeah, cant wait to get xbmc on cubox-i |
08:41 | purch | with similar hw it runs pretty smooth and heatsink is reaylly hot ( http://stephan-rafin.net/blog/2013/07/18/xbmc-on-wandboard/ ) |
08:42 | rabeeh | purch: sometimes hot and feels hot are two different things |
08:42 | purch | I will sink that wandboard when I get those cubox-i's, community matters :thumb |
08:43 | rabeeh | for instance if you get a plastic and heat it to 45c; and then get aluminum (typical heat sink material) and heat it to 45c then the plastic will feel a bit warm and the heatsink will feel hot |
08:44 | rabeeh | this is mainly because of the heat transfer coefficients of different materials |
08:45 | rabeeh | cbxbiker61 and all: withregards cubox-i installer; i wonder what the approach should be this time. |
08:46 | rabeeh | previously we let CuBox install itself while booting from a USB thumb drive and then it downloads everything and intalls on the microSD |
08:46 | rabeeh | now we have more options; we can either put that installer on the microSD; boot it and let it installs |
08:46 | rabeeh | we can download an image on a PC, flash it to a microSD and then just put it on the CuBox-i |
08:47 | rabeeh | and there is a third option; but dangerous one to use a host to host USB cable and program the i.MX6 board from a PC |
08:47 | rabeeh | anyone wants to vote? |
08:48 | wumpus | why is the last one dangerous? |
08:48 | rabeeh | i know most of you guys don't care; since you command line the damn microSD until it's flashed; but most of the users out there wants to get the resultent OS images as fast and easy as possible |
08:49 | rabeeh | it's dangerous since we need to use a USB host to host that the 5V on the USB cable is supplied from the PC; to make the connection to the i.MX6 |
08:49 | Juggie | i did not see the video no |
08:49 | wumpus | I'd personally prefer a user friendly program to flash the microSD in the PC and then put it in the cubox |
08:49 | rabeeh | but once the i.MX6 is up and running; it will enable the 5V on it's USB so there will be a contention |
08:49 | wumpus | (as it's so simple to replace the microSD in the device, it'd be different for devices which you have to open to replace the sd) |
08:49 | rabeeh | Juggie: the video is offline now; we will get it back online again |
08:49 | Juggie | whats the power port on the imx6? |
08:50 | Juggie | basic ac port? or usb? |
08:50 | rabeeh | DC jack |
08:50 | Juggie | feisable to use usb? |
08:50 | Juggie | or is 5v not enough |
08:50 | rabeeh | 5V is required; but the current is beyond that |
08:50 | wumpus | and it'd be very similar to creating ubuntu live images |
08:51 | rabeeh | the main reason is that we provide two powered USB hosts; that each mush have a 500mA; both 1A |
08:51 | wumpus | usb-creator or something like that, great little tool to make bootable usb sticks that can be used to run or install ubuntu |
08:51 | rabeeh | wumpus: why live? |
08:51 | Juggie | right, i was thinking not a usb host |
08:51 | purch | rabeeh: I liked this one, but requires _linux_ https://github.com/RobertCNelson/netinstall; this could also deliver full images too; GUI to this with windows support |
08:51 | rabeeh | wumpus: today people are putting raw ext images; which in my mind is really wasteful |
08:51 | Juggie | but a micro usb port, for power, debug, adb (when using android), and flashing |
08:51 | wumpus | rabeeh: I don't mean it should be live, but that tool is a good example of a user friendly program |
08:51 | wumpus | to do a similar thing |
08:51 | rabeeh | Juggie: for the single processor yes |
08:52 | Juggie | why could it not be for any? |
08:52 | wumpus | would be nice to have the same for cubox, just put in the sdcard, select the image, push a button |
08:52 | purch | One program to give full blown images and different distro netinstallers written to sd card <- my vote |
08:52 | rabeeh | wumpus: i'm having hard time downloading a 100MB filesystem and writing 4GB to the flash because it's a raw image |
08:53 | rabeeh | i was thinking about something smarter; something to log the written blocks to a virtual drive; and then recreate only those writes to the final flash |
08:53 | Juggie | something like fastboot would be fine |
08:53 | Juggie | minimal boot you could use to write images from sd |
08:54 | Juggie | rabeeh, why would micro usb not be enough to power dual/quad |
08:54 | Juggie | all the cheap chinese sticks use usb? |
08:54 | Juggie | the imx6 ones im ean |
08:54 | rabeeh | for now our measurements shows max current for the quad about 1.2A; add to that the 500+500 for the host USB and you get 2.2A |
08:54 | Juggie | *i mean |
08:54 | rabeeh | today the best USB chargers i have are 2A |
08:55 | Juggie | ah |
08:55 | rabeeh | and besides that the spec for typical micro USB connector is up to 1.9A (i think given 10c temperature rise). |
08:55 | rabeeh | so; for the question if it work or not; most probably it will work; but we as a company need to give the worst case scenario and provide a solution for it |
08:56 | rabeeh | that's btw we kept the DC - jack in the CuBox-i |
08:57 | jnettle | 08:57 * jnettlet is completely fine with a DC jack. |
08:57 | Juggie | doesnt matter to me i was just curious |
08:57 | Juggie | will there be a micro sd for debug/etc though? |
08:57 | Juggie | or just host |
08:59 | rabeeh | Juggie: you mean micro USB? |
08:59 | Juggie | yes sorry |
08:59 | Juggie | its late :) |
08:59 | Juggie | jtag etc |
08:59 | rabeeh | on the two higher end models there is a built-in micro USB to rs-232 |
09:00 | rabeeh | this provides access to the u-boot for command line |
09:01 | rabeeh | for jtag the pins are there that can be accessed; but no more convenient way is provided |
09:11 | Juggie | k |
09:11 | cbxbiker61 | rabeeh, i think a pc based installer would probably be the most convenient, maybe a streamlined installer in a small first partion that could resize or create a second part with the desired filesystem |
09:12 | cbxbiker61 | write a small raw image in any pc, which would kick off the installer when it first boots in the cubox-i |
09:20 | cbxbiker61 | raspbmc's installer is simple and effective, although it doesn't have to deal with multiple filesystem types |
09:27 | jnettlet | I am still vaguely interested in running CoreOS and creating Docker packages for different rootfs's and applications. |
09:28 | jnettlet | If now default service is available CoreOS could run the installation gui and have different Docker packages for XBMC, Android, Desktop Linux available for download |
09:29 | jnettlet | I started looking at it for my new take on the OLPC OS, but decided it would be phase 2 |
09:36 | purch | rabeeh: wandboard-quad went to CPU 54 degrees and heatsink 50 degrees (http://www.laser-liner.co.uk/product/thermospot-laser-2/); runtime 10 minutes; video 1080p/runtime 50 min/4,5GB and system settings page on with fps ~18 -- not a heat transfer problem and yeah aluminun at 50 degrees feels hot |
09:43 | jnettlet | 54C is not bad at all. My nvidia GPU's normal temp is about 62C |
09:43 | jnettlet | that is internal temp though. you are talking about surface temps |
09:43 | purch | yes, it is "normal" |
09:44 | rabeeh | on the quad internal temp and external are almost alike |
09:44 | purch | 54 is what xbmc system settings provids for cpu |
09:44 | rabeeh | 2 to 3c difference |
09:44 | rabeeh | (flip chip) |
09:44 | purch | xbmc did not show gpu temp |
09:45 | rabeeh | purch: you need to get the readings from the SoC first |
09:45 | rabeeh | for the thermospot laser; i wouldn't trust it too much on reflective surfaces |
09:45 | rabeeh | black surfaces and non reflective it measures ok |
09:46 | rabeeh | but for aluminum; if there is light reflection then sometimes the readings are not accurate |
09:46 | rabeeh | oh; and running for 10m is not good enough; in my experience, especially in a closed box you need to run for at least 30m to get to the 95% of the final temperature |
09:47 | purch | rabeeh: 30 minutes, thats slow |
09:48 | rabeeh | the chip and memories needs to heat all the boards, heat sinks and finally the enclosure until it reaches the max temp |
09:49 | purch | true |
10:00 | jnettlet | rabeeh, just got an SMS that my Cubox-i is out for delivery. Looking forward to hooking it up. Does it come with an image or should I download something ahead of time? |
10:00 | rabeeh | those dhl guys are fast |
10:00 | rabeeh | no image; and i haven't put anything on the net |
10:00 | rabeeh | i'll start cleaning things up and putting on github |
10:01 | jnettlet | okay. I will start setting up a Yocto openembedded build for a quick start. |
10:02 | rabeeh | great |
10:09 | _rmk_ | rabeeh: did you mail out the tracking numbers? I've heard nothing. |
10:09 | rabeeh | _rmk_: i'll ask operations to send you tracking number |
10:10 | _rmk_ | thanks |
10:10 | jnettlet | _rmk_, I got my tracking number in an SMS |
10:12 | _rmk_ | I don't give my mobile number generally (because its normally off) |
10:12 | _rmk_ | otherwise people try to phone it and end up leaving messages, which cost me to retrieve (because the mobile signal is soo poor around here) |
10:12 | jnettlet | that would explain that |
10:16 | _rmk_ | and we didn't get any mail yesterday (not even any sign of the postman delivering) - I suspect the local sorting office is still short staffed which means this could take longer especially if they try posting the payment details |
10:17 | rabeeh | _rmk_: no it's our problem |
10:18 | _rmk_ | hmm? |
10:18 | rabeeh | we should have sent those emails already yesterday; but clearly not everybody got it |
10:18 | rabeeh | i mean the tracking number |
10:18 | _rmk_ | ah |
10:25 | _rmk_ | ah ha, it should arrive today |
10:27 | jnettlet | rabeeh, did you get my note yesterday about marking any future dev board shipments as Engineering Samples? |
10:28 | rabeeh | yes. |
10:29 | rabeeh | i think operations put value of 1cent on this |
10:31 | rabeeh | just looked on the papers; they also added it as engineering samples |
10:31 | rabeeh | they already know the drill |
10:33 | jnettlet | great. |
10:54 | jnettlet | dv_, are you using the KMS or fbdev driver on your iMX6 board? |
10:58 | dv_ | the one from meta-fsl-arm |
10:58 | dv_ | no idea what that uses |
11:00 | jnettlet | looks like it is using fbdev |
11:36 | _rmk_ | jnettlet: unfortunately, hal/os/linux/kernel/gc_hal_kernel_driver.c references hal/user/gc_hal_user_context.h |
11:37 | _rmk_ | that I think is the only user header file which is required, and that needs the file header sorted |
11:37 | jnettlet | _rmk_, if you include a header in a GPL released file doesn't that legally make the header file GPL? |
11:38 | jnettlet | I understand they would need to change it as copyright holders. |
11:39 | _rmk_ | possibly, but it won't stop the GPL police complaining about it, so its best to get it corrected |
11:40 | jnettlet | Oh this is in reference to the older driver your patches are based on? |
11:42 | _rmk_ | yep |
11:44 | jnettlet | one sec let me look at something. |
11:48 | rabeeh | jnettlet: i started writing a wiki page here - |
11:48 | rabeeh | http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware |
11:51 | jnettlet | _rmk_, so it looks like the only thing needed in that header is the gcsQUEUE structure. In the new driver that has been moved to hal/kernel/inc/gc_hal_kernel_buffer.h which is GPL licensed. |
11:52 | jnettlet | maybe backport that change and be done with this? |
11:52 | _rmk_ | sounds good :) |
11:53 | jnettlet | It has a slightly different pointer type for next, but I think we can safely incorporate that change if necessary. |
11:54 | jnettlet | rabeeh, great. |
12:17 | pacolm | hi there |
12:17 | pacolm | anyone has the uboot and kernel for the i-cubox? |
12:19 | rabeeh | pacolm: hi. no one yet |
12:20 | rabeeh | you need to hold on few hours. |
12:20 | rabeeh | i'm updating the wiki with first instructions |
12:20 | rabeeh | oh boy; DHL was really fast; i though i had the whole day to do cleanups |
12:20 | rabeeh | http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware |
12:22 | _rmk_ | what? you mean none dropped, none hidden and none lost yet? |
12:34 | rabeeh | ok. higher resolution is on the wiki |
12:34 | rabeeh | with some explanation |
12:36 | jnettlet | rabeeh, okay got my package. Your team did do everything correct and there was no problems with Moms etc. It was DHL texting me mis-information :-) |
12:36 | rabeeh | great |
12:37 | rabeeh | _rmk_: no drops for now |
12:41 | jnettlet | this board runs fine off a single usb port's power? |
12:46 | rabeeh | nop |
12:46 | rabeeh | you need ~600mA to 700mA for the board and additional 2x500mA for the two USB ports |
12:46 | _rmk_ | dropit's arrived |
12:51 | _rmk_ | cute |
12:54 | jnettlet | oh so a serial console is provided through the raspberry pi header. |
12:54 | jnettle | 12:54 * jnettlet has the perfect cable for that somewhere |
12:58 | _rmk_ | urgh, so what will I need to get at that? |
13:00 | jnettlet | _rmk_, you can use the usb serial board that came with your XO's and either cannibalize the adapter cable or do a mini molex to the header board. |
13:01 | rabeeh | _rmk_: refresh the wiki to access the uart interface |
13:01 | rabeeh | temportay images - |
13:02 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/c1_images/u-boot.bin |
13:02 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/c1_images/uImage |
13:02 | rabeeh | the first is u-boot image and the second is a buildroot with the kernel |
13:02 | rabeeh | i will follow up with sources in few hours (cleaning up) |
13:02 | rabeeh | to burn u-boot; on your PC do the following - |
13:03 | rabeeh | sudo dd if=u-boot.bin of=/dev/sdX bs=512 seek=2 skip=2 conv=fsync |
13:03 | rabeeh | the uImage can be put on a fat32 filesystem on the first partition |
13:03 | rabeeh | kernel command line is as follows - |
13:04 | rabeeh | setenv bootargs 'console=ttymxc0,115200 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32'; bootm 0x10800000 |
13:04 | rabeeh | you can load the kernel to 0x10800000 - |
13:04 | rabeeh | fatload mmc 0:1 0x10800000 /uImage |
13:04 | rabeeh | the uImage is being uploaded right now; give it 10-15m to upload (~30MB file) |
13:09 | rabeeh | ok. file uploaded |
13:28 | dv_ | rabeeh: did you get the dhl tracking numbers? |
13:28 | rabeeh | i can ask operations |
13:29 | rabeeh | let me check |
13:29 | rabeeh | lets see whom the first to get u-boot prompt :) |
13:32 | purch | okei okei, when is the next dev batch shipped? I want to play too! :) |
13:36 | dv_ | everybody wants to play with it |
13:37 | jnettlet | got uboot |
13:38 | jnettlet | it works hurray |
13:40 | dv_ | rabeeh: did otavio get the uboot patches? |
13:40 | jnettlet | dm |
13:43 | jnettlet | it doesn't like my mm3 |
13:43 | jnettlet | mmc3 make that. too much stuff around keyboard |
13:45 | pacolm | thanks rabeeh, I will follow the instructions |
13:46 | pacolm | first I need to get a cable for the serial console (I have the standard, need to do the connector interface for the iCubox) |
13:48 | dv_ | whats the interface? |
13:48 | dv_ | 4 pin? |
13:49 | jnettlet | depends on your converter. My olpc serial board only needs ground tx and rx |
13:54 | jnettlet | rabeeh, have you tested uhs1 sdhc cards yet? |
13:57 | rabeeh | nop |
13:57 | rabeeh | the regular SD cards |
13:57 | jnettlet | I am testing on normal now. |
13:58 | jnettlet | uboot sees the card and can read the info but it can't boot from it. |
13:58 | rabeeh | mmcinfo? |
13:58 | jnettlet | yep one sec |
13:58 | jnettlet | wife just got home |
13:58 | rabeeh | hehe |
13:59 | rabeeh | wife is more important than carrier one :) |
14:00 | rabeeh | should i clone this tree - https://github.com/Freescale/u-boot-imx ? |
14:00 | rabeeh | i'm using now 2009-08 |
14:04 | jnettlet | I am going to work off the tree that has KMS support included |
14:05 | jnettlet | rabeeh, not the card. my normal Class 4 card has the same problem. |
14:05 | jnettlet | let me get you the logs |
14:05 | rabeeh | what does 'mmcinfo' show? |
14:05 | rabeeh | is it detecting it correctly? |
14:06 | jnettlet | seems to be. |
14:06 | jnettlet | No boot partition available |
14:07 | jnettlet | http://fpaste.org/42086/01108331/ |
14:07 | rabeeh | do you have a partition on it? |
14:08 | rabeeh | if it's fat then you can run 'fatls mmc 0:1 /' |
14:08 | jnettlet | it sees uimage |
14:09 | rabeeh | ok. |
14:09 | rabeeh | fatload mmc 0:1 0x10800000 /uImage |
14:09 | rabeeh | ? |
14:09 | rabeeh | ddr at fsl starts at 0x10000000 |
14:10 | jnettlet | ah okay |
14:10 | rabeeh | setenv bootargs 'console=ttymxc0,115200 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32'; bootm 0x10800000 |
14:10 | jnettlet | and we are off |
14:11 | jnettlet | have hdmi output |
14:11 | jnettlet | username/password? |
14:13 | rabeeh | root |
14:13 | rabeeh | 123456 |
14:13 | rabeeh | :) |
14:18 | rabeeh | working? |
14:18 | jnettlet | we are good |
14:24 | ralix | Is there actually a newer kernel 3.5.7-12 under Archlinux? I wonder which is so old ;-) |
14:27 | jnettlet | there is work to get stuff into mainline. |
14:28 | ralix | ok |
15:02 | rabeeh | registered machine ID 4773 |
15:34 | dv_ | ralix: you were talking about the imx kernel? |
15:34 | ralix | no kernel for the old cubox |
15:35 | dv_ | ah |
15:35 | ralix | ;-) |
15:35 | dv_ | there is rabeeh's 3.6.9 kernel |
15:35 | ralix | i have no cubox-i yet :( |
15:36 | dv_ | ralix: https://github.com/rabeeh/linux |
15:38 | ralix | yes i found it on git repo , I was just wondering because it was discussed in the forum on kernel 3.9/3.10 ... in xilka or debian and I think ... |
15:38 | dv_ | there are several kernel efforts |
15:38 | dv_ | and it can be very confusing |
15:38 | dv_ | the critical part is whether or not the platform specialties are included |
15:38 | dv_ | (hw video acceleration, GPU drivers etc.) |
15:38 | ralix | ah ok |
15:39 | ralix | thx, I had not understood exactly |
15:40 | dv_ | ideally we'd have a 3.11 kernel with the galcore and vmeta bits inside |
15:40 | dv_ | but I dont see this happening any time soon |
15:41 | ralix | well but ok , the moment I got on the CUBOX only openvpn / nfs and just try mpd |
16:00 | rabeeh | https://github.com/rabeeh/u-boot.imx6 |
16:00 | rabeeh | that's the u-boot for c1 |
16:01 | rabeeh | 'make imx6solo_c1' |
16:07 | jnettlet | dv_, _rmk_ posted his drm kernel yesterday, and has been sorting through licensing bits for galcore today. Not that that means anything :-P |
16:14 | jnettlet | dv_, I know I am being lazy not looking myself. Are you aligning the buffers used in your gstreamer vmeta plugin? |
16:17 | dv_ | the vdec calls align them already |
16:18 | dv_ | vmeta_mem->virt_addr = vdec_os_api_dma_alloc_writecombine(maxsize, align, &(vmeta_mem->phys_addr)); |
16:22 | jnettlet | ah right. Then I think we can handle the GPU copies in the Xvideo with no additional magic, just using the GPU to blit the decoded frame to the destination. |
16:23 | jnettlet | I also think I know why _rmk_'s textured XV adapter's scaled image looked bad. |
16:24 | dv_ | oh? |
16:25 | jnettlet | are the iMX6 decoded frames also aligned? |
16:25 | dv_ | yes |
16:25 | jnettlet | 64 bytes? |
16:25 | dv_ | not automatically though - you need to align them yourself |
16:25 | dv_ | (at least in theory ... in practice I have never seen unaligned allocated frames) |
16:25 | jnettlet | Vivante prefers 64 byte alignment. |
16:26 | jnettlet | for the offsets |
16:26 | dv_ | the VPU docs speak of 16 byte alignment |
16:27 | jnettlet | well if we can force them to 64 then all the hardware should be happy |
16:27 | dv_ | see https://github.com/dv1/gst-fsl/blob/master/src/vpu/framebuffers.c#L200 and https://github.com/dv1/gst-fsl/blob/master/src/vpu/framebuffers.c#L231 |
16:29 | jnettlet | oh and that is a param you can pass in. perfect |
16:29 | dv_ | param? pass in? |
16:30 | dv_ | ALIGN_VAL_TO is just a macro defined at line 34 |
16:40 | jnettlet | dv_, GstFslVpuFramebufferParams |
16:40 | jnettlet | passed into gst_fsl_vpu_framebuffers_configure |
16:40 | dv_ | ah. yes |
16:40 | jnettlet | it has an align param |
16:40 | jnettlet | sorry address_alignment |
16:40 | dv_ | this one is defined by the VPU though |
16:40 | dv_ | but I could modify it to allow for manual values |
16:42 | jnettlet | no reason to worry about it just yet. Barely getting my iMX6 board up and running :-) |
16:42 | dv_ | see decoder/decoder.c line 850 |
16:42 | dv_ | gst_fsl_vpu_framebuffers_dec_init_info_to_params(&(vpu_dec->init_info), &fbparams); |
16:46 | jnettlet | dv_, that is fine then. Ultimately the framebuffers should also be handing out 64 byte aligned buffers also if they want to be easily accelerated by the GPU |
16:47 | dv_ | in real-world tests, I have never seen physical address that were not 64byte aligned |
16:47 | dv_ | most look like: 0x182000 0x1A9000 etc. |
16:47 | jnettlet | yep. probably for the GPU. |
16:48 | dv_ | btw. I was thinking of renaming this |
16:48 | dv_ | "gst-fsl" is somewhat misleading" |
16:48 | dv_ | "gstreamer1.0-imx" would perhaps be better |
16:48 | dv_ | or gst-imx |
16:48 | dv_ | opinions? |
16:49 | jnettlet | gst-imx works for me. |
16:50 | jnettlet | I like things named after the hardware rather than the company. Then you get hardware licensed to someone else and it works the same, but the name makes no sense. |
16:50 | dv_ | better than gst-fsl, right? |
16:50 | dv_ | yes |
16:50 | dv_ | also, freescale develops tons of microcontrollers wholly unrelated to imx |
16:50 | jnettlet | sounds good to me. |
16:51 | dv_ | now I wonder if renaming in github breaks links, or if keeps a redirection stored |
16:51 | jnettle | 16:51 * jnettlet has no idea |
16:51 | dv_ | looking at their FAQ |
16:54 | dv_ | ah, they do. nice. |
17:00 | jnettlet | dv_, make sure to update the yocto builds |
17:00 | jnettle | 17:00 * jnettlet going to walk the dogs |
17:01 | _rmk | 17:01 * _rmk_ gets back to looking at the gpu stuff |
17:04 | _rmk_ | jnettlet: it also wants _gcoCONTEXT too |
17:05 | _rmk_ | and gcoCMDBUF |
17:06 | _rmk_ | and gcsQUEUE, but not gcoQUEUE |
17:17 | otavio | I'd take gstreamer-imx |
17:17 | otavio | so when 1.2 or later is out we can reuse the project |
17:17 | otavio | dv_: it does; it does not break forks thought |
17:18 | rabeeh | otavio: devs already got some boards and i'm putting things on github |
17:18 | otavio | \m/ |
17:18 | otavio | I envy them |
17:18 | otavio | heh |
17:19 | rabeeh | i'm using kernel 3.0.35; any recommendation for a github kernel i can clone and patch? |
17:19 | rabeeh | otavio: did you get you boards? |
17:19 | otavio | rabeeh: from you? I did not |
17:19 | otavio | rabeeh: Use freescale GIT |
17:19 | otavio | rabeeh: and base on 3.0.35-4.1.0 |
17:21 | rabeeh | otavio: i'll send you tracking number |
17:21 | rabeeh | your board is in Paris now :) |
17:21 | rabeeh | it's doing some sort of around the world trip |
17:21 | Juggie | rabeeh, where are the boards being manafactured? |
17:21 | dv_ | otavio: what about the 3.5.7 alpha? |
17:22 | rabeeh | otavio: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.0.35_4.1.0 ? |
17:22 | rabeeh | is there a github one ready to clone? |
17:22 | otavio | rabeeh: no github for it |
17:22 | rabeeh | i can't find any in https://github.com/Freescale |
17:22 | otavio | dv_: what you want to know? |
17:22 | otavio | :) |
17:23 | dv_ | rabeeh: and base on 3.0.35-4.1.0 |
17:23 | dv_ | you recommend kernel 3.0.35 |
17:23 | dv_ | not 3.5.7 |
17:23 | _rmk_ | rabeeh: should I assume that the audio out connector works? |
17:23 | rabeeh | _rmk_: should |
17:24 | rabeeh | we only measured the voltage levels and the fact there is SPDIF coming out |
17:24 | _rmk_ | I was meaning that marked 10 on your photo |
17:24 | rabeeh | it works perfectly fine on CuBox-i with the optical audio out |
17:24 | dv_ | okay, gotta go. later |
17:25 | rabeeh | no; that one doesn't |
17:25 | rabeeh | yet |
17:25 | rabeeh | it's a PWM based audio driver |
17:25 | _rmk_ | due to lack of U601 :) |
17:25 | otavio | dv_: 3.5.7 is an alpha kernel so no official support for service requests |
17:25 | rabeeh | you are fast :) |
17:25 | rabeeh | we will publish the design files after some cleanup |
17:26 | rabeeh | basically now it's connected directly to two pwm channels coming from the i.MX6 |
17:26 | _rmk_ | I spotted the line in/line out pads next to U601 and wondered |
17:26 | rabeeh | U601 is an optional codec that provides to amplified speakers and microphone input |
17:26 | _rmk_ | I always look at what's not on the board and wonder what its for :) |
17:27 | rabeeh | _rmk_: oh; lots of things are not on the board |
17:27 | rabeeh | as i previously said this is an internal development board that has tons of things |
17:27 | rabeeh | look at the wiki page for italic lines; those are unassembled |
17:50 | jnettlet | If I have learned anything this weekend this is it. Come out with a Gold case for the Cubox-i and you guys will sell millions :-) |
17:53 | rabeeh | :) |
17:53 | rabeeh | gold? |
17:53 | rabeeh | for women? |
17:53 | _rmk_ | jnettlet: do you have the connections on the olpc serial adapter to hand? |
17:55 | rabeeh | _rmk_: don't you have a simple usb to serial cable? |
17:55 | jnettlet | _rmk_, sure. green->pin8 red->pin10 orange->pin25 |
17:56 | rabeeh | it's 3.3 voltages; please measure before |
17:57 | jnettlet | rabeeh, all of OLPC's serial is 3.3v's |
17:57 | jnettlet | maybe the XO-1 was 5volts |
17:59 | jnettlet | nope all 3.3v |
18:00 | jnettlet | but the +3.3v on the serial adapter doesn't even need to be connected. Just gnd tx rx |
18:06 | _rmk_ | doesn't rabeeh mean of=/dev/mmcblkX in his dd line? |
18:10 | _rmk_ | right, so the first partition can't be below sector 327 because of the u-boot size |
18:18 | _rmk_ | MX6SDL SABRESD U-Boot > |
18:19 | jnettlet | hurray. 2 for 2 |
18:19 | _rmk | 18:19 * _rmk_ appears to have a root prompt |
18:20 | _rmk_ | Memory: 384MB = 384MB total |
18:20 | _rmk_ | SMP: Total of 1 processors activated (1581.05 BogoMIPS). |
18:21 | jnettlet | yep, that seems about right. |
18:22 | rabeeh | :) |
18:22 | _rmk_ | hmm |
18:22 | _rmk_ | sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00010000 |
18:22 | _rmk_ | mmc1: req failed (CMD5): -110, retrying... |
18:23 | rabeeh | 1581 bogomips since it boots with 800MHz |
18:23 | rabeeh | cat /proc/cpuinfo while memtester is running in the background would show you 1ghz |
18:23 | rabeeh | bogomips = 2x cpu speed on cortex-a9 |
18:23 | jnettlet | scaling says it should drop to 400Mhz |
18:23 | rabeeh | yes. |
18:24 | rabeeh | when hdmi blanks ddr interface should scale down from 400mhz to 25mhz too |
18:24 | jnettlet | oh nice. |
18:25 | _rmk_ | I can see I'm going to need some more network and hdmi cables |
18:26 | _rmk | 18:26 * _rmk_ wonders if this fits in a RPi case |
18:30 | dv_ | rabeeh: got it |
18:30 | jnettlet | my crappy rapoo wireless keyboard/touchpad combo work. hurray. |
18:30 | dv_ | dv_, make sure to update the yocto builds <- ? |
18:31 | jnettlet | dv_, still sorting out the OE layers I am using. |
18:31 | jnettlet | I want to test the KMS driver. |
18:31 | dv_ | but what should I update? |
18:31 | rabeeh | dv_: congrats |
18:31 | rabeeh | lets see now how fast you can get u-boot and kernel prompt :) |
18:31 | dv_ | rabeeh: unfortunately I cannot do anything with it until friday afternoon |
18:31 | dv_ | got important things to finish first |
18:32 | jnettlet | dv_, if you rename the plugin don't you need to change the meta info? |
18:32 | dv_ | what meta info? |
18:32 | dv_ | I didnt build these plugins with OE yet |
18:32 | dv_ | there are currently no recipes for it |
18:32 | jnettlet | ah okay. I thought you had them included already. |
18:33 | dv_ | it would probably be best to add these to meta-fsl-arm |
18:33 | dv_ | or meta-fsl-arm-extra |
18:33 | dv_ | as said, in the weekend i have more time for this |
18:33 | _rmk_ | ok, my HDMI works too :) |
18:33 | dv_ | so, gotta tend to other things again. ttyl |
18:33 | jnettlet | _rmk_, did you boot with it plugged in? My hotplug didn't work. |
18:34 | _rmk_ | no, but I did have to do: echo -e "\033[9;0]" >/dev/tty1 to wake it up |
18:34 | _rmk_ | PHY: 1:00 - Link is Up - 1000/Full |
18:34 | _rmk_ | :) |
18:35 | rabeeh | _rmk_: udhcpc |
18:35 | jnettlet | ah, that might have been the problem. I hadn't hooked up my keyboard yet. |
18:35 | jnettle | 18:35 * jnettlet is off to fix dinner. ttyl |
18:35 | _rmk_ | and yes, network works |
18:35 | rabeeh | ttyl |
18:36 | rabeeh | great |
18:36 | _rmk_ | this kernel is quite noisy |
18:37 | rabeeh | lots of debug messages from my hacking |
18:38 | _rmk_ | iirc you said the carrier board is your standard dev board? |
18:39 | rabeeh | yes |
18:39 | rabeeh | for the imx6 |
18:42 | Juggie | rabeeh, not saying this would be necessairy for the cubox, but would it be possible for the imx6 to have 2 gbit lan ports? |
18:42 | Juggie | or just not enough bus speed? |
18:42 | rabeeh | yes it can |
18:42 | rabeeh | through pci-e |
18:42 | rabeeh | but that's a different board |
18:46 | Juggie | so what you are using does not have the bus speed for sure |
18:46 | Juggie | to keep it low cost |
18:46 | Juggie | which is fine. |
18:49 | Juggie | I was just pondering if imx6 would make a good router. |
18:51 | rabeeh | Juggie: is there a mini PCI-E ethernet card? |
18:51 | rabeeh | i have boards with mini PCI-E card option i can try |
19:03 | Juggie | rabeeh, posibly? i never looked. |
19:05 | Juggie | http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166019 |
19:05 | rabeeh | this requires a mini PCI-E to PCI-E adapter |
19:06 | Juggie | mini pcie? |
19:06 | cbxbiker61 | i always buy ath9k mini pci-e cards |
19:06 | Juggie | so you have a mini pci-e card slot |
19:07 | Juggie | cbxbiker61, we were talking lan not wireless |
19:07 | rabeeh | http://en.wikipedia.org/wiki/PCI_Express#PCI_Express_Mini_Card |
19:07 | cbxbiker61 | oh, yep |
19:08 | Juggie | http://www.amazon.com/StarTech-ST1000SMPEX-Express-Gigabit-Ethernet/dp/B006VCPB2S |
19:08 | Juggie | something like that |
19:10 | Juggie | Realtek RTL8111E |
19:10 | Juggie | is the chipset |
19:17 | rabeeh | yes. |
19:18 | rabeeh | something like that; a bit scary putting the ethernet wires on that cable :) |
19:34 | Juggie | y? |
19:38 | rabeeh | Gigabit ethernet signals are 125MHz DDR; and carrying those on a cable like that looks more like a toy |
19:39 | jnettle | 19:39 * jnettlet agrees. |
19:39 | jnettlet | when you are taught to wire a punch down block having your twisted pair that untwisted would not be acceptable. |
19:44 | Juggie | i guess |
19:44 | Juggie | over a short cable though i doubt it matters |
19:56 | jnettlet | hmmm. Better but still not great. http://www.ebay.com/itm/Mini-PCI-Express-PCIe-Gigabit-Ethernet-x2-Network-Adapter-NIC-Card-2-Port-/221070821678?_trksid=m263&_trkparms=algo%3DSIC%26its%3DI%26itu%3DUCI%252BIA%252BUA%252BFICS%252BUFI%26otn%3D10%26pmod%3D110851823925%26ps%3D50 |
20:02 | jnettlet | okay these seem pretty reasonable. http://www.amazon.co.uk/Mini-Express-Gigabit-Ethernet-Controller/dp/B0058W2Y7C/ref=sr_1_5?s=computers&ie=UTF8&qid=1380132010&sr=1-5&keywords=mini+pci+express+gigabit#productDetails |
20:07 | Juggie | over a short distance |
20:07 | Juggie | i dont think its a problem |
20:08 | Juggie | you could run gbit over 8 wire clothes hangers if you had to |
20:08 | Juggie | for a few feet |
20:11 | cbxbiker61 | amd does their live release of new radeons in 50 minutes on youtube |
20:12 | cbxbiker61 | i'd sure like it if they would mention the new FX cpu's |
21:35 | _rmk_ | jnettlet: yay, I now have the galcore updates right at the beginning of my galcore branch :) |
21:40 | jnettlet | _rmk_, hurray |
21:42 | jnettlet | _rmk_, any chance you want to move it to drivers/gpu/galcore and add proper Kconfig/Makefile support and options? |
21:43 | jnettlet | Freescale took the initial work that I did and added it to their tree. |
21:43 | _rmk_ | I still have quite a delta post my updates to the version I manually pulled from your git repo |
21:44 | _rmk_ | so not quite there yet, but getting closer :) |
21:44 | jnettlet | fair enough. |
21:47 | jnettlet | I have harassed Vivante again about trying to build a direct community relationship. I figure if I just keep mailing people in my contacts list someone will have to respond. |
22:30 | rabeeh | i have two patches now ready against 3.0.35 bsp 4.1.0 from freescale |
22:31 | rabeeh | anyone suggest where to post? |
22:34 | jnettlet | rabeeh, is 3.0.35 going to be the shipping kernel? |
22:35 | jnettle | 22:35 * jnettlet is still sorting through Freescale's kernel projects. |
22:36 | rabeeh | jnettlet: i hope not |
22:36 | rabeeh | by then (2 months) fsl might have a newer kernel |
22:36 | rabeeh | i'm mainly looking at their mainline support |
22:40 | jnettlet | okay. |
22:46 | rabeeh | hi paco |
22:46 | pacolm | hi rabeeh, good night |
22:47 | _rmk_ | jnettlet: just looking at what was done with gckOS_WaitSignalNoInterruptible |
22:47 | _rmk_ | in gc_hal_kernel_command.c, there used to be two calls to gckOS_WaitSignal() before that was introduced |
22:48 | _rmk_ | the one in the Stall function was converted to NoInterruptible, which is good |
22:48 | _rmk_ | but the one in _NewQueue wasn't changed |
22:49 | _rmk_ | so... if we get a signal (remember, X11 uses signals for scheduling) we error out |
22:50 | cbxbiker61 | rabeeh, if cubox-i must have fat partition for u-boot, why don't we make that 250-300M so we can throw an installer on there to create the root fs |
22:51 | rabeeh | cbxbiker61: that's a good idea |
22:51 | rabeeh | i like more the self installation type; but somehow devs tend to throw raw images |
22:51 | jnettlet | _rmk_, looking |
22:51 | rabeeh | i mean from all the devs i'v worked on the cubox; their default is throw a tarball; or an ext image |
22:53 | _rmk_ | jnettlet: the vivante code has two return "modes" - everything was succesful, or there was a failure. There's no room for a "but we got a signal so need to drop back to userspace to run the signal handler and then restart" |
22:53 | pacolm | I like cbxbiker61 idea. This guy was my salvation when I start playing with Guruplugs! |
22:55 | pacolm | Using an built-in installer is better than downloading images or tarballs and then copying to the uSD |
22:56 | jnettlet | _rmk_, yep. I see that. |
22:59 | _rmk_ | what should've happened is gckOS_WaitSignal() should've been made uninterruptible and be done with it |
23:07 | pacolm | good night everyone |
23:11 | cbxbiker61 | amd's adding some sort of advanced audio processor to their new gpus |
23:19 | jnettlet | _rmk_, sorry I had to record a teaser trailer for the next Unleash Kids broadcast |
23:19 | rabeeh | http://imx.solid-run.com/wiki/index.php?title=Building_Carrier-One_U-boot_and_Kernel |
23:20 | rabeeh | ok. now both u-boot and kernel for carrier-one has machine ID 4773 |
23:20 | rabeeh | i'm uploading the freescale git tree to github; hopefully tomorrow it will be ready so we can start patching it. |
23:24 | jnettlet | _rmk_, in the newest driver version WaitSignal is not uninterruptable and WaitSignalNoInterruptible doesn't exist, but all WaitSignal calls have a time of gcvINFINITE which equates to non-interruptible |
23:26 | _rmk_ | jnettlet: in the v4 driver? |
23:32 | jnettlet | _rmk_, sorry I was reading my notes. Comparing it to the code now. |
23:41 | rabeeh | http://download.solid-run.com/pub/solidrun/c1/kernel/initial/ |
23:41 | rabee | 23:41 * rabeeh goes to sleep |
23:52 | jnettlet | _rmk_, I remember why an Uninterruptible signal was bad. If the hardware goes haywire the userspace code can get completely stuck waiting for a signal that is never going to happen. |
23:53 | _rmk_ | maybe you want to use a wait there which only allows SIGKILL then |
23:54 | _rmk_ | wait_for_completion_killable_timeout() ? |
23:55 | jnettlet | In my local branch I have moved the signal_pending check to the bottom of the loop. I think that fixed most of the raciness I was seeing. |
23:56 | _rmk_ | can I see your code there? |