**** BEGIN LOGGING AT Mon Feb 08 02:59:58 2016 Feb 08 03:53:15 hello guys Feb 08 03:53:34 can you help me ? Feb 08 03:54:53 how to use cloud9 to program and compile into beaglebone black ? Feb 08 04:22:55 ping Feb 08 05:05:37 can threads within the same process preempt one another? Feb 08 05:08:23 i'm getting zeros from read() when there shouldn't be zeros. i'm wondering if another process is preempting and overwriting the variable where the character is stored, since threads share memory space. but i'm not even sure this isn't a hardware problem. Feb 08 05:08:52 just theorizing at this point. Feb 08 05:09:55 also, what does linux do with the data if there was an error (i.e., if read returns -1)? does it zero it? Feb 08 05:11:29 i.e., if there was a parity error Feb 08 05:12:23 ot Feb 08 05:12:31 test Feb 08 05:12:43 it's just a serial port. ttySxyz Feb 08 05:15:35 threads can absolutely preempt each other.... they're basically the same as processes, but with shared memory space (and couple of other things) Feb 08 05:16:11 ouch. Feb 08 05:16:38 that means that every thread has the potential to corrupt every other (within a process) at any point in time... Feb 08 05:16:47 parity error afaik does not result in an error code, instead (assuming parity is enabled) a substitution char is used Feb 08 05:17:11 if you don't use appropriate mutexes or other synchronization constructs, yes Feb 08 05:17:17 no no no Feb 08 05:17:33 i meant WITHOUT synchronization. PRE-EMPT Feb 08 05:17:34 I personally hate threads and avoid them whenever possible Feb 08 05:17:38 yes Feb 08 05:17:52 they can preempt, hence you need to use e.g. mutexes to protect shared data structures Feb 08 05:17:53 what does a mutex have to do with it? Feb 08 05:18:22 it's what makes threaded programs able to work at all :P Feb 08 05:19:11 oh yeah. Feb 08 05:19:18 i was thinking semaphore Feb 08 05:19:24 or, well, there are alternatives Feb 08 05:20:14 i knew this. Feb 08 05:20:16 i forgot it. Feb 08 05:20:27 i've written my own mutex-protected code ... Feb 08 05:20:29 so how do mutex's work . Feb 08 05:20:29 ouch. Feb 08 05:20:38 I've been tryin gto get my head around threading Feb 08 05:20:42 and I kinda need to Feb 08 05:20:43 like write messages to a shared ring buffer, issue memory barrier (compiler barrier suffices on uniprocessor), send a notification to the other thread that it should grab messages from the ring buffer Feb 08 05:21:05 veremit: are threads being forced upon you? poor you Feb 08 05:21:11 zmatt: about what about multicores Feb 08 05:21:15 i like threads. very much. Feb 08 05:21:27 keep in mind that on a uniprocessor using threads will decrease performance Feb 08 05:21:28 no .. sad as it may sound .. I *want* to use threads to increase performance on an app Feb 08 05:22:00 that and I have quite a slow IO routine .. until such time as I go event-driven .. Feb 08 05:22:19 go event-driven :P Feb 08 05:22:35 yeah I dunno how to do that in.. wait for it ..perl ... Feb 08 05:22:53 I think python is in my future .. Feb 08 05:23:13 bear in mind this is what I'm paid for .. lol ;p Feb 08 05:23:21 [allegedly] Feb 08 05:23:23 if you care about parallel processing in your app. i didn't. it was the am3358 anyway. Feb 08 05:23:45 naa, this is x86 Feb 08 05:23:49 or x64 Feb 08 05:24:13 I'm likely moving up from a dual to quad-core .. so .. makes sense Feb 08 05:24:19 veremit: perl has threads, though using fork() is often more lightweight Feb 08 05:24:26 veremit: python is single-threaded Feb 08 05:24:38 brb, grabbing some food Feb 08 05:24:40 real men use c/c++ Feb 08 05:24:48 shup . not my choice :p Feb 08 05:25:01 grows hair on the chest. Feb 08 05:25:10 :) Feb 08 05:25:22 yea I heard perl does threading .. safely too .. Feb 08 05:26:46 got in a mess last time I used fork iirc, lots of zombies lol Feb 08 05:27:36 i use posix threads. once you get the hang of them they're easy Feb 08 05:27:52 yeah I did some event driven threaded stuff in c# years ago Feb 08 05:27:58 but i didnt' write the core code Feb 08 05:28:11 it worked well Feb 08 05:28:14 i also made threads message-based. Feb 08 05:28:57 I could easily re-create the front-end using wxwidgets once more .. but it'd take a while to translate all the back end code. Feb 08 05:29:04 and I *hate* pointers. Feb 08 05:29:10 i had a project last year, 20000 LOC with over 20 threads. worked beautifully. Feb 08 05:29:28 including a server. Feb 08 05:29:54 you have good code-fu Feb 08 05:30:00 yates: if you're working message-based, why use threads instead of processes? Feb 08 05:30:18 i defined my own client/server protocol, i.e., and implemented the server on the bbb side and the client using Qt on the pc side Feb 08 05:30:36 zmatt: seemed approprite. threads save memory. Feb 08 05:30:43 approrpiate Feb 08 05:30:45 why not? Feb 08 05:30:51 save memory? huh? Feb 08 05:31:42 why not? because the benefit of using message passing is that you can avoid threads and use processes instead :P Feb 08 05:31:54 which e.g. can't corrupt each other's state Feb 08 05:32:27 they're also slightly faster (linking against libpthread will causes many libstdc calls to become slower) Feb 08 05:33:10 threads share process state. Feb 08 05:33:17 thus they save memory in that manner. Feb 08 05:33:30 but if ... nvm. lol. Feb 08 05:33:52 zmatt: question: if threads are so evil, why does ANYONE use them for any purpose? Feb 08 05:34:01 except they're not actually *sharing* that state, other than e.g. readonly stuff and that gets shared with processes too Feb 08 05:35:00 zmatt: you spawn a process like you might a thread? Feb 08 05:35:50 because 1. they seem benign 2. they're a minor syntactic extension (versus going event driven) 3. probably other historical reasons.... see also http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf Feb 08 05:36:15 veremit: and things inbetween (see man clone) Feb 08 05:37:38 but never mind the pros and cons, sometimes threads are the path of least resistance (e.g. lots of existing synchronous code) Feb 08 05:38:23 like i said, i had 20000 sloc running without a problem. Feb 08 05:38:29 20+ threads Feb 08 05:38:51 i like them. Feb 08 05:39:00 vermit: you wanted to know specific details? "so how do mutex's work" ... behind the scenes you mean? or? Feb 08 05:42:42 zmatt: just overviews at this point .. I want to figure how much effort is involved in translating a moderately large (production) program into one thats multithreaded. Feb 08 05:43:01 zmatt: I nearly understand -some- of the basic principles lol Feb 08 05:43:16 zmatt: but I never did software engineering ever. Feb 08 05:43:29 .. and I find myself wishing I had. Feb 08 05:43:57 unless you can excise the slow parts extremely well (such that you might as well use a separate process for them) it will probably be a nightmare Feb 08 05:44:03 * veremit reading perlthrtut Feb 08 05:44:39 python may be an exception if you're trying to deal with slow I/O Feb 08 05:44:47 since it allows Feb 08 05:44:58 zmatt: the app has a lot of slow IO .. or relatively slow IO .. which could occur in parallel Feb 08 05:45:10 multiple threads, but they grab the Big Interpreter Lock whenever python code is executing Feb 08 05:45:37 however when it does an OS call for which it needs to wait, the Big Interpreter Lock is dropped and another python thread gets to run Feb 08 05:46:12 perl ithreads are... pointless if you want me Feb 08 05:46:34 you get separate interpreters, and it's actually considerably slower than forking Feb 08 05:46:41 *if you ask me Feb 08 05:47:56 yea I didn't think perl threading was a 'good' model Feb 08 05:48:10 if you 'fork' though .. do you not lose any interaction .. Feb 08 05:49:34 you keep open file descriptors (hence you can communicate through pipes/sockets), memory specifically mapped as shared Feb 08 05:51:29 with threads you have shared state, but that means that all access to that shared state suddenly needs (with rare exceptions) to be protected with a mutex or similar to avoid corruption issues Feb 08 05:52:14 sooner or later you need to grab multiple mutexes for some operation, a bit later you'll have your first deadlock :P Feb 08 05:52:24 heh Feb 08 05:52:39 yeah all these kinda things don't really instill enthusiasm Feb 08 05:56:01 see also the paper I linked (originally found in the SQLite FAQ) Feb 08 06:04:32 I'll read when my brain is capable lol Feb 08 06:06:45 surely .. if you're not using shared data structures (or few or minimal) your exposure to the "dangers" of threading are much mor elimited .. Feb 08 06:07:11 I mean , if you're using OOP, you will be passing data to/fro, not relying on global variables or shared resources necessarily. Feb 08 06:12:27 time for more rest before mayhem begins/resumes .. Feb 08 07:49:13 Can i wake up the PRU0 after SLP 1, only used C# code? I tryed use prussdrv_pru_reset(0) - doesn't work. Feb 08 10:23:25 Is there a way to view details about the installed cape on the BeagleBone Black from the OS? Feb 08 10:23:59 Hewball: ^ Feb 08 10:27:12 if the cape has a I²C EEPROM you should be able to query that Feb 08 10:27:33 the elinux wiki should also have more details and options Feb 08 10:54:29 blahdeblah: cat /sys/bus/nvmem/devices/at24-1/nvmem |hexdump -C for a 4.1 kernel Feb 08 10:54:54 or for 3.8 kernel cat /sys/bus/i2c/devices/1-0054/eeprom |hexdump -C Feb 08 10:55:26 Hewball: ta Feb 08 10:56:55 Shows up as /sys/bus/i2c/devices/2-0054/eeprom on my 4.4 kernel Feb 08 10:58:42 yeah its been moving around recently Feb 08 14:05:01 vermit / stt_michael: if you're not using shared data structures (note that this includes shared objects) then there's no reason to use threads instead of processes. if the primary means of interaction between the threads is passing data (handing over exclusive access) from one thread to the other, this is called "message-passing". You could use a pipe or socket for that, although using shared memory may in Feb 08 14:05:07 deed be faster (but requires a shared ... Feb 08 14:05:09 ... datastructure for bookkeeping this handoff). Note that it is perfectly possible to use explicitly share some memory between processes as well, but this is still a lot safer than sharing all state by default Feb 08 14:15:00 panto: ping Feb 08 14:15:57 dwery, what's up? Feb 08 14:16:09 panto: it's getting better. I moved to your latest tree and tweaked a few things. had to remove cs-gpios since it doesn't work (and I saw you have already patched mcspi), I'm still struggling with spi->irq being zero. did anything change wrt interrupts? Feb 08 14:16:31 not that I know of Feb 08 14:16:43 all that stuff has nothing to do with the overlays code though Feb 08 14:16:54 what changed in the drivers? Feb 08 14:16:58 I guess something bad happened in mcspi / spi framework Feb 08 14:17:09 with 3.8 i was getting a valid ir in spi->irq Feb 08 14:18:16 * panto shrugs Feb 08 14:18:29 if the driver's probe methods are called, overlays work Feb 08 14:18:40 no idea about what's going on for the spi driver Feb 08 14:18:48 oh well.. I'll stay with 3.8 for now, I don't have time to debug every single issue. thanks anyway! Feb 08 14:21:06 veremit: btw, classic problem with shared resources and potential for deadlock (though they explicitly avert it by globally ordering the mutexes) -> https://doc.rust-lang.org/book/dining-philosophers.html Feb 08 14:23:40 also, Rust is an interesting lang in that it is very explicit about ownership and has strong guarantees of data safety (most of it checked at compile-time) Feb 08 14:28:12 (though deadlocking is still possible. E was an interesting experimental language which solved that by using promises/futures pervasively and having no blocking operations whatsoever. then the only form of "deadlock" possible is a cycle of promises (a "data lock") which is detected and broken by the garbage collector) Feb 08 15:04:18 t Feb 08 15:06:47 veremit: here is my favorite reference on posix threads, in case you want to use them: https://computing.llnl.gov/tutorials/pthreads/ Feb 08 15:55:58 btw.. am I the only one who thinks systemd shouldn't be on a system like the beaglebone? and has anyone managed to remove it? Feb 08 15:56:24 dwery, it solves so many other issues. ;) Feb 08 15:56:43 dwery: hard to remove it when so many distros/users are moving to it. Feb 08 15:57:05 dwery: the monolithic nature is a bit disturbing, agreed, but it does work and work reasonably well. Feb 08 15:57:39 dwery, you can run without it in wheezy, editi /boot/uEnv.txt but everytime you run into an issue that needs resolved related to booting, usually it turns out the systemd guys already fixed it.. Feb 08 15:58:10 rcn-ee: I hadn't any issue before systemd :D I've removed it under wheezy but not yet tried under the latest 8.x images Feb 08 15:58:33 jkridner: agreed on the "many distro" things, I'm actually using it on my desktop (well, I'm forced to use it) Feb 08 15:59:03 dwery, so on 8.3, without systemd: time doesn't get synced, shutdown is broken... (quick ones).. Feb 08 15:59:08 dwery: replacing a collection of crufty shell scripts by a systemd-equivalent written in C tends to result in a leaner system (notably switching from ifupdown to systemd-networkd decreased boot time. it isn't used yet however in jessie since its systemd is too old) Feb 08 15:59:28 jkridner: but for the servers and embedded stuff.. it's not going in on my watch, I'd erather switch to freebsd Feb 08 16:00:24 the systemd components overall seem much better integrated Feb 08 16:00:27 dwery, freebsd controls all the startup scripts.. whereas non-systemd, you have 100 random scripts... Feb 08 16:00:43 rcn-ee: once they moved to systemd it's obvious that bugs will apper on non-systemd systems. you can't keep them both I think Feb 08 16:00:59 zmatt: I don't need boot time, I boot once in a while ;) Feb 08 16:01:35 e.g. if you cold-boot without network, then as soon as you plug in network networkd will bring it up, obtain an ntp server address, and timesyncd will fix the rtc up Feb 08 16:01:57 rcn-ee: I just hope the freebsd peaople will keep them this way, it will be hard to switch once, don't want to do it twice :D Feb 08 16:01:59 dwery: boot time matters a lot for many embedded systems Feb 08 16:02:22 zmatt: probably yes, I boot my embedded once in a while and tey usually boot in a few seconds Feb 08 16:02:25 where as non-systemd, we had issues where ntpdate would fail, because network wasn't setup ... just the fact systemd & systemd-timesycn actually "communicate"... Feb 08 16:03:00 rcn-ee: my ntpdate is run whenever the interface goes up, with ifupdown scripts ;) Feb 08 16:03:38 dwery, and why wasn't that pushed as default? another "random" script.. where systemd just does it. :) Feb 08 16:04:44 rcn-ee: I don't know, I'm not in charge of that :) except that I can read and manage any "random" script.. good luck booting a damaged system that requires systemd to recover it ;) Feb 08 16:05:45 dwery: it's a lot easier for a system to get damaged in the first place if it depends on a large incoherent collection of boot scripts, some of which are distro-updated and others written/customized by the administrator :P Feb 08 16:05:59 btw.. I don't really want to argue, I know that systemd is there and will stay there. I was just wondering how many people actually support this new kind of stuff Feb 08 16:06:08 * zmatt raises hand Feb 08 16:06:21 i do! ;) Feb 08 16:06:37 today I saw a bug report where someone decided to change the output of the "ls" command, so I don't really have any hope :) Feb 08 16:06:39 (i was against it for awhile..) Feb 08 16:06:49 * jsmith supports systemd as well Feb 08 16:07:01 dwery: yeah, shell scripting in general is very error-prone Feb 08 16:07:32 zmatt: sure. because people can't do that kind of stuff anymore :) Feb 08 16:07:49 dwery: no, because it's much easier to do it wrong than to do it right Feb 08 16:08:04 zmatt: then I must have been lucky xD Feb 08 16:08:06 blah $path vs remembering to do blah "$path" Feb 08 16:08:18 or, if blah allows it, blah -- "$path" Feb 08 16:08:52 I find it very easy :) Feb 08 16:08:55 a no brainer Feb 08 16:08:58 dwery, remember we are dealing with this generation now: http://developers.slashdot.org/story/16/02/07/0624258/drag-and-drop-cs-tutorials-the-emperors-new-code Feb 08 16:09:13 rcn-ee: I know :( Feb 08 16:09:46 I actually stopped any linux kernel development due to the way things are going. I can't just can't hold it. Feb 08 16:10:28 I'll teach assembly to my kids. Feb 08 16:11:36 I also have no idea how to accomplish anything in the kernel... too often when I examine something, I end up in a endless maze of code where documentation is absent or wrong, I have no idea what preconditions or constraints apply where, etc Feb 08 16:12:16 zmatt, has any of that the tilcdc re-write (rip out) fixed your lcd side tearing issues? Feb 08 16:12:20 probably if you do full-time kernel hacking then sure Feb 08 16:12:33 zmatt: You learn by reading the code. A lot of it. It takes years. And that usually allows to filter out people. usually. Feb 08 16:12:35 rcn-ee: have not yet had the chance to test it... Feb 08 16:12:49 ah okay.. Feb 08 16:14:54 rcn-ee: the customer has all working demos of that board, another one looked nearly-assembled but finishing it isn't a priority for the team. I also have a small HDMI screen but it hasn't exhibited any of the issues on any of the kernels Feb 08 16:15:11 so apparently timing parameters may play a role Feb 08 16:24:41 rcn-ee: btw, is the tilcdc rewrite only in 4.1-ti or also other branches? Feb 08 16:32:38 zmatt, yeap, just in the 4.1-ti branch... Feb 08 16:33:06 Jyri posted it for v4.6-rc0... Feb 08 16:35:29 ok Feb 08 16:41:43 Hey everyone. Quick question that I can't find confirmation about. If I boot from uSD and remove the virtual eMMC cape, can I use those pins as GPIO? Or are the MMC pins required for other functions? Feb 08 16:42:10 kbr_, as long as the eMMC is held in reset, you can use those pins for anything.. Feb 08 16:42:31 rcn-ee: note that the eMMC reset pin is not enabled in eMMC config by default Feb 08 16:42:49 it shoudl be by the main *.dtb.. Feb 08 16:43:10 but in 3.8.x i'd have to look again. .;) Feb 08 16:43:16 rcn-ee: I'm referring to OTP config in the eMMC itself Feb 08 16:43:49 really? so we have the physcial gpio pin, but the eMMC is not setup to use it? Feb 08 16:43:56 enabling the reset pin is a potential security vulnerability hence it's not enabled by default but a one-time programmable decision Feb 08 16:44:30 note however that eMMC is also safe if: Feb 08 16:44:36 1. you leave the cmd pin high, or Feb 08 16:44:44 2. you don't toggle the clk pin, or Feb 08 16:45:23 3. you send eMMC a command to enter inactive state at boot time (involves the cmd and clk pins) after which it will withdraw itself from the bus till next power up Feb 08 16:45:56 4. really, do you expect to perform a successful initialization sequence (with correct CRCs in the command) *by accident* ? :P Feb 08 16:48:10 the only slight worry is if you hold cmd continuously low and then toggle clk, since that is the trigger for boot mode which would cause the eMMC to drive data onto the data pins... however iirc this functionality is disabled in the default config Feb 08 16:50:28 so even if I config uBoot to use SD or wipe the eMMC I'll still push data to the GPIO pins Feb 08 16:50:45 or did I misunderstand that Feb 08 16:52:07 kbr_: the summary of what I said is: even if eMMC isn't explicitly disabled, if you sacrifice 1 gpio pin (the eMMC clk or cmd pin) then you can safely use the rest Feb 08 16:53:59 if you want that last pin too, you can either send eMMC a single command telling it to disable itself until next power-on (you could bit-bang that sequence), or enable the reset pin and use that to hold eMMC in reset Feb 08 16:56:03 (but note that enabling the reset pin is an irreversible procedure. this however is only a concern when trying to create highly security-hardened systems booting from eMMC, in particular for bootloader security) Feb 08 16:56:44 I'll stay away from the reset pin, better safe than sorry Feb 08 16:57:01 then hold either cmd or clk high and you're also safe Feb 08 17:00:18 I'm new to configuring dtb's, is that a setting I can configure there? Or just use a jumper cable Feb 08 17:00:35 refraining from using them suffices, they have pull-up resistors Feb 08 17:02:17 I don't know what you mean by suffices Feb 08 17:02:33 is sufficient Feb 08 17:03:05 oh sorry, you meant in regards to clk and cmd Feb 08 17:03:12 my apologies Feb 08 17:03:15 yes Feb 08 17:03:46 as long as clk never toggles, eMMC will never see a command and never send a response Feb 08 17:05:36 alternatively, if cmd is held high (this is the default) then even if clk toggles eMMC will never see any command and never send a response Feb 08 17:06:06 or I can send a message using both to turn it off, then leverage all the pins Feb 08 17:06:14 but that all makes sense, thank you Feb 08 17:06:15 exactly Feb 08 17:11:03 thanks for the help zmatt and rcn-ee, learned lots Feb 08 17:11:12 I'm browsing the standard a bit Feb 08 17:15:11 it looks like even if you'd send it random bits, the probability of getting any reaction out of eMMC is negligible Feb 08 17:19:38 can you link me to the document you were reading? I'd like to take a look at it Feb 08 17:22:31 you can download the eMMC standards from JEDEC (free registration required). The applicable version depends on which eMMC flash you have: the micron is v4.41 (JESD84-A441) while the kingston is v4.51 (JESD84-B451) Feb 08 17:23:23 beware that they're extremely poorly written standards, with almost no organizational structure, vague wording, bits and pieces of legacy stuff, etc Feb 08 17:24:32 I had trouble merely double-checking something, even though I'm actually familiar with the standard and have intensely browsed these standards not long ago Feb 08 17:27:38 (I wanted to verify that invalid commands result in no response, seems like it shouldn't be hard to find such a basic thing right? :P ) Feb 08 18:15:46 yeah, i don't understand why folks don't like systemd. i think it's a good thing. Feb 08 18:16:08 pfft Feb 08 18:16:17 because folks always mis up systemd (the project) with systemd (pid 1) Feb 08 18:16:17 everythingd Feb 08 18:16:42 systmd as pid 1 isnt more evil than any other init system ... Feb 08 18:16:58 its no big deal .. soon you'll have the kernel and systemd and you won't *need* anything else .. :) Feb 08 18:17:08 the umbrella systemd swallowing the world perhaps is ... thats personal preference :) Feb 08 18:18:10 and kdbus went into rewrite mode, so it'll be a few more years before systemd eats everything... Feb 08 18:18:35 ye could patch it to use binder meanwhile ;) Feb 08 18:18:48 hehe Feb 08 18:20:58 dbus is conceptually nice... whoever came up with the serialization however should be shot Feb 08 18:23:12 rcn-ee: i don't quite grok your patch system fully ... Feb 08 18:23:16 rcn-ee: https://github.com/RobertCNelson/armv7-lpae-multiplatform/blob/v4.5.x/patch.sh Feb 08 18:23:39 rcn-ee: are those is_44 patches mainlined patches that help backporting to 4.4.x ? Feb 08 18:24:01 vagrantc, correct, those are ones i'm auto-backporting to 4.4. Feb 08 18:24:40 but yeah, something in the v4.5-rc merge fixed sata on the x15.. Feb 08 18:25:12 well, that's good news Feb 08 18:25:36 minus video of course.. that worked in v4.4.x.. ;) Feb 08 18:26:11 oh Feb 08 18:26:17 progress is non-linear Feb 08 18:26:48 i think it's kms atomic related.. the bbb has a similar issue, and a work-around patch.. Feb 08 18:27:14 if it were linear there wouldn't be multiple branches being maintained Feb 08 18:27:17 :P Feb 08 18:27:51 and if ti didn't decide to re-invent things... "uio_pruss" was already mainline for the davanci family. ;) Feb 08 18:28:08 * vagrantc needs to nudge the debian kernel team to push 4.4 into sid Feb 08 18:28:28 to make room for 4.5 in experimental Feb 08 18:28:28 i think ben was doing the last 4.3.x upload this last weekend.. Feb 08 18:28:33 couldn't uio_pdrv_genirq do the job of uio_pruss pretty much equally well? Feb 08 18:28:53 and for that matter, i need to enable bbx15 in u-boot Feb 08 18:29:04 although some of those ti-u-boot patches are a little nervous-making Feb 08 18:30:03 vagrantc, and then this showed up: http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=69ecb027dcdd6245ade69efa2186d848d4dea451 Feb 08 18:30:44 and: http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commit;h=0989cb1e1128a4d8043aac6e4ef0ca97e43b47b8 Feb 08 18:31:31 rcn-ee: hopefully that can go mainline that without the mess the wandboard series ended up it... Feb 08 18:32:33 i think i took that week off, but i should have spoke up when they didn't name the new one "rev-c1" instead used the old name.. and move the odl to "rev-b1" dtb naming.. Feb 08 18:33:30 * vagrantc nods Feb 08 18:33:35 vagrantc, btw, they are using the eeprom value to detect the correct board.. my beaglebone green u-boot commit is going to mess that diff up for your re-base... (the ti-branch unified the eeprom read before my u-boot change).. Feb 08 18:34:28 they at least have the model name differentiated Feb 08 18:34:48 and this is nice commit: http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=commit;h=8ba6f26d663e88b8e2ab5c955fe8166c5b8852ad Feb 08 18:35:06 gota get that model for reproducible-builds.org ;) Feb 08 18:35:37 really need to get the bbx15 patches in mainline u-boot ... otherwise i'll go crazy trying to forward-port patches from ti-u-boot all the time Feb 08 18:35:46 I'm actually fairly convinced you could have 8 GB even though the TRM says you can't... Feb 08 18:36:03 rcn-ee: yeah, that'd be nice! Feb 08 18:37:39 though the requisite memory chips are uncommon (and are incompatible with the pcb) Feb 08 18:38:00 then probally spendy too.. Feb 08 18:39:15 it would need eight single-rank 1Gx8 chips Feb 08 18:41:16 basically the x8 packaged version of the chips mentioned in that commit Feb 08 18:42:18 same amount of RAM per chip, but with 8-bit data path hence you can place twice as many Feb 08 18:45:32 * vagrantc needs to get the fan going on the bbx15 Feb 08 18:45:44 unless EMIF genuinely treats bit 31 special in some way in Vayu, but I've done a quick test on the DM814x by lying about my memory geometry (and using DMM to be able to access the full 4GB address space of EMIF) and there it seems to work fine Feb 08 18:46:06 especially if working esata support is in sight for mainline Feb 08 18:50:44 (the am335x could support 2 GB in similar fashion) Feb 08 18:54:47 8 GB on the dm814x, if you don't mind having to change LISA mappings to select which 2 GB subset is accessible at any given time :P could be used as frontswap I guess Feb 08 18:57:54 whatever floats your boat :) Feb 08 19:00:44 zmatt, time to kickstart a dra7 with 8gb of ram? i only need 5 ;) Feb 08 19:01:02 I kinda wanna know whether I'm right though... maybe I'll post on E2E, the fact that they may be able to advertise twice as much RAM support as they do currently might grab their attention Feb 08 19:02:29 (even if I'm wrong, I'd hopefully learn why) Feb 08 19:10:33 heh. asking a question on the internet is sometimes less effective than stating a (known) wrong and getting corrected. Feb 08 19:13:07 yeah in this case there's a bit of tension between "how would TI manage to screw up something like this" vs "as far as I've been able to test it should work" Feb 08 19:14:15 though I can already guess a possible answer to that first question... probably when the docs were written these memory devices weren't available yet and 8 GB required dual-rank, which they defeatured as usual hence resulting in the conclusion of only 4 GB supported Feb 08 19:18:36 but the docs seem confused anyhow, they seem to imply the top bit determines rank, but normally the rank bit (when enabled) is actually somewhere in the middle of the address just after the bank bits Feb 08 19:18:55 the am571x TRM in contrast makes no such implication Feb 08 19:20:17 I have an idea Feb 08 19:20:24 pizza. \o/ Feb 08 19:26:00 pizza is good idea. Feb 08 21:01:21 Hello. I have a problem with the CALL and RET in PRU. After calling does not return. What should I do? Feb 08 21:06:25 double-check the register used as return address isn't accidently modified by the subroutine? (R3.w2 in EABI, configurable in pasm but defaults to R30.w0) Feb 08 21:08:48 i working on r30, .setcallreg r3.w2? Feb 08 21:09:48 huh that's an odd default indeed considering the special functionality of R30, weird Feb 08 21:10:47 but yeah you can change it to anything you wish Feb 08 21:11:32 thanks for the help Feb 08 22:24:45 hi, i'm trying to flash beaglebone black emmc from microsd, and first i got the cylon led pattern, but then instead of all leds staying on, all leds flash simultaneously Feb 08 22:25:04 which revision bbb ? Feb 08 22:25:04 with long delay short delay pattern, like 'double flashes' Feb 08 22:25:13 rev c Feb 08 22:25:26 hmm, odd Feb 08 22:25:57 (the most common cause of failure is people trying to flash a 4gb image onto an older bbb which only had 2gb eMMC) Feb 08 22:26:11 i can't find that flash pattern described anywhere Feb 08 22:26:20 * zmatt pokes rcn-ee Feb 08 22:26:36 it's this BBB-eMMC-flasher-debian-8.3-lxqt-4gb-armhf-2016-02-07-4gb.img.xz from here https://rcn-ee.com/rootfs/bb.org/testing/ Feb 08 22:26:50 should be fine yes Feb 08 22:26:53 then I have no idea Feb 08 22:27:11 shrug i'll try booting it Feb 08 22:27:36 I also suggest hanging around here, it may take time for someone who has an idea to respond Feb 08 22:28:02 no prob Feb 08 22:28:05 (in particular, rcn-ee might know, but he's probably busy right now) Feb 08 22:29:30 is that robert nelson? Feb 08 22:29:34 yup Feb 08 22:29:43 ah, cool to know he's in here Feb 08 22:31:19 sklv, double flash means something went wrong.. are you using a 5volt dc power supply? Feb 08 22:31:29 no using a usb cable Feb 08 22:31:38 sklv, you probally ran out of juice... Feb 08 22:31:53 if it occurs within 60-90 seconds, that's the issue.. Feb 08 22:32:04 happened after like 10 minutes Feb 08 22:32:30 okay, that's even odder... usually it's early as we max cpu/eMMC/microsd pretty quickly... Feb 08 22:32:46 does it still boot when you remove the microSD card? Feb 08 22:32:51 long cable, front usb port, trying to flash again now, if it happens again i'll go make sure i have a proper power supply Feb 08 22:33:01 rcn-ee: are some supplies that really feeble? dipping far enough for the 3v3 to destabilize? (but not enough for the pmic to intervene?) Feb 08 22:33:35 when i try boot it after removing microsd it flashes D1-D3 sporadically like during normal boot, then d2 starts doing the same double flash pattern Feb 08 22:33:57 i guess that means boot fail right? i guess I'll go solder up a serial adapter for it so i can see the boot log Feb 08 22:34:18 double flash pattern? you mean like a heartbeat? Feb 08 22:34:23 i think d2 is hearbeat.. Feb 08 22:34:27 have you tried to login.. Feb 08 22:34:42 can't because i don't get any video out Feb 08 22:34:44 (wish we put real names on the silkscren) Feb 08 22:35:02 do you have a serial cable? otherwise "ssh debian@beaglebone.local" over ethernet should work.. Feb 08 22:35:22 sklv, does the "video out" work when flashing, it'll just be a kmsconsole log of what's going on... Feb 08 22:35:27 rcn-ee: would be misleading if they got repurposed (first thing I do to any BBB image is turn off that incredibly annoying heartbeat) Feb 08 22:36:29 no video out during flashing Feb 08 22:37:14 humm, then it's not detecting your monitor... under /boot/uEnv.txt there's video override.. "uncomment this if video fails" give that a shot.. (you'll have to login over serial/ethernet/usb gadget) Feb 08 22:37:43 rcn-ee: that image, does it have the new tilcdc ? Feb 08 22:37:49 yeap.. Feb 08 22:38:00 as of last thursday.. Feb 08 22:38:27 i have an hdmi to vga adapter Feb 08 22:38:29 I hope they didn't manage to reintroduce the timing calculation bug that was fixed in 4.1-ti (but not in any other branch), haven't checked that yet Feb 08 22:38:32 so maybe https://rcn-ee.com/rootfs/bb.org/testing/2016-01-24/ woudl work.. Feb 08 22:38:43 sklv, passive or it has a power adapter? Feb 08 22:38:48 passive Feb 08 22:38:55 yeah, that's not going to work.. Feb 08 22:39:00 :( Feb 08 22:39:05 i've seen it work once Feb 08 22:39:11 that relies on the hdmi source to detect and send vga over hdmi... Feb 08 22:39:26 rcn-ee: are you sure about that? Feb 08 22:39:34 unless it's getting power from "hdmi"... Feb 08 22:39:48 hdmi does have 5v, but I'm not sure how much you're allowed to draw from it Feb 08 22:39:49 http://www.ebay.co.uk/itm/351217653599 Feb 08 22:39:54 it doesn't have analog signals like dvi does Feb 08 22:40:21 sklv, sorry, yeah that one won't work.. Feb 08 22:40:28 mind recommending one? Feb 08 22:40:36 do i need to search active? Feb 08 22:41:16 according to the second image it can be powered also Feb 08 22:41:53 the one i have has no usb plug Feb 08 22:41:56 ok Feb 08 22:42:26 what about this http://www.ebay.co.uk/itm/172090407033 Feb 08 22:42:41 i know the ones you need, cost more then $5... they need to sample the hdmi "fb" then re-sample and transmit it as a vga signal.. Feb 08 22:43:38 oh wow I hadn't even looked at the price yet... I wonder what on earth is inside that thing then Feb 08 22:43:54 i dont mind the price, just so long as i find one that works Feb 08 22:44:17 some pc video cards detect it, and i know apples does too, then internal it switchs from hdmi to vga, just over a vga cable.. Feb 08 22:44:45 rcn-ee: that's... gross Feb 08 22:47:07 http://www.ebay.co.uk/itm/262229121335 Feb 08 22:47:09 ? Feb 08 22:49:12 or http://www.amazon.co.uk/dp/B00NBUTHJG/ maybe? Feb 08 22:49:37 rcn-ee: apparently at least some "passive" hdmi-to-vga cables use the 5V supplied via the hdmi cable Feb 08 22:50:17 sklv, that amazon looks good, they say rasberry pi.. Feb 08 22:52:48 ayt i'll give that a go Feb 08 22:53:05 sklv, note : http://www.amazon.co.uk/gp/customer-reviews/R5Z70BN361T54/ref=cm_cr_pr_rvw_ttl?ie=UTF8&ASIN=B00NBUTHJG Feb 08 22:59:33 what about http://www.amazon.co.uk/dp/B00LIHRFPW/ seems to have better reviews Feb 08 22:59:41 lots of reports of success for raspberry pi Feb 08 23:07:40 i think because it has an external usb cable for power, it probally get's connected more often... Feb 08 23:19:20 I think the bbb can probably deliver decent amount of power via hdmi 5v, as long as it has a decent 5v power supply available itself Feb 08 23:20:17 I still think "passive" hdmi-to-vga cables are just single chip converters (e.g. the CH7101-1) powered by hdmi 5v Feb 08 23:24:52 the trip current of the PTC protecting the hdmi 5v is rated 200 mA at room temperature Feb 08 23:38:07 I have a randomly jumping/clicking cursor when i start x on the 8.3 BBB image using a LCD-Cape, anyone knows what that is? Feb 08 23:40:46 it might be haunted? Feb 08 23:41:50 i thought so too Feb 08 23:42:05 but it looks like evdev is dreaming up events Feb 08 23:43:20 what input devices are listed under /dev/input/by-id/ ? Feb 08 23:43:38 when i 'cat' /dev/input/event3 i only get events when i touch the screen, but after xstarts the cursor is jumping in the lower right portion of the screen till i touch the screen then it stops and moves with the finger Feb 08 23:43:52 weird Feb 08 23:44:17 I've knwon similar to that Feb 08 23:44:26 but no slution yet Feb 08 23:44:54 you can use xinput to examine all input devices known to X as well as the events they are generating I think Feb 08 23:45:01 if i tell X to ignore all inputs it stops ... but the touchscreen stops functioning too Feb 08 23:45:16 by-id only lists my keyboard on the USB port Feb 08 23:45:29 yeah I just noticed by-id doesn't list all devices Feb 08 23:45:40 xinput is more useful Feb 08 23:46:35 i forgot in what package that is? and does it list the device of origin? Feb 08 23:46:56 because xev was not helpfull at all ;) Feb 08 23:47:42 xinput has a variety of functions to query/configure/test input devices Feb 08 23:51:37 hm, there is a "virtual core xtest pointer" is that normal? Feb 08 23:51:42 yes Feb 08 23:52:01 it's for generating synthetic events Feb 08 23:52:29 you can use xinput test $dev to monitor the events of a specific device Feb 08 23:52:38 (name or id) Feb 08 23:54:29 i see Feb 08 23:54:53 i get constant "release" events without "presses" Feb 08 23:55:51 that's.... odd Feb 08 23:59:28 whats odd is that event3 does not list any of this events Feb 08 23:59:52 is there a way to filter events? Feb 09 00:02:58 btw, you mentioned cat'ing an event device? doesn't that get you a vomit of binary garbage? Feb 09 00:03:39 yes, but i dont mind ;) Feb 09 00:04:05 its just to see if there is data at all Feb 09 00:04:07 ok but you could also be missing events if they consist of control chars Feb 09 00:04:12 use evtest instead Feb 09 00:05:11 since it still seems more plausible that X is just passing through garbage events than that it is inventing them spontaneously Feb 09 00:06:31 same with evtest Feb 09 00:06:58 but x is reporting very low pressure values Feb 09 00:07:19 the stuff in evtest has ~double the pressure Feb 09 00:08:14 maybe evdev is configuring something there Feb 09 00:11:53 they might just have different scales or X might apply some calibration values Feb 09 00:12:21 but if the events are already in evtest then that means buggy driver Feb 09 00:12:47 evtest only lists the events i want to have Feb 09 00:13:34 its just after i startx Feb 09 00:14:27 huh Feb 09 00:14:28 ok Feb 09 00:14:53 but evtest does list the events (while x is running) ? Feb 09 00:15:34 or not even then? Feb 09 00:17:18 if the xorg-input-evdev driver is pulling events out of its ass that would be a rather bizarre and serious bug Feb 09 00:17:41 yes, after i startx it returns a lot of the "ghost" events Feb 09 00:18:01 ok, so X reconfigures the device and then the driver starts emitting garbage events Feb 09 00:18:09 which kernel driver is involved here? Feb 09 00:18:51 good question Feb 09 00:19:50 i know the dts where it is configed but i dont know what module takes care of it afterwards, X said something about "ti-tsc" Feb 09 00:20:03 ah, right, why am I not surprised Feb 09 00:20:58 which kernel version are you using? (uname -r) Feb 09 00:21:03 that i dont know or that TI is involved? ;) Feb 09 00:21:25 ti's tscadc driver is not known for its brilliance Feb 09 00:21:47 (tsc = touchscreen controller) Feb 09 00:22:53 4.1.17-ti-rt-r46 Feb 09 00:24:55 try the non-rt version ( apt-get install linux-image-4.1.17-ti-r46 ), RT kernels do have some tendency to make poorly written drivers misbehave Feb 09 00:25:34 dunno why rcn-ee switched to installing rt by default Feb 09 00:26:35 if he returns, we should ask him... Feb 09 00:26:39 I would not use one unless really necessary (and then you also need to carefully tune process priorities) Feb 09 00:27:08 i thought i used the non RT release ... Feb 09 00:27:21 Killili: the newest images all install an RT kernel by default Feb 09 00:27:26 like I said, I have no idea why Feb 09 00:28:14 personal style? Feb 09 00:28:21 an RT kernel is only useful for if applications explicitly make use of real-time scheduling, and otherwise it just leads to a less efficient (and often buggier) system Feb 09 00:28:38 i know Feb 09 00:29:21 I noticed for example that ping flooding a bbb "merely" caused the gui to hiccup on a non-rt kernel while it froze hard on the rt version of the same kernel Feb 09 00:29:46 but after reading a book about the BBB where they said linux is not a preemptiv sheduling OS and you need the RT kernel for that ... maybe there is a great deal of missunderstanding out there Feb 09 00:30:17 though on the RT kernel I could resolve that by demoting the ethernet irq handlers to SCHED_OTHER, which is a really bizarre thing to do but it actually worked :) that's a definitely benefit of RT kernels Feb 09 00:31:00 same with the non-RT kernel Feb 09 00:31:51 you can't change the process scheduling of something that isn't a process... RT kernels turn (nearly) all irq handlers into kernel therads Feb 09 00:31:58 *threads Feb 09 00:32:42 and linux without RT not being a "preemptive scheduling OS" ? in what piece of garbage was that written ? Feb 09 00:32:55 i mean same bug with the non-RT kernel ;) Feb 09 00:33:09 ah ok, it was worth a try Feb 09 00:33:31 "http://exploringbeaglebone.com" but the book Feb 09 00:33:34 not the site Feb 09 00:33:58 there's a lot of crap in print I guess Feb 09 00:35:32 but the linux kernel has a compile-time "latency vs efficiency" slider with 3 settings, the RT patches add another step (leap?) to the low-latency end of that slider Feb 09 00:37:03 the am355x has 2 "coprocessors" for realtime stuff so why would i need that? Feb 09 00:37:52 efficiency will however suffer since every irq handler becomes a kernel thread and every "spinlock" (which on a uniprocessor non-RT kernel just means "disable interrupts") becomes a priority-inheritance mutex Feb 09 00:38:19 recipe for disaster in the wrong hands Feb 09 00:38:44 *shrug* no idea... because your RT code doesn't fit into 2x 8KB of instruction RAM ? Feb 09 00:39:30 i programmed 8051 ... 8K is practicaly enough for everything(TM) *gg* Feb 09 00:39:36 hehe Feb 09 00:40:22 also, if you can live on using one core you could combine it with edma to swap in the next page of code into the one core while the other is running Feb 09 00:41:15 8051 was a very good processor once you got to know its power. Feb 09 00:41:16 first i need a running LCD, or this whole project will never start Feb 09 00:41:48 why "was"? its still nice for its purpose Feb 09 00:42:11 but yeah, I had a "wtf, how did my (baremetal cortex-a8) application grow to 6 KB?!" moment a while ago, but I realized I added rather verbose abort decoding and all those messages add up Feb 09 00:44:02 byte per character ;P Feb 09 00:44:26 Killili: I actually dumped the adc kernel driver in favor of direct userspace access, but that's a bit inconvenient if you want to use it as a touchscreen controller (though you could use the uinput kernel driver for that) Feb 09 00:45:40 and have a userspace driver sending emulated events back to x? Feb 09 00:45:41 veremit: plus the dispatching logic, and unfortunately gcc's output is still not all that great Feb 09 00:46:41 Killili: you could also directly send them to X (they'd end up on that virtual core xtest pointer) Feb 09 00:46:47 errors only need 6bit per char, and its more intimidating in ALL CAPS, too ;) Feb 09 00:46:51 heh have to split debugging out to subsystems eh?! :P Feb 09 00:48:36 cant i tell X to use the stuff evtest is using and ditch ti-tsc? Feb 09 00:48:37 veremit: nah this is just the fault decoding for the cortex-a8, I still need to add interconnect error decoding logic (let alone fault reporting from the few subsystems that have it, such as EMIF) Feb 09 00:48:50 zmatt: damnit man, get to it :P lol Feb 09 00:49:59 veremit: I started working on an interconnect error logging daemon under linux (the same logic would of course work on baremetal) but have been too busy with other things Feb 09 00:50:07 (like the stuff I get paid to do) Feb 09 00:50:16 d'oh bloody paid work .. :p Feb 09 00:50:17 heh Feb 09 00:50:41 Killili: you mean there's actually a specific x11 driver for it, rather than using the generic evdev driver? Feb 09 00:50:55 that sounds unlikely Feb 09 00:54:44 hm, so why does it call it ti-tsc then? Feb 09 00:55:00 and not "touchscreen" as i named it Feb 09 00:55:09 neither is a driver name Feb 09 00:55:19 xorg.log should list the driver name somewhere Feb 09 00:56:53 veremit: I did semi-recently run an automated scan of the whole L3 interconnect. it didn't really result in any new info (other than some areas that lead to lockup on attempt to access) but it's good to have anyway Feb 09 00:57:08 it says loading "evdev" Feb 09 00:57:19 Killili: there ya go Feb 09 00:58:18 the adc_tsc is one permutation of the driver .. but I'd guess its funnelling through evdev .. since that's the standard method Feb 09 00:58:19 so we're back at, driver is buggy and responding poorly to whatever reconfiguration is done by X11 (most likely calibration? I thought that was done in userspace but I don't know the input subsystem that well) Feb 09 00:58:49 driver goes bezerk and thats spewing garbage Feb 09 00:58:56 *starts Feb 09 00:59:18 im not sure on the "garbage" Feb 09 00:59:22 there might be other explanations, but this is one hypothesis Feb 09 00:59:34 Killili: a release event without corresponding press event is garbage Feb 09 01:01:36 i ran evtest in another terminal an there are press events, too. So i guess permanently clicking a window and reading it is harder then i thought ;) Feb 09 01:02:30 but as i said they have a lower pressure value, and when i press the screen the "garbage" stops and the "real" events have higher pressure values Feb 09 01:02:45 ok, so there may be a threshold issue Feb 09 01:03:01 thats my current theorie at least Feb 09 01:03:22 but only the wacom and synaptics evdev stuff has a threshold option Feb 09 01:03:50 there's nothing of interesting shown using "xinput list-props" ? Feb 09 01:03:59 or maybe somewhere in sysfs Feb 09 01:04:39 http://pastebin.com/q6v1FZJT Feb 09 01:06:46 it must be a setting somewhere, since X11 is changing it :P Feb 09 01:07:04 linux is nothing if not well documented .... Feb 09 01:08:50 lol Feb 09 01:08:53 "as far as I'm concerned, writing documentation is a total and utter waste of my time and resources. It just gets ignored." -- Russell King Feb 09 01:09:29 tell that the iso9600 guys ;) Feb 09 01:10:13 there are 3 kernel modules with names like ti*adc|tsc Feb 09 01:10:30 but nothing in /sys/ to interact with them Feb 09 01:11:31 yeah, there's the tscadc multipurpose driver on which the adc (IIO subsystem) and tsc (input subsystem) drivers depend Feb 09 01:12:00 also, iso... -.- Feb 09 01:13:13 i guess every programmer hates them Feb 09 01:13:38 some iso standards really hurt the standardization process I think... people will either fall asleep trying to read them or just fail to comprehend them, assuming they're willing to pay for them in the first place (or find a copy floating around on the web) Feb 09 01:14:05 "The input buffer shall be greater than, or equal to, zero bytes in length." Feb 09 01:14:14 like, WHY IS THAT SENTENCE IN THERE Feb 09 01:14:43 cause they are paid by word? Feb 09 01:15:09 so stateing the obvoise is money in the pocket ;) Feb 09 01:15:25 the X.509 style guide ( https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt ) also has a nice quote, search for "ISO 8824" Feb 09 01:16:35 uh nice Feb 09 01:16:50 so thats where all those philosopie students end up Feb 09 01:19:37 (if you scroll down slightly, the description of TBSCertificate is also a wonderful mess and a fitting quote to complement it) Feb 09 01:24:00 someone realy had fun writing this Feb 09 01:24:30 after having previously banged a sizeable hole in the wall Feb 09 01:26:13 never wander off to where math guys go to have fun Feb 09 01:26:44 all you will find is horrible code and not understandable writing Feb 09 01:27:13 i gave up on encryption a long time ago Feb 09 01:29:08 on a side note my framebuffer has some lines of pixels ~4 at the top that have the wrong color, hardware fault or setting? Feb 09 01:29:30 its using a TI driver too iguess ;) Feb 09 01:39:54 tilcdc \o/ Feb 09 01:40:10 and the math is not the problem Feb 09 01:40:23 no its the people! Feb 09 01:40:58 it's what happened when Standards™ came along Feb 09 01:42:26 the only problem with the math is that it's being ignored. the algorithms and protocols still being used are embarrasing compared to the state-of-art ... or state-of-the-90s for that matter Feb 09 01:43:46 lol, useful -> https://github.com/JoelBesada/activate-power-mode Feb 09 02:01:00 ok thx zmatt, i need some sleep. cya Feb 09 02:01:05 nite **** ENDING LOGGING AT Tue Feb 09 02:59:59 2016