[git pull] m68k updates for 3.8

[git pull] m68k updates for 3.8

[Geert Uytterhoeven]

	Hi Linus,

The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
  Linus Torvalds (1):
        Linux 3.7

are available in the git repository at:

  ra.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
  git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus

Greg Ungerer (13):
      m68k: switch to using the asm-generic hw_irq.h
      m68k: switch to using the asm-generic spinlock.h
      m68k: switch to using the asm-generic shmparam.h
      m68k: switch to using the asm-generic auxvec.h
      m68k: switch to using the asm-generic msgbuf.h
      m68k: switch to using the asm-generic sembuf.h
      m68k: switch to using the asm-generic shmbuf.h
      m68k: switch to using the asm-generic socket.h
      m68k: switch to using the asm-generic sockios.h
      m68k: switch to using the asm-generic termbits.h
      m68k: switch to using the asm-generic termios.h
      m68k: merge MMU and non-MMU versions of mm/init.c
      m68k: move to a single instance of free_initmem()

Kees Cook (1):
      arch/m68k: remove CONFIG_EXPERIMENTAL

Thomas Bogendoerfer (2):
      m68k/sun3: Get interrupts working again
      m68k/sun3: Fix instruction faults

Summarized:
  - Two fixes for Sun-3
  - Several clean ups

There will be a trivial merge conflict in
arch/m68k/include/uapi/asm/socket.h, as we switched to the generic
version, while you already pulled the net tree that added SO_GET_FILTER
everywhere. Just remove the offending file to fix it.

Thanks for pulling!

 arch/m68k/Kconfig.bus                 |    4 +-
 arch/m68k/Kconfig.cpu                 |    3 +-
 arch/m68k/Kconfig.debug               |    2 +-
 arch/m68k/Kconfig.devices             |    6 +-
 arch/m68k/include/asm/Kbuild          |    4 +
 arch/m68k/include/asm/hw_irq.h        |    6 -
 arch/m68k/include/asm/shmparam.h      |    6 -
 arch/m68k/include/asm/spinlock.h      |    6 -
 arch/m68k/include/asm/termios.h       |   50 --------
 arch/m68k/include/uapi/asm/Kbuild     |   17 ++--
 arch/m68k/include/uapi/asm/auxvec.h   |    4 -
 arch/m68k/include/uapi/asm/msgbuf.h   |   31 -----
 arch/m68k/include/uapi/asm/sembuf.h   |   25 ----
 arch/m68k/include/uapi/asm/shmbuf.h   |   42 ------
 arch/m68k/include/uapi/asm/socket.h   |   72 -----------
 arch/m68k/include/uapi/asm/sockios.h  |   13 --
 arch/m68k/include/uapi/asm/termbits.h |  201 -----------------------------
 arch/m68k/include/uapi/asm/termios.h  |   44 -------
 arch/m68k/kernel/traps.c              |    2 +-
 arch/m68k/mm/init.c                   |  224 ++++++++++++++++++++++++++++++++-
 arch/m68k/mm/init_mm.c                |  176 --------------------------
 arch/m68k/mm/init_no.c                |  145 ---------------------
 arch/m68k/mm/mcfmmu.c                 |    4 -
 arch/m68k/mm/motorola.c               |   14 --
 arch/m68k/mm/sun3mmu.c                |    4 -
 arch/m68k/sun3/sun3ints.c             |   29 +----
 26 files changed, 247 insertions(+), 887 deletions(-)
 delete mode 100644 arch/m68k/include/asm/hw_irq.h
 delete mode 100644 arch/m68k/include/asm/shmparam.h
 delete mode 100644 arch/m68k/include/asm/spinlock.h
 delete mode 100644 arch/m68k/include/asm/termios.h
 delete mode 100644 arch/m68k/include/uapi/asm/auxvec.h
 delete mode 100644 arch/m68k/include/uapi/asm/msgbuf.h
 delete mode 100644 arch/m68k/include/uapi/asm/sembuf.h
 delete mode 100644 arch/m68k/include/uapi/asm/shmbuf.h
 delete mode 100644 arch/m68k/include/uapi/asm/socket.h
 delete mode 100644 arch/m68k/include/uapi/asm/sockios.h
 delete mode 100644 arch/m68k/include/uapi/asm/termbits.h
 delete mode 100644 arch/m68k/include/uapi/asm/termios.h
 delete mode 100644 arch/m68k/mm/init_mm.c
 delete mode 100644 arch/m68k/mm/init_no.c

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

