[uClinux-dev] uClinux on Amiga 500

[Geert Uytterhoeven]

Hi,

Recently I started picking up my old uClinux on Amiga project
(http://home.tvd.be/cr26864/Linux/68000/) again, and started integrating
nommu-support into Linux/m68k 2.6.0-test3.

So far the kernel starts on an emulated Amiga 500 (using UAE), but it crashes
quite early in reserve_bootmem().

A preliminary kernel patch (relative to Linux/m68k CVS when it was at
2.4.0-test3) is available from
http://home.tvd.be/cr26864/Download/uc-20030821.diff.bz2 (this includes many
outstanding patches from uclinux.org). Note that many things are protected by
!CONFIG_MMU, while they are actually pre-020-specific. This needs some clean
ups.

After building the kernel, you have to run the `reloc2' script to convert your
`vmlinux' into a `ucimage' suitable for download (amiboot-uC needs VMA to be
zero-based, while LMA is 0x200000-based).

System requirements:
- An (emulated) Amiga 500 or 2000
- AmigaOS 2.04 or later (required by amiboot-uC)
- 2 MB FastRam at 0x200000
- amiboot-uC (http://home.tvd.be/cr26864/Download/index.html)
- cross-gcc 3.2 (2.95 does unaligned accesses in memcpy)
- hacking skills

Enjoy!

And as usual, all help is welcome ;-)

Gr{oetje,eeting}s,

Geert

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

[Bernardo Innocenti]

Post by Geert Uytterhoeven
Recently I started picking up my old uClinux on Amiga project
(http://home.tvd.be/cr26864/Linux/68000/) again, and started integrating
nommu-support into Linux/m68k 2.6.0-test3.

That's a very nice hack, indeed. Please, please, try to merge at least
some of this work with Greg!

Post by Geert Uytterhoeven
So far the kernel starts on an emulated Amiga 500 (using UAE), but it
crashes quite early in reserve_bootmem().

reserve_bootmem() seems to be the favourite place for the kernel to
hang. I've been stuck there when I had a bug in GCC and a co-worker
of mine is also struggling there with his ARM kernel ;-)

Post by Geert Uytterhoeven
A preliminary kernel patch (relative to Linux/m68k CVS when it was at
2.4.0-test3) is available from
http://home.tvd.be/cr26864/Download/uc-20030821.diff.bz2 (this includes
many outstanding patches from uclinux.org). Note that many things are
protected by !CONFIG_MMU, while they are actually pre-020-specific. This
needs some clean ups.

I wish the m68k and m68knommu directories could be merged back together
some day. Would be quite some work and many things would break... but in
the end I feel it's the way to go.

Post by Geert Uytterhoeven
After building the kernel, you have to run the `reloc2' script to convert
your `vmlinux' into a `ucimage' suitable for download (amiboot-uC needs VMA
to be zero-based, while LMA is 0x200000-based).

I wonder if this could be combined with CONFIG_UML to get a kernel that runs
as an Amiga process ;-)

[Geert Uytterhoeven]

Post by Bernardo Innocenti

Post by Geert Uytterhoeven
Recently I started picking up my old uClinux on Amiga project
(http://home.tvd.be/cr26864/Linux/68000/) again, and started integrating
nommu-support into Linux/m68k 2.6.0-test3.

That's a very nice hack, indeed. Please, please, try to merge at least
some of this work with Greg!

Note that I modified arch/m68k and include/asm-m68k, not m68knommu, so I could
use the same Amiga core support as for MMU-equipped Amigas.

Post by Bernardo Innocenti
I wish the m68k and m68knommu directories could be merged back together
some day. Would be quite some work and many things would break... but in
the end I feel it's the way to go.

Yes, that would be nice, but it requires a lot more work...

Gr{oetje,eeting}s,

Geert

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

[Christoph Hellwig]

Post by Geert Uytterhoeven

Post by Bernardo Innocenti
I wish the m68k and m68knommu directories could be merged back together
some day. Would be quite some work and many things would break... but in
the end I feel it's the way to go.

Yes, that would be nice, but it requires a lot more work...

Well, if the m68k and m68knommu maintainers both want this to happen
lets start to get it going piece by piece.

First step would imho be to share the headers, e.g. start unfying them
until every asm-m68knommu header that's present in asm-m68k #includes
that version. After that the board support files from arch/m68knommu
can move over to m68k, the makefile can pick them up using arch/m68k/
instead of arch/$(ARCH) like it was done with mips. after that the
hard part will be to unify the kernel/ and lib/ subdirs.

I'll could try to fire up the crosstoolchain for my snapgear box and
take a look :)

