Re: [opensuse-arm] Images for Raspberry Pi

[Ludwig Nussel]

Alexander Graf wrote:

On 21.12.15 11:03, Ludwig Nussel wrote:

Andreas Färber wrote:

[...]
=> Find ways to use openQA for more testing, e.g. serial only rather
than graphical testing with QEMU machines such as cubieboard. Maybe


IOW cubieboard can be emulated by qemu? Do you have a command line for
me? What host architecure is needed for that? Can the aarch64 worker we
have for openQA emulate that in reasonable speed?


So far we haven't managed to make AArch64 KVM work with full AArch32
only VMs. Also keep in mind that with KVM host cpu == guest cpu, so
you'd get a cubieboard with an A57 CPU - something nobody expects to see.


So x86_64 with emulation? Can you provide me with a qemu command
line to boot an image?


contribute to upstream efforts such as finally upstreaming Raspberry Pi
or Beagleboard emulations, to broaden the base to test against.

=> Use Wifi-enabled SD cards, USB gadget devices, HDMI framegrabbers,
JTAG adapters or other creative solutions to implement automated
hardware testing, avoiding some of the QEMU/KVM shortcomings.


That would be nice :-) The minimum requirement for openQA would be
control over the power switch and SD card and access to the serial port.
On the weekend I found this:
http://www.linuxinternals.org/blog/2014/06/04/a-microsd-card-remote-switcher/

Maybe that could be cheap solution to allow the openQA worker to get
the disk image on the target.


Yup, Linaro also has built similar adapters for their QA initiative.
Unfortunately my hardware skills aren't as great, so I doubt I could
actually solder this thing together ;). If you can find a way to get us
a dozen, we can start to make automated testing become reality.


Aren't there some hardware tinkerers on your floor? :-)

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Alex Armstrong]

Freek de Kruijf wrote:
> Op maandag 21 december 2015 04:27:40 schreef Andreas Färber:
>> Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:
>>> I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
>>> Build354.2 which shows a black screen and does not boot at all, same as
>>> the
>>> latest one from Staging, which is from a few days back.
>>>
>>> Currently there are no working Tumbleweed images for any of the Raspberry
>>> Pi systems. Is there anything I can do, apart from testing the latest
>>> images?
>> Yes.
>>
>> "Black screen" and "does not boot" do not help getting it fixed.
>> Buy yourself a cheap UART adapter (less than 4 EUR for 3.3 V!) and post
>> concrete error output if something is not working. A good report is half
>> the fix!
> Dear Andreas,
>
> Maybe I can find such a device, but I have no idea how to connect it to my 
> system to get some characters on a screen.
I am using the TTL - USB cable from Adafruit
(https://www.adafruit.com/products/954) and they have a tutorial on how
to use it (which helped me) here -
https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable.

Basically, connect the the data lines (white and green on mine) to pins
14 (TX) & 15 (RX) respectively (For RPi 1), and plug into a free USB
port.  Then open a terminal and use the command 'screen /dev/ttyUSB0
115200' (your USB number might be different) to start monitoring. 
Finally, power up your Pi in the normal manner.  You should see the boot
process scroll across the terminal.
> I restrict myself to getting all the images for the Raspberry Pi 1B and 2B 
> from http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/
>
> Should I use another source for the images.
This is a question I've had in the past too.  The wiki for RPi 1 only
lists repos for 13.1 & 13.2, nothing about latests builds.  The RPi 2
wiki talks about Tumbleweed, but not the others.  Andreas posted the
link for Tumbleweed earlier, saying it was becoming a more first-class
citizen.  If someone points to the other definitive repos for the RPi,
I'll update the wiki.

Best,
- A

--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Alexander Graf]

On 21.12.15 11:45, Ludwig Nussel wrote:
> Alexander Graf wrote:
>> On 21.12.15 11:03, Ludwig Nussel wrote:
>>> Andreas Färber wrote:
 [...]
 => Find ways to use openQA for more testing, e.g. serial only rather
 than graphical testing with QEMU machines such as cubieboard. Maybe
>>>
>>> IOW cubieboard can be emulated by qemu? Do you have a command line for
>>> me? What host architecure is needed for that? Can the aarch64 worker we
>>> have for openQA emulate that in reasonable speed?
>>
>> So far we haven't managed to make AArch64 KVM work with full AArch32
>> only VMs. Also keep in mind that with KVM host cpu == guest cpu, so
>> you'd get a cubieboard with an A57 CPU - something nobody expects to see.
> 
> So x86_64 with emulation? Can you provide me with a qemu command
> line to boot an image?

I haven't used the cubietruck on myself either yet :).

> 
 contribute to upstream efforts such as finally upstreaming Raspberry Pi
 or Beagleboard emulations, to broaden the base to test against.

 => Use Wifi-enabled SD cards, USB gadget devices, HDMI framegrabbers,
 JTAG adapters or other creative solutions to implement automated
 hardware testing, avoiding some of the QEMU/KVM shortcomings.
>>>
>>> That would be nice :-) The minimum requirement for openQA would be
>>> control over the power switch and SD card and access to the serial port.
>>> On the weekend I found this:
>>> http://www.linuxinternals.org/blog/2014/06/04/a-microsd-card-remote-switcher/
>>>
>>>
>>> Maybe that could be cheap solution to allow the openQA worker to get
>>> the disk image on the target.
>>
>> Yup, Linaro also has built similar adapters for their QA initiative.
>> Unfortunately my hardware skills aren't as great, so I doubt I could
>> actually solder this thing together ;). If you can find a way to get us
>> a dozen, we can start to make automated testing become reality.
> 
> Aren't there some hardware tinkerers on your floor? :-)

