SBF (Serial Boot) 52274 52277 5227x

[PaulH]

The SBF module has an errata, SECF122, that prevents the serial boot facility on the 52274/52277 from functioning properly. After doing a serial boot, the movec instruction does not work. This means that you can not set VBR. VBR default is 0. Internal RAM can can't be located at 0x0. Therefore unless you have an external SRAM  located at 0x0, you will not have a place to put an exception table. (ie interrupts/exceptions will not work)

VBR is not the only register that is effected.

This errata is as of Rev1.3 of the part. As of  May 13.2010, Freescale does not intend to correct this problem.

[PaulH]

Any updates on this or on Errata SECF122?

[TomE]

> Internal RAM can can't be located at 0x0.

Are you sure? The manual states:

10.4.3 Execution Transfer...— If SBFSR[BLL] is set, the reset vector and boot code are read from the on-chip SRAM. (TheSBF enables the SRAM and maps it to address 0 via the RAMBAR before control of theprocessor is restored to the ColdFire core.) The reset vector (initial stack pointer and programcounter) should point to locations in the on-chip SRAM, so that boot code can initialize thedevice and load the application software from the SPI

The Errata also states:

The core has single cycle access to the on-chip SRAM starting ataddress 0x0000_0000. To avoid overlap with the on-chip SRAM, do notuse the first 128 KBytes of the FlexBus memory space (0x0000_0000- 0x3FFF_FFFF).

Is the above correct or is there something in the Errata or your private correspondence that says the above doesn't work?

 > This errata is as of Rev1.3 of the part. As of  May 13.2010, Freescale does not intend to correct this problem.

The Errata is dated August 2010, and says "TBD" on that item, so it postdates your date. Or did you mean "May 13, 2011"? Do you have something from Freescale after August 2010 that you can post here?

If you have a separate communication channel to Freescale, then you should be asking if the SBF is usable with some workarounds.

If the SBF can't be used, then you'll have to boot it some other way, or use a different chip.

Tom

[PaulH]

It was my last correspondance with Freescale that was on May2010. There had been quite a bit of correspondence with tech support at different levels of escalation. In the end they agreed that you couldn't have interrrupts if booting via the SBF.

Unfortunately no one (including myself) read 10.4.3.

I think I was under the impression that SRAM couldn't be located at 0x0 because section 6 says in multiple places that it can only be located between 0x8000_0000 and 0x8FFF_FFFF.

Thanks for takling the time to respond. We've been relying on the parallel boot from Flash, but I will give the serial boot another try.

[TomE]

Since your last correspondence with Freescale is last year, it might be worth asking them again.

Search for "SBF" on this board. Some people were working on getting U-Boot working with SBF, so they may have more experience with SBF than Freescale has.

It may be that the SBF is useless for regular booting, but might be usable on the production line for the initial loading of code into parallel FLASH. The Reference Manual promises more than that though:

10.1 IntroductionIt is nearly impossible to dedicate and very impractical to share pins for the numerous available power-upoptions on today’s complex, highly-integrated processors. The serial boot facility (SBF), shown inFigure 10-1, solves this problem by providing the user with the capability to store and load all device resetconfiguration data and user code from an external SPI memory.

With 128 of SRAM, there would be a lot of applications that could fit into that. Not having to add external FLASH would be a good feature of the SBF if it worked. It would also help avoid the problems of SECF150. SECF162 (internal resets, watchdogs don't work with SBF) is another failing of this mode though.

If you want SBF badly enough you could always change tothe MCF5445X chips, which also have SBF. But they have the "internal reset sources don't work" bug (also "no plans to fix this").

> We've been relying on the parallel boot from Flash

How are you handling SECF150? Are you using the "Split Bus" or does the pullup on SD_CKE work on that chip?

Tom

[PaulH]

Thats exactly what I had had in mind, putting our entire application in serial flash.

Re SECF 150: We're using the split bus. A lucky choice I think.