[git pull] m68k updates for 3.8

[Geert Uytterhoeven]

	Hi Linus,

The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
  Linus Torvalds (1):
        Linux 3.7

are available in the git repository at:

  ra.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
  git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus

Greg Ungerer (13):
      m68k: switch to using the asm-generic hw_irq.h
      m68k: switch to using the asm-generic spinlock.h
      m68k: switch to using the asm-generic shmparam.h
      m68k: switch to using the asm-generic auxvec.h
      m68k: switch to using the asm-generic msgbuf.h
      m68k: switch to using the asm-generic sembuf.h
      m68k: switch to using the asm-generic shmbuf.h
      m68k: switch to using the asm-generic socket.h
      m68k: switch to using the asm-generic sockios.h
      m68k: switch to using the asm-generic termbits.h
      m68k: switch to using the asm-generic termios.h
      m68k: merge MMU and non-MMU versions of mm/init.c
      m68k: move to a single instance of free_initmem()

Kees Cook (1):
      arch/m68k: remove CONFIG_EXPERIMENTAL

Thomas Bogendoerfer (2):
      m68k/sun3: Get interrupts working again
      m68k/sun3: Fix instruction faults

Summarized:
  - Two fixes for Sun-3
  - Several clean ups

There will be a trivial merge conflict in
arch/m68k/include/uapi/asm/socket.h, as we switched to the generic
version, while you already pulled the net tree that added SO_GET_FILTER
everywhere. Just remove the offending file to fix it.

Thanks for pulling!

 arch/m68k/Kconfig.bus                 |    4 +-
 arch/m68k/Kconfig.cpu                 |    3 +-
 arch/m68k/Kconfig.debug               |    2 +-
 arch/m68k/Kconfig.devices             |    6 +-
 arch/m68k/include/asm/Kbuild          |    4 +
 arch/m68k/include/asm/hw_irq.h        |    6 -
 arch/m68k/include/asm/shmparam.h      |    6 -
 arch/m68k/include/asm/spinlock.h      |    6 -
 arch/m68k/include/asm/termios.h       |   50 --------
 arch/m68k/include/uapi/asm/Kbuild     |   17 ++--
 arch/m68k/include/uapi/asm/auxvec.h   |    4 -
 arch/m68k/include/uapi/asm/msgbuf.h   |   31 -----
 arch/m68k/include/uapi/asm/sembuf.h   |   25 ----
 arch/m68k/include/uapi/asm/shmbuf.h   |   42 ------
 arch/m68k/include/uapi/asm/socket.h   |   72 -----------
 arch/m68k/include/uapi/asm/sockios.h  |   13 --
 arch/m68k/include/uapi/asm/termbits.h |  201 -----------------------------
 arch/m68k/include/uapi/asm/termios.h  |   44 -------
 arch/m68k/kernel/traps.c              |    2 +-
 arch/m68k/mm/init.c                   |  224 ++++++++++++++++++++++++++++++++-
 arch/m68k/mm/init_mm.c                |  176 --------------------------
 arch/m68k/mm/init_no.c                |  145 ---------------------
 arch/m68k/mm/mcfmmu.c                 |    4 -
 arch/m68k/mm/motorola.c               |   14 --
 arch/m68k/mm/sun3mmu.c                |    4 -
 arch/m68k/sun3/sun3ints.c             |   29 +----
 26 files changed, 247 insertions(+), 887 deletions(-)
 delete mode 100644 arch/m68k/include/asm/hw_irq.h
 delete mode 100644 arch/m68k/include/asm/shmparam.h
 delete mode 100644 arch/m68k/include/asm/spinlock.h
 delete mode 100644 arch/m68k/include/asm/termios.h
 delete mode 100644 arch/m68k/include/uapi/asm/auxvec.h
 delete mode 100644 arch/m68k/include/uapi/asm/msgbuf.h
 delete mode 100644 arch/m68k/include/uapi/asm/sembuf.h
 delete mode 100644 arch/m68k/include/uapi/asm/shmbuf.h
 delete mode 100644 arch/m68k/include/uapi/asm/socket.h
 delete mode 100644 arch/m68k/include/uapi/asm/sockios.h
 delete mode 100644 arch/m68k/include/uapi/asm/termbits.h
 delete mode 100644 arch/m68k/include/uapi/asm/termios.h
 delete mode 100644 arch/m68k/mm/init_mm.c
 delete mode 100644 arch/m68k/mm/init_no.c

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: [git pull] m68k updates for 3.8

