[linuxsh-dev] RE: [linux-sh:02308] !!! HELP - Video framebuffer and keyboard fo r LINUXSH !!!

[CHU L. KWEK-H. <clk...@ha...>]

Fabio

If you think of x86 System, the Vga Controller I/O Memory is at 0x3C0 for
I/O registars. Frame Buffer Memory is usually at A0000. SH don't have I/O
memory Map Area. So you need to remap the I/O area to the memory map. As for
the Frame Buffer Memory Location, you must see where the Frame Memory Buffer
will be located in your system. For example VGA Card Base Address is
0xA1000000, then 0xA10003C0 is the start of the registers that you need to
initialise. 0XA10A0000 could be your frame buffer address if the address in
the Video Chip is set to that address. You just need to write data into the
Framebuffer and you will changes to the image on Screen. Please look at the
Chip Specifications. Normally, VGA don't need to use interrupts.

Keyboard, you need to remap the I/O area and the irq number. Search for
irq_request. irq_request will hook your interrupt handler with a particular
interrupt. The interrupt number that is link to the interrupt handler is a
shifted number from INTEVT.

For PC irq 1 is used for Keyboard , 12 for mouse. Therefore ensure that your
Keyboard IRQ is linked directly to IRQ 1. If you are using a companion Chip,
you might need to decode the Companion Chip Interrupts in the main Interrupt
routine DO_IRQ in irq.c (ALL interrupts comes in here to decode the IRQ
number and search for the interrupt handle and run  it) and give the new
interrupt number to the function (which means you are remapping the IRQ).


regards
kwek


-----Original Message-----
From: Fabio Giovagnini [mailto:fg...@ti...]
Sent: 04 April 2002 19:00
To: Stuart Menefy
Cc: lin...@m1...; lin...@li...
Subject: [linux-sh:02308] !!! HELP - Video framebuffer and keyboard for
LINUXSH !!!


I found what was the problem of the interrupt (PINT initialization);
Now, where can I find the guidelines to implement the support for video in 
framebuffer and keyboard?

On Wednesday 03 April 2002 20:18, Stuart Menefy wrote:
> Fabio
>
> If you look at the bit of code in assembler, it reads the value from
> the INTEVT register, shifts right by 5 and subtracts 16. So an interrupt
> code of 0xd corrisponds to INTEVT code of 0x3a0. Have a look at the
> interrupt code table in the appropriate manual, and you'll see which
> interrupt this corrisponds to. I don't have a 7709 manual to hand,
> but IIRC this is an external interrupt on all SuperH parts.
>
> So something on your board is raising an interrupt, and this error
> message is saying that there is no interrupt handler installed to
> handle it.
>
> This could just be a mis-configuration issue. The interrupt controllers
> on some of the SH3's have quite a few modes and config registers. When
> your board was designed, they probably intended the interrupt controller
> to be set up in a particular way, make sure you're doing this.
>
> Alternativly something on your board really is raising an interrupt.
>
> Hopefully your board has some external logic to control enabling and
> disabling of interrupts from peripherials, so maybe this needs to be
> set up before you enable interrupts at the CPU level.
>
> Or maybe the device which is raising the interrupt at boot time needs
> to be initialised first.
>
> Either would be pretty grotty, most devices power up with interrupts
> disabled and/or inactive until you do something to provoke them, but
> it wouldn't be the first time somebody had designed hardware that didn't
> work that way.
>
> If all else fails, you could look at using the irq_imask routines to
> disable the interrupt using the IMASK in the status register, but
> that should be a last resort, as it results in all interrupts of lower
> priority being disabled, so could disbale something you need.
>
> Hope this helps
>
> Stuart
>
>
>
> On Wed, 3 Apr 2002 16:12:28 +0200
>
> fg...@ti... wrote:
> > Sorry,
> > but I don't understand what means:
> > "unexpected IRQ trap at vector 0d"
> >
> > I suppose it is an interrupt always entering but I don't understand what
> > is its source.
> >
> > Thanks.
> >
> > Fabio
> >
> > On Tuesday 02 April 2002 14:27, Stuart Menefy wrote:
> > > Hi Fabio
> > >
> > > You might like to have a look at the 'board porting guide' a colleague
> > > here wrote. Have a look at:
> > >   http://www.linuxsh.st.com/getting_started/board_porting.php3
> > >
> > > As far as I know, you'll be the first person to try it in anger, so
any
> > > comments welcome!
> > >
> > > You're right, it sounds like you have a pending interrupt. So the
first
> > > thing I'd do is stick a printk at the start of do_IRQ(), and print the
> > > irq number (just after the little bit of asm code which retreives it).
> > >
> > > Stuart
> > >
> > >
> > > On Fri, 29 Mar 2002 10:55:32 +0100
> > >
> > > fg...@ti... wrote:
> > > > Hi, Stuart,
> > > > I' porting linux SH on my sh3 7709a based board.
> > > > I'm able to compile and run for my board sh-boot got from CVS
> > > > repository, I'm able to compile the kernel 2.4.18 and I can boot it
> > > > using gdb.
> > > >
> > > > Making a debug using printk("...."); while(1); to understant I see
> > > > that kernel stops execution at init/main.c -> start_kernel -> sti();
> > > >
> > > > I compiled my kernel as my board were a SolutionEngine, but my board
> > > > isn't a SolutionEngine.
> > > >
> > > > Having read the Documentation/sh/ document from the CVS kernel and
> > > > seeing you are the father of sh_mv model, I write to you for asking:
> > > > 1) Is it possible when I enable the interrupt mask with sti() an
> > > > interrupt pending occurs which I have no handler for?
> > > >
> > > > 2) There is an optiminezed way to trace this kind of troubles?
> > > >
> > > >
> > > > Thanks a lot.
> > > >
> > > > Fabio