Contributing to PyraOS


awesome, thanks!
'es geht voran' (means: things are moving ahead)! :cool:
 
Sounds great, this "SGX Driver" was for the 3D Chip ??
"Mach den SGX Treiber großartig wieder" (MSGXGA) ^^

Yes it's the driver for the 3D graphics. It's not really a separate chip, but the PowerVR SGX544mp2 graphics core built into the OMAP5 SoC (System on Chip).
 
So... where we are...
*ED has prototype parts on-desk...
*hns has the OS working a touch better...

[This is the something(s) that has/have to be done to get from current state to next state.]

*...Load/install a working OS onto the eMMC for the prototypes.

What things still need to be sorted out that belong between the brackets [] above?

It feels like things are getting very very close on both the hardware and software front for building out the prototype-pre-pre-orders?.
 
The next state, if not preceded by hns managing to get more working/posted upstream is ED getting results from the plastic firm which as of last report fall into the categories of aesthetic things and vents.
 
The next state, if not preceded by hns managing to get more working/posted upstream is ED getting results from the plastic firm which as of last report fall into the categories of aesthetic things and vents.

Mostly trying to fill in the known gaps between where we are now and the next highly visible step of shipping prototypes. I'm not trying to nail down dates, more curious what tasks are still in between.

Plastics...
I thought the plan for the prototypes was to use the 20 granite grey cases that he brought back from Greece? I understand these to be mechanically sound. Though he also mentioned that he might still be doing colors of choice for the prototype orders.

Hardware...
I'm not sure how many completely populated & working sets of latest generation boards exist. ED's comments seemed like he had all of this.

OS...
hns and others in this thread are making advancements on the OS using prototype hardware. I'm not sure what the 'next steps' are in getting Debian to see and like all of the hardware - or at least enough of it - or what 'enough of it' might entail.

I'm sure there are many 'milestones' in getting the OS sorted out.
-booting Debian/Letux to a command line (check?)
-booting to a 2D GUI (which one?)
-booting from the eMMC to a GUI
-'seeing' all of the storage targets (eMMC, microSDXC, left SDXC, right SDXC, USB mass storage devices on all ports)
-3D & Tiler married
-Sound power limiter so we don't blow out the speakers

Those are off the top of my head - and many of them might even be checked off now. Why do I bring it up and try to list out bits and pieces? So we can maybe know which bits need work still so that maybe people with knowledge of those types of things might be able to help - or at least advise?
 
OS...
hns and others in this thread are making advancements on the OS using prototype hardware. I'm not sure what the 'next steps' are in getting Debian to see and like all of the hardware - or at least enough of it - or what 'enough of it' might entail.

I'm sure there are many 'milestones' in getting the OS sorted out.
-booting Debian/Letux to a command line (check?)
-booting to a 2D GUI (which one?)
I think aTcs unit is currently running Mate. I'm not sure though, I'm not an absolute expert on identifying plain windowing desktop environments.
-booting from the eMMC to a GUI
May already be working. I don't know if people are booting from eMMC or an SD card though.
-'seeing' all of the storage targets (eMMC, microSDXC, left SDXC, right SDXC, USB mass storage devices on all ports)
-3D & Tiler married
-Sound power limiter so we don't blow out the speakers
I've not seen any of these demonstrated yet, so these are all valid next steps from my current understanding. 3D and tiler now kind of work together, but 3D seems to crash out after a number of tries, and not all tests run yet as far as I know.
 
Yep Mate is currently working without 3D.