Yes, I guess I can ask them next year ;).


Alex
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Ludwig Nussel]

Andreas Färber wrote:

Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:

I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
Build354.2 which shows a black screen and does not boot at all, same as the
latest one from Staging, which is from a few days back.

Currently there are no working Tumbleweed images for any of the Raspberry Pi
systems. Is there anything I can do, apart from testing the latest images?


Yes.

"Black screen" and "does not boot" do not help getting it fixed.
Buy yourself a cheap UART adapter (less than 4 EUR for 3.3 V!) and post
concrete error output if something is not working. A good report is half
the fix!

Others have reported really trivial issues (like missing symlink/file)
that either you yourself could fix on your SD card or that someone
without access to that hardware can quickly fix in OBS if told what
issue there is.

There's some main sources of trouble:
[...]


Might be worth putting those hints in the wiki and linking it from every
HCL page. Esp the contrib ones.


3) Lack of automated QA: We inherit not just kernel updates but all
package updates, without having openQA based testing before publishing


So the images should have Factory in their names rather than Tumbleweed.


images. Factory submissions get build-tested only for x86 and ppc.
Further, limited OBS build workers for ARM do not always allow for
consistent rebuilds before publishing packages.

Most breakages are hardware-specific though, in some u-boot-foo package
or a specific kernel driver or depending on NEON availability that would
not show in a generic KVM guest - and only very few of the boards have a
matching QEMU emulation. Hardware-in-the-loop testing was an alternative
idea. Several projects around openQA had been investigated but only few
successfully completed.

=> Find ways to use openQA for more testing, e.g. serial only rather
than graphical testing with QEMU machines such as cubieboard. Maybe


IOW cubieboard can be emulated by qemu? Do you have a command line for
me? What host architecure is needed for that? Can the aarch64 worker we
have for openQA emulate that in reasonable speed?


contribute to upstream efforts such as finally upstreaming Raspberry Pi
or Beagleboard emulations, to broaden the base to test against.

=> Use Wifi-enabled SD cards, USB gadget devices, HDMI framegrabbers,
JTAG adapters or other creative solutions to implement automated
hardware testing, avoiding some of the QEMU/KVM shortcomings.


That would be nice :-) The minimum requirement for openQA would be
control over the power switch and SD card and access to the serial port.
On the weekend I found this:
http://www.linuxinternals.org/blog/2014/06/04/a-microsd-card-remote-switcher/
Maybe that could be cheap solution to allow the openQA worker to get
the disk image on the target.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi(2)

[Ludwig Nussel]

Andreas Färber wrote:

Am 20.12.2015 um 15:50 schrieb Ludwig Nussel:

Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:

I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
Build354.2 which shows a black screen and does not boot at all, same
as the
latest one from Staging, which is from a few days back.

Currently there are no working Tumbleweed images for any of the
Raspberry Pi
systems. Is there anything I can do, apart from testing the latest
images?


Same here. None of the available images work. The kernel seems to be
a patched copy of some kernel devel project state. Any chance to
rebase that on something current? Looks like the sources come from
some git, but where?


The first thing you guys could do is provide some more substantial info
of what you are actually testing. Build numbers are not really telling.


The OP was referring to "Raspberry Pi 2B". That's what I tried. All
three images (factory, devel, devel:staging) show the same behavior.


[...]
Ludwig's serial log is from the Pi 2. The Pi 2 is still not supported by
the mainline Linux kernel and therefore not by the openSUSE kernel
either. The kernel-rpi2 package is built from:

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryPi2/kernel-source

These Contrib packages have no magic cron jobs unlike the openSUSE
kernels and thus need to be manually updated like any other package, via
osc bco / sr, by whomever cares about them.


The kernel-source.changes looks like some script pulled patches from
a git repo. Unfortunately the package gives no hint from which repo.
It must be something based on the openSUSE kernel git repo I guess.
So it's not as simple as branch and submit. If that was the case
we'd see patch lines in the spec file.


I guess the kernel will be from somewhere at
https://github.com/raspberrypi/linux/ - there's several branches
including an rpi-4.4.y that you might want to try building and packaging.


Do we have some spec file template that shows how to build some
"upstream" kernel in a way that is compatible with the official
openSUSE kernel packaging?

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Alexander Graf]

On 21.12.15 11:03, Ludwig Nussel wrote:
> Andreas Färber wrote:
>> Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:
>>> I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
>>> Build354.2 which shows a black screen and does not boot at all, same
>>> as the
>>> latest one from Staging, which is from a few days back.
>>>
>>> Currently there are no working Tumbleweed images for any of the
>>> Raspberry Pi
>>> systems. Is there anything I can do, apart from testing the latest
>>> images?
>>
>> Yes.
>>
>> "Black screen" and "does not boot" do not help getting it fixed.
>> Buy yourself a cheap UART adapter (less than 4 EUR for 3.3 V!) and post
>> concrete error output if something is not working. A good report is half
>> the fix!
>>
>> Others have reported really trivial issues (like missing symlink/file)
>> that either you yourself could fix on your SD card or that someone
>> without access to that hardware can quickly fix in OBS if told what
>> issue there is.
>>
>> There's some main sources of trouble:
>> [...]
> 
> Might be worth putting those hints in the wiki and linking it from every
> HCL page. Esp the contrib ones.
> 
>> 3) Lack of automated QA: We inherit not just kernel updates but all
>> package updates, without having openQA based testing before publishing
> 
> So the images should have Factory in their names rather than Tumbleweed.

