[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[microblaze-uclinux] Voi la!!...got a working interactive shell at last!!
we finally have a working interactive shell over the serial port for uClinux on Microblaze(Insight memec spartan 2E 600 LC)....it is so relieving really!!..:-)..maybe silly...but we were mighty happy today after seeing 'ls' do its job of displaying the contents of the root directory on the hyperterm..:-)...
well..as regds the problem...yeah!!..our doubts were correct...the uart interrupt was not being serviced because microblaze was not getting interrupted in the first place..
that led test proved invaluable to us atleast in isolating the problem area...thereafter it was just engineering...
and that was happening because our uart interrupt was not mapped to the interrupt controller..only the timer interrupt was mapped to it...so in effect the uart interrupts were getting ignored (i guess so..)...
here partly(or entirely) the mistake was ours...in our MHS file we had not mapped the uart interrupt to the interrupt controller...so only the timer interrupt was getting serviced...once we did that and put a printk in xmbrs_interrupt..it worked like a charm...we could easily see that xmbrs_interrupt was the ISR getting invoked and hence could conclude that microblaze was indeed getting interrupted now!!..:-)..
one thing i would like to point out is we used the MHS file provided in the uC-dist/vendors/..../XC2V1../hardware
directory as the reference...and that has only the timer interrupt mapped to the interrupt controller...the uClinux dist i am using is the latest one uClinux-dist-20040408.tar.gz....are they not updated?..i mean we downloaded the latest mbvanilla_net platform today from your website and the MHS file had all interrupts mapped to the interrupt controller...
or is it that we have to use only the most recent files provided on your website as our reference?..please clarify..
anyways...thanks for your timely guidance and patient answers to all my queries..:-)..next we plan to getting ethernet working and then proceed to interface keyboard,mouse,LCD and USB modules(this is last in the priority) with our microblaze system...enroute to building a low cost access terminal....call it a low cost computer rather...
i would request you and everyone in the list to please have a look at what we are trying to build at :
any comments(pleasant or otherwise) are most welcome!!..:-)..
> > I am still stuck with my "sash prompt not accepting user input"
> > problem.I am trying to get uClinux booting on my
> > Insight memec spartan 2e 600lc (microblaze) board...
>Can you please post your MHS file?
>Also, confirm that the information in the struct initialiser near line
>182 of xmbserial.c corresponds accurately to the base address and IRQ
>number of your uartlite peripheral(s).
>See other comments below:
>> I now suspect that the keypress is not actually interrupting the processor...if i understand it right..all interrupts are handled by the interrupt controller first..which based on its priority information interrupts microblaze which then responds accordingly by servicing the interrupt...pls correct me if i am getting it wrong here itself....
>that's mostly correct. I don't think the interrupt controller actually
>inplements interrupt priority as such, excepet in a very limited way
>that I won't go into here.
>> just to test whether the processor is actually getting interrupted..i included the uart interrupt module(in addition to tx and rx) and mapped its output to a led on board...so after this i downloaded the image on to the SDRAM on board and executed it..as soon as the sash prompt appeared..when i pressed a key on the keyboard..the led's state changed...and it remained so after that....
>> i concluded that the interrupt is being generated for the keypress but microblaze is not getting interrupted...else the interrupt would have been serviced and cleared subsequently which should have restored the led's old status..am i right here in concluding this way?
>That seems like a good test and reasonable conclusion. It suggests to
>me that you have a mismatch between either the base address or IRQ
>number, for your your uartlite peripheral.
>> on the software side..i placed several "microblaze_gpio_write" utility funtions within the serial driver interrupt handling functions..but so far i have not been able to find out which is the exact function which is invoked when an uart interrupt occurs..i guess its xmbrs_interrupt...anyways this failure to see led values changing also probably supports my theory that microblaze is not getting interrupted in the first place in which case the ISR is never invoked...
>You could put a printk statement in the xmbrs_interrupt function - it's
>a quick and dirty test to see if the interrupt handler is being invoked.
>> i am not very sure..how the uart interrupt works with microblaze...can anyone briefly explain it to me...i am going through the uart controller document but i guess i am missing some fundamental concept?..thanks in advance for any help..
>The uartlite generates a level sensitive interrupt - the interrupt line
>is asserted (high) whenever either of the following is true:
>there is *any* data in the rx buffer OR
>the tx buffer has gone from not empty to empty
>See page 7 of the uartlite data sheet.
>The fact that it is a level sensitive interrupt causes some problems,
>that were discussed a month or two ago.
>microblaze-uclinux mailing list
>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
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/