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

[Simon Glass]

Hi Rob,

On 23 October 2015 at 12:35, Rob Herring <robherring2 at gmail.com> wrote:
> On Mon, Oct 19, 2015 at 5:09 PM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Rob,
>>
>> On 19 October 2015 at 14:14, Rob Herring <robherring2 at gmail.com> wrote:
>>> On Wed, Oct 14, 2015 at 11:55 AM, Sergey Temerkhanov
>>> <s.temerkhanov at 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 at gmail.com>
>>>> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla at cavium.com>
>>>>
>>>> Reviewed-by: Simon Glass <sjg at 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.

I don't see that this is a requirement. Also I don't think it makes sense.

U-Boot and Linux have quite different field-upgrade cycles. It is
quite common to update the kernel without updating U-Boot, and vice
versa. Some platforms will never update U-Boot. Some platforms have
U-Boot in one medium (sometimes even read-only) and Linux in another.
When updating the kernel I would expect the kernel device tree to be
updated also - e.g. a new FIT image containing the kernel and device
tree files. This is because we may have new drivers or enhanced
features there were not defined in the earlier device tre.

When updating U-Boot I would expect U-Boot's device tree to update
also, without affecting the one passed to the kernel. Similar to the
above there may be new features or enhancements that require this.

If there is ever a stand-alone repository then we can revisit this
discussion, but I doubt it makes much different for U-Boot at least,
which requires the device tree to complete its build. Maybe something
has changed recently to suggest things will go that way, but as far as
I recall it has been talked about for 4 years.

It should be possible for the U-Boot project to decide how it uses device tree.

Regards,
Simon