[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Atari TT



Alan, Thorsten,

> >>On Thu, Jan 5, 2012 at 20:02, Alan Hourihane <alanh@fairlite.co.uk> wrote:
> >>>>>unexpected interrupt from 112
> >>>>That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
> >>>>IRQ_TT_MFP_TIMD. Sorry, no clues.

Timer D is used by the EtherNEC driver - if thad driver has been compiled in
please try and load it as a module only. Just a thought - I missed the
beginning of your thread so I don't know what your kernel confit would be. 

> >>That's bad. So most probably it's been broken on TT for a long time.
> >>AFAIK Atari receives most testing on (emulated -- ARAnyM) Falcon.
> >Ouch. Nothing on this? gemini8 (Bcc’d) reported the same in IRC
> >using vmlinuz-3.8.0-rc3+m68k-queue+atari-84299-g3f4758a which I
> >cross-built earlier.

Tht one _should_ have my patches to convert the timer D interrupt to be
handled by its own dedicated software interrupt 'chip', and at least one
interrupt handler ought to be installed. Might be a race between starting
the timer and requesting the interrupt:

        m68k_setup_irq_controller(&atari_mfptimer_chip, handle_polled_irq,
                                  IRQ_MFP_TIMER1, 8);

        /* prepare timer D data for use as poll interrupt */
        /* set Timer D data Register - needs to be > 0 */
        st_mfp.tim_dt_d = 254;  /* < 100 Hz */
        /* start timer D, div = 1:100 */
        st_mfp.tim_ct_cd = (st_mfp.tim_ct_cd & 0xf0) | 0x6;

        /* request timer D dispatch handler */
        if (request_irq(IRQ_MFP_TIMD, mfptimer_handler, IRQF_SHARED,
                        stmfp_base.name, &stmfp_base))
                pr_err("Couldn't register %s interrupt\n", stmfp_base.name);


Try swapping this so it looks like such:

        m68k_setup_irq_controller(&atari_mfptimer_chip, handle_polled_irq,
                                  IRQ_MFP_TIMER1, 8);

        /* request timer D dispatch handler */
        if (request_irq(IRQ_MFP_TIMD, mfptimer_handler, IRQF_SHARED,
                        stmfp_base.name, &stmfp_base))
                pr_err("Couldn't register %s interrupt\n", stmfp_base.name);

        /* prepare timer D data for use as poll interrupt */
        /* set Timer D data Register - needs to be > 0 */
        st_mfp.tim_dt_d = 254;  /* < 100 Hz */
        /* start timer D, div = 1:100 */
        st_mfp.tim_ct_cd = (st_mfp.tim_ct_cd & 0xf0) | 0x6;

I'll move the timer setup into a atari_mfptimer_startup() routine so the
timer only starts running in case an interrupt relating to the chip has been
requested. 

> >Does anyone have an idea how to help debugging that? I’m sure
> >gemini8 and, probably, Alan wouldn’t mind booting test kernels.
> >
> >00:32 < gemini8> Ok, guys. I'm trying to run mirabilos' vmlinuz-3.8.0-rc3+m68k-queue+atari-84299-g3f4758a on my
> >                  TT. Bootstrap unpacks the kernel, kernel says something about booting, I'm getting loads of
> >                  colourful pixels on my screen, and the floppy starts to blink.

The colorful pixels are your kernel code or data, hard at work making the
floppy blink. On the serial interface for debug, you likely see that a video
base address from the TT RAM range has been allocated for the frame buffer.
The shifter will ignore the hight address bits and map the base address to
the 24 bit ST RAM window. That's where your kernel resides. 

Solution - use stram_pool=512k (or whatever size the frame buffer requires;
use a video mode to minimize framebuffer size). If you're already doing that
- minimize the kernel until you've got enough free ST-RAM. How large is the
kernel once it's been uncompressed? 

> >00:32 < gemini8> That's it.
> >00:32 < gemini8> Anything I can specify in bootargs to maybe get another result?
> >00:33 < gemini8> It's the same with resolution I adjust in bootargs btw.
> >00:38 < ij> do you have serial/null modem cable? then try to add debug=ser to the kernel options
> >00:40 < gemini8> In theory yes.
> >00:40 < gemini8> Will have to find me a terminal though.
> >00:43 < ij> at least you can then see what's going wrong... I just did the same on my Amiga
> >00:58 < gemini8> https://dl.dropbox.com/u/32922157/linux-m68k/linux-m68k-on-tt030.txt
> >
> >No idea whether adding (or not adding) -s makes a difference.
> >Another thing that could be tried (wrt. the video) is the
> >stram_reserve(IIRC?) option? Michael?

That's called stram_pool these days. -s should be used anyway, otherwise the
ST-RAM is not available for use by the kernlel _at all_. Stupid discontigmem
memory model (someone please implement sparsemem. Andreas? Roman?). 

> I have a patch floating about someplace that corrects this problem.
> Let me dig it out.

Please post it for posterity (weak pun unavoidable). 

Cheers,

	Michael


Reply to: