4.19 bone kernel with uio_pruss?

[Daniel Kulp]

I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem:  uio_pruss is not configured in as it is with 4.14.  Is this an oversight?  Is there anyone I need to contact to try and convince them to re-enable uio_pruss?     I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor.   uio_pruss is a must-have.  

The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons.  Mostly concerned about the bone kernels right now.

[Robert Nelson]

On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp <d...@kulp.com> wrote:
>
>
> I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem: uio_pruss is not configured in as it is with 4.14. Is this an oversight? Is there anyone I need to contact to try and convince them to re-enable uio_pruss? I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor. uio_pruss is a must-have.
>
> The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons. Mostly concerned about the bone kernels right now.

Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
notice and mention it! ;)

Roger @ TI with comments from David posted an RFC for ti's remotproc
for mainline.. That's what i have in v4.19.x-bone "today" (and
v4.20.x-bone/v5.0.x-bone)..

Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all
uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module
to v4.17.x) and it should work fine..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Daniel Kulp]

Does this mean it's something that is being worked on to be fixed for an upcoming 4.19 kernel update or are UIO folks completely SOL and stuck on 4.14 kernels?

Dan

[Robert Nelson]

On Mon, Jan 28, 2019 at 1:33 PM Daniel Kulp <d...@kulp.com> wrote:
>
>
> Does this mean it's something that is being worked on to be fixed for an upcoming 4.19 kernel update or are UIO folks completely SOL and stuck on 4.14 kernels?

Sorry, it's not something "i'm" personally working on. Patches
welcome, like i mentioned the last point it worked was before the
v4.18.x merge.

[Jason Kridner]

On Monday, January 28, 2019 at 1:57:56 PM UTC-5, Daniel Kulp wrote:

I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem:  uio_pruss is not configured in as it is with 4.14.  Is this an oversight?  Is there anyone I need to contact to try and convince them to re-enable uio_pruss?     I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor.   uio_pruss is a must-have.  

The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons.  Mostly concerned about the bone kernels right now.

For your use case, does it work if CONFIG_SND_DUMMY is added to Robert's 4.14-ti builds? 

[Daniel Kulp]

No idea... I've never tried building a kernel for the BBB's.  I've always just relied on the the update_kernel script providing a usable kernel.  For the most part, you guys have done a great job providing kernels that works for us (or have fixed things we've run into real quick).   The lack of uio_pruss is the first real issue  that I'm concerned about. 

The dummy snd device is just "useful" cause a boot time, we can detect if there isn't a sound device and load the module.  Then the rest of the app can assume there is a sound device available and things "just work".   It's mostly just a nice to have.

I cannot use the TI kernel as the cpu idle state driver in the TI kernel really screws up the GPIO0 timing.    The bone kernels don't have the idle states so GPIO0 timing is much more consistent.  At some point, I'd like to dig through the TI kernel stuff to see if there is a way to completely turn off the cpu idle driver, but haven't had the time.   I've used the cpupower to turn off the various cpuidle states and that helped 95% of the time, but it's still not as predictable as with the bone kernel. 

[Matthijs van Duin]

On Monday, 28 January 2019 20:40:09 UTC+1, RobertCNelson wrote:

On Mon, Jan 28, 2019 at 1:33 PM Daniel Kulp <d...@kulp.com> wrote:
> Does this mean it's something that is being worked on to be fixed for an upcoming 4.19 kernel update or are UIO folks completely SOL and stuck on 4.14 kernels?

Sorry, it's not something "i'm" personally working on.  Patches
welcome

I'll look into it

Matthijs 

[Jason Kridner]

So why don't you just ask Robert to add CONFIG_SND_DUMMY to both the older -ti and -bone kernels as we are still using 4.14 for stable stuff for now due to this sort of breakage? A message about the breakage to linux-omap would really be helpful.

 

[Matthijs van Duin]

I've forward-ported the uio-pruss driver to the 4.19 kernel series, and cleaned it up a bit in the process. I've done a quick test on beaglebone black and on beagleboard-x15 (both pru instances), including that irqs work.

Here's the patchset:

