**** BEGIN LOGGING AT Thu Jan 12 03:00:01 2017 Jan 12 03:34:35 Does anyone know how to check the status of a pin without useing javascript, when I run this code http://beagleboard.org/Support/BoneScript/getPinMode I get errors Jan 12 03:47:53 Ragnarokkr: what do you mean by "pin"? Do you mean the status of the pinmux for a pin or the value of a GPIO? Jan 12 03:48:57 okay, from the link, its gpio - let me find a link for you Jan 12 03:49:11 Why in Debian on the Beaglebone Black when you run cat /proc/iomem the address range for the System RAM is 80000000-9fefffff instead of 80000000-9fffffff, thus giving you 511MB instead of 512MB? Jan 12 03:50:00 Ragnarokkr: er, sorry, pinmux Jan 12 03:50:39 try something like: cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins Jan 12 03:54:10 http://pastebin.com/kJf69TDh Jan 12 04:22:42 Astris-where-did-you-go: hmm, interesting question Jan 12 04:23:10 mag: https://github.com/mvduin/bbb-pin-utils try my show-pins utility :) Jan 12 04:23:32 it's a bit more readable than dumping the raw info from debugfs Jan 12 04:23:53 and includes pin values for gpios (provided they're exported or requested) Jan 12 04:27:22 Astris-apparently-didn't-care: it's 80000000-9fffffff on the beaglebones here Jan 12 04:29:59 (or 80000000-bfffffff on the beaglebone enhanced of course) Jan 12 04:45:59 ohey, wifi works on the BBE with the 4.9-ti kernel I built Jan 12 05:12:11 Hi Jan 12 05:51:25 Hello Jan 12 05:52:20 Hello cn some one please help me as to how do I get connected to the bbb with the network via USB cable. My bbb is running debian and my laptop has 16.04 Jan 12 05:52:32 But I'm unable to perform any updates on my bbb Jan 12 05:57:22 grep_aar_kash: open a terminal and enter 'ssh root@beaglebone.local' or enter 'beaglebone.local' into the address field of a web browser Jan 12 06:16:24 Running Ubuntu 14.04 on my BBB and I am getting an SSL Cert error when I am trying to instally python packages Jan 12 06:16:30 Anyone experience this issue? Jan 12 06:20:21 maybe update your ssl-certificates package? Jan 12 06:21:01 grep_aar_kash: having connection issues? Jan 12 06:21:18 he wants to install updates, i.e. internet connectivity on the bbb Jan 12 06:21:27 doing that via usb is non-trivial Jan 12 06:21:42 grep_aar_kash: you don't have an option of connection the beaglebone to ethernet? Jan 12 06:22:02 zmatt: i got that, i meant connection issues of his client to this channel. Jan 12 06:22:14 oh, I have joins/quits on ignore Jan 12 06:22:19 too much spam Jan 12 06:22:37 wot Jan 12 06:23:03 Did my client quit and rejoin? Jan 12 06:23:09 oh sorry Jan 12 06:23:13 I didn't see the PM Jan 12 06:23:57 DarkSector: according to the irc server you've been connected since two days ago, so no Jan 12 06:24:07 Right, my bad. Jan 12 06:25:05 DarkSector: and first instinct for ssl cert errors would be to check if the ca-certificates package needs to be update Jan 12 06:25:08 d Jan 12 06:25:47 if that isn't it you'll need to specify a lot more info before anyone can be of any help probably Jan 12 06:26:38 So if ca-certificates pacakge needed an upgrade, it's already done Jan 12 06:26:46 I think there's a bug with pip 1.5.4 Jan 12 06:27:14 did you google your error? Jan 12 06:27:42 Yes, found so much discussion Jan 12 06:27:54 Everyone recommended downgrading to 1.2.1 Jan 12 06:28:08 o.O Jan 12 06:28:12 that's quite a version jump Jan 12 06:28:13 And then upgrading Jan 12 06:28:18 uhh Jan 12 06:28:52 Repo versions are at 1.5.4. Recommended versions are at 9.0.1 Jan 12 06:28:57 talk about version jump Jan 12 06:29:06 hahahaha, niiice Jan 12 06:29:10 debian at its best Jan 12 06:31:14 http://paste.debian.net/908355/ Jan 12 06:31:51 Well, shit. That didn't work Jan 12 06:31:53 I'm not seeing the problem Jan 12 06:32:11 It's my SSL Cert for sure Jan 12 06:32:16 Here's the traceback Jan 12 06:32:51 (about repo versions I mean) Jan 12 06:33:11 Right Jan 12 06:37:10 Oh sheeet Updating certificates in /etc/ssl/certs... sed: couldn't flush stdout: No space left on device Jan 12 06:37:30 time for a less bloated OS install? Jan 12 06:37:55 oh noes :( Jan 12 06:38:25 I don't want to go through that now Jan 12 06:38:56 zmatt: one more example why using image builders is totally superior to os install + tinkering :-) Jan 12 06:39:25 LetoThe2nd: they're not superior, they're different Jan 12 06:39:28 Okay, it works with sudo Jan 12 06:39:36 aaaand still it fails Jan 12 06:39:37 DarkSector: apt-get autoclean Jan 12 06:39:44 if you're lucky Jan 12 06:39:54 Well, the certs got updated Jan 12 06:39:59 otherwise find something space-consuming and get rid of it Jan 12 06:40:23 zmatt: well, if step #314 in your manual install process fails and you need to start over again, they're vastly superior. :-P Jan 12 06:41:14 once you have a bit of breathing room, "apt-get -f install" if package installs/updates are in failed state, then try to find irrelevant packages to remove Jan 12 06:41:19 LetoThe2nd: uhh Jan 12 06:41:44 LetoThe2nd: that makes no sense to me Jan 12 06:42:10 but on a more productive note: dpkg is usually still functional if apt complains about being inconsistent Jan 12 06:42:12 it's image builders that need to start over if something goes wrong generally I think? when tinkering if it fails you try again Jan 12 06:42:21 yeah Jan 12 06:42:58 zmatt: nah, that only holds true as long as the image building process of whatever kind takes longer than your manual install process. and if you only need one of a kind. Jan 12 06:43:11 having to rebuild/reflash an image just to change one thing seems like a hassle Jan 12 06:43:25 no, you can (we do) image a system after preparing it manually Jan 12 06:43:56 also I definitely don't need 314 steps :P Jan 12 06:44:35 generally I clone some base system, customize it, image it to be able to make more clones Jan 12 06:45:03 I still have clean image building somewhere on my to-do list Jan 12 06:45:14 zmatt: of course, use whatever solution works for you. i just had great "fun" with things like 1) install this OS 2) then install this 3) then setup this config 4) install that 5) reboot 6) set up this other config 7) install some more stuff 8).... Jan 12 06:45:14 for when I have nothing better to do :P Jan 12 06:45:43 LetoThe2nd: yes that's annoying, although for me rare enough that it doesn't really bother me Jan 12 06:45:57 zmatt: in term of reproductibility, its a nightmare, at least for me. i do "bitbake production-image", and i'm all set. Jan 12 06:46:09 that's why it's still on my to-do list Jan 12 06:46:20 :-) Jan 12 06:46:47 but for development having a normal debian system is quite convenient Jan 12 06:47:01 and the cloning solution works well enough... I mean, I have a fine way to reproduce: flash another clone :) Jan 12 06:47:21 whatever fits your bill. i just never want to go back. Jan 12 06:47:52 yeah it's just a matter of "this stuff we already know" Jan 12 06:48:03 and have a workflow that works Jan 12 06:48:38 moving to something like yocto has a pretty significant entry barrier as a result Jan 12 06:49:47 or maybe it would turn out to be really easy and an "omg why didn't I do this before" (like using distcc) Jan 12 06:49:58 zmatt: if you didn't do it from the beginning, the barrier get higher each day, yes. thats why i totally refuse to had out anything that i cannot reproduce automatially, not even for early prototyping. Jan 12 06:50:21 dunno, we have few deps Jan 12 06:50:50 the barrier is just the unknown Jan 12 06:51:01 vs the familiar Jan 12 06:51:38 and having something that works well enough to make it not a priority to spend time examining potentially better alternatives Jan 12 06:51:58 for us its: "what will $COWORKER do if i get run over by a bus and he has to crank out an update in 5 years from now" Jan 12 06:54:15 yeah that is a concern (though for more reasons) Jan 12 06:54:49 for me a major motivation actually would be because I'm very concerned about system updates on debian Jan 12 06:55:29 zmatt: so i'm willing to rephrase what i said above to "use whatever fits your bill, but in any environment that i have worked so far an automated image building solution was absolutely superior to any manual process." :) Jan 12 06:56:07 how does your development workflow work in such a situation? Jan 12 06:56:26 zmatt: in terms of? Jan 12 06:58:21 well generally I'd develop any changes to the image on a beaglebone... and then they will obviously be part of the system when imaged Jan 12 06:59:08 with image building you'd need to somehow integrate those back into the image building... stuff... Jan 12 07:00:58 that seems quite inconvenient Jan 12 07:02:30 also, w.r.t. what you said earlier about what will $COWORKER do... why would that be a problem with our system? Jan 12 07:03:22 zmatt: yes and no. yes, as long as you're early in development and a lot of things are fluent. once the general project structure is settled, you have the target with the last automated build state. then that gets (automatically) equipped with some remote deployment/debugging instrumentation, so dev work happens on the host using the prebuilt sdk. once finished, push to the source repository and the next automated build incorporates the changes. Jan 12 07:04:28 zmatt: the problem is that if the manual generation takes more than one step - can you guarantee that all needed steps are properly documented? no special preparations or knowledge needed implicitly? Jan 12 07:05:15 you're thinking of building a new image from scratch that reproduces a previous image, but why would you do that? Jan 12 07:05:39 take the latest image, modify it, make a new image Jan 12 07:06:30 zmatt: its just iterative versus reproductible. your approach assumes that there always is a way to fix the existing image. Jan 12 07:06:43 which probably is true most of the time. Jan 12 07:06:44 yes I understand this scheme has some undesirable properties, but it definitely doesn't get in the way of some coworker later being able to patch a bug Jan 12 07:08:04 zmatt: it works as long as the image can be brought into whatever the desired target shape is. but there are breaking changes that prohibit that. substantial hardware changes, for example. Jan 12 07:08:45 zmatt: for us, bugfix can also mean that some component we rely on are deprecated and we need to replace them with something incompatible. Jan 12 07:09:10 that sounds like just a DT change, maybe a kernel update Jan 12 07:09:20 that's stuff I do all the time Jan 12 07:10:39 the main thing I'd worry about is accumulating weird cruft or corruption Jan 12 07:10:41 zmatt: certainly not. one of our current major problems is that we need to replace ARM7 with cortex m3 Jan 12 07:11:16 there jsut is no way to make the old binaries run there. we totally need to be able to rebuild them from scratch Jan 12 07:11:19 that's a whole different story Jan 12 07:11:37 well, i did say "breaking hardware changes" literally, didn't i? Jan 12 07:12:35 yes but something of that magnitude is not something I'm going to worry about given that all our projects are based specifically on the beaglebone Jan 12 07:13:05 and much of the hardware could be changed without requiring any recompile Jan 12 07:13:24 e.g. the same base image with just a different kernel/dt/u-boot works fine on an omap5 Jan 12 07:13:44 zmatt: so we are back to "what ever fits your bill. if you can take hardware for granted, some things get easier", i just cannot do that. Jan 12 07:13:53 I understand Jan 12 07:14:37 also if you're using arm7 or cortex-m3 then I understand that you don't care hugely about doing iterative development locally on the platform :) Jan 12 07:15:28 zmatt: that too. we've just been burnt so badly with nonreproductible stuff that anything else is a total no go. Jan 12 07:16:08 ah yes, past experiences can influence such choices Jan 12 07:18:05 absolutely. Jan 12 07:18:09 I also know that if I were to suggest moving to yocto at work I would probably not get a very enthausiastic response ;) or maybe a "yeah, it would be good to look into that eventually. right now we have products to ship" Jan 12 07:19:24 zmatt: sure. Jan 12 07:22:25 on a completely different note... if anyone is looking for something random to do, I'd be interested to get some independent confirmation of my observation that alternatingly accessing two memory locations spaced 4096 bytes apart (in a loop, no other memory touched) has absolutely abhorrently abysmal performance compared to e.g. two locations 4096+64 bytes apart Jan 12 07:23:58 theories are welcome too, since L1 cache is 4-way set associative so a loop that touches only two cachelines should perform the same regardless of which two memory locations are being accessed Jan 12 07:24:12 s/access/read/ to be more concrete Jan 12 07:26:27 zmatt: without any look into the datasheet, have you checked that the cache lines actually can hold any address? or you are maybe hitting exactly the offset where the addresses are forced to share the cache Jan 12 07:26:54 those accesses have the same cache-index Jan 12 07:27:11 but 4-way means that a cache can hold 4 cache lines with the same index Jan 12 07:27:37 and last time I checked 2 <= 4 Jan 12 07:28:13 zmatt: i'm no cache expert, just vaguely remembering something for a memory architecture book. Jan 12 07:28:35 s/for/from/ Jan 12 07:29:45 you vaguely remember correct, and indeed placement of data in cache is restricted, but that should not show up until you try to use 5 or more cache lines with the same index Jan 12 07:30:14 oh wait, 8192 bytes distance is needed to get an index collision Jan 12 07:30:42 the cache index is bits 6..12 of the address Jan 12 07:31:12 8192 byte distance btw has intermediate performance Jan 12 07:31:18 * LetoThe2nd feels vaguely right, then :) Jan 12 07:31:31 no, it means that 4096 has even less reason to be slow Jan 12 07:31:46 neither has a valid reason though Jan 12 07:32:15 cache thrashing should require 5 or more cache lines with the same index Jan 12 07:32:32 which is obviously impossible when you only touch 2 memory locations Jan 12 07:33:17 * LetoThe2nd is sad and feels vaguely wrong :'-(((( Jan 12 07:33:51 hence my invitation for an independent check, to exclude that there's something particular about how I did the test Jan 12 07:33:56 or something Jan 12 07:34:25 (accessing two locations in a loop isn't a huge volume of code to reproduce ;-) Jan 12 07:34:59 just don't forget to mark the memory as volatile, otherwise the loop will end up being reaaally fast Jan 12 07:35:02 ;-) Jan 12 07:36:50 I was seeing like 40 cycles per read instead of 1 cycle per read, hence this sort of behaviour might be rather useful to know for anyone doing performance optimization Jan 12 08:43:21 Hello. Grabbed a beaglebone I had, didn't use it for 2.5 years though AFAICR it worked fine. When plugged in, I got this http://pastebin.com/wb9qYtjv is it possible the flash card died ? Jan 12 08:44:38 ah, beaglebone white right? and yeah that looks like it's trying to netboot via usb, i.e. it doesn't consider the card bootable Jan 12 08:45:05 zmatt: indeed it's a bb white rev A5 Jan 12 08:45:17 I noticed from the [1705168.073300] usb 3-5.2.2: Product: SUBARCTIC Jan 12 08:45:29 current revisions of the SoC use a different string Jan 12 08:45:38 :p Jan 12 08:46:23 damn why are sd cards so flimsy Jan 12 08:46:43 i don't have another one lying around guess i'm stuck Jan 12 08:47:34 I don't think I would expect a card to lose its data in 2.5 years Jan 12 08:49:30 it gives a bunch of "dev 6 ep2in scatterlist error -104/-110" errors when read from directly Jan 12 08:50:03 but if you want an answer to "why are sd cards so flimsy", see https://www.youtube.com/watch?v=CPEzLNh5YIo Jan 12 08:50:55 haven't done much embedded for years but I remember always having trouble with SD cards Jan 12 08:52:33 it's not really SD cards, it's nand. no nand is thrown away, no matter how shitty, since the margins are just too tight. they even found cards where 80% of the nand storage was bad sectors.. that's still sold simply as smaller card, no prob :) Jan 12 08:53:11 afaik retention is very much temperature-dependent btw Jan 12 08:54:25 "flash memory found in most SD cards today has a retention time of about 5 years." Jan 12 08:54:49 just buy the expensive san disk, less problems Jan 12 08:54:57 I can always try to dd a new image to it but since it failed reading I don't have much hope Jan 12 08:54:59 as long as a card is used the card firmware can do housekeeping Jan 12 08:55:10 it's quite possible that might work Jan 12 08:55:15 especially if you explicitly erase it Jan 12 08:55:47 otoh if the nand data structures or firmware have been degraded, then.. yeah... Jan 12 08:56:51 xz -d bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz; dd if=bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img of=/dev/mmcblk0 bs=1M ? Jan 12 08:57:52 that wouldn't erase it, also you can just do xcat file.xz | dd of=/dev/mmcblk0 bs=4M Jan 12 08:58:24 I wouldn't use smaller bs than 4MB Jan 12 09:00:19 why wouldn't it erase the card? Jan 12 09:00:23 [janv.12 09:58] INFO: task systemd-udevd:30250 blocked for more than 120 seconds. Jan 12 09:00:26 damn Jan 12 09:00:53 hmm, I've seen that once too Jan 12 09:01:39 well with 4MB block size it will at least know it can use a fresh erase block instead of having to partially modify a block, but that's still not the same thing as erasing the whole card in advance Jan 12 09:02:03 i should zero it out before ? Jan 12 09:03:31 erasing is not the same as writing (regardless of the data)... I'm checking what the util is for erasing Jan 12 09:03:56 blkdiscard Jan 12 09:04:32 TRIM-like? Jan 12 09:05:34 trim and erase are related but different operations Jan 12 09:06:10 but trim operates on sectors which may very well be as expensive as writing Jan 12 09:06:17 erase always works on erase blocks Jan 12 09:06:54 (there's a preferred_erase_size attribute in sysfs if you want to know for sure what the erase block size is) Jan 12 09:10:41 indeed, 4MB Jan 12 09:23:53 for blkdiscard I got a BLKDISCARD ioctl failure 'operation not supported' Jan 12 09:24:15 and dd to /dev/mmcblk0 hangs Jan 12 09:24:20 so I guess it's dead Jan 12 09:25:37 scratch that, dd finished copying, I though kill -USR1 // CTRL^T printed the status Jan 12 09:26:33 be sure to do: sync Jan 12 09:26:59 though maybe dd does that already, it would explain the hang at the end Jan 12 09:28:56 LetoThe2nd: oh wow, I found it Jan 12 09:29:00 hah Jan 12 09:29:07 ok, I didn't see that one coming Jan 12 09:30:03 so, I knew that "allocated" pages aren't genuinely allocated until first access, hence I made sure to touch each page once before the benchmark loop Jan 12 09:30:45 but it turns out that if you only ever read from a freshly allocated page, it uses a single shared readonly all-zero page for that Jan 12 09:32:42 and it's the fact the pages touches were the same physical page mapped at different virtual addresses that was making a mess of performance Jan 12 09:34:07 sheesh Jan 12 09:34:42 one memset later and performance is as expected :P Jan 12 10:06:34 is this all I need to boot it ? http://beagleboard.org/getting-started Jan 12 10:08:44 ah ok it works thanks Jan 12 10:15:02 yay :) Jan 12 20:20:21 zmatt: I haven't tried it yet but your utility looks nice. Thanks! Jan 12 21:49:06 Been a while since I visited #beagle now :) I have a case on old HW where smsc95xx seems to load fine after a reboot, but I have noe eth0 interface. Ring a bell for anyone? Jan 12 21:49:39 Custom HW based on C3/C4. Jan 12 21:50:15 After reloading smsc95xx.ko eth0 comes back. Jan 12 21:50:20 ah, beagleboard rather than beaglebone Jan 12 21:51:03 no experience with those myself :) Jan 12 21:54:00 zmatt: :) Jan 12 21:58:53 gah. have to go offline right after asking a Q. If someone has a Deja Vu, please respond. I'll check the irclogs tomorrow :) Jan 13 00:59:13 BBB SD works fine but access to the emmc is not working Jan 13 00:59:16 http://dpaste.com/1MST3P2 Jan 13 01:00:07 is there something thas has disabled it software wise or is it just broken? Jan 13 01:48:45 does anyone know what pin /sys/class/pwm/pwmchip0/pwm1 corresponds too Jan 13 01:53:25 Ragnarokkr: that depends on what pwmchip0 corresponds to Jan 13 01:53:38 but probably it's eHRPWM0 Jan 13 01:53:47 hence its pwm1 is 0A Jan 13 01:53:50 eh Jan 13 01:53:51 0B Jan 13 01:54:17 darfo: hum Jan 13 01:54:56 darfo: this is on a BBB with no cape or such? Jan 13 01:56:20 Ragnarokkr: it can be muxed to P9.29 (mux 1) or P9.21 (mux 3) Jan 13 01:58:08 darfo: there just isn't enough info here to draw any conclusions, what happened that led to this state? Jan 13 02:28:32 The leds do nothing. If I try to boot from the emmc I get CCCCCCCCCCCCCCCC on the serial console because it can't access the loader. Jan 13 02:30:28 I've tried older and new versions of uBoot but always get the same result, timed out. Jan 13 02:31:01 zmatt ^ Jan 13 02:33:47 No capes Jan 13 02:34:33 sorry if my choice of words caused confusion ("led", past tense of to lead)... what happened that caused this state? Jan 13 02:35:24 I'm not sure. I acquired it used. They had attempted to load debian to the emmc but said they never could get it to boot from there only the SD. Jan 13 02:35:34 and if possible see if you can measure the voltage of the 3.3v supply Jan 13 02:35:51 what revision of BBB is it? Jan 13 02:36:34 btw it makes more sense to boot into linux (from sd) and examine the eMMC from there Jan 13 02:36:40 linux has better drivers and better tools than u-boot Jan 13 02:39:10 It is revision C. I tried using mmc-utils from debian but I only get ioctl errors. Jan 13 02:39:28 Where is the best place to probe that voltage? Jan 13 02:39:34 P9 header Jan 13 02:40:02 http://elinux.org/File:Cape_expansion_headers.PNG Jan 13 02:40:06 topleft Jan 13 02:40:18 (when ethernet connector is at the top) Jan 13 02:41:32 I checked the voltage at the reset pin of the of the eMMC through R111 and it was +3.38V Jan 13 02:41:39 ok Jan 13 02:42:39 sounds like the eMMC is indeed dead then Jan 13 02:44:00 wait Jan 13 02:44:11 you get ioctl errors... you mean the eMMC does appear as device? Jan 13 02:44:31 can you pastebin a kernel log? Jan 13 02:45:14 if it were dead then it shouldn't appear as device at all Jan 13 02:45:21 I'll have to obtain a log. Jan 13 02:45:45 Yes that's why the incorrect sizing is confusing as seen from uBoot mmcinfo Jan 13 02:46:14 yeah I'm not sure since u-boot seems to be continuing despite errors Jan 13 02:46:22 so that might just be an uninitialized structure Jan 13 02:51:09 It is going to be a while to get the log. The mmcblk1 device is not present in debian. Jan 13 02:51:33 I have to create another SD with Angstrom on it. iirc that is where the device was present Jan 13 02:52:35 can I have kernel log from debian? Jan 13 02:53:55 I don't think it's necessary/useful to make an SD with angstrom **** ENDING LOGGING AT Fri Jan 13 03:00:01 2017