we are in the conceptional phase of a i.MX6 based design. Our customer wants to use a NOR-Flash as primary boot device but we also need an CSI-port with 20-bit, so the only possible solution I see (caused by IOMUX limitations) is to connect the NOR-flash in a muxed manner to the proceesor EIM-port with an external address latch. In addition to this we want to connect a CPLD to the BootConfig-pins to have flexibility in configuring the design to different boot sources.
My plan is to use the CPLD as address latch because the BootConfig1+2-pins are the multiplexed address/data signals too. But to get this to work I need an indication of when the CPU sampled the boot configuration and it is safe to switch the CPLD from configuration- to address-latching-mode. I see in the i.MX6 Reference Manual that there is a feature called "BOOT_MODE-Inversion" (IMX6DQRM.pdf Re. 0, page 5010). As I understand, the CPU outputs the inverted value of the sampled BOOT_MODE on the BOOT_MODE-pins when the sampling of the boot configuration was done. Am I right with this??? Is there another possible solution to see when the processor finished sampling the boot configuration???
On the Freescale i.MX6-SABRE reference design schematic I see that the BOOT_MODE-pins are shorted to VSNVS_3V0 which will cause high currents when the CPU tries to output a '0' on this pins because of BOOT_MODE-Inversion. Is the BOOT_MODE-Inversion implemented in the i.MX6_CPU's as described in the reference manual??? Has someone checked this out??? Maybe someone with a i.MX6-SABRE board on his desk can check it out by changing R106 from 0 ohm to about 1k ohm and measure the voltage on the BOOT_MODE1 after the device booted up (if the voltage on BOOT_MODE1 is 0V after boot has finished the feature should work as described)???
Thanks a lot in advance.
Please refer to i.Mx6 datasheet from below link:http://cache.freescale.com/files/32bit/doc/data_sheet/IMX6DQCEC.pdf?fpsp=1&WT_TYPE=Data Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
Table 93. 21 x 21 mm Functional Contact Assignments show BOOT_Mode show a dedicatd status afer reset.
about BOOT_MODE design info, please find through: i.Mx6 user guide.
Table 1-3. Boot mode input recommendations
hope above info can help you!
I want to boot the device from the Fuese setting.But I don.t know how to setting the Fuese.I configure BOOT_MODE[1:0]=0b00,but it always on dowload mode.What can I do?Please help me!
Yes,I see in Table 5-10,it say:the value of the bit BT_FUSE_SEL have the follow function:
0=Boot mode configuration is taken from GPIOs
1 - Boot mode configuration is taken from fuses
but I don't know how to configure the value of the bit?Please help me.Thanks!
Yes,I have readed the chapter 5.But it does not mention about how to set the value of the 'BT_FUSE_SEL'.I just list of its value and the corresponding function.Can you tell me how to set the value?I want to boot the device from the Fuse rather than GPIO.
On the page 5008 of the mentioned RM version, you can read "All the boot pins will be sampled at deassertion of system_early_rst_b."
On page 4999, you can see what is "system_early_rst_b". Then, on next page; "Once the above resets deassert, system_early_rst_b reset is deasserted after 2 CKIL clock."
Above resets are all possible user's source of reset. Typically, this is POR_B.
Conclusion, boot pins are latched when POR_B goes inactive.
Everything about inversion is a description of the internal logic, there's nothing you can change here, so you should better forget it.
thank you for your answer. But when I look at the timing diagram on page 5003 of the RM I see that IPP_RESET_B (POR) goes high and after 3 CKIL cycles system_early_reset_b is deaserted (where the Boot-Configuration pins are sampled). When I use the deassertion of POR to switch my CPLD from outputting the boot-configuration to the state where it works as address latch for the EIM then it is not guaranteed that the processor samples the right boot mode cause the sampling is done 3 CKIL cycles after POR deassertion. The PowerPC's have a reset output for such a purpose. In the hardware design guide it is mentioned not to drive a signal on the boot configuration pins while boot is not finished. There a solution with a analog switch for isolation of this signals is named, but how to trigger the analog switch?
Here is the description from the RM page 5010 regarding boot-mode-inversion:
ipp_do_boot_mode_inv[1:0] - inversion of IPP_BOOT_MODE[1:0]. Once the boot signals (ipp_boot_mode[1:0]) are sampled in SRC, SRC will generate the inversion of ipp_boot_mode[1:0] on those pins. The IO ring will use system_rst_b to generate the ipp_do_boot_mode_inv[1:0] on the boot pads:
When system_rst_b=0 , the boot pads will be configured as inputs, allowing boot info to propagate to SRC's inputs ipp_boot_mode[1:0].
When system_rst_b=1 , the boot pads will be configured as output, allowing ipp_do_boot_mode_inv[1:0] to be generated to the pads, i.e. it will be noticed on the pads will reflect that the value has flipped.
The board will catch this flip and in this way will be notified that the system sequence has changed, and it is allowed to use the boot pads for a different purpose.
I don't want to invert anything in the chip regarding the boot. When I understand the above paragraph right, then the CHIP outputs the inversion of the sampled BOOT_MODE-pins out on this pins.
I asked if someone checked this out or has a solution where this feature is used. And when the boot mode inversion works as described then there is a error in the SABRE reference design where BOOT_MODE1 is shorted to VSNVS_3V0.
For the i.MX6, at reset, all the pins are input, and remains in that direction until the I/Os are reconfigured for the EIM or other function. So, that is not a problem to driver these pins between POR and any time later.
Otherwise, I don't know how the I/Os could be reconfigured in the CPLD, so that the I/Os could be simply input with pull-up/down as needed during boot, and reconfigured as output after.
I had misread the description about the inverting mechanism that shows that the boot pins sampling is done. In that case, I agree that none of the signals should be tied directly to VCC or GND !
Finally, it is recommended to use the configuration through the fuses in a final product, so that you can get rid of the boot pins.