Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

OETF #16 - Open Extensible Firmware Interface

Recommended Posts

Posted (edited)


  • Application: Lua script booting using OEFI. Application formats/types are "EFI" and "EFI2".
  • Conventional Booting: OpenComputers default booting method. Often called "BIOS"
  • Operating System (OS) : Complex Application with user interaction. Concept only used in this document for Conventional Booting
  • OC: Shortcut for "Open Computers"


Due to the limitation of current OC booting method which basically searches for an init.lua file, a new and open specification has been made: Open Extensible Firmware Interface. The limitation OEFI fix in Conventional Booting in OC is:

  • In Conventional Booting, there is only one init script per filesystem, while in OEFI there can be multiple applications per filesystem.
  • The operating system, once launched, cannot return back to the BIOS (or here, the OEFI), while OEFI have oefi.returnToOEFI()!
  • Conventional Booting doesn't have any native support for multiple applications. An OS that want to boot another one need to manually check for init.lua files in all filesystems, OEFI has oefi.getApplications() method for it


Application Table Format:

The application table must contains tables as entries.
The tables must contains the drive address with "drive" key and the path (from drive) with "path" key


    "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25",
    "path": ".efi/sampleos.lua"
    "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25",
    "path": ".efi/osOnSameDrive.lua"
    "drive": "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec",
    "path": ".efi/another_os.efi"

Application Finding:

OEFI Applications can be found on any sort of drives, from disk drives to floppy, with raids, only if they contains a ".efi" directory.
The OEFI should search in that ".efi" directory, and add every .efi files to its application table. ".efi" directory name has been chosen for being hidden by default on POSIX systems.

EEPROM Configuration:

Booleans are a single character value, they are equals to "T" if true, or "F" if false

1-Byte Numbers are also single character values, they are corresponding to the ASCII character of the number (use string.char(number)), these are limited to 255 as maximum value

As of API version 1:

The data (512 bytes) should be written in the following format (in the same order!) :

- 1-byte number, equals to the API version of the implementation (current is 1), having it at start will allow for config conversion in case of new version

- Last booted application filesystem component id (always 36 bytes) (like 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b)

- 1-byte number, equals to the length of the last booted application path (next value)

- Last booted application path

- 1 boolean for weither it should allow the OS to return back to OEFI or not


Example (line breaks should NOT be included):

(ASCII character 1)


(ASCII character 15)




All OEFIs compatible must allow using conventional booting.

Methods are same as in Version 1, of course API version is now 2 (logic), and some new methods are being added, so here is the new list of methods:

  • oefi.loadfile(path) - Loads file from boot drive
  • oefi.getBootAddress() - replaces computer.getBootAddress()
  • oefi.getApplications() - Return an application table as described below
  • oefi.getAPIVersion() - Return API version number. Returns 1 for this version
  • oefi.getImplementationName() - Returns implementation name
  • oefi.getImplementationVersion() - Returns implementation version number
  • oefi.returnToOEFI() - Recalls the OEFI program, most of _G structure should remain as it was at boot. Meaning that if for example, component API needs "require(...)" function, this will just crash.
  • oefi.execOEFIApp(drive, path) - Boot another OEFI app by using the implementation routine

Other notable changes to API: It must now be available in Global

Please also note that computer.getBootAddress() and computer.setBootAddress(addr) has been REMOVED! This is due to that Applications supporting OEFI doesn't need any compatibility methods as thoses conventional booting methods are only kept when booting a OS that only support conventional booting.
Implementation can create their own methods, however it should not be inside the OEFI API! This must be in their own table and only the OS will manage eithe r or not it will be in OEFI library or be kept in global state.


EFI2 is a new format for Applications, it is an URF v1.1 archive. All files in that archive must be placed at root and are listed here:

  • app.lon
  • main.lua

app.lua is only the OEFI program, just the normal Lua file, with the OEFI library in global state.

app.lon is a LON file (LON files are just Lua Tables/Objects, see examples in Fuchas). The file should look like this:

  "name" = "Application Name",
  "version" = 1.0,
  "luaVersion" = 5.2,
  "oefiVersion" = 2

