13:14 | topi` | jnettlet: since you probably know the low-level stuff well, what do you think causes the fact that microSD's are unreliable in production devices? |
13:14 | topi` | I have already fried 3 microSD's under various conditions (most probable cause of death is that voltage was dropped during a MMC write) |
13:15 | jnettlet | topi`, because microSD's are horrible unreliable :\ |
13:15 | topi` | jnettlet: ultimately, I need to know what to advice our client. They want a robust solution, but not having eMMC to boot from isn't very robust in my eyes. But otherwise than that, the HB Gate would be a 100% match for their needs |
13:16 | topi` | I thought eMMC is electrically similar to SD cards? Why aren't they unreliable then? |
13:16 | jnettlet | topi`, basically you need a very good vendor for your SDHC cards. and to randomly test each lot you buy |
13:16 | topi` | OK |
13:16 | topi` | have you done any testing? |
13:17 | jnettlet | eMMC tend to be a much higher quality. generally because they don't go to consumer outlets |
13:17 | jnettlet | I have done lots of testing both for SolidRun as well as OLPC |
13:17 | jnettlet | Does you customer just need something to boot from or do they need speed as well. |
13:18 | jnettlet | generally I have found that non-UHS speed cards are most stable, although the very high end Sandisk and Samsung cards tend to be much better, but obviously a bit pricy |
13:20 | topi` | we need to be able to reliably boot the device and it'll just run the filesystems as read-only to avoid problems |
13:20 | topi` | if they require some logging arrangements, I'd say they could probably compressed to ram and periodically written to disk |
13:21 | topi` | the customer seems to be cost-sensitive (these times many are!) so we would want to offer the HB Gate but it doesn't have eMMC |
13:21 | jnettlet | In that case most cards should be fine. I would recommend disabling UHS support and just run at normal SDHC High Speed mode. |
13:21 | topi` | the HB will be our choice in any case, since we don't want extra software risk, and HB carries no SW risks :) |
13:22 | topi` | how do you disable UHS support? |
13:22 | jnettlet | just in the device-tree file. add no-1-8-v; to the usdhc2 entry in imx6qdl-hummingboard.dtsi |
13:23 | jnettlet | It sounds like you don't need much performance, so I would just look for a class 10 card that performs well. You can test it using iozone |
13:25 | topi` | ok |
13:25 | jnettlet | but definitely buy in lots and then randomly test. If you buy one by one you are kind of getting the luck of the draw. I have bought cheap sdhc's that have lasted for years, and bought expensive sdhc's that have started spewing errors after weeks |
13:26 | jnettlet | it is not uncommon for manufacturers to change the flash memory used in sdhc's mid run to save money and mix them in so it is harder for QA to tell |
13:26 | jnettlet | flash memory manufacturing in China is a very sketchy business |
13:28 | topi` | yeah |
13:28 | topi` | ideally we would want to have eMMC on the Gate. I need to ask rabeeh on that. |
13:29 | topi` | and ask the customer about their volumes... :) |
13:31 | jnettlet | topi`, you can get that |
13:32 | jnettlet | topi`, you will just need to order them together, because you will need to buy unfused microsoms and then program them to boot from the eMMC by default |
13:33 | jnettlet | but that is all easily doable |
13:33 | jnettlet | and the samsung eMMC we are buying are really good. 60MB/s read and 20MB/s write |
13:39 | topi` | OK, so MicroSOMs need modifications as well? |
13:39 | topi` | I thought they had a boot order like uSD, eMMC, ... ? |
13:43 | jnettlet | kind of, but it takes more than that |
13:43 | jnettlet | so we just stick to sdhc only |
13:47 | topi` | OK |
13:47 | topi` | so, if you have both a HB Gate and HB Edge, the uSOMs are not readily exchangeable? (because of the boot order) |
14:00 | jnettlet | sorry, getting some house work done :) |
14:01 | jnettlet | topi`, well the HB Edge comes with eMMC |
14:02 | jnettlet | we were looking into non-fused boot selection but it was a bit buggy and decided it was best just to rely on the fusing. |
14:06 | jnettlet | topi`, of course this is just for u-boot. Once you have bootstrapped u-boot you can boot everything else from any medium you prefer |
17:52 | vpeter | Question about M.2 socket on ClearFog: It is M type right? But can also accept B+M disk. Correct? |
18:19 | jnettlet | vpeter, the samsung m.2 ssd I have connected right now is B + M keyed |
18:21 | vpeter | Good. So my thinking is correct. |
18:21 | vpeter | First time M.2 user. |
18:24 | jnettlet | yeah it is still pretty new |
18:28 | jnettlet | vpeter, cbxbiker61, so the patches are cleaned up but the rendering isn't quite right yet, so I have a bit more debugging to do on the backports for Kodi. |
18:28 | jnettlet | I am trying to finish it up tonight and integrate it into OpenElec |
18:58 | vpeter | jnettlet: Cool. Put all in -next branch. |
18:59 | jnettlet | vpeter, well it is in a -next branch if you are following HEAD. I am just backporting it to run on upstreams -stable |
19:01 | jnettlet | but then I need to talk with sraue and decide how to integrate the changes. I am already way behind on Kodi work and mk01 and I have some ideas on how to optimize the performance a bit more. |
19:04 | vpeter | jnettlet: Yes, talk with him directly. How many changes you do have and what? Kernel, libraries, kodi? |
19:05 | jnettlet | vpeter, oh it is extensive. From gpu libraries, to properly integrating hardware encryption |
19:05 | jnettlet | including a few optimizations like NEON accelerated libz and a couple of others |
19:07 | vpeter | Ok, so build system itself too. |
19:08 | vpeter | Anyway, sraue will tell. |
19:08 | jnettlet | sure |
19:09 | vpeter | Don't forget to take my last PR for kernel. |
20:47 | vpeter | rabeeh: I assume you can fix SR's web page - the link is dead: http://solid-run.com/blog/hbvsrpi/ |