[beagleboard] uBoot do not read uEnv.txt

2018-11-21 Thread Romain REIGNIER
Hi everyone,

I am facing an issue with uBoot.

I have built a small system with buildroot 2018.05 and mainline uBoot 
2018.03.
The whole sdcard.img image has been dd to /dev/mmcblk1.
I have tried both am335x_evm_defconfig and am335x_boneblack_defconfig.

But on uBoot start, it seems that it does not read the uEnv.txt file.
But if I put the zImage in mmcblk1p2 in /boot, it manages to find the image 
and start the kernel but with default bootargs.

I have the following log:

U-Boot SPL 2018.03 (Nov 20 2018 - 19:28:32 +0100)
Trying to boot from MMC2
Loading Environment from FAT... Card did not respond to voltage select!
** Bad device mmc 0 **
Failed (-5)


U-Boot 2018.03 (Nov 20 2018 - 19:28:32 +0100)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)
No USB device found
 not set. Validating first E-fuse MAC
Net:   eth0: ethernet@4a10
Hit any key to stop autoboot:  0 
MMC: no card present
MMC: no card present
MMC: no card present
MMC: no card present
MMC: no card present
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
4517040 bytes read in 309 ms (13.9 MiB/s)
38181 bytes read in 20 ms (1.8 MiB/s)
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8fff3000, end 8524 ... OK

Starting kernel ...

I have copied the uEnv.txt file to :

   - mmcblk1p1 -> /uEnv.txt
   - mmcblk1p1 -> /boot/uEnv.txt
   - mmcblk1p2 -> /uEnv.txt
   - mmcblk1p2 -> /boot/uEnv.txt

My goal was to put it in mmcblk1p1 as /uEnv.txt, so my uEnv.txt content is :

bootpart=1:1
devtype=mmc
bootdir=
bootfile=zImage
bootpartition=mmcblk1p2
set_bootargs=setenv bootargs console=ttyO0,115200n8 root=/dev/${
bootpartition} ro rootfstype=ext4 rootwait
uenvcmd=run set_bootargs;run loadimage;run loadfdt;printenv bootargs;bootz $
{loadaddr} - ${fdtaddr}

So the fallback could be OK, but I want my rootfs to be mounted as 
read-only and the default cmdline is set to rw.

Does anyone have already encounter this issue?

Romain

-- 
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/f7f5d5ad-aab9-44ce-92cf-f51a3dfbd368%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[beagleboard] Re: DHCPCD5 on BegaleBone Black

2018-11-21 Thread Mike Brandon
Here is a glimpse at what is getting logged in syslog

