Legodude522
Very Active Member
At least the OMAP processor will give us an option to use SATA.
It reminds me of the Pandora!
- Thread starter EvilDragon
- Start date
levi
Still fresh, damnit!
'By accident' might be overstating it. A lot of testing and trying is going on behind the scenes at present I think, and they all have a value.
fusion_power
Advanced Member
Sometimes I want to travel back in time so ~30 years and show the Computer fans back then what we have today.
Just look at this little Pi400, you have an "Keyboard AIO Computer" for under $100 with that power, compared to old clasics like the Atari, Amiga, C64 and so on. No, I would not shock the past people with modern Smart Phones or big gaming PC's, just stuff they can compute (hehe). ^^
oskda
Very Active Member
- Joined
- Mar 29, 2015
- Messages
- 375
Why? Because there is no other pocket computer like Pyra even after 5 years of development, so even with OMA5 idle bug is so unique and valuable.
And look at GPD Win 3: they get away from pocket computer design. There is no real keyboard but an horrible touch surface acting like a keyboard under display. Even old GPD Win 1/2 were too much big to be "real pocket" computer, and their keyboards were bad (Win 3 has no real keyboard) and without backlight: you can't use that keyboard in a lot of places. Backlight is a must on a mobile device.
And the best part is that you will can upgrade to new CPU board when it be ready.
You can wait, but you will have to wait more than a year, even 2 years.
And no, i.MX 8 is not an option: it doesn't fit (you can read on The Future of Pyra's CPU [following page 5]). Actual i.MX fitting on Pyra CPU board will have 4 Cortex-A53 cores, so in mono-core they will have less performance than Cortex-A15, although they will be more energy efficient.
At present moment we don't know what CPU will use next Pyra CPU board, and I suppose we would not until launch be near (in 1 or 2 years in best case?) because ED also knows about Osborne Effect.
Of course you can decide if you want to but actual Pyra, enjoy it, and upgrade it when new CPU board be ready, or if you prefer to wait a few years more to get your Pyra with next CPU inside.
The worst part is that if you are didn't ordered time ago, you have no option: you have to wait until all previous orders be sent.
oskda
Very Active Member
- Joined
- Mar 29, 2015
- Messages
- 375
And Raspberry Pi doesn't have to pay for Broadcomm IP.
The worst part of Raspberry is not only uese a lot o blobs, even a blob to boot, even worst is that closed OS for GPU is always on, it has real control (and its backdoors plus bugs) and highest priority, and the user OS you load after it is on lower priority. So you have a OS controlling your machine and you don't control that OS, even you know nothing about it (this also occurs on modern PC x86 CPUs).
oskda
Very Active Member
- Joined
- Mar 29, 2015
- Messages
- 375
I know RPi 400 will have great sales because surprising some people see a computer only if they see a keyboard :O
If they see a normal RPi, they think it isn't a computer but other thing
It is the same that expensive Spectrum Next: it is simply a FPGA, and there were better (for example MiSTER) or cheaper FPGA before (for example ZX-UNO). But if people doesn't see a keyboard (and better one looking something like old Sinclair keyboard), they don't see a ZX Spectrum, when all them are simply FPGA, and you can use a better keyboard on others FPGA without integrated keyboard.
What is the point of having integrated and surely bad keyboard instead of having computer and keyboard separated (joined by a cable or wireless) and where you can choose the keyboard you want?
Having separate keyboard from CPU case was always a plus. I remember for example having 8 bit machines with keyboard son same CPU and you can't move keyboard as you can do with a separate keyboard, because case with integrated keyboard has a lot of cables connected: power, monitor/TV, dattasete, disk_drive, joystick, cartridge... And usually that box was bigger than a stand alone keyboard.
Post automatically merged:
Modern cars have a lot of CPUs inside. And power is on all time when car is started-on. Remember a normal car has a thermal power plant inside
An OMAP5 on a normal car is handling things like displays and multimedia, and that is on all time when car is on. There is no need for idle mode in a car for that OMAP: it is off when car is off and it is on all time car is on.
PD: Electric cars have even more electronics and more CPUs.
Last edited:
It's almost the same. When a SOC needs a blob to boot, the code in that blob is in a position to stay resident, keep control on the system, and in some way set up a virtual machine for the rest of the system to work in.
I don't mean that they always do, just that they always could.
The details vary depending on the architecture and for simple microcontrollers what I'm saying could be false, but as a general rule whoever boots first can keep the control, and can decide what payload is allowed to boot next.
Then the SOC may have more or less infrastructure to keep a "secure world" separate and invisible from the OS and applications, or have it rougher and simply brick the device if it doesn't like what you installed,
but at the very least it has always the decision on what can boot next.
If that boot code is in a ROM it can still be bad, but at least it cannot be changed to worse once you have the system installed. If it is loaded from storage then you have to keep trusting the provider than any update really fixes a
vulnerability instead of introducing one or adding antifeatures. And trust than the blob won't update itself.
The boot chain is a control chain, which can be used (plus memory protection) to set up a trust chain. Whoever comes first rules over the next code.
I don't need to know that the OS in the GPU is controlling the system. The simple fact that I can't understand or change what it does when it boots is enough to worry that it could be so.
Now in the case of the Raspberry, I'm not sure whether the code for the GPU that boots first could be changed and the problem is "only" lack of manpower and documentation, or it is signed and the GPU won't boot anything you would give it if you could write it.
The later is worse, but both are bad enough.
dracmas
Member
- Joined
- Aug 30, 2017
- Messages
- 65
- Age
- 41
Still haven’t found anything that I’d replace the pyra with. Gpd doesn’t have the extra storage options the pyra does. No lte option. Nothing much pocket friendly. GPD 3 already going away from clamshell design. With removable battery I don’t have to worry about not being able to find a replacement if it goes bad. Even the keyboard was worked on forever for the pyra so it is in the best form factor for its size. Should also be less worrisome if you accidentally drop it when closed because of the case that was developed. Still a bit curious how good the stylus is.
Raspbery pi does have some diy handheld computer builds but doesn’t come close to the quality of pyra’s build. Don’t think the ones I saw had the lte chip added on so even those build would need to be modified for that. The keyboard used didn’t look nearly as good.
also joystick to move the mouse just seems better overall than the implementations used on other devices.
Raspbery pi does have some diy handheld computer builds but doesn’t come close to the quality of pyra’s build. Don’t think the ones I saw had the lte chip added on so even those build would need to be modified for that. The keyboard used didn’t look nearly as good.
also joystick to move the mouse just seems better overall than the implementations used on other devices.
Regarding the perfect keyboard (and to continue the tradition to derail every news-thread whenever possible and as much as possible): I was crazy enough to buy a HHKB Professional Hybrid and I did not regret it.
I think the differences are subtle at first, but if you do a lot of coding and/or work on the terminal a lot it really makes a difference at the end of the day. Specially when using vim or vi-mode alot.
I think the differences are subtle at first, but if you do a lot of coding and/or work on the terminal a lot it really makes a difference at the end of the day. Specially when using vim or vi-mode alot.
zdwg
Member
- Joined
- Jan 15, 2011
- Messages
- 46
Yeah things are probably tight for development now, but it is great to see this project still going strong. I might hop onto the preorder bandwagon at the end of the year or beginning of the new year.
I'm still more excited for this thing than I am for new consoles or computer parts. I wonder what a small rPi cluster would do for it.
I'm still more excited for this thing than I am for new consoles or computer parts. I wonder what a small rPi cluster would do for it.
theredbaron
Very Active Member
sed 's/preorder/order/g'
At least, hopefully by the end of tgis year
.Sent from my H3123 using Tapatalk
I wonder what happens to the Pyra,
On Twitter whe saw these cool Magnet Boxes arrive, and ED was waiting for the special Booklets, and he said that when everything arrive, he will send the final order Emails and everything..
But there isnt even a status Update..
My vacations are now as good as over and they were ideal to make the final order, but unfortunally, my next vacations are end of this yeahr
On Twitter whe saw these cool Magnet Boxes arrive, and ED was waiting for the special Booklets, and he said that when everything arrive, he will send the final order Emails and everything..
But there isnt even a status Update..
My vacations are now as good as over and they were ideal to make the final order, but unfortunally, my next vacations are end of this yeahr
ClockworkCoder
Chaotic Neutral
I'm curious too, although it seems that ED is too busy to post any update, so I'm not really expecting anything until it appears right now.
Phlyra
FLOSSing
- Joined
- Jul 25, 2019
- Messages
- 1,517
I thought the reply came back that changing resistors wasn’t necessary because it could be implemented in s/w?
ClockworkCoder
Chaotic Neutral
I think that was for the keyboard's brightness...
Mmm... Maybe I should correct myself. I still don't know, but I read an update at pine64.org that seems to indicate the PinePhone suspends when unused and will resume when a call comes in time to pick it up. So maybe idling is not necessary for telephony with a Pyra???
From Lukasz Erecinski (or maybe Gamiee, JF, PizzaLovingNerd, or Clover, all credited as helping in writing /reviewing the update):
(boldtype mine)
So if "resumes from suspend" means literally that, and not something like "transitions from idle to more performant states", could mean idle won't be needed once we manage to nail suspend/hibernate (possibly by kernel improvements, which doesn't sound simple, but we can't consider impossible yet).
As per my understanding in suspend mode running state of system is saved in RAM, and power supply to all other parts excluding RAM is cut off. So how did pinephone is able to detect incoming call in suspend mode, and what triggers it to come out of suspend mode ?
ClockworkCoder
Chaotic Neutral
Not sure it does? Just tested mine, and it doesn't wake up for a call.
