openSUSE ARM October 2015

arm@lists.opensuse.org

17 participants
20 discussions

[opensuse-arm] Attempt to run KIWI on unsupported architecture 'armv8l'

by Dirk Müller

Hi, this is a known OBS bug, asked the admins to deploy a fix shortly. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 9 months

[opensuse-arm] New package for ARM: raspberrypi-firmware

by Andreas Färber

Hello, I have submitted the raspberrypi-firmware package for inclusion in Factory: https://build.opensuse.org/request/show/341314 This package contains VideoCore IV binaries that are read from a FAT partition by the Raspberry Pi boot ROM. Without these files neither the ARM U-Boot bootloader nor an ARM kernel can be booted on that device. It is not really needed on x86 systems, so as alternative we could submit it to openSUSE:Factory:ARM instead. However, since in the past some non-free binaries snuck into this package (disguised as SUSE-Firmware instead of SUSE-NonFree license and probably without obtaining permission first), I think it makes sense to have it go through the full legal review process of openSUSE:Factory. Similarly, I would like to split out arndale-bl1.img from u-boot package as arndale-firmware (a signed version of GPL'ed U-Boot Secondary Program Loader) and to submit odroid{,xu}-firmware at some point, possibly more. This will allow us to build JeOS images for boards with upstream U-Boot and upstream kernel support centrally in openSUSE:Factory:ARM rather than in some Contrib project. In particular my intent here is to drop the devel:ARM:Factory:Contrib:RaspberryPi:upstream project in favor of openSUSE:Factory:ARM. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (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

5 years, 1 month

[opensuse-arm] u-boot: bootmenu cmd

by Matwey V. Kornilov

Hello, Why bootmenu command is not used atm? Are there any reasons? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 2 months

[opensuse-arm] Tests of latest images for RPi1

by Freek de Kruijf

Build336.2 from repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi:/upstream/ boots, the SD is partitioned and the resulting system boots. However the Ethernet connection does not become active. The lights stay off. I could not find a method to list the journal on the SD partition on a system where the SD is mounted. Build325.2 from repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi/ does the low level boot, but after that, like before, can't find the boot image on the 3rd partition. Upgrading a system build earlier with a working image works OK. Finally the problem using the command "yast lan" is solved. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 2 months

[opensuse-arm] cuboxi tumbleweed images don't boot

by Thomas Bechtold

