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