Nov 21 14:00:22 beaglebone dhcpcd[1402]: can0: up_interface: Invalid 
argument
Nov 21 14:00:22 beaglebone dhcpcd[1402]: can0: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:22 beaglebone connmand[900]: can0 {newlink} index 5 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone kernel: [   72.979573] c_can_platform 
481d.can can1: bit-timing not yet defined
Nov 21 14:00:23 beaglebone kernel: [   72.986511] c_can_platform 
481d.can can1: failed to open can device
Nov 21 14:00:23 beaglebone connmand[900]: can0 {newlink} index 5 operstate 
2 
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: set_mtu: Invalid argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: up_interface: Invalid 
argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:23 beaglebone connmand[900]: can1 {newlink} index 6 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone connmand[900]: can1 {newlink} index 6 operstate 
2 
Nov 21 14:00:23 beaglebone kernel: [   73.031073] c_can_platform 
481cc000.can can0: bit-timing not yet defined
Nov 21 14:00:23 beaglebone kernel: [   73.037980] c_can_platform 
481cc000.can can0: failed to open can device
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: set_mtu: Invalid argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: up_interface: Invalid 
argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:23 beaglebone kernel: [   73.077959] c_can_platform 
481d.can can1: bit-timing not yet defined
Nov 21 14:00:23 beaglebone kernel: [   73.084876] c_can_platform 
481d.can can1: failed to open can device
Nov 21 14:00:23 beaglebone connmand[900]: can0 {newlink} index 5 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone connmand[900]: can0 {newlink} index 5 operstate 
2 
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: set_mtu: Invalid argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: up_interface: Invalid 
argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:23 beaglebone kernel: [   73.125759] c_can_platform 
481cc000.can can0: bit-timing not yet defined
Nov 21 14:00:23 beaglebone kernel: [   73.132708] c_can_platform 
481cc000.can can0: failed to open can device
Nov 21 14:00:23 beaglebone connmand[900]: can1 {newlink} index 6 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone connmand[900]: can1 {newlink} index 6 operstate 
2 
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: set_mtu: Invalid argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: up_interface: Invalid 
argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:23 beaglebone connmand[900]: can0 {newlink} index 5 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone connmand[900]: can0 {newlink} index 5 operstate 
2 
Nov 21 14:00:23 beaglebone kernel: [   73.198296] c_can_platform 
481d.can can1: bit-timing not yet defined
Nov 21 14:00:23 beaglebone kernel: [   73.205158] c_can_platform 
481d.can can1: failed to open can device
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: set_mtu: Invalid argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: up_interface: Invalid 
argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:23 beaglebone kernel: [   73.247552] c_can_platform 
481cc000.can can0: bit-timing not yet defined
Nov 21 14:00:23 beaglebone kernel: [   73.254472] c_can_platform 
481cc000.can can0: failed to open can device
Nov 21 14:00:23 beaglebone connmand[900]: can1 {newlink} index 6 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone connmand[900]: can1 {newlink} index 6 operstate 
2 
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: set_mtu: Invalid argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: up_interface: Invalid 
argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:23 beaglebone kernel: [   73.318195] c_can_platform 
481d.can can1: bit-timing not yet defined
Nov 21 14:00:23 beaglebone kernel: [   73.325025] c_can_platform 
481d.can can1: failed to open can device
Nov 21 14:00:23 beaglebone connmand[900]: can0 {newlink} index 5 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone connmand[900]: can0 {newlink} index 5 operstate 
2 
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can0: set_mtu: Invalid argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: up_interface: Invalid 
argument
Nov 21 14:00:23 beaglebone dhcpcd[1402]: can1: unsupported interface type 
00, falling back to ethernet
Nov 21 14:00:23 beaglebone connmand[900]: can1 {newlink} index 6 address 
00:00:00:00:00:00 mtu 16
Nov 21 14:00:23 beaglebone kernel: [   73.419087] c_can_platfor

Re: [beagleboard] Re: (ASK) MELP vocoder on Beagleboard

2018-11-21 Thread stratwiz
There's lots of helpful information and data about the MELP vocoder and MELPe 
codec at:
Http://www.melp.org 
Incluing implementations, software, hardware and solutions

-- 
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/976e00ef-5419-4e90-aba9-5b940aad6ab3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] How to acess shared memory between the PRU and Beagle Bone Black

2018-11-21 Thread Fred Gomes
Can anyone explain to me why the below example does not work?  I could
confirm on the PRU side that I am writing correctly in the 0x1 address,
however, I can't get the written value in the beagle bone side. It's quite
confusing to me, since if the memory is shared it should work.

PRU code:

#include 
#include 
#include "resource_table_empty.h"

#define PRU_SHARED_MEM_ADDR 0x0001

void main(void)
{
// enable OCP
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
volatile int* buffer = (volatile int *) PRU_SHARED_MEM_ADDR;
buffer[0] = 0xED;
/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port  --> Shared memory
*/
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
}

Host C++ code:

#include 
#include 
#include 
#include 
#include 

using namespace std;

#define PRU_SHARED_MEM_ADDR 0x0001

int main(int argc, char **argv)
{

volatile int* buffer = (volatile int *)PRU_SHARED_MEM_ADDR;


printf("Memory address: %x\n", &buffer);

return(0);
}

Regards,
Fred Gomes

 escreveu no dia terça, 20/11/2018 à(s) 17:13:

