Hi,
since i've been having quite some problems getting the pyra to run without locking up constantly, could you give me a link (or a working makesd config) to a known working SD card image for my pyra prototype.
I did try making one with the makesd script, but all the "latest" links seems to have been last updated 5 months ago, and I get an image with a 4.6.0 kernel. I also don't know which .dtb to use on this one, since there are quite a few to choose from, and i'm also not sure about which lcd panel config this one needs.
That way i'd at least know if the problems i'm seeing are just part of the prototype, or part of my messing about with kernels/u-boot/xorg configs/etc.
Hi,
Am 15.09.2016 um 23:08 schrieb aTc atc@k-n-p.org:
Hi,
since i've been having quite some problems getting the pyra to run without locking up constantly, could you give me a link (or a working makesd config) to a known working SD card image for my pyra prototype.
Some option would be that I dd a copy of my latest SD card and make it available for download. But I currently have no Pyra hardware to check which SD card is really the latest and working for me... And uploading/downloading GBytes takes some time (although my server has ca. 8Mbit upstream).
makesd is too flexible... Hence the documentation is not complete what it can do. We should some time find someone to work on improving documentation (could easily become its own O'Reilly booklet)...
The problem is that it is sometimes easier to look into the source to know the parameters...
http://git.goldelico.com/?p=gta04-makesd.git;a=blob;f=makesd
I did try making one with the makesd script, but all the "latest" links seems to have been last updated 5 months ago,
Well, there was no need to update u-boot (last update was indeed in April 2016) or the rootfs (apt-get update && apt-get upgrade will get latest jessie assuming network connection on the device). All changes and attempts to make the Pyra work were kernel related. 5 months work of kernel stabilization...
But if you just tried yesterday, I was in the middle of updating the debian rootfs images to Jessie 8.5.
and I get an image with a 4.6.0 kernel.
This is indeed the current default for the latest kernel installed by makesd and there have been a lot of important fixes and improvements since its release.
I will explain how you can bake a card with a different kernel or rootfs:
DEV=/dev/sdd ./makesd pyra+lc15
"pyra+lc15" installs everything "latest" for the Pyra and defaults to lxde [should probably be renamed to pyra-lxde or something] "pyra" would install everything "latest" and fetch http://packages.pyra-handheld.com/rootfs/pyra-debian-jessie-xfce-rootfs.tgz but rootfs config might not match kernel
All defaults and "latest" can be overwritten (I could not test if it really works). For a different kernel (on a dual-partition SD card):
DEV=/dev/sdd ./makesd pyra+lc15 -f1 -k letux-4.8-rc6 -d letux-4.8-rc6 -f2 -m letux-4.8-rc6
"pyra+lc15" is a macro that expands roughly into: "make two partitions, install latest boot loader for Pyra with LC15 CPU-Board, install latest kernel and latest LXDE (default)". "-f1" means "go back to first partition (FAT where uImage is stored) for the following commands" "-k letux-4.8-rc6" means "replace latest kernel by letux-4.8-rc6 to be fetched from default download server location" "-d letux-4.8-rc6" means "replace latest device tree by letux-4.8-rc6 to be fetched from default download server location" "-f2" means "go to second partition for the following command" "-m letux-4.8-rc6" means "replace latest modules by letux-4.8-rc6 to be fetched from default download server location"
Default download server location is http://download.goldelico.com/letux-kernel
Let's assume you want (default configured) xfce4 instead of lxde:
DEV=/dev/sdd ./makesd pyra+lc15 -f2 -r xfce
"-f2" means "go to second partition" "-r xfce" means "replace latest lxde by latest xfce4 to be fetched from default download server location"
Default download server location is http://download.goldelico.com/letux-debian-rootfs/
A specific version (the one which was latest until yesterday) could be selected by
DEV=/dev/sdd ./makesd pyra+lc15 -f2 -v 20151024-jessie-8.2 -r xfce"
Since all parameters to ./makesd build up a configuration parameter set for all partitions, they can be combined and the last settings will finally be used to bake the SD card.
So I would recommend to do:
DEV=/dev/sdd ./makesd pyra+lc15 -f1 -k letux-4.8-rc6 -d letux-4.8-rc6 -f2 -m letux-4.8-rc6 -r xfce
If you want to try the same kernel on EVM please do (this is something I have verified some minutes ago - and noticed there is an issue with X11 config but you can login as root (empty password) through FT232 port):
DEV=/dev/sdd ./makesd omap5432evm -f1 -b OMAP5432-uEVM/2016-05-10 -k letux-4.8-rc6 -d letux-4.8-rc6 -f2 -m letux-4.8-rc6 xfce
I also don't know which .dtb to use on this one, since there are quite a few to choose from, and i'm also not sure about which lcd panel config this one needs.
What I do during development is to patch a new kernel + modules + dtb over an existing SD card image by manual copy (or mostly automated by a script) of the latest built uImage and /lib/modules.
So you could also download files from http://download.goldelico.com/letux-kernel and expand on your SD card. Please expand also the config.tbz since it contains the Letux/root and Letux/etc files which are tied to a specific kernel release. The bootargs.scr can be ignored for OMAP5 (they are a relict for old boot loaders on GTA04).
The device tree binary loaded by U-Boot is defined in uEnv.txt in the boot partition (first).
Now let me explain how the plethora of (latest) DTBs are organised.
http://download.goldelico.com/letux-kernel/letux-4.8-rc6/ has a device-trees.tbz
This package contains the following omap5 device tree binaries:
omap5-letux-cortex15+pyra.dtb -- this is the one to use for the current prototypes (means Pyra PCBs V5.0) omap5-letux-cortex15-v4.9+pyra.dtb -- this is for the V4.9 CPU + Mainboard (old) omap5-letux-cortex15-v4.9.dtb -- this is for the V4.9 CPU standalone (old) omap5-letux-cortex15-v5.1+pyra-v5.1.dtb -- this will be for the first mass production version (there will be minor changes to be reflected by DT) omap5-letux-cortex15-v5.1.dtb -- this will be for the first mass production version (there will be minor changes to be reflected by DT) omap5-letux-cortex15.dtb -- this is for the V5.0 (current prototypes) standalone (i.e. if not mounted on a Pyra main board) omap5-uevm+pyra4+boe.dtb -- this is for the BOE panel connected to an uEVM (old) omap5-uevm+pyra4+lg.dtb -- this is for some LG panel connected to an uEVM (old) omap5-uevm+pyra4+ssd+boe.dtb -- this is for the BOE panel connected with SSD2858 to an uEVM (old) omap5-uevm+pyra4+ssd+succ.dtb -- this is for some Success panel connected to an uEVM (old) omap5-uevm+pyra4+succ.dtb -- this is for some Success panel connected with SSD2858 to an uEVM (old) omap5-uevm+pyra4.dtb -- this is for a Pyra4.9 mainboard to an uEVM (old) using the panel-mipi-debug driver omap5-uevm-broken+pyra4.dtb -- a variant of previous where some i2c has been replaced by a bit-bang gpio driver omap5-uevm.dtb -- pure uevm.dtb as by linus/master
So you should use omap5-letux-cortex15+pyra.dtb and make sure that the uEnv.txt in the boot partition does choose it. This DTB will reference the panel-mipi-debug driver and some shell script (/root/ssd2858) is used to set-up the ssd2858 by the X config.
./makesd pyra+lc15
should set up this combination of boot loader, uEnv.txt, DT and xinitrc patch to start /root/ssd2858 automatically.
Of course we can get rid of the older things soon - I just bundle/publish them to keep the older prototypes running as good as possible for doing comparisons. Especially the pyra4 and different panel things can be removed since nobody besides me (maybe ED and notaz) still uses such a hardware.
Hope this mail is a good reference for the current situation.
That way i'd at least know if the problems i'm seeing are just part of the prototype, or part of my messing about with kernels/u-boot/xorg configs/etc.
Yes, that would be good for debugging.
Phew. This became quite a lot of material and it took me two hours to prepare and review.
But it took me much longer to build up this expertise (by doing many mistakes) and we definitively have to exchange and spread this information to more people.
Please let me know if it works or does not work or questions arise.
BR and thanks, Nikolaus
Hi,
okay, I took the time today to look a bit at the stability issues we have. I didn't do any analysis, just tried different boards with different setups and wrote down what happened.
The analysis should happen when I visit Nikolaus with all the PCBs and various AC Adaptors and USB cables.
@Nikolaus: But of course, if you want me to run any other tests upfront, let me know.
First, here are some general things I found out:
* The Micro USB cable matters! I've got a MicroUSB cable that, when connected to the Pyra, is not able to boot it. All I get is a short blinking of lights and then a reboot. The cable itself works fine for any other device (I use it to charge my smartphone each night) and also works fine as data cable (I used it in the tests to connect the FTDI to the laptop)
* The same thing applies to the AC Adaptor: Some AC Adaptors work, some simply cause the same reboot loop. So to get it to boot a proper combination between an AC Adaptor and USB Cable is needed.
* Even with a proper cable, the USB port seems to be VERY unstable. Just touching it or wiggling a bit can cause a freeze on the Pyra!
* When inserting a battery, the Pyra sometimes boots up immediately and sometimes it doesn't. No idea when it does what and why.
* I didn't have a single freeze at MLO even though I always had the SD Card in the slot already when I connected the power. So that issue Nikolaus had cannot be confirmed here (which is good :))
Okay, so much for the general info. Now take a look at the attached Excel sheet. These are some results I got from booting various boards under different setups. The display board I used is one with the SSD included.
Here is a summary of the results:
* Booting without a display board attached almost ALWAYS works fine. Except for the first one or two tries. Regardless of whether I boot with an AC Adaptor, a battery or both.
* Booting WITH a display board attached makes the whole thing very random. Often the board boots up fine but doesn't find the display board. This especially seems to happen when only powering from a battery.
* Booting WITH a display board but without battery causes the Pyra to shut itself off when X is loading and the display should show something. This happens regardless whether my laptop or a 2A USB AC adaptor is used to power the unit. If the display board is not found, it doesn't shut itself off.
* Booting WITH a display board and powering ONLY from battery works stable (once you managed to boot it, as most of the times it doesn't find the display board, as mentioned above).
* The best combination seems to be booting WITH a battery AND an AC Adaptor connected. In that case, it finds the display board most of the time and also doesn't shut off when it's booted up. However, in case the battery is removed while AC is still being kept connected, the Pyra shuts off after a few seconds.
What does that tell us? I'm not sure. I doubt the LCD Cable itself is flakey, as it hasn't been touched during the reboots and once it found and initialized the display board, it worked stable.
But as it mostly works if both the battery AND the AC connecter is attached, it could be some power issue. Maybe at bootup, when the kernel initializes the hardware, the display board lacks the power to respond and therefore it's not being found?
It's a bit of a mystery, but the more power I pump into the system, the more stable it seems to run and find the display board as well.
Hi,
Am 18.09.2016 um 17:12 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
okay, I took the time today to look a bit at the stability issues we have. I didn't do any analysis, just tried different boards with different setups and wrote down what happened.
The analysis should happen when I visit Nikolaus with all the PCBs and various AC Adaptors and USB cables.
@Nikolaus: But of course, if you want me to run any other tests upfront, let me know.
First, here are some general things I found out:
- The Micro USB cable matters!
Indeed!
I've got a MicroUSB cable that, when connected to the Pyra, is not able to boot it. All I get is a short blinking of lights and then a reboot. The cable itself works fine for any other device (I use it to charge my smartphone each night)
What is the charging current of your smartphone?
and also works fine as data cable (I used it in the tests to connect the FTDI to the laptop)
- The same thing applies to the AC Adaptor: Some AC Adaptors work, some
simply cause the same reboot loop. So to get it to boot a proper combination between an AC Adaptor and USB Cable is needed.
Ah, you use different wall chargers with a standard USB socket and then attach an external USB-to-micro-USB cable?
This makes all depend on the question if the cable can carry 2 Amperes.
Usually such cables are for data use only and assume a maximum current of USB 1: 100 mA USB 2: 500 mA USB 3: 900 mA (!)
It is allowed that voltage at the device end of a cable drops to 4.4V.
Here is some discussion:
http://electronics.stackexchange.com/questions/170292/what-is-the-maximum-ph...
So unless you have an "PD aware cable" is likely to be too weak...
Then a too high resistance and 2A makes the voltage that arrives inside the Pyra too low for stable operation. Software could be able to detect this and print a warning like I have seen on some smartphones: "bad charging cable". But this works only if the device is up and running.
This all is different for pure chargers (i.e. not a combination of wall charger plus cable). If it is rated 2A the cable is designed for 2A and the encoding of the USB charging spec (D+ and D- according to the bq24297 table I recently referred to) allows the bq24297 to detect such a power supply and draw 2 Amperes.
Since we tamper with this detection in our u-boot if there is no battery installed, the bq24297 also tries to pull 2A through a weak cable from a potentially strong enough power supply and that can be the problem.
- Even with a proper cable, the USB port seems to be VERY unstable.
Just touching it or wiggling a bit can cause a freeze on the Pyra!
Seems to be a mechanical problem. Dust inside?
- When inserting a battery, the Pyra sometimes boots up immediately and
sometimes it doesn't. No idea when it does what and why.
That is also something I have observed. Maybe it depends on whether the Palmas RTC is still running and how the device was shut down last time.
There might be a bit within Palmas which can control the behavior.
- I didn't have a single freeze at MLO even though I always had the SD
Card in the slot already when I connected the power. So that issue Nikolaus had cannot be confirmed here (which is good :))
Okay, so much for the general info. Now take a look at the attached Excel sheet.
One significant observation: Linux letux 4.8.0-rc1-letux+
The -rc1 was known to have problems. Please update to -rc5 or -rc6.
These are some results I got from booting various boards under different setups. The display board I used is one with the SSD included.
Here is a summary of the results:
- Booting without a display board attached almost ALWAYS works fine.
Except for the first one or two tries. Regardless of whether I boot with an AC Adaptor, a battery or both.
- Booting WITH a display board attached makes the whole thing very
random. Often the board boots up fine but doesn't find the display board. This especially seems to happen when only powering from a battery.
- Booting WITH a display board but without battery causes the Pyra to
shut itself off when X is loading and the display should show something. This happens regardless whether my laptop or a 2A USB AC adaptor is used to power the unit. If the display board is not found, it doesn't shut itself off.
- Booting WITH a display board and powering ONLY from battery works
stable (once you managed to boot it, as most of the times it doesn't find the display board, as mentioned above).
- The best combination seems to be booting WITH a battery AND an AC
Adaptor connected. In that case, it finds the display board most of the time and also doesn't shut off when it's booted up. However, in case the battery is removed while AC is still being kept connected, the Pyra shuts off after a few seconds.
What does that tell us? I'm not sure. I doubt the LCD Cable itself is flakey, as it hasn't been touched during the reboots and once it found and initialized the display board, it worked stable.
But as it mostly works if both the battery AND the AC connecter is attached, it could be some power issue. Maybe at bootup, when the kernel initializes the hardware, the display board lacks the power to respond and therefore it's not being found?
It's a bit of a mystery, but the more power I pump into the system, the more stable it seems to run and find the display board as well.
It could still be a kernel bug. Detection of battery and or AC connector has different activities in the kernel so some things may boot in different order.
And generally DSI/MIPI and our hacked ssd driver is instable (these atomic timeout thing is an important hint). So these messages may indicate that the kernel is running through unexpected states which might have side-effects, even for power management.
This is why I think we should clean this up asap. Either by retiring the ssd2858 completely or fixing the ssd2858.ko kernel module. So that we do no longer see warnings from the DSS startup.
But: according to my memory the Pyra usually hangs much earlier before DSS is even initialized. It seems (I haven't made a statistics) hang shortly after initializing the bq24297 and before the audio subsystem.
Let's see if we can find out more in our planned working session.
BR, Nikolaus
First some good news :
pyra booting pyraos with a TILER enabled kernel.
It still needs a very ugly hack to keep the display on for more than 10 seconds, but at least the basics work. (no display until it loads the kernel modules, which is why you don't see anything the first 19 seconds, and the annoying flashing leds are turned off by my led-config, the one "failed" message you see is just the sgx driver modules failing to load)
It's still quite a struggle to boot the thing though, but once it does, its fairly stable when both usb power and the battery are used. USB power alone tends to drop out when the load gets higher. Taking out the battery while on USB power also seems to cause a drop in brightness of the leds.
Booting usually gets stuck on the u-boot "Starting kernel ..." message. Although sometimes it doesn't even get beyond the first two lines : "U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27) OMAP5432 ES2.0 "
It seems it gets easier to boot the longer you try, like something needs charging/warming up first :)
I did take apart the entire thing, and after that booting does seem to have become slightly more reliable. Maybe it has something to do with that cpu board not beeing mounted properly in the second socket. At the angle it sits it's a miracle it works at all. Although I also took out the stuck shoulderbuttons. (not sure if they were pushing down on the buttons, but they didn't move anyway)
Another thing I noticed was a high pitched whine when plugging in usb devices.
When using the letux makesd created image, there's a 3 minute delay halfway through booting, right after "[ 15.161997] wlcore: loaded" After the delay, it continues booting without problems. I didn't really investigate what caused it, it doesn't happen when using the pyraos image (probably because that uses the much more parallel systemd) Also, devmem2 seems to be missing from the image, the package is there, but the executable isn't found, which causes some issues with the lcd script (which doesn't seem to be needed on my pyra anyway, since the display just works when using omap5-letux-cortex15-v5.1+pyra-v5.1.dtb)
Hi, thanks for the feedback!
Am 20.09.2016 um 22:14 schrieb aTc atc@k-n-p.org:
First some good news :
pyra booting pyraos with a TILER enabled kernel.
It still needs a very ugly hack to keep the display on for more than 10 seconds, but at least the basics work.
Great!
(no display until it loads the kernel modules, which is why you don't see anything the first 19 seconds, and the annoying flashing leds are turned off by my led-config, the one "failed" message you see is just the sgx driver modules failing to load)
It's still quite a struggle to boot the thing though, but once it does, its fairly stable when both usb power and the battery are used. USB power alone tends to drop out when the load gets higher. Taking out the battery while on USB power also seems to cause a drop in brightness of the leds.
Yes, this is intentional (by texas instruments when designing the bq24297). The LEDs are operated directly from VSYS and VSYS voltage depends on USB and/or battery operation. If the battery is more than ~50% charged the voltage from battery is higher and hence VSYS.
Booting usually gets stuck on the u-boot "Starting kernel ..." message. Although sometimes it doesn't even get beyond the first two lines : "U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27) OMAP5432 ES2.0 "
Yes, I have had that as well several times. It even does not load U-Boot in that case. Initially I thought that the SD interface could be a factor - but then it would not even have found the SPL (MLO).
The only solution was to remove all power (incl. battery) and retry.
This is something on my should-be-done-list to add debugging to SPL where it hangs and why.
It seems it gets easier to boot the longer you try, like something needs charging/warming up first :)
One candidate is the backup battery for the RTC. Or the Palmas stores some internal state from the last boot attempt which makes SPL hang.
I did take apart the entire thing, and after that booting does seem to have become slightly more reliable. Maybe it has something to do with that cpu board not beeing mounted properly in the second socket.
Could potentially be an issue. But this corner of the connector provides interface to the second SD slot and WiFi. So those would fail but nothing else.
At the angle it sits it's a miracle it works at all.
This should be solved with the new CPU boards.
Although I also took out the stuck shoulderbuttons. (not sure if they were pushing down on the buttons, but they didn't move anyway)
Another thing I noticed was a high pitched whine when plugging in usb devices.
This is the inductor of the DC/DC converter for providing 5V. It makes some noise. I have thought about choosing different one, but haven't found some small enough replacements with same parameters from a different manufacturer. All others are too big.
When using the letux makesd created image, there's a 3 minute delay halfway through booting, right after "[ 15.161997] wlcore: loaded" After the delay, it continues booting without problems.
I didn't really investigate what caused it, it doesn't happen when using the pyraos image (probably because that uses the much more parallel systemd)
This is likely induced by /etc/network/interfaces (waiting for dhcpd or something).
Also, devmem2 seems to be missing from the image, the package is there, but the executable isn't found, which causes some issues with the lcd script (which doesn't seem to be needed on my pyra anyway, since the display just works when using omap5-letux-cortex15-v5.1+pyra-v5.1.dtb)
Ah, ok. I had rebuilt the devmem2 package and my new build script did place it in /usr/bin/arm-linux-gnueabihf which is not in $PATH.
Unfortunately I could not test the latest image on a Pyra...
BR, Nikolaus
On 20 September 2016 at 22:29, H. Nikolaus Schaller hns@goldelico.com wrote:
"U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27)
Why is such an old u-boot being used? There have been pretty important-looking patches this year such as this one:
https://patchwork.ozlabs.org/patch/613289/
Matthijs
Hi Matthijs,
Am 08.10.2016 um 01:46 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 20 September 2016 at 22:29, H. Nikolaus Schaller hns@goldelico.com wrote:
"U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27)
Why is such an old u-boot being used?
"Never touch a running (boot) system..."
Especially if you have to urgently fix known problems elsewhere (hardware, software).
Because it is unlikely (until explicitly proven) that the boot loader is the source of the problem.
There have been pretty important-looking patches this year such as this one:
Well, the EVM did work for a long time w/o this patch, so it might improve things but does not seem to be essential to me.
What I also can't see is if this patch fixes something introduced after 2015.10.
Following mainline U-Boot it needs a little time to correctly rebase and update (there are several CONFIG modifications to track and functions move between board file and core and change names).
But anyways I have started to rebase on 2016.09 yesterday because I need a new U-Boot for the GTA04A5 device as well. There we still use an 2011.03 U-Boot which has never made a problem until now because it does not support the OneNAND chip.
It my experience using the latest things sometimes needs more efforts (tracking what has been changed, rebasing, testing) than plainly using an old but mature system.
So we will have a latest U-Boot in some days for testing.
BR, Nikolaus
I don't see the emmc under linux, i only have one /dev/mmcblk* and that's the sd card. u-boot does seem to detect it, so i guess it's missing from the dts, or is there something else going on ?
On Sat, Oct 08, 2016 at 08:22:55PM +0200, aTc wrote:
I don't see the emmc under linux, i only have one /dev/mmcblk* and that's the sd card. u-boot does seem to detect it, so i guess it's missing from the dts, or is there something else going on ?
Not sure if I say anything new to you... MMC and microSD card reader are connected to same SDIO bus (?) line. And there's some circuitry switching between them, this is supposed to be done by tiny chip, I believe its name is like twl6040, and implementation of this on-demand switching is a pending task.
On 8 October 2016 at 21:35, Andrey Utkin andrey_utkin@fastmail.com wrote:
connected to same SDIO bus (?) line
I would say "same mmc/sd interface".
twl6040
That's the audio IC
Matthijs
Am 08.10.2016 um 21:35 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Sat, Oct 08, 2016 at 08:22:55PM +0200, aTc wrote:
I don't see the emmc under linux, i only have one /dev/mmcblk* and that's the sd card. u-boot does seem to detect it, so i guess it's missing from the dts, or is there something else going on ?
Not sure if I say anything new to you... MMC and microSD card reader are connected to same SDIO bus (?) line. And there's some circuitry switching between them, this is supposed to be done by tiny chip, I believe its name is like twl6040,
Yes, almost. It is a txs02612.
and implementation of this on-demand switching is a pending task.
Here is a collection of some details what I think we finally should have:
http://projects.goldelico.com/p/gta04-kernel/issues/698/
A driver skeleton exists but has no function except proposing bindings:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
but no code... I think we should first find out where to place the driver (drivers/misc or drivers/mmc/card or drivers/mmc/misc?).
And there is some DT preparation (of course completely untested):
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap...
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap...
Our U-Boot/MLO also has some preliminary code to control the switch. And hardware controls, which one is taken for initially locating MLO.
BR, Nikolaus
Hi,
On Tue, Sep 20, 2016 at 11:14 PM, aTc atc@k-n-p.org wrote:
It's still quite a struggle to boot the thing though, but once it does, its fairly stable when both usb power and the battery are used. USB power alone tends to drop out when the load gets higher. Taking out the battery while on USB power also seems to cause a drop in brightness of the leds.
Booting usually gets stuck on the u-boot "Starting kernel ..." message. Although sometimes it doesn't even get beyond the first two lines : "U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27) OMAP5432 ES2.0 "
That looks familiar, for me it almost always gets stuck at the 2 SPL lines, after a hour or so of warmup it starts entering u-boot and randomly hanging there, occasionally reaching "Starting kernel ...", and if I'm very lucky, it will show some kernel output too before it hangs again. That is with both battery and power supply connected. What's interesting is that shortly after receiving it from ED I was able to boot to desktop, but it degraded to unusable state over time.
Gražvydas
Am 21.09.2016 um 13:32 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Tue, Sep 20, 2016 at 11:14 PM, aTc atc@k-n-p.org wrote:
It's still quite a struggle to boot the thing though, but once it does, its fairly stable when both usb power and the battery are used. USB power alone tends to drop out when the load gets higher. Taking out the battery while on USB power also seems to cause a drop in brightness of the leds.
Booting usually gets stuck on the u-boot "Starting kernel ..." message. Although sometimes it doesn't even get beyond the first two lines : "U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27) OMAP5432 ES2.0 "
That looks familiar, for me it almost always gets stuck at the 2 SPL lines, after a hour or so of warmup it starts entering u-boot and randomly hanging there, occasionally reaching "Starting kernel ...", and if I'm very lucky, it will show some kernel output too before it hangs again. That is with both battery and power supply connected. What's interesting is that shortly after receiving it from ED I was able to boot to desktop, but it degraded to unusable state over time.
This makes me think: soldering issue. I.e. should be solved by next production run.
Ah, and if I remember correctly it was one of the really early boards? Then it does not even have all hardware fixes and some might influence the boot process.
Or did you get one of the Gamescom devices?
BR, Nikolaus
On Wed, Sep 21, 2016 at 2:47 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Am 21.09.2016 um 13:32 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
On Tue, Sep 20, 2016 at 11:14 PM, aTc atc@k-n-p.org wrote:
It's still quite a struggle to boot the thing though, but once it does, its fairly stable when both usb power and the battery are used. USB power alone tends to drop out when the load gets higher. Taking out the battery while on USB power also seems to cause a drop in brightness of the leds.
Booting usually gets stuck on the u-boot "Starting kernel ..." message. Although sometimes it doesn't even get beyond the first two lines : "U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27) OMAP5432 ES2.0 "
That looks familiar, for me it almost always gets stuck at the 2 SPL lines, after a hour or so of warmup it starts entering u-boot and randomly hanging there, occasionally reaching "Starting kernel ...", and if I'm very lucky, it will show some kernel output too before it hangs again. That is with both battery and power supply connected. What's interesting is that shortly after receiving it from ED I was able to boot to desktop, but it degraded to unusable state over time.
This makes me think: soldering issue. I.e. should be solved by next production run.
Ah, and if I remember correctly it was one of the really early boards? Then it does not even have all hardware fixes and some might influence the boot process.
Or did you get one of the Gamescom devices?
No, it's one of the early boards.
Gražvydas
Trying to boot this thing just takes too much effort. That latest u-boot patch did make things slightly more reliable, but I'm beginning to suspect there's a lot more wrong with this one than not having enough power.
I can't even seem to boot the thing with the battery inserted anymore. Once the battery is removed, usb booting works, after about 15 minutes of trying, and even then it's very unreliable. I tried booting it with the lcd cable disconnected, but that didn't help either. It still gets stuck in u-boot most of the time. So it's probably not power related.
I do get a lot of fun error messages:
from u-boot:
SCSI: SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode undefined instruction pc : [<fef7c7c2>] lr : [<fef7c799>] reloc pc : [<801137c2>] lr : [<80113799>] sp : fdf48e10 ip : 0000000f fp : fef9e286 r10: 00000001 r9 : fdf48ef8 r8 : fefbbff4 r7 : 00000004 r6 : fef9e2ca r5 : ef26ff80 r4 : fefa18c9 r3 : fefa18c9 r2 : fef9e27b r1 : fef9e28c r0 : fef9e2cf Flags: nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
and
spl: mmc init failed with error: -19 ### ERROR ### Please RESET the board ###
and some nice kernel panics : [ 22.271826] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
When it does work, the screen sometimes ends up with a lot of garbage on it, sometimes causing it to freeze.
I suspect it has to do with the cpu board, it needs to be pushed in really really hard after disassembling the pyra to get it to even work at all.
Enough complaining for now, i'll see if changing the kernel makes a difference, since i'm pretty much only using a patched kernel with the TILER stuff enabled, and haven't tried the latest 4.8 one either.
Am 07.10.2016 um 01:35 schrieb aTc atc@k-n-p.org:
Trying to boot this thing just takes too much effort. That latest u-boot patch did make things slightly more reliable, but I'm beginning to suspect there's a lot more wrong with this one than not having enough power.
I can't even seem to boot the thing with the battery inserted anymore. Once the battery is removed, usb booting works, after about 15 minutes of trying, and even then it's very unreliable. I tried booting it with the lcd cable disconnected, but that didn't help either. It still gets stuck in u-boot most of the time. So it's probably not power related.
I do get a lot of fun error messages:
from u-boot:
SCSI: SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode undefined instruction
oops... I have never seen such in U-Boot.
pc : [<fef7c7c2>] lr : [<fef7c799>] reloc pc : [<801137c2>] lr : [<80113799>] sp : fdf48e10 ip : 0000000f fp : fef9e286 r10: 00000001 r9 : fdf48ef8 r8 : fefbbff4 r7 : 00000004 r6 : fef9e2ca r5 : ef26ff80 r4 : fefa18c9 r3 : fefa18c9 r2 : fef9e27b r1 : fef9e28c r0 : fef9e2cf Flags: nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
and
spl: mmc init failed with error: -19 ### ERROR ### Please RESET the board ###
and some nice kernel panics : [ 22.271826] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
When it does work, the screen sometimes ends up with a lot of garbage on it, sometimes causing it to freeze.
I suspect it has to do with the cpu board, it needs to be pushed in really really hard after disassembling the pyra to get it to even work at all.
Yes, very likely. It could theoretically be the SD card which might copy bad file contents but that is quite unlikely since it should be CRC protected (but this might also be wrong).
I assume these things occur at random locations? Then it looks as if either the I-cache or the DRAM looses some bits.
Enough complaining for now, i'll see if changing the kernel makes a difference, since i'm pretty much only using a patched kernel with the TILER stuff enabled, and haven't tried the latest 4.8 one either.
If you see this in SPL (MLO), u-boot and kernel then it is likely a hardware issue. Maybe your CPU board is very flappable by power supply variations.
Let's cross fingers that the new CPU boards are available soon and the SMPS3 solves the issues.
BR, Nikolaus
Hi,
BOE was visiting me today and I also received the new touchscreens from Fatih ago (the ones using the exact same material as the Pandora touchscreens).
Well, looks like the company that delivered the touchscreens to BOE used a wrong material, as the touchscreens were grainy again (and the first sample in the wrong size wasn't), so no need to comment on these, as they were wrong.
However, I tried the ones from Fatih and FINALLY we have touchscreens which do NOT degrade the picture quality. Yay!
But there's something else that's interesting:
1. These touchscreens are ACCURATE without any jitter. All other touchscreens tried before were jittering a lot - and I thought this was something to fix in the driver. But these now don't jitter at all, the pointer stays exactly on one spot when keep the stylus pressed down. And they ALWAYS hit exactly where I press! I can also access every corner and the top and bottom which was always an issue with the previous touchscreens.
2. However: They still need more force to react than on the Pandora. Which reminded me: The Pandora touchscreen is pressure sensitive (255 values, if I remember correctly?) So this one should ALSO be pressure sensitive. Could it be that you can change the sensitivity in the driver? That would explain why the touchscreen needs more force to react - even though it's the exact same as on the Pandora.
Could someone check the driver to see whether there's some setting or whether it could be added? I'm not sure whether that's related to the touchscreen controller as well - how does this work on the Pandora?
Hi,
Am 21.09.2016 um 18:26 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
BOE was visiting me today and I also received the new touchscreens from Fatih ago (the ones using the exact same material as the Pandora touchscreens).
Well, looks like the company that delivered the touchscreens to BOE used a wrong material, as the touchscreens were grainy again (and the first sample in the wrong size wasn't), so no need to comment on these, as they were wrong.
However, I tried the ones from Fatih and FINALLY we have touchscreens which do NOT degrade the picture quality. Yay!
But there's something else that's interesting:
- These touchscreens are ACCURATE without any jitter. All other
touchscreens tried before were jittering a lot - and I thought this was something to fix in the driver.
Well, the driver can only filter jitter and try to suppress it, but it reduces precision.
But these now don't jitter at all, the pointer stays exactly on one spot when keep the stylus pressed down.
This is great!
And they ALWAYS hit exactly where I press! I can also access every corner and the top and bottom which was always an issue with the previous touchscreens.
- However: They still need more force to react than on the Pandora.
Which reminded me: The Pandora touchscreen is pressure sensitive (255 values, if I remember correctly?) So this one should ALSO be pressure sensitive. Could it be that you can change the sensitivity in the driver?
The driver also reports pressure values - but only if you you press more than some minimum pressure. This is to support debouncing.
That would explain why the touchscreen needs more force to react - even though it's the exact same as on the Pandora.
Could someone check the driver to see whether there's some setting or whether it could be added?
Yes, there is a minimum pressure value. And the resistance of the touch should correctly been set or the pressure isn't calculated properly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/pyra...
This means: * touchscreen-max-pressure * ti,max-rt * ti,x-plate-ohms
must be matched with the touch.
(don't be worried by the FIXME for the interrupt - it would be a duplicate entry and should be deleted in the mainboard DTS)
I'm not sure whether that's related to the touchscreen controller as well - how does this work on the Pandora?
Basically the same. Although Pandora OS does not have these parameters.
With Letux kernel for Pandora it is here:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap...
BR, Nikolaus
Am 21.09.2016 um 19:41 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 21.09.2016 um 18:26 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
BOE was visiting me today and I also received the new touchscreens from Fatih ago (the ones using the exact same material as the Pandora touchscreens).
Well, looks like the company that delivered the touchscreens to BOE used a wrong material, as the touchscreens were grainy again (and the first sample in the wrong size wasn't), so no need to comment on these, as they were wrong.
However, I tried the ones from Fatih and FINALLY we have touchscreens which do NOT degrade the picture quality. Yay!
But there's something else that's interesting:
- These touchscreens are ACCURATE without any jitter. All other
touchscreens tried before were jittering a lot - and I thought this was something to fix in the driver.
Well, the driver can only filter jitter and try to suppress it, but it reduces precision.
Means: the better the touch the less the driver has to fix...
But these now don't jitter at all, the pointer stays exactly on one spot when keep the stylus pressed down.
This is great!
And they ALWAYS hit exactly where I press! I can also access every corner and the top and bottom which was always an issue with the previous touchscreens.
- However: They still need more force to react than on the Pandora.
Which reminded me: The Pandora touchscreen is pressure sensitive (255 values, if I remember correctly?) So this one should ALSO be pressure sensitive. Could it be that you can change the sensitivity in the driver?
The driver also reports pressure values - but only if you you press more than some minimum pressure. This is to support debouncing.
That would explain why the touchscreen needs more force to react - even though it's the exact same as on the Pandora.
Could someone check the driver to see whether there's some setting or whether it could be added?
Yes, there is a minimum pressure value. And the resistance of the touch should correctly been set or the pressure isn't calculated properly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/pyra...
This means:
- touchscreen-max-pressure
- ti,max-rt
- ti,x-plate-ohms
must be matched with the touch.
(don't be worried by the FIXME for the interrupt - it would be a duplicate entry and should be deleted in the mainboard DTS)
I'm not sure whether that's related to the touchscreen controller as well - how does this work on the Pandora?
Basically the same. Although Pandora OS does not have these parameters.
With Letux kernel for Pandora it is here:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap...
BR, Nikolaus _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 09/21/2016 08:41 PM, H. Nikolaus Schaller wrote:
Hi,
Am 21.09.2016 um 18:26 schrieb Michael Mrozek EvilDragon@openpandora.org:
- However: They still need more force to react than on the Pandora.
Which reminded me: The Pandora touchscreen is pressure sensitive (255 values, if I remember correctly?)
It's closer to 16 I think.
I'm not sure whether that's related to the touchscreen controller as well - how does this work on the Pandora?
Basically the same. Although Pandora OS does not have these parameters.
It's not only the OS, the controller (and hence the driver) is completely different I think? I don't think it is possible to influence the minimum sensitivity that makes it react (on Pandora).
Grazvydas
Am Thu, 22 Sep 2016 00:33:56 +0300 hat Grazvydas Ignotas notaz@openpandora.org geschrieben:
Hi,
- However: They still need more force to react than on the
Pandora. Which reminded me: The Pandora touchscreen is pressure sensitive (255 values, if I remember correctly?)
It's closer to 16 I think.
Ah, okay, I thought it was more.
I'm not sure whether that's related to the touchscreen controller as well - how does this work on the Pandora?
Basically the same. Although Pandora OS does not have these parameters.
It's not only the OS, the controller (and hence the driver) is completely different I think? I don't think it is possible to influence the minimum sensitivity that makes it react (on Pandora).
Ah, so the sensitivity is simply being read out by that painting program (as I know we have one on the Pandora supporting pressure sensitivity).
Well, as it seems the new driver does support different sensitivity values, I have to try playing with them. Would be great having them configurable in the userspace for on-the-fly testing, but I don't think the driver supports that :)
Am Wed, 21 Sep 2016 19:41:09 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
- These touchscreens are ACCURATE without any jitter. All other
touchscreens tried before were jittering a lot - and I thought this was something to fix in the driver.
Well, the driver can only filter jitter and try to suppress it, but it reduces precision.
Oh, than this one seems to be a LOT better than all the other ones I tried. Great!
- However: They still need more force to react than on the Pandora.
Which reminded me: The Pandora touchscreen is pressure sensitive (255 values, if I remember correctly?) So this one should ALSO be pressure sensitive. Could it be that you can change the sensitivity in the driver?
The driver also reports pressure values - but only if you you press more than some minimum pressure. This is to support debouncing.
Good to know :)
That would explain why the touchscreen needs more force to react - even though it's the exact same as on the Pandora. Could someone check the driver to see whether there's some setting or whether it could be added?
Yes, there is a minimum pressure value. And the resistance of the touch should correctly been set or the pressure isn't calculated properly: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/pyra...
This means:
- touchscreen-max-pressure
- ti,max-rt
- ti,x-plate-ohms
must be matched with the touch.
Ah, but that's hardcoded in the driver, so you can't change the parameters without recompiling it, I guess.
Maybe we can do that when I visit you to work on the power supply weirdnesses (if we find the time).
Am 22.09.2016 um 12:35 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Wed, 21 Sep 2016 19:41:09 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
- These touchscreens are ACCURATE without any jitter. All other
touchscreens tried before were jittering a lot - and I thought this was something to fix in the driver.
Well, the driver can only filter jitter and try to suppress it, but it reduces precision.
Oh, than this one seems to be a LOT better than all the other ones I tried. Great!
- However: They still need more force to react than on the Pandora.
Which reminded me: The Pandora touchscreen is pressure sensitive (255 values, if I remember correctly?) So this one should ALSO be pressure sensitive. Could it be that you can change the sensitivity in the driver?
The driver also reports pressure values - but only if you you press more than some minimum pressure. This is to support debouncing.
Good to know :)
That would explain why the touchscreen needs more force to react - even though it's the exact same as on the Pandora. Could someone check the driver to see whether there's some setting or whether it could be added?
Yes, there is a minimum pressure value. And the resistance of the touch should correctly been set or the pressure isn't calculated properly: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/pyra...
This means:
- touchscreen-max-pressure
- ti,max-rt
- ti,x-plate-ohms
must be matched with the touch.
Ah, but that's hardcoded in the driver, so you can't change the parameters without recompiling it, I guess.
Yes, because the assumption is that plate resistance and max-pressure are constants and describe hardware.
Maybe we can do that when I visit you to work on the power supply weirdnesses (if we find the time).
Yes, we can try. Should not be too difficult.
BR, Nikolaus
Am Thu, 22 Sep 2016 13:06:52 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Ah, but that's hardcoded in the driver, so you can't change the parameters without recompiling it, I guess.
Yes, because the assumption is that plate resistance and max-pressure are constants and describe hardware.
Yes, these two parameters are. But some users might want the touchscreen to react with less pressure than others. So it's a sensitivity setting that's missing :)
Maybe we can do that when I visit you to work on the power supply weirdnesses (if we find the time).
Yes, we can try. Should not be too difficult.
Great.
Am 26.09.2016 um 11:36 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 22 Sep 2016 13:06:52 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Ah, but that's hardcoded in the driver, so you can't change the parameters without recompiling it, I guess.
Yes, because the assumption is that plate resistance and max-pressure are constants and describe hardware.
Yes, these two parameters are. But some users might want the touchscreen to react with less pressure than others. So it's a sensitivity setting that's missing :)
Well, Kernel is not prepared to provide that as a user-setting. But I guess it can be added in user-space.
Maybe we can do that when I visit you to work on the power supply weirdnesses (if we find the time).
Yes, we can try. Should not be too difficult.
Great.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am Thu, 15 Sep 2016 23:08:11 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
well, I tested this unit with the Non-Tiler SD Card I created with you and zmatt together via IRC, so that one should work.
I should've probably included it, but I can also upload you an image, if you like.
Yes, booting it can be quite horrible sometimes... some experiences I made:
* Often, if it doesn't want to boot, an fsck on both partitions on a normal PC helps.
* It also seems to hang if it can't connect to the display board properly - so if the flex cable is not properly inserted, it could also hang.
And as Tony also confirmed: Current kernels seem to be unstable with both the EVM and the Pyra. Something bad has been going on there...
since i've been having quite some problems getting the pyra to run without locking up constantly, could you give me a link (or a working makesd config) to a known working SD card image for my pyra prototype.
I did try making one with the makesd script, but all the "latest" links seems to have been last updated 5 months ago, and I get an image with a 4.6.0 kernel. I also don't know which .dtb to use on this one, since there are quite a few to choose from, and i'm also not sure about which lcd panel config this one needs.
That way i'd at least know if the problems i'm seeing are just part of the prototype, or part of my messing about with kernels/u-boot/xorg configs/etc. _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-
Andrey Utkin -
aTc -
Grazvydas Ignotas -
Grazvydas Ignotas -
H. Nikolaus Schaller -
Matthijs van Duin -
Michael Mrozek