Program i2c-0 during boot time

Program i2c-0 during boot time



I have a custom board(RC10), which has E3845 and is similar to MinnowBoard MAX. I have customized from Intel Firmware Engine MinnowBoard MAX firmware to RC10 by enabling i2c-0, PCIe-2, etc. I also wrote an EFI application that programs a LED controller via i2c-0, andI put the EFI application in startup.nsh to turn the LED light on. However it taked more than 5 seconds to turn the light on, which is too long. I want to turn on as fast as it can.

1. Is there a way to run a custom program during firmware boot time earlier than startup.nsh?

2. If yes to #1, how fast can it turn on the LED? I'm expecting to be able to run within a couple of seconds.

3. Any suggestion that makes the programming of LED controller faster, please let me know.



2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

There are three options for introducing custom code into Intel Firmware Engine.

  1. Add a .EFI program as a payload. If you can write and test a UEFI application at the Shell that initializes the controller, then you can run the program before launching the OS or other payloads. Go to 'Projects' on the menu bar (icon farthest to the left) and pick 'Add Files', then use 'Add firmware application' to pick the file. Make sure your file is the first on the list, so it runs before anything else.
  2. Add a UEFI DXE driver as a payload. Similar to step #1 above, but this code will run earlier. Use the same 'Add files' dialog in #1, but add it to 'Drivers' instead of 'Applications'. 
  3. Use the Intel Firmware Engine SDK to develop a package to initialize the controller. This is like writing a UEFI PEI/DXE Driver, but with some additional features that allow you to configure PCD options using the Intel Firmware Engine GUI (you can't do this in options #1 or #2). You can also properly specify the hardware connections, so it attaches to the proper bus and shows up in the GUI as a "gear".

I prefer #3 since it gives you the most control over configuration after the package is built, and will run sooner in the boot process. The SDK documentation provides many examples. #1 will also work and it's easier to test than #2, but it runs much later in the boot process. #2 may have problems if you don't properly handle protocol dependencies. 

You can download the SDK here:

Leave a Comment

Please sign in to add a comment. Not a member? Join today