[PATCH] cmd: fdt: skip board specific fixup using env variable

[Tom Rini <trini@konsulko.com>]

On Thu, Jan 28, 2021 at 08:15:33AM +0000, Wasim Khan (OSS) wrote:
> Hi Tom,
> 
> > -----Original Message-----
> > From: Tom Rini <trini@konsulko.com>
> > Sent: Wednesday, January 27, 2021 7:41 PM
> > To: Wasim Khan (OSS) <wasim.khan@oss.nxp.com>
> > Cc: sjg at chromium.org; t-kristo at ti.com; Varun Sethi <V.Sethi@nxp.com>; u-
> > boot at lists.denx.de; Wasim Khan <wasim.khan@nxp.com>
> > 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 <wasim.khan@nxp.com>
> > >
> > > 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 <wasim.khan@nxp.com>
> > > ---
> > >  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: <https://lists.denx.de/pipermail/u-boot/attachments/20210129/d2c37157/attachment.sig>