Contributing to PyraOS

Discussion in 'Pyra OS (Debian GNU/Linux)' started by ToastBucket, Jul 30, 2019.

  1. hns

    hns Very Active Member

    Joined:
    Jul 16, 2012
    Messages:
    349
    Location:
    Oberhaching
    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.
     
    rSl likes this.
  2. ToastBucket

    ToastBucket Member

    Joined:
    Oct 12, 2010
    Messages:
    178
    Location:
    Seattle
    @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
     
  3. hns

    hns Very Active Member

    Joined:
    Jul 16, 2012
    Messages:
    349
    Location:
    Oberhaching
    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 :)
    --- Double Post Merged, Aug 5, 2019, Original Post Date: Aug 5, 2019 ---
    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: Aug 5, 2019
    ingoreis, rSl, ptitSeb and 2 others like this.
  4. ToastBucket

    ToastBucket Member

    Joined:
    Oct 12, 2010
    Messages:
    178
    Location:
    Seattle
    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.
     
  5. hns

    hns Very Active Member

    Joined:
    Jul 16, 2012
    Messages:
    349
    Location:
    Oberhaching
    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: Aug 5, 2019
    rSl likes this.
  6. ToastBucket

    ToastBucket Member

    Joined:
    Oct 12, 2010
    Messages:
    178
    Location:
    Seattle
    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: Aug 5, 2019
    rSl likes this.
  7. Grench

    Grench Forum Addict!

    Joined:
    Oct 3, 2008
    Messages:
    6,102
    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!
     
    ClockworkCoder, rSl and directive0 like this.
  8. ClockworkCoder

    ClockworkCoder Chaotic Neutral

    Joined:
    Jan 21, 2016
    Messages:
    1,013
    Location:
    Menzoberranzan
  9. ingoreis

    ingoreis Advanced Member

    Joined:
    Mar 7, 2012
    Messages:
    3,094
    Location:
    49.491276,8.423518
    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 :)
     
  10. hns

    hns Very Active Member

    Joined:
    Jul 16, 2012
    Messages:
    349
    Location:
    Oberhaching
    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.
     
    rSl, Haraldur and ingoreis like this.
  11. EvilDragon

    EvilDragon Administrator Staff Member

    Joined:
    Mar 4, 2003
    Messages:
    19,749
    Location:
    Ingolstadt
    Android usually runs on OpenGL, so TILER rotation is not even needed there.
     
    Haraldur and ingoreis like this.
  12. ingoreis

    ingoreis Advanced Member

    Joined:
    Mar 7, 2012
    Messages:
    3,094
    Location:
    49.491276,8.423518
    Ah i see ..thank you both ..good explained :)
     
  13. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    11,086
    Location:
    Somewhere off the coast of the EU
    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.
     
    rSl likes this.
  14. pmprog

    pmprog Advanced Member

    Joined:
    Apr 25, 2011
    Messages:
    3,825
    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)
     
  15. Silent-Hunter

    Silent-Hunter Hardcore Member

    Joined:
    May 29, 2010
    Messages:
    3,046
    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.
     
  16. EvilDragon

    EvilDragon Administrator Staff Member

    Joined:
    Mar 4, 2003
    Messages:
    19,749
    Location:
    Ingolstadt
    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 :)
     
    rSl likes this.
  17. EvilDragon

    EvilDragon Administrator Staff Member

    Joined:
    Mar 4, 2003
    Messages:
    19,749
    Location:
    Ingolstadt
    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.
     
  18. Silent-Hunter

    Silent-Hunter Hardcore Member

    Joined:
    May 29, 2010
    Messages:
    3,046
    I was thinking about WebGL after I sent that, yeah.
     
  19. pmprog

    pmprog Advanced Member

    Joined:
    Apr 25, 2011
    Messages:
    3,825
    That's good news

    I'd love to, but I don't have a clue about kernel drivers and most of linux's systems, I wouldn't even know where to start
     
    rSl likes this.
  20. hns

    hns Very Active Member

    Joined:
    Jul 16, 2012
    Messages:
    349
    Location:
    Oberhaching
    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.
     
    b_o_b, Djoga'Ro, Grench and 16 others like this.

Share This Page

Loading...