Support for MMU-less Atari ST

Support for MMU-less Atari ST

[Matthias Reis]

Hi all,

since the m68k and the m68knommu trees have now been merged, I wonder if it is possible to run linux on mmu-less 68000 machines like the (original) Atari ST. I think the first thing to do would be to modify arch/m68k/kernel/head.S in order to handle non-mmu CPUs. I would be happy to do some work on this but the problem is that I'm not very familiar with the kernel so far. It would be nice if someone could tell me which things need to be done to run linux on a mmu-less Atari ST. I'm not expecting detailed step-by-step instructions, but rather some hints where the MMU- or 68020-dependent stuff in the Atari drivers lies.

Thanks in advance.

Best regards,
Matthias

Re: Support for MMU-less Atari ST

[Greg Ungerer]

Hi Matthias,

On 03/06/11 05:25, Matthias Reis wrote:
> since the m68k and the m68knommu trees have now been merged, I wonder if it is possible to run linux on mmu-less 68000 machines like the (original) Atari ST. I think the first thing to do would be to modify arch/m68k/kernel/head.S in order to handle non-mmu CPUs. I would be happy to do some work on this but the problem is that I'm not very familiar with the kernel so far. It would be nice if someone could tell me which things need to be done to run linux on a mmu-less Atari ST. I'm not expecting detailed step-by-step instructions, but rather some hints where the MMU- or 68020-dependent stuff in the Atari drivers lies.

Although m68k and m68knommu now all live in one arch directory a lot
of the pieces are not really integrated yet. We are working towards
that now.

I haven't looked in arch/m68k/kernel/head.S yet, but if that can
be made to work without enabling the MMU then that seems like a
reasonable start. Currently the non-mmu based targets do not use
that (there is a couple of different head.S files for various
targets/cpus under arch/m68k/platfom/, search for files with "head"
in the name). Ultimately it would be nice to clean all those up.

Above that you may well hit problems trying to get timers and
interrupts working, might not be too hard to sort that out.
Basic device drivers might be ok. Lets see how far you can get :-)

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

Re: Support for MMU-less Atari ST

[Geert Uytterhoeven]

On Fri, Jun 3, 2011 at 09:04, Greg Ungerer <gerg@snapgear.com> wrote:
> On 03/06/11 05:25, Matthias Reis wrote:
>> since the m68k and the m68knommu trees have now been merged, I wonder if
>> it is possible to run linux on mmu-less 68000 machines like the (original)
>> Atari ST. I think the first thing to do would be to modify
>> arch/m68k/kernel/head.S in order to handle non-mmu CPUs. I would be happy to
>> do some work on this but the problem is that I'm not very familiar with the
>> kernel so far. It would be nice if someone could tell me which things need
>> to be done to run linux on a mmu-less Atari ST. I'm not expecting detailed
>> step-by-step instructions, but rather some hints where the MMU- or
>> 68020-dependent stuff in the Atari drivers lies.

I worked on getting uClinux running on MMUless Amiga (read: UAE) in
the 2.6.8.1 era.
I got it more or less into booting userspace:
http://www.kernel.org/pub/linux/kernel/people/geert/uClinux-amiga-2.6.x-merging/

Recently, I tried forward porting this to 2.6.39 in the (idle) hope
converting the Amiga
code to genirq would be easier while debugging on UAE than on real hardware.
However, it's not as far yet as the work on 2.6.8.1, but since you're
interested in
it, I'll push it out later today.

W.r.t. drivers, they are the easy part, and should work without any changes.

> Although m68k and m68knommu now all live in one arch directory a lot
> of the pieces are not really integrated yet. We are working towards
> that now.
>
> I haven't looked in arch/m68k/kernel/head.S yet, but if that can
> be made to work without enabling the MMU then that seems like a
> reasonable start. Currently the non-mmu based targets do not use
> that (there is a couple of different head.S files for various
> targets/cpus under arch/m68k/platfom/, search for files with "head"
> in the name). Ultimately it would be nice to clean all those up.
>
> Above that you may well hit problems trying to get timers and
> interrupts working, might not be too hard to sort that out.
> Basic device drivers might be ok. Lets see how far you can get :-)

Following up on Greg, indeed a lot is not integrated yet. The main difficulty to
support MMUless operation on the classic Linux/m68k platforms (Amiga, Atari,
Mac, ...) is the different frameworks used by mmu-based platforms and nommu
platforms. I.e. the Amiga and Atari platform code depends a lot on the mmu-based
core framework, in the parts that are not related to the MMU at all.
So for now I ended up still using most of the *_mm.c files, and
sprinkling lots of
#ifdefs for CONFIG_MMU in them. Yes, this includes arch/m68k/kernel/head.S.

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: Support for MMU-less Atari ST

