#cubox irc log of Fri 07 Feb 2014

IRC log of #cubox of Fri 07 Feb 2014. All times are in CET < Back to index

13:25 hste_ My isp called me and told me they had had some problems with a cable and they would compensite that with giving me 70/10 instead of 70/5 without paying extra :) I hadn't even noticed the problem

13:26 _rmk_ I wish my ISP would offer me something better than 8.3/0.5

13:29 liok 13:29 * lioka .oO feels good with 100/100

13:30 hste_ _rmk_ first they wanted to give me a hd-pvr but I told them I didn't need it since I don't have a hd-tv then they asked if I wanted 5Mbit extra instead :)

13:34 dxtr I have 100/100Mbps

13:35 dxtr And I can get 1000/100Mbps

13:39 MarcusVinter ive got 400kbit/s down and like 100kbit up lol

13:41 jnettle 13:41 * jnettlet is fine with 40-50/5

13:41 jnettlet could get more, but don't need it for the extra money

13:42 _rmk_ I can't get anymore - not without going to dodgy cable (at which point I'll be subject to transparent proxies and other silliness)

14:31 mk01 hello everyone

14:33 mk01 is there a reason why sound card 1 (hdmisoc) is not working if "video=mxcfb0:dev=hdmi" is not specified on kernel command line

14:33 mk01 ?

14:38 jnettlet mk01, yes. You need to init the video signal over hdmi before you can add audio.

14:42 _rmk_ ... because audio is embedded into the data islands created inside the video blanking periods

14:43 _rmk_ so unless the video path is configured, you can't pass audio

14:52 mk01 _rmk_ I understand that, bug clearly kernel configures HDMI video path later, including EDID fetch etc. audio is configured later in the go. this is for sure not technical limitation. it looks more like a bug or programmer shortcut

14:54 mk01 _rmk_ and is clear if you use HARD specs for hdmi, you don't get resolutions info

15:06 mk01 _rmk_ re "bug clearly kernel configures HDMI video path later, including EDID fetch etc" => also without hdmi specification during kernel load, HDMI is properly configured, audio goes later and imx-hdmi-soc is configured the same way.

15:27 _rmk_ mk01: well, you're using the framebuffer driver - I've no idea how any of that stuff works. DRM is the future :)

15:33 mk01 _rmk: I could be funny the same way and ask how this connects to the non-working audio

15:33 dv 15:33 * dv_ recalls _rmk_'s struggles with IPU and DRM

15:37 _rmk_ mk01: because the entire video configuration and audio hookups are /totally/ different between the framebuffer implementation and the DRM implementation

15:37 _rmk_ it's totally different code

15:39 _rmk_ mk01: I know the DRM implementation inside out, because I've put significant effort into reworking it. I haven't looked at even one line of the framebuffer code, but what I do know is that none of that code is shared.

15:39 jnettlet mk01, we are spending all our available resources working on the future codebases. Perhaps we will backport some of those patches into 3.0.35 at a later time. The only developer here that has really worked with the 3.0.35 codebase is rabeeh.

15:40 _rmk_ so now, how about /you/ stop being funny and pissing me off

15:40 jnettlet that code is almost all from freescale

15:43 mk01 jnettlet: I know. and please don't backport to 3.0.35. nobody wants that kernel. but the situation is obvious - newer is not available so we are fighting with what;s available

15:44 mk01 a statements go for DRM - which has not been made available - will not help the situation ;)

15:44 mk01 a = and

15:47 _rmk_ mk01: are you trying to provoke a fight - because you're going the right way about it.

15:48 _rmk_ the code /is/ available, it's been on the web since the hummingboard was first released

15:48 _rmk_ it's been posted on linux mailing lists around Christmas time for review for acceptance into mainline as well

15:48 mk01 _rmk_ with working DRM ?

15:48 _rmk_ some bits of it /have/ gone into mainline already

15:49 _rmk_ mk01: ever since I received my hummingboard, I've been booting with DRM - that's the last 4 months now.

15:49 _rmk_ jnettlet has taken that work and backported it into 3.10

15:49 _rmk_ so now, don't you dare say that it's "not been made available"