[Greg Ungerer]

Post by Christoph Hellwig

Post by Geert Uytterhoeven

Post by Bernardo Innocenti
I wish the m68k and m68knommu directories could be merged back together
some day. Would be quite some work and many things would break... but in
the end I feel it's the way to go.

Yes, that would be nice, but it requires a lot more work...

Well, if the m68k and m68knommu maintainers both want this to happen
lets start to get it going piece by piece.

I am in favor, but there certainly is some work to do.

Post by Christoph Hellwig
First step would imho be to share the headers, e.g. start unfying them
until every asm-m68knommu header that's present in asm-m68k #includes
that version. After that the board support files from arch/m68knommu
can move over to m68k, the makefile can pick them up using arch/m68k/
instead of arch/$(ARCH) like it was done with mips. after that the
hard part will be to unify the kernel/ and lib/ subdirs.

The headers will be relatively easy, many of the current m68knommu
headers just include the same m68k header. Of the rest a large
number are new (for different hardware peices) and the remainder
are different for non-mmu and <68020/coldfire CPU's.

I think the arch/m68k* kernel, mm and machine support is where
the real work will be. This would be a good excuse to do something
better than the current way m68knommu/platform is :-)

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com
Snapgear Pty Ltd PHONE: [phone]
825 Stanley St, FAX: [phone]
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com

[Bernardo Innocenti]

Post by Christoph Hellwig

Post by Geert Uytterhoeven

Post by Bernardo Innocenti
I wish the m68k and m68knommu directories could be merged back together
some day. Would be quite some work and many things would break... but in
the end I feel it's the way to go.

Yes, that would be nice, but it requires a lot more work...

Well, if the m68k and m68knommu maintainers both want this to happen
lets start to get it going piece by piece.

Greg, Geert, what do you think? I would volunteer to help with this
transition. Of course I can only take simple tasks since I'm not
familiar with all subarchitectures and all kernel subsystems.

But who is going to collect patches for Linus? I expect most changes
would have to touch _both_ m68k and m68knommu at the same time.

Post by Christoph Hellwig
First step would imho be to share the headers, e.g. start unfying them
until every asm-m68knommu header that's present in asm-m68k #includes
that version.

I 100% agree here.

Post by Christoph Hellwig
After that the board support files from arch/m68knommu
can move over to m68k, the makefile can pick them up using arch/m68k/
instead of arch/$(ARCH) like it was done with mips.

Could we take advantage of the new sub-architecture infrastructure
introduced in 2.5? I don't know much about it.

Post by Christoph Hellwig
after that the
hard part will be to unify the kernel/ and lib/ subdirs.
I'll could try to fire up the crosstoolchain for my snapgear box and
take a look :)

Nothing prevents us from leaving some source files disjunct and use
Makefile conditionals to select the correct one.

[Greg Ungerer]

Hi Geert,

Post by Geert Uytterhoeven
Recently I started picking up my old uClinux on Amiga project
(http://home.tvd.be/cr26864/Linux/68000/) again, and started integrating
nommu-support into Linux/m68k 2.6.0-test3.
So far the kernel starts on an emulated Amiga 500 (using UAE), but it crashes
quite early in reserve_bootmem().

This is very cool :-)

Regards
Greg

