.next development


aTc

Very Active Member
Joined
Apr 25, 2009
Messages
252
this topic is for a previous image, for the latest one, go here : http://boards.openpandora.org/index.php/topic/12336-new-next-image-help-needed/

right, here we go, .next.

Basically we're rebuilding all the pandora stuff on top of angstrom from scratch.
This time in a maintainable way, and with all the angstrom features working that were missing from the old firmware.
This should mean that from now on everything in the firmware will be reasonably up to date, and with a fully working package manager.

At the moment, pretty much everything pandora related is broken, so don't expect to be able to run ANY .pnd files.
This is NOWHERE near as usable as the HF/superzaxxon betas

A lot of the pandora stuff, and a few systemd things fail. Which is why we need help with this thing.
We need to find out why some things fail, which libraries are required in the basic firmware, which .pnd files cause problems, and why.

bugs can be reported here : http://bugs.openpand...x.php?project=3
Or just as a new topic in this section if you think more discussion is needed.


Staying backwards compatible with the old firmware is really something we want to avoid as much as possible.
If a .pnd can easily be recompiled to fix complaints about not finding the right library version, that's preferred to having to include lots of old libs.




How to get started:

The firmware images can be downloaded here :

http://next.openpandora.org/images/

There are 2 versions :


Angstrom-openpandora-xfce-image : should have everything the old firmware has, but has a lot of bloat in it too.
Angstrom-systemd-pndwip-image : only has the bare essentials for a working pandora image, more and more stuff gets added to this untill we get a nice lean image that can do everything.

If unsure, use xfce-image for now.

  • Download the image (http://next.openpand....rootfs.tar.bz2 )
  • Format an SD card to have a single ext2 partition.
  • Extract the image to SD
  • Insert SD card into the pandora, power on, and it should start to boot from it automatically.
  • The first boot takes quite a while (slightly shorter on the pndwip image), it will appear to get stuck on "Started Load Random Seed", but the SD led should keep blinking.
  • Eventually it'll go into the first run wizard, set it up as usual (only booting into xfce, without automatically login is tested)
  • After the first run wizard, it'll set up some more stuff, and end with "Starting SGX fixup for ES2.x" on screen.
  • The Login: prompt has scrolled offscreen, so you can just type "root" and log in (no password), The first run wizard doesn't reboot at the end, so you'll have to halt/reboot manually for now.
  • The second boot should be a LOT faster than the first, and should end up with the graphical login: prompt of slimdm.
  • Log in as the user you created in the first run wizard
And that's where things start to go wrong. It still has the old pandora xfce settings, which you can try to convert, or let it make a new one.
Most of the .pnd system doesn't work yet, but it is possible to run some .pnd files manually (most fail because they're trying to load old libraries that have been replaced with newer ones)

To get the usb port to work, you have to "modprobe ehci-hcd" first.
Wifi does work, but needs to be set up manually too, networkmanager doesn't start at boot yet.

opkg fully works now, and uses packages from our own feeds.
usage:

"opkg update" : download latest list of packages
"opkg upgrade" : upgrade packages to latest version. This can break during development, and sometimes it's required to download/extract a completely new image to get things back to a working state.
"opkg list" : list all available packages ( opkg search is a bit of a pain to use, so it's easier to just use "opkg list > opkg.txt" and then grep through opkg.txt to find what you want)
"opkg install" : install packages

All the -dev packages are in the feeds too, and doing "opkg install task-core-sdk" should install the basic tools required to compile stuff.

A crosscompiler toolchain is available here : http://next.openpand...2012.05.tar.bz2
Only for 64 bit systems at the moment.
Extract, and move to /usr/local/oecore-x86_64/
run ". /usr/local/oecore-x86_64/environment-setup-arm7a-angstrom-linux-gnueabi" to set up all the paths.
This one also has a fully working package manager included, to update the crosscompiler itself, and the pandora libs it uses.
"opkg-sdk" is used to update/upgrade the crosscompiler itself.
"opkg-target" is used to update/upgrade/install new libraries on the pandora side of the crosscompiler.
Both work exactly like opkg on the pandora itself.

How to build your own images :
(you really need to know what you're doing to use this)

It's recommended to use debian for this

git clone git://github.com/openpandora/setup-scripts.git
MACHINE=omap3-pandora ./oebb.sh config omap3-pandora
. ~/.oe/environment-angstromv2012.05
bitbake openpandora-xfce-image
 
Last edited by a moderator:
Staying backwards compatible with the old firmware is really something we want to avoid as much as possible.


If a .pnd can easily be recompiled to fix complaints about not finding the right library version, that's preferred to having to include lots of old libs.

I understand the need to keep the image small, but this means developers would possibly need to maintain 2+ versions of software to support both old and newer images. This is a big enough problem for me that i would almost stay with the current angstrom image.


What about symlinks to the new lib, assuming that the new lib works as the old.


What kernel is image using?


SGX is working?
 
The idea is to first find out, which of the new libraries aren't working anymore.


We've got the same libs, just more recent versions, hopefully most of them won't cause problems.


We'll try to get the ones that cause problems included within the new main OS (unless they need tons of space), but if one library is only needed for a handful of programs that can simply be recompiled, there's no need to keep this one for backwards compatibility.


The image should work with latest 3.2.17 kernel and SGX should be working.
 
Last edited by a moderator:
but if one library is only needed for a handful of programs that can simply be recompiled, there's no need to keep this one for backwards compatibility.

But then those apps wont work on older images. Then you have to think about how to host multiple pnds and make sure the user gets the right one.


I guess another alternative is for the pnds to contain the older libs themselves.


I understand the real situation isnt known yet, and I will try to test out my software on this image when i can.
 
Why should they work on old images?


Once the next OS is ready, it should be the new standard for all users.
 
Staying backwards compatible with the old firmware is really something we want to avoid as much as possible.
If a .pnd can easily be recompiled to fix complaints about not finding the right library version, that's preferred to having to include lots of old libs.

Looking on repo stats, it will be hard to re-compile all 600 apps/games/emus, and it will be streeetched in time badly, so many people will protest for sure when something will not work on new FW, and they'll refuse to update..
 
It isn't like nothing at all works anymore, and most things that fail can probably be solved by simply having a symlink from the old library name to the new one.


Most stuff using SDL works for example, because the app itself only opens SDL, and the freshly compiled SDL opens all the right library versions for the app.


At the moment the biggest problem is actually that alsa isn't configured properly, so there's no sound device set up, which causes a lot of programs to fail.


The "avoiding backwards compatibility" line wasn't meant as a "NONE of the existing .pnds work, and ALL will have to be rebuilt!"


Most only have minor problems that can be easily fixed.


It's just that when there's a choice between having to put some ugly hack in the build system, or rebuilding a single .pnd, rebuilding the pnd wins.


Things should be kept as close to the main angstrom/openembedded feeds as possible, to avoid ending up with a hacked together unmaintainable half working firmware again.


Of course at the next big upgrade the same thing will happen all over again, and the only real way of avoiding these problems is to only use statically compiled binaries in .pnds


Unfortunately that can be quite a pain to compile, and wastes a lot of space (although wasting space on SD is a lot less worse than wasting space on the nand)


Anyway, there are far bigger problems to solve in .next than a few .pnds that don't work.
 
I wonder if we could run a git for really popular releases - maintain and build them collectively on major changes? this would be for the really common showcases and if the developer approves,
 
Last edited by a moderator:
I may be being dense here, and I apologise in advance. Is hard-abi working in this firmware? I'll gladly rebuild any of my PND files if necessary. I gather that the only reason we're still in soft-abi land is due to it not having been implemented before a significant number of PNDs had already been built, not to mention a large chunk of the firmware.


D.
 
I may be being dense here, and I apologise in advance. Is hard-abi working in this firmware? I'll gladly rebuild any of my PND files if necessary. I gather that the only reason we're still in soft-abi land is due to it not having been implemented before a significant number of PNDs had already been built, not to mention a large chunk of the firmware.

you mean hard-fp/soft-fp? Either way I think we would lose SGX support with the binary blob which is soft-fp only.
 
I may be being dense here, and I apologise in advance. Is hard-abi working in this firmware? I'll gladly rebuild any of my PND files if necessary. I gather that the only reason we're still in soft-abi land is due to it not having been implemented before a significant number of PNDs had already been built, not to mention a large chunk of the firmware.

you mean hard-fp/soft-fp? Either way I think we would lose SGX support with the binary blob which is soft-fp only.

I was sure there was a good reason for it, and yes, that's what I was talking about (I'm quite drunk atm!). Thanks for the clarification.


D.
 
Staying backwards compatible with the old firmware is really something we want to avoid as much as possible.
If a .pnd can easily be recompiled to fix complaints about not finding the right library version, that's preferred to having to include lots of old libs.

I was planning to work zaxon-compat.pnd with support for that in pnd_run.sh sso the system can stay clean as much as possible.


My plan is to mount that zaxon-compat.pnd as an overlay over the PND mount point for every PND that doesnt claim to support the OS at 2.0.0.0 (or higher).


That PND will include every libs that are not found in the new OS (think jpeg62 and so on)


Sound like it's time for me to start on this ;)
 
I think compatibility should be preserved as much as possible, but avoiding major hacks; adding a 'compat' recipe that makes a package with some symlinks shouldn't be a big problem. Most libs should provide everything needed for old stuff to run already, only in extreme cases some pnds could need to be repacked to add some old libs into them (no need for a recompile), and that should not prevent them from running on old firmware.


For hardfp, maybe something like debian multiarch could be done, and only essential hardfp libs provided by default, but I doubt OE/Angstrom offers that. There is also an option of static linking. Both of these assume SGX is not used though..
 
Last edited by a moderator:
Will there be gtk 2 and 3 installed? I think that is one of the bigger concerns for backwardscompatibility while opening new possibilities.
 
Um, I'm sorry if I'm just being stupid, but I read through most of the posts on this board many times a day and I feel like I've missed a memo or something.


1. Is this official? It certainly *sounds* official, if in a "we're getting this started now but it's for a fair way off in the future" sort of way. Or maybe it's just an alternative, like PanDebian or Slackware, which is all well and good on an open system like this.


2. Who is aTc?


3. What's the relationship between this .next project and current firmware maintainers (eg notaz). Their involvement?


It all just seems to have come out of the woodwork, and I'm a little confused.
 
1. Is this official? It certainly *sounds* official, if in a "we're getting this started now but it's for a fair way off in the future" sort of way. Or maybe it's just an alternative, like PanDebian or Slackware, which is all well and good on an open system like this.
It is official. This project is ongoing since a while. DjWillis started it about a year ago.

2. Who is aTc?
A well known and respected member of this comunity since... the begining (despite his posts count ; irc)

3. What's the relationship between this .next project and current firmware maintainers (eg notaz). Their involvement?
Notaz is the Pandora kernel maintainer (beside his others projects).


The current firmware maintainer is EvilDragon.


aTc is now the current pandora .next project manager. it use notaz' kernel. And my guess are that ED will be the release manager


;)
 
6dMtu.jpg



Of all the people to reply..... ;) Just kidding.


Thankyou. Should be interesting to watch it develop over time.
 
Back
Top