I know about config.txt parameters dtparam=act_led_trigger=none and dtparam=act_led_activelow=off, but these only affect the Linux kernel, which is too late as the kernel is never started. The LED is still driven by any one of the boot ROM, bootcode.bin, or start_cd.elf, causing our boot problem (there is crosstalk on EMMC_DISABLE_N induced by the LED). I have found no way to deactivate the ACT LED this early in the boot process by software to confirm this.
And a software solution is key for us. We have a significant amount of this hardware in the field which we need to upgrade (coming from Linux kernel 3.18), and we cannot easily fix all the hardware out there. Further, we plan on using the same software for the Compute Module 3 and would prefer not to make any case distinctions between CM1/CM3. The CM3 actually works fine in the same hardware which is failing on the CM1, using the same exact software.
Here are the messages coming in from the UART when booting a CM1 (created a file named "UART" on the boot partition to get these):
And nothing else.
Code: Select all
Found SD card, config.txt = 1, start.elf = 0, recovery.elf = 0, timeout = 0 Read File: config.txt, 224 (bytes) Raspberry Pi Bootcode Read File: config.txt, 224 Read File: start_cd.elf, 683172 (bytes) Read File: fixup_cd.dat, 2623 (bytes)
Is there anything more I can try? Is it possible to patch the firmware so to keep the LED untouched?