**** BEGIN LOGGING AT Sat Jun 09 03:00:07 2018 Jun 09 04:34:18 e Jun 09 08:30:17 zz: are you booting from sd card or eMMC ? Jun 09 10:52:56 Hello Jun 09 10:54:23 my pc is not detecing the beaglebone blue... Need help.. Jun 09 11:03:23 Jai: please tell us more about your setup Jun 09 11:10:01 Beaglebone blue Rev A2 connected to pc via USB cable. Connected to a Ubuntu OS PC. Jun 09 11:12:31 tried with another USB cable too.. also tried with windows too.. But no luc.. Jun 09 11:13:35 Power ON LED is constantly ON. LED 0 is blinking in heartbeat pattern.. Jun 09 11:20:01 Hello Jun 09 12:55:15 quick question: is it possible to fry the wifi chip on the bbbw through the antenna cables? Jun 09 15:17:44 depends on what you connect it to :P Jun 09 15:17:52 but not by connecting it to an antenna, no Jun 09 19:42:15 well, i somehow have a beaglebone black wireless that thinks it has an ethernet port Jun 09 19:42:37 all its brothers and sisters do fine, with the same sd-card Jun 09 19:42:48 but this one suddenly decided "no more wifi" Jun 09 19:45:01 this one *suddenly* decided this? I mean if one thinks out of the box that it has ethernet I can tell you right away why that is, but not if it used to think it had wireless and suddenly changed its mind Jun 09 19:45:38 well, one of our interns might have friend one bbbw, when he was "brushing off dust" off of the large ICs housing Jun 09 19:45:45 that one does not boot anymore =) Jun 09 19:46:00 no amount of damage to the wifi chip would cause that anyway. you could turn the wifi chip into a plume of smoke and it still wouldn't suddenly think it has ethernet Jun 09 19:46:10 and i am guilty of mishandling one while unplugging the antennas Jun 09 19:46:17 yeah, that is puzzling to me Jun 09 19:46:29 however, i use the same sdcard, ip link shows me wlan0 on all other bbbws Jun 09 19:46:33 on this one it shows eth0 Jun 09 19:46:55 normally a bbbw with identity crisis is simply one from the batch with factory-misprogrammed EEPROM Jun 09 19:47:15 oh Jun 09 19:47:17 is that fixable? Jun 09 19:47:52 yes. there's a testpoint to override the write-protection of the eeprom and then you can write correct data to it Jun 09 19:48:51 i'd need the correct image as well, and a tool to flash it though, right? Jun 09 19:49:16 you need to boot it and log in Jun 09 19:49:22 how you boot it isn't important Jun 09 19:50:35 then confirm the problem by inspecting eeprom: Jun 09 19:50:35 head -c 32 /sys/bus/nvmem/devices/0-00500/nvmem | hexdump -C Jun 09 19:50:50 oh right, i can read it Jun 09 19:51:05 can i paste those three lines here? Jun 09 19:51:14 two actually Jun 09 19:51:38 bytes 4-15 should be (in ascii) "A335BNLTBWA5" Jun 09 19:51:47 if misprogrammed those last four bytes will be garbage Jun 09 19:51:56 no, they actually are correct =( Jun 09 19:51:57 as will the serial number on the next line Jun 09 19:52:14 hold on, are those bytes what uboot reads when deciding which device tree to load? Jun 09 19:52:21 yes Jun 09 19:52:41 unfortunately, it seems to be correct. let me look at my serial console output Jun 09 19:53:31 it is indeed loading reading /am335x-boneblack.dtb instead of the -wireless one i think Jun 09 19:54:42 that makes no sense, BWA5 results in -wireless Jun 09 19:55:08 ill boot again with the SD card, i tried stock image before for a second opinion Jun 09 19:55:12 have you erased eMMC? (since you're booting from sd card) Jun 09 19:56:53 i did not touch eMMC, but when i plug in an SDcard, it boots from there by default (i think?) Jun 09 19:57:32 it uses the bootloader from eMMC if there's one there, which can cause all sorts of hilarious problems if it's much older than the image on SD card that it's loading Jun 09 19:57:55 zmatt: https://gist.github.com/mbr/b1551fed6067125885f40e3b87ce85d6 Jun 09 19:58:42 2016, look at that vintage Jun 09 19:59:30 did your intern somehow manage to flash an image to eMMC that's too old to even support the bbbw or something? Jun 09 20:00:07 do not blame the intern, he's a great guy =). no, this is the stock image - no one did even flash anything on this, it came out of the box Jun 09 20:00:19 that's pretty bizarre Jun 09 20:00:27 so simply flashing a new image should solve the issue? Jun 09 20:00:34 anyway, wipe or reflash eMMC Jun 09 20:00:41 i'll try wiping it Jun 09 20:02:56 alright, i successfully killed it - taking out the sd card just yields a lot of CCCCCCCC... on uart0 Jun 09 20:03:12 that sounds normal? Jun 09 20:03:21 booting again with my SD card, however, does again select the non-wireless dtb Jun 09 20:03:47 ah you didn't mean to imply it was a problem, I misinterpreted Jun 09 20:04:04 okay that's really weird Jun 09 20:04:04 if what you're saying is correct, it seems my sd-card image is sub-par and only working because the other beaglebones have proper emmc firmware? Jun 09 20:04:20 oh that's another possibility Jun 09 20:04:21 luckily, i have more machines to compare. i'll check their eeproms Jun 09 20:04:39 i'll even risk killing one Jun 09 20:04:41 you can test that theory by booting one of them while powering on with the S2 button held down Jun 09 20:04:53 this temporarily removes eMMC from the boot order Jun 09 20:04:53 ah boot from SD Jun 09 20:05:16 (you can confirm you did it right by doing this without sd card: it won't boot. then insert sd card and press the reset button) Jun 09 20:09:59 alright, that seems to be the issue Jun 09 20:10:09 only those with a working "newer" bootloader work Jun 09 20:10:27 what sort of ancient u-boot did you get from where? Jun 09 20:10:30 i'm building my own bootloader through buildroot Jun 09 20:10:41 newer build, older version. check this: Jun 09 20:10:50 sillybeans Jun 09 20:10:59 U-Boot 2016.09.01 (Jun 07 2018 - 17:20:34 +0200) -- not working, freshly built Jun 09 20:11:10 vs U-Boot 2017.01-00006-g55e748eda0 (Jan 18 2017 - 13:01:45 -0600), Build: jenkins-github_Bootloader-Builder-503 Jun 09 20:11:23 you silly you :) Jun 09 20:11:24 but: ** Unable to read "uboot.env" from mmc0:1 ** -- might be the issue Jun 09 20:11:34 i might just be missing the .env file? Jun 09 20:11:41 I've never seen a file with that name in my life Jun 09 20:12:16 regardless, selecting the correct dtb is done based on EEPROM, not based on any config file (otherwise you can't have a single image working on different hardware) Jun 09 20:12:38 hmm, does a stock u-boot version work? Jun 09 20:12:41 or do i need a custom one? Jun 09 20:13:37 mainline u-boot you mean? no idea, never felt any motivation to try one. I know it uses a different boot script, but I don't know in which way it differs Jun 09 20:13:38 my buildroot just pins this at 2016.09.01 for some reason, but i can enable a recent 2018 one Jun 09 20:14:05 I do know that rcn's u-boot builds of course support new beaglebone variants well before mainline u-boot does Jun 09 20:14:13 there is no URL for uboot in my buildroot config, so it must be stock Jun 09 20:14:50 you could of course just download a prebuilt one. I mean, you've been unwittingly using prebuilt u-boot so far ;) Jun 09 20:15:21 yeah, but i need to understand what's going on to reproduce it. fingers crossed that everything made it into mainline uboot 2018.01 Jun 09 20:15:32 other than that, where's the URL for the BBB-specific uboot? Jun 09 20:15:33 to build from source, you can find rcn's patch relative to mainline here: Jun 09 20:15:42 (one sec, need to dig) Jun 09 20:16:14 https://rcn-ee.com/repos/git/u-boot-patches/ Jun 09 20:16:39 then subdir for the mainline u-boot tag, then apply 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch and optionally 0002-U-Boot-BeagleBone-Cape-Manager.patch Jun 09 20:20:32 i'll try that. now it's 22 minutes to rebuild the image... Jun 09 20:21:13 lol that sucks Jun 09 20:22:39 it's a small price for working CI - but yes, it makes me want to just take 3-6 month of and try to come up with a better build system =) Jun 09 20:25:24 don't get me wrong, I do think I should ensure I can reproduce an image from scratch, but the system of using a working image as a prototype has worked pretty acceptably for us so far Jun 09 20:29:11 zmatt: is that for products you ship or just prototypes? Jun 09 20:29:48 products Jun 09 20:31:01 hmm, are you basing those off of the official images? i find those have features i really don't want and are missing some i need. like ro root, systemd and such Jun 09 20:31:20 specifically shipped products use a "master" snapshot of the system image, while most of the application code is in a small number of individually updateable components Jun 09 20:31:45 zmatt: yeah, that's what i am working towards as well. only we are kind of starting out and haven't found "our" master yet Jun 09 20:32:53 once upon a time it was based off a console image from rcn, but I think nearly all of his customizations are gone by now and many of our own replace them Jun 09 20:34:50 I'm not claiming our way is ideal in any sense or fashion... part of it is simply familiarity, development convenience, and the need to ship something Jun 09 20:36:06 wait you currently don't have systemd you mean? Jun 09 20:37:23 that's not something I would want to have to do without Jun 09 20:46:24 zmatt: i might have confused some older stock images Jun 09 20:46:33 read-only root is a must though Jun 09 20:47:00 I have no experience with read-only root and its implications Jun 09 20:47:27 as an aside: which defconfig do i use with uboot? Jun 09 20:47:39 uhh it's called am335x_evm_defconfig I think Jun 09 20:47:52 unless there's a beaglebone-specific one Jun 09 20:48:17 oh there is Jun 09 20:48:19 am335x_boneblack_defconfig Jun 09 20:48:20 *** No rule to make target 'am335x_evm_defconfig' . oh well =/ Jun 09 20:48:21 there Jun 09 20:48:29 i'll try that one Jun 09 20:48:36 uhh what? how can am335x_evm_defconfig not exist? Jun 09 20:48:38 it definitely does Jun 09 20:48:54 what u-boot version are you using? Jun 09 20:50:08 might be a glitch with buildroot, it somehow set it to "custom svn" repo. the dir is empty. sorry about that Jun 09 20:50:26 it should be am335x_boneblack_defconfig anyway Jun 09 20:51:23 yep, starting over with that one Jun 09 21:56:46 zmatt: what's a good place to get a pre-built uboot from? Jun 09 21:57:44 https://rcn-ee.com/repos/bootloader/am335x_boneblack/ Jun 09 21:58:25 for the record, the stock version does not work Jun 09 21:58:44 but applying that single first patch does seem to make it work. although i might not have pressed the S2 button hard enough =) Jun 09 21:59:17 you can test it in the one with wiped eMMC of course Jun 09 21:59:21 then no S2 button is needed Jun 09 22:00:01 yeah, just did that. apparently, all is well Jun 09 22:04:02 zmatt: ... and that brought the "confused" bbbw back. thanks a lot =) Jun 09 22:05:38 \o/ Jun 09 22:08:07 now i'm wondering: i am trying to create an image that can be installed to the eeprom as well as onto an SD card. currently, my last issue is that the root partition is hardcoded (/dev/mmcblk0p2 in my case, which should be mmcblk1p2) when booting from emmc Jun 09 22:08:13 is there a trick here somewhere? Jun 09 22:08:29 "boot from whichever device this loader is on"? Jun 09 22:08:53 lol, "to the eeprom"... to eMMC you mean Jun 09 22:10:01 whoups, sorry. it's late ;) Jun 09 22:10:56 ehh, I'm used to u-boot passing the correct rootfs partition to the kernel Jun 09 22:11:51 it does that? Jun 09 22:12:00 that seems quite magical Jun 09 22:12:13 why? it knows from where it loaded the kernel just moments ago Jun 09 22:12:54 I don't know why you're expecting p2 ... I've never used multiple partitions on a beaglebone Jun 09 22:13:19 but I think it might iterate over the partitions... not sure Jun 09 22:13:47 if you're not using multiple partitions, how does that work? can u-boot read ext partitions? Jun 09 22:13:53 of course Jun 09 22:14:10 the internet has misinformed me then Jun 09 22:14:31 otoh, how does the beaglebone boot code know how to find uboot? Jun 09 22:14:39 fixed offset Jun 09 22:15:37 so... place MLO on ext partition, somehow tell the ext-filesystem creation thing to put it at exactly the right offset, preferably continuous? Jun 09 22:16:26 no, MLO is placed at a fixed offset Jun 09 22:16:35 between the partition table and the rootfs partition Jun 09 22:16:55 https://pastebin.com/1NeFbUjE Jun 09 22:18:18 (little u-boot install script I wrote) Jun 09 22:18:52 MLO can technically even coexist with the partition table at offset 0, but nobody seems to do that Jun 09 22:18:52 i'm borrowing that, for later! Jun 09 22:19:05 isn't that standard for x86? Jun 09 22:19:34 rom bootloader checks four offsets: start sector i*256 for i=0..3 Jun 09 22:20:46 yeah but x86 puts actual code there, while MLO is preceded by a configuration header (which, somewhat confusingly, is included in the "MLO" file produced by u-boot, even though that means the resulting file isn't an MLO anymore) Jun 09 22:22:44 i guess that would depend on low large it is Jun 09 22:23:04 the configuration header is fairly small, and the actual MLO starts at the next sector Jun 09 22:34:30 I need help in building an qt5 application to run on the beaglebone black. Is this the correct forum I need? Jun 09 22:35:24 there shouldn't be much beaglebone-specific to building a qt5 application, but it never hurts to simply try asking your question of course :) Jun 09 22:38:12 zmatt: I built beaglebone_qt5_defconfig which runs completed and runs on the beaglebone black. I can execute console applications fine but I would like to try a gui based one Jun 09 22:38:40 oh you're compiling qt5 yourself? I've never tried that Jun 09 22:38:41 but when I try to run I get the following error https://paste.ubuntu.com/p/kRmj2q6jT8/ Jun 09 22:39:12 zmatt: No I am using buildroot Jun 09 22:40:02 zmatt: like I mentioned I can run console based executable fine Jun 09 22:40:19 using the cross toolchain generated by buildroot Jun 09 22:43:26 back. sorry, microwave wanted my attention :) Jun 09 22:43:44 I don't know anything about buildroot, but I'll take a look at your error Jun 09 22:45:02 oh you're trying to use the sgx drivers? and judging by the error, the *old* sgx drivers Jun 09 22:45:37 zmatt: microwave sound is always a good thing Jun 09 22:46:31 ehm, good luck with that? :) I know how to get the new drivers working on debian (with a bit of effort), but I'm not sure how helpful that is ;) Jun 09 22:46:39 is it. nom nom :D Jun 09 22:46:42 *it is Jun 09 22:47:48 I don't even think the old sgx drivers are supported with the tilcdc driver? or are you also using an ancient kernel? Jun 09 22:47:51 zmatt: thanks for taking time to consider, keep looking. Unfortunately I only have Saturday night to look at these things Jun 09 22:49:18 no using Linux kernel 4.1 Jun 09 22:49:35 the root cause of your problem seems to be similar to the bootloader issue some other buildroot user had earlier: buildroot uses ancient versions of everything Jun 09 22:50:16 okay, so you *are* using an ancient kernel, but not actually ancient enough for the old sgx drivers I think. not sure, I'm not that deeply into archeology Jun 09 22:50:18 :) Jun 09 22:52:44 kernel 4.1 was maintained from July 2015 to May 2018 Jun 09 22:53:42 I don't think it is so far fetch then Jun 09 22:54:28 barely unmaintained is still unmaintained. maintenance is the promise to fix problems Jun 09 22:55:53 there is a guy on youtube that has done what I am trying to do but would not respond to me https://www.youtube.com/watch?v=_lTGwQmfs9k Jun 09 22:56:42 I'm seeing a desktop environment, so presumably he's simply using debian Jun 09 22:56:49 oh never mind Jun 09 22:57:27 what makes you think he uses buildroot though? Jun 09 22:58:20 buildroot users seem to be a very small minority Jun 09 22:59:40 in the description I thought I saw something about buildroot but now I can only see my comments Jun 09 23:01:45 zmatt: are you a desktop application person? Jun 09 23:02:04 I ask because I have a silly question to ask. Jun 09 23:02:10 I have no idea what that question even means Jun 09 23:02:51 I mean do you develop application for the desktop environment for example Qt GUI etc Jun 09 23:02:58 on Debian Jun 09 23:04:31 qt gui != desktop environment. for both of those the question however is no. I've helped a qt5 developer with building his applications on the beaglebone, and gotten the sgx drivers working to be able to use the eglfs qpa Jun 09 23:05:25 (the qt5 application in question is single-window-fullscreen using eglfs. we don't use a desktop environment on any beaglebone) Jun 09 23:06:59 okay correction accepted. Jun 09 23:08:07 how do I go about getting a similar setup as shown in that video assuming I scrap thing of buildroot Jun 09 23:09:21 I've never used qt5 creator. I think the qt5 dev mainly develops on his own computer and just syncs the sources over to the beaglebone and compiles it there Jun 09 23:13:19 I am an electronics engineer with embedded system experience (metal to metal) and I am trying to break into the embedded Linux world using the beaglebone black as hardware of choice. So I am trying to create a simple button press application that I can interface to some hardware. Jun 09 23:13:54 sounds like using something as obscure as buildroot might not be the smart move then :) Jun 09 23:14:56 just use debian, and probably the linuxfb backend for qt5 rather than the eglfs backend to avoid having to deal with the headache of the sgx drivers Jun 09 23:15:50 I agree with you. As I have been trying for a few weeks like you said the number of user are very few Jun 09 23:16:27 if you compile a qt5 application you should be able to run with little more than a QT_QPA_PLATFORM=linuxfb environment variable set Jun 09 23:17:12 I have a debian image which runs on the beaglebone fine and even has gui touch screen that is working Jun 09 23:17:12 (I recommend against using the lxqt image, it's unnecessarily fat and slow) Jun 09 23:19:07 QT_QPA_PLATFORM=linuxfb would this be something I put in the .pro file? Jun 09 23:19:32 no, environment variable when you run it. qt5 has runtime-selection of the Qt Platform Abstraction Jun 09 23:20:35 the defaults are set at compile-time of qt, so when using debian's qt5 packages (which assume a desktop environment) these defaults need to be overridden Jun 09 23:22:02 sorry for the delay, I am trying to process the information you have given :) Jun 09 23:22:23 that's okay, I'm trying to watch a silly youtube video Jun 09 23:22:27 ;) Jun 09 23:24:33 when I installed qt5 I ran the following executable qt-opensource-linux-x64-5.10.1.run. Are you saying that I need one that is debian-qt5 specific? Jun 09 23:24:57 uhh, I have no idea what that is Jun 09 23:25:27 but at the very least it's not referring to something that runs on the beaglebone obviously Jun 09 23:26:11 most applications and libraries have debian packages, hence you'd typically use those when using debian Jun 09 23:26:19 (installed via APT) Jun 09 23:26:28 It is an executable that installed Qt creator on my desktop environment. The buildroot I had created a cross toolchain which I was able to integrate and compile file that ran on beagle bone black Jun 09 23:27:00 what os are you using on your desktop? Jun 09 23:27:14 Ubuntu 18.04 Jun 09 23:27:17 mate Jun 09 23:27:36 Ubuntu 18.04-mate Jun 09 23:27:54 actually I didn't even really need to ask that: every linux desktop distribution will include a qt5 creator package Jun 09 23:28:13 so using some obscure standalone installer seems like an odd thing to do Jun 09 23:28:39 I am sure I didn't have Qt5 creator when I installed the OS Jun 09 23:28:59 but it will have been available in the package manager Jun 09 23:29:07 ah Jun 09 23:29:20 That I didn't know Jun 09 23:29:57 so should I remove this one and then try and see if I can install from the packet manager? Jun 09 23:30:51 I have not done any heavy project on Qt creator so I can easily replace it Jun 09 23:31:13 it ultimately doesn't really matter how you choose to develop on your desktop machine Jun 09 23:32:08 so do I need to install something else for getting qt5 on debian build which I have for the beaglebone black Jun 09 23:33:45 you'd copy over the sources to the beaglebone, and (after making sure the relevant dependencies are installed such as qt5-qmake and qtbase5-dev) compile it there Jun 09 23:34:36 cross-compiling is also possible but I have no idea how that works with qt5... in my experience, the more libraries are involved, the bigger the hassle of cross-compiling :) Jun 09 23:36:00 I hear you Jun 09 23:36:21 I actually feel like I am moving forward now :) Jun 09 23:37:10 I think the image on my beaglebone black is sdcard is "BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.img.xz" Jun 09 23:38:41 that's really really really old Jun 09 23:38:52 so what you practically saying is that load a stand debian image on to the BBB and install build-essentials qt5-make atbase5-dev and what other dependencies are required and build on the device Jun 09 23:39:23 I could look up a new version. Jun 09 23:39:36 just grab the latest iot image Jun 09 23:40:55 yeah I think the minimum you need is something like qt5-default qt5-qmake qtbase5-dev qtbase5-dev-tools Jun 09 23:41:07 and possibly qtchooser if that isn't already installed as dependency Jun 09 23:41:24 cool you are the man Jun 09 23:41:28 it's been quite a while since I did an install of that stuff so don't hold me to it :P Jun 09 23:42:03 it's worth being selective with which packages you installed, since the basics are a few 100 MB at most, while installing everything-and-the-kitchen-sink is gigabytes Jun 09 23:42:03 No worries it got me out of the vicious circle I have been running around int Jun 09 23:49:29 The channel is pretty quiet tonight. Where is everybody? Jun 09 23:50:41 it's not a social channel. there's no particular reason to expect it to not be quiet right now (or at any other time) Jun 09 23:51:55 I have been here and there is lots of conversation going on Jun 09 23:52:11 that can happen Jun 09 23:52:57 like I mention before this world is all new to me :) **** ENDING LOGGING AT Sun Jun 10 03:00:04 2018