4.19 bone kernel with uio_pruss?

GoogleGroups
21

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)

22

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:
ti-linux-kernel-dev/patches/drivers/ti/uio_pruss at ti-linux-4.19.y-uio-pruss · mvduin/ti-linux-kernel-dev · GitHub

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

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 LKML: Roger Quadros: [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings
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)

    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.

cheers,
-roger

23

Robert,

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! :wink:

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.

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

cheers,
-roger

24

Hi Roger,

Robert,

>>
>>
>> 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! :wink:
>
> 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.
examples:lab_5:am572x: Update Interrupt map resource · rogerq/pru-software-support-package@6346adb · GitHub

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:

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

Regards,

25

Robert,

Hi Roger,

Robert,

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! :wink:

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.
examples:lab_5:am572x: Update Interrupt map resource · rogerq/pru-software-support-package@6346adb · GitHub

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:

bb.org: stretch/buster/bionic: add repo: https://github.com/rogerq/pr… · RobertCNelson/omap-image-builder@edd84bc · GitHub

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

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

26

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/tree/am33x-v4.20/patches/drivers/ti/pruss

27

> +#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 LKML: Roger Quadros: [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings

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

28

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

29

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

Regards,

30

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

31

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

Regards,

32

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?

33

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

Regards,

34

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

bb-kernel/patch.sh at am33x-v4.20 · RobertCNelson/bb-kernel · GitHub

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

from : LKML: Roger Quadros: [PATCH 00/17] Add support for TI PRU ICSS

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

from : LKML: Roger Quadros: [PATCH 00/16] remoteproc: Add support for TI PRU

and we needed: LKML: "Derald D. Woods": Re: [PATCH 00/17] Add support for TI PRU ICSS

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

bb-kernel/patches/drivers/ti/rogerq_pruss at am33x-v5.0 · RobertCNelson/bb-kernel · GitHub

bb-kernel/patch.sh at am33x-v5.0 · RobertCNelson/bb-kernel · GitHub

Thanks.

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

e.g.
examples:lab_5:am572x: Update Interrupt map resource · rogerq/pru-software-support-package@6346adb · GitHub

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:

bb.org: stretch/buster/bionic: add repo: https://github.com/rogerq/pr… · RobertCNelson/omap-image-builder@edd84bc · GitHub

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

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.

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