@henrix - firstly thank you for all your efforts getting the CTAG boards into our hands!

I am able to flash a microSD with bela_image_v0.3.6b.img and (using my MacBook Pro with OS 10.12.6) access the BBB via USB to SSH 192.168.7.2 as expected. I have used this BBB many times without issue.

However, when I flash the same microSD with ctag_bone_debian_v0.1.2.img, my Mac does not behave in the same way resulting in my not being able to SSH the BBB (via USB) at all. When I look in my System Preferences -> Network, the BeagleBoneBlack interface shows as only having a "Self-Assigned IP".

I have tried two different MacBook Pros with the same result. I have also tried installing/re-installing HoRNDIS and FTDIUSBSerial drivers, but this has not changed my experience.

When the BBB is plugged into an ethernet cable connected to my home router, I have been able to SSH via the router's DHCP assigned IP. However, when I tried to run sudo ./load-ctag-beast-16ch-drivers.sh the BBB became unresponsive. I have tried multiple times with the same failed result.

I'm at a loss as to what's wrong. Any ideas?

    taggalucci bela_image_v0.3.6b.img

    nice to see it's in use: uploaded just yesterday!

    I don't know what is wrong with the bb.org image, but it seems like the DHCP is not working properly. You have two options:

    1)

    • use beaglebone.local instead of the IP: ssh debian@beaglebone.local (note the debian user; also, password is temppwd

    2)

    • Find the name for the interface running ifconfig, it will be enX (note there will be some more enX interfaces on your computer that are built-in and are not the board.
    • sudo ifpconfig set enX DHCP this should force the computer to go request an IP address from the board. If after this your computer sill has a self-assigned IP, try to brute force it:
      • if the board shows up as ONE network interface :
        • sudo ifconfig enX up 192.168.6.1
        • ssh debian@192.168.6.2
      • if the board shows up as TWO distinct interfaces, enX, enY(e.g.: because you have the Horndis drivers installed), you have to guess which one is which, one will have IP 192.168.6.x, the other 192.168.7.x:
        • sudo ifconfig enX up 192.168.6.1
        • ssh debian@192.168.6.2
        • if the ssh times out, undo the step above: sudo ifconfig enX down, and try the other interface:
        • sudo ifconfig enY up 192.168.6.1
        • ssh debian@192.168.6.2
          this should work, at last

      Hi taggalucci,

      Can you verify that no other ALSA sound cards are available after boot with aplay -l?
      Moreover, did you changed anything kernel related or in the uEnv.txt?

      Thanks @giuliomoro and @henrix

      When I run aplay -l I get...

      **** List of PLAYBACK Hardware Devices ****
      card 0: Black [TI BeagleBone Black], device 0: davinci-mcasp.0-i2s-hifi i2s-hifi-0 []
      Subdevices: 1/1
      Subdevice #0: subdevice #0

      No I have not modified anything. I downloaded the 0.1.2 image, decompressed and wrote to SD card using Etcher. Both DHCP issue and problem loading the Beast's drivers occur for me from this point.

      I'm able to work around the DHCP issue (although it seems odd that I'd need to given it works fine with other BBB images).

      I am still unable to load the Beast's drivers.

      Ha Ha! I've worked out how to get the Beast's drivers to load!!!

      Steps as follows:

      1. Using the Bela image 0.3.6b, insert the SD card
      2. Press the USER button and hold it while powering up the Beaglebone
      3. Once the board boots successfully, copy the new bootloader to the eMMC /opt/Bela/bela_flash_emmc.sh
      4. Power down and restart pressing the USER button again, but this time with 0.1.2 image on the SD card
      5. Run sudo ./load-ctag-beast-16ch-drivers.sh and then aplay -l to confirm

      This didn't resolve the DHCP issue, but that's easily worked around.

      Seems that the CTAG image requires the eMMC to have the Bela image on it (or at least whatever state the Bela image puts the eMMC in). I tried reformatting it so there was nothing on the eMMC, but this didn't work either. I previously had a stock BB.org image on the eMMC.

        hmm. I actually drafted a reply last night to confirm whether you actually had successfully booted from the CTAG image or whether it was still booting from the eMMC. Then I read back your first post:

        taggalucci wever, when I tried to run sudo ./load-ctag-beast-16ch-drivers.sh the BBB became unresponsive

        so I assumed that the file ./load-ctag-beast-16ch-drivers.sh actually was there, which would mean that you were indeed on the CTAG image.

        taggalucci I tried reformatting it so there was nothing on the eMMC, but this didn't work either.

        this should have totally worked. How did you try that?

        taggalucci Seems that the CTAG image requires the eMMC to have the Bela image on it (or at least whatever state the Bela image puts the eMMC in).

        Hmm. Do you have a guess of what version of the bb.org image you had on your eMMC? How old was it?

              Yes, I sure was on the CTAG image. This booted by default without needing to press the USER button during power up.

              After booting to the SD card, I formatted the eMMC using fdisk:

              • fdisk /dev/mmcblk1
              • o - this clears the existing partitions
              • p - this lists all partition tables on the card (there should be none)
              • n - create a new partition
              • p - primary partition
              • 1 - partition number
              • 2048 - default value for the first sector
              • +16M - last sector / partition size
              • t - change the partition type (defaults to selecting partition 1)
              • e - change the partition type to "W95 FAT16 (LBA)"
              • a - set the bootable flag for the selected partition (1)
              • n - create a new partition
              • p - primary partition
              • 2 - partition number
              • hit Enter to choose the default (next available) value for the first sector
              • hit Enter to choose the default (last) value for the last sector
              • p - this lists all partition tables on the card (there should be two)
              • w - write all the above changes to disk
              • umount /dev/mmcblk1p1; mkfs.vfat -F 16 /dev/mmcblk1p1 - format the first partition
              • umount /dev/mmcblk1p2; mkfs.ext4 /dev/mmcblk1p2 - format the second partition

              eMMC was running BBB-blank-debian-8.7-iot-armhf-2017-03-26-4gb.img

              Ok I get it now. My guess is that there was something in the uEnv file that was on the eMMC that did not actually load the overlays properly. Seeing how CTAG needs a specialized dtb, and not the default one, this may have been the reason?

              I will hand this over the @henrix as he knows better.

              Hi,

              As Giulio mentioned, the CTAG Image was booted as the scripts for loading the drivers were available. I believe there was something wrong in the uEnv, because the audio drivers of the factory Image were loaded. When booting with our dtb, this is not the case. Thus the BB became unresponsive. Anyways, glad you can use beast now.

              Thanks @giuliomoro and @henrix - I've run a basic stereo sound test using ALSA and it sounds like things are working as expected at this stage 🙂

              I ended up following the workaround in this post to write a uEnv.txt file on the root of the SD card so that I don't have to press the USER button when booting.

              As a test I've formatted the eMMC (as in my post above) so it doesn't have the Bela image on it. The CTAG image boots fine, but I get the same issue with trying to load the CTAG Beast's drivers.

              Once I return the eMMC to containing the Bela image, the drivers load as expected.

              @henrix Should the CTAG image really need to have the eMMC in a particular state to work correctly?

              @giuliomoro Should this thread be renamed? Started out as an SSH issue for me, but this is really about the configuration required to get the Beast's drivers to load.

              The CTAG Image should work independently of the eMMC Image. I'm using a BB with the factory Image on the eMMC. Could you please send your uEnv.txt and kernel version (uname -r) when you have the default Image on the eMMC (i.e. when your described problems occur)?

              Hi @henrix

              The problem of not being able to load the drivers also occurs when there is nothing on the eMMC, so there is no uEnv.txt or kernel version from that to post here.

              When booting to your 0.1.2 CTAG image, the kernel version is 4.4.62+.

              aplay -l confirms no soundcards found, but driver still fails to load, hangs the board and requires a hard reset.

              If I install the BBB-blank-debian-8.7-iot-armhf-2017-03-26-4gb.img (originally from here) that I originally had on the eMMC then when booting to the eMMC the kernel version is 4.4.55-ti-r94. There is no uEnv.txt file (only a bbb-uEnv.txt and a nfs-uEnv.txt).

              aplay -l reports the default Beaglebone sound device when booting either the eMMC or your 0.1.2 CTAG image.

              I have to restore the Bela image to the eMMC to get the beast's drivers to load from the 0.1.2 CTAG image.

              All of my experiences detailed above suggest that the CTAG image is not currently working independently of the eMMC image.

                uboot searches for uEnv.txt at several locations on the board. These include / and /boot. Not sure where else. Also, I think it's a bit confusing in the way it works: sometimes it uses (or it used to use) a uEnv.txt from the eMMC even when booting from the SD card.

                taggalucci If I install the BBB-blank-debian-8.7-iot-armhf-2017-03-26-4gb.img

                To have the CTAG overlays to work you need at least the CTAG custom base device tree, which is loaded by the custom uEnv.txt in the CTAG image. So, it's expected that a bb.org image will not work out of the box. Or do you mean that you place that image on the eMMC and then boot from the CTAG image from the SD card?

                  @taggalucci if the OS freezes after loading the CTAG drivers, do you get any error outputs? That would help to find the problem as I can't reproduce this issue. Or could you create an image of your SD for testing?

                  The kernel 4.4.62+ is definitely the right kernel for CTAG.