**** BEGIN LOGGING AT Thu Mar 21 02:59:57 2019 Mar 21 03:01:27 I'm not sure at which temperature one should get concerned when measured on the outside of the package, but the max junction temperature is 90͏°C Mar 21 03:02:06 well if what i'm doing doesn't heat it up > 45 then it is unlikely anything i do would Mar 21 03:02:06 there's probably some appnote to estimate junction temp vs external temp Mar 21 03:04:58 well compiling probably doesn't exercise the Neon unit or GPU Mar 21 03:17:23 Hi everyone. Could someone please help me Mar 21 03:19:00 I need help enabling UART on my beaglebone because i need to transmit data Mar 21 03:20:02 what have you tried that doesn't work tjane ? Mar 21 04:41:05 @zmatt: Thanks for your suggestions Mar 21 09:54:21 Hmm, can I reflash a BeagleBone Blue from its own command line? (SD button has been torn off) Mar 21 09:55:35 Tried to run /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh directly from the old image, but it reverses source and destination (understandable). If I chroot to a mounted image, it cannt "reliably determine source and destination Mar 21 09:59:42 Knaldgas: you can just "simulate" the button by a resistor Mar 21 10:00:09 i don't have the schematic ready (and no time to search, sorry), but I've done that in the past. Mar 21 10:05:50 LetoThe2nd, sorry I should have been more specific - The button *and* the underlying pads have been torn off; no copper to get to Mar 21 10:13:36 Knaldgas: the S2 button is not of any importance for reflashing Mar 21 10:13:45 if you boot from a flasher card, it will reflash eMMC Mar 21 10:14:03 (you can turn a normal bootable SD card into a flasher card by uncommenting one line in /boot/uEnv.txt on the sd card) Mar 21 10:16:51 LetoThe2nd: on most beaglebones you can easily simulate the SD button by connecting a resistor (1K-10K) between P8.43 and ground, but the blue doesn't have the usual expansion headers, and sysboot 2 is not accessible on any external pin Mar 21 10:17:42 but it doesn't matter anyway, S2 button isn't needed Mar 21 10:18:44 zmatt: P8.43, thats it. as i said i remember doing that, just forget the pin :) Mar 21 10:19:21 zmatt: and, exception: if you happen to have a very old BBB, it will not boot the sd unless forced to. early u-boots preferred the emmc :) Mar 21 10:19:34 thats why i needed the resistor hack back then. Mar 21 10:20:17 in that case just wipe the bootloader from eMMC (assuming you still have access to the system, which Knaldgas does) Mar 21 10:21:14 zmatt: yes, yet another option Mar 21 12:28:46 m Mar 21 13:26:25 @zmatt: Still facing the same problem. I changed am335x-bonegreen.dts file this time and coverted it to dtb. At the end, added a line in /boot/uEnv.txt as dtb=am335x-bonegreen.dtb Mar 21 13:27:14 shreeya: generally speaking you should not override the dtb like that. use an overlay instead Mar 21 13:28:00 normally u-boot composes the actual DT that's passed to the kernel from multiple files (a base dtb, which is not am335x-bonegreen.dtb btw, plus several overlays depending on settings in /boot/uEnv.txt) Mar 21 13:28:35 But isn't it preferred to use device tree bindings for mentioning the details of the device attached? Mar 21 13:28:50 in principle overriding the main dtb should still work though (and render most settings in /boot/uEnv.txt non-functional) Mar 21 13:30:05 Is there a possibility that it is not working because maybe I have made any wrong changes in the file which are causing run time errors? Mar 21 13:30:30 if it doesn't boot then either you used the wrong version of the dts (be sure to use the correct branch for the kernel series you're using) or you just made a mistake in your changes Mar 21 13:30:42 of course that's possible Mar 21 13:31:29 I just changed the built-in dtb files to dts files and then made some changes Mar 21 13:31:36 note that customizing the main dtb will make it difficult to switch between kernel versions, since you'd need to recompile the dtb each time. that's another reason to use an overlay instead Mar 21 13:31:47 wait what do you mean? Mar 21 13:32:06 which source tree are you using for the dts files? Mar 21 13:32:20 There are dtb files present in /boot/dtbs/ Mar 21 13:32:36 you're not decompiling the dtbs and then modifying them are you? Mar 21 13:32:36 I saw am335x-bonegreen.dtb file there Mar 21 13:33:02 decompiling dtbs is purely for debugging, and recompiling those generally will not result in a functional dtb Mar 21 13:33:14 Ohh Mar 21 13:33:16 they're also very unreadable compared to the original sources Mar 21 13:33:25 I didn't know this :( Mar 21 13:33:43 What is the best way to do this correctly? Mar 21 13:33:46 if you really want/need to modify the base dts, use the dtb-rebuilder repository Mar 21 13:33:53 however like I said, in general you want to use an overlay instead Mar 21 13:34:17 Yes, I will try to use overlay this time Mar 21 13:34:22 what kind of changes are you making anyway? is there a reason to not simply use config-pin? Mar 21 13:36:30 I have adt7516 device attached to my BBG. I want to make it talk using SPI interface ( I did it successfully using I2C interface with DT bindings) Mar 21 13:39:05 So under the spi1 node of am335x-bonegreen.dts file I added... Mar 21 13:39:05 adt7516@0 { Mar 21 13:39:05 compatible = "adi, adt7526"; Mar 21 13:39:05 reg = <0x0>; Mar 21 13:39:05 } ; Mar 21 13:39:44 I don't really know about config-pin Mar 21 13:39:50 you probably mean "adi,adt7526" (without the space) Mar 21 13:40:02 Yes Mar 21 13:40:28 Also adt7516* Mar 21 13:46:32 my "spi0.dtsi" example in https://github.com/mvduin/overlay-utils may be useful as template Mar 21 13:46:44 you can build the corresponding dtbo with "make spi0.dtbo" Mar 21 13:47:00 in your case, make a copy of it and change the compatible-string to whatever you need Mar 21 13:47:19 oh wait, spi1 node, not spi0 ? Mar 21 13:48:15 There was no spi0 Mar 21 13:48:22 So I had to go with spi1 Mar 21 13:48:25 what Mar 21 13:48:32 what kernel version are you using? Mar 21 13:48:49 4.9 which came with the image Mar 21 13:49:35 4.9 has an &spi0 node Mar 21 13:49:43 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am33xx.dtsi#L729 Mar 21 13:50:05 oh maybe you're talking about the alias Mar 21 13:50:40 anyway, if you mean to use spi0, my spi0.dtsi example should hopefully work for you Mar 21 13:50:49 Okay great Mar 21 13:50:57 I will try that soon Mar 21 13:53:41 7:19 PM  https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am33xx.dtsi#L729 Mar 21 13:53:59 This wasn't there in am335x-bonegreen Mar 21 13:54:02 oh yeah I linked 4.14... it's there in 4.9 too Mar 21 13:54:12 am33xx.dtsi is #included in am335x-bonegreen.dts Mar 21 13:54:14 It was spi1 and spi2 Mar 21 13:54:37 Ohh so I had to change am33xx.dtsi? Mar 21 13:54:41 no Mar 21 13:55:39 I mean you couldn't tell what source code declarations were coming from since you looked at a decompiled binary Mar 21 13:55:51 there are no spi nodes in am335x-bonegreen at all: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bonegreen.dts Mar 21 13:56:12 btw, kernel 4.9 is getting pretty old, so you might want to start with flashing the latest image Mar 21 13:56:23 4.14 has been the default for quite a while now Mar 21 13:57:23 I didn't actually needed it since I wanted to work with adt7316 driver which is quite old driver and is compatible with most of the versions Mar 21 13:57:42 But yeah I should switch to 4.14 Mar 21 13:58:17 it's not even specifically about the kernel version (I'm just using that as indicator for the age of the image you're using), it's also the rest of the image including the bootloader Mar 21 13:59:04 7:25 PM  there are no spi nodes in am335x-bonegreen at all: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bonegreen.dts Mar 21 13:59:13 I don't really understand this Mar 21 13:59:24 When I look at the source code Mar 21 13:59:36 you didn't look at the source code, this is the source code Mar 21 13:59:44 you looked at a decompiled binary Mar 21 14:00:00 But then what was that which I had decompiled? Mar 21 14:00:13 see those #include directives on lines 10-11 ? that means the contents of those files is included into this one Mar 21 14:00:23 It wasn't this which you pointed oit Mar 21 14:00:26 Out* Mar 21 14:01:00 am33xx.dtsi contains basic definitions for the SoC, am335x-bone-common.dtsi adds declarations on top of that that are common to all beaglebone variants, and finally the dts adds some board-specific declarations Mar 21 14:01:35 Ohh so when we decompile the dtb file it gives the source code of all the included files also? Mar 21 14:02:05 it attempts to produce source code (sort of) that represents the binary compiled tree Mar 21 14:02:26 it is not actually usable source code, just the best dtc can do Mar 21 14:02:38 a lot of information is lost when compiling that cannot be recovered when decompiling Mar 21 14:02:39 Okay Mar 21 14:03:21 Surprisingly this worked for i2c interface Mar 21 14:03:59 recompiling the decompiled dtb can work, but it's extremely fragile Mar 21 14:04:19 Hmmm yeah Mar 21 14:04:20 basically, if it works, it works by accident Mar 21 14:04:57 Yeah true... i2c interface didn't work everytime Mar 21 14:06:04 Anyway, thanks for your help. Will get back to you after I try dt overlays Mar 21 16:33:11 hello, for those w experience with SSD drives. If you overprovision a brand new drive before you partition it, will the available space be adjusted accordingly? Can you overprovision after you have formatted the drive? I'm using a Samsung SSD 850 EVO. Mar 21 16:37:20 if trim is enabled then overprovisioning is probably unnecessary, you'd get the same benefit by simply leaving some free disk space Mar 21 16:39:13 hm, apparently it is a rather old ssd though? Mar 21 16:40:49 first generation of v-nand, so for old not bad. ;) Mar 21 16:42:03 i've had it about 3 years. I had other brand new 860 EVOs. How do you enable trim? Mar 21 16:42:50 https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems Mar 21 16:45:31 hmm, apparently discard is not recommended with the 850 EVO Mar 21 16:46:12 my 850 failed on Tuesday. I'm trying to figure out what happened to it. I still can read it and SMART says it is fine. I'm accessing it through a cheap USB enclosure and getting errors, but I don't know if it is due to the enclosure or the device. Mar 21 16:47:17 I'll be back later today. I need to vaccinate my cats this afternoon. thanks for the link. Mar 21 16:47:40 should have a 5 year warrente: https://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850evo/ Mar 21 16:47:46 it has the ATA_HORKAGE_NO_NCQ_TRIM flag, which means that it doesn't support queued TRIM. my guess would be that this adversely affects trim performance, hence someone recommended not using the discard-flag (but just manually fstrim every now and then) Mar 21 16:48:35 I like the name of those flags... ATA_HORKAGE_* Mar 21 16:48:54 mounting with discard is overkill ... better to run fstrim periodically, say, weekly Mar 21 16:49:17 * vagrantc should read before replying Mar 21 16:50:43 well in theory using discard would always be better, but that assumes a well-behaved ssd controller Mar 21 17:06:43 so zmatt you seem to know a lot about usb .. Mar 21 17:07:03 the data signalling part of usb stays between 0 and 3v3 yes? Mar 21 17:07:14 i realize the vusb is 5v Mar 21 17:12:52 correct (it's called "vbus" btw) Mar 21 17:14:49 (low/full-speed communication is roughly 0-3.3V, high-speed communication is 0 - 0.4V) Mar 21 17:19:03 and the data lines remain at 0V until both sides are ready (host drives vbus to indicate it is ready to communicate with a device, the device pulls up D- (low-speed) or D+ (full/high-speed) when vbus is present and the device is ready to communicate) Mar 21 17:26:17 thanks for the confirmation Mar 21 20:27:39 rcn-ee: still stuck on u-boot. can you look at what I might have screwed up? Mar 21 20:28:08 the CONFIG_DM_MMC warning is the most confusing to me. Mar 21 20:31:13 I'm looking for recommendations for USB enclosures for M.2 SSD drives. Two out of three I got don't support SMART. Mar 21 21:16:43 2/cu Mar 21 21:39:54 rcn-ee: I've made changes to your u-boot for the file name update and I'm seeing a minor regression related to reserved-memory. Can you look at my last diff? Mar 22 02:25:31 hi Mar 22 02:25:41 i need some help **** ENDING LOGGING AT Fri Mar 22 02:59:57 2019