got quik working with OldWorld G3 Beige 233MHz

[Duane Cottle]

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.

Installation: pre-rc2 buisnesscard iso cd of 20040930 initiated via
BootX-1.2.2

Machine: PowerMac Beige G3
uname -a
Linux ppc2 2.6.8-ppc2.100504-1 #1 Tue Oct 5 11:43:06 EDT 2004 ppc
GNU/Linux

hard drive
hda: QUANTUM FIREBALL SE4.3A, ATA DISK drive
hda: MDMA, cycleTime: 120, accessTime: 75, recTime: 45
hda: Set MDMA timing for mode 2, reg: 0x00211526
hda: Enabling MultiWord DMA 2
hda: max request size: 128KiB
hda: 8418816 sectors (4310 MB) w/80KiB Cache, CHS=14848/9/63, (U)DMA

partitions
IDE1 master (hda) - 4.3 GB QUANTUM FIREBALL SE4.3A
#1 32.3 kB Apple
#2 27.6 kB Macintosh
#3 37.9 kB Macintosh
#4 102.4 kB Macintosh
#5 262.1 kB Macintosh
#6 262.1 kB Patch Partit
#7 314.6 MB hfs+ untitled
#8 52.4 MB hfs+ untitled 2
#9 900.0 MB ext2 root
#10 1.0 GB ext3 var
#11 1.7 GB ext3 usr
#12 342.7 MB swap swap


lspci
0000:00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 40)
0000:00:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10)
0000:00:10.0 ff00: Apple Computer Inc. Heathrow Mac I/O (rev 01)
0000:00:12.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro
215GP (
rev 5c)

0000:00:00.0 0600: 1057:0002 (rev 40)
0000:00:0d.0 0c03: 1045:c861 (rev 10)
0000:00:10.0 ff00: 106b:0010 (rev 01)
0000:00:12.0 0300: 1002:4750 (rev 5c)

cpuinfo
processor : 0
cpu : 740/750
temperature : 39-41 C (uncalibrated)
clock : 233MHz
revision : 2.2 (pvr 0008 0202)
bogomips : 465.92
machine : Power Macintosh
motherboard : AAPL,Gossamer MacRISC
detected as : 48 (PowerMac G3 (Gossamer))
pmac flags : 00000000
L2 cache : 512K unified pipelined-syncro-burst
memory : 352MB
pmac-generation : OldWorld