[Geert Uytterhoeven]

On Fri, Jun 3, 2011 at 09:43, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, Jun 3, 2011 at 09:04, Greg Ungerer <gerg@snapgear.com> wrote:
>> On 03/06/11 05:25, Matthias Reis wrote:
>>> since the m68k and the m68knommu trees have now been merged, I wonder if
>>> it is possible to run linux on mmu-less 68000 machines like the (original)
>>> Atari ST. I think the first thing to do would be to modify
>>> arch/m68k/kernel/head.S in order to handle non-mmu CPUs. I would be happy to
>>> do some work on this but the problem is that I'm not very familiar with the
>>> kernel so far. It would be nice if someone could tell me which things need
>>> to be done to run linux on a mmu-less Atari ST. I'm not expecting detailed
>>> step-by-step instructions, but rather some hints where the MMU- or
>>> 68020-dependent stuff in the Atari drivers lies.
>
> I worked on getting uClinux running on MMUless Amiga (read: UAE) in
> the 2.6.8.1 era.
> I got it more or less into booting userspace:
> http://www.kernel.org/pub/linux/kernel/people/geert/uClinux-amiga-2.6.x-merging/
>
> Recently, I tried forward porting this to 2.6.39 in the (idle) hope
> converting the Amiga
> code to genirq would be easier while debugging on UAE than on real hardware.
> However, it's not as far yet as the work on 2.6.8.1, but since you're
> interested in
> it, I'll push it out later today.

Just for reference, I pushed it out to
git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git
uamiga-untested
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/uamiga-untested

It's not identical to what I tested, and some work is required to
rebase it to 3.0-rc1, due to
changes in the m68knommu handling.

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: Support for MMU-less Atari ST

[Matthias Reis]

Thanks. I'm a bit busy the next weeks, but after that I will have a look
at it.

Best regards,
Matthias


> Just for reference, I pushed it out to
> git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git
> uamiga-untested
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/uamiga-untested
>
> It's not identical to what I tested, and some work is required to
> rebase it to 3.0-rc1, due to
> changes in the m68knommu handling.
>
> 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
>

Autovector exceptions on Atari ST

[Matthias Reis]

Hi all,

I wanted to tell you that my Atari ST kernel now boots up until calibrate_delay loop, which hangs in an infinite loop ... I have read that this indicates normally that the timer interrupt is not working. I therefore checked if atari_sched_init is called and found that it is invoked by time_init which is ok. However, the interrupt handler timer_interrupt is never called subsequently (I can check that by setting a corresponding breakpoint in the emulator). This means probably that MFP autovector exceptions (the timer interrupt is handled by the MFP chip) are not registered properly.

I have applied most of the patches from Geert's uamiga-untested branch, especially the one regarding the 68000 autovectors (http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commit;h=21e03a7a7c60b2646bd7edd740cc964091bf8ca0). Comparing the amiga_init_IRQ and the atari_init_IRQ functions, I can see that the Amiga code registers the autovectors with request_irq. Do I need to do something similar in atari_init_IRQ and write a special handler for the MFP autovector (I think it is level 6)? If yes, how would such a handler look like?

Thanks in advance for your help :)

Best regards,
Matthias

Re: Autovector exceptions on Atari ST

[Geert Uytterhoeven]

On Sun, Aug 7, 2011 at 22:57, Matthias Reis
<matthias.reis@physik.tu-berlin.de> wrote:
> I wanted to tell you that my Atari ST kernel now boots up until calibrate_delay loop, which hangs in an infinite loop ... I have read that this indicates normally that the timer interrupt is not working. I therefore checked if atari_sched_init is called and found that it is invoked by time_init which is ok. However, the interrupt handler timer_interrupt is never called subsequently (I can check that by setting a corresponding breakpoint in the emulator). This means probably that MFP autovector exceptions (the timer interrupt is handled by the MFP chip) are not registered properly.
>
> I have applied most of the patches from Geert's uamiga-untested branch, especially the one regarding the 68000 autovectors (http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commit;h=21e03a7a7c60b2646bd7edd740cc964091bf8ca0). Comparing the amiga_init_IRQ and the atari_init_IRQ functions, I can see that the Amiga code registers the autovectors with request_irq. Do I need to do something similar in atari_init_IRQ and write a special handler for the MFP autovector (I think it is level 6)? If yes, how would such a handler look like?

W.r.t. interrupts, the only difference between MMU and NOMMU should be
the location of the exception vectors, as the 68000 doesn't have the
VBR.

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: Autovector exceptions on Atari ST

[Geert Uytterhoeven]

