**** BEGIN LOGGING AT Thu Jul 07 02:59:59 2016 Jul 07 03:01:01 anyone know how to turn off framebuffer sleep from C? Jul 07 06:19:45 i need debian source code for beaglebone black Jul 07 06:20:09 any link is available Jul 07 06:23:07 sudoman: holding the SD button pressed changes the boot order from {eMMC, μSD, uart, usb} to {spi, μSD, usb, uart} Jul 07 06:23:36 sudoman: an attempt to boot from spi will leave the spi pins configured, that's why I labeled them "spi boot" in my script Jul 07 06:24:16 no no i need to create my own debian image for that i need that source code Jul 07 06:24:44 angu: as the "sudoman:" prefix shows, I wasn't replying to you Jul 07 06:25:40 Then who can reply to me Jul 07 06:25:44 your question is vague, but you may want to check https://eewiki.net/display/linuxonarm/BeagleBone+Black Jul 07 06:26:00 it describes the steps used to make the debian images Jul 07 06:26:42 sudoman: "echo into .../slots early in the boot process" did you check for errors? if you're too early it may simply not exist yet Jul 07 06:27:04 oh ok ok thank you so much Zmatt Jul 07 07:24:29 ahlllo Jul 07 07:49:52 hi, i'm using BBB with Simulink Embedded Coder Jul 07 07:50:14 I wrote a controller for a Ball on Wheel model Jul 07 07:50:40 now i have a problem with execute the cote on BBB Jul 07 07:51:41 the controller works for many seconds and sudently the ececution of the code interrupts for <1sec Jul 07 07:52:09 also no data is send to Simulink scope Jul 07 07:52:37 afterwards the controller starts agin but its to late and the ball falls down Jul 07 07:55:30 the designed controller works definately because i had it running on the same BoW-model and with the same parameters Jul 07 07:55:59 the answer to the question you didnt ask is.... no. Jul 07 08:02:48 Does somebody know this phenomenon Jul 07 08:03:00 and how can i avoid it Jul 07 08:05:57 I'd guess the program is run in user space where it yields to some other thread every now and then. Jul 07 08:06:26 Someone Else can point you to Real-time OSes and how to use them on BBB, I've no idea. Jul 07 08:08:11 Yes i think that the programm runs in user space Jul 07 08:08:41 can i priorise it ? Jul 07 08:09:47 8 Jul 07 08:09:51 sudo nice -n -20 ./program (or something like that). But it will still get interrupted every now and then. Jul 07 08:15:24 you can use an -rt kernel and give it real-time priority (SCHED_FIFO) Jul 07 08:15:53 you can also try to track down what's causing the significant interruption and deprioritize that Jul 07 08:16:07 (on -rt kernels that can even be done if the cause is an irq handler) Jul 07 08:16:42 your program should however not be cpu-bound for this Jul 07 08:18:07 i.e. it should operate on a timer or on external events Jul 07 08:23:06 hi zmatt Jul 07 08:23:23 is there a possibility to include it in my Simulink file Jul 07 08:27:11 "it" ? Jul 07 08:27:35 and my experience with simulink is very limited Jul 07 08:28:06 I mean can i configure some parameters at simulink to get a higer priority Jul 07 08:28:12 but iirc you can configure it to generate code that can be linked into an existing application Jul 07 08:29:37 be sure first that it's not trying to get 100% cpu load Jul 07 08:30:17 how can i do this? Jul 07 08:30:37 check with top for example Jul 07 08:32:16 you may also want to disable logging to emmc/sd since periodic flushes of data to slow storage would be my first guess what's causing periodic stalls (although I think it shouldn't stall an application that's not accessing mmc/sd but I've never verified this) Jul 07 08:35:20 (if you apt-get remove rsyslog and rm -rf /var/log/journal and then reboot then if all is well there should be no system logging to mmc anymore, you can still access the size-limited in-memory system log via journalctl) Jul 07 08:48:10 hi zmatt i have now removed syslog but still have the same issues Jul 07 08:49:47 i can adjust at simulink base rate task priority Jul 07 08:50:01 do u have some experince with that? Jul 07 08:50:35 have you checked cpu load? Jul 07 08:51:30 how can i do this? Jul 07 08:52:02 10:30 < zmatt> check with top for example Jul 07 08:55:30 can you explain top for me please Jul 07 08:55:45 i i never used it before Jul 07 08:56:08 should i use the serial conection for that Jul 07 08:56:45 ssh, serial, whichever you prefer Jul 07 08:59:33 top -o '%CPU' shows sorted by cpu usage Jul 07 09:00:59 ok i will try this Jul 07 09:14:14 hi my programm runs at very high cpu load Jul 07 09:14:26 >95% all the time Jul 07 09:14:48 well then there's your problem Jul 07 09:15:13 PR is rt Jul 07 09:15:26 that's an even bigger problem Jul 07 09:15:37 when combined with trying to get 100% cpu load Jul 07 09:16:17 a process running under an OS can't use up all cpu time, the OS needs some too Jul 07 09:16:37 so if you don't voluntarily give up cpu time often enough it'll be taken by force Jul 07 09:16:47 and you will have a lot less control over when and how long Jul 07 09:17:07 ok i see Jul 07 09:17:28 do you have an idea how to fix this? Jul 07 09:17:39 it's not a beaglebone question, it's a simulink question Jul 07 09:17:52 so you're not really in the right support channel for that Jul 07 09:18:51 i understand that but it really drives me crazy Jul 07 09:19:47 we might feel for you, but we can't tell you how to convince simulink to produce non-stupid code Jul 07 09:21:29 setting RT priority and then running fully cpu-bound normally would freeze the rest of your system and leave you unable to even kill the program other then by pressing the reset button; fortunately current linux versions have a safety mechanism to prevent that, but that's what's probably causing your pauses Jul 07 09:22:07 until the cpu loading is reduced to <90% it may actually run better *without* rt priority Jul 07 09:39:41 Hi, I'm trying to figure out why LCD7'0 worked fine on ti kernel and doesn't on bone kernel. The screen appears in the slots but I see nothing on the screen. User and pwr leds are working. Jul 07 09:39:52 It's seem the configuration with the dts didn't work. Jul 07 09:40:01 *it seems Jul 07 09:40:17 Can't see the pwm which controls the brightness (in /sys/class/pwm ) Jul 07 09:40:30 line compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green"; in dts Jul 07 09:40:35 Is this line mean that is only for ti kernel ? Jul 07 09:42:34 I know that there are dts allergic in this channel ;) but I still try Jul 07 09:43:54 Hi Jul 07 09:44:22 my first post here... just got a BBB C and tried to flash the eMMC with a flash version of Debian Jul 07 09:45:52 what I am getting on every attempt, using two different sd cards and both the latest and the next latest images, is the to-and-fro led lights for a few mins, then a pattern that is two flashes in quick succession followed by around a second pause, repeated constantly (the last one I left overnight) Jul 07 09:47:02 I am using osx on a MacBook air, so I used Disk Utility to prepare the sd card, and Apple Pi Baker to put the image on the sd card Jul 07 09:47:09 did you follow a tutorial ? Jul 07 09:47:14 yes Jul 07 09:47:42 the one on this site.. also looked at some youtube videos that also started from osx Jul 07 09:47:53 I read on this channel that there are some issues with osx but I don't have details Jul 07 09:48:00 before trying this I was able to ssh into the ångström that was originally there Jul 07 09:48:15 so I think it is a problem with the flashing process Jul 07 09:49:58 After each unsuccessful attempt, I have pulled out the 5v power cord (barrel), pushed down the button on the board, and put the power back in to reboot Jul 07 09:50:16 Will_: the all leds flashing pattern = failure Jul 07 09:50:37 so any pattern in which all leds flash is failure: ok Jul 07 09:50:48 to-and-fro means it's flashing, when done all leds should stay on iirc Jul 07 09:51:12 are you sure it's a rev C ? Jul 07 09:51:15 right - so if they start doing that pattern I described, I can assume failure and not wait to see if anything else will happen Jul 07 09:51:17 yes Jul 07 09:51:21 def rev Jul 07 09:51:22 c Jul 07 09:51:57 ok odd, the most common cause for failures to flash is trying to flash a 4gb image onto a 2gb emmc Jul 07 09:54:03 sorry just had to rejoin... thank you for the observation that the most common cause of flashing problems is trying to use a 4Gb image on a 2Gb board Jul 07 09:54:14 I will doublecheck that when I get home Jul 07 09:54:52 Presumably using a 2Gb image on a 4Gb board wouldn't be a problem Jul 07 10:04:20 no Jul 07 10:04:30 it means more free emmc space Jul 07 13:29:39 Hi everyone. A couple of hours ago someone kindly helped me with my problem flashing the emmc, suggesting it was 2Gb not 4Gb (which means I've picked up a board sold as rev C when it must be rev B, I suppose). Jul 07 13:29:56 It successfully flashed debian 2Gb version image Jul 07 13:30:03 my question now is about the password Jul 07 13:30:27 I have tried 'root' and just pressing return, and neither are letting me ssh Jul 07 13:31:56 it says in the terminal "default username:password is [debian:temppwd]" Jul 07 13:32:16 I have tried "debian:temppwd" and "temppwd" Jul 07 13:32:45 the user is debian the password is temppwd Jul 07 13:33:54 Got it. debian@... thanks. Jul 07 13:39:53 you can then 'sudo -i' Jul 07 15:16:20 zmatt: my problem regarding echoing into slots was the other way around. it only works if it's done by setting it in /etc/default/capemgr. i'm not sure why that is. perhaps there's an advantage to doing it early in the boot process. in any case, i think it should work later on too, so it seems like a bug. Jul 07 15:40:45 it should work later on yes, unless a conflicting overlay has been loaded Jul 07 19:58:04 I have a question regarding PWM frequencies on the beaglebone black. What are the maxiumum frequencies the PWM signals can operate at? I have an application that requires 50-200 KHz frequencies, and I'm assuming the beaglebone can demolish this. Jul 07 20:38:59 (yes, but you didn't stick around for the answer) Jul 07 20:43:01 But they are AHHappy. Jul 07 20:45:04 Allah is doing Jul 07 20:45:19 sun is not doing allah is doing Jul 07 20:45:28 moon is not doing Allah is doing Jul 07 20:45:36 stars are not doing Allah is doing Jul 07 20:45:47 planets are not doing Allah is doing Jul 07 20:46:00 That turd flower is here, too? Jul 07 20:46:09 galaxies are not doing Allah is doing Jul 07 20:46:40 oceans are not doing Allah is doing Jul 07 20:46:58 mountains are not doing Allah is doing Jul 07 20:47:07 trees are not doing Allah is doing Jul 07 20:47:15 mom is not doing Allah is doing Jul 07 20:47:29 dad is not doing Allah is doing Jul 07 20:47:33 Don't suppose an op is around to whack this moron? Jul 07 20:47:37 boss is not doing Allah is doing Jul 07 20:47:51 job is not doing Allah is doing Jul 07 20:48:01 dollar is not doing Allah is doing Jul 07 20:48:06 It's been on #arduino for some time, and it doesn't stop. Jul 07 20:48:15 degree is not doing allah is doing Jul 07 20:48:26 medicine is not doing Allah is doing Jul 07 20:48:35 We've actually programmed our channel bot to auto-quiet it. Jul 07 20:48:47 customers are not doing Allah is doing Jul 07 20:49:00 Fuck allah Jul 07 20:49:42 you can not get a job without the permission of allah Jul 07 20:49:46 Fuck allah Jul 07 20:50:04 you can not get married without the permission of allah Jul 07 20:50:07 Fuck allah Jul 07 20:50:21 * zmatt pokes av500 / _av500_ and jkridner Jul 07 20:50:29 [jadonk] ? Jul 07 20:50:35 ? Jul 07 20:50:51 \o/ Jul 07 20:51:03 :) Jul 07 20:51:44 Ragnorok might not have been SOOO out of place, but I still find that language unacceptable. Jul 07 20:51:59 zmatt: thanks for the poke Jul 07 20:52:53 yw Jul 07 20:52:54 let me know if we need more ops to keep this sort of nonsense out of here. Jul 07 20:54:05 * jkridner doesn't know how permanent a /kick is. Jul 07 21:08:30 hello friends Jul 07 21:26:45 I have BBB, ATX power supply and 3D printer cape (CRAMPS). I want to connect VDD_5V and 5VSB, software running power supply. at the same time 3v3 and 5v rails are connected to the ATX power supply, instead of the BBB. Is this correct? I am confused Page 113 SRM: "3) Do not apply any voltages that are generated from external sources." Jul 07 21:28:28 you supply the BBB with 5v, it generates all remaining supplies it needs Jul 07 21:28:45 you cannot supply the BBB with an external 3.3v Jul 07 21:33:28 I maybe not so expressed. Roughly speaking, the BBB is powered by 5vsb ATX and expansion card has on 3v3 and 5v by ATX. Jul 07 21:34:42 you need to be careful since the bbb does not tolerate voltage being applied to its I/Os unless it is powered up Jul 07 21:36:12 so the bbb would need to power up first, or at least any outputs from the cape to the bbb need to be 0V or high-impedance until the bbb has powered up Jul 07 21:39:03 This is why I want to use the ATX power supply, because it is enabled within the BBB and off earlier. about Fail-safe pins I know. formally 5vsb, 3v3 and 5c in the ATX power supply is different, and SRM is written that you can not do. Jul 07 21:41:41 and there is. 5vsb there when the power plug, and after the boot I turn the rest of the power supply units Jul 07 21:41:45 if the bbb controls the power supply and grounds are properly connected then there's no problem of course, it's not like it can label electrons to see where they came from Jul 07 21:42:37 in fact the 3.3v on the expansion headers is already different (vdd_3v3b) from the one supplying the processor I/O banks (vdd_3v3a) Jul 07 21:43:16 I am concerned about the applicability of the item "3) Do not apply any voltages that are generated from external sources." to this situation. Jul 07 21:43:42 it is an over-simplified warning Jul 07 21:46:17 my main worry would be whether the externally supplied voltages will power down sufficiently fast when the bbb shuts down Jul 07 21:50:32 I think so too, but I decided to ask the community. TL5209 operating current (3v3b) is not enough for my ideas in the future. I wanted to BBB worked constantly, and everything devices launched and shutdown from linux Jul 07 21:51:30 it is switched off before Jul 07 21:52:29 if you make sure of that then there's no problem... just be careful there aren't huge capacitors that take ages to drain Jul 07 21:52:50 I have a suspicion that the smaller load on 3v3b, the less chance to catch the bug Jul 07 21:53:15 what do you mean? Jul 07 21:55:16 https://groups.google.com/forum/#!topic/beaglebone/CKuTbHepHYE Jul 07 21:56:56 ah yes, but that concerns sudden loss of power Jul 07 21:57:34 if that happens you also don't have an opportunity to switch off the auxiliary 3.3v so you'd have bigger problems Jul 07 21:59:25 Some cards (one of the 650 or something so) have a bug where TL5209 off later than PMIC and leakage current is enough to make a broken SoC Jul 07 22:00:09 the TL5209 shuts down late on all BBBs Jul 07 22:00:31 it usually seems to avoid doing actual harm though Jul 07 22:01:14 large capacitor in 5vsb Jul 07 22:01:21 maybe Jul 07 22:01:44 probably since even when the TL5209 is on, reset is asserted to external components such as eMMC and ethernet phy which means they won't drive signals into the am335x I/O Jul 07 22:02:03 anyway has enhanced degradation Jul 07 22:02:23 there's only limited amounts of current injected via pull-up resistors into processor I/O Jul 07 22:02:48 unless you have components that drive hard signals powered by 3.3v, like the serial console buffer Jul 07 22:03:19 but most people don't usually have a serial cable connected, and without cable the pin is low Jul 07 22:03:41 STM1061xxxx Jul 07 22:04:38 you can also find more details (including links to other threads) here -> http://elinux.org/BeagleBone_Power_Management Jul 07 22:11:09 Yes, I was there. and the trade has read :) maybe install UPS? Jul 07 22:12:45 working with multiple power domains can be a headache, although it's not always difficult Jul 07 22:13:40 e.g. using open-drain/open-collector outputs and use a pull-up to the receiver's power supply is always safe Jul 07 22:16:45 one annoying detail there is that when the receiver is the bbb, the relevant power supply is actually non-trivial to access (it's vdd_3v3a, not vdd_3v3b) Jul 07 22:17:21 hence my workaround -> https://groups.google.com/forum/#!msg/beagleboard/7sxPePT7wkM/_oNSCta5WusJ Jul 07 22:17:24 ;) Jul 07 22:18:46 excellent method) Jul 07 22:23:14 ah the wire link bodge .. :D Jul 07 22:23:26 but in my case it is simpler to put the UPS. anyway to put it ... I looked oscilloscope pics from my board, and saw almost synchronous shutdown of 3v3a and 3v3b. the difference was about 300-400us. I think if TL5209 not load, then nothing will change. Jul 07 22:24:17 element14 BBB rev.C 4Gen Jul 07 22:24:19 that's actually weird, I saw 3v3b staying on noticably too long Jul 07 22:24:33 (on unpatched bbb) Jul 07 22:25:28 https://lh3.googleusercontent.com/-_xHMJGdwpTA/VUKJFjC8koI/AAAAAAAAACc/VmSqofhSmXM/s1600/off-dc-noserial.png Jul 07 22:26:34 https://pp.vk.me/c636828/v636828467/16f37/6F_R7nG9Z4g.jpg Jul 07 22:27:22 on signatures do not pay attention))) Jul 07 22:28:14 the scaling and vertical offsets make it really hard to tell what the timing is here Jul 07 22:29:42 do note that my pic looks like 3v3a actually tracks 3v3b (with an offset) during the initial part of its descent, which would suggest it's actually higher than it should as a result of leakage from 3v3b via I/Os Jul 07 22:32:22 with patch it falls much faster until it hovers around 1.4v due to leakage from vdds: http://elinux.org/File:Bbb-c-3v3u-shutdown-dc5v.png Jul 07 22:33:07 (note different scales in the two pics) Jul 07 22:38:35 the purple dashed line in off-dc-noserial.png is when the last pmic supply is switched off, but on unpatched bbb power consumption from vsys visibly continues for about 10 ms Jul 07 22:39:48 zmatt: you mean ;hardware patched; right?! :p Jul 07 22:40:15 yes, which I linked to about 20 min ago Jul 07 22:40:18 something about 8 ms and my and patched. and it is very similar, oddly enough. Jul 07 22:41:36 serega2net: note that this means the 3v3b actually switched off 18 ms after the 3v3a, which is really much too late Jul 07 22:42:18 the risk of damage is reduced however by the (otherwise idiotic) fact the pmic cuts power to vsys at the start of shutdown Jul 07 22:44:31 where 18 ms? oO Jul 07 22:45:19 from 3v3 to gnd? Jul 07 22:46:23 https://lh3.googleusercontent.com/-_xHMJGdwpTA/VUKJFjC8koI/AAAAAAAAACc/VmSqofhSmXM/s1600/off-dc-noserial.png from the dashed line where the 3v3a starts to drop to the point where 3v3b starts to diverge from vsys (labeled BAT), after which the latter levels out since no more power is drawn from it Jul 07 22:46:43 scale in that pic is 1 ms per minor division Jul 07 22:48:13 you can also see 3v3a is failing to fall to ground up to that point Jul 07 22:48:29 that's current being injected from 3v3b into 3v3a via cpu I/Os Jul 07 22:49:48 yes? i now it Jul 07 22:49:58 ?=. Jul 07 22:50:04 :) Jul 07 22:52:13 I see that with the patch first decline sharper than mine, but a complete 3v3 turn-off time is about the same Jul 07 22:55:52 well the final tail isn't really all that important, it is already below 1.5v there (note btw that in that pic horizontal scale is 2ms per major division) Jul 07 22:57:14 what matters is getting the 3.3v below 2v and avoiding strange current paths Jul 07 23:00:03 and not dropping too excessively fast... processors are fussy things :) Jul 07 23:01:20 (e.g., my bbb probably didn't appreciate this -> http://elinux.org/File:Bbb-c-3v3u-powercut-hdmi.png ) Jul 07 23:02:33 then again this abuse is done to bbbs all the time and they usually seem to cope Jul 07 23:03:57 My head really exploded :) judging by my pictures, I do 3v3 patch, or the current time off normally? Jul 07 23:04:52 maybe just worry less... in practice I've... well, actually seen plenty of BBBs die, but usually that's with accidents involving a high voltage line (>= 5v) Jul 07 23:05:50 well, clearly. thanks for info! Jul 07 23:07:06 to tie back to your original question, the main thing to avoid is driving an external voltage into BBB I/Os when it is off Jul 07 23:07:54 Yes, this is understandable Jul 07 23:08:48 since the cpu goes into reset (hence all gpios go high-impedance with default pull-up/down) about 3ms before that at shutdown, using a gpio to enable external supplies would be safe as long as it discharges quickly enough when disabled Jul 07 23:10:32 alternatively disabling/isolating external drivers would work too obviously Jul 07 23:11:48 in my case, at the time of shutdown the PMIC, 5v atx is three minutes as the off Jul 08 01:04:45 Hi People Jul 08 01:36:03 allo Jul 08 01:39:01 does anyone have any quick tips to get a BBB into a low power state as a PoC? e.g. disabling hdmi or eth Jul 08 01:42:16 have tried not loading the hdmi cape and lowering the cpu frequency which helps a little **** ENDING LOGGING AT Fri Jul 08 02:59:58 2016