Kernel does not boot on TT030

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Kernel does not boot on TT030

Stefan Niestegge-2
Hi,

after i showed some screenshots of my new Debian 10 netinstalled system
on the Falcon, some people got interested and tried it, too.

Two guys on atari-home tried the netinstall on the TT030.
They have plenty of TT-RAM but still, the kernel does not start up
and run the D-I from the initrd. A serial terminal was connected to
one TT, but all it received was "ABCDEJK".

It has been tried with and without the -S (kernel to ST RAM) bootarg.

Is the kernel of the netinstall CD supposed to run on a TT030?

with kind regards,
Stefan "Beetle" Niestegge

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

John Paul Adrian Glaubitz
Hi Stefan!

On 08/28/2018 02:29 PM, Stefan Niestegge wrote:
> after i showed some screenshots of my new Debian 10 netinstalled system on the Falcon, some people got interested and tried it, too.

Great to hear ;-).

> Two guys on atari-home tried the netinstall on the TT030.
> They have plenty of TT-RAM but still, the kernel does not start up
> and run the D-I from the initrd. A serial terminal was connected to
> one TT, but all it received was "ABCDEJK".

Hmm, that's bad.

> It has been tried with and without the -S (kernel to ST RAM) bootarg.
>
> Is the kernel of the netinstall CD supposed to run on a TT030?

It's supposed to work, yes. But I'm not so much of an Atari expert
that I would know what else to test. I will try to build new installation
images with a newer kernel this week so you have something to test.

Maybe Michael Schmitz can suggest some changes to the kernel command
line to get the machine to boot. FWIW, it also took me a couple of tries
until I managed to boot a kernel on my Amiga 1200.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Finn Thain
In reply to this post by Stefan Niestegge-2
On Tue, 28 Aug 2018, Stefan Niestegge wrote:

> the kernel does not start up and run the D-I from the initrd. A serial
> terminal was connected to one TT, but all it received was "ABCDEJK".
>

If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
Try passing the kernel parameter 'earlyprintk'. That should cause kernel
messages to be sent to the same device(s) to which "ABCDEJK" was sent.

--

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Stefan Niestegge-2


Am 28.08.2018 um 15:00 schrieb Finn Thain:

> On Tue, 28 Aug 2018, Stefan Niestegge wrote:
>
>> the kernel does not start up and run the D-I from the initrd. A serial
>> terminal was connected to one TT, but all it received was "ABCDEJK".
>>
>
> If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
> Try passing the kernel parameter 'earlyprintk'. That should cause kernel
> messages to be sent to the same device(s) to which "ABCDEJK" was sent.
>

good hint, we'll do that and report.

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Michael Schmitz-4
In reply to this post by Finn Thain
Hi Stefan,

Am 29.08.2018 um 01:00 schrieb Finn Thain:
> On Tue, 28 Aug 2018, Stefan Niestegge wrote:
>
>> the kernel does not start up and run the D-I from the initrd. A serial
>> terminal was connected to one TT, but all it received was "ABCDEJK".
>>
>
> If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
> Try passing the kernel parameter 'earlyprintk'. That should cause kernel
> messages to be sent to the same device(s) to which "ABCDEJK" was sent.

I have the following options set to direct console messages to the
serial port:

debug=ser console=tty

'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
Messages appearing there mean the boot process has made it out of early
startup code which I'd expect for a TT.

No idea about any interactions with earlyprintk, sorry.

Option 'stram_pool=128k' might also be required to reserve ST-RAM for
use by drivers that can only address 24 bit (not sure if that's a
problem with the TT video driver).

