Quik booting Wallstreets - a howto of sorts
First off, I've replied offlist to Ben Racher on this, but here's a bit of a howto on getting quik booting working on a Wallstreet powerbook with 2.6 initrd kernels (it probably works for other oldworld powerbooks too and might be useful for other machines with horribly busted firmware and ide drives) What you will need: - A MacOS boot CD, preferably 8.6 or better - A network connection to a machine running an appletalk / appleshare server - A copy of BootX on the appletalk server - A copy of System Disk on the appletalk server or an OSX 10.[0-2] boot disk - A recent debian boot CD (I used the 3.1r2 netinst CD) - it's important that you are using a recent copy of quik as older ones foul up with initrd kernels First thing we'll do is entirely zap the machine. Power it off completely, then do the cmd-opt-p-r tango on startup, letting at least 3 chimes go through. Next up, we'll install the Apple firmware patches. Either do the first boot / reboot phase off the OSX install CD, or, preferably, boot up off the MacOS CD, connect to the appleshare server and run System Disk. If you're running system disk, also make the machine stop at the open firmware prompt on boot. If you did the patching through the OSX CD, you want to now make the machine stop at open firmware on boot, which is, frankly, a pain. Wallstreets are particularly picky about timings for the cmd-opt-o-f keypress, so this will probably take you a few shots to get right, the key thing seems to be hitting all the keys at the same time, and doing so _during_ the startup chime. Fear not, it _can_ be done, and eventually you'll be seeing open firmware's friendly[1] 0 prompt. open the CD drive, stick your MacOS boot CD in, and type the following: setenv auto-boot? false reset-all wait for reboot back to OF bye You now have a machine with patched firmware running MacOS off the install CD. If you're not already connected to your appletalk server, connect to it now. The next step is crucial - although your firmware is patched, it won't boot a drive that doesn't have a horde of tiny little Apple- provided partitions on it (8 on my machine). So we will run the disk utility off the install CD to reformat the drive. Obviously, if you have important stuff on there, you want to back it up first. Don't worry about how many partitions you create or whether they are hfs or hfs+, you'll be blowing them away later anyway, the important thing is that the Apple tool sems to be the only way of getting the chain loader partitions onto the disk. Next, we'll run BootX. If you don't already have the installation kernel and initrd on the appleshare server, get them on there now. Fire up BootX, set it to use the installation kernel and ramdisk and add an additional kernel argument of video=ofonly. Don't hit Linux yet, though. With BootX still running, hard-eject the MacOS CD (biro / paperclip on the drive's force eject tab) and swap in the debian install CD. Now click on Linux and yo should (finally) see the penguin logo and the standard boot messages When you get to the partitioning the disk stage of the installer, choose manual partitioning. Other choices will blow away the chain loader partitions and you won't be able to boot with quik. Be careful not to blow those partitions away yourself, either, they may look pointless, but they are not. Your usable partitions will probably start around partition 9. Also be aware that your boot partition (whether it's a separate partition mounted onto /boot, or the entire root partition) must be plain-jane EXT2, and must live in the first 8GB of the drive. Remember what partition number your boot partition is. As for the rest - knock yourself out :) Ignore the warning about quik at the end of the install process. Let it rip, and to hell with the consequences. If you have an unorthodoxsetup, you may need to fire up a shell and manually run quik before rebooting, but if you're that advanced you already know this and what you have to do. If messing with the quik config file, be aware that booting from quik with anyhing other than video=ofonly seems to crash the kernel hard (more on this in another post) Reboot. Watch in awe as you machine drops to the open firmware prompt and does - ummm - nothing. There's a final bit of cleanup to be done before we can make this work. The installer's quik setup knowns nothing of the firmware patches, and also kills the proper boot command, so we need to tidy that up. The '9' below should be replaced by the partition number of your boot partition, as a hex number (thus partition 10 would be 'a') setenv boot-device ide0/[EMAIL PROTECTED]:9 setenv boot-command 1 bootr reset-all wait for reboot back to OF boot And you should now be into the second stage of installation of your machine. See? It's simple, really :)
Wallstreet + quik + atyfb = crash
So, I'm back on my Wallstreet, which I bought back in '99 or so as a Linux machine, and then moved to OSX in 2001. For teh last year or so, it's lingered, mildly unloved and gathering dust, and I decided to get it back on Linux as a test platform. So, as per my other post, I have it up and running, booting with quik, and all is well. Except that, like Ben Racher, I can't get accelerated video running with a quik boot. I _think_ that way back when, I was quik booting with accelerated video (video=atyfb:vmode: 14,cmode:32 etc etc), but whether or not that's true it most certainly doesn't work now. I've tried with the stable branch kernel (2.6.8) both as a binary install and as a modularised build and a monolithic build, ditto for the testing kernel (2.6.15 as of yesterday). With video=ofonly all is well, but any combination of arguments to video=atyfb cause a hard crash - the screen gets blanked (presumably as the early console driver gets switched out) and I see screenmelt psychedelic patterns (or, if running with an external monitor, signal out of range errors), there's a very brief flurry of hard drive activity and then nothing. nada. Hard rebooting the system and coming back up with working video shows that the boot process has not got as far as mounting the root drive R/W as everything mounts clean with no fsck required. The same kernels, booted using the OS9 CD and an appleshare server with BootX on it, boot fine with both video=ofonly and video=atyfb... It seems to me that quik is leaving the video card in a state that the atyfb driver can't cope with, but of course I can't see any output to even begin to tell where that might be happening. I might be able to dig out a serial device to act as console if that is possible. If I can debug what's going on I have no issues with doing some real work on getting this going. Anyway, any gurus feel like chipping in? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New I2C and machine probing method
Hi,
I want to use some OF and kernel 2.6 features to improve device probing
in pbbuttonsd. Unfortunately I have only an ancient PowerBook so I need
your help to test the new routines on as many different machines as
possible.
I attached the source code of a short program. You could compile it as
follows:
$ gcc -o of_probing of_probing.c
This program does three things:
1. detecting the machine ID.
Any PowerBook user can test this feature. Launch the program and
check if the machine ID is correctly detected on your machine. If
you don't know which ID your machine have see in
$ cat /proc/device-tree/model or
$ cat /proc/cpuinfo
Tell me if your machine is not correctly identified. PowerBooks
before the G3 Pismo will get the dummy ID 1, because Apple started
his numbering system just with the Pismo.
2. detecting the LMU I2C address
The program looked for the lmu-controller in the device tree and
read the attached data to find out the I2C address.
This test will only have a result, if you have a PowerBook with an
ambient light sensor. Otherwise the program won't find an LMU.
If your machine definitely has an ambient light sensor and the program
won't find it, the device tree path might be wrong. In this case please
send me the correct path or an tar archive of /proc/device-tree.
3. detecting of the /dev/i2c device to communicate with the LMU
This test reads /sys to find out which i2c devices are available and
which one is connected to the uni-n controller the LMU is attached
to. Each found i2c device will then be checked for the LMU.
The program lists all found i2c devices to the console and mark the
device with the LMU connected.
This test needs the kernel module i2c-dev to be loaded. If not
already done, you could load the module with
$ modprobe i2c-dev
I would appreciate any feedback.
Thank you and Best Regards
Matthias
#include stdio.h
#include dirent.h
#include string.h
#include fcntl.h
#include sys/ioctl.h
#define OFBASE /proc/device-tree
#define SYSI2CDEV /sys/class/i2c-dev
#define I2CCHIPuni-n
#define I2C_SLAVE 0x0703
int
probeLMU(char *device, int addr)
{
char buffer[4];
int fd, rc = 0;
if ((fd = open(device, O_RDWR)) = 0) {
if (ioctl(fd, I2C_SLAVE, addr) = 0) {
if (read (fd, buffer, 4) == 4)
rc = 1;
}
close(fd);
}
return rc;
}
int
addPath(char *path, int maxlen, char *pattern)
{
DIR *dh;
struct dirent *dir;
int rc = 1;
if ((dh = opendir(path))) {
while (dir = readdir(dh)) {
if ((strncmp(dir-d_name, pattern, strlen(pattern)) == 0)) {
strncat(path, /, maxlen-1);
strncat(path, dir-d_name, maxlen-1);
rc = 0;
break;
}
}
closedir(dh);
}
return rc;
}
int
getLMUAddress()
{
char path[200];
FILE *fd;
long reg;
int n, rc = 0, err = 0;
path[0] = 0; /* terminate path buffer */
strncat(path, OFBASE, sizeof(path)-1);
err += addPath(path, sizeof(path), uni-n);
err += addPath(path, sizeof(path), i2c);
err += addPath(path, sizeof(path), lmu-controller);
strncat(path, /reg, sizeof(path)-1);
printf( OF: '%s'\n, path);
if (err 0)
printf(Path incomplete! One or more elements not found.\n);
else if ((fd = fopen(path, r)) = 0) {
n = fread(reg, sizeof(long), 1, fd);
if (n == 1)
rc = (int) (reg 1);
fclose(fd);
}
return rc;
}
int
findI2CDevice(int addr)
{
char buffer[40];
DIR *dh;
FILE *fd;
struct dirent *dir;
int n;
if ((dh = opendir(SYSI2CDEV))) {
while (dir = readdir(dh)) {
if (dir-d_name[0] == '.') continue;
snprintf(buffer, sizeof(buffer), SYSI2CDEV/%s/name, dir-d_name);
if ((fd = fopen(buffer, r)) = 0) {
n = fread(buffer, 1, sizeof(buffer), fd);
if (n 0 n sizeof(buffer)) {
buffer[n-1] = 0;
printf( I2C: '%s', '%s', dir-d_name, buffer);
if ((strncmp(I2CCHIP , buffer, 6) == 0)) {
snprintf(buffer, sizeof(buffer), /dev/%s, dir-d_name);
if ((probeLMU(buffer, addr)))
printf( - this is the LMU device);
}
printf(\n);
}
fclose(fd);
}
}
closedir(dh);
}
}
int
getMachineID()
{
char buffer[32];
int fd, n, machine = 0;
if ((fd = open(OFBASE/model, O_RDONLY))) {
if ((n = read(fd, buffer, sizeof(buffer) - 1)) != -1) {
buffer[n] = 0; /* terminate buffer, only to be sure */
if (strncmp(PowerBook, buffer, 9) == 0) {
if (buffer[9] == 0)
machine = 1; /* Dummy code for pre-Pismo PowerBooks */
else {
machine = (atoi(buffer[9]) 0xf) 4;
for (n = 9; buffer[n] != ',' buffer[n] != '\0'; ++n);
if (buffer[n] == ',')
machine |= atoi(buffer[n+1]) 0xf;
}
}
}
close(fd);
}
return machine;
}
int
main (int argc, char *argv[])
{
int addr, machine;
printf(\nProbing machine...\n);
machine = getMachineID();
if (machine != 0) {
printf ( Machine: ID = %x\n, machine);
addr = getLMUAddress();
if (addr) {
printf( LMU: I2C address = %x \n, addr);
findI2CDevice(addr);
} else
printf(
Re: xorg nv options
On Sat, Jul 15, 2006 at 06:19:33PM -0400, Benjamin Herrenschmidt wrote: I haven't been able to use an external monitor/beamer with this laptop and xorg. Is it possible now (I have not tried it for a while). The nv driver doesn't support dual head. I think it's possible however to coerce it into using the external output instead of the internal flat panel but I don't know the details. Others on the list might. I can successfully use the external vga out, however the laptop LCD is not usable meanwhile. Note that you have to boot with the external vga adaptor plugged in. -88-- Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameMonitor Model HorizSync 28-49 VertRefresh 43-72 Option DPMS EndSection Section Monitor Identifier Monitor1 VendorName Monitor Vendor ModelNameMonitor Model HorizSync 28-49 VertRefresh 43-72 Option DPMS EndSection Section Device Identifier Card0 BusID PCI:0:16:0 Driver nv Option CrtcNumber 1 # 0 is external crt Option FlatPanel 1 # 0 is external crt #Option UseFBDev true #Option fbdev /dev/fb0 EndSection Section Device Identifier Card1 BusID PCI:0:16:0 Driver nv Option CrtcNumber 0 # 0 is external crt Option FlatPanel 0 # 0 is external crt EndSection Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 DefaultDepth 16 SubSection Display Depth 16 Modes 1024x768 800x600 640x480 EndSubSection EndSection Section Screen Identifier Screen1 Device Card1 MonitorMonitor1 DefaultDepth 16 SubSection Display Depth 16 Modes 800x600 640x480 # Modes 1024x768 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier XFree86 Configured #Screen 1 Screen1 LeftOf Screen0 # only one of each at a time. # lcd screen Screen 0 Screen0 # vga out #Screen 1 Screen1 InputDeviceMouse0 CorePointer InputDevice Mouse1 InputDeviceKeyboard0 CoreKeyboard EndSection -88-- filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: I always keep the Titanic in mind when I talk about security or safety, meaning that nothing is fully secure. -- Anonymous (?) signature.asc Description: Digital signature
Re: New I2C and machine probing method
On Sun, Jul 16, 2006 at 03:45:57PM +0200, Matthias Grimm wrote: Hi, I want to use some OF and kernel 2.6 features to improve device probing in pbbuttonsd. Unfortunately I have only an ancient PowerBook so I need your help to test the new routines on as many different machines as possible. I attached the source code of a short program. You could compile it as follows: $ gcc -o of_probing of_probing.c $ ./of_probing Probing machine... Machine: ID = 62 OF: '/proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/reg' Path incomplete! One or more elements not found. LMU: No LMU found! [EMAIL PROTECTED]:/tmp$ cat /proc/cpuinfo processor : 0 cpu : 7447/7457, altivec supported clock : 998.40MHz revision: 0.1 (pvr 8002 0101) bogomips: 47.94 timebase: 18432000 platform: PowerMac machine : PowerBook6,2 motherboard : PowerBook6,2 MacRISC3 Power Macintosh detected as : 287 (PowerBook G4) pmac flags : 001a L2 cache: 512K unified pmac-generation : NewWorld seems fine, powerbook 12 bought nov'03 filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: I was once walking through the forest alone. A tree fell right in front of me -- and I didn't hear it. -- Steven Wright signature.asc Description: Digital signature
Re: New I2C and machine probing method
2. detecting the LMU I2C address The program looked for the lmu-controller in the device tree and read the attached data to find out the I2C address. This test will only have a result, if you have a PowerBook with an ambient light sensor. Otherwise the program won't find an LMU. If your machine definitely has an ambient light sensor and the program won't find it, the device tree path might be wrong. In this case please send me the correct path or an tar archive of /proc/device-tree. I haven't tested it, but a quick look at the code suggests it won't find it here: johannes:/proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] hd compatible 6c 6d 75 2d 63 6f 6e 74 72 6f 6c 6c 65 72 00 |lmu-controller.| 000f ...$ hd device_type 6c 6d 75 2d 63 6f 6e 74 72 6f 6c 6c 65 72 00 |lmu-controller.| johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Wallstreet + quik + atyfb = crash
on my powerbook3400 where i just got quik going, i just double checked -- i have no video options set at all. just in case i worry somebody, my disk is ok i think (its just the old fashioned laptop parking makes me nervous, or maybe it does need some tuning somewhere, but its ok) i do have apparently though some video driver problem, that is no better or worse in quik or bootx. the pb3400 has chips tho not ati, but keep reading. worried about my disk, i did finally manage to backup my debian sarge off the 3400 and copy it to my beige g3 and am up and running there, more or less, with bootx. the one video problem i had with chips disappears but there are some other minor problems, i am still working with the xf86config. besides the ati there i also have an ixmicro16MB card which i am studying how to get going. (no luck yet). i have seen people suggest options like you are discussing but i have no idea what the various flags there represent, may be out of date, i don't wish to burn up something !! one thing quik did help with on 3400 is now i have hotplug support for my wireless card - that is it does not have to be inserted allways before startup. my video problem there is about some twisted up fonts in various places - only urw family apparently work ok. the evidence with the beige being fine i either have and error in my x config or a problem with video drivers / kernel somewhere ? note i am always so far using stock kernels- that is i have not tried either building my own or putting an etch kernel into sarge- now that i have sarge on the g3 i have more resources there i might try it. my oldworlds run sarge/2.6.8-3. brian Simon Stapleton [EMAIL PROTECTED] wrote: So, I'm back on my Wallstreet, which I bought back in '99 or so as a Linux machine, and then moved to OSX in 2001. For teh last year or so, it's lingered, mildly unloved and gathering dust, and I decided to get it back on Linux as a test platform.So, as per my other post, I have it up and running, booting with quik, and all is well. Except that, like Ben Racher, I can't get accelerated video running with a quik boot. I _think_ that way back when, I was quik booting with accelerated video (video=atyfb:vmode: 14,cmode:32 etc etc), but whether or not that's true it most certainly doesn't work now.I've tried with the stable branch kernel (2.6.8) both as a binary install and as a modularised build and a monolithic build, ditto for the "testing" kernel (2.6.15 as of yesterday). With "video=ofonly" all is well, but any combination of arguments to "video=atyfb" cause a hard crash - the screen gets blanked (presumably as the early console driver gets switched out) and I see "screenmelt" psychedelic patterns (or, if running with an external monitor, "signal out of range" errors), there's a very brief flurry of hard drive activity and then nothing. nada. Hard rebooting the system and coming back up with working video shows that the boot process has not got as far as mounting the root drive R/W as everything mounts clean with no fsck required.The same kernels, booted using the OS9 CD and an appleshare server with BootX on it, boot fine with both "video=ofonly" and "video=atyfb..."It seems to me that quik is leaving the video card in a state that the atyfb driver can't cope with, but of course I can't see any output to even begin to tell where that might be happening. I might be able to dig out a serial device to act as console if that is possible. If I can debug what's going on I have no issues with doing some real work on getting this going.Anyway, any gurus feel like chipping in?Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
