Hi,
pandora-kernel.git pandora-37 branch has been rebased to 2.6.37.2 . This means in case you have this branch cloned, you need to rebase it: git fetch git rebase remotes/origin/pandora-37
Also latest aufs patches have been merged into that branch, and proposed kernel config to use in firmware (arch/arm/configs/omap3_pandora_defconfig) has been added. The config is based on one we use in .27, but some more things made as modules to shift size out of uImage (to reduce u-boot workload which is slow because u-boot works with caches disabled). DJWillis, if you can use that defconfig directly somehow than hook it in, if not we'll need to sync that with OE tree regularly.
currently known issues: - NAND driver seems to be broken and needs to be debugged (broke sometime in 2.6.32-2.6.34 era, mainline people don't seem to use NAND which is bad luck) - OSS emulation is broken - BT is missing (maybe use userspace bluez instead of hacking kernel driver this time?) - the new charging driver doesn't set charge current, so charging may take long time - kernel starts in 32bpp mode which xf86-video-omap doesn't like, but maybe newer xf86-video-omap will handle this. If not, stick 'fbset -depth 16' in slim-init or somewhere else before X.
to those few of us who have a serial bob, serial device has been changed because of new OMAP specific serial driver: old: /dev/ttyS0 new: /dev/ttyO2 so update your bootargs.
-- Gražvydas
Hey Gražvydas,
pandora-kernel.git pandora-37 branch has been rebased to 2.6.37.2 . This means in case you have this branch cloned, you need to rebase it: git fetch git rebase remotes/origin/pandora-37
Great
Also latest aufs patches have been merged into that branch, and proposed kernel config to use in firmware (arch/arm/configs/omap3_pandora_defconfig) has been added. The config is based on one we use in .27, but some more things made as modules to shift size out of uImage (to reduce u-boot workload which is slow because u- boot works with caches disabled). DJWillis, if you can use that defconfig directly somehow than hook it in, if not we'll need to sync that with OE tree regularly.
I have got a tweaked recipe that pulls in the omap3_pandora_defconfig and makes no changes to it. I'll test this with the rebased tree but if that works I'll commit the recipe tomorrow (it was working before the rebase but with the minimal config that was in the kernel tree, I expect no problems).
Also, thanks for doing the AUFS stuff, that really simplifies the OE side of things :).
currently known issues:
- NAND driver seems to be broken and needs to be debugged (broke
sometime in 2.6.32-2.6.34 era, mainline people don't seem to use NAND which is bad luck)
- OSS emulation is broken
- BT is missing (maybe use userspace bluez instead of hacking kernel driver
this time?)
- the new charging driver doesn't set charge current, so charging may take
long time
- kernel starts in 32bpp mode which xf86-video-omap doesn't like, but
maybe newer xf86-video-omap will handle this. If not, stick 'fbset -depth 16' in slim-init or somewhere else before X.
to those few of us who have a serial bob, serial device has been changed because of new OMAP specific serial driver: old: /dev/ttyS0 new: /dev/ttyO2 so update your bootargs.
Good to note, people should expect to consider most of that 'known issues' for now as I am just looking to get working images with this kernel. I'll make sure the fbset is in if it is needed but I am also pulling in the latest xf86-video-omap so I'll check that is actually still broken 1st ;).
Thanks again,
John
John, here is some WIP graphics for you :) Not 100% happy with the colors right now, but enough for an experimental release ;)
haha, nice, lol .. Yars Revenge :) A classic :)
I called Yamato back when we made Zaxxon, but Yars.. haha, so awesome :)
jeff
On Sun, 27 Feb 2011, Michael Mrozek wrote:
# # # John, here is some WIP graphics for you :) # Not 100% happy with the colors right now, but enough for an # experimental release ;) # # -- # Mit freundlichen Gr��en, # # Michael Mrozek # # ----------------------- # OpenPandora GmbH # Gesch�ftsf�hrer: Michael Mrozek # # Josef-Ponschab-Str. 8 # 85049 Ingolstadt # Deutschland # Tel.: 0841 / 13 177 33 # http://www.openpandora.de/ # HRB 4879, Amtsgericht Ingolstadt # ----------------------- # ICQ: 15691903 # MSN: EvilDragon1717@hotmail.com # eMail: info@openpandora.de # # # !DSPAM:4d69b0d0726701221318276! #
-- If everyone would put barbecue sauce on their food, there would be no war.
I'd suggest my attachment.
On Sun, Feb 27, 2011 at 12:23 PM, John Willis <John.Willis@distant-earth.com
wrote:
Thanks Mike,
John, here is some WIP graphics for you :) Not 100% happy with the colors right now, but enough for an experimental release ;)
I'll drop them in to the .next tree.
John
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Hiya,
I'd suggest my attachment.
I quite like it but a few observations.
The boot logo's should have 'Powered by Ångström' somewhere in it and ideally the www.openpandora.org URL (that covers us and give the Ångström guys a nod, something I am quite insistent we do).
Also, a restriction of psplash is that the progress bar is a fixed rectangle (no rounded corners) and the bar would need to be a separate image (see Ed's example). That is one of the reasons we have kept it quite simple ;).
With that in mind I'll keep Ed's startup screen in the .next stuff for now but don't let this discourage you. The clean and simple aesthetic is rather pleasing.
Thanks,
John
On Sat, Mar 12, 2011 at 7:21 PM, John Willis John.Willis@distant-earth.comwrote:
Hiya,
I'd suggest my attachment.
I quite like it but a few observations.
The boot logo's should have 'Powered by Ångström' somewhere in it and ideally the www.openpandora.org URL (that covers us and give the Ångström guys a nod, something I am quite insistent we do).
There's a lot of other and better places this could be placed. I feel like the version and the experimental discalmer is enough.
Also, a restriction of psplash is that the progress bar is a fixed rectangle (no rounded corners) and the bar would need to be a separate image (see Ed's example). That is one of the reasons we have kept it quite simple ;).
So psplash doesn't support overlaying one image on another? Doesn't sound like a particularly hard thing to add.
I see that psplash is in usermode, how long does it take boot to usermode? and how long after usermode is loaded until the loading is done? Also do you turn off the LCD until there is valid data in it? (one cool thing could be to fade the LCD on using PWM.)
With that in mind I'll keep Ed's startup screen in the .next stuff for now but don't let this discourage you. The clean and simple aesthetic is rather pleasing.
Thanks,
John
Hiya,
I see that psplash is in usermode, how long does it take boot to usermode?
and how long after usermode is loaded until the loading is done?
Also do you turn off the LCD until there is valid data in it? (one cool
thing could be to fade the LCD on using PWM.) Kernel mode -> user mode splashes on embedded systems are a bit of a mess, there is some nice tech. out there but it needs work to glue it all together, the KMS stuff has a bearing on this also. Things such as Plymouth also.
User mode is up quick enough, you can get an exact figure for the psplash load by turning on your OpenPandora and see how long it is till the logo shows up ;).
Feel very free to hack on psplash (and the LCD PWM if that floats your boat), you can grab the code from Poky's SVN (http://labs.o-hand.com/psplash/). None of this is very hard to do but it needs someone to do it. If you're that person I salute you :).
You will want to mesh on the patches from our GIT tree (in .next you want over the top of Poky's SVN as there are a few hacks/fixes we did (The Poky guys are not really maintaining psplash anymore so the patches did not go far when pushed upstream).
I think the URL is http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=tree;f=re cipes/psplash/psplash-omap3pandora;b=op.openembedded.next for the patches.
Regards,
John