Re: Linux 3.1-2-m68k config (was: Re: Linux 3.10-2-m68k FPU support)
On Mon, Nov 11, 2013 at 6:16 AM, Finn Thain wrote:
>> > ! CONFIG_FB_SYS_COPYAREA : m n
>> > ! CONFIG_FB_SYS_FILLRECT : m n
>> > ! CONFIG_FB_SYS_FOPS : m n
>> > ! CONFIG_FB_SYS_IMAGEBLIT : m n
>> >
>> >Would this prevent the macfb framebuffer console from working in the
>> >absence of kernel modules?
>> >
>>
>> With the switch to initrd, absence of modules is simply no longer
>> supported at all, period.
>
> When something goes wrong, and the kernel messages aren't available to
> tell you what went wrong, then you may lack the information you need to
> support those things that you are willing to support.
>
> Hence I was trying to find an explanation for the screen shot posted,
> which says "console [tty0] enabled" even though the macfb console did not
> appear.
No, without fb/console support you wouldn't even see those.
>> ...
>> Besides, if multi_defconfig has it as "n"...
>
> That should be OK; all of my test kernel configs also disable these
> options.
Indeed. Mac needs the CONFIG_FB_CFB_* counterparts.
CONFIG_FB_SYS_* is for system RAM, while CONFIG_FB_CFB_*
is for iomem. Not that it would matter much on m68k, m68k has no
strict separation between both.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMuHMdXKPDo-cNL5btcmy=4obz9WB2W=9buxbu5m72uxdsy...@mail.gmail.com
Re: Modernizing a Macintosh LC III
On Mon, Nov 11, 2013 at 6:04 AM, Patrick McCarthy wrote:
> It seems that one way or another something is missing, so I either need to
> find a better kernel/ramdisk pair or else build one. I only have this one
> 68k Mac that runs 2.2 when it works, how would I build something? Would it
> be the same kernel build process as one does for x86? Is there anywhere to
> look for other prebuilt pairs?
I think the easiest way is to cross-compile your own mac_defconfig kernel.
Get a cross-compiler from:
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
(s/x86_64/i386/ if you're still in 32-bit land) and install it.
make ARCH=m68k mac_defconfig
make ARCH=m68k
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMuHMdUnPhhY8caUTMqVqUK=zwbv3epqmkcwyktmtm+1yy_...@mail.gmail.com
Re: Modernizing a Macintosh LC III
Scott Holder dixit: >> I don't use an initrd (I build my own kernels) so I can't tell you >> what the right arguments are. Probably root=/dev/ram Also, you No, root=/dev/ram is for when you want to run a system installed on the initrd. For the “initramfs style”, you just need to ensure the initrd.img-$version file is loaded by the bootloader, the rest appears to be automagic. >> probably need to specify the real root filesystem partition (e.g. >> /dev/sda5) but I don't know how this is done for a Debian initrd. > I still use the real root (root=/dev/sda4 for example) option in Yes, just pass root=something on the kernel command line, and the Debian magic scripts will dissect that. > Still haven't gotten around to trying to figure out the ADB options > for X. I have a couple or three PPC Macs sitting around that ought to I think evdev is correct right now for keyboard and mouse, and fbdev might work for the graphical device (IIRC, someone reported that it works on mac68k OOTB, and Geert has written a patch for Atari, although I’ve not checked yet whether it’s been applied upstram, and whether it’s already included in a release that is packaged inside Debian, and I still need to manually rebuild X.org since autobuilding it fails because it doesn’t seem to pass its testsuite or something). On the other hand, I was at OpenRheinRuhr this weekend and ran Debian/m68k in ARAnyM on my laptop as “showcase”, which gathered quite some interest from the crowd. (And I talked before thinking, which is why I was forcibly volunteered to hold a talk about it at the next VCFe (Vintage Computing Festival Europe)… I’ll talk mostly about the ARAnyM and Debian aspects of it, so if people can fill in the upstream (e.g. Linux kernel) or hardware (e.g. real Atari, Amiga buildds, etc.) parts, we could do a joint talk.) bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”) -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.131425290.23...@herc.mirbsd.org
Re: Linux 3.1-2-m68k config (was: Re: Linux 3.10-2-m68k FPU support)
Geert Uytterhoeven dixit: >On Mon, Nov 11, 2013 at 6:16 AM, Finn Thain wrote: >>> > ! CONFIG_FB_SYS_COPYAREA : m n >>> > ! CONFIG_FB_SYS_FILLRECT : m n >>> > ! CONFIG_FB_SYS_FOPS : m n >>> > ! CONFIG_FB_SYS_IMAGEBLIT : m n >>> > >>> >Would this prevent the macfb framebuffer console from working in the >>> >absence of kernel modules? >> When something goes wrong, and the kernel messages aren't available to >> tell you what went wrong, then you may lack the information you need to I see. >> Hence I was trying to find an explanation for the screen shot posted, >> which says "console [tty0] enabled" even though the macfb console did not >> appear. > >No, without fb/console support you wouldn't even see those. OK. >Indeed. Mac needs the CONFIG_FB_CFB_* counterparts. > >CONFIG_FB_SYS_* is for system RAM, while CONFIG_FB_CFB_* >is for iomem. Not that it would matter much on m68k, m68k has no >strict separation between both. OK. So there needs to be no further change then those already submitted to the Debian Linux maintainers in #728392 correct? bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”) -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.131418320.23...@herc.mirbsd.org
Re: Buying RAM expansion from project money
Am 05.11.2013 um 11:27 schrieb John Paul Adrian Glaubitz : >> So I would say, that - if noone objects until Thursday 0:00 GMT - we ask for >> a quote of 4 BigRamPlus cards with additional 2 cards as an option when we >> made sure they work inside of the modified Tower cases. Or, because it's now >> about just the quote, to ask for 6 cards and then order at least 4 cards >> with 2 more as an option. > There is no quote. We order the cards from icomp.de and can get a 10% > discount with an electronic coupon that Jens gave me. Anyway, the question is still: 4 or 6 cards? As long as Crest and Elgar are sitting in 3d party tower cases I recommend to first make a test with both of them before we buy cards for them. So, that would make 4 BigRamPlus cards for now. Is there any buildd without a network card? Does any buildd beside the ZIII Amigas need some RAM? Anything else? And who will do the buying and transaction? I think we need to pay it first and then getting reimbursed. -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc signature.asc Description: Message signed with OpenPGP using GPGMail
BTS tags/pseudopackages for ports [Was: Re: Potential issues for most ports]
On Tue, 05 Nov 2013, Don Armstrong wrote: > In any event, if a few active porters wouldn't mind creating a wishlist > bug against bugs.debian.org for this with a suggested course of action, > I'd appreciate it. Assuming there is no significant disagreement about > that course of action, I'd like to implement it within a week or so. If someone has filed a wishlist bug, I've missed it. -- Don Armstrong http://www.donarmstrong.com I really wanted to talk to her. I just couldn't find an algorithm that fit. -- Peter Watts _Blindsight_ p294 -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013181711.gv9...@rzlab.ucr.edu
Re: Buying RAM expansion from project money
On Mon, Nov 11, 2013 at 3:56 PM, Ingo Jürgensmann
wrote:
> Anyway, the question is still: 4 or 6 cards?
>
> As long as Crest and Elgar are sitting in 3d party tower cases I recommend to
> first make a test with both of them before we buy cards for them.
If there are problems with a card in one ore two machines, they can be
added to one of the others, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMuHMdXFiWE8agQTCW+1u1MQS0MnxDn02ygkn6Cfc717q]9...@mail.gmail.com
Re: Modernizing a Macintosh LC III
On Mon, Nov 11, 2013 at 3:31 PM, Thorsten Glaser wrote:
> I think evdev is correct right now for keyboard and mouse, and
> fbdev might work for the graphical device (IIRC, someone reported
> that it works on mac68k OOTB, and Geert has written a patch for
> Atari, although I’ve not checked yet whether it’s been applied
> upstram, and whether it’s already included in a release that is
> packaged inside Debian, and I still need to manually rebuild X.org
> since autobuilding it fails because it doesn’t seem to pass its
> testsuite or something).
It's in upstream xorg-server-1.14.99.2 and later.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMuHMdU4v1EtSSi_Upd5=o5jlfqri6dccd+5qem5jsuge9t...@mail.gmail.com
Re: Buying RAM expansion from project money
On 11/11/2013 07:28 PM, Geert Uytterhoeven wrote: > On Mon, Nov 11, 2013 at 3:56 PM, Ingo Jürgensmann > wrote: >> Anyway, the question is still: 4 or 6 cards? >> >> As long as Crest and Elgar are sitting in 3d party tower cases I recommend >> to first make a test with both of them before we buy cards for them. > > If there are problems with a card in one ore two machines, they can be > added to one of the others, right? Yes, I'm pretty sure, you can. I have seen people bumping the memory of their Amigas up to 1GB using four of these cards. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52812561.9070...@physik.fu-berlin.de
[OT] Re: Buying RAM expansion from project money
John Paul Adrian Glaubitz dixit: >Yes, I'm pretty sure, you can. I have seen people bumping the memory of >their Amigas up to 1GB using four of these cards. I’m almost finished building KDEPIM 4.11 so you can actually make use of all that memory :D SCNR, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”) -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.131847090.23...@herc.mirbsd.org
Re: Buying RAM expansion from project money
Am 11.11.2013 um 19:28 schrieb Geert Uytterhoeven : >> As long as Crest and Elgar are sitting in 3d party tower cases I recommend >> to first make a test with both of them before we buy cards for them. > If there are problems with a card in one ore two machines, they can be > added to one of the others, right? Ok, that's a valid point. So we are going for 6 cards. Who's volunteering to order them? :) -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc signature.asc Description: Message signed with OpenPGP using GPGMail
X11 on Atari/ARAnyM (was Re: Modernizing a Macintosh LC III)
Geert Uytterhoeven dixit: [ fbdev for Atari ] >It's in upstream xorg-server-1.14.99.2 and later. Thanks! Debian experimental has got 1.14.99.3, which I’ve just started building on just another VM ;-) (now I’m out of idle/stopped ARAnyM instances…) I’ll write again when it’ll be uploaded. The magic then: deb http://ftp.debian-ports.org/debian experimental main bye, //mirabilos -- │ untested │ tut natürlich │ was auch sonst ... │ fijn ☺ -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.131912330.23...@herc.mirbsd.org
Bug#729337: xorg-server: FTBFS: preprocessor macro R_SP conflict with glibc headers
Source: xorg-server Version: 2:1.14.99.3-1 Severity: important Justification: fails to build from source (but built successfully in the past) Hi, trying to build xorg-server from experimental because it includes a patch to support the Atari planes for the fbdev module, upstream. Note that the version in sid FTBFS due to this: .../../../../hw/xfree86/int10/xf86x86emu.c:89:5: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] I have no idea why, but (also in #728333 for console-tools) on some buildds, -Werror=format-security is enabled, leading to those. I do suspect this also applies to the version in experimental, given the warnings shown (full build log attached), but the flag does not show up in cowbuilder and on some other buildds, so this is an unknown issue. Anyway, back to the problem at hand: there’s a build failure, basically because xf86x86emu.c #defines R_SP before including which in turn pulls /usr/include/m68k-linux-gnu/sys/ucontext.h in, which *also* defines R_SP (which is apparently valid to do). The R_SP definition in X11 comes from: hw/xfree86/x86emu/x86emu/regs.h comes from: ../../../../include/globals.h There are some ways to fix this, such as including first in regs.h, then #undef-ing all R_* things before redefining them, which (given the existing use of headers-including-headers here) would fit the overall theme, or blaming eglibc (which doesn’t look like a viable solution), or other hacks. I’m tending towards the first way, which is why I file this against xorg-server; please let me know if something like this is acceptable: --- ../../../../hw/xfree86/x86emu/x86emu/regs.h~2013-11-11 22:52:33.0 + +++ ../../../../hw/xfree86/x86emu/x86emu/regs.h 2013-11-11 22:55:55.0 + @@ -39,6 +39,9 @@ #ifndef __X86EMU_REGS_H #define __X86EMU_REGS_H +/* we sometimes clash with system headers, so pull them in here */ +#include + /*-- Macros and type definitions --*/ #ifdef PACK @@ -117,6 +120,14 @@ }; /* 8 bit registers */ +#undef R_AH +#undef R_AL +#undef R_BH +#undef R_BL +#undef R_CH +#undef R_CL +#undef R_DH +#undef R_DL #define R_AH gen.A.I8_reg.h_reg #define R_AL gen.A.I8_reg.l_reg #define R_BH gen.B.I8_reg.h_reg @@ -127,18 +138,32 @@ #define R_DL gen.D.I8_reg.l_reg /* 16 bit registers */ +#undef R_AX +#undef R_BX +#undef R_CX +#undef R_DX #define R_AX gen.A.I16_reg.x_reg #define R_BX gen.B.I16_reg.x_reg #define R_CX gen.C.I16_reg.x_reg #define R_DX gen.D.I16_reg.x_reg /* 32 bit extended registers */ +#undef R_EAX +#undef R_EBX +#undef R_ECX +#undef R_EDX #define R_EAX gen.A.I32_reg.e_reg #define R_EBX gen.B.I32_reg.e_reg #define R_ECX gen.C.I32_reg.e_reg #define R_EDX gen.D.I32_reg.e_reg /* special registers */ +#undef R_SP +#undef R_BP +#undef R_SI +#undef R_DI +#undef R_IP +#undef R_FLG #define R_SP spc.SP.I16_reg.x_reg #define R_BP spc.BP.I16_reg.x_reg #define R_SI spc.SI.I16_reg.x_reg @@ -147,14 +172,12 @@ #define R_FLG spc.FLAGS /* special registers */ -#define R_SP spc.SP.I16_reg.x_reg -#define R_BP spc.BP.I16_reg.x_reg -#define R_SI spc.SI.I16_reg.x_reg -#define R_DI spc.DI.I16_reg.x_reg -#define R_IP spc.IP.I16_reg.x_reg -#define R_FLG spc.FLAGS - -/* special registers */ +#undef R_ESP +#undef R_EBP +#undef R_ESI +#undef R_EDI +#undef R_EIP +#undef R_EFLG #define R_ESP spc.SP.I32_reg.e_reg #define R_EBP spc.BP.I32_reg.e_reg #define R_ESI spc.SI.I32_reg.e_reg @@ -163,6 +186,12 @@ #define R_EFLG spc.FLAGS /* segment registers */ +#undef R_CS +#undef R_DS +#undef R_SS +#undef R_ES +#undef R_FS +#undef R_GS #define R_CS seg.CS #define R_DS seg.DS #define R_SS seg.SS -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 3.11-1-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013225718.23696.24577.report...@ara3.mirbsd.org
Re: Modernizing a Macintosh LC III
On Mon, 11 Nov 2013, Patrick McCarthy wrote: > > MacOS applications only get the amount of memory assigned to them. You > > can increase Penguin's memory in Finder using Get Info under the File > > menu. Given the size of this kernel image, Penguin's default setting > > isn't likely to work. > I tried playing around with this - on a fresh boot with no open windows, > I have 5.9mb free. I followed your advice and maximized the minimum ram > required, however on doing that and trying to boot the kernel/initrd > Penguin says it doesn't have enough memory to allocate. The dearth of > memory is a result of running System 7.5, but though I could downgrade > messing with MacOS is more hassle than I'm up for. I use MacOS 7.5.3 on everything; even 8 MB systems. The overheads are small enough since you don't need any system extensions to run Penguin. You can disable those with the Extensions Manager control panel (I think that's what it's called) or just restart and hold down shift key when you hear the chime. A few seconds later you will see something like "Extensions disabled" on the screen. > > Fortunately, emile supports mounting the hard disk (not just from > floppy) and loading from there - the progress bars load and I have every > reason to believe I can boot that way, Sounds good. I didn't know emile could do that... > assuming I get the correct initrd and kernel for the job. Right. I can't validate these files as I have no m68k Mac hardware to hand. Perhaps Scott or one of the Debian developers can test this initrd and kernel binary on a Mac. > > It seems that one way or another something is missing, so I either need > to find a better kernel/ramdisk pair or else build one. I only have this > one 68k Mac that runs 2.2 when it works, how would I build something? > Would it be the same kernel build process as one does for x86? Is there > anywhere to look for other prebuilt pairs? If you are comfortable with cross compiling kernels, that's the best way to go. If not, and if you can't use the Debian kernels, then let me know and I'll build a suitable kernel binary for you. Finn -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LNX.2.00.1311121039400.20517@nippy.intranet
Re: Linux 3.1-2-m68k config (was: Re: Linux 3.10-2-m68k FPU support)
On Mon, 11 Nov 2013, Geert Uytterhoeven wrote: > On Mon, Nov 11, 2013 at 6:16 AM, Finn Thain > wrote: > >> > ! CONFIG_FB_SYS_COPYAREA : m n > >> > ! CONFIG_FB_SYS_FILLRECT : m n > >> > ! CONFIG_FB_SYS_FOPS : m n > >> > ! CONFIG_FB_SYS_IMAGEBLIT : m n > >> > > >> >Would this prevent the macfb framebuffer console from working in the > >> >absence of kernel modules? > >> > > >> > >> With the switch to initrd, absence of modules is simply no longer > >> supported at all, period. > > > > When something goes wrong, and the kernel messages aren't available to > > tell you what went wrong, then you may lack the information you need > > to support those things that you are willing to support. > > > > Hence I was trying to find an explanation for the screen shot posted, > > which says "console [tty0] enabled" even though the macfb console did > > not appear. > > No, without fb/console support you wouldn't even see those. "console [tty0] enabled" comes from the early console, which implies CONFIG_FRAMEBUFFER_CONSOLE and CONFIG_EARLY_PRINTK. But neither of these implies a working macfb... > > >> ... > >> Besides, if multi_defconfig has it as "n"... > > > > That should be OK; all of my test kernel configs also disable these > > options. > > Indeed. Mac needs the CONFIG_FB_CFB_* counterparts. > > CONFIG_FB_SYS_* is for system RAM, while CONFIG_FB_CFB_* is for iomem. > Not that it would matter much on m68k, m68k has no strict separation > between both. OK, thanks Geert. I guess the mystery of the missing macfb remains unsolved. Without hardware I'm not going to be much help here. Finn -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LNX.2.00.1311121104180.20517@nippy.intranet
Re: Modernizing a Macintosh LC III
On 11/11/2013 12:04 AM, Patrick McCarthy wrote: I tried playing around with this - on a fresh boot with no open windows, I have 5.9mb free. I followed your advice and maximized the minimum ram required, however on doing that and trying to boot the kernel/initrd Penguin says it doesn't have enough memory to allocate. The dearth of memory is a result of running System 7.5, but though I could downgrade messing with MacOS is more hassle than I'm up for. If you're on a 36mb system and only showing 5.9mb free, it sounds like you're running in 24-bit mode. Go to the Memory control panel and make sure you're in 32 bit mode. This should let you access the whole 36mb in Mac OS. I haven't messed with emile at all but I've had good luck with Penguin so I'll likely stick with it. I do occasionally use the Mac side as well so I have a complete happy installation of 8.1 there. I'm not completely familiar with the depths of the Mac hardware; if it's still in 24-bit mode when emile tries to boot (thanks to PRAM settings) then that could account for the failures. Unfortunately since I'm on 8.1 I don't have an easy way of testing a boot in 24 bit mode since it requires 32-bit. assuming I get the correct initrd and kernel for the job. These are the same pair I'm using, so they should work. Scott -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52819bb8.3040...@iamscott.net
Re: Modernizing a Macintosh LC III
On Mon, 11 Nov 2013, Scott Holder wrote: > On 11/11/2013 12:04 AM, Patrick McCarthy wrote: > > if it's still in 24-bit mode when emile tries to boot (thanks to PRAM > settings) then that could account for the failures. I don't know about emile, but Penguin should work in 24-bit mode. But you may be right. ISTR in 24-bit mode Penguin leaves more memory mappings for Linux than it would otherwise and maybe the kernel doesn't like that (it used to work okay...) > > > assuming I get the correct initrd and kernel for the job. > > These are the same pair I'm using, so they should work. Thanks for confirming this. Finn -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LNX.2.00.1311121427010.24638@nippy.intranet
