Hi, I have seen there has been a recent discussion on IRC:
<aTc> yeah, im compiling a kernel <aTc> and it failed <aTc> what a surprise
why did you expect that?
<aTc> same error as the one from the pyra git <aTc> make[6]: *** No rule to make target 'drivers/video/fbdev/omap2/displays-new/panel-success-s90451.c', needed by 'drivers/video/fbdev/omap2/displays-new/panel-success-s90451.o'. Stop.
The error message above (and the one for the bb+b1) comes from missed files. I simply forgot to check them in after fixing something before Xmas holidays and because my local compile worked it remained unnoticed.
I noticed myself some days ago when doing a make clean on a different machine. It has been fixed in 3.19-rc3.
<urjaman> sounds like somebody doesnt know git add
somebody does not know how to be polite and fair and someone who has never made a mistake in his life.
<aTc> yeah, the gta kernels do have that problem quite a lot
all gta04 kernels? I think only the last 3 or 4 versions had it.
<aTc> it's usually the his collection of .dts files that isn't one there <aTc> but this one doesn't even get to that stage <aTc> https://eewiki.net/display/linuxonarm/OMAP5432+uEVM <aTc> stuff from there is far more reliable
what do you mean with “reliable”?
<aTc> which is what i use
So in summary, please give me a favour and ask me (e.g. by private mail or by inviting me to IRC or here on this list) before you spread FUD and question my reputation or the reliability of my work in public. Especially as it was quite some work to get it to the state where it already is.
Compiling should go the following:
checkout 3.19-rc3 use gta04_defconfig copy omap5-pyra*.dtb on the boot partition copy modules to the rootfs partition
You can even beta-test a very new tool:
http://projects.goldelico.com/p/gta04-makesd/
run ./makesd pyra -k http://url-for-your/uImage -d http://url-for-your/device-tree.tbz
Handling different panels connected to the EVM it is a little tricky. There is a panelselect script in GTA04/root which can be installed on the Pyra rootfs and allows to overwrite the default omap5-pyra.dtb by a panel specific variant.
This allows to select a different panel, power off, connect the different panel and reboot. This will of course not become the long-term standard for a complete Pyra device but is very helpful in the current phase of HW development.
In summary I would prefer to get help for the gta04-kernel to be tested and stabilized instead of complaining that it is not good and others are much better.
BR, Nikolaus
PS: I have tested eSATA and it works for me (as a secondary drive besides the uSD). I do not yet know if we can boot from eSATA.
On 01/10/2015 02:11 PM, Dr. H. Nikolaus Schaller wrote:
Hi, I have seen there has been a recent discussion on IRC:
<aTc> yeah, im compiling a kernel <aTc> and it failed <aTc> what a surprise
why did you expect that?
since the last few kernels had the same problem.
what do you mean with “reliable”?
That it "just works".
Another problem is that your kernel seems very unstable. (for 3.18.0, and 3.19-rc3 as well) Most obvious problems were random segfaults when using xorg (almost immediately), and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine) Using the exact same version (and using the same compiler) of the other kernel, and everything was rock solid.
It also isn't very clear which kernel is the one that's supposed to be used,and in what state it is. So I prefer to use one that's at least a bit "known good" than one where someone else is in the middle of fixing/adding things.
<aTc> which is what i use
So in summary, please give me a favour and ask me (e.g. by private mail or by inviting me to IRC or here on this list) before you spread FUD and question my reputation or the reliability of my work in public. Especially as it was quite some work to get it to the state where it already is.
I do have to keep up my grumpy reputation on irc, so i tend to make things sound a lot worse than they really are, which most people there are well aware of. Out of context it sounds a lot ruder than it was meant :) And it was mostly just a bit of background ranting while messing about with the stuff. Trying to dig up the source of the problem takes a lot more time and effort than quickly writing "blah, this doesn't work" on irc.
Compiling should go the following:
checkout 3.19-rc3 use gta04_defconfig copy omap5-pyra*.dtb on the boot partition copy modules to the rootfs partition
You can even beta-test a very new tool:
http://projects.goldelico.com/p/gta04-makesd/
run ./makesd pyra -k http://url-for-your/uImage -d http://url-for-your/device-tree.tbz
Handling different panels connected to the EVM it is a little tricky. There is a panelselect script in GTA04/root which can be installed on the Pyra rootfs and allows to overwrite the default omap5-pyra.dtb by a panel specific variant.
This allows to select a different panel, power off, connect the different panel and reboot. This will of course not become the long-term standard for a complete Pyra device but is very helpful in the current phase of HW development.
Which one do you recommend for using with the plain devboard with hdmi output. omap5-uevm seemed to work best, fb0 doesn't show up when using omap5-pyra
Do you use any special kernel cmdline ?
In summary I would prefer to get help for the gta04-kernel to be tested and stabilized instead of complaining that it is not good and others are much better.
I'm not that great with kernels, and certainly not at devicetrees, where , unfortunately, most of the major problems seem to come from.
BR, Nikolaus
PS: I have tested eSATA and it works for me (as a secondary drive besides the uSD). I do not yet know if we can boot from eSATA.
Works fine, but does need "SCSI disk support" and "TI PIPE3 PHY Driver " compiled in, instead of the module your config is currently set to.
Hi,
Am 10.01.2015 um 23:48 schrieb aTc atc@k-n-p.org:
On 01/10/2015 02:11 PM, Dr. H. Nikolaus Schaller wrote:
Hi, I have seen there has been a recent discussion on IRC:
<aTc> yeah, im compiling a kernel <aTc> and it failed <aTc> what a surprise
why did you expect that?
since the last few kernels had the same problem.
Hm. The compile problem (missing files)? It was introduced not long ago. I think not earlier than december.
what do you mean with “reliable”?
That it “just works".
Well, that also depends on the environment you have. One kernel “just works” on a naked EVM while it does not handle any of the Pyra hardware extensions. The other other one might not work without the correct hardware attached because the DT is not always capable of doing a fallback.
Another problem is that your kernel seems very unstable.
I run it quite long without any problems.
(for 3.18.0, and 3.19-rc3 as well) Most obvious problems were random segfaults when using xorg (almost immediately)
I have traced this issue to the missing hardware on your EVM.
The kernel assumes that you have a LCD panel connected which is selected by the /root/panelselect script.
If the kernel is booted without running panelselect it disables the LCD - and that makes the omapfb fail to create /dev/fb0.
Therfore you get these symptoms: * Xorg can’t start * no HDMI
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
, and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine)
Please test the latest 3.19-rc3 if it still makes any compile problems.
Using the exact same version (and using the same compiler) of the other kernel, and everything was rock solid.
Maybe, because testers tell the developer their test results :)
And, they may have much more testers than we (I am the only one who is currently testing the gta04-kernel on OMAP5).
Finding bugs is proportional to the number of people looking for them… So if I am the only one it strongly depends on what I am doing.
It also isn’t very clear which kernel is the one that's supposed to be used,and in what state it is.
Yes, this isn’t clear indeed.
Let’s say it this way: it depends on what you want.
If you want a rock solid kernel with a lot of missing functions: use kernel.org If you want a kernel with more functions (but not related to the Pyra-hardware): use any more advanced kernel than kernel.org If you want to operate the Pyra-Hardware (which will be built in the next weeks), use the latest 3.19-rc from the gta04-kernel. It will support all features but might run into yet unknown bugs.
What we generally have not yet agreed on is how to do the production kernel.
On one side gta04-kernel has added a lot of missing features on top of linus/master and we are constantly pushing things upstream (but maybe with a delay of 6-12 months) so that in the long run (2-3 years?) maybe everything is in linus/master. So we do no longer need our own kernel project to support some hardware.
And, I use this gta04-kernel to accompany the hardware development. Adding a chip to hardware means that it must be possible to test it. And testing is done by adding/fixing drivers. And voilà, we have the driver we need. So it is impossible to test and develop hardware without writing the drivers. And of course they are not in any of the other kernels available (even if they look more stable).
To simplify working on several hardware projects, we at Goldelico have a single unified gta04-kernel for all hardware platforms because we simply can’t manage having multiple kernels for different boards. It was a nightmare to try this… Hence the big collection of device tree files (the ones not for the current board are simply ignored by u-boot).
Unfortunately the 3.19-rc is still not complete enough for all boards to make them the master branch.
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
So I prefer to use one that’s at least a bit "known good" than one where someone else is in the middle of fixing/adding things.
The 3.19-rc3 is know to be 99% good.
<aTc> which is what i use
So in summary, please give me a favour and ask me (e.g. by private mail or by inviting me to IRC or here on this list) before you spread FUD and question my reputation or the reliability of my work in public. Especially as it was quite some work to get it to the state where it already is.
I do have to keep up my grumpy reputation on irc, so i tend to make things sound a lot worse than they really are, which most people there are well aware of. Out of context it sounds a lot ruder than it was meant :)
Ok! I understand. I rarely look into IRC so I wasn’t aware of that context.
And it was mostly just a bit of background ranting while messing about with the stuff. Trying to dig up the source of the problem takes a lot more time and effort than quickly writing “blah, this doesn't work" on irc.
Yes, sigh. I know how difficult it is to work with someone else’s things. Last week I was almost throwing all Linux stuff against a wall… But then I found some deeply hidden hint in the source code how to solve the issue.
Compiling should go the following:
checkout 3.19-rc3 use gta04_defconfig copy omap5-pyra*.dtb on the boot partition copy modules to the rootfs partition
You can even beta-test a very new tool:
http://projects.goldelico.com/p/gta04-makesd/
run ./makesd pyra -k http://url-for-your/uImage -d http://url-for-your/device-tree.tbz
Handling different panels connected to the EVM it is a little tricky. There is a panelselect script in GTA04/root which can be installed on the Pyra rootfs and allows to overwrite the default omap5-pyra.dtb by a panel specific variant.
This allows to select a different panel, power off, connect the different panel and reboot. This will of course not become the long-term standard for a complete Pyra device but is very helpful in the current phase of HW development.
Which one do you recommend for using with the plain devboard with hdmi output. omap5-uevm seemed to work best, fb0 doesn’t show up when using omap5-pyra
Do you use any special kernel cmdline ?
The command line is this:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=GTA04/bootargs.txt;hb=...
and my boot script:
http://download.goldelico.com/gta04-u-boot/unstable/pyra/src/boot.txt
but all the mux, vram, cma, mpurate, omapfb things are no longer needed and are there only to keep the kernel compatible to a multitude of different systems.
In summary I would prefer to get help for the gta04-kernel to be tested and stabilized instead of complaining that it is not good and others are much better.
I’m not that great with kernels, and certainly not at devicetrees, where , unfortunately, most of the major problems seem to come from.
Well, it appears to be the LCD config entry of the device tree, i.e. that by default a non-existing lcd panel driver is configured.
Anyways, I have added another panel driver for MIPI testing and made it the default driver. So that you should always get /dev/fb*
And I have tested that it compiles with make clean.
Please test with HDMI (I have no good HDMI screen to do such tests - mine is incompatible to approx. 50% of the HDMI sources).
BR, Nikolaus
PS: I have tested eSATA and it works for me (as a secondary drive besides the uSD). I do not yet know if we can boot from eSATA.
Works fine, but does need “SCSI disk support” and "TI PIPE3 PHY Driver " compiled in, instead of the module your config is currently set to.
Ok, that is necessary, if we want to boot from eSATA (only). I boot from SD (only) and other boards supported by the gta04-kernel have no SATA) - therefore I did not notice.
The other reason I haven’t compiled it in is to keep the kernel binary small and load only what is urgently needed by the system to come to a console prompt .
But in this case it is reasonable to make it compiled into the kernel.
Should we change it for the gta04_default config?
BR, Nikolaus
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
Not really, we saw this at least both with Xorg from debian stable and testing (whatever version was in testing around summer 2014). The workaround is to recompile Xorg with ARM instructions only (thumb2 disabled) without any source code changes.
, and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine)
This might actually be the same problem as with Xorg, I think I saw it once too. I suspect mainline kernels might be missing some errata workarounds for the (very) early revision of Cortex-A15 that's in OMAP5. Attempting to debug the Xorg problem showed "impossible" situation so it looks something hardware related (misconfigured hardware or missing workarounds for hardware bugs).
Please test the latest 3.19-rc3 if it still makes any compile problems.
Yeah it would be good to know if mainline is still affected, I saw multiple fixes that affect OMAP5 (like disabling deeper power save modes as they are broken in OMAP5 hardware).
...
Let’s say it this way: it depends on what you want.
If you want a rock solid kernel with a lot of missing functions: use kernel.org
Unfortunately this is often only true for x86 and maybe for something like PowerPC, mainline tends to be broken on other platforms.. Although the situation might be improving, the ARM maintainers now have a huge farm of test boards (which fortunately includes OMAP5), so boards are at least tested to boot nowadays.
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
Yeah, we'll want overclocking at least, which is forbidden in mainline. We'll also want hardware virtualization support, which needs PAE enabled in kernel, and PAE kernels can only run on Cortex-A15 or newer, which means one-uImage-for-everyone is not possible here.
Gražvydas
Hi,
Am 12.01.2015 um 13:13 schrieb Grazvydas Ignotas notasas@gmail.com:
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
Not really, we saw this at least both with Xorg from debian stable and testing (whatever version was in testing around summer 2014). The workaround is to recompile Xorg with ARM instructions only (thumb2 disabled) without any source code changes.
, and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine)
This might actually be the same problem as with Xorg, I think I saw it once too. I suspect mainline kernels might be missing some errata workarounds for the (very) early revision of Cortex-A15 that's in OMAP5. Attempting to debug the Xorg problem showed "impossible" situation so it looks something hardware related (misconfigured hardware or missing workarounds for hardware bugs).
Please test the latest 3.19-rc3 if it still makes any compile problems.
Yeah it would be good to know if mainline is still affected, I saw multiple fixes that affect OMAP5 (like disabling deeper power save modes as they are broken in OMAP5 hardware).
...
Let’s say it this way: it depends on what you want.
If you want a rock solid kernel with a lot of missing functions: use kernel.org
Unfortunately this is often only true for x86 and maybe for something like PowerPC, mainline tends to be broken on other platforms.. Although the situation might be improving, the ARM maintainers now have a huge farm of test boards (which fortunately includes OMAP5), so boards are at least tested to boot nowadays.
Interestingly the number of patches for ARM has heavily reduced since 3.17. So I think people have stabilized a lot of basics and might be working on fine-tuning.
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
Yeah, we'll want overclocking at least, which is forbidden in mainline. We'll also want hardware virtualization support, which needs PAE enabled in kernel, and PAE kernels can only run on Cortex-A15 or newer, which means one-uImage-for-everyone is not possible here.
Ok, but if I understand the recent development directions correctly, both might be reduced to a modified (overlaid) device tree and a modified kernel config and I would hope that in the future PAE is ignored by pre-A15 CPUs (if not defined by DT).
But I am not a specialist of either topic (I even thought that PAE is only for x86 but learned about CONFIG_ARM_LPAE).
BR, Nikolaus
On 01/12/2015 06:49 PM, Dr. H. Nikolaus Schaller wrote:
Hi,
Am 12.01.2015 um 13:13 schrieb Grazvydas Ignotas notasas@gmail.com:
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
Yeah, we'll want overclocking at least, which is forbidden in mainline. We'll also want hardware virtualization support, which needs PAE enabled in kernel, and PAE kernels can only run on Cortex-A15 or newer, which means one-uImage-for-everyone is not possible here.
Ok, but if I understand the recent development directions correctly, both might be reduced to a modified (overlaid) device tree and a modified kernel config and I would hope that in the future PAE is ignored by pre-A15 CPUs (if not defined by DT).
But I am not a specialist of either topic (I even thought that PAE is only for x86 but learned about CONFIG_ARM_LPAE).
Right, it's LPAE on ARM. With this setting ARM CPU is switched to different mode that uses page tables in completely different format from classic ARM. Linux memory management subsystem is deeply tied into page table format, and different page table format support is implemented using multiple levels of macros, so there is currently no way to support both with single binary. Theoretically it may possible to implement multiple format support in single binary, but I don't think it will ever happen in practice (it hasn't happened for IA32 either and distributions offer separate kernels with PAE on and off).
Grazvydas
But I am not a specialist of either topic (I even thought that PAE is only for x86 but learned about CONFIG_ARM_LPAE).
Right, it's LPAE on ARM. With this setting ARM CPU is switched to different mode that uses page tables in completely different format from classic ARM. Linux memory management subsystem is deeply tied into page table format, and different page table format support is implemented using multiple levels of macros, so there is currently no way to support both with single binary. Theoretically it may possible to implement multiple format support in single binary, but I don't think it will ever happen in practice (it hasn't happened for IA32 either and distributions offer separate kernels with PAE on and off).
The other kernel I was using did have it enabled, could give that a try on the gta one as well.
On 01/12/2015 01:13 PM, Grazvydas Ignotas wrote:
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
Not really, we saw this at least both with Xorg from debian stable and testing (whatever version was in testing around summer 2014). The workaround is to recompile Xorg with ARM instructions only (thumb2 disabled) without any source code changes.
, and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine)
This might actually be the same problem as with Xorg, I think I saw it once too. I suspect mainline kernels might be missing some errata workarounds for the (very) early revision of Cortex-A15 that's in OMAP5. Attempting to debug the Xorg problem showed "impossible" situation so it looks something hardware related (misconfigured hardware or missing workarounds for hardware bugs).
Please test the latest 3.19-rc3 if it still makes any compile problems.
Yeah it would be good to know if mainline is still affected, I saw multiple fixes that affect OMAP5 (like disabling deeper power save modes as they are broken in OMAP5 hardware).
Thing is, using the https://github.com/RobertCNelson/armv7-lpae-multiplatform 3.18 kernel, things are a lot more stable with the plain debian xorg. So they might have some patches/config settings in there that may point to the real source of the problem.
The gta04 kernel is very unstable with the debian xorg, but very solid with the patched (compiled with -marm) one. Im not entirely sure if it's just the kernel, since I did have the ocasional xorg problem with it, but that might have been just me messing about. I've never seen a kernel compile fail with theirs though.
I just tried a kernel compile on the gta 3.19.0-rc3, and kernel compiling failed with the usual
Makefile:1098: recipe for target 'modules' failed make: *** [modules] Segmentation fault make: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!
Place it happens is pretty random of course, but it's very rare that it'll go through the entire compile in one go. Compiling with only 1 thread does seem to make it more stable, but I haven't done any serious tests with that.
The kernel compiling also fails when the patched xorg is running.
...
Let’s say it this way: it depends on what you want.
If you want a rock solid kernel with a lot of missing functions: use kernel.org
Unfortunately this is often only true for x86 and maybe for something like PowerPC, mainline tends to be broken on other platforms.. Although the situation might be improving, the ARM maintainers now have a huge farm of test boards (which fortunately includes OMAP5), so boards are at least tested to boot nowadays.
It's a lot worse than that, even the TI official kernels for the board have a lot of missing features, and are very picky about which compiler they're compiled with.
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
Yeah, we'll want overclocking at least, which is forbidden in mainline. We'll also want hardware virtualization support, which needs PAE enabled in kernel, and PAE kernels can only run on Cortex-A15 or newer, which means one-uImage-for-everyone is not possible here.
We might also need aufs patched in. The current dbp system relies on aufs, and some aufs features might have some problems moving to overlayfs easily. Of course it's still very early stages for that, so overlayfs could still be a possibility. Issue is mostly that overlayfs only became available in mainline kernels very recently, so slaeshjag couldn't really test it.
Hi there,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
On 01/12/2015 01:13 PM, Grazvydas Ignotas wrote:
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
Not really, we saw this at least both with Xorg from debian stable and testing (whatever version was in testing around summer 2014). The workaround is to recompile Xorg with ARM instructions only (thumb2 disabled) without any source code changes.
, and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine)
This might actually be the same problem as with Xorg, I think I saw it once too. I suspect mainline kernels might be missing some errata workarounds for the (very) early revision of Cortex-A15 that's in OMAP5. Attempting to debug the Xorg problem showed "impossible" situation so it looks something hardware related (misconfigured hardware or missing workarounds for hardware bugs).
Please test the latest 3.19-rc3 if it still makes any compile problems.
Yeah it would be good to know if mainline is still affected, I saw multiple fixes that affect OMAP5 (like disabling deeper power save modes as they are broken in OMAP5 hardware).
Thing is, using the https://github.com/RobertCNelson/armv7-lpae-multiplatform 3.18 kernel, things are a lot more stable with the plain debian xorg. So they might have some patches/config settings in there that may point to the real source of the problem.
Indeed. I suspect that something in the omapfb is different and the plain debian xorg (assuming to be built against kernel 3.2 headers!) is not aware of that. We have one patch in our code so that it provides a “name” entry somewhere in the /sys nodes. Otherwise the stable xorg wouldn’t find anything.
The gta04 kernel is very unstable
please provide bug reports. dmesg traces, other symptoms, error messages etc.
“very unstable” does not help anyone to fix anything. Precise bug reports do :)
with the debian xorg, but very solid with the patched (compiled with -marm) one. Im not entirely sure if it's just the kernel, since I did have the ocasional xorg problem with it, but that might have been just me messing about. I’ve never seen a kernel compile fail with theirs though.
I guess it is a mix between both. Some combinations work and others may have some uninitialized variable or dangling pointer or alignment assumption or whatever is triggering problems.
I just tried a kernel compile on the gta 3.19.0-rc3, and kernel compiling failed with the usual
Makefile:1098: recipe for target 'modules' failed make: *** [modules] Segmentation fault make: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!
Is this from the compiler? Which compiler are you using? On which machine are you compiling?
We have not added any code to trigger a segfault in the make command :)
Place it happens is pretty random of course, but it's very rare that it'll go through the entire compile in one go. Compiling with only 1 thread does seem to make it more stable, but I haven't done any serious tests with that.
The kernel compiling also fails when the patched xorg is running.
Ah, you are compiling on the EVM as a stress test? So I probably should set up this as well. It is just a git clone away…
I am cross-compiling and did never see that problem during compile or during operation of the EVM. Maybe we should compare uImage binaries? At least the file size. Plain diff fails because the compile date is included somewhere and also makes the CRC differ.
...
Let’s say it this way: it depends on what you want.
If you want a rock solid kernel with a lot of missing functions: use kernel.org
Unfortunately this is often only true for x86 and maybe for something like PowerPC, mainline tends to be broken on other platforms.. Although the situation might be improving, the ARM maintainers now have a huge farm of test boards (which fortunately includes OMAP5), so boards are at least tested to boot nowadays.
It’s a lot worse than that, even the TI official kernels for the board have a lot of missing features, and are very picky about which compiler they're compiled with.
That is why I don’t use the TI kernels any more. I think the strategy used with the gta04-kernel is the best we can get (which is still suboptimal of course). We get latest official developments, I can write drivers as soon as hardware becomes available without fighting with incompatible changes of anyone else, and we have a chance to get our things upstream.
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
Yeah, we'll want overclocking at least, which is forbidden in mainline. We'll also want hardware virtualization support, which needs PAE enabled in kernel, and PAE kernels can only run on Cortex-A15 or newer, which means one-uImage-for-everyone is not possible here.
We might also need aufs patched in. The current dbp system relies on aufs, and some aufs features might have some problems moving to overlayfs easily. Of course it's still very early stages for that, so overlayfs could still be a possibility. Issue is mostly that overlayfs only became available in mainline kernels very recently, so slaeshjag couldn’t really test it.
Yes, overlayfs is promising and might be the better choice (because it is likely to be maintained). But we will probably run through a learning curve.
BR, Nikolaus
On 01/12/2015 07:19 PM, Dr. H. Nikolaus Schaller wrote:
Hi there,
Indeed. I suspect that something in the omapfb is different and the plain debian xorg (assuming to be built against kernel 3.2 headers!) is not aware of that. We have one patch in our code so that it provides a “name” entry somewhere in the /sys nodes. Otherwise the stable xorg wouldn’t find anything.
Almost forgot, with the gta kernel i get these: [ 14.577329] omapfb omapfb: Unknown ioctl 0x40187a22 [ 14.582500] omapfb omapfb: Unknown ioctl 0x40187a21
And they don't appear with the other kernel. I think it's just fbturbo probing around for stuff though.
The gta04 kernel is very unstable
please provide bug reports. dmesg traces, other symptoms, error messages etc.
“very unstable” does not help anyone to fix anything. Precise bug reports do :)
I would if i got any more output from things, but dmesg stays empty. I'll need to check if the stuff ends up somewhere else.
Ah, you are compiling on the EVM as a stress test? So I probably should set up this as well. It is just a git clone away…
I do most work on the board itself,not just as a stress test. Best way to run into problems is to just use it for as many different things as possible.
So the "make" segfaulting doesn't happen when crosscompiling :)
I am cross-compiling and did never see that problem during compile or during operation of the EVM. Maybe we should compare uImage binaries? At least the file size. Plain diff fails because the compile date is included somewhere and also makes the CRC differ.
I boot mine using the zImage, I'll need to recompile the kernel to get a uImage out of it, since i messed things up slightly trying to patch the 3.18 aufs into a 3.19 kernel :)
3.19.0-rc3-gta04 4282264 Jan 11 20:33 zImage
gcc (Debian 4.9.1-19) 4.9.1
I also used that to compile the other kernels.
Am 12.01.2015 um 20:01 schrieb aTc atc@k-n-p.org:
On 01/12/2015 07:19 PM, Dr. H. Nikolaus Schaller wrote:
Hi there,
Indeed. I suspect that something in the omapfb is different and the plain debian xorg (assuming to be built against kernel 3.2 headers!) is not aware of that. We have one patch in our code so that it provides a “name” entry somewhere in the /sys nodes. Otherwise the stable xorg wouldn’t find anything.
Almost forgot, with the gta kernel i get these: [ 14.577329] omapfb omapfb: Unknown ioctl 0x40187a22 [ 14.582500] omapfb omapfb: Unknown ioctl 0x40187a21
And they don't appear with the other kernel. I think it’s just fbturbo probing around for stuff though.
I think there are fbdev configure options - and we might be missing some.
The gta04 kernel is very unstable
please provide bug reports. dmesg traces, other symptoms, error messages etc.
“very unstable” does not help anyone to fix anything. Precise bug reports do :)
I would if i got any more output from things, but dmesg stays empty.
Hm. But what is the symptom?
I'll need to check if the stuff ends up somewhere else.
Ah, you are compiling on the EVM as a stress test? So I probably should set up this as well. It is just a git clone away…
I do most work on the board itself,not just as a stress test. Best way to run into problems is to just use it for as many different things as possible.
So the “make" segfaulting doesn't happen when crosscompiling :)
Yes, basically this is a very good strategy.
I am cross-compiling and did never see that problem during compile or during operation of the EVM. Maybe we should compare uImage binaries? At least the file size. Plain diff fails because the compile date is included somewhere and also makes the CRC differ.
I boot mine using the zImage, I'll need to recompile the kernel to get a uImage out of it, since i messed things up slightly trying to patch the 3.18 aufs into a 3.19 kernel :)
3.19.0-rc3-gta04 4282264 Jan 11 20:33 zImage
gcc (Debian 4.9.1-19) 4.9.1
I also used that to compile the other kernels.
Ok. I cross-compile with some gcc 4.5 I have built 3 years ago and never touched since…
BR, Nikolaus
Am 12.01.2015 um 20:14 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Am 12.01.2015 um 20:01 schrieb aTc atc@k-n-p.org:
On 01/12/2015 07:19 PM, Dr. H. Nikolaus Schaller wrote:
Hi there,
Indeed. I suspect that something in the omapfb is different and the plain debian xorg (assuming to be built against kernel 3.2 headers!) is not aware of that. We have one patch in our code so that it provides a “name” entry somewhere in the /sys nodes. Otherwise the stable xorg wouldn’t find anything.
Almost forgot, with the gta kernel i get these: [ 14.577329] omapfb omapfb: Unknown ioctl 0x40187a22 [ 14.582500] omapfb omapfb: Unknown ioctl 0x40187a21
And they don't appear with the other kernel. I think it’s just fbturbo probing around for stuff though.
I think there are fbdev configure options - and we might be missing some.
I mean these:
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set
Xorg might check for their presence. Can you check with your other kernel(s) how they are defined?
The gta04 kernel is very unstable
please provide bug reports. dmesg traces, other symptoms, error messages etc.
“very unstable” does not help anyone to fix anything. Precise bug reports do :)
I would if i got any more output from things, but dmesg stays empty.
Hm. But what is the symptom?
I'll need to check if the stuff ends up somewhere else.
Ah, you are compiling on the EVM as a stress test? So I probably should set up this as well. It is just a git clone away…
I do most work on the board itself,not just as a stress test. Best way to run into problems is to just use it for as many different things as possible.
So the “make" segfaulting doesn't happen when crosscompiling :)
Yes, basically this is a very good strategy.
I am cross-compiling and did never see that problem during compile or during operation of the EVM. Maybe we should compare uImage binaries? At least the file size. Plain diff fails because the compile date is included somewhere and also makes the CRC differ.
I boot mine using the zImage, I'll need to recompile the kernel to get a uImage out of it, since i messed things up slightly trying to patch the 3.18 aufs into a 3.19 kernel :)
3.19.0-rc3-gta04 4282264 Jan 11 20:33 zImage
gcc (Debian 4.9.1-19) 4.9.1
I also used that to compile the other kernels.
Ok. I cross-compile with some gcc 4.5 I have built 3 years ago and never touched since…
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 01/12/2015 09:55 PM, Dr. H. Nikolaus Schaller wrote:
Am 12.01.2015 um 20:14 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Am 12.01.2015 um 20:01 schrieb aTc atc@k-n-p.org:
On 01/12/2015 07:19 PM, Dr. H. Nikolaus Schaller wrote:
Hi there,
Indeed. I suspect that something in the omapfb is different and the plain debian xorg (assuming to be built against kernel 3.2 headers!) is not aware of that. We have one patch in our code so that it provides a “name” entry somewhere in the /sys nodes. Otherwise the stable xorg wouldn’t find anything.
Almost forgot, with the gta kernel i get these: [ 14.577329] omapfb omapfb: Unknown ioctl 0x40187a22 [ 14.582500] omapfb omapfb: Unknown ioctl 0x40187a21
And they don't appear with the other kernel. I think it’s just fbturbo probing around for stuff though.
I think there are fbdev configure options - and we might be missing some.
I mean these:
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set
Xorg might check for their presence. Can you check with your other kernel(s) how they are defined?
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set
I'll see if it makes any difference with those options enabled.
On 2015-01-12, Dr. H. Nikolaus Schaller wrote:
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
On 01/12/2015 01:13 PM, Grazvydas Ignotas wrote:
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
Not really, we saw this at least both with Xorg from debian stable and testing (whatever version was in testing around summer 2014). The workaround is to recompile Xorg with ARM instructions only (thumb2 disabled) without any source code changes.
...
https://github.com/RobertCNelson/armv7-lpae-multiplatform 3.18 kernel, things are a lot more stable with the plain debian xorg. So they might have some patches/config settings in there that may point to the real source of the problem.
Indeed. I suspect that something in the omapfb is different and the plain debian xorg (assuming to be built against kernel 3.2 headers!) is not aware of that.
The corresponding xorg-server package version built in Debian was built with linux-libc-dev 3.14.15-2 headers (which is the package that includes the kernel headers):
https://buildd.debian.org/status/fetch.php?pkg=xorg-server&arch=armhf&am...
More recent versions are built against linux-libc-dev 3.16.5-1, FWIW. So I don't think it's an issue with building against the wrong kernel headers.
If disabling thumb2 causes it to work, it seems worth reporting a bug to Debian, and CCing debian-arm@lists.debian.org. I don't have the hardware to test and reproduce the issue, otherwise I'd report it myself...
There's another bug that reports crashes with a touchpad on an am3354, but doesn't include any workaround to fix the issue:
https://bugs.debian.org/760878
live well, vagrant
Hi,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
On 01/12/2015 01:13 PM, Grazvydas Ignotas wrote:
On Sun, Jan 11, 2015 at 2:18 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
And I see a long time known problem with Xorg that it might segfault if the touch/mouse is moved rapidly. This was traced back to an older Xorg. Notaz did recompile it and ED could use it for demos.
Not really, we saw this at least both with Xorg from debian stable and testing (whatever version was in testing around summer 2014). The workaround is to recompile Xorg with ARM instructions only (thumb2 disabled) without any source code changes.
, and make when compiling a kernel (takes a while to show up there, but when resuming the compile everything works fine)
This might actually be the same problem as with Xorg, I think I saw it once too. I suspect mainline kernels might be missing some errata workarounds for the (very) early revision of Cortex-A15 that's in OMAP5. Attempting to debug the Xorg problem showed "impossible" situation so it looks something hardware related (misconfigured hardware or missing workarounds for hardware bugs).
Please test the latest 3.19-rc3 if it still makes any compile problems.
Yeah it would be good to know if mainline is still affected, I saw multiple fixes that affect OMAP5 (like disabling deeper power save modes as they are broken in OMAP5 hardware).
Thing is, using the https://github.com/RobertCNelson/armv7-lpae-multiplatform 3.18 kernel, things are a lot more stable with the plain debian xorg. So they might have some patches/config settings in there that may point to the real source of the problem.
The gta04 kernel is very unstable with the debian xorg, but very solid with the patched (compiled with -marm) one. Im not entirely sure if it's just the kernel, since I did have the ocasional xorg problem with it, but that might have been just me messing about. I've never seen a kernel compile fail with theirs though.
I just tried a kernel compile on the gta 3.19.0-rc3, and kernel compiling failed with the usual
Makefile:1098: recipe for target 'modules' failed make: *** [modules] Segmentation fault make: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!
Place it happens is pretty random of course, but it's very rare that it'll go through the entire compile in one go. Compiling with only 1 thread does seem to make it more stable, but I haven't done any serious tests with that.
The kernel compiling also fails when the patched xorg is running.
I did the following: * boot EVM from my 8GB SD card * with BOE panel attached and installed * showing LXDE desktop
Here the commands (edited from bash history):
155 apt-get install git 156 git clone http://git.goldelico.com/gta04-kernel.git 159 cd gta04-kernel/ 162 git checkout 3.19-rc4 163 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14) 165 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules /bin/sh: 1: bc: not found make[3]: *** [kernel/time/timeconst.h] Error 127 make[2]: *** [kernel/time] Error 2 make[1]: *** [kernel] Error 2 make: *** [__build_one_by_one] Error 2
real 7m38.197s user 4m13.890s sys 0m33.050s
166 apt-get install bc 169 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules
here would be the standard compile log. Nothing significant, except that I have seen at least 4 [-Wuninitialized] likethis:
ipc/shm.c:1310:59: warning: ‘file’ may be used uninitialized in this function [-Wuninitialized]
real 72m29.449s user 42m58.220s sys 5m2.280s root@gta04:~/gta04-kernel# ls -l arch/arm/boot total 17312 drwxr-xr-x 2 root root 4096 Jan 12 21:18 bootp drwxr-xr-x 2 root root 4096 Jan 13 06:20 compressed drwxr-xr-x 3 root root 69632 Jan 13 06:20 dts -rwxr-xr-x 1 root root 9062600 Jan 13 06:20 Image -rw-r--r-- 1 root root 1648 Jan 12 20:09 install.sh -rw-r--r-- 1 root root 3148 Jan 12 20:09 Makefile -rw-r--r-- 1 root root 4265464 Jan 13 06:20 uImage -rwxr-xr-x 1 root root 4265400 Jan 13 06:20 zImage root@gta04:~/gta04-kernel# ls -l /boot/uImage -rwxr-xr-x 1 root root 4322896 Jan 12 16:03 /boot/uImage root@gta04:~/gta04-kernel# uname -a Linux gta04 3.19.0-rc4-gta04+ #958 SMP Mon Jan 12 11:33:17 CET 2015 armv7l GNU/Linux root@gta04:~/gta04-kernel# cat /etc/debian_version 7.7
So it works and is stable (on Wheezy 7.7). I just had to install ‘bc’.
Compiling the kernel needs ~60 Minutes on a class 10 SD card and fills it to ~75%.
Interestingly, the binary is a little smaller than my cross-compiled one.
But I also see ca. 4 [-Wuninitialized] warnings.
One of them in ipc/shm and I think Xorg is using shared memory for communication?
I have also copied the new kernel into /boot and installed the new dtb and modules, rebooted and have not yet seen any difference.
I was even able to make clean and compile the kernel again using the newly compiled one.
So to summarize: on my EVM (with Pyra development hardware) it works and is stable (except the known Xorg segfault if the mouse is moved rapidly).
I must admit that I have no idea where your make-segfault problems are coming from.
Some random thoughts what might differ between your and my setup: * system library linked by make * a bug in gcc * one of the uninitialized things in the kernel * some dangling pointer elsewhere * a hardware difference of the boards (which might depend on clock frequency settings by different kernels so that I would not say the gta04-kernel is unstable but it reveals some other instability)
BR, Nikolaus
...
Let’s say it this way: it depends on what you want.
If you want a rock solid kernel with a lot of missing functions: use kernel.org
Unfortunately this is often only true for x86 and maybe for something like PowerPC, mainline tends to be broken on other platforms.. Although the situation might be improving, the ARM maintainers now have a huge farm of test boards (which fortunately includes OMAP5), so boards are at least tested to boot nowadays.
It's a lot worse than that, even the TI official kernels for the board have a lot of missing features, and are very picky about which compiler they're compiled with.
On the other side I think Notaz wants to do optimizations that never will be accepted by linus/master. So this still needs a separate tree.
Yeah, we'll want overclocking at least, which is forbidden in mainline. We'll also want hardware virtualization support, which needs PAE enabled in kernel, and PAE kernels can only run on Cortex-A15 or newer, which means one-uImage-for-everyone is not possible here.
We might also need aufs patched in. The current dbp system relies on aufs, and some aufs features might have some problems moving to overlayfs easily. Of course it's still very early stages for that, so overlayfs could still be a possibility. Issue is mostly that overlayfs only became available in mainline kernels very recently, so slaeshjag couldn't really test it.
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Tue, Jan 13, 2015 at 11:32 AM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
The kernel compiling also fails when the patched xorg is running.
I did the following:
- boot EVM from my 8GB SD card
- with BOE panel attached and installed
- showing LXDE desktop
Here the commands (edited from bash history):
155 apt-get install git 156 git clone http://git.goldelico.com/gta04-kernel.git 159 cd gta04-kernel/ 162 git checkout 3.19-rc4 163 gcc -v Using built-in specs. ...
166 apt-get install bc 169 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules
...
So it works and is stable (on Wheezy 7.7). I just had to install ‘bc’.
You need to use "make -j3 ..." for make to keep running 3 jobs (1 for each ARM core and one to take a free core that's waiting for SD card when it's reading new source files). Then problems tend to show up, some time ago I've tried doing this on internal eMMC and it corrupted the filesystem (this might be unrelated eMMC driver problem and was on TI kernel I think, so probably unrelated to currently discussed issues).
Gražvydas
Am 13.01.2015 um 14:46 schrieb Grazvydas Ignotas notasas@gmail.com:
On Tue, Jan 13, 2015 at 11:32 AM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
The kernel compiling also fails when the patched xorg is running.
I did the following:
- boot EVM from my 8GB SD card
- with BOE panel attached and installed
- showing LXDE desktop
Here the commands (edited from bash history):
155 apt-get install git 156 git clone http://git.goldelico.com/gta04-kernel.git 159 cd gta04-kernel/ 162 git checkout 3.19-rc4 163 gcc -v Using built-in specs. ...
166 apt-get install bc 169 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules
...
So it works and is stable (on Wheezy 7.7). I just had to install ‘bc’.
You need to use "make -j3 ..." for make to keep running 3 jobs (1 for each ARM core and one to take a free core that's waiting for SD card when it's reading new source files). Then problems tend to show up, some time ago I've tried doing this on internal eMMC and it corrupted the filesystem (this might be unrelated eMMC driver problem and was on TI kernel I think, so probably unrelated to currently discussed issues).
Ok, I will test.
Gražvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 13.01.2015 um 14:46 schrieb Grazvydas Ignotas notasas@gmail.com:
On Tue, Jan 13, 2015 at 11:32 AM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
The kernel compiling also fails when the patched xorg is running.
I did the following:
- boot EVM from my 8GB SD card
- with BOE panel attached and installed
- showing LXDE desktop
Here the commands (edited from bash history):
155 apt-get install git 156 git clone http://git.goldelico.com/gta04-kernel.git 159 cd gta04-kernel/ 162 git checkout 3.19-rc4 163 gcc -v Using built-in specs. ...
166 apt-get install bc 169 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules
...
So it works and is stable (on Wheezy 7.7). I just had to install ‘bc’.
You need to use "make -j3 ..." for make to keep running 3 jobs (1 for each ARM core and one to take a free core that's waiting for SD card when it's reading new source files). Then problems tend to show up, some time ago I've tried doing this on internal eMMC and it corrupted the filesystem (this might be unrelated eMMC driver problem and was on TI kernel I think, so probably unrelated to currently discussed issues).
Still no segfault :(
root@gta04:~/gta04-kernel# make clean CLEAN . CLEAN arch/arm/kernel CLEAN drivers/tty/vt CLEAN drivers/video/logo CLEAN firmware CLEAN kernel/time CLEAN kernel CLEAN lib CLEAN usr CLEAN arch/arm/boot/compressed CLEAN arch/arm/boot/dts CLEAN arch/arm/boot CLEAN .tmp_versions root@gta04:~/gta04-kernel# time make -j3 gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/bin2c HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h HOSTCC scripts/dtc/dtc.o
…. (the order of compile steps is scrambled compared to make w/o -j3) …
LD [M] sound/soc/omap/snd-soc-omap-mcbsp.ko LD [M] sound/soc/omap/snd-soc-omap-mcpdm.ko HOSTCC firmware/ihex2fw IHEX2FW firmware/emi26/loader.fw IHEX2FW firmware/emi26/firmware.fw IHEX2FW firmware/emi26/bitstream.fw IHEX2FW firmware/emi62/loader.fw IHEX2FW firmware/emi62/bitstream.fw IHEX2FW firmware/emi62/spdif.fw IHEX2FW firmware/emi62/midi.fw
real 56m11.666s user 49m47.790s sys 6m5.240s root@gta04:~/gta04-kernel# ls -l arch/arm/boot/ total 17312 drwxr-xr-x 2 root root 4096 Jan 12 21:18 bootp drwxr-xr-x 2 root root 4096 Jan 13 14:31 compressed drwxr-xr-x 3 root root 69632 Jan 13 14:31 dts -rwxr-xr-x 1 root root 9062600 Jan 13 14:30 Image -rw-r--r-- 1 root root 1648 Jan 12 20:09 install.sh -rw-r--r-- 1 root root 3148 Jan 12 20:09 Makefile -rw-r--r-- 1 root root 4265456 Jan 13 14:31 uImage -rwxr-xr-x 1 root root 4265392 Jan 13 14:31 zImage
Only one thing was interesting. While the make was running, I tried cpufreq-info through a second ssh session:
root@gta04:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:82.99%, 1.50 GHz:17.01% (3376) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:82.99%, 1.50 GHz:17.01% (3376) root@gta04:~#
This shows that running the make isn’t driving the cores to max. speed. Most times they are at 1GZh- And I measured the temperature to be 45C which isn’t really hot.
Could it be that my SD card is slower than a SATA disk and the problem only appears if the CPUs are both permantently running at 1.5 GHz?
I could try connecting my only disk with eSATA connector… But it had some spindle startup problems so I don’t know if it really works well or introduces its own problem.
BR, Nikolaus
Hi, me again…
Am 13.01.2015 um 16:51 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Am 13.01.2015 um 14:46 schrieb Grazvydas Ignotas notasas@gmail.com:
On Tue, Jan 13, 2015 at 11:32 AM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
The kernel compiling also fails when the patched xorg is running.
I did the following:
- boot EVM from my 8GB SD card
- with BOE panel attached and installed
- showing LXDE desktop
Here the commands (edited from bash history):
155 apt-get install git 156 git clone http://git.goldelico.com/gta04-kernel.git 159 cd gta04-kernel/ 162 git checkout 3.19-rc4 163 gcc -v Using built-in specs. ...
166 apt-get install bc 169 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules
...
So it works and is stable (on Wheezy 7.7). I just had to install ‘bc’.
You need to use "make -j3 ..." for make to keep running 3 jobs (1 for each ARM core and one to take a free core that's waiting for SD card when it's reading new source files). Then problems tend to show up, some time ago I've tried doing this on internal eMMC and it corrupted the filesystem (this might be unrelated eMMC driver problem and was on TI kernel I think, so probably unrelated to currently discussed issues).
Still no segfault :(
root@gta04:~/gta04-kernel# make clean CLEAN . CLEAN arch/arm/kernel CLEAN drivers/tty/vt CLEAN drivers/video/logo CLEAN firmware CLEAN kernel/time CLEAN kernel CLEAN lib CLEAN usr CLEAN arch/arm/boot/compressed CLEAN arch/arm/boot/dts CLEAN arch/arm/boot CLEAN .tmp_versions root@gta04:~/gta04-kernel# time make -j3 gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/bin2c HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h HOSTCC scripts/dtc/dtc.o
…. (the order of compile steps is scrambled compared to make w/o -j3) …
LD [M] sound/soc/omap/snd-soc-omap-mcbsp.ko LD [M] sound/soc/omap/snd-soc-omap-mcpdm.ko HOSTCC firmware/ihex2fw IHEX2FW firmware/emi26/loader.fw IHEX2FW firmware/emi26/firmware.fw IHEX2FW firmware/emi26/bitstream.fw IHEX2FW firmware/emi62/loader.fw IHEX2FW firmware/emi62/bitstream.fw IHEX2FW firmware/emi62/spdif.fw IHEX2FW firmware/emi62/midi.fw
real 56m11.666s user 49m47.790s sys 6m5.240s root@gta04:~/gta04-kernel# ls -l arch/arm/boot/ total 17312 drwxr-xr-x 2 root root 4096 Jan 12 21:18 bootp drwxr-xr-x 2 root root 4096 Jan 13 14:31 compressed drwxr-xr-x 3 root root 69632 Jan 13 14:31 dts -rwxr-xr-x 1 root root 9062600 Jan 13 14:30 Image -rw-r--r-- 1 root root 1648 Jan 12 20:09 install.sh -rw-r--r-- 1 root root 3148 Jan 12 20:09 Makefile -rw-r--r-- 1 root root 4265456 Jan 13 14:31 uImage -rwxr-xr-x 1 root root 4265392 Jan 13 14:31 zImage
Only one thing was interesting. While the make was running, I tried cpufreq-info through a second ssh session:
root@gta04:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:82.99%, 1.50 GHz:17.01% (3376) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:82.99%, 1.50 GHz:17.01% (3376) root@gta04:~#
This shows that running the make isn’t driving the cores to max. speed. Most times they are at 1GZh- And I measured the temperature to be 45C which isn’t really hot.
Could it be that my SD card is slower than a SATA disk and the problem only appears if the CPUs are both permantently running at 1.5 GHz?
I could try connecting my only disk with eSATA connector… But it had some spindle startup problems so I don’t know if it really works well or introduces its own problem.
Yes, it did take 5 minutes with some clicking noises and flicker on the power supply LED but then it got to speed and did mount.
Here the result:
LD [M] sound/soc/omap/snd-soc-gta04-fm.ko LD [M] sound/soc/omap/snd-soc-gta04-headset.ko LD [M] sound/soc/omap/snd-soc-gta04-jack.ko LD [M] sound/soc/omap/snd-soc-gta04-voice.ko LD [M] sound/soc/omap/snd-soc-omap-abe-twl6040.ko LD [M] sound/soc/omap/snd-soc-omap-dmic.ko LD [M] sound/soc/omap/snd-soc-omap-mcbsp.ko LD [M] sound/soc/omap/snd-soc-omap-mcpdm.ko HOSTCC firmware/ihex2fw IHEX2FW firmware/emi26/loader.fw IHEX2FW firmware/emi26/firmware.fw IHEX2FW firmware/emi26/bitstream.fw IHEX2FW firmware/emi62/loader.fw IHEX2FW firmware/emi62/bitstream.fw IHEX2FW firmware/emi62/spdif.fw IHEX2FW firmware/emi62/midi.fw
real 29m51.179s user 49m0.820s sys 5m10.640s root@gta04:/media/usb0/gta04-kernel#
As you can see it is almost using 200%.
And:
root@gta04:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:26.41%, 1.50 GHz:73.59% (152) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:26.41%, 1.50 GHz:73.59% (152) root@gta04:~#
So much higher CPU utilization of both cores. And temperature did rise to ~55C (measured externally with infrared thermometer).
But still no segfault.
So I can only conclude that the gta04-kernel works stable - at least for me and my EVM setup and I have really no idea why it fails for you.
You may now understand why grumbling about gta04-kernel being very unstable didn’t find immediate positive reactions :)
What you could try is to boot with a copy of my kernel binary (pulled from the EVM using scp):
http://download.goldelico.com/gta04-kernel/unstable/pyra/Archiv.zip
What I don’t know exactly is if it boots without LCD panel.
BR, Nikolaus
So much higher CPU utilization of both cores. And temperature did rise to ~55C (measured externally with infrared thermometer).
Yeah, those sensors seems to have dissapeared since the 3.8 kernel too.
But still no segfault.
So I can only conclude that the gta04-kernel works stable - at least for me and my EVM setup and I have really no idea why it fails for you.
Using the same setup (omap5-pyra.dtb, rootfs on sd, kernel dir on sata) i had no problems either. Of course i have no working xorg with that setup.
using omap5-uevm and rootfs on sata, i do get segfaults again. Doesn't matter if xorg is running or not. So a place to look would be hdmi , or in the omap5-uevm.dts. I did notice quite a lot of overrides in omap5-pyra. so an omap5-pyra+hdmi would be nice (unless there's an easy way of switching the output).
gta 3.19.-rc3 with omapdrm compiled in didn't segfault, but i didn't get a working xorg with that either.
Am 14.01.2015 um 01:21 schrieb aTc atc@k-n-p.org:
So much higher CPU utilization of both cores. And temperature did rise to ~55C (measured externally with infrared thermometer).
Yeah, those sensors seems to have dissapeared since the 3.8 kernel too.
But still no segfault.
So I can only conclude that the gta04-kernel works stable - at least for me and my EVM setup and I have really no idea why it fails for you.
Using the same setup (omap5-pyra.dtb, rootfs on sd, kernel dir on sata) i had no problems either.
Ah, good!
Of course i have no working xorg with that setup.
Hm. Let me think… I pulled the pyra.dtb from the EVM - but with BOE panel. So it might be the one with the BOE driver which fails to init the DSS if no panel is connected.
Please try the attached .dtb file (which uses the panel-mipi-debug driver that works with no panel connected).
using omap5-uevm and rootfs on sata, i do get segfaults again. Doesn't matter if xorg is running or not. So a place to look would be hdmi , or in the omap5-uevm.dts.
Ah, ok. That are 2 diffs to my setup: * you have rootfs on SATA * you use hdmi
I did notice quite a lot of overrides in omap5-pyra. so an omap5-pyra+hdmi would be nice (unless there's an easy way of switching the output).
I think hdmi should be available automatically by omap5-pyra.dtb but I don’t know since I have no well working hdmi monitor (all my computers are all-in one or VGA and the only „hdmi“ monitor is some years old). Maybe I should look into that (when I find time and a good monitor).
gta 3.19.-rc3 with omapdrm compiled in didn't segfault, but i didn't get a working xorg with that either.
BR, Nikolaus
Am Wed, 14 Jan 2015 07:35:55 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
using omap5-uevm and rootfs on sata, i do get segfaults again. Doesn't matter if xorg is running or not. So a place to look would be hdmi , or in the omap5-uevm.dts.
Ah, ok. That are 2 diffs to my setup:
- you have rootfs on SATA
- you use hdmi
From what I heard from notaz, SATA seems to be horribly buggy on the OMAP5 - you're lucky if your harddrive even works.
That might be the issue.
Of course i have no working xorg with that setup.
Hm. Let me think… I pulled the pyra.dtb from the EVM - but with BOE panel. So it might be the one with the BOE driver which fails to init the DSS if no panel is connected.
Please try the attached .dtb file (which uses the panel-mipi-debug driver that works with no panel connected).
Seems the problem was more to do with it choosing lcd as the default output instead of hdmi, since xorg was opening a 720x1280 screen.
And after a bit of kernel option fighting, adding omapdss.def_disp=hdmi does make it work :)
I'll still have to check if this is any more stable.
On 01/14/2015 05:07 PM, aTc wrote:
I'll still have to check if this is any more stable.
I've recompiled that kernel with the sata stuff in there, which went fine, and then ran that kernel with the rootfs on sata. And that has been running stable compiling kernels and playing youtube videos for a few hours now. So it seems the problem was in the omap5-uevm.dts
I'm now using the 3.19.0-rc5-gta04 , with a few config changes, and everything seems extremely stable. Even running the debian xorg causes no problems. Haven't seen any segfaults when compiling either.
The (major) things i enabled were lpae and virtualization, which also required disabling armv6 support. So i suspect one of those to be the cause of the problems. Without those changes, the debian xorg crashes almost immediately (unless the non thumb version from our repo is used)
compiled version here : http://next.openpandora.org/omap5/kernel/3.19.0-rc5-gta04-av-2.tar.xz
Am 29.01.2015 um 16:00 schrieb aTc atc@k-n-p.org:
I'm now using the 3.19.0-rc5-gta04 , with a few config changes, and everything seems extremely stable. Even running the debian xorg causes no problems. Haven't seen any segfaults when compiling either.
The (major) things i enabled were lpae and virtualization, which also required disabling armv6 support. So i suspect one of those to be the cause of the problems.
Oh, that looks good! At least we have traced it down to a manageable set of potential factors. Which does not mean that it will be easy to find out what the problem-maker really is. But it is easier to ask e.g. on LKML or the e2e-Forum if someone knows about such issues.
Without those changes, the debian xorg crashes almost immediately (unless the non thumb version from our repo is used)
compiled version here : http://next.openpandora.org/omap5/kernel/3.19.0-rc5-gta04-av-2.tar.xz
Great. Thanks!
Nikolaus
PS: I am in the middle of placing the copper traces for the CPU board. Looks as if it is just time-consuming, but no big hurdles are visible. It is indeed easier on a 8-layer 100um structure PCB with micro-vias than a 4-layer board without and 150um structure (making it much cheaper…). With a little luck we will have our own omap5 board soon (there can be an engineering variant with 2 SD slots and a micro-USB socket for external power and FTDI console - I plan to build 1, maybe 2 of these for board bringup)
Hi,
On Thu, Jan 29, 2015 at 5:27 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
PS: I am in the middle of placing the copper traces for the CPU board. Looks as if it is just time-consuming, but no big hurdles are visible. It is indeed easier on a 8-layer 100um structure PCB with micro-vias than a 4-layer board without and 150um structure (making it much cheaper…). With a little luck we will have our own omap5 board soon (there can be an engineering variant with 2 SD slots and a micro-USB socket for external power and FTDI console - I plan to build 1, maybe 2 of these for board bringup)
Aren't we going to have some UART-to-USB solution on the charging port on final boards too?
Gražvydas
Am 30.01.2015 um 01:57 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Thu, Jan 29, 2015 at 5:27 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
PS: I am in the middle of placing the copper traces for the CPU board. Looks as if it is just time-consuming, but no big hurdles are visible. It is indeed easier on a 8-layer 100um structure PCB with micro-vias than a 4-layer board without and 150um structure (making it much cheaper…). With a little luck we will have our own omap5 board soon (there can be an engineering variant with 2 SD slots and a micro-USB socket for external power and FTDI console - I plan to build 1, maybe 2 of these for board bringup)
Aren't we going to have some UART-to-USB solution on the charging port on final boards too?
Yes, for complete devices. This optional addition allows to operate the CPU baord without main board (or some breakout board).
It is needed for board-bringup for two reasons: * the production device will use a different UART3 pinmux, i.e. we will have to recompile MLO first, before I can debug the board. With the debug addition, the SD card from the EVM should work out of the box * the other thing is that the CPU is sandwiched between its PCB and the main PCB, i.e. I have no access to any measurement points - or I have no console. Therefore I need a way to operate it without main board.
As soon as the CPU board works, we can switch to the different MLO and there is no need to worry about that interim solution any more.
BR, Nikolaus
On 2015-01-29, aTc wrote:
The (major) things i enabled were lpae and virtualization, which also required disabling armv6 support. So i suspect one of those to be the cause of the problems. Without those changes, the debian xorg crashes almost immediately (unless the non thumb version from our repo is used)
https://wiki.debian.org/ArmHardFloatPort#Supported_devices
"Currently the Debian armhf port requires at least an ARMv7 CPU with Thumb-2 and VFP3D16."
The main obvious thumb related change from the armhf kernels in Debian vs. the armel kernels is CONFIG_ARM_THUMBEE=y. They all have CONFIG_ARM_THUMB=y.
live well, vagrant
Am Sat, 10 Jan 2015 23:48:01 +0100 hat aTc atc@k-n-p.org geschrieben:
Hi,
I do have to keep up my grumpy reputation on irc, so i tend to make things sound a lot worse than they really are, which most people there are well aware of. Out of context it sounds a lot ruder than it was meant :) And it was mostly just a bit of background ranting while messing about with the stuff. Trying to dig up the source of the problem takes a lot more time and effort than quickly writing "blah, this doesn't work" on irc.
Heh, right - Nikolaus, you don't know aTc yet. I think whenever he stops complaining, the world is bound to explode.
That's totally normal (and once you get used to it, it's actually fun ;))
One thing that comes to my mind: While I'm not a developer, I've been in contact with all different kinds of developers myself. And one thing I found out is that most of them usually don't want to hassle anyone with eMails - so if something doesn't work, many simply quit working on that.
That's why some minimum information (what branch is what, etc.) should be somewhere easy to find - then those questions won't arise.
We should try to get that all sorted out as fast as possible. The rootfs is just one part, the kernel another one. Our current Debian rootfs doesn't provide a kernel, as we had no real idea which one to use. Everyone who wants to help with testing should use the same kernel, so we need to get all of this into a Debian recipe so that the kernel automatically updates as well.