Cross-compiling Beaglebone on amd64

Well I got tired of using crochet as a crutch and I figured out how to cross compile for Beaglebone. At first I cheated and wrote to the microSD Card, but I buckled down and figured out how to manipulate a memory disk.

Code:
[Copy Source to Build Dir]
mkdir /BBB
cp -vipr /usr/src /BBB/src
mkdir /mnt1

[Setup env]
setenv BASEDIR /BBB
setenv MAKEOBJDIRPREFIX $BASEDIR/obj
setenv TARGET arm
setenv TARGET_ARCH armv6

[Move to base dir and build world and kernel]
cd $BASEDIR/src
make -j8 buildworld TARGET=arm TARGET_ARCH=armv6 UBLDR_LOADADDR=0x88000000 -DWITH_FDT __MAKE_CONF=/dev/null SRCCONF=/dev/null
make buildkernel TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE

[Create image file and format memory disk]
truncate -s 1500M /BBB/bbb.img
mdconfig -f /BBB/bbb.img -u md0
gpart create -s MBR md0
gpart add -t \!12 -s 10m md0
newfs_msdos -F12 -L 'MSDOSBOOT' /dev/md0s1
gpart set -a active -i 1 md0

[Mount Fat slice and copy uboot and ubldr]
mount_msdosfs /dev/md0s1 /mnt
cp -vipr /usr/local/share/u-boot/u-boot-beaglebone/ /mnt
cp /BBB/obj/arm.armv6/BBB/src/sys/boot/arm/uboot/ubldr /mnt
cp /BBB/obj/arm.armv6/BBB/src/sys/boot/arm/uboot/ubldr.bin /mnt
umount /mnt

[Partition freebsd]
gpart add -t freebsd md0
gpart create -s BSD md0s2
gpart add -t freebsd-ufs md0s2
newfs /dev/md0s2a
#tunefs -N enable -j enable -t enable /dev/md0s2a
mount /dev/md0s2a /mnt1

[Copying world and kernel to memory disk]
make installworld TARGET_ARCH=armv6 DESTDIR=/mnt1
make distribution TARGET_ARCH=armv6 DESTDIR=/mnt1
make installkernel TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE DESTDIR=/mnt1

[Install Setup]
touch /mnt1/firstboot
mkdir /mnt1/boot/msdos

[Create an /etc/fstab for mounts]
ee /mnt1/etc/fstab
# Custom /etc/fstab for FreeBSD embedded images
/dev/mmcsd0s1    /boot/msdos    msdosfs rw,noatime    0 0
/dev/mmcsd0s2a    /        ufs rw,noatime        1 1

[Create an /etc/rc.conf]
ee /mnt1/etc/rc.conf
hostname="beaglebone"
ifconfig_DEFAULT="DHCP"
sshd_enable="YES"
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

[Make links to dtb files]
ln /mnt1/boot/dtb/beaglebone.dtb /mnt1/boot/dtb/am335x-bone.dtb
ln /mnt1/boot/dtb/beaglebone-black.dtb /mnt1/boot/dtb/am335x-boneblack.dtb

[Complete setup by unmounting and shut down memory disk]
umount /mnt1
mdconfig -d -u0
Then you have an image to dd.
 
Last edited:
Found these 3 critical lines in /usr/src/release/arm/BEAGLEBONE.conf
Code:
    chroot ${CHROOTDIR} ln ${UFSMOUNT}/boot/dtb/beaglebone.dtb \
        ${UFSMOUNT}/boot/dtb/am335x-bone.dtb
    chroot ${CHROOTDIR} ln ${UFSMOUNT}/boot/dtb/beaglebone-black.dtb \
        ${UFSMOUNT}/boot/dtb/am335x-boneblack.dtb
    chroot ${CHROOTDIR} touch ${UFSMOUNT}/firstboot
This was what I was missing. Retooling now and will update.
 
Simple error as I forgot to make a directory for my fstab mount.

I now have a booting Beaglebone build. I updated my instructions.
 
#tunefs -N enable -j enable -t enable /dev/md0s2a
I edited this line out as I was not sure if I should run tunefs on the memory disk.
It seems it would be ideal for firstboot to run tunefs on the native disk.

Does anybody know where the firstboot rc.d script resides? I cant seem to find it in /etc/rc.d.
 
I see. So firstboot is not a script per say but a "KEYWORD" for use in rc.d scripts. Only finding growfs using it so far.
Colin has some ports for using firstboot. This one adds packages using firstboot.
sysutils/firstboot-pkgs/
 
