From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 29 Jan 2021 14:23:21 -0500 Subject: [PATCH] cmd: fdt: skip board specific fixup using env variable In-Reply-To: References: <20210127130948.4038705-1-wasim.khan@oss.nxp.com> <20210127141035.GB7530@bill-the-cat> Message-ID: <20210129192321.GC7530@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, Jan 28, 2021 at 08:15:33AM +0000, Wasim Khan (OSS) wrote: > Hi Tom, > > > -----Original Message----- > > From: Tom Rini > > Sent: Wednesday, January 27, 2021 7:41 PM > > To: Wasim Khan (OSS) > > Cc: sjg at chromium.org; t-kristo at ti.com; Varun Sethi ; u- > > boot at lists.denx.de; Wasim Khan > > Subject: Re: [PATCH] cmd: fdt: skip board specific fixup using env variable > > > > On Wed, Jan 27, 2021 at 02:09:48PM +0100, Wasim Khan wrote: > > > > > From: Wasim Khan > > > > > > Sometimes it is useful to boot OS with already fixed-up device tree. > > > Check for env variable 'skip_board_fixup' > > > before calling ft_board_setup(). > > > Current behaviour is unchanged, additionally user can set > > > skip_board_fixup to 1 to skip the fixup. > > > > > > Signed-off-by: Wasim Khan > > > --- > > > common/image-fdt.c | 17 ++++++++++++----- > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > Can you provide a specific example or two here? Thanks! > > Thank you for your comments. > > Recently I faced issue where Linux crash in PCIe was observed in customer's env. > Whereas same Linux was booting fine in my environment. After debugging we found that U-boot was doing fixup based on SVR value. SVR check was failing in customer's env because of different SoC personality which was causing the crash in OS. > So I thought it is good idea to have an option to bypass U-boot fixup and use an already fixed-up device tree so that we can quickly check if the problem is in OS or it is caused because of missed/wrong fixup from Uboot. > > Another use case I can think of is suppose if we want to introduce a new dtb fixup , we can directly add the change in a fixed-up device tree, do all experiments and once validated thoroughly , we can do the same change via Uboot fixup. OK, I can see how this can be useful in some circumstances, thanks. What I'd like to see is updating checkpatch.pl to have a check that we aren't setting this by default in environments (something like the check that exists now for (fdt|initrd)_high=0xffffffff should be a good reference) as my worry is that someone will decide that's how to work-around some issue and we'll end up in another nightmare down the road of uncorrected dtbs causing other problems. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: