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. OEFI v2 FOR LUA ARCHITECTURE, OEFI PRESENTS LITTLE TO NO ADVANTAGES! Lua BIOSes that implements OEFI must allow using conventional booting. Note that OEFI has been made to be more architecture-independent and will support ANY architecture able to read files and CPIO (basically any architecture with basic access to component and bitwise operations). Concepts Application: Executable code booting using OEFI in the EFI1 or EFI2 format. Conventional Booting: OpenComputers default booting method. Often called "BIOS" Operating System (OS) : Complex Application with user interaction and/or providing an environment for programs. 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, the most big problem is that this only work for Lua architecture, and what should other architectures use, init.asm? init.test? init.o? What happens if we want one drive to contains multiple inits for multiple architectures? Well that's where Open Extensible Firmware Interface comes handy. 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. 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, this is even worse for Applications booting on unmanaged drives Conventional Booting isn't made for any other architecture than Lua. And with it, like addressed below, it's impossible to have multiple applications for multiple architectures, while OEFI allows in theory to have one same drive to boot on all architectures it support, without tweaks needed from the user! 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.efi" }, { drive = "af58dbe2-ff8c-433a-a871-c08723e01f25", path = ".efi/osOnSameDrive.efi2" }, { drive = "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec", path = ".efi/another_os.efi" } } For architectures not supporting tables, "drive" is index 0 and "path" is index 1 For architectures not supporting arrays inside arrays (2D arrays), the arrays should be appended in such a way it look like that: drive, path, drive, path, drive, path, ... 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 files in ".efi" directory: If the file ends with .efi, then check if it contains CPIO signature, if no, boot in compatibility mode (OEFI1, which is not described anymore on this document). However if the same file contains that signature, then boot as normal. .efi2 will ALWAYS be in standard EFI2 format, unlike .efi which can be EFI or EFI2. .efi can be EFI1 or EFI2 to keep compatibility with old OEFI Applications, and to allow 8.3 filesystems to still support OEFI (would be problematic otherwise) Standard Methods 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 2 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 is not accessible from global, this will just crash. That is the expected behavior. oefi.execOEFIApp(drive, path) - Boot another OEFI app by using the implementation's routine For architectures supporting tables (and global), API must be available in Global Else, API must be available as a pointer/struct/class/anything like that available as argument to the code Please also note that if possible, computer.getBootAddress() and computer.setBootAddress(addr) should be 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 either or not it will be in OEFI library or be kept in global state. (example: Zorya-specific methods should be in 'zorya' and not 'oefi.implementation' or anything like that) EFI2 EFI2 is a new format for Applications, it replaces EFI(1) in , it is a CPIO archive. All files in that archive must be placed at root and are listed here: app.lon app.exe app.exe is only the Application, it contains the code designed for target architecture, and will be launched by the OEFI . 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, oefiVersion = 2, architecture = { name = "Lua", minimumVersion = 5.2, maximumVersion = 5.3 } } "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 "architecture" is a table containing the fields "name", which is the name of architecture, "minimumVersion" and "maximumVersion" are self-explanatory. Note that for minimumVersion and maximumVersion, -1 can be used if a version doesn't make sense to the architecture to have a version. (example: a 6502 architecture) "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. Configuration Data Everything is explained in that image: Component Address Packing To shrink down components to 16 bytes, since components address (and UUIDv4 in general) are just hexadecimal numbers converted to string, we can re-convert the string to a byte array and vice-versa. To do it, the lines (-) must be ignored, and each group of 2 characters must be interpreted as a hexadecimal string, this should be easy with architecture supporting string to number with optional base (in our case base is equals to 16) For example it turns: 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b into: {0x68, 0xCA, 0x0F, 0x59, 0xAC, 0x2C, 0x49, 0xF8, 0xBA, 0x6A, 0x3C, 0x4C, 0x7E, 0x5F, 0x06, 0x9B} Here is a code sample submitted by AwesomeCatgirl to encode and decode the addresses: function binToHex(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)) end function hexToBin(addr) addr = addr:gsub("%-", "") local result = "" for i=1, #addr, 2 do baddr = result .. string.char(tonumber(addr:sub(i, i+1), 16)) end return baddr end -- example: hexToBin("68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b") == {0x68, 0xCA, 0x0F, 0x59, 0xAC, 0x2C, 0x49, 0xF8, 0xBA, 0x6A, 0x3C, 0x4C, 0x7E, 0x5F, 0x06, 0x9B} -- "68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b" == binToHex(the array below) Back to EEPROM data, implementation name and custom configuration are very easy to understand what they're about.
×
×
  • Create New...

Important Information

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