Re: [opensuse-arm] Support for Hardkernel Odroid N2

[Andreas Färber]

Am 13.04.20 um 12:45 schrieb Matthias Brugger:

On 4/13/20 12:19 PM, Jogchum Reitsma wrote:



Anything I can do (not, I suppose)?

1) check if the firmware blobs has such a license
2) if not, talk to hardkernel to see if they can publish then under such
a license.

 From what I see on

https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/amlogic/w400/README.odroid-n2

I think it's the files

https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz

and

https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz

Correct? And is there a specific license type you need?


No, that's the toolchain.

I don't know which binary files you need which Guillaume mentioned.
But normally it's something you have to 'dd' to a specific part of your
SD card so that the bootrom can load it.

First you need to find out how to build a SD card from scratch



and then
you need to integrate that into OBS.


Why would you need that? Have any of you checked the Wiki at all?

https://en.opensuse.org/HCL:OdroidN2

It has a SPI flash, so you just need to locally build a decent U-Boot, 
flash it to SPI and boot the .iso or JeOS-efi. Unfortunately the .iso 
got stuck last time I tried, so someone will need to re-try with a newer 
kernel or debug which driver may be missing in our initrd causing this.


Same problem with the VIM3 btw.

Sure, making it easier for users to get a working U-Boot would be nice, 
but binary blobs are not the only problem here, there's also x86_64 
binary-only tools from Amlogic that nobody is helping to replace.


Regards,
Andreas

--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (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] RE: WireGuard, kernel 5.6, openSUSE Arm

[Andreas Färber]

Salut Jimmy,

Am 02.02.20 um 14:09 schrieb jimmypierre.rouen.fra...@gmail.com:

Once final v5.6 is released and built in Kernel:HEAD, it'll be submitted to 
Kernel:stable and then openSUSE:Factory and will ultimately appear in 
Tumbleweed.

Great! Allow me to sort of rephrase my question. As far as you know does 
WireGuard work fine on openSUSE Arm please?


I do not know! To me it is just one out of dozens of Kconfig options 
that'll be new in 5.6. To get an idea of what I've been talking about in 
the previous answer, see here my last arm64 update for 5.5 cycle:


https://github.com/openSUSE/kernel-source/commit/4e170862d6ded97cf64615162818274a2559003a#diff-02a76de3564cccb6aa670bfab5fa0cbd

From my local linux-next based development trees I know that the option 
is available for both 32-bit arm and 64-bit arm64. But I have no clue 
what your favorite option does, nor how to test it, and on most new 
boards that I spend my time on enabling I don't even have Ethernet 
drivers yet.



And when kernel 5.6 will be released in April or so, WireGuard will be part 
natively, will openSUSE Arm support same? It's aarch64 the target as I believe 
that x64/Tumbleweed is taken care of.


To me, openSUSE Arm is Tumbleweed, and I explained the process for that.

Dunno what you mean with taken care of. Please re-read my full answer: I 
will choose whatever is chosen for x86_64 and the other openSUSE 
architectures. So if you want Michal K. to look into his crystal ball, 
you'll need to ask on opensuse-kernel list.


If you're asking whether I'll be quick enough in updating the configs, 
that I can't guarantee, -rc7 was fairly late this cycle, and 
armv6hl/armv7hl are still unfinished. If everything were great with me, 
I'd be at FOSDEM now, not answering emails...


At this stage without -rc1 this is all very hypothetical still. The 
option might get reverted upstream, for instance, if there's problems.



I run NUI.fr (basically a LUG, Computer Club) since 2001 and before telling my guys what we will be 
working on as we do have visitors and if they see us "fiddling", they will lose interest 
and negatively  "advertise" our activities.


Whatever website you run doesn't change our workflows nor that this is 
all driven by volunteers in their spare time. You'll need to be patient 
and do your own testing before you try to show it off wherever.


If you have a spare system that you can reinstall if needed, you can try 
https://build.opensuse.org/project/show/Kernel:linux-next today, at your 
own risk; CONFIG_WIREGUARD appears to be enabled as module. It gets 
updated automatically and is not QA'ed.


You'll need to figure out whether any userspace packages need to be 
added or updated to make use of the kernel option (e.g., iproute2 or 
similar NetLink based tools). I could imagine that if you expect YaST 
support for such new technologies, you might need to contribute it 
yourself. The good thing is, with OBS you can easily show your members 
how to update and test branched packages for that.


Regards,
Andreas

--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (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] RE: WireGuard, kernel 5.6, openSUSE Arm

[Andreas Färber]

Hello Jimmy,

Am 30.01.20 um 23:07 schrieb jimmypierre.rouen.fra...@gmail.com:

Linus added WireGuard in future Linux kernel 5.6.

If anyone has a roadmap of its integration in openSUSE Arm, I shall be very 
grateful.


The roadmap is same as always:

Once v5.6-rc1 has been released and I find time, I'll be updating our 
configs to the new kernel. Options that are not specific to arm/arm64 
will inherit the choices from the other architectures. Once merged in 
Git, test kernels will build in OBS Kernel:HEAD project.


Once final v5.6 is released and built in Kernel:HEAD, it'll be submitted 
to Kernel:stable and then openSUSE:Factory and will ultimately appear in 
Tumbleweed.


Cheers,
Andreas

--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (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] arm 32bit vs arm 32bit

[Andreas Färber]

Hi,

Am 10.12.19 um 16:21 schrieb Guillaume Gardet:
>> -Original Message-
>> From: Adrian Schröter 
>> Sent: 07 December 2019 12:46
>> To: openSUSE ARM ML (opensuse-arm@opensuse.org) > a...@opensuse.org>
>> Subject: [opensuse-arm] arm 32bit vs arm 32bit
>>
>> Hi,
>>
>> I was going to add 32bit package configs to repackage armv7hl libs for 
>> aarch64
>> installations (for personal need, samsung binary only printer driver)
>>
>> However, I noticed that armv7hl 32bit userland would conflict with 
>> aarch64_ilp32
>> definitions.
>>
>> Was there already any discussion how a mixed arch installation should look 
>> alike?
>>
>> My proposal would be (for a aarch64 installation):
>>
>>  armv[567]* libs should be installed in /lib (and /usr/lib) via 
>> *-32bit*.aarch64.rpm
>> /lib to stay compatible with armv[567] installations.
>>
>>  aarch64_ilp32 libs should be installed in /lib-ilp32 via 
>> *-ilp32*.aarch64.rpm
>> current config seems to put these in -32bit packages, what seems to be wrong 
>> to
>> me.
>>
>>  Do we also need to take care about aarch32?
>>
>> any opinion about this?
> 
> AFAIK, you cannot use armv7 libs/bins as is on arm64 systems.

It depends on the CPU. ThunderX and Kunpeng 920 don't support AArch32
mode, but most Cortex cores still do.

I concur that the outlined ilp32-as-32bit setup sounds wrong, in
particular since that is not even mainline-supported still.

There were discussions or even recommendations on cross-distro or so
some years back on naming/placement - Andy might remember.

As for AArch32, I assume you mean armv8l? I don't think we currently
build any packages for it, at least we have no separate scheduler.

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (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] arm-trusted-firmware and Factory

[Andreas Färber]

Hi Matwey,

Am Freitag, den 08.11.2019, 20:10 +0300 schrieb Matwey V. Kornilov:
> I've just found that arm-trusted-firmware is missed in Factory. I
> wonder
> what is the reason?

In short, build dependencies.

> I am asking because arm-trusted-firmware is required to build rk3328
> u-boot.itb which is a single supported upstream way to run u-boot.
> u-boot.itb is currently the last piece of the large puzzle to have
> JeOS-rock64 fully bootable with the upstream u-boot and kernel out of
> the box.

Please look at how we handle this in Contrib:Pine64 project, where U-
Boot is rebuilt with TF-A dependency.

An actual Factory solution will be more time-consuming.

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (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] New Tumbleweed snapshot 20190907 released! - corosync

[Andreas Färber]

Hi Guillaume,

Am Montag, den 16.09.2019, 06:53 + schrieb Guillaume Gardet:
> > -Original Message-
> > From: Andreas Färber 
> > Sent: 15 September 2019 20:47
> > To: opensuse-arm@opensuse.org
> > Subject: Re: [opensuse-arm] New Tumbleweed snapshot 20190907
> > released! -
> > corosync
> > 
> > Am 13.09.19 um 15:04 schrieb Guillaume Gardet:
> > > Packages changed:
> > [...]
> > >   busybox
> > >   ceph (14.2.2.348+gf6da3d1d18 -> 14.2.2.354+g8878cf2360)
> > >   cronie
> > >   dhcp
> > [snip]
> > 
> > In my upgrade from 20190814 I also saw this, missing from above
> > list:
> > 
> > (252/276) Installieren: corosync-2.4.5-2.1.aarch64
> > .[fertig]
> 
> I guess corosync is not on the DVD. As stated on the header:
> The described changes are computed based on the aarch64 DVD. The full
> online repo contains too many changes to be listed here.

I don't mind whether it's in a list or not. The implied question is,
are you or anyone aware of the below errors this package generates (on
a JeOS-raspberrypi3 image) and is there already a Bugzilla tracking it?
You didn't mention any known issue - this threads seems the perfect
place to collect them per snapshot.

> > Zusätzliche rpm-Ausgabe:
> > Updating /etc/sysconfig/corosync ...
> > /var/tmp/rpm-tmp.LTra7O: line 67: [: -eq: unary operator expected
> > /var/tmp/rpm-tmp.LTra7O: line 71: [: -gt: unary operator expected

I don't knowingly use this package and certainly didn't touch its
config, so this looks scary! I wonder how it passed openQA - maybe
because it's "not on the DVD" and the tests need to be expanded? Or
does zypper not make such rpm scriplet errors available to the caller
and needs to be amended?

Thanks,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 247165 (AG München)

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

Re: [opensuse-arm] New Tumbleweed snapshot 20190907 released! - corosync

[Andreas Färber]

Am 13.09.19 um 15:04 schrieb Guillaume Gardet:
> Packages changed:
[...]
>   busybox
>   ceph (14.2.2.348+gf6da3d1d18 -> 14.2.2.354+g8878cf2360)
>   cronie
>   dhcp
[snip]

In my upgrade from 20190814 I also saw this, missing from above list:

(252/276) Installieren: corosync-2.4.5-2.1.aarch64
.[fertig]
Zusätzliche rpm-Ausgabe:
Updating /etc/sysconfig/corosync ...
/var/tmp/rpm-tmp.LTra7O: line 67: [: -eq: unary operator expected
/var/tmp/rpm-tmp.LTra7O: line 71: [: -gt: unary operator expected

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 247165 (AG München)
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Re: katacontainers broken on non-x86_64 architectures

[Andreas Färber]

Hi Guillaume,

Am 04.09.19 um 17:21 schrieb Guillaume Gardet:
>> Am 04.09.19 um 13:03 schrieb Marco Vedovati:
>>> On 9/4/19 9:14 AM, Guillaume Gardet wrote:
 katacontainers and katacontainers-image-initrd  are broken on non-
>> x86_64 architectures.

 The main reason is katacontainers-image-initrd requires kernel-kvmsmall
>> which is available only on x86_64 and katacontainers package now requires it.
 So, should we use kernel-default on other archs, or should we add
>> kvmsmall to kernel flavors on non-x86_64?
>>>
>>> It would be preferable to have kvmsmall flavor for non-x86 too. That's
>>> what I started to do here:
>>> https://bugzilla.suse.com/show_bug.cgi?id=1137361
>>>
>>> However this ended up being less simple than expected. If you are
>>> knowledgeable about the topic, I'm looking for help :-)
>>
>> Not aware of that bug, I am maintaining the four (five) arm flavors in my
>> spare time and that is not working well, with armv6hl and armv7hl 5.3 still
>> missing on master branch for weeks. So adding another separately
>> maintained flavor to my plate will not be appreciated. I'd much prefer the
>> default (aarch64) and lpae (armv7hl) flavors to be reused please.
> 
> Please note that kvmsmall is "just" a diff from default flavor, similar to 
> 64kb flavor, but with more lines. 

The problem I see in
https://kernel.opensuse.org/cgit/kernel-source/tree/config/x86_64/kvmsmall
is that lots of drivers and subsystems get blacklisted (I2C, USB,
SENSORS, ...). So kvmsmall would need active work to stay small.

By comparison, 64kb is just changing a handful of settings and usually
does not need to be updated by me.

https://kernel.opensuse.org/cgit/kernel-source/tree/config/arm64/64kb

> If you run out of time to update some kernel configs, just ping me. IIRC, 
> Yousaf and Matthias did some updates in the past, as well.

I will likely not manage before Plumbers and Labs. Sorry.

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 247165 (AG München)
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

[opensuse-arm] Re: katacontainers broken on non-x86_64 architectures

[Andreas Färber]

Hi,

Am 04.09.19 um 13:03 schrieb Marco Vedovati:
> On 9/4/19 9:14 AM, Guillaume Gardet wrote:
>> Hi,
>>
>> katacontainers and katacontainers-image-initrd  are broken on non-x86_64 
>> architectures.
>>
> 
> Hi Guillaume,
> 
> thanks for your interest in the katacontainers packages.
> 
> FYI kata packages were recently added in Factory, and I gave priority to
> x86 as that's the only architecture I could run tests on.
> 
> I'm adding Penny in Cc, she's a kata contributor for the ARM
> architecture, as she kindly accepted to help us getting packages working
> for aarch64.
> 
>> The main reason is katacontainers-image-initrd requires kernel-kvmsmall 
>> which is available only on x86_64 and katacontainers package now requires it.
>> So, should we use kernel-default on other archs, or should we add kvmsmall 
>> to kernel flavors on non-x86_64?
> 
> It would be preferable to have kvmsmall flavor for non-x86 too. That's
> what I started to do here: https://bugzilla.suse.com/show_bug.cgi?id=1137361
> 
> However this ended up being less simple than expected. If you are
> knowledgeable about the topic, I'm looking for help :-)

Not aware of that bug, I am maintaining the four (five) arm flavors in
my spare time and that is not working well, with armv6hl and armv7hl 5.3
still missing on master branch for weeks. So adding another separately
maintained flavor to my plate will not be appreciated. I'd much prefer
the default (aarch64) and lpae (armv7hl) flavors to be reused please.

Regards,
Andreas

> 
> I have updated katacontainers-image-initrd to use the default flavor,
> and it is now compiling on all architectures:
> https://build.opensuse.org/package/show/devel:kubic/katacontainers-image-initrd
> It should be available in Factory shortly.
> 
>> Marco, when you update a package, please do not break all non-x86_64 archs.
> 
> Does having a package in Factory not building on non-x86_64 archs cause
> any problems?
> 
> Thanks
> Marco
> 
>> Thanks,
>> Guillaume
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose the 
>> contents to any other person, use it for any purpose, or store or copy the 
>> information in any medium. Thank you.
>>
> 


-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 247165 (AG München)
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] About temperature sensor device

[Andreas Färber]

Am 19.06.19 um 09:33 schrieb Matthias Brugger:
> On 19/06/2019 01:21, 村川 了 wrote:
>> Do we have the list of the temperature sensor devices that openSUSE Leap 
>> 15/15.1 on Raspberry Pi 3B/3B+ can handle by default?
>> Previously I asked DTH11. But I want to know this. If yes, I want to know if 
>> I can get the data with mraa?
> 
> You can check that in the kernel config. For arm64 you can find it here:
> https://github.com/openSUSE/kernel-source/tree/master/config/arm64
> 
> The branches are the different releases of openSUSE. Branch "master" refers to
> openSUSE Tumbleweed, the others should be self explaining. Just have a look at
> the "default" config file, don't care about vanilla, you most probably won't
> ever need it.

For armv7hl there's also the lpae config that's relevant.

I would ask that we align sensor additions across armv6hl default,
armv7hl default & lpae and arm64 default configs please.

> If you find any driver you want to have enabled but isn't feel free to open a
> bug and assign it to me, Guillaume or Andreas.
> 
> You can also send patches to opensuse-ker...@opensuse.org if you want to
> participate in that. Otherwise we three will do that in a best effort manner.

Note that the expected process is to enable new things in master first,
then merge or cherry-pick into stable and/or openSUSE-x.y branches, to
make sure we don't lose drivers with new releases.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
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] Temperature sensor of DHT11

[Andreas Färber]

Am 17.06.19 um 13:12 schrieb Matthias Brugger:
> On 17/06/2019 12:26, Guillaume Gardet wrote:
>> DHT11 driver is not enable: 
>> https://kernel.opensuse.org/cgit/kernel-source/tree/config/arm64/default?h=openSUSE-15.0
>> I guess we should enable it.
> 
> That's a pity. Yes we definitely should enable it. Could you send a patch? 
> While
> at it, I think it would make sense to go through IIO subsystem and enable all
> drivers as long as there is no good reason to not do that.

Whenever I updated the arm configs I did enable all new iio modules.
Unless Yousaf missed something, we probably just didn't enable old ones?
Feel free to go ahead and enable them, but try to check history for
whether someone disabled them for a reason, such as them being specific
to non-arm platforms (e.g., git blame / git gui in local repo).

I recall a few iio drivers conflicting with their hwmon counterparts.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
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] Warning: aarch64 Tumbleweed JeOS images may require a manual update

[Andreas Färber]

Hi,

Am 11.06.19 um 12:48 schrieb Guillaume Gardet:
> People using Tumbleweed on aarch64  from an "old" JeOS image may not have 
> Tumbleweed update repo enabled out of the box.
> So, you can add it with:
>  zypper ar -f http://download.opensuse.org/ports/aarch64/update/tumbleweed/ 
> repo-update
> 
> This will prevent breakage or repair your current setup, as you need some 
> libopenssl fix from this update repo to prevent some segfault with zypper on 
> current Tumbleweed snapshot.

I've documented my test case of yast - it is still a problem on armv7hl:

https://bugzilla.opensuse.org/show_bug.cgi?id=1138371

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
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] pxe for Raspberry Pi

