- openSUSE ARM

[opensuse-arm] gcj and 12.2 status
by Alexander Graf 28 Jul '12

28 Jul '12

Hi guys, Here's a short update from the last couple weeks / days on recent decisions we made quickly, to get things rolling. 1) There is now an openSUSE:12.2:ARM branch. That branch is currently in bootstrap and will probably be stuck there for the next weeks. 2) We used to build everything with thumb2 code. We still do for Factory, but bumped 12.2 to legacy arm code. Now for some more detail on the respective items. --- openSUSE 12.2 --- We need to get a 12.2 release out. People don't want to play with a factory build that can break every day. They usually don't even do that on x86 which gets tested a lot more than the ARM builds :). So we figured, we should have a full 12.2 build available as soon as possible. We probably won't get all our ARM special fixes in for the release, so we're currently working on a solution to keep our ARM base open to change, while still maintaining update compatibility, so that we get all the glorious 12.2 hardening for all the non-ARM-specific issues. Stay tuned for details :). --- gcj and thumb --- After a pretty tough debugging marathon, we finally found out last night that gcj miscompiles its hash map implementation (which is java code that gets compiled to assembly) when using thumb. Funnily enough neither Debian nor Fedora build with thumb as their default. Because neither Dirk nor me felt like digging into the full build process of gcj (which takes > 8h) to boil it down to a specific instruction that gets misplaced and it was already Friday, we concluded that we do: * default to non-thumb (-marm) for the 12.2 build, so we don't accidentally hit bugs other distros haven't hit either * build gcj with -marm in Factory, until we figured out what the problem is We will write a full summary of what we did and what exactly we debugged things down to in a bug report against gcc, so that the upstream/Linaro folks don't need to go through the same tedious debugging as us. --- Once we're through that, we should have a working java stack everywhere. I'm also thrilled to see how many build failures we'll have left on 12.2 after all the thumb introduced issues are evaporated :). Have a nice weekend! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] llvm build
by Alexander Graf 24 Jul '12

24 Jul '12

Hi Adrian, Something looks weird in the llvm build. I'm getting an assert during compilation: [22708s] /emul/x86_64-for-arm//usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.7/../../../../armv7hl-suse-linux-gnueabi/bin/ld: BFD (GNU Binutils; openSUSE Factory) 2.22 assertion fail ../../bfd/elf32-arm.c:11477 which points to this source line: 11473 /* If the input has no requirement about FP hardware, do 11474 nothing. */ 11475 else if (in_attr[i].i == 0) 11476 { 11477 BFD_ASSERT (in_attr[Tag_ABI_HardFP_use].i == 0); So for some reason the compiler generated softfp code, but the linker thinks it should he hardfp instead? Does the resulting binary work? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

[opensuse-arm] O-DroidX For ARM Dev
by Manu Gupta 24 Jul '12

24 Jul '12

Hi All, thanks for the lot of info you have given me. On Further investigating I came across this board ODROID-X http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G13399… Seems like a good choice to me but would like second opinions too. 1. It has a cortex A-9 which is armv7 2. It has video out ( so I can connect to my laptop ) 3. Its cheaper than most. (129 USD ) 4. Its based on exynos, so maybe it can be extended to origen too. I am stressing on the video out, because the laptop is the only video output device which I have..other than my phone. I had questions like - 1. Difference between board bringups and working on top layers too. I could not fully understand that part. Thanks a lot.. Regards Manu -- Regards Manu Gupta -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

[opensuse-arm] BeagleBone for openSUSE ARM
by Manu Gupta 19 Jul '12

19 Jul '12

Hi All, I have been looking on the internet for a ARM board. My current budget for an ARM board is 100 Euros / 6000 INR. While going through the net, I came across BeagleBone http://beagleboard.org/bone Can you guys have a look at it and suggest me if its a okaish choice. Is there anything else that you can suggest me under the same range. One more question I had was, if I buy this board Can I connect it to my Laptop's LCD as I cannot afford anything over and above the above price range. Suggestions are welcome. Thanks a lot -- Regards Manu Gupta -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 9

[opensuse-arm] Using Trello
by Andrew Wafaa 19 Jul '12

19 Jul '12