The nice thing about building it by hand is you realize the nuances.
I would have never guessed that 2 of the dtb files in /boot/dtb were symbolic links to the other 2 dtb files in the same directory.
My guess this linking is done to support the Linux naming regime.
 
Last edited:
Crochet doesn't use the symbolic links. They use /boot/loader.conf to point to the dtb:

/boot/loader.conf
fdt_file="beaglebone-black.dtb"
 
Well I got tired of using crochet as a crutch and I figured out how to cross compile for Beaglebone. At first I cheated and wrote to the microSD Card, but I buckled down and figured out how to manipulate a memory disk.

Code:
[Copy Source to Build Dir]
mkdir /BBB
cp -vipr /usr/src /BBB/src
mkdir /mnt1

[Setup env]
setenv BASEDIR /BBB
setenv MAKEOBJDIRPREFIX $BASEDIR/obj
setenv TARGET arm
setenv TARGET_ARCH armv6

[Move to base dir and build world and kernel]
cd $BASEDIR/src
make -j8 buildworld TARGET=arm TARGET_ARCH=armv6 UBLDR_LOADADDR=0x88000000 -DWITH_FDT __MAKE_CONF=/dev/null SRCCONF=/dev/null
make buildkernel TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE

[Create image file and format memory disk]
truncate -s 1500M /BBB/bbb.img
mdconfig -f /BBB/bbb.img -u md0
gpart create -s MBR md0
gpart add -t \!12 -s 10m md0
newfs_msdos -F12 -L 'MSDOSBOOT' /dev/md0s1
gpart set -a active -i 1 md0

[Mount Fat slice and copy uboot and ubldr]
mount_msdosfs /dev/md0s1 /mnt
cp -vipr /usr/local/share/u-boot/u-boot-beaglebone/ /mnt
cp /BBB/obj/arm.armv6/BBB/src/sys/boot/arm/uboot/ubldr /mnt
cp /BBB/obj/arm.armv6/BBB/src/sys/boot/arm/uboot/ubldr.bin /mnt
umount /mnt

[Partition freebsd]
gpart add -t freebsd md0
gpart create -s BSD md0s2
gpart add -t freebsd-ufs md0s2
newfs /dev/md0s2a
#tunefs -N enable -j enable -t enable /dev/md0s2a
mount /dev/md0s2a /mnt1

[Copying world and kernel to memory disk]
make installworld TARGET_ARCH=armv6 DESTDIR=/mnt1
make distribution TARGET_ARCH=armv6 DESTDIR=/mnt1
make installkernel TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE DESTDIR=/mnt1

[Install Setup]
touch /mnt1/firstboot
mkdir /mnt1/boot/msdos

[Create an /etc/fstab for mounts]
ee /mnt1/etc/fstab
# Custom /etc/fstab for FreeBSD embedded images
/dev/mmcsd0s1    /boot/msdos    msdosfs rw,noatime    0 0
/dev/mmcsd0s2a    /        ufs rw,noatime        1 1

[Create an /etc/rc.conf]
ee /mnt1/etc/rc.conf
hostname="beaglebone"
ifconfig_DEFAULT="DHCP"
sshd_enable="YES"
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

[Make links to dtb files]
ln /mnt1/boot/dtb/beaglebone.dtb /mnt1/boot/dtb/am335x-bone.dtb
ln /mnt1/boot/dtb/beaglebone-black.dtb /mnt1/boot/dtb/am335x-boneblack.dtb

[Complete setup by unmounting and shut down memory disk]
umount /mnt1
mdconfig -d -u0
Then you have an image to dd.
Hi, I tried above procedure for cross compiling FreeBSD's SDIO driver(From release 11.1.0) for BBB but always ran low of swap space while buildworld. I have my FreeBSD 11.1.0 AMD setup on virtual box with following configuration :
Bash:
$ swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/gpt/swapfs   1048576     6748  1041828     1%
/dev/md99          524288     6376   517912     1%
Total             1572864    13124  1559740     1%
$ sysctl hw.physmem
hw.physmem: 1756221440
$ dmesg | grep memory
real memory  = 1789853696 (1706 MB)
avail memory = 1692106752 (1613 MB)
$ df /
Filesystem      1K-blocks    Used    Avail Capacity  Mounted on
/dev/gpt/rootfs  20307196 4543704 14138920    24%    /
$ du -sh /
4.3G    /
 
1.5 Gigs of RAM seems like a small amount to be feeding it. Can't you increase this with VirtualBox?

I use no swap drives but use 16gb RAM on bare metal.
 
Would this system help (ARMv6 Jail on an amd64 host)?
https://forums.freebsd.org/threads/arm-or-sparc-in-freebsd-jail-on-amd64-host.65130/

