public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox