gcc-4.6.3, was Re: Debian on mac68k

gcc-4.6.3, was Re: Debian on mac68k

[Finn Thain]

Has anyone else tried the m68k cross-compiler from kernel.org and observed 
strange behaviour from the binaries it produces?

I used that cross-compiler (the i686 one) to build the kernel seen booting 
below. The resulting binary consistently crashes two different systems (LC 
III and LC 475), both during kernel startup. These two machines use 
different drivers and have different failure modes, but the failures are 
completely repeatable. The failures went away when I reverted to my usual 
(patched) gcc-4.4.6.

Perhaps gcc-4.6.3 is more strict than gcc-4.4, in such a way that would 
affect code generation, when presented with incorrect or undefined code? 
Are there any warnings that could be enabled to discover that code?

Is there some way to run the GCC test suite against this cross-compiler?

-- 

On Thu, 27 Oct 2016, Mac User wrote:

> 
> Please see attached for console log of LC III booting 
> "vmlinux-4.1.35-mac_scsi+". [...]
> 
> ABCFGHIJK
> Linux version 4.1.35-mac_scsi+ (fthain@nippy) (gcc version 4.6.3 (GCC) ) #1 Tue6
> Saving 402 bytes of bootinfo
> Detected Macintosh model: 27
> VIA1 at 50f00000 is a 6522 or clone
> VIA2 at 50f26000 is an RBV
> Apple Macintosh LC III
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 9135
> Kernel command line: root=/dev/sda6 console=ttyS0 nologo
> PID hash table entries: 256 (order: -2, 1024 bytes)
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Sorting __ex_table...
> Memory: 32572K/36864K available (2825K kernel code, 247K rwdata, 664K rodata, 1)
> Virtual kernel memory layout:
>     vector  : 0x003879e8 - 0x00387de8   (   1 KiB)
>     kmap    : 0xd0000000 - 0xf0000000   ( 512 MiB)
>     vmalloc : 0x02800000 - 0xd0000000   (3288 MiB)
>     lowmem  : 0x00000000 - 0x02400000   (  36 MiB)
>       .init : 0x003ab000 - 0x003c7000   ( 112 KiB)
>       .text : 0x00001000 - 0x002c3784   (2826 KiB)
>       .data : 0x002c6bf0 - 0x003aaa64   ( 912 KiB)
>       .bss  : 0x00387900 - 0x003aaa64   ( 141 KiB)
> SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
> NR_IRQS:72
> Killing onboard sonic... Done.
> WARNING: Persistent clock returned invalid value!
>          Check your CMOS/BIOS settings.
> Console: colour dummy device 80x25
> console [ttyS0] enabled
> Calibrating delay loop... 5.81 BogoMIPS (lpj=29056)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> devtmpfs: initialized
> clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911s
> NET: Registered protocol family 16
> NuBus: Scanning NuBus slots.
> Slot E:
>   Board resource:
>     type: [cat 0x1 type 0x0 hw 0x0 sw 0x0]
>     name: Farallon EtherMac LC-TP
>     board id: 0x8
>     vendor info:
>     ID: Farallon
>     revision: 001
>     part: PN 592a-TP
>   Function 0x80:
>     type: [cat 0x4 type 0x1 hw 0x10c sw 0x100]
>     name: Farallon EtherMac LC-TP
>     memory offset: 0x000d0000
>     MAC address: 00:00:c5:43:36:11
> SCSI subsystem initialized
> NET: Registered protocol family 2
> TCP established hash table entries: 1024 (order: 0, 4096 bytes)
> TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> TCP: Hash tables configured (established 1024 bind 1024)
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> futex hash table entries: 256 (order: -1, 3072 bytes)
> NFS: Registering the id_resolver key type
> Key type id_resolver registered
> Key type id_legacy registered
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> io scheduler noop registered
> io scheduler deadline registered (default)
> macfb: framebuffer at 0x60b00000, mapped to 0xd0000000, size 507k
> macfb: mode is 832x624x8, linelength=832
> Console: switching to colour frame buffer device 104x39
> fb0: Sonora frame buffer device
> pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
> scc.0: ttyS0 at MMIO 0x50f04002 (irq = 4, base_baud = 230400) is a Z85c30 ESCC t
> scc.1: ttyS1 at MMIO 0x50f04000 (irq = 4, base_baud = 230400) is a Z85c30 ESCC t
> brd: module loaded
> Warning: no ADB interface detected
> Uniform Multi-Platform E-IDE driver
> ide-gd driver 1.18
> scsi host0: Macintosh NCR5380 SCSI, irq 19, io_port 0x0, base 0x50f10000, can_q 
> scsi 0:0:0:0: Direct-Access     SEAGATE  ST318416N        0010 PQ: 0 ANSI: 3
> kernel BUG at block/deadline-iosched.c:332!
> *** TRAP #7 ***   FORMAT=0
> Current process id is 1
> BAD KERNEL TRAP: 00000000
> Modules linked in:
> PC: [<001882f2>] deadline_merge+0x0/0x8a
> SR: 2000  SP: 02031ba0  a2: 0202c000
> d0: 0000002b    d1: 00000059    d2: 00000000    d3: 00086c86
> d4: 020cb8a8    d5: 00000001    a0: 00373d8e    a1: 00373d92
> Process swapper (pid: 1, task=0202c000)
> Frame format=0 
> Stack from 02031bd4:
>         0032302f 00337762 0000014c 0017392a 0213a200 0211d2c4 0211d0f4 00178d2c
>         0213a200 0211d2e0 0037ba98 0018a144 0211d2c4 0213b014 020cba50 020cb800
>         020cb8a8 001f0dc2 0211d2e0 00000000 00000003 00000002 001f0ccc 020cb8d0
>         020cb8d8 001915c0 0002881e 020cba50 020cb8d8 001f0cc8 001f0ccc 020cba50
>         001cc0f6 020cb8d0 020efcc0 020cb8f4 0037fe28 0018a144 020cb8d8 00000000
>         020cb800 02031cd2 0213b300 001ee63c 020cb8f4 020ce120 ffffffff ffffffff
> Call Trace: [<0017392a>] elevator_exit+0x24/0x40
>  [<00178d2c>] blk_release_queue+0x44/0xce
>  [<0018a144>] kobject_release+0x3a/0x7c
>  [<001f0dc2>] scsi_device_dev_release_usercontext+0xf6/0x134
>  [<001f0ccc>] scsi_device_dev_release_usercontext+0x0/0x134
>  [<001915c0>] memset+0x0/0x8c
>  [<0002881e>] execute_in_process_context+0x52/0x5a
>  [<001f0cc8>] scsi_device_dev_release+0x16/0x1a
>  [<001f0ccc>] scsi_device_dev_release_usercontext+0x0/0x134
>  [<001cc0f6>] device_release+0x26/0xa6
>  [<0018a144>] kobject_release+0x3a/0x7c
>  [<001ee63c>] scsi_probe_and_probe_and_add_lun+0x0/0xb92
>  [<001e5608>] scsi_is_host_device+0x0/0x14
>  [<001cbf80>] put_device+0x0/0x14
>  [<001d32ee>] transx4c4
>  [<002c0920>] mutex_lock+0x0/0x22
>  [<001d119e>] platform_drv_probe+0x16/0x44
>  [<001cff9c>] driver_probe_device+0x17e/0x2
> 

