Re: [beagleboard] Ethernet not working with debian stretch 4.14.67-ti-r73

[smith . winston . 101]

On Friday, September 7, 2018 at 12:43:22 AM UTC-4, smith.wi...@gmail.com 
wrote:
>
> On Thursday, September 6, 2018 at 5:48:39 PM UTC-4, smith.wi...@gmail.com 
> wrote:
>
>>
>> Just for sanity I will rebuild the rcn-ee_console_debian_stretch_armhf 
>> but with a flasher and retry that.
>>
>
> I rebuilt from scratch and generated an eMMC flasher, installed and I get 
> the same results as with USB mass-storage flashing.
>
>
> I noticed that the fast-blink of the green LED starts almost at power up, 
> which is odd and makes me think it's a u-boot or dtb issue?  Here's the 
> compete output from power up to login prompt:
>

I got a new beagle bone and it looks like it was a h/w problem on the old 
one (after finding both stretch & jessie images doing the same thing ... I 
was beginning to wonder, so I ordered a new BBB).

Very annoying ...!  that's 3 BBBs I have gone through in this USB flashing 
saga.  2 just stopped powering up and this one acting weird.

Sorry for the alarm.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/276efa13-0332-411a-aac6-a9042943d6b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ethernet not working with debian stretch 4.14.67-ti-r73

[smith . winston . 101]

On Friday, September 7, 2018 at 12:43:22 AM UTC-4, smith.wi...@gmail.com 
wrote:
>
>
> Next up, I'll retry without btrfs (i.e. omitting the --rootfs btrfs on 
> the sdcard_setup step).
>

FWIW: Without btrfs, I see the same network problems.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6b9a7f34-e1fd-492f-9eb5-f3e2edc219dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ethernet not working with debian stretch 4.14.67-ti-r73

[smith . winston . 101]

On Thursday, September 6, 2018 at 5:48:39 PM UTC-4, smith.wi...@gmail.com 
wrote:

>
> Just for sanity I will rebuild the rcn-ee_console_debian_stretch_armhf but 
> with a flasher and retry that.
>

I rebuilt from scratch and generated an eMMC flasher, installed and I get 
the same results as with USB mass-storage flashing.


I noticed that the fast-blink of the green LED starts almost at power up, 
which is odd and makes me think it's a u-boot or dtb issue?  Here's the 
compete output from power up to login prompt:

U-Boot SPL 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)
Trying to boot from MMC2
Loading Environment from EXT4... Card did not respond to voltage select!
** Bad device mmc 0 **
Failed (-5)


U-Boot 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500), Build: 
jenkins-github_Bootloader-Builder-47

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4... Card did not respond to voltage select!
** Bad device mmc 0 **
Failed (-5)
Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[00C0] ...
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
2102 bytes read in 32 ms (63.5 KiB/s)
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.14.67-ti-r73 ...
10379776 bytes read in 679 ms (14.6 MiB/s)
loading /boot/dtbs/4.14.67-ti-r73/am335x-boneblack.dtb ...
60317 bytes read in 61 ms (964.8 KiB/s)
uboot_overlays: add [enable_uboot_overlays=1] to /boot/uEnv.txt to enable...
loading /boot/initrd.img-4.14.67-ti-r73 ...
4530206 bytes read in 315 ms (13.7 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=btrfs 
rootwait coherent_pool=1M net.ifnames=0 quiet] ...
debug: [bootz 0x8200 0x8808:45201e 0x8800] ...
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Ramdisk to 8fbad000, end 801e ... OK
   Loading Device Tree to 8fb9b000, end 8fbacb9c ... OK

Starting kernel ...

[0.000760] timer_probe: no matching timers found
[0.542293] dmi: Firmware registration failed.
[1.036826] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[1.253210] dmi-sysfs: dmi entry is absent.
[1.285511] omap_voltage_late_init: Voltage driver support not added
[1.595720] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: no source 
widget found for Playback
[1.604591] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: Failed to 
add route Playback -> direct -> TX

Debian GNU/Linux 9 arm ttyS0

rcn-ee.net console Debian Image 2018-09-06

Support/FAQ: http://elinux.org/BeagleBoardDebian

default username:password is [debian:temppwd]

arm login: 
 

Next up, I'll retry without btrfs (i.e. omitting the --rootfs btrfs on the 
sdcard_setup step).

Thanks!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d1f33255-1170-4449-b219-863609c60c00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ethernet not working with debian stretch 4.14.67-ti-r73

[smith . winston . 101]

On Thursday, September 6, 2018 at 5:18:07 PM UTC-4, RobertCNelson wrote:
>
>
> Just to confirm details, please restate the steps you did from the output 
> of the image builder script to sdcard.
>

Sure!

This is based on a pull of github.com/beagleboard/image-builder over the 
long weekend (which I think hasn't changed since):

time ./RootStock-NG.sh -c rcn-ee_console_debian_stretch_armhf
cd debian-9.5-console-armhf-2018-09-06
sudo ./setup_sdcard.sh --img-4gb 
../BBB-eMMC-debian-9.5-console-armhf-2018-09-06 --dtb beaglebone 
--enable-systemd --bbb-old-bootloader-in-emmc --rootfs btrfs

Now the flashing part is a bit odd but I don't think it is part of the 
problem (since I saw the same issue when installing via a flasher).  I'm 
using a variant of BBBlfs and the SPL/uboot binaries from 
https://github.com/ravikp7/node-beagle-boot to boot the BBB into USB Mass 
Storage mode and then mount the eMMC as /dev/sda, Finally, I dd the image 
to /dev/sda, mount /dev/sda1 and fix /etc/fstab (otherwise it won't boot!).

Just for sanity I will rebuild the rcn-ee_console_debian_stretch_armhf but 
with a flasher and retry that.

Thanks!

-W

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/00c6c517-18c4-4353-9dae-999eae7a5258%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Ethernet not working with debian stretch 4.14.67-ti-r73

[smith . winston . 101]

I built a debian stretch image (with 4.14.67-ti-r73) kernel using the 
current image-builder -- I used the rcn-ee_console_debian_stretch_armhf 
configuration.

Once I've flashed it, when it comes up, I notice the green LED on the 
ethernet is blinking quickly.  Once it comes up, it ends up with a 
self-assigned IP, but eventually picks up a DHCP address.  Seems like it's 
dropping a lot of packets ... cannot SSH into it and ping shows 
intermittent results.

Nothing obviously wrong in dmesg, here's the tail end:

...
[   13.534669] nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
[   15.044026] net eth0: initializing cpsw version 1.12 (0)
[   15.116989] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver 
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
[   15.146311] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   17.152982] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full - 
flow control off
[   17.153073] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   17.361787] 8021q: 802.1Q VLAN Support v1.8
[   17.361874] 8021q: adding VLAN 0 to HW filter on device eth0
[   23.030864] random: crng init done
[   23.030890] random: 7 urandom warning(s) missed due to ratelimiting
[   32.941240] systemd[1]: apt-daily.timer: Adding 3h 18min 33.058208s 
random time.
[   33.917355] systemd[1]: apt-daily.timer: Adding 5h 56min 18.925035s 
random time.
[   37.074459] device-mapper: uevent: version 1.0.3
[   37.075002] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: 
dm-de...@redhat.com
[   44.261128] using random self ethernet address
[   44.261148] using random host ethernet address
[   44.301103] using random self ethernet address
[   44.301123] using random host ethernet address
[   44.420543] usb0: HOST MAC b0:d5:cc:xx:xx:xx
[   44.424277] usb0: MAC b0:d5:cc:xx:xx:xx
[   44.431951] usb1: HOST MAC b0:d5:cc:xx:xx:xx
[   44.432459] usb1: MAC b0:d5:cc:xx:xx:xx
[   44.790231] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[   44.907574] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[   46.432911] systemd[1]: apt-daily.timer: Adding 3h 49min 1.211334s 
random time.
[   47.095854] net eth0: initializing cpsw version 1.12 (0)
[   47.185601] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver 
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
[   47.201861] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   47.201883] 8021q: adding VLAN 0 to HW filter on device eth0
[   49.216703] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full - 
flow control off
[   49.216810] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

root@arm:/home/debian# ip addr show eth0
2: eth0:  mtu 1500 qdisc mq state 
UP group default qlen 1000
link/ether b0:d5:cc:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 169.254.180.191/16 brd 169.254.255.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::b2d5:ccff:fexx:/64 scope link 
   valid_lft forever preferred_lft forever

root@arm:/home/debian# uname -a
Linux arm 4.14.67-ti-r73 #1 SMP PREEMPT Thu Aug 30 00:08:52 UTC 2018 armv7l 
GNU/Linux


I mostly want to try out btrfs as a filesystem (to avoid corruption) and 
possibly use the overlayroot, but it seems I need stretch for that.  Note 
that I've tried the 4.4 kernel version with the same results, so I guess 
it's either something in stretch, or a dtb issue.

Any ideas???

Thanks!

-W

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9b152d9a-ced2-4de9-a337-9675a1cfc9db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian jessie (4.4.113-ti-r148) boots to rescue mode when cape attached (u-boot 2018.03+rootwait 1?)

[smith . winston . 101]

On Sunday, April 8, 2018 at 1:03:57 PM UTC-4, RobertCNelson wrote:

> Ah, you found a fun bug in the old path..  I'll fix it up for the next 
> person, but you can go down the new path with your setup... 
>
> [snip...]
>
> in /boot/uEnv.txt 
>
> remove your: dtb=am335x-boneblack-emmc-overlay.dtb 
>
> Then set: 
>
> enable_uboot_overlays=1 
> disable_uboot_overlay_video=1 
>

Making this change solved it.  I updated my bb_ble_image.sh script to add 
--enable-uboot-cape-overlays and move from --dtb beaglebone-nohdmi to --dtb 
beagblebone.  However, I couldn't see a way when invoking setup_sdcard.sh 
to set disable_uboot_overlay_video=1 in uEnv.txt via the command line.  So 
I made the following change to add a custom --disable-uboot-overlay-video 
option to setup_sdcard.sh (which temporarily helps me out in this case!):

diff --git a/tools/setup_sdcard.sh b/tools/setup_sdcard.sh
index 9d86f92..b9de76e 100755
--- a/tools/setup_sdcard.sh
+++ b/tools/setup_sdcard.sh
@@ -1266,7 +1266,11 @@ populate_rootfs () {
echo "###" >> ${wfile}
echo "###Disable auto loading of virtual capes 
(emmc/video/wireless/adc)" >> ${wfile}
echo "#disable_uboot_overlay_emmc=1" >> ${wfile}
-   echo "#disable_uboot_overlay_video=1" >> ${wfile}
+   if [ "x${uboot_overlay_video}" = "xdisable" ] ; then
+   echo "disable_uboot_overlay_video=1" >> 
${wfile}
+   else
+   echo "#disable_uboot_overlay_video=1" >> 
${wfile}
+   fi
echo "#disable_uboot_overlay_audio=1" >> ${wfile}
echo "#disable_uboot_overlay_wireless=1" >> ${wfile}
echo "disable_uboot_overlay_adc=1" >> ${wfile}
@@ -2041,6 +2045,9 @@ while [ ! -z "$1" ] ; do
--enable-uboot-pru-rproc-414ti)
uboot_pru_rproc_414ti="enable"
;;
+   --disable-uboot-overlay-video)
+   uboot_overlay_video="disable"
+   ;;
--efi)
uboot_efi_mode="enable"
;;

With this I now have an eMMC flasher image that creates the correct 
/boot/uEnv.txt after flashing.

Please let me know if there is a better way to disable video (I just need a 
cmd line option vs whitelisting), there are other options that you might 
want to control (e.g. audio, adc etc) so maybe a more generalized version 
of this would be a nice enhancement.

Many thanks!


-W
 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d3c65884-36b9-4611-8796-cacdf69683af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Debian jessie (4.4.113-ti-r148) boots to rescue mode when cape attached (u-boot 2018.03+rootwait 1?)

[smith . winston . 101]

I have a custom .conf for image-builder that's based on the beaglebone 
ones, except that I have a handful of extra packages and copy some extra 
files into the image.  Periodically, I update this against 
image-builder:master.  I've been using jessie with a 4.4 kernel for a while 
quite successfully, I just updated the other day and now my flashed images 
won't boot properly if the cape is attached.  If I detach the cape & boot, 
all is fine.

*With* the cape attached, it boots into the rescue-service, but journalctl 
-xb shows no [obvious!] errors.  I can actually continue the boot and get 
to a normal state if I enter systemctl default from the rescue-shell.

After some debugging (hard to attach USB-serial when there's a cape 
attached!), I think i have it narrowed down.  In comparing the boot output, 
the u-boot command line seems to be getting an extra "1" after rootwait 
when the cape is on, but not otherwise.  I'm guessing that perhaps this 
stray "1" causes systemd to fail to load the "target" and so it goes to 
rescue-mode.  I'm guessing this "1" comes from u-boot?  The u-boot version 
is set in the chroot/beagleboard.org-jessie.sh script as follows:

u_boot_release="v2018.03"

With the cape:

debug: [console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait 
1 coherent_pool=1M net.ifnames=0] ...
debug: [bootz 0x8200 0x8808:5363d1 0x8800] ...

Without the cape:

debug: [console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0] ...
debug: [bootz 0x8200 0x8808:5363d1 0x8800] ...


