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
Hello,
This weekend I've had the opportunity to test openSUSE on a prototype of
CZ.NIC's Indiegogo-funded Turris Omnia router [1].
In a FOSDEM 2016 talk a prototype had already been shown to the public,
whereas this was the first time we could peek at the current software
environment of a running prototype ourselves and provide some early
third-party distro feedback to its creators.
Known for being overly critical and aiming at perfect solutions, let me
say in advance that the Armada 385 mainline kernel support looks quite
good already, needing only the Turris Omnia Device Tree [2] apparently.
Turris Omnia's U-Boot [3] is quite usable but will need a little more
love before we can benefit from new features such as UEFI boot support
(both upstream where it's not yet using the distro defaults [4] and
downstream for deriving a clean new turris_omnia_defconfig).
I'm confident that most of the functional limitations I observed can be
fixed until the final board version ships to backers.
That said, here's a quick how-to I would've added to the Wiki [1] if it
let me...
== Manual installation ==
As of 2016-03-18, the prototype's U-Boot does not yet support XHCI, so
that the two USB ports cannot be used for booting.
That leaves eMMC and mSATA as local boot options.
=== Building an upstream kernel ===
Use mvebu_v7_defconfig and enable CONFIG_BTRFS_FS.
=== Installation to USB ===
As of 2016-03-18, the prototype's U-Boot does not yet support XHCI and
therefore does not recognize any USB devices on either of the two USB ports.
Still you can place your rootfs onto USB.
As of 2016-03-18, the prototype's kernel has USB drivers built as
modules and no initrd, so you cannot directly boot a USB rootfs with it.
An easy solution is to build an upstream kernel yourself with those
drivers built-in and to copy it to the eMMC's /boot directory (e.g.,
zImage-next).
Note: In linux-next.git next-20160318 kernel only USB 3.0 devices work.
Partition your USB disk with GPT or MBR. Create a partition for the
rootfs and extract an
[http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl…
openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-Current.tbz] tarball.
Then boot similar to this (derived from bootargs and mmcboot variables):
setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=ext4
rootwait rw'
btrload mmc 0 0x01000000 boot/zImage-next @
btrload mmc 0 0x02000000 boot/dtb @
bootz 0x01000000 - 0x02000000
Note: As always, "/dev/sda1" is unsafe as it may become, e.g., /dev/sdb1
when an mSATA SSD or a second USB storage device is connected.
You could save those commands in a U-Boot environment variable,
otherwise you will need to re-type them on each boot.
=== Installation to mSATA ===
Unless you have another device with mSATA port, you may find it
difficult to set up the SSD.
As of 2016-03-18, the prototype's OpenWrt kernel did not recognize a
Samsung SSD 850 EVO 120 GB mSATA card (while U-Boot's scsi scan does).
As workaround you can compile an upstream kernel (cf.
[[#Building_an_upstrea_kernel|above]]), copy it under a new name to
/boot on the eMMC (e.g., zImage-next) and boot OpenWrt with this new
kernel (derived from mmcboot variable):
btrload mmc 0 0x01000000 boot/zImage-next @
btrload mmc 0 0x02000000 boot/dtb @
bootz 0x01000000 - 0x02000000
Now that you have a /dev/sda device for the mSATA SSD, you may find that
OpenWrt does not come with parted, fdisk or gdisk tools for partitioning
this device.
One solution is to boot into openSUSE Tumbleweed, where you can easily
install those tools, from USB (cf. [[#Installation_to_USB|above]]):
setenv bootargs 'console=ttyS0,115200 root=/dev/sdb1 rootfstype=ext4
rootwait rw'
btrload mmc 0 0x01000000 boot/zImage-next @
btrload mmc 0 0x02000000 boot/dtb @
bootz 0x01000000 - 0x02000000
>From inside openSUSE verify that /dev/sda is your mSATA card and
partition it using gdisk (zypper in gptfdisk). Format your new partition
and extract a JeOS rootfs tarball. For now just copy zImage-next and dtb
over.
mount /dev/sda1 /mnt
tar xvjf
[http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl…
openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz] -C /mnt
cp /boot/zImage-next /mnt/boot/zImage-next
cp /boot/dtb /mnt/boot/armada-385-turris-omnia.dtb
ln -sf zImage-next /mnt/boot/zImage
ln -sf armada-385-turris-omnia.dtb /mnt/boot/dtb
Boot similar to this:
setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs
rootwait rw'
setenv fdtfile armada-385-turris-omnia.dtb
scsi scan
btrload scsi 0:1 0x01000000 boot/zImage-next
btrload scsi 0:1 0x02000000 boot/dtb/$fdtfile
bootz 0x01000000 - 0x02000000
It's beginning to look much more like openSUSE, just lacking an openSUSE
kernel still.
=== Installation to eMMC ===
In theory you can also replace OpenWrt with openSUSE, optionally backing
it up as btrfs snapshot.
To do so you'll need to boot from some other root device such as USB or
mSATA.
mount /dev/mmcblk0p1 /mnt
btrfs subvolume snapshot /mnt/@ /mnt/root-pre-opensuse
rm -rf /mnt/@/*
tar xvjf
[http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl…
openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz] -C /mnt/@
cp /boot/zImage-next /mnt/@/boot/zImage-next
cp /boot/dtb /mnt/(a)/boot/armada-385-turris-omnia.dtb
ln -sf zImage-next /mnt/@/boot/zImage
ln -sf armada-385-turris-omnia.dtb /mnt/@/boot/dtb
Then on next boot you should boot into openSUSE automatically.
=== openSUSE kernel ===
Unlike mvebu_v7_defconfig, the openSUSE kernels build drivers as modules
whenever possible.
To boot you will need additional driver modules in a ramdisk.
There's two easy ways to create such an initrd file. Either use Kiwi (as
done for our JeOS SD card images) or boot into the system once without
modules and have the initrd be created by dracut. If you zypper up or
zypper dup the system for the first time, chances are a new
kernel-default package gets installed and generates an initrd; you can
force this the easy way by reinstalling the package (zypper in -f
kernel-default) or figure out the lengthy dracut command line. Try to
boot it like this:
setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs
rootwait rw'
scsi scan
btrload scsi 0:1 0x01000000 boot/zImage
btrload scsi 0:1 0x02000000 boot/dtb/armada-385-turris-omnia.dtb
btrload scsi 0:1 0x03000000 boot/initrd
bootz 0x01000000 0x03000000:$filesize 0x02000000
This resulted in:
Kernel image @ 0x1000000 [ 0x000000 - 0x6f2d78 ]
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
''To be investigated - U-Boot lacking CONFIG_SUPPORT_RAW_INITRD?''
This is blocking creation of a JeOS disk image.
Cheers,
Andreas
[1] https://en.opensuse.org/HCL:Turris_Omnia
[2]
https://gitlab.labs.nic.cz/turris/openwrt/tree/test/target/linux/mvebu/file…
[3] https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/commits/omnia
[4]
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/db-88f6820-gp.h;h…
--
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
Hello all!
I'm testing openSUSE (and SLES) on ARM64 servers and I ran into an issue with the default DT integrated into the UEFI of my server (this problem is investigated by Matthias Brugger). To workaround my problem, I had to load a custom DT using the 'devicetree' option of grub2. But the main problem is that I didn't find a way to add it properly in the grub.cfg file without hacking the file (which is very bad)!
So, I've made a small patch to add a new option called GRUB_DEVICETREE_FILE in /etc/default/grub file. I also compiled a new grub2 version with this patch and tested it successfully on my servers (https://build.opensuse.org/package/show/home:ldevulde:branches:Base:System/…).
I opened a bug/fate on the official grub bugtracker (https://savannah.gnu.org/bugs/?48358) but it seems to have low activity...
I plan to submit my change to the official openSUSE grub2 version but it could interesting to have some feedback before :-)
PS: I know that a 'dtb' option exists in the kernel for loading a custom DT from efi but I wasn't able to make it work. And I think it's easier and more cleaner to use the grub2 option.
Regards,
Loic
Hello,
With help from Matwey we finally have armv7hl kernels in Kernel:HEAD
again. Here are some mixed test results of 4.7.0-rc6-4.g3146576:
Jetson TK1:
* lpae works but only with Tumbleweed kernel-firmware, oops otherwise
* 4.6.2-1-lpae boots okay with dtb-tegra124 4.7.rc6
Cubietruck:
* lpae broken, no output
* 4.6.2-1-lpae boots with dtb-sun7i 4.7.rc6
* Only boot.scr works, no output with GRUB (u-boot-cubietruck 2016.05)
Raspberry Pi 2:
* default and lpae broken, no output
* 4.6.2-1-default boots with dtb-bcm2836 4.7.rc6 (-lpae known broken)
Raspberry Pi:
* default boots fine, except for some deadbeef vc4 error
* 4.6.2-1-default boots with dtb-bcm2835 4.7.rc6
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
Hi,
As discussed briefly at the openSUSE conference, I recently worked on a
project[1] which made use of the Cubietruck Tumbleweed JeOS image. The
image itself works very well, but I had to rebuild the kernel to include
USB device/gadget support, via:
CONFIG_USB_MUSB_DUAL_ROLE=y
CONFIG_USB_MUSB_SUNXI=m
CONFIG_USB_F_MASS_STORAGE=m
Alex mentioned that it should be possible to enable this support for
openSUSE ARM kernels.
- Are there any objections to this?
- if not, which branches / configs should I target with the pull
request?
Cheers, David
1. Cubietruck USB storage gadget project
http://blog.elastocloud.org/2015/12/ceph-usb-storage-gateway.html
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
> On 20 Jul 2016, at 09:29, Matwey V. Kornilov <matwey(a)opensuse.org> wrote:
>
>
>
> 18.07.2016, 11:15, "Guillaume Gardet" <guillaume.gardet(a)free.fr>:
>> Le 18/07/2016 à 09:55, Guillaume GARDET a écrit :
>>
>> Le 17/07/2016 à 05:12, Andreas Färber a écrit :
>> Am 11.07.2016 um 02:17 schrieb Andreas Färber:
>> Here are some mixed test results of 4.7.0-rc6-4.g3146576:
>> Updates for kernel 4.7.0-rc6-5.gcc11143 / U-Boot 2016.07:
>>
>> Jetson TK1:
>> * lpae works but only with Tumbleweed kernel-firmware, oops otherwise
>> * lpae works with either kernel-firmware
>> * udev-induced oops still happens, but with some patience recovers
>> http://paste.opensuse.org/ddbac180 <http://paste.opensuse.org/ddbac180>
>> * U-Boot 2016.07 works
>>
>> * 4.6.2-1-lpae boots okay with dtb-tegra124 4.7.rc6
>>
>> Cubietruck:
>> * lpae broken, no output
>> * lpae and default still broken
>>
>> * 4.6.2-1-lpae boots with dtb-sun7i 4.7.rc6
>> * Only boot.scr works, no output with GRUB (u-boot-cubietruck 2016.05)
>> * U-Boot 2016.07 still boots with boot.scr only
>>
>>
>> Raspberry Pi 3:
>> * U-Boot 2016.07 works
>>
>> Raspberry Pi 2:
>> * default and lpae broken, no output
>> * default and lpae still broken
>>
>> * 4.6.2-1-default boots with dtb-bcm2836 4.7.rc6 (-lpae known broken)
>> * U-Boot 2016.07 works
>>
>> Raspberry Pi:
>> * default boots fine, except for some deadbeef vc4 error
>> * default still boots
>>
>> * 4.6.2-1-default boots with dtb-bcm2835 4.7.rc6
>> * U-Boot 2016.07 works
>>
>>
>> BeagleBone Black:
>> * default boots fine
>> * 4.6.2-1-default does _not_ boot with dtb-am335x 4.7.rc6:
>> "irq 22: nobody cared" triggered by udev / omap_aes
>> * u-boot-am335xevm 2016.07 _broken_: stuck after "DRAM: 512 MiB",
>> reboots continuously (watchdog?); reverting to 2016.05 fixes
>>
>> You could try u-boot-am335xboneblack and/or upstream version.
>> If upstream version is broken, please report it upstream.
>>
>> A quick test shows that :
>> * upstream u-boot-am335xboneblack : boots on Beagle Bone Black
>> * upstream u-boot-am335xevm : is broken on Beagle Bone Black
>>
>
> Don't they differ only in config?
Yes, as do all targets :). I think the main difference (and reason for breakage) is that evm is trying to read from NAND.
Either way, I see little reason to not switch to the beaglebone u-boot target. Could someone please verify that this one works correctly (read: does more than just boot)? Then I’ll switch the package inclusion in JeOS.
Alex
Hi,
I tested latest Chromebook image (openSUSE-Tumbleweed-ARM-LXQT-chromebook.armv7l-2016.07.15-Build1.1.raw.xz)
First boot is ok except that X server segfault and I only get a console.
Xorg errors are the following:
********************************************************************************
[ 44.713] (II) ARMSOC(0): [DRI2] DRI driver: armsoc
[ 44.713] (==) ARMSOC(0): Backing store enabled
[ 44.713] (==) ARMSOC(0): Silken mouse enabled
[ 44.713] (II) ARMSOC(0): HW cursor init()
[ 44.713] (EE) ARMSOC(0): ERROR: Failed driver-specific cursor initialization
[ 44.722] (WW) depth 32 FB unsupported : falling back to depth 24
[ 44.731] (EE) ARMSOC(0): ERROR: Failed to add framebuffer to the scanout buffer
[ 44.750] (EE) ARMSOC(0): ERROR: xf86SetDesiredModes() failed!
[ 44.750] (EE) ARMSOC(0): ERROR: ARMSOCEnterVT() failed!
[ 44.750] (EE)
[ 44.750] (EE) Backtrace:
[ 44.751] (EE) 0: /usr/bin/X (xorg_backtrace+0x40) [0x1aeed8]
[ 44.751] (EE) 1: /usr/bin/X (0x10000+0x1a3d08) [0x1b3d08]
[ 44.751] (EE) 2: /lib/libc.so.6 (__default_rt_sa_restorer+0x0) [0xb697a090]
[ 44.751] (EE) 3: /usr/bin/X (0x10000+0x56078) [0x66078]
[ 44.751] (EE) 4: /usr/bin/X (AddScreen+0x14c) [0x46964]
[ 44.751] (EE) 5: /usr/bin/X (InitOutput+0x3dc) [0x8eb40]
[ 44.752] (EE) 6: /usr/bin/X (0x10000+0x3a5bc) [0x4a5bc]
[ 44.752] (EE) 7: /lib/libc.so.6 (__libc_start_main+0x120) [0xb6961d64]
[ 44.752] (EE)
[ 44.752] (EE) Segmentation fault at address 0x200
[ 44.752] (EE)
Fatal server error:
[ 44.752] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 44.752] (EE)
[ 44.752] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 44.752] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 44.752] (EE)
[ 45.038] (EE) Server terminated with error (1). Closing log file.
********************************************************************************
Moreover, 2nd boot is broken. I need to manually enable bootflag on partition 2:
parted $diskname set 2 boot on
and do the CGPT magic:
cgpt add -t kernel -i 1 -S 1 -T 5 -P 10 -l U-BOOT $diskname
Once done, I can boot again on my SD card, but I get lots of "max77686-rtc: RTC cannot handle the year 1970" messages.
I guess we need to update preCallInit.sh or installUBoot.sh?
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I'm trying to use qemu/kvm to run virtual machines on my aarch64 machine
(SoftIron Overdrive 3000) running Leap42.1 but I'm running into problems
at every turn. I'm not an expert, and don't understand well enough to
debug.
Can anybody who has successfully run VMs give me an example command
line, or at least some idea what approach I should be using?
thanks much,
-david
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi All
I am looking for xrdp package on my Pi3.
Could you tell me where xrdp package is.
Regards.
Ryo
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