https://github.com/mvduin/ti-linux-kernel-dev/tree/ti-linux-4.19.y-uio-pruss/patches/pruss

Only the first patch is needed on beaglebone, the second one is beagleboard-x15 specific. The third patch enables uio-pruss in the base dts, which you'll need for beagleboard-x15 but on beaglebone you can also just use the AM335X-PRU-UIO overlay instead.

Matthijs

[Daniel Kulp]

Many thanks for digging through this... once this is available in a kernel I can install via "update_kernel.sh", I'd be more than happy to test my UIO based apps and such.

Dan

[Robert Nelson]

On Sun, Feb 10, 2019 at 3:52 PM Daniel Kulp <d...@kulp.com> wrote:
>
>
> Many thanks for digging through this... once this is available in a kernel I can install via "update_kernel.sh", I'd be more than happy to test my UIO based apps and such.

Matthijs patchset is now merged into 4.19.15-ti-r8, should be pushed
out in a few hours.

[Daniel Kulp]

Well,  it's still not working for our application.   :(    Something isn't working the same as it used to.  

If you grab the old am335x_pru_package stuff from https://github.com/beagleboard/am335x_pru_package and build/install, none of the examples work either.    They all crash:

#0  0xb5ac6ffc in __pruss_detect_hw_version () from /usr/local/lib/libprussdrv.so

#1  0xb5ac717e in __prussdrv_memmap_init () from /usr/local/lib/libprussdrv.so

#2  0xb5ac74b8 in prussdrv_open () from /usr/local/lib/libprussdrv.so

so it looks like something is behaving differently or is laid out in memory differently or something.   Not sure.

Dan

[Matthijs van Duin]

I just realized that enabling it in the base dts for beaglebone using a remoteproc-pru compatible structure was probably a bad idea... While it is safe to apply the remoteproc-pru overlay on top of it (albeit pointless since it hasn't been ported to 4.19 yet), applying the uio-pruss overlay on top of it would create a mess.

Assuming you have the UIO-PRUSS overlay enabled, try disabling it.

[Daniel Kulp]

On Tuesday, February 12, 2019 at 1:06:51 PM UTC-5, Matthijs van Duin wrote:

I just realized that enabling it in the base dts for beaglebone using a remoteproc-pru compatible structure was probably a bad idea... While it is safe to apply the remoteproc-pru overlay on top of it (albeit pointless since it hasn't been ported to 4.19 yet), applying the uio-pruss overlay on top of it would create a mess.

Assuming you have the UIO-PRUSS overlay enabled, try disabling it.

Without the uio-pruss overlay, I don't get any /dev/uio entries and then nothing works.    Is there a different overlay I need?    

 

[Robert Nelson]

I just enabled the first patch by default:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.19.y/patch.sh#L489-L492

[Matthijs van Duin]

On Tue, 12 Feb 2019 at 19:56, Robert Nelson <robert...@gmail.com> wrote:

I just enabled the first patch by default:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.19.y/patch.sh#L489-L492

Ahh, I missed that. I just saw the merge in the git commits and didn't realize it was a merge with modifications.

I wonder what's going on then, I'll see if I can replicate the problem.

Daniel, when you say "crash", you mean a SIGBUS presumably?

Matthijs

[Daniel Kulp]

Yep.  SIGBUS.

-- 
Daniel Kulp
d...@kulp.com - http://dankulp.com/blog

[Matthijs van Duin]

OK, shame on me for just testing everything works on bbx15 and merely checking the devices show up on beaglebone and assuming they work. They really didn't. I had overlooked that the ti,deassert-hard-reset DT property is a non-standard thing added by the original uio-pruss patch. A better solution would be to have the uio-pruss driver deassert the reset directly, just like the pruss_soc_bus driver does, but since I don't have time to persue that right now I've simply added that patch back in.

I've also dropped the patch that enables uio-pruss by default on beaglebone, and restructured the dts patches in general. The patch set is now:

0001: uio-pruss driver itself

0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also needed for remoteproc-pru)

0003: add support for ti,deassert-hard-reset (needed for uio-pruss on am335x)

0004: outline dts declarations for pruss (can be dropped when full declarations are added for remoteproc-pru)

0005: dtsi files for enabling uio-pruss (for convenience of #including by those who want it)

0006: enable uio-pruss by default on beagleboard-x15 (feel free to drop, but seemed better than nothing until remoteproc-pru works)

and I've moved them to patches/drivers/ti/uio_pruss.

Hopefully this makes the patchset acceptable to merge as-is (or optionally dropping the last patch if you feel it is a bad idea).

Tests confirmed working on beaglebone-black:

am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam

py-uio/pru-examples/intc-test.py

py-uio/pru-examples/ddr-ping.py

Tests confirmed working on beagleboard-x15:

am335x_pru_package/pru_sw/example_apps/PRU_memAccessPRUDataRam (pruss1)

py-uio/pru-examples/intc-test.py (pruss1 and pruss2)

py-uio/pru-examples/ddr-ping.py (pruss1 and pruss2)

I should caution that the libprussdrv examples look pretty broken. The PRU_industrialEthernetTimer example doesn't actually work (it doesn't wait 10s like it was supposed to) and after fixing the most obvious bugs (TICKS written to wrong memory, shared memory access not volatile-qualified) it seems to hang forever. The remaining two examples use /dev/mem to access a part of DDR3 memory that's not actually reserved for use by pruss (instead of using libprussdrv's API to access the ddr3 memory that is reserved for pruss), and will therefore probably clobber some kernel memory.

