**** BEGIN LOGGING AT Mon Jun 10 02:59:57 2019 Jun 10 05:31:49 (catching up on transcript from last several days) lmao at your response to the all-caps guy, zmatt Jun 10 05:41:27 but what if the poor bastard is in fact impoverished with a baudot teletype that he's managed to use as input to the IRC client he's got running on the BB he found on the ground like mana from heaven? Jun 10 05:50:54 inb4 the guy is on a remote island and doing IRC over shortwave radio with RTTY Jun 10 05:51:37 now I'm getting flashbacks to the /other special guy we had a while ago, although I think he was mostly on G+ Jun 10 05:57:24 indeed, that could've been the last bit of connectivity he had for the lunar cycle :D Jun 10 05:58:48 he will now surely die of boredom without that debian source code as reading material Jun 10 06:29:35 dabbler1: now the CD with his downloads won't make the mail-boat and the next one won't arrive for another 6 months Jun 10 07:42:23 @zmatt: so what ended up coming of the image-shrinking request? Jun 10 07:44:34 it seemed like you and RCN were discussing how to detect which filesystem to grow, but i didn't understand a lot of the particulars mentioned (e.g. initramfs?) Jun 10 12:52:45 We are using Beaglebone black in our project. We want to test all hardware modules as diagnostic test. We are using beagle-tester-bt-0.1.15-boneblack.img for testing purpose. Test set up was as mentioned in beagle-tester readme. Flashed the image on sd card and inserted sd card on beaglebone black. HDMI displays nothing. and on serial terminal logs shows buildroot login. Are we missing something? Jun 10 19:50:31 I'm now running a custom board which is for the most part a BBB but with a 3352. It has an additional USB hub, an RTC and an LTE modem on the same board (a cape grafted on the same PC, next to the BBB part). Ot Deb 8.11 / 4.4.68-ti-r110. Jun 10 19:51:58 I'm not having success at compiling a fresh image for it. I can't get the USB or modem to work. Jun 10 19:53:06 have you amended the device-tree for your new peripherals? Jun 10 19:53:17 did the old image use an overlay or a custom dts? Jun 10 19:54:03 the 'cape' does not appear to have it's own overlay Jun 10 19:54:13 On the precompiled image, that is. Jun 10 19:54:20 i.e. it's using a custom dts Jun 10 19:54:22 ? Jun 10 19:55:34 in that case you'd need to forward-port that to your new kernel Jun 10 19:55:56 has anyone you ever heard of a pocketbeagle being fried by simply plugging it into a macbook ? Jun 10 19:56:02 (seems that just happened here) Jun 10 19:56:20 ogra: that sounds very implausible Jun 10 19:56:39 I'm kind of 'green' when it comes to the dts / dto things, I have gone through a few dts's from what came with the precompiled image and compared them to the ones that come with the new image but have not managed to pinpoint the issues. Jun 10 19:56:51 i would think so too ... but it doesnt give any sign of life anymore and gets really hot Jun 10 19:57:27 ogra: are there any connections to the pocketbeagle other than the usb connection to the mac? Jun 10 19:57:36 that indeed doesn't sound good Jun 10 19:58:14 (it was running just fine on my ubuntu laptop ... i handed it to a firend, he plugged it into his macbook (running ubuntu as well), it booted, threw an oops shortly after and now there is no sign of life anymore Jun 10 19:58:26 i even wrote a new SD with the latest image Jun 10 19:58:35 ogra: that's really bizarre Jun 10 19:58:38 no other connections Jun 10 19:58:57 any chance something somehow got shorted? Jun 10 19:59:03 it has three pins soldered on for a UART connection Jun 10 19:59:21 was that connection also in use? Jun 10 19:59:26 nope, there is a tablecloth on the table and it was lying properly on the cloth Jun 10 19:59:30 not touching any metal Jun 10 19:59:46 and no, UART wasnt connected Jun 10 20:01:01 then I have no idea... it still seems extremely unlikely that plugging the board into the mac was the cause of its death, but I also have no idea what could have caused it to die like that Jun 10 20:01:19 yeah, very strange Jun 10 20:10:07 zmatt: With the limited information given, would you say it is most likely an dts / overlay issue? How would one go about forward-porting the old dtb's to my new kernel? decompile the dtb's tp dts, copy the dts files from /lib/firmware over before compiling the kernel? Jun 10 20:10:37 outrageous_: what? no Jun 10 20:11:48 you use the original dts file (presumably it's one file) for your custom board and compile that within either the kernel tree or (typically more convenient) within the appropriate branch of dtb-rebuilder Jun 10 20:11:57 this is assuming you indeed have a custom dt Jun 10 20:12:09 what does /boot/uEnv.txt look like on the working system? Jun 10 20:12:59 also, try using my show-pins script (with -vv in case any pins have been customized that are not expansion header pins on the bbb): https://github.com/mvduin/bbb-pin-utils/#show-pins Jun 10 20:15:00 a decompiled dtb is not suitable for being recompiled, it's just a way to make it slightly easier to examine the contents of a dtb in the rare case you'd want to Jun 10 20:20:07 zmatt: uEnv: https://pastebin.com/cEWu7uF3 , show-pins: https://pastebin.com/9FeJ7iGe Jun 10 20:20:20 zmatt: show-pins is certainly useful, thank you. Jun 10 20:21:04 so it doesn't look like it's using a custom dtb, it looks like it's using cape-universal Jun 10 20:21:20 be sure to disable audio/video in /boot/uEnv.txt on the new image Jun 10 20:21:49 actually, it doesn't looks like it's using cape-universal either Jun 10 20:21:55 even though the uEnv.txt does say so Jun 10 20:22:32 zmatt: yes, I have made sure to do so on the new image that there isn't any hdmi or audio yes. Jun 10 20:22:42 it just seems to use two uart overlays and some manually-exported gpios Jun 10 20:23:19 Yes, but the uarts are not important for the functionality of the cape. It works on the precompiled image even if the uarts are disabled. Jun 10 20:23:55 well as you can see, those are the only non-gpio pins in use Jun 10 20:24:44 yes Jun 10 20:26:55 presumably those gpios are things like control/status pins of the usb hub and the lte modem, but since they were exported via sysfs (rather than being declared in DT) they are unlabeled hence you'll need to check your schematic Jun 10 20:29:57 P8.11,P8.12 and P8.16 are control pins for the modem. The P9.23, P9.25, P9.27 and P9.30 are my own exports. Uart2 is something I also exported. Uart1 was exported already out of the box, but I have tried disabling it without any issues. Jun 10 20:34:19 The reason I was going down the route of compiling a new image for it was that I can't get the Adafruit BBIO python lib to work. According to something I found from RCN at https://github.com/adafruit/adafruit-beaglebone-io-python/issues/165 , it has to do with an outdated uboot. Is it possible to install a new uboot with the old image? Jun 10 20:39:35 outrageous_: that person was trying to use the latest image with an ancient u-boot Jun 10 20:39:59 also whenever you have trouble with adafruit libraries, it's typically because those libraries are hot garbage Jun 10 20:41:04 making a new image for it might be a good idea anyway since it sounds like whoever made your current image didn't bother documenting what he did to make things working :P Jun 10 20:43:28 you don't really need any library for gpios, pure python is fine Jun 10 20:44:17 the adafruit lib is known to be ancient and not-working, afaik .. Jun 10 20:44:32 she hasn't touched it in years Jun 10 20:45:59 reading an input is just reading a number (0 or 1) from a file, changing an output is just writing 0 or 1 to a file, and you can get change-events on inputs by using select(), poll() or epoll (all three available via the "select" module in python's standard library) Jun 10 20:47:45 zmatt: I see. Yes, I bought one of these boards last year to try it out and just recently got 10 more, hoping that they would come with a new image. I am going to push the company who's selling them to offer a new image themselves as I would buy more of the boards if they would. Jun 10 20:48:27 zmatt: Yes, I will see if I can figure that out. Thank you very much for taking the time to answer my questions. Jun 10 20:48:30 oh it's a custom board created by a third party, I see Jun 10 20:48:47 indeed Jun 10 20:50:14 From an Indian company called Yantrr. Jun 11 02:09:17 zmatt: not sure whether you saw my question earlier re what came of the image-shrinking discussion with rcn Jun 11 02:12:46 oh, yeah, but no idea Jun 11 02:14:06 i couldn't tell for sure, but it seemed you two were talking about the re-expansion step Jun 11 02:14:39 I don't think there's any particular obstacle other than just doing it, dunno Jun 11 02:15:28 ok, i'll finish putting together the complete snippet of commands i use to shrink an image and then bring it up with him again Jun 11 02:16:01 I very much doubt rcn needs to be told how to shrink the image Jun 11 02:16:43 also I have a script: https://pastebin.com/qFQb4NCq Jun 11 02:17:13 didn't think he needed it, but thought reducing the work involved might help :) Jun 11 02:18:49 re script: oh, nice. i quickly realized there's a step between the resize2fs -M and the truncate: shrinking the partition within the image Jun 11 02:21:06 studying the end of your script rn. wish my bash wasn't rusty Jun 11 02:23:35 I hope it works, I can't remember if I actually tested this.... I *think* I did? Jun 11 02:23:43 yeah I think I did Jun 11 02:25:09 the thing i do with dumpe2fs is gross, I'm sure there's a better way to do what I'm doing there, but I had already written that bit in the past so reusing it was the quickest solution Jun 11 02:25:29 I just want to know how big the filesystem is Jun 11 02:26:57 it's given in the output of the resize2fs -M operation Jun 11 02:27:10 yeah I probably should have extracted it from there instead Jun 11 02:27:23 maybe there was a good reason I didn't do that, I don't remember Jun 11 02:28:38 the resize2fs output doesn't exactly look like it's meant to be machine-parsed... the value we need is used embedded in a sentence Jun 11 02:29:08 well, it's given in number of blocks. it also says the block size, but maybe you weren't sure about robustly picking out both numbers Jun 11 02:29:31 yeah, at least dumpe2fs gives clean "key: value" pairs Jun 11 02:29:40 oh, then def use that Jun 11 02:29:50 which I then stick into a bash associative array Jun 11 02:30:20 i noticed that. not sure i've seen anyone actually use that feature before outside tutorials haha. good for you Jun 11 02:30:44 do you use bashdb? Jun 11 02:30:50 never heard of it Jun 11 02:31:10 this script is definitely pushing against the point where I'd be inclined to switch from bash to perl Jun 11 02:31:46 bash debugger. i haven't used it Jun 11 02:32:44 your script just gets to the point where i'd prefer to step through it in a debugger to make sure i'm following it correctly, but bashdb itself has never looked user friendly to me Jun 11 02:33:23 but anyway, after truncating, it looks like you're copying (fallocate, cat). how come? Jun 11 02:34:32 so, earlier I saved the stuff before the rootfs partition (i.e. partition table and u-boot) to a separate file and cut it from the head of the file using fallocate Jun 11 02:34:56 since the e2fs tools require a filesystem image, not a disk image Jun 11 02:35:11 that's the $image.header stuff i take it Jun 11 02:35:14 yes Jun 11 02:35:41 and after the filesystem stuff I inject it in front of the filesystem again using fallocate -i and cat Jun 11 02:35:56 then I fix the partition table and I'm done Jun 11 02:36:48 ah. i'm using a mac to do this and there's a command to mount the image like a loopback device, which then automatically creates devices for the partitions within it, which is what i execute the resizefs on Jun 11 02:37:05 that would require root privileges on linux Jun 11 02:38:36 or interacting with udisks maybe Jun 11 02:38:37 and doing it all in place isn't worth requiring sudo use? Jun 11 02:38:48 "doing it all in place" ? Jun 11 02:38:56 I'm doing it all in place Jun 11 02:39:01 well, depending on what you mean Jun 11 02:39:11 I'm never copying the image itself Jun 11 02:40:17 oh, is the fallocate at the end just pre-pending the header back onto the same image after it was removed earlier? Jun 11 02:41:10 it's not allocating a whole new file? Jun 11 02:41:12 yeah, fallocate -c/-i allow you to remove/insert a byterange of a file (dependent on filesystem support, and with certain alignment restrictions) Jun 11 02:41:27 correct Jun 11 02:41:34 ok Jun 11 02:42:27 see documentation for -c and -i in http://man7.org/linux/man-pages/man1/fallocate.1.html Jun 11 02:45:22 nifty Jun 11 02:51:19 closest thing macos has to fallocate is mkfile, but that doesn't support -i/-c equiv. actions Jun 11 02:51:38 i think my script will just need sudo :p Jun 11 02:53:38 looks like root privileges wouldn't be needed on most linux systems, udisks could be used provided it's installed (I think it is by default on most linux desktop distros) and the script is run by a user that is logged in locally Jun 11 02:54:17 at least that latter restriction is what the example policy for udisks requires for creating a loopback device Jun 11 02:55:57 but involving the kernel in modifying a filesystem image seems silly Jun 11 02:57:05 it would be nice if the e2fs tools accepted an offset parameter **** ENDING LOGGING AT Tue Jun 11 03:00:01 2019