[U-Boot] Strange / Unreadable console output

[Andreas Bießmann]

Dear Markus Hubig,

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:
> 
> <snipp>
> 
>>>>> Has anyone an ideea how to fix this? Or what's the cause of it? Is it even
>>>>> related to u-boot or is it something at91bootstrap is doing wrong?
>>>>
>>>> can you please check http://patchwork.ozlabs.org/patch/107896/
>>>>
>>>> It seems this patch was set to 'Accepted' but never applied to the
>>>> master repository. Unfortunately this got lost in nirvana end of last
>>>> year. I will apply it in any case but can you please check if it fixes
>>>> your problem?
>>>
>>> Unfortunately not ... but it dosen't do any harm.
>>
>> How sad!
>>
>> I wonder if this has something to do with the ominous PC9. It is
>> possible that this PC9 switches some vital element e.g. power supply,
>> 'output enable' of UART level shifter or something else which needs some
>> settling. Have you tried adding some delay in between setting this pin
>> and activating the serial port output pins?
> 
> Hmm no, good idea. I tryed this in board_early_init_f(), but again with no
> console output at all ...
> 
> | 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.

>> 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 ...
>  
>> 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().

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()?

> 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 wait what taskit says, maybe this will shine some light on this issue.

BTW: have you seen this patch http://patchwork.ozlabs.org/patch/71772/
before?

Best regards

Andreas Bießmann

PS: mdelay relies on __udelay() which needs the timer running, but the
timer is started after board_early_init_f!