It's a mixed bag :). I think there were reasons we had to rename to
Tumbleweed - something with the publisher not working otherwise. Dirk
might remember details here.

> 
>> images. Factory submissions get build-tested only for x86 and ppc.
>> Further, limited OBS build workers for ARM do not always allow for
>> consistent rebuilds before publishing packages.
>>
>> Most breakages are hardware-specific though, in some u-boot-foo package
>> or a specific kernel driver or depending on NEON availability that would
>> not show in a generic KVM guest - and only very few of the boards have a
>> matching QEMU emulation. Hardware-in-the-loop testing was an alternative
>> idea. Several projects around openQA had been investigated but only few
>> successfully completed.
>>
>> => Find ways to use openQA for more testing, e.g. serial only rather
>> than graphical testing with QEMU machines such as cubieboard. Maybe
> 
> IOW cubieboard can be emulated by qemu? Do you have a command line for
> me? What host architecure is needed for that? Can the aarch64 worker we
> have for openQA emulate that in reasonable speed?

So far we haven't managed to make AArch64 KVM work with full AArch32
only VMs. Also keep in mind that with KVM host cpu == guest cpu, so
you'd get a cubieboard with an A57 CPU - something nobody expects to see.

> 
>> contribute to upstream efforts such as finally upstreaming Raspberry Pi
>> or Beagleboard emulations, to broaden the base to test against.
>>
>> => Use Wifi-enabled SD cards, USB gadget devices, HDMI framegrabbers,
>> JTAG adapters or other creative solutions to implement automated
>> hardware testing, avoiding some of the QEMU/KVM shortcomings.
> 
> That would be nice :-) The minimum requirement for openQA would be
> control over the power switch and SD card and access to the serial port.
> On the weekend I found this:
> http://www.linuxinternals.org/blog/2014/06/04/a-microsd-card-remote-switcher/
> 
> Maybe that could be cheap solution to allow the openQA worker to get
> the disk image on the target.

Yup, Linaro also has built similar adapters for their QA initiative.
Unfortunately my hardware skills aren't as great, so I doubt I could
actually solder this thing together ;). If you can find a way to get us
a dozen, we can start to make automated testing become reality.


Alex
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi(2)

[Michael Emory Cerquoni]

I can tell you my biggest source of frustration is there is very
little if any correct information/documentation posted anywhere about
opensuse-arm on Raspberry Pi2.  I have been trying to get myself more
oriented but I can barely even get the image to boot I have to use an
older version just to even get a log in prompt.  If people are
frustrated this probably why, I have spent weeks trying to even get
basic functionality with little luck.  I did just acquire a second pi2
for dev stuff but my time is very limited in terms of being able to
fix stuff, plus I am very new to Arm and Raspberry Pi2 I have a lot to
learn!  Thanks everyone I know working on opensource volunteer efforts
can be thankless and sometimes frustrating work, I really do
appreciate the help I have received so far!

On Mon, Dec 21, 2015 at 10:43 AM, Alexander Graf  wrote:
>
>
> On 21.12.15 16:34, Andreas Färber wrote:
>> Alex,
>>
>> Am 21.12.2015 um 11:18 schrieb Alexander Graf:
>>> On 21.12.15 10:45, Ludwig Nussel wrote:
 Do we have some spec file template that shows how to build some
 "upstream" kernel in a way that is compatible with the official
 openSUSE kernel packaging?
>>>
>>> The easiest is to use my awesome "Contrib Kernel" script. Just point it
>>> at a downstream tarball plus .config and it creates all the
>>> kernel-source and kernel-foo packages in OBS for you:
>>>
>>>   http://users.suse.com/~dmueller/contrib_kernel.sh
>>
>> During your absence someone had reported your awesome script were not
>> working any more - have you tested or fixed it lately?
>
> I've used it for the Tegra TX1 kernel and it worked for me:
>
>
> https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Tegra/kernel-tx1
>
>
> Alex
> --
> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
>



-- 
Michael Emory Cerquoni
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi(2)

[Alexander Graf]

On 21.12.15 16:34, Andreas Färber wrote:
> Alex,
> 
> Am 21.12.2015 um 11:18 schrieb Alexander Graf:
>> On 21.12.15 10:45, Ludwig Nussel wrote:
>>> Do we have some spec file template that shows how to build some
>>> "upstream" kernel in a way that is compatible with the official
>>> openSUSE kernel packaging?
>>
>> The easiest is to use my awesome "Contrib Kernel" script. Just point it
>> at a downstream tarball plus .config and it creates all the
>> kernel-source and kernel-foo packages in OBS for you:
>>
>>   http://users.suse.com/~dmueller/contrib_kernel.sh
> 
> During your absence someone had reported your awesome script were not
> working any more - have you tested or fixed it lately?

I've used it for the Tegra TX1 kernel and it worked for me:


https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Tegra/kernel-tx1


Alex
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Andreas Färber]

