**** BEGIN LOGGING AT Sun May 15 02:59:58 2016 May 15 05:13:29 VKS LIVES! May 15 05:14:07 o,O May 15 05:14:29 new bone like board bring up :D May 15 05:14:43 kernel just booted May 15 05:15:24 it's aliiiiiiive May 15 05:15:52 this is fascinating too... https://www.youtube.com/watch?v=on3ZLLKQp-4 May 15 05:15:55 I did NOT mirror the BGA footprint by mistake May 15 05:16:22 ds2: is this your *special* board. . May 15 05:16:33 veremit: of course May 15 05:16:55 I see May 15 05:17:09 ds2: lol, that would have been slightly problematic to patch May 15 05:17:29 zmatt: yes, hence the big sigh of relief May 15 05:18:34 there been a few buggy footprints already. nothing kapton and jumpers can't fix so far May 15 05:19:45 http://www.thekirchners.net/rebol.jpg ;) May 15 06:07:54 so uio really is the best huh May 15 06:08:12 hmm? May 15 06:09:01 i just think it's great that you can open up so many features May 15 06:14:50 indeed :) kernel drivers are generally expected to implement some general/reusable interface, and rightly so, but often that involves some sacrifice of specific features of a peripheral May 15 06:16:02 having no abstraction layer means you get to use a peripheral to its fullest capacity. it too has a price of course, namely loss of portability, but in embedded systems the software is often tied to specific hardware already anyway May 15 06:16:48 i think the biggest problem with moving physical memory in userspace is security concerns May 15 06:17:08 most peripherals are not able to affect the rest of the system though May 15 06:17:34 but if you were controlling some essential machinery you wouldn't want to use uio May 15 06:17:40 ie in a power plant May 15 06:18:12 I don't see the reasoning here... May 15 06:19:31 my concern is that by bringing control out of kernel space into user space you make it more vulnerable to be attacked May 15 06:20:00 ie a 3rd party would have a greater change to execute specific damaging code May 15 06:20:01 not if the kernel is doing its job May 15 06:20:03 chance* May 15 06:20:14 and the system is competently setup May 15 06:20:19 just get rid of the kernel May 15 06:20:19 yeah i realize there are some other protective measures May 15 06:20:29 no point tohave the kernel if you do stuff in userland May 15 06:20:39 ds2: there's a lot of point of having the kernel May 15 06:21:01 in fact securely partitioning the system is one of its most important jobs May 15 06:21:02 zmatt: think we have agreed to disagree on that :D May 15 06:21:29 if userland has control of EDMA or the PRUSS, that is no do able May 15 06:21:32 not doable May 15 06:21:48 haha don't worry that's coming next ds2 May 15 06:21:55 all drivers in javascript May 15 06:22:06 ironally, PRUSS is probably the part of the am335x most commonly accessed using uio :P May 15 06:22:08 :D May 15 06:22:18 javastation v2? May 15 06:22:26 zmatt: trying to fix that May 15 06:22:45 jquery station v2 May 15 06:22:46 ds2: of course you can also setup the L3 and L4 firewalls instead May 15 06:23:04 the 335x retains the firewalls? May 15 06:23:08 thought that went away May 15 06:23:10 yes, they're fully functional May 15 06:23:16 is it documented? May 15 06:23:49 I'm sure there's documentation *somewhere*, but not in the public TRM if that's what you mean :) May 15 06:24:05 the omap4 trm however does document them May 15 06:24:22 and they work basically the same on the am335x May 15 06:25:00 so you can block PRU's access to most of the system May 15 06:26:50 EDMA is a bit more complicated... it is designed to proxy a security identifier (MReqDomain) of the initiator that configured the dma transfer, but unfortuately it appears that on the GP am335x all initiators have MReqDomain equal to zero and no way to change it May 15 06:28:04 :P May 15 06:28:15 (thanks TI, great job there) May 15 06:28:31 you are using unofficial features... May 15 06:28:35 I have the offset of the relevant register in the control module, but it behaves RAZ/WI May 15 06:28:56 probably only writeable by secure-world May 15 06:29:04 -.- May 15 06:30:21 ds2: every standard linux system for the am335x includes drivers for the AES and hash accelerators, yet they don't exist according to the TRM :P May 15 06:30:54 zmatt: i prefer they don't exists May 15 06:32:10 that's unfortunate.. the AES accelerator is fast enough that the bottleneck when not using DMA seems to be keeping it fed with data May 15 06:33:04 zmatt: u are not in the US May 15 06:33:36 don't tell me there is still export control bullshit about crypto? May 15 06:33:55 I thought that was a thing of the embarrasing past? May 15 06:34:02 zmatt: still very much exists May 15 06:34:19 so I have full faith in the manual saying there is no crypto accel. May 15 06:34:23 in TI I trust. May 15 06:34:35 except they have benchmarks on their wiki May 15 06:34:50 maybe that is a "special" version May 15 06:35:42 also listed in the datasheet as a feature May 15 06:35:52 @%#$@#@ May 15 06:36:27 if i figured it all out do i get a job May 15 06:36:27 even in the comparison table of all versions of am335x May 15 06:37:04 I have the aes accelerator fully figured out btw (the kernel driver only supports a subset of features) May 15 06:39:03 ( https://lkml.org/lkml/2015/9/20/58 ) May 15 06:42:26 jeez May 15 06:53:53 the fastest modes (such as AES-CTR-128) run at 160 ns per 16-byte block... that's about 95 MB/s May 15 06:54:14 reality does not quite reach that yet... http://processors.wiki.ti.com/index.php/AM335x_Crypto_Performance May 15 07:33:12 zmatt: the uio driver is normally used as a library to another c driver, but in this case we're using a generic uio driver? May 15 07:33:19 i'm tryin to clarify May 15 07:33:57 yes there's a uio framework and a generic uio driver that uses it May 15 07:34:33 specific uio drivers are sometimes needed for special irq handling May 15 07:34:46 thats actually why i'm asking May 15 07:35:02 are we at the best we're gonna get for generic irq handling? May 15 07:35:03 in particular on systems using shared irq lines, which is very common outside SoCs May 15 07:36:46 yes the generic driver is fine.. the only downside is that it supports only one irq per device, but if a peripheral has multiple irqs you can just make additional uio devices just for the purpose of hosting those irqs May 15 07:37:07 https://github.com/mvduin/py-uio/blob/master/dts/pwmss2.dtsi#L60 May 15 07:38:16 it'd be nice if you could specify the possible irq's in the dt May 15 07:38:29 and end up with separate files for each one May 15 07:39:06 it would it general be nice to generate DTs from a more intelligent format May 15 07:39:30 there's a lot of verbosity in them May 15 07:40:17 but peripherals typically have only one irq anyway May 15 07:40:34 maybe but especially with the adc May 15 07:40:35 i have like 10 May 15 07:41:23 no, it has many event, but those only set a bit in a register in the peripheral May 15 07:41:36 it has iirc only two actual irq outputs May 15 07:41:46 i see what you're saying May 15 07:41:53 i can differentiate with the irq flag register May 15 07:42:23 but you can only map one output with the generic irq framework, so you're missing some set of interrupts May 15 07:42:30 no May 15 07:43:00 those bits are all mapped to the same signal going to the cortex-a8 May 15 07:44:13 only one is treated specially, the "pen event" (I think the async pen event but I'm not sure) May 15 07:44:49 it's routed to irq 115, the rest all go to irq 16 May 15 07:44:52 hmm alriight May 15 07:45:12 it sleep time May 15 07:46:41 ayjay: https://goo.gl/O64hMr listing of irqs, for reference May 15 07:47:52 (including undocumented ones) May 15 08:00:02 don't forget to setup the M3 before the WFI... May 15 08:01:04 ... if for some reason you set the cortex-a8 to "disabled" in prcm May 15 08:01:49 which is generally a bad thing to do if you haven't made arrangements for it to be turned back on ;P May 15 08:02:29 doesn't strictly speaking have to be the M3 though, could also be PRU or even EDMA May 15 08:03:05 the M3 is however in a better position for the job (obviously, since it's its intended purpose) May 15 09:32:26 hello May 15 09:33:19 somebody easy with .dts for a cstom LCD 7inch screen? May 15 11:01:59 I am new here I need some help in updating software May 15 11:15:53 he also needs some help with being patient May 15 15:14:41 ayjay: what on earth is that bitblanket thing, other than an incredibly inefficient way to duplicate the functionality of ctypes.Structure ? May 15 15:15:19 the idea was to provide an interface to UIO that was ignorant of its implementation May 15 15:15:55 that inherently makes no sense May 15 15:16:03 you need to know the structure of the peripheral you're accessing May 15 15:16:30 that's not the point of it though May 15 15:17:24 its not meant to mask the structure of the peripheral, it's meant to give the programmer a class that is reminiscent of avr/arduino type programming regardless of what memory structures are used to map the registers May 15 15:18:08 I don't know what that type of programming looks like, but I really doubt they're doing lookups by name at runtime May 15 15:18:22 considering that probably wouldn't even fit in the memory of an avr May 15 15:18:25 you're right the dictionary look ups are week May 15 15:18:39 and also yeah, it's not a perfect match, but it couldn't be May 15 15:19:15 also, avr registers are probably all single-byte May 15 15:19:29 most yeah May 15 15:19:30 on the am335x the type varies and _matters_ May 15 15:19:42 that was also one of my concerns May 15 15:20:56 i'm not too familiar with its peculiarities yet. but one of the other reason for bit blanket (ignoring the inneficiency of dict at the moment) was because you expressed that the cstruct method might not be the best one May 15 15:21:36 note that l3_sn uses ("vendor", c_uint32, 16) instead of ("vendor", c_uint16) exactly because of the access size issue May 15 15:21:42 (using the latter would result in bus error) May 15 15:21:56 is that bus error at mmap or is it when reading and writing the structure? May 15 15:22:01 reading/writing May 15 15:22:10 such a pain May 15 15:22:16 you can never get a bus error at mmap May 15 15:23:30 note that the adc fifo also requires a lot of care May 15 15:23:52 yeah the fifo is intriguing May 15 15:24:33 i disabled all the steps but brought the enable hit in CTRL high and the fifo's were still changing value frequently May 15 15:24:52 i figured if all the steps were disabled the ctrl-enable wouldn't do anything May 15 15:25:00 it's not "changing value", you're reading garbage by attempting to read from an empty fifo May 15 15:25:21 it could easily have given a bus error instead May 15 15:25:42 ah i see May 15 15:26:08 yeah that's kinda where i left off before i wanted to address the mapping issues like the dict structure May 15 15:26:35 note that the fifo memory region is relatively large to allow reading multiple values in a single burst May 15 15:27:11 the data sheet says 104h-200h is reserved but i figured it was the rest of the fifo and was gonna inspect it May 15 15:27:29 i guess reading any of that tho will change the value, that i didn't know May 15 15:27:59 if the datasheet says that then someone fucked up May 15 15:28:22 I'm pretty sure the correct info is also somewhere in there, I know I didn't randomly poke around to discover it May 15 15:29:13 * ayjay shrugs May 15 15:29:21 each of the fifo areas is 64 words May 15 15:29:48 which is also the size of the fifo itself, so you can read the entire content of the fifo in a single burst if you'd want to May 15 15:29:54 it definitely wasn't in the register reference... May 15 15:31:10 so you can type it as c_uint32 * 64 .. but realize that the index you use to read that from array is actually ignored, only the number of elements accessed matter May 15 15:31:39 and should never be more than the fifo level May 15 15:32:37 oh okay that's pretty cool May 15 15:33:05 haha it lives up to it's name then... May 15 15:33:21 a typical example would be to program N steps which store data into the fifo, set the fifo's irq threshold to N-1, and when the relevant irq arrives read N words from the fifo May 15 15:34:28 also enable the fifo overrun and underrun irqs and print large error messages in all-uppercase when they occur :P May 15 15:34:30 yeah i can see that occuring in real time May 15 15:35:16 i'm kinda wondering what the latency is between threshold to irq process using these python libraries May 15 15:35:55 i'll test it out May 15 15:36:36 for debugging it's also useful to set bit 1 of the control register to verify that you're getting data from the steps you're expecting to get data from, although in production code it would just be annoying to have to mask it off May 15 15:36:51 yeah i like that bit May 15 15:38:21 I've tested irq latency with uio in C once and measured about 44-88 μs May 15 15:38:52 I don't think python will add much to that but I'd need to test to be sure May 15 15:41:42 btw, it's kind of pointless to specify field widths when that field is in fact the whole register May 15 15:41:53 (the ", 32" you have on nearly every register) May 15 15:42:18 or, not "nearly", I think every register May 15 15:42:49 also, '0{0}b'.format(32) == "032b" May 15 15:43:24 I actually just used that ugly construction because I needed a runtime-variable width May 15 15:43:53 oh i hadn't looked up the syntax on that May 15 15:43:57 i just copied it verbatim May 15 15:44:36 the preferred python3 syntax would be something like print( "{0:x}: {1:032b}".format( i, x3 ) ) May 15 15:45:58 are you convinced there might be a benefit to the bitblanket implentation, taking for granted it's issues at the moment? May 15 15:46:00 it's a bit like printf( "%x: %032b", .. ) would be in C or Perl, except %b actually isn't a valid format specifier in C May 15 15:47:59 that much i could guess but ill read the doc for the specifics May 15 15:48:18 i was so excited just to see the registers that i put it off May 15 15:48:22 hehe May 15 15:48:45 and no I don't really see the point of bitblanket May 15 15:50:07 I understand the desire for something like IterableStructure for debugging, although the problem is that in general it is unsafe to do with peripherals May 15 15:51:46 in general, both reads and writes act like method calls on the peripheral, even though most registers behave reasonably "memory-like", or at least safe to read May 15 15:52:04 the fifo however is an example of being unsafe to read May 15 15:53:31 hmm i think maybe there might be a compromise. i really like the idea of a very simple and standard interface to the peripherals, like indexing by offset May 15 15:53:35 it is worth considering actually omitting them from the structure and mapping them separately with e.g. adc.map( uint * count, 0x100 ) for some count May 15 15:54:05 so you don't iterate through them? May 15 15:54:21 on accident? May 15 15:54:29 then you can safely make the main registers iterable yes May 15 15:55:11 also, the fifos can be mapped via the dma memregion instead, which is slightly more efficient May 15 15:55:21 or not mapped at all if using dma May 15 15:56:13 yeah thats also on the list... May 15 16:01:44 "I'm thinking CSV or XML" .... XML?! ew ew ew why would you ever think XML? go wash your brain :P May 15 16:03:20 the existence of XML is a mistake. the applications for which it is the most suitable format are: none. May 15 16:03:53 it strikes a unique balance between the needs of man and machine by being equally hard to read for both May 15 16:05:48 in any case, that data is equivalent to a ctypes structure, except for being more limited in expressiveness May 15 16:06:05 and requiring code to convert it into a ctypes structure May 15 16:07:53 the only benefit is being able to specify offsets instead of having to insert spacers... it would be nice to extend ctypes.Structure in some way to allow that, although it will be difficult to do so elegantly May 15 16:10:20 ayjay: lol @ #if you can't tell, dynamic typing terrifies me May 15 16:11:14 that line is horrible though... one of the big benefits of python for low-level stuff is that it actually has integers which behave saner than they do in C May 15 16:12:14 ctypes.c_ubyte(255).value is not "statically typed", it's just 255 except with the pointless creation and destruction of a temporary object May 15 16:21:33 the only thing to be cautious of is division... a/b gives a floating-point result, if you want explicitly want integer division you need to write a//b May 15 16:22:40 on the other hand, for integer division python again behaves saner than C and uses floored rather than truncated division May 15 16:24:35 which means n//2 and n%2 are equivalent to n>>1 and n&1 respectively, also for negative n May 15 16:24:54 yeah i guess ill take your word on python behaving more sane at C, it really bugs me that i sys.getsizeof(someVar) and if it's a ubyte it gives me 10? 12? 14 sometimes May 15 16:25:24 ctypes.sizeof May 15 16:26:50 actually no, if it's variable then you probably did it on an integer value? May 15 16:27:56 asking sizeof those makes no sense, an integer is just an integer, it doesn't remember that it came from a c_ubyte May 15 16:28:15 no i'm doing it on the variable itself May 15 16:28:57 if you want to know the size of the memory represented by a ctypes object, use ctypes.sizeof May 15 16:28:58 i use this interactive parser to kinda learn python as i do this and yeah i just tested the ctype.sizeof which of course works exactly as it should and gives me a lot of relief May 15 16:33:34 i wish python had macros May 15 16:35:15 ... you can actually even generate new types or compile code at runtime... wishing for such a limited and error-prone mechanism as C macros is probably just because you're used to them :P May 15 16:35:31 don't get me wrong, python doesn't come naturally to me yet either, I'm also still learning May 15 16:36:57 meh i'm trying to fend off the death of bitblanket May 15 16:37:03 without making things too ridiculous May 15 16:37:39 i *really* like it's front end and i realize theres problems on the backend May 15 16:38:38 I still don't really understand what it's supposed to offer that you don't have with a struct, other than iteration which you solved with IterableStructure (which however should never be the default due to the hazards I explained) May 15 16:40:01 it just reduces the complexity for people who just want to access the registers and use the datasheet to program things May 15 16:40:48 tons of students at my school have a lot of success with the AVR style programming which is just a) look at the datasheet b) write a value to the offset May 15 16:42:03 of course we do things in (not canonical) C and without structures so theirs a headerfile that maps a bunch of register names to their physical addresses via precompiler directives May 15 16:42:22 fair enough, I can understand that, but the problem is that you'll at least need the type in addition to the offset May 15 16:42:31 yeah you need the length? May 15 16:42:59 for the issues like in the l3 May 15 16:43:02 if your universe only consists of unsigned integers, yes :P May 15 16:43:34 hahahaha uint8_t and uint16_t May 15 16:43:54 i would like to remove the dictionary lookups and make something more efficient there May 15 16:44:18 and then theres restricting access to the fifobuffers when iterating (i don't really need to iterate beyond debugging i guess) May 15 16:44:28 the l3 shows you may also need to specify an access size that is different from the size you're trying to read May 15 16:44:58 i really like UIO because not only can we write highlevel device drivers for the BBB/Arm but it also allows students to experiment with programming registers May 15 16:46:00 if it's possible to use a simple dictionary (albeit not one that has to do costly searches at run time), you could use the same libuio code, bitBlanket, UIO, MemRegion, etc and easily port it to other devices May 15 16:46:56 the uio code is not device-specific, although code for specific peripherals usually is May 15 16:47:45 i was just thinking that there would be one file per peripheral/device May 15 16:48:06 like ti/qep.py May 15 16:48:30 i just read that yesterday, i understood it but i haven't figured out how it fits into the big picture yet May 15 16:49:04 which is actually why I put it in a subdir "ti" .. I regard it as vendor-specific library code rather than as mere example code that I dumped into the top-level of my project for now May 15 16:49:21 so basically my idea of a dictionary file is just an include with the c-structure May 15 16:51:24 representing a peripheral adequately by some data structure is something I desire, but I know that doing so adequately is actually going to be quite complicated May 15 16:51:55 devicetree-ception May 15 16:51:56 if it were simple and obvious, I would have done so already May 15 16:52:07 devicetree is very dumb in fact May 15 16:52:29 i mean i realize that it's a pretty dumb datastructure but do you also mean poorly designed? May 15 16:52:47 C structures are also inadequate... that's something I fight with all the time when programming in C/C++ May 15 16:53:10 i don't know what you want with them May 15 16:53:11 it's a datastructure designed to be read *and produced* by code rather than by humans May 15 16:53:25 DT was never intended to be written by humans May 15 16:53:31 oh May 15 16:53:50 that's a perversion that came after it was created May 15 16:54:05 well its all i know May 15 16:55:57 and the problem with C is that the optimizer will happily turn your code into garbage because you weren't able to inform it of relevant constraints May 15 16:56:06 like with the l3-sn May 15 16:56:52 python is sadly doing better here simply because the memory accesses aren't optimized at all, which is also not exactly desirable but still better than crashes I guess May 15 16:57:43 also, intuitively it feels less offensive because it's already a high-level dynamic language with its associated overhead/costs May 15 16:57:53 in exchange for which you do get a high-level dynamic language May 15 16:58:22 im not completely warm to python yet May 15 16:58:37 while in C, being forced to do extra work to *prevent* optimization feels downright offensive May 15 16:58:43 volatile? May 15 16:59:50 volatile is indeed a blunt instrument to inhibit optimization, although by default it doesn't work on bitfields May 15 17:00:18 lol, python May 15 17:00:43 good luck with real time execution with python :) May 15 17:00:48 I've still had bus errors on the l3-sn just by reading multiple volatile u32 at once May 15 17:01:32 (the compiler thought it was still okay to use an "ldm" instruction. it thought wrong.) May 15 17:03:01 mrx1_: I probably wouldn't, although it's not altogether evident whether it would be a problem to do so May 15 17:03:59 at long as the overhead isn't unpredictable there may not be a problem ... I recall mention of an optional cyclic garbage collector being enabled by default, that may need to be disabled May 15 17:05:16 i.e. gc.disable() May 15 17:10:31 mrx1_: of course "real time" is a relative term... ultimately most things need to do their job in a reasonable timespan to be considered "usable" May 15 17:13:43 it's not like the python libraries are meant to compete with the prus... May 15 17:15:00 note that "real time" does not need to be *fast*, in fact getting deterministic latency is often antagonistic to performance. e.g. linux-rt kernels are overall less efficient than non-rt kernels May 15 17:15:43 ohhh so thats how they do that May 15 17:15:52 i always thought it was a matter of premption May 15 17:17:11 it is a matter of preemption... it needs to be able to switch to higher-priority code at basically any moment May 15 17:17:28 in a normal linux system it can't do that while inside an interrupt handler May 15 17:17:54 no i get it May 15 17:18:05 i said that ambiguously sorry May 15 17:19:15 what linux-rt changes is two things: 1. irq handlers become kernel threads 2. "spin locks", which on non-SMP kernels actually just disable irqs, are turned into priority-inheritance mutexes May 15 17:20:29 zmatt how do you all these thigns May 15 17:20:32 needless to say, performing a thread switch has more overhead than a normal irq handler, adn acquiring and releasing a PI-mutex is considerably more expensive than disabling and reenabling interrupts May 15 17:20:42 you know * May 15 17:21:01 hehe May 15 17:21:54 at work my boss was giving an intern a tour and jokingly introduced me as "the oracle" May 15 17:23:58 i'm pretty sure oracles took psychedelics to gain their knowledge May 15 17:24:31 if theres a drug from what you've got let me know May 15 17:24:33 for* May 15 17:24:36 linux-rt is kind of funky though... being able to raise the priority of a userspace thread above that of kernelspace irq handlers, or conversely demote an irq handler to non-real-time is pretty weird May 15 17:25:48 lol, psychedelics have on occasion left me with greater self-knowledge, but I've never suddenly ended up knowing stuff about the linux kernel May 15 17:29:22 I actually have a nice example of -rt's strength and weakness: I noticed that (at least in the linux version I was then testing) the ethernet driver wasn't particularly efficient and ping-flooding a beaglebone actually caused the gui to occasionally hiccup on a non-rt kernel May 15 17:29:58 on the rt version of the same kernel, the gui didn't just hiccup, it completely froze solid (including mouse cursor) as long as the ping flood was going on May 15 17:31:03 however, demoting the ethernet irq handlers from SCHED_FIFO ("real-time") to SCHED_OTHER ("non-real-time") fixed the problem entirely May 15 17:32:04 conclusion: while the kernel was actually less efficient hence coped with the ping flood more poorly by default, you do gain more control over scheduling that you otherwise wouldn't have May 15 17:38:29 I'm glad rt isn't the default anymore though (like it briefly was in testing images) since to benefit from it you need to ensure all threads on your system have priorities that suit the overall application of your system, which is something most people aren't going to bother with May 15 17:40:59 in fact I noticed the default has moved from CONFIG_PREEMPT__LL to CONFIG_PREEMPT_VOLUNTARY May 15 17:41:57 (in recent -bone kernels anyway) May 15 17:42:06 May 15 20:07:07 I'm using Debian 8.3 image on beaglebone black. The problem is when i move the mouse, the cpu does 100%. And the whole system feels slow and laggy too. I think its because of graphics driver. May 15 20:07:33 Does debian have the graphics driver for powervr sgx? May 15 20:08:23 dasd May 15 20:08:27 asdlkja May 15 20:08:27 skdal May 15 20:08:28 sdaskld May 15 20:08:28 askd May 15 20:08:29 akldkal May 15 20:08:29 sdklaksdka May 15 20:08:30 sdkl May 15 21:18:30 that's a very interesting contribution, do tell more :P **** ENDING LOGGING AT Mon May 16 02:59:59 2016