On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass <sjg@xxxxxxxxxxxx> wrote:
> Hi Rob,
>
> On 14 August 2015 at 14:29, Rob Herring <robherring2@xxxxxxxxx> wrote:
>> On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass <sjg@xxxxxxxxxxxx> wrote:
>>> -linux-tegra
>>>
>>> Hi,
>>>
>>> On 12 August 2015 at 07:21, Simon Glass <sjg@xxxxxxxxxxxx> wrote:
>>>> Hi Lucas,
>>>>
>>>> On 11 August 2015 at 11:05, Lucas Stach <dev@xxxxxxxxxx> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> why did you send this to the Tegra ML?
>>>>>
>>>>> Am Dienstag, den 11.08.2015, 08:25 -0600 schrieb Simon Glass:
>>>>>> This updates the device tree from the kernel version to something suitable
>>>>>> for U-Boot:
>>>>>>
>>>>>> - Add stdout-path alias for console
>>>>>> - Mark the /soc node to be available pre-relocation so that the early
>>>>>> serial console works (we need the 'ranges' property to be available)
>>
>> I find it quite strange that you must explicitly enable the parent
>> node, but not the uart node.
>
> U-Boot tries hard to find and bind the UART using the stdout-path
> link. I would like to add it in the UART node also but we were able to
> work around it so far.
>
>>
>>>>>>
>>>>>> Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx>
>>>>>> ---
>>>>>>
>>>>>> arch/arm/boot/dts/bcm2835.dtsi | 4 +++-
>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
>>>>>> index 301c73f..bd6bff6 100644
>>>>>> --- a/arch/arm/boot/dts/bcm2835.dtsi
>>>>>> +++ b/arch/arm/boot/dts/bcm2835.dtsi
>>>>>> @@ -8,6 +8,7 @@
>>>>>>
>>>>>> chosen {
>>>>>> bootargs = "earlyprintk console=ttyAMA0";
>>>>>> + stdout-path = &uart;
>>>>>> };
>>>>>>
>>>>>> soc {
>>>>>> @@ -16,6 +17,7 @@
>>>>>> #size-cells = <1>;
>>>>>> ranges = <0x7e000000 0x20000000 0x02000000>;
>>>>>> dma-ranges = <0x40000000 0x00000000 0x20000000>;
>>>>>> + u-boot,dm-pre-reloc;
>>>>>
>>>>> Why do you need this and why should upstream carry your favourite
>>>>> bootloaders configuration? This is in no way hardware description.
>>>>
>>>> I'm not sure how much you know about U-Boot, so let me know if you
>>>> need more info.
>>>>
>>>> U-Boot normally starts up by setting up its serial UART and displaying
>>>> a banner message. At this stage typically only a few devices are
>>>> initialised (e.g. maybe just the UART). It then relocates itself to
>>>> the top of memory and starts up all the devices. It throws away any
>>>> previous devices that it set up before relocation and starts again.
>>>>
>>>> U-Boot uses a thing called driver model (dm) which handles driver
>>>> binding and probing. Driver model has the device tree and would
>>>> normally scan through it and create devices for everything it finds.
>>
>> How do you debug the DM itself? It seems like you still would need
>> something earlier for debug like earlycon in the kernel. u-boot DM is
>> probably simple enough you can get away with using it early, but you
>> often can't as the complexity increases. Ultimately you need something
>> simple that just hits all the registers needed to get characters out.
>> What happens when you add pinmux, clocks, PMIC, power domains, etc. to
>> the DM and they all become dependencies for the UART?
>
> This doesn't seem like a device tree binding question but let me try
> to answer it.
>
> This is a problem - one of the challenges of driver model is that the
> UART gets further away from the reset vector.
This is a common problem for any complex embedded system. Nothing
special about u-boot here. So either we don't need anything because
everyone else has dealt with the problem in some way or we need a
common solution because we all have this problem.
> In U-Boot there is a single debug UART which can be supported by the
> various serial drivers (only one can be selected on each platform).
> There is a special debug_uart_init() function which is supposed to set
> up the UART for that platform. After that, and until driver model UART
> is up, console output can go through the debug UART.
So you don't need this for the common case of an early console, but
only for platforms needing some other platform specific setup?
>>>> Before relocation we don't need every device. Also the CPU is often
>>>> running slowly, perhaps without the cache enabled. SDRAM may not be
>>>> available yet so space is short. We want to avoid starting up things
>>>> that will not be used.
>>>>
>>>> So this property indicates that the device is needed before relocation
>>>> and should be set up by driver model. We need it to avoid a very slow
>>>> and memory-hungry startup.
>>
>> Can't the need for that property change over time? Either as more
>> drivers are converted to DM you need to add this or you add some
>> feature that depends on a driver (e.g. get a board rev or boot mode
>> from GPIO). You would have backwards compatibility issues with this.
>> I'm somewhat less worried about that for u-boot as we should be
>> bundling the dtb and bootloader rather than kernel and dtb. For the
>> UART, you can just get which UART to initialize early from
>> stdout-path. But for other cases, couldn't you just have the platform
>> provide the list of needed drivers. Then when u-boot needs change, you
>> just change u-boot.
>
> Yes U-Boot and its device tree are normally built from the same tree
> at the same time. We don't expect to have to support an older or newer
> device tree with the same U-Boot binary. So I don't see a problem
> here.
My point is that if I had to pick how bootloader+dtb+kernel are
bundled or not, I would rather see the dtb in sync with the bootloader
rather than the kernel. But I can't decide that for everyone and
neither can you. You still have a compatibility problem and that has
to be addressed.
> The UART should have as few dependencies as possible. But if the
> particular platform needs to check a GPIO to find out the UART number
> (i.e. stdout-path cannot be used) then we would need to support that
> case. It hasn't come up yet but it might. I certainly see platforms
> where we need some other nodes before relocation and would like to
> mark them as such. But I hope that for UART we can generally use
> stdout-path.
>
> The list of drivers doesn't help that much. What would I do with such
> a list, and where would I keep such platform-specific information
> other than in the device tree? It seems much simpler to hold the
> information about what the platform needs to get through early boot in
> one place. Then we have just a few lines of generic code to deal with
> it.
If you need certain drivers such as gpio, then you obviously have some
board specific code using those drivers already. If you can tell the
DM which devices to enumerate via DT, you can also tell the DM with C
code.
While doing everything generically without board code is nice, we
should only do that for the common cases and handle the screwy cases
with board code.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
