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

Search the Community

Showing results for tags 'booting'.



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. I understand some people might just dislike another booting method, even if implementations should be compatible with original one. And as the document might seem "empty", any criticisms (good or bad) and/or suggestions are welcomed. Note: "Application" refers as init scripts for OEFI booting. Why: 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 BIOS booting in OC is: - In BIOS 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()! - Since BIOS 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 Specification: Every OEFI should be backward-compatible with OC original booting method which is basically booting init.lua. OEFI must also create a standard API available to the OEFI program as the first argument (of "..."), the API must implement at minimum the following: oefi.getApplications() - Return an application table as described below oefi.getAPIVersion() - Return API version number, current = 1 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 computer.getBootAddress() - Return the filesystem address from which the application booted computer.setBootAddress(addr) - Provided for compatibility, does nothing Implementations can create implementation-specific methods that can be used by applications and OSes launched by them. Application Table: 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 .lua or .efi files to its application table. ".efi" directory name has been chosen for being hidden by default on POSIX systems. (EEPROM) Data Format: 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
×
×
  • Create New...

Important Information

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