Hi, I tried to use the Tumbleweed images from [1] but the image does not boot. Here's the output during boot: U-Boot SPL 2013.10-rc4 (Oct 16 2015 - 05:16:01) Boot Device: SD1 spl: error reading image u-boot.img, err - -1 Load image from RAW... U-Boot 2013.10-rc4 (Oct 16 2015 - 05:16:01) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: MX6-CuBox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 mmc0 is current device 2762 bytes read in 34 ms (79.1 KiB/s) Running bootscript from mmc ... ## Executing script at 10800000 mmc0 is current device 7163544 bytes read in 492 ms (13.9 MiB/s) 49298053 bytes read in 2897 ms (16.2 MiB/s) ** File not found dtb/call_autodetectfdt ** Kernel image @ 0x10800100 [ 0x000000 - 0x6d4e98 ] ## Loading init Ramdisk from Legacy Image at 14800100 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 49297989 Bytes = 47 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree ** File not found /boot/boot.scr ** ** File not found /boot/uEnv.txt ** ** File not found /boot/zImage ** ** File not found /boot/uImage ** Booting from net ... FEC Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY FEC FEC Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY FEC FEC Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY FEC Booting uImage ## Booting kernel from Legacy Image at 10800000 ... Image Name: Boot-Script Image Type: ARM Linux Script (uncompressed) Data Size: 2698 Bytes = 2.6 KiB Load Address: 00000000 Entry Point: 00000000 Contents: Image 0: 2690 Bytes = 2.6 KiB Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! CuBox-i U-Boot > Evironment is: CuBox-i U-Boot > printenv autoboot=echo Booting ${boot_file}; if test ${boot_file} = zImage; then bootz ${loadaddr} ${ramdisk_addr} ${fdt_addr}; else bootm ${loadaddr} ${ramdisk_addr} ${fdt_addr}; fi; autodetectfdt=if test ${cpu} = 6SOLO || test ${cpu} = 6DL; then setenv fdt_prefix imx6dl; else setenv fdt_prefix imx6q; fi; if test ${board} = mx6-cubox-i; then setenv fdt_file ${fdt_prefix}-cubox-i.dtb; elif test ${board} = mx6-hummingboard; then setenv fdt_file ${fdt_prefix}- hummingboard.dtb; else setenv fdt_file ${fdt_prefix}-hummingboard2.dtb; fi; baudrate=115200 board=mx6-cubox-i boot_fdt=try boot_file=uImage boot_kernel=${boottype} ${kerneladdr} ${ramdiskaddr}:${rd_filesize} ${fdtaddr} boot_prefixes=/ /boot/ bootargs=console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=:,v3,tcp bootcmd=for bootdev in ${bootdevs}; do for unit in ${units}; do setenv bootpart; for bootpart in ${bootparts}; do setenv fix_bootpart "setenv bootpart $bootpart"; run fix_bootpart; run setdev; run doit; done; done; done bootdelay=3 bootdevs=mmc bootenv=uEnv.txt bootfile=uImage bootit=setenv boot_file ${bootfile}; if test -n ${ramdisk_file}; then if run loadramdisk; then echo Loaded ${ramdisk_file}; setenv ramdisk_addr ${ramdisk_addr}:0x${filesize}; else setenv ramdisk_addr -; fi; else setenv ramdisk_addr -; fi; if test ${boot_file} = zImage; then if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then echo Loaded ${fdt_file}; else setenv fdt_addr; if test ${boot_fdt} = try; then echo WARN: Cannot load the DTB and boot file is type zImage;echo if you have not appended a dtb to the file it may;echo hang after displaying Starting kernel...;echo ;else echo WARN: Cannot load the DT; fi; fi; else setenv fdt_addr; fi; else setenv fdt_addr; fi; run autoboot; bootpart=0:1 bootparts=${unit}:1 bootscript=echo Running bootscript from mmc ...; source; boottype=net console=ttymxc0 cpu=6Q doit=run load_splashfile; if run load_kernel; then; run load_initrd; run loadfdt; run boot_kernel; fi ethact=FEC ethaddr=d0:63:b4:00:66:05 ethprime=FEC fdt_file=imx6q-cubox-i.dtb fdt_high=0xffffffff fdt_prefix=imx6q fdtaddr=0x14700100 fdtfile=call_autodetectfdt fdtfolder=dtb file_prefix=/boot/ filesize=2f03a85 fix_bootpart=setenv bootpart ${unit}:1 flavor=cuboxi get_cmd=dhcp importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t ${loadaddr} ${filesize}; initrd=boot/initrd.uboot initrd_high=0xffffffff ip_dyn=yes kernel=boot/linux.vmx kerneladdr=0x10800100 load_initrd=${fs}load ${bootdev} ${bootpart} ${ramdiskaddr} ${initrd}; setenv rd_filesize ${sizeprefix}${filesize} load_kernel=${fs}load ${bootdev} ${bootpart} ${kerneladdr} ${kernel} load_splashfile= loadaddr=0x10800000 loadbootenv=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${file_prefix}${bootenv}; loadbootfile=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${file_prefix}${bootfile}; loadbootscript=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${file_prefix}${script}; loadfdt=${fs}load ${bootdev} ${bootpart} ${fdtaddr} ${fdtfolder}/${fdtfile} loadramdisk=if test ${boottype} = mmc; then load mmc ${mmcdev}:${mmcpart} ${ramdisk_addr} ${file_prefix}${ramdisk_file}; else ${get_cmd} ${ramdisk_addr} ${ramdisk_file}; fi; mmcargs=setenv bootargs quiet console=${console},${baudrate} root=${mmcroot}; mmcboot=echo Booting from mmc ...; run mmcargs; setenv boottype mmc; run bootit; mmcdev=0 mmcpart=1 mmcroot=/dev/mmcblk0p2 rootwait rw netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp; netboot=echo Booting from net ...; run netargs; setenv boottype net; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; if test ${bootfile} = auto; then setenv bootfile zImage; if ${get_cmd} ${bootfile}; then run bootit; else setenv bootfile uImage; fi; fi; ${get_cmd} ${bootfile}; run bootit; origbootfile=auto preboot=if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout serial,vga; setenv stderr serial,vga; else setenv stdin serial; setenv stdout serial; setenv stderr serial; fi; ramdisk=boot/initrd.uboot ramdisk_addr=- ramdisk_file=initrd ramdiskaddr=0x14800100 rd_filesize=0x2f03a85 script=boot.scr setdev=mmc dev ${unit} should_load_fdt=1 should_use_fdt=1 should_use_splashfile=0 sizeprefix=0x splashfile=opensuse.bmp splashpos=m,m stderr=serial stdin=serial stdout=serial target=firstboot units=0 update_sd_firmware=if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; if mmc dev ${mmcdev}; then if ${get_cmd} ${update_sd_firmware_filename}; then setexpr fw_sz ${filesize} / 0x200; setexpr fw_sz ${fw_sz} + 1; mmc write ${loadaddr} 0x2 ${fw_sz}; fi; fi; update_sd_firmware_filename=u-boot.imx Environment size: 4849/8188 bytes CuBox-i U-Boot > Comments how to solve this? Best, Tom [1] http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Cont rib:/IMX6/images/openSUSE-Tumbleweed-ARM-JeOS-cuboxi.armv7l.raw.xz -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 2 months