Matthijs

[Roger Quadros]

+David, Tony, Suman.

Robert, Matthijs, Daniel,

On 28/01/19 21:15, Robert Nelson wrote:
> On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp <d...@kulp.com> wrote:
>>
>>
>> I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem: uio_pruss is not configured in as it is with 4.14. Is this an oversight? Is there anyone I need to contact to try and convince them to re-enable uio_pruss? I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor. uio_pruss is a must-have.
>>
>> The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons. Mostly concerned about the bone kernels right now.
>
> Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
> notice and mention it! ;)
>
> Roger @ TI with comments from David posted an RFC for ti's remotproc
> for mainline.. That's what i have in v4.19.x-bone "today" (and
> v4.20.x-bone/v5.0.x-bone)..

This is the latest series that I posted for pruss remoteproc
https://lkml.org/lkml/2019/2/4/677

I have been mostly focussing on remoteproc framework and PRU ethernet driver use case.

I see that uio_pruss is important for the bone community. We will need
to work together to make sure that it continues to operate when the
PRUSS remoteproc stuff gets merged to kernel.org.

I will keep you all in cc when I post v3 of the series so you can
test uio_pruss.c and review the patches.

Meanwhile, I'd like to understand what must be done to ensure uio_pruss.c
is supported. We might need to make some changes to uio_pruss.c
so that it can understand the device tree node (interrupts, memory regions)
and do runtime_pm etc. It will be great if we don't have to make any
device tree changes when switching between pruss_remoteproc and uio_pruss
drivers. Just unbinding the current driver and binding the alternate driver
should work.

>
> Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all
> uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module
> to v4.17.x) and it should work fine..
>
> Regards,
>

cheers,
-roger

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[Matthijs van Duin]

On Wed, 13 Feb 2019 at 12:20, Roger Quadros <rog...@ti.com> wrote:

I see that uio_pruss is important for the bone community. We will need
to work together to make sure that it continues to operate

Fortunately uio_pruss is a pretty simple driver that's easy to forward-port.

 

Meanwhile, I'd like to understand what must be done to ensure uio_pruss.c
is supported. We might need to make some changes to uio_pruss.c
so that it can understand the device tree node (interrupts, memory regions)
and do runtime_pm etc. It will be great if we don't have to make any
device tree changes when switching between pruss_remoteproc and uio_pruss
drivers. Just unbinding the current driver and binding the alternate driver
should work.

Adding ti,pintc-offset = <0x20000>; to &pruss should suffice to be able to switch between the two drivers (by changing "compatible" in the DT or by rebinding at runtime). It might even be nice to add both drivers to the compatible-property of &pruss to make it automatically fall back to uio-pruss if remoteproc-pru is disabled in kernel config or blacklisted as a module. All the child nodes inside &pruss are simply ignored by the uio-pruss driver.

