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
Hi All,
over the last few days I've been pretty busy with enabling
pre-configured appliances for ARMv7 and AArch64 on openSUSE Leap 42.2,
and I'm happy to report that we now have some images available:
http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/appliance…http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliance…
As you can see its a pretty elaborative list of images, and I don't
have time to test all of them myself. so whoever is interested in
having some of those variants working for him, please try them out and
report both successes and failures. The overall goal is to announce
the ARM port end of next week (Dec 1st) so it would be great to have
some testing feedback before that (and << before that so that we can
maybe even fix it before announcement).
Thanks a lot in advance,
Dirk
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hey guys,
I recently started playing with connecting Raspberry Pi Hats and Arduino
Shields to boards and am wondering where/how to document this.
Hats may be compatible with multiple boards but may need board-specific
instructions for the device tree. I am therefore thinking that an
expansion-board-centric page with instructions for one or more boards
may be the best approach.
For ARM boards we are so far using the flat HCL namespace and a
Category:ARM_devices to group them. Should we do the same for shields
(HCL:Foo_Shield) and have another Category page to locate them?
Or should we have some two-level namespace like HCL:Arduino_Shield/Foo?
Another interesting question then is how would we generate a list of
compatible expansion boards pages on, say, HCL:Raspberry_Pi2? Would that
be possible if we had, e.g., Category:Raspberry_Pi_B+_Connector? Or
should we rather manually maintain such bidirectional links?
Any thoughts and suggestions appreciated.
Cheers,
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!
I tried the latest raspberry pi and pi2 images (armv6l-2016.1.15-Build57 resp.
armv7l-2016.11.15-Build5.9). Both fail on the second boot with the error
"ext4fs_devread read outside partition ...". Afterward it tries to boot from
TFTP.
Searching the net gives the suggestion, that the 64bit feature may be set
on the ext4 partition, so that U-Boot cannot boot. I have found a matching
opensuse bug report (boo#989284), too. But checking the partition with
dumpe2fs and haven't found this feature.
Are any hints how I can make the images work?
How can help to resolve this issue?
Here is the full log from the pi2:
> U-Boot 2016.09.01 (Oct 15 2016 - 11:25:48 +0000)
>
> DRAM: 880 MiB
> RPI 2 Model B (0xa01041)
> MMC: bcm2835_sdhci: 0
> reading uboot.env
>
> ** Unable to read "uboot.env" from mmc0:1 **
> Using default environment
>
> In: serial
> Out: lcd
> Err: lcd
> Net: Net Initialization Skipped
> No ethernet found.
> starting USB...
> USB0: Core Release: 2.80a
> scanning bus 0 for devices... 3 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
> scanning usb for ethernet devices... 1 Ethernet Device(s) found
> Hit any key to stop autoboot: 0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:2...
> Found U-Boot script /boot/boot.scr
> ext4fs_devread read outside partition 2225344
> ## Executing script at 02000000
> Wrong image format for "source" command
> SCRIPT FAILED: continuing...
> 11691 bytes read in 128 ms (88.9 KiB/s)
>
> USB device 0: unknown device
> Waiting for Ethernet connection... unable to connect.
> missing environment variable: pxeuuid
> missing environment variable: bootfile
Herbert
Hi ARM guys!
I think current openQA AArch64 tests are done using qemu (at least virtualization).
But, how far is ARM tests on real hardware? It seems os-autoinst support real hardware and I remember that some people worked on it during hackweeks.
I would like to collect all information in order to maybe work on it a bit. For example, which devices do you use to power on/off boards. Did you use os-autoinst or some other tests tools?
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
I did tests with images from the above site on:
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2016.11.15-Build7.
[4-6].raw.xz
All did show the Grub boot screen and continued, but stopped with a message on
my TV screen as in the attached photo.
--
fr.gr.
member openSUSE
Freek de Kruijf
I tried from http://download.opensuse.org/ports/aarch64/tumbleweed/images/
the image:
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3_aarch64.aarch64-2016.06.03-
Build4.1.raw.xz
This one does not boot at all. Not a single message on the screen.
Is there another image I should use on my RPi3?
Maybe openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2016.10.30-Build1.1.raw.xz ?
I do not need any desktop on that device, just some servers.
--
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
I tried the image openSUSE-Leap42.2-ARM-JeOS-
raspberrypi3_aarch64.aarch64-2016.11.09-Build3.2.raw.xz from
http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliance…
on my RPi3 and found one problem. It hangs when a USB drive is connected,
otherwise it works OK.
--
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