Am 21.12.2015 um 12:08 schrieb Alexander Graf:
> On 21.12.15 11:45, Ludwig Nussel wrote:
>> Alexander Graf wrote:
>>> On 21.12.15 11:03, Ludwig Nussel wrote:
 Andreas Färber wrote:
> [...]
> => Find ways to use openQA for more testing, e.g. serial only rather
> than graphical testing with QEMU machines such as cubieboard.

 IOW cubieboard can be emulated by qemu? Do you have a command line for
 me? What host architecure is needed for that? Can the aarch64 worker we
 have for openQA emulate that in reasonable speed?
>>>
>>> So far we haven't managed to make AArch64 KVM work with full AArch32
>>> only VMs. Also keep in mind that with KVM host cpu == guest cpu, so
>>> you'd get a cubieboard with an A57 CPU - something nobody expects to see.
>>
>> So x86_64 with emulation? Can you provide me with a qemu command
>> line to boot an image?
> 
> I haven't used the cubietruck on myself either yet :).

Note it's the A10 based Cubieboard (sun4i?); Cubietruck is A20 (sun7i).

I'm guessing it would be 'qemu-system-arm -machine cubieboard -kernel
... -initrd ... -append "..." ...' (i.e., don't expect full U-Boot).

Not sure what storage options are available for which of the lesser
known emulations for accessing the rootfs.

qemu-system-arm -M \? gives a list of available machine options - not
all supported by openSUSE (ARM9 etc.) but highbank, midway, smdkc210,
vexpress-a9, vexpress-a15, xilinx-zynq-a9 are some of the other possibly
interesting emulations available on Leap.

dracut -N might help create an ad-hoc initrd that works for all such
boards without needing to build a full JeOS image for each.

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi(2)

[Andreas Färber]

Alex,

Am 21.12.2015 um 11:18 schrieb Alexander Graf:
> On 21.12.15 10:45, Ludwig Nussel wrote:
>> Do we have some spec file template that shows how to build some
>> "upstream" kernel in a way that is compatible with the official
>> openSUSE kernel packaging?
> 
> The easiest is to use my awesome "Contrib Kernel" script. Just point it
> at a downstream tarball plus .config and it creates all the
> kernel-source and kernel-foo packages in OBS for you:
> 
>   http://users.suse.com/~dmueller/contrib_kernel.sh

During your absence someone had reported your awesome script were not
working any more - have you tested or fixed it lately?

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi(2)

[Andreas Färber]

Am 21.12.2015 um 10:45 schrieb Ludwig Nussel:
> Andreas Färber wrote:
>> Am 20.12.2015 um 15:50 schrieb Ludwig Nussel:
>>> Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:
 I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
 Build354.2 which shows a black screen and does not boot at all, same
 as the
 latest one from Staging, which is from a few days back.

 Currently there are no working Tumbleweed images for any of the
 Raspberry Pi
 systems. Is there anything I can do, apart from testing the latest
 images?
>>>
>>> Same here. None of the available images work. The kernel seems to be
>>> a patched copy of some kernel devel project state. Any chance to
>>> rebase that on something current? Looks like the sources come from
>>> some git, but where?
>>
>> The first thing you guys could do is provide some more substantial info
>> of what you are actually testing. Build numbers are not really telling.
> 
> The OP was referring to "Raspberry Pi 2B". That's what I tried. All
> three images (factory, devel, devel:staging) show the same behavior.

Yes, but it was diluted by talking about "any of the Raspberry Pi
systems" - Raspberry Pi and Raspberry Pi 2 are very different, not just
ARMv6 vs. ARMv7 but also the kernel situation, as I outlined.

I mainly meant, tell us the download location (project) where you got
the image from. There's :upstream vs. :RaspberryPi1 vs. the new official
one and :RaspberryPi2 vs. :Staging that I thought Dirk said was obsoleted...

You'd be surprised that some people still complain about ancient images
from Bernhard they saw in some old blog post that were never officially
built in OBS by any of us! ;)

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Freek de Kruijf]

Op maandag 21 december 2015 04:27:40 schreef Andreas Färber:
> Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:
> > I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
> > Build354.2 which shows a black screen and does not boot at all, same as
> > the
> > latest one from Staging, which is from a few days back.
> > 
> > Currently there are no working Tumbleweed images for any of the Raspberry
> > Pi systems. Is there anything I can do, apart from testing the latest
> > images?
> Yes.
> 
> "Black screen" and "does not boot" do not help getting it fixed.
> Buy yourself a cheap UART adapter (less than 4 EUR for 3.3 V!) and post
> concrete error output if something is not working. A good report is half
> the fix!

Dear Andreas,

Maybe I can find such a device, but I have no idea how to connect it to my 
system to get some characters on a screen.

I restrict myself to getting all the images for the Raspberry Pi 1B and 2B 
from http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/

Should I use another source for the images.

After putting an image on the (micro-)SD card I test the image with a 
connected HDMI screen and an Ethernet cable, so I can watch how the system 
boots. When I report a black screen, this means I do not seen ANY information 
on the HDMI screen. It does not boot means I do not see the Ethernet 
connection coming up.

Furthermore I can change files on the SD card in case this is relatively 
simple. Putting a new kernel on it is beyond my capabilities. I do realize I 
am part of the team, but I have limited capabilities. Reporting about what 
works and not is about all I can do. After that I hope I am quite willing to 
regularly follow a cookbook type of procedure and report about the results. I 
once did something quite simple in OBS.

-- 
fr.gr.

member openSUSE
Freek de Kruijf

