Re: [opensuse-arm] hctosys does not wait for rtc0 and fails

[Alexander Graf]

> Am 02.01.2019 um 11:04 schrieb Guillaume Gardet :
> 
> Hi,
> 
>> Le 07/12/2018 à 14:04, Alexander Graf a écrit :
>> 
>>> Am 07.12.2018 um 13:34 schrieb Guillaume GARDET :
>>> 
>>> 
>>> Hi,
>>> 
>>> On my Chromebook ARM, hctosys does not wait that /dev/rtc0 appears and 
>>> fails on rtc0 opening as it is not accessible at this point. See my dmesg:
>>> [7.026205] hctosys: unable to open rtc device (rtc0)
>>> [9.474121] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc 
>>> as rtc0
>>> 
>>> The RTC appears 2.5 sec after hctosys failed. This is because i2c module is 
>>> needed and is loaded at this time.
>>> 
>>> Any idea how to fix/workaround that?
>> Are the drivers in the initrd? If not, maybe that helps.
> 
> 
> I added i2c driver to initrd, RTC driver is already built-in. But it does not 
> help. The same problem appears earlier in the boot process.
> 
> BTW, we should be able to get time via EFI, no? Not sure what is the u-boot 
> support for this, though.

U-Boot does not implement RTC retreival via runtime services on any board 
today. The i2c bus might for example be shared, or clocks are owned by Linux 
instead.

In this particular case though, I still think we're just merely missing a 
dependency in the initrd. Looks at lsmod of a fully booted system and try to 
put those in.


Alex


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

[opensuse-arm] VPP

[Alexander Graf]

Hi Guillaume,

To your question on IRC:

> [14:37:37]   dirk: is there a mean to be scheduled only on 
> one type of machine (e.g. TX1 or TX2) in OBS? Maybe there is a flag or 
> something?
> [14:40:41]   it would be for next VPP version, which perform 
> some runtime checks at configure and if scheduled on TX1 (and maybe HiSi) it 
> would not run on other machines. And if it is build on TX2 (or others), it 
> would not be efficient on TX1.

That sounds like we'd (short term) need to patch the configure script to
explicitly be tuned for a particular target platform. Then build the
binary n times - one for each optimization target.

The long term fix is to work with OSEC for example and make sure that
this becomes a real runtime check via IFUNCs for example, nothing
checked at compile time. The same binary ideally runs fast everywhere then.


Alex

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

Re: [opensuse-arm] hctosys does not wait for rtc0 and fails

[Alexander Graf]

> Am 07.12.2018 um 13:34 schrieb Guillaume GARDET :
> 
> 
> Hi,
> 
> On my Chromebook ARM, hctosys does not wait that /dev/rtc0 appears and fails 
> on rtc0 opening as it is not accessible at this point. See my dmesg:
> [7.026205] hctosys: unable to open rtc device (rtc0)
> [9.474121] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc 
> as rtc0
> 
> The RTC appears 2.5 sec after hctosys failed. This is because i2c module is 
> needed and is loaded at this time. 
> 
> Any idea how to fix/workaround that? 

Are the drivers in the initrd? If not, maybe that helps.

Alex

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

--
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] Notice for Tumbleweed users - root access from ssh is disabled by default

[Alexander Graf]

On 03.12.18 10:38, Guillaume GARDET wrote:
> 
> - Alexander Graf  a écrit :
>>
>>
>>> Am 03.12.2018 um 09:55 schrieb Guillaume GARDET :
>>>
>>>
>>> Hi,
>>>
>>> In Tumbleweed, latest openSSH update disables root login by default.
>>> So, if you have only 'root' user on your headless system, please run the 
>>> following command on your system, before running a 'zypper dup':
>>>
>>>  echo -e "\n# Allow root login on ssh\nPermitRootLogin yes" >> 
>>> /etc/ssh/sshd_config
>>>
>>> Otherwise, you will not be able to login to your system anymore.
>>>
>>> If it is too late, please use a local connection (serial or 
>>> keyboard/screen, if not headless), or edit the /etc/ssh/sshd_config file on 
>>> your SD card from another computer.
>>
>> Ugh, that explains a few things I've seen. Cases where that breaks:
>>
>>   1) Installer
>>
>> You can set up the installer with ssh installation. That spawns sshd in the 
>> instsys, so you can install a system headlessly. But only the root user 
>> exists, so you can not log in anymore.
> 
> I guess all arches are affected. Could you fill a bug for this one, please?

https://bugzilla.suse.com/show_bug.cgi?id=1118114


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

Re: [opensuse-arm] Notice for Tumbleweed users - root access from ssh is disabled by default

[Alexander Graf]

> Am 03.12.2018 um 09:55 schrieb Guillaume GARDET :
> 
> 
> Hi,
> 
> In Tumbleweed, latest openSSH update disables root login by default.
> So, if you have only 'root' user on your headless system, please run the 
> following command on your system, before running a 'zypper dup':
> 
>  echo -e "\n# Allow root login on ssh\nPermitRootLogin yes" >> 
> /etc/ssh/sshd_config
> 
> Otherwise, you will not be able to login to your system anymore.
> 
> If it is too late, please use a local connection (serial or keyboard/screen, 
> if not headless), or edit the /etc/ssh/sshd_config file on your SD card from 
> another computer.

Ugh, that explains a few things I've seen. Cases where that breaks:

  1) Installer

You can set up the installer with ssh installation. That spawns sshd in the 
instsys, so you can install a system headlessly. But only the root user exists, 
so you can not log in anymore.

  2) The same applies to the dvd rescue system.

  3) JeOS

Our images define a root user only by default, so you can not install JeOS 
images headlessly anymore

Alex


--
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)

[Alexander Graf]

On 25.11.18 14:55, Freek de Kruijf wrote:
> Op zaterdag 24 november 2018 19:43:24 CET schreef Alexander Graf:
>> On 24.11.18 17:57, Freek de Kruijf wrote:
>>> Op vrijdag 19 oktober 2018 09:52:32 CET schreef Alexander Graf:
>>>> Hi Freek,
>>>>
>>>> On 18.10.18 16:45, Freek de Kruijf wrote:
>>>>> I noticed a number of images/support for Banana Pi systems having an
>>>>> armv7
>>>>> type processor architecture. Also using names with sinovoipbpi in the
>>>>> name
>>>>> of the image.
>>>>>
>>>>> This name is also present in information about the Banana Pi M64 of
>>>>> which
>>>>> the processor architecture is aarch64. There is even an openSUSE
>>>>> Tumbleweed image, dating a year back, which runs on this system.
>>>>
>>>> Where did you find that image? Who created it?
>>>>
>>>> The Banana Pi M64 seems to be A64 based, so I'm fairly sure from a
>>>> kernel enablement point of view, we're in good shape. The only thing you
>>>> might be missing would be the low level firmware bits.
>>>
>>> Hi Alex,
>>>
>>> continued my research and found
>>> https://github.com/BPI-SINOVOIP/BPI-Mainline-kernel . I did a git clone
>>> to get the content in folder BPI-Mainline-kernel. I installed the
>>> required packages mentioned in ./linux-4.19/Documentation/
>>> process/changes.rst. However "oprofiled --version" is mentioned to check
>>> the version of the packet oprofile, but that did not work. The command
>>> should be "opreport --version".
>>> After that I ran "./build_kernel_64.sh" in folder BPI-Mainline-kernel,
>>> which succeeded. I got a lot of generated files in
>>> ./linux-4.19/output/bpi-64/ among other a vmlinux, which seems to be the
>>> new kernel. Also a lot of drivers and modules have been generated.
>>> I also downloaded the source of kernel 4.19.4 as a tar.xz, unpacked it in
>>> folder linux-4.19-4 in BPI-Mainline-kernel and adapted build_kernel_64.sh
>>> to enter linux-4.19.4. I also needed to copy a few file from linux-4.19
>>> to linux-4.19.4, build_64.sh and linux-4.19/arch/arm64/bpi_64_defconfig.
>>> After that I succeeded in building the kernel 4.19.4.
>>>
>>> So far what I did. Now the experiment to make the kernel run. If you have
>>> any suggestions, please let me know.
>>
>> I don't think you need any downstream patches for the kernel. Everything
>> in that tree only adds a few changes for the m2u/m2b boards which you
>> don't have. 4.19 from Tumbleweed should already have everything required
>> to run on that system.
> 
> I did not have any idea what is needed. I just found this website and tried 
> what it talked about, just trying to see if it also works for a newer kernel 
> from its original source. I used cross compiling on my x86_64 system with 
> Tumbleweed to get the kernel for the aarch64 system. In the generated files I 
> do find similar file names which are present on /dev/mmcblk0p1, but not all.
>  
>> So all you need is firmware that adheres to EBBR and you're all set with
>> a Tumbleweed JeOS.
> 
> I am very fresh in this area. So I have no idea what EBBR means and how to 
> build things for a JeOS system. I found in the original openSUSE image for 
> the 
> Banana Pi M64 on /dev/mmcblk0p1 a folder dtb/allwinner/ containing o.a. a 
> file 
> sun50i-a64-bananapi-m64.dtb which seems to be needed. Is this the one you are 
> referring to? There is also a folder overlay which has files *.dtbo with 
> names 
> similar to the above.
> I did not find a folder dtb in the folder with the linux source, also not 
> after the generation. However there is a folder dts as a subfolder of output, 
> so generated, in which I found a file named like above, sun50i-a64-bananapi-
> m64.dtb.
>  
>> Did anyone create a working (recent) image that works from eMMC? If so,
>> it probably boots using U-Boot? In that case, you should be able to just
>> abort the boot, modify the "boot_targets" variable to point to MMC boot
>> instead and run "boot" to boot into a Tumbleweed image on an SD card.
> 
> Yes there is a debian system that can be started from the microSD card and 
> that allows populating eMMC. However the openSUSE system does not show the 
> eMMC device. After populating eMMC with that debian system, the system will 
> start from eMMC, however after that the microSD is no longer visible, as far 
> as I recall.
> However what you sugge

Re: [opensuse-arm] Question about support for Banana Pi (M64)

[Alexander Graf]

On 25.11.18 19:34, Andreas Färber wrote:
> 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.

Are you sure? 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.

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

> 
> 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
> 
-- 
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)

[Alexander Graf]

On 24.11.18 17:57, Freek de Kruijf wrote:
> Op vrijdag 19 oktober 2018 09:52:32 CET schreef Alexander Graf:
>> Hi Freek,
>>
>> On 18.10.18 16:45, Freek de Kruijf wrote:
>>> I noticed a number of images/support for Banana Pi systems having an armv7
>>> type processor architecture. Also using names with sinovoipbpi in the name
>>> of the image.
>>>
>>> This name is also present in information about the Banana Pi M64 of which
>>> the processor architecture is aarch64. There is even an openSUSE
>>> Tumbleweed image, dating a year back, which runs on this system.
>>
>> Where did you find that image? Who created it?
>>
>> The Banana Pi M64 seems to be A64 based, so I'm fairly sure from a
>> kernel enablement point of view, we're in good shape. The only thing you
>> might be missing would be the low level firmware bits.
> 
> Hi Alex,
> 
> continued my research and found 
> https://github.com/BPI-SINOVOIP/BPI-Mainline-kernel . I did a git clone to 
> get the content in folder BPI-Mainline-kernel. I 
> installed the required packages mentioned in ./linux-4.19/Documentation/
> process/changes.rst. However "oprofiled --version" is mentioned to check the 
> version of the packet oprofile, but that did not work. The command should be 
> "opreport --version".
> After that I ran "./build_kernel_64.sh" in folder BPI-Mainline-kernel, which 
> succeeded. I got a lot of generated files in ./linux-4.19/output/bpi-64/ 
> among 
> other a vmlinux, which seems to be the new kernel. Also a lot of drivers and 
> modules have been generated.
> I also downloaded the source of kernel 4.19.4 as a tar.xz, unpacked it in 
> folder linux-4.19-4 in BPI-Mainline-kernel and adapted build_kernel_64.sh to 
> enter linux-4.19.4. I also needed to copy a few file from linux-4.19 to 
> linux-4.19.4, build_64.sh and linux-4.19/arch/arm64/bpi_64_defconfig.
> After that I succeeded in building the kernel 4.19.4.
> 
> So far what I did. Now the experiment to make the kernel run. If you have any 
> suggestions, please let me know.

I don't think you need any downstream patches for the kernel. Everything
in that tree only adds a few changes for the m2u/m2b boards which you
don't have. 4.19 from Tumbleweed should already have everything required
to run on that system.

So all you need is firmware that adheres to EBBR and you're all set with
a Tumbleweed JeOS.

Did anyone create a working (recent) image that works from eMMC? If so,
it probably boots using U-Boot? In that case, you should be able to just
abort the boot, modify the "boot_targets" variable to point to MMC boot
instead and run "boot" to boot into a Tumbleweed image on an SD card.


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

Re: Re : [opensuse-arm] ARMv8 CRC and Crypto on openSUSE Leap 42.1

[Alexander Graf]

On 12.11.18 20:54, Jeffrey Walton wrote:
> On Mon, Nov 12, 2018 at 2:31 PM Guillaume GARDET
>  wrote:
>>
>> - Jeffrey Walton  a écrit :
>>> Hi Everyone,
>>>
>>> I'm working on the GCC Compile Farm. I'm on machine
>>> gcc118.fsffrance.org, which is an ARMv8.a machine. The cpu offers CRC
>>> and Crypto. The machine runs openSUSE Leap 42.1.
>>
>> openSUSE Leap 42.1 is discontinued. Please use Leap 15.0 (the latest Leap 
>> version) or openSUSE Tumbleweed, the rolling release, with latest software, 
>> including latest kernel.
>> Tumbleweed ISO: http://download.opensuse.org/ports/aarch64/tumbleweed/iso/
>> or:
>> Leap 15.0 ISO: 
>> http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/iso/
> 
> Thanks Guillaume .
> 
> We don't really have a choice in the matter.

Why do you not have a choice here? It really makes little sense to
develop against an out of support distribution, no?

> Would you happen to know if that version of openSUSE supports CRC and
> Crypto extensions?

It depends on what you consider "supports" I guess? I don't think we
shipped binutils on 42.1 yet that allowed you to assemble crc enabled code.

> Sorry to ask. I need to know if it is my problem or someone else's
> problem. If its my problem I need to fix it.

I would really recommend to update the system. Can you ask the gcc
Compile Farm people to do that for you?

If not, do you have root access? If so, you should be able to create a
chroot and just run your tests from there. The kernel shouldn't really
care whether you're running crc operations:


http://download.opensuse.org/ports/aarch64/distribution/leap/15.0/appliances/openSUSE-Leap15.0-ARM-JeOS.aarch64-rootfs.aarch64-2018.07.02-Buildlp150.1.1.tar.xz


Alex
-- 
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)

[Alexander Graf]

Hi Freek,

On 18.10.18 16:45, Freek de Kruijf wrote:
> I noticed a number of images/support for Banana Pi systems having an armv7 
> type processor architecture. Also using names with sinovoipbpi in the name of 
> the image.
> 
> This name is also present in information about the Banana Pi M64 of which the 
> processor architecture is aarch64. There is even an openSUSE Tumbleweed 
> image, 
> dating a year back, which runs on this system.

Where did you find that image? Who created it?

The Banana Pi M64 seems to be A64 based, so I'm fairly sure from a
kernel enablement point of view, we're in good shape. The only thing you
might be missing would be the low level firmware bits.

The idea openSUSE scenario for that would be if someone in the community
did a "firmware installer" that really just writes U-Boot and ATF onto
the eMMC. That U-Boot would then run distro boot and provide a workable
DT for the platform.

With that in place, you could just take the openSUSE installer iso, boot
it, and install your system as with any other machine. No need for images.

> 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.

It's not very complicated to have such an image available. In fact, all
it takes is someone who takes the pieces necessary (ATF, U-Boot), makes
sure everything's mainline and built in our copies and then sends a
submit request to the JeOS package to enable the port.


Alex
-- 
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

[Alexander Graf]

On 01.10.18 05:01, Walter M. Peteren wrote:
> On Monday, July 30, 2018 11:35:10 AM CDT Matwey V. Kornilov wrote:
>> 2018-07-30 14:23 GMT+03:00 Alexander Graf :
>>> Hi Matwey,
>>>
>>> On 07/29/2018 01:19 PM, Matwey V. Kornilov wrote:
>>>> Hello,
>>>>
>>>> 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). And currently I see the
>>>> following new issue:
>>>>
>>>> mmc1 is current device
>>>> Scanning mmc 1:2...
>>>> 52462 bytes read in 43 ms (1.2 MiB/s)
>>>> Failed to mount ext2 filesystem...
>>>> ** Unrecognized filesystem type **
>>>> Scanning mmc 1:1...
>>>> Found EFI removable media binary efi/boot/bootaa64.efi
>>>> reading efi/boot/bootaa64.efi
>>>> 1247744 bytes read in 58 ms (20.5 MiB/s)
>>>> ## Starting EFI application at 0200 ...
>>>> Card did not respond to voltage select!
>>>> mmc_init: -95, time 10
>>>> Scanning disk rksd...@ff52.blk...
>>>> Scanning disk rksd...@ff50.blk...
>>>> Found 2 disks
>>>> Welcome to GRUB!
>>>>
>>>> ethernet@ff54 Waiting for PHY auto negotiation to complete.
>>>> TIMEOUT !
>>>> Could not initialize PHY ethernet@ff54
>>>>
>>>>  GNU GRUB  version 2.02
>>>>   
>>>>   Minimal BASH-like line editing is supported. For the first word, TAB
>>>>   
>>>> lists possible command completions. Anywhere else TAB lists possible
>>>> device or file completions.
>>>>
>>>> grub>
>>>>
>>>>
>>>> I see that both dtb file and EFI GRUB executable are loaded. But instead
>>>> of GRUB menu I see GRUB command line. I suppose it means that grub
>>>> failed to fetch GRUB configuration. How could I debug further what is
>>>> wrong?
>>>
>>> Correct. Grub failed to fetch the configuration because it failed to
>>> initialize the prefix correctly. If you run "set" on the command line, you
>>> should be able to see that the prefix is wrong. You can as interim step
>>> set
>>> it manually using the set command and then run "normal". That should get
>>> you a working grub menu.
>>
>> Indeed, the prefix is (hd0)/efi/boot, instead of (hd0,gpt1)/efi/boot.
>>
>>> The really important question is why grub could not determine its prefix
>>> correctly though. 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
>>
>>> Alex
> 
> Has anyone gotten their rock64 to boot opensuse?
> 
> I have ayufan's u-boot installed to SPI.
> 
> The opensuse Tumbleweed JeOS image downloaded from https://
> download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rockchip/
> images/
> 
> I've dd'ed the image to emmc and usb. The boot partition seems to start at 
> the 
> correct position 32768, but when the rock64 boots, I'm dropped to grub shell 

This is most likely because of a bug in the device path logic in u-boot
versions between 2017.09 and 2017.11.

> grub>
> grub>  ls 
>  yields (hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)
> grub>  set prefix=(hd0,gpt1)/efi/boot
> grub>  set root=(hdo,gpt3)
> grub>  set btrfs_relative_path=yes  < yes or blank yields the same
> grub>  normal
> 
> yields the grub menu, and whether I chose Tumbleweed or failsafe I get:
>Loading kernel...
>Loading initrd...
>EFI stub: Booting Linux Kernel...
>EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
>EFI stub: ERROR: Could not determine UEFI Secure Boot status.
>EFI stub: Using DTB from configuration table
>EFI stub: Exiting boot services and installing virtual address map
> 
> and that's as far as it gets.

That means Linux booted. It's a matter of fiddling with DT and kernel
command line options to also make it show something.

Does your device tree contain a /chosen node with an stdout-path
property? In that case, passing "earlycon" on the kernel command line
might already be enough.


Alex

> 
> My internet searches don't provide me with a howto on grub with btrfs and the 
> man page for grub2-editenv is very sparse.
> 
> Thanks for any help.
> 
> Mark
> 
> 
> 
> 
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Re: Control output pin on RPi

[Alexander Graf]

On 05.09.18 11:00, Volker Kuhlmann wrote:
> On Wed 05 Sep 2018 19:42:18 NZST +1200, Alexander Graf wrote:
> 
>> You need to first make sure the pin is muxed properly as GPIO and not
>> associated with a special function:
>>
>>   /sys/kernel/debug/pinctrl/3f20.gpio/pinmux-pins
>>
>> Once that's clear, you can use the GPIO export to actually access the
>> GPIO function.
> 
> Ahh, how obvious... ;-) Thanks! OK, makes sense.
> grep gpio4 pinmux-pins says
>   pin 4 (gpio4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> and I guess it ought to not say "MUX UNCLAIMED".
> 
> But I can't find how to do that. All online instructions go straight to
> exporting the pin (assuming a base of 0...).
> 
> Appending
>   [all]
>   gpio=4=op,dh
>   gpio=462=op,dh
> to /boot/efi/extraconfig.txt and rebooting makes no difference.
> 
> I'm stuck again :-(

Looks like the pin muxing actually happens automatically :)

