**** BEGIN LOGGING AT Sun Aug 21 02:59:58 2016 Aug 21 20:11:09 is there a "console" headless image for the beaglebone black rev c? I'm highly confused as to why the recommended image for an sbc includes a DE. Aug 21 20:12:18 of course there is Aug 21 20:13:06 tbr: I don't see it here https://beagleboard.org/latest-images Aug 21 20:13:15 it includes a DE because too many people are "special". You wouldn't believe how many people claim their board is "now broken" after they flash a console image (and it doesn't have HDMI nor usb) Aug 21 20:13:35 twellick_: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Aug 21 20:14:33 tbr: that's hilarious, thanks I'll give that a read. Aug 21 20:15:31 np Aug 21 20:50:50 tbr: thanks a ton, found the image I was looking for time to flash! Aug 21 20:51:51 :) Aug 21 20:55:55 tbr: so if I understand this right, i'll dd the image to a microsd, boot off the microsd, uncomment the flasher line in uEnv, reboot and the eMMC will be flashed with the image i dd'd to the microsd? Aug 21 20:56:10 wipe the microsd and be on my merry way after? Aug 21 20:56:34 twellick_: yes, obviously uncompress the image before/while Aug 21 20:56:45 also attaching to the debug UART is a given Aug 21 20:56:59 the debug port? Aug 21 20:57:03 yes Aug 21 20:57:04 I have that hooked up already Aug 21 20:57:20 didn't want to mess with ssh/hdmi Aug 21 20:57:21 I expected that. :) Aug 21 20:57:52 many a person at this point gets told to just get one, as they cost 1-2$ on ebay if you go cheap Aug 21 20:57:55 I bought the bbb to flash libreboot so yeah don't want to mess around lol Aug 21 20:58:11 tbr: I ate my lunch and bought the adafruit one haha Aug 21 20:58:17 was like 20usd Aug 21 20:58:29 real FTDI then :) Aug 21 20:58:35 yeah, that's what I read Aug 21 20:58:41 supposedly the knockoffs can be finnicky Aug 21 20:59:01 and when you're flashing new firmware ontop a laptop i dont really want to risk bricking it Aug 21 20:59:03 haven't noticed problems. have both types Aug 21 20:59:05 I have little issue with CP2012. CH340 or whatever appears nightmarish. Aug 21 21:00:27 tbr: I also bought this case, it is fantastic. https://www.amazon.com/GeauxRobot-BeagleBone-Black-Compact-Case/dp/B00JVD594E Aug 21 21:01:04 nice and compact still and protects the pcb Aug 21 21:01:20 ah, neat Aug 21 21:01:27 total waste of money probably Aug 21 21:01:48 10$ doesn't sound like waste of money Aug 21 21:02:17 hard to make something yourself or have acrylic done to order for that Aug 21 21:02:32 oh yeah definately, it's far beyond my scope of knowledge to make something like that Aug 21 21:11:18 tbr: do you know by any chance if the console image ships non-free blobs? Aug 21 21:11:41 I doubt it Aug 21 21:11:46 good Aug 21 21:11:55 i'll check once its flashed just curious Aug 21 21:13:09 booting is completely done by U-Boot, no blobs. No other firmware necessary for operation. Optional are: power management firmware and SGX/PVR gpu driver Aug 21 21:15:38 tbr: fantastic, I know GNU rates this sbc higher than most. Aug 21 21:16:28 the extra cost of the bbb is 100% worth it to not rely on blobs imo Aug 21 21:24:50 tbr: so I believe I just flashed the image, the documentation says it can take 45 minutes and it just took maybe 5mins. hmm.. Aug 21 21:24:59 it powered down too like the docs said it would Aug 21 21:25:10 not sure why it would be 40 minutes faster Aug 21 21:26:36 yep seems like it worked fine Aug 21 21:27:38 tbr: thanks for all the help that was shockingly easy, I expected more pain. Aug 22 00:02:18 the power management firmware is published in a git repo, not sure what license though Aug 22 00:02:40 (as in, source code) Aug 22 00:03:30 only sgx requires proprietary userspace libs (with reasonable redistribution license) Aug 22 00:14:56 zmatt: are these libs shipped with the images provided? Aug 22 00:29:10 zmatt: also, do you know if the bone kernels are deblobbed? hard to find info on it Aug 22 00:34:42 it looks like SGX module is not shipped "lsmod | grep omaplfb" returns nothing, which is good... Aug 22 00:41:58 sgx blobs probably aren't (look for pvrsrvkm.ko), wakeup-m3 firmware image probably is with -ti kernels (not sure -bone kernels), I have no idea what you mean by "if the bone kernels are deblobbed" Aug 22 00:46:33 the TSPA might actually qualify as an open source license (when applied to source code rather than binaries), it grants "license to reproduce, use, and create modified or derivative works of the Licensed Materials provided to you in source code format and to distribute an unlimited number of copies of such source code Licensed Materials, or any derivatives thereof, in any format." subject to conditions that Aug 22 00:46:39 look mostly like TI covering its ass (no ... Aug 22 00:46:42 ... warrenties etc) Aug 22 00:47:53 http://arago-project.org/git/projects/?p=am33x-cm3.git;a=blob;f=License.txt;h=198e640df05166519de32dfdaa5b076f98a33062;hb=HEAD Aug 22 00:48:43 (note that no part of that firmware is provided in object code only, so you can ignore those provisions of the license) Aug 22 01:02:21 apparently the beaglebone black does not like the linux-image-armmp stock kernel on debian jessie lol. Aug 22 01:02:31 ended up in initramfs with a broken boot Aug 22 01:03:18 zmatt: thanks, my goal is to make my bbb as "free" as possible. deblobbed like libre-linux kernel Aug 22 01:03:58 hence why i just tried the stock kernel without sucess Aug 22 01:04:57 what freedom are you imagining you have now that you wouldn't if you installed the sgx blobs? Aug 22 01:05:35 proprietary blobs are potential backdoors etc... Aug 22 01:06:41 that's not a freedom concern but a security concern Aug 22 01:07:04 run 3d applications in a sandbox if you're very concerned about it Aug 22 01:07:54 zmatt: not according to the FSF, example https://www.gnu.org/distros/common-distros.html#Fedora Aug 22 01:08:06 non-free blobs = violates foss Aug 22 01:08:22 zmatt: I don't need to run 3d applications Aug 22 01:08:44 you're not answering my question: what freedom are you imagining you have now that you wouldn't if you installed the sgx blobs? Aug 22 01:09:59 regardless of whether it brings you utility, or whether it might pose a security risk Aug 22 01:10:04 zmatt: "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. " Aug 22 01:10:08 violated Aug 22 01:10:16 "The freedom to redistribute copies so you can help your neighbor (freedom 2). " Aug 22 01:10:18 violated Aug 22 01:10:20 no Aug 22 01:10:27 yes Aug 22 01:10:31 if you install the blobs Aug 22 01:10:32 you have the freedom to redistribute copies Aug 22 01:10:33 those freedoms Aug 22 01:10:34 are violated Aug 22 01:10:37 okay. Aug 22 01:10:46 freedom 1 then Aug 22 01:10:57 no matter how you look at it non-free blobs violate foss Aug 22 01:11:02 you don't have that right w.r.t. the sgx blobs regardless of whether you install them or not Aug 22 01:11:21 purging them from your system does not increase your rights or freedoms Aug 22 01:11:57 semantics really Aug 22 01:12:26 purging non-free blobs does make the system more "free" Aug 22 01:12:31 I don't even see how that is an arguement Aug 22 01:12:52 I don't understand what it's an argument for Aug 22 01:14:22 zmatt: this is the motivation for most of us https://en.wikipedia.org/wiki/Linux-libre#Effects Aug 22 01:14:22 [WIKIPEDIA] Linux-libre#Effects | "Linux-libre (/ˈlɪnəks ˈliːbrə/) is an operating system kernel and a GNU package that is maintained from modified versions of the Linux kernel. The aim of the project is to remove from the Linux kernel any software that does not include its source code, has its source code obfuscated, or is released under..." Aug 22 01:14:25 as much as I like open source software, in the absence of an open source driver (and none is on the horizon) having a working driver that makes my system more useful still seems like a net benefit, unless it came with annoying restrictions like inability to redistribute but it doesn't Aug 22 01:15:03 zmatt: security concerns seems like a very valid reason if you're a pragmatic guy Aug 22 01:15:17 zmatt: for me the reasons are both security and having a more free system Aug 22 01:15:25 hardly, maybe the hardware itself is backdoored, how would you know? Aug 22 01:15:42 on my laptop Aug 22 01:15:43 x86 Aug 22 01:15:43 also, open source is hardly a guarantee for lack of security problems Aug 22 01:15:47 libreboot Aug 22 01:16:12 on the beaglebone the u-boot should suffice Aug 22 01:16:26 of course, but what's the alternative that is superior? Aug 22 01:16:28 there is none. Aug 22 01:16:38 u-boot in invoked by the ROM bootloader to which you do not have any source code Aug 22 01:17:06 well there is nothing I can do about that then, but everything I can do I will Aug 22 01:17:11 to have a more free system Aug 22 01:17:30 the bbb is about as good as it gets in the sbc arena afaik Aug 22 01:17:41 for freedom Aug 22 01:17:58 * zmatt shrugs Aug 22 01:18:02 whatever floats your boat Aug 22 01:18:02 :P Aug 22 01:18:52 agreed Aug 22 01:20:32 I think the generic debian arm kernel is too old for the bbb or something Aug 22 01:20:44 trying to figure out why im not able to boot with it Aug 22 01:21:08 no part of the am335x requires proprietary kernel blobs so you needn't worry about that anyhow Aug 22 01:21:34 (as in, none exist or have existed) Aug 22 01:22:12 even the kernel part of the sgx drivers is GPL Aug 22 01:22:52 on an embedded system you're generally better off with a system-specific tuned kernel than a generic one Aug 22 01:24:52 zmatt: yeah, surely that is true. I just wanted to see if I could run the stock kernel Aug 22 01:25:13 tried to fix it in initramfs recovery shell to no avail, kern panics haha Aug 22 01:25:23 zmatt: what kernel do you recommend in that case? Aug 22 01:25:30 I'm pretty sure it ought to work if you're using a non-ancient mainline kernel Aug 22 01:25:50 I use 4.7-bone series currently Aug 22 01:26:03 with custom config and some patches Aug 22 01:27:02 zmatt: yeah it was 3.16 Aug 22 01:27:26 zmatt: whats the difference between the bone and ti kernel? Aug 22 01:27:37 3.16 is pretty ancient Aug 22 01:27:43 yeah it is Aug 22 01:28:43 ti generally has more patches that are still in the process of being upstreamed, which may enable more functionality. currently however most efforts on the -ti kernels are probably directed at the am57xx rather than the am335x Aug 22 01:28:47 crazy how fast flashing a new image to the emmc is Aug 22 01:28:53 2 minutes maybe Aug 22 01:29:11 zmatt: interesting, and what about the bone kernel? Aug 22 01:29:33 as the name suggests, specific to beaglebone Aug 22 01:30:25 ill try it out Aug 22 01:33:42 https://github.com/dutchanddutch/bb-kernel my own fork of the patches/build repo for the bone kernel Aug 22 01:34:56 (of course my patches and config are specific to my needs, although the patches are mostly suitable for general consumption I think) Aug 22 01:35:31 except the most recent one *might* break IMA, still need to check that (I've never used IMA though nor is it enabled in kernel config) Aug 22 01:35:31 zmatt: I'm not a dev, so this is mostly foreign to me. Aug 22 01:35:53 my dev knowledge extends to writing glue python for sysadmin/pen tasks but thats about it Aug 22 01:36:32 are the commits your own? Aug 22 01:36:38 1,089 commits? Aug 22 01:36:52 notice the word "fork" Aug 22 01:36:58 right Aug 22 01:37:04 > not a dev Aug 22 01:37:07 also near the top of the page "forked from" Aug 22 01:37:13 mhm Aug 22 01:39:09 as far as building kernels though this is silly easy... grab any random decently beefy debian machine, apt-get install needed packages (the script will check if any are missing and tell you what to apt-get install), ./build_deb.sh and grab some coffee ;) Aug 22 01:39:27 and out come debian packages for your very own kernel Aug 22 01:40:29 zmatt: yeah, I've built a rbpi kernel for QEMU with some patches before Aug 22 01:40:39 zmatt: I just mean creating my own patches and configs for a kernel Aug 22 01:40:42 that is beyond my knowledge atm Aug 22 01:41:20 config is mostly just tedious... "what is this option? do I need it? is it useful?" Aug 22 01:42:22 doing development in the kernel otoh is a different story... it's a really hostile environment imho Aug 22 01:42:30 yeah I am positive I could learn it just haven't had a need to yet, but maybe now that I am diving into the sbc world there will be a need for me to learn. Aug 22 01:43:05 yeah I've heard stories and read the mailing lists Aug 22 01:43:08 some are quite funny Aug 22 01:43:15 I love to read linus torvalds rant Aug 22 01:47:50 yes and in my very limited number of posts to kernel-related mailing lists I already managed to anger a maintainer already (though I still think I was right and rmk was wrong :P ) Aug 22 01:49:03 though I meant more the codebase itself Aug 22 01:50:16 zmatt: you shouldn't give up Aug 22 01:50:25 kernelspace is not very tolerant of even small mistakes. more problematic is that often it's very hard to get an overview of what the rules are in some particular context (invariants to be maintained, locking rules, etc) Aug 22 01:50:41 which makes it very hard to have confidence that a modification is correct Aug 22 01:51:15 wmat: who said I was? Aug 22 01:51:25 zmatt: excellent Aug 22 01:51:36 doesn't change any of the above though Aug 22 01:52:14 and if I can do something in userspace rather than in the kernel, I most definitely do Aug 22 01:53:41 though lately I've been hacking away at the omapdrm driver... mostly with not that many kernel panics or oopses Aug 22 01:54:19 I'm going to stick with the stock ti 4.4.x kernel for now Aug 22 01:54:40 read some mailing lists sounds like its best to stay with the ti one Aug 22 01:54:49 at least for my use Aug 22 02:21:40 zmatt: so apparently there is a stable bone kernel which is a better choice than the debian stock kernel I mentioned earlier, hilariously it is even older. "3.8.13-bone80" Aug 22 02:25:12 don't, unless you're into archeology Aug 22 02:26:41 zmatt: see here is what im doing with my bbb, flashing libreboot (SPI). I'm going to have a seperate install on a microsd with the stable kernel setup for flashing then use the emmc for tinkering Aug 22 02:26:45 best of both worlds Aug 22 02:26:57 I need that kernel for capemgr though Aug 22 02:26:58 I've never experienced any stability problems with just using the latest (non-rc) bone kernel, but if you think using an "LTS" kernel is better then just grab 4.4-bone Aug 22 02:27:14 capemgr is in all -bone and all -ti kernels Aug 22 02:27:23 not in 4.4 ti Aug 22 02:27:23 (and also largely unnecessary for most purposes) Aug 22 02:27:26 I can tell you that for sure Aug 22 02:27:33 I can tell you for sure it is Aug 22 02:27:39 http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI0 Aug 22 02:27:41 really? Aug 22 02:28:09 zmatt: I encourage you to check for /sys/devices/bone_capemgr.*/slots Aug 22 02:28:12 on the 4.4 ti kernel Aug 22 02:28:14 it does not exist Aug 22 02:28:27 exists on bone Aug 22 02:28:35 that's because the path changed slightly, iirc it's under /sys/devices/platform/ Aug 22 02:28:46 the change isn't -ti vs -bone, it's ancient kernel vs non-ancient kernel Aug 22 02:29:43 zmatt: like i said ill have a seperate sd for flashing spi Aug 22 02:29:59 also, capemgr is a beaglebone-specific kludge, in 4.x kernels they introduced a new mechanism via configfs for loading overlays Aug 22 02:30:43 you can use my overlay-utils for convenience if you want https://github.com/mvduin/overlay-utils (includes spi example) Aug 22 02:30:55 zmatt: i dont want to figure that out just to flash libreboot, much easier to just use the old kernel on a seperate sdcard install Aug 22 02:31:05 its a one time ordeal Aug 22 02:31:15 doesnt make sense to invest tons of time learning the new interface or w.e Aug 22 02:31:47 okay, just saying your original statement was incorrect Aug 22 02:34:06 zmatt: you're right. **** ENDING LOGGING AT Mon Aug 22 02:59:59 2016