Post by Geert Uytterhoeven
A preliminary kernel patch (relative to Linux/m68k CVS when it was at
2.4.0-test3) is available from
http://home.tvd.be/cr26864/Download/uc-20030821.diff.bz2 (this includes many
outstanding patches from uclinux.org). Note that many things are protected by
!CONFIG_MMU, while they are actually pre-020-specific. This needs some clean
ups.
After building the kernel, you have to run the `reloc2' script to convert your
`vmlinux' into a `ucimage' suitable for download (amiboot-uC needs VMA to be
zero-based, while LMA is 0x200000-based).
- An (emulated) Amiga 500 or 2000
- AmigaOS 2.04 or later (required by amiboot-uC)
- 2 MB FastRam at 0x200000
- amiboot-uC (http://home.tvd.be/cr26864/Download/index.html)
- cross-gcc 3.2 (2.95 does unaligned accesses in memcpy)
- hacking skills
Enjoy!
And as usual, all help is welcome ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org

[Geert Uytterhoeven]

Post by Bernardo Innocenti

Post by Christoph Hellwig

Post by Geert Uytterhoeven

Post by Bernardo Innocenti
I wish the m68k and m68knommu directories could be merged back together
some day. Would be quite some work and many things would break... but in
the end I feel it's the way to go.

Yes, that would be nice, but it requires a lot more work...

Well, if the m68k and m68knommu maintainers both want this to happen
lets start to get it going piece by piece.

Greg, Geert, what do you think? I would volunteer to help with this
transition. Of course I can only take simple tasks since I'm not
familiar with all subarchitectures and all kernel subsystems.
But who is going to collect patches for Linus? I expect most changes
would have to touch _both_ m68k and m68knommu at the same time.

Submitting patches to Linus is a minor issue. First the includes and core code
have to be put in sync. E.g. support for < 68020 CPUs has to be added to m68k
first.

Yes, it will be a lot of work, and the workforce is limited (as usual).

Post by Bernardo Innocenti

Post by Christoph Hellwig
After that the board support files from arch/m68knommu
can move over to m68k, the makefile can pick them up using arch/m68k/
instead of arch/$(ARCH) like it was done with mips.

Could we take advantage of the new sub-architecture infrastructure
introduced in 2.5? I don't know much about it.

You mean the split on i386 for PC, VISWS, and Voyager? That won't help since
it's i386-only. Besides, m68k has had a much better sub-architecture
infrastructure since ages.

Gr{oetje,eeting}s,

Geert

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

[Greg Ungerer]

Hi All,

Post by Geert Uytterhoeven

Post by Bernardo Innocenti

Post by Christoph Hellwig

Post by Geert Uytterhoeven

Post by Bernardo Innocenti
I wish the m68k and m68knommu directories could be merged back together
some day. Would be quite some work and many things would break... but in
the end I feel it's the way to go.

Yes, that would be nice, but it requires a lot more work...

Well, if the m68k and m68knommu maintainers both want this to happen
lets start to get it going piece by piece.

Greg, Geert, what do you think? I would volunteer to help with this
transition. Of course I can only take simple tasks since I'm not
familiar with all subarchitectures and all kernel subsystems.
But who is going to collect patches for Linus? I expect most changes
would have to touch _both_ m68k and m68knommu at the same time.

Submitting patches to Linus is a minor issue. First the includes and core code
have to be put in sync. E.g. support for < 68020 CPUs has to be added to m68k
first.

The ColdFire support will mess things up a bit, the < 68020 is
probably not that bad. I don't think the includes will cause
many problems though, they will be relatively easy.

Post by Geert Uytterhoeven
Yes, it will be a lot of work, and the workforce is limited (as usual).

Yes indeed :-)

Right now I want to focus on getting m68knommu and MMUless in general
complete and stable in 2.6. This is a job for 2.7 :-)

Post by Geert Uytterhoeven

Post by Bernardo Innocenti

Post by Christoph Hellwig
After that the board support files from arch/m68knommu
can move over to m68k, the makefile can pick them up using arch/m68k/
instead of arch/$(ARCH) like it was done with mips.

Could we take advantage of the new sub-architecture infrastructure
introduced in 2.5? I don't know much about it.

You mean the split on i386 for PC, VISWS, and Voyager? That won't help since
it's i386-only. Besides, m68k has had a much better sub-architecture
infrastructure since ages.

There will be some amount of pain in the m68k/kernel area as well.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com
Snapgear Pty Ltd PHONE: [phone]
825 Stanley St, FAX: [phone]
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com

[Christoph Hellwig]

Post by Greg Ungerer
The ColdFire support will mess things up a bit, the < 68020 is
probably not that bad. I don't think the includes will cause
many problems though, they will be relatively easy.

But given that coldfire v4 has a mmu and I've heared motorla is doing
a full linux port to it this might be nessecary anyway, no?

Or maybe they're going the arch/coldfire/ route..

[Greg Ungerer]

Hi Christoph,

Post by Christoph Hellwig

Post by Greg Ungerer
The ColdFire support will mess things up a bit, the < 68020 is
probably not that bad. I don't think the includes will cause
many problems though, they will be relatively easy.

