All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Humphreys <j-humphreys@ti.com>
To: Andrew Davis <afd@ti.com>, Manorit Chawdhry <m-chawdhry@ti.com>
Cc: Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>,
	"Nishanth Menon" <nm@ti.com>, Roger Quadros <rogerq@kernel.org>,
	<vigneshr@ti.com>, <jonas@kwiboo.se>, <srk@ti.com>, <bb@ti.com>,
	<praneeth@ti.com>, <u-boot@lists.denx.de>,
	Roger Quadros <rogerq@kernel.org>,
	MD Danish Anwar <danishanwar@ti.com>
Subject: Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
Date: Thu, 4 Jan 2024 16:23:20 -0600	[thread overview]
Message-ID: <86il48wxev.fsf@udb0321960.dhcp.ti.com> (raw)
In-Reply-To: <7e7dde90-0711-4cce-b2ca-ab7369f36ae4@ti.com>

Andrew Davis <afd@ti.com> writes:

>>>>>>>>      * uEnv.txt processing
>>>>>>>
>>>>>>> What command can do this?
>>>>>>>
>>>>>>
>>>>>> run envboot;
>>>>>>
>>>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/mmc.env?ref_type=heads#L20
>>>>>
>>>>> This could be a new bootmeth which looks for uenv.txt on available
>>>>> devices. It might be better to put the env in a FIT or something with
>>>>> a checksum.
>> 
>> We use non-FIT boot as well for our non HS platforms, I think the new
>> bootmeth might be helpful as you mentioned, would have to look at this
>> more as I thought bootmeth is supposed to boot a platform at the end
>> only but it seems like here we'll be combining this bootmeth ( that'll
>> just import the env ) and then other bootmeth will actually boot Linux.
>> 
>
> As long as bootmeths can perform an action then continue with other
> bootmeths that could work. This might require complex logic though.
> For instance the uenv.txt bootmeth would only need run on some subset
> of available bootdevs, and it should scan all those devs for uenv.txt
> first, before the Linux finding bootmeths start.
>

It doesn't make sense to treat envboot as a bootmeth because it's really
not about a way of booting but more often just used to modify
environment variables before going through another boot flow (although
you could define/run env variables that performs it's own boot).  It may be
better to think of it as a preprocessing step before a bootflow scan.

Some other thoughts - envboot is more of a hacky way to solve things:
1) As we move more towards secure boot as the standard, we should
   understand what use cases the hacks are working around and properly
   support those use cases.
2) But I don't think we should just remove it altogether because it is a
   very powerful 'feature' during the development phases to try out
   changes without modifying/rebuilding/reflashing u-boot.
3) This is a TI feature.  Are others solving this need in a better way?

Jon

  reply	other threads:[~2024-01-04 22:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04 13:23 [PATCH 0/2] board: ti: am6x: Switch to standard boot Roger Quadros
2023-10-04 13:23 ` [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets Roger Quadros
2023-10-04 13:48   ` Andrew Davis
2023-10-04 13:54     ` Nishanth Menon
2023-10-05 14:19       ` Andrew Davis
2023-10-05 16:36         ` Tom Rini
2023-10-05 17:10           ` Nishanth Menon
2023-10-05 17:16             ` Nishanth Menon
2023-10-05 17:22               ` Andrew Davis
2023-10-05 17:28                 ` Nishanth Menon
2023-10-05 17:22               ` Simon Glass
2023-10-06  9:54                 ` Roger Quadros
2023-11-06  5:53                 ` Manorit Chawdhry
2023-11-06 15:31                   ` Tom Rini
2023-11-06 17:27                     ` Andrew Davis
2023-11-06 17:47                       ` Simon Glass
2023-11-06 18:05                         ` Andrew Davis
2023-11-28  9:31                           ` Manorit Chawdhry
2023-11-30  2:16                             ` Simon Glass
2023-11-30  2:45                           ` Simon Glass
2023-12-31 12:48                             ` Simon Glass
2024-01-02 14:58                               ` Andrew Davis
2024-01-04  7:52                                 ` Manorit Chawdhry
2024-01-04 15:55                                   ` Andrew Davis
2024-01-04 22:23                                     ` Jon Humphreys [this message]
2024-01-05  7:46                                     ` Manorit Chawdhry
2023-10-04 13:59   ` Nishanth Menon
2023-10-04 13:23 ` [PATCH 2/2] board: ti: am64x: Switch to standard boot flow Roger Quadros
2023-10-04 13:59   ` Nishanth Menon

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=86il48wxev.fsf@udb0321960.dhcp.ti.com \
    --to=j-humphreys@ti.com \
    --cc=afd@ti.com \
    --cc=bb@ti.com \
    --cc=danishanwar@ti.com \
    --cc=jonas@kwiboo.se \
    --cc=m-chawdhry@ti.com \
    --cc=nm@ti.com \
    --cc=praneeth@ti.com \
    --cc=rogerq@kernel.org \
    --cc=sjg@chromium.org \
    --cc=srk@ti.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=vigneshr@ti.com \
    /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.