Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

This makes a whole lot more sense now, because I swear I had it working on
those GPIO ports at one point. I think I had exported pins manually while
testing things. Thanks for the help!

On Wed, Apr 29, 2020 at 2:59 PM John Allwine  wrote:

> That did it! I exported pin 8.43:
>
> echo 226 > /sys/class/gpio/export
>
> And now the PRUs can write to the set and clear addresses for GPIO8.
>
> I also exported 8.26:
>
> echo 124 > /sys/class/gpio/export
>
> And now the PRUs can write to the set and clear addresses for GPIO4.
>
> On Wed, Apr 29, 2020 at 11:42 AM Jason Kridner 
> wrote:
>
>>
>>
>> On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
>> char...@steinkuehler.net> wrote:
>>
>>> Regarding your bus errors, I don't see anything in the TRM that
>>> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>>>
>>> I have, however, seen bus errors on uninitialized GPIO banks which come
>>> up disabled by default.  Check to make sure at least one GPIO pin is
>>> exported by the Linux Kernel (either manually or via device tree) and
>>> see if the bus errors go away.
>>>
>>
>> I'll double-down on that feedback. I forwarded this to the team at TI and
>> they said it is likely that the GPIO bank doesn't have its clock enabled. I
>> inquired what the minimal action to enable the clock would be, but haven't
>> heard back yet. Enabling one of the GPIOs in the bank in Linux seems like a
>> sure way to do it.
>>
>> I'll get back when I can find anything more minimal than that.
>>
>>
>>>
>>>
>>> On 4/28/2020 4:45 PM, John Allwine wrote:
>>> > Using that test, I was able to quickly check to see which GPIO ports I
>>> was
>>> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't
>>> have
>>> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7
>>> that
>>> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
>>> GPIO 4
>>> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
>>> > document how each pin can be used, but it seems like just about all
>>> the P8
>>> > and P9 pins can be used as long as you know which PRU to run it on for
>>> > direct outputs and which are suitable to be used as GPIO outputs.
>>> >
>>> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
>>> > wrote:
>>> >
>>> >> Ok, I have a more localized test that triggers the exception:
>>> >>
>>> >>
>>> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
>>> >>
>>> >> Two stack traces can be seen in dmesg after running that on the PRU.
>>> If it
>>> >> has something to do with the device tree, this is the overlay I'm
>>> using:
>>> >>
>>> >>
>>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>>> >>
>>> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine 
>>> wrote:
>>> >>
>>> >>> Are there any ramifications of the PRU writing 0 to both the set and
>>> >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the
>>> device tree
>>> >>> has several overlapping pins allocated to being direct outputs on
>>> the PRU?
>>> >>> The issue seems to arise when I write to those two addresses on the
>>> PRU, as
>>> >>> well as the set and clear addresses of GPIO4 (0x48059190 and
>>> 0x48059194).
>>> >>> What could cause that to trigger an exception in the kernel?
>>> >>>
>>> >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
>>> wrote:
>>> >>>
>>>  It seems that even if I hardcode the addresses in there (to
>>> eliminate
>>>  the possibility that my registers were getting overwritten
>>> somewhere), that
>>>  I get the bus error.  Does enabling the OCP Master port work the
>>> same way
>>>  as on the BBB? It's supposedly being set here:
>>> 
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
>>> 
>>>  On Tue, Apr 28, 2020 at 11:47 AM John Allwine 
>>> wrote:
>>> 
>>> > It's the hal_pru_generic code. It definitely smells like a bus
>>> error.
>>> > In fact, if I comment out the lines that write to the GPIO, it
>>> stops
>>> > happening, so it seems like I have the wrong addresses in there,
>>> but I'm
>>> > struggling figuring out how that could be.
>>> >
>>> > These lines are where the GPIO ports are written to in memory:
>>> >
>>> >
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
>>> >
>>> > Theoretically, the addresses should be set to the clear addresses
>>> of
>>> > GPIO3, GPIO5, GPIO6 and GPIO7:
>>> >
>>> > Addresses defined here:
>>> >
>>> >
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
>>> >
>>> > Loaded into registers here:
>>> >
>>> >
>>> 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

