Really cool modular and freedom-respecting computer

[sulu]

hmmm, intriguing concept... i'm not sure that Dr Stallman could be convinced that the ethical considerations behind "Freedom" could be separated from the ethical considerations behind "Privacy", on the basis that only through *having* the source code under freedom-respecting software licenses do we stand a chance of verifying that people's privacy is respected.

my feeling is that you shouldn't even *try* to have one without the other, because it stems from the same root unethical behaviour.

Well RMS's concept of FLOSS is pretty old. And while he clearly opposes software patents, the FLOSS licenses are pretty much blind to them, because apparently nobody in the FSF thought of the possibility to separate licenses and patents to protect intellectual property while formally adhering to FLOSS licenses.
I think a similar thing is happening with privacy right now. FLOSS might be necessary to ensure privacy, but it's clearly not enough. After all, Google, probably the most privacy-hostile company out there, proudly claims to carry the FLOSS banner. And there are more than enough people who won't see that there's no spirit supporting that banner.

i've spoken to Intel,

Was that a two-way communication, as in there were at least two rounds of back and forth with answers from them that weren't simply ready-made text templates?

On a more practical note, I have three questions regarding your project:
1. I don't understand yet, how the whole I/O handling works. How do the keyboard inputs get to the EOMA board, and how does the graphics signal go from there to the display? I would assume that requires some basic OS running on the host's hardware, which would defeat the point of circumventing its potentially malicious CPU. Did I miss some documentation?
2. I see you're using the PC-Card form factor. Are there any plans to use other form factors, like Expresscard or maybe something like a DVD bay caddy? I'm asking, because I don't have any laptops with PC-Card slots, but several with Expresscard slots and unused DVD drives.
3. Crowdsupply only seems to accept credit cards, which I don't use. Is there a way to support you via SEPA?


Edit:

what _will_ kill it off though is if Debian GNU/Linux stops support for 486 and (original) pentium-level processors. that would be... bad.

Effectively Debian already did. Jessie/i586 doesn't run well, because all the x86_32 software is compiled on i686, even the i586 packages.
This introduces implicit dependencies on i686 instructions (e.g. cmov, fucomip), which makes certain software crash on i586 hardware.

 

[pyrat]

hmmm, intriguing concept... i'm not sure that Dr Stallman could be convinced that the ethical considerations behind "Freedom" could be separated from the ethical considerations behind "Privacy", on the basis that only through *having* the source code under freedom-respecting software licenses do we stand a chance of verifying that people's privacy is respected.

my feeling is that you shouldn't even *try* to have one without the other, because it stems from the same root unethical behaviour.

I tend to agree with lkcl.

Well RMS's concept of FLOSS is pretty old. And while he clearly opposes software patents, the FLOSS licenses are pretty much blind to them, because apparently nobody in the FSF thought of the possibility to separate licenses and patents to protect intellectual property while formally adhering to FLOSS licenses.
I think a similar thing is happening with privacy right now. FLOSS might be necessary to ensure privacy, but it's clearly not enough. After all, Google, probably the most privacy-hostile company out there, proudly claims to carry the FLOSS banner. And there are more than enough people who won't see that there's no spirit supporting that banner.

About patents and FSF :