I think if the pruss_soc_bus is driver is used then it'll take care of deasserting the hard reset, so the ti,deassert-hard-reset property (and the kernel patch that introduces it) wouldn't be needed. I haven't tested this though. On the other hand if you want the same DT to work even if pruss_soc_bus is disabled in kernel config or blacklisted as a module, then you can add "simple-pm-bus" as fallback to the compatible-property of &pruss_soc_bus and add the ti,deassert-hard-reset = "pruss", "pruss"; property to it. I don't think adding this property messes up the actual pruss_soc_bus driver, but that would need to be double-checked.

For the beagleboard-x15 I also add a "pruss-instance" property to each pruss instance containing its name ("pruss1" or "pruss2") to allow udev rules to create convenient symlinks.

Matthijs

[Matthijs van Duin]

Since I just noticed a bunch of people were added to the Cc... Just for context, this is the patch set I made to get uio-pruss for the am335x and dra7/am57xx working again on the 4.19-ti series kernel:
https://github.com/mvduin/ti-linux-kernel-dev/tree/ti-linux-4.19.y-uio-pruss/patches/drivers/ti/uio_pruss

Summary of the patches:

0001: uio-pruss driver itself

0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also needed for remoteproc-pru)

0003: add support for ti,deassert-hard-reset (needed for uio-pruss on am335x)

0004: outline dts declarations for pruss (can be dropped when full declarations are added for remoteproc-pru)

0005: dtsi files for enabling uio-pruss (for convenience of #including by those who want it)

0006: enable uio-pruss by default on beagleboard-x15 (feel free to drop, but seemed better than nothing until remoteproc-pru works)

On Wed, 13 Feb 2019 at 12:44, Matthijs van Duin <matthij...@gmail.com> wrote:

Adding ti,pintc-offset = <0x20000>; to &pruss should suffice

Obviously we could also change the uio-pruss driver to avoid this need for this property entirely. It ought to be implicit from the compatible-string.

Matthijs

[Roger Quadros]

On 13/02/19 13:57, Matthijs van Duin wrote:
> Since I just noticed a bunch of people were added to the Cc... Just for context, this is the patch set I made to get uio-pruss for the am335x and dra7/am57xx working again on the 4.19-ti series kernel:
> https://github.com/mvduin/ti-linux-kernel-dev/tree/ti-linux-4.19.y-uio-pruss/patches/drivers/ti/uio_pruss
>
> Summary of the patches:
> 0001: uio-pruss driver itself

> +#ifdef CONFIG_ARCH_DAVINCI_DA850
> if (pdata->sram_pool) {
> gdev->sram_pool = pdata->sram_pool;
> gdev->sram_vaddr =

What is this sram pool? Is it about MSMC/OCMC RAM? Why is this only for DA850?

> 0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also needed for remoteproc-pru)

This part will eventually be not needed as we are moving away from hwmods.
If you see
https://www.spinics.net/lists/devicetree/msg272572.html

I have got rid of pruss_soc_bus entirely. We now use ti-sysc bus driver to
manage the SYSCONFIG register.

> 0003: add support for ti,deassert-hard-reset (needed for uio-pruss on am335x)

This should also be managed by ti-sysc bus driver but using some form of
reset control driver that can toggle the necessary PRM registers RESET bit.
There were some challenges as to how to keep the clockdomain out of auto-idle
before reset can be issued.

> 0004: outline dts declarations for pruss (can be dropped when full declarations are added for remoteproc-pru)
> 0005: dtsi files for enabling uio-pruss (for convenience of #including by those who want it)

The only issue I see here is these 2 properties

compatible = "ti,pruss-v2";
ti,pintc-offset = <0x20000>;

It will be nice if we can retain the compatibles that I'm using here https://lkml.org/lkml/2019/2/4/679
See PRUSS Node->Required properties->compatible

We use a different compatible for every SoC as there are differences e.g. different RAM sizes, number of interrupts, INTC offset, etc.
So if we can teach uio_pruss to decipher the different compatibles and get the register offsets/RAM sizes right using some kind
of driver data (of_match_table->data?), then you don't need ti,pintc-offset.

> 0006: enable uio-pruss by default on beagleboard-x15 (feel free to drop, but seemed better than nothing until remoteproc-pru works)
>

> On Wed, 13 Feb 2019 at 12:44, Matthijs van Duin <matthij...@gmail.com <mailto:matthij...@gmail.com>> wrote:
>
> Adding ti,pintc-offset = <0x20000>; to &pruss should suffice
>
>
> Obviously we could also change the uio-pruss driver to avoid this need for this property entirely. It ought to be implicit from the compatible-string.

Exactly.

[Roger Quadros]

Robert,

On 28/01/19 21:15, Robert Nelson wrote:

> On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp <d...@kulp.com> wrote:
>>
>>
>> I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem: uio_pruss is not configured in as it is with 4.14. Is this an oversight? Is there anyone I need to contact to try and convince them to re-enable uio_pruss? I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor. uio_pruss is a must-have.
>>
>> The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons. Mostly concerned about the bone kernels right now.
>
> Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
> notice and mention it! ;)
>
> Roger @ TI with comments from David posted an RFC for ti's remotproc
> for mainline.. That's what i have in v4.19.x-bone "today" (and
> v4.20.x-bone/v5.0.x-bone)..

