Contributing to PyraOS


aTc said:
I just tried it with a fresh 4.19.63, straight from the letux git, using letux_lpae_defconfig with CONFIG_DRM_LEGACY enabled manually, and that also works fine.
(meaning it runs gles1test1)
Click to expand...
Ah, that is good.
It allows us to make a quick test if you can provide me this uImage and the kernel modules (incl. the pvrsrvkm) through some download.
Then we can decide once for ever if is kernel or kernel build related or some user-space issue on my side.
 
  • Like
Reactions: rSl
@hns is the github for the Letux kernel (and U-Boot) active? It appears to track commits present on the official Letux kernel site, but it’s unclear if they are the same repository.

If this github remote is active, can contributors such as myself push patches or WIP fix/feature branches in the form of merge requests here? It would be very nice to have an open method of tracking progress and modifications that we can all see.

https://github.com/goldelico/letux-kernel
 
ToastBucket said:
@hns is the github for the Letux kernel (and U-Boot) active? It appears to track commits present on the official Letux kernel site, but it’s unclear if they are the same repository.

If this github remote is active, can contributors such as myself push patches or WIP fix/feature branches in the form of merge requests here? It would be very nice to have an open method of tracking progress and modifications that we can all see.

https://github.com/goldelico/letux-kernel
Click to expand...
It is a mirror (done once per hour), mainly intended as an alternate archive and git clone location (to protect against server or network failures). Not as a place to push patches to. Reason is that I do not know how to handle such github patches locally and how to configure access permissions. And, I find the github user interface more confusing than GitWeb :)
[doublepost=1564999336,1564998044][/doublepost]
aTc said:
that it can run eglinfo
Click to expand...
I have now done an strace eglinfo on my setup. But there are only two system calls which return an error (access for non-existing files /etc/ld.so.nohwcap and /etc/ld.so.preload).
There is no syscall related to sgx or x11 or anything. eglinfo almost immediately fails after loading the shared libs.
Please can you run "strace eglinfo" on your working setup and provide me the result?

Edit: I have now booted a hybrid between LetuxOS kernels and https://packages.pyra-handheld.com/rootfs/stretch/pyra-debian-stretch-mate-rootfs.tgz
Here, eglinfo seems to work (haven't started SGX yet because I have lost the pvrsrvkm on this SD card). strace is indeed different. Mainly, it does not even look for libX11-xcb at all. But it loads some other libs and finally scans /dev/dri. This just means that some package in the LetuxOS is not compatible with eglinfo.

Edit2: :):):):):):):) - it works with this setup.

Here is a short video:


I can run it at least 3-4 times before some buffer problem:
Code: 
root@localhost:~# gles1test1 100
[ 1926.586551] omapdrm omapdrm.0: could not remap: -12 (3)
[ 1926.592204] PVR_K:(Error): DmaBufImportAndAcquirePhysAddr: dma_buf_map_attachment failed: -383932736
[ 1926.602778] PVR_K:(Error): PVRSRVMapDmaBufKM: Failed to get dma-buf phys addr
[ 1926.610541] PVR_K:(Error): PVRSRVMapDmaBufBW: Failed to map dma-buf handle
PVR:(Error): CreateBuffer: Couldn't map buffer: PVRSRV_ERROR_BAD_MAPPING [0, ]
'eglCreateWindowSurface' returned egl error 'EGL_BAD_ALLOC' (0x3003)
[ 1926.641155] omap_hwmod: gpu: _wait_target_disable failed
[ 1926.668215] omap_hwmod: gpu: _wait_target_disable failed
[ 1926.699621] omap_hwmod: gpu: _wait_target_disable failed
root@localhost:~#

So this is a big breakthrough since I can now start to compare and fix things of the in-kernel driver tree (drivers/staging/pvr) until we get repeatable results. And most likely the problem with LetuxOS is that libX11-xcb makes unexpected interferences.
 
Last edited:
hns said:
It is a mirror (done once per hour), mainly intended as an alternate archive and git clone location (to protect against server or network failures). Not as a place to push patches to. Reason is that I do not know how to handle such github patches locally and how to configure access permissions. And, I find the github user interface more confusing than GitWeb :)
Click to expand...

Can the GitWeb interface handle merge requests? If so, can you turn this feature on? This is a much more public and interactive method for contributing than simply emailing patches to the mailing list.
 