Basically it is quite easy to set up a jail to utilize qemu-user-static so that you can run an ARMv7 userland inside a Jail on an x86_64 host. Then you can simply use clang, cmake, vim, tmux, etc... to develop / test the software in the emulated jail environment.

I have tried and have it working using the userland provided by the Raspberry Pi image (ARMv6) here: https://download.freebsd.org/ftp/releases/arm/armv6/ISO-IMAGES/11.1 but I assume it will work in exactly the same way for BBB.
 
1.5 Gigs of RAM seems like a small amount to be feeding it. Can't you increase this with VirtualBox?

I use no swap drives but use 16gb RAM on bare metal.
I increased RAM usage to 2 Gb along with swap memory to 3.5Gb and this time with -j7 option i had success in buildworld
 
I am glad to see you got a post on the arm mailing list. I was wondering what you were doing with the SIO driver.

A link to your blog.
http://81.4.107.225/wordpress/index...ting-a-mmc-sd-sdio-stack-using-cam-framework/

Feel free to ask any questions you might have. We will help the best we can.
Thanks for your contributions.
Thanks. I am actually pursing a project of importing FreeBSD's SDIO driver to RTEMS. So, I am making an attempt to understand it's CAM architecture and implementation.
 
BTW, Above method for cross compiling for BBB on AMD works perfectly for latest versions(I have tested it multiple times on various branches). However, I tried making an older version of freebsd with above method and had following error:

Bash:
Mounting from ufs:/dev/mmcsd0s2a failed with error 19.                         
Trying to mount root from ufs:mmcsd0s2 []...                                   
mountroot: waiting for device mmcsd0s2...                                       
Mounting from ufs:mmcsd0s2 failed with error 19.                               
                                                                                
Loader variables:                                                               
  vfs.root.mountfrom=ufs:/dev/mmcsd0s2a                                         
  vfs.root.mountfrom.options=rw,noatime                                         
                                                                                
Manual root filesystem specification:                                           
  <fstype>:<device> [options]                                                   
      Mount <device> using filesystem <fstype>                                 
      and with the specified (optional) option list.                           
                                                                                
    eg. ufs:/dev/da0s1a                                                         
        zfs:tank                                                               
        cd9660:/dev/cd0 ro                                                     
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)           
                                                                                
  ?               List valid disk boot devices                                 
  .               Yield 1 second (for background tasks)                         
  <empty line>    Abort manual input                                           
                                                                                
mountroot>

Here is the complete log: https://gist.github.com/madaari/0d012361b956020cb107ff7accc3c3b2. This error seems somewhat same as the one reported here. What can be the possible solution of this, apart from switching to latest FreeBSD version? Will using an older u-boot version work?
 
Using that github repository could be troubling because of its age. Like you said its a 6 month old -CURRENT revision.
I would keep my eye on -CURRENT and make sure nothing is changing in the MMCCAM driver.
RTOS work probably shouldn't use -CURRENT code as it is a testing version. But I would keep apprised of the driver development. Make sure that there are no major chances anticipated.

I had never heard of RTEMS. I like the approach and the license:
2- and 3-clause BSD, MIT, and other OSI-approved non-copyleft licenses that permit statically linking with code of different licenses are acceptable.

What is the kernel ???
You seen this ticket?
https://devel.rtems.org/ticket/2891
Re:uboot
GPL3 is a problem and so a BSD-licensed alternative to do the same thing would be better.


I am afraid you might be stuck with uboot. There is no BSD alternative. Free/Net/Open all use uboot.
Maybe look at libreboot. I don't think they do arm.
 
Using that github repository could be troubling because of its age. Like you said its a 6 month old -CURRENT revision.
I would keep my eye on -CURRENT and make sure nothing is changing in the MMCCAM driver.
RTOS work probably shouldn't use -CURRENT code as it is a testing version. But I would keep apprised of the driver development. Make sure that there are no major chances anticipated.

I had never heard of RTEMS. I like the approach and the license:
2- and 3-clause BSD, MIT, and other OSI-approved non-copyleft licenses that permit statically linking with code of different licenses are acceptable.

What is the kernel ???
You seen this ticket?
https://devel.rtems.org/ticket/2891
Re:uboot
GPL3 is a problem and so a BSD-licensed alternative to do the same thing would be better.


I am afraid you might be stuck with uboot. There is no BSD alternative. Free/Net/Open all use uboot.
Maybe look at libreboot. I don't think they do arm.

Sure, I infact tried with the CURRENT FreeBSD version but encountered a kernel panic (logs: here, freebsd-arm: thread).
For importing to RTEMS, I am currently searching and trying different branches of freeBSD, to find the best stable branch with working SDIO driver.