1.- GPL 2 was written in a time when software wasn't patentable. It still isn't in many parts and is not so well legally defined in others. Sadly the powers that be don't care and keep patenting it and threatening with it.
If the GPL 2 would have included patent provisions it would have helped patent hoarders in acknowledging that software patents were even possible.
2.- GPL 3 deals with patents as it can.
3.- No copyright license can deal with software patents. Patents block independent development, are granted at patent offices to those who pay for them, and it's terribly expensive to determine if a program infringes a patent, who has patents that may affect your programs, whether they want to use them against you or your community or your bussiness relations, whether the patents are good enough and whether the attack will be successful in court or the threat/FUD effective in the marketplace. It is such a random exercise that megacorps just stockpile patents so that they can throw many coins against you. Copyright is automatically granted to authors without expense or paperwork so that can be used to build a community heritage, patents can only be fought in the legislative. Patents are too expensive and cumbersome to get and can only be used to build monopolies and thickets. Copyleft can't really work with patents (there are attempts that are better than nothing, but anyone anywhere unaffected by any patent agreement can have a patent that blocks everything, so there's no real solution).

About privacy:

1.- You are very right that privacy can be abused even with free software (not by free software, that's too easy to fix).

2.- No RYP certification could guarantee anything. Whatever software or hardware you put on a device, it will still communicate with other devices owned by other people and corporations and they will mishandle your data. You could try to put a blacklist so that it does not connect to GAFAM but then your buddy will give you away adding all his addressbook to linkedIn or WhatsApp. Even for devices without network, they can leak data when resold. Privacy is more about usage than about the device. RYP might be a certification for services, not devices, and yet it wouldn't be very useful, because the only thing a service can do to try to have users behave is put stuff in their terms of use that nobody reads...

3.- If a device RYF then you can use it in privacy, because you can remove or modify any privacy violating software. And you (or we as a community) can check whether it respects priacy or not. But no software can guarantee your privacy when you communicate with others.

AMD keeps trying desperately to get rid of that processor range: i believe they've been trying for about five years at least to shut it down, but for some strange reason perhaps something to do with the AMAZING level of support (thanks to the original OLPC) they just can't seem to stop taking people's money.

Don't forget the Moore law is slowing down and the vast majority of needs were already covered by the eighties or nineties hardware capacities.
Even without the attorcities being introduced "lately" people already had reason to use old gear.

believe me when i say that the RYF Certifications are NEVVVERRRRR going to be "watered down". the FSF is a Foundation: there are legal ramification of it violating its own Charter. what kind of message would it send for them to back down or change their stance? nobody would ever trust them ever again!

We can argue all we want about the requirements that should go in a certification, but it would be very strange for any ertification by anyone to modify the requirements once there are already certified products in the market.
What would they do ? Decertify some products ? Tell some products that part of they efforts turn out not to be necessary ?
IT would be very little credible. Whenever a certifier wants to change criteria they have to start a different certification.

oo, oo, i just learned that the qualcomm 410 might actually qualify as useable, it's available on arrow, there's schematics available, and much more - even the GPU has been reverse-engineered.

The problem I tend to hear about Qualcomm is their modems are not isolated, might control the mic, GPS, RAM or from there the rest (and I assume they run proprietary software), so there are risks similar to the AMD PSP or Intel ME .
But it's hearsay and I don't know if all models are the same. Maybe if you take the SOC, don't connect it to any antena and are careful in your software it can boot and work, and you just have to add another
wireless chip if you want LTE, WiFI or bluetooth, I don't know. The 410 seems to include a modem.

On a more practical note, I have three questions regarding your project:
1. I don't understand yet, how the whole I/O handling works. How do the keyboard inputs get to the EOMA board, and how does the graphics signal go from there to the display? I would assume that requires some basic OS running on the host's hardware, which would defeat the point of circumventing its potentially malicious CPU. Did I miss some documentation?

Lkcl can of course answer better, but I think the signals that would go to the monitor go to the EOMA68 contact points, and then there're cables/PCB tracks from the device EOMA68 connector to the monitor or keyboard plugs, where you
plug a normal keyboard o monitor cable that brings the signal from your keyboard or to your monitor. So no logic needed in the device.
The laptop has a small Embedded Controller with free software to control the battery, the keyboard decoding or something like that, but that's not necessary in every device. In fact I think you could connect
the EOMA68 card to peripherals directly and power it through USB for those EOMA68 cards that have the necessary connectors in addition to the EOMA68 interface.
The EOMA68 card is the computer. The EOMA68 device can only be peripherals and cabling (or can be more complex too, I guess).

2. I see you're using the PC-Card form factor. Are there any plans to use other form factors, like Expresscard or maybe something like a DVD bay caddy? I'm asking, because I don't have any laptops with PC-Card slots, but several with Expresscard slots and unused DVD drives.

I'm not sure why you care about the devices you may have that are compatible with PC-Card. EOMA68 isn't PC-Card. They use maybe the same physical connectors because that makes easier to source components
but that's all, the signal at each pin are different and the purpose is reversed, so you won't use a EOMA68 card in a laptop with a PC-Card bay. At most you could dismantle the laptop, scavenger the PC-Card connector,
and add it to some device you designed with the proper wiring. But I guess you could also buy the connector.

But I think there was talk of a future standard with bigger connector, more pins or power or something.

3. Crowdsupply only seems to accept credit cards, which I don't use. Is there a way to support you via SEPA?

I asked crowdsupply recently, no news yet.

Edit:
Effectively Debian already did. Jessie/i586 doesn't run well, because all the x86_32 software is compiled on i686, even the i586 packages.
This introduces implicit dependencies on i686 instructions (e.g. cmov, fucomip), which makes certain software crash on i586 hardware.

Ow. Pity. Do you know if debian needs more manpower or more hardware to better support i586 ?

 

[sulu]

3.- If a device RYF then you can use it in privacy, because you can remove or modify any privacy violating software. And you (or we as a community) can check whether it respects priacy or not.

Except for when the privacy violation happens in hardware.

I'm not sure why you care about the devices you may have that are compatible with PC-Card.

Because I assumed, I could put a EOMA68 card in pretty much any laptop with a PC-Card slot and run whatever system is installed on the card.
This is also why I asked for the I/O, because I see no way to interface between the card and the host computer, except for maybe some backdoor-like mechanism like it's in principle possible via Firewire.
If I got the concept wrong, then thanks for clearing that up for me!

Ow. Pity. Do you know if debian needs more manpower or more hardware to better support i586 ?

Debian is in a constant state of manpower shortage. So that would be the primary problem.
Lack of hardware is another issue. There is just no real i586 hardware, that is powerful enough to compile the Debian repository within a reasonable amount of time. So it has to be done on i686/amd64, which is very tricky, because even if running the i586 kernel on i686 hardware, the i686 instructions will cause no problems. You need to actually run i586 hardware or an i586 emulation.
i586 has already been dropped in Stretch, because it was not maintainable. I got this info directly from Ben Hutchings. The decision is final.

 

[pyrat]

Except for when the privacy violation happens in hardware.

Well, there's something along those lines in the certification. You might argue that it only talks of software,
but it's hard to imagine for me hardware directly doing that
without software. Maybe you and I don't put the line between software and hardware in the same place ?

From the certification requirements:

No Spying or back doors
Please be aware that we can't check products for spy features or back doors, but if we find out about any we will drop our endorsement unless they are promptly removed.

Further, because spyware or a back door may take many forms, we will need to work out precise criteria as we go along. The criteria stated below are our first attempts, and we may change them if we come across examples which they handle wrong.

"Spyware" is software that transmits or makes available to anyone other than the owner any information about the owner's or the product's identity, location or activity except (1) when the owner asks to do so, (2) when inevitable due to communication protocols used, or (3) when required by law. In the case 3 applies, the product should come with prominent warning, plus a URL for where to obtain more information.

A "back door" is any functionality that gives remote control over any aspect of the device operation or its software. It is normal for computers to have facilities for updating software or for letting people log in remotely. These become back doors when they are enabled by default.

How would you write it in a usable RYP certification ?

If I got the concept wrong, then thanks for clearing that up for me!

Well, my idea can be as wrong as yours. It's not been my idea. Maybe I misunderstood.
Lkcl may explain it better. Or we could look it up because I think it is explained somewhere.
Hopefully this page or this is valid. I can't find anything else right now.

Debian is in a constant state of manpower shortage. So that would be the primary problem.
Lack of hardware is another issue. There is just no real i586 hardware, that is powerful enough to compile the Debian repository within a reasonable amount of time. So it has to be done on i686/amd64, which is very tricky, because even if running the i586 kernel on i686 hardware, the i686 instructions will cause no problems. You need to actually run i586 hardware or an i586 emulation.
i586 has already been dropped in Stretch, because it was not maintainable. I got this info directly from Ben Hutchings. The decision is final.

 

[sulu]

Well, there's something along those lines in the certification. You might argue that it only talks of software,
but it's hard to imagine for me hardware directly doing that
without software. Maybe you and I don't put the line between software and hardware in the same place ?

I put the line here between firmware and the actual operating system, mainly having x86 AMT and microcode in mind. But I'm totally fine if you want to see firmware on the software side. There is no clear border, which leads to strange situations.

In the case of the Neo900 project, the devs tried to get RYF certification, but since the proprietary modem firmware (same as in the Pyra) could be replaced, the FSF considered it software and rejected a certificate. They even asked the Neo900 team to make the modem firmware irreplaceable, because then the FSF would consider it to be hardware, therefore wouldn't care about it and issue a certificate. The Neo900 devs refused to do that, claiming that if the firmware were found to be malicious, it could at least potentially be replaced by the user with a clean one, therefore restoring privacy.
I think from their respective points of view, both were right. The Neo900 should not get a RYF certificate. But it should also not have a fixed modem firmware.

How would you write it in a usable RYP certification ?

I have no idea how that should be written.

Hopefully this page or this is valid. I can't find anything else right now.

I don't find any info there, that supports either of our interpretations, since it says nothing about the host's hardware. But from a technical point of view, I think your interpretation is more reasonable.

 

[JonnyH]

Hi, there seems a bit of misunderstanding/misinformation in this thread I'd like to try to clear up.

Note, I'm not trying to defend 'closed' drivers, I (personally) believe PowerVR are missing a great opportunity by not having an open driver, I worry the main reason they don't is due to FUD rather than any real decision - they 'sell' HW designs, the driver 'comes free' with that. Anything that can cause them to sell more is better, surely? And I'm sure 'easier integration' due to the code being upstreamed in linux & open userspace they can 'try out' before spending $$$ on licensing the hw designs that's good, right?

So yeah, preaching to the choir.

I didn't like PowerVR but I thought if I don't load the proprietary driver and don't use the 3D acceleration it won't mess anything. Do you think that I'm going to have problems with the OMAP 5432 in the Pyra even if I disable, not install or remove any PowerVR software ?

No, there's no issue with just disabling the sgx in the omap. There's nothing 'behind' it, so it's not required to be enabled for any (non-3d) parts of the chip to work, as it has it's own connection to the bus fabric. It also defaults to clocks off and powered down, so if you never load the driver it'll not be wasting power either. (And if you do, it should automatically clock itself off and power down unless there's something waiting in the command queue, so again it'll be off unless you start using it for 3d).

It is also behind a 'full' mmu, so (so long as you trust the hardware, but then kinda all bets are off anyway) it will not be able to access any memory that's not mapped into the mmu. The page tables are purely managed from the kernel driver, all traffic from the sgx (including it's firmware, as there's no real difference other than a 'different mmu context') goes through this mmu, and the sgx itself does not (or at least should not) have mappings to it's own page tables to change what it can 'see'. The kernel driver is all GPL'd, so if you're paranoid (or interested) and wanted to verify what the sgx can access at what time it should be possible by annotating that. I'm not saying the code is clean, or bug free, but it should be possible.

PowerVR's design are that it's actually an extremely powerful general-purpose processor, where it's software-programmed for the most part.

That's not true at all. The sgx 3d pipeline is no more 'general purpose' than pretty much any competitor's core that can run shaders. The 'firmware' runs on the shader core, and the only 'special case' this gets is a mmu context that can read buffers setup from the kernel driver, and enter other mmu contexts to kick other renders. It doesn't 'bypass' the mmu, it doesn't get any special bus accesses in any way. Due to the shader core not really being a good fit for such code, it's rather nasty and written in asm, and is really rather simple.

Our core is possibly slightly more 'programmable' than others, due to most hw blocks (like the rasteriser, the vertex/pixel shader input/output blocks) being programmable, but that's more 'fancy dma block' instead of a 'general purpose processor'. This does make it slightly harder to get working, as all need to be setup correctly to get /anything/ useful out the core, which I suspect is what makes reverse engineering this rather difficult, but I wouldn't consider this a 'software 3d renderer'. Stuff like the texture units/pixel backend/vertex binning/rasterisation are all 'fixed' hw blocks. The shader core on the 544 runs in a simd-vec4 mode (where possible, otherwise it 'discards' 3/4 it's calculations) so it's *really* not general purpose (though is likely technically turing complete, but then again someone 'proved' the x86 mmu fault management is 'turing complete' - doesn't mean you want to write code for anything useful in it!).

Perhaps you were thinking of the first 'Open Source' (HA) release for the vc4 before they hired Eric Anholt to work on a 'real' driver - the VC4 appears to be more like a general purpose processor (or a DSP, so 'more' general than a shader core) and *did* actually run the GLES driver & state tracker & shader compiler 'on-core', so the 'open source' driver they released was just a serialisation layer for GLES commands down into the VC4, hence it being a bit of a joke. Thankfully, their current progress w/the mesa driver doesn't do this, and is much more promising.

you should look up luc verhaegen's talk on "the state of embedded graphics" i think it's called,

I would really like to see this - the only thing I can find is his blog, where he says 'PowerVR is really difficult to reveng' (likely due to the issues above meaning you need to get all your ducks in a row before 'anything' happens at all), so 'other cores will likely provide better results for the same efforts'.

EVEN INTEL ended up hating it because imgtec were f*****g about demanding $150k fees to recompile the software which they themselves NO LONGER UNDERSTAND.

That is not true. The HW 'comes with' full driver source, which is just a 'reference' driver (so will likely only work on PowerVR test chips or other 'reference' platforms. The expectation is that the customer modifies it to work on their platform and ships it themselves. PowerVR do not provide binaries. Yes, a lot went wrong with the Intel projects, but it wasn't this (and I probably can't list what I consider the 'real' reasons, as it'll inevitably be biased, and not the sort of thing 'Some Random Engineer' really can talk about publicly)

I hope that's cleared up a few misconceptions

Jonny

 

[lkcl]

Well RMS's concept of FLOSS is pretty old. And while he clearly opposes software patents, the FLOSS licenses are pretty much blind to them, because apparently nobody in the FSF thought of the possibility to separate licenses and patents to protect intellectual property while formally adhering to FLOSS licenses.
I think a similar thing is happening with privacy right now. FLOSS might be necessary to ensure privacy, but it's clearly not enough. After all, Google, probably the most privacy-hostile company out there, proudly claims to carry the FLOSS banner. And there are more than enough people who won't see that there's no spirit supporting that banner.

frickin tell me about it. i know that Dr Stallman is deeply unimpressed with this, he calls it "SaaSS" - Service As A Software Substitute: https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html - he's quite clever with words like that.

Was that a two-way communication, as in there were at least two rounds of back and forth with answers from them that weren't simply ready-made text templates?

yes.

On a more practical note, I have three questions regarding your project::

great!

1. I don't understand yet, how the whole I/O handling works. How do the keyboard inputs get to the EOMA board, and how does the graphics signal go from there to the display? I would assume that requires some basic OS running on the host's hardware, which would defeat the point of circumventing its potentially malicious CPU. Did I miss some documentation?

5 years catching up on prior development in 2 questions... let me see if i can do it justice ok? ok, you've been over the standard? http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 so you can see there's a few pins GPIO, RGB/TTL for LCD panels, there's I2C, SPI, SD/MMC and 2 USB ports.

let's cover the keyboard first. so, in a budget-constrained overly-simple base board you could use the GPIO as a 16x8 keyboard matrix . or, if you needed some more GPIO than that, you could put in an I2C GPIO multiplier IC like this http://www.ti.com/product/TCA6424A - either way you do it like this guy explains: http://pcbheaven.com/wikipages/How_Key_Matrices_Works/

but those 24-pin I2C GPIO expanders aren't cheap, man! $0.75 or so, bear in mind that an STM32F072 is around $1.50! so the other option is, you just plug in a USB keyboard. simple - sorted. except... if it's a laptop, you need to *embed* the USB Keyboard Controller IC, that's $1.50 in components. wait... hang on, that's the same price as an STM32F072, and we got a whole stack of other things that need doing, so wtf?? and if we connected both a dedicated USB Keyboard Controller IC *and* an STM32F072 (to cover battery monitoring, mouse trackpad, power management and so on) there's not enough spare USB ports so we'd need *another* $1.50 for an extra USB 4-port hub... *THAT* means we exceed the power budget of the 15W PMIC...

.... dang

ok so, how about using some of the 64 pins of the STM32F072 to do a 16x8 keyboard matrix ourselves, then do the firmware ourselves just like google did with one of its chromebooks? and make it a libre software project, and publish a USB-HID endpoint from the STM32F072 as a keyboard? and, ta-daaa, that's what i've done: http://git.rhombus-tech.net/?p=eoma-firmware.git;a=shortlog;h=refs/heads/master


the display is much easier to answer: 18-pin RGB/TTL. in the laptop i use an SN75LVDS83b (or its chinese clone equivalent... hilarious that that IC got cloned...) and that converts to LVDS for the 1366x768 LCD. it's really simple and straightforward. in the case of the micro-desktop VGA output, the analog lines (R, G and B) are done as 3 crude-but-effective D-to-A converters made using six 0.5% accuracy resistors. take the digital outputs of RGB/TTL, convert to analog. done.

but basically, i've covered this on the mailing list - it'll be hard to track down where as it's been five years. i've done my best but i have had to choose what to focus on, to get stuff done. sorry

2. I see you're using the PC-Card form factor. Are there any plans to use other form factors, like Expresscard or maybe something like a DVD bay caddy? I'm asking, because I don't have any laptops with PC-Card slots, but several with Expresscard slots and unused DVD drives.

noow you're getting it basically the idea is to re-use stuff that people are discarding, that way *we* can consider making things on a reasonable budget instead of requiring $0.25 million and above in VC-funded investment, losing control of the project even before we started, and being beholden to people who only care about money not about ethics or why software libre actually exists.

yes i have a standard in development which uses ExpressCard - it's called EOMA26. the other one is EOMA54: surpriiise, it uses CompactFlash we did consider DVD caddies but the number of pins (with SATA) is too small, and IDE DVD is kiinda too out-of-date now so the tooling won't really be around. DVD caddies are also quite big, so would be able to fit an entire high-end PC in there.... heat becomes an issue... you'd also want lots more pins (around 200) because you'd want PCIe, SATA, lots of USBs.... yeah. man, that discussion goes back around 4 years on the mailing list.

3. Crowdsupply only seems to accept credit cards, which I don't use. Is there a way to support you via SEPA?

first, talk to support@crowdsupply.com and cc me, luke.leighton@gmail.com i'm sure we could work something out including potentially talking to one of my friends (or to thinkpenguin, just thinking out loud here) and putting it on someone else's credit card... have to check if that's okay with crowd supply first though - don't take it as gospel ok! it's crowd supply who are handling the campaign, that's the agreement we have with them: even using someone else's credit card might not be within the agreement, ok? so yeah, email them, cc me, we'll talk about it.

Edit:
Effectively Debian already did. Jessie/i586 doesn't run well, because all the x86_32 software is compiled on i686, even the i586 packages.
This introduces implicit dependencies on i686 instructions (e.g. cmov, fucomip), which makes certain software crash on i586 hardware.

damn. then the LX800 is history. which is a real shame. it's an awesome SoC. auto-clocking. National Semi did an incredible job there.
[doublepost=1467743605,1467742740][/doublepost]

We can argue all we want about the requirements that should go in a certification, but it would be very strange for any ertification by anyone to modify the requirements once there are already certified products in the market.
What would they do ? Decertify some products ? Tell some products that part of they efforts turn out not to be necessary ?
IT would be very little credible. Whenever a certifier wants to change criteria they have to start a different certification.

hooray! someone who gets it! this is *EXACTLY* why i spent five years making damn sure i was as happy as i could be with EOMA68, because if you're going to make any changes they had better damn well be both backwards *AND* forwards compatible (yes, really: forwards-compatible).

this is what the CEO of Linaro didn't understand when he posted the "we can always fix it later" response to my post-mortem examination of the 96board "fait-accomplit" standard which was developed without any public consultation. aaargh, man, YOU CAN'T!

the way that EOMA68 manages to be forwards-compatible is to be made up of standards that themselves have a proven track record of being upgraded and made faster *OVER THE SAME WIRES*. SD/MMC for example. 1, 2, 4 and 8-bit variants. DDR was added recently, doubling the speed over the same wires, but it's negotiated at the hardware level. USB 1, 1.1, 2.0 are all on the same wires.

for a standard to work, *nothing* must be "optional", there must be *NO* mutually-exclusive options (multiplexing of complex functions onto the same pins), and *NO* incompatible changes.

I asked crowdsupply recently, no news yet.

send me what you wrote, cc me (luke.leighton@gmail.com) bear in mind it's been a holiday in the US (4th july).
[doublepost=1467744033][/doublepost]

In the case of the Neo900 project, the devs tried to get RYF certification, but since the proprietary modem firmware (same as in the Pyra) could be replaced, the FSF considered it software and rejected a certificate. They even asked the Neo900 team to make the modem firmware irreplaceable, because then the FSF would consider it to be hardware, therefore wouldn't care about it and issue a certificate. The Neo900 devs refused to do that, claiming that if the firmware were found to be malicious, it could at least potentially be replaced by the user with a clean one, therefore restoring privacy.
I think from their respective points of view, both were right. The Neo900 should not get a RYF certificate. But it should also not have a fixed modem firmware.

i explored this with Dr Stallman several years ago, patiently going over this with him, back iiiin.... 2010? we came up with a potential strategy but it was just.... frickin hard to do, let alone justify.

so this is why i dropped *ALL* those low-cost MMC-based WIFI SIP modules, period. they are ALL proprietary. instead, i decided that the designs i would make would use USB dongles, so that people could drop in RYF-Certified USB products such as those from Thinkpenguin. this is why the laptop housing has two internal USB ports.

there are other reasons as well: the MOQs on those MMC-based WIFI SIP modules are insane. they're specialist items which factories don't hold in stock. they are also under NDA so don't want to supply you unless *you* sign an NDA... it's completely mad, and a very risky or costly proposition to consider using them, if you ask me.

so, having cut them from the picture, we're down to a very simple Computer Card that has no proprietary-firmware co-processors, so we are literally one of the first people that might actually successfully get an RYF Certification on an embedded-style computer available today [LOTS of people have tried applying for RYF on A20 boards. they all have MMC-based proprietary WIFI]. which is kinda scarey and awesome at the same time.
[doublepost=1467744150][/doublepost]

Hi, there seems a bit of misunderstanding/misinformation in this thread I'd like to try to clear up.

appreciated, man. i just have this gut feeling which says "stay the hell away from PowerVR", i know people like luc verhaegen has actually worked with it, he gave a talk about the state of embedded graphics a couple years back, the video's available online. i haven't the time to know all the details (too much to do), so appreciate the clarification.

 

[Exophase]

the problems with PowerVR's design are that it's actually an extremely powerful general-purpose processor, where it's software-programmed for the most part. the actual core 3D engine software was written over 15 years ago, it's extremely hard to understand, the key critical engineers who understood it have left, and anyone else coming in just f***s it up.

Where do you get this information?

It's important to understand that PowerVR underwent a major architectural shift between Series 5/5XT (SGX) and Series 6 (Rogue). Changes since then have been more incremental. Even shader binaries written for Series 5 won't work on Series 6, yet alone anything lower level. So nothing that could have been written 15 years ago, although I doubt SGX was designed that early. That's the era of GPUs like Kyro which were much different and much less programmable.

As far as anything I've ever seen on the architecture goes it isn't really any more or less programmable or software defined than any other current GPU architecture. It has hardware triangle setup, rasterization, alpha blending, depth/stencil test/update, texture units etc like other GPUs, and like other tilers today it has a hardware tiling unit.

all they f*****g well have to do to sort this out is give us the f*****g source code and documentation.

You could say that about ARM and Qualcomm (or Vivante if anyone's still looking at that), and it's not like they don't ever produce buggy drivers that end up crashing the whole OS either...

tyou should look up luc verhaegen's talk on "the state of embedded graphics" i think it's called, he is absolutely SCATHING of the piss-poor design of PowerVR.

AFAIK he's never worked on anything newer than SGX so I don't know if the newer archs are as bad.

The big issue with Rogue and beyond, and I think the big reason why we don't see much of a reverse engineering effort going on with it, is that not a lot of non-Apple devices are using it. Far fewer than Mali. It hurts that TI exited mobile SoCs before switching to it and Intel never came out with phone-oriented 14nm chips that would have been using it.

honestly when things calm down a bit here i can take a look - i know that the team who built the pyra were not receptive to me being on these forums back when a third party posted a "hey there's this thing called EOMA68" message a couple years back. times change, though...

I think you got the wrong impression here..

Back then weople were arguing against EOMA68 being a good solution for Pyra. Which I stand by, I think it'd be a lot worse than what we're getting (which I still have various issues with). But that doesn't mean that people can't see the value of EOMA68 in other devices, or its overarching ideological value. And I don't think anyone wants you to leave the forums regardless...

 

[JonnyH]

appreciated, man. i just have this gut feeling which says "stay the hell away from PowerVR", i know people like luc verhaegen has actually worked with it, he gave a talk about the state of embedded graphics a couple years back, the video's available online. i haven't the time to know all the details (too much to do), so appreciate the clarification.

As far as I'm aware, Luc said "Stay away from PowerVR as it's hard and poor return-on-investment" more than "PowerVR is evil/in some way 'worse' tehnically (just different " - of course I could be corrected as I haven't seen (or found with a quick google) the talk you mentioned.

To be honest, the whole mobile graphics market is terrible for OSS or freedom-focused use cases. I would love to be able to change that, but quoting inaccuracies doesn't really help that. There's plenty wrong with PowerVR's architecture without things of questionable accuracy.

It's important to understand that PowerVR underwent a major architectural shift between Series 5/5XT (SGX) and Series 6 (Rogue).

There's a massive incompatible shader difference between 5, 5XT and Roguec (IE 5 and 5XT are completely different too - moving from a SIMD to a VEC4-SIMD for most instructions, then rogue to a scaler shader core). They were never designed for any sort of cross-compatibility with ISAs. There are even differences in shader instructions based on customer 'options' for features etc. that can be enabled/disabled independently of the marketing name. It's a mess if you want this sort of compatibility.

 

[Exophase]

There's a massive incompatible shader difference between 5, 5XT and Roguec (IE 5 and 5XT are completely different too - moving from a SIMD to a VEC4-SIMD for most instructions, then rogue to a scaler shader core). They were never designed for any sort of cross-compatibility with ISAs. There are even differences in shader instructions based on customer 'options' for features etc. that can be enabled/disabled independently of the marketing name. It's a mess if you want this sort of compatibility.

Right, I shouldn't have suggested Series 5 and 5XT were in any way compatible. Series 6 was just a more significant change. The idea that pretty much anything written 15 years ago could be applied to a GPU today isn't really credible. Even the purely driver managed stuff would have changed a lot with 3D API evolution.

Being able to substantially alter the architecture without regard to binary compatibility every single generation is a big advantage GPUs hold vs say, CPUs (except ones like Denver). But also a big headache for reverse engineering.

 

[_jr_]

This doesn't necessarily make it right though. It's a good thing, but a good thing doesn't immediately negate a bad thing. Looking back at the assassin analogy, but looking at the assassin himself: if you murder someone for money and then donate that money to charity you aren't absolved of the murder. If caught, the court isn't going to go "well, you did donate that money to charity, so I guess you're off the hook"; you'll get a trial and a sentence just like any other murderer.
I have no idea what AllWinner's "trial" and "punishment" should be, but this is probably a step in the right direction.

Sorry for grave digging this branch of the discussion, but it might be illuminating that one of the major changes in V3 of the GPL is such a you're off the hook clause that is activated just by starting to comply with the license (any previous misbehaviour may still be the object of a lawsuit, obviously). It really is about distributing free software as pragmatically as possible (while keeping it free).
[doublepost=1467755654,1467755098][/doublepost]

Note, I'm not trying to defend 'closed' drivers, I (personally) believe PowerVR are missing a great opportunity by not having an open driver, I worry the main reason they don't is due to FUD rather than any real decision

In my experience the problem is the naive fallacy that the value of a piece of software should be related to the cost of creating said piece of software. That is almost never true, since usually the investment is mostly converted into developer know how and code is just a by product.

 

[JonnyH]

In my experience the problem is the naive fallacy that the value of a piece of software should be related to the cost of creating said piece of software. That is almost never true, since usually the investment is mostly converted into developer know how and code is just a by product.

Exactly, PowerVR doesn't sell software. The driver is 'part' of the HW design. It's not useful without it at all, and therefore has 'zero' value.

The real worry is that there's some *magic* in there somewhere that will lost a competitive advantage by telling someone how our HW works (which is unlikely from my POV) or some patented thing someone will sue us for.

Even if these are 'negligible' risks, they are non-zero. And current SW management do not see 'any' benefit to OSS (IMHO incorrectly). Therefore the decision is 'ANY risk > zero benefit. No. Next question'

 

[lkcl]

Where do you get this information?

i have a friend who knew the original designer of the processor that went into the PowerVR engine. he told me the story about it. so... third-hand... i'm sure stuff got lost in translation... and you're right: stuff gets updated...

I think you got the wrong impression here..

this is very likely..

Back then people were arguing against EOMA68 being a good solution for Pyra. Which I stand by, I think it'd be a lot worse than what we're getting (which I still have various issues with). But that doesn't mean that people can't see the value of EOMA68 in other devices, or its overarching ideological value. And I don't think anyone wants you to leave the forums regardless...

i get a little oversensitive to things at times... appreciated exophase.

 

[pyrat]

Hi, there seems a bit of misunderstanding/misinformation in this thread I'd like to try to clear up.
No, there's no issue with just disabling the sgx in the omap. There's nothing 'behind' it, so it's not required to be enabled for any (non-3d) parts of the chip to work, as it has it's own connection to the bus fabric. It also defaults to clocks off and powered down, so if you never load the driver it'll not be wasting power either. (And if you do, it should automatically clock itself off and power down unless there's something waiting in the command queue, so again it'll be off unless you start using it for 3d).

It is also behind a 'full' mmu, so (so long as you trust the hardware, but then kinda all bets are off anyway) it will not be able to access any memory that's not mapped into the mmu. The page tables are purely managed from the kernel driver, all traffic from the sgx (including it's firmware, as there's no real difference other than a 'different mmu context') goes through this mmu, and the sgx itself does not (or at least should not) have mappings to it's own page tables to change what it can 'see'. The kernel driver is all GPL'd, so if you're paranoid (or interested) and wanted to verify what the sgx can access at what time it should be possible by annotating that. I'm not saying the code is clean, or bug free, but it should be possible.

Thank you. That's very useful info.

i just have this gut feeling which says "stay the hell away from PowerVR", i know people like luc verhaegen has actually worked with it, he gave a talk about the state of embedded graphics a couple years back, the video's available online. i haven't the time to know all the details (too much to do), so appreciate the clarification.

I would really like to see this - the only thing I can find is his blog, where he says 'PowerVR is really difficult to reveng' (likely due to the issues above meaning you need to get all your ducks in a row before 'anything' happens at all), so 'other cores will likely provide better results for the same efforts'.

I'm not sure which libv talk lkcl means,

• 2013 FOSDEM Open ARM GPU drivers Where are we today, one year after the unveiling of the Lima driver.

35:19 about PowerVR​

• 2014 FOSDEM on Lima driver (for "older" Mali GPUs from ARM)
• This is a 2015 FOSDEM talk on his unfinished, unpublished work on Tamil, a driver for Migard, Mali-T , the "newer" GPU from ARM.

Or maybe it wasn't Luc but Rob Clark ?

• Phoronix article with a similar title: The State Of Open-Source ARM GPU Drivers
  • Slides PDF
  • Talk video
• 2013 Linux Plumbers Conference. Open Source Graphics on ARM - Rob Clark, Red Hat

I don't have time now to watch all this.

That is not true. The HW 'comes with' full driver source, which is just a 'reference' driver (so will likely only work on PowerVR test chips or other 'reference' platforms. The expectation is that the customer modifies it to work on their platform and ships it themselves. PowerVR do not provide binaries. Yes, a lot went wrong with the Intel projects, but it wasn't this (and I probably can't list what I consider the 'real' reasons, as it'll inevitably be biased, and not the sort of thing 'Some Random Engineer' really can talk about publicly)

I hope that's cleared up a few misconceptions

Jonny

Thanks. I assume these sources (that don't work on real SOCs) are proprietary licensed, NDAd, etc. right?

first, talk to support@crowdsupply.com and cc me, luke.leighton@gmail.com i'm sure we could work something out including potentially talking to one of my friends (or to thinkpenguin, just thinking out loud here) and putting it on someone else's credit card... have to check if that's okay with crowd supply first though - don't take it as gospel ok! it's crowd supply who are handling the campaign, that's the agreement we have with them: even using someone else's credit card might not be within the agreement, ok? so yeah, email them, cc me, we'll talk about it.

They answered that wire transfer is possible, on a manual basis, not what they have automated or so, but they can adapt for a few cases I guess.
They don't want to publish their bank account number. I'm not sure what's the risk on that, but I'm not good on those things, there may be a reason.
They may send me an encrypted (hopefully signed) bank account number by email if I send them an order.
They don't have banking in the SEPA area, so no SEPA. They hinted at https://transferwise.com/ which I know nothing about. I tend to dislike intermediaries, but I'll sort it out later.

send me what you wrote, cc me (luke.leighton@gmail.com) bear in mind it's been a holiday in the US (4th july).

I'll PM you. I didn't mean they were late to answer, just that they didn't have time. I didn't remember the 4th of july. They answered the 5th at 10 or 11 AM.
I wasn't complaining or anything, sorry for my English.

 

[JonnyH]

Thanks. I assume these sources (that don't work on real SOCs) are proprietary licensed, NDAd, etc. right?

Yes, *sadface*

 

[pyrat]

Yes, *sadface*

Don't be sad. It's as bad as it was, now at least some of us are a little less ignorant. You're probably helping as much as you can.

 

[vinipsmaker]

https://www.crowdsupply.com/eoma68/micro-desktop

TL;DR: a standard for laptops where you can eaily (in seconds) replace/upgrade only the board/shell. It's like being able to carry your computer around on your wallet. And the best thing: the possibility to run on free (as in freedom) open hardware

 

[TrashyMG]

Old news, also what does it have to do with the pyra?
https://pyra-handheld.com/boards/threads/really-cool-modular-and-freedom-respecting-computer.77612/

 

[rygD]

There are already some other threads about this, including a recent one that was fairly active.

Edit: Too slow.

 

[TrashyMG]

Interesting discussion on the other thread, especially with the freedom respecting aspect being question since AllWinner loves violating GPL agreements.