[Andreas Färber]

Am 14.06.19 um 21:46 schrieb Michal Suchánek:
> I suspect our u-boot would need to be reconfigured to
> load grub from network.

Upstream U-Boot is already configured to fall back to network if there's
no bootable files on SD or USB. Yes, we can construct situations where
that would break, but let's start easy...

For the 3B+ it may be necessary to use an updated u-boot-rpi3 binary
from the :Update channel rather than from original Leap 15.0 release.
Symptoms would be unreliable TFTP transmissions.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
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] Is there any support for a Raspberry Pi camera in an openSUSE system?

[Andreas Färber]

Am 11.04.19 um 18:58 schrieb Freek de Kruijf:
> Op donderdag 11 april 2019 13:59:16 CEST schreef Matthias Brugger:
>> On 10/04/2019 22:02, Freek de Kruijf wrote:
>>> Before installation of kernel-default-5.1.rc4-1.1.g1478096 I changed
>>> gpu_mem to 128, however it was back to 32 afterwards. So I changed it
>>> first to 128 and later 192 (max). Did not help.
>>
>> How did you changed it? What do you mean with "it was back to 32
>> afterwards"?
> 
> After installation of the new kernel the value of gpu_mem was set back to 32. 
> It was not left alone, as I would expect.

You need to set your options in extraconfig.txt, not config.txt.
config.txt gets overwritten with default settings on package update.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
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] Drop armv6 support?

[Andreas Färber]

Am 11.04.19 um 09:29 schrieb Guillaume GARDET:
> do we have people still using openSUSE Tumbleweed on armv6 systems? Which is 
> Raspberry Pi 1, as it is the only armv6 board supported.

Raspberry Pi 0 and 0W are also armv6hl and just as supported.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
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] openSUSE 15 on Raspberry Pi 2

[Andreas Färber]

Hi,

Am 03.03.19 um 04:08 schrieb 村川 了:
> I have 2 Raspberry Pi2. I burned openSUSE15 on 32GB SDHC card.
> One of them (named A) works fine. But other one (named B) didn't boot up. 
> But Raspbian works on A and B. I changed SDHC card. But B doesn't boot up.
> Of course, I burned all images for openSUSE15  on SDHC card. But B doesn't 
> boot up.
> Does anyone know the workaround for B? Only difference is when I bought.

Some late Raspberry Pi 2 revisions got a chip upgrade and are
essentially a Raspberry Pi 3 without Wifi/BT. Please check PCB revision
and whether the chip has BCM2836 or BCM2837 written on it.

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] Raspberry Pi 3 B+ ?

[Andreas Färber]

Stefan,

Am 01.03.19 um 15:00 schrieb Stefan Seyfried:
> BTW: what is the benefit of a 64bit system on a 1GB RAM machine?

We didn't design this hardware.

AArch64 is what SUSE supports for SLES.

If you prefer to run 32-bit openSUSE on 64-bit hardware, you are free to
do that as well. There is no openQA for armv7hl or armv6hl though, and
build hardware for AArch32 is slowly getting sparse.

> Apart from breaking most of the multimedia stuff and being dog slow compared 
> to raspbian?

Don't compare apples to oranges: The Raspberry Pi guys did not upstream
their cpufreq driver, so if you compare mainline 32-bit to 64-bit the
observed difference should be fairly negligible.

There was also a discussion on the opensuse-kernel list about our
preemption config that can influence _perceived_ performance.

But as I've told you before: If you prefer other Linux distros, please
stop trolling on our opensuse-arm mailing list. Otherwise mind your tone
and feel free to contribute to making mainline Linux & openSUSE better.

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] trying out Jeos for nanopi neo air

[Andreas Färber]

Am 27.01.19 um 14:57 schrieb Per Jessen:
> Andreas Fc3a4rber wrote:
> 
>> Am 26.01.19 um 23:15 schrieb Per Jessen:
>>> Per Jessen wrote:
>>>
 I've just booted a nanopi neo air with
>>>
> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/NanoPiNeo/images/openSUSE-Tumbleweed-ARM-JeOS-nanopineoair.armv7l-2019.01.08-Build6.14.raw.xz

 and I am greeted with:

 Ubuntu 15.10 FriendlyARM ttyS0
 FriendlyARM login:

 ???
[...]
>> It sounds to me as if it's booting from eMMC and doesn't support UEFI
>> yet. 
> 
> Afaict, it's simply because the image above does not have the boot.scr.

After checking for boot.scr it should check for efi/boot/bootarm.efi.
So as I said, if it doesn't do that, your U-Boot is too old or
misconfigured and needs to be replaced.

Our image surely does not contain Ubuntu, so that must be coming from
somewhere other than our image! Either it's on an internal boot medium,
or you're having difficulties writing our image to SD card and have
leftovers on that 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] trying out Jeos for nanopi neo air

[Andreas Färber]

Am 26.01.19 um 23:15 schrieb Per Jessen:
> Per Jessen wrote:
> 
>> I've just booted a nanopi neo air with
>>
>>
> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/NanoPiNeo/images/openSUSE-Tumbleweed-ARM-JeOS-nanopineoair.armv7l-2019.01.08-Build6.14.raw.xz
>>
>> and I am greeted with:
>>
>> Ubuntu 15.10 FriendlyARM ttyS0
>> FriendlyARM login:
>>
>> ???
> 
> Having also tried with nanopineo Leap15 from ports (which worked fine),
> it appears the problem is in in the lack of a boot.scr file (in the
> above). 

As a reminder, I prepared that image about two years ago, and this is
the first real test feedback we're getting - that's why it's not in
Factory:ARM:Live but in Contrib:NanoPiNeo. So you'll need to investigate
any problems at your own, as no one else here seems to have that board.

It sounds to me as if it's booting from eMMC and doesn't support UEFI
yet. Then instead of adding an older boot method to our image, you
should upgrade your U-Boot on eMMC - extract the
/boot/u-boot-sunxi-with-spl.bin from our rpm u-boot-nanopineoair and dd
it to its expected location of seek=8k on the eMMC's mmcblkX - compare
other boards' HCL Wiki pages, e.g., Pine64.
Depending on how the Neo Air's boot flow is, erasing U-Boot on eMMC
might also make it fall back to SD, but having it on SPI or eMMC would
seem preferable, as you can then have a "normal" GPT on SD.

If the Neo Air does come with eMMC pre-populated, then we can drop this
JeOS-nanopineoair image and instead use JeOS-efi after upgrading U-Boot.
We may need to add another dtb package to JeOS-efi then.

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] Question about support for Banana Pi (M64)

[Andreas Färber]

Am 26.11.18 um 13:08 schrieb Freek de Kruijf:
> I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, and 
> started the Banana Pi M64 with it. It did boot, which I followed on the 
> serial 
> console, USB-TTL serial cable. However the Ethernet device did not come up.

Did you or did you not dd the M64 u-boot-sunxi-with-spl.bin file as I
documented on the Wiki page?

If you use the Pine64 bootloader and Device Tree, all kinds of things
can go wrong.

> I did a reboot and now the Ethernet device comes up and gets addresses. Also 
> zypper ref works.
> I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is 
> installed. There I also found u-boot-bananapim64, should that one be 
> installed?

It doesn't matter which package is installed, it only matters which
binary was written (dd'ed) to the right location on the SD card.

Uninstalling u-boot-pine64plus is certainly a good idea to avoid
mistakes, but installing u-boot-bananapim64 is only one way of obtaining
the binary to dd onto the SD card. You could also extract the .rpm on
another machine, using e.g. file-roller or command line tools.

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] pine64-image not booting on Pinebook 1080p

[Andreas Färber]

Hello,

Am 26.11.18 um 20:18 schrieb Freigeist:
> I own an 11.6" Pinebook 1080p for a few weeks now and have some problems
> getting opensuse running on it. Maybe someone can help me figuring out
> what is going wrong. I do not have a serial cable.
> 
> I am using the latest pine64 image from
> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Pine64/images/
> 
> and write it to a 32GB sdcard using the openSUSE image writer.
> 
> As I could see, these images now contain a sun50i-a64-pinebook.dtb so I
> am assuming that they should/could boot on a pinebook.

That assumption is wrong. To boot you mainly need the right bootloader,
and you're using that of the Pine64 board instead of one for Pinebook,
so all kinds of subtle differences such as display vs. HDMI or differing
Ethernet PHYs can cause problems.

Same as for the Banana Pi M64 you can use the Pine64 image as a base but
need the right U-Boot for your hardware. Otherwise it will not load the
right .dtb even if installed - it simply doesn't know it's a Pinebook.

A pinebook_defconfig exists. I don't have a Pinebook myself, so can't
test it. You could add it to the hardware:boot:staging/u-boot package,
look for pine64 in pre_checkin.sh.

Beware that there's a known serial output issue with
arm-trusted-firmware in version 2.0.

> These are my problems:
> 
> 1. Whenever I look at an sdcard with a freshly written image using
> gparted, gdisk or any other disk utility it says:
> 
> "The backup GPT table is not at the end of the disk, as it should be.
> Fix, by moving the backup to the end (and removing the old backup)?"
> "Yes" or "Ignore"
> 
> When I answer "Yes", the card is not recognized afterwards during boot
> by the pinebook anymore and the pinebook boots Arch Linux from the
> installed emmc.
> 
> When I answer "Ignore" the card is recognized during boot by the
> pinebook but the screen stays black and no matter how long I wait, the
> pinebook does not boot of it.
> 
> My questions are, is there something wrong with the image and should I
> fix it as above or leave it alone and just use it as it is when the
> image writer has finished its job?

Leave it alone. The SD card image is smaller than your card (therefore
no backup table at the end of the card) and it resizes on first boot.
If your tools make the primary GPT too large (by using its default size)
it will overwrite U-Boot at offset 8K.

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] Question about support for Banana Pi (M64)

[Andreas Färber]

Am 25.11.18 um 22:20 schrieb Alexander Graf:
> On 25.11.18 19:34, Andreas Färber wrote:
>> Am 18.10.18 um 16:45 schrieb Freek de Kruijf:
>>> Will there be support for the Banana Pi M64 with a more recent image? It 
>>> does 
>>> seem very complicated to have such an image available in the ports 
>>> repository 
>>> for aarch64.
>>
>> Please see my Wiki page: https://en.opensuse.org/HCL:BananaPi_M64
>>
>> While we don't have an image for the BPi-M64 specifically (yet), you can
>> derive one from JeOS-pine64 by replacing its U-Boot as described above.
>>
>> Note that some images like these cannot appear on the download server in
>> the official places because they depend on TF-A packages not in Factory.
> 
> Are you sure?

Yes! :)

> There is an upstream U-Boot port for the M64 and I don't
> see anything striking me that would require ATF modifications compared
> to the Pine64.
> 
> So it would be a good start to just try and build pine64 ATF + upstream
> U-Boot compiled for M64.

Why?! I packaged u-boot-bananapim64 myself (as linked in the Wiki above)
and updated arm-trusted-firmware to support A64. TF-A has downstream
dependencies in hardware:boot (HiKey) and therefore TF-A cannot go to
Factory until those get resolved. Ideas welcome.

Both hardware:boot and Contrib:Pine64 build mainline U-Boot with
mainline TF-A. There is no need to use arm-trusted-firmware-pine64
anymore, it is unused now and IMO candidate for deletion if no bug
reports arrive for the current A64 and H5 based U-Boot packages.

Regards,
Andreas

> 
> My suggestion to you Freek would be to join us in IRC on Freenode's
> #opensuse-arm channel and we'll try to figure this out together.
> 
> 
> Alex

-- 
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] Question about support for Banana Pi (M64)

[Andreas Färber]

Hi Freek,

Am 18.10.18 um 16:45 schrieb Freek de Kruijf:
> Will there be support for the Banana Pi M64 with a more recent image? It does 
> seem very complicated to have such an image available in the ports repository 
> for aarch64.

Please see my Wiki page: https://en.opensuse.org/HCL:BananaPi_M64

While we don't have an image for the BPi-M64 specifically (yet), you can
derive one from JeOS-pine64 by replacing its U-Boot as described above.

Note that some images like these cannot appear on the download server in
the official places because they depend on TF-A packages not in Factory.

I'm seeing issues with my serial console not working reliably (only
fragments; already tried multiple known-working cables) but it boots up
okay with 4.19.1 and I could ssh into the resulting image.

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] Cubox-i Tumbleweed JeOS images broken

[Andreas Färber]

Hi Josua,

Am 15.09.18 um 17:03 schrieb Josua Mayer:
> I just tried the two available JeOS images for cubox-i:
> openSUSE-Tumbleweed-ARM-JeOS-cuboxi.armv7l-2018.08.13-Snapshot20180905.raw.xz
> openSUSE-Tumbleweed-ARM-JeOS-cuboxi.armv7l-2018.08.13-Snapshot20180822.raw.xz
> 
> Both fail at booth with
> Loading kernel...
> Loading initrd...
> [    0.303128] Initramfs unpacking failed: junk in compressed archive

http://bugzilla.opensuse.org/show_bug.cgi?id=1104833

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: Re : Re: [opensuse-arm] Re : Re: Re : Re: [opensuse-arm] Re: Control output pin on RPi

[Andreas Färber]

