Re: got quik working with OldWorld G3 Beige 233MHz
On Wed, Oct 06, 2004 at 04:42:23AM -0400, Rick Thomas wrote:
> On Tuesday, October 5, 2004, at 03:22 PM, Duane Cottle wrote:
>
> >It's been a week of reading and fumbling, but I got sarge booting with
> >quik. I'm hurrying to leave for the day, so I'll post some system
> >details here and follow up on proceedures if clarification is
> >requested.
>
> Can you summarize what you had to do to get it to work?
>
> Rick
Hi Rick,
To get all it out where others can see, I'll more than summarize.
(Understandable if you wanna skip 43 lines to "Begin Your Summary")
Interestingly, I was about to post to your on-going discussion about
CONFIG_BLK_DEV_IDE, because I think it's related? Well, I actually
know it is, just dont't know how/why yet. There are clearly such holes
in my grasp of the technical aspects. (That's normal.)
Quik is losing the ramdisks on these, my OldWorld boxes.
In my short experience, when quik works, it doesn't load the
ramdisk, regardless of quik.conf... _ANY_ ramdisk! Kernel arguments?
No go. Open Firmware boot-file arguments, you may suggest. Nada. Put the
options you need to boot into the kernel itself (particulary
CONFIG_BLK_DEV_IDE=y); however, and presto. Ramdisk becomes
superfluous and it boots...
Temporary in rc < 2? Maybe. My errors? Probably.
Why is BootX able to load a particular kernel/ramdisk combination and
get all the modules working, when the same combination yields
'unknown-block(0,0)' kernel panic errors with quik?
Sure, I'll make public my fog of ignorance, Rick... ;)
Possibly, not reasonably:
[1] Because MacOS is running when BootX does its thing, it jumpstarts
detection of the hardware with OF ROM voodoo??? Nah, but not knowing
PowerMac well, OF keeps appearing in my nightmares.
More probable:
[2] Quik is semi-broke in certain, if not many, older OF version(s)?
Like yours, my G3 is OldWorld, AIIRC, has scsi and ide drives.
_That_ machine is a work in progress; kernel's rolling to my right, oh,
no, there it goes. Done! booting... yup, theory substantiated: (no
ramdisk compiled, no needed scsi or file systems as modules -> boots in
quik) I hope users aren't going to be required to recompile to us this.
The other quik-booty box is the desktop version of this one w/o a scsi
drive and with an ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT]
(rev 9a) vice an ATI Technologies Inc 3D Rage Pro 215GP (rev 5c).
#########################
Your Summary:
ALL I DID
was give up the ramdisk track and compile my own 2.6.8 debianized kernel
the way I do it all the time on x386. On this last one, I didn't even
patch it with kernel-patch-powerpc-2.6.8 like before. (Doesn't seem to
give up anything I need, according to the compiler log. Evidently not,
seems small and fast without!)
at OF prompt (ok >):
ok > printenv boot-device
/AAPL,ROM # Apple's default
ok > dev / ls # prints the device tree from root up
# for my ide drive ends up being disk@0,0
# for my scsi it's sd@0,0
ok > devalias # prints aliases - useful to forego typing full paths
ok > setenv boot-device ide/disk@0,0:9 # partition 9 is ext2 root part.
ok > printenv boot-command
(returns) boot # some websites suggest otherwise, this works for quik
# and so for me on both disks
ok > printenv boot-file # kernel and args, quik handles these later
(returns nothing, fine)
ok > boot
(returns quik.conf's init-message and this prompt)
boot: (I type) MyLinux (Label of image in quik.conf) <press enter>
It boots the kernel, and it's off to the races.
(I've also entered at boot: ide/disk@0,0:9/boot/vmlinux-(...)
and it works as well.)
End Your Summary
######################
Some remaining quirks:
[1] I get the nice framebuffer boot at 1024x768,
small font, etc. as BootX, but without BootX's required argument,
video=atyfb... etc. Same image, different booter, different behavior!
[2] Am I using the backside cache?
I don't see the
L2CR overriden (0xa9100000), backside cache is enabled
dmesg line like when using BootX. Hmmm, is there a way to check? Can
quik pull this one out of its @!*&%?
[3] The complete OF device tree to the ide disk includes
/pci/mac-io/ide/disk@0,0, or something. I can use its alias,
ide/disk@0,0 to get to the disk; however..
A similar tree and alias exist for the scsi drive, but entering
scsi/sd@0,0 or mesh/sd@0,0 (scsi and mesh, both aliasses) fails: I must
use the full path, pci/mac-io/mesh/sd@0,0 for the scsi. DRAT!
Concerning OF and SystemDisk:
I don't recall if I was reading on miboot or what, but SystemDisk was
purported to be required. With quik, SystemDisk settings were just an
unneeded, incomplete step that is transcended at the OF prompt or with
nvsetenv in Linux. I didn't _bless_ anything with it, and I didn't use
it for LinuxPPC to make it boot the CD for installation either (which I
think was an miboot CD?).
Regards,
Duane
Reply to: