Change boot GPIO states

[farfromrefug]

Hi,

I am currently buiding the Pyro64 to test it. One thing i would need it for is to able to change GPIO state as soon as possible. The reason are:

• we have a power button for which we need to put the GPIO state to 0 as soon as possible. That button is used to power on the device and we need to tell it we are good and the edison is started
• we have a pump connected to gpio which state makes it start at full speed. We would like for the pump to be off on start (less noise)

Can i do that using a recipe? Could someone point me to the right way to do that? Sorry i am new to building my own linux image

Thanks

[htot]

@farfromrefug During boot first the microkernel starts (from ROM), then U-Boot, then (as it is now) after pressing you manually boot the kernel with initramsfs which then switchroots to the rootfs on the sd card. Eventually the manual intervention will go away (but currently I want always to automatically fall back to a working original image). But I think the fastest point in time to reset a gpio is in U-Boot. I don't know if you feel like patching U-Boot for this? I will be working on getting U-Boot to provide acpi tables to an acpi enabled kernel. It might be possible to get his done by providing some acpi stuff to U-Boot. As I understand U-Boot has an interpreter for that. More info here: https://edison.internet-share.com/wiki/ACPI

[farfromrefug]

@htot Yes that s what i was thinking too. I also talked with @esialb and that s what he said too. Now about patching U-Boot i think i can do it. But honestly i don't know anything about it or ACPI. If you are willing to help me a bit that would be great!

If i understand correctly the ACPI stuff is not working yet but you are working on it? If so let me know if i can help in anyway too.

Thanks

[htot]

No it works (but not everything is there yet). Andy Shevchenko works on that. I just trying to make it build with yocto.

[farfromrefug]

Ok great do you have a sample code anywhere? I or maybe I should ask @andy-shev directly? Thanks again

[htot]

The acpi code is linked from here https://edison.internet-share.com/wiki/ACPI

[andy-shev]

U-Boot does not have any ACPI interpreter. It just provides a minimum tables needed to boot a board on certain OS(es). Basically what you, @farfromrefug, need is to create a pinctrl/GPIO driver for Merrifield in U-Boot (followed by enabling of gpio command there) where you control pins as needed. You may take Linux' driver as a base.

It doesn't have anything to do with ACPI per se.

[farfromrefug]

@andy-shev thanks it is what i was afraid of when i first started to look at this. Linux driver is something totally new to me but i might try(don't really have a choice). That's what you are talking about right? https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-merrifield.c I even see you are a contributor ! I might try with this. Thanks @andy-shev for pointing me there.

[farfromrefug]

@andy-shev Made a a little bit of research about how i could achieve this. I think i figured it out:

• adding the merrifield driver to you u-boot edison branch
• update edison_defconfig to enable GPIO command

Now from what i have seen i can simply upgrade my u-boot without touching my kernel or linux, is that right? I am currently using jubilinux. Would upgrading the u-boot still work?

Thanks and sorry for all the questions

[htot]

Newer u-boot still boots the original edison image. You can read in the wiki for this repo how to upgrade. I few env variables need to be manually modified. Likely jubilinux will also still boot, otherwise you can always go back to the original u-boot.

[farfromrefug]

@htot thanks just pushed a compile uboot with success! Now i have a final question. If i want to update my "flash image" with that u-boot. Simply copying the u-boot.bin is enough? I see a u-boot.img in my "flash image" which is not built by u-boot.

[htot]

That one would be used by flashall --recovery (xfstk). And of course the env still needs to be fixed up.

[andy-shev]

@farfromrefug There are two parts, pin control or Family-Level Interface Shim (FLIS) and GPIO. Thus, if you want to switch function of the pin (pin muxing) you need pin control stuff to do it, GPIO drivers works only on GPIO function itself.

You need to consider pinctrl-merrifield.c and gpio-merrifield.c.

[farfromrefug]

@andy-shev thanks for the info. I will to look deeper at this. To be honest for now i have no idea on how to do this. Will dig deeper.

[htot]

@farfromrefug Have you gotten any further with this issue? If so would you like to share the result?

[andy-shev]

To support I²C #6 @staroselskii added minimal pin control stubs. You perhaps may extend this.

[andy-shev]

This is a U-Boot related question and since we are switched to upstream, this should be asked in official mailing list of U-Boot project. Closing here.