--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Michael Ströder]

Stefan Bruens wrote:
> On Sunday 20 December 2015 18:43:34 Michael Ströder wrote:
>>> The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not
>>> start anymore. The error message on the screen said:
>>> File not found dtb.bcm2835-rpi-b.dtb
>>
>> Since a couple of kernel updates and only on some systems I have to manually
>> copy the fimware files into /boot/dtb/ to make it work again.
> 
> Most probably your system is not properly updated, which happens as not 
> everything is updated automatically, unfortunately.
> [..]
> * The dtbs are multiversion enabled since a few weeks.

Matches time-frame of first failure.

> You should remove the 
> old /boot/dtb/ directory and reinstall the latest dtb-bcm2835 rpm, /boot/dtb 
> should be a symlink to the versioned dtb directory afterwards.

That makes sense and seemed to work as you described. Thanks.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [opensuse-arm] Images for Raspberry Pi

[Andreas Färber]

Freek,

Am 20.12.2015 um 18:17 schrieb Freek de Kruijf:
> The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not 
> start anymore. The error message on the screen said:
> File not found dtb.bcm2835-rpi-b.dtb

I assume that was a typo: dtb/bcm2835-rpi-b.dtb?

1) It was reported, e.g. for Cubietruck, that the dtb symlink was
missing. Dirk and me have fixed that during Hackweek (a missing
coreutils dependency for ln -s in my %post scriptlet) - in Factory now.

2) In my raspberrypi-firmware thread I reported update installation
problems with missing dtb-bcm2835 package files. Reinstalling the
package via zypper in -f helped. If you can no longer boot with a manual
U-Boot command line to do so, you can also download the .rpm file on
another machine and extract the .dtb with file-roller (or whatever) to
your SD card.

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Andreas Färber]

Am 20.12.2015 um 23:23 schrieb Stefan Bruens:
> On Sunday 20 December 2015 18:43:34 Michael Ströder wrote:
>>> The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not
>>> start anymore. The error message on the screen said:
>>> File not found dtb.bcm2835-rpi-b.dtb
>>
>> Since a couple of kernel updates and only on some systems I have to manually
>> copy the fimware files into /boot/dtb/ to make it work again.

Typo, I assume. .dtb files go to /boot/dtb* but not the firmware files.
Currently there is no standard mount point for the FAT partition yet,
cf. below.

> Most probably your system is not properly updated, which happens as not 
> everything is updated automatically, unfortunately.
> 
> As of today, the blueprint for booting looks as follows:

A nice summary, Stefan! Some corrections and updates inline.

> 
> - RPi loader (bootcode.bin) on the first partition (FAT16) is loaded and 
> started.
> - Reads Config.txt, kernel=u-boot.bin
> - RPi loader starts u-boot
> 
> -- handover -
> 
> - u-boot starts, reads default environment
> - environment contains command to find first bootable partitions [1]
>   -> this yields the second, ext3 boot partition

Actually until today it yielded the first, fat partition. Hopefully
fixed now (JeOS-raspberrypi2 >= build 355).

> - bootable partion is scanned for boot.scr
> - boot.scr is loaded and executed

boot.scr on fat previously chain-loaded the boot.scr on ext3:

> - boot.scr contains
>  - the path to the fdt file (e.g. dtb/bcm2835-rpi-b.dtb)
>  - the path to the kernel (zImage)
>  - the path to the initrd (initrd)
>  - the kernel cmdline arguments (root=...)
> - u-boot loads the fdt file
> - u-boot loads the kernel
> - u-boot loads the initrd
> - u-boot appends the initrd address to the fdt
> - u-boot executes the kernel
> 
> 
> * The boot.scr is only created once during kiwi image creation, so this may 
> be 
> outdated. You can view its contents with:
>  $> tail -c +72 /boot/boot.scr

And you can easily replace it with a much simpler version such as:

setenv bootargs 'console=ttyAMA0,115200 root=/dev/mmcblk0p3
rootfstype=ext4 rw rootwait' # or whatever you were using
load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} zImage
load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} dtb/${fdtfile}
load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} initrd
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

Note the -b-rev2.dtb vs. -b.dtb ${fdtfile} issue discussed elsewhere.

> * u-boot.bin itself has to be copied to the FAT partition manually. 

https://build.opensuse.org/request/show/350127

Use /boot/vc as mount point for the FAT partition (/etc/fstab or YaST
Partitioner), then new raspberrypi-firmware,
raspberrypi-firmware-branding-openSUSE and soon u-boot-rpi / u-boot-rpi2
packages will update the FAT partition without manual copying.

> * The dtbs are multiversion enabled since a few weeks. You should remove the 
> old /boot/dtb/ directory and reinstall the latest dtb-bcm2835 rpm, /boot/dtb 
> should be a symlink to the versioned dtb directory afterwards.

Note that while the packages are prepared for multiversion through
distinctive folder names, they will not be installed side by side unless
you create a file such as /etc/zypp/multiversion.d/my-dtb.conf that
enables the new behavior with:

provides:multiversion(dtb)

This has the downside that once you install, e.g., dtb-bcm2835-4.4.rc5
from Kernel:HEAD it might no longer install updated 4.3.x versions from
a home branch of yours. (Obsoletes do not seem to work well with custom
Provides, we'll need to borrow some magic from the kernel package for
improving this... also the directory names for Kernel:HEAD remain to be
tidied from 4.4.rc5-x to 4.4.0-rc5-x.deadbeaf.)

