Re: [beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?

[Matthijs van Duin]

On Sunday, 30 August 2015 11:13:03 UTC+2, Andrew P. Lentvorski wrote:
>
> Apparently mmap is doing something stupid that slows down the access from 
> user space.
>

It maps the memory as "strongly ordered", which means the writes get 
flagged with a "delivery confirmation required" bit and the cpu will sit 
and wait for it.

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

Re: [beagleboard] potential toolchains for building for BBB

[Robert P. J. Day]

On Mon, 2 Nov 2015, William Hermans wrote:

> Just an additional thought . . . Personally, I rather like the idea
> of Linaro's toolchain. It makes it really simple for a regular user
> to setup, use, and compile stuff without having to actually having
> to install anything into / onto the system.

  that's almost certainly what i'm going to use as my primary
toolchain in class next week ... i'm mostly following along RCN's BBB
eewiki page here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

and he refers to the linaro toolchain:

https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz

and other than experimenting with whether any of the components listed
there could be upgraded, that page looks pretty battle-tested so i
most likely won't mess with it.

  well, not much ...

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[beagleboard] anyone tested yocto BBB build using musl C library?

[Robert P. J. Day]

  more a curiosity than anything, but has anyone built a bootable
system for the BBB using the musl C library rather than glibc? i'm
tempted to give out an assignment to build for the BBB using musl,
just to demonstrate using a C lib other than glibc.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [beagleboard] Signed BBB drivers for Windows 10

[Robert Nelson]

On Mon, Nov 2, 2015 at 9:22 PM, Jason Kridner 
wrote:

> Already found an issue. Try
> https://github.com/beagleboard/beaglebone-getting-started/releases/tag/1.1.3
>


Jason, i just tested these on a fresh never plugged bbb windows 10
hard-drive..  Looks good, i'll queue up a build right now.

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

Re: [beagleboard] Beaglebone Green Debian 8.2 Kernel 4.1.12-bone16 Capemgr failures

[Ross Morrison]

Robert,

No joy on the redo.

I now remember on a BBB with an erased eMMC and booting off the uSD 
card, I had to remove /boot/initrd.img-4.1.10-bone16 to get capemgr to 
work. But again, this was a Black and booting off the uSD card.


Just did the same (remove /boot/initrd) on my Green, with the uSD 
card as the boot device. The overlay loads okay.


But, if I remove /boot/initrd... from the eMMC booting version, the 
system hangs here:



[3.983731] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[3.989491] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write

[3.996457] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[4.003320] at24 2-0054: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write
[4.010520] at24 2-0055: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write
[4.017732] at24 2-0056: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write
[4.024921] at24 2-0057: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write

[4.031840] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[4.043863] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,,BBG115092762'
[4.050870] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4

[4.112787] bone_capemgr bone_capemgr: slot #0: No cape found
[4.172776] bone_capemgr bone_capemgr: slot #1: No cape found
[4.232777] bone_capemgr bone_capemgr: slot #2: No cape found
[4.292776] bone_capemgr bone_capemgr: slot #3: No cape found
[4.298560] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-UART2' VER 'N/A' PR '0'

[4.306696] bone_capemgr bone_capemgr: slot #4: override
[4.312033] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[4.319038] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,BB-UART2'

[4.328278] bone_capemgr bone_capemgr: initialized OK.
[4.333993] cpu cpu0: of_pm_voltdm_notifier_register: Fail 
calculating voltage latency[95<->1325000]:-22
[4.344173] cpu cpu0: of_pm_voltdm_notifier_register: Fail 
calculating voltage latency[95<->1325000]:-22

[4.412806] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[4.418932] davinci_mdio 4a101000.mdio: detected phy mask fffe
[4.425438] davinci_mdio: dt: updated phy_id[0] from phy_mask[fffe]
[4.432096] davinci_mdio: dt: updated phy_id[1] from phy_mask[fffe]
[4.439795] libphy: 4a101000.mdio: probed
[4.443882] davinci_mdio 4a101000.mdio: phy[0]: device 
4a101000.mdio:00, driver SMSC LAN8710/LAN8720

[4.453711] cpsw 4a10.ethernet: Detected MACID = 84:eb:18:e6:d6:32
[4.461534] omap_rtc 44e3e000.rtc: setting system clock to 2015-11-03 
18:04:45 UTC (1446573885)

[4.470328] of_cfs_init
[4.472869] of_cfs_init: OK
[4.479376] Waiting for root device /dev/mmcblk1p1...
[  125.532778] random: nonblocking pool is initialized

This is what I know. I do want to run this off the eMMC, so ideas for 
finding a solution would be nice.


Thanks,
Ross



On 11/03/2015 09:35 AM, Robert Nelson wrote:

On Tue, Nov 3, 2015 at 11:29 AM, Ross Morrison  wrote:

I haven't been following the postings to closely related to the BBG and have
run into a small problem.

I've built a new 4.1 system using Robert C Nelson's instructions from the
eewiki.

Root file system:
wget -c
https://rcn-ee.com/rootfs/eewiki/minfs/debian-8.2-minimal-armhf-2015-09-07.tar.xz

Current /boot/uEnv.txt contents:

uname_r=4.1.12-bone16

dtb=am335x-bonegreen.dtb

cape_enable=bone_capemgr.enable_partno=BB-UART2

uuid=d8dfc06b-1696-4918-9a58-9c781183bbea


I used the flasher script:
bbb-eMMC-flasher-eewiki-ext4.sh
To copy the working uSD card to the eMMC

I followed the capemgr instructions for v4.1.x+ on the BBG after booting, no
problems encountered there.

All is working except I'm getting capemgr load failures.
Partial dmesg output:

[4.319441] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[4.325219] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1
bytes/write
[4.332151] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[4.339003] at24 2-0054: 32768 byte 24c256 EEPROM, writable, 1
bytes/write
[4.346257] at24 2-0055: 32768 byte 24c256 EEPROM, writable, 1
bytes/write
[4.353462] at24 2-0056: 32768 byte 24c256 EEPROM, writable, 1
bytes/write
[4.360633] at24 2-0057: 32768 byte 24c256 EEPROM, writable, 1
bytes/write
[4.367574] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[4.379591] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,▒,BBG115092762'
[4.386620] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[4.452718] bone_capemgr bone_capemgr: slot #0: No cape found
[4.512714] bone_capemgr bone_capemgr: slot #1: No cape found
[4.572715] bone_capemgr bone_capemgr: slot #2: No cape found
[4.632713] bone_capemgr bone_capemgr: slot #3: No cape found
[4.638499] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART2'
VER 'N/A' PR '0'
[4.646637] 

[beagleboard] Internet Of Things with BBB

[Serge Parent]

My current project


Video 

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

Re: [beagleboard] Beaglebone Green Debian 8.2 Kernel 4.1.12-bone16 Capemgr failures

[Robert Nelson]

On Tue, Nov 3, 2015 at 11:29 AM, Ross Morrison  wrote:
> I haven't been following the postings to closely related to the BBG and have
> run into a small problem.
>
> I've built a new 4.1 system using Robert C Nelson's instructions from the
> eewiki.
>
> Root file system:
> wget -c
> https://rcn-ee.com/rootfs/eewiki/minfs/debian-8.2-minimal-armhf-2015-09-07.tar.xz
>
> Current /boot/uEnv.txt contents:
>
> uname_r=4.1.12-bone16
>
> dtb=am335x-bonegreen.dtb
>
> cape_enable=bone_capemgr.enable_partno=BB-UART2
>
> uuid=d8dfc06b-1696-4918-9a58-9c781183bbea
>
>
> I used the flasher script:
> bbb-eMMC-flasher-eewiki-ext4.sh
> To copy the working uSD card to the eMMC
>
> I followed the capemgr instructions for v4.1.x+ on the BBG after booting, no
> problems encountered there.
>
> All is working except I'm getting capemgr load failures.
> Partial dmesg output:
>
> [4.319441] tps65217 0-0024: TPS65217 ID 0xe version 1.2
> [4.325219] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1
> bytes/write
> [4.332151] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
> [4.339003] at24 2-0054: 32768 byte 24c256 EEPROM, writable, 1
> bytes/write
> [4.346257] at24 2-0055: 32768 byte 24c256 EEPROM, writable, 1
> bytes/write
> [4.353462] at24 2-0056: 32768 byte 24c256 EEPROM, writable, 1
> bytes/write
> [4.360633] at24 2-0057: 32768 byte 24c256 EEPROM, writable, 1
> bytes/write
> [4.367574] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
> [4.379591] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,▒,BBG115092762'
> [4.386620] bone_capemgr bone_capemgr:
> compatible-baseboard=ti,beaglebone-black - #slots=4
> [4.452718] bone_capemgr bone_capemgr: slot #0: No cape found
> [4.512714] bone_capemgr bone_capemgr: slot #1: No cape found
> [4.572715] bone_capemgr bone_capemgr: slot #2: No cape found
> [4.632713] bone_capemgr bone_capemgr: slot #3: No cape found
> [4.638499] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART2'
> VER 'N/A' PR '0'
> [4.646637] bone_capemgr bone_capemgr: slot #4: override
> [4.651974] bone_capemgr bone_capemgr: Using override eeprom data at slot
> 4
> [4.658978] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,BB-UART2'
> [4.668226] bone_capemgr bone_capemgr: initialized OK.
> [4.673926] cpu cpu0: of_pm_voltdm_notifier_register: Fail calculating
> voltage latency[95<->1325000]:-22
> [4.684119] cpu cpu0: of_pm_voltdm_notifier_register: Fail calculating
> voltage latency[95<->1325000]:-22
> [4.752743] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
> [4.758870] davinci_mdio 4a101000.mdio: detected phy mask fffe
> [4.765364] davinci_mdio: dt: updated phy_id[0] from phy_mask[fffe]
> [4.772022] davinci_mdio: dt: updated phy_id[1] from phy_mask[fffe]
> [4.783500] libphy: 4a101000.mdio: probed
> [4.787547] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
> driver SMSC LAN8710/LAN8720
> [4.797495] cpsw 4a10.ethernet: Detected MACID = 84:eb:18:e6:d6:32
> [4.805386] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01
> 00:00:01 UTC (946684801)
> [4.814089] of_cfs_init
> [4.816617] of_cfs_init: OK
> [4.822601] PM: Hibernation image not present or could not be loaded.
> [4.823538] Freeing unused kernel memory: 448K (c098a000 - c09fa000)
> [4.903712] systemd-udevd[86]: starting version 215
> [4.910405] random: systemd-udevd urandom read with 10 bits of entropy
> available
> [5.627393] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
> mode. Opts: (null)
> [5.682949] bone_capemgr bone_capemgr: loader: failed to load slot-4
> BB-UART2:00A0 (prio 0)


Odd, well rerun:

git clone https://github.com/beagleboard/bb.org-overlays
cd bb.org-overlays/

./dtc-overlay.sh
./install.sh

on your bone again..

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

Re: [beagleboard] Understanding the whole Yocto/Linux stack for the BB

['Andreas Müller' via BeagleBoard]

On Tue, Nov 3, 2015 at 7:04 PM, Robert Nelson  wrote:
>> Is there a more stable source available (probably in near future)?
>
> The "4.1" branch get's rebased every thursday...  The git tag's
> "4.1.12-ti-r26" will never be modified after they are pushed..
>
Hmm I am not sure if bitbake's git fetcher can get a commit not
belonging to a branch. If not I'll create a mirror so I'll update
sources and recipe at the same time. Whatever I have more information
than before :)

