From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilias Apalodimas Date: Thu, 2 Apr 2020 15:33:25 +0300 Subject: [PATCH 09/16] efi_loader: imply FAT, FAT_WRITE In-Reply-To: <20200401070403.GU11504@linaro.org> References: <20200327052800.11022-1-xypron.glpk@gmx.de> <20200327052800.11022-10-xypron.glpk@gmx.de> <20200331074433.GM11504@linaro.org> <0f574f72-cac2-7d4c-ff3e-442740333d66@gmx.de> <20200331235732.GO11504@linaro.org> <20200401011359.GR11504@linaro.org> <01de804a-5394-7d27-7e52-090873aa88f1@gmx.de> <20200401070403.GU11504@linaro.org> Message-ID: <20200402123325.GA371904@apalos.home> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Apr 01, 2020 at 04:04:04PM +0900, AKASHI Takahiro wrote: > > [...] > > Yes, we may add further stores later on. > > Why not now? > How will you generalize it? > > > Ilias wants to use the RPMB > > area of eMMC devices. > > I think that he plans to use RPMB as secure storage for Standalone MM. Sorry for my really delayed replies, but I was over my head with EDK2 and RPMB indeed :) So my implementation is orthogonal to this patchset and I do have some code that write UEFI variables on an RPMB via OP-TEE. > > > As an EFI system partition exists on any UEFI > > compatible device I think implementing this first is a valid approach. > > I don't deny your approach here, but > I expect that more generic framework for back storage be > implemented and FAT driver be on top of that. > Akashi has a point here. On the other hand can't we just make the store a callback in the future? So for example is FAT_FS support is not included, we write the data into raw flash sectors or a file. That being said EDK2 uses Fvb and Fault Tolerant Writes to write the actual UEFI variables. So you end up needing 3 partitions for the actual storage. The question here is should we implement something similar to u-boot EFI code since this is only supposed to serve as a 'fallback'? If the board has OP-TEE then that will be responsible for writing the variables (and it will use whatever EDK2 uses). I'll have a closer look to the patchset and try to give some feedback. Regards /Ilias > -Takahiro Akashi > > > > > Best regards > > > > Heinrich > > > > > > > > -Takahiro Akashi > > > > > >> -Takahiro Akashi > > >> > > >>> Best regards > > >>> > > >>> Heinrich > > >>> > > >>>> > > >>>>>> > > >>>>>> In addition, why do you treat FAT specifically here? > > >>>>>> I remember that you insisted that other file system should be > > >>>>>> allowed on U-Boot when I posted some patch. > > >>>>> > > >>>>> An EFI system partition is always FAT formatted. So if we want to safe > > >>>>> U-Boot variables to the EFI system partition we require FAT. > > >>>> > > >>>> As system partition is required to be in FAT, file system used on > > >>>> other partitions must also be in FAT since, as I said before, > > >>>> UEFI specification clearly defines its file system format based on FAT. > > >>>> See section 13.3. > > >>>> > > >>>> So, > > >>>> > > >>>>>> I remember that you insisted that other file system should be > > >>>>>> allowed on U-Boot when I posted some patch. > > >>>> > > >>>> You reverted your statement above here. > > >>>> That is my point. > > >>>> > > >>>> -Takahiro Akashi > > >>>> > > >>>>> Best regards > > >>>>> > > >>>>> Heinrich > > >>>>> > > >>>>>> > > >>>>>> -Takahiro Akashi > > >>>>>> > > >>>>>> > > >>>>>>> imply USB_KEYBOARD_FN_KEYS > > >>>>>>> imply VIDEO_ANSI > > >>>>>>> help > > >>>>>>> -- > > >>>>>>> 2.25.1 > > >>> > >