Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Void Linux for PowerPC

I noticed that we have a 5.7 kernel now.

Starting with 32-bit kernel versions 5.6 and newer, together with an appropriately compiled libc and userland, 32-bit Linux software has the potential to behave properly across the year 2038 limit using 64-bit time_t.

A syscall compatibility layer exists, to allow legacy binaries to continue interacting with the kernel using 32-bit time_t, bringing with it all the anticipated integer overflow problems which would be expected to begin occurring some time during the year 2038.

It appears that void is still shipping userland binaries that are compatible with older kernels, which would suggest to me that it must still be using 32-bit time_t, and relying on the compatibility layer to run them on the 5.7 kernel. Is there any possibility of a future update which shifts the libc and userland to a 2k38-ready state? (Yes, this would almost certainly sacrifice the ability to work with all kernels 5.5 and older.)
 
  • Like
Reactions: dextructor
q66_ said:
Anyway, as for the graphics stuff, 9200 is a fairly new card so it'll just work with the default KMS drivers and is not relevant to the previous conversation, which was about the xorg UMS driver, which indeed doesn't work with modern xorg.

As for mach64 and r128, we don't have 3D accel, as that would require packaging DRI drivers from Mesa 7.x, but the xorg driver (and 2D acceleration) should work for both. They use the legacy DRM infrastructure, so DRM is only used together with Mesa and doesn't deal with display, which is taken care of by the framebuffer driver. They don't do KMS at all.

But the Radeon 7xxx series are newer than r128/mach64. I don't have any hardware with that. I don't have hardware with mach64/r128 either, but it should work.

@wicknix it's not the VRAM on its own that makes the difference, it's that radeon 9200 and radeon 9700 are entirely different cores (the former is an opengl 1.3 card without unified shaders, the latter is a much more modern opengl 2.1 chip)

having shaders and stuff helps immensely with compositors, modern video players and so on which don't have fast fixed function paths anymore
Click to expand...
I've been experimenting with a couple of Macs:
- Quicksilver 800 MHz PowerMac G4 running a fresh install of 32-bit Void
- DP2.0 GHz PowerMac G5 running a fresh install of Big-Endian 64-bit Void

With a combination of video cards:
- Radeon 7500 AGP (G4 only due to the Apple Display Connector power tab being in a location that's incompatible with the G5's AGP Pro slot)
- Radeon 9600 AGP (Both systems)
- Radeon 9200 legacy PCI (Both systems)

I get a usable graphical desktop with no apparent signs of instability with all hardware combinations. I see varying levels of performance, but the basic group of built-in apps work. The 7500 does not show any signs of flashing or crashing after several hours of up time.

(On the G4, I need to manually load the snd-powermac kernel module to make sound work; I created a comment a few months back on the open GitHub FAQ TODO issue about this requirement.)

Web browsing is a mixed bag, with Firefox on the G5 being the only graphical browser I've seen fully functional so far.

On the G5, Firefox "works" with both the 9600 AGP and the 9200 legacy PCI graphics cards; I wouldn't be surprised if the 9600 gave better performance but I didn't seriously test this. Both Midori and Epiphany try to render web pages, but the result is "washed out" and impossible to use.

On the G4, with the 7500 AGP, Midori and Epiphany both try to load web pages, but all I get is a blank white window after the first page finishes loading. With the 9200 PCI, I get similar results, except that the window seems to end up black instead of white. With the 9600 AGP, Epiphany and Midori give the same "washed out" effect that I see on the G5.

(edit: The version of Epiphany that is included in the April XFCE live image does work normally on the G4 with all graphics cards tested. So whatever is wrong, it must be a change that has been introduced since that image was created.)
 
Last edited:
  • Like
Reactions: ks23, z970 and dextructor
goosnarrggh said:
I noticed that we have a 5.7 kernel now.

