dm365 u-boot questions (rebuilding then reflashing from within u-boot)

I just wanted to add one more quick question. When building u-boot I see the following warning for almost every file. Is this normal?

warning: target CPU does not support interworking

UPDATE: OK, I found a solution to this....just add the following line to cpu/arm926ejs/config.mk

PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,)

I still wonder if the source is the same that was used to build the binary image included with the PSP.

Hi Craig,

the procedure is incorrect:

1) Blocks 1-24 are reserved for UBL descriptor (and, depending on how your flash is organized, UBL code. But it can also be in another place on flash). So don't erase them if you don't know how to restore them.

2) The actual position of U-Boot on the flash is not 0, but depends on how your UBL works. TI's one looks for U-Boot descriptor on blocks 25-50: the actual U-Boot code position is written in that descriptor. Other first stage bootloaders can work in another way. Even knowing you are using UBL, the actual U-Boot code position depends on bad blocks on your flash.

So, basically, boot is a 2 stage process (UBL + U-Boot). Details of boot depend on your UBL, flash organization and bad blocks.

Rewriting U-Boot should involve rewriting its descriptor, since several details can require it (i.e. the image size has increased or moved, bad blocks are encountered, etc). You can try to preserve previous descriptor and simply overwrite the U-boot image, but you must know where previous image is actually placed on the flash. Also if the number of flash pages used is increased, this will not work.

So, to put it simple, U-Boot can't easily update itself. If you know how to do it, you can still try, but you must be very careful of details.

Erasing 0x30000 bytes from address 0 of flash will most probably cause your board not to boot anymore, so don't do this unless you have a JTAG cable ready.

Thanks Marco, this is what I suspected.

Question for TI folks: What about a UART based UBL/u-boot flash programmer for dm365 (similar to other Davinci chips)? Was this ever developed? If not, will it be (and when)?

Thanks again.

-Craig

CraigSmith said:

Question for TI folks: What about a UART based UBL/u-boot flash programmer for dm365 (similar to other Davinci chips)? Was this ever developed? If not, will it be (and when)?

Unfortunately this may not be available soon as it will likely require a silicon rev to fix, as there is an errata with the ROM boot loader on DM365 that prevents the UART boot mode from operating at a standard baud rate, so when you go to talk to the board over the serial port to boot instead of seeing "BOOTME BOOTME ..." you see "P?tig) P?tig) ..." or "'PÔtig) 'PÔtig) ...". Since most terminals do not necessarily operate outside of standard baud rates there has been no serial booting utility for the DM365, if/when this errata is fixed in a future silicon revision the serial boot utilities should work for it.

OK, thanks Bernie. We are going to go ahead an order an XDS510 from Spectrum Digital. Can you confirm that the XDS510 USB PLUS ($1495) is the correct model to purchase for the dm365? (you may remember we did not have any success with the device we bought from Wintech, so I don't want to make the mistake again)? There is another model (without the "PLUS") for $989, but I'm not sure about the difference.

Thanks.

I suspect both would work, I have never used a USB PLUS myself, I think the difference has to do with supporting some other ARM debug modes but I have not really looked into it much, all the SD XDS510 USB emulators I have around here are the standard old model, including the one I used on your board a while back. To be specific, this is the model I use when I need to emulate on the go, so unless you find a good reason to get the PLUS, I would save the $500.

Yes, this model works just fine.

So, now I still have the same question as above. The tried the u-boot binary compiled from the source included with the PSP and it does not boot. As I mentioned above the size is considerably smaller than the binary file provided (which does work).

Is this the correct procedure to re-build u-boot from the source?

make davinci_dm365_evm_config

make all

If so, then why is the resulting binary so much smaller (and why does it not work)?

Regards,

-Craig

I have a related question and possibly an answer.

I am building the same uboot as specified above.  I am usein the BlackHawk 560 to load u-boot rather than u-boot-1.3.4-dm365_evm.bin.  When I run it the ethernet initialiation fails.  The version I still have in flash works though.  Any ideas why the flash version works with ethernet while the built version does not?  See the console logs below

==================  Flash Version =========================

U-Boot 1.3.4 (Mar  2 2009 - 11:50:39)

I2C:   ready

DRAM:  128 MB

NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

Bad block table not found for chip 0

Bad block table not found for chip 0

Bad block table written to 0x3ffe0000, version 0x01

Bad block table written to 0x3ffc0000, version 0x01

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

Bad block table not found for chip 0

Bad block table not found for chip 0

Bad block table written to 0x3ffe0000, version 0x01

Bad block table written to 0x3ffc0000, version 0x01

2048 MiB

In:    serial

Out:   serial

Err:   serial

Ethernet PHY: GENERIC @ 0x00

Hit any key to stop autoboot:  0

U-Boot 1.3.4 (Sep 16 2009 - 09:11:52)

I2C:   ready

DRAM:  128 MB

NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

Bad block table found at page 524224, version 0x01

Bad block table found at page 524160, version 0x01

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

Bad block table found at page 524224, version 0x01

Bad block table found at page 524160, version 0x01

2048 MiB

In:    serial

Out:   serial

Err:   serial

ethernet init failed!

Hit any key to stop autoboot:  0

keith36119 said:

I am building the same uboot as specified above.  I am usein the BlackHawk 560 to load u-boot rather than u-boot-1.3.4-dm365_evm.bin.  When I run it the ethernet initialiation fails.  The version I still have in flash works though.  Any ideas why the flash version works with ethernet while the built version does not?  

Did you try bulding with the options Keith suggested above?

   PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,)

