**** BEGIN LOGGING AT Thu Jan 07 02:59:59 2016 Jan 07 06:50:36 hello~ Jan 07 06:50:47 anybody here? Jan 07 06:50:57 i just bought bbb Jan 07 06:51:11 and i wanna use opencv Jan 07 06:51:29 so how do i do if i wanna Jan 07 06:53:41 beginner: what have you tried so far? have you searched for howtos online? Jan 07 06:54:25 https://duckduckgo.com/?q=beaglebone+black+opencv Jan 07 06:55:05 i have no idea how it works, but one of those links might get you started Jan 07 06:58:26 * vagrantc tried Jan 07 06:58:48 everryone want solutions on a plate .. in an instant. Jan 07 06:58:54 sooo lazy ... Jan 07 06:59:15 * vagrantc suspects beginner had already disconnected before i responded Jan 07 06:59:37 yes I think so .. 240s = 4min no? Jan 07 07:44:50 it seems the moment I feared has finally arrived... Jan 07 07:45:05 I really need to take a closer look at what the fuck is going on with usb :/ Jan 07 07:46:24 my condolences, was nice knowing you Jan 07 07:46:59 thanks Jan 07 07:51:43 this is what I got when I connected a mouse to my laptop via a USB protocol analyzer: http://gerbil.xs4all.nl/laptop-usb-mouse.png Jan 07 07:52:04 same thing but connected to a BBB instead: http://gerbil.xs4all.nl/bbb-usb-mouse.png Jan 07 08:50:20 zmatt: have fun!!! :D Jan 07 12:06:48 Hi good evening all !!! Jan 07 12:07:26 is there PRU gpio toggle application support with CCS for beaglebone ? Jan 07 12:08:02 any one can suggest how can i make c application on the same... Jan 07 12:11:17 I don't think many people here would use CCS. you'll probably find enough source example on the internet though, no idea if they will work with ccs. Jan 07 12:31:05 thanks @tbr Jan 07 12:31:42 no problem even normal c application also ok.. Jan 07 12:32:08 i need to make gpiotoggle using c application .. Jan 07 14:35:41 I'm trying to build kernel 3.8.13-bone71-lsm303 using the beyondlogic wiki page, which works for kernel 4.1. On the step to make bb.org_defconfig it fails. Other sites mention a different defconfig but when I look in arch/arm/configs I see nothing else that looks appropriate. Could someone toss me a clue? (grin) Jan 07 14:40:07 there isn't a "beagle" or "am335x" board config? Jan 07 14:40:47 * stt_michael takes a gander on git.kernel.org Jan 07 14:42:51 Further research indicates omap2plus_defconfig may work. Jan 07 14:45:41 yeah nothing in mainline Jan 07 14:45:42 Except it gets the same recursive dependency error. I suspect the issues in Kconfig, not the defconfig. Sorta new at this kernel build thing. Other than finding others with issues building this version, and newer versions working correctly, I see naught. Jan 07 14:46:18 https://github.com/beagleboard/linux is official Jan 07 14:46:31 and there's probably a TI one too... Jan 07 14:46:39 Right. Both my versions came from there. Jan 07 14:47:28 The Branch drop-down has the 3.8.13-bone71-lsm303 I'm failing on. Jan 07 14:47:38 http://wiki.beyondlogic.org/index.php?title=BeagleBoneBlack_Building_Kernel .. these instructions? Jan 07 14:47:43 Yup. Jan 07 14:48:45 I see config for the lsm kernel there.. so... what error do you get? Jan 07 14:49:27 drivers/video/Kconfig:60:error: recursive dependency detected! Jan 07 14:50:32 hmm bugger. Jan 07 14:50:43 Sadly I can't copy/paste from here. It gets to HOLDLD scripts/kconfig/conf, then this error. Jan 07 14:51:06 you've definitely done a 'make clean' before .. so there's no stray files? Jan 07 14:51:14 Just did as a matter of fack. Jan 07 14:51:16 t. Jan 07 14:51:22 :) ok cool Jan 07 14:51:35 brb. Hitting the coffee machine. Jan 07 14:51:37 well .. I'd defer to rcn-ee as he's good at kernels .. but he's AWOL .. Jan 07 14:51:51 unless he's sick :p Jan 07 14:53:53 Yeah. I was hoping tab-complete would turn him up, but alas. Jan 07 14:54:54 he's been in/out .. less in and more out Jan 07 14:55:01 !seen rcn-ee Jan 07 14:55:05 oh damnit .. no bot Jan 07 14:55:22 Dang. Jan 07 14:56:10 * rcn-ee has quit (Quit: Leaving) Jan 07 14:56:17 that was Weds Jan 07 14:56:20 at .. Jan 07 14:56:43 11pm mytime .. and its 3pm now .. so .. 8 hours hence yesterday Jan 07 14:57:07 That's not so long. Guy needs to sleep and all. Maybe he'll be back later. Jan 07 14:57:49 he will probably be around soon .. my logs say he was about about this time yesterday Jan 07 15:04:35 One site suggested this is a warning. It seems it may be - the next step is in process. Go figure. Jan 07 15:09:16 heh Jan 07 15:27:07 Almost. INSTALL_MOD_PATH has no target. Jan 07 15:30:19 Ah. PEBCAK. Jan 07 15:30:32 \o/ Jan 07 15:47:09 I have a question about kernel, systemd and graphics. I'm using the eMMC flasher script that Robert C Nelson and Charles Steinkuehler has developed, and I'd like to display an image on the screen during the eMMC flashing. I've had this working before, but for some reason letting the script take over the boot process renders the screen dark. Is there something that systemd does that enables the hdmi/display during start-up? Shouldn't this be completely Jan 07 15:47:09 handled by the kernel? Jan 07 16:00:39 eliasbakken: is the screen off / no signal, or merely black? Jan 07 16:01:03 try writing some data to /dev/fb0 Jan 07 16:04:45 the screen will be black by default if there's no console (e.g. getty) nor graphics application (e.g. X11) running, it may be off due to automatic screen blanking / powersaving (or due to hdmi being disabled in kernel or device tree of course, but I'm assuming you're using a set that has hdmi enabled) Jan 07 16:06:21 if the screen is merely black you can simply freely scribble onto /dev/fb0 to make it appear, if screen blanking or powersaving has been activated then it somehow needs to be poked alive Jan 07 16:06:59 still not sure how to do that, I've tried passing consoleblank=0 as kernel parameter but it either seems to be ignored or overridden by something Jan 07 16:07:50 zmatt: Yeah, i'm passing consoleblank=0 as kernel param, let me try without... Jan 07 16:08:18 consoleblank=0 actually means "do not blank the screen" Jan 07 16:08:21 so that's what you want Jan 07 16:08:25 if it worked Jan 07 16:10:08 Is it not "do not go to sleep mode"? Jan 07 16:10:54 it's how long to wait before blanking the console when idle, with 0 meaning automatic blanking is disabled Jan 07 16:11:00 that's at least what it's supposed to do Jan 07 16:12:25 running a qt application on the framebuffer (using QT_QPA_PLATFORM=linuxfb) does however manage to disable blanking, so there's probably some ioctl on the framebuffer device for it Jan 07 16:13:28 I'm starting an application on the frame buffer, similar to Qt (Clutter) Jan 07 16:14:34 I'm starting an application on the frame buffer, similar to Qt (Clutter) "console=tty0 console=ttyO0,115200n8" Jan 07 16:15:10 I'm seeing some strange stuff on the kernel command line. "console=tty0 console=ttyO0,115200n8" Jan 07 16:15:41 the first one got is bogus and probably got there by accident, the second one configures a serial console Jan 07 16:15:55 that's typical, otherwise you get all boot messages and crap like that via hdmi Jan 07 16:16:14 Ah, ok. Jan 07 16:16:52 I'll try to revert what I did with the u-boot config, that probably screwed that up. Jan 07 16:17:21 on a no-X11 config, if I disable all autovts in logind.conf I just get a black screen Jan 07 16:17:31 but one that's responsive to writes to the framebuffer Jan 07 16:18:54 I actually wanted to change the console to ttyS0, to see if I could get kernel messages on the HDMI during the flashing process... Jan 07 16:19:21 then you should use tty1 Jan 07 16:20:02 blanking seems to be controllable via the FBIOBLANK ioctl() on the framebuffer device Jan 07 16:22:19 ioctl( fd, FBIOBLANK, FB_BLANK_UNBLANK ); or something like that Jan 07 16:23:29 rcn-ee: plugging a mouse into laptop vs bbb via usb analyzer hardware: Jan 07 16:23:31 http://gerbil.xs4all.nl/laptop-usb-mouse.png Jan 07 16:23:36 http://gerbil.xs4all.nl/bbb-usb-mouse.png Jan 07 16:24:55 only a few sync errors. ;) Jan 07 16:25:25 the red lines with "I" in error column are wrong pid (DATA0 vs DATA1) Jan 07 16:25:39 :P Jan 07 16:27:48 I also disabled grouping the transactions into logical transfers like I did on my laptop since on the BBB the analyzer had trouble with that and caused it to reorder entries out of chronological order Jan 07 16:28:01 (there are still a few entries out of order, not sure why) Jan 07 16:28:30 no idea what sync error means Jan 07 16:28:55 endian? Jan 07 16:30:01 ?? Jan 07 16:30:47 wait, a mouse is a low-speed device, so the bus turnaround erratum applies to that and may be confusing the heck out of the analyzer Jan 07 16:31:21 I need a full-speed-but-not-high-speed device to test... hmz.. Jan 07 16:32:06 (there's a debugfs thing to force to post to full-speed instead of high-speed but it seems to do absolutely nothing, and the analyzer can't handle high-speed) Jan 07 16:32:16 *to force the port Jan 07 16:47:01 rcn-ee: has there been any mainline work on musb as far as you know? Jan 07 16:47:46 or has everyone fled the scene in horror? :P Jan 07 16:47:47 zmatt, no, it's been pretty quiet, the only thing that's changed is the dma backend for musb (allowing multilple versions to be built vs just one..) Jan 07 16:48:11 zmatt, and the sunxi guys are using musb now too.. Jan 07 16:48:11 ;) Jan 07 16:48:56 I have some cam that really totally borks up on the bbb (with or without hub) Jan 07 16:49:36 including free kernel oopses if you disconnect it to kill the hanging uvccapture Jan 07 16:50:27 rcn-ee: I'm wanting to build BeagleLogic in a new kernel, say 4.1.13. I see a lot of symbol overlap between pru_rproc in 3.8.x and pruss_remoteproc in 4.1.x, but so far no function / struct overlap. Does it seem reasonable to extract common symbols and have a whack at building? Jan 07 16:51:56 but there's also an odd thing, usb seems to enable auto-suspend by default on the bbb, it doesn't do that on my laptop and I recall reading somewhere that linux disables autosuspend by default because too many usb devices bork up on it (it definitely makes the cam behaviour worse) Jan 07 16:52:30 Poo. Function collision. There it is. If it was easy.... Jan 07 16:53:26 wb Jan 07 16:54:04 Ragnorok, 3.8 -> 4.1.x is already a big move, save the "uio_pruss" -> remoteproc_pruss for 4.4.x now (or when it gets to mainline).. Jan 07 16:54:54 rcn-ee: Kinda on short time. Seems like I should just use 3.8.x and move up later, then? Jan 07 16:55:44 Ragnorok, 4.1.x-bone with uio_pruss should be a pretty close drop-in replacment for 3.8.x-uio_pruss.. ;) Jan 07 16:56:05 I did't see a -bone in the repo. Jan 07 16:56:26 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.1 Jan 07 16:56:36 Ah. Donkies! Jan 07 16:58:12 Ragnorok, Elias Bakken's did the uio_pruss work on 4.1.x, he sells printer capes, and had uses uio_pruss on 3.8/3.12.. so uio-pruss on 4.1.x-bone is in pretty good shape.. Jan 07 16:59:47 Ragnorok, btw there's also a "rt" variant of 4.1.x-bone, might help with BeagleLogic even more. ;) Jan 07 17:00:22 I see that. Thanks! Jan 07 17:06:36 rcn-ee: rt has its disadvantages though, I could completely freeze up the GUI by ping-flooding by bbb (which only caused occasional hiccups on the non-rt kernel) Jan 07 17:07:13 otoh rt does give you more tools to deal with such things... demoting the kernel threads involved with networking to SCHED_OTHER fixed the problem entirely Jan 07 17:07:52 hm, at least I think that's an rt thing, or can I do that on a regular kernel also? Jan 07 17:08:23 no wait that's definitely rt Jan 07 17:08:34 since those kernel threads were actually the irq handlers Jan 07 17:08:36 zmatt, yeah, i prefer PREEMPT_NONE ;) Jan 07 17:08:45 rcn-ee: It looks like I can use LINUX_GIT to say pt to my existing 4.1 source and have at? Jan 07 17:08:53 rcn-ee: for a build farm, sure Jan 07 17:09:04 but bb.org wanted PREEMPT in base and then the full RT.. Jan 07 17:09:11 zmatt, exactly... ;) Jan 07 17:09:31 Ragnorok, as long as it has kernel.org tag's.. Jan 07 17:10:29 rcn-ee: did I ever mention I got a bbb image to boot inside a systemd-nspawn? slightly patched qemu-user and bind-mounted some critical executables that qemu-user can't handle (such as systemd) worked Jan 07 17:11:14 if I can get a cross-compiler in that environment (acting as though it is the "native" compiler) then it would be a pretty spiffy environment to build stuff that can't normally be easily cross-compiled Jan 07 17:11:41 any ledscape users about? Jan 07 17:11:46 the uname -a looks really odd though, involving both "amd64" and "armv7l" Jan 07 17:12:05 that may confuse most auto-build tools. ;) Jan 07 17:12:57 nah, the amd64 only occurred in the uname -r I think Jan 07 17:13:11 nobody parses the suffixes of that I'd hope Jan 07 17:14:02 for a couple days i was looking at apple's swift (for the bbb), that parses a lot of random crap.. Jan 07 17:14:09 point is that it could just compile and run tests just like it would do normally Jan 07 17:14:29 if necessary I think you can override all uname things in a container anyway? Jan 07 17:16:10 ideally you'd use native versions of most executables but armhf versions of all "dev" stuff (includes, libs) so you get near-native performance apart from executables built and run during the build process Jan 07 17:17:26 has anyone built a Yocto image that works with the 4dcape43T LCD panel ? Jan 07 17:18:18 ew yocto lol Jan 07 17:18:52 This is a question for my curiousity only - Why do all the manual kernel build instructions use gnueabi, but this script is using gnueabihf? I would expect the latter, actually. Jan 07 17:22:26 stt_michael, "ew yocto lol"? can you elaborate... Jan 07 17:22:27 kernel is going to override that anyway, but fpu/neon in unavailable in the kernel except under special circumstances Jan 07 17:23:08 gt653, yocto is considered quite 'old' and unsupported Jan 07 17:23:09 the fpu/neon registers are saved/restored lazily Jan 07 17:23:24 Roit. I figured something like that. Jan 07 17:23:25 gt653, the 4D capes are supported in the default debian images afaik ... Jan 07 17:23:36 isn't that correct rcn-ee ? Jan 07 17:23:44 stt_michael: you sure about that? Jan 07 17:23:55 zmatt, I thought so .. Jan 07 17:24:02 stt_michael, is it? are you sure? I just started with it so I don't know, but it seems pretty mainstream and up to date Jan 07 17:24:36 * stt_michael awaits the wisdom of RN .. Jan 07 17:25:01 stt_michael: you're not confusing yocto with ångström ? Jan 07 17:25:11 I thought I read somewhere (here) that the DT files were all there and stuff Jan 07 17:25:24 stt_michael, yes it works fine on debian, using the default BBB image; but I am asking specifically about doing this with Yocto Jan 07 17:25:42 zmatt, there is no such "yocto" image for BBB that I'm aware of .. and ok I'm conflating the angstrom with yocto, as one is derived from the other Jan 07 17:26:28 gt653, I suspect you're on-your-own to port the relevant bits of code into a yocto build. Jan 07 17:26:34 gt653, there's no offical "yocto" for bb.org anymore.. but your free to grab https://github.com/beagleboard/linux/tree/4.1 and teach yocto to use it.. (other have) Jan 07 17:26:55 https://www.yoctoproject.org/downloads/bsps/jethro20/beaglebone Jan 07 17:27:13 released two months ago Jan 07 17:27:29 zmatt, I'm impressed. Jan 07 17:27:44 zmatt, ah ti set that up.. Jan 07 17:28:05 it's based on ti's 4.1.x, so no "3dcape43t" support.. Jan 07 17:28:25 * zmatt has no idea what 3dcape43t is Jan 07 17:28:50 ah, 4d Jan 07 17:28:53 it's just an lcd cape.. clone of circuitco's 4inch. Jan 07 17:29:26 why unsupported on 4.1-ti ? my impression was that lcdc driver worked *better* there than in mainline Jan 07 17:29:48 I suspect the problem is with the dts I have for the 4dcape43t on the kernel, but not sure what or if that is the problem. Jan 07 17:30:17 "out of the box" working support... gt653 will have to o patch that yocoto kernel.. Jan 07 17:30:20 the ...tree/4.1 kernel tree for beaglebone does not have a dts for it Jan 07 17:30:38 I believe someone the cape manager extracts that info form the EEPROM on the cape itself Jan 07 17:30:52 gt653, that's how its Supposed to work :D Jan 07 17:30:57 oh just the dts, that's not really an obstacle Jan 07 17:31:16 gt653, we extract the name and load the appropate dtbo: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD4-01-00A1.dts Jan 07 17:31:16 (with or without capemgr, I never use it) Jan 07 17:31:39 * stt_michael has no capemgr on his main beaglebone .. Jan 07 17:32:07 just the 'toy' one for testing Jan 07 17:32:10 setting up the dts for the lcd display we're using was relatively easy Jan 07 17:32:29 we got a 4d cape here .. its pretty good Jan 07 17:32:37 touch too iirc Jan 07 17:33:19 a bit inane the driver has _mandatory_ DT properties which are actually only relevant for passive-matrix displays, especially since it doesn't even support passive-matrix mode Jan 07 17:33:43 zmatt, the lcdc or the cape ? Jan 07 17:33:47 so did you put that dts together from scratch? how did you build that? Right now I have one I modified from a 4dcape70t, which is the big brother to the 4dcape43t Jan 07 17:33:49 lcdc_panel Jan 07 17:33:53 tilcdc_panel Jan 07 17:35:15 gt653: yeah I bake my own DT entirely since I disliked too many things about the main DT, but I'm nuts Jan 07 17:36:08 I build it using a Makefile Jan 07 17:36:10 cpp -nostdinc -undef -D__DTS__ -I . -I include -x assembler-with-cpp -MMD -MQ dd-test.dtb -MP -MF .dep/dd-test.dtb.d dd-test.dts -pipe | dtc -@ -H epapr -i include -I dts -O dtb -o dd-test.dtb Jan 07 17:36:30 zmatt, yeah I d say, that thing looks cryptic in parts. I now understand the structure and syntax, but even then that is some job to do it from scratch Jan 07 17:36:49 gt653: DT really ought to be generated from a better format Jan 07 17:37:27 it's really tiresome in its limited expressiveness, redundancy, mandatory boilerplate, etc Jan 07 17:37:50 at least having preprocessor macros helps slightly Jan 07 17:39:01 a bigger problem is that it's a tree Jan 07 17:39:24 I've also been mailing with tony lindgren to help him with his efforts in accurately representing the interconnect Jan 07 17:39:46 problem is that it's not a tree but a directed graph (and not even necessarily an acyclic one) Jan 07 17:39:51 in reality Jan 07 17:41:01 for example even the ADC attaches in two places: it's on the L4WK but also has a port directly on the L3 to allow efficient data access (especially for dma) Jan 07 17:42:25 the tree structure worked fine for physical busses, but for on-chip interconnects it's probably going to be increasingly problematic Jan 07 17:43:26 but, well, we have to make do with it for the time being :) Jan 07 17:45:03 although it means the kernel driver for the adc uses the L4WK for data access instead of the L3 port Jan 07 18:11:12 zmatt: Thanks for your help, I've got to continue this tomorrow! Jan 07 22:15:12 Hello! Jan 07 22:16:28 Hi Beaglebone community, can anyone help me with troubleshooting a faulty BBB? Jan 07 22:17:45 describe the issues you have Jan 07 22:23:28 So when I start the beaglebone, I only get a solid power LED, and User LED 2 lit up. no heart beat. Jan 07 22:23:53 booting from emmc or sd? Jan 07 22:24:00 I tried flashing the EMMC, but the same lights tay solidly lit. Is there a workaround, or what does this combination of lit led's mean? Jan 07 22:24:15 boot from both emmc or sd doesn't start a heartbeat Jan 07 22:24:37 do you have access to the debug UART port? Jan 07 22:26:02 I have access to the port, what should i do? Jan 07 22:26:10 sorry, i disconnected Jan 07 22:26:47 open it in a terminal emulator, boot the board, see the output Jan 07 22:27:14 I haven't thought of that, do i need a special cable? Jan 07 23:12:15 hi guys I needed to find out how I can flash an image onto my beaglebone black through serial. I can see that the bootloader is waiting but I do not know of how to load an image onto the emmc through serial Jan 07 23:12:41 through serial? that's a pretty obscure route Jan 07 23:13:25 you definitely don't want to flash eMMC via serial.... bootloader *maybe* (though even then there are many simpler ways), but eMMC was take ages Jan 07 23:13:28 *would take Jan 07 23:14:30 i am unable to use a microsd card. the board doesnt read them I was getting error 101's i believe Jan 07 23:14:36 I generally flash eMMC via usb Jan 07 23:14:37 it has been a while since i touched the board Jan 07 23:14:56 how would I be able to do that? my board isnt detected through usb Jan 07 23:16:24 http://pastebin.com/x5QzB18E Jan 07 23:16:42 assuming linux host Jan 07 23:16:47 what OS are you using? Jan 07 23:16:59 or wait Jan 07 23:17:33 when you say "I can see that the bootloader is waiting", what do you mean exactly? Jan 07 23:18:09 with my serial cable connected and the board powered on. I just see C's repeating Jan 07 23:18:17 ah ok, ROM bootloader Jan 07 23:19:13 I did a number on this board trying to figure out why i couldnt read from microsd cards. Jan 07 23:19:26 if you connect via usb to your computer, does the CCC stop ? Jan 07 23:19:34 how would I correct the bootloader or am i still able to follow the above procedure Jan 07 23:19:56 the thing I pasted does not use the μSD slot in any way Jan 07 23:20:39 yes it does Jan 07 23:20:40 flash from USB Jan 07 23:20:43 I'm currently in a train and will lose internet shortly, but will be back later (about an hour)... Jan 07 23:20:54 ok, then you can flash via USB, assuming you have a linux host Jan 07 23:21:02 yes i do Jan 07 23:21:03 no trench coats required either Jan 07 23:21:30 the pastebin I linked to explains how to make the eMMC appear as an usb mass storage device Jan 07 23:22:07 you can then directly flash a filesystem image (I suggest the latest jessie snapshot) Jan 07 23:22:17 be sure to download the "standalone" rather than the "flasher" Jan 07 23:23:40 and I think you can just xzcat blah.img.xz >/dev/sdb or whatever device name the BBB got when it appeared as mass storage (double-check carefully :P ) Jan 07 23:23:48 afk Jan 07 23:23:54 zmatt: thanks for the help will try to get it done now Jan 08 00:08:42 zmatt: not sure what I did wrong. I am able to get it to boot to something but I think I either used the wrong image or something as it eventually hangs during boot Jan 08 00:10:38 http://pastebin.com/LUyBqyzp Jan 08 00:10:44 that is what i get now Jan 08 00:13:37 Hi guys, i have a problem with my beagleboneblack, and i have it connected to an ftdi, can anyone help with interpreting errors read on the printout? Jan 08 00:15:58 ftdi_problem: tip: just showing your actual problem (i.e. giving a link to pastebin or similar containing the errors) generally has better chance of getting help than asking "can anyone help" Jan 08 00:16:52 Here's the output i get from ftdi: Jan 08 00:16:54 ffe6 e1fc f8c4 05c0 (6803) f44f Jan 08 00:17:01 U-Boot SPL 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29) reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img U-Boot 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29) I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment Net: not set. Validating first E-fuse MAC Could not get Jan 08 00:17:06 do NOT Jan 08 00:17:10 paste text here Jan 08 00:17:18 Oh sorry, let me pastebin it Jan 08 00:18:00 Here's the link: Jan 08 00:18:01 http://pastebin.com/MHPbdCsk Jan 08 00:18:16 (and unless you feel your existence is defined by getting an error message via an ftdi serial cable, maybe consider a different nickname ;-) Jan 08 00:19:13 Haha duely noted Jan 08 00:19:55 hm, a crash in cpsw_probe, unusual Jan 08 00:20:43 my first thought would be a mismatch between dtb and kernel Jan 08 00:21:10 is there a way to stop the debian images from trying to connect to ethernet on boot Jan 08 00:21:55 If it helps, the Led's taht power on are only the power LED and USR2, no heartbeat present Jan 08 00:22:03 mistawright: assuming you're still using ifupdown, remove the "auto eth0" from /etc/network/interfaces Jan 08 00:23:52 ftdi_problem: I do see u-boot also has trouble with the ethernet subsystem ("Could not get PHY for cpsw: addr 0") Jan 08 00:24:13 it's also quite odd it is loading uEnv from both μSD _and_ eMMC Jan 08 00:24:26 you have a card inserted apparently? Jan 08 00:25:01 I do have a card inserted, it had the emmc flash image on it, should i try booting without it inside and see the FTDI output? Jan 08 00:25:04 it looks like you're booting a "mixed system" .. parts coming from μSD card and parts from eMMC Jan 08 00:25:31 current images prevent that by using filesystem uuid, but your system is quite old and doesn't have that protection yet Jan 08 00:26:00 zmatt: what device is this? dev-ttyGS0.device i notice my boot is slowed down because of it Jan 08 00:26:30 mistawright: I have no idea, I've seen it too and I have no clue Jan 08 00:26:38 I'd say systemctl disable it Jan 08 00:26:42 (I did) Jan 08 00:27:31 zmatt: cool. i was able to get one of my beaglebones going that i thought i had to replace so im somewhat happy. the other though that i asked for help with initially i think i missed something somewhere on that Jan 08 00:28:06 mistawright: still odd μSD doesn't work... I'm not sure how you'd break that Jan 08 00:28:43 Should i try a different emmc file? Jan 08 00:29:30 ftdi_problem: unless it's very inconvenient, I would recommend flashing a recent jessie snapshot Jan 08 00:30:04 OK, is it possible to flash the beaglebone through the FTDI or do I have to do it through a microsd? Jan 08 00:30:40 then you have a newer (or well, less ancient) debian system *and* a new bootloader that helps to guard against the mixed-boot issue Jan 08 00:32:11 what do you think would cause the mixed-boot issue? and is that why the booting just freezes? Jan 08 00:32:31 μSD is easiest usually, flashing via USB from another linux system is also possible Jan 08 00:33:07 mixed-boot is caused by a combination of three factors: Jan 08 00:34:00 1. boot system is eMMC, but a μSD card is also present from boot Jan 08 00:35:39 2. the root device is set to /dev/mmcblk0p1 (or p2 on really old systems) since the asswipes maintaining the linux mmc subsystem refuse to accept patches that fix the mmc device numbering to match the numbering used by hardware Jan 08 00:36:11 (μSD card is then detected by the kernel before eMMC, hence becomes mmcblk0) Jan 08 00:37:13 actually I somehow already managed to embed my point 3 into point 2, never mind :P Jan 08 00:37:13 Ok i downloaded BBB-eMMC-flasher-debian-8.2-lxqt-4gb-armhf-2016-01-03-4gb.img.xz onto my computer, i'll just flash it onto the sd card and see if it will boot :) Jan 08 00:37:20 I recommend the 2gb btw Jan 08 00:37:24 less crap, more free space Jan 08 00:37:39 (less time to flash also) Jan 08 00:42:48 OK i'm writing the file to the SD card as we squeak, thanks for the help zmatt!! Jan 08 00:53:54 IT WORKS!!!! thank you so much zmatt!!!! Jan 08 00:54:28 \o\ Jan 08 00:54:29 So now I just wait for 30-45 minutes, then I can put a version of debian onto the SD card and it should work fine? Jan 08 00:54:31 /o/ Jan 08 00:57:04 I have no idea what exactly the rules of the current bootloader are, but if your /boot/uEnv.txt contains an uuid= line (I think the flasher arranges that but I've never used one so I'm not sure) then at least you will get a matching version of uboot settings + kernel/initrd/dtb + rootfs Jan 08 00:57:17 but if you intend to boot from μSD, why are you flashing a system to eMMC ? Jan 08 00:58:59 Oh if i understand correctly, what i'm doing now is basically installing an OS onto the EMMC that doesn't require the SD card to be present? Jan 08 01:00:21 Sorry if i sound incompentent, I'm very new to embedded systems :/ Jan 08 01:01:30 yes if you flash to eMMC there's no reason for a μSD card to be present Jan 08 01:02:14 it's not really different from a desktop system, just think of eMMC as "hard disk" and μSD as "usb stick / installler cd" or whatever Jan 08 01:04:03 and instead of a bios setup screen where you can configure the boot device order there's just the annoyingly tiny button labeled "S2" Jan 08 01:05:15 although that just determines how the rom bootloader ("BIOS") finds u-boot ("grub") Jan 08 01:05:44 OK it shutdown and I rebooted it with the SD card still installed, so it re-flashed the EMMC :p i'll remove the SD card when it shuts down again Jan 08 01:05:57 after that it's all up to u-boot's script, which is mostly hardcoded although it can be overridden with uEnv files it looks for in various palced Jan 08 01:06:17 also keep in mind the S2 button is sampled only at power-up Jan 08 01:06:21 not at reboot or reset Jan 08 01:06:25 power up. Jan 08 01:08:08 so if you powered up with the S2 button pressed to force booting from μSD (it takes eMMC out of the boot device order), you need to really power off and on again to boot your new system on eMMC Jan 08 01:14:15 IT WORKS! i'm able to ssh into the board, so we've got it figured out! Jan 08 01:14:26 THANKYOU ZMATT Jan 08 01:15:38 o/ Jan 08 01:15:42 time for tea. Jan 08 02:11:49 zmatt: Hi not sure if you can help me further. the first board that you recommended i try to flash through usb was successful somewhat but i cant get it to boot all the way. http://pastebin.com/M5v4R9fe Jan 08 02:12:15 i believe it is the rootfs it is having trouble finding. i am reflashing with a jesse image to see if it works better Jan 08 02:50:46 lol, exactly the same problem as "ftdi_problem" had but in the opposite direction **** ENDING LOGGING AT Fri Jan 08 02:59:58 2016