As stated in my last post eMMC memory devices are quickly replacing native NAND memory on embedded devices. This can not happen soon enough in my opinion. If anyone has worked with native NAND and tried to get these working knows exactly what I am talking about.
The BeagleBone Black utilizes a 2Gb eMMC memory part for local, on board, bulk non-volatile storage. On later rev C boards the part was upgraded to 4Gb with no change in the footprint.
To fully support eMMC on the community BSP several modifications had to be made. Several drivers (SDHC, SDMEMORY and FATFS) had to be modified as well as the boot code. Support for sector mode addressing (eMMC parts greater than 2Gb) was also added.
The sdmemory driver needed some tweaks but for the most part the sdmemory library included with WEC2013 and WEC7 works as-is. This library handles the commands issued to the SD/SDHC/MMC/eMMC device and is also responsible for detecting which flavor of device is connected, among other tasks.
The SDHC also needed modification as this is the hardware specific layer that interfaces directly to the AM335x MMC/SDIO on-chip controller. The AM335x processor actually has three instances of the controller. One is connected to the uSD card cage on the Beaglebone, another is connected to the eMMC device and a third is not used. The uSD card cage is connected as a 4bit interface while the eMMC is connected as an 8bit interface (one of the subtle differences).
Once the drivers are working both devices (uSD and eMMC) should be able to mount as a separate drive under Windows Embedded. This is the easy part, much harder to develop and debug is the boot code. Basically, the same driver functionally has to be pushed down into the boot code but without the added benefits of a running OS. Things like threading and most of the API call are not available in the boot code. You also have limited operating memory and some very strict formatting requirements as imposed by the AM335x (I won’t go into all the gory details).
Partitioning is the next task. As I have stated before, the BeagleBone comes with Linux and the eMMC device comes from the factory with two working partitions. Unfortunately the factory FAT32 formatted boot partition is too small for most Windows Embedded images so re-partitioning is required.
I like having two partitions, one I’ll call the “BOOT” partition and this will hold the MLO, EBOOTSD.NB0 and NK.BIN files. It will also hold the hive based persistent registry files created after initial boot up. The second, larger partition will be the “Hard Disk” partition and is available for application use.
I created a “DISKPARTEMMC.EXE” partitioning tool and included it in the image to help with the partitioning and formatting tasks needed to properly configure the eMMC device for initial use. A simple batch file will kick off a script which will partition, format and copy the boot files to the eMMC memory. To use this tool it is very important to remember this batch file must ONLY be run when you have initially booted the device from a properly formatted uSD card (see on-line documentation on the community BSP’s for uSD card creation).
Here is what happens:
PREPEMMC will: Prompt you to make sure you booted from uSD card. Run the diskpartemmc executable with the partemmc.txt script file. The script will: Clean the MBR deleting all existing partitions. Create a primary partition of approximately 100Mb for the boot files. Format the boot partition as FAT32. Mark the boot partition as ACTIVE. Create a second partition with all remaining space on the eMMC device. Format the partition FAT32. The script will return and the batch will take over Batch file will copy MLO, EBOOTSD.NB0 and NK.BIN from the storage card to the boot partition. Remove the uSD card and cycle power. The BeagleBone should now boot directly from the eMMC device. A few things to note: The same image file set (MLO, EBOOTSD.NB0 and NK.BIN) works on the BeagleBone White and Black as executed from a uSD card or the BeagleBone Black executed from ether a 2Gb or 4Gb eMMC. Unlike other BSPs there is no need build separate images or keep track of several file sets based on which device you are booting from! David Vescovi
A few things to note: The same image file set (MLO, EBOOTSD.NB0 and NK.BIN) works on the BeagleBone White and Black as executed from a uSD card or the BeagleBone Black executed from ether a 2Gb or 4Gb eMMC. Unlike other BSPs there is no need build separate images or keep track of several file sets based on which device you are booting from!
Re: Windows Embedded Compact 2013 on Beaglebone gets IoT sample
Please contact me regarding a full installation of this BSP for WINCE2013, and what is necessary for...
-- Aaron Peterson
Re: BeagleBone BSP code clean up
Hi David, Interest in the fully version of the image. Please let me know the commercials. I need clarification...
Re: BeagleBone BSP gets several improvements
Hi David, How can I get a full version (without reboot) of your image available for demonstration?
-- Marco Aurélio Braun
Re: Low power operation on the community IoT Beaglebone BSP (Part 1)
Hello , dvescovi . Because of Job , I use your Beaglebone black BSP which is helpful for me . I want...
Re: Yet Another Gotcha: Compact 7 Update
Hi David, Would you please contact me regarding the wince7 BSP for the BBB? I have a few LCD Capes...
Seems MS may have posed a new updated ISO on MSDN. For those without a subscription, you are still out...
Re: Power management on the Beaglebone part 2–Battery
Hi David, First of all thanks for this, blog it's been very useful. Before I go ahead and solder anything...
Re: More improvements for Beaglebone BSP
Thank you for the fixes. The latest version builds under WEC7! Yay! Next .. have to try deploying it...
Of course, I meant the WEC2013 SDK ... see what happens when you work with too many bits at the same...
Hi David. First, thank you for what must have been a huge amount of work. I have been trying to install...