Another thing worth pointing out is that when you're installing two new
kernel and corresponding multiversion dtb packages, there is no
guarantee that kernels and dtb packages will be installed in the same
order, so do check that dtb and initrd/zImage are pointing to the same
version before rebooting (ll /boot/).

We're slowly getting there!

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Andreas Färber]

Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:
> I tested the latest released Tumbleweed image for the Raspberry Pi 2B, 
> Build354.2 which shows a black screen and does not boot at all, same as the 
> latest one from Staging, which is from a few days back.
> 
> Currently there are no working Tumbleweed images for any of the Raspberry Pi 
> systems. Is there anything I can do, apart from testing the latest images?

Yes.

"Black screen" and "does not boot" do not help getting it fixed.
Buy yourself a cheap UART adapter (less than 4 EUR for 3.3 V!) and post
concrete error output if something is not working. A good report is half
the fix!

Others have reported really trivial issues (like missing symlink/file)
that either you yourself could fix on your SD card or that someone
without access to that hardware can quickly fix in OBS if told what
issue there is.

There's some main sources of trouble:


1) Kernel instability: ARM kernels are often less stable than on x86 -
mainline kernel.org kernels frequently break on some board while adding
cool new features for another one. Our use of modules is less tested
than built-in drivers used by the defconfigs.

=> Compare Kernel:stable when there's a problem in openSUSE:Factory:ARM.

=> Test Kernel:HEAD kernels before they hit Tumbleweed and report such
issues on opensuse-kernel list. Chances are, problems need to be
reported to the respective upstream kernel maintainers.

=> Kernel:linux-next has been in preparation for testing maintainers'
queues even earlier, in particular for enablement of new boards.

=> On most boards that run kernel-lpae you can compare kernel-default,
and for kernel-default you can compare kernel-vanilla to rule out any
SUSE patches.

=> perl-Bootloader and U-Boot enhancements for grub2 are two projects to
help dealing with multiple possibly broken kernels.


2) qemu-linux-user: For ARMv6, updated packages may fail to work under
QEMU emulation when new syscalls or ioctls got introduced, leading to
failing or hanging builds.

=> Help find a small test case narrowing down what the issue is.

=> Packages' testsuites can get disabled or ignored for QEMU builds.


3) Lack of automated QA: We inherit not just kernel updates but all
package updates, without having openQA based testing before publishing
images. Factory submissions get build-tested only for x86 and ppc.
Further, limited OBS build workers for ARM do not always allow for
consistent rebuilds before publishing packages.

Most breakages are hardware-specific though, in some u-boot-foo package
or a specific kernel driver or depending on NEON availability that would
not show in a generic KVM guest - and only very few of the boards have a
matching QEMU emulation. Hardware-in-the-loop testing was an alternative
idea. Several projects around openQA had been investigated but only few
successfully completed.

=> Find ways to use openQA for more testing, e.g. serial only rather
than graphical testing with QEMU machines such as cubieboard. Maybe
contribute to upstream efforts such as finally upstreaming Raspberry Pi
or Beagleboard emulations, to broaden the base to test against.

=> Use Wifi-enabled SD cards, USB gadget devices, HDMI framegrabbers,
JTAG adapters or other creative solutions to implement automated
hardware testing, avoiding some of the QEMU/KVM shortcomings.


4) Work in progress: Whenever we touch things to make them better,
something may break. The same may happen if we don't update something.

=> Report regressions early. Check if there was a recent submission that
looks suspicious. Be prepared to submit small fixes yourself to speed
things up.

Usual suspects are:
https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS
https://build.opensuse.org/package/show/openSUSE:Factory:ARM/dtb-source
https://build.opensuse.org/package/show/openSUSE:Factory:ARM/u-boot


Also, since our armv7l build power is insufficient, keeping your eyes
open whether, e.g., x86 users are wastefully branching kernel packages
and forgetting to turn off armv7l builds can help to get our fixes to
you more quickly. f.ex.: https://build.opensuse.org/request/show/245580


Lastly, while you're waiting for other Raspberry Pi fixes, you could
help clean up any "trivial" packages in the Contrib projects that you
use (e.g., raspberrypi-userland, pihwm) and find them a new devel
project (e.g., hardware), so that they can get submitted to Tumbleweed
properly. That won't help your boot problems but it will take some time
(weeks?) to go through reviews, so looking into it early will save you
time later.

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Andreas Färber]

Am 18.12.2015 um 10:39 schrieb Freek de Kruijf:
> Op donderdag 17 december 2015 09:15:12 schreef u:
>> It is very disappointing from what i can tell there is almost zero interest
>> from the overall opensuse-arm community for supporting raspberry pi
>> hardware properly.

Everyone who complains here is forgetting that "the opensuse-arm
community" includes yourself:

* Make meaningful error reports as soon as things break - if you remain
inactive, you can't complain about others' inactivity!
* Make Submit Requests to improve what you dislike, it's all open on
build.opensuse.org - no secret sauce, no permission needed.

Constant bitching is not exactly motivating those that are fighting for
a proper packaging.

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Andreas Färber]

