openSUSE ARM November 2013

arm@lists.opensuse.org

14 participants
15 discussions

[opensuse-arm] Latest 13.1 JeOS image for Chromebook broken

by Daniel Bischof

Hi, the image openSUSE-13.1-ARM-JeOS-chromebook.armv7l-1.12.1-Build15.1 from [1] is broken. It does not even show a bootloader prompt or something, the Chromebook just falls back to the white screen (the one that expects Ctrl-U to boot from SD). Something I could try? [1] http://download.opensuse.org/repositories/devel:/ARM:/13.1:/Contrib:/Chrome… Best regards, --D.B. -- Daniel Bischof <suse-bugz(a)bischof.org> -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years

[opensuse-arm] 13.1 & neon?

by Michal Hrusecky

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

7 years

[opensuse-arm] OpenSUSE 13.1 for armv7 upgrade

by G. Heim

Hi all, OpenSUSE 13.1 for PC just came out. I understood that there will be an armv7 version. Is that correct? And if so, when and where can I find it? What is the (preferably easy) way to upgrade my existing 12.3 to 13.1 (by not reinstalling everything)? Thanks. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years, 1 month

[opensuse-arm] u-boot 2013.04 fixed for pandaboard

by Guillaume Gardet

Hi Dirk, Hi Alex, I managed to fix OMAP4 pandaboard MLO (u-boot SPL). Please accept SR#207990 to Base:System project and copypac it 13.1:Ports It tried to boot in raw mode, instead of FAT/EXT2 mode for OMAP4 boards. We still need to update to 2013.10 more or less quickly to fully support Device Tree, but we could start with this one for now. I also updated u-boot to 2013.10 locally but I am missing sunxi patch for 2013.10. Dirk, where did you get this patch? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years, 1 month

[opensuse-arm] Move to Device Tree

by Guillaume Gardet

Hi, As you may know all ARM boards support should move more or less quickly to Device Tree. Upstream folder for DTB files is /boot/dtb/ (and not /boot/ as it is currently the case for some of our boards, such as Arndale). So we have to modify that. I will submit a patch for JeOS image later but we need to add or fix some packages first. For beagle and panda, the DTB packages are currently in Base:System project only. So we need to copy them to 13.1:Ports. (I have no right to do it, Dirk or Alex, could you do it, please?) Moreover, we need to update u-boot ASAP because: * current u-boot is not able to choose which DTB to load depending on board version (beagle original or beagle xM - panda, panda A4 or panda ES). * current panda MLO (u-boot SPL) is broken * We have the last kernel before omap4 (panda) boards are only DT. (done in 3.12, we are in 3.11.* for openSUSE 13.1). We can switch Arndale DTB to dtb-source package as it is done for beagle and panda (support already included). (I have no right to do it, Dirk or Alex, could you do it, please?) I cannot find where is the DTB for chromebook. I have also added support for chromebook DTB in dtb-source package if needed. If needed I can add support for more DT packages for other boards in dtb-source package. If you have any comment, please share. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years, 2 months

[opensuse-arm] [RFC] kernel-default armv7 config update/fix

by Guillaume Gardet

Hi, I already sent a patch to opensuse-kernel ML to set CONFIG_GPIO_TWL4030 as built-in (instead of module). It is a requirement to boot on SD card on beagleboard xM. See: http://lists.opensuse.org/opensuse-kernel/2013-11/msg00028.html But it is not merged. I will send a ping. In attachment, you will find a patch to: * Add USB PHY support (needed to get USB and Ethernet working on beagle and panda) * Add CONFIG_PINCTRL_SINGLE=y to be able to use Device tree (at least for beagle and pandaboard) * Add ARM SoC sound support * Add SPI bus support * Add user-space access to I2C and SPI * Switch DRM omap from built-in to module to ease debug (it does not work at all ATM!) Please comment. Most of the changes were present in previous config (at least old omap2plus config). No idea why it have not been kept/re-added before. If nobody object in the next days, I will submit it to opensuse-kernel ML for inclusion. We need to get bootable images for beagle and panda ASAP. Guillaume

7 years, 2 months

RE: [opensuse-arm] OpenSUSE 13.1 for armv7 upgrade

by G. Heim