Starting with 32-bit kernel versions 5.6 and newer, together with an appropriately compiled libc and userland, 32-bit Linux software has the potential to behave properly across the year 2038 limit using 64-bit time_t.

A syscall compatibility layer exists, to allow legacy binaries to continue interacting with the kernel using 32-bit time_t, bringing with it all the anticipated integer overflow problems which would be expected to begin occurring some time during the year 2038.

It appears that void is still shipping userland binaries that are compatible with older kernels, which would suggest to me that it must still be using 32-bit time_t, and relying on the compatibility layer to run them on the 5.7 kernel. Is there any possibility of a future update which shifts the libc and userland to a 2k38-ready state? (Yes, this would almost certainly sacrifice the ability to work with all kernels 5.5 and older.)
Click to expand...
Partially answering my own question: The two libc's which are supported by Void are glibc and musl.

musl made the transition to 64-bit time_t on 32-bit systems starting with release 1.2; Void is currently shipping 1.1.24.

glibc was supposed to make the transition to uniformly use 64-bit time_t on 32-bit systems starting with release 2.32, but the release notes for 2.32 (which was just released a few days ago) makes sparse mention of it so I suspect it's still a work-in-progress for most architectures; in any event, Void is currently shipping 2.30.
 
  • Like
Reactions: dextructor
i feel like everything's slow on my A1095. the graphics acceleration doesn't work really well (radeon 9700 mobile 128MB) and it doesn't seem to detect the battery which is odd. any ways i can fix this?
 
superlions16 said:
i feel like everything's slow on my A1095. the graphics acceleration doesn't work really well (radeon 9700 mobile 128MB) and it doesn't seem to detect the battery which is odd. any ways i can fix this?
Click to expand...
Turn off the compositor that's enabled by default in xfce. It will solve the sluggishness of the graphics. It's in a GUI setting somewhere. I'd look, but i removed xfce and installed IceWM as it's more lightweight (and i personally like icewm). As for battery, you'll have to modprobe pmu_battery then log out and log back in. To make that stick between reboots i just added
Code: 
modprobe pmu_battery
to /etc/rc.local

Cheers
 
  • Like
Reactions: smnbldwn, alectrona6400 and dextructor
@wicknix As I was testing out a self-built Arctic Fox 27.10.2a on my Void PPC32 glibc machine, I noticed that sometimes certain text seems to render into something totally incomprehensible. This happens very commonly, for example, in Github.com's rendering of a repository's readme.md.

I saw similar symptoms with the commonly distributed prebuilt version of 27.10.1 for PPC32/Linux/glibc.

Are you aware of any outstanding issues which might account for that?
 
Have a screenshot? I have not noticed it at all on Ubuntu or void32. I do however have similar issues on void64 and debian64. The desktop randomly displays weird fonts/characters along with everything else. A reboot is required for it to go back to normal (for awhile). Happens randomly. My guess is its a gfx driver issue.

Cheers
 
wicknix said:
Have a screenshot? I have not noticed it at all on Ubuntu or void32. I do however have similar issues on void64 and debian64. The desktop randomly displays weird fonts/characters along with everything else. A reboot is required for it to go back to normal (for awhile). Happens randomly. My guess is its a gfx driver issue.

Cheers
Click to expand...
Here are a couple of examples:

2020-08-27-104133_1440x761_scrot.png
2020-08-27-104120_1440x761_scrot.png
 
Yikes. Nope, never seen that. Could it be you are missing some fonts? I always install extra font packages for things like gimp and OpenOffice. That's all I can think of. Or check AF prefs and make sure you haven't disabled "use sites fonts" or something to that nature.

Cheers
 
I want to start the live CD on my G5 2x2 GHz with AGP NV 7800GS, but at the end i get a black screen with a hanging cursor at the top left and after a time fans going to max. With a Radeon 9800 Pro i can start the CD.

Any solution to start the CD with the 7800GS?
 
Last edited:
-MB- said:
Hi,

