Provide a means to use an alternate config.txt based on a gpio pin level

[msperl]

Can you please provide a means to use/load an alternate config.txt based on a gpio pin - say: use_alt_config_gpio=26 to use GPIO 26 as a signal for which one to load?

[popcornmix]

Can you describe the use case for this?
Is this for using a jumper/switch? Or detecting external hardware?

[msperl]

having a fallback os that I can boot from when the "target" os does not work.

During the testing of the merges to enable the clock framework this would have been very handy - I had to resort to using u-boot instead to avoid "bricking" the rpi and having to get back to the rpi to rpi out the sd card to modify config.txt so that the default firmware gets used.

[msperl]

Booting via USB is only possible on bcm2708 devices without ethernet...
There are no other ModelA or CM variants that have the newer chip(s)...

[popcornmix]

We currently support sections. E.g. [pi3] or [0x123456789] (serial number).
We could add a section like: [gpio4=1] (active when GPIO4 is high).
You could combine that with the include directive.

[gpio4=1]
include config_testing.txt
[all]
# safe options

where config_testing.txt contains your risky options.

[msperl]

fine with that as well...

We may only need to make sure we have the correct pullups/pulldowns for those gpios, so that we get consistent behavior.

So [gpio4=1] would mean a pulldown on gpio4
And [gpio4=0] would mean a pullup on gpio4.

but that could be a separate thing to allow to set the gpio pullup/pulldown prior to testing the conditions...

[popcornmix]

The plan is that the config.txt decision is purely made by reading a gpio level.
It won't change gpio input/output state or pullup state.
You are free to attach external pullup/pulldowns, or configure the pullups/pulldown through dt-blob.dts, or pick a line that already has a suitable pullup/pulldown.

[msperl]

That makes is slightly "wobbly", but then I would just need to find a gpio that has a pullup or pulldown by default...

As per datasheet the SOC should come up with these pull-ups/pull-downs:

• pull-up: GPIO0-8, gpio34-36, gpio46-53
• pull-down: GPIO9-27, gpio30-33, gpio37-43
• without: gpio28-29, gpio44-45

If the firmware does not change them, then we should be able to use those as their default states.

[msperl]

Note as an aside: if there is a means to chang the base directory where the firmware looks for all of its files, then this would also help keeping all the setups different.

So that could get used like this:

[gpio4=1]
cd mykernel
[all]

This way we can make kernels, dts and overlays for development go to a separate sub-dir and then these would get used without causing conflict (I just had one such situation where apt-get upgrade replaced my bcm2710-rpi-3-b-s.dtb - and this would avoid it - note I have a foundation.dts to use with the foundation kernels)

[xdsopl]

Thank you msperl for beating me to it in opening this issue :)
I am also very interested in having an "alternate config" on boot using a GPIO.
Just reading RPI-CMIO-V1_2-SCHEMATIC.pdf I can see, that we already have a nice GPIO47_CTL_1V8 which is read by GPIO47_1V8 on boot and "if low perform 'alternate' boot".
Can't find any documentation to this "'alternate' boot" though.
With this, I won't need uboot (which can't detect the eMMC on CM anyway).

• Ahmet

[msperl]

Actually I got u-boot working fine on my cm - there was not even a major change needed (not that I can remember the details how I did it, but it was not that complicated - you may only need to set the jumpers on the CM-connection-board slightly differently than documented - disable USB slave disable)

[popcornmix]

https://dl.dropboxusercontent.com/u/3669512/temp/firmware_gpio.zip
implements the [gpio4=1] filter. Please check it behaves as expected.

The cd directory suggestion is not so trivial, so isn't supported.

[msperl]

looking at it.

I guess most of the needs could be solved by having a command to define the directory for the overlays - this would be just short of having distinctive firmware based on gpio...

That way I could make it look like:

[gpio4=1]
kernel=mine/kernel7.img
device_tree=mine/bcm2708-rpi-cm.dtb
device_tree_overlay_dir=mine/overlay
[all]

[msperl]

So I gave it a try with the following fragment:

...
[gpio37=0]
kernel=kernel.img
device_tree=bcm2708-rpi-cm0.dtb
[gpio37=1]
kernel=kernel.img
device_tree=bcm2708-rpi-cm1.dtb
[all]

but regardless of the GPIO it always uses gpio37=1

Here some diagnostics with GPIO37 pulled low by another RPI:

root@raspcm:~# /opt/vc/bin/vcdbg log msg 2>&1 | grep bcm2708-rpi-cm
002069.764: Loading 'bcm2708-rpi-cm1.dtb' to 0x3f5710 size 0x2915
root@raspcm:~# raspi-gpio get 37
GPIO 37: level=0 fsel=0 func=INPUT

and when I switch level to 1:

root@raspcm:~# /opt/vc/bin/vcdbg log msg 2>&1 | grep bcm2708-rpi-cm
002086.535: Loading 'bcm2708-rpi-cm1.dtb' to 0x3f5710 size 0x2915
root@raspcm:~# raspi-gpio get 37
GPIO 37: level=1 fsel=0 func=INPUT

Does it only work for gpio4?

Note: I originally had one with kernel=u-boot.bin, so I have simplified to the above only using foundation kernels...

Here something more, to show the firmware used:

[    0.254415] raspberrypi-firmware soc:firmware: Attached to firmware from 2016-05-04 15:54

[msperl]

Note I have also attached an oscilloscope - the pin levels always stay at the expected values during boot
(just to confirm if something was pulling the pin high, or something)

[msperl]

note that I went all the way to use gpio4:

[gpio4=0]
kernel=kernel.img
device_tree=bcm2708-rpi-cm0.dtb
[gpio4=1]
kernel=kernel.img
device_tree=bcm2708-rpi-cm1.dtb
[all]

still cm1 is loaded:

root@raspcm:~# raspi-gpio get 4
GPIO 4: level=0 fsel=0 func=INPUT
root@raspcm:~# /opt/vc/bin/vcdbg log msg 2>&1 | grep bcm2708-rpi-cm
002070.907: Loading 'bcm2708-rpi-cm1.dtb' to 0x3f5710 size 0x2915

[xdsopl]

Doesn't work for me either and I have shorted the GPIO4 hard to GND or 3V3 on RPI 2 B at home.
Can't test on CM using GPIO47 until next week at work.

• Ahmet

[popcornmix]

Can you try the updated https://dl.dropboxusercontent.com/u/3669512/temp/firmware_gpio.zip
It should fix the issue with reading gpio state and also implements:
overlay_prefix=overlays/
to set an alternative overlay path. Note: this is a prefix so the final / is required.

[xdsopl]

Sorry, still doesn't work and I have something as simple as this in config.txt:

kernel=kernel7.img
[gpio4=1]
kernel=rescue.img

It always uses rescue.img, regardless of forced level on GPIO4 (PIN16 on J8 with RPI2B).

FYI: bootcode.bin has same md5sum as before, if that makes sense.

[popcornmix]

The change was to start.elf not bootcode.bin.

$ vcgencmd version
May  4 2016 17:41:04 
Copyright (c) 2012 Broadcom
version 9f4e6501c75396ac5a0e1dfb54d0902ff8feb5e5 (clean) (release)

[xdsopl]

This is what I've got:
$ vcgencmd version
May 4 2016 17:44:54
Copyright (c) 2012 Broadcom
version 9f4e6501c75396ac5a0e1dfb54d0902ff8feb5e5 (clean) (release)

[popcornmix]

Looks okay - I guess you are using start_x.elf or start_cd.elf hence the slightly different build time.

[xdsopl]

Have tried both start_x.elf and start.elf, still doesn't work.
Is there any way I can help to debug, besides trying new builds?

[popcornmix]

GPIO 4 is pin 7 of J8 by my numbering.

[msperl]

As far as I can test I can now switch between u-boot and foundation with a single GPIO...
I still need to test the overlay_prefix.

As far as I can tell the functionality work now!

When do you plan the next update of the firmware, so that I can start distributing it to all the different machines via "normal" means?

@popcornmix : Thanks for all your efforts!

[popcornmix]

It may be a few days. There is a raspbian update imminent, so we are avoiding pushing anything risky. We'll push this once that is finalised.