That did it! I exported pin 8.43:

echo 226 > /sys/class/gpio/export

And now the PRUs can write to the set and clear addresses for GPIO8.

I also exported 8.26:

echo 124 > /sys/class/gpio/export

And now the PRUs can write to the set and clear addresses for GPIO4.

On Wed, Apr 29, 2020 at 11:42 AM Jason Kridner 
wrote:

>
>
> On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> Regarding your bus errors, I don't see anything in the TRM that
>> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>>
>> I have, however, seen bus errors on uninitialized GPIO banks which come
>> up disabled by default.  Check to make sure at least one GPIO pin is
>> exported by the Linux Kernel (either manually or via device tree) and
>> see if the bus errors go away.
>>
>
> I'll double-down on that feedback. I forwarded this to the team at TI and
> they said it is likely that the GPIO bank doesn't have its clock enabled. I
> inquired what the minimal action to enable the clock would be, but haven't
> heard back yet. Enabling one of the GPIOs in the bank in Linux seems like a
> sure way to do it.
>
> I'll get back when I can find anything more minimal than that.
>
>
>>
>>
>> On 4/28/2020 4:45 PM, John Allwine wrote:
>> > Using that test, I was able to quickly check to see which GPIO ports I
>> was
>> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't
>> have
>> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7
>> that
>> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
>> GPIO 4
>> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
>> > document how each pin can be used, but it seems like just about all the
>> P8
>> > and P9 pins can be used as long as you know which PRU to run it on for
>> > direct outputs and which are suitable to be used as GPIO outputs.
>> >
>> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
>> > wrote:
>> >
>> >> Ok, I have a more localized test that triggers the exception:
>> >>
>> >>
>> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
>> >>
>> >> Two stack traces can be seen in dmesg after running that on the PRU.
>> If it
>> >> has something to do with the device tree, this is the overlay I'm
>> using:
>> >>
>> >>
>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>> >>
>> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine 
>> wrote:
>> >>
>> >>> Are there any ramifications of the PRU writing 0 to both the set and
>> >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device
>> tree
>> >>> has several overlapping pins allocated to being direct outputs on the
>> PRU?
>> >>> The issue seems to arise when I write to those two addresses on the
>> PRU, as
>> >>> well as the set and clear addresses of GPIO4 (0x48059190 and
>> 0x48059194).
>> >>> What could cause that to trigger an exception in the kernel?
>> >>>
>> >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
>> wrote:
>> >>>
>>  It seems that even if I hardcode the addresses in there (to eliminate
>>  the possibility that my registers were getting overwritten
>> somewhere), that
>>  I get the bus error.  Does enabling the OCP Master port work the
>> same way
>>  as on the BBB? It's supposedly being set here:
>> 
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
>> 
>>  On Tue, Apr 28, 2020 at 11:47 AM John Allwine 
>> wrote:
>> 
>> > It's the hal_pru_generic code. It definitely smells like a bus
>> error.
>> > In fact, if I comment out the lines that write to the GPIO, it stops
>> > happening, so it seems like I have the wrong addresses in there,
>> but I'm
>> > struggling figuring out how that could be.
>> >
>> > These lines are where the GPIO ports are written to in memory:
>> >
>> >
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
>> >
>> > Theoretically, the addresses should be set to the clear addresses of
>> > GPIO3, GPIO5, GPIO6 and GPIO7:
>> >
>> > Addresses defined here:
>> >
>> >
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
>> >
>> > Loaded into registers here:
>> >
>> >
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
>> > jkrid...@beagleboard.org> wrote:
>> >
>> >> What is the code running on PRUSS2 PRU1?
>> >>
>> >> This line 

[beagleboard] Reg: LCD LIDD DMA: Not working: Interrupt not happening

[anu]

Dear All,

I am having problem writing to a character 16 x 2  LCD with DMA enabled. 
Please note that, the same character LCD works fine when DMA is not enabled.