rpi:~ # grep 'pin 4 ' /sys/kernel/debug/pinctrl/3f20.gpio/pins
pin 4 (gpio4) function gpio_in in hi; irq 83 (none)
rpi:~ # echo $(( 458 + 4 )) > /sys/class/gpio/export
rpi:~ # echo out > /sys/class/gpio/gpio462/direction
rpi:~ # grep 'pin 4 ' /sys/kernel/debug/pinctrl/3f20.gpio/pins
pin 4 (gpio4) function gpio_out in lo; irq 83 (none)
rpi:~ # echo 1 > /sys/class/gpio/gpio462/value
rpi:~ # grep 'pin 4 ' /sys/kernel/debug/pinctrl/3f20.gpio/pins
pin 4 (gpio4) function gpio_out in hi; irq 83 (none)


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

Re: [solved] Re: [opensuse-arm] How to get openSUSE aarch64 on a RPi3B+?

[Alexander Graf]

On 08/16/2018 10:13 AM, Volker Kuhlmann wrote:

See $SUBJECT - the Leap 15.0 JeOS image fails to boot.

openSUSE-Leap15.0-ARM-JeOS-raspberrypi3.aarch64-2018.07.02-Buildlp150.1.1.raw.xz

dd the .raw to a 16GB micro SD card on a linux desktop computer.

Check the config.txt:

mount /dev/sd_usb3_uSD2 /mnt -r

/mnt/boot/vc/config.txt contains arm_control=0x200
(Ugh, mount point not empty)

mount /dev/sd_usb3_uSD1 /mnt/boot/ -r

/mnt/boot/config.txt contains arm_control=0x200

The last 2 blocks of the micro SD card are zeroes.

Powerup:
Green LED flashes briefly, colourwheel screen shows + disappears,
stuck, with screen showing
Net:   No ethernet found.
starting USB...
USB0:   Core release: 2.80a
scanning bus 0 for devices...

(After over an hour I gave up; it'd be useless anyway if it took
that long to boot.)


This sounds like the U-Boot USB stack is unhappy about something on your 
USB bus. What devices do you have connected via USB to your RPi3? Can 
you try to unplug all and see how far you get?



Alex

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

[Alexander Graf]

On 07/30/2018 06:35 PM, Matwey V. Kornilov wrote:

2018-07-30 14:23 GMT+03:00 Alexander Graf :

Hi Matwey,

On 07/29/2018 01:19 PM, Matwey V. Kornilov wrote:

Hello,

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). And currently I see the
following new issue:

mmc1 is current device
Scanning mmc 1:2...
52462 bytes read in 43 ms (1.2 MiB/s)
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Scanning mmc 1:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
1247744 bytes read in 58 ms (20.5 MiB/s)
## Starting EFI application at 0200 ...
Card did not respond to voltage select!
mmc_init: -95, time 10
Scanning disk rksd...@ff52.blk...
Scanning disk rksd...@ff50.blk...
Found 2 disks
Welcome to GRUB!

ethernet@ff54 Waiting for PHY auto negotiation to complete.
TIMEOUT !
Could not initialize PHY ethernet@ff54
  GNU GRUB  version 2.02

   Minimal BASH-like line editing is supported. For the first word, TAB
 lists possible command completions. Anywhere else TAB lists possible
 device or file completions.



grub>


I see that both dtb file and EFI GRUB executable are loaded. But instead
of GRUB menu I see GRUB command line. I suppose it means that grub
failed to fetch GRUB configuration. How could I debug further what is
wrong?


Correct. Grub failed to fetch the configuration because it failed to
initialize the prefix correctly. If you run "set" on the command line, you
should be able to see that the prefix is wrong. You can as interim step set
it manually using the set command and then run "normal". That should get you
a working grub menu.


Indeed, the prefix is (hd0)/efi/boot, instead of (hd0,gpt1)/efi/boot.


The really important question is why grub could not determine its prefix
correctly though. 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


Yes, that probably has one or two bugs in the device path support. Can 
you try upstream instead?



Alex

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

[Alexander Graf]

Hi Matwey,

On 07/29/2018 01:19 PM, Matwey V. Kornilov wrote:

Hello,

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). And currently I see the
following new issue:

mmc1 is current device
Scanning mmc 1:2...
52462 bytes read in 43 ms (1.2 MiB/s)
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Scanning mmc 1:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
1247744 bytes read in 58 ms (20.5 MiB/s)
## Starting EFI application at 0200 ...
Card did not respond to voltage select!
mmc_init: -95, time 10
Scanning disk rksd...@ff52.blk...
Scanning disk rksd...@ff50.blk...
Found 2 disks
Welcome to GRUB!

ethernet@ff54 Waiting for PHY auto negotiation to complete.
TIMEOUT !
Could not initialize PHY ethernet@ff54
 GNU GRUB  version 2.02

  Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.



grub>


I see that both dtb file and EFI GRUB executable are loaded. But instead
of GRUB menu I see GRUB command line. I suppose it means that grub
failed to fetch GRUB configuration. How could I debug further what is wrong?


Correct. Grub failed to fetch the configuration because it failed to 
initialize the prefix correctly. If you run "set" on the command line, 
you should be able to see that the prefix is wrong. You can as interim 
step set it manually using the set command and then run "normal". That 
should get you a working grub menu.


The really important question is why grub could not determine its prefix 
correctly though. What U-Boot version are you basing on? There were a 
few bugs with the device path exposure in 2018.05 IIRC.



Alex

--
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+?

[Alexander Graf]

On 27.07.18 11:19, Sten Bert wrote:
> Freek,
> 
> Unfortunally - no success!
> Her'e my outputs:
> 
> ./sd-card.sh
> 2+0 records in
> 1024+0 records out
> 1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00331344 s, 309 kB/s
> 
> # df -h /dev/sdf1
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sdf1    31G   16K   31G   1% /run/media/root/A402-8523
> 
> # xzcat
> openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64-2017.07.26-Build1.1.raw.xz
> | dd bs=4M of=/dev/sdf1 iflag=fullblock oflag=direct; sync

of= needs to be /dev/sdf, not /dev/sdf1 :).

> 383+1 records in
> 383+1 records out
> 1607467008 bytes (1.6 GB, 1.5 GiB) copied, 136.038 s, 11.8 MB/s
> 
> # df -h /dev/sdf1
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sdf1    31G   16K   31G   1% /run/media/root/A402-8523
> 
> Shouldn't be a difference there before/after?

Please also make sure you do not have any file system mounted when you
do the dd. Otherwise an unmount afterwards might corrupt the newly
written file system.


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

Re: [opensuse-arm] Re: Z-turn Lite

[Alexander Graf]

> Am 25.07.2018 um 16:20 schrieb Matwey V. Kornilov :
> 
>> On 25.07.2018 17:08, Alexander Graf wrote:
>> 
>> 
>>> Am 25.07.2018 um 15:42 schrieb Matwey V. Kornilov 
>>> :
>>> 
>>> 
>>> Hi,
>>> 
>>> Does anybody tried Z-turn Lite board with combined CPU/FPGA SoC? It
>>> seems to be the most inexpensive model based on Xilinx Zynq SoC.
>>> 
>>> http://www.myirtech.com/list.asp?id=565
>> 
>> I regularly use the 7020 based Z-Turn. I guess enabling the Lite shouldn't 
>> bee too hard.
>> 
>> Alex
> 
> Cannot find it on openSUSE wiki.

Did I forget to build an image too?

> Is FPGA running supported well with
> upstream kernel? What is overall support?

Depends on what you're trying to do. If all you need is a constant bitstream 
that is pushed in from FSBL/U-Boot, it works very well.

I have personally not used fpga manager for runtime fpga updates though.

Alex


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

Re: [opensuse-arm] Z-turn Lite

[Alexander Graf]

> Am 25.07.2018 um 15:42 schrieb Matwey V. Kornilov :
> 
> 
> Hi,
> 
> Does anybody tried Z-turn Lite board with combined CPU/FPGA SoC? It
> seems to be the most inexpensive model based on Xilinx Zynq SoC.
> 
> http://www.myirtech.com/list.asp?id=565

I regularly use the 7020 based Z-Turn. I guess enabling the Lite shouldn't bee 
too hard.

Alex

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

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

Re: [opensuse-arm] Tests of ARM Leap 15.0

[Alexander Graf]

On 06/20/2018 09:00 AM, Guillaume Gardet wrote:



Le 19/06/2018 à 22:11, Frank Kunz a écrit :

Am 19.06.2018 um 20:23 schrieb Frank Kunz:

Am 11.06.2018 um 08:27 schrieb Guillaume Gardet:


Tested armv7l JeOS:X11-olinuxinolime2 (Allwinner A20 dual core) and
JeOS:X11-olinuxinolime (Allwinner A10 sinngle core) with HDMI 
output and

usb mouse + keyboard. For both network + serial console works also.

Thanks for testing! :)

Guillaume


Hello,

I tested also JeOS-socfpgade0nanosoc, but this does not boot at all.
u-boot is not installed in the raw image. By doing that manually it 
works.


It seems that the /usr/src/packages/KIWIROOT-oem path is not there and
this is used by the uboot-image-install.in for different things, 
also to

install the uboot for this target. I added "ls -l /usr/src/packages" to
that script and it is not displaying anything. The directory is empty.
Here
https://build.opensuse.org/build/home:frank_kunz:branches:openSUSE:Leap:15.0:Ports:Live/images_arm/armv7l/JeOS:JeOS-socfpgade0nanosoc/_log 


at

[  917s] + [[ -d EFI ]]
[  917s] + [[ -d boot/efi/EFI ]]
[  917s] + pushd /usr/src/packages/KIWIROOT-oem/
[  917s]
/usr/src/packages/KIWI-oem/build/image-root/image/edit_boot_install.sh:
line 45: pushd: /usr/src/packages/KIWIROOT-oem/: No such file or 
directory


there is also some effect for the efi part. So also other boards might
be affected by that missing path?

Should there be an environment variable instead of the hard coded path?


...and for v2018.05 (Tumbleweed) there is the efi support for
JeOS-socfpgade0nanosoc kicked out of uboot:


commit f369e1564cf4f81654b8a806fdc325b62b6627dc
Author: Dinh Nguyen 
Date:   Thu Apr 12 09:03:37 2018 -0500

configs: socfpga: disable EFI and ISO partition types

None of the SoCFPGA platforms will support EFI/ISO partition types that
is needed for DISTRO_DEFAULTS. SoCFPGA bootroom will only support 0xa2
partition type.

This is needed to help limit the size of the SPL to within the 64k limit
that is required for SoCFPGA.

Signed-off-by: Dinh Nguyen 