All upstream PRUSS series that I posted will not work without changes in
the resource tables in pru-software-support packages.

e.g.
https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f

If you can wait for 2 weeks then we could have something in
TI 2019 that should work smoothly.

cheers,
-roger

>
> Last i looked at v4.19.x-bone and uio_pruss, you'll need to revert all
> uio changes in v4.18.x/v4.19.x/etc.. (essentially revert that module
> to v4.17.x) and it should work fine..
>
> Regards,
>

--

[Robert Nelson]

Hi Roger,

On Wed, Feb 13, 2019 at 9:52 AM Roger Quadros <rog...@ti.com> wrote:
>
> Robert,
>
> On 28/01/19 21:15, Robert Nelson wrote:
> > On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp <d...@kulp.com> wrote:
> >>
> >>
> >> I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem: uio_pruss is not configured in as it is with 4.14. Is this an oversight? Is there anyone I need to contact to try and convince them to re-enable uio_pruss? I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor. uio_pruss is a must-have.
> >>
> >> The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons. Mostly concerned about the bone kernels right now.
> >
> > Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
> > notice and mention it! ;)
> >
> > Roger @ TI with comments from David posted an RFC for ti's remotproc
> > for mainline.. That's what i have in v4.19.x-bone "today" (and
> > v4.20.x-bone/v5.0.x-bone)..
>
> All upstream PRUSS series that I posted will not work without changes in
> the resource tables in pru-software-support packages.
>
> e.g.
> https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f
>
> If you can wait for 2 weeks then we could have something in
> TI 2019 that should work smoothly.

So around the time that your first RFC came out, we actually added
that repo by default under /opt/source/ so users could test out your
patchset on the beagle default images:

https://github.com/RobertCNelson/omap-image-builder/commit/edd84bc5c2d925d67d00d0c2008f48cdd75e3e99

So any Stretch/Buster/Bionic image after Nov 24 2018, has your repo
installed by default in the root file system. ;)

[Roger Quadros]

Robert,

On 13/02/19 18:04, Robert Nelson wrote:
> Hi Roger,
>
> On Wed, Feb 13, 2019 at 9:52 AM Roger Quadros <rog...@ti.com> wrote:
>>
>> Robert,
>>
>> On 28/01/19 21:15, Robert Nelson wrote:
>>> On Mon, Jan 28, 2019 at 12:58 PM Daniel Kulp <d...@kulp.com> wrote:
>>>>
>>>>
>>>> I tried to update our app image from the 4.14 bone kernel to the 4.19 bone kernel and ran into a big problem: uio_pruss is not configured in as it is with 4.14. Is this an oversight? Is there anyone I need to contact to try and convince them to re-enable uio_pruss? I'd like to get CONFIG_SND_DUMMY also enabled (module) as that would allow us to use some same configuration between Pi's and BBB's, but that's really minor. uio_pruss is a must-have.
>>>>
>>>> The ti kernels also don't have it, but I cannot use the ti kernels due to other timing reasons. Mostly concerned about the bone kernels right now.
>>>
>>> Actually, uio_pruss broke in v4.18.x... Congrats's your the first to
>>> notice and mention it! ;)
>>>
>>> Roger @ TI with comments from David posted an RFC for ti's remotproc
>>> for mainline.. That's what i have in v4.19.x-bone "today" (and
>>> v4.20.x-bone/v5.0.x-bone)..
>>

