Building and Trying...BeagleBone Black and Aufs


I have, am currently, used aufs to build the kernel. I found their info. on a dainty oops. Anyway, outside of the miracle accident that got me involved in aufs, I would like to understand a bit more.

Does the images that are available to build only for eMMC or is there a way to utilize the build instructions from this site to allow for SD Card image creation?


P.S. Right now, I used these commands to build my image:

1. install u-boot
2. compile u-boot
3. install the kernel
4. compile the kernel
5. Then, I started to listen to the eewiki Linux guides on this effort
6. install info. to /fstab
7. install debian
8. build debian to the /rootfs/ dir.
9. debian is now at /rootfs/
10. I altered some files for use...
    a. /opt/ and /boot/ and /etc/ only
    b. I put in the files and info. into those directories to build the image w/ debian at /dev/mmcblk0p1
        and at /dev/mmcblk0p2
11. As you might guess, I cannot boot.

When did /dev/mmcblk0 start and /dev/mmcblk0p1 and /dev/mmcblk0p2 stop?

I am asking trying to fill in the data of what happened and when…

aufs only allows for so much of ideas in their kernels, e.g. .dts files, modules are mostly hidden so far, and now I cannot boot.

I understand that this build from your ideas and knowledge is done and completed for now. I am not trying to follow along 100% of the time, i.e. as I would like to build differently and w/ other methods.

I will try to post the build. Oh!

are these builds for use w/ TTL to USB adapters or can I just plug and play w/ them? I may be mistaken but I think:

  1. These builds are for eMMC builds only
  2. The builds are for USB to TTL cable adapters also but only?


Sorry about the above garble. I will update this compilation, the steps taken, soon. I just realized w/out proper explanations, helping me is beyond the scope of what actually I typed in my first set of ideas.



This is what I did:

install dependencies...and then compile the main components!

git clone
cd u-boot/

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig 
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

xz -d linux-5.4.228.tar.xz
tar -xvfp linux-5.4.228.tar
cd linux-5.4.228/

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- omap2plus_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

This is now me following the references at eewiki for building the image that was made.

sudo cfdisk /dev/mmcblk0

... Either use two partitions or one partition depending on the year/make/model of the kernel/u-boot?

make it bootable
save yes

Then I basically follow all of the guide on the eewiki for the BeagleBone Black up until building the kernel modules and naming scheme for the kernel. If you see anything I am doing that is out of bounds, please let me know.


P.S. If there are a particular set of ideas I am missing, please instruct me.

Hi @silver2row a well debugged and fully supported how to is posted here: Debian: Getting Started with the BeagleBone Black

BeagleBone Blacks and similar devices have been shipping with this default configuration for probably 8-9 years now… It’s well tested and simpler then your split partition setup.


1 Like

Hello @RobertCNelson ,

No issue as usual. I am just recalling when I could build w/ one partition and a boot partition.

I do not think it was six years ago or so…

About the boards, like the BBB, for a bit there was ideas being allocated into the kernel, /arch/arm/boot/*/dts/*, slowly and made things change a bit. So I thought…

I could be way off base. Anyway, no issue.


P.S. I will keep trying, i.e. as there is a fellow trying to get i2s working on his BBBW (I think). Anyway, I was going to pitch in and keep building images while producing the correct build steps for him/her but came up short.

I2S works fine on the BBB.

No one made a reference I2S cape, so there is no reference overlay in our git repo.

So as long as you:

  1. Wire it up correctly
  2. Load the proper Overlay

It’ll work. There are a few threads in the ti e2e forums on custom wiring/device-tree/etc…


1 Like

Thank you…


P.S. I saw on the site in the docs. sections, there is a short on playing sound w/ ALSA. I sort of directed the person to that specified section of the docs.

The BBB has always had i2s audio, thru the HDMI port…


1 Like

The framer provides this support?


P.S. Right…the NXP onboard. That is the framer. So, it will be a hack from the am335x → NXP framer → HDMI → extra circuitry…

Why? SPI1_SCLK, SPI1_CS0, and SPI1_D0 used for i2s audio are between the am335x and the NXP framer, are routed on the P8/P9 header so users can use them directly…

Just disable TDA19988…


Oh…nice. I was unaware of this idea. I did not know how the i2s worked on the BBB.


P.S. Okay…I will keep reading about this idea.

Hello @RobertCNelson ,

I thought i2c0 was internal only…


P.S. So, the overlay gets allocated to /boot/uEnv.txt, then before the actual build of the source of the overlays, one would remove said TDA19988, and then finally build the overlays…

i2c and i2s are nothing alike, unlike a similar acronym… i2s is a serial point to point link…


To Disable HDMI AUDIO:



Okay and Right,

So, it is just disabling the HDMI audio in the u-boot via the already-made-available /boot/uEnv.txt file.

Then, one can use the sound and audio w/ SPI and not i2c.

I got confused I guess. Line 70 from the link above shows the &i2c0 phandle or directive (whatever it is called in DTS format) which showed the item in question.



That’s the node with tda19988, which shows the i2s configuration…


Okay and Yes Sir,

Node. It is called a node. I saw that a little too late.