Re: gcc-4.6.3, was Re: Debian on mac68k

[John Paul Adrian Glaubitz]

On 11/06/2016 03:03 AM, Finn Thain wrote:
> Has anyone else tried the m68k cross-compiler from kernel.org and observed 
> strange behaviour from the binaries it produces?

No, not really. Is there any particular reason why you are using these old
compilers? In Debian, we have up-to-date versions of the gcc cross-toolchain
for all target architectures we have in Debian, so I think there is little
incentive to use these old compilers.

Adrian

Re: gcc-4.6.3, was Re: Debian on mac68k

[Finn Thain]

On Sun, 6 Nov 2016, John Paul Adrian Glaubitz wrote:

> On 11/06/2016 03:03 AM, Finn Thain wrote:
> 
> > Has anyone else tried the m68k cross-compiler from kernel.org and 
> > observed strange behaviour from the binaries it produces?
> 
> No, not really. Is there any particular reason why you are using these 
> old compilers?

Mature, proven tools are important to upstream developers. Developers of 
distros needn't have the same expectations, since they take it upon 
themselves to put together reliable tools.

Please forgive my cross-posting.

> In Debian, we have up-to-date versions of the gcc cross-toolchain for 
> all target architectures we have in Debian,

Some years ago, for Debian users, I added links to those tools here: 
http://www.mac.linux-m68k.org/docs/cross-dev.php

But I suspect that this information is no longer current. It may give the 
impression that Debian m68k cross-compilers are unavailable. Do you have 
any better sources of information that I could link to?

