| Message ID | 502B800D.30805@gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi Markus, On 16.08.2012 17:07, Markus Hubig wrote: > Dear Andreas, > > On Wed, Aug 15, 2012 at 12:55 PM, Andreas Bießmann wrote: >> On 14.08.2012 17:11, Markus Hubig wrote: >>> On Tue, Aug 14, 2012 at 02:03:55PM +0200, Andreas Bießmann wrote: >>>> On 14.08.2012 11:08, Markus Hubig wrote: >>>>> On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote: >>>>>> On 27.07.12 11:16, Markus Hubig wrote: > > <snip> > >>> | int board_early_init_f(void) >>> | { >>> | struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC; >>> | >>> | /* Enable clocks for all PIOs */ >>> | writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) | >>> | (1 << ATMEL_ID_PIOC), &pmc->pcer); >>> | >>> | /* Enable the serial interface */ >>> | at91_set_gpio_output(AT91_PIN_PC9, 1); >>> | mdelay(1000); >>> | at91_seriald_hw_init(); >>> | >>> | return 0; >>> | } >> >> Can you just test the delay in board_init()? I think it should remove >> the wired characters. > > Yes, the strange chars are gone with a small delay after enabling PC9! > > | --- a/board/taskit/stamp9g20/stamp9g20.c > | +++ b/board/taskit/stamp9g20/stamp9g20.c > | @@ -166,6 +166,7 @@ int board_init(void) > | > | /* Enable the serial interface */ > | at91_set_gpio_output(AT91_PIN_PC9, 1); > | + mdelay(1); > | at91_seriald_hw_init(); > | > | stamp9G20_nand_hw_init(); > > And now the output correctly shows "NAND: ..." as the first message course > stamp9G20_nand_hw_init() is the first funktion that writes something to the > serial line after it is enabled. great! >>>> Did you investigate the PCB? Which device is directly behind the DB9 >>>> connector? Can you find a datasheet for that device and check if it has >>>> some power saving features? Can you check if these power saving features >>>> switched with the PC9? Did taskit respond to your request for detailed >>>> information? >>> >>> Problem is, I don't have the circuit diagrams and taskit didn't respond >>> yet ... > > OK now I got an responce from taskit. PC9 enables the level converter of the > RS232 interface. The level converter is a TI MAX3243I. And PC9 is connected > to ~FORCEOFF. So in order to get the serial line working PC9 has to be high. Ok, as I thought ... >>>> Another possible reason can be the fact that you enable the output pins >>>> after serial port is enabled (serial_init runs way before board_init). >>> >>> This is what I think too! But board_early_init_f() is called befor >>> serial_init() so this would be the place to put this, but I don't >>> unterstand why the >>> >>> | at91_set_gpio_output(AT91_PIN_PC9, 1); >>> >>> command is not working in board_early_init_f() ... >> >> This works for me: >> ---8<--- >> --- a/board/atmel/at91sam9263ek/at91sam9263ek.c >> +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c >> @@ -254,6 +254,14 @@ int board_early_init_f(void) >> (1 << ATMEL_ID_PIOCDE), >> &pmc->pcer); >> >> + at91_set_gpio_output(AT91_PIN_PB28, 0); >> + mdelay(10); >> + at91_set_gpio_output(AT91_PIN_PB28, 1); >> + mdelay(10); >> + at91_set_gpio_output(AT91_PIN_PB28, 0); >> + mdelay(10); >> + at91_set_gpio_output(AT91_PIN_PB28, 1); >> + >> at91_seriald_hw_init(); >> return 0; >> } >> --->8--- >> >> I can see pin toggling, unfortunately not the correct timing (~38 us >> instead of 10 ms; have to have a look for that). However the PB28 stays >> high after leaving board_early_init_f(). > > But it definitly dosn't work here. I checked with an oscilator, if I toggle > the pin in board_init() I can nicely see it going high and low but if I > toggle it in board_early_init_f() *nothing* happens! Well as mentioned in my mail the mdelay() can not work in board_eraly_init_f() cause the timers are not setup at this stage. You need to provide some nop-loop based delay here to have proper delay! As mentioned before my at91sam9263 (running at about 200 MHz produce 38 us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz produces here). A simple test could be to move the timer init in a/a/lib/board.c before board_early_init_f in the init_sequence. Then the mdelay() will work as expected! > This seems to be the real problem ... for some reason a can *not* toggle gpio > pins in board_early_init_f()! I also double checked this with a LED pin. I bet > there is something I need to enable earlier to get the at91_set_gpio_output() > command working in board_early_init_f() ... Have you tried pulling the pin low in board_early_init_f and pull it high later on in e.g. board_init? >> Another possibility: Your switching of PC9 in board_early_init_f works >> correctly but needs some settling. Due to the defective mdelay() in >> board_early_init_f() you will just see nothing cause it was toggled out >> after your level shifter was ready. Have you tried pressing <Return> >> after boot in your terminal when you tested the at91_seriald_hw_init() >> in board_early_init_f()? > > Yes but this dosn't work either ... damn ... >>> I even put this into serial_init() but again with no luck ... >>> >>>> Therefore your output is put into the TX register but I don't know what >>>> happens then. Eventually the output is delayed until the output pins are >>>> enabled in conjunction with the 'SYS' clock. Maybe the TX logic is >>>> happily shifting the bits into nirvana until you switch on the output >>>> pins. In conjunction with the PC9 thing this could be your problem. > > I'll have a look how stuff is done in board_early_init_f() in other boards, > maybe I find a hint what to do to enable the use ob PIO pins there ... > >> BTW: have you seen this patch http://patchwork.ozlabs.org/patch/71772/ >> before? > > Not exactly this one, when I first started to work on the patch I got an > old (~2 years) one from taskit ... Damn! Here the PC5 and PC9 pins are > nicly named ;( send a patch (including working serial console output ;) Best regards Andreas Bießmann
Hi Andreas, On Thu, Aug 16, 2012 at 05:33:26PM +0200, Andreas Bießmann wrote: > On 16.08.2012 17:07, Markus Hubig wrote: <snip> > > But it definitly dosn't work here. I checked with an oscilator, if I toggle > > the pin in board_init() I can nicely see it going high and low but if I > > toggle it in board_early_init_f() *nothing* happens! > > Well as mentioned in my mail the mdelay() can not work in > board_eraly_init_f() cause the timers are not setup at this stage. You > need to provide some nop-loop based delay here to have proper delay! > As mentioned before my at91sam9263 (running at about 200 MHz produce 38 > us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz > produces here). A simple test could be to move the timer init in > a/a/lib/board.c before board_early_init_f in the init_sequence. Then the > mdelay() will work as expected! You were right! The problem was the missing delay after setting the pin! Just moving the timer_init() before board_early_init_f() in the init_sequence didn't work because we need the clocks from board_early_init_f() first. But I found the | board_postclk_init() function and the corresponding | CONFIG_BOARD_POSTCLK_INIT switch, so I put everything there and now it all works fine! ;-) > send a patch (including working serial console output ;) Unfortunately the board_postclk_init() function was not in the init_sequence at arch/arm/lib/board.c so I added it there. I will provide two patches, one for the board stuff and one for the stamp stuff, if this is OK with you ... Cheers, Markus
On 16.08.2012 18:51, Markus Hubig wrote: > Hi Andreas, > > On Thu, Aug 16, 2012 at 05:33:26PM +0200, Andreas Bießmann wrote: >> On 16.08.2012 17:07, Markus Hubig wrote: > > <snip> > >>> But it definitly dosn't work here. I checked with an oscilator, if I toggle >>> the pin in board_init() I can nicely see it going high and low but if I >>> toggle it in board_early_init_f() *nothing* happens! >> >> Well as mentioned in my mail the mdelay() can not work in >> board_eraly_init_f() cause the timers are not setup at this stage. You >> need to provide some nop-loop based delay here to have proper delay! >> As mentioned before my at91sam9263 (running at about 200 MHz produce 38 >> us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz >> produces here). A simple test could be to move the timer init in >> a/a/lib/board.c before board_early_init_f in the init_sequence. Then the >> mdelay() will work as expected! > > You were right! The problem was the missing delay after setting the pin! > Just moving the timer_init() before board_early_init_f() in the init_sequence > didn't work because we need the clocks from board_early_init_f() first. But I > found the > > | board_postclk_init() > > function and the corresponding > > | CONFIG_BOARD_POSTCLK_INIT > > switch, so I put everything there and now it all works fine! ;-) great! >> send a patch (including working serial console output ;) > > Unfortunately the board_postclk_init() function was not in the init_sequence > at arch/arm/lib/board.c so I added it there. I will provide two patches, one > for the board stuff and one for the stamp stuff, if this is OK with you ... I think adding the postclock stuff to arm is ok. Albert is responsible for that so if he is willing to accept that the stamp9g20 stuff is no problem. Best regards Andreas Bießmann
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c @@ -254,6 +254,14 @@ int board_early_init_f(void) (1 << ATMEL_ID_PIOCDE), &pmc->pcer); + at91_set_gpio_output(AT91_PIN_PB28, 0); + mdelay(10); + at91_set_gpio_output(AT91_PIN_PB28, 1); + mdelay(10); + at91_set_gpio_output(AT91_PIN_PB28, 0); + mdelay(10); + at91_set_gpio_output(AT91_PIN_PB28, 1); + at91_seriald_hw_init(); return 0; }