01:37 | Coburn | yeah, just got that |
01:37 | Coburn | going to see if it crashes xorg |
01:37 | _rmk_ | if Xorg crashes, it becomes Xorg.0.log.old |
01:37 | Coburn | yep, it crashed xorg |
01:37 | Coburn | woot |
01:38 | Coburn | getting logs |
01:39 | Coburn | so |
01:39 | Coburn | I have the "working" log |
01:39 | Coburn | and the "crashed" log |
01:39 | Coburn | is that all you need or do you need dmesg dump too? |
01:40 | _rmk_ | well, if you include the dmesg dump, then I won't have to ask for it if I decide I'd like it :) |
01:41 | Coburn | ok |
01:41 | Coburn | copying to usb |
01:46 | Coburn | _rmk_: https://clients.dryhosting.net/client-projects/rmk_logs.7z |
01:57 | _rmk_ | can't see anything obvious in there - I wonder if it's something which Xorg 1.12.4 is doing differently |
02:01 | Coburn | I'm making a backup of the uSD in case you want to use the image I have for debugging |
02:01 | Coburn | I don't think it has client data on it apart from just configurations |
02:02 | _rmk_ | I assume you'll be able to do updates to it? |
02:02 | Coburn | uhh |
02:02 | Coburn | I've actually packaged the CuBox up |
02:03 | Coburn | HOWEVER |
02:03 | Coburn | I haven't got payment for this client job yet |
02:03 | Coburn | so I do have leeway but just wanted to get it out of my task list :P |
02:03 | Coburn | (I was packing up the whole thing to get a postage quote) |
02:05 | Coburn | but if you have changes to be made, I can do it |
02:05 | _rmk_ | I don't have anything immediate |
02:05 | Coburn | any ideas though? |
02:06 | _rmk_ | just looking at what changed in Xorg |
02:06 | _rmk_ | on the hdmi issue - let me get it straight - you boot with the hdmi display connected and powered, and it doesn't display? |
02:06 | Coburn | no. |
02:06 | Coburn | I boot the cubox |
02:07 | Coburn | and I see the Xorg starts up. |
02:07 | Coburn | I then plug in the monitor. |
02:07 | Coburn | No signal |
02:07 | Coburn | If I have the HDMI monitor connected at boot, I get a tux and Xorg desktop (auto-login with lightdm) |
02:08 | Coburn | although, if I am late after it boots, it does sometimes flicker on and show a underscore and the HW cursor |
02:08 | Coburn | So basically, hotplugging doesn't work, but connect screen to cubox before booting = success! |
02:14 | _rmk_ | hmm, okay, I'll look at these three problems and see if I can get to the bottom of what's going on |
02:15 | _rmk_ | I've seen hotplug work, because I booted many a time with the tv turned off - it doesn't provide EDID or even a the detection signal in that state - and had it sort itself out after powering the tv on. |
02:16 | _rmk_ | one last question: what was the last commit in xf86-video-armada? |
02:19 | Coburn | i dunno |
02:20 | Coburn | I think it was like... jan 13 or something |
02:20 | Coburn | 2013-12-23 Fix segfault on X shutdown.HEADmaster |
02:20 | Coburn | that's from cgit |
02:22 | _rmk_ | yep, latest. |
02:23 | _rmk_ | okay, last (two part!) question for tonight... you said you had a copy of the SD card. (a) how large is it (b) can it be sent to me somehow? |
02:23 | _rmk_ | as you've already packaged the cubox up, it sounds like you're not intending to do any further changes to it |
02:24 | Coburn | i can stick it on my webserver |
02:24 | Coburn | i own my own hosting network so I have resources :P |
02:24 | _rmk_ | ah :) |
02:25 | _rmk_ | what I'm thinking is, it may be easier if I run your image and debug it locally |
02:27 | Coburn | ok |
02:30 | _rmk_ | my attempts at trying to see what's changed in Xorg are being thwarted by a reformatting of the code |
02:30 | Coburn | making a backup now |
02:32 | _rmk_ | and please don't 7zip it, I ended up using a website to do the un7zip'ing |
02:32 | _rmk_ | annoyingly, fedora ship p7zip for x86_64 but not i686 |
02:40 | Coburn | .... |
02:40 | Coburn | I 7zip'd it... >_> |
02:41 | Coburn | I'll try a zip, the 7z archive is 992mb |
02:42 | Coburn | shite, zip has better compression?! |
02:44 | _rmk_ | heh. |
02:50 | Coburn | 1.2gb |
02:50 | Coburn | for the zip |
02:50 | Coburn | let me try a tarball |
02:51 | _rmk_ | ok, /msg me a url to it and I'll pull it down tomorrow evening outside peak times here |
02:51 | Coburn | going to try a xz and a tarball |
02:51 | Coburn | alright, I will do |
07:35 | Coburn | aussie internet can go /dev/null itself |
07:35 | Cobur | 07:35 * Coburn shakes fist |
07:54 | Xobs | Is anyone running relatively recent (e.g. newer than 3.13.0-rc4+) kernels? I'm on a different i.MX6 platform, but newer kernels are really unstable for me. |
07:55 | jnettlet | Xobs, there are a handful of people running 3.13+ kernels. _rmk_ believes there is a memory leak of sorts in newer kernels. There is definitely a patch needed for the sockets that was causing OOM's |
07:57 | Xobs | jnettlet: That's good to know. But this is lots of "unable to handle kernel paging requests", particularly when booting or building a kernel. |
07:57 | jnettlet | Xobs, sounds like a symptom of the memory leak. |
07:57 | jnettlet | booting a kernel? |
07:59 | jnettlet | Xobs, oh nice to meet you in realtime. Just placed your nick. How is the Novena board bringup going? |
07:59 | Xobs | jnettlet: You too :) |
08:00 | jnettlet | Xobs, did you see full GC2000 3d support has landed in etnaviv? |
08:00 | Xobs | jnettlet: It's going well. I'm fixing up the audio codec code right now, in preparation for submitting both it and the novena dts to mainline. But I haven't been able to build a kernel. |
08:01 | Xobs | jnettlet: That's really exciting. I hadn't heard that. |
08:01 | jnettlet | Just happened last week |
08:01 | jnettlet | I still haven't had time to test it. |
08:03 | Xobs | jnettlet: Me neither. Though I'll do that once I have a kernel that works reliably. |
08:04 | Xobs | It'll be nice to get a machine again with multi-monitor support /and/ some sort of 3D support. |
08:04 | jnettlet | Xobs, do you get the errors if you limit the memsize to 2GB? You are one of the few platforms supporting 4GB's right now. |
08:05 | Xobs | jnettlet: That's an excellent question. I'll swap out DIMMs and try it. |
08:05 | Xobs | That's amusing. Init segfaulted during the shutdown. |
08:06 | jnettlet | ouch |
08:08 | jnettlet | Xobs, oh and really cool work by you and bunnie on the SDHC card hack. |
08:12 | Xobs | jnettlet: Thanks! |
08:13 | Xobs | Still trying to adjust the RAM. For some reason, smaller DIMMs aren't letting U-Boot access SATA. And init just panicked during boot, right around the time USB enumerated. |
08:14 | Xobs | Something is definitely broken. Fortunately, 3.13.0-rc4+ works reliably. |
08:17 | jnettlet | Xobs, are you guys using a recent u-boot or the old 2009 version that Freescale is supporting? |
08:18 | jnettle | 08:18 * jnettlet has shifted his focus to barebox. |
08:19 | Xobs | Hmm... Linux is limited now to 1024 MB, and init still segfaulted during one of the reboots. Good thought. |
08:19 | Xobs | We're still using U-Boot mainline from early 2013. I'd like to move to Barebox, though. |
08:20 | Xobs | I'll have to investigate U-Boot's SPL once we add 6DL boards, just so we can calibrate DDR before loading a program image. Unless U-Boot has something similar to SPL. |
08:20 | Xobs | ...unless Barebox has SPL. Sorry. |
08:21 | jnettlet | they don't have SPL specifically but I am working out the 2-stage bootloader pieces with them. |
08:22 | jnettlet | my goal is stage one that init's ddr and reads an env for boot config to load zImage and boot direct to linux. If a boot fails then it can fall back to second stage barebox. |
08:22 | Xobs | That's very similar to my goal. |
08:23 | Xobs | We have a "USER" button that I'm using to switch kernels. All development is being done on-board. |
08:23 | jnettlet | I have part one mostly done, but have been distracted getting a fully functional 3.10 lks kernel that doesn't suck ready |
08:23 | jnettlet | oh cool idea |
08:23 | Xobs | If I hold the button during boot, it loads the recovery kernel. |
08:23 | jnettlet | we have something similar on the XO laptop |
08:26 | Xobs | Maybe I'll try a bisect. Or just ignore it for now and develop the patches on 3.13.0-rc4 |
08:26 | jnettlet | Xobs, if you want to talk specific u-boot/barebox/kernel/driver stuff we have a #cubox-devel over on OFTC. Freenode has been quite unstable and gets a lot of support chatter, so we added a new channel for devel specific stuff. |
08:27 | Xobs | Alright. I'll go join over there. |
09:25 | dv_ | Xobs: you are a novena guy? |
09:25 | Xobs | dv_: Yep. |
09:25 | dv_ | novena uses a different audio chip, or what do you mean by codec? |
09:29 | dv_ | Xobs, if you want to talk specific u-boot/barebox/kernel/driver stuff we have a #cubox-devel over on OFTC. Freenode has been quite unstable and gets a lot of support chatter, so we added a new channel for devel specific stuff. <- hey, how come nobody told me that? :) |
09:52 | Xobs | dv_: Different audio chip. Freescale's reference board uses the SGTL5000. Novena's uses the ES8328. It's cheap. |
16:43 | _505 | for #cubox-devel on OFTC, any interest in a public log like for this channel? or do you want to keep it a bit more low profile? |
17:22 | wbx | hmm. what are good CFLAGS for gcc to produce optimal code for cubox-i? -march=? |
17:26 | wbx | is this okay: -march=armv7-a -mtune=cortex-a9 -mfpu=vfpv3-d16 ? |
17:29 | jnettlet | wbx, you probably want mfpu=neon |
17:36 | wbx | jnettlet: http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html says neon usage is not conforming to IEEE 754. do you think this is a problem? |
17:39 | jnettlet | wbx, no because you are not using the -funsafe-math-optimizations flag. Therefore unless it is a specific NEON operation or intrinsic NEON won't be used and gcc will compile for vfpv3-d16 which is the default. |
17:40 | jnettlet | so really it comes down to. Are you looking for the same flag to be used for all projects, or is this specifically for a project that is/is not using the NEON instruction set. |
17:41 | wbx | jnettlet: I am looking for a flag, which is best for all software I compile. |
17:42 | jnettlet | then -mfpu=neon is what you want, so software written with NEON intrinsics and instructions will be optimized. |
17:43 | jnettlet | for non-NEON software gcc will just fallback to using vfpv3-d16 |
17:43 | wbx | jnettlet: okay fine. thx. And what do you think about arm thumb mode? do I need/want it on cubox-i? |
17:44 | jnettlet | some users have benchmarked thumb performing well, however in general the rule is thumb code is smaller but less performant. |
17:45 | rabeeh | wbx: you need to test with and without thumb |
17:46 | jnettlet | most distros compile code as standard arm instructions, so compiling thumb code is really asking to poke at a lot of possible bugs that nobody has experienced or has great interest in fixing. |
17:48 | rabeeh | there are binaries that will run faster with thumb-2; given the lower footprint and sometimes all the heavy working code fits in i-cache without conflict within it's size or number of ways |
17:55 | jnettlet | but for a general rule of thumb *haha* compile for ARM. Then go back and optimize specific packages with Thumb2 |
17:57 | rabeeh | jnettlet: i think i'v read it somewhere that iOS does it the way around - the build everything for thumb2 |
17:57 | rabeeh | i'll dig it |
17:59 | jnettlet | rabeeh, that may be due to their use of llvm. It may be more optimized for thumb2 instructions where gcc is generally the other way around. |
18:08 | jnettlet | rabeeh, well that explains why IOS is able to run with considerably less RAM |
18:08 | jnettlet | thumb2 code is generally about 30% or so smaller than ARM code. |
18:09 | jnettle | 18:09 * jnettlet is very interested in a Linux distro that defaults to thumb2 code |
18:10 | jnettle | 18:10 * jnettlet is also very scared as the bugs of gcc generated thumb2 code could be insane |
18:15 | purch | rabeeh: roadmap ready for next ubuntu LTS for cubox-i4? :) |
18:17 | wbx | jnettlet, rabeeh: thanks for the input. I think I will add it as an option, so I can create both. |
18:22 | rabeeh | purch: big debate on the distro to officially support |
18:22 | rabeeh | looking at the landscape today; xbmc on CuBox-i / HB looks pretty good and advancing |
18:22 | rabeeh | there is a debate on what is the major distro to support |
18:23 | rabeeh | given it's ARMv7 with neon and vfpu; the binaries of any distro today is supported as-is; but then comes the packaging and tweaks to make it super easy (and maintanable) for end users |
18:23 | rabeeh | purch: on the table Debian, Arch, Ubuntu and Fedora |
18:23 | rabeeh | my biggest worries is starting a flamewar between users which one is better but we should decide on one |
18:25 | jnettlet | I know it is insanity but I am reviving SolusOS-2 for the platform :-) |
18:25 | Coolgeek | rabeeh: make a poll on the forum |
18:27 | rabeeh | Coolgeek: :) |
18:27 | Coolgeek | but I think you already think of that :p |
18:28 | rabeeh | let me rephrase my previous sentence; i know that there will be a flamewar on which distro to use; either it's on #cubox or the forums doesn't matter |
18:28 | rabeeh | Coolgeek: well.. that's the other thing; if I say what i think in my mind will move people away from CuBox |
18:28 | Coolgeek | erf |
18:28 | purch | I have used Arch for 5 years and I got bored to syncin configs etc. Before that I used several years of debian and now ubuntu last 6 years. Ubuntu I say, but debian ok, too. |
18:29 | rabeeh | i previously asked Zaher on #cubox and he had the following line - "choose anything but Ubuntu" |
18:30 | jnettlet | should we start CubeOS? |
18:30 | jnettlet | OS^3 |
18:30 | purch | thumb-2's to that =) |
18:31 | purch | second kid coming in a month, so free time is rare. I prefer easy stuff nowadays |
18:31 | rabeeh | cbxbiker61 has Xilka |
18:32 | rabeeh | purch: boy/girl? |
18:33 | purch | second boy |
18:33 | hste | cubox-iOS :) |
18:33 | rabeeh | jnettlet: i can't even find a sane link to SolusOS |
18:33 | rabeeh | CuBoS |
18:33 | rabeeh | :) |
18:33 | rabeeh | purch: congrats; hope everything will be smooth |
18:34 | purch | that's not up to me :P |
18:34 | rabeeh | i have two girls; 6 and 4. and yesterday the younger one demanded a pink CuBox for her room |
18:34 | jnettlet | rabeeh, that is because Sean the guy working on it got burned out, got a new job and closed up shop for the new year. But he left behind the code and build infrastructure. |
18:34 | purch | nice :) |
18:34 | purch | where is the blue ones?! |
18:34 | jnettlet | It is literally the best XFCE based distro I have used. |
18:35 | rabee | 18:35 * rabeeh likes xfce |
18:35 | purch | one fr xfce |
18:35 | purch | for |
18:35 | rabeeh | but i like lxde more |
18:35 | jnettlet | but what makes it different is the Pisi package manager from pardus linux which is really nice. |
18:35 | purch | kde more or less ... less tweaking and configs editing |
18:36 | purch | dual seat (2x gpu) works on kde nicely |
18:36 | rabeeh | hmm.. how about 'damn small cubos' |
18:37 | rabeeh | what i would really like is a distro that doesn't have an update every day |
18:37 | rabeeh | once a month at the 1st of every month you update it, reboot it and that's it; no more rebooting the whole month |
18:38 | hste | ksplice? :) |
18:39 | rabeeh | on ARM? |
18:39 | hste | that's the challenge :) |
18:40 | hste | or lxc kernel so you could use many different distroes |
18:41 | rabeeh | if 16 core i7 does virtualization; ARM does phyiscalization |
18:42 | rabeeh | that kills lxc :) |
18:43 | hste | a beowulf cluster of cubes |
18:44 | jnettlet | hste, I was looking at porting coreos over and supporting docker packages. |
18:44 | rabeeh | hste: i showed a picture few days a go of ~250 CuBox-i4pro waiting for burn-in before shipping |
18:44 | jnettlet | although lxc with btrs is better for supporting from init up |
18:44 | hste | rabeeh: maybe you should use those and delay shipping..... :) |
18:45 | rabee | 18:45 * rabeeh is tempted; but ever time i look at our delays i would only cry |
18:45 | rabeeh | one of the things i wanted to test is seti@home |
18:46 | rabeeh | and if the opencl 1.1e can be really used to accelerate calculations |
18:46 | lioka | jnettlet: we (altlinux) are -mthumb by default |
18:46 | lioka | so stop looking around :] |
18:46 | rabeeh | jnettlet: lioka from openwrt project |
18:46 | jnettlet | lioka, oh really? do you have to carry a lot of patches to support it? |
18:47 | lioka | not really |
18:48 | jnettlet | do you guys have any performance/resource usage comparisons posted? |
18:48 | jnettle | 18:48 * jnettlet is just curious |
18:48 | hste | jnettlet: have u tried f2fs on your kernel? |
18:48 | lioka | dozen packages maybe among 10000+ source packages |
18:48 | jnettlet | hste, I just finished backporting 3.13.y f2fs back to my kernel over the weekend. |
18:49 | jnettlet | so I should be all caught up. |
18:49 | lioka | jnettlet: we're into thumb from start of our port, so no performance charts |
18:50 | rabeeh | jnettlet: cbxbiker61 would have better idea about this since he is porting full distros (tens of thousands of packages) |
18:50 | lioka | jnettlet: as for sizes -- 25-30% less than in arm mode |
18:50 | jnettlet | cbxbiker61, ping ^^^ you want to weigh in? |
18:51 | jnettlet | lioka, RSS? |
18:51 | rabeeh | i'v done it in the past (few years ago on Fedora) and i mainly stumbled with issues on the Eclipse part, building java stuff and lots of mono issues |
18:51 | jnettlet | or on disk? |
18:51 | lioka | jnettlet: on disk. |
18:52 | jnettlet | lioka, do you have an altlinux CBi image to download? |
18:53 | jnettle | 18:53 * jnettlet will give it a roll |
18:53 | lioka | jnettlet: nope, sorry |
18:53 | jnettlet | no worries. we can work on that |
18:55 | warped-rudi | jnettlet: on which hardware did you gather the lmbench results yesterday ? |
18:55 | jnettlet | warped-rudi, from my CBi4p |
18:56 | jnettlet | warped-rudi, could you post your dmesg logs for your CBi4p? |
18:57 | rabeeh | jnettlet: you can probably start here - http://www.altlinux.org/Cubox |
18:57 | warped-rudi | sure, just need to boot it up. did you see my results ? |
18:58 | rabeeh | warped-rudi: i had brief discussion with jnettlet with regards the numbers; he sent me numbers that looked even better than your HB / i4pro |
18:58 | jnettlet | yes. That is why I am curious to look more at your kernel logs |
19:00 | rabeeh | i suggest we leave the dd and cached dd since they heavily rely on the memcpy implementation that is part of the kernel |
19:00 | rabeeh | i mean the buffer cache to user space copy function (highly depends on kernel version and toolchain) |
19:00 | rabeeh | for the stream benchmark; can it be built with '-static'? |
19:01 | rabeeh | this also to remove different libc and toolchain optimizations (different gcc with different built-in flags for processor, with / without neon etc...) |
19:02 | jnettlet | stream is very basic it only links against libgcc and libc |
19:03 | warped-rudi | here we go: http://fpaste.org/77944/ |
19:05 | jnettlet | Memory: 512MB 1280MB = 1792MB total? |
19:05 | jnettlet | are all the 3.0.35 kernels broken up like that? |
19:06 | jnettlet | rabeeh? |
19:06 | rabeeh | http://pastebin.com/L0q8u4RX |
19:06 | rabeeh | 3.0.35 broken? |
19:06 | rabeeh | because of 1792? or two regions? |
19:07 | jnettlet | the two regions |
19:07 | rabeeh | 1792=2048-128(GPU)-128(VPU) |
19:07 | rabeeh | yes.. two regions is what comes with the fsl kernel |
19:07 | jnettlet | blech. I need to get these people on 3.10 |
19:07 | rabeeh | CONFIG_VMSPLIT_2G=y |
19:08 | rabeeh | hahaha |
19:08 | rabeeh | jnettlet: i wouldn't agree more |
19:08 | hste | jnettlet: its all up to u :) |
19:09 | jnettlet | hste, actually it has relied on many people. All the outstanding issues have just recently been sorted out. I am now into cleanup and almost ready for testing. |
19:10 | hste | jnettlet: which galcore version are you planning to release it on? |
19:11 | jnettlet | hste, the version that freescale just released, plus _rmk_'s race patches and my optimization patches. |
19:13 | jnettlet | 4.6.9 9754 |
19:14 | rabeeh | this is my stream binary (static) - http://dl.dropboxusercontent.com/u/72661517/stream |
19:14 | hste | jnettlet: that one does support xorg with randr, but there are some bugs so you have to set resolution manually |
19:15 | warped-rudi | jnettlet: Can't wait... btw, I backported _rmk_'s race patches to the old CuBox 3.6.9 kernel we are using in geexbox |
19:15 | jnettlet | hste, yeah I have fixed that. Their ddx implementation is poor. Although we are using this to move the MX6 platform to support _rmk_'s KMS driver and the universal vivante 2d acceleration driver |
19:16 | jnettlet | warped-rudi, his race patches were written for that that kernel :-) |
19:16 | jnettlet | I had to adapt them to the new V4 codebase. But they do make the driver a lot more stable. |
19:17 | rabeeh | just tried running ./stream few times; the numbers are pretty solid -+1% |
19:21 | firemanxbr | hey guys |
19:22 | firemanxbr | Anybody using Fedora 20 on Cubox-i ? |
19:22 | jnettle | 19:22 * jnettlet has an image for testing but doesn't use it too much. |
19:23 | warped-rudi | rabeeh: your stream benchmark gives here pretty much the same results as on your machine |
19:23 | rabeeh | ok. great. |
19:23 | rabeeh | do you have your stream / stream2 in binary static? |
19:24 | rabeeh | jnettlet: can you try? |
19:24 | rabeeh | the only thing that differs is different kernel; that it might only change page table attributes |
19:24 | firemanxbr | jnettlet, I wish port all features of cubox-i to Fedora, I'm engineer of Fedora Project |
19:25 | rabeeh | firemanxbr: welcome to #cubox :) |
19:25 | jnettlet | firemanxbr, well Fedora will only officially support upstream features |
19:25 | firemanxbr | firemanxbr, I'm buying 2 models(cubox-i2 and cubox-i4pro) |
19:25 | firemanxbr | * great |
19:26 | firemanxb | 19:26 * firemanxbr Cool |
19:26 | rabeeh | firemanxbr: please ping me with regards this; we will support with regards that. |
19:27 | firemanxbr | rabeeh, thnzk for attention :D |
19:27 | rabeeh | firemanxbr: sorry for getting into the middle between you and jnettlet; but i work for SolidRun |
19:27 | jnettlet | base support will be included in F21 as _rmk_ has already pushed things upstream |
19:27 | jnettlet | rabeeh, no need to apologize |
19:28 | firemanxbr | I created support for some arm devices(pandaboard es, beaglebone black and cubieboard 2 and cubietruck) |
19:28 | firemanxbr | rabeeh, :) |
19:29 | jnettlet | firemanxbr, did you create separate spins or was this official Fedora support? |
19:30 | firemanxbr | I created this documentation in our Fedora: https://fedoraproject.org/wiki/Architectures/ARM |
19:31 | firemanxbr | jnettlet, no, only official support, remix works at other team |
19:34 | firemanxbr | I live in Brazil, my wish create more documentation in my native language(portuguese-brazilian) about cubox-i products, I believe your products have great oportunity for developers |
19:35 | firemanxbr | when my products arrive in Brazil beginning the tests and I report everyone here, thanks for listening, I'll be here, which can help with Fedora I am available |
19:36 | jnettlet | firemanxbr, okay. Did you already receive a Cubox-i? |
19:37 | firemanxbr | jnettlet, my boss bought two today |
19:38 | jnettlet | firemanxbr, okay. I have already chatted with Fedora about u-boot and upstream support. It should be in rawhide soon, although I have to catch up with probinson |
19:39 | firemanxbr | jnettlet, my request this is> #4928 |
19:40 | jnettlet | firemanxbr, is that an order number? |
19:40 | firemanxbr | jnettlet, yes |
19:40 | firemanxbr | jnettlet, my order number(4928) |
19:41 | rabeeh | ok. got those |
19:42 | firemanxbr | jnettlet, which can help with uboot I'm here |
19:44 | wbx | jnettlet: regarding u-boot, is there any plan to get it into upstream? |
19:44 | jnettlet | myself and rabeeh. although we have moved to the unoffical unified SPL booting for MX6 u-boot rather than the old individual images that Fedora is currently supporting |
19:45 | warped-rudi | rabeeh: tried static version of stream from lmbench. no difference. |
19:45 | rabeeh | fabio from freescale has been helping upstreaming things to u-boot |
19:45 | jnettlet | wbx, base support is upstream but there is no progress on them accepting SPL in its current form. |
19:47 | jnettlet | we are kind of holding where we are now, and I am putting my bootloader time into getting barebox up to snuff. The code is nicer to work on and the community is moving at a faster pace. |
19:55 | jas-hacks | firemanxbr: hi, is there any support for wayland in Fedora ARM ? |
19:56 | firemanxbr | jas-hacks, yes, i'm use in my work |
19:58 | firemanxbr | jas-hacks, if I can help you, I'm here. |
20:01 | jas-hacks | firemanxbr: thanks, would like to see if we could get the imx6 wayland libraries working with Fedora. |
20:02 | jas-hacks | firemanxbr: do you know if gnome shell and gtk+ are ported to use wayland? |
20:02 | firemanxbr | jas-hacks, yes |
20:02 | firemanxbr | jas-hacks, is GUI no my area, but I believed yes |
20:04 | firemanxbr | jas-hacks, in our wiki(https://fedoraproject.org/wiki/Changes/Wayland) I believe go done in next release(fedora 21) |
20:05 | jas-hacks | firemanxbr: I saw that, but wasn't sure if it was applicable to ARM release |
20:07 | firemanxbr | jas-hacks, arm is primary arquitecture in Fedora, my packages be build first in arm, after em x86_* |
20:08 | firemanxbr | jas-hacks, all functions be created in ARM & X86 & and more... |
20:12 | jas-hacks | firemanxbr: is there a prebuilt rootfs I could try to boot with? |
20:13 | rabeeh | warped-rudi: i talked to tomlohave today and i need to put the build machine offline to install a new UPS for it. |
20:13 | rabeeh | can I do this tomorrow noon? he suggested to contact you to start the buildbot after reboot |
20:14 | firemanxbr | jas-hacks, I use resize2fs for resize my partitions, but I dont know others options |
20:15 | warped-rudi | rabbeh: yes, do it that way |
20:15 | firemanxbr | jas-hacks, I need go now... sorry, but I have one meeting, see you later guy, bye |
21:39 | kalasmannen | ERROR: GetPicture - player is ahead of time |
21:39 | kalasmannen | anyone know what this might be caused by? running the latest geexbox nightly |
21:40 | kalasmannen | playback of all files except h264 P 5.1 seems to work |
21:40 | kalasmannen | they keep the right fps for a while, (~23 in this case), but sometimes drops as low as 15 |