• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 2597 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Uniflash with AM335x sends packets but cannot boot from USB

utelia
Intellectual 290 points
Other Parts Discussed in Thread: UNIFLASH, FLASHTOOL

Hello,

I followed t he instructions in processors.wiki.ti.com/.../Sitara_Uniflash_Quick_Start_Guide and now have got Uniflash ver 3.1.0.00026 installed and set up, and AM335x (AM3358BZCZ100) (on a BBB board) connected over USB, which shows as "Linux USB Ethernet/RNDIS Gadget #n" (with n depending on which USB I am connected to). 

Looking at the Local Area Connection Status, I can see packets are being sent from the host PC (Windows 7) to the device. Each time I reset the BBB, the sent packets number resets to zero and starts counting again.

UniFlash also shows the device Mac address in Status View, with status FlashInProgress, but the progress percentage never gets any other values than 0%.

(And after some time, the status becomes FlashUnknownError).

The situation is partially similar to this one: e2e.ti.com/.../346938 - but I seem to have it one or two steps past that already. Also, I do not have silicon rev 1.0 samples but mine is rev 2.1.

I have tried to look into the USB with USBPcap and WireShark, but there is not much interpretation of what happens on the line. I just see the same I get from the LAN Connection window, that there is outbound traffic, 

Firewall is not running. According to BBB documentation, the SYSBOOT settings do support USB boot.

