1 Reply Latest reply on Jun 13, 2018 8:00 AM by ZhiF_31

    Memory options for Boot Loader and Boot Code


      I recently had an engineer ask how to maximize the available memory space required to start a microprocessor.

      I paraphrased the question and provided the following response, which I'm posting here for comments.

      References to "Good practice" with some justification would also be appreciated.


      Rephrased Question:

      Q1: Can boot code extend across multiple die is a single package?

      Q2: Can the bootloader and the kernel reside in different devices?


      Initial Response:

      Answer to Q1: Yes – however, the boot code should be as small as possible – used only to initiate basic security and communication functions to internal and external devices including memory before starting the kernel.

      Answer to Q2: Yes.


      S34ML08G201BHI000 @ http://www.cypress.com/file/207446/download is a good memory selection.

      This part does have two die. For most operations, the separate die are transparent. However, there is one unique feature. Flash devices have a constraint that the flash can’t be read while a section of the flash is being written. Writes take much longer than reads, so this can cause extra waits. With two die, one die can be read while the other is being written. Cypress describes this feature in section 6, Read Status Enhanced of the data sheet.

      Keeping the Boot Code to a minimum will mitigate many of the potential issues. U-Boot should fit in under 128KB (Reference U-Boot Design Principles @ https://www.denx.de/wiki/U-Boot/DesignPrinciples ).

      If more memory is desired and physically contiguous memory is desired, Multiple Flash devices can be configured to appear as a single contiguous memory device. This can be done with logic outside the microprocessor or with serial memory, by daisy-chaining the memory.

      Cypress has multiple types of memories compatible with NXP processors. There are Excel tables matching the processors with recommended memories @ http://www.cypress.com/chipset-partners

      Given the specific processor being used and the amount of memory desired, I can recommend a couple specific options aligned with Cypress’ flash memory roadmap @ http://www.cypress.com/product-roadmaps/cypress-flash-memory-roadmap

      I don’t have the insight into NXP’s i.MX processors. It may help to pose the same question about memory recommendations to the ESC’s NXP IMX lead, Anna Jamieson.

      Note: If Serial Memory is selected to hold boot code, selecting memory with a reset input will ensure the memory starts at a specific address after both power on reset and re-start. Some of the older serial flash devices don’t have a reset input. Older devices can be identified in the part number by the Technology. Older technologies used larger feature sizes such as 110 nm or 90 nm. Reference Community Post https://community.cypress.com/docs/DOC-10179

        • 1. Re: Memory options for Boot Loader and Boot Code



          Thanks for posting your comments about booting from a multiple-die-stack package flash device.


          One thing you need to pay attention to when dealing with multiple-die-stack devices, is that reading across the die boundary.


          If the device is Parallel NOR or NAND device, it usually does not have any problem, because the reading operation is per page. If the multiple-die-stack device is a SPI device, it may not support burst read across the die boundary. In that case, if the boot loader software resides in more than one device, the host controller will need to be aware of the die boundary and perform the read operations accordingly. That means the first burst read can be done from Address 0 to the first die boundary, then a second burst read is necessary starting from the 2nd die, so on and so forth.


          New generation of Cypress SPI devices support burst read across the die boundary in MCPs. Users can check with the specific datasheet for such function.


          Best regards,