Re: [opensuse-arm] Extremely slow boot of raspberry pi 4 images
Op donderdag 29 oktober 2020 09:51:10 CET schreef Freek de Kruijf: > Op woensdag 28 oktober 2020 16:02:44 CET schreef Freek de Kruijf: > > Op woensdag 28 oktober 2020 07:57:58 CET schreef Guillaume Gardet: > > > Hi, > > > > > > RPi4 is now tested in openQA: https://openqa.opensuse.org/tests/1451651 > > > And there is no such problem. > > > > > > Could you try another uSD card, and/or another RPi4, maybe? > > > > Once the system is up, it behaves normal/fast. I don't have another RPi4. > > I > > could try another uSD, but considering it is fast when it is up I have no > > hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled > > 10. > > Also putting the image on it is fast. > > > > > Cheers, > > > Guillaume > > Another observation is that another uSD with Raspbian is working normally. > Boots in less than a minute. So it is NOT the RPi4. > > openSUSE shows a number of tests on different partitions, before it finds a > bootable image and gives an error message that an image has not been found. > > Will try the uSD with Raspbian with openSUSE. I tried the uSD, which works good with Raspbian, with the Tumbleweed JeOS images from Snapshot20200918 and Snapshot20201022 and both show the same behavior as described earlier. Did put Raspbian back on the uSD; works OK. Started a bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1178293 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Extremely slow boot of raspberry pi 4 images
Op woensdag 28 oktober 2020 16:02:44 CET schreef Freek de Kruijf: > Op woensdag 28 oktober 2020 07:57:58 CET schreef Guillaume Gardet: > > Hi, > > > > RPi4 is now tested in openQA: https://openqa.opensuse.org/tests/1451651 > > And there is no such problem. > > > > Could you try another uSD card, and/or another RPi4, maybe? > > Once the system is up, it behaves normal/fast. I don't have another RPi4. I > could try another uSD, but considering it is fast when it is up I have no > hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled 10. > Also putting the image on it is fast. > > > Cheers, > > Guillaume Another observation is that another uSD with Raspbian is working normally. Boots in less than a minute. So it is NOT the RPi4. openSUSE shows a number of tests on different partitions, before it finds a bootable image and gives an error message that an image has not been found. Will try the uSD with Raspbian with openSUSE. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Extremely slow boot of raspberry pi 4 images
Op woensdag 28 oktober 2020 07:57:58 CET schreef Guillaume Gardet: > Hi, > > RPi4 is now tested in openQA: https://openqa.opensuse.org/tests/1451651 > And there is no such problem. > > Could you try another uSD card, and/or another RPi4, maybe? Once the system is up, it behaves normal/fast. I don't have another RPi4. I could try another uSD, but considering it is fast when it is up I have no hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled 10. Also putting the image on it is fast. > Cheers, > Guillaume > -- 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
[opensuse-arm] Latest image for openSUSE-Tumbleweed pine64 gets no IPv4 connection
I used openSUSE-Tumbleweed-ARM-JeOS-pine64.aarch64-2020.10.25-Build11.2.raw.xz to build a system for my Banana Pi M64. After starting the system I do have an IPv6 connection, but no IPv4 connection I arrived at this test because I upgraded that system, which started with 2020.08.15-Build11.11. I configured that system, disabling IPv6. After the upgrade I did not have an IPv4 connection anymore. The interface eth0 was UP, but it did not have/get an IPv4 address. Probably something is wrong with getting an address via DHCPv4. I did have the older image and now I have a system with both an IPv4 and IPv6 address. I filed a bug report https://bugzilla.opensuse.org/show_bug.cgi?id=1178221 -- 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
[opensuse-arm] Extremely slow boot of raspberry pi 4 images
I tried the newest XFCE Raspberry Pi 4 images for openSUSE Leap 15.2 and Tumbleweed. Both are extremely slow to start. I did not have enough patience for Leap 15.2 to see it finish with a log screen, so abandoned that test and continued with the test of Tumbleweed. There are several error messages during the boot process to explain why it takes so long, but even loading the final linux image takes minutes. Below is what I did catch during the start of the boot process: --- U-Boot 2020.04 (Aug 09 2020 - 19:41:12 +) DRAM: 3.9 GiB RPI 4 Model B (0xc03112) MMC: mmcnr@7e30: 1, emmc2@7e34: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In:serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 4 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:3... ** Invalid partition 4 ** ** Unrecognized filesystem type ** Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! Scanning disk mm...@7e30.blk... Disk mm...@7e30.blk not ready Scanning disk em...@7e34.blk... ** Unrecognized filesystem type ** Found 4 disks BootOrder not defined EFI boot manager: Cannot load any image 1382256 bytes read in 108 ms (12.2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Welcome to GRUB! Please press 't' to show the boot menu on this console error: file `/boot/grub2/locale/nl.gmo' not found. --- This is the first reboot after the initial boot of the system and after making some configuration changes in that system. O.a. the default language to be nl_NL. I needed at least 30 minutes to get to the GRUB screen. It looks as if the clock is very slow. On the GRUB screen 10s appeared, which is the initial count down time, but this time is very slowly decreasing. About 5 minutes per second. The USB keyboard does nothing. I finally tried the keyboard on the serial port which started loading the openSUSE image. After 2 hours I got the login screen of XFCE. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Very slow zypper dup on Banana Pi M64
Op maandag 7 september 2020 17:15:22 CEST schreef u: > On 06/09/2020 12:05, Freek de Kruijf wrote: > > Hi all, > > > > I have a Banana Pi M64 on which I installed: > > openSUSE-Tumbleweed-ARM-JeOS-pine64.aarch64-2020.07.28-Build8.3.raw.xz > > When performing a "zypper dup" downloading the upgraded packages is as > > expected, BUT installing the packages is very slow. > > > > I also have a Raspberry Pi 4B+ which uses the same repository on which > > upgrading is as to be expected. > > > > The Banana Pi M64 has 2 GB memory, which is quite enough. > > > > The only striking difference, to me, is that the image for the Banana Pi > > uses btrfs, whereas the image for the Raspberry Pi uses ext4 as the file > > system for the ROOT partition. > > > > Any ideas? > > Did you test with the same SD card? I did now. Both show similar speeds, fast. So it must be a rather faulty micro-SD, although data seems to be intact. Thanks for the answer. > > Regards, > Matthias -- 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
[opensuse-arm] Very slow zypper dup on Banana Pi M64
Hi all, I have a Banana Pi M64 on which I installed: openSUSE-Tumbleweed-ARM-JeOS-pine64.aarch64-2020.07.28-Build8.3.raw.xz When performing a "zypper dup" downloading the upgraded packages is as expected, BUT installing the packages is very slow. I also have a Raspberry Pi 4B+ which uses the same repository on which upgrading is as to be expected. The Banana Pi M64 has 2 GB memory, which is quite enough. The only striking difference, to me, is that the image for the Banana Pi uses btrfs, whereas the image for the Raspberry Pi uses ext4 as the file system for the ROOT partition. Any ideas? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Bluetooth keyboard on a Raspberry Pi 4B
Op woensdag 8 juli 2020 09:45:59 CEST schreef Matthias Brugger: > On 07/07/2020 19:52, Fabian Vogt wrote: > > Am Dienstag, 7. Juli 2020, 19:06:38 CEST schrieb Freek de Kruijf: > >> Op dinsdag 7 juli 2020 14:57:40 CEST schreef Fabian Vogt: > >>> Hi, > >>> > >>> Am Dienstag, 7. Juli 2020, 14:46:42 CEST schrieb Freek de Kruijf: > >>>> On the wiki page HCL:Raspberry_Pi4 I don't see an issue for Bluetooth > >>>> support. Because my normal keyboard died I am trying to use a small > >>>> bluetooth keyboard on this system. However I can't find or enable a > >>>> hci0 > >>>> device. > >>>> > >>>> How do I activate the bluetooth interface of the Rapberry Pi 4? > >>> > >>> On the Pi3, this command is needed: hciattach /dev/ttyAMA1 bcm43xx > >>> 921600 > >>> On the Pi4 it might be a different interface. > >>> > >>> Cheers, > >>> Fabian > >> > >> Thanks. That did the trick. Should this not be included in enabling > >> bluetooth on a Raspberry Pi 4? Bug report? > > > > Could be done. Maybe a .service provided by raspberrypi-firmware with some > > code to detect that it's present? This device is always present on a Raspberry Pi 3/4 (aarch64). > Sounds like a plan. Freek could you open a bug, so that we can track that? > > Regards, > Matthias https://bugzilla.opensuse.org/show_bug.cgi?id=1173877 See also: https://bugzilla.opensuse.org/show_bug.cgi?id=1140688 I filed a bug report for Tumbleweed, but Leap is also affected. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Bluetooth keyboard on a Raspberry Pi 4B
Op dinsdag 7 juli 2020 14:57:40 CEST schreef Fabian Vogt: > Hi, > > Am Dienstag, 7. Juli 2020, 14:46:42 CEST schrieb Freek de Kruijf: > > On the wiki page HCL:Raspberry_Pi4 I don't see an issue for Bluetooth > > support. Because my normal keyboard died I am trying to use a small > > bluetooth keyboard on this system. However I can't find or enable a hci0 > > device. > > > > How do I activate the bluetooth interface of the Rapberry Pi 4? > > On the Pi3, this command is needed: hciattach /dev/ttyAMA1 bcm43xx 921600 > On the Pi4 it might be a different interface. > > Cheers, > Fabian Thanks. That did the trick. Should this not be included in enabling bluetooth on a Raspberry Pi 4? Bug report? -- 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
[opensuse-arm] Bluetooth keyboard on a Raspberry Pi 4B
On the wiki page HCL:Raspberry_Pi4 I don't see an issue for Bluetooth support. Because my normal keyboard died I am trying to use a small bluetooth keyboard on this system. However I can't find or enable a hci0 device. How do I activate the bluetooth interface of the Rapberry Pi 4? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Leap 15.2 only sees 1 GB on a 4GB RPi4
Op maandag 6 juli 2020 15:01:08 CEST schreef Matthias Brugger: > On 06/07/2020 13:13, Freek de Kruijf wrote: > > Op maandag 6 juli 2020 09:12:03 CEST schreef Matthias Brugger: > >> On 05/07/2020 16:11, Freek de Kruijf wrote: > >>> I have an openSUSE Leap 15.2 JeOS image running on a 4 GB RPi4. It > >>> reports > >>> only 960MB RAM. > >>> > >>> Is there a solution to increase the amount of memory seen and used? > >> > >> That should long be fixed. Can you try to update? > >> Otherwise please provide the u-boot version (zypper info for example). > >> > >> Regards, > >> Matthias > > > > I first tried to update, but the problem remained, so I did send this > > message. After receiving your answer I inspected u-boot and it turned out > > to be u-boot- rpi3, so I installed u-boot-rpi4, which was a mistake. The > > system does boot but hangs after loading the image. > > Hm strange. Was this an old image? We changed rpi3 to rpiarm64 month ago. Yes. I started this system in January and went from there with zypper dup. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Leap 15.2 only sees 1 GB on a 4GB RPi4
Op maandag 6 juli 2020 09:12:03 CEST schreef Matthias Brugger: > On 05/07/2020 16:11, Freek de Kruijf wrote: > > I have an openSUSE Leap 15.2 JeOS image running on a 4 GB RPi4. It reports > > only 960MB RAM. > > > > Is there a solution to increase the amount of memory seen and used? > > That should long be fixed. Can you try to update? > Otherwise please provide the u-boot version (zypper info for example). > > Regards, > Matthias I first tried to update, but the problem remained, so I did send this message. After receiving your answer I inspected u-boot and it turned out to be u-boot- rpi3, so I installed u-boot-rpi4, which was a mistake. The system does boot but hangs after loading the image. I installed on another micro-SD card the newest Leap 15.2 image and saw that u-boot-rpiarm64 should be installed. So I need to start a complete new 15.2 system. -- 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
[opensuse-arm] Leap 15.2 only sees 1 GB on a 4GB RPi4
I have an openSUSE Leap 15.2 JeOS image running on a 4 GB RPi4. It reports only 960MB RAM. Is there a solution to increase the amount of memory seen and used? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Any progress getting sound in Raspberry Pi 4 images?
Op maandag 29 juni 2020 11:09:21 CEST schreef Nicolas Saenz Julienne: > Hi Freek, > > On Thu, 2020-06-18 at 14:34 +0200, Freek de Kruijf wrote: > > Is there any progress in getting working sound in Raspberry Pi 4 images; > > XFCE or KDE? Tumbleweed and/or Leap 15.2? > > Long story short, it's being worked on upstream. > > HDMI sound through vc4 has already seen some patches[1], but it's still work > in progress. I'm working on enabling sound through the Jack connector, but > I don't have anything ready yet, nor can estimate when it'll be ready. > > Regards, > Nicolas > > [1] https://lkml.org/lkml/2020/5/27/972 Thanks Nicolas. The friend I am assisting uses the Jack connector, so now this system is using Raspbian to have sound. I stick to openSUSE and HDMI, so I am waiting. Will it only be available for Tumbleweed? -- 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
[opensuse-arm] Any progress getting sound in Raspberry Pi 4 images?
Is there any progress in getting working sound in Raspberry Pi 4 images; XFCE or KDE? Tumbleweed and/or Leap 15.2? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Test with newest, Snapshot20200612, KDE Tumbleweed image for RPi4; no login screen for Plasma
Op woensdag 17 juni 2020 18:22:44 CEST schreef Matthias Brugger: > On 16/06/2020 17:57, Freek de Kruijf wrote: > > I did a test with the newest KDE Tumbleweed image for the Raspberry Pi > > 4B, > > Snapshot20200612. I noticed it is using the newest kernel 5.7.1. > > > > Apart from some warning about obsolete use of /var/run instead of /run the > > system started OK, except the main process sddm did start, but there was > > no > > login screen to start a Plasma session. > > > > I made a bugreport: https://bugzilla.opensuse.org/show_bug.cgi?id=1172924 > > > > It also does not show the Wi-Fi device. > > This is most probably: > https://bugzilla.opensuse.org/show_bug.cgi?id=1127613 > > Regards, > Matthias > > > The keyboard is active in GRUB. Tried the mentioned solutions (new kernel, new firmware). Now I have a working Wi-Fi connection. -- 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
[opensuse-arm] Test with newest, Snapshot20200612, KDE Tumbleweed image for RPi4; no login screen for Plasma
I did a test with the newest KDE Tumbleweed image for the Raspberry Pi 4B, Snapshot20200612. I noticed it is using the newest kernel 5.7.1. Apart from some warning about obsolete use of /var/run instead of /run the system started OK, except the main process sddm did start, but there was no login screen to start a Plasma session. I made a bugreport: https://bugzilla.opensuse.org/show_bug.cgi?id=1172924 It also does not show the Wi-Fi device. The keyboard is active in GRUB. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Problem with particular SD card in RPi4
Op dinsdag 16 juni 2020 14:12:12 CEST schreef Michal Suchánek: > On Tue, Jun 16, 2020 at 02:02:44PM +0200, Matthias Brugger wrote: > > +nicolas +michal > > > > On 16/06/2020 14:00, Freek de Kruijf wrote: > > > I am doing some testing with the newest Tumbleweed images for the > > > Raspberry Pi 4B. The micro-SD card I was using for the KDE version > > > showed a rather slow system. Long waiting between commands. > > > > > > After trying to change the default language with "yast language", which > > > pulls in quite a lot of new packages, the system was very slow. Finally > > > dmesg showed error messages complaining: > > > > > > mmc1 timeout waiting for hardware interrupt > > > > > > Searching for a solution I found the following patch: > > > > > > https://patchwork.kernel.org/patch/10219153/ > > > > > > The main cause seems to be the behaviour of certain SD cards of which I > > > apparently have one. I do have a similar card, same brand, same kind and > > > same size, which does not show this behaviour. > > > > > > So my question is: Has this patch been implemented in the newest version > > > of > > > Tumbleweed for the RPi4? > > Most likely. > > > > If not, would it solve this problem? > > No. > > In the case that matters it seems most of the system is locked up. I > suspect something essential like the DMA controller locks up rather than > the MMC controller itself. I can see now why Chinese chips employ > multiple DMA cotrollers with key components like storage having a > private DMA each. > > Given the low general interest and low occurence of these broken cards I > gave up on debugging this. > > I may be able to find the one card that exhibits the problem after > covid-19 situation stabilizes some more but I did not seriously try to > debug a low-level problem like this yet. > > Thanks > > Michal I can send you my SD card if you wish. It behaves normally in my desktop computer. Send me your address by private email. It is a SanDisk Ultra 16 GB. -- 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
[opensuse-arm] Problem with particular SD card in RPi4
I am doing some testing with the newest Tumbleweed images for the Raspberry Pi 4B. The micro-SD card I was using for the KDE version showed a rather slow system. Long waiting between commands. After trying to change the default language with "yast language", which pulls in quite a lot of new packages, the system was very slow. Finally dmesg showed error messages complaining: mmc1 timeout waiting for hardware interrupt Searching for a solution I found the following patch: https://patchwork.kernel.org/patch/10219153/ The main cause seems to be the behaviour of certain SD cards of which I apparently have one. I do have a similar card, same brand, same kind and same size, which does not show this behaviour. So my question is: Has this patch been implemented in the newest version of Tumbleweed for the RPi4? If not, would it solve this problem? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rpi2 does not boot after update to ARM Tumbleweed snapshot 20200226
Op vrijdag 28 februari 2020 12:03:40 CET schreef Michael Ströder: > HI! > > I've updated my Raspberry PI 2 to Tumbleweed snapshot 20200226. > > After the update only the rainbow-colored screen appears but after that > only a black screen, no boot. > > See below the directory listings of /boot and /boot/efi. > > Ciao, Michael. Did you try with a fresh image on another microSD? -- 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
[opensuse-arm] Is there any indication when sound will be supported in an image (Tumbleweed or Leap 15.2) for the Raspberry Pi 4B?
L.S. Is there any indication when sound will be supported in an image (Tumbleweed or Leap 15.2) for the Raspberry Pi 4B? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Flooded with messages dev_pm_opp_set_rate: failed to find current OPP for freq
Op maandag 3 februari 2020 15:05:08 CET schreef Nicolas Saenz Julienne: > Hi, > > On Mon, 2020-02-03 at 14:34 +0100, Freek de Kruijf wrote: > > Currently my Raspberry Pi 4B using the Tumbleweed image with XFCE is > > showing a > > flood of messages: > > > > 2020-02-03T14:28:11.235034+01:00 bach2 kernel: [ 256.866262] cpu cpu0: > > dev_pm_opp_set_rate: failed to find current OPP for freq > > 9223372036854775802 (-34) > > That's unexpected, could you provide the full kernel logs? (make sure the > full boot process is visible). > > Regards, > Nicolas > > > Can somebody explain what it means and how to get rid of them? See bugzilla #1162511 -- 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
[opensuse-arm] Flooded with messages dev_pm_opp_set_rate: failed to find current OPP for freq
Currently my Raspberry Pi 4B using the Tumbleweed image with XFCE is showing a flood of messages: 2020-02-03T14:28:11.235034+01:00 bach2 kernel: [ 256.866262] cpu cpu0: dev_pm_opp_set_rate: failed to find current OPP for freq 9223372036854775802 (-34) Can somebody explain what it means and how to get rid of them? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some progress with official images for Tumbleweed on Raspberry Pi 4B
Op maandag 20 januari 2020 12:38:00 CET schreef Freek de Kruijf:
> I just tried the JeOS, XFCE and KDE versions of the "official" Tumbleweed
> images for the Raspberry Pi 4. They use kernel 5.4.10.
> openSUSE-Tumbleweed-ARM-{JeOS,XFCE,KDE}-raspberrypi4.aarch64-2020.01.08-
> Snapshot20200115.raw.xz
Tried again the XFCE image for Tumbleweed with great success!!!
However I don't see any sound device. Is there a kernel module/driver to load
to have sound via HDMI or the mini jack interface?
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some progress with official images for Tumbleweed and Leap 15.2 on Raspberry Pi 4B
Op vrijdag 24 januari 2020 21:8 CET schreef Freek de Kruijf: Repeated some of the tests on jan 24 using XFCE image for raspberrypi3. > jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Triggering > OnFailure= dependencies. > jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Failed to enqueue > OnFailure= job: No such file or directory Was resolved by installing plymouth, but seems not necessary. Also another error message about org.freedesktop.Accounts was resolved by installing packet accountsservice. > jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Failed with > result 'exit-code'. > > After a reboot all looks OK, except the display-manager. Problem seems to be > the X11 server. Still a problem. I have packages xf86-video-fbdev and xf86-video-fbturbo installed, but still the error message in /var/log/Xorg.0.log: open /dev/dri/card0 : No such file or directory Associated with xf86-video-fbturbo is a device /dev/fb0, is that somehow a replacement for this device? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some progress with official images for Tumbleweed and Leap 15.2 on Raspberry Pi 4B
Op vrijdag 24 januari 2020 11:53:56 CET schreef Guillaume Gardet: > Does dmesg show some errors regarding SD card? > > Guillaume Also tried the XFCE image. Removed swiotlb=512 from grub2.conf before booting this image. Things went OK, except no login screen for XFCE. Entered via ssh and installed u-boot-rpiarm64. Did a reboot and had slow respons. Entering via ssh provided an unexpected prompt after some error messages. At the end of dmesg got: [ 69.353406] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 193.212508] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:747: group 16, block bitmap and bg descriptor inconsistent: 16384 vs 19791 free clusters [ 193.333075] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. [ 298.387322] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:747: group 48, block bitmap and bg descriptor inconsistent: 16768 vs 24768 free clusters [ 335.068930] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:747: group 64, block bitmap and bg descriptor inconsistent: 16768 vs 24768 free clusters [ 337.118447] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. [ 344.421203] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. -bash-4.4# Above line is the console prompt. systemctl status display-manager gave: ● display-manager.service - X Display Manager Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2020-01-24 14:02:23 UTC; 11min ago Process: 2314 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS) Main PID: 2555 (code=exited, status=1/FAILURE) dec 13 10:57:09 bach2 display-manager[2314]: W: This will result in an 'us' X keyboard layout as default jan 24 14:00:57 bach2 display-manager[2314]: Starting service lightdm..done jan 24 14:00:53 bach2 systemd[1]: display-manager.service: PID file /var/run/ displaymanager.pid not readable (yet?) after start: No such file or directory jan 24 14:00:57 bach2 systemd[1]: Started X Display Manager. jan 24 14:01:51 bach2 lightdm[2555]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Main process exited, code=exited, status=1/FAILURE jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Unit entered failed state. jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Triggering OnFailure= dependencies. jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Failed to enqueue OnFailure= job: No such file or directory jan 24 14:02:23 bach2 systemd[1]: display-manager.service: Failed with result 'exit-code'. After a reboot all looks OK, except the display-manager. Problem seems to be the X11 server. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some progress with official images for Tumbleweed and Leap 15.2 on Raspberry Pi 4B
Op vrijdag 24 januari 2020 11:53:56 CET schreef Guillaume Gardet: > > However the system also reported ext4 errors and some commands crashed. > > Does dmesg show some errors regarding SD card? > > Guillaume Installed JeOS image on SD card. Via ssh entered the RPi4 system. Installed u- boot-rpiarm64 and did a reboot. Entered the system again via ssh. This was extremely slow before a login prompt was shown and the prompt for the password. Saw with "top i" the amount of memory. Also hwinfo --memory reported: 01: None 00.0: 10102 Main Memory [Created at memory.74] Unique ID: rdCR.CxwsZFjVASF Hardware Class: memory Model: "Main Memory" Memory Range: 0x-0xf1446fff (rw) Memory Size: 3 GB + 768 MB Config Status: cfg=new, avail=yes, need=no, active=unknown dmesg shows a lot of messages like below: [ 190.326171] [ cut here ] [ 190.326258] WARNING: CPU: 0 PID: 418 at ../drivers/mmc/host/sdhci.c:1094 sdhci_prepare_data+0x960/0x978 [sdhci] [ 190.326262] Modules linked in: af_packet iscsi_ibft iscsi_boot_sysfs nls_iso8859_1 nls_cp437 vfat fat btsdio bluetooth ecdh_generic ecc brcmfmac brcmutil cfg80211 broadcom xhci_pci bcm_phy_lib rfkill xhci_hcd mdio_bcm_unimac cpufreq_dt raspberrypi_hwmon raspberrypi_cpufreq iproc_rng200 bcm2835_wdt pcie_brcmstb genet uio_pdrv_genirq uio crct10dif_ce leds_gpio mmc_block dwc2 sdhci_iproc sdhci_pltfm sdhci udc_core usbcore gpio_raspberrypi_exp clk_raspberrypi mmc_core i2c_bcm2835 bcm2835_dma phy_generic gpio_regulator fixed dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [ 190.326353] CPU: 0 PID: 418 Comm: kworker/0:1H Tainted: GW 5.3.18-lp152.1-default #1 openSUSE Leap 15.2 (unreleased) [ 190.326358] Hardware name: raspberrypi rpi/rpi, BIOS 2019.10 12/20/2019 [ 190.326380] Workqueue: kblockd blk_mq_run_work_fn [ 190.326389] pstate: 4085 (nZcv daIf -PAN -UAO) [ 190.326405] pc : sdhci_prepare_data+0x960/0x978 [sdhci] [ 190.326419] lr : sdhci_prepare_data+0x960/0x978 [sdhci] [ 190.326423] sp : 103939d0 [ 190.326428] x29: 103939d0 x28: b30f6b188148 [ 190.326436] x27: 0002 x26: b30f6c5e0800 [ 190.326444] x25: b30f6cf05000 x24: 0001 [ 190.326450] x23: 00418958 x22: b30f6b1882e0 [ 190.326457] x21: 2327e5999000 x20: b30f6b188360 [ 190.326463] x19: b30f6cf05580 x18: [ 190.326469] x17: 0001 x16: 0007 [ 190.326475] x15: 2327e5999708 x14: 6f74202c29736574 [ 190.326481] x13: 7962203633353536 x12: 2327e59c [ 190.326487] x11: x10: 2327e5bd2000 [ 190.326494] x9 : x8 : 0003 [ 190.326500] x7 : 0461 x6 : 536549d7 [ 190.326506] x5 : 0001 x4 : b30f7b77f2c8 [ 190.326513] x3 : b30f7b77f2c8 x2 : f19f862514c0b000 [ 190.326519] x1 : x0 : 0024 [ 190.326526] Call trace: [ 190.326541] sdhci_prepare_data+0x960/0x978 [sdhci] [ 190.326555] sdhci_send_command+0xf0/0x618 [sdhci] [ 190.326568] sdhci_request+0xe8/0x120 [sdhci] [ 190.326605] __mmc_start_request+0x88/0x1b0 [mmc_core] [ 190.326639] mmc_start_request+0x98/0xd0 [mmc_core] [ 190.326652] mmc_blk_mq_issue_rq+0x5d4/0x7d0 [mmc_block] [ 190.326662] mmc_mq_queue_rq+0x14c/0x328 [mmc_block] [ 190.326669] blk_mq_dispatch_rq_list+0xb0/0x440 [ 190.326676] blk_mq_do_dispatch_sched+0x6c/0x110 [ 190.326684] blk_mq_sched_dispatch_requests+0x128/0x1f0 [ 190.326693] __blk_mq_run_hw_queue+0xd0/0x138 [ 190.326701] blk_mq_run_work_fn+0x28/0x38 [ 190.326712] process_one_work+0x200/0x450 [ 190.326720] worker_thread+0x50/0x4d0 [ 190.326727] kthread+0x130/0x138 [ 190.326736] ret_from_fork+0x10/0x18 [ 190.326741] ---[ end trace 8235e3938456c6b5 ]--- Hope this is what you are looking for. Currently the system, after this last message of dmesg, is responsive and repeating dmesg does not show any additions to its output. Did again a reboot. The system was more responsive and less output from dmesg. The last message was about swiotlb buffer full. Remembered a recommendation to remove swiotlb=512 from the command line in grub. Did so and did a reboot. Access via ssh was fast. No obvious error messages in dmesg anymore. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some progress with official images for Tumbleweed and Leap 15.2 on Raspberry Pi 4B
Op donderdag 23 januari 2020 10:10:15 CET schreef Matthias Brugger: > Looks really strange to me, as this should have been fixed a while ago. Can > you try to update the u-boot-rpiarm64 package please and reboot. > > Regards, > Matthias I found u-boot-rpi3 was installed in the image. Tested only the JeOS image. After installation of u-boot-rpiarm64, which removed u-boot-rpi3, and a reboot the system saw the 4GB memory. However the system also reported ext4 errors and some commands crashed. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some progress with official images for Tumbleweed and Leap 15.2 on Raspberry Pi 4B
Op dinsdag 21 januari 2020 11:51:03 CET schreef Matthias Brugger: > Be patient, it takes a while. We will need to add the HW RNG to speed things > up. I think this should be part of openSUSE Leap 15.2, maybe you want to > try this images: > https://download.opensuse.org/ports/aarch64/distribution/leap/15.2/appliance > s/ > > RaspberryPi3 image should work (TM) on the RPi4 as well. I tried the JeOS and XFCE RPi3 15.2 images om my RPi4. Both give a live system with keyboard access and a working network, both Ethernet and Wi-Fi and output on the HDMI screen. As was to be expected no keyboard access in grub2. However starting the display manager in XFCE did not work. Message about OnFailure which shows plymouth-quit.service. On my desktop the file /usr/lib/ systemd/system/plymouth-quit.service is delivered by the package plymouth. After installation of this package on the RPi4, this file did not appear. Also the system does only see 1 GB of memory, while my RPi4 has 4 GB. The XFCE system performed very slow when I was installing some extra software using zypper. Might be caused by a partly faulty SD card; after a reboot I got ext4 errors. > > Regards, > Matthias -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some progress with official images for Tumbleweed on Raspberry Pi 4B
Op maandag 20 januari 2020 21:19:20 CET schreef Fabian Vogt:
> Hi,
>
> Am Montag, 20. Januar 2020, 12:38:00 CET schrieb Freek de Kruijf:
> > I just tried the JeOS, XFCE and KDE versions of the "official" Tumbleweed
> > images for the Raspberry Pi 4. They use kernel 5.4.10.
> > openSUSE-Tumbleweed-ARM-{JeOS,XFCE,KDE}-raspberrypi4.aarch64-2020.01.08-
> > Snapshot20200115.raw.xz
> >
> > Console input from the keyboard attached to a USB interface now works,
> > however not in the grub2 window. I could switch between the tty{1-6}
> > screens. However with XFCE and KDE there was no login screen on tty7.
>
> Sounds like X didn't start. Is xf86-video-fbdev installed?
I have no access to the system, not even via the serial console. Don't know
how to inspect the SD card.
>
> > The console also gives a prompt for login, however after entering root
> > there is no prompt for the password.
> >
> > I did not try to login via the serial line.
> >
> > On the console the system also shows there is an Ethernet connection
> > working, and shows the IPv4 and IPv6 addresses, of which at least IPv4
> > reacts on an outside ping.
> > It does present its public key, which is stored in ~/.ssh/known_hosts on
> > the outside host.
> > However ssh access hangs when a public key for this type of access is
> > presented.
>
> You mean when you ssh to the pi, it hangs after the host key exchange?
Yes. I did "ssh -v".
>
> Cheers,
> Fabian
BTW. The XFCE system also reports errors in the ext4 file system.
--
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
[opensuse-arm] Some progress with official images for Tumbleweed on Raspberry Pi 4B
I just tried the JeOS, XFCE and KDE versions of the "official" Tumbleweed
images for the Raspberry Pi 4. They use kernel 5.4.10.
openSUSE-Tumbleweed-ARM-{JeOS,XFCE,KDE}-raspberrypi4.aarch64-2020.01.08-
Snapshot20200115.raw.xz
Console input from the keyboard attached to a USB interface now works, however
not in the grub2 window. I could switch between the tty{1-6} screens. However
with XFCE and KDE there was no login screen on tty7.
The console also gives a prompt for login, however after entering root there
is no prompt for the password.
I did not try to login via the serial line.
On the console the system also shows there is an Ethernet connection working,
and shows the IPv4 and IPv6 addresses, of which at least IPv4 reacts on an
outside ping.
It does present its public key, which is stored in ~/.ssh/known_hosts on the
outside host.
However ssh access hangs when a public key for this type of access is
presented.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Problems with latest image openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi-Build62.3.raw.xz
Op woensdag 8 januari 2020 15:56:55 CET schreef Thorsten Kukuk: > On Wed, Jan 08, Freek de Kruijf wrote: > > The latest image for the Raspberry Pi 4B from Matthias Brugger appears to > > be very slow when installing packages. > > Matthias told you several times to use the official images, why are > you still using this outdated ones? I do use the official ones also, but these are unusable; no ethernet, no keyboard and no mouse support; access only via a serial connection. This support should be available in kernel 5.4, which is used in the images of Matthias. I do see daily new images generated by Matthias, so I would not qualify these as outdated. In fact these are the ones that currently can be used on a RPi4B. I even did add enough packages to have a workable XFCE system and most likely could have a workable KDE system. It lacks however support for sound and support for video output is poor. To avoid the problem I reported on in this thread, I needed to convert the image of Matthias into a system without btrfs. I am using ext4 for BOOT and ROOT and added a xfs partition for /home. > > It shows a lot of errors like: > > sdhci-iproc fe34.emmc2: swiotlb buffer is full (sz: 8192 bytes), total > > 512 (slots), used 507 ... > > dec 03 17:59:27 localhost kernel: sdhci-iproc fe34.emmc2: swiotlb > > buffer is full (sz: 4096 bytes), total 512 (slots), used 511 ... > > > > I could not find a parameter to increase the buffers. > > > > Is it OK to report issues like these on this list? > > For this we have bugzilla, it's known and people are working on fixing > it. Use the official images and you don't have this problems ;) My only intention is to assist in getting a proper working system on the RPi4B. My understanding is that bugzilla is for the "official" images and not for the images Matthias is working on. > > Thorsten -- 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
[opensuse-arm] Problems with latest image openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi-Build62.3.raw.xz
The latest image for the Raspberry Pi 4B from Matthias Brugger appears to be very slow when installing packages. It shows a lot of errors like: sdhci-iproc fe34.emmc2: swiotlb buffer is full (sz: 8192 bytes), total 512 (slots), used 507 ... dec 03 17:59:27 localhost kernel: sdhci-iproc fe34.emmc2: swiotlb buffer is full (sz: 4096 bytes), total 512 (slots), used 511 ... I could not find a parameter to increase the buffers. Is it OK to report issues like these on this list? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Some success with image for RPi4 from Matthias Brugger to reach graphical interface
Op donderdag 26 december 2019 16:40:01 CET schreef Freek de Kruijf: > Today I tried image: > openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi-Build61.34.raw.xz > from Matthias Brugger. > > After installing xorg packages and pattern XFCE, adding a normal user, and > setting the default target to graphical-interface, I was able, after login, > to have a XFCE desktop for that normal user. I can use the mouse and the > keyboard, so it almost reaches a usable state for me. > > In order to use wireless one needs to replace the package wpa_supplicant by > the older one from the repository. At least 2.4 GHz wireless works with that > older version. The system also sees 5 GHz access points, but I could not > connect to these. Shortly after this rather positive result I ran into problems, which according to my findings, were caused by the btrfs file system for /root and /boot. So I copied the content of a newer version of this image onto a SD which was formatted with ext4 for these folders/partitions. Furthermore I have a separate /home partition with xfs and a 4 GiB swap partition. Also changed the UUIDs in grub.conf in the used UUID on that card and made a new /etc/fstab to mount these file systems by LABEL. This system performs well. The main problem is the lack of sound. The system does not show an interface for sound. I would expect sound to be available via HDMI. Should I enable a driver in the kernel? I found a loadable module: modprobe snd_bcm2835, but yast does not report a sound device when I try to configure it. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] New ARM Tumbleweed snapshot 20191225 released!
Op vrijdag 27 december 2019 20:08:21 CET schreef Guillaume Gardet: > > Please check the known defects of this snapshot before upgrading: > https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=3&version > =Tumbleweed&build=20191225 > > Please do not reply to this email to report issues, rather file a bug > on bugzilla.opensuse.org. For more information on filing bugs please > see https://en.opensuse.org/openSUSE:Submitting_bug_reports > I tried the JeOS and XFCE images for the Raspberry Pi 4B, but both have the same problems: No support for an attached keyboard and mouse via USB. There is no wired Ethernet interface (eth0) visible, only wlan0. Wireless will probably not work because of a faulty wpa_supplicant packet. Should I file bug reports for these problems? -- 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
[opensuse-arm] Some success with image for RPi4 from Matthias Brugger to reach graphical interface
Today I tried image: openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi-Build61.34.raw.xz from Matthias Brugger. After installing xorg packages and pattern XFCE, adding a normal user, and setting the default target to graphical-interface, I was able, after login, to have a XFCE desktop for that normal user. I can use the mouse and the keyboard, so it almost reaches a usable state for me. In order to use wireless one needs to replace the package wpa_supplicant by the older one from the repository. At least 2.4 GHz wireless works with that older version. The system also sees 5 GHz access points, but I could not connect to these. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] OpenSuse with KDE for raspberry pi 4?
Op maandag 16 december 2019 18:20:28 CET schreef Matthias Brugger: > As I said, this is my playground. I don't pretend to have a working bug-free > project there. If you want to use the btrfs subvolume and want to make it > work as expected then please make a copy of the project as this can go away > anytime soon. If you don't want to do so, please switch to the official > images, which I posted links for on Sunday. > > Regards, > Matthias A bit aside of the subject. I tried Wi-Fi in your image and found that it does not work. The solution is to use wpa_supplicant version 2.6-9.1 from the aarch64 repository. I could connect to the 2.4 and 5 GHz access point. Version 2.9-1.1 contains a bug which will be solved in January. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] OpenSuse with KDE for raspberry pi 4?
Op maandag 16 december 2019 18:20:28 CET schreef Matthias Brugger: > On 16/12/2019 17:41, Freek de Kruijf wrote: > > Op zaterdag 14 december 2019 00:17:47 CET schreef Freek de Kruijf: > >> Op woensdag 27 november 2019 15:13:13 CET schreef Freek de Kruijf: > >>> Op woensdag 27 november 2019 14:05:42 CET schreef Narender Mann: > >>>> Sent from my iPhone > >>> > >>> Matthias Brugger is currently working on a working image for openSUSE > >>> Tumbleweed on the Raspberry Pi 4B. The main problem currently seems to > >>> be > >>> getting the network for Ethernet working. Also Wi-Fi is not working. For > >>> KDE you also need support for an attached monitor on a micro-HDMI > >>> interface and working USB for mouse and keyboard. > >>> > >>> My tests so far show a working system, but the only access is via the > >>> serial interface using the three pins on the GPIO system. > >>> > >>> There are two repositories with images showing the above shortcomings: > >>> https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi > >>> 4/ > >>> openSUSE_Tumbleweed_ARM/ > >>> https://download.opensuse.org/ports/aarch64/tumbleweed/images/ > >> > >> Today I tried openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi- > >> Build61.5.raw.xz from the first repository on my RPi4. > >> > >> It works, although wireless does not work, but Ethernet does. > >> The layout of the disk is a fat32 partition EFI, a btrfs partition BOOT > >> and > >> a btrfs partition ROOT. There is a warning during boot of a duplicated > >> entry in /etc/fstab, although I could not find out what was wrong. > >> > >> When doing yast2->System->Partitioning to change from UUID in /etc/fstab > >> to > >> using LABEL, the same warning appears. Also a warning that the 16M > >> partition should be 278MB. > > > > Did a bit of analyzing this issue and found that the partition BOOT, which > > contains the boot image of the kernel is not mounted when the system is > > up. In stead there is an almost empty btrfs sub volume /boot of / in > > which partition EFI is mounted as /boot/efi. > > Shouldn't partition BOOT be mounted as /boot and partition EFI as a sub > > folder of /boot named /boot/efi? > > As I said, this is my playground. I don't pretend to have a working bug-free > project there. If you want to use the btrfs subvolume and want to make it > work as expected then please make a copy of the project as this can go away > anytime soon. If you don't want to do so, please switch to the official > images, which I posted links for on Sunday. > > Regards, > Matthias I am quite aware that this is your playground and I am thankful I can play with it. I just tried to let you know my findings. If it distracts you I will stop sending these. > >> Does this mean that we will soon have a working network in the images in > >> the second repository? I am not aware of your message from Sunday. Are the official images on my first repository mentioned above? Naturally I did try these images also, but they are not useful yet. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] OpenSuse with KDE for raspberry pi 4?
Op zaterdag 14 december 2019 00:17:47 CET schreef Freek de Kruijf: > Op woensdag 27 november 2019 15:13:13 CET schreef Freek de Kruijf: > > Op woensdag 27 november 2019 14:05:42 CET schreef Narender Mann: > > > Sent from my iPhone > > > > Matthias Brugger is currently working on a working image for openSUSE > > Tumbleweed on the Raspberry Pi 4B. The main problem currently seems to be > > getting the network for Ethernet working. Also Wi-Fi is not working. For > > KDE you also need support for an attached monitor on a micro-HDMI > > interface and working USB for mouse and keyboard. > > > > My tests so far show a working system, but the only access is via the > > serial interface using the three pins on the GPIO system. > > > > There are two repositories with images showing the above shortcomings: > > https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4/ > > openSUSE_Tumbleweed_ARM/ > > https://download.opensuse.org/ports/aarch64/tumbleweed/images/ > > Today I tried openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi- > Build61.5.raw.xz from the first repository on my RPi4. > > It works, although wireless does not work, but Ethernet does. > The layout of the disk is a fat32 partition EFI, a btrfs partition BOOT and > a btrfs partition ROOT. There is a warning during boot of a duplicated > entry in /etc/fstab, although I could not find out what was wrong. > > When doing yast2->System->Partitioning to change from UUID in /etc/fstab to > using LABEL, the same warning appears. Also a warning that the 16M partition > should be 278MB. Did a bit of analyzing this issue and found that the partition BOOT, which contains the boot image of the kernel is not mounted when the system is up. In stead there is an almost empty btrfs sub volume /boot of / in which partition EFI is mounted as /boot/efi. Shouldn't partition BOOT be mounted as /boot and partition EFI as a sub folder of /boot named /boot/efi? > Does this mean that we will soon have a working network in the images in the > second repository? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] OpenSuse with KDE for raspberry pi 4?
Op woensdag 27 november 2019 15:13:13 CET schreef Freek de Kruijf: > Op woensdag 27 november 2019 14:05:42 CET schreef Narender Mann: > > Sent from my iPhone > > Matthias Brugger is currently working on a working image for openSUSE > Tumbleweed on the Raspberry Pi 4B. The main problem currently seems to be > getting the network for Ethernet working. Also Wi-Fi is not working. For KDE > you also need support for an attached monitor on a micro-HDMI interface and > working USB for mouse and keyboard. > > My tests so far show a working system, but the only access is via the serial > interface using the three pins on the GPIO system. > > There are two repositories with images showing the above shortcomings: > https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4/ > openSUSE_Tumbleweed_ARM/ > https://download.opensuse.org/ports/aarch64/tumbleweed/images/ Today I tried openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi- Build61.5.raw.xz from the first repository on my RPi4. It works, although wireless does not work, but Ethernet does. The layout of the disk is a fat32 partition EFI, a btrfs partition BOOT and a btrfs partition ROOT. There is a warning during boot of a duplicated entry in /etc/fstab, although I could not find out what was wrong. When doing yast2->System->Partitioning to change from UUID in /etc/fstab to using LABEL, the same warning appears. Also a warning that the 16M partition should be 278MB. Does this mean that we will soon have a working network in the images in the second repository? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspi 3b / Leap 15.1 / reproducible Kernel Panic
Op zondag 1 december 2019 17:05:58 CET schreef Axel Braun: > Am Freitag, 29. November 2019, 11:43:06 CET schrieb Axel Braun: > > I'm about to set up a Raspi 3b+, and see kernel panics with the image > > openSUSE-Leap-15.1-ARM-LXQT-raspberrypi3.aarch64-2019.05.17- > > Snapshot1.62.raw.xz > > > > I organized a second Raspi, and , surprise, here it worked without any > problems. So it seems to be a hardware issue. Sorry for the noise! > > Any idea how to test the hardware? > > Thanks > Axel Had a similar problem with a RPi1B+, which worked fine for quite some time, but started to crash and rebooted several times a day. After replacing the power device, it behaved like before. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] OpenSuse with KDE for raspberry pi 4?
Op woensdag 27 november 2019 14:05:42 CET schreef Narender Mann: > Sent from my iPhone Matthias Brugger is currently working on a working image for openSUSE Tumbleweed on the Raspberry Pi 4B. The main problem currently seems to be getting the network for Ethernet working. Also Wi-Fi is not working. For KDE you also need support for an attached monitor on a micro-HDMI interface and working USB for mouse and keyboard. My tests so far show a working system, but the only access is via the serial interface using the three pins on the GPIO system. There are two repositories with images showing the above shortcomings: https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4/ openSUSE_Tumbleweed_ARM/ https://download.opensuse.org/ports/aarch64/tumbleweed/images/ -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op zondag 10 november 2019 18:48:11 CET schreef Matthias Brugger: > On 09/11/2019 17:25, Freek de Kruijf wrote: > > Op vrijdag 8 november 2019 12:35:03 CET schreef Matthias Brugger: > >> Out of interest, what's the most urgent thing you need in RPi4 that is > >> not > >> supported by our image right now (I know we are missing a lot of stuff > >> still). > > > > For me, the order of importance is: > > 1. Make wired Ethernet working with ssh access, so you don't need to > > configure the system to run. It should run using DHCP from the image. > > 2. Make keyboard, mouse and display working, so a desktop can be used. > > Keyboard and mouse will need to get connected to the USB3.0 port, or are you > able to connect and power the deivce via the type-C connector? Yes. I power the device via the USB-C with a 5V 3A unit with a converter cable. > Regards, > Matthias > > > 3. Make Wi-Fi working. > > 4. Make USB 3.0 working. > > > >> Regards, > >> Matthias -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op vrijdag 8 november 2019 12:35:03 CET schreef Matthias Brugger: > Out of interest, what's the most urgent thing you need in RPi4 that is not > supported by our image right now (I know we are missing a lot of stuff > still). > For me, the order of importance is: 1. Make wired Ethernet working with ssh access, so you don't need to configure the system to run. It should run using DHCP from the image. 2. Make keyboard, mouse and display working, so a desktop can be used. 3. Make Wi-Fi working. 4. Make USB 3.0 working. > Regards, > Matthias -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op dinsdag 24 september 2019 16:49:42 CET schreef Matthias Brugger: > Hi, > > I'm working on some (still hacky) support for RPi4. > You can find the JeOS image in my home project [1]. > Beware that I was able to break the build of U-Boot yesterday. I'll try to > fix this tonight. > > Regards, > Matthias I am still unable to get any output on an attached HDMI monitor. Also using Raspbian Buster is not showing anything on the screen. This last system has a application, tvservice, to manipulate the output to the screen. It shows HDMI0 is active. Is there something in openSUSE which does the same? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op woensdag 30 oktober 2019 20:56:42 CET schreef Matthias Brugger: > You need to boot with the HDMI cable comnected to the RPi4. This should give > you an EFI framebuffer. Work on the KMS driver is in progress but will take > a while. > >> So, my question is: should I get something in the current state on > > > >the HDMI > > > >> screen? > > Try to add console=tty to your kernel boot parameters. Beware that USB is > not working ATM. Another thing we are working on, stay tuned. No output on the HDMI interface. Is there a way to from within the system that video output to which HDMI port is active? > >> Is there anything I can do to help with getting TW or Leap 15.1/2 > > > >running on the > > > >> RPI4? > > You could try if i2c and SPI is working on the pins. Can you point me to some documentation to see how these things should work? I did work with python-RPi.GPIO. > Regards, > Matthias -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op vrijdag 18 oktober 2019 23:15:42 CET schreef Freek de Kruijf: > Op dinsdag 24 september 2019 16:49:42 CEST schreef Matthias Brugger: > > Hi, > > > > On 24/09/2019 13:24, Linux Kamarada wrote: > > > Hi, everyone! > > > > > > AFAIK openSUSE does not support Raspberry Pi 4 Model B yet. [1] > > > > > > I’ve bought that board, I know the very basics on how to use it [2] > > > and I want to help to port openSUSE to it. How can I start? > > > > I'm working on some (still hacky) support for RPi4. > > You can find the JeOS image in my home project [1]. > > Beware that I was able to break the build of U-Boot yesterday. I'll try to > > fix this tonight. > > > > Regards, > > Matthias > > Today I got my RPi4B system. I tried both images on: > > https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4/ > openSUSE_Tumbleweed_ARM/ > > but did not get any result; that is: nothing on the HDMI screen. Tried both > outputs. > > What am I doing wrong? Tried openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi4-Build42.8.raw.xz and got some results: output/input on the serial line. However no network connection. The eth0 interface is UP and has link local addresses 169... and fe80::..., but apparently not a proper connection. I tried Buster on this system and got it working, both via the serial line and via ssh, but I did not get any output on the HDMI interface. This seems to be a known problem with certain monitors. I have a TV screen and an ACER display with HDMI and VGA input, but also a HDMI->VGA converter gives nothing on the screen. So, my question is: should I get something in the current state on the HDMI screen? Is there anything I can do to help with getting TW or Leap 15.1/2 running on the RPI4? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B (side problem)
Op maandag 21 oktober 2019 13:42:09 CEST schreef Freek de Kruijf: > I even have a problem with screen to connect via my USB serial line to the > RPi4. I can't find how to change the window size from 24x80 to something > larger. I tried "C-a : width -w 132 48" and "C-a : displays" these values, > but my lines are cut off at 80. Found the solution. Before starting screen give command "stty -a" to find the value of rows and cols. After starting screen and in a shell session on the RPI4 give the commands: stty cols stty rows -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op maandag 21 oktober 2019 11:00:49 CEST schreef u: > On 20/10/2019 18:18, Freek de Kruijf wrote: > > Op vrijdag oktober 2019 23:15:42 CEST schreef Freek de Kruijf: > >> Op dinsdag 24 september 2019 16:49:42 CEST schreef Matthias Brugger: > >>> Hi, > >>> > >>> On 24/09/2019 13:24, Linux Kamarada wrote: > >>>> Hi, everyone! > >>>> > >>>> AFAIK openSUSE does not support Raspberry Pi 4 Model B yet. [1] > >>>> > >>>> I’ve bought that board, I know the very basics on how to use it [2] > >>>> and I want to help to port openSUSE to it. How can I start? > >>> > >>> I'm working on some (still hacky) support for RPi4. > >>> You can find the JeOS image in my home project [1]. > >>> Beware that I was able to break the build of U-Boot yesterday. I'll try > >>> to > >>> fix this tonight. > >>> > >>> Regards, > >>> Matthias > >> > >> Today I got my RPi4B system. I tried both images on: > >> > >> https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4 > >> / > >> openSUSE_Tumbleweed_ARM/ > >> > >> but did not get any result; that is: nothing on the HDMI screen. Tried > >> both > >> outputs. > > You will need to add console=tty boot parameter. But no USB, so no > keyboard... > >> What am I doing wrong? > > > > I connected a serial device to the UART pins on the GPIO and got the > > system > > running with output and input on this console. > > > > Build31.12 from the above repository did not work. The above working > > system is with Build26.1. > > > > Updated the wiki to reflect this fact. > > Thanks. The project is not meant to always provide working images. I'm > working on a Tumbleweed image. I do not expect that. It is meant to warn other users. > > I tried to enable Wired Ethernet but this failed so far. Any suggestions? > > Wait, the patches are not upstream. We are working on it. OK. I am patiently waiting. Indeed the message Chester Lin mentioned is found in the journal. But I do not have the skills to do anything with his suggestion. I even have a problem with screen to connect via my USB serial line to the RPi4. I can't find how to change the window size from 24x80 to something larger. I tried "C-a : width -w 132 48" and "C-a : displays" these values, but my lines are cut off at 80. > Regards, > Matthias -- fr.gr. member openSUSE Freek de Kruijf -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op maandag 21 oktober 2019 11:00:49 CEST schreef u: > On 20/10/2019 18:18, Freek de Kruijf wrote: > > Op vrijdag oktober 2019 23:15:42 CEST schreef Freek de Kruijf: > >> Op dinsdag 24 september 2019 16:49:42 CEST schreef Matthias Brugger: > >>> Hi, > >>> > >>> On 24/09/2019 13:24, Linux Kamarada wrote: > >>>> Hi, everyone! > >>>> > >>>> AFAIK openSUSE does not support Raspberry Pi 4 Model B yet. [1] > >>>> > >>>> I’ve bought that board, I know the very basics on how to use it [2] > >>>> and I want to help to port openSUSE to it. How can I start? > >>> > >>> I'm working on some (still hacky) support for RPi4. > >>> You can find the JeOS image in my home project [1]. > >>> Beware that I was able to break the build of U-Boot yesterday. I'll try > >>> to > >>> fix this tonight. > >>> > >>> Regards, > >>> Matthias > >> > >> Today I got my RPi4B system. I tried both images on: > >> > >> https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4 > >> / > >> openSUSE_Tumbleweed_ARM/ > >> > >> but did not get any result; that is: nothing on the HDMI screen. Tried > >> both > >> outputs. > > You will need to add console=tty boot parameter. But no USB, so no > keyboard... > >> What am I doing wrong? > > > > I connected a serial device to the UART pins on the GPIO and got the > > system > > running with output and input on this console. > > > > Build31.12 from the above repository did not work. The above working > > system is with Build26.1. > > > > Updated the wiki to reflect this fact. > > Thanks. The project is not meant to always provide working images. I'm > working on a Tumbleweed image. I do not expect that. It is meant to warn other users. > > I tried to enable Wired Ethernet but this failed so far. Any suggestions? > > Wait, the patches are not upstream. We are working on it. OK. I am patiently waiting. Indeed the message Chester Lin mentioned is found in the journal. But I do not have the skills to do anything with his suggestion. I even have a problem with screen to connect via my USB serial line to the RPi4. I can't find how to change the window size from 24x80 to something larger. I tried "C-a : width -w 132 48" and "C-a : displays" these values, but my lines are cut off at 80. > Regards, > Matthias -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op vrijdag oktober 2019 23:15:42 CEST schreef Freek de Kruijf: > Op dinsdag 24 september 2019 16:49:42 CEST schreef Matthias Brugger: > > Hi, > > > > On 24/09/2019 13:24, Linux Kamarada wrote: > > > Hi, everyone! > > > > > > AFAIK openSUSE does not support Raspberry Pi 4 Model B yet. [1] > > > > > > I’ve bought that board, I know the very basics on how to use it [2] > > > and I want to help to port openSUSE to it. How can I start? > > > > I'm working on some (still hacky) support for RPi4. > > You can find the JeOS image in my home project [1]. > > Beware that I was able to break the build of U-Boot yesterday. I'll try to > > fix this tonight. > > > > Regards, > > Matthias > > Today I got my RPi4B system. I tried both images on: > > https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4/ > openSUSE_Tumbleweed_ARM/ > > but did not get any result; that is: nothing on the HDMI screen. Tried both > outputs. > > What am I doing wrong? I connected a serial device to the UART pins on the GPIO and got the system running with output and input on this console. Build31.12 from the above repository did not work. The above working system is with Build26.1. Updated the wiki to reflect this fact. I tried to enable Wired Ethernet but this failed so far. Any suggestions? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 4 Model B
Op dinsdag 24 september 2019 16:49:42 CEST schreef Matthias Brugger: > Hi, > > On 24/09/2019 13:24, Linux Kamarada wrote: > > Hi, everyone! > > > > AFAIK openSUSE does not support Raspberry Pi 4 Model B yet. [1] > > > > I’ve bought that board, I know the very basics on how to use it [2] > > and I want to help to port openSUSE to it. How can I start? > > I'm working on some (still hacky) support for RPi4. > You can find the JeOS image in my home project [1]. > Beware that I was able to break the build of U-Boot yesterday. I'll try to > fix this tonight. > > Regards, > Matthias Today I got my RPi4B system. I tried both images on: https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4/ openSUSE_Tumbleweed_ARM/ but did not get any result; that is: nothing on the HDMI screen. Tried both outputs. What am I doing wrong? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] On a Raspberry Pi 2B cat /proc/cpuinfo shows wrongly Hardware: BCM2835
Op woensdag 18 september 2019 17:52:59 CEST schreef Freek de Kruijf: > On a Raspberry Pi 2B "cat /proc/cpuinfo" shows o.a.: > Hardware: BCM2835 > Revision: > Serial : 8ce0c548 > > All information I search for says the Raspberry Pi 2B has a BCM2836. > So I wonder where this information is introduced in the the kernel module. > The packet python-RPi.GPIO relies on the accurate information in > /proc/cpuinfo Currently this packet sees the RPi 2B as a RPi 1. bug report #1151368 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] On a Raspberry Pi 2B cat /proc/cpuinfo shows wrongly Hardware: BCM2835
Op donderdag 19 september 2019 09:53:27 CEST schreef Matthias Brugger: > On 18/09/2019 17:52, Freek de Kruijf wrote: > > On a Raspberry Pi 2B "cat /proc/cpuinfo" shows o.a.: > > Hardware: BCM2835 > > Revision: > > Serial : 8ce0c548 > > > > All information I search for says the Raspberry Pi 2B has a BCM2836. > > So I wonder where this information is introduced in the the kernel module. > > Which openSUSE are you referring to? I had a quick look and it seems it > get's inherited from the DTS. Can you check what your device tree looks > like? Currently /etc/os.release reports: NAME="openSUSE Tumbleweed" # VERSION="20190607" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20190607" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20190607" BUG_REPORT_URL="https://bugs.opensuse.org"; HOME_URL="https://www.opensuse.org/"; LOGO="distributor-logo" > > The packet python-RPi.GPIO relies on the accurate information in > > /proc/cpuinfo Currently this packet sees the RPi 2B as a RPi 1. > > Regards, > Matthias -- 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
[opensuse-arm] On a Raspberry Pi 2B cat /proc/cpuinfo shows wrongly Hardware: BCM2835
On a Raspberry Pi 2B "cat /proc/cpuinfo" shows o.a.: Hardware: BCM2835 Revision: Serial : 8ce0c548 All information I search for says the Raspberry Pi 2B has a BCM2836. So I wonder where this information is introduced in the the kernel module. The packet python-RPi.GPIO relies on the accurate information in /proc/cpuinfo Currently this packet sees the RPi 2B as a RPi 1. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] RPI1 does not boot after Tumbleweed upgrade
Op woensdag 11 september 2019 20:31:16 CEST schreef Freek de Kruijf: > Op woensdag 11 september 2019 20:26:41 CEST schreef Freek de Kruijf: > > I did have the same problem as Michael. After a "zypper dup --no-r" the > > system did not boot anymore. I used the serial connection with the RPi1 > > and > > there was no output at all. > > > > So I did check the content of the first partition on the SD. It did lack > > the 6 files present in: raspberrypi-firmware-2019.09.04-1.1.noarch.rpm On > > my desktop I unpacked these files and put them on the first partition. > > After that the system boots again. > > > > The question is: why were these files removed in the upgrade? > > I found also the answer: > they are wrongly placed in /boot/vc/ instead of /boot/efi/ . Bugzilla #1150408 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] RPI1 does not boot after Tumbleweed upgrade
Op woensdag 11 september 2019 20:26:41 CEST schreef Freek de Kruijf: > I did have the same problem as Michael. After a "zypper dup --no-r" the > system did not boot anymore. I used the serial connection with the RPi1 and > there was no output at all. > > So I did check the content of the first partition on the SD. It did lack the > 6 files present in: raspberrypi-firmware-2019.09.04-1.1.noarch.rpm > On my desktop I unpacked these files and put them on the first partition. > After that the system boots again. > > The question is: why were these files removed in the upgrade? I found also the answer: they are wrongly placed in /boot/vc/ instead of /boot/efi/ . -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] RPI1 does not boot after Tumbleweed upgrade
Op woensdag 11 september 2019 16:36:53 CEST schreef Guillaume Gardet: > > -Original Message- > > From: Michael Ströder > > Sent: 11 September 2019 16:17 > > To: Guillaume Gardet ; openSUSE ARM ML > > > > Subject: Re: [opensuse-arm] RPI1 does not boot after Tumbleweed upgrade > > > > > > > > On 9/11/19 3:53 PM, Guillaume Gardet wrote: > > > > >> From: Michael Ströder > > >> Sent: 11 September 2019 13:55 > > >> > > >> > > >> > > >> On 9/11/19 1:47 PM, Guillaume Gardet wrote: > > >> > > >>>> -Original Message- > > >>>> From: Michael Ströder > > >>>> Sent: 11 September 2019 13:34 > > >>>> > > >>>> > > >>>> > > >>>> I'm running Tumbleweed on RPI1 (armv6). It does not boot after last > > >>>> upgrade to kernel from 5.2.10 to 5.2.13. During upgrade there were > > >>>> no error messages. > > >>> > > >>> > > >>> > > >>> Did you update the kernel only, or the whole distribution (maybe > > >>> including > > >> > > >> firmware)? > > >> > > >> > > >> > > >> I did the usual full upgrade with > > >> zypper dup -l --no-allow-vendor-change --no-recommends > > > > > > > > > > > > Did you run out of space, maybe? > > > > > > > > No. There's plenty of space on the partitions: > > - The firmware partition still has 15MB available and 1.5M used. > > - On the OS partition (where's /boot) 4.9GB are still available. > > > > > > > > > If the rainbow screen is not display, this means that the firmware is > > > not > > > > loaded/started properly. > > > > > IIRC, there was a firmware update with latest snapshot. > > > > > > > > Can I check whether the firmware files are complete? > > > I read again your 1st email and it seems that you are missing the firmware > files on the 1st partition of your SD card. My list: > total 6340 > drwxr-xr-x 3 root root2048 Sep 8 21:15 EFI > -rwxr-xr-x 1 root root 28432 Sep 7 13:21 bcm2708-rpi-b-plus.dtb > -rwxr-xr-x 1 root root 28173 Sep 7 13:21 bcm2708-rpi-b.dtb > -rwxr-xr-x 1 root root 27950 Sep 7 13:21 bcm2708-rpi-cm.dtb > -rwxr-xr-x 1 root root 28634 Sep 7 13:21 bcm2708-rpi-zero-w.dtb > -rwxr-xr-x 1 root root 27898 Sep 7 13:21 bcm2708-rpi-zero.dtb > -rwxr-xr-x 1 root root 29520 Sep 7 13:21 bcm2709-rpi-2-b.dtb > -rwxr-xr-x 1 root root 31325 Sep 7 13:21 bcm2710-rpi-3-b-plus.dtb > -rwxr-xr-x 1 root root 30706 Sep 7 13:21 bcm2710-rpi-3-b.dtb > -rwxr-xr-x 1 root root 29504 Sep 7 13:21 bcm2710-rpi-cm3.dtb > -rwxr-xr-x 1 root root 44472 Sep 7 13:21 bcm2711-rpi-4-b.dtb > -rwxr-xr-x 1 root root 52296 Sep 4 12:07 bootcode.bin > -rwxr-xr-x 1 root root1476 Nov 30 2018 config.txt > -rwxr-xr-x 1 root root6736 Sep 4 12:07 fixup.dat > -rwxr-xr-x 1 root root6092 Sep 4 12:07 fixup4.dat > drwxr-xr-x 2 root root 16384 Sep 8 21:01 overlays > -rwxr-xr-x 1 root root 2877892 Sep 4 12:07 start.elf > -rwxr-xr-x 1 root root 2762820 Sep 4 12:07 start4.elf > -rwxr-xr-x 1 root root 8 Sep 8 21:16 startup.nsh > -rwxr-xr-x 1 root root 443036 Jul 18 12:21 u-boot.bin > > You can get them from the raspberrypi-firmware package: > http://download.opensuse.org/ports/armv6hl/tumbleweed/repo/oss/noarch/raspb > errypi-firmware-2019.09.04-1.1.noarch.rpm You can use ark or 7zip (any > other archive extractor) to extract the files from this RPM. > I tried the latest JeOS-raspberrypi image for RPi1 from > http://download.opensuse.org/ports/armv6hl/tumbleweed/images/openSUSE-Tumbl > eweed-ARM-JeOS-raspberrypi.armv6l-2019.09.04-Snapshot20190907.raw.xz and I > have no problem. > Cheers, > Guillaume I did have the same problem as Michael. After a "zypper dup --no-r" the system did not boot anymore. I used the serial connection with the RPi1 and there was no output at all. So I did check the content of the first partition on the SD. It did lack the 6 files present in: raspberrypi-firmware-2019.09.04-1.1.noarch.rpm On my desktop I unpacked these files and put them on the first partition. After that the system boots again. The question is: why were these files removed in the upgrade? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Inconsistent names of Tumbleweed image for Raspberry Pi 1B in repository
Op maandag 1 juli 2019 10:18:32 CEST schreef Guillaume Gardet: > Hi, > > > -Original Message- > > From: Freek de Kruijf > > Sent: 29 June 2019 15:26 > > To: Mailinglist openSUSE ARM > > Subject: [opensuse-arm] Inconsistent names of Tumbleweed image for > > Raspberry Pi 1B in repository > > > > The latest Tumbleweed image for the Rasberry Pi 1B has two names on the > > web > > page: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l- > > Current.raw.xz and > > openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2019.05.17- > > Snapshot20190607.raw.xz > > This is intended as *Current* link points to the latest image. > > > The corresponding sha256 files have the same content. The fourth line in > > these files contains the sha256 checksum followed by the name of the > > image. > > However this name is: > > openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2019.05.17- > > Build1.43.raw > > This is the name once built in OBS. > > > So one needs to rename the image file before doing the checksum to this > > name. > > > > This name should however also have .xz added at the end. > > Thanks for the report. > Could you open a bug report on https://bugzilla.opensuse.org and Cc me, > please? I think we should just update the name inside the sha256 file. https://bugzilla.opensuse.org/show_bug.cgi?id=1139915 > Thanks, > Guillaume -- 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
[opensuse-arm] Inconsistent names of Tumbleweed image for Raspberry Pi 1B in repository
The latest Tumbleweed image for the Rasberry Pi 1B has two names on the web page: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-Current.raw.xz and openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2019.05.17- Snapshot20190607.raw.xz The corresponding sha256 files have the same content. The fourth line in these files contains the sha256 checksum followed by the name of the image. However this name is: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2019.05.17-Build1.43.raw So one needs to rename the image file before doing the checksum to this name. This name should however also have .xz added at the end. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Is there any support for a Raspberry Pi camera in an openSUSE system?
Op donderdag 11 april 2019 13:59:16 CEST schreef Matthias Brugger: > On 10/04/2019 22:02, Freek de Kruijf wrote: > Well that give us at least some more hints. :) Hope you will find the culprit. > > Before installation of kernel-default-5.1.rc4-1.1.g1478096 I changed > > gpu_mem to 128, however it was back to 32 afterwards. So I changed it > > first to 128 and later 192 (max). Did not help. > > How did you changed it? What do you mean with "it was back to 32 > afterwards"? After installation of the new kernel the value of gpu_mem was set back to 32. It was not left alone, as I would expect. > > Regards, > Matthias -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Drop armv6 support?
Op donderdag 11 april 2019 09:29:21 CEST schreef Guillaume GARDET: > Hi all, > > do we have people still using openSUSE Tumbleweed on armv6 systems? Which is > Raspberry Pi 1, as it is the only armv6 board supported. > > Depending on the amount of users, we might consider to drop armv6 support > from Tumbleweed in the future. It would save build power in OBS and save > some people time, as there will be no more fixes to handle for armv6. > > Thanks, > Guillaume Yes, I still have three systems running Tumbleweed on Raspberry Pi 1B. The only access is via ssh. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Is there any support for a Raspberry Pi camera in an openSUSE system?
Op woensdag 10 april 2019 16:22:06 CEST schreef Matthias Brugger: > On 10/04/2019 12:36, Freek de Kruijf wrote: > > Op donderdag 4 april 2019 21:01:07 CEST schreef Freek de Kruijf: > >> I searched on the Internet for the answer. Did not find even the > >> question. > >> > >> Is there any support for a Raspberry Pi camera, bcm2835, on a Rasphberry > >> Pi > >> in an openSUSE system? > > > > Started with the latest Tumbleweed image for the Raspberry Pi 3B > > (aarch64). > > This one contains kernel version 4.20.13-1.1. > > Did find some information, even found that the kernel module bcm2835-v4l2 > > is present in the kernel-default package. > > Also found that gpu_mem in /boot/efi/config.txt needs to be at least 128. > > Did give the command "modprobe -i bcm2835-v4l2 which indeed loaded the > > module together with other modules. > > However got the warning: > > bcm2835_v4l2: module is from the staging directory, the quality is > > unknown, > > you have been warned. > > And the error messages: > > bcm2835-v4l2: error -1 while loading driver > > bcm2835-camera: probe of bcm2835-camera failed with error -1 > > I had a quick glance at the source and it is not clear to me where this > error comes from. You could try to install the kernel from our Kernel:HEAD > repository and retry: > https://download.opensuse.org/repositories/Kernel:/HEAD/ARM/ Still the same problem. Output: media: Linux media interface: v0.10 videodev: Linux video capture interface: v2.00 bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned. bcm2835_v4l2: vchiq_mmal_component_init: failed to create component -1 (Not enough GPU mem?) bcm2835-v4l2: bcm2835_mmal_probe: mmal init failed: -1 bcm2835-camera: probe of bcm2835-camera failed with error -1 Before installation of kernel-default-5.1.rc4-1.1.g1478096 I changed gpu_mem to 128, however it was back to 32 afterwards. So I changed it first to 128 and later 192 (max). Did not help. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Is there any support for a Raspberry Pi camera in an openSUSE system?
Op donderdag 4 april 2019 21:01:07 CEST schreef Freek de Kruijf: > I searched on the Internet for the answer. Did not find even the question. > > Is there any support for a Raspberry Pi camera, bcm2835, on a Rasphberry Pi > in an openSUSE system? Started with the latest Tumbleweed image for the Raspberry Pi 3B (aarch64). This one contains kernel version 4.20.13-1.1. Did find some information, even found that the kernel module bcm2835-v4l2 is present in the kernel-default package. Also found that gpu_mem in /boot/efi/config.txt needs to be at least 128. Did give the command "modprobe -i bcm2835-v4l2 which indeed loaded the module together with other modules. However got the warning: bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned. And the error messages: bcm2835-v4l2: error -1 while loading driver bcm2835-camera: probe of bcm2835-camera failed with error -1 After removing this module and installing it again I got: vchiq: module is from the staging directory, the quality is unknown, you have been warned. vchiq: vchiq_init_state: slot_zero = 0cb75000, is_master = 0 bcm2835_vchiq 3f00b840.mailbox: failed to set channelbase vchiq: could not load vchiq bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned. The visible result is that the device /dev/video0, which should appear, is not present. Is there anything I can do to improve the situation? -- 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
[opensuse-arm] Is there any support for a Raspberry Pi camera in an openSUSE system?
I searched on the Internet for the answer. Did not find even the question. Is there any support for a Raspberry Pi camera, bcm2835, on a Rasphberry Pi in an openSUSE system? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Latest Tumbleweed for Raspberry Pi 2 fails to boot
Op maandag 28 januari 2019 08:28:49 CET schreef Guillaume Gardet: > Hi, > > > -Original Message- > > From: Freek de Kruijf > > Sent: 26 January 2019 22:12 > > To: Mailinglist openSUSE ARM > > Subject: [opensuse-arm] Latest Tumbleweed for Raspberry Pi 2 fails to boot > > > > First I upgraded Tumbleweed on my RPi2, which gave me an system that > > does not boot anymore. > > I have the same problem with my Chromebook ARM which also uses kernel-lpae. > Did you reported this bug to bugzilla.opensue.org? Yes. https://bugzilla.opensuse.org/show_bug.cgi?id=1123350 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Latest Tumbleweed for Raspberry Pi 2 fails to boot
Op maandag 28 januari 2019 08:28:49 CET schreef Guillaume Gardet: > Hi, > > > -Original Message- > > From: Freek de Kruijf > > Sent: 26 January 2019 22:12 > > To: Mailinglist openSUSE ARM > > Subject: [opensuse-arm] Latest Tumbleweed for Raspberry Pi 2 fails to boot > > > > First I upgraded Tumbleweed on my RPi2, which gave me an system that > > does not boot anymore. > > I have the same problem with my Chromebook ARM which also uses kernel-lpae. > Did you reported this bug to bugzilla.opensue.org? No, not yet. Should I? > As a workaround, you can boot previous kernel (4.19.x) and install > kernel-default instead of kernel-lpae. I did not think of using the previous kernel. Instead I am using Leap 15.0 now on that system. Reinstalling the honeypot on it is not so much work. One of the messages after "zypper dup --no-r" was about the non existence of a file /boot/.../fonts/unicode.pf2. This file is in /boot/, so I created the fonts folder and a link to this file. Did not help. > @Andreas, could it be the EFI enablement for armv7 which could break lpae? > > Guillaume When a new image is available I will try to use Tumbleweed again. -- fr.gr. member openSUSE Freek de Kruijf P.S. No need to reply to my address; to the list is enough. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Latest Tumbleweed for Raspberry Pi 2 fails to boot
First I upgraded Tumbleweed on my RPi2, which gave me an system that does not boot anymore. After that I installed openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2019.01.08- Snapshot20190121.raw.xz on that system, which gives more or less the same problem. See the first few lines below. The output on the console is: [0.356882] Initramfs unpacking failed: junk in compressed archive [0.487556] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [0.495835] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [0.505224] Hardware name: BCM2835 [0.508660] [] (unwind_backtrace) from [] (show_stack+0x1c/0x28) [0.516411] [] (show_stack) from [] (dump_stack+0xac/ 0xd8) [0.523641] [] (dump_stack) from [] (panic+0x108/0x29c) [0.530612] [] (panic) from [] (mount_block_root+0x260/0x30c) [0.538099] [] (mount_block_root) from [] (prepare_namespace+0x158/0x1a0) [0.546628] [] (prepare_namespace) from [] (kernel_init_freeable+0x3f8/0x410) [0.06] [] (kernel_init_freeable) from [] (kernel_init+0x10/0x11c) [0.563775] [] (kernel_init) from [] (ret_from_fork+0x14/0x28) [0.571343] Exception stack(0xef12bfb0 to 0xef12bff8) [0.576394] bfa0: [0.584573] bfc0: [0.592750] bfe0: 0013 [0.599378] CPU2: stopping [0.602091] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [0.611479] Hardware name: BCM2835 [0.614890] [] (unwind_backtrace) from [] (show_stack+0x1c/0x28) [0.622637] [] (show_stack) from [] (dump_stack+0xac/ 0xd8) [0.629863] [] (dump_stack) from [] (handle_IPI+0x3f4/0x41c) [0.637261] [] (handle_IPI) from [] (__irq_svc+0x5c/ 0x94) [0.644394] Exception stack(0xef145f60 to 0xef145fa8) [0.649446] 5f60: 2dff7000 4093 e000 c1805dd4 c1805e1c 0004 [0.657625] 5f80: c171d558 c18f982f c1963ab8 ef145fb0 c043b948 c043b94c [0.665800] 5fa0: 4013 [0.669293] [] (__irq_svc) from [] (arch_cpu_idle+0x30/0x64) [0.676694] [] (arch_cpu_idle) from [] (do_idle+0x1fc/ 0x2a4) [0.684095] [] (do_idle) from [] (cpu_startup_entry+0x24/0x2c) [0.691670] [] (cpu_startup_entry) from [<0040326c>] (0x40326c) [0.698461] CPU3: stopping [0.701173] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [0.710561] Hardware name: BCM2835 [0.713970] [] (unwind_backtrace) from [] (show_stack+0x1c/0x28) [0.721718] [] (show_stack) from [] (dump_stack+0xac/ 0xd8) [0.728943] [] (dump_stack) from [] (handle_IPI+0x3f4/0x41c) [0.736342] [] (handle_IPI) from [] (__irq_svc+0x5c/ 0x94) [0.743474] Exception stack(0xef147f60 to 0xef147fa8) [0.748527] 7f60: 2e009000 4093 e000 c1805dd4 c1805e1c 0008 [0.756706] 7f80: c171d558 c18f982f c1963ab8 ef147fb0 c043b948 c043b94c [0.764880] 7fa0: 4013 [0.768373] [] (__irq_svc) from [] (arch_cpu_idle+0x30/0x64) [0.775772] [] (arch_cpu_idle) from [] (do_idle+0x1fc/ 0x2a4) [0.783172] [] (do_idle) from [] (cpu_startup_entry+0x24/0x2c) [0.790744] [] (cpu_startup_entry) from [<0040326c>] (0x40326c) [0.797532] CPU1: stopping [0.800243] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.20.0-1-lpae #1 openSUSE Tumbleweed (unreleased) [0.809632] Hardware name: BCM2835 [0.813042] [] (unwind_backtrace) from [] (show_stack+0x1c/0x28) [0.820790] [] (show_stack) from [] (dump_stack+0xac/ 0xd8) [0.828015] [] (dump_stack) from [] (handle_IPI+0x3f4/0x41c) [0.835414] [] (handle_IPI) from [] (__irq_svc+0x5c/ 0x94) [0.842546] Exception stack(0xef143f60 to 0xef143fa8) [0.847599] 3f60: 2dfe5000 4093 e000 c1805dd4 c1805e1c 0002 [0.855778] 3f80: c171d558 c18f982f c1963ab8 ef143fb0 c043b948 c043b94c [0.863952] 3fa0: 4013 [0.867446] [] (__irq_svc) from [] (arch_cpu_idle+0x30/0x64) [0.874845] [] (arch_cpu_idle) from [] (do_idle+0x1fc/ 0x2a4) [0.882244] [] (do_idle) from [] (cpu_startup_entry+0x24/0x2c) [0.889816] [] (cpu_startup_entry) from [<0040326c>] (0x40326c) [0.896622] Rebooting in 90 seconds.. [ 91.909884] Reboot failed -- System halted -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64) [ANSWERED]
I updated the wiki on Banana Pi M64, which shows how it is supported. Many thanks for the discussions. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
Op zaterdag 1 december 2018 16:59:44 CET schreef Freek de Kruijf: > Op zaterdag 1 december 2018 15:47:17 CET schreef Andreas Färber: > > Am 26.11.18 um 13:08 schrieb Freek de Kruijf: > > > I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, > > > and > > > started the Banana Pi M64 with it. It did boot, which I followed on the > > > serial console, USB-TTL serial cable. However the Ethernet device did > > > not > > > come up. > > Hi Andreas, > thanks for your answer. > > > Did you or did you not dd the M64 u-boot-sunxi-with-spl.bin file as I > > documented on the Wiki page? > > I did not. Didn't know where to find that file. > > > If you use the Pine64 bootloader and Device Tree, all kinds of things > > can go wrong. > > Apparently I am fine, except that when booting right after power on, the > Ethernet device does not come up. However a "shutdown -r now" does a reboot > and the device does come up. > > > > I did a reboot and now the Ethernet device comes up and gets addresses. > > > Also zypper ref works. > > > I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is > > > installed. There I also found u-boot-bananapim64, should that one be > > > installed? > > I just tried a "zypper in --download-only u-boot- > bananapim64-2018.11-95.1.aarch64" which conflicts with u-boot- > pine64plus-2018.11-95.1.aarch64. > I downloaded it using curl and got: > # rpm -ql u-boot-bananapim64-2018.11-95.1.aarch64.rpm > /boot/sunxi-spl.bin > /boot/u-boot-sunxi-with-spl.bin > /boot/u-boot.itb > /usr/share/doc/packages/u-boot-bananapim64 > /usr/share/doc/packages/u-boot-bananapim64/README > /usr/share/licenses/u-boot-bananapim64 > /usr/share/licenses/u-boot-bananapim64/gpl-2.0.txt > > > It doesn't matter which package is installed, it only matters which > > binary was written (dd'ed) to the right location on the SD card. > > So these above files in /boot are not used in the boot process? > > > Uninstalling u-boot-pine64plus is certainly a good idea to avoid > > mistakes, but installing u-boot-bananapim64 is only one way of obtaining > > the binary to dd onto the SD card. You could also extract the .rpm on > > another machine, using e.g. file-roller or command line tools. > > So I should move the above /boot/u-boot-sunxi-with-spl.bin to my desktop > system and dd that file with "dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX > bs=1024 seek=8" to the SD card? > This moves the content of that file to a location on the micro-SD which lies > before the sector 2048 on which /dev/mmcblk0p1 starts. Starts at sector 16? > > Regards, > > Andreas Tried another test SD card with your recipe on the wiki. Did work. So I also transferred u-boot-sunxi-with-spl.bin to the SD card I already did have running. Now the Ethernet interface comes up right away. Will update the wiki on how to get u-boot-sunxi-with-spl.bin. On the test SD I saw also the eMMC visible, however it not visible on my first SD which I am preparing for production. On this SD I removed kernel 4.19.2, now running 4.18.15-1. Just saw Tumbleweed 20181129 is available. Will install that system. Uses 4.19.4. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
Op zaterdag 1 december 2018 15:47:17 CET schreef Andreas Färber: > Am 26.11.18 um 13:08 schrieb Freek de Kruijf: > > I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, > > and > > started the Banana Pi M64 with it. It did boot, which I followed on the > > serial console, USB-TTL serial cable. However the Ethernet device did not > > come up. Hi Andreas, thanks for your answer. > Did you or did you not dd the M64 u-boot-sunxi-with-spl.bin file as I > documented on the Wiki page? I did not. Didn't know where to find that file. > If you use the Pine64 bootloader and Device Tree, all kinds of things > can go wrong. Apparently I am fine, except that when booting right after power on, the Ethernet device does not come up. However a "shutdown -r now" does a reboot and the device does come up. > > I did a reboot and now the Ethernet device comes up and gets addresses. > > Also zypper ref works. > > I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is > > installed. There I also found u-boot-bananapim64, should that one be > > installed? I just tried a "zypper in --download-only u-boot- bananapim64-2018.11-95.1.aarch64" which conflicts with u-boot- pine64plus-2018.11-95.1.aarch64. I downloaded it using curl and got: # rpm -ql u-boot-bananapim64-2018.11-95.1.aarch64.rpm /boot/sunxi-spl.bin /boot/u-boot-sunxi-with-spl.bin /boot/u-boot.itb /usr/share/doc/packages/u-boot-bananapim64 /usr/share/doc/packages/u-boot-bananapim64/README /usr/share/licenses/u-boot-bananapim64 /usr/share/licenses/u-boot-bananapim64/gpl-2.0.txt > It doesn't matter which package is installed, it only matters which > binary was written (dd'ed) to the right location on the SD card. So these above files in /boot are not used in the boot process? > Uninstalling u-boot-pine64plus is certainly a good idea to avoid > mistakes, but installing u-boot-bananapim64 is only one way of obtaining > the binary to dd onto the SD card. You could also extract the .rpm on > another machine, using e.g. file-roller or command line tools. So I should move the above /boot/u-boot-sunxi-with-spl.bin to my desktop system and dd that file with "dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8" to the SD card? This moves the content of that file to a location on the micro-SD which lies before the sector 2048 on which /dev/mmcblk0p1 starts. Starts at sector 16? > > Regards, > Andreas -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
Op maandag 26 november 2018 15:53:38 CET schreef Freek de Kruijf: > Op maandag 26 november 2018 13:08:36 CET schreef Freek de Kruijf: > > Op zondag 25 november 2018 22:53:41 CET schreef Andreas Färber: > > > > 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. > > > > I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, > > and > > started the Banana Pi M64 with it. It did boot, which I followed on the > > serial console, USB-TTL serial cable. However the Ethernet device did not > > come up. I did a reboot and now the Ethernet device comes up and gets > > addresses. Also zypper ref works. > > I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is > > installed. There I also found u-boot-bananapim64, should that one be > > installed? > > Also journalctl gives only lines of 80 characters and 40 lines. I > > installed > > xterm and used resize to give the command "COLUMNS=132;LINES=41;export > > COLUMNS LINES;", which solved that problem. Pleased with the results so > > far. > > > > Using IRC would be my first time. Will search how to use it. > > So far I failed to use IRC. Nickname is freek. Tried also using the > > Because the installed openssh-7.8p1-1.1 does not allow ssh access I replaced > it by openssh-7.9p1-198.1, which I found somewhere on OBS. > I also did a "zypper dup --no-r" which replaced kernel-default from 4.19.2-1 > to 4.18.15-1. Symbolic links in /boot all point to these new files. However > "uname -a" still shows "4.19.2-1-default". Anyway it works and it uses the > same aarch64 repository as for the Raspberry Pi 3B except for the u-boot... > package. Problem with 4.19.2 being booted is solved. It was and still is the preferred system in grub. I changed the preferred system to 4.18.15 using yast -> bootloader, however 4.19.2 is still the one that is booted by default. I have to select 4.18.15 in the Advanced setting in the grub screen to get this kernel. Still a problem with starting the system to get an Ethernet connection. Sometimes it works, mostly not. Need to "shutdown -r now" from the serial console to get eth0 up with the requested IP addresses. I search for this problem and found a solution to reload the driver, here dwmac_sun8i, with modprobe, but that did not work. Just need to do a reboot until the eth0 device comes up. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
Op maandag 26 november 2018 13:08:36 CET schreef Freek de Kruijf: > Op zondag 25 november 2018 22:53:41 CET schreef Andreas Färber: > > > 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. > > I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, and > started the Banana Pi M64 with it. It did boot, which I followed on the > serial console, USB-TTL serial cable. However the Ethernet device did not > come up. I did a reboot and now the Ethernet device comes up and gets > addresses. Also zypper ref works. > I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is > installed. There I also found u-boot-bananapim64, should that one be > installed? > Also journalctl gives only lines of 80 characters and 40 lines. I installed > xterm and used resize to give the command "COLUMNS=132;LINES=41;export > COLUMNS LINES;", which solved that problem. Pleased with the results so > far. > > Using IRC would be my first time. Will search how to use it. So far I failed to use IRC. Nickname is freek. Tried also using the Because the installed openssh-7.8p1-1.1 does not allow ssh access I replaced it by openssh-7.9p1-198.1, which I found somewhere on OBS. I also did a "zypper dup --no-r" which replaced kernel-default from 4.19.2-1 to 4.18.15-1. Symbolic links in /boot all point to these new files. However "uname -a" still shows "4.19.2-1-default". Anyway it works and it uses the same aarch64 repository as for the Raspberry Pi 3B except for the u-boot... package. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
Op zondag 25 november 2018 22:53:41 CET schreef Andreas Färber: > > 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. I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, and started the Banana Pi M64 with it. It did boot, which I followed on the serial console, USB-TTL serial cable. However the Ethernet device did not come up. I did a reboot and now the Ethernet device comes up and gets addresses. Also zypper ref works. I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is installed. There I also found u-boot-bananapim64, should that one be installed? Also journalctl gives only lines of 80 characters and 40 lines. I installed xterm and used resize to give the command "COLUMNS=132;LINES=41;export COLUMNS LINES;", which solved that problem. Pleased with the results so far. Using IRC would be my first time. Will search how to use it. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
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 suggest above is most likely beyond my capabilities to figure out without some detailed instructions. Maybe it gives some clue to you when I show the content of /dev/mmcblk0p1: bpim64tum:~ # ls -l /mnt total 24692 -rwxr-xr-x 1 root root 80 aug 29 2017 armbianEnv.txt -rwxr-xr-x 1 root root 1557 aug 29 2017 armbian_first_run.txt -
Re: [opensuse-arm] Question about support for Banana Pi (M64)
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. -- 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
[opensuse-arm] No ssh access to openSUSE Tumbleweed on Raspberrry Pi 1B
Recently I upgraded Tumbleweed on my Raspberry Pi 1B to the latest version. After that I am unable to access that system using ssh. I found that the problem is caused by upgrading openssh to version 7.8p1. The problem is solved in 7.9p1, which for other systems is available in OBS. However I could not find that version for armv6hl. Any information on that? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
Op vrijdag 19 oktober 2018 13:32:25 CEST schreef Freek de Kruijf: > Op vrijdag 19 oktober 2018 09:52:32 CEST 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? > > There are two images on https://dev.banana-pi.org.cn/Image/BPI-M64/ > 2017-08-29-openSUSE-Tumbleweed-ARM-MATE-desktop-demo-bpi-m64-aarch64-sd- > emmc.img.zip > and > 2017-08-29-opensuse-xfce-desktop-demo-bpi-m64-aarch64-sd-emmc.img.zip > > I could not find who created these images. Asked for information in the > BananaPi forum, but got no answer. > > I used the MATE image and was able to update the system to the latest > Tumbleweed version. However a new kernel and initrd was generated but was > not put on the boot partition. So a reboot worked but showed the old > kernel. The boot partition mmcblk0p1 is not mounted only the root partition > mmcblk0p2. I compared the new initrd and Image in /boot on the root > partition with the old one on the boot partition (mmcblk0p1) and did not > try to replace these files. > > The eMMC is shown on the debian system as /dev/mmcblk1. There are other > partitions /dev/mmcblk1boot0, /dev/mmcblk1boot1, /dev/mmcblk1p0 and /dev/ > mmcblk1p1. The first two are read-only, the second two are currently a small > fat32 partition (256M and a large ext4 partition (6.7G). Although the first > two share the text mmcblk1, they do not show up in fdisk -l /dev/mmcblk1 > > In some documentation I found a type of shell script which reads a file > uEnv.txt and at the end contains a load command which first loads something > like a dtb file, second a file initrd.img and third a file Image. In the > boot partition are folder with names 1080p, 480p, 720p, lcd5 and lcd7. In > these folders are three files all with the same name in each folder. The > names are bootlogo.bmp, sun50i-a64-bpi-m64-lcd5.dtb and uEnv.txt. uEnv.txt > contains parameter definitions for console, kernel_filename, > initrd_filename and fdt_filename of which only fdt_filename receives > different values in the different folders. Both kernel_filename and > initrd_filename point to files in the parent folder of these > > I assume that this type of shell script exists somewhere on the bootX > devices. I was wrong. This type shell script is in the boot partition (mmcblk0p1) of the openSUSE image. This partition looks quite different from the boot partition of the debian image. On the boot partition of the openSUSE image almost everything is in the top folder. There is only a dtb subfolder. On debian the real content starts in bananapi/bpi-m64/linux/ with the file Image etc. like mentioned before. The content of the shell script mentioned U-boot and also a command mkimage to generate images. On openSUSE I dont see a device /dev/mmcblk1, so the eMMC is invisible. > > 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 > > Do you want some more information on the openSUSE image? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Question about support for Banana Pi (M64)
Op vrijdag 19 oktober 2018 09:52:32 CEST 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? There are two images on https://dev.banana-pi.org.cn/Image/BPI-M64/ 2017-08-29-openSUSE-Tumbleweed-ARM-MATE-desktop-demo-bpi-m64-aarch64-sd- emmc.img.zip and 2017-08-29-opensuse-xfce-desktop-demo-bpi-m64-aarch64-sd-emmc.img.zip I could not find who created these images. Asked for information in the BananaPi forum, but got no answer. I used the MATE image and was able to update the system to the latest Tumbleweed version. However a new kernel and initrd was generated but was not put on the boot partition. So a reboot worked but showed the old kernel. The boot partition mmcblk0p1 is not mounted only the root partition mmcblk0p2. I compared the new initrd and Image in /boot on the root partition with the old one on the boot partition (mmcblk0p1) and did not try to replace these files. The eMMC is shown on the debian system as /dev/mmcblk1. There are other partitions /dev/mmcblk1boot0, /dev/mmcblk1boot1, /dev/mmcblk1p0 and /dev/ mmcblk1p1. The first two are read-only, the second two are currently a small fat32 partition (256M and a large ext4 partition (6.7G). Although the first two share the text mmcblk1, they do not show up in fdisk -l /dev/mmcblk1 In some documentation I found a type of shell script which reads a file uEnv.txt and at the end contains a load command which first loads something like a dtb file, second a file initrd.img and third a file Image. In the boot partition are folder with names 1080p, 480p, 720p, lcd5 and lcd7. In these folders are three files all with the same name in each folder. The names are bootlogo.bmp, sun50i-a64-bpi-m64-lcd5.dtb and uEnv.txt. uEnv.txt contains parameter definitions for console, kernel_filename, initrd_filename and fdt_filename of which only fdt_filename receives different values in the different folders. Both kernel_filename and initrd_filename point to files in the parent folder of these I assume that this type of shell script exists somewhere on the bootX devices. > > 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 Do you want some more information on the openSUSE image? -- 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
[opensuse-arm] Question about support for Banana Pi (M64)
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. 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. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Support for Banana Pi M64 and some experiments with Tumbleweed on it
Op woensdag 22 augustus 2018 18:13:20 CEST schreef Freek de Kruijf: > I experienced problems with the 1GB memory of the Raspberry Pi 3, so I went > to a Banana Pi M64, which has almost the same specifications as the RPi3, > except it has 2 GB memory, and it uses a slightly different CPU. I even > found an image to run openSUSE Tumbleweed on it from a year ago. The image > used the same repository as the repository for the RPi3 (aarch64). However > upgrading to a newer version of Tumbleweed failed. As far as I could see > the only issue is a slightly different kernel and boot system. > > Currently I am trying to implement my services on it using Debian Stretch. > > I would very much like to use openSUSE on it, because I am more familiar > with it. Debian is quite different, both in managing packages as in > configuration of the services. > > If I can be of assistance in implementing openSUSE on a Banana Pi M64 I am > quite willing to do that. Don't know if I have the necessary knowledge. The problems I was facing stem from a bad micro-SD card. Now I am using a proper one and used the above mentioned Tumbleweed image for the Banana Pi M64 dated about a year ago. It uses the Tumbleweed aarch64 repository for the Raspberry Pi 3. I was able to upgrade the system even a new kernel was installed. However the system uses still the old kernel 4.13.0. I notice that /dev/mmcblk0p1, from which the system is booted, is not mounted on /boot. In fact it is not mounted at all. Most likely this is the best option. When executing mkinird I see two new systems generated for versions 4.11.8-2-default and 4.17.14-2-default. However there are missing firmware kernel modules: isight.fw, aic94xx-seq.fw, wd719x- risc.bin, wd719x-wcs.bin, sd8688.bin, sd8688_helper.bin, sd8686.bin, sd8686_helper.bin, sd8385.bin, and sd8385_helper.bin. Another issue is that at start the root partition on the micro-SD card is using almost all its initial space. So either one has to remove a lot of the installed packages or enlarge the partition. Finally I found this is quite easy using fdisk and partprobe. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: Control output pin on RPi
Op woensdag 5 september 2018 11:06:28 CEST schreef Alexander Graf: > On 05.09.18 11:00, Volker Kuhlmann wrote: I did generate rpm's in the beginning of this year for armv6hl, armv7hl, and aarch64 on openSUSE Tumbleweed, using the source file RPi.GPIO-0.6.3.tar.gz with my own patches to overcome the problem with a non-zero in gpiochip, both for Python 2 and 3. So in total 6 files. I did this on my three different RPi's. I am using only the Python 2 version on a RPi A (armv6hl). I do have patch files and the .spec file to build these packages with rpmbuild. I assume these rpm's are usable on other versions of openSUSE or even on other OSes. With these rpm packages you can use the examples for Python to manipulate pins and to run some action on an event that occurred on a pin. The library also provides two types of pin mapping. See the documentation. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Control output pin on RPi
Op dinsdag 4 september 2018 04:51:25 CEST schreef Volker Kuhlmann:
> > File "/usr/lib/python3.6/site-packages/gpiozero/pins/local.py", line
> > 67, in _get_revision>
> > raise PinUnknownPi('unable to locate Pi revision in /proc/cpuinfo')
> >
> > gpiozero.exc.PinUnknownPi: unable to locate Pi revision in /proc/cpuinfo
>
> Hardcoding the version into the python2 file
> /usr/lib/python2.7/site-packages/gpiozero/pins/local.py
>
> exits with I/O error on /dev/mem when the few lines of python are run as
> user (ok fine), and segfaults when run as root.
>
> Volker
Sometime ago I needed to read input on a GPIO pin. I found a problem in the
kernel of openSUSE to access these pins compared to what is documented for
Python in Raspbian.
The problem is apparent when you do "ls /sys/class/gpio/". At least you need
to see gpiochipN there, where N is some number. On my Raspberry Pi A with
openSUSE it is 298. Raspbian has 0.
The Python library RPi.GPIO needs to use this N to address the right pin. This
also means that the right /sys/class/gpio/gpioM needs to be used for a certain
pin.
--
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
[opensuse-arm] Support for Banana Pi M64
I experienced problems with the 1GB memory of the Raspberry Pi 3, so I went to a Banana Pi M64, which has almost the same specifications as the RPi3, except it has 2 GB memory, and it uses a slightly different CPU. I even found an image to run openSUSE Tumbleweed on it from a year ago. The image used the same repository as the repository for the RPi3 (aarch64). However upgrading to a newer version of Tumbleweed failed. As far as I could see the only issue is a slightly different kernel and boot system. Currently I am trying to implement my services on it using Debian Stretch. I would very much like to use openSUSE on it, because I am more familiar with it. Debian is quite different, both in managing packages as in configuration of the services. If I can be of assistance in implementing openSUSE on a Banana Pi M64 I am quite willing to do that. Don't know if I have the necessary knowledge. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Which packages for yast2?
Op dinsdag 21 augustus 2018 14:35:32 CEST schreef Andreas Färber: > Am 21.08.2018 um 13:45 schrieb Volker Kuhlmann: > > On Tue 21 Aug 2018 23:11:52 NZST +1200, Axel Braun wrote: > >> For sure, if you install the qt component, there will be a bunch of > >> dependencies behind. > > > > Yes, but plotting software and a postscript interpreter - for a GUI, for > > a program hat already has the equivalent ncurses functionality > > installed?!??? > This YaST discussion has little to do with arm. If you want to complain > about general packaging, try opensuse-factory list. > > As Guillaume pointed out, this is most likely due to recommended rather > than required packages. > > Cheers, > Andreas On https://en.opensuse.org/HCL:Raspberry_Pi you may find more information on how to use YaST on your RPi. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] How to get openSUSE aarch64 on a RPi3B+?
Op zondag 29 juli 2018 17:20:32 CEST schreef Sten Bert: > Alex - thank you for your little hints, > > /dev/sdf1 was choosen, 'cause /dev/sdf got me into the rainbow-screen > (desperately!) > After dd-ing the card automount(?) gets me 2 mounts in the filemanager: > ROOT, EFI. What else should I do, than umount them? > (openSUSE-Leap42.3-ARM-JeOS-raspberrypi3.aarch64-2017.07.26-Build1.1.raw.xz) > The filesystem isn't destroyed, when I look a the card the next time. > >>I have a perfectly running system with this image. Indeed /dev/sdf1 > > needs to be /dev/sdf, there will be two partitions on the SD card and a > lot of unused space.<< > > Freek - are you talking about the RPi3b+? > I have the actual (this year - 2018) board RPi3B+ and I'm looking for an > (openSUSE!)image, that at least boots this board! > From http://download.opensuse.org/ports/aarch64/ I took different > xz-Images (15.0 JeOS, 15.0 LXQT, 42.3 JeOS). - They all produce > different sd-card partition layouts! But none of them boots a RPi3B+! No I wasn't. Sorry I missed the + in your subject. Still you always have to dd to the whole disk, so /dev/sdf; not /dev/sdf1, when you use an image. If I understand the message from Andreas correctly, you can use the image for Tumbleweed or Leap 15.0, which you apparently already have. However after dd- ing, you do "mount /dev/sdf1 /mnt". In /mnt/ there is a file extraconfig.txt or you create that file and enter a line "arm_control=0x200", most likely without the "'s. After "umount /mnt", you put the SD in the RPi3B+ and boot. That should do the trick. Good luck. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] How to get openSUSE aarch64 on a RPi3B+?
Op vrijdag 27 juli 2018 11:19:40 CEST schreef Sten Bert: > Freek, > > Unfortunally - no success! > Her'e my outputs: I have a perfectly running system with this image. Indeed /dev/sdf1 needs to be /dev/sdf, there will be two partitions on the SD card and a lot of unused space. After the "xzcat .. | dd .." I mount /dev/sdf2 and do already some configuration on that partition. However I do not touch the partitioning on the SD card. That will be done after the first boot. After this first boot there will be a third partition (swap; about 500 MB) at almost the end of the card and the second partition (ext4) will take the rest of the space on the card. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] How to get openSUSE aarch64 on a RPi3B+?
Op donderdag 26 juli 2018 17:14:38 CEST schreef Sten Bert: > Thank you for the fast reply! > Of course. - But that was the only path that was working rudimental and > promised a similar way as on x86-PC. > The section marked as(easiest)dind't work at all- rainbow screen! > Maybe there's a hint missing about the preparation of the sd-card? You may need to clear the highest blocks on the SD card. I use in bash: dev=sdX 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 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] resize the swap partition
Op dinsdag 24 juli 2018 15:01:10 CEST schreef Xavier Primer: > Hi, > > I'm newbie in openSUSE ... > > I'm running openSUSE on Raspberry Pi 3 machine. > > How can I resize the swap partition ? > > Thanks, see you. I use next to the swap partition on the RPi3 a swap file. You create the file using: fallocate --length ?MiB /var/swapfile /var/swapfile can be any path to a file, replace ? with the required size. I use 512. Initialize the file using mkswap /var/swapfile If you need the swap space occasionally you can can use: swapon /var/swapfile otherwise make an entry in /etc/fstab like: /var/swapfile none swap sw 0 0 mount -a will mount the swapfile right after creation, otherwise it will be made available in the boot process. You can inspect the swap space using: swapon --bytes -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Rasberry Pi 3B image openSUSE Tumbleweed starts on Banana Pi M64
Op zondag 22 juli 2018 21:31:22 CEST schreef Freek de Kruijf: > Op zondag 22 juli 2018 20:35:57 CEST schreef Andreas Färber: > > If apparently you have the bootloader on eMMC instead of SD, you can use > > the generic JeOS-efi.aarch64 image, for instance. > > Which one? I see the JeOS-efi.aarch64 install version and the normal > version. Should I put the openSUSE boot image on the eMMC and how? I tried the version without install in its name at no avail. > The reason to ask is that "uname -a" shows the Debian kernel name. The root > partition is on the SD. With "yast partitioner" I can enlarge the root > partition and create a swap partition on the SD. I leave the eMMC alone. After searching I found two version for the BPiM64 based on openSUSE Tumbleweed dated 2017-08-29. One with MATE and one with XFCE in its name. Tried the XFCE which did boot OK. Did not use the boot system on the eMMC. However the eMMC is not visible in the system. Tried a "zypper dup --no-r", but that failed. Currently trying the MATE version with more careful upgrading the system. Boots OK without using anything on the eMMC. Removed already a lot of MATE, XFCE and GNOME. I need the system only with basic types of software, no desktop stuff. Also the cautious upgrade resulted in a failure. Maybe I have to stick with the Debian system for my server. Asked on the BPi forum how to build a newer openSUSE Tumbleweed version. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Rasberry Pi 3B image openSUSE Tumbleweed starts on Banana Pi M64
Op zondag 22 juli 2018 20:35:57 CEST schreef Andreas Färber: > Am 22.07.2018 um 13:26 schrieb Freek de Kruijf: > > Instead of a Banana Pi M3 I got a Banana Pi M64, of which I was uncertain > > that the processor was the same as the one on a Raspberry Pi 3B. > > It is not. Allwinner vs. Broadcom. > > > My experiments with it will be continued, but if you have any advice I > > will be happy to receive it. > > My advice: Don't do that. Use a proper image, don't reuse Raspberry Pi > images on non-Raspberry-Pi boards. Same for most other boards, but the > Raspberry Pi uses a special MBR partitioning whereas you want GPT here. > Not to mention "wrong" bootloader packages. > > If apparently you have the bootloader on eMMC instead of SD, you can use > the generic JeOS-efi.aarch64 image, for instance. Which one? I see the JeOS-efi.aarch64 install version and the normal version. Should I put the openSUSE boot image on the eMMC and how? The reason to ask is that "uname -a" shows the Debian kernel name. The root partition is on the SD. With "yast partitioner" I can enlarge the root partition and create a swap partition on the SD. I leave the eMMC alone. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Rasberry Pi 3B image openSUSE Tumbleweed starts on Banana Pi M64
Op zondag 22 juli 2018 13:26:02 CEST schreef Freek de Kruijf: > Instead of a Banana Pi M3 I got a Banana Pi M64, of which I was uncertain > that the processor was the same as the one on a Raspberry Pi 3B. Still I > did put the image for the Raspberry Pi 3B (aarch64) on a micro-SD card and > booted the BPi. I was very happy to see the system came alive. > > Before this I did put the Debian image on the eMMC and was able to boot that > system without a micro-SD card. On this system I inserted the micro-SD with > the above mentioned openSUSE system, which came alive. The initialization > of the system was not completely as it should be. There was no swap at the > end of the micro-SD card and the root partition was not enlarged. I did put > the swap on the eMMC, effectively erasing what was there and enlarged the > root partition on the micro-SD. > > However after that I did a "zypper dup --no-recommends" and did a reboot. > The system does not start anymore. > > My experiments with it will be continued, but if you have any advice I will > be happy to receive it. Left the eMMC with Debian untouched and now I have a working updated Tumbleweed system after "zypper dup --no-r" and a reboot. However "uname -a" reports the Debian BPI kernel name. -- 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
[opensuse-arm] Rasberry Pi 3B image openSUSE Tumbleweed starts on Banana Pi M64
Instead of a Banana Pi M3 I got a Banana Pi M64, of which I was uncertain that the processor was the same as the one on a Raspberry Pi 3B. Still I did put the image for the Raspberry Pi 3B (aarch64) on a micro-SD card and booted the BPi. I was very happy to see the system came alive. Before this I did put the Debian image on the eMMC and was able to boot that system without a micro-SD card. On this system I inserted the micro-SD with the above mentioned openSUSE system, which came alive. The initialization of the system was not completely as it should be. There was no swap at the end of the micro-SD card and the root partition was not enlarged. I did put the swap on the eMMC, effectively erasing what was there and enlarged the root partition on the micro-SD. However after that I did a "zypper dup --no-recommends" and did a reboot. The system does not start anymore. My experiments with it will be continued, but if you have any advice I will be happy to receive it. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Images for Banana Pi M3 available?
Op zondag 15 juli 2018 15:44:33 CEST schreef Stefan Brüns: > On Sonntag, 15. Juli 2018 15:24:25 CEST Freek de Kruijf wrote: > > Apparently there are images for Tumbleweed and Leap 15.0 for the Banana Pi > > M2. > > > > Question: Are there also images for the Banana Pi M3 or should the images > > for Raspberry Pi 3B also work for this device? > > TLDR: no > > M3 uses an Allwinner A83T, an 32 bit ARM processor with 8 cores. > > RPi3 uses a Broadcom BCM2837, a 64 bit ARM processor with 4 cores. > > For booting, you need a board specific image (unless you have one of the few > boards which use UEFI, but these typically come in a case ready for > deployment in you data center). > > The userland is the same for all boards with a common architecture, but 32 > and 64 bit ARM are different. > > Kind regards, > > Stefan Thanx Stefan, Still the question remains: is there is an openSUSE image for this device? In the ARMv7 series? -- 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
[opensuse-arm] Images for Banana Pi M3 available?
Apparently there are images for Tumbleweed and Leap 15.0 for the Banana Pi M2. Question: Are there also images for the Banana Pi M3 or should the images for Raspberry Pi 3B also work for this device? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Is there any support for the Raspberry Pi Camera in an openSUSE image/repository?
Op maandag 25 juni 2018 14:25:02 CEST schreef guillaume.gar...@free.fr: > Hi, > > ----- Freek de Kruijf a écrit : > > The question says it all! > > > > Is there any support for the Raspberry Pi Camera in an openSUSE image/ > > repository? > > I think we have support for it but never tried myself. Is it for RPi 1, 2 or > 3? I have for all three a spare system, so whatever works is OK. > Do you have an error? For Raspbian I found to enter start_x=1 and gpu_mem=128 in config.txt or rather extraconfig.txt. However I could not find anything about the camera in the my RPi3 system with openSUSE Tumbleweed after entering these lines. > Guillaume -- 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
[opensuse-arm] Is there any support for the Raspberry Pi Camera in an openSUSE image/repository?
The question says it all! Is there any support for the Raspberry Pi Camera in an openSUSE image/ repository? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Problem running python script using GPIO
Op donderdag 14 juni 2018 21:06:03 CEST schreef Freek de Kruijf: > Op donderdag 14 juni 2018 17:56:41 CEST schreef Brüns, Stefan: > > On Donnerstag, 14. Juni 2018 17:50:56 CEST Alexander Graf wrote: > > > 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 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. > > > > Unfortunately the RPi foundation kernel is patched to hardcode the offset > > to 0, so any of these simplistic wrappers only work with the foundation > > kernel, but not with the upstream kernel, or on any other boards. > > This made me think about a patch I made to generate a proper version og > RPi.GPIO for openSUSE, which is needed to compensate for the fact that > raspbian uses gpiochip0, where as you can see above, openSUSE uses a > non-zero value, namely 298. > > To get the RPi.GPIO packet I used pip, which is apparently a version that > assumes gpiochip0. > > I inspected build.opensuse.org and found that in the project hardware / > python-RPi.GPIO the patch is included. However generating it for armv6l, > armv7l, and aarch64 in openSUSE_Factory_ARM is disabled. It is not mentioned > for these architectures for Leap 42.3 and 15.0 and for Tumbleweed. > > Could this be enabled, such that the package appears in a repository, > preferably the standard repository for Leap 42.3, 15.0 and Tumbleweed? Some time ago I already generated versions for the three architectures and for python 2 and 3. Must have slipped my older brain. I did a "pip uninstall RPi.GPIO" and installed my packet for python2 and armv6hl. Problem solved for me. Two years ago I already made a ticked for the product on sourceforge providing the patch, which should also work for /sys/class/gpio/gpiochip0 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Problem running python script using GPIO
Op donderdag 14 juni 2018 17:56:41 CEST schreef Brüns, Stefan: > On Donnerstag, 14. Juni 2018 17:50:56 CEST Alexander Graf wrote: > > 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 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. > > Unfortunately the RPi foundation kernel is patched to hardcode the offset to > 0, so any of these simplistic wrappers only work with the foundation > kernel, but not with the upstream kernel, or on any other boards. This made me think about a patch I made to generate a proper version og RPi.GPIO for openSUSE, which is needed to compensate for the fact that raspbian uses gpiochip0, where as you can see above, openSUSE uses a non-zero value, namely 298. To get the RPi.GPIO packet I used pip, which is apparently a version that assumes gpiochip0. I inspected build.opensuse.org and found that in the project hardware / python-RPi.GPIO the patch is included. However generating it for armv6l, armv7l, and aarch64 in openSUSE_Factory_ARM is disabled. It is not mentioned for these architectures for Leap 42.3 and 15.0 and for Tumbleweed. Could this be enabled, such that the package appears in a repository, preferably the standard repository for Leap 42.3, 15.0 and Tumbleweed? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Problem running python script using GPIO
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 -- 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