Andreas

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

Re: [beagleboard] Beaglebone Green Debian 8.2 Kernel 4.1.12-bone16 Capemgr failures

[Ross Morrison]

Here is my updated uEnv.txt. By ordering the entries like yours and 
adding the cmdline= entry, the overlays are now loaded at boot time 
without error.


===
root@bbb-green:~# cat /boot/uEnv.txt
uname_r=4.1.12-bone16

uuid=69951811-ca64-49d9-9e55-49c7c727f449

cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd

dtb=am335x-bonegreen.dtb

cape_enable=bone_capemgr.enable_partno=BB-UART2

root@bbb-green:~#

===

Would you think ordering is significant or the one of the coherent_pool 
or init entries is the fix?


Thanks for your help,

Ross

On 11/03/2015 10:35 AM, Robert Nelson wrote:

On Tue, Nov 3, 2015 at 12:08 PM, Ross Morrison  wrote:

Robert,

No joy on the redo.

I now remember on a BBB with an erased eMMC and booting off the uSD card, I
had to remove /boot/initrd.img-4.1.10-bone16 to get capemgr to work. But
again, this was a Black and booting off the uSD card.

Just did the same (remove /boot/initrd) on my Green, with the uSD card
as the boot device. The overlay loads okay.

But, if I remove /boot/initrd... from the eMMC booting version, the system
hangs here:

odd that shouldn't be needed..

Here's my green:

Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-4.1.10-bone16 ...
7001280 bytes read in 405 ms (16.5 MiB/s)
loading /boot/dtbs/4.1.10-bone16/am335x-bonegreen.dtb ...
54482 bytes read in 47 ms (1.1 MiB/s)
loading /boot/initrd.img-4.1.10-bone16 ...
3900537 bytes read in 237 ms (15.7 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-UART2
root=UUID=e759a48a-f2f3-4bfd-a08e-fe33c3547612 ro rootfstype=ext4
rootwait coherent_pool=1M quiet init=/lib/systemd/systemd] ...
debug: [bootz 0x8200 0x8808:3b8479 0x8800] ...
Kernel image @ 0x8200 [ 0x00 - 0x6ad4c0 ]
## Flattened Device Tree blob at 8800
Booting using the fdt blob at 0x8800
Loading Ramdisk to 8fc47000, end 8479 ... OK
Loading Device Tree to 8fc36000, end 8fc464d1 ... OK

Starting kernel ...



debian@beaglebone:~$ cat /boot/uEnv.txt
uname_r=4.1.10-bone16
uuid=e759a48a-f2f3-4bfd-a08e-fe33c3547612
#dtb=

cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd

cape_enable=bone_capemgr.enable_partno=BB-UART2


[0.00] Linux version 4.1.10-bone16
(root@a5-imx6q-wandboard-2gb) (gcc version 4.6.3 (Debian 4.6.3-14) )
#1 Sun Oct 4 10:00:59 UTC 2015
[0.00] Kernel command line: console=ttyO0,115200n8
bone_capemgr.enable_partno=BB-UART2
root=UUID=e759a48a-f2f3-4bfd-a08e-fe33c3547612 ro rootfstype=ext4
rootwait coherent_pool=1M quiet init=/lib/systemd/systemd
[3.072409] usb usb1: Manufacturer: Linux 4.1.10-bone16 musb-hcd
[3.249190] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,\x1a,BBG115081143'
[3.249214] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[3.303112] bone_capemgr bone_capemgr: slot #0: No cape found
[3.363112] bone_capemgr bone_capemgr: slot #1: No cape found
[3.423108] bone_capemgr bone_capemgr: slot #2: No cape found
[3.483108] bone_capemgr bone_capemgr: slot #3: No cape found
[3.488894] bone_capemgr bone_capemgr: enabled_partno PARTNO
'BB-UART2' VER 'N/A' PR '0'
[3.488905] bone_capemgr bone_capemgr: slot #4: override
[3.488918] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[3.488932] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART2'
[3.489178] bone_capemgr bone_capemgr: initialized OK.
[3.506182] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-UART2-00A0.dtbo' loaded; overlay id #0

debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
  0: PF  -1
  1: PF  -1
  2: PF  -1
  3: PF  -1
  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-UART2


debian@beaglebone:~$ ls -lh /lib/firmware/BB-UART*
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART1-00A0.dtbo
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART2-00A0.dtbo
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART4-00A0.dtbo
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART5-00A0.dtbo

debian@beaglebone:~$ cat /usr/share/initramfs-tools/hooks/dtbo
#!/bin/sh -e
# Copy the *.dtbo's into the initramfs

if [ "$1" = "prereqs" ]; then exit 0; fi

. /usr/share/initramfs-tools/hook-functions