Open Firmware version 2.01f
nvsetenv
little-endian? false
real-mode? false
auto-boot? false
diag-switch? false
fcode-debug? false
oem-banner? false
oem-logo? false
use-nvramrc? true
real-base 0xffffffff
real-size 0x100000
virt-base 0xffffffff
virt-size 0x100000
load-base 0x600000
pci-probe-list 0xffffffff
screen-#columns 0x64
screen-#rows 0x28
selftest-#megs 0x0
boot-device ide/***@0,0:9
boot-file
diag-device
diag-file
input-device kbd
output-device screen
oem-banner
oem-logo
nvramrc hex
: $D find-device ;
: $E device-end ;
: $L BLpatch ; : $R BRpatch ;
: $X execute ;
: $p 0 to my-self property ;
: $a " /chosen" $D $p $E ;
: &c " ata-enable" $call-parent ;
10 buffer: km
dev kbd
get-key-map km swap move
$E
: ck 0 do swap dup 3 >> km + c@ 1 rot 7 and << and or loop ;
: bootr 0d word count encode-string " machargs" $a
0 0 1 ck if 0 and else f 3d 0 2 ck if 40 or then then
if bye else 1e 0 do ['] boot catch drop 1f4 ms loop then bye ;
: myboot boot-command eval ;
dev enet
' open constant $M
: $M2 $M 710 - $X ;
: rl@ -7D9D40 $X ;
: chstat begin $M2 $M 14f8 - $X -7D6C20 $X rl@ 400 and 0= until ;
: bmstat begin $M2 $M 13F0 - $X rl@ 100 and until ;
: xmt1 get-msecs $M 720 - ! chstat $M A00 - $X bmstat chstat ;
' xmt1 ' WRITE 10 + l!
62 ' READ 7 - c!
: READ { _p _n ; _a } begin _p _n bead -> _a _a 2+
if _p c@ 80 and 0= else 1 then until _a ;
$E
dev /packages/obp-tftp
: $M over + ['] noop $L ;
: $O ['] open + ;
: $M1 dup 24 - -1720 $O $X 6 move 14 + ;
-5BC $O ' $M1 $L
0 $O E8 $M EC $M F0 $M F4 $M F8 + ' true $L
$E
dev /packages/mac-parts
: $M -7E89E0 $X 8000 alloc-mem 7F00 + 4 -7E89E0 $X ;
' load 268 - ' $M $L
' load 160 + ' 0 $L
$E
dev ide0
: open use-ata-interface 0 &c -1 ;
: set-device-ID set-drive-select ;
: reset-atapi-bus reset-ata-bus ;
' reset-ata-bus 2c + ' 2 $L
$E
dev ide1
: open use-ata-interface 0 &c -1 ;
: set-device-ID set-drive-select ;
: reset-atapi-bus reset-ata-bus ;
' reset-ata-bus 2c + ' 2 $L
$E
dev scsi
: $M ['] do-cmd + ;
: $M2 5 us -5f0 $M $X ;
: $M3 -710 $M f over $X $X ;
: $M4 1 ms ;
-1AC $M ' $M2 $L
100 $M ' $M3 $L
120 $M ' $M4 $L
124 $M ' 1 $L
$E
unselect-dev
boot-command boot

quik.conf
## quik.conf generated by debian-installer
## second image by me. image=Linux fails with unknown-block(0,0)

init-message="QuikBoot (sarge)"
default=MyLinux
timeout=100
partition=9

## Do not point image= to a symlink, quik can't follow symlinks
image=/boot/vmlinux-2.6.8-powerpc
root=/dev/hda9
label=Linux
read-only
ramdisk=/boot/initrd.img-2.6.8-powerpc

image=/boot/vmlinux-2.6.8-ppc2.100504-1
root=/dev/hda9
label=MyLinux
read-only
ramdisk=/boot/initrd.img-ppc2.100504-1

lsmod - d-i original 2.6.8-powerpc kernel - fails to boot with quik
Installed to do the installation

Module Size Used by
xfs 585628 0
reiserfs 333464 0
jfs 201284 0
ext3 130736 2
jbd 71576 1 ext3
mbcache 10116 1 ext3
vfat 15968 0
fat 54052 1 vfat
ext2 65220 1
af_packet 21352 0
bmac 19120 0
crc32 4832 1 bmac
ds 23844 0
yenta_socket 23616 0
pcmcia_core 76788 2 ds,yenta_socket
isofs 42296 0
nls_base 8672 4 jfs,vfat,fat,isofs
ide_cd 49764 0
cdrom 49660 1 ide_cd
ide_disk 27072 5
ide_floppy 23584 0
aec62xx 13500 0
cmd64x 15356 0
generic 5536 0
hpt34x 7040 0
ns87415 6340 0
pdc202xx_new 15836 0
pdc202xx_old 22300 0
sc1200 12776 0
siimage 15712 0
sl82c105 9088 0
trm290 6114 0
via82cxxx 16732 0
mesh 25692 0
usb_storage 84204 0
scsi_mod 113376 2 mesh,usb_storage
usbserial 33840 0
usbhid 53952 0
ohci_hcd 26212 0
usbcore 139092 6 usb_storage,usbserial,usbhid,ohci_hcd
unix 31992 8

lsmod - custom-rolled 2.6.8 kernel (with
:$fakeroot make-kpkg {my version} --added-patches powerpc --initrd
kernel_image)
Module Size Used by
af_packet 21352 2
snd_powermac 41164 0
snd_pcm 116920 1 snd_powermac
snd_page_alloc 13480 1 snd_pcm
snd_timer 29348 1 snd_pcm
snd 64952 3 snd_powermac,snd_pcm,snd_timer
soundcore 11812 1 snd
mesh 24828 0
scsi_mod 113312 1 mesh
ide_cd 49220 0
cdrom 49660 1 ide_cd
bmac 17872 0
crc32 4832 1 bmac
evdev 11968 0
unix 31992 18

in-kernel config
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_HOTPLUG=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
CONFIG_6xx=y
CONFIG_ALTIVEC=y
CONFIG_TAU=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_PPC_CHRP=y
CONFIG_PPC_PMAC=y
CONFIG_PPC_PREP=y
CONFIG_PPC_OF=y
CONFIG_PPCBUG_NVRAM=y
CONFIG_HIGHMEM=y
CONFIG_KERNEL_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_PROC_DEVICETREE=y
CONFIG_CMDLINE_BOOL=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_MAC_FLOPPY=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_IDE_PMAC=y
CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y
CONFIG_BLK_DEV_IDEDMA_PMAC=y
CONFIG_BLK_DEV_IDEDMA_PMAC_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SCSI_LOGGING=y
CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_MACIO=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NET=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_DEV_APPLETALK=y
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_PSAUX_ENABLE=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
CONFIG_INPUT_MISC=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_PMACZILOG=y
CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_NVRAM=y
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
CONFIG_I2C=y
CONFIG_I2C_ALGOBIT=y
CONFIG_FB=y
CONFIG_FB_OF=y
CONFIG_FB_ATY_CT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_NLS=y
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVFS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_HFS_FS=y
CONFIG_HFSPLUS_FS=y
CONFIG_CRAMFS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_LOCKD_V4=y
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_AMIGA_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_ZLIB_INFLATE=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_BOOTX_TEXT=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_MD5=y

I hope this will help d-i/kernel/manual folks to get d-i installing quik
correctly for this type of box.

Regards,
Duane Cottle

[Clive Menzies]

Post by Duane Cottle
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.

Hi Duane

Excellent! Persistence rewarded ....I am ashamed to say I gave up and
resigned myself to using BootX. Let's hope your experience helps the
developers fix it for rc2 .... for us mere mortals ;)

Regards

Clive

[Rick Thomas]

Post by Duane Cottle
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.

Wow! I'm impressed!

Can you summarize what you had to do to get it to work?

Thanks,

Rick

[Duane Cottle]

Post by Rick Thomas

Post by Duane Cottle
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 ***@0,0
# for my scsi it's ***@0,0
ok > devalias # prints aliases - useful to forego typing full paths
ok > setenv boot-device ide/***@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/***@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/***@0,0, or something. I can use its alias,
ide/***@0,0 to get to the disk; however..

A similar tree and alias exist for the scsi drive, but entering
scsi/***@0,0 or mesh/***@0,0 (scsi and mesh, both aliasses) fails: I must
use the full path, pci/mac-io/mesh/***@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

[Duane Cottle]

I already have to correct my last post. I found this in dmesg:
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing
disabled
IN from bad port 3f9 at c0103aac
IN from bad port 3f9 at c0103aac
IN from bad port 3f9 at c0103aac
IN from bad port 2f9 at c0103aac
IN from bad port 2f9 at c0103aac
IN from bad port 2f9 at c0103aac
IN from bad port 3e9 at c0103aac
IN from bad port 3e9 at c0103aac
IN from bad port 3e9 at c0103aac
IN from bad port 2e9 at c0103aac
IN from bad port 2e9 at c0103aac
IN from bad port 2e9 at c0103aac
pmac_zilog: 0.6 (Benjamin Herrenschmidt <***@kernel.crashing.org>)
pmac_zilog: Error registering serial device, disabling pmac_zilog.
pmac_zilog: Did another serial driver already claim the minors?

instead of:
serial8250_init: nothing to do on PowerMac
in the patched kernel dmesg.
I guess the kernel-patches-powerpc-2.6.8 at least save dmesg lines! Ha!

That's what I get for posting before at least a quick check, sorry.

Another OF/scsi quirk:
I entered "nvsetenv auto-boot? true" and changed to "timeout=0" in
quik.conf to check if Sarge will start without stopping in OF. It works
on the ide box, but not the scsi. I got the familiar "Can't OPEN" OF
error. I recalled that at penquinppc.org was something concerning disks
not getting a chance to spin up with just "boot" as the boot command, so

I changed it to the suggested with
"setenv boot-command begin ['] boot catch 1000 ms cr again",
dirty-downed it, and typed in boot at ok >. "Can't OPEN" What?!

I changed it back to "boot", typed "boot", and it booted after the
message "SCSI BUS Reset" or something. Then I played, shutting down,
rebooting, etc., and I can't yet tell whether it's time-related or I
have to enter "boot" at least twice.

There's one for ya.

Regards,
Duane

[Brad Boyer]

Post by Duane Cottle
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...

Perhaps someone will step up and provide evidence to the contrary,
but I'm pretty sure that quik doesn't support loading a ramdisk. I've
never tried it myself, but I don't remember ever hearing about anyone
doing it.

Brad Boyer
***@allandria.com

[Duane Cottle]

Post by Brad Boyer
Perhaps someone will step up and provide evidence to the contrary,
but I'm pretty sure that quik doesn't support loading a ramdisk. I've
never tried it myself, but I don't remember ever hearing about anyone
doing it.
Brad Boyer

man quik.conf says it does, and d-i sets quik.conf up that way.
Not supported? That'd be news to me.

Regards,
Duane

[Holger Levsen]

Hi,

Post by Duane Cottle

Post by Brad Boyer
Perhaps someone will step up and provide evidence to the contrary,
but I'm pretty sure that quik doesn't support loading a ramdisk. I've
never tried it myself, but I don't remember ever hearing about anyone
doing it.

man quik.conf says it does, and d-i sets quik.conf up that way.
Not supported? That'd be news to me.

man quik.conf is wrong, but d-i used to believe that . There are code
fragments for initrd-supports in quik but not more. As the debian 2.6 kernels
use initrds (and will continue to use them as they won't be changed so close
to sarge getting released) they cannot work with quik.
(see http://lists.debian.org/debian-boot/2004/09/msg01884.html for more info,
look for "quik, bootx & initrd")

If you need to use quik, you have to use the 2.4 kernels (with debian sarge
standard kernel packages). Of course, you can build your own 2.6 kernels
without initrd.

So sarge / debian-installer will have to use 2.4.27 with quik - and I don't
see this as a major problems as this old hardware is well supported with 2.4
and you still have the option to build a custom 2.6 kernel after installation.


regards,
Holger

[Sven Luther]

Post by Holger Levsen
Hi,

Post by Duane Cottle

Post by Brad Boyer
Perhaps someone will step up and provide evidence to the contrary,
but I'm pretty sure that quik doesn't support loading a ramdisk. I've
never tried it myself, but I don't remember ever hearing about anyone
doing it.

man quik.conf says it does, and d-i sets quik.conf up that way.
Not supported? That'd be news to me.

man quik.conf is wrong, but d-i used to believe that . There are code
fragments for initrd-supports in quik but not more. As the debian 2.6 kernels
use initrds (and will continue to use them as they won't be changed so close
to sarge getting released) they cannot work with quik.
(see http://lists.debian.org/debian-boot/2004/09/msg01884.html for more info,
look for "quik, bootx & initrd")
If you need to use quik, you have to use the 2.4 kernels (with debian sarge
standard kernel packages). Of course, you can build your own 2.6 kernels
without initrd.
So sarge / debian-installer will have to use 2.4.27 with quik - and I don't
see this as a major problems as this old hardware is well supported with 2.4
and you still have the option to build a custom 2.6 kernel after installation.

Notice that if we manage to free miboot, a miboot kernel on a special
partition may be one solution for 2.6.8 kernels with initrd.

That said, the amount of work needed to freeing miboot may well be more than
the amount of work needed to get initrds working in quik.

Friendly,

Sven Luther

[Rick Thomas]

Post by Sven Luther
Notice that if we manage to free miboot, a miboot kernel on a special
partition may be one solution for 2.6.8 kernels with initrd.

The situation may be worse than we thought. Take a look at Apple
Tech Note 1189 which is available at
http://developer.apple.com/technotes/tn/pdf/tn1189.pdf

In particular see pages 35 and 36 regarding the licensing required
to use the apple patch chaining drivers and associated patches to
the Apple boot ROM.

I may be mistaken, but I believe that, when booting from a hard
disk (not a floppy), miboot depends on having it's early stages
loaded by the Apple OldWorld Boot ROM code, which needs the
afore-mentioned patches to do its job.

These patches and the patch chaining driver are placed on the
low-numbered partitions of a hard-disk by the Apple disk
partitioning utility (or by third-party partitioning utilities that
[presumably] use the patches under license from Apple.)

In the listing snippet below, I'm talking about the contents of
hdc[2-5] -- the reason why my macOS9 partition is hdc6 rather than
hdc2.

This theory would be disproved if anyone had ever gotten miboot to
boot from a disk that was missing the driver partitions. Anybody
ever tried that?

For NewWorld machines, this seems *not* to be required. I believe
that this is because all the code needed to boot is in the Open
Firmware. This is the reason why, if you install a PCI disk
interface card and you expect to boot from it, you need to be sure
that the card has an on-board ROM with Open Firmware booting
support that effectively extends the mother-board's Open Firmware
so that it knows how to deal with the new card.

Booting from a floppy does not require any patches -- for a couple
of reasons: 1) space -- a floppy doesn't have much space and a
couple of dozen Kbytes for patches would be highly inconvenient; 2)
testing -- the ROM code that deals with booting from floppies must
get pretty well rung-out during design test, so it's got to be
absolutely bug-free before the hardware is released.

Enjoy!

Rick


============

debian:~# mac-fdisk -l
/dev/hdc
# type name length
base ( size ) system
/dev/hdc1 Apple_partition_map Apple 63 @
1 ( 31.5k) Partition map
/dev/hdc2 Apple_Driver43 Macintosh 54 @
64 ( 27.0k) Driver 4.3
/dev/hdc3 Apple_Driver43 Macintosh 74 @
118 ( 37.0k) Driver 4.3
/dev/hdc4 Apple_Driver_IOKit Macintosh 512 @
192 (256.0k) Unknown
/dev/hdc5 Apple_Patches Patch Partition 512 @
704 (256.0k) Unknown
/dev/hdc6 Apple_HFS untitled 2097152 @
1216 ( 1.0G) HFS
/dev/hdc7 Apple_UNIX_SVR2 root 19531251 @
2098368 ( 9.3G) Linux native
/dev/hdc8 Apple_UNIX_SVR2 swap 1953126 @
21629619 (953.7M) Linux swap

[Brad Boyer]

Post by Rick Thomas
I may be mistaken, but I believe that, when booting from a hard
disk (not a floppy), miboot depends on having it's early stages
loaded by the Apple OldWorld Boot ROM code, which needs the
afore-mentioned patches to do its job.

Well, it's not really that simple. I'll try to explain as I go
along in the message.

Post by Rick Thomas
These patches and the patch chaining driver are placed on the
low-numbered partitions of a hard-disk by the Apple disk
partitioning utility (or by third-party partitioning utilities that
[presumably] use the patches under license from Apple.)
In the listing snippet below, I'm talking about the contents of
hdc[2-5] -- the reason why my macOS9 partition is hdc6 rather than
hdc2.

Actually, The partitions between the partition map and your data are
the actual disk drivers (as well as patches to them). The I/O layer
in the classic MacOS is really odd. The OS provides the equivalent
of VFS and the low level SCSI/IDE/etc. framework. The drivers to
connect the two different layers are device specific. This would be
similar to the sd/sr driver in linux. For floppies, the .SONY driver
is completely in ROM, but for other devices, the system has to load
the real driver off of the device. The ROM just has a really simple
driver that is barely smart enough to find and load drivers.

I looked into writing a read-only driver (for CD-ROM usage), but it's
a ton of work. Apple makes enough info available. The only issue is
the driver patches that you mentioned above. They are workarounds for
some really stupid bugs in the ROM in places like the MESH driver.
They would be difficult to reproduce in a free environment.

Post by Rick Thomas
This theory would be disproved if anyone had ever gotten miboot to
boot from a disk that was missing the driver partitions. Anybody
ever tried that?

Can't be done on oldworld. The MacOS ROM will not read a device for
which it can't find drivers. This is why we can't make a bootable
CD-ROM (for oldworld) without using something like Toast.

Post by Rick Thomas
For NewWorld machines, this seems *not* to be required. I believe
that this is because all the code needed to boot is in the Open
Firmware. This is the reason why, if you install a PCI disk
interface card and you expect to boot from it, you need to be sure
that the card has an on-board ROM with Open Firmware booting
support that effectively extends the mother-board's Open Firmware
so that it knows how to deal with the new card.

That's because on newworld, even the MacOS is actually loaded off
disk directly from OF. We can use yaboot to hook in at exactly the
same level that Apple uses for their own system. However, the classic
MacOS still needs the drivers even on a newworld system. They just
get loaded by the fake software ROM that is loaded off the system disk.

Post by Rick Thomas
Booting from a floppy does not require any patches -- for a couple
of reasons: 1) space -- a floppy doesn't have much space and a
couple of dozen Kbytes for patches would be highly inconvenient; 2)
testing -- the ROM code that deals with booting from floppies must
get pretty well rung-out during design test, so it's got to be
absolutely bug-free before the hardware is released.

Due to space limits, Apple explicitly designed the system to not
require or even expect drivers on a floppy. The drivers are only
expected on partitioned media. And before you ask, Apple style
CD-ROM images are indeed partitioned.

Brad Boyer
***@allandria.com

[Rick Thomas]

Post by Brad Boyer

I may be mistaken, but I believe that <snip...>

Well, it's not really that simple. I'll try to explain as I go
along in the message. <snip...>

Thanks Brad! the extra detail really helps.

Bottom line question... Does the Apple licensing requirement for
the drivers and patches mean that (as a practical matter) we'll
never be able to write a "free" miboot that can boot off
"partitioned media"?

Is a "free" but "floppy only" version of miboot worth the effort?

Rick

[Brad Boyer]

Post by Rick Thomas
Bottom line question... Does the Apple licensing requirement for
the drivers and patches mean that (as a practical matter) we'll
never be able to write a "free" miboot that can boot off
"partitioned media"?

Well, I wouldn't say never. The only patch we absolutely have to have
is the one for MESH support. Obviously that is important, since most
oldworld models do have that. However, that would only prevent us
from creating a free partitioning tool. As long as the user has at
some point partitioned the drive with an official tool, the patches
will all be there. The problem with that is CD-ROM support, since
that is done as part of the ISO image creation. The patches aren't
actually put into miboot, so it's relatively independent of the
question of "is miboot free".

Would we be able to use the patch drivers if someone convinced
Apple to give us permission to redistribute them? This is old,
obsolete stuff, after all. If we could even put them in a special,
non-free package, it could be usable.

Post by Rick Thomas
Is a "free" but "floppy only" version of miboot worth the effort?

Probably. It would make it possible to make bootable floppy images
that actually work without having to change OF settings. If we had
this support, we could legally put an image up that users could dd
onto a floppy, stick in their Mac, and run the installer without
needing anything else.

Of course, they couldn't install a bootloader in this case without
either booting from floppy every time or having used 3rd party tools.

Brad Boyer
***@allandria.com

[Rick_Thomas]

Post by Brad Boyer
Would we be able to use the patch drivers if someone convinced
Apple to give us permission to redistribute them? This is old,
obsolete stuff, after all. If we could even put them in a special,
non-free package, it could be usable.

I'll see what I can do on this. I'll start by contacting the
University's Apple Technical Support people.

Post by Brad Boyer

Post by Rick Thomas
Is a "free" but "floppy only" version of miboot worth the effort?

Probably. It would make it possible to make bootable floppy images
that actually work without having to change OF settings. If we had
this support, we could legally put an image up that users could dd
onto a floppy, stick in their Mac, and run the installer without
needing anything else.
Of course, they couldn't install a bootloader in this case without
either booting from floppy every time or having used 3rd party tools.

Booting from floppy every time is a pain -- especially since floppies
tend to go bad (wear out, actually) over time. But it's a possible
option in the rare case when you haven't got access to any MacOS{89}
install CD.

But that's a rare situation. The most common situation is that you will
have a MacOS{8.x,9.x} CD on hand (or can buy one one cheap on e-bay).

In that case you can use BootX, and don't need (free or otherwise)
miboot unless you're a free software absolutist. Though, come to think
of it, even the absolutist will either have to live with quik's quirks
or allow Apple's non-free drivers to take up space on their system
disk. (If it helps, you can just think of them as firmware!)

I guess I'd support the effort of building a clean-room free version of
miboot, just to keep the absolutists happy (though I'm not of that
persuasion myself) if I was sure that it *would* keep them happy...

With the effort on D-I winding down, we might actually be able to come
up with the necessary talents and person-power to do the job!

Enjoy!

Rick

[Brad Boyer]

Post by Rick_Thomas
Booting from floppy every time is a pain -- especially since floppies
tend to go bad (wear out, actually) over time. But it's a possible
option in the rare case when you haven't got access to any MacOS{89}
install CD.
But that's a rare situation. The most common situation is that you will
have a MacOS{8.x,9.x} CD on hand (or can buy one one cheap on e-bay).

As long as you have the official tools, and use them to partition your
drive, you already get the drivers and patches installed. And as long
as you don't accidentally delete them with the partitioning tools in
the installer, it's irrelevant.

Post by Rick_Thomas
In that case you can use BootX, and don't need (free or otherwise)
miboot unless you're a free software absolutist. Though, come to think
of it, even the absolutist will either have to live with quik's quirks
or allow Apple's non-free drivers to take up space on their system
disk. (If it helps, you can just think of them as firmware!)

Even in this case, someone would have to write the regular disk drivers.
The patches are just fixes to allow the regular drivers to work at boot
time. Apple is much less likely to let us redistribute those unless we
write it ourselves. They have documented it enough for someone to do
it, since third party drivers were relatively common at one point.

Post by Rick_Thomas
I guess I'd support the effort of building a clean-room free version of
miboot, just to keep the absolutists happy (though I'm not of that
persuasion myself) if I was sure that it *would* keep them happy...

Yes, but that by itself would not be enough to start from nothing and
install. It's messier than it seems like it should be due to the
on-disk driver headache.

To support starting from just a Debian CD on all oldworld boxes as well
as install a bootable system, we need to do the following:

1) Write disk drivers for SCSI and IDE (both HD and CD-ROM)
2) License the patches from Apple (or somehow reverse engineer them)
3) Add support to mac-fdisk to install the drivers and patches
4) Fix miboot to be truly free.
5) Add a miboot installer (similar to ybin/mkofboot)

On the other hand, if you only want to use it on floppies, only #4
(and maybe #5) are needed.

Brad Boyer
***@allandria.com

[Rick Thomas]

Post by Brad Boyer
To support starting from just a Debian CD on all oldworld boxes as well
1) Write disk drivers for SCSI and IDE (both HD and CD-ROM)
2) License the patches from Apple (or somehow reverse engineer them)
3) Add support to mac-fdisk to install the drivers and patches
4) Fix miboot to be truly free.
5) Add a miboot installer (similar to ybin/mkofboot)
On the other hand, if you only want to use it on floppies, only #4
(and maybe #5) are needed.

Let me see if I've got this right...

The world is divided into three types of people:

0) People with hardware other than OldWorld Powermacs. I will
ignore this group, except to say that, according to the latest
popularity contest results, they constitute over 98% of the users
of Debian software.

1) Of those who have an OldWorld PowerMac (or clone) the large
majority will also have a copy of the MacOS{8.x,9.x} install CD
that came with the machine (or that they bought cheap on e-bay, or
bought expensive from Apple when the world was new and we were all
very young...) and will be willing to use it to install MacOS so
that they can use BootX as their default boot loader.

2) A vocal but tiny minority of absolutists who are unwilling to
have any non-free software (above the level of unavoidable firmware
ROMs) on their machines.

3) Those who are opposed to non-free software or for other reasons
(such as disk space) don't want to have MacOS on their machines,
but are willing to at least have their disks initialized and
partitioned by the Apple Disk Utility software. (Personal opinion:
this group is likely somewhat larger than group 2 but still much
smaller than group 1.)


Group 1 has no problem. They can use BootX to start up the D-I
installer, and they can continue to use BootX as their default
boot-loader. The fact that BootX is not free is not a problem for
these folks. MacOS isn't free either! All they need is good
directions in the manual for how to do it.

Eliminating group 1 leaves us with (as a guess) somewhat less than
0.1% of debian users in groups 2 and 3. Still, this represents
(guess) 5% of Debian OldWorld PowerMac users. And they are a vocal
bunch, for all their small numbers.

As Brad points out, group 3 needs only a clean-room free
implementation of miboot and they are off and running. They can
boot from floppies to run the D-I installer -- either via the
network or via CDs, and use the (proposed) free miboot as their
default boot-loader from disk after installation is complete. That
is: after the initial installation the Apple drivers on their disk
will be enough to allow them to use miboot to boot from that disk.
They will need good clear directions in the manual for how to make
boot floppies and use them to start up D-I.

We're now down to group 2 -- the (at a guess) less than 0.01% of
hard-core absolutists who will not allow *any* non-free software to
touch their machines. These folks have a few alternatives: a) They
can implement their own free boot software, including Apple Boot
ROM compatible disk and CD drivers. b) They can put up with the
vagaries of Open firmware and quik for their particular hardware.
c) They can use the (proposed) free miboot but only from
floppies -- meaning that they must forever boot their machine with
a floppy -- installation and post-install production.

I don't think that alternative (a) is going to happen. There just
isn't the critical mass to get such a project off the ground.
Personally, I think alternative (b) is not viable either -- it's
just too much pain for anyone to put up with long-term -- though
there are undoubtedly folks out there who will try it for a while
before they give up. Fortunately, alternative (c) is a workable
compromise between pain (having to keep and use floppies, and
replace them when they wear out) and living with your principles.

Hope this helps!

Rick

[Brad Boyer]

Post by Rick Thomas
Let me see if I've got this right...

[ Massive snip ]

Yes, that looks accurate to me.

Post by Rick Thomas
I don't think that alternative (a) is going to happen. There just
isn't the critical mass to get such a project off the ground.

You'll note that I haven't done it, either. :)

If I do ever work on this, I'll probably do it for the 68k platform,
and make it compatible with ppc only if it's convenient. It would be
nice to be able to make a bootable CD for 68k and oldworld ppc macs.
It's way down on my list, tho.

Post by Rick Thomas
Personally, I think alternative (b) is not viable either -- it's
just too much pain for anyone to put up with long-term -- though
there are undoubtedly folks out there who will try it for a while

Well, I have quik on my 7600. However, I should admit that I didn't
have any choice on that when I originally installed linux on it.
It's even still got some ancient system on it using glibc 1.99.
Maybe I should pull it out some time and install something modern.

Post by Rick Thomas
before they give up. Fortunately, alternative (c) is a workable
compromise between pain (having to keep and use floppies, and
replace them when they wear out) and living with your principles.

I tend to agree.

Brad Boyer
***@allandria.com

[Sebastiaan Molenaar]

On Sat, 2004-10-30 at 06:54, Rick Thomas wrote:
<snip> </snip>

Post by Rick Thomas
ROM compatible disk and CD drivers. b) They can put up with the
vagaries of Open firmware and quik for their particular hardware.

<snip> </snip>

Post by Rick Thomas
Personally, I think alternative (b) is not viable either -- it's
just too much pain for anyone to put up with long-term -- though
there are undoubtedly folks out there who will try it for a while
before they give up. Fortunately, alternative (c) is a workable

<snip> </snip>

Now my question is, why isn't it possible to get this more stable?
(guess wich group I'm in)
Is it just that the apple OF isn't stable or is quik not stable?
I understand apple OF is different on pretty much every oldworld ppc
but it should still be possible to find the workaround for every different
one and once it's working it should keep working doesn't it?

Greetz,
Seb.

[Rick Thomas]

Post by Sebastiaan Molenaar
<snip> </snip>

Post by Rick Thomas
ROM compatible disk and CD drivers. b) They can put up with the
vagaries of Open firmware and quik for their particular hardware.

<snip> </snip>

Post by Rick Thomas
Personally, I think alternative (b) is not viable either -- it's
just too much pain for anyone to put up with long-term -- though
there are undoubtedly folks out there who will try it for a while
before they give up. Fortunately, alternative (c) is a workable

<snip> </snip>
Now my question is, why isn't it possible to get this more stable?
(guess wich group I'm in)
Is it just that the apple OF isn't stable or is quik not stable?

A bit of both.

Post by Sebastiaan Molenaar
I understand apple OF is different on pretty much every oldworld ppc
but it should still be possible to find the workaround for every different
one and once it's working it should keep working doesn't it?

Indeed, the BSD folks have done exactly that. Quik is their
preferred boot-loader for OldWorld Macs. They have a huge table
with each model of Mac and the particular workarounds/patches for
that model to make its OF boot via quik.

To my mind, the fundamental problem is that patches to Open
Firmware, once made, don't last. OF patches reside in the PRAM.
If you ever boot MacOS{8,9} on a patched machine you will have to
clear the PRAM and thereby loose all your patches. Also, the PRAM
can be cleared by a power failure if your PRAM battery has run
down -- a common problem on older machines. If the patches get
lost, you have to re-patch, which can be a pain if your machine has
the kind of OF that wants a terminal on the serial port.

That said, I have two old 6500 PowerMacs that boot via quik and
have been running that way for over four years. They are sitting
in my machine room on a diesel-backed UPS and haven't been rebooted
more than a half-dozen times in those four years. I've had to
re-patch one of them a couple of times. It's not fun, but it's not
impossible either. Fortunately, neither of these machines is
"mission critical" -- they can afford to be offline for a week or
so if they loose their PRAM patches while I'm on vacation.

Rick