It reminds me of the Pandora!


This looks like fun:
Sometimes I want to travel back in time so ~30 years and show the Computer fans back then what we have today. :D 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). ^^
 
Why should i buy a pyra with OMAP5 with hardware bugs?

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.

I wait a few more month to get thy pyra with the i.MX 8. Performance and battery life will be increased.

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.
 
The rapsberry is build in hundreds of thousands or millions. That is what lowers the price.
Whoever wants a rapsberry can buy it easily. We don't need Evil Dragon for that. But I'm not interested anyway in a SOC that needs blobs to boot.

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).
 
This looks like fun:
Post automatically merged:

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 :D

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:

This surprises me a bit, since in automotive there are very strict requirements on power consumption and so on. I would have expected that an idle mode is a must.

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:
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).

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.
 
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.
 
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.
 
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.
 
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.
sed 's/preorder/order/g'

At least, hopefully by the end of tgis year :).

Sent from my H3123 using Tapatalk
 
  • Like
Reactions: rSl
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
 
Mailing list seems that he maybe need to replace a resistor for the propper charging temperature.

But mails still flying around
I thought the reply came back that changing resistors wasn’t necessary because it could be implemented in s/w?
 
Or does suspend and hibernate not work on the Pyra ? And then it is just work on software to make it work, or there's some reason it can't ever work ?
Ah, I see it. You want the modem on, tracked by telephony towers and wake up the whole system when a call comes, is that the problem ? Then you would need some small cpu somewhere to wake the system up, but could miss the handshake with the phone network, the call or whatever, if awakening is too slow.

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):
Lastly, I also found that the PinePhone now resumes faster from suspend on incoming calls, and that the Bluetooth adapter functions reliably. Both of these features, while relatively minor when compared to the major strides made in the past month, are actually very significant in terms of making the PinePhone viable as a daily driver. This, combined with the much improved voice call audio quality in the newest kernel, means that my SIM card now resides exclusively in the PinePhone, while I keep my Android phone for auxiliary tasks. We’ve come a long way since January 2020 and at this pace I feel the PinePhone may become a viable daily driver for many users early next year – I truly believe this.
(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 ?
 
Back
Top