**** BEGIN LOGGING AT Fri Jan 13 03:00:02 2017 Jan 13 03:01:56 debian kern.log at http://dpaste.com/0E31263 Jan 13 03:02:23 ehm Jan 13 03:02:39 i can't find any mention of mmcblk1 in it. Jan 13 03:03:15 I don't know what you pasted but here it just appears as a pile of garbage Jan 13 03:03:41 I had to gzip it. I need a different paste destination for larger files. Jan 13 03:03:54 ok, you might have mentioned that :P Jan 13 03:04:13 sorry Jan 13 03:06:11 it didn't survive, it's not decompressable Jan 13 03:06:17 paste.debian.org ? pastebin ? hastebin ? Jan 13 03:06:39 just a sec Jan 13 03:09:39 plain text kern.log at https://gist.github.com/318658a453d41611287b83d3343c1bd2 Jan 13 03:11:40 I see why it's so big, this isn't just from this boot but many many boots dating back to october Jan 13 03:12:57 though indeed mmc1 isn't mentioned Jan 13 03:13:54 It did appear on one OS. I tried fdisk but just got command timeouts from the kernel. Jan 13 03:14:18 so, couple of options Jan 13 03:14:30 it might have been dying (for whatever reason) and is now dead Jan 13 03:14:52 or it works sporadically/unreliably, e.g. due to a marginal connection Jan 13 03:15:35 the best case scenario would be a connection issue of some sort Jan 13 03:16:09 but dunno how much time you want to invest in trying to get it to work Jan 13 03:16:54 your confirmation lets me see that I'm not doing things totally wrong Jan 13 03:17:10 if you really want to try to figure out what's up with that thing (and no guarantee that you ever will) you need to know exactly what's going on back and forth Jan 13 03:17:38 i.e. enable low-level debug messages to log all attempts of communication with it Jan 13 03:17:52 I don't think it is worth fixing. I don't have a hot air desoldering tool and I'm not sure I can source the part to attempt a replacement. Jan 13 03:18:14 You mean low-level debug in debian logging or in uBoot? Jan 13 03:18:27 sourcing an eMMC (they're basically interchangable) isn't the issue, desoldering definitely is Jan 13 03:18:42 in the kernel yeah Jan 13 03:19:02 problem is that you're booted from another sd/mmc medium Jan 13 03:19:16 so if you enable debug messages in that driver, you risk getting spammed to death Jan 13 03:19:52 You've given me some ideas. And confirmation that I'm not totally doing something wrong. Jan 13 03:20:53 It's my first time with the BBB and has been difficult because it is broken. Would have been nice to know what normal was first. Jan 13 03:20:55 though you can minimize the risk by going into emergency mode Jan 13 03:21:14 well, you knew the previous owner had problems with it Jan 13 03:21:30 For the price of the desoldering tool I can buy another BBB or equivalent. Jan 13 03:21:45 are good desoldering tools that cheap? Jan 13 03:21:51 sounds unlikely Jan 13 03:22:22 You can get really cheap ones for around $70 but I don't know about the quality. Jan 13 03:22:32 Good ones run into the hundreds. Jan 13 03:22:54 I wouldn't suggest attempting it unless you have good tools and a lot of experience with them, and probably your experience would then tell you "no way" Jan 13 03:23:33 Yes, I've done some surface mount repairs before and the procedure for ball arrays looks very difficult to learn. Jan 13 03:24:16 I keep thinking if I could just get access to it and format it then maybe it would work. Jan 13 03:25:05 you can enable debug messages e.g. with echo 'file drivers/mmc/* +p' >/sys/kernel/debug/dynamic_debug/control Jan 13 03:25:15 be sure to kill logging first Jan 13 03:25:20 ok Jan 13 03:25:22 logging to file I mean Jan 13 03:25:39 since otherwise file write -> sd activity -> log messages -> file write -> ... Jan 13 03:25:55 and the echoes go on forever :) Jan 13 03:26:01 better yet, remount the root filesystem readonly Jan 13 03:26:39 I could log to the serial console. Maybe it could keep up. Jan 13 03:26:56 you can also reboot into initramfs, then the card won't even be mounted Jan 13 03:27:02 but the tools there are meh Jan 13 03:27:22 I could set something up to boot/run from NFS too. Jan 13 03:27:43 you can make the kernel reattempt to communicate by unbinding and rebinding the mmc host driver Jan 13 03:28:00 ahh, good idea Jan 13 03:28:30 it's refreshing to not have to explain things when I say something like that :D Jan 13 03:28:37 nfsroot works too yeah Jan 13 03:28:56 in fact if you're really enthausiastic you could netboot it entirely Jan 13 03:29:03 In looking at mmc-utils hwreset enable it says: NOTE! This is a one-time programmable (unreversible) change. Jan 13 03:29:16 eMMC has a lot of OTP settings Jan 13 03:29:20 isn't that fun Jan 13 03:29:53 oh, so it's in the eMMC device. Jan 13 03:29:55 note that the reset pin is connected and driven high (not-asserted) by default so no problem there Jan 13 03:30:15 That's why I checked the voltage, to make sure it was high. Jan 13 03:30:38 the reset input of eMMC is not enabled by default Jan 13 03:31:35 you can use mmc-utils to enable it permanently or disable it permanently Jan 13 03:32:11 mmc-utils is nowhere near complete btw Jan 13 03:32:15 last time I checked anyway Jan 13 03:32:25 I couldn't see any reason to mess with the default. I just wondered if the previous owner had mucked with it. Jan 13 03:33:11 Well I haven't pulled the datasheet on the Kingston chip in this unit yet to see what it is capable of. Maybe I should give it a read just for fun. Jan 13 03:33:28 since when does kingston have datasheets Jan 13 03:33:41 ouch Jan 13 03:33:44 They have spec sheets. Jan 13 03:33:50 you can download the official standard from jedec btw after free registration Jan 13 03:33:53 it's horrible Jan 13 03:33:59 a complete mess Jan 13 03:34:08 GenTooMan: older ones yeah Jan 13 03:34:21 I really burn when standards are locked up where I can't get at them. Jan 13 03:34:42 darfo: jedec is hassle-free in my experience Jan 13 03:35:17 JEDEC is different than IEEE (those are locked up) Jan 13 03:35:21 GenTooMan: this is the full public documentation on the latest eMMCs I've encountered in the BBB: http://media.kingston.com/pdfs/emmc/MKF_625_19nm_emmc_flyer.pdf Jan 13 03:35:49 GenTooMan: well, not all of it ( http://standards.ieee.org/about/get/ ) Jan 13 03:35:50 eMMc is a SD standard no? Jan 13 03:35:51 Oh, it thought you meant jedec was a complete mess Jan 13 03:36:11 GenTooMan: sd and emmc are both descendents of mmc Jan 13 03:36:14 GenTooMan: they're not compatible Jan 13 03:36:24 darfo: the eMMC standard is a mess Jan 13 03:36:44 That's no surprise MMC was a bit of a mess too. Jan 13 03:37:29 darfo: you could randomly shuffle the sections with little or no negative effect on readability Jan 13 03:38:04 :) Jan 13 03:38:41 zmatt is the BBB SDRAM memory interface 16bits? Jan 13 03:38:48 yes Jan 13 03:39:01 That explains some of the limitations it has. Jan 13 03:39:02 one x16 DDR3L chip Jan 13 03:39:17 (two x8 chips on the BBE) Jan 13 03:39:31 zmatt: thanks for the help. Gotta go feed my animals and then go to sleep. Jan 13 03:39:32 GenTooMan: it seems fine for most of it purposes Jan 13 03:39:43 darfo: good night and good luck Jan 13 03:39:51 GenTooMan: *its Jan 13 03:42:04 Well I was looking at the video output and was scratching my head then it dawned on me that having wider bandwidth likely makes a difference. Jan 13 03:44:26 it can become a problem if you run video output at its limits, though I think it may be more of a latency issue. using QoS features of the interconnect and/or EMIF might help Jan 13 03:45:05 the max bandwidth required by video output is not a large fraction of the max memory bandwidth Jan 13 03:45:53 Well I was trying to mix the video data with an FPGA so I could add overlay data selectively for instrumentation. Jan 13 03:46:24 what's your pixel clock rate? Jan 13 03:47:22 I'm not sure what you're saying there Jan 13 03:47:30 And that's when I started digging through the video system (I had no idea how to sync the two). Jan 13 03:47:48 eh, by using the video sync signals? Jan 13 03:48:07 That and the pixel clock output. Jan 13 03:48:13 obviously :) Jan 13 03:48:33 which reminds me, this is pretty neat btw -> https://www.adafruit.com/product/609 Jan 13 03:52:54 Oh yeah that guy had a great article on how to detect fake SD cards (the person who makes the device that is) he got a huge number of boards that were failing at the factory and discovery that the SD card provider had some fake memory chips in the cards. Jan 13 03:53:50 well, "fake" ... it was authentic memory, kingston apparently just should have been a bit pickier about sourcing chips :P Jan 13 03:54:16 the authentic kingston brand basically doesn't mean much Jan 13 03:54:34 Hence the reason "Kingston" doesn't have have data sheets ... :D Jan 13 03:55:10 of course that article was quite old, and about SD Jan 13 03:55:35 for eMMC they'll at least need some uniformity of controllers, since they spec a version of the standard Jan 13 03:56:22 with SD cards you can be much sloppier Jan 13 03:57:32 Unfortunately ... Jan 13 04:00:05 lol, "Traditional flash memories employ simple algebraic codes, such as BCH codes..." Jan 13 04:00:34 for reference, http://lxr.free-electrons.com/source/lib/bch.c Jan 13 04:01:17 before this I really wouldn't have expected to find a phrase like "Given a polynomial f and an integer k, compute Tr(a^kX) mod f" in the linux kernel Jan 13 04:03:02 Hi Jan 13 04:03:20 beaglevsrasp: they're very different. Jan 13 04:03:21 ;) Jan 13 04:04:58 betwwen rasberry pi3 and beagle bone for ROS , which is the best for you ?? Jan 13 04:05:56 I'm not familiar with ROS. the raspberry pies are media-oriented while the beaglebone targets industrial markets and has a lot of fancy I/O capabilities Jan 13 04:07:44 the rpi3 has more cpu power, but the beaglebone has e.g. the PRU cores for hard real-time response Jan 13 04:08:24 ok , beagle blone black rev c has the same gpu that beagleblone green wireless ?? Jan 13 04:08:26 the processor on the beaglebones is extensively documented, the rpi SoC has little docs Jan 13 04:09:43 and the beaglebone is an open hardware design with components you can buy on the open market (hence there are various derivative boards), while the rpi is closed and the SoC custom Jan 13 04:10:39 all beaglebones are built around the same SoC, the AM3358 Jan 13 04:10:55 I recommend against the beaglebone green wireless btw Jan 13 04:11:21 consider the beaglebone black wireless instead Jan 13 04:11:41 the green wireless pointlessly sacrificed a whole bunch of expansion header pins Jan 13 04:12:03 which limits your options for using the board Jan 13 04:13:37 the AM3358 isn't strong in video capability, and its gpu (PowerVR SGX530) isn't in the default distribution Jan 13 04:13:43 *isn't used Jan 13 04:14:24 it can be made to work though, but it's not supported with X11 Jan 13 04:15:07 is a very hard decision , i want to use kinect and open cv Jan 13 04:18:11 if that's the only factor important then the rpi3 is probably better suited for that, though I don't have experience with opencv or performing tasks like these on a beaglebone Jan 13 04:19:55 the cortex-a8's neon unit is not bad at all though, apparently for some workloads it can have 2-4x the performance of a cortex-a7 core (like the rpi2) at the same clock frequency Jan 13 04:20:01 but it's not a speed monster Jan 13 04:20:54 as I said, the BBB is stronger in peripherals, real-time stuff, and openness Jan 13 04:21:18 (with peripherals I mean on-chip peripherals like PWM and such) Jan 13 06:36:59 zmatt: thanks for reporting the cache result, was around anymore yesterday. Jan 13 06:48:14 LetoThe2nd: yeah, long live linux-perf Jan 13 07:14:02 hi everyone Jan 13 07:14:56 anyone could help me to figure out what i am missing to blink a led via PRU, please? Jan 13 07:51:55 lore4: it helps to ask a concrete question rather than asking for an assistant Jan 13 08:18:31 zmatt: roger that, thank you. I followed Greg's guide and loaded remoteproc; I compiled with success the example PRU_gpioToggle of pru-software-support-package to use it as firmware to blink a led. Therefore, I attached a led with resistance from p8.11 to gnd and loaded the firmware into pru0, but nothing is blinking... What am I missing? : \ Jan 13 08:19:59 PRU_gpioToggle should use P8.11 and I also used "config-pin P8.11 pruout" in order to setup the pin Jan 13 08:21:09 hmm Jan 13 08:21:42 driving a led directly from digital outputs is not recommended, the leds on the beaglebone are connected via transistors Jan 13 08:22:23 try leaving it open and measuring the voltage Jan 13 08:23:44 I should note I'm not really familiar with the pru-remoteproc stuff or how you're supposed to debug stuff when using it, uio_pruss seems to be more commonly used here Jan 13 08:25:12 I believe it should work, as I blinked this led on the same pin using official 3.8 kernel and righto's guide. However, I am not able to blink since I moved to official 4.4 Jan 13 08:25:19 do you have some way to confirm the program is running, e.g. query the program counter? Jan 13 08:25:57 oh so you've previously used uio_pruss already? then why go for remoteproc this time? Jan 13 08:27:33 To figure out if the program was running I used "dmesg", which is not so clear... at least for me Jan 13 08:28:21 so that was also the impression I got from a quick glance at remoteproc, little or no useful way to directly interact with pruss Jan 13 08:29:16 (which is why I paid no further attention to it really) Jan 13 08:29:37 that is my impression too... do you know if there is a better way to understand if it is running or even better debug it? :) Jan 13 08:29:51 I am exploring the differences Jan 13 08:30:24 between 3.8 and 4.4 Jan 13 08:31:04 no, you're exploring the differences between uio_pruss and remoteproc-pru Jan 13 08:31:14 so far, I was able to use PRUs only on 3.8, at least for some blinky led Jan 13 08:31:15 uio_pruss is still available Jan 13 08:31:58 just because TI decided to push this remoteproc thing doesn't mean people actually cared :) Jan 13 08:31:58 Understanding uio_pruss and remoteproc is something that I was struggling with as well Jan 13 08:32:11 lol Jan 13 08:32:31 so, you are using uio_pruss? Jan 13 08:34:01 to my shame I haven't played with pruss nearly as much as I should :/ so far I've always used the generic uio driver (uio_pdrv_genirq) which works for most peripherals/subsystems, I saw no specific need for the peculiarities of uio_pruss at least for the things I did Jan 13 08:34:29 uio_pruss uses the same uio framework though, it just adds some flavor Jan 13 08:36:43 tlab: Checked my rev on the towertech cape. I have rev 5 Jan 13 08:37:06 dome flavor with "pru" taste? :) Jan 13 08:37:11 *some Jan 13 08:38:25 zmatt, btw what are you doing with you bb? Jan 13 08:39:20 lots of stuff, at work we use beaglebones as embedded controllers in products Jan 13 08:39:35 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.42-bone16/drivers/uio/uio_pruss.c here's the uio_pruss driver btw, it's quite small Jan 13 08:40:38 it does a bit for pru->arm irqs, though I'm not sure what it does is actually necessary Jan 13 08:41:46 uhm... what do you mean? Jan 13 08:41:50 has support for allocating shared memory in ddr3... which is sometimes going to be useful though you'd prefer to avoid it given it's very slow to access from PRU (and unpredictable timing) Jan 13 08:42:15 I'm browsing uio_pruss to see what it does (on top of basic uio) Jan 13 08:42:40 oh yeah, that's why I didn't use it... Jan 13 08:43:53 the obnoxious "No children" error Jan 13 08:44:43 I got lost... what do you mean by "that's why I didn't use it..."? Jan 13 08:44:50 (sorry) Jan 13 08:45:15 sorry, I was browsing the source and encountered the reason I used the generic uio instead of uio_pruss Jan 13 08:46:10 the driver does weird and meddlesome gpio checking, which not only makes no sense to me but moreover aborts with an error if you don't declare any, as if there's no valid use for pru without gpios Jan 13 08:46:22 hence, is it possible to use uio instead of uio_pruss to use PRUs? Jan 13 08:47:17 it is possible, since I do, but the library used by examples will probably break so I wouldn't recommend it to the beginner :) Jan 13 08:47:27 T.T Jan 13 08:47:41 the main useful thing it does is shared memory allocation Jan 13 08:47:53 but I don't understand why that's not in the generic driver since it's obviously of general use Jan 13 08:48:09 sa Jan 13 08:48:16 the rest of uio_pruss looks either superfluous or harmful to me Jan 13 08:48:30 (not harmful harmful but more... the wrong thing to do) Jan 13 08:49:42 uhm... ok, but then, how do you pass data from PRUs to ARM, if you have to ofc Jan 13 08:49:46 for BBW do I have to compile a device tree to access SPI1? there are spi devices under /dev Jan 13 08:49:58 lore4: use the pru local memories Jan 13 08:50:55 zmatt: hence, some producer-consumer located in pru's local mem? Jan 13 08:51:14 gquere: spi devices are always defined using DT (either the main one or an overlay) since they have settings... Jan 13 08:51:49 lore4: any technique suitable for use with shared memory and/or irqs Jan 13 08:52:30 zmatt: roget that, thanks ;) Jan 13 08:52:43 there are also IPC peripherals like mailbox and spinlock but they're inefficient and rarely used Jan 13 08:53:04 inter-processor spinlock also seems like an inherent bad idea Jan 13 08:53:07 to me anyway Jan 13 08:54:25 zmatt: so far, what I understood from you is to use uio instead of uio_pruss and remoteproc to exploit PRUs, am I right? At least, use uio till something better comes up Jan 13 08:55:17 yeah, though like I said I haven't done much with pruss anyway Jan 13 08:55:43 the difference between uio_pruss and uio is small (but probably enough to break things unless you understand the differences) Jan 13 08:55:58 zmatt: don't worry, I believe is definitely more than what I have done with pruss ;) Jan 13 08:56:27 I did study the subsystem in a fair bit Jan 13 08:56:47 did some testing with the core, since some details of the core control registers were unclear to me Jan 13 08:57:31 found an undocument bit that indicates when the core encountered an error (e.g. illegal instruction)... no idea why that's not in the TRM Jan 13 08:57:48 zmatt: I have SPI devices under /dev (/dev/spidev1.0 /dev/spidev1.1 /dev/spidev2.0 /dev/spidev2.1) presumably the .dtbo loaded by default has SPI enabled ? Jan 13 08:58:16 what kernel are you using? Jan 13 08:58:26 what version I mean Jan 13 08:58:53 BeagleBoard.org Debian Image 2016-11-06 Jan 13 08:58:58 (from /etc/issue) Jan 13 08:59:01 uname -r Jan 13 08:59:15 and maybe /etc/dogtag Jan 13 08:59:28 Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux Jan 13 08:59:35 huh, ok Jan 13 09:00:08 dogtag (first time seeing this) is the same as issue Jan 13 09:00:12 no idea why there are spi devices then, maybe crap-universal does that Jan 13 09:00:38 ah I thought it was more specific about which image it is Jan 13 09:00:54 I pulled the latest from beagleboard.org Jan 13 09:01:18 do I assume spidev1 = SPI0 and spidev2 = SPI1 ? Jan 13 09:02:08 no in that kernel they're just numbered consecutively in probe-order, 1-based, for extremely bogus reasons Jan 13 09:02:33 I contributed a patch to fix that but I guess they're not backporting it for compatibility reasons Jan 13 09:02:36 maybe Jan 13 09:02:37 dunno Jan 13 09:02:42 how do I tell which is which ? Jan 13 09:03:00 well it would 'break userspace' Jan 13 09:03:06 not really Jan 13 09:03:12 since right now the numbering is undefined Jan 13 09:03:29 but in practice yeah probably there are people relying on it anyway Jan 13 09:03:58 undefined by be different from random :p Jan 13 09:04:06 s/by/might/ Jan 13 09:04:14 zmatt: cool! I have no idea as well, why it is not documented : \ Jan 13 09:05:55 here's the enormous and complicated patch I needed to do to fix spi device numbering: https://github.com/RobertCNelson/linux-stable-rcn-ee/commit/c4e2602d2282b7043b9410301d4ee0daeb299627 Jan 13 09:06:26 haha :p Jan 13 09:06:40 spi core does bus numbering correct Jan 13 09:06:57 TI's mcspi driver overrides it with a counter in a fucking static int Jan 13 09:07:33 gquere: I personally use an udev rule that creates named aliases though Jan 13 09:07:47 /dev/spi/$name where $name is the name of the DT node Jan 13 09:08:52 lrwxrwxrwx 1 12 Dec 23 12:32 /dev/spi/dsp -> ../spidev0.1 Jan 13 09:08:52 lrwxrwxrwx 1 12 Dec 23 12:32 /dev/spi/flash -> ../spidev0.0 Jan 13 09:09:00 (e.g.) Jan 13 09:09:33 ah yes Jan 13 09:09:45 how did you tell them apart at first though? Jan 13 09:10:46 I don't need to "tell them apart", I introduced them with name in the first place Jan 13 09:10:56 zmatt: do you know a guide to load uio/uio_pruss on 4.4, please? I'd like to give it a try again to the blinking led Jan 13 09:11:12 *use not load Jan 13 09:11:36 lore4: I don't but I'd hope one exists Jan 13 09:11:47 zmatt: btw, it is still a bit shady "enable pru" Jan 13 09:11:50 if you find it, consider adding i to http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration Jan 13 09:12:07 shady? Jan 13 09:13:11 zmatt: lol... I am struggling since a week to do it or finding a guide with 4.4 xD Jan 13 09:13:49 lore4: well I've told most previous people here to ask on the forum, so I'd hope there'd be a thread about it right now :/ Jan 13 09:14:21 zmatt: *shady = unclear Jan 13 09:14:35 ah, that's not a synonym Jan 13 09:14:47 gquere: https://hastebin.com/oxekafeqak.cpp Jan 13 09:15:00 zmatt: my fault due to I am not a native speaker ;) Jan 13 09:15:14 shady is like... dubious, questionable Jan 13 09:15:23 suspicious Jan 13 09:15:29 something in that direction Jan 13 09:16:22 lore4: wait, I just remembered I do know how to enable it... maybe Jan 13 09:16:55 yeah, there's an uio_pruss_enable overlay Jan 13 09:17:01 zmatt: I wrote a post on the google group, I hope that it will be accepted, and it could help to understand how to manage PRUs Jan 13 09:17:13 echo uio_pruss_enable >/sys/devices/platform/bone_capemgr/slots Jan 13 09:17:14 or something Jan 13 09:17:31 uhm... that rings me some bells! Jan 13 09:17:40 be sure to first get rid of whatever you did to enable remoteproc Jan 13 09:18:04 can you link to that guide you mentioned? Jan 13 09:18:08 because I'm kinda curious Jan 13 09:18:12 don't worry, I start to flash the uSD for the n-time Jan 13 09:18:24 since rcn said remoteproc can't be enabled at... runtime.. ah Jan 13 09:18:24 which one_ righto or greg? Jan 13 09:18:39 reflash the usd? why? Jan 13 09:19:01 greg Jan 13 09:19:11 to clear the capes mess that I did while example was not working Jan 13 09:20:08 uhh, I'll take your word for it that you made enough of a mess to justify reflashing Jan 13 09:20:47 zmatt: that's the discussion that i followed for 4.4 https://groups.google.com/forum/#!topic/beagleboard/tQW4ZLcncF8 , which contains also greg guide link https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf Jan 13 09:21:48 I once recovered a beaglebone which crashed during a big system update, leaving it unbootable (libc.so was corrupted)... but I'm probably nuts Jan 13 09:21:59 zmatt: yeah... after the example was not working, I started to change the capes to check if it was a pin issue, but you know, it only got worst Jan 13 09:22:17 zmatt: lol Jan 13 09:23:14 it's nice to have confidence in being able to do recovery though Jan 13 09:23:22 better to practice in cases where it's not important :) Jan 13 09:24:26 now before I forget again, time to add it to the wiki Jan 13 09:25:47 fair enough! However, I am so newbie that I am still struggling to make leds blink... recovery will be on the list, but not today ;) Jan 13 09:26:14 hehe, no Jan 13 09:26:19 that I understand Jan 13 09:27:51 zmatt: brb Jan 13 09:27:52 gquere: note that, although I'd still recommend configuring spi devices properly, you can at least get sane spi device numbering simply by upgrading the kernel Jan 13 09:29:21 I make the symlinks with this udev rule: Jan 13 09:29:21 SUBSYSTEM=="spidev", IMPORT{parent}="OF_NAME", SYMLINK+="spi/%E{OF_NAME}" Jan 13 09:29:46 which should also work on 4.4 Jan 13 09:56:02 zmatt: thanks, will look into it I'm still taking baby steps here Jan 13 09:56:16 lol @ today's xkcd Jan 13 10:22:37 Hi guys! Jan 13 10:23:39 Have anybody used a max310x device? Jan 13 10:24:22 doing polls in here is generally not a fruitful persuit Jan 13 10:25:01 I cant get it to receive data, only send data. Seems like the module isnt handling the irq correctly Jan 13 10:36:44 zmatt: back, I give a try again to use remoteproc. Then, I'll try to use uio_pruss_enable as you suggeste! Thanks zmatt Jan 13 10:36:49 *suggested Jan 13 10:37:44 One of these days I'll remove "spidev" from my highlight... Jan 13 10:57:27 Can I see if the interrupt from the dtb is correctly configured? Jan 13 10:57:54 so my understanding is that I'm to use /dev/spidev2.0 for SP1 CS0 Jan 13 10:58:10 is it enough to run flashdump from here ? Jan 13 10:58:42 I get the error "No EEPROM/flash device found." though I'm still reading the manpage for parameters Jan 13 10:59:04 laurittr: if the driver has requested the irq it will show up e.g. in my show-pins utility Jan 13 10:59:09 (it's connected to a SPI flash memory chip) Jan 13 10:59:19 gquere: is pinmux set correctly? Jan 13 11:00:23 zmatt: I get this from show-pins: P9.27 105 fast rx up 7 gpio 3.19 spi@481a0000 (spi1_pins) Jan 13 11:02:22 zmatt: do I need to understand /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups to answer this ? Jan 13 11:02:54 gquere: fortunately not, grab my show-pins utility from here: https://github.com/mvduin/bbb-pin-utils Jan 13 11:03:18 arg perl ;) Jan 13 11:03:36 laurittr: vs the other one? (which does have a working irq) Jan 13 11:03:46 laurittr: I remembered that right didn't I? Jan 13 11:04:14 since this looks like the irq hasn't been requested by the driver Jan 13 11:04:56 Y, got the mcp2515 (spi to can) to work at last. And that one usese irq. Jan 13 11:04:58 I'd expect to see << hi or << lo after the gpio number Jan 13 11:05:05 ah, ok Jan 13 11:05:35 Il boot up my other image and see what i get from that one Jan 13 11:05:59 zmatt: it's for bbb tho Jan 13 11:06:42 gquere: you're using? Jan 13 11:07:43 BBW Jan 13 11:07:59 it should work okay for any am335x-based system, except the pin labels (first column) may be wrong and you may need to pass -v to show more pins (twice to show all pins) Jan 13 11:08:13 I guess this is why you were surprised that SPI seemed to be enabled by default Jan 13 11:08:40 default_pin = mode0 ? Jan 13 11:09:01 why? the bbw doesn't have any spi devices on board does it? (certainly not four) Jan 13 11:09:17 default in what sense? Jan 13 11:09:26 i'm confused now Jan 13 11:09:38 there are 4 spi devices under /dev Jan 13 11:09:38 as am I Jan 13 11:09:47 yeah so something declared those in DT Jan 13 11:09:57 my bet would be cape-universal Jan 13 11:09:59 i'm using a stock image Jan 13 11:10:07 i'm not so that doesn't say much for me Jan 13 11:10:13 :) Jan 13 11:11:16 you can try rebooting with cape-universal disabled (it's enabled by a config option in /boot/uEnv.txt, not hard to find) Jan 13 11:11:29 if the devices are gone then, then you know where they came from Jan 13 11:14:12 yep, they come from cape-universal indeed Jan 13 11:14:37 yeah I see it now Jan 13 11:15:17 configured for 16 MHz, spi mode 1 Jan 13 11:15:20 do I still need to check the pinmux (it was my undesrtanding that the pinmux was dependent on the device trr) Jan 13 11:15:28 s/trr/tree/ Jan 13 11:16:26 so probably earlier it didn't work because you didn't have the pins muxed and/or because perhaps the spi mode is wrong (depends on whether the program you ran overrides it) Jan 13 11:18:13 arf my spi devices are gone now :p Jan 13 11:18:18 off to eat tho Jan 13 11:19:17 zmatt: Output from the show pins with the can cape: P9.27 105 fast rx up 7 gpio 3.19 0@spi2 (pinmux_tt3201_0_mcp2515_pins) Jan 13 11:20:35 still no < But than it says it is being used by sysfs Jan 13 11:21:19 duh, you exported it Jan 13 11:21:44 mhm Jan 13 11:21:48 had to try Jan 13 11:22:13 :p Jan 13 11:22:43 I think il just add some prints to the module and see if it actually ever run the icr Jan 13 11:27:11 icr? Jan 13 11:28:26 So used to microcontrollers. I meant the interrupt routine Jan 13 11:28:43 it won't Jan 13 11:28:43 It probably sets a flag and then the module run some handle_rx function or somehting like that Jan 13 11:28:52 since the irq isn't requested Jan 13 11:29:03 ah, ok Jan 13 11:29:04 you can probably also verify that in a more direct way via debugfs Jan 13 11:29:36 ohh wait, you're saying the working irq doesn't show as input? that's very odd Jan 13 11:29:39 it ought to Jan 13 11:29:52 Yea, thats what I am saying Jan 13 11:30:53 hmm, weird, either I misremember or that changed Jan 13 11:30:54 It might change when i actually start to send something on the bus Jan 13 11:31:05 give me a sec Jan 13 11:31:09 no I'm now seeing it too Jan 13 11:31:21 ok Jan 13 11:31:43 you can find it in /proc/interrupts though Jan 13 11:31:45 But i got the hi/lo thingy when i exported a gpio manualy from sysfs Jan 13 11:33:48 zmatt: I found a blinky example in pru-support-package, and I tryed to exploit it with the remoteproc by following Greg's guide.. howver, when I try to load the fw on pru0 via echo xxx.pru0 > "..." I catch an error "echo: write error: no such device".. :( Jan 13 11:34:14 zmatt: omw to take lunch... be back in the afternoon ;) Jan 13 11:34:33 Here is my output from showpins and proc/interupts: http://dpaste.com/3KX2E40 Jan 13 11:34:49 I dont understand how they map between each other. Jan 13 11:37:42 they don't very much, but any gpio used as irq would appear similar to the sd card detect: http://dpaste.com/3KX2E40#line-25 Jan 13 11:39:41 zmatt when do you sleep? Jan 13 11:39:41 (which isn't included in show-pins output unless you pass the -v option) Jan 13 11:39:53 GenTooMan: ? Jan 13 11:39:55 sleep? Jan 13 11:40:35 ;) Jan 13 11:40:41 with the -v option, i can see that the mmc thing has a < yeah it's inconsistent, I don't know why Jan 13 11:44:09 https://hastebin.com/soxedezepu.txt <-- I'm seeing the same thing Jan 13 11:44:26 Is there a fast way to rebuild just one module, and not the whole kernel? Jan 13 11:45:34 possible in theory I think, but probably a lot easier if you've built the kernel once already Jan 13 11:45:50 I built it a couple of days ago Jan 13 11:45:53 the kernel Jan 13 11:46:16 make should only rebuild the changed files, then Jan 13 11:46:20 exactly Jan 13 11:46:53 ./build_deb.sh does always rebuild, annoyingly Jan 13 11:47:05 so use ./build.sh Jan 13 11:47:11 assuming you're using rcn's scripts Jan 13 11:47:17 mabye that script passes -B to make Jan 13 11:47:27 I have a script called build_kernel.sh Jan 13 11:47:27 when you invoke make -B, it rebuild everything Jan 13 11:47:32 laurittr: ah that Jan 13 11:47:47 tocix: no it uses debian-packaging tools Jan 13 11:48:03 which perform explicit cleaning as step 1 Jan 13 11:48:06 i see Jan 13 11:48:21 I can sort of understand why, but it's annoying Jan 13 11:48:32 fortunately rcn's scripts will ensure ccache is used if installed Jan 13 11:49:05 yeah, also pass -pipe to gcc and -j to make Jan 13 11:49:12 for maximum speedz Jan 13 11:49:22 etc Jan 13 11:50:14 What about the rebuild.sh script in tools? Jan 13 11:50:25 oh yeah sorry Jan 13 11:50:28 that one I meant Jan 13 11:50:36 crap Jan 13 11:50:43 so I was right about the lack of -suffix Jan 13 11:50:43 i already started the build script Jan 13 11:50:51 well, now you know for next time Jan 13 11:50:55 y Jan 13 11:51:15 if you have ccache installed then this shouldn't take as long as the first time anyhow Jan 13 11:51:18 i was hoping i could use my bbb as a router. unfortunately, my isp uses fiber which plugs into their special router/mediaconverter Jan 13 11:52:56 is there such a thing as a fiber-to-ethernet converter? Jan 13 11:53:16 but trivial (i.e. without software) Jan 13 11:54:45 tocix: if their fiber protocol is just ethernet, then yes. if its something telco specific, things might be hard. Jan 13 11:54:54 perhaps it's easier to change isp Jan 13 11:55:25 tocix: i wonder anyways why anybody wants to use a board with only one ethernet port as a router ;-) Jan 13 11:55:43 everyone uses wifi these days Jan 13 11:56:09 tocix: nope, and i can prove you wrong. Jan 13 11:56:30 ok Jan 13 11:57:19 anyway, I have a usb wifi thingy plugged into the bbb which acts as an access point Jan 13 11:57:34 BBE has wifi and gigabit ethernet Jan 13 11:57:54 still wouldn't want to use it as a router though :P Jan 13 11:58:05 zmatt: same here, but hey - use cases differ. Jan 13 11:58:08 the am335x is not well optimized for the purpose Jan 13 11:58:41 so it would be slow? Jan 13 11:59:27 maybe, maybe not, depends of course also on how much bandwidth and how much time invested in tuning the system Jan 13 11:59:41 and on the expectations ;-) Jan 13 12:00:05 but given the ubiquity of cheap routers, why bother Jan 13 12:00:23 it sounds like an utter waste of bbb to me Jan 13 12:00:50 s/bbb/time/ - except for learning purposes. Jan 13 12:00:58 forced into a task it's not made for while its true resources are neglected Jan 13 12:08:17 zmatt, what are its true resources? Jan 13 12:09:31 its i/o and interfacing abilities, PRUSS of course, stuff like the pwmss modules Jan 13 12:11:25 PRUSS is its most unique feature (there are other TI SoCs with PRUSS but they're much bigger and more expensive, or an old arm9 with an old pruss version) Jan 13 12:12:13 though the pwmss peripherals are also interesting, those got imported from TI's real-time microcontrollers Jan 13 12:13:06 basically it has peripherals more typical of microcontrollers, yet a powerful enough cpu to comfortably run linux and display a user interface Jan 13 12:13:40 adc is I think also quite uncommon among cortex-A based SoCs Jan 13 12:14:36 zmatt: depends, sama5 has them too. Jan 13 12:15:09 I didn't say unique :) Jan 13 12:15:31 though sama5 is I think quite new? Jan 13 12:15:32 newer, low end imx6 have them too Jan 13 12:15:43 zmatt: sama5 is about the same age Jan 13 12:15:44 ul, ull, solox Jan 13 12:15:50 ok Jan 13 12:15:57 i'd say any industrial targetted soc has them Jan 13 12:17:12 how big a chunk of the cortex-A SoCs are industrial targeted though? :P Jan 13 12:18:06 but yeah it makes sense that it becomes more common to use cortex-A based oversized-microcontrollers Jan 13 12:19:26 I didn't put adc at the front of the list :) Jan 13 12:23:38 I would like to know the best way to have a virtual keyboard with jessie Jan 13 15:49:34 xmatt: do you have any experience with cape-universala? Jan 13 15:49:58 zmatt: do you have any experience by disabling hdmi? Jan 13 15:50:34 lore4: I consider cape-universal fundamentally a bad idea, even though I accept it makes things initially simpler for newcomers, if their use case happens to be supported by cape-universal Jan 13 15:51:16 are you researching my qualifications or do you have an actual question? :P Jan 13 15:51:41 zmatt: uhm.. ok, because I was able to: 1. enable the remoteproc, but not to unlock the pin that I want to toggle as assigned to hdmi; 2. set pin that i want to toggle as pruout, but unable to enable remoteprox and prus. Jan 13 15:52:07 zmatt: lol, I have a lot of questions, but i would not sacrifice you :P Jan 13 15:53:11 I thought you were going to use uio_pruss? Jan 13 15:54:06 zmatt: I'd like to, but a collegue of mine would like to be sure that remoteproc is out Jan 13 15:56:42 zmatt: if I try to change mode of pin8 45 i get this: debian@beaglebone:~$ sudo config-pin -q P8.45 pruout P8_45 pinmux file not found! cape-universala overlay not found run "config-pin overlay cape-universala" to load the cape Jan 13 15:57:16 I believe that is due to hdmi Jan 13 15:58:14 zmatt: In fact, if i use a pin that it is not used by hdmi I am able to change its mode: sudo config-pin -q P8.11 pruout P8_11 Mode: default Direction: in Value: 0 Jan 13 15:59:28 zmatt: i'll try to work around that and change the pin used for blinky Jan 13 16:03:45 lore4: config-pin requires cape-universal Jan 13 16:03:55 oh Jan 13 16:04:01 yeah Jan 13 16:04:10 so disable hdmi then Jan 13 16:05:26 i do not know why, but if i disable hdmi via /boot/uEnv.txt, when I reboot, remoteprox is not loaded T.T Jan 13 16:05:44 how did you enable remoteproc in the first place? Jan 13 16:06:09 wait, you linked to some guide earlier... I forgot Jan 13 16:06:14 I followed Greg's guide, chapter 10.2 Jan 13 16:07:26 hence, I cloned dtb-rebuilder from RobertCNelson, edited am335x-boneblack.dts to load rempteprox, and then compiled the dts and isntalled dtbs via "make; make install" Jan 13 16:07:43 I also made the blacklist with uio_pruss Jan 13 16:07:51 the blacklist is utterly pointless Jan 13 16:08:03 but, ok so you modified and rebuilt that dtb Jan 13 16:08:14 yep Jan 13 16:08:32 and then you select a different dtb to disable hdmi and you're surprised remoteproc is no longer enabled? Jan 13 16:09:08 btw I strongly urge *against* modifying existing dts files Jan 13 16:09:26 leave the stock dtbs as they are so you can fall back on them Jan 13 16:09:47 for customizations make a copy of whatever dts file is closest to what you want and modify that Jan 13 16:09:49 in order to disable hdmi, as far as I understood, I edited /boot/uEnv.txt by uncommenting "dtb=----emmc-overlay.dtb" Jan 13 16:10:00 which selects the dtb Jan 13 16:10:11 ahhhhh Jan 13 16:10:40 do you believe that it would be enough to edit am335x-boneblack-emmc-overlay.dts to include remoteprox? Jan 13 16:10:47 *remoteproc Jan 13 16:10:53 can you please read what I said a few lines ago? Jan 13 16:11:28 where do you get the default dts? Jan 13 16:12:12 zmatt: yeah, facepalm Jan 13 16:12:32 you had them :P they're also installed with every kernel so reinstalling the kernel package will restore the installed dtbs to original Jan 13 16:13:18 you can also revert the dts files in dtb-rebuilder since it's a git repo Jan 13 16:13:22 git reset --hard Jan 13 16:13:40 (in the dtb-rebuilder directory) Jan 13 16:13:59 that won't throw away any new files you created Jan 13 16:14:42 uhm.. sorry I got lost in the last 4 messages Jan 13 16:16:42 you can restore the source files in the dtb-rebuilder directory tree to their original state by using the command git reset --hard in that directory Jan 13 16:17:18 that's right! God bless git :D Jan 13 16:17:40 you can restore your installed dtbs to original state using: sudo apt-get --reinstall install linux-image-$(uname -r) Jan 13 16:18:33 btw when using a custom dtb, I recommend placing it in /boot/dtbs/ rather than the kernel-version-specific subdirectory Jan 13 16:20:22 zmat: thank you, I noted down both of them ;) Jan 13 16:20:31 zmatt: btw, now: debian@beaglebone:~$ sudo config-pin -q P8.45 pruout P8_45 Mode: default Direction: in Value: 0 Jan 13 16:20:57 zmatt: do you mean to create a different one instead of modifing the default ones? Jan 13 16:21:28 as I said, in my opinion you shouldn't modify default ones at all Jan 13 16:21:54 zmatt: it is blinking!!!! Jan 13 16:22:07 cheers Jan 13 16:23:16 zmatt: I owe you a beer! thanks a lot :D Jan 13 16:23:34 I don't drink beer, but thanks :) Jan 13 16:23:58 lol... damn, the central repository for my decentralised source control system is down.... Jan 13 16:24:12 lol Jan 13 16:24:14 (github has an outage) Jan 13 16:24:51 zmatt: let's say that I owe you one (not of beer then) Jan 13 16:30:08 zmatt: may I ask you a question about pinmuxing and R30/31 register, please? Jan 13 16:32:59 zmatt: the example should blink R30 ^= 0X000F which I believe shoud be pr1_pru0_pru_r30_15 (i.e. GPIO 45). However, the blinking led is pr1_pru1_pru_r30_0 (i.e. p8_45 / GPIO 70). Do you have any idea why? Jan 13 16:35:28 zmatt: is it because it puts the first 4 bits to 1? Jan 13 16:37:08 zmatt: leaving work, thanks for everything ;) tomorrow I'll read the logs Jan 13 16:38:15 ... Jan 13 16:39:30 every bit is an output, you're toggling bits 0..3 hence outputs 0..3 Jan 13 21:32:24 laurittr, yeah mine says rev 2. I've finally confirmed with towertech there is an issue. They say they have a fix and asked for the serial number so I gave them an eeprom dump. I'm waiting to hear back from them. Jan 13 21:43:43 hi Jan 13 21:44:09 is it possible to get a tty through the mini-usb port on a bbb? Jan 13 21:45:35 I was absolutely certain it's possible ever since I've seen someone get a tty over it, until I've googled it today and found absolutely nothing. Jan 13 23:19:57 cannot get board to connect to my pc/ pc driver wont intal Jan 13 23:46:32 Could someone help me out? I plug my BBB into the usb the blue leds came on and went off. i have also plug it into the wall and nothing Jan 13 23:47:29 Now no leds are on. Jan 14 01:34:27 hi , i have a question gpio and serial ide is the same ?? Jan 14 01:35:59 bros Jan 14 01:38:50 i have a question gpio and serial ide is the same ?? **** ENDING LOGGING AT Sat Jan 14 03:00:00 2017