| 08:45 | zeev234 | Hi, are there regualar usb ports on cubox-i ? how am I suppose to connect mouse and keyboard? |
| 08:53 | jnettlet | zeev234, you could use USB, Bluetooth, or InfraRed if you really wanted to. |
| 08:54 | zeev234 | can I plug both keyboard AND mouse using USB? |
| 08:55 | jnettlet | zeev234, are you asking if it has two usb ports? The original Cubox had two usb ports, I don't have the exact details on the Cubox-i but I believe that the ports are all the same. |
| 08:56 | jnettlet | regardless you can of course use a usb hub. |
| 08:59 | zeev234 | yes, 1. how many ports does Cubox-i has? 2. are they standard or micro? |
| 09:16 | wumpus | zeev234: the original has two full-sized usb ports for connecting devices and a micro-usb for serial output |
| 09:17 | zeev234 | and Cubox-i? |
| 09:17 | zeev234 | only one micro USB, is it correct? |
| 09:18 | wumpus | yes, and the micro usb is not for connecting devices, it is for serial communication to a host |
| 09:18 | wumpus | no idea if it can be used in master mode |
| 09:19 | wumpus | if you want to connect more than two usb devices you need a hub |
| 09:19 | zeev234 | will I be able to use this micro USB port to connect a hub, and then connect a keyboard, a mouse and a disk-on-key to the hub? |
| 09:20 | wumpus | no, you can only use the full sized usb ports for that, as I said the micro port is a USB slave not master |
| 09:21 | zeev234 | as far as I understood the full sized ports are not available on the new Cubox-i only on the old model, or am I wrong? |
| 09:22 | zeev234 | at least I don't see it in the specs... |
| 09:22 | wumpus | I'm purely talking about the original one, I don't know about the ports on the -i variant |
| 09:23 | wumpus | but AFAIK it's externally the same |
| 09:23 | zeev234 | ok thanks. I would like know how one connects a disk-on-key to the new -i model . Specs do not mention any standard USB port and I don't see it on the picture... |
| 09:26 | wumpus | and I really doubt they took away usb ports on the new model, though they indeed don't mention it in the specs @rabeeh |
| 09:29 | zeev234 | rabeeh: are the two USB ports still there on the -i model? (if yes - you probably should update the specs) |
| 09:56 | rabeeh | zeev234, wumpus: the new models has two power USB 2.0 hosts (full size) |
| 09:56 | zeev234 | great thanks |
| 09:57 | wumpus | that's what I thought, thanks |
| 09:58 | rabeeh | the control over the two USB hosts is separated; meaning you can turn on and off each USB power alone |
| 10:07 | jnettlet | rabeeh, oh you can? That is excellent. |
| 13:34 | roentgen | Hi guys |
| 13:35 | roentgen | Anyone knows if it's possible to make wifi hotspot with cubox? |
| 13:36 | roentgen | the usual stuff with hostadp in a Linux ARM distro |
| 13:39 | wumpus | well at least of you plug in the right wifi dongle it will work |
| 13:40 | wumpus | whether the built-in wifi of cubox-i can do it, no idea |
| 13:40 | wumpus | depends on the chipset they used |
| 13:45 | roentgen | wumpus: yes, I really mean the internal wifi. I'd like to save the usb ports for something else |
| 13:46 | jnettlet | I think the internal wifi is a broadcom chip. rabeeh mentioned the other day, but I don't have my IRC logs handy |
| 13:55 | roentgen | jnettlet: thanks, I'll go search some more, brb |
| 14:54 | _rmk_ | jnettlet: any view on whether the vivante GPU needs a valid source to do any kind of fill operation? |
| 14:55 | _rmk_ | I occasionally see my X server lock up at boot on the very first operation - the GPU seems to have run the instructions (by way of its 'current address') but I don't see my fence data in memory being updated |
| 14:56 | _rmk_ | I can't see why the GPU would want to read the source on a solid fill with a 0xf0 ROP... but who knows, it could be buggy |
| 15:07 | _rmk_ | hmm, that's not it |
| 15:12 | jnettlet | _rmk_, Does the Xorg server just spin at 100%, and the GPU has fired a single interrupt? |
| 15:15 | _rmk_ | I put a micro-sleep in, so it doesn't spin at 100%, but in effect it does, and yes, no interrupt (but then there isn't an EVENT command in the GPU command queue) |
| 15:15 | _rmk_ | it sounds like you know of this :) |
| 15:16 | jnettlet | _rmk_, yeah I had something similar...just trying to wake up the neurons that store that information. |
| 15:17 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/gpu-cmds.txt is the sum total of all the commands submitted to the GPU after boot up to the point it gets stuck |
| 15:17 | _rmk_ | reg 0x664 (the current address) is at 0x10281010 |
| 15:19 | _rmk_ | and the word at 0x2f100000 is 0xffffffff (which is what I initialise that to before telling the GPU to fill that location with - in this case - '1') |
| 15:19 | _rmk_ | the previous command is another GPU fill, clearing the framebuffer to black. |
| 15:24 | jnettlet | So you destination pixmap is at 0x10281010? |
| 15:25 | _rmk_ | no, that's the current gpu instruction address read from 0x664 (see the guard thread code) |
| 15:27 | _rmk_ | the destination pixmap for the first is 0x2f200000, and the second is 0x2f100000 |
| 15:28 | jnettlet | yep. got it. |
| 15:29 | _rmk_ | it's not easy to see whether the first GPU operation was done or not, because chances are that memory is already initialized to 0 |
| 15:29 | _rmk_ | so asking for it to be filled with colour 0... |
| 15:32 | wumpus | _rmk_: you need to make sure that the ROP is set on fill operations |
| 15:33 | wumpus | _rmk_: if you set the ROP that a source is needed, it may be looking for a source |
| 15:33 | _rmk_ | that's what the 0xf0 is |
| 15:33 | jnettlet | that should be plain solid fill |
| 15:34 | _rmk_ | yep - I just tried giving it a source... no difference in behaviour |
| 15:35 | _rmk_ | I'll try reading the profile registers in a moment, and see if there's any info that can be gathered from those |
| 15:35 | jnettlet | I think I have partially repressed some of this early debugging because the drivers and hardware were so buggy at the time. |
| 15:36 | wumpus | 0803048A 2F200000 00001400 00000000 LOADSTATE 0x1228 - Target Address, Stride |
| 15:36 | wumpus | oh wait, it's ok |
| 15:40 | jnettlet | I have to walk the dogs. I will chew on this and see if I can remember what was causing it. |
| 15:43 | wumpus | can you try a rop of 0xcc instead of 0xf0? |
| 15:43 | _rmk_ | heh. apparantly, 0xBABEF00D pixels have been rendered |
| 15:43 | wumpus | 0801048F 000000C0 LOADSTATE 0x123c - ColorConvert -- also, doesn't this load the pattern cache? |
| 15:44 | wumpus | if you're not loading a pattern it may do a load from 0 |
| 15:44 | wumpus | not sure tho |
| 15:44 | wumpus | hehe that looks like a very messed up state |
| 15:44 | _rmk_ | wumps: this is what I'm doing: |
| 15:44 | _rmk_ | gco2D_LoadSolidBrush(vivante->e2d, gcvSURF_A8R8G8B8, 0, col, ~0ULL); |
| 15:44 | _rmk_ | gco2D_SetClipping(vivante->e2d, &rect); |
| 15:45 | rabeeh | jnettlet: wifi / bt is bcm4329 based |
| 15:45 | _rmk_ | gco2D_SetTarget(vivante->e2d, handle, 64, gcvSURF_0_DEGREE, 0); |
| 15:45 | wumpus | I had some problems with accidentally rop'ing in patterns at a certain point, but I'm not sure it was with clear |
| 15:45 | _rmk_ | gco2D_Blit(vivante->e2d, 1, &rect, 0xf0, 0xf0, gcvSURF_A8R8G8B8); |
| 15:45 | _rmk_ | where rect is a 1px by 1px rectangle |
| 15:45 | _rmk_ | this is all for the 2nd op - the 0x2f100000 one |
| 15:46 | _rmk_ | col = 1, handle = 0x2f100000 |
| 15:46 | wumpus | ok |
| 15:47 | wumpus | yeah, debugging vivante gpu hangs is always lots of fun :p |
| 15:49 | wumpus | indeed, the second op is rendering one 1x1 rectangle, the first one 1280x720 rectangle |
| 15:55 | wumpus | but have you tried with a rop of 0xCC instead of 0xF0? 0xF0 is "pattern only" afaik, whereas 0xCC is "source only" |
| 15:56 | _rmk_ | as this is supposed to be a fill, 0xf0 is correct - note that a source isn't being setup |
| 15:56 | wumpus | yes but 0xf0 sources from a pattern |
| 15:56 | wumpus | which is not set up |
| 15:57 | wumpus | then again that should be ignored for a fill but yeah... |
| 15:57 | _rmk_ | I thought the pattern is 08020492 FFFFFFFF FFFFFFFF |
| 15:59 | wumpus | that's the color mask, not the pattern, pattern is distinct from source/destination, its address is set up through 0x1238 |
| 16:00 | _rmk_ | hrm... that doesn't behave as a color mask when I set it to non-1s |
| 16:03 | cbxbiker61_ | rabeeh, i downloaded IMX_MMCODEC_3.0.5_Bundle from freescale, it appears that they don't have hardfp versions in the bundle |
| 16:04 | cbxbiker61_ | https://community.freescale.com/thread/302776 |
| 16:05 | cbxbiker61_ | looks like you may have to work with Genesi or some other partner for hardfp libraries. |
| 16:07 | dv_ | otavio: any infos about hardfp mmcodecs? |
| 16:09 | dv_ | cbxbiker61_: but why do you want the imx mmcodecs? |
| 16:11 | cbxbiker61_ | libGLES*, maybe libOpenCL* |
| 16:12 | cbxbiker61_ | also libGL* |
| 16:14 | dv_ | download these instead: |
| 16:14 | dv_ | http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/gpu-viv-bin-mx6q-3.5.7-1.0.0-alpha.2-hfp.bin (hardfp) |
| 16:14 | dv_ | http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/gpu-viv-bin-mx6q-3.5.7-1.0.0-alpha.2-sfp.bin (softfp) |
| 16:15 | dv_ | there are also non-alpha versions . not sure what is the difference. |
| 16:15 | dv_ | (here is a mirror: http://download.ossystems.com.br/bsp/freescale/source/ ) |
| 16:17 | dv_ | what are you using for setting up your rootfs? yocto? |
| 16:18 | cbxbiker61_ | i don't have the cubox-i yet, but I was going to try to migrate a cubox image to the cubox-i |
| 16:19 | cbxbiker61_ | i've built a preliminary imx.6 kernel, we'll see how that goes with i get the cubox-i |
| 16:23 | _rmk_ | wumpus: what I mean by that is if I set it to 0xffff0000 0xffff0000, I see the GPU write 16 pixels, avoid the next 16, etc. It doesn't prevent writing to the lower 16 bits of each pixel. |
| 16:25 | _rmk_ | I assume to get a loadstate against 0x1238, gco2D_ConstructColorBrush() needs to be used? |
| 16:31 | jnettlet | _rmk_, that is it. It was 1px by 1px rectangles. For anything less than 4x4 we switched to using the CPU. |
| 16:31 | jnettlet | It was more performant, but also solved the hangs. |
| 16:31 | wumpus | yes you were right, 1248 is something w/ the pattern, just not the address |
| 16:32 | _rmk_ | jnettlet: ah, so it can't reliably do anything less than 4x4 ? |
| 16:33 | jnettlet | _rmk_, I think that was the final decision between us, Marvell and Vivante. |
| 16:33 | jnettlet | I think the actual answer from Vivante was "Why would you want to use the GPU to blit 1 pixel?" |
| 16:35 | jnettlet | _rmk_, it is possible that this was fixed in the newer drivers. I am slowly tracing through a twisted email thread on it. |
| 16:35 | _rmk_ | there's an easy answer to that with a non-cache coherent architecture, especially when the gpu libs only allow you to operate on whole surfaces :) |
| 16:36 | _rmk_ | I'm just trying something: any black fill is now going to get replaced by a fill of 0x00010101 |
| 16:36 | _rmk_ | this way I can see if the first op has been done |
| 16:38 | _rmk_ | nope, first op doesn't get done either |
| 16:38 | _rmk_ | the 1280x720 one |
| 16:38 | wumpus | hm, let's try some 1x1 fills |
| 16:39 | _rmk_ | lemme just try telling the GPU to go back to 0x10281000 |
| 16:39 | jnettlet | wumpus, which version of the kernel driver API are you basing your work on? |
| 16:39 | jnettlet | 4.xxxx? |
| 16:40 | wumpus | jnettlet: various (v2, v4, imx bsp 4, etc) |
| 16:40 | wumpus | but for most devices we're using v4 now |
| 16:40 | wumpus | except the cubox really :) |
| 16:40 | jnettlet | wumpus, you really hate yourself huh? |
| 16:40 | jnettlet | :-D |
| 16:41 | jnettlet | wumpus, well I almost have my cubox merge into my 3.10lts kernel tree done. |
| 16:41 | wumpus | lol the various kernel interfaces is really crazy yes |
| 16:41 | jnettlet | That will include v4 |
| 16:42 | jnettlet | I am hoping to have everything synced to v4 so I can be standard with my Android builds |
| 16:43 | wumpus | it would be very nice to normalize on v4 |
| 16:43 | jnettlet | Then maybe we can get vivante to release source directly to the OSS community |
| 16:44 | jnettlet | hahaha |
| 16:44 | wumpus | though a v5 would be nice that removes the fields that the kernel doesn't use, but are left over from the userspace :-) |
| 16:44 | otavio | dv_: what you want? |
| 16:44 | wumpus | mth has done a great job slimming down the interface headers already, removing enumerations and structures that are not needed for kernel communciation |
| 16:46 | wumpus | also we really need _rmk_'s dmabuf support merged :D |
| 16:47 | jnettlet | they have a v5 out already? |
| 16:47 | jnettlet | It took them 3+ years to get out v4 |
| 16:47 | wumpus | no that was figuratively spoken |
| 16:47 | wumpus | but if we want any chance of upstreaming we need to get rid of the cruft, that's what I meant |
| 16:49 | jnettlet | well I think the entire kernel module is so abstracted in order to be multi-platform that it would never make it into mainline. |
| 16:49 | wumpus | yes, that's another problem |
| 16:49 | jnettlet | It is the most unkernel kernel module I have loked at |
| 16:49 | dv_ | otavio: cbxbiker61_ was wondering about the imx mmcodec package (see above) |
| 16:51 | wumpus | luckily removing abstraction layers is usually easier than thinking of and adding them |
| 16:54 | _rmk_ | ok, that unwedged it. |
| 16:55 | wumpus | I tried some 1x1 fills, no problem on my cubox |
| 16:55 | _rmk_ | stopping the GPU (by giving it an END command) and then resetting the instruction stream back to 0x10281000 and re-starting causes it to unstick |
| 16:55 | wumpus | thats interesting, I've never been able to unstuck a hung gpu yet |
| 16:56 | wumpus | apart from rebooting the whole thing |
| 16:56 | _rmk_ | admittedly, because I have the guard thread here, it blatted it with a reset too, so it may not be that simple :( |
| 16:57 | _rmk_ | so... theory... could the GPU have ignored the LINK command at 0x10280000 entirely. |
| 17:03 | _rmk | 17:03 * _rmk_ goes back to look at the first command buffer dump... |
| 17:03 | _rmk_ | 0x10281000: 4000002C 19C20000 AAAAAAAA AAAAAAAA 380000C8 AAAAAAAA 40000002 10281010 |
| 17:04 | _rmk_ | on startup, the first four words should be the wait-link looping it back to 0x10281000, and when the first command buffer is submitted from userspace, the wait gets replaced by a link to that. |
| 17:05 | _rmk_ | but... where's the link gone - which should be where those AAAAAAAA AAAAAAAA are. |
| 17:12 | _rmk | 17:12 * _rmk_ re-provokes the bug |
| 17:28 | _rmk_ | err, this is not good. |
| 17:28 | _rmk_ | gckCOMMAND_Start: command queue is at 0xe7846000 |
| 17:28 | _rmk_ | gckCOMMAND_Start: WL 380000c8 0cf6d19f 40000002 10281000 |
| 17:29 | _rmk_ | that's what the first 4 words should've been at the beginning (and where when the GPU was started) |
| 17:29 | _rmk_ | they then conveniently become: 4000002C 19CE0000 AAAAAAAA AAAAAAAA |
| 17:29 | _rmk_ | the first two change because of the wait being converted to a link |
| 17:29 | _rmk_ | the second two... |
| 17:30 | _rmk_ | well, 0xaaaaaaaa is the free page poisoning. |
| 17:30 | _rmk_ | which suggests that the GPU command page was freed while still in use |
| 17:46 | _rmk_ | ah ha, that'll be how. get lucky with the cache behaviour and this is what happens... |
| 17:47 | _rmk_ | page poisoning enabled. When a lowmem page is allocated, it's memset() through its lowmem mapping, which is cacheable. |
| 17:47 | _rmk_ | this data can sit in the CPU cache. |
| 17:47 | _rmk_ | it is then ioremap()'d (which I've been dead against for years) which creates a *device* mapping. |
| 17:47 | _rmk_ | we then write the wait/link through the device mapping. |
| 17:48 | _rmk_ | at some point later, the cache lines get evicted from the _normal memory_ mapping. |
| 17:48 | _rmk_ | thereby overwriting the original wait/link commands in the GPU stream with 0xAAAAAAAA |
| 17:49 | _rmk_ | I wonder what that a command word with a bit pattern of 10101 in the top 5 bits tells the GPU to do... |
| 17:55 | _rmk_ | the only thing I can say is... if people would damn well listen to me when I say "don't do this" then you wouldn't get these bugs. |
| 17:56 | _rmk_ | this is one of the reasons why my check in ioremap.c exists to prevent system memory being ioremap'd and therefore this kind of issue cropping up |
| 18:05 | _rmk_ | right, I guess I need to rewrite the galcore memory management |
| 18:07 | _rmk | 18:07 * _rmk_ blames this on this commit: |
| 18:07 | _rmk_ | commit 36ccc654781ffed14f8c671b9f1bc4f53b729b9d |
| 18:07 | _rmk_ | Author: Rabeeh Khoury |
| 18:07 | _rmk_ | Date: Sat Mar 3 14:44:47 2012 +0200 |
| 18:07 | _rmk_ | +#ifndef CONFIG_MACH_CUBOX |
| 18:07 | _rmk_ | if (WARN_ON(pfn_valid(pfn))) |
| 18:07 | _rmk_ | return NULL; |
| 18:07 | _rmk_ | +#endif |
| 18:14 | _rmk_ | the correct fix is _not_ to do that, but to instead fix the code which is calling it to use proper APIs |
| 19:19 | _rmk_ | right, fixed, buy switching to using dma_alloc_coherent, making that use GFP_KERNEL (why was it using GFP_ATOMIC in the first place?) and passing a proper device struct to it. |
| 19:21 | _rmk_ | I'm now going to rip out all the code for NO_DMA_COHERENT = 1 |
| 19:28 | _rmk_ | and now, re-enabling that check in that commit above... |
| 19:34 | _rmk_ | yep, that hack is now no longer required |
| 19:55 | jnettlet | _rmk_, oh so you found a completely different bug. We have been running with NO_DMA_COHERENT = 0 all along. |
| 19:59 | _rmk_ | jnettlet: I'm going to try committing (without a flush) after each operation again - last time I tried this, things went pair shaped pretty quickly |
| 20:00 | _rmk_ | probably due to the races in the event code |
| 20:02 | jnettlet | That is the ideal situation. As long as you don't fill up the command event queue's. Unfortunately you can only tweak their size at compile time. |
| 20:02 | jnettlet | which using X's less than efficient drawing mechanisms can happen pretty quick. |
| 20:05 | dv_ | I am seeing such weird output with the vivante direct textures |
| 20:06 | dv_ | its as if it is only looking at the rightmost texture column and stretching that |
| 20:20 | _rmk_ | jnettlet: seems to be working fine at the moment :) |
| 20:22 | jnettlet | _rmk_, excellent! |
| 20:24 | _rmk_ | almost up to 32k interrupts |
| 20:24 | _rmk_ | side effect from running rhythmbox with its creeping progress bar :) |
| 20:48 | MadCamel | It looks like cubox has cryptoapi support for the SoC's crypto processor.. Anyone use this successfully? How fast is it with dm-crypt? |
| 20:51 | MadCamel | I'm just interested in setting one up as a really customized nas, hoping to get decent-ish performance with low power. Every other arm based solution I've messed with had no/broken cryptoapi support so I'm leery of shelling out more bucks. |
| 21:09 | jnettlet | MadCamel, I think there is a thread on it in the forums |
| 21:11 | MadCamel | kthx |
| 21:32 | dv_ | yay! found the bug. direct textures work now, and show me 1080p in GLES with 6% CPU usage |
| 21:32 | dv_ | two things concern me though: first, I see this in top: 39% [galcore daemon ] |
| 21:33 | dv_ | second, I see this in dmesg, repeated many times over: !!!!!!!!!!!!! AXI BUS ERROR !!!!!!!!!!!!! |
| 21:33 | dv_ | wumpus? any idea what that is? |
| 21:53 | wumpus | that is shown when the GPU asserts an axi bus error notification |
| 21:53 | wumpus | no idea what causes an axi bus error though |
| 21:59 | dv_ | it happens every time I render something with GLES |
| 22:00 | dv_ | and, the galcore daemon CPU usage, is this to be expected? ever seen the galcore daemon CPU usage? |
| 22:16 | wumpus | in general the kernel driver shouldn't use a lot of CPU |
| 22:16 | wumpus | sounds like some hardware/clock issue if you get AXI bus errors all the time |
| 22:17 | wumpus | maybe it's getting extremely large amounts of interrupts |
| 22:17 | dv_ | would explain the CPU usgae |
| 22:17 | dv_ | *usage |
| 22:18 | dv_ | I'll update meta-fsl-arm . with any luck, this was fixed already. |
| 22:21 | dv_ | otavio: uh oh, DEFAULTTUNE_mx6 ?= "cortexa9hf-neon" in the machine config won't make OE-core guys happy :) |