.next alpha image
- Thread starter aTc
- Start date
My /etc/powervr-esrev says "2" - the same as it says in SuperZaxxon.
I'm fairly sure the GPU problems were because libgles-omap3-es2 wasn't installed, and so when pvr-init ran the first time, it only copied over the libpvrPVR libraries from /usr/lib/ES2.0 into /usr/lib/, and not all the other libraries that libgles-omap3-es2 puts into /usr/lib/ES2.0 (e.g libEGL, libIMegl, and libsrv_um).
For me, after installing libgles-omap3-es2, and forcing pvr-init to do it's SGX fixup by deleting /etc/powerver-esrev, then the demos (in /usr/bin/SGX/demos/X11) worked.
More excitingly, after following the hint from aTc and also changing /etc/powervr.ini to the same as SuperZaxxon (so WindowSystem=libpvrPVR2D_FRONTWSEGL.so), now A7Xpg also works!!
(I checked and copied the old libraries back, and the demos and A7Xpg stopped working, so they do seem to need the new libraries aswell the powervr.ini edit).
klaxon: does your /etc/powervr-esrev not say "2" (or "3", or "5"). Is it maybe the case that pvr-init successfully recognises ES2 hardware, but not the other ones?
I'm fairly sure the GPU problems were because libgles-omap3-es2 wasn't installed, and so when pvr-init ran the first time, it only copied over the libpvrPVR libraries from /usr/lib/ES2.0 into /usr/lib/, and not all the other libraries that libgles-omap3-es2 puts into /usr/lib/ES2.0 (e.g libEGL, libIMegl, and libsrv_um).
For me, after installing libgles-omap3-es2, and forcing pvr-init to do it's SGX fixup by deleting /etc/powerver-esrev, then the demos (in /usr/bin/SGX/demos/X11) worked.
More excitingly, after following the hint from aTc and also changing /etc/powervr.ini to the same as SuperZaxxon (so WindowSystem=libpvrPVR2D_FRONTWSEGL.so), now A7Xpg also works!!
(I checked and copied the old libraries back, and the demos and A7Xpg stopped working, so they do seem to need the new libraries aswell the powervr.ini edit).
klaxon: does your /etc/powervr-esrev not say "2" (or "3", or "5"). Is it maybe the case that pvr-init successfully recognises ES2 hardware, but not the other ones?
Last edited by a moderator:
aTc
Very Active Member
- Joined
- Apr 25, 2009
- Messages
- 253
I've made some changes to the various recipes, and things now seem to work.
At least good enough to run the Jedi Knight 3 demo.
The pnd itself segfaults all over the place, probably because its including a lot of libs that already have versions in the firmware itself,
but the thing works when you unpack the pnd and run things manually.
One of the problems was actually the sgx demos i included, its dependencies overwrite the settings in powervr.ini.
A opkg update/upgrade probably doesn't bring things into a working state, so it's recommended to reinstall the image.
http://next.openpandora.org/v2012.12/images/openpandora/Angstrom-OP-XFCE-NetworkManager-image-eglibc-ipk-v2012.12-openpandora.rootfs.tar.xz
At least good enough to run the Jedi Knight 3 demo.
The pnd itself segfaults all over the place, probably because its including a lot of libs that already have versions in the firmware itself,
but the thing works when you unpack the pnd and run things manually.
One of the problems was actually the sgx demos i included, its dependencies overwrite the settings in powervr.ini.
A opkg update/upgrade probably doesn't bring things into a working state, so it's recommended to reinstall the image.
http://next.openpandora.org/v2012.12/images/openpandora/Angstrom-OP-XFCE-NetworkManager-image-eglibc-ipk-v2012.12-openpandora.rootfs.tar.xz
sebt3
homebrew player (P. & C.)
Yay for new stuff.
I have one problem with it though: USB-OTG stopped working. As in the small port with an adapter to host stuff (1.1 and 2.0 devices). The normal, big port (2.0 only) works.
In SuperZaxxon, my KVM-Switch and the connected mouse and keyboard work. If I reboot into .next, they don't. I already looked at dmesg, but there is nothing useful there (in .next), I think.
I have one problem with it though: USB-OTG stopped working. As in the small port with an adapter to host stuff (1.1 and 2.0 devices). The normal, big port (2.0 only) works.
In SuperZaxxon, my KVM-Switch and the connected mouse and keyboard work. If I reboot into .next, they don't. I already looked at dmesg, but there is nothing useful there (in .next), I think.
aTc
Very Active Member
- Joined
- Apr 25, 2009
- Messages
- 253
I don't have an otg adapter here, so I can't test it myself.
Reading through the wiki and some forums posts, it's most likely because the g_cdc kernel module isn't loaded.
You could try doing a "sudo modprobe g_cdc" , and then plugging in the otg stuff.
Reading through the wiki and some forums posts, it's most likely because the g_cdc kernel module isn't loaded.
You could try doing a "sudo modprobe g_cdc" , and then plugging in the otg stuff.
aTc
Very Active Member
- Joined
- Apr 25, 2009
- Messages
- 253
No easy solution for that unfortunately.
A lot of pnds segfault on .next.
I think it's caused by the pnd having versions of libs in it that clash with the ones in .next itself.
If you look through the logs even things like a "cp" that the pnd runs to copy some files around segfaults.
But i've already mention that in previous posts.
A lot of pnds segfault on .next.
I think it's caused by the pnd having versions of libs in it that clash with the ones in .next itself.
If you look through the logs even things like a "cp" that the pnd runs to copy some files around segfaults.
But i've already mention that in previous posts.
Just tried it myself.
With Qupzilla, it's libdl.so that creates the segfault.
Removing this will make Qupzilla work.
With Qupzilla, it's libdl.so that creates the segfault.
Removing this will make Qupzilla work.
My plan for my PNDs that need updating for .next was for there to a temporary period where the PND contains enough stuff for both SuperZaxxon and .next, and the startup script chooses between them.
So, internally, it would have:
libs_for_next/
libstuff.so.1
libs_for_superzaxxon/
libthings.so.1
and the startup script would do:
if [ OS == .next ]
then
LD_LIBRARY_PATH=./libs_for_next
else
LD_LIBRARY_PATH=./libs_for_superzaxxon
fi
That said, once .next is officially released, we don't have to support superzaxxon any more - anybody still using it for whatever reason can always download an archived copy of a PND.
So, internally, it would have:
libs_for_next/
libstuff.so.1
libs_for_superzaxxon/
libthings.so.1
and the startup script would do:
if [ OS == .next ]
then
LD_LIBRARY_PATH=./libs_for_next
else
LD_LIBRARY_PATH=./libs_for_superzaxxon
fi
That said, once .next is officially released, we don't have to support superzaxxon any more - anybody still using it for whatever reason can always download an archived copy of a PND.
Agree.
hmc
Active Member
I only partially agree.
There may be reasons for people to stay on SuperZaxxon for some time, even after .next is released.
Or will you only release .next, once EVERYTHING works flawlessly in it, that already worked flawlessly on SuperZaxxon? Then it may be okay to drop SuperZaxxon support in newer PNDs.
However, no matter how the answer to above question is, during the time when both firmware variants are around, these problems will occur:
1. It will create big efforts for PND maintainers to support both firmware variants in the way you describe, freamon
2. Many PNDs won't be upgraded during that time, or even not at all anymore, so they will never be comatible with .next, even if they could if only one lib was removed / replaced.
So I suggest rather finding another solution to make old PNDs also run in .next, e.g. by providing some "compatibility mode" (reminds you of Windows? Yes, sort of ;-).
I am not enough of an expert to guess, if something like that could work with reasonable efforts, but what about solving most PND lib problems with symlinks, and those that are not solvable with symlinks, solve with providing SZ lib version AND .next lib version in parallel in some way? If not both lib versions can coexist in one system, then some switching mechanism, that symlinks either version in place could be used maybe?
There may be reasons for people to stay on SuperZaxxon for some time, even after .next is released.
Or will you only release .next, once EVERYTHING works flawlessly in it, that already worked flawlessly on SuperZaxxon? Then it may be okay to drop SuperZaxxon support in newer PNDs.
However, no matter how the answer to above question is, during the time when both firmware variants are around, these problems will occur:
1. It will create big efforts for PND maintainers to support both firmware variants in the way you describe, freamon
2. Many PNDs won't be upgraded during that time, or even not at all anymore, so they will never be comatible with .next, even if they could if only one lib was removed / replaced.
So I suggest rather finding another solution to make old PNDs also run in .next, e.g. by providing some "compatibility mode" (reminds you of Windows? Yes, sort of ;-).
I am not enough of an expert to guess, if something like that could work with reasonable efforts, but what about solving most PND lib problems with symlinks, and those that are not solvable with symlinks, solve with providing SZ lib version AND .next lib version in parallel in some way? If not both lib versions can coexist in one system, then some switching mechanism, that symlinks either version in place could be used maybe?
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
Trying to put this on an SD card, but I get a bunch of lines saying "Cannot mknod: Operation not permitted"
From my /media/dotNext path of my desktop, I was using
tar -xJf Angstrom-OP-XFCE-NetworkManager-image-eglibc-ipk-v2012.12-openpandora.rootfs.tar.xz .
Is this right? Do I just sudo the command? or will that mess up my desktop Linux?
Cheers
From my /media/dotNext path of my desktop, I was using
tar -xJf Angstrom-OP-XFCE-NetworkManager-image-eglibc-ipk-v2012.12-openpandora.rootfs.tar.xz .
Is this right? Do I just sudo the command? or will that mess up my desktop Linux?
Cheers
Last edited by a moderator:
sebt3
homebrew player (P. & C.)
you can use "tar tf <filename>" to get the content of a tarball to be sure.
Else, indeed extracting that file requiere root privileges.
Else, indeed extracting that file requiere root privileges.