I did try both kernels on but stuck here. I can’t go any further than this. What to do now?

View attachment 906650
Click to expand...

Had the same issue right after installing from the April ISO. What helped to resolve this is resetting the nvram in OpenFirmware:
Code: 
reset-nvram
reset-all

After that I could see the GRUB prompt and boot into Void.

My impressions so far after a couple of hours of using the ppc64-glibc version on a PM G5 DP1.8 PCI-X equipped with a Radeon 9650:

1. The installation was much simpler than I imagined. The trickiest bit was the partitioning which was where the documentation (kudos q66_!) came in useful and easy to digest.
2. On the initial run with the 5.4 kernel, the XFCE UI was lagging randomly. Sometimes the mouse would get stuck, then jump all over. I had this effect ages ago on an OpenBSD laptop - couldn't tell if it was due to graphical drivers or something else.
3. An easy upgrade with xbps-install -Su fixed it and made the system responsive and usable!

My next goal is finding a working Telegram client. Telegram-desktop from the official repos had graphical issues and couldn't connect to the server. Also not sure if a later than the ESR Firefox release is available.

UPDATE:

I've been trying to get the Radeon to output 2560x1440 to the 27" monitor in Linux. So far I had no success despite the card working in full resolution in OS X and MorphOS.

1. With the DVI-0 port connected: The GRUB "window" is small and crisp (you can tell it's native resolution), Void starts booting and after the KMS event the screen turns to black with the message "Timing not supported, make sure you set it to 2560x1440@60". It then flickers again (when starting LXDM) to the same message.

2. With the DVI-1 port connected: The GRUB "window" is blurry and stretched and so are the subsequent boot messages. Void boots normally and goes into LXDM at 1920x1080. While in LXDE there is no way to go to the higher resolution. Apparently DVI-1 is a single link port. The desktop is responsive and everything appears to be working normally.

3. DVI-0 and setting video=2560x1440 results in the artifacts. Upon KMS, the tty text becomes shaky with vertical scan lines. The LXDM colors are inverted / trippy. When logging in, the desktop is stretched and unusable, colors are borked.

4. Booting with DVI-1 and setting a custom Modeline in the Xorg config to 2560x1440, then hot-swapping to DVI-0 with xrandr results in a very laggy desktop - albeit working at full resolution! Vertical scrolling in any application (e.g. Firefox) is unbearably slow and the system eventually hangs.

Some observations so far:
- Xorg logs show the PixelRate of 285. Apparently I need at least 311 (according to the custom modeline) to go full res
- Setting the video= kernel parameters affects the X resolution (unless overridden in the Xorg configuration file)
- Setting a different refresh rate in a custom modeline doesn't seem to be affecting the performance - I can see the same symptoms as in (4) above.
 
Last edited:
  • Like
Reactions: dextructor
I have temporarily switched away from booting Void on my Powermac as I wanted to multi-boot other OSes and couldn't find a way around GRUB.

What I did instead is set up a Void chroot environment:
1. Installed the Ubuntu 16.04 remix
2. Downloaded https://repo.voidlinux-ppc.org/live/current/void-ppc64-ROOTFS-20200411.tar.xz
3. Extracted and mounted the chroot environment:

Code: 
mkdir void && cd void
tar xvf ../void-ppc64-ROOTFS-20200411.tar.xz
mount -o bind /sys void/sys
mount -o bind /tmp void/tmp
mount -o bind /dev void/dev
mount -o bind /proc void/proc
xhost +local:
sudo chroot void

Given this I was able to get the fresh versions of Void packages running on the Ubuntu. I imagine this could come in handy whilst using wicknix's suspend/resume capable 12.04 remix.

Was super excited to see Firefox 81.0.1 in the repos. It is indeed working and seems very fast (by PowerPC standards). Images have a blue coloration to them which seems like an expected big endian artifact.
 
  • Like
Reactions: repairedCheese and wicknix
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back