Thanks for your reply again. I tried to upgrade as follows and it failed. 1. I changed the repository to http://download.opensuse.org/ports/armv7hl/distribution/13.1/repo/oss/ (and removed the old repositories) 2. I did "zypper dup" 3. then about 576 packages needed to be upgraded, etc 4. it downloaded all these packages 5. it installed 23 packages 6. then it failed. This is the log ("rtas" is my hostname): ( 21/845) Installing: xbitmaps-1.1.1-9.1.1 ...............................[done] ( 22/845) Installing: yast2-trans-stats-2.19.0-14.1.3 ....................[done] ( 23/845) Installing: glibc-2.18-4.4.1 ...................................[done] Additional rpm output: /usr/sbin/glibc_post_upgrade: While trying to execute /usr/sbin/iconvconfig child terminated abnormally warning: %post(glibc-2.18-4.4.1.armv7hl) scriptlet failed, exit status 115 ( 24/845) Installing: libgcc_s1-4.8.1_20130909-3.2.7 ....................[error] Installation of libgcc_s1-4.8.1_20130909-3.2.7 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: Command was killed by signal 4 (Illegal instruction). Abort, retry, ignore? [a/r/i] (a): r ( 24/845) Installing: libgcc_s1-4.8.1_20130909-3.2.7 ....................[error] Installation of libgcc_s1-4.8.1_20130909-3.2.7 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: Command was killed by signal 4 (Illegal instruction). Abort, retry, ignore? [a/r/i] (a): a Problem occured during or after installation or removal of packages: Installation aborted by user Please see the above error message for a hint. There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs. rtas:~ # zypper ps Check failed: Executing 'lsof' failed (132). rtas:~ # zypper dup Illegal instruction rtas:~ # Any hints how to continue? Thanks a lot. > -------- Oorspronkelijk bericht -------- > Onderwerp: Re: [opensuse-arm] OpenSUSE 13.1 for armv7 upgrade > Le 19/11/2013 15:52, G. Heim a écrit : >> Thanks for your quick answer. I have a mirabox and I suppose the standard kernel won't work anyway (it took me quite some time to get a running kernel when I installed OpenSUSE 12.3). > > Our kernel-default should work if you pass a valid device tree for the mirabox. > >> >> I already made an image of my SD card, thanks for the hint. >> >>> So, you could upgrade the software in your rootfs, but not the kernel ATM. >> So that means the rootfs for OpenSUS 13.1 is already available? Where can I get it and how do I upgrade? > > Yes and no. > > I mean you can do a "zypper dup" using 13.1 repos: > http://download.opensuse.org/ports/armv7hl/distribution/13.1/repo/oss/ > > Otherwise, the 13.1 rootfs is available here: > http://download.opensuse.org/ports/armv7hl/distribution/13.1/appliances/?C=… > Grab the latest armv7 rootfs tbz file. > > Please tell us if all is ok once updated. > > Guillaume > > > >> >> Thanks again. >> >> ---------------------------------------- >>> Date: Tue, 19 Nov 2013 14:29:18 +0100 >>> From: guillaume.gardet(a)free.fr >>> To: heelgeheim(a)hotmail.com; opensuse-arm(a)opensuse.org >>> Subject: Re: [opensuse-arm] OpenSUSE 13.1 for armv7 upgrade >>> >>> Hi, >>> >>> Le 19/11/2013 14:13, G. Heim a écrit : >>>> Hi all, >>>> >>>> OpenSUSE 13.1 for PC just came out. I understood that there will be an armv7 version. Is that correct? And if so, when and where can I find it? >>> Currently, our ARM images are not ready. >>> What is your board? >>> >>>> What is the (preferably easy) way to upgrade my existing 12.3 to 13.1 (by not reinstalling everything)? >>> I would recommand to backup your system (make an image of your SD card) to restore it if things goes wrong. >>> >>> Moreover, kernel for 13.1 is not good ATM (does not boot on beagleboard and pandaboard, at least). >>> >>> So, you could upgrade the software in your rootfs, but not the kernel ATM. >>> >>> >>> Guillaume >>> >>> >>>> Thanks. -- >>>> To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org >>>> To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org >>>> >>>> >>> > > -- > To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years, 2 months

[opensuse-arm] openSUSE 13.1 beagle and panda images status

by Guillaume Gardet

