Message ID | fcf6e3d9-8fb0-53f0-5eca-e2b85c0cf5a1@gmx.de |
---|---|
State | Accepted |
Delegated to: | Tom Rini |
Headers | show |
Series | Pull request for UEFI sub-system for efi-2020-10-rc1 | expand |
On Sat, Jul 04, 2020 at 11:50:01AM +0200, Heinrich Schuchardt wrote: > The following changes since commit bcfe764ee925d0820e82c69ccf75b71d142644c7: > > Merge tag 'efi-2020-07-rc6-2' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-30 17:15:39 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2020-10-rc1 > > for you to fetch changes up to 93f6201af71d9a0a521c99212e6066778270a357: > > efi_loader: imply FAT, FAT_WRITE (2020-07-03 18:03:56 +0200) > > ---------------------------------------------------------------- > Pull request for UEFI sub-system for efi-2020-10-rc1 > > This series comprises error corrections for the UEFI subsystem: > > * correct consideration of timestamps for variable authentication > * correct collection of data regions for code authentication > * correct unit tests to test loading dbx > * enable FAT_WRITE as required by the UEFI spec So, FAT_WRITE is required by the UEFI spec, ok. Are we exposing the ability to write files via the UEFI API? What happens if we return failure to write here? I'm asking because the first thing I see reviewing this is thee large number of platforms with: u-boot: add: 30/0, grow: 5/-4 bytes: 139792/-10412 (129380) function old new delta tmpbuf_cluster - 131072 +131072 For FAT write support. Perhaps another way of looking at it is, can we rework the FAT write support to get that buffer dynamically? Thanks!
On 06.07.20 01:40, Tom Rini wrote: > On Sat, Jul 04, 2020 at 11:50:01AM +0200, Heinrich Schuchardt wrote: >> The following changes since commit bcfe764ee925d0820e82c69ccf75b71d142644c7: >> >> Merge tag 'efi-2020-07-rc6-2' of >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-30 17:15:39 >> -0400) >> >> are available in the Git repository at: >> >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git >> tags/efi-2020-10-rc1 >> >> for you to fetch changes up to 93f6201af71d9a0a521c99212e6066778270a357: >> >> efi_loader: imply FAT, FAT_WRITE (2020-07-03 18:03:56 +0200) >> >> ---------------------------------------------------------------- >> Pull request for UEFI sub-system for efi-2020-10-rc1 >> >> This series comprises error corrections for the UEFI subsystem: >> >> * correct consideration of timestamps for variable authentication >> * correct collection of data regions for code authentication >> * correct unit tests to test loading dbx >> * enable FAT_WRITE as required by the UEFI spec > > So, FAT_WRITE is required by the UEFI spec, ok. Are we exposing the > ability to write files via the UEFI API? What happens if we return Yes the UEFI API allows to write files. If the write fails we return an error code conforming to the UEFI specification. But especially I want to save non-volatile UEFI variables on the EFI system partition in v2020.10. Cf. https://patchwork.ozlabs.org/project/uboot/list/?series=167069 Currently I am reworking that patch series. > failure to write here? I'm asking because the first thing I see > reviewing this is thee large number of platforms with: > u-boot: add: 30/0, grow: 5/-4 bytes: 139792/-10412 (129380) > function old new delta > tmpbuf_cluster - 131072 +131072 > > For FAT write support. Perhaps another way of looking at it is, can we > rework the FAT write support to get that buffer dynamically? Thanks! > I will send a patch to allocate tmpbuf_cluster dynamically. Best regards Heinrich
On Sat, Jul 04, 2020 at 11:50:01AM +0200, Heinrich Schuchardt wrote: > The following changes since commit bcfe764ee925d0820e82c69ccf75b71d142644c7: > > Merge tag 'efi-2020-07-rc6-2' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-30 17:15:39 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2020-10-rc1 > > for you to fetch changes up to 93f6201af71d9a0a521c99212e6066778270a357: > > efi_loader: imply FAT, FAT_WRITE (2020-07-03 18:03:56 +0200) > Given that I see you've addressed the size growth from FAT_WRITE, applied to u-boot/next, thanks!