**** BEGIN LOGGING AT Mon Nov 11 02:59:57 2019 Nov 11 11:11:54 hello Nov 11 11:13:52 i'm wondering if (or how much) i'm killing the BBB eMMC by writing log files and other data while running my app.... Nov 11 11:14:49 if i'm risking to mess the whole partition in case of power shortage while writing, if making a small partition just for my data will help or will change nothing Nov 11 11:14:56 any tought? Nov 11 11:21:04 so there are two separate questions here: one concerning eMMC lifetime, and the other concerning filesystem integrity Nov 11 11:21:29 yup. they're related, but two different questions Nov 11 11:30:42 they're not that strongly related though, except that MLC flash makes both of them more problematic. we currently try to tame both of them by reconfiguring the eMMC into (pseudo)SLC mode and the latter by also enabling "reliable writes" (these are both done at the same time as part of OTP configuration of the eMMC), and we try to minimize unnecessary writes to eMMC. we don't know for sure how much ... Nov 11 11:30:48 ...this helps, it's just our best guess at maximizing eMMC lifetime and reliability. our products are never cleanly shut down, they're always just turned off (but there's a decent chance many users will just leave them on all the time). we have not yet had a single case of a system failing to boot due to filesystem corruption. we had managed to destroy a few eMMCs with excessive writes. in some cases ... Nov 11 11:30:54 ...this was due to a serious software mistake causing excessive continuous data writes (like gigabytes per hour), in at least one case I'm unsure how it managed to get destroyed Nov 11 11:31:38 zmatt: that one case was me. with a sledge hammer Nov 11 11:32:18 (reconfiguring eMMC from MLC to SLC does sacrifice 50% storage capacity, but we use less than 0.5G so we don't really mind that) Nov 11 11:32:21 letothe2nd: :P Nov 11 11:32:46 zmatt: at least i'm being honest! Nov 11 11:33:58 Parduz: so far, eMMC wearout has manifested itself by the eMMC controller suddenly becoming unresponsive (deadloop?) on an attempted write. once in that state, after power cycling the eMMC we could still dump the eMMC contents but any attempt to write would again lock up the eMMC Nov 11 11:34:51 ok, well, at least it boots. Nov 11 11:35:06 it doesn't, mounting a filesystem includes a write Nov 11 11:35:51 uh, right. :\ Nov 11 11:36:02 (and any write locks up the eMMC controller so no further reads are possible anymore either) Nov 11 11:38:20 SLC will not be doable for me in a short term, given the space i still need. Nov 11 11:40:01 the two questions were related 'cause if the eMMC lifetime will become too short by wrting on it, i don't care anymore about filesystem integrity: i'll need to switch to a eeprom storage solution Nov 11 11:41:47 otherwise i could accept to slowly kill the eMMC if the expectancy of life is high enough, and then i'm concerned about not messing up the partition if the BBB will be shut down while writing Nov 11 11:41:54 I'm not sure which will have longer lifetime, it'll depend on how much free space there is on eMMC (be sure to run "sudo fstrim /" at least once and whenever a lot of space has been freed up) and the quality of the wear leveling algorithm Nov 11 11:42:49 the limited lifetime is an intrisic limitation of flash memory, in all its manifestations (including eeprom and eMMC) Nov 11 11:45:39 mounting readonly shouldnt include a write (beyond an entry in mtab which should live in a pseudo filesystem anyway) and if your boot is clever enough it falls back to readonly mounting after failure (that indeed needs in initrd) Nov 11 11:45:51 if you really want insane write lifetime, get e.g. an F-RAM/FeRAM (Ferroelectric RAM) device... e.g. cypress offers smallish (4Kbit-4Mbit) devices (with eeprom-like i2c or spi interface) with lifetime up to 100 trillion write-cycles Nov 11 11:47:20 ogra: the problem is that we need it mounted read/write normally, and when the eMMC has failed attempting to mount it rw will cause the eMMC to become unresponsive hence you can't then mount it ro Nov 11 11:49:10 right, not sure what debian does here (i think they do the same) but in ubuntu we alwys have ro on the cmdline and the rw remount only happens in initrd ... that at least gives you a chance to inspect the breakage since you got enough OS boothed for inspection Nov 11 11:50:37 a device that's in initrd is for us effectively equivalent to a dead device, and there's not really any utility in being able to "inspect" a device in initrd (especially when the eMMC is inaccessible) Nov 11 11:50:53 thats indeed moot on locked down products where you dont enable a fallback shell etc Nov 11 11:51:17 the serial console is not accessible in any practical way Nov 11 11:51:29 and I wouldn't have any use for it in this situation even if it were Nov 11 11:53:08 right, then this is moot Nov 11 11:54:08 still, there are technically ways to recover your data in readonly mode ... thats what i meant to point out Nov 11 11:54:08 Parduz: note that when in MLC mode without reliable writes enables, power loss during a write may corrupt seemingly unrelated sectors of the eMMC, not just the ones that were being written when the power loss occurred, so a separate partition may not help Nov 11 11:54:55 that's a useful info, thanks Nov 11 11:55:10 ogra: yes but the device will need to get swapped out for a new one anyway, and then I just boot the dead device from a flasher card, make a backup of its entire eMMC, flasher that onto a new beaglebone, and stick it back into the device (and then of course try to investigate why it was writing so much to eMMC) Nov 11 11:55:42 true ... Nov 11 11:57:15 Parduz: also, I don't know if these eMMC will periodically rewrite existing data even if you don't explicitly write to it... but it probably should since data stored in nand flash also slowly degrades over time due to reads (but this isn't permanent damage and is fixable by rewriting the data to a new location) Nov 11 11:57:29 my guess would be that "background operations" need to be enabled for that, and it's not by default Nov 11 11:58:10 Parduz: isn't flash fun? :D Nov 11 11:59:47 lol Nov 11 11:59:53 not really :) Nov 11 12:03:07 unfortunately magnetic core memory isn't really available anymore ;) well I guess there's mram, but they're still pretty small I think Nov 11 12:04:04 (mram has no wearout and data retention exceeding 20 years at 125͏°C) Nov 11 12:08:05 “Developed in the mid-1980s, proponents have argued that magnetoresistive RAM will eventually surpass competing technologies to become a dominant or even universal memory.” Nov 11 12:08:28 Emphasis on “eventually” I guess Nov 11 12:09:04 yeah it's reaaally hard to compete existing ram and flash devices fabricated on the latest technology nodes Nov 11 12:09:50 while also having to compete with other new non-voltage storage techologies with similar benefits Nov 11 12:16:05 So it’s a case of the best marketing & not the best tech winning? Nov 11 12:16:23 probably both I guess, dunno Nov 11 12:16:38 ¯\_(ツ)_/¯ Nov 11 12:17:45 you mean we should replace eMMC with VHS tape ? Nov 11 12:17:56 it's probably partially solving technical problems and partially getting some party to make the gamble of investing in fabrication on a more recent technology node to get competitive density/pricing. but I'm not deeply into the subject matter, this is just my impression based on bits I've read over the years Nov 11 12:18:13 The science goes straight over my head but with my kindy grade understanding it sounds cool Nov 11 12:18:34 ogra: hey, DVHS had pretty good storage density and okay transfer rate... seeking was just a bit slow Nov 11 12:18:45 :D Nov 11 12:20:00 okay no transfer speed was kinda meh.. well maybe it was good at the time (28.2 Mbps) Nov 11 12:20:22 but 50GB in 1998 seems not bad Nov 11 12:20:34 I’ve seen VDSL2 that’s slower -_- Nov 11 12:21:09 well if your local storage is as slow as your internet connection, your local storage sucks :P Nov 11 12:30:58 I am using Beaglebone Black 4.14.71-ti-r80. Can anyone please help me on falcon setup? Nov 11 12:31:42 I never bothered with falcon, I just recompiled u-boot with some changes to make it not slow :P Nov 11 12:33:52 i.e. no delay before booting, and a highly simplified boot script... https://github.com/dutchanddutch/u-boot/commit/a55fd0c64ae8a2a894facbc52f24374f6e971407#diff-5c68b76c6be7687729e16852a89fd5b6L98 Nov 11 12:34:40 Indeed Nov 11 12:34:59 I doubt falcon would be much faster than that Nov 11 12:35:24 making the kernel smaller and not using initrd helps a lot too, less stuff for u-boot to load from eMMC Nov 11 12:35:53 (note my simplified boot script doesn't even support initrd) Nov 11 12:40:30 Thanks zmatt. Will try it out and get back to you if required any. Nov 11 15:32:53 Hi Nov 11 15:33:30 how are you every body ? Nov 11 15:33:44 i have a qustion ? Nov 11 15:35:34 i am using BBB to build my 3d printer and am using a Bebopr ++ Nov 11 15:36:23 my question ist : Which firmeware is the best to use it in my situation! Nov 11 15:37:13 I would like to have tow extruder Nov 11 15:39:13 i have seen there is a firmware from Mr.Bas Laarhove but its just for one extruder Nov 11 15:48:20 uhh Nov 11 15:48:40 I'm confused why you think the "firmware" is relevant for the number of extruders Nov 11 15:59:38 sorry but i dont have a high expierence and thats the first project with 3d printer Nov 11 16:02:09 I have read the firmware from Mr.Laarhove and it was for 4 Axis Nov 11 16:03:17 I have no idea what you're referring to, can you provide a link? Nov 11 16:05:03 sorry i mean this firmware : Nov 11 16:05:05 https://github.com/modmaker/BeBoPr Nov 11 16:07:29 that seems to be a specific hardware + software solution, not "firmware" Nov 11 16:07:35 it also appears to be ancient and unmaintained Nov 11 16:09:55 there's also the "replicape" but it no longer seems to be sold, instead they're working on a custom board (basically beaglebone + cape integrated into one) Nov 11 16:26:26 Yaman: sadly modmaker passed away, his designs were some of the best at the time, but you should lookat the machinekit guys for upgraded hardware.. Nov 11 16:26:38 replicape is no longer being designed, he's doing other things now.. Nov 11 16:46:38 which way I use GPIO pin using PRU from Karnel? **** ENDING LOGGING AT Tue Nov 12 02:59:57 2019