jackhall

• Logibone with BeagleBone Black Wireless (booting from eMMC)

  jackhall

  July 2017
  Hello all, 

  
  

  I'm posting this here in hopes that I can save someone else the time and effort I've spent on trying to get the Logi-Bone R 1.5.1 (same as V2 Logibone on element14) communicating over SPI with the new BBB Wireless which runs a distribution of Debian Jessie. Below are the steps that I took, the biggest discovery for me was finding danielvilas' post here which explains how to use the logi-kernel repo to place the proper device tree overlay in /lib/firmware
  

  
  

  DISCLAIMER: I am not an expert with UNIX based systems or FPGA but I have dipped my feet in both before. If you see something that I am doing that is totally wrong and terrible practice (like when I add a root profile just in case I need it later....) please don't hesitate to point it out. I really just made this post to consolidate what I could find about getting BBB Wireless, a version of Jessie, and a Logi-bone playing together nicely while the OS is on eMMC.. Cheers!

  
  

  ## Begin by flashing eMMC with (Debian 8.7 2017-03-19 4GB SD LXQT ) then:#

  ################################################################

  # Set up wifi so we can connect without usb

  
  

  sudo connmanctl 

  tether wifi disable

  enable wifi

  scan wifi

  services

  agent on

  connect wifi_#_#

  
  

  # connect to your listed router wifi_#_# by entering appropriate passkey, then exit connmanctl by typing:

  exit 

  
  

  # Adding a root access profile to the board 

  sudo su

  # enter debian password (temppwd)

  passwd

  # enter and repeat new root password then turn off super user mode with:

  exit

  
  

  # edit this configuration file to confirm the root profile will be accessible over ssh

  sudo nano /etc/ssh/sshd_config

  
  

  CHANGE LINE FROM:

  PermitRootLogin without-password

  
  

  TO:

  PermitRootLogin yes

  
  

  # restarting ssh service to reflect updated permissions of root

  
  

  /etc/init.d/ssh restart

  sudo reboot

  
  

  ### Daniel Vilas' additions (from discussion "beaglebone shared pins, dts overlay") 

  # Update Kernel

  cd /opt/scripts/tools/

  git pull

  sudo ./update_kernel.sh

  sudo reboot

  
  

  # Update software and Install DTC

  sudo apt-get update

  sudo apt-get install device-tree-compiler 

  sudo reboot

  
  

  # Create and copy Device tree overlay from .dts

  cd /home/debian

  git clone https://github.com/fpga-logi/logi-kernel.git

  cd logi-kernel/beaglebone-black/logibone_r1/

  dtc -O dtb -o BB-BONE-LOGIBONE-00R1.dtbo -b 0 -@ BB-BONE-LOGIBONE-00R1.dts

  sudo cp BB-BONE-LOGIBONE-00R1.dtbo /lib/firmware

  
  

  # Add new device tree overlay to initial ram file system

  sudo update-initramfs -uk `uname -r`

  sudo poweroff

  
  

  ##########################################################

  ## For ESD protection: !!!DISCONNECT ALL WIRES!!!                           #

  ## Physically install Logibone 1.5.1 at this point, then:                             # 

  ##########################################################

  
  

  cd /home/debian

  git clone https://github.com/fpga-logi/logi-tools.git

  cd logi-tools/unified_loader/

  nano logi_loader.h 

    change all /dev/spidevX.X to dev/spidev1.0

  cd ..

  sudo ./install_logibone.sh

  sudo reboot

  
  

  cd /home/debian

  git clone -b logibone https://github.com/fpga-logi/logi-apps.git

  logi_loader logi-apps/blink_led_app/logibone_r1_blink.bit 

  
  

  sudo apt-get autoremove

  sudo reboot

  
  

  #####################################################################################

  Now that the Logibone is physically installed we can successfully write .bit files to it, we will look at the modifications needed to allow wishbone bus comm for applications such as streaming bytes of audio from a pdm mic on one of the logibones PMOS ports, or other sensors that have been configured with the FPGA

  
  

  By default, the uEnv.txt file in /boot will have lines commented out that look like this:

  
  

  ##Example v4.1.x

  #cape_disable=bone_capemgr.disable_partno=

  #cape_enable=bone_capemgr.enable_partno=

  
  

  change these lines to:

  cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

  cape_enable=bone_capemgr.enable_partno=BB-SPIDEV1,BB-SPIDEV0,BB-SPIDEV2

  
  

  The first line will disable to HDMI output relinquishing control of the three SPI pins which are then enabled for SPI functionality with the second line 

  after saving the changes to uEnv.txt, reboot and cat the following file:

  
  

  cat /sys/devices/platform/bone_capemngr/slots

  
  

  your output should look like this:

  
  

   cat /sys/devices/platform/bone_capemgr/slots

   0: P-----  -1 BB-BONE-LOGIBONE,00R1,VALENTFX,BB-BONE-LOGIBONE

   1: PF----  -1

   2: PF----  -1

   3: PF----  -1

   4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-SPIDEV1

   5: P-O-L-   1 Override Board Name,00A0,Override Manuf,BB-SPIDEV0

  
  

  I know you are probably concerned, as I was, about the lack of Loading being indicated in the slots file, but if you re-run 

  
  

  logi_loader /home/debian/logi-apps/blink_led_app/logibone_r1_blink.bit 
  

  
  

  It should still be loading .bit files properly.

  
  

  ## A caveat I'm realizing about Startup scripts on the BBB Wireless

  
  

  On the regular BeagleBone Black, if I wanted to add a script (in my example called recorder_startup.sh) to the initialization scripts of the BBB I would create a soft link of the desired script in the init.d folder of /etc and then update the init.d depend.start scripts by doing the following:

  
  

  sudo ln -s /home/debian/jack/recorder/recorder_startup.sh
  /etc/init.d # creates soft link

  sudo update-rc.d recorder_startup.sh defaults                                        # updates init.d scripts to add to depend.start

  
  

  In my recorder_startup.sh script, a C function called read_mic_data is called and I have found that on the BBB Wireless, for some reason, two instances of the read_mic_data program will be running if I run the startup script using just these steps, however, I can overcome this odd behavior by adding line 

  sleep 30

  to the top of recorder_startup.sh. Has anyone else experienced this increased boot time? I think it is possible that the init scripts are being called twice in the startup of this kernel and perhaps adding the sleep line to the script will cause the first call of the startup script to