yaboot installation media
Hello, I haven't been able to get any GRUB installation media to work on my PowerMac G4. I've tried Debian, Gentoo, and Arch Linux, and every time it doesn't recognize GRUB at all. Even attempting to boot manually from Open Firmware just hangs. In all situations where I've tried, this issue has been solved with yaboot. I tried to create some yaboot install media, but I've seen that it would require patching debian-installer and I'm not sure where to start with that. If anyone could help in this process of creating install media that uses yaboot instead of GRUB, it would help me out tremendously. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: yaboot installation media
Hello, try these https://www.debian.org/ports/powerpc/inst/yaboot-howto/ http://seb.france.free.fr/linux/ibookG4/iBookG4-howto-2.html My issue lies with actually booting the install media. These are of no help to me; I already know how yaboot works. it would not surprise me if the default for grub is now EFI and of course there is a snowball in hell's chance EFI was around for G4s. the BIOS was based on BSD. We're using grub-ieee1275, IEEE-1275 being the specification for Open Firmware. There is no issue getting GRUB to run on my G3, and most others are having success on their machines, but my G4 just refuses to recognize GRUB in any way, only yaboot. Thanks for your quick response, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: yaboot installation media
Hello Jeffrey, Maybe you should try to reset the nvram? From the OF prompt, I believe the commands are reset-nvram and reset-all. Just tried that, unfortunately no effect. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: yaboot installation media
In case it's useful, here's the exact system I have: https://everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350.html It's running Open Firmware 3.1.1 (1.2f2 BootROM). This is what it came with, and I was unable to find any upgrades online for this particular model. -- Ben Westover signature.asc Description: PGP signature
Re: yaboot installation media
Hello Adrian, What is more likely is that you have bad memory modules in your machines and Yaboot just happens to use different memory regions which is why it's not affected by the problem. Hmmm… this computer came from my High School's IT department, so its RAM was upgraded by High Schoolers and may very well be bad. I just never thought it was because I never ran into issues on OS X or the 2019 snapshot of Debian I got installed with yaboot. I would suggest running a memory tester to check your RAM's health or replace all modules with known good ones. Also, make sure that the machine has reasonable amounts of memory. I believe I have 384 MB. What program should I use for this? You can either use the last stable installation images for PowerPC: https://cdimage.debian.org/cdimage/archive/7.11.0/powerpc/iso-cd/ and then upgrade from Wheezy to unstable but that's not going to be easy. Why Wheezy when Jessie is available? Is that image not stable? Or, you can use one of the older ISO images for PowerPC which were still based on Yaboot: https://cdimage.debian.org/cdimage/ports/9.0/powerpc/iso-cd/ https://cdimage.debian.org/cdimage/ports/10.0/powerpc/iso-cd/ https://cdimage.debian.org/cdimage/ports/snapshots/ (anything before May 2019 should be Yaboot) Yeah, I've already managed to get the April 20 2019 image running. Upgrading to the latest sid is a nightmare though; I'll have to go in small steps utilizing snapshot.debian.org if this is the case. Reverting the installer system back to Yaboot is not an option for us since that would bring much more problems than it would solve. In particular, Yaboot is no longer maintained upstream, does not work with modern filesystems and does not allow debian-cd and debian-installer code to be shared with other architectures as can be done with GRUB. Yeah, I've already been made well aware of this. I'm not asking for debian-installer to switch back to yaboot, many people are having success with GRUB; I was just asking for assistance in creating my own special 2022 yaboot image. Thanks for all this useful info, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: yaboot installation media
Hello, Bad memory modules can actually result in such weird behavior. We've seen similar reports before. When I have time, I'll run a memory test. Can this be done from OF? What commands should I use? You can also create a fresh chroot from unstable using debootstrap and that pivot the root file systems. Good idea. I didn't think about debootstrap. Creating custom images takes quite some work. An outdated guide can be found here: https://wiki.debian.org/PortsDocs/CreateDebianInstallerImages?highlight=%28%5CbCategoryPorts%5Cb%29 I actually got pretty far in my original attempt; I got stuck in the part where I had to patch d-i for yaboot. These new ideas of a memory fix and using debootstrap for a new chroot give me hope. Thanks again, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: yaboot installation media
Hello, A thank you goes out to all the people who have attempted to help me. In all the excitement of this endeavor, my G4's motherboard has died. Based on previous discussion, I believe the culprit in its failure to load GRUB was the system's memory. Upon closer inspection of the machine during its autopsy, I found that the memory was mixed and matched with all four sticks having different capacities, speeds, and brands. Seemingly the only PowerMac in the world that fails to boot GRUB has officially kicked the bucket. Thanks for all the help, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: yaboot installation media
Hello Sam, If I try to boot from Open Firmware, I try "boot usb1/disk@1:,\\grub.img" and the error after quite a long pause is "can't OPEN: usb1/disk@1:,\\grub.img Can't open device or file" Of course I can't rule out the possibility that I'm using Open Firmware wrong, after some searches of this list and on the Internet I didn't specifically find a description of the boot line and I'm really not an OF wizard. GRUB is located at /boot/grub/powerpc.elf most of the time. The command you're looking for is `boot usb1/disk@1:,\boot\grub\powerpc.elf`. You can also see what's on it with the command `dir usb1/disk@1:,\`, adding directories at the end to go deeper. My G4 was unable to even recognize USBs in Open Firmware, but the fact that yours showed up is a good sign. That means it should be able to boot from the drive provided it can read the filesystem. I use variations of these commands on my G3 all the time with success, and some others have managed to get them to work on their G4s. The NetBSD installation guide for macppc[1] was a wonderful resource about all these Open Firmware commands (I believe it was even cited in the Debian Wiki as being a massive help). [1] https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.2/macppc/INSTALL.html Regards, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: GRUB Multiboot
Hello Stan, unfortunately, I'm neither an OF expert nor a programmer, but I would guess that the best way to make GRUB boot Mac OS and Mac OS X would be for it to do whatever yaboot does. I believe all yaboot does is ask OF to boot to the partition containing the original bootloader of OS X. When we dual boot OS X and Linux on a PPC Mac, we just shrink the OS X partition then put our own partitions after it, and tell OF to boot to the new Linux boot partition instead of the old OS X one. When you tell yaboot to boot to OS X, all it's doing is telling OF to boot to that original OS X boot partition. I don't know if GRUB has the ability to do that, but it would certainly be useful. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: yaboot installation media
Hello, I've been able to get the G4 working again. The issue recognizing GRUB does not seem to be memory-related, as I tried each stick one at a time and was never able to boot to GRUB. This shows that unless they're all somehow faulty in the same exact way that manages to not affect normal operation, memory is not the issue. In other news, my G3 memory upgrade arrived yesterday, and the system was able to boot perfectly into the latest Debian and worked well. I will be using this machine to attempt to port Arch Linux to PowerPC. Does anybody have any more ideas to diagnose my G4's complete inability to recognize or boot GRUB? Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Apple PowerPC G5 7,2 No GUI NVIDIA FX 5200
Hello, On 5/20/22 4:20 PM, Guido R. Rolón A. wrote: > Thanks, I'll check it out. > > On Fri, May 20, 2022 at 4:07 PM Jeffrey Walton <mailto:noloa...@gmail.com>> wrote: > > On Fri, May 20, 2022 at 3:54 PM Guido R. Rolón A. <mailto:gro...@gmail.com>> wrote: > > > > Hi all this is my first time here and my first time with an Apple > Machine > > > > My setup is a > > Apple PowerMac7,2 5.1.5f2 BootROM built on 09/21/04 at 11:58:53 > > 5.1.5 - Power Macintosh G5 (Omega, June 2003) > > Model No.: A1047 EMC No.: 1969 > > Serial NO: YM337XX > > Ethernet ID: 000A9597FAE2 > > CPU 1.6GYHZ 970 > > RAM 4096MB 333 > > DISK 160GB HD > > DVD-R/CDRW > > NVIDIA GF5200 Ultra > > 56K Modem > > > > I have managed to install Debian Linux 11 > (debian-11.0.0-ppc64-NETINST-1.iso), CD-ROM Install > > With no errors during installation. > > First problem, blank screen after first boot, > > Access with ssh to this machine and edited /etc/default/grub > > GRUB_CMDLINE_LINUX_DEFAULT="text quiet nomodeset" > > Then > > update-grub2 > > and finally > > reboot > > i can access console, text mode > > NO GUI, > > > > Tried X -configure > > and > > X, > > No screen detected > > This may help: https://wiki.debian.org/NvidiaGraphicsDrivers > <https://wiki.debian.org/NvidiaGraphicsDrivers> > > When I had problems with the NVIDIA card, I took the NVIDIA card out, > and installed a Radeon card instead. > > Jeff That doesn't look like the right place to go. From what I can see, that page is about the proprietary driver, which won't work on your card. You're looking for Nouveau, which should be built in. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Boot fails
Hello David, On August 6, 2022 2:06:41 PM EDT, David VANTYGHEM wrote: >I've got this error : https://ibb.co/tLfS8np > >Is it a problem with my DVD? How much RAM do you have installed? This message implies that you either don't have enough RAM or the RAM is malfunctioning. -- Ben Westover signature.asc Description: PGP signature
Re: Boot fails
On 8/6/22 17:41, David VANTYGHEM wrote: I've got 128 MB RAM, the standard RAM on this model. That's probably not enough. When I got my iMac G3, it had 128 MBs in it, and Arch would not boot, same error. I never tried Debian back then, but after a RAM upgrade both Arch and Debian booted fine. It would be interesting to add the new version of Memtest86+ in GRUB menu, so one could test the RAM at boot, like with some other distros (Linux Mint...). https://www.memtest.org That's only for x86(_64). I think there's a variant available for ARM, but none that I know of for PowerPC, especially not Big Endian PPC. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Boot fails
Hi David, On 8/11/22 7:54 AM, David VANTYGHEM wrote: > I upgraded RAM to 1 Go and it's booting now. Thank you for your help. > > I installed Debian, all is OK, excepted with ATI128, Xorg doesn't start. Did you install the correct driver xserver-xorg-video-r128? -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Boot fails
David, On August 11, 2022 11:27:55 AM EDT, David VANTYGHEM wrote: >>> I installed Debian, all is OK, excepted with ATI128, Xorg doesn't start. >> Did you install the correct driver xserver-xorg-video-r128? > >No, it's too difficult for me. I will wait until it will be added to Debian. >Now, I will test Debian in a Qemu VM. It has been in Debian for decades… -- Ben Westover signature.asc Description: PGP signature
Re: Boot fails
David, On August 11, 2022 11:40:37 AM EDT, David VANTYGHEM wrote: >> It has been in Debian for decades… > >No, it has been removed because too old and not maintained. > >Do you think it has been added again by Adrian? > >https://lists.debian.org/debian-powerpc/2020/05/msg00156.html https://packages.debian.org/sid/xserver-xorg-video-r128 The email you sent is two years old and says it will be re-added "soon". As you can see, the package is alive and well. -- Ben Westover signature.asc Description: PGP signature
Re: Seeking for help with Debian 11 (2022-03-28 image) - can't install GRUB
Hello, On October 5, 2022 5:37:35 PM EDT, vavagoga wrote: >Hey there! > >I've been advised by kaiser.friedrich on youtube to join this list for more >detailed help with my problem.. > >I am trying to install Debian on my old G5, but installation always fail >during "Select and install software" and then also during GRUB installation.. >Maybe I am missing something during installation? (It seems straightforward, >but fails nevertheless) Can you provide any specific errors or logs? Thanks, -- Ben Westover signature.asc Description: PGP signature
Re: Seeking for help with Debian 11 (2022-03-28 image) - can't install GRUB
On 10/13/22 7:19 PM, vavagoga wrote: > Oh yeah, I have found it in /var/log/installer, thanks for the tip! > > But, when I try to compress it - it says: permission denied.. hmm.. why > is that? Is ther any work around for that? You don't have permission to write to that directory. Tell tar to output somewhere else, like your home directory, with -C. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking for help with Debian 11 (2022-03-28 image) - can't install GRUB
On 10/13/22 8:12 PM, vavagoga wrote: > Thanks for the suggestion! But... hmm... well.. I tried to output it to > my home dir and also tried copying the whole install directory to the > desktop and also my home directory, but it keeps on saying I don't have > permission... So my guess is it looks like I don't actually have read > permission to do anything with that "install" directory.. Use sudo/root -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Xorg segfaults on iMac G3 with Rage 128 Pro
Hello, I have an iMac G3 with a Rage 128 Pro and 1 GB of RAM. I tried to install and run Xfce4, but Xorg segfaults when I try to start it. The full Xorg log is attached, but here is the backtrace at the end: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x240) [0xac4a60] (EE) 1: linux-vdso32.so.1 (?+0x0) [0xa7b92400] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 2: /usr/lib/xorg/modules/drivers/r128_drv.so (?+0x0) [0xa6e8cc98] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 3: /usr/lib/xorg/modules/drivers/r128_drv.so (?+0x0) [0xa6e8cdf8] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 4: /usr/lib/xorg/modules/drivers/r128_drv.so (?+0x0) [0xa6e890b4] (EE) 5: /usr/lib/xorg/Xorg (InitOutput+0xa04) [0x941a74] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x23c) [0x8efd1c] (EE) 7: /usr/lib/xorg/Xorg (miPolyFillRect+0xe1c) [0x8d1fa4] (EE) 8: /lib/powerpc-linux-gnu/libc.so.6 (__libc_init_first+0xa0) [0xa793a280] (EE) 9: /lib/powerpc-linux-gnu/libc.so.6 (__libc_start_main+0x1e0) [0xa793a4c0] (EE) unw_get_proc_info failed: no unwind info found [-10] (EE) Segmentation fault at address 0x48 My system is up to date as of April 15, 2023; I'm running kernel 6.1.0-7-powerpc with Mesa 22.3.6. Does anyone how to fix this problem? Thanks, -- Ben Westover [ 154.957] X.Org X Server 1.21.1.7 X Protocol Version 11, Revision 0 [ 154.958] Current Operating System: Linux iMacG3 6.1.0-7-powerpc #1 Debian 6.1.20-2 (2023-04-08) ppc [ 154.958] Kernel command line: BOOT_IMAGE=/boot/vmlinux-6.1.0-7-powerpc root=UUID=3b090de3-b669-4818-8bb3-8f0cfbb6fe9e ro quiet [ 154.959] xorg-server 2:21.1.7-2 (https://www.debian.org/support) [ 154.960] Current version of pixman: 0.42.2 [ 154.960] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 154.960] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 154.963] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 15 15:33:21 2023 [ 155.254] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 155.793] (==) No Layout section. Using the first Screen section. [ 155.794] (==) No screen section available. Using defaults. [ 155.794] (**) |-->Screen "Default Screen Section" (0) [ 155.795] (**) | |-->Monitor "" [ 155.875] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 155.876] (==) Automatically adding devices [ 155.876] (==) Automatically enabling devices [ 155.876] (==) Automatically adding GPU devices [ 155.876] (==) Automatically binding GPU devices [ 155.876] (==) Max clients allowed: 256, resource mask: 0x1f [ 156.196] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 156.196] Entry deleted from font path. [ 156.512] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 156.512] (==) ModulePath set to "/usr/lib/xorg/modules" [ 156.512] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 156.575] (II) Loader magic: 0xb907b0 [ 156.576] (II) Module ABI versions: [ 156.576] X.Org ANSI C Emulation: 0.4 [ 156.576] X.Org Video Driver: 25.2 [ 156.576] X.Org XInput driver : 24.4 [ 156.576] X.Org Server Extension : 10.0 [ 156.589] (++) using VT number 1 [ 156.589] (--) controlling tty is VT number 1, auto-enabling KeepTty [ 156.610] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_33 [ 156.629] (--) PCI:*(0@0:16:0) 1002:5052:1002:5052 rev 0, Mem @ 0x9400/67108864, 0x9000/16384, I/O @ 0x0400/256, BIOS @ 0x/131072 [ 156.777] (II) LoadModule: "glx" [ 157.177] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 158.846] (II) Module glx: vendor="X.Org Foundation" [ 158.846] compiled for 1.21.1.7, module version = 1.0.0 [ 158.846] ABI class: X.Org Server Extension, version 10.0 [ 158.847] (==) Matched ati as autoconfigured driver 0 [ 158.847] (==) Matched modesetting as autoconfigured driver 1 [ 158.847] (==) Matched fbdev as autoconfigured driver 2 [ 158.847] (==) Assigned the driver to the xf86ConfigLayout [ 158.847] (II) LoadModule: "ati" [ 158.849] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so [ 158.933] (II) Module ati: vendor="X.Org Foundation" [ 158.933] compiled for 1.21.1.3, module version = 19.1.0 [ 158.933] Module class: X.Org Video Driver [ 158.933] ABI class: X.Org Video Driver, version 25.2 [ 158.934] (II) Loa
Re: Xorg segfaults on iMac G3 with Rage 128 Pro
Hi, On 4/15/23 10:56 PM, Paul Wise wrote: I think you will need to do some debugging, there are some tips here: https://x.org/wiki/Development/Documentation/ServerDebugging/ I'm probably doing something wrong (never used gdb before), but Xorg closes almost instantly after I run it so there's not enough time to launch gdb before it's already segfaulted. It sounds like these tips are for when Xorg launches and runs for a bit but crashes when a specific action is performed. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Xorg segfaults on iMac G3 with Rage 128 Pro
Hello,
On 4/16/23 10:18 PM, Paul Wise wrote:
There is also the case where you launch Xorg via gdb and then run it.
$ gdb `which Xorg`
(gdb) run
(gdb) bt full
Perfect! I was able to get a full backtrace, which is attached. Here's
the part that I think is important:
Program received signal SIGSEGV, Segmentation fault.
0xa6e7cc98 in R128GetConnectorInfoFromBIOS (pScrn=pScrn@entry=0x776620,
otypes=otypes@entry=0xa0f4) at ../../src/r128_output.c:432
432 ../../src/r128_output.c: No such file or directory.
(gdb) bt full
#0 0xa6e7cc98 in R128GetConnectorInfoFromBIOS (pScrn=pScrn@entry=0x776620,
otypes=otypes@entry=0xa0f4) at ../../src/r128_output.c:432
info = 0x776ed0
bios_header =
offset =
i = 2
Here's part of the relevant funtion in r128_output.c [1]:
void R128GetConnectorInfoFromBIOS(ScrnInfoPtr pScrn, R128OutputType *otypes)
{
R128InfoPtr info = R128PTR(pScrn);
uint16_t bios_header, offset;
uint32_t i;
for (i = 0; i < R128_MAX_BIOS_CONNECTOR; i++) {
otypes[i] = OUTPUT_NONE;
}
/* non-x86 platform */
if (!info->VBIOS) {
otypes[0] = OUTPUT_VGA;
}
bios_header = R128_BIOS16(0x48);
There's more after this, but it seems to crash at that last line,
failing to read the memory at 0x48 to get the BIOS' connector info.
The last version of Debian that I successfully ran Xorg on this machine
with was jessie, so it's not like the r128 driver has never worked on
PowerPC. I don't know how recent this breaking change was since I never
ran Xorg on my Debian sid install until now. Hopefully this information
is useful to someone who knows what to do with it!
Thanks,
--
Ben Westover
[1]
https://sources.debian.org/src/xserver-xorg-video-r128/6.12.1-1/src/r128_output.c/
(gdb) run
Starting program: /usr/lib/xorg/Xorg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
Current Operating System: Linux iMacG3 6.1.0-7-powerpc #1 Debian 6.1.20-2
(2023-04-08) ppc
Kernel command line: BOOT_IMAGE=/boot/vmlinux-6.1.0-7-powerpc
root=UUID=3b090de3-b669-4818-8bb3-8f0cfbb6fe9e ro quiet
xorg-server 2:21.1.7-2 (https://www.debian.org/support)
Current version of pixman: 0.42.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 17 18:34:08 2023
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Program received signal SIGSEGV, Segmentation fault.
0xa6e7cc98 in R128GetConnectorInfoFromBIOS (pScrn=pScrn@entry=0x776620,
otypes=otypes@entry=0xa0f4) at ../../src/r128_output.c:432
432 ../../src/r128_output.c: No such file or directory.
(gdb) bt full
#0 0xa6e7cc98 in R128GetConnectorInfoFromBIOS (pScrn=pScrn@entry=0x776620,
otypes=otypes@entry=0xa0f4) at ../../src/r128_output.c:432
info = 0x776ed0
bios_header =
offset =
i = 2
#1 0xa6e7cdf8 in R128SetupConnectors (pScrn=pScrn@entry=0x776620) at
../../src/r128_output.c:471
info = 0x776ed0
pR128Ent = 0x776a70
otypes = {OUTPUT_VGA, OUTPUT_NONE}
output =
num_vga = 0
num_dvi = 0
i =
#2 0xa6e790b4 in R128PreInitControllers (pInt10=0x0, pScrn=0x776620) at
../../src/r128_driver.c:1163
config = 0x778770
found = 0
i =
config =
found =
i =
output =
#3 R128LegacyMS (pScrn=0x776620) at ../../src/r128_driver.c:1371
info =
pInt10 = 0x0
ret = 0
freeInt10 =
info =
pInt10 =
ret =
exit =
freeInt10 =
#4 R128PreInit (pScrn=0x776620, flags=) at
../../src/r128_driver.c:1520
info =
#5 0x004c1a74 in InitOutput (pScreenInfo=pScreenInfo@entry=0x73a044
, argc=argc@entry=1, argv=argv@entry=0xa594) at
../../../../../../hw/xfree86/common/xf86Init.c:478
i = 0
j =
k =
scr_index =
modulelist =
optionlist = 0x75c9e0
autoconfig =
sigio_blocked = 0
want_hw_access =
configured_device =
#6 0x0046fd1c in dix_main (argc=1, argv=0xa594, envp=) at
../../../../dix/main.c:190
i =
alwaysCheckForInput = {0, 1}
#7 0x00451fa4 in main (argc=, argv=,
envp=) at ../../../../dix/stubmain.c:34
No locals.
OpenPGP_signature
Description: OpenPGP digital signature
Re: Xorg segfaults on iMac G3 with Rage 128 Pro
On 4/18/23 10:44 PM, Paul Wise wrote: These are the macro definitions. #define R128_BIOS8(v) ((info->VBIOS[(v)])) #define R128_BIOS16(v) ((info->VBIOS[(v)]) | \ (info->VBIOS[(v) + 1] << 8)) #define R128_BIOS32(v) ((info->VBIOS[(v)]) | \ (info->VBIOS[(v) + 1] << 8) | \ (info->VBIOS[(v) + 2] << 16) | \ (info->VBIOS[(v) + 3] << 24)) Please try these gdb commands once you hit the crash point: print info print info.VBIOS print info->VBIOS print info->VBIOS[0x48] print info->VBIOS[0x49] (gdb) print info $1 = (R128InfoPtr) 0x776ed0 (gdb) print info.VBIOS $2 = (uint8_t *) 0x0 (gdb) print info->VBIOS $3 = (uint8_t *) 0x0 (gdb) print info->VBIOS[0x48] Cannot access memory at address 0x48 (gdb) print info->VBIOS[0x49] Cannot access memory at address 0x49 -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Xorg segfaults on iMac G3 with Rage 128 Pro
Hello,
On 5/7/23 3:14 AM, Paul Wise wrote:
If you add a return statement like this, does that fix the crash?
/* non-x86 platform */
if (!info->VBIOS) {
otypes[0] = OUTPUT_VGA;
return;
}
Yes, it no longer segfaults. It goes past the point where it previously
crashed, but now I have a new error:
(WW) R128(0): Static buffer allocation failed -- need at least 36864 kB
video memory
(II) R128(0): Filling in EXA memory info
(II) R128(0): Setting up EXA callbacks
(II) R128(0): Initializing 2D acceleration engine...
(II) R128(0): Initializing EXA driver...
(EE) EXA(0): ExaDriverRec::offScreenBase must be <= ExaDriverRec::memorySize
(EE) R128(0): EXA Acceleration initialization failed.
(II) R128(0): Acceleration disabled.
(EE) R128(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE)
Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 0
Is this something I can fix, or does modern Xorg just need more VRAM?
Thanks,
--
Ben Westover
OpenPGP_signature
Description: OpenPGP digital signature
Can't upgrade kernel or GRUB: /boot/grub is a read-only filesystem
Hello, When I ran apt upgrade on my iMac G3, the kernel and GRUB packages failed to configure. The step that failed in each case was update-grub or grub-install, which failed when trying to write to the /boot/grub HFS partition because it's a "Read-only filesystem." Investigating /etc/fstab, even though it doesn't say to mount that partition read-only, it was mounted as "ro,relatime,uid=0,gid=0". I tried running `mount -o remount,rw`, but it still mounted as read-only. I also tried mounting it in a non-Debian live environment [1], using the rw option explicitly, but it was still mounted with those same options. It now makes sense why writing to the disk fails, as it seems any HFS mount is automatically read-only, but why is this only now breaking kernel upgrades? It can't have been a recent change to HFS mounting, since my live environment's ISO was from December 2022. Does anyone know what the problem here could be? Thanks, -- Ben Westover [1] https://archlinuxpower.org OpenPGP_signature Description: OpenPGP digital signature
Re: Can't upgrade kernel or GRUB: /boot/grub is a read-only filesystem
Hi Bob, On 5/7/23 9:40 PM, Bob McGowan wrote: I would suggest you run an fsck on the filesystem and see if there are any problems. Filesystems may be considered "required" for the system to function and be mounted read-only when problems are detected, to prevent further problems from developing while allowing the system to run. I had already run generic fsck on the filesystem, and it ran without any meaningful output, so I assumed it was clean. It turns out the real fsck.hfs program is inside the hfsprogs packages, not installed by default, instead of the hfsutils package that every new install comes with. One fsck.hfs later, the filesystem was repaired and became writable again. I wish either that the hfsprogs package was installed by default on powerpc, since it seems to be pretty important to have, or at least the system did something to tell me there was a problem other than just silently mounting it read-only. Thanks for your suggestion! -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Can't upgrade kernel or GRUB: /boot/grub is a read-only filesystem
Hello, On 5/7/23 10:15 PM, Paul Wise wrote: Possibly the filesystem is damaged, I suggest you check dmesg for errors when mounting it read-write and check the filesystem using the fsck tool from the hfsprogs package in your live environment. Yep, you were right. If I had just checked dmesg, I would've found this out sooner. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Debian on IBM RS/6000 7248-43p
On 5/11/23 7:26 AM, Gabriel Paubert wrote: I suspect it is hopeless, as far as I remember PReP support disappeared when the ppc and ppc64 kernel trees were merged into the single powerpc architecture. Arch Linux's unofficial ppc port lists instructions for installing on PReP machines [1], so unless they're inaccurate I would assume Linux still supports PREp. -- Ben Westover [1] https://github.com/kth5/archpower/wiki/Installation-%7C-KVM-or-PReP OpenPGP_signature Description: OpenPGP digital signature
Re: Why it's so difficult to fix PowerMac booting for good
Hello, On May 30, 2023 6:45:03 AM EDT, Linux User #330250 wrote: > > The last time I installed Debian SID with GRUB on a PowerBook Pismo, the > > Apple_Bootstrap partition was mounted as /boot/grub (it might have been > > /boot, I don't remember now). But it was a persistent mount. Everything > > worked, except Mac OS and Mac OS X volumes could not be boot from the > > menu (booting Mac OS X also doesn't work on an Intel Core 2 Duo system). > > Actually, I was able to boot Mac OS X from GRUB. But if I remember > correctly, I had to play with it a bit as it isn't intuitive... > os-prober might be helpful as a starting point. The GRUB Manual [1] says that the PPC port of GRUB only supports booting Linux at the moment. AFAIK booting macOS with GRUB on x86 machines works by just chainloading macOS' UEFI bootloader. I assume this is what yaboot does as well, telling Open Firmware to load OS X's blessed binary instead of the second stage of yaboot and Linux from there. All we need to do is find a way to support Open Firmware chainloading from within GRUB. -- Ben Westover [1] https://www.gnu.org/software/grub/manual/grub/grub.html#Supported-kernels
Re: Why it's so difficult to fix PowerMac booting for good
Hello, On May 30, 2023 12:42:39 PM EDT, Linux User #330250 wrote: > On 05/30 2023 17:13 Stan Johnson wrote: > > On 5/30/23 7:16 AM, Ben Westover wrote: > >> The GRUB Manual [1] says that the PPC port of GRUB only supports booting > >> Linux at the moment. AFAIK booting macOS with GRUB on x86 machines works > >> by just chainloading macOS' UEFI bootloader. I assume this is what yaboot > >> does as well, telling Open Firmware to load OS X's blessed binary instead > >> of the second stage of yaboot and Linux from there. All we need to do is > >> find a way to support Open Firmware chainloading from within GRUB. > > AFAIR yaboot does its magic within the CHRP boot script. It would be > relatively easy to add an option to load GRUB, I guess. The "chain" > would then start by choosing Mac OS (Classic), Mac OS X, or GRUB, via > the yaboot CHRP script. But then, GRUB would be only managing Linux. That makes a lot more sense now. The "first stage" of yaboot where you select Linux, OS X, or CD Boot is actually a script run by Open Firmware, and that's how it can so easily chainload, since it's just a script selecting which binary for Open Firmware to load. In that case, instead of trying to integrate chainloading functionality into GRUB itself, we could just set a similar script to run before GRUB that allows you to make that selection. -- Ben Westover
Re: Why it's so difficult to fix PowerMac booting for good
On 5/31/23 10:20 AM, Ben Westover wrote: AFAIR yaboot does its magic within the CHRP boot script. It would be relatively easy to add an option to load GRUB, I guess. The "chain" would then start by choosing Mac OS (Classic), Mac OS X, or GRUB, via the yaboot CHRP script. But then, GRUB would be only managing Linux. That makes a lot more sense now. The "first stage" of yaboot where you select Linux, OS X, or CD Boot is actually a script run by Open Firmware, > and that's how it can so easily chainload, since it's just a script selecting which binary for Open Firmware to load. In that case, instead of trying to integrate chainloading functionality into GRUB itself, we could just set a similar script to run before GRUB that allows you to make that selection. I have just tested this concept. I wiped my iMac G3, installed OS X and Debian, and put a modified version of yaboot's stage 1 script in the bootstrap partition and blessed it. Now I am greeted with a screen that asks me if I'd like to boot into Linux, OS X, or whatever's in the CD drive, and all of the options work, the Linux one loading right into GRUB. If I don't select an option after a bit it defaults to GRUB. This combines the convenience of yaboot with the versatility of GRUB, and only requires a single (relatively) human readable and editable file. The script is attached; the only change you should have to make is of the partition numbers, as it currently assumes /boot/grub is on partition 2 and OS X is on partition 3. -- Ben Westover MacRISC MacRISC3 MacRISC4 PowerPC GNU/Linux First Stage Bootstrap : .printf fb8-write drop ; : bootgrub " Loading GRUB..." .printf 100 ms load-base release-load-area " hd:2,\grub" $boot ; : bootmacosx " Booting Mac OS X..." .printf 100 ms load-base release-load-area " hd:3,\\:tbxi" $boot ; : bootcd " Booting CDROM..." .printf 100 ms load-base release-load-area " cd:,\\:tbxi" $boot ; " screen" output variable interactive 1 interactive ! 0 interactive @ = if bootgrub then dev screen " "(00aa00aaaaaa005500aa)" drop 0 7 set-colors " "(55ff55ffffff55ff55ff)" drop 8 15 set-colors device-end f to foreground-color 0 to background-color " "(0C)" .printf " First Stage Debian GNU/Linux Bootstrap"(0d 0a)" .printf " "(0d 0a)" .printf " Press l for GNU/Linux,"(0d 0a)" .printf " x for Mac OS X,"(0d 0a)" .printf " c for CDROM."(0d 0a)" .printf " "(0d 0a)" .printf " Stage 1 Boot: " .printf get-msecs d# 10 3E8 * + begin key? if key case ascii l of " l "(0d 0a)" .printf bootgrub endof ascii x of " x "(0d 0a)" .printf bootmacosx endof ascii c of " c "(0d 0a)" .printf bootcd endof endcase then dup get-msecs < until drop " "(0d 0a)" .printf bootgrub 1010 F8FEACF6 00F5FEFEF500 002BFAFEFAFCF700 00F65D5857812B00 00F5350B2F885600 00F6335708F8FE00 005600F600F5FD81 F9F800F5FAFFF800 8100F5F5F6FEFE00 00F8F700F500F5FCFFF7 0088F7F5F5FCFF2B 002F582A00F508ADE02C 00090B0A35A62B002D3B350A 000A0A0B0B3BF6505E0B0A0B0A00 002E350B0B2F87FAFCF45F0B2E09 0007335FF82BF72B57590700 AC81 00818100 00FBAC00 0081DFDFDB00 0081DD5F83FFFD00 0081DDDF5EACFF00 00FDF981F981 FFACF9F9F981AC00 FFF98181F9F98100 00ACACF981F981F9F9AC 00FFACF9F981F9F981FB 0083DFFBF981F9F95EFC 005F5F5FDDFFFBF9F9F9835F 005F5F5F5FDD81F9F9E7DF5F5F5F5F00 0083DD5F5F83DF5F835F 00FBDDDFACFBACFBDFDFFB00 0000 0000 0000 0000 0000 00FF FF00 FF00 00FF 00FF 00FF 00FF 0000 00FF 0000 OpenPGP_signature Description: OpenPGP digital signature
Re: Why it's so difficult to fix PowerMac booting for good
Hello, On June 1, 2023 1:01:49 PM EDT, Stan Johnson wrote: > Would this solution allow both PowerPC and Intel Macs to boot Mac OS? > Whichever solution is used would need to be supported by the GRUB > developers or Debian (perhaps through a GRUB patch or a separate package?). This script would not work on an Intel Mac as it's run by Open Firmware which was replaced by UEFI on the Intel devices. As stated before, there is nothing preventing GRUB from simply chainloading macOS' UEFI bootloader just as rEFInd, systemd-boot, etc would do. The only problem is that the boot entry os-prober generates for macOS is faulty in some way. Either fix os-prober or write your own boot entry for macOS with the correct EFI file, and you've solved the problem. Here's a hint: On macOS, there is no separate EFI partition, and the bootloader is stored in /System/Library/CoreServices/boot.efi on the main HFS+ root. As for how this script could be integrated into Debian, it should definitely not be put into the GRUB package. As Glaubitz has said, the goal is for as little PowerPC-specific patches to be put into these core packages as possible. GRUB's also not really the right place for a script that runs before it to enable booting other OSes more easily. It also wouldn't make sense to create a whole separate package just for one script file. Since the script is unnecessary for those who don't want to dual-boot, I don't know if it should really be included in Debian at all. -- Ben Westover signature.asc Description: PGP signature
How are CHRP bootinfo icons formatted?
Hello, Every Linux bootinfo file I've seen for PowerMacs has had either the GNU logo for GRUB or the Tux for yaboot. Here's an example of the Tux: 1010 F8FEACF6 00F5FEFEF500 002BFAFEFAFCF700 00F65D5857812B00 00F5350B2F885600 00F6335708F8FE00 005600F600F5FD81 F9F800F5FAFFF800 8100F5F5F6FEFE00 00F8F700F500F5FCFFF7 0088F7F5F5FCFF2B 002F582A00F508ADE02C 00090B0A35A62B002D3B350A 000A0A0B0B3BF6505E0B0A0B0A00 002E350B0B2F87FAFCF45F0B2E09 0007335FF82BF72B57590700 AC81 00818100 00FBAC00 0081DFDFDB00 0081DD5F83FFFD00 0081DDDF5EACFF00 00FDF981F981 FFACF9F9F981AC00 FFF98181F9F98100 00ACACF981F981F9F9AC 00FFACF9F981F9F981FB 0083DFFBF981F9F95EFC 005F5F5FDDFFFBF9F9F9835F 005F5F5F5FDD81F9F9E7DF5F5F5F5F00 0083DD5F5F83DF5F835F 00FBDDDFACFBACFBDFDFFB00 0000 0000 0000 0000 0000 00FF FF00 FF00 00FF 00FF 00FF 00FF 0000 00FF 0000 It seems like there are three different tuxes here, each one being 16x16 pixels and each pixel getting a byte in hex. The third tux seems to only have two pixel values, 0x00 and 0xFF. The GNU logo is formatted a bit differently. I won't post the whole thing here, but an example can be found at [1]. It also has three different bitmaps with each pixel getting a byte in hex, but now each one is 52x52 instead of 16x16, and the two-byte value above the bitmaps is 3434 instead of 1010. It seems that the difference between these is that the 52x52 GNU logo takes up the entire boot icon, while the 16x16 Tux appears in the bottom right corner of an HDD icon, similar to OS X. I spent a while searching for information on how exactly these icons are formatted so I can make a custom one with the Debian logo, and the best I could find is [2] which describes the original CHRP standard without any changes from Apple. It shows that the byte for each pixel can be calculated by giving the first three bits to red, the next three to green, and the last two to blue. Example: #008080 -> rgb(0, 128, 128) -> 00010010 -> 0x12. I created a Python script [3] that generates this bitmap from a 16x16 image file. The only problem is that the original CHRP standard doesn't have those second and third bitmaps, only the first one, and I can't find any resources explaining what the second and third ones are for and how they are formatted. I think that the third one might carry information about transparency, e.g. 0xFF for any pixel that should be drawn and 0x00 for transparent ones, but I have no idea what the second one is supposed to be and how I can create it. Since I can find absolutely no information about this anywhere, I'm asking here if anyone has any idea of how to format a CHRP icon. The developers of yaboot and GRUB must know, since they include the logos in the bootinfo files in their source code. Does anyone have any information that could point me in the right direction? Thanks, -- Ben Westover [1] https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC)#CHRP_boot_script [2] https://www.devicetree.org/open-firmware/bindings/chrp/chrp1_8a.ps [3] https://gist.github.com/benthetechguy/e31fb541c49a57f5f44c4c7cca79770c OpenPGP_signature Description: OpenPGP digital signature
Re: How are CHRP bootinfo icons formatted?
On 6/1/23 4:18 PM, Ben Westover wrote: I have no idea what the second one is supposed to be and how I can create it. One thing I tested was just making the first and second bitmaps the exact same. When I did this, it produced what looked like a color-inverted version of the image. So, the next thing I tested was creating an inverted version of the bitmap, and using that as the second one. This, however, produced the same result. I then tried making the inverted bitmap the first one and the regular one second, and I got an image that looked relatively close to the original. I also tested making them both the inverted bitmap, and this produced the same result. It seems to be that no matter what the second bitmap is changed to, even if you just make it all zeroes, the resulting image still stays the same. So, if you take a 16x16 image, invert its colors, and use the attached script to generate the three bitmaps (first and second being the actual image and third just being 0xFF where it's not transparent and 0x00 where it is), you can create an icon for a CHRP script. While this is a good enough method for something simple like the Debian logo, anything with more complex colors doesn't look right at all. This and the fact that changing the second bitmap doesn't seem to do anything confirms for me that this is most definitely not the correct way to do things, but the result of this method is certainly interesting and useful. Here's a Debian icon I was able to create with this: 1010 003E3E3E3A3E3A11 3E3E3E3E3E3E3E3E3E00 003E3E3E3E003A3E3E3E 3E3E3E3E003E3E3E 3A3E3E3E3E3E3E003E3E 3E3E003A36003E3A 3E3A3E3E3A003E3E 3E003E3E36003E3A 3E3E3A3E003A003E3A00 3E3A363A3E3E3E3E3E00 3E3E113E3E3E3E00 3E3E3E00 003E3E00 3E3E 3E3E3A00 3E3E3E00 00C1C1C1C5C1C5EE C1C1C1C1C1C1C1C1C100 00C1C1C1C100C5C1C1C1 C1C1C1C100C1C1C1 C5C1C1C1C1C1C100C1C1 C1C100C5C900C1C5 C1C5C1C1C500C1C1 C100C1C1C900C1C5 C1C1C5C100C500C1C500 C1C5C9C5C1C1C1C1C100 C1C1EEC1C1C1C100 C1C1C100 00C1C100 C1C1 C1C1C500 C1C1C100 00FF FF00 0000 00FF FF00 00FFFF00 FF00 FF00FF00 00FF0000 FF00 FF00 FF00 0000 FF00 FF00 Bonus version that is full-sized 52x52 like the GNU logo: 3434 003A3E36113E000D 3A3A3E3E3E3E3A363E3A3E3E3600 3A3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3A00 3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E1500 003A3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3A3A00 003A3A3E3E3E3E3E3E3E3E3E3E3A3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E3E 3E3E3E3E3E3E3E3E3E3E3E3A3E3E3E3E3E3E3E3E3600 003E3E3E3E3E3E3E3E3E3A3A003E3E3E3E3E3E3E3E3E 003E3E3E3E3E3E3E3A003E3E3E3E3E3E3E3E3A00 3E3E3E3E3E3E3E3E003A3E3E3E3E3E3E3A00 003A3E3E3E3E3E3E11003E3E3E3E3E3E3E3E 003A003E3E3E3E3E3E3E3E3E3E3E3E3E 3A3E363E3E3E3E3A3E3E3E3E3A3A1100 3E3E3E3E3E003E3E3E3E003E 003A3E3E3E3A3A3E3A3E3E3A003A3E3E3E3A3600 003A163E3E3E3A3E3E3E3E3E3E3E3A3E003E3E3E3E003A00 00363E3E3E3E3E003A3E3E15003A3A3E
Re: Why it's so difficult to fix PowerMac booting for good
Hello, On 6/1/23 10:34 PM, Paul Wise wrote: As for how this script could be integrated into Debian, it should definitely not be put into the GRUB package. As Glaubitz has said, the goal is for as little PowerPC-specific patches to be put into these core packages as possible. GRUB's also not really the right place for a script that runs before it to enable booting other OSes more easily. It also wouldn't make sense to create a whole separate package just for one script file. Since the script is unnecessary for those who don't want to dual-boot, I don't know if it should really be included in Debian at all. What about including it in os-prober? That's on the right track, but not quite. os-prober is just a program that detects other OSes and reports where they are, it doesn't actually install any files AFAIK. What we could actually do is put a hook in debian-installer that runs os-prober and installs the script if it finds any OS X or OS 9 installations. It could even use os-prober to find out which partition(s) the OS(es) are on and modify the script accordingly. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: Why it's so difficult to fix PowerMac booting for good
Hello, On 6/1/23 1:59 AM, Linux User #330250 wrote: The only thing that I can think of that might make the script slightly better was if you used &device; for \grub, because this should default to the current partition (where stage1 is on), and this is presumably where GRUB is as well... I.e., the line stating with ": bootgrub" would look like this: : bootgrub " Loading GRUB..." .printf 100 ms load-base release-load-area " &device;,\grub" $boot ; I'll definitely use this when I get around to installing Linux on my Clamshell... Thanks! I've got a final script attached that takes that into account, and now all you'd need to modify is which partition OS X is on, unless it's different than 3 which is the most common one I saw. I also added a nice Debian logo to the badge shown in the OS picker. All you have to do after installing Debian alongside OS X is replace /boot/grub/System/Library/CoreServices/BootX with this file, rebless it if needed, and now you have an easy dual-boot solution! -- Ben Westover MacRISC MacRISC3 MacRISC4 PowerPC GNU/Linux First Stage Bootstrap : .printf fb8-write drop ; : bootgrub " Loading GRUB..." .printf 100 ms load-base release-load-area " &device;,\grub" $boot ; : bootmacosx " Booting Mac OS X..." .printf 100 ms load-base release-load-area " hd:3,\\:tbxi" $boot ; : bootcd " Booting CDROM..." .printf 100 ms load-base release-load-area " cd:,\\:tbxi" $boot ; " screen" output variable interactive 1 interactive ! 0 interactive @ = if bootgrub then dev screen " "(00aa00aaaaaa005500aa)" drop 0 7 set-colors " "(55ff55ffffff55ff55ff)" drop 8 15 set-colors device-end f to foreground-color 0 to background-color " "(0C)" .printf " First Stage Debian GNU/Linux Bootstrap"(0d 0a)" .printf " "(0d 0a)" .printf " Press l for GNU/Linux,"(0d 0a)" .printf " x for Mac OS X,"(0d 0a)" .printf " c for CDROM."(0d 0a)" .printf " "(0d 0a)" .printf " Stage 1 Boot: " .printf get-msecs d# 10 3E8 * + begin key? if key case ascii l of " l "(0d 0a)" .printf bootgrub endof ascii x of " x "(0d 0a)" .printf bootmacosx endof ascii c of " c "(0d 0a)" .printf bootcd endof endcase then dup get-msecs < until drop " "(0d 0a)" .printf bootgrub 1010 003E3E3E3A3E3A11 3E3E3E3E3E3E3E3E3E00 003E3E3E3E003A3E3E3E 3E3E3E3E003E3E3E 3A3E3E3E3E3E3E003E3E 3E3E003A36003E3A 3E3A3E3E3A003E3E 3E003E3E36003E3A 3E3E3A3E003A003E3A00 3E3A363A3E3E3E3E3E00 3E3E113E3E3E3E00 3E3E3E00 003E3E00 3E3E 3E3E3A00 3E3E3E00 00C1C1C1C5C1C5EE C1C1C1C1C1C1C1C1C100 00C1C1C1C100C5C1C1C1 C1C1C1C100C1C1C1 C5C1C1C1C1C1C100C1C1 C1C100C5C900C1C5 C1C5C1C1C500C1C1 C100C1C1C900C1C5 C1C1C5C100C500C1C500 C1C5C9C5C1C1C1C1C100 C1C1EEC1C1C1C100 C1C1C100 00C1C100 C1C1 C1C1C500 C1C1C100 00FF FF00 0000 00FF FF00 00FFFF00 FF00 FF00FF00 00FF0000 FF00 FF00 FF00 0000 FF00 FF00 OpenPGP_signature Description: OpenPGP digital signature
Re: Why it's so difficult to fix PowerMac booting for good
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. -- Ben Westover MacRISC MacRISC3 MacRISC4 PowerPC GNU/Linux First Stage Bootstrap : .printf fb8-write drop ; : bootgrub " Loading GRUB..." .printf 100 ms load-base release-load-area " &device;:&partition;,\grub" $boot ; : bootmacosx " Booting Mac OS X..." .printf 100 ms load-base release-load-area " &device;:3,\\:tbxi" $boot ; : bootcd " Booting CDROM..." .printf 100 ms load-base release-load-area " cd:,\\:tbxi" $boot ; " screen" output variable interactive 1 interactive ! 0 interactive @ = if bootgrub then dev screen " "(00aa00aaaaaa005500aa)" drop 0 7 set-colors " "(55ff55ffffff55ff55ff)" drop 8 15 set-colors device-end f to foreground-color 0 to background-color " "(0C)" .printf " First Stage Debian GNU/Linux Bootstrap"(0d 0a)" .printf " "(0d 0a)" .printf " Press l for GNU/Linux,"(0d 0a)" .printf " x for Mac OS X,"(0d 0a)" .printf " c for CDROM."(0d 0a)" .printf " "(0d 0a)" .printf " Stage 1 Boot: " .printf get-msecs d# 10 3E8 * + begin key? if key case ascii l of " l "(0d 0a)" .printf bootgrub endof ascii x of " x "(0d 0a)" .printf bootmacosx endof ascii c of " c "(0d 0a)" .printf bootcd endof endcase then dup get-msecs < until drop " "(0d 0a)" .printf bootgrub 1010 003E3E3E3A3E3A11 3E3E3E3E3E3E3E3E3E00 003E3E3E3E003A3E3E3E 3E3E3E3E003E3E3E 3A3E3E3E3E3E3E003E3E 3E3E003A36003E3A 3E3A3E3E3A003E3E 3E003E3E36003E3A 3E3E3A3E003A003E3A00 3E3A363A3E3E3E3E3E00 3E3E113E3E3E3E00 3E3E3E00 003E3E00 3E3E 3E3E3A00 3E3E3E00 00C1C1C1C5C1C5EE C1C1C1C1C1C1C1C1C100 00C1C1C1C100C5C1C1C1 C1C1C1C100C1C1C1 C5C1C1C1C1C1C100C1C1 C1C100C5C900C1C5 C1C5C1C1C500C1C1 C100C1C1C900C1C5 C1C1C5C100C500C1C500 C1C5C9C5C1C1C1C1C100 C1C1EEC1C1C1C100 C1C1C100 00C1C100 C1C1 C1C1C500 C1C1C100 00FF FF00 0000 00FF FF00 00FFFF00 FF00 FF00FF00 00FF0000 FF00 FF00 FF00 0000 FF00 FF00 OpenPGP_signature Description: OpenPGP digital signature
Re: Why it's so difficult to fix PowerMac booting for good
Hello, On 6/2/23 1:56 AM, Linux User #330250 wrote: One thing that concerns me a bit is putting Linux's CHRP boot script into /System/Library/CoreServices/BootX, which is specific to Mac OS X. Why is this necessary? It's not necessary, it's just that the existing script placed by GRUB to load itself is already in that location, so putting the new one there a) removes the existing entry for GRUB and b) saves you a blessing step. The only special thing I found about that particular spot is that none of the PowerMacs I've used will display a blessed script on a USB drive unless it's in that specific location. Another bonus is if the script is in that directory along with a 'Volume Name Icon' file it will have a nice label of your choosing under the icon like OS X does. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: How are CHRP bootinfo icons formatted?
Hello,
On 6/3/23 4:21 AM, Linux User #330250 wrote:
I was experimenting with those CHRP icons a while back but never could
figure out how they work, specifically the color palette was a complete
riddle to me. I searched the internet until finally I gave up...
So, again, thank you! I'm very happy you found the key to the
hexadecimal colors!
I don't think I really did. All I did was guess that the colors are
stored in some sort of 3,3,2 8 bit color format since that's what
standard CHRP does. My method for converting RGB pixels into 3,3,2 was
based on a Stack Overflow answer that I'm not so sure was accurate. The
color of the Debian logo is close to (but not quite) what it should look
like in this format, and anything with more than just one basic color
doesn't look right at all. I made a color palette in GIMP, attached,
with all 256 of the colors that are possible to make with my script, and
they don't look right at all; basic values like #FF that definitely
show up on the OS picker aren't present in it. I need to figure out what
the actual format is and how it can be translated to and from standard
RGB color, so I can make icons that look right.
Another thing I can't figure out is the second bitmap. While it's
possible to just make it the same as the first one, it definitely must
have some function. While the GNU logo doesn't make use of it, the Tux
one does, and the OS X logo is definitely doing something interesting:
1010
F800
2B73732B0055735500F8
F5799DF6004F792BF800
00F69D4E004F2B00F800
559D2A55F5F8
F69D732B00F8
004F96F500F8
00799D4E00F8
2AF8559D00F8
79F6F59D4EF8
004E4F557300F800
4F9D55F5004F9D4FF500F800
F800557A56F50055567A2BF8
00F8F8F8F800
00F8F8F8F8F8F800
00F7F7F7F7F7F700
00F7F7F7F7F7F7F7F7F78100
F7F7F99E9EF9F7809E80F781
00F7F7F7F8A4C856F77AA4F9F7F78100
00F7F7F7F756C879F77AF9F7F7F78100
F7F7F7F7F7F780C85580F8F7F7F7F781
F7F7F7F7F7F756C89EF9F7F7F7F7F781
F7F7F7F7F7F7F77AC1F8F7F7F7F7F781
F7F7F7F7F7F7F7A4C879F7F7F7F7F781
F7F7F7F7F7F7558180C8F7F7F7F7F781
F7F7F7F7F7F7A456F8C879F7F7F7F781
00F7F7F7F7797AF7F7809EF7F7F78100
00F7F7F77AC880F8F77AC87AF8F78100
81F780A5FBF8F780FBA5F981
008181F7F7F7F7F7F7818100
0081818181818100
0000
0000
0000
0000
0000
0000
0000
0000
Notice how the first bitmap only details the X in the foreground while
the second one details both the foreground and the background. This is a
complete mystery to me, and I don't understand why there would be unique
information in the second bitmap for both the Tux and the OS X logo when
changing it doesn't seem to do anything with the Debian or GNU logos.
I wish I could find some Apple documentation somewhere that could help
to solve the mysteries of both the color format and the second bitmap.
--
Ben Westover
/* Generated with GIMP Palette Export */
.Untitled { color: rgb(0, 0, 0) }
.Untitled { color: rgb(0, 0, 64) }
.Untitled { color: rgb(0, 0, 128) }
.Untitled { color: rgb(0, 0, 192) }
.Untitled { color: rgb(0, 32, 0) }
.Untitled { color: rgb(0, 32, 64) }
.Untitled { color: rgb(0, 32, 128) }
.Untitled { color: rgb(0, 32, 192) }
.Untitled { color: rgb(0, 64, 0) }
.Untitled { color: rgb(0, 64, 64) }
.Untitled { color: rgb(0, 64, 128) }
.Untitled { color: rgb(0, 64, 192) }
.Untitled { color: rgb(0, 96, 0) }
.Untitled { color: rgb(0, 96, 64) }
.Untitled { color: rgb(0, 96, 128) }
.Untitled { color: rgb(0, 96, 192) }
.Untitled { color: rgb(0, 128, 0) }
.Untitled { color: rgb(0, 128, 64) }
.Untitled { color: rgb(0, 128, 128) }
.Untitled { color: rgb(0, 128, 192) }
.Untitled { color: rgb(0, 160, 0) }
.Untitled { color: rgb(0, 160, 64) }
.Untitled { color: rgb(0, 160, 128) }
.Untitled { color: rgb(0, 160, 192) }
.Untitled { color: rgb(0, 192, 0) }
.Untitled { color: rgb(0, 192, 64) }
.Untitled { color: rgb(0, 192, 128) }
.Untitled { color: rgb(0, 192, 192) }
.Untitled { color: rgb(0, 224, 0) }
.Untitled { color: rgb(0, 224, 64) }
.Untitled { color: rgb(0, 224, 128) }
.Untitled { color: rgb(0, 224, 192) }
.Untitled { color: rgb(32, 0, 0) }
.Untitled { color: rgb(32, 0, 64) }
.Untitled { color: rgb(32, 0, 128) }
.Untitled { color: rgb
Re: How are CHRP bootinfo icons formatted?
On 6/3/23 3:58 PM, Ben Westover wrote:
I don't think I really did. All I did was guess that the colors are
stored in some sort of 3,3,2 8 bit color format since that's what
standard CHRP does. My method for converting RGB pixels into 3,3,2 was
based on a Stack Overflow answer that I'm not so sure was accurate.
I tried something else; while I'm not quite there yet, I think I'm
getting closer. My last palette based on a Stack Overflow answer
incremented the red and green by 32, giving a range from 0x00 to 0xE0,
and the blue by 64, giving a range from 0x00 to 0xC0.
I created a new palette incrementing red and green by 36, giving a range
from 0x00 to 0xFC, and blue by 85, which gives the complete range of
color from 0x00 to 0xFF. This is much better coverage than before, and
the new palette as well as a new script that uses it is attached.
The reason why I think the new palette is closer than the old one is
that I no longer need to invert the Debian logo's colors to make it look
right. The red is also a lot darker than it was before, going from
almost pink to a sort of burgundy. It's still not quite right, though,
as more complex images still look completely wrong.
--
Ben Westover
from PIL import Image
from more_itertools import chunked
img = Image.open('image.png')
pixels = []
for i in range(0, 16):
for j in range(0, 16):
pixels.append(img.getpixel((j, i)))
bmp1_values = []
for pixel in pixels:
red = format(round(pixel[0] / 36), 'b').zfill(3)
green = format(round(pixel[0] / 36), 'b').zfill(3)
blue = format(round(pixel[0] / 85), 'b').zfill(2)
bmp1_values.append(format(int(red + green + blue, 2), 'X').zfill(2))
bmp3_values = []
for pixel in pixels:
if pixel == (0, 0, 0, 0):
bmp3_values.append("00")
else:
bmp3_values.append("FF")
for chunk in chunked(bmp1_values, 16):
print(''.join(chunk))
print("")
for chunk in chunked(bmp1_values, 16):
print(''.join(chunk))
print("")
for chunk in chunked(bmp3_values, 16):
print(''.join(chunk))
.Untitled { color: rgb(0, 0, 0) };
.Untitled { color: rgb(0, 0, 85) };
.Untitled { color: rgb(0, 0, 170) };
.Untitled { color: rgb(0, 0, 255) };
.Untitled { color: rgb(0, 36, 0) };
.Untitled { color: rgb(0, 36, 85) };
.Untitled { color: rgb(0, 36, 170) };
.Untitled { color: rgb(0, 36, 255) };
.Untitled { color: rgb(0, 72, 0) };
.Untitled { color: rgb(0, 72, 85) };
.Untitled { color: rgb(0, 72, 170) };
.Untitled { color: rgb(0, 72, 255) };
.Untitled { color: rgb(0, 108, 0) };
.Untitled { color: rgb(0, 108, 85) };
.Untitled { color: rgb(0, 108, 170) };
.Untitled { color: rgb(0, 108, 255) };
.Untitled { color: rgb(0, 144, 0) };
.Untitled { color: rgb(0, 144, 85) };
.Untitled { color: rgb(0, 144, 170) };
.Untitled { color: rgb(0, 144, 255) };
.Untitled { color: rgb(0, 180, 0) };
.Untitled { color: rgb(0, 180, 85) };
.Untitled { color: rgb(0, 180, 170) };
.Untitled { color: rgb(0, 180, 255) };
.Untitled { color: rgb(0, 216, 0) };
.Untitled { color: rgb(0, 216, 85) };
.Untitled { color: rgb(0, 216, 170) };
.Untitled { color: rgb(0, 216, 255) };
.Untitled { color: rgb(0, 252, 0) };
.Untitled { color: rgb(0, 252, 85) };
.Untitled { color: rgb(0, 252, 170) };
.Untitled { color: rgb(0, 252, 255) };
.Untitled { color: rgb(36, 0, 0) };
.Untitled { color: rgb(36, 0, 85) };
.Untitled { color: rgb(36, 0, 170) };
.Untitled { color: rgb(36, 0, 255) };
.Untitled { color: rgb(36, 36, 0) };
.Untitled { color: rgb(36, 36, 85) };
.Untitled { color: rgb(36, 36, 170) };
.Untitled { color: rgb(36, 36, 255) };
.Untitled { color: rgb(36, 72, 0) };
.Untitled { color: rgb(36, 72, 85) };
.Untitled { color: rgb(36, 72, 170) };
.Untitled { color: rgb(36, 72, 255) };
.Untitled { color: rgb(36, 108, 0) };
.Untitled { color: rgb(36, 108, 85) };
.Untitled { color: rgb(36, 108, 170) };
.Untitled { color: rgb(36, 108, 255) };
.Untitled { color: rgb(36, 144, 0) };
.Untitled { color: rgb(36, 144, 85) };
.Untitled { color: rgb(36, 144, 170) };
.Untitled { color: rgb(36, 144, 255) };
.Untitled { color: rgb(36, 180, 0) };
.Untitled { color: rgb(36, 180, 85) };
.Untitled { color: rgb(36, 180, 170) };
.Untitled { color: rgb(36, 180, 255) };
.Untitled { color: rgb(36, 216, 0) };
.Untitled { color: rgb(36, 216, 85) };
.Untitled { color: rgb(36, 216, 170) };
.Untitled { color: rgb(36, 216, 255) };
.Untitled { color: rgb(36, 252, 0) };
.Untitled { color: rgb(36, 252, 85) };
.Untitled { color: rgb(36, 252, 170) };
.Untitled { color: rgb(36, 252, 255) };
.Untitled { color: rgb(72, 0, 0) };
.Untitled { color: rgb(72, 0, 85) };
.Untitled { color: rgb(72, 0, 170) };
.Untitled { color: rgb(72, 0, 255) };
.Untitled { color: rgb(72, 36, 0) };
.Untitled { color: rgb(72, 36, 85) };
.Untitled { color: rgb(72, 36, 170) };
.Untitled { color: rgb(72, 36, 255) };
.Untitled { color: rgb(72, 72, 0) };
.Untitle
Re: How are CHRP bootinfo icons formatted?
Hello, On 6/4/23 1:56 AM, Gabriel Paubert wrote: With 3/3/2 it's impossible to produce photo realistic images. Even 16 bit, which is RGB 565 if memory serves (not used in well over a decade), gives quite a few artefacts. I'm not expecting a 16x16 image of 8 bit color depth to be anything close to photorealistic. I'm saying that basic things like Tux (only a few colors) look horrible compared to the one that yaboot supplies. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Re: How are CHRP bootinfo icons formatted?
On 6/4/23 2:57 AM, Linux User #330250 wrote: The thing with the first and second icon: I now remember that I had an idea what it could mean, but didn't get around testing it: Could it be active/inactive, i.e. not selected for boot (first icon) and selected boot option (second icon)? Interesting idea, I'll have to test that. Also, if the yaboot people made the Tux and did make use of the second icon, they must know what it means. Maybe we can get hold of who made the Tux for the CHRP script... Funny you say that, I just sent the person who designed yaboot's CHRP icon an email about 30 minutes ago. It happened 23 years ago, so it's unlikely that a) the email with a university domain is still active and b) the person remembers exactly how to do it or the software/format used is still around. I also sent one to the person (gmail address) who did the GNU logo for GRUB's CHRP icon in 2013, which is more likely to work. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
