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
next prev parent 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