Pyra News: Springs are brilliant!

[sebt3]

With the Pandora, my main job was handling the community. I was NOT handling any of the hardware production, etc.

Wrong.. Your job was to handle the fallout of each craigx post... and that was a heck of a job if you ask me

 

[linx]

@EvilDragon How long are you gonna stay in Greece this time? You should leave a prototype at the new company in Thessaloniki so I can go there and play with it later this summer.

 

[levi]

GPS, Altometer, Hygrometer, Barometer and Compass are only available in the mobile edition.

Ah, now I've looked at and checked the 2016 schematics release, I understand better why some of the chips are crossed out on different versions (sometimes it's because a better chip had been found, sometimes it's because something's only optional, and sometimes it's because they're removed from the standard edition). So yes, no sensors on the standard edition, but to bring it back to the original question, both revisions have the vibramotor included, which I guess in English means we all get haptics/rumble.

 

[EvilDragon]

@EvilDragon How long are you gonna stay in Greece this time? You should leave a prototype at the new company in Thessaloniki so I can go there and play with it later this summer.

I'm leaving on Thursday... so yeah, only a short trip.
They will receive some units, but I don't know if they will already have some in summer. You might want to ask azouls if you can come visit though

 

[fusion_power]

Only thing I'm a bit worried about is the software - it's still nigh impossible to find devs with time who are able to do low-level coding :/

I don't want to sound rude, but you actualy had YEARS to find some, during the Pyra development. Enough time for spreading the word at least. I can't imagine there are no talented people out there who would like to tinker on a promising open source handheld.
Or did GPD catched every available talent? (I would not be surprised, actualy).

 

[CommanderB]

I don't want to sound rude, but you actualy had YEARS to find some, during the Pyra development. Enough time for spreading the word at least. I can't imagine there are no talented people out there who would like to tinker on a promising open source handheld.
Or did GPD catched every available talent? (I would not be surprised, actualy).

I think that the big issue is the lack of hardware - it is extremely hard to develop drivers for systems that you can't put your hands on

 

[EvilDragon]

You're very welcome to provide some, if you like to.
Where are all the talented low-level devs GPD has you speak of?
99% of their setup including drivers has been provided by Intel, most of the rest by the manufacturers of the chips.
As most manufacturers have Windows drivers available.
The documentation and documents Intel provides are awesome.
And a company supports you if your order is big enough, these companies provide you with great support.
The only way we could even get the OMAP was by acknowledging we won't receive any support.