Once you have console messages on the serial port, the option
'initcall_debug' may be useful to pinpoint where the boot hangs. My
guess would be during probing for optional stuff such as ROM port or
CT60 expansion network card hardware in atari_platform_init(), unless
your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
(m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.

Cheers,

        Michael

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Michael Schmitz-4
Quick clarification - stram_pool is only required if the kernel gets
loaded to TT-RAM (no -s option).

Cheers,

  Michael

On Wed, Aug 29, 2018 at 8:30 PM Michael Schmitz <[hidden email]> wrote:

>
> Hi Stefan,
>
> Am 29.08.2018 um 01:00 schrieb Finn Thain:
> > On Tue, 28 Aug 2018, Stefan Niestegge wrote:
> >
> >> the kernel does not start up and run the D-I from the initrd. A serial
> >> terminal was connected to one TT, but all it received was "ABCDEJK".
> >>
> >
> > If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
> > Try passing the kernel parameter 'earlyprintk'. That should cause kernel
> > messages to be sent to the same device(s) to which "ABCDEJK" was sent.
>
> I have the following options set to direct console messages to the
> serial port:
>
> debug=ser console=tty
>
> 'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
> Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
> Messages appearing there mean the boot process has made it out of early
> startup code which I'd expect for a TT.
>
> No idea about any interactions with earlyprintk, sorry.
>
> Option 'stram_pool=128k' might also be required to reserve ST-RAM for
> use by drivers that can only address 24 bit (not sure if that's a
> problem with the TT video driver).
>
> Once you have console messages on the serial port, the option
> 'initcall_debug' may be useful to pinpoint where the boot hangs. My
> guess would be during probing for optional stuff such as ROM port or
> CT60 expansion network card hardware in atari_platform_init(), unless
> your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
> (m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
> that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.
>
> Cheers,
>
>         Michael
>

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Stefan Niestegge-2
Ah, ok. We will try that.

Thanks a lot,
Stefan

Am 30.08.2018 um 00:34 schrieb Michael Schmitz:

> Quick clarification - stram_pool is only required if the kernel gets
> loaded to TT-RAM (no -s option).
>
> Cheers,
>
>    Michael
>
> On Wed, Aug 29, 2018 at 8:30 PM Michael Schmitz <[hidden email]> wrote:
>>
>> Hi Stefan,
>>
>> Am 29.08.2018 um 01:00 schrieb Finn Thain:
>>> On Tue, 28 Aug 2018, Stefan Niestegge wrote:
>>>
>>>> the kernel does not start up and run the D-I from the initrd. A serial
>>>> terminal was connected to one TT, but all it received was "ABCDEJK".
>>>>
>>>
>>> If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
>>> Try passing the kernel parameter 'earlyprintk'. That should cause kernel
>>> messages to be sent to the same device(s) to which "ABCDEJK" was sent.
>>
>> I have the following options set to direct console messages to the
>> serial port:
>>
>> debug=ser console=tty
>>
>> 'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
>> Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
>> Messages appearing there mean the boot process has made it out of early
>> startup code which I'd expect for a TT.
>>
>> No idea about any interactions with earlyprintk, sorry.
>>
>> Option 'stram_pool=128k' might also be required to reserve ST-RAM for
>> use by drivers that can only address 24 bit (not sure if that's a
>> problem with the TT video driver).
>>
>> Once you have console messages on the serial port, the option
>> 'initcall_debug' may be useful to pinpoint where the boot hangs. My
>> guess would be during probing for optional stuff such as ROM port or
>> CT60 expansion network card hardware in atari_platform_init(), unless
>> your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
>> (m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
>> that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.
>>
>> Cheers,
>>
>>          Michael
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Eero Tamminen
Hi,

One option for testing is Hatari.  Its Mercurial version just got final
missing pieces for TT emulation (= initial SCC & SCSI support).

Unlike Aranym, which emulates only 040, Hatari emulates 030, including
i- & d-caches, MMU and FPU.


        - Eero

PS. With latest Hatari release, it would be better to us (more complete)
Falcon emulation, and just set CPU to 32MHz + enable FPU emulation to
get it closer to TT.

On 08/30/2018 08:31 AM, Stefan Niestegge wrote:

> Ah, ok. We will try that.
>
> Thanks a lot,
> Stefan
>
> Am 30.08.2018 um 00:34 schrieb Michael Schmitz:
>> Quick clarification - stram_pool is only required if the kernel gets
>> loaded to TT-RAM (no -s option).
>>
>> Cheers,
>>
>>    Michael
>>
>> On Wed, Aug 29, 2018 at 8:30 PM Michael Schmitz <[hidden email]>
>> wrote:
>>>
>>> Hi Stefan,
>>>
>>> Am 29.08.2018 um 01:00 schrieb Finn Thain:
>>>> On Tue, 28 Aug 2018, Stefan Niestegge wrote:
>>>>
>>>>> the kernel does not start up and run the D-I from the initrd. A serial
>>>>> terminal was connected to one TT, but all it received was "ABCDEJK".
>>>>>
>>>>
>>>> If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
>>>> Try passing the kernel parameter 'earlyprintk'. That should cause
>>>> kernel
>>>> messages to be sent to the same device(s) to which "ABCDEJK" was sent.
>>>
>>> I have the following options set to direct console messages to the
>>> serial port:
>>>
>>> debug=ser console=tty
>>>
>>> 'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
>>> Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
>>> Messages appearing there mean the boot process has made it out of early
>>> startup code which I'd expect for a TT.
>>>
>>> No idea about any interactions with earlyprintk, sorry.
>>>
>>> Option 'stram_pool=128k' might also be required to reserve ST-RAM for
>>> use by drivers that can only address 24 bit (not sure if that's a
>>> problem with the TT video driver).
>>>
>>> Once you have console messages on the serial port, the option
>>> 'initcall_debug' may be useful to pinpoint where the boot hangs. My
>>> guess would be during probing for optional stuff such as ROM port or
>>> CT60 expansion network card hardware in atari_platform_init(), unless
>>> your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
>>> (m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
>>> that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.
>>>
>>> Cheers,
>>>
>>>          Michael
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Eero Tamminen
In reply to this post by Stefan Niestegge-2
Hi,

On 8/30/18 8:31 AM, Stefan Niestegge wrote:
> Ah, ok. We will try that.

Did you ever get kernel booting on TT?


I've now looked a bit into this with Hatari TT emulation.

"initcall_debug" doesn't give any output, but I've enabled the dummy
IRQ handler [1] and get constant warnings from it.  There's quite
a lot of them in few seconds:
----------------------------------------------
$ grep unexpected tt-boot.log | sort | uniq -c
    1200 unexpected interrupt from 104
     212 unexpected interrupt from 112
----------------------------------------------

Any idea what those interrupts are for?


FYI: When I enable profiler at start and invoke debugger after
a while, it gives me following kernel backtrace:
----------------------------------------------
Finalizing costs for 12 non-returned functions:
- 0x46fba: console_unlock (return = 0x47932)
- 0x4781c: vprintk_emit (return = 0x47966)
- 0x4794a: vprintk_default (return = 0x4835c)
- 0x482e4: vprintk_func (return = 0x48016)
- 0x48004: printk (return = 0x585c)
- 0x5834: handle_badint (return = 0x29a0)
- 0x29a8: resume (return = 0x24b2d4)
- 0x24afd0: __schedule (return = 0x24b364)
- 0x24b31a: schedule (return = 0x24b3dc)
- 0x24b3d2: schedule_preempt_disabled (return = 0x24a07a)
- 0x24a008: rest_init (return = 0x318f64)
- 0x318f88: start_kernel (return = 0x318344)
----------------------------------------------

Attached is dot callgraph [2] of the function call counts from
first instruction until above point.

Good tool to view it is XDot (from "xdot" package).  Red lines
in the graph show which functions get called most often.

(I thought call counts are for this case more interesting than
instruction or cycle counts.)


        - Eero

[1] $ grep IRQ .config
CONFIG_IRQ_WORK=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_DUMMY_IRQ=y
CONFIG_DEBUG_SHIRQ=y

[2] Command line to get graph from the Hatari profiler readable
requires removing edges to generic low level functions:
$ hatari_profile.py -s -t -p -g -a System.map \
   --only-subroutines --no-intermediate --compact \
   --ignore-from __start,copy_process.isra.11.part.12 \
   --ignore-to
memcpy,memset,memmove,memcmp,strlcpy,strlen,strchr,strncmp,kstrdup_const,mutex_lock,mutex_unlock,__mutex_init,__init_rwsem,__init_waitqueue_head,__ashldi3,__lshrdi3,__list_add_valid,__list_del_entry_valid,__alloc_percpu,d_alloc,__d_alloc,__kalloc,__kmalloc,kfree,new_slab,alloc_workqueue_attrs,kmem_cache_alloc,memblock_alloc_try_nid,kmem_cache_create,hwreg_present,__sw_hweight32,printk
   profile.txt

> Am 30.08.2018 um 00:34 schrieb Michael Schmitz:
>> Quick clarification - stram_pool is only required if the kernel gets
>> loaded to TT-RAM (no -s option).
>>
>> Cheers,
>>
>>    Michael
>>
>> On Wed, Aug 29, 2018 at 8:30 PM Michael Schmitz <[hidden email]>
>> wrote:
>>>
>>> Hi Stefan,
>>>
>>> Am 29.08.2018 um 01:00 schrieb Finn Thain:
>>>> On Tue, 28 Aug 2018, Stefan Niestegge wrote:
>>>>
>>>>> the kernel does not start up and run the D-I from the initrd. A serial
>>>>> terminal was connected to one TT, but all it received was "ABCDEJK".
>>>>>
>>>>
>>>> If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
>>>> Try passing the kernel parameter 'earlyprintk'. That should cause
>>>> kernel
>>>> messages to be sent to the same device(s) to which "ABCDEJK" was sent.
>>>
>>> I have the following options set to direct console messages to the
>>> serial port:
>>>
>>> debug=ser console=tty
>>>
>>> 'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
>>> Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
>>> Messages appearing there mean the boot process has made it out of early
>>> startup code which I'd expect for a TT.
>>>
>>> No idea about any interactions with earlyprintk, sorry.
>>>
>>> Option 'stram_pool=128k' might also be required to reserve ST-RAM for
>>> use by drivers that can only address 24 bit (not sure if that's a
>>> problem with the TT video driver).
>>>
>>> Once you have console messages on the serial port, the option
>>> 'initcall_debug' may be useful to pinpoint where the boot hangs. My
>>> guess would be during probing for optional stuff such as ROM port or
>>> CT60 expansion network card hardware in atari_platform_init(), unless
>>> your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
>>> (m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
>>> that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.

profile-unexpected-interrupts-call-counts.dot.gz (37K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Andreas Schwab-2
On Apr 06 2019, Eero Tamminen <[hidden email]> wrote:

> "initcall_debug" doesn't give any output, but I've enabled the dummy
> IRQ handler [1] and get constant warnings from it.  There's quite
> a lot of them in few seconds:
> ----------------------------------------------
> $ grep unexpected tt-boot.log | sort | uniq -c
>    1200 unexpected interrupt from 104
>     212 unexpected interrupt from 112
> ----------------------------------------------
>
> Any idea what those interrupts are for?

These are the HSYNC and VSYNC interrupts.  The HSYNC irq should be
masked by tt_scu.sys_mask, the VSYNC irq is used for the cursor, but I
can't find where it is set up right now.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Stefan Niestegge-2
In reply to this post by Eero Tamminen


Am 06.04.19 um 16:32 schrieb Eero Tamminen:
> Hi,
>
> On 8/30/18 8:31 AM, Stefan Niestegge wrote:
>> Ah, ok. We will try that.
>
> Did you ever get kernel booting on TT?

Nope, sadly we didn't get it running at all on TT030 or Mega with PAK030
no matter what bootargs we tried.

>
>
> I've now looked a bit into this with Hatari TT emulation.
>
> "initcall_debug" doesn't give any output, but I've enabled the dummy
> IRQ handler [1] and get constant warnings from it.  There's quite
> a lot of them in few seconds:
> ----------------------------------------------
> $ grep unexpected tt-boot.log | sort | uniq -c
>     1200 unexpected interrupt from 104
>      212 unexpected interrupt from 112
> ----------------------------------------------
>
> Any idea what those interrupts are for?
>
>
> FYI: When I enable profiler at start and invoke debugger after
> a while, it gives me following kernel backtrace:
> ----------------------------------------------
> Finalizing costs for 12 non-returned functions:
> - 0x46fba: console_unlock (return = 0x47932)
> - 0x4781c: vprintk_emit (return = 0x47966)
> - 0x4794a: vprintk_default (return = 0x4835c)
> - 0x482e4: vprintk_func (return = 0x48016)
> - 0x48004: printk (return = 0x585c)
> - 0x5834: handle_badint (return = 0x29a0)
> - 0x29a8: resume (return = 0x24b2d4)
> - 0x24afd0: __schedule (return = 0x24b364)
> - 0x24b31a: schedule (return = 0x24b3dc)
> - 0x24b3d2: schedule_preempt_disabled (return = 0x24a07a)
> - 0x24a008: rest_init (return = 0x318f64)
> - 0x318f88: start_kernel (return = 0x318344)
> ----------------------------------------------
>
> Attached is dot callgraph [2] of the function call counts from
> first instruction until above point.
>
> Good tool to view it is XDot (from "xdot" package).  Red lines
> in the graph show which functions get called most often.
>
> (I thought call counts are for this case more interesting than
> instruction or cycle counts.)
>
>
>      - Eero
>

Thanks for looking into it again!

Greets,
Stefan

> [1] $ grep IRQ .config
> CONFIG_IRQ_WORK=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
> CONFIG_INLINE_READ_UNLOCK_IRQ=y
> CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
> CONFIG_DUMMY_IRQ=y
> CONFIG_DEBUG_SHIRQ=y
>
> [2] Command line to get graph from the Hatari profiler readable
> requires removing edges to generic low level functions:
> $ hatari_profile.py -s -t -p -g -a System.map \
>    --only-subroutines --no-intermediate --compact \
>    --ignore-from __start,copy_process.isra.11.part.12 \
>    --ignore-to
> memcpy,memset,memmove,memcmp,strlcpy,strlen,strchr,strncmp,kstrdup_const,mutex_lock,mutex_unlock,__mutex_init,__init_rwsem,__init_waitqueue_head,__ashldi3,__lshrdi3,__list_add_valid,__list_del_entry_valid,__alloc_percpu,d_alloc,__d_alloc,__kalloc,__kmalloc,kfree,new_slab,alloc_workqueue_attrs,kmem_cache_alloc,memblock_alloc_try_nid,kmem_cache_create,hwreg_present,__sw_hweight32,printk
>    profile.txt
>
>> Am 30.08.2018 um 00:34 schrieb Michael Schmitz:
>>> Quick clarification - stram_pool is only required if the kernel gets
>>> loaded to TT-RAM (no -s option).
>>>
>>> Cheers,
>>>
>>>    Michael
>>>
>>> On Wed, Aug 29, 2018 at 8:30 PM Michael Schmitz
>>> <[hidden email]> wrote:
>>>>
>>>> Hi Stefan,
>>>>
>>>> Am 29.08.2018 um 01:00 schrieb Finn Thain:
>>>>> On Tue, 28 Aug 2018, Stefan Niestegge wrote:
>>>>>
>>>>>> the kernel does not start up and run the D-I from the initrd. A
>>>>>> serial
>>>>>> terminal was connected to one TT, but all it received was "ABCDEJK".
>>>>>>
>>>>>
>>>>> If you have CONFIG_EARLYPRINTK=y then you can enable the early
>>>>> console.
>>>>> Try passing the kernel parameter 'earlyprintk'. That should cause
>>>>> kernel
>>>>> messages to be sent to the same device(s) to which "ABCDEJK" was sent.
>>>>
>>>> I have the following options set to direct console messages to the
>>>> serial port:
>>>>
>>>> debug=ser console=tty
>>>>
>>>> 'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
>>>> Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
>>>> Messages appearing there mean the boot process has made it out of early
>>>> startup code which I'd expect for a TT.
>>>>
>>>> No idea about any interactions with earlyprintk, sorry.
>>>>
>>>> Option 'stram_pool=128k' might also be required to reserve ST-RAM for
>>>> use by drivers that can only address 24 bit (not sure if that's a
>>>> problem with the TT video driver).
>>>>
>>>> Once you have console messages on the serial port, the option
>>>> 'initcall_debug' may be useful to pinpoint where the boot hangs. My
>>>> guess would be during probing for optional stuff such as ROM port or
>>>> CT60 expansion network card hardware in atari_platform_init(), unless
>>>> your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
>>>> (m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
>>>> that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Eero Tamminen
In reply to this post by Andreas Schwab-2
Hi,

On 4/6/19 8:58 PM, Andreas Schwab wrote:

> On Apr 06 2019, Eero Tamminen <[hidden email]> wrote:
>
>> "initcall_debug" doesn't give any output, but I've enabled the dummy
>> IRQ handler [1] and get constant warnings from it.  There's quite
>> a lot of them in few seconds:
>> ----------------------------------------------
>> $ grep unexpected tt-boot.log | sort | uniq -c
>>     1200 unexpected interrupt from 104
>>      212 unexpected interrupt from 112
>> ----------------------------------------------
>>
>> Any idea what those interrupts are for?
>
> These are the HSYNC and VSYNC interrupts.  The HSYNC irq should be
> masked by tt_scu.sys_mask, the VSYNC irq is used for the cursor, but I
> can't find where it is set up right now.
Thanks!

Looking at config_atari(), there's this:
-----------------------------------------------------
         if (hwreg_present(&tt_scu.sys_mask)) {
                 ATARIHW_SET(SCU);
                 /* Assume a VME bus if there's a SCU */
                 ATARIHW_SET(VME);
                 pr_cont(" VME SCU");
         }
-----------------------------------------------------

Hatari doesn't emulate VME bus nor SCU, but Hatari SCU regs don't
return bus error either.

After I changed Hatari to give bus error on accesses to 0xff8e01
SCU system interrupt mask, unexpected interrupts stopped and minimal
kernel booted fine to minimal rootfs on emulated TT.

I didn't have time to build kernel where the VME assumption is disabled,
but maybe VME part is the issue on real TT?


Btw. that register area is zero on boot in Hatari.  TOS v3 sets there
0x14 early on boot, but with LILO there's no TOS to do that, and Linux
was setting it to 0x10:
-----------------------------------------------------
         if (ATARIHW_PRESENT(SCU)) {
                 /* init the SCU if present */
                 tt_scu.sys_mask = 0x10;         /* enable VBL (for the
cursor) and
 
  * disable HSYNC interrupts (who
 
  * needs them?)  MFP and SCC are
 
  * enabled in VME mask
                                                                          */
                 tt_scu.vme_mask = 0x60;         /* enable MFP and SCC
ints */
         } else {
                 /* If no SCU and no Hades, the HSYNC interrupt needs to be
                  * disabled this way. (Else _inthandler in
kernel/sys_call.S
                  * gets overruns)
                  */

                 vectors[VEC_INT2] = falcon_hblhandler;
                 vectors[VEC_INT4] = falcon_hblhandler;
         }
-----------------------------------------------------


        - Eero

Reply | Threaded
Open this post in threaded view
|

Re: Kernel does not boot on TT030

Michael Schmitz-4
In reply to this post by Andreas Schwab-2
Hi Andreas,

Am 07.04.2019 um 05:58 schrieb Andreas Schwab:

> On Apr 06 2019, Eero Tamminen <[hidden email]> wrote:
>
>> "initcall_debug" doesn't give any output, but I've enabled the dummy
>> IRQ handler [1] and get constant warnings from it.  There's quite
>> a lot of them in few seconds:
>> ----------------------------------------------
>> $ grep unexpected tt-boot.log | sort | uniq -c
>>    1200 unexpected interrupt from 104
>>     212 unexpected interrupt from 112
>> ----------------------------------------------
>>
>> Any idea what those interrupts are for?
>
> These are the HSYNC and VSYNC interrupts.  The HSYNC irq should be
> masked by tt_scu.sys_mask, the VSYNC irq is used for the cursor, but I
> can't find where it is set up right now.

drivers/video/fbdev/atafb.c:3118:

>                         error = request_irq(IRQ_AUTO_4, falcon_vbl_switcher, 0,
>                                             "framebuffer:modeswitch",
>                                             falcon_vbl_switcher);

Only used for Falcon though.

Cursor used to be handled by drivers/video/fbcon.c before that got
refactored - Geert ought to know where the console cursor handling now
lives.

Cheers,

        Michael


>
> Andreas.
>