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