Re: [beagleboard] Re: Beaglebone Black PRU Troubles

[Jason Reeder]

Greg and Zach,

Check out the two tarballs in this drive link: 
https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing


   - PRU_Halt_Assembly.tar.gz
   - Contains a project to drop into 
  /opt/source/pru-software-support-package/examples/am335x/ that is an 
  assembly only project
  - There are only two parts to the main.asm file: an empty resource 
  table at the top (mandatory for RemoteProc loading) and a main function 
  that writes '0xdeadbeef' to address 0x4a31 and then halts.
  - I created this assembly file by first writing the program in C, 
  compiling it with the '-k' compiler option to keep the generated 
assembly, 
  and then removing all the unnecessary generated comments
  - Make it on target using the included Makefile (I modified the 
  Makefile to build both .c and .asm files before linking)
 - 
 cd 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/
 - export PRU_CGT=/usr/share/ti/cgt-pru
 - ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
 - make
 - (generated files will be in the 'gen' folder
  - Add a symbolic link from /lib/firmware/am335x-pru1-fw
 - cd /lib/firmware/
 - rm am335x-pru1-fw
 - ln -s 
 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/gen/PRU_Halt_Assembly.out
 
 am335x-pru1-fw
  - Reload the firmware in PRU 1
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
  - Check that the firmware actually ran by seeing if '0xdeadbeef' has 
  been written to 0x4a31 (I use devmem2 for this and I am logged in as 
  root)
 - cd ~/
 - wget http://free-electrons.com/pub/mirror/devmem2.c
 - gcc devmem2.c -o devmem2
 - ./devmem2 0x4a31
 - (output should say '0xdeadbeef' is at that address)
  - PRU_Halt_Mixed.tar.gz
   - Contains a project to drop into 
  /opt/source/pru-software-support-package/examples/am335x/ that is a C 
  program that calls a function that is defined in an assembly file
  - main.c contains a C program that calls a function that takes an 
  integer as a parameter and returns an integer as a result
  - assembly_loop.asm is an assembly file that contains a single 
  function which can be called by a C program (which is what main.c does)
 - the loop is mostly nonsense but shows how to take a parameter in 
 an assembly function as well as how to return a result
  - Make it on target using the included Makefile (I modified the 
  Makefile to build both .c and .asm files before linking)
 - 
 cd 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/
 - export PRU_CGT=/usr/share/ti/cgt-pru
 - ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
 - make
 - (generated files will be in the 'gen' folder
  - Add a symbolic link from /lib/firmware/am335x-pru1-fw
 - cd /lib/firmware/
 - rm am335x-pru1-fw
 - ln -s 
 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/gen/PRU_Halt_Mixed.out
 
 am335x-pru1-fw
  - Reload the firmware in PRU 1
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
  - Check that the firmware actually ran by seeing if address 
  0x4a31 contains the integer passed to the function in the C file 
minus 
  1 (I use devmem2 for this and I am logged in as root)
 - ./devmem2 0x4a31
 - (output should be the parameter passed to the C function in 
 main.c minus 1)
  
Let me know if any of this doesn't make sense. These two projects should 
cover assembly only projects, as well as C programs where you want to write 
one of the functions in assembly.

Jason Reeder

On Monday, November 28, 2016 at 7:52:16 PM UTC-6, Greg wrote:
>
> I believe asmpru is the assembler code compiler which is part of the PRU 
> compilation system which is described in the C/C++ Compiler manual.
>
> pasm is the older assembler which existed prior to the C compiler.
> There are differences in the assembly instructions used with pasm versus 
> the more recent asmpru.
>
> I believe clpru actually uses asmpru in the compilation process of C code.
>
> Check out this discussion, especially the link to the pasm to clpru 
> porting guide:
>
>
> https://groups.google.com/forum/#!searchin/beagleboard/mark$20yoder$20pasm%7Csort:relevance/beagleboard/vuxsX_oMzkM/UjNIYWiKAQAJ
>
> On Monday, November 28, 2016 at 4:49:46 PM UTC-5, Zach B wrote:
>>
>> Greg,
>>
>> Thanks for the info. That linker primer helped a bit with what is exactly 
>> going on inside of the linker, at least to the level that I can understand. 
>> I'm still 

Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram

[dinuxbg]

Unfortunately I have not dealt with python for Pru.

On Tuesday, November 29, 2016 at 1:18:50 AM UTC+2, Neil Jubinville wrote:
> Thx, correct on many accounts.  I found it strange that there was no default 
> way load in a 32 bit value given it is the default register size.  
> 
> 
> Love the macro!  I am going to adopt it :)
> 
> 
> I'll likely now dig into the next level up which implementing the same in 
> pru-gcc / c code vs assembly.   Going even higher level , do you know if 
> there are core bindings to the pruMemMap in python?  I know PRU Speak works a 
> bit but not sure if it does the memory mapping parts.
> 
> 
> Neil
> 
> 
> 
> 
> 
> 
> On Monday, November 28, 2016 at 10:25:57 AM UTC-7, din...@gmail.com wrote:
> Hi Neil,
> 
> 
>  The "r2 = 20" syntax does not load a value in a register. It is for 
> setting symbols - see 
> https://sourceware.org/binutils/docs/as/Setting-Symbols.html#Setting-Symbols 
> . You probably meant to load r2 with a constant integer:
> 
> 
> 
>     ldi r2, %lo(20)
>      ldi, r2.w0 %hi_rlz(20)
> 
> 
> 
> 
> The %lo(X) returns the lower 16 bits of a 32-bit constant integer. The 
> "%hi_rlz(X) returns the higher 16-bits of a 32-bit integer, and marks the 
> instruction for possible elimination if those higher bits are all zero. You 
> may want to declare and use the following helper macro:
> 
> 
> .macro ldi32 rx, expr
>         ldi     \rx, %lo(\expr)
>         ldi     \rx\().w2, %hi_rlz(\expr)
> .endm
> 
>         ; Use like this:
>         ldi32   r2, 20
> 
> 
> 
> 
> Please note that "sp" (Stack Pointer) is an alias for "r2", and "ra" (Return 
> Address) is an alias for "r3". Hence R3 is used whenever you use the "call" 
> instruction to store the return PC address.
> 
> 
> I also don't think that "lbbo r2, r2, 0 4" is correct. You are overwriting 
> the R2 address with a value, which value you are using as an address in the 
> next iteration. Equivalent C code:
> 
> 
> 
>     uint32_t *r2;
>      r2 = (uint32_t)(*r2);
> 
> 
> Also, $lo(r6/4) is probably not what you meant. %lo expects a constant 
> integer as an argument. If you want to copy a register, simply use mov:
> 
> 
>  mov r2,r6
> 
> Regards,
> Dimitar
> 
> 
> On Monday, November 28, 2016 at 7:39:38 AM UTC+2, Neil Jubinville wrote:
> Ok I got it working,   the part I changed is commented out.
> 
> 
> Essentially I used my r6 debug register that had the correct one in it.  Now 
> I can dial in the blinky action! fun!
> 
> 
> So for some reason even though we were setting the r2 form the lbbo it just 
> did not like this syntax.
> 
> 
> 
>   ldi r14, %lo( r6/4 )
>   ldi r14.w2, %hi_rlz(r6/4)
> 
> 
> Seemed to always load the old initial value.   I have to search for the %lo 
> and %hi_rlz  meaning I know it is used to load a high and low set of bytes 
> due to limitations of ldi to a max of 65535 but it was probably messing 
> things up.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>         lbbo r2, r0, 8 ,4
>         mov r6, r2   // to prove in the c program that data arrived and is 
> correct when displayed R2 should equal R6- debug
> 
> 
>         sbbo  r0, r0, 0 , 48    // copy all 12 registers to memory R0...R11 .
> 
> 
>         // the goal is for  R2 to get  set in a C program outside theis 
> assembly.   Thus changing the speed of the
>        // blinking LED  - defualt is set to 1 second  = 200,000,000 cycles in 
> CPU delay.
> 
> 
>         // led on
>         mov     r30, r1
>         mov     r14,r6
>         call    delay_n2_cycles
> 
> 
>         // led off
>         mov     r30, r0
>         mov     r14, r6
>         call    delay_n2_cycles
> 
> 
> /*
>         // led on
>  mov     r30, r1
>  ldi r14, %lo( r6/4 )
>  ldi r14.w2, %hi_rlz(r6/4)
>  call delay_n2_cycles
> 
> 
>  // led off
>  mov r30, r0
>  ldi r14, %lo(r6/4)
>  ldi r14.w2, %hi_rlz(r6/4 )
>  call delay_n2_cycles
> */
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sunday, November 27, 2016 at 10:09:55 PM UTC-7, Neil Jubinville wrote:
> Yes, thank-you, I already know the prompt cycle needs to run twice to pick up 
> the write in the subsequent read cycle, no big deal there, I just enter the 
> same vale twice and I get the feedback. 
> 
> 
> The part I am focused on is why the value from the LBBO does not seem to be 
> used in the delay call.
> 
> 
> You may have missed my  last post where the LBBO worked using the 8 bytes of 
> offset,  R2 is the third 32 bit number in my reference   R0 is the first , R1 
> the second, R2 the third
> 
> 
>   lbbo    r2, r0, 8 ,4    works like a champ.
> 
> 
> 
> After the lbbo I transfer the value I entered into R6 in the PRU and it comes 
> back to me in the sbbo so I know it is working and getting to the general 
> registers.
> 
> 
> The question now is why R2 used as a delay value does not change the delay 
> time when it is truly reaching the PRU.
> 
> 
> Any comments on the initialization of R2 = 200,000,000 ?  does that syntax 
> lock it into a constant?
> 
> 
> 
> 
> 
> 
> 
> On Sunday, 

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

[Jason Reeder]

Greg and Zach,

Check out the two tarballs in this drive link: 
https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing


   - PRU_Halt_Assembly.tar.gz
   - Contains a project to drop into 
  /opt/source/pru-software-support-package/examples/am335x/ that is an 
  assembly only project
  - There are only two parts to the main.asm file: an empty resource 
  table at the top (mandatory for RemoteProc loading) and a main function 
  that writes '0xdeadbeef' to address 0x4a31 and then halts.
  - I created this assembly file by first writing the program in C, 
  compiling it with the '-k' compiler option to keep the generated 
assembly, 
  and then removing all the unnecessary generated comments
  - Make it on target using the included Makefile (I modified the 
  Makefile to build both .c and .asm files before linking)
 - 
 cd 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/
 - export PRU_CGT=/usr/share/ti/cgt-pru
 - ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
 - make
 - (generated files will be in the 'gen' folder
  - Add a symbolic link from /lib/firmware/am335x-pru1-fw
 - cd /lib/firmware/
 - rm am335x-pru1-fw
 - ln -s 
 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/gen/PRU_Halt_Assembly.out
  - Reload the firmware in PRU 1
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
  - Check that the firmware actually ran by seeing if '0xdeadbeef' has 
  been written to 0x4a31 (I use devmem2 for this and I am logged in as 
  root)
 - cd ~/
 - wget http://free-electrons.com/pub/mirror/devmem2.c
 - gcc devmem2.c -o devmem2
 - ./devmem2 0x4a31
 - (output should say '0xdeadbeef' is at that address)
  - PRU_Halt_Mixed.tar.gz
   - Contains a project to drop into 
  /opt/source/pru-software-support-package/examples/am335x/ that is a C 
  program that calls a function that is defined in an assembly file
  - main.c contains a C program that calls a function that takes an 
  integer as a parameter and returns an integer as a result
  - assembly_loop.asm is an assembly file that contains a single 
  function which can be called by a C program (which is what main.c does)
 - the loop is mostly nonsense but shows how to take a parameter in 
 an assembly function as well as how to return a result
  - Make it on target using the included Makefile (I modified the 
  Makefile to build both .c and .asm files before linking)
 - 
 cd 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/
 - export PRU_CGT=/usr/share/ti/cgt-pru
 - ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
 - make
 - (generated files will be in the 'gen' folder
  - Add a symbolic link from /lib/firmware/am335x-pru1-fw
 - cd /lib/firmware/
 - rm am335x-pru1-fw
 - ln -s 
 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/gen/PRU_Halt_Mixed.out
  - Reload the firmware in PRU 1
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
  - Check that the firmware actually ran by seeing if address 
  0x4a31 contains the integer passed to the function in the C file 
minus 
  1 (I use devmem2 for this and I am logged in as root)
 - ./devmem2 0x4a31
 - (output should be the parameter passed to the C function in 
 main.c minus 1)
  
Let me know if any of this doesn't make sense. These two projects should 
cover assembly only projects, as well as C programs where you want to write 
one of the functions in assembly.

Jason Reeder

On Monday, November 28, 2016 at 7:52:16 PM UTC-6, Greg wrote:
>
> I believe asmpru is the assembler code compiler which is part of the PRU 
> compilation system which is described in the C/C++ Compiler manual.
>
> pasm is the older assembler which existed prior to the C compiler.
> There are differences in the assembly instructions used with pasm versus 
> the more recent asmpru.
>
> I believe clpru actually uses asmpru in the compilation process of C code.
>
> Check out this discussion, especially the link to the pasm to clpru 
> porting guide:
>
>
> https://groups.google.com/forum/#!searchin/beagleboard/mark$20yoder$20pasm%7Csort:relevance/beagleboard/vuxsX_oMzkM/UjNIYWiKAQAJ
>
> On Monday, November 28, 2016 at 4:49:46 PM UTC-5, Zach B wrote:
>>
>> Greg,
>>
>> Thanks for the info. That linker primer helped a bit with what is exactly 
>> going on inside of the linker, at least to the level that I can understand. 
>> I'm still working through getting a single assembly file to work 

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

[Jason Reeder]

Greg and Zach,

Check out the two tarballs in this drive 
link: 
https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing


   - PRU_Halt_Assembly.tar.gz
   - Contains a project to drop into 
  /opt/source/pru-software-support-package/examples/am335x/ that is an 
  assembly only project
  - There are only two parts to the main.asm file: an empty resource 
  table at the top (mandatory for RemoteProc loading) and a main function 
  that writes '0xdeadbeef' to address 0x4a31 and then halts.
  - I created this assembly file by first writing the program in C, 
  compiling it with the '-k' compiler option to keep the generated 
assembly, 
  and then removing all the unnecessary generated comments
  - Make it on target using the included Makefile (I modified the 
  Makefile to build both .c and .asm files before linking)
 - 
 cd 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/
 - export PRU_CGT=/usr/share/ti/cgt-pru
 - ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
  - Add a symbolic link from /lib/firmware/am335x-pru1-fw
 - cd /lib/firmware/
 - rm am335x-pru1-fw
 - ln -s 
 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/gen/PRU_Halt_Assembly.out
  - Reload the firmware in PRU 1
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
  - Check that the firmware actually ran by seeing if '0xdeadbeef' has 
  been written to 0x4a31 (I use devmem2 for this and I am logged in as 
  root)
 - cd ~/
 - wget http://free-electrons.com/pub/mirror/devmem2.c
 - gcc devmem2.c -o devmem2
 - ./devmem2 0x4a31
 - (output should say '0xdeadbeef' is at that address)
  - PRU_Halt_Mixed.tar.gz
   - Contains a project to drop into 
  /opt/source/pru-software-support-package/examples/am335x/ that is a C 
  program that calls a function that is defined in an assembly file
  - main.c contains a C program that calls a function that takes an 
  integer as a parameter and returns an integer as a result
  - assembly_loop.asm is an assembly file that contains a single 
  function which can be called by a C program (which is what main.c does)
 - the loop is mostly nonsense but shows how to take a parameter in 
 an assembly function as well as how to return a result
  - Make it on target using the included Makefile (I modified the 
  Makefile to build both .c and .asm files before linking)
 - 
 cd 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/
 - export PRU_CGT=/usr/share/ti/cgt-pru
 - ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
  - Add a symbolic link from /lib/firmware/am335x-pru1-fw
 - cd /lib/firmware/
 - rm am335x-pru1-fw
 - ln -s 
 
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/gen/PRU_Halt_Mixed.out
  - Reload the firmware in PRU 1
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
 - echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
  - Check that the firmware actually ran by seeing if address 
  0x4a31 contains the integer passed to the function in the C file 
minus 
  1 (I use devmem2 for this and I am logged in as root)
 - ./devmem2 0x4a31
 - (output should be the parameter passed to the C function in 
 main.c minus 1)
  
Let me know if any of this doesn't make sense. These two projects should 
cover assembly only projects, as well as C programs where you want to write 
one of the functions in assembly.

Jason Reeder

On Monday, November 28, 2016 at 7:52:16 PM UTC-6, Greg wrote:
>
> I believe asmpru is the assembler code compiler which is part of the PRU 
> compilation system which is described in the C/C++ Compiler manual.
>
> pasm is the older assembler which existed prior to the C compiler.
> There are differences in the assembly instructions used with pasm versus 
> the more recent asmpru.
>
> I believe clpru actually uses asmpru in the compilation process of C code.
>
> Check out this discussion, especially the link to the pasm to clpru 
> porting guide:
>
>
> https://groups.google.com/forum/#!searchin/beagleboard/mark$20yoder$20pasm%7Csort:relevance/beagleboard/vuxsX_oMzkM/UjNIYWiKAQAJ
>
> On Monday, November 28, 2016 at 4:49:46 PM UTC-5, Zach B wrote:
>>
>> Greg,
>>
>> Thanks for the info. That linker primer helped a bit with what is exactly 
>> going on inside of the linker, at least to the level that I can understand. 
>> I'm still working through getting a single assembly file to work but for 
>> now I figured out a workaround with an empty c file. What is asmpru? I only 
>> know about "clpru" and "pasm".
>>
>>
>> Is it 

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

[Greg]

I believe asmpru is the assembler code compiler which is part of the PRU 
compilation system which is described in the C/C++ Compiler manual.

pasm is the older assembler which existed prior to the C compiler.
There are differences in the assembly instructions used with pasm versus 
the more recent asmpru.

I believe clpru actually uses asmpru in the compilation process of C code.

Check out this discussion, especially the link to the pasm to clpru porting 
guide:

https://groups.google.com/forum/#!searchin/beagleboard/mark$20yoder$20pasm%7Csort:relevance/beagleboard/vuxsX_oMzkM/UjNIYWiKAQAJ

On Monday, November 28, 2016 at 4:49:46 PM UTC-5, Zach B wrote:
>
> Greg,
>
> Thanks for the info. That linker primer helped a bit with what is exactly 
> going on inside of the linker, at least to the level that I can understand. 
> I'm still working through getting a single assembly file to work but for 
> now I figured out a workaround with an empty c file. What is asmpru? I only 
> know about "clpru" and "pasm".
>
>
> Is it possible to load firmware into the PRU, start and stop it for 
> testing and then reload new software without having to reboot? Whenever I 
> stop the PRU and go to remove pru_rproc with "rmmod" or "modprobe -r" I get 
> a message that it is still in use. In order to get around that I just 
> restart the system after copying my new firmware file to /lib/firmware, but 
> is there another way around this? As far as I can tell the PRU is not 
> running when I try to unload/remove pru_rproc. Also when exactly is the pru 
> firmware loaded into the PRU, is it when the system boots or when "modprobe 
> pru_rproc" is called and the remoteproc is started?
>

-- 
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/b7258700-705e-4969-8e6e-ca7096dc36cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Compare kernel versions? (re: Adafruit_BBIO ADC bug)

[Drew Fustini]

On Nov 28, 2016 8:46 AM, "Robert Nelson"  wrote:
> yay, sounds like a bug with the native compiler. ;)

What do you mean by native compiler bug?

Are your builds done on ARM whereas I am cross compiling on my Intel PC?

Thanks,
Drew

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

Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram

[Neil Jubinville]

Thx, correct on many accounts.  I found it strange that there was no 
default way load in a 32 bit value given it is the default register size.  

Love the macro!  I am going to adopt it :)

I'll likely now dig into the next level up which implementing the same in 
pru-gcc / c code vs assembly.   Going even higher level , do you know if 
there are core bindings to the pruMemMap in python?  I know PRU Speak works 
a bit but not sure if it does the memory mapping parts.

Neil



On Monday, November 28, 2016 at 10:25:57 AM UTC-7, din...@gmail.com wrote:
>
> Hi Neil,
>
>  The "r2 = 20" syntax does *not* load a value in a register. It is 
> for setting symbols - see 
> https://sourceware.org/binutils/docs/as/Setting-Symbols.html#Setting-Symbols 
> . You probably meant to load r2 with a constant integer:
> ldi r2, %lo(20)
> ldi, r2.w0 %hi_rlz(20)
>
>
>
> The %lo(X) returns the lower 16 bits of a 32-bit constant integer. The 
> "%hi_rlz(X) returns the higher 16-bits of a 32-bit integer, and marks the 
> instruction for possible elimination if those higher bits are all zero. You 
> may want to declare and use the following helper macro:
> .macro ldi32 rx, expr
> ldi \rx, %lo(\expr)
> ldi \rx\().w2, %hi_rlz(\expr)
> .endm
>
> ; Use like this:
> ldi32   r2, 20
>
>
> Please note that "sp" (Stack Pointer) is an alias for "r2", and "ra" 
> (Return Address) is an alias for "r3". Hence R3 is used whenever you use 
> the "call" instruction to store the return PC address.
>
> I also don't think that "lbbo r2, r2, 0 4" is correct. You are overwriting 
> the R2 address with a value, which value you are using as an address in the 
> next iteration. Equivalent C code:
> uint32_t *r2;
> r2 = (uint32_t)(*r2);
>
>
> Also, $lo(r6/4) is probably not what you meant. %lo expects a constant 
> integer as an argument. If you want to copy a register, simply use mov:
>  mov r2,r6
>
> Regards,
> Dimitar
>
>
> On Monday, November 28, 2016 at 7:39:38 AM UTC+2, Neil Jubinville wrote:
>>
>> Ok I got it working,   the part I changed is commented out.
>>
>> Essentially I used my r6 debug register that had the correct one in it. 
>>  Now I can dial in the blinky action! fun!
>>
>> So for some reason even though we were setting the r2 form the lbbo it 
>> just did not like this syntax.
>>
>> *ldi r14, %lo( r6/4 )*
>> * ldi r14.w2, %hi_rlz(r6/4)*
>>
>> *Seemed to always load the old initial value.   I have to search for the 
>> %lo and %hi_rlz  meaning I know it is used to load a high and low set of 
>> bytes due to limitations of ldi to a max of 65535 but it was probably 
>> messing things up.*
>>
>>
>>
>> lbbo r2, r0, 8 ,4
>> mov r6, r2   // to prove in the c program that data arrived and 
>> is correct when displayed R2 should equal R6- debug
>>
>>
>> sbbo  r0, r0, 0 , 48// copy all 12 registers to memory 
>> R0...R11 .
>>
>>
>> // the goal is for  R2 to get  set in a C program outside theis 
>> assembly.   Thus changing the speed of the
>>// blinking LED  - defualt is set to 1 second  = 200,000,000 
>> cycles in CPU delay.
>>
>>
>> // led on
>> mov r30, r1
>> mov r14,r6
>> calldelay_n2_cycles
>>
>>
>> // led off
>> mov r30, r0
>> mov r14, r6
>> calldelay_n2_cycles
>>
>>
>> /*
>> // led on
>>  mov r30, r1
>>  ldi r14, %lo( r6/4 )
>>  ldi r14.w2, %hi_rlz(r6/4)
>>  call delay_n2_cycles
>>
>>
>>  // led off
>>  mov r30, r0
>>  ldi r14, %lo(r6/4)
>>  ldi r14.w2, %hi_rlz(r6/4 )
>>  call delay_n2_cycles
>> */
>>
>>
>>
>>
>>
>>
>> On Sunday, November 27, 2016 at 10:09:55 PM UTC-7, Neil Jubinville wrote:
>>>
>>> Yes, thank-you, I already know the prompt cycle needs to run twice to 
>>> pick up the write in the subsequent read cycle, no big deal there, I just 
>>> enter the same vale twice and I get the feedback. 
>>>
>>> The part I am focused on is why the value from the LBBO does not seem to 
>>> be used in the delay call.
>>>
>>> You may have missed my  last post where the LBBO worked using the 8 
>>> bytes of offset,  R2 is the third 32 bit number in my reference   R0 is the 
>>> first , R1 the second, *R2 the third*
>>>
>>>   lbbo  r2, r0, 8 ,4works like a champ.
>>>
>>> After the lbbo I transfer the value I entered into R6 in the PRU and it 
>>> comes back to me in the sbbo so I know it is working and getting to the 
>>> general registers.
>>>
>>> The question now is why R2 used as a delay value does not change the 
>>> delay time when it is truly reaching the PRU.
>>>
>>> Any comments on the initialization of R2 = 200,000,000 ?  does that 
>>> syntax lock it into a constant?
>>>
>>>
>>>
>>>
>>> On Sunday, November 27, 2016 at 7:12:38 PM UTC-7, Charles Steinkuehler 
>>> wrote:

 On 11/27/2016 6:35 PM, Neil Jubinville wrote: 
 > 
 > Description of the program: 
 > 
 > An LED toggles on and off from a set 

Re: [beagleboard] Beagle Board X-15 Restore OS

[Robert Nelson]

On Mon, Nov 28, 2016 at 1:51 PM, Joseph  wrote:
> I have a Beagle Board X-15.
>
> I attempted to load Java on it, and ran out of space.  I read blogs, and
> followed an attempt to remove Java; but ended up with a beagle board that
> only shows a blinking cursor on the terminal screen (and nothing more).
>
> I would like to load a new image on the Beagle Board X-15, and start over.
> I found this page:  https://beagleboard.org/latest-images
>
> I clicked on the link for the X-15 (to load on my micro-SD card).  But the
> link returns a 404 error.
>
> I'm also not sure how to put the new image on the board, since it doesn't
> seem to have a button to hold down (like the beagle bone black does).
>
> Does anyone have experience with installing a new image on the X-15?
> Thanks,

https://rcn-ee.net/rootfs/bb.org/testing/2016-11-27/lxqt-4gb/bbx15-blank-debian-8.6-lxqt-4gb-armhf-2016-11-27-4gb.img.xz

use https://etcher.io/ to write to a microSD..

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

[beagleboard] Beagle Board X-15 Restore OS

[Joseph]

I have a Beagle Board X-15.  

I attempted to load Java on it, and ran out of space.  I read blogs, and 
followed an attempt to remove Java; but ended up with a beagle board that 
only shows a blinking cursor on the terminal screen (and nothing more).  

I would like to load a new image on the Beagle Board X-15, and start over. 
 I found this page:  https://beagleboard.org/latest-images

I clicked on the link for the X-15 (to load on my micro-SD card).  But the 
link returns a 404 error.  

I'm also not sure how to put the new image on the board, since it doesn't 
seem to have a button to hold down (like the beagle bone black does). 

Does anyone have experience with installing a new image on the X-15? 
 Thanks,

Joseph 

-- 
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/92d5dd98-e7db-420e-9893-06538c33de17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

[Zach B]

Greg,

Thanks for the info. That linker primer helped a bit with what is exactly 
going on inside of the linker, at least to the level that I can understand. 
I'm still working through getting a single assembly file to work but for 
now I figured out a workaround with an empty c file. What is asmpru? I only 
know about "clpru" and "pasm".


Is it possible to load firmware into the PRU, start and stop it for testing 
and then reload new software without having to reboot? Whenever I stop the 
PRU and go to remove pru_rproc with "rmmod" or "modprobe -r" I get a 
message that it is still in use. In order to get around that I just restart 
the system after copying my new firmware file to /lib/firmware, but is 
there another way around this? As far as I can tell the PRU is not running 
when I try to unload/remove pru_rproc. Also when exactly is the pru 
firmware loaded into the PRU, is it when the system boots or when "modprobe 
pru_rproc" is called and the remoteproc is started?

-- 
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/dfb6db1e-5c03-4f2e-8ef6-eec109d73a89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issue with WiFi USB adapter on BBB

[Robert Nelson]

On Mon, Nov 28, 2016 at 2:42 PM, Robert Nelson  wrote:
> On Mon, Nov 28, 2016 at 12:09 PM, Robert Nelson  
> wrote:
>> On Mon, Nov 28, 2016 at 12:03 PM, AG M  wrote:
>>> Thank you. That suggestion worked. I installed a pre-compiled kernel
>>> 4.4.27-ti-r62.
>>>
>>> I'm trying to find a kernel which supports these 3 things
>>>
>>> 1. Runs Xenomai
>>> 2. Power management with the wireless adapter (the current issue)
>>> 3. Power management features in kernel (CPU freq, CPU idle, Suspend-to-Ram,
>>> Runtime PM)
>>>
>>> With 2, manually patching and compiling xenomai with an existing Linux
>>> kernel from scratch didn't work (gave up due to time constraints). I had to
>>> install a pre-compiled kernel 3.8.13-xenomai-r79 and then installed the
>>> xenomai userspace (xenomai 2.6.4). That worked perfectly.
>>>
>>> With 3, I would like to suspend the CPU and then wakeup using GPIO.
>>>
>>> Any chance there is a 4.4.x precompiled Xenomai kernel which supports 2 and
>>> 3?
>>
>> Well i see an ipipe driver for 4.4.x:
>>
>> https://git.xenomai.org/ipipe.git/
>>
>> the xenomai patch merge is always fun...
>
> Okay, give this a shot, totally un-tested:
>
> git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
> cd ti-linux-kernel-dev/
> git checkout origin/ti-linux-xenomai-4.4.y -b tmp
> ./build_deb.sh
>
> cp deploy/linux-image*.deb to target and install via:
>
> sudo dpkg -i linux-image*.deb

debian@beaglebone:~$ dmesg | grep Xenomai
[1.662891] [Xenomai] scheduling class idle registered.
[1.662905] [Xenomai] scheduling class rt registered.
[1.663079] I-pipe: head domain Xenomai registered.
[1.666337] [Xenomai] Cobalt v3.0.3 (Groovy Cosmic Halo)

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

Re: [beagleboard] Issue with WiFi USB adapter on BBB

[Robert Nelson]

On Mon, Nov 28, 2016 at 12:09 PM, Robert Nelson  wrote:
> On Mon, Nov 28, 2016 at 12:03 PM, AG M  wrote:
>> Thank you. That suggestion worked. I installed a pre-compiled kernel
>> 4.4.27-ti-r62.
>>
>> I'm trying to find a kernel which supports these 3 things
>>
>> 1. Runs Xenomai
>> 2. Power management with the wireless adapter (the current issue)
>> 3. Power management features in kernel (CPU freq, CPU idle, Suspend-to-Ram,
>> Runtime PM)
>>
>> With 2, manually patching and compiling xenomai with an existing Linux
>> kernel from scratch didn't work (gave up due to time constraints). I had to
>> install a pre-compiled kernel 3.8.13-xenomai-r79 and then installed the
>> xenomai userspace (xenomai 2.6.4). That worked perfectly.
>>
>> With 3, I would like to suspend the CPU and then wakeup using GPIO.
>>
>> Any chance there is a 4.4.x precompiled Xenomai kernel which supports 2 and
>> 3?
>
> Well i see an ipipe driver for 4.4.x:
>
> https://git.xenomai.org/ipipe.git/
>
> the xenomai patch merge is always fun...

Okay, give this a shot, totally un-tested:

git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
cd ti-linux-kernel-dev/
git checkout origin/ti-linux-xenomai-4.4.y -b tmp
./build_deb.sh

cp deploy/linux-image*.deb to target and install via:

sudo dpkg -i linux-image*.deb

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/CAOCHtYjGmDshmLn%3Dq%3DYhvTxBuq5jZhDOK6iorWS_yVaaLAyO3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Startup Scripts

[Stephane Charette]

>
> I am trying to run some simple startup shell scripts when the system boots.
>

One thing I tend to use is the @reboot keyword in cron.  For example:

*cat /etc/cron.d/startup_scripts*
MAILTO=""
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

@reboot root /home/stephane/scripts/check_for_upgrade.sh
@reboot root /home/stephane/scripts/startup_commands.sh

Stéphane

-- 
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/d465bb3d-09c0-41e1-ae7c-0f77651249cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issue with WiFi USB adapter on BBB

[Robert Nelson]

On Mon, Nov 28, 2016 at 12:03 PM, AG M  wrote:
> Thank you. That suggestion worked. I installed a pre-compiled kernel
> 4.4.27-ti-r62.
>
> I'm trying to find a kernel which supports these 3 things
>
> 1. Runs Xenomai
> 2. Power management with the wireless adapter (the current issue)
> 3. Power management features in kernel (CPU freq, CPU idle, Suspend-to-Ram,
> Runtime PM)
>
> With 2, manually patching and compiling xenomai with an existing Linux
> kernel from scratch didn't work (gave up due to time constraints). I had to
> install a pre-compiled kernel 3.8.13-xenomai-r79 and then installed the
> xenomai userspace (xenomai 2.6.4). That worked perfectly.
>
> With 3, I would like to suspend the CPU and then wakeup using GPIO.
>
> Any chance there is a 4.4.x precompiled Xenomai kernel which supports 2 and
> 3?

Well i see an ipipe driver for 4.4.x:

https://git.xenomai.org/ipipe.git/

the xenomai patch merge is always fun...

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

Re: [beagleboard] Issue with WiFi USB adapter on BBB

[AG M]

Thank you. That suggestion worked. I installed a pre-compiled kernel
*4.4.27-ti-r62.*

I'm trying to find a kernel which supports these 3 things

1. Runs Xenomai
2. Power management with the wireless adapter (the current issue)
3. Power management features in kernel (CPU freq, CPU idle, Suspend-to-Ram,
Runtime PM)

With *2*, manually patching and compiling xenomai with an existing Linux
kernel from scratch didn't work (gave up due to time constraints). I had to
install a pre-compiled kernel* 3.8.13-xenomai-r79 *and then installed the
xenomai userspace (xenomai 2.6.4). That worked perfectly.

With *3*, I would like to suspend the CPU and then wakeup using GPIO.

*Any chance there is a 4.4.x precompiled Xenomai kernel which supports 2
and 3?*

Appreciate your help. Took me a while to figure out this wireless issue.
Thanks.

On Mon, Nov 28, 2016 at 11:10 AM, Robert Nelson 
wrote:

> On Mon, Nov 28, 2016 at 11:06 AM, AG M  wrote:
> > Thanks Robert. That command is not working. This is what I get when I run
> > that command (my wireless interface is wlan1)
> >
> > root@beaglebone:~# iwconfig wlan1 power off
> > Error for wireless request "Set Power Management" (8B2C) :
> > SET failed on device wlan1 ; Operation not permitted.
> >
> > I tried this with two USB wifi adapters popular with BBB (this and this).
> > Does not work on both. I'm currently running 3.8.13-bone79 kernel.
>
> any reason you can't use 4.4.x? (4.4.34-ti-r69)
>
> 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/CALD0yU5TZD7YGXpwWYU8W2SjAGbZXVkmqqmz2jtWR5UtuSEPmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram

[dinuxbg]

Hi Neil,

 The "r2 = 20" syntax does *not* load a value in a register. It is for 
setting symbols - see 
https://sourceware.org/binutils/docs/as/Setting-Symbols.html#Setting-Symbols 
. You probably meant to load r2 with a constant integer:
ldi r2, %lo(20)
ldi, r2.w0 %hi_rlz(20)



The %lo(X) returns the lower 16 bits of a 32-bit constant integer. The 
"%hi_rlz(X) returns the higher 16-bits of a 32-bit integer, and marks the 
instruction for possible elimination if those higher bits are all zero. You 
may want to declare and use the following helper macro:
.macro ldi32 rx, expr
ldi \rx, %lo(\expr)
ldi \rx\().w2, %hi_rlz(\expr)
.endm

; Use like this:
ldi32   r2, 20


Please note that "sp" (Stack Pointer) is an alias for "r2", and "ra" 
(Return Address) is an alias for "r3". Hence R3 is used whenever you use 
the "call" instruction to store the return PC address.

I also don't think that "lbbo r2, r2, 0 4" is correct. You are overwriting 
the R2 address with a value, which value you are using as an address in the 
next iteration. Equivalent C code:
uint32_t *r2;
r2 = (uint32_t)(*r2);


Also, $lo(r6/4) is probably not what you meant. %lo expects a constant 
integer as an argument. If you want to copy a register, simply use mov:
 mov r2,r6

Regards,
Dimitar


On Monday, November 28, 2016 at 7:39:38 AM UTC+2, Neil Jubinville wrote:
>
> Ok I got it working,   the part I changed is commented out.
>
> Essentially I used my r6 debug register that had the correct one in it. 
>  Now I can dial in the blinky action! fun!
>
> So for some reason even though we were setting the r2 form the lbbo it 
> just did not like this syntax.
>
> *ldi r14, %lo( r6/4 )*
> * ldi r14.w2, %hi_rlz(r6/4)*
>
> *Seemed to always load the old initial value.   I have to search for the 
> %lo and %hi_rlz  meaning I know it is used to load a high and low set of 
> bytes due to limitations of ldi to a max of 65535 but it was probably 
> messing things up.*
>
>
>
> lbbo r2, r0, 8 ,4
> mov r6, r2   // to prove in the c program that data arrived and 
> is correct when displayed R2 should equal R6- debug
>
>
> sbbo  r0, r0, 0 , 48// copy all 12 registers to memory 
> R0...R11 .
>
>
> // the goal is for  R2 to get  set in a C program outside theis 
> assembly.   Thus changing the speed of the
>// blinking LED  - defualt is set to 1 second  = 200,000,000 
> cycles in CPU delay.
>
>
> // led on
> mov r30, r1
> mov r14,r6
> calldelay_n2_cycles
>
>
> // led off
> mov r30, r0
> mov r14, r6
> calldelay_n2_cycles
>
>
> /*
> // led on
>  mov r30, r1
>  ldi r14, %lo( r6/4 )
>  ldi r14.w2, %hi_rlz(r6/4)
>  call delay_n2_cycles
>
>
>  // led off
>  mov r30, r0
>  ldi r14, %lo(r6/4)
>  ldi r14.w2, %hi_rlz(r6/4 )
>  call delay_n2_cycles
> */
>
>
>
>
>
>
> On Sunday, November 27, 2016 at 10:09:55 PM UTC-7, Neil Jubinville wrote:
>>
>> Yes, thank-you, I already know the prompt cycle needs to run twice to 
>> pick up the write in the subsequent read cycle, no big deal there, I just 
>> enter the same vale twice and I get the feedback. 
>>
>> The part I am focused on is why the value from the LBBO does not seem to 
>> be used in the delay call.
>>
>> You may have missed my  last post where the LBBO worked using the 8 bytes 
>> of offset,  R2 is the third 32 bit number in my reference   R0 is the first 
>> , R1 the second, *R2 the third*
>>
>>   lbbo  r2, r0, 8 ,4works like a champ.
>>
>> After the lbbo I transfer the value I entered into R6 in the PRU and it 
>> comes back to me in the sbbo so I know it is working and getting to the 
>> general registers.
>>
>> The question now is why R2 used as a delay value does not change the 
>> delay time when it is truly reaching the PRU.
>>
>> Any comments on the initialization of R2 = 200,000,000 ?  does that 
>> syntax lock it into a constant?
>>
>>
>>
>>
>> On Sunday, November 27, 2016 at 7:12:38 PM UTC-7, Charles Steinkuehler 
>> wrote:
>>>
>>> On 11/27/2016 6:35 PM, Neil Jubinville wrote: 
>>> > 
>>> > Description of the program: 
>>> > 
>>> > An LED toggles on and off from a set delay time in R2. 
>>> > 
>>> > A separate C program loads the PRU program, starts the core and then 
>>> prompts the 
>>> > user for a Time to do a delay.   Upon the user entering a time, the c 
>>> program 
>>> > writes that value to dataram and reads back the mapped memory from the 
>>> PRU to show. 
>>> > 
>>> > The PRU loop does a SBBO each time as well as a LBBO for a single R2 . 
>>>   My LBBO 
>>> > call however is not returning the proper value, I am likely using the 
>>> wrong 
>>> > pointer value. 
>>> > 
>>> > Here is where I believe the problem is, how I interpret what register 
>>> address to 
>>> > start at by setting an arbitrary r9 to the start. 
>>> > 
>>> > *ldir9, 9  //  offset to the start of the 

Re: [beagleboard] Issue with WiFi USB adapter on BBB

[Robert Nelson]

On Mon, Nov 28, 2016 at 11:06 AM, AG M  wrote:
> Thanks Robert. That command is not working. This is what I get when I run
> that command (my wireless interface is wlan1)
>
> root@beaglebone:~# iwconfig wlan1 power off
> Error for wireless request "Set Power Management" (8B2C) :
> SET failed on device wlan1 ; Operation not permitted.
>
> I tried this with two USB wifi adapters popular with BBB (this and this).
> Does not work on both. I'm currently running 3.8.13-bone79 kernel.

any reason you can't use 4.4.x? (4.4.34-ti-r69)

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

Re: [beagleboard] Issue with WiFi USB adapter on BBB

[AG M]

Thanks Robert. That command is not working. This is what I get when I run
that command (my wireless interface is wlan1)

*root@beaglebone:~# iwconfig wlan1 power off*
*Error for wireless request "Set Power Management" (8B2C) :*
*SET failed on device wlan1 ; Operation not permitted.*

I tried this with two USB wifi adapters popular with BBB (this

and this ). Does not work on both.
I'm currently running *3.8.13-bone79 *kernel.

Also tried adding this to my* /etc/network/interfaces* file. Still no luck.

*allow-hotplug wlan1*
*iface wlan1 inet dhcp*
*wireless-power of*f

Any suggestions? Thank you.



On Tue, Nov 22, 2016 at 1:46 PM, Robert Nelson 
wrote:

> On Tue, Nov 22, 2016 at 1:20 PM,   wrote:
> > Hello All,
> >
> > I'm using BeagleBone Black as a TCP client which sends a TCP packet
> every 5
> > seconds and the same packet is echoed by the server immediately and I'm
> > measuring the RTT (Round Trip Time). I'm using Edimax WiFi USB adapter.
> The
> > RTT measured was ridiculously high (400ms) and I eventually found out its
> > because the BBB suspends power to the adapter every few milliseconds (if
> > there is no activity). I can see the current toggling between 80mA and 0
> > through an ammeter. Its because of this toggle, the RTT shoots up. I have
> > disabled the auto suspend for the USB. Some observations
> >
> > The same WIFI adapter plugged into a computer (Linux and windows) running
> > the same code works fine (with and without change to the autosuspend
> > settings). No toggling of power and a steady 40ms RTT is observed. Also
> blue
> > LED on adapter is stable.
> > I powered the the USB through a hub(powered externally) and connected it
> to
> > BBB and it still exhibits the issue
> > The toggling of power can be observed with the blue led on the edimax
> > adapter which remains constant when connected to other computers but
> blinks
> > when connected to BBB. Cross checked with an ammeter.
> > When I keep the adapter busy on BBB (by sending the packet every 500ms
> > instead of 2s), the adapter consumes a steady 80mA and the RTT is stable
> at
> > 40ms
> >
> >
> > I have played around with the autosuspend settings (by writing -1 to
> > autosuspend for the usb device), powered through hub etc. but the problem
> > persists.
>
> Have you disable power management?
>
> sudo iwconfig wlan0 power off
>
>
> 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/CALD0yU73B0u9Y7CD9NtcL5XSXZXxZ7Y176b%3DSTQmJO4qkgCDsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Compare kernel versions? (re: Adafruit_BBIO ADC bug)

[Robert Nelson]

On Mon, Nov 28, 2016 at 12:56 AM, Drew Fustini  wrote:
> On Thu, Nov 24, 2016 at 11:56 AM, Robert Nelson  
> wrote:
>> You'll have to use yakbuild*, start with 4.4.30-ti-r66 and in
>> ./KERNEL/, git revert one at a time..
>
> The odd thing is that the issue does not occur with the 4.4.30-ti-r66
> kernel I built using yakbuild:
> https://gist.github.com/pdp7/740c5472ae13e52787f37be0484241f6/#gistcomment-1932257
>
> However, 4.4.30-ti-r66 is a problem when installed via apt-get.

yay, sounds like a bug with the native compiler. ;)

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