I followed the sequence of:-

1. Enabling clocks in for LCD_CLKC_ENABLE for the clocks of DMA, LIDD & 
Core clock. I write and read back the value of 0x07.

2. I initialize the LCD using the LIDD_CS0_DATA & LIDD_CS0_ADDR. I see the 
cursor blinking and I also see a number "4" bein displayed when I write 
0x34 to LIDD_CS0_DATA.
So this proves the LCD module is working and the LCD is initialized 
perfectly and character is also displayed on the LCD. So the LCD is also 
working.

3. Next  data is written into the virtual memory location allocated by a 
kernel module from the user space program. The physical memory address of 
the virtual memory allocated in the kernel module,
is read by into the user space process and the same physical memory base 
address is used in step 6. The ceiling address of the physical memory is 
calculated from the base based on number of words written.

4. In the LIDD_CTRL, the DMA enable bit, "lidd_dma_en" was always set to 0, 
right from start of the program. This is to disable the DMA right from 
start. 
As for the "dma_cs0_cs1" bit is set to 0, so that the DMA uses LIDD CS0 
(Frame Buffer0).

5. The LCDDMA_CTRL is set to 0x00.

6. The LCDDMA_FB0_BASE is written with the Physical memory address. 

7. The LCDDMA_FB0_CEILING is written with the Physical memory address. 

8. Next the Interrupt is enabled by setting the bit, "done_en_set" of the 
IRQENABLE_SET.

9. Next In the LIDD_CTRL, the DMA enable bit, "lidd_dma_en" is set to 1 to 
enable the DMA.

10. There is continuous while loop polling of the IRQSTATUS register for 
the done bit to become set. 

*But in the program the **"done_en_set" of the IRQENABLE_SET never gets 
set. I don't know why?.*

To verify, if data is getting written in the memory allocated by the kernel 
module, I read back the data from the memory location and it reads 
correctly.

So I am not sure if this is problem with DMA of the LIDD LCD module or is 
there some sequence missing. 

So can someone help me is getting the LIDD DMA to work?.

Please help me to resolve this issue.

Thanks & Regards
Anu

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b8a9dc13-3f00-4419-a0d2-da390a7829e2%40googlegroups.com.

Re: [beagleboard] PRU locking up Beaglebone AI

[Jason Kridner]

On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> Regarding your bus errors, I don't see anything in the TRM that
> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>
> I have, however, seen bus errors on uninitialized GPIO banks which come
> up disabled by default.  Check to make sure at least one GPIO pin is
> exported by the Linux Kernel (either manually or via device tree) and
> see if the bus errors go away.
>

I'll double-down on that feedback. I forwarded this to the team at TI and
they said it is likely that the GPIO bank doesn't have its clock enabled. I
inquired what the minimal action to enable the clock would be, but haven't
heard back yet. Enabling one of the GPIOs in the bank in Linux seems like a
sure way to do it.

I'll get back when I can find anything more minimal than that.


