**** BEGIN LOGGING AT Thu Sep 07 03:00:01 2017 Sep 07 10:34:13 i have an old custom cape which i have been using with capemgr on old 3.8 kernels until now. now i want to upgrade things to stretch and a new kernel. which kernel should i choose? and how should i proceed to migrate the old dts/dto to the cape management in use with most recent kernel? Sep 07 12:26:40 samael: capemgr hasn't changed all that much Sep 07 12:28:21 you might want to double-check whether all references in your overlay's dts are still right... I vaguely recall that some stuff in 3.8 used 1-based numbering for no good reason Sep 07 12:28:52 other than that... if your cape has an eeprom for auto-detection, the appropriate dtbo should still get automatically loaded from /lib/firmware Sep 07 12:39:45 as for kernels, I personally use the 4.9-bone series Sep 07 12:40:58 it may be a good idea to start fresh with a new image, I don't know if upgrading all the way from the 3.8 era (wheezy I presume?) is going to go right Sep 07 12:48:38 zmatt: jessie actually, but i don't feel such brave to update. i'll start from rcn prebuilt image again Sep 07 12:56:44 zmatt: the cape does not have the onboard eeprom (damn scrooge people), i just load the dto at boot. so it is enough to check the dts and still put the dto in /lib/firmware/? cool Sep 07 12:57:47 I thought jessie came with a 4.x kernel already? hmm Sep 07 12:57:48 is there a list of differences between the various available kernel to help one decide? or should i read the entire patchsets to have an idea? Sep 07 12:59:05 zmatt: yes but i started with wheezy and decided to still stay with 3.8 when updated to jessie, because $reasons Sep 07 12:59:33 the -ti series are shared across multiple TI SoCs, i.e. it also works on the beagleboard-x15. the -bone kernel is more specific to the beaglebone, and iirc closer to mainline Sep 07 13:00:37 i see. i remember years ago there was problems with USB support, i currently don't need it but who knows... are there better kernels for that? Sep 07 13:01:13 4.4-ti is still the default currently... there was a reason why 4.9 isn't the default yet but I forgot what. I haven't run into any problems with it anyhow Sep 07 13:01:28 dunno, I almost never use usb. I do believe things have gotten better since the early days Sep 07 13:01:53 I'd suggest 4.9-bone or 4.9-ti, these are the latest LTS kernels Sep 07 13:02:40 i guess -bone is perfect for me, i don't nee to use it with other ti-based SoCs. unless there is a fully compatible board i can use to develop my images and system housekeepings, then use the exact same image on BBB revC Sep 07 13:03:02 zmatt: good, i'll stick with that then Sep 07 13:04:51 I think there's still some other functionality in the -ti kernels not in the -bone kernels (i.e. neither in mainline nor ported to -bone). of course I don't know whether any of it is relevant to you Sep 07 13:05:16 e.g. I think remoteproc-pru is Sep 07 13:06:20 don't need pru atm Sep 07 13:06:56 pru is supported via uio-pruss on both -bone and -ti kernels anyhow Sep 07 13:09:36 btw, i'd be interested in a dev board 100% cpu compatible with BBB but faster, to use it as a test environment without the need of different kernels o images. is there something like that? Sep 07 13:10:46 depending on what you mean by "cpu compatible" Sep 07 13:10:50 *depends Sep 07 13:11:43 I also don't quite get what you mean by "to use it as a test environment without the need of different kernels or images" Sep 07 13:14:39 if you just want to run linux software with no hardware dependencies whatsoever then you can use pretty much any board with an arm cortex-A series cpu Sep 07 13:18:26 i often need to run a BBB to test and debug my softwares (which in production run on BBBs, so to check the "full stack" i cannot just use a container or a VM). it implies many repetitive tasks, which sometimes takes minutes to run on a BBB. i'd like a board with a faster CPU and possibly 1GB+ RAM, where i could just flash my existing BBB image and run it without further adjustments. no need for cape support. Sep 07 13:19:19 a kernel *can* be configured to work on multiple different ARM-based SoCs, including from different vendors. The -bone kernels however are only configured to support the AM335x Sep 07 13:20:06 (supporting multiple SoCs obviously makes the kernel bigger, and possibly less efficient) Sep 07 13:20:16 yep, that's why i was asking: by using -ti kernels which boards are supported out-of-the-box? maybe some of them are good for my needs Sep 07 13:21:13 well the bbx15 is obviously quite a bit faster than the bbb Sep 07 13:21:36 using fast storage connected to SATA or USB3 would also help a lot Sep 07 13:22:20 (the eMMC on the bbb is pretty slow, although the ones used on BBBs produced in recent times are at least faster than the early ones) Sep 07 13:24:03 are the x15 easy to buy right now? a quick search on mouser say they have it in a month Sep 07 13:25:05 digikey has them in stock Sep 07 13:25:51 zmatt: many thanks for all the info! Sep 07 13:25:52 oh, I just realized I overlooked a detail Sep 07 13:26:23 even if the kernel is compatible with both, you still can't have the same image working on both... the bootloader is different Sep 07 13:28:13 you however e.g. use a bootloader on eMMC that boots your image from some other storage Sep 07 13:28:48 thus preventing the x15 from trying to use the am335x-specific bootloader in your image Sep 07 13:29:00 that's a good solution anyway Sep 07 13:29:39 just curious though... if your software isn't really hardware-dependent, can't you just recompile it for x86 to run tests? Sep 07 13:34:27 my software are mainly twisted matrix daemons (python2, then), which of course i can run on other platforms. but they behave really differently depending on the hardware found at runtime (i.e. UARTs, etc), so i'd like to avoid many software adaptations only for debug purposes Sep 07 13:35:10 there would still be differences then if you use any board other than the bbb Sep 07 13:37:18 yep, but i think they are not crucial. at least i am willing to evaluate different hardware if possibly useful Sep 07 15:31:20 just receveid a couple BBB industial from arrow and having trouble flashing them with 7.11 debian Sep 07 15:32:54 Flashed the image on the SD card . Put it in the BBB and powered up with boot button depressed. let it go and no cyclon happening Sep 07 15:33:07 cylon Sep 07 15:34:22 Been trying different things for a while but the BBB will only boot to the as shipped image Sep 07 15:36:30 that's a pretty old version of debian Sep 07 15:37:13 though it ought to boot Sep 07 15:37:23 mjn: where did you get the image from? Sep 07 15:38:28 https://debian.beagleboard.org/images/ Sep 07 15:40:08 Now trying the image from here https://debian.beagleboard.org/images/bone-debian-7.11-lxde-4gb-armhf-2016-06-15-4gb.img.xz Sep 07 15:40:58 why that image? Sep 07 15:41:15 there's also https://beagleboard.org/latest-images but should have the same images Sep 07 15:41:20 makes it clearer which to use, though Sep 07 15:41:58 my understanding is that pressing the boot button will cause the BBB to boot from the SD card and the image on the SD card will automatically flash the image onto the EMMC Sep 07 15:42:39 yes, that's generally how it works Sep 07 15:42:40 pressing the boot button while powering up to be clear Sep 07 15:43:17 are you sure you're pressing the correct button? Sep 07 15:44:32 the bottun on the other side of the board from the SD card slot Sep 07 15:46:20 I've been holding it for about 10 seconds while the LEDs go from ooff to spread on to blank off and sread on then relase the button Sep 07 15:46:58 I can ssh into the BBB using putty Sep 07 15:47:22 is there a way to query the Sd card while it's plugged into the BBB ? Sep 07 15:48:31 Just to check the image is indeed correct on the SD card as the Win 32 Disk imager claimed Sep 07 15:49:32 look ad /dev/mmcblk* partitions which are not the ones that are mounted for rootfs Sep 07 15:49:34 Would there be something about the BBB industrial that would be different and causing this problem? Sep 07 15:49:56 it's not impossible Sep 07 15:52:18 root@beaglebone:~# ls /dev/mmcblk* /dev/mmcblk0 /dev/mmcblk1 /dev/mmcblk1boot1 /dev/mmcblk1p2 /dev/mmcblk0p1 /dev/mmcblk1boot0 /dev/mmcblk1p1 Sep 07 15:59:50 so your /dev/mmcblk0 is the microSD card Sep 07 16:00:03 looks like it's unpartitioned, so it doesn't look like your image took. Sep 07 16:00:48 e.g. i'd expect to see at least a /dev/mmcblk0p1 and possibly /dev/mmcblk0p2 Sep 07 16:01:09 the /dev/mmcblk1boot* indicate it's the eMMC Sep 07 16:01:28 oh, it does have /dev/mmcblk0p1 ... Sep 07 16:01:46 mount it and see what's on it ... Sep 07 16:01:54 sudo mount /dev/mmcblk0p1 /mnt Sep 07 16:22:23 so the drive is mounted. is there something specific I should be looking for? Sep 07 16:25:44 generally, make sure it's not just a bunch of cat pictures Sep 07 16:26:30 maybe includes /bin and /lib and so on Sep 07 17:31:22 a shame that u-boot doesn't support booting cat pictures Sep 07 18:25:25 So I finally got the BBB Insustrial from Arrow to load debian 7.11 image. (at least I have the cylon happening now). Turn out that uEnv.txt has to have #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh uncommented AND the boot button needs to be depressed during powerup Sep 07 18:42:42 mjn: probably that image is way too ancient to be compatible with the relatively modern bootloader that's probably preinstalled on the bbb Sep 07 18:42:54 hence the need to hold down the boot button Sep 07 18:43:07 (to force it to use the bootloader on card) Sep 07 18:57:01 are the pre0built images armel or armhf? Sep 07 18:57:23 armhf Sep 07 18:57:59 zmatt thanks, i am trying to set up linaro cross compile on ubuntu Sep 07 18:58:32 apt-get install gcc-arm-linux-gnueabihf Sep 07 18:58:39 yep Sep 07 18:59:12 any idea where i can find a sample project? (c or c++ file and make file) Sep 07 18:59:21 of course the linaro toolchain would work too, but using the debian cross-compiler is probably more convenient Sep 07 18:59:37 oh i think they are the same now Sep 07 18:59:42 no they're not Sep 07 18:59:52 but either should be fine Sep 07 18:59:53 that is the same command used on the linaro site Sep 07 19:00:26 where? Sep 07 19:00:43 retracing my steps Sep 07 19:01:13 here is one reference (not on linaro) http://nairobi-embedded.org/050_linaro_arm_toolchain.html#obtaining-a-pre-built-linaro-arm-cross-toolchain-package Sep 07 19:01:26 I am still looking for the linaro page i used Sep 07 19:02:27 well at least on debian that package is not a linaro toolchain Sep 07 19:03:07 you can check with arm-linux-gnueabihf-gcc --version Sep 07 19:03:37 a linaro toolchain will include the word "Linaro" somewhere in the first line Sep 07 19:06:01 anyway, a minimalistic way to use it: https://hastebin.com/raw/dobovavuka Sep 07 19:06:10 (I can run it because I have qemu-user installed) Sep 07 19:07:15 https://wiki.linaro.org/WorkingGroups/ToolChain Sep 07 19:07:30 Pre-built versions that run on generic Linux or Windows are available at http://www.linaro.org/downloads/ . Ubuntu 10.10 (Maverick) and later include pre-built versions of the toolchain. Try running apt-get install gcc-arm-linux-gnueabi. Sep 07 19:07:35 "" Sep 07 19:07:48 yes I can read that Sep 07 19:08:08 oh, same text different place Sep 07 19:08:09 curious Sep 07 19:08:38 yea, i am confused as well, maybe the working group is linaro Sep 07 19:08:54 working group that supports arm cross toolchain Sep 07 19:08:57 like I said, at least on debian it's a not a linaro toolchain. maybe it is on ubuntu, dunno. it really doesn't matter either way Sep 07 19:09:07 true Sep 07 19:15:07 zmatt i ran that on the beaglebone, meant to compile on ubuntu vm then run on bbb\ Sep 07 19:15:40 the resulting executable should run on the bbb yes Sep 07 19:15:55 zmatt makes sense it would work though right? i am assuming the toolchain on bbb is same as cross toolchain Sep 07 19:18:25 yes. on the bbb, arm-linux-gnueabihf-gcc is simply an alias for the native compiler (so you can use the same invocation for native compilation on the bbb and cross-compilation from your ubuntu system) Sep 07 19:18:31 Bad news. After Cylon and all leds off I remove the Sd card and repower. Boot starts then freezes Sep 07 19:19:21 This happens on two different BBB-I boards each with it's own SD card Sep 07 19:19:21 mjn: ohh, I can guess that one since recently someone else had the same issue with an ancient kernel on a modern board Sep 07 19:19:36 I'm guessing an error about the EXT_CSD version Sep 07 19:19:37 ? Sep 07 19:19:56 thanks for the info zmatt Sep 07 19:20:13 mjn: is there any reason you're set on using such an old debian image? Sep 07 19:20:17 Once I had one board loading (cylon) I started another Sep 07 19:20:49 although... wait, then flashing would have no reason to work either... that's odd Sep 07 19:21:22 so maybe it's a different issue Sep 07 19:21:26 My team was struggling with getting a peripheral to work on a later version a while back and we settled on that version Sep 07 19:21:41 by that version I mean 7.11 Sep 07 19:22:00 although still the most likely reason for problems is due to using an ancient system Sep 07 19:22:45 maybe the BBB Industrial needs a different DT that didn't exist yet Sep 07 19:23:06 although again then it shouldn't even boot the flasher... hmm Sep 07 19:24:03 you'll need to grab a boot log to be able to get help really... although even then I'm not really into supporting wheezy, I'm not an archeologist ;) Sep 07 19:24:13 zmatt i kdiffed the output binaries and they are not the same but both work Sep 07 19:24:43 zarzar: they're probably not even the same if you compile the same thing twice (due to build id) Sep 07 19:25:18 even with build id disabled, you'd need *exactly* the same version of gcc to get the same output Sep 07 19:25:42 anyway, I need to go for some shopping, bbl Sep 07 19:26:36 true, probably the version is different Sep 07 19:59:21 well, as you all know, migrating to newer revisions can cause a whole landslide of changes. I've contacted the manufacturer, Enbedded Planet. Hopefully they can shed some light Sep 07 20:19:34 * zmatt . o O ( and the longer you wait, the harder it becomes to migrate ) Sep 07 23:31:21 Hey guys!!am facing an issue with the second step of the "getting started page". Despite the fact that I did download the two drivers on my mac, the second box indicating step 2 does not go green. Therefore am not able to proceed to step 3 and connect it to the network. Any suggestions???? **** ENDING LOGGING AT Fri Sep 08 02:59:59 2017