**** BEGIN LOGGING AT Fri Aug 05 02:59:58 2016 Aug 05 03:26:28 Hi,my BBB PWR LED & user LED all not work.What it happen? Aug 05 18:38:28 why is there a TMP102 TI temperature sensor on the x15 just hanging out in the middle of the board not near anything that makes heat? it's what is driving the fan control? Aug 05 18:41:59 why wouldn't the internal temperature sensors on the am57xx soc die be used for controlling the fan? Aug 05 18:47:27 bradfa: how you could tell the difference between "SoC is 80C because ambient is 70C and SoC has light load" and "SoC is 80C because ambient is 30C and SoC has heavy load"? Aug 05 18:48:19 how would you make use of knowing the difference? Aug 05 18:48:57 if ambient is too high tell user to turn on the air conditioning? Aug 05 18:49:38 or maybe using fan to pull some cooler air over board, although air conditioning would work too :p Aug 05 18:50:41 well it depends a bit on what "ambient" means and where the fan is located Aug 05 18:50:46 true Aug 05 18:53:54 but in general I'd expect that a control loop based on temperature sensors on die (which is ultimately that whose temperature needs to be kept below limits) should work Aug 05 18:57:34 of course it never hurts to have an extra sensor... it's easier to discard info if you don't need it then conjure it up if you do need it Aug 05 18:59:49 but I'd expect a near-board-ambient temperature sensor to be mainly useful if you have a case and at least two controllable fans: one on the cpu (cooling the cpu with case-air) and one drawing fresh air into the case Aug 05 19:03:27 also, can I say: ARGH the reseller of the (non-FCC) x15 batch available doesn't sell to individuals, only to companies =( Aug 05 19:03:46 (at least in NL) Aug 05 19:13:09 Question; Does anyone know if it's possible to have more than one eMMC connected at once? I've seen mixed info about it such as some notes in the kernel source about a broadcast to see what chips are on the bus Aug 05 19:14:00 I have an FPGA connected to the eMMC pins and was going to make a core that simulates an eMMC on the FPGA to allow fast r/w access to it's other functions Aug 05 19:15:30 I would still like to use the onboard eMMC though Aug 05 19:16:38 LoialOtter: there's still an unused third mmc/sd/sdio interface available via the BBB's expansion headers Aug 05 19:18:49 it's missing a critical pin or that pin is used on the LCD or something Aug 05 19:19:29 nope, P8.11-19 are clk and d0-d7, P9.15 has cmd Aug 05 19:21:27 oh, I see now; I need CAN and the I2C that are on those pins Aug 05 19:26:00 ojousima: zmatt: thanks for the input :) Aug 05 19:26:41 LoialOtter: uh no Aug 05 19:27:19 LoialOtter: none of those pins coincide with any of the CAN or I2C interfaces Aug 05 19:31:33 well, it still comes down to I don't have enough IO as it is with a whole bunch taken up by the eMMC, the LCD and the rest of the requirements. I ended up using expanders where I could... Aug 05 19:32:07 This is also a board that's already made. I'm just getting the components to stuff it. Changing the IO is no longer an option Aug 05 19:32:29 I don't NEED the emmc interface, I just would rather have it Aug 05 19:33:21 old mmc supported multiple cards on a shared bus, but that's ancient history Aug 05 19:44:24 so you want to use the mmc1 interface, you'll need to keep the eMMC in reset (note: you first need to enable the hardware reset line by setting an OTP bit in the eMMC itself) Aug 05 19:45:32 or command it to go into inactive mode via software Aug 05 20:01:03 It looks like the MMC spec says that the card will not respond to an illegal instruction and will not change state - I can make my FPGA respond to CMD44 for instance and then clear the flag after the access Aug 05 20:01:39 otherwise I can tell the eMMC to go into standby or idle but i think that needs to be re-initialized after Aug 05 20:02:54 if you don't need the FPGA to behave like eMMC but just use a custom protocol "tunneled" over the MMC interface that would work yeah Aug 05 20:03:21 one thing to consider: the reason support for multiple cards on a bus was dropped was due to signal integrity problems as clock speeds increased Aug 05 20:05:30 ya. I've placed some "gate" analog switches between the pins and my FPGA if I have to turn it off. I've also kept the traces short and direct to the FPGA so it should work in a similar way to a cape that does pass-through on those pins Aug 05 20:08:59 thanks; helped me track down stuff that !might! work and I'll give it a try once I have the hardware fully made Aug 05 20:09:05 good luck with it :) Aug 05 20:09:21 fortunately MMC has CRC on both commands and data Aug 05 20:09:33 so if there are signal integrity issues at least you won't get silent corruption Aug 05 20:10:13 ya. That's also another way to pipe a second interface over emmc, though I'm expecting the CRC is handled in the peripheral rather than software so it'll be harder to fake Aug 05 20:14:03 yes CRCs are handled in the peripheral, you do want to make sure you're using normal command and data block transfer structures Aug 05 20:15:33 hmmm Aug 05 20:16:57 ya. I'm just examining what an out-of-address error will do. It looks like the memory will respond with an error then return to transfer state but I'm not sure if that's tristated or not Aug 05 20:17:02 yeah I think your idea of using non-standard command numbers, relying on the eMMC to remain silent in response, should work as long as no signal integrity issues pop up Aug 05 20:17:37 well I'm assuming you're not going to try this in the middle of an eMMC transfer Aug 05 20:17:51 if the invalid address tristates, I can use the bus while the emmc is waiting for the end of transmition Aug 05 20:18:02 heh... hopefully not... doubtful really Aug 05 20:18:23 it'd be really slick to just make this a memory mapped location that's outside the valid range for the flash Aug 05 20:20:24 I think that's much hairier then you're imagining right now Aug 05 20:21:25 ya, i think so too... I'll give it a try though as it means no kernel changes or software really Aug 05 20:22:05 you can forget about the "no kernel changes" Aug 05 20:22:37 it obtains the card size by reading an information block from the card, not by trial and error :P Aug 05 20:22:43 eh, i know that's one heck of a stretch for this Aug 05 20:22:56 the FPGA has no way to interfere with that Aug 05 20:23:04 and you have no idea to read out of bounds by default Aug 05 20:23:10 good point Aug 05 20:23:38 otoh if you use custom commands then I think you might actually not need kernel changes Aug 05 20:23:54 iirc there's a userspace mechanism for issuing low-level MMC commands Aug 05 20:24:02 it depends on if there's a sysfs or other interface to the ... awesome! Aug 05 20:24:15 but you'd need to check what exactly it can or cannot do Aug 05 20:24:21 ya Aug 05 20:24:59 I also don't know if the kernel allows it while a filesystem is mounted on the MMC Aug 05 20:25:14 ya Aug 05 20:25:40 but see e.g. mmc-utils which uses it for reading/altering ECSD registers Aug 05 20:25:49 oh, awesome, thanks Aug 05 20:27:51 also, in case you don't already know: the eMMC specs are freely downloadable from JEDEC (only registration required) Aug 05 20:29:25 the relevant spec for the eMMC on the BBB is JESD84-A441 (for the micron eMMC) or JESD84-B451 (for the kingston eMMC) Aug 05 20:29:33 they're absolutely horrible documents Aug 05 20:29:39 heh Aug 05 20:30:09 they actually make one longing for the painful formality of IEEE standards Aug 05 20:30:49 the eMMC standards are vague, regularly retain obsolete info, and completely lack any sort of meaningful organization Aug 05 20:30:56 oh man... wow... Aug 05 20:31:18 I've been reading through this one: http://rere.qmqm.pl/~mirq/JESD84-A44.pdf Aug 05 20:31:33 yeah that's slightly older Aug 05 20:32:34 4.41 added background operations, HPI, and a whole bunch of clarifications Aug 05 20:32:41 (according to revision log) Aug 05 20:33:26 but like I said you don't need to scrape the net for standards in this case, you can officially download them from the free Aug 05 20:48:23 Hello, does anyone have experience watercooling a BBB? I'm hoping to use it for a project in an ultra low pressure environment where there isn't air to move heat away from the processor. Aug 05 20:49:52 someperson40: not the BBB but somewhat related - https://www.youtube.com/watch?v=O7cc4eLAOMk Aug 05 20:55:43 That’s a good find, thanks :) Can you think of any reason the same method wouldn't work on a BBB? I think the PRUs would also need to be cooled but I'm not sure what else would get hot Aug 05 20:57:06 the PRUs are within the CPU so will be cooled at the same time. There's a power supply near the ethernet connector and power input jack that may produce a little Aug 05 20:57:22 the ram is another possible source of heat Aug 05 20:57:29 and that sounds very interesting... sorry to jump in Aug 05 20:58:46 why not just use a thermally conductive membrane or silicone mat to catch everything at once? They're a little expensive, but should be rated for near vacuum and will conform to the chips Aug 05 21:00:05 I like that idea. I don't have access to the environment for a while so that will be a lot safer Aug 05 21:02:47 maybe something like this: https://www.digikey.ca/product-detail/en/t-global-technology/TG6050-30-30-2/1168-1579-ND/3042390 Aug 05 21:07:24 Thanks :) I was struggling to find that. It will form around the chips, right? Aug 05 21:08:26 it's Shore 00 so highly flexible. I can't tell if that one's a compressible one or not... just a sec Aug 05 21:09:36 If i'm reading the spec sheet right it's 80% compressible Aug 05 21:11:24 this may be a closed-cell foam. If it is, you may have to test how it handles low pressure/vacuum Aug 05 21:11:54 If i had a sample of this, I could test it and the BB in a small vac chamber but it's not something i have on hand Aug 05 21:13:24 okay, I should be able to get to a vacuum chamber so I'll order this, and maybe a couple other options and see how they perform. Thank you for the help :) Aug 05 21:13:48 what's the environment? high altitude? Aug 05 21:15:04 if you don't need the processing power, you can also lower the CPU frequency and/or put the system to sleep when it's idle; that'll limit how much heat is produced Aug 05 21:15:28 It's inside SpaceX's hyperloop vacuum tube Aug 05 21:15:46 I think we need the processing power too much for that Aug 05 21:16:16 oh damn... and you have me jealous Aug 05 21:19:51 and here I am just hacking cars Aug 05 21:23:40 haha thanks. That sounds really cool too Aug 05 21:25:07 btw, out of everything I've tried, the beaglebone is the best CAN traffic analyzer. Has some troubles keeping up with playback of a volkswagen onboard bus though Aug 05 21:25:44 where nothing else I've tried can even try, so a few troubles are way better than not working Aug 05 21:27:02 and I'm planning on making a PRU do the lowlevel timing task soon, so even those will hopefully be taken care of Aug 05 21:31:42 oh nice, we've been throwing around a lot of different board ideas and settled on this because it seems to have the most support for using an RTOS Aug 05 21:34:07 I haven't tried running an RTOS on the beaglebone; I use ChibiOS on a STM32F105 to do the final product I work on. I've also been going toward using FPGAs on more timing critical or unusual protocol tasks Aug 05 21:34:58 hence why I was asking about emmc interface to an FPGA... though in truth the PRUs would do everything I needed if they had a bit more IO Aug 05 21:53:00 if you make a custom board you might be able to make more efficient use of the I/O available on the am335x, though the bbb actually does a present decent job of breaking it out Aug 05 21:54:55 the next step up would be the am571x I guess, but that's a rather non-trivial step up Aug 05 21:55:08 The problem is soldering the thing, hehehehe. Also working on onesy-twosies makes anything I build at least double the cost even with leaving off some of the unneeded parts Aug 05 21:55:39 onesy-twosies? Aug 05 21:55:48 single parts rather than reel-quantities Aug 05 21:55:52 ah yes Aug 05 21:56:42 though once an FPGA gets involved you're generally not into cost-minimization anymore anyway :P Aug 05 21:56:49 i mean the CPU on this is $40CAD in singles from Digikey... and a Beaglebone Green is $55 Aug 05 21:57:11 ice40 series; sub $10 for a fantastic little chip Aug 05 21:57:42 hmm, hadn't heard of it Aug 05 21:58:31 but yeah, it's kinda weird the cpu is that more expensive in single quantity Aug 05 21:58:51 https://www.digikey.ca/product-detail/en/lattice-semiconductor-corporation/ICE5LP4K-SG48ITR50/220-2068-1-ND/5358109 Aug 05 21:59:10 I mean yes, the BBB and BBG are mass-produced, but by the same argument the AM3358 itself is even more mass-produced, so why wouldn't the same economics apply? Aug 05 21:59:38 handling/packaging costs... plus it's the norm Aug 05 22:00:25 yeah mostly the fact that almost nobody who buys embedded SoCs buys single units Aug 05 22:01:46 i mean, buy resistors some time. 1 is $0.15; 10 is $0.17; 100 is $0.67; 1000 is $3.00 and a full reel of 5000 is $9.78 Aug 05 22:02:46 yes but in that case the individual resistors are so cheap it just makes no sense to ship one unit Aug 05 22:02:50 same is not true for SoCs Aug 05 22:03:13 so what you're paying Digikey for, in the case of a microcontroller, is their markup for having to hold on to $35,000 in product so they can sell you one :) Aug 05 22:03:48 or well, maybe that's the problem: they are cheap for the target market of individual SoCs (manufacturers of embedded systems), while they aren't for the target market of beaglebones (individuals) Aug 05 22:04:05 *nodnods* Aug 05 22:05:08 it would be nice if there'd be something a bit of a step up from the BBB though Aug 05 22:05:41 maybe the am437x is any good, but for some reason it seems to have very little attention compared to the am335x and the am57xx Aug 05 22:05:53 i'll be back in a couple Aug 05 22:07:46 interesting, these guys actually give complete pricing details for all config options and quantities... http://www.compulab.co.il/products/computer-on-modules/cm-t43/?gclid=CMi9wa2kq84CFUJmGwoddVABnQ#ordering Aug 05 22:10:09 ya, i love that form factor too... wow... Aug 05 22:10:30 but do they offer single units... Aug 05 22:10:35 scroll to bottom Aug 05 22:10:47 oh, i see, thanks Aug 05 22:11:21 it's just a random google hit, there are tons of SOMs Aug 05 22:11:56 I should check again... i haven't for a few years Aug 05 22:13:59 I never really know quite what to think of them, often they're still expensive, introduce limitations, and i'm not entirely convinced that designing a baseboard for such a thing (which still involves all high-speed I/O) is that much easier than a custom board Aug 05 22:15:52 there's not all that much high speed off the module itself Aug 05 22:16:37 well if there isn't then you'd be using it mainly as a computational module, which seems unlikely Aug 05 22:16:56 it depends on what you need it for really. What I'm working on right now is a programming jig so it's effectively a little laptop with some hardware interfaces that's locked down to its task. A SOM is pretty ideal as then I don't have to use high-layer boards or solder BGAs Aug 05 22:18:02 I have some programmable analog sections that can do 1MHz and a couple CAN interfaces. I also have to throw SWD over a bit... but it's all slow Aug 05 22:18:53 even my previous use of the BBB was a motion controller, again slow stuff and the thing is overkill and a half... but it's the same price to make it with a microcontroller with 64K of ram... so... why not go with a little overkill Aug 05 22:19:11 no display? ethernet? usb? Aug 05 22:20:01 I do have USB but that's pretty easy and I could have (if i didn't have to monitor the current for testing reasons) pushed that onto an off-the-shelf hub Aug 05 22:20:32 usb easy? easy to fuck up yes Aug 05 22:20:35 this does have an LCD but even and SPI one would've been overkill Aug 05 22:20:51 high-speed usb is half a gigabit/s Aug 05 22:21:38 If i get 12mbit i'm happy... and if my untested board fails, I just hack a USB hub to using power from my board Aug 05 22:21:55 but compared to the DDR interface, USB is easy Aug 05 22:22:00 very very easy :) Aug 05 22:23:45 I'm not that intimidated by DDR anymore, especially since with the am335x you'd have only a single RAM chip and all traces point-to-point Aug 05 22:24:06 it's lower clock frequency than high-speed USB Aug 05 22:24:21 (iirc) Aug 05 22:24:21 and USB is just a differential pair with spec'd impedance Aug 05 22:25:08 yes but it has to exit your board, which often means the traces are longer and may get in the way Aug 05 22:25:40 well ok you're right it is easier Aug 05 22:26:42 but more like, once you include DDR3 you're not going to be tempted to try a pcb with too few layers Aug 05 22:26:58 ya Aug 05 22:27:06 usb looks like an innocent pair of traces Aug 05 22:27:17 leading people to do stupid things Aug 05 22:28:04 like https://gerbil.xs4all.nl/pocketbone-composite.png Aug 05 22:28:35 (usb interfaces on left and right side, pink/red is top layer, green is bottom layer GND, blue is bottom layer non-GND) Aug 05 22:29:24 erf... that one on the right breaks it's impedance and as it is it'll be too high due to having ground plane right under it... Aug 05 22:29:34 left side usb routed over one split in the ground plane, right side usb over two splits in ground plane Aug 05 22:29:43 ground plane under it is required Aug 05 22:29:51 how close though Aug 05 22:30:14 probably closer than this pcb has it Aug 05 22:30:59 but also this ground "plane" looks more like a nice big loop antenna Aug 05 22:31:37 as someone commented "have fun submitting a 2-layer design for FCC testing" Aug 05 22:31:54 I just checked, I did put an unbroken ground plane under my usb. I also cut back the plane near it on it's own layer... hmm... Aug 05 22:32:21 http://www.ti.com/lit/an/sprabt8a/sprabt8a.pdf Aug 05 22:34:15 there's a chance my stuff won't work... hmm... Aug 05 22:35:44 a one-line addition to the device tree can be used to limit usb to full-speed instead of high-speed Aug 05 22:35:56 maximum-speed = "full-speed"; Aug 05 22:36:02 oh, nice, thanks Aug 05 22:36:42 it won't save you if you get dreaded vbus errors though Aug 05 22:37:54 haven't seen the pocketbone project thing before... Aug 05 22:38:57 it seems a bit misguided to me (sorry jkridner :P ) Aug 05 22:39:12 the USB subsection of my board is an optional one. Worst case I wire it's power system into a known working USB hub (per port current monitoring) and should be all good Aug 05 22:40:26 a while back i tried designing a hand solderable AM3358 board using FPC but... uh... turns out the anular ring and size of the hole required to pass the BGA ball through made routing impossible Aug 05 22:40:53 it probably would've also failed miserably... but it seemed like such a good idea at the time Aug 05 22:41:16 http://koti.kapsi.fi/jahonen/Electronics/Stuff/BGA_rework.jpg Aug 05 22:45:36 I've done stuff like that; wirewrap wire is great, when you glue it into flat sets it's almost exactly 0.5mm pitch Aug 05 22:45:38 there's also a guy who deadbugged a 484-BGA FPGA (with decoupling caps soldered directly onto the bga) Aug 05 22:46:02 but i haven't done anything more than a very small BGA Aug 05 22:48:13 I personally only rarely wield a soldering iron, I leave the hard stuff to other people ;) Aug 05 22:49:03 I know people are creative though, like when you see someone referring to their "reflow toaster" Aug 05 22:49:09 http://imgur.com/USDigSI Aug 05 22:49:40 heh, yikes Aug 05 22:51:18 i did that a long time ago though Aug 05 22:52:19 I think nowadays custom pcbs have become way too cheap to justify this kind of effort Aug 05 22:52:35 absolutely Aug 05 22:52:50 that took me something like 14 hours to do... I can ALMOST get a PCB that fast Aug 05 22:53:12 there's a local place that if you spend enough they'll get you a board in 23 hours Aug 05 22:54:09 hurry is always costly Aug 05 22:57:23 speaking of things that always frustrates me though... async complex communications between UI, control and an arbitrary socket... Aug 05 23:05:31 I see fun topics there indeed Aug 05 23:21:44 this is disturbing... http://blog.regehr.org/archives/161 Aug 06 01:13:15 hello, quick q -- im writing a driver for the am335x's LCD controller. i am trying to choose between LIDD or raster mode Aug 06 01:13:30 for most large (1024x1280+) LCD displays, which mode should i use? Aug 06 02:56:26 kremlin: given that they're completely different protocols, using the one your lcd display understands would be a good idea :P but almost certainly that will be raster mode Aug 06 02:56:53 zmatt: thanks, that is what i was looking for Aug 06 02:56:56 LIDD is used for displays with built-in framebuffer, e.g. character displays Aug 06 02:57:01 gotcha Aug 06 02:57:19 i am looking to target the more common 1080/720 pixel wide displays Aug 06 02:57:46 i really am not looking forward to writing i2c TDA19988 driver... Aug 06 02:58:10 ah you're interfacing via HDMI, then *definitely* raster Aug 06 02:58:16 the "no on-chip EDID prober" design was a baaaaad idea Aug 06 02:58:18 gotcha Aug 06 02:58:23 also you'll need non-obvious settings Aug 06 02:58:30 oh? Aug 06 02:59:30 iirc there's something about the hsync timing from LCDC not being directly suitable for HDMI, hence linux programs the tda19988 to reconstruct it **** ENDING LOGGING AT Sat Aug 06 02:59:58 2016