On Thu, 22 Aug 2013, Scott Holder wrote:
>
> The problem I'm having now is getting the mouse and keyboard to work.
Issues with ADB devices in X11 on m68k Macs should be no different on
linux-ppc on Old World Macs (i.e. pre-USB). So you could try searching or
asking on a Debian/PPC mailing li
On 8/21/2013 6:34 AM, Finn Thain wrote:
X11 worked on macs back when I was testing etch-m68k. The pixel formats
are not the weird ones found on ataris. The only Xorg driver available is
fbdev.
Not having any trouble with graphics. It's working about the same as it
did before. I don't have muc
On Thu, Aug 22, 2013 at 3:37 PM, Joseph S. Myers
wrote:
> On Thu, 22 Aug 2013, Geert Uytterhoeven wrote:
>
>> > The vDSO support has been there in glibc ever since the NPTL port was
>> > first added. I've no idea why the kernel changes still haven't gone in.
>>
>> I didn't know that. Seems to be
On Thu, 22 Aug 2013, Geert Uytterhoeven wrote:
> > The vDSO support has been there in glibc ever since the NPTL port was
> > first added. I've no idea why the kernel changes still haven't gone in.
>
> I didn't know that. Seems to be recent work, cfr.
> https://github.com/Xilinx/glibc/blob/master
On Thu, Aug 22, 2013 at 1:44 PM, Joseph S. Myers
wrote:
> On Thu, 22 Aug 2013, Finn Thain wrote:
>> Losing a register also hurts performance. Someone suggested moving
>> get/set_thread_area to a VDSO (as well as the atomic ops). As I understand
>> it, this need not break the ABI and should be fast
On Thu, 22 Aug 2013, Finn Thain wrote:
> Losing a register also hurts performance. Someone suggested moving
> get/set_thread_area to a VDSO (as well as the atomic ops). As I understand
> it, this need not break the ABI and should be faster than the TLS system
> calls.
The vDSO support has been
On Thu, 22 Aug 2013, Thorsten Glaser wrote:
> Finn Thain dixit:
>
> we could do other sensible things (64-bit time_t, register passing of
> arguments, other legacy cleanup).
Probably adding syscalls could fix the 32-bit time_t without breaking
anything (given symbol versioning in libc).
Fixi
Finn Thain dixit:
>Losing a register also hurts performance. Someone suggested moving
Right, but at least m68k is not as register-starved as i386.
And when changing the ABI “anyway”, we could do other sensible
things (64-bit time_t, register passing of arguments, other
legacy cleanup).
>get/set_
On Wed, 21 Aug 2013, Thorsten Glaser wrote:
> >> Anything GTK+/GNOME (e.g. xchat) is not usable due to their use of
> >> TLS and/or atomics. I had thought KDE would suffer from the same, but
> >> they seem to be faster?
> >
> >We do have TLS now, don't we?
>
> Yes, that precisely is the proble
Geert Uytterhoeven dixit:
>However, Atari iplan2p4/8 (and Amiga afb4/8) support has been in
>upstream xserver-xfbdev for a few months.
Ok, so it should be in Debian in 10 years or so ☺ SCNR…
>> Anything GTK+/GNOME (e.g. xchat) is not usable due to
>> their use of TLS and/or atomics. I had though
On Wed, Aug 21, 2013 at 10:25 AM, Thorsten Glaser wrote:
>>> giving X a try for fun. icewm was almost usable under the old setup,
>>> and you could sort of browse with Firefox.
>
> At least for Atari, we do not have any working X server.
However, Atari iplan2p4/8 (and Amiga afb4/8) support has be
On Wed, 21 Aug 2013, Thorsten Glaser wrote:
> >> giving X a try for fun. icewm was almost usable under the old setup,
> >> and you could sort of browse with Firefox.
>
> At least for Atari, we do not have any working X server. IceWM works
> very well on a tightvncserver or vnc4server, even kde
Finn Thain dixit:
>On Wed, 21 Aug 2013, Scott Holder wrote:
>
>> ... it looks like the kernel I'm using (Still
>> http://www.freewrt.org/~tg/f/vmlinux-3.10-2-m68k.gz ) doesn't do ext4,
>> so back to ext2 it is.
>
>Mostly likely you just need the modules; try booting into the initrd and
Right, the
On Wed, 21 Aug 2013, Scott Holder wrote:
> ... it looks like the kernel I'm using (Still
> http://www.freewrt.org/~tg/f/vmlinux-3.10-2-m68k.gz ) doesn't do ext4,
> so back to ext2 it is.
Mostly likely you just need the modules; try booting into the initrd and
doing "modprobe ext4". If that wo
On 8/20/2013 2:59 AM, Thorsten Glaser wrote:
Maybe we can cheat.
http://zigo.mirbsd.org:8080/t/initrd.img-3.10-2-m68k
is the one Debian generated for me on the system running the buildd
and *might* be able to get you into console mode at least.
Well, I never did get the mirnitrd thing working
On Tue, 20 Aug 2013, Thorsten Glaser wrote:
> Finn Thain dixit:
>
> >Whereas http://www.freewrt.org/~tg/f/mirnitrd has /init so I'd try
> >"root=/dev/ram init=/init" with that initrd.
>
> I think no root= at all... this is basically an "initramfs" that just
> never pivots. It's not a "ramdisk
On 20/08/13 11:03, Scott Holder wrote:
I do not know whether an LC475 is even supported.
In general, the LC475 is considered unsupported only because it came
with a 68LC040 with very broken FPU originally. Swapping it for a full
68040 with a full FPU (which I did) should make it run fine. I ra
Finn Thain dixit:
>has CONFIG_SCSI_MAC_ESP=m but the kernel modules are not in the initrd at
>http://www.freewrt.org/~tg/f/mirnitrd
It’s just a minimal thing to get to userspace *at all*.
>Whereas http://www.freewrt.org/~tg/f/mirnitrd has /init so I'd try
>"root=/dev/ram init=/init" with that
Scott Holder dixit:
> I went ahead for broke and figured I didn't have anything to lose, so I went
> ahead and untarred the m68k-base.tgz on a spare partition and tried it. But,
> it
> appears the kernel is missing the Mac SCSI drivers (or they aren't working).
> It
Yes, the 3.10 kernel does no
On Mon, 19 Aug 2013, Scott Holder wrote:
> ... it appears the kernel is missing the Mac SCSI drivers (or they
> aren't working). It failed to detect any drives. I see the kernel config
> has the Mac SCSI drivers enabled, but maybe there's more to it. This
> machine has a NCR 53C96 SCSI chip
T
On 8/18/2013 9:14 PM, Thorsten Glaser wrote:
Can you get something, maybe some console output, with
http://www.freewrt.org/~tg/f/vmlinux-3.10-2-m68k.gz
(may need to decompress first), possibly with
http://www.freewrt.org/~tg/f/mirnitrd (do not decompress)
as initrd loaded (to get a bare shell)?
Geert Uytterhoeven dixit:
>> … for 3.10 we got rid of that baggage (except ARAnyM NatFeat, but
>> once the patch series related to that is in, we can switch those
>> (except nfcon of course) to modules, too).
>
>It's in 3.11-rc6, and will be in the next version of several stable branches.
One of
On Mon, Aug 19, 2013 at 2:05 PM, Thorsten Glaser wrote:
>>You can cut out a lot of the excess baggage in the debian kernel. I always
>
> … for 3.10 we got rid of that baggage (except ARAnyM NatFeat, but
> once the patch series related to that is in, we can switch those
> (except nfcon of course) t
Michael Tomkins dixit:
> I have install instructions for the base_cow.tgz on Quadra 605 and 650
> http://mich431.net/m68k.html I didn't get to X, just console. Just update the
Nice!
But you used base.cow which is really the “buildd” flavour,
that is, minbase without standard tools (such as netwo
Michael Tomkins dixit:
> I have install instructions for the base_cow.tgz on Quadra 605 and 650
> http://mich431.net/m68k.html I didn't get to X, just console. Just update the
Oh, and you REALLY REALLY REALLY must use the 'p' option to tar!
(Write x first, to make it clear what we’re doing.)
2.6
On 19/08/13 13:13, Finn Thain wrote:
On Sun, 18 Aug 2013, Scott Holder wrote:
So I finally dug the old LC 475 (aka Performa 475, aka Quadra 605) out
of the closet and got it booting its old Linux again. I've upgraded it
with a full 33mhz 68040 and overclocked it to 33mhz, so the 68LC040
issues
Finn Thain dixit:
>If you know how, it's definitely worth cross-compiling a custom kernel.
Yes, but…
>You can cut out a lot of the excess baggage in the debian kernel. I always
… for 3.10 we got rid of that baggage (except ARAnyM NatFeat, but
once the patch series related to that is in, we ca
On Sun, 18 Aug 2013, Scott Holder wrote:
> So I finally dug the old LC 475 (aka Performa 475, aka Quadra 605) out
> of the closet and got it booting its old Linux again. I've upgraded it
> with a full 33mhz 68040 and overclocked it to 33mhz, so the 68LC040
> issues should be gone. This is a ci
Scott Holder dixit:
> and white penguin with some hardware info and it hangs at that point. I see on
> the Debian wiki there's no feedback yet for Macintosh on this kernel, so I
We don’t have anyone else working on the Macintosh right now,
except Finn Thain upstream on the kernel and for Gentoo I
So I finally dug the old LC 475 (aka Performa 475, aka Quadra 605) out
of the closet and got it booting its old Linux again. I've upgraded it
with a full 33mhz 68040 and overclocked it to 33mhz, so the 68LC040
issues should be gone. This is a circa 2002 setup with a nice old 2.2
kernel. Even ha
30 matches
Mail list logo
