**** BEGIN LOGGING AT Wed May 11 02:59:58 2016 May 11 03:57:51 stt_michael: https://github.com/mvduin/py-uio/blob/master/qep-test.py :D May 11 03:58:23 still need to make an overlay for it, currently this uses my custom dts May 11 03:58:34 I really hope it'll work as overlay May 11 03:58:51 and those perl probs you mentioned are weird May 11 03:59:00 maybe just dike out the locking entirely? May 11 03:59:10 it's kinda overkill anyhow May 11 04:02:03 (i.e. all lines containing $dh_fh) May 11 04:06:28 if you can check whether removing the lines containing $dh_fh fix the issue for you, I'll commit that May 11 04:06:51 zmatt, looks nice May 11 04:07:00 yeah when I get back to base :) May 11 04:07:07 does it run for you though? May 11 04:07:22 without any problem May 11 04:07:54 I suspect your perl will be slightly older than 5.22 though May 11 04:09:06 iirc debian doesn't support installing multiple perl versions, so I can't easily test with an old one May 11 04:09:20 yeah iirc uts 5.18 May 11 04:09:29 hmm not that old May 11 04:09:34 dunno May 11 04:10:16 I know :/ May 11 04:10:25 I'll just dike out the locking anyway, it's baroque overdesign... if you need locking around rm-overlay, you're probably doing creepy things to begin with May 11 04:10:57 not to mention that add-overlay lacks the same locking currently May 11 04:14:41 pushed May 11 04:16:25 stt_michael: qep makes a nice example though... it has actual substance, shows how to cope with it being in pwmss, uses an irq, while at the same time not being too complicated to get completely lost May 11 04:19:00 I still want a good solution for registers with bitfields though... something that lets you use them as individual fields (rather than having to mask or combine them manually), while at the same time allowing updating multiple fields at once or overwriting the whole register with new values for all fields May 11 04:19:27 ctypes bitfields allow the former, but they perform a read-modify-update for each write May 11 05:13:04 Is it possible to boot uncompressed kernel image with recent uboot versions? May 11 05:18:44 Guest27051: hmm, aren't compressed kernel images actually self-extracting executables? if so, I'm not sure why u-boot would care about compressed vs uncompressed May 11 05:18:49 why would you want to though? May 11 05:24:47 I timestamped my boot process and i have around 5 sec delay on "starting kernel ..." line which i think is due to uncompressing zimage file? actually i want to reduce kernel loading delay May 11 05:25:33 normally compressed kernels are used to *speed up* the boot process May 11 05:25:43 since loading data from storage is slower than decompressing May 11 05:26:26 you can however select which compression method is used when compiling the kernel, giving different trade-offs May 11 05:26:30 5 seconds is long though May 11 05:26:59 how big is your kernel? May 11 05:27:39 yes it long and i'm using official BBB rcn kernel and zimage is 7.4 MB May 11 05:28:04 normal image is 12.1 MB May 11 05:29:40 the kernels I compile myself are typically 3.5 - 4.0 MB (compressed) May 11 05:31:28 it seems LZO is being used May 11 05:31:44 "Lempel–Ziv–Oberhumer (LZO) is a lossless data compression algorithm that is focused on decompression speed." May 11 05:32:43 so, rcn already picked the option for fast decompression May 11 05:33:19 I don't think it'll be spending 5 seconds on decompression May 11 05:36:44 please see: http://pastebin.com/PfFNFR0i May 11 05:36:58 it's possible btw that you're simply not seeing log messages during very early boot, until the serial driver loads and then all buffered log messages get dumped at once May 11 05:37:27 turning on earlyprintk could help May 11 05:39:52 Guest27051: I've seen that delay also, I only just now realized that temporary inability to log any messages might be the reason May 11 05:43:01 using lz4 instead of lzo may slightly improve things, perhaps an uncompressed kernel will too since reading from flash is relatively fast (then again, u-boot's drivers tend to be quite slow) May 11 05:43:31 much bigger improvements will be obtained however simply by reducing the size of kernel and initramfs May 11 05:44:44 I should also admit that i did not have this delay in 3.8.x kernel version with older uboot. May 11 05:45:27 it could be that the timing has changed of when the serial driver is initialized May 11 05:47:08 when optimizing boot time, be sure to also check out systemd-analyze plot >boot.svg May 11 05:49:52 the "active" time it shows on a block device is the time spent on I/O May 11 05:50:18 (waiting on mmc tends to be a major part of boot time) May 11 05:50:24 thanks i'll analyze boot.svg also i have this: Startup finished in 9.338s (kernel) + 11.280s (userspace) = 20.618s ,is 9.3 sec long ? May 11 05:50:53 w00t@bb938:~# systemd-analyze May 11 05:50:53 Startup finished in 1.929s (kernel) + 4.637s (userspace) = 6.566s May 11 05:51:19 omg May 11 05:51:42 your device is BBB? May 11 05:51:47 yes May 11 05:52:06 with a custom-built kernel based on 4.4.8-bone10 currently May 11 05:52:28 somewhat stripped (but not *very* heavily) May 11 05:52:41 i'm using also 4.4.8-bone10 none customized :) May 11 05:53:47 hmm the command isn't "plot" May 11 05:53:49 what was it May 11 05:54:01 oh wait it is, stupid me May 11 05:54:18 (typed systemctl instead of systemd-analyze) May 11 05:54:57 ya np May 11 05:55:33 what should be my concentration on customizing kernel in this case? May 11 05:55:54 http://gerbil.xs4all.nl/boot.png May 11 05:56:29 i use this as reference though May 11 05:57:35 zmatt, pwmss? May 11 05:57:42 oh nvm May 11 05:57:47 bleurgh May 11 05:58:12 I don't know whether anything specific made a major difference... over time I've just went several times through the config options and got rid of anything I had no use for :) May 11 05:58:38 considering recompiling a kernel takes like 10 min, I can always turn something back on later if I turn out to need it anyway May 11 06:01:10 http://imgh.us/boot_6.svg May 11 06:02:45 yeah I see lots of the crap on a default install May 11 06:03:04 generic-board-startup in particular is compeletely useless yet horribly slow May 11 06:03:53 you are right i had plan to remove it and lots of rootfs stuffs but here the kernel boot time annoys me a lot May 11 06:04:45 seems that i should go for directly customizing kernel not to worry about kernel loading itself May 11 06:05:48 and start with a clean system May 11 06:06:27 http://gerbil.xs4all.nl/flash-images.html the lines at 12:41:09 and 12:42:17 describe how I've generally started out May 11 06:08:14 stt_michael: yeah pwmss is lovely... shove some "foreign" modules (imported from their C2000 microcontrollers) into a subsystem, don't bother figuring out how to deal with PRCM but instead just wire it into registers and leave it basically undocumented May 11 06:08:18 :P May 11 06:08:40 zmatt, sounds about right for TI May 11 06:09:00 no actually it sounds right for the AM335x May 11 06:09:18 I don't think they would have pulled crap like that on an OMAP May 11 06:09:21 they're that specific?! lol May 11 06:09:37 I thought it was an omap2 derivative? May 11 06:11:00 zmatt: thanks for your help, i'll check them out May 11 06:11:07 it's more a netra/centaurus-descendent (which is omap4-generation, though with plenty of differences)... netra and centaurus however still clearly received some love and care, not so much for the am335x May 11 06:12:31 on centaurus (dm814x et al) the prcm was sufficiently well-organized that I was actually kind of shocked to discover two registers were swapped in the PRM of one of the power domains May 11 06:12:44 lol May 11 06:13:24 subarctic (am335x) prcm otoh is organized by shuffling the registers like a deck of cards, and then putting some bitfields at gratuitously incompatible offsets May 11 06:14:13 this chip is really a mess May 11 06:14:16 but hey, it's cheap May 11 06:14:28 yes, I suspect thats no coincidence May 11 06:15:09 I still miss centaurus though May 11 06:15:15 it's even better if after shuffling you can put bitfields related to multiple separate components into same register, so that locking becomes a nightmare May 11 06:15:37 tomba: hehe May 11 06:16:02 tomba: the longer you dig around, the more gems you find May 11 06:16:21 like reset control and reset status registers not using the same bit-allocation for the individual resets May 11 06:17:10 gpio CLKCTRL registers put a writable bit at a location normally reserved for a status indicator May 11 06:17:31 I often wonder what the HW guys are thinking, but then, it's easy for SW people as we can just fix the code afterwards. May 11 06:17:46 (making it incompatible with omap4 prcm register layout, while centaurus/netra were a clean subset) May 11 06:18:31 HW people and those responsible for writing drivers/bootloaders should really work in the same office for a while, without slapping-with-trout distance May 11 06:18:38 *within May 11 06:18:56 I mean, from a HW point of view it probably makes no difference how you wire bits into a register May 11 06:19:13 from a sw point of view otoh it can make me want to strangle those responsible :P May 11 06:19:38 I fully agree. the guys doing the HW and SW for a component should be in the same team. May 11 06:21:24 but really, look at a SoC like the dm814x and it's clear it *is* possible for hw people to care and try or organize things May 11 06:21:51 so either they fired those and let an intern handle the am335x, or they just really spent as little time as possible on it May 11 06:22:15 I'm also still amazed by the many "ghost" modules it has May 11 06:22:47 where there's a CLKCTRL register, a target agent, yet without any doubt there's no actual module behind it May 11 06:23:57 my only explanation is that a larger design was used as template, and removing just the module has less impact than removing the supporting infrastructure May 11 06:24:21 zmatt: was your kernel customizations only on removing useless drivers? sry for my poor english. May 11 06:24:53 Guest27051: just config changes, not code changes, if that's what you mean May 11 06:25:22 (actually I do have a code change, but that's actually the addition of a driver, not removal of one :) May 11 06:26:23 i mean when i'm going for menuconfig should i concentrate on removing drivers or sw else does the magic May 11 06:26:44 tomba: sigh... probably I soon need to resume work on the project with lcdc headache ... -.- May 11 06:29:01 Guest27051: http://gerbil.xs4all.nl/config-4.4.8-bone10-dd3 May 11 06:29:49 Guest27051: note that of course my needs might not equal your needs May 11 06:30:12 zmatt: thanks, i will consider May 11 06:30:18 I can recommend 'make xconfig' over menuconfig btw May 11 06:30:31 easier to browse imho May 11 06:31:35 i'm a fan of Qt so i'll go for that May 11 06:33:16 zmatt: good luck =). I'm trying to get some hw guy study the IP, but... let's see what happens. May 11 06:33:26 tomba: my worry is about the async fifo May 11 06:33:57 especially due to the erratum that the newly added 'auto-restart on fifo underflow' feature doesn't work May 11 06:34:05 that means someone tinkered with that part of lcdc May 11 06:34:07 and failed May 11 06:34:44 it's not entirely unimaginable that more got mucked up in the process May 11 06:35:45 in general, people seem to have a lot of trouble getting asynchronous stuff right :P May 11 06:36:35 the async fifo in the uart I also buggy I discovered... if you write too many bytes consecutively (but with plenty of space in the fifo for them) the fifo pointers get corrupted May 11 06:36:43 *is also May 11 06:37:22 humans are synchronous, async is always difficult =) May 11 06:37:23 "fortunately" real-world uart drivers seem to be too inefficient to trigger this bug May 11 06:37:39 that's not true, humans are usually event-driven May 11 06:39:30 but I also put a lot of blame on the available languages and toolchains May 11 06:40:40 e.g. when a pulse-irq-output was connected to level-irq-input in silicon 1.0, why did that not result in a type error? May 11 06:41:33 answer: afaik you can't even make such distinctions in verilog, a bit is a bit May 11 06:43:35 zmatt: hmm, I haven't looked at the am3 errata/trm for a while... but this auto_uflow_restart seems to imply that the LCDC should be reset whenever we get even a single underflow. I don't think the driver does that. May 11 06:44:11 I'm not sure it even properly signals underflows though May 11 06:44:43 the guy who was getting them (due to heavy emif traffic and incorrect prioritization) was iirc getting sync-lost rather than underflow May 11 06:45:19 I really doubt anyone actually tested whether underflows work as documented, or how to properly recover May 11 06:46:07 true, I think sync losts are not supposed to happen on a "normal" underflow. but maybe the driver should just always reset when either an underflow or sync lost happens May 11 06:46:42 note that I've also seen indications that resetting may be hazardous if dma has not been cleanly shut down and a request may still be in flight May 11 06:47:02 some remark in the docs hinted at that anyhow May 11 06:47:11 yes, the LCDC output should first be disabled, and the driver should wait for framedone May 11 06:47:28 I can imagine that a reset while a trasnsaction is in flight can result in bus protocol desynchronization May 11 06:47:50 although hopefully it'll just ignore an unexpected reply May 11 06:48:54 hi, i am doing camera interfacing with bbb under linux. i want to interface 2 usb cameras with bbb. is this possible? if yess then how? May 11 06:50:07 tomba: question is thoguh, do you still get framedone if an underflow happened? May 11 06:51:12 tomba: really a lot more details are needed, or specific (and _correct_) instructions on how to act in all cases May 11 06:53:25 tomba: note btw that in my testing it seemed lcdc always recovered by itself on a sync lost (triggered by briefly configuring a wrong-size framebuffer) May 11 06:53:45 zmatt: I haven't heard that we would have ever missed the framedone irq, but yes, I don't think we have explicitly studied that situation May 11 06:56:50 tomba: an interesting possibility would be to put a tiny framebuffer in OCMC ram (be sure to use a kernel without the fancy power management that requires ocmc) May 11 06:57:02 then you can use the ocmc firewall to temporarily stall all requests May 11 06:57:29 resulting in guaranteed underflow May 11 06:58:51 since the L3 switches are crossbars this should *hopefully* not lock up the whole system as a side-effect O:) May 11 07:00:32 it also gives the opportunity to see the effect of performing a reset while a request is in flight May 11 07:02:02 this is the only easy way I know of keeping an L3 request in flight for human-scale times May 11 07:02:32 makh: you can connect multiple usb cameras of course using a hub May 11 07:02:47 makh: how well the bbb will handle it... I don't know May 11 07:04:24 I think in theory you could even make the device port act as a second host post instead, although that would require some creative hackery May 11 07:04:51 (the usb consortium would frown upon you ;) May 11 07:07:51 makh: usb is however not considered to be the bbb's strongest point... although it doesn't seem to have as much problems as it used to in earlier days, so drivers have improved May 11 07:10:15 oh ok May 11 07:10:45 it apparently still operates without DMA though in the standard kernels May 11 07:10:59 someone semi-recently reported that enabling it actually made things *slower* May 11 07:11:03 which is quite an accomplishment May 11 09:01:56 hi everybody May 11 09:02:11 i have some troubles with emmc flash May 11 09:03:59 i would like to flash the emmc of a beaglebone black with the following immage May 11 09:04:02 Jessie for BeagleBone, BeagleBone Black, SeeedStudio BeagleBone Green, element14 BeagleBone Black Industrial and Arrow BeagleBone Black Industrial via microSD card Debian 8.3 (BeagleBone, BeagleBone Black, SeeedStudio BeagleBone Green, element14 BeagleBone Black Industrial, Arrow BeagleBone Black Industrial - 4GB SD) 2016-01-24 - more info - bmap - sha256sum: da97d7794d834ee785265162635aedcca80fd6dc374593dd05473c0a25f0ac73 May 11 09:06:10 to get a eMMC flasher image i have to edit the /boot/uEnv.txt file May 11 09:07:37 how can i edit this file. I tryed a lot of tools bot nothing worked. Is there a manual or sth like this available? May 11 09:08:11 or is there still a flasher image available May 11 09:10:15 Daniel_1901: or you could just download the corresponding ready to use flasher image May 11 09:12:39 but you should be able to write the image you have to a SD-card. Mount it under linux and edit boot/uEnv.txt May 11 09:14:49 thx for answer May 11 09:15:57 is there somewhere a repository where i can find the flasher image May 11 09:16:12 on beaglebord org the flasher versions are removed May 11 09:17:39 looks like they have been completely phased out May 11 09:17:56 you can also just boot the image on the card and edit from within May 11 09:22:30 Thx i will try it May 11 09:22:54 Daniel_1901: You can find img on http://elinux.org/Beagleboard:BeagleBoneBlack_Debian May 11 09:23:40 dirkk: they are gone there May 11 09:23:50 only two flasher images for console remaining May 11 09:27:11 tbr: strange, microSD/Standalone: (lxqt-4gb) works for me May 11 09:28:37 dirkk: none of the lxqt images are flasher images? May 11 09:32:05 tbr: sorry, you're right May 11 09:35:10 they used to be May 11 09:35:43 I spent some time looking through the page and then through rcn's server to make sure I wasn't stupid or something. So no surprise you got confused too. May 11 11:09:44 weirdness May 11 11:10:55 https://rcn-ee.com/rootfs/bb.org/testing/2016-04-18/lxqt-2gb/ May 11 11:11:15 still got flashers there May 11 11:11:35 (also for lxqt-4gb and iot) May 11 11:12:21 allfailer.... www.theregister.co.uk/2016/05/09/allwinners_allloser_custom_kernel_has_a_nasty_root_backdoor/ May 11 11:12:32 that one is hilarious May 11 11:12:52 yeah, it seems to be a recent change that he dropped the flashers May 11 11:12:59 yes, shame on them for editing a struct cred ! those are supposed to be immutable! May 11 11:13:17 you need to make a new one and install that as task cred May 11 11:13:30 this could lead to race conditions! May 11 11:13:31 ;) May 11 11:14:17 who knows, you might be able to exploit them for privilege escalation... oh wait May 11 11:14:35 hehe May 11 11:15:13 weird thing is, I don't think this fully works May 11 11:15:41 as in, the task will be uid 0 but I don't think it'll act like root is supposed to May 11 11:16:00 since the capability mask is unchanged May 11 11:16:54 it might get turned into proper root creds during fork/exec though May 11 11:18:25 and even with all capabilities dropped, being uid 0 is bad enough due to the rather important files owned by it May 11 11:18:47 maybe the BSP readme says "run /bin/sh in addition if something doesn't work as expected" May 11 11:19:06 well you probably do this from a shell May 11 11:19:21 and then the programs you execute have proper root privileges May 11 11:19:28 right, so everything is a fork anyway May 11 11:23:02 unless you had a geeky moment and made your system run with all SECUREBITS set May 11 11:23:17 in which case uid 0 is Just Another Uid May 11 11:24:41 I'm not sure how feasible it is currently to have a functional system like that though May 11 13:47:00 hi, I am playing around with boot up times. I notice with no OS present the ROM code spits out 'C' gery soon after power is applied, however when ther is an OS present (eMMC or SD card) ther is a ~2.3 second delay between power applied and the first output of u-boot's SPL May 11 13:47:13 *very May 11 13:47:49 is this due to delay of loading SPL into SRAM? May 11 13:48:51 just a guess: ROMBL is quite conservative in all settings and only has minimal control of peripherals. This probably makes loading MLO not the fastest thing and then it needs to set up everything so that U-Boot can actually start. May 11 13:49:28 I guess you might be able to instrument MLO to spit out something to the UART at various stages May 11 13:49:49 after all it's just a minimal U-Boot itself May 11 13:50:55 or you watch things over JTAG or if you are made of money you use TRACE May 11 13:55:19 I bet zmatt can say something much more concrete about those things, as I only have rather high level familiarity May 11 13:58:20 ok, thanks! I am assuming the ROM is in fact ROM and not flash, so not much I can do about it. I'm wondering is there is any thing I can do to "help" though. I'm getting ready to try the newer format of placing SPL and u-boot in the first few sectors rather than in a FAT partition. May 11 13:58:58 I'm hoping removing the extra step of reading a FS might improve things May 11 14:00:54 I doubt you'll see much of a difference May 11 14:01:12 note that apparently you need to place it at all three(?) offsets May 11 14:01:50 and yes, ROMBL sits in mask(?) rom inside the SoC May 11 14:15:06 ok, I'll give it a shot and see, I just did a quick gut check comparing Debian vs my Image and it does seem the newer style placement of SPL prints the SPL version number sooner after power on, but not really apples-to-apples. I'll work on a better test May 11 14:15:43 enoch247, great nick. May 11 14:17:04 :) thanks goes clear back to my old MSN chat days, just kinda stuck with me May 11 14:21:29 hmm? May 11 14:22:28 enoch247: the CCC is rom trying to boot via xmodem May 11 14:23:44 I just use the CCC as a measuring point because it tells me the rails and clocks ar up and the ROMBL is going May 11 14:24:41 in general, ROM takes very very little time... when I do baremetal tests I often use netbooting where ROM uses bootp + tftp to directly download my program from my laptop... if I press the 'r' key in my program which triggers a warm reset then my app is already downloaded and running again before my finger has properly let go of the 'r' key yet ;) May 11 14:25:54 actually the CCC means the cpu is up, ROM perform system init, tried to boot via 2 or 3 boot media already and failed, and finally tries UART boot May 11 14:26:14 attempting to boot from mmc/sd also includes a bunch of retries May 11 14:26:29 so the CCC actually appears relatively late May 11 14:27:23 the default boot device order is { eMMC, μSD, uart, usb } May 11 14:27:43 if you power up with the S2 button pressed it becomes { SPI, μSD, usb, uart } May 11 14:28:01 but there in lies my interest. CCC is reached very fast I agree, but the SPL version string when it is present apears much latter than CCC May 11 14:28:19 milliseconds vs 2.3 seconds May 11 14:28:59 hmm, hold on I can quickly check whether that's due to SPL or simply loading time May 11 14:29:00 I assume SPL prints its version as soon as it starts May 11 14:29:06 ROM is pretty dumb at loading data May 11 14:30:19 my assumption is due to putting SPL into SRAM May 11 14:30:28 I can check that May 11 14:30:46 by putting my own baremetal app on uSD card May 11 14:31:11 ok, would be great if SPL is just slow, then maybe I can do something about that May 11 14:31:14 and then another version made artificially large May 11 14:31:41 awsome, I really appreciate that. May 11 14:31:50 if ROM is slow then there's an easy solution too: make the secondary loader as tiny as possible May 11 14:32:09 good point May 11 14:32:36 it would also be interesting to compare speed with that of SPI flash... but I don't have one around May 11 14:58:48 ok, loading a small MLO from uSD is definitely not slow May 11 15:03:00 how small is small? May 11 15:15:51 https://www.youtube.com/watch?v=EUZLy3sybzo May 11 15:16:36 the delay between the power led and user led is time to load and boot my program ;) May 11 15:17:01 I'll try making it artificially large May 11 15:18:03 ok MLO is 72K if you don't mind doing something in that range May 11 15:22:56 are you placing you MLO in a FAT partition? May 11 15:22:59 yes May 11 15:24:56 hi May 11 15:25:00 anyone here May 11 15:25:17 no, 240 people are just /pretending/ to be here May 11 15:25:18 http://www.catb.org/esr/faqs/smart-questions.html May 11 15:25:36 lurkers May 11 15:25:52 complete noob to beagleboards so couple questions May 11 15:26:31 our school is planning on using beagleboard for our satellite instead of microcontrollers, whats the advantage May 11 15:29:03 assuming you use a Linux distro with it, mostly that you can develop as a higher level. of curse at the cost of abstraction May 11 15:29:14 *at May 11 15:30:37 That and the SoC on a BBB has a pair of 200mhz aux cores for fast GPIO / whatever. May 11 15:31:46 you may want to consider the temperature range if you are gonna launch one into space though May 11 15:34:06 the radio we are putting on our sat comes with beaglebone and they say the radio is design to use in space so i dont think temperature will be a problem, but i will check May 11 15:34:16 hows python multithreading work on it May 11 15:38:10 aubie: can you be more specific? May 11 15:41:07 enoch247: https://www.youtube.com/watch?v=KMhzy7tzYFE May 11 15:43:30 we have multiple subsystem that all needs to run simultaneously so we dont know how well beagle handles thats May 11 15:44:26 our original design was using microcontroller for each subsystem and all send input to main controller board with i2c May 11 15:45:16 we are completely new to beagleboards so we have no idea whats what May 11 15:47:09 zmatt: again, thanks a ton. so it seems the load time is negligible. perhaps MLO is doing a bunch of work before printing to the console. I'm looking at the source now. May 11 15:47:41 though I can't image what May 11 15:48:48 aubie: I don't think anybody will be able to tell you which is better May 11 15:49:27 best to try both approaches or just pick one and be okay with never knowing if you chose right May 11 15:49:47 you could do some simple mockups and time and extrapolate May 11 15:49:51 aubie: I've never coded Python so I can't say how well it multitasks, but it's essentially Linux. As a rule of thumb it should do as well as any other Linux, but it has two PRU cores for low latency / parallel operations. May 11 15:49:56 enoch247: quite possibly u-boot is just a painfully slow piece of bloatware? May 11 15:50:06 But som PoC would certainly answer a lot of questions. May 11 15:50:59 ok i guess we just have to play with it to find out May 11 15:51:13 also you are certainly not limited to Python May 11 15:51:14 has anyone tried docker on beagle\ May 11 15:51:54 if performance is critical by all means use c on the main cores or the PRUs May 11 15:51:57 we like python but might have to do c++ because all the sensor stuff May 11 15:51:57 I'm doing C on the PRUs and C++ for the main system. May 11 15:52:15 enoch247: I mean, that 5 KB executable doesn't just turn on the LED, it also includes proper cortex-a8 initialization including MMU and caches, full irq support, fault/abort decoding (all those different fault messages actually take up significant space), and basic console output code May 11 15:54:41 if I add my preliminary eMMC code, the result is 6 KB :P May 11 15:58:03 I have no idea what u-boot is doing with all that space May 11 15:58:09 ok, well I guess I just need to keep digging, at least I know for certain its not the ROM code. May 11 15:58:14 does it maybe include a video game as easter egg? :P May 11 15:58:27 :) wouldn't surprise me May 11 15:59:29 it makes since that u-boot proper is large given what it can do, but one would think MLO would be pretty light May 11 16:00:02 I don't understand why I'd want an u-boot with all that crap considering boot ROM already supports plenty of boot media May 11 16:02:05 it just needs to perform necessary init (mainly DDR3 ram, which consists of writing constants to maybe a dozen registers), load the kernel, initrd, and DT, and execute it May 11 16:02:59 and maybe go to 1 GHz before doing so (incl necessary voltage change in pmic), simply to speed up boot time up to the point the kernel takes over power management May 11 16:03:51 all of this could fit comfortably in an MLO May 11 16:04:26 anyhow, I gotto do shopping, bbl May 11 16:04:30 just the price you pay for a general purpose piece of code. as I understand it it is *posible* to jump directly into the kernel from MLO May 11 16:06:06 hello all. I need some help with device tree overlays. I downloaded the latest debian 8.3 console image and i disabled HDMI to have P8.[27-29] unclaimed. Then I created the following overlay http://pastebin.com/a9AFHdV1. After applying it, PINS seem not programmed. Here the process I followed http://pastebin.com/Bmr0cs9P May 11 16:10:47 probably running a 4.1-ti kernel? try installing 4.1-bone kernel instead May 11 16:11:23 there's this remoteproc vs uio_pruss thing that I know virtually nothing about except that it's been giving people headache :) May 11 16:12:13 afk now May 11 16:14:05 do the pins show up as claimed in /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux- May 11 16:14:05 pins? May 11 16:14:21 zmatt: yes I'm running a 4.1-ti kernel May 11 16:14:37 I have found this http://www.valvers.com/embedded-linux/beaglebone-black/step04-gpio/ to be a great guide May 11 16:16:35 enoch247: I disabled HDMI to have pins unclaimed May 11 16:18:38 I *belive* that your fragment should claim the pins in order for you pinctrl settings to be applied May 11 16:19:44 ie: Override Board Name,00A0,Override Manuf,CB7S-LED-PRU1 needs to claim them now that you freed them up from the HDMI cape May 11 16:20:50 btw, to show current pin state in a nicer way -> http://gerbil.xs4all.nl/show-pins-v3.pl.tgz May 11 16:21:32 I don't have a ton of experience with DT, but I recall having a similar problem and having to do that May 11 16:21:54 enoch247: if you use the configfs mechanism for overlays the metadata is irrelevant in any case May 11 16:22:05 https://github.com/mvduin/py-uio/tree/master/dts contains utils for that May 11 16:22:30 enoch247: excuse me, i've not understood. What I did is: 1) modify uEnv.txt in order to have HDMI disabled 2) boot BBB 3) apply the process described here http://pastebin.com/Bmr0cs9P May 11 16:22:57 it can compile overlays from dtsi files instead of the horrible syntax of overlays, supports macros for pin stuff, and bin/ has scripts for adding/removing/listing overlays May 11 16:23:18 enoch247: so what I have to do to claim pins? May 11 16:23:42 alfatau: your pin claim looks fine to me May 11 16:24:03 so most likely the driver is the problem May 11 16:25:06 my guess: remoteproc is enabled by default, therefore the overlay has no effect May 11 16:25:36 pretty much any guide will assume uio_pruss anyway, so ditch that 4.1-ti kernel :) May 11 16:27:41 bingo May 11 16:27:42 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.1.16-ti-r44/arch/arm/boot/dts/am33xx.dtsi#L854 May 11 16:27:55 that's the node you're targeting with your overlay May 11 16:28:04 it has no status = "disabled"; property May 11 16:28:43 hence trying to enable it with status = "okay"; in the overlay has no effect May 11 16:29:11 the pinctrl properties are modified, but this has no effect since the driver is already loaded May 11 16:31:36 zmatt: thank you. really i'm quite confused: are you mentioning that if the uio_pruss already loaded, the overlay loading has no effect on pins? May 11 16:32:27 most if not all DT properties for a device are only consulted when the driver for it loads May 11 16:32:44 note however this isn't uio_pruss May 11 16:32:47 it's remoteproc May 11 16:33:01 which works totally different anyway, so even if your overlay worked, whatever you wanted to do with it probably doesn't May 11 16:33:09 solution May 11 16:33:15 sudo apt-get update May 11 16:33:53 apt-cache search -n '^linux-image-4.*bone[0-9]+$' | sort -V May 11 16:33:57 take your pick May 11 16:34:01 apt-get install it May 11 16:34:32 ok, I'm going to try. thank you May 11 16:34:34 I'd recommend linux-image-4.1.23-bone21 if you want to stay close to your current version May 11 16:34:48 or linux-image-4.4.9-bone10 to be more up-to-date May 11 16:35:01 (4.1 and 4.4 are LTS versions iirc) May 11 16:35:26 for comparison, here's the pruss node from 4.4.9-bone10: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.9-bone10/arch/arm/boot/dts/am33xx.dtsi#L461 May 11 16:35:42 ok. do you think there will be problems using -rt kernel? May 11 16:35:47 note it looks very different, and has status="disabled"; May 11 16:36:16 zmatt: yes, I see! May 11 16:36:37 I generally recommend against using an rt kernel unless you genuinely understand what it does, know you need it, and know how to tune your applications and overall system to take advantage of it May 11 16:37:01 without doing so, it just makes your system slower May 11 16:37:08 and possibly less reliable May 11 16:38:02 alfatau: FWIW I missed the line "pinctrl-0 = <&pru_pru_pins>;" in your fragment. as I understand that is the line that says you want to use/claim that group of pins. so ignore my comment May 11 16:41:01 zmatt: ok. thank you very much May 11 16:42:23 alfatau: I did as zmatt suggests and the PRUs work fine; remoteproc is in my xp an unmitigated nightmare for development. When your uio_pruss is working correctly you'll see stuff under /sys/class/uio relating to pruss. May 11 16:43:36 alfatau: btw, with the dts scripts from my py-uio project, you could write your overlay like this: http://pastebin.com/98vKYzNt May 11 16:43:39 :) May 11 16:45:48 anyhow, now _really_ afk :P May 11 16:45:49 zmatt: wow! if I'll be able to get it working, I'll try to use them! May 11 17:01:19 is reading the dt specification the best way to go on getting caught up to date on this thing? May 11 17:14:11 ayjay! did you see py-uio progress? :) May 11 17:14:26 well zmatt i just wrapped up finals last week and i'm taking a look at it now May 11 17:15:42 i'll take it out for a test drive in a lil bit May 11 17:16:05 two small examples that should actually work on a standard jessie system, and some real code for QEP (but for which I still need to make an overlay) May 11 17:20:15 okay, i'm itching to make some headway myself, ill update you a bit later May 11 17:23:45 ayjay: I'm still having weird issues with overlays May 11 17:24:20 whenever I try to do pinmux, I get in my kernel log: could not find pctldev for node /interrupt-controller@48200000, deferring probe May 11 17:25:02 the last time i checked i think you were editing the device tree directly? May 11 17:25:15 yeah that always works fine May 11 17:25:22 only overlays are giving hell May 11 17:25:57 note that the message above is completely chuckoo.... it's complaining it can't find the _pin controller_ for the interrupt-controller node May 11 17:28:08 i did see that May 11 17:28:42 i'm really shooting in the dark if i start theorizing tho until i crack it open May 11 17:32:18 I'm wondering if somehow the configfs way to load overlays has bugs that the bone_capemgr way doesn't May 11 17:32:32 that should be easy enough to verify May 11 17:32:36 but first afk May 11 19:35:16 ok, let's see if BUG_ON( strstr( np_config->full_name, "/interrupt-controller" ) ); yields anything insightful May 11 20:16:24 ARGH May 11 20:16:56 found the problem May 11 20:17:54 I invoked dtc without -@ so phandle refs within the overlay itself could not be fixed up May 11 20:18:13 yet dtc didn't feel a need to warn about this, even though it knows I'm compiling an overlay May 11 20:19:06 zmatt what version of python are you shooting for again? May 11 20:24:12 3.4 May 11 20:24:45 I pushed the fix, so hopefully no more "could not find pctldev for node" nonsense May 11 20:50:36 wow nice zmatt it works May 11 20:50:59 i wasn't getting the same error you had been getting though May 11 20:53:41 whats the output supposed to be for the l3-sn test? i was getting some warnings making the dtbo May 11 20:55:19 a bunch of zeros May 11 20:56:10 and yes Warning (reg_format) and Warning (avoid_default_addr_size) can be produced during builds, and safely ignored May 11 20:56:27 that's just dtc being an idiot again May 11 20:56:44 haha yeah i got a bunch of zeros, for sure May 11 20:57:05 i wasn't getting a pinctrl error btw i was getting a uio directory error May 11 20:57:26 but either way it disappeared May 11 20:57:32 (with the fix) May 11 20:57:39 there have been more fixes May 11 20:57:54 veremit had issues with my perl scripts so I tweaked those too May 11 20:58:21 the dtc warnings btw would have been legit if the input it was fed was an actual device tree May 11 20:58:55 do you think i should still tackle a library for ADC access? May 11 20:58:56 but the stuff inside an __overlay__ node aren't truly children of that /fragment@0/__overlay__ node May 11 20:59:14 rather, they're children of the node being targeted for overlaying May 11 20:59:23 its checking code however doesn't know that May 11 20:59:36 and issues bogus warnings as a result May 11 21:00:19 does inserting the adc overlay work? May 11 21:01:18 the one that ships with the BBB does with it's driver tsc_adc May 11 21:01:29 oh i see you have one too, lets see May 11 21:01:34 i'll let you know May 11 21:02:22 if insertion is successful, then look at ti/qep.py for an example on how to declare the structure of a peripheral May 11 21:03:27 see l3-sn-test.py on how to make things like bitfields May 11 21:03:31 if you need them May 11 21:57:05 for the address field do we use the physical address ie in the TRM or something else May 11 22:01:37 Hi all.. bit of a weird shot in the dark but I cannot track this down anywhere. I am trying to track down the u-boot I can check out with a git sha b2412df, I've got a board that boots with "U-Boot 2015.01-00001-gb2412df" but I cannot find this commit ANYWHERE. May 11 22:02:00 I can find a TON of other people booting it on forums May 11 22:03:26 but I absolutely cannot find this commit anywhere in the mainline u-boot, the beaglebone u-boot, the RobertCNelson u-boot... May 11 23:15:57 Hello, I'm new to the BeagleBone world, and I was wondering, how many quadrature encoders can the processor handle? May 12 00:15:46 ayjay: why pm? May 12 00:16:05 doesn't matter, i just got it working May 12 00:16:25 ayjay: address field? you mean the reg = <> in the DT fragment? that's the physical address (or well, the address relative to the parent bus in the DT) May 12 00:16:35 though usually you won't need to define it, it's already in the main dt May 12 00:16:54 yeah i figured out it was relative to the parents after i tree'd out the uio sys directory to figure out how that driver works May 12 00:17:06 the "l3s" and "l3f" arguments to .map() in the l3-sn example are referring to the fact it has two memory regions defined in the dtsi May 12 00:17:08 so i literally just got it working < 1 min ago May 12 00:17:26 (they are the "reg-names") May 12 00:17:29 i read through all your code most of it i get not all of it May 12 00:17:40 woo :) May 12 00:17:41 and yeah i had to add reg-name field to your overlay to access the adc registers May 12 00:17:47 no May 12 00:17:51 see qep May 12 00:18:05 you don't need to pass any region index/name if there's only one May 12 00:18:38 wait you can acces by index too? May 12 00:18:51 look at the last line of ti/qep.py May 12 00:18:53 self.regs = self.map( Regs ) May 12 00:19:11 cause i looked up the default name which was memoryaddress@label and that didn't work so i reg-named it and it works May 12 00:19:32 there's no need for reg-names unless the device has multiple regions May 12 00:19:46 which is rare May 12 00:20:01 and even then you have the option of just using the index instead May 12 00:20:04 theres a tsc-adc and a adc-dma region May 12 00:20:08 i didn't know i could pass an int May 12 00:20:11 ahh May 12 00:20:21 i'm actually just learning python at the same time i do this and dynamically typed languages freak me out May 12 00:20:45 great to learn by doing tho May 12 00:20:47 note: I'm a python-novice, so I may be doing things in stupid ways May 12 00:21:09 but check uio.py, look for the comment "allow lookup by index" May 12 00:21:50 so if you don't give it an offset does it map the whole region? May 12 00:22:06 i DID see that but somehow it didn't register May 12 00:22:09 in my brain that is May 12 00:22:32 and using the default name (containing the whole DT path) didn't work because I deliberately made it like that May 12 00:22:56 since those paths are not something humans should use in their code, they're not stable or future-proof May 12 00:23:40 well if thats the case shouldn't the adc overlay explicity state the memory region? May 12 00:23:46 otherwise your depending on the original overlay not changing May 12 00:24:06 original dt* sorry May 12 00:24:37 if the dma region has been defined then giving them reg-names might be a good idea... though there's actually still a future problem lurking there May 12 00:25:08 namely there's still a trend toward correctly modelling the interconnect structure and placing devices in their proper place May 12 00:25:56 problem is, the ADC's main port attaches to the L4WK while its dma port attaches to the L3S May 12 00:26:08 i.e. the device tree isn't a tree :) May 12 00:26:21 I still have no idea how they hope to solve that May 12 00:26:45 well it's two separate control registers... May 12 00:27:07 they're two target ports, but they attach to the same peripheral May 12 00:27:31 for different purposes, but that doesn't change they do belong to the same device May 12 00:27:42 yet they're in different places in the interconnect hierarchy May 12 00:27:45 i didn't realize that the DT was supposed to be modeled after the silicon May 12 00:28:00 well it isn't very much right now May 12 00:28:46 the only reason we can get away with that currently is because there are still large tables of hardcoded interconnect/prcm data in the linux kernel May 12 00:29:06 yeah that's what i read May 12 00:29:13 which is not very DTish May 12 00:29:23 that's what you're referencing with "ti,hwmods" May 12 00:29:41 i actually didn't know what to make of that May 12 00:30:05 anyhow, the main register space of the peripheral is always index 0, I'm pretty sure the driver also relies on that May 12 00:30:25 and index 0 is the default, so you can still just map( Regs ) May 12 00:30:26 :) May 12 00:31:35 yeah i'm gonna do some work on getting a better python ide running May 12 00:31:47 using the dma port for data transfer might be slightly speedier, but i'm not sure you're going to notice until the data rates are high enough that you wouldn't be using python to read the adc data anyhow (you'd be using DMA :P ) May 12 00:33:13 I'm not quite sure what the reasoning is for having a separate dma port May 12 00:34:40 oh you asked earlier about offset May 12 00:35:18 that's used when there are multiple register ranges within the same memory region declared in DT May 12 00:36:16 either out of laziness to declare them individually, or more importantly because only ranges which start and end of a page boundary can be directly mapped May 12 00:37:17 it'll become clearer when I finish the overlay for pwmss May 12 00:37:23 i need to reread your code because i don't understand it fully, but just enough May 12 00:37:33 how do you want to handle collaborating? May 12 00:38:08 (i only have it printing the status register I still have to make a nice structure for the whole region) May 12 00:39:48 qep actually has a tiny register range... 0x80 bytes. to map it you use the parent pwmss device, whose memory region is a full page and includes qep and friends, and then do pwmss.map( qep.Regs, qep ) .. except you don't actually have to write it like that since I allow specifying a parent MemRegion when you make an uio device which is then used implicitly May 12 00:40:04 this allows qep to be written and .map() itself without being aware of this complication May 12 00:40:32 but you obtain the qep instance from pwmss, which instantiates qep with itself as parent May 12 00:41:06 (you need to open the parent pwmss module anyway since its ti,hwmods associated prcm magic is necessary to access any part of the subsystem) May 12 00:41:46 and eh, dunno, via github I guess? May 12 00:41:52 ill just keep my fork updated May 12 00:42:20 pull requests can also be used as a way to get feedback May 12 00:43:07 I'll add some more comments here and there, especially uio.map() is rather opaque right now May 12 00:43:57 hahah that's the one! May 12 00:49:30 I think I'm just gonna restructure things a tiny bit there... I really don't like that map processes its arguments in such an awkward way it can't even properly declare them May 12 01:15:05 yes, this is looking better... May 12 01:21:20 pushed May 12 01:21:38 hi gays May 12 01:21:46 i hame some question May 12 01:21:51 I now require explicitly querying for a memory region if you want to map one other than the default May 12 01:22:00 slightly more verbose, but much clearer May 12 01:22:05 how to use tsc adc with edma?? May 12 01:22:57 heh, nice timing May 12 01:23:34 sorry guy's May 12 01:24:06 no it's just something funny :) May 12 01:24:08 but ehm May 12 01:25:59 if the kernel driver doesn't use it (haven't looked at it in recent times) then your options are: 1. learning to do kernel programming and fixing it yourself 2. convincing someone with the required expertise to implement it 3. disregard the kernel driver and setup things directly from userspace May 12 01:26:53 the funny part is that I've recently been working on code to make it easier to directly use peripherals from userspace, and ayjay is trying to get the adc working via that route :) May 12 01:27:28 so, I have study kernel driver May 12 01:27:34 no ur fine May 12 01:27:40 I do it from userspace myself May 12 01:28:01 I can use the ADC from kernel space just fine May 12 01:28:02 to a circular buffer, allowing me to read the most recent measurements whenever I want May 12 01:28:33 taylor__: sounds like ds2 may be offering to help you implement EDMA support May 12 01:28:36 the driver is drop dead simple May 12 01:28:40 and dma is working unstablely May 12 01:28:56 whateven is edma May 12 01:29:04 the adc is indeed pretty simple May 12 01:29:07 how is it unstable? May 12 01:29:27 (edma is also not hard, just documented in a way that makes it seem a lot harder than it is) May 12 01:29:47 the ADC can get a bit irate if you let things over flow May 12 01:29:49 ayjay: the insanely flexible DMA controller on most TI SoCs May 12 01:30:00 huh it's... different than DMA? May 12 01:30:17 ayjay: EDMA is just the name of the dma controller May 12 01:30:34 there can be more then one DMA controller May 12 01:30:45 how well they work is left as an exercise for the user :D May 12 01:30:48 hahaha May 12 01:31:43 *ahem*MUSB*ahem* May 12 01:31:46 sgx, lcdc, ethernet, and usb all have integrated dma May 12 01:31:57 EDMA however is the general-purpose dma controller May 12 01:32:34 ds2: I wonder though if it's really the hardware that's bad or just the driver May 12 01:32:42 zmatt: both May 12 01:34:09 :-O May 12 01:34:15 tsc_adc is no good? May 12 01:34:18 the dma hardware appears to be heavily borrowed from the Keystone "Multicore Navigator" May 12 01:34:22 ayjay: we're talking about usb May 12 01:34:25 oh May 12 01:34:34 ayjay: the adc is fine May 12 01:34:36 * ayjay goes back to work May 12 01:35:41 is any body have sample code??? May 12 01:35:51 ds2: I'm still slightly curious to play with it myself to see what it's actually capable is... my loathing of usb is kind of holding me back May 12 01:36:19 taylor__: I don't think many people are currently using the adc with dma May 12 01:36:26 taylor__: you can enable the BB_ADC cape May 12 01:36:39 ayjay: that would help... how? May 12 01:36:40 taylor__: then google TI tsc_adc driver and it will explain how it works May 12 01:36:49 ok May 12 01:37:05 zmatt: it maps whatever portion of memory is DMA'ed to a file in /sys/ May 12 01:37:06 taylor__: are you sure you need dma though? May 12 01:37:18 ayjay: oh it does support dma? May 12 01:37:22 yes May 12 01:37:23 nowadays May 12 01:37:40 i need adc with dma May 12 01:37:48 it has an "enable scan" file you can echo 1 to, and whichever channels are also enabled, it will dump those values into some file i forget the name May 12 01:37:49 taylor__: that's an odd thing to say though May 12 01:38:01 taylor__: you probably mean you need adc with certain performance criteria May 12 01:38:10 and you're *assuming* that means you need dma May 12 01:38:33 you could very well be right, but you're phrasing it as an X-Y problem May 12 01:38:41 dma is a means, not a goal in itself May 12 01:39:14 i want to sample 1KHz signal May 12 01:39:21 that's extremely slow May 12 01:39:34 but i don't want use cape May 12 01:39:45 1 kHz ? one channel? May 12 01:39:50 because i made custorm board May 12 01:40:34 Only one sample, periodically May 12 01:41:20 well, I guess dma is still preferable in case of unpredictable delays May 12 01:41:29 but it's really not high speed at all May 12 01:42:03 so, i set edma and TS ADC May 12 01:42:29 DMA1REQ and DMAENABLE_SET May 12 01:42:41 you don't directly do anything with DMA, the kernel does May 12 01:43:03 in my custorm device driver May 12 01:43:14 ?? why would you do that? May 12 01:43:22 oh well May 12 01:43:30 I'm sorry because my English is poor. May 12 01:43:57 ayjay just explained the built-in driver supports dma May 12 01:44:10 using that seems like the most sensible solution May 12 01:45:01 ayjay: btw, you approve of the changes I pushed? May 12 01:59:36 sorry zmatt i was at the store May 12 01:59:48 np May 12 02:00:16 silly taylor__ May 12 02:00:34 gawd the default DT definitions of pwmss are such a mess... I have no idea whether this overlay will work, but we'll see May 12 02:00:57 I don't have good experiences with using /delete-property/ in an overlay May 12 02:01:01 hey zmatt if we don't use capemgr then our overlays don't show up in it's list May 12 02:01:20 ayjay: and capemgr's overlays don't show up in configfs May 12 02:01:36 note that capemgr is meant for managing overlays for capes (based on i2c autodetection) May 12 02:01:43 using them for random overlays is technically abuse May 12 02:15:52 ohh, this might come in handy May 12 02:24:34 if it worked May 12 02:26:29 hmm? haha i just updated vim with a ton of plugins for python support :-D May 12 02:26:44 https://realpython.com/blog/python/vim-and-python-a-match-made-in-heaven/ May 12 02:31:08 simple-pm-bus ... would have been really convenient for pwmss, if it worked May 12 02:35:39 that's one thing I really don't like about python May 12 02:36:38 it is virtually incapable of performing meaningful checks on your code until it is actually run May 12 02:37:20 even in cases where I'd be inclined to say something is blatently an invalid/undeclared identifier May 12 02:37:37 it doesn't complain until execution actually reaches that point May 12 02:37:39 very annoying May 12 02:38:42 (see the two fixes I just pushed) **** ENDING LOGGING AT Thu May 12 02:59:58 2016