U-Boot on P2020RDB-PCA via SD Card

cancel
Showing results for 
Search instead for 
Did you mean: 

U-Boot on P2020RDB-PCA via SD Card

Jump to solution
1,334 Views
Contributor I

After an erroneous NOR flash write on my P2020RDB-PCA, I am unable to even bring up the u-boot environment. Right now I am in the process of attempting to have the P2020RDB-PCA start u-boot from an SD card. I have perused through several discussion threads and other pages, I've surmised that I need to use the boot_format tool that is installed with the cross-compilation toolchain produced by the QorIQ Linux SDK. After creating a single FAT32 partition on the SD card (per the documentation in the Freescale Technical Information Center), I execute the boot_format as follows:

sudo /opt/fsl-networking/QorIQ-SDK-V1.6/sysroots/x86_64-fslsdk-linux/usr/bin/boot_format \

/opt/fsl-networking/QorIQ-SDK-V1.6/sysroots/x86_64-fslsdk-linux/usr/share/boot_format/config_ddr3_1gb_64bit_p2020rdb_pc.dat \

'/home/rnieves/QorIQ-SDK-V1.6-20140619-yocto/build_p2020rdb_release/tmp/deploy/images/p2020rdb/u-boot-sd-P2020RDB-PC_SDCARD-2014.01+fslgit-r0.bin' \

-sd /dev/sdc1

The boot_format tool seems to report a successful write to the SD card, after which I unmount from my Linux machine. I then ensure that the P2020RDB-PCA attempts to pull u-boot from the SD card (via the dip switches in SW3: 011010XX), plug the SD card into my P2020RDB-PCA, and power up. Based on all the documents I've read this should be enough, but the only response I receive from the P2020RDB is a fast-blinking eTSEC2 green and amber light. The serial console I have connected to the P2020RDB via UART0 does not produce any output that I could use to help diagnose the problem.

My question to the community is: Is the board completely bricked? Or is there something I'm doing wrong in the SD card formatting.

Pertinent configuration details:

Workstation: Ubuntu 14.04 LTS; x86-64

QorIQ SDK: 1.6

SD Card: Kingston 8GB SDHC

Many thanks for your assistance.

Labels (1)
0 Kudos
1 Solution
47 Views
NXP TechSupport
NXP TechSupport

Hello Rolando,

I just confirmed with Linux SDK testing team, please use the boot_format configuration file "config_sram_p1022ds.dat".

Because in the latest SDK 1.6, the u-boot images become larger(more than 512K), you could refer to the following definition in

meta-fsl-ppc/conf/machine/p2020rdb.conf

BOOTFORMAT_CONFIG = "config_sram_p1022ds.dat"


If this still doesn't work, please feel free to let me know.


Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
6 Replies
47 Views
Contributor I

Yiping,

Many thanks for your reply! Indeed after I used the device name vs. the partition name, the P2020RDB reacted differently. Now as it turns on, the eTSEC2 green and amber lights turn on for about one second then turn off. Unfortunately, there still is no activity evident on the UART0 or UART1 serial port on boot up. Is it possible that the write of bad data on the NOR flash still be interfering? The erroneous write did clobber the u-boot environment area as well as the u-boot code area (0xefec0000 through 0xefffffff were clobbered, which according to table 5 in the Freescale Technical Information Center "QorIQ SDK 1.6 Documentation => Configuration => Hardware Configurations => P1020/P1021/P2020RDB" page is the NOR Flash area for u-boot).

The sequence of commands that got me in this predicament, which I admit was my fault for not fully understanding the documentation, were:

=>tftp 1000000 u-boot-<platform>.bin

=>protect off all

=>erase <u-boot_start_addr> <u-boot_end_addr>

=>cp.b 1000000 <u-boot_start_addr> $filesize

as documented in the Freescale Technical Information Center "QorIQ SDK 1.6 Documentation => Development Deployment => Non-DPAA" page under the "Flashing U-Boot" heading. I had the correct u-boot image, but in the "u-boot_start_addr" and "u-boot_end_addr" I put in efec0000 and efffffff respectively (based on the table 5 I mentioned in the previous paragraph). I now believe should have put in eff40000 and efffffff instead.

Again, many thanks for your reply!

0 Kudos
48 Views
NXP TechSupport
NXP TechSupport

Hello Rolando,

I just confirmed with Linux SDK testing team, please use the boot_format configuration file "config_sram_p1022ds.dat".

Because in the latest SDK 1.6, the u-boot images become larger(more than 512K), you could refer to the following definition in

meta-fsl-ppc/conf/machine/p2020rdb.conf

BOOTFORMAT_CONFIG = "config_sram_p1022ds.dat"


If this still doesn't work, please feel free to let me know.


Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
47 Views
Contributor I

Yiping,

That was excellent detective work! Indeed after I used the "config_sram_p1022ds.dat" the P2020RDB came up to the uBoot prompt! Many thanks for your help!

Rolando.

0 Kudos
47 Views
Contributor I

Hi Rolando,

I've got same problem when I try to use 'config_ddr3_1gb_64bit_p2020rdb_pc.dat' but try with 'config_sram_p1022ds.dat', the result was same. no output from UART.

Anyway, what kind of u-boot binary (or source) you used with 'config_sram_p1022ds.dat'? and may I have the specific configuration of u-boot build?

0 Kudos
47 Views
NXP TechSupport
NXP TechSupport

Hello Rolando,

I think the most probable cause is that you didn't use boot_format tool correctly.

For boot_format command, please specify a device name to it rather than a partition name, for example "<path>/boot_format  config_ddr3_1gb_64bit_p2020rdb_pc.dat  u-boot-sd.bin -sd /dev/sdd"(/dev/sdd is the device name), because boot_format tool needs to rewrite SD partition table, it seems that the document in SDK is not very clear.

If the above doesn't help, please feel free to let me know.


Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
47 Views
Contributor I

Yiping,

Many thanks for your reply! Indeed after I used the device name vs. the partition name, the P2020RDB reacted differently. Now as it turns on, the eTSEC2 green and amber lights turn on for about one second then turn off. Unfortunately, there still is no activity evident on the UART0 or UART1 serial port on boot up. Is it possible that the write of bad data on the NOR flash still be interfering? The erroneous write did clobber the u-boot environment area as well as the u-boot code area (0xefec0000 through 0xefffffff were clobbered, which according to table 5 in the Freescale Technical Information Center "QorIQ SDK 1.6 Documentation => Configuration => Hardware Configurations => P1020/P1021/P2020RDB" page is the NOR Flash area for u-boot).

The sequence of commands that got me in this predicament, which I admit was my fault for not fully understanding the documentation, were:

=>tftp 1000000 u-boot-<platform>.bin

=>protect off all

=>erase <u-boot_start_addr> <u-boot_end_addr>

=>cp.b 1000000 <u-boot_start_addr> $filesize

as documented in the Freescale Technical Information Center "QorIQ SDK 1.6 Documentation => Development Deployment => Non-DPAA" page under the "Flashing U-Boot" heading. I had the correct u-boot image, but in the "u-boot_start_addr" and "u-boot_end_addr" I put in efec0000 and efffffff respectively (based on the table 5 I mentioned in the previous paragraph). I now believe should have put in eff40000 and efffffff instead.

Again, many thanks for your reply!

0 Kudos