**** BEGIN LOGGING AT Wed Nov 09 03:00:01 2016 Nov 09 04:40:59 tejas_: recompiling the kernel is pretty easy if you have some linux host system available, but if you want to experiment with a different cpuidle governor then yeah using cpuidle_sysfs_switch sounds easier Nov 09 04:41:06 Hi I am trying to boot an image of ubuntu core off a microsd card Nov 09 04:41:46 I believe I should pressed the S2 button for an extended time to trigger the cylon flashing pattern Nov 09 04:42:02 However, this hasnt work for me Nov 09 04:42:05 Any tips? Nov 09 04:43:43 elfgoh: the S2 button is sampled during power-on, you can let it go once the power led turns on. its purpose is to take eMMC out of the boot device order, effectively forcing the processor to boot from sd Nov 09 04:44:36 (beware that it is only sampled at power-on, it is not resampled at reset or reboot) Nov 09 04:45:01 if the sd card contains a flasher, then it should proceed to flash the system Nov 09 04:45:29 if it contains some other bootable system (including bootloader), it should boot that system Nov 09 04:45:34 zmatt : I have ubuntu 12.04. I am reading about cpuidle subsystem (this link is really good https://lwn.net/Articles/384146/) however how can I build a kernel in which cpuidle disabled. how can I "exactly "do it ? Nov 09 04:45:35 if it contains neither, nothing will happen Nov 09 04:47:23 tejas_: rcn has build scripts that recreate his kernels (as debian packages even), and before building it will give you a config menu to make your customizations. you can simply disable cpuidle there and then just wait until it has built and packaged your customized kernel Nov 09 04:49:15 zmatt: rcn-ee had given a link. My client doesn't happen to show it on scrolling up. can you please give it ? Nov 09 04:49:26 which kernel series? Nov 09 04:49:55 I am using pre-installed debian, I guess 3.8 Nov 09 04:50:46 oh wow that ancient... uhh, ok, 3.8-bone it is then Nov 09 04:52:35 actually I think in such distant history it might not have used debian packages for the kernel yet but just installed it separately, but the build scripts presumably still work Nov 09 04:53:23 if you have some particular problem with your kernel, have you tried first updating it to the latest 3.8-bone kernel? Nov 09 04:54:29 (3.8.13-bone81) Nov 09 04:54:32 uname -a shows beaglebone 3.8.3-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 arm71 GNU/Linux Nov 09 04:54:36 I am using the board BBGW but I faced the problem when I boot the board with new image Nov 09 04:54:42 zmatt: hmmmm i believe I did what you said. But after boot up, I find that I have a debian system. Could it be that my image isnt ubuntu, given that I didnt build the image myself? Nov 09 04:56:16 elfgoh : sure it can happen Nov 09 04:56:21 ah for some reason, this debian image seems to be from my emmc Nov 09 04:56:24 elfgoh: there are a few options: 1. you actually failed to hold the S2 button down during power up (it can happen easily, I speak from experience) 2. the bootloader on the uSD card helpfully detects the OS installed on eMMC and boots that instead of the OS on uSD (depends on u-boot config) Nov 09 04:57:10 option 1 is easy to eliminate: try it without any card inserted, it should not boot at all (only power led turns on), then insert the card and press the reset button Nov 09 04:57:40 So right now, I have removed my microsd card, and I deduced via the serial connection that a debian system is booted Nov 09 04:58:07 So my emmc has debian Nov 09 04:58:16 that's the default yes Nov 09 04:59:08 Ok. So I should turn off the power, put back the card, press S2 button and then turn on power again? Nov 09 05:00:07 yes. or if you want to be extra sure, try it without card and if it (correctly) fails to boot insert the card and press reset (don't power cycle) Nov 09 05:01:11 I see. Usually for powering off, I issue a poweroff command Nov 09 05:01:24 yeah, sudo poweroff, or just press the power button Nov 09 05:02:43 Ok so "try it without card and if it (correctly) fails to boot insert the card and press reset (don't power cycle" just shows an ever increasing ny=umber of C characters in my serial console Nov 09 05:02:53 Is that expected behaviour Nov 09 05:02:55 ? Nov 09 05:02:56 yes Nov 09 05:03:23 rom is cycling through four possible boot devices, one of which is xmodem via uart (seriously) Nov 09 05:03:32 Ok so how should I turn off the BBB now? Nov 09 05:03:36 don't Nov 09 05:03:41 Ah Nov 09 05:03:42 insert card, press reset button Nov 09 05:03:43 Ok Nov 09 05:03:45 I see Nov 09 05:03:52 or insert card and just w2ait Nov 09 05:03:54 *wait Nov 09 05:04:10 since rom is cycling through the boot devices anyway (one of which is uSD) Nov 09 05:04:40 Outstanding! I now have Ubuntu core booting! Nov 09 05:04:42 Thanks a lot~ Nov 09 05:04:50 (reset button may be needed when powering the bbb by connecting it via usb to a computer, since it may get stuck on usb boot) Nov 09 05:05:33 zmatt : I dont seem to have any problem with the kernel at all. I have a group of servers running on BBB. If my client app on other machine is not communicating with BBB frequently, or say after that it communicates after an interval of few hours, it doesn't respond (I often have to go for reboot, I never want to reboot). I want to check if it starts responding by working around cpuidle Nov 09 05:06:05 if you want to boot from uSD in the future, the simplest solution is eradicating the bootloader on eMMC Nov 09 05:06:09 #BBB doesnt respond Nov 09 05:06:38 tejas_: you're having a problem. you want to try diddling the kernel to fix it. conclusion: you in fact do at least suspect a problem with the kernel Nov 09 05:08:08 upgrading the kernel is easier than rebuilding a kernel, and if you build your own kernel then by default you get the latest version of the series anyway so it's better to upgrade first so you can distinguish between changes due to upgrade and changes due to customizing condif Nov 09 05:08:12 *config Nov 09 05:09:42 zmatt: any implications/considerations if I wanna eradicate the bootloader on the eMMC? Nov 09 05:09:58 Does that mean that I wont be able to boot debian by default then? Nov 09 05:11:14 elfgoh: it's not hard to fix if you'd want to. although, since the preinstalled debian inevitably lags behind the latest images you'd probably want to consider flashing a new image anyway Nov 09 05:11:33 (which would overwrite eMMC entirely, including bootloader) Nov 09 05:12:35 Yes. I agree that it is a small issue. Just wanted to be full aware of the implication Nov 09 05:12:38 it's a bit odd this is needed anyhow, normally the eMMC bootloader on eMMC would detect the OS on uSD and prefer to boot that, but maybe the version mismatch is too great or perhaps ubuntu does things differently in some significant way causing the debian bootloader to fail to boot it Nov 09 05:13:27 does eMMC have two partitions or one? (equivalently, was the debian on eMMC wheezy or jessie?) Nov 09 05:15:08 zmatt: I do suspect kernel. Now I have 2 BBB with me. I am upgrading kernel on one of it. And for the 2nd BBB I believe I should look for changes that could be done in the idle subsystem and states (I shall compare both). I'll try with rebuilding the stuff after comparing these 2 results. Nov 09 05:16:21 zmatt : can you share some link that shows how to work on cpuidle_sysfs_switch (which lets know the "process" and concept) ? Nov 09 05:16:40 tejas_: for rebuilding you'd grab the am33x-v3.8 tree of https://github.com/RobertCNelson/bb-kernel and then just follow instructions. it will automatically check if you have all necessary dependencies installed and tell you which are missing Nov 09 05:16:58 tejas_: you just add cpuidle_sysfs_switch to your kernel parameters (cmdline= in /boot/uEnv.txt) Nov 09 05:17:20 then apparently the sysfs entry for the current governor becomes r/w instead of ro Nov 09 05:18:04 note btw that if you want to disable cpuidle entirely you don't even need cpuidle_sysfs_switch Nov 09 05:18:36 will adding it change the files visible (they said more files be visible in that mode - developer testing mode). And can I edit the files ? Nov 09 05:18:54 that's what the documentation says Nov 09 05:19:00 ok Nov 09 05:19:18 specifically you can then change the governor (which is normally autoselected instead) Nov 09 05:20:10 if you merely want to disable cpuidle states just write 1 to their 'disable' attribute, this doesn't require cpuidle_sysfs_switch Nov 09 05:20:11 and what about one doesn't need the cpuidle_sysfs_switch, if one has to completely disable it ? Nov 09 05:21:26 I'm assuming here things were the same in 3.8 (the documentation link you pasted was for latest mainline kernel) Nov 09 05:21:33 I am not able to see cpuidle directory in cpu0.. there does not exist ~/system/cpu/cpu0/cpuidle Nov 09 05:22:02 I thought that directory would pop up in developer testing mode Nov 09 05:22:41 what's that ~ doing there? and don't expect paths to stay exactly the same in sysfs, look around a bit or use find Nov 09 05:23:41 I meant /sys/devices Nov 09 05:23:49 e.g. find /sys/devices -name cpuidle Nov 09 05:24:38 (or if that fails -name 'cpuidle*' ) Nov 09 05:25:31 the path /sys/devices/system/cpu/cpuidle is present Nov 09 05:26:35 but /sys/devices/system/cpu/cpu0/cpuidle (where the said files are supposed to exist - there is no cpuidle directory in sys/devices/system/cpu/cpu0/) Nov 09 05:26:55 Document says Nov 09 05:26:56 Per logical CPU specific cpuidle information are under Nov 09 05:26:56 for each online cpu X Nov 09 05:27:25 #Per logical CPU specific cpuidle information are under Nov 09 05:27:25 for each online cpu X Nov 09 05:27:33 sorry Nov 09 05:27:43 please don't copy-paste from documentation you've already linked to Nov 09 05:27:56 ok Nov 09 05:28:00 especially after I said that documentation is for the latest kernels, not the ancient one you're running Nov 09 05:28:09 I am just reading this https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/cpuidle/sysfs.txt Nov 09 05:28:22 ohk Nov 09 05:28:24 even if it were, documentation isn't a sacred text, it can be wrong Nov 09 05:28:39 :D Nov 09 05:28:49 you found cpuidle in sysfs, go from there Nov 09 05:29:26 probably it was swapped: cpuidle/cpu0 instead of cpu0/cpuidle Nov 09 05:29:30 or something like that Nov 09 05:29:53 or perhaps it wasn't cpu-specific yet Nov 09 05:30:13 go forth and explore :P Nov 09 05:30:40 I was referring to mainline kernel docs. It mostly matched with the paths on BBB actually Nov 09 10:13:16 Hi, since I have been lookig about the problem around, many people have problem like I have, they also have /sys/devices/system/cpu/cpuidle directory but not /sys/devices/system/cpu/cpu0/cpuidle Nov 09 10:13:46 Which means I am not able to locate "states" files Nov 09 10:14:43 What can I do ? or should it be concluded that Beaglebone Black doesn't support the cpuidle power saving states etc ? Nov 09 10:20:41 when you ask a question like this, please do always mention the kernel version you're using. in no case can you draw the conclusion that "the Beaglebone Black" doesn't support cpuidle, at most that some particular kernel doesn't Nov 09 10:21:10 kernel 3.8.13 (bone -50, May 2014) Nov 09 10:21:53 also bone -79, October 2015 Nov 09 10:21:56 I'm quite certain that I've seen cpuidle enabled in at least some kernels, I don't really remember which Nov 09 10:22:07 earlier you showed 3.8.3-bone50 actually Nov 09 10:22:15 unless that was a mistake Nov 09 10:22:32 bone-79 also doesn't have it Nov 09 10:22:46 I upgraded to bone-79, still no luck Nov 09 10:24:18 Neither am I finding something that discusses cpuidle_sysfs_switch boot option correctly, everyone everywhere just displays the same file since ages Nov 09 10:24:20 :( Nov 09 10:27:29 just tested cpuidle_sysfs_switch, it works for me Nov 09 10:29:18 http://pastebin.com/vvL9cNRT (without vs with that option) Nov 09 10:31:31 zmatt : 1. are you able to locate any states files ? 2. as you suggested earlier, to edit the "offline" to 1, it denies the permission Nov 09 10:31:41 even as root Nov 09 10:32:47 "disabled" Nov 09 10:33:07 can you please pastebin it ? Nov 09 10:33:32 and no I don't have any cpuidle states, the kernel I'm using doesn't include any cpuidle driver Nov 09 10:34:08 did you build your own kernel ? how can I find if my kernel has the dpuidle driver ? Nov 09 10:34:14 cpuidle# Nov 09 10:34:30 cat /sys/devices/system/cpu/cpuidle/current_driver Nov 09 10:34:36 seems like a good start to me Nov 09 10:34:57 also, if you have any cpuidle states, then you have a cpuidle driver Nov 09 10:34:59 cat /sys/devices/system/cpu/cpuidle/current_driver displays "none" Nov 09 10:35:09 there ya go Nov 09 10:35:31 So it desn't have cpuidle drivers Nov 09 10:36:07 which means am335x on my BBB does not go into the sleep state at all ? if it does, who is managing that ? Nov 09 10:36:25 what do you mean by "sleep state" ? Nov 09 10:36:35 I mean a C State Nov 09 10:36:57 mistyped as sleep state Nov 09 10:37:09 Any idle state Nov 09 10:38:16 it will obviously use wfi when idle, which will cause the cortex-a8 clock to be internally gated hence might be considered C1 Nov 09 10:40:50 then how can I know about the exit latency (time it takes to switch from idle to a higher priority task) ? Nov 09 10:41:06 in wfi exit latency is essentially zero Nov 09 10:42:58 If you remember briefly, I had asked you about why MobaXterm ssh client fails to connect to BBB and why JuiceSSH connects (since you said JuiceSSH does a better job with respect to failure/reconnect, and it takes a ping or two to wake the processor fully) Nov 09 10:43:31 then I thought of this as a problem because of cpuidle states Nov 09 10:43:45 And hence I wanted to disable them all Nov 09 10:43:47 I'm pretty sure you must have had that conversation with someone else, since I've never heard of either of those ssh clients Nov 09 10:44:27 Ok Nov 09 10:44:40 cpuidle should never cause a ping to be missed or a connect to fail Nov 09 10:45:20 But if you please consider above 3-4 lines of the scenario, it turns out that cpuidle is not responsible Nov 09 10:45:38 because cpuidle drivers aren't there Nov 09 10:45:51 I am back to square one :D Nov 09 10:46:07 that what could be the reason of connection failure Nov 09 10:46:10 also because cpuidle would merely cause the bbb to take a bunch of microseconds longer than usual to respond to a packet Nov 09 10:46:27 I have no idea Nov 09 10:46:58 because If it uses plainly WFI, it is unlikely that connection failure would be there Nov 09 10:48:46 even if it were in the deepest sleep state that would still allow it to notice packets at all, it should receive them correctly and not cause a connection failure Nov 09 10:51:08 Did you build your own kernel ? Nov 09 10:51:39 I use customized kernels yes Nov 09 10:59:52 Now if I install cpuidle drivers, and disable all the states, will the kernel panic or will it start using WFI again as a backup ? Nov 09 11:01:29 didn't you have some networking problem to debug? Nov 09 11:01:42 and of course it wouldn't panic Nov 09 11:02:25 btw I've never seen or heard of a beaglebone becoming unreachable by ssh due to being left alone for too long Nov 09 11:03:20 That has been happening to me since 4 years :D Nov 09 11:04:08 I wouldn't have tolerated such behaviour from a bbb for 4 days :) Nov 09 11:05:56 I never bothered about it since I was all the time into writing libraries and interfacing for it rather than looking into stability problems Nov 09 11:06:22 Now I am into all of this :/ Nov 09 11:08:08 I don't have a networking problem actually. It just happens that commands sent to BBB aren't propmptly handled (I expect commands to be serviced quickly and expect a feedback packet). If left alone for long time, commnads are serviced after a delay or its a flat failure. Nov 09 11:09:50 does it respond to ping (promptly) ? no -> it's a networking problem, yes -> it's an application problem Nov 09 11:12:32 I'll keep that in mind, I'll have to leave alone for some time now :D funny yeah Nov 09 12:48:49 zmatt: does it respond to ping -> no (someone disabled icmp.....) Nov 09 12:56:35 = networking problems, exactly Nov 09 12:58:34 in case of icmp being administratively filtered, a good solution may be to stab the administrator in the knee. (it would be considered polite to first check there are no external forces to blame) Nov 09 13:15:12 im trying to find the dimensions of the beagle bone black-wireless and green-wireless where can i find them? Nov 09 13:16:00 have you looked in the SRM? Nov 09 13:16:32 ah, hmm, there might not be one, then the design files, which hopefully got published Nov 09 13:17:23 they should be very close to the BBB though, for which there is a SRM Nov 09 13:17:48 the mounting holes don't seem to be the same... Nov 09 13:33:51 What could be the reason for mcasp to output only zeroes, even if no underrun occurs? Nov 09 13:40:34 different mounting holes? really? wtf... Nov 09 13:47:15 My recollection when we worked with McAsp1 is we had to process xmit even though we were only receiving. Or something like that. It was ... counter-intuitive. But I didn't set all that up, I just used the infor gathered by others, so I don't know the why or the how of it. Nov 09 13:52:41 depends on how you set it up Nov 09 13:52:53 it's definitely not the case in general Nov 09 13:54:09 Ragnorok: btw is that a reply to something? it looks a bit out of the blue to me :) Nov 09 13:54:34 overlord_tm asked about McAsp output. Nov 09 13:54:36 zmatt, in reply to me :) (What could be the reason for mcasp to output only zeroes, even if no underrun occurs?) Nov 09 13:55:02 i am using it in loopback mode, handling bots xmit and recv events in interrupts Nov 09 13:55:11 oh I've never tried loopback mode Nov 09 13:55:37 Me either. Nov 09 13:55:41 plenty of experience using it functionally in various modes though Nov 09 13:55:52 how do you test it otherway? Nov 09 13:56:44 with mcasp there's very little margin between "status register full of errors" and "working correctly" Nov 09 13:57:01 the case it if i set RPAD and XPAD to 1, then I get 0xFFFFFFFF, if i set it to 0, i get 0x00000000, but no data i send :D Nov 09 13:57:42 already figured that out, but i get no errors in status registry now (slowed down the clock, so interrupts are fast enough for handling) Nov 09 13:58:26 did you set the mask registers to 0xffffffff ? Nov 09 13:58:48 zmatt, RFMT and XFMT? Nov 09 13:59:28 RMASK / XMASK Nov 09 14:00:28 they were 0xFF, changing to 0xFFFFFFFF :D Nov 09 14:01:14 [ 9290.602888] RECEIVED ABCDABCD Nov 09 14:01:17 0xff is fine is your data is u8 :) although then you also need to configure the FMT registers right Nov 09 14:01:25 i think this is a little win for today, thanx zmatt :D Nov 09 14:23:08 Hi folks, did anyone use powertop on their BBB. Did it make real sense to use it at all ? Nov 09 14:45:16 tejas: some of the output sure looks sensible on my device (running a 4.0 kernel because I'm lazy) Nov 09 17:05:56 hi. having probs getting uio_pruss on bbb - tried image 4.4.1, 4.4.9, and i think 4. ... something newer. tried just about everything on the now useless internet Nov 09 17:22:22 ZeekHuge has a blog about using remoteproc that seems to make that usable. Might try that, unless uio_pruss is a requirement. I'm using uio_pruss, but I'm on 4.1.19, and Back In The Day said blog post didn't exist. Nov 09 17:34:03 not sure what the diff is, but i need the PRU and to code for it. Derecks book sux and I'm not sure if this hasn't been a big waste of time and money Nov 09 17:35:28 if i try 4.1.19, will uio_pruss just work or what? Nov 09 17:36:19 It's for an older kernel that had uio-pruss rolled in. Either select a kernel with uio-pruss, or use remoteproc, are the two simplest choices. It does just work for me, but that doesn't mean it's the only option. That's an old kernel by today's standards. In general it was that the *-bone kernels had uio-pruss and the others didn't. Nov 09 17:37:11 yeah. i read that and made sure i got a bone kernel, tho someone in google groups got a ti kernel working Nov 09 17:37:15 If I were starting again today I'd try ZeekHuge's blog and remoteproc, as that's the the likely path moving forward. Nov 09 17:38:10 We got a TI kernel to load uio_pruss, but it didn't work in the end. (shrug) This was last year. Much has changed. Nov 09 17:39:48 it will do everything uio_pruss does? the deal is that the flippin book has c code that uses the pruss (i think_ driver and API to load the assy program. I need to start with that code and go from there or just tell my boss something i'd really like to say, but prefer to wait Nov 09 17:41:00 Ragnorok: there was a thred last june that was supposed to be the end all be all and it doesn't work, either Nov 09 17:41:53 I may only guess, as I haven't used remoteproc, and I've only skimmed ZeekHuge's blog, but it based on my own PRU development effort, it seemed like it was usable. As for coding, I use CCS 6, which has a PRU C compiler and hex conversion built in. That part was easy. Nov 09 17:43:24 Compiled code seems pretty tight, at least if one does standard C style programming and minds their Ps and Qs. Couple thousand lines is 4k of code, so I'm only using half. I was suitably impressed. Nov 09 17:43:25 ccs is costly, IIRC. I'd put it on the company CC but... Nov 09 17:52:01 Ragnorok: Zeek's page looks like a possibility. i take it i can still load a prog written in assembly from a C prog if I do this, right? Nov 09 17:52:57 The source shouldn't matter, long as the binary is good. Nov 09 17:55:12 cool. thanks. Nov 09 18:00:36 One is happy to be of service. Let me know how it goes. I'd like to know if remoteproc is worthwhile from someone who's working it out. Nov 09 23:26:17 greetings... I need a link to how to make the sparkfun protocape's eeprom available to write to. Nov 09 23:36:06 I keep getting a connection timed out. Nov 10 02:18:49 cdw: schematic shows a solder jumper, SJ5 Nov 10 02:23:19 looks like it is write-enabled by default though (i.e. when the jumper is unsoldered) Nov 10 02:23:30 soldering SJ5 write-protects the eeprom **** ENDING LOGGING AT Thu Nov 10 03:00:00 2016