**** BEGIN LOGGING AT Wed Mar 09 02:59:58 2016 Mar 09 05:41:22 hi, I am doing image processing on linux using open cv. I am following the link of derek molloy: “http://derekmolloy.ie/beaglebone/beaglebone-video-capture-and-image-processing-on-embedded-linux-using-opencv/” when I execute the capture program. Not even a single frame is captured and I got “select timeout” error .i am googling it but did't find any solution for this. Mar 09 06:06:43 hi, I am doing image processing on linux using open cv. I am following the link of derek molloy: “http://derekmolloy.ie/beaglebone/beaglebone-video-capture-and-image-processing-on-embedded-linux-using-opencv/” when I execute the capture program. Not even a single frame is captured and I got “select timeout” error .i am googling it but did't find any solution for this. Mar 09 06:18:27 hi veremit and zmatt Mar 09 06:20:15 the 1.1v problem was solved when we used a switch Mar 09 06:20:26 it was probably a ramp up issue Mar 09 06:20:38 thanks for ur suggestions Mar 09 06:20:46 it really helped Mar 09 06:20:59 now i hav another issue in another board Mar 09 06:21:20 all the voltages are generated and the board fails to boot Mar 09 06:21:45 the same code boots all the other boards but this board fails to boot Mar 09 06:21:54 any idea?? Mar 09 08:21:33 Someone? Mar 09 10:18:49 e Mar 09 10:19:01 hell0 Mar 09 10:19:19 i am newbie to beagle black board Mar 09 10:19:54 in 'install drivers' section Mar 09 10:20:14 i am using ubuntu 14.04 LTS Mar 09 10:20:37 "Driver installation isn't required, but you might find a few udev rules helpful" Mar 09 10:20:43 linux doesn't need drivers Mar 09 10:20:55 yeah Mar 09 10:20:58 but Mar 09 10:21:23 i don't understand why linux doesn't drivers Mar 09 10:21:52 i think that it use virtual ethernet via usb Mar 09 10:21:59 isn't that? Mar 09 10:24:26 the drivers are included in linux already Mar 09 10:24:34 that's why you don't need to install them Mar 09 10:25:10 please show me what driver is included? Mar 09 10:39:08 http://www.linux-drivers.org/ Mar 09 12:05:02 hi Mar 09 12:05:06 I've got problem with beaglebone rev. b: http://pastebin.com/4RHZnQQd Mar 09 12:05:08 after that the board goes off Mar 09 12:30:30 Posterdati: I've seen that before Mar 09 12:30:52 beaglebone white or black? Mar 09 12:32:56 the resolution was switching to a non-rt kernel. rt kernels have a tendency to escalate subtle flaws in drivers into full-blown crashes, and the tps65217 driver apparently contains such a flaw Mar 09 12:33:35 I've only heard of it being triggered on a BeagleBone White, although I have no idea where that difference comes from Mar 09 12:43:51 Posterdati: if you have a Black available, boot the card on that if possible and apt-get install a non-rt kernel Mar 09 12:47:54 alternatively, you may be able to get it to boot on a White by clearing the irq that's being asserted by the pmic at boot time, e.g. by dumping the pmic registers in u-boot prior to booting the kernel. the u-boot command for that is: i2c md 24 00 20 Mar 09 12:48:51 ok thanks Mar 09 12:49:12 (assuming that trick works; you could do this once manually to get the system to boot once and be able to install a non-rt kernel, or you might integrate it into the u-boot boot script) Mar 09 12:50:26 zmatt: it is a beablebone white from circuitco rev. b Mar 09 12:50:37 ultimately the best fix would be to figure out what the tps65217 driver is doing wrong... I mean, that irq handler is only used to detect when the power button is being pressed. it's kinda impressive they managed to fuck that up :P Mar 09 12:51:27 a White that has AM335x rev 2.1 ... how unusual Mar 09 12:52:41 i2c md 24 00 20 Mar 09 12:52:41 0000: f2 3d 01 01 b1 80 b2 01 00 00 04 00 7f 0c 1e 08 .=.............. Mar 09 12:52:41 0010: 08 06 09 38 3f 3f 7f 00 03 15 5f 23 40 80 00 00 ...8??...._#@... Mar 09 12:53:28 yeah you only need to dump one register (containing the irq status bits) but I was too lazy to look up which one so I just dumped all the regs Mar 09 12:53:43 if you do the command a second time you'll see one byte will have changed into 00 Mar 09 12:53:59 ok Mar 09 12:55:11 no byte was changing Mar 09 12:55:22 odd Mar 09 12:55:39 * zmatt grabs the register reference Mar 09 12:55:47 shall I press any button? Mar 09 12:56:18 you can try. pressing the power button briefly should set a status bit Mar 09 12:56:23 that clears when you read it Mar 09 12:56:28 there's no a power button Mar 09 12:56:32 ah Mar 09 12:56:43 only a reset button Mar 09 12:58:05 the tps65217 has only three irq sources: power button pressed, DC power connected/disconnected, USB power connected/disconnected Mar 09 12:58:31 one of those three will normally be set at boot since that's what caused the system to power up Mar 09 13:01:12 ok Mar 09 13:04:21 the interrupt register is byte 2 btw.... bits 0-2 are interrupt status, bits 4-6 interrupt mask Mar 09 13:04:35 your dump shows bit 0 set, "USB power status change interrupt" Mar 09 13:05:11 which is false because I'm powering with usb! Mar 09 13:05:22 no that's correct then Mar 09 13:05:29 status changed = you connected usb power Mar 09 13:06:13 ? Mar 09 13:07:50 you connected power to usb, this initially caused the pmic to power up in reset state. it then noticed usb power was connected, set the interrupt bit, and proceeded to enable power to the rest of the system Mar 09 13:11:40 that bit should be cleared if you dump the registers (or specifically the interrupt register) a second time though Mar 09 13:12:14 hopefully if no interrupt is pending at boot, the tps driver won't crash Mar 09 13:13:00 (I still have no clue why this only happens on a White running an rt kernel... the tps behaviour is exactly the same on the Black) Mar 09 13:13:57 maybe some hardware difference causes a subtle difference in timing of events during boot Mar 09 13:17:29 I also still have no clue why rcn-ee has changed to installing an rt kernel by default :/ Mar 09 13:17:56 i2c md 24 00 20 Mar 09 13:17:57 0000: f2 3d 01 01 b1 80 b2 01 00 00 04 00 7f 0c 1e 08 .=.............. Mar 09 13:17:57 0010: 08 06 09 38 3f 3f 7f 00 03 15 5f 23 40 80 00 00 ...8??...._#@... Mar 09 13:18:10 now byte 2 is changed Mar 09 13:19:04 now reset (don't power cycle!) and see if it boots Mar 09 13:19:46 with the button? Mar 09 13:20:28 or any other way, but the reset button is easiest Mar 09 13:20:44 not working Mar 09 13:21:01 weird Mar 09 13:21:45 *LIGHT BULB* ... don't tell me they forgot about the NMI polarity issue... Mar 09 13:22:05 hold on a second Mar 09 13:22:09 ok Mar 09 13:23:11 btw, to dump only the int register you can do i2c md 24 02 01 Mar 09 13:23:15 saves a bit of output Mar 09 13:24:02 but I need to look up the address of a register to confirm whether the polarity of the signal is right, hold on Mar 09 13:24:55 i2c md 24 02 01 Mar 09 13:24:55 0002: 01 . Mar 09 13:25:05 huh, still 01 ? Mar 09 13:25:13 yes Mar 09 13:25:15 even if you dump it a second time without rebooting? Mar 09 13:25:24 wait Mar 09 13:25:51 now 00 Mar 09 13:25:54 I resetted Mar 09 13:26:22 since the board goes off I have to disconnect the usb and reconnect Mar 09 13:26:47 the board going off is also weird Mar 09 13:27:19 yes it goes off at the end of the dmesg I posted Mar 09 13:27:38 can you confirm that if you now press reset and break into u-boot again the bit is still 0 ? Mar 09 13:27:57 I did now, shall I reset? Mar 09 13:28:01 I did with reset command Mar 09 13:28:26 it is 0 Mar 09 13:29:08 ok, so the irq is *not* being asserted... so that crash makes me fear they really forgot about the polarity... lemme continue looking up the register to check that Mar 09 13:30:51 ok, we need to check bit 7 of the register at 0x48200080 Mar 09 13:31:42 48200080: 00000082 ffffffff 00000000 00000000 ................ Mar 09 13:31:55 sigh, idiots.... Mar 09 13:32:40 they did not catch the correct polarity for the irq? Mar 09 13:32:58 it's a known chip erratum of revision 1.0 of the processor that the polarity of the IRQ input pin was inverted, that's the pin they used for the pmic irq Mar 09 13:33:14 that bug was fixed in revision 2.x of the processor, which is what you have now Mar 09 13:33:22 grrr Mar 09 13:33:44 is it useless? Mar 09 13:34:18 that irq is... but you probably don't need it anyway Mar 09 13:34:31 like I said it's only used for detecting when the power button is pressed... and you don't even have one Mar 09 13:34:58 ok shall I throw away this board? Mar 09 13:35:00 a non-rt kernel probably works since it'll switch to "irqpoll" Mar 09 13:35:17 no, all that's needed is disabling the irq entirely Mar 09 13:35:32 which is probably a small DT change Mar 09 13:35:42 I placed irqpoll in cmdline Mar 09 13:36:09 [ 0.000000] irqpoll boot option not supported w/ CONFIG_PREEMPT_RT_BASE Mar 09 13:36:18 that's why it crashes on rt kernels Mar 09 13:36:59 note however that using a non-rt kernel with irqpoll is not really a good fix, it'll continuously waste cpu time on that irq Mar 09 13:37:15 the fix is disabling the irq Mar 09 13:37:23 ok how? Mar 09 13:37:34 (and yelling at circuitco to fix their boards) Mar 09 13:38:54 :( Mar 09 13:39:49 &tps { /delete-property/ interrupts; }; Mar 09 13:40:14 is it suffice to disable from uboot? Mar 09 13:40:29 or will be reenabled by the kernel? Mar 09 13:40:45 it'll be enabled by the kernel... Mar 09 13:41:08 is there a way to tell the kernel to not reenable it via cmdline? Mar 09 13:41:18 I was just wondering about that Mar 09 13:42:11 irqfixup — Basic fix to interrupt problems. Mar 09 13:42:11 Mar 09 13:42:11 When an interrupt is not handled, search all known interrupt handlers for it. This is intended to get systems with badly broken firmware running. Mar 09 13:42:24 no Mar 09 13:42:54 the problem is that the irq is being asserted continuously, ceaselessly Mar 09 13:43:04 since in fact, it's not, but the polarity is wrong Mar 09 13:43:20 OHH, maybe, just maybe... Mar 09 13:43:25 hold on Mar 09 13:43:57 I have a dirty idea Mar 09 13:44:12 throw away the board? Mar 09 13:44:57 is the polarity changeable? Mar 09 13:46:27 the pcb was designed to allow the polarity to be easily changed during production... you just remove one 0-ohm resistor (R28) and install it at R10 instead (currently marked 'do not install') Mar 09 13:48:09 but that'll probably be a flyspeck-sized resistor so not many people will be comfortable doing such a patch Mar 09 13:48:16 but I still have an idea for a software workaround Mar 09 13:48:24 better Mar 09 13:48:40 what is the cpu companion? Mar 09 13:49:08 tps65217? Mar 09 13:49:22 where do you see that term? Mar 09 13:51:34 btw, if my dirty hack doesn't work, the software solution is still to fix the device tree file... it would be a good idea to report this issue on the mailing list also, since you won't be the only person who has it. it should be fixed upstream by disabling the interrupt on these buggy White boards Mar 09 13:53:01 ti microcontrolers all work with a cpu companion chip Mar 09 13:53:15 no they don't Mar 09 13:53:18 which is in charge of power management and clock Mar 09 13:53:24 I know the term from the OMAPs Mar 09 13:53:57 but there the chip really does all sorts of auxiliary tasks Mar 09 13:54:07 the tps65217 is really just a pmic Mar 09 13:54:32 the am335x has on-chip oscillator and rtc Mar 09 13:55:21 you can also swap out the pmic for a different one if you want Mar 09 13:55:31 there are several which are compatible with the am335x Mar 09 13:56:19 oh yeah I was still looking up the dirty hack Mar 09 13:57:37 my idea is: disable the RXEN bit of the pinmux register of that pin. most likely the pinmux register is never touched, and I know from experience that disabling RXEN causes the cpu to perceive the pin as being low regardless of... oh crap that won't work either, we want it to perceive the pin as high, not low Mar 09 13:59:17 ok, next strategy: post it on the mailing list. the problem has been identified, it simply needs to be fixed upstream. it should be an easy fix for kernel devs Mar 09 14:02:11 if you want the board working asap, find a way to either install a non-rt kernel and use the irqpoll option, or patch the device tree to disable the tps irq (or if you don't know how to do that, ask on the list if someone can provide a patched DT) Mar 09 14:03:03 ok, thanks Mar 09 14:03:19 patching the DT is the best quick solution Mar 09 14:04:09 it just requires appending one line to am335x-bone.dts ... the line I pasted earlier Mar 09 14:04:17 and then rebuild the dtb and install it Mar 09 14:04:36 &tps { /delete-property/ interrupts; }; Mar 09 14:05:22 at least, I hope that works. it's possible of course the driver will seriously object to not being able to find its irq, in that case the driver will need to be fixed. probably an easy fix for a kernel developer though Mar 09 14:07:05 and you're also perfectly justified to yell angrily at CircuitCo for not having fixed the polarity on the pcb, especially since the pcb was already designed in advance to allow the polarity to be inverted (since it was known the NMI polarity was considered a bug hence would be fixed in a future chip revision) Mar 09 14:08:29 ok, I gotto go now, good luck with your board Mar 09 14:10:00 http://minix-i2c.blogspot.it/2013_07_01_archive.html Mar 09 14:10:03 thanks Mar 09 14:12:03 Posterdati: note that if you do want the board to detect the power button (which could be located on a cape, the power button pin is available via P9), the only solutions would be fixing the polarity by moving the resistor (no fun), or have the driver periodically poll the register instead of using an interrupt Mar 09 14:15:23 those are basically the two options to *fully* fix the problem, without loss of functionality. but if you don't care about that stupid button, disabling the irq is the way to go Mar 09 14:16:24 oh and I just checked the driver: it looks like it's okay with not having an irq Mar 09 14:16:33 ok, really going now Mar 09 14:16:37 thanks Mar 09 14:16:39 bye Mar 09 14:18:44 Hello, how do I protect the Inputs of an Beaglebone? which Diodes or Shottky do I use or a preferred to use? Mar 09 14:55:53 Bastiaan: protect from what? Mar 09 15:07:32 i am facing issues in booting the beaglebone black Mar 09 15:09:20 monty_: you might want to explain the issues you're facing Mar 09 15:16:04 instead of flashing the eMMC it detects the beagle board Mar 09 15:16:33 the flashing doesn't happen as per the text mentioned in the manual Mar 09 15:29:28 l Mar 09 15:31:18 monty_, there are 2 possible problems 1) the ssd doesnt contain a valid image 2) u dont switch on sd on start via hardware by pressing the right button Mar 09 16:00:35 av500: aliens. what do you recommend? ;) Mar 09 16:17:14 zmatt, zombies ... Mar 09 16:22:32 Are there any recommended 7' or larger LCD touch screens that are compatible with early revision BeagleBone Blacks? Any that can do 1080p? Mar 09 18:02:26 i try to insert the ping configuration with a DT file ... the confiruation need to be loaded at boot time... so i inserted the file in rc.local Mar 09 18:02:49 rc.local file seems not to be executed Mar 09 18:03:14 echo bspm_P8_27_15 > /sys/devices/bone_capemgr.?/slots Mar 09 18:03:14 echo 86 > /sys/class/gpio/export Mar 09 18:03:19 thats what i added Mar 09 18:03:28 to rc.local Mar 09 18:04:14 i found that rc.local seems to try to execute the file BEFORE the cape manager execution Mar 09 18:04:26 etc/rc.local: 29: /etc/rc.local: cannot create /sys/devices/bone_capemgr.?/slots: Directory nonexistent Mar 09 18:04:26 + echo bspm_P8_27_15 Mar 09 18:04:26 + echo 86 Mar 09 18:04:26 + exit 0 Mar 09 18:04:47 is there any other option to load the DT i need? Mar 09 18:04:54 i mena on boot time Mar 09 18:06:07 or the slow down the execution of rc.local AFTER the creation of the cape manager ? Mar 09 18:47:59 I think there's some way you can get capemgr to load specific capes at boot (i.e. a config file or cmdline parameter)... I don't know the specifics since I don't use capemgr myself Mar 09 19:40:36 ok il chce the cfg file for capemanager Mar 09 19:40:40 cehck Mar 09 19:45:34 in general you can also use dependency constraints to ensure services are started only when prerequisite services and/or devices are available Mar 09 19:46:17 i.e. you could add a custom service for your initialization, or add constraints to the rc.local service Mar 09 19:48:00 I'm a bit surprised capemgr shows up so late, but maybe it first needs to complete its probing of the i2c bus for cape eeproms before it appears as a device Mar 09 19:49:01 if that's the case, then assuming you're using a 4.1 kernel or later you could also work around the problem by using the new configfs mechanism to load your overlay instead of using capemgr Mar 09 20:17:11 zmatt, thank for all advice, problem solved i dont know why directory wasnt visible from rc.local execution BUT was actually there, so i just added a sudo for the execution of that command ... im using a xenomai 3.8 btw Mar 09 20:17:42 i need some real time features Mar 09 20:17:52 with machinekit Mar 09 20:19:46 oh ok, I've briefly looked at xenomai but currently don't really have real-time needs (and if I did I'd be more inclined to use PRU) Mar 09 20:20:31 zmatt, using the PRU also ... to develop PWM signals Mar 09 20:21:03 i need to retrieve some i2c informations and pass it to PRU to provide PWM Mar 09 20:21:19 i2c is kinda slow to be used with PRU Mar 09 20:21:27 dere is not really need i think Mar 09 20:21:46 and of course there are -rt kernels also... I know that's still not quite the same as xenomai, but I wouldn't want to be stuck with an ancient kernel Mar 09 20:22:23 xenomai never arrived at 4.1 Mar 09 20:22:42 and 3.14 xenomai doesnt have the cape manager Mar 09 20:23:00 so i preferred the use of the 3,.8 Mar 09 20:23:15 I don't see why you would not use pru for i2c... if your needs are still real-time it would still make sense to me Mar 09 20:23:51 an rt linux kernel would probably do fine too, but I'd have less faith in it Mar 09 20:24:16 because that spare me a lot of programming for PRU ... programming i2c from a c source to make work a IMU sensor its just easyer Mar 09 20:24:40 so xenomai works better for me Mar 09 20:24:42 there's a C compiler for PRU and the i2c controller isn't that hard to use Mar 09 20:25:27 its not just the i2c controller ... its all the informations from i2c that need to be filtered and evaluated Mar 09 20:25:44 may be too much complex probably Mar 09 20:26:02 need to implement a kalman filter Mar 09 20:26:21 after receiving IMU data Mar 09 20:26:37 the project is for a quadcopter Mar 09 20:27:13 ive seen the TI CCS Mar 09 20:27:15 hmm, fair enough, PRU is not the ideal place for such numerical processing... Mar 09 20:27:25 didnt try to make it work anyway Mar 09 20:27:36 CCS sucks Mar 09 20:27:43 what u suggest to use= Mar 09 20:27:44 ? Mar 09 20:27:51 vim and a makefile? :P Mar 09 20:28:05 compiler pasm? Mar 09 20:28:41 hehe, to be honest I'm not sure... I haven't yet played with PRU yet, even though it's been high on my priority list. Mar 09 20:28:58 pasm looks quite interesting, it has powerful features for an assembler Mar 09 20:29:17 it definitely looks more appealing to me than using TI's C compiler Mar 09 20:29:19 i gave a look to the manual... doesnt seem so hard to make it work Mar 09 20:29:31 ill give a look to both Mar 09 20:29:35 the thing that sucks is that afaik TI never publicly released pasm2 Mar 09 20:29:55 hum no you are right Mar 09 20:30:01 although I haven't searched hard yet. I did find a windows version of it Mar 09 20:30:23 and the source code of a partially extended pasm1 is available Mar 09 20:30:33 ill start with pasm then Mar 09 20:30:39 lets see where it goes Mar 09 20:31:31 I have scraped together the full instruction set though. I still want to do some actual testing against the PRU core and then see about writing a *proper* cpu instruction reference Mar 09 20:32:08 it's insane that there are a dozen sources, all with different bits of information Mar 09 20:32:22 i will probably read that :) Mar 09 20:33:16 and TI's new assembler is extremely fussy and rejects many examples of assembly instructions from the TRMs (and, bizarrely, even from its own documentation) Mar 09 20:33:31 basically the new assembler is useless except as backend used by the C compiler Mar 09 20:34:29 ! Mar 09 20:34:45 sounds fair for me Mar 09 20:34:56 from where to start Mar 09 20:35:39 you can find a windows version of pasm2 in this git repo btw -> https://git.ti.com/keystone-rtos/pruss-lld/ Mar 09 20:35:48 test/src/pru_firmware/pasm_dos.exe Mar 09 20:36:07 ok thanks ill download it Mar 09 20:36:29 (it's not actually a DOS executable btw, contrary to its name. even though it's commandline it only runs under windows) Mar 09 20:36:58 need to virtual machine a windows ... long time i dont use one Mar 09 20:37:27 yeah I tried dosemu first... but "This program cannot be run in DOS mode." Mar 09 20:38:09 64 bit? Mar 09 20:39:04 pasm_dos.exe: PE32 executable (console) Intel 80386, for MS Windows Mar 09 20:39:23 ok Mar 09 20:40:50 it looks like the pasm in https://github.com/beagleboard/am335x_pru_package might be pretty complete also though Mar 09 20:41:25 root@beaglebone:/lib/firmware# apt-cache search am335 Mar 09 20:41:25 am335x-pru-package - AM335x PRU PACKAGE Mar 09 20:41:35 its in the repository Mar 09 20:45:50 I thought it still had missing functionality, but it looks like it has been added Mar 09 20:46:06 so, never mind, there's a full-featured pasm available after all Mar 09 20:46:43 do you know PRU SPEAK also? Mar 09 20:47:06 no, what is it? Mar 09 20:48:57 also, random factoid: the PRU core's original (afaik) name was "Packed Data Structure Processor" .. you can actually sometimes still find a reference to the abbreviation "PDSP" in pru documentation, that's where it comes from :) Mar 09 20:49:32 they used to talk directly with PRU Mar 09 20:49:44 http://beagleboard.org/pru Mar 09 20:49:50 there is a video dedicated Mar 09 20:50:05 a sort of real time environment Mar 09 20:50:23 i think it works with python Mar 09 20:50:25 what do you mean "talk directly with PRU" ? Mar 09 20:50:54 Blink LED (to Cloud9 IDE terminal window running netcat connected to PRU Speak server) Mar 09 20:50:54 SCRIPT Mar 09 20:50:54 SET DIO[4], 1 Mar 09 20:50:54 WAIT 100 Mar 09 20:50:54 SET DIO[4], 0 Mar 09 20:50:55 WAIT 100 Mar 09 20:50:57 GOTO 0 Mar 09 20:50:59 ENDSCRIPT Mar 09 20:51:01 RUN Mar 09 20:51:03 Mar 09 20:51:21 chekc the last example from the site Mar 09 20:52:24 generating code for PRU is easy enough, it's a very simple and regular instruction set Mar 09 20:52:26 not useful for my project but it looks interesting Mar 09 20:52:34 its RISC Mar 09 20:52:42 reduced instruction set Mar 09 20:53:15 sure, but more so than plenty of other CPUs that claim to be RISC ;) Mar 09 20:54:24 looking at their block diagram now, I really don't understand why they'd still go through remoteproc and all Mar 09 20:54:40 just map the subsystem into userspace already Mar 09 21:00:23 zmatt, so increasing mreqprio and initiator priority did not help but changing PR_OLD_COUNT did the trick, here is the email which i got from my colleague: http://pastebin.com/eFsNAF0G and the current solution is just running "devmem2 0x4c000054 w 0x00FFFFF10" and it's actually mentioned on this wiki page http://processors.wiki.ti.com/index.php/DA8xx_LCDC_Linux_FB_FAQs -> "Issue disappears on configuring PR_OLD_COUNT field in the EMIF control Mar 09 21:00:23 register(OCP config) to value close to zero.", this might fix 32pixel issue as well, there is also some more info regarding REG_PR_OLD_COUNT here http://e2e.ti.com/support/arm/sitara_arm/f/791/p/300197/1052263#1052263 Mar 09 21:02:33 filt3r: setting PR_OLD_COUNT low effectively disabled all forms of prioriziation though... that still leaves the question why the cortex-a8 was being prioritized over lcdc Mar 09 21:02:38 *disables Mar 09 21:03:22 btw I think (but I'm not sure) mreqprio works inverted, i.e. 0=highest priority Mar 09 21:03:28 yes that is a concern with the current solution, so we are still not considering it fixed Mar 09 21:03:53 yes, but it still had no effect Mar 09 21:03:53 also check out EMIF's "read write execution threshold register" or something like that Mar 09 21:04:49 EMIF tends to prefer not switching between reads and writes since there's overhead involved Mar 09 21:05:24 aforementioned register puts a limit on that to prevent continuous writes to blocking reads indefinitely and vice versa, but I don't know if it's enabled by default Mar 09 21:07:09 ok that also might be worth a try Mar 09 21:07:39 if setting priorities using mreqprio (for cortex-a8) and the dma priority register in lcdc doesn't help (it's hard to verify whether they actually *work*) then another alternative would be configuring the "class of service" functionality of EMIF Mar 09 21:08:17 that can specifically prevent lcdc requests from sitting in the command queue for too long Mar 09 21:08:25 by matching on initiator id Mar 09 21:13:42 which of course are documented in the detailed TRM chapter on the Interconnects... oh no wait, just kidding, the interconnect "chapter" for the am335x is 4 pages and completely useless :P Mar 09 21:14:04 ok so with the class of service functionality you would only increase the priority of the specific class instead of all commands in the emif fifo, i'm getting this right? Mar 09 21:14:05 fortunately I do have some docs -> https://docs.google.com/spreadsheets/d/1dkd70ST-W2Dg3A0_8ynIyP2TczBgbARDH7qP4Te3EYU/edit Mar 09 21:14:23 and then you would add lcdc dma transfers to that prioritized class Mar 09 21:14:27 thats my current understanding Mar 09 21:15:03 yes, by matching on initiator id Mar 09 21:15:31 so 24 according to your spreadsheet? Mar 09 21:15:43 yeah, 0x24, or maybe 0x90 depending on how exactly they wired things Mar 09 21:18:18 but 0x24 is what makes the most sense, that's the 6-bit initiator ID as used by the L3 interconnect Mar 09 21:22:16 ok we'll try that, but there is also priority to class of service mapping, so does the priority thing even work when the priority to class of service mapping is disabled, it would be dumb if not because you have 7 priorities but only 3 classes Mar 09 21:23:17 but if you need to enable priority to class of service mapping for it to work than that might explain why changing the priority did not do anything Mar 09 21:24:26 no afaik priorities are just hard priorities, but the priority-to-cos mapping allows you to make sure some lower-priority traffic doesn't get starved indefinitely Mar 09 21:25:52 COS acts like a "tag" on requests. iirc some docs actually indicated that if you use both priority-based COS and initiator-based COS then a request can actually get tagged with both COS1 and COS2 simultaneously Mar 09 21:27:53 btw, if you have doubt whether the connid is right, you can enable a performance counter with connid-based matching Mar 09 21:28:48 (this also lets you track e.g. how long requests from lcdc tend to wait in emif's command queue) Mar 09 21:29:12 (connid = initiator id, sorry for mixing terminology) Mar 09 21:34:01 ahh ok, i found it in the TRM, ye this might come in handy Mar 09 21:34:32 unfortunately I don't really know how exactly all the prioritization works. this would require some empirical science and I haven't had the time yet Mar 09 21:34:37 but it mentions a "MConnID" so it's the initator id? Mar 09 21:34:40 yes Mar 09 21:34:44 ok Mar 09 21:36:22 there are various kinds of terminology going around due to the mixing of things like Open Core Protocol, Sonics interconnects (e.g. the L4 interconnects), Arteris FlexNOC (L3), VBUS (TI's own tech, used in many subsystems) Mar 09 21:36:59 btw, if you want to learn more about the AM335x interconnects, I can recommend the DM814x TRM Mar 09 21:37:33 it's another TI SoC actually quite closely related to the AM335x architecturally, and it has quite a detailed interconnect chapter Mar 09 21:42:58 ok thanks, that is definitely good information to help us find a proper/better fix Mar 09 21:43:15 unfortunately even there the L3 is presented as a black box Mar 09 21:43:28 even though obviously it isn't Mar 09 21:44:17 it may not matter though since it appears that prioriziation inside EMIF is the problem, not the L3 interconnect Mar 09 21:47:49 if I ever find the time I still want to try to see if it's possible to use scripted tests to figure out the actual topology of the L3 interconnect Mar 09 21:48:38 I know roughly what to expect since I stumbled across this diagram of a large chunk of the DM814x L3F -> http://gerbil.xs4all.nl/centaurus-partial-L3F.png Mar 09 21:53:54 ok have a very basic aka. almost none understanding of the interconnect stuff, but i assume for example the l3 interconnect will queue some commands for the emif and tag the commands with the connectid? so thats the reason the emif then can prioritize by connection id? Mar 09 21:55:04 the L3 is basically just a packed-switched network like ethernet. packets include a source address and a destination address Mar 09 21:57:17 so for requests that's the initiator id and target id Mar 09 21:58:49 ahh ok, so the emif sees the initiator id in and can prioritize accordingly Mar 09 21:59:16 the term connid actually comes from TI's VBUS interconnects where the situation is different... afaik there it's actually just metadata, used for things like prioritization and firewalling Mar 09 22:01:50 which is why EDMA can spoof connid on TI SoCs that use VBUSM as main interconnect (their DSPs) Mar 09 22:04:01 that's not possible with FlexNOC (used on am335x) since it needs that id to be able to route replies back to the requestor Mar 09 22:08:29 i just googled for flexnoc, i'm really fascinated by the fact that companies can make a living by designing chip interconnects Mar 09 22:08:44 is that surprising? Mar 09 22:10:20 hmm for me yes, for some reason i assumed that chip designers would design the interconnects on their own Mar 09 22:11:09 TI actually used a different third-party interconnect on the omap3 (SonicsMX), *and* they have their own interconnect tech Mar 09 22:11:40 so the fact they switched to FlexNOC suggests the benefits must be pretty substantial Mar 09 22:13:12 not for everything though, they do use VBUS on their DSPs, including the enormous Keystone processors, so there must be some trade-off involved Mar 09 22:14:46 they also have very different usage patterns probably... I'd expect the Keystones to be more throughput dependent while general-purpose code is often more latency-bound Mar 09 22:18:00 but ultimately I don't know... I'm not a chip designer :) Mar 09 22:18:32 ye me neither but it's almost as much of a dark magic as RF for me :D Mar 09 22:20:36 but apart from the Keystone processors all of their recent SoCs seem to follow the same set of interconnect choices: FlexNOC for the L3, Sonics S3220 for the L4 interconnects, and VBUS for local interconnects inside subsystems Mar 09 22:23:34 hi Mar 09 22:23:38 many subsystems are clearly derived from their DSP technology though, so that may at least explain that aspect Mar 09 22:25:38 EMIF and the ethernet subsystem come from there, the DMA of the USB subsystem is a scaled-down version of the Keystone queue manager, and I recently discovered Keystone processor are littered with PRU cores (aka PDSPs) all over the place Mar 09 22:25:57 the keystone 2 packet accelerator has 15 of 'em Mar 09 22:32:55 my guess would be that the third-party interconnects allow them to build a SoC more quickly from a heterogenous bunch of subsystems and peripherals then their own technology does Mar 09 22:33:37 the am335x certainly looks to me like it was done in a hurry :P Mar 09 22:33:47 ye, that makes sense Mar 09 22:33:48 or maybe an intern or something Mar 09 22:33:52 :D Mar 09 22:37:18 ok just for my understanding if you use the interconnect id for class of service mapping and you use no mask, you effectively can only map up to 2 id's to a class, is that right? Mar 09 22:37:53 correction up to 3 Mar 09 22:38:00 3 yes Mar 09 22:38:37 ok, makes sense Mar 09 22:39:33 this is my understanding of that register: http://pastebin.com/ACjDRfkA Mar 09 22:39:43 never tested it though Mar 09 22:42:26 yes although it looks like the numbering is reversed, the first mask (#1 from the trm) has the larger mask size Mar 09 22:43:42 lemme see. I do occasionally make mistakes there since the TRM annoyingly lists fields in big endian order :P Mar 09 22:44:29 no, my struct agrees with the TRM, just the labels don't Mar 09 22:46:00 the TRM numbered them 3, 2, 1 (in order of ascending bit position); I used 0, 1, 2 as any sane programmer would :P Mar 09 22:47:07 ye i meant the naming not the layout, but the layout confused me there for a second as well :) Mar 09 22:47:27 since the TRM starts at bit 31 and the struct starts at bit 0 obviously Mar 09 22:48:08 yes, that's one annoying habit of the TRM Mar 09 22:48:37 but i think most datasheets, etc. list msb first in the register tables Mar 09 22:50:09 (another one is nearly always presenting the register map of a peripheral as 32-bit registers, even if it clearly consists of separate 8- or 16-bit parts, or conversely presenting a 64-bit register as two 32-bit ones) Mar 09 22:50:41 yes it's commonly seen... doesn't make it less annoying :P Mar 09 22:51:09 :D Mar 09 22:51:38 documenting an array as pages and pages of separate registers also makes me want to slap the person responsible Mar 09 23:26:50 hello Mar 09 23:26:55 anyone there? Mar 09 23:27:03 occasionally :P Mar 09 23:27:09 I need help with bare-metal programming of BBB Mar 09 23:28:53 How to generate .bin files for BBB without using CCS? Mar 09 23:28:56 well, stick around, since I gotto catch a train but I'll be back later (and I actually have experience with baremetal programming on the BBB) Mar 09 23:29:04 okay Mar 09 23:29:11 thanks Mar 09 23:29:26 https://github.com/mvduin/bbb-asm-demo <-- although there's actually on reason to use asm, this may be of interest Mar 09 23:29:31 *no reason Mar 09 23:32:34 ok Mar 09 23:34:42 @zmatt could you please tell me how to use this bbb-asm-demo to convert .exe files to .bin files? Mar 10 00:00:27 ok zmatt i just tried it quickly but neither inititor id 0x24 0x09 0x90 worked here is how i tried it: devmem2 0x4c000054 w 0x001010FF and then devmem2 0x4c000104 w 0x84800000 for e.g. 0x09, but as soon as i set REG_PR_OLD_COUNT to 0x10 it works, maybe the initiator id is wrong, but i'm gonna sleep now, will be back in ~6hours Mar 10 00:21:55 anyone there? Mar 10 00:22:32 How to generate .bin files for BBB without using CCS? Mar 10 00:26:06 I guess the concept of "stick around, I'll be back later" was too complicated... Mar 10 00:32:52 zmatt: always Mar 10 00:36:17 though for some reason I'm kinda glad he left before I could ask him wtf an ".exe" or ".bin" file is in this context :P Mar 10 00:46:03 :D I like how this room mostly self-moderates :D Mar 10 00:48:41 zmatt: I still think we need a "let me google that for you" bot in here ... :) Mar 10 00:49:20 netsplit woo Mar 10 01:09:27 Hey! I was wondering, can I just grab a lubuntu desktop iso to install it to the beaglebone Mar 10 01:12:06 veremit: well we certainly have plenty of bots here... when I paste a link to an image the webserver gets instantly hit by 7 HEAD requests (5 of which follow up with a GET request) Mar 10 01:12:57 zmatt: nice Mar 10 02:37:50 did the RCN linux-dev repo got moved? bone70 isn't tagged there **** ENDING LOGGING AT Thu Mar 10 02:59:58 2016