if [ -d /lib/firmware/ ] ; then
 unset check
 check=$(ls /lib/firmware/ | grep dtbo | head -n 1)
 if [ ! "x${check}" = "x" ] ; then
 mkdir -p $DESTDIR/lib/firmware/
 cp -a /lib/firmware/*.dtbo $DESTDIR/lib/firmware/
 fi
fi

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 

Re: [beagleboard] Beaglebone Green Debian 8.2 Kernel 4.1.12-bone16 Capemgr failures

[Robert Nelson]

On Tue, Nov 3, 2015 at 12:50 PM, Ross Morrison  wrote:
> Here is my updated uEnv.txt. By ordering the entries like yours and adding
> the cmdline= entry, the overlays are now loaded at boot time without error.
>
> ===
> root@bbb-green:~# cat /boot/uEnv.txt
> uname_r=4.1.12-bone16
>
> uuid=69951811-ca64-49d9-9e55-49c7c727f449
>
> cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd
>
> dtb=am335x-bonegreen.dtb
>
> cape_enable=bone_capemgr.enable_partno=BB-UART2
>
> root@bbb-green:~#
>
> ===
>
> Would you think ordering is significant or the one of the coherent_pool or
> init entries is the fix?

Not sure either, I disabled each individually,

coherent_pool=1M
This is for some wifi module, with it removed, the cape loads fine..

init=/lib/systemd/systemd
This is for debian wheezy (7.x) to load systemd as init, for debian
(8.x) this isn't needed as systemd is init..
with it removed, the cape loads fine..

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

[beagleboard] Beaglebone Green Debian 8.2 Kernel 4.1.12-bone16 Capemgr failures

[Ross Morrison]

I haven't been following the postings to closely related to the BBG and 
have run into a small problem.


I've built a new 4.1 system using Robert C Nelson's instructions from 
the eewiki.


Root file system:
|wget -c 
https:||//rcn-ee.com/rootfs/eewiki/minfs/debian-8.2-minimal-armhf-2015-09-07.tar.xz|


Current /boot/uEnv.txt contents:

uname_r=4.1.12-bone16

dtb=am335x-bonegreen.dtb

cape_enable=bone_capemgr.enable_partno=BB-UART2

uuid=d8dfc06b-1696-4918-9a58-9c781183bbea


I used the flasher script:
bbb-eMMC-flasher-eewiki-ext4.sh
To copy the working uSD card to the eMMC

I followed the capemgr instructions for v4.1.x+ on the BBG after 
booting, no problems encountered there.


All is working except I'm getting capemgr load failures.
Partial dmesg output:

[4.319441] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[4.325219] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write

[4.332151] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[4.339003] at24 2-0054: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write
[4.346257] at24 2-0055: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write
[4.353462] at24 2-0056: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write
[4.360633] at24 2-0057: 32768 byte 24c256 EEPROM, writable, 1 
bytes/write

[4.367574] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[4.379591] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,▒,BBG115092762'
[4.386620] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4

[4.452718] bone_capemgr bone_capemgr: slot #0: No cape found
[4.512714] bone_capemgr bone_capemgr: slot #1: No cape found
[4.572715] bone_capemgr bone_capemgr: slot #2: No cape found
[4.632713] bone_capemgr bone_capemgr: slot #3: No cape found
[4.638499] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-UART2' VER 'N/A' PR '0'

[4.646637] bone_capemgr bone_capemgr: slot #4: override
[4.651974] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[4.658978] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,BB-UART2'

[4.668226] bone_capemgr bone_capemgr: initialized OK.
[4.673926] cpu cpu0: of_pm_voltdm_notifier_register: Fail 
calculating voltage latency[95<->1325000]:-22
[4.684119] cpu cpu0: of_pm_voltdm_notifier_register: Fail 
calculating voltage latency[95<->1325000]:-22

[4.752743] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[4.758870] davinci_mdio 4a101000.mdio: detected phy mask fffe
[4.765364] davinci_mdio: dt: updated phy_id[0] from phy_mask[fffe]
[4.772022] davinci_mdio: dt: updated phy_id[1] from phy_mask[fffe]
[4.783500] libphy: 4a101000.mdio: probed
[4.787547] davinci_mdio 4a101000.mdio: phy[0]: device 
4a101000.mdio:00, driver SMSC LAN8710/LAN8720

[4.797495] cpsw 4a10.ethernet: Detected MACID = 84:eb:18:e6:d6:32
[4.805386] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 
00:00:01 UTC (946684801)

[4.814089] of_cfs_init
[4.816617] of_cfs_init: OK
[4.822601] PM: Hibernation image not present or could not be loaded.
[4.823538] Freeing unused kernel memory: 448K (c098a000 - c09fa000)
[4.903712] systemd-udevd[86]: starting version 215
[4.910405] random: systemd-udevd urandom read with 10 bits of 
entropy available
[5.627393] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data 
mode. Opts: (null)
*[5.682949] bone_capemgr bone_capemgr: loader: failed to load slot-4 
BB-UART2:00A0 (prio 0)*
[5.857575] systemd[1]: systemd 215 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP 
-APPARMOR)

[5.871367] systemd[1]: Detected architecture 'arm'.
[5.904036] systemd[1]: Set hostname to .
[6.170629] systemd[1]: Cannot add dependency job for unit 
display-manager.service, ignoring: Unit display-manager.service failed 
to load: No such file or directory.
[6.188167] systemd[1]: Starting Forward Password Requests to Wall 
Directory Watch.



root@bbb-green:/# cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
root@bbb-green:/#

What have I missed if possible to tell from this info.

Thanks,
Ross


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

Re: [beagleboard] Beaglebone Green Debian 8.2 Kernel 4.1.12-bone16 Capemgr failures

[Ross Morrison]

Okay, this was unexpected. The cmdline=quiet NEEDS to be there for the 
capes to load at boot.
I confirmed your findings in that the other two entries made no 
difference, but the quiet option apparently is SIGNIFICANT.


Thanks for your help on this one. Don't even want to guess what's up here.

Moving on now,
Ross


On 11/03/2015 10:58 AM, Robert Nelson wrote:

On Tue, Nov 3, 2015 at 12:50 PM, Ross Morrison  wrote:

Here is my updated uEnv.txt. By ordering the entries like yours and adding
the cmdline= entry, the overlays are now loaded at boot time without error.

===
root@bbb-green:~# cat /boot/uEnv.txt
uname_r=4.1.12-bone16

uuid=69951811-ca64-49d9-9e55-49c7c727f449

cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd

dtb=am335x-bonegreen.dtb

cape_enable=bone_capemgr.enable_partno=BB-UART2

root@bbb-green:~#

===

Would you think ordering is significant or the one of the coherent_pool or
init entries is the fix?

Not sure either, I disabled each individually,

coherent_pool=1M
This is for some wifi module, with it removed, the cape loads fine..

init=/lib/systemd/systemd
This is for debian wheezy (7.x) to load systemd as init, for debian
(8.x) this isn't needed as systemd is init..
with it removed, the cape loads fine..

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

[beagleboard] Embedded QT with QT-Creator,undefined symbols

[kscharf]

I followed the examples for setting up a QT cross build environment and an 
Arm-Linux-gnueabihf tool chain
http://exploringbeaglebone.com/chapter11/
http://exploringbeaglebone.com/chapter7 

I've also followed his directions on building QT for the BBB (arm-gueabihf)

The simple command line built program,

#include 
#include 
 
int main(int argc, char *argv[]){
   QApplication app(argc, argv);
   QLabel label("Hello BeagleBone!");
   label.resize(200, 100);
   label.show();
   return app.exec();
}



worked fine, I was able to sftp it to the target and run if locally in an 
LXDE xterm, or via ssh -XC.

However when I tried to build a simple widget application using QT creator 
I ran into various issues.

#include "widget.h" #include  int main(int argc, char 
*argv[]) { QApplication a(argc, argv); Widget w; w.show(); return a.exec(); 
} 

#include "widget.h" Widget::Widget(QWidget *parent) : QWidget(parent) { } 
Widget::~Widget() { } 

#ifndef WIDGET_H
#define WIDGET_H

#include 

class Widget : public QWidget
{
Q_OBJECT

public:
Widget(QWidget *parent = 0);
~Widget();
};

#endif // WIDGET_H


The above project (main.ccp, widget.cpp, and widget.h) compiles and runs 
when built for the desktop, but when I sftp it
to the BBB and run it either way, I get a missing symbol error

./Test3: symbol lookup error: ./Test3: undefined symbol: 
_ZN7QWidget8qwsEventEP8QWSEvent 

My BB is running the Linux distro it came with
uname -a
Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l 
GNU/Linux

and I've installed QT on it via apt-get (rev 4.8.2).  The version of QT I 
built on my host build system is the same.

As an experiment I tried replacing the installed Qt libraries with the 
crossbuilt ones.  I then get a different error when trying to run the 
simple program on the BBB (either via SSH -XC or locally in the LXDE X term)

ebian@beaglebone:~/lib$ ./Test3
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
No Qt for Embedded Linux server appears to be running.
If you want to run this program as a server,
add the "-qws" command-line option.

That "QWS" seems to mean something, it's buried in that missing symbol 
message.  The applications (both the command line version and the QT 
creator one) were both linked against the arm-gueabihf libraries built on 
the cross dev machine, but only the QT-creator (using the widget class) has 
the issues.  Simple examples built to run on the PC (Debian Jessie) run as 
expected.

Any ideas what I've got miss-configured here?






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

Re: [beagleboard] Understanding the whole Yocto/Linux stack for the BB

['Andreas Müller' via BeagleBoard]

On Tue, Nov 3, 2015 at 4:56 PM, Baptiste  wrote:
> Hello,
>
>
>
> I’m using a BeagleBone as a base to develop a custom board. I’ve read pages
> and pages of doc and I feel I need some highlights to make sense of it all.
> Note that I’m mainly trying to understand the custom Linux distribution
> workflow at the lowest level here, for instance to be able to recreate from
> scratch the OE BeagleBoard stack… and I’m confused by all the available
> resources.
>
>
> So, here is my question spree to shed some light on these matters, not
> necessarily specific to the BeagleBone but it's a great platform to
> understand it all. Feel free to contribute even if you don’t have all the
> answers.
>
>
> I don’t understand why is the meta-beagleboard layer that huge. First, why
> is it using the kernel 3.8 where the meta-ti layer supports 4.1? (is
> meta-beagleboard depending on meta-ti in the first place, and if not, why?
> There are references to the BB in the meta-ti tree, why is an other layer
> even needed?) What's the difference with the layer meta-bbb?
>
> Then, why is recipes-kernel so full of all kind of patches? Where do those
> come from, why does the kernel need so much patching? Then, if those patches
> are here to “fix” the mainline kernel for the BB, what is exactly the
> RobertCNelson/bb-kernel repo? And the beagleboard/linux repo? What’s the
> relationship between all those projects?
>
>
> Also, I’ve read the DeviceTree story, but it seems that the actual
> BeagleBone DTS is in the kernel
> (arch/arm/boot/dts/am335x-bone-common.dtsi)... yet I thought the whole point
> of the DTS transition was not to add all ARM board files to the kernel.
> Moreover, many mach-omap2/ and DTS files are patched in bb-kernel and in
> meta-beagleboard... is it just because they’ve not been merged back to
> mainline yet?
>
> When it comes to customizing the DTS, I’ve seen for instance a reference to
> https://github.com/bradfa/beaglebone_pinmux_tables/blob/master/beaglebone_pins_p8
> or https://github.com/jadonk/bonescript/blob/master/src/bone.js to find out
> the actual pin numbers. How are these files have even been generated?
>
>
> I know I am mixing up different concepts here but they all coexist in the
> different docs… so I thought I’d give it a try here. Some resources clearing
> that up would be great too.
>
>
> Thank you for any clue that’ll help me to see through this forest!
> Baptiste
>
FWIW: For the reason other meta's seem to me either unmaintained for
long time or bloated or both, I created another very simple layer [1]
with current beagleboard.org kernel and dt.overlays. No meta-ti
dependency / only sw-rendered mesa - works just fine for me.

[1] https://github.com/schnitzeltony/meta-bbone

Andreas

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

Re: [beagleboard] Understanding the whole Yocto/Linux stack for the BB

[Robert Nelson]

>>> FWIW: For the reason other meta's seem to me either unmaintained for
>>> long time or bloated or both, I created another very simple layer [1]
>>> with current beagleboard.org kernel and dt.overlays. No meta-ti
>>> dependency / only sw-rendered mesa - works just fine for me.
>>>
>>> [1] https://github.com/schnitzeltony/meta-bbone
>>
>> And i probally break it weekly:
> Yes I noticed that already when building on different machines trying
> to checkout non existent commits. Up to now I thought that happened by
> accident.
>
>>
>> https://github.com/schnitzeltony/meta-bbone/blob/master/recipes-kernel/linux/linux-bbone_4.1.bb#L12
>>
>> I never got it working 100%, but you should be able to use the git tag's
>
> As far as I can remember: tags in yocto SRC_URI are causing trouble -
> something like a broken or weak network connection causes recipe
> parsing to fail - even when building for another machine.
>
>>
>> https://github.com/RobertCNelson/meta-beagleboard-kernel/blob/master/recipes-kernel/linux/linux-beagleboard.org_4.1.bb#L46-L58
>
> Wow - so many people doing the same thing - what a waste of resources.
> My excuse: We have many different machines to build images for and use
> yocto for very long time. Now I was forced to get something to work on
> bbb...

I just setup it for an example.. (haven't touched *.bb files in years)

>> So it'll break less often..
>>
> Is there a more stable source available (probably in near future)?

The "4.1" branch get's rebased every thursday...  The git tag's
"4.1.12-ti-r26" will never be modified after they are pushed..

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

Re: [beagleboard] Beaglebone Green Debian 8.2 Kernel 4.1.12-bone16 Capemgr failures

[Robert Nelson]

On Tue, Nov 3, 2015 at 12:08 PM, Ross Morrison  wrote:
> Robert,
>
> No joy on the redo.
>
> I now remember on a BBB with an erased eMMC and booting off the uSD card, I
> had to remove /boot/initrd.img-4.1.10-bone16 to get capemgr to work. But
> again, this was a Black and booting off the uSD card.
>
> Just did the same (remove /boot/initrd) on my Green, with the uSD card
> as the boot device. The overlay loads okay.
>
> But, if I remove /boot/initrd... from the eMMC booting version, the system
> hangs here:

odd that shouldn't be needed..

Here's my green:

Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-4.1.10-bone16 ...
7001280 bytes read in 405 ms (16.5 MiB/s)
loading /boot/dtbs/4.1.10-bone16/am335x-bonegreen.dtb ...
54482 bytes read in 47 ms (1.1 MiB/s)
loading /boot/initrd.img-4.1.10-bone16 ...
3900537 bytes read in 237 ms (15.7 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-UART2
root=UUID=e759a48a-f2f3-4bfd-a08e-fe33c3547612 ro rootfstype=ext4
rootwait coherent_pool=1M quiet init=/lib/systemd/systemd] ...
debug: [bootz 0x8200 0x8808:3b8479 0x8800] ...
Kernel image @ 0x8200 [ 0x00 - 0x6ad4c0 ]
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Ramdisk to 8fc47000, end 8479 ... OK
   Loading Device Tree to 8fc36000, end 8fc464d1 ... OK

Starting kernel ...



debian@beaglebone:~$ cat /boot/uEnv.txt
uname_r=4.1.10-bone16
uuid=e759a48a-f2f3-4bfd-a08e-fe33c3547612
#dtb=

cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd

cape_enable=bone_capemgr.enable_partno=BB-UART2


[0.00] Linux version 4.1.10-bone16
(root@a5-imx6q-wandboard-2gb) (gcc version 4.6.3 (Debian 4.6.3-14) )
#1 Sun Oct 4 10:00:59 UTC 2015
[0.00] Kernel command line: console=ttyO0,115200n8
bone_capemgr.enable_partno=BB-UART2
root=UUID=e759a48a-f2f3-4bfd-a08e-fe33c3547612 ro rootfstype=ext4
rootwait coherent_pool=1M quiet init=/lib/systemd/systemd
[3.072409] usb usb1: Manufacturer: Linux 4.1.10-bone16 musb-hcd
[3.249190] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,\x1a,BBG115081143'
[3.249214] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[3.303112] bone_capemgr bone_capemgr: slot #0: No cape found
[3.363112] bone_capemgr bone_capemgr: slot #1: No cape found
[3.423108] bone_capemgr bone_capemgr: slot #2: No cape found
[3.483108] bone_capemgr bone_capemgr: slot #3: No cape found
[3.488894] bone_capemgr bone_capemgr: enabled_partno PARTNO
'BB-UART2' VER 'N/A' PR '0'
[3.488905] bone_capemgr bone_capemgr: slot #4: override
[3.488918] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[3.488932] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART2'
[3.489178] bone_capemgr bone_capemgr: initialized OK.
[3.506182] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-UART2-00A0.dtbo' loaded; overlay id #0

debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-UART2


debian@beaglebone:~$ ls -lh /lib/firmware/BB-UART*
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART1-00A0.dtbo
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART2-00A0.dtbo
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART4-00A0.dtbo
-rw-r--r-- 1 root root 883 Nov  3 18:26 /lib/firmware/BB-UART5-00A0.dtbo

debian@beaglebone:~$ cat /usr/share/initramfs-tools/hooks/dtbo
#!/bin/sh -e
# Copy the *.dtbo's into the initramfs

if [ "$1" = "prereqs" ]; then exit 0; fi

. /usr/share/initramfs-tools/hook-functions

if [ -d /lib/firmware/ ] ; then
unset check
check=$(ls /lib/firmware/ | grep dtbo | head -n 1)
if [ ! "x${check}" = "x" ] ; then
mkdir -p $DESTDIR/lib/firmware/
cp -a /lib/firmware/*.dtbo $DESTDIR/lib/firmware/
fi
fi

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

Re: [beagleboard] Understanding the whole Yocto/Linux stack for the BB

[Robert Nelson]

On Tue, Nov 3, 2015 at 10:57 AM, 'Andreas Müller' via BeagleBoard
 wrote:
> On Tue, Nov 3, 2015 at 4:56 PM, Baptiste  wrote:
>> Hello,
>>
>>
>>
>> I’m using a BeagleBone as a base to develop a custom board. I’ve read pages
>> and pages of doc and I feel I need some highlights to make sense of it all.
>> Note that I’m mainly trying to understand the custom Linux distribution
>> workflow at the lowest level here, for instance to be able to recreate from
>> scratch the OE BeagleBoard stack… and I’m confused by all the available
>> resources.
>>
>>
>> So, here is my question spree to shed some light on these matters, not
>> necessarily specific to the BeagleBone but it's a great platform to
>> understand it all. Feel free to contribute even if you don’t have all the
>> answers.
>>
>>
>> I don’t understand why is the meta-beagleboard layer that huge. First, why
>> is it using the kernel 3.8 where the meta-ti layer supports 4.1? (is
>> meta-beagleboard depending on meta-ti in the first place, and if not, why?
>> There are references to the BB in the meta-ti tree, why is an other layer
>> even needed?) What's the difference with the layer meta-bbb?
>>
>> Then, why is recipes-kernel so full of all kind of patches? Where do those
>> come from, why does the kernel need so much patching? Then, if those patches
>> are here to “fix” the mainline kernel for the BB, what is exactly the
>> RobertCNelson/bb-kernel repo? And the beagleboard/linux repo? What’s the
>> relationship between all those projects?
>>
>>
>> Also, I’ve read the DeviceTree story, but it seems that the actual
>> BeagleBone DTS is in the kernel
>> (arch/arm/boot/dts/am335x-bone-common.dtsi)... yet I thought the whole point
>> of the DTS transition was not to add all ARM board files to the kernel.
>> Moreover, many mach-omap2/ and DTS files are patched in bb-kernel and in
>> meta-beagleboard... is it just because they’ve not been merged back to
>> mainline yet?
>>
>> When it comes to customizing the DTS, I’ve seen for instance a reference to
>> https://github.com/bradfa/beaglebone_pinmux_tables/blob/master/beaglebone_pins_p8
>> or https://github.com/jadonk/bonescript/blob/master/src/bone.js to find out
>> the actual pin numbers. How are these files have even been generated?
>>
>>
>> I know I am mixing up different concepts here but they all coexist in the
>> different docs… so I thought I’d give it a try here. Some resources clearing
>> that up would be great too.
>>
>>
>> Thank you for any clue that’ll help me to see through this forest!
>> Baptiste
>>
> FWIW: For the reason other meta's seem to me either unmaintained for
> long time or bloated or both, I created another very simple layer [1]
> with current beagleboard.org kernel and dt.overlays. No meta-ti
> dependency / only sw-rendered mesa - works just fine for me.
>
> [1] https://github.com/schnitzeltony/meta-bbone

And i probally break it weekly:

https://github.com/schnitzeltony/meta-bbone/blob/master/recipes-kernel/linux/linux-bbone_4.1.bb#L12

I never got it working 100%, but you should be able to use the git tag's

https://github.com/RobertCNelson/meta-beagleboard-kernel/blob/master/recipes-kernel/linux/linux-beagleboard.org_4.1.bb#L46-L58

So it'll break less often..

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

[beagleboard] Slave McSPI with DMA

[John Syne]

Hi Matthijs,

I have been reading your posts and I am impressed with your detailed knowledge 
of the inner workings of the AM335x. Do you have any experience with using 
MCSPI as a slave and using EDMA. I’m using a high speed ADC that works as a SPI 
master (generates sclk). Since LInux has no support for SPI slave mode, my plan 
was create a driver that sets up MCSPI in slave mode and use EDMA to store 
measurements to a ping-pong buffer. 

Regards,
John



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

Re: [beagleboard] Understanding the whole Yocto/Linux stack for the BB

['Andreas Müller' via BeagleBoard]

On Tue, Nov 3, 2015 at 6:05 PM, Robert Nelson  wrote:
> On Tue, Nov 3, 2015 at 10:57 AM, 'Andreas Müller' via BeagleBoard
>  wrote:
>> On Tue, Nov 3, 2015 at 4:56 PM, Baptiste  wrote:
>>> Hello,
>>>
>>>
>>>
>>> I’m using a BeagleBone as a base to develop a custom board. I’ve read pages
>>> and pages of doc and I feel I need some highlights to make sense of it all.
>>> Note that I’m mainly trying to understand the custom Linux distribution
>>> workflow at the lowest level here, for instance to be able to recreate from
>>> scratch the OE BeagleBoard stack… and I’m confused by all the available
>>> resources.
>>>
>>>
>>> So, here is my question spree to shed some light on these matters, not
>>> necessarily specific to the BeagleBone but it's a great platform to
>>> understand it all. Feel free to contribute even if you don’t have all the
>>> answers.
>>>
>>>
>>> I don’t understand why is the meta-beagleboard layer that huge. First, why
>>> is it using the kernel 3.8 where the meta-ti layer supports 4.1? (is
>>> meta-beagleboard depending on meta-ti in the first place, and if not, why?
>>> There are references to the BB in the meta-ti tree, why is an other layer
>>> even needed?) What's the difference with the layer meta-bbb?
>>>
>>> Then, why is recipes-kernel so full of all kind of patches? Where do those
>>> come from, why does the kernel need so much patching? Then, if those patches
>>> are here to “fix” the mainline kernel for the BB, what is exactly the
>>> RobertCNelson/bb-kernel repo? And the beagleboard/linux repo? What’s the
>>> relationship between all those projects?
>>>
>>>
>>> Also, I’ve read the DeviceTree story, but it seems that the actual
>>> BeagleBone DTS is in the kernel
>>> (arch/arm/boot/dts/am335x-bone-common.dtsi)... yet I thought the whole point
>>> of the DTS transition was not to add all ARM board files to the kernel.
>>> Moreover, many mach-omap2/ and DTS files are patched in bb-kernel and in
>>> meta-beagleboard... is it just because they’ve not been merged back to
>>> mainline yet?
>>>
>>> When it comes to customizing the DTS, I’ve seen for instance a reference to
>>> https://github.com/bradfa/beaglebone_pinmux_tables/blob/master/beaglebone_pins_p8
>>> or https://github.com/jadonk/bonescript/blob/master/src/bone.js to find out
>>> the actual pin numbers. How are these files have even been generated?
>>>
>>>
>>> I know I am mixing up different concepts here but they all coexist in the
>>> different docs… so I thought I’d give it a try here. Some resources clearing
>>> that up would be great too.
>>>
>>>
>>> Thank you for any clue that’ll help me to see through this forest!
>>> Baptiste
>>>
>> FWIW: For the reason other meta's seem to me either unmaintained for
>> long time or bloated or both, I created another very simple layer [1]
>> with current beagleboard.org kernel and dt.overlays. No meta-ti
>> dependency / only sw-rendered mesa - works just fine for me.
>>
>> [1] https://github.com/schnitzeltony/meta-bbone
>
> And i probally break it weekly:
Yes I noticed that already when building on different machines trying
to checkout non existent commits. Up to now I thought that happened by
accident.

>
> https://github.com/schnitzeltony/meta-bbone/blob/master/recipes-kernel/linux/linux-bbone_4.1.bb#L12
>
> I never got it working 100%, but you should be able to use the git tag's

As far as I can remember: tags in yocto SRC_URI are causing trouble -
something like a broken or weak network connection causes recipe
parsing to fail - even when building for another machine.

>
> https://github.com/RobertCNelson/meta-beagleboard-kernel/blob/master/recipes-kernel/linux/linux-beagleboard.org_4.1.bb#L46-L58

Wow - so many people doing the same thing - what a waste of resources.
My excuse: We have many different machines to build images for and use
yocto for very long time. Now I was forced to get something to work on
bbb...
>
> So it'll break less often..
>
Is there a more stable source available (probably in near future)?

Andreas

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

Re: [beagleboard] Looking for SPI Salve configuration and sample code for testing on BBB with kernel 3.8.13

[John Syne]

Hi Ravi,

My best advise is to look at Starterware example code for McSPI. This will give 
you some idea on how to configure and use the McSPI at the register level. When 
that is familiar, then reading through the /drivers/dma/edma.c code will be 
easier to understand. You will notice that the McSPI is configures in slave 
mode by default and then the driver configures it to master mode. The complete 
SPI framework in Linux is based on master mode and there is as far an I know no 
slave mode framework. I am looking at using McSPI with EDMA so that packets 
received by the McSPI are stored in a ping-pong buffer and then using a 
callback, process that buffer. At the moment this is WIP and I’m hoping with 
some help from others on the mailing list I will get this done shortly. 

Regards,
John




> On Nov 3, 2015, at 4:22 AM, ravi@gmail.com wrote:
> 
> 
> Hi ALL,
> 
> Please provide your support on this BBB SPI slave configuration and sample 
> code for kernel 3.8.13 .
> 
> I have done Master mode communication  with slave memory device, but i want 
> to communication with two BBB. one is mater and another is salve device.
> 
> I guess present kernel doesn't support slave mode but i don't know kernel 
> modification to change master to salve mode.
> 
> Please provide your valuable inputs to me.
> 
> Thank you in advance
> 
> Regards
> Ravi 
> 
> -- 
> 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 
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] anyone have mainline drivers/staging/fbtft working?

[Drew Fustini]

thanks for the quick the response! that gives a me a good place to
start looking.

On Tue, Nov 3, 2015 at 3:04 PM, Robert Nelson  wrote:
> On Tue, Nov 3, 2015 at 3:01 PM, Drew Fustini  wrote:
>> fbtft is a collection of Linux kernel framebuffer drivers for small
>> LCD and OLED displays.
>>
>> It is was developed out-of-tree in this github repo:
>>
>> https://github.com/notro/fbtft
>>
>> I compiled those fbtft kernel modules for 3.8.13-bone79, and it does
>> work OK for me with 1.8" & 2.2" TFT LCD displays:
>>
>>   https://gist.github.com/pdp7/2fba066dcf23b049781a
>>
>> Photos of displays working:
>>
>>   https://plus.google.com/photos/+DrewFustini/albums/6211546193314906001
>>
>> Earlier this year, fbtft was added to the mainline Linux kernel in
>> drivers/staging dir:
>>
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/staging/fbtft
>>
>> I compiled Linux 4.3-rc7 with staging fbtft modules enabled using the
>> am33x-v4.3 branch of bb-kernel:
>>
>>  https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.3
>>
>> I load the SPIDEV1 cape OK after compiling the dtbo's from:
>>
>> https://github.com/beagleboard/bb.org-overlays
>>
>> I modprobe the fbtft_device module for adafruit18 like I did in
>> v3.8.13, but this time the SPI code hangs.  Here is the backtrace from
>> kernel log:
>>
>> https://gist.github.com/pdp7/579c1d5c48670c92db44
>>
>> It seems the hang occurs in omap2_mcspi_driver:
>>
>> spi_transfer_one_message() -> omap2_mcspi_transfer_one() ->
>> wait_for_completion()
>
> I think it's related too:
>
> https://groups.google.com/forum/#!msg/beagleboard/udVR5aJvifg/_hbAw4EzuaoJ
>
> background:
>
> debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=159 count=1
> 1+0 records in
> 1+0 records out
> 159 bytes (159 B) copied, 0.000508833 s, 312 kB/s
> debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=160 count=1
> ^C
>
> (hangs..)
>
> I should really start a bisect run, as it broke before mainline v4.1.x..
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] anyone have mainline drivers/staging/fbtft working?

[Robert Nelson]

On Tue, Nov 3, 2015 at 3:37 PM, Drew Fustini  wrote:
> thanks for the quick the response! that gives a me a good place to
> start looking.

okay seems to work in v4.0.x so it's a regression in v4.1.x..

 debian@beaglebone:~$ uname -r
4.0.9-bone-rt-r8.1
debian@beaglebone:~$ sudo dd if=/dev/zero of=/dev/spidev1.0 bs=320 count=1
1+0 records in
1+0 records out
320 bytes (320 B) copied, 0.00266366 s, 120 kB/s

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

Re: [beagleboard] anyone have mainline drivers/staging/fbtft working?

[Robert Nelson]

On Tue, Nov 3, 2015 at 3:01 PM, Drew Fustini  wrote:
> fbtft is a collection of Linux kernel framebuffer drivers for small
> LCD and OLED displays.
>
> It is was developed out-of-tree in this github repo:
>
> https://github.com/notro/fbtft
>
> I compiled those fbtft kernel modules for 3.8.13-bone79, and it does
> work OK for me with 1.8" & 2.2" TFT LCD displays:
>
>   https://gist.github.com/pdp7/2fba066dcf23b049781a
>
> Photos of displays working:
>
>   https://plus.google.com/photos/+DrewFustini/albums/6211546193314906001
>
> Earlier this year, fbtft was added to the mainline Linux kernel in
> drivers/staging dir:
>
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/staging/fbtft
>
> I compiled Linux 4.3-rc7 with staging fbtft modules enabled using the
> am33x-v4.3 branch of bb-kernel:
>
>  https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.3
>
> I load the SPIDEV1 cape OK after compiling the dtbo's from:
>
> https://github.com/beagleboard/bb.org-overlays
>
> I modprobe the fbtft_device module for adafruit18 like I did in
> v3.8.13, but this time the SPI code hangs.  Here is the backtrace from
> kernel log:
>
> https://gist.github.com/pdp7/579c1d5c48670c92db44
>
> It seems the hang occurs in omap2_mcspi_driver:
>
> spi_transfer_one_message() -> omap2_mcspi_transfer_one() ->
> wait_for_completion()

I think it's related too:

https://groups.google.com/forum/#!msg/beagleboard/udVR5aJvifg/_hbAw4EzuaoJ

background:

debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=159 count=1
1+0 records in
1+0 records out
159 bytes (159 B) copied, 0.000508833 s, 312 kB/s
debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=160 count=1
^C

(hangs..)

I should really start a bisect run, as it broke before mainline v4.1.x..

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

[beagleboard] Re: Slave McSPI with DMA

[Matthijs van Duin]

On 2 November 2015 at 19:02, John Syne  wrote:

> I have been reading your posts and I am impressed with your detailed
> knowledge of the inner workings of the AM335x. Do you have any experience
> with using MCSPI as a slave and using EDMA. I’m using a high speed ADC that
> works as a SPI master (generates sclk). Since LInux has no support for SPI
> slave mode, my plan was create a driver that sets up MCSPI in slave mode
> and use EDMA to store measurements to a ping-pong buffer.


I don't have any experience with it yet, but it sounds like it should work.
McSPI even has an option to relocate the fifo port to a 32-byte aligned
address which is specifically added to allow you to use EDMA's "FIFO mode"
(aka "constant addressing" or "streaming burst"), which enables it to slurp
16 or 32 bytes from the McSPI fifo with a single read.

I'm not sure about the "ping-pong buffer" though, I'm not really familiar
with linux kernel programming but I think for incoming DMA it might be
better to allocate cache-cold pages? hmm, not sure how the reduced cache
activity would balance against the increase in bookkeeping... depends also
on what you intend to do with the received data, e.g. if you're going to
stuff it down a pipe towards userspace you probably want to hand over the
pages and need to allocate new ones anyway.

Beware BTW that if SPI mode 0 or 2 is used, chip select is *required* to be
deasserted between transfers. No such restriction applies to SPI mode 1 or
3, and chip select is optional there.

Depending on what exactly that adc is sending, there's also a (small)
chance you could interface it to McASP instead, which has a larger fifo and
some data reformatting options.

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

[beagleboard] 4.1 kernel difficulties with SPI

[m...@gehlvail.net]

Hi - I’m trying kernel 4.1.12-ti-r26, and trying to overlay the
BB-SPIDEV0-0A00.dtbo (after disabling HDMI in uEnv.txt)

echo 'BB-SPIDEV0' > /sys/devices/platform/bone_capemgr/slots
gives me sh: echo: I/O error, and tail’ing dmesg shows:

[ 1195.632275] bone_capemgr bone_capemgr: slot #8: override
[ 1195.632324] bone_capemgr bone_capemgr: Using override eeprom data at
slot 8
[ 1195.632375] bone_capemgr bone_capemgr: slot #8: 'Override Board
Name,00A0,Override Manuf,BB-SPIDEV0'
[ 1195.633705] __of_adjust_tree_phandle_references: Could not find target
property 'fixup' @/__local_fixups__
[ 1195.656537] bone_capemgr bone_capemgr: slot #8: Failed to resolve tree
#

Am I missing something?

Thanks,

Mike

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

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

[Pierre-Louis Constant]

>
> Anyhow, I noticed we've drifted slightly off-topic here... ;-)
>

Holy molly ... we did, however you guys provided me enough info leads for a 
whole year of insomnia. 

Nevertheless there are a point I'd like to bump up :  

Correct, pretty much anything can be used from userspace like that, 
> although some people will frown at you for bypassing the kernel if you do.


Righteo, so far I was using the somewhat slow (but easy) way thyrough FS, 
however I am stuck with running my program as root, as I can't access the 
PWM (or hardware) as normal user. Using the mmap() method would be 
permission free, would it ? 

Cheers guys, 

PL



 
On Monday, November 2, 2015 at 3:44:01 PM UTC+8, Matthijs van Duin wrote:
>
> On 2 November 2015 at 07:52, William Hermans  > wrote:
>
>> Determinism. I do agree with what you're saying, but sometimes, you need 
>> things to happen at exactly . In userland, you may be 
>> able to achieve that most of the time, but you will not be able to achieve 
>> that all of the time. Even if that time interval does not happen very often.
>>
>
> Determinism is relative. RT kernels should in principle allow things to 
> happen within  all of the time, provided the interval 
> is not too tight, you correctly configured priorities, and you don't run 
> into a seriously misbehaving driver.
>
> PRUSS of course offers absolute determinism, but only if you stay within 
> the subsystem. As soon as you start using peripherals outside it your 
> timing starts getting affected by interconnect traffic from the cortex-A8.
>
> For some applications even the jitter due to competing interconnect 
> traffic is already bad. For most however the jitter of an RT kernel is 
> probably fine.
>
> As an added bonus, we get to offload the main core in the process :)
>>
>
> I'd consider PRU to be a more precious resource than cortex-A8 cycles 
> though.
>  
>
>> So /dev/iio:device0 is a buffer for the ADC when operating in continuous 
>> mode
>>
>
> Ah, yes I also use a tiny ring buffer for ADC which I reserved (using DT) 
> in OCMC ram. Configured DMA to write the ADC data to the buffer whenever 
> it's available, and userspace can simply read the latest measurements from 
> the buffer whenever it needs them.
>  
>
>> I now consider iio a waste of time. In a way, like you, I do not like 
>> unnecessary abstraction layers. Especially those that seem to fight against 
>> ones willingness to learn
>>
>
> I have to admit I didn't look at it very long, but to me it also seemed 
> overly complicated and opaque.
>
> Anyhow, I noticed we've drifted slightly off-topic here... ;-)
>

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

Re: [beagleboard] 4.1 kernel difficulties with SPI

[Robert Nelson]

On Tue, Nov 3, 2015 at 8:05 PM, m...@gehlvail.net  wrote:
> Hi - I’m trying kernel 4.1.12-ti-r26, and trying to overlay the
> BB-SPIDEV0-0A00.dtbo (after disabling HDMI in uEnv.txt)
>
> echo 'BB-SPIDEV0' > /sys/devices/platform/bone_capemgr/slots
> gives me sh: echo: I/O error, and tail’ing dmesg shows:
>
> [ 1195.632275] bone_capemgr bone_capemgr: slot #8: override
> [ 1195.632324] bone_capemgr bone_capemgr: Using override eeprom data at slot
> 8
> [ 1195.632375] bone_capemgr bone_capemgr: slot #8: 'Override Board
> Name,00A0,Override Manuf,BB-SPIDEV0'
> [ 1195.633705] __of_adjust_tree_phandle_references: Could not find target
> property 'fixup' @/__local_fixups__
> [ 1195.656537] bone_capemgr bone_capemgr: slot #8: Failed to resolve tree

These missing "fixup"'s are a hint it was built with a different dtc compiler..

https://github.com/beagleboard/bb.org-overlays/blob/master/dtc-overlay.sh

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

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

[Matthijs van Duin]

On 4 November 2015 at 03:40, Pierre-Louis Constant 
wrote:

> you guys provided me enough info leads for a whole year of insomnia.
>

haha, sorry :-)


> Correct, pretty much anything can be used from userspace like that,
>> although some people will frown at you for bypassing the kernel if you do.
>
>
> Righteo, so far I was using the somewhat slow (but easy) way thyrough FS,
> however I am stuck with running my program as root, as I can't access the
> PWM (or hardware) as normal user. Using the mmap() method would be
> permission free, would it ?
>

other way around: you can simply change owner/group/permissions in sysfs if
you want to (although obviously it won't persist across reboots, hence
would need to be done e.g. in an udev rule).

/dev/mem however always requires root permissions to open. You can of
course open it and then drop permissions (and close the descriptor after
mmapping the regions you need). The same is true for other files and
devices of course, including sysfs files.

uio is the cleanest here: the pastebin I linked to actually included an
example udev rule for setting group and permissions.

sysfs files aren't devices hence you can't set their permissions in the
same way but need to do something ugly like RUN="/bin/chmod ...". It's
still wise to do it in an udev rule rather than a fixed startup script
since it may run too early and the files may not exist yet.

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

Re: [beagleboard] Re: Slave McSPI with DMA

[John Syne]

I think that link refers to SPI slave nodes and not SPI slave mode. There are a 
few postings on E2E related to SPI slave mode, but none seem to have achieve 
anything, or at least anything that they disclosed. 

My approach is to use Starterware to mock up a solution where I have McSPI and 
EDMA transferring data to a ping-pong buffer (DMA writes to one buffer while 
CPU processes the other buffer and then swap buffers at the end of each 
transfer). If I can achieve that then I should be able to implement the same 
solution in a device driver. 

Regards,
John




> On Nov 3, 2015, at 7:33 PM, William Hermans  wrote:
> 
> So, I was curious about this too, and decided to do some web searching . . . 
> it seems there is a lot of talk about this going back since around 2009. 
> Although it is unclear whether or not slave mode was ever achieved, some guy 
> on the E2E forums claimed to have done it. Using DMA as well.
> 
> But there is this:
> http://linux-kernel.2935.n7.nabble.com/PATCH-spi-spi-omap2-mcspi-c-Add-dts-for-slave-device-configuration-td622831.html
>  
> 
> 
> And a bunch of other semi code related posts here and there that I can't make 
> out if they're useful or not. It's kind of a wonder that any of these guys 
> ever get anything done . . .
> 
> 
> On Tue, Nov 3, 2015 at 4:25 PM, Matthijs van Duin  > wrote:
> On 2 November 2015 at 19:02, John Syne  > wrote:
> I have been reading your posts and I am impressed with your detailed 
> knowledge of the inner workings of the AM335x. Do you have any experience 
> with using MCSPI as a slave and using EDMA. I’m using a high speed ADC that 
> works as a SPI master (generates sclk). Since LInux has no support for SPI 
> slave mode, my plan was create a driver that sets up MCSPI in slave mode and 
> use EDMA to store measurements to a ping-pong buffer. 
> 
> I don't have any experience with it yet, but it sounds like it should work. 
> McSPI even has an option to relocate the fifo port to a 32-byte aligned 
> address which is specifically added to allow you to use EDMA's "FIFO mode" 
> (aka "constant addressing" or "streaming burst"), which enables it to slurp 
> 16 or 32 bytes from the McSPI fifo with a single read.
> 
> I'm not sure about the "ping-pong buffer" though, I'm not really familiar 
> with linux kernel programming but I think for incoming DMA it might be better 
> to allocate cache-cold pages? hmm, not sure how the reduced cache activity 
> would balance against the increase in bookkeeping... depends also on what you 
> intend to do with the received data, e.g. if you're going to stuff it down a 
> pipe towards userspace you probably want to hand over the pages and need to 
> allocate new ones anyway.
> 
> Beware BTW that if SPI mode 0 or 2 is used, chip select is required to be 
> deasserted between transfers. No such restriction applies to SPI mode 1 or 3, 
> and chip select is optional there.
> 
> Depending on what exactly that adc is sending, there's also a (small) chance 
> you could interface it to McASP instead, which has a larger fifo and some 
> data reformatting options.
> 
> -- 
> 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 
> .
> 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 
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] anyone have mainline drivers/staging/fbtft working?

[Drew Fustini]

I'm trying to build bb-kernel am33x-v4.0 but a patch conflict occurs:

  CONFLICT (content): Merge conflict in include/linux/compiler-gcc.h
  Patch failed at 0052 overflow-arith: begin to add support for
overflow builtin functions

Full log: https://gist.github.com/pdp7/73eb4857d38054ebcf9f

I can do a fresh git clone of bb-kernel (which takes quite awhile), so
I'm wondering if this is a problem for "just me".

thanks,
drew

On Tue, Nov 3, 2015 at 4:19 PM, Robert Nelson  wrote:
> On Tue, Nov 3, 2015 at 3:37 PM, Drew Fustini  wrote:
>> thanks for the quick the response! that gives a me a good place to
>> start looking.
>
> okay seems to work in v4.0.x so it's a regression in v4.1.x..
>
>  debian@beaglebone:~$ uname -r
> 4.0.9-bone-rt-r8.1
> debian@beaglebone:~$ sudo dd if=/dev/zero of=/dev/spidev1.0 bs=320 count=1
> 1+0 records in
> 1+0 records out
> 320 bytes (320 B) copied, 0.00266366 s, 120 kB/s
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Slave McSPI with DMA

[William Hermans]

>
> *I think that link refers to SPI slave nodes and not SPI slave mode.*
>

Yeah it's not always clear what these people are talking about. For
instance, peopel talking about using SPI Master mode using the inccorect
acronyms (SIMO, SOMI ) etc.

Master device -> MISO, MOSI
Slave device -> SIMO, SOMI

Is how I understand it's supposed to be . . .  anyway, good luck, and I'll
keep an eye out for anything useful.

On Tue, Nov 3, 2015 at 8:56 PM, John Syne  wrote:

> I think that link refers to SPI slave nodes and not SPI slave mode. There
> are a few postings on E2E related to SPI slave mode, but none seem to have
> achieve anything, or at least anything that they disclosed.
>
> My approach is to use Starterware to mock up a solution where I have McSPI
> and EDMA transferring data to a ping-pong buffer (DMA writes to one buffer
> while CPU processes the other buffer and then swap buffers at the end of
> each transfer). If I can achieve that then I should be able to implement
> the same solution in a device driver.
>
> Regards,
> John
>
>
>
>
> On Nov 3, 2015, at 7:33 PM, William Hermans  wrote:
>
> So, I was curious about this too, and decided to do some web searching . .
> . it seems there is a lot of talk about this going back since around 2009.
> Although it is unclear whether or not slave mode was ever achieved, some
> guy on the E2E forums claimed to have done it. Using DMA as well.
>
> But there is this:
>
> http://linux-kernel.2935.n7.nabble.com/PATCH-spi-spi-omap2-mcspi-c-Add-dts-for-slave-device-configuration-td622831.html
>
> And a bunch of other semi code related posts here and there that I can't
> make out if they're useful or not. It's kind of a wonder that any of these
> guys ever get anything done . . .
>
>
> On Tue, Nov 3, 2015 at 4:25 PM, Matthijs van Duin <
> matthijsvand...@gmail.com> wrote:
>
>> On 2 November 2015 at 19:02, John Syne  wrote:
>>
>>> I have been reading your posts and I am impressed with your detailed
>>> knowledge of the inner workings of the AM335x. Do you have any experience
>>> with using MCSPI as a slave and using EDMA. I’m using a high speed ADC that
>>> works as a SPI master (generates sclk). Since LInux has no support for SPI
>>> slave mode, my plan was create a driver that sets up MCSPI in slave mode
>>> and use EDMA to store measurements to a ping-pong buffer.
>>
>>
>> I don't have any experience with it yet, but it sounds like it should
>> work. McSPI even has an option to relocate the fifo port to a 32-byte
>> aligned address which is specifically added to allow you to use EDMA's
>> "FIFO mode" (aka "constant addressing" or "streaming burst"), which enables
>> it to slurp 16 or 32 bytes from the McSPI fifo with a single read.
>>
>> I'm not sure about the "ping-pong buffer" though, I'm not really familiar
>> with linux kernel programming but I think for incoming DMA it might be
>> better to allocate cache-cold pages? hmm, not sure how the reduced cache
>> activity would balance against the increase in bookkeeping... depends also
>> on what you intend to do with the received data, e.g. if you're going to
>> stuff it down a pipe towards userspace you probably want to hand over the
>> pages and need to allocate new ones anyway.
>>
>> Beware BTW that if SPI mode 0 or 2 is used, chip select is *required* to
>> be deasserted between transfers. No such restriction applies to SPI mode 1
>> or 3, and chip select is optional there.
>>
>> Depending on what exactly that adc is sending, there's also a (small)
>> chance you could interface it to McASP instead, which has a larger fifo and
>> some data reformatting options.
>>
>> --
>> 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.
>> 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.
> 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.
> 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 

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

[Matthijs van Duin]

On 4 November 2015 at 05:01, William Hermans  wrote:

> Where would be a good start to read up on uio ? I've been reading around,
> but have not found anything of much use yet.
>

The official doc is the UIO Howto
, but it's very
PCI-oriented. The basic assumption is that there are only a few irq lines
which are shared, hence even if you want to do most things in userspace a
tiny kernel driver is still needed to do whatever is necessary to get the
irq deasserted before delivering it to userspace. The uio kernel framework
is designed to facilitate that.

uio_pdrv_genirq is a simple uio driver which "handles" the irq simply by
disabling it (until reenabled by userspace), which requires that the irq
line isn't shared. This is fine since the AM335x doesn't use shared irq
lines, its interrupt controller for the cortex-A8 has 128 inputs.


> Also, that pastebin you gave, this is *everything* needed to use an uio
> adc ?
>

Yep. I don't think the device tree snippet works as overlay though, you may
need to add it to the main dts. (I never use overlays so I haven't tested
that.)


> But for instance, assuming the pastebin you gave is everything needed(
> which would be awesome ), how do I know how this adc uio "object" is set up
> ?
>

As the comment at the bottom says, /dev/uio/adc would appear.


> e.g. how would i write a userspace driver for it ?
>

open /dev/uio/adc, mmap() it (offset 0 size 4KB) to obtain access to its
registers. See TRM chapter 12 for usage (yes, "Touchscreen Controller",
that's the one).

If you want to receive interrupts, write (u32)1 to the fd to enable the
irq. When it occurs, the irq is disabled, the fd becomes readable and you
read an u32 from it (value will be 1).

A word of caution: once you've enabled the ADC, if you want to reconfigure
it, first disable all steps (set STEPENABLE to 0) and wait until it is idle
(check ADCSTAT register, STEP_ID and FSM_BUSY will both indicate idle).
Failure to do so can lock up the ADC state machine in a way that requires
reboot to clear. Most peripherals have some kind of reset functionality but
oddly the ADC does not.

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

Re: [beagleboard] Re: Slave McSPI with DMA

[William Hermans]

So, I was curious about this too, and decided to do some web searching . .
. it seems there is a lot of talk about this going back since around 2009.
Although it is unclear whether or not slave mode was ever achieved, some
guy on the E2E forums claimed to have done it. Using DMA as well.

But there is this:
http://linux-kernel.2935.n7.nabble.com/PATCH-spi-spi-omap2-mcspi-c-Add-dts-for-slave-device-configuration-td622831.html

And a bunch of other semi code related posts here and there that I can't
make out if they're useful or not. It's kind of a wonder that any of these
guys ever get anything done . . .


On Tue, Nov 3, 2015 at 4:25 PM, Matthijs van Duin  wrote:

> On 2 November 2015 at 19:02, John Syne  wrote:
>
>> I have been reading your posts and I am impressed with your detailed
>> knowledge of the inner workings of the AM335x. Do you have any experience
>> with using MCSPI as a slave and using EDMA. I’m using a high speed ADC that
>> works as a SPI master (generates sclk). Since LInux has no support for SPI
>> slave mode, my plan was create a driver that sets up MCSPI in slave mode
>> and use EDMA to store measurements to a ping-pong buffer.
>
>
> I don't have any experience with it yet, but it sounds like it should
> work. McSPI even has an option to relocate the fifo port to a 32-byte
> aligned address which is specifically added to allow you to use EDMA's
> "FIFO mode" (aka "constant addressing" or "streaming burst"), which enables
> it to slurp 16 or 32 bytes from the McSPI fifo with a single read.
>
> I'm not sure about the "ping-pong buffer" though, I'm not really familiar
> with linux kernel programming but I think for incoming DMA it might be
> better to allocate cache-cold pages? hmm, not sure how the reduced cache
> activity would balance against the increase in bookkeeping... depends also
> on what you intend to do with the received data, e.g. if you're going to
> stuff it down a pipe towards userspace you probably want to hand over the
> pages and need to allocate new ones anyway.
>
> Beware BTW that if SPI mode 0 or 2 is used, chip select is *required* to
> be deasserted between transfers. No such restriction applies to SPI mode 1
> or 3, and chip select is optional there.
>
> Depending on what exactly that adc is sending, there's also a (small)
> chance you could interface it to McASP instead, which has a larger fifo and
> some data reformatting options.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

[William Hermans]

Matthijs,

Where would be a good start to read up on uio ? I've been reading around,
but have not found anything of much use yet. Also, that pastebin you gave,
this is *everything* needed to use an uio adc ?

But for instance, assuming the pastebin you gave is everything needed(
which would be awesome ), how do I know how this adc uio "object" is set up
? e.g. how would i write a userspace driver for it ? I have so many
questions, but no idea where to start looking for answers . . .

On Tue, Nov 3, 2015 at 8:49 PM, Matthijs van Duin  wrote:

> On 4 November 2015 at 03:40, Pierre-Louis Constant 
> wrote:
>
>> you guys provided me enough info leads for a whole year of insomnia.
>>
>
> haha, sorry :-)
>
>
>> Correct, pretty much anything can be used from userspace like that,
>>> although some people will frown at you for bypassing the kernel if you do.
>>
>>
>> Righteo, so far I was using the somewhat slow (but easy) way thyrough FS,
>> however I am stuck with running my program as root, as I can't access the
>> PWM (or hardware) as normal user. Using the mmap() method would be
>> permission free, would it ?
>>
>
> other way around: you can simply change owner/group/permissions in sysfs
> if you want to (although obviously it won't persist across reboots, hence
> would need to be done e.g. in an udev rule).
>
> /dev/mem however always requires root permissions to open. You can of
> course open it and then drop permissions (and close the descriptor after
> mmapping the regions you need). The same is true for other files and
> devices of course, including sysfs files.
>
> uio is the cleanest here: the pastebin I linked to actually included an
> example udev rule for setting group and permissions.
>
> sysfs files aren't devices hence you can't set their permissions in the
> same way but need to do something ugly like RUN="/bin/chmod ...". It's
> still wise to do it in an udev rule rather than a fixed startup script
> since it may run too early and the files may not exist yet.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Slave McSPI with DMA

[John Syne]

Thanks William.

Regards,
John




> On Nov 3, 2015, at 8:05 PM, William Hermans  wrote:
> 
> I think that link refers to SPI slave nodes and not SPI slave mode.
> 
> Yeah it's not always clear what these people are talking about. For instance, 
> peopel talking about using SPI Master mode using the inccorect acronyms 
> (SIMO, SOMI ) etc. 
> 
> Master device -> MISO, MOSI
> Slave device -> SIMO, SOMI
> 
> Is how I understand it's supposed to be . . .  anyway, good luck, and I'll 
> keep an eye out for anything useful.
> 
> On Tue, Nov 3, 2015 at 8:56 PM, John Syne  > wrote:
> I think that link refers to SPI slave nodes and not SPI slave mode. There are 
> a few postings on E2E related to SPI slave mode, but none seem to have 
> achieve anything, or at least anything that they disclosed. 
> 
> My approach is to use Starterware to mock up a solution where I have McSPI 
> and EDMA transferring data to a ping-pong buffer (DMA writes to one buffer 
> while CPU processes the other buffer and then swap buffers at the end of each 
> transfer). If I can achieve that then I should be able to implement the same 
> solution in a device driver. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 3, 2015, at 7:33 PM, William Hermans > > wrote:
>> 
>> So, I was curious about this too, and decided to do some web searching . . . 
>> it seems there is a lot of talk about this going back since around 2009. 
>> Although it is unclear whether or not slave mode was ever achieved, some guy 
>> on the E2E forums claimed to have done it. Using DMA as well.
>> 
>> But there is this:
>> http://linux-kernel.2935.n7.nabble.com/PATCH-spi-spi-omap2-mcspi-c-Add-dts-for-slave-device-configuration-td622831.html
>>  
>> 
>> 
>> And a bunch of other semi code related posts here and there that I can't 
>> make out if they're useful or not. It's kind of a wonder that any of these 
>> guys ever get anything done . . .
>> 
>> 
>> On Tue, Nov 3, 2015 at 4:25 PM, Matthijs van Duin > > wrote:
>> On 2 November 2015 at 19:02, John Syne > > wrote:
>> I have been reading your posts and I am impressed with your detailed 
>> knowledge of the inner workings of the AM335x. Do you have any experience 
>> with using MCSPI as a slave and using EDMA. I’m using a high speed ADC that 
>> works as a SPI master (generates sclk). Since LInux has no support for SPI 
>> slave mode, my plan was create a driver that sets up MCSPI in slave mode and 
>> use EDMA to store measurements to a ping-pong buffer. 
>> 
>> I don't have any experience with it yet, but it sounds like it should work. 
>> McSPI even has an option to relocate the fifo port to a 32-byte aligned 
>> address which is specifically added to allow you to use EDMA's "FIFO mode" 
>> (aka "constant addressing" or "streaming burst"), which enables it to slurp 
>> 16 or 32 bytes from the McSPI fifo with a single read.
>> 
>> I'm not sure about the "ping-pong buffer" though, I'm not really familiar 
>> with linux kernel programming but I think for incoming DMA it might be 
>> better to allocate cache-cold pages? hmm, not sure how the reduced cache 
>> activity would balance against the increase in bookkeeping... depends also 
>> on what you intend to do with the received data, e.g. if you're going to 
>> stuff it down a pipe towards userspace you probably want to hand over the 
>> pages and need to allocate new ones anyway.
>> 
>> Beware BTW that if SPI mode 0 or 2 is used, chip select is required to be 
>> deasserted between transfers. No such restriction applies to SPI mode 1 or 
>> 3, and chip select is optional there.
>> 
>> Depending on what exactly that adc is sending, there's also a (small) chance 
>> you could interface it to McASP instead, which has a larger fifo and some 
>> data reformatting options.
>> 
>> -- 
>> 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 
>> .
>> 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 
>> 

Re: [beagleboard] anyone have mainline drivers/staging/fbtft working?

[Robert Nelson]

On Tue, Nov 3, 2015 at 10:15 PM, Drew Fustini  wrote:
> I'm trying to build bb-kernel am33x-v4.0 but a patch conflict occurs:
>
>   CONFLICT (content): Merge conflict in include/linux/compiler-gcc.h
>   Patch failed at 0052 overflow-arith: begin to add support for
> overflow builtin functions
>
> Full log: https://gist.github.com/pdp7/73eb4857d38054ebcf9f
>
> I can do a fresh git clone of bb-kernel (which takes quite awhile), so
> I'm wondering if this is a problem for "just me".

Just try re-checking out the branch..

git reset HEAD --hard
git checkout master -f
git branch -D (current one)
git checkout origin/am33x-v4.0 -b tmp

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

Re: [beagleboard] Re: Poor Java performance on new BBB

[Fohnbit]

Hi Robert,

thank you!!
I made:
sudo apt-get install linux-image-3.8.13-bone67

Now the Java application are working with 40ms ... seems really the kernel 
was the problem.

Thanks again!

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

Re: [beagleboard] Re: Poor Java performance on new BBB

[Fohnbit]

Hi Robert,

thank you!!
I made:
sudo apt-get install linux-image-3.8.13-bone67

Now the Java application are working with 40ms ... seems really the kernel 
was the problem.

Thanks again!

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

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

[Matthijs van Duin]

On 4 November 2015 at 07:06, Matthijs van Duin 
wrote:

> See TRM chapter 12 for usage (yes, "Touchscreen Controller", that's the
> one).


You can also peek at my header: http://gerbil.xs4all.nl/adc.h (the headers
it depends on can be found in https://github.com/dutchanddutch/jbang )

My code is in a bit eccentric style of C++14 though :P  but even if you
don't use it directly the comments in it may be useful.

Word of caution: if you do use it; since I don't make any config registers
volatile (it doesn't really work with bitfields anyway) you need an
occasional compiler barrier to avoid reordering, e.g. between setting the
configuration and enabling it. You can #include  and use
write_barrier(adc); (or write_barrier(*adc) if it's a pointer rather than a
reference)

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

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

[Matthijs van Duin]

On 4 November 2015 at 07:34, Matthijs van Duin 
wrote:

> #include 


sorry, #include "util/device.h"
it's obviously not a system header (but also one you can find in jbang)

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

Re: [beagleboard] BBB won't boot up (PWR Led does a single quick blink)

[mahesh ingle]

Many Thanks Gerald, I got response to my RMA request this time. In fact I 
received response to all my earlier RMA request as well. 


Cheers 
Mahesh

On Tuesday, October 27, 2015 at 7:37:52 PM UTC+5:30, Gerald wrote:
>
> Try the RMA again.
>
> Gerald
>
>
> On Tue, Oct 27, 2015 at 6:51 AM, mahesh ingle  > wrote:
>
>> Hi, 
>>
>> I Also have exactly same behavior with my Rev C BBB. 
>>
>> @Gerald: I tried RMA twice but i did not got any response !! I got the 
>> Board from Sumeet Online shop which is listed on beagleboard.org for 
>> Indian buyers.  Any thoughts?
>>
>>
>> Thanks & Regards
>> Mahesh 
>>
>>
>> On Wednesday, November 5, 2014 at 2:29:00 AM UTC+5:30, Shu Liu wrote:
>>>
>>> Hi,
>>>
>>> There should be a short on board. The U2 shuts itself down to prevent 
>>> the high current draw which is caused by the short. That is why the LED 
>>> goes off after it blinks once.
>>>
>>> Regards,
>>> Shu
>>>
>>> On Monday, October 27, 2014 10:56:34 PM UTC-5, s...@kopi-d.com wrote:

 I am in the same situation.  Was trying out new images.  Did an forced 
 SD change to a non-bootable bbb. Now it won't boot.  Just a pwr blink then 
 dead. 

 Are there any other ways to recover other than RMA?  PMIC replacement 
 or reflashing of bootloader?

 Sam

 On Wednesday, June 18, 2014 9:53:25 PM UTC+8, Gerald wrote:
>
> Request an RMA.
>
> http://beagleboard.org/Support/RMA
>
> And read this. 
> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Hardware
>
> Gerald
>
>
> On Mon, Jun 9, 2014 at 5:54 PM,  wrote:
>
>> My BBB (A5A) was working fine with ARM Arch (installed on the eMMC), 
>> but since yesterday it won't turn on. I don't know what changed.
>>
>> When I plug the power source or the USB cable the PWR Led quickly 
>> blinks, but the board doesn't turn on. 
>> If I press the POWER button, the PWR led does a single blink too, but 
>> it doesn't proceed to boot.
>>
>> I also tried to boot from the SD card, but It didn't work.
>>
>> -- 
>> 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...@googlegroups.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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
>

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

[beagleboard] Looking for SPI Salve configuration and sample code for testing on BBB with kernel 3.8.13

[ravi . hpv]

Hi ALL,

Please provide your support on this BBB SPI slave configuration and sample 
code for kernel 3.8.13 .

I have done Master mode communication  with slave memory device, but i want 
to communication with two BBB. one is mater and another is salve device.

I guess present kernel doesn't support slave mode but i don't know kernel 
modification to change master to salve mode.

Please provide your valuable inputs to me.

Thank you in advance

Regards
Ravi 

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

Re: [beagleboard] Re: Poor Java performance on new BBB

[Robert Nelson]

On Tue, Nov 3, 2015 at 8:34 AM, Fohnbit  wrote:
> Hi Robert,
>
> sorry for asking again!
>
> Did you see a way to downgrade the kernel?

yes.. via apt:

sudo apt-get update

sudo apt-get install linux-image-3.8.13-bone63

bone73-> bone74, bone76 -> bone79

(not sure what happened to bone75..)

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

Re: [beagleboard] kernel updates thread

[Drew Fustini]

On Nov 2, 2015 1:34 PM, "Robert Nelson"  wrote:
>
> 4.1.12-ti-r26

How can I compile that from source?

I've been using your wonderful bb-kernel repo but didn't see any branches
or tags a with 'ti' in the name.

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

[beagleboard] Understanding the whole Yocto/Linux stack for the BB

[Baptiste]

Hello,

 

I’m using a BeagleBone as a base to develop a custom board. I’ve read pages 
and pages of doc and I feel I need some highlights to make sense of it all. 
Note that I’m mainly trying to understand the custom Linux distribution 
workflow at the lowest level here, for instance to be able to recreate from 
scratch the OE BeagleBoard stack… and I’m confused by all the available 
resources.


So, here is my question spree to shed some light on these matters, not 
necessarily specific to the BeagleBone but it's a great platform to 
understand it all. Feel free to contribute even if you don’t have all the 
answers.


I don’t understand why is the meta-beagleboard layer that huge. First, why 
is it using the kernel 3.8 where the meta-ti layer supports 4.1? (is 
meta-beagleboard depending on meta-ti in the first place, and if not, why? 
There are references to the BB in the meta-ti tree, why is an other layer 
even needed?) What's the difference with the layer meta-bbb?

Then, why is recipes-kernel so full of all kind of patches? Where do those 
come from, why does the kernel need so much patching? Then, if those 
patches are here to “fix” the mainline kernel for the BB, what is exactly 
the RobertCNelson/bb-kernel repo? And the beagleboard/linux repo? What’s 
the relationship between all those projects?


Also, I’ve read the DeviceTree story, but it seems that the actual 
BeagleBone DTS is in the kernel 
(arch/arm/boot/dts/am335x-bone-common.dtsi)... yet I thought the whole 
point of the DTS transition was not to add all ARM board files to the 
kernel. Moreover, many mach-omap2/ and DTS files are patched in bb-kernel 
and in meta-beagleboard... is it just because they’ve not been merged back 
to mainline yet?

When it comes to customizing the DTS, I’ve seen for instance a reference to 
https://github.com/bradfa/beaglebone_pinmux_tables/blob/master/beaglebone_pins_p8
 
or https://github.com/jadonk/bonescript/blob/master/src/bone.js to find out 
the actual pin numbers. How are these files have even been generated?


I know I am mixing up different concepts here but they all coexist in the 
different docs… so I thought I’d give it a try here. Some resources 
clearing that up would be great too.


Thank you for any clue that’ll help me to see through this forest!
Baptiste

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

Re: [beagleboard] Understanding the whole Yocto/Linux stack for the BB

[Robert Nelson]

On Tue, Nov 3, 2015 at 9:56 AM, Baptiste  wrote:
> Hello,
>
>
>
> I’m using a BeagleBone as a base to develop a custom board. I’ve read pages
> and pages of doc and I feel I need some highlights to make sense of it all.
> Note that I’m mainly trying to understand the custom Linux distribution
> workflow at the lowest level here, for instance to be able to recreate from
> scratch the OE BeagleBoard stack… and I’m confused by all the available
> resources.
>
>
> So, here is my question spree to shed some light on these matters, not
> necessarily specific to the BeagleBone but it's a great platform to
> understand it all. Feel free to contribute even if you don’t have all the
> answers.
>
>
> I don’t understand why is the meta-beagleboard layer that huge. First, why
> is it using the kernel 3.8 where the meta-ti layer supports 4.1? (is
> meta-beagleboard depending on meta-ti in the first place, and if not, why?
> There are references to the BB in the meta-ti tree, why is an other layer
> even needed?) What's the difference with the layer meta-bbb?

"meta-beagleboard" has been 'un-maintained' for over a year now
(actually 2 years..), consider it dead...

> Then, why is recipes-kernel so full of all kind of patches? Where do those
> come from, why does the kernel need so much patching? Then, if those patches
> are here to “fix” the mainline kernel for the BB, what is exactly the
> RobertCNelson/bb-kernel repo? And the beagleboard/linux repo? What’s the
> relationship between all those projects?

It depends on the branch...

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v3.8 ->
beagleboard/linux (3.8)

https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-3.14.y
 ->  beagleboard/linux (3.14)

https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.1.y
-> beagleboard/linux (4.1)


> Also, I’ve read the DeviceTree story, but it seems that the actual
> BeagleBone DTS is in the kernel
> (arch/arm/boot/dts/am335x-bone-common.dtsi)... yet I thought the whole point
> of the DTS transition was not to add all ARM board files to the kernel.
> Moreover, many mach-omap2/ and DTS files are patched in bb-kernel and in
> meta-beagleboard... is it just because they’ve not been merged back to
> mainline yet?

Yet again, 3.8 was over two years ago..  Look again at the "v4.3.0" kernel..

>
> When it comes to customizing the DTS, I’ve seen for instance a reference to
> https://github.com/bradfa/beaglebone_pinmux_tables/blob/master/beaglebone_pins_p8
> or https://github.com/jadonk/bonescript/blob/master/src/bone.js to find out
> the actual pin numbers. How are these files have even been generated?
>
>
> I know I am mixing up different concepts here but they all coexist in the
> different docs… so I thought I’d give it a try here. Some resources clearing
> that up would be great too.

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

Re: [beagleboard] kernel updates thread

[Robert Nelson]

On Tue, Nov 3, 2015 at 10:12 AM, Drew Fustini  wrote:
> On Nov 2, 2015 1:34 PM, "Robert Nelson"  wrote:
>>
>> 4.1.12-ti-r26
>
> How can I compile that from source?
>
> I've been using your wonderful bb-kernel repo but didn't see any branches or
> tags a with 'ti' in the name.

It's located here:

https://github.com/RobertCNelson/ti-linux-kernel-dev

BUT... it's between two moving targets, "v4.1.x lts" and ti's v4.1.x
branch, so you can branch to that commit, but it's probally already
broken..

Best to just stick on the top of the v4.1.x branch, or build using the
github.com/beagleboard/linux src

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

[beagleboard] Re: Is it possible to shutdown Main CPU but keep PRU running?

[Stefan St]

Hello Matthijs van Duin,

Thank you very much for taking your time and answereing my this detailed 
and precise!

Everything you wrote was very interesting and I used the information as 
keywords for further investigations.

Unfortunetly I think I am far away from beeing advanced enough for some of 
this. But I will try to get there.

Thx a lot!

Stefan

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

Re: [beagleboard] Re: Poor Java performance on new BBB

[Fohnbit]

Hi Robert,

sorry for asking again!

Did you see a way to downgrade the kernel?

Thank you!

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