[U-Boot] Strange / Unreadable console output

[Andreas Bießmann]

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