B4860 errata A-007212 PBI option.

[jonathanbaird]

Hi,

For an unsecure B4860 boot, I am attempting to implement the PBI workaround option for errata A-007212 as described in B4860CE_Rev4.pdf.

Most of the steps can be represented by the available PBI commands but I don't understand step 2: "Wait for PBI (unsecure parts) before continuing with the workaround".

Could someone let me know what it means please (maybe someone has even implemented the PBI workaround successfully).

Thank you in advance.

Jon Baird

[ufedor]

Sorry, which "CS0 related registers"?

[jonathanbaird]

I’m assuming that if cfg_rcw_src is selecting NOR Flash, this will be on CS0 therefore I assume I need to set up: -

LAW_LAWBARHn

LAW_LAWBARLn

LAW_LAWARn (target set to IFC)

IFC_CSPR0

IFC_CSOR0_NOR (mostly already set up by cfg_rcw)

IFC_FTIM0_CS0_NOR

IFC_FTIM1_CS0_NOR

IFC_FTIM2_CS0_NOR

And any others I have forgotten…

[ufedor]

Your assumption is incorrect.

The PBI instructions are read by PBL - i.e. it is not required to perform such initializations.

[jonathanbaird]

Sorry, I missed out something from the last reply..

Ok, not required by PBL but don’t these registers need to be set up for when the PBL has finished and it’s time to boot?

I’m obviously doing something else wrong then; I end up in a state with HRESET permanently low (driven by the 4860) and I can’t attach with the emulator. Only a power-on reset recovers it.

[ufedor]

Please confirm that you are doing the experiments using QCVS PBL Tool - i.e. the RCW has correct CRC.

[jonathanbaird]

I am entering the PBL code in codewarrior 10.5.0 in component inspector-PBL. Then I click ‘generate processor expert code’ under the ‘project’ tab.

[ufedor]

Please provide the resulting RCW binary image for inspection.

[jonathanbaird]

Ok. 3 formats (filenames appended). I am using the srec to program the flash. For future reference, which format is best for you?

Based on what you said previously, the IFC section is not required. Originally, it was just the rcw and no pbi data with the similar result (HRESET asserted by the processor).

[ufedor]

Are you writing the RCW from scratch or modifying RCW from the Freescale SDK?

Please confirm that the processor was able to boot with "original" RCW (before the modification).

[jonathanbaird]

Hi ufedor,

Another possible problem even before we get to PBI……

We have provision for setting cfg_rcw_src to the hard coded rcw setting. When I do this we can at least use the emulator (this is what we were using previously when we were having problems getting stuck in doze after reset). So I looked at the DCFG_CCSR_PORSR1 and everything looked normal except for bit 14 (pll_cfg_sel_b) which was set to 0. In our firmware, the PLL_CFG_SEL_B pin is set to ‘1’ at power-up, the intention being to load the clock configuration from RCW. When I look for information on the PLL_CFG_SEL_B pin function in the reference manual rev 1, I can’t find it although it is referred to in the DCFG_CCSR_PORSR1 register description. It used to be a shared pin with IFC_A18...

Should we still be driving IFC_A18 at power-up? If so, is it inverted?

I was thinking that maybe, when cfg_rcw_src is selecting the hard coded rcw, the above doesn’t matter but when we select nor flash as the rcw source, it does, maybe..

It doesn’t seem clear in the reference manual.

Regards

Jon

[ufedor]

Please use a digital scope to check behaviour of the IFC_A18 during power-on reset.

Refer to the B4860 QorIQ Qonverge Data Sheet, Rev. 2, Table 1. Pinout list by bus, Notes:

“8. Pin must NOT be pulled down during power-on reset. This pin may be pulled up, driven high, or if there are any externally connected devices, left in tristate. If this pin is connected to a device that pulls down during reset, external pull-up is required to drive this pin to a safe state during reset.”

[jonathanbaird]

IFC_A18 is pulled high during PORESET_B low and for at least 3 SYSCLKs after PORESET_B goes high.

[ufedor]

Please provide a digital scope trace showing the IFC_A18, SYSCLK and deassertion edge of PORESET_B.

[jonathanbaird]

Please find attached scope traces showing IFC_A18, PORESET_B and SYSCLK. This is for the hard-coded RCW case, but the logic/ timing is the same.

Yellow: SYSCLK (66.667MHz).. See note below.

Green: PORESET_B

Blue: IFC_A18

end_of_poreset_b_2.gif: -

N.B. I could not get a good trace with SYSCLK connected due to a lack of a local ground at the probe tip so the terrible-looking SYSCLK is not the actual waveform but good enough as a timing reference for the other signals which, as you can see, are also contaminated. Without SYSCLK connected, these artefacts disappear and are more representative as you can see in the other gifs. I will try to capture a better trace as soon as I can get the right test setup but can we work with this one for now.

end_of_poreset_b_3.gif: -

No SYSCLK connected to get rid of the noise artefact. 1us per division.

end_of_poreset_b_4.gif: -

No SYSCLK connected to get rid of the noise artefact. 50us per division.

[ufedor]

It is assumed that maximum rise/fall time of PORESET_B is 1 SYSCLK (in contrary the input setup/hold times for all POR configs became meaningless).

Please refer to the B4860 QorIQ Qonverge Data Sheet, Table 13. RESET Initialization timing specifications.

[jonathanbaird]

Ok. Mods done to speed up hreset_b and poreset_b risetime.

I now see poreset_b go high followed about 662 us later by only two accesses to nor flash on IFC_CS0 (active for about 822 ns each access). Hreset_b stays asserted.

I assumed that the two IFC_CS0 accesses were to read the RCW preamble so I looked at IFC_AD(0:15) and could see that the data being read did not match the preamble (A separate issue unrelated to B4860).

So, the questions:

a) Are the first 2 reads for reading the preamble?

b) If the processor does not find the preamble in the first two reads, does the RCW loading process halt immediately with hreset_b held low?

Regards

[jonathanbaird]

Yes, good point. It is not specifically stated but the other timings wouldn’t make much sense otherwise, especially with another active device driving the config pins. I shall pass that on to the designer. Also, in the same table, HRESET_B needs 1 SYSCLK rise/ fall and we are almost certainly breaking that as our pullup is 4K7. I shall pass that on too.

I will report back with the outcome once mods are done.

Thanks

Jon

[jonathanbaird]

RCW was entered via the fields in the RCW section of the ‘Component Inspector - PBL’ tab – modifying as required.

I haven’t tried the unmodified one as it doesn’t match our hardware.

[jonathanbaird]

Ok, not required by PBL but don’t these registers need to be set up for when the PBL has finished and it’s time to boot?

[ufedor]

“Wait for PBI (unsecure parts) before continuing with the workaround” corresponds to the PBL Flush command (set 0x138000 to 0x0) – i.e. previous write is followed with a read from the same address to ensure the previous write has taken effect.