joshuawierenga / efisharp Goto Github PK

See dotnet/runtimelab#633, you can now specify <EntryPointSymbol>EfiMain</EntryPointSymbol>

Currently, the older v1 alpha compiler is used since building with v6 leads to the linker complaining about the wmainCRTStartup function being missing. As far as I know, this is a windows specific function and so cannot be added. This was with an older version of the compiler however and this might be fixed by now.

Check if this is because of the compiler not being designed for this use or if it is because dotnet.exe is being told to build for win-x64. Both are possible since the other .net efi projects using a stock compiler either use csc directly or the same compiler as this project where this issue does not exist.

Currently, the program will terminate after 5 minutes because of a timer set by uefi before starting it. This can be disabled by running SetWatchdogTimer(0, 0, 0, NULL) from BootSerivices. From https://wiki.osdev.org/UEFI#My_UEFI_application_hangs.2Fresets_after_about_5_minutes.

Despite my efforts to improve array support so far, it is currently impossible to store a regular array directly in a static class/struct.
As an example, in my current efforts to port System.DateTime I had these two arrays defined that caused the program to crash at runtime if used. I solved this by moving the arrays into the function I needed them for. This method, however, breaks somewhat if I need them for something else later on.

This has been the case for quite a while since I had the same problem here in my console class.
Since it crashes at runtime, it has so far been impossible to diagnose. It might be possible to inspect the efi file to see if the method used to define the arrays is broken, however.

This has the same purpose as #15 and describes important missing features from the full corelib that rather than build up from system features are based on existing features in corelib.

• Span. Requires Span.cs, ReadOnlySpan.cs, MemoryMarshal.cs and more complete versions of Unsafe.cs and Type.cs if not more.
• Nullable.
• Intrinsics/Vectors.
• System.Math.
• TimeZone. TimeZone.cs? TimeZoneInfo.cs?
• Tuple. Tuple.cs and ValueTuple.cs?
• Improved Primitive support
• Collections: List, Array, IEnumerable and Foreach, ...
• Exceptions

Above is an example showing that non user input can be removed and then replaced.

This should be fixed so that only user input can be removed and not surrounding text provided by Write and WriteLine.

Despite most console functions working, some crucial ones like the format string write functions are missing, can these work without concatenation? Even if so, it would probably be good to support string concat as well.

Vhds no longer work with gen 2 VMs and are hence restricted to gen 1 VMs which only support bios emulation.
Need to either get diskpart to output a vhdx or get hyperv to convert the vhd automatically.

An example is shown below where backspace and then yes is entered which results in ReadLine not returning "yes" and in this case not clearing the screen.

Entering any number of control chars while entering chars into ReadLine should produce the same string and just entering the chars directly. Additionally, this string should match the chars shown on screen.

This might be linked to #3.

Pressing lower case a during a ReadKey returns 0 as the ConsoleKey, the key code is however correctly identified as 97.
This also affects the cursor test since it relies on ReadKey but this can be fixed by using an upper case a.

Current attempts to support throwing have not worked. The most recent attempt involved just adding a throw and then trying to add code until the errors went away. This began with RhpThrowEx in ExceptionHandling.asm which caused issues with _tls_index and tls_CurrentThread being missing since both threads and local storage are not supported. Ignoring this lead to RhThrowEx in ExceptionHandling.cs which requires many other functions in StackFrameIterator.cs, UnsafeGCHandle.cs and TypeCast.cs and the following list of internal calls:
RhpHandleAlloc,
RhpHandleSet,
RhpEHEnumInitFromStackFrameIterator,
RhpEHEnumNext,
RhpGetClasslibFunctionFromCodeAddress,
RhpGetClasslibFunctionFromEEType,
RhpSfiInit,
RhpSfiNext,
RhpGetRequestedExceptionEvents,
RhpSendExceptionEventToDebugger,
RhpCallCatchFunclet,
RhpCallFinallyFunclet,
RhpCallFilterFunclet,
RhpSetThreadDoNotTriggerGC,
RhpValidateExInfoStack,
RhpCopyContextFromExInfo,
RhpAcquireCastCacheLock,
RhpReleaseCastCacheLock,
PalGetTickCount64.

Adding externs for these in order to pass the il compilation stage works but the ilc stage fails with "EXEC : LLVM error : invalid symbol redefinition" without indicating what symbol it is talking about. The plan was to see which of those internal calls were actually required since some are debug only and then look into adding those but that required getting to the linker.

Currently, I have to include guids specific to setup in EfiSharp.csproj and either keep modified files around forever or commit them. It would be ideal if these could be read in at build time with an external config file that was on the .gitignore list.

While debugging does work now, it is definitely not ideal as producing a debug build currently opens a second visual studio window which sometimes stays in the background and then starts debugging on it. Ideally, this would be moved into the main instance and should only occur when the start button is pressed, just like the release build. Given this is largely the current debugging method for nativeaot programs, there may not be much I can do. Perhaps replace the vbs debugging script with a vs plugin? Is dte available then?

Several c# features could be added by supporting more low-level EFI functions like time, networking, file systems and graphics. Supporting these features would massively improve support with third-party applications and help make EfiSharp much more useful.

APIs to support:

• Time support. Requires adding the EFI_TIME struct and the EFI_GET_TIME and EFI_SET_TIME functions within EFI_RUNTIME_SERVICES. See #17.
  • Add efi support. DONE. Should the todos be dealt with?
  • Add c# wrapper, DONE, a lot of DateTime is now supported, including .Now.
• Networking support. This is a lot of work and requires the EFI_TCP4_PROTOCOL, EFI_MAC_ADDRESS, EFI_DHCP4_PROTOCOL and EFI_IP4_PROTOCOL structs and their functions, if not more.
• File System Support. Another big project and requires the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and EFI_FILE_PROTOCOL structs and their functions, if not more.
• Graphics Support. Requires the EFI_GRAPHICS_OUTPUT_PROTOCOL, EFI_GRAPHICS_OUTPUT_MODE_INFORMATION, and EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE structs and their functions, if not more. Additionally, there is some image/forms stuff in EFI_HII_IMAGE_PROTOCOL, Image Package and Forms Package which looks somewhat useful.
• Random Number Generation. Requires EFI_RNG_PROTOCOL at a minimum and perhaps EFI_RNG_ALGORITHM. See #20.
  • Add efi support. DONE
  • Add c# wrapper. DONE. Added efi specific implementation for all functions except ReadBytes(Span<byte>).
  • Add Legacy and Xoshiro rng implementations. DONE. Same as above with the additional exception that the seedless constructor in Random.cs always uses Xoshiro.
• Thread Support
  • Sleep Support. Requires either CreateEvent, SetTimer and WaitForEvent or Stall, both sets of functions are in EFI_BOOT_SERVICES. Then Thread.Sleep and Thread.InternalSleep to wrap the efi call(s)

Most of these require accessing their protocols via the boot service's protocol handler functions but a few are accessed by EFI_RUNTIME_SERVICES so that appears like a good place to start.