**** BEGIN LOGGING AT Tue Aug 13 02:59:56 2019 Aug 13 10:24:40 Hello there! Can anyone help me figuring out why my pocket beagles are randomly restarting without any visible error? The problem exists if i power the pb through the micro USB or the Header with a stable 5V power supply. Aug 13 11:51:53 you probably want to attach a serial debug cable so you can capture the log(s) when it actually drops out .. its not unusually warm is it? do you have any peripherals attached? Aug 13 12:16:20 JMTRG: first question would be whether it's a reboot or a reset... the difference should be easy enough to tell from logs (e.g. check whether the rootfs was clean or not, e.g. using something like journalctl -t systemd-fsck -b ) Aug 13 12:19:54 if it was a reboot then I'd expect the cause of it to be logged as well (although to see it you obviously need either persistent journal or a syslog daemon that writes more oldschool logfiles... the latter is installed by default on standard beaglebone debian images) Aug 13 12:23:26 I have created my own OS with buildroot. And everything is working as expected except the reboots/resets. Aug 13 12:24:17 In this example i have left it pinging a remote address with a usb wifi dongle. And then it stopped pinging and just reset... Aug 13 12:24:24 64 bytes from 213.13.146.142: seq=19246 ttl=246 time=11.774 ms Aug 13 12:24:25 9251 ttl=246 time=10.903 ms Aug 13 12:26:59 64 bytes from 213.13.146.142: seq=19253 ttl=246 time=10.694 ms Aug 13 12:27:00 ev 2.1 Aug 13 12:27:29 In that example it was pinging a remote address and then restarted. Aug 13 12:27:53 I have a usb wifi connected and nothing else. Aug 13 12:28:31 Im using a buildroot image that i have developed. Aug 13 12:33:19 pasting the output from ping is just spam since it provides absolutely no useful information :P also saying you're using buildroot once suffices, no need to repeat yourself Aug 13 12:35:29 Sorry. I lost the connection and did not know if the message was sent. Aug 13 12:36:40 ok. anyway, like I said, go check logs for useful info (at the minimum whether it was a reboot or a reset)... since you're using buildoroot you may need to figure out where you can find relevant log info, but hopefully it's somewhere :P if it's a crash/reset or relevant logging is only done to the serial console, then go capture log output from the serial console Aug 13 12:36:51 like veremitz said Aug 13 12:37:05 what kernel version are you using? Aug 13 12:37:36 4.14.71-ti-r80 Aug 13 12:37:54 I cant seem to find any useful log. Aug 13 12:38:17 are you using systemd? Aug 13 12:38:34 No. Aug 13 12:39:17 sysvinit i think... Aug 13 12:39:40 okay, so no journal. well then I guess the relevant info might be logged somewhere by a syslog daemon, if you have one running? if not, then my guess would be that logging is only to serial console... or maybe nowhere, in which case you're fucked, but that seems unlikely Aug 13 12:41:18 Another user complains of the same here: https://groups.google.com/forum/#!msg/beagleboard/8Y5COfcW-Ok/HOgIO2-lBwAJ Aug 13 12:42:25 It seems that also might be related to VIN and/or VBUS Aug 13 12:43:46 Anyway i have tested with a usb supply and a 5v supply. They both work on my Bone Black and i have never seen them rebooting. Aug 13 12:45:19 hmm, I wonder if the pmic is spuriously switching from power input Aug 13 12:45:55 If thats the case do i need to supply with both USB and External? Aug 13 12:46:32 if it's the case then it's easy to work around in software, but I'd also wonder why this is happening on the pocketbeagle... I'd need to check the schematic Aug 13 12:46:57 lemme first look up a command to force the pmic to use only one of the two inputs, so it can't switch Aug 13 12:47:17 @zmatt, i know that i am fucked, and specially when i already have 200 pb on some clients and they have started complaining :] Aug 13 12:47:45 Any help would be very appreciated! Aug 13 12:48:58 I will always use the 5v power supply. So i can force PMIC to use only the external power supply? Aug 13 12:49:57 I just said I was looking up a command to do exactly that Aug 13 12:50:06 since yes, you can Aug 13 12:51:28 Ok. Thanks! Aug 13 13:03:56 i2cset -f -y 0 0x24 0x01 $(( $(i2cget -f -y 0 0x24 0x01) & ~0x10 )) Aug 13 13:05:56 Done! Aug 13 13:07:26 What does that command do? Besides setting a value to a i2c device? Sorry for my questions but my knowledge regarding the pocketbeagle is very limited... Aug 13 13:11:19 disables the usb power input of the pmic Aug 13 13:12:13 Ok, and if solves the problem should i do it everytime i powerup the board? Aug 13 13:14:27 yes Aug 13 13:16:08 you can also omit the i2cget and just i2cset that register to the desired value, which would be 0x2f probably (since the default is 0x3f and bit 4 controls whether usb power input is enabled) Aug 13 13:16:58 actually, hold on, how exactly do you have a wifi chipset connected? Aug 13 13:17:23 since the pocketbeagle doesn't have a proper usb host port Aug 13 13:19:41 I have connected it with a FE1.1S usb hub on USB1 Aug 13 13:21:12 And it is working, right now i have connect a wifi dongle, a usb printer and a usb barcode reader... Aug 13 13:23:49 I will read the TPS65217C datasheet to learn more regarding the PMIC. Aug 13 13:23:51 with P1.1 going to both P1.5 and the VBUS of the hub? Aug 13 13:24:54 Let me check... Aug 13 13:24:59 (technically there should be a power switch in between, controlled by the drvvbus signal on P1.3, but iirc the linux driver is nowadays more tolerant of vbus being continuously present... I'm pretty sure that used to result in loud complaints and a non-working usb port) Aug 13 13:27:49 Yes. I have P1.1 and P1.5 connected. Even if i connect both power supplies i get the micro usb with serial gadget working. Aug 13 13:27:59 And no problems on the USB as well Aug 13 13:31:20 actually no, sys_5v (P2.13) ought to be used as vbus source (i.e. connected to P1.5 and vbus of the hub) Aug 13 13:31:39 P1.1 is just an input to the beaglebone (more specifically, the pmic) Aug 13 13:33:14 this ensures that the hub is only powered on when the pocketbeagle is powered on Aug 13 13:34:24 with "vbus of the hub" I mean the "VBUSM" signal Aug 13 13:34:47 I misspoke, it's fine if the usb hub is *powered* independently, but its vbus detection should be sys_5v Aug 13 13:36:35 if that's not the case (you mentioned the products are already out there), I'd recommend avoiding the state in which they're powered but shut down (e.g. by software request) Aug 13 13:39:32 since the vbusm input of the hub devices whether or not it will pull up D+ to 3.3V (via 1.5Kohm) to signal its presence... doing so while the am335x is powered down could probably damage the i/o cell (at least in the long run) Aug 13 13:39:43 *decides, not devices :P Aug 13 13:46:34 ugh the tps65217 is such an awful pmic Aug 13 14:01:33 explicitly disabling the charger is probably also a good idea: Aug 13 14:01:35 i2cset -f -y 0 0x24 0x04 $(( $(i2cget -f -y 0 0x24 0x04) & ~0x01 )) Aug 13 14:06:31 an alternative to disabling one of the two power inputs might be to enable input discharging... that might prevent false detection (assuming that's what is causing the resets) while still being able to use both power input options... that would be: Aug 13 14:06:35 i2cset -f -y 0 0x24 0x01 $(( $(i2cget -f -y 0 0x24 0x01) | 0xc0 )) Aug 13 14:08:28 Ok, so regarding the USB i have P1.1 connected to P1.5 SYS_VIN - VBUS and also P1.13 connected to P1.15 USB1_ID and GND. What do you propose to do? Aug 13 14:08:39 wait what Aug 13 14:08:45 oh Aug 13 14:09:25 I've never heard of"SYS_VIN", but the pocketbeagle seems to be a bit messy with its terminology Aug 13 14:10:56 On the pocketbeagle is P1.1 SYS_VIN. Am i wrong? Aug 13 14:11:45 https://i.pinimg.com/originals/7b/e6/4b/7be64bff40672b00228caeac0c238472.png Aug 13 14:15:01 Do you think that the way i have connected the USB might damage the PB? It seems to be working at least for 5 months? That was the only way i have found to get the USB working... Aug 13 14:27:49 JMTRG: https://pastebin.com/BxqmF6Zv if I'm reading the schematic right, this is what the various power and vbus pins are, along with how vbus is *supposed* to be implemented (although like I said, people seem to be getting away with no switching the vbus power. I'm not a fan of doing so, but *shrug*) Aug 13 14:34:13 Ok. Thanks! I will have a look at it. In the mean time i will try to check if the reboots still happen. Aug 13 14:34:43 @zmatt Thank you very much for your help! Aug 13 14:37:09 JMTRG: if not using a power switch, it's probably a good idea to use drvvbus as reset signal for the hub Aug 13 14:37:33 (assuming it will disconnect its D+ pullup when in reset) Aug 13 14:45:05 Ok! Aug 13 15:02:59 m Aug 13 15:10:59 <_hays> Does anyone know the details of how the boot process works when one writes x-loader and u-boot into NAND memory? Aug 13 15:11:42 <_hays> The TI chip seems to check (1) SPI (2) emmc (3) sdcard --- I am curious if NAND is in there somewhere implicitly? Aug 13 15:12:36 <_hays> So if I write the x-loader into NAND for example, how does the chip know to look there? Aug 13 15:12:36 where'd you get that from? you seem to be talking about the original beagleboard (or the xM), which don't have eMMC afaik Aug 13 15:13:37 <_hays> most of my info comes from https://elinux.org/BeagleBoardNAND Aug 13 15:13:58 zmatt: Solved my SPI issue. I updated to the latest 4.19 kernel and it solved my issue Aug 13 15:14:30 _hays: ah yeah so you're talking about the old beagleboard (apparently the xM doesn't have a NAND boot option) Aug 13 15:15:01 <_hays> I'm trying to see if I could fit a little linux into NAND that was basically for remote recovery Aug 13 15:15:32 okay let's back up: which board are you using? Aug 13 15:16:11 <_hays> beaglebone black or variant possibly like the beaglecore or sancloud variant(s) Aug 13 15:16:25 the bbb has no NAND, it has eMMC Aug 13 15:16:35 that wiki page is talking about a totally different board Aug 13 15:16:42 namely the beagleboard, not the beaglebone Aug 13 15:16:42 <_hays> OK. Aug 13 15:17:06 <_hays> So my options are EMMC and SD CARD Aug 13 15:17:27 those are the most commonly used options Aug 13 15:17:53 <_hays> If I want to write a new x-loader remotely, can I do that from within the BBB environment while it is booted? Aug 13 15:18:10 "x-loader" is not a concept that exists on the bbb Aug 13 15:18:19 not applicable to the AM335x Aug 13 15:18:49 you might mean u-boot, in which case the answer is yes, although that is a bit risky Aug 13 15:18:49 <_hays> huh. I was reading about that from the beaglebone book Aug 13 15:19:11 then whatever book you're reading from is confused Aug 13 15:19:19 <_hays> is it possible the x-loader is in ROM? Aug 13 15:19:36 no Aug 13 15:20:03 <_hays> ok. I'll go re-read that part of the book. it seems to be one of two books on the subject Aug 13 15:20:10 x-loader is an omap3 concept, it's an intermediate loader between bootrom and u-boot. I don't really know much about it or why it was used since I don't have any omap3 device Aug 13 15:20:16 <_hays> exploring beaglebone Aug 13 15:21:03 <_hays> rewriting u-boot is risky because if it fails in some undetected way, a reboot will brick the device? Aug 13 15:21:03 i think x-loader was used before u-boot had SPL support Aug 13 15:21:16 but u-boot has had SPL support for quite some years Aug 13 15:21:16 yeah I see now Aug 13 15:21:32 x-loader indeed played the role that SPL now fulfills Aug 13 15:21:38 fair enough Aug 13 15:22:21 i think when i first started working with beagleboneblack late ~2013 it still had x-loader at least out of the box. Aug 13 15:22:34 all because u-boot can't manage to fit its fat ass into 127KB of internal SRAM Aug 13 15:22:57 interesting, so maybe the book is just really old Aug 13 15:23:03 i see we have a big fan :) Aug 13 15:23:40 <_hays> amazon has a 2nd ed Aug 13 15:23:52 <_hays> but I was using o'reilly. maybe it was 1st ed Aug 13 15:24:05 look at copyright date :P Aug 13 15:24:37 books about topics like these have a tedency to be outdated the moment they hit the shelves anyway Aug 13 15:24:43 yeah Aug 13 15:24:45 <_hays> yeah I know. I'm bringing it up right now. my oreilly login is weird because I have it through the acm Aug 13 15:25:00 oo, i have the same little package with the ACM Aug 13 15:25:02 good stuff Aug 13 15:25:26 <_hays> yeah books are nice though because they seem to be the only time anyone tries to explain things from a top-down approach. a good way to get started Aug 13 15:25:59 <_hays> kremlin yeah its an amazing deal Aug 13 15:28:02 <_hays> weird. the copyright date isn't shown in this online version--or can't find it. but I think its 1st ed. Aug 13 15:28:08 <_hays> so that was 2014 I think Aug 13 15:28:37 <_hays> yep, there it is 2014. Aug 13 15:29:25 oof Aug 13 15:29:41 back when dinosaurs roamed the land Aug 13 15:30:06 <_hays> lol Aug 13 15:41:36 <_hays> so what are the risks with writing u-boot from within the beaglebone? Aug 13 15:42:29 <_hays> like, if I know its a good image, and I verify it was written correctly, are the risks just associated with weird unknowns, or is there a chance that writing it will actually cause an issue Aug 13 15:43:23 <_hays> I'm guessing this would be infrequent, but just trying to game out what risks are if for some reason it was necessary to do this in the future Aug 13 15:44:17 the main risk is getting a power failure at the worst possible moment :P Aug 13 15:45:20 it's pretty rare for there to be any need to update the bootloader in the field though Aug 13 15:47:47 <_hays> ah ok so it its UPS-backed then risk is minimal Aug 13 15:48:10 certainly Aug 13 15:48:33 especially since overwriting the bootloader takes very little time Aug 13 15:53:43 <_hays> I'm having trouble finding the process for doing this without an SD CARD Aug 13 15:55:44 how you booted the system is irrelevant for the process of replacing the bootloader on eMMC Aug 13 16:03:26 https://pastebin.com/Yb3J7KMu this is the script I generally use for installing uboot (it expects "MLO" and "u-boot.img" files in the same directory as the script) Aug 13 16:10:38 <_hays> interesting, so you are using dd to write directly into certain offsets of the emms Aug 13 16:10:40 <_hays> emmc Aug 13 16:11:02 <_hays> as opposed to using /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh Aug 13 16:11:14 <_hays> which seems to be the supported? way to do it from the SDCARD Aug 13 16:12:37 that's something to reflash the whole eMMC from sd card, not just update the bootloader Aug 13 16:13:03 <_hays> yeah im trying to find the actual source of this file--maybe RobertCNelson? Aug 13 16:13:15 that's a script from rcn yes Aug 13 16:13:28 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh Aug 13 16:15:58 _hays: there are risks to updating, u-boot, hence why the updater script is under ./developers.. Aug 13 16:16:25 i usally ask lots of questions, before i tell a user to use it.. Aug 13 16:17:19 but side, note, if you flashed an image in the last 2 years to the eMMC, or boot directly off the microsd, it's 99% safe.. Aug 13 16:17:53 <_hays> does the init-emmc-flasher update u-boot? it doesn't look like it does Aug 13 16:18:04 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/developers/update_bootloader.sh Aug 13 16:18:05 in principle it is possible to atomically update u-boot, but that would require making SPL look for u-boot.img in two different locations, or just have the updated version use the alternate offset (and then you can go back to the original offset for the next update after that) Aug 13 16:18:41 the emmc flasher wipes eMMC, creates a filesystem, copies files, does more stuff, and yes it installs u-boot otherwise the beaglebone wouldn't be bootable Aug 13 16:19:07 <_hays> these are good scripts to read--I'll read them Aug 13 16:19:27 init-emmc-flasher uses the presence of /boot/uboot/MLO and /boot/uboot/u-boot.img and the dd details stored in soc.sh to write them to the eMMC.. Aug 13 16:20:12 if only the AM335x bootrom supported using the eMMC boot partition :/ Aug 13 16:20:17 if you look on your drive, there should be a file: /boot/SOC.sh if you cat that, you'll see all the magic numbers.. Aug 13 16:20:22 then atomic bootloader updates would be trivial Aug 13 16:22:10 _hays: for example: http://paste.debian.net/1095643/ Aug 13 16:25:04 <_hays> ok so I think that happens in _dd_bootloader() called by prepare_drive() Aug 13 16:25:56 oh, god, yeah, i'm not going to debug "functions.sh" i should have never accepted that rewrite.. it was nothing but pain to make it work on everything after the merge.. Aug 13 16:27:21 _heays: study this version: https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/bbb-eMMC-flasher-eewiki-12mb.sh it does the same thing, but not not has convoulted... Aug 13 16:27:22 yeah I don't understand why it's structured the way it's structured Aug 13 16:28:12 nor why it uses so many global variables -.- Aug 13 16:29:44 <_hays> cool. what is 12mb referring to? vs. another one called -ext4 Aug 13 16:30:14 yeah, use the ext4 one.. Aug 13 16:30:40 so originally, we had a small fat partition for u-boot's files.. (-12mb stood for the 12mb fat partition).. Aug 13 16:31:07 then we figured out how to use 'raw boot', hence the "1" ext4 partition.. (-ext4) file... Aug 13 16:31:40 rcn-ee[m]: message="-----------------------------" ; broadcast ... that looks really weird to me though, why use a global variable instead of just an argument, i.e. broadcast "-----------------------------" ? Aug 13 16:31:58 (then later we got btrfs working, the -ext4 could be modified to do that..) Aug 13 16:32:29 <_hays> nice. working btrfs Aug 13 16:32:44 <_hays> This is very helpful. Thank you zmatt and rcn-ee Aug 13 16:34:39 zmatt there's lot of things i'd like to change in them. but best to not touch. ;) Aug 13 16:34:41 or better yet, just use echo (and if sending a copy to /dev/tty0 is desired you could just wrap the whole thing in { .. } | tee /dev/tty0 Aug 13 16:34:49 ) Aug 13 16:34:51 fair Aug 13 16:35:24 <_hays> it is always interesting to see how different people scale out bash scripting Aug 13 16:35:53 yeah, message was sent to both serial and video.. then they wanted to be faster.. Aug 13 16:36:00 hehe Aug 13 16:41:03 and since you're using bash (and don't have to be compatible with every ancient or obscure sh-variant out there) I'd write [[ -n $var ]] or [[ $var != '' ]] instead of [ ! "x${var}" = "x" ] Aug 13 16:41:10 much easier on the eyes Aug 13 16:42:37 (yes, amazingly no quotes are needed around $var in [[ .. ]], even if $var is blank or contains spaces) Aug 13 16:43:45 ah yeah, "Word splitting and pathname expansion are not performed on the words between the [[ and ]]" Aug 13 16:46:02 (you can also do glob matching e.g. [[ $var == foo* ]] which is why it's a good thing that no pathname expansion happens) Aug 13 16:47:07 @zmatt the problem was not on the PMIC, after the changes we have made to the registers the PB still reboots. Aug 13 16:47:34 Do you have any other idea? Aug 13 16:47:34 JMTRG: you still haven't determined whether it's "reboot" or "reset" Aug 13 16:47:39 yes, examine logs Aug 13 16:48:51 serial console is probably your best bet, but if you're not sure how to obtain relevant log information in your buildroot system, maybe ask in #buildroot Aug 13 18:06:59 pi Aug 13 18:07:19 also known as tau/2 Aug 13 19:03:45 Hello all. I'm experiencing the 3v3B power rail bug when using a battery, which is well document on a Black RevC. I looked at the schematic for a Black Wireless and it looks like that may be resolved there b/c it gets 3v3B from its PMIC, not via an external regulator. Am I looking at that right? Aug 13 19:08:43 I doubt that's true, but I'll take a look Aug 13 19:08:50 Thanks! Aug 13 19:11:40 I looked at the one here: https://github.com/beagleboard/beaglebone-black-wireless Aug 13 19:14:26 it has the same issue Aug 13 19:14:57 Poo. I was hoping I didn't miss it. Oh well. Does the AI have it as well? I haven't found a lot of info on it yet. Aug 13 19:16:35 AI is a completely different design Aug 13 19:16:45 different SoC, different PMIC, no battery terminals afaik Aug 13 19:17:23 Oh. No battery terminals. That can't be good. For me that is. Aug 13 19:20:45 I guess that's one way to solve the issue though. (wink) Not the answers I hoped for, but answers none-the-less. Thanks again! Aug 13 19:21:59 so yeah it looks like they made exactly the same mistake on the wireless... all the on-board stuff is powered from 3V3B instead of 3V3A Aug 13 19:22:17 That does make sense, really. Aug 13 19:22:31 ? Aug 13 19:23:32 Using the same overall power design instead of redoing it, I mean. Makes sense to modify as little as necessary. Aug 13 19:24:09 I just wish I'd seen that. I mean it looked. (pout) Aug 13 19:24:23 also, it looks like there's a clamp circuit to ensure 1.8V doesn't drop too far below 3V3A and 3V3B (the abs max voltage between them is 2V), but in scenarios where the 3V3B regulator won't shut down, that means hilarity will ensue :P Aug 13 19:25:43 actually I don't really understand why they put that clamp circuit on 3V3B as well.. the problem is 3V3A may never exceed the 1.8V supply by more than 2V, no such constraint exists for 3V3B Aug 13 19:26:20 I mean yeah I understand not wanting to make changes, except they did make changes and moreover the previous design had known issues :P Aug 13 19:26:21 I confess I haven't dug around a lot in the schematic so far. I've largely been reading all the stuff about that particular battery issue. Aug 13 19:26:49 yeah I did a fair bit of investigating back then Aug 13 19:27:44 the unfortunate thing on the bbb-wireless is also that there's no way in hell you can fix it there with a patch, while on the bbb it was reasonably easy to patch (by removing the LDO and tying 3V3A and 3V3B together) Aug 13 19:28:25 I saw that but didn't know how much power I could pull off 3v3A. Aug 13 19:29:10 I haven't been able to find that data anywhere either, prolly b/c one would normally be using the LDO. Aug 13 19:29:23 yeah it depends a bit on what's consuming power on the board Aug 13 19:29:34 the LDO is rated for 400 mA Aug 13 19:29:43 LDO4 of the pmic I mean Aug 13 19:29:59 In your estimation how many mA could I pull off 3v3A? I *assume* the board itself is using some percentage of that 400mA. Aug 13 19:30:00 but ethernet and eMMC can consume a fair bit under worst-case circumstances Aug 13 19:30:44 and sd card, if you use one Aug 13 19:30:50 We do. Aug 13 19:31:56 16GB. Is there a way to measure what 3v3A is supplying? Be nice if the PMIC did that, but so far I haven't seen a lot in the datasheet regarding monitoring. Aug 13 19:32:01 well those three things + external hardware would be the main consumers, so you could look those up individually... for sd cards it will obviously also depend on the card used Aug 13 19:32:26 nah this pmic has negligible monitoring, I hate the tps65217 Aug 13 19:32:31 lol Aug 13 19:33:09 I was more than a little surprised how anemic it is in that regard. But there it is. Aug 13 19:34:55 yeah it's bad... it doesn't even have a register readout of whether battery is detected (VBAT > UVLO), even though it does have a comparator on that Aug 13 19:35:14 Yeah, and it's not exposed. lol Aug 13 19:35:27 To me that is. The end user type. Aug 13 19:37:40 The schematic clip of the power section of the AI looks like its PMIC doesn't even support a battery. Aug 13 19:37:48 I imagine it doesn't Aug 13 19:38:19 the tps65217 is fairly unusual in having an (pretty crappy) integrated charger Aug 13 19:38:58 Ragnorok: on the AI, use the "Power Cape"... Aug 13 19:39:38 I'll look that up. Thanks! Aug 13 19:40:01 https://github.com/beagleboard/capes/tree/master/beaglebone/Power Aug 13 19:40:23 Even easier. (wink) Aug 13 19:40:37 jason's been using one on his AI while testing it.. Aug 13 19:44:39 brb Aug 13 19:45:54 HUh. Acrobat doesn't like the PDF from power cape link. Aug 13 19:46:42 PEBKAC. Aug 13 19:48:45 I am trying to connect over SHH via Putty, and it won't accept *enter* for a password.. Any help? Aug 13 19:52:15 On a Black using the console connector it should "just work". Ours have had that disabled on networking for so long I can't remember if that ever did. Aug 13 19:53:41 I can acess 192.168.7.2 over chrome without a problem.But the moment I try over a putty it wont work Aug 13 19:53:48 rcn-ee[m] I'm missing the battery connection on that cape schematic. It looks like it's an external regulated supply. I was thinking if we needed battery we could plausibly do this with a boost converter. Aug 13 19:57:52 Sadly I'd have to look if SSH is even running by default. I don't recall. It should be documented somewhere, or you could use a serial cable and the console. That works for sure. Aug 13 20:32:28 "it won't accept *enter* for a password" ... well duh :P Aug 13 20:33:07 Oh... yeah good point zmatt Aug 13 20:33:07 I thought it did otb? (shrug) Aug 13 20:36:35 years ago it did. Aug 13 20:38:04 Ah. It's been years since I've seen an otb B'Bone. At least I haven't likely lost that part of my mind yet. Aug 13 20:38:20 Ragnorok: I wonder if for battery-powered am335x boards it wouldn't be better to use the tps65218d0 + external charger.. since the tps65218 is more efficient and it accepts input power as low as 2.7V which is convenient for powering using a single-cell battery (it has a buck-boost converter to generate 3.3V from it) Aug 13 20:39:01 Ragnorok: it's been years since root + empty password was a thing... now you just log in as "debian" / "temppwd" and use sudo in the rare case you need it Aug 13 20:39:06 zmatt: Plausibly, but the existing design uses the on-board PMIC/charger. Aug 13 20:39:52 sure I was just idly pondering better alternatives than the sucky tps65217 Aug 13 20:40:12 I'm wading through the BOM looking up datasheets to estimate board consumption. Then I'm going to simply strap one board and measure what our system draws. Should be decent enough guess. (shrug) Aug 13 20:40:49 If it's well under 400mA I'll count coup. Aug 13 20:41:08 Total ofc. (grin) Aug 13 20:41:37 with the tps65217 you also have the issue you can't really use much of the charge in the battery before the voltage has dropped too low to make the 3.3v supplies destabilize Aug 13 20:43:47 pizza! Aug 13 20:44:15 Oh man. I'm jealous. (grin) Yeah we only run it for a minute before we do something if still on battery. Aug 13 20:45:02 ah it's just to allow for time to cleanly shutdown? Aug 13 20:45:26 Pretty much. We wait a bit to see if it's a transient, then we roll over. Aug 13 20:57:53 Rev C schematic shows 3v3A drives U6, U3, Y4, bunch of SoC pins, and U7. U6 runs the HDMI Framer, U3 runs eMMC RSTn, Y4 is some HDMI clock, and U7 is a serial EEPROM. Today seems to be my day for missing things on schematics. Unless the "bunch of SoC pins" are used to drive SD & Ethernet? Aug 13 21:00:56 Ah. Now I have the SoC DS open I think that is the case. They're all VDDSHV* pins, which appear to power subsystems. Aug 13 21:02:29 the OSD335x series uses the TPS63217c right? well that makes things interesting. I wonder if that was specifically made for that SoC? Aug 13 21:12:36 Hello there! i would like to know if there is any information on the release of Beagleboard A.I Aug 13 21:13:37 Hurm. Rev schematic says e'net io is powered by 3v3B & rest is VDD_PHYA. But I don't find VDD_PHYA source anywhere. Aug 13 21:14:16 Specifically, when it will be available for purchases Aug 13 21:14:26 Ragnorok: doesn't the phy have an internal regulator to generate the core voltage? Aug 13 21:14:51 Ragnorok: i'm pretty sure you can just add the current consumption values together and account them all to 3.3v Aug 13 21:16:07 So just tack in the e'net chip and call that a wash, sounds like. On the SoC, the total of all the power domains could be as much as 350mA. That seems pretty hefty. Aug 13 21:18:10 that depends mostly on you though... if you're drawing current from a gpio, that current obviously comes from vdd_3v3a Aug 13 21:19:28 Yeah. This is getting messier all the time. lol Aug 13 21:19:41 TI isn't saying "take into account that these supplies can draw this much power", they're saying those supplies are not rated for more current than that, and you should not exceed that Aug 13 21:41:48 If I add up the three mentioned it's 258mA max, which is a pretty big chunk of the 400 available. But it's quittin' time now. I'll take this up again tomorrow. Thanks for everything! Aug 14 02:56:00 I see GHI and BeagleBoard.org put some brd files on the examples section on EAGLE's free version. Nice. Aug 14 02:58:03 BBBW! **** ENDING LOGGING AT Wed Aug 14 02:59:56 2019