[beagleboard] 3.15.0-rc5-bone1

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

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.

So far "v3.15-rc5" seems okay on my test farm, I'm getting close to
moving it over v3.14.x in the --beta-kernel channel for the bones..

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?

right now the options are:

cape=tty01
cape=tty02
cape=tty04

As these were something i need here in the lab for a new cape.

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.15/patches/dts-bone-capes/0001-capes-ttyO1-ttyO2-ttyO4.patch

Looking at the above patch, it's pretty easy to add multiple serial
devices to a dts if you need it.

I just haven't really done much with the lcd's.

Regards,

is there a quick list somewhere for getting the PRU enabled in 3.15?

thanks!

Bob

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

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.”

both the 3.8 and 3.15 driver probe functions look like this:

#ifdef CONFIG_ARCH_DAVINCI_DA850
/* Power on PRU in case its not done as part of boot-loader */
gdev->pruss_clk = clk_get(&dev->dev, “pruss”);
if (IS_ERR(gdev->pruss_clk)) {
dev_err(&dev->dev, “Failed to get clock\n”);
kfree(gdev->info);
kfree(gdev);
ret = PTR_ERR(gdev->pruss_clk);
return ret;
} else {
clk_enable(gdev->pruss_clk);
}
#endif

since this is the Sitara chip I don’t see anywhere else the clock is being activated.

The module should be loaded, as uio_pruss appears in the lsmod list

thanks,

Bob