Re: Re: [microblaze-uclinux] uclinux build fails because

[anand_12 <anand_12@xxxxxxxxxxxx>]

Hi john

 Thanks for your suggestions.Fine,we will start using  mdm/fsl from now.

 Btw,looks like it was a freak problem..a random event..
I did not make any changes..its fully functional today 
I still cannot figure out what actually caused that...
I just compiled another image today and it works fine..

 I have one doubt here...How does inclusion of FSL improve the download speed?...I mean, FSL is used only by MDM to communicate with MicroBlaze right?..

 Another thing I have observed over a period of these interactive shell sessions(over serial port) is that, 
beyond some time the uart interrupt does not get serviced
...we still have the uart interrupt mapped to the gpio led on board...it works fine say for about 25 minutes(roughly..i guess its got more to do with the number of commands executed than the time..)..during this time..we can observe the led status changing..beyond some time(mentioned a
bove)..it seems as though the uart interrupt does not get serviced for some reason and hence it stops taking keyboard input ...the session hangs i mean...

the session hangs even if we type at a fast rate...
is this because of the serial line limitation or 
the serial driver is not able to handle interrupts at this
rate?..


has anybody faced this problem before?


Regards
 
 V.Anand
(www.tenet.res.in)



 . 













anand_12 wrote:
>> 
>>  No..I am not using that combination..I am using xmdstub only..not even mdm...i am not using FSL also..
>> actually I have scaled down..i mean..this problem is happening for the past 2-3 days...so right now I am back to
>> some very basic kernel configuration..image size around 1MB...
>
>If you've got sufficient logic resources I stronly recommend using the 
>mdm/fsl stuff - it makes makes the build-download-debug cycle much 
>faster than using the serial port.  Also, since it's hardware based, 
>it's less intrusive than having the xmdstub program running on microblaze.
>
>Anyway...
>
>> 
>> after downloading the image..when i give a "con start-address" command...it either says USERSTOP at some location or says nothing...but both cases..the execution (probably) halts and nothing shows up on the hyperterm...
>> one more point is some older images run without any problems
>
>It seems a bit stragne - what happens if you quit xmd after the 
>download, then restart/reconnect, *then* do the con 0X80000000?
>
>
>> ..i mean..the execution is smooth(with full networking)..only for the past few days we are facing this problem...the build environment is still the same..
>> 
>> the location where i generally get this message(USERSTOP) is 0x80000004 or 0x80000008(mostly 04)..here is the image.dump :
>
>That's pretty odd - those are the first instructions in the early kernel 
>startup code.  I can't imagine why you'd be getting a breakpoint in 
>there.  If you can, try to go with the mdm debugging, it seems much more 
>robust.
>
>Cheers,
>
>John
>___________________________
>microblaze-uclinux mailing list
>microblaze-uclinux@itee.uq.edu.au
>Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
>Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>
>
****************************************

-----
  Trouble with windows? Re boot.... 
  Trouble with Linux? Be root....
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/