> so I think there is little incentive to use these old compilers.

It is useful for upstream developers to have distro-neutral tools. 
Ideally, we could use the kernel.org compiler as a "reference compiler".
For automated builds, it seems to be that already. But no-one boots those 
binaries AFAIK.

-- 

> 
> Adrian
> 
> 

Re: gcc-4.6.3, was Re: Debian on mac68k

[John Paul Adrian Glaubitz]

On 11/06/2016 11:22 PM, Finn Thain wrote:
>> No, not really. Is there any particular reason why you are using these 
>> old compilers?
> 
> Mature, proven tools are important to upstream developers. Developers of 
> distros needn't have the same expectations, since they take it upon 
> themselves to put together reliable tools.

To be honest, my personal experience is different. The toolchain has often
bugs and lots of bugs are constantly being fixed upstream which is why
Debian is always following the respective gcc SVN branches instead of
using release versions.

Thus, gcc-6 in Debian isn't based on a release version but rather on the
current gcc-6 SVN branch with all recent fixes and updates.

>> In Debian, we have up-to-date versions of the gcc cross-toolchain for 
>> all target architectures we have in Debian,
> 
> Some years ago, for Debian users, I added links to those tools here: 
> http://www.mac.linux-m68k.org/docs/cross-dev.php
> 
> But I suspect that this information is no longer current. It may give the 
> impression that Debian m68k cross-compilers are unavailable. Do you have 
> any better sources of information that I could link to?

If you're on Debian Stretch or newer, you can just install everything
directly from the regular package archives, very convenient:

$ apt install gcc-m68k-linux-gnu g++-m68k-linux-gnu binutils-m68k-linux-gnu

>> so I think there is little incentive to use these old compilers.
> 
> It is useful for upstream developers to have distro-neutral tools. 
> Ideally, we could use the kernel.org compiler as a "reference compiler".
> For automated builds, it seems to be that already. But no-one boots those 
> binaries AFAIK.

The problem with the toolchain on kernel.org seems that it's not updated
very often if at all. I mean, gcc-4.6.3 is ancient, that was released
over four years ago [1]. gcc has seen lots of improvements and fixes,
particularly the SH has had so many bugs fixed that I'd highly discourage
people using any of the older versions.

Adrian

> [1] https://gcc.gnu.org/gcc-4.6/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: gcc-4.6.3, was Re: Debian on mac68k

[Finn Thain]

On Sun, 6 Nov 2016, John Paul Adrian Glaubitz wrote:

> On 11/06/2016 11:22 PM, Finn Thain wrote:
> 
> >> In Debian, we have up-to-date versions of the gcc cross-toolchain for 
> >> all target architectures we have in Debian,
> > 
> > Some years ago, for Debian users, I added links to those tools here: 
> > http://www.mac.linux-m68k.org/docs/cross-dev.php
> > 
> > But I suspect that this information is no longer current. It may give 
> > the impression that Debian m68k cross-compilers are unavailable. Do 
> > you have any better sources of information that I could link to?
> 
> If you're on Debian Stretch or newer, you can just install everything 
> directly from the regular package archives, very convenient:
> 
> $ apt install gcc-m68k-linux-gnu g++-m68k-linux-gnu binutils-m68k-linux-gnu

Nice. More widely useful might be a docker image or some other portable 
app container offering these packages. That's not a criticism of Debian, 
just a reflection of upstream development practices.

> 
> >> so I think there is little incentive to use these old compilers.
> > 
> > It is useful for upstream developers to have distro-neutral tools. 
> > Ideally, we could use the kernel.org compiler as a "reference 
> > compiler". For automated builds, it seems to be that already. But 
> > no-one boots those binaries AFAIK.
> 
> The problem with the toolchain on kernel.org seems that it's not updated 
> very often if at all.

Updating gcc in this case may or may not fix the crash. I fixed it by 
downgrading gcc, but even that result can't be taken to imply a compiler 
"bug", just a change in behaviour in gcc-4.6.3 which may even benefit 
someone somewhere.

Updating needlessly makes fault-finding more difficult, as witnessed by 
the effort required to isolate the "kernel BUG" regression earlier in this 
thread.

Dependable tools are more important to me than new tools. YMMV.

-- 

> I mean, gcc-4.6.3 is ancient, that was released over four years ago [1]. 
> gcc has seen lots of improvements and fixes, particularly the SH has had 
> so many bugs fixed that I'd highly discourage people using any of the 
> older versions.
> 
> Adrian
> 
> > [1] https://gcc.gnu.org/gcc-4.6/
> 
> 

