**** BEGIN LOGGING AT Fri Jun 12 02:59:58 2020 Jun 12 03:18:01 what is typical RTS or CTS in serial comms Jun 12 03:18:19 I have no idea what you mean by that question Jun 12 03:18:34 i have a RS232 to TTL adapter Jun 12 03:18:40 it has male port on it Jun 12 03:18:56 but it also has two jumper options RTS Jun 12 03:19:00 and CTS I can enable Jun 12 03:19:09 I can show manual Jun 12 03:19:10 one sec Jun 12 03:20:02 https://images-na.ssl-images-amazon.com/images/I/71mo9IoyFVL.pdf Jun 12 03:20:25 if I figured I did not need either one Jun 12 03:20:31 so I took the jumpers off Jun 12 03:20:51 but I am getting junk back in my loopback test Jun 12 03:21:04 rts/cts has no influence on data Jun 12 03:21:48 (and if you're not using rts/cts-based hardware flow control then it doesn't matter whether the jumpers are present or not) Jun 12 03:22:29 do I need to worry about logic level Jun 12 03:22:39 Serial is 5V Jun 12 03:22:59 I'd just leave them in the rightmost configuration ("RTS/CTS HW handshake") ... removing them is fairly pointless and the loopback connection is only for very obscure cases Jun 12 03:23:09 ehm, the whole point of this thing is to convert logic levels Jun 12 03:23:15 right Jun 12 03:23:33 just making sure not sure wahts going on I will put back the jumpers in handshake Jun 12 03:23:44 " Serial is 5V" ... that's a nonsensical statement Jun 12 03:24:09 in the manual it has 3.3V to 5V Jun 12 03:24:18 both sides of your converter are "serial" Jun 12 03:24:24 yeah, that description in the manual is also wrong Jun 12 03:24:36 oh never mind Jun 12 03:24:45 lol Jun 12 03:24:46 they don't mean conversion between 3.3V and 5V Jun 12 03:24:58 they mean the logic level can be 3.3V to 5V (depending on VCC supplied) Jun 12 03:25:10 with the other side being RS232 Jun 12 03:26:00 so it's probably a MAX3232 or similar IC Jun 12 03:27:29 another question is there a way to prevent the BBB from powering on as soon as it sees power Jun 12 03:27:39 either usb or barrel jack Jun 12 03:27:41 no Jun 12 03:27:46 i got my LCD cape back Jun 12 03:28:11 and I need to have the barrel jack go first or else it wont start Jun 12 03:28:20 kind of a pain in the ass Jun 12 03:30:50 sounds like your cape sucks Jun 12 03:31:07 well i am in too deep Jun 12 03:31:22 i need to be more shrewd on purchases Jun 12 03:31:59 so if you were developing a product how do people power the beagle Jun 12 03:33:28 I think I already said so last time, but if the inrush current of the backlight during power-on is the problem then removing R1 might help (to prevent the backlight from being immediately turned on Jun 12 03:33:32 ) Jun 12 03:33:55 yeah but that required soldering and stuff Jun 12 03:34:02 not confident I could pull that off Jun 12 03:34:02 depends on the situation, either via barrel, via usb, or via the cape header Jun 12 03:35:17 for a random beagle probably usually via usb since it's generally easier to find a usb charger or usb port to power a beagle than to find a suitable 5V adapter with barrel jack Jun 12 03:36:49 this thing is a piece of crap Jun 12 03:37:04 I put power to the module and disconnects the beagle Jun 12 03:37:13 the RS232 module Jun 12 03:37:14 "disconnects" ? Jun 12 03:37:19 what do you mean? Jun 12 03:37:42 so I have the Tx and Rx plugged in and then I connect GND to the BBB GND pin Jun 12 03:37:44 also what do you mean by "put power to the module" ? Jun 12 03:37:51 wait what Jun 12 03:38:08 when I plug in the 3.3V pin into the 3.3V pin on the BBB Jun 12 03:38:23 absolutely never NEVER EVER have signal wires connected while no GND wire is connected Jun 12 03:38:49 GND should be the very first thing to connect and the last thing to disconnect Jun 12 03:39:14 ok Jun 12 03:39:26 so connecting GND Jun 12 03:39:40 GND, then power, then signals. or better yet, connect all of them while the whole thing is powered off and only then power things up Jun 12 03:40:29 but if you are hot-connecting... first GND, then power, then signals Jun 12 03:40:51 ok so I have GND and PWR Jun 12 03:40:54 its ok Jun 12 03:41:00 now I will do Tx Jun 12 03:42:16 ok Jun 12 03:42:22 now it is not complaining Jun 12 03:42:25 note that "tx" on this thing is the input on the TTL side (output on the RS232 side) hence would connect to the uart txd on the BBB Jun 12 03:43:23 (fortunately they've drawn arrows showing the data direction, which helps to avoid the ambiguity of "tx" and "rx" whose meaning depends on perspective) Jun 12 03:43:48 i bought it since it had a manual Jun 12 03:43:51 =) Jun 12 03:45:00 if I change connections I should unplug everything Jun 12 03:45:15 not sure I'd call this 4-slide powerpoint presentation a "manual", but at least it's something :P Jun 12 03:45:24 so I was connectiong Tx to Rx Jun 12 03:45:26 depends on what you mean by "change connections" and "unplug everything" Jun 12 03:45:29 now I want to put in the device Jun 12 03:47:02 in other words you connected output to output... you might want to try not doing that, it's not good for your hardware's longevity Jun 12 03:47:24 so by "disconnects the beagle" earlier you meant "I caused a short-circuit hence my beaglebone shut itself off" Jun 12 03:48:29 yeah it was probably in mortal danger yes Jun 12 04:09:53 ok what would be the difference between Putty and py serial Jun 12 04:09:59 same computer Jun 12 04:10:06 if I use putty to open the serial port works Jun 12 04:10:11 if I use py serial Jun 12 04:10:13 doesnt Jun 12 04:10:35 probably just doing something wrong with pyserial Jun 12 04:10:48 should be exactly the same Jun 12 04:10:59 so the only thing I specify is port Jun 12 04:11:07 '/dev/ttyUSB0' Jun 12 04:11:09 buad rate Jun 12 04:11:11 9600 Jun 12 04:11:16 and timeout=0 Jun 12 04:11:21 am I missing something Jun 12 04:12:02 you're running putty on linux? o.O Jun 12 04:12:34 I do all the time? Jun 12 04:12:34 yes Jun 12 04:12:39 just to check Jun 12 04:12:46 before I headbutt this thing Jun 12 04:12:49 also be sure to close the putty session before opening the port with pyserial Jun 12 04:13:03 so you don't try to use the same serial port in two applications Jun 12 04:13:13 right I did that Jun 12 04:13:17 no dice Jun 12 04:13:22 something is missing Jun 12 04:13:32 same cord nothing change other than putty vs pyserial Jun 12 04:13:36 what are you doing with pyserial and what result are you expecting vs getting? Jun 12 04:14:24 so in Putty I connect to /dev/ttyUSB0 Jun 12 04:14:29 if I send FFV Jun 12 04:14:33 i get V1.09 Jun 12 04:14:40 if I do the same in pyserial Jun 12 04:14:45 I send b'FFV' Jun 12 04:14:49 I get nothing back Jun 12 04:14:57 both are at 9600 baud rate Jun 12 04:15:09 because you forgot to include the enter at the end Jun 12 04:15:40 b'FFV\n' Jun 12 04:15:41 ? Jun 12 04:15:47 which I mentioned last time, the documentation didn't really clarify whether the commands are terminated by CR (b'FFV\r') or NL (b'FFV\n') but I'd try CR first Jun 12 04:16:27 its \r Jun 12 04:16:29 ok Jun 12 04:16:32 there it is Jun 12 04:16:42 putty must terminate transmission for you Jun 12 04:17:53 no, you press enter Jun 12 04:18:14 so putty sends an enter (which I think is a CR) Jun 12 04:18:35 i press enter in pyserial too =) Jun 12 04:18:52 no, you weren't Jun 12 04:19:49 you were sending three bytes, 'F', 'F', and 'V' Jun 12 04:20:08 there isn't going to magically be a CR after that unless you send one Jun 12 04:21:07 zmatt: have you found the CR key on the keyboard yet?! ;) Jun 12 04:21:31 s/have/haven't/ Jun 12 04:21:51 forgot what window I was in Jun 12 04:21:58 restarted my laptop =) Jun 12 04:25:57 ok I am back where I started with MAX3232 not getting the job done Jun 12 04:26:32 can send bytes no response Jun 12 04:27:17 would changing the logic level be bad Jun 12 04:27:23 so right now I have 3.3V Jun 12 04:27:33 "be bad" ?? Jun 12 04:27:34 would I fry my board powering at 5V Jun 12 04:27:41 yes Jun 12 04:27:56 (not the max3232 but your beaglebone) Jun 12 04:28:28 ok didnt do it =/ Jun 12 04:29:08 it would be really great if, after all this time, you slowly started to get *any* sort of mental model of how electronics works Jun 12 04:30:21 since connecting stuff pretty much at random (and you're giving the impression that's pretty much what you're doing) will fry hardware sooner or later, and most likely the beaglebone Jun 12 04:31:25 well I did not connect them Jun 12 04:32:03 i get random when things dont work Jun 12 04:33:33 you may want to test whether the uart txd pin still works (in gpio mode or using a loopback connection to uart rxd) to verify you didn't damage it when you misconnected the max3232 earlier (or whatever that "ttl" to rs232 converter is you're using) Jun 12 04:33:54 you shouldn't get random, especially when things don't work Jun 12 04:34:00 when things don't work, get systematic Jun 12 04:35:16 FINALLY!!!! Jun 12 04:36:29 i dont have the schematic but this must be different from the other MAX32323 I had Jun 12 04:36:55 well the other max3232 you had had absolutely zero information Jun 12 04:37:04 true true Jun 12 04:37:11 I don't know why you _again_ bought something that didn't have a schematic Jun 12 04:37:24 seems like an odd choice to me Jun 12 04:37:46 well I wrongly assumed that the document would have it Jun 12 04:38:00 I did not scroll through Jun 12 04:38:08 why would you assume that instead of just reading it? it's FOUR PAGES Jun 12 04:38:22 COVID-19 Jun 12 04:38:27 joking Jun 12 04:38:29 i dunno Jun 12 04:38:54 why make a little thing and NOT put a schematic Jun 12 04:39:33 why make assumptions about what is or isn't in the four-page document instead of just checking what's in the four-page document? Jun 12 04:39:51 if your beagle bone is in product how do you handle shutdowns and power offs Jun 12 04:39:55 regardless, the documentation looked adequate to me Jun 12 04:40:25 well it is functional Jun 12 04:40:31 we don't, people just flip the switch that cuts power to the whole product Jun 12 04:40:49 that is ok for the beagle to not get shut down properly Jun 12 04:41:08 though we do reconfigure eMMC to SLC mode to hopefully prevent corruption Jun 12 04:41:28 (since MLC flash is particularly unhappy about power cuts during writes) Jun 12 04:42:08 do you have to program around that or is that pretty trivial Jun 12 04:42:19 around what? Jun 12 04:42:30 reconfiguring the eMMC Jun 12 04:42:34 to SLC Jun 12 04:42:45 is that something one worry about while developing Jun 12 04:44:04 no our flashing tool does that before flashing the eMMC with our image (reconfiguring eMMC to SLC mode will implicitly wipe it, and you also lose 50% of capacity since it now stores only 1 bit per cell instead of 2 bits per cell) Jun 12 04:46:57 * zmatt zZ Jun 12 04:47:58 zmatt: treated myself to a https://www.element14.com/community/docs/DOC-81966 since it was like £11 on offer Jun 12 04:48:22 might have to 3D print a frame/cover for it though Jun 12 04:48:59 hopefully it won't be a giant PitA to get working Jun 12 04:49:36 And a BB-blue too :/ on a good discount also Jun 12 04:49:42 it was an expensive week lol Jun 12 04:50:05 i think he is sleeping Jun 12 04:50:15 likely I just missed him Jun 12 04:50:20 it is silly-am for Europeans Jun 12 04:50:22 yeah I wore him out Jun 12 04:50:34 many people do :/ Jun 12 04:50:50 i give him a lot of credit Jun 12 04:51:27 I never see the other mods Jun 12 04:52:06 i probably should of got that lcd cape Jun 12 04:52:10 is yours touch Jun 12 04:52:21 yeah touch too Jun 12 04:52:53 i got the following has been giving me problems https://www.newhavendisplay.com/nhd70ctpcapev-p-9536.html Jun 12 04:53:05 anyway hitting the hay Jun 12 05:04:34 Not having seen the bottom of the board, which must have all the blazing camera interfaces etc. on it, I don't understand why only 1GB DDR4. Here there are a bunchload of CPUs being served and I'm thinking maybe not everything can be memoized before passing. Slay me with how wrong I be. Jun 12 05:10:25 Log video data somewhere else, train models fast and break things on the Sitara platform that is Beaglebone AI? Not even a slide out of usual suspects panovision-in videocameras on the product selection nibbles on productpage left? Jun 12 05:11:12 Sidereal midnight just doesn't bring out the chatty solar powered mcu fans. Later! Jun 12 11:51:38 wat Jun 12 12:23:27 I have no idea... Jun 12 12:30:15 some kind of chat bot? Jun 12 12:36:29 challenge for every neural network to recognize patterns, but I guess he's complaining that the AI only has 1GB of memory, with all the camera interfaces, but the rest is gibberish Jun 12 12:37:10 "all the camera interfaces" ? :P Jun 12 12:37:17 the kind of gibberish a fairly good text generator might produce Jun 12 12:40:21 some actual text generator output: Jun 12 12:40:23 Another interesting thing here is that both the LCD and the RF card interface is going to be pushed down in the Raspberry Pi so as not to be obscured by other peripherals. Unfortunately the Pi is an LCD device and as such isn't good at rendering high resolution images, so there's probably not a whole lot of fun to be had on that front. Jun 12 12:47:31 I guess it still has three video inputs... sort of: https://pastebin.com/Lm1KnHXr Jun 12 12:48:23 mru: no, I can actually understand what he said motsly, I don't think it was a chatbot Jun 12 12:48:32 unlike what you just pasted, which really is just random gibberish Jun 12 12:49:41 though it did look like he's more interested in being an ass than in being informed Jun 12 13:02:23 oh nice, the only full video input interface on the bbai is not an ioset Jun 12 13:08:43 because the clock pin of its ioset has been used as usb vbus detect gpio, lol Jun 12 15:23:50 jkridner[m]: is it an oversight that the bbai's only 16/24-bit video input is missing the (rather important) pixel clock signal in the same ioset? :P Jun 12 15:24:11 probably. Jun 12 15:24:31 https://pastebin.com/Lm1KnHXr Jun 12 15:24:32 I tried to use the pinmux tool to tell me what was needed for a 16-bit VIN.... Jun 12 15:24:43 overlapping with the VOUT. Jun 12 15:25:14 pinmux tool didn't catch this? well that would definitely be a bug Jun 12 15:25:17 I think we may have just missed the rev A2 window. can you input an issue and propose a fix? Jun 12 15:26:04 is there a nice small imaging processing package for embedded platforms Jun 12 15:26:12 I looked up what that pin is used for.. it's used as a random gpio (for an usb detection signal) Jun 12 15:27:02 going for the quadrature today Jun 12 15:27:17 Lots of people use Beagle for IoT/IIoT. Jun 12 15:34:29 zmatt: which signal is the pixel clock? Jun 12 15:34:44 oh, nevermind... Jun 12 15:34:53 just missed seeing it in the tool. _clk :-) Jun 12 15:37:58 I hate that sysconfig doesn't show the ball numbers in the pull-down. Jun 12 15:40:09 my notes indicate that vin4a_clk was the one I intended to work. Jun 12 15:40:15 when setting pins your overlay how do you know if you should pull up or pull down Jun 12 15:40:48 jkridner[m]: is that P9.22a ? because that belongs to a different ioset (https://pastebin.com/Lm1KnHXr) Jun 12 15:41:32 yes. :-( Jun 12 15:43:24 the tool today tells me there is a resource conflict. Jun 12 15:43:59 with a bit of luck it only matters at very high clockrates, at which point I think things are going to get interesting from a signal integrity perspective anyway, getting a high-speed parallel interface across the BBAI's headers with no ground pins nearby Jun 12 15:44:25 man, ioset2 was so close. Jun 12 15:44:46 it is, and that pin (116) is used for something silly too Jun 12 15:44:48 how could you manage without the clock? Jun 12 15:44:58 you could just violate the ioset Jun 12 15:45:25 does that work? just not characterized? Jun 12 15:45:52 * jkridner[m] thought iosets went away with the AM572x crazy not-near-the-pin pinmuxing. Jun 12 15:46:20 honestly it's a mystery to me why iosets are still a thing given that every single pin has individually configurable delay Jun 12 15:48:54 I feel like ioset violations can be worked around using suitable manual iodelay values Jun 12 15:49:18 if not, I'd love to hear the explanation of why not Jun 12 15:49:27 exactly.... I didn't think this chip had iosets that mattered, but perhaps only certain combinations get characterized so that those values can be published. Jun 12 15:51:00 well, I've got to run and get gas for the generator that just run out. Over 40 hours without electricity now. Jun 12 15:51:07 ouch Jun 12 15:51:09 that sucks Jun 12 15:52:25 I'll try to confirm with Manisha who promised me a detailed app note on why we can't do dynamic pinmuxing, which I still think we can figure out the safe way to do it... and that app note would sure help. Jun 12 15:52:45 btw, did you see the issue on the DVS I2C connection to PMIC? Jun 12 15:53:39 I wonder if that is why BBAI rev A1a tends to run a bit warmer than other AM57x/DRA7 boards. Very odd it wasn't caught. Jun 12 15:54:33 no, what did you do? Jun 12 15:55:03 oh LOL Jun 12 15:55:07 hahahaha Jun 12 15:55:20 oooof Jun 12 15:55:45 how DID that not get caught.. shouldn't the kernel be screaming? Jun 12 15:58:55 that reminds me of some old prototype board I worked on where half a dozen people had checked the schematic (myself included) and noone caught that the RAS and CAS lines to SDRAM were swapped Jun 12 16:06:34 jkridner[m]: well, easy patch right, just remove R146 and R149 and cross-connect them with patch wires ;) Jun 12 16:50:20 jkridner: zmatt: got me hands on a discounted bB-blue and 4.3" touchscreen-cape :D Jun 12 16:50:31 you mentioned that yes Jun 12 16:50:32 more phatz! :D Jun 12 16:50:49 ah you saw .. I know you were headed AFK Jun 12 16:51:22 it'll be next on my list after I set up the ubiquitous pi :/ Jun 12 16:51:31 I'm looking forward to the screen :D Jun 12 18:58:22 I've decided an alternative to this systemd thing I've been trying is to make the root fs ro. I can do that trivially, it seems, by just adding "ro" in fstab, but I'm thinking there's a lot of stuff that breaks. Jun 12 18:58:47 uh, to accomplish what exactly? Jun 12 18:58:59 I've been searching for how to make a ro root fs, and while I've found things for Ubuntu and such, they seem to all be for non-systemd. Jun 12 18:59:17 how is this related to trying to prevent shutdown? Jun 12 18:59:33 I want to minimize the chance of eMMC corruption for unexpected power failures. Jun 12 18:59:55 how is that related to trying to prevent shutdown? Jun 12 19:00:40 oh I see, you were trying to quickly shut down on power loss but had troube figuring out how to abort it if power comes back before shutdown completes? Jun 12 19:00:52 The whole power thing is to get an external power module to hold power for a short time to allow it to shut down cleanly. The prevention bit was an attempt to allow that external module to tell the system it isn't actually goig to shut down, but that angle isn't going to work. Jun 12 19:01:00 Yes. Jun 12 19:02:03 honestly I'm not sure I'd try to cleanly shut down on power loss. all you should need is getting any pending eMMC writes to finish and preferably tell eMMC to prepare for power loss Jun 12 19:02:18 depending a bit on what type of corruption you're trying to prevent Jun 12 19:02:35 but with ext4, that should suffice to prevent true filesystem corruption Jun 12 19:03:00 and of course just minimize unnecessary writes (which you'll need to do if you're considering going readonly anyway) Jun 12 19:03:30 like, there's no reason for an idle system to be writing to eMMC Jun 12 19:04:25 I would think preventing fs corruption would suffice. Does init have a SIGPWR hook I could use to sync before the electrons are actually gone? Jun 12 19:04:59 what do you mean? Jun 12 19:05:36 You mentioned getting pending writes & prep eMMC before power loss. I'm guess how that might be done. (grin) Jun 12 19:08:13 if you have notification you're going to lose power, you could suspend eMMC writes using fsfreeze, and assuming it also syncs (I assume it does) you can then probably use a low level mmc call to tell it to prepare for poweroff Jun 12 19:08:35 and then just await the power loss, or if notified that power has returned you can undo these steps and the system continues running Jun 12 19:08:42 Roit toe. I'll look into how to assemble all that. Thanks! Jun 12 19:09:24 freezing the filesystem by itself would probably already help a lot Jun 12 19:11:03 also, consider tweaking sysctl values to keep linux from buffering writes too much, so that there isn't too much to sync to disk. these are the values we currently use, but you can tune them for your situation of course: https://pastebin.com/raw/deRHGZ2T Jun 12 19:12:18 Thanks! I hadn't even thought of that. Jun 12 19:12:57 and if you can afford to sacrifice 50% eMMC capacity you can consider reconfiguring eMMC to SLC mode (i.e. 1 bit per cell instead of 2 bits per cell) with reliable writes enabled. we do that in the hope of minimizing the risk of eMMC corruption and maximizing its lifetime, and so far it seems to work reasonably well Jun 12 19:13:21 (as a bonus, SLC mode seems to dramatically increase write performance) Jun 12 19:15:22 Ohh. I read about that but hadn't stumbled on if the Black supported it. I will consider it for sure. Jun 12 19:16:17 Ragnorok: I patched a custom command into mmc-utils that performs the necessary steps after doing sanity checks: https://github.com/dutchanddutch/mmc-utils/commit/d550d3e2edaa4518af99ffdc101a32e93c5d37a5 Jun 12 19:16:30 since the default commands were kinda awkward and error-prone Jun 12 19:16:49 (and "error-prone" is not what you want when dealing with One Time Programmable configuration) Jun 12 19:17:35 I'm thinking if I go this route I'll have to craft a bootable system b/c the exising flasher does 4GB? Jun 12 19:17:51 you're using a stock IoT image? Jun 12 19:17:52 oof Jun 12 19:17:57 Currently. Jun 12 19:18:39 It was simpler back then than trying to assemble it. Now that I know more I can probably do it from scratch. Jun 12 19:18:51 start with a console image, install what you want Jun 12 19:19:10 also remove rsyslog (dunno if it's installed by default on the console image, it definitely is on iot) Jun 12 19:19:50 logging to eMMC is an easily avoidable source of unnecessary eMMC writes Jun 12 19:20:07 I think that was done; I was building the main system while another guy did the Linux and hardware setup bits. I saw "IoT" and thought "console" for some reason. Jun 12 19:20:33 ok well the console image doesn't need 4GB, or even 1GB Jun 12 19:20:54 our production beaglebones have a pretty minimalistic system Jun 12 19:21:26 Since it uses journald I took out syslog some time ago. The eMMC is currently 39% full but this is my dev unit. I'd have to flash a different firmware to see how big it really is. Jun 12 19:22:23 But my question about size was related to fact all the flashers I have were done from a 4GB eMMC, so I'm thinking they won't write to a 2GB eMMC? Jun 12 19:23:51 I haven't assembled a system from scratch yet. I've always just built a flasher from the eMMC at hand. (shrug) Jun 12 19:24:12 I have however read a lot about how to assemble one from scratch and it doesn't look horrible. Jun 12 19:27:34 oh I haven't assembled one fully from scratch either Jun 12 19:27:45 I just create a master image from a model system Jun 12 19:28:10 But that model system was assembled from scratch? Jun 12 19:29:16 once upon a time it started with a debian console image from rcn, though since then I've been through everything more than once and stripped it of anything unnecessary Jun 12 19:29:28 (and it's now debian buster) Jun 12 19:29:39 and a custom kernel and custom u-boot Jun 12 19:29:42 custom dt Jun 12 19:30:54 Right. I don't have anything like that to work from. No biggie. I'll sort it all out. As always, thanks for all your help! Jun 12 19:33:40 to illustrate, this is what's running on the system if I exclude our custom services: https://pastebin.com/raw/PkC25BfU Jun 12 19:34:30 not sure why that takes 309 MB on eMMC (again excluding custom stuff) but it's not really worth the effort of minimizing it further Jun 12 19:35:07 brb Jun 12 19:38:15 I've a lot more than that, but at this juncture I don't have the time to pare it back. There it is. I don't call the shots, I just figure out how to make them happen. Jun 12 19:58:16 sure, but it sounds like you've been having fs corruption issues, so that might motivate taking another look at minimizing the system, both to minimize eMMC activity and since using less space may be important if you're considering SLC mode (which you probably should, since MLC is known to be relatively sensitive to corruption resulting from power loss) Jun 12 19:59:18 the big problem with MLC being that power loss while writing one sector can cause corruption to a seemingly unrelated sector, which is not something journal filesystems can cope with Jun 12 19:59:19 I haven't had them yet. I'm attempting to avoid having them in an environment where we don't have clear control over the power. (grin) Jun 12 20:00:19 I'll add minimizing the system to the list of stuff we discuss Monday. Jun 12 20:00:44 we originally considered using a li-ion battery to give us time to prepare for power loss, but in the end it was just too inconvenient (also because adding a li-ion complicated shipping), and so far we seem to be doing okay without (knock on wood) Jun 12 20:01:39 though if you can have advance notice of power loss, taking advantage of that is obviously a good idea Jun 12 20:01:49 Yeah. Our original solution was a battery but it was tied to the b'bone's charger. I redesigned our power ... oop. Work. Jun 12 20:03:19 yeah our plan back then was also to use the bbb's li-ion header, which also meant that we patched a bunch of beaglebones to unify the 3.3v supplies (to avoid the 3.3v regulator bug when powering the bbb via the battery header) Jun 12 20:03:42 (when powering off while a battery is present, rather) Jun 12 20:04:08 I resigned our power to address all the issues, but it was decided not to implement that, so now we're in this other boat. It's not ideal but here we are. Jun 12 20:06:02 so wait do you now have a battery on the bbb's header or not? Jun 12 20:06:29 Not any longer. Jun 12 20:07:11 We can put a battery on it but it causes other problems b/c of the power rail thing, where on 3v3 doesn't go down. Jun 12 20:07:30 yeah that Jun 12 20:08:09 but you still have advance notice of poweroff? you're keeping the board powered via external means? Jun 12 20:08:55 Currently yes. I think this fsfreeze thing is the ticket I've not be able to find. Jun 12 20:10:02 If I can do that but still have USB up that would be ideal. I'm looking for the low-level mmc command you mentioned. Jun 12 20:10:36 I mean, it obviously won't affect usb directly Jun 12 20:11:43 so, the mmc-utils I linked to is a util for various low-level mmc commands... I don't know if the one you seek if among it, probably not, but you could just add it Jun 12 20:12:15 Missed the link to. I'll scroll back. I have no reason to suspect it will affect USB either. Jun 12 20:12:57 Ah. That was part of the SLC thing. Jun 12 20:13:50 Wasn't on my system. Is now. I'll have a peek. Jun 12 20:15:07 yeah I added a single command that performs the OTP configuration of the eMMC to both convert the entire "user area" to SLC mode and enables reliable writes Jun 12 20:16:23 honestly fsfreeze is probably the more important part Jun 12 20:18:46 Serious! The mmc bit is just insurance in my mind, but if it's easy... Jun 12 20:20:47 you set POWER_OFF_NOTIFICATION (byte 34 of extcsd) to POWER_OFF_SHORT (0x02) Jun 12 20:23:00 the main caveat is that if another command is sent to eMMC after that, the byte will return to POWERED_ON Jun 12 20:23:31 Hopefully fsfreeze will prevent that. Jun 12 20:23:35 hopefully Jun 12 20:23:46 but I'd check that (e.g. using dynamic debug) rather than assuming Jun 12 20:23:53 Roit. Jun 12 20:23:54 I also hope fsfreeze won't block the low-level mmc commands Jun 12 20:24:02 (nods) Jun 12 20:24:07 it shouldn't, it's not a filesystem operation, but still Jun 12 20:25:24 When I try to read extcsd it says operation not permitted. Jun 12 20:25:55 I'll keep digging. This is just one utility. Jun 12 20:27:11 sudo ./mmc extcsd read /dev/mmcblk1 Jun 12 20:27:12 should work Jun 12 20:27:48 Ah. Tried the part. Jun 12 20:30:10 lol Jun 12 20:46:01 god I hate the tps65217 Jun 12 20:53:40 Whelp, all done here. Have a great weekend. Jun 12 20:56:55 you too Jun 13 02:47:45 can anyone recommend a big touchscreen cape that does not eat up too many pins Jun 13 02:47:49 I have given up on this one **** ENDING LOGGING AT Sat Jun 13 02:59:57 2020