Am 20.12.2015 um 15:50 schrieb Ludwig Nussel:
> Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:
>> I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
>> Build354.2 which shows a black screen and does not boot at all, same
>> as the
>> latest one from Staging, which is from a few days back.
>>
>> Currently there are no working Tumbleweed images for any of the
>> Raspberry Pi
>> systems. Is there anything I can do, apart from testing the latest
>> images?
> 
> Same here. None of the available images work. The kernel seems to be
> a patched copy of some kernel devel project state. Any chance to
> rebase that on something current? Looks like the sources come from
> some git, but where?

The first thing you guys could do is provide some more substantial info
of what you are actually testing. Build numbers are not really telling.

On the Pi 1 the official openSUSE kernel-default 4.3.0 from Tumbleweed
works just fine (not 4.4-rcX due to USB, as reported). I.e., you need to
double-check which kernel package you have and which repository you are
installing your kernel from if it looks like "a patched copy of some
kernel devel project state" - it might be kernel-rpi from
devel:ARM:Factory:Contrib:RaspberryPi or kernel-rpi2 from
devel:ARM:Factory:Contrib:RaspberryPi2, which are not maintained by the
kernel team.

Ludwig's serial log is from the Pi 2. The Pi 2 is still not supported by
the mainline Linux kernel and therefore not by the openSUSE kernel
either. The kernel-rpi2 package is built from:

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryPi2/kernel-source

These Contrib packages have no magic cron jobs unlike the openSUSE
kernels and thus need to be manually updated like any other package, via
osc bco / sr, by whomever cares about them.
I guess the kernel will be from somewhere at
https://github.com/raspberrypi/linux/ - there's several branches
including an rpi-4.4.y that you might want to try building and packaging.


One of my Hackweek projects was to clean up Raspberry Pi images and move
the Pi 1 closer to first-class Tumbleweed citizen. raspberrypi-firmware
was accepted into Tumbleweed and JeOS-raspberrypi "moved" from
devel:ARM:Factory:Contrib:RaspberryPi:upstream project to official
openSUSE:Factory:ARM, i.e. the download locaction will change to:

http://download.opensuse.org/ports/armv6hl/tumbleweed/images/

As mentioned multiple times already, armv6 image builds keep hanging.
Any help debugging that is appreciated - it's been broken for weeks and
months, so waiting and complaining is seriously not going to help!

https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS-raspberrypi

Depending on your host kernel, a local osc build on x86_64 may work.

Also, you can always check the list archives - long before we got the
now-broken JeOS image, I had posted a how-to for manually partitioning
and bootstrapping an upstream-based rpi1 card based on the armv6 rootfs
(which still seems building fine) that with some tweaks should still
work. Only the lazy way of installing a new Raspberry Pi is broken. :)


Just today my Hackweek submission of raspberrypi-firmware was accepted,
adding a Config.txt template and moving the files from /boot to /boot/vc
so that the FAT partition can be automatically updated by zypper in the
future.
https://build.opensuse.org/request/show/347964

The matching change to JeOS has just been submitted:
https://build.opensuse.org/request/show/349929

The corresponding u-boot change I haven't accepted yet, to not interfere
with Guillaume's -rc2 submission.
https://build.opensuse.org/request/show/350127


> Also, it takes ages to even boot up to this point. Kernel/initrd too big?

On first boot of Kiwi images, a huge initrd is loaded and it will resize
partitions, which both can take some time.

For ARMv6 we mainly enable the Raspberry Pi, for ARMv7 the number of
SoCs and boards and thus of drivers is significantly higher.

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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Stefan Bruens]

On Sunday 20 December 2015 18:43:34 Michael Ströder wrote:
> > The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not
> > start anymore. The error message on the screen said:
> > File not found dtb.bcm2835-rpi-b.dtb
> 
> Since a couple of kernel updates and only on some systems I have to manually
> copy the fimware files into /boot/dtb/ to make it work again.
> 
> Ciao, Michael.

Most probably your system is not properly updated, which happens as not 
everything is updated automatically, unfortunately.

As of today, the blueprint for booting looks as follows:

- RPi loader (bootcode.bin) on the first partition (FAT16) is loaded and 
started.
- Reads Config.txt, kernel=u-boot.bin
- RPi loader starts u-boot

-- handover -

- u-boot starts, reads default environment
- environment contains command to find first bootable partitions [1]
  -> this yields the second, ext3 boot partition
- bootable partion is scanned for boot.scr
- boot.scr is loaded and executed
- boot.scr contains
 - the path to the fdt file (e.g. dtb/bcm2835-rpi-b.dtb)
 - the path to the kernel (zImage)
 - the path to the initrd (initrd)
 - the kernel cmdline arguments (root=...)
- u-boot loads the fdt file
- u-boot loads the kernel
- u-boot loads the initrd
- u-boot appends the initrd address to the fdt
- u-boot executes the kernel


* The boot.scr is only created once during kiwi image creation, so this may be 
outdated. You can view its contents with:
 $> tail -c +72 /boot/boot.scr
* u-boot.bin itself has to be copied to the FAT partition manually. 
* The dtbs are multiversion enabled since a few weeks. You should remove the 
old /boot/dtb/ directory and reinstall the latest dtb-bcm2835 rpm, /boot/dtb 
should be a symlink to the versioned dtb directory afterwards.

Kind regards,

Stefan


[1] as of u-boot 2015.04-rc5

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424

signature.asc
Description: This is a digitally signed message part.

Re: [opensuse-arm] Images for Raspberry Pi

[Ludwig Nussel]

Am 17.12.2015 um 13:04 schrieb Freek de Kruijf:

