All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Lawnick <ml.lawnick@gmx.de>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH v2 1/2] efi: SPI NOR flash support
Date: Fri, 12 Feb 2021 10:17:21 +0100	[thread overview]
Message-ID: <056bd2c3-33d8-19d9-8f17-0364add76228@gmx.de> (raw)
In-Reply-To: <e651d634-18e1-7586-797d-a1fde270f1d4@gmx.de>

Am 11.02.2021 um 18:16 schrieb Heinrich Schuchardt:
> On 11.02.21 17:01, Michael Lawnick wrote:
>> Am 11.02.2021 um 15:04 schrieb Heinrich Schuchardt:
>>> On 11.02.21 13:50, Michael Lawnick wrote:
>>>> Hi,
>>>> Several boot parameters are stored in our SPI flash to configure the
>>>> systems for different use cases.
>>>
>>> I still do not understand why you need access in GRUB. You can read and
>>> write the SPI flash in U-Boot on your embedded system.
>>
>> In our latest system we get U-Boot from vendor. We try to change nothing
>> in it. To execute our boot management we let start GRUB as an EFI app.
>> The boot management needs configuration information which depends on
>> customer deployment scenario saved in SPI flash. It is our boot
>> management S/W which uses the EFI_SPI_NOR interface.
>
> You should consider upstreaming your board to mainline U-Boot.

This is in responsibility of the SoC vendor and as far as I know part of
contract.

>>
>>> Maybe you could provide a short example script showing how the new
>>> command would fit into the GRUB boot flow.
>>
>> The spi_nor command is more intended as an example application and for
>> test, not intended for real use. I have no problem to deactivate it by
>> default (put it to separate config module) or even completely remove it.
>> My real point is the driver to abstract away the H/W and take EFI into
>> use if available.
>
> U-Boot does not provide the EFI_SPI_NOR_FLASH_PROTOCOL. How will you
> ever use the spi_nor command?

After upstreaming of current version it will be.

> How about creating a UEFI application that can run
>
> * in the UEFI shell
> * directly from the UEFI boot manager
> * from GRUB EFI
>
> and upstreaming that utility to Tianocore EDK II which already has the
> protocol that you want to consume?

Even Tianocore depends on support by underlying boot software.
No gain.

All in all you vote against adding more EFI support to make GRUB more
H/W independent?
Whats about EFI-PCI which exists only in form of *.h files?

KR
Michael



      reply	other threads:[~2021-02-12  9:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05  8:58 [PATCH v2 1/2] efi: SPI NOR flash support Michael Lawnick
2021-02-05  9:02 ` [PATCH v2 2/2] efi: SPI NOR flash command line Michael Lawnick
2021-02-12  9:20   ` Michael Lawnick
2021-02-16 13:28     ` Paul Menzel
2021-02-11  7:36 ` [PATCH v2 1/2] efi: SPI NOR flash support Michael Lawnick
2021-02-11  7:36   ` Paul Menzel
2021-02-11  8:51   ` Heinrich Schuchardt
2021-02-11 12:50     ` Michael Lawnick
2021-02-11 14:04       ` Heinrich Schuchardt
2021-02-11 16:01         ` Michael Lawnick
2021-02-11 17:16           ` Heinrich Schuchardt
2021-02-12  9:17             ` Michael Lawnick [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=056bd2c3-33d8-19d9-8f17-0364add76228@gmx.de \
    --to=ml.lawnick@gmx.de \
    --cc=grub-devel@gnu.org \
    --cc=xypron.glpk@gmx.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.