This is the *only* difference in the boot sequence until it gets to the 
point where the rescue-service starts with the cape attached.  The cape is 
pretty simple, it's a BTLE module that is connected to ttyO5 with a couple 
of GPIOs for resetting etc. (and it has worked just fine with previous 
image-builder incarnations). Oh, I also use --dtb beaglebone-nohdmi when 
building the image.

FWIW, here's the full boot sequence with the cape attached (note: in this 
run I moved the .dtbo file from /lib/firmware while debugging, but it does 
the same with it in place):

U-Boot SPL 2018.03-2-g254339602c (Mar 16 2018 - 12:36:44 -0500)
Trying to boot from MMC2
Loading Environment from EXT4... Card did not respond to voltage select!
** Bad device mmc 0 **
Failed (-5)


U-Boot 2018.03-2-g254339602c (Mar 16 2018 - 12:36:44 -0500), Build: 
jenkins-github_Bootloader-Builder-42

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4... Card did not respond to voltage select!
** Bad device mmc 0 **
Failed (-5)
Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
debug: process_cape_part_number:[BB-BLE]
debug: process_cape_part_number:[42422D424C45]
BeagleBone: cape eeprom: i2c_probe: 0x54: /lib/firmware/BB-BLE-00A0.dtbo 
[0x1a9643f]
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[00C0] ...
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
814 bytes read in 15 ms (52.7 KiB/s)
Loaded environment from /boot/uEnv.txt
debug: [dtb=am335x-boneblack-emmc-overlay.dtb] ...
Using: dtb=am335x-boneblack-emmc-overlay.dtb ...
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.4.113-ti-r148 ...
9447320 bytes read in 614 ms (14.7 MiB/s)
loading /boot/dtbs/4.4.113-ti-r148/am335x-boneblack-emmc-overlay.dtb ...
60416 bytes read in 34 ms (1.7 MiB/s)
uboot_overlays: add [enable_uboot_overlays=1] to /boot/uEnv.txt to enable...
loading /boot/initrd.img-4.4.113-ti-r148 ...
5465041 bytes read in 361 ms (14.4 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait 
1 coherent_pool=1M net.ifnames=0] ...
debug: [bootz 0x8200 0x8808:5363d1 0x8800] ...
## Flattened Device Tree blob at 8800
   Booting usi

[beagleboard] 46x2 0.1" header ZIF socket?

[smith . winston . 101]

I'm looking for something where I can "drop in" a cape for testing and 
flashing the CAT24C256 eeprom that has little to no insertion/removal force 
-- there's a lot of friction with the BBB headers and I keep bending the 
pins etc. when removing the capes).

Has anyone come across a 46x2 0.1" Zero Insertion Force (ZIF) type socket? 
 All of the ZIF type sockets I've found so far are for ICs, not headers.

Thanks!


-W.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/44644ddb-c329-4b79-a67b-cd2bf920519b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone/Element 14 Data Matrix barcode stickers

[smith . winston . 101]

On Monday, April 25, 2016 at 4:55:47 PM UTC-4, Gerald wrote:
>
> Best bet would be to ask on the E14 forums what it means. 
>

Thanks, it looks almost identical to the data matrix on the bottom of a RPi 
Model B+ (I think also made by Element14).

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bfe8048f-db09-4ce5-84c0-2ac9b5d0296a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone/Element 14 Data Matrix barcode stickers

[smith . winston . 101]

At some point recently, the newer Beaglebone Blacks (made by Element 14) 
have swapped out the older barcode for a small data matrix code sticker. 
 Previously, the barcode looked like it was the same or similar to the 
serial number, but now the numbers on the datamatrix code don't seem to 
mean anything; they're all decimal digits of the following form (it's 
actually printed on the sticker in tiny type):

4n 1nnn 0n 1nnn

Anyone got any ideas what might be encoded in that?  I'm guessing just some 
internal manufacturing identifier.

It would've been nice if it was something obvious like the serial number, 
MAC address and a manufacturing date!

Thanks!


-W

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/eb6c2b8c-9851-40ef-8bea-63ede1314d0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB/jessie/4.1.10-ti-r21 -- bone_capemgr: loader: failed to load slot-0 BB-SERIAL:00A0 (prio 0)

[smith . winston . 101]

On Wednesday, October 14, 2015 at 11:16:28 PM UTC-4, RobertCNelson wrote:

>
> This isn't an issue anymore.. Make sure your *.dtbo is under 
> /lib/firmware then run: 
>
> sudo update-initramfs -uk `uname -r` 
>
> to make sure the *.dtbo get's copied to the intrd. (it'll still read 
> it from the /lib/firmware) 


Magic!  That resolved it.

Many thanks


-W

-- 
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] BBB/jessie/4.1.10-ti-r21 -- bone_capemgr: loader: failed to load slot-0 BB-SERIAL:00A0 (prio 0)

[smith . winston . 101]

I'm trying to sync up with the latest & greatest image-builder work by 
Robert Nelson.  So far so good, I have my debian jessie 4.1.10-ti-r21 BBB 
image built and flashed; I've converted my .dts *back* into an overlay for 
the 4.1 capemgr with the kernels.

The cape EEPROM is properly flashed, but while capemgr detects it, it 
doesn't seem to be able to load the BB-SERIAL-00A0.dtbo located in 
/lib/firmware:

[3.588753] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,0A6A,BBBK'
[3.588789] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[3.632229] bone_capemgr bone_capemgr: slot #0: 'Serial Util 
Board,00A0,WinstonSmith,BB-SERIAL'
[3.688184] bone_capemgr bone_capemgr: slot #1: No cape found
[3.748178] bone_capemgr bone_capemgr: slot #2: No cape found
[3.808177] bone_capemgr bone_capemgr: slot #3: No cape found
[3.814213] bone_capemgr bone_capemgr: initialized OK.
...
[4.838440] bone_capemgr bone_capemgr: loader: failed to load slot-0 
BB-SERIAL:00A0 (prio 0)
[9.857097] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
mode. Opts: (null)

Basically, the .dts simply enables UART1,2,4,5 and a DS1307 RTC.

I know the .dts is ok as I can manually load the .dtbo with:

echo 'BB-SERIAL' > /sys/devices/platform/bone_capemgr/slots

But I can't get it to automatically load, I've tried the EEPROM detection, 
adding it to uEnv.txt and even /etc/default/capemgr (which used to be the 
only solution for 3.8).

