Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753249AbbHODqU (ORCPT ); Fri, 14 Aug 2015 23:46:20 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:38166 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751722AbbHODqS (ORCPT ); Fri, 14 Aug 2015 23:46:18 -0400 Message-ID: <55CEB607.7060908@wwwdotorg.org> Date: Fri, 14 Aug 2015 21:46:15 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Simon Glass , Lucas Stach CC: "linux-tegra@vger.kernel.org" , lak , Stephen Warren , Russell King , Lee Jones , Devicetree Discuss , Kumar Gala , lk , Ian Campbell , Rob Herring , linux-rpi-kernel@lists.infradead.org, Pawel Moll , Mark Rutland Subject: Re: [PATCH] arm: rpi: Device tree modifications for U-Boot References: <1439303153-12171-1-git-send-email-sjg@chromium.org> <1439312701.2451.3.camel@lynxeye.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3956 Lines: 95 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/