Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Ster1
Novice
1,193 Views

Soft-reset on intel-edison

On soft-reset, I see uboot on intel-edison is setting pins high.

Uboot's edison patch seems small and has no information about the pins. Where is getting set, then?

7 Replies
Pablo_M_Intel
Employee
132 Views

Hi stixter,

The explanation to this is that digital pins ae shared by different interfaces through muxing, that's why some pins go high at startup, the interfaces are loaded during kernel startup. The IFWI firmware is setting the initial sate of the pins, however, the SFI tables and the IFWI cannot be made available to the public because it's not open source information.

If you want to avoid this behavior you can try connecting pull down resistors on these pins to keep them 'low' before they are initialized.

Regards,

PabloM_Intel

Ster1
Novice
132 Views

What can we do in software?

Also, in the Linux kernel sources for intel_edison, I see the file called

arch/x86/platform/intel-mid/intel-mid.c and it has the following code:

static void intel_mid_reboot(void)

{

if (intel_scu_ipc_fw_update()) {

pr_debug("intel_scu_fw_update: IFWI upgrade failed...\n");

}

if (force_cold_boot)

rpmsg_send_generic_simple_command(IPCMSG_COLD_BOOT, 0);

else

rpmsg_send_generic_simple_command(IPCMSG_COLD_RESET, 0);

}

Is there anyway to send COLD BOOT command (from command line or via gpio) ?

Looking to test before making it permanent.

Ster1
Novice
132 Views

Adding 2.6k ohm resistor as pull down made no difference to the behavior. It seems like the voltage across those pins go "high" or 5V when "reboot" command is issued, and before uboot runs. Either a power reset of the entire board through software OR way to set the status of these pins explicitly either in uboot or kernel is a must have for us.

Ster1
Novice
132 Views

Alternatively, Is there a way to set a pin in the kernel directly to either power-reset OR?

 

Failing that, Is there a way to set pin to a known state in either uBoot or kernel before userland programs are ready?
Pablo_M_Intel
Employee
132 Views

Hi stixter,

As a suggestion, a hardware work around may be possible by buffering the devices from the GPIO with a muxing that has a delayed select. Have you tried this?

Another option would be to customize the standard Linux image by excluding the packages that you won't use and that cause this 'high' behavior at boot.

Regards,

PabloM_Intel

Carlos_M_Intel
Employee
132 Views

Hi stixter,

Do you have updates on this?

Have you been able to run more tests? Have you considered the suggestions above?

Regards,

Charlie

Ster1
Novice
132 Views

We redesigned the board and do not have this problem anymore. Thanks!

Reply