Back in the 3.8 days, there was an issue with the root filesystem not being 
mounted when the capemgr did it's detection ... is this still an issue (see 
last line of dmesg output above -- I did try adding rootwait to the kernel 
cmdline).  In 3.8, this was easily resolved by adding CAPE=BB-SERIAL to the 
/etc/default/capemgr (which doesn't seem to work now).

Any ideas?


-W

-- 
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: Multiple 1-Wire Pins

[smith . winston . 101]

On Wednesday, April 8, 2015 at 6:10:48 PM UTC-4, Clark Leach wrote:

> If it were me, I would interface to the 1-wire bus with one of the handy 
> interface devices available from Maxim.  The DS2482-100 and DS2482-800 are 
> I2C to 1-wire and I2C to 1-wire X 8 interfaces respectively.
>

The DS2482 series work really well, letting it manage the 1-wire bus (or 8 
of them for the -800 version) and communicating with it via I2C is a good 
strategy and very easy to implement in software.  Here's an old blog post 
about doing this with an Atmel NGW100:

http://www.dgmo.org/1-wirecircuits

The author made the Eagle files available for the circuit he built:

http://randomtechmakings.blogspot.com/2009/07/belated-files.html

You could easily adapt this to a BBB cape, in fact there's even a breakout 
board for this:

http://www.inmojo.com/store/inmojo-market/item/1-wire-driver-ds2482-800/


-- 
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: New BeagleBone Black Metal Enclosure

[smith . winston . 101]

On Thursday, April 9, 2015 at 11:05:15 PM UTC-4, William Hermans wrote:
>
> *One question though: Does the cable management get in the way of the 
>> cape?*
>
>
> This is something I was wondering about too. But at the time I did not 
> want to come off as really negative. 
>

Same here.

I have used the cases from Adafruit, Seeed Studios, Logic Supply, but I 
haven't found one that's robust enough AND fits a cape (I really just need 
1/2" of clearance between the top of the BBB Ethernet and the cover.

If they made a version without the cable management plug/hole it would be 
perfect since the power/ethernet/usb connections are already machined into 
the case.  I could drill a hole and buy a strain relief plug if I needed to 
run additional cables to the cape.
 

> Plus the cost is kind of high
>

Yeah, I thought the same, compared to the Logic Supply metal case (although 
this one is much better).

-- 
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: how to read the BBB EEPROM using the "i2c" u-boot command?

[smith . winston . 101]

On Thursday, April 9, 2015 at 7:46:49 AM UTC-4, Robert P. J. Day wrote:
>
>
> > It works on both Debian (Jessie) and FreeBSD!  It uses ioctl()'s to 
> > read 28 bytes from slave addr 0x50 on i2c-0. 
>
>   ah, very nice, thanks. 
>

The nice thing is that you don't have to be root to use it -- just a member 
of the i2c group.  Reading from /sys/bus/i2c/devices/0-0050 can only be 
done by root. 

-- 
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: BBB: RS232/UARTs send "break" during power up

[smith . winston . 101]

On Thursday, April 9, 2015 at 11:48:35 PM UTC-4, William Hermans wrote:

> *The 10K pull-up didn't work.  I didn't think it would, the am335x drives 
>> the pins low during initialization and this is overcoming the pull-up [the 
>> outputs were never free-floating].  I think I should have used a MAX3222 
>> and wired up the SHDN pin to a GPIO so that I could independently enable 
>> the level converter once the system is stable (assuming I can figure out 
>> the .dts incantation to make a GPIO pin work under jessie/3.14-ti).*
>>
>
> Winston is it ?
>

Yes. 
 

> Anyway, you could use Charles S' universal-IO device tree overlay(s)
>  to do this for you. I understand that they are built into the latest 
> images ( for several months now ).
>
> https://github.com/cdsteinkuehler/beaglebone-universal-io
>
> I meant to demonstrate this and write up a mini how-to, but have been 
> really busy for the last several months . . .
>

I think my issue is more fundamental.  The issue is really that the RS232 
peripheral is connected when the BBB boots, for those first few ms, before 
it's even loaded u-boot, the pinmux is at it's default "zero" state and the 
UART pins are thus low which the peripheral reads as a stream of 0's, this 
continues until the dtb (I'm using jessie/3.14) is loaded that enables the 
UART via the pinmuxing.

I had even tried building a custom version of u-boot that enabled UART5 
(whereas normally it only enables UART0 for the console).  Sadly, it still 
isn't quick enough for the peripheral not to see enough 0's to cause a 
serial break.

Thanks!

-- 
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: how to read the BBB EEPROM using the "i2c" u-boot command?

[smith . winston . 101]

On Wednesday, April 8, 2015 at 10:14:23 AM UTC-4, Robert P. J. Day wrote:

>
>   seeing differing opinions online ... if you read this: 
>
> https://e2e.ti.com/support/arm/sitara_arm/f/791/t/233139 
>
> i should be able to display the first few bytes of the BBB's EEPROM 
> from u-boot using: 
>
>  i2c md 0x50 0 16 
>
> but, for me, that just displays "ff" throughout, which is what *other* 
> people claim to see when they try it. 
>
>   should this command work? do i need to initialize something first? 
> am i (theoretically) using the correct arguments? 
>
>
I wrote this C utility a while ago to read the BBB eeprom for the model & 
serial #s:

http://pastebin.com/p7XwKUGZ

It works on both Debian (Jessie) and FreeBSD!  It uses ioctl()'s to read 28 
bytes from slave addr 0x50 on i2c-0.


-W


-- 
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: BBB: RS232/UARTs send "break" during power up

[smith . winston . 101]

On Tuesday, April 7, 2015 at 5:36:55 PM UTC-4, Graham wrote:

> The GPIO pins on most processors, are open inputs until configured.
> So a weak pull up resistor to +3.3V (not the switched +3.3V) on the TX 
> line between the Sitara pin and the MAX3232 input would likely fix your 
> problem.
> Once configured, the TX line will overpower the weak pull up resistor.
>

That's what I was afraid of.  Sadly, the connected peripheral doesn't 
respond well to the break (I'm guessing it's missing it's pullups for the 
RX line).  I did try rebuilding u-boot with UART5 enabled in the hope that 
it would get configured sooner, but it appears the break happens 
immediately at power up before *anything* has happened.

I shall try a 10K pulllup on the TX line.

Thanks for the feedback!


-W

-- 
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: Beaglebone black not booting when circuitry connected

[smith . winston . 101]

On Monday, April 6, 2015 at 2:32:55 PM UTC-4, star...@gmail.com wrote:
>
> Hello there, I have been working on a robotics project using the 
> beaglebone black and have just run into some difficulty.
>
> I am using a protocape for holding all of my circuitry to various sensors. 
> While the protoboard is connected, the board turns on but does not boot. 
> When I disconnect the protocape, my board turns on and boots normally. This 
> happened in between runs with no changes made.
>

Sounds to me like you're shorting something on your protocape.  Check your 
pin usage, particularly the power/gnd pins.  Also look for shorts on the 
protoboard (again, pwr/gnd lines), I know it's easy to make mistakes on the 
protoboards.

-- 
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] BBB: RS232/UARTs send "break" during power up

[smith . winston . 101]

I have a MAX3232 connected to UART5 on a BBB.  During power up; presumably 
before the dtb has been loaded to set the pinmux for the UART, I see a 
"break" sequence being sent.  A break sequence is defined as "tx held low 
for a duration longer than 1 frame".

Seems like pinmuxing won't help because it occurs too late.  According to 
the am335x data sheet the "zero state" for the corresponding pin is Z which 
presumably means the pin will be low (i.e. "emitting" 0's) until the pinmux 
takes over and configures it as a UART pin which presumably brings it to 
idle (high).

Any ideas how to avoid this?

Thanks,


-W

-- 
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: BBB Jessie image with UART4 support

[smith . winston . 101]

On Thursday, March 12, 2015 at 12:36:33 PM UTC-4, Enoch wrote:

>  Is there some /etc/init.d script or equivalent to manipulate the pin mux?
> If not, links to where to start dealing with the source would be 
> appreciated.
>

You need a DTB with the UARTs enabled.  See:

https://github.com/RobertCNelson/dtb-rebuilder/tree/3.14-ti

In particular, for ttyO4 you'll want to look at:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack-ttyO4.dts

The steps are:

git clone https://github.com/RobertCNelson/dtb-rebuilder.git
cd dtb-rebuilder
git checkout 3.14-ti
make src/arm/am335x-boneblack-ttyO4.dtb
cp src/arm/am335x-boneblack-ttyO4.dtb /boot/dtbs/`uname -r`/


Then you'll need to edit /boot/uEnv.txt and add:

dtb=am335x-boneblack-ttyO4.dtb

Then reboot; check dmesg to make sure that the pinmux-helper has properly 
set up the pins for uart mode.

-W

-- 
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] BBB Debian/Jessie -- Enabling GPIO pins in a custom DTS (kernel 3.14)

[smith . winston . 101]

Turning my attention now to enabling GPIO for Jessie/3.14.  I merged my 
prior DTS/overlay into my custom .dts for use with dtb-rebuilder So far I 
have this:

&ocp {


P9_15_pinmux {
// GPIO_A
mode = "P9_15_gpio_pin";
};
P9_16_pinmux {
// GPIO_B
mode = "P9_16_gpio_pin";
};


test_gpio {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <>;


/* declare your gpios */
gpio_a {
gpio-name = "gpio_a";
gpio = <&gpio2 16 0x00>;/* gpio2 is gpio1 */
output;
init-high;


/* /sys/class/gpio/gpio48 */
};


gpio_b {
gpio-name = "gpio_b";
gpio = <&gpio2 19 0x00>;/* gpio2 is gpio1 */
output;
init-high;


/* /sys/class/gpio/gpio51 */
};
};
};



When loading the dtbo on Wheezy, I'd see the gpioXX directories appear in 
/sys/class/gpio, but when loading this on Jessie, I don't see anything in 
dmesg, but I also don't see the directory entries in /sys/class/gpio either.

I've looked through the samples in dab-rebuilder, but aside from a couple 
of LED specific ones, there's no clear example of a GPIO set to output-high 
that's not a device tree overlay.  Anyone know of any Jessie/3.14 custom 
DTS examples of this?

Thanks!


-W

-- 
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 Debian Jessie: Enabling all serial ports (incl. ttyO5)

[smith . winston . 101]

On Monday, March 9, 2015 at 1:22:09 PM UTC-4, RobertCNelson wrote:

> I've been seeing that locally too, but i see the issue... 
>
> CONFIG_SERIAL_8250_NR_UARTS=4 
> CONFIG_SERIAL_8250_RUNTIME_UARTS=4 
>
>
One other thing I noticed, I see entries in dmesg output like this:

[2.656184] bone-pinmux-helper P8_37_pinmux.28: Set initial pinmux mode 
to uart
[2.656791] bone-pinmux-helper P8_38_pinmux.29: Set initial pinmux mode 
to uart

In fact, I see it for the ttyO1, ttyO2, ttyO4 and ttyO5 TXD and RXD pins. 
 However, I want to enable hardware flow control (CTS/RTS) for ttyO4 and 
ttyO5, so I have added the following lines to my custom .dts file:

 P8_33_pinmux {
mode = "uart";
 };
 P8_35_pinmux {
mode = "uart";
 };


 P8_31_pinmux {
mode = "uart";
 };
 P8_32_pinmux {
mode = "uart";
 };



But I don't see corresponding entries in `dmsg` showing the 
bone-pinmux-helper settings the uart modes for 3 of these extra pins (it 
did actually set the uart mode for P8_31).  A bit of digging in 
am335x-bone-common-pinmux.dtsi shows that it's missing the pinctrl modes 
for P8_32, P8_33 and P8_35, along with the uart pinmux definitions for 
P8_33 and P8_35.  So I added them and I now see bone-pinmux-helper property 
configuring these pins.  Here's the diff for am335x-bone-common-pinmux.dtsi:

Next up, I need to get or build a kernel with 5 serial ports enabled to 
test this.


-W

-- 
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.
diff --git a/src/arm/am335x-bone-common-pinmux.dtsi b/src/arm/am335x-bone-common-pinmux.dtsi
index 7c7ea61..75c61a7 100644
--- a/src/arm/am335x-bone-common-pinmux.dtsi
+++ b/src/arm/am335x-bone-common-pinmux.dtsi
@@ -747,6 +747,8 @@
 		pinctrl-single,pins = <0x0d4  0x37>; }; /* Mode 7, Pull-Up, RxActive */
 	P8_33_gpio_pd_pin: pinmux_P8_33_gpio_pd_pin {
 		pinctrl-single,pins = <0x0d4  0x27>; }; /* Mode 7, Pull-Down, RxActive */
+	P8_33_uart_pin: pinmux_P8_33_uart_pin {
+		pinctrl-single,pins = <0x0d4  0x06>; }; /* Mode 6, Pull-Down */
 	P8_33_hdmi_pin: pinmux_P8_33_hdmi_pin {
 		pinctrl-single,pins = <0x0d4  0x08>; }; /* lcd_data13.lcd_data13, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
 
@@ -773,6 +775,8 @@
 		pinctrl-single,pins = <0x0d0  0x37>; }; /* Mode 7, Pull-Up, RxActive */
 	P8_35_gpio_pd_pin: pinmux_P8_35_gpio_pd_pin {
 		pinctrl-single,pins = <0x0d0  0x27>; }; /* Mode 7, Pull-Down, RxActive */
+	P8_35_uart_pin: pinmux_P8_35_uart_pin {
+		pinctrl-single,pins = <0x0d0  0x26>; }; /* Mode 6, Pull-Down, RxActive */
 	P8_35_hdmi_pin: pinmux_P8_35_hdmi_pin {
 		pinctrl-single,pins = <0x0d0  0x08>; }; /* lcd_data12.lcd_data12, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
 
@@ -1621,23 +1625,25 @@
 	P8_32_pinmux {
 		compatible = "bone-pinmux-helper";
 		status = "okay";
-		pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "hdmi";
+		pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "uart", "hdmi";
 		pinctrl-0 = <&P8_32_default_pin>;
 		pinctrl-1 = <&P8_32_gpio_pin>;
 		pinctrl-2 = <&P8_32_gpio_pu_pin>;
 		pinctrl-3 = <&P8_32_gpio_pd_pin>;
-		pinctrl-4 = <&P8_32_hdmi_pin>;
+		pinctrl-4 = <&P8_32_uart_pin>;
+		pinctrl-5 = <&P8_32_hdmi_pin>;
 	};
 
 	P8_33_pinmux {
 		compatible = "bone-pinmux-helper";
 		status = "okay";
-		pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "hdmi";
+		pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "uart", "hdmi";
 		pinctrl-0 = <&P8_33_default_pin>;
 		pinctrl-1 = <&P8_33_gpio_pin>;
 		pinctrl-2 = <&P8_33_gpio_pu_pin>;
 		pinctrl-3 = <&P8_33_gpio_pd_pin>;
-		pinctrl-4 = <&P8_33_hdmi_pin>;
+		pinctrl-4 = <&P8_33_uart_pin>;
+		pinctrl-5 = <&P8_33_hdmi_pin>;
 	};
 
 	P8_34_pinmux {
@@ -1655,12 +1661,13 @@
 	P8_35_pinmux {
 		compatible = "bone-pinmux-helper";
 		status = "okay";
-		pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "hdmi";
+		pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "uart", "hdmi";
 		pinctrl-0 = <&P8_35_default_pin>;
 		pinctrl-1 = <&P8_35_gpio_pin>;
 		pinctrl-2 = <&P8_35_gpio_pu_pin>;
 		pinctrl-3 = <&P8_35_gpio_pd_pin>;
-		pinctrl-4 = <&P8_35_hdmi_pin>;
+		pinctrl-4 = <&P8_35_uart_pin>;
+		pinctrl-5 = <&P8_35_hdmi_pin>;
 	};
 
 	P8_36_pinmux {

Re: [beagleboard] BBB Debian Jessie: Enabling all serial ports (incl. ttyO5)

[smith . winston . 101]

On Monday, March 9, 2015 at 1:22:09 PM UTC-4, RobertCNelson wrote:
>
>
> I've been seeing that locally too, but i see the issue... 
>
> CONFIG_SERIAL_8250_NR_UARTS=4 
> CONFIG_SERIAL_8250_RUNTIME_UARTS=4 
>
> So... yeah.. next kernel build ;) 


Ah!  So r55 then?
 

-- 
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] BBB Debian Jessie: Enabling all serial ports (incl. ttyO5)

[smith . winston . 101]

I am using RCN's image-builder to build jessie images for the BBB (was 
previously using Wheezy).  So far so good, I now need to create a custom 
dtb to enable ttyO1,ttyO2,ttyO4 and ttyO5.  I cloned RCN's dtb-rebuilder 
and created a .dts with the following contents:

/dts-v1/;

#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
#include "am335x-bone-common-pinmux.dtsi"

/ {
 model = "TI AM335x BeagleBone Black";
 compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
};

&ldo3_reg {
 regulator-min-microvolt = <180>;
 regulator-max-microvolt = <180>;
 regulator-always-on;
};

&ocp {
 /* clkout2 */
 P9_41_pinmux {
 status = "disabled";
 };
 /* mmc1 */
 P9_92_pinmux {
 status = "disabled";
 };
};

&mmc1 {
 vmmc-supply = <&vmmcsd_fixed>;
};

&am33xx_pinmux {
 pinctrl-names = "default";
 pinctrl-0 = <&clkout2_pin>;
};

#include "am335x-boneblack-emmc.dtsi"
#include "am335x-bone-i2c2-cape-eeprom.dtsi"

#include "am335x-bone-ttyO1.dtsi"
#include "am335x-bone-ttyO2.dtsi"
#include "am335x-bone-ttyO4.dtsi"
#include "am335x-bone-ttyO5.dtsi"




However, it seems that while ttyO1, ttyO2 and ttyO4 appear (although the 
device numbering is off as I see ttyO0-ttyO3 in /dev), I'm not seeing ttyO5 
appear.  dmesg shows:

[2.613986] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[2.616773] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 88, 
base_baud = 300) is a 8250
[2.634561] console [ttyS0] enabled
[2.635559] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 89, 
base_baud = 300) is a 8250
[2.636413] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 90, 
base_baud = 300) is a 8250
[2.637193] 481a8000.serial: ttyS3 at MMIO 0x481a8000 (irq = 61, 
base_baud = 300) is a 8250
[2.637737] omap8250 481aa000.serial: unable to register 8250 port
[2.644177] omap8250: probe of 481aa000.serial failed with error -28


So it looks like the old "HDMI needs to be disabled" error, except that 
with there's no capemgr in 3.14 loading BB-HDMI and I'm NOT including any 
of the am335x-*hdmi* .dts[i] files.  I *think* this should work as is.  Not 
sure what error -28 is (28 is ENOSPC in errno.h?).

Any ideas on why ttyO5 is not coming up?

Thanks!


-W

-- 
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-Debian fails to flash [from master]

[smith . winston . 101]

On Wednesday, May 14, 2014 11:40:23 PM UTC-4, RobertCNelson wrote:
>
> Yeah.. I was debugging blank eMMC's at CircuitCo i ended up breaking 
> everyone else's..
>
> cd /opt/scripts/tools/
> git pull
>
> and you'll get all the fixes from tonight..
>
> It should work, I'll fire up a new build tomorrow and refresh the demo 
> images.. ;)
>

It works.  Fantastic, thanks for the extremely quick response!

-W 

-- 
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] BBB-Debian fails to flash [from master]

[smith . winston . 101]

Hi Robert,

I built a set of images using the latest image-builder (from the master 
branch), after booting from the SD card, the image fails to flash.  There 
doesn't appear to be a log file, but after running the 
beaglebone-black-eMMC-flasher.sh script with -x, it seems that it's failing 
in the partition_drive() step.  I think it's because /boot/uboot is mounted 
in /etc/fstab to the SD card (mmcblk0p1) and the script is trying to umount 
mmcblk1p1 which isn't actually mounted, which in turn causes 
write_failure() to get called.  Anyway, here's the output (below).

-W.

