Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752183AbbHNSfG (ORCPT ); Fri, 14 Aug 2015 14:35:06 -0400 Received: from mail-qk0-f175.google.com ([209.85.220.175]:36435 "EHLO mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbbHNSfD (ORCPT ); Fri, 14 Aug 2015 14:35:03 -0400 MIME-Version: 1.0 In-Reply-To: References: <1439303153-12171-1-git-send-email-sjg@chromium.org> <1439312701.2451.3.camel@lynxeye.de> From: Simon Glass Date: Fri, 14 Aug 2015 12:34:41 -0600 X-Google-Sender-Auth: AOqPWYvYIKgMnyM1H2bylHKrtPk Message-ID: Subject: Re: [PATCH] arm: rpi: Device tree modifications for U-Boot To: Lucas Stach Cc: lak , Stephen Warren , 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3295 Lines: 85 -linux-tegra Hi, On 12 August 2015 at 07:21, 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. Is the above explanation sufficient? Will this patch be applied? Regards, Simon -- 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/