[mk01]

(4th Jul, 2014 01:46 AM)CurlyMo Wrote:  1) Put the linux-image-3.10.30-armmp package on hold so it doesn't get upgraded.

what should this one specifically be useful for ?

---

@IriDium,

As part of the HUGE change which is ongoing we have to rebuild a different APT structure - this is one moment of yours one minute it goes another not

As part of the img auto-builders, we are currently updating ~half of packages for dependencies and helper scripts. So i'm quite surprised you updated at all.

Code:

there are package renames for cubox:
xbian-package-firmware-6q -> firmware-imx
xbian-package-imx-lib -> libimx
xbian-package-libfslvpuwrap-6q -> libfslvpuwrap

I'm creating transition packages for them but until they are published if other package requires new name -> old will be going to be removed and if it was listed as Required apt-get will ask the magic question about removing essential package.

Until result of that action is remove only of that one particular package, it is ok and confirm. If it would launch cascade effect trying to remove 100 packages, report it.

if you want freq img, follow wiki and create it. Or grab this one
http://ivka57.dyndns-ip.com/images/xbian-image-imx6-20140703.img.xz

but so far only RPI img was tested. I have no idea for imx6 if it even boots.
report

[CurlyMo]

The latest kernel made my HB i2eX unbootable.

[IriDium]

Well after last upgrade and reboot - system has become unstable.

Everything was fine and then nothing:

Last dmesg"

[ 874.957726] btrfs: ERROR did not find backref in send_root. inode=276, offset=0, disk_byte=12582912 found extent=12582912
[ 1712.217103] device label xbian devid 1 transid 1773 /dev/mmcblk0p2
[ 1716.300582] BTRFS debug (device mmcblk0p2): unlinked 1 orphans
[ 5142.751504] init: xbian-xbmc-bridge main process ended, respawning
[ 5143.221750] init: xbmc main process (1399) terminated with status 129
[ 5146.640181] init: wait-for-state (xbmcxbmc-loaded) main process (7683) killed by TERM signal

Restart of xbmc (No reboot) and all seems fine.

I'll test the new image tomorrow and let you know.

[CurlyMo]

Kernel 3.10.30 has in general a lot of issues. Also confirmed by Rabeeh.

[belese]

i've got same problem as irridium with last update for xbmc (from yesterday, but the today update is the same) on cubox (devel repo)
but have to check a bit more, as i can't start xbmc from ssh too.
but don't remember to have seen btrfs errors

[mk01]

(4th Jul, 2014 02:48 AM)CurlyMo Wrote:  Kernel 3.10.30 has in general a lot of issues. Also confirmed by Rabeeh.

yes.

and 3.0.35 can't make use of the hw

so pick one

---

@belese @IriDium

as you ask from users at least basic info, consider sending the same.
in past week there was rebuilded / repatched / repushed maybe 200 versions of packages. do you believe your "last" and your "yesterday" your "that package" is the same as mine ?

regarding the btrfs error - it can be caused by update to xbianhome package which is used to deliver initial /home/xbian content. but during upgrade it let's apt to "overwrite" some files - by snapshoting the running content, removing "new" after and renaming "backup" to running.

from all aspects this is safe even with running XBMC, but that was BTRFS but back then causing BTRFS to complain way like this - as runnning (1) gets snapshoted (2), then (1) removed and (2) renamed to (1). logically (2) being (1) is missing parent (back reference to original root (send_root)) - informations which are used for instance during incremental FS send.

it was fixed later in 3.11 or 3.12 (you see that RPI is not throwing that error). even in the times when RPI was at 3.10 I remember this - never caused any harm. it is really just untracked situation for this version of BTRFS.

Anyhow I'm slowly backporting btrfs from 3.14 . And because CurlMo now know about all problems with 3.10 he will help too so the work will go faster

[belese]

You look happy with kernel ;-)

