In the past few days I have attempted to get 2.6 kernels booting on my
diskless MVME167 boards.
I have tried several kernels, including:
linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
None of them appear to continue beyond the initialisation code in:
arch/m68k/kernel/head.S
They load norm
Hi,
> > m68k-atari-scsi.patch and m68k-atari-scsi2.patch were supposed to be
> > applied on
> > top of each other instead of exclusive. m68k-atari-scsi2.patch fails to
> > apply in
> > this situation so Christian must have backed out the first one. Now the
> > first
> > one is the one that u
Looking at the qemu docs it would appear they only emulate the M5208.
Which is a Coldfire V2 proc with no MMU. So it can run uclinux but
that's about it.
Only V4 parts have an MMU (547x/548x/5445x).
--Kurt
Xerxes Rånby wrote:
> In curious on the coldfire status to run the whole debian m68k.
>
In curious on the coldfire status to run the whole debian m68k.
I have been running a devmachine using aranym now for some time ant it
is unfortuannly horribly slow doing java gcc gcj debugging and
developement on. Im thinking of setting up a qemu devmachine but since
qemu-m68k only emulated t
On Mon, Nov 10, 2008 at 02:08:32PM +0100, Xerxes Rånby wrote:
> It turned out that the bug is located in libgcj. The gcj java in debian
> m68k should be concidered unstable.
> If someone wants to fix gcj on m68k there is a list of things to look
> into from the gcc libjava tests:
> http://gcc
On Sun, Nov 09, 2008 at 11:14:41PM +0100, Michael Schmitz wrote:
> Hi,
>
> > > Anyway, now that I have wised up to the fact that the etch install
> > > kernels are
> > > still at 2.6.18 (how backwards is that ...) I'm quite confident that all
> > > that's
> > > needed to fix the SCSI problems
It turned out that the bug is located in libgcj. The gcj java in debian
m68k should be concidered unstable.
If someone wants to fix gcj on m68k there is a list of things to look
into from the gcc libjava tests:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00733.html
The developement of the
made a new testcase for ant this morning and found the early ant exit
bug in the exec ant target as well.
testing ant exec target with this simple testcase:
== output from debian m68k (fail)
[EMAIL PROTECTED]:~/an
8 matches
Mail list logo