Hi Guillaume,

Am 06.09.2018 um 18:56 schrieb Guillaume GARDET:
> ----- Andreas Färber  a écrit :
>> Am 06.09.2018 um 09:15 schrieb Guillaume GARDET:
>>> - Volker Kuhlmann  a écrit :
>>>> On Thu 06 Sep 2018 03:42:50 NZST +1200, Guillaume GARDET wrote:
>>>>
>>>>> For information, I created a wiki page for GPIO as it seems to be a 
>>>>> problem for some people: 
>>>>>   https://en.opensuse.org/openSUSE:GPIO
>>>>
>>>> Great! However all that info is readily available, and the 2 pieces of
>>>> info that stopped me from making things work are missing on that page:
>>>>
>>>> "For Leap 15.0, you need to install it from 'hardware' repo. One click
>>>> installation is also available"
>>>>
>>>> Ooops, not so. The hardware repo does not have libgpiod for any ARM
>>>> because it's disabled!!, and I dare say most such boards do not run
>>>> x86...
>>>
>>> Indeed, I will ask to get the hardware repo building for ARM.
>>
>> You're the libgpiod maintainer, so you can check those boxes yourself.
> 
> The problem was there was no Leap 15.0 ARM repo, I asked this morning to get 
> it added. ;)
> 
>> I've done it for you now.
> 
> Thanks.
> Yes, some packages are disabled for ARM, not sure why.

For build power reasons i had added arm but disabled it by default.
Packages that need arm builds (e.g., raspberrypi-firmware) can then
enable it as needed. For Leap 15.1 please help ensure that libgpiod gets
included in the distro, then we won't need extra builds in hardware.

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] Cubieboard2 versions 2012+2015

[Andreas Färber]

Am 28.08.2018 um 13:36 schrieb Volker Kuhlmann:
> There are 2 different cubieboard2 versions:
> http://dl.cubieboard.org/model/CubieBoard2/
> 
> The 2012 one has nand flash, or TSD flash but I expect that's uncommen.
> 
> The 2015 one has EMMC or TSD flash, nand flash versions don't exist, and
> a battery for a RTC.
> 
> Apparently the EMMC and TSD versions are interchangeable, and that flash
> behaves like an SD card.
> http://dl.cubieboard.org/model/CubieBoard2/CubieBoard2-20151211-EMMC/Docs/Linux/CubieBoard2-20151211-EMMC-Linux-installation-guide-V1.0.pdf
> 
> Has anyone tested openSUSE on a 2015 version of cubieboard2? Or is the
> JeOS image for the 2012 version? Or both?

Both U-Boot and kernel dts don't distinguish such two CB2 versions.
In the kernel .dts I spotted an mmc0 node FWIW.

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] Which packages for yast2?

[Andreas Färber]

Am 21.08.2018 um 13:45 schrieb Volker Kuhlmann:
> On Tue 21 Aug 2018 23:11:52 NZST +1200, Axel Braun wrote:
> 
>> For sure, if you install the qt component, there will be a bunch of 
>> dependencies behind.
> 
> Yes, but plotting software and a postscript interpreter - for a GUI, for
> a program hat already has the equivalent ncurses functionality installed?!???

This YaST discussion has little to do with arm. If you want to complain
about general packaging, try opensuse-factory list.

As Guillaume pointed out, this is most likely due to recommended rather
than required packages.

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] How to get openSUSE aarch64 on a RPi3B+?

[Andreas Färber]

Am 16.08.2018 um 09:37 schrieb Volker Kuhlmann:
> Tumbleweed, 2 months older, gives the same result. Not very useful.

That's really boring to hear, as it means you're not reading this list!
We've explained so many times a) how to download a newer image that
works, b) how to fix the old published image to boot.