15:49 mk01 and Vivante support ?

15:49 jnettle 15:49 * jnettlet +1

15:50 jnettlet the updated kernel that irons out some bugs will be out very soon now that I have a CBi to test on again.

15:50 _rmk_ no vivante support because that's not going to be part of the DRM KMS driver, that's going to be a separate DRM Vivante acceleration driver which can be re-used between Dove and IMX - but the problem is its all closed source and etnaviv needs serious effort put into it

15:51 crypt0s _rmk_: Does all that mean I shouldn't be trying to run the new 3.13.1 kernel on the Cubox-i?

15:51 _rmk_ and if /I/ put the amount of effort into etnaviv that it requires, then I'm /not/ doing kernel stuff, and I'm /not/ pushing stuff upstream, and I'm /not/ working on what I'm employed to do either.

15:52 _rmk_ jnettlet and myself are volunteers here, we're doing what we can do as our time permits. We're not getting any payment to support any of this.

15:56 mk01 _rmk_ you are taking this too much personally. don't do that please. I know exactly how the situation is - that's why I asked how can we solved the sound problem with 3.0.35. and obviously not "when _rmk_ finally does something that it finally works". sp once again PLEASE, we are on the same side here.

16:03 dv_ _rmk_: perhaps we should set up some kind of donation system

16:04 dv_ somebody here already suggested this I think

16:06 _rmk_ dv: that's not the issue... it's more that the available time doesn't let us do everything that even we would like to do.

16:06 _rmk_ I'm trying at the moment to work out what's going on with UHS SD cards - my card won't accept the voltage switch to 1.8V

16:06 _rmk_ meanwhile, jnettlet is looking at the same issue, but his card does accept the voltage switch

16:07 _rmk_ and I've been looking at this for the last 4 or so hours - sorting through trying to work out why stuff doesn't work with imx6 CPUs is /very/ time consuming.

16:08 hste_ _rmk_ does it differ if u both run the same kernel also?

16:14 dv_ _rmk_: sure, but it would be useful eventually, for material costs like sd cards, displays etc.

18:50 _rmk_ okay, the UHS-1 card story is not good... and we're coming to the conclusion that the voltage switch to 1.8V can't be supported with an iMX6 host... at least at the moment. Investigations will probably continue, but for the time being we haven't been able to get it working.

18:51 _rmk_ what that means is: we're putting it on the back burner and dropping it as a priority.

18:51 _rmk_ so, UHS-1 cards will only be driven in standard mode.

18:54 _rmk_ my personal opinion is that the SDHCI code in the kernel has been hacked on by multiple different people without an "overview" of what's been going on, so the result is a collection of hacks - at least one of those hacks places the voltage switching sequence out of spec. Fixing it is going to be on the level of a rewrite of chunks of that driver, which I haven't got the bandwidth for.

18:59 _rmk_ now, I need to get back to the component support for the Dove, before JFM completely screws that up by trying to lever DT support into that helper, where it's just not needed.

19:00 _rmk_ hmm, let's think about this: it was developed on imx-drm, which is DT based, and works with DT already... why would it need to have DT crap in it to make it work with DT when it already does.

21:13 dv_ _rmk_: sounds like the "left hand does not know what the right hand is doing"-syndrome

21:15 _rmk_ dv: no, JFM just likes to work in areas I've already got code for

21:16 dv_ uh..why?

21:16 dv_ does he think he can do it better?

21:16 dv_ sounds like a very stupid idea to spend the spare time

21:17 _rmk_ dv: well, I managed to get the ASoC stuff sorted at the kernel summit, and ever since Mark has been taking patches from JFM which has totally screwed all that effort

21:18 dv_ oh. sigh..

21:18 _rmk_ I've basically turned round to Mark and said that if he wants my code, he _has_ to ask me to send it to him now... I'm not chasing his constantly moving bullet any longer

21:18 _rmk_ and he has to give me time to prepare it

21:24 _rmk_ right, hopefully that's JFM dealt with

22:28 FrenchW Hi !

22:29 FrenchW Could someone point me to a place where I could have some help with my cubox ? (not dev related)

