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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot