Power, Memory and Schematics


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,986
Age
46
Location
Ingolstadt
Pheww, that was quite a while ago that I posted news!
I had ENOUGH new stuff to post, but I'm stuffed with different work right now - not only Pyra-related but also in my normal daytime job (yep, the job is not my main job).
This resulted in having about 4 hours of sleep each night last week, so I really didn't find the time to summarize everything that happened.

But now it's Sunday, and while I had to work yesterday and last Sunday, I didn't have to work today and therefore can finally give you some up-to-date information!

It was a pretty crazy time since the last update, and I've got some good and also bad news for you. I had hoped to only have good news... but well, bad things can happen as well and I won't hide them from you.

So, let's start, shall we?

1. The case

The final changes have now all been implemented. FormAction plans to produce a bunch of cases tomorrow (at least thirty, so enough for all prototypes).
They also already created the molds for the silicon that's needed to seal the speakers, and hopefully we'll get those preapplied to the cases as well.

Can't wait for them :)
Once we got them and the keymats, I can finally build the prototype units for devs and the ones who ordererd one.
We might sell a few more of them as well, but not before they're ready to be shipped.


2. CPU-Board

Well, we got some good news, some bad news and something inbetween :)

First, here are the good news:

29 out of the 30 produced CPU-Boards work fine!
That's a perfectly fine failure rate and a definitive improvement over the first production run (where only 10 out of 18 produced CPU-Boards worked, and even some of those needed rework).
So Global Components is now ready for mass production, there shouldn't be any issues with that.

Now for the bad news:
The 1,5GHz freeze has not yet been fixed. We had hoped that the one trace we cut was the issue, but it wasn't
Therefore, the last 1,5 weeks we spent quite a bit of time figuring out what's going wrong here - and I guess we're pretty close!

The OMAP5 (and probably all new SoCs) are A LOT more picky when it comes to power supply and voltage stability than the OMAP3 or other SoCs.
We've spent nights figuring out whether it's purely hardware based or whether it can be fixed with software.
And we really got some improvement: My unit now runs stable at 1,2GHz, but that's the maximum we were able to achieve with our current setup.

Getting the power supply is actually a pretty complicated thing. It depends on a number of capacitors with different values, different traces and trace lenghts, the amount of layer in the PCB, the number of vias, and and and.
So this is not something generic you can build - if the power management chip is a bit further away from the OMAP5 than on a different board or you got more or less layers, you need different capacitors.
And as there's also other stuff on the CPU board (like the DRAM) that has special requirements as well, you can't simply design a perfect power supply circuit.

It's a puzzle with compromises, and with the correct set of changes and capacitors at the right places, you can improve things until they're good enough that everything works.

Nikolaus already included numerous improvements last week (he had to read A LOT of OMAP5 design documents for that...) and he will also try changing the capacitors on our CPU boards as well to see if that improves things or makes them even worse.
We're still doing more tests with both the CPU Boards and the EVMs to find out more improvements and I'm sure the next bunch of CPU boards will work perfectly fine, but it means we need to produce another small batch to test our fixes as well.

BTW: I had to smile a bit when I read today that the GPU driver crashes of the GPD Win have a similar issue: Power supply instability.
It only affects a couple of SoCs and can be fixed by replacing some resistors, but it's actually very very similar.
Yes, these modern CPUs sure are evil beasts!

We're not that far off though - 1,5GHz single core runs without any issues as well as 1,2GHz dualcore. So it's probably just a small improvement we need - and that's certainly a good thing.

So, what about the "inbetween"?
Well, memory prizes are currently going haywire!
Memory is getting more and more expensive, so I had to order the memory for the mass production right away, otherwise, it could be that it would be twice as expensive!

The problem is: While we have CPU-Boards with the 4GB RAM chips assembled already, we haven't had the time to update the kernel and bootloader yet.
We know that 2GB work perfectly fine (even with the 4GB RAM chips installed), but we don't know whether the additional 2GB will work properly as well.
They should, though, as it's a software change that enables the usage of the additional 2GB RAM, but it's untested.

Well, testing that is one of the next things on our to-do list. And in case they REALLY don't work, we can probably sell the 4GB chips for a higher price than we bought them for ;)



3. The schematics


As promised, the Pyra will be more open than the Pandora and Nikolaus had some time to clean up the schematics!
Attached to this post are the schematics for the current revision (5.1.3) of the Pyra. Unless a bug is found, these won't change anymore.

Feel free to look through them, learn from them - or report any potential issues you find to us, so we can check them!

License is CC-BY-NC-SA which means you can use and distribute them - except asking for money for a copy of this document or parts of it.

This does not exclude that you study the ideas and make your own (commercial) designs, because that is not covered by a document licence. But please let us know if you do that... We might be interested in learning your ideas as well :)

So much for today, I'll post news as soon as something happens AND I find the time :D
Feel free to ask any questions here at this thread!
 

Attachments

  • Pyra-Schematics.Rev5.1.3.zip
    1 MB · Views: 1,319
It's an issue that can be resolved, it runs properly on the OMAP5 EVM devboard. It's likely some minor issue.
Oh right I forgot about the EVM. But still, the way ED described it, it sounded virtually impossible to solve.

EDIT: I'm sure it can be done though!
 
Hopefully this is temporary? Can it be changed to a free license after the final products ship?