"name" is equals to the name of the Application.
"version" is equals to the version of the Application, if you don't want to fill it, just make it stay to 1.0
"luaVersion" is equals to the Lua version it has been designed to run to. If luaVersion is higher than the current Lua version, then ignore this Application.
"oefiVersion" is equals to the OEFI version the Application has been designed to run with, if the "oefiVersion" field have a version incompatible with the current API version or if it's higher than the current one (ex. it's equals to 3 but we're on API v2, or it's equals to 1 but we're on API v2).

With all thoses fields in mind, the EFI2 was designed to be durable, with only changes being to app.lon and URF version.

Now let's speak about the shell..

Edited by Zen1th
draft OEFI v2

Share this post

Link to post
Share on other sites

I was thinking about component IDs. Shouldn't they be minified? Like, "68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b" turns into a string of 16 bytes:

{0x68, 0xCA, 0x0F, 0x59, 0xAC, 0x2C, 0x49, 0xF8, 0xBA, 0x6A, 0x3C, 0x4C, 0x7E, 0x5F, 0x06, 0x9B}

Also, OEFI implementations need to have room for custom configuration, as something like Zorya needs some EEPROM space for knowing the device that the "zorya-module" and "zorya-cfg" folders are stored on. Maybe 64 bytes or so can be dedicated to custom config? 64 bytes should be plenty of space for basic configuration, yeah? 32 bytes would be too little, probably, as a component ID can only be shrunk down to 16 bytes.

As for how to convert binary component ID to text component ID and back again:

function binid_to_hexid(id)
  local f, r = string.format, string.rep
  return f(f("%s-%s%s", r("%.2x", 4), r("%.2x%.2x-", 3), r("%.2x", 6)), id:byte(1, 16))

function hexid_to_binid(id)
  local lasthex = 0
  local match = ""
  local bstr = ""
  for i=1, 16 do
    match, lasthex = id:match("%x%x", lasthex)
    bstr = bstr .. string.char(tostring(match, 16))
  return bstr

Otherwise, this looks pretty good.

Share this post

Link to post
Share on other sites

Thanks for the review. I will make a version 2 (on same post) to add the changes you suggested and some others changes. I will also soon make a more presentable form of the specification.

Share this post

Link to post
Share on other sites

So, some recommendations for OEFI v2:

  • Storage of addresses in a binary format
  • Maybe a standard set of commands for an OEFI shell?
  • "oefi.loadfile(path)", which loads a file from the boot device
  • Vendor prefixes on extensions to OEFI (ie "oefi.vendor.extensionmethod()")
  • BIOS configuration space of 64 bytes, at the end of the EEPROM
  • Maybe a network boot protocol?
  • The OEFI library should be global unless booting in compatibility mode (for example, from an init.lua file)
  • OEFI implementation must allow the OS to return
  • Standard for passing kernel arguments (For things like Fuchas NT or Tsuki)
  • Maybe a sample OEFI implementation?
  • Must support compatibility mode, though maybe there can be an option to disable compatibility mode.
  • Maybe a URF-based bootable package?

Share this post

Link to post
Share on other sites

Nice proposals, i'm still making the draft for version 2

The URF-based bootable package is a very good idea, however this would cause problem since the only implementation for writing/reading URF is uncertain of actually being standard and is only available from Lua from OC.
WIth my knowledge i could also make an application to extract/package URFs, but who would trust it anyways? So the best option is: Making an dedicated C/C++/Java app/library, finding a known archive extractor that support plugins. So based on my existing work and on the specifications, gotta try to make those

Share this post

Link to post
Share on other sites

Fair. Also, we could use binary CPIO for bootable packages. That would probably be the best bet. It's standard and been around for a while.


Also, OEFI v2 applications should end in `.efi2` to differentiate them from the OEFI v1 applications. OEFI v2 applications should also probably support a few basic arguments.

Share this post

Link to post
Share on other sites

.efi2 could probably be a CPIO archive. Entry point can be defined by a .cfg file in the root of the archive. Or, we could also check if it's a CPIO file or a Lua file. Dunno, it's up to you.

Share this post

Link to post
Share on other sites

I decided to instdead use URF, sure it's less supported, but it is more adapted to OpenComputers, as it is made for OpenComputers

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.