| 23:59 | jnettlet | http://fpaste.org/42297/13801463/ |
| 23:59 | jnettlet | that is against v4. But they are relatively close. |
| 00:02 | jnettlet | rabeeh couldn't sleep |
| 00:06 | jnettlet | but you are right there are things that should be signals that are uninterruptible like Creating a Queue. |
| 00:07 | jnettlet | A command stall should definitely be interruptible. |
| 00:08 | _rmk_ | yes, but only if there's a way that userspace can restart it |
| 00:14 | jnettlet | _rmk_, userspace can just call gckCOMMAND_Execute again |
| 00:16 | _rmk_ | isn't that call buried in the userspace libs? |
| 00:20 | jnettlet | mmmm kind of |
| 00:20 | jnettlet | okay yes it is |
| 00:31 | _rmk_ | btw... Linus applied my patch to the tda998x driver |
| 00:32 | jnettlet | Aren't you winning all the battles today? |
| 00:32 | _rmk_ | technically, that happened yesterday :) |
| 00:32 | _rmk_ | http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/i2c/tda998x_drv.c?id=db6aaf4d55f95dcb6b162c3a59b56eb1e85ccdfe |
| 00:36 | jnettlet | calling gcoHAL_Commit again will resubmit the current command buffer to hardware again. |
| 00:37 | _rmk_ | hmm, that sounds like a problem though... lets say the first gcoHAL_Commit submitted this command buffer, and we got to wait. |
| 00:37 | _rmk_ | if we're waiting, the command buffer has already been given to the GPU. |
| 00:37 | _rmk_ | now, if we get a signal, we drop out of the wait returning interrupted status. |
| 00:38 | _rmk_ | so if userspace re-calls gcoHAL_Commit on the same command buffer which the GPU is already using... |
| 00:38 | _rmk_ | the kernel driver will at least modify the LINK command at the very end |
| 00:39 | _rmk_ | sounds like a recipe for the gpu to end up getting confused |
| 00:47 | jnettlet | _rmk_, you are right. in gckCOMMAND_Start we want to be able to catch interrupted commands and only re-execute them. |
| 01:01 | jnettle | 01:01 * jnettlet calling it a night. Lots of fun as always. |
| 01:01 | _rmk_ | night :) |
| 01:01 | _rmk_ | sorry if I've given you a new problem to solve |
| 01:07 | jnettlet | most these problems sort themselves out in my subliminal while I sleep. I will probably be up in a couple of hours with a solution :-) |
| 01:07 | jnettlet | night |
| 01:51 | MikeSeth | yarr, ordering a cubox-i tomorrow |
| 01:51 | _rmk | 01:51 * _rmk_ thought talk-like-a-pirate day was over :p |
| 02:21 | dbsx | Debian jessie, be warned that udev version 204 seems to stop my cubox from booting. Will post back when I figure out how to recover |
| 10:57 | ralix | morning |
| 11:15 | jnettlet | ralix, morning |
| 11:16 | ralix | morning jnettlet :) |
| 11:17 | jnettlet | well almost afternoon actually |
| 11:17 | jnettlet | switched from coffee to tea. |
| 11:21 | ralix | Here it is 11:20 in the morning, I drink a cup of coffee... |
| 11:22 | jnettlet | 11:20 here also. My day starts at 5:30 so I have already had enough coffee :-) |
| 11:23 | ralix | my day 8:00... Where do you work? I was in Germany (Potsdam) |
| 11:24 | jnettlet | Denmark (Aarhus) |
| 11:24 | jnettlet | U.S. expatriate |
| 11:25 | ralix | Ui nice... Since it is certainly just as cold as ours, but just under 10 days then I got it warm again. |
| 11:26 | jnettlet | we are hovering around 10c right now. Getting almost to 0 at night |
| 11:28 | ralix | its very cold! |
| 11:29 | jnettlet | I grew up in Upstate NY, that is nothing :-) |
| 11:33 | ralix | I was 3 days in New York in June: rain 2 days one really sunny :) Next week Monday we go to jakarta there are like 30 + � C. It |
| 11:33 | jnettlet | Jakarta sounds nice. |
| 11:34 | _rmk_ | did your dreams reveal any magic solutions? :) |
| 11:35 | ralix | Especially beautiful the city is not, but it's always warm ... Indonesia, I can only recommend as are so many great places ... |
| 11:35 | _rmk_ | we've 16?C here at the moment, forecasted to 19?C |
| 11:36 | jnettlet | _rmk_, a few things. Not all related to the problem. |
| 11:38 | jnettlet | 1) All the work wumpus has done on etnaviv should get drm IOCTL's and become a basis for an replacement galcore driver. He has really done all the hard work and just needs GEM for memory management and then to pull in the Hardware commands. |
| 11:39 | jnettlet | 2) Then drm_armada, and drm_etnaviv can use dmabuf to share buffers just the way they are doing it for the Intel/Nvidia architecture. |
| 11:40 | jnettlet | 3) more relevant to the issue at hand. We either need a better in kernel command submission state tracker, or we need to force all Waits to be NonInterruptible |
| 11:43 | wumpus | jnettlet: +1 |
| 11:45 | wumpus | what really needs to be done is to add buffer management support to the etnaviv user space, and the kernel driver |
| 11:46 | wumpus | so that the extensions that pass buffers between processes can work |
| 11:46 | wumpus | and so that it can render to KMS instead of fbdev |
| 11:47 | wumpus | btw my cubox-i should be coming this morning |
| 11:47 | jnettlet | excellent. |
| 11:47 | _rmk_ | that's where drm prime comes in |
| 11:47 | jnettlet | right |
| 11:48 | _rmk | 11:48 * _rmk_ wonders who will get the first recent mx6 kernel running on the cubox-i |
| 11:48 | _rmk_ | are we yet at the point where writing a DT description will work |
| 11:49 | jnettlet | for the cubox-i? |
| 11:49 | _rmk_ | yea |
| 11:50 | jnettlet | I thought I already saw one somewhere when I was poking around the web last week. |
| 11:53 | jnettlet | there are the basic imx6q bits. Should be trivial to add Cubox-i support |
| 11:57 | jnettlet | _rmk_, as far as the answer. Command->running needs to become Command->state and should be able to be running, stopped, interrupted. Then in gckCOMMAND_Start we can abort if running, skip the Link command if interrupted. |
| 11:57 | _rmk_ | jnettlet: an alternative would be to dump this and switch to etnaviv :) |
| 11:58 | jnettlet | _rmk_, well that seems like a better alternative. |
| 12:00 | _rmk_ | maybe I should pull etnaviv into my kernel and X driver, and start giving it a bashing :) |
| 12:00 | jnettlet | right now etnaviv just talks to galcore. |
| 12:01 | _rmk_ | its just a replacement userspace? |
| 12:01 | jnettlet | and mesa driver |
| 12:03 | wumpus | yes, its a replacement userspace |
| 12:03 | wumpus | it can work with various kernel interfaces |
| 12:04 | wumpus | which are all Vivante GPL drivers at the moment, but at some point it'd be nice to have a better kernel driver too =) |
| 12:04 | rabeeh | all: fixed a bug in LVDS driver registration - |
| 12:04 | rabeeh | http://download.solid-run.com/pub/solidrun/c1/kernel/initial/ |
| 12:04 | rabeeh | third patch |
| 12:04 | rabeeh | otherwise HDMI won't work |
| 12:07 | _rmk_ | ok, so effort required to sort out the kernel side. |
| 12:08 | _rmk_ | jnettlet: btw, one thing I really hate about the vivante kernel side is the way they insist on using their OS abstractions in OS specific code |
| 12:08 | jnettlet | I hate their OS abstraction period |
| 12:09 | _rmk_ | they'll use get_free_pages() for instance, but won't use NULL in the same file |
| 12:09 | _rmk_ | they have to use gcvNULL and pass that into kernel functions and check return values |
| 12:10 | _rmk_ | I suspect their programmers are only allowed to write code using their stupid abstractions |
| 12:12 | _rmk_ | rabeeh: which kernel are these against? |
| 12:12 | rabeeh | 3.0.35 + BSP 4.1.0 |
| 12:13 | rabeeh | http://imx.solid-run.com/wiki/index.php?title=Building_Carrier-One_U-boot_and_Kernel |
| 12:16 | _rmk_ | next obvious question is... has anyone yet put the cubox-i into a RPi case yet |
| 12:16 | jnettle | 12:16 * jnettlet doesn't have any RPi's or cases. |
| 12:16 | _rmk_ | or even lego :) |
| 12:16 | _rmk_ | me neither |
| 12:17 | jnettle | 12:17 * jnettlet living in Denmark should probably go the Lego route |
| 12:17 | rabeeh | almost fits |
| 12:17 | _rmk_ | I asked someone with some RPis, and he thinks the only problem would be the audio jack |
| 12:17 | _rmk_ | analogue audio jack |
| 12:17 | rabeeh | in what means? |
| 12:18 | jnettlet | probably nothing that a dremel couldn't fix |
| 12:18 | _rmk_ | he thinks it won't line up with any holes |
| 12:18 | _rmk_ | jnettlet: my thoughts exactly :) |
| 12:18 | rabeeh | it's the same size and height |
| 12:18 | jnettlet | these are the days I wish I had a 3d printer |
| 12:18 | rabeeh | it looks different since it's 4 poles instead of 3 (for the microphone-in when using the codec) |
| 12:19 | rabeeh | the only problem is the RJ45 connector we use now since it's slightly taller (about 1mm) than the pi |
| 12:20 | jnettlet | this one looks pretty close. http://www.amazon.co.uk/Stealth-Black-Case-For-Raspberry/dp/B0099PR98I/ref=sr_1_3?ie=UTF8&qid=1380190747&sr=8-3&keywords=raspberry+pi+case |
| 12:20 | _rmk_ | rabeeh: great. I may put mine in a RPi case then |
| 12:20 | rabeeh | :) |
| 12:21 | rabeeh | that's the whole intent; to reuse as much as possible accessories; otherwise we would have to build things from scratch |
| 12:21 | rabeeh | i think the pi is becoming like an ATX standard :) |
| 12:21 | jnettlet | I agree that is a worthy investment. although need to figure out what to do about IR |
| 12:21 | rabeeh | for clear cases it should work |
| 12:21 | _rmk_ | jnettlet: another job for the dremel? :) |
| 12:22 | jnettle | 12:22 * jnettlet is wondering if one of the transparent cases wouldn't be a better idea. |
| 12:23 | _rmk_ | that would be the easiest solution |
| 12:23 | _rmk_ | you'd also be able to see the LEDs too |
| 12:23 | jnettlet | oh my. http://www.amazon.co.uk/RASPBERRY-MICRO-COMPUTER-ACRYLIC-PRIMARY-ACCESSIBLE/dp/B00AQU4QRM/ref=sr_1_7?ie=UTF8&qid=1380190909&sr=8-7&keywords=raspberry+pi+case |
| 12:23 | jnettlet | although that would needs some dremelling for the SOC |
| 12:24 | jnettlet | clear ones are the cheapest. Curse you _rmk_ I don't need these distractions :-) |
| 12:24 | _rmk_ | lol |
| 12:27 | rabeeh | haha |
| 12:32 | wumpus | _rmk_: we're working on cleaning up and stripping down the (v4) kernel driver for gcwzero, but it should work for imx6 too, I guess with minor changes |
| 12:33 | wumpus | we got at least the user space interface headers down to one header, and removed thousands of lines of fluff |
| 12:34 | _rmk_ | I'd rather dump the galcore kernel API and start afresh. |
| 12:34 | wumpus | oh sure, but this is a way of learning how it works |
| 12:34 | wumpus | by not losing continuity we keep a working userspace+kernel at all time |
| 12:35 | wumpus | a stripped down kernel driver is much easier to read too |
| 12:35 | wumpus | even if you start afresh afterwards |
| 12:35 | wumpus | btw, robclark has/had plans in that direction too |
| 12:36 | rabeeh | robclark? |
| 12:37 | jnettlet | TI guy |
| 12:37 | wumpus | the freedreno developer |
| 12:37 | jnettlet | or was |
| 12:37 | jnettlet | freedreno uses vivante? |
| 12:37 | wumpus | he's working at redhat at open source gpu drivers, he expressed some interest in imx6/vivante at some time, maybe as next project |
| 12:37 | wumpus | jnettlet: nope, they're completely different |
| 12:38 | jnettlet | wumpus, ah okay |
| 12:38 | jnettlet | I thought The redhat version had an "e" at the end...most likely my mistake |
| 12:39 | jnettlet | Has anyone seen or used any Vivante hardware that uses the VG engine? |
| 12:41 | wumpus | jnettlet: yes, imx6 quad has a VG engine |
| 12:41 | wumpus | GC320 or so |
| 12:41 | wumpus | no, GC355 |
| 12:42 | jnettlet | wumpus, it is the same Rob Clark. He went from TI -> Linaro -> RedHat |
| 12:42 | _rmk_ | so he didn't spend much time with Linaro then? |
| 12:42 | wumpus | right, never knew that |
| 12:43 | jnettlet | He was just there for a project. Might have been the ramp up they did for the Chromebook |
| 12:43 | wumpus | jnettlet: from the (public) presentation of vivante on the subject the VG engine has a slightly higher fillrate than the 3D engine for straightforward fills, and somewhat lower power usage |
| 12:44 | jnettlet | If that is all you are doing. |
| 12:45 | wumpus | and it has tesselation support and some more blending operations than the 3D core IIRC, but I've never studied it in detail |
| 12:45 | wumpus | the register interface is completely different, so an open source driver for that will be lots of work probably |
| 12:47 | jnettlet | I don't think it is that interesting right now. 2D and 3D are way more useful to the OSS community. |
| 12:48 | wumpus | yes, I judged the same way |
| 12:53 | wumpus | in any case, mesa should be able to do openvg with the 3d engine (never tested that yet though) |
| 12:53 | jnettlet | that is actually an option in the kernel as well. |
| 13:23 | jnettlet | rabeeh, does tftboot from uboot work? |
| 13:23 | rabeeh | nop |
| 13:23 | rabeeh | ethernet is still not supported in u-boot |
| 13:23 | rabeeh | work in progress thing |
| 13:45 | jnettlet | _rmk_, wumpus, so what are our next steps. It seems like we are on the cusp of the "right" next move. |
| 13:46 | _rmk_ | jnettlet: I suspect I might grab etnaviv and start work on the kernel DRM side of that |
| 13:47 | _rmk_ | having crawled all over the kernel vivante driver, I've got a fairly good understanding of it |
| 13:47 | _rmk_ | and all its bugs :) |
| 13:48 | dbsx | An old (v2) cubox question: I can no longer boot a debian system as they seem to have screwed udev. Any tips for debugging udev at boot? |
| 13:48 | _rmk_ | and modelling someing off the vivante event code is probably the wrong solution because its the biggest can of races going |
| 13:48 | _rmk_ | s/someing/something/ |
| 13:49 | _rmk_ | _IsEmpty, _GetEvent, gckEVENT_Submit and gckEVENT_Notify are all racy |
| 13:49 | wumpus | jnettlet: well I still need to implement context support for v4, you know the STATE_DELTA crap... either that or we think of something compeltely new to share the GPU between processes |
| 13:49 | _rmk_ | dbsx: I looked at my ubuntu, and it seemed to be an older version of udev |
| 13:50 | wumpus | I think the state_delta stuff is racy as hell too |
| 13:50 | _rmk_ | dbsx: udev is particularly nasty to debug because you need it to setup the devices so you have a console |
| 13:51 | wumpus | haven't fully figured out how it's supposed to work and keep the context up to date, it stashes pointers and pulls some buffers from user space later |
| 13:51 | dbsx | _rmk_: So is the best thing to try and downgrade my debian version 175, I know to be ok |
| 13:51 | jnettlet | _rmk_, I think most the event code can be fixed by implementing a proper fence |
| 13:51 | _rmk_ | dbsx: my best suggestion would be to enable devtmpfs and have it auto-mount with the rootfs, then you might be able to boot again |
| 13:52 | _rmk_ | jnettlet: not really, because some of the events are used to determine when the previous command buffer has been completed, and so can be re-used... which is why things explode if you try too many operations |
| 13:52 | wumpus | in v2 it was easy, the context was just a command buffer that set up the state to what the application is expected, and was executed when context switching before executing the other application's command buffer |
| 13:52 | wumpus | _rmk_: yes, I've had a few explosions too :-) |
| 13:53 | wumpus | it runs out of signals and things start going bad |
| 13:53 | _rmk_ | and if a previous command buffer gets re-used before the GPU has finished with it, expect random memory corruption, even fs corruption. |
| 13:53 | jnettlet | yep |
| 13:54 | _rmk_ | wumpus: you mean the "event X is not pending" stuff? |
| 13:54 | wumpus | I never reuse command buffers that the GPU is not finished with |
| 13:54 | _rmk_ | galcore internally does - it allocates two command buffers and toggles between them |
| 13:54 | wumpus | the idea is to keep a signal per command buffer, queue the signal at the end, and only reuse the command buffer when the signal is raised |
| 13:55 | wumpus | so when the userspace queues too many commands it'll just wait at a certain point for the gpu to finish with the next command buffer |
| 13:56 | wumpus | IIRC the blob does a similar thing |
| 13:56 | _rmk_ | if you ever see the kernel galcore complain about a lost event or an event not pending, that's because the kernel driver raced |
| 13:56 | wumpus | yes, I've had those races, especially on cubox |
| 13:56 | _rmk_ | and its caused by three races |
| 13:56 | wumpus | even when using it only from one process :D |
| 13:56 | _rmk_ | one in _GetEvent, where it finds an event slot under a lock but has no way to mark it as having been allocated |
| 13:57 | _rmk_ | one in gckEVENT_Submit, where you can end up with two events being allocated and then inserted in the reverse order to allocation |
| 13:57 | wumpus | ugh |
| 13:57 | _rmk_ | and one in gckEVENT_Notify, where the processing of pending events can screw it up (I need to write that one up properly in the commit) |
| 13:58 | wumpus | I guess some more correct and linuxy synchronization should be used, not some leaky abstractions |
| 13:58 | _rmk_ | the final one - _IsEmpty - can work both ways. This function can report that the event queues are empty when they aren't, and they aren't empty when they are. |
| 13:59 | _rmk_ | one of the issues with gckEVENT_Submit() is its recursive though! |
| 13:59 | _rmk_ | in trying to add the event command into the command queue, it can trigger the allocation of a new queue, and guess what that does... |
| 14:00 | wumpus | yes, I've seen that, makes the traces very hard to erad |
| 14:00 | _rmk_ | find the nearest wall, apply head :p |
| 14:00 | _rmk_ | right, lunch time |
| 14:01 | wumpus | I have no idea what kind of synchronization mechanism nouveau/radeon uses, but maybe it's something to learn from |
| 14:01 | jnettlet | I think ring buffers and fences to sync to. |
| 14:02 | jnettlet | If you try to allocate a command and there isn't enough space then you just flush the buffer to the next fence point. |
| 14:02 | jnettlet | at least last time I worked on any of that. |
| 14:03 | wumpus | ok, makes sense |
| 14:04 | wumpus | I currently implement the gallium fences using galcore signals, they look pretty similar |
| 14:08 | wumpus | though it's indeed unecessary that they're reusable, and have this reset/no-auto-reset flag |
| 14:19 | _rmk_ | oh yes, that's the gckEVENT_Notify race - it scans the event queues/lists without holding any locks - it was coded with the assumption that the only thing you need to protect against is writes to queue->head and apparantly reads are fine. |
| 14:22 | _rmk_ | the problem that leads to is that you can end up with queue->head non-NULL, queue->stamp being old, and then gckEVENT_Notify() identifies it as a missed event when in actual fact the event queue is in the middle of being setup |
| 14:22 | _rmk_ | ... and NULLs out queue->head and runs all the queued events |
| 14:23 | _rmk_ | since I've fixed all these, I'm seriously considering getting rid of my fencing in my Xorg driver... it's just not needed anymore |
| 14:26 | wumpus | the way you make it sound it's really horribly broken :) |
| 14:26 | _rmk_ | it _is_ horribly broken |
| 14:27 | _rmk_ | these races basically make the event stuff completely unreliable |
| 14:27 | wumpus | not only unreliable, dangerous |
| 14:28 | wumpus | I guess that's why dv_ experiences kernel hangs all the time |
| 14:28 | _rmk_ | its one of the reasons my ext4 fs on it now spits this out: |
| 14:28 | _rmk_ | EXT4-fs (sda2): error count: 14 |
| 14:28 | _rmk_ | EXT4-fs (sda2): initial error at 1369503707: ext4_iget:4125: inode 415617: block 1365403246 |
| 14:28 | _rmk_ | EXT4-fs (sda2): last error at 1369503708: ext4_iget:4158: inode 417719 |
| 14:28 | wumpus | eek... |
| 14:28 | _rmk_ | ext4 permanently remembers that its been messed up - fsck won't clear that out. |
| 14:29 | _rmk_ | the only way around that is to re-mkfs the fs :p |
| 14:30 | wumpus | so you fixed a lot of the problems, but you still want to start from scratch? |
| 14:30 | wumpus | yes the only way to salvage would be to make a new fs and copy the files over, as far as those aren't randomly damanged beyond repair :p |
| 14:32 | _rmk_ | definitely, because otherwise we'll probably end up bringing forward some subtle races. it's easier to get the design right if its thought through first, rather than modifying something that pre-exists |
| 14:33 | _rmk_ | and the recursive mutexes need to die |
| 14:33 | wumpus | that's true; and we want a completely different user space interface anyway |
| 14:33 | wumpus | right |
| 14:34 | jnettlet | _rmk_, if you want to start from scratch. You could dump me your patchset and I can rebase that onto v4. Then we could at least have something more stable to use until a new kernel driver is done. |
| 14:34 | wumpus | yes, it would still be interesting to rebase the work to v4 for the meantime |
| 14:34 | wumpus | depending on how much work it is to design and make a new kernel driver |
| 14:35 | jnettlet | wumpus, not necessarily. your abstraction is pretty decent. You are still building the needed commands they will just be submitted through different IOCTL's |
| 14:35 | jnettlet | and memory allocation can generally be kept the same just adapted to make _GEM requests. |
| 14:35 | wumpus | jnettlet: yep, and after that we can rename libetnaviv to libdrm_etna, and it almost fits in :) |
| 14:36 | jnettlet | exactly |
| 14:40 | _rmk_ | there's a reason why some people should have their computer removed... "ubus still has no acl lists but for security reasons it could be at least be set to 0700, so no user except root can start it" |
| 14:41 | _rmk_ | (quote from another channel) |
| 14:42 | _rmk_ | lets see, if you have perl on the platform, or a myriad of other programming languages, you could still write a script to access its unix domain socket which has world privileges... |
| 14:43 | jnettlet | haha. |
| 14:43 | wumpus | heh |
| 14:44 | jnettlet | error is between the chair and the keyboard |
| 15:21 | _rmk_ | shesselba: I don't think JF's problem is that the external clock isn't stable... no interrupts probably means either no external clock running or the audio block isn't being enabled |
| 15:22 | _rmk_ | shesselba: this is where having a working devmem2 and poking at the control register would be useful |
| 16:15 | jnettle | 16:15 * jnettlet pulled the trigger and went with a transparent green case. |
| 16:16 | _rmk_ | green case with red LEDs... hmm. |
| 16:24 | jnettlet | http://www.amazon.co.uk/gp/product/B00AO5NR6K/ref=s9_simh_gw_p147_d0_i2?pf_rd_m=A3P5ROKL5A1OLE&pf_rd_s=center-2&pf_rd_r=1AXW5DKT6FY1QK8AWNNH&pf_rd_t=101&pf_rd_p=418450947&pf_rd_i=468294 |
| 16:24 | jnettlet | I think it is transparent enough to pass IR |
| 16:25 | jnettlet | will probably need to dremel the USB flange a bit. |
| 16:28 | jnettlet | _rmk_, you should look here. https://www.modmypi.com/raspberry-pi-case-clear-green |
| 16:28 | jnettlet | mix and match cases |
| 16:33 | _rmk_ | jnettlet: I think I'd go for the blue... http://www.amazon.co.uk/Transparent-Enclosure-Raspberry-Model-Cable/dp/B00D1D4RAM/ref=sr_1_6?s=computers&ie=UTF8&qid=1380205949&sr=1-6&keywords=raspberry+pi+case+blue or maybe http://www.amazon.co.uk/PCSL-Adafruit-Midnight-Blue-Manufactured/dp/B009D4YW5I/ref=sr_1_3?s=computers&ie=UTF8&qid=1380206020&sr=1-3&keywords=raspberry+pi+case+blue |
| 16:34 | jnettlet | I saw the adafruit one. It is very tempting. |
| 16:35 | _rmk_ | I saw some of the reviews complaining about lack of instructions and another review complaining about those complaining about the lack of instructions :) |
| 16:37 | jnettle | 16:37 * jnettlet has realized that without accountability and reward online review systems are useless. |
| 16:38 | jnettlet | Amazon would be smart to offer credit to people that post reviews and get X number of "This was helpful" votes. |
| 16:39 | jnettle | 16:39 * jnettlet likes this response. "Some claim that it's fragile. I wouldn't recommend using a hammer to assemble it" |
| 16:41 | jnettlet | hmmm my custom uboot is ubooting. must have broken something. |
| 16:41 | _rmk_ | yes :) |
| 17:03 | jnettlet | rabeeh, should probably get him some of these. https://www.modmypi.com/multi-pi-stackable-raspberry-pi-case |
| 17:03 | jnettlet | stack his test boards all the way to the ceiling. |
| 17:04 | _rmk_ | hmm, looks like gckHARDWARE_QueryIdle() is buggy |
| 17:04 | _rmk_ | gcmkONERROR(gckOS_ReadRegister(Hardware->os, 0x00004, &idle)); |
| 17:04 | _rmk_ | if( (idle & 0x7FFFFFFE) != 0x7FFFFFFE ) { |
| 17:04 | _rmk_ | /* Something is busy. */ |
| 17:05 | _rmk_ | *IsIdle = gcvFALSE; |
| 17:05 | _rmk_ | what does mine report for idle... |
| 17:05 | _rmk_ | root@cubox:~# ./devmem2 0xf1840004 |
| 17:05 | _rmk_ | Value at address 0xF1840004 (0xb6f7c004): 0xFE |
| 17:23 | jnettlet | _rmk_, you are correct. if you do bitwise operations on idle it never evaluates properly. I ended up just testing (idle == 0x7FFFFFE) to see if the hardwaare was idle. |
| 17:36 | gimli | Hardware : Freescale i.MX 6Quad/DualLite/Solo Sabre-SD Board |
| 17:36 | gimli | nice |
| 17:37 | wumpus | _rmk_: it differs per chip, some report non-exstent modules as 0 (busy) in the idle register, others report non-existing modules as 1 (idle) |
| 17:37 | wumpus | in any case, yes it seems to be a bug |
| 17:38 | _rmk_ | wumpus: something to be fixed then :) |
| 17:38 | _rmk_ | do we have any ideas about which bits are present on which devices? |
| 17:39 | wumpus | no.. looks like a hardware bug even |
| 17:39 | wumpus | it should report non-existent ones as 1 |
| 17:39 | wumpus | otherwise the driver needs to have knowledge about this :/ |
| 17:40 | wumpus | this is on cubox? |
| 17:41 | wumpus | I don't think this is right, are you sure nothing goes wrong while reading the register? |
| 17:42 | wumpus | let me check... |
| 17:42 | _rmk_ | yep on the cubox |
| 17:43 | _rmk_ | I've never seen it have anything above bit 7 set |
| 17:44 | wumpus | you're right |
| 17:44 | _rmk_ | bah. the problem of modern TVs with their shiney screens is that a camera sees more reflection than image on it. |
| 17:44 | jnettlet | no flash |
| 17:44 | _rmk_ | even with no flash |
| 17:44 | cbxbiker61 | interesting, i see a new patch on the linux mailing list for i.MX6Q/DL for SD3.0, so maybe the cubox-i will properly support UHS-I. |
| 17:44 | wumpus | at least on gc860 this is fixed |
| 17:44 | _rmk_ | I'd need to be in a completely dark room to photograph it |
| 17:44 | jnettlet | cbxbiker61, it is supposed to. |
| 17:45 | cbxbiker61 | that's cool |
| 17:45 | wumpus | but on cubox gc600 it only sets the lower 8 bits (and probably the upper bit, for axi low power mode) |
| 17:46 | wumpus | it doesn't have the modules above that either (VG, IM, FP, TS), but now the driver needs knowledge of that which is sucky :/ |
| 17:46 | wumpus | a workaround could be to query the idle register at initialization |
| 17:47 | wumpus | as it's a reasonable assumption that's the idle state |
| 17:47 | wumpus | either that or you need a model-specific workaround |
| 17:48 | jnettlet | or we could keep track of what hardware supported what features and only queried those bits. |
| 17:48 | wumpus | but where's the cutoff point, when did they fix it.... |
| 17:49 | wumpus | I know it's fixed on gc860, and likely gc880, gc2000... I could check on gc800 when I dig up my old tablet |
| 17:50 | wumpus | jnettlet: well all the newer hardware returns 1 for everything that's not present, so keeping track on bit granularity seems overkill |
| 17:55 | _rmk_ | we just need to track what's prior to the hardware fix |
| 17:59 | _rmk_ | and it should just be as simple as having a mask which identifies which bits must be ones for idle |
| 18:00 | _rmk_ | the driver already knows which GC* chip it has |
| 18:00 | wumpus | yes -- my guess is that the problem only exists for gc600 and earlier |
| 18:00 | wumpus | then again, 'earlier' is hard to determine sometimes, the names are not entirely chronological |
| 18:01 | jnettlet | then just change the idle mask if the chip is newer than GC600 |
| 18:01 | wumpus | there is also the revision... |
| 18:03 | jnettlet | maybe it is easiest to get the mask on init |
| 18:03 | wumpus | remember that the 2d cores always have lower numbers , so do the vg cores (gc35x) |
| 18:03 | _rmk_ | well, we know that the GC600 doesn't and the GC800 does, so as we find others... |
| 18:03 | wumpus | so you can't just compare the model number |
| 18:03 | wumpus | for now, let's say only gc600 has the problem |
| 18:03 | wumpus | that's easy :) |
| 18:03 | _rmk_ | quite :) |
| 18:03 | _rmk_ | easy and simple == good :) |
| 18:04 | wumpus | yep, when we find another chip with the problem ,we add another exception |
| 18:04 | jnettle | 18:04 * jnettlet thought he had a board that only had a 2d core in it....maybe it was that chumby box |
| 18:05 | wumpus | ingenic jz4760 has only a 2d core, and Marvell 88SV331x |
| 18:06 | wumpus | neither of both I have though :) |
| 18:07 | jnettle | 18:07 * jnettlet shrugs. Not the chumby that is just a Marvell chip. No Vivante on it |
| 18:26 | _rmk_ | hmm |
| 18:26 | _rmk_ | DT_MACHINE_START(IMX6SL, "Freescale i.MX6 SoloLite (Device Tree)") |
| 18:51 | MikeSeth | yay, ordered a cubox-i just now |
| 19:04 | jnettlet | congrats |
| 19:44 | _rmk_ | well, trying to boot 3.12-rc2 with a minimal DT doesn't seem to work |
| 19:47 | jnettlet | How far does it get? |
| 19:47 | _rmk_ | dies immediately after Starting kernel ... |
| 19:50 | _rmk_ | rabeeh: the UART port we're using for serial console is at 0x02020000 ? |
| 20:05 | _rmk_ | bingo |
| 20:05 | _rmk_ | Linux version 3.12.0-rc1+ ([email protected]) (gcc version 4.5.4 (GCC) ) #3 SMP Thu Sep 26 18:45:42 BST 2013 |
| 20:05 | _rmk_ | CPU identified as i.MX6DL, silicon rev 1.1 |
| 20:06 | _rmk_ | Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280) |
| 20:06 | _rmk_ | VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 |
| 20:10 | _rmk_ | hmm |
| 20:19 | dv_ | _rmk_: nice find (the data race) |
| 20:20 | dv_ | btw. I got the OK from management to release & upstream my VPU chromium patch (-> html5 video using the VPU) |
| 20:21 | dv_ | its still not perfect, since the chromium codebase copies frames around, but its much better than decoding in sw.. |
| 20:22 | dv_ | also, perhaps there is a way to use the vivante textures with chromium if GLES is used for drawing the 2d contents. its more complex though. i'm still trying to find out how exactly I add this to chromium. |
| 20:25 | _rmk_ | looks like that boot was a fluke |
| 20:28 | _rmk_ | got it |
| 20:37 | _rmk_ | rabeeh should really fix the instructions |
| 20:38 | _rmk_ | not /dev/sdX but /dev/mmcblkX |
| 20:38 | _rmk_ | otherwise he may have people overwriting the SATA disks |
| 20:51 | dv_ | _rmk_: the race condition you found is interesting for our project |
| 20:51 | dv_ | but from what I've read, this is not done by a simple patch |
| 20:52 | ojn | Wife says "package from Israel just arrived", which should mean my cubox-i is waiting for me at home. |
| 20:56 | _rmk_ | dv_: "not done by a simple patch" ? you mean, not trivial to fix? |
| 20:56 | dv_ | yes |
| 20:56 | dv_ | more specifically, not doable without a rewrite |
| 20:56 | _rmk_ | wait a moment... |
| 20:57 | dv_ | we have seen numerous crashes with chromium 29 when using GLES for rendering 2d |
| 20:57 | dv_ | kernel crashes |
| 20:58 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/races/ |
| 20:58 | _rmk_ | have the fixes for those four races plus a couple of others. |
| 20:58 | _rmk_ | may not apply cleanly tho |
| 20:58 | _rmk_ | couple of other fixes from my series included too :) |
| 20:58 | dv_ | oh. missed this line: so you fixed a lot of the problems, but you still want to start from scratch? |
| 20:58 | dv_ | nice! thanks |
| 20:59 | _rmk_ | I have 81 patches against galcore :( |
| 20:59 | _rmk_ | I used to have 97 but I cleaned up a number and reshuffled them |
| 20:59 | dv_ | its that buggy? |
| 21:00 | _rmk_ | not all are fixes, some are cleanups |
| 21:00 | _rmk_ | for example, I got rid of all the __QNXNTO__ stuff |
| 21:14 | jnettlet | I will pull those patches into a v4 kernel driver and fix that last race we talked about last night. |
| 21:15 | jnettlet | That should get us to stable testing for all the devices and give us something consistent to compare to moving forward with better drivers. |
| 21:16 | jnettle | 21:16 * jnettlet is closer to getting ethernet working on uboot. Must have tftboot for kernel dev. |
| 21:16 | _rmk_ | absolutely, that'll make this job of getting 3.12-rc1 much easier |
| 21:16 | _rmk_ | I'm trying to work out what's required in DT for ethernet, particularly the pinmux settnigs |
| 21:34 | _rmk | 21:34 * _rmk_ waits for git fetch to crunch on freescale's git server |
| 21:54 | jnettlet | _rmk_, while you are waiting for git do you have a patch for your vmeta char driver? If not I will just keep the uio driver for dv_ to test against. |
| 21:56 | _rmk_ | the easiest thing for me to do is going to be to diff between v3.11 and the tip of my tree for that, which'll give me one big diff for vmeta and bmm |
| 21:58 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/bmm-vmeta.diff |
| 21:58 | _rmk_ | there's probably a few bits in arch/arm which are also required |
| 21:58 | jnettlet | I can roll with that. Then I will add bmm support to libphycontmem and we can have one library to support all the current memory allocation frameworks supported by vmeta. |
| 21:59 | _rmk_ | basically, pass the bmm reserved memory as a memory resource in the platform device |
| 22:00 | _rmk_ | vmeta device wants the phys base and irq of course, and a 32-bit DMA mask setup |
| 22:00 | _rmk_ | vmeta still uses the old "ap510-vmeta" name |
| 22:00 | jnettlet | okay |
| 22:01 | _rmk_ | then you'll want my libvmeta.git for userspace |
| 22:01 | _rmk_ | optionally the libbmm.git too |
| 22:01 | jnettlet | yeah I will need to merge that with mine. |
| 22:01 | _rmk_ | I may need to push updates out for those tho. |
| 22:01 | jnettlet | and I will merge your libbbm with libphycontmem as another backend. |
| 22:02 | _rmk_ | vmeta is up to date |
| 22:02 | _rmk_ | its just libbmm which isn't |
| 22:03 | _rmk_ | nope, libbmm is also up to date |
| 22:03 | jnettlet | great. |
| 22:03 | _rmk_ | I know something isn't |
| 22:04 | _rmk_ | that's it, libdrm-armada |
| 23:22 | Tenkawa | greetings all |
| 23:22 | Tenkawa | so is there an eta for the cubox-i yet? |