But given that coldfire v4 has a mmu and I've heared motorla is doing
a full linux port to it this might be nessecary anyway, no?
Or maybe they're going the arch/coldfire/ route...

from what I know about the v4e core is it closer to the 68060
than anything else. Some of the older ColdFire specific changes
no longer apply, single stack pointer, etc. Some of the ColdFire
internal registers do apply (MBAR and the like I think), so some
of the includes can probably be used "as is" from m68knommu.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com
SnapGear Pty Ltd PHONE: [phone]
825 Stanley St, FAX: [phone]
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com

[Geert Uytterhoeven]

Post by Greg Ungerer
Right now I want to focus on getting m68knommu and MMUless in general
complete and stable in 2.6. This is a job for 2.7 :-)

I agree.

Post by Greg Ungerer

Post by Geert Uytterhoeven

Post by Bernardo Innocenti
Could we take advantage of the new sub-architecture infrastructure
introduced in 2.5? I don't know much about it.

You mean the split on i386 for PC, VISWS, and Voyager? That won't help since
it's i386-only. Besides, m68k has had a much better sub-architecture
infrastructure since ages.

There will be some amount of pain in the m68k/kernel area as well.

Of course.

Gr{oetje,eeting}s,

Geert

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

[Geert Uytterhoeven]

Post by Christoph Hellwig

Post by Greg Ungerer
The ColdFire support will mess things up a bit, the < 68020 is
probably not that bad. I don't think the includes will cause
many problems though, they will be relatively easy.

But given that coldfire v4 has a mmu and I've heared motorla is doing
a full linux port to it this might be nessecary anyway, no?

It's been exactly one year ago I heard something about that project, though...

Gr{oetje,eeting}s,

Geert

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

[Greg Ungerer]

Hi Geert,

Post by Geert Uytterhoeven

Post by Christoph Hellwig

Post by Greg Ungerer
The ColdFire support will mess things up a bit, the < 68020 is
probably not that bad. I don't think the includes will cause
many problems though, they will be relatively easy.

But given that coldfire v4 has a mmu and I've heared motorla is doing
a full linux port to it this might be nessecary anyway, no?

It's been exactly one year ago I heard something about that project, though...

I heard some talk of int a couple of months back. I beleive it
is still in the works...

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com
SnapGear Pty Ltd PHONE: [phone]
825 Stanley St, FAX: [phone]
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com

[GRatcliff]

What? V4? pointer, pointer!

Greg





Christoph Hellwig <hch at lst.de>
Sent by: uclinux-dev-bounces at uclinux.org
09/03/2003 10:06 AM
Please respond to uClinux development list


To: Greg Ungerer <gerg at snapgear.com>
cc: Bernardo Innocenti <bernie at develer.com>, Linux/m68k
<linux-m68k at lists.linux-m68k.org>, uClinux development list
<uclinux-dev at uclinux.org>
Subject: Re: [uClinux-dev] uClinux on Amiga 500

Post by Greg Ungerer
The ColdFire support will mess things up a bit, the < 68020 is
probably not that bad. I don't think the includes will cause
many problems though, they will be relatively easy.

But given that coldfire v4 has a mmu and I've heared motorla is doing
a full linux port to it this might be nessecary anyway, no?

Or maybe they're going the arch/coldfire/ route..

[Greg Ungerer]

Hi Greg,

Post by GRatcliff
What? V4? pointer, pointer!

Goto http://www.motorola.com/COLDFIRE and follow the
Architecture -> v4e link on the left.

Regards
Greg

Post by GRatcliff
Christoph Hellwig <hch at lst.de>
Sent by: uclinux-dev-bounces at uclinux.org
09/03/2003 10:06 AM
Please respond to uClinux development list
To: Greg Ungerer <gerg at snapgear.com>
cc: Bernardo Innocenti <bernie at develer.com>, Linux/m68k
<linux-m68k at lists.linux-m68k.org>, uClinux development list
<uclinux-dev at uclinux.org>
Subject: Re: [uClinux-dev] uClinux on Amiga 500

Post by Greg Ungerer
The ColdFire support will mess things up a bit, the < 68020 is
probably not that bad. I don't think the includes will cause
many problems though, they will be relatively easy.

But given that coldfire v4 has a mmu and I've heared motorla is doing
a full linux port to it this might be nessecary anyway, no?
Or maybe they're going the arch/coldfire/ route..
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org