| 09:48 | mk01_ | jnettlet: the latest drivers/mmc changes returned this (on my only one SanDisk card I have): |
| 09:48 | mk01_ | [ 2.940643] mmc1: host does not support reading read-only switch, assuming write-enable |
| 09:48 | mk01_ | [ 2.943512] mmc1: Problem setting current limit to 3! |
| 09:48 | mk01_ | [ 2.944737] mmc1: Problem setting current limit to 2! |
| 09:48 | mk01_ | [ 3.051895] mmc1: new ultra high speed DDR50 SDHC card at address aaaa |
| 09:48 | mk01_ | [ 3.052799] mmcblk0: mmc1:aaaa SL16G 14.8 GiB |
| 09:48 | mk01_ | [ 3.066529] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00 |
| 09:48 | mk01_ | [ 3.106978] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready |
| 09:48 | mk01_ | [ 3.309660] mmc1: Problem setting current limit to 3! |
| 09:48 | mk01_ | [ 3.311050] mmc1: Problem setting current limit to 2! |
| 09:48 | mk01_ | [ 3.417870] mmc1: tried to reset card |
| 09:48 | mk01_ | [ 3.439700] mmcblk0: p1 p2 p3 |
| 10:00 | mk01_ | jnettlet: tried reverting one by one the commits (relevant to ./mmc including the .dtb change) but none of them as single revert reversed the situation |
| 10:13 | jnettlet | mk01_, you need to take the card out each time you build and test. The problem is that means the firmware on the card crashed. |
| 10:14 | jnettlet | it is really a nightmare. Those reverts fixed another Sandisk card 32GB. |
| 10:14 | jnettlet | it seems the DDR50 cards are the most picky |
| 10:19 | jnettlet | mk01_, also was the card working in UHS mode before or was it only using high speed? |
| 10:19 | mk01_ | was working |
| 10:19 | mk01_ | I got it when you was telling that finally UHS works. |
| 10:20 | mk01_ | and plugged it and used until now |
| 10:20 | mk01_ | needs to be said that even with this error it still operates at the same speed |
| 10:21 | mk01_ | (and with no further errors during operations) |
| 10:21 | jnettlet | oh it is recovering properly? Well that is the first time that has worked |
| 10:21 | jnettlet | I bet that 100ms delay is too long |
| 10:22 | mk01_ | yes, despite this error reset recovers it and works at full speed |
| 10:22 | jnettlet | so it still transitions to 1.8v |
| 10:22 | mk01_ | this happens 2x from 4. one boot is fully ok |
| 10:22 | jnettlet | did you check /sys/kernel/debug/mmc0/ios ? |
| 10:22 | mk01_ | and one boot ends with more (same) errors, can not read part. table... then reverts to STD speed |
| 10:22 | mk01_ | and boots |
| 10:23 | jnettlet | mk01_, well it sucks it is unstable, but it is great that the fall back is working. It used to just stop talking to the card and hang |
| 10:24 | jnettlet | mk01_, this is with your 4.1 kernel right? |
| 10:24 | mk01_ | oh no, never seen that |
| 10:24 | mk01_ | (full hang) |
| 10:24 | mk01_ | I was sure you will ask and I recompiled also your vanilla |
| 10:24 | mk01_ | basically it is the same |
| 10:24 | jnettlet | well the hardware isn't hung, the card wouldn't transition back properly so the rootfs would never be readable |
| 10:26 | jnettlet | mk01_, how far back did you go? I would recommend undoing the revert of my patch and then removing 9ac05c5fc49a6496927e7bef40c4014c6b21b8f1 |
| 10:26 | mk01_ | ./ios reports 3.3V, but card is doing 37MB/s. |
| 10:26 | mk01_ | wait, will tell you how far |
| 10:26 | jnettlet | oh maybe it is mmc1 |
| 10:26 | mk01_ | oh ok |
| 10:27 | mk01_ | my bad |
| 10:27 | mk01_ | clock: 50000000 Hz |
| 10:27 | mk01_ | actual clock: 49500000 Hz |
| 10:27 | mk01_ | vdd: 21 (3.3 ~ 3.4 V) |
| 10:27 | mk01_ | bus mode: 2 (push-pull) |
| 10:27 | mk01_ | chip select: 0 (don't care) |
| 10:27 | mk01_ | power mode: 2 (on) |
| 10:27 | mk01_ | bus width: 2 (4 bits) |
| 10:27 | mk01_ | timing spec: 7 (sd uhs DDR50) |
| 10:27 | mk01_ | signal voltage: 0 (1.80 V) |
| 10:27 | mk01_ | this is now boot with the dmesg I copied |
| 10:27 | mk01_ | so it is recovered, is it? |
| 10:27 | jnettlet | yep, so it is using ultra high speed |
| 10:27 | jnettlet | yes |
| 10:28 | jnettlet | well the only way to really figure this out is turn on CONFIG_MMC_DEBUG and look at the very messy logs :) |
| 10:28 | mk01_ | I didn't try to revert |
| 10:28 | mk01_ | mmc: core: Increase delay for voltage to stabilize from 3.3V to 1.8V |
| 10:28 | mk01_ | ENGR00295184-3 mmc: sdhci-esdhc-imx: add keep power feature during suspend |
| 10:28 | mk01_ | ENGR00240226-07 mmc: add delay after CMD6 befoer sending CMD13 for sandisk |
| 10:29 | mk01_ | I tried revert the reverts |
| 10:29 | mk01_ | and |
| 10:30 | mk01_ | ok |
| 10:31 | mk01_ | tried all changing drivers/mmc back to the first group of updates (from May) |
| 10:31 | mk01_ | so stopped here |
| 10:31 | mk01_ | commit 4e436a5c9ed007fb1866433dc5d1704cf81ca1c1 |
| 10:31 | mk01_ | Author: Russell King |
| 10:31 | mk01_ | also tried the dtb change (regularator hook to gpio) |
| 10:32 | mk01_ | OK |
| 10:32 | jnettlet | the dtb change is correct |
| 10:32 | jnettlet | otherwise some cards will hang on reboot |
| 10:33 | mk01_ | ok, so the freeze is this one. ... nevertheless |
| 10:33 | jnettlet | the dtb change causes the error? |
| 10:34 | mk01_ | commit 564d91e3127cbc49aca56199cb1c2c9c6069f3f2 |
| 10:34 | mk01_ | Author: Jon Nettleton |
| 10:34 | mk01_ | Date: Mon Aug 24 16:09:33 2015 +0200 |
| 10:34 | mk01_ | Revert "mmc: core: Extend mmc_delay in mmc_power_cycle for UHS transition" |
| 10:34 | mk01_ | ok, so undo this |
| 10:34 | mk01_ | + revert 9ac05c5fc49a6496927e7bef40c4014c6b21b8f1 |
| 10:34 | mk01_ | ? |
| 10:34 | mk01_ | will do |
| 10:34 | jnettlet | oh so my patch is working correct? |
| 10:34 | mk01_ | your patch |
| 10:34 | jnettlet | I originally wrote that to fix my Sandisk DDR50 card under the 4.1 kernel |
| 10:34 | mk01_ | (1) ms -> (3) ms |
| 10:34 | mk01_ | ? |
| 10:35 | jnettlet | yes |
| 10:35 | mk01_ | this one was from the 1st pool and was working for whole time |
| 10:35 | mk01_ | (for me) |
| 10:35 | mk01_ | that's why I was surprised you are reverting it (and why I started reverting reverts) |
| 10:36 | jnettlet | well I assumed the change the chromium team added was the proper fix. |
| 10:36 | mk01_ | ok, so let's try 9ac05c5fc49a6496927e7bef40c4014c6b21b8f1 ... |
| 10:36 | mk01_ | ? |
| 10:36 | mk01_ | basically - until (also) this one ( 1ms -> 3ms) |
| 10:36 | mk01_ | I had one user not booting at all |
| 10:37 | mk01_ | going to try 9ac05c5fc49a6496927e7bef40c4014c6b21b8f1 |
| 10:37 | jnettlet | yeah, well I found another card who with both patches applied couldn't boot at all |
| 10:38 | mk01_ | ((from all being said - best fix is to avoid sandisks)) |
| 10:38 | jnettlet | well the DDR50 cards. |
| 10:38 | jnettlet | they seem to be very problematic |
| 10:42 | mk01_ | jnettlet: but I wanted more topics |
| 10:44 | mk01_ | I moved https://github.com/SolidRun/linux-fslc/blob/3.14-1.0.x-mx6-sr/drivers/video/mxc/mxc_hdmi.c#L2065 to https://github.com/SolidRun/linux-fslc/blob/3.14-1.0.x-mx6-sr/drivers/video/mxc/mxc_hdmi.c#L2037 |
| 10:45 | mk01_ | switched order here https://github.com/SolidRun/linux-fslc/blob/3.14-1.0.x-mx6-sr/drivers/video/mxc/mxc_hdmi.c#L2507 |
| 10:45 | mk01_ | and call to hdmi_setup() iffed with if (check_hdmi_state()) |
| 10:46 | mk01_ | wait, will rebase to your tree and post link |
| 11:01 | mk01_ | jnettlet: https://github.com/mk01/linux-fslc/commit/c56737947086238899120dc5a46b88ad0a6bc55d |
| 11:04 | mk01_ | basically that early UNBLANK (practically irq unmask in mxc_hdmi_fb_event() was returning the HP hell as before your jitter patch (maybe not so visible without AVR between TV and device). |
| 11:06 | mk01_ | ((this is why probably you wanted initially keep cable state disconnected (so IPU would power on but fb_event would return NOOP))) |
| 11:09 | mk01_ | this change looks to revert your initial intention - while properly initialises sound too |
| 11:13 | jnettlet | okay I will take a look. |
| 11:13 | jnettlet | I am in image building hell today though. |
| 11:14 | mk01_ | as you said last week. no hurry. |
| 11:14 | mk01_ | between I implemented the blank/unblank to xbmc |
| 11:16 | mk01_ | there is one consequence I didn't see first - when we blank, sound is disabled. there is use case for some users to use kodi as music box -> playing AVR (hdmi) while TV off / or black screen (black screensaver) |
| 11:18 | mk01_ | not a practical issue at the end, but added setting for that |
| 11:18 | jnettlet | mk01_, yes I have been thinking about that. My initial thought is if we receive a blank event but audio is playing to just send a black frame over hdmi for the video signal. |
| 11:19 | jnettlet | I think catching the CEC disconnect event will help solve this problem. |
| 11:19 | jnettlet | but then we do need to figure out how to catch an event when the music is stopped |
| 11:25 | mk01_ | I like your direction (to have a code path for all possible scenarios) but my experience is to better let user decide via click/unclick option. so while adding this setting option I made also configurable the HP reception + modelist re-read & mode reapply (at the level of xbmc). |
| 11:25 | mk01_ | but wanted to say - it works very nicely as a 'whole' now |
| 11:27 | mk01_ | idling Kodi (at ondemand governor and freq fallen down to 396mhz) takes ~1% cpu (I had that before with stopping renderer), but now temp is going below 39C |
| 11:27 | mk01_ | on HB2ex |
| 11:27 | mk01_ | before mine minimum was ~42-44C |
| 11:33 | mk01_ | I will start slowly sending you the commits to xbmc - that you can properly test path where all the sleeping and blanking is triggered from screensaver() path - I run all boards from cec path. theoretically there should not be difference, but |
| 11:33 | jnettlet | yeah, I am trying to finally get the power usage under control. |
| 11:33 | jnettlet | okay thanks |
| 11:34 | mk01_ | there is a difference . so hopefully there won;t be closed loop (of calls). |
| 11:34 | mk01_ | and also I decided not to wait for Koying |
| 11:34 | jnettlet | okay |
| 11:34 | mk01_ | last time in May there was quite fight within Kodi guys because of it |
| 11:34 | jnettlet | I am sure. |
| 11:35 | jnettlet | so many germans in that group. always full of fight |
| 11:35 | jnettlet | mk01_, are you using the smart_eee patches and kernel option? |
| 11:36 | mk01_ | yes, the last group I merged 1:1 |
| 11:36 | mk01_ | group = pool of commits |
| 11:36 | jnettlet | if you see any strange disconnects please report them to me. I am trying to gauge the stability of my fix. |
| 11:37 | mk01_ | after you ask already - yes, I see some - but because ONLY on HB1 connected via POWERLINK adapter |
| 11:38 | mk01_ | it doesn't mean anything for now |
| 11:39 | mk01_ | ((basically link 'looks' up (no disconnect / reconnect reported), both leds (on powerlink adapter and also HB1) do signal traffic, but I'm getting like 10-20s window without data actually transmitted |
| 11:40 | mk01_ | what it makes even more interesting is that THIS is selective to some workstations on network |
| 11:40 | jnettlet | oh my power adapters do that as well. They have their own power-saving mode that can be problematic |
| 11:40 | mk01_ | so you see ... yes |
| 11:41 | mk01_ | funny is, the "blackout" is traveling - at one time only one destination is affected |
| 11:41 | mk01_ | so I have four machines pinging |
| 11:42 | mk01_ | 1st gets no connect to that HB1, then ping restores -> 2nd station loose ping -> and so on |
| 11:42 | mk01_ | very funny |
| 11:43 | jnettlet | oh, I believe PLC holds elections to determine who is the master of the network. I bet they are trying to figure that out. |
| 11:43 | jnettlet | there is openplc that has tools that you can monitor the traffic with. |
| 11:44 | mk01_ | from HB1 perspective important is, that IT's connection to ANY station (so direction HB1->net and replies back) are not dicontinued |
| 11:45 | mk01_ | so I have IPTV running on it since early Saturday non-stop |
| 11:45 | mk01_ | with no drop or messy timeouts in Kodi log |
| 11:45 | jnettlet | great |
| 11:46 | mk01_ | on cubox / HB2ex I realised literally no change |
| 11:46 | mk01_ | ((and run ieee=1 on all) |
| 11:47 | mk01_ | and that's all four topics I wanted to discuss |
| 11:47 | mk01_ | hmm forgot to reboot the new kernel to test. |
| 11:49 | mk01_ | (((only btw: gave 3h again to re-check galcore v5, but no change on my side. starting to be a bit confused))) |
| 11:49 | mk01_ | [ 3.480759] mmc1: card never left busy state |
| 11:49 | mk01_ | [ 3.485170] mmc1: error -110 whilst initialising SD card |
| 11:49 | mk01_ | [ 3.746130] mmc1: host does not support reading read-only switch, assuming write-enable |
| 11:49 | mk01_ | [ 3.749069] mmc1: Problem setting current limit to 3! |
| 11:49 | mk01_ | [ 3.750034] mmc1: Problem setting current limit to 2! |
| 11:49 | mk01_ | [ 3.857769] mmc1: new ultra high speed DDR50 SDHC card at address aaaa |
| 11:49 | mk01_ | [ 3.858182] mmcblk0: mmc1:aaaa SL16G 14.8 GiB |
| 11:49 | mk01_ | [ 3.880572] mmcblk0: p1 p2 p3 |
| 11:50 | jnettlet | mmc1: card never left busy state |
| 11:50 | jnettlet | that is interesting |
| 11:50 | mk01_ | I have seen it already once |
| 11:50 | jnettlet | let me look at the code around there. |
| 11:50 | mk01_ | ((also only after the last commits)). what I already did is git diff yourtree -- drivers/mmc |
| 11:51 | jnettlet | okay thanks for everything. I will download your image and debug v5 drivers as soon as I have some free time |
| 11:51 | mk01_ | jnettlet: don't waste time, really |
| 11:52 | jnettlet | well I will be moving to 4.1 soon enough |
| 11:52 | jnettlet | we can revisit it then. |
| 11:52 | mk01_ | I'm sure you would eventually succeed ... but for now I will have no immediate benefit from it so benefit not worth the cost (for now) |
| 11:52 | mk01_ | jnettlet: yes, that makes sense |
| 11:53 | mk01_ | last words to the drivers/mmc |
| 11:55 | mk01_ | not important. will leave it rebooting / logging for next 12h and report tomorrow |
| 11:56 | jnettlet | okay thanks |
| 11:56 | mk01_ | hmm, four reboots in a row the same - didn't left busy state |
| 11:56 | mk01_ | re 'didn't leave' |
| 11:57 | mk01_ | but card is always inited ok |
| 11:57 | mk01_ | clock: 50000000 Hz |
| 11:57 | mk01_ | actual clock: 49500000 Hz |
| 11:57 | mk01_ | vdd: 21 (3.3 ~ 3.4 V) |
| 11:57 | mk01_ | bus mode: 2 (push-pull) |
| 11:57 | mk01_ | chip select: 0 (don't care) |
| 11:57 | mk01_ | power mode: 2 (on) |
| 11:57 | mk01_ | bus width: 2 (4 bits) |
| 11:57 | mk01_ | timing spec: 7 (sd uhs DDR50) |
| 11:57 | mk01_ | signal voltage: 0 (1.80 V) |
| 12:02 | jnettlet | mk01_, this isn't an early dev board by any chance? The gpio to power cycle the sdhc card was added until the first production version of the board which is v3.0 |
| 12:03 | mk01_ | CPU identified as i.MX6Q, silicon rev 1.5 |
| 12:03 | jnettlet | yeah, this isn't the microsom version, it is the board revision. You actually need to pop off the microsom to see |
| 12:03 | jnettlet | sometimes there are some stickers covering it as well |
| 12:04 | mk01_ | ok, will check later |
| 12:05 | mk01_ | only sticker is saying i2EX - 310 - D |
| 12:06 | mk01_ | if still not it, then I will take the board down at evening |
| 12:06 | jnettlet | yeah it the revision is silk screened on the board |
| 12:06 | mk01_ | ok |
| 12:39 | mk01_ | jnettlet: will you mind if instead of picking & posting #SHAs I will cherry-pick needed code myself and rebase onto upstream/master ? the practical problem is I have in our tree ~200 commits created during period of 2y - some are unique reusable block, some others just fixes on top or even rewrites of parts of previous changes - simply continual development. it would cause a bit headache to you. but If I will roll them one by one by applying |
| 12:39 | mk01_ | & rebasing , you will get clean working tree with the expected areas of functionality |
| 12:40 | jnettlet | mk01_, that is fine by me. Just point me to your finished commits and I am sure we can work with it. |
| 12:40 | mk01_ | agreed |
| 14:22 | Eskimon | Hi there ! |
| 14:24 | Eskimon | I was going to flash the debian image provided on solid-run website, but the uncompressed file is not a .img as expected. Is it still the same procedure (dd) to flash all the system? |
| 14:25 | Eskimon | Or maybe I'll simple download one of those : http://download.solid-run.com/pub/solidrun/cubox-i/Debian/Jessi-repackaged-trial/ |
| 14:25 | Eskimon | (but which one ? Is there any difference between the two files ?) |
| 14:26 | vpeter | Eskimon: In this folder you have img file. |
| 14:26 | Eskimon | yep, can see that |
| 14:27 | Eskimon | But there is two times the same with different size, any reason why ? |
| 14:28 | Eskimon | (and what is the kernel file for ?) |
| 16:12 | mk01_ | jnettlet: https://github.com/mk01/xbmc/commits/treeJnettlet |
| 16:17 | jnettlet | mk01_, looks good. thanks. |
| 16:21 | mk01_ | jnettlet: if something won't compile or wouldn't make sense to you - I missed commit or put one more - you can use this as reference https://github.com/xbianonpi/xbian-sources-xbmc/tree/treeIsengard . it is 'live' tree which is used for 'stable' .deb compilation |
| 16:22 | jnettlet | okay |
| 17:55 | mk01_ | jnettlet: from 130 reboots all passed (or recovered). the blk read error + reset was case in ~1/4 boots. but again, always "timing spec: 7 (sd uhs DDR50)" |
| 17:58 | mk01_ | 2ex uses bolts to attach the cpu, or just the heatsink ? in any case I will need screwdriver ? |
| 18:31 | jnettlet | mk01_ depends on the board. Early Dev boards had a acre and nut, but later production board screwed right into the board mounts |