PROCESSOR-SDK-AM335X: Linux download on Beaglebone Black

Thanks Biser for the fast response and thelink. will definitely give it a try.  I appreciate it .

cheers

Mark

Hi Biser -

Thanks for the link , I looked at it and like all of the procedures I have seen for this work I have been trying, it seems rather lengthy and complex.  I have outlined some thoughts below and wonder if you could comment or advise and hopefully correct my eroneous thinking.

We have created a design that originated on a piece of hardware that had a beaglebone black attached as a plug in board to the hardware platform.  We are in the process of porting the design to a new piece of hardware that has the beaglebone hardware incorporated into the hardware platform.  In this port we got rid of the SD card interface on the board which forces me to load a new unprogrammed board from one of the other sources , uart0, usb0 or ethernet.  I is in this area that I am finding challenges.

Since the hardware is not in my hands yet I am using a bbb to try and get this loading system working in preparation for the arrival (very soon) of the hardware.  I alos hav an evm that I could use.  I am starting with the prebuilt tools from the linux processor sdk.

I have been able to connect to a beaglebone black and load the spl and uboot bootloader onto the board , It has a load of the bbb linux system on it but I bypassed that by holding down S2 to get it to go to uart 0.  I am currently running this from teraterm on windows but have a linux box available as well. 

So here is my perception of the simplest path and how this works.

All I really need to do is to somehow get a working image of the actual target system into the emmc on the board.  This working image would be pretty much exactly what is supplied on the sd card by many sources and flavors such as the ti sdk or the bbb image.  this image needs to have all of the spl, uboot zimage( kernel) file system and device tree in the correct places in memory so that once loaded into emmc an booted the processor will execute the boot process (call spl, uboot and kernel) correctly to fire up the processor. It would seem that this is what the sd card image does when it is installed onto the emmc from the sd card when instructed to do so in uenv.txt.

I have not been able to find any examples of doing anything like this.  Every thing I look at sys I need to build the kernel or uboot or both.  Has this not already been done in some image by someone already, in fact is that not the prebuilt pieces supplied in the sdk for the evm specifically and indirectly in the bbb image that is put on the sd card?  What am I not understanding?

Another possiblility , is there a version of uboot that could be configured to initialize the processor through the serial port that would read the image off of an sd card connected to the usb port through an adapter?  This would be a really simple solution.

It look like doing anything in this space requires me to work and understand the depths of U-boot and the kernel and file system  and I am not seeing why?  As long as the image I am loading has the correct device tree and every thing maps correctly, which it should since the hardware is standard on these boards why would I need to work with uboot or rebuild anything?

So assuming I do want to do this the hard way, I can get through the u-boot process enough to get to the kernel and filesystem and dev tree stage.  How do I proceed from here?  How do I tell u-boot to load the kernel file (zimage) and to where ? How do I get the file system onto the board or even into ram (no doubt uboot…).  So even if I am booting from an external host without loading to emmc how do I do that ? Is there a script or something available to help here ?

 Thanks biser

Mark

Mark,

I'm looking into some options to try to make this as simple as possible. One thing that makes this complicated is the need to partition the eMMC on a fresh board. On your BBB, it is already partitioned at production (using the SD Card). I'm assuming on your new boards that this will not be the case? U-Boot cannot do this partitioning and this is the primary reason why we recommend booting to at least a partial Linux system in order to partition the eMMC and then copy the files over. If you have some other means to partition the eMMC, or is it done for you, then yes, this can probably be simplified.

Thanks,

Ron

Hi 

Ron - thanks for the reply.

The hardware will have a clean sitara processor am335x on it with an empty emmc.  no partition.  perhaps you can clear something up for me.  The image that sits in the emmc after sd card load of whatever linux os is a complete partitioned representation of the operating system with everything in the correct place as laid down by the load from the sd card kernel uboot (for board bootup) device tree and file system.  If I can copy this image bit for bit off of an existing BBB into a file on my pc , then replace the bbb with my target board, connected through the serial port or usb, then I shold just need a program that boots and loads into ram a program that can copy from the serial port bit by bit the image back into the new emmc.  If this could happen then when I boot the new board, it should execute exactly the process that the BBB did when it booted since it goes to the same locations in the new as in the old.

So a question is , is this correct , and if so what tools exist to make this happen from ti. It seems to me that the uniflash program might be able to do this to do the writing  and I found a procedure to extract the emmc contents (I will have to find it again ) into a file but i am not certain it is a direct image of the emmc.  having some way to read out the emmc contents bit for bit would be really great.  perhaps you know a way to get uboot to do this or perhaps you can say whether the sd card image is indeed a complete image that is just copied to the emmc directly.

