All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] cmd: fdt: skip board specific fixup using env variable
Date: Thu, 4 Feb 2021 08:20:29 -0500	[thread overview]
Message-ID: <20210204132029.GW10169@bill-the-cat> (raw)
In-Reply-To: <VE1PR04MB67028D93A3C579627D37A2BE90B39@VE1PR04MB6702.eurprd04.prod.outlook.com>

On Thu, Feb 04, 2021 at 07:19:21AM +0000, Wasim Khan (OSS) wrote:
> Hi Tom,
> 
> > -----Original Message-----
> > From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Tom Rini
> > Sent: Saturday, January 30, 2021 12:53 AM
> > 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
> > 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@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!
> 
> 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>

      reply	other threads:[~2021-02-04 13:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 13:09 [PATCH] cmd: fdt: skip board specific fixup using env variable Wasim Khan
2021-01-27 14:10 ` Tom Rini
2021-01-28  8:15   ` Wasim Khan
2021-01-29 19:23     ` Tom Rini
2021-02-04  7:19       ` Wasim Khan
2021-02-04 13:20         ` Tom Rini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210204132029.GW10169@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.