Problem with the efi332 start

Gerald Klaucke Gerald.Klaucke at
Tue Dec 4 19:46:08 UTC 2001

> | i try to start an efi332 like board with the RTEMS latest snapshot, but
> | it allways disappearce in to spurious interrupt.
> | I think there is an error in the BSP since the ISR_vector_table was
> | changed from static to dynamic allocated memory, because in the BSP
> | set_vector and with it _CPU_ISR_install_vector is called before the
> | ISR_vector_table is allocated.
> I have not had any such problems (off hand, I think you are seeing the
> initialization of a temporary startup table used only immediately
> after reset, but my memory is vague on that portion of the
> code.)... if you email me a better description of what you believe are
> problems in the bsp, I'm sure I can help.
> | Is anybody out there who is working seriously with efi332 and who was
> | fixing the problem?
> |
> | G.Klaucke
> I see the patches I submitted on rtems-ss-20010525 did not get
> applied. I ran the samples last night on rtems-4.5.1-pre3 with the
> patches from 20010525. The RAM model ran fine; will test the ROM model
> tonight.
> I recommend you apply the patches I have for rtems-ss-20010525
> ( to rtems-4.5.1-pre3 and
> give it another shot (all patched applied except for linkcmd and
> linkcmd_ROM, use the linkcmd* from 20010525).
> I will resubmit the patches and update my web page once I complete
> testing of pre3.
> hths
> john gwynne
> ---------------------------------------------------------
>                                 John S Gwynne, PhD.
> Mission Research Corporation    Email: jgwynne at
> 3975 Research Blvd              Tel: (937) 429-9261 x166
> Dayton Ohio 45430-2625          Fax: (937) 320-2562
> ---------------------------------------------------------

Thanks John,

i fixed the problem. I use the ss20011025 with the ROM model.

As described the ISR_vector_table became now a pointer which is set in  
_ISR_Handler_initialization (which is different to 4.5.1). In your version 
ISR_vector_table is a static array.
But the table is already used by set_vector in Spurious_Initialize. Which is 
called in start before boot_card is called where somewhere 
_ISR_Handler_initialization is called.
On boot the ISR_vector_table pointer is zero and so the spurious vectors 
where written right into my processor interrupt table.

I fixed the error in ...

void Spurious_Initialize(void)
  rtems_vector_number vector;

  for ( vector = 0x0 ; vector <= 0xFF ; vector++ )
    (void) set_vector( Spurious_Isr, vector, 0 );

The set_vector type parameter (the last one) became zero for initialize just 
the raw vectors and not the ISR_vector_table.


More information about the users mailing list