From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Date: Wed, 13 Apr 2016 20:02:24 +0200 Subject: [U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable In-Reply-To: <570E848E.2060408@wwwdotorg.org> References: <1460551699-30796-1-git-send-email-afaerber@suse.de> <570E41C0.1010904@suse.de> <570E665F.405@wwwdotorg.org> <570E803E.6050305@suse.de> <570E848E.2060408@wwwdotorg.org> Message-ID: <570E89B0.6070309@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 13.04.2016 um 19:40 schrieb Stephen Warren: > On 04/13/2016 11:22 AM, Andreas F?rber wrote: >> Am 13.04.2016 um 17:31 schrieb Stephen Warren: >>> 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. >>> >>> 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. >> >> As Alex described, you're entirely missing the point here. > > Well, that's because the point you're making is re: the benefits of EFI, > but that's not the point the patch is addressing nor the point I'm > objecting to. The patch addresses the need for all boards to set > $fdtfile. That is what I'm arguing about. The benefits of EFI aren't > relevant to this discussion. Alex was arguing about benefits, not me. I am specifically objecting to you telling me that the solution for a generic boot mechanism were for the user to supply custom board information. That has nothing to do with EFI as I underlined by referring to boot.scr as well. >> The EFI bootloader is an alternative to a board-specific script, not an >> addition. The loading logic is all in the U-Boot environment and it >> needs to know what device tree to use without the user telling it: >> >> a) master branch searches for $fdtfile in various prefixes on the >> current boot device partition. >> >> a') We're testing a variation where we load $fdtfile from a different >> partition on the same device (i.e., from ext4/btrfs rather that fat). >> >> b) A pending patch exposes the internal U-Boot device tree. >> >> The former is what we need to boot today. For openSUSE we get the .dtb >> files from rpm packages built from the kernel. >> >> The latter would match the Tianocore/Aptio model where all board info >> comes from the firmware exclusively. As reported elsewhere it does not >> yet work on this board with your DT though; you yourselves discussed >> about differing cell sizes and node names. >> >> Now during my EFI testing I had to repeatedly remember to interrupt >> U-Boot and type: >> >> setenv fdtfile tegra124-jetson-tk1.dtb > > You can always run "saveenv" here. Admittedly it's not a nice > user-experience to have to do that, but it's a workaround that would > work today. That does not help me as developer since the environment is getting updated with several of the EFI patches I'm testing. How would I know when to do that? And as soon as I do reset the environment to default it'll be gone again. Not all boards actually have saveenv anyway. >> boot >> >> until I got so annoyed that I figured out this patch to make it >> permanent. >> >> The hikey and some other boards got their variable renamed to fit >> standardized $fdtfile, for dragonboard410c I sent a similar patch. >> >> My above question was more precisely: Can we automate supplying the >> $fdtfile at tegra124-common.h or tegra-common.h level instead of as in >> this patch manually at jetson-tk1.h level where I happened to notice? > > As I mentioned in my other reply, it would be better if the EFI logic > handled this, rather than requiring every board to solve the problem > over and over. > >> The Raspberry Pi has been supplying $fdtfile just fine (modulo the rev >> B), so I don't understand why you'd be against it now. > > I have no objection to boards setting $fdtfile where they need to. Some > U-Boot boards support multiple HW, so it's a base requirement that the > code supply $fdtfile since there's no other way to know what the correct > value is. Other boards only operate on a single piece of HW, and we > shouldn't burden every config header (or other board-specific code/...) > with defining this value since there's a reasonable default that core > code could use. Rather, let's deal with it in some core code (not > per-SoC, but U-Boot-wide), for example using the code snippet I posted > in my other response. > >> Thanks, >> Andreas >> >> P.S. Without a standardized $fdtfile you can't have a standard boot.scr >> either, so the generic mechanism becomes moot. > > That's not true. the model there is to use ${soc} ${board} and > ${boardver} to construct it. I thought that was documented in > doc/README.distro, but perhaps I only mentioned it in commit > descriptions and scripts that build boot.scr, e.g.: > > https://github.com/NVIDIA/tegra-uboot-scripts/blob/master/gen-uboot-script.py#L133 > > > :-( See my other reply with another suggestion to be used at distro header level. But my point was that U-Boot != Linux filename in some cases. For example, the dragonboard410c is using dragonboard410c.dts but in Linux it's qcom/apq8016-sbc.dts. To make things worse, for arm64 they're in vendor subdirectories, for arm they're flat. It's not as easy as you make it sound. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg)