**** BEGIN LOGGING AT Thu Nov 08 02:59:59 2018 Nov 08 03:13:53 Aw! Nov 08 03:26:24 I got the the nginx name to show on my website so far. Nov 08 03:26:35 Sheesh. Not easy stuff w/out the proper guide. **** BEGIN LOGGING AT Thu Nov 08 04:57:30 2018 **** BEGIN LOGGING AT Thu Nov 08 05:12:34 2018 Nov 08 08:42:16 OOPS I accidentally the MEMS! https://twitter.com/BenKrasnow/status/1060451203316764672 Nov 08 09:42:56 lol Nov 08 09:45:34 Hi, I received a new beagleboard x-15 today, do I need ti prepare SD card or board ia already comes with Linux installed ? Nov 08 09:51:53 you'll never know Nov 08 10:00:14 tbr: a fellow time-nut at JPL will do the same experiment with He and H as well, soon Nov 08 10:00:30 tbr: i withold my judgement until I see it done by someone I trust :) Nov 08 10:02:02 KotH: please keep us posted! I'd be interested to know about the molecular mechanics involved. You'd think frequency would go *up* if it's anything like what happens with vocal chords. Then this is probably going through conditioning and there might be a failure mode down the line. Nov 08 10:02:29 tbr: if it is indeed a leak in the packaging, then it's just simply damping of the resonator Nov 08 10:02:40 tbr: mems stuff is tiny, with very little space around the resonator Nov 08 10:03:10 tbr: there are something like 1-10µm between the swinging mass and the wall Nov 08 10:03:12 but it's not a vacuum, is it? Nov 08 10:03:23 usually it is Nov 08 10:03:42 ah, ok, then it makes sense, He leaks in and resistance goes up Nov 08 10:03:43 all high stability resonators, be it mems or quartz, are under vacuum Nov 08 10:04:38 might be hard to get it back out and into working condition… not sure how the phone as a whole would react to being put in a vacuum to facilitate dissociation Nov 08 10:04:55 but, quartz is usually less sensitive, because packaging is done using a cold-weld stainless steel enclosure and because the virbational mode is mostly a shear mode, with very little movement "outside" the quartz plane Nov 08 10:05:31 i'm sure that all but the display and the barometer can handle vacuum Nov 08 10:05:50 most electronic barometers should be able to handle vacuum as well, but one never knows what kind of cheap shit they use Nov 08 10:06:02 yeah, display was what I thought about Nov 08 10:06:11 i have no idea whether a modern lcd has any problems with vacuum or not Nov 08 10:06:54 I suppose just leaving it to sit for potentially a long while might be sufficient, but wouldn't want to know the value range. :) Nov 08 10:07:04 check the dash on that tesla they sent to mars... Nov 08 10:07:36 all hail Z-order and the mighty AV500! Nov 08 10:07:36 lol Nov 08 10:07:53 * KotH hails Z-order and the mighty AV500 Nov 08 10:08:28 surprisingly it seems that apple actually knew about those risks and put it in their TFM Nov 08 10:08:47 * KotH shrugs Nov 08 10:08:49 someone quoted this: "Der Betrieb des iPhone in Umgebungen mit Industriechemikalien in hoher Konzentration (einschließlich verflüssigter Gase wie Helium nahe der Verdampfungstemperatur) kann zu Schäden am Gerät und zu Beeinträchtigungen der iPhone-Funktionalität führen. " Nov 08 10:09:22 SiTime is pretty open about what their devices can do and what they cannot...at least at conferences Nov 08 10:09:39 I'm not blaming them, was interesting to see that it was in the TFM. Nov 08 10:09:53 -T Nov 08 10:09:56 and the boss seems to know what he is doing... so my guess is they checked for these kind of things and warned their big customers Nov 08 10:10:42 People here will appreciate: https://mamot.fr/@dashcom/101034894356001220 Nov 08 10:10:51 "this wiring is a mess!" Nov 08 10:20:43 looks better than the electrical wiring i've seen in most german flats Nov 08 10:26:08 that batter not be Beyonce's mike amp Nov 08 13:54:50 does a filesystem exist for eeproms? Nov 08 14:00:26 that sounds a bit odd **** BEGIN LOGGING AT Thu Nov 08 14:02:16 2018 Nov 08 14:02:33 because eeproms are typically very small and just used to store some parameters Nov 08 14:02:52 a filesystem sounds like a rather excessive thing Nov 08 14:05:47 small is relative. we will not have a lot of data, but the data can be varied and we don't know a-priori what it is, so "parametrizinhG" it isn't possible Nov 08 14:06:36 our current eeprom is 64KB, but we may increase it if necessary Nov 08 14:07:07 it is certainly off the beaten path, but i thought perhaps it's been done already. Nov 08 14:07:36 is it factory programmed or programmed at runtime? if runtime changes happen, does that include adding/deleting parameters or changing their size? what sort of reliability do you need? Nov 08 14:08:05 runtime Nov 08 14:08:54 a tiny bit of googling yielded "littlefs" Nov 08 14:09:55 is there a reason you're using eeprom rather than flash? Nov 08 14:16:21 yes Nov 08 14:16:26 to extend the life of the flash Nov 08 14:17:56 we need to get 10 years Nov 08 14:18:34 it's an art, not science. we're just looking at ways which aren't too painful to try to ensure we get sufficient flash life Nov 08 14:18:44 10 years doesn't sound like a very long time? Nov 08 14:18:55 statement or question? Nov 08 14:19:51 we currently reconfigure the eMMC into SLC mode with reliable writes enabled and hope for the rest ;) Nov 08 14:19:58 question I guess, I don't have a very good feel for it Nov 08 14:20:26 are you talking about a bbb? Nov 08 14:20:32 yeah Nov 08 14:20:50 i'm cheating/abusing the channel - we're actually using a Variscite DART 6UL SoM Nov 08 14:21:13 based on the i.MX6 Nov 08 14:21:23 how do you get into SLC mode? Nov 08 14:21:28 that doesn't really change anything though Nov 08 14:21:42 SLC mode is a thing of eMMC itself (its one-time-programmable configuration) Nov 08 14:22:11 it sacrifices 50% of the capacity in exchange for (as far as I've been able to find) about 10x increase in durability Nov 08 14:22:19 configuration? where? how? i've never seen such a choice with our SoM, but maybe i've missed it. Nov 08 14:22:30 i think it's a great idea. Nov 08 14:23:02 in fact that was one of my recommendations when i researched this a few months ago. from what i read, that's one of the best ways to improve life Nov 08 14:23:16 i just didn't know you had a choice. Nov 08 14:23:24 in the eMMC configuration. i.e. Nov 08 14:23:34 it can be done with mmc-utils, but since the procedure is tricky, error-prone, and irreversible, I've created a custom branch that adds a command that does all the sanity checks and performs the right steps Nov 08 14:24:06 branch "custom" of https://github.com/dutchanddutch/mmc-utils Nov 08 14:24:19 thanks! Nov 08 14:24:20 see warning in the commit message Nov 08 14:24:29 "may blow up the world"? Nov 08 14:25:21 well it's one-time-programmable configuration, so you permanently lose 50% of your storage capacity. it will also erase the eMMC (obviously) Nov 08 14:25:45 yes, but it's nice to have the choice Nov 08 14:27:11 eMMC has quite a lot of OTP settings, although SLC mode ("enhanced' storage) and various other things are set at the same time as the hardware partitioning Nov 08 14:27:38 (i.e. after using my command you also can't hardware-partition the eMMC anymore) Nov 08 14:28:32 so have you characterized the life in slc mode? doesn't it still depend heavily on how many writes you do? Nov 08 14:28:46 of course it depends heavily on how many writes you do Nov 08 14:29:09 and write amplification will also depend on various factors Nov 08 14:29:20 right Nov 08 14:29:36 so did you get a bottom-line number, or estimate? Nov 08 14:29:47 "X writes per LBA"? Nov 08 14:29:47 not really, since that would require destructive testing Nov 08 14:30:47 we did end up destroying the eMMC on some beagles, due to a "little" mistake in a logging process causing iirc around 16 GB of data written per hour Nov 08 14:31:11 i hate it when that happens.. Nov 08 14:31:20 interesting though! Nov 08 14:31:47 so we probably won't get 10 years writing 16 GB per hour? Nov 08 14:32:07 lol Nov 08 14:32:08 :) Nov 08 14:33:18 I've seen various numbers, but the general ballpark seems to be a few hundred erase cycles for TLC, a few thousand for MLC, a few tens of thousands for SLC Nov 08 14:33:48 i really don't want to use an eeprom filesystem, but i can't justify to my boss why we'll be ok with just using the flash Nov 08 14:33:53 ah! interesting. Nov 08 14:34:03 did you mkean LBA erases? Nov 08 14:34:04 unfortunately I don't know how much write-amplification to expect in practice, and unfortunately the cheapass eMMC on the beaglebone offers no information about how far it is on the road to death Nov 08 14:34:19 I mean flash block erases Nov 08 14:34:28 whether explicit or implicit Nov 08 14:34:31 yeah, i think "flash black == LBA" Nov 08 14:34:36 block Nov 08 14:34:42 isn't it? Nov 08 14:34:50 what's "LBA" ? Nov 08 14:35:18 a flash block is like 4MB or so (but it'll vary a bit depending on the eMMC of course) Nov 08 14:35:22 * yates squeaks.. Nov 08 14:35:28 i'm not sure. Nov 08 14:36:48 so, what eMMC does it use? Nov 08 14:37:02 datasheet says basically nothing about it Nov 08 14:37:15 i don't know Nov 08 14:37:46 and since it's a SoM, they can change it anytime anyway. Nov 08 14:38:21 you mean the dart 6ul datasheet? Nov 08 14:38:25 yeah Nov 08 14:38:42 it just lists the eMMC size and that's it Nov 08 14:38:51 no brand, no eMMC version, nothing Nov 08 14:39:12 they probably want to be free to use whatever they want Nov 08 14:39:27 yeah so like the beaglebone Nov 08 14:40:14 that's definitely a downside to these boards/soms Nov 08 14:40:25 yeah Nov 08 14:41:05 if you build my mmc-utils, sudo ./mmc extcsd read $DEV will dump a lot of info Nov 08 14:41:37 though the easy way to determine the manufacturer/part number is of course simply by visual inspection Nov 08 14:41:51 the erase cycles you quoted are per flash block? Nov 08 14:42:01 yes Nov 08 14:42:39 so, if the wear-leveling is doing its job, that number times the eMMC size would be the amount of data you can expect to write (ignoring write-amplification) Nov 08 14:43:14 right. the eMMC size in blocks Nov 08 14:43:31 bytes, sectors, whatever your preferred unit Nov 08 14:44:03 total writes /device = writes/block * blocks / device Nov 08 14:44:11 no? Nov 08 14:44:14 ehh Nov 08 14:44:34 no, what would be a "write/device" in that final formula anyway? Nov 08 14:44:59 byte writes, i gues Nov 08 14:45:01 guess Nov 08 14:45:05 good question Nov 08 14:45:38 the number of program/erase cycles each block supports indicates how many times each part of the eMMC can reprogram Nov 08 14:46:28 so that number times eMMC size in bytes = lifetime amount of data written in bytes Nov 08 14:47:21 this is assuming writes are equally distributed across the eMMC and blocks are erased as needed, i.e. if the FTL is perfect and no write amplification occurs Nov 08 14:47:34 FTL? Nov 08 14:47:41 flash translation layer Nov 08 14:48:06 the piece of software in the eMMC that hides the quirks of NAND storage and makes it look like a normal block device Nov 08 14:48:14 shouldn't static wear leveling ensure writes are equally distributed across the eMMC? Nov 08 14:48:20 right. Nov 08 14:48:56 basically the controller algorithms Nov 08 14:49:18 yeah, also responsible for the wear leveling and such Nov 08 14:50:28 zmatt: I've heard from $sources that the published numbers are pretty conservative and should be well in line to guarantee the stated number of writes for the entire flash disk Nov 08 14:52:51 zmatt: did you turn off your /var/log logging, or remount that as a tmpfs? Nov 08 14:53:23 yates: I don't have rsyslog installed on any beaglebone. persistent journal is also not enabled by default (just the runtime journal) Nov 08 14:53:51 are you talking about ext4 journals? Nov 08 14:58:08 what? no Nov 08 14:58:35 the journal, as in the thing into which all log messages go on a modern linux system that uses systemd Nov 08 14:58:47 Some eMMC parts also have a pseudo SLC mode you can put them in (reducing the size in half) that will greatly increase the life. See datasheet Nov 08 14:58:57 georgem: yep we use that Nov 08 15:01:14 as for numbers being conservative, the first paper I just found that did some testing found that the wear-out indicator of the eMMC (theirs was polite enough to have one) went up much faster than naively expected Nov 08 15:02:50 hrmmm Nov 08 15:03:14 indicator... Nov 08 15:03:16 of course maybe the indicator is conservative too, Nov 08 15:03:19 right Nov 08 15:03:48 tests until failure would be of more interest but of course would need a reasonably large sample size to mean anything Nov 08 15:06:06 it would help me sleep better at night if the FTL firmware was open source so it could be reviewed Nov 08 15:11:55 yates: oh and once I reconfigured the eMMC to SLC mode I discovered another nice benefit: a huge increase in write performance (despite also enabling "reliable writes" as part of the reconfiguration) Nov 08 15:37:07 that is nice Nov 08 15:37:22 what filesystem are you using? Nov 08 15:37:26 ext4 Nov 08 15:37:30 right Nov 08 15:37:46 with journaling enabled? Nov 08 15:37:54 of course Nov 08 16:07:25 m Nov 08 16:33:41 zmatt: in your mmc-utils command, is $DEV the devfs path? /dev/mmcblk0 e.g.? Nov 08 16:33:58 yep Nov 08 16:35:03 works Nov 08 16:35:07 thanks! Nov 08 16:35:48 https://paste.fedoraproject.org/paste/ua95iqY59dSS3tBQ0BEvGw Nov 08 16:37:19 i thought there would be a vendor/model listed? Nov 08 16:37:23 i don't see it Nov 08 16:38:49 no Nov 08 16:39:07 that information should be in the cid but iirc mmc-utils doesn't decode it well, and the info there is rarely informative Nov 08 16:39:24 that's why I said manufacturer/partnumber is best obtained by visual inspection Nov 08 16:39:33 yeah Nov 08 16:39:59 is there a write cycles spec in the info? Nov 08 16:40:19 (sorry i haven't pored through it all yet) Nov 08 16:40:42 I don't think so but I'm not 100% sure Nov 08 16:40:54 there can be health info in there, but it depends on the eMMC Nov 08 16:55:57 it looks like it is an E7L0940EC (zeros may be "O"s) but i can't find that p/n Nov 08 17:23:03 no recognizable logo? Nov 08 17:25:40 every photo google finds of the bottom side of the eMMC-version of this SoM shows a micron eMMC Nov 08 17:30:36 the big chip on the left here: https://www.eletimes.com/wp-content/uploads/2017/06/DART-6UL-emmc-and-nand-Bottom-1.jpg Nov 08 17:30:37 ? Nov 08 17:31:12 i think that is a KLM8G1GEME Nov 08 17:31:21 couldn't find that either. Nov 08 17:33:35 that doesn't look like a micron part marking. it should be 5 chars Nov 08 17:33:45 the second line Nov 08 17:35:58 for example this would be JW983 : https://www.variscite.com/wp-content/uploads/2018/01/DART-6UL-bottom-side-with-eMMC.png Nov 08 17:36:21 (which is the micron MTFC4GMDEA-4M IT ) Nov 08 17:36:30 https://www.micron.com/support/tools-and-utilities/fbga?fbga=JW983 Nov 08 18:05:59 that's very instructive. thanks zmatt Nov 08 18:16:36 that part is EOL. i cannot find hide-nor-hair about lifetime (P/E cycles, whatever) on the suggested replacement, the suggested replacement MTFC4GACAANA-4M Nov 08 18:16:42 i can't even find the datasheet. Nov 08 18:16:57 mouser says this is the datasheet, i disagree: https://www.mouser.com/pdfdocs/ManagedNAND_eMMCChild.pdf Nov 08 18:19:03 have you tried registering on micron's site to be able to download the datasheet? Nov 08 18:21:04 I also found this preliminary version floating around: https://4donline.ihs.com/images/VipMasterIC/IC/MICT/MICTS06163/MICTS06163-1.pdf Nov 08 21:33:54 zmatt: i finally got it, after registering and going through about a dozen BS screens. Nov 08 21:34:03 thank you. Nov 08 21:34:05 Nov 08 21:49:05 the emmc in the beaglebone-x15 lists 3 disks: /dev/mmcblk1, /dev/mmcblk1boot0 and /dev/mmcblk1boot1. Switching to SLC would erase them? would fdisk -l look the same as but with the reduced size? Nov 08 21:49:38 the boot0/1 partitions wouldn't be affected, they're SLC already anyway Nov 08 21:49:58 fdisk -l would say there's no partition table, since the eMMC would be wiped :P Nov 08 21:50:25 (note: boot0/1 are fixed-size hardware partitions and have nothing to do with the partition table created by fdisk) Nov 08 21:59:00 ok. I use the emmc to store the boot loader and the /boot directory, everything else goes into an SSD drive. Loosing half the capacity wouldn't be bad for me. Nov 08 22:00:21 iirc the x15 (unlike the bbb) also supports actually booting from a boot partition (useful for atomic updates since you can toggle a bit to select which of the two boot partitions is used) Nov 08 22:03:44 the docs said you could boot from SATA but I was never able to. I think u-boot has that disabled and your only choices are emmc or usd. I saw today a thread in the google group where one can turn it on, but I have not tried it yet. Nov 08 22:04:01 well even if you ran entirely from eMMC, losing half of it isn't necessarily a problem. our production beaglebones all use SLC mode and use maybe 0.5G of space on eMMC or so Nov 08 22:05:58 hmm, SATA is definitely a boot mode that ROM has Nov 08 22:13:42 though unfortunately the x15 doesn't make it easy to change the bootmode used by rom Nov 08 22:58:02 early board releases had the jumpers, it didn't work when I tried it. The boot loader itself says usb_boot and scsi_boot are disabled. Nov 08 23:00:30 those jumpers are to select from where rom will load the u-boot. which ways of loading linux are subsequently supported by u-boot is an entirely separate matter Nov 09 02:34:08 so if i turn my encoder suddenly connected to the eqep using the standard kernel driver it gives me large negative numbers instead of increasing. Is this something I should fix with driver options or do I need to change how the encoder is wired? Nov 09 02:34:21 it works fine when turned slowly either way **** ENDING LOGGING AT Fri Nov 09 02:59:58 2018