Aloha all, After a discussion this morning I've set up a Trello board [0] to try and help everyone track the goings on, and help focus our efforts. The board is publicly viewable (or at least should be), and have sent of member invites (sorry if you didn't want the invite) so people can actually part take in the fun. If you haven't received an invite and require one, please let me know. Regards, Andy 0 - https://trello.com/board/opensuse-on-arm/5007cfc12cf0ae352e21d8dc -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] Regular sync meeting
by Alexander Graf 17 Jul '12

17 Jul '12

Hi folks, First off, thanks a lot for your contributions, help and all the other awesomeness you have been doing. We are what makes openSUSE on ARM possible. Never forget that :). And because we are so many people who do different things, we some times need to coordinate to know which direction we want to walk towards as a whole and to make sure we don't waste time in duplicated efforts. So I would like to propose that we hold a regular phone meeting, open to everyone who wants to join, to discuss current affairs of openSUSE for ARM, roadmaps, timelines, etc. When would work for people? Who would be in? Is it easier for folks to do it during working or non-working hours? Would you prefer weekly, bi-weekly, monthly, irregular? Looking forward to a bunch of constructive replies :) Alex-- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 8

[opensuse-arm] Hackable hardware?
by Will Stephenson 16 Jul '12

16 Jul '12

I'm thinking about playing with openSUSE on ARM. Do you have any recommendations which hardware would be suitable? Preferably a tablet so I have something shiny to promote the effort with? Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

3 2

[opensuse-arm] How to not do upstream
by Alexander Graf 13 Jul '12

13 Jul '12

Hi Andrew, openSUSE fellows, While trying to get a stable working base on at least a single SoC family (OMAP), I've stumbled over a bunch of issues, all of which are frustrating of their own, but are driving me insane in combination. OMAP graphics ============== There are 2 competing implementations for graphics on OMAP. Well, actually 3: * omapfb (open source kernel+xorg, no xrandr, limited ) * omapdrm (open source kernel part, open source Xorg part, can piggy-bag on closed source driver for EXA) * pvr (closed source) So what's the big deal with the situation as is? Well, omapfb is reasonably fast, but doesn't work in 3.4. It did work in 3.2. Also mode setting doesn't work with it. It also renders everything in software, so it doesn't use the graphics hardware. Omapdrm is a nice future facing technology that is still in staging upstream, so I can overlook the fact that I needed a bunch of patches to actually make it work at all. It does its mode setting job reasonably well given the early state of development. Funnily enough it seems to not exploit the hardware completely on OMAP3, since omapfb can do 1080p there while omapdrm can not. Oh well. Also, Rob has been very helpful to get me going with the open source parts, so kudos to him! The omapdrm Xorg driver however is crawlingly slow. It takes _seconds_ to move a window in xfce when running on 1080p. So we have an awesome kernel+user space bundle that could do most of the things users want (2d, easy mode setting), but is basically useless, since it's unbearable to work with. Has anyone ever tried to work with it? The omapdrm driver has a special hack to piggy bag on the pvr driver when it's installed. So you can install the pvr driver and get accelerated graphics. Well, tough luck of you don't work for Canonical (or Linaro which is apparently Canonical in disguise), because they only release Ubuntu binary .debs that _link directly against Xorg. How could you possibly design binary drivers any worse? Every time the ABI changes in Xorg, the driver doesn't work. Different compiler flags potentially break it too. Since openSUSE has an Xorg ABI version of 12 and current Ubuntu which the TI folks build against is 11, we're out of luck. No acceleration for us. But then again, acceleration would also only be there for OMAP4, because OMAP3 drivers are compiled for soft float only. What a mad world. As to running the pvr driver directly, I can't comment either, thanks to the above facts. Pandaboard ES ============== So far, I was always under the impression that TI was a reasonably good citizen when it comes to keeping things open source and in a working state there. They have their code in upstream Linux and in upstream u-boot. Or do they? Apparently to run Linux on the OMAP4460 SoC, you basically have to have VCC logic in the kernel which simply isn't upstream yet. So using an upstream kernel, you can basically not use the Pandaboard ES which does use that SoC. Isn't that insane? That board is publicly available for more than 1/2 year now! I haven't tried yet, but at least u-boot support is supposed to be synchronized between the pandas by now. That's at least some good news. Pandaboard ============== Our pandaboards ended up being reasonably unstable. Some times they were able to endure for weeks without crashing, some times only for hours. Thanks to some hints on IRC I finally updated u-boot to have updated voltage controls. Apparently there are 2 ways to do voltage control: * statically in firmware * dynamically in the OS You always want the static one in firmware to work right to get you going. But eventually it's nice to have voltage control in the OS as well, right? Especially when firmware's initial settings weren't all as optimal as you might expect, which isn't unheard of in the firmware world. Well, turns out there is a Ubuntu kernel that has voltage control. Upstream doesn't. Again, the same problem as for the ES, just that it hit me on non-ES boards this time. At least updating u-boot got me a stable board. Hooray. Beagleboard ============== This is my favorite. After updating u-boot to get panda boards stable, suddenly my beagle board wouldn't boot anymore. It'd crash randomly, some times just freeze seconds after the boot. The only variable here is the boot loader. Does anyone even test upstream code? I mean, seriously. I tried u-boot 2012.04 and 2012.07-rc1 now with the same 3.4 kernel that worked just fine before on the older Linaro u-boot snapshot we had. Both show very similar crashes, so it's probably an issue that has never been addressed. So I went into the #beagle IRC channel to ask for help. Unlike the #pandaboard channel where people actually ended up being helpful, all I got was: [3:13pm] <aholler> use 3.2.x [3:16pm] <aholler> everything above is broken on the beagleboard, at least here. Are you kidding me? There's a user in the IRC channel who reports that upstream completely breaks for him. There wasn't even any objection to that comment, so I assume more people have had issues there. I'm also quite sure that if I'm having issues with upstream u-boot + upstream kernel that this is not because of any special environment I might have. It's most likely because upstream is simply not working. Is TI even supporting upstream sources or is it just a nuisance to get off the table so merging with Linaro and Ubuntu trees is easier? This is certainly not a way to foster a community and puts a lot of work on _our_ table which really should be in the SoC vendors' and specifically Linaro's hands. Annoyed, Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 5

