| Message ID | 1439303153-12171-1-git-send-email-sjg@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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) > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > 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. Regards, Lucas
On 08/11/2015 11:05 AM, Lucas Stach wrote: > Hi Simon, > > why did you send this to the Tegra ML? At my request, so that the DT changes could be reviewed by the kernel DT reviewers and added to the copy of the DT files in the kernel source tree if approved. My assertion is that DT content should be independent of SW stack. Or put another way, all SW stacks should use the same DT content. As such, if these properties are needed by U-Boot, and contained in the copy of the DT files in the U-Boot source tree, they should also be present in the copy of the DT files in the kernel source tree, so the two do not become out of sync. > 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) >> 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.
Am Dienstag, den 11.08.2015, 11:29 -0600 schrieb Stephen Warren: > On 08/11/2015 11:05 AM, Lucas Stach wrote: > > Hi Simon, > > > > why did you send this to the Tegra ML? > > At my request, so that the DT changes could be reviewed by the kernel DT > reviewers and added to the copy of the DT files in the kernel source > tree if approved. > This doesn't really answer the question why it was sent to the Tegra list if it is an RPi change, but that's just a side note. > My assertion is that DT content should be independent of SW stack. Or > put another way, all SW stacks should use the same DT content. As such, > if these properties are needed by U-Boot, and contained in the copy of > the DT files in the U-Boot source tree, they should also be present in > the copy of the DT files in the kernel source tree, so the two do not > become out of sync. > I agree with that overall goal to have a common DT base between different software stacks. After all I lobbied for keeping the Tegra pinctrl setting in the DT even though Linux doesn't use them any more. For my question below I honestly want an answer as to why U-Boot needs those DT changes and why it can't work with the current DT contents. It's really just the same question we also have to answer for each and every DT addition that we do for Linux. Regards, Lucas > > 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) > > >> 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. > >
Hi Lucas, On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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) >> >> Signed-off-by: Simon Glass <sjg@chromium.org> >> --- >> >> 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. 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. As to why upstream should accept it, my understanding of upstream is that people can send patches to it and in fact are encouraged to do so, to avoid misunderstandings and duplication. The device tree files are stored in Linux so any binding or source file changes should end up there. Otherwise the files tend to diverge and we end up with multiple bindings and multiple versions of the same source file. Regards, Simon
-linux-tegra Hi, On 12 August 2015 at 07:21, Simon Glass <sjg@chromium.org> wrote: > Hi Lucas, > > On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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) >>> >>> Signed-off-by: Simon Glass <sjg@chromium.org> >>> --- >>> >>> 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. > > 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. > > As to why upstream should accept it, my understanding of upstream is > that people can send patches to it and in fact are encouraged to do > so, to avoid misunderstandings and duplication. The device tree files > are stored in Linux so any binding or source file changes should end > up there. Otherwise the files tend to diverge and we end up with > multiple bindings and multiple versions of the same source file. Is the above explanation sufficient? Will this patch be applied? Regards, Simon
On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass <sjg@chromium.org> wrote: > -linux-tegra > > Hi, > > On 12 August 2015 at 07:21, Simon Glass <sjg@chromium.org> wrote: >> Hi Lucas, >> >> On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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. >>>> >>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>> --- >>>> >>>> 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? >> 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. >> As to why upstream should accept it, my understanding of upstream is >> that people can send patches to it and in fact are encouraged to do >> so, to avoid misunderstandings and duplication. The device tree files >> are stored in Linux so any binding or source file changes should end >> up there. Otherwise the files tend to diverge and we end up with >> multiple bindings and multiple versions of the same source file. > > Is the above explanation sufficient? Will this patch be applied? Well, for starters bindings need to be documented, so you need to send this as a binding doc with this detail. Rob
On 08/12/2015 07:21 AM, Simon Glass wrote: > Hi Lucas, > > On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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) >>> >>> Signed-off-by: Simon Glass <sjg@chromium.org> >>> --- >>> >>> 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. > > 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. > > As to why upstream should accept it, my understanding of upstream is > that people can send patches to it and in fact are encouraged to do > so, to avoid misunderstandings and duplication. The device tree files > are stored in Linux so any binding or source file changes should end > up there. Otherwise the files tend to diverge and we end up with > multiple bindings and multiple versions of the same source file. On many platforms, we have U-Boot SPL running first, then the main U-Boot. The main U-Boot binary contains both the code to do the relocation and the binary that runs after relocation. It seems like it'd be simpler to split these up into 3 binaries that each do a single job: 1) SPL, roughly as-is today (varying jobs depending on platform) 2) Relocator, which does nothing but work out where to copy U-Boot, memcpy()s it there, relocates the image (if not PIE), and jumps to it. 3) The main U-Boot. Item (2) above should be simple enough that it can use a very simple debug mechanism rather like DEBUG_LL in the Linux kernel. Similar to what Rob mentioned in his email. Item (3) could use DM and DT/ACPI/... to get device information in a complete non-hard-coded manner.
Hi Rob, On 14 August 2015 at 14:29, Rob Herring <robherring2@gmail.com> wrote: > On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass <sjg@chromium.org> wrote: >> -linux-tegra >> >> Hi, >> >> On 12 August 2015 at 07:21, Simon Glass <sjg@chromium.org> wrote: >>> Hi Lucas, >>> >>> On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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@chromium.org> >>>>> --- >>>>> >>>>> 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. 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. > >>> 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. 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. > >>> As to why upstream should accept it, my understanding of upstream is >>> that people can send patches to it and in fact are encouraged to do >>> so, to avoid misunderstandings and duplication. The device tree files >>> are stored in Linux so any binding or source file changes should end >>> up there. Otherwise the files tend to diverge and we end up with >>> multiple bindings and multiple versions of the same source file. >> >> Is the above explanation sufficient? Will this patch be applied? > > Well, for starters bindings need to be documented, so you need to send > this as a binding doc with this detail. OK I'll update the patch and resend it. Regards. Simon
Hi Stephen, On 14 August 2015 at 21:46, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 08/12/2015 07:21 AM, Simon Glass wrote: >> Hi Lucas, >> >> On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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) >>>> >>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>> --- >>>> >>>> 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. >> >> 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. >> >> As to why upstream should accept it, my understanding of upstream is >> that people can send patches to it and in fact are encouraged to do >> so, to avoid misunderstandings and duplication. The device tree files >> are stored in Linux so any binding or source file changes should end >> up there. Otherwise the files tend to diverge and we end up with >> multiple bindings and multiple versions of the same source file. > > On many platforms, we have U-Boot SPL running first, then the main > U-Boot. The main U-Boot binary contains both the code to do the > relocation and the binary that runs after relocation. It seems like it'd > be simpler to split these up into 3 binaries that each do a single job: > > 1) SPL, roughly as-is today (varying jobs depending on platform) > > 2) Relocator, which does nothing but work out where to copy U-Boot, > memcpy()s it there, relocates the image (if not PIE), and jumps to it. > > 3) The main U-Boot. > > Item (2) above should be simple enough that it can use a very simple > debug mechanism rather like DEBUG_LL in the Linux kernel. Similar to > what Rob mentioned in his email. > > Item (3) could use DM and DT/ACPI/... to get device information in a > complete non-hard-coded manner. This comment does no seem to relate to my patch. We could certainly re-architect U-Boot to work this way. There are lot of reasons why U-Boot works as it does and many platforms don't have SPL. Relating what you said to the current U-Boot, your item (2) is analogous to us not setting up driver model before relocation at all, and just having a debug UART. That's a huge topic though, well beyond the scope of my original patch. I think it would be better for you to start a thread on the U-Boot mailing list with your proposal. At least on x86 (which has no SPL) there are all sorts of things that currently happen before relocation. Regards, Simon
On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Rob, > > On 14 August 2015 at 14:29, Rob Herring <robherring2@gmail.com> wrote: >> On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass <sjg@chromium.org> wrote: >>> -linux-tegra >>> >>> Hi, >>> >>> On 12 August 2015 at 07:21, Simon Glass <sjg@chromium.org> wrote: >>>> Hi Lucas, >>>> >>>> On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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@chromium.org> >>>>>> --- >>>>>> >>>>>> 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
Hi Rob, On 25 August 2015 at 10:22, Rob Herring <robherring2@gmail.com> wrote: > On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Rob, >> >> On 14 August 2015 at 14:29, Rob Herring <robherring2@gmail.com> wrote: >>> On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass <sjg@chromium.org> wrote: >>>> -linux-tegra >>>> >>>> Hi, >>>> >>>> On 12 August 2015 at 07:21, Simon Glass <sjg@chromium.org> wrote: >>>>> Hi Lucas, >>>>> >>>>> On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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@chromium.org> >>>>>>> --- >>>>>>> >>>>>>> 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. I'm struggling to understand the value of this statement - is it just philosophizing? I do have a real problem and would like to solve it. Please make a concrete suggestion. > >> 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? The debug UART is generally disabled and has very limited use. It is hard-coded and does not use the device tree. I mentioned it because you asked "How do you debug the DM itself". You dropped that from the context so this thread is now quite confusing. Let's ignore the debug UART. > >>>>> 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. What are you getting at here? If I move to a new kernel and still use an old device tree I may be missing features, or fail to boot. Don't do that! But do we need to talk about this? How does this affect my patch? > >> 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. OK so let's ignore the GPIO example. After reading your email I am none the wiser about what you are suggesting. This is not a screwy case. Every board will have a console. In some cases it is inside a 'soc {' node and in some cases it is not. The pure solution would be to mark every UART node with u-boot,dm-pre-reloc and we can do that if you prefer. It isn't necessary though for the reasons I previously explained. It seems reasonable that U-Boot should be able to add private properties to the device tree, intended for U-Boot, just as Linux does. What is the problem here? If are you asking for a generic property that any bootloader could use, to locate what is needed to bring up the serial console then please propose something and I can take a look. But I know that not all bootloaders work like U-Boot (small space-constrained SPL, relocatable main loader, try to output something on a serial port as early as possible). How can we resolve this so that the device tree files in U-Boot and Linux can stay in sync? Regards, Simon
Hi, On Friday, 28 August 2015, Simon Glass <sjg@chromium.org> wrote: > > Hi Rob, > > On 25 August 2015 at 10:22, Rob Herring <robherring2@gmail.com> wrote: > > On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass <sjg@chromium.org> wrote: > >> Hi Rob, > >> > >> On 14 August 2015 at 14:29, Rob Herring <robherring2@gmail.com> wrote: > >>> On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass <sjg@chromium.org> wrote: > >>>> -linux-tegra > >>>> > >>>> Hi, > >>>> > >>>> On 12 August 2015 at 07:21, Simon Glass <sjg@chromium.org> wrote: > >>>>> Hi Lucas, > >>>>> > >>>>> On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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@chromium.org> > >>>>>>> --- > >>>>>>> > >>>>>>> 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. > > I'm struggling to understand the value of this statement - is it just > philosophizing? I do have a real problem and would like to solve it. > Please make a concrete suggestion. > > > > >> 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? > > The debug UART is generally disabled and has very limited use. It is > hard-coded and does not use the device tree. I mentioned it because > you asked "How do you debug the DM itself". You dropped that from the > context so this thread is now quite confusing. > > Let's ignore the debug UART. > > > > >>>>> 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. > > What are you getting at here? If I move to a new kernel and still use > an old device tree I may be missing features, or fail to boot. Don't > do that! > > But do we need to talk about this? How does this affect my patch? > > > > >> 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. > > OK so let's ignore the GPIO example. > > After reading your email I am none the wiser about what you are suggesting. > > This is not a screwy case. Every board will have a console. In some > cases it is inside a 'soc {' node and in some cases it is not. The > pure solution would be to mark every UART node with > u-boot,dm-pre-reloc and we can do that if you prefer. It isn't > necessary though for the reasons I previously explained. > > It seems reasonable that U-Boot should be able to add private > properties to the device tree, intended for U-Boot, just as Linux > does. What is the problem here? > > If are you asking for a generic property that any bootloader could > use, to locate what is needed to bring up the serial console then > please propose something and I can take a look. But I know that not > all bootloaders work like U-Boot (small space-constrained SPL, > relocatable main loader, try to output something on a serial port as > early as possible). > > How can we resolve this so that the device tree files in U-Boot and > Linux can stay in sync? It doesn't look like this thread has made any progress. I'll redo the patch with a binding file and try again. Regards, Simon
On 08/28/2015 11:27 AM, Simon Glass wrote: > Hi Rob, > > On 25 August 2015 at 10:22, Rob Herring <robherring2@gmail.com> wrote: >> On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Rob, >>> >>> On 14 August 2015 at 14:29, Rob Herring <robherring2@gmail.com> wrote: >>>> On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass <sjg@chromium.org> wrote: >>>>> -linux-tegra >>>>> >>>>> Hi, >>>>> >>>>> On 12 August 2015 at 07:21, Simon Glass <sjg@chromium.org> wrote: >>>>>> Hi Lucas, >>>>>> >>>>>> On 11 August 2015 at 11:05, Lucas Stach <dev@lynxeye.de> 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) [... discussion of u-boot,dm-pre-reloc property] >>>> 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. > > What are you getting at here? If I move to a new kernel and still use > an old device tree I may be missing features, or fail to boot. Don't > do that! One of the central points of DT is that it is an ABI. As such, moving to a new kernel and continuing to use the same old DTB *MUST NOT* break anything. Of course, you won't get any features enabled/described in any new DT if you don't use it. ... > After reading your email I am none the wiser about what you are suggesting. > > This is not a screwy case. Every board will have a console. In some > cases it is inside a 'soc {' node and in some cases it is not. The > pure solution would be to mark every UART node with > u-boot,dm-pre-reloc and we can do that if you prefer. It isn't > necessary though for the reasons I previously explained. > > It seems reasonable that U-Boot should be able to add private > properties to the device tree, intended for U-Boot, just as Linux > does. What is the problem here? Why is that reasonable? DT is intended to describe the HW. It is supposed to be OS-agnostic. Having U-Boot-specific properties completely goes against that. What Linux-specific properties are you referring to? The only one I recall you mentioning (although I'm missing a lot of sleep right now) is the keycodes in the input binding. While the DT property name for those is linux,... and the values happen to match internal Linux numbering, there's absolutely nothing Linux specific about the /concept/ of a keycode, and some numbering scheme had to be picked. There's nothing practical or conceptual stopping any other OS/SW-stack from translating those Linux IDs into something internally meaningful. Conversely, the concept of e.g. "u-boot,dm-pre-reloc" is not something that translates at all to any other OS/WW-stack.
Hi! > 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) > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > arch/arm/boot/dts/bcm2835.dtsi | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > @@ -16,6 +17,7 @@ > #size-cells = <1>; > ranges = <0x7e000000 0x20000000 0x02000000>; > dma-ranges = <0x40000000 0x00000000 0x20000000>; > + u-boot,dm-pre-reloc; > Given low ammount of memory available for SPL, such stuff is going to be neccessary. Should it have more generic name... "critical-for-early-boot" ? Best regards, Pavel
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; timer@7e003000 { compatible = "brcm,bcm2835-system-timer"; @@ -92,7 +94,7 @@ #interrupt-cells = <2>; }; - uart@7e201000 { + uart: uart@7e201000 { compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell"; reg = <0x7e201000 0x1000>; interrupts = <2 25>;
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) Signed-off-by: Simon Glass <sjg@chromium.org> --- arch/arm/boot/dts/bcm2835.dtsi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)