I cannot interrupt (stop) U-Boot on P2020

[mohammadbaghera]

Hi there,

I work with P2020RDB-PCA platform which has a P2020E processor. The main problem is that I cannot stop the U-Boot (the primary boot). I am sure that the communication line is established correctly, because I have the same board and works well with the same communication line (UART0 to USB). I use the putty (Baud rate : 115200, Data bit : 8, Parity : None, Stop bits : 1, Flow control : None) and the putty and the pc has the same configuration for both P2020 platforms. I do not what is the problem? and where does it come from? I should say that the board which cannot load the U-Boot, can still load the image from TFTP communication line and I think all the functions works except serial port in one direction. I tried the UART1 port but the serial communication cannot be stablished (I read that jumper on the board set for UART0 for loading U-Boot). Is there anything inside the BIOS that probably is changed? Is there any way to upgrade or flash the BIOS to turn all the setting as default?

Thanks for any suggestions.

[hwrobel]

If you say you cannot stop U-Boot, do you mean you can’t successfully type a key so that U-Boot will end up in the command line rather than booting?

If so, a very likely explanation is that someone modified the U-Boot environment to set the “bootdelay” variable to 0. This might have been well meant, but is usually painful as it effectively prohibits the key check, and it a bit annoying to recover from.

You would need to either “trash” the U-Boot environment by overwriting at least one byte in the flash for it, or just reflash it with a default environment.

I had this case once on a board and used CodeWarrior to first trash the environment in the flash. Then I could boot into the U-Boot command line again and fix up things manually.

Depending on your needs, you may want to try a more complex recovery procedure by first manually changing the bootdelay variable in the env flash and then recalculating the CRC for the environment.

This is a bit nontrivial, so it might be easier just reflash a prebuilt full flash image from the Freescale SDK.

Hope this helps,

Heinz

[lunminliang]

Please kindly find technical support comment below:

This looks like a damaged UART port on the board, but I cannot tell it for a hundred percent because I do not see the board. I see the following options:

1.You says the board boots over TFTP. If you can boot Linux, you

can check the both UARTs, as Linux normally listens on the both. If only

one responds, another is broken.

2. If you has CodeWarrior, you can try initializing the problematic

UART port "by hand", send some symbols to it from a PC and check if they

appear in the receive data register.

3. You can re-build u-Boot to listen on another UART and re-program it over

JTAG, using CodeWarrior. Details can be found here:

http://www.freescale.com/infocenter/topic/QORIQSDK/2942548.html

Note, there is a confusion about BIOS. P2020RDB has no BIOS. u-Boot and Linux operate directly over the hardware.

[marius_grigoras]

Hi,

You can also attach to the u-boot application using CodeWarrior and stop it anywhere you want.

Regards,

Marius