Later on, we need to create a system which boots over USB and runs a flashing algorithm. For the time being, I am however just starting with a simple piece of code which blinks a LED. This code does not get to run now, and I can also confirm with XDS560 emulator that no code has appeared in the 0x402f0400 address. (Which is not surprising when the FlashInProgress hasn't proceeded past 0%).

After resetting the BBB, I can see it running in circles in the ROM boot code. It would help to know where the USB boot code starts and stops. (And any other ROM boot code symbols). Would you have this information available? 

Would you be able to suggest to me what I could be missing? Can you give me advice on what traffic I should see on the USB link?

Is this a driver/Windows set-up issue or could I have an issue with the image I am trying to transfer? Accoding to the specs (among others, AM335x TRM), no header is needed for the USB boot image, so I used the executable .out file as such (with everything linked to internal memory starting at 0x402f0400). Is this correct?

Is my idea correct that with Uniflash set up according to the instructions, I should be able to run any code by just placing the image in the C:\AM335x_Flashtool\images directory?  If there is just one image in the image directory, shouldn't it just transfer that and then start running it? Would you have a sample u-boot binary + sources which I could try out?

Thanks!

  • 0
    Intellectual 290 points
    Hello again,

    It looks like I am answering to myself after all.
    I googled for ethernet traffic analysis tools, found Microsoft Network Monitor and, looking into this adapter, realised that I am talking to the AM335x USB port after all.

    It then turned out the error occurs in the following way:

    2010 12:32:54 26.1.2015 1401.7586676 opentftp.exe 192.168.100.3 MY_PC_NAME_ TFTP TFTP: Read Request - File: u-boot-spl-restore.bin, Transfer Mode: octet {UDP:50, IPv4:49}
    2011 12:32:54 26.1.2015 1401.7590286 MY_PC_NAME_ 192.168.100.3 TFTP TFTP: Error - ErrorCode: 1, ErrorMessage: File not found or No Access {UDP:208, IPv4:49}

    so quite obviously the file name u-boot-spl-restore.bin is hardcoded to ROM boot code. (Right? If not there, where else?)

    I now rename my executable with this name and, indeed, it starts running my code! I am booting from USB.

    Just for the record, as I could find this information anywhere but had to do it by trial and error: I generated the bin file (now renamed like described above), by the following post_build step:

    "${IA_SDK_HOME}/tools/post_build/post_build.bat" "${CCS_INSTALL_ROOT}" "${CG_TOOL_ROOT}" "C:\My_path" "${ProjName}" "${IA_SDK_HOME}/tools/isdk_image"

    i.e. no option for either bootloader (0) or application (1), and no binary storage type (As all of them appear to generate a header).
    Generated like this, the bin appears to have cut some bytes from the beginning of the compiler+linker-generated .out file.
  • 0 in reply to utelia
    Intellectual 290 points
    Hello,

    I have a couple of additional questions. These are related to transferring the flashable image over the USB as a TFTP transfer.
    Looking into u-boot, it offers a way of starting more of TFTP transfers over USB. However, I would need to build it in Linux, which feels like an unnecessary complication at this point.

    (1) Is there any other practical way of getting the flashable image into AM335x over USB than by starting another TFTP transfer? I take that I cannot concatenate everything into the initial file (which is transferred in the control of ROM code, and always goes to internal memory (right?)) as the internal memory is not large enough. Also, at this time I already have the server (Uniflash) running in the host PC which would make a similar transfer a logical option.

    (2) Do you have a plain language explanation somewhere and/or some other reference code for starting a TFTP transfer other than the u-boot code?

    Thanks.
  • 0 in reply to utelia
    TI__Expert 4150 points

    Utelia,

    The error messages from your previous post appears to suggest that your tftp server is not accessible to the device. You can try to test if the tftp server works by using some free utils out there on the web. It is mandatory for the flash operation.

    regarding the current post:

    1. I am not aware of any other flashing solutions out there. However, I think you can copy your image to a flash card and stick it into your board and boot off the card. This flash solution in the UniFlash is targeted to be a production tool, therefore this spl+uboot approach is selected as it will be viable across the whole family of devices and board variants, including custom boards.

    2. The file requests to be flashed are hardcoded(on UniFlash not on hardware) to be :

    "u-boot-spl-restore.bin",
    "u-boot-restore.img",
    "debrick.scr",
    "flash-image.out"

    Where "flash-image.out" is your compiled image and "debrick.scr" is how to write the image on device memory. These must be created by following the instructions from the Sitara team: processors.wiki.ti.com/.../Sitara_Linux_AM335x_Flash_Programming_Linux_Development

    You can of course, not follow these and build your own sequence and load whatever you want. The device request the filenames from the tftp server based on the filenames attached in the BOOT and DHCP request. The DHCP and TFTP servers used in UniFlash are modified opensource projects and their source and binaries are attached in the installation:"uniflashv3\third_party\sitara" For more information, you can refer to the device user guide, all the details are specified there regarding the device boot process,

    However, be noted that if you actually want to flash the device memory, uboot is needed as it understand how to handle the hardware abstraction for the particular board. If you have something does the similar, you can go ahead and use that. Bottom line is that when you boot off USB or Ethernet, it goes through the BOOTP/DHCP and TFTP mechanics. From that point onward you can technically do whatever you want.

    Victor

  • 0 in reply to Victor Yang
    Intellectual 290 points
    Victor,

    Thank you for your answer. I am just two days into this topic and still putting together bits and pieces and evaluating different options for flashing. I appreciate your answers and they are proving very valuable.

    To clarify my situation quickly:
    (1) I am currently doing the flashing with a CCS based tool i.e. I have code for flashing
    (2) After my discovery yesterday to rename my executable to "u-boot-spl-restore.bin", I can now run my own code from USB (with Uniflash). Thanks to you your comments I now also understand where this file name is configured (opendhcp.ini) and believe that I can change it if I want.

    Now, what I am still missing is:
    (3) means of transferring my flashable files over USB to the AM335x memory. This is what TI's example implementation for CCS Flashing tool does by Tools -> Load Memory, and what I believe u-boot does by calling TFTP.

    Would you be able to clarify this concept:
    >You can of course, not follow these and build your own sequence and load whatever you want. The device request the filenames from
    >the tftp server based on the filenames attached in the BOOT and DHCP request. The DHCP and TFTP servers used in UniFlash are
    >modified opensource projects and their source and binaries are attached in the installation:"uniflashv3\third_party\sitara" For more
    >information, you can refer to the device user guide, all the details are specified there regarding the device boot process,

    Especially - what does this mean: "The device request the filenames from the tftp server based on the filenames attached in the BOOT and DHCP request. "
    Does Uniflash support transferring more files into AM335x in any other way than having the u-boot running?
    Exactly what part of the system makes the request for these additional files
    - is it the u-boot (or: u-boot-spl-restore.bin, standard version), or something else? How exactly do I would I go about to start loading some other file "abcdefg.zxc" to AM335x from Uniflash?

    (I have been reading the User's Guides and do understand the concept with these files.)
    >"u-boot-restore.img",
    >"debrick.scr",
    >"flash-image.out"
    Is loading of these now also hardcoded in Uniflash (where?) or is it something different?
    If this is the u-boot version of u-boot-spl-restore.bin, will it do it automatically? (If it does, it might just be an option for me to get a frozen image for this part of u-boot, as it would not require maintaining a Linux environment for this purpose).

    Thanks again!
  • 0 in reply to utelia
    Intellectual 290 points
    PS. I cannot see any other of the four files than "u-boot-spl-restore.bin" transfer automatically, so I assume there must be some interaction between the image now running at AM335x, and Uniflash. And this would be the key for me to solve this remaining issue for being able to get my flashable images to the AM335x.
  • 0 in reply to utelia
    TI__Expert 4150 points

    Utelia,

    UniFlash does not support any other ways of transfering files to the Sitara board other than SPL/UBOOT approach as I mentioned ealier because we want to provide a mass production flashing tool. The one approach that would decouple hardware from software and work across the board from now and foreseeable future is through UBOOT as we can delegate hardware handling to it. And the 4 file names I quoted in the earlier email are hardcoded in UniFlash while the file names you found in opendhcp.ini are the files used in BOOTP request to the device.

    When the device boot from Ethernet/USB, it is basically a network device.

    1. In the beginning theres only ROM code, the first thing it does is send out BOOTP request to get an IP address.
    2. Our DHCP server sees that request, serve an IP and along side pick that bootfile you saw in [VENDOR_ID_TO_BOOTFILE_MAP] field in opendhcp.ini as the first stage boot file in the reply. As in which file to pick depending on how the device identify itself in the BOOTP request.
    3. Now the device has an IP, it will request for that file specified in the reply from the DHCP server through TFTP, 
    4. after obtaining the first stage file, the SPL in this case, it is gonna run that file, which setup the device and restart itself again, and this time, it takes over from the ROM code and restart from 1. but has a different identity, say "AM335x U-B", which according to our list in opendhcp.ini, we will now serve UBOOT instead of SPL. Repeating process from 1-4
    5. When UBOOT is onboard, we can do some real stuff, this is when the debrick.scr and other things comes into play. This is where we load the 4 hardcoded filenames earlier.

    You can hijack the process from 1-4 to load your own code into the device memory, but not on flash.

    If you need the code on flash, you need to compile the debrick.scr and the big image file that concatenate all your binaries according to the Sitara team's specification.

    I strong suggest you to read the user guide section regarding device boot and the image creation link I provided in the earlier email.

    As you can see, the flashing is independent of UniFlash, just network protocol. UniFlash just sit ontop and provide a GUI for monitoring. You can use the 2 servers to build your own implementation.

    Victor

  • 0 in reply to Victor Yang
    Intellectual 290 points

    Victor,

    Thanks again.

    I have been reading the specs and had been able to figure out most of the above, but missed the middle step of UBOOT (or u-boot-restore.img as it is named). From your answer, I finally understood how it jumps from the SPL phase to the procedure for downloading the the four later stage files. I hadn't come to realise that it has got one more phase between the SPL and actual flashing.

    My belief is still that I could run the process from setting up the AM335x, downloading the flashable image(s) + debrick.scr (or similar), parsing the debrick.scr (or similar) and do the flashing, in the SPL code. (I assume the middle step in the case of UBOOT is there because UBOOT has got e.g. the server functionality and you can connect to it with the terminal etc.). 

    >If you need the code on flash, you need to compile the debrick.scr and the big image file that concatenate all your binaries according to the Sitara

    >team's specification.

    Yes, I am aware of this. I will most likely be able to simplify this procedure because I do not need all the configurability that the UBOOT approach offers. (Nothing wrong with UBOOT, I just don't want the Linux.) 

    I have two further questions where I would appreciate any help available:

    Would you be able to give me some insight into what parts of the u-boot code will compile to u-boot.img (aka u-boot-restore.img) and which code to spl/u-boot.bin (u-boot-spl-restore.bin)? Clarifying that is my next target before produce a simplified version to be used in our project. 

    Would you by chance have compiled images (with symbolic information) for the two u-boot images (AM335x, BBB), which I could run (with an emulator) and see for myself which code (especially) the SPL runs to get going with the UBOOT image loading? (As this is the only part I am currently missing from my project).

    Thanks!

  • 0 in reply to utelia
    TI__Expert 4150 points

    Utelia,

    You are right that maybe uboot might be over kill for this, but I guess it is just less effort as size isn't an issue since all can be fit into RAM space and its probably just easier to reuse what was available.

    I can't help you with your newest inquiries however, as I am not a device expert, nor UBOOT and SPL for that matter. My effort in this was to create this flash tool that mask the convoluted flashing process to users, primarily for production. 

    For these question, you should refer to the experts in the Sitara forum.

    Regards,

    Victor