On EOMA-68 patent licensing...

On EOMA-68 patent licensing...

[Yuhong Bao]

I read this: http://hardware.slashdot.org/comments.pl?sid=3102545&cid=41270883
"to explain: the patents are there to protect people from physical harm due to the possibility of idiotic companies creating non-interoperable products that could potentially short-circuit things e.g. a lithium battery. if the scope of this project was to sell only 50,000 units maximum, we would not bother with the patents. however, given that the volume of units is expected to reach several million per year, there is no way in hell that we can leave this to "self-policing"."
Makes me wonder what would happen if something similar was tried with EFI or ACPI?

Yuhong Bao 		 	   		  

Re: On EOMA-68 patent licensing...

[Luke Kenneth Casson Leighton]

On Sun, Nov 24, 2013 at 3:35 AM, Yuhong Bao <yuhongbao_386@hotmail.com> 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.