Re: Off-Topic: G5 Open Firmware instability
On Fri, 13 May 2022 at 19:09, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 5/13/22 01:11, to...@suse.de wrote: > > https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-28/ > > > Overheating is common and I'm aware of the process to try to fix it > > but my concern is that the machine has also become totally unstable > > in Open Firmware (OF). > > > > Initially OF was stable but I noticed that the machine had stopped > > chiming at power on and in the course of trying the various fixes for > > this OF has become totally unstable. > > (...) > > I've tested the RAM (4 sticks of PC2-4200) in a PC with MemTestx86+ > > and they are fine. I've also tried swapping in different RAM. > > > > I've tried all of the usual fixes, remove CMOS battery, power off > > for a day, clear NVRAM, boot holding down power key to go thru > > programmers tone into OF. This dinking is what made it worse :) > > Sounds like bad capacitors [1] to me. Have you checked for any suspiciously > looking capacitors on the mainboard? > My first thought reading this thread was also capacitors. I'd check none are bulging/have leaked. Could also be capacitors inside the PSU so testing a known working PSU could also be quite a good idea. Ed
eMac can't boot recent kernels
Hello! I updated my system a few weeks ago for the first time in a while, and I am unable to boot the last two kernels at all. Those are 6.10.3-powerpc and 6.9.10-powerpc. I get an error from yaboot: ERROR: claim of 0x170 in range 0xc200 0x1000 failed Claim error, can't allocate kernel memory (Note, that I am still using yaboot because I can't find a good explanation of how to boot OS X from grub. I have heard of a workaround for it mentioned in other mails to the list but not found it myself). I managed to rescue my system using a netinstall disc to chroot and add an extra entry to yaboot.conf for the old kernel that still works (6.0.0-4-powerpc). I note that the newer kernels are larger than the old ones, could that be the cause? Can anyone please advise on a route forward? Thanks, Ed
Re: eMac can't boot recent kernels
Thank you Adrian. It looks as though this also affects boot in grub as it's a kernel assertion? It seems also that the culprit kernel config option was found in the thread you linked to. Is some further investigation required to discover why that config option causes an issue? Aside: I trawled the mailing list archives last night and found the guide to booting OS X using an openfirmware script when grub is installed [1]. I still find OS X useful mostly for testing the hardware. What is the process to switch from yaboot to grub? Just install grub and uninstall yaboot? I couldn't find much info on this, though I know I did it previously on my ibook. Thanks, Ed [1] https://lists.debian.org/debian-powerpc/2023/06/msg9.html On Tue, 13 Aug 2024 at 06:49, John Paul Adrian Glaubitz wrote: > > Hi, > > On Mon, 2024-08-12 at 21:09 +0100, Ed Robbins wrote: > > ERROR: claim of 0x170 in range 0xc200 0x1000 failed > > Claim error, can't allocate kernel memory > > This is a known issue (see [1]), but I have not had time yet to work on it. > > Adrian > > > [1] https://lists.debian.org/debian-powerpc/2024/07/msg1.html
Re: eMac can't boot recent kernels
On Tue, 13 Aug 2024 at 12:32, Mike wrote: > > I am also interested in this grub migration guide. My trusty powerbook is on > yaboot, but if grub can't boot OSX or MorphOS I'll need to chain these as i > bet yaboot boots grub just fine. Could you link to that script for booting > osx under grub? I'll be taking a deep dive into grub anyway I've decided. Two > or three of my old workhorse PCs that support some early EFI standard or > draft now don't display the grub menu, but works regardless. I linked it in my previous mail: https://lists.debian.org/debian-powerpc/2023/06/msg00009.html > > > On Tue, 13 Aug 2024, 13:20 Ed Robbins, wrote: >> >> Thank you Adrian. >> >> It looks as though this also affects boot in grub as it's a kernel assertion? >> >> It seems also that the culprit kernel config option was found in the >> thread you linked to. Is some further investigation required to >> discover why that config option causes an issue? >> >> Aside: >> I trawled the mailing list archives last night and found the guide to >> booting OS X using an openfirmware script when grub is installed [1]. >> I still find OS X useful mostly for testing the hardware. >> >> What is the process to switch from yaboot to grub? Just install grub >> and uninstall yaboot? I couldn't find much info on this, though I know >> I did it previously on my ibook. >> >> Thanks, >> Ed >> >> [1] https://lists.debian.org/debian-powerpc/2023/06/msg9.html >> >> On Tue, 13 Aug 2024 at 06:49, John Paul Adrian Glaubitz >> wrote: >> > >> > Hi, >> > >> > On Mon, 2024-08-12 at 21:09 +0100, Ed Robbins wrote: >> > > ERROR: claim of 0x170 in range 0xc200 0x1000 failed >> > > Claim error, can't allocate kernel memory >> > >> > This is a known issue (see [1]), but I have not had time yet to work on it. >> > >> > Adrian >> > >> > > [1] https://lists.debian.org/debian-powerpc/2024/07/msg1.html >>
Re: eMac can't boot recent kernels
On Tue, 13 Aug 2024 at 14:30, Ed Robbins wrote: > > On Tue, 13 Aug 2024 at 12:32, Mike wrote: > > > > I am also interested in this grub migration guide. My trusty powerbook is > > on yaboot, but if grub can't boot OSX or MorphOS I'll need to chain these > > as i bet yaboot boots grub just fine. Could you link to that script for > > booting osx under grub? I'll be taking a deep dive into grub anyway I've > > decided. Two or three of my old workhorse PCs that support some early EFI > > standard or draft now don't display the grub menu, but works regardless. > > I linked it in my previous mail: > https://lists.debian.org/debian-powerpc/2023/06/msg9.html I should add, you'll want to look at the few messages before it in that thread to see how to use it. > > > > > > > On Tue, 13 Aug 2024, 13:20 Ed Robbins, wrote: > >> > >> Thank you Adrian. > >> > >> It looks as though this also affects boot in grub as it's a kernel > >> assertion? > >> > >> It seems also that the culprit kernel config option was found in the > >> thread you linked to. Is some further investigation required to > >> discover why that config option causes an issue? > >> > >> Aside: > >> I trawled the mailing list archives last night and found the guide to > >> booting OS X using an openfirmware script when grub is installed [1]. > >> I still find OS X useful mostly for testing the hardware. > >> > >> What is the process to switch from yaboot to grub? Just install grub > >> and uninstall yaboot? I couldn't find much info on this, though I know > >> I did it previously on my ibook. > >> > >> Thanks, > >> Ed > >> > >> [1] https://lists.debian.org/debian-powerpc/2023/06/msg9.html > >> > >> On Tue, 13 Aug 2024 at 06:49, John Paul Adrian Glaubitz > >> wrote: > >> > > >> > Hi, > >> > > >> > On Mon, 2024-08-12 at 21:09 +0100, Ed Robbins wrote: > >> > > ERROR: claim of 0x170 in range 0xc200 0x1000 failed > >> > > Claim error, can't allocate kernel memory > >> > > >> > This is a known issue (see [1]), but I have not had time yet to work on > >> > it. > >> > > >> > Adrian > >> > > >> > > [1] https://lists.debian.org/debian-powerpc/2024/07/msg1.html > >>
Re: Firefox 52esr on PPC32 is outdated
On Sun, 15 Sep 2024, 17:23 Leo Historias, wrote: > What? You didn't finish due to lack of "manpower"? > As far as I understand Adrian does almost all of the debian powerpc maintenance (with some help here and there, not from me I'm afraid). Without him there would be no ppc or ppc64 debian: As far as I'm aware it's mostly a one man show (but apologies to anyone else whose efforts I have missed in making that statement). He simply doesn't have time to maintain thousands of packages and all the other work that goes into the OS AND port a gargantuan browser and all its dependencies to powerpc as well, I think is what he is communicating here. And nor can anyone reasonably expect him to. And we need cross transpile? Okay, i could do it for you if only i had the > skills necessary and I'm not too young (but being too young isn't neccesary > for the reason not to do it,right? I'm 17,almost turning 18 next year!) > Sounds like a great time to learn and get involved! There is no too young! Ed Any alternatives in case firefox 52esr doesn't get updated to 115esr? > Especially for tls 1.3 support,since some websites require it. 52esr's tls > 1.3 support is only disabled by default,as far as i know. > > Em dom., 15 de set. de 2024 13:09, John Paul Adrian Glaubitz < > glaub...@physik.fu-berlin.de> escreveu: > >> On Sun, 2024-09-15 at 13:04 -0300, Leo Historias wrote: >> > Thanks for your explanation,but why Node.JS? >> >> Because Firefox upstream decided they want to transpile Javascript files >> during >> the build process instead of the development process. >> >> > Why don't we have it on ppc32? >> >> Because it's not been fully ported to 32-bit PowerPC. I started working >> on it and >> some others did, but it was never finished. As I said before, all these >> things >> require a lot of human resources, i.e manpower. >> >> > One alternative is to build either Firefox using nodejsc >> >> I have no idea what NodeJSC is. As I said, one could cross-transpile the >> JavaScript >> files for 32-bit PowerPC and other architectures without NodeJS support. >> >> But someone has to do the actual work and I cannot clone myself. >> >> > or use a version of Firefox that requires rust but not Node.JS >> >> We're using the Firefox version that is part of Debian. Maintaining a >> custom version >> is extremely time-consuming. >> >> >> Adrian >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer >> `. `' Physicist >> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >> >
eMac video modes
Hello, Back in December I was able to get sid running on my eMac using a net install image and a custom EDID binary. This is necessary due to the strange timings of the eMac monitor. Furthermore it is necessary to put the EDID binary into the initramfs by creating a hook, otherwise the eMac monitor refuses to switch to the new mode when an incorrect mode was used during the initial boot. I posted about this on the Linux on powerpc macs facebook group and have been supporting it there [1]. I wondered if it is possible to directly support eMac machines by supporting this in the installer and taking the necessary steps during installation? Is this something that you would be happy to have upstream? I do not know how to go about adding this but I am happy to do testing (including committing to release testing) or try to add the support myself if you could provide some pointers? Thanks very much, Ed Robbins [1] https://www.facebook.com/groups/ppclinux/permalink/437344776940132/
Re: eMac video modes
On Fri, 3 Apr 2020 at 22:08, John Paul Adrian Glaubitz
wrote:
>
> On 4/3/20 10:58 PM, Ed Robbins wrote:
> >> 2. I used switchresx on mac OS X to export all the video modes of the eMac
> >> monitor, rewrote them into modelines, and then used [3] to generate an EDID
> >> bin file (1280x960.bin). It only contains the video mode for the highest
> >> resolution, 1280x960@72Hz. The modeline is "1280x960" 122.24 1280 1328
> >> 1424 1696 960 961 964 1002 +hsync +vsync.
> >> 3. Copy the EDID bin file to /lib/firmware/edid/1280x960.bin
> >> 4. Create /usr/share/initramfs-tools/hooks/edid with contents as below
> >> (looking at it now, I guess this could actually be done with a one line
> >> "install -D" but anyway...)
> >>
> >> #!/bin/sh
> >> mkdir -p ${DESTDIR}/lib/firmware/edid
> >> cp -pnL /lib/firmware/edid/1280x960.bin
> >> ${DESTDIR}/lib/firmware/edid/1280x960.bin
> >> chmod 644 ${DESTDIR}/lib/firmware/edid/1280x960.bin
> >>
> >> 5. Run "update-initramfs -u" to create the new initramfs
>
> This sounds like a reasonable approach. We would just need to find a
> firmware package where the EDID file fits in, see:
>
> > https://packages.debian.org/search?suite=buster§ion=all&arch=any&searchon=names&keywords=firmware
The only place I can see it fitting is firmware-linux-free, but it is
not that similar to other firmwares in that package, which look to all
be firmware in the sense of executable code. However, I don't know if
that distinction is important: it is free firmware for the Linux
kernel.
>
> > Alternatively, I think the attached kernel patch will do the same thing.
> > You would then boot with the parameter:
> > drm.edid_firmware=edid/emac_1280x960.bin
> >
> > The disadvantage is that it wont work for any kernel, and I guess it is
> > unlikely to be accepted upstream by the kernel devs. However most emac
> > users will not be building mainline kernels, and I guess you are already
> > patching the kernel for powerpc? So this might be the best way, even if
> > users have to manually add the boot parameter.
>
> No, we're not rolling a custon kernel. Debian for PowerPC uses the Debian
> stock kernel, with all the patches Debian needs.
>
> It could be added as a patch to the kernel package, but it would have be
> carried around forever which I don't think is acceptable.
I agree that the other solution is neater, just wanted to check a
kernel patch wasn't easier for you.
Best,
Ed
>
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaub...@debian.org
> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: eMac video modes
I'm resending this message in pure plain text (rather than multipart,
which I didn't realise my mailer was using), because it was rejected
by the list the first time I think.
On Wed, 1 Apr 2020 at 17:45, John Paul Adrian Glaubitz
wrote:
>
>
> > I wondered if it is possible to directly support eMac machines by
> > supporting this in the installer and taking the necessary steps during
> > installation? Is this something that you would be happy to have upstream?
>
> Depending on what it's involved to achieve that, absolutely yes.
That's great
>
> > I do not know how to go about adding this but I am happy to do testing
> > (including committing to release testing) or try to add the support myself
> > if you could provide some pointers?
>
> Just let me know what needs to be patched where and how. Then I can figure
> out how we can upstream this.
The process I followed is
1. Install from a net install image (last time I tried a number and
could only get [1] to work because the others wanted to use grub and
it was broken). Then boot the machine with the "nomodeset" parameter,
edit source.list to include the sid repository, install the debian
ports keyring (from [2]), update the kernel, install ca-certificates,
ssh server, firmwares and X. This step is pretty much business as
usual.
2. I used switchresx on mac OS X to export all the video modes of the
eMac monitor, rewrote them into modelines, and then used [3] to
generate an EDID bin file (1280x960.bin). It only contains the video
mode for the highest resolution, 1280x960@72Hz. The modeline is
"1280x960" 122.24 1280 1328 1424 1696 960 961 964 1002 +hsync +vsync.
3. Copy the EDID bin file to /lib/firmware/edid/1280x960.bin
4. Create /usr/share/initramfs-tools/hooks/edid with contents as below
(looking at it now, I guess this could actually be done with a one
line "install -D" but anyway...)
#!/bin/sh
mkdir -p ${DESTDIR}/lib/firmware/edid
cp -pnL /lib/firmware/edid/1280x960.bin
${DESTDIR}/lib/firmware/edid/1280x960.bin
chmod 644 ${DESTDIR}/lib/firmware/edid/1280x960.bin
5. Run "update-initramfs -u" to create the new initramfs
6. Edit /etc/yaboot.conf and add a line to add a kernel argument for
this: append="drm.edid_firmware=edid/1280x960.bin"
7. Run "ybin -v"
I also added the other modelines to xsessionrc, as follows. I am not
sure how to create an EDID bin with all the modes in it, but that
would be a better solution.
#!/bin/sh
xrandr --newmode "640x480" 62.27 640 656 720 864 480 481 484 522 +hsync +vsync
xrandr --newmode "800x600" 77.84 800 816 896 1080 600 601 604 642 +hsync +vsync
xrandr --newmode "1024x768" 99.19 1024 1072 1168 1376 768 769 772 810
+hsync +vsync
xrandr --newmode "1152x864" 112.44 1152 1216 1344 1560 864 865 868 906
+hsync +vsync
xrandr --addmode VGA-0 640x480
xrandr --addmode VGA-0 800x600
xrandr --addmode VGA-0 1024x768
xrandr --addmode VGA-0 1152x864
I think that you would need to detect that the installer is running on
an eMac and take the steps as above, but I guess that adding the
kernel parameter will be different under grub.
The only other thing to note is that while this has been tested on all
the ATI graphics models of eMac, the very first models had NVIDIA
GeForce 2 MX graphics and have not been tested. I think they have a
modesetting driver, so I guess it may work, but I can't be sure.
Also, I have created a really rough gtk tool for configuring the
monitor size/position etc. They don't seem to follow any kind of
DDC/CI protocol like other monitors, unfortunately [4].
Let me know if I can provide any further details, it would be really
great to get these machines fully supported!
Best,
Ed
[1]
https://cdimage.debian.org/cdimage/ports/10.0/powerpc/iso-cd/debian-10.0-powerpc-NETINST-1.iso
[2]
http://archive.ubuntu.com/ubuntu/pool/universe/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2018.01.05_all.deb
[3] https://github.com/akatrevorjay/edid-generator
[4] https://github.com/static-void/emac_monitor_tool
Re: iMac G3 support in Sid, Impossible?
On Sat, 18 Apr 2020 at 23:45, aggaz wrote: > Il 18/04/20 23:22, John Paul Adrian Glaubitz ha scritto: > > > > Rather, he has most likely issues getting X running on his iMac G3 and > > I assume it's a similar issue as seen on the eMac [1]. > > I had the chance to play both with an eMac G4 and a iMac G3 in the past. > Both machines have CRT monitors and ATI video cards. > To the best of my knowledge, for both machines "black screen of death" > issues started with Jessie [1]. > I strongly believe the two issues are similar. > > The email that Adrian is reporting is the first promising approach to > find a solution for eMacs that I saw in the last years. > > I think it could be worth to create an EDID binary for the iMac G3 too. > Unfortunately I do not have access to one anymore. Both these machines have CRTs that have non standard timings and don't provide EDID data. However, I don't believe the approach used for eMac will work on iMac G3. The eMac GPU driver uses KMS, so providing an EDID binary to the KMS DRM helper early enough in the boot solves the problem. The iMac G3 GPU drivers still use UMS, so, assuming UMS still works with new kernels (don't see why not) and X.org (not certain but I think so), all that should be needed is the correct driver installed and an xorg.conf with the correct modelines (the same as it always has been for these machines). >From what Riccardo said, you need to install xserver-xorg-legacy and (I guess) x-server-xorg-video-r128 or xserver-xorg-video-mach64 (depending on your machine). Then just drop one of the many available iMac G3 xorg.conf files into the right place. Or maybe I am missing something? Best, Ed
Re: Patched XOrg to get r128 working?
On Mon, 20 Apr 2020, 21:11 Alex McKeever, wrote: > > Tried everything to get X working (needed working for LXDE), including a new > xorg.conf with modelines. NO SUCCESS AT ALL. > > Another developer (who works on VoidPPC) said r128 needs patched to even > work…. I don’t even know what he did to get it working over there. "Tried everything" is not very informative. Reports on this list are that you need to install xserver-xorg-legacy (and x-server-xorg-video-r128) for rage 128 [1]. Have you tried that? What xorg.conf have you tried? What rage 128 patches are you alluding to? By the way, you've started four email threads about this, most of them with little to no new information. It would be much easier to follow if you would stick to one thread. Ed Robbins [1] https://lists.debian.org/debian-powerpc/2020/04/msg00148.html
Re: Lombard booting Debian Ports 2020-04-19 (was Re: Updated installation images for Debian Ports 2020-04-19)
On Mon, 20 Apr 2020 at 15:12, John Paul Adrian Glaubitz wrote: > > On 4/20/20 3:30 PM, user...@yahoo.com wrote: > >> Did you try loading GRUB directly from the OpenFirmware prompt? > > > > From the Open Firmware prompt, the Debian 7.8 CD can be booted using the > > following command: > > 0 > boot cd:,\install\yaboot > > > > From the Open Firmware prompt, the Debian SID CD can't be booted; I > > tried these commands: > > 0 > boot cd:,\boot\grub\powerpc.elf > > MAC-PARTS: can't find a default partition > > can't OPEN: cd:,\boot\grub\powerpc.elf > > This should actually work unless the system has issues reading the > CD-ROM itself or the HFS+ filesystem used on the CD-ROM. > > > 0 > boot cd:,\install\vmlinux > > MAC-PARTS: can't find a default partition > > can't OPEN: cd:,\install\vmlinux > > > > 0 > boot cd:,\install\initrd.gz > > MAC-PARTS: can't find a default partition > > can't OPEN: cd:,\install\initrd.gz > > Neither of these can be booted. \boot\grub\powerpc.elf is the one > that should work. > > > Perhaps I'm not booting the right file? > > I have more the impression that your machine is unable to read the HFS+ > filesystem. > FWIW, I have been booting the new images from USB, and there the command is boot ud:,\\grub.elf This is despite the fact that the ISO looks like it should want to boot boot/grub/powerpc.elf Remember also that you can list files in OF with dir ud:,\\ Or dir cd:,\\ etc
Re: G4 semi-success
I have the same problem on my ibook g4. It does boot to single user mode if I append "single" in grub. But otherwise it seems successful, but then I get a blank screen. I checked the Xorg.0.log and it looks normal. I also supplied a wireless firmware during installation (though I manually copied the b43 files into /lib/firmware), I wonder if that can somehow be related (seems unlikely). I haven't had time to look into it much yet. I also noted that grub will not boot mac OS. Best, Ed On Fri, 24 Apr 2020 at 03:09, Doug Kiekow wrote: > > Hi, and first off thanks for getting grub working. > > First attempt, with guided partitioning after install it failed to boot. > > Second attempt, same thing. So I booted into rescue off the cd, ran fdisk and > found no partitions on /dev/sda > > Third attempt, the installer asked for an additional file (it had asked for > firmware-misc-nonfree_20190717-2_all.deb previously) regulatory.db. The > closest I could come up with was wireless-regdb_2016.06.10-1_all.deb, which > seemed to make the installer happy. Then i partitioned the disk manually with > a 1Gb boot partition. Installation was successful, the system booted grub, > and started to boot Debian, then went into a black screen. I’ve tried editing > the esetparms with nomodeset, radeon.modeset=0, grub_gfxmode=1024x768x16, > vga=ask and setting the run level to 1, all with the same black screen result. > > Any help would be appreciated. > > PowerBook3,4 ATIMobility Radeon 7500
Re: G4 semi-success
Awesome, thanks. I thought it might be firmware related! Will give it a try later today On Fri, 24 Apr 2020, 08:13 John Paul Adrian Glaubitz, < glaub...@physik.fu-berlin.de> wrote: > Hi Ed! > > On 4/24/20 9:08 AM, Ed Robbins wrote: > > I have the same problem on my ibook g4. It does boot to single user > > mode if I append "single" in grub. But otherwise it seems successful, > > but then I get a blank screen. I checked the Xorg.0.log and it looks > > normal. I also supplied a wireless firmware during installation > > (though I manually copied the b43 files into /lib/firmware), I wonder > > if that can somehow be related (seems unlikely). I haven't had time to > > look into it much yet. I also noted that grub will not boot mac OS. > > You need to install the AMD firmware package which is currently not > included > in the installer CD (known issue, I'm working on that, it's not trivial to > fix). > > You can fix this issue afterwards by adding the following line to your > sources.list: > > deb [arch=all] http://ftp.debian.org/debian/ unstable contrib non-free > > You can use my sources.list for that [1]. > > After adding the entry, run: > > # apt update > # apt install firmware-amd-graphics > > Adrian > > > [1] https://people.debian.org/~glaubitz/sources.list > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: G4 semi-success
On Fri, 24 Apr 2020 at 08:13, John Paul Adrian Glaubitz wrote: > > Hi Ed! > > On 4/24/20 9:08 AM, Ed Robbins wrote: > > I have the same problem on my ibook g4. It does boot to single user > > mode if I append "single" in grub. But otherwise it seems successful, > > but then I get a blank screen. I checked the Xorg.0.log and it looks > > normal. I also supplied a wireless firmware during installation > > (though I manually copied the b43 files into /lib/firmware), I wonder > > if that can somehow be related (seems unlikely). I haven't had time to > > look into it much yet. I also noted that grub will not boot mac OS. > > You need to install the AMD firmware package which is currently not included > in the installer CD (known issue, I'm working on that, it's not trivial to > fix). > That did the trick, thanks very much!
Re: Maintaining older xorg driver packages by Debian Ports
On Tue, 21 Apr 2020 at 12:23, John Paul Adrian Glaubitz wrote: > > Hi! > > After some xorg driver packages were removed from the archive in #955603 [1] > that we still need for Debian Ports, I was wondering whether it's okay when > I take over maintainership and upload the packages to unstable as we need > them. > > I understand that the timing is a bit unfortunate, but I wasn't aware of the > removal bug otherwise, I would have asked for some of the drivers to stay. > > But I can just maintain the driver packages myself if that's ok? This sounds like a good idea. I have a number of machines affected by this issue (both G4 and x86). Is it possible to bring these packages back into debian? They work well enough for many users. Thanks, Ed Robbins
Re: Maintaining older xorg driver packages by Debian Ports
On Tue, 21 Apr 2020 at 14:22, John Paul Adrian Glaubitz wrote: > > On 4/21/20 3:09 PM, Julien Cristau wrote: > >> After some xorg driver packages were removed from the archive in #955603 > >> [1] > >> that we still need for Debian Ports, I was wondering whether it's okay when > >> I take over maintainership and upload the packages to unstable as we need > >> them. > >> > >> I understand that the timing is a bit unfortunate, but I wasn't aware of > >> the > >> removal bug otherwise, I would have asked for some of the drivers to stay. > >> > >> But I can just maintain the driver packages myself if that's ok? > >> > > If they're needed by debian-ports, then may I suggest you maintain them > > there? > > Maintaining them in Debian Ports is completely manual and therefore very > cumbersome. The packages cannot be built automatically unless they > are part of the main archive. Hi Julien et al, is it possible to get some further feedback on this issue? It affects a large number of users of older hardware, who were not aware of the change until after the fact. It isn't as though the drivers fail to build or are unsupported upstream, and a Debian developer (Adrian) has offered to maintain the package. Thanks, Ed Robbins
Re: yaboot with updated e2fsprogs
Awesome! Notably grub can't yet boot OS X on PPC AFAIK. On Wed, 9 Sep 2020 at 09:01, John Paul Adrian Glaubitz wrote: > > Hi Richard! > > On 9/9/20 5:38 AM, Richard Allen wrote: > > I'm unsure if this is helpful for anyone, but I started hacking > > on yaboot a few days ago for GCC10 and better ext4 support. > > This boots my PowerMacG5, but I have yet to try booting a > > 64-bit ext4 /boot partition - the updated e2fsprogs should > > support it though. It's still a little kludgy, but it's here: > > > > https://github.com/rsaxvc/yaboot4 > > Thanks, great work. I can upload an updated Debian package into the > "unreleased" distribution this week for those folks who prefer Yaboot > over GRUB on their PowerPC machines. > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: iMac G3 r128 - failed to load module "r128"
On Sat, 27 Feb 2021 at 11:33, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 5/23/20 9:52 PM, John Paul Adrian Glaubitz wrote: > > On 5/23/20 9:48 PM, Jeroen Diederen wrote: > >> I installed Debian Sid on an old iMac G3 500 with an ATI Rage 128 card. > I cannot > >> get X working. In the /var/log/Xorg.0.log I can see that r128 module > fails to load. > >> I can not find the xserver-org-video-r128 package. Can someone shed a > light ? > > > > The driver was removed from the package repository [1], I will re-add > them soonish. > > Good news on this issue: Adrian Bunk has kindly stepped up and is working > on re-adding > the legacy driver packages to the Debian archive [1]. So users will be > able to use > X on the affected machines in the near future again. > > If anyone knows about some particular fixes that are required for the > drivers - such > as for the eMac - it would be nice if we could assemble a list of these > fixes so they > can be integrated into the Debian packages later. The fixes should, of > course, get > upstreamed whereever possible. > > Hi Adrian! My emac is fully up to date and is still working great with my changes (as detailed some time ago on this list) to put an EDID binary in the initrd and set a kernel argument to specify it. It has worked fine through kernel updates etc, though I have not tried it with grub. However the emac driver is modesetting, whereas I believe r128 and friends are not. Thus r128 etc require booting with modesetting disabled, and CRT imacs in particular will also require an xorg.conf with the correct modelines because, like the emac, they do not support EDID, but as they are not modesetting the method is different (xorg.conf vs kernel arguments/EDID binary). If you'd like I can try to find some time to package the EDID binary I use on my emac. However debian packaging is a new process for me... Best, Ed Robbins Thanks, > Adrian > > > [1] https://lists.debian.org/debian-devel/2021/02/msg00055.html > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
apm_emu module missing
Hi all, I believe that the apm_emu module is required for battery indicator/monitoring on certain powerbooks? It seems to be missing on latest kernels (6.3, 6.11). Can it be enabled for our config? Or, is there an alternative way to enable battery indicators? Thanks, Ed
Re: Debian 12 installation on iMac G3
Hi Manuel On Thu, 10 Oct 2024 at 23:50, Manuel Molina Cuberos wrote: > > Hi all! > > I have several PowerPC based computers. One of them is an iMac G3/500 DV SE > (powermac2,2) with 1 GB RAM and 30 GB hard drive. > > I've had it with Ubuntu 14.04 LTS but it's out of support already. It worked > fine from boot perspective, and it was using yaboot. > > I wanted to install Debian 12, now that I know that the architecture is being > maintained. > I downloaded and installed it from this image: > https://cdimage.debian.org/cdimage/ports/snapshots/2024-02-25/debian-12.0.0-powerpc-NETINST-1.iso > . Grub right now only works on certain specially prepared CD images. You need to use this one, it should solve your issue https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/debian-12.0.0-powerpc-NETINST-1.iso Best, Ed > > The disk layout for this installation was: > > Device / Size / Type / Mount point / Bootable > --- > /dev/sda13 128MB HFS /boot/grub yes > /dev/sda14 11GB ext4 / no > /dev/sda15 512MB swap no > > However, when it comes the time to install grub, the system hangs at 16% > progress of that stage. > I opened a console and checked. The process hung was grub-ieee1275 > > The system log (Alt+F4) showed a dump of a killed process. > > I was able to kill that and finish the installation (users etcetera). > I booted in rescue mode. Then mounted and verified that /boot/grub was r/w. > Then tried to complete the installation, to no avail. The error message this > time: > > Installing for powerpc-ieee1275 platform . Errors were encountered while > processing grub-ieee1275 > > Any hint of what I'm missing or doing wrong? > Any hint will be very much appreciated. > > -- > Regards, > > Manuel Molina Cuberos
Re: Why it's so difficult to fix PowerMac booting for good
Hi Adrian, On Wed, 2 Oct 2024 at 09:52, John Paul Adrian Glaubitz wrote: > > On Tue, 2024-10-01 at 23:38 +0100, Ed Robbins wrote: > > I just tried this, and blessed the file with: > > > > hmount /dev/sda2 > > hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX > > humount > > > > But I see no difference upon rebooting the machine. Am I missing something? > > You actually did not bless the bootloader folder. From the grub-installer > script [1]: > > # hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX > # hattrib -b :System:Library:CoreServices > Thanks. Just gave this a try (running both those commands) and I'm afraid the behaviour is still identical to what I described previously. I mean, holding down alt is not so bad honestly, and that seems to "just work" with the standard grub install as far as I am aware. > Adrian > > > [1] > > https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer?ref_type=heads#L1061 > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Booting OS X from grub
Hi Adrian, On Wed, 2 Oct 2024 at 12:42, John Paul Adrian Glaubitz wrote: > > Hello Ed, > > On Wed, 2024-10-02 at 12:35 +0100, Ed Robbins wrote: > > Picking up from the other thread... this is about booting OS X on > > apple ppc hardware when grub is being used to boot Linux. > > Ah, that's a completely different problem then. I don't actually know whether > GRUB can load other bootloaders when using Open Firmware (ieee1275). > I think Ben's solution (the BootX file he shared) is just an openfirmware script that runs before grub, which allows you to choose between a grub/os x/CD. And it is also how yaboot handled this (I think his script is a modification of the yaboot one). But I am not sure how to make that script run by default instead of jumping straight to grub. > This is probably something that needs to be asked on the grub-devel mailing > list. Although grub shows options for the other installed operating systems (i.e. OS X) it indeed seems unable to boot them. I am not sure if this is supposed to work. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Booting OS X from grub
Hi all, Picking up from the other thread... this is about booting OS X on apple ppc hardware when grub is being used to boot Linux. I tried the version of the BootX file Ben Westover shared in this message https://lists.debian.org/debian-powerpc/2023/06/msg8.html I placed the file in /boot/grub/System/Library/CoreServices/BootX. I then blessed it: umount /dev/sda2 hmount /dev/sda2 hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX hattrib -b :System:Library:CoreServices humount What I expected to happen, was that on power on I would get a menu, the same as yaboot used to have, which says something like "press l for linux, x for mac os, c for cdrom". What actually happens is that on power on it goes straight to grub, as it did before. If I hold alt down at power on and select the debian option, then I do get the "press l for linux, x for mac os, c for cdrom" menu. However I am not really sure this is worth pursuing, because holding down alt to select the operating system is already a working solution for booting mac os x when grub is used as the bootloader for Linux. I do wonder though how one would go about changing the default boot OS. Thanks, Ed
Re: mesa update broke GL on nvidia nv34
On Mon, 21 Oct 2024 at 14:40, Ed Robbins wrote: > > On Mon, 21 Oct 2024 at 14:22, Ed Robbins wrote: > > > > Downgrading those packages fixes everything. They all interdepend so I > > am not really sure why. But at least I can now report this... > > Bug report here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12048 I just tried this on another machine with radeon graphics and it has the same problem. So it seems to be a more general issue.
Re: mesa update broke GL on nvidia nv34
On Mon, 21 Oct 2024 at 17:14, Leo Historias wrote: > > Ah, I see. But why did you put an rankine gpu on it instead of ATI/AMD? I am still not really following. Rankine is an nvidia GPU architecture? These are all machines without expansion slots. The powerbook 12" has nvidia nv34 (geforce fx go5200), the others are various radeon r300 cards. The GPUs on those machines are soldered and cannot be changed. I have tried radeon r300 and nvidia nv34 machines (all the powerpc machines I have available) and DRI/GL is not working with new mesa packages on any.
Re: mesa update broke GL on nvidia nv34
On Mon, 21 Oct 2024 at 14:22, Ed Robbins wrote: > > Downgrading those packages fixes everything. They all interdepend so I > am not really sure why. But at least I can now report this... Bug report here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12048
Re: mesa update broke GL on nvidia nv34
On Mon, 21 Oct 2024 at 13:48, Steffen Grunewald wrote: > > Hi Ed, > > On Mon, 2024-10-21 at 13:41:20 +0100, Ed Robbins wrote: > > I suspect I know the answer to this, but I'm going to ask just in > > case: Are old .deb packages kept around online anywhere, or will I > > need to rebuild the old versions to test which one broke the install > > so I can report upstream? I've checked my apt cache and I don't have > > the original packages, presumably because they were installed during > > my initial installation. > > there's help just around the corner: > > http://snapshot.debian.org/archive/debian-ports/20240930T191757Z/pool-powerpc/main/m/mesa/ > > (any available timestamp before the version change would do I guess) > > Best, > Steffen Thank you Steffen, this is awesome! Downgrading those packages fixes everything. They all interdepend so I am not really sure why. But at least I can now report this...
mesa update broke GL on nvidia nv34
Hi, One of my machines is a powerbook 12" with nvidia nv34 chipset. Last week there was an update to mesa packages and since then opengl has stopped working. glxinfo reports "Error: couldn't find RGB GLX visual or fbconfig", other GL applications have similar issues. I believe the breaking upgrade was this one from 2024-10-17: Upgrade: libglx-mesa0:powerpc (24.1.6-1, 24.2.4-1), libgbm1:powerpc (24.1.6-1, 24.2.4-1), mesa-va-drivers:powerpc (24.1.6-1, 24.2.4-1), libgl1-mesa-dri:powerpc (24.1.6-1, 24.2.4-1), mesa-vulkan-drivers:powerpc (24.1.6-1, 24.2.4-1), libglapi-mesa:powerpc (24.1.6-1, 24.2.4-1), libegl-mesa0:powerpc (24.1.6-1, 24.2.4-1), mesa-vdpau-drivers:powerpc (24.1.6-1, 24.2.4-1) I suspect I know the answer to this, but I'm going to ask just in case: Are old .deb packages kept around online anywhere, or will I need to rebuild the old versions to test which one broke the install so I can report upstream? I've checked my apt cache and I don't have the original packages, presumably because they were installed during my initial installation. Thanks, Ed
Re: mesa update broke GL on nvidia nv34
Hi Leo, On Mon, 21 Oct 2024 at 15:32, Leo Historias wrote: > > Rankine is for retro elder lowend pcs,not ppc pcs like this. I'm think this was an autocorrect error (s/rankine/radeon/)? I'm still not quite sure what you mean though: Many apple powerpc machines have radeon hardware that is supported by the Linux radeon driver... basically anything with a radeon r300 series card: radeon 9500, 9550, 9600, 9700. Used on the last gen powerbook, ibook, emac, imac, mac mini etc. Ed
Re: mesa update broke GL on nvidia nv34
On Mon, 21 Oct 2024 at 19:24, Leo Historias wrote: > > What? Have you tried the Nouveau drivers? They might offer NV34 drivers. Perhaps a misunderstanding here: I'm not seeking advice on what packages to install, or how to modify my hardware configuration. A mesa package update has broken DRI, at least under nouveau nv30 and radeon r300 drivers on powerpc, but possibly in general on powerpc (I cannot say as I have no other hardware to test). I have provided a link to a bug report with further details in an earlier mail. Please re-read the chain and check the bug report if you need further details, we should try to keep mailing list noise to a minimum. Ed
Re: apm_emu module missing
Hi Riccardo, On Fri, 18 Oct 2024 at 08:44, Riccardo Mottola wrote: > > Hi Ed, > > Ed Robbins wrote: > > I believe that the apm_emu module is required for battery > > indicator/monitoring on certain powerbooks? > > > > It seems to be missing on latest kernels (6.3, 6.11). Can it be > > enabled for our config? > > > > Or, is there an alternative way to enable battery indicators? > > GNUstep battery monitor (batmon.app) supports directly the Apple PMU. > Didn't check if it is packaged on Debian though. > I didn't even know emulation of APM existed. > It has some minor shortcomings since it seems the kernel has some bogus > flags, I asked about this here in the mailing list a year ago and never > got an answer! So it can what I found though reverse engineering. > Well, the latest version of xfce4-battery-plugin supports neither APM nor upower nor the apple PMU in some more direct way. So fixing upower does not actually resolve my original problem directly either. But there is some other battery indicator in the xfce panel by default that does support upower, and the xfce power preferences also seems to support upower. So if upstream accept a patch for upower support this will be acceptable to me. However if the apm_emu module would be useful for other desktop environments I can submit a patch to add it to the default debian powerpc kernel config as suggested by Adrian? It appears the GNUstep battery monitor does support APM. I submitted a kernel patch to fix upower support this morning [1]. Ed [1] https://lore.kernel.org/linux-pm/iofjls.120oj5kjg9...@googlemail.com/T/#u
Re: apm_emu module missing
On Thu, 17 Oct 2024 at 17:54, Ed Robbins wrote: > > On Thu, 17 Oct 2024 at 16:51, John Paul Adrian Glaubitz > wrote: > > > > Hi Ed, > > > > On Thu, 2024-10-17 at 16:42 +0100, Ed Robbins wrote: > > > So I think that the apm_emu module should be included by default in > > > powerpc kernel builds. Is it possible to have it added to the kernel > > > config? > > > > Yes, this is possible. Someone needs to open a pull request with the > > corresponding change to the powerpc kernel configuration [1]. > > > > Adrian > > > > > [1] > > > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-powerpc/config?ref_type=heads > I spent some time looking at this again this evening, and it turns out that there is a much better solution. The macintosh PMU driver uses the Linux power supply subsystem and reports info about the battery, but it is not being picked up by the upower daemon because the driver does not give the battery type, so it comes out as "Unknown", and upower doesn't recognise it as battery: ed@powerbook12:~$ cat /sys/class/power_supply/PMU_battery_0/uevent DEVTYPE=power_supply POWER_SUPPLY_NAME=PMU_battery_0 POWER_SUPPLY_TYPE=Unknown ... ed@powerbook12:~$ sudo journalctl -u upower ... Oct 13 20:00:24 powerbook12 upowerd[994]: did not recognise type Unknown, please report ... ed@powerbook12:~$ upower -e /org/freedesktop/UPower/devices/line_power_pmu_ac /org/freedesktop/UPower/devices/DisplayDevice It turns out that adding a single line in the driver (drivers/power/supply/pmu_battery.c) is enough to fix this: pbat->bat_desc.type = POWER_SUPPLY_TYPE_BATTERY; After recompiling the module upower can see the battery and the default GUI indicators work as well. I will try to submit this change upstream. Ed
Re: Why it's so difficult to fix PowerMac booting for good
On Tue, 1 Oct 2024 at 23:38, Ed Robbins wrote: > > Hi Ben, > > On Fri, 2 Jun 2023 at 05:26, Ben Westover wrote: > > > > Hello, > > > > It turns out that adding &device; alone is not enough since it refers to > > only the drive and not the partition along with it. &device;:&partition; > > is what was actually needed. Fixed script is attached. > > I just tried this, and blessed the file with: > > hmount /dev/sda2 > hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX > humount > > But I see no difference upon rebooting the machine. Am I missing something? I played a bit more (without changing anything). The behaviour I get now is: If I just turn on the machine, it goes to the grub menu. If I hold down alt, I can choose between debian (with a nice logo but called "untitled"), Leopard and Tiger -> OS X options both work -> If I choose debian, I get a menu the same as the old yaboot first menu: Press l for Linux, x for mac os, c for cdrom -> x does boot mac os -> l takes me to the grub menu Thanks, Ed > > Thanks, > Ed > > > > > -- > > Ben Westover
libglib2.0-0t64 vs libglib2.0-0 dependencies
Hi all, I have noticed that there have been a few broken packages on the repository for some time, that presumably need to be rebuilt or fixed after libglib2.0 moved to t64. Notably I have been wanting to install xpra for a while but it has not been updated. Is this a problem specific to our port or is it a wider problem? Is it being tracked anywhere? A brief search didn't turn up anything. Thanks, Ed
Re: libglib2.0-0t64 vs libglib2.0-0 dependencies
29 Oct 2024 14:12:09 John Paul Adrian Glaubitz : > On Tue, 2024-10-29 at 15:10 +0100, John Paul Adrian Glaubitz wrote: >> Such situations can occur when the package in question or one of its build >> dependencies didn't build successfully. > > The former is true: > https://buildd.debian.org/status/package.php?p=xpra&suite=sid > > On this page, you will two bug reports referenced and both refer to an FTBFS. > > So, if you want to use xpra, someone needs to fix the package. > > Adrian Thanks Adrian. It turns out that the version in debian is ancient anyway, so I will just try to build a newer package. Ed > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: libglib2.0-0t64 vs libglib2.0-0 dependencies
On Sat, 2 Nov 2024 at 11:13, John Paul Adrian Glaubitz wrote: > > As for Pidgin, like I have explained, I cannot fix every bug in the > universe that affects PowerPC. I'm doing this just as a hobby and > I'm already investing quite a lot of time into this. I am not sure exactly what the issue is with pidgin, but if it's just a concern about availability of glib 2.0, then there is no need for concern. Glib 2.0 is still there, it's just been updated to use 64 bit time_t to avoid the 2038 problem. The change breaks the ABI, which means that packages that are dependent on glib 2.0 need to be rebuilt, that's all. Pidgin is available in the repository and presumably has already been rebuilt. xpra breakage seems to be unrelated to glib after all, it's just that the last version that built successfully and is in the debian repository was built against 32 bit time_t version of glib 2.0. The version of xpra in debian is too old to be really useful in any case (if I remember rightly it is version 3.something, and the latest version is 6.something). Ed
Re: apm_emu module missing
On Fri, 18 Oct 2024 at 09:20, Ed Robbins wrote: > I submitted a kernel patch to fix upower support this morning [1]. > Ed > > [1] https://lore.kernel.org/linux-pm/iofjls.120oj5kjg9...@googlemail.com/T/#u FYI this got accepted to Sebastian Reichel's tree and should appear in 6.13, after that battery and power monitoring for apple laptops should work again. Ed
Re: Installing on PowerBook G4 - grub failure
FWIW on most of my machines "boot ud:,\\yaboot" will boot from USB, but not all of them. On Thu, 26 Sept 2024 at 12:47, Steffen Grunewald wrote: > > On Tue, 2024-09-24 at 12:42:02 +0100, Mark Cave-Ayland wrote: > > > There are hints in some forum threads that the A1095 indeed may be one of > > > few (perhaps the only?) G4 models that cannot boot from USB. > > > BootROM version is 4.8.6f0, fwiw. > > > > That's frustrating. Can you confirm which partition contains the main > > filesystem by testing each number from 0 to 9 e.g. > > > >dir usb0:0,\ > >dir usb0:1,\ > >dir usb0:2,\ > >... > >... > >dir usb0:9,\ > > None of them (for usb1, including "dir usb1" and "dir usb1:") worked, > "DIR method failed" being the uniform result. > > Should I be able to run some "dir cd:..." (same image) successfully? > > Thanks, > Steffen >
Re: Why it's so difficult to fix PowerMac booting for good
Hi Ben, On Fri, 2 Jun 2023 at 05:26, Ben Westover wrote: > > Hello, > > It turns out that adding &device; alone is not enough since it refers to > only the drive and not the partition along with it. &device;:&partition; > is what was actually needed. Fixed script is attached. I just tried this, and blessed the file with: hmount /dev/sda2 hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX humount But I see no difference upon rebooting the machine. Am I missing something? Thanks, Ed > > -- > Ben Westover
Re: apm_emu module missing
Hi again, On Sun, 13 Oct 2024 at 22:04, Ed Robbins wrote: > > Hi all, > I believe that the apm_emu module is required for battery > indicator/monitoring on certain powerbooks? > > It seems to be missing on latest kernels (6.3, 6.11). Can it be > enabled for our config? > > Or, is there an alternative way to enable battery indicators? I recompiled the 6.11.2 kernel and added the apm_emu module. It does give extra compatibility with battery indicator software. xbattbar works, and although xfce4 battery plugin removed support for APM on Linux a couple of versions ago, I was able to build an older version (1.1.1) and it works perfectly with the latest xfce4, as long as apm_emu is present. So I think that the apm_emu module should be included by default in powerpc kernel builds. Is it possible to have it added to the kernel config? Thanks, Ed > > Thanks, > Ed
Re: apm_emu module missing
On Thu, 17 Oct 2024 at 16:51, John Paul Adrian Glaubitz wrote: > > Hi Ed, > > On Thu, 2024-10-17 at 16:42 +0100, Ed Robbins wrote: > > So I think that the apm_emu module should be included by default in > > powerpc kernel builds. Is it possible to have it added to the kernel > > config? > > Yes, this is possible. Someone needs to open a pull request with the > corresponding change to the powerpc kernel configuration [1]. > > Adrian > > > [1] > > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-powerpc/config?ref_type=heads Thanks Adrian, I will try to do it! Ed