alternativly I could go the uboot route but so far i have not been able to put together all of the files  that are needed.  I can get to uboot prompt through the serial port but dont know where to find the files I need to complete the operation.  perhaps you can point me to the sdk prebuilts that allow for this.

Please advise, I am sure I am making this overly complicated.

Thanks

Mark

Mark,

OK, so the eMMC is not partitioned. So, you'll need to use an image file (which contains partition information) or partition the eMMC.

If you are completely confident that you don't need to make any changes to the sources, we provide an image file on our download page that might be a good place to start.

http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/latest/exports/am335x-evm-linux-06.00.00.07.img.zip

We also provide instructions for how to use it:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/06_00_00_07/linux/Overview_Getting_Started_Guide.html#windows-sd-card-creation-guide

The process that we use to populate the appropriate files on the SD Card (basically the same as eMMC) are best documented in our create-sdcard.sh located in the /bin directory of the SDK.

You'll see that it basically does the following:

1. Does some basic checking for size and such
2. Creates partitions
3. Copies files to the partitions using those provided in the /board-support/prebuilt-images and the /filesystem directories. It should document all of the files needed which basically boils down to two files for U-Boot (MLO (or SPL) and u-boot.img), DTB file for board, zImage for kernel, and a filesystem. All of this can be tested/verified by running the script and creating a SD Card.

To address one of your earlier questions about USB storage, I validated that the BBB with the PLSDK can indeed read both FAT and EXT partitions on a SD Card mounted via a USB card reader. 

The BBB cannot boot from USB Mass Storage, so you'll need to use your UART method (or USB or Ethernet) to get to a U-Boot prompt. From there, you can use the USB commands (usb help) to get the device mounted and use FAT or EXT commands to copy the image (previously placed on the SD Card mounted on USB) to the eMMC. Then, see if it boots properly from eMMC.

If this meets your needs, it would be the best approach in my opinion. Transferring a multi-GB image over UART would be too slow in my opinion.

All of this assumes you will need no changes for your hardware. One that often gets people is the i2C based EEPROM ID that U-Boot uses to ID the board. Did you place this and is it being programmed with the right information to ID it as a BBB? If not, this will require a U-Boot code change. 

Take a look at this and see what you think. The BBB test should be pretty straightforward and a good start. 

I hope this is helpful to you...

Hi Ron - thanks so much for the responses and help.  probably the most encouraging approach so far.  I will definitely try it.  was not aware of the eeprom issue.  unlikely the new hardware will have this in place.  I believ and eeprom is on the board but unprogrammed.

I am not married to the bbb viewpoint.  we just happen to be developing with bbb's till now.  if there was a ti sdk build that can work that would be fine.  I just need to get some form of linux on the processor. I am making the rather rash assumption that once I have a working os, it could be updated or changed via ethernet or usb or something.  please advise if this is not true.

I was hoping you could comment on the idea of copying bit for bit the emmc contents out of a working board and copy them bit by bit into a new board.  I dont see why this would not work since whatever is in eemc at bootup (say power on) is what gets loaded in a normal startup of the processor.  there us no other "program" source (normally) on the board.  at some level the processor executes the reset (startup) vector and finds instructions from somewhere in emmc or rom and executes the boot up process.  the image that is in emmc is this sequence of instructions, organized in some unknown (to me) way but as long as I make a direct copy of all of theese instructions( the emmc contents image) I dont see why it wont behave exactly the same.  this seems like a fairly simple peice of code running in ram (loaded possibly by uboot even) to do this copy and send the emmc contents out the serial port directly via kermit or something.  when loading the process is simply reversed.

Is that not orders of magnitudes simpler than rebuilding uboot and the kernel to do all of this?  what am I missing here?  

a related question - are the partitions not part of the image as well? dont they have to be.  it is like cloning a hard drive in a sense. as long as it goes back into the same hardware it works fine.

Perhaps ccs could even accomplish through jtag?  

Not to seem ungrateful - I really appreciate your help on this.

I will give what you suggest A try.  please let me know what you think about my ramblings...

thanks

Mark

Hey Mark,

You are very welcome for the help. I know it can be a lot to digest.

Mark Mitchell said:

I believ and eeprom is on the board but unprogrammed.