Re: gcc-4.6.3, was Re: Debian on mac68k

[Angelo Dureghello]

Hi Finn,

On 06/11/2016 03:03, Finn Thain wrote:
>
> Has anyone else tried the m68k cross-compiler from kernel.org and observed
> strange behaviour from the binaries it produces?
>
> I used that cross-compiler (the i686 one) to build the kernel seen booting
> below. The resulting binary consistently crashes two different systems (LC
> III and LC 475), both during kernel startup. These two machines use
> different drivers and have different failure modes, but the failures are
> completely repeatable. The failures went away when I reverted to my usual
> (patched) gcc-4.4.6.
>
> Perhaps gcc-4.6.3 is more strict than gcc-4.4, in such a way that would
> affect code generation, when presented with incorrect or undefined code?
> Are there any warnings that could be enabled to discover that code?
>
> Is there some way to run the GCC test suite against this cross-compiler?
>

I also observed issues with some kernel.org toolchains, at least for coldfire
the 4.9.x was producing some wrong opcode, due to incorrect gcc libs used
over linking.

Maybe you can try some toolchains i prepared, they are the kernel.org with
some packaging adjustments done by me. Let me know in case if they work
for you.


http://sysam.it/toolchains.html

Regards,
Angelo Durgehello

Re: gcc-4.6.3, was Re: Debian on mac68k

[Finn Thain]

On Mon, 7 Nov 2016, Angelo Dureghello wrote:

> 
> I also observed issues with some kernel.org toolchains, at least for 
> coldfire the 4.9.x was producing some wrong opcode, due to incorrect gcc 
> libs used over linking.
> 
> Maybe you can try some toolchains i prepared, they are the kernel.org 
> with some packaging adjustments done by me. Let me know in case if they 
> work for you.
> 
> 
> http://sysam.it/toolchains.html

Thanks for that.

The only problem is that my fast Linux host is i686 and your compiler runs 
on x86_64. But it is a convenient way to get hold of a gcc-5.2 compiler to 
target m68k/coldfire.

I may have to build a recent cross-compiler to run on my i686 host if and 
when my gcc-4.4 build lets me down, or I get time to chase down bugs like 
the issue I have with the kernel.org compiler.

> 
> Regards,
> Angelo Durgehello
> 

Re: gcc-4.6.3, was Re: Debian on mac68k

[John Paul Adrian Glaubitz]

On 11/08/2016 10:01 AM, Finn Thain wrote:
> The only problem is that my fast Linux host is i686 and your compiler runs 
> on x86_64. But it is a convenient way to get hold of a gcc-5.2 compiler to 
> target m68k/coldfire.

Installing Debian testing and running

	apt install gcc-5-m68k-linux-gnu

is not an option?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: gcc-4.6.3, was Re: Debian on mac68k

[Finn Thain]

On Tue, 8 Nov 2016, John Paul Adrian Glaubitz wrote:

> On 11/08/2016 10:01 AM, Finn Thain wrote:
> > The only problem is that my fast Linux host is i686 and your compiler 
> > runs on x86_64. But it is a convenient way to get hold of a gcc-5.2 
> > compiler to target m68k/coldfire.
> 
> Installing Debian testing and running
> 
> 	apt install gcc-5-m68k-linux-gnu
> 
> is not an option?

As a way to get a compiler, it's more difficult than untarring the one 
from kernel.org, which was the effort I've been willing to invest so far.

I would consider installing the Debian Testing compiler in the form of a 
container, if one was available.

Or I could just update my cross-compiler build scripts again, but that 
solution doesn't get the upstream project much closer to the ideal 
solution, i.e. a convenient, reliable "reference" compiler.

That would require supported compiler and distro releases. Certainly 
Debian's gcc-5-m68k-linux-gnu or gcc-6-m68k-linux-gnu packages are good 
candidates for building a container, and time permitting, I would 
willingly test them and isolate and report any bugs I found.

-- 

> 
> Adrian
> 
> 

Re: gcc-4.6.3, was Re: Debian on mac68k

[Michael Schmitz]

Hi Finn,

>> so I think there is little incentive to use these old compilers.
> 
> It is useful for upstream developers to have distro-neutral tools. 
> Ideally, we could use the kernel.org compiler as a "reference compiler".
> For automated builds, it seems to be that already. But no-one boots those 
> binaries AFAIK.

