[U-Boot] [PATCH v7 5/9] arm: serial: Add ability to use pre-initialized UARTs

[Rob Herring <robherring2@gmail.com>]

On Mon, Oct 19, 2015 at 5:09 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Rob,
>
> On 19 October 2015 at 14:14, Rob Herring <robherring2@gmail.com> wrote:
>> On Wed, Oct 14, 2015 at 11:55 AM, Sergey Temerkhanov
>> <s.temerkhanov@gmail.com> wrote:
>>> On some systems, UART initialization is performed before running U-Boot.
>>> This commit allows to skip UART re-initializaion on those systems
>>>
>>> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com>
>>> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
>>>
>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>
>> I'll comment on this now that I'm here, but as the rest of the thread
>> said, please send to DT list.
>>
>>> diff --git a/doc/device-tree-bindings/serial/pl01x.txt b/doc/device-tree-bindings/serial/pl01x.txt
>>> index 61c27d1..0591497 100644
>>> --- a/doc/device-tree-bindings/serial/pl01x.txt
>>> +++ b/doc/device-tree-bindings/serial/pl01x.txt
>>> @@ -5,3 +5,6 @@ Required properties:
>>>  - reg: exactly one register range with length 0x1000
>>>  - clock: input clock frequency for the UART (used to calculate the baud
>>>    rate divisor)
>>> +
>>> +Optional properties:
>>> +- u-boot,skip-init: skip UART initialization at start.
>>
>> What are you trying to accomplish by skipping?
>>
>> stdout-path can take options now, so what about making it an option there:
>>
>> stdout-path = &serial0:no-init
>>
>> I have similar concerns with this as I did with the early init flag.
>> This requires the dtb and u-boot to be in sync. For example, you have
>> this option in the dtb, but then you add clock initialization to your
>> platform which changes the default clock frequency of the UART. Now if
>> you boot with an older dtb and new u-boot, then it will break because
>> the UART is at the wrong baudrate.
>
> If you are saying what I think you are saying, U-Boot expects the
> device tree that IT uses for configuration to come from the same
> commit as the source code. It doesn't support anything else as the DTB
> is bundled with (and replaced at the same time as) U-Boot.. You would
> be on your own in that case.

You can have that expectation, but that is generally not how DT works.
Bindings are an ABI. You may not care for some usecases or boards, but
we generally can't assume a DTB and its user whether u-boot, kernel,
BSD, etc. are linked together. The rule is new s/w version should work
with old DTB.

How is it going to work when/if we put dts files in a standalone repository?

What I want to see WRT u-boot and DTB handling is that they are
independently updateable. That is already the case on some platforms
such as highbank. The way it works is the management processor put
both u-boot and the DTB into memory and then boots the cores. u-boot
does minor tweaks and then passes the DTB on to the OS. I was working
some to add u-boot DT config support for highbank before Calxeda's
demise. IIRC, the main problems I hit were telling u-boot where the
dtb is and then having it pass the same DTB on to the kernel. I doubt
I'm the only one that would like things to work that way.

Rob