root@beaglebone:/etc/init.d# /bin/bash -x 
/opt/scripts/tools/beaglebone-black-eMMC-flasher.sh
+ grep -q root
+ id
+ unset boot_drive
++ grep /boot/uboot
++ LC_ALL=C
++ lsblk -l
++ awk '{print $1}'
+ boot_drive=mmcblk0p1
+ '[' xmmcblk0p1 = x ']'
+ '[' xmmcblk0p1 = xmmcblk0p1 ']'
+ source=/dev/mmcblk0
+ destination=/dev/mmcblk1
+ '[' xmmcblk0p1 = xmmcblk1p1 ']'
+ check_running_system
+ '[' '!' -f /boot/uboot/uEnv.txt ']'
+ echo -
-
+ echo 'debug copying: [/dev/mmcblk0] -> [/dev/mmcblk1]'
debug copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
+ lsblk
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk1boot0 179:16   0 1M  1 disk 
mmcblk1boot1 179:24   0 1M  1 disk 
mmcblk0  179:00   3.7G  0 disk 
├─mmcblk0p1  179:1096M  0 part /boot/uboot
└─mmcblk0p2  179:20   1.6G  0 part /
mmcblk1  179:80   1.8G  0 disk 
├─mmcblk1p1  179:9096M  0 part 
└─mmcblk1p2  179:10   0   1.7G  0 part 
+ echo -
-
+ '[' '!' -b /dev/mmcblk1 ']'
+ update_boot_files
++ uname -r
+ '[' '!' -f /boot/initrd.img-3.8.13-bone50 ']'
++ uname -r
+ update-initramfs -u -k 3.8.13-bone50
update-initramfs: Generating /boot/initrd.img-3.8.13-bone50
++ uname -r
+ '[' -f /boot/vmlinuz-3.8.13-bone50 ']'
++ uname -r
+ '[' -f /boot/initrd.img-3.8.13-bone50 ']'
++ uname -r
+ cp -v /boot/initrd.img-3.8.13-bone50 /boot/uboot/initrd.img
`/boot/initrd.img-3.8.13-bone50' -> `/boot/uboot/initrd.img'
++ uname -r
+ mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d 
/boot/initrd.img-3.8.13-bone50 /boot/uboot/uInitrd
Image Name:   initramfs
Created:  Thu May 15 03:19:02 2014
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:2959366 Bytes = 2890.01 kB = 2.82 MB
Load Address: 
Entry Point:  
+ partition_drive
+ flush_cache
+ sync
+ umount_p1
+ '[' -b /dev/mmcblk1p1 ']'
+ echo 'umounting: /dev/mmcblk1p1'
umounting: /dev/mmcblk1p1
+ umount /dev/mmcblk1p1
umount: /dev/mmcblk1p1: not mounted
+ force_umount_p1
+ echo 'Trying to force umount -l of /dev/mmcblk1p1'
Trying to force umount -l of /dev/mmcblk1p1
+ flush_cache
+ sync
+ umount -l /dev/mmcblk1p1
umount: /dev/mmcblk1p1: not mounted
+ write_failure
+ echo 'writing to [/dev/mmcblk1] failed...'
writing to [/dev/mmcblk1] failed...
+ '[' -e /sys/class/leds/beaglebone:green:usr0/trigger ']'
+ echo heartbeat
+ echo heartbeat
+ echo heartbeat
+ echo heartbeat
+ echo -
-
+ flush_cache
+ sync
+ umount /dev/mmcblk1p1
umount: /dev/mmcblk1p1: not mounted
+ true
+ umount /dev/mmcblk1p2
umount: /dev/mmcblk1p2: not mounted
+ true
+ exit

-- 
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: cross compiler the mDNSResponder

[smith . winston . 101]

On Thursday, May 8, 2014 7:02:05 AM UTC-4, jay071...@gmail.com wrote:
>
> how to cross compiler the mDNSResponder for AM335X TI SDK6.0 ??
>
>
> Not sure what you mean by "SDK 6.0", but if you have a Linux based BBB, 
you can install avahi-daemon for Bonjour support.

-- 
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: UART issues on BBB

[smith . winston . 101]

On Saturday, May 10, 2014 4:09:24 PM UTC-4, Christopher Longbottom wrote:
>
> I'm struggling to talk to a modem over the UART. The UARTs in question are 
> 1 and 2, which I enabled using the Adafruit python library.
>
> They can talk to each other fine so I presume they are set up fine.
>
> The problem is that after going through a level shifter they seem unable 
> to communicate to my devices. The GPS module sends data, and it can be 
> received no problem, but sending data seems to be a problem. I have two 
> specific questions.
>
> 1) should I be using a common ground? At the moment I am using two 
> separate power supplies as I can't draw power from the BBB. There is 
> currently no ground common to both.
>
Always.  You should have a TX, RX and GND connectors irrespective of the 
power supplies.  Make sure the TX and RX are crossed and you have the right 
pins.  Then check again and again!  Note that the hardware flow control 
pins are on available on one of the UARTs (if you disable HDMI), so you 
need to ensure that you disable hardware flowcontrol.

2) is the transmission power from the tx pin high enough to get through the 
> level shifter? Does anybody know what the power of these tx pins are?
>
Depends on your level shifter; I've used a Sparkfun MAX3232 breakout board 
and that works really well, I also have a Sparkfun DB-9 to TTL breakout 
(which doesn't use a MAX 232 type device) and I've never gotten it to work. 
 The TTL voltage should be 3.3v.

Make sure you have the correct overlay loaded (for UART1 and/or UART2), 
although I think the Adafruit library loads them for you.  See:

http://robogoby.blogspot.com/2014/04/beaglebone-black-uart-gps.html

-- 
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: debian: test images (2014-02-05)

[smith . winston . 101]

On Friday, February 7, 2014 8:41:25 AM UTC-5, RobertCNelson wrote:
>
> * Custom image: Building a customized version of the beagleboard.org image
>>
>> I don't have any personal plans to do that yet.  If you look closely, all 
> the frontend scripts do is create a ".project" file and call 
> ./RootStock-NG.sh... If you want to make something universal generic, go 
> ahead.. All generic options should end up in the main chroot call with 
> "enable" options passed thru .project and anything  target specific should 
> end up under target/
>

There's still a fair bit of stuff that goes on for the prep of the core & 
flasher images as well the chroot script(s) that would otherwise need to be 
cloned or customized.  I like the way you have the NNN.* scripts in 
machinekit/scripts, right now it just runs them in order, but a 
"config.myimage" script could specify a list of these chroot actions.  For 
example, I don't need any of the X11 stuff, nor any of the 
bonescript/nodejs, but I do want system_patches(), unsecure_root() etc. and 
I also have a custom .deb to install the userside app for the cape (and a 
few other minor bits & pieces).

It looks like the machinekit stuff is close!  but it's not clear how it's 
invoked (I do see the function in releases.sh and the config.machinekit) 
... is there a separate script (or branch) to run a machinekit build?

Thanks!

-- 
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/groups/opt_out.

[beagleboard] Re: debian: test images (2014-02-05)

[smith . winston . 101]

I have a couple of things I'm working on with the image-builder:

* Cape support: I need a way to get dtbo loaded at boot, preferably without 
custom kernel (e.g. via initrd or by putting the .dtbo's in mmcblp0p1)
* Custom image: Building a customized version of the beagleboard.org image

For the latter, at your suggestion, I forked the repo and created my own 
myimage_image.sh by copying beagleboard.org_image.sh.  However, you've been 
busy ... *too* busy and I'm way behind on merging in your changes!

It looks like you're working to a more extensible scheme for 
customizations, I see the machinekit configuration now has a directory with 
custom scripts in it, along with the machinekit() function in releases.sh.

This looks pretty interesting, it would be kind of cool to be able to do:

./image_builder.sh "myimage"

And have it raid the ./myimage" directory to get the configuration, package 
lists etc. for the "myimage" build.

How far off is this?  I'd love to help test this out.

Thanks!


-W.

-- 
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/groups/opt_out.

[beagleboard] Re: How can I know my Angstrom Distribution version?

[smith . winston . 101]

On Thursday, February 6, 2014 8:38:45 AM UTC-5, Kenji Nakasone wrote:
>
> I follow: 
> http://derekmolloy.ie/automatically-setting-the-beaglebone-black-time-using-ntp/
> but still cant set my time. I think that is why I cant get Adafruit 
> library etc.
>

I've also tried to get ntp to work, but it doesn't, even with the -g option 
(ntp won't adjust the time if the offset is more than a certain amount).
 

> Even 
>
> root@beaglebone:~# ntpdate -b -s -u pool.ntp.org
>
> dont work.
>
>>
>>
This does work for me, I don't use the -b, -s or -u options.  Are you sure 
your router or ISP isn't somehow blocking the NTP requests?

Try a couple of other NTP servers (as root):

ntpdate time.apple.com
ntpdate ntp.ubuntu.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/groups/opt_out.

[beagleboard] Re: How can I know my Angstrom Distribution version?

[smith . winston . 101]

On Tuesday, February 4, 2014 6:21:15 AM UTC-5, Kenji Nakasone wrote:
>
> Well, that!
>
> I´m having trouble setting my clock, wifi, adafriut python library ..etc 
> so I was thinking to update my Distro.
>
>
ntpdate time.nist.gov

Should set the clock.  Note that although the BBB has an RTC, it has no 
battery, so it doesn't remember the time!
 

> Is any command where I can get my Distro version?
>
>
lsb_release -a

And you can also look at the contents of /etc/dogtag

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-29) (resend with correct topic..)

[smith . winston . 101]

On Thursday, January 30, 2014 1:29:30 PM UTC-5, RobertCNelson wrote:
>
> > So presumably, this isn't detecting capes via EEPROM; it's effectively 
> the 
> > equivalent of doing: 
> > 
> > echo cape-bone-proto > /sys/devices/bone_capemgr.9/slots 
> > 
> > In a startup script? 
>
> Yeap. 


Ok, so I'm still interested in getting my overlay loaded at boot time via 
EEPROM.  Could you elaborate on your ideas about using initrd.img to store 
the .dtbo files?

Thanks!
  

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-29) (resend with correct topic..)

[smith . winston . 101]

On Wednesday, January 29, 2014 10:04:50 PM UTC-5, RobertCNelson wrote:
>
> On Wed, Jan 29, 2014 at 8:03 PM,  > 
> wrote: 
> > You had previously mentioned adding .dtbo scripts to the /boot partition 
> (or 
> > was it initrd.img) to allow overlays to be detected via EEPROM and 
> loaded 
> > without blocking waiting for the emmc cape. 
> > 
> > Were you able to get that to work? 
>
> That thread was mostly me talking about ways to make it work.. 
>
> I did add a very trivial load cape at boot time (without modifing 
> uEnv.txt) script.. 
>
>
> https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/capemgr-debian.sh
>  
>
>
> https://github.com/beagleboard/image-builder/blob/master/target/init_scripts/capemgr
>  
>
> So i just: 
>
> echo "CAPE=cape-bone-proto" >> /etc/default/capemgr 
>
> and it's autoloaded on the next reboot.. 
>

So presumably, this isn't detecting capes via EEPROM; it's effectively the 
equivalent of doing:

echo cape-bone-proto > /sys/devices/bone_capemgr.9/slots

In a startup script?

-- 
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/groups/opt_out.

[beagleboard] Re: debian: test images (2014-01-29) (resend with correct topic..)

[smith . winston . 101]

On Wednesday, January 29, 2014 4:25:22 PM UTC-5, RobertCNelson wrote:
>
> Lets keep this going, round 4... 
>
>
This is great, thanks again for your hard work.  I'll take a look tonight. 

You had previously mentioned adding .dtbo scripts to the /boot partition 
(or was it initrd.img) to allow overlays to be detected via EEPROM and 
loaded without blocking waiting for the emmc cape.

Were you able to get that to work?

Thanks Robert.


-W.

-- 
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/groups/opt_out.

[beagleboard] Re: Writing image to SD Card using OS X Mavericks on a macbook pro

[smith . winston . 101]

On Sunday, January 26, 2014 9:56:27 AM UTC-5, Kevin McQuown wrote:
>
> I just received my new BBB and wanted to upgrade it to the latest Angstrom 
> version.  I have followed the instructions to the letter.  When I insert 
> the SD card into my mac using it's SD card reader (not a separate SD Card 
> reader via the USB) I am able to write the OS to the card successfully.  Or 
> at least it appears to be.  The output I receive is:
>
> 3724+0 records in
>
> 3724+0 records out
>
> 3904897024 bytes transferred in 2459.711570 secs (1587543 bytes/sec)
>
>
> However when I put the card into the BBB and power it up, I get 3 solid 
> blue led lights just above the usb connection and nothing else.   It 
> doesn't boot.
>
>
> Note, that I have also wrote the eMMC-flasher version to the card and then 
> insert into the BBB, hold down the button just above the SDCard and power 
> it up.  Again, nothing.  I have waited up to a minute with the button down 
> and nothing happens.
>
>
> I am suspecting that when I write the image onto the SDCard using 
> Mavericks on my macbook pro that it may not be doing it in the proper 
> format.
>
>
> Does anyone have any experience with this that might shed some light on 
> what I am doing wrong?
>

There's a dependency problem in the startup where it runs opkg to update 
something (there's an SNNsomething start up script in /etc/init.d that's 
causing it).  It makes it block for many minutes before it gives up and 
moves on.

Best thing to do is to get a USB/Serial cable onto J1 and see what's going 
on.

http://elinux.org/Beagleboard:BeagleBone_Black_Serial

 

-- 
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/groups/opt_out.

Re: [beagleboard] Beaglebone Black backordered everywhere

[smith . winston . 101]

On Monday, January 27, 2014 2:18:04 PM UTC-5, Gerald wrote:
>
> Arrow is showing 500 boards in stock. We have people buying boards to go 
> into products, something we cannot plan for. When will that be fixed? I 
> have no idea. We cannot plan for something we don't know about. 
>
>
Thank you!  I've had them backorderd at both Digikey and Newark for weeks 
now.  Arrow have already shipped my order.  They still have 436 in stock.

 

