**** BEGIN LOGGING AT Sat Sep 12 02:59:58 2015 Sep 12 03:28:49 hey jkridner, are you online? Sep 12 05:17:39 need hlp Sep 12 05:27:07 help with what? Sep 12 05:27:10 http://www.catb.org/esr/faqs/smart-questions.html Sep 12 05:37:06 i have a beaglebone rev 45 Sep 12 05:37:34 i can connect to vnc)? Sep 12 05:38:25 for devian 7 Sep 12 05:41:18 Hi Sep 12 05:43:07 i have a beaglebone rev 45 ,i can connect to vnc)? Sep 12 05:43:10 hi Sep 12 06:12:24 so... I just got given a black to play with - but I can't figure this thing out.... Sep 12 06:12:43 It boots via the onboard flash, and I can get to its ethernet IP and get the splash page Sep 12 06:12:53 but SSH'ing in, I get a connection terminated. Sep 12 06:13:08 I also don't have any way to format / reimage a microSD card right now Sep 12 06:13:26 so I was going to boot via the eMMC, see if I can write to the microSD from within that Sep 12 06:13:40 then reboot to flash the eMMC with the latest debian console only download Sep 12 06:14:18 I found a whole heap of stuff that mentions cloud9 on port 3000 - but that port doesn't seem to be open on my setup... only 22 / 80 / 443 Sep 12 06:14:42 mh, hard to tell what's going on. do you know which software it runs? Sep 12 06:14:54 do you have a 3.3V UART adapter? Sep 12 06:14:55 I got given it second hand - so not quite sure Sep 12 06:15:12 the site I see shows: Sep 12 06:15:13 Your board is connected! Sep 12 06:15:14 BeagleBone Black rev 0A5C S/N 2513BBBK4978 at 10.1.1.176 Sep 12 06:15:35 hmmmm - not sure... can I get to something via the USB socket? Sep 12 06:15:49 I do get a COM port when I plug it into my windows system Sep 12 06:15:52 right, you could try to get in via cdc-acm Sep 12 06:16:03 but I don't seem to get in via 9600/8/n/1 etc Sep 12 06:16:05 yes, use an terminal emulator with it Sep 12 06:16:24 try 115200, although it shouldn't matter Sep 12 06:17:19 hmmmm Sep 12 06:17:50 just waiting for it to finish flashing its USR leds...... Sep 12 06:18:11 they will always flash to a degree Sep 12 06:18:18 they indicate system activity Sep 12 06:18:38 yeah - looks almost done now.... they're not ON ;) Sep 12 06:18:51 interesting, I don't get a COM now :\ Sep 12 06:18:59 the usb serial should have something after it's fully booted Sep 12 06:19:07 wait - here we go... COM4 Sep 12 06:19:15 ah ha Sep 12 06:19:32 ok, so got a console now Sep 12 06:20:29 ssh startup was broken in some version long ago Sep 12 06:20:48 so if you have a microsd, you might want to reflash it Sep 12 06:20:54 rm /etc/dropbear/dropbear_rsa_host_key && /etc/init.d/dropbear stop && /etc/init.d/dropbear start Sep 12 06:20:57 that's better. Sep 12 06:21:08 so, I'm looking at putting the debian console on the emmc Sep 12 06:21:22 I downloaded: BBB-eMMC-flasher-debian-7.8-console-armhf-2015-03-01-2gb.img.xz Sep 12 06:21:44 can I flash that via the beagle? due to not having an adapter that works with this 8Gb MicroSD :\ Sep 12 06:22:00 you might be able to do that, yes Sep 12 06:22:28 try sticking in the card and poking /dev/mmc?blk with fdisk to see which one is the emmc Sep 12 06:23:27 everything starts with /dev/mmcblk0 Sep 12 06:23:35 that seems wrong/ Sep 12 06:23:36 ? Sep 12 06:24:27 nothing seems to appear in /dev when I plug in the MicroSD? :\ Sep 12 06:24:32 nothing in dmesg either Sep 12 06:24:55 try rebooting with the card inserted (that might fail alltogether though, depending on the U-Boot) Sep 12 06:25:05 always the way ;) Sep 12 06:25:46 well, at least I should be able to SSH in after a reboot as well Sep 12 06:26:47 See, now I get a "ELMO GMAS (COM5)" detected, but when I connect to it, I don't get any prompt Sep 12 06:27:10 that might be the ROM Bootloader Sep 12 06:28:05 nothing in my DHCP logs to say it got a network address either :\ Sep 12 06:28:18 LEDs? Sep 12 06:28:36 heartbeat + naybe a CPU one flickering? Sep 12 06:28:58 hmm, then it should be past u-boot Sep 12 06:29:19 so yeah - I'm not sure what is on the microSD at all Sep 12 06:29:26 hence I've been booting without it Sep 12 06:29:44 ah, it came with the board? Sep 12 06:29:57 yeah - but its all 'second hand' Sep 12 06:30:12 the guys at work have been mucking with it - so who knows what state its in Sep 12 06:30:15 yeah Sep 12 06:30:39 TBH, rewriting the card externally would be best Sep 12 06:30:46 it would be.... Sep 12 06:31:07 but i only have a MicroSD to mSD that doesn't work with SDHC cards Sep 12 06:31:20 and the microSD that was in this thing was 8Gb Sep 12 06:31:42 I've only got a 4Gb (also sdhc) and a 1Gb one Sep 12 06:31:48 whereas the image is 2Gb ;) Sep 12 06:31:55 Sep 12 06:32:04 you could try to trick things by inserting the microSD right after u-boot comes up Sep 12 06:32:22 how do I know uboot is up though? Sep 12 06:32:23 uboot is when all the leds light up solid one after another Sep 12 06:32:28 hmmmm Sep 12 06:33:50 woah Sep 12 06:33:59 opkg list-upgradable <-- shows a TON of stuff ;) Sep 12 06:34:15 don't Sep 12 06:34:21 oh? Sep 12 06:34:35 with angstrom large upgrades usually don't go well Sep 12 06:34:36 hmmm Sep 12 06:34:36 root@beaglebone:~# cat /etc/dogtag Sep 12 06:34:37 Cloud9 GNOME Image 2013.06.06 Sep 12 06:34:51 ancient image is ancient Sep 12 06:35:09 probably the stock one it came with Sep 12 06:35:35 likely Sep 12 06:35:53 ok - so I just plugged in the MicroSD when all 4 lights were on Sep 12 06:35:54 also I'm not sure what would limit your sd reader with sdhc cards Sep 12 06:36:12 I don't think the adapter is smart enough Sep 12 06:36:22 micro -> mini adapter? Sep 12 06:36:23 that's just a specification, the adapter shouldn't care Sep 12 06:40:30 hmmmm Sep 12 06:41:38 so, how can I poke this thing to say 'Hey, there's a card in there now?' :) Sep 12 06:44:01 does /boot/uEnv.txt have something to do with things? Sep 12 06:52:38 root@beaglebone:/etc/udev# lsblk Sep 12 06:52:38 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT Sep 12 06:52:38 mmcblk0boot0 179:8 0 1M 1 disk Sep 12 06:52:38 mmcblk0boot1 179:16 0 1M 1 disk Sep 12 06:52:38 mmcblk0 179:0 0 1.8G 0 disk Sep 12 06:52:40 |-mmcblk0p1 179:1 0 70.6M 0 part /media/BEAGLEBONE Sep 12 06:52:43 `-mmcblk0p2 179:2 0 1.7G 0 part / Sep 12 06:52:45 hmm - that's all I see :\ Sep 12 06:53:36 yeah, no card Sep 12 06:53:40 udevadm monitor doesn't show any events when I insert / remove the micro sd :\ Sep 12 06:53:57 I don't remember if there is a way to trigger a card detection on that kernel Sep 12 06:54:22 is it safe to update just the kernel via opkg? Sep 12 06:55:05 no idea. how about trying to stick in that 8G card into your reader and checking if the image writer sees it? Sep 12 06:55:58 lemme try a different laptop.... Sep 12 06:59:15 ohhhh Sep 12 06:59:17 it worked in this laptop Sep 12 06:59:25 flashy flashy Sep 12 07:00:14 I'm using rufus tbh though - it supports dd images etc :) Sep 12 07:02:26 woooo Sep 12 07:02:40 got a knight rider pattern going with the USR leds.... Sep 12 07:02:48 I guess that means its flashing the emmc? Sep 12 07:03:27 hi i have problem in u-boot loader in beagle bone black. Sep 12 07:03:29 http://pastebin.com/er6ag9zc Sep 12 07:04:28 Unable boot second stage boot loader beagle bone black. Sep 12 07:05:50 i have compiled debug mode in u-boot source code. Sep 12 07:07:32 it still shows spl:board_init_r() after it is hang Sep 12 07:08:38 what kind of problem in beagle bone black? Sep 12 08:43:24 well, good news... Debian is installed on the eMMC and everything is happy :) Sep 12 08:43:29 glad its only a 200Mb install Sep 12 08:43:31 and that includes perl Sep 12 08:43:43 which is a BIG win for me (I only really write stuff in perl) Sep 12 09:00:51 CRCinAU: glad you got it sorted Sep 12 09:16:49 tbr: me too :) Sep 12 10:23:52 Hi People. I am not sure if this is a FreeBSD, a BBB, or a JTAG issue. I am using an application called screen to connect to a BBB running FreeBSD. I use it to watch the BBB boot, log in, and to get the IP Address. Whenever I exit screen, the BBB seems to stop responding. Does anyone have any ideas why it would? Sep 12 14:47:07 can someone point me to the location in the custom kernel for bbb the i2c0 is allocated/used for 1) the HDMI driver (U11) and 2) the board ID eeprom (U7)? Sep 12 14:48:40 https://github.com/beagleboard/linux.git Sep 12 14:49:14 i've been grepping around and don't see anything specific to these devices using i2c0 as the search term Sep 12 15:42:15 ? Sep 12 17:32:50 Can the beagle board be repurpoused as a product ie, a robot or some other conusumer device and redold? Sep 12 17:35:10 the boards as sold by distributors are not intended for products. You can contact the companies producing those to place volume orders though. Sep 12 17:37:24 that would be seeed, element14 and I guess CCo Sep 12 17:37:32 seed? Sep 12 17:37:54 the board I ordered came in from element14 Sep 12 17:38:21 say I want to use it as the brains of a household autonomous project for resale. Sep 12 17:38:44 not sure on the legalities Sep 12 17:42:06 http://www.seeedstudio.com/depot/BeagleBone-Green-p-2504.html?cPath=122_113 Sep 12 17:43:00 As said, talk to the companies producing the boards if you need boards for commercial use Sep 12 19:06:24 My BBB isn't detected from Arch Linux, even after udev script instalation. What can't be wrong? Sep 12 19:07:53 what are you running on the board? Sep 12 19:12:22 tbr: probably standard debian. Long time ago I was using SD card (with arch) but now, without SD it should boot to emmc debian Sep 12 19:12:47 tbr: after power up, I see it reads from eMMC, then I see heartbeat Sep 12 19:13:16 you try to aceess it over USB? did you try ethernet? Sep 12 19:13:41 lack of usb gadget support in your kernel Sep 12 19:15:03 hoijui: I was trying with ethernet, now USB. I couldn't connect through ethernet either Sep 12 19:15:29 veremit: oh, really? I had no problem with BBB some time ago, with older kernel, also arch:) Sep 12 19:15:57 do you still have an SD card? Sep 12 19:16:46 hoijui: nope Sep 12 19:17:27 mmmm Sep 12 19:17:54 i used BBBlfs a few times to flash the BBB over the USB cable Sep 12 19:18:02 maybe you want to try that Sep 12 19:19:24 hoijui: is it even possible to flash something over USB cable if I can't connect to the device over the USB cable? :> Sep 12 19:20:29 if it shows up when in ROMBL, yes Sep 12 19:20:34 i am new to BBB, so i dont know... i just know you need to press the BOOT button on the BB when you put power to it Sep 12 19:20:53 that's for booting from SD Sep 12 19:21:07 .. so i guess it does not use what is on the eMMC for that Sep 12 19:21:21 it is also for flashing over BBBlfs Sep 12 19:22:10 I'll try to install some additional packages for usb support, will see Sep 12 20:09:27 can someone point me to the location in the custom kernel for bbb (https://github.com/beagleboard/linux.git) where i2c0 is allocated/used for 1) the HDMI driver (U11) and 2) the board ID eeprom (U7)? Sep 12 20:09:35 i've been grepping around and don't see anything specific to these devices using i2c0 as the search term Sep 12 20:14:13 did you look at the BBB specific commits? Sep 12 20:14:28 or the current state? Sep 12 20:16:09 i'm on branch 4.1 Sep 12 20:18:13 hoijui: should i be looking at a specific tag? Sep 12 20:19:43 yates, sorry, i have no idea about this stuff, just though this might help (as none of the knowledgable people here seems to be... here/listening right now) Sep 12 20:21:38 hoijui: hey, i appreciate it. your ideas help me think things through. by the way, "git describe --tags" says i'm on tag 4.1.6-ti-r14 Sep 12 20:22:51 :-) Sep 12 20:27:08 is it more that the kernel "grabs" all 4 (?) i2cs on the AM3359 and exposes them through the devfs (/dev/i2c-x), and that something else (non-kernel code) in the boot process handles talking to these chips through the devfs? Sep 12 23:25:53 what's the easiest way to disable the cape mechanism on a bbb, so that i2c2 is left unused and another application may take control of it? Sep 12 23:26:20 use a main dtb with omits bone_capemgr Sep 12 23:27:13 (and if you still want to use overlays, use a 4.x kernel which has mainline support for them) Sep 12 23:31:23 zmatt: did you mean a main dts file (pre-compiled)? Sep 12 23:33:15 there are a whole bunch of .dts files in the 4.1 kernel. 1) which arch subdirectory is the bbb? and 2) which .dts is the "main" dts? Sep 12 23:34:35 fyi, i'm looking on the 4.1 branch of https://github.com/beagleboard/linux.git Sep 12 23:35:43 is it arch/arm/boot/dts/am335x-boneblack-overlay.dts? Sep 12 23:51:26 hi Sep 12 23:51:29 what is the actual latest, stable branch or tag for the bbb? Sep 12 23:51:55 i get this list from the current repo: http://ur1.ca/nrmdj -> http://paste.fedoraproject.org/266591/10190414 Sep 12 23:55:49 yates: hold beagleboard/linux is not the right repo Sep 12 23:56:22 https://github.com/RobertCNelson/linux-stable-rcn-ee/releases Sep 12 23:56:51 there you can the source trees for rcn-ee's releases (not just the -bone kernels) Sep 12 23:57:39 zmatt: ok, wow, thanks alot. i'll take a look Sep 12 23:58:04 note that it's not really a linear git repo: each release is made by some scripts that apply a bunch of patches Sep 12 23:58:53 so it looks like https://github.com/beagleboard/linux.git is where the real-time development work is done, and at release intervals they update the https://github.com/RobertCNelson/linux-stable-rcn-ee/releases ? Sep 12 23:59:08 no Sep 12 23:59:27 for one, beagleboard != beaglebone Sep 12 23:59:57 * yates facepalms Sep 13 00:00:21 is there a rock i can crawl under? Sep 13 00:00:25 hmm, also I thought beagleboard/linux wasn't being updated at all anymore, but it seems now it is again Sep 13 00:00:52 this is the old generation board? is it what they call the beaglebone white? Sep 13 00:01:23 zmatt: yeah, i just fetched some changes that happened in the last couple of days. Sep 13 00:01:49 there's the original beagleboard (omap35xx), beagleboard-xM (dm37xx), beaglebone white (am335x r1), beaglebone black (am335x r2), and upcoming beagleboard-x15 (am572x) Sep 13 00:02:15 for beaglebone the two most relevant repos afaik are: Sep 13 00:02:44 https://github.com/RobertCNelson/bb-kernel/releases # build scripts and patches, for if you want to (re)build your own kernel based on a -bone kernel Sep 13 00:03:03 ok, please go on. Sep 13 00:03:22 and the one I previously linked to, which contains the effective source tree as produced by the scripts Sep 13 00:03:38 why do you mean by the term "source tree"? Sep 13 00:03:44 s/why/what/ Sep 13 00:04:48 just the directory tree? Sep 13 00:05:16 well, just look at Sep 13 00:05:17 https://github.com/RobertCNelson/bb-kernel/tree/4.2-bone2 Sep 13 00:05:19 versus Sep 13 00:05:22 https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.2-bone2 Sep 13 00:05:29 and it should be clear what i mean Sep 13 00:09:06 there's also https://github.com/RobertCNelson/stable-kernel which appears to be the similar to bb-kernel but I think for the older beagleboards Sep 13 00:09:31 https://github.com/RobertCNelson/linux-dev is afaik the main development repo for all of these Sep 13 00:10:49 rcn-ee should really make a short overview of all these repos and how they interrelate and put it up somewhere Sep 13 00:11:10 yes! Sep 13 00:11:59 but, back to your original question Sep 13 00:12:20 what's the difference between https://github.com/RobertCNelson/bb-kernel/tree/4.2-bone2 and https://github.com/RobertCNelson/linux-dev? they're both a repo of scripts to build the kernel, right? Sep 13 00:12:40 linux-dev is devel, and by default won't build a -bone kernel Sep 13 00:13:07 ah, ok. Sep 13 00:14:58 while if you do ./build_deb.sh in bb-kernel tag 4.2-bone2 (branch am33x-v4.2) you should get a linux-image-4.2.0-bone2 debian package similar to the one you get rcn-ee's debian repository Sep 13 00:15:10 *get from Sep 13 00:15:47 ha. Sep 13 00:16:04 i was just goign to ask you about building the entire img (rootfs and all) Sep 13 00:16:24 also useful link to have: https://rcn-ee.com/rootfs/bb.org/testing/ various recent rootfs images Sep 13 00:16:38 but I don't know what scripts he uses for them, I've never build one from scratch Sep 13 00:17:30 I just take a minimalistic console image, install the stuff I want, and them use that beaglebone as a template (taking care to avoid copying things like ssh host keys etc) Sep 13 00:17:40 i saw somewhere where he had a few choices, like a very small rootfs Sep 13 00:17:52 console is the most basic one Sep 13 00:18:08 are these scripts for crossbuilding, e.g., under fedora? Sep 13 00:18:19 although even there some useless packages snuck in last time I checked ;) Sep 13 00:18:26 no these are simply the output images Sep 13 00:18:36 I don't know anything about the build scripts for them Sep 13 00:19:26 so, original question... Sep 13 00:19:29 ok Sep 13 00:19:45 https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.2-bone2/arch/arm/boot/dts shows a couple of am335x-boneblack*.dts flavors Sep 13 00:20:43 nearly all seem to include capemgr Sep 13 00:22:49 it seems that's no universal dts for boneblack+eMMC without bone capemgr Sep 13 00:23:09 *generic dts Sep 13 00:23:29 I should avoid the word "universal" since it's used for the hideous "universal overlay" :P Sep 13 00:23:47 lol - hideous. Sep 13 00:24:42 but look at am335x-cape-bbb-exp-r.dts for example Sep 13 00:24:54 ok, excellent. thanks much, zmatt. Sep 13 00:25:07 or better yet Sep 13 00:25:32 fyi, we're spinning our own custom board and throwing away some of the hardware we don't need (like the video driver 19988, etc.) Sep 13 00:26:21 and my job is to see what that is goign to screw up and / or if we can fix it in software. Sep 13 00:27:10 just look at the various am335x-boneblack*.dts files Sep 13 00:27:22 right Sep 13 00:27:27 but basically you need am335x-bone-common-no-capemgr.dtsi Sep 13 00:27:41 and two dtsi files for eMMC Sep 13 00:27:48 (that's normally a "virtual cape") Sep 13 00:28:41 zmatt: when are these (compiled) overlays loaded? at boot time? after uboot? Sep 13 00:28:42 I don't really understand why am335x-bone-common-no-capemgr.dtsi is so much copy-pastework instead of just including one in the other Sep 13 00:29:11 uboot loads the kernel, initrd, and dtb and then executes the kernel with initrd and dtb as arguments Sep 13 00:29:17 actually Sep 13 00:29:45 it unpacks the device tree, patches some things, and then passes that to the kernel Sep 13 00:30:08 for example the /memory is filled in by u-boot Sep 13 00:30:26 another thing we're doing is throwing away the EEPROM on I2C0. do you think that's going to hang the boot? Sep 13 00:30:31 yes Sep 13 00:30:35 but Sep 13 00:30:41 easy to patch in u-boot Sep 13 00:31:07 it reads the board type from it and tests for that in various places Sep 13 00:31:15 replace by hardcoded board type Sep 13 00:31:25 right. let me quit asking stupid questions and do some research. thanks a BUNCH! Sep 13 00:31:47 btw, a useful thing to know if you make derivatives of device-trees Sep 13 00:31:52 and I think not well known Sep 13 00:32:00 * yates is all ears Sep 13 00:32:55 usually every chunk of device tree source just adds nodes (if not already exist) and adds/replaces properties Sep 13 00:33:35 yeah, what creates the "root device tree"? Sep 13 00:33:48 the first chunk of a dts Sep 13 00:33:53 always begins with / { Sep 13 00:34:12 but, little-known is that you can also delete nodes/properties that were previously defined Sep 13 00:34:15 like Sep 13 00:34:18 { Sep 13 00:34:24 /delete-node/ bone_capemgr; Sep 13 00:34:24 } Sep 13 00:35:42 (just taking an example here, you should actually remove bone_capemgr by not introducing it in the first place since there's more to it than just the /bone_capemgr node, there's also the i2c stuff which is elsewhere in the dts) Sep 13 00:35:56 similarly there's a /delete-property/ directive Sep 13 00:36:05 ok. but wouldn't it be better to just modify whatever .dts so the node is not created in the first place/ Sep 13 00:36:07 yeah. Sep 13 00:36:18 ? Sep 13 00:36:28 s&/&?& Sep 13 00:36:29 yes but sometimes a dtsi will configure sensible defaults Sep 13 00:36:43 with an exception or two? Sep 13 00:36:47 but in some cases you may want to override that Sep 13 00:37:01 and in some cases overriding would consist of deleting a property Sep 13 00:37:37 like bone-common has &tps { ti,pmic-shutdown-controller; }; Sep 13 00:38:04 which makes sure that upon shutdown the pmic does into OFF-state rather than SLEEP-state (aka "RTC-only mode") Sep 13 00:38:28 where is it defined which .dts files are used? is it in a uboot script or in some C source? Sep 13 00:38:47 if you made really really sure that your board is compatible with RTC-only mode then you could override bone-common by deleting that property Sep 13 00:39:16 (see comments in bone-common for details, if you actually happen to care about RTC-only mode) Sep 13 00:39:48 startup script of u-boot Sep 13 00:40:01 and, indirectly, /boot/uEnv.sh Sep 13 00:40:12 what else would there be? (besides RTC)? Sep 13 00:40:22 hmm? Sep 13 00:40:50 RTC-only mode. i don't understand what that's about. Sep 13 00:41:04 i know there's the RTC in the AM335x Sep 13 00:41:09 RTC-only mode means the whole system is off but the RTC remains powered Sep 13 00:41:16 so you don't lose your date & time settings Sep 13 00:41:45 well, we need to wake up every N seconds (about 12 hours) Sep 13 00:42:31 are you running on battery power? Sep 13 00:44:36 either way, I'd say use suspend to RAM, then the RTC also remains operational Sep 13 00:46:01 yes Sep 13 00:46:31 we have two modes, one we're connected to a power source and don't care about power, the other is minimizing energy on a battery Sep 13 00:47:24 yeah, but ram has to stay powered on, right? Sep 13 00:47:47 is it minimal draw when not changing? Sep 13 00:48:02 ram draw low but non-negligible power Sep 13 00:49:49 the alternative is save some state and shutdown (or suspend-to-disk, although flash won't like that) and use an external RTC to power up the system again Sep 13 00:50:11 we're trying to run for at least 30 days on a 5AH battery Sep 13 00:50:11 there are RTCs that draw typical 0.15 μA Sep 13 00:50:30 there's an rta in the AM335x right? Sep 13 00:50:32 rtc Sep 13 00:50:42 yes, you can also use that Sep 13 00:50:43 but Sep 13 00:50:53 you'll need to fix the power supply scheme of the beaglebone Sep 13 00:51:00 oh? Sep 13 00:51:02 fix??? Sep 13 00:51:09 repair? Sep 13 00:51:16 yes, it's buggy in all releases Sep 13 00:51:21 different bugs though Sep 13 00:51:22 ah shit. Sep 13 00:51:42 the PMIC is also buggy, especially if no battery power is present Sep 13 00:52:14 you mean the TPS65217c? Sep 13 00:52:37 i didn't want to hear this... Sep 13 00:52:50 yeah, use a TPS65217d if you have the choice (the c defaults to ddr3, reconfigured to ddr3l by u-boot. the d defaults to ddr3l) Sep 13 00:53:10 the TPS bugs seems to disappear however if a battery is used Sep 13 00:53:39 you mean on pins 4,5 ? Sep 13 00:53:45 BAT, BATMON, TS Sep 13 00:54:04 although even that's kinda suboptimal Sep 13 00:54:21 BATMON == BAT_SENSE? Sep 13 00:54:44 since you have no indication of consumption, remaining charge, etc Sep 13 00:54:48 yes Sep 13 00:55:27 i think we're going to do our own battery state algorithm Sep 13 00:55:52 coloumb counting or whatnot Sep 13 00:56:46 yeah, measure or estimate the current, integrate over time Sep 13 00:57:09 anyhow, the main issues with power on the bbb are: Sep 13 00:57:34 1. multiple 3.3V power domains which are not properly sequenced Sep 13 00:58:02 let me preempt this with, "but it works!" Sep 13 00:58:12 2. cpu pin "VDDS" is connected to LDO1 instead of LDO3 -- there's still a not-placed resistor to undo that Sep 13 00:58:34 let me add to that "for now" Sep 13 00:58:51 but without fixes, RTC-only mode will draw a lot of current Sep 13 01:00:30 some of my findings can btw be found at: Sep 13 01:01:39 http://elinux.org/BeagleBone_Power_Management Sep 13 01:01:48 https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/3vFMPydR20IJ and follow-up posts Sep 13 01:02:58 cool - thank you! Sep 13 01:03:47 also, while changing things, consider using a GPIO for the ethernet PHY reset to avoid this -> https://groups.google.com/forum/#!topic/beagleboard/9mctrG26Mc8%5B1-25%5D Sep 13 01:04:15 more power stuff: Sep 13 01:04:16 https://groups.google.com/d/msg/beaglebone/CKuTbHepHYE/qCEuTD5bGcsJ Sep 13 01:05:22 that also contains a link to a TI support question (never answered) about VDDS: Sep 13 01:05:26 https://e2e.ti.com/support/arm/sitara_arm/f/791/t/421756 Sep 13 01:06:14 would any of this change with the AM3352 instead of the AM3359? Sep 13 01:06:21 that's what we're using Sep 13 01:06:36 "this" meaning just about anything we've discussed tonight. Sep 13 01:06:37 no, same cpu, just some features disabled Sep 13 01:07:14 all AM335x varieties are basically just "speed/feature bins" based on factory testing Sep 13 01:07:23 the die revision however *is* important Sep 13 01:07:35 yeah, figured. Sep 13 01:07:36 you need rev 2.1 (die code 'B') Sep 13 01:07:54 you mean the latest? Sep 13 01:08:10 yes Sep 13 01:08:35 got it. Sep 13 01:08:45 or maybe rev A works too, would need to check the errata, but rev A has completely broken rtc-only mode Sep 13 01:08:48 eh Sep 13 01:08:48 rev 0 Sep 13 01:09:02 rev 1 / die code I mean Sep 13 01:09:16 so annoying they don't use die code 'A' for the initial release Sep 13 01:12:51 reducing power consumption is probably also going to be a "fun" exercise Sep 13 01:13:13 lots and lots of little tuning knobs that probably nobody ever really looked at Sep 13 01:13:22 oh boy. Sep 13 01:13:38 while i've got your attention, lemme ask something else... Sep 13 01:17:33 have you ever used one of Telit's cellular modules with linux? e.g., an LE910? it appears that with a usb connection to it and the libqmi library you can get a network interface pretty easily. Sep 13 01:21:39 the other method seems to be using pppd and chat over the serial port. Sep 13 01:21:51 do you know of any preferences? Sep 13 01:25:15 try finding an SDIO module that has a linux driver Sep 13 01:25:21 mmc2 is still entirely available Sep 13 01:25:27 usb is buggy as shit Sep 13 01:25:41 and ppp over serial... oh come on Sep 13 01:25:49 ? Sep 13 01:26:00 I think TI WiLink interfaces over sdio Sep 13 01:26:48 our hardware is already chosen and set in stone. Sep 13 01:30:47 ok, you're aware for example that USB DMA support is disabled in the kernel due to bugs? Sep 13 01:32:10 no.... Sep 13 01:32:29 the hardware is actually designed for USB OTG ... so it's more an USB peripheral (gadget) controller that also happens to be able to act as an USB host Sep 13 01:32:53 supporting Sep 13 01:33:19 supporting multiple devices via a hub (which is optional for OTG) is even worse Sep 13 01:33:38 we're just talking to one device: the le910 Sep 13 01:33:46 that will hopefully help Sep 13 01:33:55 and might even mean you can enable DMA support Sep 13 01:34:01 actually we're not even using a connector, just wireing up DM, DP, and sense Sep 13 01:34:15 and ID (to ground) Sep 13 01:34:27 yes Sep 13 01:35:30 so we'll fire up our first board and it's just gonna work, right? Sep 13 01:35:38 :) Sep 13 01:36:03 i tried convincing them to buy a JTAG, but they want to wait til we have a dead piece of hardware.. Sep 13 01:36:14 w.r.t. power supply scheme: if you have separate 3V3A and 3V3B rails like the BBB does, and you have a serial port buffer/isolater like the BBB does, connect that thing to 3V3A !!!! Sep 13 01:36:42 absolutely include a JTAG port (TI-14 is easier to find connectors and cables than cTI-20) Sep 13 01:37:03 and get an XDS100v2 adapter.. they're dirt cheap Sep 13 01:37:42 we were going to go with a \href{https://www.segger.com/j-link-plus.html}{Segger J-Link PLUS} & \$598 USD\\ Sep 13 01:38:09 I've heard that name before but never used it Sep 13 01:39:03 also, actually, put a cTI-20 header on the board... the headers are not particularly expensive afaik and for example the XDS100v2 usually includes an adapter to connect to cTI-20 Sep 13 01:39:57 having EMU0-4 available rather than just EMU0-1 means that in theory you can get reasonable bandwidth real-time trace data export, though I don't know anyone who's ever tried (let alone succeeded) to get that to work Sep 13 01:40:49 but debugging fresh hardware or a custom bootloader without jtag is hell Sep 13 01:41:28 well, it'll be a two day delay to order the part and get it in. Sep 13 01:41:41 also, unless you copied the DDR3L layout verbatim (include trace widths/distances, distances from signal layer to ground place, etc etc) you should run the ddr3l leveling program Sep 13 01:42:09 which you upload via jtag Sep 13 01:42:20 huh? Sep 13 01:42:36 this is a program you run on the am335x? Sep 13 01:42:55 yes, it experimentally determines optimal leveling values Sep 13 01:43:01 we did not, btw, it's a new board, 8 layers i think Sep 13 01:43:03 since automatic hardware leveling support in the PHY is broken Sep 13 01:43:11 (the DDR3 PHY) Sep 13 01:43:28 what is levelling? Sep 13 01:43:33 leveling? Sep 13 01:44:04 i presume this is some software that "calibrates" ddr3 accesses somehow? Sep 13 01:44:22 never heard of such a thing. Sep 13 01:44:34 adjusting the timing of signals (in steps of 1/256 clock cycle) Sep 13 01:44:46 to account for pcb trace lengths and such Sep 13 01:45:10 do you have a link/reference for this? Sep 13 01:45:28 am335x is relatively simple since you usually only have one RAM chip, which greatly simplifies things Sep 13 01:46:18 two x8 RAM chips is already tricker, since then cmd/addr make a "fly-by" past the two RAM chips, so data signals for the second chip have to be slightly delayed compared to the first RAM chip (if pcb traces are equal) Sep 13 01:47:16 http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling Sep 13 01:47:24 thanks again. Sep 13 01:47:31 i sure am tellign you thanks a lot! Sep 13 01:48:35 ok, let me try to cobble this into a response to my boss. i don't think they're going to be happy - it's already been routed and they wanted to send it out to fab Monday. Sep 13 01:48:38 note that with pcb layout this means that you only have to keep trace lengths equal per command/data "macro", since each macro has configurable timing to compensate for pcb trace length Sep 13 01:49:10 I hope they have experience with working with high-speed signals like DDR3 Sep 13 01:49:32 i'm not sure. we have several guys on the team. Sep 13 01:50:08 the two data macros are simply the two byte lanes with associated dq/dqm Sep 13 01:50:33 the remaining signals are spread across three command macros in a bizarre way, see Control Module chapter of the AM335x TRM Sep 13 01:50:48 (there's probably some system in it, but I haven't discovered it yet) Sep 13 01:51:16 i'll hang out here but will be focusing on writing. thanks very much matt. Sep 13 01:53:23 one last time: since you probably have multiple voltage rails, pay really really close attention to power sequencing and the interaction between components in different power domains Sep 13 01:53:36 the BBB really screwed up some things there Sep 13 01:54:25 doesn't the TPS65217 handle that automagically? Sep 13 01:54:25 we're patching our BBBs to remove the separate regulator of the 3V3B and directly tied 3V3B to 3V3A Sep 13 01:54:58 (this patch or something similar is required for battery-powered operation) Sep 13 01:55:30 what do you mean by "patching"? is this a hardware change or software? Sep 13 01:55:52 nm Sep 13 01:55:56 stupid question. Sep 13 01:56:05 I mean https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/_oNSCta5WusJ Sep 13 01:57:33 the problem is that if two 3.3V domains have different sequencing, you get brief windows where one domain is powered up and the other is not Sep 13 01:57:57 those windows are excellent moments to violate absolute maximum ratings of components in the unpowered domain if you're not careful Sep 13 01:58:36 oh, so you're talking about the second 3V3B domain from the TL5209DR? Sep 13 01:58:50 the 3V3B regulator issue is discussed as length in this thread I linked to earlier: https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/3vFMPydR20IJ Sep 13 01:59:06 (pretty scope pics included) Sep 13 01:59:37 ok. Sep 13 01:59:54 btw, i've pretty much copied the last two hours of information into a file. Sep 13 02:00:00 wise Sep 13 02:00:05 2.5 Sep 13 02:00:56 did you see my pm question? Sep 13 02:01:07 also as I mentioned, for RTC-only mode you have to connect VDDS to LDO3 to LDO1 .. this was its original connect but TI issued an advisory to connect it to VDO1 instead... this has as side-effect it breaks rtc-only mode Sep 13 02:01:36 looking at the scope however I see significant leakage from VDDS to other rails during shutdown in this new configuration Sep 13 02:01:47 while no issues are visible if VDDS is connected to LDO3 Sep 13 02:02:05 I've asked TI for clarification ( https://e2e.ti.com/support/arm/sitara_arm/f/791/t/421756 ) but did not get any useful answer Sep 13 02:03:55 ok, let me get this into my report as well. Sep 13 02:04:12 i've got a half a night of writing to do... Sep 13 02:04:18 a prime example of wrong use of two power domains is in the console buffer/isolator, discussed here (same thread as earlier, later post) https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/V1Ft-xxh0agJ Sep 13 02:05:02 that showed apparently 45 mA being pumped into an unpowered IO of the AM335x Sep 13 02:05:13 (until I very quickly cut the supply) Sep 13 02:06:04 I should note that I've already seen 3 reports of people whose UART0_RXD pin started to exhibit erratic behaviour or died entirely after some time Sep 13 02:06:27 I would guess due to this Sep 13 02:06:55 now that i look at the power circuit, why is this second domain a problem? shouldn't SYS_5V comes up first and the VDD_3V3A input to U20 be inactive until VDD_3V3A fires up? Sep 13 02:07:14 (powering the console buffer/isolator from the 3V3A instead of 3V3B would have solved the problem btw) Sep 13 02:07:58 apart from the fact that using a power supply signal (which ramps up) as a digital logic input is a bit questionable, this configuration indeed works correctly at power up Sep 13 02:08:10 not so at power down however Sep 13 02:08:18 details are in the posts I linked to Sep 13 02:08:53 but short version: SYS_5V -> [regulator] -> 3v3b -> [leakage] -> 3v3a -> [enable input of regulator] Sep 13 02:09:42 ok. Sep 13 02:10:08 so instead of shutting down *before* 3v3a as it should (or at the same time at the latest) it stays on for way too long, or indefinitely if on battery power Sep 13 02:11:11 SYS_5V is btw of course a misnomer if you're running on a 3.6V li-ion Sep 13 02:11:55 (which itself may cause problems with usb) Sep 13 02:14:11 alternative is some external battery solution that provides 5V instead of using the PMIC's integrated battery charger (which only supports charging standard 3.6V/3.7V li-ion batteries) Sep 13 02:17:32 (benefit of having SYS_5V at lower voltage is reduced power consumption since all 1.8/3.3V supplies are made using regulators, downside is that you can only partially deplete the battery before voltage drops too low) Sep 13 02:19:37 note that 1.8V is really the preferred I/O voltage of the am335x, 3.3V is a concession for backwards compat (note that those supplies are labeled "VDDHV" -- High Voltage) Sep 13 02:20:00 beaglebone put everything on 3.3V for hobbyist convenience Sep 13 02:20:37 ok, enough rambling... Sep 13 02:48:11 *and backwards compat with peripherals that require 3.3V of course Sep 13 02:59:38 Anyone recently try to flash eMMC to latest version? I started the process over 4 hours ago.... I am afraid to turn it off and risk causing serious problems but at this point I think it isnt working **** ENDING LOGGING AT Sun Sep 13 02:59:58 2015