>
> I am using 4.9 kernel which is having ADXL34x driver configured as module.
> After cross compile i am able to detect the device in kernel but ADXL345
> interrupt is not generating.
>
> I made this below changes in device tree. I mapped interrupt 5 of the
> interrupt controller to adxl345 dev
On Sunday, November 18, 2018 at 11:36:43 PM UTC+5:30, Prakash Dash wrote:
>
> I am using 4.9 kernel which is having ADXL34x driver configured as module.
> After cross compile i am able to detect the device in kernel but ADXL345
> interrupt is not generating.
>
> I made this below changes in devi
I have been spending some time trying to understand device tree overlays.
Currently my uEnv.txt is configured so that:
##BeagleBone Black: HDMI (Audio/Video) disabled:
dtb=am335x-boneblack-emmc-overlay.dtb
cat /sys/devices/platform/bone_capemgr/slots
0: PF -1
1: PF -1
2: PF -1
William,
THANK YOU for doing this! :) I am finding this in Nov 2018 and your
solution is exactly what I'm looking for. I really appreciate you
documenting this. But yeah, Google Groups... lol. TBH I'm really
surprised I was able to find this!
Thanks again.
ST
--
For more options, visit h
Mark,
Thank you for the excellent instructions. However, I am still having
trouble getting my PocketBeagle to ping anybody. Thanks to your
instructions, I can log onto the bone without a password for debian and
root. That makes logging on to the bone much simpler, but for the life of
me, I cannot
I ended up finding the .dts sources in /opt/source/bb.org-overlays/src/arm
where I was able to look for partno's.
On Friday, November 23, 2018 at 12:21:30 PM UTC-5, Mike Brandon wrote:
>
> Where can proper "partno" values be located in order to add to this
> configuration in uEnv.txt?
>
--
For
Where can proper "partno" values be located in order to add to this
configuration in uEnv.txt?
--
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 re
Thank you very much for the feedback, Gerard. I already could get access to
the shared memory and have tackled the problem.
However, I think I have not expressed myself correctly. I implemented an
SPI Slave interface in the PRU because the Kernel driver only allows that
as Master. But I have both
Ok, thank you for the feedback Daniel. However, I think I will stick by the
PRU interface, to ensure that no data is loss.
-- Fred Gomes
Daniel Kulp escreveu no dia quinta, 22/11/2018 à(s) 23:19:
> Also note that using GPIO0 pins is slower and more unpredictable that the
> other GPIO's, particu
Hi Alex,
Thank you very much for your tip. I could already solve the problem.
Fred Gomes
Alex Bagehot escreveu no dia quinta, 22/11/2018 à(s)
13:46:
> Hi Fred,
>
> The problem is that
> DDR_BASEADDR != PRU_SHARED_MEM_ADDR
> Ie. The shared memory from the PRU's view is 0x1, but from the Arm
Hi Gianfranco,
did you succeeded with adding 1G of SDRAM to your BBB? I'm fighting with
similar problem but different chip. Thanks.
BR,
marek
Dňa piatok, 26. júna 2015 11:32:36 UTC+2 Gianfranco Rosso napísal(-a):
>
> I have a couple of BBB boards (rev. C) where the original 512MB DDR3 chip
Hi,
I am designing a custom cape for a BeagleBone running with debian 9.4. The
cape has to be connected at the system start, since it is the power supply
for my BB. The cape has a LCD on it which is of course conncted to the
LCD_data pins. Unfortunately I am running into issues while booting si
12 matches
Mail list logo