ToastBucket said:
Can the GitWeb interface handle merge requests? If so, can you turn this feature on? This is a much more public and interactive method for contributing than simply emailing patches to the mailing list.
Click to expand...
No GitWeb can't. Indefero (https://projects.goldelico.com) had tried to provide a similar method, but Indefero is too slow for a really big git repository like the Linux kernel.
Well, we closely follow the development process kernel.org is doing and they also do not use GitHub and merge requests, just GitWeb and patches/pull requests by e-mail. This is sometimes a little old-fashioned (and AFAIR they have started to think about better ways), but running a different method in the back-end than in the front-end needs a good reason.
On the other hand here is no problem of giving you write access to https://github.com/goldelico/letux-kernel so that you can run a feature branch there. You just need to register with https://projects.goldelico.com, provide your SHA key and let me know the user name. This would allow you to push new material directly to branches, like all other members of the Letux kernel Development Team (see left column of https://projects.goldelico.com/p/gta04-kernel/) .
Or as you already have proposed, I have added https://dev.pyra-handheld.com/kernel to my local remotes. So just mailing me a commit hash is enough to let me know what to pull in. Or you can place a branch for-letux-4.19-next or pyra-defconfig or similar there, give me a notice if there is something new and I can merge it every now and then.
From a quality gate perspective the second method seems to be better and fits better in the well established workflow.
Finally I am not sure that merge requests are more interactive than mailing patches. In both methods the patches need review and comments. On a public mailing list they are run like multi-party discussions where everyone can jump in. On GitHub I admit that I don't know how this works. Most likely it is just a front-end sending out an e-mail notification to the repo owner that there is a new merge request to be taken care of, but I am open to learn about how it works.
 
Last edited:
  • Like
Reactions: rSl
Ok sounds good. I will work on setting up the Pyra remote in that fashion, since it sounds like you prefer that.

For a decent example of merge requests, you can check out the merge request aTc and I used to get the base Pyra support patched in on the Pyra remote. You can easily view the diff, make comments (even on specific lines) and view the commit-by-commit progress as the issues are resolved. This is nice because a contributor can create a merge request, and maintainers/developers can open discussions on specific portions of the code (ie “This logic should be simplified”, “Use snake case instead of camel case here”, “Is this the correct default, datasheet doesn’t agree” etc). Then the contributor can repair the commit and push again until all discussions are resolved. Then the maintainer merges when they are happy with it. Testing can be done by simply pulling the feature branch rather than applying patches on top of a branch.

Functionally, it serves the same purpose as mailing patches, but is more accessible and verbose than a mailing list in my opinion, as well as maintaining a nice history of the feature development right within the remote’s interface. This could just be that I’m used to this workflow, however.

https://dev.pyra-handheld.com/kernel/pyra-kernel/merge_requests/1
 
Last edited:
  • Like
Reactions: rSl
I have no foundational knowledge to be able to assist in what you are all working on.

But - I thought I'd comment on one bit... It is great to see pictures and videos of prototype Pyras doing something - even if it is a video test pattern and blinkenlights.

https://en.wikipedia.org/wiki/Blinkenlights

Thank you all for what you're getting advanced or done on the Pyra Prototypes!
 
Question:
Would be this "Omap Tiler" Function a big Problem to port other OS in the Future for the Pyra?

I see even Devs fight with it and i have the Fear that Tiler will make porting other Linux OS or Android very difficult.

Or will be a simple Kernel Patch released with it then?

Sorry..i do not know much about that Stuff :)
 
ingoreis said:
Question:
Would be this "Omap Tiler" Function a big Problem to port other OS in the Future for the Pyra?

I see even Devs fight with it and i have the Fear that Tiler will make porting other Linux OS or Android very difficult.

Or will be a simple Kernel Patch released with it then?

Sorry..i do not know much about that Stuff :)
Click to expand...
TILER is a hardware subsystem inside the OMAP5 chip, specialized on rotating framebuffer content. Think of it as a very specialized graphics accelerator. Its purpose is to rotate the screen contents so that applications think the panel is a landscape panel, although the scanning direction is a portrait panel.
Everything can work without. It is just better to have a special kernel driver which makes use of the TILER.
Android or other Linux OS (non-Debian) can directly use it since it is a kernel function and they also use the Linux kernels.
Only other OS kernels (e.g. Risc OS) will have to take care of screen rotation themselves. Either by having their own TILER driver or something else.
The status is that it works with the v4.19 kernels. It is just broken with the v5.3 release candidates and we are working to fix it until v5.3 is officially released.
And it is not yet in the kernel.org repository, so that kernel developers outside of our community are not aware that their changes may break our tiler code.
So in fact nothing you will have big trouble with as a user.
 