-- 
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/groups/opt_out.

[beagleboard] Re: BBB+FreeBSD RELEASE-10: capes, i2c, UARTs, API and the device tree

[smith . winston . 101]

On Wednesday, January 22, 2014 10:42:49 PM UTC-5, Richard Lyon wrote:
>
> The problem starts with the version of u-boot they are using. By cloning 
> some of the functionality of u-boot-denx you might be able to get it to 
> work. But ... it's a lot of work. Then you face the issues with the kernel 
> etc  Not sure how well the raspberry pi version works either. The flow 
> seems to be with Linux.
>
> For me it is a better use of time to use Yocto (Angstrom) or Embedian Grip 
> (embedded Debian). ie I prefer a source based distribution instead of 
> binary. Yocto is probably the better long term choice, assuming Angstrom 
> continues to be developed.
>
>
I had started with Angstrom, but it was hard work!  now it appears effort 
is switching to debian.  I really just need a fast, reliable, stable and 
secure OS that can run Go binaries ... but it must be able to boot from 
eMMC, support capes (preferably via a device tree type mechanism) and have 
good support for system updates.

-- 
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/groups/opt_out.

[beagleboard] Re: Simple web interface with BBB

[smith . winston . 101]

On Wednesday, January 22, 2014 12:23:34 AM UTC-5, tsfl...@gmail.com wrote:
>
> This is actually a very basic question, but I'm kind of lost right now.
> I was working on a school project with the Beagle bone black. It controls 
> a bunch of motors and sensors, etc. We essentially wrote everything in C++ 
> and made them into libraries of functions. They work when a main program 
> calls the libraries and the function needed.
>
> Recently we have been asked to demo our progress so far, that too in just 
> a few days. The main program is far from over, so we were thinking of 
> making a very basic web interface that is just going to call the functions. 
> I personally never did this yet, so have no idea what should I be looking 
> at. Node.js and Javascript ('bonescript') seems to be a popular tutorial 
> around, but can they be used to call C++ libraries? Is it possible to host 
> a webpage on the board so that we can open up the page in another PC over 
> LAN?
>
> I know this is a very basic question, but I don't want to spend too much 
> time looking up the wrong methods. Any points towards the right direction 
> would be appreciated.
>

Others have suggested nodejs, but I think interfacing to your C++ directly 
from Javascript is going to be non-trivial; alternately you would have to 
build some kind of RPC interface to C++ that nodejs can call (e.g. REST or 
0MQ).