It's only the non-commercial aspect that makes that license non-free as far as I can tell. Presumably if you wanted to relicense it from ED you can talk to him and agree a fee, so I don't mind that restriction personally.

Thanks for the update ED. I can't do much from here to help you find a solution, but you have my best wishes. Go go team Pyra!
 
Many thanks for the update and your hard work! Better sleep more and deliver later. I'm really impatient about getting the Pyra in my hands, but not at the price of your health, please!

Memory:
I ordered a 4GB Pyra, but I think I can live easily with the 2GB variant as well :~) Also 2GB means less power consumption than 4GB. I don't worry about this!

License: I really hope, you reconsider this. CC-BY-NC-SA is clearly a non-free license and the limitation on "non-commercial" use has a lot of bad implications. Think about this: I am a developer (well the least important one of ~1000 developers) of a free OS. You can use it for Pyra and you can make money with it. I even hope, you make a lot of money :~) This is, because we make software that has no limitation regarding commercial use. One reason I ordered a Pyra is, because it is supposed to be an open hardware running free software. This is really an USP (https://en.wikipedia.org/wiki/Unique_selling_proposition)! Note, that e.g. the Turris Omnia router uses the CERN Open Hardware License (CERN OHL), which is IMHO a very good license for open hardware projects.
 
License is CC-BY-NC-SA which means you can use and distribute them - except asking for money for a copy of this document or parts of it.

This does not exclude that you study the ideas and make your own (commercial) designs, because that is not covered by a document licence.
I think that 2nd part might be a problem with a NC license.
If I study your design and then design my own commercial(!) product based on what I learned from your design, then my design would be a derivative of your design. I'm not sure I would be allowed to sell that product based on that license.
I believe it hinges on whether my design is a part of my product. I'd think it is.

it sounded virtually impossible to solve.

EDIT: I'm sure it can be done though!
Now THAT is the definition of faith! ;)
 
I think that 2nd part might be a problem with a NC license.
If I study your design and then design my own commercial(!) product based on what I learned from your design, then my design would be a derivative of your design. I'm not sure I would be allowed to sell that product based on that license.
I believe it hinges on whether my design is a part of my product. I'd think it is.
What we need is a licence that prohibits charging for the schematics, but allows charging for a product made using them. Surely there is a solution?
 
I think that 2nd part might be a problem with a NC license.
If I study your design and then design my own commercial(!) product based on what I learned from your design, then my design would be a derivative of your design.
That even contradicts the FSF's understanding of a derivative work: Using and copying the original or parts of it makes a derivative, simply applying knowledge learned by studying the original doesn't. Does the CC license even cover this part or are we talking about a lack of properly defined legal terms in varying national laws again?
 
License is CC-BY-NC-SA which means you can use and distribute them - except asking for money for a copy of this document or parts of it.


Great thank you very much for opening up the pyra material!

Regarding the nc clause, while it is maybe very reasonable to use this clause now, core issue with it is the ambiguity of "commercial". Which might prevent community usage as collateral damage (additionally to wkipedia or wikimedia commons usage). An elegant solution which would release such deadlock at least in the future could be a time-bomb license, e.g. an additional clause which states that the material switches to cc-by-sa in 2 years automatically. (Like it is used here http://www.boyter.org/2016/08/gpl-time-bomb-interesting-approach-foss-licensing/ )

Ps: the "share alike" is already quite strong on its own in preventing malicious misuse without giving back, as we learned in the software domain from the GPL, nc not needed
 
Last edited:
I fully condemn the decision to put restrictions on commercial use of the schematics. But I don't expect to influence your decision regarding that, so if you're going to insist on that restriction, I want to implore you to also forbid modifications. The reason: non-commercial restrictions are infectious to at least the same extent as copyleft. If you have, say, 10 people modifying an NC-licensed work, that means you need to go and get permission from all 10 of those people for any commercial use, which depending on the circumstances may be impossible. This property is only acceptable if you consider all commercialism to be something you want to oppose, which I'm sure you don't. In this sense, a fully proprietary license is better than a license that permits modifications but not commercial use.
 
Two operating cores require more current than one operating core, so you may need to either increase the voltage or reduce the resistance when two cores are running.
 
I'd have thought he does want to forbid all commercial use of these designs, to stop Chinese copycats from making boards based on these schematics (although concrete layouts would be much more useful for that I guess).

There might be a problem down the line if he accepts copyrighted changes from others and incorporates those if he then wants to re-licence it, but I doubt many people will submit changes, and those that do will probably allow ED to sublicense those changes as he sees fit (which is something ED should insist on before accepting those changes).

And I'm slightly concerned that these bits being NC might have an impact on those using the interfaced defined in these schematics to make hardware mods that they might want to be able to sell down the line, but I'm not sure if interfaces are subject to licenses like that, and anyway, despite a number of homebrew hardware hacks for the Pandora, nobody made a business out of selling them, and given there's less space inside the Pyra case, I'd guess that's even less likely for the Pyra.
 
I think the 4GB is more important than 1.5GHz, or maybe both are not that important for end user. Rock stable is the most important thing.

Sent from my SM-G900F using Tapatalk
 
I think we'll have to say goodbye to the hope of getting a descent camera, there is just a single sine of the mipi interface. Enough for ~2MP, but not for 8MP or higher. Still very excited about it! :D

S5Np
 
Back
Top