**** BEGIN LOGGING AT Sat Dec 26 02:59:58 2015 Dec 26 08:52:03 can you set a resolution to 320x240 which is the max my 3.5 touchscreen to roll view 800x600? Dec 26 13:46:37 greetings. before I buy one I want to know if anyone here has managed to get the beagleboard black to operate as an MTP device? Dec 26 13:52:18 https://github.com/prife/ptp-gadget Dec 26 13:53:20 http://git.denx.de/?p=ptp-gadget.git;a=summary seems actually updated Dec 26 13:53:26 My question was more along the lines of will the board function as the USB client? Dec 26 13:54:12 I was working with a raspPi and found that the USB ports will not work as a USB client. Dec 26 13:54:13 "usb gadget" is the magic term Dec 26 13:55:01 https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-usbgadget Dec 26 13:55:03 bueto-mtp works via the usb gadget interface as well, but the hardware on the rPi would not support the USB client code. Dec 26 13:55:08 Provides http access to beaglebone black over usb. Dec 26 13:55:21 It actually does Dec 26 13:55:25 If you use a model A Dec 26 13:55:26 IIRC Dec 26 13:55:32 Or a zero Dec 26 13:55:39 it's the hub chip that's stopping it. Dec 26 13:55:53 (at least in principle, I don't know if the Pi kernel actually supports the hw) Dec 26 13:57:12 I'm running archlinux on Pi-A it does not have the usbgadget stuff. Dec 26 13:57:34 perhaps I should try and install Angstrom linux and work from that. Dec 26 15:26:39 if you can get a pre built image of it. Dec 26 20:10:54 zmatt: what is the linke to that cheap jtag you gave a few weeks ago at digikey? i've lost it. Dec 26 20:11:00 for am335x Dec 26 20:11:09 that works with CCS Dec 26 20:12:41 if i recall correctly, it was around USD79 Dec 26 21:08:48 an xds1000v2 (get one with a cTI-20 connector!) Dec 26 21:08:52 xds100v2 Dec 26 21:09:29 e.g. https://www.digikey.com/product-detail/en/TMDSEMU100V2U-20T/296-31067-ND/2261950 Dec 26 21:16:06 thanks Dec 26 21:21:39 in section 26.1.4.3 of the trm it is stated that the DDR DPLL is initialized to 400 MHz by the rom code. is this to be trusted? Dec 26 21:26:04 dunno, I don't think I ever checked it yet Dec 26 21:27:57 the list looks slightly out of date, e.g. "L3 ADPLLS locked to provide 200MHz" ... the am335x has no L3 PLL, its predecessor did but the am335x uses the core PLL to derive the L3 clock Dec 26 21:28:25 otoh the numbers otherwise look okay to me Dec 26 21:29:26 ok, cool Dec 26 21:30:21 the emif configuration states that you must enable clock domain PD_PER_L4_GCLK, but a search of the trm doesn't reveal which register this is part of Dec 26 21:30:55 see section 7.3.2 Dec 26 21:34:54 where is the register to control this domain? Dec 26 22:52:39 i think the clock architecture of the am335x is horribly explained in the trm Dec 26 22:53:39 e.g., take a look at Figure 8-10, "Core PLL", and try to relate those signal names to anything else in the trm. there are a few you can find, but most seem to be uniquely named in that diagram Dec 26 22:56:26 * KotH has seen worse Dec 26 22:57:10 I'm a bit confused about what the SD OCP clock is that is mentioned in the MMC documentation. Dec 26 22:58:10 KotH: of course. the goal is not to be readable, but just not be the worst out there... Dec 26 22:58:17 Heh. Dec 26 23:02:36 yates: Is it not in CM_PER_L4LS_CLKSTCTRL? Dec 26 23:06:30 yates: sorry for the delayed response, I'm in the train on my way home Dec 26 23:07:08 yates: and it says L3, not L4 Dec 26 23:07:50 the L3 clock domain is on by default, you wouldn't even be able to reach PRCM to enable it otherwise Dec 26 23:08:46 the GCLK means it's a gated version of the clock, the gate being whether the module (EMIF in this case) is enabled or not Dec 26 23:10:36 your main concern is whether the DDR PLL has indeed been set up by ROM... you can check bit 0 of the CM_IDLEST_DPLL_DDR register (in PRCM) to verify whether the PLL has indeed been set up Dec 26 23:13:11 if it is, then just enable EMIF in its module control (CM_PER_EMIF_CLKCTRL) and you should be able to access its registers Dec 26 23:14:14 but note that EMIF has some fairly specific setup to be followed, including some registers in the Control Module.... this stuff isn't terribly well documented Dec 26 23:14:25 it may be best to closely follow e.g. u-boot Dec 26 23:15:22 at the very least the DDR PHYs need to be configured, and the VTP macro initialized Dec 26 23:20:42 mcarberry: what about it? Dec 26 23:21:51 mcarberry: the "SD OCP clock" sounds like it's just an interface clock Dec 26 23:22:22 almost home, bbiab Dec 27 00:03:13 zmatt: It mentions enabling the SD OCP cloc, and the CLKADPI clock. I've enabled the clocks in CM_PER_MMC0_CLKCTRL, and am not sure if there's something else I should have enabled. Dec 27 00:07:37 hmm, I've successfully communicated with eMMC... Dec 27 00:07:38 I'm attempting to write an mmc driver for rtems. Haven't really done this before. Dec 27 00:18:40 Seemed like a reasonable way to attempt to get my feet wet. Dec 27 00:18:40 mmc doesn't really require any unusual clocks Dec 27 00:18:40 Seems like just that one and the 32Khz clock divisor? Dec 27 00:18:55 Eh, just was confused by the writing I guess. Dec 27 00:18:55 you don't really control the individual clocks, you just enable the module and prcm will ungate the necessary clocks (if not already ungated for other reasons) Dec 27 00:18:57 of course it is relevant that the clock signals themselves must be setup already, but they are in this case... they're all standard clocks used by many many modules Dec 27 00:18:59 zmatt: That's makes sense for sure. Dec 27 00:19:05 Thanks! Dec 27 00:19:06 core and per PLLs are typically never touched after ROM sets them up Dec 27 00:19:06 you might double-check clk_24 to be sure Dec 27 00:19:12 although it'll be a waste of time :P Dec 27 00:19:12 what is the symptom? Dec 27 00:19:13 zmatt: No symptoms. Just starting and was reading that and figured I'd get clairification. Dec 27 00:19:13 *clarification Dec 27 00:19:13 the mmc module interface *is* a bit weird... I mean it's sort of the standard SD host controller interface, but with enough magic TI sauce to make it not quite so Dec 27 00:19:13 Heh. Does TI have a habit of doing that? Dec 27 00:19:15 well some peripherals are completely their own design, others are stuff they partially purchased and then glued, yet other cases they want to satisfy some interface standard to allow driver reuse Dec 27 00:20:00 Is that why there's a lot of reference to omap3 drivers? Dec 27 00:20:09 Similarities between the sitara and that? Dec 27 00:20:21 but I usually prefer the first case, provided they didn't screw it up :P but the other two invariably lead to ugliness Dec 27 00:20:59 sitara is just a wide-scoped brand for their ARM cores Dec 27 00:21:19 but yes many peripherals are inherited from omap4, omap3, or even older Dec 27 00:21:47 Ahh Dec 27 02:40:33 zmatt: you wrote: 19:09 you don't really control the individual clocks, you just enable the module and prcm will ungate the necessary clocks (if not already ungated for other reasons) Dec 27 02:40:57 but this contradicts what you wrote to me in an email: "make sure its clock domain is awake by writing 2 (SW_WKUP) to the applicable clock domain register. " Dec 27 02:41:08 or seems like does. Dec 27 02:44:29 i'm confused at this fundamental level. Dec 27 02:45:27 my current mental model is this: 1) there is the generation of clocks themselves, such as the various DPLLs driven from the main input clock. it appears those are all setup properly by ROM Dec 27 02:45:54 2) there is a bit in the PRCM module that turns on a clock domain, i.e., ungates the clock to it. Dec 27 02:46:18 3) there is enable control of the individual modules. Dec 27 02:47:40 apparently also the module enable control is part of the PRCM as well, e.g., 8.1.12.1.8, the EMIF clkctrl register Dec 27 02:49:07 is this correct? Dec 27 02:59:12 by the way, it appears these clock domain controls are in the CM_PER_L3_CLKSTCTRL register, section 8.1.12.1.3 Dec 27 02:59:26 u-boot configuration noted, by the way **** ENDING LOGGING AT Sun Dec 27 02:59:59 2015