[Rob Landley]

On 12/13/2012 01:44:14 PM, Geert Uytterhoeven wrote:
> 	Hi Linus,
> 
> The following changes since commit  
> 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
>   Linus Torvalds (1):
>         Linux 3.7

Query: what's your test environment?

I've been trying to get m68k linux to boot in qemu on and off for years  
(http://landley.net/aboriginal/bin/system-image-m68k.tar.bz2), but qemu  
seems to be missing bits (mmu stuff mostly, some work's being done at  
git://gitorious.org/qemu-m68k/qemu-m68k especially in the q800 branch,  
but it throws a double MMU fault during kernel boot).

Somebody got one of my images to boot under aranym but they had to  
patch the kernel fairly extensively to add the emulated device support  
that emulator provided. It doesn't emulate real devices the way qemu  
does, but qemu doesn't fully emulate the processor (just coldfire in  
mainline)...

Rob

Re: [git pull] m68k updates for 3.8

[Rob Landley]

On 12/13/2012 01:44:14 PM, Geert Uytterhoeven wrote:
> 	Hi Linus,
> 
> The following changes since commit  
> 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
>   Linus Torvalds (1):
>         Linux 3.7

Query: what's your test environment?

I've been trying to get m68k linux to boot in qemu on and off for years  
(http://landley.net/aboriginal/bin/system-image-m68k.tar.bz2), but qemu  
seems to be missing bits (mmu stuff mostly, some work's being done at  
git://gitorious.org/qemu-m68k/qemu-m68k especially in the q800 branch,  
but it throws a double MMU fault during kernel boot).

Somebody got one of my images to boot under aranym but they had to  
patch the kernel fairly extensively to add the emulated device support  
that emulator provided. It doesn't emulate real devices the way qemu  
does, but qemu doesn't fully emulate the processor (just coldfire in  
mainline)...

Rob

Re: [git pull] m68k updates for 3.8

[Greg Ungerer]

Hi Rob,

