**** BEGIN LOGGING AT Mon Nov 16 02:59:58 2015 Nov 16 05:59:25 hi Nov 16 05:59:55 hello Nov 16 06:01:01 I'm getting an error while building buildroot, can anyone help me Nov 16 06:01:03 ? Nov 16 06:21:55 https://learn.adafruit.com/setting-up-wifi-with-beaglebone-black/hardware <--- this is a really great article Nov 16 06:22:17 disabling hdmi, upgrading kernel and their script helped my wifi work nicely Nov 16 06:53:08 btipling: given that there are things like PCIe on those connectors, I guess they are mostly meant to mate with a matching connector on a PCB extensionboard Nov 16 08:30:09 tbr / btipling: you can also check the schematic of course to see what's on them, or my pins spreadsheet for the x15 ( https://goo.gl/S4t2lw ) Nov 16 08:30:45 all pins that contain "exp" in column C are on the expansion connectors (I was too lazy to record which connector/pin) Nov 16 08:32:35 tbr: and you're correct about that... I recognize the connectors from other TI EVMs, they're suitable for highspeed signals but there's no way you can easily connect something to a single pin like you can on the BBB Nov 16 08:33:36 (and connecting/disconnecting two boards mated by multiple of these connectors is really hell) Nov 16 08:35:02 yup Nov 16 08:35:58 then again, you can have three 24-bit parallel video outputs on them (in addition to the HDMI output on the x15 itself), so comparing it with the BBB is kinda pointless anyway ;) Nov 16 08:35:59 I guess it might be interesting to design a simple breakout Nov 16 08:36:15 for just general fooling around Nov 16 08:36:35 for everything with signal quality requirements you'll likely have to design custom boards Nov 16 08:37:07 yeah, for simpler I/O purposes I'd say a breakout board that also contains extra protection would be useful Nov 16 08:37:20 especially since frying an x15 is a bit more expensive than frying a BBB Nov 16 08:37:44 then again my board doesn't have connectors, so I can just solder wires to the pads if I really want to Nov 16 08:37:56 weird it doesn't have connectors Nov 16 08:38:31 AFAIU the beta boards were shipped without as sourcing the connectors would have introduced delays and a choice was made Nov 16 08:39:27 I might actually solder some stuff on as I'd like to connect an 802.15.4 transceiver and test it with the board Nov 16 08:47:30 http://www.ti.com/lit/ds/symlink/sn74cb3t16211.pdf something like this looks nice... although non-inverted OE would have been even better since then you could tie that directly to the reset output Nov 16 08:49:37 pins isolated in absence of power or when disabled, clamped (without current flow) to vcc when enabled, 5V-tolerant in both cases Nov 16 09:14:44 hi all, is it possible to use LCD24 togather with eMMC on beaglebone black? Nov 16 09:15:13 ot hte answer is LCD24 or eMMC ? Nov 16 09:16:21 lcdc is fully usable on the expansion headers in combo with eMMC Nov 16 09:17:31 see also the LCDC tab of my spreadsheet -> https://goo.gl/Jkcg0w Nov 16 09:21:25 24-bit only sacrifices the mmc 2 port on the expansion header (eMMC is mmc 1, μSD is mmc 0) Nov 16 09:22:05 the P8 tab of the spreadsheet shows this in more detail Nov 16 09:22:33 ty Nov 16 09:24:11 i ve got confused by 8.1.2 section of bbb system refence manual Nov 16 09:25:20 (apologies for the eye-stabbing purple color of the eMMC pins in my spreadsheet, I just wanted to be sure people can't overlook that those pins are special :P ) Nov 16 09:25:32 :-D Nov 16 09:27:28 if you plan to connect anything to the LCDC pins, don't forget to mind the fact that those pins are also used for boot configuration (latched at power-on-reset release), so avoid pulling them Nov 16 09:27:44 (applies only to d0-d15 though) Nov 16 09:28:33 thank you - i am aware of it Nov 16 09:28:41 okidoki :) Nov 16 09:28:59 it is a good news i don't have to 24 bit tft to 16 Nov 16 09:29:25 but i don't get what is written in bbb srm the :( Nov 16 09:30:02 am335x pinout calcuator also shows everythnig is fine Nov 16 09:30:23 * zmatt checks to see what's written in that section of the TRM... Nov 16 09:32:05 it's just warning about the eMMC pins... I don't see anything suggesting they would conflict with LCD Nov 16 09:33:58 looks like there's quite a bit of wrong info there anyway Nov 16 09:36:01 "When used for other functions, the eMMC cannot be used. This means you must boot from the uSD slot." :\ Nov 16 09:36:50 when *those pins* are used for other functions Nov 16 09:37:12 note that the point is listed under "If using these pins," Nov 16 09:37:22 where "these" refers to the table above it Nov 16 09:37:30 none of those pins are used by LCDC Nov 16 09:38:21 okay thank very much - i ll go consume your table and sitara TRM before asking any other questions Nov 16 09:39:39 I actually made my spreadsheet to consolidate pretty much all relevant info in a single spreadsheet (which would otherwise be scattered across many places in many docs) Nov 16 09:40:25 hi, I'm trying to boot the Kali BB version on a Beagle Bone Black, I've flashed the OS to a micro SD card - plug it into the BBB powered down, holding the USB/S2 switch down I then plug the device in, but nothing other than the power led lights up Nov 16 09:40:44 yes quite atonishing work indeed Nov 16 09:40:51 eventually I let go of the USB/S2 switch but only the power button stays light up Nov 16 09:41:03 any suggestions on what I'm doing wrong? Nov 16 09:42:00 thunder5_: "USB/S2" ? it's just called S2, or "SD boot button" Nov 16 09:42:12 and it means boot from the μSD card is failing Nov 16 09:43:00 in an early stage apparently Nov 16 09:44:20 oh dear Nov 16 09:44:27 thunder5_: how did you write the image to the card? Nov 16 09:44:35 checking output on the serial console is the best way to see what's going on, but there's another way to recognize whether boot rom considers your card to be bootable Nov 16 09:44:50 i used windiskimage32 Nov 16 09:44:57 said it wrote successfully Nov 16 09:45:08 and you decompressed the image first? Nov 16 09:45:08 has never failed on making bootable things before Nov 16 09:45:11 yes sir Nov 16 09:45:15 hrm Nov 16 09:45:38 checksum was fine on the compressed image too Nov 16 09:45:39 if boot ROM doesn't think your SD is bootable, and your BBB is connected to USB (you can connect it after powering up or use it to power the BBB), then the BBB will show up via USB as a network device Nov 16 09:45:54 that should be noticable Nov 16 09:46:38 with SD button pressed, boot ROM tries the following boot devices in order: spi, μSD, usb, uart Nov 16 09:46:55 (normally it tries: eMMC, μSD, uart, usb ) Nov 16 09:48:12 if it never shows up as a usb device then probably boot rom did manage to load the MLO from card and execute it, and it subsequently crashed or otherwise failed Nov 16 09:49:03 the latter is pretty much impossible to diagnose without a console cable... I highly recommend one, since it sucks to be blind when you have trouble booting Nov 16 09:49:41 console cable Nov 16 09:49:42 ok Nov 16 09:49:58 http://elinux.org/Beagleboard:BeagleBone_Black_Serial Nov 16 09:50:08 ah, zmatt is there... Nov 16 09:50:18 script didn't work Nov 16 09:50:27 same error message as before Nov 16 09:50:59 Sandhya: huh? did I mess up the upload? since I did remove the dependency on 'experimental' Nov 16 09:51:12 i think you did Nov 16 09:51:56 well that's what the error message was about, so it can't still be there if I removed the 'use experimental' line Nov 16 09:53:30 I don't think I'm now using anything that would require a recent perl version Nov 16 09:54:50 but before you put in more effort, check whether you even have the two '/sys/kernel/debug/...' paths mentioned in the source code of my script, since if you don't then the script won't work anyway Nov 16 09:55:49 I don't know how big the chance is that it'll work on a 3.8 kernel since I only tested on 4.1 and later and much has changed since then Nov 16 09:56:23 at the moment, I have to do something else, but I'll try it Nov 16 10:21:17 zmatt: really great table Nov 16 11:45:16 mmc0 is exposed only via sdcard slot on beaglebone black? Nov 16 12:06:24 i have question about .dtb files: do they affect the machine accross reboots? do they work something like firmware functionality? Nov 16 12:07:00 if the file is present across reboots Nov 16 12:07:05 it will affect the machine Nov 16 12:08:51 thanks Nov 16 12:09:58 i came to this conclusion because i added some touchscreen .dtb from element13 about BBView on lxde image for the view cape to work Nov 16 12:10:23 and now when i use a console flasher image after finishing flash the bone is bricked Nov 16 12:10:42 if i flash a lxde image again the bone is ok again Nov 16 12:11:03 maybe the flasher image is not deleting someting? Nov 16 12:27:45 maquefel: yes Nov 16 12:30:19 hi Nov 16 12:30:44 paranic: just in case try a cold power-on rather than a reboot, some chip config may be insensitive to warm reboots (and most notably the HDMI framer is entirely unaware of any kind of reset other than power cycling) Nov 16 12:31:31 thus some config can "bleed over" from the running system when rebooting into a different one Nov 16 12:32:25 zmatt: thanks Nov 16 12:32:38 Hi use: 3.8.13-bone70 Nov 16 12:32:46 and have this problem: Nov 16 12:32:50 after: Nov 16 12:32:55 zmatt: i will also try to boot with and eMMC image and zero-out the onboard mmc Nov 16 12:33:46 paranic: dtbs should not leave any kind of persistent config though (other than the dtb file itself) Nov 16 12:34:03 echo ADAFRUIT-UART1 > /sys/devices/bone_capemgr.*/slots Nov 16 12:34:14 -bash: /sys/devices/bone_capemgr.*/slots: No such file or directory Nov 16 12:34:40 zmatt: then the flasher image i was using was not wiping out the fileystem or the partition table before copying the release Nov 16 12:35:00 file slots, not exist?! Nov 16 12:35:04 why? Nov 16 12:35:04 i am using https://rcn-ee.com/rootfs/bb.org/ images Nov 16 12:36:14 paranic: those normally overwrite eMMC completely Nov 16 12:37:03 they don't merely copy files Nov 16 12:37:08 fr1: as you've already been told this a few times, i won't spend too much time on it. Nov 16 12:37:13 maybe its missing cp -f or something because i remember i overwriteen a dtb to make the BBVIEW to work Nov 16 12:37:45 fr1: basically: "*" is the wildcard. if you want to do it programmatically, replace the wildcard by the actual name Nov 16 12:37:46 paranic: it's copying over the raw filesystem data, it doesn't even care about any preexisting filesystem (or even partition table) on eMMC Nov 16 12:38:20 fr1: if in doubt, evaluate the contents of /sys/devices beforehand. Nov 16 12:39:07 LetoThe2nd:-bash: /sys/devices/bone_capemgr.9/slots: No such file or directory Nov 16 12:39:19 fr1: nothing more to say from my side, sorry. Nov 16 12:40:47 LetoThe2nd:"slot" file, is not created by the system, because? Nov 16 12:41:06 you have any idea? Nov 16 12:41:33 because, sysfs. you don't create "files" there, the kernel does Nov 16 12:41:55 they're just representatives of kernel objects Nov 16 12:51:38 zmatt:but, the system have an problem? In first time, "slot" file,It was available. Now no, suddenly Nov 16 12:52:03 * zmatt shrugs Nov 16 12:52:22 I don't use capemgr and I don't use such ancient kernels either Nov 16 12:52:27 so can't help you there Nov 16 12:53:59 zmatt:okay, but how can set on the ttyO1, otherwise? Nov 16 12:57:06 zmatt:otherwise how can I enable UART1 on ttyS1? Thanks, can you help me? Nov 16 12:57:19 *ttyO1 Nov 16 12:58:30 I use:Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux Nov 16 13:01:19 did anyone manage to get rtl8812au to work with the beaglebone? Nov 16 13:10:38 thanks Nov 16 13:16:40 fr1: 1) read something Nov 16 13:16:43 fr1: 2) understand it Nov 16 13:16:51 fr1: 3) google for the parts you dont understand Nov 16 13:16:59 fr1: 4) ... Nov 16 13:17:11 fr1: go back to 1) until problem solved Nov 16 13:17:15 fr1: 6) profit Nov 16 13:18:08 fr1: please note, this channel is known not to be friendly to people who 1) do not listen to advice give, and 2) demand #exactsteps Nov 16 13:19:32 given* Nov 16 13:47:14 @KotH, KotH: I have shown a problem, stop! I did Google searches, and there is nothing. I thought you could help me. No problem. Nov 16 13:47:40 thaks for all Nov 16 13:48:02 fr1: you disregard everyone who tells you that you are trying to use a bulldozer to hammer in a nail Nov 16 13:49:18 fr1: your problem is simple, you have been told the solution multiple times Nov 16 13:49:23 fr1: yet, you insist on doing it wrong Nov 16 13:49:29 Okay, clearly, Nov 16 13:50:31 clearly? system() does not do shell expansion Nov 16 13:50:40 there is nothing about that you can do Nov 16 13:50:43 no matter what you try Nov 16 13:50:47 it wont work Nov 16 13:51:19 if you want to do shell expansion, you have to either do it by hand or call a proper shell Nov 16 13:55:30 KotH:now I do not use the system(), but simply from command line:echo ADAFRUIT-UART1 > /sys/devices/bone_capemgr.*/slots Nov 16 13:56:24 so, that should work Nov 16 13:56:58 KotH:Now I try with another mode, to load ttyO1, becouse the my first mode not work Nov 16 13:57:17 what do you mean by mode? Nov 16 13:57:32 and what does it have to do with calamari fritti? Nov 16 13:58:18 mode..., I intend another solution Nov 16 13:58:31 * KotH sings to the tune of https://www.youtube.com/watch?v=n0aMtzGgxGM Nov 16 13:59:51 cpufreq_cpu0: failed to scale voltage down: -22 Nov 16 13:59:53 omap_i2c 44e0b000.i2c: controller timed out Nov 16 14:00:32 it is likely that my sim card corrupted? Nov 16 14:00:58 or the board? Nov 16 14:01:20 it's likely that something is wrong Nov 16 14:01:25 what, nobody knows Nov 16 14:01:40 connect a scope to the pins and check whether you get the right signal on those pins Nov 16 16:45:41 Anyone have experience building out-of-tree kernel modules? My kernel is cross-compiled, so /lib/modules/`uname -r`/build/scripts/* are all built for the wrong architecture(x86-64). How do I rebuild those scripts for arm? Nov 16 17:27:21 abferm: doesn't one normally build an out-of-tree module simply by using the main makefile of the linux kernel? (which would know how to pay attention to the fact you're cross-compiling) Nov 16 18:58:21 Hello, has anyone used the logic supply serial cape CBB-serial on rev. A beagle bone black? Nov 16 19:16:49 KotH: that address is i²c 0, it's not easily accessible to hook up scope probes Nov 16 19:18:25 so ka... Nov 16 19:18:26 well... Nov 16 19:18:35 pmic failing to respond probably means some driver issue since it's an ancient kernel Nov 16 19:18:38 also, i2c sucks\ Nov 16 19:18:46 depends Nov 16 19:18:46 (and omap_i2c doubly so) Nov 16 19:18:51 you're right Nov 16 19:19:16 i2c is nice, there is one single STANDARD, ORDER, DECORUM... unlike SPI where there is a multitude of standards... all slightly incompatible Nov 16 19:19:18 I mean, nearly every i2c controller peripheral I've encountered in a microcontroller or SoC sucks Nov 16 19:19:56 TI's is buggy as shit; ST's is buggy as shit; broadcom's is buggy as shit Nov 16 19:20:25 fucking up i2c controllers seems to be a popular hobby among μC/SoC designers Nov 16 19:22:21 SPI has lots of variants, but in practice it's trivial for a controller to support all of them and it's much harder to mess up; it's straightforward synchronous serial and the different variants can happily share a bus since they have chip selects anyhow Nov 16 19:22:45 I2C is inherently asynchronous, and apparently tooling for that still sucks Nov 16 19:23:30 also, I2C has nasty situations where desynchronization or any misbehaving bus device can take down the entire bus Nov 16 19:25:19 and having one standard is of limited use when it's rare to find it properly implemented Nov 16 20:04:57 <[Butch]> zmatt: I’m not really clear on this. Can you please tell us exactly how you feel about I2C? Nov 16 20:05:49 <[Butch]> zmatt: :-) Nov 16 20:44:34 I2C is the bestest Nov 16 20:44:44 pull ups always make things better Nov 16 21:21:35 [Butch]: it's quite nice really Nov 16 21:21:36 ;) Nov 16 21:23:37 [Butch]: though I'd avoid multimaster I2C unless using HS mode, since non-HS-mode has subtly broken arbitration Nov 16 21:25:28 and also avoid multimaster I2C in HS mode since your controller is probably too buggy to support it reliably anyway (except those from NXP I would hope, but haven't used any NXP μC recently) Nov 16 21:26:00 I'm having an odd issue where sometimes the BBB will fail to reboot. I think it might have something to do with USB (a peripheral disappeared just prior to this happening). I noticed there is no broadcast message about the reboot when the reboot fails: http://pastebin.com/0B3nciU9 Nov 16 21:26:43 [Butch]: on the bright side, usb sucks even worse Nov 16 21:29:40 rcn-ee: btw, got a new version of my pinmux dumper -> http://gerbil.xs4all.nl/show-pins-v2.pl.gz Nov 16 21:30:45 now also shows what the in-kernel use is of the pins, and prettier output Nov 16 21:35:21 zmatt, I like it! do you have it in a repo i can add? Nov 16 21:39:04 no, but feel free to add it to one Nov 16 21:41:18 zmatt, added: https://github.com/RobertCNelson/boot-scripts/commit/4b0e474c840c114492588724a0c6673c25263b89 so everyone will get it ;) Nov 16 21:42:45 I have absolutely no idea whether it might have dependencies on some particular kernel version though, I don't test on anything older than 4.1 Nov 16 21:43:06 it also used to require a recent perl, though I think I fixed that (but didn't test that either) Nov 16 21:43:10 and v4.1.x+ is all i care about. .;) everything else gets ignored.. Nov 16 21:43:19 \o/ Nov 16 21:43:34 rcn-ee: I think the latest official release image still uses 3.8 ? Nov 16 21:43:58 on a state-of-the-art wheezy system -.- Nov 16 21:44:15 yeah, the 'offical' wheezy image will remain 3.8.. (dtc issues) when the x15 comes out, jessie (4.1.x) for both bones/x15 will be "offical".. Nov 16 21:46:58 why on earth isn't it yet? it sucks to have to regularly explain to newbies that the "latest" image they downloaded is nevertheless ancient crap Nov 16 21:48:21 (it also doesn't help that http://beagleboard.org/latest-images links to a truly ancient image) Nov 16 21:48:40 yuck that should have been updated last week... where's jason... Nov 16 21:49:46 it should have been updated nearly 4 months ago after the 2015-07-28 release :P Nov 16 21:50:24 but it still points to 2015-03-01 Nov 16 21:50:59 I want it to point to : http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-11-03 which has windows 10 drivers.. Nov 16 21:51:24 <[Butch]> Oh, silly question, have the USB gadet drivers been fixed for Mac El Capitan yet? Nov 16 21:51:35 one of the "bbb-clone" boards has a different lcd framer chip, so they are stuck on v4.1.x+ Nov 16 21:53:02 [Butch], based on: https://github.com/jwise/HoRNDIS/issues/42 jwise is in contact with Apple's USB team... Nov 16 21:53:12 aka Apple regressed something big... Nov 16 21:53:45 <[Butch]> rcn-ee: thanks Nov 16 21:54:15 I still find the BBG a can of disappointment... they could have taken the opportunity to fix known hw bugs, none have been. they did however replace the main crystal with a spread-spectrum clock generator, even though that clock primarily feeds into PLLs -.- (which, moreover, themselves support spread-spectrum clock generation if desired) Nov 16 21:56:01 zmatt, the pre-production bbg was better.. it has a cp210x coin cell holder... Nov 16 21:56:10 but they axked it.. Nov 16 21:56:19 for an rtc? Nov 16 21:56:22 yeap Nov 16 21:57:00 yeah cr21xx, cp210x is silabs.. :) Nov 16 21:58:14 we're just gonna hook it up to the li-ion we have anyway to give the BBB some shutdown time when the power is cut Nov 16 21:58:29 (and to make the pmic less buggy) Nov 16 22:12:06 I'm think of setting the flag CONFIG_WATCHDOG_NOWAYOUT and recompiling in order to prevent my reboot hang issue. Is there any way to patch this on a system I don't have physical access to? Nov 16 22:13:02 recompile, upload, install, reboot, pray Nov 16 22:13:31 doh, i usually ahve that set, except for the ti kernel.. i'll add it.. ;) Nov 16 22:13:31 ugh...i DREAD the "pray" step... Nov 16 22:15:30 thisisbrians: a recognized alternative to prayer is sacrificing a young goat Nov 16 22:21:36 rcn-ee: great, thanks! Nov 16 22:23:14 zmatt: touché. if i test it out first on a device i do have physical access to...it should work in the field then? Nov 16 22:23:32 in theory. Nov 16 22:25:28 wunderbar! Nov 16 22:28:09 in practice, murphy's law applies Nov 16 22:28:25 Seen it burn a number of people, myself included Nov 16 22:29:31 MathOnNapkins: of course. sadly, my limited days of engineering have taught me that there is no such thing as 100%. Nov 16 22:29:40 Also, Beaglebone Green being a green circuitboard... it's like 'black is the new black' Nov 16 22:30:05 or rather, green is the new green for circuitboards Nov 16 22:31:23 I'm so used to seeing green circuitboards that when I see pictures of the BBG it doesn't really register as something different or unique. Maybe if it were a different shade of green, it would. Nov 16 22:34:38 So assuming I have CONFIG_WATCHDOG_NOWAYOUT set and succeed in opening /dev/watchdog, can anyone imagine any way in which the BBB could manage to NOT reboot if I issue an /sbin/shutdown -r now? Nov 16 22:34:39 there seems to be some proportionality though... if a remote device fails, it will be due to something silly that's trivially fixable, except for the part where you don't have access Nov 16 22:35:19 on the other hand, last time I had an upgrade fail, to compensate for the full local access I had the gods decided it was funny to clobber libc for me Nov 16 22:35:37 zmatt: naturally Nov 16 22:38:38 (or rather, due to running out of kernel memory to allocate dma descriptors it started randomly dropping writes for a while before it finally failed altogether, and thus during an update of things like libc, systemd, and other rather essential packages) Nov 16 22:38:47 *and this Nov 16 22:40:43 thisisbrians: and yes, there are always ways Nov 16 22:41:38 MathOnNapkins, the first beagle's where red.. then they went white, then black.. (hence a green now..) Nov 16 22:42:02 and there was almost a 'blue'... Nov 16 22:42:42 zmatt: geez. so my focus lately is just trying to create a reliable embedded linux solution, where manual intervention is almost always expensive and should be avoided at all costs. is there anything i can read on this? Nov 16 22:42:43 blue would have been better... I agree with MathOnNapkins that green isn't really an advertisable PCB color Nov 16 22:43:14 thisisbrians: no idea Nov 16 22:43:22 i've got to imagine there are people who do this for large companies that make modems or router or rokus or the like who have lots of tricks... Nov 16 22:44:07 thisisbrians: is your device subject to random power failures? Nov 16 22:44:38 zmatt: it's usually not behind a UPS, so as much as anything else plugged into a wall. Nov 16 22:45:09 no but, there's still a difference between devices that *might* have a power failure, versus devices that are casually unplugged by users all the time Nov 16 22:45:43 agreed. we didn't go as far as setting up an RO filesystem or anything. Nov 16 22:45:49 but we've thought about it... Nov 16 22:46:45 if you never need to write eMMC that would (probably) work yes, although it's a rather severe restriction Nov 16 22:47:45 we're currently going with a small LiPo, but that has its own headaches Nov 16 22:48:25 Yeah... that can be a real pain. Nov 16 22:49:42 well it helps that the pmic is designed for them, it helps less that the BBB needs a hw patch for it Nov 16 22:50:16 Oh that kind of bites. Nov 16 22:50:29 Our plan was to mount the eMMC readonly, and store everything on the sd card. Nov 16 22:50:48 These days back up power is much more common on industrial systems. Nov 16 22:51:57 Does having a battery help you keep the time any better between reboots? (We're using fake-hwclock) Nov 16 23:01:12 oi, stupid freenode Nov 16 23:01:57 what was the last line from me that still came through? Nov 16 23:16:16 zmatt: "well it helps that the pmic is designed for them, it helps less that the BBB needs a hw patch for it" Nov 17 01:30:41 I wonder if I can set up a BBB as an SVN server Nov 17 01:30:57 sure you can. Nov 17 01:33:33 same as any other box :p Nov 17 01:35:43 https://www.howtoforge.com/debian_subversion_websvn go for it Nov 17 01:38:03 Just seemed like an interesting idea (wanders off and looks) Nov 17 01:39:21 there might be better tutorials out there. 'apt-get install subversion' should be enough for a basic setup... **** ENDING LOGGING AT Tue Nov 17 02:59:58 2015