[opensuse-arm] Re: [opensuse-factory] Suse and Raspberry Pi Build

by Freek de Kruijf

Op woensdag 28 oktober 2015 11:31:53 schreef gm1mqe(a)aol.com: > This is GREAT! As soon as my HDMI cable arrives I will install it onto a Pi > 2 B+ and just have some fun. I had seen there were some ARM buids but was > not sure what to use. Do any problems go here or is there a specific ARM > forum? There is a special ARM mailing list: opensuse-arm(a)opensuse.org Subscribe via: opensuse-arm+subscribe(a)opensuse.org -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 2 months

[opensuse-arm] openSUSE on Raspberry B+/2 usable as a server?

by Johannes Kastl

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear opensuse-on-Raspi-Folks, I read the last couple of months of the mails on the opensuse-arm mailinglist, but I am not sure: Is openSUSE 13.x usable on a Raspberry B+ or 2? If I find one of the few images that are installing correctly, can I keep it up to date and secure without issues? (I am not talking about Tumbleweed, I'd prefer something less time consuming. And I do not mean I would take lots of manual intervention, its just lots and lots of updates and the occasional configuration change) Ideally this would mean 13.1 or 13.2 being usable, or maybe Leap is going to be usable. Anyone tried Leap yet? Thanks in advance for your input! Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlYgDfMACgkQzi3gQ/xETbJChQCeN/wgiXCfLio5jP3pG3iVqpsp C4sAn1d0VJW5KGj40ROlSQ7yVfc7Z4UQ =mMa1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 3 months

[opensuse-arm] Creating a coreboot based image

by Andrew Wafaa

Hi, I'm the proud owner of a delightful Asus C100P Chromebook Flip (veyron_minnie), and I'm hoping to create an image similar to the Series3 Samsung Chromebook. One of the big differences is that the Flip uses coreboot only and not u-boot, so I can't reasonably just copy what was done previously. So how am I supposed to go about it? Thanks, Andy -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 3 months

[opensuse-arm] Re: Factory:ARM publishing is disabled

by Dirk Müller

Hi, >> It's always disabled, because publishing happens via product building and >> testing. I just checked, we have recently published a new tree (a day ago) >> and have worked on openqa the last few days. >> Is there any particular problem that you're looking for? > I'm trying to build u-boot for udoo board (since it's very similar to > cuboxi, I'm using it as a base). I branched u-boot from Base:System in > home:ocurero:branches:Base:System and then I modified the templates to build > each flavour. However, I'm must be doing something wrong because all u-boot > packages I have are "blocked" for two days. Ah, that can happen, we just had a deep rebuild on Tumbleweed due to a toolchain update. sometimes this can take a few days until things get unblocked. if you want to not wait for blocking, change your prj meta for that repo to "block=local" Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 3 months

[opensuse-arm] sunxi GMAC disabled

by Frank Kunz

Hello, unfortunately the GMAC kernel configuration for Allwinner A20 and A31 devices is disabled in armv7l kernel 4.2. Therefore the A20 Olimex bards do not have network anymore. What needs to be done to get that enabled again: config DWMAC_SUNXI tristate "Allwinner GMAC support" default ARCH_SUNXI depends on OF ---help--- Support for Allwinner A20/A31 GMAC ethernet controllers. This selects Allwinner SoC glue layer support for the stmmac device driver. This driver is used for A20/A31 GMAC ethernet controller. Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 3 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM October 2015