On Sun, Nov 24, 2013 at 3:35 AM, Yuhong Bao <[email protected]> wrote: > I read this: http://hardware.slashdot.org/comments.pl?sid=3102545&cid=41270883 > Makes me wonder what would happen if something similar was tried with EFI or > ACPI?
the EOMA68 project is unique in that it is a mass-volume *modular* architecture [*1], and it is (until intel and amd pull their fingers out their arses and properly get below the 2W barrier) using the so-called "embedded" SoCs - you know, the ones that don't have a BIOS? the ones that are causing linus to throw toys-out-of-prams? what's the name again... oh yes - ARM! yes, that's the ones, silly me how could i forget. so with no BIOS a degree of cooperation between hardware and software on *both* sides of the interfaces is therefore... critical. an example of the closest corresponding danger that's related to single-board monolithic designs is CONFIG_SYS_GPIO. access to GPIO is typically disabled by default in distro-released kernels (e.g. debian) and even there if you look at e.g. the CS5535 GPIO module it's hard-coded into the kernel source that "unsafe" GPIO cannot be accessed even if it's requested. in other words, what would normally be dealt with either by the proprietary vendor's BIOS on a single-board design plus a tiiiny bit of help from some linux kernel source, suddenly now that's all out the window. the next closest corresponding danger is x86 BIOSes (coreboot, tinybios) etc. which is where dangers related to EFI and ACPI would properly come into play and that's not the linux kernel's problem, it's coreboot, tinybios, phoenix bios etc. etc.'s BIOS's problem, so i'd kiinda say it's out of scope. unless anyone else knows different? l. [*1] designed to solve the toys-out-of-pram issue by reducing the Linux Kernel Hell surrounding embedded products from an "N product design types times M processors" problem to a manageable "N designs *plus* M processor-modules" arena. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
