Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pi 4 conditional configs seem parsed before halt and get confusing when booting later #493

Open
jheeks opened this issue Oct 27, 2023 · 4 comments
Labels
documentation Improvements or additions to documentation

Comments

@jheeks
Copy link

jheeks commented Oct 27, 2023

Describe the bug

It seems that bootloader conditional configurations are evaluated and stored when entering halt mode.
Later, when starting from halt mode it seems that the conditionals are not re-evaluated but the stored status is used.

The expectation is that the conditionals are evaluated when starting from halt mode.

Steps to reproduce the behaviour

I have described this observation in forum post
The key points:

  • The configuration allows halt mode.
  • Based on state of a GPIO some boot options are changed.
  • It works as expected in power on reset case and in reboot case but not in halt mode case.

Device (s)

Raspberry Pi 4 Mod. B

Bootloader configuration.

$ vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
[gpio3=1]
BOOT_ORDER=0xf14
[all]

System

raspinfo.txt

Bootloader logs

No response

USB boot

No response

NVMe boot

No response

Network (TFTP boot)

No response

@jheeks
Copy link
Author

jheeks commented Oct 29, 2023

I have captured a UART log from bootloader
bootloaderLog.txt
With following steps:

  • power off to halt mode with button not pressed, means GPIO3=1
  • start with button always pressed, means GPIO3=0
    -> boots from USB, which fits to the condition GPIO3=1
  • power off to halt mode with button pressed, means GPIO3=0
  • start with very short button press, means GPIO3=1 afterwards
    -> boots from SD, which fits to the condition GPIO3=0

Unfortunately, i cannot see any indication of the conditional's evaluation in the UART log.
But the log shows that first boot is using USB and second boot is using SD.

@timg236
Copy link
Collaborator

timg236 commented Oct 30, 2023

The EEPROM config is not re-evaulated after coming out of vpu-HALT (WAKE_ON_GPIO) so this is the expected behaviour.

@jheeks
Copy link
Author

jheeks commented Oct 30, 2023

Ok, I understand that this behaviour is expected and will not be changed.
Is it then reasonable to make this clear in the documentation with a small note at WAKE_ON_GPIO ?
Or is it already documented elsewhere?

@timg236
Copy link
Collaborator

timg236 commented Oct 30, 2023

Ok, I understand that this behaviour is expected and will not be changed. Is it then reasonable to make this clear in the documentation with a small note at WAKE_ON_GPIO ? Or is it already documented elsewhere?

It's not documented, but I would agree that it's non-obvious so tagging this bug as documentation as a reminder to update the docs.

N.B. The underlying reasons are due to some slightly complex dependencies on whether you read the config before/after halt before/after DDR init before/after secure-boot verification.

Pi5 has an early config pass so if we release a 2711 update for top of tree then it might get nicer, too much churn right now though!

@timg236 timg236 added the documentation Improvements or additions to documentation label Oct 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants