On Tuesday, June 17, 2014 3:16:40 PM UTC-4, [email protected] wrote: > > so far, some minor progress. > > the kernel does not have the drivers enabled in drivers/uio > based on the nxctrl project, I replaced the files and Konfig , which > allowed me to select the Ti Pruss Driver when rebuilding the kernel. > > the device tree has no reference or mentions of the pru, > I added this to the am33xx.dtsi file > pruss: pruss@4a300000 { > compatible = "ti,pruss-v2"; > ti,hwmods = "pruss"; > ti,deassert-hard-reset = "pruss", "pruss"; > reg = <0x4a300000 0x080000>; > ti,pintc-offset = <0x20000>; > interrupt-parent = <&intc>; > status = "disabled"; > interrupts = <20 21 22 23 24 25 26 27>; > }; > > I added this to the boneblack dts file > &pruss { > pinctrl-names = "default"; > pinctrl-0 = <&uart2_pins>; > // pinctrl-0 = <&pruss_pins>; > /* does this initialize the I/O or something? */ > > status = "okay"; > }; > > i pointed it at the uart pins, since I dont have any pru pins defined at > the moment, I'm trying to get the memory transfer example to work. > > at this point, the uio_pruss appears when I do lsmod. > and uio0 thru uio7 appear when doing ls /sys/class/uio > > the driver appears to initialize ok, as the driver struct gets populated > with addresses (running gdb remotely) > > the software bugs out (unable to access memory at 0x0 or something like > that, gdb clears the output window pretty quickly) > > if I execute the program from a terminal window I get a bus error, if I > sudo execute it it just exits without completing, no error. (I am logged > in as root.) > > so, I see in the nxctrl project a clock initialization, do I need to > create something like this? > #if 1 // shoud I need this? > U32REG_CM_PER_L3S_CLKCTRL |= BIT1; > U32REG_CM_PER_L3_CLKSTCTRL |= BIT1; > U32REG_CM_PER_L3_INSTR_CLKCTRL |= BIT1; > U32REG_CM_PER_L3_CLKCTRL |= BIT1; > U32REG_CM_PER_OCPWP_L3_CLKSTCTRL |= BIT1; > U32REG_CM_PER_L4LS_CLKSTCTRL |= BIT1; > U32REG_CM_PER_L4LS_CLKCTRL |= BIT1; > #endif > > > is pru support likely to happen in anything post 3.8? > > any suggestions, I feel like I'm missing something obvious (but perhaps > burried on page 666 of some document somewhere) > > Thanks!! > > Bob >
I got a response from the TI apps team: "It's the first line of the prussdrv_pruintc_init() function. If they haven't enabled clocks as they suspect then writing to the INTC registers will not work. As an FYI this is done in the pruss_probe() function inside the kernel driver (uio_pruss.c). May want to make sure they are loading the uio driver." > > > On Friday, June 13, 2014 9:57:50 AM UTC-4, [email protected] wrote: >> >> is there a quick list somewhere for getting the PRU enabled in 3.15? >> >> thanks! >> >> Bob >> >> On Tuesday, May 20, 2014 11:10:31 AM UTC-4, Ross Morrison wrote: >>> >>> Is it safe to move forward on 3.15 at this time? This is the only kernel >>> that supports my Asix AX88x72A based USB Ethernet dongles correctly on >>> our custom board. I'm using the Wheezy 7.5 root file system and would >>> like to stay here and get everything working. My wants are to get >>> multiple UARTs running and an LCD based on the LCD-3. >>> >>> Since there is no capemgr for 3.14 and above (at this time), is there a >>> simple way to get these cape type devices working? >>> >>> I saw in one of the postings to add cape=tty01 in uEnv.txt to enable >>> tty01, are there other options to the like this to force configuration >>> from uEnv.txt? >>> >>> Thanks, >>> Ross >>> >>> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
