Hi,
Just asking if this is only me or it's a wider problem: I recently
updated my cubox-i with zypper, pulling in kernel-default-4.4.114, and
after reboot the box boots, but several drivers are missing, so there is
no wired ethernet, no mmcblk, etc.
After booting and waiting for a while, dmesg starts to complain about
driver detection did not finish in time (sadly I don't have the
backtrace at hand, it already went out of the buffer of the serial
console).
For now I worked around the problem this way:
- download the repo-oss (ie. non-update) kernel-default-4.4.76 rpm on an
other machine, copied it to an usb stick
- install the old kernel-default from the usb stick
- copy the /boot from the root fs to the usb stick
- use the other machine to update the /boot on the mmcblk device where
u-boot reads it
So is this only me or do other cubox-i users see the same?
Thanks,
Miklos
Hello,
Is it possible to have Ubuntu:18.04:Ports with aarch64?
I am trying to make some experiments with GStreamer and RockChip SBC and
I need to rebuild specific deb-packages. Everything was ok until I found
that only x86_64 is available.
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
From: Jimmy PIERRE [mailto:jimmypierre.rouen.france@gmail.com]
Sent: 25 April 2018 14:38
To: Alexander Graf
Cc: Matthias Brugger; opensuse-arm(a)opensuse.org
Subject: Re: [opensuse-arm] Raspberry Pi 2
Thanks!
On Mon, 23 Apr 2018 at 21:13, Alexander Graf <agraf(a)suse.de> wrote:
On 23.04.18 19:28, jimmypierre.rouen.france(a)gmail.com wrote:
>
>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: 23 April 2018 19:20
> To: Matthias Brugger; jimmypierre.rouen.france(a)gmail.com; opensuse-arm(a)opensuse.org
> Subject: Re: [opensuse-arm] Raspberry Pi 2
>
>
>
> On 23.04.18 18:43, Matthias Brugger wrote:
>> Hi Jimmy,
>>
>> On 04/23/2018 06:20 PM, jimmypierre.rouen.france(a)gmail.com wrote:
>>> Greetings
>>>
>>> In view of Linux Presentation Day April 28, I got two Raspberry Pi 3 with SUSE and would happily install openSUSE on three Raspberry Pi 2, that we own, if only there is a straight forward image ready to go. If you happen to know of a working image for RPI 2.
>>>
>>
>> Did you tried the images here:
>> https://en.opensuse.org/HCL:Raspberry_Pi2
>
> I think the published images are still broken :(.
>
> If they don't work for you, please directly fetch the current ones from OBS:
>
> $ osc getbinaries openSUSE:Factory:ARM:Live JeOS:JeOS-raspberrypi2
> images armv7l
>
> These should hopefully work :).
>
> Hi guys,
>
> I have been downloading many images but to no avail.....
>
> I will give OBS a try though.
>
> Do you burn the image to a SD exactly as with a RAW image?
Yes, the procedure is the same as described on the wiki page above, just
that the image is not the published one, but the current bleeding edge
image.
Hi guys,
I would like to share what happened next:
1. >> This has been updated - I downloaded: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2018.04.17-Build2.9.raw
2. copied to a 8 GB SD
3. did zypper ref, zypper up and zypper dup
4. used yast to install XFCE, Xorg, xrdp and setup ntp
5. changed hostname
6. installed screenfetch
7. executed vncserver :1
8. remotely connected from various devices
9. can't get wifi to work at the moment, using LAN over eth0
I am quite happy that I will have 2 SUSE RPI3 and 2 RPI2 with TW and finallly 1 RPI2 with raspbian.at Linux Presentation Day next Saturday.
Cheers, guys!
Jimmy
nui.fr
tw76one:~ # screenfetch
/usr/bin/screenfetch: line 1341: [: =: unary operator expected
.;ldkO0000Okdl;. root@tw76one
.;d00xl:^''''''^:ok00d;. OS: openSUSE
.d00l' 'o00d. Kernel: armv7l Linux 4.16.3-1-lpae
.d0Kd' Okxol:;,. :O0d. Uptime: 56m
.OKKKK0kOKKKKKKKKKKOxo:, lKO. Packages: 1716
,0KKKKKKKKKKKKKKKK0P^,,,^dx: ;00, Shell: bash 4.4.19
.OKKKKKKKKKKKKKKKKk'.oOPPb.'0k. cKO. CPU: 4x ARMv7 rev 5 (v7l)
:KKKKKKKKKKKKKKKKK: kKx..dd lKd 'OK: GPU:
dKKKKKKKKKKKOx0KKKd ^0KKKO' kKKc dKd RAM: 678MiB / 964MiB
dKKKKKKKKKKKK;.;oOKx,..^..;kKKK0. dKd
:KKKKKKKKKKKK0o;...^cdxxOK0O/^^' .0K:
kKKKKKKKKKKKKKKK0x;,,......,;od lKk
'0KKKKKKKKKKKKKKKKKKKKK00KKOo^ c00'
'kKKKOxddxkOO00000Okxoc;'' .dKk'
l0Ko. .c00l'
'l0Kk:. .;xK0l'
'lkK0xl:;,,,,;:ldO0kl'
'^:ldxkkkkxdl:^'
tw76one:~ #
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Greetings
In view of Linux Presentation Day April 28, I got two Raspberry Pi 3 with SUSE and would happily install openSUSE on three Raspberry Pi 2, that we own, if only there is a straight forward image ready to go. If you happen to know of a working image for RPI 2.
Thanks 👍
Jimmy
nui.fr
--
Sent from my iPad
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi,
I have submitted pyOCD for inclusion in Factory:
https://build.opensuse.org/request/show/596738
pyOCD is an on-chip debugger tool for Arm mbed microcontroller boards.
An alternative, more generic tool we already have in Factory is OpenOCD.
I recall that someone had been maintaining a python3-pyOCD package in
the past, but that appears to have disappeared as a result of the new
singlespec packaging approach.
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 Daniel,
Le 03/04/2018 à 19:23, Daniel Bischof a écrit :
> Hi Guillaume,
>
> thank you for your reply.
>
> On Fri, 30 Mar 2018, Guillaume Gardet wrote:
>
>> Le 30/03/2018 à 15:58, Daniel Bischof a écrit :
>>>
>>> checked for changes in
>>>
>>> https://build.opensuse.org/package/view_file/openSUSE:Factory/u-boot-snow/u…
>>>
>>> yesterday, and there's an update that may fix the ongoing boot issues
>>> on my Chromebook (Snow).
>>
>> Which boot issue?
>
> ok, boot issue is probably misleading. The images boot, but after "Starting kernel" the screen turns black and nothing happens. I tried to just wait, used different SD cards and checked, whether my Chromebook works with Arch Linux ARM (it does).
>
>>> However, the JeOS-images for Snow haven't been rebuilt for more than
>>> one month:
>>>
>>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Chr…
>>>
>>> Intention or mistake?
>>
>> The Chromebook, is now fully upstream, so please use images from:
>> http://download.opensuse.org/ports/armv7hl/tumbleweed/images/
>
> Very good, I didn't know that. However, the February image shows the same behaviour as described above. Tried JeOS- and X11-images today.
New images are building. There is also an u-boot update (to fix chromebook boot), on the way to Tumbleweed.
Then, you could try those new images. :)
Guillaume
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Le 04/04/2018 à 10:48, Marcus Schäfer a écrit :
> Hi,
>
>> It seems that new kiwi does not support u-boot (non EFI/Grub2) images? Is there a solution/workaround?
> I have not ported plain u-boot support to the next generation kiwi, because
> of the effort to move all boards to efi boot. u-boot basically works as the
> EFI firmware being capable to load the grub efi module(s).
Yes, but not all boards are supporting EFI with U-Boot. Especially Arndale because "Samsung's bl1 lies at sector 1, overlapping with the EFI GPT, so we can not use EFI".
Maybe for other boards, we may use the EFI config in kiwi, but still boot using u-boot script? (I will give it a try)
>
> One of the changelog entries I have here is this:
>
> Date: Fri Mar 18 10:23:07 2016 +0100
>
> Delete obsolete support for uboot
>
> arm boot is using grub2 efi images loaded by a firmware. The
> firmware could be uboot but due to the non generic way to
> setup the board that it loads the firmware all of these tasks
> are handled by custom scripts called via the kiwi
> editbootconfig / editbootinstall script hooks. Therefore kiwi
> itself does not have to setup or install uboot
>
> iirc this was one result of a conversation with Alex some time ago,
> not sure though. In our integration test example for the panda board
> I can see those kind of scripts:
>
> https://github.com/SUSE/kiwi/tree/master/build-tests/arm/test-image-panda-o…
>
> If this is going to become a problem we should start a discussion
> what parts are missing in the builder
Alex, you may give us more information, maybe?
Guillaume
>
> Thanks
>
> Regards,
> Marcus
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Le 04/04/2018 à 10:35, Marcus Schäfer a écrit :
> Hi,
>
>> openSUSE:Factory:ARM switched to new kiwi to build images. But we have
>> still a number of images requiring firmware=custom option to build
>> with u-boot. But this leads to the following error:
> I can not remember we ever had "custom" as allowed value for the
> firmware attribute. No schema in v7 nor in the next generation kiwi
> supported that. I remember bootkernel="custom" added via
>
> - added custom bootkernel profile (bnc #846068)
>
> in the past. Is this what you refer to ?
No. It was in the image file to replace the old firmware=vboot option. Anyway, if I remove this option (and just use spare_part option), I hit the next error because standalone U-Boot is not supported.
Guillaume
>
> Regards,
> Marcus
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org