From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH] arm: rpi: Device tree modifications for U-Boot Date: Fri, 14 Aug 2015 21:46:15 -0600 Message-ID: <55CEB607.7060908@wwwdotorg.org> References: <1439303153-12171-1-git-send-email-sjg@chromium.org> <1439312701.2451.3.camel@lynxeye.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Simon Glass , Lucas Stach Cc: "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , lak , Stephen Warren , Russell King , Lee Jones , Devicetree Discuss , Kumar Gala , lk , Ian Campbell , Rob Herring , linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Pawel Moll , Mark Rutland List-Id: linux-tegra@vger.kernel.org On 08/12/2015 07:21 AM, Simon Glass wrote: > Hi Lucas, > > On 11 August 2015 at 11:05, Lucas Stach 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 >>> --- >>> >>> 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html