> Hi,
>
> I need your help,
>
> I am developing an application on the beagle bone for reading data for an
> SPI slave. For that, I have to use the PRU since the data transmission is
> up to 15 KHz.
>
> Following this tutorial: https://markayoder.github.io/PRUCookbook/ , in
> the *Chapter** 5 - Memory allocation*, it is explained how memory
> allocation works on the PRU, as well as how to store variables on specific
> memory addresses. But he doesn't mention how do I get access to those
> memory addresses from a host code.
>
> I did some researching on the internet and everything I can find is
> examples of getting access to specific memory adresses using the prussdrv,
> which I think no longer work in the latest Debian images ( I tried to use
> it and it trhowed an error from the very beginning when trying to open the
> drive (*prussdrv_open()*) .  Can anyone give me an inkling on how can I
> achieve this?
>
>
> Ps: Here's an example using the prussdrv :
> http://catch22.eu/beaglebone/beaglebone-pru-ipc/
>
> Best regards,
> Fred Gomes
>
> --
> 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/R8gzE6POFZU/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/c697c5b6-70ff-48e1-97e9-9f89613ba455%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/CAJHs20xwyLQ3MVNmT7O%2BdBGTptzrYB-GTuN2xS-dB8qjLtgwKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] How to acess shared memory between the PRU and Beagle Bone Black

2018-11-21 Thread Chad Baker
On the C-side, you need to find the address that maps the physical to 
logical address. The function "mmap" does that.

volatile int *buffer = (volatile int *)mmao( PRU_SHARED_ADDRESS, ...
Check the man pages for how to use mmap.
Chad

On 11/21/18 7:47 AM, Fred Gomes wrote:
Can anyone explain to me why the below example does not work?  I could 
confirm on the PRU side that I am writing correctly in the 0x1 
address, however, I can't get the written value in the beagle bone 
side. It's quite confusing to me, since if the memory is shared it 
should work.


PRU code:

#include 
#include 
#include "resource_table_empty.h"

#define PRU_SHARED_MEM_ADDR 0x0001

void main(void)
{
// enable OCP
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
volatile int* buffer = (volatile int *) PRU_SHARED_MEM_ADDR;
buffer[0] = 0xED;
/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port  --> Shared 
memory */

CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
}

Host C++ code:

#include 
#include 
#include 
#include 
#include 

using namespace std;

#define PRU_SHARED_MEM_ADDR 0x0001

int main(int argc, char **argv)
{

volatile int* buffer = (volatile int *)PRU_SHARED_MEM_ADDR;


printf("Memory address: %x\n", &buffer);

return(0);
}

Regards,
Fred Gomes

mailto:fred.p.gome...@gmail.com>> escreveu 
no dia terça, 20/11/2018 à(s) 17:13:


Hi,

I need your help,

I am developing an application on the beagle bone for reading data
for an SPI slave. For that, I have to use the PRU since the data
transmission is up to 15 KHz.

Following this tutorial: https://markayoder.github.io/PRUCookbook/
, in the *Chapter** 5 - Memory allocation*, it is explained how
memory allocation works on the PRU, as well as how to store
variables on specific memory addresses. But he doesn't mention how
do I get access to those memory addresses from a host code.

I did some researching on the internet and everything I can find
is examples of getting access to specific memory adresses using
the prussdrv, which I think no longer work in the latest Debian
images ( I tried to use it and it trhowed an error from the very
beginning when trying to open the drive (/prussdrv_open()/) .  Can
anyone give me an inkling on how can I achieve this?


Ps: Here's an example using the prussdrv :
http://catch22.eu/beaglebone/beaglebone-pru-ipc/

Best regards,
Fred Gomes
-- 
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/R8gzE6POFZU/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/c697c5b6-70ff-48e1-97e9-9f89613ba455%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/CAJHs20xwyLQ3MVNmT7O%2BdBGTptzrYB-GTuN2xS-dB8qjLtgwKA%40mail.gmail.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/4b70ca6a-9593-4a38-b727-9f90b5b13dc3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Abridged summary of beagleboard@googlegroups.com - 13 updates in 9 topics

2018-11-21 Thread Prakash Dash
Hi Robert ,
Robert Nelson : Nov 19 09:54AM -0600

> but no Interrupt related to TAP detection and Freefall detection and
others.

> i think evtest tool itself following the iNotify framework and Pollfd to
monitor and collect the data from device

What is the use of this INT_SOURCE and INT_MAP register in ADXL345.
This INT_SOURCE register have different Bits for different types of
Interrupt.
These Interrupts are
1)  Data Ready
2)  Single Tap
3) Double Tap
4) Activity
5) Inactivity
6) Free Fall
7) watermark
8) overrun