Hi, here are some tests results of 13.1 images. Results are pretty bad ATM. :( * Beagleboard xM rev B : - Image fails to boot with the following error message: ******************************************************************************** [ 8.109588] Freeing unused kernel memory: 532K (c07e5000 - c086a000) setterm: cannot (un)set powersave mode: Inappropriate ioctl for device /usr/sbin/klogconsole Thu Nov 7 00:00:00 UTC 2013 [ 13.670684] ehci-omap ehci-omap.0: Can't get PHY device for port 1: -6 [ 15.271728] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [437097081.923981] Including oem partition info file [437097082.043030] Searching for boot device... [ 16.471771] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 17.671752] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 18.925598] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 18.933227] hub 1-0:1.0: unable to enumerate USB device on port 1 [437097110.607544] Failed to find boot device ! [437097110.639527] rebootException: reboot in 120 sec... ******************************************************************************** The USB problem seems to be known: http://www.spinics.net/lists/linux-omap/msg90670.html Is boot problem related? I do not know. D6 and D7 lights (related to MMC) are turned OFF when kernel start whereas it was ON with u-boot. So, MMC seems to be not working at all. It seems that kernel modules (at least omap mmc modules) from initrd are not loaded. Very strange. * Pandaboard rev A3 : - Image hangs early with the following message: (Tested with 2 SD cards). ******************************************************************************** U-Boot SPL 2013.04 (Oct 21 2013 - 22:37:21) OMAP4430 ES2.2 OMAP SD/MMC: 0 ******************************************************************************** Is there anyone who could test those images on their baords, especially pandaboard? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years, 2 months

[opensuse-arm] Re: [obs submit-request 206130] openSUSE:13.1:Ports/JeOS: created by Guillaume_G

by Alexander Graf

Cool, thanks a lot for thd patch! See a few comments inline. Am 11.11.2013 um 05:18 schrieb <hermes(a)opensuse.org>: > > > home:Guillaume_G:branches:openSUSE:13.1:Ports/JeOS -> openSUSE:13.1:Ports/JeOS > > > https://build.opensuse.org/request/show/206130 > > Description: * Various fixes: > - rename loadfdt (already used differently upstream) in should_load_fdt > - rename usefdt in should_use_fdt > - Undef $bootpart before using it in for loop otherwise var is not updated (bug or feature?) > > ++++++ uboot-image-arndale-setup > --- uboot-image-arndale-setup > +++ uboot-image-arndale-setup > @@ -64,7 +64,7 @@ > # mkinitrd to point to the kernel and initrd in order > # to support kernel updates > # ---- > - kernel=uImage > + kernel=zImage Don't we need uImages at all anymore? That change is not documented in the description btw :). > initrd=initrd > > # gather kernel command line > @@ -100,7 +100,7 @@ > case $flavor in > highbank) > bootdevs=scsi > - usefdt=1 > + should_use_fdt=1 > setdev=1 > # Highbank's u-boot already prepends 0x to the file size > sizeprefix= > @@ -114,30 +114,30 @@ > boottype=bootm > kerneladdr=0x48000000 > ramdiskaddr=0x43100000 > - loadfdt=1 > - fdt=$flavor.bin > + should_load_fdt=1 > + fdtfile=$flavor.bin > fdt_addr=0x43000000 > ;; > > loco) > - usefdt=1 > - loadfdt=1 > + should_use_fdt=1 > + should_load_fdt=1 > units="0 1" > - fdt=imx53-qsb.dtb > + fdtfile=imx53-qsb.dtb > ;; > arndale) > boottype=bootm > - usefdt=1 > - loadfdt=1 > - fdt=exynos5250-arndale.dtb > + should_use_fdt=1 > + should_load_fdt=1 > + fdtfile=exynos5250-arndale.dtb > fdt_addr=0x44000000 > ;; > chromebook) > bootdevs="mmc usb" > bootparts='${unit}:2' > - usefdt=1 > - loadfdt=1 > - fdt=exynos5250-snow.dtb > + should_use_fdt=1 > + should_load_fdt=1 > + fdtfile=exynos5250-snow.dtb > ;; > esac > > @@ -150,9 +150,9 @@ > fdt_high=0xffffffff > > # copy bash variables into boot script > -for variable in kernel initrd fdt flavor target bootargs bootdevs bootparts \ > - initrd_high fdt_high boottype kerneladdr ramdiskaddr usefdt \ > - loadfdt fdt_addr setdev units sizeprefix; do > +for variable in kernel initrd fdtfile flavor target bootargs bootdevs bootparts \ > + initrd_high fdt_high boottype kerneladdr ramdiskaddr should_use_fdt \ > + should_load_fdt fdt_addr setdev units sizeprefix; do > value=$(eval "echo $(echo \$$variable)") > # only set variables that contain data, leave the others alone > if [ "$value" ]; then > @@ -165,18 +165,18 @@ > printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r} > setenv load_kernel 'ext2load ${bootdev} ${bootpart} ${kerneladdr} ${kernel}' > setenv load_initrd 'ext2load ${bootdev} ${bootpart} ${ramdiskaddr} ${initrd}; setenv rd_filesize ${sizeprefix}${filesize}' > - if itest 1${loadfdt} == 11; then > - setenv load_fdt 'ext2load ${bootdev} ${bootpart} ${fdt_addr} ${fdt}' > + if itest 1${should_load_fdt} == 11; then This makes sense > + setenv should_load_fdt 'ext2load ${bootdev} ${bootpart} ${fdt_addr} ${fdtfile}' Here the should is a misnomer, sorry. It should rather be 'do_load_fdt' ir something similar, as the contents of that variable are going to be executed later. We should give it a name that makes its function obvious. Sorry for misguiding you on it earlier. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years, 2 months

[opensuse-arm] Arndale 13.1 image status

by Guillaume Gardet

Hi, JeOS arndale image is broken ATM. * boot.scr script is looking for in the root of the partition instead of boot/ folder. => Will be fixed with SR #206887 * DTB is in boot/ folder of partition 2, not in partition 1. => Part of SR # 206890 * Once the above 2 problems fixed, kernel-exynos does not boot at all. hanging after: ********************************************************************** Starting kernel ... Uncompressing Linux... done, booting the kernel. ********************************************************************** Maybe a wrong load address is used for uImage. Is there any reason to not using a zImage here? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

7 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM November 2013