On 12/14/2012 07:08 PM, Rob Landley wrote:
> On 12/13/2012 01:44:14 PM, Geert Uytterhoeven wrote:
>>     Hi Linus,
>>
>> The following changes since commit
>> 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
>>   Linus Torvalds (1):
>>         Linux 3.7
>
> Query: what's your test environment?
>
> I've been trying to get m68k linux to boot in qemu on and off for years
> (http://landley.net/aboriginal/bin/system-image-m68k.tar.bz2), but qemu
> seems to be missing bits (mmu stuff mostly, some work's being done at
> git://gitorious.org/qemu-m68k/qemu-m68k especially in the q800 branch,
> but it throws a double MMU fault during kernel boot).
>
> Somebody got one of my images to boot under aranym but they had to patch
> the kernel fairly extensively to add the emulated device support that
> emulator provided. It doesn't emulate real devices the way qemu does,
> but qemu doesn't fully emulate the processor (just coldfire in mainline)...

I use aranym for testing m68k. Though I don't really pound to heavily
on the devices. I really only cross-compile small systems for testing
on it.

Regards
Greg

Re: [git pull] m68k updates for 3.8

[Greg Ungerer]

Hi Rob,

On 12/14/2012 07:08 PM, Rob Landley wrote:
> On 12/13/2012 01:44:14 PM, Geert Uytterhoeven wrote:
>>     Hi Linus,
>>
>> The following changes since commit
>> 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
>>   Linus Torvalds (1):
>>         Linux 3.7
>
> Query: what's your test environment?
>
> I've been trying to get m68k linux to boot in qemu on and off for years
> (http://landley.net/aboriginal/bin/system-image-m68k.tar.bz2), but qemu
> seems to be missing bits (mmu stuff mostly, some work's being done at
> git://gitorious.org/qemu-m68k/qemu-m68k especially in the q800 branch,
> but it throws a double MMU fault during kernel boot).
>
> Somebody got one of my images to boot under aranym but they had to patch
> the kernel fairly extensively to add the emulated device support that
> emulator provided. It doesn't emulate real devices the way qemu does,
> but qemu doesn't fully emulate the processor (just coldfire in mainline)...

I use aranym for testing m68k. Though I don't really pound to heavily
on the devices. I really only cross-compile small systems for testing
on it.

Regards
Greg

Re: [git pull] m68k updates for 3.8

[Rob Landley]

On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
> Hi Rob,
...
>> Somebody got one of my images to boot under aranym but they had to  
>> patch
>> the kernel fairly extensively to add the emulated device support that
>> emulator provided. It doesn't emulate real devices the way qemu does,
>> but qemu doesn't fully emulate the processor (just coldfire in  
>> mainline)...
> 
> I use aranym for testing m68k. Though I don't really pound to heavily
> on the devices. I really only cross-compile small systems for testing
> on it.

What kernel config do you use for aranym? I don't see an an aranym  
entry in
arch/m68k/configs, and I stopped using it precisely because it required  
several large patches to add emulated device support for everything  
from serial console to block devices. (There was a kernel upgrade, it  
broke, I cut a release without it. Pretty much the same reason I  
stopped using squashfs for a year or so until it finally got merged.)

I can poke Laurent Vivier about possibly getting the qemu-system-m68k  
and the q800 board emulation to work better if there's interest from  
anyone other than me. (I just checked and it dies at the same place it  
did last year: setting up the page tables. The MMU emulation ain't  
there, and I haven't got documentation for it.)

My interest is that my aboriginal linux setup builds the same system  
for a dozen different targets and then natively builds packages inside  
the emulator. This allows me to regression test if their behavior  
diverges, even from a cron job if I want to. From my viewpoint, the  
more targets the merrier.

(I don't care hugely about which board emulation I'm using, the point  
is to run a native root filesystem including a native toolchain and  
build stuff locally on the board. This requires at least 256 megs of  
memory in the emulated board for gcc 4.2 (more for newer versions), and  
ideally I want a virtual network card so I can hook up distcc to the  
cross compiler and move the heavy lifting of compilation outside the  
emulator without reintroducing the whole "keep track of two  
simultaneous build contexts" complexity of cross compiling. So it's not  
"q800 vs aranym", it's "I already got qemu to emulate all the other  
targets I'm testing and it doesn't require an extensively patched  
kernel" vs "other emulator requiring patched kernel"...)

Thanks,

Rob

Re: [git pull] m68k updates for 3.8

[Rob Landley]

On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
> Hi Rob,
...
>> Somebody got one of my images to boot under aranym but they had to  
>> patch
>> the kernel fairly extensively to add the emulated device support that
>> emulator provided. It doesn't emulate real devices the way qemu does,
>> but qemu doesn't fully emulate the processor (just coldfire in  
>> mainline)...
> 
> I use aranym for testing m68k. Though I don't really pound to heavily
> on the devices. I really only cross-compile small systems for testing
> on it.

What kernel config do you use for aranym? I don't see an an aranym  
entry in
arch/m68k/configs, and I stopped using it precisely because it required  
several large patches to add emulated device support for everything  
from serial console to block devices. (There was a kernel upgrade, it  
broke, I cut a release without it. Pretty much the same reason I  
stopped using squashfs for a year or so until it finally got merged.)

I can poke Laurent Vivier about possibly getting the qemu-system-m68k  
and the q800 board emulation to work better if there's interest from  
anyone other than me. (I just checked and it dies at the same place it  
did last year: setting up the page tables. The MMU emulation ain't  
there, and I haven't got documentation for it.)

My interest is that my aboriginal linux setup builds the same system  
for a dozen different targets and then natively builds packages inside  
the emulator. This allows me to regression test if their behavior  
diverges, even from a cron job if I want to. From my viewpoint, the  
more targets the merrier.

(I don't care hugely about which board emulation I'm using, the point  
is to run a native root filesystem including a native toolchain and  
build stuff locally on the board. This requires at least 256 megs of  
memory in the emulated board for gcc 4.2 (more for newer versions), and  
ideally I want a virtual network card so I can hook up distcc to the  
cross compiler and move the heavy lifting of compilation outside the  
emulator without reintroducing the whole "keep track of two  
simultaneous build contexts" complexity of cross compiling. So it's not  
"q800 vs aranym", it's "I already got qemu to emulate all the other  
targets I'm testing and it doesn't require an extensively patched  
kernel" vs "other emulator requiring patched kernel"...)

Thanks,

Rob

Re: [git pull] m68k updates for 3.8

[Al Viro]

On Fri, Dec 14, 2012 at 03:48:20PM -0600, Rob Landley wrote:
> On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
> >Hi Rob,
> ...
> >>Somebody got one of my images to boot under aranym but they had
> >>to patch
> >>the kernel fairly extensively to add the emulated device support that
> >>emulator provided. It doesn't emulate real devices the way qemu does,
> >>but qemu doesn't fully emulate the processor (just coldfire in
> >>mainline)...
> >
> >I use aranym for testing m68k. Though I don't really pound to heavily
> >on the devices. I really only cross-compile small systems for testing
> >on it.
> 
> What kernel config do you use for aranym? I don't see an an aranym
> entry in
> arch/m68k/configs, and I stopped using it precisely because it
> required several large patches to add emulated device support for
> everything from serial console to block devices. (There was a kernel
> upgrade, it broke, I cut a release without it. Pretty much the same
> reason I stopped using squashfs for a year or so until it finally
> got merged.)

config NATFEAT
        bool "ARAnyM emulator support"
        depends on ATARI
        help
          This option enables support for ARAnyM native features, such as
          access to a disk image as /dev/hda.

followed by rather obvious options that depend on it (block/console/NIC).

Re: [git pull] m68k updates for 3.8

[Al Viro]

On Fri, Dec 14, 2012 at 03:48:20PM -0600, Rob Landley wrote:
> On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
> >Hi Rob,
> ...
> >>Somebody got one of my images to boot under aranym but they had
> >>to patch
> >>the kernel fairly extensively to add the emulated device support that
> >>emulator provided. It doesn't emulate real devices the way qemu does,
> >>but qemu doesn't fully emulate the processor (just coldfire in
> >>mainline)...
> >
> >I use aranym for testing m68k. Though I don't really pound to heavily
> >on the devices. I really only cross-compile small systems for testing
> >on it.
> 
> What kernel config do you use for aranym? I don't see an an aranym
> entry in
> arch/m68k/configs, and I stopped using it precisely because it
> required several large patches to add emulated device support for
> everything from serial console to block devices. (There was a kernel
> upgrade, it broke, I cut a release without it. Pretty much the same
> reason I stopped using squashfs for a year or so until it finally
> got merged.)

config NATFEAT
        bool "ARAnyM emulator support"
        depends on ATARI
        help
          This option enables support for ARAnyM native features, such as
          access to a disk image as /dev/hda.

followed by rather obvious options that depend on it (block/console/NIC).

Re: [git pull] m68k updates for 3.8

[Greg Ungerer]

On 12/15/2012 07:48 AM, Rob Landley wrote:
> On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
>> Hi Rob,
> ...
>>> Somebody got one of my images to boot under aranym but they had to patch
>>> the kernel fairly extensively to add the emulated device support that
>>> emulator provided. It doesn't emulate real devices the way qemu does,
>>> but qemu doesn't fully emulate the processor (just coldfire in
>>> mainline)...
>>
>> I use aranym for testing m68k. Though I don't really pound to heavily
>> on the devices. I really only cross-compile small systems for testing
>> on it.
>
> What kernel config do you use for aranym? I don't see an an aranym entry in
> arch/m68k/configs, and I stopped using it precisely because it required
> several large patches to add emulated device support for everything from
> serial console to block devices. (There was a kernel upgrade, it broke,
> I cut a release without it. Pretty much the same reason I stopped using
> squashfs for a year or so until it finally got merged.)

arch/m68k/configs/atari_defconfig

AranyM is an Atari emulator. As far as I know all the special device
support has been merged into mainline now.


> I can poke Laurent Vivier about possibly getting the qemu-system-m68k
> and the q800 board emulation to work better if there's interest from
> anyone other than me. (I just checked and it dies at the same place it
> did last year: setting up the page tables. The MMU emulation ain't
> there, and I haven't got documentation for it.)
>
> My interest is that my aboriginal linux setup builds the same system for
> a dozen different targets and then natively builds packages inside the
> emulator. This allows me to regression test if their behavior diverges,
> even from a cron job if I want to. From my viewpoint, the more targets
> the merrier.
>
> (I don't care hugely about which board emulation I'm using, the point is
> to run a native root filesystem including a native toolchain and build
> stuff locally on the board. This requires at least 256 megs of memory in
> the emulated board for gcc 4.2 (more for newer versions), and ideally I
> want a virtual network card so I can hook up distcc to the cross
> compiler and move the heavy lifting of compilation outside the emulator
> without reintroducing the whole "keep track of two simultaneous build
> contexts" complexity of cross compiling. So it's not "q800 vs aranym",
> it's "I already got qemu to emulate all the other targets I'm testing
> and it doesn't require an extensively patched kernel" vs "other emulator
> requiring patched kernel"...)

For whatever it is worth I don't run patched kernels under AranyM.
But I don't really care to much about the odd ball devices either
for most of the testing I use it for.

Regards
Greg

Re: [git pull] m68k updates for 3.8

[Greg Ungerer]

On 12/15/2012 07:48 AM, Rob Landley wrote:
> On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
>> Hi Rob,
> ...
>>> Somebody got one of my images to boot under aranym but they had to patch
>>> the kernel fairly extensively to add the emulated device support that
>>> emulator provided. It doesn't emulate real devices the way qemu does,
>>> but qemu doesn't fully emulate the processor (just coldfire in
>>> mainline)...
>>
>> I use aranym for testing m68k. Though I don't really pound to heavily
>> on the devices. I really only cross-compile small systems for testing
>> on it.
>
> What kernel config do you use for aranym? I don't see an an aranym entry in
> arch/m68k/configs, and I stopped using it precisely because it required
> several large patches to add emulated device support for everything from
> serial console to block devices. (There was a kernel upgrade, it broke,
> I cut a release without it. Pretty much the same reason I stopped using
> squashfs for a year or so until it finally got merged.)

arch/m68k/configs/atari_defconfig

AranyM is an Atari emulator. As far as I know all the special device
support has been merged into mainline now.


> I can poke Laurent Vivier about possibly getting the qemu-system-m68k
> and the q800 board emulation to work better if there's interest from
> anyone other than me. (I just checked and it dies at the same place it
> did last year: setting up the page tables. The MMU emulation ain't
> there, and I haven't got documentation for it.)
>
> My interest is that my aboriginal linux setup builds the same system for
> a dozen different targets and then natively builds packages inside the
> emulator. This allows me to regression test if their behavior diverges,
> even from a cron job if I want to. From my viewpoint, the more targets
> the merrier.
>
> (I don't care hugely about which board emulation I'm using, the point is
> to run a native root filesystem including a native toolchain and build
> stuff locally on the board. This requires at least 256 megs of memory in
> the emulated board for gcc 4.2 (more for newer versions), and ideally I
> want a virtual network card so I can hook up distcc to the cross
> compiler and move the heavy lifting of compilation outside the emulator
> without reintroducing the whole "keep track of two simultaneous build
> contexts" complexity of cross compiling. So it's not "q800 vs aranym",
> it's "I already got qemu to emulate all the other targets I'm testing
> and it doesn't require an extensively patched kernel" vs "other emulator
> requiring patched kernel"...)

For whatever it is worth I don't run patched kernels under AranyM.
But I don't really care to much about the odd ball devices either
for most of the testing I use it for.

Regards
Greg

Re: [git pull] m68k updates for 3.8

[Geert Uytterhoeven]

On Sat, Dec 15, 2012 at 1:09 PM, Greg Ungerer
<gregungerer@westnet.com.au> wrote:
> On 12/15/2012 07:48 AM, Rob Landley wrote:
>> On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
>>> Hi Rob,
>>>> Somebody got one of my images to boot under aranym but they had to patch
>>>> the kernel fairly extensively to add the emulated device support that
>>>> emulator provided. It doesn't emulate real devices the way qemu does,
>>>> but qemu doesn't fully emulate the processor (just coldfire in
>>>> mainline)...
>>>
>>> I use aranym for testing m68k. Though I don't really pound to heavily
>>> on the devices. I really only cross-compile small systems for testing
>>> on it.
>>
>> What kernel config do you use for aranym? I don't see an an aranym entry
>> in
>> arch/m68k/configs, and I stopped using it precisely because it required
>> several large patches to add emulated device support for everything from
>> serial console to block devices. (There was a kernel upgrade, it broke,
>> I cut a release without it. Pretty much the same reason I stopped using
>> squashfs for a year or so until it finally got merged.)
>
> arch/m68k/configs/atari_defconfig

The normal defconfig (aka multi_defconfig) should also work.

> AranyM is an Atari emulator. As far as I know all the special device
> support has been merged into mainline now.

Indeed, as of v2.6.39.

Even without that support, an Atari kernel should work (albeit slower), except
for networking.

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: [git pull] m68k updates for 3.8

[Geert Uytterhoeven]

On Sat, Dec 15, 2012 at 1:09 PM, Greg Ungerer
<gregungerer@westnet.com.au> wrote:
> On 12/15/2012 07:48 AM, Rob Landley wrote:
>> On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
>>> Hi Rob,
>>>> Somebody got one of my images to boot under aranym but they had to patch
>>>> the kernel fairly extensively to add the emulated device support that
>>>> emulator provided. It doesn't emulate real devices the way qemu does,
>>>> but qemu doesn't fully emulate the processor (just coldfire in
>>>> mainline)...
>>>
>>> I use aranym for testing m68k. Though I don't really pound to heavily
>>> on the devices. I really only cross-compile small systems for testing
>>> on it.
>>
>> What kernel config do you use for aranym? I don't see an an aranym entry
>> in
>> arch/m68k/configs, and I stopped using it precisely because it required
>> several large patches to add emulated device support for everything from
>> serial console to block devices. (There was a kernel upgrade, it broke,
>> I cut a release without it. Pretty much the same reason I stopped using
>> squashfs for a year or so until it finally got merged.)
>
> arch/m68k/configs/atari_defconfig

The normal defconfig (aka multi_defconfig) should also work.

> AranyM is an Atari emulator. As far as I know all the special device
> support has been merged into mainline now.

Indeed, as of v2.6.39.

Even without that support, an Atari kernel should work (albeit slower), except
for networking.

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