- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2406875_en-US
2406875_en-US
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2406875_en-US
2406875_en-US
Dear NXP Support Team,
one of our i.MX6Quad module customers has the requirement for a custom carrier board variant detection (loading different device tree in U-Boot).
The system uses SD Card as boot source only.
The customers idea is to use BOOT_CFG4[6] (high or low) to detect the custom board variant.
Since BOOT_CFG4[6] is documented as "EEPROM Recovery Enable" and reserved for 'Serial-ROM' boot mode.
We are wondering whether there might be any restrictions or problems if this pin is used on customer’s baseboard when booting from SD Card.
Can NXP comment on whether the BOOT_CFG4[6] can be used safely for the board variant detection without any impact on SD card boot.
Thank you in advance
Tim
Hi,
Thank you for your interest in NXP Semiconductor products,
BOOT_CFG4[6] acts as "EEPROM Recovery Enable" and there would not have an impact on SD card boot, but a restriction.
If you pull one board variant high, the impact would be regarding SD boot fail. BOOT_CFG4[6] acts as cross-boot-mode fallback mechanism, after failing the primary boot, BootROM would try to load boot firmware from ECSPI.
Results in a unwanted phenomena, maybe has a bigger impact if ECSPI pins are used elsewhere in your design. However, if your setup is ok with this restriction when SD boot fails, you could use the pin.
Regards