Sorry, I'm still a bit lost here ;).
How do I see the PRUSS kernel patches that you have picked up?

>> All upstream PRUSS series that I posted will not work without changes in
>> the resource tables in pru-software-support packages.
>>
>> e.g.
>> https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f
>>
>> If you can wait for 2 weeks then we could have something in
>> TI 2019 that should work smoothly.
>
> So around the time that your first RFC came out, we actually added
> that repo by default under /opt/source/ so users could test out your
> patchset on the beagle default images:
>
> https://github.com/RobertCNelson/omap-image-builder/commit/edd84bc5c2d925d67d00d0c2008f48cdd75e3e99
>
> So any Stretch/Buster/Bionic image after Nov 24 2018, has your repo
> installed by default in the root file system. ;)

OK. But I haven't fixed all examples as I wasn't sure if the changes that
I'm making will be accepted or not.

Suman has insisted that he wants to continue using the old resource table format
for TI's 2019 release.

What do you think is the best approach to take?

I would suggest.
-Get PRUSS kernel drivers via ti-linux-4.19.y
-Switch pru-software-package to use git://git.ti.com/pru-software-support-package/pru-software-support-package.git

Do you see any issues with this?

cheers,
-roger

[Robert Nelson]

> Sorry, I'm still a bit lost here ;).
> How do I see the PRUSS kernel patches that you have picked up?

Okay for v4.19.x & v4.20.x, i've picked up RFC 1: (I need to backport
the am33xx-l4 dts changes to then backport RFC2..)

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.20/patch.sh#L382-L392

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss

from : https://lkml.org/lkml/2018/11/22/948

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/remoteproc

from : https://lkml.org/lkml/2018/11/26/319

and we needed: https://lkml.org/lkml/2018/12/2/361

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss-from-v4.14.x-ti

For 5.0.x/5.1.x: I've picked up RFC 2 directly from your git tree:

https://github.com/rogerq/linux/commits/for-v5.1/pruss-2.0

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.0/patches/drivers/ti/rogerq_pruss

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v5.0/patch.sh#L352-L379

>
> >> All upstream PRUSS series that I posted will not work without changes in
> >> the resource tables in pru-software-support packages.
> >>
> >> e.g.
> >> https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f
> >>
> >> If you can wait for 2 weeks then we could have something in
> >> TI 2019 that should work smoothly.
> >
> > So around the time that your first RFC came out, we actually added
> > that repo by default under /opt/source/ so users could test out your
> > patchset on the beagle default images:
> >
> > https://github.com/RobertCNelson/omap-image-builder/commit/edd84bc5c2d925d67d00d0c2008f48cdd75e3e99
> >
> > So any Stretch/Buster/Bionic image after Nov 24 2018, has your repo
> > installed by default in the root file system. ;)
>
> OK. But I haven't fixed all examples as I wasn't sure if the changes that
> I'm making will be accepted or not.

I assumed that repo would be a work in progress, it was more to make
it easy for pru users to give it a quick test and give some feedback

> Suman has insisted that he wants to continue using the old resource table format
> for TI's 2019 release.
>
> What do you think is the best approach to take?

I think what TI has been doing with pru-remoteproc just isn't
working... To give you some perspective on what users of this forum
have dealt with: TI's "changed" the pru-remoteproc interface/etc for
end users in every TI kernel: From v3.14.x-ti, v4.1.x-ti, v4.4.x-ti,
v4.9.x-ti, to v4.14.x-ti.. It's really Painful..

Whereas the uio interface is compatible all the way back to our
ancient 3.8.x based kernel.. and yes the uio driver isn't perfect,
secure, etc..

