This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Redboot: No network interfaces found on olimex lpc-l2294 board


Ð ÐÑÐ, 14/11/2007 Ð 09:18 +0200, Sergei Gavrikov ÐÐÑÐÑ:
> Alexey Shusharin writes:
> > Bronislav Gabrhelik wrote: 
> > > Curently I use redboot image from Sergei's Gavrikov site
> > > (http://sgs.gomel.by/sg/downloads/olpcx2294-latest) and it works fine.
> > > Sergei did great job.
> > > 
> > > I want do make my own image from current sources. I applied patch for
> > > ethernet drive cs8900  + applied epk file to add new hardware as
> > > described on Sergei's site.
> > > My platform is cygwin + arm-elf-gcc 4.0.2 + ecos Configuration Tool
> > > 
> > > When I compile redboot it shows that "No network interfaces found".
> > > After some research in sources I found out that it must be
> > > cs8900a_init what fails. I noticed that there are some diag_printf()
> > > logging under compile condition #if DEBUG & 8.
> > > So I added into common build options for cs8900a -DDEBUG=0xf to switch
> > > on all printfs. But build with this option found network interface and
> > > also redboot obtained the ip address from DHCP server. So it worked.
> > > Finally I found out that if was option -DDEBUG=0x2 which made that
> > > everything works fine. The compilation condition #if DEBUG & 2 is used
> > > in get_reg() and put_reg(), so it slows down writing and reading
> > > into/from cs8900a. The cs8900a chip is connected through External
> > > Memory Controler and mapped into memory space at address 0x82000000. I
> > > suspected that  BCFG2 is different in my image, but after some playing
> > > with arm-elf-objdump -D an comparing of dissassembled code I rejected
> > > it. Note that dissassemled code is different, it uses different
> > > registers, but roughly it is very similar.
> > > 
> > > When I set option -DDEBUG=0x8 it doesn't work and It shows that
> > > "CS8900 didn't reset - abort!". I verified in dissassembled code that
> > > the "callback" CYGHWR_CL_CS8900A_PLF_POST_RESET is called.
> > > 
> > > I don't know what I am doing wrong. I know that it is not bug in compiler :-).
> > > I suspect that I missed set some parameter in config tool. I am
> > > atttaching ecm file.
> > > 
> > > TIA for any hint.
> > > Bronislav GabrhelÃk
> > 
> > Hi
> > 
> > I had the same problem then i was using olpcl2294. Sergei's port has a
> > small bug. He don't use volatile keyword and i think compiler reject
> > code which activates 16-bit mode of cs8900A. For me this bug appears
> > only for olpcl2294. olpce2294 works fine in 8-bit mode.
> > 
> > You should change several lines in ethernet driver (for me it's a
> > devs_eth_arm_olpcl2294.inl).
> > 
> > 
> > Sergei's code:
> > 
> > static __inline__ void post_reset(cyg_addrword_t base)
> > {
> >     // Toggle A0 connected to the SBHE# line
> >     *(char *)0x82000000 = 1;
> >     *(char *)0x82000001 = 2;
> >     *(char *)0x82000000 = 3;
> >     *(char *)0x82000001 = 0;
> > }
> > 
> > Your code:
> > 
> > static __inline__ void post_reset(cyg_addrword_t base)
> > {
> >     // Toggle A0 connected to the SBHE# line
> >     (*(volatile char *)0x82000001) = 0x00;
> >     (*(volatile char *)0x82000000) = 0x00;
> >     (*(volatile char *)0x82000001) = 0x00;
> > }
> > 
> > And i recommend to add lines after this function to call it after
> > hardware reset:
> > 
> > #undef CYGHWR_CL_CS8900A_PLF_INIT
> > #define CYGHWR_CL_CS8900A_PLF_INIT(cpd) post_reset(cpd->base)
> > 
> > 
> > And more...
> > If you are going to use this port for application (not only for RedBoot)
> > you should fix one more bug. olpcl2294 HAL doesn't configure EINT2, and
> > it's used by default (level-sensitivity and low-active mode). But for
> > work with CS8900A it must be in level-sensitivity and high-active mode.
> > So you should make call hal_interrupt_configure somewhere in HAL
> > initialising procedure before network init:
> > 
> > hal_interrupt_configure(CYGNUM_HAL_INTERRUPT_EINT2, 0, 1);
> > 
> > Best regards
> > Alexey Shusharin
> 
> Hello Alexey,
> 
> It seems that I should check the stuff is placed on web. My local copy
> the lpcl2294_misc.c has
> 
> #ifdef HAL_PLF_HARDWARE_INIT
> //--------------------------------------------------------------------------
> // hal_plf_hardware_init --
> //
> void
> hal_plf_hardware_init (void)
> {
>     // configure IRQ level from CL CS8900A
>     cyg_drv_interrupt_configure (CYGNUM_HAL_INTERRUPT_EINT2, 0, 1);
> }
> #endif // HAL_PLF_HARDWARE_INIT
> 
> ASAP, I'll upgrade the web stuff, if that will be needed.
> 
> Thank you,
> 
> Sergei


Hi Sergei

I've got your code from web and found that it's not your bug. Your code
is fine.

I worked with olpcl2294 some month ago and don't remember exactly why i
think so. Maybe it was old version or i modified it and forgot about it.

Sorry for wrong remark.

Best regards
Alexey Shusharin



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]