Re: won't someone please think of the users!?
Clark, Rob wrote: just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time [+1] :) Actually, the issue isn't as much with Ubuntu as with Android. For Ubuntu, I have stopped pointing people at Linaro and always advise them to use official Ubuntu releases because there they at least stand a chance of getting some kind of support - although they often return from #ubuntu-arm saying that nobody would/could help them there... And don't get me wrong, I absolutely do not expect Linaro to provide Ubuntu support, I would actually prefer if Linaro Ubuntu builds were much more less visible to end users :) For Android on e.g. Pandaboard, there simply is not much else than Linaro to point people to. The original TI Pandroid effort was scrapped when TI found that it is too much work to support a user centric Android release and now TI as well points to Linaro. The only other place one could point people to is plain AOSP, but that lacks stuff like HW accell and isn't the focus of Google any more as far as panda is concerned. So Linaro is the only viable solution there, but as with Ubuntu, there is no end-customer support and the monthly releases make it a moving target. Again, I do not blame Linaro for the lack of support, it is simply a fact that Android as a distribution is way less supported than others, especially on less mainstream platforms. Having e.g. Cyanogenmod on Panda would surely help a lot, but I guess there is no critical mass for that and dev boards like Panda and others are in a way moving targets themselves... So I guess the only thing that can be done short-term is to state very clearly what Linaro builds are and what they are not and to discourage the average user from going down that road unless they know what they are doing (which will fail as well since users like car drivers all think they are above average..) Regards, Vladimir ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: won't someone please think of the users!?
Clark, Rob wrote: Also, I wonder if we should split #linaro, either into #linaro-devel and leave #linaro as a place that users can come to for help, or setup a separate #linaro-users? This way we aren't just dumping out new releases with nowhere for users to turn to for help.. (Well, they can always come to #linaro but I guess this would help with the signal-to-noise..) Think twice before setting up something like #linaro-users, unless you are willing to staff it and really help users there. Just having another idle mostly ghost town on IRC does not help much. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Why are our Android toolchains 32bit?
Bernhard Rosenkranzer wrote: Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than we inherited it from AOSP)? While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about fwiw, android GB and HC both build fine on 32 bit here... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android libjpeg
Måns Rullgård wrote: Mandeep Kumarmandeep.ku...@linaro.org writes: Vladimir Pantelicvlado...@gmail.com writes: Either I am doing something wrong or this libjpeg-turbo is not so turbo. Libjpeg (turbo or regular) is full of inefficiencies. I guess they all add up. My numbers should only be used for relative comparison purpose as djpeg decoding time that I sent also include time to read input file from filessystem. Actual decoding speed may be higher when special modification are done in djpeg application to read input from memory. I doubt reading from a cached file can account for that much time. Besides, I presume Vladimir was reading his file from somewhere too. my times have been measured around the libavcodec decode() call and include colorspace conversion to YUYV interleaved. I realize that libjpeg might have an additional YUV to RGB step that I did not do since my display is YUV capable. However, no matter how slow libjpeg is, that's what lots of apps use, and thus improving it should be beneficial to them insofar jpeg decoding is a bottleneck. sure, I did not mean for you to stop working on it :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Pandaboard is / x-loader flow and official branch
Andy Green wrote: ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care about any arcane stuff like geometry for example. It only needs to success to pull MLO reliably and anything further can be done there in an upgradeable way. neither does the OMAP3 ROM code. All the cargo cult around geometry stems from the fact that initially x-loader aka MLO hardcoded sector 63 for the start of the boot partition and this is fixed since long. Unfortunately, there is a large number of ancient unfixed MLO files out there... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Pandaboard is / x-loader flow and official branch
Andy Green wrote: I think we can count that as arcarna... but I think we're talking about different problems, and that the ROM fragility to partitioning on OMAP3 is real enough. On an IGEP0020 I was unable to create a bootable image -- one that would boot x-loader so it would talk on the serial console -- even after a couple of days struggling. It was only 'solved' in the end when Loic imaged the start of his magic working card and I dd'd it on to mine. Then it was happy even when I put my MLO on there. It would have been interesting to compare the 2 cards. In fact I did that once for a friend that had similar issues and in the end came up with: http://groups.google.com/group/beagleboard/browse_thread/thread/ae8e64e6be02baae?pli=1 the fact that partition size in MBR and FAT have to match came as a little surprise :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Pandaboard is / x-loader flow and official branch
Dechesne, Nicolas wrote: ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care about any arcane stuff like geometry for example. It only needs to success to pull MLO reliably and anything further can be done there in an upgradeable way. yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the feedback from linux/SD card users. would you be able to come up with a short list of fixes that have been done? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Pandaboard is / x-loader flow and official branch
Dechesne, Nicolas wrote: On Thu, Jun 30, 2011 at 9:24 AM, Vladimir Pantelic vlado...@gmail.com mailto:vlado...@gmail.com wrote: would you be able to come up with a short list of fixes that have been done? the notable problem fixed in OMAP4 vs OMAP3 boot code is related to how the ROM code will read the FAT table. in OMAP3 if you keep replacing the MLO/uboot/uimage (whether you cp or mv to it) after a while (~10 iterations, iirc) the ROM code will not be able to locate MLO anymore, and you need to reformat the card. this problem is fixed on OMAP4. there might be other things, but this one was really the biggest issue i think. thanks! also, note that the SD can be used as RAW instead of FAT, in which case you aren't going through the embedded FAT implementation and avoid such issues. sure, that's how we boot from emmc :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android libjpeg
Mandeep Kumar wrote: Hi All, I have done some benchmarking on OMAP4 running Ubuntu for various versions of libjpegs. Benchmarks were collected with modified version of djpeg that prints out ms time taken for decoding. Sample used for benchmarking is a 12MP image downloaded from a photography website. Here are the results: ... libjpeg-turbo trunk version that has NEON patches (5 runs). *http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/* * Decoding Time for Run 1: 1068 ms Decoding Time for Run 2: 1065 ms Decoding Time for Run 3: 1093 ms Decoding Time for Run 4: 1066 ms Decoding Time for Run 5: 1067 ms *Median Decoding Time: 1067 ms* One remark: a 12MP image decoded in 1076ms equals ~12MP/s decoding speed. decoding a 640x480 MJPEG file on a 1GHz OMAP4 using libavcodec gives me an average decoding time per frame of ~10ms which yields: 640x480/10ms = ~30MP/s so roughly 2.5 times faster. Either I am doing something wrong or this libjpeg-turbo is not so turbo. Regards, Vladimir ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android libjpeg
On 06/24/2011 08:13 PM, Woodruff, Richard wrote: This suggests to me that a simple drop-in of libjpeg-turbo might be actually easy to do, and that there is probably a significant performance benefit to be achieved. One thing to keep in mind is that this code still supports armv6, so we'd probably want to preserve that. You have to be a little careful as ARM did drop some bad NEON errata in A9 which require care to work around. Some CPU versions are impacted while others are not, tanstaafl. AFAIK ARM has a tool that can scan object code for bad neon sequences, maybe they are willing to make that generally available? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