Not for Mac, but Geert usually boots kernels using ARAnyM. Pretty basic,
for sure, but it's been good enough so have something to work from.

Having something like ARAnyM for Mac or Amiga would increase coverage,
but the varied and quirky Mac hardware out there makes that almost
pointless again.

Cheers,

	Michael

Re: gcc-4.6.3, was Re: Debian on mac68k

[Finn Thain]

On Wed, 9 Nov 2016, Michael Schmitz wrote:

> Not for Mac, but Geert usually boots kernels using ARAnyM. Pretty basic, 
> for sure, but it's been good enough so have something to work from.

I thought Geert still used gcc-4.1 (?)

> 
> Having something like ARAnyM for Mac or Amiga would increase coverage, 
> but the varied and quirky Mac hardware out there makes that almost 
> pointless again.

AFAIK, MAME/MESS is the only thing that would be accurate enough.

For the Mac models that I was interested in (LC III for Egret and LC 520 
for Cuda), I was able to patch some of the known bugs in MAME/MESS to get 
the ROM to boot to a flashing question mark, but I didn't try to boot any 
further. I will try loading EMILE.

-- 

> 
> Cheers,
> 
> 	Michael
> 
> 

Re: gcc-4.6.3, was Re: Debian on mac68k

[Geert Uytterhoeven]

On Wed, Nov 9, 2016 at 8:08 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Wed, 9 Nov 2016, Michael Schmitz wrote:
>> Not for Mac, but Geert usually boots kernels using ARAnyM. Pretty basic,
>> for sure, but it's been good enough so have something to work from.
>
> I thought Geert still used gcc-4.1 (?)

Indeed.

Gcc-4.1 has issues with some bitfields, e.g. to compile gfs2 I need
workarounds like:

-       struct gfs2_rbm rbm = { .rgd = rgd, .bii = 0, .offset = 0 };
+       // FIXME Avoid gcc 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21) ICE
+       // struct gfs2_rbm rbm = { .rgd = rgd, .bii = 0, .offset = 0 };
+       struct gfs2_rbm rbm = { .bii = 0, .offset = 0 };
+       rbm.rgd = rgd;

I also have a 4.9.0 from kernel.org, if needed.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

Re: gcc-4.6.3, was Re: Debian on mac68k

[John Paul Adrian Glaubitz]

On 11/09/2016 07:50 AM, Michael Schmitz wrote:
> Having something like ARAnyM for Mac or Amiga would increase coverage,
> but the varied and quirky Mac hardware out there makes that almost
> pointless again.

Current versions of WinUAE or fs-uae (available in Debian) should actually
be able to boot Linux now as they include MMU support now. Haven't tried
it yet though.

Adrian

Re: gcc-4.6.3, was Re: Debian on mac68k

[John Paul Adrian Glaubitz]

On 11/09/2016 12:06 AM, Finn Thain wrote:
> As a way to get a compiler, it's more difficult than untarring the one 
> from kernel.org, which was the effort I've been willing to invest so far.

If you're not on a Debian-based distribution, that is :).

> I would consider installing the Debian Testing compiler in the form of a 
> container, if one was available.

You can just install Debian into a systemd-nspawn chroot with the help
of debootstrap. No need to use Docker or anything else. I have used
this method to install and boot Fedora Rawhide on my Debian unstable
system. Pretty nifty and simple:

# debootstrap --no-check-gpg --arch=amd64 --variant=buildd unstable /srv/unstable/ ftp://ftp.debian.org/debian
# systemd-nspawn -bD /srv/unstable

That's all you need to boot a Debian container on any machine running systemd.

> Or I could just update my cross-compiler build scripts again, but that 
> solution doesn't get the upstream project much closer to the ideal 
> solution, i.e. a convenient, reliable "reference" compiler.

Does that really make such a difference? I have always used the gcc
versions shipped in Debian and never had any issues. Matthias Klose
also updates them very regularly, so I don't have to worry about
that.

> That would require supported compiler and distro releases. Certainly 
> Debian's gcc-5-m68k-linux-gnu or gcc-6-m68k-linux-gnu packages are good 
> candidates for building a container, and time permitting, I would 
> willingly test them and isolate and report any bugs I found.

We're thoroughly testing the toolchain in Debian on the buildds. By
actively building packages, we have found many bugs in gcc and binutils,
most of them were in the SH and SPARC targets though. I don't remember
running into any m68k-related toolchain issue.

