PBL stops loading before End Command

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PBL stops loading before End Command

Jump to solution
2,645 Views
ralftruebenbach
Contributor III

Hello,

we have a new T2081 based cpu board and try to load RCW and U-Boot from nor flash. I can see that the PBL reads the preamble and RCW data (36*16Bit). But the PBL stops after reading the RCW and does not read the End Command. The data format should be ok since I used CodeWarrior Dev Studio to create the data and I checked the created data.

Labels (1)
Tags (4)
0 Kudos
1 Solution
1,081 Views
ralftruebenbach
Contributor III

We had pull-downs connected to IFC_AVD and IFC_WP0_B. There is a note in T2081 data sheet that this pins must not be pulled down during power-on reset. After we changed these pull-downs to pull-ups the PBL works as expected.

View solution in original post

0 Kudos
4 Replies
1,081 Views
ed_swarthout
NXP Employee
NXP Employee

Does the PBL use a flush command?  The SDK and u-boot/pblimage used to use it until this restriction was put in place:

"Use of the Flush command is restricted to CCSR space. Software must use the Wait command after commands to non-CCSR space to allow them time to complete before issuing subsequent commands to non-CCSR space."

Ed Swarthout

0 Kudos
1,081 Views
ralftruebenbach
Contributor III

No Flush command. We don't have any PBI data at all (PBI_SRC=disabled), just the RCW.

From measuring reset signals and cs0 (see above) I know that the cpu reads preamble and rcw. But the cpu never deasserts the HRESET signal and the end command is never read.

I already compared the signals with an T2080 eval board. From that and FTF-NET-F0152.pdf I know that pll should lock (according to the ratios specified in rcw) before HRESET is deasserted and end command is read. But I cannot find any errors in our rcw settings or input clocks.

Are there any other reasons beside the plls/input clocks which could cause this?

Our system controll FPGA needs some time before it can drive/assert PORESET (see pics above). Could this be a problem (it looks like CPU asserts HRESET before we assert PORESET)?

Ralf

0 Kudos
1,082 Views
ralftruebenbach
Contributor III

We had pull-downs connected to IFC_AVD and IFC_WP0_B. There is a note in T2081 data sheet that this pins must not be pulled down during power-on reset. After we changed these pull-downs to pull-ups the PBL works as expected.

0 Kudos
1,081 Views
ralftruebenbach
Contributor III

I found an interesting document about the QorIQ pre-boot loader:

http://cache.freescale.com/files/training/doc/ftf/2014/FTF-NET-F0152.pdf -> PBL in the Power Up Sequence

So I think sequence is something like this:

- reading the rcw data

- pll should lock according to the ratios specified in rcw

- hreset release

- PBL finishes the PBI

I checked my rcw settings but unfortunately still no success. I did some measurement and found that hreset is never released.

Are there any reasons beside the pll locks which could cause this?

hreset is asserted before poreset. Is this normal (our reset logic sets hreset to tri-state)?

Reset Signals (PORESET=dark blue, HRESET=light blue, HRESET_REQ=pink, CS0=green):

overview.png

Details:

detail_powerup.png

CS0 RCW:

detail_cs_rcw.png

My RCW Settings:

rcw_settings.png