I am also looking into this internally

Just to be clear.....I tried building with that "no-thumb-interwork" option, I'm not sure if Keith did.

The build I tried did not print anything to the console. I have not tried debugging this yet, I just expected it to work (even though I suspected it wouldn't because of the file size difference).

I hadn't tried PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) before but I just tried them with no difference.  I figured out how to make it work though.

1. Atl-c to disconnect the jtag

2. power cycle the evm

3. alt-c to connect the evm before the resident u-boot initializes the ethenet.  If I am not  fast enough I have the same problem.  Not only that, but if I have my boot options such that it tries to use the ethernet such as TFTP then the ethernet initializatioin will cause a processor reset.

4. My problem seemed to be that u-boot requires the ethernet hardware to be in the default power on state during initialition.

It would be nice if the GEL file and/or the hardware initialiation could handle it.  But I have a work around for now.

FYI my build steps each time were 

make distclean

This generate the error "gcc: Command not found"

make distclean

the second time I get no errors

make davinci_dm365_evm_config 

Craig Smith said:

What about a UART based UBL/u-boot flash programmer for dm365 (similar to other Davinci chips)? Was this ever developed? If not, will it be (and when)?

Here is SD card flash programmer for dm365.

I erased my flash so that I wouldn't have to hit alt-c so fast to catch u-boot before teh ethernet init.  Now my unit is dead.  

I get nothing from the console any more and the new U-boot seems to be running based on the break points and my ability to single step.  But nothing comes out the console any more.

keith36119 said:

I erased my flash so that I wouldn't have to hit alt-c so fast to catch u-boot before teh ethernet init.  Now my unit is dead.  

I get nothing from the console any more and the new U-boot seems to be running based on the break points and my ability to single step.  But nothing comes out the console any more.

1. Try to switch to another boot mode and catch RBL with debugger

2. Try this http://e2e.ti.com/forums/t/10032.aspx

I just restored my board with UBL and my new u-boot that I built.   have a black hawk 560 jtag and I followed the instructions in dvsdk_2_10_01_18/PSP_02_10_00_14/docs/DM365-installation.doc.  It took a while for me to get all the updates straight.  But after that it worked like a charm.

I think that u-boot depends on UBL initializing certain hardware before it runs.  I am assuming this because once I flashed in the new u-boot along with the factory supplied UBL_DM36x_NAND.bin my u-boot ran fine.

Keith, can you tell me to size of the resulting u-boot.bin file you built from the source at dvsdk_2_10_00_17/PSP_02_10_00_14/board_utilities/u-boot.tar.gz?

This is what I built (that doesn't seem to work):

-rwxr-xr-x   1 csmith git  150504 Sep 10 11:00 u-boot-1.3.4-dm365_evm.bin

I have added a little code mainly printfs of my own so mine is slightly bigger.  So for a test I reverted my changes and built it.  I got the same size as you.

-rwxr-xr-x   1 keith keith  150504 2009-09-18 07:40 u-boot-1.3.4-dm365_evm.bin

I will try it after a full erase and see if it works.  Thanks for confirming the size, so as least now I believe it should work.

Success! (problem was probably not running the erase tool first).  I tried a subsequent update with u-boot only (entering 'none' for UBL) and it also worked.  Thanks again.