I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
Build354.2 which shows a black screen and does not boot at all, same as the
latest one from Staging, which is from a few days back.

Currently there are no working Tumbleweed images for any of the Raspberry Pi
systems. Is there anything I can do, apart from testing the latest images?


Same here. None of the available images work. The kernel seems to be
a patched copy of some kernel devel project state. Any chance to
rebase that on something current? Looks like the sources come from
some git, but where?

This is what's on the serial port:

---8<---
U-Boot 2016.01-rc1 (Dec 01 2015 - 17:28:22 +)

DRAM:  880 MiB
WARNING: Caches not enabled
RPI 2 Model B
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.
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
113 bytes read in 26 ms (3.9 KiB/s)
## Executing script at 0200
2861 bytes read in 74 ms (37.1 KiB/s)
## Executing script at 0200
switch to partitions #0, OK
mmc0 is current device
7317720 bytes read in 8278 ms (862.3 KiB/s)
53327828 bytes read in 71003 ms (733.4 KiB/s)
9312 bytes read in 143 ms (63.5 KiB/s)
Kernel image @ 0x100 [ 0x00 - 0x6fa8d8 ]
## Loading init Ramdisk from Legacy Image at 0210 ...
   Image Name:   Initrd
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:53327764 Bytes = 50.9 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0100
   Booting using the fdt blob at 0x000100
   Using Device Tree in place at 0100, end 555f

Starting kernel ...
---8<---

Also, it takes ages to even boot up to this point. Kernel/initrd too big?

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Freek de Kruijf]

Op vrijdag 18 december 2015 10:39:46 schreef Freek de Kruijf:
> Op donderdag 17 december 2015 09:15:12 schreef u:
> > I have had the same experience have had to stop using opensuse on my pi's.
> > It is very disappointing from what i can tell there is almost zero
> > interest
> > from the overall opensuse-arm community for supporting raspberry pi
> > hardware properly.
> > 
> > On Dec 17, 2015 7:04 AM, "Freek de Kruijf"  wrote:
> > > I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
> > > Build354.2 which shows a black screen and does not boot at all, same as
> > > the
> > > latest one from Staging, which is from a few days back.
> > > 
> > > Currently there are no working Tumbleweed images for any of the
> > > Raspberry
> > > Pi
> > > systems. Is there anything I can do, apart from testing the latest
> > > images?
> 
> The situation is not that negative. I have Tumbleweed systems running on
> both RPi1 and RPi2 started from a working image, some month ago, on which I
> am still able to update these to the latest version of Tumbleweed from the
> repository. So it seems that the only problem is with the boot system, but
> generating a new initrd still works.

The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not 
start anymore. The error message on the screen said:
File not found dtb.bcm2835-rpi-b.dtb

-- 
fr.gr.

member openSUSE
Freek de Kruijf

-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Images for Raspberry Pi

[Michael Ströder]

Freek de Kruijf wrote:
> Op vrijdag 18 december 2015 10:39:46 schreef Freek de Kruijf:
>> Op donderdag 17 december 2015 09:15:12 schreef u:
>>> I have had the same experience have had to stop using opensuse on my pi's.
>>> It is very disappointing from what i can tell there is almost zero
>>> interest
>>> from the overall opensuse-arm community for supporting raspberry pi
>>> hardware properly.
>>>
>>> On Dec 17, 2015 7:04 AM, "Freek de Kruijf"  wrote:
 I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
 Build354.2 which shows a black screen and does not boot at all, same as
 the
 latest one from Staging, which is from a few days back.

 Currently there are no working Tumbleweed images for any of the
 Raspberry
 Pi
 systems. Is there anything I can do, apart from testing the latest
 images?
>>
>> The situation is not that negative. I have Tumbleweed systems running on
>> both RPi1 and RPi2 started from a working image, some month ago, on which I
>> am still able to update these to the latest version of Tumbleweed from the
>> repository. So it seems that the only problem is with the boot system, but
>> generating a new initrd still works.
> 
> The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not 
> start anymore. The error message on the screen said:
> File not found dtb.bcm2835-rpi-b.dtb

Since a couple of kernel updates and only on some systems I have to manually
copy the fimware files into /boot/dtb/ to make it work again.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [opensuse-arm] Images for Raspberry Pi

[Michael Ströder]

Freek de Kruijf wrote:
> Op donderdag 17 december 2015 09:15:12 schreef u:
>> I have had the same experience have had to stop using opensuse on my pi's.
>> It is very disappointing from what i can tell there is almost zero interest
>> from the overall opensuse-arm community for supporting raspberry pi
>> hardware properly.
>>
>> On Dec 17, 2015 7:04 AM, "Freek de Kruijf"  wrote:
>>> I tested the latest released Tumbleweed image for the Raspberry Pi 2B,
>>> Build354.2 which shows a black screen and does not boot at all, same as
>>> the
>>> latest one from Staging, which is from a few days back.
>>>
>>> Currently there are no working Tumbleweed images for any of the Raspberry
>>> Pi
>>> systems. Is there anything I can do, apart from testing the latest images?
> 
> The situation is not that negative. I have Tumbleweed systems running on both 
> RPi1 and RPi2 started from a working image, some month ago, on which I am 
> still able to update these to the latest version of Tumbleweed from the 
> repository.

Same here.

> So it seems that the only problem is with the boot system, but 
> generating a new initrd still works.

FULL ACK.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature