Re: [opensuse-arm] Leap 15.2 image
On Mon, Feb 24, 2020 at 12:55:05PM +0100, Matthias G. Eckermann wrote: > Hello Axel, > > On 2020-02-24 T 11:41 +0100 Axel Braun wrote: > > Am Sonntag, 23. Februar 2020, 22:36:33 CET schrieb Matthias G. Eckermann: > > > On 2020-02-23 T 17:03 +0100 Axel Braun wrote: > > > > > Except that I feel that one should not use btrfs on a 32GB > > > > SD card > > > > > > one of the reasons to use btrfs for the RPi image (I know > > > that at least for SUSE Linux Enterprise) is that it is > > > compressed and thus the low IO-throughput of the SD card > > > interface is accelerated; assuming a compression rate for > > > the OS part of more than 30%, the performance factor should > > > be similar for reads and writes. > > > > Thanks for the information! > > > > So the old rule (i remember some discussions on the factory > > mailing list from some time ago) that btrfs on less than 40GB > > is not recommended, is not valid any longer? > > well. I would have never called this "40GiB" a "rule", but more > a "recommendation" for a btrfs root filesystem *with* snapshots > enabled, and this recommendation has a *lot* of safety buffer > included. > > Mind that this heavily depends on the > - distribution > and > - your personal way of applying updates. > > To add some details: > > * For a Tumbleweed with add-hoc updates enabled, I would > rate 40 GiB the lower limit, indeed, better more, as > you have a lot of change, thus lots of snapshots and > lots of metadata. > > * For a Leap or SUSE Linux Enterprise with, let's say, > planned weekly updates, you can easily work with a > btrfs filesystem as small as twice the size of the OS > installation, or for an extra buffer three times: > > MINIMAL_SIZE=$(( 3* $( du -msx / | cut -d'/' -f1) )) > > I personally run (all my) systems with a 32 GiB root > filesystem with snapshots enabled, and the number of > snapshots limited to 8 in total. > > That said, for a Raspberry Pi and an SD card, I would recommend > to apply updates rather carefully and not in tumbleweed style, > because the SD card might not like this too much:-/ Thus, a > 32 GiB filesystem (with compression enabled this is equivalent > to 42 GiB or more effectively) should be very comfortable. To move even closer to a real sytem: I'm running btrfs on 12GB https://build.opensuse.org/package/show/home:duwe:Teres-I/Teres-I-image without snapshotting, and it "works". In quotes because I have not done comparisons or even benchmarks vs. f2fs or ext4. Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Re: New 32-bit Arm support needed for future OBS builds
On Wed, Feb 05, 2020 at 03:15:28PM +, Guillaume Gardet wrote: > > No, that is the problem. With newer hardware, this option will be gone as > 32-bit mode will not be supported in kernel mode, so qemu/kvm cannot run > armv7 kernel. Are you sure about this? I mean, those cores will not be able to run 32-bit kernels natively, sure, but my (maybe outdated) information is that kvm always runs guest code in "user mode" and faults on privileged instructions, which are then emulated anyway. Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Pimoroni pHAT DAC on Raspberry Pi 3
On Tue, 3 Dec 2019 00:40:29 +0100 Stefan Brüns wrote: > On Montag, 2. Dezember 2019 22:02:38 CET Richard MQ wrote: > > > Is this because I have a pcm5102 not a 5122? Or just that the > > address (0x4d) is incorrect? > > A short glimpse at the datasheet reveals the pcm510x is dumb and has > no I2C interface at all. > > Just use the hifiberry-dac DT overlay contents, look for the > hifiberry-dac- overlay.dts And https://learn.pimoroni.com/tutorial/phat/raspberry-pi-phat-dac-install says: " #dtparam=audio=on " Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Pimoroni pHAT DAC on Raspberry Pi 3
On Mon, 25 Nov 2019 20:15:26 +
Richard MQ wrote:
> And I already knew about /boot/efi/extraconfig.txt and had
> dtoverlay=hifiberry-dacplus to no avail, I have pre-pended
> dtparam=i2s=on as suggested but still no dice (nothing shows up in
> hwinfo, nor Yast - Sound Card)
>
> @Torsten - please can you advise where to configure the strings and
> addresses that you mention?
Accessing the little box, which has been running happily for quite some
time now, I hope I can remember the tweaks I had to do back then:
It is a RPi Zero W, with a "justboom amp zero" pHAT. The point is,
no overlay matched it exactly back then so I chose a compatible chip
from the "iqaudio-dac" and fixed the I2C address, IIRC.
config.txt has:
---
dtoverlay=iqaudio-dac
dtparam=audio=on
dtparam=i2c0=on
dtparam=i2c1=on
The overlay produces in my fdt:
i2c@7e804000 {
compatible = "brcm,bcm2708-i2c";
[...]
pcm5122@4d {
status = "okay";
reg = <0x4d>;
compatible = "ti,pcm5122";
#sound-dai-cells = <0x0>;
};
The kernel loads snd_soc_pcm512x_i2c and dmesg yields:
snd-rpi-iqaudio-dac soc:sound: pcm512x-hifi <-> 20203000.i2s mapping ok
hifiberry-dacplus already has an overlay that should work out of the
box, in theory.
Torsten
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Pimoroni pHAT DAC on Raspberry Pi 3
On Mon, Nov 25, 2019 at 10:59:01AM +, Guillaume Gardet wrote: > Hi, > > > -Original Message- > > From: Richard (MQ) > > Sent: 25 November 2019 11:42 > > To: opensuse-arm@opensuse.org > > Subject: [opensuse-arm] Pimoroni pHAT DAC on Raspberry Pi 3 > > > > Hi All > > > > Has anyone had any luck getting Pimoroni accessories such as "pHAT DAC" > > working on Raspberry Pi 3 under recent opensuse images? This is a PCM5102A > > DAC connected via I2S interface, the Pimoroni instructions are specific to > > Raspian. > > I think you need to create/update /boot/efi/extraconfig.txt file to enable > I2S and select the right DAC: > dtparam=i2s=on > dtoverlay=hifiberry-dacplus Oh yes. And additional pitfalls here are the exact compatible string (there is some variety of these audio hats, with subtle differences) and the DACs/ AMPs i²C address. BTDT. Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ?
On Fri, 08 Mar 2019 18:19:13 +0100 Per Jessen wrote: > > https://patchwork.kernel.org/patch/10836377/ > > > > for the broadcom. > > Thanks Torsten, I'll have a look. Ok, you have the driver and the DT node, as proven by the kernel message in your first mail, so forget my previous remarks. drivers/mailbox/mailbox.c creates an internal device, but I see no consumers besides rpi-firmware. As Guillaume has already noted, downstream had created a device node here, which is lacking upstream. Do you have a platform device named "raspberrypi-hwmon"? Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ?
On Fri, 8 Mar 2019 18:05:44 +0100 Torsten Duwe wrote: > On Fri, 08 Mar 2019 17:11:21 +0100 > Per Jessen wrote: > > whatever it is that provides that interface. > > A similar patch set has been submitted for sunXi this week. Look > for code that looks like > > https://patchwork.kernel.org/patch/10836377/ > > for the broadcom. 4.20 has drivers/mailbox/bcm2835-mailbox.c. It looks for "brcm,bcm2835-mbox" in the DT. Do you have that? Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] /dev/vcio for accessing the raspi "mailbox" ?
On Fri, 08 Mar 2019 17:11:21 +0100 Per Jessen wrote: > Guillaume Gardet wrote: > > I think /dev/vcio is a downstream feature only. So, not available on > > openSUSE kernel which uses upstream kernels. > > > > Thanks Guillaume > > so, what do I need to do to talk to the raspi mailbox? I tried > creating /dev/vcio myself (majornum 100), but I'm clearly missing That's definitely the wrong way. This can only work around a broken driver that somehow does not trigger udev. > whatever it is that provides that interface. A similar patch set has been submitted for sunXi this week. Look for code that looks like https://patchwork.kernel.org/patch/10836377/ for the broadcom. Torsten > > -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Raspberry Pi 3 B+ ?
On Fri, Mar 01, 2019 at 01:59:36PM +0100, Per Jessen wrote: > I have just acquired two of these, one for my son's school project, one > for our mediacentre. Using the KDE appliance, it boots up fine, but as > soon as I start setting up the wifi, it crashes. Then I tried usig > yast to set date - crash. Are they equipped with _appropriate_ power supplies? RPi3 is said to have higher demands than just an ordinary 5V/2.5A plugger. Some shops sell 3.0 amps minimum, others swear by raising Vout to 5.2V. My assumption is those rascals like to demand sudden current bursts, e.g. when certain peripherials kick in or the CPU gets to do some work. For the media centre you might want to look at libreELEC, for a comparison, just to see whether that runs stable. OTOH it's only 32-bits wide :-P https://libreelec.tv/downloads_new/raspberry-pi-3-3/ Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Olimex Teres-I boots openSUSE
Hi all! just to let you know I got all the neccessary pieces together now to boot an unmodified kernel with a sort-of mainline U-Boot with some hacks on the open source hardware laptop Teres-I https://www.olimex.com/Products/DIY-Laptop https://linux-sunxi.org/Olimex_Teres-A64 My first goal was to use the same device tree for U-Boot and kernel, and getting the hardware I²C to work was the biggest task. It allows the use of i2c0 to enable the built-in LCD in the boot loader. As a weird side effect, this mysteriously breaks the WiFi; any pointers welcome! With the LCD working, U-Boot provides an EFI frame buffer to the kernel, and the kernel messages appear until user land is started. This is all work in progress and I need to find out how the hacks could fit into the upstream trees cleanly, but I thought you might be interested in the progress already made. You can have a look at the current status in OBS:/home:duwe:branches:hardware:boot:staging Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
