| 01:44 | _rmk_ | whee, I can now just type 'reboot' on the carrier-1 and it'll autoboot now :) |
| 08:33 | jnettlet | rabeeh, when you burnt the fuses did you set the MAC address? |
| 08:41 | jnettlet | looks like no :-) |
| 08:41 | jnettlet | got MAC 0 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 1 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 2 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 3 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 4 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 5 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 6 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 7 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 8 address from fuse: 00:00:00:00:00:00 |
| 08:41 | jnettlet | got MAC 9 address from fuse: 00:00:00:00:00:00 |
| 11:07 | jnettlet | uh oh |
| 11:08 | jnettlet | rabeeh, my board won't power up any longer. Any fuses where I can check the voltage? |
| 11:08 | MikeSeth | ouch |
| 11:09 | MikeSet | 11:09 * MikeSeth wants a dev board to play with |
| 11:11 | jnettle | 11:11 * jnettlet wonders if the new case built up an ESD with the dry air. |
| 11:19 | jnettlet | looks like f201 has blown |
| 11:20 | jnettlet | board still runs |
| 11:28 | _rmk_ | urgh |
| 11:28 | _rmk_ | any idea what F201 does? |
| 11:30 | jnettlet | looks like the fuse on the + side of the usb power connection |
| 11:31 | jnettlet | I would rather replace it, but I may just bypass it temporarily |
| 11:31 | _rmk_ | my guess would be either a weak fuse or maybe doesn't like the inrush current |
| 11:32 | _rmk_ | I've been trying to avoid plugging the power too much on mine |
| 11:33 | jnettlet | like I said. I am a known ESD tester as well. After the 1.5 wifi problem a machine was only considered ESD safe if I could use it for a couple months with no problems. |
| 11:33 | jnettlet | _rmk_, me too. I have been using a reset, but was seeing some oddity and wanted to see if a cold boot had any effect. |
| 11:34 | _rmk_ | jnettlet: it's your electric personality :) |
| 11:34 | jnettlet | yeah, most likely it is the dogs that like to sleep up against the bottom of my metal chair that sits on a plastic anti-scratch mat. |
| 11:35 | jnettlet | I generally tend to stay grounded but.... |
| 11:38 | jnettlet | well something funky is going on with the memory layout regardless. Trying to enable the framebuffer is causing the same hang I was seeing before when the EXTRA_OPTIONS hash was over a certain size. |
| 11:38 | _rmk_ | there are anti-static mats which you can put on the floor and then have a strap around your ankle which grounds you to that mat - slightly less inconvenient than the traditional wrist ground strap |
| 11:39 | _rmk_ | maybe get some for the dogs too :) |
| 11:39 | jnettlet | I actually have metal legs on my desk I have grounded and I put my bare feet on top of them |
| 11:41 | _rmk_ | this might sound perverse and the wrong thing, but ground it via a 1 or 10M resistor rather than a direct connection |
| 11:41 | dbsx | Can you guys be a little more positive? |
| 11:42 | jnettlet | that wouldn't be any pun |
| 11:42 | dbsx | it would be |
| 11:42 | dbsx | I thought is wan't bad |
| 11:43 | _rmk_ | the reasoning is to avoid the sudden static discharges - those wrist straps and workstation mats are always grounded via such a resistor |
| 11:43 | dbsx | wasn't |
| 11:43 | _rmk_ | dbsx: please don't be soo negative |
| 11:43 | dbsx | It is my excess electrons |
| 11:43 | jnettlet | It is probably time to setup a proper ground work area in my new office. |
| 11:43 | dbsx | sorry |
| 11:44 | jnettle | 11:44 * jnettlet has been to static. Time to walk the dogs. |
| 11:45 | _rmk_ | jnettlet: your legs will be alternating for a while |
| 11:46 | jnettlet | dealing with this dead board has really shortened my fuse. |
| 11:47 | dbsx | good see that you both get a charge out of this work |
| 11:47 | jnettlet | until I fix this board I will have to switch to another project |
| 11:48 | jnettlet | okay I am done. |
| 11:48 | _rmk_ | where did you source that one? from the drain? |
| 11:48 | _rmk_ | maybe your collector of jokes was emitting some real bad ones. |
| 11:49 | jnettlet | rabeeh, if you get back and wade through these horrible puns. Let me know what options I have to replace what I think is fuse F201. |
| 11:49 | jnettlet | regardless I will push my u-boot git tree when I get back. |
| 11:49 | _rmk_ | jnettlet: mind the gates :) |
| 11:50 | _rmk_ | though that one might have been base-less |
| 11:52 | _rmk_ | if I can locate the pad connections for the lvds connector, I might have a go at getting some of the imx-drm stuff going |
| 12:29 | dv_ | so. is the goal to unify galcore for armada and imx still current? |
| 12:30 | _rmk_ | that's what I'd want to do |
| 12:31 | dv_ | perhaps something like a wiki for all that would be a good idea |
| 12:31 | dv_ | just to have a todo list stored somewhere for example |
| 12:31 | dv_ | right now, all these things exist only in our heads |
| 12:34 | dv_ | overall, I have noticed how fragmented all these efforts for kernel mainlining, opensource drivers, gstreamer/libav/xbmc support etc. are |
| 12:40 | _rmk_ | well, the galcore stuff isn't something that can be mainlined |
| 12:41 | _rmk_ | as I understand it, etnaviv doesn't have any kernel side at the moment either |
| 12:42 | _rmk_ | I'm in two minds about the galcore stuff: if I do much more, it'll become impossible to rebase onto later versions of vivante's code base |
| 12:43 | _rmk_ | on the other hand, I think I do need to do more to it, pulling cleaned up stuff out of it into a separate library which it (and others) can use |
| 12:43 | _rmk_ | okay, that's the imx_v6_v7_defconfig file updated |
| 12:50 | _rmk | 12:50 * _rmk_ adds the cubox-i-carrier-1 to his nightly builds |
| 12:58 | dv_ | from what I was told, galcore is opensource, but violates all kernel coding conventions |
| 12:58 | dv_ | so it would amount to a rewrite |
| 12:59 | _rmk_ | you know my feelings towards the galcore code base :) |
| 13:01 | dv_ | yeah, but I do not know how big it is |
| 13:01 | dv_ | is a rewrite feasible? |
| 13:02 | _rmk_ | its big but I think a rewrite is feasible. one reason its big is because of all the argument validation it does on every single function |
| 13:02 | _rmk_ | ... which really does nothing to save the code from real proper bugs |
| 13:02 | dv_ | ahah, I am reminded of the memcpy with a return code |
| 13:02 | dv_ | hmm |
| 13:02 | dv_ | sounds like an interesting project. the kernel counterpart to etnaviv. |
| 13:04 | _rmk_ | right, that's Rob's suggestions incorporated into the armada drm stuff |
| 13:06 | _rmk_ | and... one more test-run of the nightly ktest build for carrier-1 should be successful |
| 13:08 | dv_ | would robclark's suggestions work for the imx too? are they purely about vivante? |
| 13:08 | _rmk_ | no, they're about getting armada drm finally merged |
| 13:09 | dv_ | i see |
| 13:12 | dv_ | so the galcore is the drm component in the whole DRI chain? |
| 13:14 | jnettlet | etnaviv should get its own drm driver that both imx and armada can use. |
| 13:14 | jnettlet | or any other chip with vivante bolted in. |
| 13:14 | dv_ | yes, thats my point |
| 13:14 | jnettlet | before it would have been a nightmare, but I think all the pieces are there to make it work now. |
| 13:15 | dv_ | okay |
| 13:16 | jnettlet | _rmk_, I almost have your patches rebased onto the newer codebase. Although you are right there is more that needs to be cleaned up. |
| 13:17 | _rmk_ | jnettlet: what is the exact version string you have? |
| 13:17 | _rmk_ | for the _GC_VERSION_STRING_ |
| 13:17 | _rmk_ | the version I pulled from the OLPC stuff a while back was Ver0.8.0.2905 |
| 13:19 | _rmk_ | its in hal/inc/gc_hal_options.h |
| 13:19 | jnettlet | _rmk_, unfortunately that is marvell's version number scheme. The code with all the proper GPL headers is 4.6.9 build 1210 by Vivante's scheme. |
| 13:20 | jnettlet | However that has all of Freescale's customizations in it. I have ripped out all Freescale/Marvell stuff and need to think about common clock and frequency scaling for it. |
| 13:20 | jnettlet | I want to do as little as possible, so I am wrestling on a simple solution. |
| 13:20 | _rmk_ | hmm, where do you find that 4.6.9 version info from? |
| 13:21 | jnettlet | gc_hal_options.h |
| 13:21 | jnettlet | it could bin in hal/user/inc/ or hal/kernel/inc depending on the version and codebase |
| 13:21 | dv_ | whats that stuff in drivers/gpu/drm/vivante/ ? (in the linux-imx kernel) |
| 13:22 | jnettlet | dv_, that is a very hackish interface the vivante threw together to let their mesa driver draw directly to the screen |
| 13:22 | _rmk_ | jnettlet: hmm, the closest I have to anything like that is this: |
| 13:22 | _rmk_ | #define _GC_VERSION_STRING_ "GC Ver0.8.0.2905" |
| 13:22 | dv_ | looks like a hack, yes |
| 13:22 | dv_ | also, the linux-imx galcore copy does not seem to have a _GC_VERSION_STRING_ |
| 13:23 | jnettlet | _rmk_, yeah that is the "old" format. that is the Version 2 codebase, they are now on Version 4 |
| 13:23 | dv_ | at least I cant find it in mxc/gpu-viv/ |
| 13:23 | _rmk_ | jnettlet: do you know whether they've changed the user API in any incompatible ways again between v2 and v4 |
| 13:24 | jnettlet | the version? dv_ that is because in the newer version they broke it up into 4 different definitions. Major/Minor/Release/Build |
| 13:24 | dv_ | _rmk_: my colleague tried to apply your patches, which was written for v2 IIRC. he could apply them because the differences were severe |
| 13:24 | jnettlet | _rmk_, yes some things. The drivers check and won't let you run userspace/kernel that don't match |
| 13:25 | dv_ | right. 4.6.9 build 6622 |
| 13:26 | _rmk_ | okay, what I think I'll do is pull my rewritten galcore mmu support out of galcore so that can be re-used |
| 13:26 | dv_ | is it common for drm drivers to be that fragmented? arch/hal, kernel/os etc. |
| 13:27 | jnettlet | well depends. This isn't really a drm driver. It is fragmented so they can have once monolithic codebase for all their supported platforms and gpu's |
| 13:28 | _rmk_ | one huge monolithic codebase where every vendor puts their own hacks in |
| 13:28 | dv_ | okay, this brings me to my original question.. what _is_ the galcore driver? |
| 13:28 | dv_ | how could it be categorized? |
| 13:28 | dv_ | drm plus extras? |
| 13:28 | _rmk_ | the galcore driver is basically just something which provides userspace access to the GPU in a semi-controlled way |
| 13:28 | dv_ | sounds like thats what DRI is supposed to do |
| 13:29 | _rmk_ | yep |
| 13:29 | dv_ | so essentially galcore circumvents DRI with their own kinda similar mechanism |
| 13:29 | jnettlet | right. which is why I have it sitting at drivers/gpu/galcore next to drivers/gpu/drm |
| 13:29 | _rmk_ | but because they want it to work everywhere even non-linux, they don't want to use linux apis |
| 13:29 | dv_ | this reminds me of what nvidia does |
| 13:29 | dv_ | jnettlet: is this uploaded somewhere? |
| 13:30 | jnettlet | dv_, Wed. :-) I have a date now. |
| 13:30 | _rmk_ | right back later. |
| 13:30 | dv_ | later |
| 13:30 | wumpus | _rmk_: yes the user space API is completely incompatible between v2 and v4 |
| 13:30 | jnettlet | been busy |
| 13:30 | jnettle | 13:30 * jnettlet is blue wiring the fuse for now. |
| 13:30 | dv_ | ah np, just been curious |
| 13:31 | dv_ | I have been thinking about eventually trying to help with the vivante drm stuff once I have time, since my gstreamer-imx work is close to being finished |
| 13:31 | wumpus | _rmk_: for example the context handling is completely different (v4 introduced state deltas, which are pretty terrible) |
| 13:31 | dv_ | so I wonder where the situation is more urgent, userspace or kernel space |
| 13:32 | jnettlet | well DRI3 was just announced and is in Xorg mainline now. |
| 13:32 | jnettlet | that is what we should be shooting for with the new driver |
| 13:42 | jnettlet | okay blue wire is rocking. |
| 14:39 | _rmk_ | so long as it isn't glowing :) |
| 14:52 | jnettlet | haha...I just added the 3 color glowing logo plate from my deceased boxee to my setup :-) |
| 14:52 | jnettlet | I have no idea how to drive it yet. But it is mounted in the case |
| 15:21 | jnettlet | you guys are going to be so jealous when you see my new setup :-P |
| 16:53 | robclark | wumpus, btw, do you see any need to build cmdstream buffers in userspace? Ie. maybe if you have some big chunk of state you want to re-use (color lookup tables or something like that?) |
| 16:54 | robclark | errg |
| 16:54 | wumpus | robclark: yes, of course you want to be able to do that |
| 16:54 | robclark | build cmdstream buffers with branches in userspace |
| 16:54 | robclark | coffee not kicking in yet this AM :-P |
| 16:54 | wumpus | oh, you want to use the link/call/return in userspace? I guess that'd be pretty cool |
| 16:55 | wumpus | but mind that the command stream can only use real physical addresses |
| 16:55 | robclark | is it useful |
| 16:55 | wumpus | so it may be difficult |
| 16:55 | wumpus | it's not possible with the vivante driver AFAIK |
| 16:55 | robclark | well, that would be part of the patching up |
| 16:55 | wumpus | or hmm maybe it is |
| 16:55 | robclark | to replace handle+offset w/ paddr or gpu vaddr |
| 16:56 | robclark | for reference, this is what I have for msm: http://cgit.freedesktop.org/~robclark/linux/tree/include/uapi/drm/msm_drm.h?h=msm-fixes-3.12-rc2#n98 |
| 16:56 | wumpus | the contiguous memory allocator could be used, it's just difficult to track what is currently in use by the gpu and what not |
| 16:56 | wumpus | (but yes, command buffers really need to be contiguous) |
| 16:56 | robclark | for msm (and I think really all the other drm drivers) kernel knows all the cmdstream and other buffers in flight at any given time |
| 16:56 | robclark | ok |
| 16:57 | robclark | so that means we need to support allocation of contig and non-contig buffers.. but several other drivers do this too, not too much of a big deal |
| 16:57 | wumpus | yes that makes sense, exposing as much of the functionality as possible to userspace would be great, it's not used at this point but I can see how it can be useful |
| 16:57 | robclark | ok |
| 16:57 | wumpus | yes; non-contiguous/virtual buffers can be used for other content such as textures, framebuffers, vertex/index buffers |
| 16:58 | wumpus | the vivante driver has some logica to keep them on different banks of sdram, but it isn't really necessary, you can just use mmu'd memory for all of them |
| 16:58 | wumpus | only for the command stream (IIRC) you really need contiguous memory |
| 16:58 | robclark | ok.. I guess for a starting point I'll probably nearly copy/paste the msm API.. plus add flag bit for cmdstream buffer allocation to indicate to kernel to do contig |
| 16:58 | wumpus | ok |
| 16:59 | _rmk_ | robclark: I guess people will soon learn about 96477b4c |
| 17:00 | robclark | wumpus, I probably won't do the whole state-delta thing.. but instead give you something like the 'MSM_SUBMIT_CMD_CTX_RESTORE_BUF' |
| 17:00 | _rmk_ | robclark: with that __get_user() implementation, try building this: |
| 17:00 | _rmk_ | int test_ptr(unsigned int **v, unsigned int **p) |
| 17:00 | _rmk_ | { |
| 17:00 | _rmk_ | return get_user(*v, p); |
| 17:00 | _rmk_ | } |
| 17:01 | _rmk_ | it should produce no warnings |
| 17:01 | robclark | _rmk_, from a quick look at git history, it didn't seem like get_user_8 support was reverted on x86-32.. |
| 17:01 | robclark | ok.. I did have some test code once upon a time.. |
| 17:01 | robclark | let me try to resurrect that |
| 17:01 | _rmk_ | I just ran it through my test, which spat out this for the above: |
| 17:01 | _rmk_ | t-getuser.c:236:9: warning: cast to pointer from integer of different size |
| 17:01 | robclark | hmm.. |
| 17:02 | robclar | 17:02 * robclark hoping he actually sent most recent version of that patch.. |
| 17:02 | _rmk_ | hpa and myself spent a long time on this problem a while back |
| 17:03 | wumpus | robclark: that's great because I already have code for that, I don't handle the state delta stuff currently at all :) |
| 17:03 | robclark | wumpus, ok, that works out well |
| 17:05 | robclark | _rmk_, hmm, I don't seem to get any warning.. although I did have to revert back to gcc 4.7 since 4.8.1 was giving me non-booting kernels (at least for older 3.4 based msm crap) |
| 17:06 | dv_ | robclark: not booting at all? or an immediately crashing kernel? |
| 17:06 | _rmk_ | robclark: this is weird... |
| 17:07 | robclark | dv_, well, no output on debug uart (even w/ earlyprintk), and I don't have jtag to debug further.. but that could be something wrong in msm kernel (which has strayed far from mainline) |
| 17:07 | dv_ | hmm |
| 17:07 | dv_ | I'd have otherwise guessed its the memset bug again |
| 17:07 | dv_ | https://lists.yoctoproject.org/pipermail/meta-freescale/2013-July/003534.html |
| 17:07 | dv_ | its currently biting many people |
| 17:07 | robclar | 17:07 * robclark has a look |
| 17:07 | _rmk_ | looking at the code at Linus' tip, it doesn't support __get_user() with 64-bit args on X86_32 |
| 17:08 | _rmk_ | read through the code :) |
| 17:08 | dv_ | I needed it to get the linux-imx kernel to boot |
| 17:08 | robclark | dv_, it isn't actually a compile time error that I get (fwiw) |
| 17:08 | dv_ | robclark: the fix is for a runtime error |
| 17:09 | robclark | _rmk_, hmm... odd, maybe it was broken again sometime after ville's patch? I've not dug into the git history there yet |
| 17:09 | robclark | dv_, hmm, ok |
| 17:09 | _rmk_ | I can't find anything in the git history on this |
| 17:09 | robclar | 17:09 * robclark assumes ville actually managed to test his patch somehow? |
| 17:10 | _rmk_ | get_user() itself does seem to support it |
| 18:12 | _rmk_ | robclark: ok, updated stuff at http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/log/?h=drm-tda998x-3.12 |
| 18:12 | _rmk_ | if you see anything obvious... |
| 18:12 | _rmk_ | is DRM: or drm/subsection: preferred? |
| 18:27 | rabeeh | _rmk_: "<_rmk_> if I can locate the pad connections for the lvds connector, I might have a go at getting some of the imx-drm stuff going" ?? |
| 18:27 | rabeeh | you need LVDS? |
| 18:27 | rabeeh | do you have an LVDS monitor? |
| 18:32 | _rmk_ | rabeeh: no but its a case of "what is supposed in mainline" :p |
| 18:32 | _rmk_ | fwir, you don't have the connector on the board |
| 18:36 | rabeeh | _rmk_: the connector is not there |
| 18:36 | rabeeh | but lvds was validated and found to be working; |
| 18:36 | rabeeh | the main issue with LVDS is that there is no standard |
| 18:37 | rabeeh | we have used the Freescale connector as-is; and we are using a Hannstar LVDS display |
| 18:59 | robclark | _rmk_, ok, I'll have a look in a bit.. I usually do drm/subsystem (ie. drm/armada, drm/tda998x, etc) |
| 18:59 | robclark | the nouveau guys have their own scheme where they indicate hw generation.. but I don't claim to understand it ;-) |