Some other users have reported this before. The explanation to this is that digital pins are shared by different interfaces (as you pointed out) through muxing, which makes them behave differently at startup when interfaces are loaded during kernel startup. Right now this is being investigated and as soon as I have a more accurate answer to your questions I’ll let you know.
Is there any progress on this issue? we have a product which can't be released until we solve this problem.
The pin state changes 5ms after power-on, which suggests to me the micro is making the change, but I'd like to know if it is configurable or hard-coded.
This would be happening before the kernel starts to boot up wouldn't it?
I would suggest to customize the standard Linux image, you’ll need to exclude the packages that you won’t be using and just use the ones you’ll definitely need, in your case the ones related to the GPIO configuration. Then when you’re building the image, you can de-activate the drivers you won’t be using with your module via the menuconfig tool.
You can check the Edison Board Support Package for further instructions, there you’ll find how to add or exclude packages from the image.
I've been trying to go through the kernel source without much luck.
I think I have found the files where the GPIO is initialised but they are not included in the source download.
specifically the directories...
etc are all missing.
I'm no Linux expert - am I missing something?
Is it possible to get the full u-boot source used to build the firmware image?
I was wrong...
It is the IFWI bootloader which initialises the GPIO pins. Unfortunately the source does not appear open - is that correct?
If not, perhaps you can direct me to some information regarding the SFI configuration.
It would appear that the IFWI bootloader uses this to know which drivers to initialise. Can I use the SFI tables to stop the IFWI from initialising the GPIO pins until the kernel loads?
Intel is giving no help at all...
I called their office to see if there was anybody I could talk to about the Edison. The reply was, literally, "I'm sorry, but it's company policy not to release that kind of information" !
Pablo, in desperation I tried your idea. I compiled a custom image with every extraneous driver and module disabled, and it had no effect on the boot up state of the GPIO pins. No surprise there.
We've confirmed it is the IFWI firmware setting the initial state of the pins. But without the source there is nothing we can do to change it.
For anybody else starting their design with the Edison, these are the initial states of the GPIO pins (without alternate functions)...
GP44: Input with 50K pull-up
GP165: Output low
GP14: Input with 50K pull-down
GP15: Input with 50K pull-down
GP45: Input with 50K pull-down
GP46: Input with 50K pull-down
GP47: Input with 50K pull-down
GP48: Input with 50K pull-down
GP49: Input with 50K pull-down
The mini breakout board user manual has a table which maps these pins to the appropriate headers. There is a column in that table which seems to list alternate functions for these pins (e.g. Accelerometer or gyro interrupts). It would appear that these references might explain the initial state of the pins.
But as far as I can tell, they don't belong to the arduino break out or the mini breakout so they must be for some other breakout board/product? Perhaps the phone hinted at in other docs?
As far as we are concerned our solution is two-fold:
1) Abuse the pins with a super-strong pull-up (5-10K) so they behave as we need them to at start-up.
2) Hope Intel doesn't change the IFWI firmware (unless it's to make everything input high-Z).
3) Phase out the Edison and go to something else.
OK - this story gets even better...
The GPIO states listed in the last post are the state of the pin from 5ms after power up. So on the Edisons I have been testing with, the GPIO has been:
0ms to 5ms - Input high-impedance
5ms onward - as listed above.
But I've just run across one edison which does the following:
0ms to 5ms - Input with 2K pull-down
5ms onward - as listed above.
And one other edison which has the 2K pull-down intermittently. Half the time it is a strong pull-down the other half it is high-impedance.
So for the GPIO states - the first 5ms seems to be unpredictable, and the following 30 seconds is uncontrollable!
Unfortunately, the SFI tables and the IFWI cannot be made available to the public given that it’s not open source. As a suggestion, a hardware workaround may be possible by buffering the devices from the GPIO with a muxing that has a delayed select.
Yes - that's what we are looking at - a new board design.
We considered using another GPIO pin to control a mux on the level shifters but since we can't trust the GPIO state at startup that doesn't work. A timer could work but it's ugly.
Frankly, since we can't use the GPIO pins - we would be better off just putting a micro on the I2C bus and using it for all the I/O. It would give us a full speed SPI bus, extra I2C, heaps of I/O etc...
The Edison just becomes something that runs linux and acts as a bridge between the rest of our network and the micro which handles the hardware.