hns said:
Only other OS kernels (e.g. Risc OS) will have to take care of screen rotation themselves. Either by having their own TILER driver or something else.
Click to expand...
For RISC OS you maybe just need to redefine how OS_Plot and OS_ReadPoint calculate the addresses used to set or to read graphics points. With a bit of luck, everything else will shake out in the wash, although it may make sense to generalise this and add a flag to OS_ReadModeVariable and allow the code to go back upstream and be reused by anyone with a wonky screen or just to rotate their monitor if they have a fancy rotating stand for it. You probably need to speak to Jeffrey Lee about this, who's active on the iconbar forum and the riscosopen forum too, or just port a thread to the latter forum and he along with anyone else interested will probably contribute.

Edit: When I say 'you' here I mostly mean the developer here who wants to port riscos to the Pyra of course.
 
  • Like
Reactions: rSl
EvilDragon said:
SGX only works fullscreen on the Pandora as well. But that wasn't a big deal, as 3D was only used for gaming on the Pandora which you only use in fullscreen anyways.
Click to expand...
Are you saying we're going to be stuck with full screen GL(ES) again? You refer to "3D", but it's not just 3D, or at least it wasn't on the Pandora. All my Allegro based games could not be used in a windowed mode.

That's really disappointing if that's going to be the case. Sure it might not have been an issue for most users, but i found it very frustrating during development, and limits done of my planned projects (not that my productivity is great, but still)
 
Isn't it kind of hard to play a game, 3D or otherwise, in a window on such a small screen anyway? A lot of people would have trouble seeing it.
 
pmprog said:
Are you saying we're going to be stuck with full screen GL(ES) again? You refer to "3D", but it's not just 3D, or at least it wasn't on the Pandora. All my Allegro based games could not be used in a windowed mode.

That's really disappointing if that's going to be the case. Sure it might not have been an issue for most users, but i found it very frustrating during development, and limits done of my planned projects (not that my productivity is great, but still)
Click to expand...

There are solutions to fix this, and there are already some ideas how to do it.
You're very welcome to help contributing or work on it as well :)
 
  • Like
Reactions: rSl
Silent-Hunter said:
Isn't it kind of hard to play a game, 3D or otherwise, in a window on such a small screen anyway? A lot of people would have trouble seeing it.
Click to expand...
I've never missed windowed 3D on my Pandora, to be honest.
On the Pyra, it could be useful for running webgl stuff in a browser.
 
hns said:
So this is a big breakthrough since I can now start to compare and fix things of the in-kernel driver tree (drivers/staging/pvr) until we get repeatable results. And most likely the problem with LetuxOS is that libX11-xcb makes unexpected interferences.
Click to expand...

I have good progress that I want to share with you:
  • I can now build a working SGX driver from the kernel tree and do no longer need the binaries provided in this thread
  • the working SGX driver will now be fully integrated into the letux-4.19 source code so that developers just need configure the kernel & make for future stable releases
  • is also working with letux-5.3-rc4 so that we can follow future mainline improvements in parallel
  • the "omap_hwmod: gpu: _wait_target_disable failed" is gone
  • I have found out that the interference "xcb_connect failed" occurs as soon as either libegl1-mesa, libegl1-mesa-drivers, libwayland-egl1-mesa is installed on my setup. Unfortunately xorg or building kmscube depend on them. Needs more analysis but is not a kernel or hardware issue.
So thanks to all who helped to get here.
 
You must log in or register to reply here.

Similar threads

aTc
  • Sticky
PyraOS Changelog
Replies
5
Views
7K
matzesu
matzesu
ToastBucket
Pyra Gitlab access
Replies
10
Views
4K
EvilDragon
EvilDragon
Silent-Hunter
Is the PyraOS going to have systemd-homed?
Replies
11
Views
6K
netcat
netcat
Linux-SWAT
Booting the Pyra : unifying the efforts.
Replies
14
Views
5K
aTc
aTc
sebt3
  • Sticky
Pyra pyra-builder: Docker based toolchain for pyra
Replies
4
Views
7K
sebt3
sebt3
Back
Top