[beagleboard] Startup Scripts

[rickyc8888]

Hi,

I am trying to run some simple startup shell scripts when the system boots. 
It used to be an easy task by putting the script in /etc/init.d. But now 
with systemd I have no idea how this can be done. I've tried to put them in 
etc/rc.local, etc/init.d, but the scripts don't seem to run. I've seen some 
tutorials to put the scripts in a service with systemctl, which I haven't 
yet tried. But there must be some other ways?

Kernel version:
Linux beaglebone 4.4.34-ti-r69 #1 SMP Wed Nov 23 20:01:14 UTC 2016 armv7l 
GNU/Linux


Thanks for the help!

Best Regards,

Ricky Chang

-- 
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/3d4f4130-1bb6-4ec9-8744-f444ad731a95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel 4.4.31-bone-rt-r14 sgx-startup.sh - not setting permissions

[Moscowbob]

This is confusing me even more now - I added a "stat" on /dev/pvrsrvkm in 
the sgx-startup.sh, at the end before the "start" finishes and the 
permissions areset correctly -
debian@arm:~$ systemctl status sgx-startup
● sgx-startup.service - LSB: Start daemon at boot time
   Loaded: loaded (/etc/init.d/sgx-startup.sh; generated; vendor preset: 
enabled
   Active: active (exited) since Mon 2016-11-28 07:37:30 UTC; 1min 59s ago
 Docs: man:systemd-sysv-generator(8)
   CGroup: /system.slice/sgx-startup.service

Nov 28 07:37:27 arm systemd[1]: Starting LSB: Start daemon at boot time...
Nov 28 07:37:27 arm sgx-startup.sh[363]: sgx: Starting PVR
Nov 28 07:37:30 arm systemd[1]: Started LSB: Start daemon at boot time.
Nov 28 07:37:30 arm sgx-startup.sh[363]: 666  < just before the script 
completes

debian@arm:~$ ls -al /dev/pvrsrvkm 
crw--- 1 root root 247, 0 Nov 28 07:37 /dev/pvrsrvkm

but still the permissions are 600 as can be seen above.
Any advice will be greatly appreciated.

Thanks

Rob

On Sunday, 27 November 2016 23:16:25 UTC, Moscowbob wrote:
>
> Thank you Robert but I am  not sure what you mean, would you kindly 
> clarify.
> As far as I understand the script, you are setting the permissions to 666 
> and you also start the service.
> What I do not understand is how and why the permissions are not set when 
> the script runs in the first place.
>
> Rob
>
> On Sunday, 27 November 2016 22:03:50 UTC, RobertCNelson wrote:
>>
>> On Sun, Nov 27, 2016 at 3:59 PM, Moscowbob  wrote: 
>> > 
>> > I have just built fresh kernel, dtb, u-boot and sgx as per RCN eewiki 
>> and I 
>> > have also built Qt 5.6.2. 
>> > Everything is working correctly except for one problem which I do not 
>> > understand and hope somebody could explain. 
>> > 
>> > After installing sgx drivers and a reboot I have everything as per 
>> > instructions: 
>> > 
>> > lsmod | grep omaplfb 
>> > 
>> > omaplfb12356  0 
>> > tilcdc 26717  1 omaplfb 
>> > pvrsrvkm  157212  1 omaplfb 
>> > 
>> > but my Qt Quick programs only work when run as root (sudo). 
>> > 
>> > Looking at the sgx-startup script, /dev/pvrsvrkm should be set with 666 
>> > permissions, but after startup this is what I get: 
>> > ls -al /dev/pvrsrvkm 
>> > crw--- 1 root root 247, 0 Nov 27 20:54 /dev/pvrsrvkm 
>> > 
>> > When I run: 
>> > sudo /etc/init.d/sgx-startup.sh stop 
>> > sudo /etc/init.d/sgx-startup.sh start 
>> > 
>> > I get: 
>> > sgx: Starting PVR 
>> > /usr/local/bin/pvrsrvctl: SrvInit failed (already initialized?) 
>> (err=129) 
>> > 
>> > ls -al /dev/pvrsrvkm 
>> > crw-rw-rw- 1 root root 247, 0 Nov 27 21:48 /dev/pvrsrvkm 
>> > Permissions are now correct for running program as normal user. 
>> > 
>> > my programs run correctly with platform eglfs - which is what I want. 
>> > 
>> > My questions: 
>> > 
>> > 1. Why does sgx-startup.sh not set the permissions correctly on boot 
>> and is 
>> > there a way to solve this? 
>>
>> Oh let's patch that in the sgx-startup.sh script..  Probably after the 
>> modprobe/pvrsrvct start.. 
>>
>> Send me a patch and i'll push it out... 
>>
>> 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/71145c6e-6aa9-43f0-a8c4-190b314fc38e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.