January 2014 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] OBS certificate error
by Andreas Färber 08 Jan '14

08 Jan '14

Hi, Trying to build my new armv6hl kernel in OBS I get the following error: could not retrieve ssl certificate: 400 remote error: /usr/local/sbin/bssign 256 https://build.opensuse.org/package/live_build_log/home:a_faerber:branches:K… This was already visible during "scheduled" stage, now it's at "failed". Locally it continues building. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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] 13.1 images broken due to kiwi update?
by Guillaume Gardet 07 Jan '14

07 Jan '14

Hi Marcus, 13.1 ARM JeOS images do not boot anymore, because boot.scr and u-boot.bin are now in root folder and no more in boot/ folder. Did you make some changes to kiwi recently which could explain that? Is it a wanted behavior? If so, we should update our JeOS templates and SPL/u-boot paths accordingly. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 7

[opensuse-arm] Raspberry Pi status update
by Andreas Färber 07 Jan '14

07 Jan '14

Hi everyone, To start the New Year, I've tested the 13.1:Contrib JeOS-raspberrypi image. That one does not boot unless the "BOOT" FAT partition is resized, as Guillaume and Marcus discussed recently. I went on to test the Factory:Contrib JeOS-raspberrypi image (from osc getbinaries), and that one boots right out of the box. Yay! Still, either are rather useless since the ext4 root partition is too small for a `zypper dup`. Alex has therefore asked me to investigate booting via U-Boot, to be able to load kiwi's initrd. https://build.opensuse.org/request/show/212779 was necessary for JeOS-raspberrypi to load kernel and initrd from the FAT partition - accepted. A first u-boot-rpib fix to execute our boot.scr is waiting for review: https://build.opensuse.org/request/show/212778 (Question: Contrib:Factory:RaspberryPi u-boot-rpib looks like openSUSE:Factory:ARM u-boot-rpib but there is no _link - is that intentional?) Not sure yet if it makes a difference, but the path to cmdline.txt was obviously wrong since it didn't end up in the JeOS-raspberrypi image - waiting for review: https://build.opensuse.org/request/show/212860 If non-empty, this will affect also the default boot without U-Boot. U-Boot showed an error about setenv syntax visible. Inserting a printenv in the boot script I noticed that bootargs was missing. Turns out, U-Boot is configured to accept 8 command arguments only and setenv bootargs was trying to supply more than that. Single quotes fixed this, SR TBD. Whether using fdt or not, initrd or not, with kernel=u-boot.bin this is the furthest I have come: mmc0 is current device reading boot/linux.vmx 2616584 bytes read in 374 ms (6.7 MiB/s) reading boot/initrd.uboot 64897618 bytes read in 8628 ms (7.2 MiB/s) reading boot/dtb/bcm2835-rpi-b.dtb 7216 bytes read in 23 ms (305.7 KiB/s) Kernel image @ 0x1000000 [ 0x000000 - 0x27ed08 ] ## Loading init Ramdisk from Legacy Image at 02100000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 64897554 Bytes = 61.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02000000 Booting using the fdt blob at 0x2000000 Using Device Tree in place at 02000000, end 0x004c2f Starting kernel ... That's using the identical kernel that boots okay as kernel=zImage. Alex noticed that sometimes the LEDs would show activity on Ethernet after a bit, but I was unable to ssh onto the device, so I consider it rather unlikely that it's proceeding fine on UART but just having some HDMI console issue. The red PWR LED is lit but no activity on the green ACT LED. Comparison of /proc/cmdline with boot.script bootargs revealed that the Raspberry Pi bootloader is passing some additional arguments, including vc_mem.mem_base. Adding them to bootargs did not help. My .dtb file was extracted from a local (x86_64 host) build of home:algraf:branches:Base:System dtb-source's dtb-bcm2835.spec. https://build.opensuse.org/request/show/212777 When using a .dtb file, fdtaddr needs to be set. This either requires a line similar to kerneladdr to `setenv fdtaddr ${fdt_addr_r}` or be specified in our script - not sure which is preferred in this case, duplicating addresses into our script or outputting `printenv` errors to the user? Can someone with a TTL UART adapter please check if there's anything more on serial output that might give us a clue of what's wrong? Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 8

[opensuse-arm] AArch64 status?
by Andreas Färber 07 Jan '14

07 Jan '14