Git:
mory  = 536870912 (512 MB)                                               
avail memory = 510996480 (487 MB)                                               
Texas Instruments AM335x Processor, Revision ES2.1                             
arc4random: no preloaded entropy cache                                         
random: entropy device external interface                                       
kbd0 at kbdmux0                                                                 
ofwbus0: <Open Firmware Device Tree>                                           
simplebus0: <Flattened device tree simple bus> on ofwbus0                       
simplebus1: <Flattened device tree simple bus> on simplebus0                   
simplebus2: <Flattened device tree simple bus> mem 0x210000-0x211fff on simpleb1
ti_scm0: <TI Control Module> mem 0-0x7ff on simplebus2                         
ti_aintc0: <TI AINTC Interrupt Controller> mem 0x48200000-0x48200fff on simpleb0
ti_aintc0: Revision 5.0                                                         
am335x_prcm0: <AM335x Power and Clock Management> mem 0x200000-0x203fff on simp1
am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz                             
cpulist0: <Open Firmware CPU Group> on ofwbus0                                 
cpu0: <Open Firmware CPU> on cpulist0                                           
pmu0: <Performance Monitoring Unit> mem 0x4b000000-0x4bffffff irq 0 on ofwbus0 
ti_pinmux0: <TI Pinmux Module> mem 0x800-0xa37 on simplebus2                   
am335x_scm0: <AM335x Control Module Extension> on ti_scm0                       
gpio0: <TI AM335x General Purpose I/O (GPIO)> mem 0x44e07000-0x44e07fff irq 7 o0
gpiobus0: <OFW GPIO bus> on gpio0                                               
gpioc0: <GPIO controller> on gpio0                                             
gpio1: <TI AM335x General Purpose I/O (GPIO)> mem 0x4804c000-0x4804cfff irq 8 o0
gpiobus1: <OFW GPIO bus> on gpio1                                               
gpioc1: <GPIO controller> on gpio1                                             
gpio2: <TI AM335x General Purpose I/O (GPIO)> mem 0x481ac000-0x481acfff irq 9 o0
gpiobus2: <OFW GPIO bus> on gpio2                                               
gpioc2: <GPIO controller> on gpio2                                             
gpio3: <TI AM335x General Purpose I/O (GPIO)> mem 0x481ae000-0x481aefff irq 10 0
gpiobus3: <OFW GPIO bus> on gpio3                                               
gpioc3: <GPIO controller> on gpio3                                             
��uart0: <TI UART (16550 compatible)> mem 0x44e09000-0x44e0afff irq 11 on simpl0
uart0: console (115384,n,8,1)                                                   
iichb0: <TI I2C Controller> mem 0x44e0b000-0x44e0bfff irq 17 on simplebus0     
iichb0: I2C revision 4.0 FIFO size: 32 bytes                                   
iichb1: <TI I2C Controller> mem 0x4819c000-0x4819cfff irq 19 on simplebus0     
iichb1: I2C revision 4.0 FIFO size: 32 bytes                                   
sdhci_ti0: <TI MMCHS (SDHCI 2.0)> mem 0x48060000-0x48060fff irq 20 on simplebus0
sdhci_ti0: Custom-disabling 8-bit bus                                           
mmc_alloc_device()                                                             
sdhci_ti1: <TI MMCHS (SDHCI 2.0)> mem 0x481d8000-0x481d8fff irq 21 on simplebus0
sdhci_ti1: Custom-disabling 8-bit bus                                           
mmc_alloc_device()                                                             
ti_wdt0: <TI Watchdog Timer> mem 0x44e35000-0x44e35fff irq 23 on simplebus0     
ti_mbox0: <TI System Mailbox> mem 0x480c8000-0x480c81ff irq 26 on simplebus0   
ti_mbox0: revision 4.0                                                         
am335x_dmtimer0: <AM335x DMTimer2> mem 0x48040000-0x480403ff irq 28 on simplebu0
Event timer "DMTimer2" frequency 24000000 Hz quality 500                       
am335x_dmtimer1: <AM335x DMTimer3> mem 0x48042000-0x480423ff irq 29 on simplebu0
Timecounter "DMTimer3" frequency 24000000 Hz quality 500                       
am335x_rtc0: <AM335x RTC (power management mode)> mem 0x44e3e000-0x44e3efff irq0
am335x_rtc0: AM335X RTC v1.0.6                                                 
usbss0: <TI AM33xx integrated USB OTG controller> mem 0x47400000-0x47400fff on 0
usbss0: TI AM335X USBSS v0.0.13                                                 
musbotg0: <TI AM33xx integrated USB OTG controller> mem 0x47401400-0x474017ff,00
usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM             
usbus0 on musbotg0                                                             
musbotg1: <TI AM33xx integrated USB OTG controller> mem 0x47401c00-0x47401fff,00
usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM             
usbus1 on musbotg1                                                             
cpswss0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a1007ff,0x4a101200
cpswss0: CPSW SS Version 1.12 (0)                                               
cpswss0: Initial queue size TX=128 RX=384                                       
cpsw0: <Ethernet Switch Port> on cpswss0                                       
miibus0: <MII bus> on cpsw0                                                     
smscphy0: <SMC LAN8710A 10/100 interface> PHY 0 on miibus0                     
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto                 
cpsw0: Ethernet address: 68:9e:19:6f:38:cd                                     
fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 43 on simplebus0     
ti_adc0: <TI ADC controller> mem 0x44e0d000-0x44e0dfff irq 44 disabled on simpl0
ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0                 
gpioled0: <GPIO LEDs> on ofwbus0                                               
cryptosoft0: <software crypto>                                                 
Timecounters tick every 1.000 msec                                             
iicbus0: <OFW I2C bus> on iichb0                                               
iic0: <I2C generic I/O> on iicbus0                                             
am335x_pmic0: <TI TPS65217 Power Management IC> at addr 0x48 irq 58 on iicbus0 
iicbus0: <unknown card> at addr 0xa0                                           
tda0 at addr 0xe0 on iicbus0                                                   
iicbus1: <OFW I2C bus> on iichb1                                               
iic1: <I2C generic I/O> on iicbus1                                             
iicbus1: <unknown card> at addr 0xa8                                           
iicbus1: <unknown card> at addr 0xaa                                           
iicbus1: <unknown card> at addr 0xac                                           
iicbus1: <unknown card> at addr 0xae                                           
(noperiph:sdhci_slot0:0:-1:ffffffff): xpt_async(AC_PATH_REGISTERED)             
mmc_dev_async(async_code=0x20, path_id=0, target_id=0, lun_id=0                 
Got AC_PATH_REGISTERED -- whatever...                                           
mmc_dev_async(async_code=0x20, path_id=0, target_id=ffffffff, lun_id=ffffffff   
(noperiph:sdhci_slot1:0:-1:ffffffff): xpt_async(AC_PATH_REGISTERED)             
mmc_dev_async(async_code=0x20, path_id=1, target_id=0, lun_id=0                 
Got AC_PATH_REGISTERED -- whatever...                                           
mmc_dev_async(async_code=0x20, path_id=1, target_id=ffffffff, lun_id=ffffffff   
usbus0: 480Mbps High Speed USB v2.0                                             
usbus1: 480Mbps High Speed USB v2.0                                             
(noperiph:sdhci_slot0:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN}                   
Kernel page fault with the following non-sleepable locks held:                 
exclusive sleep mutex CAM device lock (CAM device lock) r = 0 (0xc30e1464) lock2
stack backtrace:                                                               
Fatal kernel mode data abort: 'Translation Fault (L1)' on read                 
trapframe: 0xd0dc0ac0                                                           
FSR=00000005, FAR=00000010, spsr=60000013                                       
r0 =00000061, r1 =00000188, r2 =d0dc0a8c, r3 =60000013                         
r4 =c30e0000, r5 =c30dec40, r6 =00000000, r7 =d0dc0b68                         
r8 =c086f528, r9 =c068f050, r10=00000000, r11=d0dc0d10                         
r12=00000062, ssp=d0dc0b50, slr=c002b77c, pc =c002b5c0                         
                                                                                
[ thread pid 4 tid 100048 ]                                                     
Stopped at      mmc_action+0x94:        ldr     r6, [r6, #0x010]               
db>

AFAIK, as an alternative of uboot , last time umon(http://www.umonfw.com/) with apache license was used. There's a lot more to be said about RTEMS, but i'm afraid, that would render this post a bit off topic.
 
I also noted a Coreboot BSP for the Beaglebone(very very limited and GPL).
I didn't see anything in Libreboot
 
Well call me ignorant but could you explain what the GENERIC-MMCCAM kernel does that is different than the GENERIC Beaglebone kernel.
 
It builds the MMCCAM driver instead of SDHCI. And that's where the problem lies. It looks like, current MMCCAM driver is broken as it leads to the following kernel panic(log):
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex CAM device lock (CAM device lock) r = 0 (0xc30e1464) lock2

BTW, I have something else, which might interest you. I did some sd card benchmarking on freebsd using SDHCI and MMCCAM driver, to compare their performance. Here's the result
 
Back
Top