**** BEGIN LOGGING AT Mon Apr 15 02:59:57 2019 Apr 15 07:44:24 Hi Guys, Can anyone please help me on retaining values even after power loss? Apr 15 07:44:40 I am using BBBW Apr 15 07:49:38 I mean, same as on any other linux system Apr 15 07:51:03 @zmatt, asking me? Apr 15 07:52:32 I didn't ask anything, I replied Apr 15 07:55:55 oh ok thanks. I meant, is there any option available in ti am335x? Apr 15 07:56:55 your vague question isn't hardware-specific. you "retain values" on the beaglebone the same way you do so on any other linux system: write them to a file :P Apr 15 07:57:36 writing into a file and restoring it will not be fail proof right? Apr 15 07:58:08 you may need to take appropriate precautions to avoid data loss if power is lost shortly after writing data, same as on any other linux system Apr 15 08:00:13 In Microcontroller, there is an option to keep it in EPROM. I am checking, is there any option similar to that. Writing it to file every time, IO operation causes unwanted overload to CPU. I am using timer application, it overloads a slot. Writes per second. Apr 15 08:00:25 the safest way is 1. write data to a new file 2. fsync() it (or at least fdatasync()) 3. replace the original file with the new one using a move (rename()) 4. fsync() the parent directory Apr 15 08:00:48 Raj_: if you are writing data to eeprom on a uC with out power fail preconditions you are equally doomed. Apr 15 08:01:10 Raj_: plus you are going to kill every eeprom when you write once per second. Apr 15 08:02:00 indeed, eeprom has maybe 100000 write-cycles? so if you write once per second, you'd wear it out in a day or so? Apr 15 08:02:21 in reality you can probably reach 1.000.000, but hey... Apr 15 08:02:42 okay, two weeks then :P Apr 15 08:14:25 might be better if spread across the eeprom Apr 15 08:15:39 artag: there are always tricks, of course :) Apr 15 08:15:55 I still wouldn't write 1 per second though:) Apr 15 08:42:31 if something really needs to be updated once per second *and* persist, probably the way to go would be to keep it in ram and use a backup battery to write it to persistent memory on powerfail, or use battery-backup ram directly. there are also some more relatively new forms of persistent memory that have very high endurance Apr 15 08:46:04 how do you get an RTC on a BB ? Does it need an external one or is there a battery input ? Apr 15 08:47:26 there is an internal rtc and there are battery terminals, but rtc-only mode is defeatured and requires board patches to use, and it has very high power consumption compared to using a separate rtc (mostly because standalone RTCs can have insanely low power consumption) Apr 15 08:48:00 is there a specific one with kernel support ? Apr 15 08:48:54 most have kernel support I think Apr 15 08:50:18 damn, you can buy FRAM chips that behave like spi flash or i2c eeprom, but have 10^14 write-cycles Apr 15 08:51:46 I'm not sure you can even exhaust that if you continuously write at the max data transfer rate supported Apr 15 08:55:22 ah they actually do the math... if doing continuous sequential writes (opcode + address + 64 bytes) at max spi frequency (40 MHz) it would take 42.6 years to hit the write endurance limit Apr 15 08:56:04 zmatt: so quick, hurry, you can do it before retirement Apr 15 09:07:31 not cheap of course... e.g. €1 for 2 KB, €2 for 8 KB, €8 for 128 KB, €18 for 512 KB (all @ 1ku) Apr 15 09:08:48 zmatt: given the offer of 42yrs worth of entertainment, thats hilariously cheap! Apr 15 09:10:20 42 if you write at max speed Apr 15 09:10:31 more if you don't Apr 15 09:10:43 there is only one valid speed. Apr 15 09:13:42 you'll probably sooner hit the retention limit (which is highly temperature-dependent) Apr 15 09:19:54 artag: I recommend PCF8523. Apr 15 10:01:39 thanks, do i need to load a driver for that or will it check for it ? Apr 15 10:02:00 you need a DT declaration for any rtc... or I guess in theory you could load it at runtime via sysfs Apr 15 10:03:15 i2c is not a discoverable bus, so it won't magically appear Apr 15 10:10:06 the DT fragment required is pretty trivial though: https://github.com/mvduin/overlay-utils/blob/master/i2c2-pcf8523.dtsi Apr 15 10:11:07 ta Apr 15 11:48:05 hi there! does anyone have a mehanical drawing documentation for Baglebone black board? **** BEGIN LOGGING AT Mon Apr 15 18:56:52 2019 Apr 15 19:58:08 Hello, I downloaded 9.5 from Beagle.org. What is the default password for sudo? live does not work. Thanks Apr 15 19:59:56 Jake: what password did you use to login? Apr 15 20:07:29 I lost connect. I D/L an image to a SD card and booted from the SD Card. done same on 7.11 and 8.3 without needing a P/W. Apr 15 20:08:59 the default username and password are in the getting-started guide, which is the first result I get when I google for "beaglebone password" Apr 15 20:10:53 root login via ssh using password authentication is disallowed by openssh server in its default configuration for security reasons, and beagleboard.org has adopted that default quite a while ago already (also for security reasons) Apr 15 20:11:51 for the rare case root privileges are needed, just use sudo (which asks for the password of the account you're logged in to) Apr 15 20:13:48 Thanks. I will try that. Apr 15 20:16:14 Hi zmatt, that P/W worked. Thanks to all. **** ENDING LOGGING AT Tue Apr 16 02:59:57 2019