Hello, Alex B. has asked about debuginfos for aarch64 packages. According to Alex G. we only publish those for Factory. How are people supposed to work with aarch64 Factory these days? The latest instructions I found were for 12.3: http://en.opensuse.org/Portal:ARM/AArch64 For 13.1 it appears that there are only rootfs tarballs without further instructions? http://download.opensuse.org/ports/aarch64/distribution/13.1/appliances/ https://build.opensuse.org/project/show/openSUSE:13.1:Ports has no JeOS-vexpress64. NB: Similar to armv7hl, changing repository configuration from 12.3 to 13.1 requires changing to type=yast2 and using the following URL (without trailing suse/ subdirectory) in /etc/zypp/repos.d/*.repo file: http://download.opensuse.org/ports/aarch64/distribution/13.1/repo/oss/ However, I just got timeouts during `zypper ref` in the 12.3 image when it tried to download repository metadata from suse/setup/. For Factory:ARM there's JeOS-vexpress64 but no appliances get published: http://download.opensuse.org/ports/aarch64/factory/ Alex, you can try the .raw.xz from the heading of the description page: https://build.opensuse.org/package/binaries/openSUSE:Factory:ARM/JeOS-vexpr… Is the devel:ARM:AArch64:Factory project still in use? https://build.opensuse.org/project/show/devel:ARM:AArch64:Factory Doesn't build any images and is referenced from the Wiki page. Which package provides a .axf-format kernel for use with the Foundation Model? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] Re: [opensuse-factory] Re: Thanks for RPi port of openSUSE
by Andreas Färber 06 Jan '14

06 Jan '14

Hi, Am 06.01.2014 01:15, schrieb Jim Henderson: > Did you start with the image at http://www.zq1.de/~bernhard/linux/ > opensuse/ - or is there another image I should be looking at? You should please be looking at the official images on OBS: https://build.opensuse.org/project/show/devel:ARM:13.1:Contrib:RaspberryPi https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Raspberry… Similarly, thanks and questions are best directed to the opensuse-arm mailing list since several other contributors deserve credit, too (Marcus Schäfer, Guillaume Gardet, David Sterba, ..., plus the usual suspects Dirk Müller, Alexander Graf and Adrian Schröter) and may be able to help you more quickly. I just posted a status report there the other day [0] as part of our joint post-13.1 testing efforts: Apart from Kiwi not yet resizing the partition of the image during first boot, JeOS-raspberrypi image in Factory was looking pretty good now! There's also an XFCE-raspberrypi image defined (assuming FXCE was a typo?), but that package still has a few unresolved dependencies, such as Firefox. Larry, if you can help update the kernel-raspberrypi package in above :Factory:Contrib repository from 3.11 to your 3.12, that would probably be appreciated by other users! > The repo > this image uses is missing a few libraries, Jim, if you find libraries are missing, please mention which repo you are using and which library you are missing. You might be: ...using an outdated repository, ...facing soft-/hard-float or armv5/armv6 ABI RPM incompatibilities, ...experiencing failing package builds that no one has fixed yet, ...needing a library that's not yet packaged at all, ...needing a package where armv6hl builds have not been enabled yet, or any number of other reasons we can only guess without further info. Please understand that SUSE has no enterprise customers for the Raspberry Pi, so this work is dependent on individual contributions, with people like you hacking on this in their spare time. Testing new images and providing feedback to opensuse-arm as well as updating or adding Wiki pages [1] are easy ways for you to contribute. Keeping track of which packages are failing [2, 3] for what reasons is another, if you don't want to get your hands dirty and actually help with fixing or updating packages yourself yet. ;) Have a lot of fun, Andreas [0] http://lists.opensuse.org/opensuse-arm/2014-01/msg00008.html [1] http://en.opensuse.org/Portal:ARM [2] https://build.opensuse.org/project/monitor?utf8=%E2%9C%93&commit=Filter%3A&… [3] https://build.opensuse.org/project/monitor?utf8=%E2%9C%93&commit=Filter%3A&… -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 4

[opensuse-arm] 13.1 & neon?
by Michal Hrusecky 06 Jan '14

06 Jan '14

Hi, today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I ended up with invalid instruction errors just after update of glibc. My guess is that glibc was compiled with neon support enabled. Was there any decision to drop non-neon devices or is it simply a bug? Is it just glibc that has neon enabled or everything? I know that for 32bits we have two glibc packages, maybe something similar would be possible for armv7? -- Michal Hrusecky <Michal(a)Hrusecky.net> -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

6 23

[opensuse-arm] Cubieboard2 only boots the first time
by Oscar 04 Jan '14

04 Jan '14

