All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Brack <fb@ltec.ch>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: Early debug UART not working on AM33XX SoC
Date: Mon, 31 Jan 2022 10:43:39 +0100	[thread overview]
Message-ID: <2854cc5f-31ff-6e14-edc5-eed5da3f8213@ltec.ch> (raw)
In-Reply-To: <CAPnjgZ1h8DmD-bCBvcfhCROqDLsD4sGT0X7tkqrsotvL+GBLBg@mail.gmail.com>

Hello Simon

On 27.01.22 18:33, Simon Glass wrote:
> Hi Felix,
> 
> On Thu, 27 Jan 2022 at 09:27, Felix Brack <fb@ltec.ch> wrote:
>>
>> Hello Simon,
>>
>> On 27.01.22 16:05, Simon Glass wrote:
>>> Hi Felix,
>>>
>>> On Wed, 26 Jan 2022 at 07:02, Felix Brack <fb@ltec.ch> wrote:
>>>>
>>>> Hello Simon,
>>>>
>>>> I am trying to get the current U-Boot master working on the PDU001
>>>> board. This involves the use of an early debug UART.
>>>>
>>>> With commit 0dba4586 (arm: Init the debug UART) the early debug UART on
>>>> the AM33XX SoC doesn't work anymore.
>>>>
>>>> By looking at the code involved I believe a call to
>>>> setup_clocks_for_console() implemented in clock_am33xx.c before the call
>>>> to debug_uart_init() is missing. This is also what happens prior to
>>>> commit 0dba4586 by a call to early_system_init() which in turn calls
>>>> setup_early_clocks() which then calls setup_clocks_for_console().
>>>>
>>>> My quick and dirty fix consist of inserting a call in crt0.S to
>>>> setup_clocks_for_console() just before the call to debug_uart_init()
>>>> which was added in commit 0dba4586. I have guarded this call with
>>>> #if/#endif testing for CONFIG_AM33XX. The code sequence in crt0.S now
>>>> looks like this:
>>>>
>>>> #if defined(CONFIG_DEBUG_UART) && CONFIG_IS_ENABLED(SERIAL)
>>>>   #if defined(CONFIG_AM33XX)
>>>>     bl setup_clocks_for_console
>>>>   #endif
>>>>     bl debug_uart_init
>>>> #endif
>>>>
>>>> However, from what I understand the crt0.S is for _all_ ARM boards hence
>>>> it's probably a bad idea polluting it with such #if/#endif tests for
>>>> different SoCs. What do you think?
>>>>
>>>> If my quick and dirty fix is not that dirty I would be happy to send a
>>>> patch which would also include the removal of the currently remaining
>>>> call to debug_uart_init() in am33xx/board.c
>>>>
>>>> Please apologize my narrow view of the matter dealing only with AM33XX SoCs.
>>>
>>> Are you able to put that call into board_debug_uart_init() and enable
>>> CONFIG_DEBUG_UART_BOARD_INIT ?
>>>
>> Sure I can but there two drawbacks:
>> 1. this fixes the problem only for my board, others might remain broken
> 
> I suggest you make the function common to all boards that need it.
>
I will check that. Maybe the board_debug_uart_init() is not the right
place then as it is board specific. Probably better to have a AM33XX
platform specific function.

Having said that there is still something I don't understand: commit
0dba4586 has added a call to debug_uart_init() in crt0.S but not removed
any existing call to debug_uart_init(). Hence this function is called twice.
Is this intentional (and if so, why ?) or are the remaining calls some
sort of leftovers?

>> 2. the now redundant call to setup_early_clocks() in am33xx/board.c
>>    remains (at least it does not seem to hurt ;-))
> 
> Yes, it is possible to use flags to avoid that, but might not be worth it.
> 
>>
>> I will prepare a patch with a modified board_debug_uart_init() for the
>> PDU001 board then.
>>
>> --
>> Many thanks for your help and kind regards, Felix
>>
> 
> Regards,
> Simon

-- 
Regards, Felix


  reply	other threads:[~2022-01-31  9:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 14:02 Early debug UART not working on AM33XX SoC Felix Brack
2022-01-27 15:05 ` Simon Glass
2022-01-27 16:27   ` Felix Brack
2022-01-27 17:33     ` Simon Glass
2022-01-31  9:43       ` Felix Brack [this message]
2022-01-31 16:12         ` Simon Glass
2022-02-01 10:48           ` Felix Brack
2022-02-01 14:05             ` Simon Glass
2022-02-01 16:54               ` Felix Brack
2022-02-01 17:13               ` Felix Brack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2854cc5f-31ff-6e14-edc5-eed5da3f8213@ltec.ch \
    --to=fb@ltec.ch \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.