These bits will set by the device based on the requirements. In Driver ISR
routine we are reading this Register to
check which bit is set based on the interrupt bit we will forward the
request to the corresponding routine to handle the functionality.

I have already verified this device in OMAP4460 and in OMAP4460 interrupts
are generated properly and each functionality was working fine.
When i was trying to port this device in BBB i am not seeing any interrupt
except watermark.

As  i told i connected ADXL345 externally to BBB pin header using
Breadboard. There is no physical mapping of INT1 and INT2 pin with
Interrupt controller.

Could you suggest any input on this

Thanks
Prakash


On Tue, Nov 20, 2018 at 7:50 PM  wrote:

> beagleboard@googlegroups.com
> 
>  Google
> Groups
> 
> 
> Today's topic summary
> View all topics
> 
>
>- Use as many GPIO pins as possible on Beaglebone black
><#m_-7806384649898860343_group_thread_0> - 1 Update
>- Safely power down the PocketBeagle supplied by a battery
><#m_-7806384649898860343_group_thread_1> - 3 Updates
>- Trouble in getting started with PRU
><#m_-7806384649898860343_group_thread_2> - 2 Updates
>- mcspi receive invalid data on RX
><#m_-7806384649898860343_group_thread_3> - 1 Update
>- Cannot i2cdetect I2C device PCA9685 on BBG
><#m_-7806384649898860343_group_thread_4> - 1 Update
>- The LoadCape and am335x/BeagleBone Black
><#m_-7806384649898860343_group_thread_5> - 1 Update
>- Ideas for Google Summer of Code 2019
><#m_-7806384649898860343_group_thread_6> - 1 Update
>- gpio-keys and gpio-leds not working in linux 4 kernels?
><#m_-7806384649898860343_group_thread_7> - 2 Updates
>- Interrupt is not generating in ADXL345 using 4.9 kernel
><#m_-7806384649898860343_group_thread_8> - 1 Update
>
> Use as many GPIO pins as possible on Beaglebone black
> 
> Wei Shi : Nov 20 05:56AM -0800
>
> I would like to use as many GPIO pins as possible on a Beaglebone black
> board. I use the latest 4.14 image. I am not using HDMI, wireless, but I
> do
> need wired Ethernet and EMMC. So I have my ...more
> 
> Back to top <#m_-7806384649898860343_digest_top>
> Safely power down the PocketBeagle supplied by a battery
> 
> e...@erikhougaard.dk: Nov 19 01:40PM -0800
>
> I am currently facing this issue, because I need to run the 9.3 kernel for
> compatibility reasons (some old PRU code). I know I can probably fix this
> issue by setting the RTC to internal clock, but ...more
> 
> Robert Nelson : Nov 19 06:51PM -0600
>
>
> > I am currently facing this issue, because I need to run the 9.3 kernel
> for compatibility reasons (some old PRU code). I know I can probably fix
> this issue by setting the RTC to internal clock, but ...more
> 
> : Nov 20 01:54PM +0100
>
> U-Boot SPL 2018.09-2-gd5b4c4b656 (Oct 19 2018 - 14:16:02 -0500)
> Trying to boot from MMC1
> Loading Environment from EXT4... ** File not found /boot/uboot.env **
>
> ** Unable to read ...more
> 
> Back to top <#m_-7806384649898860343_digest_top>
> Trouble in getting started with PRU
> 
> "Mark A. Yoder" : Nov 19 09:11AM -0800
>
> Fred:
> It's odd that you have the code from chapter 2 working, but not the code
> in chapter 6. How is the LED wired to P9_11?
> Did you config-pin P9_11 for gpio and not pruout? Is P9_11 configgid
> ...more
> 

[beagleboard] Re: need help with node-red http flow

2018-11-21 Thread TJF
Hi!

Am Mittwoch, 21. November 2018 03:08:31 UTC+1 schrieb Sir BearKat:
>
> Has anyone else done this? Does anyone have a flow that's known to work on 
> the BBB rev C?
>

Most of my projects provide a web interface. I never used a slow node-red 
service. Instead I install lighttpd to serve the pages (and I use further 
features like https and user login) . For contingous site updates ie. in a 
control panel showing the current system state I use fcgi.

This meight be a solution for you as well.

Regards

-- 
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/d18815d3-07ab-4642-a630-a876c467c15d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.