>
>
> On 4/28/2020 4:45 PM, John Allwine wrote:
> > Using that test, I was able to quickly check to see which GPIO ports I
> was
> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't
> have
> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7
> that
> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
> GPIO 4
> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
> > document how each pin can be used, but it seems like just about all the
> P8
> > and P9 pins can be used as long as you know which PRU to run it on for
> > direct outputs and which are suitable to be used as GPIO outputs.
> >
> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
> > wrote:
> >
> >> Ok, I have a more localized test that triggers the exception:
> >>
> >>
> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
> >>
> >> Two stack traces can be seen in dmesg after running that on the PRU. If
> it
> >> has something to do with the device tree, this is the overlay I'm using:
> >>
> >>
> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
> >>
> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine  wrote:
> >>
> >>> Are there any ramifications of the PRU writing 0 to both the set and
> >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device
> tree
> >>> has several overlapping pins allocated to being direct outputs on the
> PRU?
> >>> The issue seems to arise when I write to those two addresses on the
> PRU, as
> >>> well as the set and clear addresses of GPIO4 (0x48059190 and
> 0x48059194).
> >>> What could cause that to trigger an exception in the kernel?
> >>>
> >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
> wrote:
> >>>
>  It seems that even if I hardcode the addresses in there (to eliminate
>  the possibility that my registers were getting overwritten
> somewhere), that
>  I get the bus error.  Does enabling the OCP Master port work the same
> way
>  as on the BBB? It's supposedly being set here:
> 
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
> 
>  On Tue, Apr 28, 2020 at 11:47 AM John Allwine 
> wrote:
> 
> > It's the hal_pru_generic code. It definitely smells like a bus error.
> > In fact, if I comment out the lines that write to the GPIO, it stops
> > happening, so it seems like I have the wrong addresses in there, but
> I'm
> > struggling figuring out how that could be.
> >
> > These lines are where the GPIO ports are written to in memory:
> >
> >
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
> >
> > Theoretically, the addresses should be set to the clear addresses of
> > GPIO3, GPIO5, GPIO6 and GPIO7:
> >
> > Addresses defined here:
> >
> >
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
> >
> > Loaded into registers here:
> >
> >
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
> > jkrid...@beagleboard.org> wrote:
> >
> >> What is the code running on PRUSS2 PRU1?
> >>
> >> This line kinda spells out an illegal access by that PRU or of that
> >> PRU:
> >> MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in
> Supervisor
> >> mode during Functional access
> >>
> >> Looks like the error is from here:
> >>
> https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135
> >>
> >> Looks like a bus exception to me.
> >>
> >> On Tue, Apr 28, 2020 at 

Re: [beagleboard] Re: Network setup taken over by something

[jonnymo]

Although a bit off track from the original subject, you may what to look at
some sort of lint tool to check you code for syntax errors.  If you use an
editor such as Eclipse or Atom, this may do this for you already.
https://en.wikipedia.org/wiki/Lint_(software)

You could also look at the warning and error level settings and options to
increase the level of complaints when the code is compiled.

Jon

On Wed, Apr 29, 2020 at 9:28 AM maxmike  wrote:

>
> Without  much longer belabouring the point, in my case gcc did not check
>> my .h file; instead of checking it
>
> for syntax (a semicolon missing in a function definition) it accepted it
> and  reported what the effect was of trusting it - totally incomprehensible
> errors.
>
> However, I have learned from this that before I compile the .c files I
> will compile the .h's separately first - that would have prevented the
> issue.
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/b27b924a-9ca3-44cf-bceb-a355d002da2f%40googlegroups.com
> 
> .
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAG99bkqBbS6drEkBK8FnvGXzfR8Zj6igu%3DVx47Z2HAN49t6EYQ%40mail.gmail.com.

Re: [beagleboard] PRU locking up Beaglebone AI

[Charles Steinkuehler]

Regarding your bus errors, I don't see anything in the TRM that 
indicates the PRU shouldn't be able to talk to all of the GPIO banks.


I have, however, seen bus errors on uninitialized GPIO banks which come 
up disabled by default.  Check to make sure at least one GPIO pin is 
exported by the Linux Kernel (either manually or via device tree) and 
see if the bus errors go away.



On 4/28/2020 4:45 PM, John Allwine wrote:

Using that test, I was able to quickly check to see which GPIO ports I was
able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't have
any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7 that
I can use for hal_pru_generic. The P8 and P9 pins that are mapped to GPIO 4
and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
document how each pin can be used, but it seems like just about all the P8
and P9 pins can be used as long as you know which PRU to run it on for
direct outputs and which are suitable to be used as GPIO outputs.

On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
wrote:


Ok, I have a more localized test that triggers the exception:

https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c

Two stack traces can be seen in dmesg after running that on the PRU. If it
has something to do with the device tree, this is the overlay I'm using:

https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts

On Tue, Apr 28, 2020 at 1:20 PM John Allwine  wrote:


Are there any ramifications of the PRU writing 0 to both the set and
clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device tree
has several overlapping pins allocated to being direct outputs on the PRU?
The issue seems to arise when I write to those two addresses on the PRU, as
well as the set and clear addresses of GPIO4 (0x48059190 and 0x48059194).
What could cause that to trigger an exception in the kernel?

On Tue, Apr 28, 2020 at 12:19 PM John Allwine  wrote:


It seems that even if I hardcode the addresses in there (to eliminate
the possibility that my registers were getting overwritten somewhere), that
I get the bus error.  Does enabling the OCP Master port work the same way
as on the BBB? It's supposedly being set here:
https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176

On Tue, Apr 28, 2020 at 11:47 AM John Allwine  wrote:


It's the hal_pru_generic code. It definitely smells like a bus error.
In fact, if I comment out the lines that write to the GPIO, it stops
happening, so it seems like I have the wrong addresses in there, but I'm
struggling figuring out how that could be.

These lines are where the GPIO ports are written to in memory:

https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217

Theoretically, the addresses should be set to the clear addresses of
GPIO3, GPIO5, GPIO6 and GPIO7:

Addresses defined here:

https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307

Loaded into registers here:

https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264







On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
jkrid...@beagleboard.org> wrote:


What is the code running on PRUSS2 PRU1?

This line kinda spells out an illegal access by that PRU or of that
PRU:
MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor
mode during Functional access

Looks like the error is from here:
https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135

Looks like a bus exception to me.

On Tue, Apr 28, 2020 at 11:46 AM  wrote:


I'm getting this stack trace in dmesg, but I'm unsure what it means
or how to figure out what it means. As far as I can tell, the code running
on the PRU is working. I'm generating a 100Khz signal on a direct output,
and am able to successfully measure this signal. The Beaglebone is locking
up, though, and I believe this stack trace is being spammed so heavily that
the logging is taking over the CPU and my ssh shell gets locked out.

I'm using this device tree overlay:
https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts

The code I'm running is implemented in PRU Assembly that is assembled
with pasm. pasm outputs a .bin file and I need a .elf file for running it
with remoteproc, so I'm jumping through some hoops to do that conversion.
The elf file does seem to work, but I'm not sure if I need to do more to
ensure I'm specifying what resources I need access to or something like
that. I can go into more detail if need be.

The stack trace is below. Any ideas about 

[beagleboard] Re: Network setup taken over by something

[maxmike]

> Without  much longer belabouring the point, in my case gcc did not check 
> my .h file; instead of checking it

for syntax (a semicolon missing in a function definition) it accepted it 
and  reported what the effect was of trusting it - totally incomprehensible 
errors.

However, I have learned from this that before I compile the .c files I will 
compile the .h's separately first - that would have prevented the issue.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b27b924a-9ca3-44cf-bceb-a355d002da2f%40googlegroups.com.

[beagleboard] Re: Converting GPIO pins to MMC mode (BeagleBone Black)

[TJF]

Am Dienstag, 28. April 2020 23:56:34 UTC+2 schrieb 
geral...@motorolasolutions.com:
>
> I was able to toggle those 2 lines as GPIO and validate their manipulation 
> using a logic analyzer.
>
> When done, I went back to the other program to communicate with the micro 
> SD card in the slot and it worked just as if those pins had never been 
> changed!  I was like Wow!  Very impressive!
>

Fine! Note: the pinmuxing is only active in the time after the 
pruio_config() call and before the DTOR call to pruio_destroy(). The DTOR 
restores the original setting (by default). (A cosmetic note: I prefer 
calling pruio_pgio_setValue() before pruio_config() -> all start values get 
set simultaneously.)
 

> So when I do a show-pins -v
>
> μSD d360 fast rx  up  0 mmc 0 d3
>  mmc@4806 (pinmux_mmc1_pins)
> μSD d261 fast rx  up  0 mmc 0 d2
>  mmc@4806 (pinmux_mmc1_pins)
> μSD d162 fast rx  up  0 mmc 0 d1
>  mmc@4806 (pinmux_mmc1_pins)
> μSD d063 fast rx  up  0 mmc 0 d0
>  mmc@4806 (pinmux_mmc1_pins)
> μSD clk   64 fast rx  up  0 mmc 0 clk
> mmc@4806 (pinmux_mmc1_pins)
> μSD cmd 65 fast rx  up  0 mmc 0 cmd
> mmc@4806 (pinmux_mmc1_pins)
>
> this will always show uSD d0 and uSD d1 as mmc under pinmux_mmc1_pins even 
> when they are switched to GPIO mode briefly under libpruio control?  Just 
> asking out of curiosity?
>

I don't know the show_pins tool. What happens when you execute it in a 
second shell while your libpruio prog is running? Perhaps it lists the 
kernel setting, but ignores the hardware state. 

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/948e664e-38fd-4aeb-bfd1-3d7bb8f07508%40googlegroups.com.

[beagleboard] Errors after switch-off USB power (battery powerred)

[bernid111]

I've build  RT kernel 4.19 for my bbb and Debian buster. 
Linux beaglebone 4.19.94+ #1 SMP PREEMPT RT Sun Apr 26 11:04:37 CEST 2020 
armv7l GNU/Linux

I use wifi USB stick with kernel module mt760u and it works great.
After switching of USB power I'm flooded with messages:

[   75.890362] mt7601u 1-1:1.0: Vendor request req:07 off:1700 failed:-110
[   79.122377] mt7601u 1-1:1.0: Vendor request req:07 off:1704 failed:-110
[   82.354362] mt7601u 1-1:1.0: Vendor request req:07 off:1708 failed:-110
[   85.586380] mt7601u 1-1:1.0: Vendor request req:07 off:101c failed:-110
[   88.818362] mt7601u 1-1:1.0: Vendor request req:07 off:170c failed:-110
[   92.050380] mt7601u 1-1:1.0: Vendor request req:07 off:101c failed:-110
[   95.282362] mt7601u 1-1:1.0: Vendor request req:07 off:1710 failed:-110


I cannot even switched off my bbb using onboard power button. Why there is 
no normal transition from USB to battery power?
How could I fixed this for my board?
Thanks, 

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/214c4dbb-34a5-4458-9d54-6436271d98b4%40googlegroups.com.

[beagleboard] pppd & n_gsm problem

[pavel havlik]

Hello

i'd like to ask to questions related to serial communication.

1. Is there any reason why DMA is disabled by default in beagle bone black 
serial_omap driver (CONFIG_SERIAL_8250_DMA=n) ?
Is it safe to recompile it with CONFIG_SERIAL_8250_DMA=y?

2. I encountered board freeze (most probably deadlock but I'm not sure) 
when using pppd and n_gsm to communicate with GSM modem over serial line.
When I connected to the board from internet and issued some command 
wich output a lot of data, board got stuck but when output little data
board behaved correctly. After digging into n_gsm driver I discovered 
that board gets stuck when 8250 driver calls gsmld_write_wakeu() indicating 
upper layer (n_gsm)
that is has room again for new data. n_gsm in return sends more data to 
8250 driver directly in the gsmld_write_wakeup() , which is called from 
interrupt. I thought this could be the source of the deadlog but I didn't 
discover anything wrong. However the problem got treated when I instead of 
directly sending data in  gsmld_write_wakeup()  scheduled tasklet and only 
inside it I sent the data.

Any hint what could be wrong with the original code? The behaviour was the 
same both in 4.19.94-ti-r37 and 4.14.49-ti-r54.
Tank you for any help
regards
Pavel



Instead of

static void gsmld_write_wakeup(struct tty_struct *tty)
{
struct gsm_mux *gsm = tty->disc_data;
unsigned long flags;

/* Queue poll */
clear_bit(TTY_DO_WRITE_WAKEUP, >flags);
spin_lock_irqsave(>tx_lock, flags);
gsm_data_kick(gsm);
if (gsm->tx_bytes < TX_THRESH_LO) {
gsm_dlci_data_sweep(gsm);
}
spin_unlock_irqrestore(>tx_lock, flags);
}




this

static void gsmld_write_wakeup(struct tty_struct *tty)
{
struct gsm_mux *gsm = tty->disc_data;
 
/* Queue poll */
clear_bit(TTY_DO_WRITE_WAKEUP, >flags);
tasklet_schedule(>wkup_tasklet);
}

static void wkup_tasklet_handler(unsigned long data)
{
struct gsm_mux *gsm = (struct gsm_mux *)data;
unsigned long flags;

spin_lock_irqsave(>tx_lock, flags);
gsm_data_kick(gsm);
if (gsm->tx_bytes < TX_THRESH_LO) {
gsm_dlci_data_sweep(gsm);
}
spin_unlock_irqrestore(>tx_lock, flags);
}

this is call stack trace from omap driver up to n_gsm driver resulting in 
freez

[  361.652243] [] (gsmld_write_wakeup [n_gsm]) from [] 
(tty_wakeup+0x60/0x6c)
[  361.652255] [] (tty_wakeup) from [] 
(tty_port_default_wakeup+0x24/0x30)
[  361.652266] [] (tty_port_default_wakeup) from [] 
(tty_port_tty_wakeup+0x20/0x24)
[  361.652277] [] (tty_port_tty_wakeup) from [] 
(uart_write_wakeup+0x24/0x2c)
[  361.652288] [] (uart_write_wakeup) from [] 
(serial8250_tx_chars+0x104/0x208)
[  361.652300] [] (serial8250_tx_chars) from [] 
(serial8250_handle_irq.part.11+0xd8/0xdc)
[  361.652312] [] (serial8250_handle_irq.part.11) from 
[] (serial8250_handle_irq+0x28/0x2c)
[  361.652323] [] (serial8250_handle_irq) from [] 
(omap8250_irq+0x3c/0x54)
[  361.652336] [] (omap8250_irq) from [] 
(__handle_irq_event_percpu+0x84/0x2d0)
[  361.652349] [] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x3c/0x90)
[  361.652361] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x48/0x6c)
[  361.652373] [] (handle_irq_event) from [] 
(handle_level_irq+0xdc/0x158)
[  361.652384] [] (handle_level_irq) from [] 
(generic_handle_irq+0x34/0x44)
[  361.652396] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x8c/0xfc)
[  361.652408] [] (__handle_domain_irq) from [] 
(omap_intc_handle_irq+0x44/0x9c)
[  361.652419] [] (omap_intc_handle_irq) from [] 
(__irq_svc+0x6c/0xa8)

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/47e941c4-17de-4f19-941e-73eaa072c799%40googlegroups.com.

[beagleboard] Re: Network setup taken over by something

[Chris Green]

maxmike  wrote:
> [-- multipart/alternative, encoding 7bit, 58 lines --]
> 
> [-- text/plain, encoding 7bit, charset: UTF-8, 21 lines --]
> 
> 
> 
> Thank you Dennis.
> 
> I don't know if this is the right place to make a comment or express an 
> opinion, but be that as it may
> I have to say that gcc needs a far better error reporting mechanism. In 
> java if the "compiler" encounters an
> unterminated expression at end of file, it flags it immediately. In gcc 
> that error is held in abeyance for a huge
> number of lines (about 500 in my case, in multiple files) before it's 
> manifested as something that seems 
> completely unrelated and slightly insane.
> 
That's nothing to do with gcc really, it's just down to C syntax.  The
compiler *can't* know until a lot later that there is an error.

I was a software engineer at BT (and spin off comapnies) for many
years, I coded in C, C++ and Java.  All of them could throw very
confusing errors, many, many lines later than the original typo or
whatver that caused it.

That said, you shouldn't really have modules 500 lines long! :-)  This
sort of problem is yet another reason for keeping functions short and
source files to a reasonable size.

-- 
Chris Green
·

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/r3onng-a8s.ln1%40esprimo.zbmc.eu.