If this is the case, then you will either need to find a way to program the EEPROM or rebuild U-Boot. Otherwise, it will not boot on your new boards.

Mark Mitchell said:

I am making the rather rash assumption that once I have a working os, it could be updated or changed via ethernet or usb or something.  please advise if this is not true.

Depending on the update you are referring to, yes, you should be able to make changes to the filesystem or the boot partition assuming you have the right priveledges.

Mark Mitchell said:

Is that not orders of magnitudes simpler than rebuilding uboot and the kernel to do all of this?  what am I missing here?  

I don't really see the benefit of copying out the eMMC contents if you haven't made any changes. The img file that I pointed to should basically be everything that is written to the eMMC. So, why write it just to read it back out? However, if this is the path you'd like to take, this is certainly possible.

Mark Mitchell said:

a related question - are the partitions not part of the image as well? dont they have to be.  it is like cloning a hard drive in a sense. as long as it goes back into the same hardware it works fine.

If you use an image, yes, the partition information is part of the image. That's why U-Boot can do it.

Mark Mitchell said:

Perhaps ccs could even accomplish through jtag?  

Yes, I suppose this is possible. A bit outside of my expertise.

Please take a look at this post:

https://e2e.ti.com/support/processors/f/791/p/825011/3071951#3071951

I just went through this on a BBB using USB network. If you can follow this, it will get you to a Linux system that has everything you need to partition and copy files to the eMMC. This would give you a lot more flexibility. If you have Ethernet available, I would recommend that, but you will need to jumper some boot pins on the BBB to get it to boot over Ethernet.

This is just an alternative that provides more power.

I hope I've helped clarify things. Let me know if you have more questions...

Thanks.

Hi Ron -

I want to really thank you . you are helping me get further than I have before and I really appreciate it.  your comments are right on. I will try to do the image over usb you suggest.  just a point of clarificaytion, the idea of reading out the emmc contents would be to read out the contents off of an existing working system , a bbb loaded with bbb linux version say, then saving that image.  then writing to a fresh hardware set (say our new target hardware).  perhaps I was not clear on that .  Anyway your way might be easier.

I hope it is ok to leave this unresolved for now.  I dont want to close this channel quite yet as you are currently my lifeline.

Thanks

Mark

Hi ron -

Still confused.  below are some questions about this process  in a paste from earlier...  my questions in bold.

Thanks

Mark

Mark,

OK, so the eMMC is not partitioned. So, you'll need to use an image file (which contains partition information) or partition the eMMC.

If you are completely confident that you don't need to make any changes to the sources, we provide an image file on our download page that might be a good place to start.

http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/latest/exports/am335x-evm-linux-06.00.00.07.img.zip

I realized I dont know what an img file is.  is this an image of the entire operating system including partitions? what exactly is it?

We also provide instructions for how to use it:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/06_00_00_07/linux/Overview_Getting_Started_Guide.html#windows-sd-card-creation-guide

The process that we use to populate the appropriate files on the SD Card (basically the same as eMMC) are best documented in our create-sdcard.sh located in the /bin directory of the SDK.

You'll see that it basically does the following:

1. Does some basic checking for size and such
2. Creates partitions
3. Copies files to the partitions using those provided in the /board-support/prebuilt-images and the /filesystem directories. It should document all of the files needed which basically boils down to two files for U-Boot (MLO (or SPL) and u-boot.img), DTB file for board, zImage for kernel, and a filesystem. All of this can be tested/verified by running the script and creating a SD Card.

so my uderstanding is the the linux sdk is only on a linux box.  but the previous steps are done on a windows machine.  you have provided a .sh file, is that a windows thing ? looks like it but i dont have a sdk in windows??? 

I did the file copy onto sd card and can actually see the sd card through host usb port on BBB.  

To address one of your earlier questions about USB storage, I validated that the BBB with the PLSDK can indeed read both FAT and EXT partitions on a SD Card mounted via a USB card reader. 

The BBB cannot boot from USB Mass Storage, so you'll need to use your UART method (or USB or Ethernet) to get to a U-Boot prompt. From there, you can use the USB commands (usb help) to get the device mounted and use FAT or EXT commands to copy the image (previously placed on the SD Card mounted on USB) to the eMMC. Then, see if it boots properly from eMMC.

So this is where I am stuck now...  can I actually do a fatload of the image on the sd card into the ram?  or emmc ?  what is the address I point it to?  I dont know what "it" actually is so I cannot even guess where to put it.

