| 00:46 | ptl | does anyone know where I can get the source for the kernel used in CuBox, with all patches applied and .config set? |
| 00:55 | _rmk | 00:55 * _rmk_ chucks out the sdhci patches |
| 01:05 | _rmk_ | I think that's about it for the v3.8 merge window... I guess the next easy one should be the hwmon stuff, but that needs sorting properly |
| 01:05 | _rmk_ | that will leave vmeta and sorting the video driver one way or another, and galcore |
| 01:08 | _rmk_ | once 3.7 is out, I'll rebase my copies of these patches onto v3.7 and make that available (which should be the same as folk have queued for the merge window) |
| 01:08 | _rmk_ | the difference will be, mine will be directly on top of v3.7, rather than some other point |
| 02:03 | ptl | does anyone know where I can get the source for the kernel used in CuBox, with all patches applied and .config set? |
| 07:37 | jnettlet | _rmk_, I am working on getting galcore 4.6.4 and suite released for use right now...it is pending Legal okay at Marvell. |
| 07:37 | jnettlet | of course userland will still be binary HAL, and EGL/GLESv2 |
| 10:00 | shesselba | _rmk_: You want me to add any acked-by or tested-by to the sdhci patches? BTW it's spelled "Hesselbarth". |
| 10:02 | _rmk | 10:02 * _rmk_ wonders where that typo came from :) sorry about that |
| 10:02 | _rmk_ | lets wait for Sascha to respond to my reply first |
| 10:03 | shesselba | IRC, rabeeh used it once or twice.. no big deal - it's a long name ;) ok, I ll wait |
| 10:04 | _rmk_ | "Code done by Sebastian Hasselbrath" - yep, that's where I got it from |
| 10:16 | rabeeh | my fault? |
| 10:16 | _rmk_ | the above is what's in your git tree :( |
| 10:17 | rabeeh | jnettlet: do you have android GPU drivers too? |
| 10:19 | _rmk_ | jnettlet: I wonder if they're going to obfuscate gc_hal_kernel_hardware.c in the same way |
| 10:20 | _rmk_ | ... and still provide the macros that were used for that obfuscation |
| 10:24 | _rmk_ | jnettlet: also... will it be an arhmf or armel release of userspace? |
| 10:24 | _rmk | 10:24 * _rmk_ hopes both. |
| 10:24 | _rmk_ | or failing that, armhf |
| 11:17 | jnettlet | rabeeh, yes android as well...although I haven't explicitely asked to release them. We are dabbling in an Android release for our hardware, so I should probably do that now. It takes forever. |
| 11:19 | jnettlet | _rmk_, do you mean those horrible long register writes? Yeah those are the same. Haven't looked for the macros, can check...yes I have them build everything for hardfp |
| 11:19 | jnettlet | Everything is compiled for hardfp and iwmmxt |
| 11:21 | rabeeh | jnettlet: there is interest in getting JellyBeans on CuBox. that would be very helpful. |
| 11:23 | jnettlet | rabeeh, We only have ICS right now. Although the newest framebuffer drivers expose the vsync uevents needed for Jellybean's project butter |
| 11:26 | rabeeh | oh; so probably the same binaries can run as-is on CuBox? |
| 11:26 | rabeeh | have a pointer for code drop? |
| 11:26 | rabeeh | using r3184 i assume |
| 11:27 | jnettlet | it is using vivante's 4.6.4 with Marvell specific tweaks. I am still in Legal limbo getting the okay to release that. It is making our C1 board release very difficult |
| 11:27 | Kiranos | jnettlet: what is your project? |
| 11:27 | jnettlet | their's might be 4.6.2. |
| 11:27 | jnettlet | Kiranos, I work for OLPC (One Laptop Per Child) |
| 11:28 | ralix | damn damn, I can not drive by a usb boot;-) |
| 11:28 | ralix | Sorry Good Morning @ alldamn damn, I can not drive by a usb boot;-) |
| 11:28 | ralix | Sorry Good Morning @ all |
| 11:28 | ralix | copy and paste error ;-) |
| 11:29 | rabeeh | hi ralix. |
| 11:30 | Kiranos | hope the rest of the day dosnt continue in the same vein :P |
| 11:31 | dotarray | hi ralix :) |
| 11:34 | ralix | I wanted to boot from a usb drive. I made it according to the instructions: "http://archlinuxarm.org/platforms/armv7/cubox" |
| 11:34 | ralix | Uncompressing Linux... done, booting the kernel. |
| 11:34 | ralix | m25p80 spi0.0: unrecognized JEDEC id 20ba16 |
| 11:34 | ralix | mmc0: Card removed during transfer! |
| 11:34 | ralix | mmc0: Resetting controller. |
| 11:34 | ralix | Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) |
| 11:34 | ralix | :( |
| 11:36 | Kiranos | [11:34:36] mmc0: Card removed during transfer! |
| 11:36 | Kiranos | that doesnt sound to good |
| 11:36 | ralix | rabeeh, The arrangement of the interfaces and the serial-usb at the rear Cubox is nice as my first :) |
| 11:36 | Kiranos | have you tried another sd-card? |
| 11:37 | ralix | I booted completely without sdcarte, only one hard drive |
| 11:52 | jnettlet | It still amazes me that I can get a nano-usb plug that provides 300Mbs 802.11 |
| 12:09 | RandomPixels | hello |
| 12:09 | ralix | New try :) booting from mmc and root on sda1: |
| 12:09 | ralix | Uncompressing Linux ... done, booting the kernel. |
| 12:09 | ralix | M25P80 spi0.0: unrecognized JEDEC id 20ba16 |
| 12:09 | ralix | Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (0.0) |
| 12:09 | ralix | hello RandomPixels |
| 12:09 | RandomPixels | E: Package git has no installation candidate |
| 12:09 | RandomPixels | any ideas? :) |
| 12:10 | ralix | I do not understand |
| 12:10 | RandomPixels | trying to apt-get install git |
| 12:11 | Kiranos | git-core |
| 12:11 | RandomPixels | actually, i'm trying to set up a XBMC using rabeeh's fork |
| 12:12 | RandomPixels | thanks Kiranos |
| 12:51 | ralix | f*ck |
| 13:00 | ralix | I'm too stupid ;-) |
| 14:03 | RandomPixels | trying geexbox :) |
| 14:11 | ralix | no ;-) |
| 14:12 | ralix | I like archlinux ... geexbox is quite nice, I had already tested. |
| 15:15 | rabeeh | I did send Rabeeh a few patches which sort out the memory grabbing for vmeta/bmm/gpu stuff but I don't think he ever merged them |
| 15:15 | rabeeh | rmk_: the ioctl callback to the vmeta driver somehow didn't reach to the point where it really shuts down the power of vmeta when unused |
| 15:15 | rabeeh | that hack was somehow to force it to do that. |
| 15:16 | rabeeh | (ugly unclean hack). |
| 15:16 | rabeeh | to explain that, Dove has few power domans - |
| 15:16 | rabeeh | to explain that, Dove has few power domains - |
| 15:16 | rabeeh | oh; rmk_ is not online. anyhow i will continue the speech and point him out on the logs |
| 15:16 | rabeeh | 1. cpu domain |
| 15:16 | rabeeh | 2. gpu domain |
| 15:16 | rabeeh | 3. vmeta domain |
| 15:17 | rabeeh | 4. peripherals (or sometimes called core) |
| 15:17 | rabeeh | 5. rtc |
| 15:17 | rabeeh | for the gpu/vmeta you can control the clock (on/off) and power (on/off). Somehow the ioctls back from the vmeta user space driver didn't reach a point where vmeta power down is reached |
| 15:18 | rabeeh | so constant power was drawn. |
| 15:49 | ralix | rabeeh, Are you working yet on Cubox-installer, so that one can not only install on mmc but also on usb / sata? |
| 15:50 | rabeeh | ralix: it's in the queue |
| 15:51 | rabeeh | install from hdmi is first |
| 15:51 | rabeeh | patches welcomed :) |
| 15:51 | ralix | ok |
| 15:51 | rabeeh | https://github.com/rabeeh/cubox-installer |
| 15:51 | ralix | I have difficulty reading archlinux install a usb hda, and I just wanted to get the sources ;) |
| 15:52 | ralix | I've already found;-) , I'll checkout when I'm at home . |
| 15:52 | rabeeh | i think the changes would be root=/dev/sda1 or something like that |
| 15:52 | rabeeh | maybe rootdelay=5 is also needed to wait for usb stick to connect to subsystem. |
| 15:53 | ralix | I'll try, but it loads the kernel already on the hdd and then Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (0.0) |
| 15:53 | rabeeh | do you have the 'root=...' set? |
| 15:56 | ralix | yes, |
| 15:56 | ralix | ox systemd top usb boot scrip{echo ======== Setting bootargs ======== |
| 15:56 | ralix | setenv bootargs 'console=ttyS0,115200n8 console=tty1,115200n8 init=/bin/systemd root=/dev/sda1 rw vmalloc=384M video=dovefb:lcd0:1280x720-32@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=0 usb0Mode=host usb1Mode=host' |
| 15:56 | ralix | echo ======== Loading kernel ======== |
| 15:56 | ralix | ext4load usb 0:1 0x00200000 /boot/uImage |
| 15:56 | ralix | echo ======== Booting kernel ======== |
| 15:56 | ralix | bootm |
| 15:59 | dung | ralix, try bootarg rootwait |
| 15:59 | dung | http://www.solid-run.com/mw/index.php/Kernel_parameters |
| 16:00 | ralix | ok i try ... 5 Minutes |
| 16:06 | ralix | There it is going! YOU have my degree was real happy! |
| 16:11 | ralix | Ok, I can now happily at home after. |
| 16:12 | _rmk_ | umm, console=tty1 doesn't take any other arguments |
| 16:12 | _rmk_ | and if you have systemd installed, it should run just as 'init', the init= argument shouldn't be required |
| 16:13 | ralix | ok thx :) ! |
| 16:13 | dung | isn't just one console? |
| 16:13 | _rmk_ | dung: you can have multiple consoles, but only the first is the primary one |
| 16:13 | _rmk_ | the output is duplicated on the others you list |
| 16:14 | _rmk_ | rabeeh: right, I've noticed that libvmeta doesn't get the appropriate callbacks from the closed source part for the power control |
| 16:30 | jnettlet | _rmk_, do you mean the vdec_os_api_clock_on clock_off power_on power_off calls? |
| 16:30 | _rmk_ | yup |
| 16:31 | jnettlet | those don't get called by the UIO binary...they should be called by whatever is using libvmeta to decode the video. So the gstreamer plugin implements those calls |
| 16:32 | jnettlet | or should. Just like the xbmc implementation should also implement those calls if it wants to clock things up or down. |
| 16:33 | jnettlet | in most the reference code the clocking should actually be based on the resolution of the video to be decoded. |
| 16:34 | _rmk_ | it looked to me like libcodecvmetadec makes the clock calls |
| 16:34 | _rmk_ | and it makes some of the power calls; certainly when the codec library is initialized |
| 16:39 | _rmk_ | in any case, the uio kernel folk have rejected vmeta outright due to the ioctl stuff, so either it stays out of mainline or we switch to my misc device version (which I of course have the appropriate libvmeta for) |
| 16:39 | jnettlet | I actually have a test version that switches the ioctl version to using sysfs |
| 16:39 | _rmk_ | why bother |
| 16:39 | jnettlet | my hope was to submit it to show the UIO folks that their response was ridiculous and it has basically made uio an almost useless subsystem. |
| 16:40 | jnettlet | it is most ridiculous to create something and tell vendors that have to provide binary drivers...use this, but then completely limit the functionality. |
| 16:41 | _rmk_ | no; I'm on the side of the UIO folks on this |
| 16:41 | _rmk_ | and quite honestly the vmeta uio driver is rather crappy |
| 16:42 | _rmk_ | there's a whole bunch of things it can do better, and all that user ID management is rather broken |
| 16:44 | _rmk_ | http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=libvmeta.git |
| 16:44 | _rmk_ | that's my version of libvmeta |
| 16:44 | _rmk_ | the kernel side isn't fully debugged; there's still horrid bugs in the user id management code |
| 16:44 | _rmk_ | especially with the "lets wipe out all state on force-init" thing which breaks any other concurrent user |
| 16:46 | _rmk_ | as for the locking in the original kernel driver, that was total crap (which is actually putting it in a nice way) |
| 16:46 | _rmk_ | and the clk API handling was just as bad |
| 16:49 | jnettlet | yes but that stuff was never going to get fixed because when Marvell first tried to get the driver included they got shot down on the ioctl's |
| 16:49 | jnettlet | and they had no real incentive to make it better because all the hardware was basically single user systems |
| 16:50 | _rmk_ | well, strangely the ioctls are just fine as a misc device |
| 16:50 | jnettlet | sure, but I thought misc devices that were only used by binaries wouldn't be accepted upstream ? |
| 16:50 | _rmk_ | oh, and... btw.. the irq handling in libvmeta is broken; after the first IRQ it just returns immediately because nothing ever does the required UIO read. |
| 16:52 | jnettlet | I never noticed that problem. Could be fixed in my version of the driver. |
| 16:52 | _rmk_ | when I discussed with gregkh, he basically agreed that this as a miscdevice would be fine |
| 16:52 | _rmk_ | that was after I went through the licensing battle with him |
| 16:53 | _rmk_ | I have 52 commits against that vmeta kernel driver |
| 16:54 | jnettlet | If it is getting converted to a miscdevice why not dump bmm and just do the dma directly from the vmeta driver? |
| 16:58 | _rmk_ | do we want the X server opening the vmeta device? I don't think we do; it makes development against it harder because you'd have to shut the X server down to remove vmeta as a kernel module. |
| 16:58 | _rmk_ | afaics bmm is better off being separate at the moment |
| 17:08 | jnettlet | sorry wife called. The X server shouldn't open the vmeta device. The userspace program should open the vmeta device causing vmeta to request a dma-buf then it can generate a fd which can be passed up to the accessing program. |
| 17:10 | jnettlet | the userspace program, should then be able to use dri2 to render the decoded frame on screen. |
| 17:11 | _rmk_ | what you're suggesting means getting rid of the overlay completely, and involve having to have the GPU blit the image into the screen |
| 17:12 | _rmk_ | I'd rather keep Xv with its overlay support |
| 17:12 | jnettlet | do you have kms overlay support in your driver? |
| 17:12 | _rmk_ | of course :) |
| 17:14 | _rmk_ | supporting not only the common YUV formats but also the ones vmeta likes to spit out, both in BMM mode and as DRM buffer objects passed via named buffers (which my bmmxvimagesink makes use of) |
| 17:16 | _rmk_ | you can run software-decoding vlc against my X server and it works; try that with the standard dove backend driver and it'll grind because vlc has inefficient format conversion |
| 17:19 | jnettlet | I believe you would just need to change your bmmxvimagesink to hook directly to the kms-overlay instead of going through XV....basically allowing you to decode video via gstreamer without needing an X server running. |
| 17:19 | jnettle | 17:19 * jnettlet has to run. back in an hour or so. |
| 17:26 | _rmk_ | except there's a huge can of worms surrounding colourkeying, cropping and in multi-head setups which crtc to use, and with virtual X resolutions where on the screen the image should be placed... |
| 17:40 | RandomPixels | hello guys |
| 17:40 | RandomPixels | i ran into some trouble trying to install geexbox for cubox |
| 17:40 | RandomPixels | anyone did it successfully ? |
| 20:29 | RandomPixels | hello |
| 20:30 | RandomPixels | anyone around ? |