22:29 FrenchW just receive mine and it looks bricked from bricked ...

22:54 FrenchW could someone help me ?

22:57 _rmk_ FrenchW: which model is it?

22:59 FrenchW hi

23:00 FrenchW i4-Pro

23:00 FrenchW nothing heppens at boot time

23:00 dv_ note that without a properly set up u-boot, you will see zero activity

23:00 dv_ not one byte output over UART

23:00 FrenchW nothingn happens when booting on the serial to unbrick via XMODEM

23:01 _rmk_ FenchW: you have an SD card inserted with u-boot installed?

23:02 FrenchW not yet

23:02 FrenchW was supposed to do thins after booting, in install mode not ? just followed those steps at last : http://www.solid-run.com/mw/index.php/Unbricking_CuBox

23:02 _rmk_ it needs the SD card in order to do anything.

23:03 _rmk_ ignore that, that's for the Dove based Cubox

23:03 _rmk_ The Cubox-i* have no on-board memory, they do nothing without the SD card installed with u-boot on

23:03 FrenchW OK, but I've not purshased the card, How am I supposed the prepare the sdcard ? FAT32 and /boot from the installer ?

23:04 davorin_away there is no installer for i-models

23:04 davorin_away "dd" is your friend (o;

23:04 FrenchW on the installer pagen they say to boot on a USB storage with FAT32 and the /boot from the installer

23:05 davorin_away http://imx.solid-run.com/wiki/index.php?title=Main_Page

23:05 davorin_away this is the right wiki

23:06 FrenchW so, what can I do with the sdcard .. with the help of my windows ? ;-)

23:06 _rmk_ http://imx.solid-run.com/wiki/index.php?title=Flash_an_image

23:07 xraxor Win32 Disk imager to send image to sd... :)

23:08 FrenchW thanks, I'll check this page

23:08 FrenchW will try and tell you back

23:08 FrenchW thanks

23:25 FrenchW Hi, cool, that works. You pointed me to the right good page. I'm booting the mini installer while downloading android, ubuntu ans geexbox images (I've 3 SDCard)