Hint: /boot/efi/*config.txt are the relevant files, not /boot/vc/*.

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] How to debug Grub config

[Andreas Färber]

Am 30.07.2018 um 18:35 schrieb Matwey V. Kornilov:
> 2018-07-30 14:23 GMT+03:00 Alexander Graf :
>> On 07/29/2018 01:19 PM, Matwey V. Kornilov wrote:
>>> I am (stilL) trying to boot openSUSE on Rock64. I use JeOS image from
>>> Contrib:Rockchip and manually built bootloader (with
>>> 0001-XXX-openSUSE-XXX-Prepend-partition-.patch).
[...]>> What U-Boot version are you basing on? There were a few
>> bugs with the device path exposure in 2018.05 IIRC.
> 
> I am running downstream u-boot with rock64 support:
> https://github.com/ayufan-rock64/linux-u-boot
> It is based on 2017.09

What's missing for Rock64 in upstream? There's some RK3328 EVB code:
https://git.denx.de/?p=u-boot.git;a=tree;f=board/rockchip/evb_rk3328;h=1d01065444611e4512a57072f97a6f39c30239fa;hb=HEAD

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] How to get openSUSE aarch64 on a RPi3B+?

[Andreas Färber]

Am 30.07.2018 um 07:33 schrieb Sten Bert:
> Here's my result for Leap 15.0 from
> http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/appliances/:
> 
> xzcat
> openSUSE-Leap15.0-ARM-JeOS-efi.aarch64-2018.07.02-Buildlp150.1.1.install.tar.xz
> | dd bs=4M of=/dev/sdf iflag=fullblock oflag=direct; sync

.tar.xz != .raw.xz
And that's not a -raspberrypi3 image either.

If you dd the wrong file it can't possibly work. :)

> openSUSE-Leap15.0-ARM-LXQT-raspberrypi3.aarch64-2018.07.02-Buildlp150.1.1.raw.xz
> 
> - booted after activating 1st partition as active, but stopped with 
> "incompatible licence, Press any key to continue"

Don't understand what exactly you're doing there and where exactly
you're seeing that message.

> - with and without extraconfig.txt

If it boots, you don't have to touch extraconfig.txt. You only need that
if ubootconfig.txt with that contents is missing (it was moved from one
file to another and - Murphy's Law - the Tumbleweed image got published
in between).

Cheers,
Andreas

P.S. Please don't top-post.

-- 
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] How to get openSUSE aarch64 on a RPi3B+?

[Andreas Färber]

Am 29.07.2018 um 17:20 schrieb Sten Bert:
>>>I have a perfectly running system with this image. Indeed /dev/sdf1
> needs to be /dev/sdf, there will be two partitions on the SD card and a
> lot of unused space.<<
> 
> Freek - are you talking about the RPi3b+?
> I have the actual (this year - 2018) board RPi3B+ and I'm looking for an
> (openSUSE!)image, that at least boots this board!
> From http://download.opensuse.org/ports/aarch64/ I took different
> xz-Images (15.0 JeOS, 15.0 LXQT, 42.3 JeOS). - They all produce
> different sd-card partition layouts! But none of them boots a RPi3B+!

You somehow appear to assume that the image not booting has anything to
do with the B+. Please don't try things like a headless chicken. Either
you want Tumbleweed or you want Leap 15.0. No point messing with 42.3
still, which never supported the B+. Using an old release because of a
problem with a newer one is rarely a good idea.

SLES 15 boots on the B+, so I'd be surprised if Leap 15.0 doesn't.

As I've tried to hint you, the latest published Tumbleweed image is
known broken and therefore I told you to use the latest built image
instead. If you're unwilling to set up an openSUSE account (which you'd
also need to report new bugs!), then you could also add a one-line
extraconfig.txt to the EFI partition with the missing aarch64 setting
"arm_control=0x200". Most problems are solvable if you ask the right
questions...

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] Rasberry Pi 3B image openSUSE Tumbleweed starts on Banana Pi M64

[Andreas Färber]

Am 22.07.2018 um 13:26 schrieb Freek de Kruijf:
> Instead of a Banana Pi M3 I got a Banana Pi M64, of which I was uncertain 
> that 
> the processor was the same as the one on a Raspberry Pi 3B.

It is not. Allwinner vs. Broadcom.

> My experiments with it will be continued, but if you have any advice I will 
> be 
> happy to receive it.

My advice: Don't do that. Use a proper image, don't reuse Raspberry Pi
images on non-Raspberry-Pi boards. Same for most other boards, but the
Raspberry Pi uses a special MBR partitioning whereas you want GPT here.
Not to mention "wrong" bootloader packages.

If apparently you have the bootloader on eMMC instead of SD, you can use
the generic JeOS-efi.aarch64 image, for instance.

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

[opensuse-arm] Why JeOS-efi removal?

[Andreas Färber]

Hi Guillaume,

Why is your sr#621203 deleting the JeOS-efi flavor? I don't see any
discussion here about this change, nor any bug report referenced.

Thanks,
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] opensuse.org and openSUSE ARM

[Andreas Färber]

Hi Matwey,

Am 16.06.2018 um 13:09 schrieb Matwey V. Kornilov:
> 
> Hi all,
> 
> I think it is important that there is no way to figure out that openSUSE
> available at ARM architecture reading site www.opensuse.org
> 
> Trying to "download" Linux, I end up on
> https://software.opensuse.org/distributions/leap?locale=en where only
> x86_64 is available.
> 
> In my opinion we could highlight presence of ARM port for a few
> best-supported SBCs (for instance, Raspberry Pi, BeagleBone, QEMU/EFI).
> 
> What do you think?

It needs someone to do it. ;) Richard Brown had a proposal somewhere in
Git for both Arm and PowerPC ports a while ago (on opensuse-factory?),
but if it's still not there, apparently no one took up that project.

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] Problem running python script using GPIO

[Andreas Färber]

Am 14.06.2018 um 21:06 schrieb Freek de Kruijf:
> I inspected build.opensuse.org and found that in the project hardware / 
> python-RPi.GPIO the patch is included. However generating it for armv6l, 
> armv7l, and aarch64 in openSUSE_Factory_ARM is disabled. It is not mentioned 
> for these architectures for Leap 42.3 and 15.0 and for Tumbleweed.
> 
> Could this be enabled, such that the package appears in a repository, 
> preferably the standard repository for Leap 42.3, 15.0 and Tumbleweed?

Done for Factory ARM - the other repositories need to be set up first.

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] Beagle Board Black boot from µSD

[Andreas Färber]

Am 31.05.2018 um 13:20 schrieb Guillaume Gardet:
> Le 31/05/2018 à 12:42, Roger Oberholtzer a écrit :
>> Time to get a board and see what it can do. It is the ARM's PRU that
>> makes this board interesting.
>>
> 
> I think Andre[a]s (in Cc) played with PRU already.

I had prepared a cross-compiler toolchain, but it was not yet upstream
at the time and I haven't updated the packages for some years - SRs welcome.

https://build.opensuse.org/project/show/home:a_faerber:pru

Matwey and Alex will know more, but at the time there was only a uio
driver. The remoteproc driver was still missing upstream, and I still
don't see any with pru in the name:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/remoteproc

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] Beagle Board Black boot from µSD

[Andreas Färber]

Am 31.05.2018 um 09:02 schrieb Roger Oberholtzer:
> I want to explore the ARM PRU (programmable
> real-time unit).

Please note that the PRU has nothing to do with arm. It's a TI thing and
needs its own toolchain that openSUSE does not provide at this time.

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

[opensuse-arm] New package: python-pyOCD

[Andreas Färber]

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

Re: [opensuse-arm] New kiwi and firmware=custom problem

[Andreas Färber]

Am 04.04.2018 um 14:53 schrieb Alexander Graf:
>> Am 04.04.2018 um 14:38 schrieb Andreas Färber <afaer...@suse.de>:
>>> Am 04.04.2018 um 11:14 schrieb Alexander Graf:
>>>> On 04.04.18 11:08, Guillaume Gardet wrote:
>>>> Le 04/04/2018 à 10:48, Marcus Schäfer a écrit :
>>>>>> 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".
>>>
>>> This is not true. For those boards, we can still use EFI, but need to
>>> convert to MBR. This is done in uboot-image-install.in in section
>>> "Convert GPT to MBR if necessary".
>>>
>>> The only case I'm aware of where EFI is not a viable option is when we
>>> rely on U-Boot that is delivered with the system, but doesn't have
>>> efi_loader enablement. Apart from moonshot and midway I'm not aware of
>>> any such system still alive.
>>
>> Is 32-bit Allwinner working with UEFI by now? Last time I tried it still
>> fell apart and thus needed boot.scr.
> 
> Why does it fall apart? I‘m not aware of anything specific to Allwinner 
> devices that would make it fail.

I didn't figure out and I haven't heard from anyone since. Probably
missing memory reservations? IIRC my Cubietruck got into GRUB but had
problems loading the kernel, hanging.

Jetson TX1 was another case where UEFI was not working. It aborts and
resets when loading GRUB.

Dragonboard 410c was another such case I reported in the past.

Theoretically they're all fixable, but right now there are a couple
platforms where UEFI in U-Boot is not working.

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] New kiwi and firmware=custom problem

[Andreas Färber]

Am 04.04.2018 um 11:14 schrieb Alexander Graf:
> On 04.04.18 11:08, Guillaume Gardet wrote:
>> Le 04/04/2018 à 10:48, Marcus Schäfer a écrit :
 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".
> 
> This is not true. For those boards, we can still use EFI, but need to
> convert to MBR. This is done in uboot-image-install.in in section
> "Convert GPT to MBR if necessary".
> 
> The only case I'm aware of where EFI is not a viable option is when we
> rely on U-Boot that is delivered with the system, but doesn't have
> efi_loader enablement. Apart from moonshot and midway I'm not aware of
> any such system still alive.

Is 32-bit Allwinner working with UEFI by now? Last time I tried it still
fell apart and thus needed boot.scr.

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] RPi3 Leap image links broken

[Andreas Färber]

Am 24.01.2018 um 16:34 schrieb Freek de Kruijf:
> Op woensdag 24 januari 2018 13:57:08 CET schreef Andreas Färber:
>> Am 24.01.2018 um 13:06 schrieb Freek de Kruijf:
>>> Op woensdag 24 januari 2018 12:32:31 CET schreef Alexander Graf:
>>>>> Am 24.01.2018 um 12:11 schrieb Freek de Kruijf <fr...@opensuse.org>:
>>>>> Made links point to the right images. Only there is no LXQT image at
>>>>> all.
>>>>
>>>> The links were correct; something went wrong during publishing that did
>>>> not
>>>> create symlinks on the web server, hence the email to Adrian.
>>>>
>>>> If you change the web links to a specific version, any change to the JeOS
>>>> sources will make them obsolete again and we‘ll be stuck in a busy loop
>>>> fixing web links all day :).
>>>
>>> The images for Leap 42.3 should not change anymore, any update should be
>>> done on the update repository.
>>
>> No, the Ports project is not frozen, and the Ports images are not part
>> of the Update repository.
>>
>> Regards,
>> Andreas
> 
> I disagree. This is the output of zypper lr on my RPi3 with Leap 42.3.
> 
> 1 | openSUSE-Ports-Leap-42.3-Update   | openSUSE-Ports-Leap-42.3-Update 
> 2 | openSUSE-Ports-Leap-42.3-repo-oss | openSUSE-Ports-Leap-42.3-repo-oss
> 
> I never saw anything updated from the repo-oss. It is frozen as it should.

Where you get updates or not says nothing about image-building in OBS.
Please look at OBS before arguing I'm wrong - I did check.

https://build.opensuse.org/project/show/openSUSE:Leap:42.3:Ports

Thanks,
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] RPi3 Leap image links broken

[Andreas Färber]

Am 24.01.2018 um 13:06 schrieb Freek de Kruijf:
> Op woensdag 24 januari 2018 12:32:31 CET schreef Alexander Graf:
>>> Am 24.01.2018 um 12:11 schrieb Freek de Kruijf :
>>> Made links point to the right images. Only there is no LXQT image at all.
>>
>> The links were correct; something went wrong during publishing that did not
>> create symlinks on the web server, hence the email to Adrian.
>>
>> If you change the web links to a specific version, any change to the JeOS
>> sources will make them obsolete again and we‘ll be stuck in a busy loop
>> fixing web links all day :).
> 
> The images for Leap 42.3 should not change anymore, any update should be done 
> on the update repository.

No, the Ports project is not frozen, and the Ports images are not part
of the Update repository.

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] rock64

[Andreas Färber]

Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov:
> 2018-01-02 18:27 GMT+03:00 Andreas Färber <afaer...@suse.de>:
>> Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
>>> Why didn't we allocate separate GPT partition for each bootloader
>>> image? It seems to be generic way to denote that specific place at SD
>>> card is allocated and used by something.
>>
>> Kiwi only supports a few partitioning schemes, it does not allow to add
>> random other partitions AFAIK. Every scheme needs to be defined in the
>> XML Schema and needs a matching implementation in Kiwi.
>>
>> Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?
> 
> Nope. Where can I find it?
> 
> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64
> 
> This one?

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/pine64-instsd

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] rock64

[Andreas Färber]

Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
> 2017-09-02 13:25 GMT+03:00 Andreas Färber <afaer...@suse.de>:
>> Hi,
>>
>> Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:
>>> 1. Tools from https://github.com/rockchip-linux/rkbin are required to
>>> prepare u-boot binary to be deployed into sd-card. The tools are
>>> permitted to be redistributed, but they are x86_64-only binary blobs.
>>> I think we could package them in RPM package and wrap them using
>>> qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64
>>> architecture).
>>
>> Negative. Same topic came up for Amlogic, and I had to develop the
>> native Open Source meson-tools instead.
>>
>> For creating a JeOS image we need to use U-Boot SPL, which as I already
>> pointed out should avoid all those binary-only x86 tools.
>>
>> If that is not working yet (you did not say), then we can just document
>> the x86-only steps to keep them out of OBS.
>>
>>> 2. bootloader are required to be placed at +16MB offset from the
>>> beginning of SD card. We have to find a way to specify KIWI to place
>>> EFI partition not at 2048sector as default.
>>
>> Yousaf gave a presentation on how to accomplish that for RK3399.
>>
>> If this reservation is implemented, then similar to my JeOS-nanopik2
>> image we could just leave out U-Boot and give users Wiki instructions on
>> how to place U-Boot there themselves.
> 
> Why didn't we allocate separate GPT partition for each bootloader
> image? It seems to be generic way to denote that specific place at SD
> card is allocated and used by something.

Kiwi only supports a few partitioning schemes, it does not allow to add
random other partitions AFAIK. Every scheme needs to be defined in the
XML Schema and needs a matching implementation in Kiwi.

Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?
That should allow to create custom bootloader partitions. Just keep in
mind that U-Boot might check only the first partition if none is flagged
as bootable, so you may want to keep EFI first even if physically second.

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] RaspberryPi 3 and wifi

[Andreas Färber]

Hello Hartmut,

Am 29.12.2017 um 17:10 schrieb Hartmut Krummrei:
> "it should" but it is not! And I can not create a file which content I
> do not know. Send me such content and I will edit.
> 
> Hartmut
> 
> Am 29.12.2017 um 13:13 schrieb Manu Maier:
>> Hello Hartmut,
>>
>> my suggestion with the raspberrypi_modules.conf file refers to both Leap
>> 42.2 and 42.3.
>> It should also be present in Leap 42.3.
>> Look here:
>> https://build.opensuse.org/package/view_file/openSUSE:Leap:42.3:Ports/JeOS/config.sh?expand=1
>>
>> Line: 1310 to 1312

^^^

Apparently you didn't look at the link provided, it has the three lines
of contents for you.

Cheers,
Andreas

>>
>> Just create the raspberrypi_modules.conf file with the content and try
>> it out.
>>
>> Regards,
>> Manu
-- 
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] RPi 3 video requires CMA memory which is not automatically configures

[Andreas Färber]

Am 28.12.2017 um 16:29 schrieb Michal Suchánek:
> On Mon, 25 Dec 2017 22:18:45 +0100
> Alexander Graf  wrote:
>> On 25.12.17 18:36, Michal Suchánek wrote:
>>> Hello,
>>>
>>> for testing I installed stable and master kernel on Leap 42.3 E20
>>> image.
>>>
>>> Initially it would work fine but later I would have to add cma=256MB
>>> (some random value found on a forum) to kernel commandline for video
>>> output to work.
>>>
>>> Has the cma requirement changed as a result of recent vc4 changes?  
>>
>> No, it's always been there. In the early days we had a default CMA
>> size of 64MB IIRC, but given that a good number of platforms don't
>> need any CMA space at all, it seemed like a wasted allocation.
>>
>> For the RPi, we added a CMA command line parameter to the kiwi file to
>> override the default 0MB allocation. Maybe something went wrong and
>> that change never happened in Leap 42.3?
> 
> Maybe 42.3 dose not really need it because it does not have the driver
> in the kernel or still has the 64MB default.
>>
>>> Can the kernel allocate the required size automatically?  
>>
>> Yes, if you tell it on the kernel command line :).
> 
> I do not have to tell the kernel I have an integrated Intel graphics
> card and it can still allocate its buffers just fine. 
> 
>> Really, CMA is all
>> about reserving a range of memory space for contiguous allocations, so
>> all allocations happening inside that range have to be movable and can
>> be forced to move at any given point in time.
>>
>> I'm not quite sure what the kernel should do more automatically than
>> it already does.
> 
> Just allocate the buffer whenever there is a vc4 card :)

The RPi does not have an IOMMU, so it needs to pre-allocate a contiguous
hunk of memory, unlike other Intel or Arm based systems.

HTE,
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] Raspberry Pi 3 interrupt handling

[Andreas Färber]

Am 13.12.2017 um 15:42 schrieb Roger Oberholtzer:
> On Wed, Dec 13, 2017 at 2:28 PM, Alexander Graf  wrote:
>> On 13.12.17 14:00, Roger Oberholtzer wrote:
>>> On Wed, Dec 13, 2017 at 1:35 PM, Alexander Graf  wrote:
>>>
 Would it make sense to resort to polling at those speeds instead? Maybe
 poll using a constant reoccuring hrtimer?
>>>
>>> Granted polling does not have the interrupt overhead. But I wonder how
>>> it keeps up with respect to scheduling. Might one miss activity when
>>> the kernel thread is not running?
>>
>> Depends on how bad your jitter is, but I would hope that you'll get
>> better granularity than 23khz ;).
> 
> If jitter is too big, then perhaps if more than one interrupt is
> pending when already in an interrupt, only the first one is seen. I do
> not think interrupts are stacked.

I might be wrong, but isn't that the point of "chained" interrupts?

In my example code you can also see me playing with "threaded" interrupts.

This is the only official documentation I could find:
https://www.kernel.org/doc/html/latest/core-api/genericirq.html

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] Raspberry Pi 3 interrupt handling

[Andreas Färber]

Am 12.12.2017 um 19:32 schrieb Andreas Färber:
> Am 30.11.2017 um 10:59 schrieb Roger Oberholtzer:
>> We have written a minimal kernel interrupt handler for the Raspberry
>> Pi 3. It is running the current 64-bit Tumbleweed kernel. I am curious
>> about the rate of interrupts that we might be able to capture.
[...]
> Personally I haven't had any success using GPIO interrupts on my rpi3,
> but that may be a matter of the device/driver (SX1276) I tried it with.

FTR it was indeed a custom driver issue for me, I succeeded last night.
I get only a single TX Done interrupt though, so still can't comment on
maximum achievable rates.

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] Raspberry Pi 3 interrupt handling

[Andreas Färber]

Hi Roger,

Am 30.11.2017 um 10:59 schrieb Roger Oberholtzer:
> We have written a minimal kernel interrupt handler for the Raspberry
> Pi 3. It is running the current 64-bit Tumbleweed kernel. I am curious
> about the rate of interrupts that we might be able to capture.
> 
> The ISR does little other than run when a raising edge interrupt
> happens. We are looking at /proc/interrupts to see how many interrupts
> have happened.
> 
> We see that at around 23 kHz we begin to loose interrupts. The system
> is not doing anything else.
> 
> Does that seem reasonable? I have not seen any good discussion of
> this. I think it is rather low. I am guessing that the issue is how
> the Linux kernel responds to interrupts. The housework in setting
> things up so that the interrupt can run must be the resource hog.
> 
> Opinions? Suggestions?

I don't see anything openSUSE-specific in here, so I'd suggest to ask on
upstream linux-rpi-kernel list about any performance expectations.

Personally I haven't had any success using GPIO interrupts on my rpi3,
but that may be a matter of the device/driver (SX1276) I tried it with.

Can you share any more details on DT overlay or driver init you're using
to set up the interrupt? What's your interrupt source?

Regards,
Andreas

https://github.com/afaerber/lora-modules/blob/9c5fcb64d7dac953c29da527d0f929efbef4c07e/sx1276.c#L315

-- 
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] No DMA on Raspberry Pi 3B using latest image

[Andreas Färber]

Am 12.12.2017 um 10:11 schrieb Andreas Schwab:
> On Dez 12 2017, Andreas Färber <afaer...@suse.de> wrote:
> 
>> [...] You can see "a year ago" here:
>>
>> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:RaspberryPi3
> 
> Shouldn't the project be deleted then?

IMO yes - done, and removed from Wiki as well.

For reference the recommended alternatives are:
* Tumbleweed image with Tumbleweed kernel
* Leap 42.3 image with Leap kernel

I've also updated the Wiki page to point to 42.3 instead of 42.2 image.

https://en.opensuse.org/HCL:Raspberry_Pi3

>  Why does it build against
> Factory when it uses the 42.2 kernel?

I guess because that was where Wifi support was originally developed...

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

[opensuse-arm] ATF and U-Boot (was: [aarch64] TW on Pinebook?)

[Andreas Färber]

Am 11.12.2017 um 21:47 schrieb Andrew Wafaa:
> On 11 December 2017 at 20:23, Andreas Färber <afaer...@suse.de> wrote:
>> Am 11.12.2017 um 14:22 schrieb Alex Naumov:
>>> do we want to integrate everything what Pinebook needs to our TW
>>> images OR we would like to have separate images for it?
>>
>> I don't think it's possible to combine the Pinebook into an existing
>> image, as it likely needs its own U-Boot with matching Device Tree.
>>
>> That leaves us with two options:
>>
>> a) Derive a new separate image once all needed packages are in place. As
>> long as arm-trusted-firmware is not in Tumbleweed, such an image can
>> only live in some Contrib repository, not officially part of Tumbleweed.
>>
> 
> Is there a particular reason why arm-trusted-firmware isn't in
> Tumbleweed yet? Sorry but I missed any previous discussion on ATF.

Short summary: U-Boot is in Base:System devel project and for some
boards now has a soft dependency on ATF - builds okay but won't work.
Base:System has so few maintainers and keeps blocking and rebuilding
packages (due to core packages such as glibc), that we've already
resorted to Base:System:Staging for actually being able to test new
sub-packages and updates. So I really don't want to submit my ATF
packages to Base:System.
Additionally, Andre did not yet get his Allwinner A64/H5 support merged
into upstream ATF, so an arm-trusted-firmware package today would only
help e.g. Firefly-RK3399 and Geekbox, not Pine64 or Orange Pi PC 2.

One proposed idea was a new sub-project under "hardware" (where u-boot
or arm-trusted-firmware don't fit 100%, I'm surprised vboot was accepted
despite not being about peripherals), but so far we haven't discussed
any names or alternative locations. Opinions?

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] No DMA on Raspberry Pi 3B using latest image

[Andreas Färber]

Am 12.12.2017 um 00:23 schrieb Freek de Kruijf:
> Op maandag 11 december 2017 18:05:55 CET schreef Andreas Färber:
>> Hi Freek,
>>
>> Am 11.12.2017 um 13:42 schrieb Freek de Kruijf:
>>> I used repository:
>>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/
>>> RaspberryPi3/images
>>> and downloaded the image:
>>> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.12.04-Build4.5.raw.
>>> xz to start some testing. [...]
>>
>> That's not an official image and hasn't been touched for over a year.
>>
>> Can you please try the official Tumbleweed (or Leap) image instead?
>> My headless RPi3 appears to work okay with both 4.14.3 and 4.15-rc2.
>>
>> Thanks,
>> Andreas
> 
> Very strange. As you can see the date is 2017.12.04. Yesterday it had the 
> same 
> date except the Build was 4.4. So it is very recent.

No, not my point. You can see "a year ago" here:

https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:RaspberryPi3

> Moreover the repository in /etc/zypp/repos.d/openSUSE-Ports-Tumbleweed-repo-
> oss.repo in this image is the same as the image from repository:
> http://download.opensuse.org/ports/aarch64/tumbleweed/images
> in image:
> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.11.22-Build1.13.raw.xz
> 
> I test was done on the mentioned system and upgraded using that repository, 
> except for the upgrade of the kernel.

You also need the matching dtb-allwinner package.

So the alternative would be to disable or delete your Contrib
repository, then zypper dup. But there's really no point for this detour
when there's an official image.

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] [aarch64] TW on Pinebook?

[Andreas Färber]

Hi Alex,

Am 11.12.2017 um 14:22 schrieb Alex Naumov:
> do we want to integrate everything what Pinebook needs to our TW
> images OR we would like to have separate images for it?

I don't think it's possible to combine the Pinebook into an existing
image, as it likely needs its own U-Boot with matching Device Tree.

That leaves us with two options:

a) Derive a new separate image once all needed packages are in place. As
long as arm-trusted-firmware is not in Tumbleweed, such an image can
only live in some Contrib repository, not officially part of Tumbleweed.

b) Use pine64-instsd [*] as inspiration to build a bootable SD image and
then install interactively from an .iso on USB stick.

Regards,
Andreas

[*]
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/pine64-instsd

-- 
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] No DMA on Raspberry Pi 3B using latest image

[Andreas Färber]

Hi Freek,

Am 11.12.2017 um 13:42 schrieb Freek de Kruijf:
> I used repository:
> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/
> RaspberryPi3/images
> and downloaded the image:
> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.12.04-Build4.5.raw.xz 
> to start some testing. [...]

That's not an official image and hasn't been touched for over a year.

Can you please try the official Tumbleweed (or Leap) image instead?
My headless RPi3 appears to work okay with both 4.14.3 and 4.15-rc2.

Thanks,
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] Packet fake-hwclock generated

[Andreas Färber]

Hi Freek,

Am 06.12.2017 um 15:23 schrieb Freek de Kruijf:
> In Raspbian I noticed a packet always included in the image called fake-
> hwclock. I used the tar.gz file together with a .spec file to generate this 
> packet for openSUSE distributions for systems without a Real Time Clock.
> 
> The description is:
> Some machines don't have a working realtime clock (RTC) unit, or no driver 
> for 
> the hardware that does exist.
> fake-hwclock is a simple set of scripts to save the kernel's current clock 
> periodically (including at shutdown) and restore it at boot so that the 
> system 
> clock keeps at least close to realtime. This will stop some of the problems 
> that may be caused by a system believing it has travelled in time back to 
> 1970, such as needing to perform file system checks at every boot.
> 
> On top of this, use of NTP is still recommended to deal with the fake clock 
> "drifting" while the hardware is halted or rebooting.
> 
> Hope this is accepted to be included.

You forgot to mention the link or request number you want us to accept.

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

[opensuse-arm] Re: [opensuse-factory] New Tumbleweed snapshot 20171120 released!

[Andreas Färber]

Hi Daniel,

Let's move the discussion to opensuse-arm list.

Am 23.11.2017 um 12:07 schrieb Daniel Molkentin:
> On 11/22/2017 06:31 PM, Andreas Färber wrote:
>> Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger:
>>>  kernel-source 
>>> Version update (4.13.12 -> 4.14.0)
>>> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs 
>>> kernel-macros kernel-syms
>>>
>>> - Update to 4.14-final.
>> On the aarch64 based Pine64 board it has been observed that the updated
>> dtb-allwinner package now requires the axp20x-regulator module in the
>> initrd for using the MMC driver, and its parent module axp20x-rsb does
>> not get loaded automatically even if added to the initrd.
> I would prefer if that would be fixed in the kernel by adding the proper
> dependencies.
> Is there any chance for that?

There's multiple issues at play here:

1) This is not a module compile-time dependency issue, but rather a
run-time dependency issue, which AFAIU dracut is not resolving today.

As a result the JeOS images in openSUSE:Factory:ARM etc. contain a
number of add_drivers entries to load such extra modules:
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/config.sh?expand=1
That is of course ugly and would be nice to get resolved differently.

Dracut would need to parse the Device Tree in /sys/firmware/ to discover
what regulator, clock, power domain, etc. nodes are being referenced,
then read their "compatible" strings and resolve them to the modules to
add. The kernel uses generic API calls such as clk_get() and
regulator_get(), thus no compile-time dependency for e.g. mmc modules.

However when updating from 4.13 to 4.14 or from 4.14-rc4 to -rc8 it
would've still read the current Device Tree and not discovered this new
dependency for next boot. And Kiwi images get built in KVM, which will
have a different Device Tree than the user's system or even ACPI. So I
don't see a full solution yet.

Let me know if I should report this somewhere upstream - it didn't seem
a distro-specific issue for our Bugzilla.
https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshooting
explains what info to include in a bug report, but not actually where to
file it. ;) No link on dracut.wiki.kernel.org either.

2) axp20x-rsb driver does have MODULE_DEVICE_TABLE(of, ...), so it is
unclear to me why the DT -> module resolution for auto-loading is not
working here.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/axp20x-rsb.c?h=v4.14

It is almost certainly an upstream kernel issue, possibly in sunxi-rsb
bus driver. Stefan has already reported this on #linux-sunxi.

> Otherwise, the "proper" dracut patch would
> looks something like the attached one.

Hm, instmod is just the equivalent of "add_drivers", is it? That would
not be enough here. Also not all ARM systems need this driver, it's an
extra chip on some boards only.

What you could do is more generally add all =drivers/mfd drivers. But if
we keep adding drivers by category instead of addressing the underlying
discovery issue, we risk at some point the initrd getting too large for
low-RAM systems.

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

[opensuse-arm] Re: [opensuse-factory] New Tumbleweed snapshot 20171120 released!

[Andreas Färber]

Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger:
>  kernel-source 
> Version update (4.13.12 -> 4.14.0)
> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs 
> kernel-macros kernel-syms
> 
> - Update to 4.14-final.
> - commit c152297
> - rpm/kernel-binary.spec.in: rename kGraft to KLP (fate#323682)
> - commit 0ed191d

On the aarch64 based Pine64 board it has been observed that the updated
dtb-allwinner package now requires the axp20x-regulator module in the
initrd for using the MMC driver, and its parent module axp20x-rsb does
not get loaded automatically even if added to the initrd.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts?id=3f241bfa60bdc9c4fde63fa6664a8ce00fd668c6

Workaround is to add to your /etc/dracut.conf.d/sunxi_modules.conf:

force_drivers+=" axp20x-rsb "

and (if after the update) to re-run dracut by, e.g., mkinitrd.

Without such an initrd change it will wait indefinitely for the root
partition on SD card on next boot.
Selecting an older kernel in GRUB will not help - only manually loading
an older dtb in U-Boot can help (if e.g. you had multiversion enabled).

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] Moving SoC specific files from JeOS/KIWI config.sh to separate packages

[Andreas Färber]

Hi,

Am 18.11.2017 um 09:42 schrieb Alexander Graf:
> Am 17.11.2017 um 23:46 schrieb Stefan Brüns :
>> currently config.sh creates several SoC specific files ad-hoc (i.e. using 
>> echo). This has several drawbacks:
>>
>> - it bloats config.sh (e.g 840 lines for the omap beagle /var/lib/alsa/
>> asound.state)
>> - it creates files which are not tracked by RPM
>> - most importantly, these files are never updated
> 
> There is one more problem: The mechanism only works with images, not the 
> installer.
> 
> Ideally, we could somehow get override logic like this working with the 
> installer as well. Is there some rpm magic that automatically selects a 
> package depending on dmi information for example? Or dt compatibles?

Check out the Supplements in
https://build.opensuse.org/package/view_file/hardware/bcm43xx-firmware/bcm43xx-firmware.spec?expand=1

That said, I pointed out to Stefan that it would be best to implement
the DT dependency resolution in dracut rather than cementing these
workaround configs into packages that need to be maintained forever.

That leaves a couple of blacklists or forced loads that should be
investigated and dropped once fixed in the kernel.

Remaining would then be some X11 configs that might go into generic
packages if guarded properly?

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] Moving SoC specific files from JeOS/KIWI config.sh to separate packages

[Andreas Färber]

Hi,

Am 17.11.2017 um 23:46 schrieb Stefan Brüns:
> currently config.sh creates several SoC specific files ad-hoc (i.e. using 
> echo). This has several drawbacks:
> 
> - it bloats config.sh (e.g 840 lines for the omap beagle /var/lib/alsa/
> asound.state)
[snip]

Agree that this config in particular is disturbingly large.

Alsa configs belong into alsa upstream repository and alsa packages.
I recall we cleaned that up for Snow or Spring Chromebook.

Guillaume? (or anyone else with a Beagleboard)

Thanks,
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] Enable SPI

[Andreas Färber]

Am 25.10.2017 um 16:15 schrieb Alexander Bergmann:
> Hi Andreas,
> 
> On Wed, Oct 25, 2017 at 06:06:26AM +0900, Andreas Färber wrote:
>> Hi Alex,
>>
>> Am 25.10.2017 um 03:14 schrieb Alexander Bergmann:
>>> I'm not sure how to enable SPI in openSUSE Leap 43.3. I've changed the
>>> config.txt file and added "dtparam=spi=on", this has however no affect
>>> on the hardware. The same steps are working in Raspbian.
>>>
>>> #> cat /proc/device-tree/soc/spi@7e204000/status
>>> disabled
>>>
>>> Any ideas?
>>
>> Please see my examples linked from the 40-pin connector on the HCL Wiki
>> page.
> 
> Hmmm, I've digged through the wiki last night, but I was unable to find
> it. Could you post the link here?

https://en.opensuse.org/HCL:Raspberry_Pi3 ->
https://en.opensuse.org/Category:Raspberry_Pi_40-pin_connector ->
https://en.opensuse.org/HCL:Chistera_Pi

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] Enable SPI

[Andreas Färber]

Hi Alex,

Am 25.10.2017 um 03:14 schrieb Alexander Bergmann:
> I'm not sure how to enable SPI in openSUSE Leap 43.3. I've changed the
> config.txt file and added "dtparam=spi=on", this has however no affect
> on the hardware. The same steps are working in Raspbian.
> 
> #> cat /proc/device-tree/soc/spi@7e204000/status
> disabled
> 
> Any ideas?

Please see my examples linked from the 40-pin connector on the HCL Wiki
page.

Since we use U-Boot, such external Raspberry Pi examples won't work and
you should use U-Boot's fdt apply command instead.

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] ARM64 installation DVD link on web page

[Andreas Färber]

Am 16.10.2017 um 15:17 schrieb Loic Devulder:
> On 10/16/2017 03:12 PM, Alexander Graf wrote:
>> On 16.10.17 14:56, Loic Devulder wrote:
>>> Hi!
>>>
>>> Small question: on this web page
>>> https://software.opensuse.org/distributions/tumbleweed we can find a
>>> link to download TW Ports, like the page we can found for Leap.
>>> But on the TW Ports there is no ARM64 link as for Leap:
>>> https://software.opensuse.org/distributions/tumbleweed/ports.
>>>
>>> Is a link to the installation DVD could be added like Leap or the other
>>> architectures?
>>
>> Sure!
>>
>>   http://download.opensuse.org/ports/aarch64/tumbleweed/iso/
> 
> Thanks Alex.
> 
> But my question was more on how or who can add this link on the TW Ports
> web page?

Probably somewhere in https://github.com/openSUSE/software-o-o ?

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] EFI boot device-tree

[Andreas Färber]

Am 13.10.2017 um 14:02 schrieb Frank Kunz:
> Am Freitag, 13. Oktober 2017, 12:10:47 CEST schrieb Andreas Färber:
>> Am 13.10.2017 um 11:22 schrieb Alexander Graf:
>>> On 13.10.17 11:17, Frank Kunz wrote:
>>>> I'm doing some test with EFI boot on an olinuxino board here: https://
>>>> build.opensuse.org/package/show/home:frank_kunz:branches:openSUSE:Factory
>>>> :ARM/ JeOS-olinuxinolime
>>>>
>>>> The image works and the kernel has a device-tree visible under
>>>> /proc/device- tree. With non EFI configurations the device-tree is
>>>> loaded by uboot from the boot partition dtb directory and is then passed
>>>> to the kernel by boot command. For EFI there is no dtb directory. Also I
>>>> haven't found a *.dtb file on the filesystem anywhere.
>>>>
>>>> How does the kernel get the device-tree in EFI boot mode?
>>>
>>> It gets it from either a device tree that gets loaded from /boot/dtb or
>>> if none is found from the built-in device tree that U-Boot contains.
> 
> I successfully tried that by compiling a dtb file out of the upstream kernel 
> tree and copied it to the target board. U-boot then u-boot tries to load the 
> file from the first partition, which is the EFI partition. So then the 
> correct 
> path on Linux is then /boot/efi/dtb.
> 
>>>
>>>> The background is that some hardware specific configurations need to be
>>>> done per use case in the device-tree. E.g. adding a battery or a touch
>>>> screen. Without the device-tree settings the kernel will not probe the
>>>> devices. Enabling that on u-boot boot mode can be done by either
>>>> modifying the device-tree file or create overlays and load them by
>>>> u-boot script with "fdt apply" command. How can this be configured in
>>>> EFI mode?
>>>
>>> There are a couple of approaches. I think by now you can add dt overlays
>>> on demand even after the kernel is loaded, so you could just have a
>>> systemd service adding them for you.
>>
>> Please provide proof of such a feature - I don't believe it's in 4.13,
>> and I haven't noticed it in 4.14-rc yet. Patchsets have been around for
>> a long time...
>>
>> Depending on what overlay operation is desired, fdt apply could just
>> operate on $fdtcontroladdr for the internal tree today.
> 
> So far the only some u-boot configurations have the OF_LIBFDT_OVERLAY 
> configuration set. Without that the "fdt apply" command is not supported.
> Also the distroboot environment is not supporting "fdt apply" yet. I think 
> with that, for the moment, supporting fdt overlays would be then a opensuse 
> specific configuration in boot.scr. That is then similar as raspibian and 
> armbian are doing it. They read a *Env.txt file which contains a list of 
> overlay file names.

Both issues - dtb on the wrong partition and lack of fdt apply -
indicate that you're not using an openSUSE-built U-Boot. Please re-test.

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] EFI boot device-tree

[Andreas Färber]

Am 13.10.2017 um 11:22 schrieb Alexander Graf:
> On 13.10.17 11:17, Frank Kunz wrote:
>> I'm doing some test with EFI boot on an olinuxino board here: https://
>> build.opensuse.org/package/show/home:frank_kunz:branches:openSUSE:Factory:ARM/
>> JeOS-olinuxinolime
>>
>> The image works and the kernel has a device-tree visible under /proc/device-
>> tree. With non EFI configurations the device-tree is loaded by uboot from 
>> the 
>> boot partition dtb directory and is then passed to the kernel by boot 
>> command. 
>> For EFI there is no dtb directory. Also I haven't found a *.dtb file on the 
>> filesystem anywhere.
>>
>> How does the kernel get the device-tree in EFI boot mode?
> 
> It gets it from either a device tree that gets loaded from /boot/dtb or
> if none is found from the built-in device tree that U-Boot contains.
> 
>> The background is that some hardware specific configurations need to be done 
>> per 
>> use case in the device-tree. E.g. adding a battery or a touch screen. 
>> Without 
>> the device-tree settings the kernel will not probe the devices. Enabling 
>> that 
>> on u-boot boot mode can be done by either modifying the device-tree file or 
>> create overlays and load them by u-boot script with "fdt apply" command. How 
>> can this be configured in EFI mode?
> 
> There are a couple of approaches. I think by now you can add dt overlays
> on demand even after the kernel is loaded, so you could just have a
> systemd service adding them for you.

Please provide proof of such a feature - I don't believe it's in 4.13,
and I haven't noticed it in 4.14-rc yet. Patchsets have been around for
a long time...

Depending on what overlay operation is desired, fdt apply could just
operate on $fdtcontroladdr for the internal tree today.

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] KVM on RPi3

[Andreas Färber]

Am 09.10.2017 um 18:42 schrieb Loic Devulder:
> On 10/09/2017 04:39 PM, Alexander Graf wrote:
>>> So, "simple" question: is it plan to add KVM_CAP_ARM_USER_IRQ in the
>>> official Leap 42.3 kernel? Or is it better to use Tumbleweed for KVM
>>> testing on rpi3?
>>
>> It's there, but it only works with the Leap 42.3 QEMU version, as the
>> patches weren't upstream by the time the kernel was done yet, so it uses
>> non-upstream identifiers.
>>
>> In a nutshell, use 42.3 QEMU and kernel and it should work too :).
>>
> I had to add the "Virtualization" repository because qemu-ipxe is
> missing, and so virt-manager showed me an error.

Sounds like we're missing an aggregate package for Leap.
This is an x86-built firmware package: As quicker workaround you can
just touch a file of the expected name.

https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/qemu-aggregate/_aggregate?expand=1

Regards,
Andreas

> 
> So, I installed qemu-ipxe apart and try with 42.3 QEMU and kernel and it
> works :)
> 
> Thanks.
> 


-- 
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] RPi3 camera module

[Andreas Färber]

Hi Alex,

Am 07.10.2017 um 15:32 schrieb Alexander Bergmann:
> did anyone get the Raspberry Pi camera module working on a RPi3 with
> openSUSE Leap etc.?

I'm pretty sure that Leap 42.3 does not contain a driver for the camera.

In Tumbleweed last time I checked (4.12 possibly?) it was restricted to
32-bit arm by upstream Kconfig.

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] Khadas VIM2 Max TV Box

[Andreas Färber]

Am 21.09.2017 um 23:11 schrieb Loic Devulder:
> On 08/24/2017 03:54 PM, Andreas Färber wrote:
>> Am 24.08.2017 um 14:54 schrieb Loic Devulder:
>>> I also ordered I VIM1 board (S905x), so mainline U-Boot should work on
>>> it, and so openSUSE too, no?
>>
>> No, S905X is different from S905. Same as S912 it could reuse drivers
>> from S905, but that needs to be tested and missing bits ported from
>> kernel drivers to U-Boot drivers.
>>
> As Amlogic version of u-boot contains support for S905x/S912, and as
> this code is GPL (I've checked inside the code) it should theoretically
> been possible to "copy" this code to mainline u-boot, no?
> 
> I know that there are *lot* of differences due to the old u-boot version
> used by Amlogic :-) But copy/paste the code should be possible when
> needed, because it's GPL code.

It's a human, not a legal problem. Someone needs to take the time.

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] rock64

[Andreas Färber]

Am 05.09.2017 um 15:28 schrieb Alexander Graf:
> 
> 
> On 05.09.17 15:23, Matwey V. Kornilov wrote:
>> 2017-09-05 16:12 GMT+03:00 Alexander Graf :
>>>
>>>
>>> On 05.09.17 15:02, Matwey V. Kornilov wrote:

 2017-09-05 16:00 GMT+03:00 Alexander Graf :
>
>
> On 05.09.17 14:58, Matwey V. Kornilov wrote:
>>
>>
>> Still no luck. No signal at video, no text in console after EFI stub.
>> Any ideas why?
>>
>
> Can you try to make earlycon work? I'm sure someone has the magic
> parameters
> for it somewhere...


 Indeed. But they don't work either. Ones which should is
 earlycon=uart8250,mmio32,0xff13
>>>
>>>
>>> That is very odd. Usually earlycon works. The only case I've found
>>> where it
>>> was unintuitively broken was when U-Boot ran in EL3, but I assume you do
>>> have ATF running somewhere, right?
>>
>> It is supposed to be so.
>>
>>>
>>> What you can still try is to recover the kernel log from RAM. For
>>> that, boot
>>> up the system, then reset (don't power cycle, use the reset button if
>>> available, otherwise use the reset line on the jtag port if available).
>>> After reset, you should get back to U-Boot. There, run "bdinfo" to
>>> find out
>>> the base offset of RAM.
>>
>> What is the offset here?
>>
>> => bdinfo
>> arch_number = 0x
>> boot_params = 0x
>> DRAM bank   = 0x
>> -> start    = 0x0020
> 
> This is the offset. It does sound quite weird though, so don't be
> surprised if things don't work :).

This means the offset is actually zero, but 0x20 bytes are reserved
for ATF or something.

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] Upgrade of openSUSE Tumbleweed on RPI1 fails

[Andreas Färber]

Am 05.09.2017 um 12:11 schrieb Freek de Kruijf:
> Op dinsdag 5 september 2017 08:53:02 CEST schreef Freek de Kruijf:
>> Op maandag 4 september 2017 14:28:24 CEST schreef u:
>>> On 04.09.17 11:49, Freek de Kruijf wrote:
 I used the latest JeOS image 2017.05.23-Build1.1 for the RPi1 (armv6l)
 on
 a SD card and booted the system, which went OK.

 After that I did a "zypper dup --no-recommends" on that system which, at
 the end, shows the following message:

 Output of grub2-arm-uboot-2.02-6.1.armv6hl.rpm %posttrans script:
  update-bootloader: 2017-09-04 11:31:09 <3> update-bootloader-1244

 run_command.274: '/usr/lib/bootloader/grub2-efi/install' failed with
 exit
 code>

 1, output:
  
  target = arm-efi
  ls: cannot access '/sys/firmware/efi/efivars': No such file or
  directory
  + /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable
  Installing for arm-efi platform.
>>>
>>> Can you try to run this command on its own? If it still fails, run it
>>> with strace -f and upload the output somewhere (or look at it and search
>>> for failures)?
>>>
>>> Thanks!
>>>
>>> Alex
>>
>> The RPi1 is not EFI system, so I wonder why the target should be arm-efi.
>>
>> # /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable
>> Installing for arm-efi platform.
>> /usr/sbin/grub2-install: error: cannot find a GRUB drive for /dev/mmcblk0p2.
>> Check your device.map.
>>
>> # more /boot/grub2/device.map
>> (hd0) /dev/disk/by-id/mmc-SDC_0x49910339
>>
>> # ls /dev/disk/by-id/
>> mmc-SDC_0x49910339  mmc-SDC_0x49910339-part1  mmc-SDC_0x49910339-part2  mmc-
>> SDC_0x49910339-part3
>>
>> When running yast in ncurses to change the bootloader without any update I
>> also get the same error message:
>> Error
>> Execution of command "[["/usr/bin/grub2-editenv", "list"]]" failed.
>> Exit code: 1
>> Error output: /usr/bin/grub2-editenv: error: cannot find a GRUB drive for /
>> dev/mmcblk0p2.  Check your device.map.
>>
>> I am able to continue and I get the default "GRUB for EFI", which I change
>> for GRUB2
>> After that I get the message:
>> Error
>> Internal error. Please report a bug report with logs.
>> Run save_y2logs to get complete logs.
>> Details: unsuported architecture arm
>> Caller:  /usr/share/YaST2/lib/bootloader/stage1_proposal.rb:266:in `block in
>> '
>>
>> Obviously the architecture is armv6l.
>>
>> Submitted bug#1057142: https://bugzilla.opensuse.org/show_bug.cgi?id=1057142
> 
> Got answer:
> 
> --- Comment #1 from Ladislav Slezák  ---
> Unfortunately RPi1 is not supported by YaST. YaST supports only aarch64 EFI
> based boards. 
> 
> On RPi1 you have configure booting manually. You can find some booting hints 
> at https://en.opensuse.org/
> HCL:Raspberry_Pi#Installing_the_openSUSE_Tumbleweed_image

I had started preparing arm for yast2-bootloader but I needed to wait
until a yast2-core pull request got merged and packaged and I haven't
followed up since. Basically we need to check all (Ruby?) code paths in
there that check for aarch64 or arm64 and decide whether to extend those
to arm as well - any volunteer?

That is independent of the GRUB error.

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] rock64

[Andreas Färber]

Michal,

Am 29.08.2017 um 18:02 schrieb Michal Suchánek:
> Unfortunately, the wiki which had the information on
> reverse-engineering of the boot sequence is gone.

The boot sequence is documented by Rockchip on the link I just gave!

http://opensource.rock-chips.com/wiki_Boot_option

No need to reverse engineer it.

The purpose of the U-Boot SPL work is merely to get rid of binary blobs
and the tools to create them.

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] rock64

[Andreas Färber]

Am 29.08.2017 um 16:40 schrieb Michal Suchánek:
> On Tue, 29 Aug 2017 16:23:44 +0200
> Andreas Färber <afaer...@suse.de> wrote:
>> Am 29.08.2017 um 14:08 schrieb Michal Suchánek:
>>> On Fri, 25 Aug 2017 22:16:09 +0300
>>> "Matwey V. Kornilov" <matwey.korni...@gmail.com> wrote:
>>>   
>>>> It seems that the following tools are binary only:
>>>> https://github.com/rockchip-linux/rkbin/tree/master/tools
>>>> They are required to convert u-boot to proprietary loader known
>>>> format. Proprietary loader is required because there is no (yet?)
>>>> support for SPL in u-boot for rk3328.
>>>> The tools are also x86_64 only, so I wonder how could they be used
>>>> in OBS to produce package for u-boot image in deployable format.  
>>>
>>> There is rkflashtool https://github.com/linux-rockchip/rkflashtool
>>> which worked for me with some cheap rk33?? TV box for modifying a
>>> boot script on partition that is not accessible from Android. There
>>> was one caveat - the partitions were downloaded with some zero
>>> padding at the start.
>>>
>>> If you look for resources for Radxa Rock (rk3188) you can possibly
>>> find more about rockchip bootable card layout which may or may not
>>> work for you with 3328.  
>>
>> http://opensource.rock-chips.com/wiki_Main_Page is a good starting
>> point
>> - the workflow for 64-bit is slightly different.
>>
>> Note that this is not about flashing but about creating the files to
>> be flashed.
> 
> If rkflashtool works for your board you can download different
> partitions, backup them, upload your code into memory and execute it
> without making changes to storage, replace the content of different
> partitions on the medium with your own, observe the actual content
> change of the medium if you have offline access, restore the backups,
> etc.

Please see rkdeveloptool:

https://build.opensuse.org/package/show/hardware/rkdeveloptool

>> Mainline U-Boot circumvents many of those problems by using its own
>> FIT storage format, but it lags in enabling SPL for the various
>> chipsets.
> 
> There is some 'magic' part at the start of the medium which you need to
> preserve for the medium to be bootable. Using rkflashtool this is
> preserved while you can make changes to the other parts. Getting this
> 'magic' right is somewhat error-prone so it is easier to start with a
> bootable image that works and change parts one by one.

Like Matwey and I said, it's not that easy on arm64. Some parts can't be
flashed into individual partitions because the ARM Trusted Firmware
fip.bin and other Rockchip-specific formats are used, with several
binaries glued together ("the files to be flashed").

At oSC17 I spoke about an RK3328 TV box, where I did not succeed in
interrupting U-Boot, so the various "magic" pieces need to be replaced
with their latest versions according to the Rockchip instructions.
There's so many loader pieces that you can't just load one to memory;
you need to flash a compatible combination, reset and see if it works.

Matwey, see https://en.opensuse.org/HCL:Firefly-RK3399#U-Boot for how to
do it on RK3399 without SPL using Open Source tools apart from binary
"loaderimage". The same "armv8 with miniloader" instructions from
http://opensource.rock-chips.com/wiki_Boot_option should apply, just
with different files from the rkbin repo that you already know.

If you've meanwhile succeeded with SPL please let us know.
I barely just received a Rock64 and haven't played with it yet.

Guillaume has updated and submitted U-Boot - we'll need to check on
which additional boards can be enabled already and where/how to combine
that with my ATF builds - no progress there yet.

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] eSATA support broken in Leap 42.3

[Andreas Färber]

Hi Alessio,

Am 28.08.2017 um 08:43 schrieb Alessio Adamo:
> Anyway, going back on topic... I banged my head against the wall for
> two days trying to boot from eSATA but the partitions wouldn't mount.
> I thought there was something wrong with boot.scr configuration or
> maybe with the rootfs.  Finally,  I decided to try Tumbleweed and it
> worked like a charm.
> Any ideas what could be wrong with Leap?

Leap is using a 4.4 based kernel, Tumbleweed 4.12. Lots of things may
have changed in between... It would help to know whether Leap 42.2
worked or not (also 4.4 based) to see if this is a regression. If not,
you could try to bisect, and if it's just a small bug fix you could open
a Bugzilla ticket to get it backported. Otherwise I'd suggest to stay
with Tumbleweed.

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] Wireless interface on Raspberry Pi 3

[Andreas Färber]

Hi,

Am 25.08.2017 um 12:57 schrieb Roger Oberholtzer:
> 2. Does one run mkinitrd and not dracut on the Raspberry? I really do
> not want to mess up the initrd file!

Recent mkinitrd calls dracut for you.

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] Khadas VIM2 Max TV Box

[Andreas Färber]

Hi Loic,

Am 24.08.2017 um 14:54 schrieb Loic Devulder:
> I also ordered I VIM1 board (S905x), so mainline U-Boot should work on
> it, and so openSUSE too, no?

No, S905X is different from S905. Same as S912 it could reuse drivers
from S905, but that needs to be tested and missing bits ported from
kernel drivers to U-Boot drivers.

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] Khadas VIM2 Max TV Box

[Andreas Färber]

Hi Loic,

Am 22.08.2017 um 10:21 schrieb Loic Devulder:
> Just need to see the status of S912 SoC in the mainline kernel (at least
> in the openSUSE kernel).

At FOSDEM 2017 I showed openSUSE Tumbleweed running on S912, but with a
mainline based kernel due to the TV box vendor's U-Boot not supporting
UEFI or raw initrds or kernel Images with default text offset.

You can probably fix the initrd problem by tweaking the Vim2's U-Boot
config, but you'd need to convert the openSUSE kernel Image to a uImage
and boot as described on linux-meson.com.

Or contribute to mainline U-Boot on S912 (S905 is in mainline, may need
smaller patches for e.g. pinctrl). Then our standard boot flows would
apply and we can attempt to build an official openSUSE image.[*]

Regards,
Andreas

[*] My meson-tools are not yet prepared for S912 either.

-- 
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] aarch64 installer?

[Andreas Färber]

Hi Peter,

Am 28.07.2017 um 09:23 schrieb Peter Czanik:
> I wanted to install Leap 42.3 on my SoftIron box, but the installer
> seems to be unavailable. If I click on 42.3 at
> http://download.opensuse.org/ports/aarch64/distribution/leap/ I get a
> 404 error.
> 
> Last week an RC version installed fine, but now that's also unavailable.
> 
> Any estimates, when 42.3 for Aarch64 becomes available?

There's a known publishing issue. In the meantime you should be able to
retrieve the images from OBS directly, either via osc getbinaries or via
Web interface.

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] Build a downstream kernel in OBS

[Andreas Färber]

Hi Oscar,

Am 24.07.2017 um 20:49 schrieb Oscar C:
> Is there a guide on how to build a downstream kernel in obs like a
> upstream genuine kernel?
> 
> I have a CHIP allwinner R8 with debian but I would like to use opensuse
> instead.

Why do you want a downstream kernel for that? Even the 4.11 kernel
contains a sun5i-r8-chip.dts. Also note that you can use Kernel:HEAD
(v4.13-rc2) or Kernel:linux-next repositories if necessary.

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

[opensuse-arm] Raspberry Pi Zero boot broken after update

[Andreas Färber]

Hi,

Updating my Raspberry Pi Zero to latest Tumbleweed plus staging U-Boot,
I get an exception in GRUB. Could this be related to the native builds?

U-Boot 2017.07-rc3 (Jul 10 2017 - 12:54:03 +)

DRAM:  416 MiB
RPI Zero (0x900093)
MMC:   sdhci@7e30: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In:serial
Out:   vidconsole
Err:   vidconsole
Net:   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
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
21968 bytes read in 249 ms (85.9 KiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
105984 bytes read in 30 ms (3.4 MiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
Found 1 disks
Welcome to GRUB!

data abort
pc : [<18b36628>]  lr : [<18b4e178>]
reloc pc : []lr : []
sp : 19b5c150  ip : 0074 fp : 0001
r10: 18b58cb8  r9 :  r8 : 18b360e4
r7 : 18b36080  r6 :  r5 : 18b36978  r4 : 19b5c290
r3 :   r2 :  r1 : 18b4e478  r0 : 18b36080
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

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] Orange Pi Prime

[Andreas Färber]

Hi Vladimir,

Am 20.07.2017 um 00:09 schrieb Vladimir Nadvornik:
> I have new Orange Pi Prime board and I'd like to run openSUSE on it :)
[...]
> I tried to compile u-boot 2017-07 from Base:System:Staging. The
> board config is already there but it seems that there is problem with
> building SPL - there is this message during build:
> 
> [  246s] WARNING: BL31 file bl31.bin NOT found, resulting binary is
> non-functional
> [  246s] Please read the section on ARM Trusted Firmware (ATF) in
> board/sunxi/README.sunxi64

Nevertheless, please do a Submit Request preparing such a package, or
let me know the name of the config you need added.

> BTW, the already enabled board Orange Pi PC2 seems to have the same
> problem.

Guillaume took care of the version update, I have not yet done a round
of testing. Previous kernel tests were with a self-compiled U-Boot.

> I haven't found anything like this in build service, do I understand
> it correctly that it needs to be packaged?

The ATF package is not in Factory, because it is not upstream. I have
the upstream one in my home. We would need to find a suitable devel
project to submit it to - probably Base:System.

You can find an arm-trusted-firmware-pine64 package in Contrib:Pine64
and need to rebuild your U-Boot package against it (adding a
BuildRequires in your branch and setting some BL31 variable according to
the above README).
If you want, we can add a Contrib:OrangePiPrime project for your board.

The 4.12 kernel was not yet working for the H5, so you'll need either
4.13-rc1 from Kernel:HEAD or kernel-sunxi64 from Contrib:Pine64.

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] Enabling WiFi on RPi3

[Andreas Färber]

Hi,

Am 19.06.2017 um 15:12 schrieb David Todd:
> On 6/19/17 6:20 AM, Freek de Kruijf wrote:
>> Last year I was able to enable WiFi on my RPi3. The problem at that
>> moment was
>> the unavailable firmware files. These files are now available in
>> Tumbleweed,
>> however I can't find how to load these files in order to have a wlan0
>> device.
>> I found a script /usr/sbin/install-brcmfmac, but I can't find how and
>> where
>> this script is called. It puts a symbolic link is some folder, but what
>> folder?
>>
>>
> I think this *might* work for you.
> https://lists.opensuse.org/opensuse-arm/2016-11/msg00018.html

It won't, that link is about Leap.

> I finally gave up on Tumbleweed as being too unstable (WiFi, USB
> booting, etc),
> and went to Leap 42.2 as my primary SUSE system.  But the technique
> outlined
> in that link has proven useful in the past.

Wifi is not "unstable" in Tumbleweed, it was never available on RPi3.
The necessary SDIO drivers just barely made it into 4.12-rcX, and
Tumbleweed still has 4.11.

To me it looked like the new 4.12 driver was misnamed just "bcm2835", so
it may require further changes to dracut configs. Or even better someone
should send a patch to rename it upstream.

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] openSUSE:Factory:ARM: armv7l: __spawnix: Assertion `ec >= 0'

[Andreas Färber]

Hi,

Am 15.06.2017 um 20:14 schrieb Matwey V. Kornilov:
> 
> There are bad thing with glibc in Factory. Every other package fails
> with the following message:
> 
> ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0'
> failed.

Got a concrete link? That error used to be for armv6l due to QEMU.

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

[opensuse-arm] filesystem package broke Base:System for aarch64 - system-users circular dependency

[Andreas Färber]

Hi Thorsten and Marcus,

The Base:System devel project is broken for aarch64 after
https://build.opensuse.org/request/show/502571 (filesystem) and
https://build.opensuse.org/request/show/502534 (system-users):

Both the filesystem and system-users packages are unresolvable due to
dependency on user(root) and group(root) provided by system-users.

I.e., it seems the filesystem package was rebuilt with new Requires
before the updated system-users providing them got scheduled to build. A
versioned BuildRequires in filesystem would've been one way to block it
from getting built too early; waiting for system-users to rebuild on all
architectures before submitting/accepting the filesystem SR would've
been a more manual solution for Base:System (that might not work for
Factory though).

For Base:System:Staging I have switched to building against Factory
instead of Base:System for now, restoring the build of the new U-Boot
packages there, but Base:System remains unresolvable for aarch64.

https://build.opensuse.org/project/monitor/Base:System?arch_aarch64=1=1=1=1=0=1=1=1=1=1_openSUSE_Factory_ARM=1=1=1=1=1

Please find a way to fix this (e.g., temporarily disable use-for-build
for filesystem on aarch64 to use the still-working Factory filesystem,
or copy/aggregate the new noarch system-users into aarch64), and make
sure this doesn't happen again when submitting your changes to Factory.

Thanks,
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] openSUSE for Khadas VIM

[Andreas Färber]

Hi Matthias and Oleg,

Am 15.05.2017 um 11:38 schrieb Matthias Brugger:
> On 14/05/17 13:22, Oleg wrote:
>> I'm trying to run openSUSE on Khadas VIM.
>>
>> Which settings\variables u-boot you need to install to transfer
>>
>> control after the start of u-boot to openSUSE ?

An empty Wiki page usually hints that either time for investigations or
essential software pieces are missing:

https://en.opensuse.org/HCL:Khadas_Vim

> As far as I know, there are no working images for the Khadas VIM.
> 
> Does mainline u-boot support your device?

Unfortunately not. I barely just sent a patch for a second S905 device,
no signs of S905X or S912 yet. The biggest question I am unclear about
(and which needs testing/review) is whether new pinctrl drivers will be
needed, or whether we might just ignore those drivers initially for at
least serial.

The second issue is that my amlbootsig tool does not support S905X yet,
so we couldn't build images in OBS, even if there were a U-Boot package.
Both S905X and S912 seem to use aml_encrypt_gxl (haven't seen any _gxm),
whereas the current state is based on aml_encrypt_gxb, and there was at
least an initial @AML header not present on S905X. Even for S905 there's
input differences between Hardkernel and FriendlyARM.
amlbootsig does not block local testing with aml_encrypt_gxl of course.

Oleg, you can download a JeOS-rootfs tarball from
http://download.opensuse.org/ports/aarch64/tumbleweed/images/
but it doesn't contain an initrd for its kernel; other images such as
JeOS-efi or JeOS-odroidc2 do contain both. If you use your own e.g.
linux-next kernel with built-in drivers you can circumvent the initrd.

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] MAC address on Raspberry PI 3

[Andreas Färber]

Hi Roger et al.,

Am 02.03.2017 um 12:11 schrieb Andreas Färber:
> Am 02.03.2017 um 08:19 schrieb Roger Oberholtzer:
>> I have just updated my previously working RI 3 to the latest kernel
>> for openSUSE 42.2
>>
>> It seems that the device now generates a unique MAC address on the
>> wired Ethernet connection each time it is powered on. Could this
>> happen? If so, how can I change it back to use a fixed MAC address?
> 
> I noticed a similar DHCP issue on RPi2 with Tumbleweed recently - so far
> no one knew why. U-Boot should pass the MAC address to the kernel in the
> device tree so that this doesn't happen [...].

I have just updated U-Boot to v2017.05-rc3, which IIUC includes a fix
for this issue. Any testing feedback appreciated for the new packages:

https://build.opensuse.org/project/show/Base:System:Staging

Upstream patch was "[U-Boot] [PATCH] fdt: Move fdt_fixup_ethernet to a
common place", which says 'Fixes: 3f66149d9fb4 ("Remove extra
fdt_fixup_ethernet() call")'.

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

[opensuse-arm] Re: [opensuse-factory] New package: rkdeveloptool

[Andreas Färber]

Am 01.05.2017 um 00:24 schrieb Andreas Färber:
> Hello,
> 
> I have packaged and submitted Rockchip's rkdeveloptool to Factory:

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

> In its not-yet-versioned Git state, it already replaces the proprietary
> upgrade_tool in that it allows to flash, e.g., U-Boot bootloader.
> Tested on Leap 42.2 with the GeekBox (RK3368).
> 
> Future improvements shall include installing a udev rule for rockusb

Done: https://github.com/rockchip-linux/rkdeveloptool/issues/7

> devices and fixing the build on excluded platforms
> (https://github.com/rockchip-linux/rkdeveloptool/issues/6).
> 
> 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

[opensuse-arm] New package: rkdeveloptool

[Andreas Färber]

Hello,

I have packaged and submitted Rockchip's rkdeveloptool to Factory:

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

In its not-yet-versioned Git state, it already replaces the proprietary
upgrade_tool in that it allows to flash, e.g., U-Boot bootloader.
Tested on Leap 42.2 with the GeekBox (RK3368).

Future improvements shall include installing a udev rule for rockusb
devices and fixing the build on excluded platforms
(https://github.com/rockchip-linux/rkdeveloptool/issues/6).

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] nanopi neo air ?

[Andreas Färber]

Hi Per,

Am 18.04.2017 um 18:51 schrieb Andreas Färber:
> With today's update to v2017.05-rc2, there now is a u-boot-nanopineoair
> package in Base:System:Staging for you to test.
> 
> If you interrupt it on serial and type "printenv fdtfile", I would
> expect that you see a different .dtb filename than for -nanopineo.
> 
> The sun8i-h3-nanopi-neo-air.dtb file is however not part of kernel 4.11
> (i.e., not in Kernel:HEAD), so you would need to try kernel-vanilla and
> dtb-sun8i from Kernel:linux-next. Or try just the .dtb file from there,
> with a Factory or Kernel:HEAD kernel-lpae.
> 
> To use the partially-working sun8i-h3-nanopi-neo.dtb as before with the
> new u-boot-nanopineoair, you could use a symlink.
> 
> Small steps...

Haven't heard back here yet. Note that I've recently (when touching it)
prepared a JeOS image with the above bootloader:

https://en.opensuse.org/HCL:NanoPi_Neo_Air

It still requires the above workarounds for the .dtb, thus in a Contrib.

Some feedback before oSC17 would be appreciated, as I don't have one.

Thanks,
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] Odroid-C2

[Andreas Färber]

Hi Sid,

Am 27.04.2017 um 17:20 schrieb Sid Boyce:
> Looks like my SD card interface is broken as it does not boot with any
> distro.
> 
> I normally run Ubuntu from a eMMC.

Did you detach the eMMC for SD testing?

I don't have an eMMC module. If you're feeling like experimenting, you
could back up your Ubuntu and try dd'ing the JeOS to eMMC. I'm not aware
of any special blobs being needed for eMMC, so it might work...

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] Firefly RK3399 board

[Andreas Färber]

Hello Bill,

Am 26.04.2017 um 18:32 schrieb Bill Merriam:
> Has anyone had a chance to try this board?  With 4GB of RAM on it and a
> couple of SSDs, it might make a pretty good server/build
> server/desktop/media center or something.
> 
> http://wiki.t-firefly.com/index.php/Firefly-RK3399/en
> 
> I notice Andreas has some firmware for this processor.  Can I put that
> together with our AARCH64 root file system and make a bootable system?
> 
> Would it help things along if I gifted one of these boards to Andreas?

Your trust is of course flattering. ;)
But in this particular case it won't be necessary...

Let's just say there were above-average customs problems getting that
board into Germany end of last month. I've been in touch with T-Firefly
and hope to have one arrive next week now. (Customs couldn't say
retroactively, but my hypothesis is that they held it and then returned
it to China due to the included power supply not being CE certified for
the European Union - so beware for other EU member countries as well.
Workaround is asking T-Firefly to remove the power supply - now it
passed and just needs to be delivered after weekend and Labour Day.)

I usually create HCL Wiki pages only once I have the hardware in hands,
so here's some quick notes:

* We still need a proper U-Boot package for the Firefly-RK3399, which
could be achieved by throwing one or two patches onto our 2017.05 queue.
Currently there's only a u-boot-evb-rk3399 package, which may or may not
work partially.

* I need to find a suitable devel project for my ARM Trusted Firmware
packages, which you seem to have seen. Any suggestions?

* According to Yousaf, creating a JeOS image won't work currently,
because Kiwi's first partition would overlap with the bootloaders.

* Ideally we should just make JeOS-efi work (adding dtb-rockchip) on
SD/USB/SATA and document how to get an up-to-date U-Boot onto eMMC. That
would also allow to use the installation DVD instead of JeOS-efi.

Hopefully we will know more in time for oSC17.

Regards,
Andreas

P.S. For the record there is one other new board with 4 GB on an
exchangeable DIMM (for $110 more), although the bootloader situation for
its SoC seems much more work-in-progress still, at least compared to
another board with RK3399 (not having tested the Firefly-RK3399 yet).

-- 
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] DT overlays

[Andreas Färber]

Am 24.04.2017 um 19:43 schrieb Tony Su:
> Additional,
> It's been a few months since I looked at this,
> Raspbian makes it very easy (?) to add definitions, you drop
> individual files for each definition into a directory, then boot.
> I didn't explore how difficult it would be to write the definitions 
> themselves.
> 
> Of course, if the dtb definitions are identical, then it would mean
> that just dropping the files from raspbian into the openSUSE directory
> would instantly enable support for the 50-plus or so HATs (last I
> counted) that Raspbian supports.
> 
> Tony
> 
> On Mon, Apr 24, 2017 at 10:35 AM, Tony Su  wrote:
>> Are you using the same dtb definitions and format as what is being
>> used in the Debian Raspbian image which does  use u-boot?

Reminder: Please don't top-post on our mailing lists; reply below.

openSUSE uses U-Boot, and U-Boot does not get its Device Tree from the
Raspberry Pi firmware, so their built-in overlay support (config.txt) is
useless to us.

Whether it would be possible to iterate over files in a directory from a
U-Boot script I haven't tried, can't think of how - if you have a
solution, please share.

The alternative would be to do it as a systemd service from Linux, but
that would require some DT merging tool AFAIU, which we don't have
today. That's why reusing U-Boot's existing implementation is somewhat
convenient for me, even if sub-optimal.

As for reusing Raspbian .dtbo files, any .dtbo file always depends on
the base .dtb file. So if they are still based off old non-mainline
bcm2708/09/10 files, then reusing them with mainline bcm2835/36/37 files
is unlikely to work.

https://www.raspberrypi.org/documentation/configuration/device-tree.md
section 2.1 also mentions differences between -overlay.dtb and .dtbo for
(their?) kernel v4.4+.

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] Drivers for display for rpi3

[Andreas Färber]

Hi Eric,

Am 24.04.2017 um 12:49 schrieb Eric Curtin:
> I recently bought a display that depends on the following driver:
> 
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/staging/+/master/drivers/staging/fbtft/
> 
> Could I get these drivers added to the kernel build for:
> 
> http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliances/openSUSE-Leap42.2-ARM-XFCE-raspberrypi3.aarch64.raw.xz

Looking at kernel.opensuse.org, kernel-source.git master branch has
CONFIG_FB_TFT=m set in config/arm64/default, and so does stable branch.
So before we discuss making changes to Leap releases, please verify that
it works with a Kernel:stable (i.e., Tumbleweed) or even better
Kernel:HEAD kernel-default. The latter is where new and experimental
drivers get enabled. I need to know exactly which config options you
need, as I do not have any MIPI DSI displays myself - there's several
CONFIG_FB_TFT_* sub-options available.

If it does work, the next question is, are all options available on
openSUSE-42.2 branch. If so, you'll need to open a Bugzilla ticket. Ways
to contribute yourself would be sending a patch to opensuse-kernel list
or doing a pull request on GitHub (may need a ping on the list), but for
stable branches a boo# is required. Whether kernel maintainers agree to
enable new options for 42.2 now is out of our control; note that 42.3 is
in the works.

If the options are unavailable in 42.2/42.3, you could build a KMP.

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] Odroid-C2

[Andreas Färber]

Hi,

Am 21.04.2017 um 17:00 schrieb Sid Boyce:
> On 21/04/17 15:40, Andreas Färber wrote:
>> Am 21.04.2017 um 16:13 schrieb Sid Boyce:
>>> On 21/04/17 09:13, Andreas Färber wrote:
>>>> JeOS-odroidc2 is now bootable - available from Contrib:OdroidC2,
>>>> instructions at https://en.opensuse.org/HCL:OdroidC2.
>>> Burned
>>> openSUSE-Tumbleweed-ARM-JeOS-odroidc2.aarch64-2017.04.21-Build3.1.raw.xz
>>> per instructions, does not boot.
>>> Only the red LED lights.
>> It does here. Are you maybe looking at an HDMI screen instead of serial?
>> HDMI drivers will come in 4.12, and currently there are no Odroid-C2 DT
>> patches yet. Booting does not mean full-featured!
>>
>> Also as usual it takes some minutes until Kiwi has repartitioned the
>> card and network is up.
[...]
> I have both the serial console on /dev/ttyUSB0 and HDMI screens connected.

Having HDMI connected didn't hurt here.

> The blue LED never flashes on

For some reason the ledtrig-heartbeat module does not get loaded
automatically. So the blue LED is unrelated to booting.

> and no message appears on the serial
> connection.

Baudrate 115200? Working for your Ubuntu image?

> I am using one of the recommended Toshiba SD cards - 64 GB.

32 GB SanDisk Ultra microSHDC Class 10 UHS-I here.

Where did you read about recommended cards?

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438_idx=2

"The ODROID-C2 can utilize the newer UHS-1 SD model, which is about 2
times faster than a normal class 10 card.
Note that there are some cards which needs additional booting delay time
around 30 seconds.
According to our test, most Sandisk Micro-SD cards don't cause the
booting delay. We will make a compatibility list soon."

What they're selling is SanDisk 8 GB and 16 GB:

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145636129743

Note that the initial serial output comes from BL1, so is independent of
any mainline U-Boot code specific to us. I doubt that meson-tools are at
fault if the same image boots for me. So rather puzzling...

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] Odroid-C2

[Andreas Färber]

Hi Sid,

Am 21.04.2017 um 16:13 schrieb Sid Boyce:
> On 21/04/17 09:13, Andreas Färber wrote:
>> JeOS-odroidc2 is now bootable - available from Contrib:OdroidC2,
>> instructions at https://en.opensuse.org/HCL:OdroidC2.
>>
> Hi Andreas,
> Burned
> openSUSE-Tumbleweed-ARM-JeOS-odroidc2.aarch64-2017.04.21-Build3.1.raw.xz
> per instructions, does not boot.
> Only the red LED lights.

It does here. Are you maybe looking at an HDMI screen instead of serial?
HDMI drivers will come in 4.12, and currently there are no Odroid-C2 DT
patches yet. Booting does not mean full-featured!

Also as usual it takes some minutes until Kiwi has repartitioned the
card and network is up.

On my home branch, before submitting JeOS, I had verified that also
second boot works, thanks to the dracut config added.

Regards,
Andreas

GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0;
TE: 312955
no sdio debug board detected

BL2 Built : 11:44:26, Nov 25 2015.
gxb gfb13a3b-c2 - jcao@wonton

Board ID = 8
set vcck to 1100 mv
set vddee to 1050 mv
CPU clk: 1536MHz
DDR channel setting: DDR0 Rank0+1 same
DDR0: 2048MB(auto) @ 912MHz(2T)-13
DataBus test pass!
AddrBus test pass!
Load fip header from SD, src: 0xc200, des: 0x0140, size: 0x00b0
Load bl30 from SD, src: 0x00010200, des: 0x0100, size: 0x9ef0
Sending bl30OK.
Run bl30...
Load bl301 from SD, src: 0x0001c200, des: 0x0100, size: 0x18c0
Wait bl30...Done
Sending bl301...OK.
Run bl301...
0, des: 0x1010, size: 0x00011130


--- UART initialized after reboot ---
[Reset cause: unknown]
[Image: unknown, amlogic_v1.1.3046-00db630-dirty 2016-08-31 09:24:14
tao.zeng@droid04]
bl30: check_permit, count is 1
bl30: check_permit: ok!
chipid: ef be ad de d f0 ad ba ef bLoad bl33 from SD, src: 0x00034200,
des: 0x0100, size: 0x00055b50
e ad de not ES chip
[0.427617 Inits done]
secure task start!
high task start!
low task start!
NOTICE:  BL3-1: v1.0(debug):4d2e34d
NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address = 0x100
INFO:BL3-1: Next image spsr = 0x3c9


U-Boot 2017.05-rc2 (Apr 21 2017 - 03:45:10 +) odroid-c2

DRAM:  2 GiB
MMC:   mmc@72000: 0, mmc@74000: 1
Using default environment

In:serial@4c0
Out:   serial@4c0
Err:   serial@4c0
Net:   eth0: ethernet@c941
Hit any key to stop autoboot:  0
=> boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
19109 bytes read in 28 ms (666 KiB/s)
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
731648 bytes read in 37 ms (18.9 MiB/s)
## Starting EFI application at 0108 ...
Scanning disk m...@72000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 10
Found 1 disks
Welcome to GRUB!

error: terminal `gfxterm' isn't found.
error: no suitable video mode found.
error: can't find command `terminal'.

  GNU GRUB  version 2.02~rc2

┌┐
│ openSUSE [ VMX ]
│
│*Failsafe -- openSUSE [ VMX ]
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
│
└┘

 Use the ▲ and ▼ keys to select which entry is highlighted.
  Press enter to boot the selected OS, `e' to edit the commands
  before booting or `c' for a command-line.


-- 
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] Odroid-C2

[Andreas Färber]

Am 18.04.2017 um 23:25 schrieb Andreas Färber:
> Hi Sid,
> 
> Am 18.04.2017 um 21:35 schrieb Sid Boyce:
>> On 15/04/17 09:48, Andreas Färber wrote:
>>> Amlogic S905 MMC support has just landed in U-Boot last night, allowing
>>> to finally migrate my two S905 devices over to our openSUSE kernel.
>>>
>>> Am 11.04.2017 um 01:42 schrieb Andreas Färber:
>>>> == aarch64 ==
>>> Odroid-C2 - boots OK (add fixed, gpio-regulator modules to dracut)
> [...]
>> Which image boots on the ODROID-C2?
> 
> Short answer: None, I have not created a JeOS image yet.
> 
> Just today was U-Boot v2017.05-rc2 packaged, and it'll take a while for
> it to hit Factory.
[...]
> Binary-only ARM Trusted Firmware blobs are needed for booting, that are
> unlikely to ever reach Factory. So they would need to live in a Contrib.

Packaged as odroidc2-firmware in Contrib:OdroidC2.

> Next problem was that Hardkernel uses a binary-only x86 Amlogic tool for
> packing the ATF and U-Boot binaries into a bootable form.
> My solution for OBS/aarch64 was to piece together an Open Source tool:
> https://github.com/afaerber/meson-tools
> Currently that still requires the fip tool from downstream Hardkernel
> U-Boot (with its alignment magic), which didn't build with gcc5+.

Found a workaround: fip_create actually builds fine without U-Boot.

Packaged as odroidc2-firmware-tools for Leap 42.2 and Tumbleweed.

odroidc2-firmware now builds u-boot.odroidc2 - boots OK when written to
SD card as documented in the Wiki below. :)

Thanks to everyone who supported the development of meson-tools!
In particular a hint on "sha2" functions being used, which lead me to
discover the right SHA256 check-sum algorithm, was invaluable.

> Cf. https://en.opensuse.org/HCL:OdroidC2
> 
> So... would it help to create a JeOS image without the bootloader?

Only this final part is still missing.

> You could then dd the bootloader onto the SD card in a second step.
> 
> The Factory 4.10 kernel booted okay, so no dependency on Kernel:HEAD.
> 
> I've create a Contrib:OdroidC2, but it's still empty:
> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:OdroidC2
> 
> 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] Odroid-C2

[Andreas Färber]

Am 19.04.2017 um 00:43 schrieb Sid Boyce:
> On 18/04/17 22:25, Andreas Färber wrote:
>> Am 18.04.2017 um 21:35 schrieb Sid Boyce:
>>> On 15/04/17 09:48, Andreas Färber wrote:
>>>> Amlogic S905 MMC support has just landed in U-Boot last night, allowing
>>>> to finally migrate my two S905 devices over to our openSUSE kernel.
>>>>
>>>> Am 11.04.2017 um 01:42 schrieb Andreas Färber:
>>>>> == aarch64 ==
>>>> Odroid-C2 - boots OK (add fixed, gpio-regulator modules to dracut)
>> [...]
>>> Which image boots on the ODROID-C2?
>> Short answer: None, I have not created a JeOS image yet.
>>
>> Just today was U-Boot v2017.05-rc2 packaged, and it'll take a while for
>> it to hit Factory. (https://build.opensuse.org/request/show/487710 is
>> still pending for the previous v2017.03...)
>> -rc2 still does not include all patches for a convenient boot from SD -
>> we could queue some in our package of course.
>>
>> Binary-only ARM Trusted Firmware blobs are needed for booting, that are
>> unlikely to ever reach Factory. So they would need to live in a Contrib.
>>
>> Next problem was that Hardkernel uses a binary-only x86 Amlogic tool for
>> packing the ATF and U-Boot binaries into a bootable form.
>> My solution for OBS/aarch64 was to piece together an Open Source tool:
>> https://github.com/afaerber/meson-tools
>> Currently that still requires the fip tool from downstream Hardkernel
>> U-Boot (with its alignment magic), which didn't build with gcc5+.
>>
>> Cf. https://en.opensuse.org/HCL:OdroidC2
>>
>> So... would it help to create a JeOS image without the bootloader?
>> You could then dd the bootloader onto the SD card in a second step.
>>
>> The Factory 4.10 kernel booted okay, so no dependency on Kernel:HEAD.
>>
>> I've create a Contrib:OdroidC2, but it's still empty:
>> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:OdroidC2
> 
> Thanks Andreas,
> 
> Looks like much work is left to do.

My meson-tools are packaged in Contrib:OdroidC2 now, and I've applied a
patch to u-boot-odroid-c2 in Base:System:Staging.

The Wiki page above has been updated with how to build the bootloader
from the Hardkernel blobs and our U-Boot package with my tool.

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

[opensuse-arm] Odroid-C2 (was: Kernel 4.11-rc6 testing status)

[Andreas Färber]

Hi Sid,

Am 18.04.2017 um 21:35 schrieb Sid Boyce:
> On 15/04/17 09:48, Andreas Färber wrote:
>> Amlogic S905 MMC support has just landed in U-Boot last night, allowing
>> to finally migrate my two S905 devices over to our openSUSE kernel.
>>
>> Am 11.04.2017 um 01:42 schrieb Andreas Färber:
>>> == aarch64 ==
>> Odroid-C2 - boots OK (add fixed, gpio-regulator modules to dracut)
[...]
> Which image boots on the ODROID-C2?

Short answer: None, I have not created a JeOS image yet.

Just today was U-Boot v2017.05-rc2 packaged, and it'll take a while for
it to hit Factory. (https://build.opensuse.org/request/show/487710 is
still pending for the previous v2017.03...)
-rc2 still does not include all patches for a convenient boot from SD -
we could queue some in our package of course.

Binary-only ARM Trusted Firmware blobs are needed for booting, that are
unlikely to ever reach Factory. So they would need to live in a Contrib.

Next problem was that Hardkernel uses a binary-only x86 Amlogic tool for
packing the ATF and U-Boot binaries into a bootable form.
My solution for OBS/aarch64 was to piece together an Open Source tool:
https://github.com/afaerber/meson-tools
Currently that still requires the fip tool from downstream Hardkernel
U-Boot (with its alignment magic), which didn't build with gcc5+.

Cf. https://en.opensuse.org/HCL:OdroidC2

So... would it help to create a JeOS image without the bootloader?
You could then dd the bootloader onto the SD card in a second step.

The Factory 4.10 kernel booted okay, so no dependency on Kernel:HEAD.

I've create a Contrib:OdroidC2, but it's still empty:
https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:OdroidC2

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] nanopi neo air ?

[Andreas Färber]

Am 27.02.2017 um 14:23 schrieb Andreas Färber:
> Am 27.02.2017 um 08:55 schrieb Per Jessen:
>> Andreas Fc3a4rber wrote:
>>> Am 26.02.2017 um 19:00 schrieb Per Jessen:
>>>> Per Jessen wrote:
>>>>> Andreas Fc3a4rber wrote:
>>>>>> Am 24.02.2017 um 17:47 schrieb Per Jessen:
>>>>>>> Has anyone been playing with one of these?  I'm not making much
>>>>>>> progress myself - eventually I'd like to get openSUSE running of
>>>>>>> course, but for starters, I'm just trying with the ubuntu core
>>>>>>> from http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air
>>>>>>>
>>>>>>> The device seems to be booting (blue light flashing), but it's not
>>>>>>> picking up an IP-address from dhcp.
>>>>>>
>>>>>> Have you looked at my JeOS-nanopineo? Should be fairly similar.
>>>>>
>>>>> I'll try that - it can't be too difficult to add in a wlan
>>>>> interface.
>>>
>>> Just to be clear, this is not just about adding a wlan interface.
>>> Since you're the one with the board, I pointed you to look at
>>> JeOS-nanopineo as template to create a JeOS-nanopineoair image 
>>
>> Ah, I misunderstood.  Is there a howto for me to study somewhere, this
>> is brand new territory for me. 
> 
> I'm not aware (but it's a Wiki...), that's why I pointed to an existing
> example. pre_checkin.* is always the first file to look at, and inside
> the JeOS package Images.kiwi.in.

With today's update to v2017.05-rc2, there now is a u-boot-nanopineoair
package in Base:System:Staging for you to test.

If you interrupt it on serial and type "printenv fdtfile", I would
expect that you see a different .dtb filename than for -nanopineo.

The sun8i-h3-nanopi-neo-air.dtb file is however not part of kernel 4.11
(i.e., not in Kernel:HEAD), so you would need to try kernel-vanilla and
dtb-sun8i from Kernel:linux-next. Or try just the .dtb file from there,
with a Factory or Kernel:HEAD kernel-lpae.

To use the partially-working sun8i-h3-nanopi-neo.dtb as before with the
new u-boot-nanopineoair, you could use a symlink.

Small steps...

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

[opensuse-arm] Kernel 4.11-rc6 testing status

[Andreas Färber]

Hi,

Update: Since Friday's second revision of 4.11.rc6 serdev now works.

Amlogic S905 MMC support has just landed in U-Boot last night, allowing
to finally migrate my two S905 devices over to our openSUSE kernel.

Am 11.04.2017 um 01:42 schrieb Andreas Färber:
> == aarch64 ==

Odroid-C2 - boots OK (add fixed, gpio-regulator modules to dracut)

> Pine64 - boots now, but no built-in network (USB Ethernet works)
> 
> Raspberry Pi 3 B - boots OK

Vega S95 Telos - boots OK (cf. Odroid-C2)


> == armv7hl ==
[...]
> Beagle Bone Black - boots OK
> 
> Cubietruck - boots OK
> 
> Jetson TK1 - boots OK

NanoPi NEO - boots OK (still no built-in network)

> Raspberry Pi 2 B - boots OK

UDOO Neo - still hanging


No successful armv6hl -rc6 builds yet.


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] Re: openSUSE-Leap42.2-ARM-JeOS-raspberrypi2 and RPi3

[Andreas Färber]

Am 14.04.2017 um 12:17 schrieb Matwey V. Kornilov:
> 
> 12.04.2017 11:44, Fabian Vogt пишет:
>> Hi,
>>
>> as far as I can tell this is the usual issue with uboot that it really
>> relies on a serial console.
>>
>> There is a patch on the u-boot mailing list that should fix this for
>> the rpi2 u-boot on rpi3 HW case:
>>
>> https://patchwork.ozlabs.org/patch/746827/
> 
> Unfortunately, It doesn't work for me...

Have you set skip-init as instructed in the commit message?

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

[opensuse-arm] Kernel 4.11-rc5 testing status

[Andreas Färber]

Hello,

A little delayed, here's a first update on Kernel:HEAD 4.11.

Executive summary: No regressions noticed so far.


== aarch64 ==

Pine64 - boots now, but no built-in network (USB Ethernet works)

Raspberry Pi 3 B - boots OK


== armv7hl ==

(Tested using a home branch.)

Beagle Bone Black - boots OK

Cubietruck - boots OK

Jetson TK1 - boots OK

Raspberry Pi 2 B - boots OK


== armv6hl ==

(Tested using a home branch - finished building today.)

Raspberry Pi Zero - boots OK


-rc6 should start building for armv7hl and armv6hl tomorrow.

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