So yeah, we will make what every you guys do in v4.19.x-ti as the
default for our "v4.19.x-ti" kernel, but just note, there is a big
user base, that won't care and will just use the uio interface in real
designs and products. Unless "SOMETHING" goes mainline, then the user
base doesn't have to worry about it changing on every release.

> I would suggest.
> -Get PRUSS kernel drivers via ti-linux-4.19.y

That's the default plan..

> -Switch pru-software-package to use git://git.ti.com/pru-software-support-package/pru-software-support-package.git

That also the default ;) It's actually packaged into a deb package..
using git of: df5794ce7611f8587950f491ef9bf11807e1d0cf

https://github.com/rcn-ee/repos/blob/master/ti-pru-software-support-package/version.sh

[Matthijs van Duin]

On Wed, 13 Feb 2019 at 13:42, Roger Quadros <rog...@ti.com> wrote:
> On 13/02/19 13:57, Matthijs van Duin wrote:
> > +#ifdef CONFIG_ARCH_DAVINCI_DA850
> > if (pdata->sram_pool) {
> > gdev->sram_pool = pdata->sram_pool;
>

> What is this sram pool? Is it about MSMC/OCMC RAM?

No idea, the sram pool is part of the uio-pruss driver for
freon/primus (OMAP-L1xx / AM1xxx / TMS320C674x / DA8xx) SoCs which is
in mainline, but it was never extended to the AM335x (or DT-based
configuration in general).

> Why is this only for DA850?

I simply copied that #ifdef from the previous patchset that existed.
Looking at mach-davinci/Kconfig, I guess it should probably be DA8XX
instead. Since this patchset has so far only been used for kernels
that aren't used on freon/primus anyway, it hasn't really mattered.

> > 0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also needed for remoteproc-pru)
>
> This part will eventually be not needed as we are moving away from hwmods.

Yeah I know hwmods are going away in the long run, but this patchset
was specifically to get things working on 4.19.

> > 0003: add support for ti,deassert-hard-reset (needed for uio-pruss on am335x)
>
> This should also be managed by ti-sysc bus driver but using some form of
> reset control driver that can toggle the necessary PRM registers RESET bit.
> There were some challenges as to how to keep the clockdomain out of auto-idle
> before reset can be issued.

Presumably whatever solution works for remoteproc-pru should also work
for uio-pruss.

> The only issue I see here is these 2 properties
>
> compatible = "ti,pruss-v2";
> ti,pintc-offset = <0x20000>;
>
> It will be nice if we can retain the compatibles that I'm using here https://lkml.org/lkml/2019/2/4/679

I'm confused. Those are for remoteproc-pru, not uio-pruss. They expose
different APIs to userspace, and in practice people use the
compatible-string to select the driver.

> We use a different compatible for every SoC as there are differences e.g. different RAM sizes, number of interrupts, INTC offset, etc.

Although in principle the host interrupts available could be detected
based on what's declared in DT, it actually seems to be the same
across all PRUSS instances I've seen (namely 8: host2..host9). The
only other thing that uio-pruss cares about is the INTC offset, which
seems to be 0x4000 for the old PRUSS on freon/primus and 0x20000 for
every instance of PRU-ICSS (including PRU-ICSSG), so the two
compatible-strings that the uio-pruss driver uses seem to be
sufficient for determining that. The uio-pruss driver does not care at
all about any other differences such as RAM sizes.

> > Obviously we could also change the uio-pruss driver to avoid this need for this property entirely. It ought to be implicit from the compatible-string.
>
> Exactly.

When I find a moment I'll see if I can fix that.

Matthijs

[Suman Anna]

Yeah, best to deal with this as a match data property. We can obviously
supply this using pdata-quirks as well, but definitely want to avoid
that short-term path.

Just FYI, I will be preparing my TI 4.19 baseline to support all the
SoCs within the next two weeks, and this will still follow the current
4.14 binding style, but I am going to move some of the files out of
remoteproc folder like Roger's series (as per the remoteproc
maintainer's wishes).

Roger's current upstream series is not yet ready to scale for all the
SoCs, and we are also lacking a whole bunch of ti-sysc support for
AM335x/AM437x on vanilla 4.19 kernel.

regards
Suman

