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.