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.

Sign up for GitHub

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

Jump to bottom

VL805 firmware loading twice during runtime #1380

Closed
vianpl opened this issue Apr 27, 2020 · 4 comments
Closed

VL805 firmware loading twice during runtime #1380

vianpl opened this issue Apr 27, 2020 · 4 comments

Comments

@vianpl
Copy link

vianpl commented Apr 27, 2020

My aim is to both integrate this functionality into mainline Linux and u-boot. Note that we have systems where only Linux is used and systems where u-boot is used as a bootloader preceding Linux.

What I'm seeing is that, on boards with no EEPROM available, if both u-boot and Linux trigger the firmware reload, VL805 dies the second time around. I can limit the firmware loading to only u-boot, which makes USB functional in Linux, but that's not good enough as some users might want to bypass it and only run Linux. I have some questions with regard to all this:

What kind of PCI reset needs VL805 to be performed for it clear its firmware? I've tried some power state combinations and called (half understood) Linux APIs without luck so far.

Is there a not too intrusive way to know that VL805 is up and running? As far as I can see, basic xHCI registers respond properly even if firmware isn't available.

That's all, thanks in advance!
@timg236
Copy link

timg236 commented Apr 28, 2020

Not sure about what PCI reset is required, but Linux does a fundamental reset which causes the VLI chip to be reset and was the reason for having to reload the firmware in the first place. Curiously, I'm not seeing this when the USB-MSD start.elf transfers control to Linux.
It does a clean xHC stop / reset then lets Linux do the PCIe reset.

If the VLI firmware is running then the version number which is in PCI config-space will be non-zero. See example for how to get this via lspci to get the offsets
https://github.com/raspberrypi/rpi-eeprom/blob/master/rpi-eeprom-update#L452

@vianpl
Copy link
Author

vianpl commented Apr 28, 2020

Not sure about what PCI reset is required, but Linux does a fundamental reset which causes the VLI chip to be reset and was the reason for having to reload the firmware in the first place. Curiously, I'm not seeing this when the USB-MSD start.elf transfers control to Linux.
It does a clean xHC stop / reset then lets Linux do the PCIe reset.

So I understand that with USB-MSD there is no need for firmware loading in Linux, right?
That would be similar with what I see on my u-boot+Linux setup where loading the firmware from u-boot is good enough for both.

I'm starting to doubt if that PCI reset is really happening in Linux or on the firmware side before passing control. Ultimately all this doesn't matter that much if I manage to use your suggestion below and only load the firmware when really needed.

If the VLI firmware is running then the version number which is in PCI config-space will be non-zero. See example for how to get this via lspci to get the offsets
https://github.com/raspberrypi/rpi-eeprom/blob/master/rpi-eeprom-update#L452

Thanks for the help!

@timg236
Copy link

timg236 commented Apr 28, 2020

The firmware never does a PCI reset so in theory the firmware re-load isn't required. However, Linux and the bootloader might not agree on the PCI BAR configuration or other things which I think is why the STB driver always does a reset. Or on other chips, PCIe is never configured first.

The firmware assumes that the basic PCI configuration for the VLI has already been done in order to avoid trashing whatever the OS did.

It might be possible to pass the run-time parameters via device-tree which will potentially speed up boot if the PCI is an acceptable state because Linux can just re-use these parameters or adjust things if necessary.

@vianpl
Copy link
Author

vianpl commented Jun 16, 2020

https://lkml.org/lkml/2020/5/7/1056

@vianpl vianpl closed this as completed Jun 16, 2020
@lategoodbye lategoodbye mentioned this issue Jan 4, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@timg236 @vianpl