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

Search the Community

Showing results for tags 'oefi'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • OpenComputers
    • Announcements
    • Feedback
    • IRC
  • Code Central
    • Support
    • Showcase
    • Tutorials
  • Addons & More
    • Addons Mods
    • Architectures
    • OpenEngineering Task Force
  • General
    • Lounge
    • Forum Games
    • Showcase
    • Servers
  • Archives
    • Public Archives

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Minecraft


GitHub


IRC


Location


Interests

Found 1 result

  1. Concepts 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" Rationale 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 OEFI v1 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 Example: { { "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) 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b (ASCII character 15) .efi/fuchas.efi T OEFI v2 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 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..
×
×
  • Create New...

Important Information

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