**** BEGIN LOGGING AT Sat May 25 02:59:58 2019 **** BEGIN LOGGING AT Thu May 30 09:28:10 2019 May 30 10:04:48 i'm using beagle board in debian 9 os this is support Mongo DB ? May 30 10:06:38 Mongo DB support is support or not ! in this Beagle Board im using on linux debian 9 os. May 30 10:12:36 hardware runs software May 30 10:13:08 there is no way to tell if the software will run in an acceptable manner for *your* use case **** BEGIN LOGGING AT Thu May 30 11:38:25 2019 May 30 12:32:41 hi, i'm a noob here and i wanted to ask is it possible to connect arduino displays to pocketbeagle? May 30 12:37:47 I have no idea what an "arduino display" is, especially since the name "arduino" is nowadays used for a collection of boards that use a variety of completely different microcontrollers May 30 12:44:01 oh he left, figures May 30 13:05:54 I think the correct answer is 'probably, but be careful of the bus voltage'. A lot of things made for arduino are 5v May 30 13:06:37 but the majority are i2c/spi/serial so easily supported by a bb May 30 13:12:17 that's roughly what I'd have said if he bothered to stick around **** ENDING LOGGING AT Thu May 30 17:08:18 2019 **** BEGIN LOGGING AT Thu May 30 19:16:09 2019 May 30 20:10:29 what do you think of mounting the emmc with the discard option, regardless of whether it's the boot device or not? May 30 20:13:01 dabbler, i thought i enabled that. ;) via fstrim package May 30 20:16:23 rcn-ee[m]: umm well the debian stretch console image i've just flashed doesn't have the discard option in fstab, and i don't think the ubuntu console image i was using previously did either. is it that with the fstrim package installed, you don't need to put it in fstab? May 30 20:18:40 dabbler, the fstrim package, doesn't add a fstab option, it's a systemd service, that runs periodically.. May 30 20:23:18 oh, interesting. how does that approach compare to trimming at the time of deletion? May 30 20:23:41 is there an advantage? May 30 20:37:14 in theory, typically the average user won't be doing a massive number of read/writes.. if they do, then discard would be better.. but for the generic install the cron based fstrim should be better.. May 30 20:37:57 remember, if you add it to fstab, then every read/write will be hooked up to discard, so your through-put will fall thru.. May 30 20:40:12 oh. i didn't realize a trim deletion took any longer than a non-trim deletion May 30 20:41:25 i thought trim just consisted of telling the flash controller that the block was no longer used, and that the controller didn't actually take any action until the next garbage collection cycle May 30 20:42:27 first, perhaps i should say that i'm under the impression that discard is just a synonym for trim in this context, so if that's wrong, correct me May 30 21:08:03 rcn-ee[m]: I mean, discard shouldn't have much effect on performance since it only affects block deallocation May 30 21:09:44 however it's not always a good idea since the (original) trim command requires the block to be zeroed, so if the eMMC doesn't have a convenient way to mark the requested region as deallocated it may have to take the time to explicitly write zeros to it May 30 21:10:37 iirc the eMMC standard at some point introduced a command to tell the eMMC some region is no longer important without imposing the requirement to erase it May 30 21:11:46 so provided that the eMMC supports the new command and linux uses it, the "discard" flag should be safe to use without risk of causing additional writes May 30 21:12:18 otherwise it's better to just occasionally use the fstrim command (especially after freeing up a lot of disk space) May 30 21:15:59 ah yeah, the new command (actually called "discard") was added in eMMC 4.5 May 30 21:58:51 and what version of emmc does beaglebone use? May 30 22:04:15 hmm playing with the mmc tool right now. supposedly it lists capabilities May 30 22:10:07 darn: MMC 4.41 May 30 22:14:01 "Card Supported Command sets [S_CMD_SET: 0x01]" what does a value of 1 mean? May 30 22:16:33 emmc version depends on how recently your bbb was manufactured May 30 22:17:09 command sets are an obscure thing and not relevant for emmc May 30 22:17:49 they're related to some DRM feature in old MultiMedia Cards May 30 22:52:53 it's not the set of commands that the controller supports? lovely May 30 22:53:20 I mean, it is, but not in a sense that's relevant here May 30 22:54:18 a command set is literally a completely different set of commands you could switch to May 30 22:55:45 oh i see May 30 22:56:29 it is frustratingly difficult to find out how to interpret the output of the extended CSD by googling May 30 22:56:44 I downloaded the spec from jedec May 30 22:57:34 god, the results are all random code files from various projects May 30 22:57:48 https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf (requires free registration) May 30 22:58:15 it's not the most readable or well-organized spec I've ever seen :P May 30 22:58:26 so much for open standards May 30 22:58:56 free registration doesn't strike me as unduely burdensome May 30 22:59:33 but what terms are they requiring you to agree to? money isn't the only way you can be charged May 30 22:59:38 it's better than SD cards where the full spec is only available for paying members May 30 23:00:14 oh dunno, nothing important, I think just my firstborn child or something May 30 23:00:25 joke's on them, I don't want any kids May 30 23:02:11 any chance you'd share the pdf with a link? :) May 30 23:02:46 docdroid.net looks promising May 30 23:03:50 just register.. the conditions are basically "don't distribute our stuff without permission", that's it May 30 23:04:08 the whole agreement is 4 paragraphs May 30 23:04:33 bastards. why should they care? May 30 23:05:56 because it's their work? May 30 23:06:07 it's a standards document! May 30 23:06:26 isn't the whole point for people to know the standard so they can follow it?! May 30 23:06:56 yes... and? May 30 23:07:25 in which case unlimited proliferation should be a good thing May 30 23:07:27 every eMMC manufacturer is probably a JEDEC member anyway, and anyone who isn't can download the full standard after free registration May 30 23:09:03 it doesn't need unlimited proliferation, it's basically an agreement between the major eMMC manufacturers May 30 23:09:24 similar to the SDRAM specs May 30 23:09:34 (which are also from JEDEC) May 30 23:10:13 it doesn't need it, but why would it hurt? May 30 23:10:33 only thing it protects is their ability to start charging for it in the future May 30 23:11:21 and I can understand not wanting to agree to annoying terms and conditions (I for one declined the one nvidia wanted me to agree to to get info about their SoCs), but this one is literally a few paragraphs containing basically no conditions (since what they say is already obvious or covered by copyright law anyway) May 30 23:11:52 so I think you're being silly and making a fuss over nothing here May 30 23:12:52 yeah they *could* charge for it, and in fact most standards organizations require you to pay a lot of money for any of their standards May 30 23:14:44 i guess i don't care so much what they do with the standard doc itself as long as the info contained within it is freely available, which based on google results does not seem to be the case here May 30 23:18:29 you don't have to go to whomever laid out the SMART standard to learn what the attributes mean, for example May 30 23:24:58 sorry, i'm a bit salty about people today :p May 30 23:36:09 anyway, what're peoples' thoughts on using F2FS instead of ext4 in the images? May 30 23:42:41 at least as an option that can be enabled by modifying the image (similar to turning it into a flasher) May 31 00:07:21 also, any idea of the write performance impact of enabling write reliability in the eMMC? **** ENDING LOGGING AT Fri May 31 02:59:58 2019