With that JeOS-socfpgade0nanosoc will no longer boot since it uses 
efi :-(


Alex, I think you're involved in u-boot support with this board, or at 
least in FPGA boards. Any opinion?


I've contacted the maintainer and we'll work out a solution.


Alex

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

[Alexander Graf]

On 06/14/2018 05:43 PM, Freek de Kruijf wrote:

Op woensdag 13 juni 2018 15:58:25 CEST schreef Alexander Graf:

On 13.06.18 14:27, Freek de Kruijf wrote:

I am using a Raspberry Pi 1B to count some pulses on one of the GPIO pins,
using Python script. This script runs fine on an older version of
Tumbleweed, namely 20160625.
When I run my script on the current version, 20180502, it throws an error

message:
 GPIO.add_event_detect(PIN, GPIO.FALLING, callback=cb, bouncetime=100)

RuntimeError: Failed to add edge detection

Try to find out who throws that error. Maybe just grep for the error
message in the python library directory.

Another thing that may give hints is to run strace on your application
and see what it tries to access before and what doesn't work?


I found a message from Frank Kunz about using the pins via sysfs, of which
I have the feeling this related. Maybe not!
The solution that was mentioned was installing the pinmux driver. However
I
can't find such a thing.

The in-kernel pinmux driver is =y, so no need to install or load anything:


https://kernel.opensuse.org/cgit/kernel-source/tree/config/armv6hl/default#n
3208


Alex

I used the strace and found that in fact the equivalent bash command:
echo "4" > /sys/class/gpio/export
gives the error message:
-bash: echo: write error: Invalid argument
This command should create new devices /sys/class/gpio/gpio4/* which one can
use to change the behavior of the GPIO pins.

What can be done to make this basic bash command work.
Below some more information as root:
# ls -l /sys/class/gpio/
total 0
--w--- 1 root root 4096 jun 14 17:41 export
lrwxrwxrwx 1 root root0 apr 23 09:40 gpiochip298 -> ../../devices/
platform/soc/2020.gpio/gpio/gpiochip298
--w--- 1 root root 4096 jun 14 16:34 unexport



Sounds like the library doesn't realize that there is an offset for GPIO 
numbers on the system. The DT usually indicates what the respective 
offset is.



Alex


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

[Alexander Graf]

On 13.06.18 14:27, Freek de Kruijf wrote:
> I am using a Raspberry Pi 1B to count some pulses on one of the GPIO pins, 
> using Python script. This script runs fine on an older version of Tumbleweed, 
> namely 20160625.
> When I run my script on the current version, 20180502, it throws an error 
> message:
> GPIO.add_event_detect(PIN, GPIO.FALLING, callback=cb, bouncetime=100)
> RuntimeError: Failed to add edge detection

Try to find out who throws that error. Maybe just grep for the error
message in the python library directory.

Another thing that may give hints is to run strace on your application
and see what it tries to access before and what doesn't work?

> I found a message from Frank Kunz about using the pins via sysfs, of which I 
> have the feeling this related. Maybe not!
> The solution that was mentioned was installing the pinmux driver. However I 
> can't find such a thing.

The in-kernel pinmux driver is =y, so no need to install or load anything:


https://kernel.opensuse.org/cgit/kernel-source/tree/config/armv6hl/default#n3208


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

Re: [opensuse-arm] armv7l tw updates?

[Alexander Graf]

On 05/23/2018 02:42 PM, Adrian Schröter wrote:

On Mittwoch, 23. Mai 2018, 14:35:35 CEST wrote Alexander Graf:

On 05/23/2018 09:09 AM, guillaume.gar...@free.fr wrote:

- Alexander Graf <ag...@suse.de> a écrit :

Am 22.05.2018 um 19:47 schrieb Dirk Müller <d...@dmllr.de>:

Hi,


http://download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/

Last update was snapshot 20180319 but no updates since then.

Same is true for armv7...

Anything got stuck?

Any updates on this?

We managed to publish it once manually, currently we have massive
performance issues due to to-test-manager waiting for ftp trees
for armv6,armv7 and aarch64 plus all the live images (with KDE and GNOME
flavors) to build which basically never finishes.

I've reduced the refreshing to twice a week, we might have to go down to
once a week or remove some images. Does anyone care strongly about GNOME or
KDE images?

What I would much rather prefer is to trim the other dimension.

What if we could take the efi image builds as build input in OBS? Then we could 
just apply the few u-boot additions ad hoc and automatically create a board 
specific image without all of the image building overhead.

It would be awesome! :) Is kiwi ready for such a thing?

I think this would have to happen outside of kiwi. So kiwi would produce
for example a JeOS-efi image. A different build job could create a
JeOS-pine64 out of that then.

I don't think we have the logic to do that in OBS quite yet though. If
we could convince someone to add the few missing like I believe we could
dramatically reduce build times.

hm, could you just use the post kiwi build hook of the build script?

Means you need to build an rpm which provides some executable

  /usr/lib/build/kiwi_post_run

and you just require that package in your prjconf.

So you could basically run anything there and modify or produce more
images.


That sounds pretty much like one way to do it, yes. We'd lose 
parallelism, but given that everything is at least "cache hot" (files 
are on the local disk) that might make up for it.


Guillaume, do you want to take a look at this and see how far you can 
get with that approach? I guess we really just need to copy the 
{JeOS,GNOME,XFCE,...}-efi image to a temporary one, run the 
uboot-image-install script part on that and compress the result back 
into a new image.


The biggest problem I can see would be that we have a few package 
overlays as well. So how can we get the target specific u-boot packages 
into the build environment to install them in the post run step? They're 
conflicting each other IIRC.



Alex

--
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] armv7l tw updates? (was: armv6 tumbleweed updates?)

[Alexander Graf]

On 05/23/2018 09:09 AM, guillaume.gar...@free.fr wrote:

- Alexander Graf <ag...@suse.de> a écrit :



Am 22.05.2018 um 19:47 schrieb Dirk Müller <d...@dmllr.de>:

Hi,


http://download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/

Last update was snapshot 20180319 but no updates since then.

Same is true for armv7...

Anything got stuck?

Any updates on this?

We managed to publish it once manually, currently we have massive
performance issues due to to-test-manager waiting for ftp trees
for armv6,armv7 and aarch64 plus all the live images (with KDE and GNOME
flavors) to build which basically never finishes.

I've reduced the refreshing to twice a week, we might have to go down to
once a week or remove some images. Does anyone care strongly about GNOME or
KDE images?

What I would much rather prefer is to trim the other dimension.

What if we could take the efi image builds as build input in OBS? Then we could 
just apply the few u-boot additions ad hoc and automatically create a board 
specific image without all of the image building overhead.

It would be awesome! :) Is kiwi ready for such a thing?


I think this would have to happen outside of kiwi. So kiwi would produce 
for example a JeOS-efi image. A different build job could create a 
JeOS-pine64 out of that then.


I don't think we have the logic to do that in OBS quite yet though. If 
we could convince someone to add the few missing like I believe we could 
dramatically reduce build times.



Alex

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

Re: [opensuse-arm] armv7l tw updates? (was: armv6 tumbleweed updates?)

[Alexander Graf]

> Am 22.05.2018 um 19:47 schrieb Dirk Müller :
> 
> Hi,
> 
>>> http://download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/
>>> 
>>> Last update was snapshot 20180319 but no updates since then.
>> Same is true for armv7...
>>> Anything got stuck?
>> Any updates on this?
> 
> We managed to publish it once manually, currently we have massive
> performance issues due to to-test-manager waiting for ftp trees
> for armv6,armv7 and aarch64 plus all the live images (with KDE and GNOME
> flavors) to build which basically never finishes.
> 
> I've reduced the refreshing to twice a week, we might have to go down to
> once a week or remove some images. Does anyone care strongly about GNOME or
> KDE images?

What I would much rather prefer is to trim the other dimension.

What if we could take the efi image builds as build input in OBS? Then we could 
just apply the few u-boot additions ad hoc and automatically create a board 
specific image without all of the image building overhead.


Alex


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

Re: [opensuse-arm] New Raspberry Pi 3B image in repository

[Alexander Graf]

On 09.05.18 16:58, Alexander Graf wrote:
> On 05/09/2018 02:30 PM, Freek de Kruijf wrote:
>> I am very pleased to see a new image for the Raspberry Pi 3B in
>> repository
>> http://download.opensuse.org/ports/aarch64/tumbleweed/images
>>
>> I installed the image and it works. I also noticed that
>> /boot/grub2/grub.conf
>> only contains one console parameter, console=ttyS1,115200n8, on the boot
>> command line. I have a connected serial interface to the proper GIO
>> pins and I
>> do see the initial output of the boot process appear on the screen.
>> Even the
>> GRUB screen, when pressing t. However I used to see also the output of
>> the
>> boot process of openSUSE, which used to appear when having only this
>> console
>> parameter in the boot command. This output does not appear.
>>
>> How do I get this output and how do I get the ability to log in on
>> this serial
>> line?
> 
> Can you please try and see if changing the line to
> console=ttyS0,115200n8 in grub makes it work?

Reportedly that fixes it. I changed the default line in the JeOS image
now. Version 2018.05.11 (and upwards) will have working serial output then.


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

Re: [opensuse-arm] New Raspberry Pi 3B image in repository

[Alexander Graf]

On 05/09/2018 02:30 PM, Freek de Kruijf wrote:

I am very pleased to see a new image for the Raspberry Pi 3B in repository
http://download.opensuse.org/ports/aarch64/tumbleweed/images

I installed the image and it works. I also noticed that /boot/grub2/grub.conf
only contains one console parameter, console=ttyS1,115200n8, on the boot
command line. I have a connected serial interface to the proper GIO pins and I
do see the initial output of the boot process appear on the screen. Even the
GRUB screen, when pressing t. However I used to see also the output of the
boot process of openSUSE, which used to appear when having only this console
parameter in the boot command. This output does not appear.

How do I get this output and how do I get the ability to log in on this serial
line?


Can you please try and see if changing the line to 
console=ttyS0,115200n8 in grub makes it work?



Thanks!

Alex

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

Re: [opensuse-arm] Tumbleweed images for Raspberry Pi 3B and 3B+

[Alexander Graf]

On 03.05.18 17:35, Larry Finger wrote:
> On 05/03/2018 03:20 AM, Alexander Graf wrote:
>> On 05/03/2018 08:12 AM, Cor Slot wrote:
>>> Hi
>>>
>>> When will new Tumbleweed images be published for Raspberry Pi 3 (3B,
>>> 3B+)?
>>
>> Publishing is still broken :(. Let me poke again.
>>
>>> Images on http://download.opensuse.org/ports/aarch64/tumbleweed/images/
>>> are dated Feb 02, 2018 and don't work on the 3B+.
>>>
>>> Or can I use an alternative method to install Tumbleweed on a 3B+?
>>> (how?)
>>
>> You can get the latest images directly from OBS:
>>
>>    $ osc getbinaries openSUSE:Factory:ARM:Live
>> JeOS:JeOS-raspberrypi3.aarch64 images aarch64
>>
>> That image boots (for the most part) for me on a B+. Unfortunately the
>> current Tumbleweed kernel (4.16.5) does not contain my fix for the
>> network adapter yet, so you get a kernel oops on boot. Once the kernel
>> is on 4.17 that should be ok though, as I unfortunately forgot to mark
>> the patch[1] for stable, so it won't get into 4.16.
>>
>>
>> Alex
>>
>> [1] https://patchwork.kernel.org/patch/10321831/
> 
> Alex,
> 
> If you send E-mail to GregKH telling him that the patch should also be
> applied to 4.16, he will add it to the older kernel.

Looking through my email Greg actually did queue it for 4.16 yesterday :)

It still means that it's not in current Tumbleweed builds yet.


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

Re: [opensuse-arm] Tumbleweed images for Raspberry Pi 3B and 3B+

[Alexander Graf]

On 05/03/2018 08:12 AM, Cor Slot wrote:

Hi

When will new Tumbleweed images be published for Raspberry Pi 3 (3B, 3B+)?


Publishing is still broken :(. Let me poke again.


Images on http://download.opensuse.org/ports/aarch64/tumbleweed/images/
are dated Feb 02, 2018 and don't work on the 3B+.

Or can I use an alternative method to install Tumbleweed on a 3B+? (how?)


You can get the latest images directly from OBS:

  $ osc getbinaries openSUSE:Factory:ARM:Live 
JeOS:JeOS-raspberrypi3.aarch64 images aarch64


That image boots (for the most part) for me on a B+. Unfortunately the 
current Tumbleweed kernel (4.16.5) does not contain my fix for the 
network adapter yet, so you get a kernel oops on boot. Once the kernel 
is on 4.17 that should be ok though, as I unfortunately forgot to mark 
the patch[1] for stable, so it won't get into 4.16.



Alex

[1] https://patchwork.kernel.org/patch/10321831/
--
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 2

[Alexander Graf]

On 23.04.18 19:28, jimmypierre.rouen.fra...@gmail.com wrote:
> 
> 
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de] 
> Sent: 23 April 2018 19:20
> To: Matthias Brugger; jimmypierre.rouen.fra...@gmail.com; 
> opensuse-arm@opensuse.org
> Subject: Re: [opensuse-arm] Raspberry Pi 2
> 
> 
> 
> On 23.04.18 18:43, Matthias Brugger wrote:
>> Hi Jimmy,
>>
>> On 04/23/2018 06:20 PM, jimmypierre.rouen.fra...@gmail.com wrote:
>>> Greetings
>>>
>>> In view of Linux Presentation Day April 28, I got two Raspberry Pi 3 with 
>>> SUSE and would happily install openSUSE on three Raspberry Pi 2, that we 
>>> own, if only there is a straight forward image ready to go. If you happen 
>>> to know of a working image for RPI 2. 
>>>
>>
>> Did you tried the images here:
>> https://en.opensuse.org/HCL:Raspberry_Pi2
> 
> I think the published images are still broken :(.
> 
> If they don't work for you, please directly fetch the current ones from OBS:
> 
>   $ osc getbinaries openSUSE:Factory:ARM:Live JeOS:JeOS-raspberrypi2
> images armv7l
> 
> These should hopefully work :).
> 
> Hi guys,
> 
> I have been downloading many images but to no avail.
> 
> I will give OBS a try though.
> 
> Do you burn the image to a SD exactly as with a RAW image?

Yes, the procedure is the same as described on the wiki page above, just
that the image is not the published one, but the current bleeding edge
image.


Alex
-- 
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 2

[Alexander Graf]

On 23.04.18 18:43, Matthias Brugger wrote:
> Hi Jimmy,
> 
> On 04/23/2018 06:20 PM, jimmypierre.rouen.fra...@gmail.com wrote:
>> Greetings
>>
>> In view of Linux Presentation Day April 28, I got two Raspberry Pi 3 with 
>> SUSE and would happily install openSUSE on three Raspberry Pi 2, that we 
>> own, if only there is a straight forward image ready to go. If you happen to 
>> know of a working image for RPI 2. 
>>
> 
> Did you tried the images here:
> https://en.opensuse.org/HCL:Raspberry_Pi2

I think the published images are still broken :(.

If they don't work for you, please directly fetch the current ones from OBS:

  $ osc getbinaries openSUSE:Factory:ARM:Live JeOS:JeOS-raspberrypi2
images armv7l

These should hopefully work :).


Alex
-- 
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 1 and 2 boot failed - Initramfs unpacking failed: write error

[Alexander Graf]

On 17.04.18 01:57, Alex Armstrong wrote:
> Freek de Kruijf wrote:
>> Op dinsdag 20 maart 2018 17:05:58 CET schreef Kasimir _:
>>> Both abort the boot process with the message: "Initramfs unpacking 
>>> failed: write error"
>>>
>>> Raspberry Pi 1:
>>>  - Image: 
>>> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2018.03.19-Build1.1.raw.xz
>>>  - Console output: https://paste.opensuse.org/5939196
>>>
>>> Raspberry Pi2:
>>>  - Image: 
>>> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2018.03.19-Build1.1.raw.xz
>>> - Console output: https://paste.opensuse.org/77297849
>>> N�r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^�   ޭ隊Z)z{.�櫛�0���Ǩ�
>> I am able to get a little further.
>> You probably did not clear the highest 1024 bytes.
>> You can use:
>> dev="/dev/sdX" # X is you device with SD card
>> echo "Clear last 1024 bytes"
>> ssize=$(/usr/sbin/blockdev --getss /dev/$dev)
>> [ $ssize -ne 512 ] && echo "Sector size not equal 512" && exit 1
>> size=$(/usr/sbin/blockdev --getsz /dev/$dev)
>> dd if=/dev/zero of=/dev/$dev obs=1 seek=$(($size - 2)) count=2
>>
> I can confirm this with the Raspberry Pi 1.
> 
> I noticed a broken link in the /boot/ directory; the initrd symbolic
> link points to initrd-4.14.14-1-default which doesn't exist.  Probably
> not the cause though, as grub loads initrd.vmx directly and changing the
> link doesn't make any difference.  Also the initrd.vmx file is 73MB -
> which seems a bit large.

We currently have problems publishing newer code for Tumbleweed, so the
image you're getting today unfortunately doesn't have the fix in yet.

Could you please try to fetch the latest unpublished one using

  $ osc getbinaries openSUSE:Factory:ARM JeOS:JeOS-raspberrypi images armv6l

and try again with that one? That should have all the latest additions
such as

  * dracut based initrd (no two-step initrd problems anymore)
  * config.txt overlays supported

We're still working on making publishing work again so you can get the
image with your browser, but that will unfortunately take a bit.


Alex
-- 
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

[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.

Alex

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

[Alexander Graf]

On 04.04.18 11:08, Guillaume Gardet wrote:
> 
> 
> Le 04/04/2018 à 10:48, Marcus Schäfer a écrit :
>> Hi,
>>
>>> It seems that new kiwi does not support u-boot (non EFI/Grub2)
>>> images? Is there a solution/workaround?
>> I have not ported plain u-boot support to the next generation kiwi,
>> because
>> of the effort to move all boards to efi boot. u-boot basically works
>> as the
>> EFI firmware being capable to load the grub efi module(s).
> 
> Yes, but not all boards are supporting EFI with U-Boot. Especially
> Arndale because "Samsung's bl1 lies at sector 1, overlapping with the
> EFI GPT, so we can not use EFI".

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.

> Maybe for other boards, we may use the EFI config in kiwi, but still
> boot using u-boot script? (I will give it a try)

That should also work, yes.


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

Re: [opensuse-arm] rock64

[Alexander Graf]

> Am 10.03.2018 um 10:05 schrieb Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 
> 2018-03-10 3:03 GMT+03:00 Alexander Graf <ag...@suse.de>:
>> 
>> 
>>> On 09.03.18 19:22, Matwey V. Kornilov wrote:
>>> Well, something strange happens at pre-init stage at Rock64:
>>> 
>>> ===> Calling pre-init stage in system image
>>> [  130.501368] systemd-udevd[1848]: starting version 234
>>> [  130.751693] device-mapper: uevent: version 1.0.3
>>> [  130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20)
>>> initialised: dm-de...@redhat.com
>>> [  133.143024] Internal error: Oops - SP/PC alignment exception:
>>> 8a00 [#1] SMP
>>> [  133.143029] Kernel panic - not syncing: corrupted stack end
>>> detected inside scheduler
>>> [  133.143029]
>>> [  133.143040] SMP: stopping secondary CPUs
>>> [  133.144886] Modules linked in: dm_mod btrfs xor zstd_compress
>>> zlib_deflate raid6_pq fuse squashfs zstd_decompress xxhash loop
>>> virtio_blk mmc_block brd rk808_regulator rk808 aes_ce_blk
>>> aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64
>>> sha1_ce dwc2 ohci_platform ohci_hcd ehci_platform ehci_hcd udc_core
>>> usbcore fixed dw_mmc_rockchip dw_mmc_pltfm dw_mmc
>>> phy_rockchip_inno_usb2 mmc_core rockchip_thermal i2c_rk3x aes_neon_bs
>>> aes_neon_blk crypto_simd cryptd aes_arm64
>>> [  133.148752] CPU: 2 PID: 1868 Comm: depmod Not tainted 4.15.7-1-default #1
>>> [  133.149360] Hardware name: rockchip rock64_rk3328/rock64_rk3328,
>>> BIOS 2018.01-rc2-02249-g19e31fac0d-dirty 02/01/2018
>>> [  133.150300] pstate: 2005 (nzCv daif -PAN -UAO)
>>> [  133.150738] pc : 0x6d6d61675f7465
>> 
>> localhost:~ # echo 6d6d61675f7465 | xxd -ps -r ; echo
>> mmag_te
>> 
> 
> No idea
> 
>> Do you have any idea what that string could be? Maybe some memory that
>> really is in use by EL3 isn't declared as such in the EFI memory map?
> 
> Well, the issue is gone when I reduced initial initrd size to reasonable 
> value.

Can you try some memory tester in user space then? I‘m not sure the issue is 
actually gone, it might just not get exposed on boot anymore.

Alex

> 
>> 
>> 
>> Alex
> 
> 
> 
> -- 
> With best regards,
> Matwey V. Kornilov

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

Re: [opensuse-arm] rock64

[Alexander Graf]

On 09.03.18 19:22, Matwey V. Kornilov wrote:
> Well, something strange happens at pre-init stage at Rock64:
> 
> ===> Calling pre-init stage in system image
> [  130.501368] systemd-udevd[1848]: starting version 234
> [  130.751693] device-mapper: uevent: version 1.0.3
> [  130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20)
> initialised: dm-de...@redhat.com
> [  133.143024] Internal error: Oops - SP/PC alignment exception:
> 8a00 [#1] SMP
> [  133.143029] Kernel panic - not syncing: corrupted stack end
> detected inside scheduler
> [  133.143029]
> [  133.143040] SMP: stopping secondary CPUs
> [  133.144886] Modules linked in: dm_mod btrfs xor zstd_compress
> zlib_deflate raid6_pq fuse squashfs zstd_decompress xxhash loop
> virtio_blk mmc_block brd rk808_regulator rk808 aes_ce_blk
> aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64
> sha1_ce dwc2 ohci_platform ohci_hcd ehci_platform ehci_hcd udc_core
> usbcore fixed dw_mmc_rockchip dw_mmc_pltfm dw_mmc
> phy_rockchip_inno_usb2 mmc_core rockchip_thermal i2c_rk3x aes_neon_bs
> aes_neon_blk crypto_simd cryptd aes_arm64
> [  133.148752] CPU: 2 PID: 1868 Comm: depmod Not tainted 4.15.7-1-default #1
> [  133.149360] Hardware name: rockchip rock64_rk3328/rock64_rk3328,
> BIOS 2018.01-rc2-02249-g19e31fac0d-dirty 02/01/2018
> [  133.150300] pstate: 2005 (nzCv daif -PAN -UAO)
> [  133.150738] pc : 0x6d6d61675f7465

localhost:~ # echo 6d6d61675f7465 | xxd -ps -r ; echo
mmag_te

Do you have any idea what that string could be? Maybe some memory that
really is in use by EL3 isn't declared as such in the EFI memory map?


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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.03.07-Build2.1.raw: Invalid FAT entry

[Alexander Graf]

On 07.03.18 19:58, Matwey V. Kornilov wrote:
> 2018-03-07 21:31 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>>> Am 07.03.2018 um 19:12 schrieb Matwey V. Kornilov 
>>> <matwey.korni...@gmail.com>:
>>>
>>> 07.03.2018 21:01, Matwey V. Kornilov пишет:
>>>>
>>>> Hello,
>>>>
>>>> I am trying to use
>>>> openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.03.07-Build2.1.raw to run
>>>> Rock64. I use manually compiled u-boot
>>>> 2018.01-rc2-02249-g19e31fac0d-dirty and see the following:
>>>>
>>>> => load mmc 1:1 0x0200 efi/boot/bootaa64.efi
>>>> reading efi/boot/bootaa64.efi
>>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>>> Invalid FAT entry
>>>> 6144 bytes read in 11 ms (544.9 KiB/s)
>>>>
>>>> This didn't happen when we used kiwi-7 to build JeOS at Factory.
>>>> Can it be some issue with FAT16/FAT32?
>>>>
>>>
>>> Not sure, that related, but
>>>
>>> EFI created by Kiwi-7
>>>
>>> System ID "mkfs.fat"
>>> Media byte 0xf8 (hard disk)
>>>   512 bytes per logical sector
>>>  4096 bytes per cluster
>>> 1 reserved sector
>>> First FAT starts at byte 512 (sector 1)
>>> 2 FATs, 16 bit entries
>>>102400 bytes per FAT (= 200 sectors)
>>> Root directory starts at byte 205312 (sector 401)
>>>   512 root directory entries
>>> Data area starts at byte 221696 (sector 433)
>>> 51146 data clusters (209494016 bytes)
>>> 63 sectors/track, 255 heads
>>> 0 hidden sectors
>>>409604 sectors total
>>>
>>> EFI created by Kiwi-9
>>>
>>> System ID "mkfs.fat"
>>> Media byte 0xf8 (hard disk)
>>>   512 bytes per logical sector
>>>  2048 bytes per cluster
>>> 1 reserved sector
>>> First FAT starts at byte 512 (sector 1)
>>> 2 FATs, 12 bit entries
>>>  2048 bytes per FAT (= 4 sectors)
>>> Root directory starts at byte 4608 (sector 9)
>>>   512 root directory entries
>>> Data area starts at byte 20992 (sector 41)
>>>  1013 data clusters (2074624 bytes)
>>> 32 sectors/track, 64 heads
>>> 0 hidden sectors
>>>  4096 sectors total
>>
>> We reduced the size of the efi partition to 2MB. Maybe that triggered a bug 
>> in U-Boot?
>>
>> Could you try to build an image with a 16mb partition instead?
>>
> 
> I've reparted drive manually and created 200mb EFI partition (FAT16).
> It works well with u-boot.
> It seems that u-boot doen't like FAT12.

Ok, I've changed the default EFI partition size to 16MB. I guess there's
a better fix, but this way we should be quite compatible :).


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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.03.07-Build2.1.raw: Invalid FAT entry

[Alexander Graf]

> Am 07.03.2018 um 19:12 schrieb Matwey V. Kornilov :
> 
> 07.03.2018 21:01, Matwey V. Kornilov пишет:
>> 
>> Hello,
>> 
>> I am trying to use
>> openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.03.07-Build2.1.raw to run
>> Rock64. I use manually compiled u-boot
>> 2018.01-rc2-02249-g19e31fac0d-dirty and see the following:
>> 
>> => load mmc 1:1 0x0200 efi/boot/bootaa64.efi
>> reading efi/boot/bootaa64.efi
>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>> Invalid FAT entry
>> 6144 bytes read in 11 ms (544.9 KiB/s)
>> 
>> This didn't happen when we used kiwi-7 to build JeOS at Factory.
>> Can it be some issue with FAT16/FAT32?
>> 
> 
> Not sure, that related, but
> 
> EFI created by Kiwi-7
> 
> System ID "mkfs.fat"
> Media byte 0xf8 (hard disk)
>   512 bytes per logical sector
>  4096 bytes per cluster
> 1 reserved sector
> First FAT starts at byte 512 (sector 1)
> 2 FATs, 16 bit entries
>102400 bytes per FAT (= 200 sectors)
> Root directory starts at byte 205312 (sector 401)
>   512 root directory entries
> Data area starts at byte 221696 (sector 433)
> 51146 data clusters (209494016 bytes)
> 63 sectors/track, 255 heads
> 0 hidden sectors
>409604 sectors total
> 
> EFI created by Kiwi-9
> 
> System ID "mkfs.fat"
> Media byte 0xf8 (hard disk)
>   512 bytes per logical sector
>  2048 bytes per cluster
> 1 reserved sector
> First FAT starts at byte 512 (sector 1)
> 2 FATs, 12 bit entries
>  2048 bytes per FAT (= 4 sectors)
> Root directory starts at byte 4608 (sector 9)
>   512 root directory entries
> Data area starts at byte 20992 (sector 41)
>  1013 data clusters (2074624 bytes)
> 32 sectors/track, 64 heads
> 0 hidden sectors
>  4096 sectors total

We reduced the size of the efi partition to 2MB. Maybe that triggered a bug in 
U-Boot?

Could you try to build an image with a 16mb partition instead?


Alex

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

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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Alexander Graf]

On 27.02.18 11:18, Michal Suchánek wrote:
> On Mon, 26 Feb 2018 23:29:49 +0300
> "Matwey V. Kornilov" <matwey.korni...@gmail.com> wrote:
> 
>> 2018-02-26 23:18 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 26.02.18 20:36, Matwey V. Kornilov wrote:  
>>>> 2018-02-26 22:07 GMT+03:00 Alexander Graf <ag...@suse.de>:  
>>>>>
>>>>>
>>>>> On 26.02.18 08:19, Matwey V. Kornilov wrote:  
>>>>>> 2018-02-26 0:06 GMT+03:00 Alexander Graf <ag...@suse.de>:  
>>>>>>>
>>>>>>>  
>>>>>>>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov
>>>>>>>> <matwey.korni...@gmail.com>:
>>>>>>>>
>>>>>>>> 25.02.2018 18:22, Matwey V. Kornilov пишет:  
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am faced the issue that recent JeOS builds cannot be read
>>>>>>>>> by u-boot:
>>>>>>>>>
>>>>>>>>> ls mmc 1:2 /
>>>>>>>>> Failed to mount ext2 filesystem...
>>>>>>>>> ** Unrecognized filesystem type **  
>>>>>>>>
>>>>>>>> Hm, Now I see. Why do you use btrfs for having separate /boot
>>>>>>>> partition? Is there any reason for it?  
>>>>>>>
>>>>>>> I assume that change came with the seitch to python-kiwi. I
>>>>>>> assume the main rationale would be snapshotting of /boot, so
>>>>>>> you can load old kernels. 
>>>>>>
>>>>>> /lib/modules are on the separate partition, so it won't work
>>>>>> anyway. We could have united / and put dtb files onto separate
>>>>>> EFI partition for snapshotting kernels.  
>>>>>
>>>>> Nah, if you go that far, better ensure the built-in device tree
>>>>> from U-Boot contains a device tree that just covers everything
>>>>> you need. That way you don't need to load any dtb files. The dtb
>>>>> loading from /boot is really mostly there for cases where
>>>>> firmware is "broken" and does not deliver good, upstream
>>>>> compatible device trees. 
>>>>
>>>> Well, it would be full of pain way, especially in cases when one
>>>> bootloader fits multiple dtb-s (i.e. am335x).  
>>>
>>> It depends. Currently, U-Boot needs to detect the board and find a
>>> different dtb. Instead, it could easily just pick a different
>>> built-in dtb.
>>>
>>> Depending on the board you're on, it may even be the easiest way
>>> forward. As soon as U-Boot 2018.03 is in Factory, I'll move the
>>> Raspberry Pi to a model where the RPi firmware provided devices tree
>>> gets propagated all the way to U-Boot as well as Linux. And that
>>> makes things easier at the end of the day, because we don't need to
>>> synchronize 3 different DTs throughout the boot process.
>>>  
>>
>> At least, neither rk3328 nor marvel 3700 espressobin not able to boot
>> the kernel using bundled u-boot dtb.
>> I think this should be primarily solved upstream, if they would manage
>> to merge dts trees between different projects.
>>
> 
> I think the goal is to support the features required by u-boot by the
> DT included in u-boot and new development happens in Linux with
> occasional sync. As in it is not expected that the tree provided by
> u-boot will work with Linux as well without extra effort.
> 
> So there are a few options here:
> 
>  - update devicetrees for boards we build for in u-boot. This might not
>work flawlessly due to driver differences between u-boot and Linux.
>This should not happen but some bugs might creep in occasionally

This should simply happen in upstream U-Boot if we identify such a case
;). We're not yet another Yocto distro that patches every upstream
package to death.

>  - provide separate package of devicetrees which is completely separate
>from kernel and u-boot and installs devicetrees somewhere where the
>u-boot scripts find them

We do generate dtb packages from the Linux source tree today. I'm not
sure what source you would take them from?

>  - update, build and use the devicetrees from Linux - some dtb packages
>are built but the devicetrees are not updated on the basis that the
>in-kernel devicetrees are not used for booting ?

This is the case that's happening for Matwey today already. He's relying
on the device trees that pop out from the kernel build.


Just today, I learned that U-Boot grew btrfs support though, so maybe we
could just completely avoid the boot partition altogether if we enable
btrfs support in U-Boot.


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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Alexander Graf]

On 26.02.18 20:36, Matwey V. Kornilov wrote:
> 2018-02-26 22:07 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>> On 26.02.18 08:19, Matwey V. Kornilov wrote:
>>> 2018-02-26 0:06 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>
>>>>
>>>>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov 
>>>>> <matwey.korni...@gmail.com>:
>>>>>
>>>>> 25.02.2018 18:22, Matwey V. Kornilov пишет:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am faced the issue that recent JeOS builds cannot be read by u-boot:
>>>>>>
>>>>>> ls mmc 1:2 /
>>>>>> Failed to mount ext2 filesystem...
>>>>>> ** Unrecognized filesystem type **
>>>>>
>>>>> Hm, Now I see. Why do you use btrfs for having separate /boot partition?
>>>>> Is there any reason for it?
>>>>
>>>> I assume that change came with the seitch to python-kiwi. I assume the 
>>>> main rationale would be snapshotting of /boot, so you can load old kernels.
>>>>
>>>
>>> /lib/modules are on the separate partition, so it won't work anyway.
>>> We could have united / and put dtb files onto separate EFI partition
>>> for snapshotting kernels.
>>
>> Nah, if you go that far, better ensure the built-in device tree from
>> U-Boot contains a device tree that just covers everything you need. That
>> way you don't need to load any dtb files. The dtb loading from /boot is
>> really mostly there for cases where firmware is "broken" and does not
>> deliver good, upstream compatible device trees.
>>
> 
> Well, it would be full of pain way, especially in cases when one
> bootloader fits multiple dtb-s (i.e. am335x).

It depends. Currently, U-Boot needs to detect the board and find a
different dtb. Instead, it could easily just pick a different built-in dtb.

Depending on the board you're on, it may even be the easiest way
forward. As soon as U-Boot 2018.03 is in Factory, I'll move the
Raspberry Pi to a model where the RPi firmware provided devices tree
gets propagated all the way to U-Boot as well as Linux. And that makes
things easier at the end of the day, because we don't need to
synchronize 3 different DTs throughout the boot process.


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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Alexander Graf]

On 26.02.18 08:19, Matwey V. Kornilov wrote:
> 2018-02-26 0:06 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov 
>>> <matwey.korni...@gmail.com>:
>>>
>>> 25.02.2018 18:22, Matwey V. Kornilov пишет:
>>>>
>>>> Hi,
>>>>
>>>> I am faced the issue that recent JeOS builds cannot be read by u-boot:
>>>>
>>>> ls mmc 1:2 /
>>>> Failed to mount ext2 filesystem...
>>>> ** Unrecognized filesystem type **
>>>
>>> Hm, Now I see. Why do you use btrfs for having separate /boot partition?
>>> Is there any reason for it?
>>
>> I assume that change came with the seitch to python-kiwi. I assume the main 
>> rationale would be snapshotting of /boot, so you can load old kernels.
>>
> 
> /lib/modules are on the separate partition, so it won't work anyway.
> We could have united / and put dtb files onto separate EFI partition
> for snapshotting kernels.

Nah, if you go that far, better ensure the built-in device tree from
U-Boot contains a device tree that just covers everything you need. That
way you don't need to load any dtb files. The dtb loading from /boot is
really mostly there for cases where firmware is "broken" and does not
deliver good, upstream compatible device trees.

>> I guess there is an xml tag we can provide to make /boot ext4 again?

I've changed the xml to explicitly have a /boot partition in ext4.


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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Alexander Graf]

> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov :
> 
> 25.02.2018 18:22, Matwey V. Kornilov пишет:
>> 
>> Hi,
>> 
>> I am faced the issue that recent JeOS builds cannot be read by u-boot:
>> 
>> ls mmc 1:2 /
>> Failed to mount ext2 filesystem...
>> ** Unrecognized filesystem type **
> 
> Hm, Now I see. Why do you use btrfs for having separate /boot partition?
> Is there any reason for it?

I assume that change came with the seitch to python-kiwi. I assume the main 
rationale would be snapshotting of /boot, so you can load old kernels.

I guess there is an xml tag we can provide to make /boot ext4 again?

Alex

> 
>> 
>> And then dtb files cannot be read from /boot partition.
>> 
>> Even without dtb, EFI application cannot be read correctly here:
>> 
>> reading efi/boot/bootaa64.efi
>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>> Invalid FAT entry
>> 6144 bytes read in 11 ms (544.9 KiB/s)
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> ## Starting EFI application at 0200 ...
>> Unknown Relocation off ffe type f
>> ## Application terminated, r = 9223372036854775806
>> EFI LOAD FAILED: continuing...
>> 
> 
> 
> -- 
> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
> 

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

Re: [opensuse-arm] I can't no longer connect by ssh

[Alexander Graf]

On 19.02.18 21:37, victorhck wrote:
> El 19/02/18 a las 18:49, victorhck escribió:
>> Hello!
>>
>> Today I made a zypper dup in my RaspberryPi 3 with Tw and that was what
>> I get:
>>
>> zypper dup
>> Recuperando los metadatos del repositorio
>> openSUSE-Ports-Tumbleweed-repo-oss
>> ..[terminado]
>> Construyendo el caché del repositorio openSUSE-Ports-Tumbleweed-repo-oss
>> ..[terminado]
>> Cargando datos del repositorio...
>> Leyendo los paquetes instalados...
>> Calculando actualización de distribución...
>>
>> El siguiente paquete NUEVO va a ser instalado:
>>   raspberrypi-firmware-config
>>
>> El siguiente paquete va a ser ELIMINADO:
>>   raspberrypi-firmware-config-rpi3
>>
>> Los siguientes 6 paquetes van a ser actualizados:
>>   libjemalloc2 openSUSE-release openSUSE-release-ftp
>> raspberrypi-firmware yast2-core yast2-update
>>
>> El siguiente producto va a ser actualizado:
>>   openSUSE Tumbleweed  20180208-0 -> 20180218-0
>>
>>
>> After finished the installation I made a reboot, and now I can't connect
>> via ssh by wifi
>>
>> It was removed the firmware-config-rpi3, and installed firmware-config ¿?

This was intentional - we merged the configs into a single package. The
net result should be identical though, so I wouldn't expect breakage
from it.

>>
>> any clue? do you need more information?
>>
>> 've phun!
>>
>> PS: I think this is my first post in this mailing list, sorry if I'm a
>> bit newbie...
>>
> 
> Well, sorry, but after poweroff and poweron the pi seems to work
> properly again...

That's great to hear. Thanks a lot for the report regardless :)


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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Alexander Graf]

On 25.01.18 22:16, Matwey V. Kornilov wrote:
> 2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> 2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>> 2018-01-25 0:28 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>
>>>>
>>>> On 24.01.18 20:29, Matwey V. Kornilov wrote:
>>>>> 2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>
>>>>>>
>>>>>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>>>>>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>>>>>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> There is one more thing that is unclear to me now. As far as I
>>>>>>>>>>> understand there is no other way except FDT to provide hardware 
>>>>>>>>>>> layout
>>>>>>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far 
>>>>>>>>>>> as
>>>>>>>>>>> I understand it is grub2 task to load FDT from the table at
>>>>>>>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>>>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by 
>>>>>>>>>>> means
>>>>>>>>>>> of u-boot and placed into memory. What should happen here when OVMF 
>>>>>>>>>>> is
>>>>>>>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>>>>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>>>>>>>> hypervisor?
>>>>>>>>>>
>>>>>>>>>> It basically passes through the device tree that's generated by QEMU,
>>>>>>>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>>>>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>>>>>>>
>>>>>>>>>> Maybe something went wrong and they changed them for armv7 as well by
>>>>>>>>>> accident?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I use latest version of aarch32 OVMF firmware from 
>>>>>>>>> openSUSE:Factory:ARM.
>>>>>>>>> Well, then, I suppose, I have to see appropriate EFI driver
>>>>>>>>> (FdtClientDxe ? ) in the driver list.
>>>>>>>>
>>>>>>>> I don't think the fact that the driver is loaded tells you anything.
>>>>>>>>
>>>>>>>> I assume you can't boot the VM properly? Does grub see the DT table?
>>>>>>>> lsefi in grub should show you iirc.
>>>>>>>>
>>>>>>>> If it doesn't show it, but instead shows ACPI tables, can you try to
>>>>>>>> pass -no-acpi to QEMU?
>>>>>>>>
>>>>>>>
>>>>>>> There is nothing FDT-related at GRUB side. This is why I started to
>>>>>>> search who is responsible for providing FDT.
>>>>>>> -no-acpi also doesn't change anything.
>>>>>>>
>>>>>>> grub> lsefi
>>>>>>
>>>>>> Hm, that is the object list. Maybe it was lsefisystab?
>>>>>>
>>>>>
>>>>> Ok, here FDT is present (b1b621d5-...). How can I dump it from grub 
>>>>> console?
>>>>> If I do it right, then It has correct magic header 0xd00dfeed.
>>>>
>>>> Looks all green to me then. I guess you actually get into the kernel
>>>> then with a working device tree, but just don't see output?
>>>>
>>>
>>> Sure, I've managed to dump and decomile FDT. As far as I don't see any
>>> output, something is wrong either with serial port or interrupt
>>> controller?
>>>
>>>
>>
>> Hm, with qemu debug and grub debug on, I see the following:
>>
>> Jumping to Linux...
>> Taking exception 4 [Data Abort]
>> ...from EL1 to EL1
>> ...with ESR 0x25/0x9637
>> ...with DFSR 0x37 DFAR 0xfffdd000
>>
> 
> When I use -kernel and -initrd instead of -bios in qemu command line,
> then the kernel boots successfully.

I just ran across a very similar issue and it boiled down to the fact
that grub puts the DT outside the linear memory map of Linux.

Can you try to boot with -m 768 to ensure we always fit? That should
make it work.


Thanks,

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

Re: [opensuse-arm] Re: Change to the rebuild behavior of openSUSE:Factory:ARM

[Alexander Graf]

Hi Ralph,

We're currently debugging build consistency issues with armv6, so the
builds are disabled for now to not corrupt our tree.

Once we solved those, we'll happily enable it again and have working
builds that should hopefully build as far as their armv7 counterparts.


Thanks,

Alex

On 15.02.18 09:48, BWC Illmensee GmbH - Ralph Gauer wrote:
> Hi!
> 
> Are there such severe problems with armv6hl that it's still remaining on
> openSUSE-release-20180124-1.2.armv6hl    (including conflicts with
> the ruby version)
> instead of having the same state as armv7hl
> openSUSE-release-20180214-1.1.armv7hl        (without ruby conflicts)    ?
> 
> Best regards, Ralph
> 
> Am 09.02.2018 um 21:58 schrieb Matwey V. Kornilov:
>> 03.02.2018 11:42, Dirk Müller пишет:
>>> Hi,
>>>
>>> We had a couple of issues related to getting a new build of Factory
>>> into openqa recently. This was partially caused
>>> by ARM not able to catch up with the check in frequency of x86. To
>>> some extend this was bad luck (the critial long
>>> running build job hitting the slowest / misconfigured worker taking
>>> forever to finish) and to some extend we just can't keep
>>> up I guess.
>>>
>>> Over the last few days Alex and I have reconfigured the workers to be
>>> less overcommitted and redirecting more resource
>>> intensive jobs to the better performing variants. hopefully this helps
>>> with the overall build speed and gets us to catch up.
>>>
>>> In addition, there is a rebuild counter sync endless-loop issue that
>>> isn't fully understood yet, but apparently either aarch64
>>> or armv7l were playing ping pong rebuilds with each other. we've
>>> stabilized that by disabling armv7l build temporarily (it is reenabled
>>> now).
>>>
>>> Last but not least as an experiment we've changed the source rebuild
>>> behavior. previously, Factory:ARM was directly using the
>>> sources from Factory, so whenever there was a source change there it
>>> immediately propagated to ARM. that contributed to
>>> rarely be able to finish a ftp tree build (because that one only
>>> starts when nothing else is building, and it takes a couple of hours
>>> to
>>> complete). without a ftp tree build, new DVDs are not entering openqa.
>>>
>>> So as an experiment we've switched to frozen links. this means we're
>>> linking sources from a particular level (0201 right now) of factory,
>>> and
>>> won't get automatic updates. That seems to work fine. unfortunately
>>> the "updating link" operation crashes the build service with an error
>>> 500,
>>> so we can't update anymore, and need an admin to fix that for us.
>>>
>>> The command to update the source state to build against is this:
>>>
>>> osc api -X POST '/source/openSUSE:Factory:ARM?cmd=freezelink'
>>>
>>> It needs to be run by someone who has maintainer rights in that
>>> project. currently it crashes though.
>> How often will it be triggered?
>>
>>> Unfortunately I'll be out for a few days (vacation), so I hope alex or
>>> Andreas can figure out together with the OBS team on how to get
>>> that issue fixed.
>>>
>>> The plan is to add that into the totest manager, so that we're only
>>> taking source changes once when we just have handed off a build  to
>>> openqa. this
>>> way we might not try to do every snapshot that x86 publishes, but if
>>> we were able to finish one, we take the next one from aarch64
>>> (potentially skipping
>>> one or two interim ones on x86). this part isn't implemented yet
>>> though, I'll look at that end of next week.
>>>
>>>
>>> TIA,
>>> Dirk
>>>
>>
> 
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Re: Initrd.vmx too big

[Alexander Graf]

On 02/07/2018 09:26 AM, Matwey V. Kornilov wrote:

On 05.02.2018 15:01, Alexander Graf wrote:


On 05.02.18 11:49, Alexander Graf wrote:


On 02.02.18 18:21, Alexander Graf wrote:



Am 02.02.2018 um 14:08 schrieb Guillaume Gardet <guillaume.gar...@free.fr>:




Le 23/01/2018 à 16:59, Alexander Graf a écrit :
Howdy,


On 01/23/2018 04:20 PM, Guillaume Gardet wrote:
Hi,

I just tested the latest Tumbleweed image for my Beagleboard xM and the boot 
fails because the initrd is too big (209M uncompressed) for the RAM.

I'm seeing that pattern slowly emerge across the board. I guess it's about time 
we start to drop the legacy kiwi initrd. Can you try and see if

#define USE_DRACUT_FIRSTBOOT

in Images.kiwi.in works for you? That should also drastically reduce the initrd 
size.

Build fails because jing was not preinstalled. Once preinstalled, I get an 
error about initrd_system and efipartsize attributes not allowed:
**
  EXEC [/usr/bin/jing /usr/share/kiwi/modules/KIWISchema.rng 
/usr/src/packages/SOURCES/config.converted.xml 2>/dev/null]
[  246s] Feb-02 11:02:02 <3> : /usr/src/packages/SOURCES/config.converted.xml:21:462: error: attribute "initrd_system" not allowed here; expected attribute "bootfilesystem", "bootloader", "bootpartition", "bootpartsize", "bootprofile", "boottimeout", "btrfs_root_is_snapshot", "checkprebuilt", "compressed", "container", "devicepersistency", "editbootconfig", 
"editbootinstall", "filesystem", "firmware", "flags", "format", "formatoptions", "fsmountoptions", "fsnocheck", "fsreadonly", "fsreadwrite", "gcelicense", "hybrid", "hybridpersistent", "hybridpersistent_filesystem", "installboot", "installiso", "installprovidefailsafe", "installpxe", "installstick", 
"kernelcmdline", "luks", "luksOS", "mdraid", "primary", "ramonly", "target_blocksize", "vga", "vhdfixedtag", "volid", "wwid_wait_timeou

  t", "zfsoptions" or "zipl_targettype"

[  246s] /usr/src/packages/SOURCES/config.converted.xml:21:462: error: attribute "efipartsize" not allowed here; expected attribute "bootfilesystem", "bootpartition", "bootpartsize", "bootprofile", "boottimeout", "btrfs_root_is_snapshot", "checkprebuilt", "compressed", "container", "devicepersistency", "editbootconfig", "editbootinstall", "flags", 
"format", "formatoptions", "fsnocheck", "fsreadonly", "fsreadwrite", "gcelicense", "hybrid", "hybridpersistent", "hybridpersistent_filesystem", "installboot", "installiso", "installprovidefailsafe", "installpxe", "installstick", "kernelcmdline", "luks", "luksOS", "mdraid", "primary", 
"ramonly", "target_blocksize", "vga", "vhdfixedtag", "volid", "wwid_wait_timeout", "zfsoptions" or "zipl_targettype"
[  246s]
[  246s] Feb-02 11:02:02 <3> : KIWI exited with error(s)
**

Am I missing something?

Let‘s ask Marcus :)

I had a quick chat with him and he showed me a few other points where
our xml description is doing useless things.

However, during that discussion I realized we're not using kiwi-ng, but
instead rely on the old code. That's also why you don't get the dracut
initrd pieces to work.

To build with kiwi-ng, you'll have to modify your prjconf to pull in the
right package. Check out the o:F:A one and just do the reverse in your
project's :)

I've created a small test repo where I've enabled the dracut initrd for
rpi3: https://build.opensuse.org/project/show/home:algraf:arm-kiwi-ng

Let's see how that works out ...

Once that's ok, I guess we can switch to kiwi8 in o:F:A and then start
moving beagle to the dracut initrd.

Will we move Leap:15.0:Ports to kiwi8 as well?


That depends on whether kiwi7 is available at all. From all I can tell, 
it is not. So we would need to use python-kiwi. We however do not need 
to move to dracut initrds for all targets yet.



Alex

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

Re: [opensuse-arm] Initrd.vmx too big

[Alexander Graf]

On 05.02.18 11:49, Alexander Graf wrote:
> 
> 
> On 02.02.18 18:21, Alexander Graf wrote:
>>
>>
>>> Am 02.02.2018 um 14:08 schrieb Guillaume Gardet <guillaume.gar...@free.fr>:
>>>
>>>
>>>
>>>> Le 23/01/2018 à 16:59, Alexander Graf a écrit :
>>>> Howdy,
>>>>
>>>>> On 01/23/2018 04:20 PM, Guillaume Gardet wrote:
>>>>> Hi,
>>>>>
>>>>> I just tested the latest Tumbleweed image for my Beagleboard xM and the 
>>>>> boot fails because the initrd is too big (209M uncompressed) for the RAM.
>>>>
>>>> I'm seeing that pattern slowly emerge across the board. I guess it's about 
>>>> time we start to drop the legacy kiwi initrd. Can you try and see if
>>>>
>>>> #define USE_DRACUT_FIRSTBOOT
>>>>
>>>> in Images.kiwi.in works for you? That should also drastically reduce the 
>>>> initrd size.
>>>
>>> Build fails because jing was not preinstalled. Once preinstalled, I get an 
>>> error about initrd_system and efipartsize attributes not allowed:
>>> **
>>>  EXEC [/usr/bin/jing /usr/share/kiwi/modules/KIWISchema.rng 
>>> /usr/src/packages/SOURCES/config.converted.xml 2>/dev/null]
>>> [  246s] Feb-02 11:02:02 <3> : 
>>> /usr/src/packages/SOURCES/config.converted.xml:21:462: error: attribute 
>>> "initrd_system" not allowed here; expected attribute "bootfilesystem", 
>>> "bootloader", "bootpartition", "bootpartsize", "bootprofile", 
>>> "boottimeout", "btrfs_root_is_snapshot", "checkprebuilt", "compressed", 
>>> "container", "devicepersistency", "editbootconfig", "editbootinstall", 
>>> "filesystem", "firmware", "flags", "format", "formatoptions", 
>>> "fsmountoptions", "fsnocheck", "fsreadonly", "fsreadwrite", "gcelicense", 
>>> "hybrid", "hybridpersistent", "hybridpersistent_filesystem", "installboot", 
>>> "installiso", "installprovidefailsafe", "installpxe", "installstick", 
>>> "kernelcmdline", "luks", "luksOS", "mdraid", "primary", "ramonly", 
>>> "target_blocksize", "vga", "vhdfixedtag", "volid", "wwid_wait_timeout", 
>>> "zfsoptions" or "zipl_targettype"
>>> [  246s] /usr/src/packages/SOURCES/config.converted.xml:21:462: error: 
>>> attribute "efipartsize" not allowed here; expected attribute 
>>> "bootfilesystem", "bootpartition", "bootpartsize", "bootprofile", 
>>> "boottimeout", "btrfs_root_is_snapshot", "checkprebuilt", "compressed", 
>>> "container", "devicepersistency", "editbootconfig", "editbootinstall", 
>>> "flags", "format", "formatoptions", "fsnocheck", "fsreadonly", 
>>> "fsreadwrite", "gcelicense", "hybrid", "hybridpersistent", 
>>> "hybridpersistent_filesystem", "installboot", "installiso", 
>>> "installprovidefailsafe", "installpxe", "installstick", "kernelcmdline", 
>>> "luks", "luksOS", "mdraid", "primary", "ramonly", "target_blocksize", 
>>> "vga", "vhdfixedtag", "volid", "wwid_wait_timeout", "zfsoptions" or 
>>> "zipl_targettype"
>>> [  246s]
>>> [  246s] Feb-02 11:02:02 <3> : KIWI exited with error(s)
>>> **
>>>
>>> Am I missing something?
>>
>> Let‘s ask Marcus :)
> 
> I had a quick chat with him and he showed me a few other points where
> our xml description is doing useless things.
> 
> However, during that discussion I realized we're not using kiwi-ng, but
> instead rely on the old code. That's also why you don't get the dracut
> initrd pieces to work.
> 
> To build with kiwi-ng, you'll have to modify your prjconf to pull in the
> right package. Check out the o:F:A one and just do the reverse in your
> project's :)

I've created a small test repo where I've enabled the dracut initrd for
rpi3: https://build.opensuse.org/project/show/home:algraf:arm-kiwi-ng

Let's see how that works out ...

Once that's ok, I guess we can switch to kiwi8 in o:F:A and then start
moving beagle to the dracut initrd.


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

Re: [opensuse-arm] Initrd.vmx too big

[Alexander Graf]

> Am 02.02.2018 um 14:08 schrieb Guillaume Gardet <guillaume.gar...@free.fr>:
> 
> 
> 
>> Le 23/01/2018 à 16:59, Alexander Graf a écrit :
>> Howdy,
>> 
>>> On 01/23/2018 04:20 PM, Guillaume Gardet wrote:
>>> Hi,
>>> 
>>> I just tested the latest Tumbleweed image for my Beagleboard xM and the 
>>> boot fails because the initrd is too big (209M uncompressed) for the RAM.
>> 
>> I'm seeing that pattern slowly emerge across the board. I guess it's about 
>> time we start to drop the legacy kiwi initrd. Can you try and see if
>> 
>> #define USE_DRACUT_FIRSTBOOT
>> 
>> in Images.kiwi.in works for you? That should also drastically reduce the 
>> initrd size.
> 
> Build fails because jing was not preinstalled. Once preinstalled, I get an 
> error about initrd_system and efipartsize attributes not allowed:
> **
>  EXEC [/usr/bin/jing /usr/share/kiwi/modules/KIWISchema.rng 
> /usr/src/packages/SOURCES/config.converted.xml 2>/dev/null]
> [  246s] Feb-02 11:02:02 <3> : 
> /usr/src/packages/SOURCES/config.converted.xml:21:462: error: attribute 
> "initrd_system" not allowed here; expected attribute "bootfilesystem", 
> "bootloader", "bootpartition", "bootpartsize", "bootprofile", "boottimeout", 
> "btrfs_root_is_snapshot", "checkprebuilt", "compressed", "container", 
> "devicepersistency", "editbootconfig", "editbootinstall", "filesystem", 
> "firmware", "flags", "format", "formatoptions", "fsmountoptions", 
> "fsnocheck", "fsreadonly", "fsreadwrite", "gcelicense", "hybrid", 
> "hybridpersistent", "hybridpersistent_filesystem", "installboot", 
> "installiso", "installprovidefailsafe", "installpxe", "installstick", 
> "kernelcmdline", "luks", "luksOS", "mdraid", "primary", "ramonly", 
> "target_blocksize", "vga", "vhdfixedtag", "volid", "wwid_wait_timeout", 
> "zfsoptions" or "zipl_targettype"
> [  246s] /usr/src/packages/SOURCES/config.converted.xml:21:462: error: 
> attribute "efipartsize" not allowed here; expected attribute 
> "bootfilesystem", "bootpartition", "bootpartsize", "bootprofile", 
> "boottimeout", "btrfs_root_is_snapshot", "checkprebuilt", "compressed", 
> "container", "devicepersistency", "editbootconfig", "editbootinstall", 
> "flags", "format", "formatoptions", "fsnocheck", "fsreadonly", "fsreadwrite", 
> "gcelicense", "hybrid", "hybridpersistent", "hybridpersistent_filesystem", 
> "installboot", "installiso", "installprovidefailsafe", "installpxe", 
> "installstick", "kernelcmdline", "luks", "luksOS", "mdraid", "primary", 
> "ramonly", "target_blocksize", "vga", "vhdfixedtag", "volid", 
> "wwid_wait_timeout", "zfsoptions" or "zipl_targettype"
> [  246s]
> [  246s] Feb-02 11:02:02 <3> : KIWI exited with error(s)
> **
> 
> Am I missing something?

Let‘s ask Marcus :)

Alex

> 
> Guillaume
> 

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

Re: [opensuse-arm] Serial line after booting Raspberry Pi 3 with Tumbleweed does not work

[Alexander Graf]

> Am 25.01.2018 um 23:02 schrieb Freek de Kruijf :
> 
> I did put the image:
> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.01.19-Build3.3.raw.xz
> on a micro-SD card and booted the system with the serial line connected.
> I get some data on that serial line in the beginning, only after that 
> nothing. 
> Also a reboot shows some data, but I do not get a login prompt.
> 
> I am able to connect via ssh to that system and use it.
> 
> I found some information about not using /dev/ttyAMA0 because that one is 
> used 
> on the RPi3 for bluetooth, but 
> /dev/ttyS0 should be used. I tried to start both with:
> "systemctl start getty@ttyAMA0.service" and
> "systemctl start getty@ttyS0.service"
> but the serial line does not work.
> 
> How do I enable the use of the serial line.

The serial line is called ttyS1 with recent upstream device trees.

Also, you should have a console= parameter for that in your kernel command line 
already. Care to paste the contents of /proc/cmdline?


Alex


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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Alexander Graf]

On 24.01.18 20:29, Matwey V. Kornilov wrote:
> 2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>
>>>>
>>>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>
>>>>>>
>>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> There is one more thing that is unclear to me now. As far as I
>>>>>>> understand there is no other way except FDT to provide hardware layout
>>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>>>>>> I understand it is grub2 task to load FDT from the table at
>>>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>>>>>> of u-boot and placed into memory. What should happen here when OVMF is
>>>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>>>> hypervisor?
>>>>>>
>>>>>> It basically passes through the device tree that's generated by QEMU,
>>>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>>>
>>>>>> Maybe something went wrong and they changed them for armv7 as well by
>>>>>> accident?
>>>>>>
>>>>>
>>>>> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
>>>>> Well, then, I suppose, I have to see appropriate EFI driver
>>>>> (FdtClientDxe ? ) in the driver list.
>>>>
>>>> I don't think the fact that the driver is loaded tells you anything.
>>>>
>>>> I assume you can't boot the VM properly? Does grub see the DT table?
>>>> lsefi in grub should show you iirc.
>>>>
>>>> If it doesn't show it, but instead shows ACPI tables, can you try to
>>>> pass -no-acpi to QEMU?
>>>>
>>>
>>> There is nothing FDT-related at GRUB side. This is why I started to
>>> search who is responsible for providing FDT.
>>> -no-acpi also doesn't change anything.
>>>
>>> grub> lsefi
>>
>> Hm, that is the object list. Maybe it was lsefisystab?
>>
> 
> Ok, here FDT is present (b1b621d5-...). How can I dump it from grub console?
> If I do it right, then It has correct magic header 0xd00dfeed.

Looks all green to me then. I guess you actually get into the kernel
then with a working device tree, but just don't see output?


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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Alexander Graf]

On 24.01.18 18:10, Matwey V. Kornilov wrote:
> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>
>>>>
>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>> Hi,
>>>>>
>>>>> There is one more thing that is unclear to me now. As far as I
>>>>> understand there is no other way except FDT to provide hardware layout
>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>>>> I understand it is grub2 task to load FDT from the table at
>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>>>> of u-boot and placed into memory. What should happen here when OVMF is
>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>> hypervisor?
>>>>
>>>> It basically passes through the device tree that's generated by QEMU,
>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>
>>>> Maybe something went wrong and they changed them for armv7 as well by
>>>> accident?
>>>>
>>>
>>> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
>>> Well, then, I suppose, I have to see appropriate EFI driver
>>> (FdtClientDxe ? ) in the driver list.
>>
>> I don't think the fact that the driver is loaded tells you anything.
>>
>> I assume you can't boot the VM properly? Does grub see the DT table?
>> lsefi in grub should show you iirc.
>>
>> If it doesn't show it, but instead shows ACPI tables, can you try to
>> pass -no-acpi to QEMU?
>>
> 
> There is nothing FDT-related at GRUB side. This is why I started to
> search who is responsible for providing FDT.
> -no-acpi also doesn't change anything.
> 
> grub> lsefi

Hm, that is the object list. Maybe it was lsefisystab?


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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Alexander Graf]

On 24.01.18 17:43, Matwey V. Kornilov wrote:
> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>> Hi,
>>>
>>> There is one more thing that is unclear to me now. As far as I
>>> understand there is no other way except FDT to provide hardware layout
>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>> I understand it is grub2 task to load FDT from the table at
>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>> of u-boot and placed into memory. What should happen here when OVMF is
>>> used? In theory, it has to be configured to generate FDT from QEMU
>>> config somehow, right? Or pass-through entire FDT from Qemu
>>> hypervisor?
>>
>> It basically passes through the device tree that's generated by QEMU,
>> yes. However, OVMF defaults changed a while back and it only exposes
>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>
>> Maybe something went wrong and they changed them for armv7 as well by
>> accident?
>>
> 
> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
> Well, then, I suppose, I have to see appropriate EFI driver
> (FdtClientDxe ? ) in the driver list.

I don't think the fact that the driver is loaded tells you anything.

I assume you can't boot the VM properly? Does grub see the DT table?
lsefi in grub should show you iirc.

If it doesn't show it, but instead shows ACPI tables, can you try to
pass -no-acpi to QEMU?


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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Alexander Graf]

On 24.01.18 13:15, Matwey V. Kornilov wrote:
> Hi,
> 
> There is one more thing that is unclear to me now. As far as I
> understand there is no other way except FDT to provide hardware layout
> for armv7l kernel. Then, who is responsible for FDT loading? As far as
> I understand it is grub2 task to load FDT from the table at
> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
> firmware. In case of u-boot, dtb file is loaded from the disk by means
> of u-boot and placed into memory. What should happen here when OVMF is
> used? In theory, it has to be configured to generate FDT from QEMU
> config somehow, right? Or pass-through entire FDT from Qemu
> hypervisor?

It basically passes through the device tree that's generated by QEMU,
yes. However, OVMF defaults changed a while back and it only exposes
ACPI tables instead of DT in newer versions on AArch64 IIRC.

Maybe something went wrong and they changed them for armv7 as well by
accident?


Alex
-- 
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

[Alexander Graf]

> Am 24.01.2018 um 12:11 schrieb Freek de Kruijf <fr...@opensuse.org>:
> 
> Op woensdag 24 januari 2018 10:41:03 CET schreef Alexander Graf:
>> Hi Adrian,
>> 
>> We just had an openSUSE user report on IRC that the Leap 42.3 image
>> links for the RPi3 are broken - and they indeed are:
>> 
>> http://download.opensuse.org/ports/aarch64/distribution/leap/42.3/appliances
>> /openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64.raw.xz
>> 
>> This is the link we provide on the web page. If you look at the
>> directory, you will see that there is a properly built image:
>> 
>> openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64-2017.07.26-Build1.1.raw.xz
>> 
>> but with full name indicating the build date. We usually have short
>> links for those to allow links from the outside world. IIUC they get
>> created in the publishing step, right?
>> 
>> Funnily enough, we do have short links for "tbz" targets, but our
>> "raw.xz" ones are all missing them.
>> 
>> 
>> Alex
> 
> 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 :).


Alex


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

[opensuse-arm] RPi3 Leap image links broken

[Alexander Graf]

Hi Adrian,

We just had an openSUSE user report on IRC that the Leap 42.3 image
links for the RPi3 are broken - and they indeed are:

http://download.opensuse.org/ports/aarch64/distribution/leap/42.3/appliances/openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64.raw.xz

This is the link we provide on the web page. If you look at the
directory, you will see that there is a properly built image:

openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64-2017.07.26-Build1.1.raw.xz

but with full name indicating the build date. We usually have short
links for those to allow links from the outside world. IIUC they get
created in the publishing step, right?

Funnily enough, we do have short links for "tbz" targets, but our
"raw.xz" ones are all missing them.


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

Re: [opensuse-arm] Initrd.vmx too big

[Alexander Graf]

Howdy,

On 01/23/2018 04:20 PM, Guillaume Gardet wrote:

Hi,

I just tested the latest Tumbleweed image for my Beagleboard xM and 
the boot fails because the initrd is too big (209M uncompressed) for 
the RAM.


I'm seeing that pattern slowly emerge across the board. I guess it's 
about time we start to drop the legacy kiwi initrd. Can you try and see if


#define USE_DRACUT_FIRSTBOOT

in Images.kiwi.in works for you? That should also drastically reduce the 
initrd size.



Alex

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

Re: [opensuse-arm] Repository for openSUSE Tumbleweed architecture aach64 is not kept up-to-date

[Alexander Graf]

On 01/22/2018 12:08 PM, Freek de Kruijf wrote:

I filed a bug report with this subject as:
https://bugzilla.opensuse.org/show_bug.cgi?id=1077011

I am using the image for the Raspberry Pi 3, which is available via OBS and
which is build using the newest packages also available in OBS. This image
should be available in the regular repository, also mentioned in the wiki.
Also the newest packages should be available via the repository zypper uses to
upgrade Tumbleweed, which is currently not the case.


Publishing of images and repositories (for aarch64) happens whenever 
OpenQA passes successfully:


  https://openqa.opensuse.org/group_overview/3

I guess the last run wasn't quite happy :)


Alex

--
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 use gpio pins via sysfs

[Alexander Graf]

> Am 30.12.2017 um 23:26 schrieb Frank Kunz :
> 
> I try to control a few gpio pins via bash script. Board and OS version is:
> 
> cat /proc/device-tree/compatible
> olimex,a13-olinuxinoallwinner,sun5i-a13
> 
> cat /etc/os-release
> NAME="openSUSE Leap"
> VERSION="42.3"
> ID=opensuse
> ID_LIKE="suse"
> VERSION_ID="42.3"
> PRETTY_NAME="openSUSE Leap 42.3"
> ANSI_COLOR="0;32"
> CPE_NAME="cpe:/o:opensuse:leap:42.3"
> BUG_REPORT_URL="https://bugs.opensuse.org;
> HOME_URL="https://www.opensuse.org/;
> 
> 
> In /sys/class/gpio I do:
> echo 3 > export
> ls
> export  gpio3  gpiochip0  unexport
> ls gpio3/
> active_low  device/ direction   power/  subsystem/  uevent value
> cat gpio3/direction
> in
> 
> So when I want to change the pin direction:
> echo out > gpio3/direction
> bash: echo: write error: Unknown error 517
> 
> That is EPROBE_DEFER. The kernel signals that the requested device might be 
> probed later, ...or never. I guess that there might be some device tree item 
> missing, but from the kernel documentation I haven't found a solution for 
> that. Does anybody have an idea how to get that working?

Usually changing gpio direction is the responsibility of the pinmux driver. Can 
you check if you have one loaded?

Alex


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

[Alexander Graf]

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?

> Can the kernel allocate the required size automatically?

Yes, if you tell it on the kernel command line :). 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.

> The vc4 has probably some configuration in devicetree. As I understand
> it the devicetree is taken from some place other than the kernel.

By default we take the device tree from U-Boot. I have changes in
progress that would take them one step higher up from the RPi firmware
even, so that changes to config.txt actually get populated into the
Linux device tree.

> Is this devicetree ever updated after copying the image to the SD card?

Yes, it comes from the U-Boot package right now.


Alex
-- 
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

[Alexander Graf]

On 13.12.17 13:12, Roger Oberholtzer wrote:
> On Tue, Dec 12, 2017 at 7:32 PM, Andreas Färber  wrote:
>> 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?
> 
> GPIO pin 17. In our driver, we get interrupts on this line at up to 23
> kHz. Then we start to miss some. We look at /proc/interrupts to see
> how many have occurred.
> 
> 
> The driver is absolute minimum while we test the interrupt speed we
> might obtain:

Would it make sense to resort to polling at those speeds instead? Maybe
poll using a constant reoccuring hrtimer?

I also remember some talk about FIQ interrupts being faster than normal
ones, but I never used them.


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

Re: [opensuse-arm] Raspberry Pi3 fail to boot

[Alexander Graf]

On 10.12.17 17:08, Manu Maier wrote:
> Hello,
> 
> the last Tumbleweed image[1] of Raspberry Pi 3 fails to boot with the 
> message:
> 
> [    5.646965] Initramfs unpacking failed: write error

That sounds like the initrd grew too big? Can you check out the initrd
on the image with lsinitrd and see if you can find new files that might
have caused this?


Alex
-- 
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

[Alexander Graf]

Hi Stefan,

> Am 17.11.2017 um 23:46 schrieb Stefan Brüns :
> 
> Hi,
> 
> 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?

Alex

> 
> All these files could be moved into some SoC specific package, e.g. soc-
> config-$(kiwi-iname).
> 
> If there are no objections, I will prepare an appropriate package and submit 
> to Factory. The next step then is to remove the config file creation from the 
> JeOS files and Require the SoC specific package instead.
> 
> The list of affected files (sorted by kiwi image name):
> 
> arndale:
> /etc/dracut.conf.d/exynos_modules.conf [1]
> /etc/modprobe.d/90-blacklist-xhci.conf
> 
> chromebook:
> /etc/dracut.conf.d/exynos_modules.conf [1]
> /etc/X11/xorg.conf.d/50-touchpad.conf
> /etc/modules-load.d/cros-ec-keyb.conf
> 
> beagle:
> /etc/dracut.conf.d/omap_modules.conf
> /etc/modprobe.d/50-omapdrm.conf
> /var/lib/alsa/asound.state
> 
> panda:
> /etc/dracut.conf.d/omap_modules.conf
> /etc/modprobe.d/50-omapdrm.conf
> 
> beaglebone:
> /etc/dracut.conf.d/beagleboneblack_modules.conf
> 
> pine64, cubietruck, cubieboard, olinuxino:
> /etc/dracut.conf.d/sunxi_modules.conf
> 
> sabrelite:
> /etc/dracut.conf.d/sabrelite_modules.conf
> /etc/modules-load.d/imx6.conf
> 
> raspberrypi:
> /etc/dracut.conf.d/raspberrypi_modules.conf [2]
> /etc/modprobe.d/90-blacklist-vc4.conf
> 
> raspberrypi2:
> /etc/dracut.conf.d/raspberrypi_modules.conf [2]
> 
> raspberrypi3:
> /etc/dracut.conf.d/raspberrypi_modules.conf [2]
> /etc/modprobe.d/50-rpi3.conf
> 
> socfpgade0nanosoc:
> /etc/dracut.conf.d/socfpga_modules.conf
> 
> odroidc2, nanopik2:
> /etc/dracut.conf.d/meson_gxbb_modules.conf
> 
> m400:
> /etc/sysconfig/network/ifcfg-enp1s0
> 
> Kind regards,
> 
> Stefan
> 
> [1] contents of exynos_modules.conf for chromebook and arndale differs
> [2] contents of raspberrypi_modules.conf for rpi1/rpi2/rpi3 differs
> 
> -- 
> Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
> home: +49 241 53809034 mobile: +49 151 50412019

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

Re: [opensuse-arm] [aarch64] Tumbleweed repositories is outdated

[Alexander Graf]

Hi Manu,

On 11/13/2017 11:52 AM, Manu Maier wrote:

The last images are from the 17-Jun-2017
http://download.opensuse.org/ports/aarch64/tumbleweed/images/?C=M;O=D

and the latest packages from 21-Sep-2017
http://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/suse/aarch64/?C=M;O=D

The repositories should be updated.


The reason you're not seeing any updates is because OpenQA fails:

  https://openqa.opensuse.org/group_overview/3

Any help to resolve those failures is appreciated. The biggest problem 
FWIW is the firefox java plugin one: Supposedly the package doesn't 
exist on aarch64.


With OpenQA succeeding, publishing happens automatically.


Alex

--
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-Tumbleweed ARM JeOS-efi.armv7

[Alexander Graf]

On 08.11.17 21:17, Matwey V. Kornilov wrote:
> On 08.11.2017 23:07, Alexander Graf wrote:
>>
>>
>> On 08.11.17 21:00, Matwey V. Kornilov wrote:
>>> Hi,
>>>
>>> I am trying to run
>>> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
>>> using qemu.
>>>
>>> When I use qemu-system-aarch64 with 64-bit UEFI code
>>> aavmf-aarch64-code.bin then the only I see is the EFI console:
>>>
>>> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
>>>
>>> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
>>>
>>> UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
>>>
>>> Mapping table
>>>   FS0: Alias(s):HD1a0b:;BLK2:
>>>
>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
>>>  BLK5: Alias(s):
>>>   VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
>>>  BLK0: Alias(s):
>>>   VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>>>  BLK1: Alias(s):
>>>
>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
>>>  BLK3: Alias(s):
>>>
>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
>>>  BLK4: Alias(s):
>>>
>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
>>>
>>> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
>>> FSOpen: Open '\startup.nsh' Success
>>> FSOpen: Open '\startup.nsh' Success
>>> FSOpen: Open '\startup.nsh' Success
>>> Shell> bootarm
>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>> [Security] 3rd party image[0] can be loaded after EndOfDxe:
>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
>>> Unloading driver at 0x000
>>> Shell> Error Status: Unsupported (line number 1)
>>>
>>>
>>> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
>>> run 32-bit EFI executable.
>>
>> Correct, as far as UEFI is concerned, a 32bit ARM binary could as well
>> be a MIPS one ;). It's a different, unsupported platform for it.
>>
>>> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
>>> following:
>>>
>>> Initialization of device cfi.pflash01 failed: failed to read the initial
>>> flash content
>>>
>>> As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
>>> there are no other files in ovfm rpm package.
>>
>> Which ovmf package are you looking at? I'm not sure we properly package
>> OVMF for AArch32. But you can always try with the Linaro built ones :)
>>
>> http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-ARM/RELEASE_GCC5/
> 
> Well, the last thing I see using linaro's DEBUG build is the following:
> 
> SetUefiImageMemoryAttributes - 0xBBA48000 - 0x2000
> (0x4000)
> Found Timer interrupts 29, 30, 27, 26
> InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBA48010
> Loading driver E660EA85-058E-4B55-A54B-F02F83A24707
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BAF790A8
> add-symbol-file
> /home/buildslave/workspace/leg-virt-tianocore-edk2-upstream/edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe/DEBUG/DisplayEngine.dll
> 0xBBA26000
> Loading driver at 0x000BBA25000 EntryPoint=0x000BBA26031 DisplayEngine.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BAF79990
> ProtectUefiImageCommon - 0xBAF790A8
>   - 0xBBA25000 - 0x0001C000
> SetUefiImageMemoryAttributes - 0xBBA25000 - 0x1000
> (0x4000)
> SetUefiImageMemoryAttributes - 0xBBA26000 - 0x00017000
> (0x0002)
> SetUefiImageMemoryAttributes - 0xBBA3D000 - 0x4000
> (0x4000)
> 
> Then happens nothing but 100% CPU load.

The file on the link I provided works just fine for me:

  $ qemu-system-arm -nographic -M virt -cpu cortex-a15 -bios QEMU_EFI.fd


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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Alexander Graf]

On 08.11.17 21:00, Matwey V. Kornilov wrote:
> Hi,
> 
> I am trying to run
> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
> using qemu.
> 
> When I use qemu-system-aarch64 with 64-bit UEFI code
> aavmf-aarch64-code.bin then the only I see is the EFI console:
> 
> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
> 
> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
> 
> UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
> 
> Mapping table
>   FS0: Alias(s):HD1a0b:;BLK2:
> 
> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
>  BLK5: Alias(s):
>   VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
>  BLK0: Alias(s):
>   VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>  BLK1: Alias(s):
> 
> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
>  BLK3: Alias(s):
> 
> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
>  BLK4: Alias(s):
> 
> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
> 
> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
> FSOpen: Open '\startup.nsh' Success
> FSOpen: Open '\startup.nsh' Success
> FSOpen: Open '\startup.nsh' Success
> Shell> bootarm
> FSOpen: Open '\efi\boot\bootarm.EFI' Success
> FSOpen: Open '\efi\boot\bootarm.EFI' Success
> FSOpen: Open '\efi\boot\bootarm.EFI' Success
> FSOpen: Open '\efi\boot\bootarm.EFI' Success
> [Security] 3rd party image[0] can be loaded after EndOfDxe:
> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
> Unloading driver at 0x000
> Shell> Error Status: Unsupported (line number 1)
> 
> 
> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
> run 32-bit EFI executable.

Correct, as far as UEFI is concerned, a 32bit ARM binary could as well
be a MIPS one ;). It's a different, unsupported platform for it.

> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
> following:
> 
> Initialization of device cfi.pflash01 failed: failed to read the initial
> flash content
> 
> As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
> there are no other files in ovfm rpm package.

Which ovmf package are you looking at? I'm not sure we properly package
OVMF for AArch32. But you can always try with the Linaro built ones :)

http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-ARM/RELEASE_GCC5/

> What is the proper way to run JeOS-efi.armv7? Is it supposed to work in
> qemu?

It should work, yes. It should also work on any platform that has distro
boot enabled and runs with recent U-Boot.


Alex
-- 
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

[Alexander Graf]

> Am 25.10.2017 um 09: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?
> 
>> Since we use U-Boot, such external Raspberry Pi examples won't work and
>> you should use U-Boot's fdt apply command instead.
> 
> Intressting, I'm still trying to understand the whole boot process and
> at which time which component is loaded and can be modified. I thought
> the config.txt is loaded directly before u-boot and therefore SPI gets
> activated via that dtparam switch.
> 
> So I have to get my head around the whole EFI boot.

I have work in progress that would allow you to modify config.txt and see the 
dt changes populated to Linux, but we‘re not fully there yet.

Today we simply ignore the device tree we get generated by start.elf (which 
includes config.txt changes) and replace it with a built-in one in U-Boot. So 
today you need to then modify that one again.


Alex


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

Re: [opensuse-arm] Re: EspressoBin

[Alexander Graf]

On 20.10.17 16:21, Matwey V. Kornilov wrote:
> 20.10.2017 17:12, Alexander Graf пишет:
>>
>>
>> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>>> Hi,
>>>
>>> I've just received EspressoBin 1G. Any success stories how to run openSUSE?
>>>
>>
>> I think you'll basically have to somehow flash a working U-Boot with
>> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>> stick and cross your fingers that gets you to a point where you can
>> install :)
> 
> It has microsd card, I think it should be able to boot from sd, no?
> I also need to to find serial console pins on the board :)

There seems to be a lengthy discussion on the mailing list. I guess you
can select the boot device using DIP switches though?

  http://espressobin.net/forums/topic/how-to-flash-u-boot/


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

Re: [opensuse-arm] EspressoBin

[Alexander Graf]

On 20.10.17 13:57, Matwey V. Kornilov wrote:
> Hi,
> 
> I've just received EspressoBin 1G. Any success stories how to run openSUSE?
> 

I think you'll basically have to somehow flash a working U-Boot with
distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
stick and cross your fingers that gets you to a point where you can
install :)


Alex
-- 
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

[Alexander Graf]

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/

However, we seem to be missing checksums there? I assume that's a bug in
Dirk's magical provisioning script :)


Alex
-- 
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

[Alexander Graf]

On 13.10.17 11:17, Frank Kunz wrote:
> Hi,
> 
> 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.

You could also create a custom boot.scr that gets picked up from
$bootcmd in U-Boot and which you can then use to assemble your device
tree from the base + overlays and then jump into efi boot code.

Or you could take the device tree from Linux (dtc -I fs -O dts
/proc/device-tree), add the bits you need and put the resulting file in
/boot/dtb/<$fdtname in U-Boot>.dtb.

To see the U-Boot variables, just abort the boot by pressing a key very
early and type "printenv".


Alex
-- 
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

[Alexander Graf]

On 09.10.17 16:37, Loic Devulder wrote:
> Hi guys!
> 
> I would like to test virtual machines on my rpi3 (just for fun of
> course! with the limited memory...).
> 
> I tried with a Leap 42.3 but I ran into some issue, mainly missing
> packages or not installed with the kvm_server pattern. So I had to add
> the "Virtualization" repo from OBS.
> 
> But even with it, I get the following error when I try to create a VM:
> Initialization of device arm_gic failed: KVM with user space irqchip
> only works when the host kernel supports KVM_CAP_ARM_USER_IRQ
> 
> I was able to execute a VM (YES!) after installing a 4.13 kernel from
> "Kernel Untested" repo.
> 
> 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 :).


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

Re: [opensuse-arm] RPi3 poor WiFi performance

[Alexander Graf]

> Am 07.10.2017 um 11:37 schrieb Alexander Bergmann :
> 
> Hi everyone,
> 
> I've just installed Leap 42.3 on my RPi3 last night and had some bad
> WiFi performance. The SSH connection was nearly unusable.
> 
> 21/21 packets, 0% loss, min/avg/ewma/max = 409.441/1454.630/1399.198/3025.166 
> ms
> 
> At the end simply switching off the power_save option did the trick to
> have a working connection again. Details got discussed here [1].
> 
> #> iw dev wlan0 set power_save off
> 
> The question is now, if we could disable power saving by default.

Wouldn‘t it make sense to do that in a distro agnostic fashion?

For example you could maybe provide a device tree property which disables the 
power saving mechanisms? Or just patch the upstream driver to detect the rpi3 
and do it automatically?


Alex

> There
> is already a patch [2] from the raspberrypi.org guys that is exactly
> doing that.
> 
> 
> Ciao,
> Alex~
> 
> [1] https://www.raspberrypi.org/forums/viewtopic.php?f=28=138312#p919552
> [2] 
> https://github.com/lede-project/source/blob/master/package/kernel/mac80211/patches/862-brcmfmac-Disable-power-management.patch
> -- 
> Alexander Bergmann , Security Engineer, GPG:9FFA4886
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

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

Re: [opensuse-arm] Upgrade of RPi3 to latest Tumbleweed shows a number of errors

[Alexander Graf]

> Am 04.10.2017 um 18:01 schrieb Freek de Kruijf <fr...@opensuse.org>:
> 
> Op woensdag 4 oktober 2017 12:47:35 CEST schreef Alexander Graf:
>> Can you try to allocate proper amounts of CMA memory with the cma=
>> kernel command line parameter?
> 
> In /boot/grub2/grub.cfg I see:
> 
> linux   /boot/Image-4.13.2-1-default root=UUID=d578a86e-c033-4290-8f9f-
> e9ddd2489659  root=/dev/disk/by-id/mmc-SD16G_
> 0xda58f009-part2 disk=/dev/disk/by-id/mmc-SD16G_0xda58f009 resume=/dev/disk/
> by-id/mmc-SD16G_0xda58f009-part3 quiet splash=silent ply
> mouth.enable=0  swiotlb=512,force cma=384M console=tty0 
> console=ttyS0,115200n8 
> quiet
> 
> Should swiotbl=512 be larger? cma=384M seems large enough.

Yeah, give that a try. swiotlb sizing is odd - it‘s in some multiple that I can 
never remember. 1k or so?

Alex

> 
> -- 
> fr.gr.
> 
> member openSUSE
> Freek de Kruijf
> 
> -- 
> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
> 

--
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 RPi3 to latest Tumbleweed shows a number of errors

[Alexander Graf]

On 03.10.17 23:52, Freek de Kruijf wrote:

I used the image:
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.09.09-Build3.11.raw.xz
to initialize the SD card.

After that, with some fiddling, I upgraded the system to Tumbleweed 20170920,
including the kernel to 4.13.2-1.

After the reboot I see the following error messages:
sep 14 18:32:58 rpi3tum kernel: kvm [1]: Invalid trigger for IRQ4, assuming
level low
sep 14 18:32:58 rpi3tum kernel: OF: /soc/usb@7e98: could not get #phy-
cells for /phy

and quite a lot of messages like:
okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is
full (sz: 221172 bytes)
okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: DMA: Out of SW-IOMMU
space for 221172 bytes
okt 03 23:42:29 rpi3tum kernel: mmcblk0: error -22 transferring data, sector
3465216, nr 1024, cmd response 0x900, card status 0xb00
okt 03 23:42:29 rpi3tum kernel: bcm2835-dma 3f007000.dma: swiotlb buffer is
full (sz: 221172 bytes)



Sounds like you're running out of swiotlb space during SD card DMA 
operations. I wonder what spills it? Maybe vc4?


Can you try to allocate proper amounts of CMA memory with the cma= 
kernel command line parameter? Or maybe blacklist the vc4 kernel module?



Alex

--
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 upgrade Leap 42.2 -> 42.3

[Alexander Graf]

On 13.09.17 09:31, Roger Oberholtzer wrote:

I have a functioning Leap 42.2 image for my Raspberry Pi 3. It is kept
up-to-date. I know that 42.2 will probably be around for a while. But
I am thinking of upgrading to 42.3. I would imagine one follows the
usual course of updating the repos and doing a zypper dup? On a copy
of the 42.2, of course. Any gottchas I might need to consider? Has
anyone else done this?


I would expect things to work. The only thing that might prevent 
functionality would be a U-Boot but in 42.2. I faintly remember 
something there, but I'm not sure whether we run into it with the 42.3 
kernel.


I'd say give zypper dup a try. If it doesn't boot afterwards, download 
the 42.3 image, extract the u-boot.bin binary from its FAT partition and 
copy that to your 42.2 FAT partition. Then you should be on the safe side.



Cheers,

Alex
--
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

[Alexander Graf]

On 10.09.17 17:14, Freek de Kruijf wrote:

Op zaterdag 9 september 2017 22:53:21 CEST schreef Freek de Kruijf:

Op zaterdag 9 september 2017 18:42:52 CEST schreef Freek de Kruijf:

Op dinsdag 5 september 2017 22:41:54 CEST schreef Freek de Kruijf:

Op dinsdag 5 september 2017 14:00:33 CEST schreef 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.


I repeated these steps, but now I only tried to update kernel-default
using
zypper which pulled in two other packages, wireless-regdb and crda.

There were no error messages. However a reboot did not succeed. The system
could not find an extX file system with a certain UUID.

So I put the SD card in my desktop and used fdisk to list the structure.
This structure is totally wrong. See below:

# fdisk -l /dev/sde
Disk /dev/sde: 3.7 GiB, 3991928832 bytes, 7796736 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FF922924-6706-4675-8AED-BB4E3FC84450

Device   Start End Sectors  Size Type
/dev/sde1 2048   67587   65540   32M EFI System
/dev/sde269632  509955  440324  215M Microsoft basic data
/dev/sde3   512000 6763365 62513663G Microsoft basic data
/dev/sde4  6764544 7796702 1032159  504M Microsoft basic data

Only the first partition sde1 can be mounted. the last one sde4 is a swap
partition.
The error message when mounting sde2 or sde3 is:
wrong fs type, bad option, bad superblock on /dev/sdeX, missing codepage
or
helper program, or other error.

Bug in dracut?


No. I did put the SD card in the RPi1 and waited till ssh access was
established. I did a shutdown of the system and put the SD card in my
desktop. The result is the same as above.

So it is the initialization of the SD card, creating the swap partition,
splitting up the BOOT partition of 250M in 32 EFI and a 215M other
partition, and enlarging the system partition, that goes wrong.


I initialized the SD card started it in the RPI1 entered with ssh and did the
command: fdisk -l /dev/mmcblk0 . The output follows:

# fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 3,7 GiB, 3991928832 bytes, 7796736 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FF922924-6706-4675-8AED-BB4E3FC84450

Device   Start End Sectors  Size Type
/dev/mmcblk0p12048   67587   65540   32M EFI System
/dev/mmcblk0p2   69632  509955  440324  215M Microsoft basic data
/dev/mmcblk0p3  512000 6763365 62513663G Microsoft basic data
/dev/mmcblk0p4 6764544 7796702 1032159  504M Microsoft basic data

Right after writing the SD card on my desktop it is:

# fdisk -l /dev/sde
Schijf /dev/sde: 3,7 GiB, 3991928832 bytes, 7796736 sectoren
Eenheid: sectoren van 1 * 512 = 512 bytes
Sectorgrootte (logisch/fysiek): 512 bytes / 512 bytes
In-/uitvoergrootte (minimaal/optimaal): 512 bytes / 512 bytes
Schijflabeltype: dos
Schijf-ID: 0xfa09d6bb

Apparaat   Op.  Begin   Einde Sectoren Grootte ID Type
/dev/sde12048  411651   409604200M  c W95 FAT32 (LBA)
/dev/sde2  413696 2680704  22670091,1G 83 Linux

The strange thing is that the Linux partition initially starts on 413696 and
none of the newly created partitions start on that location.


Well, sounds like something went wrong in the repartitioning step. I'm 
not quite sure what though - in the EFI case we should be quite safe:



https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/uboot-image-install.in?expand=1

So the only repartitioning happening *should be* the one coming from 
kiwi itself, plus conversion to MBR (see lines 87ff).


I guess you could try to dd a vanilla image onto an SD card, remove the 
kiwi hooks in /.kiwi-hooks and check the partition table layout after 
that. If it's sane, do the gdisk steps in the script manually and see 
what comes out of that.



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

Re: [opensuse-arm] Leap/Tumbleweed installation on RPi3

[Alexander Graf]

On 09/07/2017 01:54 PM, Loic Devulder wrote:

Hi guys!

Quick question before wasting my time by trying it: is it possible to
install Leap/Tumbleweed on a RPi3 using the ISO directly (like a
"normal" PC)?
By ISO I mean with PXE or USB key (as RPi3 can boot on USB).

Using the image is good but I would like to try a custom installation.



It's on the list of things we're trying to work towards, but it's not 
turn-key working today yet. In theory as long as you fetch U-Boot from 
PXE using the built-in PXE support on the system, you should be able to 
treat it like any other UEFI system which means installation *should* work.


Just give it a try :)


Alex


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

Re: [opensuse-arm] Overlay images for Raspberry Pi 3

[Alexander Graf]

On 06.09.17 09:36, Roger Oberholtzer wrote:

I am considering using the Raspberry Pi 3 in a project. My testing to
date has been with Leap 42.2. It has really worked well. I have a
couple of questions:

1. I would like to run openSUSE in such a way that the OS image is
read-only. All files that change are in RAM. I have built openSUSE
images like this (for standard PCs) using KIWI. Live openSUSE images
are also built this way. Has anyone done this for the PI 3? I know
that the boot starts out a bit different. Could that be a problem
here?


I'm not 100% sure if all internal kiwi logic handles things well, but in 
general booting, architectures and the read-only logic should be quite 
well separated.


I'd say just give it a try ;). A lot probably depends on the mode you're 
using. IIRC kiwi supported multiple different ways of doing read-only 
rootfs images.



2. If there is no technical reason against this (from the Pi 3 POV), I
would imagine my next step would be to copy the appropriate items in
OBS into my OBS project, and attempt changes there. Or is there a
better approach? What would be the projects to copy? I would prefer to
copy as little as possible so that I do not branch off somewhere. I
still want to run the released versions of things - except for the
kiwi change to get the overlay file system stuff set up.


You can just link your local JeOS-raspberrypi3.aarch64 against the JeOS 
package I guess and then modify it locally. Newer versions of the JeOS 
code use the multibuild feature, so if you link against it make sure to 
remove the _multibuild file - otherwise you'll end up building all 
available images in your local tree ;).



3. Is it possible to boot the PI 3 via PXE? My motivation would be
that the OS image need not be on the SD card. I have looked at
resources like 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md.
So I would think this should work - if I can make the previous items
work.


It is, but I haven't used that boot path yet. You'll have to somehow 
load grub via pxe, then pxe inside grub and do a "normal" uefi like pxe 
boot from there.



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

Re: [opensuse-arm] rock64

[Alexander Graf]

On 05.09.17 15:23, Matwey V. Kornilov wrote:

2017-09-05 16:12 GMT+03:00 Alexander Graf <ag...@suse.de>:



On 05.09.17 15:02, Matwey V. Kornilov wrote:


2017-09-05 16:00 GMT+03:00 Alexander Graf <ag...@suse.de>:



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 :).



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

Re: [opensuse-arm] rock64

[Alexander Graf]

On 05.09.17 15:02, Matwey V. Kornilov wrote:

2017-09-05 16:00 GMT+03:00 Alexander Graf <ag...@suse.de>:


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?


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.


Then do "nm vmlinux | grep log_buf" on the vmlinux file to the kernel 
you executed. You may have to extract it first, as it comes gzip'ed by 
default. In there you will find Linux virtual addresses for log_buf 
locations. IIRC __log_buf is the one you want. Remove the high 1-bits 
from that address, then add the RAM offset to it. That *should* 
hopefully be the offset into RAM for the dmesg buffer.


With that address, try to "md.b" its contents from the U-Boot command 
line. With a bit of luck you can spot something. If not we either had 
kASLR hit or didn't get as far as writing a dmesg buffer...



Alex
--
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

[Alexander Graf]

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


 /usr/sbin/grub2-install: error: cannot find a GRUB drive for /dev/
mmcblk0p2.  Check your device.map.
 

However /dev/mmcblk0p2 does exist as shows the following output of "df -h"
# df -h
Filesystem  Size  Used Avail Use% Mounted on
devtmpfs176M  8,0K  176M   1% /dev
tmpfs   201M 0  201M   0% /dev/shm
tmpfs   201M  372K  200M   1% /run
/dev/mmcblk0p2  3,0G  1,2G  1,7G  41% /
/dev/mmcblk0p1  200M  3,7M  197M   2% /boot/efi
tmpfs   201M 0  201M   0% /sys/fs/cgroup
tmpfs41M 0   41M   0% /run/user/0

File a bug report?


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

Re: [opensuse-arm] ARM-EFI: Where is the device-tree?

[Alexander Graf]

> Am 09.08.2017 um 12:45 schrieb Frank Kunz :
> 
> Hello,
> 
> I'm trying to get the USB-OTG interface working on the DE0-nano-SoC
> (socfpga) board by using openSUSE tumbleweed. The image uses ARM-EFI
> boot and there is no dtb file on the boot partition. When Linux is
> running the device-tree is visible on /proc/device-tree and
> /sys/firmware, so there is a device-tree. But there is no dtb file which
> I can change for debug purpose. So how to modify the device-tree with
> ARM-EFI boot?

Not sure about that particular board, but U-Boot uses the dt in /boot/dtb and 
then falls back to the built-in tree in U-Boot ($controlfdt).

If it does use the fallback (which is the right way to do it), just do dtc -I 
fs -O dts /proc/device-tree and save it to the location the boot script looks 
for (check $bootcmd in U-Boot).

Alex

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

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

[Alexander Graf]

On 24.07.17 20:49, Oscar C wrote:

Hi,

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.


I found a link in the wiki to a script which is supposed to help with 
this (http://users.suse.com/~dmueller/contrib_kernel.sh) but like is 
dead to me.


Hm, looks like users.suse.com does not want to talk to anyone outside of 
the SUSE network. Hooray.


Either way, here's the script. You may need to adapt it a bit, as it's 
been a while since I last used it. But overall it should still do what 
you expect.


Alex

---

#!/bin/bash
#
# Script to create an openSUSE Contrib kernel from downstream sources.
#
# Please use with care. No warranty granted if anything goes wrong. This
# file is public domain and free for everyone to use, distribute and modify.
#
# Author: Alexander Graf <ag...@suse.de>
#


KERNEL_FLAVOR="$1"
KERNEL_ARCH="$2"
KERNEL_ARCHIVE="$3"
KERNEL_CONFIG="$4"
OBS_PRJ="$5"

# Sanity check command line
if [ ! "$1" -o ! "$2" -o ! "$3" -o ! "$4" -o ! "$5" ]; then
echo "Syntax: $0config> 


Example: $0 midway armv7hl linux-midway-3.16.tar.xz linux-midway.config 
home:algraf:ARM:Factory:Contrib:Midway


Available architectures:

  armv6hl
  armv7hl
  arm64
"

exit 1
fi

# Sanity check kernel
KERNEL_TAR_VERSION=$( tar tf "$KERNEL_ARCHIVE" | head -n1 )
if [ "${KERNEL_TAR_VERSION:0:6}" != "linux-" ]; then
echo "ERROR: Invalid tar archive

Please provide a tar archive that contains the Linux tree inside
of a directory named as

  linux-version

such as

  linux-3.16-rc1"

exit 1
fi

# Derive kernel version from tarball

KERNEL_VERSION="${KERNEL_TAR_VERSION:6}"
KERNEL_VERSION="$(basename $KERNEL_VERSION)"

# Sanity check arch

case $KERNEL_ARCH in
  armv6hl|armv7hl|arm64)
;;
  *)
echo "ERROR! Invalid architecture.

Available architectures:

  armv6hl
  armv7hl
  arm64
"
exit 1
;;
esac

###

if [ ! "$KERNEL_SOURCE_GIT" ]; then
KERNEL_SOURCE_GIT=git://kernel.opensuse.org/kernel-source.git
DEFAULT_KERNEL_SOURCE_GIT=1
fi

echo "Welcome to the openSUSE Contrib kernel creator.

We will now create a kernel-source package and a kernel-$KERNEL_FLAVOR 
package.

We will also add these two packages to your $OBS_PRJ repository.

The first thing I will do is to fetch the openSUSE kernel-source.git from

  $KERNEL_SOURCE_GIT
"

if [ "$DEFAULT_KERNEL_SOURCE_GIT" ]; then
echo "If this takes too long for your taste, please keep a local 
copy of the

*most recent* kernel-source.git around and put its location into the
KERNEL_SOURCE_GIT environemnt variable.
"
fi


SRC=/dev/shm/kernel-source.$$

git clone $KERNEL_SOURCE_GIT $SRC
cp "$KERNEL_ARCHIVE" "$SRC/linux-${KERNEL_VERSION}.tar.xz"
cp "$KERNEL_CONFIG" "$SRC/config/armv6hl/$KERNEL_FLAVOR"
cp "$KERNEL_CONFIG" "$SRC/config/armv7hl/$KERNEL_FLAVOR"
cp "$KERNEL_CONFIG" "$SRC/config/arm64/$KERNEL_FLAVOR"

(
  cd $SRC
  echo patches.rpmify/firmware-path > series.conf
  echo "
+armv6hlarmv6hl/$KERNEL_FLAVOR
+armv7hlarmv7hl/$KERNEL_FLAVOR
+arm64  arm64/$KERNEL_FLAVOR
" > config.conf
  sed -i "s/^SRCVERSION=.*$/SRCVERSION=$KERNEL_VERSION/" rpm/config.sh
  ./scripts/sequence-patch.sh
  (
cd tmp/linux-$KERNEL_VERSION-master/
./run_oldconfig.sh --flavor $KERNEL_FLAVOR -a $KERNEL_ARCH
  )
  ./scripts/tar-up.sh
)

echo "We finished assembling a kernel-source package. You can find it at

  $SRC/kernel-source.

The next step is to upload this to OBS.
"

osc rdelete -m x $OBS_PRJ kernel-source
osc rdelete -m x $OBS_PRJ kernel-$KERNEL_FLAVOR

osc meta pkg $OBS_PRJ kernel-source -F - << EOF
 
   kernel-source
   
   
 
EOF

OSCDIR=/dev/shm/$$
mkdir $OSCDIR
(
  cd $OSCDIR
  osc co $OBS_PRJ kernel-source
  cd $OBS_PRJ/kernel-source
  cp $SRC/kernel-source/* .
  osc addremove
  osc ci -m "Add kernel sources"
)
osc linkpac -C copy $OBS_PRJ kernel-source $OBS_PRJ kernel-$KERNEL_FLAVOR

# Cleaning up
rm -rf $OSCDIR
rm -rf $SRC

echo "

Congratulations. You have now a working contrib kernel in 
$OBS_PRJ/kernel-$KERNEL_FLAVOR!


Have a lot of fun."
--
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 Zero boot broken after update

[Alexander Graf]

> Am 23.07.2017 um 03:20 schrieb 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

Data abort does not sound like an illegal instruction - hmm

> pc : [<18b36628>]  lr : [<18b4e178>]
> reloc pc : []lr : []

If I had to guess I'd say this is within the grub binary.

Alex

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

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

Re: [opensuse-arm] tumbleweed updates for armv6hl ?

[Alexander Graf]

On 17.07.17 16:26, Marcus Gould wrote:

Hi,

(Please note that I've joined this mailinglist since this thread started)


  Re: [opensuse-arm] tumbleweed updates for armv6hl ?
  

  * From: Michael Ströder 
  * Date: Thu, 13 Jul 2017 11:51:56 +0200
  * Message-id: <74530af2-0e5e-6dd0-090e-80984ec86...@stroeder.com
>

Dirk Müller wrote:

Unfortunately armv6hl is in a pretty bad state because it is still
built in qemu emulation, and noone maintains that emulation layer.
[..]
Over the long run we need to find a different solution though (which
could be dropping it alltogether, in the worst case). For now I take
it as a positive sign that someone does actually care about it being
available :-)


Hmm, I have several rpi1 boards and it would be nice if they do not
turn into
Elektroschrott. The video output does not work but I use them
headless anyway.

Until two weeks ago zypper dup worked but currently the update is
stuck with
this message:

Problem: libzypp-16.9.0-1.1.armv6hl requires libsolv-tools = 0.6.27,
but this
requirement
cannot be provided
deleted providers: libsolv-tools-0.6.27-2.1.armv6hl
Solution 1: Following actions will be done:
deinstallation of libzypp-16.9.0-1.1.armv6hl
deinstallation of zypper-1.13.25-1.1.armv6hl
Solution 2: keep obsolete libsolv-tools-0.6.27-2.1.armv6hl
Solution 3: break libzypp-16.9.0-1.1.armv6hl by ignoring some of its
dependencies

I'd like to register myself as a RaspPi+armv6hl user who cares about the 
repo being available :-) and mention that I am also seeing similar sorts 
of issues:


# *zypper dup --no-allow-vendor-change -d*
Warning: You are about to do a distribution upgrade with all enabled
repositories. Make sure these repositories are compatible before you
continue. See 'man zypper' for more information about this command.
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
36 Problems:
Problem: nothing provides zypper(auto-agree-with-product-licenses)
needed by SUSEConnect-0.3.2-1.1.armv6hl
Problem: libzypp-16.9.0-1.1.armv6hl requires libsolv-tools = 0.6.27,
but this requirement cannot be provided
Problem: yast2-perl-bindings-3.2.0-1.1.armv6hl requires perl =
5.24.0, but this requirement cannot be provided
Problem: yast2-core-3.2.2-1.1.armv6hl requires perl = 5.24.0, but
this requirement cannot be provided
Problem: vim-8.0.566-2.1.armv6hl requires perl = 5.24.0, but this
requirement cannot be provided
Problem: yast2-perl-bindings-3.2.0-1.1.armv6hl requires perl =
5.24.0, but this requirement cannot be provided
 [3 More]
Problem: yast2-core-3.2.2-1.1.armv6hl requires perl = 5.24.0, but
this requirement cannot be provided
 [11 More]
Problem: yast2-perl-bindings-3.2.0-1.1.armv6hl requires perl =
5.24.0, but this requirement cannot be provided
 [13 More]
Problem: yast2-core-3.2.2-1.1.armv6hl requires perl = 5.24.0, but
this requirement cannot be provided

Problem: nothing provides zypper(auto-agree-with-product-licenses)
needed by SUSEConnect-0.3.2-1.1.armv6hl
  Solution 1: keep obsolete SUSEConnect-0.3.0-1.1.armv6hl
  Solution 2: break SUSEConnect-0.3.2-1.1.armv6hl by ignoring some
of its dependencies

Choose from above solutions by number or skip, retry or cancel
[1/2/s/r/c] (c):

If I sit tight and wait, will this get fixed in some future maintenance?


Dirk and Andreas are currently working to fix up all builds. We're in 
the process to switch compilation over to native builds (previously it 
was all emulated with bitrotting emulation).


As always, helping hands are always welcome. If you see build failures 
for armv6 here:


  https://build.opensuse.org/project/show/openSUSE:Factory:ARM

and you have the time to google for failures and create OBS 
submitrequests to fix them, that would be great and helps to keep the 
target alive :).



Thanks,

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

Re: [opensuse-arm] Custom Raspberry PI3 kernel modules

[Alexander Graf]

On 26.06.17 08:14, Roger Oberholtzer wrote:

On Thu, Jun 22, 2017 at 12:24 PM, Matthias Brugger  wrote:

Hi Roger,

On 22/06/17 10:38, Roger Oberholtzer wrote:


I am looking at making a custom Raspberry PI3 kernel module that needs
to deal with the various I/O pins. I need a driver because the
activity is quite high. So a python or other high-level interface will
not be possible. It will most likely do the majority of work in the
driver's interrupt routine that, I hope, can be called when a pin or
pins change state.

My questions are:
   1. Has anyone experienced any difficulties with making custom drivers
on openSUSE running on the Pi3?
   2. Are there any drivers that are being loaded by openSUSE that
fiddle with the I/O lines that I may need to disable? Currently,
nothing is connected to the I/O lines.



Which pins are we talking about?


That's flexible. We can connect to any pins that are best suited.


Which interface do you want to use (SPI, I2C etc)?


It is not a standard interface. Just a trigger pin. But it can trigger
up to 32 kHz. And we need to react to each of them. We would like to


So what does the interface look like exactly? How many lines do you 
have? How is the data encoded? Where is the latch and how long is it?


The best case for devices like the RPi is to reuse existing IP blocks 
for the low level bit banging of wires. Some times a different protocol 
happens to match the low level protocol well enough to allow you to 
reuse it and offload things from the CPU.



try to stay away from commonly used lines so we could possibly also
attach a device that uses such a protocol. But that is a secondary
concern.


Which sensor do you want to connect?


It is a device that provides pulses related to movement. We monitor
these and take action on them. Some actions are the manipulation of


So the duration of the pulse is the bit that provides information? On 
both edges? And max freq is 32khz?


In that case, check out this stackexchange discussion:


https://raspberrypi.stackexchange.com/questions/9787/pwm-input-in-raspberry-pi

The main problem is that with PWM while your edges are only 32khz apart, 
you need to oversample quite a bit to know where they are :).



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

Re: [opensuse-arm] CPU1: failed to come online

[Alexander Graf]

On 21.06.17 11:56, Matwey V. Kornilov wrote:

2017-06-21 12:53 GMT+03:00 Alexander Graf <ag...@suse.de>:

Hi Matwey,

The QEMU code in 42.2 has a bug on rpi3 which prohibits it from running SMP
guests. Can you please try to use the 42.3 kernel and QEMU? The following
patch did make SMP work for me:


https://github.com/openSUSE/qemu/commit/3227a2bdc7a494194a6a4f7d5653ff178ecb1b2f



Isn't it in 42.2?

https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/qemu/0071-ARM-KVM-Enable-in-kernel-timers-wit.patch?expand=1


It is, but that's an older version of the patch. There we're missing the 
iothread lock, so internal state gets corrupted.


Also IIRC there were some kernel side fixes for SMP support.


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

Re: [opensuse-arm] CPU1: failed to come online

[Alexander Graf]

Hi Matwey,

The QEMU code in 42.2 has a bug on rpi3 which prohibits it from running 
SMP guests. Can you please try to use the 42.3 kernel and QEMU? The 
following patch did make SMP work for me:



https://github.com/openSUSE/qemu/commit/3227a2bdc7a494194a6a4f7d5653ff178ecb1b2f

and that one is in 42.3.


Alex

On 21.06.17 11:43, Matwey V. Kornilov wrote:


Hello,

I am running Leap 42.2 on Raspberry Pi 3 and trying to user qemu-kvm for 
OBS worker. Currently, I can not run guests with more that single CPU.


Both using libvirt and using obsworker, I see 'CPU1: failed to come 
online'.


[   28s] booting kvm...
[   28s] ### VM INTERACTION START ###
[   28s] /usr/bin/qemu-system-aarch64 -nodefaults -no-reboot -nographic 
-vga none -enable-kvm -cpu host,aarch64=off -M virt,gic-version=host 
-object rng-random,filename=/dev/hwrng,id=rng0 -device 
virtio-rng-device,rng=rng0 -runas qemu -net none -M virt,gic-version=2 
-kernel /var/cache/obs/worker/root_1/.mount/boot/kernel -initrd 
/var/cache/obs/worker/root_1/.mount/boot/initrd -append 
root=/dev/disk/by-id/virtio-0 rootfstype=ext3 
rootflags=data=writeback,nobarrier,commit=150,noatime panic=1 quiet 
no-kvmclock nmi_watchdog=0 rw rd.driver.pre=binfmt_misc elevator=noop 
console=ttyAMA0 init=/.build/build -m 768 -drive 
file=/var/cache/obs/worker/root_1/root,format=raw,if=none,id=disk,serial=0,cache=unsafe 
-device virtio-blk-device,drive=disk -drive 
file=/var/cache/obs/worker/root_1/swap,format=raw,if=none,id=swap,serial=1,cache=unsafe 
-device virtio-blk-device,drive=swap -serial stdio -smp 2

[   31s] [1.147658] CPU1: failed to come online
[   32s] [1.174458] socfpga_setup_ocram_self_refresh: Unable to find 
mmio-sram in dtb

[   34s] [4.059330] sr_init: platform driver register failed for SR
[   34s] [4.060566] Unable to find PPMU node
[   36s] [5.512390] dracut-pre-udev[161]: modprobe: FATAL: Module 
kqemu not found.
[   37s] [7.285749] dracut-pre-udev[161]: modprobe: FATAL: Module 
virtio_pci not found.
[   38s] [7.453945] dracut-pre-udev[161]: modprobe: FATAL: Module 
ibmvscsi not found.
[   38s] [7.483033] dracut-pre-udev[161]: modprobe: FATAL: Module 
e1000 not found.
[   38s] [7.498808] dracut-pre-udev[161]: modprobe: FATAL: Module 
ibmveth not found.

[   41s] ### VM INTERACTION END ###
[   41s] 2nd stage started in virtual machine


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

[Alexander Graf]

Raspbian runs Linux straight away which then adapts to the respective 
target board. U-Boot however does not; it statically compiles in which 
target serial port to use.


I agree that this should probably be fixed :). Patches are more than 
welcome!



Alex

On 12.04.17 10:23, Matwey V. Kornilov wrote:


Now it is clear, thank you. I though that the same raspbian image fitted
all RPI versions so JeOS did also.


12.04.2017 11:12, Alexander Graf пишет:

Hi,

I don't think it would work, as the serial port is behind a different
IP block.

Alex


Am 12.04.2017 um 09:17 schrieb Matwey V. Kornilov
<matwey.korni...@gmail.com>:

Hello,

Could somebody please tell me whether raspberrypi2 image supposed to
work on raspberrypi3 in armv7 mode?

I've just tried but I don't see anything on serial console, even
u-boot messages. Is it the image broken? I don't have raspberrypi2 to
test.

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







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

Re: [opensuse-arm] JeOS-2017-03-13 image for RPi 1 installs OK, Grub fails on reboot

[Alexander Graf]

On 27/03/2017 23:27, Alexander Graf wrote:



On 27/03/2017 23:15, Alex Armstrong wrote:

Alexander Graf wrote:

Hi Alex,

On 23/03/2017 20:48, Alex Armstrong wrote:

Greetings,

I was testing:
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2017.03.13-Build1.8.raw.xz



from:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi/images/


In fact, is there any particular reason you're using the downstream 
kernel image?


Do you get the same breakage with the upstream based one from here?

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


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

Re: [opensuse-arm] JeOS-2017-03-13 image for RPi 1 installs OK, Grub fails on reboot

[Alexander Graf]

On 27/03/2017 23:15, Alex Armstrong wrote:

Alexander Graf wrote:

Hi Alex,

On 23/03/2017 20:48, Alex Armstrong wrote:

Greetings,

I was testing:
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2017.03.13-Build1.8.raw.xz


from:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi/images/


On RaspberryPi 1 Model B
It installs fine - expands the file system, creates the dracut based
init and boots to a usable system.  But when I reboot, grub fails with:
error: attempt to read or write outside of partition.


This sounds like the repartitioning failed.


and drops me to the grub rescue system.
Poking around the rescue system, I've found that I can see 4 partitions,
one which is ext2 and has the normal Linux files.  From here, most of


Can you also see the size? IIRC you see partition information with

  (grub) ls (hd0)

No, using ls (hd0,gpt*), for all but the second partition grub returns:
Filesystem is unknown.

For the second partition, grub tells me that it is ext2, but no other
details.

the recovery guides say to set the root and prefix variables and then
load the normal module.  I can execute the commands:
set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub2

and list the files in the various directories - normal.mod exists in
/boot/grub2/arm-efi/ - but when I try:
insmod normal

I still get the error: attempt to read or write outside of partition.
Somewhat interestingly, if I miss-type the prefix (say; /boot/grub) the
error changes to a "file not found" one.

I was hoping someone might have some ideas about what to try next.


One thing you could try is check on a working system what the
partition table and file system look like. It almost sounds like the
ext4 partition got resized, but the partition table is still on the
old, small size.


Alex

Thanks for mentioning that, I took a look at the SD card with parted
and here's what I found:

Model: Generic- Multi-Card (scsi)
Disk /dev/sdb: 7948MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt_sync_mbr

Number  Start   End SizeFile system NameFlags
 1  1049kB  211MB   210MB   fat16   UEFIboot
 2  212MB   430MB   218MB   ext4lxboot
 3  431MB   7427MB  6996MB  lxroot
 4  7428MB  7948MB  520MB   linux-swap(v1)  lxswap

I think you're right - the resizing didn't work as expected.  I saw
the success message in the log and didn't think to check it further.


The partition table looks pretty sane to me. You have an 8GB disk and / 
is properly expanded to 7GB.



Additionally when I try to mount partition 2, it fails with this message:
EXT4-fs (sdb2): bad geometry: block count 1761625 exceeds size of
device (53248 blocks)


Ok, so something really is broken there ;). Good.

It looks like your block size is 4kb (default size for ext4 IIRC). 53248 
blocks translate to 218MB (with 1000 bytes as kbyte) while 1761625 
blocks would be 7215MB.


If I had to guess, I'd say someone dropped the requirement for a 
separate boot partition but forgot to update the partitioning script in 
the JeOS package.


If I'm right, /dev/sdb3 should not contain a valid file system.

In that case, can you manually try to fix it up for now? Remove 
partitions 2 and 3. Then create a new partition from beginning of 
current partition 2 until end of partition 3. Switch to unit type sector 
(unit s I think in parted) to make sure they really are aligned.


Then try to mount that new partition. Does it work? If so, does it boot?


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

Re: [opensuse-arm] JeOS-2017-03-13 image for RPi 1 installs OK, Grub fails on reboot

[Alexander Graf]

Hi Alex,

On 23/03/2017 20:48, Alex Armstrong wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

I was testing:
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2017.03.13-Build1.8.raw.xz

from:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi/images/

On RaspberryPi 1 Model B
It installs fine - expands the file system, creates the dracut based
init and boots to a usable system.  But when I reboot, grub fails with:
error: attempt to read or write outside of partition.


This sounds like the repartitioning failed.


and drops me to the grub rescue system.
Poking around the rescue system, I've found that I can see 4 partitions,
one which is ext2 and has the normal Linux files.  From here, most of


Can you also see the size? IIRC you see partition information with

  (grub) ls (hd0)


the recovery guides say to set the root and prefix variables and then
load the normal module.  I can execute the commands:
set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub2

and list the files in the various directories - normal.mod exists in
/boot/grub2/arm-efi/ - but when I try:
insmod normal

I still get the error: attempt to read or write outside of partition.
Somewhat interestingly, if I miss-type the prefix (say; /boot/grub) the
error changes to a "file not found" one.

I was hoping someone might have some ideas about what to try next.


One thing you could try is check on a working system what the partition 
table and file system look like. It almost sounds like the ext4 
partition got resized, but the partition table is still on the old, 
small size.



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

Re: [opensuse-arm] Re: RPi3 no wlan0 after mkinitrd

[Alexander Graf]

> Am 17.02.2017 um 12:22 schrieb Freek de Kruijf :
> 
> Op donderdag 16 februari 2017 21:13:58 CET schreef Alexander Bergmann:
>> Hi Malcolm!
>> 
>>> On Wed, Feb 15, 2017 at 06:35:07PM -0600, Malcolm wrote:
 On Wed 15 Feb 2017 06:21:25 PM CST, Malcolm wrote:
> On Thu 16 Feb 2017 12:19:15 AM CST, Alexander Bergmann wrote:
> After a simple mkinitrd the module cannot be loaded anymore.
> 
>> brcmfmac_sdio: probe of mmc1:0001:1 failed with error -110
>> brcmfmac_sdio: probe of mmc1:0001:2 failed with error -110
 
 Hi
 I just followed the steps in the following archive message on a Leap
 42.2 JeOS install (except I just used mkinitrd)
 https://lists.opensuse.org/opensuse-arm/2016-11/msg00018.html
 
 Wireless is up.
> 
>> 
>> The change of /etc/dracut.conf.d/raspberrypi_modules.conf did the trick!
>> 
>> -add_drivers+=" sdhci-iproc bcm2835-sdhost bcm2835_dma mmc_block "
>> +add_drivers+=" bcm2835-sdhost bcm2835_dma mmc_block "
>> 
>> Thanks for pointing in the right direction...
>> 
>> Alex~
> 
> My Tumbleweed version on RPi3 still does not have a wlan0. I tried the above, 
> but bcm2835-sdhost is not available on my system. The current kernel is 
> 4.9.6-1-default.

Yes, the driver for the second sd controller isn't in 4.9 yet :). It is in the 
leap kernel though.


Alex


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

Re: [opensuse-arm] "installing" openSuSE on raspberry pi2 using nfsroot

[Alexander Graf]

On 28/01/2017 10:55, Paul Neuwirth wrote:

Hello group,
as I am really unlucky with sd cards, every one has bad sectors, data
are partly not fully written without notice...
... I want to try to install openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2
image using a nfsroot.
anyone who tried this?


I haven't but it should be reasonably straight forward.



my idea was first to install to an sdcard (hope this will work) then try
to build a initrd with network/nfs support (or does the original already
have?) modify boot params to use nfsroot (and of course put the rootfs
on an nfs share).


Basically that should work. To generate a working initrd, just do it 
within the nfsroot chroot:


  $ mount  /nfs
  $ for i in dev dev/pts sys proc; do mount --bind /$i /nfs/$i; done
  $ chroot /nfs
  $ mkinitrd

That way dracut has the chance to detect that your rootfs (/, which is 
really /nfs) is located on NFS and include network as well as NFS support.


The resulting initrd obviously resides on your NFS share then though ;).


even better would be a pxe-bootloader.. googling around i did not find
such for arm/raspberry pi.. any hints?


There is full PXE support on the Raspberry Pi 3:


https://www.raspberrypi.org/blog/pi-3-booting-part-ii-ethernet-all-the-awesome/

But even with a normal SD based boot, U-Boot already has everything it 
needs to make PXE boot work. Try:


  U-Boot# setenv boot_targets dhcp
  U-Boot# boot

that should try to load grub2 from dhcp rather than SD card. If you want 
to make this permanent, just remove your bootarm.efi binary on the ESP 
(/dev/mmcblk0p1).


Once you're in grub2, you can access file paths relative to the PXE 
loading location IIRC.



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

Re: [opensuse-arm] openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.01.13-Build4.1.raw booting from usb-hdd/thumb drive without SD-Card

[Alexander Graf]

On 25/01/2017 21:55, Alexander Graf wrote:



On 25/01/2017 21:16, Freigeist wrote:

On 25/01/17 19:29, Alexander Graf wrote:



On 25/01/2017 19:20, Freigeist wrote:


"A start job is running for dev-sda2.device (xys/no limit)"


I fixed that one last weekend :). The usb driver wasn't included in the
initrd:


https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base=517





Alex, thanks for your reply. I forgot to mention that I already rebuilt
the initrd with all usb modules listed by lsmod by placing them in
/etc/dracut.conf.d/raspberrypi_modules.conf and it doesn't work.
Even building a monster initrd with mkinitrd -A didn#t work.

Or are you talking about something else here?


No, that's basically what I'm talking about. I'm surprised, as it did
work for me :).


If so, where - in which image-repo or aarch64/oss-repo - can I find an
image with your fix or a fixed package and how is it called?


It's built inside OBS, but not published because we have failing OpenQA
tests right now.

The easiest way to fetch the current image is to run the following command:

  $ osc getbinaries openSUSE:Factory:ARM JeOS:JeOS-raspberrypi3.aarch64
images aarch64

I do have to admit that I didn't verify the end resulting image. I
changed it locally on a Leap based image and then transferred the change
into the Tumbleweed image description. I also booted straight from USB,
so the first boot step was already running on USB.


Actually now that you mention it, there were some hickups with missing 
persistent device names that I didn't look into further.


As workaround, try to explicitly say root=/dev/sda2 (or whatever the 
partition is) on your kernel command line from grub and modify 
/etc/fstab to only reference /dev/sdX. names as well.



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

Re: [opensuse-arm] openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.01.13-Build4.1.raw booting from usb-hdd/thumb drive without SD-Card

[Alexander Graf]

On 25/01/2017 21:16, Freigeist wrote:

On 25/01/17 19:29, Alexander Graf wrote:



On 25/01/2017 19:20, Freigeist wrote:


"A start job is running for dev-sda2.device (xys/no limit)"


I fixed that one last weekend :). The usb driver wasn't included in the
initrd:


https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base=517




Alex, thanks for your reply. I forgot to mention that I already rebuilt
the initrd with all usb modules listed by lsmod by placing them in
/etc/dracut.conf.d/raspberrypi_modules.conf and it doesn't work.
Even building a monster initrd with mkinitrd -A didn#t work.

Or are you talking about something else here?


No, that's basically what I'm talking about. I'm surprised, as it did 
work for me :).



If so, where - in which image-repo or aarch64/oss-repo - can I find an
image with your fix or a fixed package and how is it called?


It's built inside OBS, but not published because we have failing OpenQA 
tests right now.


The easiest way to fetch the current image is to run the following command:

  $ osc getbinaries openSUSE:Factory:ARM JeOS:JeOS-raspberrypi3.aarch64 
images aarch64


I do have to admit that I didn't verify the end resulting image. I 
changed it locally on a Leap based image and then transferred the change 
into the Tumbleweed image description. I also booted straight from USB, 
so the first boot step was already running on USB.



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

Re: [opensuse-arm] openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.01.13-Build4.1.raw booting from usb-hdd/thumb drive without SD-Card

[Alexander Graf]

On 25/01/2017 19:20, Freigeist wrote:

Hello All,

let me first thank all those of you who made the above mentioned image
possible. To me, it is the first image since at least October 2016 that
ist booting on my rpi3 without any problems. The only thing not working
is wifi. But that was to be expected (as it sports kernel 4.9), as
Andreas Färber already said on this list.

So, Thank you and keep up the good work.

As most of you may already know it is possible to boot an rpi3 without
SD-Card from usb (hdd or thumb drive) directly since August 2016,
following the instructions given in the link below:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md


I tried that and it works without problems using Raspbian on both, an
hdd and a thumb drive.

Since my rpi3 is now unlocked and able to boot from usb I tried to make
it boot with openSUSE using the image in the subject and copying
bootcode.bin und start.elf from here

https://github.com/raspberrypi/firmware/tree/next/boot

to /dev/sda1/efi on my usb-hdd and - alternatively - to my usb thumb
drive, replacing the original files on it.

To make a long story short: It works! ...sort of (more about that
later). It is possible to boot openSUSE-aarch64 on an rpi3 without
SD-card directly from usb.

And now we come to the "sort of" part of the boot process.

- Grub2 appears and loads the kernel and initrd
- all kinds of boot messages appear about services that were started and
targets that were reached.

But then the system hangs indefinitely with the following line:

"A start job is running for dev-sda2.device (xys/no limit)"


I fixed that one last weekend :). The usb driver wasn't included in the 
initrd:



https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base=517


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

Re: [opensuse-arm] Watchdog trigger during first boot

[Alexander Graf]

> Am 24.01.2017 um 19:49 schrieb Frank Kunz :
> 
>> Am 24.01.2017 um 18:29 schrieb Andreas Färber:
>> Hi,
>> 
>>> Am 24.01.2017 um 17:30 schrieb Frank Kunz:
>>> But the watchdog triggers anyway during the system partition rewrite. So
>>> nothing pings the watchdog during that operation. I think there is still
>>> a service missing that pings the watchdog.
>> 
>> See https://en.opensuse.org/HCL:Turris_Omnia for an example solution.
>> I used /etc/init.d/boot.local for quick local testing.
>> 
> 
> I will try that first, but it needs util-linux which brings beside wdctl
> a lot of other things.

I would assume we already have that inside the kiwi initrd. Kiwi also executes 
hook scripts that we already populate (for SPL flashing, GPT wiggling, etc). 
Inside those you could just kick the watchdog once.

When you do that, please don't check for the board but rather the existence of 
/dev/watchdog. That way we also have it (hopefully) fixed for other systems 
that use watchdogs.

Alex


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

Re: [opensuse-arm] Adding new board: No boot device

[Alexander Graf]

> Am 10.01.2017 um 22:08 schrieb Frank Kunz <mailingli...@kunz-im-inter.net>:
> 
>> Am 10.01.2017 um 13:13 schrieb Alexander Graf:
>>> On 01/10/2017 12:51 PM, Andreas Färber wrote:
>>>> Am 10.01.2017 um 00:04 schrieb Alexander Graf:
>>>>> On 09/01/2017 21:20, Frank Kunz wrote:
>>>>> Am 08.01.2017 um 22:29 schrieb Alexander Graf:
>>>>>>>> For the gfx command line you may want to add a second console=tty
>>>>>>>> or so?
>>>>>>> That did not help so far so solve my login problem. In the mean
>>>>>>> time I
>>>>>>> started to modify the initrd that the /boot/mbrid file does not
>>>>>>> match.
>>>>>>> But no idea yet what could be wrong. I haven't found out where it is
>>>>>>> set
>>>>>>> during the image build process, how to debug that?
>>>>>> The mbrid file gets generated by kiwi when it writes the MBR ID
>>>>>> field in
>>>>>> the MBR of the target device. So they really should be in sync. If
>>>>>> they
>>>>>> are not, something goes wrong in the u-boot-install/setup scripts.
>>>>>> 
>>>>>> Also, have you verified that the target device is actually visible
>>>>>> from
>>>>>> within the kiwi initrd? Maybe the module is missing?
>>>>> I modified the initrd init/include scripts to print the device names
>>>>> that were used for the search run, and the mmcblk0 is there, and some
>>>>> value is read out. So the driver seems to be ok. The value read from
>>>>> /boot/mbrid is a different value.
>>>> That sounds to me like something is messing with the MBR after it got
>>>> created.
>>> He's calling parted in uboot-image-install.in:
>>> 
>>> https://build.opensuse.org/package/rdiff/home:frank_kunz:branches:openSUSE:Factory:ARM/JeOS?opackage=JeOS=openSUSE%3AFactory%3AARM=19
>>> 
>>> 
>>> (Any reason for that placement of the hunk instead of adding in the
>>> bottom?)
>>> 
>>> You may need to save and restore mbrid as done some lines up.
>> 
>> Ah, that explains the missing mbrid, yes :).
>> 
>> I see two potential options according to the boot documentation:
>> 
>> https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an709.pdf
>> 
>> 
>> 1) Use raw offset
>> 
>> According to the documentation you can not use a partition table when
>> using the raw format. Maybe you can trick around with abusing the first
>> 440 bytes for the boot loader and leave the actual partition table and
>> MBRID intact:
>> 
>>  https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
>> 
>> Maybe there's some way to use Preloader 1 instead of 0?
> 
> Good idea. It is possible. The rom loader first checks for a partition
> 0xa2. From there it tries to load the spl, where there is one and three
> backups. If that fails it tries to load in raw mode from sector 0 and
> does the same. If the loading and crc check of spl from offset 0 fails,
> it automatically continues at sector offset 0x80 with the first backup
> spl. So when copy the spl+uboot image to the disk by
> 
> dd if=u-boot-with-spl.sfp of=/dev/sdX bs=64k skip=1 seek=1
> 
> the rom loader loads the spl from preloader 1 location in raw mode and
> starts it. But the spl has a bug to load the attached uboot from the
> location 0x200 then. So I need to prepare some upstream patches for
> uboot to get that fixed and enabled in the defconfig (let us see if it
> will be accepted). Anyway the environment does not have the distro_boot
> variables in place, so I will upstream that as well.
> 
> By that no special partition is needed anymore then, but the "hole"
> between partition table and first partition needs to be big enough to
> store the spl images and the uboot (approx. 700kiB).

That is always the case, as parted aligns partitions to at least MB boundaries.

Please double-check where the GPT contains values and that none of them are 
beyond 64kb. You will want to make this GPT future proof ;)


Alex

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

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

Re: [opensuse-arm] Adding new board: No boot device

[Alexander Graf]

On 01/10/2017 12:51 PM, Andreas Färber wrote:

Am 10.01.2017 um 00:04 schrieb Alexander Graf:

On 09/01/2017 21:20, Frank Kunz wrote:

Am 08.01.2017 um 22:29 schrieb Alexander Graf:

For the gfx command line you may want to add a second console=tty
or so?

That did not help so far so solve my login problem. In the mean time I
started to modify the initrd that the /boot/mbrid file does not match.
But no idea yet what could be wrong. I haven't found out where it is
set
during the image build process, how to debug that?

The mbrid file gets generated by kiwi when it writes the MBR ID field in
the MBR of the target device. So they really should be in sync. If they
are not, something goes wrong in the u-boot-install/setup scripts.

Also, have you verified that the target device is actually visible from
within the kiwi initrd? Maybe the module is missing?

I modified the initrd init/include scripts to print the device names
that were used for the search run, and the mmcblk0 is there, and some
value is read out. So the driver seems to be ok. The value read from
/boot/mbrid is a different value.

That sounds to me like something is messing with the MBR after it got
created.

He's calling parted in uboot-image-install.in:

https://build.opensuse.org/package/rdiff/home:frank_kunz:branches:openSUSE:Factory:ARM/JeOS?opackage=JeOS=openSUSE%3AFactory%3AARM=19

(Any reason for that placement of the hunk instead of adding in the bottom?)

You may need to save and restore mbrid as done some lines up.


Ah, that explains the missing mbrid, yes :).

I see two potential options according to the boot documentation:

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an709.pdf

1) Use raw offset

According to the documentation you can not use a partition table when 
using the raw format. Maybe you can trick around with abusing the first 
440 bytes for the boot loader and leave the actual partition table and 
MBRID intact:


  https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout

Maybe there's some way to use Preloader 1 instead of 0?

2) Create a partition in the "hole" before the first partition

MBR partitions don't have to be sorted. You can easily create a 
partition number 4 for example that fills 1kb-1M. That region is unused 
in images created by kiwi in the MBR case. If you want to use a GPT, the 
hole starts a bit later (I keep forgetting where - just try 128kb):


  https://en.wikipedia.org/wiki/GUID_Partition_Table

That space should be enough to fit your boot loader (SPL as well as 
U-Boot) in hopefully. Keep in mind that you need to restore that special 
partition after the firstboot resize. The contents will still be there, 
you merely need to add the partition.



Alex

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

Re: [opensuse-arm] Adding new board: No boot device

[Alexander Graf]

On 09/01/2017 21:20, Frank Kunz wrote:

Am 08.01.2017 um 22:29 schrieb Alexander Graf:

For the gfx command line you may want to add a second console=tty or so?

That did not help so far so solve my login problem. In the mean time I
started to modify the initrd that the /boot/mbrid file does not match.
But no idea yet what could be wrong. I haven't found out where it is set
during the image build process, how to debug that?


The mbrid file gets generated by kiwi when it writes the MBR ID field in
the MBR of the target device. So they really should be in sync. If they
are not, something goes wrong in the u-boot-install/setup scripts.

Also, have you verified that the target device is actually visible from
within the kiwi initrd? Maybe the module is missing?


I modified the initrd init/include scripts to print the device names
that were used for the search run, and the mmcblk0 is there, and some
value is read out. So the driver seems to be ok. The value read from
/boot/mbrid is a different value.


That sounds to me like something is messing with the MBR after it got 
created. The MBR ID inside the raw image's MBR and the mbrid file are 
both created by kiwi and usually well aligned.






To verify, just boot with kiwidebug=1 as kernel parameter and you should
get into a shell after kiwi failed to find its boot device.



That is the problem I have. The shell is started on /dev/tty2, but I
need it on the same tty as the serial console is. How can this be
configured?


You should get the terminal on the serial console if the serial console 
is the default output (console=ttyS0 / ttyAMA0 / whatever only, no 
console=tty)





Does EFI not work yet or have you not tried?

No, I have not tried yet. Not sure if that will work.


EFI booting makes it much easier to modify things like the kernel
command line. It also allows you to install and select multiple kernel
versions in parallel.

To make use of it, all you need is a valid "$fdtfile" variable in the
U-Boot default environment. Then set the respective define in the
Images.kiwi.in file for your board and you should be set. You might need
to convert the GPT that kiwi generates to an MBR. See existing snippets
in the u-boot scripts for that.



That sounds interesting. I quick tested that by just setting the
environment variable and by that two partitions are generated. First
partition is a EFI-System partition and the second one a Linux
filesystem. This cannot be booted by the soc first stage loader. It
expects a partition with ID 0xa2 that has a header+spl loader. For the
upstream uboot it has to be the first partition on the SD card. How to
add an arbitrary first partition with KIWI oem?


Now it gets tricky. To simplify the code, U-Boot's internal scripts 
assume that the EFI partition is always the first partition. So we need 
to keep it there.


What SoC exactly are you targetting? Usually most of them have some way 
to put the SPL at a magic offset on the SD card.



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