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

[Fabio G. <fg...@ti...>]

Claer.

Thanks.

Fabio


On Friday 05 April 2002 07:23, CHU LIH KWEK-HMSA wrote:
> 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