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

Tom Rini trini at konsulko.com
Thu Feb 4 14:20:29 CET 2021


On Thu, Feb 04, 2021 at 07:19:21AM +0000, Wasim Khan (OSS) wrote:
> Hi Tom,
> 
> > -----Original Message-----
> > From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Tom Rini
> > Sent: Saturday, January 30, 2021 12:53 AM
> > To: Wasim Khan (OSS) <wasim.khan at oss.nxp.com>
> > Cc: sjg at chromium.org; t-kristo at ti.com; Varun Sethi <V.Sethi at nxp.com>; u-
> > boot at lists.denx.de
> > Subject: Re: [PATCH] cmd: fdt: skip board specific fixup using env variable
> > 
> > On Thu, Jan 28, 2021 at 08:15:33AM +0000, Wasim Khan (OSS) wrote:
> > > Hi Tom,
> > >
> > > > -----Original Message-----
> > > > From: Tom Rini <trini at konsulko.com>
> > > > Sent: Wednesday, January 27, 2021 7:41 PM
> > > > To: Wasim Khan (OSS) <wasim.khan at oss.nxp.com>
> > > > Cc: sjg at chromium.org; t-kristo at ti.com; Varun Sethi
> > > > <V.Sethi at nxp.com>; u- boot at lists.denx.de; Wasim Khan
> > > > <wasim.khan at 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 at 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 at 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!
> 
> Thanks, If I understood your comment correctly, you suggesting to add
> 'skip_board_fixup' to CONFIG_EXTRA_ENV_SETTINGS for all of our
> platforms and check its default value in checkpatch.pl , which must be
> 0 ?

I'm saying it can't be in CONFIG_EXTRA_ENV_SETTINGS by default, and
checkpatch.pl needs a test to complain if it's found.

-- 
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/20210204/5edad9bc/attachment.sig>


More information about the U-Boot mailing list