| 23:59 | MikeSeth | meh, crda doesn't help, guess I will have to force the channel on AP side |
| 00:01 | sraue | [OpenELEC.tv] sraue pushed 1 new commit to master: http://git.io/nC0A5g |
| 00:01 | sraue | OpenELEC.tv/master 24a0183 Stephan Raue: projects: add initial project 'Cuboxi'... |
| 00:01 | sraue | ^^^ :-) |
| 00:01 | sraue | http://snapshots.openelec.tv/OpenELEC-Cuboxi.arm-devel-20140122235627-r17121-g24a0183.tar if anyone want try (needs still a manual install) |
| 00:06 | rabeeh | sraue: great work :) |
| 00:07 | sraue | no problem hope it works :-) and we can solve the remaining problems |
| 00:07 | kalasmannen | sraue: nice, thanks |
| 00:08 | MikeSeth | brcmxmac drivers in early 3.0s have a ton of issues, gimme a new kernel! |
| 00:10 | rabeeh | MikeSeth: the issue with newer drivers is that they don't build ok with 3.0.35 |
| 00:10 | rabeeh | also monitor mode is not supported in that driver |
| 00:11 | MikeSeth | rabeeh: oh, I can live with the current ones, no problem |
| 00:11 | MikeSeth | brcmsmac was broken until 3.8, brcmfmac... probably still broken |
| 00:12 | rabeeh | in the kernel we use brcm80211 driver |
| 00:12 | rabeeh | but an older version of it |
| 00:12 | _rmk_ | hmm, wonder what package i2cdump is in... |
| 00:14 | _rmk_ | oh, that's why I can't find it, they called it lm-sensors not lm_sensors |
| 00:17 | rabeeh | _rmk_: thanks |
| 00:19 | _rmk_ | tsk, they haven't packaged it with lm-sensors |
| 00:20 | _rmk_ | in fact, lm-sensors is missing most of the utilities |
| 00:21 | rabeeh | _rmk_: which reminds me why Freescale didn't even hook the temperature sensor to the standard lm-sensors interface. |
| 00:22 | _rmk_ | got it |
| 00:23 | _rmk_ | http://ur1.ca/ghf1d |
| 00:32 | otavio | dv_: did you rework the patches? |
| 02:36 | dv_ | otavio: rebuilding the rootfs to test them out |
| 02:37 | dv_ | otavio: I think the image-types-fsl change is even easier. there is a switch-case inside, depending on ${IMAGE_BOOTLOADER} |
| 02:37 | dv_ | all I have to do is add a case for "u-boot-spl" |
| 02:38 | dv_ | which means just the two dd calls I was using in my custom class. the rest is identical anyway |
| 02:39 | otavio | dv_: yes |
| 02:39 | otavio | but the binary is u-boot-spl? |
| 02:39 | otavio | it is SPL no? |
| 02:40 | dv_ | thats not the SPL filename |
| 02:40 | dv_ | https://github.com/Freescale/meta-fsl-arm/blob/master/classes/image_types_fsl.bbclass#L112 |
| 02:41 | dv_ | also look up line 3 |
| 02:42 | otavio | You can't do it like this |
| 02:42 | otavio | https://github.com/Freescale/meta-fsl-arm/blob/master/classes/image_types_fsl.bbclass#L69 |
| 02:43 | otavio | this is the depends |
| 02:43 | otavio | so use u-boot and inside of the u-boot case check SPL_BINARY |
| 02:43 | dv_ | oh. |
| 02:43 | dv_ | didnt see that |
| 02:46 | dv_ | ok, corrected. its building now. I go to sleep. ttyl |
| 02:48 | otavio | :) |
| 03:07 | cbuser | hello |
| 03:08 | cbuser | whats the best way to reset a corrupted uboot environment having only the packaged shipped sdcard at hand ... i install uboot-envtools but there is no mtd device on the factory image |
| 03:12 | cbuser | the hardware is a CuBox-i2ultra |
| 03:57 | cbuser | got it ... used the xmodem instructions from the wiki for minicom to fix the faulty uboot variable |
| 08:06 | jnettlet | rabeeh, morning. Do you have any good ideas of a simple way to force the CBi to go into "developer/recovery" mode via hardware? I am not sure if the USB stack will fit in SRAM. |
| 08:09 | jnettlet | I guess I could look for a .recovery on the first partition and load the second stage of barebox if that exists. Then it would just be a matter of taking the SDHC card out and writing a file to it from another computer. |
| 09:35 | davorin | huomenta (o; |
| 09:53 | MikeSeth | finn detected |
| 09:53 | davorin | (o; |
| 09:53 | MikeSeth | "huomenta" is official for the PHP framework I use |
| 09:53 | davorin | was just working 3 years up north... |
| 09:53 | MikeSeth | official greeting I mean |
| 12:28 | rabeeh | jnettlet: if i.MX6 can't boot from the boot device (SD2 in our case); it will go to serial downloader |
| 12:29 | rabeeh | serial downloader is where the i.MX6 puts the USB OTG in device mode; emulating HID and waits for instructions from a USB host that you can connect to. |
| 12:30 | jnettlet | the CBi supports device-mode without software configuration? |
| 12:30 | rabeeh | by default if the chip is not programmed to boot from a source (new chip that was not fused) then it will go to serial downloader; and this is btw how we do the manufacturing process |
| 12:31 | jnettlet | but you need an OTG cable |
| 12:31 | rabeeh | jnettlet: you need an OTG cable; or Rabeeh cable :) |
| 12:31 | rabeeh | Rabeeh cable (TM) is a host to host cable but with the vbus connected from the PC to the CuBox-i via a serial 100 ohm resistor |
| 12:32 | jnettlet | okay |
| 12:32 | rabeeh | _rmk_: so your RTC is running fine then. |
| 12:33 | rabeeh | jnettlet: what are you trying to achieve? |
| 12:34 | rabeeh | what is this recovery mode? Android style recovery? |
| 12:35 | jnettlet | rabeeh, just thinking of ways to gracefully handle fallback from a "production" mode of going from SRAM -> Linux to SRAM -> second stage bootloader. |
| 12:35 | jnettlet | something similar. I guess we could have a blessed kernel image and initramfs to load. |
| 12:37 | _rmk_ | rabeeh: do you have some which aren't? |
| 12:37 | jnettlet | I guess controlling the front LED for error reporting is a good first step. |
| 12:37 | rabeeh | _rmk_: i have one that somehow the OS bit sometimes is '1' |
| 12:38 | rabeeh | OS is that the pcf8523 lost the crystal sync |
| 12:38 | rabeeh | jnettlet: yeah; error codes via the front LED; but please make sure it blinks only on real errors; otherwise boot time will be longer in a working case |
| 12:39 | rabeeh | OS bit is the MSB in the forth byte |
| 12:41 | jnettlet | rabeeh, they will be simple. probably short fast flashing if it tries to load second stage bootloader, and long slow flashing if it tries to load the kernel and fails. At that point if I set the reserve registers and the kernel doesn't boot all the way up to clear them I can flash to signal that the recovery is loading. |
| 12:42 | jnettlet | that should be pretty easy to understand and give some useful debug info for people seeking help to report |
| 12:43 | _rmk_ | now this is where having uboot working properly would be an added bonus |
| 12:43 | _rmk_ | just had to put the cubox-i on the monitor instead of the tv so I can see why the thing ain't booting |
| 12:46 | _rmk_ | hmm, it's not happy |
| 12:48 | _rmk_ | is networking subtly broken in the latest uboot? |
| 12:49 | _rmk_ | or rather Jan 15ths |
| 12:52 | jnettlet | _rmk_, was working on mine. |
| 12:52 | jnettlet | althought I think rabeeh had mentioned he had seen some occasional problems |
| 12:55 | _rmk_ | I've power cycled mine several times... I can't get any packets out of it anymore |
| 12:56 | jnettlet | thats not good |
| 12:57 | _rmk_ | the switch shows activity on the socket, but tcpdump shows nothing |
| 12:57 | _rmk_ | and as it's trying to send bootp packets.. (presumably dhcp) |
| 12:57 | _rmk_ | which should be broadcast |
| 12:58 | jnettlet | yes, yes they should |
| 12:59 | jnettlet | did you build it yourself or download the binaries? |
| 13:00 | _rmk_ | its one I had to build myself, but it has worked in the past |
| 13:00 | _rmk_ | whether it's worked after a power cycle I don't know |
| 13:01 | jnettlet | bad cable? |
| 13:02 | _rmk_ | well, it was working just a few seconds before |
| 13:03 | _rmk_ | I'm just looking at your 1024x768 mode definition in here |
| 13:04 | _rmk_ | where did that come from? |
| 13:08 | jnettlet | the initial freescale commit |
| 13:09 | _rmk_ | I wonder where they got it from... |
| 13:11 | _rmk_ | my monitor says it's a 70Hz mode |
| 13:11 | _rmk_ | have those values changed from your version? |
| 13:12 | jnettlet | my monitor says 51Hz |
| 13:13 | jnettle | 13:13 * jnettlet wonders if the standard xga mode will work better |
| 13:13 | _rmk_ | the uboot I'm using has this as its top commit: |
| 13:13 | _rmk_ | commit 920ea0f20276614e11961924b1990b6c922c8d0e |
| 13:13 | _rmk_ | Author: Rabeeh Khoury |
| 13:14 | _rmk_ | Date: Sun Jan 12 20:45:15 2014 +0200 |
| 13:14 | _rmk_ | CuBox-i and HB board auto detect code |
| 13:15 | jnettlet | _rmk_, that is the latest |
| 13:15 | jnettlet | and you are flashing the two stages, SPL and u-boot.img? |
| 13:15 | _rmk_ | yes - I've not changed it since it last worked |
| 13:15 | _rmk_ | I think this is the version I've always used on it |
| 13:16 | _rmk_ | since I haven't any other version... |
| 13:16 | _rmk_ | and it's worked for all the reboots I've done thus far |
| 13:16 | jnettlet | _rmk_, can you try this resolution change? http://fpaste.org/70971/79364139/ |
| 13:16 | jnettlet | that is vesa XGA |
| 13:16 | jnettlet | and let me give you one other patch. |
| 13:17 | _rmk | 13:17 * _rmk_ is all ears, they're all over me :) |
| 13:18 | jnettlet | http://fpaste.org/70972/79498139/ |
| 13:19 | jnettlet | at one point I was seeing some stack corruption and tried this out and found positive results. However that stack corruption may have been due to another problem. |
| 13:24 | _rmk_ | hmm, no apparant change :( |
| 13:24 | _rmk_ | in either problem |
| 13:25 | jnettlet | your monitor still reports 70Hz? |
| 13:25 | _rmk_ | yep |
| 13:25 | _rmk_ | so the pixel clock must be wrong. |
| 13:25 | jnettlet | yeah, well the ipu clock selection code is wrong. |
| 13:25 | jnettlet | that was one of the arguments that I got into that has put me off uboot |
| 13:26 | jnettlet | the barebox code because it follows linux more closely is better. |
| 13:26 | jnettlet | _rmk_, you will look at barebox and feel right at home. |
| 13:35 | _rmk_ | so... with those changes, your cubox-i4 produces 51Hz but mine produces 70Hz... |
| 13:35 | _rmk_ | wonder if that could explain why ether isn't working... could something be up with the clock tree |
| 13:36 | MikeSeth | jnettlet: I tried several modes, it doesn't help |
| 13:38 | _rmk_ | does bootp/tftp work on barebox? |
| 13:39 | _rmk_ | I think I'm going to put the android card back in and confirm that it works there |
| 13:39 | jnettlet | _rmk_, yes, but not for the CBi yet. I am working hard to get that sorted out today. |
| 13:40 | MikeSeth | you guys let me know if I can help in any way |
| 13:43 | _rmk_ | nope, android can't get an ip... |
| 13:43 | _rmk_ | Seems my cubox-i4 has died |
| 13:46 | _rmk | 13:46 * _rmk_ puts the uboot card into the hummingboard |
| 13:48 | _rmk_ | jnettlet: in the hummingboard, it produces a 52Hz mode... and ethernet boots. |
| 13:49 | _rmk_ | so yes, looks like my cubox-i4 is sick |
| 13:50 | _rmk_ | rabeeh: ^^^^ |
| 13:57 | MikeSeth | _rmk_: how can you measure the refresh rate if the display doesn't indicate it? |
| 13:58 | MikeSeth | mine just says 'unsupported resolution' |
| 13:58 | _rmk_ | that's a difficult one, because all the sync pulses are embedded as data in the hdmi stream |
| 13:59 | _rmk_ | my samsung monitor seems able to display it, and if it does display it, it can report the resolution and sync timings. the tv on the other hand just tells me there's no hdmi signal |
| 13:59 | jnettlet | oh _rmk_ let me give you another patch to see if it helps |
| 14:00 | jnettlet | _rmk_, your TV could be upset because it is a VESA mode, and your TV only knows CEA modes. Let me give you timings for the CEA 1024x768 mode |
| 14:00 | _rmk_ | the tv supports 1024x768 @60 |
| 14:00 | _rmk_ | 1024x768 60.0 |
| 14:01 | _rmk_ | the timings it gives for that are: |
| 14:01 | _rmk_ | 1024x768 (0x52) 65.0MHz -HSync -VSync |
| 14:01 | _rmk_ | h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz |
| 14:01 | _rmk_ | v: height 768 start 771 end 777 total 806 clock 60.0Hz |
| 14:02 | _rmk_ | and the dove cubox works fine with that |
| 14:04 | MikeSeth | I was digging around samsung manuals and they swear all samsung tvs support 1024x768 @ 60Hz |
| 14:04 | _rmk_ | those are the vesa timings in its edid. |
| 14:05 | _rmk_ | mikeseth: yes, the issue is that uboot should be producing 1024x768 @60, but it gets the dot clock wrong, and therefore the refresh rate is wrong |
| 14:06 | _rmk_ | in the order of 20% wrong |
| 14:07 | _rmk_ | but, from what I gather, the bigger issue here is there's no point wasting time debugging it, because uboot people seem to have decided that they aren't interested in fixing it. |
| 14:08 | MikeSeth | _rmk_: yeah.. I tried to tweak the pixclock up and down by recalculating the modes, that didn't help, not that I have a very clear idea what I am doing |
| 14:08 | _rmk_ | the line which counts in uboot is this one: |
| 14:08 | _rmk_ | .pixclock = 15385 |
| 14:08 | _rmk_ | it converts that to a kHz figure |
| 14:09 | MikeSeth | yeah, and if I understand the imx6 manual correctly, programs PLL5 and divisors to it |
| 14:10 | _rmk_ | well, that's the theory but whether uboot does that or whether it just programs some dividers and hopes for the best... |
| 14:10 | MikeSeth | but because I understand quite little in the electronics part it's hard for me to guess whether it's a problem with uboot calculations relative to the external clock or with the external clock itself |
| 14:10 | _rmk_ | the kernel does the "hope for the best" thing unless you have my patches |
| 14:10 | _rmk_ | or mainline kernels do |
| 14:10 | MikeSeth | yeah |
| 14:11 | MikeSeth | uboot imx code looks like its a patched version of linux code from earlier versions, but again, that's just gut feeling |
| 14:11 | _rmk_ | I've traced the code through to the stuff which starts calling the clk_* functions in ipu_init_sync_panel, and it looked fine to that point |
| 14:12 | _rmk_ | if they're doing what mainline kernels are doing, it's not being clocked off PLL5 at all, and even if it is, they don't propagate rate changes up to PLL5 |
| 14:12 | jnettlet | they don't and that is the problem. |
| 14:12 | MikeSeth | IIRC it depends if in fb_videomode the external clock flag is set |
| 14:13 | MikeSeth | the hdmi initialization code takes different paths based on it |
| 14:13 | jnettlet | and that is why the "slower board" with the 400Mhz bus has a low refresh rate and the fastest soc has a high refresh rate |
| 14:14 | rabeeh | _rmk_: ethernet on u-boot doesn't work for me too on i4pro |
| 14:14 | rabeeh | it actually never worked; only HB |
| 14:14 | MikeSet | 14:14 * MikeSeth has things to say about broadcom |
| 14:15 | _rmk_ | rabeeh: it's been working up until now |
| 14:15 | MikeSeth | I wonder if they have an arm build for their closed source driver.. probably not |
| 14:15 | rabeeh | in u-boot? |
| 14:15 | rabeeh | the kernel works flawless for me |
| 14:15 | _rmk_ | yes, that's how I've been testing everything |
| 14:15 | _rmk_ | I'm finding that android can't get an IP either |
| 14:15 | MikeSeth | ethernet never worked for me in android 4.3 on -i1 |
| 14:16 | _rmk_ | I went into the ethernet app, clicked on configure, it said it was on dhcp, I clicked confirm. I see the switch link light go out and come back on, and then show some activity, but it shows no IP address |
| 14:17 | rabeeh | _rmk_: it doesn't show any IP address |
| 14:17 | rabeeh | if you want to see the IP address then through the serial port run 'netcfg' |
| 14:17 | rabeeh | if Ethernet is connected then wifi is automatically disabled |
| 14:26 | _rmk_ | yea, you're right, android does work |
| 14:26 | _rmk_ | so it's just uboot which has stopped working - and it _definitely_ used to work |
| 14:27 | _rmk_ | because that's how I've booted every kernel since -rc7 on it |
| 14:28 | jnettlet | _rmk_, try and build a singular uboot for the i4pro |
| 14:28 | jnettlet | make mx6_cubox-i4pro |
| 14:38 | _rmk_ | jnettlet: I'll try that in a while |
| 14:39 | _rmk_ | rabeeh: what differences are there between the ethernet on the i4pro and the hummingboard? Are they both still the AR8035 with an external crystal? |
| 14:40 | MarcusVinter | THey both look the same to me externally if that helps... |
| 14:59 | rabeeh | external crystal only |
| 15:02 | _rmk_ | so it's identical to what I have on the hummingboard's microsom? |
| 15:05 | rabeeh | yes. identical |
| 15:13 | jnettlet | _rmk_, have you tried on 100Mbs? I just realized that I never tested my CBi on 1Gbps |
| 15:15 | jnettlet | rabeeh, ^^ |
| 15:22 | davorin | geexbox is far away of being usable... |
| 15:22 | davorin | most mkv containers don't play... |
| 15:23 | davorin | thought i could replace my popcorn c200 already (o; |
| 15:25 | Coolgeek | oh ? it plays fine on my cubox |
| 15:25 | davorin | .ts and .m2ts is no problem... |
| 15:25 | davorin | but most of my .mkv movies won't... |
| 15:26 | davorin | few seconds audio and then stops... |
| 15:26 | Coolgeek | check the codec |
| 15:27 | davorin | normal h.264 and ac3 |
| 15:27 | Coolgeek | h264 HI10p ? |
| 15:27 | davorin | vlc tells me part 10 avc1 |
| 15:28 | Coolgeek | mkvinfo |
| 15:28 | davorin | doesn't exist in macports (o; |
| 15:28 | Coolgeek | part of mkvtoolnix |
| 15:29 | davorin | xmbclog tells: Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 |
| 15:30 | Coolgeek | what video is it ? |
| 15:30 | Coolgeek | anime ? |
| 15:31 | davorin | sure not (o; |
| 15:31 | davorin | machine compiling |
| 15:32 | Coolgeek | h264 HI10p have no hw decoder for now. so it's up to the processor to decode it in software |
| 15:32 | davorin | well the load doesn't go up... |
| 15:32 | Coolgeek | I gave a video test to some geexbox dev and said that they can't play it |
| 15:32 | davorin | sometimes not even switches to movie display..just stays in the video browser |
| 15:32 | Coolgeek | they work on it now I guess |
| 15:32 | davorin | minions banana mkv plays fine ;-) |
| 15:33 | Coolgeek | check the codec :) |
| 15:33 | davorin | wtf...this mkvtoolnix install python, ruby and shit... |
| 15:34 | davori | 15:34 * davorin hates ruby |
| 15:39 | davorin | | + Codec-ID: V_MPEG4/ISO/AVC |
| 15:39 | davorin | | + Codec alle frames decodieren: 1 |
| 15:39 | davorin | | + private Codecdaten, L�nge 168 (h.264-Profil: High @L5.1) |
| 15:40 | Coolgeek | hmmm |
| 15:40 | Coolgeek | try to convert the video to another codec |
| 15:40 | davorin | sure i won't transcode any video (o; |
| 15:41 | davorin | main concept within adobe media encoder takes too long (o; |
| 15:41 | Coolgeek | so I can't nothing for you. try to ask on #geexbox channel |
| 15:41 | davorin | one thing to try is to remove unneeded tracks... |
| 15:42 | davorin | if that confuses geexbox... |
| 15:44 | davorin | or remux ... |
| 15:44 | _rmk_ | just been looking at the uboot ethernet problem... |
| 15:44 | _rmk_ | #define ENET_PAD_CTRL_CLK (PAD_CTL_PUS_100K_UP & ~PAD_CTL_PKE | \ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) |
| 15:53 | davorin | hmm..remuxing with removing subtitles palys the video now... |
| 15:53 | davorin | s/palys/plays/ |
| 15:54 | davorin | though with stuttering... |
| 15:54 | davorin | think it is already worked on this "GetPicture - player is ahead of time" |
| 16:25 | kalasmannen | davorin: i have the same issue with some of my files |
| 16:25 | kalasmannen | you can probably see a lot of frame-drop if you check during playbackup with "O" |
| 16:29 | davorin | well..i read on geexbox forum that this issue is know, i mean the player is ahead error... |
| 16:29 | davorin | other than that..i'm impressed with the performance on i1 playing bluray rips with dts 5.1 hd audio |
| 16:29 | kalasmannen | aah, okay.. sounds hopeful then :) |
| 16:29 | davorin | geexbox was so friendly to provide opkg for net-snmp |
| 16:30 | davorin | so i can log stats with cacti... |
| 16:30 | davorin | you know..customers want to know all sort of things (o; |
| 16:30 | kalasmannen | yes, i've also had good experience with it so far.. it is just this "ahead of time" problem that bothers me a bit, but it seems to only affect a small part of the files in my library |
| 16:30 | kalasmannen | davorin: ah, nice :) |
| 16:31 | davorin | any1 knows...has the arch linux image gcc installed? |
| 16:32 | davorin | this linaro image has just too many bells and whistles for me |
| 16:33 | kalasmannen | if you are using ArchLinuxARM.Cubox-i_20012014.bz2 to create the image, then it does not seem so |
| 16:34 | davorin | guess it can be installed then... |
| 16:34 | kalasmannen | yes, it's probably just a pacman away |
| 16:34 | davorin | pacman..i did pacman once in fpga (o; |
| 16:34 | davorin | and zaxxon game (o; |
| 16:34 | kalasmannen | haha, ah :) |
| 16:35 | davorin | just too less time lately due to online shop... |
| 16:35 | davorin | just today few hundred wlan and bt adapters arrived for testing... |
| 16:35 | kalasmannen | ah, okay, you have your own online-business? |
| 16:35 | davorin | yepp... |
| 16:35 | davorin | side business... |
| 16:36 | davorin | doing more networking/programming for service providers here in .ch |
| 16:36 | kalasmannen | ah, okay |
| 16:36 | davorin | and when the usom modules arrive i go back into hardware developing (o; |
| 16:36 | davorin | fire up cad and my cnc milling machine *g |
| 16:37 | kalasmannen | i'm a tapemonkey for a company in .se (backup technician) :) |
| 16:37 | davorin | aah..ruotsilainen (o; |
| 16:37 | kalasmannen | aa, nice :) |
| 16:38 | davorin | as the finns say...worked and lived 3 years in turku... |
| 16:38 | kalasmannen | oh really? :) |
| 16:39 | davorin | yes |
| 16:39 | kalasmannen | I've been to turku a few times myself, ?t's just a ferry away from here really |
| 16:39 | davorin | went abroad as the internet industry collapsed worldwide around 2000/2001 |
| 16:39 | davorin | i know... |
| 16:39 | davorin | sometimes you could drive with a car half the way to sweden (o; |
| 16:40 | kalasmannen | yeah, it's really close |
| 16:40 | davorin | never saw before that people take everyday the plane to go to work ;-) |
| 16:40 | davorin | to another country... |
| 16:41 | kalasmannen | from finland to sweden? never heard of it myself either really.. but there are a lot of finns who also know swedish, at least in the southern part of the country i guess |
| 16:42 | davorin | well..it's an official language in finland... |
| 16:42 | kalasmannen | a lot of people living here have relatives in finland too for example, at least 2-3 of my colleagues |
| 16:42 | kalasmannen | yes, that's correct :) |
| 16:50 | MikeSeth | rabeeh: here? |
| 16:54 | MikeSeth | can someone tell me which parts of fsl/vivante libraries are closed source blobs? |
| 17:03 | _rmk_ | rabeeh/jnettlet: found the problem with the ethernet |
| 17:03 | _rmk_ | in uboot, the phy comes up as phy id #4 not #0 |
| 17:04 | _rmk_ | I suspect rabeeh doesn't have a strong enough pull down on the activity led |
| 17:04 | _rmk_ | which is one of the phy pins which configures the address |
| 17:04 | _rmk_ | AR8035 data sheet, table 1-4. LED_ACT is phy address 2 |
| 17:05 | _rmk_ | configuring uboot to use a phy address of 4 works. |
| 17:08 | _rmk_ | I've tried extending the phy resets, that didn't seem to help |
| 17:11 | _rmk_ | unfortunately, the uboot phy stuff won't let us autodetect this, because get_phy_device_by_mask() returns a phy device no matter whether it finds one or not |
| 17:13 | jnettlet | _rmk_, oh I was readying something similar to that on the freescale community site. Apparently boundary has two different enet configs for their board. One for pre-reset and on for post. Apparently they were having a problem with the address changing due to the pin configs coming out of reset being different than the initial setup. |
| 17:14 | _rmk_ | I suspect there's not enough leakage in rabeeh's LEDs to properly pull the pin in the appropriate direction |
| 17:16 | jnettlet | so a different led on the two models? |
| 17:19 | MikeSeth | ahh, a genuine hardware quirk! |
| 17:21 | _rmk_ | that's just a guess... we don't have the microsom circuits yet... |
| 17:22 | jnettlet | _rmk_, does changing the phy addr break the HB1? |
| 17:23 | _rmk_ | AR8035 data sheet shows a 10K pull down on the LED_ACT line for the reference design before the LED |
| 17:23 | _rmk_ | jnettlet: I would imagine so |
| 17:24 | _rmk_ | really, this bollocks uboot code really needs to report whether it found a phy or not |
| 17:24 | jnettlet | do not even get me started |
| 17:24 | jnettlet | I am sorting out multi-boot on barebox and then we will never need to look at it again |
| 17:25 | MikeSeth | hm, I have 136Mb RAM missing |
| 17:26 | jnettlet | had a good chat with Sascha about it on IRC today. |
| 17:26 | jnettlet | MikeSeth, 128 if reserved for the GPU by default, the other 8 is for system coherent memory |
| 17:27 | MikeSeth | jnettlet: I have gpumem=16M in uEnv.txt |
| 17:28 | jnettlet | MikeSeth, that may only tell the gpu not to use the memory. I think the system hooks that reserve it may not use that. |
| 17:28 | MikeSeth | er, so it's never released to the kernel memory management? |
| 17:29 | _rmk_ | oh that's more uboot bollocks |
| 17:30 | jnettlet | MikeSeth, hold on I am checking |
| 17:30 | MikeSeth | _rmk_: I see a lot of rebasing in uboot's future |
| 17:30 | _rmk_ | I see no future for uboot |
| 17:31 | jnettle | 17:31 * jnettlet agrees |
| 17:31 | jnettlet | it is too much trouble. That is why arguments about them only accepting "proper and clean" code is ridiculous |
| 17:32 | jnettlet | sugar coated crap only attracts more flies |
| 17:33 | davorin | don't tell wolfgang (o; |
| 17:33 | _rmk_ | and it boots again :) |
| 17:34 | _rmk_ | fec 2188000.ethernet eth0: Freescale FEC PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet:04, irq=-1) |
| 17:34 | _rmk_ | whereas before, it has always been: |
| 17:34 | _rmk_ | fec 2188000.ethernet eth0: Freescale FEC PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1) |
| 17:34 | _rmk_ | note it's changed address... and our wonderful kernel can cope unlike uboot |
| 17:39 | _rmk_ | jnettlet: http://fpaste.org/71050/95148139/ <== my hacks |
| 17:40 | MikeSeth | jnettlet: so, is gpu memory allocation broken? |
| 17:45 | jnettlet | MikeSeth, it doesn't appear to be. Can you paste the output of cat /proc/cmdline |
| 17:46 | MikeSeth | root@cubox:/home/emestee# cat /proc/cmdline |
| 17:46 | MikeSeth | root=/dev/mmcblk0p1 rootwait video=mxcfb0:dev=hdmi consoleblank=0 gpumem=16M |
| 17:49 | _rmk_ | heh, after that reboot, the phy came up as address 0 again |
| 17:49 | jnettlet | MikeSeth, the kernel code looks okay |
| 17:49 | jnettlet | _rmk_, okay so it may be the problem that I was reading about. |
| 17:50 | MikeSeth | jnettlet: well, looks like I got myself a project |
| 17:51 | jnettlet | MikeSeth, can you post the top 50 lines of dmesg? It should print out the memory layout and reservations |
| 17:51 | MikeSeth | jnettlet: one sec, wpa_supplicant crapped out again |
| 17:53 | davorin | oh..openelec build... |
| 17:55 | MikeSeth | jnettlet: http://paste.debian.net/78029/ |
| 17:56 | jnettlet | _rmk_, do you think setting up the pads after the first reset will help normalize things. Maybe like this. http://fpaste.org/71058/49615113/ |
| 17:56 | _rmk_ | no - the problem phy pin is not connected to the imx6 |
| 17:57 | jnettlet | oh it is internal to the ar8035 |
| 17:58 | _rmk_ | yea, it's from the AR8035, routed from the microsom to the lower board, and then the upper board to a LED near the ether socket, with a 470 ohm resistor in series |
| 18:07 | jnettlet | MikeSeth, there is definitely something funky going on with that reserve code although it all looks reasonable. You should probably throw some printk's in that code to see if it is really changing the amount of memory reserved. You may want to start by removing the gpumem= line and see if the allocations change at all |
| 18:07 | jnettlet | I am not going to spend more time on this as we are almost ready to have people start switching to 3.10 |
| 18:17 | davorin | do people buy cubox-i1 at all? |
| 18:17 | jnettlet | there are a few people that have come onto the channel asking about them. |
| 18:17 | davorin | just sold 1 so far (o; |
| 18:18 | davorin | gives me more to play with ;-) |
| 18:18 | davorin | you know if ethernet flow is still on by default on latest kernel? |
| 18:19 | jnettlet | I don't sorry. I haven't touched a 3.0.35 kernel since we first got the boards a while ago |
| 18:21 | davorin | okay...then will i look into this once build system is setup... |
| 18:21 | jnettlet | davorin, if customers ask the CBi1 is crazy fast for 720p and can pushed for 1080p although not a perfect experience. |
| 18:22 | davorin | ehm.... |
| 18:22 | davorin | just ran a movie through...kung.fu.panda.2 bluray rip... |
| 18:22 | davorin | around 35mbits/sec steam including audio... |
| 18:22 | _rmk_ | I believe flow control defaults to enabled on linux anyway |
| 18:22 | davorin | cpu load around 60% including dts hd 5.1 audio decoding... |
| 18:22 | davorin | *iiik |
| 18:23 | davorin | who came up with this freaking idea? |
| 18:23 | _rmk_ | it's something that is negotiated between the network peers |
| 18:23 | jnettlet | davorin, using geexbox? |
| 18:23 | davorin | yepp |
| 18:23 | jnettlet | that is because they default the framebuffer to 16bpp |
| 18:23 | davorin | will publish statistics cacti graphs |
| 18:23 | jnettlet | I run everything at 32bpp |
| 18:24 | jnettle | 18:24 * jnettlet doesn't understand 1080p at 16bpp |
| 18:24 | davorin | well...doesn't influence video/audio performance |
| 18:24 | davorin | just some minor artifacts in overlay |
| 18:24 | Coolgeek | jnettlet: how do you set that ? |
| 18:24 | jnettlet | sure it does. double the memory bandwidth to the screen |
| 18:25 | davorin | there a setting within geexbox gui? |
| 18:25 | davorin | or a config file? |
| 18:25 | jnettlet | I think on geexbox you need to regenerate the boot.scr |
| 18:25 | MikeSeth | jnettlet: alright, hacky time |
| 18:25 | jnettlet | although you should be able to remove it and replace it with a uEnv.txt easy enough |
| 18:26 | jnettlet | depending on screen size but up to 42" I prefer 720p at 32bpp vs 1080p at 16bpp. |
| 18:28 | jnettlet | the color saturation is more important than pixel clarity because the additional pixels just tend to look similar due to reduced color depth |
| 18:28 | davorin | "dev=hdmi,1920x1080M@60,if=RGB24,bpp=16" |
| 18:28 | jnettlet | but that is my personal preference |
| 18:28 | jnettlet | yep change bpp=32 |
| 18:28 | davorin | reminds me of the audio discussion yesterday in the forum (o; |
| 18:28 | jnettlet | you can't set bpp=24 because the gpu gets very angry |
| 18:29 | jnettlet | dts vs dolby 5.1? |
| 18:30 | davori | 18:30 * davorin used to listen to pink floyd records in the basement on selfmade 1.6m tall dynaudio speakers (o; |
| 18:30 | davorin | yeah i think this one, where nyquist can't be high enough... |
| 18:31 | jnettlet | the quadrophonic recording? |
| 18:31 | davorin | unfortunately i only built 2 speakers (o; |
| 18:36 | _rmk_ | right, using the inversion at PWM level doesn't work for the power LED. |
| 18:38 | davorin | booz.scr is compiled from boot.cfg, right? |
| 18:38 | davorin | booz? |
| 18:40 | jnettlet | generally yes |
| 18:40 | davorin | can't do that from within mounted /boot partition i guess (o; |
| 18:40 | davorin | live was much easier in old u-boot v1.x days |
| 18:43 | davorin | on which repository do you work for bootloader and kernel normally? |
| 18:44 | jnettlet | most images are generated from rabeeh's u-boot and kernel repos on github |
| 18:48 | davorin | hmm...debian is fecked with arm-linux toolchain |
| 19:01 | davorin | okay..u-boot build fails, but at least it compiled mkimage (o; |
| 19:09 | davorin | ooh..ugly picture with 32bpp |
| 19:10 | davorin | so it sets its resolution down to 640x480 @ 32bpp |
| 19:10 | davorin | but gui is much faster |
| 19:10 | davorin | # free -m |
| 19:10 | davorin | total used free shared buffers |
| 19:10 | davorin | Mem: 240 109 130 0 5 |
| 19:10 | davorin | -/+ buffers: 104 135 |
| 19:10 | davorin | Swap: 0 0 0 |
| 19:12 | jnettlet | total 240? that seems a bit low |
| 19:12 | davorin | yepp |
| 19:12 | davorin | and freezes now with same video |
| 19:12 | davorin | cpu load 2.9% |
| 19:14 | jnettlet | might be the vpu or ipu having problems. are you getting nasty log messages from the IPU? |
| 19:14 | davorin | only log i have is xbmc.log |
| 19:14 | jnettlet | try dmesg |
| 19:15 | davorin | mxc_ipu mxc_ipu: ERR: no-0x50,ipu_queue_task err:-110 |
| 19:15 | davorin | mxc_v4l2_output mxc_v4l2_output.0: display work fail ret = -110 |
| 19:15 | davorin | mxc_ipu mxc_ipu: ERR: [0x8c89a400] no-0x60, timeout:1000ms! |
| 19:15 | davorin | mxc_ipu mxc_ipu: ERR: no-0x60,ipu_queue_task err:-110 |
| 19:15 | davorin | mxc_v4l2_output mxc_v4l2_output.0: display work fail ret = -110 |
| 19:15 | jnettlet | oh yes very angry. |
| 19:15 | davorin | so it grabs 256mb for graphics.... |
| 19:15 | davorin | but 640x480@60hz is fixed now... |
| 19:15 | davorin | at 32bpp |
| 19:16 | davorin | have you run on the i4pro with 32bpp? |
| 19:18 | jnettlet | I have run both the CBi4p and HB1 at 32bpp, although most my work has been done using the 3.10 kernel. I was testing backported graphics drivers at one point and did run 3.0.35 at that resolution. |
| 19:19 | jnettlet | I would suggest sticking with 16bpp for now, as I don't have time to fully debug this currently. |
| 19:19 | davorin | ah no worries (o; |
| 19:20 | davorin | meanwhile finishing build system setup and then openelc testing... |
| 19:20 | jnettlet | oh yeah there are patches floating around to fix this problem on the 3.0.35 kernel. again I would wait for 3.10 to finish baking |
| 19:21 | davorin | plenty to do other things...especially when rabeeh has finished the docs *lol |
| 19:22 | sraue | if anyone want test OpenELEC on Cubox-i (4pro) see: http://imx.solid-run.com/forums/viewtopic.php?f=7&t=457#p2490 |
| 19:22 | davorin | is it i4p only? |
| 19:23 | davorin | ah, you grab the i4p bootloader |
| 19:29 | davorin | regarding the bottom sticker with the mac address |
| 19:29 | davorin | is the wlan mac +1 ? |
| 19:37 | davorin | ah...openelec boots on i1 |
| 19:45 | davorin | xbmc crashes on i1 when starting a movie... |
| 19:45 | davorin | [ 465.638911] Physical memory allocation error! |
| 19:45 | davorin | [ 465.639579] Physical memory allocation error! |
| 19:45 | davorin | [ 465.639589] Physical memory allocation error! |
| 19:45 | davorin | guess i saw the same on rpi |
| 19:46 | davorin | who came up with this brilliant idea of sluggish mouse pointer anyway... |
| 20:01 | davorin | okay...cpu load is higher with openelec than geexbox on i1 |
| 20:01 | davorin | 70 - 80% with bluray h.264 and true hd 7.1 |
| 20:04 | davorin | anyway...time to go for 2day... |
| 20:28 | obinou | davorin_away: what is the benefit of openelec over regular xbmc image ? |
| 20:32 | MikeSeth | jnettlet: played a bit with gpumem= parameter, 128Mb is gone anyway no matter what |
| 20:37 | davorin_mbp | well..openelc claims to be smaller in size and with higher performance.. |
| 21:14 | MikeSeth | the pages are cleary marked reserved, now let's find out why,, |
| 21:21 | hste | MikeSeth: when I compile vivante as module I can set gpumem lower |