[Robert Nelson]

Hi Daniel,

Can you please test:

sudo apt update
sudo apt install --only-upgrade bb-cape-overlays
sudo /opt/scripts/tools/update_kernel.sh

then in /boot/uEnv.txt and set:

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-4-19-00A0.dtbo

debian@beaglebone:~$ uname -r
4.19.15-ti-r9

[Daniel Kulp]

My app seems to work fine with 4.19.15-ti-r9 and the ORIGINAL PRU-UIO overlay, but crashes hard on startup with the new PRU-UIO.

Not sure if that helps much.   Definitely a step in the right direction.   The app runs and my LED panels light up and everything with just the kernel update. 

Dan

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/poKd5tCRD04/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhDNONwBWekk3FqEWw4814jFD8bopyTC6sS9kHT1oPxMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Fri, Feb 15, 2019 at 1:47 PM Daniel Kulp <d...@kulp.com> wrote:
>
>
> My app seems to work fine with 4.19.15-ti-r9 and the ORIGINAL PRU-UIO overlay, but crashes hard on startup with the new PRU-UIO.
>
> Not sure if that helps much. Definitely a step in the right direction. The app runs and my LED panels light up and everything with just the kernel update.
>

Thanks for testing! I'll remove that notes on the newer uio overlay.

[Daniel Kulp]

On Feb 15, 2019, at 2:49 PM, Robert Nelson <robert...@gmail.com> wrote:

On Fri, Feb 15, 2019 at 1:47 PM Daniel Kulp <d...@kulp.com> wrote:

My app seems to work fine with 4.19.15-ti-r9 and the ORIGINAL PRU-UIO overlay, but crashes hard on startup with the new PRU-UIO.

Not sure if that helps much.   Definitely a step in the right direction.   The app runs and my LED panels light up and everything with just the kernel update.

Thanks for testing! I'll remove that notes on the newer uio overlay.

Next question:  I kind of had a hard time trying to follow this entire discussion.   I know you really just deal with the “ti” kernel, but my app has never run very well on the ti kernel but works perfectly with the “bone” kernel.  Do you happen to know if the changes you incorporated into this new ti kernel will also be put into the bone kernel?   

[Robert Nelson]

> Next question: I kind of had a hard time trying to follow this entire discussion. I know you really just deal with the “ti” kernel, but my app has never run very well on the ti kernel but works perfectly with the “bone” kernel. Do you happen to know if the changes you incorporated into this new ti kernel will also be put into the bone kernel?

now that's tested i can merge it back to the bone kernel..

[Roger Quadros]

On 13/02/2019 19:13, Robert Nelson wrote:
>> Sorry, I'm still a bit lost here ;).
>> How do I see the PRUSS kernel patches that you have picked up?
>
> Okay for v4.19.x & v4.20.x, i've picked up RFC 1: (I need to backport
> the am33xx-l4 dts changes to then backport RFC2..)
>
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.20/patch.sh#L382-L392
>
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss
>
> from : https://lkml.org/lkml/2018/11/22/948
>
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/remoteproc
>
> from : https://lkml.org/lkml/2018/11/26/319
>
> and we needed: https://lkml.org/lkml/2018/12/2/361
>
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss-from-v4.14.x-ti
>
> For 5.0.x/5.1.x: I've picked up RFC 2 directly from your git tree:
>
> https://github.com/rogerq/linux/commits/for-v5.1/pruss-2.0
>
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.0/patches/drivers/ti/rogerq_pruss
>
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v5.0/patch.sh#L352-L379
>

Thanks.

Yes, having PRUSS support in mainline is very important for us.

>
>> I would suggest.
>> -Get PRUSS kernel drivers via ti-linux-4.19.y
>
> That's the default plan..
>
>> -Switch pru-software-package to use git://git.ti.com/pru-software-support-package/pru-software-support-package.git
>
> That also the default ;) It's actually packaged into a deb package..
> using git of: df5794ce7611f8587950f491ef9bf11807e1d0cf
>
> https://github.com/rcn-ee/repos/blob/master/ti-pru-software-support-package/version.sh
>
> Regards,
>

--

cheers,
-roger