On Sun, Aug 7, 2011 at 23:09, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, Aug 7, 2011 at 22:57, Matthias Reis
> <matthias.reis@physik.tu-berlin.de> wrote:
>> I wanted to tell you that my Atari ST kernel now boots up until calibrate_delay loop, which hangs in an infinite loop ... I have read that this indicates normally that the timer interrupt is not working. I therefore checked if atari_sched_init is called and found that it is invoked by time_init which is ok. However, the interrupt handler timer_interrupt is never called subsequently (I can check that by setting a corresponding breakpoint in the emulator). This means probably that MFP autovector exceptions (the timer interrupt is handled by the MFP chip) are not registered properly.

MFP interrupts are not autovector interrupts, but user vector interrupts.

>> I have applied most of the patches from Geert's uamiga-untested branch, especially the one regarding the 68000 autovectors (http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commit;h=21e03a7a7c60b2646bd7edd740cc964091bf8ca0). Comparing the amiga_init_IRQ and the atari_init_IRQ functions, I can see that the Amiga code registers the autovectors with request_irq. Do I need to do something similar in atari_init_IRQ and write a special handler for the MFP autovector (I think it is level 6)? If yes, how would such a handler look like?
>
> W.r.t. interrupts, the only difference between MMU and NOMMU should be
> the location of the exception vectors, as the 68000 doesn't have the
> VBR.

Sorry, I forgot about this: it may be a stack frame format issue,
which causes the kernel to
incorrectly identify the interrupt number.

user_inthandler() in arch/m68k/kernel/entry_mm.S looks at the PT_OFF_FORMATVEC
field in the stack frame to identify the interrupt source. I don't
know from memory
if the plain 68000 stores it there. For autovector interrupts, it
doesn't, that's why
I created inidividual auto*_inthandler() functions that put an hardcoded number
on the stack instead of looking at the stack frame.

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: Autovector exceptions on Atari ST

[Matthias Reis]

> On Sun, Aug 7, 2011 at 23:09, Geert Uytterhoeven <geert@linux-m68k.org>
> wrote:
>
> MFP interrupts are not autovector interrupts, but user vector interrupts.
>
> Sorry, I forgot about this: it may be a stack frame format issue,
> which causes the kernel to
> incorrectly identify the interrupt number.
>
> user_inthandler() in arch/m68k/kernel/entry_mm.S looks at the
> PT_OFF_FORMATVEC
> field in the stack frame to identify the interrupt source. I don't
> know from memory
> if the plain 68000 stores it there. For autovector interrupts, it
> doesn't, that's why
> I created inidividual auto*_inthandler() functions that put an hardcoded
> number
> on the stack instead of looking at the stack frame.
>

Hi Geert,

thanks for your kind reply. As far as I understand the 68000 manual
(http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf,
section b.2), the CPU does not store the vector number on the exception
stack. This is also what I've seen in the debugger: some seemingly bogus
irq number is passed to m68k_handle_int. Any suggestions how to solve
this? I guess it is not a good idea to write an individual
user*_inthandler for each of the 255-64=191 possible user interrupts.

Best regards,
Matthias

Re: Autovector exceptions on Atari ST

[Joshua Juran]

On Aug 24, 2011, at 12:47 PM, Matthias Reis wrote:

>> On Sun, Aug 7, 2011 at 23:09, Geert Uytterhoeven <geert@linux- 
>> m68k.org>
>> wrote:
>>
>> MFP interrupts are not autovector interrupts, but user vector  
>> interrupts.
>>
>> Sorry, I forgot about this: it may be a stack frame format issue,
>> which causes the kernel to
>> incorrectly identify the interrupt number.
>>
>> user_inthandler() in arch/m68k/kernel/entry_mm.S looks at the
>> PT_OFF_FORMATVEC
>> field in the stack frame to identify the interrupt source. I don't
>> know from memory
>> if the plain 68000 stores it there. For autovector interrupts, it
>> doesn't, that's why
>> I created inidividual auto*_inthandler() functions that put an  
>> hardcoded
>> number
>> on the stack instead of looking at the stack frame.
>>
>
> Hi Geert,
>
> thanks for your kind reply. As far as I understand the 68000 manual
> (http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf,
> section b.2), the CPU does not store the vector number on the  
> exception
> stack. This is also what I've seen in the debugger: some seemingly  
> bogus
> irq number is passed to m68k_handle_int. Any suggestions how to solve
> this? I guess it is not a good idea to write an individual
> user*_inthandler for each of the 255-64=191 possible user interrupts.

It's not out of the question.  Although you wouldn't write 192 little  
functions by hand -- just have stubs that push the vector number or  
offset onto the stack and branch to another function, and generate  
the stub code at runtime.

Josh

Re: Autovector exceptions on Atari ST

[Geert Uytterhoeven]

