**** BEGIN LOGGING AT Wed Jan 06 02:59:58 2016 Jan 06 03:13:15 uhuh Jan 06 03:24:20 only 8 minutes, eh? Jan 06 04:28:06 where is register that determines the location of interrupt vector table? i've looked in several manuals and don't see it. Jan 06 04:28:13 for the am335x, that is. Jan 06 04:31:11 zmatt: ? Jan 06 04:32:21 also where is the definition of the interrupt vector table? Jan 06 04:33:41 your vectors.S has init, exc_undef, exc_syscall, etc., located at "vectors" (every four words), but this doesn't match the interrupts defined in Table 6-1 of the am335x trm. Jan 06 04:42:09 hello all.. How to add QT to statrtup . I am using debian on bbb. It would be great is someone could help. Jan 06 04:43:21 abhi_: what do you mean by "add QT to startup"? Jan 06 04:43:32 what do you really want to do? Jan 06 04:44:26 hi yates. i have a qt gui application. I want that at startup . I have disabled the desktop. Jan 06 04:45:16 do you know about systemd? Jan 06 04:45:32 no i dont Jan 06 04:45:47 i tries adding to /etc/init.d Jan 06 04:46:03 but its not getting started Jan 06 04:46:04 it basically is what manages what things get started Jan 06 04:46:13 yeah, that's not a good approach Jan 06 04:46:19 oh is it Jan 06 04:46:29 hang on - i'll give you an example Jan 06 04:46:31 check the ARM TRM not the AM335 TRM Jan 06 04:46:40 ya Jan 06 04:46:42 interrupt table should be a Cortex thing Jan 06 04:46:54 cuz you have been shafted by systemd Jan 06 04:47:03 you need to do the systemd config file crap Jan 06 04:49:43 abhi_: you need to create a .service file for the application, like this: http://ur1.ca/odw90 -> http://paste.fedoraproject.org/307664/52055741 Jan 06 04:50:17 i will check Jan 06 04:50:20 thanks yates Jan 06 04:50:23 :) Jan 06 04:50:41 check the manpages for systemd to find out where to put it. Jan 06 04:51:23 ya sure i will check Jan 06 04:51:23 when you get it created and in the right place, then you enable it to run at startup by issuing the command "systemctl enable xyz.service" (where xyz is the name of your service file) Jan 06 04:51:45 ds2: ok, i'll check there - thanks Jan 06 04:55:08 well, it's not there either. a search for "dabort" fails Jan 06 04:55:12 exc_dabort Jan 06 04:55:45 yates: btw, I replied to some of your questions earlier, you can find it in the irclog Jan 06 04:56:14 I wonder if there's a less obnoxious interface to those than http://www.beagleboard.org/irclogs/ ... Jan 06 04:56:42 and on a cortex-a8 you can put the vector table at any 32-byte aligned address Jan 06 04:57:07 yeah, do you remember what day you responded? Jan 06 04:58:14 2016-01-05 around 12:12 (in whatever timezone the irclogs are in) Jan 06 04:58:44 ir-clogs :) Jan 06 04:59:39 ok, got it - reading. Jan 06 04:59:43 thanks for all that. Jan 06 05:00:16 zmatt: re: vector table: yeah sure, but WHAT REGISTER controls that? or did you answer in the log? Jan 06 05:00:45 i've looked through the INTC registers and don't see it Jan 06 05:00:52 i may be blind. Jan 06 05:00:54 no since you didn't ask that back then, since it's some cp15 register Jan 06 05:01:12 easy to find since I set it in my tiny tiny initialization routine in my bbb example Jan 06 05:01:37 you need a mrc/mcr instruction to screw with them Jan 06 05:01:57 ok, lemme check that. Jan 06 05:02:01 https://github.com/mvduin/bbb-asm-demo/blob/master/init.S#L28 Jan 06 05:02:40 by the way, i found the u-boot code that initializes ddr3. got it ported. testing it now. Jan 06 05:02:57 my one day is gone... Jan 06 05:03:09 the ddr3 init in u-boot should be obvious :D Jan 06 05:04:16 lol Jan 06 05:04:35 it is fairly obvious, ONCE YOU FIND THE RIGHT U-BOOT. Jan 06 05:04:44 hmm? Jan 06 05:04:56 it is fairly obvious, ONCE YOU FIND THE RIGHT U-BOOT. Jan 06 05:05:00 you mean you still have u-boot 1's lying around? Jan 06 05:05:27 i mean without some guidance, there are a bazillion versions of u-boot out there. Jan 06 05:05:44 I don't think it's particularly obvious in any u-boot... the init code is scattered across many sources and headers Jan 06 05:05:51 they are all very similar, esp. wrt to the foundation init stuff Jan 06 05:06:06 it was to me Jan 06 05:06:21 forgot if it was a quick grep or git log Jan 06 05:07:06 i did a bit of grepping, but it wasn't a big problem. it is a little tedious, though Jan 06 05:10:07 iirc the values programmed by u-boot contained some oddities though Jan 06 05:10:20 I'm not really convinced they are optimal Jan 06 05:11:16 (I forgot the details, though I'm sure I'll run into them again once I find time to finish my own emif init code) Jan 06 05:15:14 one thing that is a big question mark is this. i'm not sure if the first subroutine in the top-level routine config_ddr, ddr_pll_config is necessary, due to the statements in section 26.1.4.3 of the am335x trm that ddr dpll is locked to 400 Mhz (as well as other plls necessary) Jan 06 05:15:44 easy enough to check whether the ddr pll is indeed locked by ROM Jan 06 05:15:46 it's not a trivial routine, so i'm hoping it isn't required. Jan 06 05:16:01 hmm, it should be a trivial routine I think Jan 06 05:16:12 no, it isn't. Jan 06 05:16:41 iirc, it initializes everything, and there are deep dependencies into the other parts of the board initialization Jan 06 05:17:03 everything meaning the various processor clocks and what not. from basic parameters. Jan 06 05:17:22 how pointless when public ROM already sets up fairly sane defaults Jan 06 05:17:32 and linux will overwrite them yet again Jan 06 05:18:23 i have to do some more digging. and reading. and scratching my head. Jan 06 05:19:12 btw, why did you even bother with thumb2 mode? i mean, we've got, what, about 200 words of assembly? Jan 06 05:19:47 i.e., code density is not an issue here. right? Jan 06 05:19:57 why wouldn't I? I mean, with unified assembler syntax there's no difference in source code, and the result is more compact Jan 06 05:20:04 there's no reason *not* to use thumb2 Jan 06 05:20:20 you can actually assemble the whole thing in arm-mode too if you'd want to for some reason Jan 06 05:20:28 of course. Jan 06 05:21:17 all my baremetal code is thumb2, except for the single instruction at the entrypoint to switch to thumb mode (since pubrom executes the image in arm mode) Jan 06 05:22:00 I noticed I dump the ddr pll also in my clock-config dump, I'll compile it and run it for you Jan 06 05:23:54 zmatt: btw, my question yesterday on the bus error was when i disassembled. there was no writing being done. Jan 06 05:24:52 i think i may have had a combination of problems, though, mostly transient. seems like after i reset power, replugged the xds usb, etc., it works fine. Jan 06 05:24:57 ok Jan 06 05:27:32 ddr pll is not initialized Jan 06 05:28:37 http://pastebin.com/HJRK0usu Jan 06 05:31:43 bummer Jan 06 05:31:51 easy enough to initialize it though Jan 06 05:31:57 i am pretty sure they are not optimal Jan 06 05:32:54 few things seem to be easy on this monster of a processor.. Jan 06 05:33:15 it isn't that bad Jan 06 05:33:37 it is your fault for not using U-boot ;) Jan 06 05:33:42 neither are finite fields. Jan 06 05:33:54 finite fields are very elegant Jan 06 05:34:05 this cpu's prcm isn't remotely Jan 06 05:34:19 iirc, galois' five theorems were pretty intense. Jan 06 05:34:53 oh, well sure, if your IQ is 165, it's pretty easy... Jan 06 05:35:32 I do recall having trouble grasping inseparable extensions, though in retrospect i don't understand anymore why I had trouble with them Jan 06 05:35:42 but that's not an issue with finite fields anyway :) Jan 06 05:35:56 that's general field theory, right? Jan 06 05:36:31 yeah, both finite fields and fields of char 0 only have separable extensions Jan 06 05:36:59 don't make me break out my Herstein... Jan 06 05:38:28 the simplest example of an inseparable one is by taking the function field F_p(X) for some prime p, and then extend it by adjoint the p'th root of X Jan 06 05:38:36 *adjoin Jan 06 05:39:30 zmatt: it's been 12 years since i had this class... Jan 06 05:39:33 hehe Jan 06 05:39:39 been a while for me too Jan 06 05:40:54 anyhow, the icky part is that the characteristic polynomial has multiple roots... in fact all p of them are the same Jan 06 05:41:03 which is a really odd situation Jan 06 05:41:44 f(x) = x^p - X is irreducible in F_p(X) Jan 06 05:42:17 yet once you adjoin one root, say α, then it splits as (x - α)^p Jan 06 05:43:24 I think we drifted slightly off-topic though Jan 06 05:43:25 ;) Jan 06 05:43:47 yeah. Jan 06 05:44:20 if you have the jtag plugged in to the target board, but have disconnected the usb, will it keep the processor halted? Jan 06 05:44:24 configuring the PLL, I think you just need to write 3 registers Jan 06 05:44:55 if i cycle power on the board, will it just stop (i guess at 0x00020000, public rom, as you said)? Jan 06 05:45:13 depends on whether you enabled break at reset Jan 06 05:45:16 that's not bad Jan 06 05:45:31 and not sure whether it's retained if you unplug, I think it is Jan 06 05:45:51 it probably does perform a TAP reset if you have a pulldown on nTRST Jan 06 05:46:06 since the xds100v2 will go high-Z on all pins Jan 06 05:46:46 this might or might not deassert DBGEN, I'm really not sure Jan 06 05:47:22 generally best to resume the cpu before disconnecting, or power cycle the board Jan 06 05:47:23 what initial user-code address does the public rom code jump to after loading it into ram? Jan 06 05:47:57 in case of MLO (sd/mmc, spi flash, etc) you can specify the address, although it needs to be in internal SRAM Jan 06 05:48:22 in case of peripheral boot (usb, uart, ethernet) it's always 0x4002f400 Jan 06 05:49:05 ok. Jan 06 05:49:41 to change it I think you need to modify it in two places in my demo: the linker script and the makefile (which passes it as argument to the script that builds the mlo header) Jan 06 05:49:54 no, it's fine. Jan 06 05:50:31 sorry I meant 0x402f0400 btw Jan 06 05:50:52 there's some benefit to using 0x40300000 instead (ocmc ram) Jan 06 05:50:55 ok, about these interrupt vectors, e.g., .fun vectors with init, exc_undef, etc., where is this documented Jan 06 05:50:56 ? Jan 06 05:51:08 what? Jan 06 05:51:19 since it's accessible from DAP, while the a8-local RAM is only accessible from the a8 Jan 06 05:51:29 DAP? Jan 06 05:51:31 so you cannot examine the a8-local RAM without halting the CPU Jan 06 05:51:46 the Debug Access Port Jan 06 05:52:01 it has direct access to the L3 interconnect, and to the debug interconnect (L4EMU) Jan 06 05:52:22 i'll keep that in mind. Jan 06 05:52:27 via the debug interconnect it can halt the cpu, examine its state, and make it execute instruction e.g. to access its local RAM and peripherals Jan 06 05:52:57 I'm not sure if CCS is smart enough to automatically route transactions via DAP when possible Jan 06 05:53:17 via its L3 access port I mean Jan 06 05:53:32 i am really interested in the interrupts. as i stated earlier, all i see is the emuint, commtx, commrx, etc. in table 6-1 of the am335x trm. Jan 06 05:53:47 that's all outside the cortex-a8 Jan 06 05:53:53 and routed to its IRQ pin Jan 06 05:54:09 the interrupt controller is not from ARM but from TI Jan 06 05:54:28 the exception vector table however *is* an ARM-specific thing Jan 06 05:54:42 hence you find its details in ARM documentation Jan 06 05:55:10 either the TRM or the architecture reference manual.. I think the former summarizes it and the latter describes it in more detail Jan 06 05:55:33 oh, so the interrupt table captioned "ARM Cortex-A8 Interrupts" are not the ARM Cortex-A8 Interrupts? Jan 06 05:55:39 they are Jan 06 05:55:40 sheesh, how stupid of me.. Jan 06 05:55:49 but "interrupt" is only one of the exceptions Jan 06 05:55:54 the exc_irq Jan 06 05:56:18 you just stated they are "outside the cortex-a8". which is it? Jan 06 05:56:18 a memory fault or undefined instruction isn't an irq Jan 06 05:57:08 by irq you mean from a hardware pin? Jan 06 05:57:21 the interrupt controller is just a separate block meant to filter and prioritize the 128 irqs going to the cortex-a8 subsystem into a single irq signal to the cortex-a8 cpu itself Jan 06 05:58:25 i think i see. Jan 06 05:58:38 this triggers exc_irq Jan 06 05:58:49 so the actual cortex a8 interrupts are in which arm document? the trm? the arm? Jan 06 05:58:58 which then queries the interrupt controller to ask which of the 128 sources has been triggered Jan 06 05:58:58 or "exceptions"? Jan 06 05:59:48 i see references to EXC_DABORT in the PMU of the arm. Jan 06 05:59:56 e.g., Jan 06 06:00:13 there are only 8: { reset, undef, syscall, iabort, dabort, , irq, fiq } Jan 06 06:00:33 each is expected to be a 4-byte instruction Jan 06 06:00:39 where is that defined? i've looked, sorry if am asking you to hold my hand... Jan 06 06:00:46 arm architecture ref Jan 06 06:00:53 ok Jan 06 06:01:06 in this case we don't control the actual reset vector Jan 06 06:01:24 but I use it as entrypoint of my program Jan 06 06:02:01 it calls init with 'bl' to put the exception table address + 4 into LR, with bit 0 indicating thumb-mode Jan 06 06:02:01 i'm looking at the "ARM Architecture Reference Manual: ARMv7-A and ARMv7-R edition" - do i have the wrong document? Jan 06 06:02:07 nope, it's in there Jan 06 06:02:19 a search fo undef fails Jan 06 06:02:30 wait, no. Jan 06 06:02:37 I may have given some of them saner names Jan 06 06:02:43 i.e. iabort is called "prefetch abort" Jan 06 06:02:56 undef is still undef though Jan 06 06:03:00 or "undefined" Jan 06 06:03:14 triggered by undefined instructions or bogus processor state Jan 06 06:05:14 btw, the ".handler" and "hret" macros I defined take care of annoying boilerplate and make exceptions behave more sanely, similar to the cortex-M (and I think AArch64 went the same direction as well) Jan 06 06:05:59 except you still need to push/pop some regs that would be automatically pushed on the cortex-M Jan 06 06:06:08 yeah, i finally noticed those. Jan 06 06:06:28 pretty tricky to call the one "ret" though! i thought that was an instruction Jan 06 06:06:53 well, it is an instruction, I just gave it a shorter name Jan 06 06:07:07 also, i noticed that's only for a one-level call stack. Jan 06 06:07:14 no Jan 06 06:07:21 unified stack, not one-level Jan 06 06:07:26 it nests just fine Jan 06 06:07:30 where are you using a stack? Jan 06 06:07:41 you just stuff the return addressing into lr, right? Jan 06 06:07:52 ..address Jan 06 06:08:33 srsfd pushes the lr and spsr of the current cpu mode onto the stack of another cpu mode Jan 06 06:09:16 oh, that comment on line 12 is wrong, should be "{ lr, spsr } of cur mode" or something Jan 06 06:09:59 are you talking about in asm-defs.h? Jan 06 06:10:03 srs and rfe were introduced exactly to allow using a single stack for all exceptions Jan 06 06:10:07 no, vectors.S Jan 06 06:10:22 in the .handler macro definition Jan 06 06:10:50 i'm talking about .fun's and ret's. Jan 06 06:11:03 .fun is just assembler boilerplate Jan 06 06:12:03 to make the right kind of symbol, and help give them correct sizes Jan 06 06:12:50 .fun and .var should officially be terminated by .done to set their size, but this is only needed at end of file since each already performs an implicit .done Jan 06 06:14:19 yates: ARM exceptions are burdened by lots of historical baggage Jan 06 06:14:45 they're quite possibly the ugliest part of the architecture Jan 06 06:17:25 hmm, I notice I made changes to this code in my main codebase... maybe I should port those over Jan 06 06:25:03 hi yates Jan 06 06:25:09 so, this is what my current start.S looks like, which is the only assembly source file in my C/C++ code: http://gerbil.xs4all.nl/start.S.html Jan 06 06:25:23 thaks its done . adding qt application to startup Jan 06 06:28:20 abhi_: you are welcome. good deal! Jan 06 06:28:36 but i have one more problem Jan 06 06:29:07 the thing is that when i boot up it echos some stuffs Jan 06 06:30:00 means the system Jan 06 06:30:10 then my qt applications runs Jan 06 06:30:14 yates: I notice some subtle differences, i.e. in my handler entry I now use "cpsid ia" instead of "cps", this prevents different handlers from interrupting each other as much as possible, saves some headache Jan 06 06:34:19 abhi_: so what? Jan 06 06:35:09 zmatt: i was just interested in interrupts from the macro level. all i'm really handling is the switch... Jan 06 06:35:45 modify your qt app so it doesn't echo anything, if that's a problem. Jan 06 06:36:34 yates: so the flow of an interrupt is: irq line asserted to subsystem, if enabled in interrupt controller this triggers the prioritization process and in parallel asserts the nIRQ input of the cortex-a8 Jan 06 06:36:55 if interrupts are enabled then the a8 will take the irq exception Jan 06 06:38:34 yates: the linux echo's on startup. how to disable that? Jan 06 06:38:35 my macro (.handler in bbb-asm-demo, henter in my current code) will cleanly stack that on top of the "handler" stack and switch to "handler" mode (as asm-defs explains this is "system mode" currently but could be "supervisor mode" instead) Jan 06 06:38:48 but with irqs disabled at this point Jan 06 06:40:06 then the interrupt controller is consulted to figure out what irq was asserted... this is done directly in exc_irq in bbb-asm-demo, but I'd normally do that in C/C++ Jan 06 06:41:29 nested irqs are possible if desired, it would require raising the base priority in the interrupt controller and then reenabling interrupts, and on exit disable irqs, restore base priority, eoi, hret Jan 06 06:42:17 (this would get you nested irqs similar to those on the cortex-M, but with more boilerplate) Jan 06 06:45:34 in my current codebase I actually went the other way: I don't enable irqs at all, instead I enter 'idle' after initialization, which does a wfi (which still performs its job with irqs disabled) and directly calls the irq dispatcher Jan 06 06:45:53 saves overhead of stacking/unstacking the irq exception Jan 06 06:47:04 basically acts like a main event loop Jan 06 06:49:28 Hi all . How to disable linux echo on startup. I have qt application and at boot i have added it to systemd. It runs as the system powers up. But before that bbb echos some stuffs. How to disable it Jan 06 06:50:01 i want to remove all the text Jan 06 07:06:41 zmatt: so by your pastebin, it's just the pll_ddr that has to be set up and enabled? Jan 06 07:10:45 yep, and I just verified it's easy indeed: to be sure it's disabled write 4 to CM_CLKMODE_DPLL_DDR and poll CM_IDLEST_DPLL_DDR until bit 8 is set Jan 06 07:12:07 write (24-1) | 400 << 8 to CM_CLKSEL_DPLL_DDR Jan 06 07:12:12 don't you have to also setup prescalers etc? Jan 06 07:12:15 (assuming 24 MHz osc) Jan 06 07:12:55 write 1 to CM_DIV_M2_DPLL_DDR Jan 06 07:13:16 write 7 to CM_CLKMODE_DPLL_DDR and poll CM_IDLEST_DPLL_DDR until bit 0 is set Jan 06 07:13:25 your pll is now locked Jan 06 07:14:23 (dco at 800 MHz, out-m2 at 400 MHz) Jan 06 07:15:00 huh? are you saying the actual output to the ddr memory is 800 MHz? Jan 06 07:15:12 what is "dco"? Jan 06 07:15:29 dco is the PLL oscillator freq, out-m2 is the postdivider output Jan 06 07:15:29 i thought the emif could only generate a max of 400 MHz. Jan 06 07:15:40 both are implicitly multiplied by two Jan 06 07:15:55 you need the even postdivider to get a clean symmetrical clock Jan 06 07:16:09 hence the PLL is locked at 800 MHz and then divided by two Jan 06 07:16:38 so the actual output to the ddr chip is 400 MHz Jan 06 07:17:23 wait, I think it actually needs 800 MHz output, lemme check the docs Jan 06 07:17:28 is there a diagram you're looking at? Jan 06 07:17:45 Figure 8-14. DDR PLL Structure Jan 06 07:19:07 according to the data sheet, the max DDR clock is 400 MHz. which means our ddr memory is only running at 800 MHz, not 1600 Mhz. Jan 06 07:19:11 right? Jan 06 07:21:21 it's a little vague, I'm not sure whether the ddr phy macros need to be clocked at the DDR clock speed or twice that speed Jan 06 07:21:43 ok, DDR clock Jan 06 07:21:49 then the setup I gave above it right Jan 06 07:21:51 *is Jan 06 07:22:01 EMIF runs at 200 MHz Jan 06 07:22:12 the ddr phy macros at 400 MHz Jan 06 07:22:31 (there's an implicit /2 divider for the EMIF clock() Jan 06 07:25:35 so N=23, M=400, M2=1 Jan 06 07:26:01 (again assuming 24 MHz osc) Jan 06 07:28:08 are you referring to the "N" in Figure 8-8? Jan 06 07:29:19 yeah Jan 06 07:29:35 CM_CLKSEL_DPLL_DDR contains N and M Jan 06 07:29:39 CM_DIV_M2_DPLL_DDR contains M2 Jan 06 07:30:00 anyway, I gotto do other stuff Jan 06 07:30:07 ok. Jan 06 09:22:16 my BBB O/S 3.8.13-bone30 ubuntu started crashing every few days, so I created a Debian image 4.1.12-ti-r29, but it seems very slow by comparison. Jan 06 09:23:56 Any suggestions which O/S image I should install so the board is stable and fast like ubuntu Jan 06 09:34:44 install latest official images, and see how that fares? Jan 06 11:17:11 hi all. I am using beabglebone black with debian Image 2015-03-01. How to disable the text at startup. It shows Debian GNU/Linux 7 beaglebone tty1 ... Jan 06 11:17:35 default user:password is [debian:temppwd] Jan 06 11:17:53 How to disable this text from showing on the lcd Jan 06 11:20:36 abhi_: you can edit the motd and other things, as for every linux system Jan 06 11:24:11 abhi_: it's in /etc/motd and /etc/issue Jan 06 11:24:40 and issue.net while you're at it Jan 06 11:24:52 That too. Jan 06 12:41:35 Hi, has anyone updated u-boot lately? Jan 06 12:44:25 Looks like the MLO and u-boot.img is layed out in the first sectors of the SDcard, is that correct? On BBB that is. Jan 06 13:19:46 eliasbakken: ? Jan 06 13:56:36 zmatt: why not N = 23, M = 800, and M2 = 2? Jan 06 14:24:58 any one there Jan 06 14:25:30 http://www.catb.org/esr/faqs/smart-questions.html Jan 06 14:25:43 Nope. Jan 06 14:27:07 Hi Spidler Jan 06 14:27:25 I would like to contribute to beaglebone black kernel Jan 06 14:27:26 Hello, vamshig Jan 06 14:27:44 what is the procedure that I can submit my changes Jan 06 14:28:53 there is no "BBB kernel" as such Jan 06 14:29:10 what are you specifically interested in? Jan 06 14:31:43 cureently I am working on am335x soc Jan 06 14:31:57 we have a custome board based on this soc Jan 06 14:32:36 I download the kernel from git clone git://github.com/beagleboard/kernel.git Jan 06 14:33:38 working on 3.8 branch Jan 06 14:34:11 Is there any means that I can submit my changes which will be useful for others Jan 06 14:36:12 I'd suggest contacting Robert Nelson, https://github.com/RobertCNelson/ Jan 06 14:37:37 as far as kernel improvements, I'd consider 3.8 a *very* dead end Jan 06 14:38:59 the rcn specific kernel sources for recent builds are here it seems https://github.com/beagleboard/linux Jan 06 14:39:16 notice the previously mentioned repository has been dead for a year Jan 06 14:40:57 and as Spidler pointed out, you should contact RCN if you want to help improve the BBB specific bits in the linux kernel (and make them fit for upstream) Jan 06 14:41:18 I'm detaching now, have a good evening all Jan 06 14:41:20 * Spidler waves Jan 06 14:41:26 thank you Jan 06 14:41:30 bye Jan 06 14:55:15 I don't see a DSP mentionned in the datasheet of the AM3x, gst-dsp won't work on the xM board, or did I miss something ? I can't believe all resellers have discontinued the previous version without having at least on-par video decoding in the newer model :) Jan 06 14:59:27 yes the AM335x doesn't have a DSP. It has PRUs if that helps you. Jan 06 14:59:52 as you mention gst-dsp it's not really dsp but media acceleration, which the AM335x doesn't have either Jan 06 15:10:32 yann|work: the newer model has no video acceleration Jan 06 15:10:47 its not the intended use case Jan 06 15:23:31 does the instruction "and r1, 0xfffffff8" do the logical AND of r1 with the constant 0xfffffff8? Jan 06 15:27:05 av500: ah, thanks. Disappointing that vendors all claim that the xM superseded the original, then... Jan 06 15:27:46 BTW, just noticed an X15 on AliExpress, I thought it was not available yet ? Jan 06 15:28:06 http://www.aliexpress.com/item/999-0006389-BeagleBoard-X15-BeagleBoard-CircuitCo-Development-Board/32532181129.html?spm=2114.01020208.3.27.ORQCQz&ws_ab_test=searchweb201556_3,searchweb201644_3_10001_10002_10005_10006_10003_10004_62,searchweb201560_8,searchweb1451318400_6149 Jan 06 15:28:11 yates: in what flavor of assembly? Jan 06 15:28:27 let's say arm Jan 06 15:28:43 the am335x Jan 06 15:28:49 well it totally depends on what assembly you're using... Jan 06 15:29:23 yates: erm, the XM superseeded the Classic Jan 06 15:29:37 and yes, the XM had video acceleration like the Classic Jan 06 15:29:44 the BBW and BBB have not Jan 06 15:29:47 I think the AND instruction in ARM assembly takes 3 parameters Jan 06 15:30:17 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/CIHDAFAI.html Jan 06 15:30:35 the syntax above assembles without error Jan 06 15:30:37 alexanderhiam: /home/time-src/tool/cgtool/armv7l/gcc-linaro-5.1-2015.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -c -mcpu=cortex-a8 -mfloat-abi=soft -Wa,-mthumb -DTARGET_ARMV7L -DPLATFORM_LINUX_X86 -D_GLIBCXX_DEBUG -I/home/time-src/tool/cgtool/armv7l/gcc-linaro-5.1-2015.08-x86_64_arm-linux-gnueabihf/include/ -I/home/time-src/lib/inc/ -I/usr/local/include/ /home/time-src/app/tst-dram/ddr3_init.sx -o Jan 06 15:30:37 /tmp/yates/home/time-src/app/tst-dram/armv7llinux_x86/ddr3_init.o Jan 06 15:31:40 i believe it's equivalent to "and r1, r1, 0xfffffff8" Jan 06 15:31:55 yeah, I'd guess so Jan 06 15:32:12 but do the xM and the Classic have same kind of video acceleration ? Jan 06 15:32:50 i read in the architecture referene manual about the various shifts, but for a negated value of 0xfffffff8, i don't see how you could construct a shift for that. Jan 06 15:33:17 or has the classic acceleration using DSP, and the xM using PRU ? Jan 06 15:33:27 unless they have a one's complement shift or somesuch Jan 06 15:33:38 yates: no Jan 06 15:33:44 yates: classic and XM both have OMAP3 Jan 06 15:33:51 so DSP and HW accel for video Jan 06 15:33:56 av500: why are you talking to me? Jan 06 15:33:59 oops Jan 06 15:34:01 yann|work: ^^ Jan 06 15:34:14 yates: BBW and BBB have PRU but it has nothing to do with video Jan 06 15:43:32 av500: when you mention "DSP and HW accel", do you mean there is some other hw acceleration than things like gst-dsp ? Jan 06 15:43:51 gst-dsp is SW Jan 06 15:44:00 its the glue to link gst and the dsp codecs Jan 06 15:44:11 the dsp codecs run on the dsp and use the HW units Jan 06 15:44:34 ok Jan 06 15:45:27 and are there other APIs implemented (VA-API, VDPAU, OMX, whatever) ? Jan 06 15:45:53 yeah, there was some OMX foo when people were using OMAP3 for android Jan 06 15:45:59 best ignored Jan 06 15:47:02 yes, the OMX world is a bit strange, it seems :) Jan 06 15:49:42 otoh, on the rPI going through OMX directly was apparently the most efficient way - even gst uses an omx backend for decoding, but then gluing it to a gst glrenderer was quite inefficient... Jan 06 15:51:04 yann|work: everything is best consumed throught a few layers of wrappers Jan 06 15:51:14 is it possible to get the GPU to read the output of the decoding efficiently, when using gst-dsp (or any other stack, btw) Jan 06 15:51:20 I've seen some brief comments from RCN via a google search, but is the logo'ed BBB as shipped by Circuitco really GPL compliant? Jan 06 15:51:34 yann|work: the GPU does not do the decoding Jan 06 15:51:38 on omap3 Jan 06 15:51:53 cebarth: the hardware is not GPL licensed AFAIU Jan 06 15:51:59 av500: I got that Jan 06 15:52:20 right, but it ships with GPL software, obviously. Jan 06 15:53:34 my question is more about how to move the decoded frames to the screen - are they just decoded to the framebuffer ? Jan 06 15:54:11 any colorspace conversion occurs in the accelerator blocks ? Jan 06 15:55:33 yann|work: omap3 has HW overlays Jan 06 15:55:46 cebarth: ah, no idea about that. current images are by RCN. so you can look at his stuff. If you _really_ want compliance (and not just the sources), then you need to contact the vendor who sold you the board anyway. Jan 06 15:55:47 so you DSP decodes to YUV and the hardware can show that directly Jan 06 15:56:08 or you use the GPU to composite it all into RGB, with of course more memory overhead Jan 06 15:56:14 mostly asking because eg. SDL2 has moved to using OpenGL as default way to render even a 2D surface, and it is apparently really slower on some platforms than just writing to framebuffer - OTOH, if there is a colorspace conversion to do after HW decoding, doing it with a GL shader may be better Jan 06 15:56:35 av500: ok, that's cool Jan 06 15:56:37 yann|work: Omap3 is bandwith starved Jan 06 15:56:49 you dont want the GPU to shuffle data around Jan 06 15:57:13 best is to use HW overlays, given that your GUI can handle that Jan 06 15:57:37 yes, I'm all for HW overlays :) Jan 06 15:58:42 yann|work: note that all this gst/DSP stuff on XM is quite dated Jan 06 15:58:53 not sure there is a good working config around these days Jan 06 15:58:57 best do a time travel Jan 06 16:03:26 tbr: thanks. My main concern is to be compliant when I ship non-logo element14 boards, but I don't think what Circuitco via Arrow (for example) is shipping is sufficient. Jan 06 16:04:09 I'm still puzzled by not finding the DSP in the AM3x datasheet - but then, it looks like TI has reorganized their website, and many links from beagleboard.org are wrong (the ones for Classic and xM at least) Jan 06 16:04:34 av500: which time travel do you advise as best ? Jan 06 16:04:36 yann|work: there is no dsp on the AM335x Jan 06 16:04:47 cebarth: if you want to be sure, take off and nuke the emmc from orbit. less convenient for the user, but certainly no software compliance necessary. Jan 06 16:05:14 indeed Jan 06 16:05:45 are you talking about the am33xx? Jan 06 16:06:01 er, i mean, omap? Jan 06 16:19:29 yates: I'm talking about the SoC in the xM, which http://beagleboard.org/beagleboard-xm advertises as AM37x (which I tend to find strange, are there several board revisions/models with different SoCs ?) and not OMAP Jan 06 16:19:59 yann|work: thats TI and their naming schemes Jan 06 16:20:36 OMAP3530 / DM3730 Jan 06 16:20:45 and AM3730 too or so Jan 06 16:21:34 same silly-cone has many names Jan 06 16:21:38 so is that an OMAP3530 on the xM ? Jan 06 16:22:47 OMAP3630 I think aka DM3730 Jan 06 16:22:57 3530 is classic, XM was one gen newer Jan 06 16:23:42 just call it omap3 Jan 06 16:27:10 ok. So what's the best course nowaday to decode/display h.264 on those, if not through gst-dsp ? Jan 06 16:28:08 use a more modern board? Jan 06 16:28:21 you can do ~VGA in SW on the main CPU Jan 06 16:28:30 you can get some 720p with gst-dsp Jan 06 16:28:36 if you get it to work Jan 06 16:30:11 I'm aiming more at 1080p and possibly 2160p :) Jan 06 16:30:48 more modern board, like what for example ? The X15 is not out yet, right ? Jan 06 16:32:07 no 1080 on XM for sure Jan 06 16:34:13 ah, too bad... Jan 06 16:36:20 OK, I'll focus on other foundries than TI then (unless there are other boards I missed ?) Jan 06 17:14:38 vagrantc, CONFIG_GPIO_PCF857X=y see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/configs/omap2plus_defconfig?id=3ab74b89c4d50e6d29d3ace2d400a8a3f1e6de3f Jan 06 17:14:54 vagrantc, you guys have: # CONFIG_GPIO_PCF857X is not set Jan 06 17:17:35 (module would probally work too, but you guys need to enable it. ;) ) Jan 06 17:17:36 zmatt: i've got the ddr pll initialization done. i am able to read/write the first ddr location (0x80000000) but not the second... Jan 06 17:17:47 any ideas? Jan 06 17:18:16 i get a dabort if i write 0x80000001 Jan 06 17:18:25 or anyone... Jan 06 17:18:52 yann|work: i see. i too have always found the omap designations highly confusing Jan 06 17:21:46 dm81xx (8168 in our case) does 1080p fine Jan 06 17:22:07 has 3 video pipelines or whatever Jan 06 17:22:15 *8168 Jan 06 17:22:32 rcn-ee: guess what? Jan 06 17:23:04 nerdboy, you go the udoo work ing ;) Jan 06 17:23:09 "compatible" imx6sx-sd dt blows chunks on neo Jan 06 17:23:19 haha ;) Jan 06 17:23:41 there suppost to be compaible. ;) Jan 06 17:23:59 all their new stuff is in 3.14 udoo fork Jan 06 17:24:21 they're supposed Jan 06 17:24:23 with backported wifi/bt Jan 06 17:24:29 :) Jan 06 17:24:55 yeah... well the backported wifi/bt is better then what they had planned.. thank god for the "backport" project.. Jan 06 17:25:11 they wanted to do an external "wifi/bt" module build, but i said, no. ;) Jan 06 17:25:17 * nerdboy would rather see push to 4.x Jan 06 17:25:53 it's all the "imx6sx" stuff.. i don't think it'll be good on mainline till 4.6/4.7.. Jan 06 17:25:54 everything should be there in theory Jan 06 17:26:15 then wtf is SoloX support doing? Jan 06 17:26:38 rcn-ee: thanks, will test and update it! Jan 06 17:26:55 it's there but it's not there? Jan 06 17:27:24 even their funky usb driver has host support in 4.x Jan 06 17:27:35 but not in 3.14... Jan 06 17:27:38 vagrantc, i'm just going thru your config (armmp-lpae) with mainline 4.4.0-rc8 trying to get it to boot to mmc (without initrd..) Jan 06 17:27:39 rcn-ee: oh, that just has to do with mmc, not esata? Jan 06 17:27:57 oh, i never touch the stuff Jan 06 17:28:05 initrd forever! Jan 06 17:28:28 * nerdboy is still confused wtf the problem is... Jan 06 17:28:48 yeah, which as =m should work.. (there's still another config breaking mmc1 for me.. ;) ) Jan 06 17:28:56 rcn-ee: although with 4.4.0-rc6 i was able to do rootfs on both microSD and eMMC ... Jan 06 17:30:37 vagrantc, doh! that's why it doesn't help: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7-evm.dts?id=refs/tags/v4.4-rc8#n541 Jan 06 17:30:49 it's just for "dra7-evm"... Jan 06 17:31:12 but that should fix hdmi/mmc on dra7-evm if they boot debian's kernel.. Jan 06 17:32:28 rcn-ee: ah, sounds like a separate bug report i can't verify myself :) Jan 06 17:32:57 i can't verify it either.. (no dra7-evm here) Jan 06 17:34:35 well, that's at least one kernel compile test i can avoid Jan 06 17:34:46 esata issues still plagues me. Jan 06 17:35:15 rcn-ee: could you test eSATA with the debian kernel? Jan 06 17:35:47 i've tried 3 different drives, all with the same cable ... but as i recall, it works fine with your 4.1.x kernel Jan 06 17:36:06 probably should retest that to be sure Jan 06 17:36:17 a quick grep, dm8168-evm, sh73a0-kzm9q, and sun5i-r8-chip also need CONFIG_GPIO_PCF857X, the "chip" might be a good reason to enable it. ;) Jan 06 17:39:27 vagrantc, eSATA, yeah that's what i'm trying right now (mmc is in the way). ;) Jan 06 17:41:06 rcn-ee: are any of those other boards enabled in the debian kernel config? Jan 06 17:42:13 rcn-ee: oh, i'll be getting some of the sun5i-r8-chip boards soonish ... so i'll have the excuse to test then! Jan 06 17:43:23 yeah that's the $9 chip, i'm looking at the other side, a83t's. ;) Jan 06 17:48:56 * vagrantc is looking all around Jan 06 18:00:13 vagrantc, darn CONFIG_REGULATOR_PBIAS was in the way... So now it boots and i get the same: ata1: softreset failed (1st FIS failed) Jan 06 18:06:10 rcn-ee: how was it in the way? Jan 06 18:06:56 about like so: https://paste.debian.net/361410/ Jan 06 18:07:29 that looks rather familiar Jan 06 18:08:08 i'm tying to move pipp3 to built-in to see what happens.. Jan 06 21:20:34 Ok, so this is a long shot I guess, but I'm getting a "data abort" when trying to use sspi on SPI 1 from u-boot, but not on SPI 0. Could it be that the SPI1 peripheral has been claimed by SPI flash? I see that abort happens during reset and writing the sysconfig register. Jan 06 21:28:50 Never mind, it was me forgetting to enable the clock for spi1. Jan 06 23:50:24 eliasbakken: unfortunately u-boot has crappy error reporting, but yes a data abort generally means one of: 1. misaligned access (u-boot specific, normally allowed) 2. unroutable address 3. target is unpowered, unclocked, held in reset, or otherwise disabled Jan 06 23:50:57 4. target doesn't support the particular access, e.g. a write to a read-only register (rare, most peripherals just ignore this) Jan 06 23:51:14 3 is most common Jan 06 23:51:41 5. request denied by target firewall Jan 06 23:53:01 and I know at least one peripheral which aborts if you write an inappropriate *value* to a register, but it's not present on the am335x Jan 07 00:15:24 the am335x has a firewall? Jan 07 00:18:06 yup internal to the dual-ethernet iirc. Jan 07 00:19:02 hmmm? Jan 07 00:25:52 ok wtf is going on with my wifi Jan 07 00:26:01 wb? Jan 07 00:26:01 veremit: no I'm talking about interconnect firewalls Jan 07 00:26:18 ahh .. chip internals. my bad. lol. Jan 07 00:27:37 the ethernet switch has no particular firewalling capabilities, beyond things like blocking a particular MAC address Jan 07 00:28:38 ds2: this is news to you? Jan 07 00:30:00 I think every L3 peripheral/subsystem has a firewall Jan 07 00:30:20 I'da thought over a certain complexity it was needed Jan 07 00:30:23 EMIF has a firewall on RAM Jan 07 00:30:45 the L4 interconnects have firewalling, though less expressive Jan 07 00:31:29 EDMA has built-in memory protection support also, but unfortunately rendered mostly useless since you can't (afaik) assign initiators to a different security domain (MReqDomain), they're all stuck at zero Jan 07 00:32:36 there are local firewalls inside the cortex-a8 subsystem also, keeping you from reading secrom or accessing the first 1 KB of its local SRAM Jan 07 00:43:29 mapping the firewalls is still on my to-do list for the am335x (which L3 area they cover, how many regions they support, which metadata they have available to differentiate requests, etc) Jan 07 00:43:59 the L4 protection regions are already in my memory map spreadsheet Jan 07 01:00:04 ds2: http://gerbil.xs4all.nl/firewall.h.html Jan 07 01:09:34 gerbil :) heh Jan 07 01:16:21 the L4 interconnects have at least one protection region for each peripheral, plus one for each block of interconnect registers Jan 07 01:17:38 but you can only assign each to one of a small number of protection groups (typically 8), each of which is a fairly basic filter Jan 07 01:17:57 you can't even grant read-only access to some initiator, it's either full-access or no-access Jan 07 01:26:03 these mechanisms really deserve to be more well-known and widely used... e.g. peripherals can usually not be shared by multiple cores, and the gpu ought to be limited to writing to its designated memory areas Jan 07 01:27:01 not quite as important yet on the am335x, but on the x15 you'll otherwise go nuts trying to debug an issue caused by one of the countless cores and DMA engines making some incorrect write and clobbering your state Jan 07 01:41:25 zmatt: thought that was removed in the am335x. Jan 07 01:45:58 eh, no? Jan 07 01:46:26 they just didn't bother giving the am335x a decent TRM chapter documenting its interconnect Jan 07 01:46:35 oh it is undocumented? Jan 07 01:46:55 seem to recall it being tied in with the DSS Jan 07 01:47:36 ?? Jan 07 01:48:17 it has nothing to do with the DSS in particular, though I guess on HS omaps DSS will often be protected Jan 07 01:48:32 it's undocumented in the am335x TRM Jan 07 01:48:45 pretty decently documented in the dm814x and omap4/5 TRMs **** ENDING LOGGING AT Thu Jan 07 02:59:58 2016