Avatar

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

jackhall

About

Username
jackhall
Joined
Visits
86
Last Active
Roles
Member
Points
5
Badges
0
  • Logibone with BeagleBone Black Wireless (booting from eMMC)

    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
    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
    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
    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 



    rki