Dear Heinrich,
In message 7083d208-4b3c-7261-a03b-9066dc8d2009@gmx.de you wrote:
to be really useful UEFI variables should be available to the operating system. This is not possible using U-Boot variables as storage.
Oops? Is it possible that you are not aware of the tools/env/fw_env* code?
Of course U-Boot environment variables can be accessed (read and written) from Linux.
And maybe a fourth dummy one implementing no variable service at all.
Is this really a good idea?
Tom is always complaining that the UEFI subsystem has become too large.
And I agree on that. But even if it was not the case, having four different implementations for the same thing is .... sub-optiman.
And if the "volatile" feature is all that is missing when using environment variables, then this should be the road taken:
- It avoids a complete new implementation - It can be added witrh very little effort - It would be just a minimal increase in memory footprinmt - It is useful for a lot of other pirposes as well.
What are your agruments for _not_ taking this approach?
The best solution for UEFI variables would be to live in the secure part of the ARM trusted firmware.
You think too narrow. Not all the world is ARM, and not everyone uses ATF.
UEFI variables have both a name and a GUID as keys.
Internally U-Boot variables are stored in a hash table; you could easily add GUID support. the external storage format is also simple enough. You could extend it in a compatible way for example from
<name>=<value>\0
to something like
<name>;<guid>=<value>\0
of, if you don't want to waste another separator character, even
<name>=<guid>=<value>\0
Extending the env import parser and the env export code for this does not look like rocket science either.
Furthermore both variable names and values are in UTF-16. So they are quite different to U-Boot variables.
Nothing in U-Boot prevents this. There is a number of ways to convert UTF-16 (or even any kind of binary data) to and from plain ASCII strings, and only your UEFI code needs to understand such encoding.
Look at this output:
-> printenv
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={boot,run}(blob)0000000000000000 efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang={nv,boot,run}(blob)656e2d555300 efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLangCodes={boot,run}(blob)656e2d555300 efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_RuntimeServicesSupported={boot,run}(blob)8004
=> printenv -e
OsIndicationsSupported: BS|RT, DataSize = 0x8 00000000: 00 00 00 00 00 00 00 00 ........ PlatformLang: NV|BS|RT, DataSize = 0x6 00000000: 65 6e 2d 55 53 00 en-US. PlatformLangCodes: BS|RT, DataSize = 0x6 00000000: 65 6e 2d 55 53 00 en-US. RuntimeServicesSupported: BS|RT, DataSize = 0x2 00000000: 80 04 ..
I'm looking at it, but I don't understand what you want to show me here?
All I can see is that this looks like something I would not want to use (read: I consider it ugly and think the design should be improved).
This is worthwhile but insufficient to solve the UEFI problems.
Could you please be so kine and clearly state what is lacking?
So far I have found:
- lack of "volatile" vs. "non-volatile" - lack of support for GUID - lack of support for UTF-16
None of these should be difficult to add by small (or even minimal) extensions of the existing code, which would probaly also useful to others (at least some of them).
So far, I see no killing point not an advantage that would justify adding a completly new implementation for a problem that has been solved before.
Best regards,
Wolfgang Denk