Bugs and Calculations


https://www.dragonbox.de/en/354-pyra-preorder-without-4g-lte-pyra.html


(strike-through by me, assuming that's a leftover from last year :^) )

I'd assume that would be sufficient for you.

This is helpful. When I looked in the Pyra section the other day, I wasn't able to find anything other than shirts and mugs. I'd still prefer to receive an email before pre-orders start, rather than once people are already hammering the servers, however this at least puts my thoughts at ease.

-God Ginrai
 
It should be just like on a regular PC and bring up the dialog window to ask if you really want to shutdown.
 
but if you hold it down it should do a hardware shutdown, right? (force poweroff?)

not that that will hopefully happen too often...
 
To power on the Pyra? it's a button just above the Start button.
No, just for software use. On the N900, for example, it locks/unlocks the screen.
On the Pyra, I would see a switch being useful to lock/unlock the externally accessible controls.
 
No, just for software use. On the N900, for example, it locks/unlocks the screen.
On the Pyra, I would see a switch being useful to lock/unlock the externally accessible controls.
Well what I seen there is no keyboard lock/hold switch like that.
 
Is "only for Pyra!" an official slogan now? :p (from the eSATA adapters, in case anyone missed it)

Regarding the keyboard locking stuff, why not just have it detect that the lid is closed and do whatever you need it to do to the shoulder buttons? Am I misunderstanding what you guys are talking about? This option would allow you to disable the shoulder buttons completely, or switch them to media controls, or maybe even enable/disable 3G/4G. Maybe that should be easily user configurable (GUI tool).
 
Plume said:
Shouldn't handling missing controllers gracefully be the base case ?

In theory yes, but in practice it's not something you can expect always to work.
I'd say that with modern (4.x) Linux kernels you can expect in practice that it almost always works :)

There are rare exceptions but I haven't seen a significant one in the Pyra so far. The only undetectable things are changes of GPIO assignment but this does not happen if components are optionally installed.
Most components are connected through I2C (and 3G/4G through USB) and if they are not installed on a PCB, the driver is simply not loaded and does not present some /dev or /sys files.
User space software can detect the presence and e.g. adjust GUI or show an alert.

So there is a single kernel for all variations of installed components ED is thinking of.
 
Most components are connected through I2C (and 3G/4G through USB) and if they are not installed on a PCB, the driver is simply not loaded
Only if you use the right DTB...

So there is a single kernel for all variations of installed components ED is thinking of.
But still many DTBs and all the trouble to load the right one.
 
I'd be perfectly happy if all the official support for Pyra was small RAM/eMMC and I had to jump through hoops to enable the bigger sizes... just saying.
 
I'd be perfectly happy if all the official support for Pyra was small RAM/eMMC and I had to jump through hoops to enable the bigger sizes... just saying.
That's be a support nightmare for novice users who buy one and don't know how to do stuff like that.
 
Only if you use the right DTB...
But still many DTBs and all the trouble to load the right one.
There is a single DTB that defines the union of all components and drivers that can maximally be available. I.e. the completely populated Pyra boards. If a component described there is not available, it will try to load the driver, and run the probe() function. Probe will not find the chip and further on, the extra information in the DTB is ignored.
A different DTB is only needed if there are PCB layout changes (e.g. a chip is moved from I2C2 to I2C3 or gpios are swapped/inverted or used differently). This are major device variants. Therefore we have a different one for the first prototypes (because of such wiring differences) and a third one for the OMAP5432EVM.
So there is no need to have different DTB files for each subvariant created by leaving out components of an otherwise identical design. It is like removing a light bulb from the socket which does not need to redraw the house plan of the light switches :)
Different eMMC sizes are automatically detected (like different MMC card sizes). Only different RAM sizes are tricky, but more a problem for different U-Boot/MLO variants.
 
Back
Top