The GPIO commit did require some reordering of startup calls:
You need the board type to configure the gpio, you now need the gpio when reading config.txt, and config.txt can override the board type so it's all a bit tricky to do these things in the right order.

[xdsopl]

Awesome! Works!
Sorry about the confusion using the wrong GPIO4 PIN :)
msperl: Does GPIO47_CTL_1V8 (PIN59 on J5 on CMIO) work for you too?
Can't test it on CM myself at the moment.
popcornmix: Thank you a lot!

[msperl]

I did not test 47 as it is 1.8v and that requires a transistor to control from a second pi....

@popcornmix : thanks again - I am happy if it takes a bit longer - anything is better than having to rip out the sd card (besides USB boot on the cm or model a)

[msperl]

@popcornmix : so the overlay_prefix thing seems to work, but it is slightly hard to verify - it would help if there was better logging in the firmware for:

• the active config chosen (so something like Chose "gpio37=1")
• the path of the overlays are not written out with the prefix - i tried with a negative test (using overlay_prefix=does/not/exist/) and got: Failed to load overlay 'hifiberry-dac'. But the prefix is not printed when the directory exists either...

I guess that would complete that patch.

[pelwell]

I don't think the lack of verbose logging makes it harder to verify - you just have to be more creative, using overlay names as trace points, etc.

One thing you need to be aware of is that DT directives are parsed in a separate pass, after the other settings. As a result, you can't change the overlay prefix part way through a set of overlays - the value of the prefix at the end of the file is the one which is used.

[msperl]

yes, it is acceptable as is - I just wanted to mention that there is some place for improvement...

I just found out because I thought that using /opt/vc/bin/vcdbg log msg would show those details immediately and I could do some lazy testing based on those - I guess it will come up again as another issue raised by someone else (but I will not raise it because of this discussion...)

[xdsopl]

FYI, I have tried gpio47=0 and shorted GPIO47_CTL_1V8 (PIN59 of J5 on CMIO) to ground just now and it doesn't work on the CM.
I can measure 1V8 shortly after powering on and then it drops to 0V.
On any other GPIO (tried gpio5=0) it works.
Would have been nice to use that gpio47 pin, as it already was meant to be used for something like that.
But for now: Thanks, I can work with that.

[msperl]

Look at the schematics of the CMIO board with regards to "USB Boot Enable"

GPIO47 is used for something entirely different on the CMIO - select USB boot or boot for MMC.

This may be different when using gpio47 on your custom IO board - there you can define your preference as it does not necessarily come with that specific logic for USB boot.

Note that basic USB Boot is part of the BCM283X ROM, so that code can not get changed!

[xdsopl]

EMMC_DISABLE_N is used for USB Boot, GPIO47_1V8 can disable USB Boot over EMMC_DISABLE_N, if for example the slave USB cable is disconnected.
Search for "MODULE BOOT OPTIONS" in RPI-CMIO-V1_2-SCHEMATIC.pdf.
The last of the three options provided is what I would have liked to use:

snip

BCM2835 BootROM boot from eMMC with GPIO boot select:

• Set J4 to disable USB boot
• EMMC_DISABLE_N therefore always HIGH
• On power up BCM2835 boots from eMMC
• BCM2835 boot SW reads GPIO47_1V8 (GPIO47_CTL_1V8) if low perform 'alternate' boot
  (e.g. can boot into safe mode, or USB mass storage...)
• Once booted GPIO47_1V8 used as status LED

snip

I couldn't find any further documentation on that 'alternate' boot :(

[msperl]

"Boot SW" = ROM boot loader and not bootcode.bin or start*.elf!
So this is relevant before the firmware becomes even active!

I guess there is one more ROM-boot loader option besides:

• boot from sdcard/emmc
• boot from usb (possibly as long as there is no "SD-Card" with the expected files available)

The ROM boot-loader has GPIO47 as input for a short period of time and then will switch to output (but that may also only happen in the later firmware stages), so that emmc becomes available again on the CM.

[xdsopl]

Thank you for clarifying that we cannot use gpio47=0 in config.txt :)

[popcornmix]

This feature is in latest rpi-update firmware.

[msperl]

thanks!