[opensuse-arm] imx51 image
by Peter Czanik 13 Jul '12

13 Jul '12

Hello, A few days ago I read on IRC, that the old Genesi kernel is being transformed into a proper rpm package. Question: could this kernel be used in the imx51 image instead of the "official" kernel? The advantage is having all hw components supported, most notably graphics, and that there is an up-to-date image to get started. The image without graphics support is a no go for most users, so currently one can only use the image from http://lizards.opensuse.org/2012/01/21/opensuse-arm-image/ and update it, which is a kind of difficult, especially since the armv7l -> armv7hl change... Bye, CzP -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 6

[opensuse-arm] Re: Ответ: Re: java-1_6_0-openjdk xprop build requires
by Michal Vyskocil 12 Jul '12

12 Jul '12

On Tue, Jul 10, 2012 at 09:46:13PM +0200, Dinar Valeev wrote: > Hi, > It seems Fedora downgraded to hs22 on non standrard architectures. > http://pkgs.fedoraproject.org/gitweb/?p=java-1.7.0-openjdk.git;a=commit;h= > 52082f611bef945585a70f9e08ab181e3761b077 Hallo Dinar, I will preffer to not to touch spec file. @adrian: do you have any hint how we can handle that? I was thinking about making the java-1_7_0-openjdk.zero package, which will be a branch or a link of older revision of java-1_7_0-openjdk. Then arm and powerpc projects will link this package instead of java-1_7_0-openjdk. Do you think if that's reasonable approach? Regards Michal Vyskocil > > Dinar > > >>> Michal Vyskocil <mvyskocil(a)suse.cz> 09.07.12 11:51 >>> > On Sat, Jul 07, 2012 at 05:55:58PM +0200, Dinar Valeev wrote: > > sent SR 127353 > > > > I've tried to build 1.7 java using fixed 1.6 but it fails the same way ARM > guys > > has recently. > > http://lists.opensuse.org/opensuse-arm/2012-06/msg00120.html > > > > But it's weird. Now arm fails differently and the don't have mentioned patch > > applied. > > Hallo Dinar, > > I'm very sorry, but according upstream guys, recent icedtea does not > build with zero, so we do not have openjdk7 for those platforms. I'll > ask people on opensuse-arm (with you in CC) for a solution. > > Regards > Michal Vyskocil >

2 3