Btw, there is one additional advantage using Debian for cross-platform
work: Multi-Arch. You can easily install build dependencies when
cross-building for other targets. I have used this extensively to
bootstrap ghc [1].

Adrian

> [1] https://wiki.debian.org/PortsDocs/BootstrappingGHC

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: gcc-4.6.3, was Re: Debian on mac68k

[Kaj-Michael Lang]

On Wed, 2016-11-09 at 19:50 +1300, Michael Schmitz wrote:
> Having something like ARAnyM for Mac or Amiga would increase coverage,
> but the varied and quirky Mac hardware out there makes that almost
> pointless again.

Has anyone tried booting Linux/sun3 on tme,
http://people.csail.mit.edu/fredette/tme/ ?

-- 
Kaj-Michael Lang <milang@tal.org>

Re: gcc-4.6.3, was Re: Debian on mac68k

[John Paul Adrian Glaubitz]

On 11/16/2016 01:43 PM, Kaj-Michael Lang wrote:
> On Wed, 2016-11-09 at 19:50 +1300, Michael Schmitz wrote:
>> Having something like ARAnyM for Mac or Amiga would increase coverage,
>> but the varied and quirky Mac hardware out there makes that almost
>> pointless again.
> 
> Has anyone tried booting Linux/sun3 on tme,
> http://people.csail.mit.edu/fredette/tme/ ?

No, not yet. But that would indeed be worth a shot.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: sun3 emulation, was Re: gcc-4.6.3

[Finn Thain]

On Wed, 16 Nov 2016, Kaj-Michael Lang wrote:

> On Wed, 2016-11-09 at 19:50 +1300, Michael Schmitz wrote:
> > Having something like ARAnyM for Mac or Amiga would increase coverage, 
> > but the varied and quirky Mac hardware out there makes that almost 
> > pointless again.
> 
> Has anyone tried booting Linux/sun3 on tme,
> http://people.csail.mit.edu/fredette/tme/ ?
> 

Good question (I've Cc'd Sam).

-- 

Re: Mac emulation, was Re: gcc-4.6.3

[Finn Thain]

On Wed, 9 Nov 2016, I wrote:

> On Wed, 9 Nov 2016, Michael Schmitz wrote:
> 
> > 
> > Having something like ARAnyM for Mac or Amiga would increase coverage, 
> > but the varied and quirky Mac hardware out there makes that almost 
> > pointless again.
> 
> AFAIK, MAME/MESS is the only thing that would be accurate enough.
> 
> For the Mac models that I was interested in (LC III for Egret and LC 520 
> for Cuda), I was able to patch some of the known bugs in MAME/MESS to 
> get the ROM to boot to a flashing question mark, but I didn't try to 
> boot any further. I will try loading EMILE.
> 

Unfortunately EMILE did not boot the emulated Mac IIx or Mac IIci in 
MAME/MESS. This resulted in a sad mac (0000000F 00000002):

$ pramutil -f ~/.sdlmess/nvram/maciix/rtc --boot-slot e --boot-slotrsrc 254
$ sdlmess -ramsize 8M maciix -nbe image -disk boot-2.6.18-mac_0.12.bin

$ pramutil -f ~/.sdlmess/nvram/maciici/rtc --boot-slot e --boot-slotrsrc 254
$ sdlmess -ramsize 16M maciici -nbe image -disk boot-2.6.18-mac_0.12.bin

Both of these emulated machines were able to boot to the desktop using a 
System 7 disk image.

I didn't test EMILE on the emulated LC III as I can't make that machine 
load any media at all, so I can't get past the flashing question mark.

-- 

Re: sun3 emulation, was Re: gcc-4.6.3

[Sam Creasey]

On Thu, Nov 17, 2016 at 09:26:45AM +1100, Finn Thain wrote:
> 
> On Wed, 16 Nov 2016, Kaj-Michael Lang wrote:
> 
> > On Wed, 2016-11-09 at 19:50 +1300, Michael Schmitz wrote:
> > > Having something like ARAnyM for Mac or Amiga would increase coverage, 
> > > but the varied and quirky Mac hardware out there makes that almost 
> > > pointless again.
> > 
> > Has anyone tried booting Linux/sun3 on tme,
> > http://people.csail.mit.edu/fredette/tme/ ?
> > 
> 
> Good question (I've Cc'd Sam).

I've thought about trying it a few times, never actually done it.
Though now that I've remembered it exists, I'm kinda tempted again.

IIRC physical 3/150 hardware worked at one point in time (at least for
the specific set of boards in my 3/150).

-- Sam