Re: Debian Bookworm+ on Cavium ThunderX?
On Fri, 2024-04-12 at 09:28 +0200, Steffen Grunewald wrote: > Upgrading to Debian Buster was successful, the current kernel is 4.19.0-25 > aka 4.19.289-2. (It doesn't even properly identify the CPU, only gives a > BogoMIPS value of 200.00.) > > Any attempt to boot a Bullseye (5.x) or Bookworm kernel (6.x) resulted in > an early kernel panic. Try the latest sid kernel (6.7.9) and the latest upstream too. This sounds like something that will need a git bisect to figure out though. https://wiki.debian.org/DebianKernel/GitBisect -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Nouvel employé
On Thu, 2024-01-04 at 12:59 -0500, ges...@ftp83plus.net wrote: > Ceci n’est pas une entreprise. C’est une liste de diffusion destinée > à mettre en relation les utilisateurs et des développeurs de Debian > sur des sujets variés. Tous participent bénévolement en fonction de > leurs compétences. The mail you have responded to is one of the few spams that pass our mailing list filters, please avoid replying to spam in future. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems
On Sat, 2023-09-09 at 11:42 +0200, Bastian Blank wrote: > The first one is the one with included size limitations, because those > load the kernel from a pre-defined flash partition, whose size can't be > easily changed by the user. This one is now overflowing for the second > to last documented one in the kernel package config. Seems like this would be solvable by writing a bootloader to the flash partition that would be able to load Linux from a normal filesystem? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Installation of debian unstable on Lenovo IdeaPad 5G 14Q8X05
On Mon, 2023-09-04 at 05:32 +, alfredo.nodo wrote: > the latest version of kernel 6.5 supports the Lenovo Flex 5G SoC > SC8180X https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5. I > have a Lenovo IdeaPad 5G 14Q8X05 with SoC SC8180XP which is the > evolution of the Flex one with the same CPU-GPU, but at higher > frequency, with BT 5.1 and WiFi 6 instead of BT 5 and WiFi 5. Do you > think it will work? If not, are you going to add support for > SC8180XP? I suggest you contact the SC8180X Linux kernel contributors about it: https://lore.kernel.org/r/20230815142042.2459048-1-anders...@kernel.org -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Cubox-i bullseye -> bookworm Upgrade failure
On Fri, 2023-08-04 at 10:55 +0300, Reco wrote: > Enjoy your (un)Predictable Interface Names. > Try adding "net.ifnames=0" to kernel's commandline. Personally, I would switch away from hardcoding interface names. ifupdown can do interface name wildcards and mac matching. The other solutions for this problem (systemd-networkd, NetworkManager, ifupdown-ng, probably ifupdown2) are much more flexible though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, 2023-06-20 at 22:46 +0200, Kurt Roeckx wrote: > Can I suggest that if you file a few bugs and add some information in > it so that maybe someone can look at it? If it only affects one > architecture, send a mail to that list asking for help. PS: when filing architecture-specific bugs, please also set the BTS usertags and XCC the ports lists for the architectures effected. https://wiki.debian.org/Teams/Debbugs/ArchitectureTags -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Mon, 2023-05-08 at 12:15 +0100, James Addison wrote: > I'd like to understand what is the approach that provides the most > compatibility and free software support with the fewest moving parts. > To me, the reliability and human-time cost savings from simpler, more > open and straightforward systems outweigh many other factors, > especially over the long term. As an end user, what I would like is everything above the CPU bootrom should be open source, packaged within Debian main and auto-updated on the appropriate schedule considering flash longevity and update types. u-boot probably comes closest to that, although blobs are required on some platforms, vendor forks are numerous and updates are manual only. EDK2 is similar but worse because edk2-platforms is not available in Debian and devices run eventually abandoned proprietary EDK2 forks. ACPI comes from the world of proprietary non-redistribable vendor firmware (some EDK2 forks) provided separately to the operating system. > On Fri, 5 May 2023 at 12:52, Pete Batard wrote: > > > The Raspberry Pi SoC has also some very non-free code running > > Yep, I've still got quite a lot to learn about that, I think. The LibreRPi folks are working on replacing that: https://github.com/librerpi/lk-overlay/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)
On Mon, 2023-04-17 at 22:21 -0700, Rick Thomas wrote: > What would have been even greater is if the error messages include > references to some documentation that explained the problem and gave > some clues to the larger context in which the problem arose. The messages I sent that patch adding are for very simple issues; "/proc not mounted", "/sys not mounted" and "i2c-dev not loaded" and since they all have very simple solutions, I just added the commands to fix them instead of pointers to documentation about each error. Probably the i2c manual pages should get some links to the Linux kernel documentation and wiki for I2C. I'm unlikely to work on that though, hopefully someone else is willing to do that. > For example, I'd like to know why it chose bus3 rather than one of > the other busses (0,1,2,4)? I expect that depends on the bus driver code for your device, those do not seem to document their ordering though and it looks like your particular i2c bus driver has no documentation. https://www.kernel.org/doc/html/latest/i2c/busses/index.html > I'd also like to know what the various modules do and what kinds of > parameters there are to influence the detailed behavior? Looks like the devices are defined by DeviceTree, ACPI, board files, dynamically by drivers for other devices, hardware probing or sysfs: https://www.kernel.org/doc/html/latest/i2c/instantiating-devices.html > And where is the documentation for the magic writing into /sys ? Seems to be here: https://www.kernel.org/doc/html/latest/i2c/instantiating-devices.html#method-4-instantiate-from-user-space https://www.kernel.org/doc/html/latest/i2c/i2c-sysfs.html These may also be useful: https://www.kernel.org/doc/html/latest/i2c/ https://archive.kernel.org/oldwiki/i2c.wiki.kernel.org/ PS: I am subscribed, no need to CC me, please respect Reply-To. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)
On Mon, 2023-04-17 at 13:39 +0300, Reco wrote: > On Mon, Apr 17, 2023 at 02:48:44AM -0700, Rick Thomas wrote: > > Sadly, when I do: > > i2cdetect -l > > I get nothing back. Leading me to conclude that there are no busses > > available. > > "modprobe i2c-dev" should fix that. This seems like a usability issue, so I have sent a patch that adds a bunch of error messages in situations of silent failure: https://lore.kernel.org/linux-i2c/20230418023248.250685-1-pa...@bonedaddy.net/T/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)
On Sun, 2023-04-16 at 11:17 +0200, Georg Gast wrote: > ExecStart=/bin/sh -c "modprobe i2c_bcm2835 && modprobe i2c_bcm2708 && > modprobe rtc_ds1307 && sleep 1 && echo ds1307 0x68 > > /sys/class/i2c-adapter/i2c-1/new_device && /sbin/hwclock -s" I feel like there should be a better way to do this than manually doing /sys changes? Is there no i2c command for wrapping /sys i2c changes? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is an ARM computer a good choice? Which one?
On Thu, 2023-03-23 at 23:33 +, Wookey wrote: > The arm64 servers debian uses for buildds are fine. DSA often complain on #debian-admin about how flaky they are and often have to reset them, there were a few jokes about rebooting from cron, also the release team arch qualifications have a note about this: * concerns-dsa: arm64/armhf/armel: yes: unstable and ageing hardware https://release.debian.org/bookworm/arch_qualify.html PS: DSA recently added a requirement for ports to publicly document how they plan to meet DSA's hardware requirements. While this was initially just for riscv64 (as a proposed official port), it would be good if all existing ports, including the ARM ones, had such a document too. https://dsa.debian.org/ports/hardware-requirements/ https://wiki.debian.org/HardwareQualification -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is an ARM computer a good choice? Which one?
On Tue, 2023-03-21 at 20:57 +0100, Lionel Élie Mamane wrote: > I think I've decided :) Thanks for the pointer! Please note the Lenovo discount for Debian members: https://wiki.debian.org/MemberBenefits#Lenovo -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is an ARM computer a good choice? Which one?
On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote: > Would an ARM-based machine be a good freedom-respecting computer to > run Debian on? I read the Raptor/Power guys saying modern ARM has > freedom problems in a, but I haven't seen them go into specifics. It depends on what you mean by freedom-respecting. All of the major ARM SoC vendors now have libre GPU drivers (inc IMGTEC). There may be various minor drivers that aren't free though depending on devices. For example sometimes GPS on smartphones uses a proprietary daemon. Firmware on the other hand is a different matter and quite varied. For example, the RPi devices start the VideoCore GPU first, proprietary firmware then starts the ARM cores, then starts the ARM boot process. The LibreRPi folks are reverse engineering this firmware and maybe also the other cores on the SoC, which are all different ISAs. In addition there is some DRM but that turns out to be easily bypassed. https://github.com/librerpi/lk-overlay/ https://github.com/librerpi/rpi-open-firmware/blob/master/docs/cracking-rpi4-hmac.txt On lots of other devices (esp SBCs), the ARM core starts first and its bootrom loads libre bootloaders like u-boot, which load Linux. On other devices, especially laptops, use UEFI, which is usually a vendor fork of TianoCore EDK2, possibly not published. There are some devices that can run mainline libre edk2+edk2-platforms, but the latter is not available in Debian yet so you would need to package it. https://github.com/tianocore/edk2-platforms/ Outside boot firmware, most firmware will be proprietary on ARM, just as it is on x86 or any other platform except the ones where there have been intensive reverse engineering efforts like RaptorCS POWER devices. On mobile devices, look at PinePhone, Librem 5 or MNT Pocket Reform, other devices have less mainline Linux support or worse freedom issues. https://wiki.debian.org/Mobile On laptops, probably the Apple ARM devices are the fastest, but mainline Linux isn't yet suitable but is gaining ground quickly. I think there might be some blobs during the boot or something and the different page size for Apple ARM devices might be a challenge. Otherwise Lenovo and other vendors have some ARM laptops. Or there is the PineBook or MNT Reform for more esoteric devices. https://asahilinux.org/ Not sure about ARM desktops. ARM servers seem problematic, IIRC the arm64 ones Debian uses for buildds are unstable and the potential replacements are way too expensive. Not sure of the status here. > Will popular Debian software "generally work" There aren't many open bugs tagged as affecting ARM ports and most of them look like build related failures rather than not working. Probably folks don't bother to usertag their ARM-only bug reports though. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-arm%40lists.debian.org https://wiki.debian.org/Teams/Debbugs/ArchitectureTags There are of course various build/test issues on ARM ports too. https://buildd.debian.org/status/architecture.php?a=arm64 https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=arm64 https://ci.debian.net/status/failing/?arch[]=arm64 > I don't particularly want to get deep into being a porter Personally I think users of every non-amd64 port should consider doing porting work to keep their ports viable, since your personal package set might not be on the radar of vendors like ARM or other users. In case you do, we now have a document about the different ways to contribute to creating new ports (it applies to existing ports too). Some of the steps may be missing for existing ports, for example all of the ARM ports are missing a page based on the status template. https://wiki.debian.org/PortsDocs/New https://wiki.debian.org/PortTemplate -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: abi-compliance-checker and library transitions [Re: another attempt at Y2038]
On Fri, 2023-03-03 at 04:07 +, Wookey wrote: > Is there a place one can grep all buildlogs? Debian members can access them on the buildd.debian.org server for eg: /srv/buildd.debian.org/db/0/0ad/0.0.11-1/i386_1347540026_log.bz2 Please keep an eye on system load while searching them though. If you only need build-dep versions, probably a better option is the archive of buildinfo files and the database for searching it. https://buildinfos.debian.net/ftp-master.debian.org/ https://salsa.debian.org/bremner/builtin-pho/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: neon: armhf baseline for next release ?
On Fri, 2023-02-10 at 10:23 -0800, Vagrant Cascadian wrote: > For an individual package that wants to make use of neon, the correct > thing to do is to make the neon support detected at run-time rather than > rely on it at build-time and enabling or disabling codepaths, features, > etc. as appropriate. FTR, there is documentation on the mechanisms for doing that here: https://wiki.debian.org/InstructionSelection If there is anything missing for NEON, please update it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Installation of debian unstable on Lenovo IdeaPad 5G 14Q8X05
On Sun, 2023-01-22 at 14:58 +, Alfredo Nodo wrote: > Maybe. What to do in this case? Some potentially useful steps: Use the network console mode of the Debian installer, which will likely let you SSH in from another device so that you can check logs etc. All of the Debian installer wiki pages are outdated so I'm not sure if these are correct/useful, but it should be possible somehow. https://wiki.debian.org/DebianInstaller/NetworkConsole https://wiki.debian.org/DebianInstaller/Remote https://www.debian.org/releases/stable/arm64/ Download the Debian Linux kernel image binary package and check if it has the build config options for SC8180X enabled in /boot/config-*. If not, try to rebuild it with that enabled and boot that. https://kernel-team.pages.debian.net/kernel-handbook/ Contact the folks who worked on mainline Linux kernel support for SC8180X and ask for help figuring out where/if the support for SC8180XP landed and how to debug the issue. > Gen 1-2 are SoC SC8180X and SC8180XP respectively which are the same > SoC except for the CPU frequency I see a lot for SC8180X in mainline Linux, but no device tree curiously and nothing for SC8180XP either. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Installation of debian unstable on Lenovo IdeaPad 5G 14Q8X05
On Sat, 2023-01-21 at 09:54 +, Alfredo Nodo wrote: > I tried the latest daily build of debian unstable with kernel 6.1 and > now the snapdragon 8cx gen 2 SoC on my laptop is recognised > correctly. However, I can start the installation in GUI and text > mode, but the keyboard only works in GRUB, not during the installation. Does an external USB keyboard work during the install? > I think the problem is lack of drivers Probably, or even just device-tree stuff. I found a thread on the Ubuntu forums about these devices and Linaro suggests that support for gen2 is now upstream, but from the search link that Linaro provided, there are still things going into mainline just two days ago, including PCI support. So you might need to either compile linux-next for yourself or wait for a newer Linux release. https://wikiless.org/wiki/List_of_Qualcomm_Snapdragon_processors?lang=en#Snapdragon_8cx_Compute_Platforms https://ubuntuforums.org/showthread.php?t=2480823 https://www.linaro.org/blog/upstream-linux-support-now-available-for-the-the-qualcomm-snapdragon-8-gen-2-mobile-platform/ https://lore.kernel.org/all/?q=SM8550 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Enable V3D on Raspberry Pi 4!
On Thu, 2023-01-19 at 20:00 +0100, Diederik de Haas wrote: > That is userland and AFAIK you need to set special settings to make that work > and IIRC also in combination with Wayland. Which those are, I do not know. To get Firefox to use Wayland, set this environment variable: MOZ_ENABLE_WAYLAND=1 > But making browsers fully utilise GPU rendering is something the user needs > to > do on their own devices with their own software. Users shouldn't have to tweak software to use their own hardware, software vendors should make software automatically do that, when the software detects that it is safe to do so. Browser vendors are fairly conservative when it comes to determining that safety level though and don't necessarily think about less common situations like V3D. These articles might be helpful for determining if it is safe to use V3D under browsers. Once you have determined the result, you will be able to send feedback to the browser vendors about what happened, so they can automatically enable it or fix any bugs you find. https://askubuntu.com/questions/1385776/how-should-i-enable-hardware-graphics-acceleration-in-chromium-web-browser-runni https://forums.raspberrypi.com/viewtopic.php?t=320844 https://support.mozilla.org/en-US/questions/1054323 https://lemariva.com/blog/2020/08/raspberry-pi-4-video-acceleration-decode-chromium https://askubuntu.com/questions/491750/force-enable-hardware-acceleration-in-firefox https://www.dedoimedo.com/computers/rpi4-ubuntu-mate-hw-video-acceleration.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: armbian for arm64's is 99% debian testing for arm64's.
On Wed, 2022-12-28 at 21:35 +, Andrew M.A. Cater wrote: > On Wed, Dec 28, 2022 at 03:59:42PM -0500, gene heskett wrote: > > But its dfu-util is truly ancient at version 0.9 > Armbian != Debian. While that is true, it seems that Armbian is an overlay derivative, which means that they just use Debian binaries for most packages, including for dfu-util, so the problem being complained about (the outdated packages in stable releases) is an issue in Debian too. https://wiki.debian.org/Derivatives/Census/Armbian None of the Armbian apt pools include dfu-util: https://apt.armbian.com/armbian/apt/pool/main/ https://apt.armbian.com/armbian/apt/pool/sid-desktop/ https://apt.armbian.com/armbian/apt/pool/sid-utils/ The answer is as mentioned earlier; backports or unstable/testing. https://lists.debian.org/msgid-search/9b04ea86-c04a-62f0-1764-8e3292bc6...@physik.fu-berlin.de -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Wonderful! I discovered that UniFi Cloud Key Gen 2 Plus is powered by Debian Linux 9
On Fri, 2022-10-21 at 22:26 +0800, Turritopsis Dohrnii Teo En Ming wrote: > UniFi Cloud Key Gen 2 Plus is powered by Debian Linux 9 Please note that Debian 9 (stretch) is no longer security supported by Debian, so you may want to upgrade your devices to a newer release. In addition there are at least two third-party organisations providing extended support for older versions of Debian. https://wiki.debian.org/LTS/Extended https://www.cip-project.org/ > Linux Teo-En-Ming-Corporation 3.18.44-ui-qcom #1 SMP Mon Aug 1 > 14:33:30 CST 2022 aarch64 GNU/Linux I note that this is a very old version of the Linux kernel that is no longer supported by the Linux kernel community and so it may have some vulnerabilities in it, including remote ones. https://www.kernel.org/ I note that the version string indicates that this is a fork of the Linux kernel, please consider asking the company providing the device to get involved in the upstream community and submitting their changes for inclusion in the official Linux version. https://www.kernel.org/doc/html/latest/process/submitting-patches.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Any suggestions for a Debian(based/like) OS for the Orange Pi zero2
On Tue, 2022-10-11 at 02:31 -0700, Rick Thomas wrote: > The /etc/apt/sources.list file is directed to > http://mirrors.tuna.tsinghua.edu.cn/debian > rather than > https://deb.debian.org/debian > Is there something special about the Chinese mirror that I should > know? If not, can I replace it with the stock debian mirror? It is probably more accessible in China than the Fastly CDN and probably the image creators are in China so they used it. Other than that it looks like a normal working Debian mirror: https://mirror-master.debian.org/status/mirror-info/nanomirrors.tuna.tsinghua.edu.cn.html https://mirror-master.debian.org/status/mirror-info/neomirrors.tuna.tsinghua.edu.cn.html > And there are a few .deb packages that come pre-installed but are > not present on that mirror. Most of them have "orangepi" as part of > their package name. Their purpose seems to be to help in configuring > the system. Many of them are borrowed almost verbatim from the > Armbian distribution for Orange Pi with "armbian" replaced by > "orangepi". This is pretty common, although it would be nice if those config changes were either not necessary or included in Debian itself. > Also, the installed system uses zram files for swap and /var/log . > This is probably to limit the space the distro takes up on an SD > card, and it works OK, but it's not what I'd expect from a "stock" > Debian install. Debian has two different zram packages for enabling swap, docs: https://wiki.debian.org/ZRam > It would be interesting to know where those .deb files reside when > their at home (i.e. is there a repository that could/should have been > included in the sources.list ?) This makes me think it is deb.odroid.in: https://wiki.odroid.com/?q=sources.list=search -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Graphics acceleration for Apple's M1 ARM GPU
On Mon, 2022-10-03 at 14:23 +0200, FritzS GMX wrote: > are there any news about graphics acceleration (drivers) for Apple's > M1 ARM - M1 ARM GPU driver? Apparently it is similar to but different to PowerVR and there is already a libre mesa driver produced via reverse engineering: https://twitter.com/LinaAsahi/status/1575343067892051968 https://rosenzweig.io/blog/asahi-gpu-part-6.html https://rosenzweig.io/blog/asahi-gpu-part-5.html https://rosenzweig.io/blog/asahi-gpu-part-4.html https://rosenzweig.io/blog/asahi-gpu-part-3.html https://rosenzweig.io/blog/asahi-gpu-part-2.html https://rosenzweig.io/blog/asahi-gpu-part-1.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: OffTopic - Default language
On Mon, 2022-08-15 at 19:14 +0200, FritzS GMX wrote: > default language here English or German? From the Debian mailing lists code of conduct: Send all of your e-mails in English. Only use other languages on mailing lists where that is explicitly allowed (e.g. French on debian-user-french). https://www.debian.org/MailingLists/#codeofconduct -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: RFH: porting bolt-lmm
On Mon, 2022-08-01 at 06:19 +, Nilesh Patra wrote: > I was trying to port bolt-lmm package, which currently builds only on > amd64, i386 and ppc to more archs - particularly arm. I am trying to > workaround amd64-specific SIMD intrinsics with the libsimde-dev > (SIMDEverywhere package) - debian wiki here[1] > I've committed the patch I used here[2]. Why do you enable SIMDE_ENABLE_NATIVE_ALIASES but also rename everything to simde_*? Only one of those is needed. The idea of the SIMDE_ENABLE_NATIVE_ALIASES define is that it lets you use SIMDe without modifying the code, except for including the headers. > I am able to get it building on arm64 box, but it does > not seem to run the right way. It seems to trigger the bolt command > again while trying to make initial guess - don't know why. > I used the same command as used in autopkgtest to test it out. Your patch should not have that effect, it is quite strange, I think you are going to have to trace the execution of how exactly it gets back into main() from elsewhere, probably using gdb or similar. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Red PWR LED is always on / not detected by the system
On Sun, 2022-07-31 at 22:18 +0200, raspberry_debian wrote: > I'm running debian on a raspberrypi 3 (image from https://raspi.debian.net) > I'd like to turn off the red LED but it doesn't work Can you try it with Linux 5.18 from Debian backports? https://backports.debian.org/Instructions/ If it works then you could do a bisect to find the fix: https://wiki.debian.org/DebianKernel/GitBisect If you can find a fix then it can get backported to Linux stable: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html If that happens then the fix will reach Debian bullseye at some point. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: latency test results for armhf vs arm64?
On Fri, 2022-07-15 at 23:05 -0400, gene heskett wrote: > The whole install of raspios is armhf. So I guess its yes. I seem to remember them switching to arm64 recently? > I have not tried to build an aarch64 from the src I have. I think it would be helpful if someone with an RPi4 could do this. > It, latency-test, has recently been worked on but I've not tested > it on a Debian image of either flavor since. It is now in testing so > those of you w/o 5 years of history to lose could try it for the price of a > 64G u-sd card. For those of you who are able to try this, sounds like you just install linuxcnc-uspace and then run latency-test. Also install/try latencytop, although Linux CONFIG_LATENCYTOP is not enabled in Debian probably. $ apt-file search latency-test linuxcnc-uspace: /usr/bin/latency-test linuxcnc-uspace: /usr/share/doc/linuxcnc/examples/sample-configs/apps/latency/latency-test.demo linuxcnc-uspace: /usr/share/man/man1/latency-test.1.gz -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
latency test results for armhf vs arm64?
On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote: > Because our latency-test results are better on armhf than on arm64, > we use armhf for its performance. Are these results for armhf kernel with armhf userland? Are the results for arm64 kernel with armhf userland similar? How much worse are the results for arm64 kernel and userland? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] arm64: compat: Implement misalignment fixups formultiword loads
On Fri, 2022-07-15 at 12:04 +0200, Arnd Bergmann wrote: > If you see /other/ problems with the 64-bit kernel (using the > same user space, kernel source and kernel config as the 32-bit > kernel), please report those to the respective upstream kernel > maintainers so we can fix those as well. Gene's complaint is unrelated to this thread, but it is that Debian refuses to support running the 32-bit ARMMP kernel on 64-bit hardware, specifically on the RaspberryPi 4b. There wasn't any justification from Debian given in the bug reports, but it sounds like only build config options are needed to be enabled, but Debian refuses to do that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12 https://bugs.debian.org/981586 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Using a serial port
On Sat, 2022-06-18 at 11:30 -0500, Steve Fatula wrote: > I'm not sure why the overlays are not included in Debian. I don't remember the details, but I have heard it is because the RPi Foundation has not gotten their work on overlays into mainline Linux and Debian mostly does not use non-mainline Linux kernel versions. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian 11 on Sheevaplug?
On Thu, 2022-06-02 at 14:15 +0200, Gilles wrote: > A search in the archives returned no hits. This mail says Sheevaplug support will be dropped *after* bullseye: https://lists.debian.org/msgid-search/5393e08f-0224-4f83-a1d6-3c2780401...@www.fastmail.com That doesn't seem to have happened yet though, see below. > Martin Michlmayr's page* shows how to install Debian 10 on a USB > keydrive to run on a Sheevaplug. > > Does it mean Debian 11 still isn't available for that device? I found that there are Sheevaplug installer images for bullseye, so I suspect that Debian 11 still supports the Sheevaplug, so Martin probably just hasn't updated the page yet and probably using the bullseye images will work fine. https://deb.debian.org/debian/dists/bullseye/main/installer-armel/current/images/kirkwood/device-tree/kirkwood-sheevaplug.dtb https://deb.debian.org/debian/dists/bullseye/main/installer-armel/current/images/kirkwood/device-tree/kirkwood-sheevaplug-esata.dtb https://deb.debian.org/debian/dists/bullseye/main/installer-armel/current/images/kirkwood/u-boot/sheevaplug/ https://deb.debian.org/debian/dists/bullseye/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/ Here are the same images for Debian 12 bookworm: https://deb.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/device-tree/kirkwood-sheevaplug.dtb https://deb.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/device-tree/kirkwood-sheevaplug-esata.dtb https://deb.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/u-boot/sheevaplug/ https://deb.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian Bullseye 64-bit for the Khadas VIM4
On Tue, 2022-05-17 at 11:48 -0700, Larry Dighera wrote: > Thank you for sharing the information you provided. Very much appreciated. > With regard to Linux drivers for the Khadas VIM4 SBC ... > Perhaps this information will assist the porting team if/when that occurs. I suggest that you contact Khadas and Amlogic about their plans for mainlining Linux support for the device. Alternatively, if you have a budget for getting the work done, the BayLibre Linux consulting company seem to be the main contributor to Amlogic/Khadas support in Linux. Its also possible that they are already working on it, not sure though. https://baylibre.com/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian Bullseye 64-bit for the Khadas VIM4
On Mon, 2022-05-16 at 07:49 -0700, Larry Dighera wrote: > Is there hope of seeing a port of Debian Bullseye 64-bit for the > Khadas VIM4 any time soon? The Khadas VIM4 and the A311D2 SoC both don't appear to be supported by Linux mainline yet, I don't see any reference to either in linux.git, but there are references to the previous generation, Khadas VIM3, so it is possible that someone will work on this. Once support for the device is upstream, the support will enter Debian unstable after the next Linux kernel release, then potentially some build config changes will be needed to enable new drivers, then the package will migrate to Debian testing, then Debian backports and then you will be able to use the backport on Debian stable. Generally support for newer SoCs does not get backported to older Linux kernel versions such as the one in Debian bullseye, but a newer Linux kernel version is added to bullseye-backports. This can take a long time. Until then you can use whatever Linux kernel build supports the Khadas VIM4 such as one from the vendor BSP or from Armbian, on plain Debian. Depending on your use-cases you may need to also get updated packages for userspace drivers (such as GPU drivers) or firmware. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian armhf test system?
On Sat, Sep 25, 2021 at 2:00 PM Jeffrey Walton wrote: > We are trying to track down the cause of a build failure on Debian; > see [1]. I want to setup a Debian armhf system for testing. (I have > about 6 testing boards, but they are other OSes). Another option is to just use the existing porterboxes. https://wiki.debian.org/PorterBoxHowToUse https://db.debian.org/machines.cgi https://dsa.debian.org/doc/schroot/ > I found the relevant area of the manual that says Debian supports > armel, armhf and arm64,[2] but I have not found a list of supported > hardware like a specific SBC. There are a few different lists of hardware where using Debian is possible: https://www.debian.org/releases/stable/armhf/ch02s01.en.html#armhf-armmp-supported-platforms https://www.debian.org/releases/stable/arm64/ch02s01.en.html#arm64-supported-platforms https://wiki.debian.org/InstallingDebianOn#sbc https://wiki.debian.org/U-boot/Status https://wiki.debian.org/FreedomBox/Hardware -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Mon, 2021-09-20 at 13:39 +, lkcl wrote: > significantly reduced executable size, significantly reduced memory > footprint, resulting in better L1/L2 cache usage with consequent > power reduction. It sounds like you are talking about userland and Debian still supports a 32-bit userland under a 64-bit Linux kernel on 64-bit devices, do these concerns also apply to the Linux kernel itself? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian on Pine64 H64B?
On Mon, Sep 20, 2021 at 9:19 AM LinAdmin wrote: > What I would like to see is that the official arm kernels automagically built > by Debian could run unchanged on RaPi 32 & 64 bit. The RPi 4 is 64-bit, is there a reason for running a 32-bit Linux kernel? (The 64-bit Linux kernel can run 32-bit userspace too). -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Mon, Sep 13, 2021 at 6:07 PM Gunnar Wolf wrote: > Please don't pay me. If you offer a good hosting solution and plan to > keep it viable in the long run, I can be persuaded to move > raspi.debian.net from my current hosting provider. As an interim step, I suggest talking to the debian.net team, who can provide VMs on a couple of cloud services, sponsored by Debian Project funds. https://wiki.debian.org/Teams/DebianNet Longer-term you could move to cdimage.debian.org, which has good bandwidth and also does torrents. Even longer term Debian could add images to a CDN or other distribution mechanism. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian Pinebook Pro
On Mon, Sep 13, 2021 at 1:57 AM Oregano wrote: > What was the purpose of providing a makefile instead of just a PDF of slides? > I already had graphviz, but all the rest took "185 MB of archives" download, > and used "605 MB of additional disk space," for 1.2 MB of PDF file? Now I is > a developer/builder?! Documentation has source and build processes just like programs, and generally only the source goes in a git repository like the salsa one vagrant linked, the PDF would normally be distributed elsewhere, like in a .deb binary package or attached to the talk web page. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Fri, Sep 10, 2021 at 2:13 PM Gunnar Wolf wrote: > I am one of them. I am willing (and have done so extensively) to put > time into making Debian easy to use in the Raspberry family, but I am > convinced raspi-firmware cannot be part of Debian itself. While raspi-firmware can't be in Debian main, it is in non-free, so there could be unofficial RPi images hosted on the cdimage.debian.org server, just like we have installer, live and other images containing non-free firmware. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Fri, Sep 10, 2021 at 7:50 AM LinAdmin wrote: > I have some doubts that debian.net has the same ownership > than official debian.org? debian.net and debian.org have the same ownership (Debian, via our fiscal sponsor SPI). debian.org subdomains are setup by the Debian sysadmins and mostly run on hardware owned by Debian and systems run by the Debian sysadmins. debian.net subdomains are registered by individual Debian members for experiments, temporary or unofficial services. Gunnar Wolf registered the raspi.debian.net domain for delivering Debian RPi images. $ whois debian.org | grep 'Registrant Organization' Registrant Organization: Software in the Public Interest, Inc. - Debian Project $ whois debian.net | grep 'Registrant Organization' Registrant Organization: Software in the Public Interest, Inc. - Debian Project $ ldapsearch -ZZZLLL -x -h db.debian.org -b ou=users,dc=debian,dc=org dnsZoneEntry=raspi* uid name dnsZoneEntry dn: uid=gwolf,ou=users,dc=debian,dc=org cn: Gunnar uid: gwolf sn: Wolf dnsZoneEntry: raspi IN A 208.97.148.173 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Fri, Sep 10, 2021 at 4:05 PM Gene Heskett wrote: > So why do we not have a .deb builder for kernels.? The upstream Linux kernel build system can build .deb files using the `make deb-pkg` (build .dsc+.deb files) or the `make bindeb-pkg` (build .deb files). https://www.kernel.org/doc/makehelp.txt For rebuilding Debian's version of the Linux kernel, see the Debian Linux kernel team's documentation: https://kernel-team.pages.debian.net/kernel-handbook/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Fri, Sep 10, 2021 at 2:35 PM Gunnar Wolf wrote: > They are not designed to suit you. I guess you want to build your own > kernels with the RT_PREEMPT enabled, and that's not something you will > get with any of the mainstream Linux distributions. This is incorrect, Debian has had RT kernels built for ages, there are RT kernels for buster and later on armhf and arm64: http://packages.debian.org/linux-image-rt- -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Thu, Sep 9, 2021 at 9:46 PM Pete Batard wrote: > If you read my posts carefully, you find that the only slight request > that I have made is that Debian (i.e. people on this list whom I expect > to know better) should stop advertising pre-built images as the one > solution to install Debian on the Pi 3 or Pi 4, when there exists an > alternative for which a lot of people (including Debian maintainers, > EDK2 people, myself, and many others) have invested quite a lot of > effort in, and that have now reached a sufficient enough level maturity. If you would like Debian to advertise the UEFI option, please feel free to register an account on the Debian wiki and add it in the appropriate places. Due to the past actions of the RPi foundation and consequent culture of the larger RPi community, the userbase expects pre-built images to be available, so I don't think those will be going away any time soon, indeed I think we will see demand for more images for other SBCs too, even though it goes against how Debian has done things in the past; suggesting use of the installer etc. https://wiki.debian.org/UEFI https://wiki.debian.org/InstallingDebianOn https://wiki.debian.org/?action=fullsearch=Raspberry PS: if you or anyone else would like to package edk2-platforms, coreboot or other libre boot/other firmware for Debian, that would be very welcome. https://wiki.debian.org/Firmware/Open -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
On Tue, Sep 7, 2021 at 10:00 AM Pete Batard wrote: > Yes, but that is *outside* of the scope of Debian, just like booting > Debian on UEFI x86 based PCs also requires the use of intel or AMD > non-free blobs (for RAM bringup, ME and all the other stuff that CPU > manufacturers have decided they no longer want to open) that are > integrated into the UEFI firmware and that you don't see or have to > provide yourself, but that are very much present still. I definitely disagree here, boot firmware needs libre licensing, source code, reproducible builds etc too. Debian should be able to provide all the software installed on a system, including the boot firmware, RAM bringup etc. We even have TianoCore in Debian, but we are missing edk2-platforms and coreboot. The only reason we can't provide boot firmware on x86 and have to resort to vendor provided firmware and fwupd is that it is all proprietary forks of TianoCore. On other platforms like POWER and some ARM devices, the firmware is libre so we could provide it and in some cases we do already. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Pine64 H64B?
If anyone wants to help to make Debian work on the RPi without the proprietary boot firmware from Broadcom/RPi folks, the solution is to package a VC4 GPU compiler for Debian and then improve and package the rpi-open-firmware project. https://github.com/librerpi/rpi-open-firmware/ https://github.com/itszor/vc4-toolchain/issues/7 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Unformatted sd card
On Tue, Aug 17, 2021 at 11:11 PM pcr wrote: > I am trying again to get bullseye to run on my raspberry pi 4. The raspi images are probably the easiest option: https://raspi.debian.net/tested-images/ https://raspi.debian.net/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Feedback from the community -> ARM
On Sun, Jun 13, 2021 at 9:45 AM Marcin Juszkiewicz wrote: > Let me bring the idea on this list that, maybe, it is time for vendors > to start looking into moving away from using good old U-Boot on microsd > or similar to provide on-board SPI flash to store bootloader. So we > could stop distributing special installable images for platforms like > the Pi. Storing boot firmware on the board seems to encourage various sub-optimal things. Fully proprietary bootloaders. GPL violating bootloaders. Bootloaders containing blobs. Bootloaders that are locked down and cannot be replaced at all, especially on mobile. Forks of random snapshots of existing bootloaders. Personally I would go the other way; there should be a standard boot protocol between the SoC boot ROM and later layers of the boot process and vendors should stop shipping any boot firmware beyond the SoC boot ROM, leaving it to OS distributors to package mainline bootloaders that support that protocol. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Feedback from the community -> ARM
On Sat, Jun 12, 2021 at 11:34 AM Andrew M.A. Cater wrote: > Some of them are hugely true: at the time when the first RPi was released, it > was released as ARM v6 with hardware floating point. Almost all Linux > distributions at that point had agreed on architectures having software floating point and ARM v7 specs to be hardware floating > point. This is no longer relevant, since the arm64 and armhf capable RPi boards are way more popular than the old boards now. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Feedback from the community -> ARM
On Sat, Jun 12, 2021 at 10:58 AM Pete Batard wrote: > > On 2021.06.12 09:29, Paul Wise wrote: > > Will this be added to edk2-platforms? > > > > https://github.com/tianocore/edk2-platforms/ > > It already has: > > https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4 > > The Raspberry Pi 4 UEFI firmware has been an official EDK2 > implementation for some time... Hmm, then I don't understand the point of the rpi4-uefi.dev project then. I guess it only exists because people don't want to compile edk2-platforms themselves, the RPi Foundation doesn't offer precompiled edk2-platforms, TianoCore doesn't offer precompiled edk2-platforms and the RPi4 is the most popular platform supported by edk2-platforms. Perhaps Debian should have edk2-platforms and edk2-non-osi packages supporting all the devices to fill this gap. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Feedback from the community -> ARM
On Sat, 2021-06-12 at 09:00 +0200, Ralph Aichinger wrote: > "All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero > W, > 2, 3) boot from their GPU" > > So it seems this is no longer true, and exactly what I said. I'm fairly sure that the RPi4 still boots via the VC4 chip, but I cannot find any proper documentation of the RPi4 SoC boot ROM like one can normally find with other SoCs. The official docs only say that the boot process is no different to older RPi hardware with the exception of there being an EEPROM involved. https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/bootflow_2711.md https://hackaday.io/page/6372-raspberry-pi-4-boot-sequence > If there are Blobs needed to bring up the RPi4 they are included > in above UEFi firmware (or the stuff used in other boot mechanisms). > I don't see how this is different from the "blobs" I load when I > boot my UEFI Asus mainboard. Correct, that is no different, but still suboptimal and can be replaced with libre software (for eg coreboot) on some machines. > > some Linux kernel patches are not in mainline etc > > What patches do you mean? WRT the Linux kernel, mainline always means kernel.org. > the RPi4b runs fine without anything but a stock debian kernel That may be true, but there are apparently patches being maintained by RPi that aren't being mainlined, I don't know the details though. > With "WIP libre replacement" do you mean the tianocore/EDK2/UEFi port > here? Sorry, I misremembered where it was mentioned and it turns out to be another thread on another list: https://lists.debian.org/debian-devel/2021/06/msg00043.html I mean rpi-open-firmware: https://github.com/librerpi/rpi-open-firmware/ https://github.com/itszor/vc4-toolchain https://github.com/itszor/vc4-toolchain/issues/7 BTW, the RPi4 boot process even has some DRM in it, but that is apparently easy to bypass due to bugs in boot code: https://github.com/librerpi/rpi-open-firmware/blob/master/docs/cracking-rpi4-hmac.txt > https://github.com/pftf/RPi4 Will this be added to edk2-platforms? https://github.com/tianocore/edk2-platforms/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Feedback from the community -> ARM
On Fri, Jun 11, 2021 at 7:25 AM Ralph Aichinger wrote: > Many criticisms of the RPi that were true 5 years ago no longer hold. Some of them are still true; the weird GPU-starts-CPU SoC boot process, blobs required for the boot process, some Linux kernel patches are not in mainline etc > or FreedomBox is rather offputting, because I very much prefer > true Debian that matches amd64 except for architecture. FreedomBox is a Debian blend, so a FreedomBox install *is* a Debian install, there are no custom packages or other hacks. At least that is how it is claimed to be, I haven't tried it. > Why is the Raspberry Pi 4 with UEFI or the stock boot process > not listed here? I assume because of the proprietary software needed to boot the RPi4, although there is a WIP libre replacement that isn't yet in Debian, see other comments in the thread about that. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Feedback from the community -> ARM
On Thu, Jun 10, 2021 at 2:54 PM Uwe Kleine-König wrote: > Is there anything on your mind that is missing above and that you'd like > to be shared with ARM? Feel free to reply here or discuss in > #debian-arm. (I'm ukleinek there.) Pretty sure just everything folks have been asking for for years can be summarized in four words: libre, upstream, standards, supported. Switch from proprietary drivers/firmware to open. Do everything upstream not in forks. Standardise things across vendors. Vendors need to support and continually update their hardware so we can continue to buy and use it. An example from #debian-arm last night: for SBCs a standard SoC boot sequence and boot ROM would be nice, so we don't have to look up how each SoC boots. Oh, and since we are asking for ponies, make Apple let us boot free software on iPhones ;) -- bye, pabs https://wiki.debian.org/PaulWise
Re: OT: Huge Right to Repair Win for Consumers
On Tue, Jun 8, 2021 at 11:54 PM Jeffrey Walton wrote: > This is not as off-topic as it may seem. In the US, the FTC just > issued a report that favors consumers. A link to the report and related discussion: https://www.ftc.gov/system/files/documents/reports/nixing-fix-ftc-report-congress-repair-restrictions/nixing_the_fix_report_final_5521_630pm-508_002.pdf https://news.ycombinator.com/item?id=27068574 > The report and its recommendations may provide a means > to pierce the veil of closed platforms, like closed-sourced firmware. It seems unlikely to me that we will ever see a "Right to Repair" for software, firmware or gateware. -- bye, pabs https://wiki.debian.org/PaulWise
Re: iMX8 support in debian
On Wed, Mar 24, 2021 at 4:02 AM Wookey wrote: > I discovered this week that iMX8 is not enabled in the debian > kernels. Does anyone know why not? It seems a rather major omission, > and too late to fix for bullseye now. Did just no-one ask? Or no-one > get round to it? I guess all the folks using common iMX8 hardware are using Debian derivatives rather than Debian itself, so they didn't think about including iMX8 support in Debian? I can't see anything about it in the freeze policy, but I got the impression from reading a few unblocks that adding hardware support is acceptable during the freeze (and in Debian stable updates). Perhaps talk to the Debian Linux kernel team about it. https://release.debian.org/bullseye/freeze_policy.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Apple M1 hardware
On Sat, Mar 13, 2021 at 4:09 PM Pip Cet wrote: > (My main problem, as mentioned, is that the source on GitHub does not > match the binary they distribute; the binary works, the source code > recompiled even with the precise same utilities doesn't.) Hmm, that sounds like a GPL violation, not a good sign. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian on Apple M1 hardware
On Sat, 2021-03-13 at 11:49 +, Wookey wrote: > I've not looked into this, and clearly it's progressed far enough > that I should. Definitely, it is worth reading the Asahi post and their wiki. > What we want is to be provided with the UEFI environment Debian will have to ship our own UEFI environment if we want that, since the Apple signed iBoot2 blobs only passes Apple Device Tree (incompatible with Linux Device Tree) to the next boot layer. > The UEFI-a-like environment that u-boot provides The other libre implementation of UEFI is TianoCore/EDKII, which Debian has a package of for virtual machines, but we do not have a package of their hardware platform support codebase, which means everyone who uses EDKII are stuck with vendor binaries of it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian on Apple M1 hardware
On Sat, 2021-03-13 at 10:05 +, Pip Cet wrote: > I think it's too early to conclude they're not interested in > upstreaming changes. Perhaps, but normally when companies are interested in upstreaming changes, they engage with the Linux kernel community early and often; posting an RFC patch sketch before it works, posting final patch series when it works, posting new patch series in response to feedback etc. > I'd like to disagree with the 'likely". It's possible, sure, but it's > also possible someone (possibly the Asahi Linux project) will polish > the Corellium work (which, well, works) and submit that to upstream. The HN thread made it clear that Asahi Linux folks are not using a fair bit of Corellium's work and that Corellium's work is often suboptimal in terms of how the Linux kernel code normally works; reusing/tweaking drivers vs duplicating them etc. > I don't think we have to, or want to, pick a side here. Ultimately what ends up in mainline is the side that will be picked. > You're describing this as what sounds like a lengthy process, and it > will be until everything is included in its "final" form, but I'd > just like to remark that I consider this architecture potentially > important and that taking a "there's no rush" attitude towards it > might be the wrong approach... For better or worse the Debian Linux kernel team does generally not accept patchsets that aren't upstream or aren't near acceptance, the same applies to all hardware including Apple M1 devices. https://kernel-team.pages.debian.net/kernel-handbook/ch-source.html#s-acceptance You can of course start working on supporting Apple M1 devices using not yet upstreamed code, which is definitely a good idea, but of course the final support will be solely based on upstreamed code. > IOW, wouldn't it be nice to have something working soon? I expect some folks who own or are able to own Apple M1 hardware would like to have support for Linux, but I guess most people using Linux on Apple M1 hardware will be doing so in virtual machines or Docker. Personally I am stuck on decade old x86 hardware for now. > independently of the question of who upstreams whose work? Agreed that who does the work is not relevant. > AIUI, the boot process does not involve macOS; installing a > kernel/bootloader image is currently only possible from the recovery > OS included with macOS, but that's not that unusual. It does mean an > inconvenient extra step installing a bootloader for users, which I > believe is precisely what Apple intended... That is correct, but it does involve a proprietary iBoot2 Apple signed binary blob, which according to Asahi folks has to be on the same partition as the operating system kernel or the next part of the boot chain, which for Asahi Linux will be: SecureROM → iBoot1 (on NOR flash) → iBoot2 (on the OS partition) → m1n1 → U-Boot → GRUB → Linux ^ ^^ ^ ^^ ^ immutable \ proprietary & signed / \ open source and unsigned / Presumably the iBoot2 blob isn't released under a license that allows redistribution, so folks wanting to install Debian on Apple M1 devices will need to grab a copy of that from their macOS partition, which means that Debian cannot ship a d-i image that will just work, we have to get the user to run something on macOS to grab iBoot2. The Asahi Linux post I pointed at has relatively detailed descriptions of how the Apple M1 devices boot and the requirements of each stage. https://asahilinux.org/2021/03/progress-report-january-february-2021/ https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart https://github.com/AsahiLinux/docs/wiki/SW%3ABoot The Raspberry Pi devices are in a similar situation, but at least there is a chance the libre firmware reimplementation will be usable eventually and for now the bootrom either doesn't require signatures or parts of the boot chain are buggy enough that the boot restrictions are easily bypassed. https://github.com/librerpi/rpi-open-firmware https://github.com/librerpi/rpi-open-firmware/blob/master/docs/cracking-rpi4-hmac.txt -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian on Apple M1 hardware
On Sat, Mar 13, 2021 at 8:57 AM Pip Cet wrote: > I'm using the kernel image provided at > https://downloads.corellium.info/linuxnvme.macho. I read that Corellium haven't participated in upstreaming Linux support for the Apple M1 devices, so this is likely to be superseded by the work Asahi Linux is doing within Linux mainline at some point. More in the Hacker News discussion of the latest post from the Asahi Linux folks about their progress bringing up Linux on M1 devices. https://news.ycombinator.com/item?id=26423935 https://news.ycombinator.com/item?id=26421963 https://asahilinux.org/2021/03/progress-report-january-february-2021/ https://lwn.net/Articles/849108/ > So how do we proceed once a fully free kernel is available? Once the Linux kernel changes are upstreamed, any needed config options can be enabled in the Debian Linux kernel build. The same process will be needed for u-boot, TianoCore or whichever bootloader ends up being used. Then flash-kernel support can get added. Then the d-i bits for M1 concatenated images can get added. There might need to be some glue running on macOS in order to get d-i booted though given the following item... > apart from the non-free firmware required for some of the hardware. As I understand it from the Asahi Linux post, a copy of the signed iBoot2 blob appears to be needed on the boot partition in order to run any alternatives to macOS. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to push back against repeated login attempts?
On Tue, Mar 2, 2021 at 9:51 AM oreg...@disroot.org wrote: >How to push back against repeated login attempts? This isn't specific to ARM devices so it is a bit off-topic here, but... The first thing to do is to ensure password authentication to SSH is disabled and replaced with key or certificate authentication. To avoid (some of) the entries in the system logs there are a few different options: Just disable or uninstall the SSH daemon. Ban access to the SSH daemon except from authorised IP addresses. Switch the SSH daemon to another port than 22, then switch again when the next botnet finds that, repeat. Use the CrowdSec alternative to fail2ban, which shares the behavior of malicious IPs with a community and in return receives a list of malicious IPs other folks have shared. https://crowdsec.net/ https://news.ycombinator.com/item?id=24826792 Move the SSH daemon to a Tor onion service so that only those who know the address can access it and you can still access it if fail2ban/crowdsec block your own IP address. Some combination of the above. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Reducing apt's memory footprint (on small boxes)
On Mon, Feb 15, 2021 at 3:04 AM Jeffrey Walton wrote: > And devices with limited storage. Two days ago I had to install Debian > 10 on a fresh SDcard and swap-in the card on an IoT gadget. The dist > upgrade used too much space and the existing SDcard ran out of space > when unpacking/installing a Perl package. The unattended-upgrades package has a "minimal steps" mode that might be helpful for devices with limited disk space. Unfortunately apt itself doesn't yet support this, but you could manually upgrade one package at a time instead. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Reducing apt's memory footprint (on small boxes)
On Sun, Feb 14, 2021 at 2:53 PM Paul Wise wrote: > I think that this could be useful to a subset of Debian users, > possibly including embedded hardware and low-RAM cloud/VPS users. This could also be useful to bandwidth-constrained environments, the apt package indices are really quite large these days. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Reducing apt's memory footprint (on small boxes)
On Sun, Feb 14, 2021 at 1:42 PM Christoph Biedl wrote: > The packages indexes became that big they no longer fit into memory. In > September 2015, there was a suggestion to create subsets of a release I seem to remember that Emdebian used that solution too. > but I objected it will be more or less impossible to create them without > breaking some builds or installations for unresolved dependencies. This should be easy to avoid, by using apt on a larger system to get the list of packages to install, and then creating a subset of Packages based on the resulting list. I believe the germinate package (that Ubuntu uses for their images) does something like this, but using the apt Python bindings instead of `apt install --download-only`. > Now, from my experience: Every good idea that I believe to have found > turned out had been prosoped earlier by somebody else and/or was not as > good as it initially seemed. So, where's the actual catch in that setup? I believe that the Emdebian project shut down because hardware with very little RAM/flash became much rarer. > Or is that something that might be of broader interest and possibly even > become part of a Debian release? I think that this could be useful to a subset of Debian users, possibly including embedded hardware and low-RAM cloud/VPS users. > Of course there is the problem of defining which packages should be > included in such a "debian-narrowed"¹. I suggest that instead the desired packages should be provided by users and the service should dynamically calculate the package install sets based on the seed packages. The service could calculate the N most popular package install sets after every mirror push and dynamically recalculate the ones with outdated or missing cache information when users request them. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to get Realtek RTL8723BS WiFi working with Debian Bullseye on Pine A64+?
On Sat, 2021-02-13 at 00:39 -0600, Gunnar Wolf wrote: > non-free firmware to begin the boot process The major blocker for replacing the non-free RPi boot firmware with the libre firmware is the fact that the VC4 support for GCC is not yet available in GCC upstream and there is no one willing to do the work needed for copyright assignment of the VC4 support to the FSF etc. https://github.com/librerpi/rpi-open-firmware https://github.com/itszor/vc4-toolchain/issues/7 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to get Realtek RTL8723BS WiFi working with Debian Bullseye on Pine A64+?
On Fri, 2021-02-12 at 18:26 +, oreg...@disroot.org wrote: > So Bluetooth isn't so happy, but at least Wifi is. The Bluetooth firmware file is in the firmware-realtek Debian package. > > Is there something I can (reasonably) do to help move this module > thing along, or is the best advice to just wait more patiently? On Debian, does `modprobe rtlwifi` help? The WiFi firmware file is in the firmware-realtek Debian package. > On a related topic, what would it take to make the Pine Debian > installs more nicely packaged, like the Raspbian installs? (Thanks, > Gunnar!) There are too many different SBCs to make individual images for each platform a viable strategy. I think the only reason there are RPi images is that the hardware is popular and the community around it expects available images rather than running an installer on-device. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to get Realtek RTL8723BS WiFi working with Debian Bullseye on Pine A64+?
On Fri, Feb 12, 2021 at 3:15 AM oreg...@disroot.org wrote: > Debian was tried. Wifi didn't work. > Armbian Bullseye was tried. WiFi worked. > Help? What magic step(s) are being missed? Boot Armbian again and look at the Linux kernel dmesg output to see which firmware is being loaded. Try to find that in Debian using apt-file. If it isn't present, try to find it in the upstream Linux firmware git repo. If it is present then you just need a newer version of the linux-firmware to get into bullseye. If it isn't present then Armbian needs to get the missing firmware added upstream, and then it will later get into Debian. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: hardware encryption
On Wed, Jan 20, 2021 at 10:40 AM wrote: > hardware accelerated encryption For Linux kernel crypto stuff (disk encryption, TLS offload etc), /proc/crypto lists what is available, some of it will be generic stuff and others will be crypto accelerators on the SoC or elsewhere. For CPUs with crypto instructions, probably they will be listed in the CPU flags in /proc/cpuinfo -- bye, pabs https://wiki.debian.org/PaulWise
Re: Status of Debian on QNAP
On Wed, Nov 25, 2020 at 1:56 PM wrote: > other than open'n the door for folks what is involved in be'n a porter Basically, take care of keeping the port useful for Debian users. The following is advice for ports in general, I guess Adrian can provide some info for armel in particular and the challenges it is currently facing apart from the ones that started this thread. The most important thing is to ensure it meets the requirements for the next Debian stable release, at this stage it sounds like there being enough registered porters is the main issue. https://release.debian.org/testing/arch_policy.html https://release.debian.org/testing/arch_qualify.html Next is to ensure that it meets the requirements for being on ftp.d.o (rather than in ftp.ports.d.o) in general: https://ftp-master.debian.org/archive-criteria.html Next is to ensure it works on hardware that can't run armhf, especially on devices where it is most commonly used by current users and on new devices that can't run armhf. This mostly involves work on bootloaders like u-boot, the Linux kernel and the Debian installer, as well as web sleuthing to find out what pre-ARMv7 hardware still exists in the market. Next is to ensure the Debian installer builds and works: http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/armel/ Next is to ensure that as many packages as possible build and run on armel and that package maintainers get the help they need resolving build/test issues: https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=armel https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=armel https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=armel https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-b...@lists.debian.org;tag=armel https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-b...@lists.debian.org=armel Next is to ensure that the port is well-tested, currently armel does not have support in the reproducible builds, DebCI or piuparts infrastructure. https://tests.reproducible-builds.org/debian/ https://ci.debian.net/data/status/unstable/ https://piuparts.debian.org/ Next is to maintain the documentation related to the port: https://www.debian.org/ports/arm/ https://www.debian.org/releases/stable/armel/ https://wiki.debian.org/Ports/armel (doesn't exist yet) https://wiki.debian.org/ArmEabiPort https://wiki.debian.org/InstallingDebianOn At some point it might be useful to have non-x86 live images, or directly writable pre-installed images (almost the same thing). https://cdimage.debian.org/cdimage/weekly-live-builds/armel/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Status of Debian on QNAP
On Fri, Nov 20, 2020 at 1:36 PM Arnd Bergmann wrote: > The main question for what would happen with the armel port > I think is what kernel to ship. When the marvell kernel gets > retired, the only kernel package left would be the raspberrypi > variant, and that is a bit silly given that it has its own raspbian > armhf port that is much more suitable for that specific > hardware. Is installing a bootloader into the kernel partition and then loading the kernel from the rootfs an option to avoid having to drop kernel support for armel devices? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Issues installing libc6:arm64 on amd64
On Fri, Nov 20, 2020 at 3:28 PM Gene Heskett wrote: > Whatever gave you the idea that arm (aarch64) software, any version, > compiled for arm would run on amd64 hardware? It is pretty clear that is not what the poster was asking about, but there are two ways this can happen: When your CPU supports multiple architectures at the same time. I recently learned of a couple of vendors of CPUs that have a MIPSish native ISA but also support MIPS, ARM, x86 and RISC-V (with the latter 3 being slower than the native ISA and MIPS). When you install qemu-user-static and run the binaries on an amd64 system, or create an emulated machine using qemu-system-* and install a full ARM OS in them. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Status of Debian on QNAP
On Fri, Nov 20, 2020 at 5:54 AM Martin Michlmayr wrote: > I wanted to capture the status of Debian on QNAP. These devices are > slowly reaching end of life but there are still users. It seems worth mentioning this on DevNews and or micronews: https://wiki.debian.org/DeveloperNews https://wiki.debian.org/Teams/Publicity/micronews https://micronews.debian.org/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Status of Debian on QNAP
On Fri, Nov 20, 2020 at 1:36 PM Arnd Bergmann wrote: > I would hope that the armel port can be kept as an official release > for longer. The DSA concerns about armel are the same for armhf, so either armel will stay or armhf will also go. Of course if there are no porters for armel (see the recent porter roll call) then that could mean it gets dropped but armhf stays. -- bye, pabs https://wiki.debian.org/PaulWise
Re: eight-core ARM64 networking platform with mainline Linux support
On Sat, Nov 14, 2020 at 2:57 PM Geert Stappers wrote: > Did order one and would like to known about simular products Not quite the same, but the Turris MOX might be another option: https://www.turris.cz/en/mox/ https://wiki.debian.org/InstallingDebianOn/Turris/MOX -- bye, pabs https://wiki.debian.org/PaulWise
Re: Qnap TS-219P+ Kernel 5.9.0-1-marvell
On Thu, Nov 5, 2020 at 10:54 AM Arnd Bergmann wrote: > I was hoping to see two more Debian armel releases to run on that > class of ARM926 hardware, but something has to be done about the > build infrastructure as the Marvell based machines are at the end of > their useful life and the newer low-end machines cannot replace them > either. We are building both armhf and armel on the Ampere arm64 machines now, but there are some annoying lockups that are being worked on by zumbi and the Ampere folks. Both arches are thus equivalent from a buildd hardware perspective, the only differentiating factor would be the number of porters, the release team recently sent their porter roll call for Debian bullseye, so you might want to respond to that: https://lists.debian.org/msgid-search/cam8zjqvyal0quk57tyzqb4jie74bocdfkkfdif+juebr7ko...@mail.gmail.com/firsthit -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#972151: glib2.0: gdbus-server-auth test consistently fails on arm-conova-03 but nowhere else
On Tue, Oct 13, 2020 at 11:12 AM Simon McVittie wrote: > What hardware is arm-conova-03 running on? Is it the same as amdahl, which > has a similar description on db.debian.org? Both are running on the ganeti cluster at Conova, made up of conova-node01 and conova-node02. Looks like amdahl is currently running on the other node than arm-conova-03 but arm-conova-02 currently runs on the same node as arm-conova-03. I'm not sure what hardware the nodes are but they appear to be identical. pabs@conova-node01:~$ sudo gnt-instance list Instance Hypervisor OS Primary_node Status Memory amdahl.debian.orgkvmnoop conova-node01.debian.org running 12.0G arm-conova-01.debian.org kvmnoop conova-node01.debian.org running 12.0G arm-conova-02.debian.org kvmnoop conova-node02.debian.org running 12.0G arm-conova-03.debian.org kvmnoop conova-node02.debian.org running 12.0G > Is there anything odd about how arm-conova-03's filesystem or /tmp works, > perhaps using tmpfs or NFS where other buildds don't, or not using tmpfs > where other buildds do, or an unusual level of load? There is no tmpfs mounted on /tmp, that is part of the ext4 from / > Or is there anything odd about arm-conova-03's TCP or other networking > setup? arm-conova-03 does not have an IPv4 address/route except on the loopback device but amdahl, arm-conova-01 and arm-conova-02 do. I would bet on the test not working on IPv6-only systems. -- bye, pabs https://wiki.debian.org/PaulWise
Re: FriendlyARM NanoPi NEO Plus2 Support
On Wed, Jun 17, 2020 at 3:02 AM Paul Wise wrote: > I note that firmware-brcm80211 also doesn't contain any of the .txt > files that are in the brcm/ directory in the firmware-nonfree source > package. I looked a bit closer at this and it seems that the .txt files are device specific, since they contain MAC addresses. So the files should not be shipped in linux-firmware and should not be included in the firmware-nonfree source package nor the firmware-brcm80211 binary package. The correct solution seems to be to get it from FriendlyARM and install it into /lib/firmware/brcm/ yourself. https://bugs.debian.org/844056 https://bugs.debian.org/908724 -- bye, pabs https://wiki.debian.org/PaulWise https://bonedaddy.net/pabs3/
Re: FriendlyARM NanoPi NEO Plus2 Support
On Tue, Jun 16, 2020 at 7:21 PM Alexandre GRIVEAUX wrote: > Ps: For the wifi it's seem it doesn't load correctly the firmware: > > [7.615241] usbcore: registered new interface driver brcmfmac > [7.626931] brcmfmac mmc1:0001:1: firmware: direct-loading firmware > brcm/brcmfmac43430-sdio.bin This is in firmware-brcm80211, seems like you have that installed. > [7.627069] brcmfmac mmc1:0001:1: firmware: failed to load > brcm/brcmfmac43430-sdio.friendlyarm,nanopi-neo-plus2.txt (-2) This second file doesn't appear to be in Debian. I note that firmware-brcm80211 also doesn't contain any of the .txt files that are in the brcm/ directory in the firmware-nonfree source package. Please report a bug against firmware-brcm80211 asking for the .txt files to be installed, since the brcmf_sdio_prepare_fw_request function in the Linux kernel driver loads both .bin and .txt files from the firmware directory. I note the second file is not in the upstream linux-firmware git repository. I think you will need to obtain that from FriendlyARM and probably talk them into getting it into the upstream linux-firmware git repository. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm Once it has gotten into the upstream linux-firmware git repository, the Debian firmware-nonfree source package can be updated to the version that contains the file and the bug I mentioned above will mean the second file will get into the firmware-brcm80211 binary package. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Graphical installer on arm64 (netboot and cdrom)
On Tue, Apr 21, 2020 at 11:15 AM Alper Nebi Yasak wrote: > IMO, the right answer is "tty0 not even being in /proc/consoles in this > case (where it should've also been the /dev/console) is a kernel bug". I > tried to write a patchset [1] a while back, but received no feedback > except from kbuild test bot saying it's broken (s/#elif/#else on the > last patch). I don't know if I did anything wrong or anything right at all. ISTR that CCing Andrew Morton can help get patches into Linux if the maintainers of the code in question do not reply. I suggest you try that after you fix the issue pointed out by the bot. -- bye, pabs https://wiki.debian.org/PaulWise
Re: The state of Arm64 on Raspberry Pi (and its Documentation
On Tue, Mar 31, 2020 at 2:55 PM Ralph Aichinger wrote: > ... Others answered the rest, but one additional point: > Does installing Debian on top of UEFI firmware work yet > in practice > > https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4 Please note that Debian does not have edk2-platforms packaged yet, so you will need to either build it yourself or use builds done by someone else to install/update the boot firmware. In case you want to help package it, check out these links: https://mentors.debian.net/intro-maintainers https://lists.debian.org/debian-efi/ https://salsa.debian.org/efi-team/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: booting with linux
On Fri, Feb 7, 2020 at 8:25 PM Andreas Jellinghaus wrote: > I wouldn't want to make the work of the kernel team more difficult and > wouldn't want to throw it on them. But then I'm not sure if additional > packages that are based on the linux kernel source are great either. What is > a good direction for this? The best way to do this is to add additional packages to the linux source package, especially if those packages are small and only used on ARM and possibly x86 to be used as a coreboot payload. Alternatively you could add an additional source package that build-depends on the linux-source binary package. The patch would need to get accepted into mainline though. > A statically linked kexec binary sounds simple enough. A tiny init to run it > (or a modification of kexec to act as a specialized init), both seems like > simple code that could be packaged. Also u-root is a simple go source code > producing a single binary (cpio file), could be easy to package. Any thoughts? These sound easy to package indeed. It seems Debian already has the init applet enabled in busybox, so you could probably use that. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Armbian
On Mon, Feb 3, 2020 at 6:52 AM Vagrant Cascadian wrote: > A great talk from last year's fosdem addressing this issue with some > success: > > https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/ That looks like a fairly useful workaround today, but ultimately it seems unsustainable as more SoC and board vendors come out. What we really need is for ARM to define a set of standards for SBC boot ROMs and also require their licensees abide by those standards. -- bye, pabs https://wiki.debian.org/PaulWise
Re: arm64-net-install buster 10.2
On Mon, Feb 3, 2020 at 7:21 PM Pete Batard wrote: > Well, if you can live without SD support and with ACPI rather than > Device Tree, then please be aware that I have just sent a patch that > should enable netinst of *vanilla* Debian ARM64 on a Raspberry Pi 4 in > ACPI mode, when using the EDK2 UEFI firmware from mainline > edk2-platforms (See [1]). Is there a plan to package edk2-platforms for Debian? We already have an edk2 package, but it only supports x86/ARM virtual machines. It would be nice to have open UEFI firmware for ARM platforms available in Debian. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Armbian
On Sun, Feb 2, 2020 at 6:57 PM Reco wrote: > [1] basically tells you that some assembly is required, and tells about > the process. Not that hard, if you ask me. > Of course, it would be better if the page told about running d-i on a > board (perfectly possible BTW save the u-boot part) - but apparently > page's author is a big fan of debootstrap. > [1] https://wiki.debian.org/InstallingDebianOn/OdroidHC1 Feel free to register an account and add the d-i based install method. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Armbian
On Sun, Feb 2, 2020 at 5:51 PM Phil Endecott wrote: > What do you know about Armbian? What do you think? Only what I see on their site and derivatives census page: https://www.armbian.com/ https://wiki.debian.org/Derivatives/Census/Armbian I think they are a useful source of workarounds for devices that are not yet supported in the mainline versions of bootloaders, the Linux kernel or in Debian itself. > Is there any overlap between the Debain ARM people on this list > and the Armbian developers? AFAICT, the Armbian folks don't post on this mailing list. > Installation involves downloading an SD card (or similar) > image which boots directly into a functioning system (with only > a few first-boot steps like initial user/password setting and > possibly resizing the filesystem to fill the device). This > reminds me more of how the Debian cloud images work than > Debian Installer. On devices like the ODROID-HC1 where you > are very likely to have a large disk as well as the boot > device, there is a script to move everything over. Image-based installation methods are currently very hacky. After installing packages, you will have system-specific files created (like /etc/machine-id or OpenSSH private keys). The Debian live/cloud images have to workaround that by deleting the files after the install is created. Probably that set of deletions needs to be synced between Debian live/cloud and any future ARM images (not sure if they are synced yet). The correct way to do this would be for packages to have a "generically installed" state in dpkg/apt, which would prevent them from creating system-specific files. More info about this is in the linked discussions: https://wiki.debian.org/ReproducibleInstalls https://wiki.debian.org/SystemBuildTools#Discussions The other problem with image-based installation methods is that there are a ridiculous number of devices, so you have to either limit your device support, produce a prohibitively large amount of device-specific images, or figure out how to create one image that works on all devices (which won't be possible due to bootloader diversity on ARM), or a compromise of a limited number of images that each work on a range of devices. Limiting the number of images is also complicated by some devices not having mainline Linux kernel support, so you need to then install multiple versions of Linux and somehow have the bootloader figure out which one to install, which also bloats the size of the images. > Once installed, the system is almost but not quite regular > Debian. For example, there are obvious things like a verbose > motd that reports the CPU temperature and more subtle differences > like /var/log being on a RAM disk. I have been gradually > trying to make the system more "vanilla" but it's not always > clear if there will be side effects from e.g. removing or > disabling these Armbian things. cruft/cruft-ng might be useful to figure out which parts of the system are shipped in Armbian but aren't from packages. > Debian on ARM does suffer a bit, IMHO, from a lack of > "official" installation support on many of the popular > boards. So we end up with things like Raspian. Unlike > Raspian, Armbian has NOT rebuilt the package archive; it > uses official Debain ARM packages. The Debian Installer supports various boards, but probably will never be able to support the range of boards Armbian does, simply because not all boards have support in bootloaders/Linux upstream and not all boards can run without blobs of some kind. This situation is unlikely to change until board manufacturers decide to upstream their patches before selling their boards. The Linux kernel community (especially Linaro) is working on changing that though. > Anyway, this all makes me wonder if there could or should > be closer collaboration here. For example, should Debian ARM > be actively steering people towards Armbian as a way to get > Debian onto their ARM boards? Could, perhaps, we have some > way to launch regular Debian Installer and get a regular > Debian system, after bootstrapping using Armbian? The collaboration should mainly happen upstream in the bootloader and Linux kernel communities and then Debian and other ARM based Linux distros will inherit that work. You can certainly boot Armbian, debootstrap a new Debian install, copy over the Armbian versions of the bootloader and Linux kernel and any other needed customisations. You can probably also repack the Debian Installer ISO/initramfs files to include the Armbian versions of bootloaders/Linux. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian 9 (armel) - doesnt start
On Fri, Jan 24, 2020 at 12:43 PM Stefan Lehner wrote: > I have a very unusal setup: a old Handheld PC with a StrongARM CPU on which > i like to get Debian 9 running. Any particular reason you didn't go for Debian 10? > Short summary of my Kernel: > 4.9.210 with BX emulation patch (to get things going on the old ARMv4) Has this patch been sent upstream? > $ cp /usr/bin/qemu-arm-static /mnt/jornada/usr/bin BTW, this should not be needed with qemu from buster and later: https://bugs.debian.org/868030 > And here is the problem: the kernel boots up fine, mounts the rootfs. After > a while it displays crng init done and thats it. Nothing more . > Can somebody help me? I suggest trying to set init=/bin/bash on the Linux kernel command-line to see if the kernel booted successfully and the issue is an init problem or not. Perhaps it is caused by your CPU being too old for armel, or is the BX emulation patch meant to workaround that? IIRC armel was ARMv4T from Debian 9 stretch and earlier and got upgraded to ARMv5TE with Debian 10 buster. Other than that I'm not sure what the issue could be, hopefully someone else has an idea here or on the upstream Linux ARM mailing list. https://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- bye, pabs https://wiki.debian.org/PaulWise
Re: ARM Linux PC can also run Android apps.
On Wed, Jan 15, 2020 at 11:09 PM Vasant K wrote: > This solid-state PC runs Debian Buster XFCE apps as well as Android apps. > https://www.youtube.com/watch?v=tpQu6yYqrp4=32s Based on their website, it seems to be running Debian as an app under Android, similar to Termux and other related apps: https://volkspc.org/software/ https://wiki.debian.org/ChrootOnAndroid -- bye, pabs https://wiki.debian.org/PaulWise
Re: AtomicCounter::is_always_lock_free on armel
On Wed, Nov 6, 2019 at 2:05 PM Rene Engelhard wrote: > (even though OpenGL is probably no thing on armel, I'd be wary to just > remove the assert...) FTR, OpenGL is available on armel, for example the Raspberry Pi devices have libre drivers for the VC4 GPU and some of them can only run Debian armel (or Raspbian armhf). -- bye, pabs https://wiki.debian.org/PaulWise
Re: ARMEL in Buster CPU_Tag, instruction set
On Sat, Jul 27, 2019 at 1:18 AM Dick Hollenbeck > The website says that you are supporting 4T in the ARMEL repo: > > See the first sentence of this page: > > https://wiki.debian.org/ArmEabiPort I've added a note to the wiki page so that other folks don't get bitten by this too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: devregs for imx
On Sun, Jul 28, 2019 at 6:16 PM Rainer Dorsch wrote: > does anybody know if there is something equivalent to devregs in > > https://github.com/boundarydevices/imx-utils > > to probe and manipulate the hardware registers in an imx6 for Debian. It looks like devregs was split out of imx-utils and is now maintained in this repository instead: https://github.com/boundarydevices/devregs Neither imx-utils nor devregs is available in Debian: https://packages.debian.org/search?searchon=contents=devregs I note there is another tool called devmem but it isn't available in Debian: https://unix.stackexchange.com/questions/4948/shell-command-to-read-device-registers https://bugs.debian.org/595805 There is also a busybox devmem applet that seems to be available in Debian. https://stackoverflow.com/questions/12040303/how-to-access-physical-addresses-from-user-space-in-linux/45127890#45127890 Please note that Linux has been restricting access to /dev/mem more in recent times so I'm not sure if any of the above tools work with modern Debian versions. In case you want to package imx-utils and or devregs for Debian, I expect both will be easy to package and folks on this list might sponsor them. You can find packaging information here: https://mentors.debian.net/intro-maintainers https://mentors.debian.net/sponsors/rfs-howto -- bye, pabs https://wiki.debian.org/PaulWise
Re: ARMEL in Buster CPU_Tag, instruction set
On Sat, Jul 27, 2019 at 1:18 AM Dick Hollenbeck wrote: > In either case a policy statement seems to be needed. Was this an oops or > was it > deliberate? (Why deliberately make an architecture which is attempting to > support old ARM > CPUs NOT support old ARM CPUs?) BTW, there is a project called that rebootstrap might be able to help you reduce the baseline of armel back to 4T. It aims to make it easier and more automatic to build new architectures from scratch. The idea would be to define a new architecture with the old baseline, then cross-build enough of build-essential for the new arch, then either natively or cross build all the other packages that your project needs, ignoring things like Firefox. The downside of this approach is the setup of new infrastructure, that you have to rebuild security updates, plus that the status of rebootstrap & cross-building for buster might not be enough for your purposes. It might be simpler to just upgrade to a newer ARM CPU. Either way, here are some links that you might be interested in: https://wiki.debian.org/HelmutGrohne/rebootstrap http://crossqa.debian.net/ https://wiki.debian.org/CrossCompiling -- bye, pabs https://wiki.debian.org/PaulWise
Re: loss of synaptic due to wayland
On Mon, Jul 8, 2019 at 8:29 PM Gene Heskett wrote: > What are we supposed to do when the default install uses wayland? The XWayland folks plan to allow X11 apps to run as root, which will make synaptic work when run under X11. Also, synaptic needs to be split up into user and root components for it to work under Wayland proper or current XWayland. Until either one of these happens, you can login using Xorg instead of Wayland. The gdm login manager has an option for this and other ones should too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: loss of synaptic due to wayland
On Mon, Jul 8, 2019 at 6:41 PM Gene Heskett wrote: > So, synaptic is gone. synaptic is still available in all suites on ARM: synaptic | 0.81.2| oldoldstable | source, amd64, armel, armhf, i386 synaptic | 0.84.2| oldstable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x synaptic | 0.84.6| stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x synaptic | 0.84.6| testing| source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x synaptic | 0.84.6| unstable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x synaptic | 0.84.6| unstable-debug | source -- bye, pabs https://wiki.debian.org/PaulWise
Re: armhf vs buster problem #2
On Thu, Jul 4, 2019 at 5:08 AM Gene Heskett wrote: > On Wednesday 03 July 2019 16:07:04 Andreas Jellinghaus wrote: > > > No idea. Sorry if I missed a mail with the reasons why stock debian > > wouldn't work? > > The application needs a realtime kernel as its controlling metal cutting > machinery. Debian has RT kernels for arm64 and armhf in stretch-backports and buster: https://packages.debian.org/search?keywords=rt-arm -- bye, pabs https://wiki.debian.org/PaulWise
Re: need recommendation for a realtime kernel to build for an armhf
On Wed, Jun 19, 2019 at 5:04 PM Ian Campbell wrote: > Possibly it is no longer part of the base install though? Quite likely yes. > suggests it is "important" but I think there can be overrides to that > from the ftp-master end. $ apt-cache show net-tools | grep Priority Priority: optional > If it really isn't installed by default it might be worth someone[0] > filing a bug against tasksel to ensure it is pulled in by the "standard > Unix system" task? Deprecated or not it certainly seems like it fits > that description. IIRC the "standard Unix system" task is determined by package priority, not by any hardcoded list of packages in tasksel. Between Debian jessie and stretch, net-tools switched from priority important to priority optional. I can't see anything in the package changelog but the change happened in the source package so presumably it was deliberate. https://sources.debian.org/src/net-tools/jessie/debian/control https://sources.debian.org/src/net-tools/stretch/debian/control -- bye, pabs https://wiki.debian.org/PaulWise
Re: need recommendation for a realtime kernel to build for an armhf
On Sun, Jun 16, 2019 at 10:52 AM Gene Heskett wrote: > Get familiar with it Alan, despite our objections, both ifconfig and > route have been expunged from the stretch and newer repo's. I haven't > figured it out either. And the man pages may as well have been written > in swahili or navajo. Even the so-called examples can't be made to work. The net-tools package is still available: $ apt-file search --regex 'bin/(ifconfig|route)$' net-tools: /sbin/ifconfig net-tools: /sbin/route -- bye, pabs https://wiki.debian.org/PaulWise
Re: a Debian executable on Android
On Thu, Mar 28, 2019 at 10:28 AM Alan Corey wrote: > There are also odd ways of running Debian under Android like the > Debian kit. They use Android's Linux kernel and supply most of a > Debian userland. The trouble is it's pretty busy accomplishing > nothing in Android, the load average in Debian is pretty high. Search > Debian on Google Play if you're interested. I haven't bothered with > it in a while. This wiki page documents how to do this both with existing Android apps and by doing it manually. https://wiki.debian.org/ChrootOnAndroid -- bye, pabs https://wiki.debian.org/PaulWise
Re: a Debian executable on Android
On Tue, Mar 26, 2019 at 7:05 AM Tony Godshall wrote: > OK, so that's a precious short list Yes. For that to change we need either phone vendors to be convinced that mainlining their Linux kernel changes (including for obsolete phones) is a good idea, or for there to be enough people from the Linux kernel community who are continually obtaining source code from vendors, rewriting it to be suitable for mainline (and or reverse engineering blobs) and getting it included in mainline. At this point neither seems likely to me. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How do I find out where u-boot environment is stored?
On Thu, Mar 7, 2019 at 11:11 AM Rick Thomas wrote: > Anybody know how can I determine where u-boot is storing it’s environment? That depends on which build of u-boot you are using, what hardware you are using etc, but all of them should be able to print it with the printenv command. -- bye, pabs https://wiki.debian.org/PaulWise
Re: a Debian executable on Android
On Thu, Mar 7, 2019 at 6:37 AM Tony Godshall wrote: > These do not seem to be available, where they ever offered? Not sure, but some future possibilities for running Debian on phones: https://shop.puri.sm/shop/librem-5/ https://necunos.com/ https://itsfoss.com/pinebook-kde-smartphone/ Also, any device that has a yes in the mainline column for postmarketOS: https://wiki.postmarketos.org/wiki/Devices -- bye, pabs https://wiki.debian.org/PaulWise
upstream help needed for Linux USB gadget userland tools (libusbgx, gt, gadgetd)
Hi all, I've been discussing with upstream the userland tools (libusbgx, gt, gadgetd) for the Linux USB gadget feature that allows for management of the Linux APIs that ARM/etc boards can use to flexibly present USB interfaces to other devices. Upstream mentioned that they have mainly been focussing on libusbgx due to a lack of time. Is anyone interested in helping out with these and related tools? https://github.com/libusbgx/libusbgx: C library & example commands https://github.com/kopasiak/gt: command-line tools https://github.com/gadgetd/gadgetd: dbus based daemon for UIs to contact -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
On Mon, Nov 26, 2018 at 11:09 AM Gene Heskett wrote: > And in what repo might I find this panfrost thingy for stretch? > > > lima (Mali), > > Or this one? Neither of these projects have a mainline mesa driver yet, they are both are in the reverse engineering and driver development phase. https://gitlab.freedesktop.org/panfrost https://gitlab.freedesktop.org/lima Latest post from the panfrost blog: https://rosenzweig.io/blog/a-panfrostian-october.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote: > Both Dmitry and I just learned that the RPI has the VC4 driver which enables > it to do hardware acceleration for Desktop OpenGL, we must admit that this is > a game changer in many ways, even if we are talking on just one board (but > quite an ubiquitous one). I expect this also applies to any driver in (or soon to be in) mesa, including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv (Vivante), Tegra etc. Drivers only supporting GLES seems to be a something that happens only with the proprietary drivers. I don't have any ARM devices with GPUs to be able to test this though. -- bye, pabs https://wiki.debian.org/PaulWise