You should consider Google's Go (http://golang.org/), it has the ability to 
interface to C directly via cgo (you might need to wrap any C++ APIs in a C 
wrapper), and using open source projects such as Martini 
(https://github.com/codegangsta/martini) you can easily build high 
performance web interfaces with Go.  The language is C/Java like, pretty 
easy to learn and very productive.

Best of all, go will produce arm/linux binaries with no dependencies that 
you can run directly on the BBB.  In fact you can cross compile them from 
your workstation with Go (https://coderwall.com/p/pnfwxg).

Hope this helps,


-W.

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-10)

[smith . winston . 101]

On Wednesday, January 22, 2014 7:38:23 PM UTC-5, RobertCNelson wrote:
>
> > On the capemgr front..I am looking into ways to get the dtbo files 
> > accessible at boot time. 
> > Option 1) Get capemgr to find /lib/firmware on startup 
> > Option 2) Put dtbo files into boot partition 
>
> Couples issues, 
>
> The *.dtbo's already compiled under /lib/firmware should work via the 
> uEnv.txt *_enable call.. 
> The kernel .config, build firmware in kernel is enabled. 
> We are using an initrd. (helps hide the lack of rtc problem for rootfs 
> and allows us to us uuid's for the eMMC, aka allowing single/multi mmc 
> card combinations..) 
>
> So, any modifications to any of the existing /lib/firmware/*.dtbo file 
> will be ignored, as the kernel has it built-in. 
>
> Any additions to /lib/firmware/*.dtbo are ignored as they are too late 
> on boot (uEnv.txt *_enable call) and are not in the initrd. 
>
> So.. I "think" we can fix the problem, by making sure all *.dtbo's 
> (including new ones from users) are re-pulled into the initrd when 
> it's regenerated. Here's the current initrd.img update routine. 
>
> if [ ! -f /boot/initrd.img-$(uname -r) ] ; then 
> update-initramfs -c -k $(uname -r) 
> else 
> update-initramfs -u -k $(uname -r) 
> fi 
> cp -v /boot/initrd.img-$(uname -r) /boot/uboot/initrd.img 
>
> I'm guessing we just have to add the *.dtbo to one of the /etc/xyz 
> files that update-initramfs utilizes.. 


This would be good ... I have a custom .dts for a cape that I need to get 
loaded at boot time (via the cape's EEPROM) without the 60s timeout for 
rootfs.

Also, one of the items on my cape is RTC (ds1307 via i2c2) -- yes, it 
actually has a battery too!  Any thoughts on how to get it to be "used" by 
the kernel?   It is detected and shows up as /dev/rtc1, but if I try to 
symlink /dev/rtc to /dev/rtc1, it gets reset at boot time and the kernel 
ignores it ... eventually getting it's time from ntpdate (if network is 
available).

Would be nice if there was a way to connect a battery to the onboard RTC!

-- 
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/groups/opt_out.

[beagleboard] Re: BBB+FreeBSD RELEASE-10: capes, i2c, UARTs, API and the device tree

[smith . winston . 101]

On Tuesday, January 21, 2014 10:54:50 PM UTC-5, rchrd...@gmail.com wrote:
>
> FreeBSD does have an ARM port available. It does use device trees to 
> specify hardware, but I don't know if the grammar is the same as that used 
> in ARM linux. There is a specific FreeBSD port for Raspberry Pi, but I 
> don't know if a BBB port is available.
>
> The best place to check for this is the FreeBSD Wiki. You will need to be 
> a pioneer to use FreeBSD on BBB.
>

So it would seem!  It appears that FreeBSD can only boot from SD card as 
the eMMC is not yet supported!

I'll do some more digging ...

Thanks!
 

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-16)

[smith . winston . 101]

On Monday, January 20, 2014 8:48:50 PM UTC-5, RobertCNelson wrote:
>
> > Yes.  Definitely!  I need both WLAN and ETH, also connman seems more 
> > established.  Finally, connman has better dbus integration for interface 
> > configuration. 
>
> Does the version of connman (1.15) we have in the repo right now work 
> for the dual wlan/eth situation? 
>

No, apparently not!  Once I configured the wifi for connman and restarted 
the service, it hung for a minute, then panic'd:

root@beaglebone:/var/lib/connman# systemctl restart connman.service

[15841.027741] INFO: task wpa_supplicant:515 blocked for more than 60seconds
.
[15841.035254] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[15841.043567] wpa_supplicant  D c045aae7 0   515  1 0x
[15841.050462] Kernel panic - not syncing: hung_task: blocked tasks
[15841.056860] [] (unwind_backtrace+0x1/0x8a) from [] (
panic+0x51/0x148)
[15841.065512] [] (panic+0x51/0x148) from [] (watchdog+
0x14f/0x194)
[15841.073718] [] (watchdog+0x14f/0x194) from [] (
kthread+0x67/0x74)
[15841.082011] [] (kthread+0x67/0x74) from [] (
ret_from_fork+0x11/0x34)
[15841.090550] drm_kms_helper: panic occurred, switching back to text 
console


 
After rebooting, ethernet comes up, but the wifi doesn't.  According to 
syslog, it does try to authenticate but times out.  This is a rtl8192cu 
based USB Wifi adapter (EDIMax), which I never have seen work reliably, so 
this many not be a connman issue.


-W.

-- 
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/groups/opt_out.

[beagleboard] Re: can't load overlay - echo: write error: No such file or directory

[smith . winston . 101]

On Wednesday, January 22, 2014 11:23:25 AM UTC-5, pushu...@gmail.com wrote:
>
> BBB Board running Angstrom v2012.12 and Linux beaglebone 3.8.13 #1 SMP Tue 
> Jun 18 02:11:09 EDT 2013 armv7l GNU/Linux
>
> Trying to run command "echo  > $SLOTS" results in error "-su: 
> echo: write error: No such file or directory"
>

What's in 'overlay' -- is this the overlay file itself or does it contain 
the name of the overlay?  You should be echoing the overlay name into 
$SLOTS; take a look here:

http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay

Could also be a conflict, you might need to add the following to uEnv in 
the boot partition (you'll need to mount /dev/mmcblk0p1 into /mnt to access 
this):

optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN


I can "cat $SLOTS" (/sys/devices/bone_capemgr.8/slots) just fine. I am root 
> and root has rw on that file..
>
> I'm trying to get my own overlay working for a very simple no-eeprom cape 
> which has a DS1307 (which works fine, btw) and which will have an HD47780 
> LCD. I have a number of pre-built overlays in /lib/firmware and none of 
> them will load.
>
> An example from dmesg:
> [ 330.631832] bone-capemgr bone_capemgr.8: failed to load firmware 
> 'cape-bone-adafru-00A0.dtbo'
> [ 490.071059] bone-capemgr bone_capemgr.8: part_number 
> 'cape-bone-adafruit-lcd-00A0', version 'N/A'
> [ 490.071138] bone-capemgr bone_capemgr.8: slot #11: generic override
> [ 490.071157] bone-capemgr bone_capemgr.8: bone: Using override eeprom 
> data at slot 11
> [ 490.071175] bone-capemgr bone_capemgr.8: slot #11: 'Override Board 
> Name,00A0,Override Manuf,cape-bone-adafru'
> [ 490.071277] bone-capemgr bone_capemgr.8: slot #11: Requesting part 
> number/version based 'cape-bone-adafru-00A0.dtbo
> [ 490.071296] bone-capemgr bone_capemgr.8: slot #11: Requesting firmware 
> 'cape-bone-adafru-00A0.dtbo' for board-name 'Override Board Name', version 
> '00A0'
> [ 490.080114] bone-capemgr bone_capemgr.8: failed to load firmware 
> 'cape-bone-adafru-00A0.dtbo'
>
> Is it failing due to lack of an eeprom? 
>

No, the EEPROM just enables "auto detection" of your cape, you put the 
part#/revision and it'll try to load it.  However, there are issues, if you 
don't compile the overlay into the kernel, then the boot stalls for 60 
seconds because the eMMC overlay gets loaded *after* the EEPROM ones and of 
course, the rootfs isn't available until then.

Check your filenames here, the part # seems to be cape-bone-adafruit-lcd, 
but it's looking for cape-bone-adafru.  Also, take another look at dmesg, 
after the 60 second stall, the eMMC overlay is loaded and rootfs mounted, I 
think it tries again.

You could also try explicitly adding it to uEnv.txt:

optargs=capemgr.enable_partno=my-overlay

 

> My LCD project is using code from here:
> LCD library:
> http://www.nunoalves.com/open_source/?p=152
> (git repo https://github.com/nunoalves/BeagleBone_IO_lib)
>
> It looks like in the code (which fails on asserting GPIO pins) tries to 
> set up the pins itself. Should an overlay even be needed?
>

Yes, you'll likely need an overlay unless the pins you are using are 
already configured by default (e.g. I2C2).

Hope this helps,


-W

-- 
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/groups/opt_out.

[beagleboard] BBB+FreeBSD RELEASE-10: capes, i2c, UARTs, API and the device tree

[smith . winston . 101]

I see that FreeBSD RELEASE-10 is out and runs on the BBB.  I have it 
running in a VirtualBox VM (x64 version) and I'm interested enough to try 
it on the BBB along with my cape & device tree overlay.

Does anyone have *any* idea how to get my cape(s) working:

* Does it support some kind of device-tree-overlay (dts) and/or capemgr?
* Do I need to build a custom kernel to enable the BBB for things like 
UART1, SPI0 and I2C

Thanks!


-W.

-- 
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/groups/opt_out.

[beagleboard] Re: debian: test images (2014-01-16)

[smith . winston . 101]

On Thursday, January 16, 2014 4:42:34 PM UTC-5, RobertCNelson wrote:
>
> Know Issues: 
> wicd: can only handle eth0 or wlan0, not both at the same time.. 
>
> Questions? Should we switch to connman? 


Yes.  Definitely!  I need both WLAN and ETH, also connman seems more 
established.  Finally, connman has better dbus integration for interface 
configuration.

Please switch!


-W.

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-10)

[smith . winston . 101]

On Wednesday, January 15, 2014 1:05:33 PM UTC-5, RobertCNelson wrote:
>
> > With the new scripts, I'm looking to do a number of things: 
> > 
> > 3) Build a custom kernel (to include a .dts) 
>

Any thoughts on adding a custom .dts to the build script to be included in 
the kernel?

I have some notes from someone else:

1. Copy the dts file to $KERNEL/firmware/capes
2. Add it to the build list in $KERNEL/firmware/Makefile

But it looks like it's downloading a pre-build kernel?

Thanks!


-W.

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-10)

[smith . winston . 101]

On Thursday, January 16, 2014 9:33:13 PM UTC-5, RobertCNelson wrote:
>
> > 1) Setting user_name in .project (or the main build script) gets 
> overwritten 
> > with 'debian' 
>
> Yeah, for some reason it's not sourcing it from ".project" correctly 
> at the moment.. 
>
> https://github.com/RobertCNelson/omap-image-builder/blob/master/chroot_script/beagleboard.org.sh#L14
>  
>
> Working on that.. 
>

Cool, thanks!
 

> > 2) No console getty respawn. 
> > - I logged on to the console, ended up logging out (see #2), never 
> got a 
> > prompt back on the console (nothing in dmesg) 
>
> Is this with the main ttyO2 debug serial console or one of the video 
> console's tty0? 
>

It was the serial console, ttyO2
 

> > 3) Terminal got screwed up. 
>
> You need to re-size your serial terminal to fix this. systemd is also 
> a lot more noiser, hence the quiet.. 
>

Yeah, I don't think the resize is the issue.  I have a Mac Terminal set at 
80x55.  I think it's some kind of stty mode that's changing.  However, 
retrying it a number of times, I have only seen it "screw up" the terminal 
I/O a couple of times.  Mostly it's ok.

I always disable the "quiet" mode, I find it disconcerting to not see 
output when the system boots ... kind of Windows like.
 

> > 4) Fails to halt properly with /sbin/halt (kernel panic) 
>
> The kernel panic with halt is known.. 
> http://bugs.elinux.org/issues/39 
>
> The system still correctly shut's off just fine..  It also affects the 
> older angstrom 3.8 images..  
>

I only had the one occasion when it failed to stop (that is the leds kept 
flashing and I could log back in via ssh).  Every other time it's halted 
(with the panic).

Thanks!


-W.

 

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-10)

[smith . winston . 101]

On Thursday, January 16, 2014 3:01:17 PM UTC-5, RobertCNelson wrote:
>
> On Thu, Jan 16, 2014 at 1:41 PM,  > 
> wrote: 
>
> Give it a few more seconds, currently "wicd" is under control of eth0 
> (not /etc/network/interfaces) on 3.8 it takes wicd about 2-3 calls 
> before it gets it.. 
>
> The only reason i'm using wicd over /etc/network/interfaces is to 
> remove the 2 minute timeout if eth0 isn't connected... 


Ok, I had removed wicd-gtk.  I replaced it with wicd-cli and the ethernet 
is fine!

Couple of things I noticed:

1) Setting user_name in .project (or the main build script) gets 
overwritten with 'debian'
2) No console getty respawn.
- I logged on to the console, ended up logging out (see #2), never got 
a prompt back on the console (nothing in dmesg)
3) Terminal got screwed up.
- At somepoint during the boot (I removed systemd=quiet so I can see 
what's going on), the terminal got screwed up and the formatting went 
haywire:
openbsd-inetd[496]: Not starting internet superserver: no services enabled.
Started LSB: Start or stop the inetd daemon.   [ 
 OK  ]
Started Provide limited super user privileges to specific users[ 
 OK  ]
Started LSB: Run /etc/rc.local if it exist [ 
 OK  ]

   Started Avahi mDNS/DNS-SD Stack[ 
 OK  ]

  Started Login Service  [ 
 OK  ]

 Started WPA supplicant [ 
 OK  ]

boot_scripts.sh[492]: Thu Jan 16 17:02:00 UTC 2014
  cron[510]: Starting periodic 
command scheduler: cron.

- 'reset' and resetting the terminal locally didn't fix it
4) Fails to halt properly with /sbin/halt (kernel panic)
- If you do it via an ssh login, it just doesn't halt
- If you do it from the console, it does halt, but you get:
[  146.037995] (NULL device *): gadget not registered.
[  146.050219] musb-hdrc musb-hdrc.0.auto: remove, state 4
[  146.055772] usb usb2: USB disconnect, device number 1
[  146.061907] musb-hdrc musb-hdrc.0.auto: USB bus 2 deregistered
[  146.068906] Disabling non-boot CPUs ...
[  146.073001] Power down.
[  146.075595] System will go to power_off state in approx. 2 secs
[  146.083999] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x
[  146.083999] 
[  146.093558] [] (unwind_backtrace+0x1/0x8a) from [] 
(panic+0x51/0x148)
[  146.102101] [] (panic+0x51/0x148) from [] 
(do_exit+0x345/0x618)
[  146.110107] [] (do_exit+0x345/0x618) from [] 
(sys_reboot+0xcb/0x13e)
[  146.118560] [] (sys_reboot+0xcb/0x13e) from [] 
(ret_fast_syscall+0x1/0x46)
[  146.127546] drm_kms_helper: panic occurred, switching back to text 
console


But otherwise, great progress!

Thanks!


-W.

-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-10)

[smith . winston . 101]

On Thursday, January 16, 2014 12:10:35 PM UTC-5, smith.wi...@gmail.com 
wrote:
>
>
> Fantastic, thanks for this, I'm in the process of running my first build.
>
>
Success! ... I think.  Don't seem to have working ethernet, here's the 
console output:

[0.361322] omap2_mbox_probe: platform not supported
[0.528826] tps65217-bl tps65217-bl: no platform data provided
[0.593518] bone-capemgr bone_capemgr.9: slot #0: No cape found
[0.630626] bone-capemgr bone_capemgr.9: slot #1: No cape found
[0.667733] bone-capemgr bone_capemgr.9: slot #2: No cape found
[0.704842] bone-capemgr bone_capemgr.9: slot #3: No cape found
[0.720846] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN 
conflict P8.45 (#5:BB-BONELT-HDMI)
[0.730428] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[0.737160] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 
BB-BONELT-HDMIN:00A0 (prio 2)
[0.753514] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' 
failed
[0.816446] pinctrl-single 44e10800.pinmux: pin 44e10854 already 
requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[0.828157] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status 
-22
[0.835441] pinctrl-single 44e10800.pinmux: could not request pin 21 on 
device pinctrl-single
Loading, please wait...
Scanning for Btrfs filesystems
systemd-fsck[201]: rootfs: clean, 32162/04 files, 140904/444160 blocks
[6.087883] libphy: PHY 4a101000.mdio:01 not found
[6.092953] net eth0: phy 4a101000.mdio:01 not found on slave 1


Any thoughts?

Thanks!


-- 
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/groups/opt_out.

Re: [beagleboard] Re: debian: test images (2014-01-10)

[smith . winston . 101]

On Wednesday, January 15, 2014 1:05:33 PM UTC-5, RobertCNelson wrote:
>
> The easiest thing to do, is first just fork the repo, then: 
>
> cp beagleboard.org_image.sh custom_image.sh 
>
> Then edit the "chroot_script" line, so you can run your own chroot 
> customization script.. 
>
> For example we are calling: ( chroot_script="beagleboard.org.sh" ) 
>
> https://github.com/beagleboard/image-builder/blob/master/beagleboard.org_image.sh#L342
>  
>
> dump your script here: 
> https://github.com/beagleboard/image-builder/tree/master/chroot_script 
>
> The main chroot script does set some sane defaults, 
>
>
> https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L289
>  
>
> Just ping us if something is enabled by default that you need off.. 
>
> Doing that other then just do a git pull everyonce in awhile to get 
> updates.. 
>
> git pull --no-edit git://github.com/beagleboard/image-builder.git master 
>
> If your project gets big, i have issues with adding it to the 
> readme.md list like I did with MachineKit then i just randomly pull 
> from those tree when they have updates.. 
>

Fantastic, thanks for this, I'm in the process of running my first build.

However, it occurs to me that perhaps I don't need to copy the 
beagleboard.org_image.sh script ... it seems to write all of the things I 
want to change to the .project file ... If I drop in my own version of 
this, will the "stock" beagleboard.org_image.sh pick those up?

Couple of other questions:

1) I'm working out of master, should I be using the 01.10.2014 branch?  I'm 
happy to work on the bleeding edge, as long as I can load my capes .dts via 
EEPROM
2) I need to load some "unstable" packages from sid, is there any way in 
the script to do this? -- specifically, golang-go (2:1.2-2) for Go 1.2
3) I'm curious as to what is QEMU used for?  I actually need it to cross 
compile Erlang for the BBB, so I'd like to see how it's getting used.

Again, many thanks for your efforts!!!


-W.


-- 
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/groups/opt_out.

[beagleboard] Re: debian: test images (2014-01-10)

[smith . winston . 101]

On Friday, January 10, 2014 5:11:09 PM UTC-5, RobertCNelson wrote:
>
> It's Friday and everyone is probally kicking back and enjoying a cold 
> beverage... Well enough of that crap, time to start actually testing 
> something... ;) 
>
>
Firstly, many thanks for your hard work here!

Now that the move to debian is official, I'm scrambling to move my custom 
images over.  With Angstrom, I had a custom .bb file that was based on the 
ti-hw-bringup-image.bb script and added a few extra things.

With the new scripts, I'm looking to do a number of things:

1) Omit some packages, such as Cloud9, Node and Xorg as I don't need them
2) Add some of my own packages
3) Build a custom kernel (to include a .dts)
4) Customize the resulting rootfs (e.g. add users, systemd service scripts 
etc)
5) Ultimately, automate this

Initially, I could just clone the script and edit the lines that set 
bborg_pkg_list to omit what I don't want (#1) and include what I do #2.  I 
could add a further function to modify the root filesystem before it gets 
zipped up (although I'm not sure how I create new users etc ...).

Is there some way of being able to extend the script in this manner without 
having to change it so that it doesn't get clobbered when updating?

Thanks!


-W.


-- 
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/groups/opt_out.

Re: [beagleboard] Adding Cape Support of BBB in Beagleboard git repo

[smith . winston . 101]

On Sunday, January 12, 2014 8:18:43 PM UTC-5, David Marquart wrote:
>
> if you are using Roberts kernel building scripts all you need to do is add 
> the DTS file to /KERNEL/firmware/capes and add it to the build list in 
> /KERNEL/firmware/Makefile .  Then run ./tools/rebuild.sh and 
> ./install-kernel.sh.   If you plan to distribute it you should try to get 
> it upstream, but for testing/one off this works. I am using this method 
> with an RS232 cape with RTS/CTS on 3.12 kernel. 
>
>>
>>
OK.  I just saw another posting referring to the switch to debian, so I 
need to re-evaluate everything! 

Many thanks for the info and taking the time to reply!


-W.

-- 
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/groups/opt_out.

Re: [beagleboard] Angstrom Release

[smith . winston . 101]

On Monday, January 13, 2014 12:22:55 PM UTC-5, RobertCNelson wrote:
>
> >I would like to know when will be the next official release 
> of 
> > Angstrom image for Beaglebone black. 
> >   We have developed a camera cape board 
> > (http://www.radiumboards.com/HD_Camera_Cape_for_BeagleBone_Black.php) 
> and it 
> > support is added in  3.8 kernel beaglebone git but not yet came 
> in 
> > Angstrom release binaries. 
>
> Probably not anytime soon, unless someone else steps up.. 
>
> http://beagleboard.org/blog/2014-01-04-happy-new-year/ 
>
> Your Camera should be working out of the box with: 
>
> https://groups.google.com/d/msg/beagleboard/9EG0SbhwTx0/BWso2srYz24J 
>
>
Thanks Robert, this answers a *lot* of questions.

I guess it's time to switch to debian.

 

-- 
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/groups/opt_out.

[beagleboard] Re: Struggling to find detailed information on how to make capes for the BBB

[smith . winston . 101]

On Sunday, May 26, 2013 1:53:01 PM UTC-4, woss...@gmail.com wrote:
>
> I'd like to find a good and detailed source of information on how to 
> create a well-integrated BBB Cape design.  I have put together a bare-bones 
> cape which is just an EEPROM chip running off the BBB's 3.3v line.  The 
> EEPROM contains my correctly formatted data and does indeed appear to be 
> recognised in the output from *dmesg*.  However, I am now a bit stuck.
>
> Following a couple of articles on the web I managed to bodge together a 
> working ".dtbo" file and this appears to work.  My prototype board does 
> show up in `cat /sys/devices/bone_capemgr.9/slots` after a reboot, which is 
> great :).
>
> But I'm at a bit of a loss as to what I should do next.  I'd like to put 
> an ATMega microcontroller onto my shield (running from the BBB's 3.3v rail) 
> and have it talk to the BBB using two IO pins to form a simple TX/RX uart. 
>  The ATMega side of this is no problem, I've done this many times, but the 
> BBB side is unknown to me.
>
>
Take a look at the BB-UART1 DTS script (in /lib/firmware), it shows how to 
configure UART1 for use.  Once you've compiled the .dtbo for your cape and 
put it in /lib/firmware, if you have the right part # and revision info in 
the EEPROM, then the capemgr should properly load the .dtbo and you'll see 
a device /dev/ttyO1 (for UART1).  At this point, you can test it by running 
minicom and configuring the port to use /dev/ttyO1 (with 115200,8,N,1 with 
no flow control etc) and you should be able to talk to your ATmega.

NOTE: There's a 60 delay when the capemgr tries to load your dtbo as 
there's a race condition with the eMMC cape (which contains the root 
filesystem!) and it hangs for 60 seconds before giving up, loading the eMMC 
cape which allows filesystem access.  At that point, it does retry your 
cape and will load the .dtbo, but the 60s hang is **very** annoying.  There 
were some patches applied a while ago, but I don't know if they have shown 
up yet.  Besides, changing the 60 timeout requires a custom kernel.

The only other option to skip the 60s delay is to compile your dtbo into 
the kernel -- I haven't yet figured out how to do this!

Hope this helps,


-W


-- 
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/groups/opt_out.

Re: [beagleboard] Adding Cape Support of BBB in Beagleboard git repo

[smith . winston . 101]

On Tuesday, November 19, 2013 9:36:02 AM UTC-5, RobertCNelson wrote:
>
> Either create a pull request against the 3.8/3.12 branch or post your 
> patches to this list.. 
>
>
Hi Robert,

Do you have any pointers on building cape support into a custom kernel?  I 
have built the Angstrom image and can flash it and load my .dtbo via uEnv 
and/or EEPROM, but I need to compile it in to the kernel to avoid the 60 
second hang during boot because of the eMMC cape conflict.

I assume there's some way of adding my .dts to the build so that it gets 
compiled with dtc and linked into the kernel image.

Thanks!


-W.

-- 
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/groups/opt_out.

[beagleboard] Custom kernel with Angstrom

[smith . winston . 101]

Anyone know how build a custom kernel with/for Angstrom using the 
OE/bitbake instructions?

Thanks.


-- 
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/groups/opt_out.

[beagleboard] Custom bitbake/Angstrom recipe to change kernel config, update target fs and cross compile golang

[smith . winston . 101]

I'm using the standard instructions for building the BBB Angstrom image, in 
particular I'm building for Angstrom 13.12/yocto1.5.  For the standard 
system images, this works quite nicely.

Can anyone give me any pointers on how to create a custom bitbake recipe 
that can modify the kernel config and after the image is built, make some 
simple rootfs image modifications such as copying in some files, editing 
./etc/hostname etc.

I know I can bootstrap off the existing recipes, for example if I create 
'mytest-image.bb' as follows:

# Somehow edit kernel .config file ...

require ti-hw-bringup-image.bb

ROOTFSTYPE_beaglebone = "ext4"

IMAGE_INSTALL += " \
"

# Now edit the filesystem???

export IMAGE_BASENAME = "Mytest"


Does this involve creating "layers" to overlay stuff?

Finally, if I wanted to add something that's not available via okpg, such 
as golang, how would I go about incorporating this?

Many thanks!

-W.

-- 
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/groups/opt_out.

[beagleboard] Re: Custom Device Tree Files

[smith . winston . 101]

On Tuesday, January 7, 2014 12:30:39 PM UTC-5, evan...@gmail.com wrote:
>
> I'm creating a custom device tree file to work with the PRU, and whenever 
> I try to add the name of the part number to the uEnv.txt file, boot will 
> hang for about 3-5 minutes then run correctly. The device tree file works 
> correctly and does not hang after bootup whenever I manually add the part 
> number by calling:
>
> echo BB-BONE-PRU-05 > /sys/devices/bone_capemgr.8/slots
>
> The device tree file I'm using is copied from the BB-BONE-PRU-01-00A0.dts 
> file in the /lib/firmware folder.
> Bootup will still hang when values aren't modified, and It's just a 
> different part number.
>
> I'm saving the BB-BONE-PRU-05-00A0.dts file in the /lib/firmware folder 
> and compiling the file using:
>
> dtc -O dtb -o BB-BONE-PRU-05-00A0.dtbo -b 0 -@ BB-BONE-PRU-05-00A0.dts
> Does anyone know how I can use this custom device tree file without boot 
> hanging?
>

The issue is that when the capemgr tries to load your .dtbo, the emmc 
overlay hasn't been loaded and so the rootfs is inaccessible.  The default 
timeout is 60s before it gives up and continues.  if you ru dmesg, you'll 
see a big gap between 1-2s and 61+s in the messages, for example:

[1.249060] bone-capemgr bone_capemgr.9: slot #0: Requesting part 
number/version based 'BB-TEST-00A0.dtbo
...
[1.850280] Waiting for root device /dev/mmcblk0p2...
[   61.500166] bone-capemgr bone_capemgr.9: failed to load firmware 
'BB-TEST-00A0.dtbo'
[   61.508320] bone-capemgr bone_capemgr.9: loader: retrying slot-0 
BB-TEST:00A0 (prio 0)
[   61.516641] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version 
'00A0'
[   61.530738] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 
'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
[   61.544284] bone-capemgr bone_capemgr.9: slot #0: Requesting part 
number/version based 'BB-TEST-00A0.dtbo

[   61.554290] bone-capemgr bone_capemgr.9: slot #0: Requesting firmware 
'BB-TEST-00A0.dtbo' for board-name 'Test Cape with EEPROM', version '00A0'
See this thread: 
https://groups.google.com/forum/#!msg/beagleboard/Iem_mHknIUM/NJkw0O7gHQYJ

There were 3 commits in the last 6 months to solve this:

1) Priority on capemgr.part_no option: 
 
https://github.com/pantoniou/linux-bbxm/commit/738e37102bdfbfd065f4f53814df62b896804d90
 
2) Retry loading firmware on failure: 
 
https://github.com/pantoniou/linux-bbxm/commit/fb99fd668f8baaf4270ce8b2359077dcc9a047aa
3) Make firmware timeout configuable: 
 
https://github.com/pantoniou/linux-bbxm/commit/66166f29c1cfa5035ba4782266d677b908e81f0e

So in theory, according to #1 if you append ::10 to the partno in uEnv.txt, 
it should load it *after* the emmc cape has been loaded which *should* 
solve your issue.

I have a custom cape with an EEPROM that designates the partno, so I don't 
need uEnv.txt, but there's no way to specify the priority here and I'm 
stuck with the 60 delay.  Supposedly, #2 and #3 fix this, but I haven't yet 
discovered where these changes actually get into the Angstrom builds.

I just built Angstrom 13.12 (yocto1.5) today and they don't appear to be 
included.  In fact I haven't even figured out where the capemgr is coming 
from, there are no .c files in drivers/misc/cape/beaglebone in the kernel 
tree!

If anyone can tell me how to take the Angstrom 13.12/yocto1.5 and update it 
(preferably via a .bb recipe!) to set the FIRMWARE_LOADING_TIMEOUT to say 
1s, that would be great!

Hope this helps,

-W.

-- 
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/groups/opt_out.

[beagleboard] Re: Help with I2C on BBB in Debian

[smith . winston . 101]

On Saturday, October 26, 2013 2:38:27 PM UTC-4, Joshua Datko wrote:
>
>
> In the default Debian imagine, can any I2C bus be used from the P9 
> expansion header, without rebuilding the kernel?  If so, which pins?  (19 & 
> 20, or 17 & 18?)
>
> When I run i2cdetect, I have two I2C buses, but I'm not sure which buses 
> they map to on the BBB:
>

See:

https://groups.google.com/forum/#!msg/beagleboard/v9r8UkN7klk/h3rFKFJDLnUJ
 

-- 
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/groups/opt_out.

Re: [beagleboard] Re: I2C and Invensense MPU6050 Driver

[smith . winston . 101]

If you're curious as to how to figure out what I2C interface maps to which 
bus, take a look at this post I wrote yesterday:

https://groups.google.com/d/msg/beagleboard/v9r8UkN7klk/h3rFKFJDLnUJ


On Friday, November 1, 2013 11:02:44 AM UTC-4, Jason Kridner wrote:
>
> On Fri, Nov 1, 2013 at 12:09 AM, Joshua Datko > 
> wrote: 
> > Nevemind, that may be unrelated.  I just rebooted and my device 
> enumerated 
> > fine.  I think what's confusing (me) is the I2C2 by the SRM (P9_19/20) 
> shoes 
> > up as I2C1... 
>
> Yeah, this is a really confusing (well-known) issue where the latest 
> Linux kernels assign the bus names in order of them being enumerated, 
> despite whatever hardware name is given to them. So, I2C0, enumerated 
> first, becomes, i2c0 and I2C2, enumerated second, becomes i2c1. If you 
> then enumerate I2C1, you'll get an i2c2. Kinda confusing, got to give 
> you that. 
>
> > 
> > some output: 
> > 
> > ebian@arm:~$ ls -l /sys/bus/i2c/devices/i2c-* 
> > lrwxrwxrwx 1 root root 0 Nov  1 04:02 /sys/bus/i2c/devices/i2c-0 -> 
> > ../../../devices/ocp.2/44e0b000.i2c/i2c-0 
> > lrwxrwxrwx 1 root root 0 Nov  1 04:02 /sys/bus/i2c/devices/i2c-1 -> 
> > ../../../devices/ocp.2/4819c000.i2c/i2c-1 
> > debian@arm:~$ su 
> > Password: 
> > root@arm:/home/debian# i2cdetect -r 1 
> > WARNING! This program can confuse your I2C bus, cause data loss and 
> worse! 
> > I will probe file /dev/i2c-1 using read byte commands. 
> > I will probe address range 0x03-0x77. 
> > Continue? [Y/n] Y 
> >  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 
> > 00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
> > 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- 
> > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> > 70: -- -- -- -- -- -- -- -- 
>
> I need hints on how the MPU6050 should be wired up or assume that I've 
> got a bad device.  I can probably try hooking it up to something else. 
>
> > 
> > 
> > 
> > On Thursday, October 31, 2013 9:57:08 PM UTC-6, Joshua Datko wrote: 
> >> 
> >> So I've been struggling with I2C.  Somebody on this list gave me the 
> tip 
> >> to do: 
> >> 
> >> echo BB-I2C1 > /sys/devices/bone_capemgr./slots 
> >> 
> >> which enables the third I2C bus and my device then was visible via 
> >> i2cdetect -y -r 1 on pins P9_19 and P9_20.  Although, after doing that, 
> >> you'll have an i2c1 and a i2c2 bus, so might want to check both.  But, 
> I'm 
> >> not quite sure why this works :) 
> >> 
> >> In my case, I don't think there is device tree entry for the device I'm 
> >> using, so I was planning on interacting with it over raw I2C. 
> >> 
> >> Hope this helps, 
> >> 
> >> Josh 
> >> 
> >> 
> >> On Thursday, October 31, 2013 2:32:46 PM UTC-6, Jason Kridner wrote: 
> >>> 
> >>> On Tue, Oct 29, 2013 at 2:19 PM, Jason Kridner <
> jkri...@beagleboard.org> 
> >>> wrote: 
> >>> > 
> >>> > On Thu, Oct 17, 2013 at 6:12 PM,   wrote: 
> >>> > > AIW: 
> >>> > > I went back thru the adafruit library and didn't find anything 
> >>> > > specific on 
> >>> > > I2C, although it is listed as a topic.  I have been looking at 
> their 
> >>> > > github 
> >>> > > adafruit-beaglebone-io-python library. I also found and looked 
> thru 
> >>> > > PyBBIO. 
> >>> > > Even tho I'm not using Python, I can see the access mechanisms 
> that 
> >>> > > they 
> >>> > > use. 
> >>> > > I can use the MPU6050 device ok enough just reading via 
> >>> > > /dev/i2c/i2c-x, but 
> >>> > > that is too slow. 
> >>> > > I'm trying to figure out how to invoke and use the inv-mpu6050 
> driver 
> >>> > > and 
> >>> > > adafruit doesn't use that. 
> >>> > > Thx -- Clark 
> >>> > > 
> >>> > > On Thursday, October 17, 2013 9:47:44 AM UTC-7, AIW wrote: 
> >>> > >> 
> >>> > >> Some good info on I2C tools at http://www.acmesystems.it/i2c. 
> >>> > >> 
> >>> > >> Python and the adafruit BBIO I2C library makes it very easy to 
> use 
> >>> > >> I2C on 
> >>> > >> Beaglebone Black as well. Python import smbus is fairly easy to 
> use 
> >>> > >> too. 
> >>> > >> Some examples of use is available in the code I provide for my 
> radio 
> >>> > >> project 
> >>> > >> herewww.aiwindustries.com. 
> >>> > >> 
> >>> > >> Not trying to sell the product, but I know that the I2C function 
> was 
> >>> > >> giving me some issues so I'm just trying to help the community. 
> >>> > >> Python code 
> >>> > >> is available to download and look at usage so feel free. 
> >>> > >> 
> >>> > >> On Tuesday, October 15, 2013 5:02:59 PM UTC-5, 
> clarkbr...@gmail.com 
> >>> > >> wrote: 
> >>> > >>> 
> >>> > >>> We are using the Invensense MPU6050 IMU on I2C with Beaglebone 
> >>> > >>> Black 
> >>> > >>> (Angstrom 3.8.13). We can use I2C-tools and file I/O thru 
> /dev/i2c 
> >>> > >>> but the 
> >>> > >>> read speed is disappoint

[beagleboard] Re: I2C on ubuntu linux 3.8, BBB pin confusion?

[smith . winston . 101]

On Thursday, October 31, 2013 1:45:16 PM UTC-4, Dacobi wrote:
>
> But how do I translate this to pin numbers on P8 and P9?
>

Take a look at this thread/post, it should help:

https://groups.google.com/d/msg/beagleboard/v9r8UkN7klk/h3rFKFJDLnUJ

-- 
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/groups/opt_out.

Re: [beagleboard] Re: modprobe rtc-ds3231 returns module not found?

[smith . winston . 101]

On Thursday, October 31, 2013 7:49:27 AM UTC-4, Will Kostelecky wrote:
>
> It's on i2c-1.   The frustrating thing is that the HW works with another 
> image that I built a while ago.  I am now trying to build a clean new image 
> (post all my development messing around) and it is not working with the new 
> build.   I am pretty sure I did not have to do anything other than what I 
> am doing now but obviously I have missed something in the new build.
>

Newer builds require the use of a device tree overlay to ensure the 
hardware you need is available, in older builds, you had to rebuild the 
kernel if what you wanted wasn't available.  Although recent builds have 
had the dto support, I have found various issues here and there.

So i2c-1 is the enumeration linux gave one of the i2c buses and does not 
necessarily correspond to the i2c pins you are using.  The BBB has two 
usable i2c devices [1], as follows:

   - i2c0: Not exposed in the expansion headers
   - i2c1: pins P9 17,18 (and 24,26)
   - i2c2: pins P9 19,20 (and 21,22)

The i2c devices appear in the AM335x memory map [2] at the following 
locations:

   - i2c0: 0x44E0_B000
   - i2c1: 0x4802_A000
   - i2c2: 0x4819_C000

Linux creates mappings in the /sys/bus/i2c/devices pseudo-filesystem that 
indicates the mappings from the i2c-* devices to the underlying hardware:

root@beaglebone:~# ls -l /sys/bus/i2c/devices/i2c-*
lrwxrwxrwx1 root root 0 Jan  1  2000 
/sys/bus/i2c/devices/i2c-0 -> ../../../devices/ocp.2/*44e0b000*.i2c/i2c-0
lrwxrwxrwx1 root root 0 Jan  1  2000 
/sys/bus/i2c/devices/i2c-1 -> ../../../devices/ocp.2/*4819c000*.i2c/i2c-1

So you can see here, that on my BBB, i2c0 is mapped to /dev/i2c-0 and i2c2 
is mapped to /dev/i2c-1.

You can check your system, but I suspect that i2c-1 is actually i2c2 on 
pins P9_19,20.


-W.



[1] BBB I2C Ports.  See 
http://circuitco.com/support/index.php?title=Cape_Expansion_Headers#2_I2C_Ports
[2] TI Sitara AM335x SRM, page 211, 212. See 
http://elinux.org/images/6/65/Spruh73c.pdf
 

-- 
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/groups/opt_out.

[beagleboard] Re: modprobe rtc-ds3231 returns module not found?

[smith . winston . 101]

On Thursday, October 31, 2013 2:15:28 AM UTC-4, Will Kostelecky wrote:
>
> I am struggling to get an RTC to work on my BBB.   I see the 0x68 address 
> in i2cdetect but it shows as UU (In Use?).  When I do a "modprobe 
> rtc-ds3231" it returns "FATAL: Module rtc-ds3231 not found."  I have this 
> same config running on another version of the OS and have followed what I 
> think is the same process on this new build...
>

What i2c bus is the DS3231 on?  And do you have the right dto (pinmux) if 
it's not on i2c2 (pins 19,20) which I believe is always enabled.

-- 
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/groups/opt_out.

Re: [beagleboard] Flashing BBB eMMC without using uSD card

[smith . winston . 101]

On Tuesday, August 27, 2013 9:46:04 AM UTC-4, Gerald wrote:
>
> There is work going on to create such a tool. It just sin't ready, And no, 
> I have mo idea when it will be ready. We uses the SD card to flash the eMMC 
> and a flashing tool already exists for the SD card.
>

Do you have any more information on this?  Is it a way to flash the BBB via 
USB from a Linux system?  Plugging in a USB cable burning the boot & rootfs 
images directly somehow seems quicker than creating a flasher image, 
burning the micro-SD, inserting it, powering it up with the boot button 
pressed etc.

Thanks.
 

-- 
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/groups/opt_out.

[beagleboard] Device Tree: UART with h/w flow control without breaking anything else?

[smith . winston . 101]

I've been through the expansion header pinouts trying to come up with a 
.dts configuration that enables a UART with hardware flow control (so TXD, 
RXD, CTS and RTS) but does NOT break any of i2c2, HDMI or the eMMC.

   - uart0: Serial console, I need that already! (but it doesn't have 
   RTS/CTS on J1)
   - uart1: RTS/CTS conflict with i2c2 (and RXD/TXD conflicts with i2c1!)
   - uart2: Has no hardware flow control pins exposed, conflicts with i2c2
   - uart3: Is missing the RXD pin (and no h/w flow control!)
   - uart4: RTS/CTS conflict with HDMI
   - uart5: Conflicts with HDMI
   

Am I right here?  Is it not possible to do this?

If it cannot be done, I guess I can live with out i2c -- there's a SPI 
version of what I need and SPI0 doesn't conflict with uart1.  But I still 
have the following error due to the uart1_ctsn conflict with i2c2_sda;

pinctrl-single 44e10800.pinmux: pin 44e10978 already requested by 
4819c000.i2c; cannot claim for 48022000.serial
Anyone know how to disable i2c2? [the cape mgr eeprom]?  I'm not sure which 
wins here ... i2c2 or uart1.

Thanks

-W.

-- 
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/groups/opt_out.

[beagleboard] Re: Can't get serial connection to BBB on OSX 10.8.4

[smith . winston . 101]

On Wednesday, October 16, 2013 8:39:30 PM UTC-4, steview...@gmail.com wrote:
>
> Thank you very much for the info, it really helped me understand whats 
> going on. It looks like it would be nice to have one of those FTDI-USB 
> adapters.
>
> I have another question now - what the difference between the TX/RX pins 
> on J1 versus all of the serial pins on P8/P9? (P9-11 UART4_RXD, P9-13 
> UART4_TXD, etc..)
>

They just belong to different UARTs.  The connections on J1 are wired up to 
UART0 which mapped to /dev/ttyO0 and used as the serial console.  If you 
want to use the other UARTs (which are not enabled by default), then you 
first need to enable them by loading the appropriate device tree overlay. 
 If you look in /lib/firmware, you'll see a number of pre-prepared sample 
dtbo files for configuring different things.  For example, if you want to 
load BB-UART5.dtbo to enable UART5 (P8 pins 37,38) you need to add the 
following to the kernel command line (in uEnv.txt in the mmcblk0p0 FAT/boot 
partition):

capemgr.enable_partno=BB-UART5

The reason for this is that the AM335x has many more functions than pins, 
so you need to do something called pinmuxing in which you enable the 
features you want by configuring the pins into the appropriate mode.  It 
used to be that if the features you wanted were not available by default, 
you had to edit the platform file in the kernel sources and build your own 
kernel, now fortunately, you can do this with the device tree overlays 
(.dts files).

If you want to get into the details of serial ports, pinmuxing and device 
tree overlays, take a look here:

http://hipstercircuits.com/enable-serialuarttty-on-beaglebone-black/


-W.


-- 
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/groups/opt_out.

[beagleboard] Re: Cape PCB outline in DXF, anyone?

[smith . winston . 101]

On Tuesday, October 15, 2013 4:15:53 PM UTC-4, Jesper We wrote:
>
> I am thinking somewhere out there there is someone who has a nice 2D CAD 
> drawing of what a Cape PCB should look like
>
> I'm looking for a file to import to my PCB layout S/W. Board outline, 
> connector and hole positions would be really nice :-)
>
> Anyone willing to export a DXF for this purpose? (I'm pretty sure there 
> are many that would benefit from it being available!!)
>
>
If you're using Eagle, then this might be what you need:

http://www.adafruit.com/blog/2011/12/22/adafruit-eagle-library-now-with-beagle-bone-outline/


-W. 

-- 
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/groups/opt_out.

[beagleboard] Re: AM3352-SOM module

[smith . winston . 101]

On Thursday, July 25, 2013 10:27:57 AM UTC-4, Tsvetan wrote:
>
> our AM3352-SOM prototypes were assembled today 
>
> http://olimex.wordpress.com/2013/07/25/am3352-som-module-with-1ghz-sitara-cortex-a8-soc-prototypes-are-ready/
>  
> we test them now and they boot Debian hf for BeagleBoneBlack successfully 
>

This is very interesting ... I'm thinking about building a board based on 
the AM335x.  Right now I'm building capes with the additional RF modules I 
need, it works well enough, but I'd rather have a single, custom board 
(hopefully cheaper and requires less assembly!).  However, there's a big 
difference between designing and producing a simple, low component count 
cape and a complete SOC based linux system such as yours (or the BBB/RPi 
etc).

Do you (or anyone else!) have any thoughts or insight about the process of 
building a custom board such as this?  You mention the cost as being €26 
ea. in quantities of 1K, can you share any numbers on design costs (or was 
that in house) and setup costs for a run.  Your board seems quite close 
both in features (aside from my RF modules) and price to what I'm looking 
to build.

BTW: I have looked at Gumstix's Geppetto , 
but there doesn't seem to be enough options as yet, and by building a 
AM335x based board, (as you mention) the software support is excellent.

Thanks.

-- 
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/groups/opt_out.

[beagleboard] Re: Can't get serial connection to BBB on OSX 10.8.4

[smith . winston . 101]

On Sunday, October 13, 2013 9:56:20 PM UTC-4, steview...@gmail.com wrote:
>
> I'm kind of a newbie, just got a brand new BBB.
>
> I installed the FTDI driver that shipped with the BBB. Checked the 
> Info.plist, file was patched. Rebooted computer, reconnected BBB USB, 
> waited for BBB to boot, checked out "ls /dev/tty* " to see if I got a 
> tty.usbserial in there somewhere. Nothing! I'm trying to use *screen 
> /dev/tty.usbserial*B 115200* so I have terminal access to the board. Can 
> anyone help me?
>

There is no serial-over-USB on the BB-Black (that *really* was a nice 
feature of the BB-White!).  Fortunately, the BBB has it's serial console 
pins exposed on J1, here's a bit more info:

http://dave.cheney.net/2013/09/22/two-point-five-ways-to-access-the-serial-console-on-your-beaglebone-black

-- 
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/groups/opt_out.

[beagleboard] Re: Which branch for building OE? v2012.12-yocto1.3 still or v2013.06-yocto1.4?

[smith . winston . 101]

On Monday, October 14, 2013 6:31:12 AM UTC-4, rchrd...@gmail.com wrote:
>
> How does one use git to select angstrom-v2013.06. I would hope this later 
> branch has USB driver fixes included (ie babble and hotplug).
>
>>
>>
It's just a question of which branch you're in, after step #2 in your list, 
do:

git checkout angstrom-v2013.06-yocto1.4

Then continue with step #3 onwards (step #5 will have a suffix of 
...2013.06 rather than 2012.12).


-W

-- 
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/groups/opt_out.

[beagleboard] Re: Which branch for building OE? v2012.12-yocto1.3 still or v2013.06-yocto1.4?

[smith . winston . 101]

On Friday, October 11, 2013 11:03:16 AM UTC-4, smith.wi...@gmail.com wrote:
>
> Last time I built OE for the BBB, the recommendation was to 
> use angstrom-v2012.12-yocto1.3 as angstrom-v2013.06-yocto1.4 didn't 
> compile.  That was in August, now I see that there's 
> a angstrom-v2013.12-yocto1.5 in 
> https://github.com/Angstrom-distribution/meta-angstrom/blob/master/README
>
> 1) Does this mean angstrom-v2013.06-yocto1.4 is now "stable" and I should 
> be using this?  
> 2) What branch was the 2013.09.04 production release built with?
>
>
To answer my own query, I built both and they both work.  So I guess 
angstrom-v2013.06-yocto1.4 is "newer".

-- 
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/groups/opt_out.

[beagleboard] Which branch for building OE? v2012.12-yocto1.3 still or v2013.06-yocto1.4?

[smith . winston . 101]

Last time I built OE for the BBB, the recommendation was to 
use angstrom-v2012.12-yocto1.3 as angstrom-v2013.06-yocto1.4 didn't 
compile.  That was in August, now I see that there's 
a angstrom-v2013.12-yocto1.5 in 
https://github.com/Angstrom-distribution/meta-angstrom/blob/master/README

1) Does this mean angstrom-v2013.06-yocto1.4 is now "stable" and I should 
be using this?  
2) What branch was the 2013.09.04 production release built with?

Thanks!


-W.

-- 
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/groups/opt_out.

[beagleboard] DT overlay for GPIO output pin -- default state="on" / init-high

[smith . winston . 101]

I have created a device tree (DT) overlay file based on the examples in 
/lib/firmware for a GPIO pin to be used to control a relay that powers a 
peripheral.  As long as the GPIO is output/high the relay is closed and the 
peripheral has power,   So consequentially, I need the GPIO pin to have a 
default state of "high" as soon as possible after BBB is powered up.

Everything seems to work (after disabling HDMI!), but I don't seem to be 
able to get it to set the pin state to high by default.  I'm loading the DT 
overlay via the uEnv command line, but it seems that until I manually go 
and export the GPIO pin and set the direction to "high" in /sys/class/gpio, 
the initial state of the pin stays low until explicitly set high.

I handle the pinmux as follows:

fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
my_gpio_pins: pinmux_my_gpio_pins {
pinctrl-single,pins = <
/* the gpio pin(s) */
0x0B4 0x0F /* P8 42 GPIO2_11: lcd_data5.gpio2_11 | MODE7 | OUTPUT */
>;
};
};
};

And add it as an OCP as follows:

fragment@2 {
target = <&ocp>;
__overlay__ {

my_gpio {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&my_gpio_pins>;

/* declare your gpios */
my_relay {
gpio-name = "my_relay";
gpio = <&gpio3 11 0x00>; /* gpio3 is gpio2 */
output;
*init-high;*
};
};
};
};

Shouldn't the "init-high" cause the pin to go high as soon as the DT 
overlay is loaded?  If not, how do I accomplish this?  I realize I can 
write an rc script to export the gpio and set direction=high, but we're 
probably talking 10 seconds after power up before that happens.

I have also tried using default-state="on" in the my_relay{} section which 
doesn't do anything either.

Finally, a question -- the gpio-name of "my_relay", what is this for?  I 
kind of assumed it would be an alias in the /sys/class/gpio tree to gpio75, 
but I don't find any references to "my_relay" anywhere in the /sys/class 
tree (or even in dmesg output for that matter).

Thanks!


-W

-- 
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/groups/opt_out.