Here is a list of the outstanding issues I'm working on:
* The battery monitor doesn't know the size of our battery yet (it uses some default values which are wrong).
* The charger chip doesn't have a proper driver yet, so we are having some quirks like not being able to run only off AC only (without battery) because it limits the USB input to 500mA and stuff like that.
* Rebooting the unit hangs the omap as some omap-register is not properly reset. Nikolaus found that out by disabling some things, so we have a clue where to look for, but no one has followed that lead yet and fixed that. (Shutting off and rebooting does work).
* A mini-kernel would be great which would be loaded before the REAL kernel loads. That would enable things like showing the battery charging status on screen or showing a boot menu (as the bootloader can't enable the screen yet).
* The bootloader should do some default setup for the charger (like disabling the 500mA limit) and other configs, as the system forgets these once the power has been cut for a few minutes.
* There is no simple way as of yet to flash to eMMC and boot from it

My progress on these issues (if anyone else is working on these, I'm unaware):
- I am currently working on battery monitor/charger issues. I've made some progress, but it is slow until I get some hardware.
- eMMC boot I don't think is currently working. This is pretty straightforward. I can get this rolling pretty quick once I get some hardware, but its not worth it to start working on it until I can test since its pretty low level.
- I've started to look at the issues with the sound chip as well, but recently hit a wall. ED just provided me what I needed to get past this wall, but I haven't had a chance to move forward on this yet as I've been out of town.


Most of my efforts recently have been directed towards creating a build environment for building U-Boot, the kernel, the rootfs, and packaging them into an image. In the future, I'd like for this to also support easy creation of DBP packages and debian packages targeted for the pyra package repo. For now, keep an eye on the original post for updates on this progress. It may be interesting to also keep an eye on the imagebuild repositories as well (main one is pyra-docker) as this is where the build system progress is happening. As of right now it is capable of building the bootloader, kernel, rootfs, and building a .img which can be flashed onto an SD card and booted from. The last feature is new and untested at the moment, however :)
 
Last edited:
What things still need to be sorted out that belong between the brackets [] above?

It feels like things are getting very very close on both the hardware and software front for building out the prototype-pre-pre-orders?.

We
ll take Pyra Parts with us to the Gamescom and build some prototypes there.
These are planned to be sent to more Developers and if I remember correctly to some Prototype preorderers.

* The charger chip doesn't have a proper driver yet, so we are having some quirks like not being able to run only off AC only (without battery) because it limits the USB input to 500mA and stuff like that.

So does that mean we'll get some sort of quick charge and can use the full 2.4 or 3 Ampare chargers provide?
 
- eMMC boot I don't think is currently working. This is pretty straightforward. I can get this rolling pretty quick once I get some hardware, but its not worth it to start working on it until I can test since its pretty low level.

eMMC booting works fine.

The only slight issue is that there's a switch between the microsd card slot and the emmc, and the hardware can only see one at a time. The kernel defaults to microsd mode currently so once it's running it can't see the eMMC. The current fix is a small script in the initramfs that checks if there's a microsd card inserted, and switches to emmc if there isn't. (Since uboot can see the eMMC , and load the kernel+initramfs from it).
The plan was to eventually make the kernel switch automatically based on which device is accessed.
 
As UI something like Hildon Desktop (or XFCE with a config like Hildon) would be nice (because of the size of the screen) IMHO :)

With full keyboard available, I will actually prefer keyboard focused desktop that can be customized and is very light weight. Something like i3 or openbox shall work very nice with Pyra.
 
So does that mean we'll get some sort of quick charge and can use the full 2.4 or 3 Ampare chargers provide?

The charge circuit should support up to 2A. Right now it looks like the configuration is a little funky. The battery does not appear to charge fully and I haven’t been able to make measurements and fully characterize this yet. More to come once I’m able to do this.

eMMC booting works fine.

The only slight issue is that there's a switch between the microsd card slot and the emmc, and the hardware can only see one at a time. The kernel defaults to microsd mode currently so once it's running it can't see the eMMC. The current fix is a small script in the initramfs that checks if there's a microsd card inserted, and switches to emmc if there isn't. (Since uboot can see the eMMC , and load the kernel+initramfs from it).
The plan was to eventually make the kernel switch automatically based on which device is accessed.

Ok that sounds good. I see in the TRM that there is an option to boot from SD and fall back to eMMC, then to USB if no bootloader is found. This may be a good way to configure the boot pins if it’s not already configured this way. This way it will fall back to eMMC unless there’s a bootable SD loaded.

Is there currently a method in place for flashing the eMMC? I remember ED saying this was not yet implemented yet but I could be mistaken. If not, a flashing SD image may be a simple solution. Basic bootloader and kernel that automatically starts up, partitions eMMC, and flashes when booted with this SD card in.

Flashing via a USB/serial boot option would probably be best, but I haven’t found any good information about the OMAP5s serial boot process. If you have any documents describing this that would be awesome :)
 
Is there currently a method in place for flashing the eMMC? I remember ED saying this was not yet implemented yet but I could be mistaken.

There is, it's the same installer used to make bootable sd cards, ran from the init-hwtest script :
https://dev.pyra-handheld.com/atc/pyra-install
https://dev.pyra-handheld.com/packages/pyra-scripts/blob/master/scripts/init-hwtest.sh#L268

It's not very well tested.
ED seems to have an issue where it takes 45 minutes to install, while on my pyra it does it in 3 minutes.
(Haven't looked into it, but i think it's to do with the date on the pyra not being set properly, and it giving a warning for the date being in the future for each file extracted.)
I did try having it just dd the image directly to emmc, but that was actually slower than extracting the .tgz to it :)

the init-hwtest script is supposed to run after assembly, to test the hardware and flash the os to emmc at the end.

And the current DE is MATE, because it looks slightly more modern than xfce, but still runs fine without 3d/2d acceleration.
 
Great, thanks aTc! I’ll take a look at these scripts and see what needs to be done to properly integrate them into the build system.
 
Can I respectfully request that you don't turn this into a DE choice, keyboard layout or case colour thread please. Unless you've got insight into the OS, you'll probably want to find another thread to post in

Thanks for showing so much respect. Btw., did I wrote anything about keyboard layout or case colour there ?
Can I respectfully reply that as far as my insight into the OS goes, desktop is part of OS.
 
Thanks for showing so much respect. Btw., did I wrote anything about keyboard layout or case colour there ?
Can I respectfully reply that as far as my insight into the OS goes, desktop is part of OS.

PyraOS is Debian based and has the Debian repository keyrings. Anything on there can be installed via apt. Anything that isn’t a Debian package can usually be built from source.

It seems Mate has been chosen as the default DE for PyraOS, but anything can be installed by the user.
 
Back
Top