do I need to load uimage and dt and file system into mem to get a version of linux running from ram to execute copying to emmc or will u-boot just magically handle it( I doubt it).

If this meets your needs, it would be the best approach in my opinion. Transferring a multi-GB image over UART would be too slow in my opinion.

All of this assumes you will need no changes for your hardware. One that often gets people is the i2C based EEPROM ID that U-Boot uses to ID the board. Did you place this and is it being programmed with the right information to ID it as a BBB? If not, this will require a U-Boot code change. 

Take a look at this and see what you think. The BBB test should be pretty straightforward and a good start. 

I hope this is helpful to you...

Hi Ron -

So I was able to get a working version of linux running on the board by loading each element through the serial port, (spl, uboot, uimage, dev tree and initramfs).  I found a video that told me where to put the files and supplied files to put in.  pretty straightforward process when you know where everything goes.

so the state after that was that i had a board with an emmc loaded with one os (our special version of bbb linux) and a seperate one running in ram .  I also had an sd card plugged into the host usb port via an sd card to usb adapter that was recognized by ram os.

I thn copied the entire emmc into a file on the ram using the linux dd  command.

I then rebooted the board so it would come up from the existing load in emmc and added a directory called test to see if it would be overwritten when I did the following emmc load from the saved image.

I then performed a dd copy of the image file on usb  to the emmc to see if i could write it back to emmc and if it would work.  if it worked It would overwrite the file system so the test directory would be gone and it would actially boot.

this worked, after rebooting i the system came up from emmc and I the test directory was not present.

So this proved to me I could indeed write the entire image to emmc from a saved copy.

Next was to try it on a unit that had a blank emmc 

I took another board loaded up to the uboot stage via serial port and then erased the emmc with the emmc erase command.  Now I had a blank emmc which was clear because it would not do any thing after reboot except spit out ccccc  which was expected.

I then loaded the os via serial and did the same copy of the image file, this did not work.  It still would not work.

So at this point i do not know how to fix.  I am guessing that the partition information has been blown away in the clearing of the emmc, and the image overwrite is not re creating it somehow.  This is a total guess at this point.

what do you think?  

Also do you have a memory map somewhere that indicates where everything is supposed to go and where the partitions go and how large they should be?

Also , I am not intentionally ignoring your solutions, I am just looking for the simplest solution to getting the code in and fooling around with building uboot and network connections seems complicated. This is coming form my ignorance about how to configure uboot and my getting burned in my previous attempts to build a uboot image.  If you could point me to a good resource that explains the uboot build process That might help.

I do think I am close with this process but am lacking some fundamental understandings.  One question I still have is what does  the .img file that is supplied by beagle bone and Ti sdk ?  are these bit for bit copies like what i think I generated with my method , or are they contain multiple images that need to be located in specific places (partitions).  any help here would be very helpful.

thanks for your patience in all of this.

cheers

mark

Mark,

A couple of clarifying questions?

How big is your DDR RAM? I'm surprised you had enough to copy an entire eMMC into RAM in order to build the image. Or, did you do it with multiple passes of the dd command. In other words, used a 20MB buffer in RAM and copied 20MB chunks from eMMC to RAM and then RAM to USB?

When you copied the image to eMMC and it "didn't work", how did it not work? It didn't boot and spit out CCCCCs? If you boot back up to the initramfs can you use tools to look at the eMMC and see what it looks like? Is it completely trashed or does some stuff look in place?

Mark Mitchell said:

Also do you have a memory map somewhere that indicates where everything is supposed to go and where the partitions go and how large they should be?

There are no specifics here. You need a FAT partition at the beginning that we call boot that is big enough to store the bootloader and any other files you want there (uEnv.txt, for example). You need a second partition for the Linux FS that is typically ext3/4 and takes up the rest of the available space unless you need that space for something else.

Mark Mitchell said:

If you could point me to a good resource that explains the uboot build process That might help.

Our instructions for building U-Boot are pretty simple and documented here:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/06_00_00_07/linux/Foundational_Components_U-Boot.html#building-mlo-and-u-boot

Mark Mitchell said:

One question I still have is what does  the .img file that is supplied by beagle bone and Ti sdk ?  are these bit for bit copies like what i think I generated with my method , or are they contain multiple images that need to be located in specific places (partitions). 

It is a bit for bit copy generated using the dd command much like you describe. We create a loop device, create the partitions and format them, and copy over the files. That device essentially is a file on the drive at that point.

I think you are close to getting this to work.