On Thu, Aug 25, 2011 at 03:51, Joshua Juran <jjuran@gmail.com> wrote:
> On Aug 24, 2011, at 12:47 PM, Matthias Reis wrote:
>
>>> On Sun, Aug 7, 2011 at 23:09, Geert Uytterhoeven <geert@linux-m68k.org>
>>> wrote:
>>>
>>> MFP interrupts are not autovector interrupts, but user vector interrupts.
>>>
>>> Sorry, I forgot about this: it may be a stack frame format issue,
>>> which causes the kernel to
>>> incorrectly identify the interrupt number.
>>>
>>> user_inthandler() in arch/m68k/kernel/entry_mm.S looks at the
>>> PT_OFF_FORMATVEC
>>> field in the stack frame to identify the interrupt source. I don't
>>> know from memory
>>> if the plain 68000 stores it there. For autovector interrupts, it
>>> doesn't, that's why
>>> I created inidividual auto*_inthandler() functions that put an hardcoded
>>> number
>>> on the stack instead of looking at the stack frame.
>>
>> thanks for your kind reply. As far as I understand the 68000 manual
>> (http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf,
>> section b.2), the CPU does not store the vector number on the exception
>> stack. This is also what I've seen in the debugger: some seemingly bogus
>> irq number is passed to m68k_handle_int. Any suggestions how to solve
>> this? I guess it is not a good idea to write an individual
>> user*_inthandler for each of the 255-64=191 possible user interrupts.
>
> It's not out of the question.  Although you wouldn't write 192 little
> functions by hand -- just have stubs that push the vector number or offset
> onto the stack and branch to another function, and generate the stub code at
> runtime.

And you only have to do it for the user interrupts you actually need/use.
I.e. m68k_setup_user_interrupt() could allocate the needed memory and fill
it with the generated interrupt handlers.
For Atari that's doable, for VME it would still generate all 192 of them.
Alternatively, let m68k_irq_startup() handle it when it's called the
first time for
that specific interrupt.

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: Autovector exceptions on Atari ST

[Greg Ungerer]

On 25/08/11 18:13, Geert Uytterhoeven wrote:
> On Thu, Aug 25, 2011 at 03:51, Joshua Juran<jjuran@gmail.com>  wrote:
>> On Aug 24, 2011, at 12:47 PM, Matthias Reis wrote:
>>
>>>> On Sun, Aug 7, 2011 at 23:09, Geert Uytterhoeven<geert@linux-m68k.org>
>>>> wrote:
>>>>
>>>> MFP interrupts are not autovector interrupts, but user vector interrupts.
>>>>
>>>> Sorry, I forgot about this: it may be a stack frame format issue,
>>>> which causes the kernel to
>>>> incorrectly identify the interrupt number.
>>>>
>>>> user_inthandler() in arch/m68k/kernel/entry_mm.S looks at the
>>>> PT_OFF_FORMATVEC
>>>> field in the stack frame to identify the interrupt source. I don't
>>>> know from memory
>>>> if the plain 68000 stores it there. For autovector interrupts, it
>>>> doesn't, that's why
>>>> I created inidividual auto*_inthandler() functions that put an hardcoded
>>>> number
>>>> on the stack instead of looking at the stack frame.
>>>
>>> thanks for your kind reply. As far as I understand the 68000 manual
>>> (http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf,
>>> section b.2), the CPU does not store the vector number on the exception
>>> stack. This is also what I've seen in the debugger: some seemingly bogus
>>> irq number is passed to m68k_handle_int. Any suggestions how to solve
>>> this? I guess it is not a good idea to write an individual
>>> user*_inthandler for each of the 255-64=191 possible user interrupts.
>>
>> It's not out of the question. áAlthough you wouldn't write 192 little
>> functions by hand -- just have stubs that push the vector number or offset
>> onto the stack and branch to another function, and generate the stub code at
>> runtime.
>
> And you only have to do it for the user interrupts you actually need/use.

That is pretty much what the code for the 68328 does.

   arch/m68k/platform/68328/entry.S

It has 8 handlers for the 8 real interrupts it can handle.

Regards
Greg


> I.e. m68k_setup_user_interrupt() could allocate the needed memory and fill
> it with the generated interrupt handlers.
> For Atari that's doable, for VME it would still generate all 192 of them.
> Alternatively, let m68k_irq_startup() handle it when it's called the
> first time for
> that specific interrupt.

Re: Support for MMU-less Atari ST

[Finn Thain]

On Fri, 3 Jun 2011, Greg Ungerer wrote:

> I haven't looked in arch/m68k/kernel/head.S yet, but if that can
> be made to work without enabling the MMU then that seems like a
> reasonable start.

I believe that Laurent Vivier was able to accomplish something similar 
with his Macintosh SE port.

Finn