Hi! After some tweaks I successfully build an image for Cubieboard2 board. Although everything works, after the first boot the u-boot script tries to load the kernel from a missing file (I suspect that during the initial setup, the kernel is renamed). This is how the /boot directory and /boot/boot.script looks __after__ the first boot: linux:~ # ll /boot total 15915 -rw-r--r-- 1 root root 0 Jan 1 2014 0x27259817 -rw-r--r-- 1 root root 1697039 Dec 31 00:13 System.map-3.4.75-86-sunxi lrwxrwxrwx 1 root root 1 Jan 1 01:00 boot -> . -rw-r--r-- 1 root root 1484 Feb 26 2013 boot.readme -rw-r--r-- 1 root root 1704 Jan 1 01:02 boot.scr -rw-r--r-- 1 root root 1632 Jan 1 2014 boot.script -rw-r--r-- 1 root root 95879 Dec 30 23:16 config-3.4.75-86-sunxi -rw-r--r-- 1 root root 45384 Dec 14 12:10 cubieboard2.bin lrwxrwxrwx 1 root root 22 Jan 1 2014 initrd -> initrd-3.4.75-86-sunxi -rw-r--r-- 1 root root 4191724 Jan 1 01:02 initrd-3.4.75-86-sunxi drwx------ 2 root root 12288 Jan 1 2014 lost+found -rw-r--r-- 1 root root 11 Jan 1 01:02 mbrid -rwxr-xr-x 1 root root 18432 Dec 10 21:52 sunxi-spl.bin -rw-r--r-- 1 root root 83294 Dec 31 00:20 symvers-3.4.75-86-sunxi.gz -rw-r--r-- 1 root root 239 Dec 31 00:20 sysctl.conf-3.4.75-86-sunxi -rw-r--r-- 1 root root 224780 Dec 10 21:52 u-boot.img lrwxrwxrwx 1 root root 22 Jan 1 2014 uImage -> uImage-3.4.75-86-sunxi -rw-r--r-- 1 root root 4446424 Dec 31 00:20 uImage-3.4.75-86-sunxi -rw-r--r-- 1 root root 5306522 Dec 31 00:14 vmlinux-3.4.75-86-sunxi.gz linux:~ # linux:~ # cat /boot/boot.script setenv ramdisk boot/initrd.uboot setenv kernel boot/linux.vmx setenv initrd_high "0xffffffff" setenv fdt_high "0xffffffff" setenv bootargs loader=uboot plymouth.enable=0 console=ttyS0,115200n8 showopts ${append} setenv kernel 'boot/linux.vmx' setenv initrd 'boot/initrd.uboot' setenv fdt 'cubieboard2.bin' setenv flavor 'cubieboard2' setenv target 'firstboot' setenv bootdevs 'mmc' setenv bootparts '${unit}:1' setenv initrd_high '0xffffffff' setenv fdt_high '0xffffffff' setenv boottype 'bootm' [..] Since there is no file named "linux.vmx", u-boot fails with the following error: Jumping to boot.scr ## Executing script at 44000000 kerneladdr=0x48000000 ramdiskaddr=0x43100000 mmc0 is current device ** File not found boot/linux.vmx ** Of course, the first boot works because the original image contains a file named linux.vmx and all the necessary files. u-boot script gets updated on the first boot? How is done in other boards? Thanks! -- Oscar C. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 1

Fwd: [opensuse-arm] 13.1 on BeagleBone Black
by Dirk Müller 03 Jan '14

03 Jan '14

Hi Matwey, > http://lists.opensuse.org/opensuse-packaging/2013-12/msg00099.html Cool, thanks for the update! I've created a JeOS for the beaglebone using your patches: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS-beaglebone Hopefully it will work. Let me know how testing goes :) Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

Re: [opensuse-arm] Booted openSUSE 13.1 on Beagle Bone Black
by Matwey V. Kornilov 02 Jan '14

02 Jan '14

2014/1/2 Alexjan Carraturo <axjslack(a)gmail.com>: > Hi Matwey > > I'm really curious to try the image for BeagleBone black. > > There is a link to download a tar.gz of this release (or loop)? http://download.opensuse.org/repositories/home:/matwey:/beaglebone/images_a… Remember, that you have to copy all files and dirs at first partition to /boot before booting (don't know where it should be fixed ;) ). You have to keep S2 switched during power-on to boot from external memory card. You need serial debug port, because there is YaST2 firstboot requiring interactive (setting time and passwords...). > I have already tried other file systems, one of which cross-compiled by me, > but I'd be happy to find some version that already has basic support for all > devices (in particular graphics acceleration and video decoder) do you know > if in the image openSUSE it's already all supported? Don't know yet, but would be nice if you could check. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2207@jabber.ru -- 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] kernel update for 13.1 ARM images
by Guillaume Gardet 02 Jan '14

02 Jan '14

Hi Dirk, Hi Alex, My patches are accepted in openSUSE GIT kernel repo so, we can get kernel update from Kernel:openSUSE-13.1 project to 13.1:Ports. Could you do it, please, since I have not the rights to proceed? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

6 21