They still have annoying bugs left in a lot of their systems (like the GPD Win 2 stopping charging when you go to sleep mode so you will have an empty battery when that happens - or the GPD Win often only showing half of the screen in a lot of games or not being able to start the GPD Win when it's connected to the charger...)

Apart from that, they have around 10 times as much funding than we have (if that's even enough).

They don't even need any Linux lowlevel devs.

We are in the great situation of using an SoC that has been abandoned by the manufacturer and a lot of stuff is unfinished.

So, please find devs who do that for a reasonable price if you think it's that easy and all I did was sitting around twiddling thumbs or donate 200,000 EUR to me, because I'm sure I can get a company for that price that will handle that.

 

[elw3]

Only thing I'm a bit worried about is the software - it's still nigh impossible to find devs with time who are able to do low-level coding :/

This is a community project after all and i totally think its our job to tackle the software side.
So focus on the hardware, then sit back, relax and hit us users with a whip till we improved the drivers.

 

[pmprog]

This is a community project after all and i totally think its our job to tackle the software side.
So focus on the hardware, then sit back, relax and hit us users with a whip till we improved the drivers.

Interesting way of looking at it. So you'll have the drivers ready by Thursday?

As ED is struggling to find a developer, that kind of implies that this community doesn't have such a person with sufficient time and/or interest... Otherwise I'd have expected them to come forward some time ago.

 

[fusion_power]

I think that the big issue is the lack of hardware - it is extremely hard to develop drivers for systems that you can't put your hands on

True, but if I remember correctly, dev-boards are out in the wild since a while.

Where are all the talented low-level devs GPD has you speak of?

That's the question. ^^"

99% of their setup including drivers has been provided by Intel, most of the rest by the manufacturers of the chips.
As most manufacturers have Windows drivers available.
The documentation and documents Intel provides are awesome.

Well, then going Intel sounds like the logical and les stressful way I guess.

And a company supports you if your order is big enough, these companies provide you with great support.

Are the quantities of GPD's devices known? It's bigger than Pyra but still really niche devices. Maybe Intel provides programs for small companies who only need a couple of hundred chips. Just to piss of AMD or whatever. ^^"

The only way we could even get the OMAP was by acknowledging we won't receive any support.

That's actualy....weird...

So, please find devs who do that for a reasonable price if you think it's that easy and all I did was sitting around twiddling thumbs or donate 200,000 EUR to me, because I'm sure I can get a company for that price that will handle that.

You get me wrong. I never sayed it's easy, I just assumed the many years during the Pyra development would have lead to the attention of the "right" people. Because it sounds like most of the "core" Software stuff is not even existant. Of course you need the hardware first, we had hope that going the Debian route would make stuff much more easy and compatible, compared to the quirky Pandora software development.
Not sure if the choosen OMAP is easier or harder to develop for. I guess, today you would look first if the choosen Chip also has propper software documentation and support. This should be a standard in the Chip industry, actualy. At least I hope so. Otherwise it is indeed hard to find people who can code "low level" stuff for an (abandoned) SoC without official support and documentations.

 

[matzesu]

I think there are some Pyra Related things that the Devboard dosnt have, like Batterie Management, and LCD Display, and this 3 Board Thing..
Or the 3G Module..

Apropos 3G: I just saw i can get 3 Sims whit my Cellphone Tarif: One in my Phone, one for the Smartwatch and the 3th will be for the Pyra ..

 

[EvilDragon]

True, but if I remember correctly, dev-boards are out in the wild since a while.

That doesn't help if the devs have no time.

Well, then going Intel sounds like the logical and les stressful way I guess.

So, throw away around 300k EUR development costs to start from scratch?
The PCB would need a complete redesign, the system would need active cooling (which means a complete case redesign, etc.)
When we started, no Intel CPU was useful. No other CPU was useful.
If we'd start now, we'd probably use the i.MX8, as it has bigger support.
But that one wasn't available back then.

It was a lot of bad luck (or bad timing), but we cannot simply throw 300k development costs away and start anew.
We're no multibillion-Dollar-Company.

Are the quantities of GPD's devices known? It's bigger than Pyra but still really niche devices. Maybe Intel provides programs for small companies who only need a couple of hundred chips. Just to piss of AMD or whatever. ^^"

I'm guessing around 20k GPD Win 2 are out in the wild.

That's actualy....weird...

No. Usually, you only get support from the manufacturer is if you buy at least 100k of their chips.
That's why there are so many generic Chinese tablets out there that all use the same generic design: The manufacturer released a reference design and they simply use that and produce it.
Then they don't need ANY support from the manufacturer.

Only if you add your own stuff is when things are getting complicated.

TIs reference design used 2GB RAM. The 2GB RAM Pyras worked out of the box.
Now just take a look what switching to 4GB RAM has brought us to: about a year delay and around 50k EUR additional costs. Just to get it to work properly.

It's just a small change from the reference design - and this is the result.

I already said multiple times: What we're doing here is something COMPLETELY different to most of the handhelds out there: We're doing TONS of custom stuff, not just using reference designs and putting them into a shell.

You get me wrong. I never sayed it's easy, I just assumed the many years during the Pyra development would have lead to the attention of the "right" people. Because it sounds like most of the "core" Software stuff is not even existant. Of course you need the hardware first, we had hope that going the Debian route would make stuff much more easy and compatible, compared to the quirky Pandora software development.
Not sure if the choosen OMAP is easier or harder to develop for. I guess, today you would look first if the choosen Chip also has propper software documentation and support. This should be a standard in the Chip industry, actualy. At least I hope so. Otherwise it is indeed hard to find people who can code "low level" stuff for an (abandoned) SoC without official support and documentations.

Don't mix up the OS with Kernels or drivers.
Debian is fully running on the Pyra. That's nothing "core" that's just the OS on top of the kernel.
The OS isn't the problem. Kernel things are what's still missing.
The Pandora had a LOT of kernel stuff added by us - luckily, we had notaz back then, but he doesn't have time anymore.

The OMAP5 is VERY well documented. Better than most SoCs out there.
But that's over 5000 pages documentation. Someone needs to implement all the timings, hardware registers, etc. into the driver modules so that everything works fine.

Audio works, but the driver doesn't have DC Offset included. We need to use DC Offset, and the chip supports it - so someone has to read the hardware documentation and include that into the driver.

TI never finished the graphics system properly. That's why rotation with TILER was terribly slow, until zmatt made a quick hack to show it can be done in fullspeed.
But TI didn't have a huge customer who was in need of that - so they never took care about it. And why should they? Android uses OpenGL for the rotation, and that was probably the main use case for the chip.

The OMAP-Series was specifically designed for Nokia-Phones. All Nokia-Smartphones used OMAPs. The OMAP5 should've been the next iteration. Microsoft bought Nokia, and the OMAP5 didn't have any huge customer anymore. The mobile version (which we wanted to use) wasn't even released, only the automotive version.

So yep, a lot of bad luck.

Now, for developers:
Nikolaus knows developers from the GTA04 times. I do know some from the Pandora-times.
They all don't have time anymore. Normal work is holding them up, so they can't really help us. If they help, it's just little things.

We even did ask some companies who are specialized on Linux kernel stuff. They're all overbooked right now.

Times have changed. Back in Pandora-days, there were motivated developers who had fun working on such devices. These days, it's very, VERY hard to find them. Even if you pay them.

 

[Letalis Sonus]

That's actualy....weird...

It might be weird, but not a very uncommon thing. Embedded components usually have a very high availability (>10 years in the automotive industry), because e.g. car manufacturers and their suppliers are not willing to invest into migrating existing ECUs to new hardware just because they are running low on replacement parts for an older model. The chip manufacturers don't just stop selling chips that are getting near their EOL, they just discourage from using them for new projects - and therefore may stop providing support for the chips they're still selling to you, the support is rarely needed if the product's development is already finished. I can tell you from experience that there are even some automotive suppliers that still want to start new projects with PowerPC BookE chips that are already over 10 years old, even though the whole architecture has already been pining for the fjords for years because everyone is going ARM these days (and because they're an organically grown mess with serious hardware bugs...).

If the OMAP5 actually made it into a single product that hit the market, TI is required to keep them in stock until the promised availability expires, even if they already discontinued it.

 

[levi]

At least we've got a couple of people getting experience of the PVR stack on the N900 device, as was announced on the mailing list a couple of days ago. It doesn't integrate Linux's direct rendering manager, and presumably doesn't do tiler rotation, but more engineers being more familiar with the baseline technologies enables efficient discussion to work out issues at the very least.

 

[crazyhorse]

Could you send out some units to the preorderers who may be able to help with the low level stuff before an “official release.”If any preorderers indicate they may be able to help and will not release any photos or details to anybody( as its still beta)

 

[fusion_power]

So, throw away around 300k EUR development costs to start from scratch?
The PCB would need a complete redesign, the system would need active cooling (which means a complete case redesign, etc.)
When we started, no Intel CPU was useful. No other CPU was useful.
If we'd start now, we'd probably use the i.MX8, as it has bigger support.
But that one wasn't available back then.

No, not for the Pyra. I thought about future projects or other small indie companies, IF you would start such an project TODAY. What would have changed, what could go different and so on. Sorry, no intention to "throw away" the long Pyra development. I'm not a cruel person.

No. Usually, you only get support from the manufacturer is if you buy at least 100k of their chips.

Even today with so much stuff going on in the hardware market? Where do small "low quantity" indie companies get their stuff from? or is the Pyra the only one in the world?

I already said multiple times: What we're doing here is something COMPLETELY different to most of the handhelds out there: We're doing TONS of custom stuff, not just using reference designs and putting them into a shell.

"Overengineered", yeah that's a typical german thing I guess. Nobody here knows the "KISS" principle (keep it simple, stupid).

The OMAP5 is VERY well documented. Better than most SoCs out there.
But that's over 5000 pages documentation. Someone needs to implement all the timings, hardware registers, etc. into the driver modules so that everything works fine.

Sounds like really low level work. No wonder all these chiense companies use common stuff for their products. I guess they never have to dig that deep into an SoC to make it run right?

TI never finished the graphics system properly. That's why rotation with TILER was terribly slow, until zmatt made a quick hack to show it can be done in fullspeed.
But TI didn't have a huge customer who was in need of that - so they never took care about it. And why should they? Android uses OpenGL for the rotation, and that was probably the main use case for the chip.

They really released that unfinished products? And they are still not bancrupt? Sometimes I wonder how companies come through with that kind of half-ass business. I remember that you lost over an year because of that rotation-chip desaster. Sounds like it could have beeen avoided if TI would gave you the right infos about TILER. ^^"

Times have changed. Back in Pandora-days, there were motivated developers who had fun working on such devices. These days, it's very, VERY hard to find them. Even if you pay them.

What happend? We only have the "Fachkräftemangel" in germany because almost everyone goes IT and "something with computers" and not into craftmanship or service jobs. The world should be full of computer specialists actualy, everyone want to go there (or become Youtuber ). So, where are all the talents?

It might be weird, but not a very uncommon thing.

Still not a good thing if you want to call yourself a professional company. Support is everything, entire industires rely on propper (software) support to even be able to exist. Long time service contracts are a thing for sure. Imagine Intel or AMD would act like that. Their drivers support a wide range of older hardware as well as the newer one. Not to infinite but long enough to not piss of the customers completely. ^^

 

[Letalis Sonus]

Imagine Intel or AMD would act like that.

...you know about the AMD Geode series? The 14 years old Geode LX is still in production, its EOL has been pushed back several times despite lacking support for any recent Windows version.

 

[fusion_power]

...you know about the AMD Geode series?

Actualy, no. 14 years and still in production? Must be a hell of a chip.

 

[EvilDragon]

Pandoras OMAP3 is also still available

 

[rSl]

Times have changed. Back in Pandora-days, there were motivated developers who had fun working on such devices. These days, it's very, VERY hard to find them. Even if you pay them.

i'm verry motivated and have fun tinkering when things are so cool like the pyra!
but i'm no hardcore kernel developer. back in the days (tm), when redhat/fedora linux was a thing (and wasn't owned by big blue...),
i hacked a lot away on little bash-scripts and better desktop integration.
these days using gnu/linux most of the time "just works" for me. maybe it's because i have learned what *not* to touch, to avoid breaking things.

i for one will spend a lot of time trying to break things while doing "the normal" stuff and trying to fix that.
when more of us with mid-level skills are doing this, we will get the gnu/linux pyraOS polished quite nicely, i'm sure.

for the core kernel and ti flavoured issues we really need some devs of near notaz qualification.

it's the beginning of the new, fun packed, pyraOS-journey, and we are starting *right now*.
the pyra *will* be alive soon! so, woohoo welcome!!!