From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 13 Apr 2016 18:49:58 -0400 Subject: [U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable In-Reply-To: <570ECA5E.8060301@suse.de> References: <1460551699-30796-1-git-send-email-afaerber@suse.de> <570E41C0.1010904@suse.de> <570E665F.405@wwwdotorg.org> <570E6B19.1090402@suse.de> <570E7B17.9030701@wwwdotorg.org> <20160413221759.GN13577@bill-the-cat> <570ECA5E.8060301@suse.de> Message-ID: <20160413224958.GQ13577@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Apr 14, 2016 at 12:38:22AM +0200, Alexander Graf wrote: > > > On 14.04.16 00:17, Tom Rini wrote: > > On Wed, Apr 13, 2016 at 07:21:27PM +0200, Alexander Graf wrote: > >> > >> > >>> Am 13.04.2016 um 19:00 schrieb Stephen Warren : > >>> > >>>> On 04/13/2016 09:51 AM, Alexander Graf wrote: > >>>>> On 04/13/2016 05:31 PM, Stephen Warren wrote: > >>>>>> On 04/13/2016 06:55 AM, Andreas F?rber wrote: > >>>>>>> Am 13.04.2016 um 14:48 schrieb Andreas F?rber: > >>>>>>> The 4.5.0 kernel cannot cope with U-Boot's internal device tree, and > >>>>>>> the > >>>>>>> distro boot commands are looking for $fdtfile, so provide it to avoid > >>>>>>> having users supply a dumb boot.scr doing a setenv fdtfile ...; boot, > >>>>>>> defeating the purpose of generic EFI boot. > >>>>>>> > >>>>>>> Cc: Stephen Warren > >>>>>>> Cc: Alexander Graf > >>>>>>> Signed-off-by: Andreas F?rber > >>>>>>> --- > >>>>>>> include/configs/jetson-tk1.h | 4 ++++ > >>>>>>> 1 file changed, 4 insertions(+) > >>>>>>> > >>>>>>> diff --git a/include/configs/jetson-tk1.h > >>>>>>> b/include/configs/jetson-tk1.h > >>>>>>> index 59dbb20..82a4be4 100644 > >>>>>>> --- a/include/configs/jetson-tk1.h > >>>>>>> +++ b/include/configs/jetson-tk1.h > >>>>>>> @@ -63,6 +63,10 @@ > >>>>>>> /* General networking support */ > >>>>>>> #define CONFIG_CMD_DHCP > >>>>>>> > >>>>>>> +#define BOARD_EXTRA_ENV_SETTINGS \ > >>>>>>> + "fdtfile=tegra124-jetson-tk1.dtb\0" \ > >>>>>>> + "" > >>>>>> > >>>>>> Is there any more intelligent solution than doing this for each board? > >>>>> > >>>>> Yes, the distro boot scripts shouldn't be using $fdtfile > >>>>> unconditionally since it's not guaranteed to be set. The model is that > >>>>> boot scripts determine the FDT filename, and $fdtfile is an optional > >>>>> override. > >>>> > >>>> The point of all of the efi magic is that we can completely get rid of > >>>> boot scripts. Boards use the distro scripts, everything else gets > >>>> implicitly detected and executed. The way other boards deal with common > >>>> code mapping into separate boards is to either implement a "findfdt" > >>>> scriptlet or directly write the fdtfile variable (e.g. beaglebone) in > >>>> board init (e.g. rpi). > >>>> > >>>>> It looks like the hard-coded use of $fdtfile was added into the EFI > >>>>> path, which I didn't get to review, and which shouldn't be enabled by > >>>>> default but unfortunately is. > >>>> > >>>> s/un// :) > >>>> > >>>> Just imagine a world where people don't have to worry about bootloaders > >>>> anymore. Things would "just work". You plug in a usb stick, it comes up, > >>>> boots Linux, everthing goes without anyone touching boot scripts, > >>>> downloading board specific files, etc. You could get a random > >>>> distribution from a common download page from somewhere and just run it. > >>>> > >>>> Well, you can also just look at any random x86 system. They get at least > >>>> that part pretty right these days. > >>> > >>> Well, you can also get the same benefit using extlinux.conf, and without relying on EFI:-P > >>> > >>> Anyway, nothing in your benefits-of-EFI statement implies that relying on $fdtfile being set is correct. That's a new requirement that didn't exist before. Either the requirement needs to be removed (e.g. using a default FDT filename such as "${soc}-${board}${boardver}.dts") or only enabling this functionality on boards that do set $fdtfile, since it relies on that. > >> > >> On boards that fon't set fdtfile we just don't load it, because we can't find the file. So you're getting a working grub2 payload, but Linux gets an empty device tree unless you pass it in using the grub2 "devicetree" command. > > > > Well, hold up. We are _not_ at the point right now where the device > > tree we use is the kernel device tree. We're trying to make sure there > > If I understand correctly that depends on the board. On some systems > like the pine64 the device tree is just a copy of the Linux device tree. > I don't see why we couldn't aim for that model going forward. > > And with that I'm not saying "this is how it works today". If you want a > reasonable working system today you probably need to provide your own > device tree at a well-known location. But thinking mid-term I don't see > why a board author couldn't just keep the U-Boot device tree and the > Linux device tree in sync. > > Again, none of this is mandatory, required, or even recommended today. I > just want to make sure that people see the potential and make the (in my > opinion) best path be the easiest one to take :). Yes, the long term goal is that everyone be able to share the same canonical device tree, bootloader and OS. And that's making progress all around and I think devicetree.org will help there too. But the problem I want to make sure you see is that you can't just use the kernel device tree on U-Boot and have it work on anything that does DM+SPL. The u-boot,dm-pre-reloc flag is required, isn't going to be in the kernel tree and is still something that needs sorting out. > > are no cases of incompatible bindings, and we're trying to make sure we > > play nicely and get the canonical device tree to have everything we > > need. But it seems risky at best to assume the loaded tree is the right > > tree for the kernel. > > So would you prefer if the board manually specifies it as the right tree > for the kernel? I'm not sure that buys us anything really. If it's the > wrong one, booting will fail. I'm saying I think today unless you know you've loaded a known correct for the kernel device tree into $fdtaddr you shouldn't use that for the kernel. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: