[beagleboard] Unable to use CAN bus on BBBL with 4.14.65-ti-r72 kernel (August image)

[Pierce Nichols]

All,

I'm having some trouble getting CAN bus to work on a Beaglbone Blue
with an image from this August, with the 4.14.65-ti-r72 kernel. I
verified that my hardware is correct by swapping in an older image
(old enough to still use the capemgr!) based one the 4.9.45-ti-r57
kernel and verifying that works.

With the newer kernel, I don't get any inbound traffic through candump
and every time I call cansend the can0 interface goes down and I get
the following error message in my dmesg output:

[  778.698672] c_can_platform 481d.can can0: bus-off

The relevant lines in /boot/uEnv.txt are as follows:

###U-Boot Overlays###
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART5-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-CAN1-00A0.dtbo
###PRUSS OPTIONS
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###Cape Universal Enable
enable_uboot_cape_universal=1
###U-Boot Overlays###

Any suggestions for what might be preventing CAN from working with the
newer image?

-p

-- 
Pierce Nichols
Principal Engineer
Logos Electromechanical, LLC

-- 
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/CAENK0PzUePHEqMRm3hPTfsMHhw0sgdhX6u%2Bk8eY4ib_a2qxfxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to use "reserved-memory" in device tree to reserve DDR memory?

[Ken Shirriff]

I'm trying to do exactly the same thing as Gaurav and I found this thread.

First, I ran into the same problem as Gaurav that the beaglebone bricked on 
boot with FDT_ERR_BADOVERLAY. The problem was I put the "reserved-memory" 
section in my overlay dts, which the overlay system doesn't like.

I moved that to a fragment, and now it boots and there's a reserved-memory 
section in /sys/firmware, but looking at dmesg and  /proc, I don't think it 
actually reserved any memory. 

 fragment@6 {
target = <&ocp>;
__overlay__ {
  reserved-memory {
  #address-cells = <1>;
  #size-cells = <1>;
  ranges; 

  pruadc_reserved: pruadc_reserved@0x9ffc {
  reg = <0x9ffc 0x0004>;
  no-map; 
  status = "okay"; 
  };  
};
  };
};


So, my question is: how do I get this fragment to actually reserve a chunk 
of memory? I just guessed at the target "ocp", so that may be wrong.

(My underlying goal is to allocate a chunk of RAM to share between the ARM 
and the PRU; the built-in shared RAM is a bit too small. It seems that the 
TIDA01555  project does just what I 
(and presumably Gaurav) want, if I can get it to work.)

Ken

On Tuesday, October 9, 2018 at 6:55:28 PM UTC-7, RobertCNelson wrote:
>
> On Tue, Oct 9, 2018 at 5:58 PM GS > 
> wrote: 
> > 
> > Thanks for the suggestion, Robert. 
> > I have attached the complete output. The relevant section is pasted 
> here: 
> > 
> > uboot_overlays: loading /lib/firmware/MEM.dtbo ... 
> > 418 bytes read in 94 ms (3.9 KiB/s) 
> > failed on fdt_overlay_apply(): FDT_ERR_BADOVERLAY 
> > 
> > Not exactly sure what it means. 
>
> it means, error, bad overlay... 
>
> Which means it didn't do the overlay syntax.. 
>
> We have lots of examples here: 
>
> https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm 
>
> what's your actual overlay dts file look like? 
>
> You need: 
>
> /plugin/; 
>
> fragment@0 {'s 
>
> target = <&xyz>;  or target-path="/"; 
>
> and 
>
> __overlay__ { 
>
> finally built with "-@" 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.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/edc48e49-b0ef-4ee0-875e-da0d81f8f7f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU compiler Optimization Issue

[Bill Bitner]

Hi!

First, a *big* thanks to Mark Yoder, who kindly put a whole lot of 
information together to help me figure this out.

I'm attempting to using the BBB to make a simple motor controller and will 
use the PRU's to do the critical timing
events.To demonstrate a baby step, I decided to play around with an 
ultrasonic detector to prove I could generate
timed pulses, and also time an incoming pulse.   I started using Mark's 
PruCookbook set up.   I found that using
the -O 2 flag for clpru, the compiler would *delete* certain looping code.  
 Removing the flag would run the code
properly.   It took a while to figure out what was happening since I'm not 
an expert in assembly, but looking at
the .lst file and using prudebug and single stepping showed me what the 
problem was.

Details:

while (1)
{

runState = pru0Dram[0]; 
if (runState == 0)
{
__R30 &= ~gpio; // Set the GPIO pin to 0, this 
should be a 10 us pulse
continue;
}

onTime  = pru0Dram[1]; 

__R30 |= gpio;
 >>>   while(1)
{
if (counter > onTime)
{
__R30 &= ~gpio; // Set the GPIO pin to 0, this 
should be a 10 us pulse
break;
}
counter += 1;
}

inputState = 0;


without the -O 2 flag, the compiler generates the following assembly code.



259;--
 260;  54 | __R30 |= gpio;  
   

 261;--
 262 007c 00F1002281  LBBO  &r1, r2, 0, 4 ; 
[ALU_PRU] |54| gpio
 263 0080 0012E1FEFE  ORr30, r30, r1  ; 
[ALU_PRU] |54| 
 264.dwpsn  file "pruUltraSonic2.c",line 55,column 
19,is_stmt,isa 0

 265;--
 266;  55 | while(1)
   

 267;--
 268;* 
--*
 269;*   BEGIN LOOP ||$C$L3||
 270;*
 271;*   Loop source line: 55
 272;*   Loop closing brace source line  : 63
 273;*   Known Minimum Trip Count: 1
 274;*   Known Maximum Trip Count: 4294967295
 275;*   Known Max Trip Count Factor : 1
PRU Assembler Unix v2.3.1 Sat Dec  1 17:26:17 2018

Tools Copyright (c) 2012-2017 Texas Instruments Incorporated
/tmp/pru0-gen/pruUltraSonic2.asm PAGE  
  6

 276;* 
--*
 277 0084 ||$C$L3||:
 278.dwpsn  file "pruUltraSonic2.c",line 57,column 
17,is_stmt,isa 0

 279;--
 280;  57 | if (counter > onTime)  


 281;--
 282 0084 00F1142280  LBBO  &r0, r2, 20, 4; 
[ALU_PRU] |57| counter
 283 0088 0058E0EE04  QBLE  ||$C$L4||, r14, r0; 
[ALU_PRU] |57| 
 284;* 
--*
 285.dwpsn  file "pruUltraSonic2.c",line 59,column 
21,is_stmt,isa 0

 286;--
 287;  59 | __R30 &= ~gpio; // Set the GPIO pin to 0, this 
should be a 10 u
 288; | s pulse


 289;--
 290 008c 001600E1E0  NOT   r0, r1; 
[ALU_PRU] |59| 
 291 0090 0010E0FEFE  AND   r30, r30, r0  ; 
[ALU_PRU] |59| 
 292.dwpsn  file "pruUltraSonic2.c",line 60,column 
21,is_stmt,isa 0

 293;--
 294;  60 | break;  
   

 295;--
 296 0094 002100! JMP   ||$C$L5|| ; 
[ALU_PRU] |60| 
 297;* 
--*
 298 0098 ||$C$L4||:
 299.dwpsn  file "pruUltraSonic2.c",line 62,column 
17,is_stmt,isa 0

 300;--
 301;  62 | counter += 1; 

Re: [beagleboard] Re: Debian 9: autorun on boot with systemd does not work

[Harke Smits]

Hi Seth,

In the meantime I think I tried just about any combination I can think of.
Mostly I get the following error codes after demanding the status;
Loaded
Active: failed
Process: 1002 ... code = exited, status=203/EXEC
Main PID: 1002.

In short; no luck so far
I am doing something fundamentally wrong I think... Or it is just
impossible.
I am lost here..
Cheers,
Harke




On Fri, 30 Nov 2018 at 22:46, Mala Dies  wrote:

> Hello,
>
> When you type under [Service], use only the PATH. Try that idea first. I
> may be able to help out a bit.
>
> Seth
>
> P.S. For instance, say I have a Python file in this dir:
> /home/debian/LoveBone/. I would simply put, under the [Service] tag,
> ExecStart=/home/debain/LoveBone/MultipleIdeas.py for my PATH. Try that idea
> and think about moving that [Unit] option for Requires=graphical.target.
> Try that section under your [Install] section.
>
> On Friday, November 30, 2018 at 10:50:15 AM UTC-6, Harke Smits wrote:
>>
>> Hello Seth,
>>
>> Thanks a lot for your reaction. I already digested these pages (as good
>> as I could, I am an RF engineer, not a programmer). Unfortunately this does
>> not help me much. The service file is at the correct location.
>> I hope to get some clue where I am doing something wrong.
>> Thanks again, regards,
>> Harke
>>
>>
>> On Friday, 30 November 2018 12:18:26 UTC+1, Mala Dies wrote:
>>>
>>> Hello Again Harke,
>>>
>>> Seth here. You need to put your .service files in /etc/systemd/system/.
>>> I am pretty sure.
>>>
>>> Seth
>>>
>>> On Monday, November 26, 2018 at 5:49:16 AM UTC-6, Harke Smits wrote:

 Hello learned group,

 I have a Python application that I'd like to see start up on boot. It
 uses Tkinter, so it needs the graphical environment.
 Running: python /home/debian/eme/myprog.py from the QTerminal command
 line works as expected. Not outside the LXQT environment, which is normal I
 think.
 I made a service file: myprog.service like this:
 [Unit]
 Description=to invoke myprog automatically on boot
 Requires=graphical.target
 [Service]
 Type=simple
 WorkingDirectory=/home/debian/eme/
 ExecStart=python /home/debian/eme/myprog.py
 [Install]
 WantedBy=multi-user.target

 Service file is located at both: /etc/systemd/system/ and
 /lib/systemd/system/ as I am unsure where it actually belongs. Of course I
 already spend a lot of time at internet to find a solution. Only succes
 stories here
 I entered the following;
 sudo systemctl enable myprog.service: nothing special
 sudo systemctl start myprog.service: service is not loaded properly.
 sudo systemctl status myprog.service: error (invalid argument),
 inactive (dead).

 Both from bash or within QTerminal: behaviour is the same.

 Please help me out what to do.
 Kind regards,
 Harke

 --
> 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/goOORlttd2c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/91cdcefd-06b6-4d68-96fe-a95b7dcd4573%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAHmciaZDo3h_tWvXBRJHG7Gc%2B77n3MjD4MQn%3DU4%3DUpqFwnYyBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.