Re: [hatari-devel] SCU/VME register access?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 11.6.2024 23.26, Nicolas Pomarède wrote:
> I will have a look, but this is strange. See my notes below :
>
> 1) in 
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/atari/ataints.c#n304
> sys_int mask is set to 0x10 to allows vsync int, but no handler is set 
> for the level 4 interrupt.
> On the contrary for falcon, they set :
>
>               vectors[VEC_INT2] = falcon_hblhandler;
>               vectors[VEC_INT4] = falcon_hblhandler;
>
> (this basically does just a RTE after disabling HBL int in SR)
>
> 2) m68k_irq_startup_irq can change vectors[] and is called 3 times, but 
> only with irq nbr 0xf, 0xc and 0xd (FDC, timerD and timerC), not with 
> irq nbr 4 (which would install auto_inthandler for this irq nbr)
>
> 3) in trap_init at 
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/kernel/vectors.c#n88 all vectors are set by default to bad_inthandler. and bad_inthandler is called when the VBL triggers :
>
> VBL=69 clock=36875019 e_clock_jitter=1
> cpu exception 28 currpc 48cbc buspc 48cb8 newpc 2518 fault_e3 0 op_e3 0 
> addr_e3 0 SR 2204
> bad_inthandler
> cpu video_cyc=   331 331@  0 36875035 : 00002518 42a7  clr.l -(a7) == 
> $00369f40 [*00048c4e]
>
> 4) Nowhere else in the code do I see  that VEC_INT4 is used to set its 
> vector (except in Falcon case). Maybe there's a not so explicit case 
> that changes vectors[VEC_INT4], but I don't see it
>
> When VBL occurs we see it calls bad_inthandler that was set in 3), and 
> not some random handler, so I think VBR is correctly used.
>
> All in all, it seems that the code enable vsync in TT mode but doesn't 
> replace bad_inthandler with another valid handler.

The files I sent to you, load Linux symbols, so you can add 
"cpu_symbols" to "--trace" option to see what all functions get called 
at Linux boot.


> I guess this linux version was tested on real TT by their author, or not 
> ? (comment at top of arch/m68k/atari/ataints.c mentions the most recent 
> changes were about TT SCU)

Kernel I sent is the latest upstream Linux kernel release, v6.9. It may 
be few releases since things have been tested on real TT, but I don't 
think anything relevant has change in quite a while.

However, because such testing runs kernel after TOS has already 
initialized HW, it may miss kernel not initializing all HW as needed 
when kernel _is_ run directly, like happens with Hatari Linux loader.

Kernel I sent to you, is already patched for one such issue:
https://github.com/hatari/hatari/blob/master/tools/linux/0002-Set-reasonable-PSG-port-A-default-value.patch


> I think that adding a line in atari/ataints.c would set a correct handler
>
>      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 */
> +        vectors[VEC_INT4] = falcon_hblhandler;
>      } else {
>
>
> Of course it could be a (stupid) emulation issue that I don't see, but I 
> don't know what I'm missing.
>
> Eero, just in case, could you build an updated kernel with the above 
> line added for the SCU part in atari/ataints.c line 302 ? So I could 
> test with my new SCU code.

I sent that in separate mail.


	- Eero