[opensuse-arm] efika questions
Hello, I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AARM ). As I have an EFIKA MX and helped to get some EFIKAs for developers, my questions relate to it: - what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...) - how are the EFIKAs used? - I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha/ Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA? I'll be an FSF Hungary conference this weekend, and would be nice to demo my smartbook with openSUSE running native :) Bye, CzP -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, Nov 08, 2011 at 03:23:46PM +0100, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help. Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AARM ). As I have an EFIKA MX and helped to get some EFIKAs for developers,
Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
- how are the EFIKAs used?
Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs. As far as the smarbooks go, one of them accompanied me to LinuxCon / ELC in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha/ Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA?
The last state I knew (just flew back in yesterday - was on the road for the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :).
I'll be an FSF Hungary conference this weekend, and would be nice to demo my smartbook with openSUSE running native :)
Just pull the same trick that I did on ELC: Run it in chroot with a separate X session :) (ubuntu) $ X -ac :1 $ for i in /dev /proc /sys /dev/pts; do mount --bind $i /suse/$i; done $ chroot /suse # export DISPLAY=:1 # wmaker tada~. You now have something that feels like a SUSE system despite running on an Ubuntu kernel. It's good enough for demoing right now IMHO :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, November 8, 2011 3:18 pm, Steve McIntyre wrote:
On Tue, Nov 08, 2011 at 03:23:46PM +0100, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
Can this please be considered? I assume this is also the best approach moving towards the 64bits armv8. http://www.arm.com/products/processors/technologies/instruction-set-architec...
Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, November 8, 2011 3:18 pm, Steve McIntyre wrote:
On Tue, Nov 08, 2011 at 03:23:46PM +0100, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
Steve, does this mean that if we would use the videodrivers taken from the Efika MX ARMHF image on page http://www.powerdeveloper.org/platforms/efikamx/linux ? That this wouldn't work because of arm-linux-gnueabi in stead of arm-linux-gnueabihf?
Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11/08/2011 03:18 PM, Steve McIntyre wrote:
On Tue, Nov 08, 2011 at 03:23:46PM +0100, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...) Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it. Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
I'm not sure what exactly you're referring to. IIRC RPM (at least last time we checked) ignored the gnueabi flag for the comparison. I haven't really dug into the problem myself too much though. Adrian and Dirk, do you remember what exactly the problems were we were facing? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Dienstag, 8. November 2011, 16:12:10 schrieb Alexander Graf:
On 11/08/2011 03:18 PM, Steve McIntyre wrote:
On Tue, Nov 08, 2011 at 03:23:46PM +0100, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
I'm not sure what exactly you're referring to. IIRC RPM (at least last time we checked) ignored the gnueabi flag for the comparison. I haven't really dug into the problem myself too much though.
Adrian and Dirk, do you remember what exactly the problems were we were facing?
I know there were a few checks explicit checking for gnueabi, but others did check for gnueabi*. However, only very few packages should be affected, so it would not be a problem to switch. Since do anyway build for "suse-linux-$arch" without the -gnu by default we would just need to change the affected packages. (we strip the -gnu also on other architectures which is not a arm decision but a generic SUSE one.)
Alex
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, Nov 08, 2011 at 04:12:10PM +0100, Alexander Graf wrote:
On 11/08/2011 03:18 PM, Steve McIntyre wrote:
On Tue, Nov 08, 2011 at 03:23:46PM +0100, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...) Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it. Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
I'm not sure what exactly you're referring to. IIRC RPM (at least last time we checked) ignored the gnueabi flag for the comparison. I haven't really dug into the problem myself too much though.
There's been a lot of discussion already between folks at RedHat/Fedora, Ubuntu, Debian, Meego etc. about how to make sure that we can get binaries working across ARM platforms. In the past, there has not been much of a push for this. But in future we're expecting that this is going to be more and more important, as we get more standardised platforms (e.g. for ARM servers) where people will expect to be able to distribute single binaries for all platforms. Think Java, or the binary OpenGL/GLES graphics drivers that the chip vendors provide. We're expecting that the standard 32-bit ARM ABI in the future is going to be hard-float, and using a common triplet to describe it is important. "arm-linux-gnueabihf" is what was agreed by lots of people back at Plumber's in September, and we're working on pushing that into upstream gcc too. There's more than just RPM to consider... :-)
Adrian and Dirk, do you remember what exactly the problems were we were facing?
Yup, please share! Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, Nov 08, 2011 at 04:10:30PM +0100, Joop Boonen wrote:
On Tue, November 8, 2011 3:18 pm, Steve McIntyre wrote:
Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
Steve, does this mean that if we would use the videodrivers taken from the Efika MX ARMHF image on page http://www.powerdeveloper.org/platforms/efikamx/linux ? That this wouldn't work because of arm-linux-gnueabi in stead of arm-linux-gnueabihf?
Potentially, yes. Konstantinos is the guy at Genesi working on those, so I'll let him respond - he'll know for sure. Added to CC above... :-) Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 8 November 2011 17:42, Steve McIntyre
On Tue, Nov 08, 2011 at 04:10:30PM +0100, Joop Boonen wrote:
On Tue, November 8, 2011 3:18 pm, Steve McIntyre wrote:
Please do *not* do stick with "arm-linux-gnueabi" if you're doing hard-float. It *will* cause you pain in the future if you ever care about cross-distro binary compatibility. The change in the ABI name is deliberate, and is there for a reason. If you have toolchain problems with it, please share them and you'll probably get help.
Steve, does this mean that if we would use the videodrivers taken from the Efika MX ARMHF image on page http://www.powerdeveloper.org/platforms/efikamx/linux ? That this wouldn't work because of arm-linux-gnueabi in stead of arm-linux-gnueabihf?
Potentially, yes. Konstantinos is the guy at Genesi working on those, so I'll let him respond - he'll know for sure. Added to CC above... :-)
Hi, well, mixing binaries built with different triplets is going to be tricky, it may work, as the ABI is the same, but I cannot guarantee you will have ABI stability or that they will run at all, esp with the dynamic linker expecting libs in /usr/lib/arm-linux-gnueabihf. I would still advise getting the same triplet as the rest of us have agreed upon (Debian, Ubuntu, Fedora). Fedora in fact will use -marm instead of -mthumb to minimise the build-failures (and they are a lot!). However, in the Debian BTS there is a big number of patches for armhf which you might find useful. Also have in mind I found and filed ~8 gcc ICE bug reports for armhf, which you may or may not have to tackle with yourselves in the future, regardless of the triplet. In short, one triplet to rule them all, one triplet to bind them, etc, etc. :) Regards Konstantinos -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tuesday 08 November 2011, Alexander Graf wrote:
Adrian and Dirk, do you remember what exactly the problems were we were facing?
we were unsure if we should build only the toolchain with that triplet or also set the default rpm target to -gnueabi. What exactly should be the toolchain triplet? arm-suse-linux-gnueabihf ? armv7-suse-linux-gnueabihf? The default rpm target we chose to leave at -suse-linux, as there is some weird triplet processing code in rpm that only checks for "-gnu" and nothing else, so we were quite sure that -gnueabi would already break / change the behavior. Thats why we have this inconsistency of building the toolchain with -gnueabi, but setting the default triplet to suse-linux (without any extension). we had quite some issues with the default "build platform" macros in rpm being defined wrongly/incompletly by default in rpm, which is why we first tried to get something running, and then fix the details later. you can see the problematic code here: http://www.google.de/codesearch#oOaobEEuy5M/pub/devil/devel/sources/1.2/rpm-4.0.4.tar.gz%7CZJw7mjoLboI/rpm-4.0.4/lib/rpmrc.c&exact_package=ftp://ftp.lmd.ens.fr/pub/devil/devel/sources/1.2/rpm-4.0.4.tar.gz&q=strcasecmp.co,&type=cs&l=1425 I don't mind switching it if we can get rpm fixed to properly handle the gnueabihf triplet and also initialize the platform target macros properly. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tuesday 08 November 2011, Peter Czanik wrote:
- how are the EFIKAs used?
All four (or 3 in practice) are currently connected to an suse internal copy of the Open Build Service system that rebuilds 1:1 openSUSE:Factory:ARM on native hardware without qemu. we use this for finding packages /build differences that trigger due to our usage of qemu. we can't connect them to the external build service yet due to policy restrictions (must not run code in chroot for OBS, as chroot is considered unsafe). looking at the options, we either have to set them up to build only "trusted" packages in the OBS (which requires a capability system that does not yet exist), or find a way to confine them further. Unfortunately one of the 4 machines is unstable and crashes every 3-4 hours hard. I had no success in finding the cause of that, as the identical setup works on the other machines just fine. I have no real HDMI capable monitor nor the ability to connect a serial console to it (or no time to dig out how to do that) so I don't know what the cause is. As only one of the 4 machines has this massive stability issue I suspect a hardware issue though. the other 3 machines are building happily along. I've connected external storage to them to have enough capacity for swapping and for build root setup, and it happily builds along around 200 packages in 24 hours. However, some of the bigger packages just fail due to OOm kills, as 512MB ram is not enough anymore for some of them , but the rest works almost as fast as the qemu based setup in OBS at the moment. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, Nov 08, 2011 at 06:03:27PM +0100, Dirk Müller wrote:
On Tuesday 08 November 2011, Alexander Graf wrote:
Adrian and Dirk, do you remember what exactly the problems were we were facing?
we were unsure if we should build only the toolchain with that triplet or also set the default rpm target to -gnueabi. What exactly should be the toolchain triplet? arm-suse-linux-gnueabihf ? armv7-suse-linux-gnueabihf?
The default rpm target we chose to leave at -suse-linux, as there is some weird triplet processing code in rpm that only checks for "-gnu" and nothing else, so we were quite sure that -gnueabi would already break / change the behavior. Thats why we have this inconsistency of building the toolchain with -gnueabi, but setting the default triplet to suse-linux (without any extension).
Hmmm. To me, that sounds like a bug in RPM then. But admittedly my background is Debian and I'm not an expert in RPM things. My suggestion would be to talk to the Fedora/RH folks and see what they're doing here. Consistency is good. :-) Jon Masters is one of the lead guys working on ARM there, and is probably a good person to ask, either directly or (even better) on the cross-distro@lists.linaro.org mailing list we've got set up for exactly this kind of discussion. </plug> Cheers, -- Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, November 8, 2011 2:31 pm, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AARM ). As I have an EFIKA MX and helped to get some EFIKAs for developers, my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
- how are the EFIKAs used?
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha/ Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA?
I'll be an FSF Hungary conference this weekend, and would be nice to demo my smartbook with openSUSE running native :)
You can try the following. This worked for me on the Pandaboard. Build the rootfs. According to Michals instructions, I used mic2 but the effect is the same. Take the armhf image from: http://www.powerdeveloper.org/platforms/efikamx/linux Use from this image /boot and /lib/modules and the video drivers (hopefully it's the same xorg version. (You can also compile the kernel yourself, that's what I did for te pandaboard) Copy all these into you're boot directory, or the other way around copy your rootfs on the sd card. Disable /etc/init.d (boot.udev, boot.rootfsck, boot.md) move them to another directory, as these processes When the system has booted start udev. For me this caused a high load. Then start network or whatever you need. You need to edit the sysconfig files yourself for this. Vim hasn't been build yet. Joe has, if you have knowledge of this editor. Via startx you can check if xwindows will work fine. It's best to start sshd first so you ca still access the system you can access it anymore via the keyboard. I've disabled udev soon after startx as it eats a lot of the cpu power. I used windowmaker as windomanager as I think this is the only one that has been build now.
Bye, CzP -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue, November 8, 2011 3:23 pm, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AARM ). As I have an EFIKA MX and helped to get some EFIKAs for developers,
Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
- how are the EFIKAs used?
Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs.
As far as the smarbooks go, one of them accompanied me to LinuxCon / ELC in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha/ Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA?
The last state I knew (just flew back in yesterday - was on the road for the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :).
Adrian, what is the status of the kiwi build? Can I help somehow as I have openSuSE running arm PandaBoard? I'm very keen to have Kiwi working as the mic2 and the chroot build options aren't what we want I think. My feeling, I might be wrong, is that if the PPC framework is used most will already work for arm.
I'll be an FSF Hungary conference this weekend, and would be nice to demo my smartbook with openSUSE running native :)
Just pull the same trick that I did on ELC: Run it in chroot with a separate X session :)
(ubuntu)
$ X -ac :1 $ for i in /dev /proc /sys /dev/pts; do mount --bind $i /suse/$i; done $ chroot /suse # export DISPLAY=:1 # wmaker
tada~. You now have something that feels like a SUSE system despite running on an Ubuntu kernel. It's good enough for demoing right now IMHO :)
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Mittwoch, 9. November 2011, 10:10:35 schrieb Joop Boonen:
On Tue, November 8, 2011 3:23 pm, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AA RM ). As I have an EFIKA MX and helped to get some EFIKAs for developers,
Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
- how are the EFIKAs used?
Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs.
As far as the smarbooks go, one of them accompanied me to LinuxCon / ELC in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha / Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA?
The last state I knew (just flew back in yesterday - was on the road for the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :).
Adrian, what is the status of the kiwi build?
I had no time for it so far, I need a kernel-default package first. Hopefully the current build will succeed. If someone wants to help, could someone package u-boot (the arm boot loader) ? I suppose it will be a pre-requirement for the kiwi support. bye adrian
Can I help somehow as I have openSuSE running arm PandaBoard? I'm very keen to have Kiwi working as the mic2 and the chroot build options aren't what we want I think. My feeling, I might be wrong, is that if the PPC framework is used most will already work for arm.
I'll be an FSF Hungary conference this weekend, and would be nice to demo my smartbook with openSUSE running native :)
Just pull the same trick that I did on ELC: Run it in chroot with a separate X session :)
(ubuntu)
$ X -ac :1 $ for i in /dev /proc /sys /dev/pts; do mount --bind $i /suse/$i; done $ chroot /suse # export DISPLAY=:1 # wmaker
tada~. You now have something that feels like a SUSE system despite running on an Ubuntu kernel. It's good enough for demoing right now IMHO
:)
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Regards,
Joop. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11/09/2011 12:26 PM, Adrian Schröter wrote:
On Tue, November 8, 2011 3:23 pm, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AA RM ). As I have an EFIKA MX and helped to get some EFIKAs for developers, Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...) Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
- how are the EFIKAs used? Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs.
As far as the smarbooks go, one of them accompanied me to LinuxCon / ELC in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha / Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA? The last state I knew (just flew back in yesterday - was on the road for the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :). Adrian, what is the status of the kiwi build? I had no time for it so far, I need a kernel-default package first. Hopefully
Am Mittwoch, 9. November 2011, 10:10:35 schrieb Joop Boonen: the current build will succeed.
If someone wants to help, could someone package u-boot (the arm boot loader) ? I suppose it will be a pre-requirement for the kiwi support.
We could also build an image that has to be "magically booted by someone else". That way we could leave out all the bootloader config and leave that up to the system's u-boot to do. Then it should be fairly simple to create an image using kiwi. Don't hold your hopes up to see this working with qemu-linux-user though :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed, November 9, 2011 12:26 pm, Adrian Schröter wrote:
Am Mittwoch, 9. November 2011, 10:10:35 schrieb Joop Boonen:
On Tue, November 8, 2011 3:23 pm, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AA RM ). As I have an EFIKA MX and helped to get some EFIKAs for developers,
Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
- how are the EFIKAs used?
Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs.
As far as the smarbooks go, one of them accompanied me to LinuxCon / ELC in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha / Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA?
The last state I knew (just flew back in yesterday - was on the road for the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :).
Adrian, what is the status of the kiwi build?
I had no time for it so far, I need a kernel-default package first.
Ok, then I'll start working on kiwi, this coming weekend. If I get something working how can I submit the diffs, to be reviewed?
Hopefully the current build will succeed.
If someone wants to help, could someone package u-boot (the arm boot loader) ? I suppose it will be a pre-requirement for the kiwi support.
U-boot has been build for the pandaboard. I used the meego version as a base. It still needs a bit of tuning. The package can be found here: home:worldcitizen:armv7l u-boot-omap4panda
bye adrian
Can I help somehow as I have openSuSE running arm PandaBoard? I'm very keen to have Kiwi working as the mic2 and the chroot build options aren't what we want I think. My feeling, I might be wrong, is that if the PPC framework is used most will already work for arm.
I'll be an FSF Hungary conference this weekend, and would be nice to demo my smartbook with openSUSE running native :)
Just pull the same trick that I did on ELC: Run it in chroot with a separate X session :)
(ubuntu)
$ X -ac :1 $ for i in /dev /proc /sys /dev/pts; do mount --bind $i /suse/$i; done $ chroot /suse # export DISPLAY=:1 # wmaker
tada~. You now have something that feels like a SUSE system despite running on an Ubuntu kernel. It's good enough for demoing right now IMHO
:)
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Regards,
Joop. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed, November 9, 2011 12:48 pm, Alexander Graf wrote:
On 11/09/2011 12:26 PM, Adrian Schröter wrote:
On Tue, November 8, 2011 3:23 pm, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is very good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFactory%3AA RM ). As I have an EFIKA MX and helped to get some EFIKAs for developers, Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...) Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a good reason to not use it.
- how are the EFIKAs used? Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs.
As far as the smarbooks go, one of them accompanied me to LinuxCon / ELC in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then-alpha / Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA? The last state I knew (just flew back in yesterday - was on the road for the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :). Adrian, what is the status of the kiwi build? I had no time for it so far, I need a kernel-default package first. Hopefully
Am Mittwoch, 9. November 2011, 10:10:35 schrieb Joop Boonen: the current build will succeed.
If someone wants to help, could someone package u-boot (the arm boot loader) ? I suppose it will be a pre-requirement for the kiwi support.
We could also build an image that has to be "magically booted by someone else". That way we could leave out all the bootloader config and leave that up to the system's u-boot to do.
MLO & u-boot can be build for the Panda board can be build according to the instruction below: http://elinux.org/Panda_How_to_MLO_%26_u-boot
Then it should be fairly simple to create an image using kiwi. Don't hold your hopes up to see this working with qemu-linux-user though :).
Alex
Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Mittwoch, 9. November 2011, 14:01:30 schrieb Joop Boonen:
On Wed, November 9, 2011 12:26 pm, Adrian Schröter wrote:
Am Mittwoch, 9. November 2011, 10:10:35 schrieb Joop Boonen:
On Tue, November 8, 2011 3:23 pm, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is
very
good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFacto ry%3AA RM ). As I have an EFIKA MX and helped to get some EFIKAs for
developers,
Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a
good
reason to not use it.
- how are the EFIKAs used?
Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs.
As far as the smarbooks go, one of them accompanied me to LinuxCon /
ELC
in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then -alpha / Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA?
The last state I knew (just flew back in yesterday - was on the road
for
the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :).
Adrian, what is the status of the kiwi build?
I had no time for it so far, I need a kernel-default package first.
Ok, then I'll start working on kiwi, this coming weekend. If I get something working how can I submit the diffs, to be reviewed?
best is to the kiwi developer mailing list. Or make a git pull request on github.com
Hopefully the current build will succeed.
If someone wants to help, could someone package u-boot (the arm boot loader) ? I suppose it will be a pre-requirement for the kiwi support.
U-boot has been build for the pandaboard. I used the meego version as a base. It still needs a bit of tuning. The package can be found here: home:worldcitizen:armv7l u-boot-omap4panda
please look for a devel project and submit to factory. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed, November 9, 2011 2:21 pm, Adrian Schröter wrote:
Am Mittwoch, 9. November 2011, 14:01:30 schrieb Joop Boonen:
On Wed, November 9, 2011 12:26 pm, Adrian Schröter wrote:
Am Mittwoch, 9. November 2011, 10:10:35 schrieb Joop Boonen:
On Tue, November 8, 2011 3:23 pm, Alexander Graf wrote:
On 11/08/2011 02:31 PM, Peter Czanik wrote:
Hello,
I did not have Internet access for more than a week, and lost a bit track, what is going on with the openSUSE ARM port. What I see is
very
good news: over 3000 packages build already ( https://build.opensuse.org/project/show?project=openSUSE%3AFacto ry%3AA RM ). As I have an EFIKA MX and helped to get some EFIKAs for
developers,
Yes, thanks a lot for that!
my questions relate to it:
- what triplet is used to compile hardfloat binaries? In the archives I found: "Currently we're building with -march=armv7-a -mfloat-abi=hard -mfpu=vfp3-d16 -mthumb." Is it still the case? (I was asked by Debian ARM HF project lead last week...)
Yes, we're using the common ground here. However, our triplet is "gnueabi" instead of "gnueabihf" at the last position because a lot of parts in our toolchain break with gnueabihf and we haven't found a
good
reason to not use it.
- how are the EFIKAs used?
Currently the two smarttop ones are building the same repo internally using chroot (we can't use chroot in publicly available nodes :( security prevails) to basically give us a good overview on which packages are broken because of qemu and which ones are actual package bugs.
As far as the smarbooks go, one of them accompanied me to LinuxCon /
ELC
in Prague and got demoed to quite a bunch of people showing openSUSE running on ARM :).
- I have openSUSE running in a chroot on my smartbook, thanks to http://michal.hrusecky.net/2011/10/opensuse-arm-chroot-less-then -alpha / Is there already an image which could be booted directly? Or instructions how to install it natively on the EFIKA?
The last state I knew (just flew back in yesterday - was on the road
for
the past 3 weeks) was that Adrian was looking at getting kiwi to work with ARM. At that point we could just build images :).
Adrian, what is the status of the kiwi build?
I had no time for it so far, I need a kernel-default package first.
Ok, then I'll start working on kiwi, this coming weekend. If I get something working how can I submit the diffs, to be reviewed?
best is to the kiwi developer mailing list. Or make a git pull request on github.com
I didn't get to this was working on the kernel. Hopefully I can fix this issues with this one soon. I have an usb issue, that I need to fix. ( home:worldcitizen:armv7l kernel-omap4panda ) After that I'll start working on kiwi.
Hopefully the current build will succeed.
If someone wants to help, could someone package u-boot (the arm boot loader) ? I suppose it will be a pre-requirement for the kiwi support.
U-boot has been build for the pandaboard. I used the meego version as a base. It still needs a bit of tuning. The package can be found here: home:worldcitizen:armv7l u-boot-omap4panda
please look for a devel project and submit to factory.
I've submitted both x-loader-omap4panda and u-boot-omap4panda to Base:System . (request id 91227 and request id 91228) I've tested both of them on my PandaBoard.
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, 2011-11-14 at 09:14 +0100, Joop Boonen wrote:
I didn't get to this was working on the kernel. Hopefully I can fix this issues with this one soon. I have an usb issue, that I need to fix. ( home:worldcitizen:armv7l kernel-omap4panda )
I've submitted a patch to the kernel team that builds the following kernels for 3.1: omap2plus, imx51 and tegra. Let me know if you need anything from that to help with u-boot etc.
After that I'll start working on kiwi.
Hopefully the current build will succeed.
If someone wants to help, could someone package u-boot (the arm boot loader) ? I suppose it will be a pre-requirement for the kiwi support.
U-boot has been build for the pandaboard. I used the meego version as a base. It still needs a bit of tuning. The package can be found here: home:worldcitizen:armv7l u-boot-omap4panda
please look for a devel project and submit to factory.
I've submitted both x-loader-omap4panda and u-boot-omap4panda to Base:System . (request id 91227 and request id 91228) I've tested both of them on my PandaBoard.
Would it be possible to re-name the packages to fall in line with the kernels being built? For OMAP it is omap2plus, as per the config. This should support all omap2plus devices, including the Beagle and Panda. Regards, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, November 14, 2011 10:09 am, Andrew Wafaa wrote:
On Mon, 2011-11-14 at 09:14 +0100, Joop Boonen wrote:
I didn't get to this was working on the kernel. Hopefully I can fix this issues with this one soon. I have an usb issue, that I need to fix. ( home:worldcitizen:armv7l kernel-omap4panda )
I've submitted a patch to the kernel team that builds the following kernels for 3.1: omap2plus, imx51 and tegra. Let me know if you need anything from that to help with u-boot etc.
Does this patch give a prompt in the tty's? I've build the terminal according to http://elinux.org/PandaBoard this didn't give a prompt in the tty. For me the only working kernel is the one according to: http://wiki.meego.com/ARM/OMAP4_Panda#kernel
After that I'll start working on kiwi.
Hopefully the current build will succeed.
If someone wants to help, could someone package u-boot (the arm
boot
loader) ? I suppose it will be a pre-requirement for the kiwi support.
U-boot has been build for the pandaboard. I used the meego version as a base. It still needs a bit of tuning. The package can be found here: home:worldcitizen:armv7l u-boot-omap4panda
please look for a devel project and submit to factory.
I've submitted both x-loader-omap4panda and u-boot-omap4panda to Base:System . (request id 91227 and request id 91228) I've tested both of them on my PandaBoard.
Would it be possible to re-name the packages to fall in line with the kernels being built? For OMAP it is omap2plus, as per the config. This should support all omap2plus devices, including the Beagle and Panda.
That's OK. I can rename it. I won't be able to test it on a BeagleBoard.
Regards,
Andy
-- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (9)
-
Adrian Schröter -
Alexander Graf -
Andrew Wafaa -
Dirk Müller -
Joop Boonen -
Joop Boonen -
Konstantinos Margaritis -
Peter Czanik -
Steve McIntyre