but maybe my it's not related to kernel,
since 2 or 3 days (since i've try to install xbian x package), and was autoremoved later with an update (
EDIT : i believe it's when firmware-imx was replaced by xbian-package firmware, and xbian-package-xserver-xorg-video-vivante-6q depend of firmware-imx ). ,
i've got an error in xbian-update :

Code:

...
patching files
/usr/local/lib/xbmc/xbmc.bin: error while loading shared libraries: libGLESv2.so.2: cannot open shared object file: No such file or directory
/var/lib/dpkg/info/xbian-update.postinst: line 775: [: : integer expression expected
patching polkit
...

and i don't find theses libraries in /opt/vc/lib
and in dmesg :

Code:

[  212.305824] init: wait-for-state (xbmcxbmc-loaded) main process (2313) terminated with status 100
[  212.342059] init: xbmc post-start process (2308) terminated with status 1
[  212.890984] init: xbmc main process (3379) terminated with status 127
[  312.880500] init: wait-for-state (xbmcxbmc-loaded) main process (3382) terminated with status 100

so i wan't to install libgles2-mesa, (maybe i'm too naive)
but it want to uninstall quite all xbian package,

i've try to reinstall xbmc and xbmc script, but nothing help for now.

otherwise, xbian run very smooth on my cubox, thanks again for your job

the problem i've got
bluetooth, but i think it's more general, but i don't catch yet rabeeh on irc
i've some problem with pvr and tvheadend, xbmc crahs often, but it's happen also on my pc with ubuntu and the 13.1 xbmc. so more related on xbmc.
some problem with dvi resolution when i restart the projector, i've to restart xbmc to have a correct screen.

[CurlyMo]

Rabeeh told me the kernel issues of 3.10.30 should be fixed within a week... Let's hope so. I understand 3.0.35 is not an option. Just informing that some issues could be related to that. Also consider that i'm only able to test on a Hummingboard i2eX which has a lot of features the other CuBoxes don't have.

[mk01]

(4th Jul, 2014 02:27 AM)CurlyMo Wrote:  The latest kernel made my HB i2eX unbootable.

unbootable you mean HDMI is not initialised (black screen) & stuck ?

I was rolling out yesterday next group of patches and as I see now one of them was reverting my fix around that. I disabled that patch so if it is your case it will be fixed in next compile round.

[CurlyMo]

Unbootable always means unable to ping, i don't have a HDMI capable device.

[mk01]

(4th Jul, 2014 07:37 AM)CurlyMo Wrote:  Rabeeh told me the kernel issues of 3.10.30 should be fixed within a week... Let's hope so. I understand 3.0.35 is not an option. Just informing that some issues could be related to that. Also consider that i'm only able to test on a Hummingboard i2eX which has a lot of features the other CuBoxes don't have.

@CurlyMo

and I'm just telling you that we all are fixing those past current and future bugs since the first release (Feb? 2014). unfortunately this is never ending process.

only final solution would be vivante hitting their secrets to upstream. and even then some odds will remain. with "fixes" more be called "hacks" - because of various things (for instance HDMI/nHDMI problems of HW signals and HW design - tiny things with huge impacts).

most probably nobody here will report a completely "new" issue to me. this is the way of things. and regardless of reported ETA (1w, 1m, 1y) it will be longer run. but despite that it still makes sense as there is no other HW closer to "IDEAL".

---

(4th Jul, 2014 07:49 AM)CurlyMo Wrote:  Unbootable always means unable to ping, i don't have a HDMI capable device.

yes, that's it. currently is HELIX building and kernel is forced after so within 1h it will hit devel repo.

[CurlyMo]

There are bugs and there are Bugs (with a capital B).

By Bugs i mean:
- GPIO not working at all (and therefor also no IR).
- No audio source selectable in XBMC. XBMC even hangs a while when scrolling to the audio settings menu's.
- Adding console parameters makes the system unbootable.
- For having HDMI to VGA + Audio i need to add the adapter after the network is back up. Else the sound is not passed to the HDMI.
- mini-pcie not working

And for a development board, i consider the totally unfunctional GPIO a major bug.

[mk01]

@CurlyMo

you are kicking wrong grave there.
I really don't feel like Encyclopedia Britannica to repeat the same over and over again or to explain simple consequences A -> B -> C. You showed many times before ability to Read and Study so maybe this should be followed most time before rushing bugs and BUGS.

Specially for you I wrote:

Code:

because of various things (for instance HDMI/nHDMI problems of HW signals and HW design - tiny things with huge impacts)

Three of your BUGS are simply consequence of that. How the FB driver is initialised, clocks started and stopped, pins handled and IRQs/events being generated.
I will not go into details because anyhow you are not interested. Otherwise this brave discussion about Bugs(B) would not be there.
You got the device for free as a community developer so don't ask the community when the functionality will be delivered to YOU.

You can rebase my work (my repo, imx6 kernel, DVI branch) which was even part of standard XBian Cubox-i kernel and looked promising. I stopped on DVI events test (as I don't have real DVI device - only HDMI with DVI port and that is pushing HDMI edid to it so my testing would be not conclusive for FSCs FB HDMI implementation) and another developer told me he has completely different and more straight forward solution - that happened maybe 6-8w ago. That code is not 100% perfect - at kernel level there are some overflow events - but not affecting userspace. Despite that it was miles ahead of current (stable) status of the kernel.

Feel free to continue. There are many options how-to also on another ©Bugs(with a capital B) front.
1) be checking FSC development (don't take it as main source tree with fixing needed - it mostly even don't boot at all - but you can find some working parts there and try to backport / rebase
2) follow upstream (vanilla) imx6 fixes/changes/development. I told you yesterday most of DTB code and stuff is pushed there. So find the right patches and backport - this could be targeted to GPIO, Radios(BT/WIFI), SDHCI and maybe others.

I did great part of CMA from 3.14 and have in testing kernel/irq parts backporting to allow newer drivers to run (for instance things around DRM). There are so many ways how to show your anticipation.

[CurlyMo]

Quote:I really don't feel like Encyclopedia Britannica to repeat the same over and over again or to explain simple consequences A -> B -> C.

1. I hope you understand it's quite a waste of time to try to figure out what has been happening in the last couple of months and i'm also not very motivated to figure that out. Sadly, i only got a HummingBoard / CuBox-i (already being on route for over a month) as of last week so i wasn't that lucky to step in earlier. I want to able to contribute from were we are now and the only thing i know is that these Bugs are there, and someone has to talk me through the process already done. I just see big consequences and have not had the time to see the small issues that caused them.

Quote:Three of your BUGS are simply consequence of that. How the FB driver is initialised, clocks started and stopped, pins handled and IRQs/events being generated. I will not go into details because anyhow you are not interested.

Then you will not get me on route here.

2. I believe i'm one of the first to get hand of a HummingBoard (here). That device is pretty different than the standard CuBoxes. So we can't just generalize the progress to done from februari to all devices.

It's not any different than in any other company. Some people start working on a project. Another one steps in. The ones already working will definitely not say "You have access to our intranet. Please figure out for yourself what we have done until know". They would instead say "Here are the reports on the stuff we already did. Please read it to get in sync. And start contributing."

Simple example. SolidRun states that the HummingBoard is pin compatible to the Raspberry Pi. So i assume i can just use the same BCM pin numbering as posted here: https://projects.drogon.net/raspberry-pi/wiringpi/pins/. I connected a led to BCM 17 and GND. Tried to light it up but it didn't work. There is no documentation on the GPIO internals so i asked. Pin compatible is not that compatible. The numbering is as follows:

Code:

RPi 7,11,12,13,15,16, 18, 22
HB  1,73,72,71,70,194,195,67

Ok. Wierd. Then they told me i can't use pin 17, because it is reserved for other stuff. There you have GPIO compatibility . I could of course make a loop to test all GPIO pins but someone simply telling me the mapping is a lot quicker. Eventually the GPIO didn't work at all. How could i have tested something like that when i don't even know what the GPIO numbers are?

[IriDium]

@mk01 Image http://ivka57.dyndns-ip.com/images/xbian-image-imx6-20140703.img.xz

Doesn't boot :-) - No boot.scr or Uenv.txt

Copied boot.scr from a working SD card - tried again
"Wrong Ramdisk Image Format"
** File not found /boot/boot.scr
/boot/uEnv.txt
/boot/zImage
/boot/uImage

Try's endlessly to boot from the Net.