13:25	hste_	My isp called me and told me they had had some problems with a cable and they would compensite that with giving me 70/10 instead of 70/5 without paying extra :) I hadn't even noticed the problem
13:26	_rmk_	I wish my ISP would offer me something better than 8.3/0.5
13:29	liok	13:29 * lioka .oO feels good with 100/100
13:30	hste_	_rmk_ first they wanted to give me a hd-pvr but I told them I didn't need it since I don't have a hd-tv then they asked if I wanted 5Mbit extra instead :)
13:34	dxtr	I have 100/100Mbps
13:35	dxtr	And I can get 1000/100Mbps
13:39	MarcusVinter	ive got 400kbit/s down and like 100kbit up lol
13:41	jnettle	13:41 * jnettlet is fine with 40-50/5
13:41	jnettlet	could get more, but don't need it for the extra money
13:42	_rmk_	I can't get anymore - not without going to dodgy cable (at which point I'll be subject to transparent proxies and other silliness)
14:31	mk01	hello everyone
14:33	mk01	is there a reason why sound card 1 (hdmisoc) is not working if "video=mxcfb0:dev=hdmi" is not specified on kernel command line
14:33	mk01	?
14:38	jnettlet	mk01, yes. You need to init the video signal over hdmi before you can add audio.
14:42	_rmk_	... because audio is embedded into the data islands created inside the video blanking periods
14:43	_rmk_	so unless the video path is configured, you can't pass audio
14:52	mk01	_rmk_ I understand that, bug clearly kernel configures HDMI video path later, including EDID fetch etc. audio is configured later in the go. this is for sure not technical limitation. it looks more like a bug or programmer shortcut
14:54	mk01	_rmk_ and is clear if you use HARD specs for hdmi, you don't get resolutions info
15:06	mk01	_rmk_ re "bug clearly kernel configures HDMI video path later, including EDID fetch etc" => also without hdmi specification during kernel load, HDMI is properly configured, audio goes later and imx-hdmi-soc is configured the same way.
15:27	_rmk_	mk01: well, you're using the framebuffer driver - I've no idea how any of that stuff works. DRM is the future :)
15:33	mk01	_rmk: I could be funny the same way and ask how this connects to the non-working audio
15:33	dv	15:33 * dv_ recalls _rmk_'s struggles with IPU and DRM
15:37	_rmk_	mk01: because the entire video configuration and audio hookups are /totally/ different between the framebuffer implementation and the DRM implementation
15:37	_rmk_	it's totally different code
15:39	_rmk_	mk01: I know the DRM implementation inside out, because I've put significant effort into reworking it. I haven't looked at even one line of the framebuffer code, but what I do know is that none of that code is shared.
15:39	jnettlet	mk01, we are spending all our available resources working on the future codebases. Perhaps we will backport some of those patches into 3.0.35 at a later time. The only developer here that has really worked with the 3.0.35 codebase is rabeeh.
15:40	_rmk_	so now, how about /you/ stop being funny and pissing me off
15:40	jnettlet	that code is almost all from freescale
15:43	mk01	jnettlet: I know. and please don't backport to 3.0.35. nobody wants that kernel. but the situation is obvious - newer is not available so we are fighting with what;s available
15:44	mk01	a statements go for DRM - which has not been made available - will not help the situation ;)
15:44	mk01	a = and
15:47	_rmk_	mk01: are you trying to provoke a fight - because you're going the right way about it.
15:48	_rmk_	the code /is/ available, it's been on the web since the hummingboard was first released
15:48	_rmk_	it's been posted on linux mailing lists around Christmas time for review for acceptance into mainline as well
15:48	mk01	_rmk_ with working DRM ?
15:48	_rmk_	some bits of it /have/ gone into mainline already
15:49	_rmk_	mk01: ever since I received my hummingboard, I've been booting with DRM - that's the last 4 months now.
15:49	_rmk_	jnettlet has taken that work and backported it into 3.10
15:49	_rmk_	so now, don't you dare say that it's "not been made available"
15:49	mk01	and Vivante support ?
15:49	jnettle	15:49 * jnettlet +1
15:50	jnettlet	the updated kernel that irons out some bugs will be out very soon now that I have a CBi to test on again.
15:50	_rmk_	no vivante support because that's not going to be part of the DRM KMS driver, that's going to be a separate DRM Vivante acceleration driver which can be re-used between Dove and IMX - but the problem is its all closed source and etnaviv needs serious effort put into it
15:51	crypt0s	_rmk_: Does all that mean I shouldn't be trying to run the new 3.13.1 kernel on the Cubox-i?
15:51	_rmk_	and if /I/ put the amount of effort into etnaviv that it requires, then I'm /not/ doing kernel stuff, and I'm /not/ pushing stuff upstream, and I'm /not/ working on what I'm employed to do either.
15:52	_rmk_	jnettlet and myself are volunteers here, we're doing what we can do as our time permits. We're not getting any payment to support any of this.
15:56	mk01	_rmk_ you are taking this too much personally. don't do that please. I know exactly how the situation is - that's why I asked how can we solved the sound problem with 3.0.35. and obviously not "when _rmk_ finally does something that it finally works". sp once again PLEASE, we are on the same side here.
16:03	dv_	_rmk_: perhaps we should set up some kind of donation system
16:04	dv_	somebody here already suggested this I think
16:06	_rmk_	dv: that's not the issue... it's more that the available time doesn't let us do everything that even we would like to do.
16:06	_rmk_	I'm trying at the moment to work out what's going on with UHS SD cards - my card won't accept the voltage switch to 1.8V
16:06	_rmk_	meanwhile, jnettlet is looking at the same issue, but his card does accept the voltage switch
16:07	_rmk_	and I've been looking at this for the last 4 or so hours - sorting through trying to work out why stuff doesn't work with imx6 CPUs is /very/ time consuming.
16:08	hste_	_rmk_ does it differ if u both run the same kernel also?
16:14	dv_	_rmk_: sure, but it would be useful eventually, for material costs like sd cards, displays etc.
18:50	_rmk_	okay, the UHS-1 card story is not good... and we're coming to the conclusion that the voltage switch to 1.8V can't be supported with an iMX6 host... at least at the moment. Investigations will probably continue, but for the time being we haven't been able to get it working.
18:51	_rmk_	what that means is: we're putting it on the back burner and dropping it as a priority.
18:51	_rmk_	so, UHS-1 cards will only be driven in standard mode.
18:54	_rmk_	my personal opinion is that the SDHCI code in the kernel has been hacked on by multiple different people without an "overview" of what's been going on, so the result is a collection of hacks - at least one of those hacks places the voltage switching sequence out of spec. Fixing it is going to be on the level of a rewrite of chunks of that driver, which I haven't got the bandwidth for.
18:59	_rmk_	now, I need to get back to the component support for the Dove, before JFM completely screws that up by trying to lever DT support into that helper, where it's just not needed.
19:00	_rmk_	hmm, let's think about this: it was developed on imx-drm, which is DT based, and works with DT already... why would it need to have DT crap in it to make it work with DT when it already does.
21:13	dv_	_rmk_: sounds like the "left hand does not know what the right hand is doing"-syndrome
21:15	_rmk_	dv: no, JFM just likes to work in areas I've already got code for
21:16	dv_	uh..why?
21:16	dv_	does he think he can do it better?
21:16	dv_	sounds like a very stupid idea to spend the spare time
21:17	_rmk_	dv: well, I managed to get the ASoC stuff sorted at the kernel summit, and ever since Mark has been taking patches from JFM which has totally screwed all that effort
21:18	dv_	oh. sigh..
21:18	_rmk_	I've basically turned round to Mark and said that if he wants my code, he _has_ to ask me to send it to him now... I'm not chasing his constantly moving bullet any longer
21:18	_rmk_	and he has to give me time to prepare it
21:24	_rmk_	right, hopefully that's JFM dealt with
22:28	FrenchW	Hi !
22:29	FrenchW	Could someone point me to a place where I could have some help with my cubox ? (not dev related)
22:29	FrenchW	just receive mine and it looks bricked from bricked ...
22:54	FrenchW	could someone help me ?
22:57	_rmk_	FrenchW: which model is it?
22:59	FrenchW	hi
23:00	FrenchW	i4-Pro
23:00	FrenchW	nothing heppens at boot time
23:00	dv_	note that without a properly set up u-boot, you will see zero activity
23:00	dv_	not one byte output over UART
23:00	FrenchW	nothingn happens when booting on the serial to unbrick via XMODEM
23:01	_rmk_	FenchW: you have an SD card inserted with u-boot installed?
23:02	FrenchW	not yet
23:02	FrenchW	was supposed to do thins after booting, in install mode not ? just followed those steps at last : http://www.solid-run.com/mw/index.php/Unbricking_CuBox
23:02	_rmk_	it needs the SD card in order to do anything.
23:03	_rmk_	ignore that, that's for the Dove based Cubox
23:03	_rmk_	The Cubox-i* have no on-board memory, they do nothing without the SD card installed with u-boot on
23:03	FrenchW	OK, but I've not purshased the card, How am I supposed the prepare the sdcard ? FAT32 and /boot from the installer ?
23:04	davorin_away	there is no installer for i-models
23:04	davorin_away	"dd" is your friend (o;
23:04	FrenchW	on the installer pagen they say to boot on a USB storage with FAT32 and the /boot from the installer
23:05	davorin_away	http://imx.solid-run.com/wiki/index.php?title=Main_Page
23:05	davorin_away	this is the right wiki
23:06	FrenchW	so, what can I do with the sdcard .. with the help of my windows ? ;-)
23:06	_rmk_	http://imx.solid-run.com/wiki/index.php?title=Flash_an_image
23:07	xraxor	Win32 Disk imager to send image to sd... :)
23:08	FrenchW	thanks, I'll check this page
23:08	FrenchW	will try and tell you back
23:08	FrenchW	thanks
23:25	FrenchW	Hi, cool, that works. You pointed me to the right good page. I'm booting the mini installer while downloading android, ubuntu ans geexbox images (I've 3 SDCard)