I have also simplified the kernel upgrade mechanism for you.
If you connect the device to Ethernet and set the IP address in /etc/network/interfaces and make sure the device has access to the outside world, you can do
apt-get update apt-get install kernel-image-omap2plus
And each time you want to try a newer version, just do
apt-get update apt-get upgrade
Flashing a new SD card is only needed if something is broken and the kernel does not boot any more or the device has no Ethernet connection.
The kernel package I have published will come from (like the devmen2 package):
http://download.goldelico.com/gta04/debian/dists/stable/main/binary-armhf/
So it should be quite simple to keep all the EVMs up to date with the latest kernel developments.
Generally my publication process on the server is:
get kernel source -> (cross-)compile -> collect kernel+DT+modules for .deb -> make the .deb -> copy to repository -> update Packages.gz -> notify users
In the far future, we can move this process to pyra-handheld.com with its own package repository and build scripts.
Please try and give me a notice about problems (the latest binary should have the evtest for BTN1 working).
BR, Nikolaus
Am Sat, 18 Jan 2014 22:58:17 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
are you still updating the kernel package? Seems like the last update is from February - that does not include the LCD driver yet, does it?
I have also simplified the kernel upgrade mechanism for you.
If you connect the device to Ethernet and set the IP address in /etc/network/interfaces and make sure the device has access to the outside world, you can do
apt-get update apt-get install kernel-image-omap2plus
And each time you want to try a newer version, just do
apt-get update apt-get upgrade
Flashing a new SD card is only needed if something is broken and the kernel does not boot any more or the device has no Ethernet connection.
The kernel package I have published will come from (like the devmen2 package):
http://download.goldelico.com/gta04/debian/dists/stable/main/binary-armhf/
So it should be quite simple to keep all the EVMs up to date with the latest kernel developments.
Generally my publication process on the server is:
get kernel source -> (cross-)compile -> collect kernel+DT+modules for .deb -> make the .deb -> copy to repository -> update Packages.gz -> notify users
In the far future, we can move this process to pyra-handheld.com with its own package repository and build scripts.
Please try and give me a notice about problems (the latest binary should have the evtest for BTN1 working).
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
okay, I've now updated the OS, grabbed the latest kernel and config files from http://download.goldelico.com/DragonFly/unstable/ and the LCD is now basically working.
Actually, I've got good eyes - I can easily read all the test in default settings, but changing the dpi to 140 makes it more comfortable. I expected it a lot worse - but I actually like the high desktop resolution.
Anyways, I now wanted to test the display rotation.
Here is my boot.scr script:
setenv devicetree omap5-pyra fatload mmc 0:1 0x825f0000 ${devicetree}.dtb fatload mmc 0:1 0x80300000 uImage # fixme: load bootargs.scr from SD setenv bootargs 'elevator=noop console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait earlyprintk fixrtc omapfb.tiler=y omapfb.rotate=1' setenv fdt_high 0x84000000 bootm 0x80300000 - 0x825f0000
However, it seems the omapfb-parameters are not working. Possibly because we're using omapdrm?
If that's the case, does anyone know how I can enable the rotation?
Thanks :)
Well, didn't get hardware rotation to work yet, but at least I could rotate the X server screen, so the desktop runs properly.
Of course, that's done in software, so it slows down the X Server a bit (but not as much as I thought).
Nikolaus: You mentioned you could not run a DE, only direct programs - well, probably because of portrait mode. I didn't get any panel in portrait mode as well - seems like Linux DEs expect the screen to be widescreen.
Try the attached xorg.conf, that should work.
One small bug: The screen is shifted a bit to the right, but that's only with the rotation (so probably a software, not a driver bug)
The PSX Emulator still runs fine with that rotation, as does a GameBoy emulator (Gambatte) and SNES9x.
Gambatte (using SDL) heavily slows down when scaling - cries for hardware acceleration :)
So far, whatever I've been trying, I didn't have ANY ghosting on the display! It has a VERY dark black and very nice colors.
On Tue, 11 Mar 2014, Michael Mrozek wrote:
# Well, didn't get hardware rotation to work yet, but at least I could # rotate the X server screen, so the desktop runs properly.
Didn't know you could do that :O
# You mentioned you could not run a DE, only direct programs - well, # probably because of portrait mode.
Shouldn't matter; Unix displays have come in Portrait for a long long time .. was using them 20 years ago. (Pretty glorious too ..)
Sorry, I can't offer any advice here, just noting that portrait should ("should") be okay.
# So far, whatever I've been trying, I didn't have ANY ghosting on the # display! # It has a VERY dark black and very nice colors.
Great stuff :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Am Tue, 11 Mar 2014 00:24:08 -0400 (EDT) hat skeezix skeezix@skeleton.org geschrieben:
Hi,
# Well, didn't get hardware rotation to work yet, but at least I could # rotate the X server screen, so the desktop runs properly. Didn't know you could do that :O
Well, it's a parameter for the fbdev driver, so it's not X that's doing it, but the driver :)
# You mentioned you could not run a DE, only direct programs - well, # probably because of portrait mode. Shouldn't matter; Unix displays have come in Portrait for a long long time .. was using them 20 years ago. (Pretty glorious too ..)
Right... and that got me thinking.
Sorry, I can't offer any advice here, just noting that portrait should ("should") be okay.
That's actually good advice - as I thought about that shifting of the display again and made some tests.
It seems we still have a bug in either the display driver or the DSS from the OMAP5.
The full picture is shifted DOWN. Means: In portrait mode, at the top at the display, there's a small black bar - and at the bottom of the display, the same amount of pixels are not shown.
This is already the case when Tux (while booting) appears.
Which explains also why we didn't have a panel in portrait mode - the panel is on the bottom (and that part of the screen is missing).
# So far, whatever I've been trying, I didn't have ANY ghosting on the # display! # It has a VERY dark black and very nice colors.
Great stuff :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war. _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On the Road --- hns
Am 11.03.2014 um 12:18 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Tue, 11 Mar 2014 00:24:08 -0400 (EDT) hat skeezix skeezix@skeleton.org geschrieben:
Hi,
# Well, didn't get hardware rotation to work yet, but at least I could # rotate the X server screen, so the desktop runs properly. Didn't know you could do that :O
Well, it's a parameter for the fbdev driver, so it's not X that's doing it, but the driver :)
# You mentioned you could not run a DE, only direct programs - well, # probably because of portrait mode. Shouldn't matter; Unix displays have come in Portrait for a long long time .. was using them 20 years ago. (Pretty glorious too ..)
Right... and that got me thinking.
Sorry, I can't offer any advice here, just noting that portrait should ("should") be okay.
That's actually good advice - as I thought about that shifting of the display again and made some tests.
It seems we still have a bug in either the display driver or the DSS from the OMAP5.
The full picture is shifted DOWN. Means: In portrait mode, at the top at the display, there's a small black bar - and at the bottom of the display, the same amount of pixels are not shown.
This is already the case when Tux (while booting) appears.
Which explains also why we didn't have a panel in portrait mode - the panel is on the bottom (and that part of the screen is missing).
That should be adjustable by the Front and back Porch settings of our driver
# So far, whatever I've been trying, I didn't have ANY ghosting on the # display! # It has a VERY dark black and very nice colors.
Great stuff :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war. _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 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 _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 11/03/14 13:18, Michael Mrozek wrote:
It seems we still have a bug in either the display driver or the DSS from the OMAP5.
The full picture is shifted DOWN. Means: In portrait mode, at the top at the display, there's a small black bar - and at the bottom of the display, the same amount of pixels are not shown.
I noticed the same. I got it working right, but I have to say that's one picky panel (or controller). And the specs didn't give much help there.
I pushed my changes to my mainline based pyra panel branch. Here's link to the panel file:
https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/vi...
With those settings, I get a proper image with 60Hz refresh rate. It may take some work to port those to the old kernel, as the recent kernels calculate most of the values automatically.
Tomi
Hi,
as I played with the display yesterday, I have a few questions.
1. Picture is shifted: As I mentioned in one of the other posts, the picture is shifted about 40 pixels at the top (black bar) and at the bottom, these 40 pixels are missing as well (they would be outside of the screen). Tux should also appear in the top left corner and is also shifted down while booting. So either the DSS or the display driver are shifting the image down. Any idea what? :)
2. Is the display brightness set to automatic right now? It's not very bright (darker than the Pandora display in full brightness). Can we set the brightness normally? I'd like to see it in full brightness for testing.
Apart from the one issue above and the second question, the display seems to be working fine.
It'll be quite a bit of work to create themes for gtk, QT, etc. to make them work properly (without having too tiny fonts), but that was to be expected.
It's a bit annoying that some apps (like FireFox) don't make use of the DPI settings...
XFCE4 works fine and looks great with DPI set to 140, but not all apps are using that.
Something that could be improved in Linux :)
Today I took the time to dive a bit into what driver to use for our X-Server.
Basically, it seems there are three different drivers for us:
* omapfb: Outdated, replaced by omapdrm * fbdev: What we're currently using. Slow but works * omap: The DRM driver
fbdev works fine, as we all know. It has a neat driver option to rotate the display, so I can already run it in landscape mode.
omap: Once you install the package xserver-xorg-video-omap, you can also use "omap" as driver in xorg.conf.
That's an OpenSource-SGX driver which features hardware acceleration, GLES usage, etc.
Doesn't seem to have been updated for a while though: https://github.com/robclark/xf86-video-omap
The driver in Debian runs out of the box. X feels WAY faster. I couldn't test stability yet, as it needs X.Org 1.14 or higher and the one notaz recompiled was 1.12. I tried recompiling 1.15 on my devboard, but it simply segfaulted as before (also when using fbdev).
notaz, maybe you could compile X.Org 1.15 (from Debian unstable) for me? :)
I think this driver still needs the 3D PVR stuff from TI, but I'd like to test speed and stability for 2D.
This driver doesn't have a rotation option - but as mentioned, we need to get that done for the full system using the DSS anyways.
Just a quick information for all of you:
Michael Weston, the designer of the Pandora PCB has joined this mailing list as well :)
I'm sure he'll be useful with some design ideas as well as reviewing schematics :)
On 03/12/2014 03:58 AM, Michael Mrozek wrote:
I couldn't test stability yet, as it needs X.Org 1.14 or higher and the one notaz recompiled was 1.12. I tried recompiling 1.15 on my devboard, but it simply segfaulted as before (also when using fbdev).
notaz, maybe you could compile X.Org 1.15 (from Debian unstable) for me? :)
So you compiled it on stable, or did you upgrade your whole distro to unstable first? Compiling 1.15 on stable doesn't work, as expected:
configure: error: Package requirements (pixman-1 >= 0.27.2) were not met: Requested 'pixman-1 >= 0.27.2' but version of Pixman is 0.26.0
..and I know that mixing packages often breaks the system (I have no desire to reconfigure everything).
Grazvydas
Am Thu, 13 Mar 2014 02:11:20 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
The first thing I did when I got the devboard was installing Debian using the scripts from Nikolaus, changed repositories to unstable and updated.
I've always run unstable Debian on my board and simply downgraded X when I got your fixed binary :)
On 03/12/2014 03:58 AM, Michael Mrozek wrote:
I couldn't test stability yet, as it needs X.Org 1.14 or higher and the one notaz recompiled was 1.12. I tried recompiling 1.15 on my devboard, but it simply segfaulted as before (also when using fbdev).
notaz, maybe you could compile X.Org 1.15 (from Debian unstable) for me? :)
So you compiled it on stable, or did you upgrade your whole distro to unstable first? Compiling 1.15 on stable doesn't work, as expected:
configure: error: Package requirements (pixman-1 >= 0.27.2) were not met: Requested 'pixman-1 >= 0.27.2' but version of Pixman is 0.26.0
..and I know that mixing packages often breaks the system (I have no desire to reconfigure everything).
Grazvydas
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 03/13/2014 05:34 AM, Michael Mrozek wrote:
Am Thu, 13 Mar 2014 02:11:20 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
The first thing I did when I got the devboard was installing Debian using the scripts from Nikolaus, changed repositories to unstable and updated.
I've always run unstable Debian on my board and simply downgraded X when I got your fixed binary :)
Ok updated my setup to testing (it also uses 1.15) and the build worked. I'm also attaching a patch of my changes, it just basically overrides the default thumb mode (that's set in compiler) to ARM and -mcpu to cortex-a15, that somehow solves the issue. It would be good to eventually dig the root cause of this and send a fix upstream, but quite a significant effort is needed for that..
And Debian testing has x11vnc broken (works on stable), how annoying..
Grazvydas
Am Fri, 14 Mar 2014 04:16:49 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
Thanks, that works. Still some slowness with omap-driver and it completely goes crazy when rotating the display, but that might be because I had HWCursor enabled (which you shouldn't do) and maybe EXA module or PVR is missing (I read somewhere about slowness of omap-driver when something is missing...)
I'll play around with it.
On 03/13/2014 05:34 AM, Michael Mrozek wrote:
Am Thu, 13 Mar 2014 02:11:20 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
The first thing I did when I got the devboard was installing Debian using the scripts from Nikolaus, changed repositories to unstable and updated.
I've always run unstable Debian on my board and simply downgraded X when I got your fixed binary :)
Ok updated my setup to testing (it also uses 1.15) and the build worked. I'm also attaching a patch of my changes, it just basically overrides the default thumb mode (that's set in compiler) to ARM and -mcpu to cortex-a15, that somehow solves the issue. It would be good to eventually dig the root cause of this and send a fix upstream, but quite a significant effort is needed for that..
And Debian testing has x11vnc broken (works on stable), how annoying..
Grazvydas